cookie_monster Posted July 21, 2009 Posted July 21, 2009 I've had a bit of a read on NFS and there seems to be an inherent issue with security in that there is none. Do you need to protect NFS shares using VLANs? As far as I can tell I just put an IP address into Xen and it adds it, it doesn't ask for a password or anything. Am I missing some settings? NFS Security - The Community's Center for Security 1
pete Posted July 21, 2009 Posted July 21, 2009 In short, yes VLAN it. Great performance, crap security. 2
Duke Posted July 22, 2009 Posted July 22, 2009 I asked about this a few times too and wondered if I was just missing something... That's more than a little worrying, I personally wouldn't consider VLANs a security tool (more a traffic management tool) and I would definitely want some kind of access control on the actual file host, especially if it's storing the data of all my servers! [ame=http://en.wikipedia.org/wiki/VLAN_hopping]VLAN hopping[/ame] I know iSCSI security isn't exactly perfect, but with initiator access lists and forward/reverse CHAP I'd be a lot happier... Chris
Ric_ Posted July 22, 2009 Posted July 22, 2009 @Duke: Rather than a VLAN, use a separate switch - far more secure than ACLs on iSCSI
pete Posted July 22, 2009 Posted July 22, 2009 I've got mine set up like so: In order to connect to NFS you have to have a NIC plugged into the storage switch and even on that switch, NFS-connected ports are on a separate vlan. The storage network uses a different IP range to make things easier under Xen - that's mainly for my sanity. The green line going from the 7110 to the main switch is for ntp and sending reports back to Sun - there's no storage available on that interface. Of course, that doesn't stop someone plugging the wrong cable into the storage switch, but it'd need to be a fairly long cable (by design - it's hard to screw it up) and I have a cluebat for that. 1
Duke Posted July 22, 2009 Posted July 22, 2009 @Duke: Rather than a VLAN, use a separate switch - far more secure than ACLs on iSCSI Yeah, that crossed my mind too. If we're doing things properly here next summer then all iSCSI/NFS traffic will be completely physically separate from the rest of the network. I'm not sure if this has been asked before (judging from Pete's reply it can be done), but is it possible to lock down an iSCSI LUN or CIFS/NFS share to a particular port on the S7000? Or do it the other way around and stop a particular port accessing them? If not, then what's to stop someone using the 'curriculum network' port to access 'iSCSI/NFS data' network port? Even if they're on different IP ranges they're both still getting data from the SAN... Cheers, Chris
cookie_monster Posted July 22, 2009 Author Posted July 22, 2009 (edited) The green line going from the 7110 to the main switch is for ntp and sending reports back to Sun So is that card on the production network then, if so how do you stop people connecting over that card to your NFS share? I have three cards on the 7110 on a seperate VLAN and IP range that I can connect to an NFS share over, the problem is that I also have one card on the production network for management and connecting to Sun like you but I can can't see a way to prevent an NFS connection on that card as well. Currently to connect to an iSCSI LUN someone would have to find the right IP range, join the VLAN then brute force the iSCSI CHAP password. Then they have the problem that unlike NFS a LUN can't be shared so they still couldn't connect as the Xenserver would have it locked. http://searchstorage.techtarget.com/tip/0,289483,sid5_gci1176417_mem1,00.html Edited July 22, 2009 by cookie_monster
pete Posted July 22, 2009 Posted July 22, 2009 (edited) So is that card on the production network then, if so how do you stop people connecting over that card to your NFS share? The card is on the production network in a 3 port vlan (dns server, itself, proxy server). My NFS shares are default deny and I filter* the switchports it connects to. It would be great if we could say "disallow access to NFS on $interface01", but iirc you can't do that in OpenSolaris without firewalling on the box and that's suboptimal on a file storage device. My problem is I need an accurate source of time for a) domain time b) storage & switches. Either needs to be accessible without the other. I could buy a GPS time source and use that, but I still would like the 7110 to have phone-home functionality. *NFS, smb and iscsi traffic is blocked. Edited July 22, 2009 by pete
Ric_ Posted July 22, 2009 Posted July 22, 2009 *NFS, smb and iscsi traffic is blocked. What are you using for this?
pete Posted July 22, 2009 Posted July 22, 2009 One of the switches allows me to filter based on tcp/udp ports and protocols. If it was a high traffic port it would be terribly sub-optimal, but since it consists of the occasional "what's the time" and "hello, I'm ok/not ok" from one host it's not really a problem. Another solution would be a (physical) $firewall_distro_of_choice box sat between production network and the 7110 - only allow in or outbound stuff that you want. An itx/atom/alix board running m0n0wall from CF would do fine and use minimal power.
cookie_monster Posted July 24, 2009 Author Posted July 24, 2009 One of the switches allows me to filter based on tcp/udp ports and protocols. If it was a high traffic port it would be terribly sub-optimal So if you wanted to use that NIC to offer a high traffic CIFS share then you couldn't use that system right? So you would then have the same issue with your NFS share.
pete Posted July 24, 2009 Posted July 24, 2009 So if you wanted to use that NIC to offer a high traffic CIFS share then you couldn't use that system right? So you would then have the same issue with your NFS share. Yeah, it'd cause unacceptable slowdown on the switch and cifs performance would be affected. To work around the problem I'd probably connect that interface back to the storage switch and place the firewall between the storage and the backbone switch. Then I'd connect another (physical) server to the storage switch, mount storage via iSCSI and share it using cifs from that server. Unless there's a better way of protecting NFS shares that the Cutter people and Phil know about?
cookie_monster Posted July 24, 2009 Author Posted July 24, 2009 What would be nice would be a way to specify what NICs NFS could be shared over, so you would say these cards on 192.168 can share NFS but NFS cannot be seen on the public card.
apaton Posted July 27, 2009 Posted July 27, 2009 I may have lost the track of this thread , but NFS does have security. I will agree its not 100% robust but if you trust IP address and user authentication/mapping (LDAP/NIS/Local users) then your OK. What would be nice would be a way to specify what NICs NFS could be shared over, so you would say these cards on 192.168 can share NFS but NFS cannot be seen on the public card. With the 7110 storage you get close to this. You can restrict which hosts and/or networks can access the a NFS share, then your down to user permissions/ACL's for fine grain file access. I've used this method for XenSever and ESX, this leaves the PUBLIC network open to CIFS and iSCSI only, as already discussed in this thread.
cookie_monster Posted July 27, 2009 Author Posted July 27, 2009 You can restrict which hosts and/or networks can access the a NFS share But could someone still spoof an IP and connect if so it's still limited security for what could be sensitive data?
apaton Posted July 27, 2009 Posted July 27, 2009 But could someone still spoof an IP and connect if so it's still limited security for what could be sensitive data? I agree, thus I said its "not 100% robust but if you trust IP address....". A dedicated network/VLAN for NFS traffic will help slightly. I'm sure this is more than enough security for most environments.
cookie_monster Posted July 27, 2009 Author Posted July 27, 2009 Ok, I just like to have a full understanding of the security implications of any setup I have running. Thanks.
Duke Posted July 27, 2009 Posted July 27, 2009 I will agree its not 100% robust but if you trust IP address and user authentication/mapping (LDAP/NIS/Local users) then your OK. With the 7110 storage you get close to this. You can restrict which hosts and/or networks can access the a NFS share, then your down to user permissions/ACL's for fine grain file access. I've used this method for XenSever and ESX, this leaves the PUBLIC network open to CIFS and iSCSI only, as already discussed in this thread. I thought this was possible too, and at the end of the day this is no worse than the security you have on a Windows server share. However, my question then is what permissions need to be set to allow an ESX host to access an NFS share? In other words, which account do I need to grant access to, is it something like [email protected], and if so how does the S7000 validate that account? Does the NFS Exceptions security just work along the same principles as iSCSI initiator security, in that you allow/deny certain hosts (in this case hostnames rather than initiator names)? Cheers, Chris
apaton Posted July 29, 2009 Posted July 29, 2009 (edited) my question then is what permissions need to be set to allow an ESX host to access an NFS share? In other words, which account do I need to grant access to, is it something like [email protected], and if so how does the S7000 validate that account? Does the NFS Exceptions security just work along the same principles as iSCSI initiator security, in that you allow/deny certain hosts (in this case hostnames rather than initiator names)? Cheers, Chris ESX mount NFS volumes as the "root" user (UID 0). It term's of NFS "root" is automatically demoted to user "nobody" for security reasons. So on the S7000 you can do two things 1) Create a share with access control of "nobody" and "other" 2) Under NFS Exceptions select "ROOT ACCESS" check box for specific host Andy Edited July 29, 2009 by apaton spelling mistake 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now