Auditd en 2026 : le guide complet du Linux Audit Framework pour la détection et la conformité

Mise à jour : 26 juillet 2026

Auditd est le démon d'audit du noyau Linux qui intercepte les appels système, les accès aux fichiers et les événements de sécurité pour les écrire dans /var/log/audit/audit.log. C'est la source de vérité utilisée par PCI-DSS, HIPAA, STIG et les benchmarks CIS pour prouver ce qui s'est passé sur une machine. Dans ce guide 2026, je détaille comment installer auditd sur RHEL 10, Debian 13 et Ubuntu 24.04, écrire des règles utiles (pas juste bruyantes), lire les logs avec ausearch et aureport, puis les transférer vers Wazuh, Splunk ou Elastic sans saturer le disque.

• Auditd s'appuie sur le sous-système audit du noyau Linux, actif dès qu'un paramètre audit=1 est passé au démarrage (par défaut sur RHEL, désactivé sur Ubuntu Server 24.04 sans configuration).
• Les règles se déclarent dans /etc/audit/rules.d/*.rules et sont chargées par augenrules --load ; ne modifiez jamais /etc/audit/audit.rules à la main.
• La commande ausearch -k <clé> et aureport --summary transforment les logs bruts en événements exploitables. Sans clés (-k) dans vos règles, l'investigation devient impossible à grande échelle.
• Le plugin audisp-remote (paquet audispd-plugins) transfère les événements en TLS mutuel vers un collecteur distant, essentiel pour la non-répudiation exigée par PCI-DSS 10.5.
• Les règles CIS Level 2 ajoutent environ 90 lignes de configuration ; sur un serveur d'applications actif, comptez 200 à 500 Mo de logs par jour.
• Wazuh, Falco et les EDR modernes consomment directement les événements auditd : pas besoin de les remplacer, il faut les augmenter.

Qu'est-ce que le Linux Audit Framework ?

Le Linux Audit Framework est un couple noyau/espace utilisateur qui journalise les événements de sécurité définis par l'administrateur. Côté noyau, un sous-système appelé audit (activé par le paramètre de démarrage audit=1) intercepte les appels système, les accès aux fichiers surveillés et les décisions LSM (dont les refus SELinux et AppArmor). Côté espace utilisateur, le démon auditd reçoit ces événements via un socket netlink, les écrit dans /var/log/audit/audit.log au format ligne clé=valeur, et les distribue à des plugins comme audisp-syslog ou audisp-remote.

Contrairement à rsyslog ou systemd-journald qui journalisent ce que les applications choisissent d'émettre, auditd journalise ce que le noyau observe. Même si un attaquant supprime les logs applicatifs, la trace kernelspace reste. Honnêtement, j'ai vu cette distinction sauver plusieurs investigations post-incident : une équipe pentest qui pensait avoir nettoyé ses traces en effaçant /var/log/secure avait laissé intacts les SYSCALL execve de son webshell dans audit.log.

Depuis 2025, la version 4.x d'audit-userspace apporte trois évolutions importantes : le support natif d'io_uring (précédemment aveugle aux règles syscall classiques), l'intégration avec les événements fanotify pour surveiller les accès en temps réel sans règles watch coûteuses, et un nouveau format JSON optionnel via audisp-json pour simplifier l'ingestion SIEM. Sur RHEL 10 et Fedora 42, ces trois évolutions sont livrées par défaut. Consultez le dépôt audit-userspace sur GitHub pour le changelog complet.

Installer et activer auditd sur RHEL, Debian et Ubuntu en 2026

Auditd est préinstallé et actif sur toutes les distributions dérivées de Red Hat depuis RHEL 6. Sur RHEL 10, Rocky Linux 10, AlmaLinux 10 et Fedora 42, un simple systemctl status auditd confirmera qu'il tourne. Sur Debian 13 et Ubuntu Server 24.04, le paquet auditd n'est pas installé par défaut et le paramètre kernel audit=0 est actif. Deux étapes sont donc nécessaires pour l'activer proprement.

Installation sur RHEL 10 / Rocky 10 / AlmaLinux 10

# Vérifier la présence et l'état
sudo dnf install -y audit audispd-plugins
sudo systemctl enable --now auditd

# Vérifier que le noyau reçoit bien les règles
sudo auditctl -s
# enabled 1
# failure 1
# pid 1234
# rate_limit 0
# backlog_limit 8192

Installation sur Debian 13 / Ubuntu 24.04

# Installer les paquets
sudo apt update
sudo apt install -y auditd audispd-plugins

# Activer le sous-systeme kernel au boot (obligatoire sur Ubuntu)
sudo sed -i 's/GRUB_CMDLINE_LINUX="\(.*\)"/GRUB_CMDLINE_LINUX="\1 audit=1 audit_backlog_limit=8192"/' /etc/default/grub
sudo update-grub
sudo reboot

# Apres redemarrage
sudo auditctl -s | grep enabled
# enabled 1

Le paramètre audit_backlog_limit=8192 est essentiel : il définit combien d'événements peuvent s'accumuler dans le kernel avant que celui-ci ne perde des enregistrements. Sur un serveur d'applications actif, la valeur par défaut de 320 est largement insuffisante. Consultez le guide Red Hat sur la configuration d'auditd pour les recommandations complètes par profil de charge.

Comment écrire des règles auditd efficaces sans saturer les logs ?

La règle d'or : chaque règle doit avoir une clé (-k nom_de_cle) qui décrit son intention métier. Sans clé, vous ne pourrez pas filtrer les événements avec ausearch -k et vos logs deviendront un flux illisible de SYSCALL anonymes. J'ai récupéré des systèmes clients avec 40 Go d'audit.log inutilisables faute de clés. La donnée était bien là, mais impossible à interroger sans écrire du regex sur chaque champ.

Structure d'un fichier de règles

Ne modifiez jamais /etc/audit/audit.rules directement. Placez vos règles dans des fichiers séparés sous /etc/audit/rules.d/. Chaque fichier commence par un chiffre qui définit l'ordre de chargement. Voici un exemple minimum pour un serveur exposé (fichier /etc/audit/rules.d/50-baseline.rules) :

# Surveiller les modifications du fichier passwd et shadow
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity

# Surveiller l'utilisation de sudo et su
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k sudo_usage
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k su_usage

# Detecter les chargements de modules kernel
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_modules

# Surveiller les changements de configuration reseau
-w /etc/hosts -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config
-w /etc/nftables.conf -p wa -k firewall_config

# Verrouiller la configuration apres chargement (a laisser en DERNIER)
-e 2

Rechargez les règles :

sudo augenrules --load
sudo auditctl -l | wc -l
# Verifie le nombre de regles actives

Choisir les bonnes règles sans crouler sous le bruit

Trois erreurs fréquentes que je vois en audit de configuration :

1. Surveiller /var/log/ ou /tmp/ : vous générerez des millions d'événements par heure sur un serveur actif. Ces règles finissent par saturer le disque en 24 heures.
2. Ne pas filtrer par auid : sans le filtre -F auid>=1000 -F auid!=unset, vous capturez toutes les exécutions système, y compris celles des services de fond. Vos logs deviennent 95% de bruit.
3. Utiliser -S all : c'est la commande favorite des tutoriels de blog, et un désastre en production. Utilisez plutôt les syscalls précis dont vous avez besoin.

Pour un point de départ éprouvé, le dépôt Neo23x0/auditd sur GitHub maintient un ensemble de règles mappées MITRE ATT&CK que je recommande à mes clients. C'est le plus proche d'un standard de facto en 2026.

Interpréter /var/log/audit/audit.log avec ausearch

Un événement auditd brut ressemble à ceci :

type=SYSCALL msg=audit(1721990400.123:842): arch=c000003e syscall=59 success=yes
exit=0 a0=55d3f8c0b8a0 a1=55d3f8c0b930 a2=55d3f8c0b950 a3=0 items=2 ppid=2841
pid=2842 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=3 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:
unconfined_t:s0-s0:c0.c1023 key="sudo_usage"

Lisible ? Pas vraiment. C'est pour ça que ausearch et aureport existent. Trois commandes couvrent 90% des besoins d'investigation :

# Toutes les utilisations de sudo dans les dernieres 24 heures
sudo ausearch -k sudo_usage --start yesterday --format text

# Modifications de /etc/passwd depuis le debut de la semaine
sudo ausearch -k identity --start week-ago -i

# Refus SELinux (AVC) des dernieres 10 minutes
sudo ausearch -m AVC --start recent

Le drapeau -i résout les UID en noms d'utilisateurs et les syscalls numériques en noms lisibles (sans lui, vous lisez du hexadécimal). Le drapeau --format text ajouté en 2024 est aujourd'hui mon défaut pour la lecture humaine ; il transforme chaque événement en une phrase intelligible du type « À 14h32, l'utilisateur alice (auid=1001) a exécuté /usr/bin/sudo avec succès. »

Pour croiser auditd avec les refus SELinux, référez-vous à mon guide complet SELinux pour RHEL 10 et Fedora 42. Les événements de type AVC et USER_AVC arrivent tous dans audit.log et se filtrent avec les mêmes outils.

Générer des rapports de conformité avec aureport

aureport agrège les événements en tableaux synthétiques, idéal pour les rapports d'audit hebdomadaires ou les preuves de conformité. Les rapports les plus utilisés dans mes missions bancaires :

# Resume general des dernieres 24 heures
sudo aureport --summary --start yesterday

# Toutes les tentatives d'authentification echouees de la semaine
sudo aureport --auth --failed --start week-ago -i

# Tous les evenements lies a un utilisateur specifique
sudo aureport --user --start this-month -i

# Liste des executables les plus utilises (utile pour reperer des binaires suspects)
sudo aureport --executable --summary -i | sort -k1 -n -r | head -20

# Modifications de comptes utilisateurs pour la revue trimestrielle
sudo aureport --mods --start 90-days-ago -i

Pour générer un rapport CSV exploitable par un outil BI :

# Necessite audispd-plugins et le plugin json active
sudo aureport --start yesterday --format csv > /var/log/audit/report-$(date +%F).csv

Transférer les logs auditd vers un SIEM (audisp-remote, Rsyslog, Wazuh)

Garder les logs sur la machine émettrice viole l'exigence de non-répudiation de PCI-DSS 10.5.3, puisqu'un attaquant qui obtient root peut simplement les supprimer. Trois approches courantes en 2026 pour le transfert :

Option 1 : audisp-remote (TLS mutuel, natif)

Le plugin audisp-remote est fourni par le paquet audispd-plugins. Il transfère chaque événement en temps réel vers un serveur d'agrégation via TCP+TLS avec authentification client par certificat.

# Sur l'emetteur : /etc/audit/audisp-remote.conf
remote_server = audit-collector.internal.example.com
port = 60
transport = krb5     # ou "tcp" pour TLS via stunnel
queue_file = /var/spool/audit/remote.log
mode = immediate
network_retry_time = 1
max_tries_per_record = 3

Option 2 : Rsyslog (le plus flexible)

Activez audisp-syslog pour rediriger les événements vers rsyslog, qui les transmet ensuite en RELP ou TLS à votre puits :

# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_LOCAL6
format = string

# /etc/rsyslog.d/50-audit-remote.conf
local6.* action(type="omfwd"
  target="siem.internal.example.com"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="siem.internal.example.com"
)

Option 3 : Agent SIEM (Wazuh, Falco)

La méthode que je recommande le plus souvent : laisser un agent lire les logs localement et gérer le transport. Wazuh 4.14 consomme nativement les événements auditd et les mappe automatiquement aux techniques MITRE ATT&CK. C'est le chemin le plus court entre un événement kernel et une alerte actionnable dans un SOC.

Auditd et conformité PCI-DSS, HIPAA et CIS Benchmarks

Plusieurs référentiels imposent une configuration auditd précise. Les correspondances les plus fréquemment citées lors des audits que je supporte :

Exigence	Règles auditd correspondantes	Volume approximatif
PCI-DSS 10.2	Accès aux données titulaires, modifications d'identifiants, actions root	~30 règles
HIPAA § 164.312(b)	Accès aux fichiers PHI, journalisation des connexions	~20 règles
CIS RHEL 10 L2	Baseline complète : identity, MAC, kernel modules, réseau	~90 règles
DISA STIG	Superset de CIS L2 avec règles sur les commandes privilégiées	~120 règles
NIS2 (transposition FR)	Traçabilité minimale + transfert vers puits externe	Baseline + audisp-remote

Le plus simple pour appliquer ces baselines : utiliser SCAP Security Guide, qui fournit des profils Ansible et Bash prêts à l'emploi. Sur RHEL 10, un oscap xccdf eval --profile stig génère un rapport HTML avec les règles auditd manquantes et un script de remédiation. J'utilise systématiquement ce workflow avant tout audit certifiant chez mes clients bancaires.

Attention néanmoins : les profils STIG sont conservateurs et génèrent un volume de logs important. Sur un serveur d'applications transactionnel, comptez 500 Mo à 2 Go/jour de logs audit. Planifiez la rotation (max_log_file = 100, num_logs = 20 dans /etc/audit/auditd.conf) et le stockage central en conséquence.

Pièges classiques et bonnes pratiques en production

Après huit ans à durcir des estates RHEL en régulé, voici les erreurs que je vois se répéter sur presque chaque mission :

1. Ignorer space_left_action

Dans /etc/auditd.conf, le paramètre space_left_action définit ce qui se passe quand le disque approche saturation. La valeur par défaut SYSLOG se contente d'écrire un warning, et vos logs continuent d'accumuler jusqu'au blocage. En environnement PCI/STIG, la valeur recommandée est email ou exec avec un script qui rote vers un stockage externe.

2. Confondre uid et auid

Le champ uid peut changer via setuid ; un attaquant qui exécute sudo apparaîtra avec uid=0. Le champ auid (audit UID, aussi appelé loginuid) est immuable : il conserve l'UID de l'utilisateur qui a ouvert la session initiale. Filtrez toujours sur auid pour l'attribution, jamais sur uid.

3. Oublier fapolicyd et les autres LSM

Auditd journalise les événements ; il ne les bloque pas. Pour empêcher activement l'exécution de binaires non approuvés, couplez-le avec fapolicyd sur RHEL ou avec un profil AppArmor restrictif. Le combo classique : auditd pour la traçabilité, systemd hardening pour la containment des services, et un LSM pour l'application des politiques.

4. Ne pas tester la rotation

Vérifiez avec logrotate ET la rotation interne d'auditd (num_logs, max_log_file_action=ROTATE). J'ai vu des systèmes STIG-compliant partir en carafe parce que les deux mécanismes se marchaient sur les pieds et supprimaient les logs simultanément. Utilisez UNE méthode de rotation, pas les deux.

5. Ignorer io_uring en 2026

Les règles syscall classiques (-S openat, -S read) sont invisibles aux opérations io_uring, la nouvelle interface asynchrone du kernel. Depuis kernel 6.6, ajoutez explicitement les événements io_uring dans vos règles si vous surveillez des workloads modernes (bases de données, proxies) :

-a always,exit -F arch=b64 -S io_uring_setup -k io_uring_usage
-a always,exit -F arch=b64 -S io_uring_enter -F success=1 -k io_uring_activity

Foire aux questions

Où sont stockés les logs auditd sous Linux ?

Par défaut dans /var/log/audit/audit.log, avec rotation vers audit.log.1, audit.log.2, etc. selon la configuration num_logs et max_log_file de /etc/audit/auditd.conf. Le répertoire est en mode 0700 et ne doit être lisible que par root.

Quelle est la différence entre auditd et syslog ?

Syslog journalise ce que les applications choisissent d'émettre en espace utilisateur. Auditd journalise ce que le noyau observe : appels système, accès aux fichiers surveillés, décisions LSM. Auditd résiste mieux à la falsification et est le seul accepté par PCI-DSS et STIG comme source de vérité pour les événements de sécurité.

Comment désactiver temporairement une règle auditd sans redémarrer ?

Utilisez sudo auditctl -d avec la spécification exacte de la règle (ou auditctl -D pour tout supprimer). Attention : si vous avez verrouillé la config avec -e 2, seul un redémarrage permet de modifier les règles. En développement, remplacez temporairement par -e 1.

Auditd ralentit-il les performances système ?

L'impact est mesurable mais généralement négligeable, de l'ordre de 1 à 3% de CPU sur un serveur d'applications avec les règles CIS L2. Le vrai coût est le disque (jusqu'à 2 Go/jour sur charges élevées) et le réseau si vous transférez en temps réel. Sur des workloads très sensibles aux syscalls (bases haute fréquence), profilez avant/après avec perf stat.

Peut-on remplacer auditd par eBPF en 2026 ?

Partiellement. Des outils comme Tetragon offrent une visibilité kernel via eBPF avec des performances supérieures et un format structuré. Mais aucun auditeur PCI ou STIG n'accepte encore eBPF seul comme source de journalisation certifiée en 2026 : auditd reste requis pour la conformité. La stratégie gagnante : auditd pour la conformité, eBPF pour la détection temps réel.