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
I just realized that the preshared keys for IPsec on a NetApp (as outlined in man na_psk.txt) are ascii, and on Solaris, (man ipseckey) they're in hex. Now, if I knew how NetApp's IPsec implementation translated their ascii string into bits, I could get the right corresponding hex representation to use on the Solaris client.
Anyone have any ideas?
I tried a simple a=0x61, b=0x62, so that abcd becomes 61626364, but that didn't work. I also tried swapping bytes so that abcd becomes 62616463, no luck there either. Of course it could be little endian vs. big endian, or swap words instead of bytes, or some combination of the above, or ...
I've finally got IPsec working between Data OnTap 6.4.5 and Solaris 10 systems! I can finally feel more comfortable running NFS to clients in public labs with accessable network jacks. It also works with RHEL, and OS X.
It turns out that a simple ascii to hex translation does work. (For Linux and MacOS X, just use the same ascii as the psk.txt file.) My problem was that I was trying to use Solaris 8, which doesn't have IKE support. The NetApp IPsec docs don't make it clear that IKE is required, and I was confusing manually keyed SAs with shared keys for IKE. IKE is used to generate keys to be used with the SAs (Security Associations). Manually keyed SAs don't use IKE at all, and apparently aren't supported in Data OnTap 6.4.5, (and are less secure without some means for regular and frequent replacement).
I ran some basic timing tests from
http://www.connectathon.org/nfstests.html
both with and without IPsec (just ah (Athentication Headers), not esp (Encapsulation Security Payload)), and the performance hit seems minimal. I have yet to run tests on more than a single system at a time. I'm guessing we'll want to purchase the accelerator card, but haven't researched the pricing yet.
I haven't yet figured out exactly which combinations of the various policy specifications don't work, but here's what we used that works: Loosely based on the directions at:
http://docs.sun.com/app/docs/doc/816-4554/6maoq0219?a=view
Filer host: filer.ucsd.edu 192.168.13.100 NFS client host: Sol10-nfs-client.ucsd.edu 192.168.13.200
Files on Sol10-nfs-client.ucsd.edu:
/etc/inet/ipsecinit.conf:
{laddr 192.168.13.200 raddr 192.168.13.100} ipsec {auth_algs md5 sa shared}
/etc/inet/ike/config:
...perhaps other preceding stuff... { label "sol10nfsclient-filer" local_addr 192.168.13.200 remote_addr 192.168.13.100 p1_xform { auth_method preshared oakley_group 1 auth_alg md5 encr_alg des } p2_pfs 2 }
We're suspicious that the oakley_group needs to be '1', and that the p2_pfs number must be '2', or the filer won't be happy. It *may* even be the case that using different numbers will crash your filer. Perhaps related to:
Bug Number/Title: 85483 / SA delete all and subsequent reconnect from BSD client can panic filer
In our case, the filer crashed when a Linux client tried to set up an SA with a filer, and the Linux client was using oakley_group 5, (1536-bit) and a p2_pfs number of 5 (1536-bit).
/etc/inet/secret/ike.preshared:
... { localidtype IP localid 192.168.13.200 remoteidtype IP remoteid 192.168.13.100 key 6162636465666768696a6b6c6d6e6f70 }
Files on filer.ucsd.edu:
/etc/psk.txt:
192.168.13.100 abcdefghijklmnop
Now for some hopefully basic questions:
What is the limit on the number of entries in the psk.txt file? Are comments allowed in psk.tst file? What format are they?
Re:
From: Brian Parent bparent@calvin.ucsd.edu Date: Tue, 24 Aug 2004 14:35:56 -0700 Subject: Re: IPsec NFS to Unix clients To: toasters@mathworks.com
I just realized that the preshared keys for IPsec on a NetApp (as outlined in man na_psk.txt) are ascii, and on Solaris, (man ipseckey) they're in hex. Now, if I knew how NetApp's IPsec implementation translated their ascii string into bits, I could get the right corresponding hex representation to use on the Solaris client.
Anyone have any ideas?
I tried a simple a=0x61, b=0x62, so that abcd becomes 61626364, but that didn't work. I also tried swapping bytes so that abcd becomes 62616463, no luck there either. Of course it could be little endian vs. big endian, or swap words instead of bytes, or some combination of the above, or ...
-
Brian Parent -
Muhlestein, Mark