Thanks Mark.
We do have CIFS. However, we have >30,000 accounts, and >300 NFS clients. And besides, any account is allowed access from any NFS client. Plus, it doesn't solve the problem of spoofing IPs.
We don't have MultiStore, but even if we did, I don't see how it solves the problem of spoofing IPs.
Spoofing IPs is painfully simple here, (as at most Universities, I would think) where labs aren't supervised, and network jacks are not physically secured.
Re:
Subject: RE: IPsec NFS to Unix clients Date: Fri, 20 Aug 2004 13:31:42 -0700 From: "Muhlestein, Mark" mark.muhlestein@netapp.com To: "Steve Losen" scl@sasha.acc.virginia.edu, "Brian Parent" bparent@calvin.ucsd.edu Cc: toasters@mathworks.com
Here are a couple of other things you can do to improve NFS security:
- If you have CIFS you might consider using the
nfs.require_valid_mapped_uid option. That allows you to set up the usermap.cfg file to do things like this:
# allow the following UIDs NFS access from the specified IP addresses tom <= 192.168.3.34:tom jerry <= jerrypc.dorm.foo.edu:jerry jerry <= lab1.foo.edu:jerry jerry <= lab2.foo.edu:jerry # etc.
# allow root from the admin network Administrator <= 10.10.20.0/24:root
# prevent all other NFS access "" <= *
The nfs.require_valid_mapped_uid option causes the usermap.cfg entries to be consulted even for access to data on qtrees with UNIX security. Combined with the normal export controls, this approach works as long as clients are not allowed to successfully spoof source IP addresses. It is also more manageable if the number of combinations of users/hosts is not overly large or dynamic; however I know we have had sites that have used this type of approach with a script-generated usermap.cfg.
- If you have MultiStore available you can also use that to fence off
NFS access. NFS clients accessing an IP address associated with a vfiler are not allowed to access storage assigned to another vfiler. This is enforced at the WAFL layer, so even if clients attempt handle spoofing the access is denied as long as the potentially rogue clients are not allowed to access the other vfilers' IP addresses (e.g. different networks on separate NICs).
Mark
-----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Friday, August 20, 2004 7:08 AM To: Brian Parent Cc: toasters@mathworks.com Subject: Re: IPsec NFS to Unix clients
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