 | Chapter 8 Configuring Internet Services |  |
| Chapter 8 Configuring Internet Services | |
NIS/YP is 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 main problem with NIS/YP is that its security isn't good enough to adequately protect some of the data it contains. In particular, a site's NIS/YP servers generally contain the shared password file (equivalent to the /etc/passwd file on a single system) for the site, complete with encrypted passwords. All you need to get data from an NIS/YP server is the NIS/YP domain name with which the data is associated. An attacker who can talk to a site's NIS/YP server, and who can guess what the site has chosen as its NIS/YP domain name (often the same as, or a derivative of, their regular Internet domain name), can request any information the server has. If the attacker gets their shared password file, these passwords can be cracked at the attacker's leisure.
NOTE: NIS/YP transfers include the encrypted passwords even if the machines are configured to use shadow passwords and the encrypted passwords are not readable on the NIS/YP server.
There is a revised version of NIS/YP, called NIS+, available from some vendors. 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/YP 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/YP. If you configure NIS+ to support NIS/YP 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/YP.
A few NIS/YP servers (notably Sun's) support a configuration file called securenets. This allows you to use IP address authentication to control which hosts your NIS/YP server will release data to. This is an order of magnitude improvement in NIS/YP security. It changes NIS/YP attacks from guessing games (guess the domain name and the NIS/YP server and you get a free prize) to requiring you to do all the same guessing and then go to serious effort to determine what addresses the NIS/YP 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 wants to attack it in particular.
The trick, then, is to keep an attacker from being able to talk to your NIS/YP servers.
NIS/YP is an RPC-based service, generally provided over UDP. As mentioned in Chapter 6, it's very difficult to handle RPC-based services with a packet filtering system, because the servers normally don't use predictable port numbers. While the port numbers to be used are too unpredictable for a packet filtering system to cope with, they're not so unpredictable that an attacker can't find them. (If nothing else, the attacker could try sending NIS/YP requests to all ports, to see which respond as they would expect an NIS/YP server to.)
RPC-based protocols are almost as unpleasant to proxy as they are to allow with packet filtering; they cannot be adequately handled with generic proxies. A dedicated NIS/YP proxy server would be possible, but we do not know of one, except for the proxying capabilities available with NIS+. In any case, proxying alone does not adequately deal with the vulnerabilities of NIS/YP.
Don't allow NIS/YP across your firewall.
|  | |
| 8.14 Network File System (NFS) |  | 8.16 X11 Window System |