auditd et ausearch : audit kernel Linux pour la conformité

Les auditeurs PCI-DSS, ISO 27001, HDS posent toujours la même question : "Qu'est-ce qui s'est passé sur ce serveur entre le 12 et le 14 mai ?". Sans auditd configuré, la réponse est "rien dans nos logs". journald capture les services, bash_history les commandes interactives, mais les modifications de fichiers, les escalades de privilèges, les syscalls sensibles passent sous le radar.

auditd est le sous-système d'audit kernel Linux. Il intercepte les syscalls et les accès fichiers selon des règles, log dans /var/log/audit/audit.log au format strict. ausearch requête, aureport agrège. Les outils sont en place sur tous les Linux depuis 15 ans. Reste qu'ils sont rarement configurés sérieusement.

Ce qui suit est la configuration à déployer pour passer un audit de conformité ou faire de la forensique post-incident.

• Pourquoi auditd et pas seulement journald
• Architecture auditd : kernel + daemon
• Règles audit : syscalls, fichiers, exécutions
• ausearch et aureport en pratique
• Intégration SIEM et logs centralisés
• Patterns CIS et baselines de conformité
• Performance et stockage
• Pièges et limites

Distinction qui compte.

journald capture ce que les services émettent : logs applicatifs, sorties systemd, kernel ring buffer. Pas conçu pour la traçabilité forensique.

auditd capture les événements système au niveau kernel : syscalls (open, execve, setuid, etc.), accès fichiers, modifications de comptes, modules kernel chargés. Format strict, intercepté avant le userland.

Cas concrets :

• Un attaquant lit /etc/shadow. Pas dans journald. Dans auditd avec une règle de surveillance fichier.
• Un script root est exécuté par un compte non-root via setuid. journald ne le voit pas. auditd capture le syscall execve et le auid (audit user ID, immuable).
• Un module kernel est chargé. journald peut logger via systemd-modules-load, mais ne capture pas un init_module direct. auditd capture le syscall.

Pour la conformité (PCI Req. 10, ISO 27001 A.12.4, HDS), auditd est requis explicitement.

Trois couches.

Kernel audit subsystem : intégré dans le kernel Linux. Maintient une queue d'événements générés selon les règles configurées via auditctl.

auditd daemon : userland. Lit la queue kernel, écrit dans /var/log/audit/audit.log ou dispatch vers d'autres backends (syslog, custom plugin).

Outils CLI : auditctl (configuration runtime), ausearch (requêter), aureport (rapport agrégé), autrace (tracer un process spécifique).

La règle d'or : ne jamais désactiver auditd sur un serveur de prod conforme. Si auditd tombe, le kernel peut être configuré pour mettre le système en panic (mode --enabled 2). Comportement délibéré : empêcher la perte d'audit.

Les règles vivent dans /etc/audit/rules.d/*.rules. Compilées au boot par augenrules puis chargées via auditctl.

Trois types de règles :

File watching : surveille un chemin filesystem. Génère un événement à chaque accès (lecture, écriture, attribut).

-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /var/log/audit/ -p wa -k audit_log_tamper

-p wa : audit en write et attribute change. -k : tag pour requête ultérieure.

Syscall watching : intercepte des syscalls.

-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation
-a always,exit -F arch=b64 -S init_module -S delete_module -k module_change

-F auid>=1000 : filtrer les commandes lancées par des utilisateurs réels (pas system).

Process control : surveille les modifications de processus, fork, exec.

Patterns courants à activer :

• Modifications de fichiers sensibles (/etc/passwd, /etc/shadow, /etc/sudoers, /etc/ssh/, /boot/).
• Toutes les commandes exécutées par les users humains (-S execve).
• Toutes les escalades de privilèges (-S setuid -S setgid).
• Tous les chargements/déchargements de modules.
• Modifications de la configuration audit elle-même.

Les règles CIS Benchmark fournissent un baseline éprouvé. Voir cis-benchmark-audit pour le contexte conformité.

Recherche par tag (key) :

sudo ausearch -k passwd_changes
# Affiche tous les événements avec ce tag

Recherche par utilisateur :

sudo ausearch -ua alice
# Tous les événements générés par alice (audit UID, immuable)

Recherche par syscall :

sudo ausearch -sc execve --start today

Recherche temporelle :

sudo ausearch --start 06/12/2026 10:00:00 --end 06/12/2026 11:00:00

Format des événements : verbose mais structuré. Chaque événement a un timestamp, un audit ID séquentiel, un type (USER_LOGIN, SYSCALL, PATH, etc.), et des champs.

aureport agrège :

sudo aureport --auth         # Authentifications réussies/échouées
sudo aureport --syscall       # Top syscalls
sudo aureport --executable    # Top exécutables lancés
sudo aureport --file          # Top fichiers accédés
sudo aureport --user          # Top users

Pour de la forensique post-incident, c'est l'outil de première ligne avant les outils plus sophistiqués.

Les logs auditd locaux ne suffisent pas pour la conformité : un attaquant root peut effacer /var/log/audit/audit.log. Forwarder vers un SIEM est obligatoire.

Patterns d'export :

rsyslog : auditd a un plugin audisp-syslog qui forward chaque événement vers syslog. Voir rsyslog-centralisation pour la stack centralisée.

Wazuh : agent Wazuh ingère auditd nativement, normalise et corrèle. Voir wazuh-siem.

Loki via Vector ou Filebeat : push vers une stack moderne. Voir stack-logging-loki ou vector-dev-2026.

Auditbeat (Elastic) : agent dédié qui parse auditd et envoie vers Elastic SIEM.

Recommandation : une politique double, audit local 30 jours + push SIEM en temps réel pour rétention longue durée et résistance à la suppression.

Le CIS Benchmark Linux fournit des règles audit standardisées. Exemples représentatifs :

# CIS 4.1.4 - Audit modification de comptes
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# CIS 4.1.7 - Audit logon/logoff events
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock -p wa -k logins

# CIS 4.1.10 - Audit modifications réseau
-w /etc/hosts -p wa -k network
-w /etc/network -p wa -k network

# CIS 4.1.13 - Audit modifications MAC (SELinux/AppArmor)
-w /etc/selinux -p wa -k mac_policy
-w /etc/apparmor -p wa -k mac_policy
-w /etc/apparmor.d -p wa -k mac_policy

# CIS 4.1.14 - Logs read tracking
-a always,exit -F arch=b64 -S openat -F a2=O_RDONLY -F path=/var/log/audit/audit.log -k log_access

L'effort initial : 100-200 lignes de rules.d. Une fois en place, ne plus toucher sauf changement applicatif majeur.

CPU. auditd consomme peu (quelques % CPU sur un serveur chargé). Les règles syscall sur des syscalls fréquents (execve, openat) peuvent générer beaucoup de volume.

Volume. Sur un serveur sysadmin actif, audit.log peut atteindre plusieurs Go par jour. Configurer rotation agressive :

# /etc/audit/auditd.conf
max_log_file = 100      # MB
num_logs = 10           # rotation
max_log_file_action = ROTATE
space_left = 200        # MB
space_left_action = SYSLOG
admin_space_left = 50
admin_space_left_action = SYSLOG
disk_full_action = SYSLOG

Network forwarding. audisp-remote pousse les événements vers un agrégateur central. Pour des parcs distribués, c'est l'option pour ne pas saturer chaque hôte avec un agent SIEM lourd.

Filtrage à la source. Plutôt qu'auditer tout, auditer ce qui compte. Une règle -S execve génère énormément. La filtrer par auid>=1000 coupe l'essentiel du bruit.

Règles bavardes. -S openat sans filtre fait exploser le volume. Toujours filtrer par chemin ou par UID.

Désynchronisation auditctl vs rules.d. Si on modifie les règles à chaud avec auditctl, elles disparaissent au reboot. Toujours éditer /etc/audit/rules.d/*.rules puis augenrules --load.

Verbose inintelligible. Le format brut auditd est ardu. Préférer parser via Wazuh ou Auditbeat qui normalise. Pour requêter manuellement, ausearch -i (interpret) rend les événements lisibles.

SELinux en mode permissive. SELinux génère beaucoup d'événements AVC dans audit. Sur un système permissive, c'est utile pour audit. Sur un système enforcing en prod, ces logs peuvent saturer si les contextes sont mal configurés. Voir selinux-2026.

Conteneurs et namespaces. auditd voit l'espace de noms d'origine. Sur un host avec beaucoup de containers, les syscalls des containers sont audités avec auid spécifique. Pour de la sécurité runtime container, Falco est plus naturel.

Rotation et perte. Si la rotation est trop agressive et qu'un attaquant déclenche beaucoup d'événements pour saturer, les anciens événements légitimes sont perdus. Forwarder vers SIEM en temps réel pour ne rien perdre.

immutable mode. Pour une conformité maximale, auditctl -e 2 rend la config audit immuable jusqu'au reboot. Aucune modification possible. Aligne avec PCI-DSS.

Pour une organisation soumise à un cadre de conformité (santé, banque, finance), auditd n'est pas optionnel. Le déploiement initial mobilise quelques jours par hôte (rules CIS adaptées + intégration SIEM), le coût opérationnel courant reste faible une fois la stack en place. Une politique auditd ne vaut que si quelqu'un relit les événements et fait tourner la rétention ; quand l'interne manque de temps, déléguer cette exploitation garde les traces utilisables.

• auditd documentation officielle : code source userspace, doc.
• Linux Audit Subsystem - kernel.org : référence kernel.
• CIS Linux Benchmarks : baselines audit pour conformité.
• Red Hat - System Auditing : guide RHEL très complet.
• PCI-DSS v4.0 Requirement 10 : exigences logging et monitoring.
• Linux audit - LWN articles : articles techniques sur l'évolution du sous-système.