Configure the root Account for Failed Password Attempts
Enforces the even_deny_root option on pam_faillock.so so the root account is also locked after repeated failed login attempts.
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
By limiting the number of failed logon attempts, the risk of unauthorized access through password guessing (brute-forcing) is reduced. By default pam_faillock exempts root, leaving the most privileged account open to unlimited guessing; even_deny_root closes that gap so the lockout policy applies to root as well.
What Pavois checks
Pavois greps the effective PAM stack under /etc/pam.d/ for a non-commented pam_faillock.so line carrying even_deny_root. Reading the assembled stack (and its @include chains and drop-ins) rather than one file avoids the false pass where the option exists in a sample but not in the rule path PAM actually evaluates.
describe command('grep -RqE \'^[^#]*\bpam_faillock\.so\' /etc/pam.d/ 2>/dev/null && { grep -RqE \'^[^#]*\bpam_faillock\.so[^#]*\beven_deny_root\' /etc/pam.d/ 2>/dev/null || grep -qE \'^[[:space:]]*even_deny_root\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 auth/account lines include even_deny_root. To prove it, deliberately fail root logins beyond the deny threshold, then check faillock --user root shows the failures (and a locked state).
Inspect & investigate
Root lockout events appear in /var/log/auth.log (Debian/Ubuntu) or /var/log/audit/audit.log (auditd, RHEL). Inspect and reset the root counter with faillock --user root and faillock --user root --reset.
Remediation
No automated remediation is wired for this rule, so it must be applied manually: add the even_deny_root option to the pam_faillock.so lines in your PAM configuration (via pam-auth-update/faillock.conf on Debian/Ubuntu or authselect on RHEL) and regenerate the stack.
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
Locking root out can be dangerous: if a remote attacker (or a mistyped automation) hits the threshold, the only way back may be physical/console access. Precautions: prefer console recovery readiness over relaxing the policy; keep an active root session while editing PAM; combine with a sane unlock window (unlock_time) so the account self-recovers; and remember single-user/recovery mode can always reset counters with faillock --user root --reset.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R31 | direct | 2.0 | high |
| NIST | AC-7(b), CM-6(a), IA-5(c) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| CIS | 5.3.3.1.3 | 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.