[TriLUG] Question About NFS Client Access Config

[Joseph Mack NA3T via TriLUG]

On Tue, 9 Apr 2019, Scott Chilcote via TriLUG wrote:

Hi Scott,

No-one's answered, so the answer is either obvious or unknown. The answer isn't 
obvious to me, so maybe it's unknown.

I confirmed that what you see is the default setup. My exports file looks like 
yours but the nfsd is listening to allcomers on all nics.

root at routera:~# netstat -anp | grep  2049
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN 
udp        0      0 0.0.0.0:2049            0.0.0.0:*

I assume the nfsd will only export disks to the location in your exports file, 
but otherwise it will exchange packets with anyone.

Is blocking the port (iptables) acceptable to $MGMT. (tcpwrappers only works 
with tcp not udp.) This is what I do.

At my last job, you weren't allowed to use iptables (it was cheating, you were 
supposed to be able to have an intrinsically secure machine), so nfs wasn't 
allowed, for the same reason your $MGMT doesn't want it.

The next approach would be to have the nfsd on a nic that doesn't have a route 
to the internet.

The simplest way of doing that is to have the machine on the wan with no route 
to the internet.

The next approach would be to make nfsd listen only on one IP and make that IP 
not routable to the internet.

(You can setup sshd to listen on an address. Presumably you can prevent routing 
of that address to the internet, although I haven't thought of how to do it 
other than with iptables. Presumably you can't have a default route. There's 
some magical routing used in openvpn to prevent openvpn packets being seen on 
the the default gw. I read about how it works once and could understand it for 
about 10mins and then I forgot it. I don't know if the openvpn routing method 
helps you.)

Since nfsd listens on all ports by default, you need some skullduggery.

I googled for "listen address nfsd" and only came up with

https://unix.stackexchange.com/questions/210772/nfs-share-with-custom-interface

which suggests rpcbind. I looked at rpcbind to find it uses libwrap and 
hosts.deny and hosts.allow, so presumably it's a version of tcp wrappers for nfs 
and hence doesn't help with udp.

It's been a while now, but I think xinetd only allowed demons to listen on a 
particular IP.

It seems the simplest thing is to put the nfs servers somewhere that they're not 
visible to the internet.

Joe


> 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: Joseph Mack <jmack at wm7d.net>
> 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/jmack%40wm7d.net
> Welcome to TriLUG: https://trilug.org/welcome

-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant
map generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!