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(a)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(a)netapp.com>
> To: "Steve Losen" <scl(a)sasha.acc.virginia.edu>,
> "Brian Parent" <bparent(a)calvin.ucsd.edu>
> Cc: <toasters(a)mathworks.com>
>
> Here are a couple of other things you can do to improve NFS security:
>
> 1. 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.
>
> 2. 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