Vérifier les permissions de /etc/audit/rules.d/*.rules
Garantit que chaque fichier *.rules de /etc/audit/rules.d/ n'est pas plus permissif que 0640 (aucun droit d'écriture groupe/autres, aucune lecture autres, aucun bit spécial).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
Les fragments *.rules de /etc/audit/rules.d/ déclarent quels appels système, fichiers et événements auditd surveille, ils sont compilés en jeu de règles actif au démarrage. S'ils sont modifiables par le groupe ou les autres, un attaquant peut supprimer ou affaiblir des règles pour rendre le système aveugle à ses actions ; s'ils sont lisibles par les autres, ils révèlent exactement ce qui est (ou non) surveillé, facilitant l'évasion. Les restreindre à root rend la politique d'audit inaltérable et confidentielle.
Ce que vérifie Pavois
Pavois exécute find /etc/audit/rules.d -name "*.rules" -perm /0137 et attend un résultat vide : le masque /0137 capture tout fichier portant l'écriture groupe, la lecture/écriture autres ou un bit d'exécution. Comme il parcourt le répertoire au moment de l'audit plutôt que de se fier à un gabarit de paquet, il détecte les nouveaux fragments déposés par Ansible, une cookbook ou un opérateur, le même angle mort de drop-in qu'oublient les scanners de gabarits.
only_if { file('/etc/audit/rules.d').exist? }
describe command('find /etc/audit/rules.d -name "*.rules" -perm /0137 2>/dev/null') do
its('stdout') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez find /etc/audit/rules.d -name '*.rules' -perm /0137 -ls. La sortie attendue est vide (tous les fragments sont en 0640 ou plus strict, appartenant à root). Toute ligne affichée désigne un fichier non conforme. Vous pouvez aussi confirmer avec stat -c '%a %n' /etc/audit/rules.d/*.rules et attendre un mode 640 ou inférieur pour chacun.
Inspecter et investiguer
auditd compile ces fragments au démarrage ; vérifiez journalctl -u auditd et auditctl -l pour confirmer le chargement des règles attendues, et /var/log/audit/audit.log (grep CONFIG_CHANGE) pour toute altération. Une correction de permissions consécutive à une modification de règle doit être suivie de augenrules --load.
Remédiation
Le plan de durcissement de Pavois lance une ressource exec nommée chmod-audit-rulesd : chmod 0640 /etc/audit/rules.d/*.rules, protégée par un not_if qui relance le même find, ce qui en fait un no-op une fois conforme (idempotent). Appliquez-le avec pavois harden apply. Il ne recharge pas auditd ; exécutez donc augenrules --load (ou redémarrez auditd) ensuite si les règles ont changé.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | chmod 0640 /etc/audit/rules.d/*.rules 2>/dev/null || true |
|---|---|
| name | chmod-audit-rulesd |
| not_if | test -z "$(find /etc/audit/rules.d -name '*.rules' -perm /0137 2>/dev/null)" |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Appliquer 0640 aux fragments de règles est sûr, auditd les lit en root. Précautions : la remédiation ne fait que durcir les permissions, sans jamais modifier le contenu des règles, donc la couverture de surveillance n'est pas affectée. Vérifiez ensuite qu'auditd charge toujours la politique avec auditctl -l. Le seul risque viendrait d'une mauvaise édition de règle sans rapport ; le chmod lui-même ne peut provoquer aucun blocage. Laisser les fragments modifiables par le groupe ou les autres permettrait à un processus non privilégié de désactiver silencieusement l'audit. Parcours de repertoire (RHEL) : /etc/audit/rules.d est un repertoire, conservez son bit de parcours proprietaire (0750) ; un 0600/0640 de style fichier retire le x, et sous SELinux enforcing auditd se voit refuser dac_read_search et echoue au demarrage. Retablissez avec chmod 750 /etc/audit/rules.d && restorecon -R /etc/audit.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.2.4.5, 6.3.4.5 | direct | per OS, see the benchmark table | haute |
| NIST | AU-12(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| DISA STIG | UBTU-22-653065, UBTU-24-900040 | 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.