NFS is well suited for sharing entire file systems with a large
number of known hosts in a transparent manner. 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
minimizes NFS security risks and better protects data on the
server.
For a concise listing of steps administrators can take to secure
NFS servers, refer the the chapter titled Server Security in the Red Hat
Enterprise Linux Security Guide.
Depending on which version of NFS you plan to implement, depends
on your existing network environment, and your security concerns.
The following sections explain the differences between implementing
security measures with NFSv2, NFSv3, and NFSv4. If at all possible,
use of NFSv4 is recommended over other versions of NFS.
NFS controls who can mount an exported file system based on the
host making the mount request, not the user that actually uses the
file system. Hosts must be given explicit rights to mount the
exported file system. Access control is not possible for users,
other than through file and directory permissions. In other words,
once a file system is exported via NFS, any user on any remote host
connected to the NFS server can access the shared data. To limit
the potential risks, administrators often allow read-only access or
squash user permissions to a common user and group ID.
Unfortunately, these solutions prevent the NFS share from being
used in the way it was 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.
Wildcards should be used sparingly when exporting directories
via NFS as it is possible for the scope of the wildcard to
encompass more systems than intended.
It is also possible to restrict access to the portmap service via TCP wrappers. Access to ports
used by portmap, rpc.mountd, and rpc.nfsd
can also be limited by creating firewall rules with iptables.
For more information on securing NFS and portmap, refer to the chapter titled Server Security in the Red Hat
Enterprise Linux Security Guide. Additional information about
firewalls can be found in Chapter 18
iptables.
The release of NFSv4 brought a revolution to authentication and
security to NFS exports. NFSv4 mandates the implementation of the
RPCSEC_GSS kernel module, the Kerberos version 5 GSS-API mechanism,
SPKM-3, and LIPKEY. With NFSv4, the mandatory security mechanisms
are oriented towards authenticating individual users, and not
client machines as used in NFSv2 and NFSv3.
 |
Note |
| |
It is assumed that a Kerberos ticket-granting server (KDC) is
installed and configured correctly, prior to configuring an NFSv4
server.
|
NFSv4 includes ACL support based on the Microsoft Windows NT
model, not the POSIX model, because of its features and because it
is widely deployed. NFSv2 and NFSv3 do not have support for native
ACL attributes.
Another important security feature of NFSv4 is its removal of
the rpc.mountd daemon. The rpc.mountd daemon presented possible security holes
because of the way it dealt with filehandlers.
For more information on the RPCSEC_GSS framework, including how
rpc.svcgssd and rpc.gssd interoperate, refer to https://www.citi.umich.edu/projects/nfsv4/gssd/.
Once the NFS file system is mounted read/write by a remote host,
the only protection each shared file has is its permissions. If two
users that share the same user ID value mount the same NFS file
system, they can 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. For more on NFS and user ID
conflicts, refer to the chapter titled Managing User Accounts and Resource Access in the
Red Hat Enterprise Linux Introduction to
System Administration.
By default, access control lists (ACLs) are supported by NFS
under Red Hat Enterprise Linux. It is not recommended that this
feature be disabled. For more about this feature, refer to the
chapter titled Network File System (NFS)
in the Red Hat Enterprise Linux System
Administration Guide.
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 nfsnobody account. Never turn off root
squashing.
If exporting an NFS share as read-only, consider using the
all_squash option, which makes every user
accessing the exported file system take the user ID of the
nfsnobody user.
