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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState