Record Attempts to Alter Logon and Logout Events - faillock
Ensures auditd has an active rule tagged logins that watches the login records (/var/log/lastlog, /var/run/faillock) so any tampering with logon/logout history is recorded.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
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
The files that track login/logout activity and failed-login counters (faillock) are prime targets for attackers covering their tracks. Manual editing of these files may indicate nefarious activity, such as an intruder removing evidence of an intrusion or resetting lockout counters. Auditing writes to them preserves the forensic record.
What Pavois checks
Pavois runs auditctl -l and checks for a loaded rule carrying the logins key. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule present in a file but not loaded gives false assurance. auditctl -l reflects only what the kernel enforces now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)logins\b/) }
end
describe command("grep -rhwsE 'logins' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run auditctl -l | grep logins. You should see watch rules such as -w /var/log/lastlog -p wa -k logins and -w /var/run/faillock -p wa -k logins. Empty output means the rule is not loaded.
Inspect & investigate
Triggered events land in /var/log/audit/audit.log. Search with grep 'key="logins"' /var/log/audit/audit.log. Actual login activity is also visible via last, lastb and journalctl -u systemd-logind (prefer grep over ausearch -k logins, which can wrongly report no matches).
Remediation
Pavois's harden plan uses the audit_ruleset resource to write the login-record watch rules into /etc/audit/rules.d/, then reloads auditd. Because the audit config may be immutable, a reboot is required to fully apply. Run pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without this rule, tampering with login history and lockout counters goes undetected. The rule is log-only and cannot block logins, so it breaks nothing. Precautions: every login/logout and every failed-auth touches these files, generating steady volume, size audit.log rotation and space_left_action so a full disk does not halt the host when auditd is set to halt.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 10.2.1.3, 6.2.3.12, 6.3.3.21, 6.3.3.12 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7, AC-6(9), AU-12(c), AU-2(d), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.2.1.3 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-654210, UBTU-22-654215, UBTU-24-900250, UBTU-24-900260 | 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.