← Toutes les règles
SOCLE-RUN-AUD-024// Audit (auditd)moyenneruntime effectif

S'assurer qu'auditd collecte les enregistrements des événements affectant "/var/log/journal"

Installe une surveillance auditd avec la clé systemd_journal sur /var/log/journal afin que chaque accès au stockage du journal systemd soit enregistré.

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.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 1 norme

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

Une fois l'accès obtenu, les attaquants cherchent souvent à établir une persistance et à effacer leurs traces en altérant les journaux. Le journal systemd sous /var/log/journal contient l'enregistrement principal de l'activité système et d'authentification ; le surveiller produit une piste de détection d'altération utilisable en analyse forensique. Sans cette surveillance, un intrus pourrait supprimer ou modifier silencieusement les fichiers de journal, effaçant les preuves de son intrusion.

Ce que vérifie Pavois

Pavois exécute auditctl -l et vérifie l'ensemble de règles actif dans le noyau pour une règle ayant la clé systemd_journal. Un fichier de règles présent sur disque n'a aucune valeur s'il n'a jamais été chargé (augenrules non exécuté, erreur de syntaxe, service non rechargé) ; seul l'ensemble actif issu de auditctl -l prouve que /var/log/journal est réellement surveillé à cet instant.

describe command('auditctl -l') do
  its('stdout') { should match(/(-k +|key=)systemd_journal\b/) }
end
describe command("grep -rhwsE 'systemd_journal' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Exécutez auditctl -l | grep systemd_journal. Attendez-vous à une surveillance telle que -w /var/log/journal -p wa -k systemd_journal. Modifiez un fichier sous ce chemin et confirmez qu'un événement est enregistré.

Inspecter et investiguer

Les événements apparaissent dans /var/log/audit/audit.log. Comme ausearch peut signaler à tort "no matches", utilisez grep sur le journal brut : grep 'key="systemd_journal"' /var/log/audit/audit.log. État du service : systemctl status auditd.

Remédiation

pavois harden apply utilise la ressource audit_ruleset pour écrire un fichier de règles géré par Pavois sous /etc/audit/rules.d/ avec -w /var/log/journal -p wa -k systemd_journal, puis recharge auditd pour le charger dans le noyau. Un redémarrage est signalé car un hôte durci verrouille l'ensemble en immuable (-e 2), de sorte que la nouvelle surveillance s'applique proprement après redémarrage.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

reboot_requiredtrue
resourceaudit_ruleset
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Impact faible : une seule surveillance passive. Précautions : les écritures dans le journal sont fréquentes, cette surveillance génère donc du volume : assurez-vous que audit_backlog_limit est suffisant et que /var/log/audit dispose d'espace. Si la politique d'échec d'auditd est halt/single, une partition d'audit pleine peut bloquer l'hôte ; dimensionnez la partition et surveillez-la avant de verrouiller l'ensemble avec -e 2.

Mapping des normes

NormeRéférenceTypeVersionConfiance
DISA STIGUBTU-22-654190, UBTU-24-300029directper OS STIG releasehaute

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.

Sources & références