Password and NIS security

Several volumes could be written about password aging, password guessing programs, and the usual poor choices made for passwords. Again, this tutorial won't describe a complete password security strategy, but here are some common-sense guidelines for password security:

Watch out for easily guessed passwords. Some obvious bad password choices are: your first name, your last name, your spouse or a sibling's name, the name of your favorite sport, and the kind of car you drive. Unfortunately, enforcing any sort of password approval requires modifying or replacing the standard NIS password management tools.
Define and repeatedly stress local password requirements to the user community. This is a good first-line defense against someone guessing passwords, or using a password cracking program (a program that tries to guess user passwords using a long list of words). For example, you could state that all passwords had to contain at least six letters, one capital and one non-alphabetic character.
Remind users that almost any word in the dictionary can be found by a thorough password cracker.
Use any available password guessing programs that you find, such as Alec Muffet's crack. Having the same weapons as a potential intruder at least levels the playing field.

In this section, we'll look at ways to manage the root password using NIS and to enforce some simple workstation security.

Managing the root password with NIS

NIS can be used to solve a common dilemma at sites with advanced, semi-trusted users. Many companies allow users of desktop machines to have the root password on their local hosts to install software, make small modifications, and power down/boot the system without the presence of a system administrator. With a different, user-specific root password on every system, the job of the system administrator quickly becomes a nightmare. Similarly, using the same root password on all systems defeats the purpose of having one. Root privileges on servers should be guarded much more carefully, since too many hands touching host configurations inevitably creates untraceable problems. It is important to stress to semi-trusted users that their lack of root privileges on servers does not reflect a lack of expertise or trust, but merely a desire to exert full control over those machines for which you have full and total responsibility. Any change to a server that impacts the entire network becomes your immediate problem, so you should have jurisdiction over those hosts. One way to discourage would-be part-time superusers is to require anyone with a server root password to carry the 24-hour emergency beeper at least part of each month. Some approach is required that allows users to gain superuser access to their own hosts, but not to servers. At the same time, the system administrator must be able to become root on any system at any time to perform day-to-day maintenance. To solve the second problem, a common superuser password can be managed by NIS. Add an entry to the NIS password maps that has a UID of 0, but login name that is something other than root. For example, you might use a login name of netroot. Make sure the /etc/nsswitch.conf file on each host lists nis on the passwd: entry:

passwd: files nis

Users are granted access to their own host via the root entry in the /etc/passwd file. Instead of creating an additional root user, some sites use a modified version of su that consults a "personal" password file. The additional password file has one entry for each user that is allowed to become root, and each user has a unique root password.[20] With either system, users are able to manage their own systems but will not know the root passwords on any other hosts. The NIS-managed netroot password ensures that the system administration staff can still gain superuser access to every host.

[20]An su-like utility is contained in Unix System Administration eBook, by Evi Nemeth, Scott Seebass, and Garth Snyder (Prentice-Hall, 1990).

Making NIS more secure

Aside from the caveats about trivial passwords, there are a few precautions that can be taken to make NIS more secure:

If you are trying to keep your NIS maps private to hide hostnames or usernames within your network, do not make any host that is on two or more networks an NIS server. Users on the external networks can forcibly bind to your NIS domain and dump the NIS maps from a server that is also performing routing duties. While the same trick may be performed if the NIS server is inside the router, it can be defeated by disabling IP packet forwarding on the router. Appendix A, "IP Packet Routing" covers this material in more detail.
On the master NIS server, separate the server's password file and the NIS password file so that all users in the NIS password file do not automatically gain access to the NIS master server. A set of changes for building a distinct password file was presented in "Using alternate map source files".

Periodically check for null passwords using the following awk script:

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

The subshell concatenates the local password file and the NIS passwd map; the awk script prints any username that does not have an entry in the password field of the password map.
Consider configuring the system so that it cannot be booted single-user without supplying the root password. On Solaris 8, this is the default behavior, and can be overridden by adding this entry to /etc/default/sulogin:
```
PASSREQ=NO 
```
When the system is booted in single-user mode, the single-user shell will not be started until the user supplies the root password.
Configure the system so that superuser can only log into the console, i.e., superuser cannot rlogin into the system. On Solaris 8, you do this by setting the CONSOLE variable in /etc/default/login:
```
CONSOLE=/dev/console
```

On Sun systems, the boot PROM itself can be used to enforce security. To enforce PROM security, change the security-mode parameter in the PROM to full:
```
# eeprom security-mode=full
```
No PROM commands can be entered without supplying the PROM password; when you change from security-mode=none to security-mode=full you will be prompted for the new PROM password. This is not the same as the root password, and serves as a redundant security check for systems that can be halted and booted by any user with access to the break or reset switches.

WARNING: There is no mechanism for removing the PROM security without supplying the PROM password. If you forget the PROM password after installing it, there is no software method for recovery, and you'll have to rely on Sun's customer service organization to recover!

The secure nets file

If the file /var/yp/securenets is present, then ypserv and ypxfrd will respond only to requests from hosts listed in the file. Hosts can be listed individually by IP address or by a combination of network mask and network. Consult your system's manual pages for details. The point of this feature is to keep your NIS domain secure from access outside the domain. The more information an attacker knows about your domain, the more effective he or she can be at engineering an attack. The securenets file makes it harder to gather information. Because ypserv and ypxfrd only read the securenets file at startup time, in order for changes to take effect, you must restart NIS services via:

# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart

Unknown password entries

If a user's UID changes while he or she is logged in, many utilities break in esoteric ways. Simple editing mistakes, such as deleting a digit in the UID field of the password file and then distributing the "broken" map file, are the most common source of this problem. Another error that causes a UID mismatch is the replacement of an NIS password file entry with a local password file entry where the two UIDs are not identical. The next time the password file is searched by UID, the user's password file entry will not be found if it no longer contains the correct UID. Similarly, a search by username may turn up a UID that is different than the real or effective user ID of the process performing the search. The whoami command replies with "no login associated with uid" if the effective UID of its process cannot be found in the password file. Other utilities that check the validity of UIDs are rcp, rlogin, and rsh, all of which generate "can not find password entry for user id" messages if the user's UID cannot be found in the password map. These messages appear on the terminal or window in which the command was typed.