Aller au contenu

Activité utilisateurJournauxRéseau

wtmp, btmp, utmp et lastlog : connexions Linux

Enregistrements de connexion Linux : historique wtmp, échecs btmp, sessions en cours utmp, dernière connexion lastlog et leurs successeurs wtmpdb/lastlog2.

Emplacement
/var/log/wtmp
Prouve
Qui s'est connecté, sur quel terminal, depuis quel hôte, quand la session s'est terminée et quand le système a redémarré
Horodatages
Enregistrements utmp : secondes epoch Unix + microsecondes (champs 32 bits), UTC. wtmpdb : microsecondes depuis l'epoch
Accès
Lisibles par tous pour wtmp/utmp/lastlog ; root (ou groupe utmp) pour btmp
Rétention
logrotate : mensuelle, 1 ancienne génération pour wtmp et btmp ; lastlog jusqu'à écrasement
Collecte
UAC, Velociraptor, cp -a

Ce que c'est

Linux conserve la comptabilité des connexions dans une famille de fichiers binaires partageant une même structure d'enregistrement, struct utmp (voir wtmp et btmp). wtmp est un historique en ajout seul des connexions, déconnexions, démarrages et arrêts ; btmp enregistre les échecs de connexion ; utmp ne contient que les sessions ouvertes à l'instant présent. lastlog utilise un autre format : un emplacement de taille fixe par UID, contenant la connexion la plus récente de ce compte.

Ces fichiers sont écrits par login, sshd, les gestionnaires d'affichage et les modules PAM, indépendamment de syslog. Cette indépendance fait leur valeur forensique : ils survivent souvent à la modification des journaux texte, et les contredisent quand une seule source a été falsifiée.

Comme l'enregistrement classique utilise des champs horaires 32 bits, les distributions récentes les remplacent par des bases SQLite : wtmpdb pour wtmp et lastlog2 (intégré à util-linux depuis la 2.40) pour lastlog.

Où il se trouve

FichierCheminLecteurRemarques
wtmp/var/log/wtmp, /var/log/wtmp.1lastHistorique des sessions, redémarrages, arrêts
btmp/var/log/btmp, /var/log/btmp.1lastbÉchecs de connexion, mode 0600/0660
utmp/run/utmp (/var/run/utmp)who, wtmpfs : sessions en cours uniquement, disparaît au redémarrage
lastlog/var/log/lastloglastlogFichier creux indexé par UID
wtmpdb (openSUSE, défaut en amont)/var/lib/wtmpdb/wtmp.dbwtmpdb lastSQLite, compatible an 2038
wtmpdb (Debian 13)/var/log/wtmp.dbwtmpdb lastDebian conserve un lien à /var/lib/wtmpdb/wtmp.db
lastlog2/var/lib/lastlog/lastlog2.dblastlog2SQLite, compatible an 2038

Particularités des distributions : openSUSE Tumbleweed et MicroOS ont abandonné /run/utmp, /var/log/wtmp et /var/log/lastlog au profit de systemd-logind, wtmpdb et lastlog2. Debian 13 (trixie) a supprimé last, lastb et lastlog ; leurs remplaçants wtmpdb et lastlog2 (avec leurs modules PAM) doivent être installés séparément après une mise à niveau (lslogins reste fourni par util-linux), si bien qu'un hôte trixie peut n'avoir aucune base de connexions. RHEL/Fedora et les versions LTS d'Ubuntu utilisent encore couramment les fichiers classiques ; vérifiez ce qui existe sur l'image.

Ce qu'il prouve

  • Les connexions interactives avec utilisateur, terminal (pts/N, tty1, :0), hôte ou IP distant, heure de début et de fin.
  • Les redémarrages et arrêts (pseudo-utilisateurs reboot et shutdown sur le terminal ~), y compris les fins brutales où une session n'a pas de déconnexion (crash ou gone - no logout dans last).
  • Les échecs de connexion avec le nom d'utilisateur tenté, qui peut contenir des mots de passe saisis par erreur dans le champ utilisateur. Traitez btmp comme sensible.
  • La dernière connexion de chaque compte via lastlog, même après la disparition de wtmp par rotation.
  • Il ne montre pas l'activité non interactive : ssh host command, scp/sftp et de nombreuses connexions automatisées n'allouent pas de tty et sont souvent absents. Utilisez auth.log/secure et le journal pour ces cas.

Champs clés

struct utmp (384 octets par enregistrement sur les systèmes glibc 64 bits courants) :

ChampSignification
ut_type1 RUN_LVL, 2 BOOT_TIME, 5 INIT_PROCESS, 6 LOGIN_PROCESS, 7 USER_PROCESS (connexion), 8 DEAD_PROCESS (déconnexion)
ut_pidPID du processus de connexion
ut_lineTerminal (pts/0), 32 octets au maximum
ut_idSuffixe du terminal ou identifiant inittab
ut_userNom d'utilisateur, 32 octets au maximum ; vide dans les enregistrements de déconnexion de wtmp
ut_hostHôte distant, ou version du noyau pour les enregistrements de démarrage, 256 octets au maximum
ut_sessionIdentifiant de session
ut_tvtv_sec et tv_usec, tous deux sur 32 bits sur les plateformes biarch
ut_addr_v6IP distante (IPv4 dans le premier mot)

struct lastlog : ll_time (epoch 32 bits), ll_line (32 octets), ll_host (256 octets), soit 292 octets par emplacement à l'offset UID x 292. wtmpdb stocke Type, User, Login, Logout, TTY, RemoteHost et Service (le service PAM) pour chaque ligne.

Horodatages

Les enregistrements classiques stockent des secondes epoch Unix plus des microsecondes, en UTC. last affiche dans le fuseau local de la machine d'analyse : définissez donc TZ=UTC. Les champs 32 bits débordent en janvier 2038. wtmpdb stocke Login et Logout en microsecondes depuis l'epoch.

TZ=UTC last -F -i -x -f /mnt/evidence/var/log/wtmp
sqlite3 wtmp.db "SELECT User, TTY, RemoteHost, Service,
  datetime(Login/1000000,'unixepoch'), datetime(Logout/1000000,'unixepoch') FROM wtmp;"

Rétention

Les blocs standard de logrotate font tourner wtmp et btmp chaque mois et conservent une ancienne génération (wtmp.1, btmp.1) : attendez-vous à un ou deux mois d'historique. Ces blocs se trouvent dans /etc/logrotate.conf ou dans /etc/logrotate.d/wtmp et btmp selon la distribution. utmp est vidé à chaque démarrage. lastlog conserve indéfiniment un enregistrement par UID, écrasé à chaque connexion. wtmpdb rotate déplace les anciennes entrées dans des fichiers datés wtmp_<date>.db à côté de la base (/var/lib/wtmpdb/ en amont, /var/log/ sous Debian).

Collecte

Copiez les fichiers avec leurs métadonnées. La taille compte : un wtmp dont la taille n'est pas un multiple de celle d'un enregistrement, ou bien plus petit que prévu, est une découverte en soi.

cp -a /mnt/evidence/var/log/{wtmp,wtmp.1,btmp,btmp.1,lastlog} /cases/2026-017/ 2>/dev/null
cp -a /mnt/evidence/var/lib/wtmpdb /mnt/evidence/var/lib/lastlog /cases/2026-017/ 2>/dev/null
cp -a /mnt/evidence/var/log/wtmp.db /cases/2026-017/ 2>/dev/null
# Live only: current sessions
cp -a /run/utmp /media/ir/ && who -a > /media/ir/who.txt

UAC collecte /var/log et /var/run/utmp et exécute last, lastb, lastlog et utmpdump en réponse live. L'artefact Velociraptor Linux.Sys.LastUserLogin analyse les fichiers wtmp* sur le poste.

Analyse

last -F -i -x -f wtmp            # full dates, IPs, system events
lastb -F -i -f btmp              # failed logins
utmpdump wtmp > wtmp.txt         # every record and field, text
wtmpdb last -F -f wtmp.db        # wtmpdb databases
lastlog2 -d lastlog2.db          # lastlog2 databases

La commande classique lastlog lit le fichier du système live : pour une copie issue d'une image, lisez les emplacements de 292 octets avec un petit script (numéro d'emplacement = UID, ignorez les emplacements entièrement à zéro). Le parser utmp de Plaso gère wtmp, btmp et utmp pour les super timelines. 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

  • Travaillez sur une machine d'analyse dont le last correspond à la structure des enregistrements (glibc 64 bits). Debian 13 ne fournit plus last ; utilisez une version d'util-linux d'une autre distribution, ou Plaso.
  • Dans la sortie de utmpdump, cherchez les enregistrements mis à zéro, les horodatages qui reculent et les connexions sans déconnexion. utmpdump -r reconvertit du texte modifié en binaire, la falsification est donc facile pour root : prouvez-la par les incohérences avec auth.log, le journal et les USER_LOGIN d'audit.log.
  • Une rafale d'entrées btmp depuis une IP suivie d'une connexion wtmp depuis la même IP est le schéma classique d'une attaque par force brute réussie.
  • Une heure lastlog plus récente que le dernier enregistrement wtmp correspondant signifie que wtmp a perdu des entrées (rotation ou suppression).
  • Comparez la version du noyau dans ut_host des enregistrements reboot avec les noyaux installés pour repérer des démarrages sur un noyau inattendu.
  • Un wtmp ou btmp de zéro octet avec un mtime ancien sur un serveur actif est un signe courant d'anti-forensique (> /var/log/wtmp).

Voir aussi