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.
Password Aging

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.

______________________

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