Horodatages ext4, crtime et fichiers supprimés

Ce que c'est

ext4 est le système de fichiers par défaut de Debian et Ubuntu, et un choix courant ailleurs. Chaque fichier et chaque répertoire est un inode contenant ses métadonnées, dont jusqu'à cinq horodatages. Ces horodatages sont la colonne vertébrale de toute chronologie de système de fichiers Linux, et la façon dont ext4 gère la suppression détermine ce qui peut encore être récupéré après le nettoyage d'un attaquant.

Où il se trouve

Sur les systèmes live, vérifiez les options avec findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS et les fonctionnalités avec dumpe2fs -h /dev/<dev> (lecture seule).

Ce qu'il prouve

• crtime (naissance) : quand l'inode a été créé sur ce système de fichiers. Les copies et extractions reçoivent un nouveau crtime ; touch ne peut pas le modifier.
• mtime : dernière modification du contenu du fichier. Modifiable depuis l'espace utilisateur (touch -d), il peut donc être falsifié.
• ctime : dernière modification de l'inode (contenu, permissions, propriétaire, renommage, nombre de liens). Non modifiable directement ; il passe à « maintenant » dès qu'un attaquant lance touch, ce qui trahit le timestomping.
• atime : dernière lecture, soumise aux règles de relatime ci-dessous.
• dtime : défini lors de la suppression de l'inode (également utilisé pour la gestion des orphelins).
• Non prouvé : qui a réalisé l'action (combinez avec auditd, l'historique du shell ou les journaux).

Champs clés

Horodatages

Toutes les valeurs sont en UTC. stat affiche la date de naissance lorsque coreutils, la glibc et le noyau prennent en charge statx (coreutils 8.31 ou plus récent sur un noyau 4.11 ou plus récent) ; debugfs l'affiche toujours.

stat --format='%n birth=%w modify=%y change=%z access=%x' /etc/passwd
debugfs -R 'stat /etc/passwd' /dev/sda1        # crtime, dtime and nanoseconds, read-only

relatime est le comportement de montage par défaut depuis Linux 2.6.30 : l'atime n'est mis à jour que s'il est antérieur au mtime ou au ctime, ou s'il date de plus de 24 heures. noatime désactive totalement la mise à jour de l'atime. Interprétez l'atime comme « lu au moins une fois depuis environ ce moment », et non comme un journal d'accès précis. Des champs nanosecondes entièrement à zéro sur un fichier dont les voisins ont une précision complète sont un signe classique d'horodatages définis par un outil.

Rétention

• Les horodatages changent avec l'activité normale ; une image réalisée rapidement les préserve.
• Lors d'une suppression, ext4 définit i_dtime, ramène le nombre de liens à zéro et efface le mappage de blocs ou d'extents de l'inode : l'inode seul ne pointe donc généralement plus vers les données. Les entrées de répertoire peuvent conserver le nom un certain temps.
• D'anciennes copies de l'inode peuvent survivre dans le journal jusqu'à ce qu'il reboucle, et c'est sur quoi repose la récupération via le journal.
• Les blocs de données restent dans l'espace non alloué jusqu'à leur réutilisation ; fstrim ou discard sur SSD peuvent les effacer rapidement.

Collecte

Réalisez une image du périphérique en lecture seule (dd, dc3dd ou ewfacquire derrière un bloqueur d'écriture, ou un snapshot cloud/VM) et travaillez sur la copie. Pour un triage live, la sortie bodyfile d'UAC enregistre chemins, tailles et horodatages (la date de naissance uniquement lorsque sa méthode de collecte peut la lire), et Velociraptor offre la même chose via ses artefacts de chronologie. Montez les images avec -o ro,noload afin que le journal ne soit pas rejoué.

Analyse

fls -r -m / -o <offset> image.raw > body.txt      # The Sleuth Kit, includes deleted names
mactime -b body.txt -d -z UTC > timeline.csv
istat -o <offset> image.raw <inode>               # full inode, times, dtime
icat -o <offset> image.raw <inode> > recovered    # content if blocks are still mapped
debugfs -c -R 'ls -d /tmp' image.raw              # deleted entries shown in <angle brackets>
ext4magic image.raw -a <epoch> -f /home/user -r -d /cases/out   # journal-based recovery

Plaso (log2timeline.py) analyse les horodatages du système de fichiers avec les journaux pour produire une super timeline. ext4magic (dernière version en 2014) et extundelete (dernière version en 2013) ne sont plus maintenus ; les résultats varient avec les fonctionnalités récentes d'ext4 : validez donc les fichiers récupérés.

Conseils d'investigation

• Comparez crtime et mtime : un fichier « modifié » des années avant sa naissance sur ce disque a été copié, extrait d'une archive ou a subi un timestomping.
• Un ctime postérieur à tous les autres horodatages avec un mtime rond est l'empreinte typique de touch -d ou touch -r.
• Les fichiers installés par un paquet reçoivent le mtime du paquet, pas l'heure d'installation ; utilisez le crtime et les journaux des gestionnaires de paquets pour l'heure d'installation.
• Les noms supprimés dans /tmp et /var/tmp sont des cibles de choix : fls -d ne liste que les entrées supprimées.
• Un grand nombre d'inodes partageant le même dtime indique une suppression de masse scriptée ; mettez-la en regard de l'historique du shell et d'auditd.
• Consignez les hypothèses de fuseau horaire de l'image : ext4 est en UTC, mais les fichiers journaux associés peuvent être en heure locale.