Problem solve Get help with specific problems with your technologies, process and projects.

Account locking for Linux via PAM

Discover how to configure account blocking on a Red Hat host with PAM and prevent a potential denial-of-service attack caused by repeated locking of user accounts.

Most Windows systems have an administrative ability to lock user accounts after too many login failures. But did

More security tips from James Turnbull:
The Linux desktop: Browser and distro security tips

Passphrases instead of passwords on Red Hat, part 1
you know that you could also enable this functionality on your Linux hosts using PAM? In this tip, I'll show you how to configure account blocking on a Red Hat host and how to prevent a potential Denial of Service attack from the repeated locking of user accounts.

To provide the account locking functionality, we need to add a PAM module called pam_tally to the system-auth file in the /etc/pam.d directory. This file handles user authentication and login for Red Hat. We need to add two references to this module in the system-auth file, one in the auth section that will turn on logging of failed login attempts, and a second in the account section that will actually do the account locking.

auth required /lib/security/$ISA/ onerr=fail no_magic_root
account required /lib/security/$ISA/ deny=4 no_magic_root reset per_user

The first auth line will log login failures to the /var/log/faillog file. You will need to create the file before the changes will operate:

# touch /var/log/faillog

The deny option on the second line of our example will lock accounts after four failed login attempts as a default; you can specify the number of attempts that suit you. The no_magic_root option ensures that accounts with a UID of 0 are tallied. You can change this option to magic_root to reverse this behaviour. The reset option indicates that the login failure count will be reset to 0 if a successful login takes place.

The last option, per_user, allows you to exclude accounts from locking if the accounts have a maximum login failure set explicitly. This exclusion of accounts allows you to specify some accounts that won't be locked and thus prevent them being the target of a potential Denial of Service attack. I recommend you exclude any accounts whose disablement will cause availability issues for applications or databases, for example the user account that runs a database process. Account exclusion are specified using the faillog command:

# faillog -u mysql -m –1

The -u option specifies the user and the -m option specifies the maximum attempts. Specifying -1 tells the pam_tally module to exclude that user from locking. Setting the -m value to 0 will re-enable locking behaviour for that user.

Running the faillog command without options will display all recent failed login attempts.

Username Failures Maximum Latest
james  0  -1  Tue Aug 22 00:53:26 +1000 2006 on

You can also use the faillog command to unlock a locked account like so:

# faillog -u james –r

Or you can use the passwd command with the -l option to unlock accounts.

Several applications won't work with pam_tally because they can't write to the /var/log/faillog file. The most common example of this is xscreensaver. Two things can correct this. The first method is to change the onerr value from fail to succeed, so that when the application fails to write to the file, it doesn't fail the whole module. This method, however, means that other errors might be overlooked.

The second method is to create or edit a PAM file for the affected programs that excludes the pam_tally functionality. Because many of these applications also use pam_stack to call the system-auth file, you can easily adjust them to use the contents of the system-auth file without the pam_tally line.

James Turnbull is an experienced infrastructure architect with a background in Linux/Unix, AS/400, Windows and storage systems. He has been involved in security consulting, infrastructure security design, SLA and service definition and has an abiding interest in security metrics and measurement.

Dig Deeper on Linux servers