On Sun, Apr 23, 2006 at 10:11:33PM -0400, J. Milgram wrote: > Just curious - NFS used to have a bad rep for security. How is it these > days? Depends on the security mode the file system is exported with. Traditionally, the security is based on the packet's source port being from the priviledged range (i.e., <1024) and the ip address matching something in the export file, which is of course crap. There are random nonces in the session that must be repeated, so it's in theory hard to mount a "blind" forged packet attack (where the attacker is not in the path between the forged client and the server), but if you root on a client and the server has any sort of write access exported, you can still do some damage.
Modern nfs implementations (read: not linux) can do Kerberose authentication, which aleaviates this. > Assuming I have Box A exposed to the Internet, talking to an internal > LAN via a separate interface, can I export volumes to the internal LAN > without fear of outside folks being able to mount them? (assuming they > don't get root on my box, of course). And assuming all the right things > are done with access control. Assuming I understand you correctly, this is totally a firewalling/routing issue, not nfs. If the bad guys can't get packets onto your internal network, they can't compromise nfs on your internal network. Now, it can be hard to get all of the nfs daemons to go to known ports so you can firewall them. By default they bind a random port and register with portmapper. Most linux implementations of rpc.nfsd take a '-p port' option so that you can force nfs to a known port so you can firewall it off (which is what I do at home). - Rob .
