iTechtalk

prashant

NFS Server Security in Linux

Before attempting any sort of file sharing from an NFS server, it is a good idea to take some basic steps to secure the server's configuration. One major problem with NFS is its reliance on RPC-based services: rather than being assigned to a fixed port, RPC services are assigned a port randomly (or semi-randomly, or in some cases, not randomly at all) when they are initiated, by the RPC portmapper daemon. Clients wishing to connect to those services will first contact the portmapper daemon to inquire to which port the needed service has been assigned. Among other things, this plays havoc with firewalls, which rely on services being assigned a particular port time and again, which can make firewalling NFS services very difficult.

Fortunately, Red Hat's NFS implementation reduces this headache considerably through the use of some thoughtful configuration options: with the following quick changes, we can make NFS as firewall-friendly as possible.

Portmapper

First, we need to configure the portmapper daemon. It is always assigned the same port (TCP and UDP 111), so we don't need to worry about fixing that, but we do need to restrict access to it. Since this will be the gateway to the NFS services on the server, we need to carefully control to whom we grant access. By default, the portmapper daemon on Red Hat Linux comes compiled with support for Wietse Venema's TCP wrappers, which allows us to control access to it using a pair of configuration files. In /etc/hosts.deny, we will first set a default-deny policy for the portmapper:

/etc/hosts.deny
portmap: ALL

Now we will configure /etc/hosts.allow to permit access to the portmapper from trusted internal machines. Add IP addresses into this file to permit NFS clients access to the portmapper, being careful to list specific IPs rather than subnets, where possible. Below, I have granted access only to the NFS client at IP address 10.1.2.3.

/etc/hosts.allow
portmap: 10.1.2.3

mountd

The mount daemon (mountd) actually implements NFS mount requests: when a client wishes to mount a filesystem over NFS, it sends a MOUNT request to mountd to initiate the process, which verifies the request against the list of exported filesystems and returns a filehandle of the filesystem if the request is approved.

Mountd is an RPC service, so the first thing to do is to lock in the port to which it will be assigned. Anticipating this desire, Red Hat has configured a simple way to do this by adding the information to a configuration file rather than having to alter the startup file for this service by hand. First, choose a port for the mount daemon: it can be any port number higher than 1024, with the default choice being 2050 most of the time. Once you have selected your port, modify /etc/sysconfig/network as follows (I have used 2050 as an example):

/etc/sysconfig/network
MOUNTD_PORT=2050

On Red Hat Linux, mountd has also been compiled with support for TCP wrappers, so this service can be granted additional security by permitting access only from selected clients. This prevents an NFS problem in which clients could bypass restrictions on the portmapper and mount a filesystem by sending the request directly to mountd if they could figure out on what port mountd was running. To implement this, alter /etc/hosts.deny and /etc/hosts.allow again and add to the bottom the following lines (as an example, again granted access only to the NFS client at IP address 10.1.2.3):

/etc/hosts.deny
mountd: ALL
/etc/hosts.allow
mountd: 10.1.2.3

nfsd

The NFS daemon (nfsd) is a sort of go-between, shuttling information back and forth between the userland space and the kernel module (nfsd.o) actually implementing NFS under Linux. Like mountd, nfsd is an RPC service, so it has no fixed port, and unlike mountd, it has not been compiled with support for TCP wrappers nor does it have a convenient shortcut in the system configuration files for pre-selecting a port. However, we can pre-select the port on it by altering the startup script (/etc/init.d/nfs) by hand and adding the following information:

/etc/init.d/nfs

Find this block:

echo -n $"Starting NFS daemon: "
daemon rpc.nfsd $RPCNFSDCOUNT

And change it to read thus (using 2049 as our pre-selected port for nfsd):

echo -n $"Starting NFS daemon: "
daemon rpc.nfsd -p 2049 $RPCNFSDCOUNT

Rquotad

The remote quota daemon (rquotad) is responsible for answering clients' queries about user quotas for exported NFS filesystems. That is, when a client attempts to write to an NFS filesystem, it will first inquire of the quota daemon (if the server has quotas active for that filesystem) whether the client has sufficient quota to issue the write. Rquotad will then check the local quotas for that user and return that information to the client. Unfortunately, in addition to lacking TCP wrappers support, rquotad cannot be fixed to a specific port. If you wish to tie user quotas to NFS, you will need to plan for this, since rquotad cannot be further secured.

On the other hand, if you are not using quotas, there is no reason to run rquotad, and you can deactivate it without having an impact on your NFS filesystems. To do so, alter the NFS startup script (/etc/init.d/nfs):

/etc/init.d/nfs

Comment out the following blocks in this file to deactivate rquotad:

if [ -x /usr/sbin/rpc.rquotad ] ; then
echo -n $"Starting NFS quotas: "
daemon rpc.rquotad
echo
fi

if [ -x /usr/sbin/rpc.rquotad ] ; then
echo -n $"Stopping NFS quotas: "
killproc rpc.rquotad
echo
fi

if [ -x /usr/sbin/rpc.rquotad ] ; then
status rpc.rquotad
fi

You will notice that all of these blocks check to see if rpc.rquotad is executable (using the -x flag) before running these commands. One possible way of deactivating rquotad is to remove the executable bits from it using chmod (chmod a-x /usr/sbin/rpc.rquotad would work). While this would deactivate it, an RPM update to quota RPM (or a well-meaning administrator!) would likely restore those executable privileges, thus inadvertently reactivating the daemon. If you have really decided not to use quotas over NFS, commenting those blocks will help guarantee that the service stays deactivated until you choose to activate it. Obviously, if the service is not needed, you should uninstall it to keep it from being a liability to the system in the future: a quick ‘rpm -e quota’ will accomplish this.