Configurer l'exécution périodique d'AIDE par un timer systemd
Garantit qu'AIDE s'exécute selon un planning via un timer systemd activé (aidecheck.timer ou dailyaidecheck.timer).
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
AIDE ne détecte une altération que lorsqu'il s'exécute réellement et compare à sa référence ; il ne se planifie pas lui-même. Un service systemd qui effectue la vérification, plus un timer qui le déclenche régulièrement, transforme AIDE d'un instantané ponctuel en une surveillance d'intégrité continue. Sans exécution périodique, une modification non autorisée pourrait persister indétectée indéfiniment.
Ce que vérifie Pavois
Pavois interroge systemctl is-enabled pour aidecheck.timer/dailyaidecheck.timer et exige qu'au moins un soit enabled. Interroger systemd reflète l'état de planification effectif résolu depuis les fichiers d'unité et les drop-ins, qu'un scan fichier de /etc/cron* manquerait entièrement puisque la planification réside ici dans systemd, pas dans 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' }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled aidecheck.timer dailyaidecheck.timer. La sortie attendue contient enabled. Utilisez systemctl list-timers '*aide*' pour confirmer la prochaine exécution planifiée, et systemctl status aidecheck.service pour le dernier résultat.
Inspecter et investiguer
Les déclenchements du timer et les exécutions du service sont dans le journal : journalctl -u aidecheck.service -u aidecheck.timer. La sortie de comparaison d'AIDE va dans /var/log/aide/aide.log et est généralement envoyée par mail à root. systemctl list-timers '*aide*' montre le planning.
Remédiation
Aucun plan de durcissement automatisé n'est fourni ; appliquez-la manuellement. Créez aidecheck.service (exécutant par ex. /usr/bin/aide.wrapper --config /etc/aide/aide.conf --check) et aidecheck.timer (avec un planning OnCalendar= quotidien) sous /etc/systemd/system/, puis systemctl daemon-reload && systemctl enable --now aidecheck.timer.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| 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 localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Cela ajoute un scan d'intégrité planifié ; les principales considérations sont l'usage des ressources et l'horaire. La vérification lit de grandes parties du système de fichiers et peut brièvement augmenter les E/S, planifiez-la donc en heures creuses (par ex. la nuit) et décalez-la sur un parc. Elle doit s'exécuter en root pour lire tous les fichiers. Assurez-vous que la base AIDE (voir misc-aide-build-database) existe d'abord, sinon chaque exécution échouera. Aucun risque de verrouillage ou de disponibilité de service.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R76 | direct | 2.0 | haute |
| CIS | 11.5.2, 6.3.2 | direct | per OS, see the benchmark table | haute |
| NIST | SI-7, SI-7(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 11.5.2 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-24-100120 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.