System Administation: Maximizing System Security, Part 1

One of the most hackneyed cliches in all of UNIX culture is that UNIX security is a contradiction in terms. While things aren't quite as hopeless as this cynical view, it is important to realize that a secure system is something you create, not something you get automatically when you install any current Linux distribution (or any other UNIX operating system for that matter).

This article provides an overview of UNIX security issues, and discusses the resources and tools available to Linux system administrators or anyone responsible for administering a Linux system—which are not necessarily synonymous. It considers what the most important issues are and what exists to defend the system. And since many of the most egregious “UNIX” security problems are actually vulnerabilities in TCP/IP networking and its component protocols, we naturally consider network security issues, as well as those relevant to an isolated computer system.

General discussions of computer security traditionally focus on the types of losses that can result from inadequate security measures:

Depending on your situation, some of these threats are obviously more potentially hazardous to you than others.

Effective thinking about security begins by considering potential losses rather than potential threats, because doing so allows you to place the threats in the context of your system and thereby make appropriate choices about how to prevent and address them. For example, every system has the potential of being broken into by an unauthorized person. However, the specific nature of that threat changes depending on the sort of loss that would be its most serious consequence—as do the corresponding measures to prevent the loss.

A successful intruder always has the potential to alter or destroy any file on the system, so every system needs to guard against and have a plan for recovering from that eventuality. In addition, for a system containing sensitive or proprietary data (customer credit card numbers, source codes for software products under development, and so on) one might need to consider ways of securing such data even from the root account. On the other hand, if loss of use is the primary loss against which a system needs to be protected, then devising ways of quickly identifying and neutralizing such an attack is much more important than providing extra security for any of the data on the system.

As these scenarios suggest, security involves more than just prevention against attacks. Equally important components of computer security are the recovery plans which specify what to do when something goes wrong. Computer security is not something you think about once in a while, but rather something that is an integral part of your thinking and actions in every administrative activity you perform. It includes the following concerns (not all of which will necessarily apply to any specific system):

A thorough discussion of all of these topics would consume several entire issues of Linux Journal, so we focus on operating system-level protections and solutions useful for Linux systems, in terms of both “standard” features and useful additional packages. Security facilities offered by the various Linux distributions vary considerably, but no current distribution includes everything that a prudent system administrator would want to have and use.

Package                          ftp Location
COPS                     ftp.cert.org:/pub/tools/cops
Courtney         ftp.best.com:/pub/lat
Crack                    ftp.cert.org:/pub/tools/crack
Gabriel                  ftp.best.com:/pub/lat
Merlin                   ciac.llnl.gov:/pub/ciac/sectools/unix/merlin
Netscape         ftp.netscape.com:/netscape/unix
npasswd                  ee.utah.edu:/admin/passwd/npasswd
passwd+                  ee.utah.edu:/admin/passwd/passwd+
Perl                     prep.ai.mit.edu:/pub/gnu
Satan                    ftp.win.tue.nl:/pub/security
shadow                   sunsite.unc.edu:/pub/Linux/system/Admin
sudo                     sunsite.unc.edu:/pub/Linux/system/Admin
swatch                   sierra.stanford.edu:/pub/sources
TCP Wrappers             ftp.win.tue.nl:/pub/security/tcp_wrapper
Tripwire         coast.cs.purdue.edu:/pub/COAST/Tripwire

Passwords are the primary way of securing user accounts on Linux systems. However, the protection offered by passwords is only as good as the passwords themselves. If a hacker decides to attack the accounts on your system, bad passwords are almost as bad as no passwords at all.

There are several things you can do to ensure that the password facility is providing the best protection it is capable of:

The first item is self-explanatory; we look at the others in detail.

Shadow password files are designed to correct the security hole resulting from the normal password file being world-readable. Everyone needs to be able to view the contents of /etc/passwd so that things like file ownership displays properly (UIDs are translated into usernames). However, since the file is readable, anyone can make a copy of it. This means someone with legitimate or illegitimate access to an ordinary user account can copy it and attempt to crack the passwords of more powerful accounts at his leisure.

A shadow password file facility removes the encoded passwords from the normal password file and places them in another file, conventionally /etc/shadow, which can be read only by root. The shadow package provides shadow password file capabilities for a variety of UNIX systems including Linux. It is included in some Linux distributions by default. It includes replacements for the login, passwd, and su commands as well as many utilities for creating and manipulating the shadow password file and account entries within it.

Building the shadow package is quite straightforward. If you've retrieved a version that has been ported to Linux, you'll generally only have to modify the config.h file. I recommend the following settings (culled from various points within that file):

/* Use shadow password file.      */
#define SHADOWPWD
/* Use up to 16 char. passwords.  */
#define DOUBLESIZE
/* Enable password aging checks.  */
#define AGING
/* Log events to syslog facility. */
#define USE_SYSLOG
/* Support for remote logins.     */
#define RLOGIN
#define UT_HOST
/* Data file for most recent login time records */
#define LASTFILE "/var/adm/lastlog"

Once the package is built and installed, the pwconv command may be used to create an initial /etc/shadow file. It creates the files /etc/npasswd and /etc/nshadow. The former is an altered version of the original password file in which the password field in each entry has been replaced by an x; the latter is the corresponding shadow password file. In order to activate them, you must rename them by hand:

# cd /etc
# mv passwd passwd.prev
# cp npasswd passwd
# cp nshadow shadow

Users don't like to change their passwords, and left to their own devices they will literally never do so. The shadow package includes an optional password aging facility which enables a system administrator to specify how often users must change their passwords. Whether using these features is necessary or not depends on the needs of your site.

Entries in /etc/shadow have the following format:

username:password:change_date:min_change:\
 max_change:warn:inactive:expire:

where the first two fields are the username and encoded password for the account. The other fields relate to account expiration and password aging. [Note that in the shadow file, it cannot be continued across two lines, as we have done here to make it fit in the magazine—ED]

change_date encodes the date of the most recent password change. min_change and max_change indicate the minimum and maximum number of days between password changes, and warn indicates the number of days before a password expires that the user is warned of this fact. inactive specifies how many days after its password has expired that an account is automatically disabled, and expire encodes the date upon which the account itself will expire and be disabled.

Here is a sample entry from /etc/shadow:

chavez:XdleIqAert:9422:7:180:5:21::

User chavez can keep the same password for at most 180 days, and she will be warned 5 days before her password expires. When she does change her password, she must keep the new one for at least 7 days. If she doesn't use her account for 21 days, it will be automatically disabled. No expiration date is set for user chavez's account.

Once /etc/shadow is installed, it can be edited directly. However, the shadow package also provides tools for manipulating entries within it. Its version of the passwd command updates passwords within the shadow password file, and the command also has additional options for modifying the other password settings. For example, the following command changes the minimum password lifetime to 2 days, the maximum password lifetime to 1 year, the warning period to 3 days, and the inactive period to two months for user chavez:

# passwd -n 2 -x 365 -w 3 -i 60 chavez

If you wanted to remove all aging controls from an account, use this combination of options:

# passwd -n 0 -x 99999 -i -1 angela

These are the default values (along with a warning period of 14 days, which is irrelevant when passwords essentially never expire).

Account expiration dates are set with the usermod command. The following command sets the account expiration date to January 1, 1999 for user chavez:

# usermod -e 1/1/1999 chavez

Note that the useradd and usermod commands may also be used to create user accounts and specify or alter these and other account settings.

passwd's -l and -uoptions may be used to manually lock (i.e., prevent logins) and unlock an account respectively:

# passwd -l badboy

Finally, the chage -d command may be used to force a user to change his password at his next login; this option sets the date of the last password change field. It may be used to force a password change at a user's next login, provided that a maximum password lifetime is also set. Here is a simple script which accomplishes this:

#!/bin/csh
# force_change username -- run as root
chage -l $1 >& /dev/null
if ($status == 1) then
   echo force_change: invalid user "\$1\"
   exit 1
endif
set max=`grep ^$1\: /etc/shadow | \
  awk -F: '{print $5}'`
chage -d `date +%D` $1
set today=`grep ^$1\: /etc/shadow | \
  awk -F: '{print $3}'`
set yest=`expr $today - 1`
if ($max >= $yest) set max=`expr $yest - 1`
set date=`expr $yest - $max`
chage -M $max -I 2 -W 7 -d $date $1

The script extracts the current maximum password lifetime setting, sets the password change date to today, and then extracts the equivalent integer value (the number of days since 1/1/1970). It then sets the password change date to yesterday, reducing the maximum lifetime if necessary so that a password expiration is possible on that date. It also sets the inactivity period to 2 days and the warning period to 1 week.

Default settings for password aging settings are defined in the configuration file for the shadow package, usually defined as /etc/login.defs. This file contains a variety of entries which control various aspects of how the package functions, all well-documented in its comment lines, and you should examine this file carefully and select settings which make sense for your system.

Here are some of the most important entries from this file, along with my suggestions for their values:

# Enable dialup passwords.
DIALUPS_CHECK_ENAB      yes

# Track login failures in /var/adm/faillog.
FAILLOG_ENAB            yes
LOG_UNKFAIL_ENAB        yes

# Track login times in /var/adm/lastlog.
LASTLOG_ENAB            yes

# Enable password obscurity checking.
OBSCURE_CHECKS_ENAB     yes

# Enable login time restrictions (/etc/porttime).
PORTTIME_CHECKS_ENAB    yes

# Specify the su log file.
SULOG_FILE      /var/adm/sulog

# Enable use of /etc/nologin file to prevent
# non-root logins. The contents of the file
# is displayed as an error message.
NOLOGINS_FILE   /etc/nologin

# Password aging settings.
PASS_MAX_DAYS   186
PASS_MIN_DAYS   7
PASS_WARN_AGE   14

# Set minimum password length.
PASS_MIN_LEN    12

Making sure that all accounts have passwords that are changed regularly is only part of what is necessary to get the maximum protection from passwords. Passwords must also remain secret, and they must be hard to guess—for either a program or a human—to be most effective. The first of these can only be ensured by educating users about the importance of passwords to system security. It is possible to have a little more control over the second.

Bad password choices include all correctly-spelled words, proper names, and names or numbers significant to the person choosing the password, as well as simple transformations of any of these items: reversals, simple capitalization changes, rotations, adding a digit at the end, and the like.

Good passwords include a variety of character types—upper and lowercase letters, numbers and symbols, and control characters. Longer passwords are also better than shorter ones. I strongly recommend enabling the shadow package's double-length password capabilities, setting a minimum length of 10 or 12 characters and allowing up to 16.

The shadow package has only minimal capabilities for checking the qualities of the password that users choose. However, there are other packages which provide this function by substituting an alternate version of the passwd command. The npasswd package can check proposed passwords against words in online dictionaries. The passwd+ package checks proposed passwords against one or more dictionaries, and also tests transformations of the proposed passwords according to instructions provided by the configuration file. The file /etc/passwd.test can be customized by the system administrator. Listing 1 gives some sample entries from the file which will give you a sense of passwd+'s capabilities.

# sample passwd+ configuration file
# Test                          Error Message
#
(%#a==8)&((%#c==0)|(%#w==0))    Include a capital letter or numeral.
(%#l>5)|(%#c==0)                Must include a nonalphabetic character.
#
"%*p"=~"^%*u$"                  Can't use username as password.
"%*p"=~"^%-*u$"                 Can't use reversed username as password.
"%*p"=~"^%*f%*f$"               Can't use doubled first name as password.
#
{tr A-Z a-z < /usr/dict/words} =~ "%*p"   Password found in dictionary.

Each entry lists a type of unacceptable password and gives an appropriate error message to be displayed to the user if such a password is proposed. The following symbols are used in the sample rules defining unacceptable passwords (passwd+ offers many more as well):

<ul>
<li>%p  proposed password
<li>%a  alphanumeric character
<li>%l  lowercase letters
<li>%c  capital letters
<li>%w  numerals
<li>%u  username
<li>%f  first name
<li>%-x reversed version of x (e.g. %-p =
reversed proposed password)
<li>%*x lowercased version of x
<li>%#  number of x's in proposed password
(e.g. %#w = # of numerals)
<li>&   logical AND
<li>|   logical OR
<li>==  equals
<li>=~  matches pattern
<li>^   beginning of line
<li>$   end of line
</ul>

The first section of the sample file checks structure of the proposed password. The first entry rejects 8-character all-lowercase passwords, and the second entry says that passwords containing 6 or more lowercase letters must also contain a capital letter.

The second section of the file tests the password against items from the user's password file entry as well as some transformations of them. The third section performs a case-insensitive comparison of the password with the words in the system's dictionary file.

By default, passwd+ is designed to be used as a stand-alone replacement for the normal passwd command, and it is not aware of the shadow password file. However, it is not very difficult to modify it for use on systems with shadow passwords; one method involves modifying the obscure routine in the shadow package to call the verify routine in the passwd+ package.

You can also use the Crack facility to check the quality of users' existing passwords. (Note that it is unethical to run Crack without permission on the password file from systems where you are not the system administrator!) Crack is easy to build and use, and it includes a shadmrg utility (in its Scripts subdirectory) which can reconstruct a traditional /etc/passwd-style file on a system using the shadow package. For example:

# cd /usr/src/Crack*
# Scripts/shadmrg > passwd.test
# Crack passwd.test

If you choose to use Crack, it is extremely important to ensure that the program and all of the data and results files that it creates are protected against all non-root access.

In some circumstances, you may want to use some means of determining that a user is who she says she is in addition to standard passwords. To address such a need, the shadow package also supports entries like the following in /etc/shadow:

chavez:XdleIqAert;@/sbin/extra:9422:7:180:5:21::
harvey:<\@>/sbin/extra:9233:0:99999:0:-1::

When user chavez logs in, she is prompted for her password, and then the program /sbin/extra runs as a secondary authentication program. This program, supplied by the system administrator, can perform whatever sort of additional authentication is desired, returning a value of 0 or 1 depending on whether the user has passed or failed. The second entry indicates that user harvey runs /sbin/extra as his only authentication method. In the shadow file syntax, the @ sign introduces the alternate or additional authentication program, and a semicolon is used to separate it from the encoded password.

The final feature of the shadow package we consider is its dialup password facility, which allows you to require an additional password from users who connect to the system via a dialup line. When this feature is enabled, two additional configuration files are used, /etc/dialups and /etc/d_passwd. /etc/dialups contains a list of special filenames for serial lines that are to be protected with an additional password whenever someone dials into the system (one per line), and /etc/d_passwd holds the encoded dialup passwords.

Dialup passwords are assigned on a shell-by-shell basis, and the dpasswd command is used to create and change them. For example, the following command will allow you to change the current dialup password for the shell /bin/bash:

# dpasswd /bin/bash

Dialup passwords will not be required from users using shells that are not listed in /etc/d_passwd.

One of the biggest weaknesses with UNIX security in general is its all-or-nothing approach to system privilege: root is powerful, so it is only prudent to limit access to the root account as much as possible. The sudo facility enables non-root users to run specified commands as root without having to know the root password, allowing a system administrator to provide users with just the level of access they actually need.

A user uses the facility by prefacing the command he wants to run with the sudo command:

$ sudo mount hamlet:/data /mnt

:sudo will require the user to enter his own password before completing the command. Thus, in this case, using sudo allows this user to use the mount command without knowing the root password.

Access to sudo is controlled by its configuration file, /etc/sudoers. This file specifies which users can use sudo along with the commands they are allowed to execute. Here is a small extract from such a file:

chavez  ALL=ALL
harvey  ALL=/bin/mount,/bin/umount
nelson  ALL=!/sbin/shutdown

Usernames are the first field in each entry, followed by one or more access description strings which have the general form: host(s)=command(s). Based upon these entries, user chavez can use sudo to run any command on any system, user harvey can mount and unmount disks, and user nelson can run any command except shutdown. Note that these examples represent only the simplest form of this file; its actual syntax is very flexible and powerful, allowing you to define named groups of hosts and/or commands and thereby specify exact access for each user-host-command combination in as much detail as necessary.

Books

Practical Internet and UNIX Security, (2nd edition of Practical UNIX Security), Simson Garfinkel and Gene Spafford (O'Reilly & Associates, late 1995 or early 1996). An excellent book-length treatment of system security and the associated system administrative concerns and tasks.

Essential System Administration, 2nd edition, Æleen Frisch (O'Reilly & Associates, 1995). A substantial chapter is devoted to system security, as are numerous additional sections throughout the book.

Firewalls and Internet Security, William R. Cheswick and Steven M. Bellovin, (Addison-Wesley, 1994); Building Internet Firewalls, D. Brent Chapman and Elizabeth D. Zwicky (O'Reilly & Associates, 1995). Two essential books for anyone considering setting up a firewall system.

Security Alerts Mailing Lists

The Computer Emergency Response Team (CERT) manages the primary UNIX-related security-alert system. Send mail to cert-advisory-request@cert.org to be added to the mailing list. Past advisories and updates are available via anonymous ftp at info.cert.org:/pub/cert_advisories.

There is also a Linux-specific security advisory mailing list. Send mail to majordomo@linux.nrao.edu with subscribe linux-alert in the body of the message to be added to the list. You may also want to subscribe to the linux-security mailing list, which is a moderated discussion list for Linux-related security topics. (To subscribe, include subscribe linux-security in the body of a message to the same email address.) The archives for these mailing lists are available via anonymous ftp at linux.nrao.edu:/pub/linux/security/list-archive.