12.3. 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.
12.3.1. 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.
12.3.2. 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 Section 4.2.6, "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!
12.3.2.1. 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
12.3.3. 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.
![Previous](../gifs/txtpreva.gif) | ![Home](../gifs/txthome.gif) | ![Next](../gifs/txtnexta.gif) |
12.2. How secure are NIS and NFS? | ![Book Index](../gifs/index.gif) | 12.4. NFS security |