Linux-Magazin_-_Januar_2019

sowie persistenten Speicher, den sie als

Blockgerät einbinden und der oft von

einer Lösung wie Ceph kommt. Hat der

Admin nun also die Aufgabe, forensische

Maßnahmen in einer Cloud durchzufüh-

ren, findet er idealerweise zunächst he-

raus, um welche Art von Speicher es

sich bei dem betroffenen System handelt.

Allerdings kommt es auch vor, dass eine

VM beide Arten von Speicher miteinan-

der kombiniert.

Bei einem Angriff ist es zunächst wich-

tig, möglichst schnell zu reagieren und

die betroffene virtuelle Maschine abzu-

schalten. Abschalten ist nicht dasselbe

wie Löschen; im Eifer des Gefechts nutzt

mancher Admin aus Versehen den fal-

schen Befehl und befördert das gesamte

System ins Nirwana.

Allzu sanft sollte der Anhalte-Vorgang

aber auch nicht sein. Schickt der Admin

der virtuellen Maschine per ACPI ein Po-

wer-Off, hat eine pfiffig programmierte

Schadsoftware auf dem System noch ein

paar Sekunden Zeit, um sich zu löschen

und vorher ihre Spuren zu verwischen.

Force Shutdown heißt die benötigte

Funktion etwa bei Open Stack.

Ist die virtuelle Maschine erfolgreich

gestoppt, geht die eigentliche forensi-

sche Untersuchung los. Zunächst findet

der Admin heraus, auf welchem Host

in der Cloud eine spezifische virtuelle

Maschine gelaufen ist. Das geht etwa bei

Open Stack mit dem Befehl »nova show«

auf die ID der VM, allerdings ist es dazu

notwendig, dass der Nutzer die Rechte

von »admin« beziehungsweise der gleich-

namigen Rolle hat.

Dann folgt ein Login auf eben jenem Sys-

tem. Hatte die VM nur flüchtigen, also

Ephemeral-Speicher, navigiert der Admin

im Beispiel von KVM in das Verzeichnis

»/var/ lib/ nova/ instances« – hier liegen

die Qcow-Abbilder der auf dem Host an-

gelegten virtuellen Maschinen. Kommt

eine andere Lösung oder auch nur ein

anderer Hypervisor zum Einsatz, ist der

Pfad zur Datei ein anderer. Die Dokumen-

tation der jeweiligen Lösung enthält dazu

entsprechende Infos.

Daten wegkopieren

Es empfiehlt sich, das Qcow-Abbild auf

einen Host außerhalb der Cloud zu über-

tragen, um dort die Untersuchung durch-

meist im Ceph-Pool »rbd« (Abbildungen

4 und 5 ) und hat als Namen zuverlässig

die ID des Volume in Open Stack – also

eine UUID. Es lässt sich grundsätzlich

auf jedem System, auf dem »rbd.ko« im

Kernel geladen ist und die Ceph-Werk-

zeuge installiert sind, lokal am System

anmelden.

Dann kopiert es der Admin schlauerweise

mit »dd« oder anderen Werkzeugen aus

dem Cluster, je nach Größe etwa auf

einen USB-Stick. Dort lässt das Abbild

des Datenträgers sich anschließend so

verwenden, wie es bei einem normalen

Blockgerät auch der Fall wäre.

Übrigens: Beim Arbeiten mit Volumes er-

geben sich für Endanwender Möglichkei-

ten, die bei Qcow-Abbildern fehlen. Denn

an die Qcow-Abbilder auf den einzelnen

Systemen kommen die Kunden nicht he-

ran, wenn die VM nicht läuft. Genau dies

ist aber zu verhindern. Ein Open-Stack-

Volume hingegen kann der Nutzer von

einer laufenden VM abkoppeln und an

eine andere, frische VM direkt anschlie-

ßen – schon lässt es sich entsprechend

untersuchen. Wer die Forensik jedoch

außerhalb der Cloudumgebung durch-

führen möchte, erledigt das sicher über

den Umweg per Host am schnellsten.

Forensik as a Service

Offensichtlich bieten sich mit Zugriff auf

die Physik mehr Optionen, was das De-

bugging und die Forensik nach einem

Einbruch angeht. Anders als die Bran-

chenriesen wie AWS oder Azure kön-

nen kleine Unternehmen ihren Kunden

an dieser Stelle einen echten Mehrwert

bieten, indem sie sie bei der Forensik

unterstützen.

Denkbar wäre etwa, dass sie ihm den

Inhalt eines Rbd-Volume als Datei zur

Verfügung stellen, damit er debuggen

kann. Das Gleiche gilt für Qcow-Abbilder,

an die der Kunde andernfalls gar nicht

herankäme. Ein solcher Service sollte

wenigstens so bepreist sein, dass er den

Aufwand ausgleicht; er wäre aber eine

echte Hilfe. (jcb) n

Infos

[1] Trove-SSH-Schlüssel:

[http:// git. openstack. org/ cgit/ openstack/

trove/ tree/ integration/ scripts/ files/ keys]

zuführen. So lässt es sich nach dem Ko-

pieren mounten: Der Befehl »modprobe

nbd max_part=8« lädt das NBD-Kernel-

modul in den Linux-Kernel. »qemu-nbd

--connect=/dev/nbd0 Datei.qcow« emu-

liert das Qcow-Abbild als Blockgerät und

»mount /dev/nbd0p1 /mnt« hängt das

Gerät ins lokale Dateisystem ein. Um das

Qemu-Abbild später zu deaktivieren, ist

der Befehl »umount /mnt« gefolgt von

»qemu-nbd --disconnet /dev/nbd0« der

richtige (Abbildung 3).

Wenn das Qcow-Abbild auf die gezeigte

Weise eingehängt ist, lässt es sich wie

jedes andere Dateisystem auch verwen-

den. Dann greifen alle regulären Foren-

sik-Tipps der physischen Welt.

Volumes untersuchen

Etwas anders liegt die Sache, wenn es

nicht um ein zu untersuchendes Abbild

von Ephemeral-Speicher geht, sondern

um den Inhalt eines Volume. Volumes

sind in Clouds meist virtuell: Sie sind die

logische Abbildung etwa einer bestimm-

ten Menge binärer Objekte in Ceph. Es

gibt nicht den einzelnen physischen Da-

tenträger, der das Storage-Volume reprä-

sentiert. Aus der Sicht des Anbieters kann

das zum großen Problem werden: Wedelt

die Polizei mit einem Durchsuchungsbe-

fehl, will sie die betroffenen Daten garan-

tiert mitnehmen.

Im schlimmsten Falle würde das heißen,

den gesamten Ceph-Cluster abzubauen.

Eingedenk des Übereifers mancher Straf-

verfolgungsbehörde sind solche Situatio-

nen jedenfalls nicht auszuschließen. Wer

darauf keine Lust hat, sollte deshalb gut

vorbereitet sein und wenigstens wissen,

wo er die Daten findet.

Bei Ceph geht das etwa so: Zunächst

findet der Admin heraus, wo die Daten

denn in Ceph liegen, also auf welchem

Rbd-Gerät. Ist Ceph im Tandem mit Open

Stack unterwegs, liegt das Rbd-Volume

Titelthema

50

http://www.linux-magazin.de

Cloud-Forensik

Abbildung 5: Innerhalb des Rbd­Pools in Ceph lagern

üblicherweise die Volumes, die Cinder anlegt.