Endpoint Protection

 View Only

NFS and NIS Security  

Jan 22, 2001 02:00 AM

by Kristy Westphal

NFS and NIS Security
by Kristy Westphal
last updated Jan. 22, 2001


Why is it that when you read almost any book or paper about Solaris security it will explicitly say: turn off the NFS and NIS services. Some system administrators, though, cannot just turn off these services, as they are already key services implemented across their enterprises. Security issues seem to be inherent in their structure; however, there are methods and precautions that can be taken to make them more secure than their plain-vanilla implementations.

What is NFS?

Based on the RPC (remote procedure call) protocol, network filesystem was originally created by Sun Microsystems in the 1980's to share files on disparate Unix systems. NFS is a client/server implementation that makes remote disks transparently available on a local client. It utilizes several daemons and configuration files to enable file sharing. By default, this process is all undertaken without any separate authentication, which makes NFS a security risk (see Figure 1).

XDR- External Data Representation
Internet Protocol
Network Transport (e.g. Ethernet)

Figure 1- NFS Protocol Stack [1]

How does it work? NFS runs on the UDP protocol, which is a connectionless protocol because it does not require any acknowledgement of packet delivery. NFS tries to make up for this by forcing an acknowledgement of every command it sends. If the acknowledgement occurs, it continues sending data. If not received in a certain amount of time, then the data is retransmitted.

NFS involves not only the NFS protocol, but also the MOUNT protocol. These protocols are implemented in NFS in the form of the daemons: rpc.mountd, nfsd and portmap on the server end. Mountd tells nfsd what filesystems are available to be mounted on the local hosts. Portmap handles the rpc-based services. On the client end, nfs is employed through the biod, rpc.statd and rpc.lockd daemons. Biod does read-ahead and write-behind performance optimizations for the client, running in multiple instances. Rpc.statd and rpc.lockd maintain the file locking and lock recovery. [2]

Key files include the /etc/exports file, which defines what shares are available and to whom, and /etc/fstab, which maintains the mounted filesystem list for the client.

What is NIS?

Network Information Service, formerly known as the Yellow Pages, is a distributed database system that centralizes commonly accessed Unix files like /etc/passwd, /etc/group, or /etc/hosts. The master server maintains the files, while the clients seamlessly access the information across the network.

The information accessed in NIS is housed in files called maps. In addition to the central master server, where all maps are maintained, and the clients that access them, slave servers exist. These slaves can handle client requests for map access, but no changes to the maps are made on the slaves. Changes are made only at the master server, and then distributed through the master (see Figure 2).


  | | |  
Slave | Slave
  | | |  
Client Client Client

Figure 2- NIS client/server structure [2]

Clients know to access the NIS maps when a + is placed in their local files. Also, the /etc/nsswitch.conf file specifies which order to look up name service information in: through DNS (domain name services), NIS or local files.

NIS is implemented through several daemons as well. Ypserv is the daemon on the server side, and ypbind on the client side for making NIS requests. Maps are transferred manually to slaves after updates are made (using yppush) or through ypxfrd automatically (slaves check timestamps on the master and update accordingly).

Problems with NFS-NIS

Why are there so many problems with these services? Over the years, there have been continuous issues with both services, which seems to be inherent in their design. NFS utilizes the AUTH_UNIX method of authentication, which implicitly trusts the UID (user ID) and GIDs (group ID) that the NFS client presents to the server. Root access to a file system explicitly exported by root can also be easily compromised if an intruder can gain root access. Further, programs can easily be developed that set the UID and GID value to any given number. This allows access to any user's file on an NFS server. [1] At times, the NFS daemons have also been known to be vulnerable to buffer overflows.

NIS has been vulnerable against DOS attacks (using the finger service against multiple clients), buffer overflows (libnasl), lax authentication while querying of NIS maps (easy for a compromised client to take advantage of), as well as the various daemons each having their own individual issues. Not to mention that misconfiguration of NIS or netgroups can also provide easy holes that can be exploited. NIS databases can also be easily accessed by someone who doesn't belong on your network. How? They simply can guess the name of your NIS domain, bind their client to that domain, and run a ypcat command to get the information they are after.

Both NFS and NIS also can run on unprivileged ports, which means that any user on the systems can run them. If a replacement version of these daemons was put in place of the original, then the attacker would have access to the resources that the daemons control.

Securing NFS

Taking NFS as it is. Following is a checklist of items to help better secure your NFS implementation.

First step: You need to make sure that your NFS patches are up to date. Exploits are found frequently, and Sun is typically very quick to respond with fixes. Second step: take a look at how your NFS is set up. Take a look first at your /etc/exports file. Are all the hosts and netgroups listed in this file up to date? Oftentimes, users and hosts move around, so it is critical to audit this file frequently to ensure that the entries are accurate. Make sure you drill down into the netgroups to check the accuracy of the groups as well (hint: they can be found in the /etc/netgroup file).

Before we leave the /etc/exports file; however, there are some other items that we need to check. File system permissions are also defined here, so we need to examine them closely. If you see no permissions at all defined for a file system, this is bad. This essentially means that that filesystem can be accessed by anyone, anywhere. Instead, you might want to think about restricting access of that directory by a specific host or hosts, or perhaps by a group of users defined in a netgroup, as well as exporting them read only. This allows a level of granularity that will help if an attacker ever targets one of your NFS filesystems because they now have to go through more levels of security. A final word on these two files: make sure that the NFS server is not self referenced in either file, either as its hostname or as localhost. Also export the hosts with fully qualified domain names. [3]

The third step is to make sure that the files do not exceed 256 characters. Once you make changes to your /etc/exports file, then be sure to run /etc/exportfs to guarantee that the changes have taken affect. Then, run a showmount -e to audit what these files actually have exported. Again, make sure that it shows what you want it to! Step four is to make sure that the permissions of /etc/exports and /etc/netgroups are 644, and that they are owned by root and the group is either root or sys (either are appropriate).

Step four is to run fsirand on the exported file systems, and then put it in your schedule to run regularly. Fsirand installs random inode generation numbers for your file systems. The file systems must be unmounted to do this, which may be inconvenient; however, you are making it harder for the bad guy as you are making the file handles unpredictable.

The last step in our securing NFS process will be to enable NFS port monitoring. We discussed previously how NFS by default can be replaced and run on any unprivileged port. This can be fixed in Solaris by adding the following line to your /etc/system file:

set nfssrv:nfs_portmon = 1

This will make the NFS server only accept client requests that occur on privileged ports. [4] Don't forget to reboot after adding this parameter.

Securing NIS

Taking NIS as it is, the first step in your NIS security checklist is to once again make sure that your patch set is up to date. The second step is to look at how your NIS structure is set up. If you have an NIS server that is on two or more networks, you may want to consider moving your NIS server services to a one-network server. The reasoning behind this is that if your multi-networked server is doing routing functions, then anyone can bind to your NIS domain and read your NIS maps in both domains. If your NIS server is behind a router, then this same principle can apply unless IP packet forwarding is disabled on the router.[2]

The next step in examining your structure involves separating NIS maps from local password files. Utilizing this strategy makes it more difficult for an intruder to gain password information from the NIS master server. Also make sure that the root password is not maintained in an NIS map. A third step in NIS security is to look at user passwords themselves. Do they adhere to recommended security practices? Are they simple words that are easy to guess? If so, no NIS security structure in place can protect your system if an intruder can guess the user's password and log right in to your system. You may want to examine your policies a bit closer if you do not have a solid one already in place. [2]

Step four in our checklist includes looking for null passwords. The following script allows you to do this quickly:

 #!/bin/sh ( cat /etc/passwd; ypcat passwd ) | awk -F':' '{if $2 == ""} print $1)'  [2] 

Step five involves making sure that the * in the password field is being used correctly. Set up your password map on a client to have this entry:


in order to utilize NIS maps. Try logging in to this client. Hopefully, you won't be able to. Then try the next step of removing the * and then logging in as the "+" user. If you can log in as this user, as well as other NIS users can log in to this box, then there is a problem with the implementation of NIS and you need to check for the most recent patches. This is a common exploit for older versions of ypbind. [5]

Step six in reviewing and securing your NIS structure involves looking at how your server database maps were created. There is a special key that can be used in the making of the DBM files called YP_SECURE, that can ensure that NIS servers only answer questions from a client on privileged ports. This helps ensure that no spoofed NIS client services are generating bogus traffic. Further, trusted hosts and networks can be included in the /var/yp/securenets file, which is read by ypserver and ypxfrd.


Netgroups can restrict groups to certain hosts, can restrict NFS access to certain hosts, and can define users as administrators for a particular domain. Netgroups can also be an administrative hassle. However, if you really want to narrow the number of possible attacks against both NFS and NIS, you may want to use them. Through defining netgroups, you can specify who and where files can be accessed throughout your enterprise. The main database for netgroups is stored on the NIS master server in the /etc/netgroup file.

Netgroups can also be implemented in ways that defeat the purpose of using them to lock down security in the first place. Netgroups have also been used in the structure of setting up networks to have transparent access across the network utilizing rlogin and rsh. This may make access to files and systems easier, but it leaves no accountability. [2] The key to remember here is that if you do implement netgroups, be sure to also implement the following policies:

  1. Disable use of the rlogin and rsh across your systems, especially at the server level.
  2. If you are unable to do that, limit usage of these services and the .rhosts file.
  3. Look for syntax errors in your /etc/netgroup files.
  4. Test access for groups defined in netgroups: make sure these groups have access to what they are supposed to, and not a whole lot else.

Further, be cautious of special characters in both of these files: blank spaces ("(,,)") in the files mean that anyone can mount the filesystem specified. Misspellings of hosts or users can also leave unwanted holes in security. [3]

Advanced Options

After reading this much, are you convinced yet that your NFS and NIS implementations are secure enough? There are options other than using these basic services.

Secure NFS is a service used in conjunction with Secure RPC, which uses a combination of DES encryption and exponential key exchange to provide the authentication layer that is missing with plain NFS.

NIS+/LDAP NIS+ is the newer generation of NIS, with more built-in security (again, not perfect, but better). NIS+ has a hierarchical structure vs. NIS flat file structure, as well as a more granular access control system. NIS+ is seemingly evolving into LDAP, which is implemented through a new server service called ypldapd. [6]

CFS (Cryptographic File System) written by Matt Blaze is a replacement for NFS that puts the encryption service at the file system level. CFS addresses numerous issues with encryption in an OS, including rational key management, transparent access and performance, as well as scalability and portability (aspects of public key encryption that are typically difficult to implement in real life).


NFS and NIS services are inherently insecure. They also continue to be a constant target for unauthorized access to your network. However, if you follow some secure layering techniques as mentioned in this article, they can be secured to a reasonable level. If this level is not good enough for your security policies, one of the options in the Advanced Options might be worth exploring in more depth.


[1] Practical UNIX Security, Simson Garfinkel and Gene Spafford, O'Reilly and Associates, Inc., 1991

[2] Managing NFS and NIS, Hal Stern, O'Reilly and Associates, Inc., 1991

[3] "Almost Everything You Ever Wanted to Know About Security" (but were afraid to ask!), http://www.nsi.org/Library/Compsec/faq.htm. Maintained by Alec Muffett.

[4] "Solaris Operating Environment Security", Alex Noordergraaf and Keith Watson, Sun BluePrints OnLine, January 2000

[5] UNIX Computer Security Checklist (Version 1.1), AUSCERT, ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist

[6] "NIS to LDAP Transition: Exploring" Tom Bialaski, Sun BluePrints OnLine, February 2000.

[7] "A Cryptographic File System for Unix", Matt Blaze, AT&T Bell Laboratories, November 1993.

Kristy Westphal is a versatile network administrator, skilled in troubleshooting and process analysis. Her experience in the IS field have allowed her to become knowledgeable in several flavors of UNIX and NT, as well as various aspects of information security and disaster recovery planning. She is currently employed by Buzzeo, Inc. as a Sr. Security/UNIX Administrator.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

0 Favorited
0 Files

Tags and Keywords

Related Entries and Links

No Related Resource entered.