© Luis Louro, 123RF

Die Unterschiede zwischen Linux und BSD fangen bei alltäglichen Tools wie Ifconfig oder Fdisk an. Dank ZFS machen sie aber auch nicht vor Festplattenimages halt. Vor allem das neue BSD 10 bereitet dem Linux-Admin bei der Rekonstruktion von Daten aus ZFS-Pools Probleme.

Seit das Linux-Magazin zuletzt über das mächtige Solaris-Dateisystem ZFS berichtete [1], hat sich einiges getan. So setzt beispielsweise auch das Free-Nas-Projekt [2] mit seiner Live-CD auf ZFS für die Datenplatten – zumindest dann, wenn es die Voraussetzungen der Hardware erlauben.

Gerichtsfestes Beispiel

Das vorliegende Beispiel wird auch dem Linux-Admin nicht fremd sein, obwohl es aus dem Vorfeld einer konkreten Gerichtsverhandlung stammt, bei der ein Sachverständiger die Aufgabe erhielt, ein Festplattenimage auszuwerten: Der Geschädigte erstellte ein Dd-Image seines Servers, um dies dem Gericht vorzulegen. Danach speicherte er das Image auf einer Festplatte, die an einem Free-NAS-System angeschlossen war.

Das Serverimage sollten Experten anschließend direkt von der Datenplatte an einer Linux-Auswertestation analysieren. Windows schied dafür von vornherein aus, weil ihm ZFS-Dateisysteme verwehrt bleiben.

Kein MBR, kein GPT – auch kein Raid?

Der Artikel unter [1] zeigt, welche Möglichkeiten Linux hier bietet – wobei es dem Forensiker naturgemäß nicht so auf Geschwindigkeit ankommt wie vermutlich einem Admin. Doch überraschenderweise zeigte die vorliegende Datenplatte keine Partitionsinformationen in Form eines MBR oder einer GPT [2].

Auch die Tricks, die der Artikel in der vorigen Ausgabe [3] nutzte, um Raid-Systeme wiederzubeleben (Abbildung 1), halfen nicht: Weder Fdisk noch Mmls – das forensische Pendant aus dem Sleuthkit – ließen sich zur Mitarbeit überreden.

Abbildung 1: Fdisk kann mit der GPT-Partition gar nichts anfangen, während Mmls schon etwas auskunftsfreudiger reagiert.

Free NAS und BSD

Eine Rückfrage beim Geschädigten ergab, dass dieser das Image über besagtes Free-NAS-System [4] abgelegt hatte. Es basiert auf BSD, das dort übliche Dateiformat hätte folglich UFS-Informationen liefern müssen. Da aber diese nicht vorhanden waren, musste es sich zwangsläufig um ZFS oder um eine defekte Festplatte handeln – Letzteres ließ sich definitiv ausschließen.

Dass auch das Anfang 2014 erschienene Free BSD 10 [5] mit ZFS arbeitet, wird die Zahl der ZFS-Installationen sicher positiv beeinflussen und mehr Admins in diese Situation bringen. Auch wenn das Dateisystem derzeit noch als experimentell gilt, ist es bereits voll funktionsfähig und für einen Testkandidaten als Samba-Server einsetzbar.

Spielwiese mit ZFS-Fuse und ZFS on Linux

Wer nun eine solche ZFS-Festplatte entfernt und in ein Linux-System einbindet, steht vor dem gleichen Problem wie die Forensiker im Beispiel oben: Das installierte ZFS-Fuse erkennt zwar einen Zpool, ihn zu mounten ist ihm jedoch nicht möglich, da der Fuse-Treiber derzeit leider mit einer veralteten ZFS-Version arbeitet. Die Lösung dafür bietet das ZFS-on-Linux-Projekt [6].

Im Gegensatz zum Fuse-Treiber aus dem Standardrepository arbeitet es mit Kerneltreibern und kann so eine Performance bieten, die diesen Namen verdient. Der Administrator übernimmt das PPA mit dem Befehl »add-apt-repository ppa:zfs-native/stable« und erhält alle notwendigen Programme nach einem »aptitude update« (Listing 1).

01 p   libzfs-dev                          - Native ZFS filesystem development files for Linux
02 p   libzfs-dev:i386                     - Native ZFS filesystem development files for Linux
03 p   libzfs1                             - Native ZFS filesystem library for Linux
04 p   libzfs1:i386                        - Native ZFS filesystem library for Linux
05 p   libzfs1-dbg                         - Debugging symbols for libzfs1
06 p   libzfs1-dbg:i386                    - Debugging symbols for libzfs1
07 i A libzfs2                             - Native ZFS filesystem library for Linux
08 p   libzfs2:i386                        - Native ZFS filesystem library for Linux
09 p   libzfs2-dbg                         - Debugging symbols for libzfs2
10 p   libzfs2-dbg:i386                    - Debugging symbols for libzfs2
11 v   lzfs                                -
12 v   lzfs:i386                           -
13 v   lzfs-dkms                           -
14 v   lzfs-dkms:i386                      -
15 i   ubuntu-zfs                          - Native ZFS filesystem metapackage for Ubuntu.
16 p   ubuntu-zfs:i386                     - Native ZFS filesystem metapackage for Ubuntu.
17 p   zfs-auto-snapshot                   - ZFS Automatic Snapshot Service
18 i   zfs-dkms                            - Native ZFS filesystem kernel modules for Linux
19 p   zfs-dkms:i386                       - Native ZFS filesystem kernel modules for Linux
20 v   zfs-dkms-build-depends              -
21 c   zfs-fuse                            - ZFS als FUSE
22 p   zfs-fuse:i386                       - ZFS als FUSE
23 p   zfs-initramfs                       - Native ZFS root filesystem capabilities for Linux
24 p   zfs-initramfs:i386                  - Native ZFS root filesystem capabilities for Linux
25 v   zfs-mountall                        -
26 v   zfs-mountall:i386                   -
27 i   zfsutils                            - Native ZFS management utilities for Linux
28 p   zfsutils:i386                       - Native ZFS management utilities for Linux
29 p   zfsutils-dbg                        - Debugging symbols for zfsutils
30 p   zfsutils-dbg:i386                   - Debugging symbols for zfsutils

Die ZFS-Tools installieren und den Zpool importieren

Der Befehl »aptitude install ubuntu-zfs« installiert alle Programme und Treiber. DKMS erledigt das Upgrade automatisch nach den recht häufig auftretenden Ubuntu-Kernel-Upgrades. Wer jetzt Fdisk und Mmls benutzt, bekommt dennoch (ein wenig) hilfreiche Information (Abbildung 1).

Nötig ist der Zugriff auf das Dateisystem, es ließe sich in »06: zfs0« vermuten. Aber um den Namen des Pools zu ermitteln, hilft erst das besagte »zpool import« (Listing 2). Der Name des Pools lautet also »zroot« (Zeile 2), unter diesem Namen lässt er sich dann endlich auch mounten.

01 zpool import
02    pool: zroot
03      id: 8592000589434241473
04   state: ONLINE
05  status: The pool was last accessed by another system.
06  action: The pool can be imported using its name or numeric identifier and
07         the '-f' flag.
08    see: http://zfsonlinux.org/msg/ZFS-8000-EY
09  config:
10
11         zroot                      ONLINE
12           ata-ST380215AS_9QZ68Z7S  ONLINE

Bitte nicht nach Root

Doch ist hier Vorsicht geboten: Ohne weitere Optionen würde der Zpool nämlich ins Root-Verzeichnis des aktiven Systems eingebunden. Ein darin enthaltenes »/var« -Verzeichnis landet dann – im laufenden Linux System – über dem vorhandenen »/var« . Probleme wären programmiert, daher empfiehlt es sich, eine neue »/« -Struktur anzugeben.

Das folgende Beispiel nutzt dazu »/media/zfs« :

zpool import -f -R /media/zfs/ zroot

Dabei steht »-f« für »–force« , »-R« legt einen neuen Ziel-Root fest, »zroot« ist der Name des gefundenen Pools. Ein Blick in »/media/zfs« zeigt: Der Admin hat vollen Zugriff auf das Dateisystem, für ihn ist der Fall damit gelöst (Abbildung 2).

Abbildung 2: So unspektakulär kann der Erfolg aussehen: Der Inhalt des ZFS-Pools unter »/media/zfs«.

Für Forensiker ist es ein wenig komplizierter

Anders für den, der gerichtsfeste Beweise bieten muss. Der Forensiker arbeitet mit Images und auf keinen Fall am Originalsystem – wegen der Nachweispflicht, nichts verändert zu haben, und der Gefahr, Beweise zu vernichten.

Die Vorgabe erweist sich mit ZFS und Linux als tückisch: Der Zpool kann mit dem Dd-Image nichts anfangen, da er ja erst einmal nur physikalische Geräte anzeigt. Da hilft nur ein Loop-Device weiter:

losetup -o $((4195362*512)) /dev/loop0 image.dd

Die ZFS-Partition überführt Root also in ein Loop-Device, anschließend informiert er den Zpool, dass die ZFS-Pool-Informationen nicht physikalisch, sondern als Loop-Device in »/dev« vorliegen. »4195362« ist dabei der Sektor-Offset zur »zfs0« -Partition. Weil der noch in Bytes umgerechnet werden muss, taucht hier die Multiplikation auf der Kommandozeile auf (»*512« ). Der angepasste Zpool-Befehl lautet nun:

zpool import -f -d /dev -R /media/zfs

Damit ist auch der logische Zugriff für den Forensiker auf ein Image mit ZFS-Dateisystem sichergestellt. Weil der in der Regel lieber mit dem Expert-Witness-Format und nicht mit den unhandlichen Raw-Images arbeitet, greift er zu Xmount, um das Image on the Fly einzubinden und zu konvertieren:

xmount --in ewf --out dd --cache /tmp/zfs.ovl image.E* /ewf
losetup -o $((4195362*512)) /dev/loop0 /ewf/image.dd
zpool import -f -d /dev -R /media/zfs

Der Xmount-Entwickler Daniel Gillen [7] hat bereits eine neue Version in Bearbeitung, die auch das direkte Konvertieren mit Offset ermöglichen wird (siehe Test im folgenden Artikel).

Der Autor

Hans-Peter Merkel ist mit dem Schwerpunkt Datenforensik seit vielen Jahren in der Open-Source-Community aktiv. Er bildet Mitarbeiter von Strafverfolgungsbehörden in Europa, Asien und Afrika aus und engagiert sich als Gründer und Vorsitzender bei Freioss und Linux4afrika.