Securing NFS
NFS works well for sharing entire file systems with a large number of
known hosts in a largely transparent manner. Many users accessing files
over an NFS mount may not be aware that the file system they are using is
not local to their system. However, with ease of use comes a variety of
potential security problems.
The following points should be considered when exporting NFS
file systems on a server or mounting them on a client. Doing so will
minimize NFS security risks and better protect your data.
Host Access
NFS controls who can mount an exported file system based on the host
making the mount request, not the user that will actually use the
file system. Hosts must be given explicit rights to mount the exported
file system. Access control is not possible for users, other than file
and directory permissions. In other words, when you export a
file system via NFS to a remote host, you are not only trusting the
host you are allowing to mount the file system. You are also allowing
any user with access to that host to use your file system as well. The
risks of doing this can be controlled, such as requiring read-only
mounts and squashing users to a common user and group ID, but these
solutions may prevent the mount from being used in the way originally
intended.
Additionally, if an attacker gains control of the DNS server used by
the system exporting the NFS file system, the system associated with a
particular hostname or fully qualified domain name can be pointed to
an unauthorized machine. At this point, the unauthorized machine
is the system permitted to mount the NFS share,
since no username or password information is exchanged to provide
additional security for the NFS mount. The same risks hold true to
compromised NIS servers, if NIS netgroups are used to allow certain hosts
to mount an NFS share. By using IP addresses in
/etc/exports, this kind of attack is more
difficult.
Wildcards should be used sparingly when granting host access to an NFS
share. The scope of the wildcard may encompass systems that you may
not know exist and should not be allowed to mount the file system.
File Permissions
Once the NFS file system is mounted read-write by a remote host,
protection for each shared file involves its permissions, and its user
and group ID ownership. If two users that share the same user ID value
mount the same NFS file system, they will be able to modify each others
files. Additionally, anyone logged in as root on the client system can
use the su - command to become a user who could
access particular files via the NFS share.
The default behavior when exporting a file system via NFS is to use
root squashing. This sets the user ID of
anyone accessing the NFS share as the root user on their local machine
to a value of the server's nobody account. You should never turn off
root squashing unless multiple users with root access to your server
does not bother you.
If you are only allowing users to read files via your NFS share,
consider using the all_squash option, which makes
every user accessing your exported file system to take the user ID of
the nobody user.
