Ensure pam_faillock module is enabled
Ensures pam_faillock.so is present in the PAM auth stack so failed login attempts are counted and accounts are locked after too many failures.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Locking out user IDs after a number of unsuccessful consecutive login attempts mitigates brute-force password attacks against the system. Without pam_faillock, an attacker can try passwords indefinitely at machine speed; the module is the enforcement point that turns a lockout policy into an actual control.
What Pavois checks
Pavois greps the effective PAM stack under /etc/pam.d/ for an active (non-commented) pam_faillock.so line. Because PAM assembles its stack from common-auth and @include chains, checking the resolved set of files catches the case where the module is declared in one place but stripped by a drop-in, something a single-file scan would not see.
describe command('grep -RqE \'^[^#]*\bpam_faillock\\.so\b\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run grep -rE '^[^#]*pam_faillock\.so' /etc/pam.d/; at least one active auth line should reference the module (typically two: a preauth and an authfail entry). faillock should also run without error and report per-user counters.
Inspect & investigate
Tracked failures and lockouts appear in /var/log/auth.log (Debian/Ubuntu). Per-user state is shown by faillock --user <name> and cleared with faillock --user <name> --reset.
Remediation
pavois harden apply uses the pam_faillock resource to enable the module: it inserts the required preauth/authfail lines into the auth stack through the distro's PAM tooling (pam-auth-update on Debian/Ubuntu) so the configuration is correct and persistent across PAM updates.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| params | audit silent even_deny_root |
|---|---|
| resource | pam_faillock |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A misplaced or duplicated pam_faillock.so line can lock out legitimate users, or even all of them, and an overly tight threshold enables trivial denial-of-service by spoofing failures against known usernames. Precautions: keep a root/console session open while editing PAM, validate login from a second terminal before disconnecting, set a reasonable deny/unlock_time, and keep faillock --reset handy to recover a locked account.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.3.2.2 | direct | per OS, see the benchmark table | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.