© aleksanderdn, 123RF

Forscher untersuchen, wie sich Hackerangriffe schnell erkennen und erfolgreich abwehren lassen und wie Admins Spuren sichern können, die später bei einer juristischen Ahndung helfen. Trotzdem soll die Privatsphäre der Anwender aber geschützt bleiben.

Das Projekt Explicit Privacy-Preserving Host Intrusion Detection System (Exploids, [1]) will die Sicherheit von virtuellen Maschinen in Rechenzentren und Cloudumgebungen erhöhen, indem es dabei hilft, Angriffe auf Linux-Gastsysteme zu erkennen und Angriffsspuren zu sichern. Letzteres so, dass einerseits dem Datenschutz genüge getan ist und andererseits später eine juristische Aufklärung möglich bleibt.

Gegenwärtig stellen Netzwerk-basierte IDS (NIDS) den Stand der Dinge dar. Sie versuchen von zentraler Stelle im Netz verdächtige oder gar schädliche Pakete zu erkennen und auszusortieren. Durch den wachsenden Anteil von verschlüsselten Netzwerkverbindungen können NIDS jedoch nur noch wenige Netzwerkpakete untersuchen.

Host-basierte IDS (HIDS) haben diesen Nachteil nicht. Ein HIDS kann theoretisch alle erdenklichen Abläufe eines Betriebssystems beobachten, inklusive der unverschlüsselten Datenkommunikation. Die Kehrseite der Medaille ist, dass der Admin diese Art von IDS auf allen zu schützenden Rechnern ausrollen und betreuen muss. Hinzu kommt, dass sich die Sensoren eines HIDS im überwachten System befinden und damit ebenfalls kompromittierbar sind.

Generell besitzen alle Angriffserkennungssysteme nicht den besten Ruf, weisen sie doch oft eine hohe Fehlalarmrate auf. Obendrein vertrauen viele Nutzer nicht unbedingt ihrem Datenschutz, kann doch ein IDS nicht nur technische Inhalte, sondern auch personenbezogene Daten beobachten. Genau hier setzt das Exploids-Projekt an.

Exploids

Der Kniff bei Exploids ist, dass es mit virtuellen Maschinen arbeitet und so die volle Kontrolle über das System, die Ressourcen und die Kommunikation erlangt. Es lassen sich nicht nur die Sensoren vor Manipulation schützen, auch die Weitergabe von Sensordaten ist reglementierbar. Um die Datenaufnahme von der Analyse zu trennen, ist Exploids in ein Front- und ein Backend unterteilt. Auch kommt spezielle Sicherheitshardware zum Einsatz (Abbildung 1).

Abbildung 1: Schematische Darstellung des Exploids-IDS.

Das Frontend besteht aus den zu schützenden Linux-Gastsystemen sowie einer Client-VM zur Aufnahme der Sensordaten. Als Virtualisierungslösung kommt eine für diesen Einsatzzweck weiterentwickelte L4-Mikrokern-Umgebung der Kernkonzept GmbH aus Dresden zum Einsatz. Sie beinhaltet einen Virtual Hypervisor zur Vollvirtualisierung von Linux-Gastsystemen. Der dabei verwendete Mikrokern L4-Fiasco wurde zuvor an der TU-Dresden entwickelt.

Die Gesamtmenge von Hard-, Soft- und Firmware, die mit Sicherheitsaufgaben betraut ist, heißt Trusted Computing Base (TCB). Sie ist in diesem Fall besonders klein und bietet damit nur eine geringe Angriffsfläche für Schadsoftware. Zudem zeigt sie durch die Capability-basierte Rechteverwaltung der Laufzeitumgebung eine höhere Systemsicherheit.

Hiervon profitieren besonders die Sensoren von Exploids. Bisher arbeiteten sie mit Introspektion. Bei der Introspektion wird das virtualisierte Gastsystem von außen durch den Hypervisor untersucht, der bei dieser Methode allerdings nur den Speicher begutachten kann. Daher muss er Zustandsübergänge und Systemabläufe aufwändig nachstellen, was nachteilig ist. Vorteilhaft ist dagegen, dass das Verfahren als sicher gilt.

Die andere Methode, die Injektion, kennt dieses Problem nicht. Bei ihr befinden sich die Sensoren im zu überwachenden System. Dabei sind die Programm- und Datenbereiche (Logdaten) vor Manipulationen zu schützen. Die Sicherung des Programmspeichers übernimmt der Hypervisor, indem er das Codesegment mit Schreibschutz versieht. Ein Hash sichert dagegen den Datenspeicher kryptografisch vor Manipulationen. Nachteil dieses Ansatzes ist, dass er aufgrund mangelhafter Schutzmechanismen bisher nur dürftig umzusetzen war.

Ebenso wichtig wie die Sensoren sind die Sensordaten. Bei externen Sensoren erhebt der Hypervisor die Daten und reicht sie via Interprozesskommunikation an den Client weiter. Bei den injizierten Sensoren ist das komplizierter. Damit ein Angreifer Logdaten nach dem Schreibvorgang des Sensors nicht beobachten oder löschen kann, sind sie zügig aus dem virtuellen Speicher der VMs zu entfernen. Das geschieht entweder, indem die Speicherseiten der VM vom Hypervisor aus- und in den Adressraum des IDS-Clienten eingeblendet werden. Alternativ kopiert die Exploids-Hardware die Daten auch per Direct-Memory-Access (DMA) ohne Zutun der CPU.

Die erste Methode bietet den Vorteil, dass die Daten nicht aufwändig kopiert werden müssen (Zero Copy). Bei der zweiten kann die Exploids-Hardware den Prozessor neben dem Kopiervorgang zusätzlich entlasten, indem sie die Logdaten erst beim Kopieren hasht. In jedem Fall nimmt die Client-VM die Datenströme entgegen, um sie zu verschlüsseln und gegebenenfalls zu anonymisieren. Die so vorverarbeiten Datenströme gelangen im Anschluss über eine gesicherte Verbindung an das Backend.

Dem Client assistieren hierbei eigens entwickelte Einsteckkarten mit FPGA-Chips (Field Programmable Gate Array). Zur Beschleunigung der Datenextraktion und Verschlüsselung besitzen sie DMA-, Signatur- und Krypto-Module. Für den Datenaustausch mit dem Backend wurden zudem Ethernet-Schnittstellen sowie die entsprechenden Netzwerkfunktionen implementiert.

Das Backend legt die verschlüsselten Sensordaten in einer eigens entwickelten, Sicherheits-sensitiven In-Memory-Datenbank ab. Das Besondere an dieser Datenbank ist, dass sie mit verschlüsselten Daten umgehen kann. Darüber hinaus kommen effiziente Methoden für die forensischen Analyse zum Zuge. Im Backend finden sich ausgefeilte Algorithmen zur Angriffserkennung. Die operieren ausschließlich auf den anonymisierten Sensordaten und arbeiten sowohl nach dem Prinzip der Muster- als auch dem der Anomalie-Erkennung.

System Calls auswerten

Um Muster und Anomalien auszumachen, greift man gern auf Systemaufrufe zurück, weil sie das Systemverhalten gut widerspiegeln. Über Systemaufrufe (System Calls) ruft ein Prozess die Funktionen des Betriebssystem auf, um zum Beispiel auf Dateien zuzugreifen. Listing1 zeigt eine stark verkürzte Darstellung der Systemaufrufe von »ls«.

Die komplette Sequenz für dieses simple Beispiel besteht bereits aus über hundert einzelnen Systemaufrufen. Das zeigt, dass die Datenmenge, die beim Aufzeichnen von Systemaufrufen entsteht, nicht zu unterschätzen ist. Bei ihren Analysen verwandten die Autoren dieses Beitrags den Datensatz ADFA-LD [2] von der Australian Defence Force Academy.

Der Datensatz besteht aus etwa 5950 Sequenzen mit einer maximalen Länge von über 4000 einzelnen Systemaufrufen verschiedener Programme, aufgezeichnet mit einem Ubuntu-System. Enthalten sind das normales Verhalten und das Verhalten der Programme, während sie angegriffen wurden. ADFA-LD ist nur einer von mehreren Datensätzen. Weitere Beispiele sind KDD und UNM.

ADFA-LD hat jedoch den Vorteil, dass er im Rahmen eines modernen Environments (Ubuntu 11.04) entstanden ist und damit einer der modernsten verfügbaren Datensätze zu Intrusion Detection ist. Im Gegensatz zur Sequenz aus dem Listing 1 enthalten die Systemaufrufe aus dem ADFA-LD-Datensatz keine Parameter oder Rückgabewerte. Zusätzlich sind die Funktionsnamen der Systemaufrufe durch ganze Zahlen ersetzt. Folglich erhält man eine Abfolge wie

01 $strace ls
02 [...]
03 execve("/bin/ls", ["ls"], 0x7ffedab238d0 /* 43 vars */) = 0
04 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) =3
05 [...]
06 close(3) = 0
07 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVA...YMOUS, -1, 0) =0x7fcb88bf0000
08 mprotect(0x7fcb887c3000, 16384, PROT_READ) = 0
09 [...]

S: 054 175 120 175 175 003 175 175 ...

die hier als Beispielsequenz S (siehe Abbildung 2) dient.

Abbildung 2: Graph der Beispiel-Sequenz S. Die Zahlen an den Kanten (Kantengewichte) stellen die Häufigkeit eines Übergangs dar.

Wahrscheinlichkeitsgraphen

Der wesentliche Ansatz bei Exploids ist es, die Sequenz der Systemaufrufe als so genannten Sequenz-Graphen zu interpretieren. Systemaufrufe stellt das Verfahren als Knoten und Übergänge zwischen ihnen als gerichtete Kanten dar.

Bis jetzt ist die Sequenz nur in eine andere Darstellung überführt. Nun stellt sich die Frage, wie man daraus Merkmale zur Anomalie-Erkennung extrahiert. Dazu gilt es, die Übergänge zwischen den Systemaufrufen näher zu beschreiben. Bei Exploids kommt ein Wahrscheinlichkeitsgraph zum Einsatz. Ein solcher fasst alle zuvor berechneten Sequenz-Graphen zusammen, indem er die Übergänge mit Wahrscheinlichkeiten sowie mit Häufigkeiten unterlegt.

Klassifikation

Der ermittelte Wahrscheinlichkeitsgraph dient zur Unterscheidung von normalem und abnormalem Verhalten. Die Einteilung nehmen im Fall von Exploids so genannte Einklassen-Klassifikatoren vor. Sie nutzen zum Training ausschließlich Informationen einer einzelnen Informationsklasse, die hier aus den unter Normalbedingungen ermittelten Aufrufsequenzen eines Programms besteht.

Die Aufgabe des Klassifikators besteht darin, eine Grenze um diese Trainingsdaten zu ziehen. Er steckt die Grenze so, dass sie so viele normale Aufrufsequenzen wie möglich umfasst und zugleich die Anzahl der Fehlklassifikationen minimiert (Abbildung 3). Anhand eines Merkmalvektors entscheidet sich, ob sich das Verhalten innerhalb oder außerhalb der Grenze abspielt. Im einfachsten Fall berechnet sich ein solcher Merkmalvektor durch die Mittelwerte von Übergangs-Häufigkeit und -Wahrscheinlichkeit. Es sind aber auch kompliziertere Bildungsvorschriften möglich.

Abbildung 3: Der AABB-Klassifikator visualisiert für zwei Dimensionen. Die einfache Form der Grenze kann Probleme bereiten: Leicht ersichtlich ist, dass der normale Wert b korrekt klassifiziert, die Anomalie a jedoch nicht erkannt wurde.

Um den Wahrscheinlichkeitsgraphen auf Wirksamkeit zu prüfen, werden drei Klassifikatoren verwendet: der AABB-, der k-Center- und der NN-Klassifikator. Der AABB-Klassifikator (Axis Aligned Bounding Box) ist der grundlegende Klassifikator in Exploids. Die aufgespannte Grenze bildet einen mehrdimensionalen Quader, der die Trainingsdaten so eng wie möglich umschließt.

Die vom k-Center-Klassifikator (Abbildung 4) gebildete Grenze besteht aus mehrdimensionalen Kugeln, die alle Trainingsdaten ebenfalls so genau wie möglich umschließen. Dabei liegen die Mittelpunkte der Kugeln auf Elementen der Trainingsdaten.

Abbildung 4: Der k-Center-Klassifikator visualisiert für zwei Dimensionen und k = 3, er bildet dabei eine komplexere Grenze.

Der NN-Klassifikator (Nearest Neighbour) bildet um jeden Punkt der Trainingsdaten eine mehrdimensionale Kugel. Diese berührt genau den Punkt, der ihr aus den Trainingsdaten am nächsten ist. Der Zusammenschluss dieser Kugeln bildet eine Gesamtgrenze (Abbildung 5).

Abbildung 5: der NN-Klassifikator visualisiert für zwei Dimensionen. Die komplexere Form der Grenze kann zu noch besseren Klassifikationsergebnissen führen. Die Beispieldatenpunkte a und b klassifiziert das Beispiel korrekt.

Experimente

Um den Ansatz zu prüfen, verglichen die Forscher die Klassifikationsergebnisse der drei Methoden mit einem Standardansatz zur Anomalie-Erkennung. Die Stide-Methode [2] eignet sich dafür besonders, da sie explizit für Intrusion-Detection-Systeme auf Basis von Systemaufrufen entstanden ist. Stide arbeitet im Unterschied zu den zuvor vorgestellten Klassifikatoren nicht mit Merkmalvektoren, sondern direkt mit Aufrufsequenzen.

Wichtig für den Vergleich ist es, die Detektionsrate (DR) der Fehlalarmrate (FAR) gegenüberzustellen. Gute Klassifikatoren zeichnen sich dadurch aus, dass ihre Detektionsrate hoch und die Fehlalarmrate gering ausfällt (Abbildung 6).

Abbildung 6: Vergleich der besten Konfigurationen der verschiedenen Klassifikatoren. Für jeden Klassifikator sind hier die n-Gramm-Längen von 1 bis 10 getestet und abgetragen.

In der Abbildung ist der NN-Klassifikator nicht dargestellt. Er scheint für die Art der Daten nicht geeignet und führte zu sehr schlechten Ergebnissen. Die k-Center-Methode ist für niedrige Werte von n und k relativ schlecht, steigt aber bei größerem n und k auf Kosten der Fehlalarmrate auf über 90 Prozent.

Der AABB-Klassifikator ist trotz seines einfachen Ansatzes vielversprechend. Mit steigender n-Gramm-Länge verbessert sich seine Detektionsrate auf Kosten der Fehlalarmrate. Stide eignet sich nur für den Bereich mittlerer Erkennungs- und Fehlalarm-Raten. In allen anderen Konfigurationen ist Stide entweder genauso gut oder schlechter als die drei bei Exploids genutzten Klassifikatoren.

Fazit

Dass Host-Intrusion-Detection-Systeme für virtuelle Maschinen in Zeiten des verschlüsselten Netzwerkverkehrs an Relevanz gewinnen, dürfte unstrittig sein. Die Frage ist nur, wie dabei die Privatheit der Nutzerdaten zu sichern ist. Exploids demonstriert ein Vorgehen, bei dem Datenquellen, Algorithmen sowie Klassifikatoren mit anonymisierten, Graph-basierten Ablaufsequenzen auskommen. Erste Tests zeigen, dass dieser Ansatz gleichwertige oder bessere Ergebnisse als der Standardansatz liefert.

Die Forscher wollen daher die Idee des n-Gramm-basierten Wahrscheinlichkeitsgraphen weiterverfolgen und zum Beispiel mit neuronalen Netzen kombinieren. Auch wollen sie untersuchen, ob die Erfassung von anonymisierten Metadaten zu besseren Ergebnissen führt. Das könnten etwa Prozessnamen, Aufrufparameter oder File-Handles sein.

Wichtigstes Ziel bleibt aber nach wie vor, die Fehlalarmrate zu senken, um ein automatisches, sicheres und im Hintergrund arbeitendes System zu realisieren, das gleichzeitig auch die Privatheit der Nutzerdaten achtet.