Rendre la configuration de auditd immuable
Garantit que le sous-système d'audit est verrouillé avec -e 2 afin que le jeu de règles chargé soit immuable jusqu'au prochain redémarrage et ne puisse être modifié à chaud.
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
Rendre la configuration d'audit immuable empêche toute modification accidentelle comme malveillante des règles d'audit à chaud. Un attaquant ayant obtenu les droits root pourrait sinon désactiver l'audit (auditctl -e 0) ou supprimer des règles pour agir sans être détecté. Avec -e 2, tout changement exige un redémarrage, lui-même un événement auditable et remarquable. Le compromis : les changements légitimes de règles nécessitent aussi un redémarrage.
Ce que vérifie Pavois
Pavois exécute auditctl -s et vérifie que le noyau renvoie enabled 2. Lire l'état d'audit vivant vaut mieux qu'inspecter la ligne finale -e 2 d'un fichier de règles : le drapeau d'immuabilité n'est effectif qu'une fois appliqué par le noyau. Un fichier contenant -e 2 jamais chargé laisse le système modifiable ; auditctl -s montre l'état réel appliqué.
describe command('auditctl -s') do
its('stdout') { should match(/enabled[[:space:]]+2/) }
endComment vérifier qu’elle est appliquée
Exécutez auditctl -s | grep enabled. La sortie attendue est enabled 2 (1 = activé mais modifiable, 0 = désactivé). Une fois immuable, auditctl -e 0 est refusé jusqu'au redémarrage.
Inspecter et investiguer
auditctl -s indique l'état vivant (enabled, drapeau, backlog). Les messages de service apparaissent via journalctl -u auditd, et toute tentative de modifier les règles en mode immuable est refusée (remontée au processus appelant comme une erreur).
Remédiation
Le plan de durcissement de Pavois utilise la ressource audit_ruleset pour ajouter la directive -e 2 comme dernière ligne du jeu de règles chargé (elle doit venir en dernier, après toutes les règles). Comme l'immuabilité ne prend effet qu'au prochain démarrage, un redémarrage est nécessaire. Exécutez pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Une fois appliqué, le jeu de règles d'audit est figé : vous ne pouvez plus ajouter, retirer ou recharger de règles sans redémarrer. Appliquez cette règle en dernier, uniquement après que toutes les autres règles d'audit sont en place et vérifiées, sinon vous figez un jeu de règles incomplet et devez redémarrer pour corriger. Elle n'affecte ni les connexions ni les services. Sur les systèmes nécessitant des changements fréquents de règles d'audit, pesez le coût opérationnel du redémarrage obligatoire.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | haute |
| CIS | 10.3.2, 6.2.3.20, 6.3.3.33, 6.3.3.20, 6.3.3.21 | direct | per OS, see the benchmark table | haute |
| NIST | 3.3.1, AC-6(9), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.3.2 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-24-909000 | 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.