NFS Admin And Security

1. NFS Admin And Security Steve Nuchia Sravani Motati Ashish Katyarmal

2. NFS Overview Server Client / / home home usr usr bin bin c c a b a b NFS: Export Subtree Windows: Share Folder 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.

3. 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

4. /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)

5. 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

6. 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

7. 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

8. 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.

9. 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.

10. 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)

11. 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

12. 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

13. /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

14. 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.

15. 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)

16. 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 )

17. 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

18. 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.

19. 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:

21. 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.

22. 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

23. 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.

24. 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

25. 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

26. Topics • Configure NFS client • NFS Daemons • Mounting NFS volume • Files used by NFS clients • Automount daemon (AMD) • RPC procedures in NFS

27. 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 enabled.

28. NFS Daemons

29. 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

30. 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.

31. 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-/etc/exports file must exist.

32. 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_volumemount_point Example: root@helium>>mount –t nfs –o nosuid,hard,intr neon:/usr/local /usr/local

33. Mounting an NFS Volume • To mount NFS volume at Boot Time: Edit /etc/fstab on client “helium” with the entry: # volume mount point type options dump fsckorder neon:/usr/local/usr/local nfs nosuid,hard,intr 0 0 • 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

34. 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

35. 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.

36. 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.

37. 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.

38. 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.

39. 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 ] ... ]

40. 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.

41. 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.

42. 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.

43. References • http://www.linuxfocus.org/English/November2000/article164.shtml • http://nfs.sourceforge.net/nfs-howto/index.html • http://nfs.sourceforge.net/nfs-howto/security.html#CLIENT.SECURITY • http://userpages.umbc.edu/~jack/ifsm498d/nfs.html

44. 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.

45. 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!

46. 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

47. 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.

48. 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.

49. 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

50. 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.