Gee, 30,000 * 300 is not even 10 million entries! :-)
Yes, you are right that this isn't going to work in every case. But I wanted to mention it because it is useful in some situations.
As to the MultiStore comment I made, I was thinking of a case where you want to use the same physical filer to serve an unprotected network (such as your normal campus network, it sounds like) and also serve a trusted network (on a different NIC or VLAN, say). As long as there is no way to access a vfiler's IP address using a client on the untrusted network, the vfiler boundary checks will prevent all access from all protocols (including NFS handle spoofing) coming from those untrusted clients.
Mark
-----Original Message----- From: Brian Parent [mailto:bparent@calvin.ucsd.edu] Sent: Friday, August 20, 2004 2:41 PM To: toasters@mathworks.com Subject: Re: IPsec NFS to Unix clients
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