Transcript nfs - shaieb.net

NFS Admin And Security
Steve Nuchia
Sravani Motati
Ashish Katyarmal
NFS Overview
Server
Client
/
/
home
usr
home
usr
bin
bin
a
b
c
NFS: Export Subtree
Windows: Share Folder
a
b
c
NFS: Mount a remote filesystem
Windows: map a shared drive
In windows you get a new drive letter. In Unix, the imported
file tree can be mounted as a subtree anywhere in your tree.
Setting Up NFS Server
Three Main Configuration files
/etc/exports
/etc/hosts.allow
/etc/hosts.deny
Only /etc/exports is needed for NFS to work
but to make the sharing secure we need the
other two
 /etc/exports
• This files is the standard for controlling which
filesystems are exported to which hosts , as well
as specifying particular options that control
everything
• Contains list of entries
• Each entry indicates a volume that is shared and
how it is shared
• Typical entry will look like
directory machine1(option11,option12) machine2(option21,option22)
directory machine1(option11,option12) machine2(option21,option22)
directory
The directory you want to share .
All directory under it within same filesystem
will be shared as well.
machine1 and machine2
Client machines that will have access to the
directory . The machine may be listed by their
IP address or their DNS address
directory machine1(option11,option12) machine2(option21,option22)
optionxx
The option listing for each machine will describe
what kind of access that machine will have
 ro:
The directory is shared read only --default
 rw:
The client machine will have read and write
access to the directory
directory machine1(option11,option12) machine2(option21,option22)
 no_root_squash:
The root on the client machine will have the
same level of access to the files on the
system as root on the server
This can have serious security implications
but one might need to perform any
administrative work on the client machine
that involves the exported directories
directory machine1(option11,option12) machine2(option21,option22)
 no_subtree_check
If only part of a volume is exported, a routine
called subtree checking verifies that a file
that is requested from the client is in the
appropriate part of the volume. If the entire
volume is exported, disabling this check will
speed up transfers.
directory machine1(option11,option12) machine2(option21,option22)
 sync
Version 2 NFS server will tell a client machine that a
file write is complete however, the file system may not
sync it to the disk.
The default behavior may therefore cause file
corruption if the server reboots
This option forces the filesystem to sync to disk every
time NFS completes a write operation
Version 3 NFS has a commit operation that the client
can call that actually will result in a disk sync on the
server end.
Example
Two client machines, slave1 and slave2,with
IP addresses 192.168.0.1 and
192.168.0.2, respectively . To share
software binaries and home directories
with these machines the entry in the
/etc/exports will look like
/usr/local 192.168.0.1(ro) 192.168.0.2(ro)
/home 192.168.0.1(rw) 192.168.0.2(rw)
Simplifications for the Entries
 Can give access to a range of machines at once
by specifying a network and a netmask.
eg /usr/local 192.168.0.0/255.255.255.0(ro)
 Can use wildcards such as *.foo.com or
192.168. instead of hostnames
These simplification could cause a security risk if
there are machines in the netgroup or local
network which cannot be trusted completely
Few Cautions
 If a directory is exported its parents and child
directory cannot be exported if they are in the
same filesystems but if a directory is exported
all the underlying subdirectories within that file
system will be exported
 Poor idea to export FAT filesystem with NFS
 Device or other special files may not exported
correctly to non-Linux clients
 /etc/hosts.allow and /etc/hosts.deny
These files specify which computer on the network
can use services on the machine.
Each line is an entry listing a service and a set of
machines
When a server gets a request from the client
 It first checks hosts.allow
 Then it checks hosts.deny
 No listing in either files then access is allowed
Security through daemons
In addition to controlling access to services handled
by inetd this file can also control access to NFS by
restricting connection to the daemons
The first daemons to restrict access to is the
portmapper. Restricting access to this is the best
defense but it is not enough if the intruder knows
how to find the daemons
Restricting portmapper will also restrict NIS but
usually NFS and NIS are restricted in similar way
Good idea to explicitly deny access to hosts that
don’t need to allow access.
Steps
 Add portmap:ALL to /etc/hosts.deny
portmap:ALL
 Add entries for each of the NFS daemons to
/etc/hosts.deny
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
By adding entry ALL:ALL to the file /etc/hosts.deny will
causes any service that looks at these files to deny
access to all hosts unless it is explicitly allowed (this is
more secure behavior)
Steps (continued)
 Add entry to hosts.allow to give any
hosts access
Typically entry in the host.allow will look
like
service: host [or network/netmask] , host [or network/netmask]
Here host is IP address of a potential client
(it may be possible in some versions to
use the DNS name of the host, but it is
strongly deprecated )
Example
To allow access to slave1.foo.com and slave2.foo.com, and
suppose that the IP addresses of these machines are
192.168.0.1 and 192.168.0.2, respectively. We could add
the following entry to /etc/hosts.allow:
portmap: 192.168.0.1 , 192.168.0.2
For Recent nfs-utils we would add the following entries
lockd: 192.168.0.1 ,192.168.0.2
rquotad: 192.168.0.1 , 192.168.0.2
mountd: 192.168.0.1 , 192.168.0.2
statd: 192.168.0.1 , 192.168.0.2
Getting the services started
The NFS server is configured and we can start it
running for this we need to check the following
things:
1)Appropriate packages installed
This consists mainly of a new kernel and a new
version of the nfs-utils package
2)TCP/IP networking functioning correctly?
If telnet, FTP, are working then chances are TCP
networking is fine.
NFS starts up simply by rebooting the
machine, and the startup scripts should
detect the set up of /etc/exports file.
To check this query the portmapper with the
command rpcinfo -p to find out what
services it is providing
Its should look something like:
Program
100000
100000
100011
100011
100005
100005
100005
100005
100005
100005
100003
100003
300019
300019
100024
100024
100021
100021
100021
100021
100021
100021
vers proto port
2
tcp
111 portmapper
2
udp 111 portmapper
1
udp 749 rquotad
2
udp 749 rquotad
1
udp 759 mountd
1
tcp
761 mountd
2
udp 764 mountd
2
tcp
766 mountd
3
udp 769 mountd
3
tcp
771 mountd
2
udp 2049 nfs
3
udp 2049 nfs
1
tcp
830 amd
1
udp 831 amd
1
udp 944 status
1
tcp 946 status
1
udp 1042 nlockmgr
3
udp 1042 nlockmgr
4
udp 1042 nlockmgr
1
tcp 1629 nlockmgr
3
tcp 1629 nlockmgr
4
tcp 1629 nlockmgr
If we do not at least see a line that says
"portmapper", a line that says "nfs", and a
line that says "mountd" then we need to
backtrack and try again to start up the
daemons
If we see these services listed, then the
server should be ready to set up NFS
clients to access files.
If this does not work, or if we cannot reboot
the machine then we can start the
daemons in order to run NFS services.
 Start the portmapper which should be
located in the /sbin but is sometimes in
/usr/sbin
Portmap or rpc.portmap
 Start the daemons
NFS serving is taken care of by five daemons:
rpc.nfsd, which does most of the work; rpc.lockd
and rpc.statd, which handle file locking;
rpc.mountd, which handles the initial mount
requests, and rpc.rquotad, which handles user
file quotas on exported volumes
The daemons are all part of the nfs-utils package,
and may be either in the /sbin directory or the
/usr/sbin directory.
If the distribution does not include them in
the startup scripts, then we need to add
them, configured to start in the following
order:
rpc.portmap
rpc.mountd, rpc.nfsd
rpc.statd, rpc.lockd (if necessary),rpc.rquotad
Making Changes to the /etc/exports
If we want to change etc/exports file, the
changes may not take effect immediately.
we should run the command exportfs -ra
to force nfsd to re-read the
/etc/exports file. If we cannot find the
exportfs command, then we can kill nfsd
with the -HUP flag
Topics
Configure NFS client
NFS Daemons
Mounting NFS volume
Files used by NFS clients
Automount daemon (AMD)
RPC procedures in NFS
Configuring NFS Client
In /etc/vfs file search the entry:
#%Defaultvfs jfs nfs
#Nfs 2 /sbin/helpers/nfsmnthelp none remote
Delete # signs.
In /proc/filesystems search for nfs (new
kernel versions):
$ Cat /proc/filesystems
Ext2
Nodev proc
Nodev nfs
If missing compile your own kernel with NFS enabled / type insmod nfs to check
if it exists.
* For
old kernel versions try to mount a local directory.If
mount fails with error message ”fs type nfs not
supported by kernel”, then make a new kernel with NFS
NFS Daemons
Daemon
nfsd
portmap
Description
File creation,searching,reading,writing,authentication and file
statistics, path:/usr/sbin/nfsd
rpc portmapper daemon, path:/usr/sbin/portmap
Protocol
nfs
portmap
Lockd
Network Lock Manager-locks clients to avoid data
modification,path:/usr/sbin/rpc.lockd
nlm
statd
Network Status Manager-monitor network nodes,
path:/usr/sbin/rpc.statd
nsm
biod
Block I/O daemon, Performs read-ahead and write-behind
caching for the client. path:/usr/sbin/biod
nfs
mountd
Mounting exported systems, handles mount and unmount
requests, path: /usr/sbin/rpc.mountd
mountd
ugidd
map the server's uid/gid space to the client's uid/gid
space,path:/usr/ sbin/rpc.ugidd
UGID RPC
Starting NFS Daemons
Order of startup:
 rpc.portmap
 rpc.mountd
 rpc.nfsd => rpc.lockd
 rpc.statd (separate)
Recent Linux distributions will have startup
scripts for these daemons.
The daemons are part of the nfs-utils package,
and may be present in the /sbin or the /usr/sbin
directory.
 To check use command: ps aux | grep portmap
Starting NFS Daemons
NFS daemons can be controlled
by the system resource
controller (SRC)
(http://www.unet.univie.ac.at/aix/aixbman/admnconc/sys_res_overview.htm#A2729f9)
by SRC commands such as startsrc,
stopsrc, and lssrc to start, stop, and check
the status of the NFS daemons.
Some NFS daemons can be
started and stopped by the inetd:
rpc.rexd, rpc.rusersd, rpc.rwalld, and rpc.rsprayd.
Starting NFS Daemons
Start the NFS Daemons at System
Startup:
 The Web-based System Manager fast path,
wsm network
 The SMIT fast path, smit mknfs
 The mknfs command
Start the NFS Daemons individually:
startsrc -s Daemon
Start all the NFS Daemons:
startsrc -g nfs
*To start nfsd, rpc.mountd daemons-
Mounting an NFS Volume
Confirm that NFS Server has exported
the directory:
Showmount –e ServerName
Establish mount point(empty):
mkdir mount_directory
Mount is invoked by the following
syntax:
# mount –t nfs -o options nfs_volume
mount_point
Example:
root@helium>>mount –t nfs –o nosuid,hard,intr
Mounting an NFS Volume
To mount NFS volume at Boot Time:
Edit /etc/fstab on client “helium” with the
entry:
# volume mount point type
fsckorder
neon:/usr/local
0
/usr/local
nfs
options
dump
nosuid,hard,intr
The /etc/fstab file is invoked by the rc.boot
script at boot time
The /etc/mtab file contains entries for file
systems currently mounted
0
Mount options
Mount
-p Print the list of mounted file systems
-a all the file systems described in /etc/fstab
-n mount without making an entry in /etc/mtab
-v Display a message indicating each file system
-t Specify a file system type.
-r Mount the specified file system as read-only
-o Specifies a comma-separated list of file system
options
option ’-o’ specific to NFS
 bg|fg If the first attempt fails, retry in the background, or, in









the fore- ground.
noquota Prevent quota from checking if user is over quota
on this file system.
retry=n The number of times to retry the mount operation.
rsize=n Set the read buffer size to n bytes.
wsize=n Set the write buffer size to n bytes.
timeo=n Set the NFS timeout to n tenths of a second.
retrans=n The number of NFS retransmissions.
port=n The server IP port number.
soft|hard Return an error if server does not respond
|continue the retry request until the server responds.
intr Allow keyboard interrupts on hard mounts.
option ’-o’ specific to NFS
 posix Request POSIX.1 semantics for the file system.
 secure Use a more secure protocol for NFS transactions
 acregmin=n Hold cached attributes for at least n seconds after






file modification.
acregmax=n Hold cached attributes for no more than n
seconds after file modification.
acdirmin=n Hold cached attributes for at least n seconds after
directory update.
acdirmax=n Hold cached attributes for no more than n seconds
after directory update.
actimeo=n Set min and max times for regular files and
directories to n seconds.
nocto Suppress fresh attributes when open- ing a file.
noac Suppress attribute and name (lookup) caching.
Mount Options for Client
Security
The nosuid mount option
If a program resident on the remote filesystem is
setuid and it is run on the client, it will have the
privileges associated with that userid (perhaps
root) on the client machine. Usually allowing
this to happen is a bad idea. Setting the nosuid
option prevents it.
The broken_suid mount option
Some older kernels rely on the idea that root can
write everywhere. Programs that do this type of
suid action can potentially be used to change
apparent uid on nfs servers doing uid mapping.
So it has to be disabled.
Files Used by NFS Clients
 /usr/etc/biod
-- Block I/O Deamon.
 /usr/etc/portmap -- rpc portmapper deamon.
 /usr/etc/rpc.lockd -- Lock deamon.
 /usr/etc/rpc.statd -- Status deamon.
 /etc/fstab -- File system table.
 /usr/etc/mount -- mount program.
 /usr/etc/umount -- umount program.
 /etc/rc.local -- local configuration file where
deamons are started.
 /etc/mtab-- flat file that shows mounted file
systems.
Automount Daemon
 Amd is a daemon that automatically mounts
filesystems whenever a file or directory within that
filesystem is accessed.
 Filesystems are automatically unmounted when they
appear to have become quiescent.
 Amd operates by attaching itself as an NFS server to
each of the specified directories.
Syntax:
/usr/sbin/automount [ -m ] [-n ] [ -T ] [ -v ] [ D name=value ] [ -f MasterFile ] [ -M MountDirectory ]
[ -tl Duration ] [ -tm Interval ] [ -tw Interval ]
Directory ..$. MapName ... [ -MountOption
[ ,MountOption ] ... ]
Automount Daemon
Its advantages include:
 it never hangs if remote server goes down
 it sends ``keep alive'' queries to servers
and keeps a list of accessible servers. It
returns ``operation would block'' errors
rather than hanging.
 it is completely public domain
 it offers more mount types
 its maps can be in NIS, Hesiod, ndm
formats among others
 the map syntax is more generic
 makes handling of subdirectories easier.
RPC Procedures Found in
NFS

NFSPROC_NULL This procedure is termed null
because it does nothing.
 NFSPROC_GETATTR -- returns the attributes protection, owner, size, and access times.
 NFSPROC_SETATTR-- sets the file attributes.
 NFSPROC_LOOKUP -- does a directory lookup for the
client.
 NFSPROC_READLINK -- reads the value stored in a
symbolic link.
 NFSPROC_READ -- allows a client to read data from a
file.
 NFSPROC_WRITE
-- write data to a file.
 NFSPROC_CREATE -- allows a client to create
a file in a directory.
RPC Procedures Found in
NFS








NFSPROC_REMOVE -- deletes a file.
NFSPROC_RENAME -- rename a file.
NFSPROC_LINK -- to form a hard link to an
existing file.
NFSPROC_SYMLINK -- to create a symlink.
NFSPROC_MKDIR -- to create a directory.
NFSPROC_RMDIR -- to remove a directory
NFSPROC_READDIR -- to get the contents of a
directory.
NFSPROC_STATFS -- Clients may use this call to
get information from the server on the status of
the filesystem.
References
 http://www.linuxfocus.org/English/Nove
mber2000/article164.shtml
 http://nfs.sourceforge.net/nfshowto/index.html
 http://nfs.sourceforge.net/nfshowto/security.html#CLIENT.SECURITY
 http://userpages.umbc.edu/~jack/ifsm49
8d/nfs.html
NFS Security
 NFS is layered over RPC/UDP (or TCP).
The default RPC protocol relies on IP
address for identification of server and
client. No authentication.
 NFS architecture involves many moving
parts, most of which have been implicated
repeatedly in security problems.
 Unlike windows, both server and client are
multi-user machines. Access control
requires careful planning.
Generic NFS Recommendations
 do install all NFS security patches (in particular, for SunOS, you





should get 100173-09, 100536-02, and for Solaris, 101344-11)
do configure NFS so that requests are only accepted from privileged
system programs (requires a user on a remote machine to be root
before sending NFS requests (well, unless the remote machine is
running an OS, like MSDOS, that doesn't make a distinction
between root and non- root, or if the OS doesn't require root access
to "privileged" ports, or the hacker has root...)), see: nfsd does
minimal continuing authentication, and will accept requests from
anyone with the correct filehandle)
do export file systems read-only whenever possible (this will prevent
anyone from writing to it, even if they get/guess the filehandle)
never ever ever! export a filesystem to the exporting server, or to a
netgroup which includes the server (at CCO we chose to create 3
netgroups, one for each server, that included all machines (client
and server), except for that one server)
do keep all suid code on one filesystem, export that filesystem no
root access (the default on suns), and mount all other filesystems nosuid (some OSes have a -nodev option that should be used
similarly, though some turn dev access off when you turn suid off)
put all mount options like the ones above in your automounter maps!
Generic Recommendations
 the statmon directories, used by statd to control locking services of NFS, are









often world writeable. try find /var/statmon -exec chmod o-w {} \; (not widely
exploited, this (the writeability) can be used in a denial of service attack to trick
the client daemon to thinking server's dead)
at your firewall/router, do not pass TCP port 111, UDP port 111, TCP port 2049,
or UDP port 2049 (111 is the portmapper, 2049 is nfsd) (this will protect against
outside attacks, even those which get/guess filehandles, though it does nothing
for internal attacks)
do not allow the /etc/exports file to contain a "localhost" reference (makes
spoofing more difficult)
do export only to fully qualified domain names (makes spoofing more difficult)
do not let export lists exceed 256 characters, even after expanding aliases
(some nfsd implementations will ignore an access list completely if it is bigger
than this (although, this is perhaps an outdated reference to an old Sun bug))
do check for typos (exporting to a nonexistent netgroup is equivalent to
exporting to the world)
do disable NFS completely if you don't need it
do run /usr/etc/exportfs after making changes to /etc/exports
if your portmap/rpcbins implementation allows you to, you can add some
protection by disallowing connections from outside your firewall ( though if your
firewall is penetrated, loose source routing might defeat this)
Source: http://www.cco.caltech.edu/~refguide/sheets/nfs-security.html
The Userid Problem
 Unix access control uses an integer to
identify the user.
 Access control rules are applied at the
server using credentials (the number)
supplied by the client.
 That integer is interpreted in the context of
the server’s principal->numeric id map.
 For NFS to work properly, you must
ensure that the numeric ids are consistent
between server and client.
Securing RPC
 The DIY solution: Many site admins have
resorted to running NFS through encrypted
tunnels and manually crafting export and
mount parameters to achieve acceptable
security.
 See http://www.linuxsecurity.com/feature_stories/feature_story-118.html
for a recent example.
 Side issue: use a good clock sync protocol.
File timestamps are written by the server and
read back by the client without accounting for
clock skew. Causes problems.
Securing RPC
 Sun Microsystems has had a DES-based
proprietary somewhat-secure version of
RPC out since the late 80s.
 In the late Nineties an open-source effort
got underway. Pre-release Linux code for
version 4 of NFS was released in February
2002.
 Based on a modern, negotiated-encryption
secure RPC called RPCSEC_GSS.
 See http://www.citi.umich.edu/projects/nfsv4
Securing RPC
 Secure RPC promises to solve the
client/server mutual authentication
problem but it does not, by itself, solve the
numeric ID management problem.
 Kerberos solves the distributed
identification and authentication problem
but does not provide assurance that the
client TCB is intact and configured as
server security policy requires.
The Trust Relationship
 Assuming no protocol-level attacks, the
user, client and server end up in a complex
and problematic trust relationship.
 The server is responsible to the user(s) for
the security of shared files.
 The user trusts the client to fairly represent
his/her intentions to the server.
 The server trusts the client to vouch for the
authenticity of the credentials it presents
with NFS requests.
The Trust Relationship
 When the clients and servers are all
administered together (e.g. a cluster of
compute and storage servers) this works
well. That’s the model NFS was designed
for.
 When user A has administrative control of
client A, the trust relationships of NFS are
in conflict. A request from machine A
claiming to represent user B can’t be
trusted, but the NFS protocol doesn’t know
that.
Solving the UID and Trust Problems
 Two generic solutions:
 Multi-user filesystems (e.g. /home) shared
among hosts with a single password database
and consistent security policies. Like a
Windows Domain.
 Single-user subtree exports, e.g. /home/steve,
shared only with machines controlled by that
user.
 Unfortunately, the mechanism for sharing
the password database is also RPC-based
and insecure (NIS).
Solving the UID and Trust Problems
 Using Kerberos to manage the user
identification and authentication database
helps, but there is nothing in NFS that
knows about Kerberos tickets.
 The Just-Say-No solution: run a file sharing
protocol that is integrated with a distributed
authentication and access control protocol.
See caltech link for discussion.
Conclusions
 NFS is available, efficient, and reliable.
 NFS is quite insecure in default config.
 For low-criticality information on a network
with physical security, reasonable users
and stable user/client pairings NFS can be
used when deployed with a good plan.
Good advice/sample designs widespread.
 NFS v4 will solve the RPC security
problem soon-ish.
 Mutual trust of user, client and server is a
harder problem, but can be solved
administratively in some environments.
Conclusions
 For acceptable security in a more hostile
or more critical environment with multiuser clients (e.g., university computing
labs) NFS is not secure enough.
 NFS v4 may include features to fix this,
but I don’t see anything about it in the
high-level descriptions.
 AFS was designed (at CMU) for this threat
environment. It is probably secure
enough, but it is not free and is less widely
used.