Les fichiers de configuration d'audit doivent appartenir au groupe root
Garantit que le répertoire de configuration d'audit /etc/audit appartient au groupe root (gid 0).
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
Le répertoire /etc/audit contient auditd.conf et les fichiers de règles (audit.rules, rules.d/*.rules) qui déterminent quels événements sont enregistrés. Sans restriction sur qui peut les modifier, du personnel non autorisé pourrait désactiver l'audit d'événements critiques, ou mal configurer les règles au point de saturer le journal et de dégrader les performances, rendant plus difficile la corrélation et l'investigation d'un incident. La propriété par le groupe root (gid 0) réserve le contrôle de la politique d'audit aux seuls utilisateurs privilégiés.
Ce que vérifie Pavois
Pavois lit l'identifiant de groupe réel de /etc/audit via la ressource InSpec file et vérifie gid == 0. Il contrôle la propriété effective sur le disque, de sorte qu'une dérive sur le répertoire (et, par extension, les fichiers de règles qu'il contient) est détectée indépendamment de ce que croit un modèle de déploiement.
only_if { file('/etc/audit').exist? }
describe file('/etc/audit') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/audit. Sortie attendue : root 0. Vérifiez aussi les fichiers : find /etc/audit -printf '%g %p\n' | grep -v '^0 ' ne doit rien afficher.
Inspecter et investiguer
Ajoutez une surveillance auditd, auditctl -w /etc/audit -p wa -k auditconfig, les modifications du répertoire ou de ses fichiers de règles apparaissent dans /var/log/audit/audit.log (grep 'key="auditconfig"' /var/log/audit/audit.log). Les rechargements de règles sont aussi rapportés par journalctl -u auditd.
Remédiation
Aucune remédiation automatique n'est câblée pour cette règle ; elle doit être appliquée manuellement : chgrp -R 0 /etc/audit. Relancez ensuite pavois harden verify.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/audit |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un groupe non-root sur la configuration d'audit pourrait permettre à un attaquant de désactiver discrètement des règles. Remettre le groupe à root est sans danger, auditd s'exécute en root et lit ces fichiers au démarrage. Aucun service n'est cassé. Précaution : conservez le mode 0750 du répertoire et 0640 des fichiers de règles ; rechargez les règles avec augenrules --load (ou systemctl reload auditd) après toute modification légitime pour que la politique active corresponde aux fichiers.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.2.4.7, 6.3.4.7 | direct | per OS, see the benchmark table | haute |
| DISA STIG | UBTU-22-653075, UBTU-24-900060 | 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.