auditd audit.log : la piste d'audit du noyau Linux

Ce que c'est

Le noyau Linux dispose d'un sous-système d'audit qui émet des enregistrements pour les événements liés à la sécurité : appels système correspondant aux règles chargées, surveillance de fichiers, changements de configuration, et messages envoyés depuis l'espace utilisateur par PAM, sudo, sshd, useradd et programmes similaires. auditd reçoit ces enregistrements via netlink et les écrit dans /var/log/audit/audit.log. Voir l'entrée du glossaire auditd.

Le contenu du journal dépend entièrement des règles. Sans règle personnalisée, vous obtenez tout de même les événements de l'espace utilisateur (connexions, authentification, début/fin de session, modifications de comptes, démarrage/arrêt de services) ainsi que quelques événements noyau. Avec des règles execve ou de surveillance de fichiers, audit.log devient le relevé d'exécution le plus détaillé d'un hôte Linux.

Où il se trouve

Sur les hôtes sans auditd, certains messages d'audit du noyau atteignent tout de même le journal du noyau et le journal systemd (_TRANSPORT=audit) : consultez aussi le journal.

Ce qu'il prouve

• Le cycle de vie de l'authentification et des sessions via PAM : USER_AUTH, USER_ACCT, CRED_ACQ, USER_LOGIN, USER_START, USER_END, avec acct=, addr=, terminal= et res=success|failed.
• L'exécution de programmes (si une règle execve existe) : les enregistrements SYSCALL + EXECVE + CWD + PATH + PROCTITLE reconstituent la ligne de commande complète et le répertoire.
• L'attribution à travers les changements de privilèges : auid est l'UID de connexion défini au login et hérité à travers sudo et su, si bien qu'un shell root lancé par deploy porte toujours l'auid de deploy.
• La gestion des comptes (ADD_USER, DEL_USER, ADD_GROUP, USER_MGMT, USER_CHAUTHTOK) et les commandes sudo (USER_CMD).
• La falsification de l'audit lui-même (CONFIG_CHANGE, DAEMON_START, DAEMON_END) et les modifications de règles de pare-feu (NETFILTER_CFG).
• Il ne prouve rien de ce que les règles ne couvraient pas, et les commandes internes du shell ne produisent jamais d'enregistrement execve.

Champs clés

Un événement execve typique (les enregistrements partagent le même tampon msg=audit(...)) :

type=SYSCALL msg=audit(1789874047.512:8812): arch=c000003e syscall=59 success=yes exit=0 ppid=4190 pid=4302 auid=1001 uid=0 gid=0 euid=0 tty=pts0 ses=12 comm="curl" exe="/usr/bin/curl" key="exec"
type=EXECVE msg=audit(1789874047.512:8812): argc=3 a0="curl" a1="-o" a2="/tmp/.x"
type=CWD msg=audit(1789874047.512:8812): cwd="/root"
type=PROCTITLE msg=audit(1789874047.512:8812): proctitle=6375726C002D6F002F746D702F2E78

Avec la valeur par défaut en amont log_format = ENRICHED, auditd ajoute des champs traduits après un octet 0x1D (séparateur de groupe), en majuscules : AUID="deploy" UID="root" SYSCALL=execve. Ces noms ont été résolus sur l'hôte d'origine, ce qui les rend plus fiables que ausearch -i sur un poste d'analyse. Audit 2.x utilisait RAW par défaut et les distributions peuvent modifier cette valeur : vérifiez la configuration sur l'image.

Horodatages

msg=audit(1789874047.512:8812) contient des secondes epoch Unix avec une fraction en millisecondes, puis le numéro de série de l'événement. Il est par nature en UTC : aucune conversion de fuseau n'est nécessaire.

date -u -d @1789874047.512
ausearch -if audit.log -ts 09/20/2026 03:00:00 -te 09/20/2026 04:00:00 -i   # date format follows the analysis host's locale

Le numéro de série est généré par le noyau et repart de zéro après un redémarrage : regroupez les enregistrements par le tampon complet sec.msec:serial, pas par le seul numéro de série.

Rétention

auditd gère lui-même la rotation de son journal, pas logrotate. Le auditd.conf fourni en amont utilise max_log_file = 8 (Mio), num_logs = 5 et max_log_file_action = ROTATE, soit environ 40 Mio d'historique. Avec l'audit execve sur un serveur chargé, cela peut ne représenter que quelques heures. num_logs = 0 ou une action keep_logs modifient ce comportement ; space_left_action et disk_full_action décident de ce qui se passe quand le disque se remplit (la configuration fournie utilise SYSLOG pour space_left_action et SUSPEND, qui cesse d'écrire sur le disque, pour admin_space_left_action et disk_full_action).

Collecte

# Dead box
cp -a /mnt/evidence/var/log/audit /mnt/evidence/etc/audit /cases/2026-017/

# Live, as root: also capture the loaded rules and status
auditctl -l > auditctl_rules.txt
auditctl -s > auditctl_status.txt
tar -C / -cpf /media/ir/audit.tar var/log/audit etc/audit

UAC collecte /var/log et exécute auditctl -l et auditctl -s en réponse live. Les règles chargées peuvent différer des fichiers sur disque si quelqu'un a lancé auditctl -D ou ajouté des règles à la main.

Analyse

ausearch et aureport du paquet audit sont les outils de référence et fonctionnent sur des journaux copiés avec -if.

A=/cases/2026-017/audit
ausearch -if "$A" -m USER_LOGIN,USER_AUTH -i                  # logins and auth, interpreted
ausearch -if "$A" -m EXECVE -ul 1001 -i                        # everything run by login UID 1001
ausearch -if "$A" -k exec --format csv > exec.csv              # by rule key, for spreadsheets
ausearch -if "$A" -m CONFIG_CHANGE,DAEMON_END,DAEMON_START -i  # audit tampering
aureport -if "$A" --login --summary -i
aureport -if "$A" -x --summary                                 # executables

Le plugin de parser text/selinux de Plaso intègre audit.log dans une super timeline. Zircolite (--auditd) applique au journal les règles Sigma pour auditd Linux. Linux Log Parser lit dans le navigateur auth.log / secure, syslog, les fichiers du journal, audit.log et wtmp / btmp / lastlog, et les fusionne en une seule chronologie avec les sessions de connexion reconstituées ; rien n'est envoyé.

Conseils d'investigation

• Avant de chercher, lisez /etc/audit/rules.d/ sur l'image : l'absence de règles execve ou -w explique mieux un manque de preuves d'exécution qu'une falsification.
• -i traduit les UID avec le /etc/passwd de la machine d'analyse, sauf si le journal est enrichi. Vérifiez toujours les noms par rapport aux fichiers de comptes de l'image.
• auid survit à sudo -i et su - : filtrer sur auid permet donc de retrouver ce qu'un utilisateur a fait dans un shell root ; comparez avec les journaux sudo et l'historique du shell.
• Recherchez auditctl -e 0, auditctl -D, systemctl stop auditd et les modifications sous /etc/audit/ dans les enregistrements CONFIG_CHANGE et SYSCALL. Le mode immuable (-e 2) empêche toute modification des règles jusqu'au redémarrage : un redémarrage inattendu juste avant un incident peut donc être délibéré.
• Les valeurs ses relient tous les enregistrements d'une même connexion ; associez-les aux sessions wtmp et aux lignes Accepted d'auth.log.
• Moins de générations tournées que ne le permet num_logs, sur un hôte assez actif pour les avoir remplies, suggère une suppression. Comparez la taille des fichiers avec max_log_file.