Has anyone else come up with some alternate means by which to secure NFS exported data, where the server is a NetApp filer? (For years I've been losing the battle to get the physical network secure, using locking wall jacks in our public access labs.) I've been using NetApp file servers since 1995, and have been generally happy, but this security problem is making me seriously reconsider.

We came up with a pretty ugly hack to prevent folks from installing impostor NFS clients on a physically insecure network, such as in a student Unix lab. We were aware of the risk, but were finally motivated to do something when some little bastard (ahem, student) replaced a lab machine with his Linux laptop, so he was able to NFS mount the home directories, and because he had root on his laptop, he could su to any user and have read/write access to their home directory.

So here is what we did. We export to a netgroup. We discovered that once a NFS client has an NFS mount, it doesn't matter if you remove the NFS client from the netgroup map. NFS keeps working fine.

So we removed all the lab machines from the netgroup. We wrote a little client/server application in perl that temporarily puts the NFS client in the netgroup. The NFS client connects to the NIS master and identifies itself with a "secret handshake" The NIS master adds the NFS client to the netgroup map and the NFS client mounts the home directory volume. Then the NIS master removes the NFS client from the netgroup map. The NIS master has a list of machines that are allowed to be added to the netgroup.

This prevents the attack we experienced. Physical access to the network is not enough any more. You also need to know the "secret handshake" to get added to the netgroup map, and only root has access to that file. (If someone gets root on a lab machine, then they don't need an impostor machine.)

This is certainly far from perfect. There is no protection against a man in the middle attack. I suppose someone could put a Linux box with two ethernet interfaces between the lab machine and the ethernet switch. The Linux box could be programmed to pass through network packets, except that it would intercept NFS packets and modify them. Perhaps the uid field could be changed. That way the hacker could make NFS requests as himself on the lab machine, but his Linux box would change the uid field to another user. Does NFS have any protection against this sort of tampering? IPsec would prevent this, of course.

There is also a brief window of vulnerability while the lab machine is in the netgroup. Perhaps with some determined trial and error a hacker could quickly slip in an impostor machine and mount the volume during this window. But he would need to power cycle the lab machine to make it boot and he would need to slip in the impostor at just the moment that the lab machine was in the netgroup. Not easy, but certainly possible.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support