prashant

NFS Client Security in Linux

Securing the client is relatively simple: it will only require the portmapper. The mount command will handle the necessary NFS module activations when called upon to mount a filesystem over NFS. Since the client will be running the portmapper, however, this should be secured in the same manner as the server's, restricting inbound connections to only those necessary.

Example I: Transient Filesystem

In this example, we will present a sample configuration for a secured NFS mount between a client and server which would be mounted manually by administrators. This would include shared directories that contain system patches, for example, so that a central patch repository could be remotely mounted to patch servers and then unmounted when not required. Since the directory containing the patches will only be read by the client and should not be modified, we can export this filesystem read-only. We can also export the filesystem using "squashing", an option that maps UIDs and GIDs on the client to corresponding UIDs and GIDs on the server. Commonly, this is done to the root account, so that the remote client's root account is not automatically granted root-level privileges to the filesystems on the server. In this case, however, we only need the right to read the patches, so we will export the filesystem with complete squashing: we will create an unprivileged user on the server who can only read the patches, and map all remote UIDs to that user, reducing all of the client's privileges accordingly. NFS also allows us to export the filesystem to a specific client or group of clients: never export a filesystem to the world! We will restrict access to the patches share to a local, internal subnet: 10.1.1.0/24, e.g.

Linux offers some convenient extra tweaks to NFS to tighten security a little: the "hide" feature, enabled by default, means that a filesystem mounted within a shared filesystem (such as having /usr and /usr/local on separate disk partitions) is not automatically shared: the server must share that secondary filesystem separately, and the client must mount it separately. In addition, the "secure" feature, also enabled by default, requires that NFS mount requests originate from a privileged port, helping to ensure that the user making the remote mount request is root or has root privileges. This isn't a foolproof determinant, but every little bit helps.

On the Server

Create the patch directory
mkdir /local/patches

Create the unprivileged user and group
groupadd -g 1500 patches
useradd -u 1500 -g patches -d /local/patches -s /dev/null patches

Edit /etc/exports to configure the share
/etc/exports
/local/patches 10.1.1.0/24(ro,secure,hide,all_squash,anonuid=1500,anongid= 1500)

Ensure that the NFS services are running on the server
/etc/init.d/portmap start
/etc/init.d/nfs start
/etc/init.d/nfslock start

Export all configured filesystem shares (-a), using verbose output (-v)
/usr/sbin/exportfs –va

Copy patches into
/local/patches

On the Client

Ensure the portmapper is running
/etc/init.d/portmap start

Create the mount point
mkdir /nfsmount/patches

Mount the remote filesystem from the server at 10.1.1.50
/bin/mount -t nfs 10.1.1.50:/local/patches /nfsmount/patches

Example II: At-Boot Filesystem

The example being explored here is a filesystem that would be mounted at boot off of a central fileserver. Frequently, this is done with user home directories. Since the users will need individual access to their directories, we cannot employ complete squashing. Instead, we will be sure to use root squashing. In order to do this, you must be careful to synchronize UIDs between the clients and the server. Since access is granted by numerical UID and not by username, a user with a different UID on the client and the server would not have access rights to her own directory, and might (even worse) have complete access to someone else's entirely!

On the Server

Create the users for whom you will want to grant access, and synchronize their UIDs with the client. If the users will not ever login to the NFS server directly, they can be granted user accounts with null shells (/dev/null or /bin/false or the like), since that account information will then only be used for mapping NFS privileges. We can at least restrict the access to this filesystem to the local LAN (as is almost always a good idea for security), and we can employ root squashing to prevent root-level breaches.

Edit /etc/exports to configure the share
/etc/exports
/home 10.1.1.0/24(rw,secure,hide,root_squash)

Ensure that the NFS services are running on the server
/etc/init.d/portmap start
/etc/init.d/nfs start
/etc/init.d/nfslock start

Export all configured filesystem shares (-a), using verbose output (-v)
/usr/sbin/exportfs –va

On the Client

One extra piece of security checking to be performed: the client should mount the filesystem as an untrusted volume. This means mounting it without SUID files (nosuid), without devices (nodev) and preferably without executables, to prevent the server from being granted additional privileges on the client. The first two options are particularly important: without them, an attacker with access to the NFS server could insert a SUID shell or compromised device into the shared filesystem and be automatically granted privileges on the other filesystems. Although we have enabled root squashing, remember that there is no squashing for users such as bin or daemon, which are potentially just as dangerous to the client as root access!

Ensure the portmapper is running
/etc/init.d/portmap start

Test connectivity by mounting the remote filesystem from the server at 10.1.1.50
/bin/mount -t nfs 10.1.1.50:/home /home

Configure /etc/fstab to mount the filesystem automatically
/etc/fstab:
10.1.1.50:/home /home nfs nosuid,nodev,noexec 0 0