4.1 NFS, mountd, and portmap 
NFS stands for Network File System. It allows a client system to "mount" an NFS server system's remote file systems as if they were directly on the client system. Samba and AppleTalk are more recently created similar facilities. NFS is a powerful capability. Unfortunately, there have been numerous severe security problems, some of them unsolvable without incompatible protocol changes. Because of this, it is recommended that it not be used at all except on private secure networks, protected from insecure networks, such as the Internet. Please review "Turn Off NFS, mountd, and portmap" on page 98 and "Switch NFS to Run over TCP" on page 99, where many of the problems have been covered in-depth. So what are the problems and under what conditions can they be worked around? UDP is insecure because it can be spoofed easily. This can be resolved by protecting the network of NFS systems (servers and clients) from unsecured networks via a properly configured firewall and ensuring that only trusted systems running secure operating systems can attach to the network. This firewall will need to know which IP addresses belong on which interfaces and reject packets received on a different interface than that of the "real" system with said IP address. If the routing system is running Linux (with at least a 2.2 kernel), a firewall is not even necessary as the kernel offers Source Address Verification. This feature enables the kernel to block packets with spoofed source addresses coming in from the wrong interface. It is very easy to set up and is explained in "Blocking IP Spoofing" on page 134. All systems on this network need to be secured against untrustworthy people having root access. This is to prevent crackers that have physical or network access to your Linux and UNIX boxes simply spoofing from an "inside" system. For Windows and Macs, similar password protection is needed, though protection against physical access to them by the untrustworthy will increase security. This is due to their having a different security model than Linux. (Many people consider many closed source operating systems to be significantly less secure than Linux.) Systems need to be protected against a rogue booting his own operating system off floppy, CD-ROM, or obtaining single-user mode booting off disk. This is discussed starting in "Booting an Intruder's Floppy or CD-ROM" on page 126. Because of NFS's design, the NFS server will be compromised in addition to the box booted. Understand that NFS was created at a time when all computers were big and expensive, only trusted SysAdmins had root access, and systems were kept in locked rooms with very limited access. Anyone with root access can alter her client box to obtain any NFS access offered to any client on the network by a given NFS server. This is done simply by altering the client system's IP address and using su to gain the privileges of whichever account is offered access by the NFS server. Even if the NFS server does not grant root access to clients, an "ordinary" account will be plenty powerful if the account has access to critical data, such as the account for http, an important application, or an account that has access to program sources, confidential documents, Web pages, databases, etc. | On some distributions, such as Red Hat, the standard installation causes Apache to run with the permissions of the nobody account. This account also defaults to be the unprivileged NFS account, usually used when a client system's root account or nonmatching account issues an NFS request. A nonmatching account is an account (UID) on the client system that has no equivalent UID in the server system's /etc/passwd file. This means that an unprivileged account on a client system would have full access to the very privileged Apache Web server account. To avoid any risk of this, it should be considered mandatory that Apache (httpd) not run with the permissions of nobody, nor should any of its files be owned by nobody. Apache must not run as root either. |
Ensure that unprotected systems cannot get packets to your NFS server, mountd, portmap (or NFS clients) that could be spoofed. This means using IP Chains, preferably on a firewall, or Source Address Verification to block port 2049 (NFS) and port 111 (portmap) for both UDP and TCP from untrusted networks and untrusted systems. Use suitable options when mounting an NFS file system. The most important ones are as follows: The tcp option will cause NFS to use TCP instead of UDP. TCP is much harder to spoof, due to the three-way handshaking using random numbers. The nosuid options will cause the Linux kernel to ignore any set-UID or set-GID bits on files. The noexec option will prevent the execution of any programs on the file system. Use the options available in /etc/exports entries to increase security. In particular, the ro option to make a file system Read/Only that does not need to be writable and the noaccess option to block access to a subtree are helpful. Do not disable root_squash with no_root_squash. | Even with root_squash, if a nonroot user can alter a program that root later invokes, that user will "own" the machine. |
Use squash_uids=0-15,20 to squash UIDs 0 15 and 20. This means that if a remote user claims to be UID 13, treat him as if he was the nobody account on the server system. This account is presumed to own no files and thus is allowed only whatever access is granted worldwide. If appropriate, use all_squash to treat all users as nobody. Another possibility is to use map_static=/etc/nfs/nervous.map to use a list that maps remote UIDs into appropriate local UIDs. A typical nervous.map file would look like this: #ID Client Server Comments uid 0-99 - # Squash UIDs uid 100-999 1000 # Map 100-999 to 1000-1999 gid 0-99 - # Squash GIDs gid 100-999 1100 # Map 100-999 to 1100-2099
|
