Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Solaris Network File System (NFS)

NFS is a network filesystem originally developed by Sun (version 2, see RFC1094) and later enhanced by Network Appliance and other companies (version 3 and 4 of NFS). It works well for sharing file systems between multiple clients but is slower then some other network filesystems (samba). It is also more fault tolerant then most other network file systems.

NFS is based on a client-server model. One computer works as a server and offers filesystems to other systems. This is called exporting or sharing and the filesystems offered are called "exports." The clients can mount server exports using an extension of  mount command used to mount local filesystems. File systems shared through NFS software can also be mounted automatically. Autofs, a client-side service, is a change directory intercept mechanism that catches the cases when user changes to NFS directory and transparently mounts it.  the list of mount points should be provided to Autofs as a configuration file. Essentially any i/o operation on s program notifies the automount daemon, automountd,  and it mounts it and then if there is long period of inactivity unmounts it. The automountd, daemon transparently performs mounting and unmounting of remote directories listed it Autofs configuration file on an as-needed basis.

NFS is platform independent because it defines an abstract model of a file system. Each OS  including Windows can applies the NFS model to its file system semantics and implement reading and writing operations as though they are accessing a local file.  NFS is also statelessness. You can reboot a server and the client won't crash. It won't be able to access files on the server's export while the server is down, but once it returns, you'll pick up right where things left off. Other network file sharing systems are not so resilient.

The benefits of the NFS service are that it:

• Allows multiple computers to use the same files, so everyone on the network can access the same data
• Reduces storage costs by having computers share applications instead of needing local disk space for each user application
• Provides data consistency and reliability because all users can read the same set of files
• Makes mounting of file systems transparent to users
• Makes accessing remote files transparent to users
• Supports heterogeneous environments
• Reduces system administration overhead

The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local ones.

Writable NFS-sharable file systems should generally be a separate disk or partition (on server). By having file systems on a separate partition of a harddisk, we can ensure that malicious users can not simply fill up the entire harddisk by writing large files onto it. This will then be able to crash other services running on the same harddisk. Prevent normal users on an NFS client from mounting an NFS file system (on server)

NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than 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 can only allow read-only access or squashing users to a common user and groupid. But these solutions may 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. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.

Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.

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 userid value mount the same NFS file system, they will be able to 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.

The default behavior when exporting a file system via NFS is to use root squashing. This sets the userid of anyone accessing the NFS share as the root user on their local machine to a value of the server's nobody account. Never turn off root squashing.

If exporting an NFS share read-only, consider using the all_squash option, which makes every user accessing the exported file system take the userid of the nobody user.

Before file systems or directories can be accessed (that is, mounted) by a client through NFS, they must be shared or  exported Once shared, authorized NFS clients can mount the resources. This term most often reflected in directory names for NFS resources such as /export/home or /export/swap.

To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. 

You need several daemons to support NFS activities. These daemons can support both NFS client and NFS server activity, NFS server activity alone, or logging of the NFS server activity. To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. There are six daemons that support NFS:

1. mountd Handles file system mount requests from remote systems, and provides access control (server)
2. nfsd Handles client file system requests (both client and server)
3. statd Works with the lockd daemon to provide crash recovery functions for the lock manager (server)
4. lockd Supports record locking operations on NFS files
5. nfslogd  Provides filesystem logging. Runs only if one or more filesystems is mounted with log attribute.

You can detect most NFS problems from console messages or from certain symptoms that appear on a client system. Some common errors are:

1. The rpcbind failure error incorrect host Internet address or server overload
    
2. The server not responding error network connection or server is down
    
3. The NFS client fails a reboot error a client is requesting an NFS mount using an entry in the /etc/vfstab file, specifying a foreground mount from a non-operational NFS server.
    
4. The service not responding error an accessible server is not running the NFS server daemons.
    
5. The program not registered error  an accessible server is not running the mountd daemon.
    
6. The stale file handle error [file moved on the server]. To solve the stale NFS file handle error condition, unmount and mount the resource again on the client.
    
7. The unknown host error the host name of the server on the client is missing from the hosts table.
    
8. The mount point error check that the mount point exists on the client
    
9. The no such file error unknown file name on the server
    
10. No such file or directory  the directory does not exists on the server

NFS Server Commands

• share Makes a local directory on an NFS server available for mounting. Without parameters displays the contents of the
  /etc/dfs/sharetab file.
• unshare Makes a previously available directory unavailable for client side mount operations.
• shareall Reads and executes share statements in the /etc/dfs/dfstab file.
• unshareall Makes previously shared resources unavailable.
• dfshares Lists available shared resources from a remote or local NFS server.
• dfmounts Displays a list of NFS server directories that are currently mounted.

NFS resources can be shared using the share command and unshared using the unshare command. In addition, any resources identified in the /etc/dfs/dfstab file are automatically shared at system boot or when the shareall command is used. Shared resources are automatically recorded in the /etc/dfs/sharetab file. When the unshareall command is used, all resources listed in the /etc/dfs/sharetab file are automatically unshared.

The share command is used to share NFS resources so that NFS clients can mount and access them. At a minimum, the full pathname of the directory (or mount point of the file system) to be shared is specified as a command-line argument. In addition, three other command-line arguments are supported:

• The -d command-line argument is followed by a description of the data being shared.

• The -F nfs command-line argument is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed.

• The -o command-line argument is followed by one or more NFS-specific options (separated by commas).

For example:

# share -F nfs -o public,ro /export/home

The unshare command is used to stop the sharing of NFS resources so that NFS clients can no longer mount and access them. At a minimum, the full pathname of a directory (or mount point of the file system) that is currently shared is specified as a command-line argument.

Only one other command-line argument is supported: the -F nfs command-line argument, which is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed.

The following listing shows using the unshare command to stop the sharing of the /export/home file system:

# unshare -F nfs /export/home

Solaris uses six configuration files to support NFS server: Three common, one specific for client and two specific for the server

NFS Logging  is accomplished by nfslogd  daemon with the configuration stored in /etc/nfs/nfslog.conf and  /etc/default/nfslogd. The functions of the nfslogd daemon:

• Converts the raw data from the logging operation into ASCII records, and stores the raw data in ASCII log files.
• Resolves IP addresses to host names and UIDs to login names.
• Maps the file handles to path names, and records the mappings in a file-handle-to-path mapping table. Each tag in the /etc/nfs/nfslog.conf file corresponds to one mapping table.

The NFS Logging Daemon monitors and analyzes RPC operations processed by the NFS server. If enabled, each RPC operation is stored in the NFS log file as a record that contains:

• Time stamp

• IP address or hostname of client

• File or directory affected by operation

• Type of operation: input, output, make directory, remove directory, or remove file

The NFS server logging consists of two phases. The first phase is performed by the kernel; it records RPC requests in a work buffer. The second phase is performed by the daemon; it reads the work buffer, constructs and writes the log records. The amount of time the daemon waits before reading the work buffer along with other configurable parameters are specified in the /etc/default/nfslogd file. /etc/default/nfslogd file can contain a number of parameters (the initial nfslogd provided with the Solaris 9 system contains only comments):

• CYCLE_FREQUENCY— Amount of time (in hours) of the log cycle (close current log and open new one). This is to prevent the logs from getting too large.

• IDLE_TIME— Amount of time (in seconds) that the logging daemon will sleep while waiting for data to be placed in the work buffer.

• MAPPING_UPDATE_INTERVAL— The amount of time (in seconds) between updates of the file handle to pathname mapping database.

• MAX_LOGS_PRESERVE— The maximum number of log files to save.

• MIN_PROCESSING_SIZE— Minimum size (in bytes) of the work buffer before the logging daemon will process its contents.

• PRUNE_TIMEOUT— The amount of time (in hours) the access time of a file associated with a record in the pathname mapping database can remain unchanged before it is removed.

• UMASK— umask used for the work buffer and file handle to pathname mapping database.

The /etc/nfs/nfslog.conf file is used to specify the location of log files, file handle to pathname mapping database, and work buffer, along with a few other parameters.  Set of parameters can be grouped together and associated with a tag. this way multiple configurations can be specified in the configuration file. The default configuration has the tag global . the following NFS logging parameters can be set:

• buffer— Specifies location of working buffer.

• defaultdir— Specifies the default directory of files. If specified, this path is added to the beginning of other parameters that are used to specify the location of files.

• fhtable— Specifies location of the file handle to pathname mapping database.

• log— Specifies location of log files.

• logformat— Specifies either basic (default) or extended logging.

For example:

#ident  "@(#)nfslog.conf        1.5     99/02/21 SMI"
#
# Copyright (c) 1999 by Sun Microsystems, Inc.
# All rights reserved.
#
# NFS server log configuration file.
#
# <tag> [ defaultdir=<dir_path> ] \
# [ log=<logfile_path> ] [ fhtable=<table_path> ] \
# [ buffer=<bufferfile_path> ] [ logformat=basic|extended ]
#

global  defaultdir=/var/nfs log=nfslog fhtable=fhtable buffer=nfslog_workbuffer

Logging is enabled on a per-share (file system/directory) basis, by adding the -o log option to the share command. 

Note:

• The configuration file that controls the number of NFS logs created and the permissions on the log files is named atypically:  /etc/default/nfslogd

Notes: Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected. This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books. The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Search Amazon by keywords:     Open directory Research Index

Old News ;-)

Managing NFS[tm] Workloads (April 1999) by Richard McDougall, Adrian Cockcroft and Evert Hoogendoorn

Demonstration of the usage and management of NFS.

NFSv4 delivers seamless network access

A word of caution

After you have used NFS to mount a remote file system, that system will also be part of any total system backup that you perform on the client system. This behavior can have potentially disastrous results if you don't exclude the newly mounted directories from the backup.

To use NFS as a client, the client computer must be running rpc.statd and portmap. You can run a quick ps -ef to check for these two daemons. If they are running (and they should be), you can mount the server's exported directory with the generic command:

mount server:directory local mount point

 

Generally speaking, you must be running under root to mount a file system. From a remote computer, you can use the following command (assume that the NFS server has an IP address of 192.168.0.100):

mount 192.168.0.100:/opt/files /mnt

Your distribution may require you to specify the file system type when mounting a file system. If so, run the command:

mount -t nfs 192.168.0.100:/opt/files /mnt

The remote directory should mount without issue if you've set up the server side correctly. Now, run the cd command to the /mnt directory, then run the ls command to see the files. To make this mount permanent, you must edit the /etc/fstab file and create an entry similar to the following:

192.168.0.100:/opt/files /mnt nfs rw 0 0

Note: Refer to the fstab man page for more information on /etc/fstab entries.

[ Sep 12, 2006] NFSv4 delivers seamless network access by Frank Pohlmann & Kenneth Hess

...Distributed file system access, therefore, needs rather more than a couple of commands enabling users to mount a directory on a computer networked to theirs. Sun Microsystems faced up to this challenge a number of years ago when it started propagating something called Remote Procedure Calls (RPCs) and NFS.

The basic problem that Sun was trying to solve was how to connect several UNIX computers to form a seamless distributed working environment without having to rewrite UNIX file system semantics and without having to add too many data structures specific to distributed file systems. Naturally, it was impossible for a network of UNIX workstations to appear as one large system: the integrity of each system had to be preserved while still enabling users to work on a directory on a different computer without experiencing unacceptable delays or limitations in their workflow.

To be sure, NFS does more than facilitate access to text files. You can distribute "runnable" applications through NFS, as well. Security procedures serve to shore up the network against the malicious takeovers of executables. But how exactly does this happen?

NFS is RPC

NFS is traditionally defined as an RPC application requiring TCP for the NFS server and either TCP or another network congestion-avoiding protocol for the NFS client. The Internet Engineering Task Force (IETF) has published the Request for Comments (RFC) for RPCs in RFC 1832. The other standard vital to the functioning of an NFS implementation describes data formats that NFS uses; it has been published in RFC 1831 as the "External Data Representation" (XDR) document.

Other RFCs are relevant to security and the encryption algorithms used to exchange authentication information during NFS sessions, but we focus on the basic mechanisms first. One protocol that concerns us is the Mount protocol, which is described in Appendix 1 of RFC 1813.

This RFC tells you which protocols make NFS work, but it doesn't tell you how NFS works today. You've already learned something important by knowing that NFS protocols have been documented as IETF standards. While the latest NFS release was stuck at version 3, RPCs had not progressed beyond the informational RFC stage and thus were perceived as an interest largely confined to Sun Microsystems' admittedly huge engineering task force and proprietary UNIX variety. Sun NFS has been around in several versions since 1985 and, therefore, predates most current file system flavors by several years. Sun Microsystems turned over control of NFS to the IETF in 1998, and most NSF version 4 (NFSv4) activity occurred under the latter's aegis.

So, if you're dealing with RPC and NFS today, you're dealing with a version that reflects the concerns of companies and interest groups outside Sun's influence. Many Sun engineers, however, retain a deep interest in NFS development

NFS version 3

NFS in its version 3 avatar (NFSv3) was not stateful: NFSv4 is. This fundamental statement is unlikely to raise any hackles today, although the TCP/IP world on which NFS builds has mostly been stateless -- a fact that has helped traffic analysis and security software companies do quite well for themselves.

NFSv3 had to rely on several subsidiary protocols to seamlessly mount directories on remote computers without becoming too dependent on underlying file system mechanisms. NFS has not always been successful in this attempt. To give you a better example, the Mount protocol called the initial file handle, while the Network Lock Manager protocol addressed file locking. Both operations required state, which NFSv3 did not provide. Therefore, you have complex interactions between protocol layers that do not reflect similar data-flow mechanisms. Now, if you add the fact that file and directory creation in Microsoft® Windows® works very differently from UNIX, matters become rather complicated.

NFSv3 had to use several ports to accommodate some of its subsidiary protocols, and you get a rather complex picture of ports and protocol layers and all their attendant security concerns. Today, this model of operation has been abandoned, and all operations that subsidiary protocol implementations previously executed from individual ports are now handled by NFSv4 from a single, well-known port.

NFSv3 was also ready for Unicode-enabled file system operation -- an advantage that until the late 1990s had to remain fairly theoretical. In all, it mapped well to UNIX file system semantics and motivated competing distributed file system implementations like AFS and Samba. Not surprisingly, Windows support was poor, but Samba file servers have since addressed file sharing between UNIX and Windows systems.

NFS version 4

NFSv4 is, as we pointed out, stateful. Several radical changes made this behavior possible. We already mentioned that subsidiary protocols must be called, as user-level processes have been abandoned. Instead, every file-opening operation and quite a few RPC calls are turned into kernel-level file system operations.

All NFS versions defined each unit of work in terms of RPC client and server operations. Each NFSv3 request required a fairly generous number of RPC calls and port-opening calls to yield a result. Version 4 simplifies matters by introducing a so-called compound operation that subsumed a large number of file system object operations. The immediate effect is, of course, that far fewer RPC calls and data have to traverse the network, even though each RPC call carries substantially more data while accomplishing far more. It is estimated that NFSv3 RPC calls required five times the number of client-server interactions that NFSv4 compound RPC procedures demand.

RPC is not really that important anymore and essentially serves as a wrapper around the number of operations encapsulated within the NFSv4 stack. This change also makes the protocol stack far less dependent on the underlying file system semantics. But the changes don't mean that the file system operations of other operating systems were neglected: For example, Windows shares require stateful open calls. Statefulness not only helps traffic analysis but, when included in file system semantics, makes file system operations much more traceable. Stateful open calls enable clients to cache file data and state -- something that would otherwise have to happen on the server. In the real world, where Windows clients are ubiquitous, NFS servers that work seamlessly and transparently with Windows shares are worth the time you'll spend customizing your NFS configuration.

Using NFS

NFS setup is generically similar to Samba. On the server side, you define file systems or directories to export, or share; the client side mounts those shared directories. When a remote client mounts an NFS-shared directory, that directory is accessed in the same way as any other local file system. Setting up NFS from the server side is an equally simple process. Minimally, you must create or edit the /etc/exports file and start the NFS daemon. To set up a more secure NFS service, you must also edit /etc/hosts.allow and /etc/hosts.deny. The client side of NFS requires only the mount command. For more information and options, consult the Linux® man pages.

The NFS server

Entries in the /etc/exports file have a straightforward format. To share a file system, edit the /etc/exports file and supply a file system (with options) in the general format:

directory (or file system) client1 (option1, option2) client2 (option1, option2)

 

General options

Several general options are available to help you customize your NFS implementation. They include:

• secure: This option -- the default -- uses available TCP/IP ports below 1024 for NFS connections. Specifying insecure disables this option.
• rw: This option allows NFS clients read/write access. The default option is read only.
• async: This option may improve performance, but it can also cause data loss if you restart the NFS server without first performing a clean shutdown of the NFS daemon. The default setting is sync.
• no_wdelay: This option turns off the write delay. If you set async, NFS ignores this option.
• nohide: If you mount one directory over another, the old directory is typically hidden or appears empty. To disable this behavior, enable the hide option.
• no_subtree_check: This option turns off subtree checking, which performs some security checks that you may not want to bypass. The default option is to have subtree checks enabled.
• no_auth_nlm: This option, also specified as insecure_locks, tells the NFS daemon not to authenticate locking requests. If you're concerned about security, avoid this option. The default option is auth_nlm or secure_locks.
• mp (mountpoint=path): By explicitly declaring this option, NSF requires that the exported directory be mounted.
• fsid=num: This option is typically used in NFS failover scenarios. Refer to the NFS documentation if you want to implement NFS failover.

User mapping

Through user mapping in NFS, you can grant pseudo or actual user and group identity to a user working on an NFS volume. The NFS user has the user and group permissions that the mapping allows. Using a generic user and group for NFS volumes provides a layer of security and flexibility without a lot of administrative overhead.

User access is typically "squashed" when using files on an NFS-mounted file system, which means that a user accesses files as an anonymous user who, by default, has read-only permissions to those files. This behavior is especially important for the root user. Cases exist, however, in which you want a user to access files on a remote system as root or some other defined user. NFS allows you to specify a user -- by user identification (UID) number and group identification (GID) number -- to access remote files, and you can disable the normal behavior of squashing.

User mapping options include:

• root_squash: This option doesn't allow root user access on the mounted NFS volume.
• no_root_squash: This option allows root user access on the mounted NFS volume.
• all_squash: This option, which is useful for a publicly accessible NFS volume, squashes all UIDs and GIDs and only uses the anonymous account. The default setting is no_all_squash.
• anonuid and anongid: These options change the anonymous UIDs and GIDs to specific user and group accounts.

Listing 1 shows examples of /etc/exports entries.

Listing 1. Example /etc/exports entries
 

/opt/files 192.168.0.* /opt/files 192.168.0.120 /opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100) /opt/files *(ro, insecure, all_squash)

 

The first entry exports the /opt/files directory to all hosts in the 192.168.0 network. The next entry exports /opt/files to a single host: 192.168.0.120. The third entry specifies host 192.168.0.125 and grants read/write access to the files with user permissions of user id=210 and group id=100. The final entry is for a "public" directory that has read-only access and allows access only under the anonymous account.

The NFS client

A word of caution   After you have used NFS to mount a remote file system, that system will also be part of any total system backup that you perform on the client system. This behavior can have potentially disastrous results if you don't exclude the newly mounted directories from the backup.

To use NFS as a client, the client computer must be running rpc.statd and portmap. You can run a quick ps -ef to check for these two daemons. If they are running (and they should be), you can mount the server's exported directory with the generic command:

mount server:directory local mount point

 

Generally speaking, you must be running under root to mount a file system. From a remote computer, you can use the following command (assume that the NFS server has an IP address of 192.168.0.100):

mount 192.168.0.100:/opt/files /mnt

 

Your distribution may require you to specify the file system type when mounting a file system. If so, run the command:

mount -t nfs 192.168.0.100:/opt/files /mnt

 

The remote directory should mount without issue if you've set up the server side correctly. Now, run the cd command to the /mnt directory, then run the ls command to see the files. To make this mount permanent, you must edit the /etc/fstab file and create an entry similar to the following:

192.168.0.100:/opt/files /mnt nfs rw 0 0

 

Note: Refer to the fstab man page for more information on /etc/fstab entries.

Criticism drives improvement
 

Criticisms leveled at NFS security have been at the root of many improvements in NSFv4. The designers of the new version took positive measures to strengthen the security of NFS client-server interaction. In fact, they decided to include a whole new security model.

To understand the security model, you should familiarize yourself with something called the Generic Security Services application programming interface (GSS-API) version 2, update 1. The GSS-API is fully described in RFC 2743, which, unfortunately, is among the most difficult RFCs to understand.

We know from our experience with NFSv4 that it's not easy to make the network file system operating system independent. But it's even more difficult to make all areas of security operating systems and network protocols independent. We must have both, because NFS must be able to handle a fairly generous number of user operations, and it must do so without much reference to the specifics of network protocol interaction.

Connections between NFS clients and servers are secured through what has been rather superficially called strong RPC security. NFSv4 uses the Open Network Computing Remote Procedure Call (ONCRPC) standard codified in RFC 1831. The security model had to be strengthened, and instead of relying on simple authentication (known as AUTH_SYS), a GSS-API-based security flavor known as RPCSEC_GSS has been defined and implemented as a mandatory part of NFSv4. The most important security mechanisms available under NFSv4 include Kerberos version 5 and LIPKEY.

Given that Kerberos has limitations when used across the Internet, LIPKEY has the pleasant advantage of working like Secure Sockets Layer (SSL), prompting users for their user names and passwords, while avoiding the TCP dependence of SSL -- a dependence that NFSv4 doesn't share. You can set NFS up to negotiate for security flavors if RPCSEC_GSS is not required. Past NFS versions did not have this ability and therefore could not negotiate for the quality of protection, data integrity, the requirement for authentication, or the type of encryption.

NFSv3 had come in for a substantial amount of criticism in the area of security. Given that NFSv3 servers ran on TCP, it was perfectly possible to run NFSv3 networks across the Internet. Unfortunately, it was also necessary to open several ports, which led to several well-publicized security breaches. By making port 2049 mandatory for NFS, it became possible to use NFSv4 across firewalls without having to pay too much attention to what ports other protocols, such as the Mount protocol, were listening to. Therefore, the elimination of the Mount protocol had multiple positive effects:

• Mandatory strong authentication mechanisms: NFSv4 makes strong authentication mechanisms mandatory. Kerberos flavors are fairly common, and Lower Infrastructure Public Key Mechanism (LIPKEY) must be supported, as well. NFSv3 never supported much more than UNIX-style standard encryption to authenticate access -- something that led to major security problems in large networks.
• Mandatory Microsoft Windows NT-style access control list (ACL) schemes: Although NFSv3 allowed for strong encryption for authentication, it did not push Windows NT-style ACL access schemes. Portable Operating System Interface (POSIX)-style ACLs were sometimes implemented but never widely adopted. NFSv4 makes Windows NT-style ACL schemes mandatory.
• Negotiated authentication styles and mechanisms: NFSv4 makes it possible to negotiate authentication styles and mechanisms. Under NSFv3, it was impossible to do much more than determine manually which encryption styles were used. The system administrator then had to harmonize encryption and security protocols.

Is NFS still without peers?

NFSv4 is replacing NFSv3 on most UNIX and Linux systems. As a network file system, NSFv4 has few competitors. The Common Internet File System (CIFS)/Server Message Block (SMB) could be considered a viable competitor given that it's native to all Windows varieties and (today) to Linux. AFS never made much commercial impact, and it emphasized elements of distributed file systems that made data migration and replication easier.

Production-ready Linux versions of NFS had been around since the kernel reached version 2.2, but one of the more common failings of Linux kernel versions was the fact that Linux adopted NFSv3 fairly late. In fact, it took a long time before Linux fully supported NSFv3. When NSFv4 came along, this lack was addressed quickly, and it wasn't just Solaris, AIX, and FreeBSD that enjoyed full NSFv4 support.

NFS is considered a mature technology today, and it has a fairly big advantage: It's secure and usable, and most users find it convenient to use one secure logon to access a network and its facilities, even when files and applications reside on different systems. Although this might look like a disadvantage compared to distributed file systems, which hide system structures from users, don't forget that many applications use files from different operating systems and, therefore, computers. NFS makes it easy to work on different operating systems without having to worry too much about the file system semantics and their performance characteristics.

Resources

Learn

• The main NFSv4 portal contains links to all technical documents and RFCs for NFSv4.
   
• Distributed file systems need a bit more effort to understand. Find the information you need at Wikipedia.
• RFC 1832 outlines the XDR standard.
• RFC 1831 outlines the RPC standard.
• RFC 1813, Appendix I: Mount protocol outlines the now-obsolete Mount protocol.
• RFC 2743 outlines the GSS-API.

Get products and technologies

• OpenAFS is the open source version of AFS, another distributed file system.
• SAMBA can be regarded as a file system and can fulfill some of the roles of NFS.

[Aug 1, 2006] Network Appliance - The Evolution of NFS by Dave Hitz & Andy Watson, Network Appliance, Inc.

1. NFS changes since 1985

• Close-to-Open File Consistency
• Automounter
• Performance Improvements
  • Non-Volatile RAM to Improve Write Performance
  • Dynamic Retry Time Adjustment
  • Improved Retry Cache Heuristics
  • Client Side Disk Caching

2. NFSv3

• 64-bit File Sizes
• Performance Improvements
  • Large Block Transfers (greater than 8 KB)
  • Safe Asynchronous Writes
  • Improved Attribute Returns
  • Readdirplus

3. Other Recent Changes and Future Possibilities

• NFS Over TCP
• Kerberized NFS
• RSA Encryption
• WebNFS

4. Conclusion

NFS version 3 (NFSv3) arrived almost exactly ten years after Sun Microsystems originally introduced NFS. This leaves some people wondering: What took so long? Will it be another ten years before NFS gets another fresh coat of paint?

In part, these questions reflect a conflation between NFS-the- protocol and NFS-the-implementation. While the NFS protocol itself remained unchanged until NFSv3, NFS implementations have changed substantially in the past ten years, and they will continue to change in the future even without another protocol revision.

The menu below outlines the evolution of NFS and reflects the sequence of topics discussed in this document.

Many people are surprised that a protocol can change so much without a protocol revision. The NFS specification RFC 1094 defines the exact format of NFS packets transmitted over the network, but it leaves great flexibility in the hardware and software that actually send the packets. In addition, a protocol can have some flexibility designed in from the start.

For instance, NFS implementations have traditionally used UDP for remote procedure calls (RPC), but the RPC specification allows either UDP or TCP. Finally, services such as the automounter can be added to improve NFS without any change at all to the protocol or its implementation.

SRP Open-Source Password Security

The Secure Remote Password protocol is the core technology behind the Stanford SRP Authentication Project. The Project is an Open Source initiative that integrates secure password authentication into new and existing networked applications.

The Project's primary purpose is to improve password security by making strong password authentication technology a standard part of deployed real-world systems. This is accomplished by making this technology an easy-to-use, hassle-free alternative to weak and vulnerable legacy password authentication schemes. SRP makes these objectives possible because it offers a unique combination of password security, user convenience, and freedom from restrictive licenses.

This site serves as the semi-official home of the SRP distribution, which contains secure versions of Telnet and FTP. In addition, it contains links to a number of SRP-related projects, products (both commercial and non-commercial), and research on the Web.

[Jun 2, 2002] CITI Projects NFS Version 4 Open Source Reference Implementation

This work was done as part of the NFS Version 4 Open Source Reference Implementation project. This release includes preliminary support for acl's and for kerberos authentication, and is in the form of a patch against the linux 2.4.18 kernel, with cryptoapi and acl patches already applied.

IBM Redbooks Securing NFS in AIX An Introduction to NFS v4 in AIX 5L Version 5.3

NFS Version 4 (NFS V4) is the latest defined client-to-server protocol for NFS. A significant upgrade from NFS V3, it was defined under the IETF framework by many contributors. NFS V4 introduces major changes to the way NFS has been implemented and used before now, including stronger security, wide area network sharing, and broader platform adaptability.

This IBM Redbook is intended to provide a broad understanding of NFS V4 and specific AIX NFS V4 implementation details. It discusses considerations for deployment of NFS V4, with a focus on exploiting the stronger security features of the new protocol.

In the initial implementation of NFS V4 in AIX 5.3, the most important functional differences are related to security. Chapter 3 and parts of the planning and implementation chapters in Part 2 cover this topic in detail.

SUMMARY NFS Security in Solaris 8

Bhavesh Shah bshah at citadon.com
Thu Apr 8 18:12:54 EDT 2004

• Previous message: SUMMARY : Sol9 - VxVM 3.5 : Log plex problem after disk replacement
• Next message: SUMMARY: NIS map transfer problems
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Thanks to all who replied:

Darren Dunham

Anatoliy Lisovskiy

Driddick

Mark Cain

Special Thanks to Darren Dunham which pointed me to the right direction
towards solving the problem quickly.

Solution was:

Reverse lookup was not setup correctly in DNS. Once that done everything
started working with FQDN.


My Original Question was


Hi Gurus,

I have a NFS Security question:

I am running Solaris 8.

Following is my /etc/dfs/dfstab entry:

/usr/sbin/share -F nfs -o rw=host1:host2,anon=0,ro /dir



even then host1 or host2 can not have write access to /dir

if I try to touch a file to host1 or host2 it gives an obvious  error
:"touch: test cannot create"

but if I replace host1 and host2 with ip addresses everything works
fine.

I can ping to host1 and host2 from NFS Server box. Was wondering how
that can happen?

I changed nsswitch.conf to search for dns first and then files but no
success.

I guess there is some configuration problem on NFS Server.

Any Help will be greatly appreciated.

Thanks in advance

B

NFS Maestro support for Solaris NFS security modes

NFS Maestro support for Solaris NFS security modes

PROBLEM

Solaris 8 "man" page for nfssec.
It discusses the different security modes in Solaris available for NFS.
If you would like to use DES (dh) security mode, which involves public/private key authentication, and would like to know how to configure this with NFS Maestro.

SOLUTION

AUTH_DH protocol - also known as Secure RPC - provides a secure means of communication between two parties across an insecure network.
In general, the communication is between a client (a user logged into one host) and a server.
AUTH_DES uses Data Encryption Standard (DES) credentials for authentication.

To use NIS+ with NFS Maestro AUTH_DH/AUTH_DES
 

1. Configure NIS+ in Hummingbird Directory Services
   • In the Directory Service dialog box, select NIS+
   • Click on Change and enter :
     NIS+ Domain:
     Secure RPC password:
     NOTE: User Name dialog box appears only if you are using the user profile.
     Then click OK.
      
   • In the General tab, you will see ( greyed out): NIS+ Profile Name:
     Domain Name:
     Root Master:
     Netname: unix.yourpcname@domainname.com
     NIS+ Server Query Order: nis+master and nis+replicas ( these can be moved up or down)
     Then click OK.
      
   • When you launch NFS Network Access the first time, you will get the NIS+ Keylogin window with:
     Username: Administrator
     Passwd:
     Please change Administrator username to your pc name, then enter the passwd ( Secure RPC password for the machine).
     If the information is correct, you can then use NFS Network Access to mount to your filesystem.
      
2. Next, export your unix resources.
   If you look in the NOTES sections of the man page for share_nfs, you can export your unix resources using sec=dh option to indicate AUTH_DH.

   For example: share -F nfs -o sec=dh /export/home/users/ken
   
   NOTE: Make sure there is no conflicting information in the exports file, for example:
   share -F nfs /export/home/users
   share -F nfs -o sec=dh /export/home/users/ken
   
    

3. Not all NFS servers support the authentication protocols in NFS Maestro Client.
   Many of the free UNIX operating systems do not support AUTH_DES or RPCSEC_GSS.
   For information about Sun Enterprise Authentication Mechanism, see:
   
   http://wwws.sun.com/software/solaris/8/ds/ds-seam
   
   Please ensure your NFS server supports the desired security protocol before attempting to connect from NFS Maestro.
   
    
4. The AUTH_DES authentication protocol is very dependent on client and server time synchronization.
   The transaction time "window" between client and server is 60 seconds. This means that all NFS transactions must occur within in this time differential, otherwise they are silently discarded.
   If the clock on the NFS server is running fast, and the clock on the client is running slow by 60 seconds, the NFS connection fails.

For information about Network Time Protocol - Version 3, see:

http://www.ccd.bnl.gov/xntp/

It is recommended that the server use a Network Time Protocol server (bundled with, or available for, most UNIX operating systems) to synchronize all hosts on the local network.

You can use the Hummingbird bundled Network Time applet to synchronize PC time to the server time.
To launch the applet:
 

1. Click on START
2. Highlight Programs
3. Highlight Hummingbird Connectivity 8.00
4. Highlight Accessories
5. Select Network Time from the listing.
6. Then click on the HOST button to configure the applet and enter the server name.

ACTION:

For the definition, please refer to:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q115873

For the workaround, please refer to:
http://www.jsifaq.com/SUBA/tip0000/rh0036.htm

The making of NFSv4

NFSv4

If you use NFS (Network File System) to share file systems between multiple computers, you are probably using NFS Version 2 or 3. However, you should know that NFSv4 is under active development and is available for trial use under a variety of operating systems.

NFSv4 offers numerous advantages over NFSv2 and NFSv3, including dealing with a variety of security issues mentioned in RFC2623 ("NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," http://www.ietf.org/rfc/rfc2623.txt ).

Those of you currently running NFS v2 or NFS v3 may also be interested in the other NFS security references mentioned below.

References

1. NFS Version 4: http://nfsv4.org/
    
2. Network Appliance—The NFS Version 4 Protocol (nice introduction): http://www.netapp.com/tech_library/3085.html
    
3. CITI Projects: NFS Version 4 Open Source Reference Implementation: http://www.citi.umich.edu/projects/nfsv4/
    
4. Learning NFSv4 With Fedora Core 2: http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html
    
5. CERT Advisory CA-1994-15 NFS Vulnerabilities: http://www.cert.org/advisories/CA-1994-15.html
    
6. NFS Security: http://www.linuxsecurity.com/feature_stories/feature_story-118.html
    
7. Security and NFS: http://nfs.sourceforge.net/nfs-howto/security.html
    
8. Secure NFS and NIS via SSH Tunnel: http://www.math.ualberta.ca/imaging/snfs/

Recommended Links

Network File System - Wikipedia, the free encyclopedia

Yahoo! NFS page

NFS - PC Webopaedia Definition and Links

IBM/System Management Guide Communications and Networks - NFS Reference

***** IBM Redbooks Securing NFS in AIX An Introduction to NFS v4 in AIX 5L Version 5.3

NFS Version 4 (NFS V4) is the latest defined client-to-server protocol for NFS. A significant upgrade from NFS V3, it was defined under the IETF framework by many contributors. NFS V4 introduces major changes to the way NFS has been implemented and used before now, including stronger security, wide area network sharing, and broader platform adaptability.

This IBM Redbook is intended to provide a broad understanding of NFS V4 and specific AIX NFS V4 implementation details. It discusses considerations for deployment of NFS V4, with a focus on exploiting the stronger security features of the new protocol.

In the initial implementation of NFS V4 in AIX 5.3, the most important functional differences are related to security. Chapter 3 and parts of the planning and implementation chapters in Part 2 cover this topic in detail.

The NFS Version 4 Protocol - Pawlowski, Shepler, Beame, Callaghan, Eisler, Noveck, Robinson, Thurlow (ResearchIndex)

Abstract: The Network File System (NFS) Version 4 is a new distributed file system similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network. Unlike earlier versions of NFS, the new protocol integrates file locking, strong security, operation coalescing, and delegation capabilities to enhance client performance for narrow data sharing applications on high-bandwidth...

[PDF]

Network Appliance - NFS Version 3 Design and Implementation Network appliance is definitely an expert in the topic...

by Brian Pawlowski, Chet Juszczak, Peter Staubach, Carl Smith, Diane Lebel, and David Hitz
Presented June 9, 1994: USENIX Summer 1994 - Boston, MA updated (10/2000) by Michael Marchi,  Network Appliance, Inc.

This paper describes a new version of the Network File System (NFS) that supports access to files larger than 4 GB and increases sequential write throughput seven-fold when compared to unaccelerated NFS Version 2. NFS Version 3 maintains the stateless server design and simple crash recovery of NFS Version 2, and the philosophy of building a distributed file service from cooperating protocols. The authors describe the protocol and its implementation, and provide initial performance measurements. They then describe the implementation effort. Finally, they contrast this work with other distributed file systems and discuss future revisions of NFS.

Download Full Version:

• the Adobe Acrobat file (63Kb)

Sun documentation

docs.sun.com NFS Administration Guide (Version 3 only)

docs.sun.com System Administration Guide, Volume 3 Chapter 29 Solaris NFS Environment

docs.sun.com NFS Server Performance and Tuning Guide for Sun Hardware

Tutorials

docs.sun.com NFS Administration Guide

docs.sun.com NFS Server Performance and Tuning Guide for Sun Hardware

[AIX] System Management Guide Communications and Networks - Network File System Overview

[AIX] Security Guide - Network File System (NFS) Security

Chapter 11 NFS IBM Redbooks IBM eServer Certification Study Guide - pSeries AIX System Administration

ONLamp.com: Configuring and Using NFS By Dru Lavigne Dru takes us through the basics of sharing files between UNIX computers. [July 26, 2000]

[02/14/2002] ONLamp.com Understanding NFS by Michael Lucas

NFS HOWTO

NFS System Administration Using NFS.

NFS -- course notes

20.2 NFS Protocol

NFS Administration -- from USAIL textbook  Integrating Your Machine With the Network See also NFS Overview

• NFS Daemons

• Exporting File Systems

• Mounting Remote File Systems

• The Automounter

Network File System Overview -- IBM R6000

LAN Team Tutorial (POC) Notes

• NFS and AMD

Reference

See also RFCs and FAQs.

NFS - PC Webopaedia Definition and Links

[AIX] System Management Guide Communications and Networks - NFS Reference

IBM Network File System (NFS) - Environmental Checklist Frequently asked questions

The following utilities are available on client machines help diagnosing simple network connection:

• rpinfo -p <hostname> to determine if portmapper (port 111), NFS (port 2049) are initialized with the appropriate port.
• ping to confirm that there is a live TCP/IP connection between client/sever machines.
• traceroute <hostname> to determine how packets are being routed from client to server.
• iptrace (AIX) or snoop (Solaris) are useful packet tracing utilities used to debug inbound and outbound packets between client and server. For example, during a MOUNT request, using iptrace or snoop will show whether the client transmitted the MOUNT request, the server has received the request, or the server is still processing the request.

RFCs

This filesystem is documented by a number of RFC's: NFS v2, NFS v3, NFS v4, and Web NFS.

•  NFS specification - version 2 - RFC1094.
   
•  NFS specification - version 3 - RFC1813.
   
•  NFS specification - version 4 - RFC2624.
• RFC 3530 (rfc3530) - Network File System (NFS) version 4 Protocol
• Web/NFS client specification - RFC2054.
• Web/NFS server specification - RFC2055
   
• RFC2623- NFS Version 2 and Version 3 Security Issues and the NFS.. ...

NFS Security

• IBM Redbooks Securing NFS in AIX An Introduction to NFS v4 in AIX 5L Version 5.3
• Managing NFS and NIS, 2nd Edition   Chapter 15: Debugging Network Problems
• NFS (in)security administration and information clearinghouse
• Security Guide - Network File System (NFS) Security
• [Doc] NFS Security
• NFS [Ch 20 of PUIS]
• Satan
  • Tutorial - Unprivileged NFS access
  • Tutorial - Portmapper exports
• Tutorial - Unrestricted NFS export
• NetManage Tutorials
• Firewalls Mailing List Re NFS proxies

Tips

Accessing NFS NFS is a commonly used tool in Unix networks that allows the sharing of files through RPC. Find out how to configure your Mac OS X client to access an NFS share

Etc

Linux NFS

NFS Tips (Red Hat)

LinuxDevCenter/Using NFS for Networked Backups By Glenn Graham Glenn. Graham demonstrates a quick and easy network backup solution using NFS [March 06, 2003]

Linux NFS HOWTO

If the directory (disk space) for a user's home directory is located on another system and AutoFS is not being used to make that space available, follow these steps to NFS-mount the home directory:

1.  Become superuser on the user's system.

2.  Edit the /etc/vfstab file and create an entry for the user's home directory. For example, to create an entry for user ignatz with a home directory on server oak, you would add this line to the file:

oak:/export/home1/ignatz - /home/ignatz nfs - yes rw,intr

3.  To create the mount point on the user's system, type mkdir /home/ login-name and press Return.

---

NOTE:  The home directory does not have the same name on the user's system as it does on the server. For example, /export/home/ignatz on the server is mounted as /home/ignatz on the user's system.

---

4.  Type chown login-name /home/login-name and press Return. The user now owns the home directory.

5.  Type chgrp primary-GID /home/login-name and press Return. The user's primary group has permission to access the user's home directory.

6.  Type mountall and press Return. All entries in the current vfstab file (whose automnt fields are set to Yes) are mounted.

7.  To verify that all entries are mounted, type mount and press Return. The file systems that are mounted are displayed.

NFS Maestro

• NFS Maestro Demand NFS Performance
• NFS Maestro Client- The World's Best NFS
• NFS Home Page

AFS NETWORK OVERVIEW

Zvon - RFC 3010 [NFS version 4 Protocol] - Bibliography

Bibliography

NFS (Network File System) is a widely used and primitive protocol that allows computers to share files over a network. Older versions of NFS relied on the inherently insecure UDP protocol, transactions are not encrypted and hosts and users cannot be easily authenticated. Below we will show a number of issues that one can follow to heal those security problems. Let us clarify how the NFS service operates. An NFS server is the server with a file system (or a directory) which is called NFS file system (or NFS directory) that will be exported to an NFS client. The NFS client will then have to import (or mount) the exported file system (directory) to itself before being able to have access to the file system (directory). We will annotate each issue below with on server, on client, on client & server and misc. Those mean that issue is done on NFS server, NFS client, both NFS client and server, and miscellaneous, respectively.

This can be done by adding parameter 'secure' in an item in /etc/exports, such as: /home nfs-client(secure)
where the directory /home is the file system to be exported to the NFS client located at address nfs-client (specify the IP address or domain name of your NFS client).

Export an NFS file system in an appropriate permission mode (on server)

Let's say that you only need read-only permission on your exported NFS file system. Then the file system should be exported as read-only to prevent unintended or even intended modifications on those files. This is done by specifying parameter 'ro' in /etc/exports. /home nfs-client(ro)


Restrict exporting an NFS file system to a certain set of NFS clients (on server)

Specify only a specific set of NFS clients that will be allowed to mount an NFS file system. If possible, use numeric IP addresses or fully qualified domain names, instead of aliases.

Use the 'root_squash' option in /etc/exports on the NFS server if possible (on server)

When this option is used, then while mounting using the command mount, the user ID ?root? on the NFS client will be replaced by the user ID ?nobody? on the NFS server. This is to prevent the root on the NFS client from taking a superuser privilege on the NFS server, thus perhaps illegally allowing him to modify files on the NFS server. Here is an example: /home nfs-client(root_squash)


Disable suid (superuser ID) on an NFS file system (on client)

Add the 'nosuid' option (no superuser ID privilege) to an item in /etc/fstab (This file is used to determine which NFS file systems are to be mounted automatically at the startup time). This is to prevent files with suid bits set on the NFS server, e.g., Trojan horse files, from being executed on the NFS client, which could then lead to root compromise on the client. Or the root on the NFS client may accidentally execute those suid files. Here is an example of ?nosuid?. An item in /etc/fstab on the client may contain: nfs-server:/home /mnt/nfs nfs ro,nosuid 0 0


where nfs-server is the IP address or domain name of the NFS server and /home is the directory on the NFS server to be mounted to the client computer at the directory /mnt/nfs. Alternatively, the 'noexec' option can be used to disable any file execution at all. nfs-server:/home /mnt/nfs nfs ro,nosuid,noexec 0 0


Install the most recent patches for NFS and portmapper (on client & server)

NFS is known to be in the top-ten most common vulnerabilities reported by CERT and was abusively exploited. This means that the NFS server and portmapper on your system must be up-to-date to security patches.

Perform encryption over NFS traffic using SSH (on client & server)

Apart from the use of Secure Shell (SSH) for secure remote access, we can use it for tunnelling between an NFS client and server so that NFS traffic will be encrypted. The steps below will guide you how to encrypt NFS traffic using SSH.

Here is the simple diagram to show the concept of how NFS and SSH services cooperate. nfs-client nfs-server
mount --- SSH SSHD --- NFS


From this figure, when you mount an NFS directory from a client computer, you will mount through SSH. After the mounting is done, the NFS traffic in both directions will be encrypted and so secure.

In the figure the NFS server is located at address nfs-server (use either the IP address or domain name of your NFS server instead), and the NFS client is at address nfs-client. Make sure that in both systems you have SSH and NFS related services already installed so you can use them.

There are two way configurations on the NFS client and server which are described in the two sections below.

NFS server configuration
Section 1.1 and 1.2 are what we have to do on the NFS server. Export an NFS directory to itself
For example, if the NFS server's IP address is 10.226.43.154 and the NFS directory to be exported is /home, then add the following line to /etc/exports /home 10.226.43.154(rw,root_squash)


The reason for exporting directory /home to itself, instead of to an NFS client? IP address in an ordinary fashion, is that according to the figure above, we will feed the NFS data on the server to SSHD which is running at 10.226.43.154, instead of to the client computer in the usual case. The NFS data will then be forwarded securely to the client computer through the tunnel.

Note that the exported directory is allowed for read and write permission (rw). root_squash means the person who starts the mounting process to this directory will not obtain the root privilege on this NFS server.

Restart NFS and SSH daemons

Using Redhat 7.2, you can manually start NFS and SSHD by issuing the following commands: #/sbin/service nfs restart
#/sbin/service sshd restart


If you want to have them started automatically at startup time, with Redhat 7.2 add the two lines below to the startup file /etc/rc.d/rc.local. /sbin/service nfs start
/sbin/service sshd start


The term nfs in the commands above is a shell script that will start off two services, namely, NFS and MOUNTD.

NFS client configuration
Three sections below show what we have to do on the NFS client. Find the ports of NFS and MOUNTD on the NFS server Let's say you are now on the NFS client computer. To find the NFS and MOUNTD ports on the NFS server, use the command. #rpcinfo -p nfs-server

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 tcp 2049 nfs
100003 2 udp 2049 nfs
100021 1 udp 1136 nlockmgr
100021 3 udp 1136 nlockmgr
100021 4 udp 1136 nlockmgr
100011 1 udp 789 rquotad
100011 2 udp 789 rquotad
100011 1 tcp 792 rquotad
100011 2 tcp 792 rquotad
100005 2 udp 2219 mountd
100005 2 tcp 2219 mountd



Note the lines with terms nfs and mountd. Under the column port, those are the ports for nfs and mountd. nfs has a port 2049 and mountd has a port 2219.

Setup the tunnel using SSH
On the NFS client computer, bind a SSH port with NFS port 2049. #ssh -f -c blowfish -L 7777:nfs-server:2049 -l tony nfs-server /bin/sleep 86400
#tony@nfs-server's password:
#

where:
-c blowfish means SSH will use the algorithm blowfish to perform encryption.

-L 7777:nfs-server:2049 means binding the SSH client at port 7777 (or any other port that you want) to communicate with the NFS server at address nfs-server on port 2049.

-l tony nfs-server means in the process of login on the authentication server at address nfs-server (specify either the IP address or domain name of the authentication server), use the user login name tony to authenticate on the server.

/bin/sleep 86400 means to prevent spawning a shell on the client computer for 1 day (86,400 seconds). You can specify any larger number.

The line with #tony@nfs-server's password: will prompt the user tony for a password to continue authentication for the user.


Also on the NFS client computer, bind another SSH port with MOUNTD port 2219. #ssh -f -c blowfish -L 8888:nfs-server:2219 -l tony nfs-server /bin/sleep 86400
#tony@nfs-server's password:
#

where:
-L 8888:nfs-server:2219 means binding this SSH client at port 8888 (or any other port that you want but not 7777 because you already used 7777) to communicate with the NFS server at address nfs-server on port 2219.
c) On the NFS client computer, mount NFS directory /home through the two SSH ports 7777 and 8888 at a local directory, say, /mnt/nfs. #mount -t nfs -o tcp,port=7777 ,mountport=8888 localhost:/home /mnt/nfs


Normally the format of the command mount is to mount, at the IP address (or domain name) of the remote host, the remote NFS directory (/home) to the local directory (/mnt/nfs). However, the reason we mount at localhost instead of the nfs-server, is because the data after decryption at the left end of the tunnel (see the figure above also) is on the localhost, not the remote host.

Alternatively, if you want to mount the NFS directory automatically at startup time, add the following line to /etc/fstab localhost:/home /mnt/nfs/ nfs tcp,rsize=8192,wsize=8192,intr,rw,bg,nosuid,port=7777,mountport=8888,noauto


Allow only traffic from authorised NFS clients to the NFS server (on server)

Supposing that an NFS server only provides the NFS service but nothing else so there are three ports available to use on the server, i.e., RPC Portmapper (on port 111), NFS (on port 2049), and Mountd (on port 2219). Here we can do some filtering on traffic that goes to the NFS server. Through the iptables firewall running locally on the NFS server (you must install iptables to use the following commands), allow only traffic from any authorised NFS client to the server. Allow traffic from an authorised subnet 10.226.43.0/24 to the ports Portmapper, NFS, and Mountd.
#iptables -A INPUT -i eth0 -s 10.226.43.0/24 -dport 111 -j ACCEPT
#iptables -A INPUT -i eth0 -s 10.226.43.0/24 -dport 2049 -j ACCEPT
#iptables -A INPUT -i eth0 -s 10.226.43.0/24 -dport 2219 -j ACCEPT

Deny something else.
#iptables -A INPUT -i eth0 -s 0/0 -dport 111 -j DROP
#iptables -A INPUT -i eth0 -s 0/0 -dport 2049 -j DROP
#iptables -A INPUT -i eth0 -s 0/0 -dport 2219 -j DROP
#iptables -A INPUT -i eth0 -s 0/0 -j DROP



Basically the NFS service operates through Portmapper service so if we block Portmapper port 111, we also then block NFS port 2049.

Alternatively, you can use the TCP wrapper to filter access to your portmapper by adding the line: portmapper: 10.226.43.0/24
to /etc/hosts.allow to allow access to portmapper only from subnet 10.226.43.0/24.

Also add the line below to /etc/hosts.deny to deny access to all other hosts not specified above. portmapper:ALL


Filter out Internet traffic to the NFS service on the routers and firewalls (misc)

In some cases for many organisations with their computers visible on the Internet, if the NFS service is also visible, then we may need to block Internet traffic to ports 111 (Portmapper), 2049 (NFS), and 2219 (Mountd) on your routers or firewalls to prevent unauthorised access to the two ports. With the iptables set up as your firewall, use the following rules: #iptables -A INPUT -i eth0 ?d nfs-server -dport 111 -j DROP
#iptables -A INPUT -i eth0 ?d nfs-server -dport 2049 -j DROP
#iptables -A INPUT -i eth0 -d nfs-server -dport 2219 -j DROP


Use the software tool NFSwatch to monitor NFS traffic (misc)

NFSwatch allows you to monitor NFS packets (traffic) flowing between the NFS client and server. It can be downloaded from ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/nfswatch/. One good reason that we need to monitor is that in case there is some malicious activity going on or already taking place, we would then use the log created by NFSwatch to trace back to how and where it came from. To monitor NFS packets between nfs-server and nfs-client, use the command: #nfswatch -dst nfs-server -src nfs-client

all hosts Wed Aug 28 10:12:40 2002 Elapsed time: 00:03:10
Interval packets: 1098 (network) 818 (to host) 0 (dropped)
Total packets: 23069 (network) 14936 (to host) 0 (dropped)
Monitoring packets from interface lo
int pct total int pct total
ND Read 0 0% 0 TCP Packets 461 56% 13678
ND Write 0 0% 0 UDP Packets 353 43% 1051
NFS Read 160 20% 271 ICMP Packets 0 0% 0
NFS Write 1 0% 1 Routing Control 0 0% 36
NFS Mount 0 0% 7 Address Resolution 2 0% 76
YP/NIS/NIS+ 0 0% 0 Reverse Addr Resol 0 0% 0
RPC Authorization 166 20% 323 Ethernet/FDDI Bdcst 4 0% 179
Other RPC Packets 5 1% 56 Other Packets 2 0% 131
1 file system
File Sys int pct total
tmp(32,17) 0 0% 15

Specify the IP address (or domain name) of the source (-src) and that of the destination (-dst).

By Nawapong Nakjang Banchong Harangsri

Last modified: February 28, 2008