Linux-Magazin_-_Januar_2019

in die VM selbst erfolgt, hilft Endkunden

nur der Weg über SSH.

Der vorgestellte Prozess bezieht sich üb-

rigens spezifisch auf Trove, also DBaaS in

Open Stack. Forensische Untersuchungen

im Hinblick auf andere Dienste bedin-

gen möglicherweise andere Debugging-

Ansätze – die hier aber nicht erschöpfend

zu beschreiben sind. Im Falle eines Falles

hilft nur, die Dokumentation der von ei-

nem Einbruch betroffenen Komponente

wälzen und herausfinden, wie man sich

zur laufenden Instanz Zugang verschafft.

Selbermachen

Alternativ dazu ist die Option, weniger

auf AaS zu setzen und die jeweiligen

Dienste effektiv selbst zu betreiben. Denn

das kann sich durchaus lohnen. Auch

wenn mancher Admin den Komfort von

AaS-Diensten schätzen gelernt hat – sie

sind nun mal eine Gratwanderung zwi-

schen Komfort auf der einen Seite und

Kontrollverlust auf der anderen.

Wer seine Datenbank lieber wie beschrie-

ben klassisch nach dem IaaS-Konzept

selbst betreibt, bekommt allerdings im

Gegenzug auch ein paar Vorteile gebo-

ten. Weil VMs mit Maria DB & Co. dann

erst einmal ganz normale Linux-Systeme

sind, stehen hier auch alle Hardening-

Maßnahmen zur Verfügung, die gewöhn-

liche Linux-Systeme kennen. Firewalls

lassen sich auf der Instanzen-Ebene wie

auf der Open-Stack-Ebene konfigurieren,

und zusätzliche Sicherungsmaßnahmen

sind auf der System- wie auch der Daten-

bank-Ebene nutzbar.

Wer sich für diesen Weg entscheidet,

übernimmt also ein Stück weit wieder die

Kontrolle über sein Setup und bekommt

im Gegenzug bessere Möglichkeiten für

ausgefeilte Forensik.

Schnell wieder online sein

Im Hinblick auf einen Aspekt unterschei-

det sich die Cloud übrigens positiv von

konventionellen Setups. In klassischen

Umgebungen ist es nämlich völlig un-

möglich, die Wiederanlaufzeit von gut

konstruierten virtuellen Umgebungen

in Clouds zu erreichen. Wer eine solche

Umgebung schlau baut, setzt verstärkt

auf Automatisierung und Orchestrie-

rung: Relevant sind quasi nur tatsächli-

che Nutzdaten, alles andere kommt aus

der Dose und lässt sich aus dieser auch

wieder schnell herbeizaubern.

Und weil das Handling von IP-Adressen

in Clouds auch gut gelöst ist, bleibt der

eigentlich Aufwand überschaubar: Es

genügt, das alte Setup vom Netz zu neh-

men, per Orchestrierung das neue Setup

zu starten und diesem die alte IP-Adresse

zuzuweisen.

Freilich sollte der Admin das aber nur

tun, wenn er weiß, warum das Setup

zuvor kompromittiert worden ist. Die

Plattform mit demselben Problem, das

zum Einbruch geführt hat, wieder online

zu bringen, wäre keine gute Idee.

Forensik aus Sicht des

Anbieters

Sinn und Zweck des Daseins als Cloudan-

bieter ist es, so wenig Arbeit wie möglich

zu haben. Das ist grundsätzlich durch

Automation zu erreichen – doch gibt es

Ausnahmefälle, in denen es keine Op-

tion ist, sich nicht zu kümmern. Denn

der Angriffsvektor in einer Cloud ist in

vielerlei Hinsicht viel größer als jener in

klassischen Setups.

Macht ein konventioneller Angreifer eine

Installation auf, so genügt es, die Hard-

ware außer Betrieb zu stellen oder den

Netzwerkzugriff zu kappen. Das geht in

Clouds aber beides nicht. Meistens je-

denfalls haben Kunden keine dedizierte

Hardware, und schaltet der Anbieter das

Netzwerk ab, betrifft das auch alle an-

deren Nutzer der Cloud. Hier muss ein

anderer Ansatz her.

Das gilt umso mehr, als sich ein Angreifer

innerhalb einer virtuellen Umgebung po-

tenziell wie ein Krebsgeschwür ausbrei-

ten kann, wenn er passende Schwach-

stellen vorfindet. Alle Cloudumgebungen

machen zwar viele Klimmzüge, um die

Trennung der einzelnen Kunden – Te-

nants – in der Cloud zuverlässig zu ge-

währleisten. Dabei gelten allerdings ein

paar Grundannahmen, etwa dass die Bar-

riere zwischen VM und Host hält. Gelingt

es aber einem Angreifer, einer VM zu ent-

vorgesehen und deshalb auch ohne ext-

reme Klimmzüge nicht erfolgreich. Zwar

verspricht Amazon, dass das auch nicht

nötig sei, weil es mit den verschiedenen

Werkzeugen leicht sei, DBaaS-Instanzen

zu warten. Aber auf solche Versprechun-

gen sollte sich der Anwender nicht voll-

ends verlassen.

Im konkreten Beispiel gibt es daher auch

nicht allzu viele Dinge, die ein Kunde tun

kann. Das sieht bei Open Stack anders

aus, denn hier tauchen die durch AaS-

Dienste gestarteten Instanzen wenigstens

noch als virtuelle Maschinen auf, die er

tatsächlich bearbeiten kann.

Mehr Zugriffsmöglichkeiten

bei Open Stack

Die für Trove vorbereiteten Images ent-

halten für den SSH-Login einen Standard-

SSH-Schlüssel, dessen privates Gegen-

stück im offiziellen Trove-Verzeichnis

liegt [1]. Hat der Admin die Trove-VM

identifiziert – das geht etwa per »trove

show Name« auf der Kommandozeile

oder über die Liste der laufenden VMs

im Dashboard –, kann er sich mit jenem

privaten Schlüssel als Benutzer »ubuntu«

am Trove-Image anmelden.

Bevor die Leser, die sich von Berufs we-

gen mit Sicherheit befassen, in Ohnmacht

fallen: Trove schirmt DBaaS-Instanzen so

ab, dass der Login aus dem Internet per

SSH nicht möglich ist. Da geht nur aus

dem lokalen Netzwerk, also aus dem vir-

tuellen Cloudnetz.

Zwar ist die Idee, eine gehackte VM

im laufenden Betrieb zu untersuchen,

nicht der beste Ansatz – wer aber wissen

möchte, wie es zum Einbruch in eine

Trove-Instanz gekommen ist, hat oft nur

diesen Weg. Denn ein anderer Trick funk-

tioniert nicht: Trove legt für Datenbank-

VMs zwar auch persistente Volumes an,

auf denen liegt aber nicht die gesamte

virtuelle Maschine, sie speichern nur die

Daten der Datenbank. Möchte der Admin

nachvollziehen, inwiefern Angreifer die

Datenbank bearbeitet haben, ist das pro-

blemlos möglich. Ist der Einbruch aber

Titelthema

48

http://www.linux-magazin.de

Cloud-Forensik

Abbildung 3: Wer den Inhalt einer Qcow­Datei eingehend betrachten möchte, tut das mit Qemu­Werkzeugen.