Account Lockouts Must Be Logged
Enforces the audit option on pam_faillock.so so every failed authentication that counts toward a lockout is logged.
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 auditing of failed-login events, it is harder (often impossible) to reconstruct what an attacker attempted before or during a brute-force attack. The audit flag makes pam_faillock record the user name for each tracked failure, including for non-existent accounts, giving incident responders the trail they need to detect password-guessing campaigns and identify targeted accounts.
What Pavois checks
Pavois greps the effective PAM stack under /etc/pam.d/ for a non-commented pam_faillock.so line carrying the audit option. Reading the PAM stack as it is actually assembled (auth/common-auth and their includes) beats trusting a single sample file: PAM resolves @include directives and distro-specific drop-ins, so a flag present in one file but overridden or absent in the included one would be missed by a naive single-file check.
describe command('grep -RqE \'^[^#]*\bpam_faillock\.so\' /etc/pam.d/ 2>/dev/null && { grep -RqE \'^[^#]*\bpam_faillock\.so[^#]*\baudit\' /etc/pam.d/ 2>/dev/null || grep -qE \'^[[:space:]]*audit\b\' /etc/security/faillock.conf 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/ and confirm the resulting auth lines contain the audit keyword. You can also trigger a failure (su - someuser with a wrong password) and verify the user name appears in the audit/auth log.
Inspect & investigate
Failed attempts tracked by faillock surface in /var/log/auth.log (Debian/Ubuntu) or via journalctl -u systemd-logind / the PAM-emitting service. On systems with auditd, look in /var/log/audit/audit.log. The live counter per user is shown by faillock --user <name>.
Remediation
pavois harden apply uses the pam_faillock resource: it ensures pam_faillock.so is wired into the auth stack with the audit option set, integrating with the distro's PAM tooling (pam-auth-update on Debian/Ubuntu, authselect on RHEL) so the change survives PAM regeneration.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | pam_faillock |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Enabling auditing of lockouts is low-risk; it only adds log verbosity. The broader risk lies in misconfiguring pam_faillock itself: an incorrectly ordered or duplicated auth line can lock out all users, including root. Precautions: keep an active root/console session open while changing PAM, test authentication from a second terminal before logging out, and know how to clear counters with faillock --user <name> --reset in case of unexpected lockout.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | AC-7 (a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.