Journal systemd : le journal binaire de Linux

Ce que c'est

systemd-journald collecte les journaux du noyau, du démarrage précoce, des appels syslog, de l'API native du journal ainsi que le stdout/stderr de chaque service systemd, puis les stocke dans des fichiers binaires indexés. Chaque entrée est un ensemble de paires CHAMP=valeur. Les champs dont le nom commence par un tiret bas sont ajoutés par journald lui-même à partir de la vue qu'a le noyau de l'émetteur (PID, UID, exécutable, unité, identifiant de démarrage) : un processus ne peut donc pas les falsifier en écrivant un faux message.

Sur de nombreuses installations récentes, le journal est le journal système principal, voire le seul. Debian 12 n'installe plus rsyslog par défaut, et Fedora l'a retiré des installations par défaut dès Fedora 20. Si /var/log/auth.log ou /var/log/secure est absent, consultez le journal avant de conclure à un effacement des journaux.

Où il se trouve

L'emplacement des données dépend de Storage=. volatile les garde dans /run, persistent écrit dans /var/log/journal, none les supprime, et auto n'écrit dans /var que si /var/log/journal existe déjà. auto a été la valeur par défaut en amont pendant des années ; systemd 259 a changé la valeur compilée par défaut en persistent (les distributions peuvent la modifier à la compilation). Lisez la configuration réelle sur l'image plutôt que de présumer l'une ou l'autre.

L'organisation est la même sur Debian/Ubuntu, RHEL/Fedora, SUSE et Arch. Les différences entre distributions portent sur l'activation du stockage persistant et sur la présence de rsyslog en parallèle.

Ce qu'il prouve

• Quelle unité ou quel processus a émis un message, avec des champs _PID, _UID, _COMM, _EXE, _CMDLINE et _SYSTEMD_UNIT fiables.
• Les démarrages, arrêts et échecs de services (par exemple une unité malveillante lancée au démarrage, ou l'arrêt de rsyslog/auditd).
• Les messages de sshd, sudo, su, PAM et cron, même en l'absence de journal texte.
• Les messages du noyau (_TRANSPORT=kernel) : branchement USB, chargement de modules, lignes LOG du pare-feu, OOM kills, segfaults.
• Les limites de démarrage via _BOOT_ID, qui révèlent les redémarrages inattendus et les sauts d'horloge.
• Il ne prouve pas qu'un message dit vrai : MESSAGE, SYSLOG_IDENTIFIER et PRIORITY sont fournis par le client, et tout utilisateur local peut écrire des entrées avec logger ou systemd-cat. Appuyez-vous sur les champs préfixés d'un tiret bas pour l'attribution.
• Il n'enregistre pas les commandes saisies dans un shell, sauf si quelque chose les journalise.

Champs clés

Le fichier sur disque commence par la signature LPKSHHRH. Les champs d'en-tête comprennent machine_id, tail_entry_boot_id, head_entry_realtime et tail_entry_realtime, et les objets de données peuvent être compressés en XZ, LZ4 ou ZSTD.

Horodatages

Tous les horodatages du journal sont stockés en microsecondes. __REALTIME_TIMESTAMP compte depuis l'epoch Unix en UTC ; __MONOTONIC_TIMESTAMP compte depuis le démarrage et n'a de sens qu'associé à _BOOT_ID. journalctl affiche les heures dans le fuseau local de la machine d'analyse, sauf si vous passez --utc.

# 1789874047512345 usec -> UTC
date -u -d @$((1789874047512345 / 1000000))
journalctl -D "$J" --utc -o short-iso-precise --since "2026-09-20 03:00" --until "2026-09-20 04:00"

Les valeurs realtime suivent l'horloge système : une horloge manipulée produit des heures trompeuses. Comparez avec l'ordre monotonic au sein d'un même démarrage et recherchez les messages d'ajustement de systemd-timesyncd ou de NTP.

Rétention

Par défaut, la rétention dépend de la taille. SystemMaxUse= vaut par défaut 10 % du système de fichiers, plafonné à 4G ; SystemKeepFree= vaut 15 %, également plafonné à 4G ; chaque fichier subit une rotation à un huitième de SystemMaxUse= (128M au maximum) ou après MaxFileSec= (un mois). MaxRetentionSec= est désactivé par défaut. Sur un serveur chargé, le journal peut ne couvrir que quelques jours, alors qu'une VM peu active peut en conserver des années. Les moyens de suppression incluent journalctl --vacuum-time/--vacuum-size/--vacuum-files, --rotate suivi d'un vacuum, Storage=volatile ou none, ou tout simplement la suppression des fichiers en root.

Collecte

Copiez tout le répertoire, fichiers .journal~ compris, en préservant propriétaires et horodatages. Sur un hôte live, récupérez aussi /run/log/journal avant l'arrêt, car il ne survit pas à un redémarrage.

# Live, as root
journalctl --flush                       # push /run data to /var if persistent
tar -C / -cpf /media/ir/journal.tar var/log/journal run/log/journal etc/systemd/journald.conf etc/systemd/journald.conf.d
journalctl -o export > /media/ir/journal.export   # lossless serialisation

# Dead box (read-only mount)
cp -a /mnt/evidence/var/log/journal /cases/2026-017/

UAC collecte les fichiers *.journal et *.journal~ sous /var/log (le journal volatil /run/log/journal n'est couvert que par son artefact distinct run_log, inclus dans ir_triage et full) et exécute journalctl --list-boots ; l'artefact Velociraptor Linux.Forensics.Journal analyse directement les fichiers sur le poste.

Analyse

journalctl sur une machine d'analyse est le lecteur de référence. Utilisez une version récente : les fichiers écrits avec des fonctionnalités incompatibles plus récentes (comme le mode compact) sont refusés par les lecteurs plus anciens.

J=/mnt/evidence/var/log/journal
journalctl -D "$J" --list-boots --utc
journalctl -D "$J" --header | less                # file ranges, boot IDs, state
journalctl -D "$J" -b all _TRANSPORT=kernel --utc # kernel messages from every boot
journalctl -D "$J" SYSLOG_IDENTIFIER=sshd SYSLOG_IDENTIFIER=sshd-session -o json > sshd.json
journalctl -D "$J" -F _SYSTEMD_UNIT               # every unit that ever logged
journalctl --file "$J/<machine-id>/system@*.journal~" --utc
journalctl -D "$J" --verify

Le parser systemd_journal de Plaso intègre les entrées dans une super timeline, et parse_journald() de Velociraptor les expose en VQL. 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

• Passez -D ou --file à chaque fois. Sans cela, journalctl lit silencieusement le journal de la machine d'analyse elle-même.
• -k implique le démarrage en cours ; sur des preuves hors ligne, utilisez plutôt _TRANSPORT=kernel -b all.
• De nombreux fichiers .journal~, des échecs de --verify concentrés autour de l'incident ou une liste de démarrages qui s'arrête net sans séquence d'arrêt sont des pistes de falsification ou de coupure d'alimentation brutale. Sans Forward Secure Sealing, --verify ne détecte que la corruption, pas une réécriture propre.
• Corrélez _AUDIT_LOGINUID et _AUDIT_SESSION avec les valeurs auid/ses d'auditd et avec les sessions de wtmp.
• Une unité qui ne journalise que via stdout reçoit quand même _SYSTEMD_UNIT et _EXE : le journal est donc le meilleur endroit pour voir ce qu'une unité systemd suspecte a réellement affiché.
• Si rsyslog tourne aussi, comparez les deux : une ligne présente dans le journal mais absente d'auth.log/secure indique une modification du journal texte.