Analyse forensique Linux : auth.log, journal, auditd, wtmp

En bref. Un hôte Linux enregistre une même intrusion à jusqu’à quatre endroits indépendants : les journaux texte écrits par rsyslog (auth.log, secure, syslog, messages), le journal systemd binaire, le journal d’audit écrit par auditd, et les enregistrements de connexion binaires (wtmp, btmp, utmp, lastlog, ou leurs successeurs SQLite). Chacun répond à une question différente, chacun peut manquer pour une raison bénigne, et un attaquant nettoie rarement les quatre. L’investigation, c’est la comparaison.

Quatre sources, quatre questions

Source	Fichiers	Répond à	Angle mort
Journaux texte	`/var/log/auth.log`, `syslog` (Debian, Ubuntu) ; `/var/log/secure`, `messages` (famille RHEL)	Qui s’est authentifié, d’où, avec quelle méthode ; lignes de commande sudo ; modifications de comptes	Heure locale, parfois sans année ; le nom du programme n’est pas vérifié
Journal systemd	`/var/log/journal/<machine-id>/*.journal`	Les mêmes messages, plus des champs fiables `_PID`, `_UID`, `_EXE`, `_SYSTEMD_UNIT`, des heures UTC à la microseconde, des identifiants de démarrage	Binaire, rétention fondée sur la taille, parfois uniquement volatil
auditd	`/var/log/audit/audit.log`	Connexions et sessions PAM, et chaque programme exécuté lorsqu’une règle execve existe, rattachés à l’utilisateur de connexion (`auid`)	Uniquement ce que couvrent les règles ; pas installé par défaut sur Debian et Ubuntu
Enregistrements de connexion	`/var/log/wtmp`, `btmp`, `lastlog`, `/run/utmp`, `wtmp.db`, `lastlog2.db`	Sessions interactives avec début et fin, échecs de connexion, dernière connexion par compte, redémarrages	SSH non interactif souvent absent ; trivial à modifier en root

Le journal systemd et rsyslog contiennent généralement des copies de la même ligne, écrites et tournées indépendamment. auditd est alimenté par le noyau, pas par syslog. Les fichiers wtmp et btmp sont écrits directement par login, sshd et PAM. Cette indépendance fait d’une chronologie fusionnée bien plus qu’une commodité : c’est elle qui rend visibles les suppressions et les modifications.

Une connexion SSH, vue partout

Prenons une seule connexion par mot de passe de svc_backup depuis 203.0.113.45 :

auth.log : sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2, puis pam_unix(sshd:session): session opened, puis systemd-logind[845]: New session 7 of user svc_backup.
Journal : les trois mêmes messages, chacun avec _PID, _UID, _SYSTEMD_UNIT=ssh.service et un horodatage UTC à la microseconde.
audit.log : USER_AUTH, USER_ACCT, LOGIN (qui définit auid=1001 ses=114), USER_START et USER_LOGIN avec addr=203.0.113.45 res=success.
wtmp : un enregistrement USER_PROCESS sur pts/1 avec l’hôte 203.0.113.45 ; à la déconnexion, un enregistrement DEAD_PROCESS sur la même ligne.
lastlog : l’emplacement de l’UID 1001 écrasé avec l’heure, pts/1 et 203.0.113.45.

Trois identifiants de session apparaissent : le PID de sshd (3071), le numéro de session systemd-logind (7) et la session d’audit (ses=114). Ce sont des numéros différents pour la même connexion. Reconstituer une session, c’est les relier : les lignes PAM session opened et session closed partagent le PID de sshd, la session logind est annoncée dans les millisecondes qui suivent, et chaque enregistrement d’audit intermédiaire porte ses=114, y compris les commandes exécutées plus tard dans un shell root.

Où les sources divergent, et pourquoi

Les divergences sont normales. Avant de conclure à une altération, écartez les explications bénignes :

Aucun auth.log. Les installations Debian 12 et Fedora récentes peuvent ne pas exécuter rsyslog. Le journal est alors le seul journal système.
Le journal commence après auth.log. Le journal est limité en taille (10 % du système de fichiers, plafonné à 4G par défaut) et peut être volatil (/run/log/journal) si le stockage persistant n’est pas activé.
Commande SSH sans enregistrement wtmp. ssh host command, scp et sftp n’allouent pas de terminal et ne laissent souvent aucune entrée wtmp.
Aucun enregistrement execve. Aucune règle d’audit n’était chargée pour execve. Lisez d’abord /etc/audit/rules.d/.
Des heures différentes. Les lignes syslog traditionnelles sont en heure locale sans année ; le journal et le journal d’audit sont en UTC. Un décalage d’une heure est généralement un fuseau horaire, pas un attaquant.

Ce qui reste après ces vérifications est intéressant : des lignes d’authentification présentes dans le journal mais absentes d’auth.log, des trous dans les numéros de séquence du journal, un enregistrement wtmp entièrement à zéro, une heure lastlog sans session wtmp correspondante. Le guide sur l’altération passe chacun de ces cas en revue.

Normaliser l’heure d’abord

Une chronologie fusionnée ne vaut que par sa gestion des horloges :

Le syslog RFC 3164 (Sep 14 10:02:11) n’a ni année ni fuseau. Le fuseau provient de /etc/localtime ou /etc/timezone dans l’image ; l’année se déduit à rebours à partir de la date de modification du fichier, en surveillant un changement d’année à l’intérieur du fichier. Voir syslog RFC 3164.
Les lignes RFC 3339 haute précision (2026-09-14T10:02:11.482113+00:00), par défaut sur Ubuntu 24.04 et Debian 12+, portent leur décalage et les microsecondes.
Les lignes RFC 5424 issues des relais portent elles aussi un horodatage complet.
Les heures du journal sont des microsecondes depuis l’epoch, en UTC. journalctl affiche _SOURCE_REALTIME_TIMESTAMP (le moment où le message a été produit) lorsque l’entrée en possède un.
Les horodatages d’audit.log sont de la forme msg=audit(1789380131.486:181296) : secondes depuis l’epoch, millisecondes, puis un numéro de série.
wtmp/btmp/lastlog contiennent des secondes depuis l’epoch (plus les microsecondes dans les enregistrements utmp).

Convertissez tout en UTC et notez comment chaque heure a été obtenue (décalage explicite, fichier de fuseau ou année déduite).

Dédoublonner, puis corréler

Sur un hôte qui exécute à la fois rsyslog et journald, chaque ligne sshd existe en double. Compter les deux gonfle les chiffres de force brute et encombre la chronologie. Conservez la copie du journal (elle a des champs fiables et les microsecondes) et marquez la ligne texte comme son doublon, mais gardez la ligne texte disponible : si la copie du journal manque, cette différence est en soi une découverte.

Corrélez ensuite par session : paires de PID sshd pour l’ouverture et la fermeture PAM, numéros de session logind, ses d’audit, et enregistrements wtmp de connexion et de déconnexion. Une session qui apparaît dans trois sources mais pas dans wtmp est exactement ce que laisse un outil de nettoyage de journaux.

Le faire dans le navigateur

Linux Log Parser effectue ces étapes sur les fichiers que vous déposez : il lit les journaux texte (RFC 3164 avec déduction de l’année et conversion de fuseau, RFC 3339, RFC 5424, générations tournées et .gz), les fichiers journal binaires y compris en mode compact et avec champs compressés, journalctl -o export et -o json, audit.log au format RAW ou ENRICHED, wtmp/btmp/utmp pour les structures x86_64 et aarch64, lastlog, wtmp.db et lastlog2.db. Il construit une chronologie UTC unique, marque les lignes d’auth.log que le journal contient aussi, reconstitue les sessions et liste des constats tels qu’un essai de mots de passe suivi d’un succès, des shells root, une persistance via cron et systemd, des trous dans le journal et des enregistrements wtmp effacés. Tout s’exécute localement en WebAssembly ; rien n’est envoyé.

Pour aller plus loin

Collecter les journaux depuis un hôte actif, un outil de triage ou une image disque.
Lire auth.log et secure pour SSH, sudo et les modifications de comptes.
Analyse forensique du journal : format de fichier, numéros de séquence et fichiers .journal~.
Analyse forensique des EXECVE auditd : auid, ses et arguments encodés en hexadécimal.
wtmp, btmp et lastlog, y compris wtmpdb et lastlog2.
Une investigation complète pas à pas sur l’exemple synthétique de l’outil.

Pour des tableaux de référence par artefact, les fiches de linuxforensics.app couvrent le journal systemd, auth.log et syslog, auditd, wtmp, btmp et lastlog, les journaux sudo et les artefacts SSH.