How to restrict NFS access from non-privileged ports?

[markus_kuhn]

We have a NetApp file server running Data ONTAP Release 7.2.7. It serves NFSv3 with sec=sys authentication to a large number of centrally administered Linux clients, where root is trusted but the normal users are not. Unfortunately, we have not found a way to configure our NetApp file server to restrict NFS RPC calls (to port 2049) such that they are only allowed if they come from a privileged source port (<1024). While many other NFS servers (e.g., the Linux one) support in /etc/exports an option

  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.

we could not find any equivalent in Data ONTAP Release 7.2.7. This is a critical security problem for us, because the absence of a source-port restriction allows normal users easily to bypass all NFS security of the NetApp filer. Two types of attack are possible:

a) via NFSv3: We are restricting the mount protocol to privileged source ports (NetApp option nfs.mount_rootonly). However, this is insufficient and insecure. The mount protocol only serves to tell the NFS client a valid file handle. Such file handles can alternatively easily be either observed on the wire (e.g., using WireShark), or they can be brute-force searched. Once any valid directory file handle is known (and they last a long time!), a suitable user-level NFSv3 client (e.g. http://www.watson.org/~robert/freebsd/nfssuite-0.1.tgz) can then be used easily by non-root users to access the filespace with an arbitrarily chosen uid/gid. 😞

b) via NFSv4: This is even easier. Because NFSv4 has no separate mount protocol, there is not even any need to guess or eavesdrop a filehandle and to use a special NFS client that can bypass the mount protocol when given a known hexadecimal filehandle. A normal non-root user can simply use ssh port-2049 forwarding from an untrusted machine under their control to a trusted machine in order to get full access to the NetApp filespace, by mounting via ssh from their own machine (where they are root). :-((

Question: Did we miss anything in the documentation or is there really no way to restrict the whole NFS protocol (except for NULL requests, see RFC2623 section 2.3.1), and not just the mount protocol, to privileged source ports? This seems to pose a very serious security problem for any installation that still has to rely on sec=sys for the foreseeable future!

Feature request: Could you please consider adding to the /etc/exports syntax something equivalent to the "secure" option (see "man exports" on Linux).

Thanks,

Dr Markus Kuhn

Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/

[adamfox]

There probably isn't an option for you assuming you are using sec=sys if you are demanding security from people snooping your wire.  Although that typically means they already have root on host that currently is NFS mounting or access to your switches or storage which is bad.

The answer most NFS people will give you is that if you really need that level of security, you should be running Kerberos.

I can see coming from a University setting where this issue is more accute.  Most corporate customers use private networks for critical servers, thus the traffic never hits the intranet, or they have use policies in place that say if you do this, you are fired, which tends to work really well but probably doesn't have the same effect on students whose immediate livelyhood doesn't depends on the institute.

You are welcome to open a case and have an RFE filed in the mean time.

[markus_kuhn]

Thanks for confirming that there is currently no way to block NFS RPC calls from non-root ports.

I have now filed a corresponding feature request as case #2001516991: http://now.netapp.com/eservice/case/caseView.jsp?caseId=2001516991

Switching entirely to Kerberos is not an option for us, and is unlikely to become so in the future. We operate a number of servers to which members of our department can login from the outside world. These servers do not support traditional password login: a very successful security measure that has dramatically reduced the keyboard-sniffer based intrusions into our department and that we do not intend to relax. Our external login servers can only be accessed via either ssh public-key authentication, or using a one-time password system (otpw). Both these login methods do not result in a Kerberos ticket, and for fear of keyboard sniffers, we actually discourage people from using "kinit" to acquire a ticket manually after login when they are away. These remote login servers are connected to the NetApp fileserver via a physically secure VLAN and therefore our router can ensure that their source IP address is very strong evidence that any NFS requests from them do indeed come from a centrally administered server on which only root can access ports below 1024. Therefore, in this setup, adding Kerberos would not add any security. In fact, Kerberos would reduce security here by exposing its many-time password to keyboard sniffers in doggy Internet cafes, etc. AUTH_SYS is still the most practical and most secure form of NFS authentication in such applications! (Another example are centrally administered servers for executing cron jobs. Again, sec=sys is far more practical and at least as secure there as Kerberos here.)

Therefore, it is very important to us to have proper sec=sys security, by being able to restrict such access to privileged port numbers. With out this, our users can run user-mode (non-root) NFS clients on the remote login machines and impersonate everyone to the NFS server.