Securing NFS against SSH tunneling

I was idly reading http://nfs.sourceforge.net/nfs-howto/ar01s06.html trying to understand why localhost exports were bad when I got to the section "6.4. Tunneling NFS Through SSH". Everything in that section about it being a possible security vulnerability to export localhost because it allows others to ssh port forward in and access the share made sense.

Here's my question, how does one keep ssh tunnels from undermining the security of a system if users can ssh in to a machine that can connect to an NFS server? For instance imagine computers A(192.168.1.1), B(192.168.1.2) and C(192.168.1.3). Let A be the server with the following export file:

/home 192.168.1.2(rw)

As you can see A is giving B permission to use the /home share. Now, let C ssh into B with:

$ ssh 192.168.1.2 -L 250:192.168.1.1:2049  -f sleep 60m
$ ssh 192.168.1.2 -L 251:192.168.1.1:32767 -f sleep 60m

It would seem that A's shares exported to B are vulnerable to anyone that can ssh into B. Is this the case? Is there a way to protect against this other than simply making sure anyone that can log into B is a very trusted user?

Solution 1:

That's a very old document your looking at it talks about kernel version 2.4 which came out in 2001, a lot have changes have happened in the last 12 years. Although some things remain the same.

I only have CentOS 6.x boxes to play with which uses nfsv4 by default. To allow the connection via an intermediate machine I had to export the filesystem with insecure set.

So to answer your question use nfsv4 and use the default secure mode. If you have sufficient privilege on B you can also set

AllowTcpForwarding no

in it's /etc/ssh/sshd_config.

As ever though with security if you give people privilege, you have to trust them.

Solution 2:

The issue you're highlighting is not a flaw, it's a feature! Yes it's a feature of the SSH protocol and giving that improperly configured SSH service can be used for a wide range of exploits like:

• Bypassing host firewalls
• Bypassing IP restrictions
• Remotely accessing services which listens only on 'localhost' interfaces [mysql?]

As an example of common misconfiguration and security issue, setting the /sbin/nologin shell to a user, does not prevent it from spawning ssh tunnels with most default configurations for the OpenSSH daemon!

As per your question, you should avoid NFSv2/NFSv3 and go with the more secure NFSv4, which shifts toward different security model, where it authenticates single users instead of the host machines. Or as an alternative, forbid SSH tunneling for ordinary users by properly configuring the OpenSSH service.

Solution 3:

That document is rather old (2006!). In the absence of better security mechanisms (i.e. NFSv4 + GSS) adding a host to exports means you implicitly trust that host, its users and processes.

SSH port-forwarding isn't your only problem, you can disallow it (sshd's AllowTcpForwarding no), but as sshd_config(5) says

Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

So add to the list socat, netcat, SOCKS (OpenSSH supports that too, though only TCP), OpenSSH tun tunneling support, and even bash with its /dev/tcp support and you can see the problem... too many to list.

If B has host firewalling that permits per-user rules (i.e. Linux /iptables with --uid-owner) you might be able to lock B down so that A can trust it more. Otherwise try NFSv4 with GSS and Kerberos, that gives you per-user trust.

Solution 4:

This is easily defeated by

1. making sure your exports are marked secure
2. not allowing root access to computer B by computer C

The man page for exports(5) says:

secure
This option requires that requests originate on an internet port
less than IPPORT_RESERVED (1024). This option is on by default. 
To turn it off, specify insecure.

Note that this is on by default.

Any user connecting from computer C to computer B will be connecting as an ordinary user. The NFS connections forwarded through SSH as you described look like the originate from a process running on B as that user. This means that connection is subject to the usual security controls on B, in particular that normal users can't originate connections from ports lower than 1024.

Tested on one of my systems, I see the following:

djs@tuonela:~$ sudo mount -o port=250,mountport=251,tcp localhost:/srv/users /mnt/x -t nfs
mount.nfs: access denied by server while mounting localhost:/srv/users

Of course, anyone who can elevate their account to root on computer B can defeat this protection, so you need to lock down NFS client computers sufficiently.