Journalisation d'audit avec auditd

Qui a fait quoi, et quand ?

Sans piste d'audit inviolable, impossible de répondre à la première question après une intrusion : qui a fait quoi, et quand. Le sous-système d'audit de Linux (auditd) est le témoin adossé au noyau qui enregistre les événements de sécurité tels que le noyau les voit, indépendamment de la journalisation propre à chaque application. Un attaquant qui prend pied va élever ses privilèges, créer ou modifier des comptes, changer des permissions, charger un module noyau (rootkit, renifleur de paquets), dérégler l'horloge pour brouiller les horodatages, puis effacer les journaux applicatifs. Si ces actions ne laissent aucune trace au niveau du noyau, l'incident est invisible. auditd est l'enregistrement qui survit à un processus hostile.

Pourquoi le durcir

Les journaux applicatifs mentent par omission : un processus peut simplement ne rien journaliser, ou être tué avant de le faire. auditd enregistre les appels système et les accès aux fichiers à l'intérieur du noyau, et capture donc l'action privilégiée même quand le programme fautif est hostile. Un jeu de règles correct apporte trois choses :

• Traçabilité : chaque enregistrement porte l'UID de connexion (auid), qui survit à su/sudo, de sorte qu'une action est rattachée à l'humain réel derrière elle, et non à la seule identité root effective.
• Investigation : une séquence précise et horodatée de qui a changé quoi, l'épine dorsale de toute analyse d'incident.
• Résistance à l'altération : un jeu de règles immuable (-e 2) ne peut pas être déchargé silencieusement par un attaquant sans redémarrage, lequel est lui-même un événement bruyant et auditable.

Un hôte où auditd est installé mais sans aucune règle chargée est un faux sentiment de sécurité courant : le démon tourne, mais n'enregistre rien d'intéressant.

Les trois couches du framework d'audit Linux

Les événements sont générés dans le noyau : un attaquant qui modifie un fichier ne peut pas empêcher l'émission de l'événement. C'est la source de vérité qu'exige un hôte durci, et le contrôle requis par les CIS Benchmarks et ANSSI BP-028 (recommandation R73, journaliser l'activité système). À noter : le sous-système d'audit n'est pas isolé par namespace, il ne fonctionne donc pas dans un conteneur (LXC, Docker) ; auditd s'exécute sur une VM ou du matériel physique.

Ce que Pavois audite : le jeu de règles effectif, réellement chargé

Pavois lit le jeu de règles réellement chargé via auditctl -l, les règles que le noyau applique à l'instant présent, plutôt que d'analyser /etc/audit/rules.d/*.rules. C'est le principe de la config effective qui distingue Pavois : un fichier de règles jamais chargé (pas de augenrules --load, une erreur de syntaxe, un appel système rejeté) ferait passer à tort un scanner de fichiers (OVAL/oscap) alors que le noyau n'audite rien. auditctl -l reflète la réalité.

Chaque règle vérifie qu'une règle portant la clé attendue (-k) est chargée. Au fil de ses règles auditd, Pavois couvre : les changements d'heure (adjtimex/settimeofday/clock_settime), l'identité et les privilèges (/etc/passwd, /etc/group, /etc/shadow, sudoers, l'usage de setuid/setgid), les changements de permissions et de politique MAC (chmod/chown/*xattr, SELinux/AppArmor), le chargement de modules noyau (init_module/finit_module/delete_module), les commandes privilégiées et actions d'administration, les suppressions de fichiers, le répertoire des journaux d'audit lui-même, et le drapeau immuable (-e 2) qui finalise le jeu de règles.

Comment vérifier et opérer auditd ?

• Vérifier que le sous-système répond avec auditctl -s : enabled 1 confirme que le noyau audite et qu'auditd tourne (pid non nul) ; surveiller lost (événements perdus) et backlog. enabled 0 ou une commande qui échoue (vous êtes sans doute dans un conteneur) signifie que rien n'est enregistré.
• Lister les règles appliquées avec auditctl -l. Les directives de contrôle -D, -b, -f n'y figurent pas, c'est normal ; un total non nul confirme le chargement, et une règle rejetée le fait baisser silencieusement.
• Rendre les règles persistantes dans /etc/audit/rules.d/*.rules, compilées par augenrules --load. Les fichiers se chargent dans l'ordre de tri (10- pour la base, 30- pour les règles, 99- pour le verrou -e 2) et le noyau applique « premier match gagne ». auditctl -R ne charge qu'en mémoire, perdu au prochain démarrage : la production passe toujours par rules.d.
• Doubler chaque règle d'appel système en arch=b32 ET arch=b64 : sur un hôte 64 bits, un binaire 32 bits peut invoquer le même appel via l'ABI 32 bits et échapper à une règle b64 seule (l'avertissement 32/64 bit syscall mismatch).
• Dimensionner le backlog (-b, par exemple 8192) pour que les événements ne soient pas perdus sous charge ; auditctl -s affichant lost > 0 signale que la file du noyau a débordé.
• Choisir l'action disque plein en conscience dans auditd.conf : space_left_action et surtout admin_space_left_action peuvent valoir halt ou single, donc une partition d'audit saturée peut arrêter la machine. Isolez /var/log/audit sur sa propre partition et réglez la rotation (max_log_file, max_log_file_action = ROTATE). log_format = ENRICHED résout les UID et appels système avant écriture, ce qui compte pour un SIEM.
• Verrouiller pour la production avec -e 2 (immuable) : toute modification par auditctl est alors refusée jusqu'au redémarrage. N'activez ce mode qu'une fois le jeu de règles stable.

Pièges

• ausearch -k n'est pas fiable sans -if. Sur Debian comme sur RHEL, ausearch -k <clé> renvoie souvent <no matches> alors que les événements sont dans le journal ; forcez toujours le fichier d'entrée : ausearch -if /var/log/audit/audit.log -k <clé>. Idem pour aureport.
• Utiliser auid, pas uid, pour l'imputabilité : auid reste l'utilisateur de la session de connexion même après su/sudo, ce qui répond exactement à qui est derrière une action.
• -e 2 impose un redémarrage pour changer. pavois harden apply écrit les règles manquantes dans un drop-in géré sous /etc/audit/rules.d/ et les charge, mais l'immuabilité n'est pleinement effective qu'après un redémarrage.

Couverture et limites

Pavois vérifie la présence des règles à clé dans le jeu réellement chargé (l'ensemble de contrôles CIS / ANSSI). Il ne note pas encore le réglage de auditd.conf (admin_space_left_action, rotation, log_format = ENRICHED) ni l'intégrité du forwarding distant via audisp ; ce sont des décisions d'exploitation, documentées dans la section vérification plutôt que mises en échec.

FAQ

auditd fonctionne-t-il dans un conteneur ? Non. Le sous-système d'audit est global à l'hôte et non isolé par namespace ; exécutez-le sur une VM ou du matériel physique.

Pourquoi Pavois lit-il auditctl -l plutôt que les fichiers de règles ? Parce que seul le jeu chargé est ce que le noyau applique. Un fichier de règles présent mais jamais chargé ne protège rien, et Pavois audite l'état effectif.

Que change -e 2 ? Il rend le jeu de règles immuable jusqu'au prochain redémarrage, de sorte qu'un attaquant qui obtient root ne peut pas désactiver l'audit silencieusement sans redémarrer, un événement lui-même visible et auditable.