Managing NFS and NIS, 2nd Edition - Mike Eisler [143]
DCE/DFS
At the time this book was written, DCE/DFS was available as an add-on product developed by IBM's Pittsburgh Laboratory (also known as Transarc) unit for Solaris, IBM's AIX, and Windows. Other vendors offer DCE/DFS for their own operating systems (for example, HP offers DCE/DFS). So DCE/DFS offers the file access solution that is both heterogeneous and very secure.
NIS has earned its reputation because it has no authentication at all. The risk of this is that a successful attacker could provide a bogus NIS map to your users by having a host he controls masquerade as an NIS server. So the attacker could use a bogus host map to redirect the user to a host he controls (of course DNS has the same issue).[1] Even more insidious, the attacker could gain root access when logging into a system, simply by providing a bogus passwd map. Another risk is that the encrypted password field from the passwd map in NIS is available to everyone, thus permitting attackers to perform faster password guessing than if they manually tried passwords via login attempts.
These issues are corrected by NIS+. If you are uncomfortable with NIS security then you ought to consider NIS+. In addition to Solaris, NIS+ is supported by AIX and HP/UX, and a client implementation is available for Linux. By default NIS+ uses the RPC/dh security discussed in Section 12.5.4. As discussed in Section 12.5.4.10, RPC/dh security is not state of the art. Solaris offers an enhanced Diffie-Hellman security for NIS+, but so far, other systems have not added it to their NIS+ implementations.
Ultimately, the future of directory services is LDAP, but at the time this book was written, the common security story for LDAP on Solaris, AIX, HP/UX, and Linux was not as strong as that of NIS+. You can get very secure LDAP out of Windows 2000, but then your clients and servers will be limited to running Windows 2000.
* * *
[1] An enhancement to DNS, DNSSEC has been standardized but it is not widely deployed.
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 book 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