Skip to content
Linux Log Parser

Linux Log Parser

auth.log, syslog, secure, le journal systemd, auditd et wtmp/btmp dans une seule chronologie : connexions SSH et force brute, sudo et su, nouveaux comptes, persistance cron et systemd, sessions reconstituées et signes d’altération des journaux. Analyse dans votre navigateur en WebAssembly ; vos journaux ne sont jamais envoyés.

Déposez des journaux Linux, un dossier /var/log ou une collecte UAC / Velociraptor

auth.log, secure, syslog, messages (avec rotations et .gz), *.journal, journalctl -o export / -o json, audit.log, wtmp, btmp, utmp, lastlog, wtmp.db, lastlog2.db, ainsi que /etc/localtime, /etc/timezone et /etc/passwd pour le contexte. Fichiers, dossiers, .zip, .tar et .tar.gz.

L’exemple est synthétique : une intrusion fictive sur le serveur de rebond fin-jump-01, à explorer sans risque.

Analysé dans votre navigateur. Rien n’est envoyé.

Comment récupérer vos journaux

Guide de collecte complet

L’outil lit les fichiers tels qu’ils sont sur l’hôte : journaux texte (y compris rotations et fichiers compressés), fichiers du journal, audit.log et les enregistrements de connexion binaires. Copiez-les avec les droits root, conservez l’arborescence et déposez l’archive ici.

  1. Collecter en root (une commande)
  2. Déposer le .tar.gz ou le dossier ici
  3. Analysé localement, jamais envoyé

Sur l’hôte, en root : une archive avec /var/log (journaux texte, journal, audit, wtmp/btmp/lastlog), le journal volatil et les fichiers de contexte. Les chemins absents sont ignorés avec un avertissement.

bash · root
sudo tar -C / -czf /tmp/linux-logs.tar.gz --ignore-failed-read --sparse \
  var/log run/log/journal etc/localtime etc/timezone etc/passwd etc/hostname

Copiez /tmp/linux-logs.tar.gz sur votre poste et déposez-le ici tel quel : l’archive est ouverte dans le navigateur.

bash
scp user@host:/tmp/linux-logs.tar.gz .

Si vous ne pouvez exécuter que journalctl

Le format export de journalctl est sans perte et conserve tous les champs ; cet outil le lit, ainsi que -o json. Les fichiers bruts du journal restent préférables : ils conservent les numéros de séquence, qui révèlent les entrées supprimées.

bash · root
sudo journalctl -o export > journal.export
sudo journalctl -D /mnt/evidence/var/log/journal -o export > journal.export   # from a mounted image

Tous les journaux d’audit, rotations comprises, dans un seul fichier, au format brut :

bash · root
sudo ausearch --input-logs --raw > audit.log

Avant de collecter

  • Exécutez en root : auth.log, btmp, audit.log et le journal ne sont pas lisibles par les utilisateurs ordinaires.
  • Prenez toutes les rotations (.1, .2.gz, fichiers datés) et les fichiers .journal~ : ils contiennent l’historique plus ancien et les fins endommagées.
  • Copiez /run/log/journal sur un hôte actif : un journal volatil est perdu au redémarrage.
  • lastlog est un fichier creux qui peut sembler énorme ; tar --sparse (comme ci-dessus) ne stocke que les emplacements utilisés.
  • Conservez une empreinte de l’archive et notez l’heure de la collecte : logrotate peut s’exécuter pendant que vous travaillez.

Ce que lit Linux Log Parser

Un hôte Linux enregistre l’authentification, l’usage des privilèges et l’activité des services à plusieurs endroits à la fois : les fichiers texte écrits par rsyslog (auth.log et syslog sur Debian et Ubuntu, secure et messages sur RHEL), le journal systemd binaire, le journal d’audit écrit par auditd, et les enregistrements de connexion binaires wtmp, btmp, utmp et lastlog (ou wtmpdb et lastlog2 sur les systèmes récents).

Cet outil les lit tous dans votre navigateur et les réunit dans une seule chronologie. Chaque ligne est normalisée en un événement avec son hôte, son programme, son identifiant de processus, son utilisateur, son adresse source et sa commande, puis classée : connexions SSH et échecs, sudo et su, modifications de comptes et de mots de passe, modifications cron et systemd, modules noyau, arrêt de la journalisation. Les connexions et déconnexions sont appariées en sessions, avec les commandes exécutées à l’intérieur lorsqu’auditd les a enregistrées.

Où se trouvent les fichiers

  • /var/log/auth.log, /var/log/syslog (Debian, Ubuntu) et /var/log/secure, /var/log/messages (RHEL, Rocky, Alma, Fedora), avec leurs rotations (.1, .2.gz, noms datés).
  • /var/log/journal/<machine-id>/*.journal et *.journal~ (journal persistant), /run/log/journal/ (volatil).
  • /var/log/audit/audit.log et ses rotations (audit.log.1 …).
  • /var/log/wtmp, /var/log/btmp, /var/log/lastlog, /run/utmp ; wtmpdb dans /var/lib/wtmpdb/wtmp.db (Debian 13 : /var/log/wtmp.db) et lastlog2 dans /var/lib/lastlog/lastlog2.db.
  • /etc/localtime ou /etc/timezone (fuseau horaire des lignes syslog traditionnelles) et /etc/passwd (UID vers nom).

Ce qu’il montre

  • Des tentatives de mot de passe suivies d’une connexion réussie, depuis la même adresse ou une autre ; des connexions depuis des adresses jamais utilisées par un compte ; des connexions root directes.
  • L’usage de sudo et su, y compris les shells root interactifs, et les tentatives échouées ou refusées.
  • Les comptes créés, ajoutés à des groupes d’administration ou dotés d’un nouveau mot de passe ; les modifications de crontab, les fichiers d’unités systemd et les unités qui démarrent pour la première fois ; les modules noyau.
  • Les signes d’altération des journaux : lacunes dans les numéros de séquence du journal, lignes d’authentification présentes dans le journal mais absentes d’auth.log, enregistrements wtmp effacés ou tronqués, services de journalisation arrêtés et commandes d’effacement de journaux.
  • Les sessions, de la connexion à la déconnexion, reconstituées à partir des lignes sshd et PAM, de systemd-logind, des identifiants de session d’audit et de wtmp, avec ce qui s’y est passé.

Ce qu’il ne peut pas vous dire

  • Les journaux ne contiennent que ce qui a été journalisé : sans règles d’audit execve, aucune trace des commandes, et les commandes internes du shell ne sont jamais enregistrées.
  • Les messages sont écrits par les programmes, et tout utilisateur local peut injecter des lignes similaires avec logger. Les champs du journal préfixés par un tiret bas (_UID, _EXE, _CMDLINE) sont les seuls fiables.
  • Les lignes syslog traditionnelles n’ont ni année ni fuseau : le résultat dépend de la date du fichier et du fuseau que vous définissez. L’outil indique quand il a fait une déduction.
  • Les constats sont des pistes, pas des verdicts : les administrateurs laissent souvent les mêmes traces. Les journaux de serveurs web ne sont pas analysés.

Comment obtenir les fichiers

  • Le plus simple : en root, archivez avec tar /var/log, /run/log/journal ainsi que /etc/localtime, /etc/timezone, /etc/passwd, /etc/hostname dans un seul .tar.gz et déposez-le ici (voir le guide ci-dessus).
  • Les collectes UAC (tar.gz) et les ZIP Velociraptor peuvent être déposés tels quels.
  • Sur une machine éteinte, montez le système de fichiers en lecture seule et archivez les mêmes chemins.

Questions

Mes journaux sont-ils envoyés ?

Non. Les fichiers sont lus et analysés dans votre navigateur par du WebAssembly exécuté dans un Web Worker. Rien n’est envoyé à un serveur ; fermer l’onglet efface tout.

Peut-il lire les fichiers binaires du journal sans journalctl ?

Oui. Le moteur décode directement le format des fichiers du journal, y compris la disposition compacte de systemd 252 et versions ultérieures et les champs compressés en XZ, LZ4 ou ZSTD. Il lit aussi les sorties de journalctl -o export et -o json.

Comment gère-t-il les lignes d’auth.log sans année ?

Les lignes syslog traditionnelles (Sep 14 10:02:11) n’ont ni année ni fuseau horaire. L’outil déduit les années à rebours depuis la date de modification du fichier (ou l’événement daté le plus récent) et convertit l’heure locale avec le fuseau de /etc/localtime ou /etc/timezone. Les deux peuvent être définis manuellement, et chaque heure déduite est signalée.

Pourquoi certaines lignes d’auth.log apparaissent-elles comme doublons ?

Sur les hôtes systemd, rsyslog reçoit ses lignes de journald : auth.log et le journal contiennent donc les mêmes événements. La copie du journal a des champs fiables et des heures à la microseconde, la ligne texte est donc marquée comme doublon et masquée par défaut. Les lignes présentes dans une seule des deux sources sont conservées et, pour les lignes d’authentification absentes d’auth.log, signalées.

Détecte-t-il les entrées de journal supprimées ?

Il signale ce qui peut être mesuré : lacunes dans les numéros de séquence du journal, entrées d’authentification présentes dans le journal mais pas dans auth.log, enregistrements wtmp effacés ou tronqués, et commandes qui arrêtent la journalisation ou suppriment des journaux. Un résultat vierge ne prouve pas que rien n’a été supprimé.

Quelles distributions sont prises en charge ?

Les arborescences Debian, Ubuntu, RHEL et ses dérivées, Fedora, SUSE et Arch : formats rsyslog traditionnel et RFC 3339, RFC 5424, le journal systemd, les journaux auditd RAW et ENRICHED, wtmp dans les dispositions d’enregistrement x86_64 et aarch64, wtmpdb et lastlog2.

Blog

Lire le blog
EXECVE auditd : auid, ses et arguments hexadécimaux
Reconstituer les commandes depuis audit.log : regroupement par événement, arguments EXECVE réassemblés, décodage hexadécimal, auid et ses à travers sudo.
linux-forensicsauditdexecvecommand-line
Analyse forensique d’auth.log et secure : SSH, sudo, su
Lire /var/log/auth.log et /var/log/secure : force brute et connexions SSH, shells root via sudo et su, mots de passe, comptes et formats d’heure.
linux-forensicsauth-logsshsudo
Collecter les journaux Linux : tar, UAC, Velociraptor
Quoi collecter pour une investigation sur les journaux Linux et comment : tar sur un hôte actif, export journalctl, ausearch, UAC, Velociraptor ou image disque.
linux-forensicsacquisitionuacvelociraptor