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.
