© Pablo Scapinachis Armstrong, 123rf.com

Wenn der alte Linux-Server mit seinem Raid-Verbund oder die betagte Windows-Kiste in ein neues, virtuelles Heim umziehen, sind gute Ideen und Software wie Opengates die besten Umzugshelfer. Der Artikel beschreibt zwei Beispiele aus einem aktuellen Gerichtsverfahren .

Schöner Mist. Die alte Pizzaschachtel tut\’s nicht mehr. Wer jetzt noch Zugriff auf die Daten im Raid-Verbund braucht, muss tricksen. Das Gleiche gilt für den Admin, der seinen Windows-Rechner in eine Virtualisierung einbauen will. Forensiker in Ermittlungsbehörden stehen noch viel häufiger vor solchen Problemen und haben dafür interessante Lösungen entwickelt. Zwar gehört es zu ihrer täglichen Arbeit, ein beliebiges Linux-System zu virtualisieren [1], doch mehrere Festplatten wieder passend zusammenzuführen erweist sich oft als viel schwieriger.

Ungeliebtes Blau

In der Microsoft-Welt lauern andere Hürden. Das beginnt schon mit dem berüchtigten Blue Screen of Death direkt nach dem Booten wegen falscher IDE-Treiber und geht über die verfallene Systemregistrierung beim Hersteller bis zur Anmeldung am System mit dem richtigen Passwort. Bis ein arbeitsfähiger Desktop erscheint, ist einiges an Vorarbeit notwendig. Der Forensiker Gillen Daniel hat dafür mit Opengates [2] ein Tool entwickelt, das auch dem Windows-Admin gute Dienste leistet.

Laufendes Verfahren

Beide Maschinen im folgenden Beispiel stammen aus einem Ermittlungsverfahren: Fahnder hatten einen Linux-Server sichergestellt, auf dem ein Software-Raid werkelte, gemanagt von einem Flash-Modul auf dem IDE-Steckplatz. Der dazu passende Client ging unter Windows XP auf Kundenfang für die zentrale MySQL-Datenbank auf dem Root-Server beim Provider. Um die beiden Maschinen auszuwerten, ohne die Daten darauf zu verändern, musste eine Virtualisierung herhalten.

Dafür eignet sich am besten ein leistungsfähiger Linux-Rechner wie ihn der Kasten “Der ideale Gastgeber” beschreibt. Auf dem Server, einer handelsüblichen Pizzabox, wie sie Internet Service Provider massenhaft einsetzen, fanden die Ermittler drei Festplatten (Listing 1). Dabei fiel ihnen vor allem die winzige IDE-Disk mit einer Kapazität von nur 2 GByte auf. Erst der Blick unter die Haube lüftete das Geheimnis (Abbildung 1).

F Abbildung 1: Ein gerade mal 2 GByte großes Transcend-Flash-Modul steckt auf dem IDE-Port und beinhaltet das Betriebssystem. Auch die Konfiguration des Raid-Verbunds findet sich hier.

2-GByte-Linux

Es handelt sich um ein Flash-Modul [3], auf dem das Betriebssystem installiert ist. Die beiden SATA-Festplatten vorne laufen als Software-Raid-1-Verbund (Abbildung 2). Für die erfolgreiche Virtualisierung braucht es daher Abbilder aller drei Speichermedien. Mit KVM startet dann die Betriebssystem-Festplatte »/dev/hda« und bindet »hdc« und »hdd« im Raid-1-Verbund automatisch ein:

kvm -m 2048 -hda hda.dd -hdc hdc.dd -hdd hdd.dd 

Dank der 8 GByte Arbeitsspeicher im Host fällt es dabei leicht, 2 GByte RAM an den Gast abzutreten. Jetzt bootet der Server bereits bis zum Login-Prompt. Den Forensikern, die am Rechner eines Fremden arbeiten, fehlt aber noch das Root-Passwort, deshalb ist auch noch kein Login möglich. Daher erstellen sie zuerst eine Kopie des Flash-Moduls, mounten es und deaktivieren in »/etc/passwd« das Root-Passwort. Das modifizierte Image dient dann als Bootfestplatte »/dev/hda«.

F Abbildung 1: Ein gerade mal 2 GByte großes Transcend-Flash-Modul steckt auf dem IDE-Port und beinhaltet das Betriebssystem. Auch die Konfiguration des Raid-Verbunds findet sich hier.

Mit EWF und Xmount

Viele Forensiker bevorzugen das Expert Witness Format (EWF, [4]) auch wegen der effizienten Komprimierung. Das in [1] vorgestellte Xmount erledigt das über Overlays, ohne dabei das Image zu verändern:

xmount --in ewf --out dd --cache hda.ovl hda.E?? ~/mnt1 
xmount --in ewf --out dd --cache hdc.ovl hdc.E?? ~/mnt2 
xmount --in ewf --out dd --cache hdd.ovl hdd.E?? ~/mnt3 
kvm -m 2048 -hda ~/mnt1/hda.dd -hdc ~/mnt2/hdc.dd ~/mnt3/hdd.dd 

Wie zuvor bootet KVM von Debian auf »/dev/hda« und bindet das Softraid als »/dev/md0« ein, das auf »/var/lib/mysql« gemountet ist und die Datenbanken enthält. Wer hier noch Netzwerksupport braucht, übergibt KVM die Parameter »-net nic -net tap«, um dann im Bridged-Modus zu arbeiten.

Suse-Distributionen prüfen beim Bootvorgang die MAC-Adresse des physikalischen Systems. Die unterscheidet sich allerdings zwangsläufig von der der virtuellen Netzwerkkarte. Wenn das System an dieser Stelle hängen bleibt, notiert der Admin die von Suse beanstandete MAC-Adresse und übergibt sie mit dem Parameter »-net nic,macaddr=MAC-Adresse -net tap« an KVM. Dann steht dem erfolgreichen Boot nichts mehr im Weg.

Ein harter Weg

Es ist immer wieder erstaunlich, wie wenige Befehle mit Virtualisierung notwendig sind, um komplette Server mit komplizierten Raid-Systemen in den Griff zu bekommen. Die manuelle Aufbereitung macht da deutlich mehr Aufwand. Der klassische Weg, das Mounten mit Offset [6] und den Daten aus Listing 1 funktioniert hier nicht:

losetup -o $((63*512)) /dev/loop0 hdc1.dd
mount /dev/loop0  /mnt
(...)
mount: unknown filesystem type 'linux_raid_member' 

Tools wie »losetup« und »mdadm« müssen das Raid-System zunächst rekonstruieren. Wie das geht, zeigt der Kasten “Raid manuell zusammenbauen”.

01 Disk hda: 2 GB, x bytes
02 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
03 Units = sectors of 1 * 512 = 512 bytes
04 Disk identifier: 0x000f12af
05 Device Boot      Start         End      Blocks   Id  System
06 hda1                63     3711014     1855476   83  Linux
07 hda2           3711015     4112639      200812+  82  Linux swap / Solaris
08 
09 Disk sda: 160 GB, x bytes
10 15 heads, 63 sectors/track, 0 cylinders, total 0 sectors
11 Units = sectors of 1 * 512 = 512 bytes
12 Disk identifier: 0x00000000
13 Device Boot  Start      End    Blocks  Id  System
14 sda1         63    12594959  6297448+  fd  Linux raid autodetect
15 Partition 1 has different physical/logical endings:
16      phys=(1023, 14, 63) logical=(13327, 14, 63)
17 
18 Disk sdb: 160 GB x bytes
19 15 heads, 63 sectors/track, 0 cylinders, total 0 sectors
20 Units = sectors of 1 * 512 = 512 bytes
21 Disk identifier: 0x00000000
22 Device Boot  Start      End    Blocks  Id  System
23 sdb1         63    12594959  6297448+  fd  Linux raid autodetect
24 Partition 1 has different physical/logical endings:
25      phys=(1023, 14, 63) logical=(13327, 14, 63)

Der Windows-Client

Dagegen reicht es nicht aus, einfach das kopierte Image in einer Virtualisierung zu starten, wenn es sich um Windows handelt. Der Gast befindet sich nicht mehr in der gewohnten Hardware-Umgebung, sondern in einem völlig neuen, virtuellen Umfeld, und da kommen Microsofts Hardware-Überprüfung und die Kopierschutzmaßnahmen in die Quere.

Windows sucht beim Start die registrierte Hardware, findet sie nicht und belohnt den Benutzer mit einem Bluescreen, weil passende IDE-, AGP- und vielleicht noch andere Treiber fehlen. Plug&Play tauscht zwar beispielsweise Soundkarten aus, bis dahin kommt der virtuelle Boot aber meist gar nicht.

Virtualisierungen wie VMware (mit Live View) oder Virtualbox treffen hier eigene Vorkehrungen. Dennoch ist der erste virtuelle Boot immer wieder eine spannende Angelegenheit. Gillen Daniels Opengates [1] dagegen tauscht beim Boot problematische Treiber aus und setzt auf Wunsch Login-Daten zurück, damit zum Beispiel Ermittler auch ohne Anmeldeinformationen ins Betriebssystem gelangen.

#losetup -o $((63*512)) /dev/loop0 hdc.dd
#losetup -o $((63*512)) /dev/loop1 hdd.dd
#mdadm -C /dev/md0 -l 1 -n 2  /dev/loop0 /dev/loop1

#mdadm -C /dev/md0 -l 1 -n 2  missing /dev/loop0

#mount -o ro,noatime /dev/md0 /mnt
#cd /mnt
#ls -al
insgesamt 20540
drwx------ 2 statd polkituser     4096 11. Sep 02:11 company_data
-rw-r--r-- 1 root  root              0 11. Sep 02:04 debian-5.1.flag
-rw-rw---- 1 statd polkituser 10485760 11. Sep 12:49 ibdata1
-rw-rw---- 1 statd polkituser  5242880 11. Sep 17:54 ib_logfile0
-rw-rw---- 1 statd polkituser  5242880 11. Sep 02:04 ib_logfile1
drwxr-xr-x 2 statd root           4096 11. Sep 02:05 mysql
-rw------- 1 root  root              6 11. Sep 02:05 mysql_upgrade_info
drwx------ 2 statd polkituser     4096 11. Sep 02:05 phpmyadmin

#umount /mnt
#mdadm - - stop /dev/md0
#losetup -d /dev/loop0
#losetup -d /dev/loop1

Türöffner Bart PE

Am einfachsten ist es, Opengates in eine Windows-Boot-CD wie Bart PE [5] zu integrieren. Wie das geht, beschreibt die Datei »README.TXT« im Opengates-Archiv ausführlich. Dann bootet der Admin beim virtuellen Start nicht mehr das Festplattenimage, sondern die Bart-CD, die wiederum Opengates startet (Abbildungen 3 und 4).

Abbildung 3: Opengates während des Bootvorgangs …

Abbildung 4: … und nach vollendeter Arbeit.

Für den Forensiker wichtig: Der Treiberaustausch findet auf Wunsch nicht im Festplattenabbild statt, sondern in einer beschreibbaren Overlay-Datei. Das Originalimage bleibt unangetastet:

kvm -m 1024 -net nic -net tap -cdrom bartcd.iso -boot d /mnt/imagefile.dd 

Hat Opengates seine Aufgaben erfolgreich erledigt, wird die Virtualisierung nochmals gestartet, diesmal ohne CD. Jetzt bootet KVM das Abbild mit Netzwerk und 1 GByte RAM. Abbildung 4 zeigt das Windows-System unter KVM, nachdem der Admin die “Tore geöffnet” hat. Auch wenn das Tool eher unbekannt ist, haben Virtualisierungen mit seiner Hilfe die Stabilität von Live View erreicht, wenn nicht gar übertroffen.