[ LINUX SECURITY & AUTH OPS ]

Linux PAM & Faillock Policy Generator

Generate production-grade PAM authentication stacks and pam_faillock account lockout policies to defend against brute-force attacks and credential spraying 100% offline.

[ SPECIFICATION // SECURITY ]: Linux PAM authentication configuration generator. Configures faillock brute-force defense, pwquality password complexity enforcement, and login session limits.
Standard: Linux-PAM (Pluggable Authentication Modules) Architecture [ VERIFIED // LOCAL EXECUTION ][ ZERO TELEMETRY ][ OFFLINE PWA ][ OPEN SOURCE // MIT ]
Brute-Force Resilience Metric
Max 3 Tries / 15m Lockout
[ HIGH RESILIENCE ]

[ 1. THRESHOLD & INTERVAL DIRECTIVES ]

3
900s (15 min)
900s (15 min)
1800s (30 min)
[ ADVANCED SECURITY DIRECTIVES ]

[ 2. LIVE CONFIGURATION EXPORT ]

# Generating PAM Faillock configuration...
[ DEPLOYMENT NOTE ]: On modern Linux distros (Ubuntu 22.04+, Debian 12+, RHEL 9+), /etc/security/faillock.conf applies system-wide automatically.

Architecture: Linux Pluggable Authentication Modules (PAM) & Faillock

The Linux Pluggable Authentication Modules (PAM) architecture provides dynamic, modular authentication abstraction across SSH, console login, `sudo`, and display managers. pam_faillock replaces the deprecated pam_tally2 module, tracking consecutive failed authentication attempts in transient tally databases under /var/run/faillock/ or /run/faillock/.

Key Security Directives Explained

even_deny_root & root_unlock_time

By default, PAM exempts the root account from lockout to prevent Denial-of-Service (DoS) attacks where an attacker intentionally locks out administrative access. Enabling even_deny_root combined with a dedicated root_unlock_time protects SSH jump hosts from root dictionary brute-force while allowing automated recovery.

silent & User Enumeration Defense

When an account is locked out, PAM can display explicit messages like "Account locked due to 3 failed logins". Enabling the silent directive suppresses these messages, preventing external attackers from identifying which usernames exist on the target system.

Managing Locked Accounts with the faillock CLI

Administrators can inspect and reset authentication tally records instantly without restarting any daemons:

# View authentication failure records for a user:
$ faillock --user devops_admin

# View failure records across all accounts:
$ faillock

# Reset / unlock a specific user account:
$ sudo faillock --user devops_admin --reset

# Reset all locked accounts on the host:
$ sudo faillock --reset
[ AUTHENTICATION & ACCESS CONTROL ]

Linux PAM faillock & Account Lockout Policy Guide

Understand internal PAM authentication stacks (auth, account, password, session) and execute a clean migration from legacy pam_tally2 to modern pam_faillock.

PAM faillock Configuration Guide ->Zero-Trust SSH Access Architecture ->

Frequently Asked Questions (FAQ)

What is the difference between 'required' and 'sufficient' control flags in PAM?
A 'required' module must succeed for authentication to pass (but evaluation continues upon failure), whereas a 'sufficient' module immediately grants authentication on success without evaluating subsequent modules.
How does pam_faillock protect SSH against brute-force attacks?
pam_faillock tracks authentication failures per user account and automatically locks out the account for a defined duration (unlock_time) once the failure threshold (deny) is reached.
Why is pam_pwquality preferred over legacy pam_cracklib?
pam_pwquality is the modern successor to pam_cracklib, offering richer password entropy scoring, integrated dictionary lookups, and enterprise policy compatibility.
How can I test new PAM configurations safely without lockout?
Always maintain an active root SSH session in a separate window as a backup, test new configurations in a fresh terminal session, and inspect /var/log/auth.log or /var/log/secure.
Copied to clipboard!