15.2 Server-Side NFS Security
Because NFS allows users on a network
to access files stored on the server, NFS has significant security
implications for the server. These implications fall into three broad
categories:
- Client access
-
NFS can (and should) be configured so that only certain clients on
the network can mount filesystems stored on the server.
- User authentication
-
NFS can (and should) be configured so that users can access and alter
only files to which they have been granted access.
- Eavesdropping and data spoofing
-
NFS should (but does not) protect information on the network from
eavesdropping and surreptitious modification.
15.2.1 Limiting Client Access: /etc/exports and /etc/dfs/dfstab
The NFS server can be configured so
that only certain hosts are allowed to mount filesystems on the
server. This is a very important step in maintaining server security:
if an unauthorized host is denied the ability to mount a filesystem,
then unauthorized users on that host should not be able to access the
server's files. This configuration is controlled by
settings in a file. Depending on the version of Unix/Linux/etc. that
you are using, the specific file structure and usage is different.
Systems with a BSD heritage use /etc/exports,
and systems with a System V heritage use
/etc/dfs/dfstab.
15.2.1.1 /etc/exports
Many versions of Unix, including
Sun's SunOS, HP's HP-UX,
SGI's IRIX, and Linux use the
/etc/exports file to designate which clients can
mount the server's filesystem and what access those
clients can be given. Each line in the
/etc/exports file generally has the form:
directory -options [,more options]
For example, a sample /etc/exports file might
look like this:
/ -access=math,root=prose.domain.edu
/usr -ro
/usr/spool/mail -access=math
The directory may be any directory or
filesystem on your server. In the example, exported directories are
/, /usr, and
/usr/spool/mail.
The options allow you to specify a variety
of security-related and performance-related options for each entry.
These include:
- access= machinelist
-
Grants access to this filesystem only to the hosts or netgroups (see
Chapter 12) specified in
machinelist. The names of hosts and
netgroups are listed and separated by colons (e.g.,
host1:host2:group3).
A maximum of 10 hosts or group names can be listed in some older
systems (check your documentation).
- ro
-
Exports the directory and its contents as read-only to all clients.
This option overrides whatever the file permission bits are actually
set to.
- rw= machinelist
-
Exports the filesystem read-only to all hosts except those listed,
which are allowed read/write access to the filesystem.
- root= machinelist
-
Normally, NFS changes the user ID for requests issued by the
superuser on remote machines from 0 (root) to -2
(nobody). Specifying a list of hosts gives the superuser on these
remote machines superuser access on the server.
- anon= uid
-
Specifies which user ID to use on NFS requests that are not
accompanied by a user ID; this might happen on a DOS client. The
number specified is used for both the UID and
the GID of anonymous requests. A value of -2 is
the nobody user. A value of
-1 usually disallows access.
- secure
-
Specifies that NFS should use Sun's Secure RPC
(AUTH_DES) authentication system, instead of AUTH_UNIX. See Chapter 13 for more information.
You should understand that NFS maintains options on a per-filesystem
basis, not on a per-directory basis. If you put two directories in
the /etc/exports file that actually reside on
the same filesystem, they will use the same options (usually the
options used in the last export listed).
Sun's documentation of anon
states that, "If a request comes from an unknown
user, use the given UID as the effective user ID."
This statement is very misleading; in fact, NFS by default honors
"unknown" user IDs—that is,
UIDs that are not in the server's
/etc/passwd file—in the same way that it honors
"known" UIDs because the NFS server
does not ever read the contents of the
/etc/passwd file. The anon option
actually specifies which UID to use for NFS requests that are not
accompanied by authentication credentials.
The Linux NFS server offers several additional options that can be
placed in the /etc/exports file and provide some
limited security improvements:
- root_squash
-
Forces requests from UID 0 to be mapped to the anonymous UID. This
option is on by default.
- squash_uids=0-10,20,25-30
-
Allows you to specify other UIDs that are mapped to the anonymous
UID. Of course, an attacker can still gain access to your system by
using non-squashed UIDs.
- all_squash
-
Specifies that all UIDs should be mapped to the anonymous UID. This
option does genuinely increase your system's
security, but why not simply export your filesystem read-only?
Some BSD-derived systems offer similar options:
- -maproot=userid or -maproot=userid:group:group
-
Forces requests from UID 0 to be mapped to the given UID and groups.
- -mapall=userid or -mapall=userid:group:group
-
Allows you to specify that all other UIDs be mapped to the given UID
and groups.
|
Let's look at the example
/etc/exports file again:
/ -access=math,root=prose.domain.edu
/usr -ro
/usr/spool/mail -access=math
This example allows anybody in the group math or
on the machine math to mount the
root directory of the server, but only the
root user on machine
prose.domain.edu
has superuser access to these files. The
/usr filesystem is exported read-only to every
machine that can get RPC packets to and from this server (usually a
bad idea—this may be a wider audience than the local network).
And the /usr/spool/mail directory is exported to
any host in the math netgroup.
15.2.1.2 /usr/etc/exportfs
The
/usr/etc/exportfs program reads the
/etc/exports file and configures the NFS
servers, which run inside
the kernel's address space. After you make a change
to /etc/exports, be sure to type this on the
server:
# exportfs -a
You can also use the exportfs command to
temporarily change the options on a filesystem. Because different
versions of the command have slightly different syntax, you should
consult your documentation.
15.2.1.3 Exporting NFS directories under System V: share and dfstab
Versions of NFS that are present
on System V-derived systems (including Solaris) have dispensed with
the /etc/exports file and have instead adopted a
more general mechanism for dealing with many kinds of distributed
filesystems in a uniform manner. These systems use a command named
share to extend access for a filesystem to a
remote machine, and the command unshare to revoke
access.
The share command has
the syntax:
share [ -F FSType ] [ -o specific_options ] [ -d description ] [ pathname ]
in which FSType should be
nfs for NFS filesystems, and
specific_options are basically the same as
those documented earlier for the /etc/exportfs
file. The optional argument description is
meant to be a human-readable description of the filesystem that is
being shared.
When a system using this mechanism boots, its network initialization
scripts execute the shell script /etc/dfs/dfstab.
This file contains a list of share commands.
Example 15-1 illustrates such a file with some
security problems.
Example 15-1. An /etc/dfs/dfstab file with some problems
# Place share(1M) commands here for automatic execution
# upon entering init state 3.
#
# This configuration is not secure.
#
share -F nfs -o rw=red:blue:green /cpg
share -F nfs -o rw=clients -d "spool" /var/spool
share -F nfs /tftpboot
share -F nfs -o ro /usr/lib/X11/ncd
share -F nfs -o ro /usr/openwin
This file gives the computers red,
blue, and green access to
the /cpg filesystem; it also gives all of the
computers in the clients netgroup access to
/var/spool. All computers on the network are
given read/write access to the /tftpboot
directory; and all computers on the network are given read-only
access to the directories /usr/lib/X11/ncd and
/usr/openwin.
One
extension to the NFS Version 3 protocol made by Sun engineers, and
proposed to be included in NFS 4, is the addition of WebNFS. This is
the capability in which an NFS server exports a single NFS partition
for access via web servers, Java applications, and other network
services but does not expose the mount protocol
to the outside.
Basically, the idea is that a system can be set up with a single
partition marked as "public" in the
/etc/dfs/sharetab
file. An appropriately equipped web browser, when presented with a
URL of the form nfs://server/filename, then contacts the
server and returns the designated item. Because there is only one
"public" partition, there is no
need to mount the disk or otherwise transfer information to find the
file. In theory, this should be a safe way to provide a file because
the mount server can be hidden behind a firewall, and the disk can be
exported read-only.
We recommend that you do not use this protocol
unless you thoroughly understand the potential risks. Not the least
among these are the following:
You need to open your firewall to traffic to your NFS server
(normally, port 2049). This can allow someone to execute a denial of
service attack against your NFS server from outside your
organization.
Opening your NFS port through the firewall may enable someone to
guess, steal, or forge file handles such that they can access your
other files.
A misconfiguration of your NFS or a bug in the software may open your
system to attack via the NFS subsystem.
By opening your NFS port to the outside, you may enable your users to
access other NFS partitions from unsecured systems that are
susceptible to eavesdropping or hijacking.
Quite frankly, the whole idea strikes us as another instance of
"Wouldn't it be cool to . . .
?" rather than "Do we introduce new
risks if we . . . ?"
|
Do you see the security hole in the above configuration?
It's explained in detail in Section 15.4.1.1
later in this chapter.
|
Under some old versions of Unix, there was a problem if you exported
any of your filesystems to yourself by name, by netgroup, or to
localhost. This came about
if your RPC portmapper had proxy
forwarding enabled (often the default). If proxy forwarding was
enabled, an attacker could carefully craft NFS packets and send them
to the portmapper, which in turn forwarded them
to the NFS server. As the packets came from the
portmapper process (which was running as
root), they appeared to be coming from a trusted
system. This configuration could allow anyone to alter and delete
files at will.
We are uncertain which systems may still harbor this vulnerability.
Thus, caution is the prudent course of action if you feel the need to
make such loopback mounts.
|
|
15.2.2 The showmount Command
You can use the Unix command
showmount (typically located in
/usr/sbin or /usr/etc and
present in most flavors of Unix) to list all of the clients that have
probably mounted directories from your server.
This command has the form:
/usr/etc/showmount [options] [host]
The options are:
- -a
-
Lists all of the hosts and which directories they have mounted
- -d
-
Lists only the directories that have been remotely mounted
- -e
-
Lists all of the filesystems that are exported; this option is
described in more detail later in this chapter
|
The showmount command does not tell you which
hosts are actually using your exported filesystems; it shows you only
the names of the hosts that have mounted your
filesystems since the last reset of the local log file. Because of
the design of NFS, someone can use a filesystem without first
mounting it.
|
|
|