Enforcing Linux Account Lockout Policies with PAM Faillock against Brute Force

1. Pluggable Authentication Modules (PAM) Workflows

Pluggable Authentication Modules (PAM) provide a centralized authentication framework for Linux operating systems. Services like SSH, local console logins, sudo, and FTP pass authentication requests to PAM modules.

When pam_faillock is configured, PAM intercepts authentication attempts before password checking occurs.

If a user exceeds the allowed failed attempt threshold, pam_faillock denies authentication immediately without verifying the password, mitigating credential guessing attacks.

Centralized PAM policies ensure consistent lockout enforcement across all system authentication interfaces.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# Inspect PAM security configuration directory
ls -la /etc/pam.d/
ls -la /etc/security/faillock.conf

2. Migrating from Deprecated pam_tally2 to pam_faillock

Legacy Linux distributions relied on pam_tally and pam_tally2 for account lockout policies. Modern distributions (RHEL 8/9, Ubuntu 22.04+, Debian 12+) have deprecated pam_tally2 in favor of pam_faillock.

Unlike pam_tally2, pam_faillock stores tally files in a secure binary format inside /var/log/faillock/ and provides enhanced denial directives.

Migrating to pam_faillock guarantees long-term compatibility with current Enterprise Linux security baselines.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# Check if pam_faillock is installed
faillock --version

3. Hardening /etc/security/faillock.conf

Configure global account lockout parameters inside /etc/security/faillock.conf.

The deny directive sets the maximum number of failed attempts before lockout. Setting unlock_time = 900 specifies a 15-minute temporary lockout window.

The fail_interval directive defines the sliding window during which consecutive failures accumulate.

Enabling silent suppresses informative error messages, preventing user enumeration by unauthenticated attackers.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# /etc/security/faillock.conf
dir = /var/log/faillock
deny = 5
fail_interval = 900
unlock_time = 900
even_deny_root
root_unlock_time = 1800
silent

4. Integrating Modules in /etc/pam.d/ Entries

Enable pam_faillock inside system-auth and password-auth files in /etc/pam.d/.

The auth stack requires pam_faillock preauth before pam_unix, and pam_faillock authfail after pam_unix to record failures accurately.

Placing preauth first allows PAM to block locked accounts before executing expensive password hashing operations.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# Example /etc/pam.d/common-auth snippet
auth    required                    pam_faillock.so preauth silent
auth    [success=1 default=ignore]  pam_unix.so nullok
auth    [default=die]               pam_faillock.so authfail
auth    sufficient                  pam_faillock.so authsucc

5. Root Account Protection & Lockout Safeguards

Enabling even_deny_root applies lockout policies to the root account as well, preventing root password guessing via local console or SSH.

Set root_unlock_time to a longer duration (e.g., 30 minutes) to deter automated root brute force while allowing legitimate emergency access recovery.

Always maintain active SSH key access before testing root lockout policies to prevent administrative lockouts.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# Verify faillock root lockout configuration
cat /etc/security/faillock.conf | grep root

6. Administration: Auditing Tally Logs & Account Unlocking

Administrators can inspect failed login records and manually reset locked accounts using the faillock command line tool.

Audit failed login tallies periodically to detect emerging brute-force attack trends.

Operating systems hardening requires continuous verification of process behavior, ensuring that isolated daemons remain tightly bounded within their security domains without degrading performance.

# View failed login attempts for user 'ubuntu'
faillock --user ubuntu

# Reset failed login count and unlock account immediately
faillock --user ubuntu --reset

Written by Zyekh Abdul Qadir Jailani

Digital Forensics & Incident Response (DFIR) Specialist & Security Researcher specializing in Linux kernel hardening, threat hunting, and system security research.

LinkedIn • GitHub • Discord • Email • PGP Key