Nfs admin and security
Download
1 / 56

NFS Admin And Security - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

NFS Admin And Security. Steve Nuchia Sravani Motati Ashish Katyarmal. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' NFS Admin And Security' - treva


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Nfs admin and security

NFS Admin And Security

Steve Nuchia

Sravani Motati

Ashish Katyarmal


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


Setting up nfs server
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 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 option221
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 option222
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 option223
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 option224
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
Example machine2(option21,option22)

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
Simplifications for the Entries machine2(option21,option22)

  • 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
Few Cautions machine2(option21,option22)

  • 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 machine2(option21,option22)

    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
Security through daemons machine2(option21,option22)

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
Steps machine2(option21,option22)

  • 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
Steps (continued) machine2(option21,option22)

  • 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 )


Example1
Example machine2(option21,option22)

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
Getting the services started machine2(option21,option22)

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:


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 then we can start the daemons in order to run NFS services.

    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
Making Changes to the /etc/exports scripts, then we need to add them, configured to start in the following order:

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
Topics scripts, then we need to add them, configured to start in the following order:

  • Configure NFS client

  • NFS Daemons

  • Mounting NFS volume

  • Files used by NFS clients

  • Automount daemon (AMD)

  • RPC procedures in NFS


Configuring nfs client
Configuring NFS Client scripts, then we need to add them, configured to start in the following order:

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


Nfs daemons
NFS Daemons scripts, then we need to add them, configured to start in the following order:


Starting nfs daemons
Starting NFS Daemons scripts, then we need to add them, configured to start in the following order:

  • 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 daemons1
Starting NFS Daemons scripts, then we need to add them, configured to start in the following order:

  • 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 daemons2
Starting NFS Daemons scripts, then we need to add them, configured to start in the following order:

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.


Mounting an nfs volume
Mounting an NFS Volume scripts, then we need to add them, configured to start in the following order:

  • 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:

    [email protected]>>mount –t nfs –o nosuid,hard,intr neon:/usr/local /usr/local


Mounting an nfs volume1
Mounting an NFS Volume scripts, then we need to add them, configured to start in the following order:

  • 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


Mount options
Mount options scripts, then we need to add them, configured to start in the following order:

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
option scripts, then we need to add them, configured to start in the following order: ’-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 nfs1
option scripts, then we need to add them, configured to start in the following order: ’-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
Mount Options for Client Security scripts, then we need to add them, configured to start in the following order:

  • 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
Files Used by NFS Clients scripts, then we need to add them, configured to start in the following order:

  • /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
Automount Daemon scripts, then we need to add them, configured to start in the following order:

  • 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 daemon1
Automount Daemon scripts, then we need to add them, configured to start in the following order:

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
RPC Procedures Found in NFS scripts, then we need to add them, configured to start in the following order:

  • 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 nfs1
RPC Procedures Found in NFS scripts, then we need to add them, configured to start in the following order:

  • 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
References scripts, then we need to add them, configured to start in the following order:

  • 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


Nfs security
NFS Security scripts, then we need to add them, configured to start in the following order:

  • 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
Generic NFS Recommendations scripts, then we need to add them, configured to start in the following order:

  • 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
Generic Recommendations scripts, then we need to add them, configured to start in the following order:

  • 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
The Userid Problem scripts, then we need to add them, configured to start in the following order:

  • 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
Securing RPC scripts, then we need to add them, configured to start in the following order:

  • 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 rpc1
Securing RPC scripts, then we need to add them, configured to start in the following order:

  • 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 rpc2
Securing RPC scripts, then we need to add them, configured to start in the following order:

  • 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
The Trust Relationship scripts, then we need to add them, configured to start in the following order:

  • 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 relationship1
The Trust Relationship scripts, then we need to add them, configured to start in the following order:

  • 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
Solving the UID and Trust Problems scripts, then we need to add them, configured to start in the following order:

  • 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 scripts, then we need to add them, configured to start in the following order:

  • 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
Conclusions scripts, then we need to add them, configured to start in the following order:

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


Conclusions1
Conclusions scripts, then we need to add them, configured to start in the following order:

  • For acceptable security in a more hostile or more critical environment with multi-user 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.


ad