System Administation: Maximizing System Security, Part 1

A lot of UNIX security is based on passwords, and in this first part of a two-part article, Æleen helps explain many of thei issues involved in setting up and maintaining passwords on Linux systems. Next month's installment will cover other system security issues.
shadow's Configuration File

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
Selecting Good Passwords

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix