"Yoder, Alan" wrote:
Right, of course if you misconfig something you open yourself to mischief. What I want to get at is whether it is safe to have a filer attached to the net-at-large, or whether it needs to be firewalled or otherwise protected. Can you elaborate on the nfs insecurities you mention?
A number of NFS systems and tools send passwords in plain text, and the filer is not an exception. Use a firewall or switched Ethernet.
That bites
What kind of real-world bandwidth can it put out (F740) ? I see the transaction specs, but what about sustained mbits in a web-type environment (3x more reads than writes)?
Netapp prefers to measure "response time" vs. "transactions/sec". In other words, a filer might be showing tremendous throughput for one party, while starving out the others (delayed responses). In the real world, you want average response time to be as fast as possible because that is what people notice. Netapp has very impressive throughput and average response time does not degrade dramatically at high loads.
Excellent, but is the filer capable of overloading 100mbit ethernet? If so, just how much bandwidth should we spec out for it so that it can perform to its max abilities?
As I remember it, the 740 can saturate at least two 100Mb Ethernet links. In house, we have our main filers connected via gigabit uplinks to a backbone, which gets switched down to 100Mb LANs from there.
Keep in mind, you need a lot of clients to saturate the filer. It takes around 50 200MHz PC clients running NetBench to max it out. A web server with a filer back end won't even make it sweat, and one 100Mb Ethernet card might be enough. What kind of uplink to the world will the web server have?
The whole system will be colocated at a facility with multiple OC-3/DS3/T1 links. Same place amazon.com is located at... It will only have about 10 300mhz PII client boxes at first, so this is sounding good. I think we may go with the Cisco FEC multiple 100mbit links instead of gigabit in order to provide some link redundancy.
Right, of course if you misconfig something you open yourself to mischief. What I want to get at is whether it is safe to have a filer attached to the net-at-large, or whether it needs to be firewalled or otherwise protected. Can you elaborate on the nfs insecurities you mention?
A number of NFS systems and tools send passwords in plain text, and the filer is not an exception. Use a firewall or switched Ethernet.
That bites
Actually, the only NFS service that involves passwords is PCNFSD.
However, NFS *itself* tends to use what's called "UNIX authentication", which means an NFS request goes over the wire with what purports to be the user ID, group ID, and group set of the user making the request.
The server is not in a position to find out whether the request is *really* coming from that set of IDs. Most NFS servers will trust anything other than a user ID of 0 (by default, they map a user ID of 0 to a user "nobody", but can be configured not to do that).
Thus, if a user on a given NFS client can, say, become "root" on that client machine, and can then become some *other* user using e.g. "su", they can read or write any file readable or writable by that other user.
NetApp filers don't support any of the stricter forms of authentication used by some NFS clients and servers, which may be able to protect against that. (I'm not sure what vulnerabilities have been found in, say, DES or Kerberos authentication, or in the Kerberos flavor of GSSAPI authentication.)
Guy Harris wrote:
Right, of course if you misconfig something you open yourself to mischief. What I want to get at is whether it is safe to have a filer attached to the net-at-large, or whether it needs to be firewalled or otherwise protected. Can you elaborate on the nfs insecurities you mention?
A number of NFS systems and tools send passwords in plain text, and the filer is not an exception. Use a firewall or switched Ethernet.
That bites
Actually, the only NFS service that involves passwords is PCNFSD.
However, NFS *itself* tends to use what's called "UNIX authentication", which means an NFS request goes over the wire with what purports to be the user ID, group ID, and group set of the user making the request.
The server is not in a position to find out whether the request is *really* coming from that set of IDs. Most NFS servers will trust anything other than a user ID of 0 (by default, they map a user ID of 0 to a user "nobody", but can be configured not to do that).
Thus, if a user on a given NFS client can, say, become "root" on that client machine, and can then become some *other* user using e.g. "su", they can read or write any file readable or writable by that other user.
NetApp filers don't support any of the stricter forms of authentication used by some NFS clients and servers, which may be able to protect against that. (I'm not sure what vulnerabilities have been found in, say, DES or Kerberos authentication, or in the Kerberos flavor of GSSAPI authentication.)
This does not make a lot of sense to me.. I mean, if some user on the client has hacked root, then game over man. Who cares past that. Of course they can su to some user and mess with their files, root can do just about anything.
What I want and need to know when designing our nfs system is whether a normal non-root user, _without hacking root_, can do any shenanigans via or to nfs. Basically, is adding properly configured nfs to an already secure system going to be ok or not ok, and if not ok what can be done about it?
This does not make a lot of sense to me.. I mean, if some user on the client has hacked root, then game over man.
I think the concern is for sites where you don't *have* to hack root - e.g., a network where users are given root privileges on their own workstation. One might not want those users to have *arbitrary* privileges, e.g. the ability to read other peoples' files, just because they have sufficient privileges to configure and administer the machines on their desktops.
-
Brian Atkins -
guy＠netapp.com