6. Security and NFS

This list of security tips and explanations will not make your site completely secure. NOTHING will make your site completely secure. This may help you get an idea of the security problems with NFS. This is not a comprehensive guide and it will always be undergoing changes. If you have any tips or hints to give us please send them to the HOWTO maintainer.

If you're on a network with no access to the outside world (not even a modem) and you trust all the internal machines and all your users then this section will be of no use to you. However, its our belief that there are relatively few networks in this situation so we would suggest reading this section thoroughly for anyone setting up NFS.

There are two steps to file/mount access in NFS. The first step is mount access. Mount access is achieved by the client machine attempting to attach to the server. The security for this is provided by the /etc/exports file. This file lists the names or ip addresses for machines that are allowed to access a share point. If the client's ip address matches one of the entries in the access list then it will be allowed to mount. This is not terribly secure. If someone is capable of spoofing or taking over a trusted address then they can access your mount points. To give a real-world example of this type of "authentication": This is equivalent to someone introducing themselves to you and you believe they are who they claim to be because they are wearing a sticker that says "Hello, My Name is ...."

The second step is file access. This is a function of normal file system access controls and not a specialized function of NFS. Once the drive is mounted the user and group permissions on the files take over access control.

An example: bob on the server maps to the UserID 9999. Bob makes a file on the server that is only accessible the user (0600 in octal). A client is allowed to mount the drive where the file is stored. On the client mary maps to UserID 9999. This means that the client user mary can access bob's file that is marked as only accessible by him. It gets worse, if someone has root on the client machine they can su - [username] and become ANY user. NFS will be none the wiser.

Its not all terrible. There are a few measures you can take on the server to offset the danger of the clients. We will cover those shortly.

If you don't think the security measures apply to you, you're probably wrong. In Section 6.1 we'll cover securing the portmapper, server and client security in Section 6.2 and Section 6.3 respectively. Finally, in Section 6.4 we'll briefly talk about proper firewalling for your nfs server.

Finally, it is critical that all of your nfs daemons and client programs are current. If you think that a flaw is too recently announced for it to be a problem for you, then you've probably already been compromised.

A good way to keep up to date on security alerts is to subscribe to the bugtraq mailinglists. You can read up on how to subscribe and various other information about bugtraq here: http://www.securityfocus.com/forums/bugtraq/faq.html

Additionally searching for NFS at securityfocus.com's search engine will show you all security reports pertaining to NFS.

You should also regularly check CERT advisories. See the CERT web page at www.cert.org.

6.1. The portmapper

The portmapper keeps a list of what services are running on what ports. This list is used by a connecting machine to see what ports it wants to talk to access certain services.

The portmapper is not in as bad a shape as a few years ago but it is still a point of worry for many sys admins. The portmapper, like NFS and NIS, should not really have connections made to it outside of a trusted local area network. If you have to expose them to the outside world - be careful and keep up diligent monitoring of those systems.

Not all Linux distributions were created equal. Some seemingly up-to- date distributions do not include a securable portmapper. The easy way to check if your portmapper is good or not is to run strings(1) and see if it reads the relevant files, /etc/hosts.deny and /etc/hosts.allow. Assuming your portmapper is /sbin/portmap you can check it with this command:

     strings /sbin/portmap | grep hosts.

On a securable machine it comes up something like this:

   /etc/hosts.allow
   /etc/hosts.deny
   @(#) hosts_ctl.c 1.4 94/12/28 17:42:27
   @(#) hosts_access.c 1.21 97/02/12 02:13:22

First we edit /etc/hosts.deny. It should contain the line

   portmap: ALL

which will deny access to everyone. While it is closed run:

   rpcinfo -p

just to check that your portmapper really reads and obeys this file. Rpcinfo should give no output, or possibly an error message. The files /etc/hosts.allow and /etc/hosts.deny take effect immediately after you save them. No daemon needs to be restarted.

Closing the portmapper for everyone is a bit drastic, so we open it again by editing /etc/hosts.allow. But first we need to figure out what to put in it. It should basically list all machines that should have access to your portmapper. On a run of the mill Linux system there are very few machines that need any access for any reason. The portmapper administers nfsd, mountd, ypbind/ypserv, pcnfsd, and 'r' services like ruptime and rusers. Of these only nfsd, mountd, ypbind/ypserv and perhaps pcnfsd are of any consequence. All machines that need to access services on your machine should be allowed to do that. Let's say that your machine's address is 192.168.0.254 and that it lives on the subnet 192.168.0.0, and that all machines on the subnet should have access to it (those are terms introduced by the Networking-Overview-HOWTO, go back and refresh your memory if you need to). Then we write:

   portmap: 192.168.0.0/255.255.255.0

in /etc/hosts.allow. This is the same as the network address you give to route and the subnet mask you give to ifconfig. For the device eth0 on this machine ifconfig should show:

   ...
   eth0   Link encap:Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:192.168.0.254  Bcast:192.168.0.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320
   ...

and netstat -rn should show:

   Kernel routing table
   Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
   ...
   192.168.0.0     0.0.0.0         255.255.255.0   U     0      0   174412 eth0
   ...

(Network address in first column).

The /etc/hosts.deny and /etc/hosts.allow files are described in the manual pages of the same names.

IMPORTANT: Do not put anything but IP NUMBERS in the portmap lines of these files. Host name lookups can indirectly cause portmap activity which will trigger host name lookups which can indirectly cause portmap activity which will trigger...

Versions 0.2.0 and higher of the nfs-utils package also use the hosts.allow and hosts.deny files, so you should put in entries for lockd, statd, mountd, and rquotad in these files too.

The above things should make your server tighter. The only remaining problem (Yeah, right!) is someone breaking root (or boot MS-DOS) on a trusted machine and using that privilege to send requests from a secure port as any user they want to be.

6.2. Server security: nfsd and mountd

On the server we can decide that we don't want to trust the client's root account. We can do that by using the root_squash option in /etc/exports:

   /home slave1(rw,root_squash)

This is, in fact, the default. It should always be turned on unless you have a VERY good reason to turn it off. To turn it off use the no_root_squash option.

Now, if a user with UID 0 (i.e., root's user ID number) on the client attempts to access (read, write, delete) the file system, the server substitutes the UID of the server's 'nobody' account. Which means that the root user on the client can't access or change files that only root on the server can access or change. That's good, and you should probably use root_squash on all the file systems you export. "But the root user on the client can still use su to become any other user and access and change that users files!" say you. To which the answer is: Yes, and that's the way it is, and has to be with Unix and NFS. This has one important implication: All important binaries and files should be owned by root, and not bin or other non-root account, since the only account the clients root user cannot access is the servers root account. In the exports(5) man page there are several other squash options listed so that you can decide to mistrust whomever you (don't) like on the clients.

The TCP ports 1-1024 are reserved for root's use (and therefore sometimes referred to as "secure ports") A non-root user cannot bind these ports. Adding the secure option to an /etc/exports entry forces it to run on a port below 1024, so that a malicious non-root user cannot come along and open up a spoofed NFS dialogue on a non-reserved port. This option is set by default.

6.3. Client Security

6.3.1. The nosuid mount option

On the client we can decide that we don't want to trust the server too much a couple of ways with options to mount. For example we can forbid suid programs to work off the NFS file system with the nosuid option. Some unix programs, such as passwd, are called "suid" programs: They set the id of the person running them to whomever is the owner of the file. If a file is owned by root and is suid, then the program will execute as root, so that they can perform operations (such as writing to the password file) that only root is allowed to do. Using the nosuid option is a good idea and you should consider using this with all NFS mounted disks. It means that the server's root user cannot make a suid-root program on the file system, log in to the client as a normal user and then use the suid-root program to become root on the client too. One could also forbid execution of files on the mounted file system altogether with the noexec option. But this is more likely to be impractical than nosuid since a file system is likely to at least contain some scripts or programs that need to be executed.

6.3.2. The broken_suid mount option

Some older programs (xterm being one of them) used to rely on the idea that root can write everywhere. This is will break under new kernels on NFS mounts. The security implications are that programs that do this type of suid action can potentially be used to change your apparent uid on nfs servers doing uid mapping. So the default has been to disable this broken_suid in the linux kernel.

The long and short of it is this: If you're using an old linux distribution, some sort of old suid program or an older unix of some type you might have to mount from your clients with the broken_suid option to mount. However, most recent unixes and linux distros have xterm and such programs just as a normal executable with no suid status, they call programs to do their setuid work.

You enter the above options in the options column, with the rsize and wsize, separated by commas.

6.3.3. Securing portmapper, rpc.statd, and rpc.lockd on the client

In the current (2.2.18+) implementation of nfs, full file locking is supported. This means that rpc.statd and rpc.lockd must be running on the client in order for locks to function correctly. These services require the portmapper to be running. So, most of the problems you will find with nfs on the server you may also be plagued with on the client. Read through the portmapper section above for information on securing the portmapper.

6.4. NFS and firewalls (ipchains and netfilter)

IPchains (under the 2.2.X kernels) and netfilter (under the 2.4.x kernels) allow a good level of security - instead of relying on the daemon (or in this case the tcp wrapper) to determine who can connect, the connection attempt is allowed or disallowed at a lower level. In this case you canstop the connection much earlier and more globaly which can protect you from all sorts of attacks.

Describing how to set up a Linux firewall is well beyond the scope of this document. Interested readers may wish to read the Firewall-HOWTO or the IPCHAINS-HOWTO. For users of kernel 2.4 and above you might want to visit the netfilter webpage at: http://netfilter.filewatcher.org. If you are already familiar with the workings of ipchains or netfilter this section will give you a few tips on how to better setup your firewall to work with NFS.

A good rule to follow for your firewall configuration is to deny all, and allow only some - this helps to keep you from accidentally allowing more than you intended.

Ports to be concerned with:

The portmapper is on 111. (tcp and udp)
nfsd is on 2049 and it can be TCP and UDP. Although NFS over TCP is currently experimental on the server end and you will usually just see UDP on the server, using TCP is quite stable on the client end.
mountd, lockd, and statd float around (which is why we need the portmapper to begin with) - this causes problems. You basically have two options to deal with it:
1. You more can more or less do a deny all on connecting ports but explicitly allow most ports certain ips.
2. More recent versions of these utilities have a "-p" option that allows you to assign them to a certain port. See the man pages to be sure if your version supports this. You can then allow access to the ports you have specified for your NFS client machines, and seal off all other ports, even for your local network.

Using IPCHAINS, a simply firewall using the first option would look something like this:

  ipchains -A input -f -j ACCEPT
  ipchains -A input -s trusted.net.here/trusted.netmask -d host.ip/255.255.255.255 -j ACCEPT
  ipchains -A input -s 0/0 -d 0/0 -p 6 -j DENY -y -l
  ipchains -A input -s 0/0 -d 0/0 -p 17 -j DENY -l

The equivalent set of commands in netfilter (the firewalling tool in 2.4) is:

 
  iptables -A INPUT -f -j ACCEPT
  iptables -A INPUT -s trusted.net.here/trusted.netmask -d \
      host.ip/255.255.255.255 -j ACCEPT
  iptables -A INPUT -s 0/0 -d 0/0 -p 6 -j DENY --syn --log-level 5
  iptables -A INPUT -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5

The first line says to accept all packet fragments (except the first packet fragment which will be treated as a normal packet). In theory no packet will pass through until it is reassembled, and it won't be reassembled unless the first packet fragment is passed. Of course there are attacks that can be generated by overloading a machine with packet fragments. But NFS won't work correctly unless you let fragments through. See Section 7 for details.

The other three lines say trust your local networks and deny and log everything else. It's not great and more specific rules pay off, but more specific rules are outside of the scope of this discussion.

Some pointers if you'd like to be more paranoid or strict about your rules. If you choose to reset your firewall rules each time statd, rquotad, mountd or lockd move (which is possible) you'll want to make sure you allow fragments to your nfs server FROM your nfs client(s). If you don't you will get some very interesting reports from the kernel regarding packets being denied. The messages will say that a packet from port 65535 on the client to 65535 on the server is being denied. Allowing fragments will solve this.

6.5. Summary

If you use the hosts.allow, hosts.deny, root_squash, nosuid and privileged port features in the portmapper/nfs software you avoid many of the presently known bugs in nfs and can almost feel secure about that at least. But still, after all that: When an intruder has access to your network, s/he can make strange commands appear in your .forward or read your mail when /home or /var/mail is NFS exported. For the same reason, you should never access your PGP private key over nfs. Or at least you should know the risk involved. And now you know a bit of it.

NFS and the portmapper makes up a complex subsystem and therefore it's not totally unlikely that new bugs will be discovered, either in the basic design or the implementation we use. There might even be holes known now, which someone is abusing. But that's life.