auth.log, secure et syslog : journaux texte Linux

Ce que c'est

Un démon syslog (rsyslog sur presque toutes les distributions courantes, parfois syslog-ng) reçoit les messages des programmes et du noyau et les écrit dans des fichiers texte selon des règles de facility et de priorité. Sur les hôtes systemd, rsyslog lit généralement depuis journald : les fichiers texte et le journal contiennent donc des copies redondantes des mêmes événements, stockées et soumises à rotation de façon indépendante.

Le fichier d'authentification est la colonne vertébrale de la plupart des chronologies d'intrusion : connexions et échecs sshd, usage de sudo et su, ouverture/fermeture de sessions PAM, création de comptes et changements de mot de passe y arrivent tous via les facilities auth et authpriv.

Où il se trouve

Par défaut, RHEL envoie authpriv.* vers secure et *.info;mail.none;authpriv.none;cron.none vers messages. Le 50-default.conf d'Ubuntu envoie auth,authpriv.* vers auth.log et tout le reste sauf auth vers syslog.

Tous les hôtes n'ont pas ces fichiers. Debian 12 n'installe plus rsyslog par défaut et Fedora a cessé de le faire à partir de Fedora 20 : une installation récente peut donc ne journaliser que dans le journal systemd. Les systèmes mis à niveau conservent rsyslog. Vérifiez la présence de /etc/rsyslog.conf et du paquet rsyslog avant d'interpréter un fichier absent comme une suppression.

Ce qu'il prouve

• Les authentifications SSH réussies et échouées, avec utilisateur, IP source, port et méthode (Accepted password, Accepted publickey ... SHA256:<fingerprint>, Failed password, Invalid user).
• L'usage de privilèges : lignes de commande sudo:, sessions su:, pam_unix(...:session): session opened for user.
• Les modifications de comptes : messages de useradd, usermod, groupadd, passwd et chpasswd.
• Les événements de services et du noyau dans syslog/messages/kern.log : redémarrages de services, branchement USB, lignes LOG du pare-feu.
• Il ne prouve pas ce qu'un utilisateur a fait après sa connexion, et tout ce qu'un utilisateur local écrit via logger ressemble à une ligne normale. Le nom du programme et le PID de la ligne proviennent de l'émetteur et ne sont pas vérifiés.

Champs clés

Une ligne traditionnelle (style RFC 3164) :

Sep 20 03:14:07 web-prod-03 sshd[4190]: Accepted password for deploy from 203.0.113.50 port 40318 ssh2

La même ligne au format haute précision par défaut de rsyslog (horodatage RFC 3339) :

2026-09-20T03:14:07.512345+02:00 web-prod-03 sshd[4190]: Accepted password for deploy from 203.0.113.50 port 40318 ssh2

Motifs de message utiles : Accepted, Failed password, Invalid user, Connection closed by authenticating user, session opened, session closed, COMMAND=, new user:, new group:, password changed for. Depuis OpenSSH 9.8, le processus par connexion est séparé dans sshd-session : cherchez les deux noms.

Horodatages

Deux formats sont courants, et vous devez identifier celui utilisé par l'hôte :

• Traditionnel (RSYSLOG_TraditionalFileFormat) : Mmm dd HH:MM:SS, heure locale, sans année ni fuseau horaire. Le rsyslog.conf de la famille RHEL définit explicitement ce modèle.
• Haute précision (format par défaut intégré à rsyslog, RSYSLOG_FileFormat) : RFC 3339 avec microsecondes et décalage UTC. Debian l'a activé à partir de bookworm (12) en cessant d'imposer le modèle traditionnel, et Ubuntu 24.04 journalise également ainsi.

Pour le format traditionnel, retrouvez le fuseau via /etc/localtime (ou /etc/timezone sous Debian) dans l'image, et déduisez l'année des métadonnées de fichiers et de l'ordre de rotation. Attention aux changements d'année au sein d'un même fichier et aux passages heure d'été/heure d'hiver qui dupliquent ou sautent une heure.

ls -l /mnt/evidence/etc/localtime        # symlink target names the zone
TZ=Europe/Paris date -u -d '2026-09-20 03:14:07'   # local -> UTC

Rétention

logrotate gère la durée de vie. Le /etc/logrotate.d/rsyslog de Debian effectue une rotation hebdomadaire, conserve 4 générations et compresse avec delaycompress (auth.log, auth.log.1, auth.log.2.gz ...). Par défaut, RHEL utilise une rotation hebdomadaire, rotate 4 et dateext (secure-20260920). Attendez-vous à environ un mois d'historique texte, sauf si la configuration a été modifiée. Le journal peut en conserver plus ou moins : comparez toujours les deux.

Collecte

# Dead box, from a read-only mount
tar -C /mnt/evidence -cpf /cases/2026-017/varlog.tar var/log etc/rsyslog.conf etc/rsyslog.d etc/logrotate.conf etc/logrotate.d etc/localtime

# Live, as root: copy, do not tail or edit in place
tar -C / -cpf /media/ir/varlog.tar var/log etc/rsyslog.conf etc/rsyslog.d etc/logrotate.d etc/localtime

L'artefact var_log d'UAC collecte l'intégralité de /var/log ; Velociraptor peut collecter les mêmes chemins avec ses artefacts de collecte de fichiers. Prenez aussi les générations tournées et compressées, et notez l'heure de collecte : logrotate peut se déclencher pendant que vous travaillez.

Analyse

Les outils texte simples suffisent souvent ; l'essentiel est de lire chaque génération dans l'ordre.

cd /mnt/evidence/var/log
zgrep -hE 'Accepted|Failed password|Invalid user' auth.log* secure* 2>/dev/null
zgrep -h 'sudo:' auth.log* secure* 2>/dev/null
zgrep -hE 'new user|new group|password changed' auth.log* secure* 2>/dev/null

Pour les chronologies, Plaso fournit les plugins de parser text/syslog et text/syslog_traditional ; passez --timezone pour les fichiers au format traditionnel afin que les heures locales soient correctement converties. lnav est pratique pour parcourir interactivement de nombreux fichiers tournés. 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

• Un nombre de lignes qui chute en milieu de journée, un fichier courant bien plus petit que ses prédécesseurs tournés, ou un fichier dont le mtime précède une activité connue sont des signes de modification ou de troncature. Comparez avec le journal et wtmp.
• Chaque ligne Accepted doit correspondre à une session wtmp et, si auditd tourne, à un enregistrement USER_LOGIN dans audit.log. Un pendant manquant mérite une explication.
• Rapprochez les empreintes Accepted publickey des entrées de authorized_keys (voir artefacts SSH) pour identifier la clé utilisée.
• Vérifiez /etc/rsyslog.conf et /etc/rsyslog.d/ pour y trouver des cibles de transfert (@host, @@host, omfwd) : un collecteur distant peut encore détenir des journaux supprimés localement, et une règle stop ou de rejet ajoutée récemment constitue en soi une falsification.
• L'arrêt de rsyslog.service apparaît dans le journal ; un trou dans le journal texte alors que le journal systemd continue d'écrire désigne directement le démon syslog.
• Sur les serveurs de journaux centralisés, rappelez-vous que l'horodatage peut être celui du récepteur et non de l'émetteur, selon le modèle utilisé.