Systemd journald forensics

forensics

Définition

La forensique des journaux systemd/journald analyse les logs produits par le système de journalisation de systemd, le système d'init dominant des distributions Linux modernes (Debian/Ubuntu 8+, RHEL/CentOS 7+, Arch, Fedora). Contrairement aux logs texte traditionnels (syslog), journald stocke ses journaux dans un format binaire structuré indexé, offrant des capacités de requête avancées mais nécessitant l'outil journalctl pour l'accès. Les journaux journald sont stockés dans /var/log/journal/ (journaux persistants) ou /run/log/journal/ (journaux volatils, perdus au redémarrage). Le format binaire .journal est un format propriétaire systemd avec des en-têtes de fichier, des objets d'entrée chainés et hashés, et un sceau cryptographique optionnel (FSS — Forward Secure Sealing) permettant de détecter les modifications des logs après coup. Forensiquement, journald offre plusieurs avantages sur les logs traditionnels. Chaque entrée de log inclut des métadonnées automatiquement ajoutées par le noyau : _SYSTEMD_UNIT (service qui a généré le log), _PID et _COMM (processus), _HOSTNAME (nom de l'hôte), _BOOT_ID (identifiant de session de démarrage, changeant à chaque boot, permettant de corréler les logs à des sessions de boot spécifiques), _MACHINE_ID (identifiant persistant de la machine), et PRIORITY (niveau de sévérité). Ces métadonnées sont injectées par journald et ne peuvent pas être falsifiées par le processus qui log. L'analyse forensique de journald pour détecter les incidents de sécurité utilise principalement journalctl avec des filtres : journalctl -u sshd (logs du service SSH), journalctl _PID=1234 (logs d'un PID spécifique), journalctl --since='2025-01-01' --until='2025-01-02' (période temporelle), journalctl -k (messages du noyau), et journalctl -b -1 (session de boot précédente — très utile pour comparer avant/après incident). La vérification d'intégrité des journaux journald (journalctl --verify) détecte les corruptions ou modifications des fichiers journal — une fonctionnalité inexistante avec les logs texte traditionnels.

Fonctionnement

journald reçoit les messages via le socket /run/systemd/journal/socket, le socket syslog (compatibilité), et les messages du noyau. Il les écrit dans des fichiers .journal en ajoutant les métadonnées noyau (UID, PID, cgroup, unité systemd). Le format inclut des hashes chainés permettant la détection de modification (FSS si configuré). Chaque session de boot a un BOOT_ID unique.

Application DFIR

Commandes forensiques journald : journalctl -b → boot actuel, journalctl -b -1 → boot précédent (avant incident ?), journalctl --since='2025-06-01 00:00' --until='2025-06-01 06:00' -o json → export JSON d'une fenêtre temporelle, journalctl -u auditd -u sshd -u cron -p warning → services critiques niveau warning+. Export vers syslog/text : journalctl -o short-iso > /tmp/journal_export.txt. Recherche de patterns : journalctl | grep -E '(failed|error|refused|denied)' -i.

Outils

journalctl (outil natif systemd, toutes options forensiques), journalcheck (vérification intégrité), log2timeline (import journald via plaso), Elastic Filebeat (module journald pour ingestion SIEM). Export JSON : journalctl -o json | python3 -c 'import sys,json; [print(json.loads(l)) for l in sys.stdin]'. Analyse de BOOT_ID : journalctl --list-boots (liste toutes les sessions de boot avec dates).

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis