By Kurt Seifried Rev 0.1
Securing specific services - NFS (S07.C15)
NFS stands for Network File SYstem and is just that, it is a good way to distribute filesystems, read only and read/write, while maintaining a degree of security and control. NFS is primarily meant for use in a high bandwidth environment (ie a LAN) where security risks are not high, or the information being shared is not sensitive (ie a small trusted LAN behind a firewall exchanging CAD/CAM diagrams, or a large university lab using nfs to mount /usr/. If you need a high level of security, ie encrypted data between hosts, NFS is not the best choice. I personally use it at across my internal LAN (this machine has 2 interfacses, guess which one is heavily firewalled), to share file systems containing rpm's, this website, etc.
NFS has a few rudimentry security controls, the first one would be firewalling, using NFS across a large, slow public network like the Internet just isn't a good idea, so firewall off port 2049, UDP. Since NFS runs as a set of daemons, tcp_wrappers are of no use. The config file for NFS actually has quite a few directives, the bulk of which deal with user id and group id settings (map everyone to nobody, perhaps map all the engineering clients to 'engineer', etc, etc) but no real mechanisms for authentication (your client claims to be uid 0, this is why root's id is squashed by default to nobody). NFS read only exports are pretty safe, you only have to worry about the wrong pople getting a look at your info (if it is sensitive) and or creating a Denial of Service attack (say you have a directory world readable/etc for sharing kernel source, and some gomer starts sucking down data like crazy...). Writable exports are a whole other ball game, and should be used with extreme caution, since the only 'authentication' is based on IP, and UID (you to can run Linux and be UID 0). Bounce a client down with a DOS attack, grab their IP, mount the writeable share and go to town. You say "but they'd have to know the ip and UID", packet sniffing is not rocket science folks.
So, how do we go about securing NFS? The first is to firewall it, especially if the machine is multi-homed, with an interface connected to a publicly accessible network (the Internet, the secretaries computer, etc). If you plan to run NFS over a publicly accessible network it better be as read only, you will be far better off with a different product then NFS. The second and most interesting part is the /etc/exports file. This controls what you allow clients to do, and how they do it.
A sample exports file, actually mine. # # NFS mounts for various things # /nfs 10.0.0.1(ro,all_squash) /nfs 10.0.0.11(ro,all_squash) /nfs 10.0.0.201(ro,all_squash) /nfs 10.0.0.202(ro,all_squash) # # The export I use so that I can edit this HTML # from my main workstation. # /www 10.0.0.11(rw,no_root_squash) # # The export to my sisters machine so she can edit her # HTML, this and the preceding rule are the only really # 'unsafe' ones, assuming someone put a machine on our LAN, # they could probably execute a DOS attack, grab the IP, # and overwrite all our html files, possibly fill that # one HD up, etc. In other words not a problem =) # /www/helen.seifried.org 10.0.0.202(rw,no_root_squash) # # Why ftp when you can cd /sundog-ftp/ ? =) # /home/ftp 10.0.0.1(ro,all_squash) /home/ftp 10.0.0.11(ro,all_squash) /home/ftp 10.0.0.201(ro,all_squash) /home/ftp 10.0.0.202(ro,all_squash)
The structure of the exports file is pretty simple, directory you wish to export, client (always use ip's, hostnames can easily be faked), and any options. The client can be a single IP (10.0.0.1), hostname (gateway.seifried.org), a subnet (10.0.0.0/255.255.255.0), or a wildcard (*.seifried.org). Some of the more interesting (and useful) directives for the exports file are:
secure - the nfs session must originate from a priviliged port, ie root HAS to be the one trying to mount the dir. This is useful if the server you are exporting to is secured well. ro - a good one, Read Only, 'nough said. noaccess - used to cut off access, ie export /home/ but do a noaccess on /home/root root_squash - squashes root's UID to the anonymous user UID/GID (usually 'nobody'), very useful if you are exporting dirs to servers with admins you do not 100% trust (root can almost always read any file.... HINT) no_root_squash - useful if you want to go mucking about in exported dirs as root to fix things (like permissions on your www site) squash_uids and squash_gids - squash certain UID(s) or GID(s) to the anonymous user, in Redhat a good example would be 500-10000, allowing any users with lower UID's (ie special accounts) to access special things. all_squash - a good one, all priviliges are revoked basically and everyone is a guest. anonuid and anongid - specifically set the UID / GID of the anonymous user (you might want something special like 'anonnfs'). The man exports page is actually quite good.
Beyond this there isn't much you can do to secure NFS apart from ripping it out and putting some other product in (like AFS, coda, etc). NFS is good, everyone supports it, and is very very easy to setup, work with and maintain. It's also 'old faithful', been around a long time. Just checked the PUIS, they also state in bold not to use NFS if security is a real issue. go fig.
Securing SQUID | Back to Section 7
Contact Kurt Seifried, All rights reserved Kurt Seifried 1998, content and information may not be reposted physically or electronically without the express permission of the author, this includes but is not limited to www mirror sites, email, usenet news, etc.