Analyse forensique d’auth.log et secure : SSH, sudo, su

En bref. auth.log (Debian, Ubuntu) et secure (famille RHEL) sont les fichiers où rsyslog écrit les facilities auth et authpriv : sshd, sudo, su, PAM, passwd, useradd, sessions cron. Regroupez les lignes sshd par PID pour reconstituer chaque connexion, comptez les échecs par adresse source, cherchez le premier succès qui les suit, puis suivez la session jusque dans sudo. Identifiez le format d’horodatage avant de convertir quoi que ce soit.

Quel fichier, quel format

Distribution	Authentification	Tout le reste	Horodatage
Ubuntu 24.04, Debian 12+	`/var/log/auth.log`	`/var/log/syslog`	RFC 3339, microsecondes, décalage
Anciennes Debian et Ubuntu	`/var/log/auth.log`	`/var/log/syslog`	Traditionnel, heure locale, sans année
RHEL, Rocky, Alma, Fedora	`/var/log/secure`	`/var/log/messages`	Traditionnel, heure locale, sans année

Les deux formats côte à côte :

Sep 14 10:02:11 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2
2026-09-14T10:02:11.482113+00:00 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2

Pour la première forme (style RFC 3164), lisez le fuseau dans /etc/localtime et déduisez l’année de la date de modification du fichier et de l’ordre de rotation. Un fichier qui chevauche le Nouvel An contient des lignes de décembre suivies de lignes de janvier ; celles de janvier appartiennent à l’année suivante. Autour des changements d’heure, les heures locales peuvent se répéter ou sauter une heure.

Debian 12 et certaines installations Fedora n’ont pas du tout rsyslog. L’absence d’auth.log ne prouve pas une suppression ; consultez le journal systemd.

SSH : reconstituer chaque connexion par PID

Chaque connexion a son propre processus sshd (sur OpenSSH 9.8 et versions ultérieures, le processus par connexion est sshd-session : cherchez les deux noms). Toutes les lignes d’une connexion partagent ce PID :

sshd[2381]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.23  user=svc_backup
sshd[2381]: Failed password for svc_backup from 198.51.100.23 port 40135 ssh2
sshd[2381]: Connection closed by authenticating user svc_backup 198.51.100.23 port 40135 [preauth]

Messages clés :

Message	Signification
`Invalid user admin from IP`	Le compte n’existe pas sur l’hôte
`Failed password for [invalid user] X from IP`	Mauvais mot de passe (ou utilisateur inexistant)
`Accepted password for X from IP`	Connexion par mot de passe réussie
`Accepted publickey for X from IP ... ED25519 SHA256:...`	Connexion par clé ; l’empreinte identifie la clé
`pam_unix(sshd:session): session opened for user X`	Début de session, même PID que la ligne `Accepted`
`pam_unix(sshd:session): session closed for user X`	Fin de session, même PID
`Connection closed by ... [preauth]`	Déconnexion avant authentification

Les lignes pam_unix proviennent du module pam_unix ; systemd-logind: New session 7 of user X suit en quelques millisecondes et attribue à la session un numéro qui apparaît aussi dans le journal sous la forme session-7.scope.

Essais de mots de passe, puis un succès

Le motif qui compte n’est pas « beaucoup d’échecs » (tout serveur SSH exposé à Internet en a) mais des échecs suivis d’un succès :

Comptez les lignes Failed password et Invalid user par adresse source et listez les noms de comptes essayés.
Cherchez une ligne Accepted pour l’un de ces comptes après le dernier échec, depuis la même adresse ou depuis une autre. Une adresse différente quelques minutes plus tard est courante : les essais venaient d’une machine, la connexion d’une autre.
Vérifiez si la méthode réussie est password pour un compte qui se connecte normalement avec publickey. Un compte de service qui utilisait toujours une clé et passe soudain par un mot de passe est une piste sérieuse.
Comparez l’adresse source à l’historique du compte. Une connexion depuis une adresse jamais vue pour ce compte mérite une question à son propriétaire.

zgrep -hE 'sshd(-session)?\[[0-9]+\]: (Failed password|Invalid user)' auth.log* | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn
zgrep -hE 'sshd(-session)?\[[0-9]+\]: Accepted' auth.log*

N’oubliez pas que, sur un hôte qui exécute à la fois rsyslog et journald, chaque ligne existe en double ; compter ensemble le journal et auth.log double les chiffres. btmp contient une troisième copie des tentatives échouées.

sudo et su

sudo écrit une ligne par commande :

sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=list
sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=/bin/bash
sudo:   pam_unix(sudo-i:session): session opened for user root(uid=0) by svc_backup(uid=1001)

COMMAND=list correspond à sudo -l : l’utilisateur vérifie les droits dont il dispose. C’est souvent la première chose qu’exécute un intrus.
COMMAND=/bin/bash avec le service PAM sudo-i correspond à sudo -i, un shell root interactif. À partir de là, auth.log ne voit plus les commandes individuelles ; seules les commandes relancées via sudo sont journalisées. Suivez la session dans auditd, où auid conserve l’utilisateur d’origine.
Échecs : user NOT in sudoers, command not allowed, N incorrect password attempts et pam_unix(sudo:auth): authentication failure.
su journalise pam_unix(su:session): session opened for user root by X (ou su-l pour su -) et, en cas d’échec, des messages du type FAILED SU, selon la distribution.

Les espaces dans les arguments de sudo sont journalisés tels quels, ce qui rend certaines lignes de commande ambiguës (/srv/finance/Q3 close : un argument ou deux ?). L’enregistrement d’audit USER_CMD encode ces valeurs en hexadécimal et tranche la question.

Comptes et mots de passe

Les lignes useradd[PID]: new user: name=..., groupadd, usermod et gpasswd pour les modifications de comptes.
passwd[PID]: pam_unix(passwd:chauthtok): password changed for X lors d’un changement de mot de passe. Un intrus qui change le mot de passe du compte par lequel il est entré verrouille le propriétaire dehors et conserve l’accès.
chpasswd et chage pour les changements en masse et les expirations.

Cron

CRON[PID]: pam_unix(cron:session): session opened for user X apparaît dans auth.log à chaque exécution de tâche ; la commande elle-même se trouve dans syslog (CRON[PID]: (X) CMD (...)), et une modification de crontab apparaît sous la forme crontab[PID]: (root) REPLACE (X). Une nouvelle crontab utilisateur installée pendant une session interactive est une piste de persistance.

Aller plus vite

Linux Log Parser lit auth.log, secure, syslog et messages dans les trois formats, y compris les fichiers tournés et .gz, reconstitue les sessions à partir des paires de PID sshd et de logind, marque les lignes qui existent aussi dans le journal, et signale les essais de mots de passe suivis d’un succès, les connexions depuis une nouvelle adresse, les connexions SSH en root, les shells root via sudo et su, les échecs sudo et les modifications de comptes. L’investigation pas à pas montre ces constats sur un exemple.

Tableaux de référence sur linuxforensics.app : auth.log et syslog, journaux sudo et artefacts SSH.