Les journaux d'audit système doivent avoir le mode 0640 ou moins permissif
Garantit que le répertoire /var/log/audit n'est pas modifiable par le groupe et n'est ni lisible, ni modifiable, ni exécutable par les autres (mode 0640 ou plus strict).
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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
L'arborescence /var/log/audit contient la piste d'audit auditd, l'enregistrement faisant autorité des événements liés à la sécurité. Si des utilisateurs non privilégiés peuvent y écrire, les pistes d'audit peuvent être altérées ou détruites, permettant à un attaquant d'effacer les preuves d'intrusion. S'ils peuvent la lire, des données sensibles capturées par les règles d'audit (commandes, chemins, arguments) fuitent. Les journaux d'audit doivent être confinés à root (et au groupe d'audit) avec le mode 0640 ou plus strict afin de protéger l'intégrité et la confidentialité de la piste.
Ce que vérifie Pavois
Pavois lit le mode effectif de l'inode de /var/log/audit et vérifie l'absence d'écriture pour le groupe et l'absence de lecture/écriture/exécution pour les autres. Lire le mode réel (et non un manifeste éditeur) est essentiel ici : auditd, la rotation des journaux et les restaurations manuelles peuvent réinitialiser ces permissions, et un répertoire d'audit altéré est précisément ce qu'un attaquant chercherait à dissimuler.
only_if { file('/var/log/audit').exist? }
describe file('/var/log/audit') do
it { should_not be_writable.by('group') }
it { should_not be_readable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_executable.by('other') }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %G %a' /var/log/audit (attendu propriétaire root, mode 700 ou 750) et stat -c '%a' /var/log/audit/audit.log (attendu 600 ou 640). Aucun bit d'écriture pour le groupe, et rien pour les autres.
Inspecter et investiguer
Les événements audités résident dans /var/log/audit/audit.log ; recherchez-y directement (par ex. grep 'key="..."' /var/log/audit/audit.log) plutôt que de vous fier à ausearch, qui peut signaler à tort l'absence de correspondance. L'état d'auditd est affiché par systemctl status auditd et auditctl -s.
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Restreignez manuellement : chown root:root /var/log/audit && chmod 700 /var/log/audit (ou 750 si un groupe d'audit a besoin de lire), et chmod 600 /var/log/audit/*.log. Le log_group et les permissions peuvent aussi être imposés dans /etc/audit/auditd.conf.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0750 |
|---|---|
| path | /var/log/audit |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Des permissions laxistes sur les journaux d'audit permettent aux attaquants d'altérer ou de lire la piste forensique, ruinant l'imputabilité. Restreindre à root est sans danger ; auditd s'exécute en root et n'est pas affecté. Précaution : si un agent de collecte de journaux ou un SIEM lit /var/log/audit en tant qu'utilisateur non-root, ajoutez-le au groupe d'audit et utilisez le mode 0640 plutôt que 0600, ou accordez l'accès via ACL/log_group, sinon le collecteur cessera silencieusement d'ingérer les événements d'audit.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 10.3.1, 6.2.4.1, 6.3.4.2, 6.3.4.1 | direct | per OS, see the benchmark table | haute |
| NIST | 3.3.1, AC-6(1), AU-9(4), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.3.1, 10.3.2 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-653060, UBTU-24-901380 | 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.