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
Outils
Comparer tous les outils- Linux Log ParserNavigateur
- last / lastbCLI · intégré à Linux
- utmpdumpCLI · intégré à Linux
- wtmpdbCLI · open source
- PlasoCLI · open source
- VelociraptorPlateforme · open source
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
| Fichier | Chemin | Lecteur | Remarques |
|---|---|---|---|
| wtmp | /var/log/wtmp, /var/log/wtmp.1 | last | Historique des sessions, redémarrages, arrêts |
| btmp | /var/log/btmp, /var/log/btmp.1 | lastb | Échecs de connexion, mode 0600/0660 |
| utmp | /run/utmp (/var/run/utmp) | who, w | tmpfs : sessions en cours uniquement, disparaît au redémarrage |
| lastlog | /var/log/lastlog | lastlog | Fichier creux indexé par UID |
| wtmpdb (openSUSE, défaut en amont) | /var/lib/wtmpdb/wtmp.db | wtmpdb last | SQLite, compatible an 2038 |
| wtmpdb (Debian 13) | /var/log/wtmp.db | wtmpdb last | Debian conserve un lien à /var/lib/wtmpdb/wtmp.db |
| lastlog2 | /var/lib/lastlog/lastlog2.db | lastlog2 | SQLite, 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
rebootetshutdownsur le terminal~), y compris les fins brutales où une session n'a pas de déconnexion (crashougone - no logoutdanslast). - 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) :
| Champ | Signification |
|---|---|
ut_type | 1 RUN_LVL, 2 BOOT_TIME, 5 INIT_PROCESS, 6 LOGIN_PROCESS, 7 USER_PROCESS (connexion), 8 DEAD_PROCESS (déconnexion) |
ut_pid | PID du processus de connexion |
ut_line | Terminal (pts/0), 32 octets au maximum |
ut_id | Suffixe du terminal ou identifiant inittab |
ut_user | Nom d'utilisateur, 32 octets au maximum ; vide dans les enregistrements de déconnexion de wtmp |
ut_host | Hôte distant, ou version du noyau pour les enregistrements de démarrage, 256 octets au maximum |
ut_session | Identifiant de session |
ut_tv | tv_sec et tv_usec, tous deux sur 32 bits sur les plateformes biarch |
ut_addr_v6 | IP 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
lastcorrespond à la structure des enregistrements (glibc 64 bits). Debian 13 ne fournit pluslast; 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 -rreconvertit du texte modifié en binaire, la falsification est donc facile pour root : prouvez-la par les incohérences avec auth.log, le journal et lesUSER_LOGINd'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
lastlogplus 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_hostdes enregistrementsrebootavec 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).