ext4-Zeitstempel, crtime und gelöschte Dateien

Was es ist

ext4 ist das Standard-Dateisystem von Debian und Ubuntu und auch anderswo verbreitet. Jede Datei und jedes Verzeichnis ist ein Inode mit seinen Metadaten, darunter bis zu fünf Zeitstempel. Diese Zeitstempel sind das Rückgrat jeder Dateisystem-Timeline unter Linux, und die Art, wie ext4 mit Löschungen umgeht, entscheidet darüber, was sich nach dem Aufräumen eines Angreifers noch wiederherstellen lässt.

Wo es liegt

Prüfen Sie auf laufenden Systemen die Optionen mit findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS und die Features mit dumpe2fs -h /dev/<dev> (nur lesend).

Was es belegt

• crtime (Geburt): wann der Inode auf diesem Dateisystem erstellt wurde. Kopien und entpackte Dateien erhalten eine neue crtime; touch kann sie nicht ändern.
• mtime: letzte Änderung des Dateiinhalts. Aus dem Userspace setzbar (touch -d) und damit fälschbar.
• ctime: letzte Änderung des Inodes (Inhalt, Berechtigungen, Eigentümer, Umbenennung, Linkzähler). Nicht direkt setzbar; sie springt auf "jetzt", sobald ein Angreifer touch ausführt, was Timestomping entlarvt.
• atime: letzter Lesezugriff, gemäß den unten beschriebenen relatime-Regeln.
• dtime: wird beim Löschen des Inodes gesetzt (auch für die Behandlung verwaister Inodes genutzt).
• Nicht belegt: wer die Aktion ausgeführt hat (kombinieren Sie mit auditd, Shell-History oder Logs).

Wichtige Felder

Zeitstempel

Alle Werte sind UTC. stat zeigt die Geburtszeit, wenn coreutils, glibc und Kernel statx unterstützen (coreutils 8.31 oder neuer auf Kernel 4.11 oder neuer); debugfs zeigt sie immer.

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 ist seit Linux 2.6.30 das Standardverhalten beim Mounten: atime wird nur aktualisiert, wenn sie älter als mtime oder ctime ist oder mehr als 24 Stunden zurückliegt. noatime deaktiviert atime-Aktualisierungen vollständig. Verstehen Sie atime als "seit ungefähr diesem Zeitpunkt mindestens einmal gelesen", nicht als genaues Zugriffsprotokoll. Nanosekundenfelder, die nur aus Nullen bestehen, bei einer Datei, deren Nachbarn volle Genauigkeit haben, sind ein klassisches Zeichen für per Werkzeug gesetzte Zeitstempel.

Aufbewahrung

• Zeitstempel ändern sich durch normale Aktivität; ein zeitnah erstelltes Image bewahrt sie.
• Beim Löschen setzt ext4 i_dtime, senkt den Linkzähler auf null und löscht die Block- bzw. Extent-Zuordnung des Inodes, sodass der Inode allein meist nicht mehr auf die Daten zeigt. Verzeichniseinträge können den Namen noch eine Weile behalten.
• Ältere Kopien des Inodes können im Journal überdauern, bis es überläuft; darauf beruht die journalbasierte Wiederherstellung.
• Datenblöcke bleiben bis zur Wiederverwendung im nicht zugewiesenen Bereich; fstrim oder discard auf SSDs können sie schnell löschen.

Sicherung

Erstellen Sie ein schreibgeschütztes Image des Geräts (dd, dc3dd oder ewfacquire hinter einem Writeblocker oder ein Cloud-/VM-Snapshot) und arbeiten Sie mit der Kopie. Für die Live-Triage erfasst die bodyfile-Ausgabe von UAC Pfade, Größen und Zeitstempel (die Geburtszeit nur, wenn die Sammelmethode sie lesen kann), und Velociraptor bietet dasselbe über seine Timeline-Artefakte. Hängen Sie Images mit -o ro,noload ein, damit das Journal nicht wiedergegeben wird.

Auswertung

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) übernimmt die Dateisystem-Zeitstempel zusammen mit Logs in eine Super-Timeline. ext4magic (letztes Release 2014) und extundelete (letztes Release 2013) werden nicht mehr gepflegt; die Ergebnisse schwanken bei modernen ext4-Features, validieren Sie wiederhergestellte Dateien daher.

Tipps für die Untersuchung

• Vergleichen Sie crtime mit mtime: Eine Datei, die Jahre vor ihrer Entstehung auf diesem Datenträger "geändert" wurde, ist kopiert, aus einem Archiv entpackt oder per Timestomping manipuliert worden.
• Eine ctime, die später liegt als alle anderen Zeiten, kombiniert mit einer runden mtime, ist der typische Fußabdruck von touch -d oder touch -r.
• Aus Paketen installierte Dateien erhalten die mtime aus dem Paket, nicht den Installationszeitpunkt; nutzen Sie für den Installationszeitpunkt crtime und die Paketmanager-Logs.
• Gelöschte Namen in /tmp und /var/tmp sind lohnende Ziele: fls -d listet nur gelöschte Einträge.
• Viele Inodes mit derselben dtime deuten auf eine skriptgesteuerte Massenlöschung hin; gleichen Sie das mit Shell-History und auditd ab.
• Dokumentieren Sie die Zeitzonenannahmen zum Image: ext4 ist UTC, die Logdateien drumherum können aber in Ortszeit vorliegen.