Linux – mount using insecure ports for nfs

The most likely reason you are having problems with non-root mounts is the "secure" export option, which is on by default. It disallows mount requests that come in with a source port greater than 1024. On most systems, binding to a port less than 1024 requires root access, so this is a fairly decent way of ensuring the mount was made by root.

The issue, as explained in the README for my NfSpy penetration testing tool, is that the NFS protocol (versions 2, 3, and even 4, without proper configuration) completely trusts the user ID sent in requests from client machines. By limiting requests to only those made by root, you limit your trust to only users on the client machine who have root access. Without this setting (using "insecure" in your exports file), any user can claim to have any UID and access any file on the export.

The reason it is working on Linux is probably because /bin/mount is setuid root:

~$ ls -l /bin/mount
-rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount

Just a hunch, but check the permissions on the mount binary on your FreeBSD system. If it is setuid, then you still have a problem, and I don't know what it is. If not, then that would explain what's going on.

Good luck with this, but please consider the security implications of allowing any user on a system to access any file on your server. I recommend using NFS4 with GSS authentication mechanisms instead of the traditional AUTH_SYS flavor.

There are settings in sysctl that defines NFS port ranges available for connections.

sunrpc.max_resvport = 1023

sunrpc.min_resvport = 650

These settings define the highest and lowest ports to use for making RPC connections (NFS)

You can open these ports or define a different range depending on your system. You will get denies if it tries to use a port that is blocked either by a firewall or another service using that port.

Edit:

You can also increase / decrease this range. I have a server that had 460 NFS mounts defined in fstab and it would fail after 372 or so. And when I would manually mount one of the failed ones it would mount it but unmount one of the working mounts. I increased this range by 150 and they all mounted. This is not the best way to do it. automounter comes to mind but, it works.

To make the modification you will edit your /etc/sysctl.conf add a line like:

sunrpc.min_resvport = 900

To make the change permanent if you need to change them. Remember if you go above 1024 that those are "unprivileged" ports and normal system users will have access to them vs. - 1024.

Edit 2:

In your NFS mount command can you add the following.

proto=tcp - forces the mount to use TCP/IP

public - bypasses portmapper completely and contacts NFS server on port 2049 unless otherwise specified

So, mount nfs.test.com:/export /test

becomes

mount -o proto=tcp ,public nfs.test.com:/export /test

EDIT 3

OK - here we go!!! root@pressyrluck # ./nowhammies > /dev/please

This information was lifted copied swiped borrowed from Sourceforge NFS

Some of the daemons involved in sharing data via nfs are already bound to a port. portmap is always on port 111 tcp and udp. nfsd is always on port 2049 TCP and UDP (however, as of kernel 2.4.17, NFS over TCP is considered experimental and is not for use on production machines).

The other daemons, statd, mountd, lockd, and rquotad, will normally move around to the first available port they are informed of by the portmapper.

To force statd to bind to a particular port, use the -p portnum option. To force statd to respond on a particular port, additionally use the -o portnum option when starting it.

To force mountd to bind to a particular port use the -p portnum option.

For example, to have statd broadcast of port 32765 and listen on port 32766, and mountd listen on port 32767, you would type:

# statd -p 32765 -o 32766
# mountd -p 3276

lockd is started by the kernel when it is needed. Therefore you need to pass module options (if you have it built as a module) or kernel options to force lockd to listen and respond only on certain ports.

If you are using loadable modules and you would like to specify these options in your /etc/modules.conf file add a line like this to the file:

options lockd nlm_udpport=32768 nlm_tcpport=32768

For the sake of this discussion lets describe a network and setup a firewall to protect our nfs server. Our nfs server is 192.168.0.42 our client is 192.168.0.45 only. As in the example above, statd has been started so that it only binds to port 32765 for incoming requests and it must answer on port 32766. mountd is forced to bind to port 32767. lockd's module parameters have been set to bind to 32768. nfsd is, of course, on port 2049 and the portmapper is on port 111.

We are not using quotas.

iptables -A INPUT -f -j ACCEPT -s 192.168.0.45
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
iptables -A INPUT -s 0/0 -d 0/0 -p 6 -j DENY --syn --log-level 5
iptables -A INPUT -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5

The first line says to accept all packet fragments (except the first packet fragment which will be treated as a normal packet). In theory no packet will pass through until it is reassembled, and it won't be reassembled unless the first packet fragment is passed. Of course there are attacks that can be generated by overloading a machine with packet fragments. But NFS won't work correctly unless you let fragments through. See Section 7, “Troubleshooting” for details.

The other lines allow specific connections from any port on our client host to the specific ports we have made available on our server. This means that if, say, 192.158.0.46 attempts to contact the NFS server it will not be able to mount or see what mounts are available.

With the new port pinning capabilities it is obviously much easier to control what hosts are allowed to mount your NFS shares. It is worth mentioning that NFS is not an encrypted protocol and anyone on the same physical network could sniff the traffic and reassemble the information being passed back and forth.