Lock Accounts After Failed Password Attempts
Configures pam_faillock to lock an account after at most 3 consecutive failed authentication attempts (deny ≤ 3).
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
Without a lockout threshold, an attacker can try passwords indefinitely until one works. Capping consecutive failures at 3 and locking the account makes online brute-force and password-spraying attacks impractical, while still tolerating the occasional typo from a legitimate user.
What Pavois checks
Pavois reads the effective faillock setting by merging /etc/security/faillock.conf with every drop-in under /etc/security/faillock.conf.d/ and taking the last deny value (the one PAM actually applies), then requires it to be 1-3. Honoring drop-in precedence is exactly what a naive single-file read would miss: a permissive override in a .d file would silently defeat a stricter main config.
describe command('v=$(grep -rh \'^[[:space:]]*deny[[:space:]]*=\' /etc/security/faillock.conf /etc/security/faillock.conf.d/ 2>/dev/null | tail -1 | grep -oE \'[0-9]+\'); { [ -n "$v" ] && [ "$v" -le 3 ] && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Inspect the merged value with grep -rh '^[[:space:]]*deny' /etc/security/faillock.conf /etc/security/faillock.conf.d/ | tail -1 (expect deny = 3 or lower). Check live lockout state for a user with faillock --user <name>. Re-running the InSpec command should print ok.
Inspect & investigate
Failed attempts and lockouts appear in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family), or via journalctl -t sshd -t login. Per-user counters and lock status are shown by faillock --user <name>; clear them with faillock --user <name> --reset.
Remediation
pavois harden apply uses the keyval resource to write deny = 3 into the drop-in /etc/security/faillock.conf.d/99-Pavois.conf. Because that drop-in is read last, it deterministically wins over any laxer setting in the main file, enforcing the lockout threshold for all PAM-based logins.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| file | /etc/security/faillock.conf |
|---|---|
| key | deny |
| resource | keyval |
| value | 3 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk of self-inflicted lockout: a forgotten password or an automated job using stale credentials can lock a real account after 3 failures, and locking out root/admin accounts can block remote recovery. Before applying, confirm you have an out-of-band console or a second privileged account, and know that faillock --user <name> --reset unlocks an account. Consider that brute-force tooling against SSH can rapidly trip this threshold for targeted users.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R31 | direct | 2.0 | high |
| CIS | 5.3.3.1.1, 8.3.4 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.8, AC-7(a), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.3.4 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-411045, UBTU-24-200610 | direct | per OS STIG release | 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.