20.2. Network Information Service (NIS)

NIS[120] is a protocol primarily used under Unix and designed to provide distributed access to centralized administrative information (such as host tables, password files, site-wide email aliases, and so on) shared by machines at a site. The advantage of NIS over DNS for hostname resolution on a local area network is that NIS is a broadcast-based protocol; clients do not have to have all of the configuration information necessary for them to use DNS. In addition, having a unified mechanism that distributes all of the administrative information simplifies site administration.

[120]NIS was formerly known as Yellow Pages (YP), and some commands still preserve this abbreviation.

The main problem with NIS is that its security isn't good enough to adequately protect some of the data it contains. In particular, a site's NIS servers generally contain the site's shared password file (equivalent to the /etc/passwd file on a single system), complete with encrypted passwords. All you need to get data from an NIS server is the NIS domain name with which the data is associated. An attacker who can talk to a site's NIS server, and who can guess what the site has chosen as its NIS domain name (often the same as, or a derivative of, its regular Internet domain name), can request any information the server has. If the attacker gets the shared password file, these passwords can be cracked at the attacker's leisure. You therefore do not want to allow NIS requests inbound.

TIP: NIS transfers may include the encrypted passwords even if the machines are configured to use shadow passwords and the encrypted passwords are not readable on the NIS server. If NIS transfers do not include encrypted passwords, they cannot be used for authentication, so implementations that close this hole simply do not allow you to use both NIS and shadow passwords.

There is no reason to allow NIS requests outbound because most of the information provided is local to an individual site, and most NIS servers will act as gateways to DNS for external hostname information when correctly configured.

A revised version of NIS, called NIS+, is available from some vendors. (It is the default version used on Suns.) NIS+ has not achieved wide acceptance, partly because of licensing and compatibility issues, but mostly because the majority of sites have managed to work around the deficiencies of NIS already, and therefore aren't motivated to switch to something new. NIS+ improves security only if it is configured so that it will not support NIS If you configure NIS+ to support NIS clients (and because few NIS+ clients are available, most NIS+ sites do use it in this mode), it is no more secure than original NIS.

A few NIS servers (notably Sun's) support a configuration file called securenets, which allows you to use IP address authentication to control which hosts your NIS server will release data to. This is an order of magnitude improvement in NIS security. It changes NIS attacks from guessing games (guess the domain name and the NIS server, and you get a free prize) to requiring you to do all the same guessing and then make a serious effort to determine what addresses the NIS server will respond to and forge packets from them. Unfortunately, an order of magnitude is probably not enough of an improvement for data as crucial as your encrypted passwords. While securenets (if you have it available) will protect you from casual attackers who want to get into any site they can, it will not protect you from an attacker who knows your site and who wants to attack it in particular. The trick, then, is to prevent an attacker from talking to your NIS servers.

NIS is an Sun RPC-based service, generally provided over UDP. Although NIS is an especially vulnerable service, it is otherwise the same as every other RPC-based service. We do not know of special proxies or packet filters for it. NIS+ may be provided over normal RPC, but this removes much of its extra security; by default, it's run over Secure RPC. The packet filtering, proxying, and network address translation characteristics of RPC and Secure RPC are discussed in Chapter 14, "Intermediary Protocols".

NIS clients may also use additional means to find servers. Older clients will do this via broadcast; newer ones will use multicast instead. Whichever method is used by clients, if you want NIS to work through a firewall, you will need to either make certain that the relevant queries are passed to the server, or explicitly configure clients with a server name.

---