Altération des journaux Linux : trous, zéros et arrêts

En bref. Root peut modifier n’importe quel journal d’un hôte Linux pris isolément. Ce qu’un intrus parvient rarement à faire, c’est les modifier tous de façon cohérente. L’altération se manifeste par des désaccords entre sources (une ligne dans le journal mais pas dans auth.log, une session dans audit.log mais pas dans wtmp, une heure lastlog sans enregistrement wtmp) et par des dégâts structurels (trous de numéros de séquence, enregistrements mis à zéro, fichiers tronqués, démons arrêtés). Écartez les causes bénignes, puis rapportez ce que dit chaque source.

1. Trous dans les numéros de séquence du journal

Chaque entrée du journal porte un numéro de séquence issu d’un compteur partagé par tous les fichiers journal de la machine. Supprimer un fichier journal entier, ou réécrire un fichier sans certaines entrées, laisse une plage de numéros qu’aucune entrée collectée ne porte.

Explications bénignes à exclure d’abord :

Des fichiers user-<UID>.journal non collectés (leurs entrées utilisent le même compteur).
Des fichiers archivés purgés par la politique de rétention (le trou se situe au début de la plage).
Une collecte effectuée pendant que journald écrivait (le trou se situe tout à la fin).

Un trou au milieu de la fenêtre de l’incident, avec les journaux utilisateur présents, ou qui coïncide avec un rm d’un fichier journal dans audit.log ou dans une ligne sudo, est un constat. L’en-tête du journal aide aussi : head_entry_seqnum et tail_entry_seqnum indiquent quelle plage un fichier devrait contenir. Voir l’analyse forensique du journal.

2. Lignes d’authentification dans le journal, absentes d’auth.log

Sur la plupart des hôtes systemd, rsyslog reçoit ses lignes de journald. Un même message sshd, sudo ou PAM existe donc aux deux endroits. Si le journal contient Accepted password for X from IP et qu’auth.log, qui couvre cette période, ne le contient pas, le fichier texte a été modifié (typiquement avec sed -i ou un outil de nettoyage qui ne connaît que les fichiers texte).

Vérifiez d’abord la couverture : la ligne doit se situer entre la première et la dernière ligne des générations d’auth.log dont vous disposez, et rsyslog doit avoir été en cours d’exécution (son démarrage et son arrêt figurent dans le journal). Le cas inverse, une ligne dans auth.log mais pas dans le journal, signifie généralement que le journal n’a pas conservé cette période.

3. Enregistrements de connexion effacés ou tronqués

Les outils de nettoyage de wtmp écrasent un enregistrement avec des zéros pour que la taille du fichier reste alignée. Signes :

des enregistrements entièrement à zéro (type 0, pas d’utilisateur, date de 1970 dans utmpdump),
une taille de fichier qui n’est pas un multiple de la taille d’enregistrement (384 octets sur x86_64, 400 sur aarch64),
des horodatages qui reculent entre des enregistrements consécutifs,
un wtmp ou btmp de zéro octet avec une date de modification ancienne sur un serveur en service.

Croisez ensuite : une session SSH interactive que montrent auth.log, le journal et audit.log, mais pas wtmp, alors que wtmp couvre cette période ; ou une entrée lastlog (la dernière connexion d’un UID) plus récente que toute session wtmp de cet utilisateur. N’oubliez pas que le SSH non interactif (commandes, scp, sftp) n’a souvent aucun enregistrement wtmp. Détails dans le guide wtmp.

4. Journalisation arrêtée ou reconfigurée

Cherchez :

l’arrêt de rsyslog.service, systemd-journald.service ou auditd.service en dehors d’un redémarrage ou d’une mise à jour de paquets,
journalctl --vacuum-time, --vacuum-size, --rotate lancés de manière interactive,
des enregistrements d’audit CONFIG_CHANGE, auditctl -D (suppression de toutes les règles) ou auditctl -e 0 (désactivation),
des modifications de /etc/rsyslog.conf, /etc/rsyslog.d/, journald.conf (Storage=none, volatile) ou /etc/audit/rules.d/,
un journal texte qui s’arrête en milieu de journée alors que le journal systemd continue : le problème vient du démon syslog.

Les redémarrages et les mises à jour arrêtent aussi des services ; lisez ce qui entoure chaque événement.

5. Commandes qui effacent journaux et historique

audit.log (avec une règle execve), les lignes sudo et le journal peuvent capturer l’effacement lui-même :

rm, shred, truncate ou > file visant /var/log/*, les fichiers journal ou /var/log/wtmp,
des scripts lancés avec un chemin de journal en argument, comme un script Python auquel on passe /var/log/wtmp et un nom d’utilisateur,
ln -sf /dev/null ~/.bash_history, unset HISTFILE, export HISTSIZE=0, history -c (les commandes internes du shell et les changements de variables ne laissent aucun enregistrement execve ; le ln, si),
journalctl --vacuum-*, utmpdump -r pour réécrire wtmp à partir d’un texte modifié.

logrotate supprime les anciens fichiers en root depuis cron, selon un calendrier ; une commande interactive lancée depuis une session utilisateur, c’est autre chose.

6. Manipulation de l’heure

Une horloge reculée fait paraître les événements plus anciens. Dans le journal, un realtime qui diminue alors que les numéros de séquence augmentent la trahit ; les messages de systemd-timesyncd ou de NTP et les entrées de changement d’horloge aident. Dans wtmp, des enregistrements qui remontent le temps en sont l’équivalent.

Rédiger le constat

Pour chaque indicateur, indiquez ce que montrent les éléments de preuve et ce qui pourrait l’expliquer d’autre. « Les numéros de séquence du journal manquent entre 10:02 et 10:50 ; aucun user-1001.journal n’a été trouvé ; une ligne sudo à 10:44:10 montre un rm -f exécuté sur ce fichier » est un constat. « Les journaux ont été supprimés » est une conclusion que le lecteur doit pouvoir en tirer.

Dans le navigateur

Linux Log Parser vérifie ces points automatiquement : trous de séquence du journal (avec un avertissement lorsqu’aucun journal utilisateur n’a été chargé), lignes d’authentification présentes dans le journal mais absentes d’auth.log, enregistrements wtmp effacés, partiels ou à rebours, arrêts des démons de journalisation, purges du journal et modifications des règles d’audit, commandes d’effacement de journaux, et connexions interactives sans enregistrement wtmp. Chaque constat liste les événements sur lesquels il repose. L’investigation pas à pas en montre trois sur une même intrusion, et la fiche auth.log liste d’autres indices d’altération par source.