We recently replaced our F820c pair running 6.4.4 with a FAS3050c pair running 7.0.1R1.
Formerly we were doing something admittedly questionable to protect unauthorized NFS mounts from networks where we do not have complete physical control. We have a public lab of Unix workstations that NFS mount home directories from our filers. This is insecure because someone can bring in a Unix laptop configured with the same IP address as a workstation and move the network cable from the workstation to the laptop, and thereby get NFS access on the laptop. The laptop owner has root so he can su to any UID that he wants, thereby getting access to any user's files.
Our solution was to write a "netgroup server" that temporarily added a NFS client to a netgroup just long enough for the client to mount and then removed the client from the netgroup. Only root on the NFS client had access to the shared secret that authenticated the client to the netgroup server. While not perfect, this made the laptop attack much more difficult.
This worked fine under 6.4.4. Once the NFS client had its mounts, it did not seem to matter to the filer that the client disappeared from the netgroup. However, this is not the case under 7.0.1R1. We have found that certain NFS operations cause the filer to recheck the netgroup information and when it discovers that the client is no longer in the netgroup, it denies further access.
I realize that we need to be looking at a "real" solution (NFSv4 ? NFS over IPsec ?). But I was wondering if there was something simple that I could do in the meantime, perhaps an obscure NFS option on the filer.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Steve,
The best thing you can do is set the timeout values as high as you can:
nfs.export.harvest.timeout nfs.export.neg.timeout nfs.export.pos.timeout
Look at the options man page.
The effect of this is that once the mount occurs, you can bypass checks for up to the maxes as discussed in the man pages.
Of course, if the filer reboots or if the client reboots, you will loose either the cache on the filer or the file handle on the client.
I know Solaris will use kerberos over NFSv3 and that the CITI guys have had good luck at getting NFSv3 to work well over Linux. Okay, so it is actually Chuck Lever, who works for us out at CITI, who has it working. ;>
But other than that, the new security model is designed to stop what you are doing.
Enjoy, Tom
On Sun, Sep 04, 2005 at 10:02:55AM -0400, Steve Losen wrote:
We recently replaced our F820c pair running 6.4.4 with a FAS3050c pair running 7.0.1R1.
Formerly we were doing something admittedly questionable to protect unauthorized NFS mounts from networks where we do not have complete physical control. We have a public lab of Unix workstations that NFS mount home directories from our filers. This is insecure because someone can bring in a Unix laptop configured with the same IP address as a workstation and move the network cable from the workstation to the laptop, and thereby get NFS access on the laptop. The laptop owner has root so he can su to any UID that he wants, thereby getting access to any user's files.
Our solution was to write a "netgroup server" that temporarily added a NFS client to a netgroup just long enough for the client to mount and then removed the client from the netgroup. Only root on the NFS client had access to the shared secret that authenticated the client to the netgroup server. While not perfect, this made the laptop attack much more difficult.
This worked fine under 6.4.4. Once the NFS client had its mounts, it did not seem to matter to the filer that the client disappeared from the netgroup. However, this is not the case under 7.0.1R1. We have found that certain NFS operations cause the filer to recheck the netgroup information and when it discovers that the client is no longer in the netgroup, it denies further access.
I realize that we need to be looking at a "real" solution (NFSv4 ? NFS over IPsec ?). But I was wondering if there was something simple that I could do in the meantime, perhaps an obscure NFS option on the filer.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
We have the same problems with public Unix labs with physically insecure network connections, and are now using IPsec. We tried using kerberos, but we were unable to get our OS X NFS clients to use kerberized NFS. It took a good chunk of time to read the documentation and get IPsec working (and decipher how the different vendors define the same terms differently), but I'm glad we did it. When you're ready to take the plunge, let me know and I'll see if I can dig up my notes on it.
Re:
Date: Sun, 4 Sep 2005 20:29:22 -0700 From: Tom Haynes thomas@netapp.com To: Steve Losen scl@sasha.acc.virginia.edu Cc: toasters@mathworks.com Subject: Re: NFS access problem going from 6.4.4 to 7.0.1R1
Steve,
The best thing you can do is set the timeout values as high as you can:
nfs.export.harvest.timeout nfs.export.neg.timeout nfs.export.pos.timeout
Look at the options man page.
The effect of this is that once the mount occurs, you can bypass checks for up to the maxes as discussed in the man pages.
Of course, if the filer reboots or if the client reboots, you will loose either the cache on the filer or the file handle on the client.
I know Solaris will use kerberos over NFSv3 and that the CITI guys have had good luck at getting NFSv3 to work well over Linux. Okay, so it is actually Chuck Lever, who works for us out at CITI, who has it working. ;>
But other than that, the new security model is designed to stop what you are doing.
Enjoy, Tom
On Sun, Sep 04, 2005 at 10:02:55AM -0400, Steve Losen wrote:
We recently replaced our F820c pair running 6.4.4 with a FAS3050c pair running 7.0.1R1.
Formerly we were doing something admittedly questionable to protect unauthorized NFS mounts from networks where we do not have complete physical control. We have a public lab of Unix workstations that NFS mount home directories from our filers. This is insecure because someone can bring in a Unix laptop configured with the same IP address as a workstation and move the network cable from the workstation to the laptop, and thereby get NFS access on the laptop. The laptop owner has root so he can su to any UID that he wants, thereby getting access to any user's files.
Our solution was to write a "netgroup server" that temporarily added a NFS client to a netgroup just long enough for the client to mount and then removed the client from the netgroup. Only root on the NFS client had access to the shared secret that authenticated the client to the netgroup server. While not perfect, this made the laptop attack much more difficult.
This worked fine under 6.4.4. Once the NFS client had its mounts, it did not seem to matter to the filer that the client disappeared from the netgroup. However, this is not the case under 7.0.1R1. We have found that certain NFS operations cause the filer to recheck the netgroup information and when it discovers that the client is no longer in the netgroup, it denies further access.
I realize that we need to be looking at a "real" solution (NFSv4 ? NFS over IPsec ?). But I was wondering if there was something simple that I could do in the meantime, perhaps an obscure NFS option on the filer.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-- Tom Haynes, ex-cfb thomas@netapp.com
-
Brian Parent -
Steve Losen -
Tom Haynes