Configure Systemd Timer Execution of AIDE
Ensures AIDE runs on a schedule via an enabled systemd timer (aidecheck.timer or dailyaidecheck.timer).
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
AIDE only detects tampering when it actually runs and compares against its baseline; it does not schedule itself. A systemd service to perform the check plus a timer to fire it regularly turns AIDE from a one-off snapshot into continuous integrity monitoring. Without periodic execution, an unauthorized change could persist undetected indefinitely.
What Pavois checks
Pavois queries systemctl is-enabled for aidecheck.timer/dailyaidecheck.timer and requires at least one to be enabled. Querying systemd reflects the effective scheduling state resolved from unit files and drop-ins, which a file-based scan of /etc/cron* would miss entirely since the schedule lives in systemd here, not in cron.
describe command('for t in aidecheck.timer dailyaidecheck.timer aide.timer; do systemctl is-enabled "$t" 2>/dev/null; done | grep -q enabled && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run systemctl is-enabled aidecheck.timer dailyaidecheck.timer. Expected output includes enabled. Use systemctl list-timers '*aide*' to confirm the next scheduled run, and systemctl status aidecheck.service for the last result.
Inspect & investigate
Timer triggers and service runs are in the journal: journalctl -u aidecheck.service -u aidecheck.timer. AIDE's own diff output goes to /var/log/aide/aide.log and is typically mailed to root. systemctl list-timers '*aide*' shows the schedule.
Remediation
No automated harden plan ships for this rule; apply it manually. Create aidecheck.service (running e.g. /usr/bin/aide.wrapper --config /etc/aide/aide.conf --check) and aidecheck.timer (with an OnCalendar= daily schedule) under /etc/systemd/system/, then systemctl daemon-reload && systemctl enable --now aidecheck.timer.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Enable a periodic AIDE integrity check (review the unit content first): systemctl list-unit-files | grep -i aide || echo 'create /etc/systemd/system/aidecheck.{service,timer}' # systemctl enable --now aidecheck.timer |
|---|---|
| reason | scheduling AIDE checks is a policy choice (frequency, mail), set it deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This adds a scheduled integrity scan; the main considerations are resource use and timing. The check reads large parts of the filesystem and can briefly raise I/O, so schedule it off-peak (e.g. nightly) and stagger it across a fleet. It must run as root to read all files. Ensure the AIDE database (see misc-aide-build-database) exists first, or each run will fail. There is no lockout or service-availability risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R76 | direct | 2.0 | high |
| CIS | 11.5.2, 6.3.2 | direct | per OS, see the benchmark table | high |
| NIST | SI-7, SI-7(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 11.5.2 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-24-100120 | 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.