[TriLUG] Question About NFS Client Access Config

[Sean Korb via TriLUG]

I'm having a little trouble with definitions and since I also manage
to annoy myself with pedantry I'm not sure I should ask but,
Metasploit found your port but it may not have performed a successful
mount?  I think you are doing the NFS part right but I agree (to pass
the scans and eliminate a forbidden vector) you may need to offer the
port only to the client IP address (and document a security exception
since passing the scan and managing a secure service are different
things).  As mentioned you can use routes on a separate NIC on another
VLAN with a private subnet to do this.  It's a little work and it's
not possible in all infrastructures but you can even DMZ it if you are
old fashioned and the respective subnets will never know about each
other.   Modern routers give you more options and I tear my hair out
over it because more options is often more complexity and ranking
traffic is really hard.

If they don't mind ssh ports you could potentially use sshfs (I tried
it once and it was fine but then I tried an older kernel and it wasn't
much into FUSE) or even tunnel though I have to realearn how to do it
every time it seems.

sean

On 4/9/19, Scott Chilcote via TriLUG <trilug at trilug.org> wrote:
> Hi LUGgers,
>
> An outside firm scans the servers at the hosting service where a couple
> of my employer's RHEL 6.9 virtual servers are housed.
>
> We were recently given a scan result that said that our NFS server did
> not prevent access by a remote client on the network, and we really need
> to fix that.
>
> We use this NFS share a lot, and it was configured for single client
> access in /etc/exports.
>
> The content of that file looks like this:
>
>     /home/shareme 192.168.0.193(rw)
>
>     /shareme2 192.168.0.193(ro)
>
>
> Based on what we know of NFS, this ought to be enough to prevent any
> server not having the local IPv4 address of 192.168.0.193 from access to
> our exports.  But the scan result says otherwise, and $MGMT wants this
> fixed.
>
> I spent a couple of hours rummaging the Redhat knowledge base for RHEL 6
> NFS issues, and came up with diddly squat.  If anyone else ever had this
> problem, my fu is lacking.  We already know about not allowing any
> spaces to get between the server string and the options that follow it,
> but that appears to be one of the few major bugaboos about configuring
> an NFS share.
>
> If anyone has an idea what to investigate here, I would love to know.
> It seems unlikely that Metasploit's NFS plugin got confused, but we
> aren't ready to rule that out.  Or anything, really.
>
> Much thanks for any pointers!
>
>    Scott C.
>
> --
> Scott Chilcote
> scottchilcote at ncrrbiz.com
> Cary, NC USA
>
> --
> This message was sent to: Sean Korb <spkorb at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web	:
> https://www.trilug.org/mailman/options/trilug/spkorb%40gmail.com
> Welcome to TriLUG: https://trilug.org/welcome


-- 
Sean Korb spkorb at spkorb.org http://www.spkorb.org
'65 Suprang,'68 Cougar,'78 R100/7,'60 Metro,'59 A35,'71 Pantera #1382
"The more you drive, the less intelligent you get" --Miller
"Computers are useless.  They can only give you answers." -P. Picasso