© belchonock, 123RF

Die Spurensuche nach einem Einbruch auf physischen Systemen ist Fleißarbeit, und das ist auch in der Cloud nicht anders. Nur dass hier besondere Effekte die Arbeit noch deutlich verkomplizieren.

Von den Cloud-Apologeten, die landauf, landab die frohe Botschaft von “Everything as a Service” und “Serverless Computing” verbreiten, ist bekannt, dass ihre Lösungen auf dem Papier zwar oft hervorragend aussehen, doch im Alltag nicht selten Probleme bereiten, deren Lösung gar nicht so leicht zu finden ist.

Auch bei der Frage, wie man nach einem Einbruch vorgeht, ergeben sich im Cloudkontext spezielle Fragen. Denn während der Admin in einer klassischen Umgebung die betroffenen Systeme üblicherweise sofort vom Strom trennt und die vorhandenen Datenträger sorgfältig prüft, ist in der Cloud alles virtuell – vom System, in dem ein Dienst läuft, bis zum Volume, auf dem er Daten ablegt. Mehr noch: Wer sich für die Nutzung von As-a-Service-Angeboten entscheidet, gibt noch mehr Kontrolle ab und kommt oft noch nicht einmal an die Systeme heran, auf denen seine Dienste laufen.

Was können Anwender in einer Cloud überhaupt nach einem Angriff tun? Gibt es bei klassischen AaS-Angeboten forensische Maßnahmen? Und wie sieht die Sache aus Sicht des Admin aus? Wie reagiert er im Falle eines Falles und wie kann er Kunden beim Thema Forensik unterstützen?

Wenige Optionen

Die Idee hinter Everything as a Service und Serverless Computing ist ja schnell durchschaut: ISPs werden zu Plattformanbietern mit standardisierter Produktpalette und festen Preisen. Kunden suchen sich aus, wie viel Verantwortung sie an den Anbieter abtreten wollen, indem sie wahlweise IaaS oder ein anderes Modell wie PaaS verwenden.

Die AaS-Angebote vieler Unternehmen unterscheiden sich in erster Linie im Maß an Verantwortung, das ein Kunde in der Cloud noch zu übernehmen bereit ist. Je weiter er in den As-a-Service-Bereich vordringt, desto einfacher wird die Wartung eines Setups – aber desto seltener werden auch die Schrauben, an denen der Kunde selbst noch drehen kann. Und das hat handfeste Konsequenzen.

Denn aus Kundensicht ist ein Einbruch in ein virtuelles Setup, das stark auf AaS-Dienste setzt, eine mittelgroße Katastrophe. Um zu verstehen, warum das so ist, ist ein kleiner Ausflug in die Technik nötig, die AaS-Dienste in der Regel antreibt.

Open Stack als Versuchsobjekt

Open Stack eignet sich zur Verdeutlichung des technischen Konzeptes sehr gut, weil es einerseits Open-Source-Software ist und andererseits auch die Open Stack zugrunde liegenden Standards öffentlich und gut dokumentiert sind. Am Anfang steht die Frage: Was ist eigentlich die Motivation hinter As-a-Service-Diensten?

Zunächst geht es Kunden darum, weniger Wartungsarbeit zu haben. Geht man von der Anforderung “Ich brauche eine funktionierende Maria-DB-Datenbank” aus, gibt es ja grundsätzlich mehrere Wege, dieses Ziel zu erreichen. Die ganz klassische Variante wäre, eine virtuelle Maschine auf Linux-Basis zu starten und darin Maria DB zu installieren. Dann hinterlegt der Admin für die DB noch eine Konfiguration, erstellt Benutzerzugänge und schlägt sich mit der Syntax des SQL-Befehls »GRANT« herum, um Zugriffsrechte zu verteilen. Am Ende steht eine lauffähige Datenbank, deren Zugangsdaten er dann noch in seine Applikation einträgt – fertig ist der Lack.

Die Wartungsarbeiten, die ein solches Setup hervorruft, sind allerdings beachtlich: Regelmäßige Updates in Sachen Security stehen ebenso wie Major Upgrades an. Auch Monitoring ist ein Thema, und eigentlich muss man ein solches Setup ja auch mit einem Hochverfügbarkeitskonzept verbinden, zum Beispiel mit Galera, was jedoch den Wartungsaufwand kurzerhand verdreifacht. (Wer alternativ auf Pacemaker setzt, wird schnell feststellen, dass das keine so gute Idee ist.)

Die Idee hinter As-a-Service-Angeboten ist, all diese Schritte aus dem Pflichtenheft des Kunden-Admin zu entfernen. Dafür bietet der Cloudprovider eine API-Schnittstelle an, die im Hinblick auf Datenbanken ähnlich arbeitet wie ein Automat: Der Kunde gibt nur an, welchen Datenbanktyp er benötigt (Abbildung 1) und wie die Datenbank erreichbar sein soll – wenig später bekommt er die IP-Adresse sowie die nötigen Benutzerdaten angezeigt, und schon steht die Datenbank zur Nutzung parat.

Abbildung 1: Wer Dienste wie DBaaS (hier am Beispiel Open Stack) verwendet, der gibt einen großen Teil der Kontrolle auf.

Das Hinzufügen neuer Benutzer erledigt der Kunde ebenso per Cloud-API wie das Feintuning der Datenbank – falls gewünscht. Die Methode hat einen unschlagbaren Vorteil: Sie ist aus Kundensicht agnostisch im Hinblick auf die genutzte Datenbank: Die API-Befehle zum Anlegen von Benutzern (Abbildung 2) unterscheiden etwa zwischen PostgreSQL, Mongo DB und Maria DB nicht.

Abbildung 2: Zwar sind Ansätze wie DBaaS bequem und komfortabel, allerdings machen sie Vorgänge – etwa Forensik – viel komplexer.

Unter der Haube viel Aufwand

Damit dieser Ablauf funktioniert, erledigt die in der Cloud verantwortliche Komponente im Hintergrund eine ganze Reihe von Arbeiten, die den Augen des Nutzers gewollt verborgen bleiben. Denn natürlich ist auch eine als DBaaS gestartete Datenbank ein normales Maria DB oder PostgreSQL, das in einer virtuellen Maschine läuft. Die DBaaS-Komponente nimmt dem Admin aber die vielen Integrationsschritte ab.

Bevor Trove in Open Stack etwa eine DBaaS startet, legt es ein persistentes Blockgerät an, auf dem die Daten der DB später zu speichern sind. Dann startet Trove eine ganz normale VM-Instanz über Nova, das für die Verwaltung von virtuellen Maschinen verantwortlich ist. Dafür nutzt es allerdings nicht die Standard-Betriebssystemabbilder, die für reguläre VMs von Kunden zum Einsatz kommen.

Stattdessen setzt Trove auf eigene Images, die explizit für Trove vorbereitet sind und einen Agenten mit an Bord haben. Dieser verbindet sich mit der Metadaten-Komponente von Nova, wo die zuvor vom Nutzer hinterlegten Konfigurationswerte gespeichert sind, und liest sie aus. Danach bereitet es die frische VM vor, indem es das persistente Volume einhängt, die Datenbank entsprechend konfiguriert und schließlich startet. Im Grunde ist Trove also nichts anderes als eine Automatisierungslösung für den Betrieb von Datenbanken in Open Stack, die auf vorhandene Infrastruktur setzt und gegebene Funktionen nutzt.

Ähnlich verhält es sich mit anderen Angeboten aus dem AaS-Dunstkreis: Monitoring-as-a-Service etwa, das Open Stack über seine Komponente Monasca realisiert, funktioniert ganz ähnlich. Am Ende geht es bei AaS-Diensten stets darum, Komplexität vor dem Nutzer zu verbergen und sie möglichst effizient wegzuautomatisieren. Das senkt für den Kunden nämlich die Einstiegshürde und steigert die Effektivität der Umgebung enorm.

Nur wenige Zugriffsmöglichkeiten

Die Medaille hat freilich auch eine Kehrseite. Denn je unselbstständiger der Kunde ist, desto weniger Möglichkeiten hat er auch, im Falle des Falles genauer hinzusehen und selbst zu handeln. Wobei das Level an Abschirmung sich hier durchaus zwischen verschiedenen Cloudanbietern unterscheidet.

Klickt sich der Admin etwa bei Amazon eine DBaaS-Instanz, erscheint es nahezu unmöglich, irgendwie an die unter der Datenbank existierende VM heranzukommen. Das ist im Konzept einfach nicht vorgesehen und deshalb auch ohne extreme 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 Versprechungen sollte sich der Anwender nicht vollends 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 enthalten für den SSH-Login einen Standard-SSH-Schlüssel, dessen privates Gegenstü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 wegen 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 virtuellen 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 funktioniert 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 problemlos möglich. Ist der Einbruch aber in die VM selbst erfolgt, hilft Endkunden nur der Weg über SSH.

Der vorgestellte Prozess bezieht sich übrigens spezifisch auf Trove, also DBaaS in Open Stack. Forensische Untersuchungen im Hinblick auf andere Dienste bedingen 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 einem 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 zwischen Komfort auf der einen Seite und Kontrollverlust auf der anderen.

Wer seine Datenbank lieber wie beschrieben klassisch nach dem IaaS-Konzept selbst betreibt, bekommt allerdings im Gegenzug auch ein paar Vorteile geboten. 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öhnliche 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 Datenbank-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 unterscheidet sich die Cloud übrigens positiv von konventionellen Setups. In klassischen Umgebungen ist es nämlich völlig unmöglich, die Wiederanlaufzeit von gut konstruierten virtuellen Umgebungen in Clouds zu erreichen. Wer eine solche Umgebung schlau baut, setzt verstärkt auf Automatisierung und Orchestrierung: Relevant sind quasi nur tatsächliche 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 nehmen, 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 Cloudanbieter 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 Option 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 Hardware außer Betrieb zu stellen oder den Netzwerkzugriff zu kappen. Das geht in Clouds aber beides nicht. Meistens jedenfalls haben Kunden keine dedizierte Hardware, und schaltet der Anbieter das Netzwerk ab, betrifft das auch alle anderen Nutzer der Cloud. Hier muss ein anderer Ansatz her.

Das gilt umso mehr, als sich ein Angreifer innerhalb einer virtuellen Umgebung potenziell wie ein Krebsgeschwür ausbreiten kann, wenn er passende Schwachstellen vorfindet. Alle Cloudumgebungen machen zwar viele Klimmzüge, um die Trennung der einzelnen Kunden – Tenants – in der Cloud zuverlässig zu gewährleisten. Dabei gelten allerdings ein paar Grundannahmen, etwa dass die Barriere zwischen VM und Host hält. Gelingt es aber einem Angreifer, einer VM zu entfleuchen und Zugriff auf den physischen Host zu erlangen, ist das schon eine Katastrophe.

Gehören zur virtuellen Umgebung, in der der Einbruch stattgefunden hat, viele VMs, die sich auf viele Systeme verteilen, ist das der Super-GAU: Dann nämlich kann der Angreifer viele Systeme innerhalb der Umgebung auf dieselbe Art und Weise infiltrieren und andere virtuelle Setups ebenfalls kompromittieren.

Der wichtigste Faktor aus Admin-Sicht ist es deshalb, möglichst frühzeitig zu bemerken, wenn etwas nicht so ist, wie es sein sollte. Je kleiner er den Schaden hält, desto weniger forensische Arbeit ist anschließend notwendig.

MAT und zentralisiertes Logging

Unerlässliche Werkzeuge für funktionale Forensik-Ansätze sind Systeme für Monitoring, Alerting und Trending (MAT) sowie ein zentralisiertes Logging. MAT lässt sich etwa mit Influx DB oder Prometheus erreichen und verschafft dem Admin einen klaren zeitlichen Vorteil in allen Fällen, in denen ein System in der Cloud – also einer virtuellen Maschine – angegriffen worden ist und der Angriff das physische System oder andere Teile der Cloud beeinträchtigt. Hat sich etwa per WordPress-Installation ein Wurm eingenistet, der Bitcoins berechnet oder Spam verschickt, ist das möglicherweise am erhöhten Traffic auf dem physischen System zu erkennen. Hier spielt freilich auch das Angriffsszenario eine Rolle, denn je besser ein Angriff ist, desto schwieriger ist er erkennbar.

Aus ähnlichen Überlegungen heraus ist auch zentralisiertes Logging äußerst hilfreich für forensische Zwecke, denn es lässt in vielen Fällen erkennen, wann eine Attacke begann. Das funktioniert selbst dann, wenn das Zielsystem in einer Weise angegriffen worden ist, die die dortigen, lokalen Logs verändert hat.

Mehr Möglichkeiten

Anders als Kunden, die Clouddienstleistungen konsumieren, haben Anbieter bei forensischen Maßnahmen mehr Möglichkeiten, weil sie Zugriff auf das physische System und notfalls auch auf die Hardware haben. Zur Erinnerung: Cloud-VMs kennen üblicherweise zwei Arten von Storage, nämlich den flüchtigen Speicher auf den Platten der physischen Systeme 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ühren, findet er idealerweise zunächst heraus, um welche Art von Speicher es sich bei dem betroffenen System handelt. Allerdings kommt es auch vor, dass eine VM beide Arten von Speicher miteinander kombiniert.

Bei einem Angriff ist es zunächst wichtig, möglichst schnell zu reagieren und die betroffene virtuelle Maschine abzuschalten. Abschalten ist nicht dasselbe wie Löschen; im Eifer des Gefechts nutzt mancher Admin aus Versehen den falschen 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 Power-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 forensische 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 gleichnamigen Rolle hat.

Dann folgt ein Login auf eben jenem System. 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 angelegten virtuellen Maschinen. Kommt eine andere Lösung oder auch nur ein anderer Hypervisor zum Einsatz, ist der Pfad zur Datei ein anderer. Die Dokumentation 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 übertragen, um dort die Untersuchung durchzuführen. So lässt es sich nach dem Kopieren mounten: Der Befehl »modprobe nbd max_part=8« lädt das NBD-Kernelmodul in den Linux-Kernel. »qemu-nbd –connect=/dev/nbd0 Datei.qcow« emuliert 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).

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

Wenn das Qcow-Abbild auf die gezeigte Weise eingehängt ist, lässt es sich wie jedes andere Dateisystem auch verwenden. Dann greifen alle regulären Forensik-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 bestimmten Menge binärer Objekte in Ceph. Es gibt nicht den einzelnen physischen Datenträger, der das Storage-Volume repräsentiert. Aus der Sicht des Anbieters kann das zum großen Problem werden: Wedelt die Polizei mit einem Durchsuchungsbefehl, will sie die betroffenen Daten garantiert mitnehmen.

Im schlimmsten Falle würde das heißen, den gesamten Ceph-Cluster abzubauen. Eingedenk des Übereifers mancher Strafverfolgungsbehörde sind solche Situationen 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 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-Werkzeuge installiert sind, lokal am System anmelden.

Abbildung 4: Open Stack und Ceph können hervorragend miteinander – so bindet ein KVM-Compute-Knoten RBD-Laufwerke ein.

Abbildung 5: Innerhalb des Rbd-Pools in Ceph lagern üblicherweise die Volumes, die Cinder anlegt.

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 ergeben sich für Endanwender Möglichkeiten, die bei Qcow-Abbildern fehlen. Denn an die Qcow-Abbilder auf den einzelnen Systemen kommen die Kunden nicht heran, 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 durchfü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 Debugging und die Forensik nach einem Einbruch angeht. Anders als die Branchenriesen wie AWS oder Azure können 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.