auditd : journaliser et tracer un serveur Linux

auditd est le démon qui enregistre, au plus près du noyau Linux, qui a touché à quoi sur votre serveur : lecture de /etc/shadow, modification de /etc/sudoers, chargement d'un module kernel, changement de l'heure. Ce guide montre comment l'installer (Debian et RHEL), déployer un jeu de règles de durcissement aligné sur les CIS Benchmarks, puis retrouver les événements avec ausearch et aureport. Public visé : administrateurs qui veulent une piste d'audit exploitable, pour la conformité ou l'investigation.

Ce que vous allez apprendre

• Installer auditd et vérifier que le sous-système d'audit du noyau répond
• Écrire des règles : surveillance de fichiers, appels système, clés de recherche
• Déployer un jeu de règles de durcissement persistant via augenrules
• Lire la piste d'audit avec ausearch et aureport, sans tomber dans les pièges
• Verrouiller la configuration en mode immuable pour la production

Qu'est-ce qu'auditd

Le framework d'audit Linux se compose de trois couches qu'il faut distinguer :

Couche	Rôle
Sous-système audit du noyau	Génère les événements à la source (appels système, accès fichiers)
auditd (démon espace utilisateur)	Reçoit les événements et les écrit dans /var/log/audit/audit.log
auditctl / ausearch / aureport	Charger les règles, rechercher et synthétiser les événements

Glissez pour voir

La force d'auditd est qu'il travaille dans le noyau : contrairement à un simple syslog applicatif, un attaquant qui modifie un fichier ne peut pas empêcher l'événement d'être généré. C'est la source de vérité d'un serveur durci, et la brique exigée par les référentiels CIS et ANSSI BP-28.

auditd exige un vrai noyau : VM, pas conteneur

Le sous-système audit n'est pas isolé par namespace : il est global à la machine. Dans un conteneur (LXC, Docker), auditd ne peut pas recevoir ses propres événements et entre en conflit avec l'hôte. Pour tester ou exécuter auditd, utilisez une machine physique ou une machine virtuelle. Tout ce guide se valide sur une VM jetable.

Prérequis

• Un serveur Debian 12+ ou RHEL/AlmaLinux/Rocky 9+ (ou une VM)
• Un accès root (ou sudo)
• De préférence une VM de test : certaines règles, une fois rendues immuables, exigent un redémarrage pour être modifiées

Installer auditd

1. Installer le paquet

   Debian / Ubuntu

   sudo apt-get update
   sudo apt-get install -y auditd audispd-plugins

   Le paquet s'appelle auditd et le service démarre automatiquement.

   RHEL / AlmaLinux / Rocky

   sudo dnf install -y audit
   sudo systemctl enable --now auditd

   Côté RHEL, le paquet s'appelle audit (pas auditd) et n'est pas toujours présent sur les images minimales : il faut l'installer puis l'activer explicitement.

2. Vérifier que le sous-système d'audit répond

   sudo auditctl -s

   enabled 1
   failure 1
   pid 838
   backlog_limit 8192
   lost 0
   backlog 0

   La ligne enabled 1 confirme que le noyau audite et qu'auditd tourne (pid non nul). Si enabled vaut 0, le service n'est pas actif ; si la commande échoue, vous êtes probablement dans un conteneur (voir l'avertissement plus haut).

Comprendre les règles d'audit

Une règle dit au noyau quoi surveiller et sous quelle étiquette. Deux formes principales suffisent pour le durcissement :

Forme	Syntaxe	Usage
Surveillance de fichier	-w <chemin> -p <perms> -k <clé>	Tracer accès à un fichier ou dossier
Appel système	-a always,exit -F arch=b64 -S <syscall> -k <clé>	Tracer une action noyau (module, heure)

Glissez pour voir

Les permissions (-p) se combinent : r (lecture), w (écriture), x (exécution), a (changement d'attributs). La clé (-k) est l'étiquette qui rend l'événement retrouvable : c'est elle que vous passerez à ausearch -k. Par exemple, surveiller toute écriture sur le fichier des mots de passe :

-w /etc/shadow -p wa -k identity

Déployer un jeu de règles de durcissement

Plutôt que d'empiler des règles à la main, placez-les dans un fichier sous /etc/audit/rules.d/. La commande augenrules compile tous les fichiers .rules de ce dossier en un jeu cohérent, persistant au redémarrage.

1. Créer le fichier de règles

   Créez /etc/audit/rules.d/hardening.rules avec un sous-ensemble aligné sur les recommandations CIS :

   ## Repartir d'une base propre au chargement
   -D
   ## Buffer kernel (eviter les pertes sous charge)
   -b 8192
   ## Mode si saturation : 1 = consigner via printk
   -f 1
   
   ## Modifications de l'heure systeme
   -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
   -w /etc/localtime -p wa -k time-change
   
   ## Identite : comptes, groupes, mots de passe
   -w /etc/group -p wa -k identity
   -w /etc/passwd -p wa -k identity
   -w /etc/gshadow -p wa -k identity
   -w /etc/shadow -p wa -k identity
   
   ## Elevation de privileges
   -w /etc/sudoers -p wa -k scope
   -w /etc/sudoers.d/ -p wa -k scope
   
   ## Chargement / dechargement de modules kernel
   -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
   -w /sbin/insmod -p x -k modules
   -w /sbin/modprobe -p x -k modules
   
   ## Environnement reseau
   -a always,exit -F arch=b64 -S sethostname,setdomainname -k system-locale
   -w /etc/hosts -p wa -k system-locale
   
   ## Acces a la configuration et aux journaux d'audit
   -w /etc/audit/ -p wa -k auditconfig
   -w /var/log/audit/ -p r -k auditlog

2. Charger les règles

   sudo augenrules --load
   sudo auditctl -l | wc -l

   20

   auditctl -l liste les règles réellement actives dans le noyau. Le compte doit correspondre à votre fichier : si une règle est rejetée, elle n'apparaît pas et le total diminue.

rules.d (persistant) contre auditctl -R (volatil)

augenrules --load lit les fichiers de /etc/audit/rules.d/, qui survivent au redémarrage. À l'inverse, auditctl -R <fichier> charge des règles immédiatement mais en mémoire seulement : pratique pour tester, perdu au prochain boot. Pour la production, on passe toujours par rules.d.

Lire la piste d'audit

C'est ici que le travail porte ses fruits. Deux outils : ausearch cherche des événements précis, aureport en fait la synthèse.

Déclenchez d'abord un événement à tracer, par exemple la création d'un compte (qui écrit dans /etc/passwd, surveillé par la clé identity) :

sudo useradd demo-audit

Le piège ausearch : toujours préciser -if

Sur Debian comme sur RHEL (testé avec audit 3.0.9 et 3.1.5), ausearch -k sans préciser le fichier renvoie souvent <no matches> alors que les événements sont bel et bien dans le log. Le contournement fiable est de forcer le fichier d'entrée avec -if :

# Peu fiable : peut renvoyer "no matches" a tort
sudo ausearch -k identity

# Fiable : toujours preciser le fichier
sudo ausearch -if /var/log/audit/audit.log -k identity

Ce comportement est documenté côté projet (ausearch does not reliably find nodes). Prenez le réflexe -if pour ausearch et aureport.

Recherchez maintenant les modifications d'identité, en interprétant les champs (-i traduit les UID, numéros d'appels système, etc.) :

sudo ausearch -if /var/log/audit/audit.log -k identity -i | tail

La ligne type=SYSCALL vous donne l'essentiel : comm et exe (le programme), AUID (l'utilisateur d'origine de la session, même après un sudo), et success. C'est exactement la réponse à « qui a modifié ce fichier, et avec quel compte d'origine ».

Pour une vue d'ensemble plutôt qu'un événement précis, aureport synthétise :

# Resume des cles declenchees
sudo aureport -if /var/log/audit/audit.log -k

# Resume des modifications de comptes
sudo aureport -if /var/log/audit/audit.log -m

Verrouiller la configuration en production

Une fois vos règles validées, vous pouvez interdire toute modification de la configuration d'audit jusqu'au prochain redémarrage. Ajoutez en dernière ligne de votre fichier de règles :

## Rendre les regles immuables jusqu'au reboot
-e 2

Après rechargement, toute tentative de auditctl pour modifier les règles est refusée. C'est une protection forte : un attaquant qui obtient root ne peut plus désactiver l'audit sans redémarrer la machine, action elle-même traçable et visible.

-e 2 impose un redémarrage

En mode -e 2, la seule façon de changer les règles est de modifier le fichier dans rules.d/ puis de redémarrer. Activez ce mode uniquement quand votre jeu de règles est stable, sinon chaque ajustement coûte un reboot.

Sécurité et points de vigilance

• Protéger les journaux : /var/log/audit/ ne doit être lisible que par root. La règle -w /var/log/audit/ -p r -k auditlog trace justement toute lecture, y compris par vos propres commandes ausearch.
• Dimensionner le stockage : un audit verbeux remplit vite le disque. Réglez max_log_file et max_log_file_action = ROTATE dans /etc/audit/auditd.conf, et surveillez l'espace.
• Le compte d'origine compte : appuyez-vous sur AUID (et non uid) pour l'imputabilité, car il reste celui de la session de connexion même après un changement d'utilisateur.
• Aligner sur un référentiel : les clés identity, scope, time-change, modules reprennent la nomenclature CIS, ce qui facilite la cartographie avec un audit Lynis ou OpenSCAP.

Dépannage

Symptôme	Cause probable	Solution
auditctl -s échoue ou enabled 0	Service arrêté, ou exécution en conteneur	systemctl enable --now auditd ; sur conteneur, basculer sur une VM
ausearch -k renvoie <no matches>	Lecture du log sans -if (comportement non fiable)	Forcer ausearch -if /var/log/audit/audit.log -k <clé>
Le compte de règles (auditctl -l) est trop bas	Une règle est rejetée (syntaxe, syscall inconnu)	Recharger avec augenrules --load et lire les erreurs
Impossible de modifier les règles	Mode immuable -e 2 actif	Éditer le fichier rules.d/ puis redémarrer
Le disque se remplit	Audit trop verbeux, pas de rotation	Ajuster max_log_file et max_log_file_action dans auditd.conf

Glissez pour voir

À retenir

• auditd trace dans le noyau : la piste d'audit résiste à un attaquant qui modifie des fichiers
• Sur conteneur, auditd ne fonctionne pas : utilisez une VM ou du physique
• Règles de durcissement dans /etc/audit/rules.d/ + augenrules --load (persistant)
• Surveillez identité, sudoers, modules kernel, heure et accès aux logs d'audit
• Pour lire les événements, toujours ausearch -if /var/log/audit/audit.log (contournement du piège)
• -e 2 verrouille l'audit en production, au prix d'un redémarrage pour tout changement

Prochaines étapes

CIS Benchmarks Le référentiel d'où viennent ces règles d'audit : mapper chaque clé à un contrôle CIS.

ANSSI BP-28 Les recommandations françaises de durcissement, qui exigent une journalisation d'audit.

Auditer avec Lynis Vérifier automatiquement votre configuration, auditd inclus, et prioriser les écarts.

Durcissement SELinux Le contrôle d'accès obligatoire, complément naturel de la traçabilité d'auditd.

×

📖 Voir la documentation →