Mathematik Und Informatik

Daniel Spiekermann

Netzwerkforensik in virtuellen Umgebungen

Mathematik und Informatik

Dissertation

deposit_hagen Publikationsserver der Universitätsbibliothek Netzwerkforensik in virtuellen Umgebungen

Dissertation

zur Erlangung des akademischen Grades DOKTOR RER. NAT.

an der

FernUniversität in Hagen Fakultät für Mathematik und Informatik

vorgelegt von

Daniel Spiekermann

geb. in Wickede-Wimbern

Betreuer: Prof. Dr. Jörg Keller

Hagen, den 28. Juni 2017 1. Gutachter: Herr Prof. Dr. Jörg Keller (FernUniversität in Hagen)

2. Gutachter: Herr Prof. Dr. Tobias Eggendorfer (Hochschule Ravensburg-Weingarten)

Vorsitzender der Prüfungskomission: Herr Prof. Dr. Wolfram Schiﬀmann (FernUniversität in Hagen)

Protokollant: Dr. Jörg Lenhardt (FernUniversität in Hagen)

Datum der mündlichen Prüfung: 05. Oktober 2017 Für Meike und Klara

Zusammenfassung

Die stetige Weiterentwicklung moderner Rechenzentren hat nach der hohen Verbreitung virtueller Maschinen nun die klassische Netzwerktechnik erreicht. Virtuelle Maschinen bieten den Nutzern ﬂexible Umgebungen, die größtenteils eigenständig an die jeweiligen Bedürfnisse angepasst werden können. Die Vernetzung dieser virtuellen Systeme mit Hilfe der klassischen Netzwerktechnik ist zwar grundsätzlich möglich, aber aufgrund unterschiedlichster Limitierungen für Provider und Kunde weder ausreichend noch zeitgemäß. Mit Hilfe virtueller Netzwerke ist es den Betreibern jedoch möglich, unterschiedlichste Lösungen über das physische Netzwerk anzubieten und so dem Kunden eine ﬂexible und dynamische Umgebung bereitzustellen. Dabei entstehen prinzipiell beliebig viele logisch voneinander getrennte Subnetze, die gemeinsam über das zugrundeliegende hardwarebasierte Netzwerk transportiert werden. Jedes dieser virtuellen Netzwerke bildet dabei eine isolierte Umgebung, die unter der möglichen Administration eines Kunden steht; der Pro- vider kennt somit auch keine Details über die interne Nutzung der Kundenumgebung. Während der Kunde dank der virtuellen Umgebung eigenständig Anpassungen vornehmen kann, ermöglicht diese Umgebung dem Provider eine schnelle Bereitstellung von Anwendungen und Dienste, da das genutzte Netzwerk nun automatisier- und programmierbar wird.

Die Netzwerkforensik der Strafverfolgungsbehörden sowie im Bereich der IT-Sicherung und des Störungsmanagements wird jedoch durch diese neue Entwicklung erschwert. Bewährte Implemen- tierungen und Verfahren zur Datenaufzeichnung und -analyse scheitern an neuen Techniken wie der Migration einer virtuellen Maschine oder der Anpassung der virtuellen Netzwerkumgebung zur Laufzeit. Hierdurch können jederzeit elementare Änderungen in der Struktur des Netzwerks auftreten. Die virtuellen Maschinen besitzen darüber hinaus weder eine hardwarebasierte Netz- werkkarte noch ist eine eindeutige Identiﬁkation unmittelbar möglich. Die zur Implementierung der virtuellen Umgebung genutzten Netzwerkprotokolle erschweren darüber hinaus die Analyse der aufgezeichneten Daten, da bisher nur wenige geeignete Analysewerkzeuge zur Verfügung stehen.

Diese Arbeit untersucht die Techniken und Möglichkeiten virtueller Netzwerke, deﬁniert die resul- tierenden Problemfelder der Netzwerkforensik und entwickelt darauf aufbauend eine Strategie, die eine valide netzwerkforensische Untersuchung in virtuellen Umgebungen ermöglicht. Das vorgeschlagene Verfahren berücksichtigt erstmals die Dynamik der virtuellen Umgebungen und schaﬀt so eine verlässliche Implementierung der Aufzeichnung. Das entwickelte Vorgehensmo- dell ist die Basis der Implementierung von zwei Lösungen, die mit OVSF für statisch ausgelegte virtuelle Netzwerke und mit ForCon für hochdynamische OpenFlow-Netzwerke entsprechende Neuentwicklungen darstellen.

Abstract

The ongoing evolution of modern datacenters has now reached the traditional network technology with the wide spread of virtual machines. The interconnection of these virtual systems is possible, but due to various limitations for the provider and customer it is neither sufficient nor up-to-date. With the help of virtual networks operators are able to provide a wide range of different environments over the physical network and therefore increase the flexibility of their environment further. As a result practically any number of logical separated subnets are shared by the underlying physical network. Each of these virtual networks creates an isolated environment, which is under the administration of a customer; the provider therefore does not know any details about the internal use of the customers environment. While the user is able to customize the assigned environment, the provider is able to quickly deploy applications and services as the network is now automated and programmable.

However, this new technique impedes network forensic investigation of law enforcement, IT- security and troubleshooting. Proven techniques like data capture and analysis might fail with new implementations like migration of virtual machines or adaptations of the network environment at runtime. At any time critical changes might arise and hamper the running process. The virtual machines have neither a hardware-based network card nor a unique identiﬁcation. Even the initial setup of a network forensic investigation within such an environment does not guarantee the capture of the entire network traﬃc. In addition to this, the new network protocols used to implement the virtual environment also impede the subsequent analysis of the recorded data, because of the lack of suitable analysis tools.

In this thesis, the techniques and possibilities of virtual networks are analysed and arising problems of network forensic investigation are deﬁned. As a result, a strategy that facilitates a valid forensic investigation process in virtual networks is presented. The proposed method considers the dynamics of virtual environments for the ﬁrst time and provides a reliable implementation of recording relevant network data in virtual environments. The development of a new forensic model provides the basis for the implementation of two solutions: OVSF for statically-designed virtual networks and ForCon for highly dynamic OpenFlow networks.

Erklärung

Ich erkläre, dass ich die vorliegende Dissertation selbständig und ohne fremde Hilfe verfasst habe. Alle von anderen Autoren wörtlich übernommenen Stellen sowie Ausführungen, die sich an Gedankengängen anderer Autoren anlehnen, habe ich gekennzeichnet und die Quellen zitiert.

Arnsberg, den 28.06.2017

Danksagung

Die erste Seite dieser Arbeit möchte ich nutzen, um all denjenigen zu danken, die mich bei der Anfertigung dieser Arbeit unterstützt haben.

Mein größter Dank gilt meinem Doktorvater Herr Prof. Dr. Jörg Keller, der es mir ermöglicht hat, meine Doktorarbeit an der Fakultät für Mathematik und Informatik an der FernUniversität in Hagen zu schreiben. Die fachliche Betreuung, die tatkräftige Unterstützung bei Fragen sowie die hilfreichen Tipps und Hinweise haben diese Dissertation erst zu einer vollständigen Arbeit gemacht. Der regelmäßige Austausch (per Mail, Telefon und persönlich) sowie seine Bereitschaft zur Förderung haben es mir erleichtert, die Arbeit als externer Doktorand zu erstellen.

Auch Herrn Prof. Dr. Tobias Eggendorfer von der Hochschule Ravensburg-Weingarten möchte ich für die Betreuung und Unterstützung bei der Durchführung sowie seinen zahlreichen Hinweisen und Verbesserungsvorschläge danken. Sein Wissen und die Bereitschaft, dieses zu teilen, haben mir tiefgehende Einblicke in wissenschaftliche Betrachtung der IT-Forensik ermöglicht.

Meinen Kollegen des KK 25 im Polizeipräsidium Dortmund danke ich ebenfalls für die Unter- stützung bei der Erstellung meiner Arbeit. Besonderer Dank gebührt dabei Markus Schulz für seine zahlreichen Diskussionen über virtuelle Netzwerke und die Netzwerkforensik. Diese fruchtbaren Diskussionen haben geholfen, Aspekte zu vertiefen und neue Ideen zu erarbeiten. Auch Jan Beisenkamp für die Korrekturen und Hinweise sowie Herbert Krusel für die Möglichkeit zur Erstellung der Arbeit möchte ich herzlich danken.

Darüber hinaus bedanke ich mich bei Marcel Selhorst für die Anregungen und Diskussionen zum Linuxkernel sowie seine Hinweise, Tipps und Korrekturen, Dr. Ingo Geue für die Hilfestellung zu Beginn meiner Promotion und Heiko Wolter für die Diskussionen und den Austausch zum Thema der klassischen Netzwerkforensik.

Besonderer Dank gebührt meinen Eltern Irmgard und Josef Spiekermann sowie meinen Schwie- gereltern Regina und Dieter Schmidt. Ohne die Unterstützung meiner Familie wäre diese Arbeit nicht möglich gewesen.

Meiner Frau Meike danke ich für Ihre Liebe, ihr Verständnis für den Verzicht auf gemeinsame Stunden zu dritt mit unser Tochter Klara und ihre Geduld mit mir. Erst ihre Worte haben mir den Mut gegeben, mit der Promotion zu beginnen.

Publikationen

Die folgenden Publikationen wurden im Rahmen dieser Arbeit veröﬀentlicht.

Spiekermann, Daniel; Eggendorfer, Tobias; Keller, Jörg: Using Network Data to Improve Digital Investigation in Cloud Computing Environments In: High Performance Computing & Simulation (HPCS), 2015 International Conference, IEEE, 2015, S. 98—105 Dieses Paper beschreibt die Analyse von aufgezeichneten Netzwerkdaten, um die Nutzung unterschiedlicher Clouddienste zu identiﬁzieren. Der Artikel wurde durch Daniel Spiekermann geschrieben. Jörg Keller und Tobias Eggendorfer haben durch Hinweise und Korrekturen die Arbeit vervollständigt.

Spiekermann, Daniel; Eggendorfer, Tobias: Towards Digital Investigation in Virtual Networks: A Study of Challenges and Open Problems In: 11th International Conference on Availability, Reliability and Security, ARES 2016, IEEE Computer Society, 2016, S. 406-–413 Dieses Paper beschreibt die neu auftretenden Probleme, die im Rahmen netzwerkforensischer Untersuchungen in virtuellen Umgebungen auftreten. Die Aufteilung der Probleme in online, oﬄine und organisatorisch wurde genutzt, um die Probleme zu klassiﬁzieren. Der Artikel wurde durch Daniel Spiekermann geschrieben, Tobias Eggendorfer hat mit hilfreichen Anmerkungen die Fertigstellung unterstützt.

Spiekermann, Daniel; Eggendorfer, Tobias: Challenges of Network Forensic Investigation in Virtual Networks In: Journal of Cyber Security and Mobility 5 (2016), Nr. 2, S. 15—46 Dieser Artikel behandelt die neu auftretenden Probleme der forensischen Untersuchungen in virtuellen Netzwerken. Der Artikel wurde durch Daniel Spiekermann geschrieben und durch Tobias Eggendorfer mit Hinweisen ergänzt.

Spiekermann, Daniel; Keller, Jörg; Eggendorfer, Tobias: Network Forensic Investigation in OpenFlow Networks with ForCon In: Digital Investigation 20 (2017), S. 66-–74 Dieses Paper beschreibt die Entwicklung und Nutzung von ForCon. Mit Hilfe von ForCon sind netzwerkforensische Untersuchungen in OpenFlow-Netzwerken möglich. Darüber hinaus wird erstmals das VNFP vorgestellt, welches als Vorgehensmodell für die Forensik in virtuellen Netz- werken dient. Der Artikel wurde durch Daniel Spiekermann geschrieben und durch Jörg Keller und Tobias Eggendorfer editiert.

XIII Spiekermann, Daniel; Keller, Jörg; Eggendorfer, Tobias: Towards Covert Channels in Cloud Environments: A Study of Implementations in Virtual Networks In: International Workshop on Digital Watermarking. Springer, 2017. Dieses Paper beschreibt Techniken zur Implementierung verdeckter Kanäle in virtuellen Netz- werken. Dabei werden sowohl protokollbasierte Techniken auf Basis von der Overlayprotokolle beschrieben als auch mit dem VM Migration Covert Channel ein protokollunabhängiger Ansatz vorgestellt. Eine Entdeckung der VM Migration Covert Channel ist dabei nur mit Hilfe der in der Arbeit beschriebenen Techniken möglich. Der Artikel wurde durch Daniel Spiekermann geschrieben und durch Jörg Keller mit Hinweisen zu covert channels ergänzt. Tobias Eggendorfer hat das mit weiteren Hinweisen editiert.

Spiekermann, Daniel; Keller, Jörg; Eggendorfer, Tobias: Using Open Source Based Distributed Agents to Perform Digital Investigation in Virtual Environments In: GI-Edition Lecture Notes in Informatics (LNI), 2017 Dieses Paper beschreibt den agentenbasierten Ansatz zur forensischen Untersuchungen in virtuellen Umgebungen. Die Open Source Implementierung ermöglicht Anpassungen an andere Umgebungen. Der Artikel wurde durch Daniel Spiekermann geschrieben und durch Jörg Keller und Tobias Eggendorfer editiert.

Tabelle 0.1 verbindet die bisherigen Veröﬀentlichungen mit den Kapiteln dieser Arbeit:

Tabelle 0.1: Liste der Publikationen Publikation Kapitel Erläuterung Using Network Data to Improve Di- 3.2 Die Analyse aufgezeichneter Netzwerkdaten gital Investigation in Cloud Compu- ermöglicht die Erkennung genutzter Cloud- ting Environments Dienste und stellt somit einen Baustein der Cloud-Forensik dar. Towards Digital Investigation in Vir- 4 Die Probleme werden in dieser Arbeit klassiﬁ- tual Networks: A Study of Challen- ziert, darüber hinaus erfolgt die Analyse mög- ges and Open Problem licher Probleme. Challenges of Network Forensic In- 4 / 8 Diese Arbeit beschreibt detailliert ForCon und vestigation in Virtual Networks die Möglichkeiten der dynamischen Überwa- chung. Network Forensic Investigation in 6.2 / 8 Das VNFP wurde im Paper kurz vorgestellt,in OpenFlow Networks with ForCon dieser Arbeit wird die Herleitung beschrieben und die notwendigen Phasen detailliert erläu- tert. Towards Covert Channels in Cloud 3.4 / 9.4 Diese Arbeit beschreibt die Entdeckung der Environments: A Study of Imple- antiforensischen Techniken mit Hilfe von For- mentations in Virtual Networks Con. Using Open Source Based Distribu- 8.4 DieseArbeit vertieft denagentenbasiertenAn- ted Agents to Perform Digital Inves- satzes von ForCon. tigation in Virtual Environments Inhaltsverzeichnis

1 Einleitung 1 1.1 Motivation...... 1 1.2 Szenarien...... 3 1.2.1 Speicherung inkriminierter Inhalte in Cloud-Umgebungen...... 3 1.2.2 Datenmissbrauch im Unternehmensnetzwerk ...... 4 1.2.3 Bewertung...... 5 1.3 BedeutungderProblemstellung ...... 6 1.4 ZielederArbeit ...... 8 1.5 Übersicht...... 9

2 Grundlagen 11 2.1 Netzwerktechnik...... 11 2.1.1 Referenzmodelle...... 12 2.1.2 Schichten ...... 13 2.1.3 Hardware ...... 19 2.2 Cloud-Computing ...... 22 2.2.1 Eigenschaften ...... 23 2.2.2 Hardwareentwicklung ...... 25 2.2.3 EntwicklungderSoftwareumgebung ...... 29 2.3 Netzwerkvirtualisierung ...... 34 2.3.1 Entstehung ...... 34 2.3.2 Overlay-Netzwerke...... 39 2.4 SoftwareDeﬁnedNetworks ...... 46 2.4.1 Konzepte...... 46 2.4.2 OpenFlow ...... 50 2.5 NetworkFunctionVirtualization ...... 55 2.5.1 NFVFramework...... 55 2.5.2 Vorteile ...... 57 2.5.3 OpenvSwitch ...... 58 2.6 Netzwerkforensik...... 60 2.6.1 Deﬁnition ...... 61 2.6.2 Aufzeichnung ...... 62 2.6.3 Speicherung ...... 64 2.6.4 Auswertung ...... 66

3 Forschungsstand 67 3.1 Netzwerkforensik...... 67 3.1.1 FokusderStrafverfolgung...... 68 3.1.2 Metadatenanalyse ...... 69 3.1.3 StatistischeBewertung ...... 71 3.1.4 Datenmenge...... 72 3.2 Cloud-Forensik...... 73 3.2.1 KomponentenbasierteForensik ...... 74 3.2.2 Containerforensik ...... 75 3.3 ForensikinvirtuellenNetzwerken ...... 76 3.4 Vorgehensmodelle ...... 77 3.5 Antiforensik ...... 79

4 Problemanalyse 81 4.1 BestimmungexistenterProblemfelder ...... 81 4.1.1 AufteilungnachPhasen ...... 82 4.1.2 AufteilungnachKomponenten ...... 83 4.1.3 AufteilungnachProzessen ...... 84 4.2 Migration ...... 86 4.3 Nutzeranpassungen ...... 87 4.4 VirtuelleNetzwerkkarten ...... 88 4.4.1 Identiﬁkation ...... 89 4.4.2 Aufzeichnungsproblem...... 89 4.5 Multitenancy...... 90 4.6 InternerDatenverkehr ...... 90 4.7 PhysischeVernetzung ...... 91 4.8 NichteindeutigkeitderMAC...... 92 4.9 Netzwerkdaten...... 92 4.9.1 Menge...... 93 4.9.2 Bestimmung...... 93 4.10 Softwareunterstützung...... 102 4.10.1 Protokolle ...... 104 4.10.2 Zielrichtung ...... 106 4.11 OverlappedIP-Addresses ...... 107 4.12Linkauslastung...... 108 4.13 VielzahlderController...... 109 4.14 Unvollständigkeitder Informationen ...... 110 4.15Klassiﬁzierung ...... 111 4.16 Zusammenfassung...... 114

5 Entwicklung eines Anforderungsmodells 115 5.1 EtablierteAnforderung ...... 115 5.1.1 IT-Forensik ...... 115 5.1.2 Netzwerkforensik ...... 117 5.2 SpezifischeAnforderungen...... 118 5.2.1 Datenreduktion ...... 118 5.2.2 DynamischeAdaption...... 119 5.2.3 Monitoring...... 120 5.2.4 Datenschutz...... 120 5.2.5 Herstellerunabhängigkeit ...... 121 5.2.6 Hardwareunabhängigkeit ...... 122 5.2.7 Netzlastminimierung...... 123 5.3 Lösungsmodell...... 124 5.4 Zusammenfassung...... 126 6 Entwicklung eines angepassten Vorgehensmodells 127 6.1 Vorgehensmodelle ...... 127 6.1.1 Differenzierung ...... 128 6.1.2 Modellbeschreibung ...... 129 6.1.3 Schwächen...... 131 6.2 VirtualNetworkForensicProcess ...... 132 6.2.1 Identifikation ...... 133 6.2.2 Vorbereitung...... 134 6.2.3 Aufzeichnung ...... 134 6.2.4 Überwachung ...... 135 6.2.5 Bewertung...... 136 6.2.6 Adaption...... 137 6.2.7 Speicherung ...... 137 6.2.8 Analyse ...... 138 6.3 Zusammenfassung...... 139

7 Open vSwitch-Forensik 141 7.1 Vorüberlegung...... 142 7.1.1 Entwicklungsbasis geeigneter Werkzeuge ...... 143 7.1.2 Datenausleitung...... 146 7.1.3 Technik zur forensischen Nutzung virtueller Switche ...... 151 7.2 Testaufbau...... 152 7.3 Portidentiﬁzierung...... 153 7.3.1 Adressenbasiert ...... 155 7.3.2 Portbasiert...... 156 7.4 Mirrorport ...... 156 7.4.1 Plain...... 158 7.4.2 VLAN ...... 158 7.4.3 VXLAN ...... 160 7.4.4 Gesamtergebnis ...... 162 7.5 Überwachung ...... 163 7.5.1 Bestimmung einer geeignetenDatenbasis ...... 163 7.5.2 ImplementierungderÜberwachung ...... 167 7.5.3 SituativeDiﬀerenzierung ...... 169 7.5.4 Protokollierung ...... 172 7.6 Implementierung...... 174 7.7 Zusammenfassung...... 176

8 OpenFlow-Forensik 179 8.1 Vorüberlegungen...... 179 8.1.1 Analyse existenter Implementierungen ...... 180 8.1.2 Bewertung...... 181 8.2 Problemanalyse ...... 181 8.2.1 VorhandeneFlows...... 182 8.2.2 KomplexitätderFlows ...... 182 8.2.3 Controllerabhängigkeit ...... 183 8.2.4 Ergebnis ...... 184 8.3 Lösungsentwicklung ...... 184 8.3.1 Evaluierungder Zugriffsmöglichkeit...... 185 8.3.2 IdentifikationderSwitchinstanz...... 187 8.3.3 IdentifikationderrelevantenFlows ...... 189 8.3.4 Flowmanipulation ...... 191 8.3.5 Überwachung ...... 194 8.4 Implementierung...... 197 8.4.1 ForCon-Server...... 199 8.4.2 Agenten ...... 200 8.4.3 ForConProtocol...... 201 8.4.4 Ablauf ...... 202 8.5 Testumgebung...... 204 8.6 Bewertung...... 208 8.7 Zusammenfassung...... 209

9 Evaluierung 211 9.1 Korrektheit...... 211 9.1.1 Vollständigkeit...... 212 9.1.2 Integrität...... 218 9.1.3 Nachweis...... 222 9.2 AbgleichmitdemVNFP ...... 223 9.2.1 Identiﬁkation ...... 223 9.2.2 Vorbereitung...... 224 9.2.3 Aufzeichnung ...... 224 9.2.4 Speicherung ...... 224 9.2.5 Überwachung ...... 225 9.2.6 Bewertung...... 225 9.2.7 Adaption...... 226 9.2.8 Analyse ...... 226 9.2.9 Ergebnis ...... 226 9.3 ValidierunginOpenStack-Umgebung ...... 227 9.3.1 BeschreibungderModellumgebung...... 227 9.3.2 Durchführung ...... 229 9.3.3 Optimierung...... 232 9.3.4 Fazit...... 234 9.4 AntiforensischeBewertung ...... 235 9.5 Zusammenfassung...... 236

10 Fazit 237 10.1 Zusammenfassung...... 237 10.2Ausblick ...... 238 10.3EigeneLeistung ...... 239

Literaturverzeichnis 241

Abbildungsverzeichnis 279

Tabellenverzeichnis 281

Verzeichnis der Listings 283

Abkürzungsverzeichnis 285 1 Einleitung

1.1 Motivation

Die Untersuchung, Rekonstruktion und Beweisführung von verdächtigen Vorfällen in Zusam- menhang mit IT-Systemen verlangt eine genaue Aufzeichnung und Auswertung möglicherweise beweiserheblicher Daten. Eine korrekt durchgeführte forensische Arbeit ist dabei nur möglich, wenn alle relevanten Daten identiﬁziert und ausgewertet werden können. Dies ist nicht nur bei klassischen IT-Umgebungen gültig, auch in virtuellen Cloud-Umgebungen sind die Ergebnisse einer Untersuchung untrennbar mit den ermittelten Daten verbunden.

Die Notwendigkeit forensischer Arbeiten in virtuellen Umgebungen wurde in der jüngsten Ver- gangenheit immer wieder deutlich. So zeigt der Fall des Datendiebstahl1 der Internetseiten www.mitfahrzentrale.de und www.mitfahrgelegenheit.de deutlich die Probleme bei Untersuchun- gen in virtuellen Umgebungen. Bei dem Angriﬀ am 29. November 2016 auf die Internetseiten wurde ein in einer Cloud-Umgebung gespeichertes Backup unrechtmäßig kopiert, so dass per- sönliche Daten wie Namen, Telefonnummern und Bankverbindungen der Kunden in den Besitz der Angreifer gelangten [Sch16]. Obwohl das Unternehmen Strafanzeige stellte und Ermittlungs- behörden den Fall untersuchten, konnte der Vorfall bisher nicht aufgeklärt werden.

Dabei ist ein solcher Angriff kein Einzelfall. Exemplarisch sind weitere Angriffe auf virtuelle Umge- bungen wie die Malwareverteilung über die Webseiten www.reddit.com am 22. September 2015 [Sch15], der Datenmissbrauch beim Passwortspeicherdienst LastPass [Sie15] am 15. Juni 2015 oder die Veröffentlichung benutzerbezogener Daten des Onlineportals Ashley Madison [Avi15] am 11. Juli 2015. All diese Angriffe waren auf die IT-Umgebungen der Unternehmen gerichtet, die bei externen Anbietern in virtuellen Umgebungen betrieben wurden.

Solche externen Anbieter bieten ihren Kunden eine Vielzahl unterschiedlicher Dienste, Angebo- te und Techniken an und übernimmt dabei Konﬁgurations- und Administrationsaufgaben der zugrundeliegenden Umgebung. Den Kunden stehen verschiedene Modelle zur Verfügung, ange- fangen von der Nutzung einer virtuellen Maschine bis hin zu einzelnen spezialisierten Software-

1Im Strafgesetzbuch existiert dieses Wort nicht, da die Daten nicht gestohlen, sondern missbräuchlich genutzt werden. Daher wird ein solcher Straftatbestand im § 202a StGB als Äusspähen von Daten deﬁniert.

1 1 Einleitung implementierungen oder einer kompletten Multitierarchitektur auf Basis miteinander vernetzter virtueller Systeme. Entwickler und Unternehmen können sich so auf ihre Hauptaufgabe konzentrieren, ohne die Anschaffungs- und Betriebskosten sowie die notwendigen Reinvestitionen für eigene Hard- und Software aufbringen zu müssen. Durch die unterschiedlichen Servicemodelle können angepasste Umgebungen gemietet werden, so dass sich der Wartungsaufwand auf ein Minimum reduzieren lässt. Entwicklern ist es so möglich, ohne Installation oder Konfiguration benötigter Laufzeitumgebungen ihren Fokus auf die Softwareentwicklung zu legen. Unterneh- men können neue Techniken erproben, ohne die benötigte Hardware oder Software jedes Mal beschaffen zu müssen. Anwender erhalten die Möglichkeit, genutzte Programme von überall auf der Welt zu nutzen und jederzeit Zugriff auf ihre Daten zu erhalten.

Der Kunde zahlt dabei die Nutzung der Dienste, der Provider stellt die hierfür benötigte Um- gebung in seinem Rechenzentrum (RZ) zur Verfügung. Hier installiert, konﬁguriert und wartet der Provider die notwendigen Systeme, stellt Verfügbarkeit und Leistungsfähigkeit der angebotenen Dienste sicher und übernimmt alle weiteren anfallenden Arbeiten im Betrieb. Um auf Anforderungen und Kundenwünsche reagieren und auch Leistungsanpassungen schnell erfüllen zu können, nutzt der Provider hochdynamische, virtuelle Umgebungen. Dies umfasst mittlerweile nicht mehr nur die Nutzung virtueller Maschinen, sondern auch die Speichervirtualisierung und Implementierung virtueller Netzwerke.

Besonders diese Netzwerkvirtualisierung bietet eine unmittelbare Steigerung der Flexibilität innerhalb der Umgebung. Jedem Kunden wird dabei ein eigenes, logisches Netzwerk angeboten, in dem dieser eigenständig Anpassungen vornehmen kann. Virtuelle Maschinen können nun ohne weitere administrative Arbeit separiert, migriert oder angepasst werden. Das jeweilige logische Netzwerk wird auf Basis des physischen Netzwerks bereitgestellt und mit Hilfe der eingesetzten Managementumgebung so konﬁguriert, dass es wie ein alleinstehendes Netzwerk erscheint. Mit Hilfe neuer Netzwerkprotokolle werden dabei Limitierungen alter Protokolle aufgehoben, Techni- ken wie Software Deﬁned Network (SDN) oder Network Function Virtualization (NFV) erhöhen zusätzlich die Flexibilität und Leistungsfähigkeit.

Allerdings ist der Kundenkreis zur Nutzung der virtuellen Umgebungen nicht beschränkt. Auch Angreifer nutzen die Techniken des Cloud-Computings, um ihre illegalen Aktivitäten zu verschleiern und so der Strafverfolgung und Aufklärung zu entgehen. Ermittlungsbehörden oder unternehmenseigene IT-Spezialisten sind dann gefordert, den Vorfall sowohl aufzuklären als auch dafür zu sorgen, dass weitere Angriﬀe nicht stattﬁnden können. Besonders der Nachweis des Verursachers ist in diesen Umgebungen mit Techniken der klassischen IT-Forensik nur schwerlich zu erbringen. Während in der Vergangenheit die Kombination mit anderen Teildisziplinen der digitalen Forensik zusätzliche Möglichkeiten zur Aufklärung bot, sind diese Ansätze im virtuellen Umfeld kaum gegeben.

2 1.2 Szenarien

Besonders der Bereich der Netzwerkforensik ist mit einer Vielzahl neuer Probleme konfrontiert, die durch die gestiegene Komplexität der virtuellen Netzwerke zusätzlich erschwert wird. Aufbauend auf dem physischen Netzwerk existiert nun eine Vielzahl virtueller Netzwerke parallel, jedes dieser Netzwerke verhält sich wie eine komplett autarke Umgebung. Der klassische Ansatz „Ein Port - eine IP-Adresse“ verliert seine Gültigkeit, so dass eine Bestimmung der notwendigen Netzwerk- ports für Aufzeichnungen nicht mehr möglich ist. Die hardwarebasierten Aufzeichnungstechniken der klassischen Netzwerkforensik sind somit genau wie die bisher genutzten Analysemöglichkeiten zum Scheitern verurteilt. Während die statisch geprägten Aufzeichnungstechniken den migrie- renden Systemen nicht folgen können, verhindern neue, bisher nicht in den Analysewerkzeugen implementierte Netzwerkprotokolle die korrekte Auswertung der möglicherweise nur teilweise aufgezeichneten Daten.

Diese Arbeit analysiert die entstandenen Probleme der Netzwerkforensik und stellt neue Mög- lichkeiten vor, auch in virtuellen Umgebungen vollständige Aufzeichnung des relevanten Netz- werkverkehrs durchzuführen, um eine spätere korrekte Auswertung der Daten zu ermöglichen.

1.2 Szenarien

Die nachfolgenden Beispiele spiegeln reale Szenarien wider, die die Schwierigkeiten der Netz- werkforensik in virtuellen Umgebungen aufzeigen.

1.2.1 Speicherung inkriminierter Inhalte in Cloud-Umgebungen

Eine staatliche Ermittlungsbehörde erhält Kenntnis über eine Tauschbörse für kinderpornogra- phische Bilder, Videos und Dokumente. Die Tauschbörse wird in einer Public Cloud konspirativ betrieben, der Zugriﬀ auf die Daten steht nur Teilnehmern zur Verfügung, die eigenes Material hochladen. Der Zugriﬀ auf diese Server erfolgt dabei nicht von beliebigen Clients, sondern nur von Systemen, die innerhalb eines Virtual Private Network (VPN) vernetzt sind. Die beteiligten Systeme sind dabei keine realen Computer, sondern virtuelle Maschinen (VMs) innerhalb der Umgebung. Die durchgeführten Provideranfragen über den relevanten Kunden werden zwar korrekt beantwortet, da die Einrichtung jedoch mit Hilfe falscher Namen und gestohlener Kre- ditkartendaten erfolgt, bieten sich hierdurch keine hilfreichen Ermittlungsansätze. Um weitere Informationen über den Betreiber und die Nutzer erhalten zu können, bestimmen die Ermittler nicht die sofortige Deaktivierung des Accounts, sondern planen die Durchführung einer Server- überwachung, bei der sämtliche Netzwerkdaten aufgezeichnet werden sollen. In Absprache mit dem Provider mietet die Ermittlungsbehörde eigene Server in der Umgebung an und stellt dem

3 1 Einleitung

Provider zusätzlich Aufzeichnungshardware in Form eines Test Access Port (TAP) zur Anbindung am Uplink zur Verfügung.

Der Provider richtet die Aufzeichnung nach den Anforderungen der Ermittlungsbehörde ein und stellt zusätzlich Kontaktpersonen für den schnellen Informationsaustausch bereit. Der verantwortliche Netzwerkforensiker konﬁguriert die Aufzeichnungssysteme wie gewohnt mit Hilfe vorgegebener Filter, um die relevanten Daten aufzeichnen zu können.

Nachdem die Aufzeichnung einige Stunden erfolgreich funktioniert, bricht die Paketaufzeichnung unvermittelt zusammen. Eine Überprüfung des überwachten Systems zeigt jedoch weiterhin, dass Netzwerkdaten übermittelt werden, allein die Aufzeichnungssysteme erhalten keinerlei neue Daten. In hektischer Absprache zwischen Provider und Ermittlungsbehörde stellt sich heraus, dass die Filterung anhand der IP-Adresse nicht ausreichend war, da der Kunde in der Weboberﬂäche des Anbieters die VM neu konﬁguriert hat.

Die notwendige Anpassung der Filterregeln auf das gewöhnlich eindeutige Merkmal der Media Access Control (MAC)-Adresse liefert nach einem Ausfall von drei Stunden erneut Daten an das Aufzeichnungssystem. Allerdings scheitert auch diese Aufzeichnung jedoch wieder nach kurzer Zeit, obwohl die Tauschbörse weiterhin erreichbar ist. Eine zeitaufwändige, manuelle Analyse durch den Providers zeigt nach mehr als zwei Stunden, dass dieses Mal die VM gestoppt und auf einen anderen Server migriert wurde. Erneut muss die Aufzeichnung nach einem Ausfall von mehr als vier Stunden manuell wiederhergestellt werden.

Die spätere Analyse der lückenhaft aufgezeichneten Daten liefert kaum nutzbare Ergebnisse, da die verwendeten Softwareumgebungen zur Analyse der Netzwerkdaten die aufgezeichneten Daten nicht interpretieren können. Innerhalb der virtuellen Umgebung wurde mit Virtual eXtensible LAN (VXLAN) ein Tunnelprotokoll zur Implementierung eines Overlay-Netzwerks genutzt. Die eingesetzte Software hat bisher keinen Interpreter für diese Netzwerkdaten, so dass auch anhand der vorliegenden Daten keine neuen Informationen extrahiert werden können.

1.2.2 Datenmissbrauch im Unternehmensnetzwerk

Ein börsennotiertes Unternehmen produziert elektronische Sicherheitssysteme für die Automobil- industrie und besitzt weltweite Niederlassungen. Die Angst vor Wirtschaftsspionage ist in diesem Sektor hoch, so dass von der Unternehmensleitung besonderes Augenmerk auf Verschwiegenheit und den vertraulichen Umgang mit Unternehmensdaten gelegt wird. Durch die Organisations- struktur ist die IT-Abteilung in die Bereiche Security, Communication, Storage, User Support und Development unterteilt.

4 1.2 Szenarien

Seit einiger Zeit registriert das Security-Team periodische Zugriffe auf ausländische Server, jeweils mit einer kurzen, ausgehenden Datenübertragung. Allerdings erfolgen diese Zugriffe aus unterschiedlichen Regionen des weltweit operierenden Unternehmens, so dass ein Zusammenhang auf den ersten Blick nicht erkennbar ist. Sowohl das Team des Supports, die neben den Client-PCs auch die heterogene Serverlandschaft betreuen, als auch das Netzwerkteam ist nicht in der Lage, diese Zugriffe korrekt zuzuordnen. Weder sind die genutzten Hostnamen noch die IP-Adressen eindeutig aufzufinden, die wechselnden Quellen des Datenaustauschs verkomplizieren zudem die Fehlerbehebung.

Aus diesem Grund wird das Computer Emergency Response Team (CERT) informiert, welches bei der Analyse eine vom Development-Team installierte Private Cloud auﬃndet. Innerhalb dieser Umgebung können Entwickler eigenständig Projekte starten und verwalten, so dass diese Umgebung außerhalb des internen Unternehmensnetzwerks läuft. Um nun den genauen Urheber und den Inhalt der Transfers zu ﬁnden, soll der Netzwerkverkehr aufgezeichnet werden, um ihn anschließend analysieren zu können.

Die Aufzeichnung der Daten wird jedoch durch die wechselnden Lokationen erschwert, jedes Mal, wenn die Firewallsysteme den Datentransfer bemerken, muss das Aufzeichnungssystem manuell an die neue Quelle angepasst werden. Die Filterung aller Daten am zentralen Router ist wegen der fehlenden Identiﬁkationsmerkmale angedacht, aufgrund des hohen Durchsatzes und der so entstehenden Datenmengen von mehr als 9 Terabyte am Tag jedoch nicht umsetzbar.

1.2.3 Bewertung

Die beiden Beispiele zeigen das Versagen klassischer netzwerkforensischer Methoden in virtuellen Umgebungen. Dabei ist es unerheblich, ob die virtuelle Umgebung durch einen großen Provider in Form einer Public Cloud oder durch ein Unternehmen als Private Cloud angeboten wird. Sobald eine Virtuelle Maschine (VM) innerhalb eines virtuellen Netzwerks läuft, scheitern sämtliche bisher genutzten Aufzeichnungstechniken sowie Filter- und Analysemöglichkeiten.

Das Beispiel aus Abschnitt 1.2.1 zeigt, dass die im Rahmen von Serverüberwachung durchgeführ- ten Maßnahmen auf ein klassisches RZ ausgelegt sind. Hier ist die Administrationsmöglichkeit für Kunden eingeschränkt, IP-Adressen können nicht oder nur eingeschränkt verändert werden und ein Neustart des Servers verändert nicht die Netzwerkumgebung. Eine Migration auf andere Ser- ver, initiiert vom Kunden selbst, ist ebenfalls nicht möglich. In diesen Fällen sind die bekannten netzwerkforensischen Ansätze ausreichend und zielführend. Sobald jedoch das statische Umfeld verlassen und eine neue, virtuelle Umgebung genutzt wird, scheitern sowohl die Aufzeichnung als auch die Analyse mit den bekannten Methoden.

5 1 Einleitung

Die Aufzeichnung scheitert, da nicht direkt an der VM aufgezeichnet und zusätzlich nicht auf Veränderungen der Umgebung reagiert werden kann. Zusätzlich beinhalten die am Uplink gespeicherten Daten viele irrelevante Netzwerkpakete, die die Aufzeichnung aufblähen und Platz zur Speicherung verbrauchen. Die Analyse scheitert, da die neuen Netzwerkprotokolle die reinen Nutzdaten erneut kapseln und zusätzlich die Ziel- und Quelladressen auf den Transitstrecken zwischen den Systemen ändern. Ohne korrekte Interpretation dieser Overlayprotokolle sind die darin übertragenen Nutzerdaten nicht identiﬁzierbar.

Das Beispiel aus Abschnitt 1.2.2 zeigt deutlich, dass auch innerhalb gut aufgestellter Unter- nehmen Probleme bei der Analyse fremdadministrierter Cloud-Umgebungen auftreten können. Die Nutzung des physischen Unternehmensnetzwerks als reines Transportmedium für eine (wenn auch) private Cloud-Lösung ist teilweise ohne Anpassung durch zuständige Netzwerkadministra- toren möglich. Die internen Abläufe innerhalb dieser Cloud-Umgebung sind nicht transparent und somit schwer zu erkennen.

Die Flexibilität der virtuellen Maschinen in solchen Umgebungen ist wesentlich höher als in traditionellen Netzwerken. Systeme könnten im laufenden Betrieb migriert oder gestoppt und an einem anderen Standort neu gestartet werden. Die notwendigen Netzwerkanpassungen erfolgen automatisiert innerhalb der Cloud, eine manuelle Anpassung ist nicht notwendig.

Um diese Daten forensisch analysieren zu können, ist diese Flexibilität ein KO-Kriterium. Klas- sische Aufzeichnungssysteme sind nicht in der Lage, schnell genug auf Änderungen zu reagieren. Innerhalb einer virtuellen Umgebung ist die Nutzung dedizierter Hardware zudem unmöglich. Eine punktgenaue Filterung der Daten hätte in diesem Fall das Massenproblem der 9 Terabyte pro Tag vermieden. Eine automatisierte Anpassung hätte schnell genug auf die dynamische Umgebung reagieren können.

1.3 Bedeutung der Problemstellung

Serverüberwachungen oder formal auch eine Server-Telekommunikationsüberwachung (TKÜ) sind bei Vorliegen der rechtlichen Bedingungen (§ 100g Telekommunikationsgesetz (TKG)) häu- fig eingesetzte Techniken von Strafverfolgungsbehörden, um zusätzliche Daten bei der Aufklärung von Straftaten zu gewinnen. Die klassische Server-TKÜ ist dabei einfach umzusetzen. Da sich der Aufbau und die Netzwerkkonfiguration im Normalfall nicht ändert, ist der gesamte Aufzeich- nungsprozess statisch. Die Netzwerkverbindung des betroffenen Servers kann quasi kopiert werden, um alle ankommenden und abgehenden Daten an ein Aufzeichnungssystem zu übertragen. Hierdurch erhält ein Ermittler zusätzliche Hinweise über Kommunikationsteilnehmer, administrative Zugriffe und möglicherweise auch die übertragenen Daten, sofern keine Verschlüsselung gewählt wurde.

6 1.3 Bedeutung der Problemstellung

Innerhalb virtueller Umgebungen ändert sich dies. Die virtuellen Systeme können wesentlich leichter von einem physischen Server auf einen anderen verschoben werden; die notwendigen Anpassungen des Netzwerks innerhalb der virtuellen Umgebung erfolgt dabei automatisiert, so dass keinerlei manuelle Eingriﬀe notwendig sind. Die statischen Aufzeichnungssysteme können dieser Migration nicht automatisch folgen, sondern verlangen eine manuelle Anpassung.

Diese Anpassungen sind in den hochperformanten und dynamischen virtuellen Umgebungen jedoch nicht leistbar. Die Gefahr von Datenverlust oder unvollständigen Aufzeichnungen ist so ohne neue Aufzeichnungsmethoden fortwährend gegeben. Diese Methoden müssen sowohl die Behand- lung neuer Netzwerkprotokolle als auch die Virtualisierung der Netzwerke und deren Trennung zwischen logischen und physischen Bereichen beachten. Schon die ehemals einfache Identiﬁ- zierung des Zielsystems anhand der genutzten Netzwerkanschlüsse ist nun deutlich schwerer durchzuführen. Auch die Anbindung der hardwarebasierten Aufzeichnungstechniken ist in reinen Softwareumgebungen nicht mehr möglich.

Die Diversität virtueller Umgebungen verhindert eine allgemein nutzbare Implementierung einer netzwerkforensischen Lösung. Erst eine Analyse und die Entwicklung eines grundsätzlichen Vorgehensmodells bietet ausreichend Sicherheit, um die Herausforderungen der virtuellen Netz- werkumgebungen zu beachten und neue Lösungswege für die Netzwerkforensik in virtuellen Um- gebungen bereitzustellen. Dies bietet auch für die Zukunft die Möglichkeit, die Vorteile einer Server-TKÜ im virtuellen Umfeld für die Aufklärung von Straftaten zu nutzen. Auch im Bereich der Fehleranalyse und -behebung können die vorgestellten Lösungen eingesetzt werden.

Die Notwendigkeit dieser Realisierung wird besonders deutlich, wenn man den Prognosen glaubt, die von einem weiteren Wachstum des Cloud-Computings und somit auch den virtuellen Um- gebungen ausgehen. So schätzt der Global Cloud Index von Cisco, dass Anwendungen in der Cloud bis zum Jahr 2019 mit 10,4 Zettabyte insgesamt 83% des weltweiten Datenverkehrs aus- machen [Cis15b]. Dieser Datenverkehr und das notwendige Management lassen sich ohne hochautomatisierte Umgebungen nicht mehr handhaben. Dies wird erst durch den Einsatz virtueller Umgebungen und somit auch der virtuellen Netzwerke möglich.

Ohne geeignete Maßnahmen ist die Netzwerkforensik in diesen virtuellen Umgebungen nicht mehr möglich, so dass die hier vorhandenen Daten nicht für mögliche Untersuchungen zur Verfügung stehen.

7 1 Einleitung

1.4 Ziele der Arbeit

Die Notwendigkeit der Netzwerkforensik wird deutlich, wenn man die Frage stellt, wo überall Netzwerke existieren und warum sie eingesetzt werden. [KC14] liefert die einfache und prägnante Antwort:

The oft-repeated statement that ”we live in a connected world” perhaps best captu- res, in its simplicity, why networks have come to hold such interest in recent years.

Die häuﬁge Nutzung der Netzwerke sowie die ausgetauschten Daten bieten für forensische Arbei- ten meist einen erheblichen Informationsgewinn. Häuﬁg kann erst durch Auswertung von Netz- werkdaten in Kombination mit extrahierten Daten eine vollständige Klärung des untersuchten Sachverhalts erfolgen.

Dabei gehören die statischen Infrastrukturen im RZ der Vergangenheit an, Provider benötigen nun zur Wahrung der Wettbewerbsfähigkeit dynamische Systeme, die ﬂexibel an Kundenwünsche angepasst werden können. Dies ist nur mit virtuellen Umgebungen realisierbar. Auch in diesen Umgebungen sind forensische Arbeiten notwendig, dabei kommt der Netzwerkforensik eine wach- sende Bedeutung zu, da der Zugriﬀ auf die entfernt laufenden Systeme und Umgebungen immer über ein Netzwerk erfolgt.

Die Vergangenheit hat gezeigt, dass Cloud-Umgebungen immer wieder Ziele von Angriffen werden, sei es, um Kundensysteme direkt anzugreifen oder interne Systeme zu kompromittieren. Genauso häufig werden virtuelle Systeme in diesen Umgebungen genutzt, um illegale Aktivitä- ten zu verschleiern und so das Risiko einer Entdeckung zu minimieren. Der Auswertung kommt dabei eine erhöhte Bedeutung zu, um weitere Angriffe möglichst zu verhindern. Allerdings sind die forensischen Möglichkeiten in diesen Bereichen noch sehr beschränkt.

Diese Arbeit stellt die entstehenden Schwierigkeiten der Netzwerkforensik, die durch die tech- nischen Rahmenbedingungen innerhalb einer Cloud-Umgebung auftreten können, detailliert vor. Diese Analyse verdeutlicht die Notwendigkeit neuer Technologien, Vorgehensweisen und Metho- den. Auf Basis einer Anforderungsuntersuchung wird ein neues Vorgehensmodell für die Auf- zeichnung, Speicherung und Analyse von Netzwerkdaten innerhalb virtueller Umgebungen beschrieben. Dieses Modell wird anschließend genutzt, um in zwei unterschiedliche Umsetzungen von virtuellen Netzwerken die Eignung zu analysieren.

Als Ergebnis steht ein Prozess zur forensischen Arbeit in virtuellen Umgebungen zur Verfügung, welcher mit einer Identiﬁzierung aller relevanten Komponenten beginnt und die notwendige Auf- zeichnung der Netzwerkdaten eines Zielsystems implementiert. Mit Hilfe von Monitoringtech- niken werden die auftretende Änderungen dynamischen überwacht, so dass die Aufzeichnung

8 1.5 Übersicht automatisch angepasst wird und eine Analyse der anfallenden Netzwerkdaten innerhalb eines Cloudsystems ermöglicht.

1.5 Übersicht

Nach dieser Einleitung werden in Kapitel 2 Grundlagen zu relevanten Teilbereichen der Arbeit vorgestellt. Dies umfasst die allgemeine Netzwerktechnik, das Cloud-Computing sowie die Netz- werkvirtualisierung mit Hilfe von Overlaytechniken, SDN und NFV. Eine detaillierte Beschreibung der Netzwerkforensik schließt dieses Kapitel ab.

Kapitel 3 liefert ein Überblick über den Stand der Technik hinsichtlich der aktuellen netzwerkforensischen Möglichkeiten in der Cloud und stellt den aktuellen Forschungsstand zu den Themen Netzwerk- und Cloud-Forensik dar.

Die klassischen Methoden der Netzwerkforensik sind bei der Analyse virtueller Netzwerke fehler- anfällig oder sogar nutzlos. Ursächlich hierfür sind unterschiedlichste Probleme, die alle Phasen der Netzwerkforensik betreﬀen. Diese Probleme werden in Kapitel 4 detailliert beschrieben und ihre Auswirkungen auf die netzwerkforensische Arbeit analysiert.

Forensische Untersuchungen verlangen ein strukturiertes Vorgehen, um korrektes und gerichts- verwertbare Ergebnisse zu erhalten. Daher existieren unterschiedliche Rahmenbedingungen, anerkannte Standards und allgemein gültige Vorgaben, die dieses strukturierte Vorgehen unterstützen. Diese resultieren aus unterschiedlichen Anforderungen, deren Einhaltung eine korrekte Arbeit erleichtern. Kapitel 5 beschreibt allgemeine Anforderungen und führt in Verbindung mit speziellen Anforderungen der Netzwerkforensik in virtuellen Netzwerken zu einem Anforderungsmodell zusammen.

Vorgehensmodelle bieten Ermittlern Handlungsanweisungen und Hilfen bei der Durchführung forensischer Arbeiten. Während für die klassische IT-Forensik und auch für die Netzwerkforensik unterschiedliche Modelle existieren, ist für netzwerkforensische Analysen in virtuellen Umgebun- gen kein geeignetes Modell vorhanden. Kapitel 6 beschreibt ausgewählte Modelle, analysiert den Einsatzzweck in virtuellen Umgebungen und untersucht mögliche Schwächen. Darauf aufbauend wird mit dem Virtual Network Forensic Process (VNFP) ein neues Vorgehensmodell entwickelt, welches Hilfestellung bei netzwerkforensischen Arbeiten in virtuellen Umgebungen bietet.

Das VNFP deﬁniert Phasen, die auf die Besonderheiten der Netzwerkforensik in virtuellen Um- gebungen eingehen. Kapitel 7 beschreibt ausgehend von diesem Modell eine Untersuchung virtueller Switchen auf Basis von Open vSwitch (OVS). Dies umfasst die Analyse der netzwerkforensischen Möglichkeiten sowie die Beschreibung eines geeigneten Lösungsmodells, welches die

9 1 Einleitung

Aufzeichnung und Speicherung der Netzwerkdaten der mit OVS vernetzten Systeme ermöglicht. Mit Hilfe dieser als OVSF bezeichneten Lösung existiert eine Umgebung, die vollständige Daten- aufzeichnung von virtuellen Switchen implementiert und so die Analyse dieser Daten ermöglicht.

Kapitel 8 untersucht die Besonderheiten und Möglichkeiten der Netzwerkforensik in hochdynamischen Umgebungen auf Basis von OpenFlow. Dabei wird mit ForCon eine Lösung vorgestellt, die auf die controllergestützte Dynamik in OpenFlow-Netzwerken reagieren kann und mit Hilfe eines agentenbasierten Ansatzes für diese Umgebungen eine vollständige Datenaufzeichnung implementiert.

Die unterschiedlichen Möglichkeiten und erarbeiteten Techniken werden im Kapitel 9 hinsichtlich ihres Einsatzzwecks evaluiert. Diese Evaluierung umfasst den Nachweis der Korrektheit, den Abgleich mit dem VNFP und die Validierung in einer Simulationsumgebung auf OpenStack- Basis. Der Schwerpunkt dieser Arbeit liegt auf der Netzwerkforensik im Sinne von Strafverfol- gungsbehörden. Daher erfolgt in diesem Kapitel ebenfalls eine Bewertung der antiforensischen Möglichkeiten.

Kapitel 10 fasst die Arbeit zusammen und gibt einen Ausblick auf oﬀene Themen.

10 2 Grundlagen

Die IT-Forensik in virtuellen Netzwerken berührt unterschiedlichste Bereiche. In diesem Kapi- tel werden die zugrundeliegenden Techniken und Bereiche beschrieben, die konkret mit diesem Themenkomplex verbunden sind. Hierzu gehören neben einer Einführung in Aspekte der Netz- werktechnik auch eine Beschreibung des Cloud-Computings, das auf Basis der virtuellen Netz- werke seine Dienste zur Verfügung stellt und somit unmittelbar von diesen Implementierungen proﬁtiert.

Ein virtuelles Netzwerk ist dabei keine einzelne, klar deﬁnierte Technik, sondern existiert in unterschiedlichen Ausprägungen. Daher werden in diesem Kapitel die Overlayprotokolle sowie die Techniken SDN und NFV detailliert beschrieben und voneinander abgegrenzt.

Nach der Beschreibung der grundlegenden Techniken erfolgt die Deﬁnition und Darstellung der Netzwerkforensik. Dies umfasst neben einer Einordnung in den Bereich der IT-Forensik auch die detaillierte Beschreibung des dreigeteilten netzwerkforensischen Prozesses.

2.1 Netzwerktechnik

Virtuelle Netzwerke bieten viele neue Möglichkeiten für die Verwaltung getrennter Netzwerkbe- reiche. Dabei werden zwar neue Techniken und Protokolle eingesetzt, die entstehenden logischen Netzwerke arbeiten jedoch weiterhin wie klassische Netzwerke. Dieser Abschnitt erläutert die für diese Arbeit relevanten theoretischen Grundlagen, die in Referenzmodellen die Verarbeitung der Netzwerkdaten abbilden, relevante Kommunikationsprotokolle sowie die Hardwarekomponenten, die im Rahmen einer traditionellen Aufzeichnung eine Rolle spielen.

11 2 Grundlagen

2.1.1 Referenzmodelle

2.1.1.1 OSI-Modell

Das OSI-Modell nach Zimmermann [Zim80] stellt ein theoretisches Schichtenmodell dar, welches von der konkreten Verarbeitung unterschiedlicher Protokolle in Netzwerken abstrahiert. Das Modell besteht aus sieben Schichten, die jeweils unterschiedliche Aufgaben wahrnehmen und somit die gemeinsame Nutzung heterogener Techniken und Implementierungen ermöglichen. Jede Schicht deﬁniert dazu Schnittstellen, die eine Kommunikation zu den benachbarten Schichten ermöglichen. Durch dieses theoretische Modell ist es möglich, die Implementierung einer Schicht intern anzupassen, ohne die benachbarten Schichten zu verändern. Tabelle 2.1 verdeutlicht dieses Schichtmodell.

2.1.1.2 TCP/IP-Modell

Das OSI-Modell wurde entwickelt, bevor es die meisten der beschriebenen Netzwerkprotokolle gab. Das TCP/IP-Modell hingegen basiert auf realen Protokollimplementierungen und wurde aufgrund von Empfehlungen des ARPANETs entwickelt. Die im OSI-Modell beschriebenen Pro- tokolle werden heute nicht mehr eingesetzt, so dass das TCP-Modell praxisnäher ist [MS11].

Dabei stellt das TCP/IP-Modell wie in Tabelle 2.1 nicht sieben Schichten bereit, sondern nur vier. Hier werden die unteren zwei Schichten des OSI-Modells zur Netzzugangsschicht zusammengefasst. Ebenso erfolgt eine Zusammenfassung der Schichten 5-7 zur Anwendungsschicht.

2.1.1.3 Hybridmodell

Aufbauend auf dem OSI-Modell und dem TCP/IP-Modell stellt [Tan03] ein Hybridmodell dar. Dieses Hybridmodell besteht aus insgesamt fünf Schichten, die unteren vier Schichten entsprechen den Schichten des OSI-Modells, die Schichten 5-7 werden jedoch zur Anwendungsschicht zusammengefasst.

Tabelle 2.1 stellt die Schichten des OSI-Modells im Vergleich zum TCP/IP-Modell und dem Hybridmodell dar. Eine vollständige Betrachtung dieser beiden Modelle liefert [PC93].

Obwohl das TCP/IP-Modell praxisnäher ist, hat sich bei der Beschreibung der Schichten das OSI-Modell durchgesetzt, so dass Netzwerkkarten als Layer 1, Switche als Layer 2 und Router als Layer 3 Komponenten herstellerübergreifend deﬁniert sind.

12 2.1 Netzwerktechnik

Tabelle 2.1: Referenzmodelle im Vergleich Schicht OSI TCP/IP Hybrid Protokolle 7 Anwendung Anwendung Anwendung HTTP, FTP, DNS 6 Darstellung 5 Sitzung 4 Transport Transport Transport TCP, UDP 3 Vermittlung Internet Vermittlung IP,ICMP 2 Sicherung Sicherung Netzzugang Ethernet, ISDN, UMTS 1 Bitübertragung Bitübertragung

2.1.2 Schichten

Die Kommunikation innerhalb eines Netzwerks erfolgt mit Hilfe von Protokollen. Jedes Protokoll ist dabei einer Schicht zugeordnet. In diesem Abschnitt werden die Aufgaben der Schichten gemäß des OSI-Modells beschrieben, anschließend erfolgt eine Klassiﬁzierung der forensischen Relevanz. Diese beschreibt die Nutzbarkeit der Informationen, die auf dieser Schicht übertragen werden, für netzwerkforensische Arbeiten.

2.1.2.1 Bitübertragungsschicht

Die Bitübertragungsschicht stellt die unterste Schicht des Referenzmodells dar. Hier werden mechanische oder elektrische Parameter deﬁniert, die für die Datenübertragung notwendig sind. So muss im Vorfeld bestimmt werden, wie eine „0“ oder eine „1“ dargestellt wird. Diese Regelung muss auf beiden Seiten des Kommunikationskanals eindeutig sein, da ansonsten die übertragenen Daten falsch interpretiert und fehlerhaft an die Sicherungsschicht weitergegeben würden.

2.1.2.2 Sicherungsschicht

Die Sicherungsschicht garantiert eine fehlerfreie Übertragung, indem fehlerhafte Netzwerkpa- kete verworfen werden. Anhand einer Prüfsumme2 wird auf dieser Schicht festgestellt, ob die Übertragung der Daten fehlerfrei war. Hierzu wird die errechnete Prüfsumme mit der im Paket übermittelten verglichen. Stimmen diese überein, wird das Paket an die nächste Schicht weitergeleitet, andernfalls verworfen. Eine Fehlerkorrektur, z.B. durch Neuanfordern der fehlerhaften Pakete obliegt den höheren Schichten.

2Diese wird auch als Frame Check Sequence (FCS) bezeichnet.

13 2 Grundlagen

Das vorrangige Protokoll dieser Schicht ist Ethernet, andere Protokolle sind Asynchronous Trans- fer Mode (ATM) oder High-Level Data Link Control (HDLC), die jedoch nur in Spezialfällen genutzt werden. Ethernet nutzt 48 Bit lange MAC-Adressen zur Adressierung der Ziel- und Quellgeräte. MAC-Adressen sollten weltweit eindeutig sein, sie setzten sich daher aus dem Her- stellerkennzeichen3 und einer eindeutigen fortlaufenden Nummer des Herstellers zusammen.

Den Aufbau des Ethernetframes zeigt Abbildung 2.1.

Präambel

Abbildung 2.1: Ethernetframe

2.1.2.3 Vermittlungsschicht

Die Vermittlungsschicht übernimmt die Aufgaben der Wegeﬁndung in Netzwerken. Das am häu- ﬁgsten eingesetzte Protokoll der Netzwerkschicht ist das Internet Protokoll (IP). Dieses existiert aktuell in zwei Versionen; Version 4 ist seit Jahren die Standardversion für die Kommunikation in Netzwerken. Tabelle 2.2 beschreibt die Aufgaben der einzelnen Felder und ihre Relevanz in der Netzwerkforensik. Dabei ist die Relevanz immer von der aktuellen Fragestellung abhängig, so dass die aufgeführte Bewertung zwar größtenteils und somit auch für die Arbeit gültig ist, dennoch gibt es unterschiedliche Bewertungen in anderen Fällen.

Tabelle 2.2: Headerfelder IPv4 Headerfeld Größe Aufgabe Relevanz Version 4 VersiondesfolgendenIP-Pakets(hier4) gering InternetHeaderLength 4 LängedesIP-Headers gering TypeofService 8 FestlegenderPriorität gering Length 16 LängedesgesamtenPakets gering Identiﬁcation 16 EindeutigeKennzeichnungdesPakets gering Flags 3 FestlegungderFragmentierung gering FragmentOﬀset 13 Gibt die Position im Paket an, an der ein gering Fragment beginnt Timetolive 8 MaximaleAnzahlvonRouternaufdemWeg gering zum Ziel Protocol 8 FolgeprotokollimPayload hoch HeaderChecksum 16 PrüfsummeüberdengesamtenHeader gering SourceIP 32 IP-AdressederQuelle hoch DestinationIP 32 IP-AdressedesZiels hoch

3Dieser als Organizationally Unique Identiﬁer (OUI) bezeichnete Zeichenkette wird von der Institute of Electrical and Electronics Engineers (IEEE) vergeben.

14 2.1 Netzwerktechnik

Die Einführung einer neuen IP-Version begann 1998 unter dem Namen IPng, später wurde der Namen IPv6 gewählt. Hauptgrund für die Entwicklung war die begrenzte Anzahl nutzbarer IPv4- Adressen, die tatsächlich im September 2015 für den amerikanischen Raum aufgebraucht war [Cur15]. Während IPv4-Adressen in 32-Bit Form zu jeweils vier Oktetten dargestellt werden, erfolgt die Darstellung der 128-Bit langen IPv6-Adressen in hexadezimaler Form. Tabelle 2.3 beschreibt die Aufgaben der enthaltenen Felder.

Tabelle 2.3: Headerfelder IPv6 Headerfeld Größe Aufgabe Relevanz Version 4 VersiondesfolgendenIP-Pakets(hier6) gering TraﬃcClass 8 Prioritätssteuerung gering FlowLabel 20 GenutztfürQualityofService(QoS) gering PayloadLength 16 LängederübertragenenDatenimIP-Paket gering NextHeader 8 IdentiﬁkationdesnächstenHeaders hoch HopLimit 8 Entspricht dem Feld Time-to-live (TTL) des gering IPv4-Headers SourceIP 128 IP-AdressederQuelle hoch DestinationIP 128 IP-AdressedesZiels hoch

Jeder Kommunikationspartner besitzt in seinem Netzwerk mindestens eine eindeutige IP-Adresse, über die eine Verbindung aufgebaut werden kann. Neben der Adressierung eines Endgerätes sind unterschiedliche Klassen von IP-Adressen standardisiert, die eine Adressierung mehrerer Syste- me zeitgleich ermöglichen. Bei IPv4 wird dabei zwischen Unicast4, Multicast5 und Broadcasts6 unterschieden. IPv6 kennt aufgrund der möglicherweise sehr großen Subnetze keine Broadcasts, sondern nutzt Anycasts für diese Zwecke [JD99].

2.1.2.4 Transportschicht

Die Transportschicht implementiert je nach eingesetztem Protokoll eine zuverlässige, dafür jedoch weniger performante, oder eine unzuverlässige, dann jedoch schnellere Möglichkeit des Datenaustauschs.

Das Transmission Control Protocol (TCP) bietet eine zuverlässige und verbindungsorientierte Kommunikation an. Dies gelingt durch die Nutzung von Sequenz- und Acknowledgenummern, die die korrekte Position des Pakets im Datenstrom anzeigen. Der TCP-Header ist in Abbildung 2.2 dargestellt.

4Diese Art wird für die Adressierung eines einzelnen Systems genutzt. 5Hierbei wird eine Teilmenge aller Systeme gleichzeitig adressiert. 6Mit Hilfe von Broadcasts werden Nachrichten an alle Systeme im Subnetz verschickt.

15 2 Grundlagen

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Source Port Destination Port Sequenznumber Acknowledgenumber Oﬀset Length U A P R S F Windows Checksum Urgent Pointer Options PDU

Abbildung 2.2: TCP-Header

Im Gegensatz dazu bietet das User Datagram Protocol (UDP) nur eine verbindungslose, un- zuverlässige Übertragung an. Hierfür werden weniger Informationen benötigt, so dass der Hea- der, wie in Abbildung 2.3 dargestellt, wesentlich weniger Felder benötigt. Durch die geringere Größe des Headers ist der Gesamtoverhead ebenfalls kleiner, dies ermöglicht schnellere Über- tragungen der Daten. UDP wird daher im Bereich von Streamingdiensten, Webradio oder auch Kommunikationsdiensten wie Voice over IP (VoIP) oder Skype eingesetzt.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Source Port Destination Port Length Checksum PDU

Abbildung 2.3: UDP-Header

2.1.2.5 Sitzungsschicht

Die Sitzungsschicht übernimmt Aufgaben der Ablaufsteuerung und -koordination zwischen zwei Systemen. Dies umfasst neben dem Auf- und Abbau von Sessions auch deren Synchronisation sowie die Aufrechterhaltung oder Wiederaufnahme nach Verbindungsabbrüchen. Mit Hilfe von Fixpunkten ist es somit möglich, auch bei kurzfristigen Ausfällen der Verbindung die eigentliche Kommunikation aufrecht zu erhalten [Tan03]. Durch ein Tokenmanagement sichert die Sitzungsschicht die Kommunikation zwischen den Systemen ab, so dass gewährleistet ist, dass keine unberechtigten Anfragen weitergeleitet werden.

2.1.2.6 Darstellungsschicht

Schicht 6 im OSI-Modell wird als Darstellungsschicht bezeichnet und realisiert eine Umsetzung der systemabhängigen Darstellung in eine unabhängige Form. Hierdurch können Daten zwi-

16 2.1 Netzwerktechnik schen Systemen ausgetauscht werden, die eine andere Form der Zeichenkodierung nutzen. Es ist hierdurch möglich, Daten eines Systems mit der ASCII-Kodierung mit einem System mit anderen Kodierung, z.B. der KOI8-U-Kodierung7, auszutauschen. Die angelieferten Daten werden durch die Darstellungsschicht so umgewandelt, dass das System die Daten mit dem geeignetem Zeichensatz passend für das lokale System aufbereiten kann.

Neben der Aufbereitung der Daten werden auf dieser Schicht ebenfalls Methoden der Kom- primierung und Verschlüsselung eingesetzt. Diese Techniken sind auf dieser Schicht eﬀektiver einzusetzen, da hier im Gegensatz zu den unteren fünf Schichten nun die Syntax und Semantik zum ersten Mal relevant werden [Tan03].

2.1.2.7 Anwendungsschicht

Die Anwendungsschicht ist die oberste Schicht im OSI-Modell und stellt die Schnittstelle zu den genutzten Anwenderprogrammen bereit. Diese Programme nutzen Dienste, die diese Schicht bereitstellt, wodurch interne Details über Kommunikationswege und -arten vor dem Anwender verborgen bleiben. Aus forensischer Sicht sind die hier beﬁndlichen Informationen die Wichtigs- ten, da hier Benutzerdaten in die genutzten Protokolle gekapselt werden. Durch Extraktion der jeweiligen Protokollinformationen können diese Nutzerdaten analysiert und für die weitere Aus- wertung genutzt werden. Wie diese Daten übertragen werden, ist von der Anwendungsschicht unabhängig, ob die Daten verschlüsselt oder komprimiert übertragen werden, wird ausschließlich durch die genutzte Anwendung bestimmt. Tabelle 2.4 listet exemplarisch häuﬁg genutzte An- wendungen der Schicht 7 und die Übertragungsart der Daten auf. Klartextübertragungen sind für netzwerkforensische Analysen von hohem Interesse, die Übertragung verschlüsselter Daten bietet meist kaum nutzbare Informationen auf dieser Schicht.

Tabelle 2.4: Einige Protokolle der Anwendungsschicht Protokoll Beschreibung Klartext HTTP HypertextTransferProtocol * HTTPS Hypertext Transfer Protocol Secure SMTP SimpleMailTransferProtocol * IMAP InternetMailAccessProtocol * FTP FileTransferProtocol * SSH Secure Shell VNC VirtualNetworkComputing *

7Eine Zeichenkodierung des kyrillischen Alphabets, welches für die ukrainische Sprache genutzt wird.

17 2 Grundlagen

2.1.2.8 Klassiﬁzierung

Nicht alle Schichten des OSI-Modells sind für forensische Auswertungen gleich wichtig. Hauptziel der meisten forensischen Analysen sind die tatsächlich übertragenen Daten, die auf der Anwen- dungsschicht bereitgestellt werden. Die Nutzbarkeit ist dabei jedoch unmittelbar mit der Art der Übertragung verbunden. Werden die Daten verschlüsselt übermittelt, sind diese Informationen nicht ohne weitere Maßnahmen einsehbar.

Aber auch mit Hilfe der Informationen aus den anderen Schichten ist es dem Forensiker möglich, weitere Details für die Analyse zu gewinnen. Eine Übersicht der einzelnen Schichten des OSI- Modells bezüglich ihrer Relevanz in forensischen Analysen liefert Tabelle 2.5.

Tabelle 2.5: Forensische Relevanz der Schichten des OSI-Modells Nummer Schicht Relevanz 1 Bitübertragung mittel 2 Sicherung hoch 3 Netzwerk hoch 4 Transport mittel 5 Sitzung gering 6 Präsentation gering 7 Anwendung hoch

Anhand der Informationen von Schicht 2 und Schicht 3 können Kommunikationspartner ermittelt werden. Dabei sind die Informationen der Sicherungsschicht vorrangig im Local Area Network (LAN) relevant. Bei netzwerkforensischen Arbeiten mit Systemen, die mit dem Inter- net verbunden sind oder innerhalb größerer Unternehmensnetzwerke genutzt werden, sind die Informationen der Schicht 2 nicht mehr ausreichend, so dass die IP-Adressen von Schicht 3 zusätzlich genutzt werden müssen. Dabei sind vorrangig die Unicasts relevant, Multicast- und Broadcastdatenverkehr beinhalten im Normalfall keine relevanten Informationen.

Die Bitübertragungsschicht ist nur für die Aufzeichnung relevant, hier muss durch die Nutzung einer geeigneten Netzwerkkarte sichergestellt werden, dass alle anfallenden Daten aufgezeichnet werden können.

Die Relevanz der Transportschicht hat sich in den letzten Jahren der Netzwerkforensik verändert. In der Vergangenheit wurden die hier übertragenen Informationen für die Klassiﬁzierung und Filterung der gespeicherten Daten genutzt. Allerdings sind die hier zur Verfügung gestellten Informationen meist nur für die korrekte Übermittlung der Daten, z.B. mit Hilfe der Sequenz- und Acknowledge-Nummern, zuständig. Die Nutzung der Portnummern sind durch Techniken wie Deep Packet Inspection (DPI) weniger relevant geworden. Hierdurch ist es nun möglich, über

18 2.1 Netzwerktechnik

Kommunikationsdetails der Anwendungsschicht auf das genutzte Protokoll zu schließen. Die Portnummer der Transportschicht besitzt daher nur noch eine geringere Aussagekraft. Während DPI-Systeme in der Vergangenheit vorrangig für Bereiche des Intrusion Detection System (IDS), Intrusion Prevention System (IPS) oder Firewalling eingesetzt wurde [KDY+06], [AMN08], wird diese Technik seit einiger Zeit auch in der Netzwerkforensik eingesetzt [WLLS11] und ermöglicht so eine entsprechende Analyse und Bewertung des aufgezeichneten Netzwerkverkehrs [DMBC14].

2.1.3 Hardware

Um Systeme miteinander zu vernetzen, stehen unterschiedliche Hardwarekomponenten zur Ver- fügung. Jede dieser Komponenten übernimmt analog zum OSI-Modell eine bestimmte Aufgabe. Zusätzlich zur vorgestellten Hardware existieren noch weitere Komponenten, die auf unterschiedlichen Schichten arbeiten können und als Middleboxes bezeichnet werden [QTC+13]. Hierzu gehören Firewallsysteme, VPN-Gateways und Proxies.

2.1.3.1 Netzwerkkarte

Die Netzwerkkarte (im Folgenden als Network Interface Card (NIC) bezeichnet) stellt die tat- sächliche Verbindung zwischen Rechner und Netzwerk her. In Abhängigkeit der gewählten Ver- netzungstechnik existieren unterschiedliche NICs mit geeigneten Schnittstellen für das Medium. Die Bitübertragungsschicht führt die notwendigen Anpassungen für das genutzte Medium vor, so dass die Daten korrekt übertragen werden können.

• Kupfer Die Verbindung mittels Kupferanschluss kann auf zwei Arten erfolgen. Die häufigste Versi- on ist die Anbindung über RJ-45, seltener werden Koaxialkabel genutzt. RJ-45 bezeichnet eine Steckverbindung, bei der kleine Kupferadern in festgelegter Reihenfolge aufgelegt sind. Koaxialkabel wurden in der Vergangenheit im Rahmen von 10BASE2 oder 10BASE5 eingesetzt. Heutzutage wird es eher für die Übertragung von Hochfrequenzsignalen und für Breitbandnetzwerke genutzt. So übertragen Kabelnetzbetreiber über die verlegten Ka- bel neben Fernseh- und Radiosignalen ebenfalls Signale zur Internetanbindung gemäß der Spezifikation Data Over Cable Service Interface Specification (DOCSIS). Weitere Vernet- zungsstandards wie RJ-11, RJ-21 oder RS-232 verlieren immer mehr an Bedeutung.

• Lichtwelle Lichtwellenleiter werden vorrangig im Backbonebereich eingesetzt. Die Daten werden als optische Signale übertragen und durch die Netzwerkkarte in elektronische Signale umge-

19 2 Grundlagen

wandelt. Glasfaserkabel ermöglichen die Nutzung sehr hoher Übertragungsraten, so dass entsprechende NICs verstärkt im Serverumfeld eingesetzt werden [LLK+10].

• WLAN Wireless LAN (WLAN)-Karten werden eingesetzt, um die Daten über Funk zwischen zwei Teilnehmern zu übertragen. Erste Verbreitung fanden WLAN-Karten in mobilen Endgerä- ten, heutzutage ﬁnden sie sich auch in immer mehr Desktop-PCs, da das Verlegen von Kabeln bei der Nutzung von WLAN entfällt. Das IEEE hat mit dem Standard IEEE 802.11 genaue Details zu unterschiedlichen Implementierungen von WLAN-Techniken vorgegeben.

2.1.3.2 Switch

Ein Switch arbeitet auf Schicht 2 und wird genutzt, um mehrere Systeme miteinander zu vernetzen. Er leitet die ankommenden Netzwerkpakete im Gegensatz zu einem Hub8 zielgenau an den korrekten Port weiter. Die richtige Zuordnung zwischen Port und Endgerät erfolgt anhand der MAC-Adressen. Der Switch lernt diese Adressen, in dem er von den ankommenden Paketen die Quell-Adresse extrahiert und zusammen mit dem Port, an dem dieses Paket ankam, in der sogenannten Forwarding Database (FDB) oder Content Addressable Memory (CAM)-Tabelle speichert. Durch die Kommunikation in einem Netzwerk lernt der Switch somit nach und nach die korrekte Zuordnung für alle aktiven Ports. Sofern er ein Paket erhält, welches nicht korrekt zugeordnet werden kann, leitet der Switch das Paket an alle aktiven möglichen Zielports weiter.

Es existieren zwei grundsätzliche Weiterleitungsstrategien, die sich in der Qualität der Paketver- arbeitung und somit in der Gesamtgeschwindigkeit unterscheiden.

• Store-and-Forward Der Switch liest erst das komplette Netzwerkpaket ein und speichert es im internen Puﬀer. Erst dann wird das Paket vollständig analysiert, in dem die Korrektheit des Frames anhand der Prüfsumme überprüft wird. Erst dann wird die Zieladresse extrahiert und das Paket weitergeleitet. Vorteil dieser Technik ist, dass keine defekten Frames weitergeleitet werden, dafür steigt aber die Verarbeitungszeit und somit die Latenz im Netzwerk an [PDM+03].

• Cut-through Im Gegensatz zum Store-and-Forward-Prinzip speichert der Switch beim Cut-Through- Ansatz nicht den gesamten Frame, sondern analysiert das ankommende Netzwerkpaket sofort. Sobald die Zieladresse eingelesen wurde, wird das Paket unmittelbar weitergeleitet. Die Verarbeitungsgeschwindigkeit im Netzwerk steigt somit an, der Gesamtdurchsatz kann jedoch aufgrund der Weiterleitung und Neuanforderung defekter Pakete schlechter werden [Yan12].

8Ein Hub leitet alle ankommenden Pakete an alle aktiven Ports weiter.

20 2.1 Netzwerktechnik

Aktuelle Verfahren nutzten meist eine Kombination dieser Techniken, die als adaptive Verfahren bei Überschreitung vorgegebener Grenzwerte der Fehlerrate von Cut-Through auf Store-and- Forward wechseln [Odo13].

2.1.3.3 Router

Router arbeiten auf Schicht 3 des OSI-Modells und leiten Pakete, die in andere Netzwerke transportiert werden müssen, weiter. Die Entscheidung, ob ein Paket über einen Router geleitet werden muss, wird anhand der IP-Adresse und der zugehörigen Subnetzmaske bestimmt. Sofern der Rechner feststellt, dass sein Ziel nicht im gleichen Subnetz erreichbar ist, wird das Paket an den Router gesandt, der es anhand seiner Routingregeln verarbeitet. Das Paket kann an das Ziel zugestellt, an einen anderen Router gesandt oder auch verworfen werden.

Um jederzeit die korrekten Wege zum Ziel zu kennen, kommunizieren Router untereinander mit Hilfe von Routingprotokollen. Diese Protokolle ermöglichen es den Routern, sukzessive die Netzwerktopologie zu erfahren. Die Umsetzung eines Routingprotokolls basiert dabei meist auf einem der folgenden Verfahren:

• Distance-Vekor Basierend auf dem Bellman-Ford-Algorithmus [Bel56] und [FF62] berechnen Router, die nach dem Distance-Vektor-Verfahren arbeiten, ihre Routingtabellen anhand von Informa- tionen, die sie von ihren direkten Routingnachbarn erhalten. Hierdurch kann ein Router sukzessive die Topologie des Netzwerks berechnen und die günstigsten Wege zum Ziel fest- stellen. Kein Router hat hierbei vollständige Kenntnisse aller Routingpfade inklusive der jeweiligen Metriken. Beispiele für Routingprotokolle nach dem Distance-Vector-Verfahren sind das Routing Information Protocol (RIP) [Mal98] oder das Interior Gateway Routing Protocol (IGRP) [Cis15d].

• Link-State Das Link-State-Verfahren basiert auf dem Shortest-Path-First-Algorithmus nach Dijkstra [Dij59]. Im Gegensatz zu den Distance-Vektor-Verfahren versendet hier ein Router sein gesamtes Wissen über die Topologie. Hierzu gehören die jeweiligen Router und die Metriken für den Weg zu diesem Router. Aus diesen Informationen kann ein anderer Router nun die günstigsten Wege berechnen. Jeder Router erhält somit globale Zustandstabellen, die nur bei Änderungen angepasst werden [KR08]. Beispiele für Link-State-Protokolle sind Open Shortest Path First (OSPF) [Moy98] oder Intermediate System to Intermediate System (IS-IS) [Ora90].

[BD15] beschreibt neben den oben aufgeführten Komponenten und den Middleboxes noch IDS und IPS sowie Spezialserver, die netzbasierte Dienste wie Dynamic Host Conﬁguration Proto-

21 2 Grundlagen col (DHCP) oder Domain Name System (DNS) anbieten. Diese Systeme bearbeiten Pakete auf unterschiedlichen Schichten und sind nicht unmittelbar für ein funktionsfähiges Netzwerk notwendig. Im Rahmen von sicherheitskritischen Umgebungen sind diese Komponenten jedoch von hoher Bedeutung.

2.2 Cloud-Computing

Erste Ansätze des Cloud-Computings sind im Jahr 1999 erkennbar, als die Firma SalesForce.com nutzbare Anwendungen über eine Internetseite ermöglichte [VVE10]. Die breite Öﬀentlichkeit konnte erstmals im Jahr 2006 auf Cloud-Umgebungen zugreifen, als Amazon EC2 die Nutzung gehosteter, virtuelle Maschinen ermöglichte [aws06]. Während zu Beginn nur wenige Möglich- keiten zur Nutzung existieren, entstehen seitdem immer mehr Implementierungen und Anbieter des Cloud-Computings [Bar15]. Die Prognosen der Umsatzentwicklung des Cloud-Computings deuten, wie in Abbildung 2.4 dargestellt, darauf hin, dass auch in den nächsten Jahren ein Bedarf an leistungsfähigen Cloud-Umgebungen gegeben ist.

Der Grund im Erfolg dieser Umgebungen gründet auf unterschiedlichen Aspekten, die in [MG11] wie folgt deﬁniert sind:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of conﬁgurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management eﬀort or service provider interaction.

140000

120000 121397

104917 100000 90233 80000 77186

65513 60000 55108 45801 40000 37619 30533 24438 20000 19286 15504 12555

0 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020

Abbildung 2.4: Prognostizierte Entwicklung des Umsatzes im Cloud-Computing, [PMT13]

22 2.2 Cloud-Computing

In diesem Abschnitt werden diese Eigenschaften und verbundene Begriﬄichkeiten deﬁniert. Die Bereitstellung cloudbasierter Umgebungen bedingt eine Änderung der Rechenzentrumsarchitek- tur, so dass eine Beschreibung der Hard- und Software diese Übersicht vervollständigt.

2.2.1 Eigenschaften

Der IT-Betrieb umfasst neben dem Vorhalten der Hardware für Server oder Netzwerke auch die Aufgaben der Konﬁguration und Administration benötigter Software sowie die Anpassung an lokale Gegebenheiten. Vorteile hierbei sind die Hoheit über die anfallenden Daten, Klarheit über Speicherorte und -arten sowie die Flexibilität bei Erweiterungen oder Änderungen. Erkauft werden diesen Vorteile durch ein erhöhtes Kostenaufkommen für IT-Personal und notwendige Ressourcen einschließlich regelmäßiger Reinvestitionen. Durch Nutzung cloudbasierter Umge- bungen ändert sich diese Zuordnung weg von einer eigenständigen Administration hin zu einer Nutzung angemieteter Systeme.

Der Grundgedanke des Cloud-Computing basiert darauf, dass der Anbieter (nach [SWC12] auch Cloud Service Provider (CSP) genannt) seinen Kunden Rechenleistung oder Speicherplatz zur Verfügung stellt. Der Kunde kann je nach Auswahl die Rechenleistung eigenständig administrieren oder die Aufgabe an den CSP outsourcen. Der Provider stellt dem Kunden anfallende Kosten für die tatsächliche Nutzung der Ressourcen zur Verfügung und übernimmt dafür die Reinvestition geeigneter Hardware und die Administration der Basisumgebung.

Der Kunde kann dabei zwischen unterschiedlichen Aufteilungen wählen, die sich am Grad der Ein- ﬂussmöglichkeit orientiert. Hierdurch entsteht das in Abbildung 2.5 dargestellte Schichtenmodell, welches auch als Cloud-Stack bezeichnet wird [Ste11].

Anzahl Endnutzer der Implementierungen

Entwickler

Administatoren

Möglichkeiten der Administration

Abbildung 2.5: Cloud-Stack, in Anlehnung an [Sha12]

• Infrastructure-as-a-Service Mit Infrastructure-as-a-Service (IaaS) wird die untere Schicht im Cloud-Stack bezeichnet.

23 2 Grundlagen

Diese bildet somit die Basis für alle darauf aufbauenden Dienste innerhalb des Cloud- Computing.

Der Grundgedanke hinter IaaS basiert auf einer Abkehr der klassischen IT-Infrastruktur, die meist aus dem Betrieb von selbständig erworbener Hard- und Software besteht. IaaS stellt dem Nutzer virtualisierte IT-Infrastrukturen zur Verfügung, in denen er Speicher, Netzwerke oder Server für seine Zwecke nutzen kann. Durch die Nutzung von IaaS entfällt die Beschaﬀung sowie die Reinvestition der Hardware; der eigene Energie- und Platzbedarf sinkt, da die benötigten Systeme nun angemietet werden können.

Diese Systeme werden von einem Provider zur Verfügung gestellt und gewartet, so dass für den Nutzer das Hauptaugenmerk auf der Administration liegen kann. In Verbindung mit dieser Fokussierung bieten die im Folgenden beschriebenen Aspekte eine größere Flexibilität und somit weitere Vorteile, die im Rahmen der klassischen IT-Umgebung nur schwerlich realisierbar sind [Bre12].

– Abfangen von Leistungsspitzen durch Hinzubuchen weiterer Ressourcen

– Freigeben nicht benötigter Ressourcen

– Bezahlung der benötigten Ressourcen

– Bereitstellung neuer Systeme

Innerhalb der virtuellen Umgebung existieren für den Nutzer nur wenige Einschränkun- gen. Auf den virtuellen Servern kann er eigenständig weitere Applikationen installieren, Speicherplatz zuteilen und Sicherheitsregeln etablieren, analog zu Arbeitsschritten, die im Rahmen der Administration von klassischen IT-Strukturen möglich sind.

• Platform-as-a-Service Während IaaS-Umgebungen von der Hardware abstrahieren und den Nutzer von der Rein- vestition und Konﬁguration entbinden, abstrahiert Platform-as-a-Service (PaaS) auch von der Konﬁguration eingesetzter Betriebssysteme und von der Administration unterschiedlicher Anwendungsumgebungen.

Nach [BKNT11] richtet sich dieser Service verstärkt an Entwickler und nicht an Endkunden. Die Entwickler können diese Umgebung nutzen, um ihre Projekte zu testen, zu kombinieren oder Endanwendern bereitzustellen. Hierdurch ist es möglich, sich auf die originäre Aufgabe des Entwickelns zu konzentrieren, da die Komplexität der Betriebssystemschicht vollständig verborgen bleiben. Weitere Investitionen in die Lauﬀähigkeit von Entwicklungs-, Test- oder Produktivumgebungen sind ebenfalls nicht notwendig.

24 2.2 Cloud-Computing

Die auf Basis von PaaS entwickelten Anwendungen werden den Kunden möglicherweise in Form von SaaS angeboten.

• Software-as-a-Service Unter Software-as-a-Service (SaaS) versteht man nach [BKNT11]

Software-Anwendungen in der Cloud, die den Endkunden direkt adressieren [...] Auf der Kundenseite entfällt in dieser Klasse die lokale Software-Installation und mithin auch die Bereitstellung der erforderlichen Ressourcen.

Die dabei zur Verfügung gestellten Softwareanwendungen sind diversitärer Natur und in einer Vielzahl von Ausprägungen vorhanden. Neben einfachen Webanwendungen existieren auch komplexe Softwareprodukte zur Verwaltung von Kundendaten, -beziehungen oder den Unternehmensressourcen [sof13].

Im Unterschied zu den vorherigen Services steht dem Endanwender nur die reine Anwen- dung zur Verfügung. Sämtliche Details wie Administration oder Konﬁguration obliegen dem Betreiber des Services. Dies bietet für den Nutzer einen direkten Komfort, da für diese Aufgaben kein weiterer Aufwand betrieben werden muss. Erkauft wird dieser Kom- fort jedoch durch die fehlende Flexibilität im Zusammenhang mit der Anwendung und möglichen Anpassungen.

Neben diesen Implementierungen existieren nach [ZH13] noch viele weitere Ausprägungen von Services, die auch unter dem Begriﬀ Everything-as-a-Service zusammengefasst werden.

2.2.2 Hardwareentwicklung

Die Bereitstellung cloudbasierter Dienste verlangt vom CSP Veränderungen in der RZ-Architektur. Bisherige, eher statisch geprägte Umsetzungen sind nicht in der Lage, den gestiegenen Anfor- derungen gerecht zu werden. Dies betriﬀt nicht nur die Server, die die Anwendungen betreiben, sondern auch das Netzwerk, welches die genutzten IT-Systeme miteinander verbindet. In diesem Abschnitt werden die für den Betrieb notwendigen Veränderungen erläutert.

2.2.2.1 Server

In der Vergangenheit bestand die genutzte Serverlandschaft aus aufwändig gepﬂegten, einzelnen Serversystemen, die jeweils für einen bestimmten Zweck bereitgestellt wurden. Diese Systeme wurden manuell gewartet, überwacht und an die aktuelle Situation angepasst.

25 2 Grundlagen

Die Entwicklung des Cloud-Computings veränderte diese Arbeitsweise fundamental. Nun werden nicht mehr separate Server betrieben, sondern leistungsfähige Komponenten bereitgestellt, die wiederum VMs betreiben. Je nach Implementierung nutzen Provider sehr performante einzelne Systeme9 oder setzen massenhaft Standard-Hardware ein, die bei Problemen schnell und einfach ausgetauscht werden.

Die Anwendungen, die klassischerweise auf einzelnen, ausgewählten Servern liefen, werden nun virtualisiert betrieben. Die Daten, die eine solche VM nutzt, werden dabei auf zentralen Spei- chersystemen vorgehalten. Tritt nun ein Problem mit einer VM auf, wird nicht mehr aufwändig analysiert, was zum Fehler führte, sondern kurzerhand die betroﬀene VM terminiert und der Dienst auf einer anderen VM auf einem anderen Host neu gestartet. Die zentrale Speicherung der relevanten Daten unterstützt dieses Arbeitsweise. Diese elementar geänderte Art der Um- setzung führte zum Schlagwort des „pets versus cattle“, welches von [Bia16] wie folgt deﬁniert wird:

In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.

Es werden somit nicht mehr einzelne Systeme betrachtet und administriert, sondern durchnum- merierte Systeme verwaltet. Keins dieser Systeme unterscheidet sich dabei von den anderen System, wodurch die einzelnen Systeme problemlos austauschbar sind.

2.2.2.2 Netzwerk

Die Veränderungen der Serverlandschaft und des Betriebs verlangen auch eine Anpassung an die physische Vernetzung, um die Leistungsfähigkeit des Netzwerks und somit auch der gesamten IT- Infrastruktur zu erhöhen. Um in Netzwerken die unterschiedlichen Services verwalten zu können, werden sogenannte 3-Tier-Architekturen mit Access-, Aggregation- und Core-Komponenten eingesetzt. Abbildung 2.6 verdeutlicht diese Arbeitsweise [BR13]. Access-Switche realisieren dabei die Anbindung der Server, die Aggregation-Ebene übernimmt Steuerungsaufgaben wie Routing oder QoS. Die Core-Ebene wird durch sehr performante Systeme gebildet, die redundante Ver- bindungen zu unterschiedlichen Netzbereichen bereitstellen.

9Diese Systeme werden häuﬁg als Bare-Metal eingesetzt, d. h., dass auf diesen Systemen direkt der Hypervisor installiert wird. Ein Betriebssystem im klassischen Sinn wird nicht benötigt.

26 2.2 Cloud-Computing

Abbildung 2.6: 3-Tier-Architektur

Dieses System skaliert für den vertikalen10 Datentransfer sehr gut. Der durch Virtualisierung entstehende Datenverkehr ist jedoch verstärkt in horizontaler Flussrichtung, da nun vermehrt Daten zwischen den beteiligten Servern übertragen werden müssen. Dies entsteht durch die Nutzung von virtuellen Maschinen, wodurch große Datenmengen von Imageservern zu Produktivumge- bungen transportiert werden. Durch die Migration untereinander kommt es darüber hinaus zu Verschiebungen der VMs zwischen Wirtssystemen.

Für diese Art des Datentransfers ist die 3-Tier-Architektur nicht optimal, was zu einer Wieder- belebung einer nichtblockierenden Vernetzung der Netzwerkkomponenten [Clo53] führte. Diese nun als multirooted Clos oder Fat-Tree-Technik [AFLV08] bezeichnete Umsetzung nutzt eine 2-Tier-Architektur, bei der ein Server, wie in Abbildung 2.7 dargestellt, mit einem oder mehreren Leaf-Switchen verbunden ist. Diese Leaf-Switche sind mit allen übergeordneten Spine-Switchen verbunden, diese wiederum sind jedoch nicht untereinander vernetzt sind. Durch die vollständige Vermaschung der Leaf- mit den Spine-Switchen ist eine hohe Ausfallsicherheit garantiert, parallel dazu wird eine hohe Skalierbarkeit des Netzwerks erreicht.

Abbildung 2.7: Fat-Tree-Implementierung Leaf-Spine

10Dies bezeichnet Datenverkehr mit einer Datenﬂussrichtung zwischen Client und Server.

27 2 Grundlagen

In ausfallsicheren Netzwerken werden neben der meist doppelten Ausstattung relevanter Kompo- nenten auch die Verbindungen zwischen den Netzwerkkomponenten redundant ausgeführt. Ohne weitere Techniken oder Anpassungen sind diese Links aktiv und führen zu Schleifen im Netzwerk, die letztlich zu dauerhaft kreisenden Netzwerkpaketen und einer daraus folgenden Vollauslastung des Netzwerks führen [Bac88], [The07].

Techniken wie das Spanning-Tree-Protokoll (STP) ermöglichen eine schleifenfreie Verkabelung auch bei redundanten Links. Allerdings wird diese Schleifenfreiheit durch die Deaktivierung bestimmter Ports erreicht, wodurch Links ungenutzt verbleiben und die zur Verfügung stehende Leistungsfähigkeit nicht voll zur Verfügung steht. Der gestiegene Geschwindigkeitsbedarf im RZ verlangt jedoch eine bestenfalls vollständige Ausnutzung aller vorhandenen Links, so dass das Problem der ungenutzten Links immer schwerer wiegt. STP bietet jedoch keine Möglichkeiten, die Anzahl der nutzbaren Links zu erhöhen.

Diese Einschränkungen führten zu der Entwicklung neuer Protokolle, die diese Limitierungen aufheben und die physische Vernetzung besser ausnutzen sollen. In Fat-Tree-Netzwerken sind solche Protokolle zwingend notwendig, so dass mit Transparent Interconnection of Lots of Links (TRILL) und Shortest Path Bridging (SPB) zwei unterschiedliche Implementierungen eingesetzt werden können. Beide ermöglichen die Nutzung bisher deaktivierter Links, die Protokolle regeln die Schleifenfreiheit und erhöhen so den Gesamtdurchsatz im Netzwerk.

• TRILL Mit Hilfe von TRILL ist es möglich, die zusätzlichen Links zu nutzen, ohne die Schlei- fenfreiheit zu gefährden. TRILL implementiert hierzu eine Routingfunktionalität auf Basis des Protokolls IS-IS auf Layer 2, wodurch redundante Links aktiv weiter genutzt werden können.

Diese Routinginformationen werden zwischen den Netzwerkkomponenten11 ausgetauscht, um die kürzesten Pfade zwischen ihnen festzustellen. Jede RBridge besitzt Informationen über alle im Netz vorhandenen RBridges, so dass mehrere redundante Pfade im Netzwerk existieren können.

TRILL kapselt die originären Netzwerkdaten durch einen MAC-in-MAC-Mechanismus, wobei die ursprünglichen Daten neben einem neuen Transport- auch einen TRILL-Header erhalten.

• Shortest Path Bridging SPB ist ebenso wie TRILL eine Layer 2-Technik zur Nutzung redundanter Pfade. SPB ist im Standard IEEE 802.1aq deﬁniert und soll damit die alten Standards des STP12 ablösen.

11Diese werden nach [rDG+11] auch als RBridge bezeichnet. 12Dies betriﬀt u.die˙ Standards IEEE 802.1D (STP), 802.1w (Rapid STP) und 802.1s (Multiple STP).

28 2.2 Cloud-Computing

SPB nutzt ebenfalls IS-IS für den Austausch von Informationen. Durch unterschiedliche Implementierungsmöglichkeiten ist SPB im Gegensatz zu TRILL meist auf vorhandener Hardware lauﬀähig.

Abbildung 2.8 zeigt die zusätzliche Nutzung redundanter Links13. Der Datenverkehr muss nun nicht mehr ausschließlich über SW1 geleitet werden, was in klassischen Netzwerken zwingend notwendig ist. Hierdurch ist eine schnellere Verarbeitung der anfallenden Netzwerkdaten möglich.

SW1 SW2

SW3 SW4 SW5

Abbildung 2.8: Nutzung redundanter Pfade

2.2.3 Entwicklung der Softwareumgebung

Die im RZ zum Betrieb einer virtuellen Umgebung notwendigen Änderungen sind nicht nur auf die Hardware beschränkt, auch die eingesetzte Software ist vor dem Hintergrund der dynamischen und automatisierten Umgebung anzupassen. Mit traditionellen Softwareumgebungen ist eine adäquate Bereitstellung einer Cloud-Umgebung nicht mehr realisierbar, so dass spezielle Anwendungen genutzt werden, die den Betrieb ermöglichen. Der Betrieb einer Cloud-Umgebung durch den CSP wird durch Programme, Werkzeuge und Techniken unterstützt, die als Cloud Management Platform (CMP) bezeichnetet werden.

2.2.3.1 Cloud Management Platform

Eine CMP stellt alle Komponenten bereit, die für eine Cloud-Umgebung notwendig sind. Hierzu gehören Programme für den Betrieb der VMs sowie der Storage- und Netzwerkkomponenten, für Abrechnungs- und Managementzwecke als auch Lösungen, die die Zusammenarbeit der einzelnen Komponenten ermöglichen [BBLS12]. Auf Basis einer solchen CMP lassen sich Cloud-Lösungen bereitstellen, die jede Stufe des Cloud-Stack (vgl. Abbildung 2.5) abbilden können.

Die am Markt existenten CMPs unterscheiden sich in verschiedenen Aspekten, Vergleiche ﬁnden sich unter anderem in [WGL+12] für OpenStack und OpenNebula, in [Yad13] für OpenStack, OpenNebula und Eucalyptus mit Betrachtung der Supportmöglichkeiten, der Architektur, der

13Die nun zu nutzenden Verbindungen (in rot eingezeichnet) ermöglichen eine direkte Verbindung für SW2 zu SW3, SW4 und SW5

29 2 Grundlagen

Schnittstellen zu Amazon, der Hypervisoren, der Gastbetriebssysteme, dem Imagemanagement und der möglichen Programmiersprachen, sowie in [VLDWF12], der zusätzlich zu den vorgenannten noch die Nimbus-Umgebung hinsichtlich Speicher, Netzwerk, Software-Deployment, Schnitt- stellen, Hypervisoren und Authentiﬁzierung vergleicht.

Im Folgenden wird am Beispiel von OpenStack als führende Umgebung [BB16] für Cloud- Implementierungen die Aufgabenverteilung einzelner Komponenten erläutert und die Zusammen- arbeit untereinander dargestellt. OpenStack wurde in Zusammenarbeit zwischen der NASA und Rackspace entwickelt und im Jahr 2010 freigegeben. Seit der ersten Version hat sich OpenStack stetig weiter entwickelt und durch einen modularen Aufbau unterschiedlichste Services integriert [Fif14]. Dabei sind Core-Services für den grundlegenden Betrieb notwendig, die optionalen Diens- te bieten zusätzliche Möglichkeiten und Erweiterungen, die jedoch nicht genutzt werden müssen, um eine funktionsfähige Cloud-Umgebung zu erhalten.

Core-Services Die Core-Komponenten stellen grundlegende Funktionalitäten bereit, die notwendig sind, um eine Storage- oder Compute-Umgebung anbieten zu können. Je nach Ziel- richtung der Umgebung ist eine Installation und Konﬁguration aller Core-Komponenten jedoch nicht notwendig. So benötigt die Einrichtung einer Storage-Umgebung nur die Installation von Swift und Keystone, eine Compute-Umgebung verlangt demgegenüber Keystone, Nova, Glance, Neutron und Cinder. Die entsprechenden Services werden im Folgenden dargestellt.

• Keystone Keystone übernimmt die Rechteverwaltung, Authentifizierung und Zugriffsverwaltung in der Cloud-Umgebung und ist somit die zentrale Komponente im System [Bei14]. Sämtliche Anfragen werden durch Keystone als sogenannter Identity Service verarbeitet. Möchte ein Benutzer eine Instanz einer VM starten, weitere virtuelle Netzwerke oder Speicherpools anlegen oder ändern, erfolgt zuerst eine Übermittlung der Anmeldeinformationen an den Keystone-Server. Dieser prüft diese Parameter anhand seiner internen Datenbank. Sind die übergebenen Parameter korrekt, erstellt Keystone ein Token, welches zur die Durchführung der Aufgaben berechtigt. Für die Prüfung steht Keystone ein Rechtekonzept in Form eines Role-Based-Access-Control (RBAC) zur Verfügung. Dabei werden Benutzer und Projekte14 mit Hilfe von Rollen verbunden. Diese Rollen definieren die Aktionen, die der Benutzer ausführen darf.

• Nova Nova bezeichnet den Compute-Service und stellt die notwendigen Funktionen und Dienste für den Betrieb der VMs bereit. Hierzu gehören Verwaltungsdienste wie die Verteilung der Instanzen auf die Compute Node (CN) oder die Kommunikation mit dem involvierten Hypervisor. Mögliche Hypervisor sind dabei KVM, Hyper-V, Xen oder auch VMWare, deren 14Bei OpenStack als Tenant bezeichnet.

30 2.2 Cloud-Computing

Unterstützung sich jedoch in ihrer Leistungsfähigkeit unterscheidet [Jer17]. Nova bietet über Regionen und Verfügbarkeitszonen die Möglichkeit, die vorhandenen CNs aufzuteilen und logisch zu separieren.

• Glance Glance bezeichnet den Image-Service innerhalb der OpenStack-Umgebung. Als Image werden Abbilder von vorkonﬁgurierten VMs bezeichnet, die in Glance verwaltet, registriert und bereitgestellt werden. Fordert ein Benutzer die Bereitstellung einer VM an, wird ein geeignetes Image vom Server auf den entsprechenden CN kopiert.

Jede weitere Anforderung des gleichen Images für den gleichen CN benötigt keinen weiteren Kopiervorgang, da das Image bis zu einer Änderung lokal vorgehalten wird.

• Neutron Die Aufgaben der als Network-Service bezeichneten Komponente stellt Neutron bereit. OpenStack bietet in einer einfachen Installationsvariante die Implementierung von Basis- netzwerkdiensten durch Nova. Diese als nova-networking bezeichnete Technik ist jedoch nicht ausreichend leistungsfähig, so dass mit dem Folsom-Release15 Neutron als Core- Service eingeführt wurde.

Neutron bietet weitgehende Konﬁgurationsmöglichkeiten für Routing, VLANs und Imple- mentierungen für Techniken wie Network-as-a-Service (NaaS) oder Firewall-as-a-Service (FWaaS). Dabei bietet Neutron weiterhin die Möglichkeit, die gesamte Netzumgebung z.B. mit Hilfe von OpenFlow oder Open vSwitch vollständig zu virtualisieren.

Neutron unterteilt die Netzwerke in physisch (auch als Physical Network Infrastructure (PNI) bezeichnet) und virtuell (Virtual Network Infrastructure (VNI)), dabei kann ein PNI mehrere VNI beinhalten. Zusätzlich wird zwischen Netzwerken und Subnetzen unterschieden. Netzwerke bezeichnen dabei ein für sich eigenständiges Layer 2-Netz, deren Ports an den VMs oder an anderen virtuellen Netzwerkkomponenten angeschlossen sind. Subnetze bezeichnen ein eigenständiges Teilnetz auf Layer 3-Basis, wobei hier IPv4 oder IPv6 zur Adressierung genutzt werden kann. Die unterschiedlichen virtuellen Subnetze werden durch virtuelle Router miteinander verbunden, jeder Router verfügt dabei über interne Schnittstel- len zu den VMs und genau ein Gateway-Interface. Dieses bezeichnet das externe Interface, welches eine Anbindung an externe Netzwerke wie dem Internet herstellt.

• Swift Swift bezeichnet den Object-Storage-Service innerhalb der OpenStack-Umgebung und wird für die Speicherung der Images oder Snapshots genutzt.

15Release dieser Version war der 27. September 2012.

31 2 Grundlagen

Im Gegensatz zu traditionellen Speichersystemen werden die Daten von Swift nicht hier- archisch gespeichert und direkt vom Betriebssystem verwaltet, sondern über den Object Storage Daemon abstrahiert angesprochen. Durch diese Abstraktion entstehen Optimie- rungspotentiale hinsichtlich der Redundanz oder der Ressourcenplanung [MKRC14]. Diese Vorteile sind der Grund für die Nutzung von Swift als verantwortliche Komponente innerhalb einer Storage-Umgebung.

• Cinder Cinder ist ebenso wie Swift für die Verwaltung von Speicher zuständig. Im Gegensatz zu Swift wird der Speicher jedoch nicht objektbasiert, sondern blockbasiert verwaltet. Diese Technik ist vergleichbar mit klassischen Speichertechniken, so dass Cinder den VMs geeignete Volumes bereitstellen kann, die von diesen eigenständig verwaltet werden können. Daher wird Cinder auch als Block-Storage-Service bezeichnet.

Optionale Services Neben diesen Core-Services existieren optionale Dienste, die gezielt Funk- tionalitäten bereitstellen, um weitere Anwendungen und Dienste leichter in der Cloud-Umgebung implementieren zu können. Zu diesen Komponenten gehören mit Stand des Newton-Releases16 die in Tabelle 2.6 aufgeführten Services.

Diese Services interagieren miteinander, um eine hochautomatisierte und flexible Umgebung bereitzustellen, die die Infrastruktur des CSP nutzt und die eingerichteten Dienste für den Kunden zur Verfügung stellt. So bietet Horizon als Dashboard-Service die einfache Verwaltung der Res- sourcen, sowohl für den CSP als auch für den Kunden. Horizon stellt eine Weboberfläche bereits, an der sich der Nutzer anmelden kann und entsprechend der Berechtigung Konfigurationen vornehmen kann. Ohne diese Weboberfläche müsste die Konfiguration der Dienste auch durch den Kunden per Command Line Interface (CLI) erfolgen.

Neben diesen Services werden parallel immer weiter zusätzliche Dienste entwickelt, die zielgerichtet Probleme beseitigen sollen. Hierzu gehören unter anderem weitere Optimierungsdienste (Watcher), Suchdienste (Searchlight), Clustermanagement (Senlin) oder auch Dienste zur ver- besserten Abrechnungsmöglichkeit (Cloudkitty). Diese Dienste werden zuerst im Incubator17 aufgenommen und besitzen dann den Status incubated. Nach mehreren Prüfungen der Verwend- barkeit und Stabilität kann der Status auf integrated wechseln, wodurch der Dienst im nächsten Releasezyklus aufgenommen wird.

16Releasedatum war der 06. Oktober 2016. 17Dies beschreibt eine Testphase, in der die neuen Dienste geprüft werden.

32 2.2 Cloud-Computing

Tabelle 2.6: Optionale Komponenten der OpenStack-Umgebung Service Aufgabe Barbican Verwaltung von Zertifikaten, Passwörtern und Schlüsselpaaren Ceilometer Zentrale Informationssammelstelle, in der alle relevanten Daten zusammengeführt und zur Weiterverarbeitung vorbereitet werden Congress Policy-Framework zur Implementierung vordefinierter Regelwerke und Common Criteria-Standards innerhalb der Umgebung Designate Bereitstellung von DNS-as-a-Service Heat Orchestrierung der anfallenden Aufgaben Horizon Managementoberfläche zur Administration durch Kunde oder CSP Ironic Betrieb der VMs auf Bare-Metal Magnum Containerverwaltung Manila Bereitstellung gemeinsamer Dateisysteme zwischen unterschiedlichen Instanzen Murano Katalogbereitstellung über nutzbare Anwendungen Sahara Clustermanagement auf Hadoop-Basis Trove Bereitstellung von Database-as-a-Service (DBaaS) Zaqar Messaging-Service

2.2.3.2 Container

Die Entwicklung der Softwareumgebung ist jedoch nicht ausschließlich auf den Betrieb von VMs oder Speicherpools limitiert. Parallel steigt in der jüngsten Vergangenheit auch die Nutzung von Containertechniken in den virtuellen Umgebungen verstärkt an [DRK14].

Die unterschiedlichen Anwendungen, die im Rahmen von SaaS- oder PaaS bereitgestellt werden, benötigen für den Betrieb geeignete Programmbibliotheken, Softwareversionen und deﬁnierte In- stallationspfade. Vorgefertigte Templates ermöglichen zwar die kurzfristige Bereitstellung einer geeigneten VM, allerdings ist der entstehende Overhead teilweise sehr hoch. Jede VM bean- sprucht Speicher, Festplattenplatz und CPU-Laufzeit für den Betrieb, selbst wenn diese Ressour- cen nicht unmittelbar benutzt werden.

Die Weiterentwicklung zu sogenannten Containertechnologien wie Docker [Tur14] ermöglicht eine verbesserte Umgebung zur Aufgabenerledigung. Nun werden nicht mehr vollständige VMs genutzt, um einzelne Anwendungen bereitzustellen, sondern mit Hilfe gekapselter, leichtgewich- tiger Container die benötigten Umgebungen gestartet. Innerhalb dieser Umgebung sind alle be- nötigten Komponenten vorhanden, so dass die Nutzung der Anwendung keine nachträglichen Installationen benötigt [Mer14].

Die Speicherung der jeweiligen Daten erfolgt dabei im Normalfall nicht im Container, sondern auf externen Speichersystemen, die vom Container beim Start eingebunden werden. Hierdurch wird das „pets vs. cattle“-Prinzip (vgl. Abschnitt 2.2.2.1) nochmals verstärkt.

33 2 Grundlagen

Der Ursprung dieser Technik ist das Linux- und Unix-Umfeld, wo Containerimplementierungen seit langer Zeit bekannt sind. Dort ermöglichen Umgebungen wie LXC oder FreeBSD-Jails die Bereitstellung gekapselter Anwendungen, um diese von anderen Anwendungen abzuschotten und keine Kommunikation zwischen Systemprozessen zuzulassen. Hierdurch wird die Sicherheit und die Stabilität der Anwendungen gesteigert, allerdings entsteht zeitgleich ein höherer Konﬁgura- tionsaufwand.

2.3 Netzwerkvirtualisierung

In diesem Abschnitt wird zuerst die Entwicklung der virtuellen Netzwerke beschrieben, anschlie- ßend werden ausgewählte Overlaytechniken beschrieben und existente Netzwerkprotokolle detailliert dargestellt. Die Paradigmen der SDN und NFV werden in den Abschnitten 2.4 sowie 2.5 beschrieben.

2.3.1 Entstehung

Unter dem Begriﬀ der Netzwerkvirtualisierung werden Techniken zusammengefasst, die von der physisch vorhandenen Netzwerktechnik abstrahieren und dem Nutzer nur logisch existente Netz- werke bereitstellen.

Dabei sind die virtuellen Netzwerke nicht durch die gestiegenen Anforderungen in Cloud-Umge- bungen entstanden, sondern existierten schon lange Zeit im Bereich der Host-Based-Virtualisierung. Wenn Virtualisierungsumgebungen wie VMWare, KVM oder Xen eingesetzt werden, ist auch meist die Anbindung der betriebenen VMs an ein Netzwerk gefordert. Für eine solche Anbindung stehen verschiedene Implementierungen bereit:

• Bridged Sofern ein Netzwerkadapter innerhalb der virtuellen Umgebung auf den Modus Bridged eingestellt ist, beﬁndet er sich mit im gleichen Subnetz wie das Wirtssystem. Falls aktiv, erhält die VM per DHCP eine IP-Adresse aus diesem Netzwerk und ist ohne weitere Anpassung auf dem Wirtssystem für andere Systeme erreichbar. Die Netzwerkkarte des Wirtssystems wird somit logisch zwischen der VM und dem physischen Host aufgeteilt [Wu10].

• NAT Durch Network Address Translation (NAT) kann eine VM mit anderen Netzwerken kommunizieren, nutzt hierfür jedoch die IP-Adresse des Wirtssystems. Die VM beﬁndet sich

34 2.3 Netzwerkvirtualisierung

in einem internen Netzwerk, welches nicht direkt von anderen Systemen erreicht werden kann [BLGM01]. Soll die VM von anderen Systemen erreicht werden, müssen auf dem Wirtssystem Konﬁgurationen wie Port-Weiterleitungen vorgenommen werden.

• Internal Eine Netzwerkkarte auf dem Wirt, die als Internal konﬁguriert wurde, ermöglicht eine Kom- munikation mit allen VMs, die ebenfalls mit dem gleichen internen Netzwerk verbunden sind. Eine Kommunikation der VM mit anderen Netzwerken ist nicht möglich. Eine solche Implementierung stellt somit eine sehr einfache Form eines Virtual Switch (vSwitch) dar, jedoch meist ohne weitergehende Konﬁgurationsmöglichkeiten.

• Host-only Im Host-only Modus operiert die VM ohne eine weitere Netzwerkanbindung innerhalb des Hosts. Ein Zugriﬀ auf andere Netzwerke oder VMs ist nicht möglich. Als Kommunikati- onspartner steht nur das Wirtssystem zu Verfügung.

Diese Techniken sind jedoch auf einzelne Host-based Virtualisierungslösungen beschränkt und somit nicht in großen Netzwerken einsetzbar. Besonders die Weiterentwicklung der RZ-Architekturen weg von statischen hin zu hochdynamischen virtuellen Umgebungen (vgl. Abschnitt 2.2.2) ver- ändert die Anforderungen an die vorhandenen Netzwerke. Diese Anforderungen sind teilweise bereits in klassischen Netzwerken relevant, konnten dort jedoch durch zusätzliche Hardware- komponenten, separate Verkabelung oder angepasste Sicherheitsstrategien umgesetzt werden. In virtuellen Netzwerken sind diese zusätzlichen Möglichkeiten nicht gegeben, dennoch sind die folgenden fünf Anforderungen aufgrund der unterschiedlichen Kunden und der hohen Dynamik auch im virtuellen Netzwerk von Bedeutung.

• Isolation Das virtuelle Netzwerk soll als LAN eine in sich geschlossene Netzwerkeinheit bilden und sich so verhalten, wie es in klassischen LANs möglich ist. Hierzu gehört die freie Wahl von IP-Adressen, Konﬁguration von Routingregeln oder das ﬂexible Hinzufügen von weiteren Systemen.

• Sicherheit Die virtuellen Netzwerke müssen voneinander getrennt sein, damit kein direkter Zugriﬀ von einem zum anderen Netzwerk möglich ist.

• Kommunikation Trotz der Trennung und Isolation der Netzwerke soll eine Kommunikation mit anderen Systemen ermöglicht werden, sofern dies vom Kunden geplant ist. Zusätzlich soll eine Anbindung an externe Netzwerke wie dem Internet möglich sein.

35 2 Grundlagen

• Anpassbarkeit Der Kunde soll das ihm zugewiesene Netzwerk eigenständig anpassen können, ohne durch externe Gegebenheiten eingeschränkt zu werden.

• Selbstbestimmtheit Der Nutzer darf die Verbindung, Adressierung und Vernetzung der Systeme untereinander eigenständig vorgeben, ohne dass der Provider Vorgaben machen muss.

Ausgehend von diesen Anforderungen deﬁniert [CB10] die Virtualisierung der Netzwerke als Teil des vorhandenen physischen Netzwerks.

A networking environment supports network virtualization if it allows coexistence of multiple virtual networks on the same physical substrate. Each virtual network (VN) in a network virtualization environment (NVE) is a collection of virtual nodes and virtual links. Essentially, a virtual network is a subset of the underlying physical network resources.

Dabei wird die konkrete Implementierung virtueller Netzwerke nicht explizit deﬁniert, vielmehr ermöglichen unterschiedliche Techniken wie Overlay-Netzwerk (ON), SDN und NFV allein oder in Kombination die Erstellung virtuelle Netzwerke. Alle Techniken nutzen dabei die zugrundeliegende physische Vernetzung, um darauf die logischen Netzwerke abzubilden. Diese nur virtuell existierenden Netzwerke besitzen über die zugrundeliegende Hardware keine Kenntnis, jedes dieser Netzwerke verhält sich wie ein eigenständiges, isoliertes Netzwerk.

Hierdurch entsteht für den Kunden eine größtmögliche Freiheit bei der Nutzung dieser virtuellen Umgebungen, die auch in bereits existenten Infrastrukturen Anwendung ﬁnden [Ama16]:

Amazon Virtual Private Cloud (Amazon VPC) ermöglicht die Bereitstellung eines logisch isolierten Bereichs der Amazon Web Services (AWS)-Cloud, in dem Sie AWS- Ressourcen in einem von Ihnen deﬁnierten virtuellen Netzwerk ausführen können. Sie haben die vollständige Kontrolle über Ihre virtuelle Netzwerkumgebung, u. a. bei der Auswahl Ihres eigenen IP-Adressbereichs, dem Erstellen von Subnetzen und der Konﬁguration von Routing-Tabellen und Netzwerk-Gateways.

Klassische Netzwerke sind nicht in der Lage, diese Anforderungen zu erfüllen. Eine physische Trennung der VMs ist aufgrund der virtuellen Umsetzung und der hohen Anzahl unmöglich, so dass folglich eine Trennung auf Layer 2-Basis benötigt wird. Ohne eine solche Separierung sind Angriffe wie ARP-Spoofing [Wha01] auch in virtuellen Umgebungen möglich. Da die VMs durch die Layer 2-Techniken separiert werden, existiert keine direkte IP-Konnektivität. Hierdurch sind bereits viele bekannte IP-basierte Angriffe wirkungslos [Bun09]. Für eine solche Trennung stehen mit VLAN und MPLS zwei unterschiedliche Techniken bereit.

36 2.3 Netzwerkvirtualisierung

• VLAN Mit der Technik eines Virtual LAN (VLAN) wurde eine Erweiterung der Schicht 2 einge- führt, die es ermöglicht, über eine physische Verbindung mehrere logische Netzwerke zu betreiben [MDD+14]. Dazu deﬁniert der Administrator die Zugehörigkeiten eines Netz- werkports zu einem VLAN; anschließend können nur Systeme im gleichen VLAN direkt miteinander kommunizieren.

Zur Implementierung wird hauptsächlich der Standard nach IEEE 802.1q genutzt, in dem, wie in Abbildung 2.9 dargestellt, ein zusätzliches Feld18 mit einer Größe von 4 Byte in den Ethernetframe eingefügt wird [Soc03]. Tabelle 2.7 beschreibt die entsprechenden Header- felder19 des VLAN-Tags.

Ether- type

Protokol VLAN Priorität DEI ID ID

Abbildung 2.9: VLAN-Tag im Ethernetframe

Tabelle 2.7: VLAN-Header Headerfeld Größe Aufgabe Tag Protocol Identiﬁer 16 Fester Wert von 0x8100 Priority 3 Festlegen der Priorität DEI 1 DropEligibleIndicator,ermöglichtdasEntfer- nen des Frames aufgrund von Überlastung VLANID 12 IdentiﬁzierungdesVLANs

VLAN-fähige Switche werten das VLAN-Tag aus und nutzen die zusätzlichen Informationen aus, um die Daten an den korrekten Empfänger zu steuern.

• MPLS Mit Multi Protocol Label Switching (MPLS) existiert eine weitere Technologie zur Erstel- lung getrennter Bereiche. Dabei nutzt MPLS Pfade, über die die entsprechenden Daten geschickt werden können. Somit entstehen verbindungsorientierte Wege innerhalb eines verbindungslosen Netzwerks [OH13]. Verbindungsorientierte Netzwerke bieten gegenüber

18Dieses Feld wird auch als VLAN-Tag bezeichnet. 19Die Größen sind in Bit angegeben.

37 2 Grundlagen

IP-basierten, verbindungslosen Netzwerken diverse Vorteile wie Durchsatzsteigerung, Ver- kehrssteuerung oder QoS.

MPLS nutzt Label, mit denen der Weg des Pakets durch das Netzwerk deﬁniert wird. Dabei versieht ein Label Edge Router (LER) das ankommende Netzwerkpaket mit einem geeigneten Label, welches den Pfad im Netzwerk beschreibt. Anschließend wird das Paket an den nächsten Router weitergeleitet, der als Label Switch Router (LSR) bezeichnet wird. Dieser muss nun im Gegensatz zu klassischen Routern nicht mehr den gesamten Header auswerten, sondern nur das Label im MPLS-Header analysieren. Anhand seiner internen Datenbank stellt der LSR anschließend fest, an welchen Port das Paket weitergeleitet werden soll. Der LSR tauscht nun das bisherige gegen ein für den angeschlossenen Pfad gültiges Label und leitet das Paket an seinen Nachbarn weiter. Hierdurch entsteht der virtuelle Pfad für das Paket im Netzwerk. Durch diese Pfadbildung ist es ebenfalls möglich, separate Netzwerke auf Layer 3-Basis zu erstellen [RR06].

Abbildung 2.10 zeigt den MPLS-Stack sowie die Aufteilung des MPLS-Header. Tabelle 2.8 beschreibt die Headerfelder.

Label TC BOS TTL

Abbildung 2.10: MPLS-Stack

Tabelle 2.8: MPLS-Header Headerfeld Größe Aufgabe Label 20 Pfadkennzeichner TC 3 TraﬃcClasszurNutzungbeiQoS BOS 1 Deﬁnition,obessichumeinverschachteltesMPLS-Paket handelt (Bottom of Stack) TTL 8 Anzahl der noch zulässigen LSR, bevor das Paket verworfen wird

Durch die Nutzung eines 20 Bit großem Labels ermöglicht MPLS die Nutzung von 220 = 1.048.576 unterschiedlichen Netzwerken.

38 2.3 Netzwerkvirtualisierung

Allerdings sind die Einsatzgebiete der vorgenannten Protokolle nicht vollständig für große Umge- bungen nutzbar. So ermöglichen VLANs nach IEEE 802.1q nur 409620 unterschiedliche Netzwerke möglich. MPLS ist in der Lage mehr als eine Million unterschiedliche Netzwerke zu verwalten, bei der Nutzung von MPLS müssen jedoch die eingesetzten Netzwerkkomponenten in der Lage sein, den MPLS-Header zu verstehen und zu ändern [BGKT13].

Unter anderem diese Limitierung führte zu der Entwicklung neuer Netzwerkprotokolle, die in virtuellen Umgebungen eingesetzt werden und dort als Overlayprotokolle virtuelle Netzwerke bereitstellen können.

2.3.2 Overlay-Netzwerke

Ein ON bezeichnet ein logisches Netzwerk, dessen Struktur hinsichtlich Adressierung und Routing losgelöst von der tatsächlich physischen Vernetzung implementiert werden kann [APST05]:

With virtualization, nodes can treat an overlay as if it is the native network, and multiple overlays can simultaneously use the same underlying overlay infrastructure.

Dabei sind auch Overlaytechniken nicht erst seit den gestiegenen Anforderungen der Cloud- Umgebungen existent. [ABKM02] beschreibt bereits im Jahr 2001 Methoden eines ON, um störanfällige Routingstrategien zwischen Autonomen Systemen im Internet durch virtuelle Netz- werke, die eine höhere Verfügbarkeit erreichen, zu optimieren [SAA+99]. Hierzu wird von den physischen Links abstrahiert und eine neue, virtuelle Routingschicht bereitgestellt. Ähnliche An- sätze der Overlaytechnik beschreibt [ZHS+04] für P2P-Netze oder [LvM02] für IPv6-Techniken.

Die ON nutzen dabei meist Tunneltechniken, bei denen die Overlay-Protokolle die traditionellen Protokolle als Payload übertragen. Diese Kapselung stellt den ursprünglichen Netzwerkdaten neue Header voran und generiert somit neue Netzwerkpakete. Diese werden dann selbst wieder mit IP- oder Ethernetheader versehen, jedoch mit angepassten Zieladressen, die auf geeignete Tunnelendpunkte verweisen.

Abbildung 2.11 zeigt diese Technik schematisch.

20Mit 12 Bit können 212 = 4096 unterschiedliche, logische Netzwerke. Hersteller-bezogene Anpassungen reduzieren diese Anzahl der möglichen Netzwerke weiter. So implementiert die Firma Cisco Systems die ID 0 und 4095 für das interne System. Die VLAN-ID 1 ist ebenfalls bereits konﬁguriert und kann nicht gelöscht werden [Cis12a].

39 2 Grundlagen

Abbildung 2.11: Kapselung von Netzwerkdaten

Die Tunnelendpunkte empfangen diese Daten und entfernen die zusätzlichen hinzugefügten Hea- der. Anschließend steht am Zielort das Ursprungsnetzwerkpaket bereit, welches dann anhand der Originaladressen korrekt weitergeleitet werden kann.

Um bestimmen zu können, ob Daten gekapselt übertragen werden müssen, protokollieren die jeweiligen Endpunkte den internen Datenverkehr mit. Sofern festgestellt wird, dass ein adressier- ter Empfänger außerhalb des direkt erreichbaren Netzwerks ist, übernimmt der Tunnelendpunkt die Weiterleitung der Daten an die korrekte Stelle. Um die Daten bei der Übertragung und am Tunnelendpunkt eindeutig zuordnen zu können, werden unterschiedliche IDs genutzt, die das jeweilige Netz oder den Kunden eindeutig kennzeichnen.

Die Veränderung der RZ-Architektur führte zu Entwicklungen von unterschiedlichen Netzwerk- protokollen, die zwar das gleiche Ziel besitzen, jedoch unterschiedliche Techniken einsetzen. Die wichtigsten fünf Overlayprotokolle werden im Folgenden vorgestellt und hinsichtlich ihrer Ar- beitsweise verglichen.

2.3.2.1 QinQ

Die Flexibilität von Ethernet im LAN führte in der Vergangenheit dazu, dass diese Qualität von Kunden auch im Wide Area Network (WAN) gewünscht wurde. Techniken wie Synchrone Digitale Hierarchie (SDH) oder Asynchronous Transfer Mode (ATM) bieten zwar ähnliche Mög- lichkeiten, dennoch setzte sich Ethernet für den Betrieb im WAN auch aufgrund der gestiegenen Übertragungsgeschwindigkeiten durch.

Um die Ethernetframes unterschiedlicher Kunden über WAN-Strecken korrekt unterscheiden zu können, kann der Provider MPLS [RR06] (vgl. Abschnitt 2.3.1) oder Provider Bridges nach IEEE 802.1ad [IEE05] (vgl. Abschnitt 2.2.2.2) nutzen [BM05]. Provider Bridges erweitern die Technik der VLANs nach IEEE 802.1q, in dem nun zwei VLAN-Tags in den Ethernetframe eingefügt werden [SRV08].

Abbildung 2.12 zeigt die doppelte Kapselung, wobei der zusätzliche Header vor dem ersten VLAN-Tag eingefügt wird.

40 2.3 Netzwerkvirtualisierung

Ether- Ethernet type

VLAN nach Ether- 802.1q type

QinQ nach Ether- 802.1ad type

Abbildung 2.12: QinQ Encapsulation

[ABMR06] unterteilt die möglichen Tags in Service VLAN ID (S-VID) und Customer VLAN ID (C-VID). Dabei erfolgt die Trennung im LAN des Kunden mit Hilfe des C-VID, sobald der Frame das Kundennetz verlässt und vom Provider weitergeleitet wird, vergibt der Provider ein S-VID. Der C-VID muss nicht verändert werden und bleibt über die gesamte WAN-Strecke gleich. Am Zielpunkt entfernt die Netzwerkkomponente des Providers das S-VID und leitet das Paket weiter.

Im RZ kann diese Technik analog verwendet werden, um die VMs von Kunden auch über geogra- ﬁsch getrennte Bereiche transparent zu verbinden. QinQ-Header beinhalten keine neuen Felder, sondern nutzen die existente Struktur nach IEEE 802.1q. Durch diese Erweiterung können nun 40962 ≈ 16 Millionen unterschiedliche virtuelle Netzwerke genutzt werden.

2.3.2.2 VXLAN

Virtual eXtensible LAN (VXLAN) beschreibt eine Weiterentwicklung der bekannten VLAN- Technik, die dessen Limitierung beseitigt und somit auch in großen Umgebungen mit mehr als 4096 unterschiedlichen Netze eingesetzt werden kann. VXLAN nutzt einen zusätzlichen Header mit einem 24 Bit langen, VXLAN Network Identiﬁer (VNI) genannten Tag, mit dem rund 16 Millionen Netze adressiert werden können. Ein durch das Tag eindeutig deﬁniertes VXLAN bildet eine eigene Broadcast-Domäne, die sich im Gegensatz zu VLAN auch über verteilte Standorte erstrecken kann.

Werden Daten versandt, wird der originale Ethernetframe mit dem VXLAN-Header versehen, anschließend in ein UDP-Paket verpackt, welches als Packet Data Unit (PDU) per IP neu versandt werden kann. Abbildung 2.13 zeigt den entsprechenden Vorgang.

Jedem VNI ist ein VXLAN Tunnel Endpoint (VTEP) zugeordnet, welches die Kommunikation über IP-Subnetze hinweg ermöglicht. Diese VTEPs lernen die angeschlossenen MAC-Adressen und speichern diese in einer Forwarding-Table, die zusätzlich die folgenden Einträge enthält:

41 2 Grundlagen

Outer Eth

Flags RSVD VNI RSVD

Abbildung 2.13: VXLAN-Kapselung

• VM MAC-Adresse

• VTEP IP-Adresse

• VTEP MAC-Adresse

• VNI

Die Daten werden zwischen den VTEPs übertragen, der Kommunikationspartner extrahiert die gekapselten Daten aus den übermittelten Netzwerkpaketen und sendet sie an den originären Empfänger. Broadcasts an Systeme innerhalb des VNI, jedoch außerhalb des VTEP, werden vom VTEP übernommen, gekapselt und mittels IP-Multicast an alle berechtigten VTEPs gesandt. Der VTEP, der direkt mit dem entsprechenden Zielsystem vernetzt ist, entpackt das übertragene Datenpaket und leitet es im Originalzustand an das entsprechende Ziel. Die entsprechenden Antwortpakete durchlaufen diesen Weg in umgekehrter Richtung.

Für Sender und Empfänger läuft diese Kapselung transparent ab, so dass sie nicht merken, dass die Übertragung auch über WAN-Strecken erfolgt sein kann. Für die Sender scheint es so, dass der Empfänger in der gleichen Layer 2-Broadcastdomäne vernetzt ist. Für Clients, die den gleichen VNI besitzen, erscheint diese Umgebung so, als würden sie sich im gleichen Subnetz beﬁnden.

2.3.2.3 NVGRE

Das Protokoll Network Virtualization using Generic Routing Encapsulation (NVGRE) [GW15] nutzt Generic Routing Encapsulation (GRE) als Tunnelprotokoll. Dabei werden Pakete über Layer 2-Tunnel übertragen, als ID wird das 24 Bit großes Headerfeld Virtual Subnet ID des GRE-Headers als Tenant Network Identiﬁer21 genutzt. Abbildung 2.14 zeigt die Aufteilung der Protokolle, die durch das zusätzliche Einfügen des GRE-Headers erfolgt.

21Dies dient zur eindeutigen Identiﬁzierung des virtuellen Netzwerks.

42 2.3 Netzwerkvirtualisierung

Outer Eth

Abbildung 2.14: Tunnelung durch NVGRE

Durch die Nutzung von GRE muss keine Anpassung der vorhandenen Hardware erfolgen, da die meisten heutzutage eingesetzten Netzwerkkomponenten das Protokoll im Gegensatz zu VXLAN verstehen. So sind keine speziellen Tunnelendpunkte notwendig, es muss nur die entsprechende GRE-Verarbeitung auf den beteiligten Komponenten möglich sein.

2.3.2.4 STT

In virtuellen Umgebungen ist die starke Beanspruchung der CPU inhärent. Die gesamte Berech- nung der logischen CPUs muss von der realen CPU übernommen werden. In virtuellen Netzwer- ken kommen zusätzlich Berechnungen hinzu, die in hardwarebasierten Umgebungen von der NIC übernommen werden können. Diese als TCP/IP Oﬄoad Engine bezeichnete Technik entlastet die CPU des Rechners von bestimmten rechenintensiven Aufgaben [YCM+02] und bietet besonders in schnellen Netzwerken Performancevorteile [WC06]. Ebenso entlastet die als TCP Segmentati- on Oﬄoad bezeichnete Technik die CPU von der Segmentierung des Netzwerkpakets, indem der Netzwerkkarte die zu übertragenen Daten in einem Stück übergeben werden. Die Netzwerkkarte übernimmt dann die Aufteilung der angelieferten Daten [FHH+03].

Diese Engpässe versucht das Stateless Transport Tunneling (STT)-Protokoll zu beseitigen. STT nutzt ebenfalls Encapsulation als Tunneltechnik, wobei der Ethernetframe vollständig mit dem STT-Header versehen und mit einem Pseudo-TCP-Header gekapselt wird. Dies wird nun als Payload per IP und einem äußeren Ethernet-Header weitergeleitet.

Bild 2.15 verdeutlicht den Aufbau der Kapselung.

Outer Eth

Abbildung 2.15: STT Encapsulation

Der TCP-ähnliche Header wird genutzt, um die Hardwarebeschleunigung bestimmter NICs ausnutzen zu können. Andere Protokolle wie VXLAN oder NVGRE bieten diese Techniken nicht, so dass die Nutzung von STT aktuell reale Geschwindigkeitsvorteile bringt [KM14], besonders durch die Möglichkeit, Netzwerkpakete mit einer größeren Maximum Transmission Unit (MTU)

43 2 Grundlagen als die des physischen Netzwerks zu übertragen. Weitere Vorteile von TCP wie Flusskontrolle oder zuverlässige Übertragung der Daten sind jedoch nicht implementiert [DG16].

Zur Adressierung nutzt STT das 64 Bit große Context-ID-Feld, mit dem 264 Systeme adressiert werden. Allerdings ist die konkrete Verwendung dieses Felds im RFC nicht genau speziﬁziert [DG16]:

Some other encapsulations [...] use an explicit tenant network identifier or virtual network identifier. The Context Identifier can be thought of as a generalized form of virtual network identifier.

Diese Unklarheit über eine mögliche Verwendung verhindert bisher die Umsetzung eines STT- basierten virtuellen Netzwerks [LEBC+12].

2.3.2.5 GENEVE

Die bisher vorgestellten Protokolle NVGRE, VXLAN und STT besitzen unterschiedliche Fähig- keiten und Stärken. Sofern ein Administrator diese Stärken nutzen möchte, ist er gezwungen, unterschiedliche Tunnel-Protokolle im Netzwerk zu betreiben. Generic Network Virtualization Encapsulation (GENEVE) wurde entwickelt, um die unterschiedlichen Stärken in einem Proto- koll zusammenzufassen, um so die Vielzahl der eingesetzten Protokolle zu reduzieren [GSG+14]. Dies umfasst

• Multivendor-Unterstützung

• Nutzung von Netzwerkkartenfähigkeiten wie Large Receive Offload [Gro05], Large Segment Offload und Checksum Offload [RMI+04]

• Keine Anpassung der Netzwerkhardware

GENEVE nutzt analog zu VXLAN einen auf UDP basierenden Header mit einem 24 Bit großem VNI. Abbildung 2.16 zeigt die Kapselung der Daten durch Einfügen des zusätzlichen GENEVE- Headers.

Outer Eth

Abbildung 2.16: Kapselung durch GENEVE

Im Gegensatz zu VXLAN ist GENEVE jedoch mit einem erweiterbaren Header entwickelt worden. So können Anpassungen und neue Funktionen ohne Entwicklung eines neuen Protokolls durch

44 2.3 Netzwerkvirtualisierung

Implementierung in den Header durchgeführt werden. Dies erhöht wiederum die Stabilität im Netzwerk, da nicht für eine neue Funktion erneut ein neues Protokoll hinzugefügt werden muss; die Anzahl der eingesetzten Protokolle und somit auch der Overhead und der Administrations- aufwand bleiben daher gering.

2.3.2.6 LISP

Klassische Adressierungstechniken wie IP erfüllen mit ihrer Notation zwei Aufgaben. Zum einen wird über den Hostteil der Adresse das Endgerät eindeutig identiﬁziert, zum anderen deﬁniert der Netzteil einer Adresse wiederum eindeutig die logische Lokation des Endgeräts im Netzwerk.

Durch die steigende Mobilität der Endgeräte, die neben virtuellen Umgebungen auch im Bereich der mobilen Endgeräte und das zugehörige Roaming zunehmend relevant wird, ist eine solche doppelte Aufgabenwahrnehmung problematisch. Wird eine VM migriert, müsste sich ohne die Nutzung von Overlayprotokollen die IP-Adresse ändern, um weiterhin im Netzwerk kommunizieren zu können. Dies führt jedoch zum Verlust der korrekten Zuordnung des Systems zum originären Netzwerk [ZFM07].

Das Locator / ID Separator-Protocol (LISP) [FFML13] führt ein neues Adressierungsschema ein, bei dem das Endgerät zwei Identifikatoren erhält. Der erste Identifikator wird Endpoint Identifier (EID) genannt und bezeichnet die Adresse des Geräts. Die Lokation des Geräts wird mit Hilfe des Routing Locator (RLOC) als zweiten Identifikator definiert. Diese Aufspaltung in zwei unterschiedliche Namensräume ermöglicht eine bessere Skalierung der Routinginformationen und somit eine vereinfachte Administration.

Hierdurch können VMs im RZ problemlos zwischen unterschiedlichen Subnetzen verschoben und weiterhin eindeutig identiﬁziert werden, da sich die EID nicht ändern. Einzig die RLOC muss bei einer Migration der VM angepasst werden.

Die Zuordnung zwischen EID und RLOC übernimmt ein Mapping-Service, der von den beteiligten Routingkomponenten über Änderungen informiert wird. Der Mapping-Service unterteilt sich in zwei Kompontenten:

• MAP-Server Der MAP-Server nimmt die Änderungen im Netzwerk entgegen und speichert den Zusam- menhang zwischen RLOC und EID.

• MAP-Resolver Der Resolver nimmt Anfragen entgegen und übermittelt die gewünschten Informationen, die er aus der verteilten Datenbank extrahiert hat.

45 2 Grundlagen

LISP erstellt somit eine Architektur, die Layer 3 in Layer 3-Pakete kapselt und unterscheidet sich somit von den vorgenannten Protokollen, die Layer 3 in Layer 2-Pakete kapseln.

2.4 Software Deﬁned Networks

Die Nutzung der VMs hat die Ressourcenauslastung im RZ deutlich verbessert. Mit der Möglich- keit, die eingesetzten VMs zu klonen, kopieren oder zu migrieren, steigt die Flexibilität enorm an. Jedoch bleibt der Aufwand für den Betrieb dieser virtuellen Umgebung immer noch hoch, da zwar die Migration einer VM von einem auf einen anderen Server per Mausklick oder kurzem CLI-Befehl problemlos umzusetzen ist, weitere Arbeitsschritte jedoch nicht in gleichem Maße automatisiert sind. Änderungen der IP-Adresse, Anpassungen von Firewall- und Routingregeln sowie Konﬁgurationen der beteiligten Netzwerkkomponenten müssen immer noch manuell durch- geführt werden.

Durch die Einführung von SDN kann nun auch dieser Verwaltungsaufwand minimiert werden. In SDN-basierten Netzwerken übernimmt ein Controller die gesamten Verwaltungsaufgaben und regelt die Steuerung des Datenverkehrs anhand deﬁnierter Regeln. Diese Regeln können sowohl händisch durch den verantwortlichen Administrator als auch automatisiert durch externe Anwen- dungen implementiert werden.

Durch den neuartigen Ansatz der SDN haben sich die Möglichkeiten und Einsatzgebiete solcher Netzwerke stark verändert. Dies umfasst Verbesserungen der Datensteuerung, des Netzwerkma- nagements, Load Balancing, Securityimplementierungen und verbesserte Network Access Con- trol (NAC)-Methoden, sowie ein vereinfachtes Testen, Debuggen und Validieren neuer Protokolle [BM14].

2.4.1 Konzepte

Mit der Entwicklung von SDN wurden drei wesentliche Konzepte umgesetzt, die die Nutzung dieser Netzwerke erheblich verändern [NG13]. Diese Konzepte betreﬀen die Separierung der Forwarding- und der Controlplane in Switchen, die Programmierbarkeit des Netzwerks und eine zentrale Steuerung des Netzwerks.

46 2.4 Software Deﬁned Networks

2.4.1.1 Trennung von Forwarding- und Controlplane

Um die vorgenannten Verbesserungen zu erreichen, trennt SDN die switchinterne Aufteilung auf. Ein Switch unterteilt sich in eine Forwardingplane22 und eine Controlplane. Letztgenannte entscheidet an welchen Port ankommende Netzwerkpakete weitergeleitet werden müssen. Die Forwardingplane übernimmt diese Weiterleitung der Datenpakete an die korrekten Ports.

Dadurch, dass diese zwei Schichten voneinander getrennt werden können, besteht nun die Mög- lichkeit, die Controlplane vollständig aus dem Switch herauszulösen und die Aufgaben in einen externen Controller zu verlagern. Dieser übernimmt nun die Entscheidungen über die ankommenden und abgehenden Pakete und teilt seine Entscheidung an die beteiligten Switche mit. Der einzelne Switch wird somit von der lokal beschränkten Berechnung der korrekten Weiterleitung entlastet, der Controller kann durch seine übergeordnete Sicht nun eine optimierte Weiterleitung für alle beteiligten Komponenten errechnen.

Einhergehend mit dieser Entkopplung verliert auch die strenge Hardwarebindung des Kunden an einen Hersteller an Relevanz. In der Vergangenheit wurde häufig versucht, eine homogene IT-Infrastruktur zu schaffen und zu bewahren. Da in einem SDN die Hardware ausschließlich für die Weiterleitung der Daten verantwortlich ist, ist diese Homogenität nicht mehr von herausra- gender Bedeutung. Sofern die eingesetzte Hardware SDN-fähig ist, kann sie eingesetzt werden; die konkrete Konfiguration erfolgt anschließend durch den Controller. Zusätzlich ist es nun auch möglich, virtuelle Switche in die IT-Landschaft zu integrieren, um so die Flexibilität und Auto- mation weiter zu steigern [Puj15].

2.4.1.2 Programmierbarkeit

Ein weiteres Merkmal einer SDN-Umgebung ist die Möglichkeit der Programmierung des Netz- werks [NG13]. Dabei bezieht sich die Programmierbarkeit sowohl auf die Nutzung von Anwen- dungen, die global festlegen, wie Daten verarbeitet werden sollen, als auch die Konﬁguration der angeschlossenen Switche. Dies führt zu einer Aufteilung des anfallenden Datenverkehrs in zwei Bereiche [MAB+08]:

• Northbound Hiermit wird Datenverkehr bezeichnet, der zwischen Controller und darüber liegenden An- wendungen und Diensten transportiert wird. Die Verwaltung dieses Datenverkehrs erfolgt durch die Northbound-API. Die Art dieses Datenverkehrs ist nicht standardisiert, sondern ist von der übergeordneten Anwendung abhängig [JZH+14].

22[BBGP10] bezeichnet die Forwardingplane auch als Dataplane.

47 2 Grundlagen

• Southbound Dieser Datenverkehr bezeichnet die Kommunikation zwischen dem Controller sowie den Switchen und regelt somit die Kommunikation zwischen der lokalen Forwardingplane und der externen Controlplane. Die Aufgaben der Southbound-API umfassen Managementauf- gaben wie die Steuerung der Switchanbindung an den Controller oder Fehlerbehandlungs- routinen, aber auch Controllingaufgaben, die den Nachrichtenaustausch oder das Monito- ring behandeln. ForCES [YDAG04], NetConf [Was11] oder OpenFlow sind Protokolle, die die Southbound-API implementieren. Eine Übersicht über mögliche Protokolle ﬁndet sich in [KZMB14]. OpenFlow wird aufgrund der marktbeherrschenden Stellung in Abschnitt 2.4.2 detailliert beschrieben.

[SSHC+13] führt eine weitere Unterteilung des Datenverkehrs ein. Mit der East/Westbound-API wird der Datenverkehr bezeichnet, der zwischen Controller und unterschiedlichen Netzwerken oder Nicht-SDN-Bereichen ausgetauscht wird:

• Westbound Dies bezeichnet den Datenverkehr, der zu anderen SDN-basierten Netzwerkabschnitten erfolgt. Hierüber können systemweite Routinganpassungen erfolgen, die eine weitreichende Anpassung über das gesamte Netzwerk ermöglichen. So ist die virtuelle Umgebung in der Lage, auch über Layer 3-Bereiche VMs zu verschieben, ohne weitere manuelle Anpassungen vorzunehmen.

• Eastbound Mit der Eastbound-API wird die Kommunikation zwischen SDN-Controllern und Systemen ermöglicht, die kein SDN-Protokoll beherrschen. Dies können z.B. MPLS-Systeme sein, deren Anforderungen und Nachrichten mittels der Eastbound-API in für den Controller verständliche Befehle übersetzt wird.

Abbildung 2.17 zeigt die Aufteilung der unterschiedlichen Datenverkehrsrichtungen.

48 2.4 Software Deﬁned Networks

Anwendungen

Northbound

externe SDN-Systeme Westbound Eastbound Non-SDN

Southbound

SDN-Switch

Abbildung 2.17: Datenverkehrsrichtung in SDN

2.4.1.3 Zentrale Steuerung

Die Controller übernehmen im Netzwerk die zentrale Steuerung des Datenverkehrs, die Kom- munikation mit den beteiligten Switchen erfolgt über die Southbound-API. Sie bilden so eine Schnittstelle für Programme im Netzwerk und agieren dabei als eine Art Netzwerkbetriebssys- tem [TS07]. Dabei hat sich der Ursprungsbegriﬀ eines solchen Netzwerkbetriebssystem verändert, [GKP+08] beschreibt diese Abwandlung der klassischen Deﬁnition der hin zu einer programmier- baren Kontrolle über das Netzwerk:

In the past, the term network operating system referred to operating systems that incorporated networking (e.g., Novell NetWare), but this usage is now obsolete. We are resurrecting the term to denote systems that provide an execution environment for programmatic control of the network.

Auf dem Markt existieren viele unterschiedliche Controller, die diese Kommunikation steuern. Eine detaillierte Übersicht und ein Vergleich der Leistungsfähigkeit weiterer Controller ﬁndet sich in [SZZ+13] oder [SFF+13].

• Floodlight Floodlight [Pro17] basiert auf der Programmiersprache Java und stellt einen Open Source- SDN-Controller bereit. Floodlight kann durch die Nutzung von Multithreading mehrere Millionen Flows pro Sekunde verarbeiten, wodurch Floodlight zu einem der performantesten SDN-Controller gehört [KAI14].

49 2 Grundlagen

• NOX NOX basiert auf C++ und gilt als der erste OpenFlow-Controller [GKP+08]. Die ur- sprüngliche Version ist in Python und C++ programmiert und wird heute als NOX Classic bezeichnet. Die aktuelle Version ist nur noch in C++ programmiert. Die so entwickelten Anwendungen proﬁtieren somit von den Vorteilen der C++-Programmierung, so z.B. einer schnellen Verarbeitung asynchroner Ein- und Ausgabeoperationen [McC16].

• POX POX ist der Nachfolger von NOX und basiert auf der Programmiersprache Python23. POX bringt vorgefertigte Implementierungen mit, die bereits rudimentäre Funktionalitäten wie Switching ermöglichen.

• OpenDaylight OpenDaylight [MVTG14] ist in der Lage, mehrere Protokolle zu verarbeiten. So erfüllt OpenDayLight mit OpenFlow die Wahrnehmung von Managementaufgaben, Controlling- aufgeben können durch die Protokolle OF-Conﬁg und OVSDB verarbeitet werden. Zur Erweiterung und Entwicklung neuer Plugins steht mit dem Service Abstraction Layer eine separate Schicht zur Anbindung an die Forwardingplane der Netzwerkkomponenten bereit. OpenDaylight ist größtenteils in Java entwickelt, für die Entwicklung von SDN- Anwendungen oberhalb des Controllers kann jedoch auch Python genutzt werden.

• Ryu Ryu [Ryu14] basiert ebenfalls auf Python und ist in der Lage, neben OpenFlow auch weitere APIs zu nutzen. Hierzu zählen NetConf, OF-Conﬁg oder sFlow. Für die OpenStack- Implementierung existiert ein Plugin, um Ryu als SDN-Controller in der Cloud-Umgebung einzusetzen und eine homogene Administration des Controllers zu ermöglichen.

2.4.2 OpenFlow

Das im Jahr 2008 an der Stanford-University entwickelte OpenFlow-Protokoll hat sich in kurzer Zeit zum marktbeherrschendem Protokoll der Southbound-API entwickelt [BM14]. Durch die Oﬀenlegung der API ist es möglich, Switche unterschiedlicher Hersteller anzubinden und über unterschiedliche SDN-Controller über das OpenFlow-Protokoll zu steuern.

OpenFlow ermöglicht die Kommunikation zwischen Controller und beteiligten Switchen, um die Weiterverarbeitung ankommender Netzwerkpakete zu steuern oder Informationen über eine solche Weiterverarbeitung zu erhalten. Kommt ein Netzwerkpaket an einem Port des OpenFlow-

23Details zu POX ﬁnden sich unter [Nox13]

50 2.4 Software Deﬁned Networks

Switches an, prüft dieser, ob er die weitere Verarbeitung kennt. Die Verarbeitung eines Netz- werkpakets umfasst drei Aspekte:

• Identiﬁzierung des Netzwerkpakets anhand deﬁnierter Flows

• Analyse der Flow-Table

• Ausführen der vorgegebenen Regel

Im Folgenden werden Flows sowie die Verarbeitung innerhalb einer Flow-Table detailliert beschrieben und die Nachrichten zwischen Controller und OpenFlow-Switch erläutert.

2.4.2.1 Flow

Switche ohne OpenFlow-Funktionalität entscheiden anhand der Ziel-Adresse eines Ethernet- frames, an welchen Port ein Paket geleitet werden soll. Die Zuordnung zwischen Port und MAC- Adresse wird dabei in der Forwarding Information Base (FIB)24 gespeichert. Der Switch analysiert hierfür parallel zur Weiterverarbeitung die ankommenden Netzwerkpakete, ermittelt die Quell- MAC-Adresse aus dem Ethernetframe und speichert diese in Verbindung mit dem Port, an dem dieses Paket ankam, temporär in der FIB. Anschließend leitet der Switch das Paket an den Port weiter, an dem laut FIB die Ziel-MAC-Adresse angeschlossen ist.

OpenFlow erweitert die Möglichkeit zur Identifikation und Verarbeitung mit Hilfe von Flows. Ein Flow bezeichnet dabei eine Folge von Netzwerkpaketen, bei denen bestimmte Header- informationen gleich sind [MAB+08]. Diese Kombination der Headerinformationen wird für die Klassifikation genutzt, so dass Pakete wesentlich spezifischer verarbeitet werden können. Abbil- dung 2.18 zeigt die möglichen Headerinformationen einschließlich der Aufgaben in traditionellen Netzwerken.

Abbildung 2.18: OpenFlow speziﬁsche Headerinformationen

Dabei ist die Klassiﬁzierung nicht mehr nur anhand der MAC-Adresse und des Ports möglich, die Nutzung der Informationen aus höheren Schichten ermöglicht eine gestiegene Flexibilität

24nach [MF93] auch als CAM bezeichnet.

51 2 Grundlagen der OpenFlow-Switche im Vergleich zur klassischen Hardware. Somit können OpenFlow-Switche auch einfache Router und Paketﬁlter ersetzen, da diese Informationen nun durch OpenFlow verarbeitet werden. Tabelle 2.9 erläutert die Aufgabe und Position der jeweiligen Felder.

Tabelle 2.9: Adressierbare Headerfelder des OpenFlow-Protokolls Feld Position Aufgabe OSI-Schicht IngressPort Physisch Portnummer des jeweiligen Swit- Bitübertragung ches DstMAC Ethernet Ziel-MAC-Adresse Sicherung SrcMAC Ethernet Quell-MAC-Adresse Sicherung Ethertype Ethernet IDdestransportiertenProtokolls Sicherung VLANID Ethernet Identiﬁzierung des zugehörigen Sicherung VLANs VLAN Priority Ethernet QoS-Option zur Steuerung der Sicherung VLANs SrcIP InternetProtocol Quell-IP-Adresse Vermittlung DstIP InternetProtocol Ziel-IP-Adresse Vermittlung IP Proto Internet Protocol IDdesübertragenenL4-Protokolls Vermittlung Src Port TCP / UDP Quell-Portnummer Transport DstPort TCP/UDP Ziel-Portnummer Transport

2.4.2.2 Flow-Table

Kommt am OpenFlow-Switch ein Netzwerkpaket an, prüft der Switch die jeweiligen Header- felder und überprüft anschließend, ob die Kombination dieser Felder einem gespeicherten Flow entspricht. Sofern die Informationen übereinstimmen, ist dem Switch die weitere Verarbeitung des Netzwerkpakets bekannt, die durchzuführende Aktion hat der Controller übermittelt und wurde vom Switch in der Flow-Table gespeichert [Ope14]. In dieser Tabelle wird jeder Flow als einzelner Eintrag mit der zugehörigen Aktion gespeichert. Diese Aktionen bestehen aus Basisaktionen, die jeder OpenFlow-Switch erfüllen muss, möglicherweise erweitert mit herstellerspeziﬁschen Anpas- sungen.

Zu den Basisaktionen, die jeder Switch unterstützen muss, gehören z. B.

• Weiterleitung des Pakets an einen bestimmten Port (FORWARD)

• Weiterleitung des Pakets an alle Ports (FLOOD)

• Verwerfen des Pakets (DROP)

52 2.4 Software Deﬁned Networks

Darüber hinaus existieren Aktionen, die nicht zu den Basisaktionen gehören, aber für den Pro- duktiveinsatz meist unabdingbar sind:

• Modiﬁkation von Headerfeldern, z.B. TTL, MPLS

• Hinzufügen oder Ändern von VLAN-Informationen

• Weiterleitung nach Anpassung an eine weitere Flow-Table

Neben diesen Informationen werden zusätzliche statistische Daten erfasst. Diese enthalten In- formationen über die Anzahl der Pakete und Bytes sowie den Zeitpunkt der letzten Nutzung. Um ein deterministisches Verhalten zu erreichen, erhalten die Einträge noch Prioritäten. Ohne diese Prioritäten besteht die Möglichkeit, dass die Deﬁnition der Flows nicht eindeutig ist und ankommende Pakete mehreren Flows zugehörig sein können.

Der Aufbau eines Eintrags in der Flow-Table umfasst somit die in Tabelle 2.10 aufgeführten Parameter.

Tabelle 2.10: Format einer Flow-Table Parameter Aufgabe Definition Klassifikation des Flows Priorität Wertigkeit des Flows zur deterministischen Zuordnung Zähler Speicherung verschiedener statistischer Daten wie erhaltene Pakete und Bytes Aktion Beschreibung der durchzuführenden Aktion Timeout Definition von Zeitspannen, nach denen ein Flow entfernt wird Cookie Nutzung durch den SDN-Controller

Ist keine Regel für das Paket bekannt, wird eine spezielle Aktion ausgeführt. Diese wird als Table-Miss bezeichnet und regelt die weitere Verarbeitung. Die Zuordnung erfolgt anhand von Wildcards, die eine Übereinstimmung mit jedem Paket erzielen. Da die Abarbeitung der Einträge in einer Flow-Table und über mehrere Flow-Tables sequentiell erfolgt, garantiert die abschließende Identiﬁzierung per Wildcards, dass nur Pakete, die bisher nicht verarbeitet werden konnten, hiervon betroﬀen sind. Meist wird in diesem Eintrag geregelt, dass entweder das Paket oder nur die Headerdaten an den Controller übermittelt werden. Der Controller erstellt dann anhand seines Regelwerks einen neuen Flow und einen oder mehrere Flow-Table-Einträge mit auszuführenden Aktionen [Sta13].

53 2 Grundlagen

2.4.2.3 Kommunikation

Der Controller stellt seine Dienste auf Port 6633/TCP bereit und wartet dort auf Anfragen von OpenFlow-Switchen, die für die Nutzung dieses Controllers konﬁguriert sind. Der Switch baut eine Verbindung zum Controller auf, über den die weiteren Schritte erfolgen können.

Es gibt drei verschiedene Nachrichtentypen, die in einem OpenFlow-Netzwerk zum Austausch von Informationen genutzt werden.

• Controller-to-Switch Diese Nachrichten werden vom Controller initiiert und können vom Switch eine Antwort verlangen. Die nachfolgende Tabelle 2.11 listet die Untertypen auf:

Tabelle 2.11: Controller-to-Switch Nachrichten Nachricht Aufgabe Features Abfrage des Controllers bzgl. der Switch-Fähigkeiten Configuration Setzen oder Abfragen bestimmter Konfigurationsparameter Modify-State Hinzufügen, Ändern oder Löschen von Tabellen Read-State Informationsabfrage Packet-Out Das Paket wird am Switch an einem Port ausgegeben. Dafür muss das Paket oder eine Buffer-ID mit übertragen werden Barrier AbfrageüberbestimmteStati Role-Request Bestimmung des Kommunikationskanals. Wird bei der Nutzung unterschiedlicher Controller für einen Switch genutzt

• Asynchron Asynchrone Nachrichten werden vom Switch übertragen, ohne dass sie vom Controller angefordert wurden. Hierüber kann der Switch Informationen an den Controller übertragen, die außerhalb der regulären Abfragen liegen. Tabelle 2.12 listet die Untertypen auf.

Tabelle 2.12: Asynchrone Nachrichten Nachricht Aufgabe Packet-In Übertragung eines Pakets an den Controller Flow-Removed Hinweis, dass ein Flow gelöscht wurde Port-Status Hinweise über unerwartete und nicht vom Controller initiierte Port- änderungen Error ÜbertragungeinerFehlermeldungvomSwitchandenController

• Symmetrisch Symmetrische Nachrichten können von beiden Seiten übertragen werden, ohne dass eine Seite dies explizit anfordert. Tabelle 2.13 listet die Untertypen auf.

54 2.5 Network Function Virtualization

Tabelle 2.13: Symmetrische Nachrichten Nachricht Aufgabe Hello ÜbertragungwährenddesVerbindungsaufbaus Echo Request / Replies werden zur Überwachung der Erreichbarkeit versandt Experimenter Reserviert für spätere Nutzung

Jede dieser Nachrichten hat wiederum eine Vielzahl von Untertypen, die spezielle Aufgaben wahrnehmen.

2.5 Network Function Virtualization

In diesem Abschnitt wird ein Architekturkonzept für Netzwerke beschrieben, das es ermöglicht, hardwarebasierte Lösungen in virtualisierter Form anzubieten. Diese als NFV bezeichnete Tech- nik zielt darauf ab, unterschiedliche Funktionalitäten im Netzwerk durch Softwarekomponenten abzubilden.

2.5.1 NFV Framework

NFV als Teil der Netzwerkvirtualisierung umfasst sämtliche Bereiche der Netzwerktechnik. Hier- zu gehören Router, Switche oder auch Firewallsysteme. Ziel ist es dabei, die Aufgaben unterschiedlichster Systeme von der Hardware zu abstrahieren und virtualisiert auf Standardhardware anzubieten [Eur12]. Hierdurch ist es wiederum möglich, Funktionalitäten an unterschiedlichen Stellen im Netzwerk zu implementieren, ohne neue Hardware zu beschaﬀen, zu installieren und bereitzustellen [MSG+16].

In [Eur14] wird das NFV Framework deﬁniert, welches die relevanten Komponenten innerhalb dieser Netzwerkarchitektur beschreibt. Das Framework besteht dabei aus drei Bereichen.

• VNF Mit Virtualised Network Function (VNF) werden die Softwareimplementierungen beschrieben, die die Aufgaben der klassischen Hardwarekomponenten übernehmen. Diese werden innerhalb einer NFV Infrastructure (NFVI) betrieben.

• NFVI Die Umgebung, in der sämtliche Hard- und Softwarekomponenten betrieben werden, wird als NFVI deﬁniert. In dieser Umgebung werden die VNF auf den vorhandenen Plattformen

55 2 Grundlagen

betrieben, um ihre Dienste zur Verfügung stellen zu können. Eine NFVI kann sich dabei über mehrere RZ verteilen.

• NFV-MANO Die Komponenten innerhalb der NFVI werden durch das NFV Management and Operations (NFV-MANO) verwaltet und gesteuert. Sämtliche notwendigen Verwaltungsaufgaben und - informationen werden durch das NFV-MANO bereitgestellt. [Eur14] beschreibt eine weitere Unterteilung der NFV-MANO in

– NFV Orchestrator für die Verwaltung der Orchestrierungsaufgaben innerhalb der NFVI.

– VNF Manager für die Verwaltung der anfallenden Aufgaben bei einem VNF.

– Virtualised Infrastructure Manager für die Verwaltung der Konﬁgurationsaufgaben in einem separaten Teil der NFVI.

Im Gegensatz zu SDN zielt NFV eher auf die Virtualisierung einzelner Komponenten ab, die dennoch zentral von einem Controller gesteuert werden können. Die gemeinsame Nutzung beider Techniken schließt sich dabei keinesfalls aus. Controller aus dem Bereich des SDN etablieren die Programmierbarkeit und die zentrale Steuerung des gesamten Netzwerks, welches aus Hardware- komponenten und virtuellen Instanzen in Form eines vSwitch oder auch Virtual Router (vRouter) besteht [MS13]. Trotz der recht jungen Technologie haben sich bereits mehrere Implementie- rungen am Markt etabliert und bieten dem Kunden eine Vielzahl von Einsatzmöglichkeiten für Router, Switche oder Security-Appliances. So bietet die Firma Brocade mit Vyatta einen vRouter an, der alle Aufgaben klassischer Router übernimmt [VYA13]. Die Firma F5 stellt mit der Lösung vFW [F5 15] eine virtuelle Firewallumgebung bereit, die die Funktionalitäten von Hardwarelö- sungen in virtuelle Systeme überführt.

Neben kommerziellen Lösungen existiert mit OVS eine Open Source Lösung, die im Abschnitt 2.5.3 detailliert vorgestellt wird. Durch seine Flexibilität wird OVS in einer Vielzahl von Soft- wareprojekten eingesetzt und zählt somit zu den wichtigsten Implementierungen im Bereich der vSwitche [AB12]. Neben Cloud-Umgebungen wie OpenStack oder OpenNebula wird OVS auch in Virtualisierungsumgebungen wie Proxmox [Ahm16] oder Datacenterlösungen wie oVirt [Les13] zur Vernetzung der verschiedenen Instanzen genutzt.

56 2.5 Network Function Virtualization

2.5.2 Vorteile

In Netzwerken übernehmen unterschiedliche Komponenten die anfallenden Aufgaben der Paket- weiterleitung, -verarbeitung und -steuerung. Die Flexibilität in modernen Umgebungen führt zu einer großen Vielfalt unterschiedlichster Komponenten, Hersteller und Geräte, die sich hinsichtlich des Administration unterscheiden. Da die Notwendigkeit dieser Funktionalitäten unbestritten ist, sind CSP gezwungen, diese Komponenten einzusetzen. Jedoch bietet nicht jeder Hersteller die gleichen Geräte und Möglichkeiten an, so dass viele unterschiedliche Geräte im Netzwerk betrieben werden müssen. Notwendige Anpassungen und Änderungen dynamisch anzupassen ist mit diesen Geräten meist nicht möglich.

Die Nutzung virtualisierter Netzwerkfunktionen bietet für diese virtuellen Umgebungen viele Verbesserungen und Möglichkeiten, die die Probleme der statischen Komponenten beseitigen [HSMA14].

2.5.2.1 Skalierbarkeit

Sofern klassische Hardwarekomponenten an ihre Auslastungsgrenzen stoßen, bleibt meist nur der Neukauf leistungsfähigerer Komponenten oder die Erweiterung durch zusätzliche Geräte. Wenn die virtualisierten Komponenten ihre Auslastungsgrenze erreichen, ist es unter Umständen bereits ausreichend, die Installation auf eine leistungsfähigere Standardhardware umzuziehen und so zusätzliche Ressourcen für den Betrieb zu erhalten.

2.5.2.2 Schnelligkeit

Die Bereitstellung relevanter Netzwerkfunktionalitäten in Software ermöglicht eine schnellere Inbetriebnahme als bei der Nutzung klassischer Hardware. Sofern die Funktionalität benötigt wird, kann sie durch Installation an der entsprechenden Position im Netzwerk bereitgestellt werden.

Bei Betrachtung der Schnelligkeit im Hinblick auf die Leistungsaspekte unterscheiden sich virtualisierte Komponenten und spezialisierte Hardwaregeräten jedoch noch. [ERWC14] vergleicht die Performance unterschiedlicher vSwitche und stellt bereits hier Unterschiede in der Datenüber- tragungsgeschwindigkeit fest. [GME12] untersuchte die Geschwindigkeit des vRouters Yvatta im Vergleich zu einem Hardwarerouter bei der Nutzung unterschiedlicher Routingprotokolle und

57 2 Grundlagen stellte auch hier eine höhere Performance dedizierter Geräte fest. Bei der Wiederherstellung der Konvergenz25 ist jedoch der vRouter schneller.

2.5.2.3 Flexibilität

Die vollständige Implementierung in Software ermöglicht eine dynamische Anpassung an lokale Gegebenheiten. Während hardwarebasierte Komponenten durch Erweiterungskarten oder zusätzliche Module an Änderungen angepasst werden müssen, können virtualisierte Geräte durch Lizenzanpassungen oder Erweiterungen durch Standardhardware26 ﬂexibler angepasst und auf Kundenwünsche zugeschnitten werden. Gleichzeitig erhöht diese Flexibilität den Automatisie- rungsgrad der virtuellen Umgebung, da die Softwarekomponenten über Standardschnittstellen administriert werden können [BREGE13].

2.5.3 Open vSwitch

OVS ist eine der meistgenutzten Implementierungen der NFV [AB12]. OVS implementiert einen vSwitch, der eine Vielzahl von Funktionalitäten hardwarebasierter Switche in Software bereitstellt. In diesem Abschnitt wird sowohl der Funktionsumfang als auch die Architektur von OVS beschrieben.

2.5.3.1 Funktionsumfang

Die reine Implementierung des Switching führt nicht zu der marktbeherrschenden Position von OVS. Das Switching innerhalb virtueller Umgebungen ist auch durch einfache Implementierungen im Linuxkernel möglich, so wurde in der Vergangenheit27 mit der Linuxbridge eine entsprechende Technik zur Vernetzung von zwei Ethernetabschnitten genutzt. OVS stellt demgegenüber voll- wertige Switchingfunktionalität bereit und erweitert so die Funktionalität der Linuxbridge um ein Vielfaches, so dass OVS mit leistungsfähigen Hardwareswitchen vergleichbar ist [PGP+10]. OVS wurde daher am 18. März 2012 oﬃziell in den Linuxkernel aufgenommen28.

• Quality of Service Die Quality-of-Service-Möglichkeiten von OVS ermöglichen eine Steuerung der maximalen Übertragungsraten und Datenmengen. So bieten Befehle wie ingress_policy_rate oder

25Hierunter versteht man im Routing die Fähigkeit, nach einer Änderung im Netzwerk möglichst schnell wieder in einen stabilen Betriebszustand, d. h. den korrekten Zustand der jeweiligen Routingtabellen, zurückzukehren. 26So können zusätzliche Netzwerkkarten durch den Einbau von geeigneten NICs erreicht werden, eine Nutzung (teurerer) Spezialkarten entfällt. 27Eingeführt wurde dies mit dem Linuxkernel 2.2 im Jahr 1999. 28Es handelt sich dabei um die Version 3.3.

58 2.5 Network Function Virtualization

ingress_policy_burst die Einstellung von separaten Werten für jedes virtuelle Interface, die für die angeschlossenen VMs gültig sind.

• Bonding Die Technik, mehrere Interfaces zu einem logisch zusammenhängenden Interface zusam- menzuschalten, bietet die Möglichkeit, mehr Bandbreite zur Datenübertragung zu erhalten.

• Sicherheit OVS bietet mit VLAN, VXLAN, STT, MPLS oder GRE viele mögliche Implementierungen der Separierung unterschiedlicher Netzwerke an. Hierdurch können die angeschlossenen Systeme voneinander isoliert auf einer Instanz betrieben werden.

• Hypervisorintegriät OVS wurde vorrangig für das Linuxumfeld entwickelt und ermöglicht durch seine Zu- sammenarbeit mit einer Vielzahl unterschiedlicher Hypervisors eine ﬂexible Nutzung zur Vernetzung der betriebenen VMs.

• Managementfunktionalität Das Management der anfallenden Netzwerkdaten spielt in großen Netzwerken eine wichtige Rolle. Durch die Unterstützung gängiger Standards wie Netﬂow und sﬂow bietet OVS die Möglichkeit, statistische Daten über die transportierten Datenmengen und -arten zu erhalten und für die weitere Auswertung zu nutzen. Durch die Bereitstellung eines CLI ist eine skriptgesteuerte Administration ebenfalls möglich.

2.5.3.2 Architektur

Die Geschwindigkeit der Paketweiterleitung ist für Switche ein entscheidendes Kriterium. Damit OVS einen hohen Durchsatz erreicht, ist eine spezielle Architektur notwendig, die verschiedene Dienste und Konﬁgurationen nutzt. Hierzu nutzt OVS zwei Hauptmodule, die im Userspace laufen, sowie ein spezielles Kernelmodul [PPK+15].

Für die reine Paketweiterleitung agiert der Dienst ovs-vswitchd im Userspace und verwaltet dort die Instanzen sowie die Verarbeitung der Pakete. Die Entscheidungen der Verarbeitung werden anschließend an das Kernelmodul kernel datapath weitergeleitet. Dieses speziell für das zugrundeliegende Betriebssystem programmierte Modul ist in der Lage, die ankommenden Netzwerk- pakete, die den Verarbeitungsregeln entsprechen, direkt weiterzuleiten. Hierdurch erreicht das Gesamtsystem eine hohe Performance [PPA+09].

59 2 Grundlagen

Die anfallenden Informationen über den Datenverkehr und die aktuelle Konﬁguration speichert OVS persistent in der Open vSwitch DataBase (OVSDB), welche durch das zweite Userspace- modul namens ovsdb-server verwaltet wird.

Abbildung 2.19 stellt die Interaktion zwischen den Modulen sowie ausgewählten Programmen schematisch dar.

ovs-dpctl ovs-appctl

Extern OpenFlow

Unix

Socket

Userspace netlink Kernelspace

Abbildung 2.19: Open vSwitch Architektur, nach [PPK+15]

Aus Kompatibilitätsgründen wird mit dem Userspacemodul ovs-brcompatd die Kompatibilität zu dem klassischen Bridgemodul gewahrt, für die neuen Funktionalitäten hat dies jedoch keine Auswirkungen.

2.6 Netzwerkforensik

Die IT-Forensik hat das Ziel, Vorgänge im Zusammenhang mit Computersystemen mithilfe unterschiedlicher Ermittlungs- und Analysemethoden nachzuweisen und Straftaten im Bereich der Computerkriminalität aufzuklären. [Bun11] deﬁniert wie folgt:

IT-Forensik ist die streng methodisch vorgenommene Datenanalyse auf Datenträ- gern und in Computernetzen zur Aufklärung von Vorfällen unter Einbeziehung der Möglichkeiten der strategischen Vorbereitung insbesondere aus der Sicht des Anla- genbetreibers eines IT-Systems.

Diese Arbeit beschäftigt sich mit der Netzwerkforensik in virtuellen Umgebungen. Nach einer detaillierten Begriﬀsbestimmung und Deﬁnition erfolgt eine Beschreibung der Aufgaben und Phasen der Netzwerkforensik. Neben diesem Teilbereich sind aufgrund der Komplexität aktueller IT-Umgebungen weitere Disziplinen der IT-Forensik existent. Manchmal ermöglicht erst die

60 2.6 Netzwerkforensik

Kombination einer der folgenden Teildisziplinen mit der Netzwerkforensik die Aufklärung des Sachverhalts.

• Computerforensik Die Computerforensik beschäftigt sich mit der Datensicherung, Analyse und Aufbereitung der auf Computersystemen gespeicherten Daten. Dies umfasst neben klassischen PCs und Notebooks auch Server und Speichersysteme wie Network Attached Storage (NAS) oder Storage Area Network (SAN).

• Mobilfunkforensik Durch die gestiegene Leistungsfähigkeit und die angebotenen Erweiterungen dienen Mo- bilfunkgeräte wie Tablets oder Smartphones immer häufiger als Ersatz für PCs und Note- books. Dies bietet dem Nutzer nahezu vollständige Arbeitsumgebungen, wodurch auch An- greifer ein gesteigertes Interesse am Zugriff auf diese Geräte bekommen [Fre12], [Fir15b]. Die Hauptaufgabe der Mobilfunkforensik ist es, diese mobilen Endgeräte forensisch zu analysieren, relevante Daten zu sichern und angepasst aufzubereiten. Dabei sind neben Bildern und Videos, die auch bei der Computerforensik relevant sind, zusätzlich spezielle, gerätebezogene Details wie Gesprächsdaten, SMS- / MMS-Informationen, Kontaktdaten, Kommunikationsdaten wie Internetverläufe, Chat oder EMail sowie installierte Apps von Wichtigkeit. Diese Daten können meist mit klassischen Werkzeugen der Computerforen- sik nicht aufbereitet werden, sondern verlangen spezielle Tools und Herangehensweisen [Yat10]. Mit Hilfe gespeicherter Bewegungsprofile ist es für Forensiker zudem möglich, festzustellen, ob sich ein Gerät zu einem bestimmten Zeitpunkt an einem gegebenen Ort befunden hat.

Daneben existieren noch weitere Teilbereiche der IT-Forensik, jeder davon mit einem speziellen Einsatzgebiet. So beschäftigt sich die Datenbankforensik mit der Extraktion von Informationen und Daten aus Datenbankmanagementsystemen sowie der Aufbereitung zur Verfügung stehen- der Informationen [TM12]. Die Multimediaforensik ist hingegen auf die Analyse von Bild- und Videomaterial spezialisiert und beschäftigt sich dabei häuﬁg mit Fragen der Authentizität der Daten [YSC07].

2.6.1 Deﬁnition

Die Netzwerkforensik als Teildisziplin der IT-Forensik beschäftigt sich mit der Analyse von Vor- gehen in Netzwerken. [PJN10a] deﬁniert die Netzwerkforensik als Teilbereich der IT-Forensik und beschreibt die drei Hauptarbeitsschritte, die in der Netzwerkforensik relevant sind:

61 2 Grundlagen

Network forensics is the science that deals with capture, recording, and analysis of network traﬃc. [...] Network forensics is a natural extension of computer forensics.

Im Folgenden werden die Aufgaben dieses dreistuﬁgen Prozesses konkret deﬁniert. Jede dieser Aufgaben muss korrekt durchgeführt werden, um eine valide Untersuchung zu garantieren. Fehler in der Aufzeichnung haben unmittelbare Auswirkung auf die nachfolgenden Aufgaben. So können fälschlicherweise aufgezeichnete Pakete die spätere Analyse verfälschen, da zusätzliche, nicht relevante Informationen mit in die Auswertung einbezogen werden.

2.6.2 Aufzeichnung

Im Rahmen der Computerforensik stehen die Daten durch die Speicherung auf persistenten Datenträgern häuﬁg automatisch zur Verfügung. Erst Techniken wie die Arbeitsspeicheranalyse verlangen eine aktive Einﬂussnahme zur Datengewinnung. Die Computerforensik ist daher auch als reaktiv zu bezeichnen. Demgegenüber verlangt die Netzwerkforensik aktives Handeln, um eine erfolgreiche Datenaufzeichnung einzurichten.

Die Aufzeichnung der Daten hat das Ziel, sämtliche relevanten Netzwerkpakete zu identifizieren und an das Speichersystem weiterzuleiten. Hierzu erfolgt zuerst die Identifikation des Zielsys- tems, je nach Aufzeichnungsstrategie anhand der MAC- oder IP-Adresse oder auch anhand der Netzwerkkarte. Erst nach dieser Identifizierung kann die Aufzeichnung erfolgen.

Anschließend wird durch Konﬁguration der Komponenten oder Neuvernetzung die Übertragung der anfallenden Netzwerkdaten auf das Sicherungssystem sichergestellt. Techniken zur Aufzeich- nung unterscheiden sich je nach Einsatzzweck, realisierbaren Möglichkeiten oder vorhandener Hardware. Grundsätzlich wird aus den folgenden Implementierungen eine Möglichkeit ausge- wählt:

• TAP Test-Access-Ports werden in die physische Netzwerkverbindung eingeschleift und ermögli- chen so eine vollständige Datenaufzeichnung der durchgeleiteten Daten. Ein TAP besitzt einen Eingangsport sowie einen Ausgangsport für das Ziel-System und einen Port für das Aufzeichnungssystem. Durch die interne Logik ist es möglich, sämtliche anfallenden Daten zum Aufzeichnungssystem zu spiegeln. Fällt der TAP aus, stellt diese interne Logik sicher, dass die Daten nach kurzer Zeitverzögerung wieder an das Zielsystem geleitet werden. Die Ausleitung an das Aufzeichnungssystem ist dann jedoch nicht mehr möglich.

• Bridge Eine Bridge wird ebenfalls in die physische Netzwerkverbindung eingeschleift, allerdings

62 2.6 Netzwerkforensik

erfolgt die Aufzeichnung direkt auf der Bridge. Fällt die Bridge aus, scheitert die gesamte Kommunikation, da keine Daten weitergeleitet werden können.

• Mirrorport Als Mirrorport werden spezielle Ports an Hardwareswitchen bezeichnet, die durch An- passung der Konﬁguration den Datenverkehr von einem Port auf diesen Mirror spiegeln. Mirrorports werden auch als Switch Port Analyzer (SPAN) bezeichnet. Während die ersten beiden Möglichkeiten zusätzliche Hardware darstellen, die in die bestehende Datenverbin- dung eingebracht werden, kann ein Mirrorport ohne zusätzliche Hardware implementiert werden.

Neben diesen drei Aufzeichnungstechniken existieren noch zwei weitere Techniken, um Netzwerk- daten aufzuzeichnen. Diese sind jedoch eher für kleinere Untersuchungen wie Malwareanalyse oder Testumgebungen geeignet.

• Virtualisierung Virtuelle Umgebungen ermöglichen es, schnell neue Systeme bereitzustellen. Ebenso ist es möglich, Schadsoftware in virtuellen Sandboxumgebungen laufen zu lassen und den anfallenden Datenverkehr aufzuzeichnen. Gängige Virtualisierungsumgebungen bieten dabei die Möglichkeit, direkt ohne zusätzliche Programme die anfallenden Netzwerkdaten zu spiegeln.

• Proxy Aus netzwerkforensischer Sicht sind Proxys als Man-in-the-Middle (MITM)-Techniken nutzbar, um den Datenverkehr über ein weiteres System zu leiten und hier aufzuzeichnen. Im Gegensatz zu den vorgenannten Methoden stehen hier je nach Implementierung sofort interpretierte Daten zu Verfügung, die aufgrund der Umleitung auch noch vor der Weiter- leitung manipuliert werden können. Die Rohdaten werden von den meisten Systemen dabei vor dem direkten Zugriﬀ versteckt.

Es existiert zur Aufzeichnung keine Lösung, die für alle Einsatzgebiete geeignet ist. Techniken wie TAPs oder Bridges, die zusätzliche Hardware in der Netzwerkumgebung benötigen, führen zu einem zumindest kurzfristigen Verbindungsausfall, da die Verkabelung geändert werden muss. Mirrorports haben dieses Problem nicht, da die Spiegelung des Datenverkehrs auf dem Switch erfolgt und die Konﬁguration keine Veränderung der Verkabelung verlangt. Allerdings entsteht in Netzwerken mit einer hohen Datenübertragungsrate das Problem, dass Paketverluste auftreten können, weil nicht alle Pakete zeitgleich übertragen werden können.

Während die Aufzeichnung in kabelgebundenen Netzwerken relativ einfach erreicht werden kann, stellen kabellose Netzwerke zusätzliche Anforderungen bereit. [CZM14] führt mögliche Störun- gen, Kanalwechsel, Mobilität der Nutzer sowie die Signalabdeckung als Problemfelder auf.

63 2 Grundlagen

2.6.3 Speicherung

Die reine Aufzeichnung der Daten ist nicht ausreichend, da eine Liveanalyse der anfallenden Daten nur selten möglich ist. Aus diesem Grund müssen die Daten gespeichert werden, hierzu existieren unterschiedliche Formate, die im Folgenden aufgeführt werden. Filter reduzieren die Datenmenge, der gewählte Speichermodus bestimmt die Anzahl und Art der Aufzeichnungsdaten. Im ersten Schritt muss zudem meist ein Aufzeichnungssystem installiert oder bereitgestellt werden, welches über ausreichend großen Speicherplatz und performante Netzwerkanschlüsse verfügt.

2.6.3.1 Captureﬁlter

Ein Captureﬁlter wird bereits während der Aufzeichnung des Datenverkehrs benutzt. Hierbei prüft das Aufzeichnungssystem, ob die aktuell auftretenden Daten dem Filterkriterium entsprechen und somit aufgezeichnet werden müssen. BSD Packet Filter (BPF) [MJ93] ermöglichen es, die ankommenden Netzwerkpakete zu analysieren und entsprechend zu ﬁltern. Dazu wandeln die Aufzeichnungsprogramme die angegebenen Filterkriterien in BPF-Bytecode um, so dass die Filterung direkt im Kernelkontext erfolgen kann.

Der Einsatz von Filtern birgt jedoch zusätzliche Risiken:

• Durch die manuelle Filterung und der damit verbundenen Reduzierung besteht die Mög- lichkeit, dass relevante Netzwerkdaten übersehen werden und daher nicht für die spätere Analyse zur Verfügung stehen.

• Die fehlende Eindeutigkeit der Kriterien kann die Aufzeichnung erschweren.

• Komplexe Filter können zu schwer erkennbaren Fehlern führen, die ungewollte Ergebnisse produzieren.

2.6.3.2 Dateiformat

Für die Speicherung der aufgezeichneten Daten stehen unterschiedliche Formate zur Verfügung, die vom aufzeichnenden System abhängig sind. Eine Umwandlung zwischen den unterschiedlichen Formaten ist möglich, allerdings je nach Zielformat mit Informationsverlusten verbunden. Exemplarisch werden die vier häuﬁgsten Formate beschrieben:

• raw Das raw-Format ist das älteste Aufzeichnungsformat und heute eigentlich nicht mehr sinnvoll einzusetzen, da es in der Leistungsfähigkeit stark eingeschränkt ist. So ist die Auf-

64 2.6 Netzwerkforensik

zeichnung der Daten sehr ineﬃzient, da für jedes Paket ein oder sogar zwei Systemcalls notwendig sind29:

In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very ineﬃcient. It uses very limited buﬀers and requires one system call to capture each packet, it requires two if you want to get packet’s timestamp (like libpcap always does).

Sollte jedoch keine libpcap-Bibliothek vorhanden sein, ist das raw-Format die einzige Mög- lichkeit, Pakete mitzuschneiden.

• libpcap Das Format libpcap [Gar08] ist ein moderneres Aufzeichnungsformat, welches lange Zeit als Standard galt und erst seit einiger Zeit langsam von PcapNg abgelöst wird. Das Format ist Teil einer API, um Netzwerkdaten mitzuschneiden. Das libpcap-Format wird von nahezu allen netzwerkforensischen Werkzeugen unterstützt, sei es zum Speichern oder zumindest, um die Daten lesen zu können. Eine per libpcap-Format erstellte pcap-Datei besteht aus einem globalen Header, darauf folgt sequentiell jedes Paket, unterteilt nach Header und den Daten.

• PcapNg Das Packet Capture Next Generation-Format wurde im Jahr 2004 als Nachfolger vom libpcap-Format entwickelt [MTRBH14] und wird mittlerweile von einigen Programmen als Standardspeicherformat angeboten.

PcapNg bietet einige Vorteile gegenüber dem libpcap-Format.

– Gleichzeitige Aufzeichnung von mehreren Interfaces in eine Datei30

– Verbesserte Zeitstempel mit einer Genauigkeit von 264 Bit31

– Implementierung einer Kommentarfunktion für jedes aufgezeichnete Paket

– Speicherung zusätzlicher Metadaten zur Datei

• Snoop Das snoop-Format [CG95] wird vorrangig auf Solaris-Systemen eingesetzt, um Netzwerk-

29Details ﬁnden sich in der Beschreibung zu PACKET_MMAP im Linux-Kernel unter [Ker17] 30Hierzu wird jedem Paket mit Hilfe des Interface Description Blocks die Informationen über das beteiligte Interface mitgegeben. 31Das libpcap-Format bietet ein 32 Bit großes Feld für die Speicherung des Aufzeichnungszeitpunkts, wodurch die kleinste Zeiteinteilung eine Mikrosekunde ist. Durch die Vergrößerung des Speicherbereichs sind nur fein- granulierte Speicherungen möglich.

65 2 Grundlagen

daten aufzuzeichnen, zu speichern und zu analysieren. Die Limitierung auf diese Syste- me führt dazu, dass gängige Programme der Netzwerkanalyse auf anderen Systemen das snoop-Format nicht lesen können. Die gespeicherten snoop-Dateien müssen somit erst in ein anderes Format umgewandelt werden, bevor eine Analyse mit libpcap-basierten Pro- grammen möglich ist.

2.6.4 Auswertung

Während die ersten beiden Aufgaben aktiv implementiert werden, um sämtliche relevanten Daten zu erhalten, erfolgt die Analyse der Daten nachträglich. In [SE16b] wird diese Trennung in Online- und Offline-Phasen definiert. Die Online-Phasen, bestehend aus der Aufzeichnung und der Speicherung, verlangen eine aktive Arbeit im laufenden Netzwerk. Demgegenüber steht die nachträgliche Analyse, die offline ohne Zugriff auf das überwachte Netzwerk erfolgt.

Die Aufgabe der Analyse ist abhängig vom Sachverhalt, meist handelt es sich jedoch um die Beantwortung der Frage:

„Wer hat wann, wie, mit wem, wie häuﬁg und wie lange mit welcher Technik kommuniziert?“

Hierzu werden die zur Verfügung stehenden Informationen der unterschiedlichen Schichten extrahiert und aufbereitet. Relevante Informationen ﬁndet man in den Zeitstempeln der Pakete, den MAC-Adressen auf Layer 2, den IP-Adressen auf Layer 3, den Portnummern sowie den ACK- und SEQ-Nummern auf Layer 4 sowie den Anwendungsprotokollen des Layer 7. Mit Hilfe von Displayﬁltern kann der zu untersuchende Datenverkehr reduziert werden, um relevante Ereignisse einzugrenzen und weitere Analysen zu vereinfachen.

Durch Feststellung der Kommunikationspartner anhand von Namen und IP-Adressen, Bestim- mung von Geolokationen mit Hilfe von Geo-IP-Datenbanken, Extraktion der TCP-Flows und der Aufbereitung der übertragenen Anwendungsdaten lassen sich Antworten auf die oben aufgeführ- ten Fragen ﬁnden. Durch Verschlüsselung und Anonymisierung werden diese Analysen jedoch erschwert, die Fragmentierung der Netzwerkpakete verkompliziert ebenfalls die Aufbereitung der Daten.

Im Gegensatz zu Auswertungen von Computern oder Mobilfunkgeräten liegen die Nutzerdaten bei der Netzwerkforensik nicht direkt vor. Während Bilder und Videos auf PCs oder Handys durch Carving oder logische Suchen gefunden werden können, sind die Daten in den gespeicherten Netzwerkmitschnitten fragmentiert, in falscher Reihenfolge gespeichert oder innerhalb der Streams mehrfach vorhanden, da Pakete aufgrund von vermeintlichen Störungen mehrfach versandt und somit auch gespeichert wurden. Erst die Nutzung spezieller Werkzeuge ermöglicht unter Umständen die Extraktion der Nutzerdaten.

66 3 Forschungsstand

In diesem Kapitel wird der aktuelle Forschungsstand der Cloud- und der Netzwerkforensik beschrieben. Während Forschungen in diesen Bereiche für sich allein betrachtet in zahlreichen wissenschaftlichen Arbeiten und Publikationen Thema sind, ist das Gebiet der Netzwerkforensik in Cloud-Umgebungen und somit auch in virtuellen Netzwerken bisher kaum Thema in wissenschaftlichen Arbeiten.

Zuerst werden aktuelle Forschungsthemen der Netzwerkforensik beschrieben. Hierzu gehören Be- reiche wie die Metadatenanalyse oder Untersuchungen der steigenden Zunahme von Netzwerk- daten, wodurch gängige Aufzeichnungstechniken an ihre Grenzen stoßen. Da die in dieser Arbeit erarbeiteten Methoden vorrangig im Bereich von Strafverfolgungsbehörden und nur sekundär für Fehleranalyse und Troubleshooting relevant sind, erfolgt in diesem Abschnitt eine Untersuchung aktueller Arbeiten, die besonders auf Strafverfolgungsbehörden Gültigkeit haben.

Anschließend stellt der Abschnitt 3.2 aktuelle Forschungen der Cloud-Forensik dar. Aufbauend auf diesen Forschungen stellt der Abschnitt 3.3 grundlegende Arbeiten der Forensik in virtuellen Netzwerken vor. Eine Analyse von antiforensischen Möglichkeiten und deren Forschungen schließt dieses Kapitel ab.

3.1 Netzwerkforensik

Bereits seit der beginnenden Vernetzung von Rechnern wurde vereinzelt die Notwendigkeit zur Analyse der Netzwerkdaten sichtbar. Dabei wurde jedoch ohne wissenschaftlichen Hintergrund einzig auf der Erfahrung des Verantwortlichen basierend die Untersuchung durchgeführt. In [Ran97] wird zum ersten Mal der Begriff „network forensics“ benutzt, ohne jedoch eine konkrete Definition anzugeben. Eine der ersten zielgerichteten wissenschaftlichen Auseinandersetzung mit dem Thema der Netzwerkforensik findet sich in [Gar97], wo bereits auf die Schwierigkeit der Datenaufzeichnung hingewiesen wurde.

Capturing everything moving over the network is simple in theory, but relatively complex in practice. I call this the ”catch it as you can” approach. [...] Another

67 3 Forschungsstand

approach to monitoring is to examine all of the traﬃc that moves over the network, but only record information deemed worthy of further analysis.

Weitere grundlegende Arbeiten über Methoden und Techniken der Netzwerkforensik sind in [Cas04], der die Möglichkeiten der Paketanalyse beschreibt, [PN12] mit einer Analyse webbasier- ter Angriffe, [MAM09] mit einer Übersicht über netzwerkforensische Werkzeuge und [CPS+02] mit einer Beschreibung der Aufteilung in die Phasen der Aufzeichnung und Analyse zu finden. Ansätze zur Auswertung spezifischer Netzwerktechniken und -anwendungen sind ebenfalls seit vielen Jahren Forschungsthema und finden sich unter anderem in [PF09] und [Gao11] zum Thema Voice over IP (VoIP) oder auch [LCX13] für den Bereich der sozialen Netze.

Die Durchführung netzwerkforensischer Arbeiten ist seitdem nur wenigen Schwankungen unterworfen. Dennoch existieren mehrere Forschungsgebiete der Netzwerkforensik, eine Übersicht liefert [KGW+16]. Aber auch hier fehlt die Betrachtung der verstärkt eingesetzten virtuellen Netzwerke und die Notwendigkeit für ein verändertes Vorgehen, da klassische Methoden in diesen Umgebungen nicht mehr funktionieren.

3.1.1 Fokus der Strafverfolgung

Die Durchführung netzwerkforensischer Arbeiten in der Strafverfolgung unterscheidet sich elementar von anderen netzwerkforensischen Analysen.

Eines der Hauptziele von CSPs oder anderen Anbietern ist meist die Gewinnerzielung [Hei13], hierfür werden sichere und stabil laufende Umgebungen benötigt. Um dies zu erreichen, betreiben professionelle Anbieter einen nicht unerheblichen personellen und materiellen Aufwand, um so das Risiko eines Angriﬀes und daraus resultierender Schäden zu minimieren.

Neben klassischen Sicherungsmaßnahmen wie Firewallimplementierungen und NAC-Systemen werden auch reaktive Techniken wie IDS, IPS oder fortgeschrittene Methoden wie Network Se- curity Management (NSM) eingesetzt [DB11]. Zielrichtung eines NSM ist die Aufzeichnung und Analyse des anfallenden Netzwerkverkehrs, um eventuelle Angriﬀsmuster oder Schadsoft- ware zu erkennen und entsprechend zu reagieren. NSM nutzen hierfür klassische Networkbased IDS (NIDS), die zusammen in einer Sicherheitsarchitektur arbeiten [Gup12]. Diese NIDS analysieren dabei in Echtzeit die Netzwerkpakete auf unterschiedliche Kriterien wie die Kombination bestimmter Headerfelder oder Schlüsselwörter im Datenstrom. Wird ein Paket dabei als relevant eingestuft, ist die weitere Verarbeitung von der Regeldeﬁnition abhängig. Wird ein Paket hingegen als unkritisch bewertet, werden keine weiteren Details zum Paket gespeichert.

Zusätzlich speichern Provider mit Hilfe von Managementprotokollen wie Simple Network Mana- gement Protocol (SNMP), Netﬂow oder sFlow statistische Daten zum anfallenden Netzwerkver-

68 3.1 Netzwerkforensik kehr. Hierbei werden ebenfalls nur Teile der Netzwerkdaten für die weitere Bearbeitung gespeichert.

Im Rahmen von Ermittlungen durch Strafverfolgungsbehörden sind diese teilweisen Aufzeichnun- gen nicht nutzbar. Ziel dieser Ermittlungen ist es, Beweise für oder gegen einen oder mehrere Beschuldigte zu ﬁnden. Hierzu werden bei Nutzung von Computern sämtliche Daten analysiert, im Rahmen einer netzwerkforensischen Untersuchung bedeutet dies die Aufzeichnung des gesamten Datenverkehrs des Zielsystems. Während dies in klassischen Umgebungen einfach umsetzbar war, verändert sich dies in virtuellen Netzwerken, dennoch existiert zu diesem Bereich nur wenig Forschungsarbeit. Der Grund hierfür liegt vermutlich an der sehr eingeschränkten Zielgruppe solcher Lösungen. Einzig Ermittlungsbehörden sind an forensischen Untersuchungen interessiert, die das Ziel haben, sämtliche Daten eines einzelnen Systems aufzuzeichnen. Eine forensisch korrekte Durchführung mit gerichtsverwertbaren Auswertungen ist für CSP nicht relevant. In ähnlich gelagerten Umsetzungen wie z.B. SIP-Trunking, welches zur Ablösung klassischer ISDN- Telefonanlagen eingesetzt wird, hat der Gesetzgeber mit dem § 110 Telekommunikationsgesetz (TKG) zur Umsetzung von Überwachungsmaßnahmen und dem § 113 TKG zur Auskunftsertei- lung dafür gesorgt, dass die Provider geeignete Schnittstellen für Ermittlungsbehörden bereitstellen müssen. Im Bereich der virtuellen Netzwerke sind solche Regelungen bisher nicht umgesetzt.

In [Eur16] ﬁnden sich Beschreibungen für die Durchführung netzwerkforensischer Arbeiten von Strafverfolgungsbehörden in virtuellen Netzwerken. Allerdings beschränkt sich diese Arbeit auf die lückenhafte Auﬂistung von Problembereichen, ohne detaillierte Information zu liefern. Ähnlich beschreibt [Nat04] die forensische Arbeit für Strafverfolgungsbehörden, verweist dabei aber nur stellenweise auf die Notwendigkeit der Datensicherung von netzwerkbezogenen Daten:

If network intrusion detection logs or other detection type logs are associated with the respective investigation [...] they should be provided (electronic form preferable, paper is acceptable).This will enhance the examiner’s ability to provide a better product and to interpret the logs in an eﬀort to search for the right items.

3.1.2 Metadatenanalyse

Nicht erst seit den Enthüllungen über die NSA-Abhöraktionen durch Edward Snowden im Jahr 2013 stehen Anwendern Möglichkeiten zur sicheren Übertragung der Daten zur Verfügung. Je- doch ist seit diesem Zeitpunkt bei vielen Nutzern ein Bewusstsein für die Überwachung- und Auswertemöglichkeiten der Datenübertragungen entstanden. Parallel stieg die Anzahl nutzbarer Werkzeuge, die auch für Laien auf einfache Art Verschlüsselungstechniken bieten.

69 3 Forschungsstand

Diese Verschlüsselungstechniken bieten dem Anwender die sichere Übertragung seiner Daten über unsichere Netzwerke. Diese Methoden sind bereits seid langer Zeit bekannt und vielfach erprobt, angepasst und optimiert. Dem Anwender stehen für die Verschlüsselung unterschiedliche Möglichkeiten, wie in [MVM09] oder [RSA78] beschrieben, zur Verfügung.

Während für Anwender die Nutzung der Verschlüsselung Sicherheit bietet, erschwert sie die netzwerkforensische Analyse. Protokolle transportieren die Daten nun nicht mehr im Klartext, sondern übertragen die verschlüsselten Daten, die ohne Kenntnis der genutzten Schlüssel nicht entschlüsselt werden können.

Aber auch Unternehmen betrachten die Übertragung von Daten im Klartext immer kritischer, so dass auch in diesen Bereichen verstärkt auf Verschlüsselungstechniken gesetzt wird. Abbildung 3.1 zeigt die Entwicklungszahlen von Unternehmen, die Verschlüsselungstechniken einsetzen.

Abbildung 3.1: Entwicklung des Einsatzes von Verschlüsselungen in Unternehmen, nach [Tha15]

Da die übertragenen Daten nun nicht mehr im Klartext übertragen werden, stehen im Auswerte- prozess weniger lesbare Daten zur Verfügung. Der tatsächliche Payload ist somit nicht mehr direkt nutzbar, so dass die Nutzung der Verbindungsdaten32 immer wichtiger wird.

[ALCF15] beschreibt jedoch die Schwierigkeit, nur die IP-Adresse als Kriterium zu nutzen. Viele Nutzer besitzen mehrere Endgeräte, mit denen sie im Netzwerk unterwegs sind. All diese Gerä- te besitzen unterschiedliche IP-Adressen, werden jedoch von der gleichen Person genutzt. Um diese Daten in Korrelation bringen zu können, sind statische Analysen nicht zielführend. Daher untersucht [ALCF15] die Möglichkeiten, Nutzer und Anwendungen anhand von Metadaten klas- siﬁzieren und identiﬁzieren zu können. Hierzu wurden drei unterschiedliche Kommunikationsarten

32Im Folgenden als Metadaten bezeichnet.

70 3.1 Netzwerkforensik

(Websurfen, Instant Messenger, soziale Netzwerke) in definierten Prozessen untersucht und die anfallenden Metadaten bewertet. Obwohl die anfallenden Daten nicht im Klartext vorlagen, war dennoch eine Identifikation der Anwendungen möglich. Ähnliche Analysen wurden bereits in Mo- bilfunknetzen durchgeführt. Hier war eine Identifikation der Nutzer anhand von Gesprächszeiten und -dauer möglich [LCPD14]. Somit sind mit hohem Aufwand netzwerkforensische Analysen möglich, auch wenn keine Kenntnis über die übertragenen Daten vorliegen. Ein ähnlicher Ansatz wurde in [SEK15] vorgestellt, dabei lag der Fokus auf der Analyse cloudspezifischer Netzwerk- daten anhand von Metadaten.

Das Problem der Verschlüsselung ist jedoch nicht einzig auf die Netzwerkforensik beschränkt, auch im Rahmen computerforensischer Untersuchungen kommt es verstärkt zur datei- oder par- titionsbasierten Verschlüsselung, die entsprechende Analysen erschwert [LBOS16], [CS08].

3.1.3 Statistische Bewertung

Die Zunahme verschlüsselter Übertragungen verlangt von Netzwerkforensikern neue Herange- hensweisen zur Analyse der Daten. Die im vorigen Abschnitt beschriebene Metadatenanalyse extrahiert daher die im Klartext übertragenen Daten und nutzt diese für die weiteren Ermittlun- gen.

Unter dem Begriﬀ der Datenverkehrsanalyse wird anhand unterschiedlicher Parameter auf einem höheren Abstraktionsniveau eine Analyse durchgeführt ohne die übertragene Payload zu untersuchen [Lip06], [Ray01]. Diese Parameter umfassen Aspekte wie Zeitstempel, Größe und Reihenfolge der aufgezeichneten Pakete sowie die Verbindungsdauer. Das Themenfeld der Ver- kehrsanalyse hat auch durch die verstärkte Nutzung des Tor-Netzwerks weiter zugenommen. Im Tor-Netzwerk werden die Daten über unterschiedliche Tor-Router übertragenen, die eine direkte Ermittlung des tatsächlichen Ziels oder der Quelle verhindern. Der Nutzer kann somit anonym mit dem Zielsystem kommunizieren. Dabei werden die Daten über mehrere Tor-Router33 verschlüsselt übertragen, der Client ermittelt im Vorfeld mit dem Tor-Circuit einen Pfad durch das Netzwerk. Jeder Router innerhalb dieses Tor-Circuits kennt nur seinen Nachbarn, aber nicht den ganzen Weg zum Ziel. Zusätzlich werden die Daten separat verschlüsselt, so dass selbst bei Kenntnis der beteiligten Tor-Router keine Extraktion der übertragenen Daten möglich ist [DMS04]. Da eine direkte Ermittlung der Kommunikationspartner nun nicht mehr möglich ist, bleibt letztlich nur die Möglichkeit, auf Basis statistischer Auswertung die jeweiligen Daten zu korrelieren. Eine Übersicht über weitere Probleme bei der Untersuchung des Tor-Netzwerks liefert [For02]. [Ray01] zielt auf den Schutz des Users ab und beschreibt dabei mögliche Angriﬀstechniken auf die Anonymität der Kommunikationsteilnehmer.

33Im Normalfall werden drei Router genutzt.

71 3 Forschungsstand

3.1.4 Datenmenge

Big Data ist eines der neuen Schlagworte im IT-Bereich. Dabei ist nicht gemeint, dass die Daten nun größer oder bisher gespeicherte Daten klein sind. Vielmehr bezeichnet Big Data Daten, die mit traditionellen Methoden nicht mehr verarbeitet werden können [ZE+11].

In short, the term Big Data applies to information that can’t be processed or analyzed using traditional processes or tools.

Nicht nur die Kapazitäten der Speichermedien steigen kontinuierlich, sondern auch die übertrage- nen Datenmengen. [Cis15c] geht von einem Zuwachs von 23% des weltweiten IP-Datenverkehrs bis 2019 aus. Dabei ist von einer zu übertragenen Datenmenge von zwei Zettabyte auszugehen.

Somit entsteht auch für die Netzwerkforensik ein neues Problemfeld. Bei ungeeigneter Wahl der Aufzeichnungsposition kommt es zu einem exorbitanten Anstieg der zu speichernden Daten. Parallel enthalten diese Datenmengen viele irrelevante Informationen, die nachträglich aus den gespeicherten Daten entfernt werden müssen.

Die Reduktion der aufgezeichneten Daten auf eine noch zu verarbeitende Menge ist ein aktuelles Forschungsgebiet. In [PCLC10] werden erste Möglichkeiten zur Reduzierung der aufgezeichneten Daten vorgestellt. [PJN11] beschreibt die Extraktion deﬁnierter Headerfelder zur statistischen Auswertung von Netzwerkangriﬀen. In [QC14] werden Möglichkeiten der digitalen Forensik vorgestellt, die auch auf den Teilbereich der Netzwerkforensik angewandt werden können. Ansätze zur Vermeidung extremer Datenmengen ohne Verlust relevanter Informationen liefert [PGBW07] oder [GSL13] mit besonderer Würdigung einer OpenStack-Umgebung.

Einhergehend mit den großen Datenmengen steigen auch die Übertragungsgeschwindigkeiten, so dass auch hier Neuerungen notwendig sind. Das Problem der Aufzeichnung hochperformanter Links ist nicht neu, bereits 2001 wurde es in [IDGM01] und [DAKF] beschrieben. Standardhard- ware ist bei der Aufzeichnung von 10GE Netzwerken ausgelastet, so dass gesonderte Hardware benötigt wird [Wil12]. Die limitierenden Komponenten sind mit

• CPU

• Speicherplatz

• Netzwerkkarte

• E/A-Busse genau die Komponenten, die vorrangig bei der Aufzeichnung von Daten benötigt werden.

72 3.2 Cloud-Forensik

Da Standardhardware für schnelle Netzwerke nicht ausreichend ist, steigt der Bedarf an teurer und komplexer Spezialhardware, die von unterschiedlichen Firmen wie Savvius [Sav16] oder FireEye [Fir15a] bereitgestellt wird.

3.2 Cloud-Forensik

Die Veränderung klassischer IT-Paradigmen zum Cloud-Computing stellt auch Forensiker vor neue Probleme. Bekannte Methoden der Datenextraktion und Analyse werden von vielen Pro- blemen begleitet, parallel dazu entstehen neue Schwierigkeiten wie die Lokalisierung der Daten oder der Lebenszyklus der involvierten VMs. Unterschiedliche Arbeiten wie [SK13] und [RCKB13] haben sich mit diesen entstandenen Problemen auseinandergesetzt. In [RBCK11] werden die folgenden Aspekte als besondere Herausforderungen aufgeführt:

• Verlust der Kontrolle über die Daten

• Kein Zugriﬀ auf die physikalische Infrastruktur

• Rechtliche Schwierigkeiten aufgrund unterschiedlicher Zuständigkeiten, Mandantenfähig- keit und Mehrfachnutzung

• Mangel an geeigneten Werkzeugen für die Analyse virtueller Umgebungen

• Keine standardisierten Schnittstellen

• Fehlende Kooperation mit den CSP

• Schwierigkeiten einer verständlichen Darstellung der forensischen Analyse vor Gericht

Dies führte zur Entwicklung der Cloud-Forensik, die in [NIS14] wie folgt deﬁniert ist:

Cloud computing forensic science is the application of scientiﬁc principles, technolo- gical practices and derived and proven methods to reconstruct past cloud computing events through identiﬁcation, collection, preservation, examination, interpretation and reporting of digital evidence.

Dabei umfasst die Cloud-Forensik viele Teilbereiche der digitalen Forensik und nutzt dabei Tech- niken der Arbeitsspeicheranalyse, Netzwerk- und Computerforensik sowie der VM-Introspektion [GR03]. [PMT13] bietet einen umfassenden Überblick über aktuelle Systeme, Techniken sowie möglicher Ansätze und beschreibt die Nutzung der VM-Introspektion ebenfalls als eine wichtige Technik, um anhand einer Virtual Machine Monitor (VMM)-Analyse und dem Zugriﬀ auf an-

73 3 Forschungsstand fallende Daten forensische Untersuchungen vorzunehmen. [DKO11] listet Ansätze auf, die eine Isolation einer verdächtigen VM ermöglichen sollen. [BW11] beschreibt die inhärente Nutzung der Netzwerktechnik in Cloud-Umgebungen, die zu einer verstärkten Relevanz netzwerkforensischer Aspekte bei der Analyse führt. Allerdings stellt keiner dieser Ansätze eine adäquate Lösung bereit, alle vorgestellten Techniken weisen unterschiedlichste Schwächen auf, die eine forensische Auswertung erschweren.

In [AIJ14] ﬁndet sich eine Übersicht über Arbeiten, welche seit dem Jahr 2006 veröﬀentlicht wurden und thematisch die Forensik in Cloud-Umgebungen abdecken. Dabei ist ein kontinu- ierlicher Anstieg an wissenschaftlichen Arbeiten zu erkennen, der die Relevanz der Thematik unterstreicht. Dies deckt sich mit Untersuchungen von [AFCF13], der in seiner Arbeit Experten aus dem Forensikumfeld befragt hat. Übereinstimmend wurde dabei festgestellt, dass ein hoher Bedarf an Cloud-Forensik existiert, es aber an geeigneten Werkzeugen und Lösungen mangelt. So stellt [DS13] in seiner Arbeit ebenfalls fest, dass viele Probleme im Cloud-Umfeld nicht ge- löst sind. Dies führt zu dem oben beschriebenen Mangel an real nutzbaren Implementierungen [MMPJ12].

[AFH17] beschreibt die Durchführung forensischer Arbeiten in Cloud-Umgebungen mit einem Fokus auf Strafverfolgungsbehörden und listet dabei Techniken auf, die eine Sicherung der Da- ten innerhalb dieser Umgebungen ermöglicht. [Ban15] benennt in seiner Arbeit die Möglichkeit zur Extraktion von Arbeitsspeicher- und Festplatteninhalten mit Hilfe der OpenStack-API für forensische Zwecke. In [AIJ16] wird die Nutzung von Snapshots zur Durchführung forensischer Arbeiten vorgestellt, deren Analyse wiederum auf Techniken der klassischen Computerforensik basiert.

3.2.1 Komponentenbasierte Forensik

Bisherige Ansätze der Cloud-Forensik konzentrieren sich häuﬁg auf einen einzelnen Teilbereich. So versuchen Ansätze der Hypervisor-Forensik, Aussagen anhand der gespeicherten Daten des VMM zu treﬀen [GLB13], [TRG+13].

Bei Betrachtung der Nutzungsmöglichkeiten, der Dynamik und der Schnelllebigkeit virtueller Umgebungen sind solche Ansätze nachvollziehbar. Die Komplexität einer solchen Umgebung ermöglicht bisher keinen vollumfänglichen Ansatz zur Auswertung, obwohl ein solcher Ansatz für erfolgreiche Untersuchungen elementar ist [Ste09]. Durch diesen als end-to-end deﬁnierten Ansatz wird deutlich, dass im Angriﬀsfall viele Systeme involviert und somit für die Auswertung relevant sind.

74 3.2 Cloud-Forensik

In [DS13] wird mit FROST eine der ersten realen Implementierungen für forensische Arbeiten in Cloud-Umgebungen vorgestellt. Dabei werden klassische Paketfilterregeln auf iptables-Basis, die in OpenStack die Zugriffsteuerung auf die Systemdienste regeln, genutzt. Diese Regeln bilden die sogenannten Security-Groups ab, die den Zugriff auf interne Dienste steuern. Ohne grundlegende Anpassungen ist ein Zugriff auf die laufenden VM-Instanzen nicht möglich, so dass die Nutzung dieser Regeln unumgänglich ist. Durch die Definition angepasster Regeln können so entsprechende Informationen zu Paketen ermittelt werden. Während der Ansatz für die anfallenden Images und Benutzerdaten unter der Vorgaben, dass der Benutzer vertrauenswürdig ist, funktioniert, ist dieser Ansatz für die Netzwerkforensik nicht ausreichend. Die Datenaufzeichnung erfolgt direkt an der VM, und umfasst dabei auch nur Metadaten über Verbindungsinformationen durch die Firewall.

3.2.2 Containerforensik

Container bieten dem Nutzer gekapselte Anwendungen, die innerhalb einer eindeutig deﬁnierten Umgebung bereitgestellt sind. Diese Container können aufgrund ihrer Einfachheit schnell gestartet und gestoppt werden. Änderungen der Umgebung sind jedoch nur durch Neuerstellung des Containers möglich. Grundsätzlich ist es möglich, Daten innerhalb eines Containers zu speichern, allerdings werden diese Daten bei Beendigung des Containers unter Umständen gelöscht. Daher empﬁehlt es sich, relevante Daten außerhalb des Containers zu lagern, um im Fehlerfall die Daten weiterhin vorhalten zu können.

Aus forensischer Sicht ist die externe Datenhaltung von Vorteil, da diese losgelöst vom tat- sächlichen Zustand des Containers analysiert werden können. Erfolgt eine solche externe Da- tenspeicherung gewollt oder ungewollt jedoch nicht, oder sind Aussagen über das Verhalten des Containers relevant, sind forensische Analysen des Containers notwendig.

Wissenschaftliche Arbeiten zum Thema Containerforensik sind rar. Einzig [DW16] stellt mit DCFF einen Ansatz zur laufzeitbezogenen Extraktion von Containerdaten vor. Die extrahierten Daten können dabei aus unterschiedlichen Umgebungen ermittelt und in ein einheitliches Format umgewandelt werden. Dabei wird zu großen Teilen auf Techniken der VM-Forensik zurückgegrif- fen, um relevante Daten zu extrahieren. Analoge Techniken der VM-Introspection ﬁnden sich in [HN08].

Neben der konkreten Untersuchung von Containern werden diese auch häuﬁg selbst als forensi- sches Werkzeug eingesetzt. So werden Container im Rahmen der Malwareanalyse als Sandboxing- Umgebung genutzt [Dal14], [IAGP15], um Schadcode vereinfacht analysieren und bewerten zu können. [CIS15a] stellen mit Spyglass eine containerbasierte Umgebung vor, die den sicheren Zugriﬀ auf andere Systeme ermöglicht. Schwerpunkt dieser Programme ist die forensische Nach-

75 3 Forschungsstand vollziehbarkeit der durchgeführten Maßnahmen. Die reproduzierbare Überprüfung der Sicherheit von Webanwendungen beschreibt [DDSMS14] mit der containerbasierten Umgebung TestREx. Hierbei stellen die Container Umgebungen zur Verfügung, die einfach anzupassen und schnell bereitzustellen sind.

3.3 Forensik in virtuellen Netzwerken

Obwohl Cloud-Computing ohne Netzwerktechnik nicht funktioniert, sind in diesem Bereich bisher kaum tiefergehende Analysen und Forschungsarbeiten vorhanden. Vereinzelt wird auf die Not- wendigkeit der Analyse und auftretende Schwierigkeiten hingewiesen, dabei wird jedoch fälsch- licherweise davon ausgegangen, dass nur das Problem der Datenaufzeichnung existiert [HZ12]:

Although the live and dead forensics categories still exist, cloud models present new challenges because network data is often diﬃcult to locate, thus acquisition might be challenging or even impossible. [...] When conventional network forensic tools work, the only aspect that a cloud tool changes is the collection method.

Die wenigen Arbeiten, die sich mit der Forensik in Cloud-Umgebungen auf Basis der Netzwerkda- ten beschäftigen, nutzen dabei keine netzwerkforensischen Methoden (vgl. Kapitel 2.6), sondern speichern nur möglicherweise relevante Daten, was zu einem unvollständigen Datenbestand führt.

So baut der Ansatz nach [YQL14] auf dem Netﬂow-Protokoll auf und nutzt diese Verbindungs- daten, um Aussagen über anfallende Verbindungen zu treﬀen. Dieser Ansatz basiert jedoch eher auf einem Monitoring-Prinzip als auf einem forensisch korrekten Vorgehen.

[DKO11] stellt unterschiedliche Ansätze zur Isolation von virtuellen Maschinen vor, ein Ansatz bezieht sich auf MITM-Angriffe. Bei dieser Technik wird ein zusätzliches System in den Datenver- kehr zwischen Client und Server eingebracht, welches sämtliche anfallenden Daten mitschneiden und manipulieren kann [CCR09]. Obwohl diese Angriffstechnik seit langem bekannt ist, wird sie immer noch aktiv ausgenutzt [Sch13]. [DKO11] nutzt diese Technik jedoch nicht originär zur Netzwerkforensik, sondern listet auch Möglichkeiten der CPU, RAM und Festplattenanalyse oder die Möglichkeit der Arbeitsspeichermitschnitte auf und definiert diese Lösung als insgesamt erfolgversprechend.

Wissenschaftliche Untersuchungen der forensischen Möglichkeiten in den Bereichen SDN oder NFV sind bisher ebenfalls nur wenig vorhanden. Einige der beschriebenen Ansätze zielen auf eine Verbesserung in der Administration und Fehlerbehebung ab. [ARDC14] stellt mit SDN

76 3.4 Vorgehensmodelle

Traceroute eine vergleichbare Nutzung wie das bekannte Netzwerkprogramm traceroute34 vor. Einen ähnlichen Ansatz verfolgen auch [KZCG12] und [ZKVM12], die jedoch für die Datenanalyse Veränderungen an existenten Regeln implementieren oder zusätzliche Komponenten benötigen. In [DMSK17] werden Möglichkeiten zur Analyse von Angriﬀen auf Basis von SDN untersucht.

In [FF14] werden die Möglichkeiten zur Identifikation der Quellen von Netzwerkanomalien in SDN-basierten Umgebungen beschrieben. Die Kenntnis des Ausgangspunktes von Netzwerkan- griffen ist dabei nicht nur für das Unternehmen selbst interessant, auch im Rahmen von Ermitt- lungen durch Strafverfolgungsbehörden ist dieses Wissen häufig von elementarer Bedeutung.

3.4 Vorgehensmodelle

Vorgehensmodelle geben forensischen Untersuchungen eine Struktur, indem die anfallenden Ar- beiten in Unterabschnitte zerlegt werden und so der komplexe Untersuchungsprozess in kleinere Teilaufgaben aufgeteilt wird. Ziel eines eingesetzten Modells ist es, dem Forensiker Handlungs- sicherheit zu bieten, so dass keine Arbeitsschritte vergessen werden und eine aufeinander auf- bauende Abarbeitung der jeweiligen Teilergebnisse zu einem nachvollziehbaren Gesamtergebnis führt.

Dabei hilft die strukturierte Anwendung der unterschiedlichen Arbeitsschritte, um die Vollstän- digkeit und Korrektheit der Untersuchung zu garantieren [KCGD06]:

The application of science to the identiﬁcation, collection, examination, and analysis of data while preserving the integrity of the information and maintaining a strict chain of custody for the data.

Ein Vorgehensmodell beschreibt dabei das allgemeine Vorgehen ohne die konkreten Arbeits- schritte zu deﬁnieren. So lassen sich im Vorgehensmodell vom Bundesamt für Sicherheit in der Informationstechnik (BSI) [Bun11] die Arbeitsschritte in der Phase der Untersuchung als

[...] alle Maßnahmen einsortieren, welche aus den gesammelten Daten zunächst allgemein forensisch wertvolle Daten extrahieren können. Ein Beispiel für eine solche Maßnahme ist die Extraktion von Bilddateien aus dem Image einer Festplatte.

Wie diese Bilddateien konkret aus dem Image extrahiert werden, wird nicht deﬁniert und kann somit eigenständig durch den zuständigen Forensiker durchgeführt werden. Diesem steht eine

34Traceroute ermöglicht eine Überprüfung des Paketwegs im Internet, indem mit Hilfe des Time-to-live-Felds und einer Inkrementierung des Werts die unterschiedlichen Stationen im Netzwerk abgefragt werden.

77 3 Forschungsstand

Vielzahl unterschiedlicher Programme zur Verfügung, von denen er das für den Zweck am besten geeignete Werkzeug wählen kann.

Während für die klassische Forensik eine Vielzahl unterschiedlicher Modelle zur Verfügung stehen, existiert im Bereich der Netzwerkforensik in virtuellen Umgebungen kein geeignetes Modell. Auch für den Bereich des Cloud-Computings existiert nur wenige Vorgehensmodelle, welche die dort notwendigen Untersuchungen deﬁnieren und geeignete Handlungsanweisungen bieten.

[Che14] beschreibt in seiner Arbeit ein angepasstes Modell für forensische Arbeiten in Cloud- Umgebungen. Die Hauptaufgaben sind dabei die folgenden vier Teilgebiete:

• Datensicherung in der Cloud

• Speicherung der Daten

• Analyse und Präsentation

• Verknüpfung von Informationen

Dies deckt sich wiederum größtenteils mit Vorgehensmodellen der klassischen Forensik, [JS15] listet die vier am häuﬁgsten aufgeführten Phasen Sicherung, Untersuchung, Analyse und Prä- sentation auf.

[RC12] stellt mit dem Cloud Forensic Maturity Modell (CFMM) ein Modell vor, welches aus zwei Hauptkomponenten besteht. Diese Komponenten agieren miteinander und garantieren so die um- fängliche Nutzung aller relevanten Aspekte. Zusätzlich dazu beschreibt das Modell Aufgaben für die unterschiedlichen beteiligten Teilnehmer wie Kunde, Provider, Auditor und Strafverfolgung.

[MC12] beschreibt in Anlehnung an [KCGD06] und [McK99] ein Modell, bestehend aus den folgenden Aspekten:

• Identiﬁkation und Speicherung

• Sammlung

• Untersuchung und Analyse

• Reports und Präsentation

Das beschriebene Modell gleicht im Aufbau den beiden Modellen, nutzt jedoch einen wiederholen- den Aufbau zwischen Identiﬁkation und Untersuchung, um so, bei Ermittlung neuer Ergebnisse, erneute Untersuchungen durchführen zu können.

78 3.5 Antiforensik

3.5 Antiforensik

Anfang des 20. Jahrhunderts stellte der Franzose Edmund Locard ein Prinzip bei der Entstehung von Spuren fest, nach dem niemand eine Tat begehen kann, ohne Spuren zu hinterlassen. Diese Spuren entstehen dadurch, dass etwas vom Tatort entnommen oder mit zum Tatort gebracht wurde. Dieses Prinzip trägt den Namen Locardsches Austauschprinzip und ﬁndet nicht nur in der kriminalistischen Forensik35, sondern auch im Rahmen von digitalen Untersuchungen Anwendung. Dieses Wissen besitzen jedoch auch meist die Angreifer von IT-Systemen.

Die klassische IT-Forensik im Rahmen von Strafverfolgungsbehörden beschäftigt sich mit der Beweissicherung in sogenannten Cybercrime-Ermittlungen. Da die Täter bei einer erfolgreichen Identifizierung mit nicht unerheblichen Strafen rechnen müssen, wenden diese häufig Maßnahmen zur Verschleierung der Aktionen, Vermeidung von Spuren und Behinderung der Ermittlungsarbeit an [Har06]. Diese Art der Manipulation wird unter dem Begriff der Antiforensik zusammengefasst. Dabei handelt es sich meist um einen Wettlauf zwischen neuen forensischen Methoden und angepassten antiforensischen Techniken [SLL12].

Neben Techniken der Kryptographie oder Steganographie werden auch gezielte Angriﬀe auf die Ermittlungswerkzeuge und -techniken genutzt, um die Auswertung zu verhindern. Dies umfasst Manipulationen von Zeitstempeln [PP09], Löschen oder mehrfaches Überschreiben von Datei- en oder auch Packprogramme, die das tatsächliche Ziel der Dateien verbergen. [Gar07]. Sofern es dem Angreifer gelingt, die auﬀälligen Daten seiner Werkzeuge ausschließlich im Arbeitsspei- cher zu halten, verringert sich die Entdeckungsgefahr deutlich. Zur Steigerung sind weiterhin antiforenische Maßnahmen auf den Arbeitsspeicher anwendbar [Bil06]. Die Entdeckung solcher Verschleierungen sind durch gängige Werkzeuge der Arbeitsspeicheranalyse jedoch nur selten erfolgreich [SC13].

Auch im Rahmen von netzwerkforensischen Arbeiten ﬁnden sich immer wieder antiforensische Techniken, die in unterschiedlichen Ausprägungen existieren:

• Nutzung von verschlüsselter Datenübertragung

• Einsatz von Tunnelprotokollen

• Nutzung von Protokollen außerhalb der vorgesehenen Speziﬁkation36

• Steganographische Techniken zur Übertragung der Daten, z.B. auf Basis von VoIP [MS08]

• Übertragung von Daten in Steuerinformationen [MSS13]

35Dies umfasst z. B. die Bereiche der Pathologie, Ballistik oder Daktyloskopie. 36DNS oder ICMP-Tunnel ermöglichen den Datenaustausch zwischen zwei Systemen über DNS oder Internet Control Message Protocol (ICMP).

79 3 Forschungsstand

Im Rahmen der Server-TKÜ wird versucht, die Aufzeichnung verdeckt zu installieren, je nach gewählter Aufzeichnungstechnik kommt es jedoch zu kurzfristigen Netzwerkunterbrechungen, die meist gegenüber den verdächtigen Personen mit Stromausfällen erklärt werden können. Um diese Erklärung zu vermeiden, wird verstärkt versucht, die Daten mit Hilfe eines SPAN auszuleiten (vgl. Kapitel 2.6.2) und so keine Unterbrechung des Datenverkehrs zu riskieren. Hierdurch ist es dem Beschuldigten nicht möglich, die Überwachung zu erkennen, so dass das Risiko der Nutzung antiforensischer Methoden minimiert wird.

Die Entdeckung antiforensischer Techniken ist keine allgemeingültige Methode, vielmehr muss situativ entschieden werden, ob entsprechende Verschleierungen vorgenommen werden. Entspre- chende Methoden zur Erkennung steganographischer Techniken ﬁnden sich in [GS13] für WLAN- Netzwerke und in [MSJ12] zur Angriﬀserkennung auf Basis von Netzwerkanomalien.

80 4 Problemanalyse

Bereits in der traditionellen Netzwerkforensik existieren Problembereiche, die die forensische Ar- beit erschweren. Die Art der Herausforderungen sowie die Anzahl der neu auftretenden Schwie- rigkeiten, die im Rahmen der netzwerkforensischen Analyse virtueller Netzwerke auftreten, über- steigen die bisher bekannten Probleme jedoch um ein Vielfaches.

Dieses Kapitel beschreibt diese Schwierigkeiten, die alle drei Phasen der Netzwerkforensik betreffen. Daher erfolgt nach der Beschreibung der neu auftretenden Herausforderungen eine Klassiﬁ- zierung des Risikopotentials anhand der Arbeitsschritte Aufzeichnung, Speicherung und Analyse.

Um die neu auftretenden Probleme zu ermitteln, erfolgt im ersten Schritt eine Aufteilung nach Untersuchungsgebieten, anhand mögliche Schwierigkeiten bestimmt werden. Diese Untersuchungs- gebiete sind:

• Phasen einer netzwerkforensischen Untersuchung

• Eingesetzte Komponenten in virtuellen Umgebungen

• Deﬁnierte Prozesse innerhalb virtualisierter Cloud-Umgebungen

4.1 Bestimmung existenter Problemfelder

Die Bestimmung der existenten Probleme für netzwerkforensische Untersuchungen in virtuellen Umgebung ist elementar für alle weiteren Arbeitsschritte. So sind unterschiedliche Aspekte der virtuellen Umgebung für neue Probleme verantwortlich. Die hohe Dynamik im virtuellen Netzwerk führt zu Schwierigkeiten bei der Aufzeichnung, die fehlenden hardwarebasierten Möglichkeiten zur Aufzeichnung und Speicherung erschwert die Datenausleitung aus den Umgebungen. Over- layprotokolle wie VXLAN oder GENEVE fügen neue Informationen in die aufgezeichneten Daten ein, so dass möglicherweise mehrere Schichten des OSI-Modells relevante Kommunikationsdetails übertragen.

81 4 Problemanalyse

[BD15] beschreibt aktuelle Herausforderungen der Netzwerkforensik, allerdings ohne eine Analyse auf die Besonderheiten virtueller Umgebungen durchzuführen. Die von ihm aufgeführten, grundlegenden Probleme wie Datenlokation, Integrität oder Datenanalyse sind dabei jedoch auch in virtuellen Umgebungen relevant.

Um die konkreten Probleme zu ermitteln, die im Rahmen netzwerkforensischer Untersuchungen in virtuellen Netzwerken entstehen, ist eine Separierung der in Abschnitt 2.6 vorgestellten Phasen notwendig [SE16a]. Hierdurch wird für jeden Arbeitsschritt einer netzwerkforensischen Analyse untersucht, ob und in welcher Form dieser Schritt mit neuen Problemen konfrontiert ist.

Eine vollständige Analyse aller Probleme kann jedoch nur erfolgen, wenn weiterhin die ablaufen- den Prozesse innerhalb einer virtuellen Umgebung untersucht werden. Dabei kann es sich nur um die Standardprozesse handeln, providerspeziﬁsche Anpassungen bleiben ebenso unbehandelt wie abweichende Sonderlösungen. Zu einer solchen Analyse der Standardprozesse gehört auch die Untersuchung der eingesetzten Komponenten, da nur so sämtliche Aspekte der virtuellen Umgebung abgedeckt werden.

Einige Problemfelder überschneiden sich dabei und sind daher in unterschiedlichen Phasen, Kom- ponenten oder Prozessen zeitgleich vorhanden.

4.1.1 Aufteilung nach Phasen

Die Identiﬁkation möglicher Problemfelder anhand der drei Phasen Aufzeichnung, Speicherung und Analyse garantiert die Vollständigkeit, da jede Phase gesondert betrachtet wird. Da so sämtliche Arbeitsschritte erfasst werden, ist eine vollständige Untersuchung gegeben.

4.1.1.1 Aufzeichnung

Die Aufzeichnung der Daten ist für die weitere Untersuchung von grundsätzlicher Bedeutung. Al- lerdings ist eine Aufzeichnung aufgrund der hohen Dynamik in der virtuelle Umgebung (Abschnit- te 4.2, 4.3) erschwert. Auch die fehlende Hardwareanbindung verkompliziert die Aufzeichnung relevanter Daten (Abschnitte 4.4, 4.6)

4.1.1.2 Speicherung

Die aufgezeichneten Daten müssen für die spätere Analyse gespeichert werden. Hierdurch entstehen Probleme der Datenmenge (Abschnitt 4.9) und der Netzwerkbelastung (Abschnitt 4.12).

82 4.1 Bestimmung existenter Problemfelder

4.1.1.3 Analyse

In der Phase der Analyse werden Probleme zusammengefasst, die eine Untersuchung der aufgezeichneten Daten erschweren. Hierzu gehören sowohl softwaretechnische Schwierigkeiten (Ab- schnitt 4.10) als auch Rohdaten, die durch ungeeignete Aufzeichnungen entstanden sind (Ab- schnitte 4.9, 4.8, 4.11).

In virtuellen Netzwerken existiert eine hohe Anzahl unterschiedlichster Daten, die zeitgleich über- tragen und verarbeitet werden. Dabei sind nicht alle Daten für die forensische Untersuchung relevant, sondern erschweren nur die Analyse (Abschnitt 4.9.2).

4.1.2 Aufteilung nach Komponenten

In Abschnitt 2.2 wurde die geänderte Soft- und Hardware für den Betrieb virtueller Umgebungen beschrieben. Eine Analyse dieser eingesetzten Komponenten ermöglicht eine Identiﬁkation daraus entstehender Probleme.

Die im Kapitel 2.2.3.2 vorgestellten Container werden im Rahmen der Arbeit virtuellen Maschinen innerhalb einer CMP als gleichwertig angesehen. Für netzwerkforensische Analysen ist es unerheblich, ob die Netzwerkdaten an eine Anwendung innerhalb einer VM oder an einen Container, der ausschließlich diese Anwendung hostet, gesandt werden.

4.1.2.1 VM

Eine VM entspricht dem zu überwachenden physischen System in traditionellen Netzwerken. Die Überwachung einer VM in virtuellen Netzwerken ist dabei umfassender, da hierbei neben den speziﬁschen Anwendungsdaten zusätzliche administrative Daten anfallen können.

Eine VM verfügt nicht mehr über eine einzelne, dezidierte NIC, sondern ist über eine Virtual NIC (vNIC) verbunden.

4.1.2.2 Controller

Die Controller in virtuellen Netzwerken steuern den internen Ablauf der angeschlossenen Kompo- nenten. So steuert der Cloud Controller (CC) sämtliche Abläufe innerhalb der Cloud-Umgebung, regelt die Kommunikation zwischen den Services und stellt Schnittstellen zur Verfügung. Der SDN-Controller hingegen übernimmt die Steuerung der angeschlossenen Switche, konﬁguriert

83 4 Problemanalyse und implementiert Flows und überwacht die Paketverarbeitung. Als zentrales Element stellt der Controller somit eine mögliche Quelle für weitere Untersuchungen dar, allerdings ist die Anzahl unterschiedlicher Controller hoch, wodurch eine umfassende Analyse erschwert wird (Abschnitte 4.13 und 4.14).

4.1.2.3 vSwitch

Der vSwitch übernimmt die Vernetzung der unterschiedlichen VMs. Dabei verfügt auch der vSwitch über vNICs, darüberhinaus managt der vSwitch den internen Datenverkehr, der nur innerhalb eines CN verarbeitet wird (Abschnitt 4.6).

4.1.2.4 Compute Node

Der CN speichert sämtliche Daten der gehosteten VMs. Dabei wird nicht eine VM auf dem CN betrieben, sondern Hunderte oder Tausende. Durch diesen Parallelbetrieb entsteht das in Abschnitt 4.5 beschriebene Problem der Multitenancy. Zeitgleich verwaltet der CN den Daten- verkehr, der zwischen VMs auf diesem CN verarbeitet wird. Dieses Problem wird als Interner Datenverkehr deﬁniert und in Abschnitt 4.6 beschrieben.

4.1.2.5 Hardwareumgebung

Auch wenn die zu untersuchende Umgebung vollständig virtuell ist, existiert dennoch eine zu- grunde liegende Hardwareinfrastruktur. Dies umfasst sowohl die CNs als auch die Netzwerkin- frastruktur. Hier entstehende Probleme werden in Abschnitt 4.7 beschrieben.

4.1.3 Aufteilung nach Prozessen

Während eine virtuelle Umgebung meist hochdynamisch ist, existieren doch immer wiederkehren- de Prozesse. Eine Analyse dieser Prozesse ermöglicht eine weitere Ermittlung möglicher Probleme.

4.1.3.1 Lebenszyklus einer VM

Eine VM, die innerhalb einer Cloud-Umgebung genutzt wird, kann sechs unterschiedliche Status einnehmen [Ste14]:

84 4.1 Bestimmung existenter Problemfelder

• ready

• running

• shutting-down

• stopping

• stopped

• terminated

Der Status running entspricht dem wichtigsten Zeitpunkt zur Aufzeichnung der Netzwerkdaten. Alle anderen Status sind für netzwerkforensische Aufzeichnungen irrelevant, da keine Netzwerk- daten anfallen, allerdings können Übergange wie in Abbildung 4.1 zu Änderungen führen, die im Rahmen der Untersuchung beachtet werden müssen.

Abbildung 4.1: Lebenszyklus einer VM, [Spi14]

4.1.3.2 Migration einer VM

Eine VM kann aus unterschiedlichen Gründen von einem CN auf einen anderen übertragen werden. Hierdurch ändern sich eventuell eingerichtete Aufzeichnungen oder Speicherprozesse, die entstehenden Probleme werden im Abschnitt 4.2 beschrieben.

4.1.3.3 Änderung durch Kunden

Nutzer der virtuellen Umgebung können den ihnen zugeteilten Bereich eigenständig ändern. Diese Änderungen können netzwerkforensische Untersuchungen gefährden, die möglichen Probleme werden daher als Nutzeranpassung in Abschnitt 4.3 beschrieben.

85 4 Problemanalyse

4.2 Migration

Unter der Migration einer VM versteht man die automatisierte Übertragung einer laufenden oder gestoppten VM auf ein anderes Wirtssystem [MG14]. Die Gründe für eine Migration sind vielfältig und umfassen Aspekte wie Fehlertoleranz, Lastverteilung [MG14] oder Wartungsﬂexibilität der zugrundeliegenden Hardware [CFH+05]. Dabei kann die Migration auf Anforderung des Providers oder durch interne Initiierung durch die Cloud-Umgebung automatisch erfolgen. Zusätzlich hat auch der Kunde die Möglichkeit, die von ihm genutzten VMs eigenständig zu migrieren [EBS13].

Es existieren zwei unterschiedliche Strategien für die Migration einer VM:

• Pre-copy Migration Der Hypervisor kopiert sämtliche Speicherinhalte auf das Zielsystem. Ändert sich im Ko- pierzeitraum der Speicherinhalt, wird diese Seite als dirty bezeichnet und anschließend kopiert. Dieser Vorgang wird solange wiederholt, bis der gesamte Speicher durch das Ziel- system verwaltet wird [CFH+05]. Diese Technik basiert auf Aspekten der Prozessmigration [MDP+00].

• Post-copy Migration Nach der Migration des Speicherinhalts wird die VM auf dem Quellsystem gestoppt und letzte Daten wie der CPU-Status oder Registerinhalte auf das Zielsystem übertragen [HNIS11].

Das Ziel der Migration einer VM muss dabei nicht innerhalb des gleichen RZ liegen, durch die Installation weltweit operierender Rechenzentren mit unterschiedlichen Regionen können VMs auch über weite Strecken migriert werden. Somit kann das Zielsystem auch an lokal weit entfernt liegenden Standorten betrieben werden, wodurch weitere Herausforderungen für den Betreiber und Forensiker entstehen [AI13], [AHTH13]. So verändern sich durch die langen Laufzeiten während der Migration die jeweiligen Kopieraufwände, losgelöst von der genutzten Migrations- strategie [BKFS07]. Eine Übersicht über weitere Probleme der Migration in Cloud-Umgebungen beschreibt [KPJ13].

Die Migration einer VM hat unmittelbare Auswirkungen auf die Aufzeichnungstechnik, die für die VM bereitgestellt wurde. Während die Migration sowohl für die VM, die auf ihr laufenden Anwendungen und die mit der VM verbundenen Clients transparent verläuft [MG14], gilt dies nicht für die Systeme, die mit der Aufzeichnung der anfallenden Daten beauftragt sind. Da klassische Aufzeichnungssysteme im Vorfeld auf die physische NIC (pNIC), die MAC-Adresse oder andere Identiﬁkationsmerkmale festgelegt werden müssen, ist dieser statische Aufbau nach der Migration der VM auf ein anderes Wirtssystem mit sehr hoher Wahrscheinlichkeit ungültig, so dass keine relevanten Daten mehr aufgezeichnet werden.

86 4.3 Nutzeranpassungen

4.3 Nutzeranpassungen

Die initiale Bereitstellung virtueller Netzwerke, in dem Kunden die eigenen Systeme betreiben, erfolgt vom verantwortlichen Administrator bei der Ersteinrichtung einer VM. Diese VM kann bis auf den fehlenden Hardwarezugriff durch den Kunden eigenständig administriert und gewartet werden. Durch die Separierung der Systeme in logische Netzwerke ist es ebenso möglich, dass dieses Netzwerk durch den Kunden quasi nach Belieben konfiguriert werden kann. Dabei kann der Nutzer sowohl die genutzten internen IP-Adressen als auch die interne Vernetzung anpassen, indem er zusätzliche vNICs konfiguriert, VPN-Tunnel installiert oder je nach Grad der Berechtigung auch andere Router nutzt.

Eine entsprechende Konﬁguration zur Implementierung von Techniken wie Demilitarisierte Zo- ne (DMZ), Policy-Based Routing [YF03] oder auch Loadbalancing ist bei Nutzung dedizierter Hardwarekomponenten sehr kostenintensiv und stellt zusätzliche Anforderungen an den Admi- nistrator. Innerhalb der virtuellen Umgebung wird eine solche Implementierung vollständig in Software abgebildet und ist somit frei von Hardwarezwängen und wesentlich kostengünstiger. Die gesamte Lösung bleibt dabei überaus dynamisch und adaptierbar.

Ermöglicht wird dies durch die Konﬁguration der als Tenant-Netzwerke bezeichneten virtuellen Einheiten, die bis zu einem gewissen Grad vollständig unter der Hoheit des Kunden stehen [Den14]. Der Kunde ist somit für die Administration dieses Subnetzes verantwortlich und kann dort sämtliche Einstellungen vornehmen, die auch in einem eigenen, physischen Netzwerk vorgenommen werden. Das zugrundeliegende physische Netzwerk des CSP bleibt von den Konﬁgu- ration des Kunden unberührt und übernimmt weiterhin die korrekte Steuerung aller anfallenden Netzwerkdaten.

Durch den hohen Virtualisierungsgrad ist es so auch möglich, IP-Adressbereiche in dem gesamten Netzwerk mehrfach zu nutzen, ohne dass Netzwerkpakete an falsche Kommunikationspartner übermittelt werden. Im Abschnitt 4.11 wird dieses als „overlapped-ip-addresses“ bezeichnete System genauer beschrieben und hinsichtlich der Auswirkungen auf die Netzwerkforensik konkret deﬁniert.

Aus forensischer Sicht ist es bei der Aufzeichnung somit immer fraglich, ob die aufgezeichneten Daten weiterhin vollständig sind, oder ob aufgrund einfacher Anpassungen im Rahmen der Routingregeln durch den Benutzer neue Transportwege ermöglicht wurden und die Daten (auch teilweise) andere Wege durch das Netzwerk nehmen.

87 4 Problemanalyse

4.4 Virtuelle Netzwerkkarten

Klassische Rechenzentren boten in der Vergangenheit eine relativ einfache, statische Verkabe- lungstechnik, die jedem Server eine oder mehrere Netzwerkkarten zuordnete. Eine Teilmenge dieser Netzwerkkarten war dabei für die Anbindung ans Internet vorgesehen, die Weiteren stellten meist eine Anbindung an ein separates Management-Netz zur Verfügung.

Im Zuge der notwendigen Erhöhung der Übertragungsgeschwindigkeit kam es durch Techniken wie Link-Aggregation nach IEEE 802.3ad zu einer Erhöhung der Portanzahl je Server [Sei00]. Allerdings änderte sich durch die Erhöhung nicht die eigentliche Aufgabe der pNIC. Einzig die Gesamtübertragungsrate und die Ausfallsicherheit des Servers konnte so erhöht werden. Die netzwerkforensische Arbeit änderte sich nur in der Form, dass nun leistungsfähigere Systeme zur Aufzeichnung und Speicherung der anfallenden Daten genutzt werden mussten.

Durch die zunehmende Virtualisierung kam es vermehrt dazu, dass auf einem Wirtssystem nun mehrere virtuelle Umgebungen bereitgestellt wurden. Den Anfang machten hierbei Webhoster, die durch Techniken wie virtuelle Hosts im Webserverumfeld auf einer IP-Adresse mehrere In- ternetpräsenzen anboten. Aus forensischer Sicht ist diese Technik unkritisch, da es weiterhin mit klassischen Aufzeichnungstechniken und korrekter Filterung des Netzwerkverkehrs möglich ist, ausschließlich die relevanten Netzwerkdaten mitzuschneiden. Darauf aufbauend entstanden jedoch erste Ansätze, diese virtuellen Hosts aufgrund unterschiedlichster Gründe von einem Sys- tem auf ein anderes System umzuziehen. Da dies auf Seiten der Provider jeweils mit einer Downtime verbunden war, um die entsprechenden Namensauﬂösungen im DNS oder auch das IP-Adressierungsschema vollständig anzupassen, war es auch hier weiterhin möglich, die klassische Aufzeichnungstechnik manuell mit anzupassen, und so weiterhin die Vollständigkeit der aufgezeichneten Netzwerkdaten zu ermöglichen.

Der letzte Schritt zur vollständigen Virtualisierung des Netzwerks basierte auf den Entwick- lungen der in Kapitel 2.3 vorgestellten Techniken. In Kombination mit der Virtualisierung der Systeme entstanden so ﬂexible Vernetzungen, die durch softwaretechnische Implementierungen der Netzwerkkarten den Systemen dynamisch die vNIC bereitstellten.

Die Anbindung der VMs erfolgt über diese vNICs, die ihrerseits mit den pNICs verbunden sein können. Sofern eine Anbindung über diese Karte erfolgt, wird die Nutzung zwischen allen angeschlossenen vNICs aufgeteilt, so dass Netzwerkpakete mehrerer VMs über eine pNIC laufen. Weitere Karten im Wirtssystem stehen meist für Management und Backupzwecke zur Verfügung, um die unterschiedlichen Daten voneinander trennen zu können.

88 4.4 Virtuelle Netzwerkkarten

Die Nutzung von vNICs verhindert die Speicherung der relevanten Netzwerkdaten, da sowohl die Identiﬁkation der korrekten Schnittstelle als auch eine nachfolgende Aufzeichnung an dieser Schnittstelle mit traditionellen Methoden nahezu unmöglich sind.

4.4.1 Identiﬁkation

Während die klassische Verkabelung eine eindeutige Vernetzung erkennen ließ, entstehen durch die Netzwerkvirtualisierung neue, nur logisch existente Netzwerke, die die anfallenden Daten aufteilen, separieren und getrennt weiterleiten.

Das Fehlen dieser physischen Verbindungen erschwert die Identiﬁzierung und Datenaufzeichnung, da nun keine eindeutige Zuordnung zwischen den Systemen mehr gegeben ist. Tracingtechniken zur Kabelverfolgung oder visuelle Überprüfungen scheiden im Bereich der vNICs aus Mangel an Sichtverbindungen oder physischen Verbindungen aus. Dabei ist die Beantwortung der Frage, über welche Verbindung zwei Systeme aktuell kommunizieren, für netzwerkforensische Auswer- tungen elementar. Da diese Frage nicht zweifelsfrei beantwortet werden kann, ist eine zielgenaue Aufzeichnung der Daten nicht möglich.

4.4.2 Aufzeichnungsproblem

In Kapitel 2.1.3.1 wurde unterschiedliche Kabeltypen beschrieben, die in der klassischen Ver- netzung vorkommen. Dabei ist es letztlich für den Forensiker irrelevant, welche Netzwerkkarte genutzt wird, sofern er geeignete Adapter oder passende Karten zur Verfügung hat.

In virtuellen Umgebungen sind diese physischen Verbindungen jedoch nicht mehr existent. Die verbliebenen pNICs transportieren eine Vielzahl unterschiedlicher Kundendaten oder interner Informationen, so dass ein Zugriﬀ auf diese Daten nicht erfolgversprechend ist.

Sofern vNICs eingesetzt werden, sind traditionelle Aufzeichnungstechniken nutzlos, da keine geeigneten Schnittstellen zur Aufzeichnung mit Hilfe der hardwarebasierten Methoden existieren. Selbst wenn es gelingt, bei Auswahl einer scheinbar geeigneten Position Daten aufzuzeichnen, entstehen hierdurch neue Probleme wie fehlende Flexibilität (beschrieben in Abschnitt 4.2), er- schwerte Filtermöglichkeiten (Abschnitte 4.8 und 4.11) oder auch irrelevante Daten (Abschnitt 4.5). Die Aufzeichnung an Uplinks oder Transitstrecken vermag ausgehende Daten des Zielsys- tems aufzuzeichnen, intern verarbeitete Daten passieren diese Strecken aber nicht und sind somit nicht speicherbar (Abschnitt 4.6).

89 4 Problemanalyse

4.5 Multitenancy

Die Nutzung virtueller Umgebung basiert auf der Annahme, dass die Gesamtauslastung der Ressourcen durch den Betrieb einer gewissen Anzahl von VMs verbessert wird. Dadurch werden auf einem Wirtssystem teilweise bis zu mehreren Hundert VMs gleichzeitig betrieben.

Diese VMs sind dabei unterschiedlichen Kunden zugeordnet, die sich somit die Ressourcen des Wirtssystems teilen. Durch administrative Maßnahmen ist dabei durch den CSP sicherzustellen, dass die Systeme unterschiedlicher Kunden keinen unmittelbaren Kontakt erhalten können. Dabei helfen die neuen Netzwerkprotokolle wie VXLAN oder NVGRE, in dem sie die unterschiedlichen VMs in isolierte, logische Netzwerke verlagern und somit keine direkte Layer 2-Kommunikation ermöglichen. Der Zugriﬀ innerhalb des Dateisystems wird dabei anhand von Berechtigungen innerhalb der Cloud-Umgebungen realisiert.

Für den einfachen Betrieb ohne Kommunikationsmöglichkeiten ist dieses System gut geeignet, sobald jedoch die Kommunikation einer VM mit externen Systemen aufgebaut werden soll, muss hierfür auf die pNIC des Systems zurückgegriﬀen werden. Diese pNIC wird somit im Wechsel bei Bedarf von unterschiedlichen VMs benötigt; ein hier installierter Aufzeichnungsprozess würde folglich auch Daten aufzeichnen, die nicht zur Ziel-VM gehören.

Die Aufzeichnung vieler irrelevanter Daten führt zum Aufblähen der Aufzeichnungsdateien, im schlimmsten Fall können die unterschiedlichen Daten die Auswertung der Daten verfälschen. Darüber hinaus bringt eine solche Aufzeichnung datenschutzrechtliche Probleme mit sich.

4.6 Interner Datenverkehr

VMs sind virtuelle Abbilder realer Systeme und erfüllen somit einen Großteil der Aufgaben, die in der Vergangenheit von physischen Systemen abgearbeitet wurden. Daher müssen auch VMs in der Lage sein, mit anderen Systemen zu kommunizieren, Daten auszutauschen oder Dienste bereitzustellen. Auch wenn die VM durch den Kunden über das Internet administriert wird, muss diese VM keine direkte Anbindung an das Internet besitzen.

So ist es ebenfalls möglich, eine Multitierarchitektur mit internem Datenbackend zu konﬁgurieren, in der vereinzelte VMs nur innerhalb des logischen Netzwerks kommunizieren und somit keine Anbindung an das Internet benötigen. In der in Abbildung 4.2 dargestellten Aufteilung hat nur der Webserver eine Anbindung an externe Netzwerke, der Applikationsserver und die Datenbank sind zwar im gleichen virtuellen Netzwerk, besitzen jedoch keine Anbindung an externe Netzwerke. Diese Implementierung wird für den Betrieb klassischer Serverlandschaften empfohlen [IG13a], so

90 4.7 Physische Vernetzung dass eine entsprechende Umsetzung bei verantwortungsvoller Arbeit als Standard gelten dürfte und somit zahlreich anzutreﬀen sein wird.

Applikations- Webserver Datenbank server

Abbildung 4.2: Multitierarchitektur für Systeme ohne Anbindung an externe Netzwerke

Bei einer solchen Arbeitsweise müssen keine Daten über die pNIC des Wirtssystems übertragen werden, so dass hier eingerichtete Aufzeichnungssysteme die internen Daten nicht erhalten. Da für eine valide Aussage zum Kommunikationsverhalten der VM jedoch alle Daten benötigt werden, verhindert die fehlende Aufzeichnung des internen Datenverkehrs diese Analyse.

4.7 Physische Vernetzung

Die korrekte Aufzeichnungsposition innerhalb des Netzwerks gewinnt in virtuellen Netzwerken zusätzlich an Bedeutung. Falls weiterhin an der pNIC aufgezeichnet werden soll, entstehen zwei weitere Problemfelder:

• Encapsulation Die mehrfache Tunnelung oder Kapselung der Protokolle ineinander kann den Analyse- prozess erschweren, da meist ein Entpacken der Tunnelprotokolle erfolgen muss, um die übertragenen Daten zu bewerten. Dieser Prozess kostet neben Rechenleistung auch Zeit, die aufgrund der schnellen Übertragung der Daten im Netzwerk nicht immer ausreichend zur Verfügung steht. Letztlich bleibt somit nur die Speicherung vieler unnötiger Dateien, um später im Auswerteprozess die relevanten Daten zu extrahieren und nur diese weiter zu verarbeiten.

• Verschlüsselung Bei einigen Protokollen ist bei bereits im Standard die Möglichkeit vorgesehen, Daten verschlüsselt zu übertragen. So bietet IPv6 mit dem Encrypted Security Payload (ESP)- Header die Möglichkeit, die im Nutzdatenbereich transportierten Daten auf Layer 3-Ebene zu verschlüsseln.

Darüber hinaus entstehen durch die Vernetzungstechniken wie in Kapitel 2.2.2.2 beschrieben redundante Wege der Pakete durch das Netzwerk, die im Rahmen der Aufzeichnung beachtet

91 4 Problemanalyse und korrekt verarbeitet werden müssen. Die eingesetzten Layer 2-Protokolle wie TRILL oder SPB nutzen wiederum Kapselungen, um die vorhandene Verkabelung besser auszunutzen, indem die zusätzlichen Links aktiviert werden. Diese Kapselung erschwert je nach Aufzeichnungsposition wiederum die Aufbereitung und Analyse der Daten. Zusätzlich besteht die Gefahr, dass an der gewählten Aufzeichnungsposition nicht alle Daten sichtbar sind und somit nicht aufgezeichnet werden können.

4.8 Nichteindeutigkeit der MAC

Die MAC-Adresse wird im Netzwerk für die Adressierung auf der Sicherungsschicht genutzt, die Adresse identiﬁziert somit normalerweise eindeutig eine Netzwerkkarte.

In virtuellen Umgebungen ist die MAC-Adresse jedoch nicht mehr an einen Hardwarehersteller gebunden, da die vNIC softwaretechnisch bereitgestellt wird. Somit kann die MAC-Adresse beliebig vergeben werden, die ursprüngliche Eindeutigkeit einer MAC-Adresse ist somit hinfällig. VMMs in virtuellen Umgebungen können MAC-Adressen zufällig erstellen oder erhalten die Adressen durch den Provider händisch übermittelt [KS12].

VXLAN ermöglicht die eindeutige Identiﬁzierung des Clients anhand der Kombination aus MAC- Adresse und VNI, so dass ist eine doppelte Vergabe von MAC-Adressen in unterschiedlichen VNI möglich ist. Eine doppelte Vergabe von MAC-Adressen innerhalb einer VNI ist jedoch weiterhin nicht möglich.

Eine mehrfache Nutzung gleichlautender MAC-Adressen ist somit möglich, wodurch die MAC- Adresse als alleiniges Identiﬁkationsmittel ausscheidet. Erst in Kombination mit dem VLAN-Tag oder der ID des VXLAN ist wieder eine eindeutige Identiﬁkation möglich.

4.9 Netzwerkdaten

Je nach Position der implementierten Aufzeichnung können weitere Probleme auftreten, die auch die Speicherung der Daten betreﬀen. Dabei ist das Problem der Datenmenge ein bekanntes Problem der Netzwerkforensik [KGW+16], in virtuellen Netzwerken kann dieses Problem durch die falsche Wahl der Positionierung noch verstärkt werden. In den folgenden Abschnitten werden daher die Probleme der Datenbestimmung als auch die daraus resultierende Datenmenge in virtuellen Netzwerken deﬁniert.

92 4.9 Netzwerkdaten

4.9.1 Menge

Zur Vorbereitung der späteren Analyse müssen erst die relevanten Daten aufgezeichnet werden. Auch wenn dieser Prozess in kleinen Netzwerken oder im statischen Umfeld meist leicht möglich ist, bleibt die korrekte Positionierung des Aufzeichnungssystems elementar wichtig. Bereits in klassischen Netzwerken wird versucht, möglichst nah an der Quelle aufzuzeichnen, um die Anzahl der anfallenden Daten zu reduzieren. Während dies aufgrund der Existenz von pNICs möglich ist, scheitert eine vergleichbare Umsetzung mit gängigen Werkzeugen in virtuellen Netzwerken.

Sofern keine geeigneten Methoden für die quellnahe Aufzeichnung der relevanten Daten genutzt werden können, bleibt nur die Möglichkeit, die Daten an der ersten gültigen pNIC aufzuzeichnen. Die hier entstehende Datenmenge umfasst neben Daten der Ziel-VM auch Daten, die andere VMs betreﬀen oder nur Steuerinformationen übertragen, die keinerlei Relevanz für die forensische Auswertung haben. Je weiter entfernt das Aufzeichnungssystem von der Ziel-VM positioniert wird, desto mehr Daten fallen an, während zeitgleich der prozentuale Anteil relevanter Daten sinkt.

Je nach Aufzeichnungsposition im virtuellen System sind die anfallenden Datenmengen riesig, so dass bereits die Aufzeichnungssysteme ausreichend schnell in der Speicherung der Daten sein müssen. Geschwindigkeiten von 10 GBit/s oder 40 GBit/s sind keine Seltenheit. Höhere Geschwindigkeiten wie 100 GBit/s sind standardisiert und werden bereits stellenweise in hochperformanten Netzwerken eingesetzt.

4.9.2 Bestimmung

Netzwerke sind sowohl bei kleinen, als auch bei global agierenden Unternehmen das Kommunika- tionsrückgrat, deren Auslastung, Leistungsfähigkeit und Störanfälligkeit maßgeblich Einﬂuss auf die Arbeitsqualität hat. Während in kleinen Netzwerken Ausfälle oder Fehler störend sind, ist es in Unternehmensnetzwerken Aufgabe der Netzwerkadministratoren, den reibungslosen Betrieb zu gewährleisten, da Ausfälle des Netzwerks die Arbeitsmöglichkeit behindern und somit ﬁnanzielle Verluste bedeuten.

Oﬃzielle Richtlinien und Empfehlungen wie [IG13c] und [IG13b] für den sicheren Netzwerkbetrieb in diesen Bereichen propagieren eine physische oder logische Netzwerksegmentierung. Dies führt in größeren Netzwerken zu einer Segmentierung der Netzwerke in die folgenden Aufteilung:

• Verwaltung Unter Verwaltungsdaten werden alle Daten zusammengefasst, die im Rahmen klassischer Büroarbeit anfallen. Dies umfasst EMail, Internetsurfen, Groupware, Schreibarbeit, Druck-

93 4 Problemanalyse

betrieb oder Vorgangsbearbeitung. Alle diese Aufgaben werden klassischerweise über das Hauptnetzwerk abgewickelt.

• Backup Diese Netzwerke stellen dedizierte Links zwischen Servern und den Backupsystemen bereit. Charakteristisch für diese Netzwerke ist eine kurzfristige, dann aber sehr hohe Auslastung der Links, da in diesem Zeitraum sämtliche Daten zum Backupsystem transferiert werden müssen. Backups sind in der Vergangenheit meist in den Nachtstunden erfolgt, so dass nicht zwangsläuﬁg separate Netzwerke genutzt werden mussten. Die hohe Datennutzung verlangt aber mittlerweile eine permanente Sicherung wichtiger Systeme, so dass die Backupsysteme dauerhaft in Nutzung sind. Um die Arbeitsfähigkeit im Unternehmen nicht zu belasten, stellen separate Backupnetzwerke die getrennte Kommunikation sicher.

• Storage Speichersysteme sind meist über separate Speichernetzwerke angeschlossen, die den Spei- cherplatz über das Netzwerk bereitstellen. Dies kann über das Network File System (NFS) oder das Common Internet File System (CIFS) erfolgen, die Speicherpools sind im SAN über iSCSI InﬁniBand oder Fibrechannel angebunden. Die gestiegene Leistungsfähigkeit von Ethernet führte weiterhin dazu, dass ein SAN auch über Fibre Channel over Ethernet angeschlossen werden kann [Nol15].

• Maschinensteuerung Industrieunternehmen nutzen mittlerweile vernetzte Steueranlagen, die ebenfalls über klassische Vernetzungen angebunden werden. Die Trennung dieser Systeme erfolgt über separate Kabel.

• DMZ Unter der DMZ versteht man ein separates Netzwerk, in dem besonders zu sichernde Systeme stehen. Eine DMZ hat Verbindung zu internen als auch zu externen Netzwerken und steuert die regelkonforme Kommunikation zwischen diesen Netzen [Kap13]. In einer DMZ stehen im EMail-Systeme, Proxy- oder Webserver, da diese auch von außerhalb des Netzwerks erreichbar sein müssen [Bau01]. Interne Systeme wie File- oder Printserver müssen nicht in der DMZ stehen, sondern können in einen separaten Servernetzwerk stehen.

Eine Klassiﬁzierung der Daten in Cloud-Umgebungen anhand dieser groben Einteilung ist grund- sätzlich möglich, aufgrund der Vielzahl von Diensten und Anwendungen innerhalb der Umgebung ist jedoch eine feinere Granularität notwendig. Eine Unterscheidung der Daten kann anhand der jeweiligen Kunden erfolgen, da jeder dieser Kunden ein eigenes logisches Netzwerk bereitgestellt bekommt, um die gemieteten Server isoliert betreiben zu können. Ebenfalls neu hinzu gekommen sind Aspekte wie Abrechnung, Monitoring oder Management, durch die ebenfalls Netzwerkdaten produziert und übertragen werden.

94 4.9 Netzwerkdaten

Eine globale Klassiﬁzierung der Daten wäre zweigeteilt und unterscheidet die in einer Cloud- Umgebung anfallenden Daten in administrativ und nutzerbezogen:

• Administrative Daten Hierzu zählen der Zugriﬀ auf Verwaltungsoberﬂächen, das Hinzubuchen oder Entfernen diverser Einstellungen oder auch nur das Selektieren unterschiedlicher Optionen des Service durch den Kunden.

• Nutzerdaten Unterschiedliche Services bieten an, Daten zur Speicherung in die Cloud zu verlagern. Diese Daten werden meist auf unterschiedlichen Servern abgelegt und unterscheiden sich von den vorangegangenen Daten vorrangig anhand ihrer Datenmenge.

Eine konkretere Aufteilung von Daten, die zwischen internen Systemen ausgetauscht werden, liefert [Azo13], der vier Bereiche auﬂistet, nach denen die Netzwerke unterschieden werden können:

• External Dieses Netzwerk beschreibt alle Netzwerke für den externen Zugriff und Bereiche, deren Interface eine Anbindung an das Internet hat. Dies betrifft somit VMs mit einer Floating-IP oder auch Webserver, die die Managementoberflächen bereitstellen.

• API Hier erfolgt die gesamte Kommunikation der Cloud-Umgebung zu den Kundennetzwer- ken. Sofern ein Kunde eine Veränderung anfordert, wird diese Anforderung über das API- Netzwerk an die zuständigen Systeme transferiert.

• Data Über dieses Netzwerk kommunizieren die VMs innerhalb der Cloud-Umgebung. Erstellte Snapshots können über das Data-Netzwerk auf andere Systeme transferiert werden, ebenso erfolgt hier die Migration der VMs.

• Management Die Kommunikation der Cloud-Komponenten untereinander erfolgt über das interne Management- Netzwerk. Dies ist das einzige Netzwerk, welches keine direkten Berührungspunkte mit Aktionen des Kunden hat.

[Fif14] beschreibt eine ähnliche Aufteilung, allerdings werden die drei Netzwerke etwas anders deﬁniert:

• Internal Hierunter wird das Netzwerk bezeichnet, welches für internen Datenverkehr wie Imagever-

95 4 Problemanalyse

teilung oder Management genutzt wird. Auch Kommunikation untereinander über die API zwischen den einzelnen Komponenten wird hierüber transportiert.

• Public Dieses Netzwerk entspricht dem External Netzwerk nach [Pep11]. Zusätzlich werden hier noch Monitoringsysteme zugeordnet, deren Datenverkehr auch von extern erreichbar sein soll.

• VM Traﬃc Dieses Netzwerk bezeichnet ein isoliertes Netzwerk, welches nur explizit einem Kunden zur Verfügung steht.

Für die konkrete Analyse der anfallenden Netzwerkdaten in virtuellen Netzwerken ist diese Klas- sifizierung jedoch zu ungenau. Eine Einschränkung auf Daten, die der Definition von Data nach [Azo13] oder VM Traffic nach [Fif14] entsprechen, gefährdet die korrekte Durchführung des Auf- zeichnungsprozesses. In diesem Fall würden Migrationen zu spät bemerkt, da diese Daten nicht in den Identifikationsprozess eingebunden sind. Etwaige Änderungen, die Benutzer vornehmen, würden ebenfalls der Aufzeichnung entgehen.

Im Folgenden erfolgt daher eine detailliertere Unterscheidung der anfallenden Daten, um im Anschluss eine konkrete Bewertung vornehmen zu können. Dabei erfolgt keine Unterscheidung nach zugrundeliegendem physischen Netzwerk, sondern nur anhand der in einer virtuellen Cloud- Umgebung anfallenden Daten.

4.9.2.1 VM-Daten

Die Nutzung virtueller Maschinen erfolgt, da kein Hardwarezugang über Maus und Tastatur auf diese VM möglich ist, vollständig über ein Netzwerk. Zusätzlich wird eine VM wohl in den meisten Fällen37 mit dem Ziel betrieben, einen Dienst anzubieten, sei es intern für eigene Zwecke oder öﬀentlich für eine größere Zielgruppe.

Die transportierten Daten sind vom betriebenen Service abhängig, so produzieren Webserver andere Daten als EMailserver. Sofern eine dieser VM als Ziel der Überwachung identiﬁziert wurde, ist die Aufzeichnung aller dort empfangenen und versandten Daten das Ziel. Eine Unterscheidung zwischen Services erfolgt dabei im Normalfall nicht, so dass die Gesamtheit der VM-Daten das Primärziel darstellt und im besten Fall komplett aufgezeichnet werden kann.

37Eine mögliche Ausnahme hiervon sind z. B. lokale Testszenarien.

96 4.9 Netzwerkdaten

4.9.2.2 Migrationsdaten

Die Migration einer VM verursacht losgelöst von der Migrationstechnik eine erhöhte Datenüber- tragung im Netzwerk, da die VM auf ein anderes Wirtssystem umgezogen wird. Dabei können, in Abhängigkeit des Migrationsziels, unterschiedliche Verbindungen und Komponenten des physischen Netzwerks betroﬀen sein. Über diese Strecken werden dann die erstellten Snapshot-Dateien transportiert, wodurch große Datenmengen in kurzer Zeit übermittelt werden können.

Die anfallenden Daten beinhalten eine zum Zeitpunkt der Migration vollständige Kopie der VM, die theoretisch im Rahmen der forensischen Untersuchung relevant werden könnte. Allerdings ist es bei Zugriﬀ auf diese Daten in den meisten Fällen wohl ebenso möglich, die Daten der VM über den CSP separat zu erhalten, so dass diese nicht im Rahmen der netzwerkforensischen Arbeiten gesichert werden müssen.

4.9.2.3 Storageservice

Cloud-Umgebungen sind nicht ausschließlich auf die Bereitstellung von VMs limitiert, ebenso wird Speicherplatz zur Nutzung durch den Kunden angeboten. Hier ist es dem Nutzer möglich, den angemieteten Platz eigenständig zu verwalten; bezahlt wird dabei in den meisten Fällen nicht der genutzte Speicherplatz, sondern die Anzahl der Transaktionen38 zum Objektspeicher. Die Speicherung der Daten erfolgt im SAN des CSP, das über separate Netzwerke angeschlossen und so nicht unmittelbar mit den Netzwerken der VMs verbunden ist. Dennoch ist durch den CSP sichergestellt, dass auch Nutzer der VM-Umgebung Zugriﬀ und somit die Nutzungsmöglichkeit des Speichers durch ihre VMs haben.

4.9.2.4 Logins

Um unzulässige Zugriffe auf interne Systeme, die VMs oder auch der Services untereinander auszuschließen, ist in Cloud-Umgebungen ein Authentifizierungssystem integriert, welches die Berechtigungen verwaltet. Während externe Nutzer sich mittels Benutzernamen und Passwort an Managementumgebungen anmelden, werden die Zugriffe auf die betriebenen VMs durch eine Public-/Private-Key Authentifizierung abgesichert. Dies bietet den Vorteil, dass nur der Besitzer des richtigen Schlüsselpaars Zugriff auf den Server erhält. Interne Systeme kommunizieren meist über fest hinterlegte Benutzernamen und Passwörter, sie bekommen bei korrekter Anmeldung ein zeitlich limitiertes Token zugewiesen, um die Anmeldeprozeduren zu reduzieren. Da diese Daten meist sensible Daten wie Benutzernamen und Passwörter beinhalten, erfolgt die Übertragung verschlüsselt.

38Dies sind im Regelfall Aktionen wie Hinzufügen, Verschieben, Kopieren und Löschen.

97 4 Problemanalyse

4.9.2.5 Protokollierung

Die Protokollierung aller anfallenden Daten ist im professionellen Bereich obligatorisch [CSP12]. In virtuellen Umgebungen werden je nach Konﬁguration die wichtigsten Ereignisse aller Systeme protokolliert. Um eine zentrale Auswertemöglichkeit dieser Daten zu haben, erfolgt die Speiche- rung auf separaten Protokollierungssystemen.

Die Übertragung der Daten an den zentralen Server kann vertrauliche Daten beinhalten und erfolgt daher meist verschlüsselt. Je nach Konfiguration unterscheidet sich der Detailgrad der Informationen, des Weiteren ist die Art der protokollierenden Systeme flexibel. So ist es möglich, die Anmeldeformationen jeder VM zentral zu sichern oder diese dezentral und getrennt von anderen Logfiles aufzubewahren und dem Nutzer zur Verfügung zu stellen. Parallel dazu können Informationen eines CN, der installierten Netzwerkkomponenten oder die Daten von separaten Services zentral mitprotokolliert werden.

4.9.2.6 Backendkommunikation

Sofern eine Multitierarchitektur genutzt wird, entsteht zwischen den beteiligten Systemen ap- plikationsspeziﬁscher Datenverkehr, der von den kommunizierenden Services abhängig ist. Dies können z.B. Anfragen von Webservern an nachgelagerte Datenbanksysteme sein, um dort gespeicherte Informationen abzufragen. Im Rahmen dieser Kommunikationsart tauschen die unterschiedlichen Systeme bidirektional Daten aus.

Im Gegensatz dazu existiert zentral gesteuerter Datenverkehr, bei dem der CC als Hauptkom- munikator arbeitet. Dieser steuert den Ablauf zwischen den unterschiedlichen Services im Cloud- system miteinander, z.B. um Token anzufordern, Systemzustände abzufragen oder auch weitere Aktionen zu initiieren. Dabei koordiniert der CC die zuständigen Abfragen, steuert den Datenﬂuss zwischen den Services untereinander und verteilt notwendige Arbeitsaufgaben an die korrekten Stellen.

4.9.2.7 Backup

Backup und Wiederherstellung gehören zu einer der wichtigsten Aufgaben des IT-Verantwortlichen [Wal02]. [Sch06a] unterscheidet beim Backup zwischen

• System

• Database

98 4.9 Netzwerkdaten

• Filestorage

Diese Aufteilung gilt sowohl in klassischen als auch in virtuellen Umgebungen. Allerdings ist das das Backup im Cloud-Umfeld meist von größeren Datenmengen betroﬀen, da je nach Konﬁgura- tion Benutzerdaten in Form der VMs gespeichert werden, dies kann auf Ebene der VM-Images als auch in Snapshot-Form erfolgen. Sofern ein Storageservice angeboten wird, müssen auch diese Daten gesichert werden.

Daneben müssen natürlich auch die gesamten, für die Bereitstellung der Cloud-Umgebung notwendigen Daten gesichert werden. Dies umfasst Konﬁgurationen, Zugangsdaten, Images, Proto- kolle oder auch Templateinformationen.

4.9.2.8 Replikation

Zur Erhöhung der Datensicherheit werden die Benutzerdaten zwischen unterschiedlichen Berei- chen eines RZ oder auch zwischen unterschiedlichen RZ repliziert. Dieses Vorgehen bietet nach [Pet09] zwei Vorteile:

• Fehlertoleranz durch Verfügbarkeit weiterer Systeme bei Ausfall eines einzelnen Systems

• Schnelle Erreichbarkeit von unterschiedlichen Orten durch geograﬁsche Verteilung der Da- ten

Die Kunden haben meist auf diese Replikation keinen Einﬂuss, der CSP übernimmt die Steuerung und Konﬁguration dieser Daten. Dabei werden diese Daten zwischen unterschiedlichen Bereichen eines RZ oder sogar zwischen zwei oder mehreren RZ übertragen, um diese Daten verfügbar zu halten.

4.9.2.9 Imageserver

Auf Imageservern werden vorgefertigte Templates von VMs vorgehalten, die auf Anforderung des Kunden vom Imageserver auf die CN kopiert werden. Der CN speichert dieses Image lokal und generiert hieraus die Instanz der VM. Sofern auf diesem CN ein weiteres Abbild dieses Templates erstellt werden soll, muss keine erneute Kopie vom CN angefordert werden, da die notwendigen Daten lokal gespeichert sind. Der Vorteil einer solchen Implementierung liegt in der gestiegenen Dynamik, mit der die unterschiedlichsten Systeme dem Kunden bereitgestellt werden [OON+03].

99 4 Problemanalyse

4.9.2.10 Monitoring

Die Überwachung der laufenden Instanzen und der gesamten IT-Infrastruktur ist eine der Haupt- aufgaben beim professionellen Betrieb von IT-Umgebungen. Dabei stehen dem Betreiber leistungs- fähige Monitoringlösungen aus dem Open Source-Bereich als auch kommerzielle Lösungen zur Verfügung, die für die zu überwachende Umgebung geeignete Implementierungen bieten.

Ziel des Monitorings ist die Überwachung der Auslastung der beteiligten Systeme, um Fehler frühzeitig zu erkennen oder entstehende Problemfelder bereits proaktiv zu beseitigen [BW16]. Hierunter fallen Aspekte wie:

• Speicherplatznutzung

• CPU-Auslastung

• Übertragener Datenverkehr

• Status der Ports

• Aktueller Zustand (z.B. laufend, gestoppt, fehlerhaft) von Diensten und Anwendungen

Durch Auswertung dieser Parameter und Deﬁnition von Schwellenwerten ist es möglich, rechtzeitig über z.B. knapp werdenden Speicherplatz informiert zu werden, bevor der verfügbare Speicherplatz tatsächlich aufgebraucht ist.

Spezielle Lösungen wie CloudSec [IHHGA11] ermöglichen auch das Monitoring virtueller Ma- schinen auf Basis der VM Introspection. Einige Monitoringlösungen bieten neben der reinen Überwachung auch parallel die dazu passenden Managementaufgaben [BSB+10].

4.9.2.11 Netzwerkmanagementdaten

Die zentrale Steuerung der eingesetzten Komponenten in IT-Umgebungen wird aufgrund der hohen Anzahl von Geräten und Diensten bei immer weniger zur Verfügung stehenden Zeiten stetig wichtiger. Dabei versteht sich der Begriff des Netzwerkmanagements als Oberbegriff aus Netzwerkkonfiguration und Überwachung [Sch06b].

[Cle06] deﬁniert das Netzwerkmanagement als

[...] the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems.

100 4.9 Netzwerkdaten

Die vielfältigen Aufgaben des Netzwerkmanagements zeigen sich in unterschiedlichen Implemen- tierungen der Managementlösungen. Basis dieser Lösungen sind Protokolle wie SNMP [CFSD90] und SNMPv2, die neben dem Monitoring auch die Möglichkeit bieten, mit Hilfe von GET - Kommandos Konﬁgurationsparameter in IT-Systemen anzupassen. Dadurch ist es möglich, sämt- liche Geräte, die SNMP implementiert haben, zu überwachen und zu steuern. Dies umfasst neben Routern und Switchen auch Drucker, Computer oder Netzwerkkameras. Da der Informa- tionsgehalt von SNMP-Nachrichten für mögliche Angreifer im Netzwerk hoch ist, besteht die Möglichkeit, diese Daten durch einen Passwortschutz vor unberechtigtem Mitlesen zu schützen.

4.9.2.12 Abrechnung

Das Geschäftsprinzip des Cloud-Computings basiert auf einer nutzungsabhängigen Bezahlung. Der Kunde muss nur für die Dauer der Nutzung zahlen, deaktivierte und nicht laufende VMs produzieren somit keine Kosten. Die Abrechnung der Nutzung erfolgt durch den CSP.

Da dieser ein Interesse daran hat, konkrete und valide Abrechnungen bereitzustellen, um den Kun- den die entstandenen Kosten für die Nutzung in Rechnung zu stellen, werden Abrechnungssys- teme bereitgehalten. Diese Systeme kommunizieren mit den zentralen Komponenten des Cloud- Systems, um die Anzahl der genutzten CPU-Zeit, Speicherplatz oder laufenden Instanzen zu erhalten. Abhängig vom Kostenmodell werden hierdurch die zu zahlenden Kosten berechnet. Klassischerweise übernehmen Authentication, Authorization, Accounting (AAA)-Systeme diese Aufgabe [Met99].

4.9.2.13 Bewertung

In diesem Abschnitt wurden die anfallen Netzwerkdaten in virtuellen Umgebungen aufgeführt. Ausgehend von klassischen Umgebungen, in denen nur wenige unterschiedliche Daten anfallen, die meist über separate Links transportiert werden, wurden die unterschiedlichen Arten von Netzwerkdaten, die in virtuellen Umgebungen übertragen werden, deﬁniert und beschrieben.

Die bisher in der Literatur genutzte grobe Klassiﬁzierung in drei oder vier Bereiche ist für die Ermittlung der relevanten Netzwerkdaten nicht geeignet, so dass in diesem Abschnitt die forensische Relevanz der auftretenden Netzwerkdaten bewertet wird.

In Anlehnung an [Ste09] wird daher eine Unterscheidung in primäre und sekundäre Relevanz vorgenommen. In [Ste02] ﬁndet sich die folgende Unterscheidung:

Primary evidence must always be corroborated by at least one other piece of relevant primary evidence to be considered a valid part of the evidence chain. Evidence that

101 4 Problemanalyse

does not ﬁt this description, but does serve to corroborate some other piece of evidence without itself being corroborated, is considered to be secondary evidence.

Primäre Relevanz haben somit alle Netzwerkdaten, die unmittelbar Bezug zum Zielsystem besitzen. Sekundäre Relevanz erhalten somit alle Netzwerkdaten, die keinen direkten Bezug zu den Kommunikationsinhalten des Zielsystems besitzen, aber dennoch für die forensische Bewertung relevant sein können. Alle anderen Daten sind für die Aufklärung nicht relevant und können aus der Auswertung ausgeschlossen werden und werden daher im Folgenden mit einer tertiären Relevanz bewertet. Tabelle 4.1 ordnet die anfallenden Daten der jeweiligen Relevanz zu.

Die wichtigsten Daten sind die VM-Daten. Dies entspricht naturgemäß der Überwachung von Servern im klassischen Sinn. Die dynamische Steuerung der Wege von Daten im Netzwerk auf Basis von Southbound-API Implementierungen wie OpenFlow unterstützen die gestiegene Flexi- bilität im Netzwerk und sind somit ebenfalls von primärer Relevanz. Da diese Daten unmittelbaren Einﬂuss auf eingerichtete Aufzeichnungsprozesse haben, muss jede netzwerkforensische Arbeit in virtuellen Netzwerken diese Daten gesondert beachten.

Die Migrationsdaten mit sekundärer Relevanz beinhalten ebenfalls nützliche Informationen, anhand derer Bewegungen von VMs im Netzwerk beobachtet werden können. Eine adäquate Re- aktion auf diese Daten ermöglicht ebenfalls die korrekte Durchführung der netzwerkforensischen Arbeiten.

4.10 Softwareunterstützung

Neben der Aufzeichnung und Speicherung umfasst die netzwerkforensische Arbeit auch die Ana- lyse der aufgezeichneten Daten. Diese Analyse ist ohne geeignete Softwareunterstützung nicht möglich [Car03]:

The Complexity Problem in digital forensics is that acquired data are typically at the lowest and most raw format, which is often too diﬃcult for humans to understand. It is not necessarily impossible, but often the skill required to do so is great, and it is not eﬃcient to require every forensic analyst to be able to do so. To solve the Complexity Problem, tools are used to translate data through one or more layers of abstraction until it can be understood. To solve the Complexity Problem, tools are used to translate data through one or more layers of abstraction until it can be understood.

102 4.10 Softwareunterstützung

Tabelle 4.1: Forensische Relevanz der Netzwerkdaten Daten Relevanz Begründung VM-Daten primär DiesbetrifftdiekonkretenDatenderüberwachten VM. Migrationsdaten sekundär Die Daten der Migration entsprechen den Daten der VM, so dass hier keine relevanten Netzwerkdaten anfallen. Je- doch ist die Information über die Migration für die Anpas- sung des Aufzeichnungsprozesses relevant. Storageservice tertiär DieAktioneninnerhalbdesStorageservice werden separat protokolliert; die anfallenden Daten sind auf dem Stora- geservice vorhanden, so dass eine weitere forensische Auf- zeichnung der Daten keine neuen Hinweise liefert. Anmeldeinformation tertiär Die Übertragung der Anmeldeinformationen erfolgt ver- schlüsselt, da die Daten jedoch keine zusätzlichen Informa- tionen beinhalten, die in diesen Daten übertragen werden, ist eine Aufzeichnung nicht notwendig. Protokollierung tertiär Die Aufzeichnung der übertragenen Protokolldaten ist nicht notwendig. Die relevanten Daten können im Bedarfs- fall über die Logserver eingesehen werden. Backendkommunikation tertiär Die Kommunikation der Systeme untereinander beinhaltet keine relevanten Informationen. Backup tertiär DiegespeichertenDatenimBackupsindfür forensische Zwecke häufig interessant, da hierüber alte Versionen gesichert werden können. Eine Analyse des Backupdatenver- kehrs ist jedoch nicht zielführend, da die Datenmenge sehr groß werden kann und die transportierten Daten durch Ex- traktion direkt am Backupsystem gesichert werden können. Replikation tertiär Bei den Daten handelt es sich um Kopien, die keine zu- sätzlichen Daten enthalten. Imageserver tertiär Die transferierten Daten entsprechen den gespeicherten Templates, die vom Provider zur Verfügung gestellt werden. Sofern die Notwendigkeit einer Analyse existiert, kön- nen diese Daten vom Imageserver direkt extrahiert werden. Darüber hinaus beinhalten diese Daten keine relevanten Daten. Monitoring tertiär DieVerfügbarkeitundAuslastungunterschiedlicher Syste- me liefert keine konkreten Ermittlungsansätze. Netzwerkmanagement primär Informationen über die Steuerung der eingesetzten Kom- ponenten auf Basis von SNMP bietet keinen Nutzwert für die forensische Analyse. Konfigurationsprotokolle wie OpenFlow hingegen steuern direkt den Weg und die Ver- arbeitung im Netzwerk, so dass diese Daten in netzwerkforensische Analysen mit einbezogen werden müssen. Abrechnung tertiär Analog zu den Anmeldeinformationen beinhalten die Ab- rechnungsinformationen keinen zusätzlichen Mehrwert. Darüber hinaus können diese Daten auch vom Abrech- nungssystem ausgelesen werden.

103 4 Problemanalyse

Die eingesetzten Programme dekodieren die übertragenen Protokolle, extrahieren Daten und fügen separate Pakete zu kompletten Streams zusammen, so dass eine Auswertung mit anderen Werkzeugen möglich wird.

Während die klassische Netzwerkforensik etabliert ist und dort geeignete Werkzeuge zur Ver- fügung stehen, haben verschiedene neu auftretende Probleme der virtuellen Netzwerken auch Auswirkungen auf die Analyse. Dies betrifft sowohl die Aufbereitung der in Kapitel 2.3.2 beschriebenen neuen Netzwerkprotokolle als auch die zur Verfügung gestellten Daten der virtuellen Umgebungen. Diese implementieren Standards von Messverfahren wie SNMP oder Netflow, die jedoch nicht für forensische Arbeiten geeignet sind. In diesem Abschnitt werden die Auswirkungen der virtuellen Netzwerke auf den softwaregestützten Auswerteprozess definiert.

4.10.1 Protokolle

Eine manuelle Auswertung von digitalen Asservaten ist aufgrund der Datenmenge nicht mehr wirtschaftlich. Die Fehlerquote bei einer solchen Auswertung ist ebenfalls zu hoch, so dass dem IT-Forensiker unterschiedliche Softwareprodukte zur Verfügung stehen. Diese Software ermög- licht eine Automatisierung der Analyse, und bietet so neben einer Arbeitserleichterung auch Sicherheit bezüglich der Korrektheit der Ergebnisse.

In der IT-Forensik existieren viele Softwareprodukte, die sich in unterschiedlichen Kategorien einordnen lassen. Einige Programme übernehmen Aufgaben des Carvings39, andere wiederum bieten umfangreiche Forensikumgebungen, die parallel noch Dokumentationsmöglichkeiten anbieten. [AIJ14] bietet eine Übersicht über gängige Forensiksoftware und ihre Einsatzmöglich- keiten in der Cloud-Forensik. Als netzwerkforensisches Programm ist nur Wireshark genannt, allerdings auch nur mit dem Einsatzzweck der Analyse von Netzwerkdaten zwischen CSP und Kunde. [SEK15] beschreibt das Fehlen geeigneter Werkzeuge zur Analyse der Netzwerkdaten in Cloud-Umgebungen.

Neuentwicklungen im Bereich der forensischen Software mit der Zielrichtung einer Protokollana- lyse sind grundsätzlich möglich, da Implementierungsdetails aus dem entsprechenden Request for Comments (RFC) entnommen werden können. Allerdings zeigt die Realität, dass selbst Techni- ken wie IPv6, die seit etwa 20 Jahren bekannt sind40, heutzutage nicht umfassend unterstützt werden. So bietet die Software Moloch [Mol17] bis heute keine IPv6-Unterstützung, sondern wird nach [May16] als

39Carving wird eingesetzt, um gelöschte Dateien, deren Zuordnung im Dateisystem entfernt wurde, zu entdecken. Dazu wird der gesamte Speicher analysiert und nach bekannten Signaturen gesucht, die eine Datei eindeutig kennzeichnen. 40Das erste RFC zu IPv6 wurde im Dezember 1995 veröﬀentlicht [DH95]. Trotz dieser langen Entwicklungszeit ist IPv6 noch längst nicht vollständig und ﬂächendeckend eingeführt (Stand Mai 2017).

104 4.10 Softwareunterstützung

[...] an open source, large scale, IPv4 full PCAP capturing, indexing and database system.

Auch VLAN-Implementierungen verursachen bei verschiedenen Tools Probleme, so kann das Programm tcpdump VLAN-Informationen nicht korrekt interpretieren [Bug13].

Als Folge dieser Fehler sind mögliche Auswertungen stark eingeschränkt und meist nicht voll- ständig.

Wie im Kapitel 2.1.2.8 beschrieben, sind in der traditionellen Netzwerkforensik vorrangig die Schichten 3, 4 und 7 relevant. Im Bereich der virtuellen Netzwerke sind die Information der Schicht 2 ebenfalls relevant für eine valide forensische Bewertung. Hier ﬁnden sich die eindeutigen Identiﬁkationsmerkmale wie MAC-Adressen, VLAN-Tag oder VNI, die eine korrekte Zuordnung ermöglichen können. Entsprechende Werkzeuge müssen somit in der Lage sein, diese Daten zu extrahieren und in Kombination auszuwerten. Eine Übersicht über netzwerkforensische Programme liefern [HZ12] und [PJN10a].

Anhand der dort aufgeführten Programme wurden aktuell noch weiter entwickelte Tools aus- gewählt und analysiert, in welcher Form die neuen Netzwerkprotokolle und Herausforderungen verarbeitet werden können.

Die ausgewählten sechs Programme zeichnen sich (mit Stand vom Mai 2017) durch Aktualität und regelmäßiger Nutzung im Rahmen klassischer netzwerkforensischer Arbeiten aus:

• Wireshark 2.2.5 64 Bit

• Network Miner 2.1 beta

• Savvius Omnipeek Enterprise 10 64 Bit

• Moloch 0.12.0

• Xplico 1.1.2

• Bro 2.4.1

Die ersten drei Programme oder entsprechende Vorversionen wurden bereits in [Spi14] hinsichtlich ihrer Eignung zur Analyse von cloudbezogenem Datenverkehr analysiert.

Zur Analyse wurden pcap-Dateien erstellt, die ausschließlich relevante Datenpakete enthalten und mit dem Programm ausgewertet werden. Diese Dateien enthielten Daten der folgenden Protokolle:

105 4 Problemanalyse

• VXLAN

• QinQ

• IPv6

• OpenFlow

Tabelle 4.2 listet die Ergebnisse auf. Dabei bezeichnet ein „*“ die Fähigkeit, das jeweilige Pro- tokoll korrekt zu interpretieren.

Tabelle 4.2: Bewertung netzwerkforensischer Werkzeuge Software VXLAN OpenFlow QinQ IPv6 Wireshark * * * * NetworkMiner * * * SavviusOmnipeek * * * * Moloch Xplico * * Bro * *

Die Untersuchung hat gezeigt, dass nur ein Drittel der untersuchten Software in der Lage ist, die neuen Protokolle zu analysieren. Die anderen Produkte scheitern an der Analyse mindestens eines der untersuchten Protokolle, die Software Moloch als Umgebung für die Analyse von Massendaten ist nicht in der Lage, ein Einziges der neuen Netzwerkprotokolle zu erkennen und aufzubereiten. So wird VXLAN-Datenverkehr als UDP-Traﬃc angezeigt, nur die Rohdatenansicht ist in der Lage, aufgrund möglicher Klartextprotokolle den Datenverkehr anzuzeigen.

4.10.2 Zielrichtung

Gängige Netzwerkkomponenten sind in der Lage, Informationen über die transportierten Da- tenströme an eine zentrale Monitoringinstanz zu übermitteln. Die grundsätzliche Zielrichtung dieser Datensammlung und -übermittlung ist die Kapazitätsplanung, Verkehrssteuerung oder eine funktionsfähige QoS-Implementierung. Hierzu stellen die Komponenten die entsprechenden Funktionen bereit, um Statistiken über die angefallenen Daten aufbereitet zu übermitteln. Die am häuﬁgsten eingesetzten Techniken sind:

• Netflow Netflow bezeichnet eine Technik, die Informationen über IP-basierte Datenströme speichert. Die Ströme werden dabei von einer oder mehreren Komponenten wie Switche oder Router gesammelt und per UDP an einen sogenannten Netflow-Collector versandt

106 4.11 Overlapped IP-Addresses

[EKMV04]. Netﬂow wurde vorrangig mit dem Ziel des Monitorings und Troubleshootings entworfen, da hier nicht alle Daten relevant sind [Kev96].

• sFlow sFlow ist in der Lage, Informationen über zusätzliche Parameter zu ermitteln. Dafür nutzt sFlow einen zeitbasierten und einen prozentualen Ansatz zur Ermittlung der übermittelten Daten. Dabei ist sFlow nicht auf IP limitiert, ermittelt aber auf der anderen Seite nicht absolut genaue Informationen über die tatsächlich transferierten Pakete [WLL04].

Beide Techniken werden in der Netzwerkforensik eingesetzt, dabei aber vorrangig mit dem Ziel der Angriffserkennung und Ermittlung des Tathergangs [SLL05], [LYL04]. Aktuelle Netzwerkgeräte unterstützen meist mindestens einen Standard; OVS ist in der Lage, die übermittelten Daten sowohl per Netflow als auch per sFlow an das konfigurierte System zu übermitteln.

Da beide Techniken nicht das gesamte Netzwerkpaket übertragen, ist es für eine valide Auf- zeichnung aller anfallenden Daten eines einzelnen Zielsystems nicht geeignet. Somit sind die zur Verfügung stehenden Informationen nicht ausreichend, um die ermittelten Daten für netzwerkforensische Untersuchungen in virtuellen Netzwerken zu nutzen.

4.11 Overlapped IP-Addresses

Nicht nur die MAC-Adressen können in virtuellen Netzwerken mehrfach vergeben werden, auch IP-Adressen können mehrfach und parallel in einem Netzwerk genutzt werden [Cis12b]:

The IP Overlapping Address Pools feature improves flexibility in assigning IP addresses dynamically. This feature allows you to configure overlapping IP address pool groups to create different address spaces and concurrently use the same IP addresses in different address spaces.

In traditionellen Netzwerken ist die IP-Adressierung eindeutig, d.h. dass jede IP-Adresse in der gesamten Layer 2-Broadcastdomäne einmalig ist. Während öﬀentliche IP-Adressen weltweit eindeutig sind, sind die Bereiche der privaten IP-Adressen frei verfügbar [RMK+96]. Da diese IP- Adressen nicht im Internet geroutet werden, können sie in voneinander getrennten Netzwerken parallel genutzt werden.

Durch die Nutzung überlappender IP-Adressbereiche können die privaten IP-Adressbereiche parallel im RZ genutzt werden. Dabei werden die entsprechenden Systeme auf Layer 2-Basis getrennt und erhalten durch korrekte Routinginformationen sowie passende NAT-Implementierun- gen eine funktionsfähige Anbindung an andere Netzwerke. Die Trennung wird auf den betroﬀenen

107 4 Problemanalyse

Servern mit Hilfe von IP-Namespaces konﬁguriert. IP-Namespaces sind getrennte Bereiche innerhalb eines Rechners, in dem separate virtuelle Netzwerkkarten, Routinginformationen und TCP-Daten gültig sind [FBSJW08].

VMs innerhalb einer Cloud-Umgebung erhalten standardmäßig eine private IP-Adresse, die in diesem Zusammenhang auch Fixed-IP genannt wird [Bei14]. Sofern notwendig, können VMs zusätzlich eine Floating-IP erhalten. Diese aus dem Pool der öﬀentlichen IP-Adressen dem CSP zugeordnete Floating-IP wird einer VM temporär zugewiesen, um einen Zugriﬀ auf dieses System von externen Netzen zu ermöglichen [Bei14].

Durch die mehrfache Nutzung von IP-Adressen muss analog zur Nutzung der MAC-Adresse eine Kombination aus mehreren Daten genutzt werden, um die Ziel-VM eindeutig zu identiﬁzieren. Auch die Floating-IP ist kein dauerhaftes Identiﬁkationsmerkmal, da diese temporär zugewiesen wird und bei einem Neustart der VM geändert werden kann.

4.12 Linkauslastung

Das Problem der korrekten Aufzeichnungsposition verkompliziert sich zusätzlich durch die Fra- gestellung, wo die anfallenden Daten gespeichert und wie die Daten dorthin transportiert werden sollen. Bei Aufzeichnung an der pNIC des Wirtssystems fallen viele irrelevante Daten an, die aufgrund der vorgenannten Probleme (Abschnitte 4.8 und 4.11) mit hoher Wahrscheinlichkeit nicht korrekt geﬁltert werden können. Durch Probleme der Migration (Abschnitt 4.2) und der Nutzeranpassung (Abschnitt 4.3) wäre selbst ein einmalig korrekter Filter nach einer Änderung im Netzwerk wieder ungültig.

Somit ist die zu übertragene Datenmenge meist ein Vielfaches der tatsächlich benötigten und relevanten Informationen. Diese Daten müssen bei Nutzung klassischer Aufzeichnungsmethoden ebenfalls mit aufgezeichnet und gespeichert werden. Heutige Netzwerke mit einer Übertragungs- geschwindigkeit von bis zu 40 GBit/s übertragen viele Daten in sehr kurzer Zeit.

Die Vielzahl der Daten erschwert dabei sowohl die Aufzeichnung als auch die Speicherung und die spätere Analyse, da die Massendaten ohne geeignete Methoden manuell ausgeﬁltert werden müssen. Sofern keine Informationen über Migrationen oder Anpassungen im Netzwerk gespeichert werden, ist es nahezu unmöglich, die relevanten Netzwerkdaten aus den aufgezeichneten Daten zu extrahieren und korrekt zuzuweisen.

108 4.13 Vielzahl der Controller

4.13 Vielzahl der Controller

SDN-Controller übernehmen im Netz die Steuerung der Netzwerkdaten und nehmen hierdurch eine zentrale Position im Netzwerk ein. Zur korrekten Steuerung der anfallenden Netzwerkpa- kete benötigt der Controller genaue Kenntnis über das gesamte Netzwerk, hierzu zählen unter anderem:

• Anzahl der vorhandenen Switche

• MAC-Adressen der angeschlossenen Systeme

• IP-Adressen der angeschlossenen Systeme

• Routingregeln und Anbindung an externe Systeme

• Angebotene Dienste

Diese Datenbasis enthält viele Informationen, die für eine forensische Analyse wertvoll sind. Eine Extraktion dieser Daten würde besonders die korrekte Identiﬁkation des Zielsystems deutlich erleichtern.

Allerdings ist die Arbeitsweise dieser Controller diversitär und unterscheidet sich nicht nur in Details. Neben Unterschieden in der zur Implementierung genutzten Sprache sind weitere Diﬀe- renzierungen möglich. Diese umfassen z.B. die Art der Datenspeicherung, die Nutzung separater Systeme, die Anbindung an die Northbound-API oder auch die Bereitstellung einer API zur Abfrage und Kommunikation mit dem Service.

[SZZ+13] beschreibt die Situation bei den Controllern als vielschichtig, wodurch eine geeignete Lösung von der vorhandenen Installation abhängt:

But the current state of the SDN/OpenFlow controller market may be compared to early operation system for mainframes, which existed 40-50 years ago. [...] Early operating systems were extremely diverse, with each vendor or customer producing one or more operating systems speciﬁc to their particular mainframe computers. Eve- ry operating system could have radically diﬀerent models of command and operating procedures.

Ein einheitliches Vorgehen für die Extraktion der gespeicherten Daten ist somit nicht möglich. Jede forensische Arbeit in SDN-basierten Netzwerken verlangt daher ein angepasstes Vorgehen an den installierten Controller, wodurch ein automatisiertes Vorgehen nahezu ausgeschlossen ist. Die Zahl möglicher Implementierungen ist dabei zwar abnehmend, aber dennoch ist die Menge der

109 4 Problemanalyse angebotenen und installierter Controller höher, als dass man eine geeignete Lösungsmöglichkeit bereitstellen könnte.

Im Jahr 2015 existierten noch mehr als 70 SDN-Controller in unterschiedlichen Ausprägungen aus dem Open Source als auch aus dem kommerziellen Bereich auf dem Markt [SDx15]. Bereits im November 2016 hat sich diese Zahl auf knapp 50 SDN-Controller reduziert, von denen einige zwar noch am Markt existent sind, aber nicht mehr aktiv weiterentwickelt werden [Ope16]. Somit scheint auch hier die klassische Marktentwicklung zu greifen, so dass davon auszugehen ist, dass sich die Situation im Controllerbereich in den nächsten Jahren weiter ändert und nur noch wenige Angebote bestehen.

Jedoch ist es aus der Mobilfunk- oder Computerforensik bekannt, dass wenige vorherrschende Systeme keine einfache Auswertung garantieren. Im Bereich der Mobilfunkforensik existieren (mit Stand Mai 2017) faktisch mit den Betriebssystemen Apple iOS, Android und Windows Phone nur drei relevante Marktanbieter, ein allgemeiner standardisierter Auswerteprozess ist jedoch bisher nicht etabliert [MV14].

4.14 Unvollständigkeit der Informationen

Die Controller als zentrale Elemente sind für die Steuerung des Datenverkehrs im Netzwerk zuständig, anhand der vorgegebenen Konﬁgurationen setzen die beteiligten Switche die Regeln um. Dabei besitzen sowohl der Controller als auch die beteiligten Switche Informationen über die eingerichteten Flows und angeschlossenen Geräte.

Diese Informationsbasis ist aus forensischer Sicht sehr wertvoll, da hierdurch Aspekte der Identi- ﬁzierung und Konﬁguration ermittelt werden können. Eine Extraktion dieser Daten mit anschlie- ßender Aufbereitung würde im Vorfeld einer netzwerkforensischen Untersuchung den nutzbaren Informationsstand drastisch erhöhen, so dass einige der in diesen Kapitel besprochenen Probleme beseitigt wären oder schneller umgangen werden könnten.

Wenn ein Switch ein ihm unbekanntes Paket erhält, überträgt er dieses oder nur den Header an den Controller, der das Paket verarbeitet und anhand seiner Konﬁguration dem Switch die korrekte Weiterverarbeitung mitteilt. Der Controller besitzt somit für einen gewissen Zeitraum Kenntnis über die Flows, die auf einem Switch gespeichert sind. Allerdings ist diese Information nicht dauerhaft auf dem Controller gespeichert, da die Paketverarbeitung nur im Arbeitsspeicher stattﬁndet und nicht persistent gespeichert wird.

110 4.15 Klassiﬁzierung

Der Switch hingegen, der die Pakete verarbeiten soll, hat solange Kenntnis von den Flows, wie sie Gültigkeit haben. Diese Zeitspanne ist von zwei unterschiedlichen Parametern abhängig, die ein Flow als Attribut besitzt [ZGL12]:

• idle_timeout Dauer in Sekunden, nach denen ein Flow entfernt wird, wenn er nicht benutzt wurde.

• hard_timeout Dauer in Sekunden, nach denen ein Flow auf jeden Fall entfernt wird, unabhängig von einer Nutzung.

Eine dauerhafte Speicherung der relevanten Flows ist somit nicht sichergestellt, so dass eine ausschließliche Analyse der Daten anhand der Switche nicht ausreichend ist. Darüber hinaus besitzen die Switche nur Kenntnis über einen Teilaspekt der relevanten Daten und werden nur bedingt über Veränderungen im Netzwerk informiert.

4.15 Klassiﬁzierung

In diesem Kapitel wurden Probleme aufgeführt, die die Netzwerkforensik in virtuellen Netzwerken erschweren. Dabei sind sowohl der Aufzeichnungs-, der Speicherungs- als auch der Auswertepro- zess betroﬀen.

Die unterschiedlichen Probleme wurden in diesem Kapitel definiert und beschrieben. Die auf- geführten Probleme sind jedoch weder gleich kritisch noch betreffen sie immer alle Phasen der Netzwerkforensik. In diesem Abschnitt werden die Probleme den Phasen der Netzwerkforensik zugeordnet und hinsichtlich ihres Risikopotentials und ihrer Auswirkungen auf die jeweilige Phase klassifiziert.

Tabelle 4.3 listet die Phasen, die von den Problemen betroﬀen sind, sowie die Auswirkungen auf. Probleme, deren Risikopotential als hoch bewertet wurde, sind in der Lage, die gesamte netzwerkforensische Untersuchung scheitern zu lassen, sei es aufgrund nicht durchführbarer Aufzeichnungen oder der Verhinderung der Speicherung oder Analyse. Probleme mit mittlerem Risikopotential können die Untersuchung scheitern lassen, allerdings ist es mit erhöhtem Auf- wand dennoch möglich, die Untersuchung durchzuführen. Diese Probleme können z.B. durch eine mühsame und fehleranfällige händische Analyse beseitigt werden, auch wenn dieser Ansatz nicht den gültigen Standards entspricht. Probleme mit geringem Risikopotential können die Un- tersuchung behindern, in dem kleinere Schwierigkeiten auftreten, diese sind jedoch bereits durch erhöhten Hardwareeinsatz oder einer detaillierten Analyse im Vorfeld zu umgehen.

111 4 Problemanalyse

Tabelle 4.3: Problemklassiﬁzierung nach Phase und Risikopotential

Problem Aufzeichnung Speicherung Analyse Risikopotential Migration * hoch Nutzeranpassung * hoch Identiﬁkation * hoch vNIC Aufzeichnungsproblem * hoch Multitenancy * * gering InternerDatenverkehr * hoch physischeVernetzung * gering NichteindeutigkeitderMAC * * mittel Menge * * * gering Netzwerkdaten Bestimmung * gering Protokolle * mittel Software Zielrichtung * gering OverlappedIPAddresses * * mittel Linkauslastung * * gering VielzahlderController * * gering Unvollständigkeit * * mittel

112 4.15 Klassiﬁzierung

Als besonders schwerwiegend für den Aufzeichnungsprozess sind die Migration, die Nutzeran- passungen, der interne Datenverkehr und die vNICs zu bewerten. Diese Aspekte verhindern bei Eintritt des Ereignisses die Aufzeichnung der Daten, so dass inkonsistente, unvollständige und im schlimmsten Fall fehlerhafte Daten aufgezeichnet und gespeichert werden. Im Folgenden werden diese Problembereiche daher unter dem Begriﬀ der kritischen Aktionen zusammengefasst.

Die Aspekte der mehrfachen MAC- und IP-Adressen, die neuen Netzwerkprotokolle sowie die Unvollständigkeit der Informationsspeicherung auf den Komponenten sind von mittlerem Risi- kopotential. Die mehrfache Nutzung der MAC- oder IP-Adresse erschwert dabei besonders die spätere Analyse der Daten, da es unter Umständen komplizierter wird, einen Datenstrom dem richtigen Zielsystem zuzuordnen. Weiterhin ist es nicht möglich, diese Daten als Filterkriterium bei der Aufzeichnung zu nutzen, so dass die Menge der zu speichernden Daten nicht reduziert werden kann. Neuere Netzwerkprotokolle erschweren die Analyse, wenn die eingesetzte Software nicht in der Lage ist, die Protokollheader zu extrahieren und die gekapselten Daten zu analysieren. In diesem Fall ist eine manuelle Extraktion der Daten notwendig, indem die Header der Overlay-Protokolle entfernt werden. Die Unvollständigkeit der gespeicherten Daten ist durch eine Kombination aller zur Verfügung stehenden Informationsquellen zu umgehen, indem sämtliche Daten gesammelt, aufbereitet und hinsichtlich geeigneter Kriterien analysiert werden. Anschlie- ßend können diese Daten genutzt werden, um die netzwerkforensische Analyse zielgerichteter durchzuführen.

Das Problemfeld der Multitenancy ist in Umgebungen, die durch unterschiedliche Personen genutzt werden, ein bekanntes Problem [SEK15]. Allerdings ist es möglich, im Nachhinein bei der Aufbereitung der Daten geeignete Methoden zu nutzen, um die fehlerhaft gespeicherten Da- ten aus den Aufzeichnungen zu entfernen, so dass nur die Speicherung der nicht im Vorfeld zu reduzierenden Daten erschwert wird. In einem solchen Fall kann es bereits ausreichen, das Aufzeichnungssystem leistungsstärker auszustatten, so dass mehr Datenpakete pro Sekunden aufgezeichnet werden können. Durch diesen Ansatz können ebenfalls die Probleme der Datenmenge und -bestimmung beseitigt werden, da so auch diese Daten gespeichert werden können. Auch hier kann die nachträgliche Aufbereitung diese Daten entfernen, so dass letztlich nur relevante Netzwerkpakete verbleiben. Die Linkauslastung kann nicht ausschließlich durch den erhöhten Hardwareeinsatz reduziert werden, da dieses Problem auch Auswirkungen auf die interne Ver- netzung des CSP hat. Die genutzte physische Vernetzung sollte in der Lage sein, die Kopie der Netzwerkdaten zeitgerecht zum Speichersystem zu übertragen ohne Daten zu verlieren.

Diese physische Vernetzung kann je nach Aufzeichnungsposition ebenfalls den Analyseprozess verkomplizieren, da auch hier zusätzliche Netzwerkdaten anfallen, die die Datenmenge der zu speichernden Informationen aufblähen und so die Analyse erschweren. Da diese Protokolle jedoch nur für das interne Management genutzt werden und somit keine relevanten Nutzerdaten beinhalten, ist es möglich, die Daten zu entfernen.

113 4 Problemanalyse

Die Bereitstellung zusätzlicher Managementdaten in Form von Netﬂow oder sFlow ist für die Ent- deckung und Analyse von Netzwerkangriﬀen ein sinnvolles zusätzliches Feature, welches jedoch nicht von elementarer Bedeutung für die forensische Analyse im Rahmen der Strafverfolgung ist.

Die Vielzahl der unterschiedlichen Ausprägungen eingesetzter SDN-Controller kann ebenfalls die Forensik in solchen Netzwerken erschweren, allerdings ändert sich das eingesetzte Controller- Setup in diesen Umgebungen nicht dynamisch, so dass eine für die aktuelle Situation implementierte Lösung für den Ablauf der Untersuchung stabil bleiben wird. Somit muss einmalig zu Beginn eine manuelle Anpassung erfolgen, die anschließend Gültigkeit innerhalb dieser Umge- bung behält. Aktuell ist jedoch die Anzahl der möglichen Systeme zu hoch, um ein einheitliches Vorgehen zu entwickeln, welches für einen Großteil der Controller gültig ist. Somit erscheint es realistisch, dass sich das Auswerteproblem der SDN-Controller auch in der nahen Zukunft nicht eklatant verbessert.

4.16 Zusammenfassung

Eine korrekte Durchführung forensischer Arbeiten ist von vielen Faktoren abhängig. Unterschied- liche Probleme können dabei eine erfolgreiche Untersuchung verhindern oder zumindest erschweren. Probleme, die Auswirkungen auf netzwerkforensische Untersuchungen in virtuellen Umge- bungen haben, wurden in diesem Kapitel vorgestellt und hinsichtlich ihrer Relevanz gewichtet und klassiﬁziert. Dabei wurden Probleme ermittelt, die schwere Auswirkungen auf laufende Auf- zeichnungen haben, genauso existieren Schwierigkeiten, die nur geringe Auswirkungen auf Un- tersuchungen in virtuellen Umgebungen haben. Hierzu gehören Probleme, die z.B. die Analyse der Daten erschweren.

Aufbauend auf diesen Problemfelder deﬁniert das folgende Kapitel erfolgskritische Anforderun- gen, die erfüllt sein müssen, um forensische Arbeiten in virtuellen Netzwerken durchführen zu können.

114 5 Entwicklung eines Anforderungsmodells

Dieses Kapitel beschreibt die Analyse unterschiedlicher Kriterien, die für eine erfolgreiche Durch- führung netzwerkforensischer Arbeiten in virtuellen Umgebungen entscheidend sind. Aufbauend auf diesen Anforderungen wird ein Modell entwickelt, welches diese Anforderungen gewichtet und die Kriterien mit den im vorigen Kapitel deﬁnierten Problemfeldern korreliert.

Zuerst erfolgt die Deﬁnition geeigneter Kriterien. Nicht alle dieser Kriterien sind neu, in der traditionellen Netzwerkforensik existieren genauso wie in der IT-Forensik bereits geprüfte und funktionierende Anforderungen, die für die virtuellen Netzwerke übernommen werden können. Somit erfolgt eine Aufteilung der Rahmenbedingungen in:

• Etablierte Anforderungen

• Speziﬁsche Anforderungen

Nach der Deﬁnition dieser Rahmenbedingungen erfolgt eine Bewertung der Kriterien und Über- prüfung, welche Probleme durch eine Bedingung beseitigt werden.

5.1 Etablierte Anforderung

Die klassische IT-Forensik sowie die Netzwerkforensik verfügen über Best-practice-Vorgehen, ge- sicherte Techniken und geprüfte sowie funktionierende Umsetzungen zur Arbeitserfüllung. Diese Standards können teilweise auch für die neuen Herausforderungen gelten, sei es durch geringfü- gige Anpassung oder durch direkte Übernahme des Standards.

5.1.1 IT-Forensik

Um IT-Forensik korrekt zu betreiben, existieren unterschiedliche Anforderungen, die mittlerweile als anerkannter Standard gelten. [Ges14] deﬁniert acht unterschiedliche Anforderungen an die IT-Forensik:

115 5 Entwicklung eines Anforderungsmodells

• Akzeptanz Es sollen im Rahmen der Untersuchung nur Werkzeuge und Techniken eingesetzt werden, die allgemein akzeptiert sind. Neue Maßnahmen sind erst durch unabhängige Stellen zu prüfen, bevor sie eingesetzt werden sollten.

• Reproduzierbarkeit Hiermit wird gefordert, dass die durchgeführten Arbeitsschritte jederzeit nachvollziehbar und wiederholbar sind. Eine nachträglich durchgeführte Untersuchung darf nicht zu einem anderen Ergebnis führen als die vorherigen Analysen. Teilweise sind Ausnahmen von dieser Praxis anerkannt, wenn neue Auswertetechniken oder neuere Softwareversionen entstehen, die die aufgefundenen Daten tiefergehend auswerten können. Durch Protokollierung der durchgeführten Schritte ist es auch nachträglich möglich, die forensische Untersuchung nachvollziehen und zumindest auf dem Papier reproduzieren zu können.

• Glaubwürdigkeit Einhergehend mit der Akzeptanz der eingesetzten Werkzeuge muss auch der Forensiker glaubwürdig sein. Dies umfasst das vorhandene Fachwissen als auch die Berechtigung, die anfallenden Arbeiten erledigen zu dürfen.

• Dokumentation Die Protokollierung der durchgeführten Schritte muss vollständig sein und somit als Ver- laufsprotokoll bereitgestellt werden. In klassischen netzwerkforensischen Untersuchungen ﬁndet im Normalfall keine detaillierte Protokollierung der Maßnahmen statt, da besonders der Aufzeichnungsprozess statisch ist. Dabei stellt die Aufzeichnung und Speicherung der gesamten Netzwerkpakete bereits eine Form der Protokollierung da, so dass auf zusätzliche Nachweise verzichtet werden kann.

• Ursache und Auswirkung Die logische Nachvollziehbarkeit der aufgefundenen Daten muss mit den eingesetzten Werkzeugen möglich sein. [Bun11] deﬁniert dies als why-because-Formel, durch die für jedes gefundene Ereignis eine Begründung gefunden werden muss.

• Lückenlosigkeit Es muss lückenlos nachgewiesen werden, was wann wie mit den genutzten Beweismitteln durchgeführt wurde. Diese als Chain-of-Custody deﬁnierte Abfolge wahrt die Nachvollzieh- barkeit der durchgeführten Arbeitsschritte [Nat04].

• Authentizität Es muss erkennbar sein, dass die durchgeführten Arbeiten von der angegebenen Person durchgeführt werden. Diese Authentizität kann durch die persönliche Unterschrift als auch durch eine digitale Signatur erfolgen.

116 5.1 Etablierte Anforderung

• Integrität Eine korrekte Untersuchung verlangt, dass ein Originalsystem nicht verändert wird. Hier- zu wird in der klassischen Computerforensik mit bitgenauen Kopien gearbeitet, die vor weiteren Analyseschritten erstellt werden. Die weiteren Arbeiten werden dann mit dem Sicherungsimage durchgeführt. Hierdurch bleibt das Originalsystem in einem konsistenten Zustand, so dass jederzeit wieder auf die Ursprungsversion zurückgekehrt werden kann. Die Einhaltung dieser Anforderung garantiert ebenfalls die Reproduzierbarkeit der Analyse. Durch Vergleich von Hashwerten können etwaige Veränderungen festgestellt werden.

Von dieser Anforderung sind jedoch Ausnahmen anerkannt. So führen Arbeiten im Rahmen der Live-Forensik zu einer Datenveränderung am auszuwertenden System, in dem durch den Start von spezialisierten Programmen Arbeitsspeicherinhalte oder Registryeinträge ver- ändert werden.

Auch in der Netzwerkforensik sind nachträgliche Manipulationen der Originaldaten nicht ausgeschlossen. Programme wie editcap [OR+04] ermöglichen die Veränderung der aufgezeichneten Daten, wodurch Zeitstempel verändert oder VLAN-Informationen entfernt werden können. Anonymisierer ermöglichen die komplette Veränderungen der aufgezeichneten Daten, so dass Quell- oder Zieladressen verändert, die Prüfsummen angepasst sowie Informationen der Schichten 3 und 4 manipuliert werden und somit die gesamte Auszeich- nung unbrauchbar wird [LLW+16], [PAPL06]. Mit Hilfe von Hash-Chaining ist es möglich, Änderungen in Dateifragmenten konstant nachzuweisen [GR97]. Durch entsprechende Pro- gramme, die ein Verzeichnis auf Änderungen überwachen und neu ankommende Daten kontinuierlich hashen, ist es somit möglich, Veränderungen zu erkennen.

[SJ07] beschreibt, dass diese Anforderungen nicht nur auf die klassische Computerforensik an- zuwenden sind, sondern auch in der Netzwerkforensik Anwendung ﬁnden müssen. Sofern eine Forderung nicht erfüllt werden kann, gilt jedoch die Verpﬂichtung, jeden der durchgeführten Schritte nachvollziehbar zu dokumentieren.

5.1.2 Netzwerkforensik

In der Netzwerkforensik existieren ebenfalls anerkannte Methoden, deren Einhaltung die Aufzeich- nung, Speicherung und Analyse der Daten vereinfacht und dabei sicherstellt, dass sachgerecht gearbeitet werden kann [Cha14].

• Quellennähe Diese Forderung besagt, dass die Aufzeichnung so nah wie möglich an der Quelle (dem

117 5 Entwicklung eines Anforderungsmodells

Zielsystem) erfolgen muss. Hierdurch kann garantiert werden, dass keine unnötigen, irre- levanten Daten aufgezeichnet werden. Je weiter sich die Aufzeichnungsposition von dem tatsächlichen Ziel entfernt, desto ungenauer wird die Aufzeichnung, die durch irrelevante Netzwerkpakete aufgebläht wird. Darüber hinaus gefährdet eine größere Entfernung vom Ziel die vollständige Datenaufzeichnung, so dass die gespeicherten Daten nachträglich nicht mehr korrekt analysiert werden können.

• Vollständiger Datenmitschnitt Diese Anforderung besagt, dass die aufgezeichneten Daten unter allen Umständen voll- ständig und zusammenhängend sein müssen. So können Datenverluste auftreten, wenn keine geeignete Aufzeichnungsmethode für die Situation ausgewählt wurde oder während der Aufzeichnung Änderungen an der Umgebung auftreten. So sind installierte Bridges als Single-Point-of-Failure eine mögliche Ausfallquelle bei einem Softwarefehler oder Konﬁgu- rationsproblem. Mirrorports können durch übermäßig viele ankommende und abgehende Pakete überlastet werden, so dass der beteiligte Switch Datenpakete verwirft, um seine Hauptaufgabe weiterhin erfüllen zu können.

Dabei sagt die Anforderung nichts über die Datenmenge aus, so dass auch Aufzeichnungen entstehen können, die eine Vielzahl irrelevanter Daten beinhalten.

5.2 Speziﬁsche Anforderungen

Neben den etablierten Anforderungen der klassischen IT-Forensik und der Netzwerkforensik sind weitere Anforderungen für Untersuchungen in virtuellen Netzwerken notwendig. Die im Kapitel 4 definierten Probleme sind vielschichtig und betreffen alle Phasen der Netzwerkforensik. Die bisherigen Anforderungen definieren dabei keine Lösungsansätze für diese neuen Probleme [AIJ14]. So sind die Aspekte der Migration oder der vNICs nicht abgedeckt, so dass in diesem Abschnitt neue Anforderungen entwickelt werden. Diese Anforderungen zielen auf die auftretenden Probleme ab, ohne konkrete Implementierungsdetails zu benennen.

5.2.1 Datenreduktion

In der Cloud-Umgebung fallen viele Daten an, die über gleiche Netzabschnitte geleitet oder sogar aufgrund der Mehrbenutzerfähigkeit der Wirtssysteme über eine einzelne pNIC transportiert werden (vgl. Abschnitt 4.9.2). Die Anbindung der installierten VMs erfolgt jeweils über eine vNIC, die den ausgehenden Datenverkehr über die involvierte pNIC transportiert. Die korrekte Zuordnung der Netzwerkdaten zu der VM erfolgt anhand vorgegebener VLAN-IDs oder durch

118 5.2 Speziﬁsche Anforderungen

Techniken wie VXLAN. In der klassischen Netzwerkforensik ist das Problem der Massendaten zwar ebenfalls existent, jedoch aufgrund der geringeren Anzahl parallel laufender Systeme weniger kritisch.

Um die Datenmenge während der Aufzeichnung zu reduzieren und so die spätere Analyse zu vereinfachen, sollen nur die relevanten Daten, die direkten Bezug zur untersuchten VM haben, aufgezeichnet werden. Dies bedeutet, dass nur Netzwerkdaten der Ziel-VM aufgezeichnet und gespeichert werden dürfen, um die anfallende Datenmenge zu reduzieren und somit die spätere Analyse zu vereinfachen.

5.2.2 Dynamische Adaption

Die hohe Flexibilität in der virtuellen Umgebung stellt eine netzwerkforensische Untersuchung vor eine Vielzahl von Problemen. So können VMs migriert oder durch den Nutzer soweit angepasst werden, dass die anfallenden Netzwerkdaten über andere Wege zum Ziel geroutet werden.

Eine geeignete Umsetzung der netzwerkforensischen Arbeiten in virtuellen Netzwerken muss somit entsprechend ﬂexibel gestaltet werden, um dynamisch und autonom auf Änderungen im Netzwerk zu reagieren und die Aufzeichnung anpassen zu können.

Dies bedingt eine korrekte Identifikation der Ziel-VM innerhalb des Netzwerks. In der klassischen Netzwerkforensik ist die korrekte Identifizierung des betroffenen Netzwerkanschlusses ohne großen Aufwand möglich. Einzig eine hohe Portdichte und große Anzahl von Netzwerkkompo- nenten erschweren die zeitnahe Identifizierung, jedoch ist es im Zweifelsfall durch eine händische Verfolgung des Netzwerkkabels möglich, den korrekten Switchport zu ermitteln. Weitere Ansätze bieten Tracingwerkzeuge, die mittels digitaler Signale ein Auffinden des korrekten Anschlusses ermöglichen. Durch Nutzung fortgeschrittener Anschlusstechniken wie in [GLMP01] beschrieben wird die Identifikation ebenfalls erleichtert.

In virtuellen Umgebungen sind diese hardwarebasierten Ansätze ohne Wirkung, so dass die Er- mittlung des korrekten vPorts durch andere Techniken realisiert werden muss. So protokollieren und speichern innerhalb der virtuellen Umgebung verschiedene Stellen die benötigten Informatio- nen ab. Hierzu gehören die beteiligten vSwitche, aber unter Umständen auch der SDN-Controller oder die CN oder CC der Infrastruktur. Nach der Identiﬁzierung und der initialen Einrichtung der Aufzeichnung muss die Lösung in der Lage sein, diese Arbeitsschritte erneut durchzuführen, um die Aufzeichnung im Falle einer Änderung erneut zu implementieren.

119 5 Entwicklung eines Anforderungsmodells

5.2.3 Monitoring

Die Identiﬁzierung einer VM zu Beginn der Untersuchung sowie die initiale Einrichtung des Auf- zeichnungsprozesses ist vergleichbar mit den Arbeitsschritten der klassischen Netzwerkforensik. In virtuellen Umgebungen treten jedoch zur Laufzeit Änderungen auf, die den konﬁgurierten Prozess stören und somit die gesamte Untersuchung scheitern lassen können.

Um diese Änderungen zu bemerken, muss eine geeignete Lösung bereitgestellt werden, die

• Parameter zur Überwachung entgegennehmen kann,

• eine deﬁnierte Anzahl von Komponenten überwacht,

• ein Regelwerk zur Bewertung der Änderungen besitzt,

• geeignete Methoden zur Information über diese Änderungen besitzt,

• parallel zu anderen Prozessen abläuft,

• bis zum manuellen Abbruch dauerhaft läuft.

Eine solche Monitoringlösung, die das Netzwerk auf Änderungen überwacht, ermöglicht die dauerhafte Aufzeichnung aller relevanten Daten, indem sie bei Eintritt von Ereignissen eine An- passung des Aufzeichnungsprozesses initiiert. Dabei sind nicht alle Änderungen gleich relevant, nur Ereignisse, die Bezug zum Zielsystem haben, müssen verarbeitet werden. Der dauerhafte Betrieb parallel zu weiteren Prozessen garantiert dabei die durchgehende Überwachung und die Sicherstellung einer geeigneten Aufzeichnung.

Parallel zu den Anpassungen kann das Monitoring protokollieren, welche Änderungen im Auf- zeichnungsprozess stattfanden und somit nachvollziehbar speichert, wie sich die forensische Un- tersuchung während des Ablaufs verändert hat.

5.2.4 Datenschutz

Nach [Wit10] deﬁniert der Datenschutz den

[...] Schutz des Einzelnen vor Beeinträchtigung seines Persönlichkeitsrechts beim Umgang mit seinen personenbezogenen Daten.

Die IT-Forensik und der Datenschutz sind unmittelbar miteinander verbunden, da im Rahmen von forensischen Untersuchungen häuﬁg Daten aufgezeichnet oder extrahiert werden, die keinen

120 5.2 Speziﬁsche Anforderungen direkten Bezug zum Sachverhalt haben. Hierbei kann es sich um persönliche Korrespondenz oder auch private Bilder handeln, die zur Aufklärung keinen Bezug haben. In § 32, Abs. 1 Bundesdatenschutzgesetz [GSK05] wird daher konkret für das Unternehmensumfeld festgelegt, dass selbst bei Untersuchung von Straftaten bereits im Vorfeld geprüft werden muss, ob die Interessen des Unternehmens zur Aufklärung die Interessen des Beschuldigten überwiegen.

Soll von Strafverfolgungsbehörden die Überwachung eines Verdächtigen durchgeführt werden, gelten hier die jeweiligen staats- und verfassungsrechtlichen Vorgaben, die eine Aufzeichnung von fremden Benutzerdaten genehmigen, wenn ansonsten keine Daten gespeichert werden kön- nen. Eine anschließende Analyse der Daten darf jedoch nur erfolgen, wenn für die Ermittlung irrelevante Daten vorher ausgeschlossen werden. Dieser Schutz bestimmter Bereiche wie der privaten Lebensgestaltung wird auch als Kernbereichsschutz deﬁniert [Bod12].

Klassische Methoden der Netzwerkforensik können durch geeignete Maßnahmen sicherstellen, dass datenschutzrechtliche Aspekte gewahrt sind. Durch die Aufzeichnung dedizierter pNICs ist ausgeschlossen, dass Daten anderer Benutzer ohne Bezug zum Zielsystem mit aufgezeichnet werden. Die Anbindung der vNICs über eine pNIC bei zeitgleicher Aufzeichnung an dieser pNIC verhindert diese eindeutige Zuordnung der Daten. Das Fehlen geeigneter Filterkriterien erschwert die nachträgliche Überprüfung der aufgezeichneten Daten und die Löschung irrelevanter Daten gemäß des Kernbereichsschutzes.

Daher muss die Lösung schon bei der Aufzeichnung ausschließlich die relevanten Daten aus- wählen, um wenig bis keine Fremddaten in der nachfolgenden Analyse zu erhalten. Nur durch eine solche Implementierung ist eine manuelle und fehleranfällige Nachbearbeitung im Sinne des Datenschutzes möglich.

5.2.5 Herstellerunabhängigkeit

Die Vielzahl unterschiedlicher Hersteller, Reseller und Provider führt zu einem heterogenen Um- feld der eingesetzten Hard- und Software. Hierdurch entstehen unterschiedlichste Konﬁguratio- nen, die jeweils für den besonderen Einsatzzweck im Netzwerk ausgelegt sind. Netzwerkforen- sische Untersuchungen werden hierdurch erschwert, so dass im Vorfeld Rahmenbedingungen, Parameter und Details zur internen Struktur aufgeklärt werden müssen. Nur so ist eine zielgerichtete Aufzeichnung der Daten möglich.

In virtuellen Netzwerken kommen neben den physischen Komponenten noch die unterschiedlichen Implementierungen der logischen Netzwerkstruktur hinzu. Aspekte wie NFV ermöglichen den Betrieb klassischer hardwaregebundener Komponenten in virtualisierter Form als Softwareappli-

121 5 Entwicklung eines Anforderungsmodells kation auf Standardhardware. SDN-basierte Netzwerke nutzen zentrale Controller zur Steuerung der Pakete durch das Netzwerk.

Während die klassische Vernetzung und Arbeitsweise wie Layer 2-Switching oder Layer 3-Routing sich nicht elementar geändert hat, implementieren die neuen Techniken wie SDN zusätzliche Komponenten, die von hohem Wert für die forensische Aufzeichnung der Daten sind. Zentrale Controller legen die Wege der Netzwerkpakete in Form von Flows fest; erhält ein Forensiker Kenntnis dieser Flows, kann er adäquat reagieren und den installierten Aufzeichnungsprozess anpassen. Die Flüchtigkeit dieser Informationen verhindert jedoch eine dauerhafte Nutzung dieser Daten, so dass zurückliegende Ereignisse, die Auswirkungen auf die Aufzeichnung haben, nicht erfasst werden.

Die Heterogenität der eingesetzten Komponenten verhindert weiterhin ein allgemeingültiges Vor- gehen, so dass die genutzten Techniken mühsam an die jeweilige Implementierung angepasst werden müssen. Die Nutzung einer eventuell existierender Application Programming Interface (API) schwächt dieses Problem nur gering ab, da die Hersteller nicht den gleichen Umfang an Funk- tionen implementieren oder keine entsprechenden Schnittstellen zur Verfügung stellen. Die verschiedenen Programmiersprachen, mit denen die Controller implementiert wurden, erschweren zusätzlich die Erstellung eines universellen Ansatzes.

Die zu nutzende Lösung muss daher unabhängig von möglichen Herstellern, Programmierspra- chen und Konﬁgurationen arbeiten und die zu nutzenden Informationen über standardisierte Wege ermitteln. Erst diese Herstellerunabhängigkeit kann eine ﬂexible Nutzung der Forensik in virtuellen Netzwerken ermöglichen.

5.2.6 Hardwareunabhängigkeit

Da in der klassischen Netzwerkforensik physische Ports und separate Hardware genutzt werden, um die Daten abzugreifen, sind diese Möglichkeiten in virtuellen Umgebungen nutzlos. Um die relevanten Daten aufzeichnen zu können, muss eine geeignete Lösung in der Lage sein, die anfallenden Daten mit Hilfe andere Techniken aufzuzeichnen. Die anschließende Speicherung der Daten ist jedoch losgelöst von dieser Einschränkung, da hierbei wieder auf die Nutzung physischer Systeme zurückgegriﬀen werden kann.

Grundsätzlich stehen zwei Möglichkeiten bereit, um eine korrekte Aufzeichnung der relevanten Daten durchzuführen:

• Aufzeichnung des gesamten Datenverkehrs an der pNIC Bei dieser Lösung wird analog zum Vorgehen in der klassischen Netzwerkforensik am physischen Anschluss die Datenaufzeichnung implementiert. Da über diese pNIC jedoch Daten

122 5.2 Speziﬁsche Anforderungen

aller internen VMs transportiert werden, muss eine Filterung dafür sorgen, dass nur die relevanten Daten gespeichert werden. Zusätzlich werden hierbei keine Daten gespeichert, die innerhalb des Wirtssystems ausgetauscht werden.

• punktgenaue Aufzeichnung an der vNIC Die vNIC einer VM überträgt sämtliche Netzwerkdaten, die von der VM gesendet oder empfangen werden. Dies umfasst auch die Daten, die innerhalb des Wirtssystems an andere VMs transportiert werden sollen. Durch die eindeutige Zuweisung der vNIC an die VM ist keine weitere Maßnahme notwendig, um irrelevante Daten herauszuﬁltern. Sämtliche Netzwerkpakete, die an der vNIC aufgezeichnet werden, müssen gespeichert werden, um so in der späteren Analyse einen konsistenten Datenstrom zur Verfügung zu haben.

Die Vorteile der Aufzeichnung aller Netzwerkdaten an der vNIC überwiegen deutlich. So ist eine Filterung der Daten nicht notwendig, da nur VM-bezogene Daten über diesen Anschluss transportiert werden. Datenschutzrechtliche Probleme treten somit nicht auf, und die Gesamtzahl der aufgezeichneten Pakete wird auf das erforderliche Minimum reduziert.

5.2.7 Netzlastminimierung

In der klassischen Netzwerkforensik ist es durch die hardwarebezogene Struktur möglich, weitere Systeme in räumlicher Nähe bereitzustellen, um den Datenverkehr, der durch die Aufzeichnung entsteht, nur über kurze Distanzen und nicht über eine Vielzahl von Links oder Transitstrecken zu übertragen.

Virtuelle Netzwerke ermöglichen dies nicht, da eine räumliche Nähe zwischen VM und Aufzeich- nungssystem nur schwerlich deﬁniert werden kann. Spätestens nach der Migration einer VM ändert sich diese Distanz und die aufgezeichneten Daten müssen möglicherweise über separate Strecken und weitere Distanzen transportiert werden.

Hierdurch steigt die Netzlast unter Umständen deutlich an, so dass das gesamte physische Netzwerk beeinträchtigt werden kann. Grundsätzlich sollte das Netzwerkdesign diese Belastung verarbeiten und durch ausreichende Skalierungsmöglichkeiten der Netzwerkgeschwindigkeit die möglichen Latenzen reduziert können [BR13]. Ist dies nicht der Fall, erhöhen sich Laufzeiten, Verzögerungen und womöglich auch die Paketverluste im Netzwerk, so dass keine vollständige Übertragung der Daten mehr garantiert ist.

123 5 Entwicklung eines Anforderungsmodells

5.3 Lösungsmodell

Die in diesem Kapitel beschrieben Anforderungen deﬁnieren grundlegende Bedingungen, die eine Lösung für die Forensik in virtuellen Netzwerken erfüllen muss. Jede der vorgenannten Rahmen- bedingungen beseitigt mindestens eines der im Kapitel 4 aufgeführten Probleme. Durch eine konsequente Beachtung der Anforderungen ist eine entsprechende Lösung somit in der Lage, eine

• vollständige,

• dauerhafte,

• minimierte,

• ﬂexible

Methode zu implementieren, die sowohl die Aufzeichnung als auch die Speicherung und die Ana- lyse der Daten ermöglicht. Tabelle 5.1 listet zusammenfassend die speziﬁschen Anforderungen und die hierdurch berührten Probleme auf. Dabei werden die Aspekte der Akzeptanz, Glaub- würdigkeit, Authentizität und Lückenlosigkeit nicht weiter beachtet. Eine Akzeptanz des neuen Vorgehensmodells ist ebenso wie die Glaubwürdigkeit ein mit der Zeit entstehendes Merkmal, welches nicht für neue Methoden und Implementierungen gelten kann. Die Authentizität ist nicht Teil des Anforderungsmodells, da die Aufzeichnung und Speicherung der anfallenden Netzwerk- pakete automatisiert erfolgt. Dennoch ist es im Rahmen netzwerkforensischer Untersuchungen üblich, die entsprechenden schriftlichen Nachweise anzufertigen. Dies ist jedoch nicht Teil des An- forderungsmodells. Ebenso muss die Chain-of-Custody eingehalten werden, auch dies ist jedoch kein spezieller Aspekt der virtuellen Netzwerke.

124 Tabelle 5.1: Anforderungsmodell Problemfeld

Software- Anforderung vNIC Netzwerkdaten unterstützung Menge Bestimmung Protokolle Zielrichtung Overlapped IP Linksauslastung Controllervielfalt Unvollständigkeit Migration Nutzeranpassung Identiﬁkation Aufzeichnung Multitenancy Interner Datenverkehr physische Vernetzung MAC-Adressen Reproduzierbarkeit * * * * Dokumentation * * * * * * Ursache und Auswirkung * * * * * Integrität * * * Quellnähe * * * * * * * * * * Vollständigkeit * * * * * * Datenreduktion * * * * * Dynamische Adaption * * * * * * * Monitoring * * * * * * Datenschutz * * Herstellerunabhängigkeit * * * Hardwareunabhängigkeit * * * * * * * * * *

125 Netzlastminimierung * * 5 Entwicklung eines Anforderungsmodells

5.4 Zusammenfassung

Eine erfolgreiche netzwerkforensische Untersuchung hängt von unterschiedlichen Kriterien ab. Dies gilt nicht nur in traditionellen Netzwerken, sondern auch in virtuellen Umgebungen. Wäh- rend in der klassischen Netzwerkforensik die Anforderungen bekannt waren, haben die neuen Herausforderungen der virtuellen Netzwerke große Auswirkungen auf den Erfolg einer Untersu- chung, so dass in diesem Kapitel erfolgskritische Anforderungen deﬁniert wurden. Nur durch Beachtung dieser Parameter ist es möglich, die in Kapitel 4 beschriebenen Probleme korrekt zu verarbeiten oder zu umgehen, so dass weiterhin eine vollständige Aufzeichnung möglich ist.

Eine Verarbeitung der kritischen Aktionen ist dabei die wichtigste Aufgabe im Rahmen netzwerkforensischer Untersuchungen in virtuellen Netzwerken. Wie das in diesem Kapitel erarbei- tete Anforderungsmodell aufzeigt, existiert keine singuläre Lösung für diesen Bereich. Allerdings ermöglicht eine Kombination unterschiedlicher Anforderungen eine geeignete Umsetzung. Dabei müssen Aspekte der Überwachung mit einer flexiblen Anpassung des Aufzeichnungsprozesses kombiniert werden. Tritt ein relevantes Ereignis auf, wird die Aufzeichnung dynamisch und automatisch angepasst, so das im Rahmen der Untersuchung manuelle Änderungen notwendig werden. Durch Nutzung einer hardwareunabhängigen Aufzeichnung an der relevanten vNIC wird es letztlich möglich, die anfallenden Daten des Zielsystems konsistent aufzuzeichnen. Dabei kann das gesamte Aufzeichnungssystem autonom laufen, die erstmalige Initiierung mit geeigneten Identifi- kationsmerkmalen reicht aus, um ein geeignetes Modell bereitzustellen. Als positive Nebeneffekte der Hardwareunabhängigkeit, des Monitorings, der dynamischen Anpassung und der quellnahen Aufzeichnung sind auch die mehrfache Nutzung von MAC- und IP-Adressen weniger kritisch. Da direkt an der korrekten vNIC aufgezeichnet wird, können somit auch keine Netzwerkpakete mit doppelten Daten auftreten.

Darüber hinaus wird die Netzlast minimiert, da tatsächlich nur die relevanten Daten des Systems übertragen werden. Backupinformationen, Imagedateien oder auch Managementdateien aus dem physischen Netzwerk werden nicht bis an diese Schnittstellen übertragen und können somit ebenfalls nicht in den aufgezeichneten Daten auftauchen. Auch datenschutzrechtliche Aspekte werden beachtet, da keine Daten anderer Benutzer in der Aufzeichnung gespeichert werden. Durch eine durchgängige Protokollierung aller Anpassungen ist es auch nachträglich möglich, den Aufzeichnungsprozess nachzuvollziehen.

Das in diesem Abschnitt deﬁnierte theoretische Lösungsmodell wird im folgenden Kapitel mit existenten Vorgehensmodellen verglichen, anschließend wird es anhand realer Implementierungen hinsichtlich der Tauglichkeit veriﬁziert.

126 6 Entwicklung eines angepassten Vorgehensmodells

Die forensische Arbeit hat das Ziel, Vorfälle und gegebene Sachverhalte nachträglich aufzuklären oder Vorkommen nachzuweisen. Dies verlangt neben einer korrekten und gründlichen Vorgehens- weise auch die Nutzung etablierter Techniken. Um dem Forensiker Handlungssicherheit zu bieten, stehen neben verschiedenen Normen wie [DIN16] und [DIN15] auch unterschiedliche Vorgehens- modelle zur Verfügung, die ein strukturiertes Vorgehen ermöglichen.

In diesem Kapitel erfolgt zuerst eine Analyse spezieller Vorgehensmodelle, die für die Arbeit in traditionellen Netzwerken Gültigkeit hatten. Anschließend wird untersucht, ob die Anforderungen aus Kapitel 5 von diese Modelle abgedeckt werden.

Aufbauend auf diesen Ergebnissen wird ein neues, auf die Forensik in virtuellen Netzwerken ausge- richtetes Vorgehensmodell vorgestellt, welches auf die besonderen Herausforderungen ausgelegt ist und die aufgestellten Anforderungen erfüllt. Dieses Modell dient in den weiteren Schritten als Richtschnur für die Entwicklung forensischer Methoden von OVS und OpenFlow-Netzwerken.

6.1 Vorgehensmodelle

In Abschnitt 3.4 wurden unterschiedliche Modelle vorgestellt, die für forensische Analysen in Cloud-Umgebungen entwickelt wurden. Keins dieser Modelle ist jedoch für den Einsatz in virtuellen Netzwerken geeignet, sondern zielt auf die Datenextraktion aus Cloud-Umgebungen ab.

Die Netzwerkforensik ist jedoch nicht auf die Extraktion der Daten beschränkt, erst durch aktive Maßnahmen ist eine Datenaufzeichnung möglich. Im Folgenden werden Modelle, die für netzwerkforensische Untersuchungen genutzt werden, analysiert und bewertet.

127 6 Entwicklung eines angepassten Vorgehensmodells

6.1.1 Diﬀerenzierung

Für den Bereich der IT-Forensik existiert eine Vielzahl unterschiedlicher Modelle, jedoch existiert kein Referenzmodell, welches allgemeingültig ist. Auch für kleine Teilbereiche sind keine Stan- dardmodelle anerkannt, so dass eine Vielzahl unterschiedlichster Modelle entwickelt wurde, die sich anhand folgender Charakteristika unterscheiden:

• Anzahl der Phasen Die Anzahl der Phasen ist größtenteils abhängig von der Zerlegung und dem Detailgrad der erstellten Phasen. Hierdurch entstehen Modelle, die aus nur vier Phasen bestehen [Nat01], andere nutzen bis zu 17 Unterprozesse, die sehr detailliert die notwendigen Schritte beschreiben [CS+03].

• Lokale Besonderheiten Die Entwicklung der Modelle erfolgt meist im Hinblick auf die gegebenen Rahmenbedin- gungen. Dies umfasst z.B. lokale Besonderheiten, so ist das Modell nach [Bun11] speziell für die Anforderungen des deutschen Rechtssystems ausgelegt.

• Einsatzgebiet Die unterschiedlichen Modelle decken nicht immer die allgemeine Computerforensik ab. So existieren Modelle der Computerforensik [BT04], der Mobilfunkforensik [YJS+09], für forensische Arbeiten in Cloud-Umgebungen [RC12] oder auch für Live-Forensik [WZZ09]. Jedes dieser Modelle zielt auf die Besonderheiten der Arbeiten in diesen Bereichen ab und deﬁniert dadurch detailliertere Richtlinien als die allgemeinen Modelle.

• Nomenklatur Die Benennung der Phasen erfolgt ebenfalls unterschiedlich, so dass gleiche Arbeitsschritte unterschiedlich benannt [CS+03] oder unterschiedlich bewertet werden [BC05]. Somit entstehen vom Ablauf faktisch gleiche Modelle, die sich jedoch hinsichtlich der Namensgebung vorhandener Phasen unterscheiden und so einen Vergleich erschweren.

Hierdurch entsteht eine Vielzahl von unterschiedlichen Modellen, sogar für kleine Teildiszipli- nen existiert eine hohe Anzahl unterschiedlicher Modelle. [Pol07] deﬁniert 15 unterschiedliche Vorgehensmodelle der IT-Forensik, [Sit08] listet 14 unterschiedliche Modelle auf, die sich dabei jedoch wiederum nur minimal unterscheiden. Die wissenschaftliche Analyse der unterschiedlichen Modelle ist bereits in mehreren Arbeiten erfolgt [JS15], [RCG02], [SYS08], so dass hier keine weitere detaillierte Analyse erfolgt.

128 6.1 Vorgehensmodelle

6.1.2 Modellbeschreibung

Die Vielzahl existenter Vorgehensmodelle ist so hoch, dass eine zeitgerechte Erfassung und Be- wertung aller Modelle nahezu unmöglich ist. In diesem Abschnitt werden daher exemplarisch einige Vorgehensmodelle beschrieben, deren allgemeine Zielrichtung auch auf die Netzwerkforen- sik angewandt werden kann.

• DFRWS [AIJ14] deﬁniert in Anlehnung an [RCKB13] das Modell nach [PC01] des Digital Forensic Research Workshop (DFRWS) als einen De-Facto-Standard. Das Modell beinhaltet die Phasen Identiﬁcation, Preservation, Collection, Examination, Analysis und Presentation. Das Modell nutzt für die Implementierung als eines der Ersten eine akademische Heran- gehensweise, die auf Basis wissenschaftlicher Ansätze die forensische Arbeit beschreibt. Vorherige Modelle basierten meist auf Ansätzen der Strafverfolgung [RCG02]. Abbildung 6.1 zeigt den aufeinander aufbauenden Ablauf der Phasen.

Identiﬁcation

Preservation

Collection

Examination

Analysis

Presentation

Abbildung 6.1: DFRWS Vorgehensmodell

• BSI Das BSI gehört zum Geschäftsbereich des Bundesministeriums des Inneren und ist für Fra- gen der IT-Sicherheit zuständig. Das vom BSI empfohlene Vorgehensmodell [Bun11] ist ein Kreislauf von sechs Teilaufgaben. Diese umfassen die strategische und die operationale Vorbereitung, die Datensammlung, die Untersuchung, die Datenanalyse sowie die Doku- mentation. Von zentraler Bedeutung ist dabei die Dokumentation, die im Gegensatz zu anderen Modellen nicht am Ende der Gesamtuntersuchung steht, sondern im Mittelpunkt der forensischen Arbeit steht. Dabei werden in jedem Arbeitsschritt die durchgeführten Aufgaben protokolliert und so zu einer Gesamtdokumentation zusammengeführt. Abbil-

129 6 Entwicklung eines angepassten Vorgehensmodells

dung 6.2 zeigt den Kreislauf sowie die Querverbindungen und die zentrale Position der Dokumentation.

strategische operationale Vorbereitung Vorbereitung

Abschlussbericht Dokumentation Datensammlung

Datenanalyse Untersuchung

Abbildung 6.2: Vorgehensmodell des BSI [Bun11]

• Generic Network Forensic Process [PJN10a] beschreibt mit dem Generic Network Forensic Process (GNFP) ein speziell für die Netzwerkforensik angepasstes Vorgehensmodell, welches mit Hilfe von Wiederholungen zwischen der Analyse und der Untersuchung eine zusätzliche Flexibilität ermöglicht. Abbil- dung 6.3 zeigt das Modell und die Aufteilung zwischen den Phasen. In [PJN10b] wird dieses Modell mit neun anderen Modellen verglichen, von denen jedoch keins die erforderlichen Phasen für eine vollständige netzwerkforensische Analyse abdeckt.

Preparation

Incident Detection Response

Collection

Preservation Improvement of security tools Improvement Examination

Analysis

Investigation

Presentation

Abbildung 6.3: Vorgehensmodell nach [PJN10a]

130 6.1 Vorgehensmodelle

6.1.3 Schwächen

Die beschriebenen Modelle decken grundlegende Arbeiten der Netzwerkforensik ab. Auch das Modell des DFRWS und des BSI ermöglicht ohne die explizite Konkretisierung zur Netzwerkfo- rensik die Anwendung des jeweiligen Modells bei solchen Untersuchungen.

Die entsprechenden Arbeitsschritte finden sich beim DFRWS in den Aspekten der Identifikation (Identification), Speicherung (Collection) und nachfolgenden Analyse (Analysis), folglich ist die Nutzung dieses Modells auch im Rahmen netzwerkforensischer Arbeiten möglich.

Das Modell des BSI beschreibt mit der strategischen Vorbereitung eine pro-aktive Arbeit, die vor allen anderen Maßnahmen erledigt werden sollte. In Verbindung mit der operationalen Vor- bereitung entspricht dies dem Vorgehen der Netzwerkforensik, in dem aktiv gearbeitet werden muss, um eine Datenaufzeichnung zu erhalten. Eine solche Unterteilung von aktiv und reaktiv ﬁndet sich auch in [GLS10], der die Netzwerkforensik in einen aktiven (ActDF), einen proaktiven (ProDF) und einen reaktiven (ReDF) Abschnitt unterteilt. Der aktive Part besteht dabei aus der Überwachung der Aufzeichnung und der notwendigen Anpassung. Reaktiv ist dann die Aufzeich- nung und die Adaption an sich. Die Analyse und Aufbereitung der bereits gespeicherten Daten während des Aufzeichnungsprozesses wird als proaktiv bezeichnet. Die Phasen der Datensamm- lung und der Analyse decken die notwendigen Arbeiten der klassischen Netzwerkforensik ﬁnal ab.

Das speziell für den Bereich der Netzwerkforensik entwickelte GNFP zielt noch detaillierter auf die Anforderungen ab und ermöglicht so in traditionellen Netzwerken eine valide Handlungs- anweisung zur Aufgabendurchführung. Allerdings ist das GNFP eher auf die Aufklärung von Angriﬀen anhand von Netzwerkdaten ausgelegt [PJN10b] und zielt somit nicht originär auf die Aufzeichnung des Datenverkehrs eines einzelnen Systems ab.

Die Anforderungen, die virtuelle Netzwerke an die Forensik stellen, werden von keinem der vorgestellten Modelle vollständig abgedeckt. Hier sind die Anforderungen wesentlich komplexer, vor allem der Aufzeichnungsprozess weicht deutlich vom statischen Prozess in traditionellen Syste- men ab. Grundsätzlich könnte man deﬁnieren, die Probleme der hohen Dynamik und Flexibilität sowie die notwendigen Anpassungen auch in Phasen wie Collection oder Datensammlung zu verarbeiten. Dies deckt sich mit der Eigenschaft der Vorgehensmodelle, keine detaillierten Hand- lungsansweisungen für einen konkreten Sachverhalt vorzugeben, sondern nur eine unterstützende Struktur anzubieten [KOE06].

Dieser Ansatz ist jedoch zu ungenau und deckt nicht sämtliche Anforderungen ab. Besonders die kritischen Aktionen in virtuellen Netzwerken, die eine Rekonﬁguration des Aufzeichnungspro- zesses verlangen, müssen aufgrund der Relevanz in einem geeigneten Modell speziell betrachtet werden. Nur so kann dem Forensiker eine passende Handlungsanweisung bereitgestellt werden,

131 6 Entwicklung eines angepassten Vorgehensmodells die in virtuellen Netzwerken Gültigkeit besitzt. Hier sind wiederholende Phasen notwendig, die im Modell des BSI oder des GNFP existieren, jedoch eine andere Zielrichtung abdecken.

Phasen, die eine Überwachung des Netzwerks beschreiben, sind in keinem existenten Modell etabliert. Auch notwendige Anpassungen sind nicht in vorhandenen Modellen dargestellt, so dass die kritischen Aktionen der virtuellen Netzwerke nicht hinreichend beachtet werden. Ebenso führt die sequentielle Abarbeitung ohne mögliche, erneute Identiﬁzierung zu einer fehlerhaften Durchführung in virtuellen Netzwerken.

Somit ist keins der vorgestellten Modelle in der Lage, die Anforderungen aus Kapitel 5 voll- umfänglich abzudecken, so dass im Folgenden ein neues Vorgehensmodell für die Forensik in virtuellen Netzwerken entwickelt wird.

6.2 Virtual Network Forensic Process

Da die bisher existenten Modelle nicht auf die Besonderheiten der virtuellen Netzwerke eingehen, wird in diesem Abschnitt aufbauend auf den deﬁnierten Anforderungen detailliert die Entwick- lung eines neuen Modells beschrieben. Da dieses Modell explizit für die Forensik in virtuellen Netzwerken entwickelt wird, trägt das Modell in Anlehnung an das GNFP den Namen Virtual Network Forensic Process (VNFP). Das Modell wurde erstmals in [SKE17] beschrieben.

Eine forensische Untersuchung in virtuellen Netzwerken umfasst in Anlehnung an die traditionelle Netzwerkforensik mindestens die folgenden Arbeitsschritte:

• Identiﬁkation des korrekten (virtuellen) Anschlusses

• Bereitstellen der Aufzeichnungsmethode

• Speicherung der aufgezeichneten Daten

• Überwachung des Netzwerks auf Änderungen

• Anpassung der Aufzeichnung

• Analyse

Das neue Modell nutzt bereits bekannte Phasen der Vorgehensmodelle. Dies ermöglicht eine vereinfachte Deﬁnition des Modells bei gleichzeitiger Wahrung einer einfachen Überprüfbarkeit, da so nur die neuen Phasen des Modells validiert werden müssen. Falls möglich, werden Phasen weitergenutzt, eventuell müssen jedoch die darin enthaltenen Aufgaben angepasst und erweitert

132 6.2 Virtual Network Forensic Process werden. Dies betrifft vorrangig die Phase der Identifizierung und der Analyse der aufgezeichneten Daten. Die weiteren Phasen sind aufgrund der neuen Anforderungen neu hinzugekommen oder unterscheiden sich wesentlich von den bekannten Methoden, so dass eine detaillierte Definition notwendig ist.

Insgesamt entstehen somit acht Phasen, deren Ablauf in Abbildung 6.4 dargestellt ist.

Identiﬁkation

Vorbereitung

Aufzeichnung Adaption

Bewertung

Speicherung Überwachung

Analyse

Abbildung 6.4: Vorgehensmodell der Netzwerkforensik in virtuellen Umgebungen

Im Gegensatz zu existierenden Modellen ist das VNFP kein linearer Prozess mit sequentieller Abarbeitung der Phasen, sondern ein Kreislauf wiederkehrender, parallel laufender Prozesse mit unterschiedlichen Verzweigungen. Dieser Kreislauf ist in Abbildung 6.4 als gestrichelter Pfeil dargestellt. Erst wenn der Aufzeichnungsprozess durch den Forensiker beendet wurde, endet dieser Kreislauf und die Phase der Analyse tritt ein.

Im Folgenden werden die Phasen beschrieben und hinsichtlich ihrer veränderten Aufgaben deﬁ- niert.

6.2.1 Identiﬁkation

In der Phase der Identifikation werden alle Techniken zusammengefasst, die eine eindeutige Iden- tifizierung der korrekten VM ermöglichen. Dies kann je nach Situation die folgenden Parameter betreffen:

• genutzte vNIC

133 6 Entwicklung eines angepassten Vorgehensmodells

• MAC-Adresse

• IP-Adresse

• VLAN-ID

• VNI

Die entsprechenden Informationen finden sich an unterschiedlichen Stellen, Hauptausgangspunkt für die Identifikation ist jedoch die VM als Basis für alle weiteren Schritte. Da sich einige Pa- rameter aufgrund auftretender Ereignisse im Netzwerk dynamisch verändern können, muss die Identifizierung unter Umständen wiederholt ausgeführt werden. Nach der erfolgreichen Identifi- zierung erfolgt der Übergang in die Phase der Vorbereitung.

6.2.2 Vorbereitung

In der Phase der Vorbereitung werden alle Arbeiten zusammengefasst, die vor der tatsächlichen Aufzeichnung durchgeführt werden müssen. Diese Phase nutzt die Informationen aus der Phase der Identiﬁkation, um zielgerichtet die Aufzeichnung vorbereiten zu können. Dies umfasst das Starten der Aufzeichnungssysteme, die Konﬁguration der Mirrorports oder der ausgewählten Aufzeichnungstechnik sowie weitere administrative Maßnahmen, die im Rahmen der forensischen Arbeit notwendig sind. Nach diesen initialen Vorbereitungen erfolgt der Übergang in die Phase der Aufzeichnung.

6.2.3 Aufzeichnung

Die Phase der Aufzeichnung umfasst die Konﬁguration und die Spiegelung der anfallenden Netz- werkdaten. Die Aufzeichnung bezieht sich dabei auf die Nutzung der vNICs, entspricht ansonsten jedoch weitestgehend der Phase der Datenaufzeichnung in existenten Modellen.

Allerdings sind in virtuellen Netzwerken die zur Verfügung stehenden hardwarebasierten Techni- ken (vgl. Kapitel 2.6.2) nutzlos, da hierüber kein direkter Zugriff auf die vNIC möglich ist. Daher bleibt als einzig nutzbare Technik die Implementierung von Mirrorports, die die anfallenden Daten der vNIC vollständig auf einen anderen Virtual Port (vPort) spiegeln. An diesem vPort befindet sich das Aufzeichnungssystem, welches so konfiguriert ist, dass sämtliche ankommenden Daten gespeichert werden. Dabei muss dieses System nicht zwangsläufig auf dem gleichen CN laufen. Die virtuelle Umgebung und die Flexibilität der Netzwerke ermöglicht dank der Tunnelprotokolle sogar eine räumliche Verteilung und eine große Distanz zwischen dem überwachten und dem auf-

134 6.2 Virtual Network Forensic Process zeichnendem System. Da hierbei jedoch die Netzlast im gesamten Netzwerk steigt, sollte primär versucht werden, die Aufzeichnungs-VM nah an der Ziel-VM anzuschließen.

6.2.4 Überwachung

Die Phase der Überwachung existiert in klassischen Modellen nicht, da die dortigen Netzwerke keine Dynamik aufwiesen, die eine spezielle Überwachung verlangen. Etwaige Veränderungen in diesen Netzwerken erfolgen langsam und meist nur mit zusätzlichem manuellen Aufwand. Im Rahmen der manuellen Anpassung ist somit eine Anpassung der Aufzeichnungstechnik möglich, wodurch eine Monitoringlösung nicht notwendig ist.

In einem virtuellen Netzwerk ist diese Starrheit jedoch nicht gegeben. Die Umgebung ist hochdynamisch und kann ohne Wissen und Einﬂussnahme des Providers und somit auch des Fo- rensikers verändert werden. In der Phase der Überwachung werden nun die notwendigen Ar- beitsschritte zusammengefasst, die den einmal eingerichteten Aufzeichnungsprozess inklusive der beteiligten Systeme auf Änderungen überwacht. Tritt eine Änderung ein, muss dies im Rahmen der Überwachung bemerkt werden.

Die Phase der Überwachung beinhaltet das Monitoring aller beteiligten Komponenten unter Einbeziehung geeigneter Informationsquellen. Diese Quellen können an diversen Positionen im Netzwerk vorhanden sein und von unterschiedlichen Komponenten bereitgestellt werden. So sind die folgenden Quellen mögliche Positionen, um Informationen über Änderungen im Netzwerk zu erhalten:

• Log-Dateien

– des Betriebssystems

– des Cloud-Controllers

∗ über Netzwerkänderungen

∗ über VM-Migrationen

– der Switch-Instanz

– des Compute-Nodes

∗ über Netzwerkänderungen

∗ über VM-Migrationen

135 6 Entwicklung eines angepassten Vorgehensmodells

• Datenbanken

– des Cloud-Controllers

– der Switch-Instanzen

– des SDN-Controllers

• API

– der Switch-Instanz

– des Compute-Nodes

– des Cloud-Controllers

• Message-Queue der Cloud-Umgebung

Welche dieser Quellen für die Überwachung genutzt wird, ist nicht Bestandteil des VNFP. Je nach Einsatzzweck sind die Informationsgrade der Quellen unterschiedlich, so dass situativ entschieden werden muss, wie die Überwachung implementiert wird.

Theoretisch wäre im Rahmen des Monitorings auch eine Bewertung der Änderung möglich, jedoch wird im VNFP durch die zusätzliche Phase der Bewertung diese Analyse und Auswertung der Änderung realisiert. Hierdurch wird die Phase der Überwachung von zusätzlichen Aufgaben entlastet. Des Weiteren ermöglicht diese Trennung die Anpassung der einen Phase, ohne dass die andere Phase mit geändert werden muss.

6.2.5 Bewertung

Nicht jede Änderung im Netzwerk hat unmittelbare Auswirkungen auf den Aufzeichnungsprozess. So ist der Neustart einer weiteren VM im Netzwerk unkritisch, sofern diese nicht auch überwacht werden soll. Dennoch produziert ein solcher Start der VM an vielen Stellen Protokolleinträge, da der CN Speicher bereitstellen, vNICs anfordern oder ACLs implementieren muss. Parallel können auf den involvierten vSwitchen durch den SDN-Controller Flows implementiert werden, die den Datenverkehr dieser VM steuern. Der CC informiert beteiligte Systeme wie die AAA- oder Imageserver, aktualisiert interne Parameter zur Anzeige im Dashboard und reserviert Floating- IPs.

Hierdurch entstehen massenhaft Daten, die im Rahmen der Überwachung bemerkt werden und in dieser Phase der Bewertung verarbeitet werden müssen. Um die Relevanz der eingetretenen

136 6.2 Virtual Network Forensic Process

Ereignisse bewerten zu können, muss in dieser Phase bereits bekannt sein, welches eindeutige Identiﬁkationsmerkmal die Ziel-VM besitzt. Sofern dabei keine einzelnen Attribute ausreichen, muss im Rahmen der Bewertung auch die Kombination unterschiedlicher Attribute möglich sein, die eine möglichst konkrete Auswertung der Ergebnisse ermöglicht. Die relevanten Informationen wurden hierfür in der Phase der Identiﬁkation gesammelt.

Sofern das Ereignis im Netzwerk Auswirkungen auf den Aufzeichnungsprozess hat, erfolgt die Re-Identiﬁzierung der VM sowie die Adaption der bisher laufenden Aufzeichnung. Dies bedeutet, dass die laufende Aufzeichnung gestoppt wird, bis die Identiﬁzierung erneut erfolgreich durchge- führt wurde. Hierdurch wird garantiert, dass keine Daten anderer Systeme in die Aufzeichnung aufgenommen werden und so die spätere Analyse erschweren.

6.2.6 Adaption

Sollte die Phase der Überwachung eine Veränderung im Netzwerk bemerken, die durch die Phase der Bewertung als relevant bewertet wird, muss die Aufzeichnung angepasst werden. Dies erfolgt in der Phase der Adaption. Um diese wieder korrekt zu implementieren, muss durch die Phase der Bewertung konkret bestimmt werden, was die Änderung verursacht hat. So sind notwendigen Anpassungen wegen eines Neustarts der überwachten VM anders abzuwickeln als die Nutzung einer zusätzlichen vNIC durch den Kunden.

Diese Phase existiert in klassischen Modellen ebenfalls nicht, da hier keine automatisierten Än- derungen benötigt wurden. Notwendige Adaptionen konnten manuell durchgeführt werden, so dass die Aufgaben nicht gesondert in einer separaten Phase aufgeführt werden mussten.

6.2.7 Speicherung

Die Phase der Speicherung entspricht größtenteils der gleichnamigen Phase in klassischen Mo- dellen. Durch die Virtualisierung entstehen jedoch zwei mögliche Speicherkonzepte:

• Speicherung auf einem zentralen, physischen Aufzeichnungsserver

• Speicherung auf einem virtuellen Aufzeichnungssystem

Die nachfolgende Analyse verlangt eine konsistente Aufzeichnung der angefallenen Daten, daher sind die gesamten Netzwerkpakete persistent abzulegen und nicht ausschließlich im Speicher vorzuhalten. Die Nutzung eines zentralen physischen Aufzeichnungssystems bietet den Vorteil, dass nach Abschluss der Aufzeichnung die dort verbauten Festplatten entnommen und direkt

137 6 Entwicklung eines angepassten Vorgehensmodells für die Analyse genutzt werden können. Hierfür ist es jedoch notwendig, die Aufzeichnung so anzupassen, dass die Daten immer an dieses statische System übertragen werden.

Demgegenüber steht die Speicherung der Daten auf einer VM, die parallel zur Ziel-VM im Netzwerk betrieben wird. Auch diese speichert die anfallenden Daten auf einer Festplatte, die dabei jedoch vom CN bereitgestellt wird. Eine Entnahme dieser Festplatte nach Abschluss der Aufzeichnung entfällt also, sodass am Ende der Aufzeichnung die Daten in einem weiteren Schritt aus der virtuellen Umgebung extrahiert werden müssen. Dies wird jedoch durch den Vorteil aufgewogen, dass die anfallenden Daten nicht dauerhaft an das statische Aufzeichnungssystem kopiert werden müssen, sondern ﬂexibel an die Aufzeichnungs-VM geleitet werden können.

Sofern die Ziel-VM migriert wird, kann die Aufzeichnungs-VM ebenfalls migriert werden. Durch Nutzung von Snaphots oder einer dynamischen Einbindung zusätzlicher Festplatten ist es weiterhin möglich, den Migrationsaufwand für die Aufzeichnungs-VM gering zu halten. Sollte diese ebenfalls migriert werden, kann die virtuelle Festplatte getrennt, die Migration ohne den Daten- bereich durchgeführt und nach Abschluss der Migration eine neue virtuelle Festplatte verbunden werden. Der Inhalt der abgetrennten virtuellen Festplatte kann somit parallel zur laufenden Spei- cherung bereits analysiert und weiter verarbeitet werden.

6.2.8 Analyse

Diese Phase wird erreicht, wenn der gesamte Aufzeichnungsprozess manuell durch den Forensiker beendet wurde. Die Phase der Analyse erfüllt die gleichen Aufgaben wie in klassischen Modellen:

• Aufbereitung der aufgezeichneten Daten

• Extraktion von übertragenen Informationen

• Identiﬁkation der Kommunikationspartner

In der Phase der Analyse entstehen aufgrund der gestiegenen Komplexität jedoch noch weitere Teilaufgaben, die nicht in klassischen Modellen abgedeckt waren.

Obwohl die optimale Aufzeichnungsposition direkt an der vNIC ist, kann es aus unterschiedlichen Gründen möglich sein, dass kein Zugriff auf diese Position möglich ist. Dies kann der Fall sein, wenn keine Implementierung für den Zugriff auf die vNICs bereitgestellt werden kann oder der Zugriff auf den involvierten CN nicht möglich ist. Sofern keine Aufzeichnung an der vNIC möglich ist, verändert sich die Art der aufgezeichneten Daten, da nun die zusätzlichen Overlay-Protokolle mit in den gespeicherten Daten vorkommen. Die unmittelbare Extraktion der übertragenen Daten ist somit nicht mehr möglich, so dass zuerst die getunnelten Netzwerkdaten von den vorange-

138 6.3 Zusammenfassung stellten Headern getrennt werden müssen. Darüber hinaus kann es aufgrund der getunnelten Übertragungswege und unterschiedlicher Parameter zu einer veränderten Fragmentierung der Pakete kommen, so dass die aufgezeichneten Pakete erst wieder zusammengebaut werden müs- sen. Erst anschließend können bewährte Analysewerkzeuge und -methoden der Netzwerkforensik eingesetzt werden.

6.3 Zusammenfassung

In diesem Kapitel wurden unterschiedliche Vorgehensmodelle, die Richtlinien und Empfehlungen für die Durchführung forensischer Untersuchungen bieten, beschrieben und hinsichtlich ihrer Eignung für Arbeiten in virtuellen Netzwerken untersucht.

Die dabei analysierten Modelle DFRWS und BSI eignen sich, obwohl nicht originär hierfür entwickelt, auch für den Einsatz in der Netzwerkforensik, da hier allgemeine Vorgehen beschrieben werden, die auch für die Arbeiten in Netzwerken gültig sind. Das speziell für diesen Zweck entwickelte GNFP bietet detailliertere Deﬁnitionen relevanter Phasen und stellt ein Standardmodell der klassischen Netzwerkforensik dar.

Dennoch erfüllt keines der untersuchten Modelle die Anforderungen aus Kapitel 5, deren Be- achtung für die korrekte Durchführung forensischer Arbeiten in virtuellen Netzwerken elementar ist. Ursächlich hierfür ist die statische Implementierung der traditionellen Netzwerke, die sich ebenfalls in den untersuchten Modellen widerspiegelt. Diese oﬀerieren meist eine sequentielle Ab- arbeitung ohne die wiederholte Nutzung benötigter Phasen. Das GNFP beschreibt grundsätzlich einen möglichen Kreislauf, allerdings nur im Bereich der Untersuchung. Die vorab durchgeführten Phasen der Detection und Collection sind sequentiell und ohne Wiederholung deﬁniert. Dabei ist gerade hier eine Wiederholung der Phasen notwendig, um der Flexibilität und Dynamik im virtuellen Netzwerk gerecht zu werden.

Neben der fehlenden Wiederholung der einzelnen Phasen bieten die untersuchten Modelle keine Ansätze zur Überwachung der Umgebung. Dies ist nachvollziehbar, da die Überwachung und Anpassung einmal eingerichteter Aufzeichnungsprozesse in traditionellen Netzwerken nicht notwendig ist. Virtuelle Umgebungen verlangen jedoch eine ﬂexiblere Umsetzung des gesamten Prozesses.

Daher wurde in diesem Kapitel das Modell des VNFP entwickelt, welches die Schwächen klassischer Modelle beseitigt und somit eine Richtlinie für die Durchführung netzwerkforensischer Arbeiten in virtuellen Umgebungen bietet. Neben bewährten Phasen, die auch in klassischen Modellen existieren, sind mit den Bereichen der Überwachung, Bewertung und Adaption drei neue Phasen beschrieben worden, die die Flexibilität der virtuellen Netzwerke abdecken. Die

139 6 Entwicklung eines angepassten Vorgehensmodells

Trennung zwischen diesen Phasen ermöglicht darüber hinaus die Anpassung an lokale Gegeben- heiten, während bereits funktionierende Unteraufgaben nicht geändert werden müssen.

Durch die Implementierung der Überwachung sind Änderungen im Netzwerk erkennbar, die Nut- zung wiederholender Phasen ermöglicht die korrekte Verarbeitung dieser Änderungen

Tabelle 6.1 vergleicht die Modelle des DFRWS, BSI und das GNFP sowie das VNFP mit den Anforderungen aus Kapitel 5.

Tabelle 6.1: Vergleich der Vorgehensmodelle mit den Anforderungen Phase DFRWS BSI GNFP VNFP Identiﬁkation * * * * Vorbereitung * * * * Überwachung * Bewertung * Adaption * Aufzeichnung * * * * Speicherung * * * * Analyse * * * *

Da keines der bekannten Modelle sämtliche Anforderungen erfüllt, ist das VNFP das einzige geeignete Modell für die Netzwerkforensik in virtuellen Umgebungen.

In den nächsten Kapiteln erfolgt aufbauend auf dem VNFP eine Analyse unterschiedlicher Ar- chitekturen virtueller Netzwerke. In Kapitel 7 werden singuläre vSwitch-Instanzen auf Basis von Open vSwitch analysiert, die VMs ohne Migration an ein Netzwerk anbinden. Im Kapitel 8 wird eine Lösung beschrieben, die eine netzwerkforensische Untersuchung in hochdynamischen Umgebungen auf Basis des OpenFlow-Protokolls ermöglicht.

140 7 Open vSwitch-Forensik

Die Wichtigkeit eines vSwitches unterscheidet sich nicht von der Wichtigkeit hardwarebasierter Switche. Diese sind in Netzwerken für den Transport der Pakete zuständig und werden daher in der Netzwerkforensik genutzt, um relevante Daten zu spiegeln und an ein Auswertesystem weiterzuleiten. Die gleichen Aufgaben sind auch im virtuellen Umfeld gefordert.

In diesem Kapitel wird daher mit OVS analysiert, welche Möglichkeiten vSwitche in der netzwerkforensischen Arbeit bieten. Dies betriﬀt die Techniken zur Datenspiegelung und Weiterleitung an ein Auswertesystem. Mit Hilfe einer Testumgebung wird ermittelt, in welcher Form die unterschiedlichen Gegebenheiten der virtuellen Umgebung die Netzwerkforensik erschweren, um dann auf Basis der Phasen des VNFP Lösungen darzustellen.

Dies umfasst neben der Identiﬁzierung der relevanten Ports auch die Implementierung der Über- wachung, die Spiegelung der Daten und die korrekte Reaktion auf Veränderungen innerhalb der Umgebung. Dabei ist es das Ziel, den Datenverkehr einer Ziel-VM41 vollständig und dauerhaft an das Aufzeichnungssystem42 zu übermitteln.

Im ersten Teil werden anhand von theoretischen Vorüberlegungen existente Möglichkeiten zur Extraktion von Informationen und der Paketspiegelung analysiert. Anschließend wird der Aufbau der Testumgebung beschrieben, einschließlich der verwendeten Komponenten. Darauf aufbauend werden mögliche Implementierungen zu den einzelnen Phasen des VNFP untersucht.

Als Ergebnis dieser Analyse wird mit OVSF eine Lösung vorgestellt, die als Proof-of-Concept (PoC) die grundlegende Funktionsfähigkeit nachweist. Es gilt dabei die Einschränkung, dass die Migration einer VM nicht überwacht wird. Die Implementierung des Überwachungsprozesses zielt einzig auf die Erkennung des Startens und Stoppens der VMt ab. Eine Lösung, die auch Migration berücksichtigt, wird im folgenden Kapitel 8 über OpenFlow-Forensik vorgestellt.

41 Im Folgenden als VMt bezeichnet. 42 Im Folgenden als VMa bezeichnet.

141 7 Open vSwitch-Forensik

7.1 Vorüberlegung

Bisher eingesetzte, klassische Werkzeuge der Netzwerkforensik sind in virtuellen Infrastrukturen nutzlos, da die hardwarebasierten Techniken in einem vollständig in Software abgebildeten Umfeld nicht einsetzbar sind. Aber genau diese Umgebungen ﬁnden sich immer häuﬁger in Unternehmen, Kommunen und Einrichtungen, um die dortige IT optimiert einsetzen zu können. Durch die Nutzung kostenloser Softwareumgebungen43 oder der Nutzung von Open Source ist es auch in kleinen Umgebungen möglich, auf einer geringen Anzahl von physischen Servern viele virtuelle Systeme zu betreiben. Auch hier kann es notwendig sein, gezielte Untersuchungen durchzuführen, bei denen traditionelle Werkzeuge nicht eingesetzt werden können und die daher einen neuen Ansatz benötigen.

Bevor eine reale Implementierung als PoC bereitgestellt werden kann, erfolgt die Analyse geeigneter Zugriﬀsmöglichkeiten auf die gespeicherten Daten und die Klassiﬁzierung möglicher Datenausleitungsfunktionen. Die möglichen Implementierungen virtueller Netzwerke sind zahlreich und von einer Vielzahl unterschiedlichster Faktoren abhängig. Dennoch sind grundsätzliche Vernetzungstechniken bekannt, die im Folgenden untersucht werden. Die drei Techniken

• Plain,

• VLAN,

• VXLAN stellen wesentliche Vernetzungstechniken innerhalb virtueller Umgebungen dar und bilden gleichzeitig die Basis für weitere Umsetzungen. Diese Umsetzungen werden hinsichtlich relevanter Parameter untersucht, die eine Aufzeichnung der Daten erschweren können.

Plain-Implementierungen verzichten vollkommen auf die Nutzung virtueller Ansätze und stellen eine reine Layer 2-Anbindung bereit. VLAN-basierte Netzwerke bilden den Einstieg in die virtuellen Umgebungen, problematische Limitierungen wurden in Kapitel 2.3.1 beschrieben. Ansätze der VXLAN-Implementierung lassen sich aufgrund der ähnlichen Konﬁgurationsparameter auch auf GRE-Tunnel und somit auch auf NVGRE und GENEVE übertragen [SSKW16], [PH15], welche daher nicht separat aufgeführt werden.

43So stellt die Firma VMWare mit VMWare ESXi einen Hypervisor für Bare-Metal-Umgebungen kostenlos zur Verfügung.

142 7.1 Vorüberlegung

7.1.1 Entwicklungsbasis geeigneter Werkzeuge

Die Extraktion, Manipulation und Überwachung der laufenden OVS-Instanz kann auf unterschiedliche Arten erfolgen. Dabei sind sämtliche relevanten Daten für den Betrieb von OVS in der OVSDB gespeichert. [PBD13] beschreibt zwei grundlegende Wege, um diese Daten abzufragen. Wrappertools bieten einen High-Level-Zugriﬀ auf die gespeicherten Daten innerhalb der OVSDB, der direkte Zugriﬀ auf die Datenbank kann mit Hilfe des OVSDB-Management-Protokolls erfolgen. Beide Techniken werden im Folgenden vorgestellt und hinsichtlich ihrer Eignung für netzwerkforensische Untersuchungen untersucht.

7.1.1.1 Wrapper

OVS bietet zur Abfrage der Daten unterschiedliche Programme an. Diese kapseln die Anfragen an die OVSDB und ermöglichen so einen Datenaustausch ohne genaue Kenntnis der Datenbank. Das Zusammenspiel einiger der Programme wurde in Abbildung 2.19 dargestellt.

• ovs-vsctl Der Dienst ovs-vswitchd steuert und kontrolliert sämtliche OVS-Instanzen auf einem Sys- tem. Diese Daten können über das Programm ovs-vsctl, welches eine High-Level Schnitt- stelle zur Datenbank bereitstellt, abgefragt und geändert werden.

• ovs-appctl Während das Programm ovs-vsctl nur die einzelnen OVS-Instanzen, die auf dem Sys- tem laufen, manipulieren kann, ermöglicht das Programm ovs-appctl darüber hinaus die Manipulation des Dienstes direkt. Hierüber ist es somit möglich, das Logging sämtlicher OVS-Instanzen zu ändern, ohne jede Instanz eigenständig abzufragen.

• ovsdb-client Die Daten über die laufenden OVS-Instanzen auf einem System werden in der OVSDB gespeichert. Diese Datenbank beinhaltet alle Informationen, die für den Betrieb der vSwitche notwendig sind. Eine Abfrage und Änderung der gespeicherten Daten ist mit dem Pro- gramm ovsdb-client möglich. Einträge, die mit Hilfe des Programms ovsdb-client durch- geführt werden, haben unmittelbare Auswirkungen auf die laufenden Instanzen. Demge- genüber steht das Werkzeug ovsdb-tool, welches die Steuerung der OVSDB ohne direkte Interaktion mit den laufenden Instanzen bietet.

• ovs-ofctl Das Programm ovs-ofctl ermöglicht die Steuerung und Konﬁguration der OVS-Instanz als OpenFlow-Switch.

143 7 Open vSwitch-Forensik

• ovs-dpctl Die Weiterleitung der Pakete erfolgt in einem Kernelmodul, um die Abarbeitung der Daten möglichst performant durchführen zu können. Die aktuell gültigen Daten, die das Kernel- modul für die Weiterleitung benötigt, können mit dem Programm ovs-dpctl abgefragt und manipuliert werden.

7.1.1.2 OVSDB Management Protocol

Das OVSDB Management Protocol [PBD13] stellt mit einer API eine Schnittstelle zur Ad- ministration und Konﬁguration der OVSDB über JavaScript Object Notation (JSON)-Remote Procedure Call (RPC) zur Verfügung. JSON bezeichnet ein Format zum Austausch von Daten zwischen Systemen und Anwendungen. JSON ist in RFC 7159 [Bra14] standardisiert und zeichnet sich durch einen geringeren Overhead und leichtere Lesbarkeit gegenüber XML aus.

Die genutzten JSON-RPCs arbeiten mit Requests und dazu gehörigen Responses, die einen gleichen Aufbau besitzen. Ein Request besteht aus den folgenden drei Teilen:

• method Name der Funktion, die aufgerufen werden soll

• id Eindeutige ID, die zur Zuordnung zwischen Request und Response genutzt werden kann

• param Array von Parametern, die an die Funktion übergeben werden

Die dazugehörige Antwort besteht ebenfalls aus drei Teilen:

• result Objekt mit den Ergebnissen

• id Gleicher Wert wie im Request, um die Antwort zuordnen zu können

• error Objekt mit aufgetretenen Fehlern

OVS bietet mit dem OVSDB-Management-Protokoll eine Schnittstelle zur Kommunikation mit der OVSDB, die einen ﬂexibleren Zugriﬀ auf die Datenbank als die Wrappertools bieten [PBD13]. Dabei unterstützt OVSDB mehrere RPC-Methoden, von denen jedoch nicht alle für forensische

144 7.1 Vorüberlegung

Zwecke relevant sind. Tabelle 7.1 listet die Methoden mit ihrem Einsatzzweck und der forensischen Relevanz auf.

Tabelle 7.1: OVSDB-Management Protokoll Methode Zweck Relevanz list_dbs AuﬂistungdererreichbarenDatenbanken gering get_schema Übertragung des angeforderten Datenbankschemas gering transact AuftragzurAusführungübermittelterKommandos mittel cancel Abbruchder transact-Methode mittel monitor Der Client erhält ein Replikat der OVSDB oder Teilen davon hoch update Aktualisierungen, die vom Server zum Client gesendet werden hoch monitor_cancel BeendetdenMonitoring-Prozess hoch lock BefehlanOVSDB,umeineSperrezuerzwingen gering locked Benachrichtigung über erfolgreichen oder fehlgeschlagenen gering lock-Befehl stolen Benachrichtigung über einen durch einen anderen Client an- gering geforderten lock-Befehl echo SicherstellungderVerfügbarkeit gering

Der unmittelbare Zugriﬀ auf die OVSDB ist jedoch nicht möglich, erst die Aktivierung wie in Listing 7.1 aufgeführt ermöglicht die Abfrage der OVSDB per Remotezugriﬀ.

Listing 7.1: Aktivierung des Remotezugriﬀs auf OVSDB ovs−appctl −t ovsdb−server ovsdb−server/add−remote ptcp:6632

Durch die Nutzung des Monitor-RPCs erhält der Client den Zugriﬀ auf die zu überwachenden Tabellen und wird bei Nutzung des Update-RPCs über sämtliche Änderungen der überwachten Tabelle informiert. Verbindet sich somit ein OVSDB-fähiger Client mit der OVSDB und fordert die Updates über Änderungen der Datenbank an, erhält dieser die Informationen sofort nachdem sie in der Datenbank eingetragen wurden.

7.1.1.3 Eigenentwicklung

Die benötigten Daten werden an unterschiedlichen Stellen in der OVSDB gespeichert, deren Struktur theoretisch durch Aktualisierungen oder Patches geändert werden kann [PBD13]. Wäh- rend die parallel bereitgestellten Werkzeuge die Änderung der Struktur kennen, wären eigene Programme, die diese Datenbank anfragen, jedes Mal zu aktualisieren. Dabei sind Arbeitstech- niken des Reverse Engineerings notwendig, da nicht alle Änderungen unmittelbar bekannt sind, sondern unter Umständen mühsam analysiert werden müssen [CC90]. Aufgrund dieser Unsicher- heit ist eine vollständige Eigenentwicklung nicht zielführend.

145 7 Open vSwitch-Forensik

7.1.1.4 Ausgewählte Zugriﬀstechnik

Alle drei Zugriﬀsmethoden sind nicht unmittelbar für die Netzwerkforensik geeignet, so dass nur die Kombination der vorhandenen Möglichkeiten bleibt, um die erforderlichen Daten zu ermitteln. Für die zeitnahe Information über Änderungen der laufenden Instanz ist die Nutzung des OVSDB-Management-Protokolls zielführend. Hier sichern die Monitor- und die Update- Methode die korrekte und zeitnahe Übermittlung der aufgetretenen Änderungen.

Die weitere Verarbeitung der notwendigen Schritte wie Ermittlung der vNIC der VMt sowie die Einrichtung des Mirrorports erfolgt über die Wrappertools, die eine schnellere und eindeutigere Manipulation der Tabellen ermöglichen. Die Kombination dieser Umsetzung muss als eigene Entwicklung durchgeführt werden.

Diese Kombination aus fertigen Wrappertools, die die Anbindung an die zentrale Datenbank realisieren und einer Eigenentwicklung zur Implementierung der forensischen Aufgaben bietet die beste Möglichkeit. Hierdurch werden zeitaufwändige Reverse-Engineering Maßnahmen unnötig, da die Schnittstellen durch die Entwickler von OVS angepasst werden.

7.1.2 Datenausleitung

Die Ausleitung der Daten der VMt zur VMa hat das Ziel, sämtliche Daten der VMt aufzuzeichnen.

Die Anbindung der VMt ist dabei vorbestimmt, somit werden zunächst die möglichen Ansätze der Anbindung der VMa und des Mirrorports geprüft. Abschnitt 2.6.2 beschreibt unterschiedliche Techniken zur Datenaufzeichnung in netzwerkforensischen Untersuchungen. Dabei sind, wie in Abschnitt 4.4.2 beschrieben, hardwarebasierte Techniken in virtuellen Umgebungen nutzlos, so dass softwarebasierte Techniken genutzt werden müssen.

Die Firmen Veryx mit dem Veryx vTAP [Ver17] oder Ixia mit der Software Phantom vTAP [ixi17] bieten erste Implementierungen für virtuelle TAPs an, allerdings benötigen diese trotz einer vorhandenen Cloud-Integration immer noch Installationen in den virtuellen Umgebungen. Hier- durch sind durch Seiteneﬀekte Schwierigkeiten bei der Aufzeichnung möglich. Einzelne vSwitch- Instanzen sind damit ebenfalls nicht zu überwachen.

[PHRF16] präferiert die Nutzung von Inline-TAPs, da diese im Vergleich zu Mirrorports weniger Probleme wie Protokollinkompatibilität oder Datenverlust aufweisen. Demgegenüber seien Mirrorports jedoch einfacher bereit zu stellen.

Durch die geeignete Wahl der Aufzeichnungsposition ist es möglich, sämtliche Protokollinkom- patibilitäten zu verhindern, die ﬂexiblere Nutzung gegenüber TAPs spricht somit deutlich für die

146 7.1 Vorüberlegung

Nutzung der Mirrorfunktionalität in vSwitchen. OVS bietet standardmäßig die Implementierung von Mirrorports, so dass im Folgenden noch die Form der Anbindung an das Aufzeichnungssystem entwickelt werden muss.

Für eine geeignete Anbindung der VMa bestehen wie in der klassischen Netzwerkforensik unterschiedliche Möglichkeiten:

• Direkte Verbindung der VMa mit den jeweiligen Mirrorports

Bei dieser Implementierung muss die VMa mit einer vNIC auf dem betroﬀenen vSwitch angeschlossen sein.

• Nutzung eines übergeordneten vSwitches

Bei dieser Umsetzung reicht auf der VMa eine vNIC, dafür wird ein zusätzlicher vSwitch benötigt, der die jeweiligen Mirrorports anbindet.

• Nutzung einer parallelen vSwitch-Instanz Hierbei wird an frei gewählter Stelle im Netzwerk ein vSwitch bereitgestellt, der über Tunneltechniken mit dem jeweiligen vSwitch verbunden wird.

7.1.2.1 Direkte Anbindung

Bei dieser Anbindung handelt es sich um die Technik, die auch in klassischen Netzwerken typi- scherweise genutzt wird. In diesen Umgebungen steht ein Switch mehreren Kunden zur Verfü- gung, in virtuellen Umgebungen besteht die Hauptimplementierung der vSwitche jedoch darin, jedem Kunden einen eigenen vSwitch zur Verfügung zu stellen, auch wenn hier zu Beginn nur eine einzige VM betrieben wird. Bei Erweiterung mit weiteren VMs ist es jedoch so ohne großen Aufwand möglich, die Vernetzung anzupassen, ohne laufende Systeme zu stören. Die Nutzung eines Mirrorports auf einem vSwitch erfasst somit mit hoher Wahrscheinlichkeit ausschließlich relevante Daten des zu überwachenden Systems.

Eine direkte Anbindung der VMa hat zudem den Vorteil, dass die relevanten Netzwerkdaten nicht außerhalb dieser vSwitch-Instanz auftreten und somit keine Auswirkungen auf die Gesamtnetzlast haben.

7.1.2.2 Elterninstanz

Eine weitere Möglichkeit der Vernetzung bieten direkt verbundene OVS-Instanzen, welche als übergeordnete Switchinstanz arbeiten. Die übergeordnete Instanz wird im Folgenden daher als Elterninstanz bezeichnet. Dieser Ansatz hat den Vorteil, dass die Beschränkung der maximal

147 7 Open vSwitch-Forensik

installierten vNICs pro VMa nicht relevant ist, da diese nur noch die Anbindung an die Elternin- stanz benötigt. Dabei ist die VMa an der Elterninstanz angeschlossen, über geeignete Methoden muss nun sichergestellt werden, dass

• die Anbindung schnell und stabil verfügbar ist

• die Ausleitung der Daten dauerhaft funktioniert.

Abbildung 7.1 zeigt den exemplarischen Aufbau einer solchen übergeordneten Instanz.

VM a

brmon

s1 s2

VM t

Abbildung 7.1: Übergeordnete Elterninstanz

Die Verbindung zwischen zwei benachbarter OVS-Instanzen ist mit unterschiedlichen Techniken möglich; da es sich bei den vSwitchen um virtuelle Instanzen handelt, muss auch diese Verbindung mit Hilfe virtueller Interfaces erfolgen.

Nach [Ope15] stehen fünf mögliche Implementierungen bereit, die sich hinsichtlich ihrer Leis- tungsfähigkeit und somit auch hinsichtlich der Eignung für forensische Arbeiten unterscheiden.

• tap Implementiert ein vNIC auf Layer 2, und ist die häuﬁgste Bereitstellung für die Anbindung einer VM an einen vSwitch. Eine Verbindung zwischen zwei tap-Interfaces in unterschiedlichen Namespaces ist jedoch nicht möglich.

148 7.1 Vorüberlegung

• tun Implementiert eine vNIC auf Layer 3. Auch hier ist die Nutzung von Namespaces nicht möglich.

• parent bridge OVS bietet die Option, mit Hilfe übergeordneter OVS-Instanzen Datenverkehr zusammenzufassen. Diese Option wird als parent bridge bezeichnet. Allerdings müssen diese Bridges bereits bei der Instanziierung mit der Parentbridge gestartet werden. Eine nachträgliche Konﬁguration ist nicht möglich.

• veth Veth-Interfaces bestehen aus einem Paar von vNICs, die direkt miteinander verbunden sind. Daten, die an einem veth-Interface ankommen, werden zum Partnerinterface weitergeleitet. Allerdings bieten diese Interfaces keine stabile Mirrorfunktionalität [Xan16].

• patch port OVS nutzt zur Verbindung zweier vSwitche gesondert implementierte patch ports, die jedoch keine Möglichkeit bieten, um eine Mirrorfunktionalität anzubinden, da diese Ports lokal auf einen Hypervisor beschränkt sind [Pet17].

Tabelle 7.2 fasst die Implementierungen zusammen und listet die Eignung für forensische Unter- suchungen auf.

Tabelle 7.2: Eignung virtueller Interfaces zur Anbindung an eine Elterninstanz vNIC Nutzbar tap * tun parent bridge * veth patch port

Durch die Nutzung einer aggregierenden Elterninstanz entsteht jedoch eine vergrößerte Layer 2 Broadcastdomäne, sodass sämtlicher Broadcastverkehr, der eigentlich lokal auf den entsprechenden vSwitch begrenzt war, nun auf allen anderen, mit der Elterninstanz verbundenen, vSwitchen sichtbar ist. Neben diesem Datenverkehr steigt mit einer solchen Implementierung auch das An- griffsrisiko innerhalb der virtuellen Umgebung. Mögliche Angriffstechniken innerhalb einer Layer 2-Umgebungen finden sich in [BH96], [AKO+05] und [Bha07]. Diese Sicherheitsrisiken verhindern die Umsetzung für forensische Zwecke.

Zur Absicherung dieser Layer 2-Umgebungen werden in klassischen Netzwerken häuﬁg Firewall- systeme eingesetzt, die den ein- und ausgehenden Datenverkehr ﬁltern. Die Nutzung einer Firewall

149 7 Open vSwitch-Forensik ist jedoch nicht möglich, da OVS keine direkte Interaktion mit Firewallimplementierungen wie iptables oder ebtables bietet. Mögliche Lösungen basieren auf einer zusätzlichen Anbindung über eine Linuxbridge, um eine Filterung vorzunehmen [Mai13].

7.1.2.3 Parallelinstanz

Neben der direkten Anbindung einer separaten OVS-Instanz besteht zusätzlich eine Anbindung über GRE oder VXLAN-Tunnel. In diesem Szenario entsteht keine direkte Verbindung zwischen den beiden Instanzen, so dass die Parallelinstanz theoretisch an jeder beliebigen Stelle im Netz- werk installiert werden kann.

Abbildung 7.2 zeigt den Aufbau exemplarisch:

s1 VXLAN / GRE brmon

VM a VM t

Abbildung 7.2: Parallele vSwitch-Instanz

Nachteilig an dieser Implementierung ist die Notwendigkeit, nun sämtliche aufzuzeichnende Daten innerhalb des physischen Netzwerks über mehrere Verbindungen zu transportieren. In Abhängigkeit von der Positionierung der Parallelinstanz kann hierdurch die Netzlast stark an- steigen. Moderne Rechenzentren betreiben einen hohen Aufwand zur Netzlastminimierung und -verteilung [ANMANAJ12]. Forensische Untersuchungen, die die Netzlast weiter steigern, sind daher ungeeignet.

7.1.2.4 Gewählte Ausleitungstechnik

Die beschriebenen Techniken zur Ausleitung des Datenverkehrs erfüllen alle eine grundsätzliche Mirrorfunktionalität. Dennoch unterscheiden sich die drei beschriebenen Methoden hinsichtlich ihrer tatsächlichen Eignung. Tabelle 7.3 fasst die Vor- und Nachteile der unterschiedlichen Im- plementierungen zusammen.

150 7.1 Vorüberlegung

Tabelle 7.3: Vergleich der Datenausleitungsmöglichkeiten Umsetzung Vorteile Nachteile keine zusätzlichen vSwitch- hoher Migrationsaufwand Direkt Instanzen notwendig keine Netzwerkbelastung außer- halb des vSwitches keine geeignete Mirrorportanbin- Eltern Geringer Migrationsaufwand dung möglich Vergrößerung der Layer 2- Broadcastdomäne Geringer Migrationsaufwand zusätzlicher Tunnel notwendig Parallel Flexibler Installationsort erhöhte Netzlast

Die direkte Anbindung der VMa an der vSwitch-Instanz der VMt bietet die meisten Vorteile für das Szenario. Dies entspricht der Technik, die auch in klassischen Netzwerken eingesetzt wird. Für den Fall einer Migration ist diese Lösung grundsätzlich nicht geeignet, aber durch die im nächsten Kapitel vorgestellte Lösung ist eine einfachere Überwachung der gesamten Umgebung möglich, so dass die direkte Anbindung präferiert wird.

Die Nutzung einer Elterninstanz ist nicht geeignet, da die Anbindung bereits bei der Einrichtung des vSwitches zu konﬁgurieren ist. Da das Entfernen und Neueinrichten des betroﬀenen vSwitches im Rahmen der forensischen Arbeit nicht möglich ist, scheidet die Nutzung einer Elterninstanz aus.

Auch die Nutzung einer parallelen vSwitch-Instanz, die an frei wählbarer Stelle im Netzwerk bereitgestellt und über VXLAN- oder GRE-Tunnel angebunden wird, scheidet aus. Der bei dieser Implementierung zusätzlich zu übertragene Datenverkehr erhöht die Netzlast je nach Situation nicht unerheblich, so dass diese Lösung nicht genutzt werden sollte. Andere Techniken bieten eine bessere Auslastung der Netzwerkverbindungen und sind damit besser geeignet.

7.1.3 Technik zur forensischen Nutzung virtueller Switche

In diesem Abschnitt wurde auf Basis vorhandener Arbeiten sowie Untersuchungen ermittelt, welche Methode für die Ausleitung relevanter Netzwerkdaten am besten geeignet ist. Dabei ist bereits die Identiﬁzierung und die Extraktion relevanter Informationen nicht trivial, da unterschiedliche Möglichkeiten existieren. Diese Möglichkeiten wurden analysiert, aufgrund der möglichen Schwierigkeiten bei der Nutzung und den fehlenden forensischen Ansätzen ist eine Kombination aus Eigenentwicklung und vorhandener Tools unumgänglich.

151 7 Open vSwitch-Forensik

Für forensischen Untersuchungen existieren, wie in Kapitel 5 beschrieben, unterschiedliche Anfor- derungen. In der US-amerikanischen Rechtssprechung existiert der sogenannte Daubert-Standard, der ähnlich der Akzeptanz aus Abschnitt 5.1 angewandt wird und auch in IT-forensischen Un- tersuchungen Anwendung ﬁndet [Car02]. Durch die Nutzung vorhandener Werkzeuge ist eine Analyse der eingesetzten Methoden einfacher möglich, als das dies durch vollständige Neuent- wicklungen möglich wäre.

Die Ausleitung der Daten basiert auf der Technik, die auch in klassischen Netzwerken angewandt wird. Die direkte Anbindung des Aufzeichnungssystems verringert die Gesamtnetzlast, wodurch das Problem des Load-Balancing in virtuellen Umgebungen vermindert werden kann [KEBZEK12].

Im folgenden Abschnitt werden die gewählten Techniken in einem Testumfeld auf ihre Eignung untersucht und gegebenenfalls angepasst.

7.2 Testaufbau

Im genutzten Testaufbau wird ein Linux-PC als Wirtssystem genutzt, darauf aufbauend wird KVM als Hypervisor eingesetzt. Das Wirtssystem, welches die VM beinhaltet, läuft unter Ubun- tu 14.04.3 LTS, die Gastsysteme werden mit Debian 8 als Aufzeichnungssystem und jeweils Ubuntu 14.04.3 LTS als Kommunikationssysteme eingesetzt. Der Aufbau der Testumgebung ist in Abbildung 7.3 dargestellt.

VM1 VM2 VM3

tap0 tap1

tap2 ! ¡

tap3

Mirror

Abbildung 7.3: Testaufbau Port-Mirror

152 7.3 Portidentiﬁzierung

Tabelle 7.4 listet die genutzten Systeme der Testumgebung sowie ihre MAC-Adressen IP-Konﬁguration und die jeweiligen Aufgaben auf. Zur Vereinfachung der Identiﬁzierung sind die MAC-Adressen händisch vergeben worden (vgl. Abschnitt 4.8).

Tabelle 7.4: Testumgebung Plain und VLAN Hostname IP-Adresse MAC-Adresse Aufgabe ubuntu 10.0.0.1/24 00:0c:29:c8:8f:6f Hosting der VM, Bereitstellung der OVS-Umgebung VM1 10.0.0.11/24 00:00:00:00:00:11 Kommunikationssystem1 VM2 10.0.0.12/24 00:00:00:00:00:22 Kommunikationssystem2 VM3 10.0.0.13/24 00:00:00:00:00:33 Kontroll-VM zur Sicherstellung der korrekten Konﬁguration Mirror 10.0.0.20/24 00:00:00:00:00:99 Aufzeichnung der gespiegelten Netz- werkdaten

7.3 Portidentiﬁzierung

Bevor die Spiegelung der Daten erfolgen kann, muss wie in der klassischen Netzwerkforensik der korrekte Port, an dem das Zielsystem angeschlossen ist, ermittelt werden. Im virtuellen Umfeld handelt es sich dabei um einen vPort, der nicht unmittelbar ersichtlich ist.

Eine Identifzierung benötigt daher andere Techniken, um den korrekten vPort zu ermitteln. [Mot16] beschreibt die Möglichkeit, Details aus der Beschreibung der VM zu extrahieren. Dieser Ansatz ist jedoch auf Informationen des Hypervisor ausgelegt und bietet daher nur eingeschränk- te Möglichkeiten. Die Vielfalt der möglichen Hypervisoren verhindert eine schnelle Nutzung, da zuerst die entsprechenden Parameter, die in Abhängigkeit vom Hypervisor an unterschiedlichen Stellen und verschiedenen Formaten gespeichert werden, extrahiert werden müssen.

Ziel ist daher die Implementierung einer vom eingesetzten Hypervisor unabhängigen Möglich- keit zur Identifizierung. Hierfür können die bereits bekannten Parameter genutzt werden, die im Rahmen der Überwachung bekannt sind. Zum einen ist die initiale Einrichtung der Aufzeichnung anhand der MAC-Adresse möglich, zum anderen kann die Ersteinrichtung über den Interfacen- amen erfolgen. Die interne Verarbeitung der Ports erfolgt bei OVS, losgelöst von Interfacena- men, anhand einer eindeutigen Universally Unique Identifier (UUID), die einen Port identifiziert [Ope15]:

Either a universally unique identiﬁer in the style of RFC 4122, e. g. f81d4fae-7dec- 11d0-a765-00a0c91e6bf6, or an @name deﬁned by a get or create command within the same ovs-vsctl invocation.

153 7 Open vSwitch-Forensik

Dabei ändern sich die UUIDs, sofern das angeschlossene System heruntergefahren und neu ge/- startet wird, da hierbei eine neue vNIC erstellt wird. Die Anbindung an den vSwitch wird zu- sätzlich durch eine interne OpenFlow-Portnummer realisiert, die dem Interface eine eindeutige Nummer zuordnet. Diese Nummern sind ebenfalls dynamisch, durch Anpassung des Quellcodes wäre eine Nutzung statischer Namen möglich, allerdings ist eine Modiﬁkation zur Laufzeit nicht möglich [Pet16].

Die Ermittlung der angeschlossenen Geräte inklusive Interfacename und UUID kann, wie im Abschnitt 7.1.1 beschrieben, über unterschiedliche Verfahren durchgeführt werden. Durch Ex- traktion relevanter Informationen der OVSDB kann eine Portidentiﬁzierung zielgerichtet und hypervisorunabhängig durchgeführt werden.

Eine Übersicht über die angeschlossenen Geräte kann mit dem Programm ovs-vsctl und dem Parameter show, wie in Listing 7.2 dargestellt, erreicht werden. Dabei werden alle auf dem System laufenden OVS-Instanzen mit den angeschlossenen vPorts aufgeführt.

Listing 7.2: Ermittlung angeschlossener vPorts ovs−vsctl show 76c944ad−6d3a−4c14 −83db−b6bb4db7f7cb Bridge "br0" Port "tap1" Interface "tap1" Port "eth0" Interface "eth0" Port "tap2" Interface "tap2" Port "br0" Interface "br0" type: internal ovs_version: "2.0.2"

Die UUIDs eines Ports können dabei mit Hilfe des Programms ovs-vsctl wie in Listing 7.3 aufgeführt, abgefragt werden.

Listing 7.3: Exemplarische Abfrage der UUID der vNIC tap3 ovs−vsctl get port tap3 _uuid 65277918−7847−4a7c−9fae −cda50ac859ad

154 7.3 Portidentiﬁzierung

7.3.1 Adressenbasiert

Diese Ausgabe liefert jedoch keinen Zusammenhang zur tatsächlichen Verbindung eines Ports zu einer VM. Die Zugehörigkeit zwischen Port und MAC-Adresse speichert vSwitch analog zu einem Hardwareswitch in der CAM-Tabelle, die bei OVS44 wie in Listing 7.4 abgefragt werden kann.

Listing 7.4: Abfrage der CAM-Table ovs−appctl fdb/show br0 p o rt VLAN MAC Age 1 0 00:50:56:eb:82:40 110 8 0 00:00:00:00:00:22 72 11 0 00:00:00:00:00:33 59 1 0 00:50:56:e9:3b:65 42 9 0 00:00:00:00:00:11 15 7 0 99:00:00:00:00:99 12 LOCAL 0 00:0c:29:c8:8f:6f 12 1 0 00:50:56:c0:00:08 5

Als Ergebnis erhält man die interne Portnummer am vSwitch, die VLAN-ID, die MAC-Adresse und die Dauer des Eintrags in der Tabelle dargestellt.

Die Zuordnung zwischen Interfacenamen und interner Portnummer lässt sich mit dem Programm ovs-ofctl, wie in Listing 7.5 dargestellt, abfragen.

Listing 7.5: Extraktion der MAC-Adressen ovs−ofctl show br0 | grep tap 7(tap0): addr:be:0e:25:4c:a3:c3 8(tap1): addr:3a:de:6a:89:33:8c 9(tap2): addr:da:cf:b0:53:a9:c1 11(tap3): addr:d6:86:35:b3:ea:54

Dabei bezieht sich die hier angeführte MAC-Adresse nicht auf das angeschlossene System, sondern auf die interne MAC-Adresse für den vPort am vSwitch. Eine Identiﬁzierung des vPorts der relevanten VM ist somit durch eine Kombination der vorgestellten Werkzeuge möglich.

Der Ansatz, anhand der MAC-Adresse den Port zu identiﬁzieren, ist von der Zielrichtung eindeutig auf die korrekte VM ausgerichtet. Die Eindeutigkeit der MAC, eventuell in Kombination mit einer VLAN-ID oder der VNI, ermöglicht eine geeignete Implementierung der Identiﬁzierung. 44Hier wird diese Tabelle als FDB bezeichnet.

155 7 Open vSwitch-Forensik

Allerdings weist dieses Verfahren eine Schwäche auf, die die initiale Einrichtung erschwert. Die Einträge in der CAM sind dynamisch und vom jeweiligen Timeout abhängig, läuft dieser Timeout ab, wird der Eintrag aus der CAM-Tabelle entfernt und eine Portidentiﬁzierung anhand der MAC- Adresse schlägt fehl.

7.3.2 Portbasiert

Die zeitlich beschränkte Gültigkeit des Eintrags einer MAC-Adresse in der CAM erschwert die initiale Einrichtung der Aufzeichnung. Erst wenn die zu überwachende VM Daten versendet, wird der Eintrag der MAC-Adresse und des Ports in der CAM-Tabelle gespeichert, so dass die Werte abgefragt werden können.

Da die Dauer der Nichtexistenz in der CAM-Tabelle unbestimmt ist, ist der im vorigen Abschnitt beschriebene Ansatz nicht vollständig umsetzbar, um eine valide Aufzeichnung zu implementieren. Aus diesem Grund erfolgt im Weiteren die Identiﬁzierung des Ports anhand des Interfa- cenamens. Von diesem Namen ausgehend werden in den weiteren Schritten zuerst die interne Portnummer und dann durch periodisches Analysieren die MAC-Adresse extrahiert.

Dabei werden die gleichen Programme wie im vorigen Abschnitt genutzt, diesmal jedoch in anderer Reihenfolge. Zuerst erfolgt wie in Listing 7.5 die Extraktion der internen Portnummern und der Interfacenamen. Da der Interfacename, mit dem die vNIC der VM mit dem vSwitch verbunden ist, bekannt ist, kann nun durch wiederholte Abfrage der CAM-Tabelle, wie in Listing 7.4 beschrieben, die MAC-Adresse an dem zugeordneten internen Port ermittelt werden.

Solange die MAC-Adresse nicht in der CAM-Tabelle gespeichert wird, kann die Aufzeichnung mit Hilfe des Interfacenamens durchgeführt werden, taucht die MAC-Adresse der Ziel-VM in der CAM-Tabelle auf, kann die Datenausleitung aktualisiert werden. So ist die Gültigkeit der Portidentiﬁzierung dauerhaft gegeben. Der Interfacename ist dabei nicht statisch an die VM gebunden, sondern kann sich, z.B. aufgrund eines Neustarts ändern.

Durch die beiden Möglichkeiten ist somit garantiert, dass jederzeit eine Identiﬁzierung des korrekten Ports möglich ist.

7.4 Mirrorport

Die Position der Datenaufzeichnung hat elementare Auswirkungen auf die sichtbaren und somit speicherbaren Daten. Wie in Kapitel 5 beschrieben, ist es zielführender, die Daten quellnah aufzuzeichnen und keine Uplinks oder Transitstrecken zu nutzen. Zum einen erhöht sich hierdurch

156 7.4 Mirrorport die aufzuzeichnende Datenmenge, zum anderen fehlt Datenverkehr, der auf dem Wirtssystem intern abgewickelt wird. Daher wird die im Folgenden aufgeführte Datenausleitung vPort-basiert sein, ohne Beachtung von switchübergreifender Kommunikation.

OVS beherrscht standardmäßig die Nutzung von Mirrorports, so dass die Implementierung der Ausleitung ohne weitere Werkzeuge realisiert werden kann. Die Konﬁguration eines solchen Mir- rorports ist sowohl über die CLI mit dem Tool ovs-vsctl als auch über die transact Methode der OVSDB möglich. Bei der Nutzung von ovs-vsctl mit dem Parameter set Bridge besteht die Möglichkeit, die UUID der Interfaces zur Laufzeit zu extrahieren. Im Listing 7.6 werden alle Daten von tap0 auf den Port mon0 kopiert.

Listing 7.6: Erstellung Mirrorport ovs−vsctl −− set Bridge INSTANZ mirrors=@m −− −−id=@quelle get Port tap0 −− −−id=@ziel get Port mon0 −− −−id=@m create Mirror name=mirror1 select −dst−port=@quelle select −src −port=@quelle output−port=@ziel

Die Manipulation per transact-Methode muss auf mehrere Tabellen innerhalb der OVSDB angewandt werden, wodurch der Aufwand deutlich erhöht wird. Ein entsprechender Aufruf mittels JSON-RPC ist in Listing 7.7 dargestellt.

Listing 7.7: JSON-RPC zur Mirrorerstellung method: transact ,params=["Open_vSwitch" , {"row": {"name":"mirror1" , "output_port" :[ "uuid","daa65d50−6862−42a8−babc−4e4fd38f6784"] , "select_src_port":["uuid","2365bd2f−f766 −4a0c−bef8 −83890cde6511"] , "select_dst_port":["uuid","2365bd2f−f766 −4a0c−bef8 −83890cde6511"]} , "table":"Mirror", "uuid−name":"row93b7a299_80e2_44b0_9f92_5965ed655ff7" , "op":"insert"}, {"row":{"mirrors": [ "named−uuid" ,"bfcb536d−f3a4 −4810−bf9d −3ffde4bd7372"]} , "table":"Bridge","where": [["_uuid" ,"==" ,["uuid","6bf85ef0 −3799−40a2−8211−8c937bf6e28a"]]] , "op":"update"}], id=1

157 7 Open vSwitch-Forensik

Eine Extraktion der UUIDs zur Laufzeit ist bei diesem Aufruf nicht möglich, so dass diese im Vorfeld durch weitere JSON-RPC Anfragen ermittelt werden müssen. Der zusätzliche Aufwand zur Extraktion, Analyse und Speicherung der relevanten Daten verkompliziert die forensische Analyse, so dass im Weiteren die direkte Abfrage der OVSDB nicht genutzt wird, sondern mit Hilfe der Wrappertools eine Identiﬁzierung und automatisierte Einrichtung des Mirrors ermöglicht wird.

7.4.1 Plain

OVS bietet unterschiedliche Methoden der Vernetzung, um die VMs in den zugewiesenen Subnet- zen zu isolieren. Eine Umsetzung ohne die Nutzung separater Layer 2-Protokolle wie VLAN oder VXLAN wird im Folgenden als Plain bezeichnet. Dabei sind alle VMs auf der OVS-Instanz gleich- berechtigt und in der Lage, sämtlichen Layer 2-Broadcastverkehr abzuhören. Diese Umsetzung entspricht einer klassischen Vernetzung ohne konﬁgurierte VLAN-Separierung auf hardwarebasierten Switchen.

7.4.1.1 Mirrorkonﬁguration

Der Mirror kann, wie in Listing 7.6 dargestellt, eingerichtet werden. Die Ausleitung der Daten zeigt dabei keinerlei Schwierigkeiten bei der Aufzeichnung, sämtliche Daten werden korrekt an das Zielsystem übermittelt.

7.4.1.2 Ergebnis

Es existieren keine kritischen Parameter, die die Aufzeichnung erschweren können. Da keine zusätzlichen Informationen wie VLAN-ID oder VID übermittelt werden, reicht die Konﬁguration des Mirrorports mit Hilfe einer adressen- oder portbasierten Identiﬁzierung aus.

7.4.2 VLAN

Die Verarbeitung von VLAN-IDs auf einem Switch erfolgt auf zwei Arten. Zum einem kann der Port als untagged konﬁguriert sein, wodurch sämtliche VLAN-Informationen vom Switch vor Weiterleitung an die VM entfernt werden. Im tagged-Modus leitet der Switch die Netzwerkpakete unverändert weiter, so dass die VLAN-Informationen an die VM geleitet werden [Soc03].

158 7.4 Mirrorport

7.4.2.1 Mirrorkonﬁguration

Auch die Konfiguration von VLANs verändert nicht den Aufzeichnungsprozess. Das Listing 7.8 zeigt die Konfiguration zweier vPorts für das VLAN mit dem VLAN-Tag 111 im untagged- mode. Eine Konfiguration im tagged-Modus erfolgt durch Setzen der Option vlan_mode=native- tagged.

Listing 7.8: Aufzeichnung von VLAN-separiertem Datenverkehr ovs−vsctl show 76c944ad−6d3a−4c14 −83db−b6bb4db7f7cb Bridge "br0" Port "tap0" tag: 111 Interface "tap0" Port "br0" Interface "br0" type: internal Port "tap2" tag: 111 Interface "tap2" Port "tap1" Interface "tap1" ovs_version: "2.0.2"

Das obige Kommando zeigt den VLAN-Modus nicht an, diese Information wird für jeden Port in der OVSDB gespeichert und kann hieraus extrahiert werden.

Die Mirrorkonﬁguration erfolgt in beiden Fällen genauso wie im vorigen Abschnitt, da auch hier zielgerichtet ein vPort überwacht wird.

7.4.2.2 Ergebnis

Da VLAN-Informationen auf dem vSwitch für einen Port hinterlegt sind, muss ermittelt werden, ob diese Daten für den Aufzeichnungsprozess relevant sind.

Bei der Analyse des untagged-Modus sind in der Aufzeichnung von 74 Netzwerkpaketen, die zwischen den Systemen übertragen wurden, wie in Listing 7.9 keine VLAN-Informationen, sondern nur Klartextinformationen in Form von Address Resolution Protocol (ARP) und ICMP-Paketen zu ﬁnden.

159 7 Open vSwitch-Forensik

Listing 7.9: Datenaufzeichnung von untagged-VLAN Datenverkehr tshark −r untagged.pcap vlan | wc −l 0 tshark −r untagged.pcap icmp | wc −l 70 tshark −r untagged.pcap arp | wc −l 4

Da der vSwitch die VLAN-Tags hinzufügt und wieder entfernt, bevor die Daten an das Zielsystem weitergeleitet werden, sind in den aufgezeichneten Datenpaketen keinerlei VLAN-Informationen zu ﬁnden.

Die Aufzeichnung von tagged-Datenverkehr wie in Listing 7.10 zeigt bei gleicher Konﬁguration des Mirrors Pakete mit VLAN-Tag, die Daten sind jedoch vollständig extrahierbar.

Listing 7.10: Datenaufzeichnung von tagged-VLAN Datenverkehr tshark −r tagged.pcap vlan | wc −l 74 tshark −r tagged.pcap icmp | wc −l 70 tshark −r tagged.pcap arp | wc −l 4

Somit ist eine Aufzeichnung sämtlicher Pakete, losgelöst von der VLAN-Konﬁguration, möglich.

7.4.3 VXLAN

VXLAN zur Trennung der VMs ist aufgrund des größeren Adressraums in großen virtuellen Umgebungen besser geeignet. Zur Analyse der anfallenden Daten wird der Testaufbau erweitert, Tabelle 7.5 führt die jeweils verwendeten Komponenten auf. Alle VMs werden unter Ubuntu 14.04.3 LTS betrieben. Als Aufzeichnungssystem wird ein physisches System ohne IP-Adresse auf Basis von Debian 8 genutzt.

Die zwei Wirtssysteme Links und Rechts sind per Netzwerkkabel über einen Netgear GS724T45 verbunden.

45Details zum eingesetzten Hardwareswitch sind unter [Net12] veröﬀentlicht.

160 7.4 Mirrorport

Tabelle 7.5: Testumgebung VXLAN Hostname IP-Adresse MAC-Adresse Aufgabe Rechts 192.168.140.128/24 00:0c:29:c8:8f:83 Hostingder VM, Bereitstellung der OVS-Umgebung Links 192.168.140.129/24 00:0c:29:ef:ee:46 HostingderVM, Bereitstellung der OVS-Umgebung VM1 10.0.0.11/24 00:00:00:00:00:11 Kommunikationssystem1 VM2 10.0.0.12/24 00:00:00:00:00:22 Kommunikationssystem2 VM3 10.0.0.13/24 00:00:00:00:00:33 Kontroll-VM zur Sicherstellung der korrekten Konﬁguration VM4 10.0.0.14/24 00:00:00:00:00:44 Kommunikationssystem4 VM5 10.0.0.15/24 00:00:00:00:00:55 Kommunikationssystem5 VM6 10.0.0.16/24 00:00:00:00:00:66 Kontroll-VM zur Sicherstellung der korrekten Konﬁguration Mirror - ae:12:43:f6:0e:e0 Aufzeichnung der gespiegelten Netzwerkdaten

7.4.3.1 Mirrorkonﬁguration

Die Konﬁguration der Testumgebung ist in Listing 7.11 dargestellt. Die erste Analyse der Mir- rorkonﬁguration erfolgt wie bei den beiden vorherigen Szenarien durch direkte Ausleitung am involvierten vPort.

Listing 7.11: VXLAN-Konﬁguration (Ausgabe gekürzt) sudo ovs−vsctl show 76c944ad−6d3a−4c14 −83db−b6bb4db7f7cb Bridge "br0" Port "tap2" Interface "tap2" Port "tap1" Interface "tap1" Port "vxlan1" Interface "vxlan1" type: vxlan options : {remote_ip="192.168.140.129"} Port "tap0" Interface "tap0" Port "br0" Interface "br0" type: internal

161 7 Open vSwitch-Forensik

In diesem Szenario existiert eine weitere Position zur Aufzeichnung der Netzwerkdaten, da auch der Hardwareswitch die Mirrorfunktionalität anbietet. Diese Anbindung entspricht der Netzwerk- forensik in klassischen Umgebungen, Abbildung 7.4 zeigt die Anbindung exemplarisch.

Links (192.168.140.129) Rechts (192.168.140.128)

¤ ¥ VM1 VM2 VM3 VM% VM VM

tap0 tap1 tap0 tap1

tap2 tap2 b¢£ VXLAN b¢£

Netgear

® MODEL GS 524T

Green=FDX,Yellow=COL 24 PORT Gigabit Switch 1 12 10/100/1000Mbps Blinking=Activity On=10M Link 1000M 100M 1 23 4 5 6 7 8 9 10 11 12 Green=FDX,Yellow=COL Auto ™ Uplink Power Blinking=Activity On=10M Link 13 24 13 14 17 18 19 20 21 22 231516 24

Mirror

Abbildung 7.4: Anbindung des Mirrorports an VXLAN-basierte Vernetzung

7.4.3.2 Ergebnis

In VXLAN-basierten Umgebungen übernehmen die VTEP die Aufbereitung der gekapselten Da- ten, so dass keinerlei VXLAN-Protokolldaten an das Endgerät übertragen werden. Somit ist diese Overlaytechnik vollständig transparent für den Nutzer.

Während die quellnahe Aufzeichnung am vPort somit keine Einschränkungen aufweist, beinhaltet die Aufzeichnung der Daten auf dem Weg zwischen den VXLAN-Endpunkten die gekapselten Daten, die wie im Abschnitt 4.10.1 beschrieben, nur mit Hilfe geeigneter Werkzeuge analysiert werden können.

7.4.4 Gesamtergebnis

Die Untersuchung der drei oben aufgeführten Fälle zeigt, dass es bei korrekter Identiﬁkation der

VMt möglich ist, eine funktionsfähige Datenausleitung zu erhalten. Da OVS für die weiteren Overlayprotokolle gleichartige Konﬁgurationen anbietet, ist dort ebenfalls eine funktionierende Mirrorfunktionalität gegeben.

162 7.5 Überwachung

Mit diesen Daten kann die initiale Einrichtung eines Mirrorports für das zu überwachende System durchgeführt werden. Anschließend kann mit Hilfe der im Folgenden vorgestellten Techniken die Überwachung der OVS-Instanz realisiert werden, die eine valide Aufzeichnung der relevanten Netzwerkdaten ermöglicht.

Dabei ist die Art der genutzten Vernetzung für das gewählte Aufzeichnungsszenario nahezu transparent. Die aufgezeichneten Daten beinhalten je nach Netzwerkkonﬁguration zusätzliche Informationen wie VLAN-ID oder gekapselte Daten. Somit ist besonders in VXLAN-basierten Umgebungen die zielgerichtete Aufzeichnung am vPort notwendig, um die Daten möglichst un- gekapselt aufzeichnen zu können.

Ein ähnlicher Ansatz wird auch in [NSV16] beschrieben, hier wird jedoch keine Unterscheidung der Netzwerkseparierung vorgenommen, sondern nur die Möglichkeit der lokalen Datenaufzeich- nung und -analyse beschrieben. Da es sich bei dem vorgestellten System um eine Analyseum- gebung einer NFVI handelt, erfolgt eine Verarbeitung der Netzwerkpakete direkt skriptgesteuert auf dem CN, nur die berechneten Statistiken werden weitergeleitet.

7.5 Überwachung

Die einmalige Identiﬁkation eines genutzten vPorts ist in virtuellen Umgebungen nicht ausreichend [SKE17]. Ein Herunterfahren und erneutes Starten einer VM führt zu neuen UUIDs auf dem Switch und verhindert so eine dauerhafte Aufzeichnung. Die OVS-Instanz löscht den zuge- hörigen Port beim Herunterfahren der VM und legt einen neuen Port mit neuem Interface und neuer UUID auf der Instanz an, wenn diese VM erneut hochgefahren wird.

In Anlehnung an [CKX+13] kann diese Technik auch als Gegenmaßnahme bei bestehenden Angrif- fen genutzt werden. Die dort beschriebenen Techniken zur Änderung ﬂexibler Daten ermöglicht die Unterbrechung laufender Angriﬀe. Somit bietet die Änderung der UUID im Bereich der IT- Sicherheit mögliche Vorteile, im Bereich der Netzwerkforensik erschwert diese Dynamik jedoch deutlich eine laufende Aufzeichnung.

7.5.1 Bestimmung einer geeigneten Datenbasis

Eine dauerhafte Ausleitung aller Netzwerkdaten der VMt ist somit nur möglich, wenn die OVS- Instanz auf Änderungen überwacht, und bei Eintritt einer solchen Änderung die erneute Identi- ﬁzierung durchgeführt werden.

163 7 Open vSwitch-Forensik

[BAM10] definiert unterschiedliche Quellen, die Informationen über Veränderungen im Netz- werk bereitstellen. Hierzu gehören Eventlogs wie SNMP oder Syslog, Netzwerkdatenverkehr und Snapshots der Netzwerktopologie. [GJN11] erweitert diese Datenquellen um mögliche Ticket- informationen, die automatisiert oder durch Nutzer erstellt werden. Da alle Änderungen einer OVS-Instanz in der OVSDB gespeichert werden, ist eine Analyse auftretender Veränderungen hier ebenfalls möglich, [RKV15] definiert OVSDB als Southbound-API zur Manipulation und Abfrage von Konfigurationen.

Für die Analyse der Statusänderungen ergeben sich somit Quellen, die sich hinsichtlich ihrer tatsächlichen Eignung für die Überwachung unterscheiden. Im Folgenden werden diese Quellen analysiert und hinsichtlich ihrer Eignung bewertet.

7.5.1.1 Syslog

Die Syslog-Überwachung bietet keine Sicherheit, dass alle notwendigen Informationen vorliegen, da diese durch den Administrator angepasst werden kann. [LBKH16] beschreibt diese Protokoll- daten als allgegenwärtig, bemängelt jedoch zeitgleich unterschiedliche Probleme:

Network device syslogs are ubiquitous and abundant [...] Despite their potential benefits, syslogs have been ignored because they lack structure (free form text), lack homogeneity (they differ across vendors and even for a vendor, they may differ across firmware versions), and lack global causality semantics that are necessary for diagnosis (information identifying causal relationships between a haystack of messages).

Eine Extraktion der benötigten Daten führt somit im Einsatzfall mit hoher Wahrscheinlichkeit zu einer Anpassung der eingesetzten Skripte und Werkzeuge. Dies ist besonders im Rahmen des strukturierten Vorgehens kein nutzbares Verhalten.

Unterschiedliche Arbeiten beschäftigen sich mit der Angleichung der verschiedenen Formate [YM05], [QGP+10], die von Netzwerkkomponenten bereitgestellt werden, oder der zeitgerechten Analyse dieser Daten [Ger16]. Die unterschiedlichen Formate erschweren dabei jede Form der Analyse, so dass jedes System analysiert und manuell an die vorgegebene Struktur angepasst werden muss. Dieses Verfahren ist somit für forensische Analysen kaum nutzbar.

7.5.1.2 SNMP

SNMP ermöglicht die Änderung und Abfrage von Konﬁgurationen unterschiedlichster Geräte. SNMP benötigt für die korrekte Funktionsweise installierte Agenten sowie eine geeignete Anbin-

164 7.5 Überwachung dung an den SNMP-Server. Sofern die Geräte SNMP unterstützen, ist es möglich, die jeweiligen Einstellungen an den zentralen Server zu senden, oder übermittelte Konﬁgurationsänderungen durchzuführen. SNMP nutzt Nachrichten mit dem Typ TRAP für die unaufgeforderte Mitteilung von Änderungen [Sta99]. Mit Hilfe diese Nachricht sendet der lokale Agent Informationen über ein aufgetretenes Ereignis, aber auch Meldungen aufgrund fehlgeschlagener Operationen.

OVS unterstützt SNMP und ist somit in der Lage, entsprechende TRAPs zu übermitteln. Aber diese SNMP-Traps sind für die Überwachung keine geeignete Datenbasis, da diese im Vorfeld de- ﬁniert werden müssen. Somit scheidet die Nutzung von SNMP als Datenbasis ebenfalls aus. Dies entspricht ebenfalls den grundsätzlichen Erfahrungen mit SNMP für forensische Zwecke. SNMP bietet für netzwerkforensische Untersuchungen nur grundlegende Informationen (vgl. Abschnitt 3.1.1) im Rahmen von Datenaufzeichnungen ist es jedoch nicht nutzbar (vgl. Tabelle 4.1).

7.5.1.3 Netzwerkdatenverkehr

Die Überwachung des Netzwerkverkehrs ist im Rahmen des Störungsmanagements oder IT- Sicherheit eine mögliche Datenbasis, um die Ursache eines Problems zu ermitteln [GTDVMFV09]. Auch für die Überwachung auf Änderungen scheint die Nutzung des aufgezeichneten Datenver- kehrs eine mögliche Umsetzung darzustellen. Da die Aufzeichnung der Daten bereits implementiert ist, fehlt letztlich nur die Liveanalyse der Daten, die sich jedoch von der eigentlichen Auswertung unterscheidet.

Die Auswertung hat das Ziel, Daten für die Klärung des Sachverhalts zu ermitteln (vgl. Abschnitt 2.6) die Liveanalyse zielt jedoch auf die zeitnahe Ermittlung der Änderung ab. Allerdings ist die Liveanalyse in stark frequentierten Umgebungen nicht einfach zu implementieren, da Aufzeich- nungstechniken nicht immer mit der hohen Übertragungsrate Schritt halten können [FD10]. Dies führt zu unvollständigen Aufzeichnungen, wodurch die Liveanalyse erschwert wird.

Die Analyse der Netzwerkdaten hängt weiterhin von den zu erwartenden Daten innerhalb der Umgebung ab, hierdurch sind schnell nutzbare Lösungen kaum möglich. Bevor die Netzwerkda- ten als Datenbasis für die Überwachung genutzt werden können, muss zuerst eine aufwändige Analyse der Netzwerkinfrastruktur, der eingesetzten Protokolle sowie der vorhandenen Kompo- nenten erfolgen. Hierdurch ist eine Analyse der Netzwerkdaten komplex und zeitaufwändig, so dass eine zeitnahe Reaktion auf Änderungen kaum möglich ist [FHD+09]. Eine Nutzung für die Überwachung auf relevante Änderungen scheidet somit aus.

165 7 Open vSwitch-Forensik

7.5.1.4 Snapshots

Snapshots dienen dazu, aktuelle Konﬁgurationen zu speichern und für spätere Zwecke vorzuhalten. Die Nutzung von Snapshots in virtuellen Umgebungen ist Thema unterschiedlichster Ar- beiten. [KXRE07] beschreibt die Implementierung eines Snapshotalgorithmus für virtuelle Netz- werkkomponenten. In [KEX12] wird die Erstellung von Snapshots innerhalb virtueller Netzwerke beschrieben, allerdings wird hierbei vorrangig die Erstellung von Snapshots virtueller Maschinen behandelt, um die Gesamtstruktur der virtuellen Umgebung zu sichern. [LT96] beschreibt die Erstellung von Snapshots virtueller Festplatten.

Die Erstellung von Snapshots laufender VNF ist mit der Erstellung von Abbildern virtueller Maschinen vergleichbar, da die virtuellen Netzwerkkomponenten als VM bereitgestellt werden. Somit beziehen sich die Änderungen auf die Daten, die in der laufenden Instanz gültig sind; im Rahmen von OVS ist dies vor allem die OVSDB, die sämtliche Daten speichert und so Änderungen durch den Abgleich unterschiedlicher Versionsstände ermöglicht. Allerdings ist die Erstellung und der Abgleich von Snapshots wiederum zeitaufwändig, so dass die Nutzung für eine Echtzeitüberwachung ausscheidet.

7.5.1.5 Ticketsystem

Die Nutzung von Ticketsystemen zur Analyse von Netzwerkproblemen bietet keinerlei Echtzeit- funktionalität, sondern eher eine Dokumentations- und Recherchemöglichkeit [GJN11]. Während die manuelle Ticketerstellung keine realistische Implementierung einer zeitnahen Benachrichti- gung darstellt, ermöglicht eine geeignete Deﬁnition relevanter Ereignisse und die damit verbundene automatisierte Ticketerstellung theoretisch eine mögliche Datenbasis. Jedoch muss die Deﬁnition der Ereignisse im Vorfeld erfolgen, somit ist eine forensische Nutzung erschwert. Sollte jedoch ein Ticketsystem implementiert sein, unterscheidet sich vermutlich das jeweilige Ausga- beformat [VN10], so dass eine forensische Nutzung analog zu Syslog-Daten nicht möglich ist.

7.5.1.6 OVSDB

Die Nutzung der OVSDB, die analog zu Abschnitt 7.1.1 auf zwei Arten abgefragt werden kann, bietet auch für die Überwachung auf Änderungen mögliche Implementierungen. Die Nutzung eines Snapshots der laufenden OVSDB ist in Abschnitt 7.5.1.4 beschrieben. Ein Vergleich der Snapshots ist zeitaufwändig, allerdings kann die OVSDB auch direkt als Datenbasis genutzt werden. Dazu können existente Werte ermittelt und für den Abgleich mit Änderungen vorgehalten werden.

166 7.5 Überwachung

Hierdurch ist eine Nutzung in forensischen Untersuchungen möglich, da keine Änderungen an der vorhandenen Umgebung vorgenommen werden müssen.

7.5.1.7 Ergebnis

Die beschriebenen Lösungen eignen sich nur teilweise für die Nutzung forensischer Untersuchun- gen. Tabelle 7.6 listet die untersuchten Techniken, die Eignung sowie Echtzeitfähigkeit und die Notwendigkeit zur Durchführung relevanter Vorarbeiten auf.

Die Echtzeitfähigkeit deﬁniert die Fähigkeit einer rechtzeitigen Reaktion auf relevante Ereignisse, die Vorarbeit beschreibt die Notwendigkeit vorheriger Maßnahmen oder Anpassungen in der Umgebung.

Eine geeignete Datenbasis sollte dabei echtzeitfähig sein, allerdings keine Veränderungen der Infrastruktur benötigen.

Tabelle 7.6: Datenquellen zur Überwachung Quelle Echtzeitfähigkeit Vorarbeit Eignung Syslog * SNMP * * Netzwerkdaten * Snapshots Ticketsystem * OVSDB * *

Nur die Nutzung der OVSDB bietet eine rechtzeitige Reaktion auf relevante Ereignisse, zeitgleich benötigt eine Abfrage keinerlei Veränderungen an der Infrastruktur. Dies gilt ebenfalls für die Snapshots, allerdings ist hier der Zeitaufwand für die Analyse der Änderungen zu hoch, um zeitgerecht reagieren zu können. Die weiteren Techniken benötigen Aufwand bei der Einrichtung oder führen zu Veränderung der Infrastruktur und sind somit nicht geeignet.

7.5.2 Implementierung der Überwachung

Bei Nutzung des OVSDB-Management-Protokolls kann mit Hilfe der Monitor- und der Update- Methode sichergestellt werden, dass Änderungen in der Datenbank zeitgerecht übermittelt werden [PBD13].

167 7 Open vSwitch-Forensik

Die Datenmenge der übermittelten Daten basiert auf der Anzahl der eingerichteten Ports, vSwitches und Interfaces, so dass der Start einer VM die Ausgabe in Listing 7.12 an den Client liefert.

Listing 7.12: Ausgabe per OVSDB-Monitoring beim Start einer VM {"method":"update","id ": null ,"params":["Open_vSwitch",{"Port": {"b76d6be8−6de4 −4344−882c−cd4898a8df85":{"new":{"name": "tap1","fake_bridge ":false ," interfaces ":["uuid", "d87904a1−9626−46fd−bed4 −1824528fa916"],"tag":[" set" ,[]]}}} , "Bridge":{"0e11588f −6303−49c5−b0a1−1aeed098bc9e":{"old":{ "ports ":[" set" ,[["uuid","200ac6b4−85b9−46b7−a285−a63ea0b945a9 "] ,[" uuid","50027975 −21ba−40f5 −8256−ae48ea1e0bdc"] ,["uuid","a54ecf5e −20af −4bfc −9845−862a455b2a05"] ,[" uuid", "f62ed699 −674e−4147−b0e2−7f31305a5f45 "]]]} , "new":{"fail_mode":[" set" ,[]] ,"name":"br1","ports ": ["set",[[ "uuid","200ac6b4 −85b9−46b7−a285−a63ea0b945a9"] , [" uuid","50027975 −21ba−40f5 −8256−ae48ea1e0bdc"] ,["uuid","a54ecf5e −20af −4bfc −9845−862a455b2a05"] , [" uuid","b76d6be8−6de4 −4344−882c−cd4898a8df85"] , ["uuid","f62ed699 −674e−4147−b0e2−7f31305a5f45 "]]] , "controller ":["set",[]]}}}, "Interface ":{"d87904a1−9626−46fd−bed4 −1824528fa916 ": {"new":{"name":"tap1"}}}}]}

Die Struktur der Daten ist durch das OVSDB Management Protokoll vorgegeben, die Daten- menge ist jedoch ﬂexibel und hängt von der jeweiligen OVS-Instanz ab. Durch Anpassung der Update-Methode ist die Struktur der zurückgelieferten Daten jedoch änderbar, ohne relevante Informationen zu verlieren. Listing 7.13 zeigt die reduzierte Datenmenge beim Beenden, erkennbar am Schlüsselwort old, und beim Start einer VM, erkennbar durch das Schlüsselwort new an.

Listing 7.13: Reduzierte Ausgabe per OVSDB-Monitoring {"method":"update","id": null ,"params":["Open_vSwitch" ,{ "Port":{"200ac6b4 −85b9−46b7−a285−a63ea0b945a9": {"old":{"name":"tap2"}}}}]} {"method":"update","id": null ,"params":["Open_vSwitch" ,{ "Port":{"fb2d6cb6−fe3c −4852−996a−edac65c8d6dd": {"new":{"name":"tap1"}}}}]}

168 7.5 Überwachung

Durch die Anbindung an die Monitormethode und Auswertung der angepassten Rückgabewerte ist es somit möglich, zeitnah Informationen über die Änderungen im Netzwerk zu erhalten und geeignete Reaktionen zu treﬀen.

7.5.3 Situative Diﬀerenzierung

Die im Vorfeld behandelten Überwachungen bezogen sich auf das Monitoring der UUID. Diese ändert sich in jedem Fall, wenn die VM gestartet oder beendet wird. Für die Überwachung und Erstellung des Mirrorports werden jedoch die vPorts genutzt, deren Eindeutigkeit nicht immer gegeben ist. Je nach Situation besteht die Möglichkeit, dass ein vPort bei Neustart der VM gleich bleibt oder inkrementiert wird. Hierdurch ist die laufende vPort-ID nicht voll randomisiert, eine Garantie, dass die zu überwachende VM nach einem Neustart wieder die gleiche vPort-ID erhält, ist somit nicht gegeben.

Es können insgesamt drei Situation entstehen, die eine diﬀerenzierte Bearbeitung benötigen:

• Neustart der VM unter Beibehaltung der vPort-ID Die VM startet neu und erhält die gleiche vPort-ID, die sie auch bereits vor dem Neustart zugeordnet hatte. Dies erfolgt, wenn in der Phase des Neustarts keine andere VM gestartet wurde.

• Neustart der VM mit neuer vPort-ID Die VM startet neu, erhält jedoch nicht den gleichen vPort zugewiesen. Dies kann passieren, wenn in der Zwischenzeit andere VMs gestartet wurden. Da die Namensgebung der vNIC in den Defaulteinstellungen dynamisch sind, wird die vPort-ID einfach inkrementiert. Somit erhält eine VM, die zwischen Stoppen und Starten der zu überwachenden VM gestartet wird, vermutlich die alte vPort-ID.

Eine neue ID ist ebenfalls möglich, wenn in der Zwischenzeit mehrere VMs heruntergefahren

und nicht wieder neu gestartet wurden. Somit erhält die VMt wahrscheinlich einen geringere vPort-ID als vor dem Neustart.

Um zu vermeiden, dass im Folgenden falsche Daten aufgezeichnet werden und die zu über- wachende VM vollständig ignoriert wird, müssen geeignete Maßnahmen gefunden werden, die dieses verhindern.

• Kein Neustart der VM Sofern die VM nicht wieder gestartet wird, ist theoretisch die Aufzeichnung zu beenden.

Da es jedoch jederzeit wieder passieren kann, dass die VMt gestartet wird, ist hier vorerst die Aufzeichnungsumgebung weiterhin notwendig.

169 7 Open vSwitch-Forensik

Die Überwachung, Protokollierung und Erstellung geeigneter Mirrorports muss solange bestehen bleiben, bis die gesamte Aufzeichnung aus anderen Gründen beendet werden soll. In diesem Zeitraum besteht somit die Gefahr, dass auf dem Host eine Vielzahl möglicher Mirrorports erstellt, überwacht und wieder gelöscht werden.

Um die vorgenannten drei Möglichkeiten valide abzudecken, sind mehrere aufeinanderfolgende Schritte notwendig:

1. Überwachung auf neue vPort-IDs Durch das Monitoren der OVSDB werden alle neu hinzugefügten vNICs bemerkt.

2. Erstellen eines Mirrorports Wird das Hinzufügen einer vNIC festgestellt, wird ein neuer Mirror erstellt. Da der Mirror sofort beim Hinzufügen der vNIC erstellt wird, ist die Datenaufzeichnung bereits implementiert, bevor tatsächlich Daten übertragen werden. Für die Verbindung des Mirrors existieren wiederum zwei Möglichkeiten, die sich hinsichtlich ihrer Eignung für den weiteren forensischen Prozess unterscheiden.

• Nutzung separater vNICs je Mirror

• Nutzung einer einzelnen vNIC für alle Mirrors

Während die erste Möglichkeit aus forensischer Sicht gut geeignet ist, scheitert eine mögli- che Umsetzung an der Limitierung maximal verfügbarer vNICs pro VM. Die Anzahl instal- lierbarer NICs ist, wie in Tabelle 7.7 dargestellt, in Abhängigkeit vom Hypervisor limitiert.

Tabelle 7.7: Maximale Anzahl der vNICs nach Hypervisor Hypervisor Limit KVM 8 Microsoft Azure 8 XenServer 7 Hyper-V 12 VMWare 10 Xen 15

Diese Begrenzung verhindert eine Nutzung dedizierter vNICs für jeden Mirror. Überschrei- tet die notwendige Anzahl der Mirrors aufgrund vieler Neustarts unterschiedlicher VMs die maximale Anzahl, die ein Hypervisor bereitstellt, würde die gesamte Aufzeichnung unvoll- ständig, da keine vNICs mehr angeschlossen werden können.

170 7.5 Überwachung

Daher muss die Implementierung so ausgelegt sein, dass jeder neue Mirror ebenfalls auf

die vPort-ID der VMa zeigt. OVS unterstützt durch eine undokumentierte Funktion von ovs-vsctl die mehrfache Mirrorbelegung. Listing 7.14 stellt den entsprechenden Aufruf dar, im Gegensatz zu Listing 7.6 ist die Syntax minimal abgeändert46.

Listing 7.14: Hinzufügen zusätzlicher Mirrorport ovs−vsctl −− add Bridge INSTANZ mirrors @m −− −−id=@quelle get Port tap1 −− −−id=@ziel get Port mon0 −− −−id=@m create Mirror name=mirror1 select −dst−port=@quelle select −src −port=@quelle output−port=@ziel

Da ist es im ersten Schritt nicht erkennbar ist, ob das korrekte Zielsystem konnektiert wurde, muss in den weiteren Schritten die Portidentiﬁzierung durchgeführt werden.

Durch die automatische Erstellung eines Mirrorports, sobald ein neues Interface bemerkt wurde, steigt die Anzahl der im System vorhandenen Mirrorports auf stark frequentierten Systemen unter Umständen deutlich an. Durch die korrekte und zeitnahe Kontrolle des angeschlossenen Systems mittels Portidentiﬁzierung reduziert sich die Anzahl der Systeme jedoch in gleichem Maße.

3. Protokollierung Durch die Erstellung des Mirrorports besteht die Gefahr, dass falsche Daten, also Pakete

von Systemen, die nicht VMt sind, in den Netzwerkmitschnitten auftauchen. Um nachträg- lich bei der Analyse diese falschen Daten ausschließen zu können, wird über die Aktionen Protokoll geführt.

4. Portvalidierung Wie in Kapitel 7.3 beschrieben, kann über die Extraktion der CAM ausgewertet werden, welche MAC-Adresse einer vNIC an einem vPort angeschlossen ist. Mit diesen Informa- tionen ist es nun möglich, die jeweiligen Mirrorports zu bewerten und unnötig aufgebaute Mirrorports zeitnah wieder abzubauen.

5. Rekonﬁguration Abhängig von der durchgeführten Portidentifzierung entstehen zwei Möglichkeiten:

46Zum Hinzufügen eines weiteren Ports zum Mirror wird das Schlüsselwort add anstatt set genutzt. Zusätzlich erfolgt keine Mirrorzuweisung in Form mirrors=@m, sondern nur die Mirrorbenennung in der Form mirrors @m.

171 7 Open vSwitch-Forensik

• Löschen des betroﬀenen Mirrorports Sofern der Mirrorports auf ein System ausgelegt ist, welches nicht dem Zielsystem entspricht, muss der Mirrorport abgebaut werden, um die Aufzeichnung nicht weiter zu verfälschen.

• Aufrechterhalten des Mirrorports

Wenn der eingerichtete Mirrorport die Daten der VMt aufzeichnet, können automatisch alle weiteren Mirrorports abgebaut und die dauerhafte Überwachung auf neue vPort-IDs bis zur nächsten relevanten Änderung eingestellt werden.

7.5.4 Protokollierung

Die Protokollierung ist ein wichtiger Bestandteil der gerichtsfesten Auswertung von Daten [DF11]. Die im vorigen Abschnitt genannten Werkzeuge und Programme bieten keinerlei nutzbare Pro- tokollierungsfunktionen, die einer forensischen Auswertung gerecht werden.

Daher umfasst der PoC neben der funktionsfähigen Überwachung und Implementierung der Mirrorports auch die sachgerechte Protokollierung der Aktionen. Alle im Netz entstehenden Aktionen produzieren Einträge in Logdateien. Diese Protokollierung ermöglicht auch nachträglich eine Aussage zu den automatisiert durchgeführten Schritten. Durch Einfügen des Zeitstempels ist eine zeitliche Bewertung auch parallel laufender Prozesse möglich. Der PoC umfasst daher die folgenden Informationen:

• Zeitstempel Mit dieser Information kann später in Kombination mit dem Netzwerkmitschnitt sicher festgestellt werden, wann diese Daten aufgezeichnet wurden.

• Aktion Dieser Eintrag legt fest, ob ein Mirrorport für eine neu eingerichtete vNIC eingerichtet (CREATE) oder entfernt (DELETE) wurde. Bei der Auswertung der Daten kann so festgestellt werden, ob ungültige vNICs in der Überwachung verblieben sind.

• vPort-ID Zur Validierung der Aufzeichnung kann mit Hilfe der vPort-ID und der vorgenannten Ak- tionen CREATE oder DELETE nachvollzogen werden, ob benötigte und nicht benötigte Mirrorports korrekt verarbeitet wurden.

• Mirrorname Diese Daten beschreiben den jeweils eingerichteten Mirror sowie die zugeordnete UUID. Durch diese Daten kann veriﬁziert werden, welche Mirror für welchen Zweck eingerichtet

172 7.5 Überwachung

wurden. Eine Analyse der zugehörigen Mirror zur vNIC der VMt ist ohne diese Information nicht möglich.

Zur Vereinfachung der Analyse erfolgt eine Aufteilung der Informationen in zwei Protokolldateien. Dabei wird aus Gründen der Nachvollziehbarkeit die IP-Adresse des Hosts, der die OVSDB bereitstellt, mit in den Dateinamen übernommen. Hierdurch ist die zeitgleiche Auswertung mehrerer Hosts von einem zentralen Steuersystem möglich.

• ovsdb_update_IP.log Diese Datei speichert sämtliche Informationen über neue oder gelöschte vNICs.

• ovsdb_mirror_IP.log Diese Datei speichert alle relevanten Daten, die die Port-Mirror betreﬀen.

Die Datei ovsdb_update_IP.log ist wie folgt aufgebaut, Listing 7.15 zeigt einen Auszug der Protokolldatei:

DATUM_UHRZEIT;AKTION;UUID_VNIC;VPORT_ID;BR_ID:UUID_BR

Listing 7.15: Logging relevanter Aktionen 20161126_05:35:09;INSERT;7 fbe48bf −2952−4b07−ac11−e589b90be1fe;\ tap8;br1;6a44d176−1d2a−4ed3−ac7c−e341b9e3115a

Die Datei zeigt das Hinzufügen von der vNIC mit der ID tap8 mit der UUID 7fbe48bf-2952-4b07- ac11-e589b90be1fe auf der Bridge 6a44d176-1d2a-4ed3-ac7c-e341b9e3115a mit dem Namen br1.

Die Datei ovsdb_mirror_IP.txt speichert die dazugehörigen Informationen zu jeder Bridge und hat dabei folgenden Aufbau. Listing 7.16 zeigt einen exemplarischen Auszug aus der Logdatei.

DATUM_UND_UHRZEIT;AKTION;NAME_DES_MIRRORS;BR_ID;UUID_BR;MIRROR_ID->VPORT_ID

Ein Mirrorport mit dem Namen mirror755 auf der Instanz br1 mit der UUID 6a44d176-1d2a- 4ed3-ac7c-e341b9e3115a ist im Beispiel so konﬁguriert, dass sämtliche Daten der vPort-ID tap8 von tap5 aufgezeichnet werden.

Listing 7.16: Logging der Mirrorportaktionen 20161126_05:45:52;CREATE; mirror755 ;br1;\ 6a44d176 −1d2a−4ed3−ac7c−e341b9e3115a ;tap5−>tap8

173 7 Open vSwitch-Forensik

7.6 Implementierung

Bisherige, einfach strukturierte Ansätze der möglichen Kommunikation mit OVS-Instanzen besitzen keinerlei Sicherheit, Protokollierung oder auch nur grundlegende forensische Herangehens- weisen. Real nutzbare Implementierungen in diesem Bereich sind nicht vorhanden, meist bleibt es bei der groben Einführung in die Thematik. So ﬁndet man bei Github mit py-ovsdb-client [Fre13], ovs-lab [rel14] oder openv_monitor [PLV16] Basisimplementierungen, die jedoch nicht für forensische Zwecke geeignet sind.

Die Überwachung der OVSDB ist über die Programme ovsdb-client oder auch ovs-appctl mög- lich. Jedoch ist keines dieser Programme für die Nutzung aus forensischer Sicht geeignet, da hier keinerlei Sicherheiten oder Automatisierungsfunktionen vorgesehen sind.

Eine reine Implementierung auf JSON-RPC-Basis verlangt verstärkten Implementierungsaufwand und erhöht somit das Fehlerrisiko. Daher wird eine Kombination aus beiden Techniken genutzt, die eine Überwachung der Datenbank mit Hilfe der JSON-RPC-Methoden implementiert und für die Einrichtung der Mirrorports auf die Wrappertools zurückgreift.

Auf einem Monitoringsystem wird OVSF ausgeführt. Dabei erwartet das Skript die Übergabe verschiedener Parameter:

• IP-Adresse des Systems, auf dem die OVSDB läuft

• Name der vNIC der VMt

• Name der vNIC der VMa

• Name der OVS-Instanz

Die Ermittlung dieser Daten erfolgt auf die in Abschnitt 7.3 beschriebene Technik. Mit Hilfe der Daten initiiert das Skript die erstmalige Einrichtung des Mirrorports und startet den Überwa- chungsprozess.

OVSF arbeitet dreistuﬁg, Abbildung 7.5 verdeutlicht den gesamten Programmablauf.

1. Datenbankverbindung Das Skript baut eine Verbindung zur OVSDB auf. Hierzu wird die IP-Adresse des Systems übergeben, welches die OVSDB betreibt. Der erfolgreiche Aufbau der Verbindung wird protokolliert, parallel werden die übergebenen Parameter zur Veriﬁzierung ausgegeben.

Connecting to 127.0.0.1 Mirrorport: tap0

174 7.6 Implementierung

Target: tap1 OVS instance: br1

Nach Aufbau der Verbindung wird die Monitoringmethode implementiert, die die Über- wachung der laufenden OVS-Instanz ermöglicht. Anschließend wird der initiale Mirrorport

erstellt, so dass eine Aufzeichnung an der vNIC der VMt erfolgen kann. Zur Veriﬁzierung wird die UUID des Mirrors übergeben.

Monitoring of the OVSDB Open_vSwitch on 127.0.0.1 enabled Create initial mirror d2f2b2c9-ead2-4d95-b7d9-41fb14d43d53 mirroring established, please start capture process on port tap1

Anschließend ermittelt das Skript die MAC-Adresse der VM, die am Zielport angeschlossen ist. Hierdurch wird veriﬁziert, ob das richtige System überwacht wird.

Extract the entries out of the FIB Found MAC address 00:00:00:00:00:55 in FIB on of-port 53 Found target VM on port tap3 SUCCESS The mac address of the target VM is 00:00:00:00:00:55

2. Überwachung auf Änderungen Die Monitoringmethode informiert bei Eintreten von Änderungen an den überwachten Tabellen das Monitoringsystem, dieses startet eine entsprechende Bearbeitung, die ein Hinzufügen oder Entfernen eines Mirrorports zur Folge hat. Dies erfolgt jedoch nur, wenn

die betroﬀene vNIC der VMt involviert ist. Ansonsten werden keine Mirror zusätzlich erstellt oder gelöscht.

3. Kontrolle Das System kontrolliert die erstellten Mirrorports auf Korrektheit. Wird festgestellt, dass ein System überwacht wird, welches nicht dem Zielsystem entspricht, wird der Mirrorport dieses Systems entfernt und die Aufzeichnung beendet.

Dabei wird durch die interne Protokollierung sichergestellt, dass keine Mirrorports gelöscht werden, die aufgrund anderer Maßnahmen, z.B. aufgrund administrativer Arbeiten innerhalb der Umgebung, eingerichtet wurden.

Sofern die VMt heruntergefahren wird, bemerkt das Skript dies und informiert über die Änderung.

Target VM is shutting down, remove mirror

175 7 Open vSwitch-Forensik

Delete mirror from tap3 on vswitch br1 assigned to initialMirror

Anschließend überwacht das Skript wieder alle Einträge der CAM. Wird die VMt wieder mit dem Netzwerk verbunden, entsteht eine neue vNIC im Netzwerk, wodurch das Skript automatisiert einen Mirrorport erstellt. Sobald die beim Programmstart ermittelte MAC- Adresse in der CAM eingetragen ist, wird der neue Port ermittelt und alle nicht mehr benötigten Mirrorports entfernt.

Abbildung 7.5 stellt den Programmablauf schematisch dar.

Start OVSF

Initialen Mirrorport erstellen

Überﬂüssige Monitoring Mirrorports starten

löschen #¦ §#

ja Parameter Event tritt ein MAC in FIB? aktualisieren

Relevant? #¦ §# FIB auslesen

#¦ §# Ausleitung ja Mirror erstellen aktiv?

Abbildung 7.5: Programmablauf OVSF

7.7 Zusammenfassung

Ebenso wie in traditionellen Netzwerken sind auch in virtualisierten Umgebungen die Switche für die Kommunikation der Systeme von zentraler Bedeutung. Es ist also zielführend, die vSwitche hinsichtlich der forensischen Möglichkeiten zu analysieren und zu bewerten. In diesem Kapi- tel wurde Open vSwitch als vSwitch-Implementierung untersucht, wie eine netzwerkforensische

176 7.7 Zusammenfassung

Untersuchung durchgeführt werden kann, welche Daten zur Verfügung stehen und welche Pro- blembereiche, die diese Untersuchung erschweren, auftreten können.

Ein dabei schon im Vorfeld auftretendes Problem ist die Portidentiﬁzierung, die in traditionellen Netzwerken bereits mit Hilfe visueller Analysemöglichkeit realisierbar ist. In virtuellen Netzwerken fehlt die Möglichkeit des Tracings, so dass nicht unmittelbar die Verbindung zwischen vNIC und vSwitch ermittelt werden kann.

Durch den Virtualisierungsgrad ist es weiterhin nicht möglich, unterschiedliche Aufzeichnungs- techniken, wie sie in klassischen Netzwerken zur Verfügung stehen, zu nutzen. Hardwarelösungen wie TAPs oder Bridges, die in den Datenstrom eingebracht werden, sind in virtuellen Umgebungen wirkungslos, so dass ausschließlich die Nutzung eines Mirrorports verbleibt.

Die eindeutige Identiﬁzierung der vNICs und der dabei genutzten Ports erfolgt innerhalb OVS mit Hilfe von UUIDs. Allerdings ist die Gültigkeit einer UUID an die Laufzeit der VM gebunden; startet diese VM neu, kann die vPort-ID bestehen bleiben, die UUID ändert sich jedoch in jedem Fall.

Zur Extraktion der UUIDs sowie weiterer relevanter Informationen stehen unterschiedliche Werk- zeuge zur Verfügung, die in diesem Kapitel hinsichtlich ihrer Eignung für die netzwerkforensische Analyse untersucht wurden. Dabei ist keines der vorgestellten Programme vollständig in der La- ge, die Anforderungen des in Kapitel 6 vorgestellten VNFP zu erfüllen. Daher wurde für den umgesetzten PoC eine Kombination der Programme entwickelt, die einerseits das Monitoring mit Hilfe des OVSDB-Management-Protokolls bereitstellt und andererseits mit Hilfe der Wrap- perprogramme die Identiﬁkation, Konﬁguration und Überwachung der Mirrorports realisiert.

Dabei implementiert die Lösung eine mehrfache Nutzung eines Mirrorports zur Anbindung der VMs, andere Realisierungen weisen diverse Nachteile auf, die die Nutzung innerhalb einer forensischen Analyse erschweren oder verhindern. Hierzu gehört die fehlende Mirroringfunktionalität der vSwitch-Verbindung oder die Erhöhung der Netzlast.

In diesem Kapitel wurde ein Lösungsweg gezeigt, der in drei Schritte aufgeteilt ist:

• Identiﬁkation des genutzten Ports

• Konﬁguration des Mirrorports

• Überwachung und Anpassung des Mirrorports

Durch diesen Lösungsweg ist garantiert, dass keine Netzwerkdaten der VMt verpasst werden, durch die schnelle Bereitstellung des Mirrorports ist die Aufzeichnungsmöglichkeit bereits vorhanden, ehe die VM tatsächlich Daten übertragen kann. Die implementierte Protokollierung

177 7 Open vSwitch-Forensik ermöglicht die Überprüfung der Korrektheit und sichert die Nachvollziehbarkeit der Datenauf- zeichnung.

Dabei implementiert der Ansatz die Überwachung einer einzelnen OVS-Instanz. Die in diesem Kapitel entwickelte Lösung in Form eines PoC für OVS-Infrastrukturen kann jedoch durch wenige Anpassungen auch auf andere vSwitch-Implementierungen angepasst werden, da die vorgestellten Techniken und Methoden allgemeine Gültigkeit für vSwitche haben. Dabei ist die Art des vSwitches nahezu unerheblich, einzig die Aspekte der Überwachung sind gesondert zu bewerten, da nicht jede Implementierung geeignete Möglichkeiten anbietet. Gelingt es jedoch, eine vSwitch-Instanz durch geeignete Maßnahmen zu überwachen, sind die weiteren Arbeitsschritte analog anwendbar.

Die Fokussierung auf die Implementierung einer softwarebasierten Untersuchung an vSwitchen bedeutet zeitgleich die Einschränkung der globalen Sicht auf das Netzwerk. Eine Migration der

VMt wird zwar bemerkt, allerdings erfolgt aufgrund der singulären Überwachung keine Anpassung der Gesamtaufzeichnung. Nachdem die VM migriert wurde, wird der lokale Port ungültig, so dass die Aufzeichnung gestoppt wird. Da kein Neustart an der überwachten OVS-Instanz erfolgt, muss die Aufzeichnung manuell unterbrochen werden. Im nächsten Kapitel wird gezeigt, wie eine VM auch bei Migrationen dauerhaft überwacht werden kann.

178 8 OpenFlow-Forensik

In diesem Kapitel wird eine Lösung für die Durchführung netzwerkforensischer Arbeiten in OpenFlow-basierten Umgebungen vorgestellt. Der dabei vorgestellte Ansatz unterschiedet sich vom im vorigen Kapitel beschriebenen OVSF durch die Realisierung einer fortlaufenden Daten- aufzeichnung, auch wenn die Ziel-VM auf andere Systeme migriert wird.

Daher werden in diesem Kapitel die forensischen Möglichkeiten einer OpenFlow-Umgebung in Verbindung mit OVS untersucht und ausgehend von diesen Ergebnissen mit ForCon eine Lösung vorgestellt, die netzwerkforensische Analysen in diesen Umgebungen ermöglicht.

Zuerst erfolgt die Analyse existenter Ansätze sowie eine Untersuchung geeigneter Techniken, die eine Netzwerkforensik in SDN-basierten Umgebungen ermöglichen. Da diese Ansätze nicht ausreichend sind, wird anschließend eine Identiﬁzierung geeigneter Implementierungen durchgeführt. Anschließend werden Probleme beschrieben, die die forensischen Arbeiten in OpenFlow-basierten Netzwerken zusätzlich erschweren. Aufbauend auf dieser Analyse werden anhand der Phasen des VNFP die notwendigen Teilschritte von ForCon erarbeitet und die Zusammenarbeit deﬁniert.

8.1 Vorüberlegungen

OpenFlow-basierte Netzwerke erschweren zusätzlich die Aufzeichnung der relevanten Netzwerk- daten. Statische Aufzeichnungssysteme sind hier gänzlich nutzlos, da die gesamte Steuerung des Datenverkehrs durch externe Controller durchgeführt wird, wodurch auch der zuständige Netz- werkadministrator nur noch mittelbaren Einﬂuss auf die interne Kommunikation im Netzwerk hat. Somit ist der verantwortliche Administrator nicht mehr in der Lage, direkte Hilfestellung bei der Aufzeichnung der relevanten Daten zu bieten.

Die Kommunikation zwischen Controller und Switch erfolgt über die Southbound-API (vgl. Kapitel 2.4). OpenFlow ist das am häuﬁgsten eingesetzte Protokoll zur Implementierung der Southbound-API. Die folgende Analyse existenter Implementierungen ist daher auf OpenFlow ausgelegt.

179 8 OpenFlow-Forensik

8.1.1 Analyse existenter Implementierungen

Der Ansatz einer zentralen Steuerung der anfallenden Daten scheint auf den ersten Blick den Aufwand der Datenaufzeichnung auf ein Minimum zu reduzieren. Ein erster Ansatz zur forensischen Arbeit im Rahmen der OpenFlow-Forensik ist daher, die Flows controllerseitig so anzupassen, dass die Daten zusätzlich zum Zielsystem auch an das Aufzeichnungssystem geleitet werden. [BBHHK14] nutzt zur Steuerung des Datenstroms einen zusätzlichen Controller parallel zum eigentlichen SDN-Controller und bezeichnet diese Technik als Deep-Packet-Inspection-as- a-Service. Hierbei leitet der zusätzliche Controller die relevanten Daten an spezielle Appliances, um so die mehrfache Analyse der Netzwerkdaten zu vermeiden.

Auch [RWJW13] nutzt mit FreeFlow und dem Split/Merge-Verfahren einen ähnlichen Ansatz, bei dem der SDN-Controller die Steuerung der Netzwerkdaten übernimmt. Die gleiche Thema- tik betrachtet auch [GPGA12] oder [QTC+13], der mit SIMPLE ein System vorstellt, welches Middleboxes und deren Aufgaben vereinfachen möchte. Auch [BBH+14] implementiert zusätzli- che Middleboxes, um mit deren Hilfe Zugriﬀ auf die internen Datenströme zu bekommen. Dabei wird mit Hilfe von OpenFlow-Regeln der relevante Datenverkehr zu den Middleboxes umgeleitet, um dort verarbeitet zu werden.

Alle Ansätze basieren jedoch auf der Umleitung der anfallenden Daten. Hierdurch verändert sich neben der Paketlaufzeit auch je nach Implementierung der Paketinhalt. Somit sind diese Techniken nicht für forensische Untersuchungen geeignet, da es hierbei auf die Unveränderlichkeit der Netzwerkpakete ankommt.

[RDKT13] verfolgt einen auf Angriffstechniken basierenden Ansatz, um die Netzwerkdaten zu kopieren. Mittels MITM-Angriff, durchgeführt mit Hilfe der Open Source-Software ettercap, erfolgt eine Manipulation der Controllerkonfiguration, um die anfallenden Netzwerkdaten zu spiegeln. Die eingesetzte Technik bezeichnen die Autoren dabei als Mirrorport, obwohl der Ansatz eher einer extern durchgeführten Manipulation als einem klassischem Mirrorport ähnelt.

[SG12] beschreibt die Implementierung einer Sicherheitslösung auf Basis des OpenFlow-Protokolls. Im ersten Schritt erfolgt die Analyse der zugrundeliegenden Netzwerkhardware, um losgelöst von der virtuellen Umgebung das Netzwerk als Graph darzustellen und für die weitere Verarbeitung zu nutzen. Anschließend werden existente Flows analysiert. Bei Zutreﬀen vorgegebener Kriterien wird der gesamte Netzwerkverkehr umgeleitet, um ihn an anderer Stelle detailliert untersuchen zu können.

180 8.2 Problemanalyse

8.1.2 Bewertung

Die existenten Ansätze zur netzwerkforensischen Arbeit in virtuellen Netzwerken haben das Ziel, Netzwerkdaten anhand unterschiedlicher Kriterien auszuwählen und diese weiterzuverarbeiten. Dabei hat die Auswahl und die Weiterverarbeitung in keiner der untersuchten Arbeiten das Ziel, den gesamten Datenverkehr eines Systems aufzuzeichnen.

Der Ansatz, die Daten mit Hilfe von MITM-Techniken umzuleiten, ist insgesamt zu ungenau, da bei Veränderungen im Netzwerk jedes Mal die Filter geändert werden müssen. Um hierbei die Veränderung oder Aufzeichnung nicht beabsichtigter Daten auszuschließen, muss der Filter gelöscht und neu angelegt werden.

Die Nutzung eines zusätzlichen SDN-Controllers hat zu starke Auswirkungen auf die interne Netzstruktur und kann daher ebenfalls nicht für forensische Arbeiten genutzt werden. Dies be- triﬀt ebenfalls Arbeiten, die mit den Middleboxen zusätzliche virtuelle Geräte in die Netzwerke einbringen, um mit diesen den Datenverkehr aufzuzeichnen. Auf den ersten Blick erscheinen die Middleboxen dabei wie TAPs, die auch bei traditionellen netzwerkforensischen Aufzeichnungen eingesetzt werden. Jedoch ist diese Umsetzung nicht nutzbar, da hierbei der Datenﬂuss erheblich verändert wird.

Die bisherigen Arbeiten zielen nicht auf eine forensische Auswertung der anfallenden Netzwerk- daten ab und bieten somit keine nutzbaren Implementierungsmöglichkeiten. Erst durch die Ent- wicklung eines neuartigen Ansatzes, der die Anforderungen der netzwerkforensischen Arbeit (vgl. Kapitel 5) erfüllt, ist eine vollständige Aufzeichnung der Daten möglich. Dieser Ansatz muss dabei sowohl existente und neue Flows beachten, die Netzwerkumgebung überwachen und ﬂexibel laufende Aufzeichnungen anpassen können.

Um eine geeignete Lösung zu entwickeln, erfolgt im Vorfeld eine Analyse möglicher Probleme.

8.2 Problemanalyse

Die gestiegene Komplexität in OpenFlow-Netzwerken bringt zusätzliche Probleme, deren Nicht- beachtung die Implementierung eines geeigneten Ansatzes erschweren. Daher erfolgt eine Analyse möglicher Probleme.

181 8 OpenFlow-Forensik

8.2.1 Vorhandene Flows

Ein OpenFlow-Switch erhält vom Controller die Regeln mitgeteilt, in welcher Form bestimmte Netzwerkpakete weitergeleitet werden sollen. Diese Regeln speichert der Switch in seiner Flow- Table. Treﬀen nun Netzwerkpakete ein, auf die Einträge aus der Flow-Table passen, führt der Switch die hinterlegte Aktion aus und beendet damit die Abarbeitung des Netzwerkpakets.

Solange er Einträge in seinen Flow-Tables findet, muss der Controller nicht kontaktiert werden. Somit ist ohne direkte Anpassung eine Aufzeichnung des Datenstroms, der bereits implementierten Flows entspricht, nicht möglich. [BAAZ11] beschreibt die Möglichkeit, Flows auf den jeweiligen Hosts zu identifizieren. [MVB13] stellt mit EMC2 eine flowbasierte Monitoringlösung für Cloud-Umgebungen vor. Beiden Ansätzen ist aber gemein, dass nicht die forensische Nutzung der Flows das Ziel ist, sondern nur Monitoringaufgaben erfüllt werden. So zielt der Ansatz nach [MVB13] darauf ab, die Funktionalität von NetFlow und sFlow zu nutzen, die Informationen zu sammeln und aufbereitet zur Verfügung zu stellen. Wie bereits in Abschnitt 4.10.2 gezeigt wurde, ist dieser Ansatz für forensische Untersuchungen nicht geeignet.

[SG12] ignoriert existente Flows zur Implementierung der Sicherheitslösung und analysiert nur auftretende Netzwerkpakete. Anschließend werden, unabhängig von existenten Flows, neue Flows konﬁguriert, um die Daten zu analysieren.

8.2.2 Komplexität der Flows

Die Form der Flows ist im OpenFlow-Standard deﬁniert, dennoch ist die Implementierung der Flows controllerabhängig. Listing 8.1 zeigt die installierten Flows von Floodlight, Listing 8.2 die gleichen Flows implementiert vom POX-Controller.

Listing 8.1: Extrahierte Flows, implementiert von Floodlight-Controller ovs−ofctl dump−flows s1 NXST_FLOW r e p l y ( x i d=0x4 ) : cookie=0x20000000000000, duration=4.386s, table=0, n_packets=6, n_bytes=532, idle_timeout=5, idle_age=0, priority=0,in _port=8, vlan_tci=0x0000 , dl_src=00:00:00:00:00:01, dl_dst=00:00:00:00:00:02 actions=output:4

cookie=0x20000000000000, duration=5.301s, table=0, n_packets=6, n_bytes=532, dle_timeout=5, idle_age=0,priority=0,in_port=4, vlan_tci=0x0000 , dl_src=00:00:00:00:00:02, dl_dst=00:00:00:00:00:01 actions=output:8

182 8.2 Problemanalyse

Listing 8.2: Extrahierte Flows, implementiert vom POX-Controller ovs−ofctl dump−flows s1 NXST_FLOW r e p l y ( x i d=0x4 ) : cookie=0x0, duration=4.776s, table=0, n_packets=5, n_bytes=490, idle_timeout=10,hard_timeout=30, idle_age=0, priority =65535, icmp,in_port=8, vlan_tci=0x0000, dl_src=00:00:00:00:0 0:01, dl_dst=00:00:00:00:00:02, nw_src=10.0.0.1, nw_dst=10.0.0.2, nw_tos=0, icmp_type=8,icmp_code=0 actions=output:4

cookie=0x0, duration=4.773s, table=0, n_packets=5, n_bytes=490, idle_timeout=10,hard_timeout=30, idle_age=0, priority =65535, icmp,in_port=4, vlan_tci=0x0000 ,dl_src=00:00:00:00:0 0:02, dl_dst=00:00:00:00:00:01, nw_src=10.0.0.2,nw_dst=10.0.0.1, nw_tos=0, icmp_type=0,icmp_code=0 actions=output:8

So setzt Floodlight spezielle Cookies, um die Pakete zuzuordnen, POX hingegen lässt diese Fel- der unberührt, deﬁniert dabei jedoch wesentlich genauer die anfallenden Netzwerkpakete. Diese unterschiedliche Herangehensweise an die Informationsfülle der installierten Flows verkompliziert die Auswertung der Flowtables und erhöht die Gesamtkomplexität im Netzwerk.

8.2.3 Controllerabhängigkeit

Da ein OpenFlow-Switch nur mit einem Controller verbunden ist, ist dieser Controller für die Konﬁguration des Switches zuständig. Somit müssen die Anpassungen auf diesem Controller stattﬁnden, um geeignete Aufzeichnungsprozesse zu implementieren.

Die Nutzung eines separaten Controllers für forensische Zwecke ist somit ausgeschlossen. Ei- ne solche Installation hätte den Vorteil, dass eine eindeutige Systemumgebung inklusive der genutzten Sprachen und OpenFlow-Versionen genutzt werden könnten, wodurch der gesamte Aufzeichnungsprozess enorm vereinfacht würde.

Die Installation eines solchen Controllers würde jedoch zu einem undeﬁnierten Zustand im Netz- werk führen, da eine vollständige Deckungsgleichheit der Regeln nicht erreicht werden kann [ASAH10]. Die nachträgliche, parallele Konﬁguration des OpenFlow-Switches an einen zweiten Controller ist ebenfalls nicht problemlos möglich, da diese nachträgliche Anbindung die erste Einstellung der Controlleranbindung überschreibt.

183 8 OpenFlow-Forensik

Eine Aktualisierung der Anbindung durch die Deﬁnition aller existenten und neuen Controller führt zum Löschen aller bereits implementierten Flows auf dem OpenFlow-Switch, wodurch kurzzeitig die gesamte Kommunikation stoppt und durch Anfordern der gültigen Regeln neu initialisiert werden muss. Schon dieser kurzzeitige Abbruch der laufenden Kommunikation ist aus forensischer Sicht nicht akzeptabel.

8.2.4 Ergebnis

Neben den in Kapitel 4 aufgeführten Schwierigkeiten der Netzwerkforensik in virtuellen Umgebun- gen entstehen in OpenFlow-basierten Netzwerken zusätzliche, anwendungsspeziﬁsche Probleme. Diese Probleme verhindern die Durchführung netzwerkforensischer Untersuchungen in diesen Umgebungen.

Die Analyse und Verarbeitung der Flows, die den Datenverkehr im Netzwerk steuern, ist bereits in verschiedenen Arbeiten untersucht worden, allerdings fehlt dabei immer der Aspekt der vollständigen Datenaufzeichnung. Besonders die Flows, die vom Controller an die angeschlossenen Switche geleitet werden, verkomplizieren die Untersuchung. Zum einen ist das Flowformat controllerspeziﬁsch, kann dabei jedoch noch zusätzlich durch den CSP angepasst werden. So- mit entstehen hier Probleme wie sie auch in Abschnitt 7.5.1.1 beschrieben wurden. Besonders kritisch ist die Existenz bereits implementierter Flows. Ein Ansatz zur Analyse dieser Flows ist bisher nicht untersucht worden, da meist auf der Basis von neuen Netzwerkdaten eigenständig Flows implementiert werden [SG12], [BRA10]. [BAAZ11] beschreibt zwar die Extraktion lokaler Flows, allerdings werden diese wiederum nicht manipuliert.

Eine nutzbare Umsetzung für die Untersuchungen in OpenFlow-Netzwerken verlangt somit die Entwicklung einer Möglichkeit, existente Flows global zu analysieren und geeignete Techniken zur Manipulation zu entwickeln.

8.3 Lösungsentwicklung

Die Analyse existenter Ansätze und die Beschreibung der zusätzlichen Probleme zeigt auf, dass für eine korrekte Durchführung einer netzwerkforensischen Arbeit in OpenFlow-basierten Netzwerken keine geeignete Implementierung bereitsteht.

Die im Folgenden vorgestellte Lösung nutzt die im VNFP beschriebene Aufteilung in verschiedene Phasen aus, um vollständige Mitschnitte der relevanten Netzwerkdaten zu erhalten.

184 8.3 Lösungsentwicklung

Um die relevanten Daten vollständig aufzuzeichnen, müssen die existenten Flows untersucht und klassifiziert werden. Vorher muss jedoch der korrekte OpenFlow-Switch identifiziert werden, da durch die in OpenFlow-Netzwerken vorherrschende Dynamik jederzeit Änderungen auftretenden können und eine einmalige Identifizierung zu Beginn nicht ausreichend ist.

Die Manipulation der Flow-Table kann durch Hinzufügen neuer Flows erfolgen, die den Kopier- prozess des gesamten Datenverkehrs an den Mirrorport etablieren. Nachdem der Kopierprozess installiert ist, muss das Monitoring gestartet werden, um sämtliche relevanten Änderungen im Netzwerk bemerken und reagieren zu können.

Bevor allerdings die Extraktion der Flows erfolgen kann, wird im Folgenden ermittelt, wie auf die Daten zugegriﬀen werden kann.

8.3.1 Evaluierung der Zugriﬀsmöglichkeit

Bisherige Ansätze zielen nicht auf die Ausleitung des gesamten Datenverkehrs ab. Um die Än- derungen im Netzwerk gering zu halten und gleichzeitig eine möglichst hohe Nutzbarkeit der Lösung zu ermöglichen, scheiden Ansätze wie im Abschnitt 8.1.1 beschrieben aus.

Um dennoch eine größtmögliche Nutzbarkeit zu erreichen, beschreibt [Ros91] die Nutzung des kleinsten gemeinsamen Nenners:

The impact of adding network management to managed nodes must be minimal, reﬂecting a lowest common denominator.

Dieser kleinste gemeinsame Nenner in OpenFlow-basierten Netzwerken ist das OpenFlow-Proto- koll, welches zwischen Controller und Switchen genutzt wird. Somit existieren drei mögliche Optionen zur Realisierung, die die eingesetzten Komponenten betreﬀen:

• Controller

• Switch

• OpenFlow

Andere Komponenten wie die VMs kommen mit OpenFlow nicht in Berührung und müssen somit nicht weiter beachtet werden.

Zur Realisierung existieren somit vier unterschiedliche Möglichkeiten, die im Folgenden untersucht werden.

185 8 OpenFlow-Forensik

8.3.1.1 Anpassung des eingesetzten Controllers

Der Controller als zentrale Stelle ist in der Lage, den Datenverkehr zu steuern und somit theoretisch auch die Ausleitung relevanter Netzwerkdaten durchzuführen. Die Vielzahl der eingesetzten Controller ermöglicht jedoch keine allgemeingültige Basis für gemeinsame Anpassungen, so dass für jeden Anwendungszweck neue Implementierungen bereitgestellt werden müssten.

8.3.1.2 Anpassung der eingesetzten OpenFlow-Switches

Die eingesetzten Switche verbinden die unterschiedlichen VMs und sind somit ein geeignetes Ziel für die Ausleitung der Netzwerke. In Abschnitt 7.4 wurde die Fähigkeit von OVS beschrieben, Mirrorports bereitzustellen. Eine mögliche Lösung umfasst somit die automatisierte Erstellung eines solchen Ports. Allerdings ist das OpenFlow-Protokoll nicht ausschließlich auf OVS begrenzt, auch hardwarebasierte Switche können OpenFlow-fähig sein. Somit ist analog zu den Controllern kein allgemeingültiger Ansatz möglich.

8.3.1.3 Erweiterung eingesetzten der OpenFlow-Version

Die häuﬁgsten eingesetzten Versionen sind OpenFlow 1.0 und OpenFlow 1.3, da diese von den meisten Switchherstellern unterstützt werden. Protokollerweiterungen dieser Versionen sind grundsätzlich möglich, aber für forensische Arbeiten nicht geeignet. Um die angepasste Versi- on einzusetzen, müsste diese auf alle OpenFlow-Systeme verteilt und alle weiteren involvierten Systeme angepasst werden.

8.3.1.4 Nutzung vorhandener Basisfunktionalitäten

Für die Kommunikation zwischen Controller und Switch wird immer eine eindeutige Version des OpenFlow-Protokolls genutzt. Sofern keine Anpassung dieser Version möglich ist, sind Kombi- nationen der Basisfunktionalitäten und -werkzeuge möglich, die die Ausleitung relevanter Daten ermöglichen. Das OpenFlow-Protokoll sieht jedoch als kleinsten gemeinsamen Nenner verschiedene Basisaktionen. Diese sind z.B. DROP, FORWARD oder FLOOD (vgl. Kapitel 2.4.2), die keine forensische Auswertung ermöglichen.

186 8.3 Lösungsentwicklung

8.3.1.5 Bewertung

Die Bestimmung geeigneter Implementierungen beschreibt vier unterschiedlichen Ansätze, die prinzipiell eine valide Aufzeichnung ermöglichen. Dabei sind die drei erstgenannten Techni- ken jedoch nicht für netzwerkforensische Arbeiten geeignet. Die Manipulation der eingesetzten OpenFlow-Version ist nicht realistisch, da unerwünschte Nebeneﬀekte nicht ausgeschlossen werden können. Darüber hinaus ist es meist nicht möglich, die Version auf hardwarebasierten OpenFlow-Switchen anzupassen. Die Anpassung des eingesetzten Controllers und Switches scheitert aufgrund der Vielzahl und Diversität der möglichen Konﬁgurationen.

Die Nutzung von Kombinationen der Basisfunktionalitäten ist somit die einzig mögliche Umset- zung, die überhaupt eine Implementierung netzwerkforensischer Arbeiten in OpenFlow-Netzwerken möglich macht. Dabei entspricht die Implementierung möglicher neuer Regeln dem proaktiven Ansatz nach [Fer13], bei dem die Regeln direkt in den OpenFlow-Switch implementiert werden, und nicht erst bei Bedarf bereitgestellt werden. Dieser Ansatz deckt sich ebenfalls mit dem allgemeinen Vorgehen der Netzwerkforensik, bei dem proaktiv Vorbereitungen getroﬀen werden müssen, um die Datenaufzeichnung bereitzustellen.

Im Folgenden können anhand der ermittelten Zugriﬀstechnik somit die weiteren Schritte durchge- führt werden. Der im Weiteren vorgestellte, mehrstuﬁge Prozess nutzt insgesamt vier Phasen, um eine vollständige Aufzeichnung zu ermöglichen und die im Abschnitt 8.2 beschriebenen Probleme beseitigen:

• Identiﬁkation der Switchinstanz

• Identiﬁkation der relevanten Flows

• Manipulation der Flow-Table

• Implementierung des Monitorings

8.3.2 Identiﬁkation der Switchinstanz

Um den korrekten Port zu identifizieren, müssen zuerst die vorhandenen Switch-Instanzen ermittelt werden. Nach dieser Identifikation können diese anschließend sequentiell untersucht werden, um das Zielsystem aufzufinden. Für diese Identifizierung stehen Informationen vom Controller und über die Schnittstelle der OVS-Instanz bereit.

187 8 OpenFlow-Forensik

8.3.2.1 Controllernutzung

Je nach Konﬁguration der Umgebung ist es möglich, die unterschiedlichen Instanzen von Swit- chen abzufragen. Dabei sind die Möglichkeiten immer controllerspeziﬁsch und lassen sich nicht unmittelbar auf andere Systeme übertragen.

Die Webcore-Komponente von POX bietet per curl und dem web.webcore-Modul die Möglichkeit, die verbundenen Switche anzuzeigen. Da die web.webcore Komponente jedoch beim Instanzstart nicht mit gestartet wird, ist eine Abfrage der angeschlossenen Geräte über den oben aufgeführten Befehl nicht immer erfolgreich.

Floodlight hingegen bietet mit dem Interface IOFSwitchService eine Schnittstelle zur Auﬂistung verbundener Switche.

Dabei unterscheidet sich nicht nur die Abfrage der Daten, auch das Ausgabeformat ist unterschiedlich und somit für eine zeitnahe Weiterverarbeitung nicht geeignet.

8.3.2.2 Extraktion zur Laufzeit

Informationen über die angeschlossenen OVS-Instanzen lassen sich controllerunabhängig auch über die OVS-Schnittstelle abfragen. Die relevante Information steht in der Tabelle Bridge der OVS-Instanz und kann per Wrappertool ovs-vsctl (vgl. Kapitel 7.1.1.1) abgefragt werden. Als Ergebnis erhält man die in Listing 8.3 gekürzt aufgeführten Informationen der hinterlegten vS- witches.

Listing 8.3: Controllerunabhängige Extraktion von Switch-Informationen zur Laufzeit ovs−vsctl list Bridge _uuid :f0e25b9b −7293−4e2f −8ad0−f3e6c254088c controller : [f382c95d−bec0−4a6b−9df6 −1bf6411bc0f5 ] datapath_id : "0000000000000001" fail_mode : secure mirrors :[] name :"s1" netflow :[] other_config : {datapath−id="0000000000000001", \ disable −in −band="true"} ports :[0f977b6f −f20a −4ab3−a63d−f411795e0ff2 ,\ 19247f2b −4b79−4316−9d7a−cbfa14a9bfe8] stp_enable : false

188 8.3 Lösungsentwicklung

8.3.3 Identiﬁkation der relevanten Flows

Nachdem die existenten Instanzen extrahiert wurden, müssen relevante Flows ermittelt werden. Als relevant gelten dabei alle Flows, die Bezug zum Zielsystem haben. Dabei ist es neben einer korrekten Aufzeichnung ebenfalls wichtig, die laufende Kommunikation so wenig wie möglich zu stören. Dies bedeutet, dass zuerst die aktuellen Flows extrahiert werden müssen, um diese anschließend zu bewerten. Durch diese Bewertung können die Flows ermittelt werden, die direkte Auswirkung auf das Zielsystem haben und daher in geeigneter Form angepasst werden müssen. Nur so ist weiterhin die korrekte Abarbeitung der Netzwerkpakete und zeitgleich die Weiterverarbeitung für forensische Zwecke gewährleistet.

8.3.3.1 Extraktion

Die Extraktion aktueller Flows eines OpenFlow-Switches muss auf der jeweiligen Instanz erfolgen, da ein Controller nicht unbedingt sämtliche zugewiesenen Flows speichert (vgl. Kapitel 8.2.1). Anhand der in Kapitel 7.1.1.1 vorgestellten Wrappertools kann eine Extraktion der vorhandenen Flows, wie in Listing 8.4 dargestellt, durchgeführt werden.

Listing 8.4: Extraktion gültiger Flows aus vSwitch ovs−ofctl dump−flows s1 NXST_FLOW r e p l y ( x i d=0x4 ) : cookie=0x0, duration=1.207s, table=0, n_packets=1, n_bytes=14, idle_timeout=10, hard_timeout=30, idle_age=0, priority=65535,icmp, in_port=3,vlan_tci=0x0000 , dl_src=00:00:00:00:00:02, dl_dst=00:00:00:00:00:01, nw_src=10.0.0.2 nw_dst=10.0.0.1,nw_tos=0, icmp_type=0,icmp_code=0 actions=output:1

cookie=0x0, duration=7.248s, table=0, n_packets=1, n_bytes=42, idle_timeout=10, hard_timeout=30, idle_age=7, priority=65535,arp , in_port=3,vlan_tci=0x0000 , dl_src=00:00:00:00:00:02, dl_dst=00:00:00:00:00:01, arp_spa=10.0.0.2, arp_tpa=10.0.0.1,arp_op=1 actions=output:1 cookie=0x0, duration=5095.972s, table=0, n_packets=2854 , n_bytes=275044, idle_age=0, in_port=1 actions=output:2

Die extrahierten Flows beinhalten sämtliche Informationen, die aktuell in einer Switch-Instanz gültig sind. Anhand dieser Daten kann die weitere Aufbereitung durchgeführt werden.

189 8 OpenFlow-Forensik

8.3.3.2 Aufbereitung

Eine Identiﬁkation der korrekten vSwitch-Instanz ist somit ebenso wie die Ermittlung gültiger Flows möglich, ohne dass auf hersteller- oder versionsbezogene Besonderheiten geachtet werden muss. Die Informationen der extrahierten Flows sind ausreichend, um hiervon ausgehend eindeutige Verarbeitungsentscheidungen treﬀen zu können. Somit können die Flows zerlegt werden, um die einzelnen Parameter zu extrahieren und für die spätere Anpassung zu nutzen. Dabei müssen diese Daten extrahiert werden, so dass alle relevanten Informationen bestehen bleiben, unwichtige Informationen jedoch nicht die weitere Bearbeitung stören.

Da die Switche für die Weiterleitung der Pakete MAC-Adressen, VLAN-IDs und teilweise auch IP-Adressen benutzen, müssen diese Daten extrahiert werden. Ebenso sind Prioritäten und die durchzuführenden Aktionen wichtig. Tabelle 8.1 listet die relevanten Parameter eines Flows auf. Die nicht aufgeführten Parameter sind protokollspeziﬁsch und nicht unmittelbar für die Aufzeich- nung der Daten relevant.

Tabelle 8.1: Relevanz der Parameter von OpenFlow-Flowentries Parameter Bedeutung Relevanz Cookie Identiﬁkator gering Duration Dauer der Flowexistenz gering Table NummerderFlow-Table hoch n_packets AnzahlderübertragenenPakete gering n_bytes AnzahlderübertragenenBytes gering Idle_timeout Dauer in Sekunden, nach denen ein Flow entfernt wird, wenn mittel er nicht benutzt wird Hard_timeout Dauer in Sekunden, nach denen der Flow entferntwird mittel Idle_age Dauer in Sekunden, die der Flow nicht benötigt wurde gering Priority Priorität des Flow-Entries hoch Protocol übertragenes Protokoll gering In_port logischerPortaufOpenFlow-Switch hoch Vlan_tci VLAN-ID mittel Dl_dst Ziel-MAC hoch Dl_src Quell-MAC hoch Nw_src Quell-IP hoch Nw_dst Ziel-IP hoch Actions Auszuführende Aktion hoch

Dabei sind nicht alle Parameter in jedem Flow existent, so dass dynamisch im Bedarfsfall entschieden werden muss, welche Parameter genutzt werden müssen.

190 8.3 Lösungsentwicklung

8.3.4 Flowmanipulation

Nach der Identiﬁkation der Instanz und der relevanten Flows kann aufbauend auf diesen Daten die Manipulation der Flows erfolgen. Diese Manipulation umfasst zum einen die Implementierung des Kopiervorgangs als auch die Anpassung unterschiedlicher variabler Werte wie Timeouts oder Prioritäten. Allerdings muss die Manipulation der Flows weiterhin die Konsistenz ermöglichen. [ASAH10] beschreibt die Gefahr von widersprüchlichen Flows, die parallel im Netzwerk existieren.

8.3.4.1 Manipulation der Aktion

Eine vollständige Aufzeichnung der Daten umfasst sowohl die gesendeten als auch die empfangenen Daten. Die detaillierte Steuerung des Datenverkehrs ermöglicht eine speziﬁsche Anpassung der Flows, wodurch bei der Manipulation sowohl auf die Empfangs- als auch auf die Senderich- tung geachtet wird.

• Ingress Pakete, die das Zielsystem empfangen soll, werden im Folgenden als Ingress-Pakete bezeichnet. Diese Ingress-Pakete können direkt durch die Manipulation der Flows an das Aufzeichnungssystem weitergeleitet werden. OpenFlow ermöglicht durch Konkatenieren unterschiedlicher Aktionen die Steuerung der Daten an mehrere Interfaces.

Als Filterkriterium kann dabei der vPort des Systems, der im Parameter in_port hinterlegt ist oder der eindeutige Identiﬁkator des Zielsystems genutzt werden. Als Ausgabe wird dann sowohl der vPort der VM und der vPort des Aufzeichnungssystems deﬁniert.

• Egress Die vorgenannte Regel umfasst jedoch noch nicht den vom System mit dieser MAC-Adresse ausgesandten Datenverkehr. Diesen Datenverkehr bezeichnen wir im Folgenden als Egress- Pakete.

Einige Arbeiten beschreiben die Fähigkeit von OpenFlow, Pakete zu kopieren und deuten damit eine forensische Nutzung dieser Fähigkeit an. Die Fähigkeit von OpenFlow, Pakete zu kopieren, ist mit Hilfe der oben aufgeführten Konkatenierung der Ausgabeports tatsächlich gegeben. Allerdings ist diese Fähigkeit für Egress-Pakete nicht geeignet, da durch einen solchen Flow nicht auf die Quelle Bezug genommen werden kann.

Sofern man eine Kombination aus eindeutigem Quellidentiﬁkator wie der MAC-Adresse und einem Ausgabeport wählt, bricht die Kommunikation zusammen, da die Netzwerkdaten vom originären Zielsystem nun immer an den Ausgabeport und nicht an das tatsächliche Ziel geschickt werden.

191 8 OpenFlow-Forensik

Grundsätzlich ermöglicht die Standardaktion NORMAL eine Weiterleitung der Egress- Pakete. Die Aktion NORMAL legt fest, dass der OpenFlow-Switch das Paket ohne weitere Anpassungen in der Standardeinstellung der OSI-Schicht 2 behandelt. Diese Einstellung lässt den OpenFlow-Switch für diese Pakete wie einen Hub agieren, der die Pakete an alle angeschlossenen Netzwerkgeräte weiterleitet, wo sie mitgelesen werden können. Dieses Verhalten verhindert somit die Nutzung der Aktion NORMAL für die forensische Aufzeich- nung.

Zur Datenaufzeichnung der ausgehenden Pakete muss daher eine Anpassung der Regeln erfolgen, die es ermöglicht, alle abgehenden Daten ebenfalls an das Aufzeichnungssystem zu leiten. Da die Quell-MAC-Adresse hierfür nicht ausreichend ist, wird mit Hilfe des Tupels Quell-MAC und Ziel-MAC ein eindeutiger Flow deﬁniert, der über eine höhere Priorität als der Ursprungsﬂow verfügt. Der Flow hat als Aktion die Weiterleitung an den Originalziel- port und an den Port der Aufzeichnungs-VM. Hierdurch werden die Daten korrekt an das Zielsystem geleitet und können zusätzlich am Aufzeichnungssystem aufgezeichnet werden.

Die Beachtung der Ingress und der Egress-Flows ermöglicht bei korrekter Manipulation die voll- ständige Ausleitung sämtlicher Daten des Zielsystems ohne die Kommunikation im Netzwerk zu unterbrechen oder merklich zu verzögern.

8.3.4.2 Manipulation der Variablen

Neben der Einrichtung des Kopiervorgangs sind zusätzliche Parameter der Flows relevant. Diese Parameter sind variable Werte, die controllerseitig festgelegt oder aufgrund der realen Netzwerk- kommunikation entstehen. Diese Werte sind daher zur Laufzeit auszuwerten und anhand der aktuellen Werte anzupassen.

• Priorität Die Priorität eines Flows bietet einen zusätzlichen Entscheidungsparameter, falls ein Netz- werkpaket auf mehrere Flows zutriﬀt. In solchen Fällen wird der Flow mit der höheren Priorität genutzt [Ope14].

The packet is matched against the table and only the highest priority flow entry that matches the packet must be selected. The counters associated with the selected flow entry must be updated and the instruction set included in the selected flow entry must be applied. If there are multiple matching flow entries with the same highest priority, the selected flow entry is explicitly undefined. This case can only arise when a controller writer never sets the OFPFF_CHECK_OVERLAP bit on flow mod messages and adds overlapping entries.

192 8.3 Lösungsentwicklung

Das entsprechende Feld in der Flow-Table umfasst 16 Bit, so dass ein Wertebereich von 0 — 65536 möglich ist. Der Wert von 0 entspricht dabei einem Table-Miss, der jedoch nicht in extrahierten Flows vorkommt, sondern nur für die interne Verarbeitung genutzt wird.

• Timeouts Die Flowfelder hard_timeout und idle_timeout legen fest, wie lange Flows im Switch verbleiben. Der Parameter idle_timeout regelt die Dauer, die ein Flow vorhanden bleibt, falls kein Treﬀer für diesen Flow erfolgt. Hierdurch werden ungenutzte Flows nach einer Zeit der Inaktivität aus der Flow-Table gelöscht. Der Parameter hard_timeout löscht einen Flow auch, wenn Pakete auf ihn zutreﬀen.

8.3.4.3 Umsetzung

Im vorigen Abschnitt wurden die Parameter eines Flows anhand ihrer Wichtigkeit bewertet. Ausgehend von diesen Daten müssen die notwendigen Manipulationen durchgeführt werden. Diese umfassen:

• Hinzufügen des output-Ports des Aufzeichnungssystems Diese Anpassung betriﬀt sowohl Ingress- als auch Egress-Pakete. Dabei ist es ausreichend, an den Flow mit dem Ziel der überwachten VM den output-Port des Aufzeichnungssystems hinzuzufügen. So wird der Flow

cookie=0x0, duration=11965.378s, table=0, n_packets=10120 ,\ n_bytes=975632, priority=1,in_port=1,dl_dst=00:00:00:00:00:03 \ actions=output:2

durch Manipulation zu

cookie=0x0, duration=11965.378s, table=0, n_packets=10120,\ n_bytes=975632, priority=1,in_port=1,dl_dst=00:00:00:00:00:03 \ actions=output:2,3

geändert. Für den Egress-Port mit Paketen an die MAC-Adresse 00:00:00:00:00:02 wird für jede bekannte MAC-Adresse auf dem OpenFlow-Switch ein separater Flow erstellt. Dabei wird als zusätzliches Kriterium die Quell-MAC-Adresse hinzugefügt. Durch diese Änderung wird der Flow

cookie=0x0, duration=1604.682s, table=0, n_packets=0, n_bytes=0,\ priority=0,dl_dst=00:00:00:00:00:02 actions=output:4

193 8 OpenFlow-Forensik

cookie=0x0, duration=1604.682s, table=0, n_packets=0, n_bytes=0,\ priority=2,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02 \ actions=output:3,output:4

• Inkrementierung der Priorität Durch Erhöhung der Flow-Priorität ist sichergestellt, dass die neu hinzugefügten Flows bei gleicher Wertigkeit genutzt werden.

Durch Inkrementierung der Priorität um 1 erhält der folgende Flow

cookie=0x0, duration=24.655s, table=0, n_packets=0, n_bytes=0,\ priority=100,dl_dst=00:00:00:00:00:72 actions=output:2

eine neue Priorität von 101 und wird bei gleichzeitiger Anpassung des Ziels zu

cookie=0x0, duration=13.2224s, table=0, n_packets=0, n_bytes=0,\ priority=101,dl_dst=00:00:00:00:00:72 actions=output:2,3

• Beachten der Timeouts Bei den Timeouts muss darauf geachtet werden, die korrekten Werte zu extrahieren und bei der Flowmanipulation zu übernehmen. Hierdurch ist dann gewährleistet, dass die Flows entfernt werden, wenn die entsprechenden Timeouts abgelaufen sind. Der idle_timeout ist dabei kritisch, da der ursprüngliche Flow nach Manipulation der Aktion und der Prioritäten nicht mehr aufgerufen wird und somit nach Ablauf des idle_timeouts gelöscht wird. Der zugehörige manipulierte Flow kann jedoch weiterhin in der Flow-Table existieren. Dieses Verhalten ist jedoch unkritisch, da die Existenz des manipulierten Flows relevant ist; wenn dieser Flow durch den idle_timeout entfernt wird, wird ein neuer, ursprünglicher, Flow angelegt, der erneut manipuliert werden kann.

8.3.5 Überwachung

Wie in Abschnitt 7.5 beschrieben, ist die einmalige Implementierung einer Aufzeichnung in virtuellen Netzwerken nicht ausreichend. Daher muss auch in OpenFlow-Netzwerken eine Möglichkeit zur Verfügung stehen, um die Umgebung auf Änderungen zu überwachen und geeignete Anpas- sungen zu implementieren.

Die durchzuführende Reaktion muss dabei zeitnah ausgeführt werden, um die mögliche Diﬀerenz zwischen Änderung der VMt und VMa so gering wie möglich zu halten. Somit muss die Anzahl

194 8.3 Lösungsentwicklung der durchzuführenden Aktionen zur Anpassung des Aufzeichnungsprozesses auf ein Minimum reduziert werden, da die Änderung vieler Komponenten mit steigender Anzahl der Regeln ebenfalls zunimmt. Der von [BMP10] beschriebene Ansatz ist daher ungeeignet. Hier wird zeitgesteuert die Extraktion von Flows durchgeführt, um so Änderungen festzustellen. Da eine Änderung der Flows jedoch jederzeit erfolgen kann, ist jede ausschließlich periodisch durchgeführte Überprüfung nicht geeignet.

Ein intervallbasierter Ansatz ist für statistische Zwecke und Langzeitmonitoring gut geeignet, um Änderungen über einen vorgegeben Zeitraum festzustellen [Bar08]. [VADK14] beschreibt einen solchen Ansatz für OpenFlow-Netzwerke, in dem die beteiligten OpenFlow-Switche zeitgesteuert abgefragt werden und die ermittelten Werte für das Monitoring genutzt werden.

Für eine Echtzeitüberwachung ist ein solcher Ansatz nicht geeignet, so dass die Extraktion der Daten losgelöst von vorgegebenen zeitlichen Parametern erfolgen muss. Allerdings ist die Spei- cherung und nachträgliche Analyse dieser Daten ebenfalls kein geeigneter Weg zur rechtzeitigen Reaktion auf mögliche Änderungen. [Pax99] beschreibt daher eine Überwachung unmittelbar an der relevanten Quelle sowie die Analyse dieser Daten parallel zur weiterhin durchgeführten Überwachung. Die Analyse und Bewertung der Daten erfolgt dabei nicht durch den Aufzeich- nungsprozess, sondern durch eine separate Analysekomponente. So kann die Überwachung weiter durchgeführt werden, die Bewertung der Daten erfolgt parallel.

Nach der ersten Implementierung der Aufzeichnung wird daher die Phase des Monitoring aktiv, die das Netzwerk auf Änderungen überwacht. Zu relevanten Änderungen zählen globale Vorgänge im Netzwerk, die Auswirkungen auf die Aufzeichnung der Daten haben. Diese sind:

• Hinzufügen oder Entfernen von Switchen

• Hinzufügen oder Entfernen von Ports

• Flowänderungen auf den überwachten Switchen

Die nutzbaren Informationen über diese Änderungen werden auf unterschiedlichen Systemen im Netzwerk bereitgehalten. Im Folgenden werden die möglichen Stellen analysiert und hinsichtlich ihrer Eignung bewertet.

8.3.5.1 Logﬁles

In den Logﬁles des Cloud-Controllers sowie der beteiligten Komponenten werden alle Informatio- nen gespeichert. Logdateien sind in der Forensik eine anerkannte Quelle für Informationen, durch die wesentliche Informationen zu Sachverhalten gewonnen werden können [CSP12], [Cas11]. Das

195 8 OpenFlow-Forensik folgende Listing zeigt den Logeintrag des Floodlight-Controllers beim Herunterfahren des Inter- faces s1-eth1, welches die interne Portnummer 8 trägt.

2016-06-03 11:34:03.223 WARN [n.f.c.i.C.s.notification]\ Switch 00:00:00:00:00:00:00:01 port s1-eth1 changed: DOWN 2016-06-03 11:34:03.591 INFO [n.f.d.i.Device] updateAttachmentPoint: \ ap [AttachmentPoint [sw=1, port=8, activeSince=1464978814694, \ lastSeen=1464978814792]] newmap null

Andere Controller wie POX oder Ryu protokollieren dies jedoch gar nicht, sondern aktualisieren ihre Informationen erst beim Neustart des Interfaces.

Diese ungleiche Behandlung von Events verhindert die reale Nutzung der Logﬁles für forensische Zwecke. Zwar ist grundsätzlich das Format anpassbar, dies bedarf jedoch einer Anpassung der Systemumgebung mit gleichzeitiger Veränderung der Controllerkonﬁguration. Somit ist diese Da- tenquelle nicht für die weitere Analyse geeignet und kann nicht für die forensische Untersuchung genutzt werden.

8.3.5.2 Controllerkommunikation

Der Controller verwaltet alle Informationen, die für die logische Steuerung der Daten notwendig sind. Die Kommunikation der hieraus entstehenden Regeln erfolgt über einen verschlüsselten Kommunikationsweg, so dass diese Daten nicht von Unbeteiligten eingesehen werden können [SSHC+13]. Um im Rahmen der forensischen Ermittlung möglichst wenige Änderungen an der Gesamtumgebung vorzunehmen, ist eine Manipulation dieser Verschlüsselung nicht geeignet, um die Daten zu extrahieren. Diese Verschlüsselung verhindert somit die Nutzung für forensische Zwecke, so dass der Datenverkehr des Controllers für die Reaktion auf Änderungen im Netzwerk nicht genutzt werden kann.

8.3.5.3 Monitoring der Flows

Zielführend ist es daher, direkt auf dem OpenFlow-Switch die Änderungen zu überwachen. Mehrere Arbeiten beschäftigen sich mit dem Monitoring von OpenFlow-Umgebungen [BMP10], [VADK14]. Für die Überwachung werden dabei existente Techniken wie Netﬂow oder sFlow genutzt, diese Daten beinhalten aber nicht ausreichend Informationen über die oben beschriebenen Ereignisse. Daher sind die gewählten Techniken nicht für forensische Untersuchungen geeignet.

196 8.4 Implementierung

Für diese Zwecke ist es daher möglich, die Monitoringimplementierung von vSwitchen zu „ent- fremden“, die vorrangig für das Debugging und Testen neuer Applikationen vorgesehen ist. Die hierbei zur Verfügung gestellten Informationen sind jedoch aus den folgenden Gründen nicht unmittelbar für eine forensische Untersuchung geeignet:

• Informationsfülle Die Monitoringinformationen sind für Debuggingzwecke vorgesehen, daher ist die Informa- tionsdichte extrem hoch. So führt ein Neustart einer vNIC zu einer Vielzahl von Debug- ginginformationen ohne direkten Bezug auf die forensische Auswertung.

• Keep-Alive-Meldungen Zwischen Switch und Controller werden Nachrichten vom Typ OFPT_ECHO_REQUEST ausgetauscht, um die Kommunikation zwischen den Komponenten aufrecht zu halten. Die entsprechenden Meldungen haben dabei die folgende Form:

OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload

Dabei kann eine solche Nachricht vom Controller zum Switch oder auch vom Switch zum Controller geschickt werden. Nach [Kin15] ist der übertragene Inhalt dieser Daten zufällig:

The OFPT_ECHO_REQUEST message contains an OpenFlow header followed by an undefined data field of arbitrary length. The data field might be filled with the timestamp at which the echo request message was sent, various length or values to measure the bandwith, or be zero-size for just checking the liveness of the connection. In most open source implementations of OpenFlow, the echo request message only contains the header field and doesn’t contain any body.

Diese Nachrichten besitzen somit keinen forensischen Wert und erschweren nur die Aus- wertung und Überwachung der Daten.

Obwohl die Monitoringumgebung auf Basis der OVS-Umgebung eine Vielzahl irrelevanter Daten produziert, ist diese Lösung dennoch am besten für die Überwachung der Umgebung geeignet. Mit Hilfe von Filtern und einer Klassiﬁzierung der Informationen ist es möglich, ausschließlich relevante Daten zu erhalten, die eine nutzbare Monitoringlösung ermöglicht.

8.4 Implementierung

Die vorgestellte Lösung namens ForCon (Forensic Controller) bietet einen neuen Ansatz in der netzwerkforensischen Arbeit. Die Implementierung arbeitet controllerunabhängig an übergeord-

197 8 OpenFlow-Forensik neter Stelle im Netzwerk, ohne die Steuerung der Netzwerkdaten durch die Northbound-API zu stören. Hierdurch ist gewährleistet, dass die aktive Steuerung der Netzwerkdaten weiterhin durch die Anwendungen und Regeln der Administration durchgeführt wird. Die Implementierung zur Aufzeichnung relevanter Daten arbeitet dabei passiv hinsichtlich der Steuerung und reagiert nur bei klar deﬁnierten Ereignissen.

Der Zugriﬀ auf die OpenFlow-Switche und ihre Flows ist dabei von externen Systemen nicht direkt möglich. Die Kommunikation muss innerhalb des aufgebauten Kommunikationskanals stattﬁnden, so dass nur der verbundene Controller die benötigten Daten abfragen kann. Um die Unabhängigkeit von den eingesetzten Controllern jedoch zu bewahren, wird mit ForCon ein dedizierter Controller genutzt, der mit einem agentenbasiertes System ausschließlich die Flows der VMt manipuliert.

ForCon ist als PoC in Python objektorientiert entwickelt und bietet über verschiedene Schnitt- stellen die Möglichkeit zur Erweiterung. Durch die Entwicklung unterschiedlicher Klassen werden sowohl die Agenten als auch der Server als eigenständige Komponenten bereitgestellt und können somit unabhängig voneinander angepasst werden. Hierzu nutzt ForCon die folgenden Klassen:

• OFServer Diese Klasse implementiert die zentrale Serverkomponente.

• OFFlow Speicherung eines extrahierten Flows und der einzelnen Parameter.

• OFSwitch Speicherung von Informationen zu angeschlossenen vSwitchen.

• OFForensicFlow Manipulierte Flows werden separat durch diese Klasse verwaltet.

• OFPeerAgent Diese Klasse stellt die Funktionalitäten der Mirror-Agenten bereit.

• OFAgent Diese Klasse stellt die Funktionalitäten der SDN-Agenten bereit.

• OFClient Die Verwaltung der angeschlossenen Agenten erfolgt durch diese Klasse.

Abbildung 8.1 stellt das Klassendiagramm und die Komposition zwischen den Klassen graﬁsch dar. Aus Gründen der Übersicht sind nicht alle Methoden und Attribute der Klassen aufgeführt.

198 8.4 Implementierung

OFForensicFlow OFServer string OFClient OFClient OFAgent

src OFForensicFlow ¨ ¨ worker() ist OFPeerAgent port performTunnel() 1..n run() 1..n getForensicFlow() updateAll() updateAll() getDestination() setMirrorAgent() setMirrorAgent()

getSource()

¨ ¨ 1 OFPeerAgent tapname peer isMirror createMirror()

deleteMirror() ¨ OFFlow OFAgent prio OFForensicFlow d_mac OFSwitch s_mac updateFlows() d_ip sendMessage() s_ip 1..n manipulateFlow() table updateStatus()

output ¨ deleteFlows() extractFromString() monitoring() separateString() createTunnel() getSIP() extractFlows()

getDIP() ¨

1..n OFSwitch ip name getIP() getName()

Abbildung 8.1: Klassendiagramm ForCon

8.4.1 ForCon-Server

Der Server wird als zentrales System an beliebiger Stelle im Netzwerk bereitgestellt. Er benötigt keine OpenFlow-Informationen, -Anwendungen oder Controllerdaten. Alle notwendigen Informa- tionen übermitteln ihm die dezentralen Agenten, die über eine IP-basierte Anbindung mittels TCP mit dem Server kommunizieren.

Der Server benötigt daher nur die relevanten Informationen über das Zielsystem, im PoC ist dabei die Quell-MAC-Adresse ausreichend47. python OFServer.py -t MAC-Adresse -p PORT

47In Kombination mit der VLAN-ID oder einer VNI kann eine Eindeutigkeit erreicht werden.

199 8 OpenFlow-Forensik

Der Server ist in der Lage, mittels Threads mehrere Agenten parallel zu verarbeiten, so dass auf jedem Wirtssystem im überwachten Netz ein Agent betrieben werden kann.

8.4.2 Agenten

ForCon nutzt zwei verschiedene Arten von Agenten. Die Agenten übernehmen dabei genau deﬁnierte Aufgaben an dislozierten Systemen und kommunizieren über das Managementnetzwerk mit ForCon. Da die aktuelle Implementierung im Rahmen des PoC in Python umgesetzt wurde, ist eine separate Installation eines Agenten nicht notwendig. Den Agenten werden per Parameter die Verbindungsinformationen zu ForCon übergeben, so dass eine weitere Kommunikation möglich ist. python OpenFlowAgent.py -s SERVER-IP -p PORT

Die ForCon-Agenten implementieren anschließend die Listenerfunktion und übernehmen eine vordeﬁnierte Verarbeitung der anfallenden Daten.

ForCon betreibt dabei ein Client-Server-System, bei dem die Agenten als Clients gelten, die sowohl Nachrichten empfangen als auch senden können.

• SDN-Agent Die dezentralen Agenten werden auf den Hostingsystemen bereitgestellt. Aufgabe dieser Agenten ist die Überwachung aller lokal laufenden vSwitch-Instanzen des Wirtssystems sowie die Manipulation der Flows auf Anforderung. Der SDN-Agent übernimmt darüber hinaus auch die Erstellung eines Tunnels zum Mirror-Agenten.

• Mirror-Agent Der Mirror-Agent wird nur einmal im gesamten Netzwerk benötigt. Die von ihm bereitge- stellte vSwitch-Instanz verbindet das Aufzeichnungssystem mit dem Netzwerk, ohne eine Kommunikation zuzulassen. Erst bei Konﬁguration des Tunnels zum involvierten SDN- Agenten initiiert der Mirror-Agent den Mirrorport auf seiner vSwitch-Instanz. Diese Kon- ﬁguration bleibt bis zum Abschluss der netzwerkforensischen Arbeit bestehen, einzig der Tunnel wird angepasst.

Dadurch, dass ForCon keinerlei OpenFlow-Informationen direkt ermittelt, ist der Agent für die Extraktion der Daten und die Manipulation der Flows zuständig. Die Entscheidung über diese Steuerung übernimmt jedoch der ForCon, die Agenten haben nur rudimentäre Filteraufgaben, um den Server über relevante Daten zu informieren.

200 8.4 Implementierung

8.4.3 ForCon Protocol

Zur Kommunikation zwischen Controller und Agenten wird das TCP-basierte, eigens entwickelte ForCon-Protokoll (FCP) genutzt. FCP ist ein einfaches Klartextprotokoll, welches unterschiedliche Nachrichtentypen deﬁniert, die spezielle Aktionen auslösen. Tabelle 8.2 beschreibt diese Nachrichtentypen. Dabei stellt FCP ein Request-Response-Protokoll dar, welches von beteiligten Komponenten interpretiert werden kann.

Tabelle 8.2: Nachrichtentypen ForCon Typ Kürzel Aufgabe Richtung Connection C Information über Connect vom Agenten C → S an den Server Informational I InformationüberIdentiﬁer C → S Flow-Extraction F Auftrag,Flowszuextrahieren S → C Manipulation M Auftrag,Flowszumanipulieren S → C Event X Ein relevantes Event ist aufdem über- C → S wachten OpenFlow-Switch aufgetreten Update U BefehlanalleAgenten,denStatuszuak- S → C tualisieren Delete D Befehl an Agenten, die übermittelten S → C Flows zu entfernen Mirror-Agent V Informationen über Connect des Mirror- C → S Agenten Tunnel T AuftragzurErstellungdesTunnels S → C Announcement A Information für Ermittler oder weitere S → C Systeme

Zusätzlich deﬁniert ForCon unterschiedliche Statuscodes als Antwort auf Anweisungen. Anhand dieser Informationen ist es ForCon möglich, die weitere Verarbeitung zu steuern, Tabelle 8.3 listet die bisher vorgesehenen Codes auf.

Tabelle 8.3: Statuscodes ForCon Code Bedeutung 1 Flowmanipulation beendet 2 FehleraufvSwitch 3 Tunnelerstellung erfolgreich 4 Tunnelerstellung fehlgeschlagen

201 8 OpenFlow-Forensik

8.4.4 Ablauf

Nachdem der Agent auf dem Wirtssystem gestartet wurde, werden im ersten Schritt die verbundenen OpenFlow-Switche sowie die dazugehörigen Flows extrahiert und die Verbindung zum ForCon-Server hergestellt.

Anschließend übermittelt der Agent die extrahierten Flows per Informational-Message an den Server. Um die Netzlast auch hier zu minimieren, werden nur Informationen zur OpenFlow- Switch-Instanz sowie zu den eindeutigen Identifizierungsmerkmalen48 übermittelt. Der Server prüft diese Daten und gleicht sie mit den angeforderten Identifizierungsmerkmalen ab. Stellt der Server dabei eine Übereinstimmung fest, beauftragt er den Agenten, die entsprechenden Mani- pulationen vorzunehmen. Jeder neu hinzugefügte Flow erhält dabei einen für die Aufzeichnungen statischen Cookie als Identifikator, darüber hinaus kann die benötigte Löschung nicht mehr relevanter Flows über die Informationen der Klasse OFForensicFlows durchgeführt werden. Diese Informationen hält ForCon im PoC nur im flüchtigen Hauptspeicher, zur Absicherung ist eine persistente Speicherung der Daten in einer Datenbank möglich. Der objektorientierte Entwurf er- möglicht eine solche Erweiterung, die besonders im produktiven Einsatz einen enormen Mehrwert bietet.

Alle weiteren Wirtssysteme und OpenFlow-Switche werden von der weiteren Bearbeitung ausgeschlossen, bis Änderungen auftreten, die eine solche umfassende Überwachung wieder notwendig machen. Hierdurch wird die Systemlast auf ein Minimum reduziert.

Solange keine Änderungen am überwachten OpenFlow-Switch auftreten, ist die Aufzeichnung statisch und das Monitoring läuft nur für dieses System. Tritt nun ein Ereignis auf, welches Änderungen notwendig macht, informiert der Agent den Server durch den Nachrichtentyp Mo- nitoring, welcher ForCon über die geänderte Situation informiert. Der Server informiert nun alle angeschlossenen Agenten mittels Update-Nachricht über die Notwendigkeit des Statusupdates. Alle Agenten ermitteln nun wieder die Informationen über installierte Flows und melden diese Daten an den Server. Sofern der Aufzeichnungsprozess angepasst wird, können alte Flows anhand der statischen Identiﬁkatoren entfernt und neue Manipulationen vorgenommen werden. Zusätz- lich informiert ForCon den Ermittler mit Hilfe einer speziellen Nachricht vom Typ Announcement über die eingetreten Änderung. Hierdurch ist es dem Ermittler möglich, weitere Maßnahmen wie computerforensische Untersuchungen durchzuführen.

Relevante Flows werden durch Anpassung zusätzlich über den Tunnel zur VMa kopiert. Dabei ist es unerheblich, ob die VMt als Sender oder Empfänger der Daten aktiv ist, die Manipulation der Daten deckt weiterhin beide Bereiche ab.

48Im vorgestellten PoC sind dies Quell- und Ziel-MAC-Adresse.

202 8.4 Implementierung

Abbildung 8.2 stellt den Ablauf des Nachrichtenaustauschs und des Tunnelaufbaus schematisch dar.

SDN-Agent Server Mirror-Agent C V F

1 oder 2

T T

3 oder 4 3 oder 4

Datentransfer

Abbildung 8.2: Initialer Nachrichtenaustausch

Abbildung 8.3 zeigt den Ablauf des Nachrichtenaustausches, falls ein SDN-Agent eine Änderung im Netzwerk feststellt.

SDN-Agent 1 SDN-Agent 2 Server Mirror-Agent

X U U I I M

1 oder 2 D D T T

3 oder 4 3 oder 4

Datentransfer

Abbildung 8.3: Nachrichtenaustausch aufgrund einer Änderung im Netzwerk

Eine solche Änderung kann durch die Migration der VMt auftreten. In Abbildung 8.3 ist die

VMt dabei auf dem CN betrieben worden, der vom SDN-Agenten 1 überwacht wurde. Dieser bemerkt die Migration und informiert den Server per Nachrichtentyp X über die Änderung. Der Server informiert alle angeschlossenen SDN-Agenten (im Beispiel sind dies SDN-Agent 1 und SDN-Agent 2) per Nachrichtentyp U, dass die Informationen aktualisiert werden müssen. Die

203 8 OpenFlow-Forensik

Agenten teilen dem Server daraufhin per Informational-Nachricht I die Flows mit. Der Server identiﬁziert das System auf dem CN, der nun von SDN-Agent 2 überwacht wird und schickt diesem die entsprechenden Informationen per Manipulation-Nachricht M. Sofern der Agent im Erfolgsfall den Statuscode 1 zurückmeldet, weiß der Server, dass die Manipulation erfolgreich war. Daraufhin kann der bisher bestehende Tunnel zwischen der VMa und dem ursprünglichen CN per Delete-Nachricht D deaktiviert und ein neuer Tunnel zwischen der VMa und dem relevanten vSwitch auf dem neuen CN aufgebaut werden (per Tunnel-Nachricht T ). Wenn der Tunnel erfolgreich aufgebaut wurde (Statuscode 3), kann die Aufzeichnung erfolgen, da alle Daten der

VMt übermittelt werden.

8.5 Testumgebung

In OpenFlow-Netzwerken besitzt ein eingesetzter Switch keine Entscheidungshoheit über die Verarbeitung der Daten. Der verantwortliche Controller regelt den Datenverkehr, indem er die entsprechende Weiterverarbeitung vorgibt.

Die Testumgebung muss daher aus mehreren Komponenten bestehen:

• Controller

• OpenFlow-Switch

• Kommunikationsteilnehmer

• ForCon

Die Testumgebung besteht wie in Tabelle 8.4 aus drei virtualisierenden System auf Ubuntu Basis, welche die jeweiligen VMs hosten, einem physischen System, welches den OpenFlow-Controller bereitstellt und einem separaten System, welches ForCon nutzt. Alle Systeme sind über einen Layer 2-Switch miteinander verbunden. Bis auf die Aufzeichnungs-VM, welche mit Debian 8 bereitgestellt ist, sind sämtliche beteiligten Systeme mit Ubuntu 14.04.3 LTS installiert.

Abbildung 8.4 zeigt den Testaufbau.

204 8.5 Testumgebung

Tabelle 8.4: Testumgebung OpenFlow Hostname IP-Adresse MAC-Adresse Aufgabe Host1 172.16.12.128/24 00:0c:29:c8:8f:6f Hosting der VM und der OVS-Instanz s1 Host2 172.16.12.129/24 00:0c:29:c8:8e:ba Hosting der VM und der OVS-Instanz s2 Host3 172.16.12.140/24 00:4c:4a:a6:32:09 Anbindung der VMa VM1 10.0.0.11/24 00:00:00:00:00:01 Kommunikationssystem1 VM2 10.0.0.12/24 00:00:00:00:00:02 Kommunikationssystem2 VM3 10.0.0.13/24 00:00:00:00:00:03 Kommunikationssystem3 VM4 10.0.0.14/24 00:00:00:00:00:04 Kommunikationssystem4 VM5 10.0.0.15/24 00:00:00:00:00:05 Kommunikationssystem5 VM6 10.0.0.16/24 00:00:00:00:00:06 Kommunikationssystem6 Mirror - 00:00:00:00:00:99 Aufzeichnung der gespiegelten Netzwerkdaten Controller 172.16.12.70/24 00:0c:29:07:e3:bc OpenFlow-Controller ForCon 172.16.12.1/24 00:ad:11:da:f1:bd Zentrale ForCon-Instanz

brmon

Northbound-API Mirror

Host 3 ForCon

Controller FCP FCP OpenFlow

OpenFlow

s1 s2

VM1 VM2 VM3 VM4VM5 VM6 Host 1 Host 2

Abbildung 8.4: Testaufbau ForCon

Im ersten Schritt muss festgelegt werden, welches Identiﬁkationsmerkmal für die VMt genutzt wird. Sinnvoll ist die Nutzung der MAC-Adresse als Kriterium. Weiterhin muss festgelegt werden,

205 8 OpenFlow-Forensik auf welchem virtuellen Port die Aufzeichnungs-VM angeschlossen ist. Die Art dieser Ermittlung ist ﬂexibel und muss nicht standardisiert werden.

Diese Parameter können nun an den Server übermittelt werden, der ausgehend von diesen Daten die Aufzeichnung und Überwachung implementiert. python OFServer.py -t 00:00:00:00:00:05 -p 6668 ForCon instance created Searching for 00:00:00:00:00:05 on all connected agents

Durch den Start des Mirror-Agenten weiß ForCon, dass eine Aufzeichnung der Daten nun grund- sätzlich möglich ist. Erst hierdurch können die benötigten Tunnel erstellt werden, die den Trans- port der anfallenden Netzwerkdaten sicherstellen.

INFO: Server received data from agent: 172.16.12.140 send V Mirror agent 172.16.12.140 connected Global mirror agent activated on 172.16.12.140

Ein SDN-Agent meldet sich durch den Nachrichtentyp Connect am Controller an, direkt an- schließend fordert der Server die Extraktion installierter Flows an:

INFO: Server received data from agent: 172.16.12.129 send C Connection of agent 172.16.12.129 established, requesting flows

Der SDN-Agent übermittelt auf Anforderung alle extrahierten Flows an ForCon per Nachrich- tentyp Informational.

Server [172.16.12.1] send me F Get flows From s1

Flows extracted Send I;s1;00:00:00:00:00:05;00:00:00:00:00:03 to server Send I;s1;00:00:00:00:00:03;00:00:00:00:00:05 to server

Die ankommenden Informationen werden analysiert und, falls notwendig, anschließend spezielle Flows vom Typ OFForensicFlow deﬁniert. Diese Deﬁnition ermöglicht die saubere Zuordnung der erstellten Flows durch ForCon.

206 8.5 Testumgebung

INFO: Server received data from agent: 172.16.12.129 send I;s1;00:00:00:00:00:05;00:00:00:00:00:03 Got information of flows Forensic Flow established for SRC 00:00:00:00:00:05 , DST: 00:00:00:00:00:03 on port s1 Set identifier of target to: 00:00:00:00:00:05

Ist die Identiﬁkation der VMt möglich, wird zuerst ein VXLAN-Tunnel aufgebaut. Hierzu erhalten der SDN-Agent und der Mirror-Agent Kenntnis und erstellen den anhand der übermittelten Parameter den Tunnel. Im Beispiel wird der Tunnel zwischen vSwitch brmon auf 172.16.12.140 und s1 auf 172.16.12.129 erstellt.

T;172.16.12.140;brmon;172.16.12.129;s1;

Nach der Erstellung dieses Tunnels ist eine Aufzeichnung der Daten möglich, durch den Forensiker muss nur an der OVS-Instanz brmon eine ausreichend dimensionierte VMa angeschlossen werden.

Die dabei relevante OpenFlow-Portnummer des VXLAN-Tunnelports wird ermittelt und für die zukünftige Ingress- und Egressmanipulation verwandt. ForCon speichert diese Informationen und beauftragt im nächsten Schritt die Einrichtung der manipulierten Flows mittels Nachrichtentyp M. Dabei wird der Identiﬁkator und der beteiligte vSwitch mitgeteilt. Zur Kontrolle werden parallel immer die ausgeführten Kommandos ausgegeben.

Server [172.16.12.1] send me M;00:00:00:00:00:05;s1; Manipulate the flows on s1 to port 6 Establish mirroring from port 1 to port 6 on Switch s1 sudo ovs-ofctl -O OpenFlow10 add-flow s1 \ cookie=0x223243,priority=65535,dl_dst=00:00:00:00:00:05,action=output:1,6

Die Agenten stellen dabei sicher, dass sämtliche existenten Flows mit der betroffenen Identifika- tion (hier die MAC-Adresse) korrekt manipuliert werden. Ab diesem Zeitpunkt ist sichergestellt, dass alle betroffene Daten vollständig kopiert werden.

Gleichzeitig stellt der Agent sicher, dass die Überwachung auf diesen Komponenten aktiviert ist und relevante Daten an den ForCon-Server übermittelt werden. Durch die Parallelität dieser Überwachung und Manipulation ist sichergestellt, dass neue Flows, die das Zielsystem betreﬀen, erkannt und sofort angepasst werden. Die Datenaufzeichnung ist somit dauerhaft gewährleistet.

207 8 OpenFlow-Forensik

Die SDN-Agenten nehmen dabei Filteraufgaben wahr, so dass die Datenmenge zum Server reduziert werden kann. Hierzu gehören unter anderem die OFPT_ECHO_REQUEST Nachrichten, die keinerlei relevanten Informationen beinhalten.

Nach dem Start der Ausleitung über den VXLAN-Tunnel entsteht der in Abbildung 8.5 dargestellte logische Netzwerkaufbau:

brmon

ForCon Northbound-API FCP Aufzeichnungs-VM

Controller FCP FCP OpenFlow OpenFlow

s1 s2

Abbildung 8.5: VXLAN-Tunnel zur Datenausleitung

8.6 Bewertung

Im Abschnitt 8.2 wurden Probleme aufgeführt, die speziell für OpenFlow-basierte Netzwerke gelten. Hierbei handelt es sich um Herausforderungen, die je nach Herangehensweise auftreten und somit bei der Entwicklung von ForCon beachtet wurden. Dabei wurden diese Probleme, wie in Tabelle 8.5 aufgeführt, beseitigt.

ForCon beseitigt oder umgeht sämtliche Herausforderungen im Rahmen der OpenFlow-Forensik. Durch den hohen Automatisierungsgrad von ForCon verringert sich die Komplexität für den Forensiker, dessen Arbeit sich für der Aufzeichnung auf zwei Aspekte beschränkt. Zuerst muss die korrekte Anbindung der VMa an einen Switch erfolgen, der später vom Mirror-Agenten verwaltet wird. Anschließend muss nach Ermittlung des Zielsystems die Informationen an ForCon übergeben werden; die die Agenten erhalten nach dem Start mit den korrekten Verbindungsparametern die entsprechenden Informationen vom Server.

208 8.7 Zusammenfassung

Tabelle 8.5: Probleme der OpenFlow-Forensik Problem beseitigt Begründung ExistenteFlows * DieExtraktionderPrioritätenermöglicht eine Ma- nipulation der Flows ohne Änderung der existenten Flows. In Verbindung mit der Eindeutigkeit der für die Aufzeichnung hinzugefügten Flows ist es möglich, nach Abschluss der Aufzeichnung den Ur- sprungszustand wiederherzustellen. Komplexität * Die Automatisierung der Manipulationen reduziert die Komplexität für den Forensiker auf ein Mini- mum. Controllerabhängigkeit * ForCon arbeitet controllerunabhängig und ist somit universell einsetzbar.

ForCon verarbeitet durch die Extraktion existente Flows und kann aufgrund der Überwachung auch Veränderungen im Netzwerk erkennen. Durch die Nutzung der SDN-Agenten entsteht dabei eine Controllerunabhängigkeit, die ForCon für eine Vielzahl von Umsetzungen einsetzbar macht. ForCon nutzt hierfür mit den Basisaktionen des OpenFlow-Protokolls den kleinsten gemeinsamen Nenner zwischen Switch, Controller und ForCon. Herstelleranpassungen der OpenFlow-Aktionen sind zwar möglich, die Implementierung der Basisaktionen ist im OpenFlow-Protokoll jedoch vor- geschrieben [Ope14]. Durch die ausschließliche Nutzung der Basisaktionen ist somit sichergestellt, dass ForCon mit sämtlichen am Markt existenten Switchen und Controllern zusammenarbeiten kann.

8.7 Zusammenfassung

In diesem Kapitel wurde mit ForCon eine Lösung erarbeitet, die netzwerkforensische Aufzeich- nungen in OpenFlow basierten Netzwerken ermöglicht. Als besonderer Schwerpunkt galt dabei die Aufrechterhaltung der Datenaufzeichnung auch bei einer Migration der überwachten VM.

Zuerst wurden existente Arbeiten hinsichtlich ihrer forensischen Möglichkeiten untersucht. Da keine der untersuchten Arbeiten eine geeignete Basis bietet, wurde durch die Identiﬁzierung geeigneter Implementierungen untersucht, wie eine valide forensische Untersuchung durchgeführt werden kann.

In Anlehnung an das VNFP wurde dabei ebenfalls eine Aufteilung in Phasen vorgenommen. Diese Aufteilung umfasst die Identiﬁkation des beteiligten Switches, die Extraktion und Aufbe- reitung der Flows und die Manipulation der Flows zur Ausleitung der Daten. Jede Phase wurde

209 8 OpenFlow-Forensik hinsichtlich möglicher Lösungsszenarien untersucht, indem Datenquellen oder Implementierungs- möglichkeiten analysiert und bewertet wurden.

Die letzte Phase stellt eine Überwachung des Systems sicher, sodass Änderungen im Netzwerk erkannt werden und eine geeignete Reaktion erfolgen kann. Analog zu den Aufzeichnungstech- niken bei vSwitchen reicht auch in OpenFlow-basierten Netzwerken nicht die einmalige korrekte Implementierung einer Aufzeichnung aus. Daher muss auch hier die Überwachung der Umgebung implementiert werden, um eine vollständige Datenaufzeichnung zu garantieren. Bisher existierte keine Lösung, die diese Überwachung zeitgerecht, sicher und umfänglich durchführt, so dass in diesem Kapitel eine Überwachungsroutine erarbeitet und implementiert wurde. Die entwickelte Lösung ist somit in der Lage, anhand von relevanten Ereignissen eine Rekonﬁguration des Aufzeichnungsprozesses zu initiieren.

Als Ergebnis dieser Aufteilung wurde mit ForCon ein neuartiger Ansatz zur forensischen Auswer- tung OpenFlow-basierter Netzwerke dargestellt. Dabei bietet ForCon die notwendige Flexibilität, eingerichtete Aufzeichnungen zu überwachen und eigenständig anzupassen. Da eine Überwa- chung des gesamten Netzwerks aufwändig ist, fokussiert ForCon die Überwachung auf den relevanten OpenFlow-Switch, da nach dem Start der Aufzeichnung nur hier kritische Aktionen auftreten können. Tritt eine solche Aktion ein, erweitert ForCon automatisch die Überwachung auf das gesamte Netzwerk, jedoch wiederum nur solange, bis eine Fokussierung möglich ist.

Um dies bei weiterhin existenter Controllerunabhängigkeit zu erreichen, nutzt ForCon verteilte Agenten, die auf den Wirtssystemen bereitgestellt werden. Diese extrahieren die Informationen aus vSwitchen und leiten sie an ForCon weiter, der die Beauftragung der notwendigen Flowma- nipulationen vornimmt und die zielgerichtete Überwachung implementiert.

Dabei ist ForCon durch das Client-Server-Prinzip in der Lage, mehrere Agenten parallel zu verwalten und den gesamten Datenverkehr aus forensischer Sicht anzupassen. Die Kommunikation zwischen ForCon und Agenten erfolgt dabei durch das neu entwickelte, auf TCP basierende FCP, welches Nachrichtentypen und Statuscodes deﬁniert und dadurch die korrekte Abarbeitung der anfallenden Aufgaben sichert. Die im PoC entwickelten Agenten sind in der Lage, OVS-Instanzen zu überwachen. Agenten, die andere OpenFlow-fähige Switche überwachen, müssen somit nur in der Lage sein, das FCP zu interpretieren und die notwendigen Arbeiten wie Extraktion und Manipulation der Flows umzusetzen.

Einzig die eindeutige Identiﬁzierbarkeit muss durch den Forensiker sichergestellt werden. Im untersuchten Beispiel wurde die MAC-Adresse des Zielsystems genutzt, erweiterte Möglichkeiten sind durch die Nutzung von VLAN-IDs oder IP-Adressen möglich.

210 9 Evaluierung

Die vorgestellten Implementierungen zur netzwerkforensischen Analyse in virtuellen Netzwerken werden in diesem Kapitel evaluiert.

Sowohl ForCon als auch OVSF nutzen Open vSwitch-Instanzen zur Anbindung der Aufzeich- nungssysteme und für den Kopiervorgang mittels Mirrorports, so dass sie sich nur in der Flexi- bilität und Konﬁguration der Ports unterscheiden. Daher ist die Überprüfung der gemeinsamen Basis ausreichend.

Die Gültigkeit und Nutzbarkeit der Implementierungen hängen von der Korrektheit der aufgezeichneten Daten ab. Dies bedeutet, dass sämtliche Netzwerkpakete, die vom oder zum Zielsys- tem transferiert wurden, in gleicher Form auch am Aufzeichnungssystem vorhanden sein müssen. Unterscheiden sich diese Daten, sind die vorgestellten Implementierungen für netzwerkforensische Untersuchungen nicht geeignet.

Nach dem Beweis der Korrektheit wird im Weiteren überprüft, ob die Lösungen dem Vorgehen des VNFP entsprechen. Es wird dabei für jede Phase im VNFP geprüft, ob und in welcher Form OVSF und ForCon die Anforderungen erfüllen.

Zuletzt erfolgt in diesem Kapitel die Durchführung einer netzwerkforensischen Analyse in einer Cloud-Umgebung auf Basis von OpenStack. Als meistgenutzte Cloud-Umgebung bietet Open- Stack eine Vielzahl von Konﬁgurationsmöglichkeiten (vgl. Kapitel 2.2.3.1). Dabei wird aufgezeigt, dass es kein allgemeingültiges Vorgehen der Netzwerkforensik in virtuellen Umgebungen gibt, sondern situativ entschieden werden muss, welche Implementierung genutzt wird.

9.1 Korrektheit

Die Korrektheit der aufgezeichneten Daten ist für die netzwerkforensische Arbeit von elementarer Bedeutung. Werden falsche oder unvollständige Daten aufgezeichnet, ist eine korrekte Analyse der Daten nicht mehr möglich. Dabei geht es um den reinen Vergleich der übertragenen Daten, die tatsächlichen Inhalte werden bei diesem Vergleich nicht bewertet. Dies bedeutet, dass auch

211 9 Evaluierung die verschlüsselte Daten korrekt übertragen werden müssen, auch wenn diese bis auf die Extrak- tion der Metainformationen kaum zusätzliche Informationen liefern. Eine Analyse verschlüsselter Daten in Netzwerken wird unter Anderem in [Koc11] beschrieben. Da im Vorfeld einer netzwerkforensischen Arbeit selten Kenntnisse über die anfallenden Daten existieren, ist eine Einschränkung der Korrektheit nicht möglich, so dass alle übertragenen Daten zur Evaluierung genutzt werden.

Die Korrektheit der Implementierungen umfasst somit die Aspekte der Vollständigkeit und der Integrität. Diese beiden Werte sind von Umgebungsparametern abhängig, die die Aufzeichnung der anfallenden Daten erschweren. Um die Lösungen unter Beachtung dieser Umgebungsparame- ter evaluieren zu können, werden innerhalb einer Simulationsumgebung Testreihen durchgeführt, die die Korrektheit der Daten nachweisen.

9.1.1 Vollständigkeit

Der Nachweis der Vollständigkeit bezieht sich auf die Anzahl der Pakete, die aufgezeichnet wurden.

9.1.1.1 Testdurchführung

Der Beweis der Vollständigkeit ist dabei gegeben, wenn die Anzahl der aufgezeichneten Pakete denen der real übermittelten Pakete entspricht. Um einen Vergleich zu ermöglichen, werden innerhalb der Simulationsumgebung an unterschiedlichen Positionen des Netzwerks Aufzeichnungen vorgenommen. Dabei bezeichnet

• PA die Summe der aufgezeichneten Netzwerkpakete am Aufzeichnungssystem,

• PZ die Summe am Zielsystem,

• P P P P ... P Q = Q1 + Q2 + Q3 + + Qn als die Summe aller Pakete, die von anderen Systemen an das Zielsystem gesandt oder von diesem empfangen wurden.

Im ersten Schritt wird ermittelt, ob PZ = PA gilt, anschließend wird ermittelt ob PZ = PA = PQ gilt. Ist dies der Fall, ist der Beweis der Vollständigkeit erbracht.

Der tatsächliche Beweis ist jedoch Einschränkungen unterworfen, die die Anzahl der Pakete, die aufgezeichnet werden, verändern. Hierzu gehören:

• Fragmentierung Die Anzahl der Netzwerkpakete berechnet sich unter anderem am Fragmentierungsgrad der

212 9.1 Korrektheit

übertragenen Daten. Die Notwendigkeit der Fragmentierung resultiert aus der maximalen zu übertragenen Datenmenge eines einzelnen Netzwerkpakets. Diese als MTU bezeichnet Größe muss auf allen Systemen gleich sein, um die gleiche Anzahl von Netzwerkpakete zu erhalten. Unterscheidet sich die MTU, werden eventuell Pakete aufgeteilt, so dass mehr Netzwerkpakete entstehen, die übertragen werden müssen. Die nachträgliche, manuelle Zusammensetzung ermöglicht jedoch auch dann den Vergleich der übertragenen Daten.

• Aufzeichnungsstart Die Summe der aufgezeichneten Pakete unterscheidet sich bei einem reinen Vergleich der Netzwerkmitschnitte. Diese Diskrepanz entsteht durch die Aktivierung des Aufzeichnungs- prozessen vor der Einrichtung des Mirrorports. Durch diese Aktivierung erhält das Aufzeich- nungssystem Broadcastverkehr, der im Netzwerk auftritt. Durch Nutzung der eingesetzten Protokollierungsmöglichkeiten ist der vorab aufgezeichnete Datenverkehr jedoch erkennbar und kann aus der Berechnung ausgenommen werden.

• Managementverkehr In Netzwerken erfolgt selbst ohne benutzerinitiierte Kommunikation ein ständiger Aus- tausch von Netzwerkpaketen. Diese umfassen Broadcastverkehr wie Spanning-Tree-Daten oder ARP-Requests. Netzwerkgeräte mit aktiviertem IPv6-Stack produzieren mit Multi- castverkehr wie All-nodes49, All-Router 50 zusätzlichen Netzwerkverkehr, der zwar an alle Teilnehmer im Netzwerk geschickt wird, jedoch nur von Kommunikationspartnern beantwortet wird.

Abbildung 9.1 zeigt den genutzten Testaufbau, Tabelle 9.1 listet die Anzahl der Netzwerkpa- kete in den sechs durchgeführten Testszenarien auf. Die Testszenarien unterscheiden sich dabei ausschließlich in der Dauer der Aufzeichnung, der genutzte Testaufbau bleibt dabei unverändert. Während der Aufzeichnung wurden skriptgesteuert Netzwerkpakete erstellt und übertragen.

vSwitch

Abbildung 9.1: Testumgebung zur Evaluation

49Hierbei werden Pakete an die Multicastadresse ﬀ02::1 geschickt, wodurch sämtliche Clients im Netzwerk antworten. 50Hierbei werden Pakete an die Adresse ﬀ02::2 geschickt.

213 9 Evaluierung

Tabelle 9.1: Erste Messreihe zum Nachweis der vollständigen Paketaufzeichnung

Testreihe Dauer PZ PA PQ 1 10s 32 30 31 2 1m 1477 1481 1475 3 8m 13.150 13.123 13.099 4 30m 174.812 174.989 175.007 5 2h 2.304.375 2.303.961 2.304.019 6 8h 10.588.173 10.587.461 10.589.142

9.1.1.2 Problemanalyse

Die Messreihen zeigen, dass die Paketanzahl zwischen den beteiligten Komponenten nicht über- einstimmt. Dabei ist kein eindeutiges Muster erkennbar, woraus sich eine Fehleranalyse ergeben würde. Da die eingebrachte Paketanzahl jedoch durch die Automatisierung innerhalb eines Durch- laufs vordeﬁniert ist, sind andere Parameter, die das Aufzeichnungsergebnis verfälschen, möglich:

• Fehler im Programm

• Fehler in der initialen Einrichtung der Aufzeichnung

• Ungewollter Netzwerkverkehr

Fehler im Programmcode sind meist schwer festzustellen, zur Analyse wird auf Softwaretests zurückgegriﬀen [Lig02]. Zur Feststellung der gewünschten Funktionalität wird der Systemtest durchgeführt, der im Gegensatz zu anderen Testszenarien die Zusammenarbeit zwischen unterschiedlichen Modulen beinhaltet und das Gesamtsystem testet [SBS07]. Der Systemtest benötigt für ein korrektes Testergebnis eine wiederverwendbare Testumgebung sowie jeweils unveränderte Testdaten. Da die Eingabe der Daten skriptgesteuert erfolgt und somit reproduzierbar ist, erfüllen die Testdaten die notwendigen Anforderungen.

Die Durchführung der Aufzeichnung wird vollständig protokolliert, so dass eine Analyse der Ein- richtung des Aufzeichnungsprozesses auch nachträglich möglich ist. Dennoch ist es möglich, dass ein Fehler im Programm, der die korrekte Einrichtung verhindert, auch die parallele Protokol- lierung mit fehlerhaften Daten durchführt und somit das Gesamtergebnis verfälscht. Ein solcher Folgefehler lässt sich ebenfalls über einen Systemtest erkennen, da es hierbei auf das Zusam- menspiel zwischen den Komponenten ankommt. Singuläre Modultests sind hierfür nicht geeignet [Lig90].

[Bel00] beschreibt bei der Überwachung von Netzwerkdaten Probleme der Überlastung, wodurch Netzwerkpakete verworfen werden und somit die Anzahl der aufgezeichneten Pakete variiert. Dies

214 9.1 Korrektheit bezieht sich jedoch vorrangig auf Datenverkehr im Internet, welcher aufgrund zusätzlicher Stör- einﬂüsse größeren Übertragungsproblemen ausgesetzt ist. Die Aufzeichnung in virtuellen Netz- werken basiert jedoch auf, wenn auch nur logisch existenten, lokalen Umgebungen, in denen die eingesetzten Managementkomponenten wie VTEPs (vgl. Kapitel 2.3.2.2) für die korrekte Übertragung sorgen. Für die beteiligten Endgeräte verhält sich das Netzwerk tatsächlich wie ein LAN.

9.1.1.3 Verbesserung der Testumgebung

Eine Analyse der aufgezeichneten Daten weist unterschiedliche Pakete auf, die nicht in allen Aufzeichnungen vorkommen. Somit existiert auch innerhalb der Testumgebung Datenverkehr, der nicht an alle Geräte gleich übertragen wird. Dieser Datenverkehr verfälscht folglich den Vergleich der Aufzeichnungen und wird daher im Folgenden als Overhead bezeichnet. Um die Anzahl der real übertragenen Daten auf die deﬁnierte Anzahl ohne Overhead zu reduzieren, müssen die in Frage kommenden Netzwerkpakete analysiert werden, um so eine Reduktion zu ermöglichen.

Bei den abweichend aufgezeichneten Paketen handelt es sich um Daten, die gemeinhin als Netz- werkrauschen oder Network traﬃc radiation [WKB+10] bezeichnet werden. Dies sind Pakete, die im normalen Netzwerkverkehr vorhanden sind und eine grundlegende Interaktion der Kompo- nenten ermöglichen. Um diese Daten zu eliminieren, werden in der Testumgebung die folgenden Konﬁgurationen vorgenommen:

• Statische ARP-Einträge zur Minimierung von ARP-Requests

• Deaktivierung von IPv6-Datenverkehr

• Kein netzwerkbasierter Fernzugriﬀ auf die involvierten Systeme mittels SSH oder RDP, sondern nur über die Managementkonsole des Hypervisors

• Deaktivierung sämtlicher Managementprotokolle wie SNMP oder STP

• Statische Vergabe aller IPv4-Adressen

• Deaktivierung von ZeroConf-Diensten wie avahi-daemon oder Bonjour

Die Reduzierung des Overheads bereinigt die Testumgebung, so dass auch der Systemtest hiervon proﬁtiert.

Mit diesen geänderten Parametern werden die gleichen Testreihen erneut durchgeführt. Zur Absi- cherung wurde jede Testreihe dabei dreimal durchgeführt, um eventuell verbleibende Netzwerk-

215 9 Evaluierung schwankungen auszugleichen. Tabelle 9.2 zeigt die Anzahl der jeweils aufgezeichneten Pakete und beweist, nach Eliminierung des Overheads, die korrekte Aufzeichnung der Netzwerkdaten.

Tabelle 9.2: Nachweis der vollständigen Paketaufzeichnung

Testreihe Dauer PZ PA PQ 1 10s 30 30 30 2 1m 1470 1470 1470 3 8m 13.090 13.090 13.090 4 30m 174.772 174.772 174.772 5 2h 2.303.471 2.303.471 2.303.471 6 8h 10.586.462 10.586.462 10.586.462

Diese Testreihe wurde jedoch in vereinfachter Umgebung durchgeführt, um die grundlegende Vollständigkeit nachzuweisen. Dabei wurde neben dem Aufzeichnungssystem nur das Zielsystem und ein einzelnes Quellsystem als Kommunikationspartner eingesetzt.

Im zweiten Schritt erfolgt eine Überprüfung der Funktionalität mit steigender Anzahl von Quell- systemen. Eine Zunahme von Systemen im Netzwerk führt ohne Beachtung des oben aufgeführ- ten Overheads unweigerlich zu diﬀerierenden Paketmitschnitten. Die Limitierung im Testszenario verhindert dies jedoch, so dass auch die Analyse von maximal fünf direkten Kommunikations- partnern stabile Paketmitschnitte liefert. Tabelle 9.3 listet die Werte unterteilt nach Anzahl der Kommunikationspartner.

Tabelle 9.3: Paketmitschnitte bei steigender Clientanzahl Quellsysteme Anzahl PZ PA PQ PQ1 PQ2 PQ3 PQ4 PQ5 1 96.299 96.299 96.299 96.299 2 101.209 101.209 50.988 50.221 101.209 3 111.448 111.448 38.976 36.600 35.872 111.448 4 131.612 131.612 29.107 35.661 31.192 35.562 131.612 5 152.410 152.410 30.189 31.283 29.770 30.580 30.588 152.410

Auch dieses Szenario ist jedoch nur eingeschränkt mit realen Umgebungen zu vergleichen. In diesen Umgebungen sind unterschiedliche Parameter vorhanden, die die Aufzeichnung verän- dern oder verhindern können. Daher wurden die folgenden Parameter in weiteren Testszenarien angepasst, um eine realitätsnahe Umgebung zu erhalten.

216 9.1 Korrektheit

• Vielzahl von Einträgen in der CAM Die Konﬁguration der Mirrorports erfolgt bei OVSF durch die Analyse der CAM, die alle MAC-Adressen der aktiven Systeme speichert. ForCon hingegen nutzt Flowinformationen, um diese Daten zu extrahieren. Existieren sehr viele Einträge in der CAM oder in den Flows, kann die Analyse dieser Daten erschwert werden.

• Hohe Netzlast auf dem Wirtssystem Sofern das Wirtssystem sehr viele Daten übertragen muss, kann es zu Verzögerungen oder Paketverlusten kommen. Diese als Congestion beschriebene Problematik existiert bereits in klassischen Netzwerken [CC96] und kann auch in virtuellen Umgebungen zu abweichenden Paketmitschnitten führen.

• Hohe CPU-Last Die CPU ist in virtuellen Umgebungen für die Verarbeitung der anfallenden Netzwerkpakete zuständig. Der Einsatz des von STT (vgl. Kapitel 2.3.2.4) als Overlay-Protokoll ermöglicht eine Entlastung der CPU, da die Aufzeichnung der Daten jedoch an der vNIC erfolgt, ist das Overlay-Protokoll irrelevant. Durch die Erhöhung der CPU-Auslastung besteht die Gefahr, dass Netzwerkpakete nicht rechtzeitig verarbeitet und übertragen werden können, so dass die Paketmitschnitte Unterschiede aufweisen.

Die Auslastung des Aufzeichnungssystems ist dabei zu vernachlässigen, da dieses System aus- schließlich für die Aufzeichnung und Speicherung der anfallenden Daten genutzt wird, und somit keine weiteren Aufgaben erfüllt. Die Ergebnisse nach Anpassung der oben aufgeführten Parame- ter ﬁnden sich in Tabelle 9.4. Die Auslastung der verfügbaren Übertragungsrate wurde mit dem inux-Programm iperf in der Version 2.0.9.1 durchgeführt, das Linux-Programm stress (in der Version 1.0.4-4) ermöglicht die beliebige Anpassung der CPU-Auslastung und wurde daher zur Simulation einer vollständig ausgelasteten CPU genutzt. Mit Hilfe von Alias-Interfaces wurde eine große Zahl kommunizierender Systeme auf dem vSwitch simuliert, die Anzahl der Einträge in der CAM steigt so entsprechend an.

Die Auslastung der CPU verringert die Gesamtzahl der übertragenen Netzwerkpakete pro Se- kunde, führt jedoch zu keinem Paketverlust bei der Aufzeichnung. Eine Vielzahl von aktiven Einträgen in der CAM verhindert ebenfalls nicht die vollständige Aufzeichnung, da ein einmal eingerichteter Mirrorport für das Zielsystem nicht von diesen Daten beeinﬂusst wird. Eine er- höhte Netzlast des Systems hat keine Auswirkungen auf den Aufzeichnungsprozess, analog zur erhöhten CPU-Auslastung verringert sich der Gesamtdurchsatz. Dies ist nachvollziehbar, da die Berechnung einer Vielzahl von Netzwerkpaketen letztlich zu einer erhöhten Auslastung der CPU führt.

217 9 Evaluierung

Tabelle 9.4: Vollständigkeit in den Szenarien

Szenario Testreihe PZ PA PQ Abdeckung 1 31 31 31 100% 2 1381 1381 1381 100% CAM 3 13.128 13.128 13.128 100% 4 174.749 174.749 174.749 100% 5 2.303.561 2.303.561 2.303.561 100% 6 10.589.497 10.589.497 10.589.497 100% 1 25 25 25 100% 2 1145 1145 1145 100% Netzlast 3 10.575 10.575 10.575 100% 4 141.469 141.469 141.469 100% 5 1.870.880 1.870.880 1.870.880 100% 6 8.566.246 8.566.246 8.566.246 100% 1 26 26 26 100% 2 1190 1190 1190 100% CPU 3 10.599 10.599 10.599 100% 4 141.508 141.508 141.508 100% 5 1.870.926 1.870.926 1.870.926 100% 6 8.566.309 8.566.309 8.566.309 100%

9.1.2 Integrität

Die Integrität bezieht sich auf die aufgezeichneten Daten. Der Nachweis soll zeigen, dass die aufgezeichneten und die Originaldaten gleich sind. Ein solcher Nachweis erfolgt in forensischen Untersuchung mit Hilfe von Hashfunktionen, die eindeutige Hashwerte für die Dateien errechnen können.

Der Nachweis der Integrität kann somit durch den Hashwertvergleich der aufgezeichneten Mit- schnitte erfolgen. Dies gilt jedoch nur, wenn die Anzahl der aufgezeichneten Pakete gleich ist. Würden sich diese unterscheiden, wäre auch ein berechneter Hashwert unterschiedlich.

Listing 9.1 zeigt die errechneten Hashwerte für zwei Mitschnitte, die in der Testumgebung aufgezeichnet wurden. Die Datei mir.pcap wurde dabei auf dem Aufzeichnungssystem erstellt und beinhaltet die dort angekommenen Daten, die Datei vm4.pcap beinhaltet die Daten der VMt. Diese Mitschnitte beinhalten somit die gleichen Payload, dennoch unterscheiden sich die Has- hwerte.

218 9.1 Korrektheit

Listing 9.1: Hashvergleich der Mitschnitts md5 ∗ .pcap MD5 (mir.pcap) = 1065cc0bad4672265257ade174e5d2f5 MD5 (vm4.pcap) = b8481ab673ae699b70ef75ec691ac07c

9.1.2.1 Problemanalyse

Da im vorigen Abschnitt gezeigt wurde, dass auf dem Aufzeichnungssystem je nach Implementie- rung eine unterschiedliche Anzahl von Netzwerkpaketen gespeichert werden kann, ist ein solcher Vergleich per Hashwertberechnung über die erstellten Paketmitschnitte nicht zielführend. Auch wenn die Paketanzahl in den Mitschnitten gleich ist, besitzen die Dateien, wie in Listing 9.1 dargestellt, unterschiedliche Hashwerte. Somit muss es sich um Unterschiede in den einzelnen Frames handeln, die die Abweichung verursachen.

Frames werden durch Aufzeichnungssysteme in zwei Teile aufgeteilt, zum einen in Packet Data, der die Paketdaten beinhaltet, sowie separate Metainformationen des Frames, die im sogenannten Packet Header gespeichert werden [Har15]. Dieser Packet Header wird vom Aufzeichnungssystem hinzugefügt und umfasst 16 Byte, die die folgenden 4 Werte speichern:

• ts_sec bezeichnet den Zeitstempel, wann dieses Paket aufgezeichnet wurde

• ts_usec speichert den Oﬀset zum Zeitstempel

• incl_len speichert die Länge des aufgezeichneten Pakets

• orig_len bezeichnet die Länge des Originalpakets

Einer Mitschnittdatei ist darüber hinaus noch ein sogenannter Global Header vorangestellt, dieser beinhaltet Metainformationen des Aufzeichnungsprozesses und hat das folgende Format [Har15]:

• Magic Number, hierüber wird das Dateiformat und die Byte-Reihenfolge bestimmt. Aktuell ist die Magic Number 0xa1b2c3d4.

• Version_major und Version_minor bestimmen die Version des Dateiformats

• Timezone speichert die Diﬀerenz der Zeitstempel zur Referenzzeit Greenwich-Mean-Time (GMT).

• Sigﬁgs speichert theoretisch die Genauigkeit der Zeitstempel. In der Praxis ist dieser Wert immer 0.

219 9 Evaluierung

• Snaplen bezeichnet die Länge des aufgezeichneten Frames.

• Network deﬁniert den Typ des folgenden Paketheaders.

Dem Global Header folgen die gespeicherten Frames. Da sich die PDU innerhalb der Testumge- bung nicht verändern kann, bleiben nur die Metainformationen, die die Ungleichheit verursachen. Je nach gewähltem Aufzeichnungsformat ist der Detailgrad dieser Informationen unterschiedlich (vgl. Kapitel 2.6.3.2).

Hierzu gehört auch die Ankunftszeit des Pakets am Aufzeichnungssystem. Diese Ankunftszeit speichern Aufzeichnungssysteme als zusätzliche Information für jedes Paket ab. Dabei handelt es sich um keine Information, die das Netzwerkpaket eigenständig transportiert hat, daher ist diese Information im Rahmen der Evaluation zu vernachlässigen.

Die Zeitstempel können auf unterschiedliche Weise verglichen werden, für die skriptgesteuerte Verarbeitung bietet sich die CLI-Version von Wireshark an. Hier kann über den Parameter frame.time der Zeitstempel jedes Frames abgefragt werden. Der nachfolgende Vergleich in Lis- ting 9.2 zwischen den Mitschnitten auf dem Mirror (mir.pcap) und dem Zielsystem (vm4.pcap) zeigt eine Diﬀerenz von 0,6 Sekunden bei den Aufzeichnungen.

Listing 9.2: Extraktion Zeitstempel der einzelnen Frames tshark −r vm4.pcap −T fields −e frame.number −e frame.time 1 Dec 16, 2016 12:56:49.334244000 CET 2 Dec 16, 2016 12:56:49.334298000 CET 3 Dec 16, 2016 12:56:50.335448000 CET

tshark −r mir.pcap −T fields −e frame.number −e frame.time 1 Dec 16, 2016 12:56:49.990117000 CET 2 Dec 16, 2016 12:56:49.991058000 CET 3 Dec 16, 2016 12:56:50.991826000 CET

Zur korrekten Prüfung der Integrität muss also eine Methode genutzt werden, die keine Rücksicht auf Zeitstempel nimmt. Darüber hinaus muss nicht nur der Global Header entfernt werden, auch jeder Packet Header muss analysiert und aufgeteilt werden, um auf die PDU zugreifen zu können.

Mögliche Implementierungen hierfür ﬁnden sich im Bereich der Deduplizierung, um gleiche Blö- cke von Dateien nur einmalig abzuspeichern. Dazu werden die anfallenden Daten in sogenannte Chunks zerlegt, die anschließend verglichen werden können [VS16]. Der Vergleich dieser Chunks kann mit klassischen Hashalgorithmen wie SHA-256 erfolgen. Die Nutzung veralteter Hashalgo- rithmen wie MD5 ist ebenfalls möglich, da der Vergleich der Netzwerkpakete keine Ansprüche an die IT-Sicherheit stellt [MZSU08].

220 9.1 Korrektheit

Für die Evaluierung ist es jedoch auch möglich, die Metadaten des Global und des Packet Hea- ders einzugrenzen. Relevant sind wie im obigen Listing aufgezeigt vorrangig die Zeitstempel. Der Kopiervorgang des Pakets zum Aufzeichnungssystem muss durch das System, auf dem die vSwitch-Instanz läuft, berechnet werden. Diese Berechnung benötigt Rechenzeit der CPU, so dass die Verarbeitung der Netzwerkdaten auf dem Zielsystem und auf dem Aufzeichnungssystem nicht zeitgleich stattﬁnden kann. Dies ist kein neues Problem der virtuellen Netzwerke, da es auch in traditionellen Aufzeichnungen physikalisch nicht möglich ist, dass die Pakete gleichzeitig ankommen. Die Paketlaufzeiten sind Schwankungen unterworfen, so dass die Ankunftszeit eines Pakets an der Netzwerkkarte im Rahmen einer netzwerkforensischen Untersuchung nicht vorherbestimmt werden kann.

9.1.2.2 Eliminierung physikalischer Parameter aus Paketmitschnitten

Da es beim Überprüfen der Integrität der Daten nicht möglich ist, eine vollständige Übereinstim- mung zu erhalten, ist ein bitgenauer Vergleich der aufgezeichneten Daten nicht zielführend. Um dennoch eine Aussage über die Korrektheit der übertragenen Daten zu erhalten, muss ein Ver- gleich der Pakete losgelöst von Metadaten erfolgen. Die jeweiligen Daten der Protokolle lassen sich über Displayﬁlter (vgl. Kapitel 2.6.4) extrahieren und vergleichen. Verschiedene Werkzeuge wie bit-twiste [Hen12] ermöglichen darüber hinaus die Zerlegung der Daten in die jeweiligen Protokolle und somit anschließend den Vergleich der Segmente.

Da ein Vergleich der gesamten Mitschnitte nicht möglich ist, muss eine Aufteilung durchgeführt werden, um die Daten dann segmentweise zu vergleichen. Diese Aufteilung wird so durchgeführt, dass jeweils ein Frame pro Datei gespeichert ist. Zerlegt man diese Datei mit den Metainforma- tionen und Paketdaten des Frames wie in Listing 9.3 aufgeführt, ist anschließend ein korrekter Vergleich möglich. Die zu entfernenden 40 Byte ergeben sich aus dem jeweiligen Global Header addiert mit dem Packet Header.

Listing 9.3: Entfernen der führenden 40 Byte aus Netzwerkmitschnitt dd bs=40 skip=1 if=icmp_vm4.pcap of=ChunkedFile.pcap 0+1 records in 0+1 records out 1042bytes transferred in 0.000901 secs (115429 bytes/sec)

Ein abschließender Hashwertvergleich weist, wie in Listing 9.4 aufgeführt, die gleichen Rohdaten nach und beweist somit die Integrität der Aufzeichnung.

221 9 Evaluierung

Listing 9.4: Vergleich der Hashwerte nach Angleichung md5 ∗ .pcap MD5 (ChunkedFile.pcap) = ed96fa2fba48ade3f7d2e8a7dc20f9d4 MD5 (ChunkedFile_mirror.pcap) = ed96fa2fba48ade3f7d2e8a7dc20f9d4

9.1.3 Nachweis

Die durchgeführten Testreihen beweisen die Korrektheit der implementierten Lösungen.

Selbst bei hoher Belastung des Wirtssystems ist es möglich, sämtliche anfallenden Netzwerk- pakete aufzuzeichnen. Das Kopieren der Flows zur Aufzeichnung auf separaten Systemen ist grundsätzlich nicht ohne Performanceverluste realisierbar. So beschreibt [ERWC14] eine Verrin- gerung der Gesamtübertragungsmenge von 30%. In [Ohi14] wird die Performance auf dedizierter Hardware und auf einem Raspberry Pi bei steigender Anzahl der Mirrorports getestet. Hierbei zeigt sich ein deutlicher Einbruch des Durchsatzes auf nur noch 50% mit steigender Anzahl der Mirrorports.

Allerdings ist dieses Problem auch in traditionellen Aufzeichnungsimplementierungen vorhanden. Konﬁgurierte Mirrorports verfügen meist über eine geringere Priorität, die im Überlastfall zu einem Paketverlust am Mirrorport führt. Der Switch leitet in diesem Fall die Daten nur noch an das tatsächliche Zielsystem weiter, an den Mirrorport werden keine Daten mehr geschickt.

Die Realisierung im virtuellen Umfeld ist im Vergleich zu klassischen hardwarebasierten Lösungen besser geeignet. Ein vSwitch ist in der Lage, sämtliche anfallenden Pakete zeitgerecht zu spiegeln, ohne dass es zu einem Verlust von Daten kommt. Da der vSwitch Kenntnis über jedes Paket hat und die benötigte Weiterverarbeitung berechnen muss, ist er in der Lage, alle Pakete zu speichern und korrekt zu kopieren. Wird das System überlastet, bricht der gesamte Datenverkehr ein, ohne den Kopiervorgang explizit zu benachteiligen.

Die Integrität der Daten ist komplexer nachzuweisen, da der durchgeführte Kopiervorgang auf dem vSwitch zusätzliche Rechenzeit benötigt. Diese Berechnung und die anschließende Weiter- leitung verzögert den Zeitpunkt des Eintreﬀens auf dem Aufzeichnungssystem. Durch Entfernen irrelevanter Metainformationen ist es dennoch möglich, die Gleichheit der Daten nachzuweisen. Die entfernten Metadaten umfassen neben den Zeitstempeln noch Informationen über das Auf- zeichnungssystem, die eingesetzte Softwareversion und Details über die übertragenen Pakete. Keine diese Informationen ist für eine valide forensische Analyse zwingend notwendig, so dass ein Vergleich der Daten ohne Metainformationen ausreichend ist.

222 9.2 Abgleich mit dem VNFP

Die so aufbereiteten Daten lassen sich über die Berechnung der Hashwerte vergleichen, sofern die Übertragungsparameter wie MTU identisch sind, ist die Integrität der Daten bewiesen. Stimmt die MTU nicht überein, ist eine Analyse dennoch möglich, jedoch müssen die extrahierten Roh- daten dann zusätzlich konkateniert werden, um die Integrität zu beweisen.

9.2 Abgleich mit dem VNFP

Das im Kapitel 6 beschriebene VNFP bietet eine Richtlinie für die erfolgreiche Durchführung forensischer Arbeiten in virtuellen Netzwerken. Dabei ist das Ziel, die gesamten Daten eines relevanten Systems aufzuzeichnen und so zu speichern, dass eine nachfolgende Analyse durchgeführt werden kann. Das Modell besteht dabei aus acht Phasen, die wiederholend durchlaufen werden und so die valide Umsetzung ermöglichen.

9.2.1 Identiﬁkation

Die Phase der Identifikation dient dem Auffinden des Zielsystems im gesamten virtuellen Um- feld. Hierfür benötigen beide Programme geeignete Identifikationsmerkmale, die eine eindeutige Zuordnung ermöglichen.

Die initiale Bestimmung eines geeigneten Merkmals ist wie in der klassischen Netzwerkforensik durch den Forensiker zu gewährleisten. Während diese einmalige Bestimmung in traditionellen Untersuchungen ausreichend ist, entsteht durch die Dynamik in virtuellen Netzwerken wieder- kehrend die Notwendigkeit, die VM im virtuellen Netzwerk aufzufinden. Tritt eine relevante Veränderung ein, muss die vNIC des Zielsystems erneut identifiziert werden. OVSF ermittelt anhand der übergebenen Parameter die MAC-Adresse, die innerhalb der Instanz und des virtuellen Netzwerks weiterhin eindeutig ist. Anschließend garantiert OVSF durch die Analyse der CAM die korrekte Zuordnung zwischen Zielsystem und vNIC. ForCon nutzt ebenfalls die MAC-Adresse als Identifikationsmerkmal. Da OpenFlow die Flows anhand einer Vielzahl von Headerfeldern definieren kann, ist für große Umgebung eine Kombination aus MAC-Adresse und VLAN-ID oder VNI möglich.

Somit bieten beide Implementierungen die Möglichkeit, das relevante Zielsystem eindeutig zu identiﬁzieren. Auch die mögliche wiederholte Identiﬁzierung ist durch beide Implementierungen möglich.

223 9 Evaluierung

9.2.2 Vorbereitung

Die Phase der Vorbereitung umfasst sämtliche Arbeitsschritte, die für die nachfolgende Auf- zeichnung relevant sind. Hierzu gehört die initiale Konﬁguration des Mirrorports, bei ForCon wird zusätzlich noch der Aufbau des Tunnels in der Phase der Vorbereitung umgesetzt. Erst nach Abschluss dieser Phase ist eine vollständige Aufzeichnung der Pakete möglich.

Die Phase der Vorbereitung wird nicht mehr aktiv, sobald die Phase der Aufzeichnung erreicht wird. Ändert sich etwas am Aufzeichnungsprozess, sei es aufgrund einer Migration, einer Nutzer- anpassung oder einer anderweitig relevanten Veränderung im Netzwerk, müssen die eingerichteten Parameter erneut für die neue Aufzeichnung angepasst werden. Dies wird dann jedoch durch die Phase der Adaption durchgeführt.

Beide Techniken unterstützen die initiale Einrichtung der Aufzeichnung und ermöglichen so einen funktionierenden Beginn der Untersuchung.

9.2.3 Aufzeichnung

Die Aufzeichnung der Daten erfolgt bei beiden Implementierungen durch Mirrorports. Während OVSF auf eine OVS-Instanz festgelegt ist, ist ForCon in der Lage, auch mehrere Instanzen zu überwachen und die Daten aufzuzeichnen. OVSF erstellt angepasste Mirrorports auf der relevanten OVS-Instanz, ForCon manipuliert die relevanten Flows, um den Datenverkehr des Zielsystems zusätzlich an einen weiteren Port zu kopieren.

Beide Techniken ermöglichen die dauerhafte Ausleitung der anfallenden Daten, so dass sämtliche Netzwerkpakete aufgezeichnet werden können.

9.2.4 Speicherung

Die Speicherung der anfallenden Daten kann wie in traditionellen netzwerkforensischen Unter- suchungen durch ein separates Speichersystem erfolgen, welches die Netzwerkpakete für die nachfolgende Analyse vorhält. Im Rahmen der virtuellen Umgebungen ist eine virtuelle Speicher- umgebung sinnvoll, aber nicht zwingend notwendig. Besonders OVSF ist in der Lage, die Daten an ein physisches System zu kopieren.

ForCon ermöglicht eine Überwachung hochdynamischer Netzwerke, so dass statische Aufzeich- nungssysteme nicht geeignet sind, den Anforderungen gerecht zu werden. Daher bietet sich beim

224 9.2 Abgleich mit dem VNFP

Einsatz von ForCon die Nutzung einer Aufzeichnungs-VM an, die den Bewegungen des Zielsys- tems folgen kann und so kurze virtuelle Netzwerkpfade nutzen kann.

Somit bieten sowohl OVSF als auch ForCon Möglichkeiten zur Speicherung der Daten, die genaue Umsetzung muss jedoch im Einzelfall bestimmt werden.

9.2.5 Überwachung

Die hohe Dynamik in virtuellen Netzwerken verlangt die dauerhafte Überwachung der Umgebung, um auftretende Ereignisse rechtzeitig zu bemerken. OVSF agiert als Listener der OVSDB und reagiert auf Änderungen der überwachten Instanz durch Nutzung des OVSDB-Monitorings, welche sämtliche Änderungen wie Hinzufügen und Entfernen protokolliert und an alle angeschlossenen Listener übermittelt.

Auch ForCon nutzt das OVSDB-Monitoring der relevanten Instanz, hier übernimmt der SDN- Agent die Überwachung.

Somit sind OVSF und ForCon in der Lage, die virtuelle Umgebung zu überwachen und auf die Ergebnisse zu reagieren. Eine Bewertung der Ereignisse erfolgt jedoch nicht in dieser Phase, sondern in der nachfolgenden Phase der Bewertung.

9.2.6 Bewertung

Da nicht jedes Ereignis Auswirkungen auf den Aufzeichnungsprozess hat, wird in dieser Phase das Ereignis analysiert und nur für den Fall, dass es relevant ist, an die nächste Phase weitergeleitet. Relevant wird ein Ereignis, wenn durch die Änderung im Netzwerk der Aufzeichnungsprozess berührt wird, dies kann durch Hinzufügen einer weiteren vNIC auf einer OVS-Instanz erfolgen oder durch Herunterfahren der Ziel-VM, wodurch auch die relevante vNIC deaktiviert wird.

OVSF analysiert die auftretenden Ereignisse eigenständig und reagiert entsprechend. Hierdurch ist es möglich, dass bei korrekter Überwachung der Ziel-VM keine weiteren Mirrorports mehr angelegt oder alle nicht benötigten Mirror deaktiviert werden.

ForCon nutzt einen dezentralen Agentenansatz, um die Ereignisse zu bewerten. Dabei schicken die Agenten mit Hilfe des Nachrichtentyps Event51 die Informationen über die Änderungen an den zentralen Server. Dieser analysiert das Ereignis und übernimmt die weitere Verarbeitung.

51Im FCP wird für die Übertragung dieser Nachrichten das Kürzel X verwendet (vgl. Abschnitt 8.4.3.

225 9 Evaluierung

Beide Techniken ermöglichen somit eine Bewertung der Ereignisse, wodurch die nachfolgende Adaption ermöglicht wird.

9.2.7 Adaption

Ist das aufgetretene Ereignis im Netzwerk relevant, muss das Aufzeichnungssystem angepasst werden. Diese Adaption kann die Rekonﬁguration des Mirrorports oder auch den Aufbau eines neuen Tunnels bei gleichzeitiger Deaktivierung des alten Tunnels zur Folge haben.

OVSF passt die Mirrorports an, sofern ein Ereignis eintritt, so dass eine dauerhafte Aufzeich- nung gewährleistet ist. ForCon informiert alle angeschlossenen Agenten über die Änderung im Netzwerk, wodurch unter Umständen eine erneute Analyse des Netzwerks zum Auﬃnden der relevanten VM gestartet wird. Diese Information wird vom Server an alle SDN-Agenten übertragen, die fortan die Überwachung ihrer zugewiesenen OVS-Instanz übernehmen.

Somit sind sowohl OVSF als auch ForCon in der Lage, auftretende Ereignisse zu bewerten und notwendige Anpassungen durchzuführen.

9.2.8 Analyse

Die abschließende Analyse der Netzwerkdaten basiert auf den aufgezeichneten Informationen. Eine solche Analyse in virtuellen Netzwerken wird durch die Overlay-Techniken erschwert (vgl. Kapitel 4.10.1), so dass relevante Informationen schlechter zu ﬁnden sind. Sowohl OVSF als auch ForCon zeichnen die Daten direkt an der vNIC auf, so dass keine zusätzlichen Netzwerkpakete wie Overlayprotokolle, Managementdaten oder irrelevante Kundeninformationen gespeichert werden.

Hierdurch ist die Analyse der Daten wieder vergleichbar mit der klassischen Netzwerkforensik. Einzig die Veränderung der Identiﬁkationsmerkmale des Zielsystems kann die Analyse weiterhin erschweren, hier bieten jedoch sowohl OVSF als auch ForCon durch die parallele Protokollierung aller durchgeführten Maßnahmen ausreichend Möglichkeiten, um die Daten korrekt zuzuordnen.

9.2.9 Ergebnis

Sowohl OVSF als auch ForCon erfüllen sämtliche Phasen des VNFP. Hierdurch ist garantiert, das beide Lösungen sämtliche Arbeitsschritte der Netzwerkforensik in virtuellen Umgebungen abdecken und so eine vollständige forensische Untersuchung in virtuellen Netzwerken ermöglichen.

226 9.3 Validierung in OpenStack-Umgebung

Tabelle 9.5 fasst die Phasen des VNFP und den Status von OVSF und ForCon zusammen.

Tabelle 9.5: Phasen des VNFP bei OVSF und ForCon Phase OVSF ForCon Identiﬁkation * * Vorbereitung * * Aufzeichnung * * Speicherung * * Überwachung * * Bewertung * * Adaption * * Analyse * *

9.3 Validierung in OpenStack-Umgebung

Nach den theoretischen Veriﬁzierungen der Lösungen erfolgt in diesem Abschnitt die Überprüfung innerhalb einer realen Cloud-Umgebung. Auf Basis von OpenStack als meistgenutzte Cloud- Implementierung erfolgt eine Analyse der möglichen netzwerkforensischen Ansätze. Nach der Deﬁnition der genutzten Modellumgebung erfolgt die Beschreibung des Vorgehens sowie der gewählten Lösungsszenarien.

9.3.1 Beschreibung der Modellumgebung

Die umfangreiche Flexibilität einer OpenStack-Umgebung verlangt eine Eingrenzung des untersuchten Themenbereichs. Eine vollständige Analyse sämtlicher Möglichkeiten betriﬀt unterschiedlichste Bereiche der IT-Forensik und wird daher in dieser Arbeit nicht weiterverfolgt.

Die genutzte Umgebung unterliegt daher folgenden Rahmenbedingungen:

• Compute-Cloud-Umgebung ohne separaten Object-Storage

• Keine Beachtung forensischer Herausforderungen auf Hypervisor und VMs

• Simulation von VMs unterschiedlicher Kunden

Innerhalb einer OpenStack-Umgebung ﬁndet sich mit nova-network und Neutron zwei Netzwer- kimplementierungen. Da nova-network seit dem Folsom-Release jedoch als deprecated markiert ist, wird ausschließlich die Neutron-Lösung analysiert.

227 9 Evaluierung

Neben einem Controller werden drei physische Hosts konﬁguriert, die die VMs betreiben. Abbil- dung 9.2 zeigt eine schematische Darstellung der genutzten Infrastruktur.

10.0.0.1/24 10.0.0.11/24 10.0.0.12/24 10.0.0.13/24 10.0.0.20/24

Controller br-ex Internet Compute-Host 1 Compute-Host 2 Compute-Host 3 Keystone Neutron Swift Nova Nova Nova Cinder

192.168.0.1/24 192.168.0.11/24 192.168.0.12/24 192.168.0.13/24 192.168.0.20/24

Abbildung 9.2: Schematische Darstellung der OpenStack-Infrastruktur

Das Subnetz 10.0.0.x/24 stellt das Managementnetzwerk dar, die Verwaltung und Kommunika- tion zwischen den OpenStack-Komponenten erfolgt über das 192.168.0.x/24 Netzwerk.

Es sind vier unterschiedliche Nutzer eingerichtet, die über eigene Subnetze verfügen, die Netz- werke der User1 (orange) , User2 (blau) und User3 (rot) haben eine Anbindung an das externe Netzwerk public, User4 (grün) besitzt keinen Zugriﬀ auf das externe Netzwerk. Abbildung 9.3 skizziert die Struktur des logischen Netzwerks.

User1_Net User2_Net

public R1

User3_Net

User4_Net

Abbildung 9.3: Struktur der virtuellen OpenStack-Umgebung

228 9.3 Validierung in OpenStack-Umgebung

9.3.2 Durchführung

Wie in traditionellen netzwerkforensischen Analysen ist auch in virtuellen Netzwerken eine Vor- arbeit durch den Forensiker notwendig. In der beschriebenen Modellumgebung muss zuerst die Identiﬁzierung des zu überwachenden Systems erfolgen. In großen Umgebungen ist hier die Unter- stützung des CSP notwendig. Weiterhin muss im Rahmen der Vorbereitung die VMa bereitgestellt werden, auf der sämtliche Daten gespeichert werden können. Hier sind die gleichen Maßnahmen wie bei klassischen Überwachungen notwendig, da keine Besonderheiten der virtuellen Netzwerke relevant sind.

Im Beispiel wird die VM User2_VM1-1, die sich im Subnetz User2_Net beﬁndet, als VMt aus- gewählt. Die Instanz-ID einer VM kann per CLI abgefragt werden, weitere Details ergeben sich hieraus, vgl. Listing 9.5:

Listing 9.5: Abfrage von Instanzdetails der Ziel-VM (Ausgabe gekürzt) [root@controller ~]# openstack server show User2_VM1−1 OS−EXT−SRV−ATTR:host node2 OS−EXT−SRV−ATTR:instance_name instance −00000030 addresses User2_Net=192.168.10.205 id ff06d7c4 −ca69−4ce9−be2f−e91c7a46e46c name User2_VM1−1

[root@node2 ~]# cat /etc/libvirt/qemu/instance −00000030.xml

ovs−vsctl show | grep qvo7563 Bridge br−int fail_mode: secure Port "qvo7563abd6−f9 " tag: 1 Interface "qvo7563abd6−f9 "

Die VMt besitzt somit die Instanz-ID ﬀ06d7c4-ca69-4ce9-be2f-e91c7a46e46c,läuft auf dem Host node2, besitzt die MAC-Adresse fa:16:3e:03:55:bc und die IP-Adresse 192.168.10.205. Das Sys- tem ist mit der vNIC tap7563abd6-f9 aktiv. Der relevante Port auf br-int ist somit qvo7563abd6-

229 9 Evaluierung f9 52. Mit dieser Port-ID ist die Aufzeichnung zu starten, so dass anschließend sämtliche Daten aufgezeichnet werden.

9.3.2.1 Aufzeichnung einer statischen VM

Der statische Betrieb einer VM deﬁniert die Eigenschaft einer VM, nicht migriert zu werden. Diese auch als Hard-Partitioning [Ora16] oder VM-Pinning [SKSD12] bezeichnete Technik wird vorrangig eingesetzt, um lizenzrechtliche Aspekte zu wahren53 oder um spezielle Tests durchzu- führen.

Sofern die VM statisch und auf dem gleichen Host betrieben wird, reicht die Nutzung von OVSF aus, um die Überwachung durchzuführen. Hierzu wird anhand der Identiﬁzierung über die Instanz-ID die MAC-Adresse sowie die vNIC ermittelt und anschließend die Aufzeichnung gestartet. OVSF ermittelt anhand des Interfaces die MAC-Adresse und erstellt nach Prüfung auf

Übereinstimmung den Mirrorport. Anschließend werden alle Daten zur VMa kopiert und dort gespeichert.

Abbildung 9.4 zeigt die Anbindung der VMa zur Aufzeichnung des Datenverkehrs der VMt User2_VM1-1:

User2_Net User2_VM1-1

public Mirror

User2_VM1-3 R2

User2_VM1-4

Abbildung 9.4: Schematische Darstellung der Netzwerktopologie zur Aufzeichnung der VMt

Sobald die VMt heruntergefahren wird, überwacht OVSF die Umgebung und startet entsprechende Mirror, wenn eine neue vNIC aktiv wird. Bemerkt OVSF, dass dieser Mirror ungültig ist, wird er wieder gelöscht, alle Aktionen werden dabei parallel protokolliert. Startet die VMt wieder, bemerkt dies OVSF und konﬁguriert den entsprechenden Mirrorport; sofern noch weitere Mirror existieren, werden diese entfernt. Listing 9.6 zeigt die Konﬁguration zur Aufzeichnung mit

52OpenStack nutzt vordefinierte Präfixe zur eindeutigen Identifizierung der vNIC und der vPorts. 53So wird sichergestellt, dass eine bestimmte Software nur auf einer vorgegebenen CPU läuft.

230 9.3 Validierung in OpenStack-Umgebung

Hilfe von OVSF. Die von OVSF ermittelten Daten stimmen mit den Daten aus der Identiﬁkation überein, somit wird das korrekte System überwacht.

Listing 9.6: Aufzeichnung der Daten in der Modellumgebung python OVSF.py 127.0.0.1 qvo7563abd6−f9 mir0 br−int Connecting to 127.0.0.1 Monitoring of the OVSDB Open_vSwitch on 127.0.0.1 enabled Target: qvo7563abd6−f9 Mirrorport: mir0 OVS instance: br−int Create initial mirror 383b3dfe−aa5d −421c−82bc−1b31f8644a57 mirroring established , please start capture process on port mir0 Extract the entries out of the FIB Found MAC address fa:16:3e:c9:66:b7 in FIB on of−port 1 Found MAC address fa:16:3e:03:55:bc in FIB on of−port 2 SUCCESS The MAC−address of the target VM ist fa:16:3e:03:55:bc Extract the entries out of the FIB Found MAC address fa:16:3e:c9:66:b7 in FIB on of−port 1 Found MAC address fa:16:3e:03:55:bc in FIB on of−port 2 Found target VM on port qvo7563abd6−f9 Remove all mirror except qvo7563abd6−f9 qvo7563abd6−f9 initialMirror

Am Interface mir0 können nun alle anfallenden Daten aufgezeichnet werden.

9.3.2.2 Aufzeichnung einer dynamischen VM

Der klassische Betrieb in Cloud-Umgebungen erfolgt ohne VM-Pinning, so dass jederzeit Mi- grationen oder weitere Anpassung der VM erfolgen können. In diesen Fällen ist eine Nutzung von OVSF nicht geeignet, da die singuläre Betrachtung der OVS-Instanzen nicht ausreichend ist. Sofern die Administration der Netzwerkkomponenten mit Hilfe von OpenFlow erfolgt, kann die Aufzeichnung der Daten durch ForCon erfolgen. Zur Evaluation einer solchen dynamischen Infrastruktur wurde die Testumgebung durch die zusätzliche Installation des SDN-Controllers POX auf dem Netzwerkcontroller erweitert. Abbildung 9.5 zeigt die schematischen Struktur der OpenStack-Umgebung nach der Integration von ForCon inklusive der Agenten und des Mirror- systems.

231 9 Evaluierung

ForCon FCP Mirror

FCP FCP FCP

10.0.0.1/24 10.0.0.11/24 10.0.0.12/24 10.0.0.13/24 10.0.0.20/24 Internet Controller br-ex Compute-Host 1 Compute-Host 2 Compute-Host 3 Neutron Keystone Swift Nova Nova Nova SDN-Controller Cinder

192.168.0.1/24 192.168.0.11/24 192.168.0.12/24 192.168.0.13/24 192.168.0.20/24

Abbildung 9.5: Integration von ForCon in einer OpenStack-Umgebung

Die Identiﬁzierung der VMt beschränkt sich auf die Suche und Zuordnung der MAC-Adresse. Die genaue Lokalisierung wie bei der statischen Umgebung ist nicht notwendig. ForCon übernimmt eigenständig die Suche nach dem Ziel. Anschließend sind zusätzliche Arbeitsschritte wie der Start der VMa innerhalb der Cloud-Umgebung und die Aktivierung der dezentralen Agenten notwendig.

Nach dem Start ermittelt jeder Agent die konﬁgurierten OVS-Instanzen. Findet ein Agent das Zielsystem auf einer seiner OVS-Instanz, wird der Server informiert, der die Konﬁguration des Mirrors beauftragt. Wird eine Migration durchgeführt, bemerkt dies der involvierte Agent, so dass der Server über die Änderung informiert wird. Dieser beauftragt die erneute Überwachung des Netzwerks.

Falls notwendig, könnte die VMa ebenfalls migriert werden, OpenStack bietet mit der Live- migration die Möglichkeit, das Zielsystem auszuwählen. ForCon bietet keine direkte Interaktion, ermöglicht jedoch über die Announcements (vgl. Abschnitt 8.4.3) eine Benachrichtigung, so dass die Livemigration manuell gestartet werden kann. Dies wird besonders relevant, wenn die VMt in ein anderes RZ migriert wird, und hierdurch der Datenverkehr über WAN-Strecken transportiert werden müsste.

9.3.3 Optimierung

Während die Nutzung von OVSF auf die Überwachung einer einzelnen Instanz ausgelegt ist, bietet ForCon eine Lösung für die Überwachung großer virtueller Umgebungen. In Produktivum- gebungen umfassen diese Infrastrukturen mehrere hundert oder sogar tausend Serversysteme, die für den Betrieb der VMs bereitstehen. Eine umfängliche Überwachung dieser Umgebung ist mit

232 9.3 Validierung in OpenStack-Umgebung

ForCon grundsätzlich möglich, allerdings steigt die Anzahl der ermittelten OVS-Instanzen und der dort installierten Flows möglicherweise stark an.

Auch wenn die tatsächliche Anzahl relevanter Flows nach erfolgter Identiﬁzierung der VMt gering ist, muss im ersten Schritt die gestiegene Anzahl der übermittelten Flows verarbeiten werden. Um solche gestiegenen Anforderungen zu bewältigen, bieten sich unterschiedliche Möglichkeiten an:

• Speicherung der erhaltenen Flows in einer Datenbank Die Speicherung der erhaltenen Flows ist durch den objektorientierten Ansatz von ForCon in unterschiedlichsten Formaten möglich, vgl. Abschnitt 8.4.4. Durch Anpassung der entsprechenden Klasse (vgl. Abschnitt 8.4) kann die Art der Speicherung angepasst werden. Im Rahmen des PoC ist die Verarbeitung der Daten im Arbeitsspeicher jedoch ausreichend stabil und schnell. Durch die Speicherung in einer Datenbank stehen jedoch sämtliche Opti- mierungspotentiale und Entwicklungen wie NoSQL [Lea10] oder In-Memory-Datenbanken [GMS92] zur Verfügung.

• Skalierung Skalierbarkeit beschreibt das Hinzufügen von zusätzlichen Leistungsressourcen, um die Gesamtleistung des Systems zu steigern. Dabei wird grundsätzlich zwischen vertikaler und horizontaler Skalierung unterschieden. Während bei der vertikalen Skalierung die vorhandenen Systeme mit leistungsfähigeren Komponenten ausgestattet werden, werden bei der horizontalen Skalierung die bisherigen Systeme gegen neue und leistungsfähigere Systeme ausgetauscht oder der Gesamtpool erweitert [JMW+11].

Eine vertikale Skalierung ForCons bietet entsprechende Optimierungspotentiale, da die Be- rechnung der relevanten Flows schneller erfolgen kann. Eine horizontale Skalierung bringt jedoch aufgrund der fehlenden Parallelität des aktuellen PoCs keine Optimierungsmöglich- keiten. In [TS07] und [Neu94] werden drei weitere Möglichkeiten zur Skalierung in verteilten Systemen beschrieben:

– Verteilung Die Verteilung hat das Ziel, die engpassverursachende Ressource zu zerlegen und auf verschiedene Subsysteme zu verteilen.

– Asynchrone Kommunikation Ziel dieser Kommunikation ist es, Wartezeiten aufgrund der Berechnung notwendiger Antworten zu minimieren und keine ineinander verzahnte Kommunikation mit Pausen notwendig zu machen.

233 9 Evaluierung

– Replikation Die Replikation hat das Ziel, die benötigten Ressourcen auf viele Systeme zu verteilen, so dass nicht ein System für die Verarbeitung zuständig ist, sondern mehrere Systeme entsprechende Anfragen beantworten können.

ForCon implementiert bereits die Verteilung und auch die asynchrone Kommunikation. Die Agenten sind bereits im PoC in der Lage, eine Vorselektion von Flows vorzunehmen, so dass der Server diese Informationen gar nicht erst erhält und demnach auch nicht verarbeiten muss. Das FCP als asynchrones Kommunikationsprotokoll ist auf die entsprechende thread- basierte Kommunikation ausgelegt und führt zu keinen Wartezeiten bei der Übermittlung der Nachrichten.

Somit verbleibt letztlich die Replikation der Daten. Da es sich bei ForCon jedoch um ein hochdynamisches System handelt, erscheint eine Replikation der Flows nicht zielführend.

• Limitierung der Zielsysteme In klassischen netzwerkforensischen Arbeiten erfolgt zuerst eine Analyse der Umgebung, in der die VM betrieben wird. Dies umfasst im Normalfall die Auslastung der Netzwerkver- bindung über einen gewissen Zeitraum sowie eine Überprüfung auf Lastspitzen.

Erweitert man diese Vorfeldanalyse auf Details zur VM, besteht die Möglichkeit, die ein- setzbaren Wirtssysteme einzugrenzen. In virtuellen Umgebungen ist die Verteilung der VMs nicht vollständig beliebig, sondern wird mit Hilfe von Regionen und sogenannten Flavors grob vorbestimmt. Ein Flavor bezeichnet dabei die vorhandene Hardwarestruktur, die die VMs nutzen können. So ermöglicht die Deﬁnition von CPU-Architekturen eine Begrenzung der startfähigen VMs pro Server. Eine Vermischung von i386, x64 oder ARM-Systemen ist somit ausgeschlossen. Diese Informationen ermöglichen somit eine Reduzierung der mögli- chen Wirtssysteme, so dass die Agenten nur auf diesen Systemen ausgeführt werden müssen und so die Gesamtzahl deutlich verringert werden kann.

9.3.4 Fazit

Die Implementierung einer Modellumgebung auf Basis von OpenStack hat gezeigt, dass die Netzwerkforensik in virtuellen Umgebungen mit den entwickelten Lösungen möglich ist. In eher statischen Umgebungen reicht die Nutzung von OVSF, sind dynamische Umgebungen vorhanden, bietet ForCon die entsprechende Lösung, sofern OpenFlow zur Konﬁguration des Paketﬂusses genutzt wird.

234 9.4 Antiforensische Bewertung

ForCon setzt dabei bereits jetzt eine Vielzahl unterschiedlicher Optimierungsmöglichkeiten zur Skalierung. Hierdurch ist in Verbindung mit einer detaillierten Vorfeldanalyse eine Umsetzung auch in Umgebungen mit mehreren tausend Wirtssystemen möglich.

9.4 Antiforensische Bewertung

Die Antiforensik ist im Bereich der illegalen Aktivitäten eine häuﬁg eingesetzte Methode, um die durchgeführten Angriﬀe zu verschleiern oder die Entdeckung zu erschweren. Dabei untertei- len sich die antiforensischen Möglichkeiten, die Auswirkungen auf die Netzwerkforensik haben können, in die folgenden Bereiche:

• Tunnelnutzung

• Dynamik

• Verschlüsselung

• Steganographie

Die Nutzung eigener Tunneltechniken wie VPN oder die verschlüsselte Übertragung der Da- ten verbergen wirksam die übertragenen Informationen. Hier unterscheidet sich der Ansatz in virtuellen Umgebungen nicht von denen in klassischen Netzwerken. Die Nutzung starker Ver- schlüsselungstechniken macht die Analyse der Daten weitestgehend unmöglich, allerdings sind Techniken der statistischen Datenanalyse sowie die Auswertung der Metadaten eine verbleibende Möglichkeit zur Untersuchung der Daten (vgl. Kapitel 3.1).

Die Dynamik in virtuellen Umgebungen bietet eine neue Form für antiforensische Techniken.

Die verdächtige Person kann in (un)regelmäßigen Abständen die VMt stoppen, neu starten oder migrieren. Ohne ForCon reicht dies bereits aus, um sämtliche Aufzeichnungstechniken scheitern zu lassen. ForCon hingegen ist in der Lage, die entsprechende VMt im Netzwerk nachzuverfolgen.

Auch bei der Entdeckung netzwerksteganographischer Techniken ist ForCon einsetzbar. Virtu- al Migration Covert Channels nutzen benutzerinitiierte Migrationen der involvierten VMs aus, um Informationen auszutauschen. Durch die dauerhafte Aufzeichnung aller Netzwerkpakete der entsprechenden VM ist es bei der Analyse der Daten unter Umständen möglich, das Kommu- nikationsschema zu entdecken. Klassische Aufzeichnungssysteme sind hierzu nicht in der Lage, da eine für diese Art der verdeckten Kommunikation genutzten VM nicht dauerhaft überwacht werden kann. Losgelöst von der Aufzeichnung verbleibt weiterhin die Erkennung der verdeckten Kanäle durch den Ermittler.

235 9 Evaluierung

9.5 Zusammenfassung

Sowohl OVSF für Open vSwitch als auch ForCon für OpenFlow erfüllen die Anforderungen des VNFP und sind somit für die forensische Untersuchung in virtuellen Netzwerken geeignet. Das Hauptproblem der klassischen Netzwerkforensik ist dabei die vollständige Implementierung der virtuellen Netzwerke in Software. Die bisher eingesetzten Techniken zur Datenaufzeichnung sind hardwarebasiert und nicht mehr nutzbar. ForCon und OVSF sind hingegen vollständig software- basiert und unterscheiden sich deutlich von den bisherigen Aufzeichnungsmethoden.

Somit kann je nach Einsatzzweck entschieden werden, ob und in welcher Form die Netzwerk- forensik durchgeführt wird. Handelt es sich um eine kleinere Infrastruktur auf Basis von Open vSwitch, bietet OVSF bereits geeignete Möglichkeiten, um die Untersuchung durchzuführen. Diese Netzwerke zeichnet dabei eine geringere Flexibilität aus, OVSF garantiert in dieser Umge- bung die vollständige Aufzeichnung parallel zu einer Protokollierung, die auch nachträglich die Arbeitsweise überprüfbar macht.

ForCon hingegen garantiert auch in großen und dynamischen Umgebungen eine Aufzeichnung der anfallenden Netzwerkdaten. In diesem Kapitel wurde darauf aufbauend gezeigt, dass ForCon Techniken zur Skalierung nutzt und somit auch in großen Umgebungen einsetzbar bleibt.

Die Relevanz zur Erkennung antiforensischer Methoden gewinnt in der heutigen Zeit immer mehr an Bedeutung. Dabei bieten sowohl OVSF als auch ForCon Möglichkeiten zur Verarbeitung, teils muss dies jedoch durch eine separate Überwachung zusätzlicher Systeme erfolgen.

236 10 Fazit

Dieses Kapitel fasst die gewonnenen Aspekte zusammen, beschreibt die erarbeiteten neuen Tech- niken und Möglichkeiten zur Durchführung netzwerkforensischer Arbeiten in virtuellen Umgebun- gen und gibt einen Ausblick auf weitere Forschungsfragen auf Basis dieser Arbeit.

10.1 Zusammenfassung

Nach einer Einführung in die Themengebiete Netzwerk, Cloud-Computing und IT-Forensik wurde detailliert die Netzwerkvirtualisierung vorgestellt. Durch diese Technik können unabhängige logische Netzwerke auf Basis vorhandener physischer Netze erstellt werden. Hierdurch steigt die Flexibilität und Dynamik der gesamten Netzwerkumgebung an, so dass die besonderen Anforde- rungen des Cloud-Computings erfüllt werden können.

Diese Anforderungen an die Netzwerke schaﬀen neuen Probleme der IT-Forensik, welche bisher kaum ausreichend wissenschaftlich analysiert, geschweige denn gelöst wurden. Da sowohl Netz- werkkarten der VMs als auch Netzwerkkomponenten wie Switche oder Router virtualisiert werden können, sind etablierte Aufzeichnungstechniken der Netzwerkforensik nicht mehr nutzbar. So können weder zusätzlich Hardwarekomponenten wie TAPs oder Bridges in das nun virtuelle Netz- werk eingebracht noch umfangreiche und zeitintensive Aufzeichnungen an Uplinks vorgenommen werden, da hier nicht rechtzeitig auf die Änderungen der relevanten VM reagiert werden kann.

Ausgehend von einer Auflistung und Klassifizierung existenter Probleme wurde eine Analyse der spezifischen Anforderungen durchgeführt, die die Besonderheiten der virtuellen Umgebungen bewertet. Hieraus wurde mit dem VNFP ein angepasstes Vorgehensmodell entwickelt, welches die Netzwerkforensik in virtuellen Umgebungen beschreibt. Das VNFP definiert neue Phasen, die die Überwachung des Netzwerks, die Bewertung von aufgetretenen Ereignissen und die geeignete Reaktion auf dieses Ereignis umfassen.

Diese theoretischen Grundlagen wurden im Folgenden genutzt, um zwei Lösungen zu erarbeiten, die diese Anforderungen erfüllen und in unterschiedlichen Szenarien geeignete Unterstützungs- möglichkeiten bieten. Auf Basis der Software Open vSwitch wurde mit OVSF eine Lösung ent-

237 10 Fazit wickelt, die eine Aufzeichnung der Netzwerkdaten einer dedizierten VM ermöglicht. Auch ein Neustart und die damit verbundenen Änderungen interner Details führt nicht zu einem Abbruch des Aufzeichnungsprozesses. Parallel wurde damit bewiesen, dass nur der direkte Zugriﬀ auf die vNIC eine korrekte Datenaufzeichnung garantiert.

Da aber in Cloud-Umgebungen eine VM nicht dauerhaft an nur einer OVS-Instanz angeschlossen ist, sondern aufgrund von Migrationen auch auf andere Wirtssysteme umziehen kann, wurde mit ForCon eine Lösung erarbeitet, die ein System überwacht und eigenständig Maßnahmen ergreifen kann, so dass auch hier der Aufzeichnungsprozess dauerhaft weiterläuft.

Beide Lösungen stellen als PoC erste Ansätze da, die Funktionsfähigkeit wurde jedoch innerhalb einer Cloud-Umgebung auf Basis von OpenStack untersucht. Beide Implementierungen sind in der Lage, die jeweiligen Aufgaben vollkommen abzudecken und so die netzwerkforensische Arbeit abzusichern.

Die durchgeführte Evaluation beweist neben der Korrektheit des Aufzeichnungsprozesses auch die Übereinstimmung mit dem VNFP, welches als Referenzmodell für netzwerkforensische Arbeiten in virtuellen Umgebungen dient.

10.2 Ausblick

Die in der Arbeit gewonnenen Möglichkeiten schaﬀen für Netzwerkforensiker und Ermittlungsbe- hörden neue Möglichkeiten, Daten innerhalb virtualisierter und somit dynamischer Umgebungen korrekt zuzuordnen und aufzuzeichnen.

Problematische Aspekte wie Neustarts oder Migrationen überwachter VMs werden losgelöst von Managementumgebungen oder eingesetzten SDN-Controller schon während der Durchführung bemerkt und separat behandelt, so dass durch geeignete Anpassung wie Flowmanipulationen oder Rekonﬁgurationen eine durchgehende Aufzeichnung aller Daten möglich ist.

Dennoch existieren vorrangig bei ForCon zusätzliche Erweiterungsmöglichkeiten. Sowohl OVSF als auch ForCon stellen als PoC erste real nutzbare Ansätze bereit, um in virtuellen Netzwerken forensische Datenaufzeichnungen durchzuführen. Der Einsatz von ForCon ist dabei auf große Netzwerke mit vielen unterschiedlichen Teilnehmern ausgelegt. Dies verlangt zusätzliche Siche- rungsmaßnahmen, um die Ausführung sicher abwickeln zu können. So ist eine Verschlüsselung der Daten sinnvoll, um in stark frequentierten Netzwerken die Steuerinformationen zu sichern. Auch eine Authentiﬁzierung der Agenten am Server ist eine sinnvolle Möglichkeit, unberechtigte Systeme auszuschließen und nur Anfragen berechtigter Systeme zu verarbeiten.

238 10.3 Eigene Leistung

ForCon kann darüber hinaus genutzt werden, um die klassische Computerforensik zu unterstüt- zen. Die Migration in virtuellen Umgebungen erschwert nicht nur die Netzwerkforensik, auch die Computerforensik ist hierdurch deutlich komplizierter geworden. Nachdem eine VM migriert wurde, wird der bisher genutzte Speicherplatz freigegeben und kann durch andere Systeme genutzt werden. Eventuell relevante Informationen werden hierdurch überschrieben und stehen für eine weitere Auswertung nicht mehr zur Verfügung. Durch die extrahierten Informationen über die involvierten Wirtssysteme erhält ein Ermittler Kenntnis über den jeweiligen Speicherort des Zielsystems und kann so nach Möglichkeit weitere Maßnahmen zur Datensicherung ergreifen.

Weitergehende Techniken wie Nested-Virtualization [BYDD+10] sind zwar grundsätzlich durch ForCon und OVSF zu verarbeiten, dennoch verhindern die mehrfache Kapselung und die damit verbundenen weiteren Zwischenschichten die punktgenaue Aufzeichnung der Daten. Sofern kein direkter Zugriﬀ auf die „innere“ Virtualisierung möglich ist, verbleibt letztlich nur die Aufzeich- nung der Netzwerkdaten, die diese Schicht verlassen.

Die erweiterten Vernetzungstechniken für Container [DKK16] ermöglichen die Bereitstellung komplexer Netzwerkinfrastrukturen, in denen leichtgewichtige Container miteinander vernetzt werden. Die zeitgleiche Bereitstellung dieser Container in VMs erhöht die Gesamtkomplexität um ein Weiteres; auch hier bleibt nur die Aufzeichnung der Netzwerkdaten an einer zentralen Übergabeposition. Trotz dieser Einschränkung ist ForCon immer noch in der Lage, diese Daten aufzuzeichnen, klassische Techniken sind weiterhin nicht in der Lage.

10.3 Eigene Leistung

Die Versuche in der Vergangenheit, Netzwerkforensik in virtuellen Umgebungen durchzuführen, lassen sich rückblickend nur als verzweifelt bezeichnen. Zum Scheitern verurteilte Versuche, an Uplinks oder Transitstrecken Datenaufzeichnungen durchzuführen waren dennoch an der Tages- ordnung, wenn es darum ging, in virtuellen Umgebungen Netzwerkforensik zu betreiben.

Meist reichte es schon, die VM einmal herunterzufahren und neu zu starten, um die Aufzeich- nung komplett scheitern zu lassen. Spätestens jedoch wenn die VM migriert wurde, war die Aufzeichnung unvollständig, meist solange, bis jemand händisch festgestellt hat, dass eben diese Aufzeichnung nicht mehr funktioniert. Die bisher genutzten Aufzeichnungstechniken haben keine Möglichkeiten implementiert, die entsprechende Reaktionen ermöglichen.

Das Problem existiert vorrangig im Rahmen von Strafverfolgungsbehörden, die eine vollständige Aufzeichnung der Netzwerkdaten einer relevanten VM im Rahmen einer Server-TKÜ benötigen, um gerichtsfest Sachverhalte beweisen oder widerlegen zu können. Solche vollständige Daten-

239 10 Fazit aufzeichnungen über mehrere Tage oder Wochen sind im Rahmen von Störungsbehebung und Netzmanagement eher unüblich, so dass dieses Problem in der Form kaum auftritt.

Durch diese Arbeit und die vorgestellten neuen Lösungen ist es nun möglich, korrekte und vollständige Datenaufzeichnungen, vollautomatisiert ohne manuelle Zusatzarbeit durchführen zu können. Strafverfolgungsbehörden erhalten nun ebenso wie IT-Sicherheitsunternehmen die Mög- lichkeit, relevante Daten eines hochdynamischen Zielsystems aufzuzeichnen. Dennoch können diese Techniken auch im Rahmen von Monitoringlösungen und Störungsmanagement eingesetzt werden, um auch hier korrekte und vollständige Aufzeichnungen zu erhalten.

Die Demonstration am konkreten Beispiel von Open vSwitch als vSwitch-Implementierung und OpenFlow als Protokoll der Southbound-API schafft unmittelbar einen praktischen Nutzen, weil marktbeherrschende Implementationen abgedeckt sind. Die Evaluierung im Rahmen einer OpenStack-Cloud beweist ebenfalls die Funktionsfähigkeit in realen Umgebungen. OpenStack nutzt für die Vernetzung der VMs standardmäßig Open vSwitch, so dass sowohl OVSF als auch ForCon in diesen Umgebungen eingesetzt werden können. Da OpenStack die am häufigsten eingesetzte Lösung für Cloud-Umgebungen handelt, sind andere Implementierungen zu vernach- lässigen. Dennoch ermöglicht der agentenbasierte Ansatz von ForCon weitere Anpassungen an andere vSwitche, so dass die Funktionsfähigkeit von ForCon erweitert werden kann und mit wenigen Anpassungen so auch andere Cloud-Umgebungen analysiert werden können. Die vollständige Trennung von controllerspezifischen Daten befreit den Forensiker ebenfalls vom Zwang, situati- onsangepasste Änderungen an ForCon vorzunehmen. Hierdurch besteht die Möglichkeit, OVSF und ForCon zu Standardwerkzeugen für Netzwerkforensiker werden zu lassen.

Selbst in Umgebungen, die weder OpenFlow noch Open vSwitch einsetzen, bietet das entwickelte VNFP eine sichere Handlungsanweisung, um auch in weiteren virtuellen Umgebungen vollständige Datenaufzeichnungen erhalten zu können.

240 Literaturverzeichnis

[AB12] APPELMAN, Michiel ; BOER, Maikel D.: Performance Analysis of Open- Flow Hardware / University of Amsterdam. 2012. – Forschungsbericht

[ABKM02] Andersen, David G. ; Balakrishnan, Hari ; Kaashoek, M. F. ; Morris, Robert: Resilient overlay networks. In: Computer Communication Review 32 (2002), Nr. 1, S. 66

[ABMR06] Allan, David ; Bragg, Nigel ; McGuire, Alan ; Reid, Andy: Ethernet as carrier transport infrastructure. In: IEEE Communications Magazine 44 (2006), Nr. 2, S. 95–101

[AFCF13] Al Fahdi,M.; Clarke, N.L. ; Furnell, S.M.: Challenges to digital forensics: A survey of researchers practitioners attitudes and opinions. In: 2013 Information Security for South Africa, 2013, S. 1–8

[AFH17] Aziz, Amira Sayed A. ; Fouad, Mohamed M. ; Hassanien, Aboul E.: Cloud Computing Forensic Analysis: Trends and Challenges. In: Multimedia Forensics and Security. Springer, 2017, S. 3–23

[AFLV08] Al-Fares, Mohammad ; Loukissas, Alexander ; Vahdat, Amin: A scalable, commodity data center network architecture. In: ACM SIGCOMM Computer Communication Review 38 (2008), Nr. 4, S. 63–74

[Ahm16] Ahmed, Wasim: Mastering Proxmox. Packt Publishing, 2016

[AHTH13] Akiyama, Soramichi ; Hirofuchi, Takahiro ; Takano, Ryousei ; Honiden, Shinichi: Fast Wide Area Live Migration with a Low Overhead through Page Cache Teleportation. In: CCGRID, IEEE Computer Society, 2013, S. 78–82

[AI13] Ajila, S. A. ; Iyamu, O.: Eﬃcient live wide area VM migration with IP address change using type II hypervisor. In: 2013 IEEE 14th International Conference on Information Reuse Integration (IRI), 2013, S. 372–379

241 Literaturverzeichnis

[AIJ14] Almulla, Sameera A. ; Iraqi, Youssef ; Jones, Andrew: A State-of-the-Art Review of Cloud Forensics. In: Journal of Digital Forensics, Security and Law 9 (2014), Nr. 4, S. 7–28

[AIJ16] Almulla, Sameera ; Iraqi, Youssef ; Jones, Andrew: Digital forensic of a cloud based snapshot. In: Innovative Computing Technology (INTECH), 2016 Sixth International Conference on IEEE, 2016, S. 724–729

[AKO+05] Altunbasak, Hayriye ; Krasser, Sven ; Owen, Henry L. ; Grimminger, Jochen ; Huth, Hans-Peter ; Sokol, Joachim: Securing layer 2 in local area networks. In: Networking-ICN 2005. Springer, 2005, S. 699–706

[ALCF15] Alotibi, Gaseb ; Li, Fudong ; Clarke, Nathan ; Furnell, Steven: Behavioral-Based Feature Abstraction from Network Traﬃc. In: ICCWS 2015- The Proceedings of the 10th International Conference on Cyber Warfare and Security Academic Conferences Limited, 2015, S. 1

[Ama16] Amazon Web Services: Amazon VPC. Online. http://aws.amazon.com/ de/vpc/. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[AMN08] AbuHmed, Tamer ; Mohaisen, Abedelaziz ; Nyang, DaeHun: A Survey on Deep Packet Inspection for Intrusion Detection Systems. In: Computing Research Repository abs/0803.0037 (2008)

[ANMANAJ12] Al Nuaimi, Klaithem ; Mohamed, Nader ; Al Nuaimi, Mariam ; Al- Jaroodi, Jameela: A survey of load balancing in cloud computing: Challenges and algorithms. In: Network Cloud Computing and Applications (NCCA), 2012 Second Symposium on IEEE, 2012, S. 137–142

[APST05] Anderson, T. ; Peterson, L. ; Shenker, S. ; Turner, J.: Overcoming the Internet impasse through virtualization. In: Computer 38 (2005), April, Nr. 4, S. 34–41

[ARDC14] Agarwal, Kanak ; Rozner, Eric ; Dixon, Colin ; Carter, John: SDN traceroute: tracing SDN forwarding without changing network behavior. In: Pro- ceedings of the Third Workshop on Hot Topics in Software Deﬁned Networking ACM, ACM, 2014 (HotSDN ’14), S. 145–150

[ASAH10] Al-Shaer, Ehab ; Al-Haj, Saeed: FlowChecker: Configuration Analysis and Verification of Federated Openflow Infrastructures. In: Proceedings of the 3rd ACM Workshop on Assurable and Usable Security Configuration. New York, NY, USA : ACM, 2010 (SafeConfig ’10), S. 37–44

242 Literaturverzeichnis

[Avi15] Avid Life Media: Statement from Avid Life Media Inc. On- line. http://media.ashleymadison.com/statement-from-avid-life- media-inc-august-18-2015/. Version:September 2015. – Letzter Zugriﬀ: 28.06.2017

[aws06] aws.amazon.com: Announcing Amazon Elastic Compute Cloud (Ama- zon EC2) - beta. https://aws.amazon.com/de/about-aws/whats- new/2006/08/24/announcing-amazon-elastic-compute-cloud-amazon- ec2---beta/. Version:2006. – Letzter Zugriﬀ: 28.06.2017

[Azo13] Azodolmolky, Siamak: Software Deﬁned Networking with OpenFlow. Packt Publishing, 2013

[BAAZ11] Benson, Theophilus ; Anand, Ashok ; Akella, Aditya ; Zhang, Ming: Mi- croTE: Fine Grained Traﬃc Engineering for Data Centers. In: Proceedings of the Seventh COnference on Emerging Networking EXperiments and Technologies. New York, NY, USA : ACM, 2011 (CoNEXT ’11), S. 8:1–8:12

[Bac88] Backes, F.: Transparent bridges for interconnection of IEEE 802 LANs. In: IEEE Network 2 (1988), Nr. 1, S. 5–9

[BAM10] Benson, Theophilus ; Akella, Aditya ; Maltz, David A.: Network traﬃc characteristics of data centers in the wild. In: Proceedings of the 10th ACM SIGCOMM conference on Internet measurement ACM, 2010, S. 267–280

[Ban15] Banas, Matus: Cloud Forensic Framework For IaaS With Support for Volatile Memory, Dublin, National College of Ireland, Diplomarbeit, September 2015

[Bar08] Barth, Wolfgang: Nagios: System and network monitoring. No Starch Press, 2008

[Bar15] Barr, Jeﬀ: EC2 Instance History. https://aws.amazon.com/de/blogs/ aws/ec2-instance-history/. Version:2015. – Letzter Zugriﬀ: 28.06.2017

[Bau01] Bauer, Mick: Paranoid Penguin: Designing and Using DMZ Networks to Pro- tect Internet Servers. In: Linux Journal 2001 (2001), March, Nr. 83

[BB16] Büst, Rene ; Buch, Meike: OpenStack als Basis für oﬀene Cloud- Architekturen. 2016

243 Literaturverzeichnis

[BBGP10] Bianco, Andrea ; Birke, Robert ; Giraudo, Luca ; Palacin, Manuel: Open- ﬂow switching: Data plane performance. In: 2010 IEEE International Conference on Communications (ICC) IEEE, 2010, S. 1–5

[BBH+14] Bates, Adam ; Butler, Kevin ; Haeberlen, Andreas ; Sherr, Micah ; Zhou, Wenchao: Let SDN be your eyes: Secure forensics in data center networks. In: Proceedings of the NDSS workshop on security of emerging network technologies (SENT’14), 2014

[BBHHK14] Bremler-Barr, Anat ; Harchol, Yotam ; Hay, David ; Koral, Yaron: Deep Packet Inspection as a Service. In: Proceedings of the 10th ACM Inter- national on Conference on emerging Networking Experiments and Technologies ACM, 2014, S. 271–282

[BBLS12] Binz, Tobias ; Breiter, Gerd ; Leymann, Frank ; Spatzier, Thomas: Por- table Cloud Services Using TOSCA. In: IEEE Internet Computing 16 (2012), May, Nr. 03, S. 80–85

[BC05] Beebe, Nicole L. ; Clark, Jan G.: A hierarchical, objectives-based framework for the digital investigations process. In: Digital Investigation 2 (2005), Nr. 2, S. 147–167

[BD15] Buric, J. ; Delija, D.: Challenges in network forensics. In: 2015 38th Interna- tional Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2015, S. 1382–1386

[Bei14] Beitter, Tilman: IaaS mit OpenStack: Cloud Computing in der Praxis. 1. Auﬂ. Heidelberg : dpunkt.verlag, 2014 (BSystems)

[Bel56] Bellman, Richard: On a routing problem / DTIC Document. 1956. – For- schungsbericht

[Bel00] Bellovin, Steven M.: Wiretapping the net. In: The Bridge 20 (2000), Nr. 2, S. 21–26

[BGKT13] Baucke, S. ; Green, H. ; Kempf, J. ; Tatipamula, M.: Using MPLS for virtual private cloud network isolation in openﬂow-enabled cloud computing. https://www.google.com/patents/US8560663. Version:Oktober 2013. – US Patent 8,560,663

244 Literaturverzeichnis

[BH96] Bishop, Matt ; Heberlein, L. T.: Attack class: Address spooﬁng. In: Pro- ceedings of the 19th National Information Systems Security Conference, 1996, S. 371–377

[Bha07] Bhaiji, Yusuf: Understanding, preventing, and defending against layer 2 attacks. Online. http://www.nanog.org/meetings/nanog42/ presentations/Bhaiji_Layer_2_Attacks.pdf. Version:2007. – Letzter Zugriﬀ: 28.06.2017

[Bia16] Bias, Randy ; Cloudscaling (Hrsg.): The History of Pets vs Cattle and How to Use the Analogy Properly. Online. http://cloudscaling.com/blog/ cloud-computing/the-history-of-pets-vs-cattle/. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[Bil06] Bilby, Darren: Low down and dirty: anti-forensic rootkits. In: Proceedings of Ruxcon 2006 (2006)

[BKFS07] Bradford, Robert ; Kotsovinos, Evangelos ; Feldmann, Anja ; Schi- öberg, Harald: Live Wide-area Migration of Virtual Machines Including Local Persistent State. In: Proceedings of the 3rd International Conference on Virtu- al Execution Environments. New York, NY, USA : ACM, 2007 (VEE ’07), S. 169–179

[BKNT11] Baun, Christian ; Kunze, Marcel ; Nimis, Jens ; Tai, Stefan: Cloud Computing - Web-Based Dynamic IT Services. Springer, 2011. – I–IX, 1–97 S.

[BLGM01] Borella, M. ; Lo, J. ; Grabelsky, D. ; Montenegro, G.: Realm Spe- ciﬁc IP: Framework. RFC 3102 (Experimental). http://www.ietf.org/rfc/ rfc3102.txt. Version:Oktober 2001 (Request for Comments)

[BM05] Behringer, Michael H. ; Morrow, Monique: MPLS VPN Security. Cisco Press, 2005

[BM14] Braun, Wolfgang ; Menth, Michael: Software-Deﬁned Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices. In: Future Internet 6 (2014), S. 302–336

[BMP10] Braga, Rodrigo ; Mota, Edjard ; Passito, Alexandre: Lightweight DDoS ﬂooding attack detection using NOX/OpenFlow. In: 2010 IEEE 35th Conference on Local Computer Networks (LCN) IEEE, 2010, S. 408–415

245 Literaturverzeichnis

[Bod12] Bode, Thomas A.: Kernbereichsschutz. In: Verdeckte strafprozessuale Ermitt- lungsmaßnahmen. Springer, 2012, S. 293–305

[BR13] Badach, Anatol ; Rieger, Sebastian: Netzwerkprojekte: Planung Realisierung Dokumentation und Sicherheit von Netzwerken. München : Hanser, 2013

[BRA10] Ballard, Jeﬀrey R. ; Rae, Ian ; Akella, Aditya: Extensible and Scalable Network Monitoring Using OpenSAFE. In: INM/WREN, 2010

[Bra14] Bray, T.: The JavaScript Object Notation (JSON) Data Interchange Format. RFC 7159 (Proposed Standard). http://www.ietf.org/rfc/rfc7159.txt. Version:März 2014 (Request for Comments)

[Bre12] Brebner, Paul: Is your cloud elastic enough? performance modelling the ela- sticity of infrastructure as a service (IaaS) cloud applications. In: International Conference on Performance Engineering, ACM, 2012, S. 263–266

[BREGE13] Batalle, J. ; Riera, J. F. ; Escalona, E. ; Garcia-Espin, J. A.: On the Implementation of NFV over an OpenFlow Infrastructure: Routing Function Vir- tualization. In: 2013 IEEE SDN for Future Networks and Services (SDN4FNS), 2013, S. 1–6

[BSB+10] Bolte, Matthias ; Sievers, Michael ; Birkenheuer, Georg ; Niehörster, Oliver ; Brinkmann, André: Non-intrusive virtualization management using libvirt. In: Proceedings of the Conference on Design, Automation and Test in Europe European Design and Automation Association, 2010, S. 574–579

[BT04] Baryamureeba, Venansius ; Tushabe, Florence: The enhanced digital investigation process model. In: Proceedings of the Fourth Digital Forensic Research Workshop, 2004, S. 1–9

[Bug13] Bugzilla, Redhat: Bug 498981 - tcpdump cannot deal with 802.1q vlan tag. Online. https://bugzilla.redhat.com/show_bug.cgi?id=498981# c4. Version:März 2013

[Bun09] Bundesamt für Sicherheit in der Informationstechnik: Kurzstudie zu Gefährdungen und Massnahmen beim Einsatz von MPLS. (2009), März, Nr. 1.5

[Bun11] Bundesamt für Sicherheit in der Informationstechnik: Leitfaden IT-Forensik. (2011), März

246 Literaturverzeichnis

[BW11] Birk, Dominik ; Wegener, Christoph: Technical Issues of Forensic Investiga- tions in Cloud Computing Environments. In: Systematic Approaches to Digital Forensic Engineering, IEEE, 2011, S. 1–10

[BW16] Betz, Lennart ; Widhalm, Thomas: Icinga 2: Ein praktischer Einstieg ins Monitoring. dpunkt.verlag, 2016

[BYDD+10] Ben-Yehuda, Muli ; Day, Michael D. ; Dubitzky, Zvi ; Factor, Michael ; Har’El, Nadav ; Gordon, Abel ; Liguori, Anthony ; Wasserman, Orit ; Yassour, Ben-Ami: The Turtles Project: Design and Implementation of Nested Virtualization. In: OSDI Bd. 10, 2010, S. 423–436

[Car02] Carrier, Brian: Open source digital forensics tools: The legal argument / stake. 2002. – Forschungsbericht

[Car03] Carrier, Brian: Deﬁning Digital Forensic Examination and Analysis Tool Using Abstraction Layers. In: International Journal of Digital Evidence 1 (2003), Nr. 4

[Cas04] Casey, Eoghan: Network traﬃc as a source of evidence: tool strengths, weak- nesses, and future needs. In: Digital Investigation 1 (2004), Nr. 1, S. 28–43

[Cas11] Casey, Eoghan: Digital evidence and computer crime: Forensic science, computers, and the internet. Academic press, 2011

[CB10] Chowdhury, N.M. Mosharaf K. ; Boutaba, Raouf: A Survey of Network Virtualization. In: Compututer Networking 54 (2010), April, Nr. 5, S. 862–876

[CC90] Chikofsky, Elliot J. ; Cross, James H.: Reverse engineering and design recovery: A taxonomy. In: IEEE software 7 (1990), Nr. 1, S. 13–17

[CC96] Carter, Robert L. ; Crovella, Mark E.: Measuring bottleneck link speed in packet-switched networks. In: Performance evaluation 27 (1996), S. 297–318

[CCR09] Callegati, F. ; Cerroni, W. ; Ramilli, M.: Man-in-the-Middle Attack to the HTTPS Protocol. In: Security Privacy, IEEE 7 (2009), Jan, Nr. 1, S. 78–81

[CFH+05] Clark, Christopher ; Fraser, Keir ; Hand, Steven ; Hansen, Jacob G. ; Jul, Eric ; Limpach, Christian ; Pratt, Ian ; Warfield, Andrew: Live Migration of Virtual Machines. In: Proceedings of the 2nd Conference on Symposium on Networked Systems Design & Implementation - Volume 2. Berkeley, CA, USA : USENIX Association, 2005 (NSDI’05), S. 273–286

247 Literaturverzeichnis

[CFSD90] Case, J. D. ; Fedor, M. ; Schoffstall, M. L. ; Davin, C.: RFC 1157: Simple Network Management Protocol (SNMP). Mai 1990

[CG95] Callaghan, B. ; Gilligan, R.: Snoop Version 2 Packet Capture File For- mat. RFC 1761 (Informational). http://www.ietf.org/rfc/rfc1761.txt. Version:Februar 1995 (Request for Comments)

[Cha14] Chappell, Laura ; University, Chappell (Hrsg.): Troubleshooting with wireshark. Protocol Analysis Institute, Inc, 2014

[Che14] Chen, Hai Y.: Design and Implement of a Computer Forensics Model for Cloud Environments. In: Applied Mechanics and Materials Bd. 599 Trans Tech Publ, 2014, S. 1848–1851

[Cis12a] Cisco Systems Inc: Cisco IOS Software Conﬁguration Guide, Release 12.2(33)SXH and Later Releases. Online. http://www. cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12- 2SX/configuration/guide/book.pdf. Version:2012. – Letzter Zugriﬀ: 28.06.2017

[Cis12b] Cisco Systems Inc: IP Overlapping Address Pools. Online. http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_ ipv4/configuration/xe-3s/asr1000/IPv4-xe-3s-asr1000-book/IP- overlap-addr-pools.pdf. Version:12 2012. – Letzter Zugriﬀ: 28.06.2017

[CIS15a] Cable II, Patrick T. ; Schear, Nabil: Spyglass: demand-provisioned Linux containers for private network access. In: 29th Large Installation System Admi- nistration Conference (LISA15), 2015, S. 37–48

[Cis15b] Cisco Systems Inc: Cisco Global Cloud Index: Forecast and Methodology, 2014-2019. Online. http://www.cisco.com/c/en/us/solutions/service- provider/global-cloud-index-gci/index.html. Version:2015. – Letzter Zugriﬀ: 28.06.2017

[Cis15c] Cisco Systems Inc: Cisco Visual Networking Index: Forecast and Methodology, 2014–2019. Online. http://www.cisco.com/c/en/ us/solutions/collateral/service-provider/ip-ngn-ip-next- generation-network/white_paper_c11-481360.pdf. Version:Mai 2015. – Letzter Zugriﬀ: 28.06.2017

[Cis15d] Cisco Systems Inc: Enhanced Interior Gateway Routing Protocol. On- line. http://www.cisco.com/c/en/us/support/docs/ip/enhanced-

248 Literaturverzeichnis

interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html. Version:Januar 2015. – Letzter Zugriﬀ: 28.06.2017

[CKX+13] Chung, Chun-Jen ; Khatkar, Pankaj ; Xing, Tianyi ; Lee, Jeongkeun ; Huang, Dijiang: NICE: Network intrusion detection and countermeasure selection in virtual network systems. In: IEEE transactions on dependable and secure computing 10 (2013), Nr. 4, S. 198–211

[Cle06] Clemm, Alexander: Network Management Fundamentals. Cisco Press, 2006

[Clo53] Clos, Charles: A Study of Non-Blocking Switching Networks. In: Bell System Technical Journal 32 (1953), Nr. 2, S. 406–424

[CPS+02] Corey, Vicka ; Peterman, Charles ; Shearin, Sybil ; Greenberg, Micha- el S. ; Van Bokkelen, James: Network forensics analysis. In: IEEE Internet Computing 6 (2002), Nr. 6, S. 60–66

[CS+03] Carrier, Brian ; Spafford, Eugene H. u.a.: Getting physical with the Digital investigation process. In: International Journal of Digital Evidence 2 (2003), Nr. 2, S. 1–20

[CS08] Casey, Eoghan ; Stellatos, Gerasimos J.: The impact of full disk encryption on digital forensics. In: ACM SIGOPS Operating Systems Review 42 (2008), Nr. 3, S. 93–98

[CSP12] Chuvakin, A. ; Schmidt, K. ; Phillips, C.: Logging and Log Management: The Authoritative Guide to Dealing with Syslog, Audit Logs, Events, Alerts and other IT Noise. Elsevier, 2012

[Cur15] Curran, John: ARIN IPv4 Free Pool Reaches Zero. Onli- ne. https://www.arin.net/vault/announcements/2015/20150924.html. Version:September 2015. – Letzter Zugriﬀ: 28.06.2017

[CZM14] Chen, Shaxun ; Zeng, Kai ; Mohapatra, Prasant: Eﬃcient data capturing for network forensics in cognitive radio networks. In: Networking, IEEE/ACM Transactions on 22 (2014), Nr. 6, S. 1988–2000

[DAKF] Deri, Luca ; A, Netikos S. P. ; Km,Via DelB. ; Figuretta, Loc L.: Improving Passive Packet Capture: Beyond Device Polling. In: In Proceedings of SANE 2004

249 Literaturverzeichnis

[Dal14] Dalziel, Henry: How to Defeat Advanced Malware: New Tools for Protection and Forensics. Syngress, 2014

[DB11] Day, David ; Burns, B: A performance analysis of snort and suricata network intrusion detection and prevention engines. In: Fifth International Conference on Digital Society, Gosier, Guadeloupe, 2011, S. 187–192

[DDSMS14] Dashevskyi, Stanislav ; Dos Santos, Daniel R. ; Massacci, Fabio ; Sa- betta, Antonino: TestREx: a testbed for repeatable exploits. In: 7th Workshop on Cyber Security Experimentation and Test (CSET 14), 2014

[Den14] Denton, James: Learning OpenStack Networking (Neutron). Packt Publishing, 2014

[DF11] Dewald, Andreas ; Freiling, Felix C.: Forensische Informatik. Books on Demand GmbH, 2011. – 1–123 S.

[DG16] Davie, Bruce ; Gross, Jesse: A Stateless Transport Tunneling Protocol for Network Virtualization (STT) / Internet Engineering Task Force. Version: April 2016. https://datatracker.ietf.org/doc/html/draft-davie-stt-08. IETF, April 2016 (draft-davie-stt-08). – Internet-Draft. – Work in Progress

[DH95] Deering, S. ; Hinden, R.: RFC 1883: Internet Protocol, Version 6 (IPv6) Spe- ciﬁcation. ftp://ftp.internic.net/rfc/rfc1883.txt,ftp://ftp.math. utah.edu/pub/rfc/rfc1883.txt. Version:Dezember 1995. – Obsoleted by RFC2460. Status: PROPOSED STANDARD.

[Dij59] Dijkstra, E. W.: A Note on Two Problems in Connexion with Graphs. In: NUMERISCHE MATHEMATIK 1 (1959), Nr. 1, S. 269–271

[DIN15] DIN-Normenausschuss Informationstechnik und Anwendungen: Information technology - Security techniques - Guidelines for the analysis and interpretation of digital evidence ISO/IEC 27042:2015-06 (E). 2015

[DIN16] DIN-Normenausschuss Informationstechnik und Anwendungen: Informationstechnik - IT-Sicherheitsverfahren - Grundsätze und Prozesse für die Untersuchung von Vorfällen ISO/IEC 27043:2015. 2016

[DKK16] Dua, Rajdeep ; Kohli, Vaibhav ; Konduri, Santosh K.: Learning Docker Networking. Packt Publishing, 2016

250 Literaturverzeichnis

[DKO11] Delport, Waldo ; Köhn, Michael ; Olivier, Martin S.: Isolating a cloud instance for a digital forensic investigation. In: ISSA, 2011

[DMBC14] Deri, Luca; Martinelli, Mario ; Bujlow, Tomasz ; Cardigliano, Alfredo: nDPI: Open-source high-speed deep packet inspection. In: Wireless Communi- cations and Mobile Computing Conference (IWCMC), 2014 International IEEE, 2014, S. 617–622

[DMS04] Dingledine, Roger ; Mathewson, Nick ; Syverson, Paul: Tor: The second- generation onion router. 2004. – Forschungsbericht

[DMSK17] Dayal, Neelam ; Maity, Prasenjit ; Srivastava, Shashank ; Khondoker, Rahamatullah: Research Trends in Security and DDoS in SDN. In: Security and Communication Networks (2017)

[DRK14] Dua, Rajdeep ; Raja,AR.; Kakadia, Dharmesh: Virtualization vs containerization to support paas. In: 2014 IEEE International Conference on Cloud Engineering (IC2E) IEEE, 2014, S. 610–614

[DS13] Dykstra, Josiah ; Sherman, Alan T.: Design and implementation of FROST: Digital forensic tools for the OpenStack cloud computing platform. In: Digital Investigation 10 (2013), S. 587–595

[DW16] Du, Jiang ; Wu, Sheng: DCFF: a container forensics framework based on Docker. In: 2016 3rd International Conference on Materials Engineering, Ma- nufacturing Technology and Control Atlantis Press, 2016

[EBS13] Elisha, Simon ; Bromberger, James ; Stanski, Peter: Migrating AWS Resources to a New Region / Amazon Web Services. Version: März 2013. http://media.amazonwebservices.com/AWS_Migrate_Resources_ To_New_Region.pdf. 2013. – Forschungsbericht. – Letzter Zugriﬀ: 28.06.2017

[EKMV04] Estan, Cristian ; Keys, Ken ; Moore, David ; Varghese, George: Building a better NetFlow. In: ACM SIGCOMM Computer Communication Review Bd. 34 ACM, 2004, S. 245–256

[ERWC14] Emmerich, Paul ; Raumer, Daniel ; Wohlfart, Florian ; Carle, Georg: Performance characteristics of virtual switching. In: 2014 IEEE 3rd International Conference on Cloud Networking (CloudNet) IEEE, 2014, S. 120–125

[Eur12] European Telecommunications Standards Institute: Network Func- tions Virtualisation - Introductory White Paper / European Telecommunicati-

251 Literaturverzeichnis

ons Standards Institute. Version:Oktober 2012. https://portal.etsi.org/ NFV/NFV_White_Paper.pdf. 2012. – Forschungsbericht. – Letzter Zugriﬀ: 28.06.2017

[Eur14] European Telecommunications Standards Institute: Network Func- tions Virtualisation (NFV) - White Paper 3 / European Telecommunications Standards Institute. Version:2014. https://portal.etsi.org/Portals/0/ TBpages/NFV/Docs/NFV_White_Paper3.pdf. 2014. – Forschungsbericht. – Letzter Zugriﬀ: 28.06.2017

[Eur16] European Telecommunications Standards Institute: Lawful Inter- ception (LI); Cloud/Virtual Services for Lawful Interception (LI) and Retained Data (RD) / European Telecommunications Standards Institute. 2016 (ETSI TR 101 567). – Forschungsbericht

[F5 15] F5 Networks Inc.: Virtual Solutions for Your NFV Environment. On- line. https://www.f5.com/pdf/solution-center/network-functions- virtualization-nfv-solution-overview.pdf. Version:2015. – Letzter Zugriﬀ: 28.06.2017

[FBSJW08] Figueiredo, Renato ; Boykin, P. O. ; St. Juste, Pierre ; Wolinsky, David: Facilitating the Deployment of Ad-hoc Virtual Organizations with Inte- grated Social and Overlay Networks. In: Proceedings of the 17th International Symposium on High Performance Distributed Computing. New York, NY, USA : ACM, 2008 (HPDC ’08), S. 201–204

[FD10] Fusco, Francesco ; Deri, Luca: High speed network traﬃc analysis with commodity multi-core systems. In: Proceedings of the 10th ACM SIGCOMM conference on Internet measurement ACM, 2010, S. 218–224

[Fer13] Fernandez, Marcial P.: Comparing OpenFlow Controller Paradigms Scalabili- ty: Reactive and Proactive. In: Proceedings of the 2013 IEEE 27th International Conference on Advanced Information Networking and Applications. Washington, DC, USA : IEEE Computer Society, 2013 (AINA ’13), S. 1009–1016

[FF62] Ford, LR ; Fulkerson, Delbert R.: Flows in networks. Bd. 1962. Princeton Princeton University Press, 1962

[FF14] François, Jérôme ; Festor, Olivier: Anomaly traceback using software deﬁ- ned networking. In: 2014 IEEE International Workshop on Information Forensics and Security (WIFS), IEEE, 2014, S. 203–208

252 Literaturverzeichnis

[FFML13] Farinacci,D.; Fuller, V. ; Meyer,D.; Lewis, D.: Locator/ID Separation Protocol (LISP) / Internet Engineering Task Force. 2013 (draft-ietf-lisp-24). – Internet-Draft. – Work in Progress

[FHD+09] Fusco, Francesco ; Huici, Felipe ; Deri, Luca ; Niccolini, Saverio ; Ewald, Thilo: Enabling high-speed and extensible real-time communications monitoring. In: 2009. IM’09. IFIP/IEEE International Symposium on Integrated Network Management IEEE, 2009, S. 343–350

[FHH+03] Foong, A.P. ; Huff, T.R. ; Hum, H.H. ; Patwardhan, J.P. ; Regnier, G.J.: TCP performance re-visited. In: Performance Analysis of Systems and Software, 2003. ISPASS. 2003 IEEE International Symposium on, 2003, S. 70–79

[Fif14] Fifield, Tom: OpenStack operations guide: [set up and manage your Open- Stack cloud]. 1. ed. Beijing and Köln : O’Reilly, 2014

[Fir15a] FireEye Security: Four Things to Consider When Building a Network Fo- rensics Storage Architecture / FireEye Inc. 2015. – Forschungsbericht

[Fir15b] FireEye Security: Out of pocket: A Comprehensive Mobile Threat Assess- ment of 7 Million iOS and Android Apps / FireEye Inc. 2015. – Forschungsbe- richt

[For02] Forte, Dario: Analyzing the Diﬃculties in Backtracking the Onion Router’s Traﬃc. In: Proceedings of the 2002 Digital Forensics Research Workshop, 2002

[Fre12] Freiling, Felix: Neueste Entwicklungen im Bereich der Mobilfunkforen- sik. Online. http://www.anwendertag-forensik.de/content/dam/ anwendertag-forensik/de/documents/2012/Vortrag_Freiling.pdf. Version:2012, Abruf: 12.01.2014. – Letzter Zugriﬀ: 28.06.2017

[Fre13] Fredhsu: OVSDB Client in Python. https://github.com/fredhsu/py- ovsdb-client. Version:2013. – Letzter Zugriﬀ: 28.06.2017

[Gao11] Gao Hongtao: Forensic Method Analysis Involving VoIP Cri- me. (2011). http://origin-www.computer.org/csdl/proceedings/kam/ 2011/4547/00/4547a241.pdf. – Letzter Zugriﬀ: 28.06.2017

[Gar97] Garfinkel, Simson: Web security and commerce: [risks technologies and strategies]. 1. ed. Sebastopol, Kalifornien : O’Reilly, 1997

253 Literaturverzeichnis

[Gar07] Garfinkel, Simson: Anti-forensics: Techniques, detection and countermea- sures. In: 2nd International Conference on i-Warfare and Security Bd. 20087, 2007, S. 77–84

[Gar08] Garcia, Luis M. ; Hakin9 (Hrsg.): Programming with Libpcap - Sniﬃng the network from our own application. Online. http:// recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf. Version:2008. – Letzter Zugriﬀ: 28.06.2017

[Ger16] Gerhards, Rainer: ﬃcient Normalization of IT Log Messages under Realtime Conditions, Fernunivsität in Hagen, Diplomarbeit, 2016

[Ges14] Geschonneck, Alexander: Computer-Forensik (iX Edition): Computerstrafta- ten erkennen, ermitteln, aufklären. dpunkt.verlag, 2014

[GJN11] Gill, Phillipa ; Jain, Navendu ; Nagappan, Nachiappan: Understanding network failures in data centers: measurement, analysis, and implications. In: ACM SIGCOMM Computer Communication Review Bd. 41 ACM, 2011, S. 350– 361

[GKP+08] Gude, Natasha ; Koponen, Teemu ; Pettit, Justin ; Pfaff, Ben ; Casado, Martín ; McKeown, Nick ; Shenker, Scott: NOX: Towards an Operating System for Networks. In: SIGCOMM 38 (2008), Juli, Nr. 3, S. 105–110

[GLB13] Graziano, Mariano ; Lanzi, Andrea ; Balzarotti, Davide: Hypervisor memory forensics. In: RAID 2013, 16th International Symposium on Research in Attacks, Intrusions, and Defenses, 23-25 October 2013, Saint Lucia, USA, 2013

[GLMP01] German, M.G. ; Leone, F.S. ; Macauley, D.W. ; Paul, L.M.: Sys- tem and method for addressing and tracing patch cords in a dedicated telecommunications system. https://www.google.com/patents/US6285293. Version:September 4 2001. – US Patent 6,285,293

[GLS10] Grobler, C. P. ; Louwrens, C. P. ; Solms, S. H.: A Multi-component View of Digital Forensics. In: 2010 International Conference on Availability, Reliability and Security, 2010, S. 647–652

[GME12] Guillen, Edward ; MaríaSossa, Ana ; Estupiñán, Edith P.: Performance Analysis over Software Router vs. Hardware Router: A Practical Approach. In: Proceedings of the World Congress on Engineering and Computer Science Bd. 2, 2012, S. 24–26

254 Literaturverzeichnis

[GMS92] Garcia-Molina,H.; Salem, K.: Main Memory Database Systems: An Over- view. In: IEEE Transactions on Knowledge and Data Engineering 4 (1992), Dezember, Nr. 6, S. 509–516

[GPGA12] Gember, Aaron ; Prabhu, Prathmesh ; Ghadiyali, Zainab ; Akella, Adi- tya: Toward Software-deﬁned Middlebox Networking. In: Proceedings of the 11th ACM Workshop on Hot Topics in Networks. New York, NY, USA : ACM, 2012 (HotNets-XI), S. 7–12

[GR97] Gennaro, Rosario ; Rohatgi, Pankaj: How to sign digital streams. In: Annual International Cryptology Conference Springer, 1997, S. 180–197

[GR03] Garfinkel, Tal ; Rosenblum, Mendel: A Virtual Machine Introspection Based Architecture for Intrusion Detection. In: NDSS, The Internet Society, 2003

[Gro05] Grossman, Leonid: Large receive oﬄoad implementation in neterion 10GbE Ethernet driver. In: Linux Symposium, 2005, S. 195

[GS13] Grabski, Szymon ; Szczypiorski, Krzysztof: Network steganalysis: Detec- tion of steganography in IEEE 802.11 wireless networks. In: Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2013 5th International Congress on IEEE, 2013, S. 13–19

[GSG+14] Gross, J ; Sridhar, T ; Garg, P ; Wright, C ; Ganga, I: Geneve: Ge- neric network virtualization encapsulation. In: Internet Engineering Task Force, Internet Draft (2014)

[GSK05] Gola, Peter ; Schomerus, Rudolf ; Klug, Christoph: BDSG - Bundesdaten- schutzgesetz : Kommentar. 8. überarbeitete und ergänzte Auﬂage. München : Beck, 2005

[GSL13] Gugelmann, David ; Schatzmann, Dominik ; Lenders, Vincent: Horizon Extender: Long-term Preservation of Data Leakage Evidence in Web Traﬃc. In: Proceedings of the 8th ACM SIGSAC Symposium on Information, Computer and Communications Security. New York, NY, USA : ACM, 2013 (ASIA CCS ’13), S. 499–504

[GTDVMFV09] Garcia-Teodoro, Pedro ; Diaz-Verdejo, J ; Maciá-Fernández, Gabriel ; Vázquez, Enrique: Anomaly-based network intrusion detection: Techniques, systems and challenges. In: Computers & Security 28 (2009), Nr. 1, S. 18–28

255 Literaturverzeichnis

[Gup12] Gupta, Sunil: Logging and Monitoring to Detect Network Intrusions and Com- pliance Violations in the Environment / SANS Institute. 2012. – Forschungs- bericht

[GW15] Garg, P. ; Wang, Y.: NVGRE: Network Virtualization Using Generic Routing Encapsulation / RFC Editor. IETF, September 2015 (7637). – RFC

[Har06] Harris, Ryan: Arriving at an anti-forensics consensus: Examining how to deﬁne and control the anti-forensics problem. In: Digital investigation 3 (2006), S. 44– 49

[Har15] Harris, Guy: Libpcap File Format. Online. https://wiki.wireshark. org/Development/LibpcapFileFormat. Version:2015. – Letzter Zugriﬀ: 28.06.2017

[Hei13] Heinen, Edmund: Das Zielsystem der Unternehmung: Grundlagen betriebs- wirtschaftlicher Entscheidungen. Bd. 1. Springer, 2013

[Hen12] Heng, Addy Yeow C.: Bit-Twist. http://bittwist.sourceforge.net. Version:2012. – Letzter Zugriﬀ: 28.06.2017

[HN08] Hay, Brian ; Nance, Kara: Forensics examination of volatile system data using virtual introspection. In: ACM SIGOPS Operating Systems Review 42 (2008), Nr. 3, S. 74–82

[HNIS11] Hirofuchi, Takahiro ; Nakada, Hidemoto ; Itoh, Satoshi ; Sekiguchi, Satoshi: Reactive Consolidation of Virtual Machines Enabled by Postcopy Live Migration. In: Proceedings of the 5th International Workshop on Virtualization Technologies in Distributed Computing. New York, NY, USA : ACM, 2011 (VTDC ’11), S. 11–18

[HSMA14] Hawilo, Hassan ; Shami, Abdallah ; Mirahmadi, Maysam ; Asal, Rasool: NFV: state of the art, challenges, and implementation in next generation mobile networks (vEPC). In: IEEE Network 28 (2014), Nr. 6, S. 18–26

[HZ12] Hunt, Ray ; Zeadally, Sherali: Network Forensics: An Analysis of Techniques, Tools, and Trends. In: Computer 45 (2012), Nr. 12, S. 36–43

[IAGP15] Iqbal, Asif ; Alobaidli, Hanan ; Guimaraes, Mario ; Popov, Oliver: Sand- boxing: aid in digital forensic research. In: Proceedings of the 2015 Information Security Curriculum Development Conference ACM, 2015, S. 3

256 Literaturverzeichnis

[IDGM01] Iannaccone, Gianluca ; Diot, Christophe ; Graham, Ian ; McKeown, Nick: Monitoring Very High Speed Links. In: Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement. New York, NY, USA : ACM, 2001 (IMW ’01), S. 267–271

[IEE05] IEEE Computer Society: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges / IEEE Standard for Local and metropolitan area networks. 2005. – Forschungsbericht

[IG13a] IT-Grundschutz: M 5.169 Systemarchitektur einer Webanwendung / Bun- desamt für Sicherheit in der Informationstechnik. 2013. – Forschungsbericht

[IG13b] IT-Grundschutz: M 5.61 Geeignete physikalische Segmentierung / Bundes- amt für Sicherheit in der Informationstechnik. 2013. – Forschungsbericht

[IG13c] IT-Grundschutz: M 5.62 Geeignete logische Segmentierung / Bundesamt für Sicherheit in der Informationstechnik. 2013. – Forschungsbericht

[IHHGA11] Ibrahim, Amani S. ; Hamlyn-Harris, James ; Grundy, John ; Almor- sy, Mohamed: CloudSec: a security monitoring appliance for Virtual Machines in the IaaS cloud model. In: Network and System Security (NSS), 2011 5th International Conference on IEEE, 2011, S. 113–120

[ixi17] ixia: IXIA PHANTOM VTAPTM WITH TAPFLOWTM FILTERING, 2017. https://www.ixiacom.com/sites/default/files/2016-07/V-DS- Phantom-vTap.pdf

[JD99] Johnson, D. ; Deering, S.: RFC 2526: Reserved IPv6 Subnet Anycast Ad- dresses. Internet Requests for Comments, March 1999

[Jer17] Jerram, Neil: Feature Classiﬁcation. Online. http://docs.openstack.org/ developer/nova/feature_classification.html. Version:2017. – Letzter Zugriﬀ: 28.06.2017

[JMW+11] Jayasinghe, Deepal ; Malkowski, Simon ; Wang, Qingyang ; Li, Jack ; Xiong, Pengcheng ; Pu, Calton: Variations in performance and scalability when migrating n-tier applications to diﬀerent clouds. In: Cloud Computing (CLOUD), 2011 IEEE International Conference on IEEE, 2011, S. 73–80

[JS15] Jafari, Fakeeha ; Satti, Rabail S.: Comparative Analysis of Digital Forensic Models. In: Journal of Advances in Computer Networks 3 (2015), Nr. 1

257 Literaturverzeichnis

[JZH+14] Jarschel, Michael ; Zinner, Thomas ; Hoßfeld, Tobias ; Tran-Gia, Phuoc ; Kellerer, Wolfgang: Interfaces, attributes, and use cases: A compass for SDN. In: Communications Magazine, IEEE 52 (2014), Nr. 6, S. 210–217

[KAI14] Khattak, Zuhran K. ; Awais, Muhammad ; Iqbal, Adnan: Performance evaluation of OpenDaylight SDN controller. In: 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS) IEEE, 2014, S. 671–676

[Kap13] Kappes, M.: Netzwerk- und Datensicherheit: Eine praktische Einführung. Springer, 2013

[KC14] Kolaczyk, Eric D. ; Csárdi, Gábor: Statistical analysis of network data with R. Bd. 65. Springer, 2014

[KCGD06] Kent, Karen ; Chevalier, Suzanne ; Grance, Tim ; Dang, Hung: Gui- de to integrating forensic techniques into incident response. In: NIST Special Publication (2006), S. 800–86

[KDY+06] Kumar, Sailesh ; Dharmapurikar, Sarang ; Yu, Fang ; Crowley, Patrick ; Turner, Jonathan: Algorithms to accelerate multiple regular expressions matching for deep packet inspection. In: ACM SIGCOMM Computer Commu- nication Review 36 (2006), Nr. 4, S. 339–350

[KEBZEK12] Khiyaita, A ; El Bakkali, H ; Zbakh, M ; El Kettani, Daﬁr: Load balancing cloud computing: State of art. In: Network Security and Systems (JNS2), 2012 National Days of IEEE, 2012, S. 106–109

[Ker17] Kernel.org: Packet MMAP. https://www.kernel.org/doc/ Documentation/networking/packet_mmap.txt. Version:2017. – Letzter Zugriﬀ: 28.06.2017

[Kev96] Kevin Delgadillo: NetFlow Services and Applications. Online. http:// ehealth-spectrum.ca.com/download/netflow.pdf. Version:1996. – Letz- ter Zugriﬀ: 28.06.2017

[KEX12] Kangarlou, Ardalan ; Eugster, Patrick ; Xu, Dongyan: VNsnap: Taking snapshots of virtual networked infrastructures in the cloud. In: IEEE Transactions on Services Computing 5 (2012), Nr. 4, S. 484–496

[KGW+16] Khan, Suleman ; Gani, Abdullah ; Wahab, Ainuddin Wahid A. ; Shiraz, Muhammad ; Ahmad, Iftikhar: Network forensics: Review, taxonomy, and open

258 Literaturverzeichnis

challenges. In: Journal of Network and Computer Applications 66 (2016), S. 214–235

[Kin15] Kingston Smiler. S: OpenFlow Cookbook. Packt Publishing, 2015

[KM14] Kawashima, Ryota ; Matsuo, Hiroshi: Implementation and performance analysis of STT tunneling using vNIC oﬄoading framework (CVSW). In: IEEE 6th International Conference on Cloud Computing Technology and Science (Cloud- Com) IEEE, 2014, S. 929–934

[Koc11] Koch, Robert: Systemarchitektur zur Ein-und Ausbruchserkennung in ver- schlüsselten Umgebungen. Books on Demand GmbH, 2011

[KOE06] Köhn, Michael ; Olivier, Martin S. ; Eloff, Jan H.: Framework for a Digital Forensic Investigation. In: ISSA, 2006, S. 1–7

[KPJ13] Kapil, D.; Pilli, E. S. ; Joshi, R. C.: Live virtual machine migration techniques: Survey and research challenges. In: 2013 IEEE 3rd International Advance Computing Conference (IACC), 2013, S. 963–969

[KR08] Kurose, James F. ; Ross, Keith W.: Computernetzwerke: Der Top-Down- Ansatz. Pearson Deutschland GmbH, 2008

[KS12] Kofler, Michael ; Spenneberg, Ralf: KVM für die Server-Virtualisierung: Von Konﬁguration und Administration bis Clustering und Cloud. München [u.a.] : Addison-Wesley, 2012 (Open source library)

[KXRE07] Kangarlou, Ardalan ; Xu, Dongyan ; Ruth, Paul ; Eugster, Patrick: Ta- king snapshots of virtual networked environments. In: Virtualization Technology in Distributed Computing (VTDC), 2007 Second International Workshop on IEEE, 2007, S. 1–8

[KZCG12] Khurshid, Ahmed ; Zhou, Wenxuan ; Caesar, Matthew ; Godfrey, P. B.: VeriFlow: verifying network-wide invariants in real time. In: HotSDN, 2012

[KZMB14] Khondoker, Rahamatullah ; Zaalouk, Adel ; Marx, Ronald ; Bayarou, Kpatcha: Feature-based comparison and selection of Software Deﬁned Networ- king (SDN) controllers. In: 2014 World Congress on Computer Applications and Information Systems (WCCAIS) IEEE, 2014, S. 1–7

259 Literaturverzeichnis

[LBKH16] Liang, Chen ; Benson, Theophilus ; Kanuparthy, Partha ; He, Yihua: Fin- ding Needles in the Haystack: Harnessing Syslogs for Data Center Management. In: Computing Research Repository abs/1605.06150 (2016)

[LBOS16] Lillis, David ; Becker, Brett ; O’Sullivan, Tadhg ; Scanlon, Mark: Cur- rent Challenges and Future Research Areas for Digital Forensic Investigation. In: Computing Research Repository (2016)

[LCPD14] Li, Fudong ; Clarke, Nathan ; Papadaki, Maria ; Dowland, Paul: Active authentication for mobile devices utilising behaviour proﬁling. In: International journal of information security 13 (2014), Nr. 3, S. 229–244

[LCX13] Liu, Yan H. ; Chen, Guo L. ; Xie, Lili: An Email Forensics Analysis Method Based on Social Network Analysis. In: 2013 International Conference on Cloud Computing and Big Data (CloudCom-Asia), 2013, S. 563–569

[Lea10] Leavitt, Neal: Will NoSQL databases live up to their promise? In: Computer 43 (2010), Nr. 2

[LEBC+12] Lewin-Eytan, Liane ; Barabash, Katherine ; Cohen, Rami ; Jain, Vinit ; Levin, Anna: Designing modular overlay solutions for network virtualization. In: IBM Technical Paper (2012)

[Les13] Lesovsky, Alexey: Getting Started with OVirt 3.3. Packt Publishing, 2013

[Lig90] Liggesmeyer, P.: Modultest und Modulveriﬁkation – State of the Art. Mann- heim, Germany : BI Wissenschaftsverlag, 1990. – 321 S.

[Lig02] Liggesmeyer, Peter: Software-Qualität - Testen, Analysieren und Veriﬁzieren von Software. Heidelberg/Berlin : Spektrum Akademischer Verlag, 2002. – 4 S.

[Lip06] Lipp, Manfred: VPN - Virtuelle Private Netzwerke: Aufbau und Sicherheit. Pearson Deutschland, 2006

[LLK+10] Lam, Cedric F. ; Liu, Hong ; Koley, Bikash ; Zhao, Xiaoxue ; Kamalov, Valey ; Gill, Vijay: Fiber Optic Communication Technologies: What’s Needed for Datacenter Network Operations. In: IEEE Communications Magazine Vol.48 No.7 (2010)

260 Literaturverzeichnis

[LLW+16] Lin, Ying-Dar ; Lin, Po-Ching ; Wang, Sheng-Hao ; Chen, I-Wei ; Lai, Yuan- Cheng: Pcaplib: A system of extracting, classifying, and anonymizing real packet traces. In: IEEE Systems Journal 10 (2016), Nr. 2, S. 520–531

[LT96] Lee, Edward K. ; Thekkath, Chandramohan A.: Petal: Distributed virtual disks. In: ACM SIGPLAN Notices Bd. 31 ACM, 1996, S. 84–92

[LvM02] Lidong Zhou ; van Renesse, R. ; Marsh, M.: Implementing IPv6 as a peer-to-peer overlay network. In: 21st IEEE Symposium on Reliable Distributed Systems, 2002, S. 347–351

[LYL04] Lakkaraju, Kiran ; Yurcik, William ; Lee, Adam J.: NVisionIP: netﬂow visualizations of system state for security situational awareness. In: Proceedings of the 2004 ACM workshop on Visualization and data mining for computer security ACM, 2004, S. 65–72

[MAB+08] McKeown, Nick ; Anderson, Tom ; Balakrishnan, Hari ; Parulkar, Guru ; Peterson, Larry ; Rexford, Jennifer ; Shenker, Scott ; Turner, Jonathan: OpenFlow: Enabling Innovation in Campus Networks. In: SIGCOMM 38 (2008), März, Nr. 2, S. 69–74

[Mai13] Mailinglist Open vSwitch: [ovs-discuss] iptables with ovs. https://mail.openvswitch.org/pipermail/ovs-discuss/2013- October/031337.html. Version:2013. – Letzter Zugriﬀ: 28.06.2017

[Mal98] Malkin, Gary S.: RFC 2453: RIP Version 2. Internet Requests for Comments, November 1998

[MAM09] Meghanathan, Natarajan ; Allam, Sumanth R. ; Moore, Loretta A.: Tools and techniques for Network Forensics. (2009)

[May16] Maynard, Christopher: Wireshark Tools. Online. https://wiki.wireshark. org/Tools#Monitoring.2Ftracing_tools. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[MC12] Martini, Ben ; Choo, Kim-Kwang R.: An integrated conceptual digital forensic framework for cloud computing. In: Digital Investigation 9 (2012), Nr. 2, S. 71–80

[McC16] McCauley, Murphy: About NOX. Online. http://www.noxrepo.org/nox/ about-nox/. Version:2016. – Letzter Zugriﬀ: 28.06.2017

261 Literaturverzeichnis

[McK99] McKemmish, Rodney: What is forensic computing? Australian Institute of Criminology Canberra, 1999

[MDD+14] Mahalingam, M. ; Dutt, D. ; Duda, K. ; Agarwal, P. ; Kreeger, L. ; Sridhar, T. ; Bursell, M. ; Wright, C.: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks. RFC 7348 (Informational). http://www.ietf.org/ rfc/rfc7348.txt. Version:August 2014 (Request for Comments)

[MDP+00] Milo´ičić, Dejan S. ; Douglis, Fred ; Paindaveine, Yves ; Wheeler, Richard ; Zhou, Songnian: Process Migration. In: ACM Computer Survey 32 (2000), September, Nr. 3, S. 241–299

[Mer14] Merkel, Dirk: Docker: Lightweight Linux Containers for Consistent Develop- ment and Deployment. In: Linux Journal 2014 (2014), März, Nr. 239

[Met99] Metz, Christopher: AAA protocols: authentication, authorization, and accounting for the Internet. In: Internet Computing 3 (1999), Nr. 6, S. 75–79

[MF93] McAuley, Anthony J. ; Francis, Paul: Fast routing table lookup using CAMs. In: INFOCOM’93. Proceedings. Twelfth Annual Joint Conference of the IEEE Computer and Communications Societies. Networking: Foundation for the Future, IEEE IEEE, 1993, S. 1382–1391

[MG11] Mell, Peter ; Grance, Timothy: The NIST Deﬁnition of Cloud Computing. In: National Institute for Standards and Technology Special Publication 800-145 (2011)

[MG14] Medina, Violeta ; García, Juan M.: A Survey of Migration Mechanisms of Virtual Machines. In: ACM Computer Survey 46 (2014), Januar, Nr. 3, S. 30:1–30:33

[MJ93] McCanne, Steven ; Jacobson, Van: The BSD Packet Filter: A New Archi- tecture for User-level Packet Capture. In: USENIX winter Bd. 46, 1993

[MKRC14] Momin, Orko ; Karakoyunlu, Cengiz ; Runde, Michael T. ; Chandy, John A.: Creating a Programmable Object Storage Stack. In: Proceedings of the 1st ACM International Workshop on Programmable File Systems. New York, NY, USA : ACM, 2014 (PFSW ’14), S. 3–10

262 Literaturverzeichnis

[MMPJ12] Mishra, A.K. ; Matta, P. ; Pilli, E.S. ; Joshi, R.C.: Cloud Forensics: State- of-the-Art and Research Challenges. In: 2012 International Symposium on Cloud and Services Computing (ISCOS), 2012, S. 164–170

[Mol17] Moloch.ch: Moloch. http://molo.ch. Version:2017. – Letzter Zugriﬀ: 28.06.2017

[Mot16] Motoki, Akihiro: Network virtualization system, physical node, and virtual interface identiﬁcation method in virtual machine. November 8 2016. – US Patent 9,489,224

[Moy98] Moy, John: RFC 2328: OSPF Version 2. Internet Requests for Comments, April 1998

[MS08] Mazurczyk, Wojciech ; Szczypiorski, Krzysztof: Steganography of VoIP streams. In: OTM Confederated International Conferences „On the Move to Meaningful Internet Systems“ Springer, 2008, S. 1001–1018

[MS11] Meinel, Christoph ; Sack, Harald: Internetworking - Technische Grundla- gen und Anwendungen. Online. http://www.hpi.uni-potsdam.de/meinel/ publikationen/books/internetworking.html. Version:2011. – Letzter Zugriﬀ: 28.06.2017

[MS13] Manzalini, Antonio ; Saracco, Roberto: Software Networks at the Edge: a shift of paradigm. In: IEEE SDN for Future Networks and Services (SDN4FNS) IEEE, 2013, S. 1–6

[MSG+16] Mijumbi, Rashid ; Serrat, Joan ; Gorricho, Juan-Luis ; Bouten, Niels ; De Turck, Filip ; Boutaba, Raouf: Network function virtualization: State-of- the-art and research challenges. In: IEEE Communications Surveys & Tutorials 18 (2016), Nr. 1, S. 236–262

[MSJ12] Mazurczyk, Wojciech ; Szczypiorski, Krzysztof ; Jankowski, Bartosz: Towards steganography detection through network traﬃc visualisation. In: Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2012 4th International Congress on IEEE, 2012, S. 947–954

[MSS13] Mazurczyk, Wojciech ; Smolarczyk, Milosz ; Szczypiorski, Krzysztof: On information hiding in retransmissions. In: Telecommunication Systems 52 (2013), Nr. 2, S. 1113–1121

263 Literaturverzeichnis

[MTRBH14] M. Tuexen, Ed. ; Risso, F. ; Bongertz, J. ; Harris, G.: PCAP Next Generation (PCAPNG) Dump File Format. Online. https://tools.ietf. org/html/draft-tuexen-opswg-pcapng-00. Version:Juni 2014. – Letzter Zugriﬀ: 28.06.2017

[MV14] Mumba, Emilio R. ; Venter, HS: Mobile forensics using the harmonised digital forensic investigation process. In: Information Security for South Africa (ISSA), 2014 IEEE, 2014, S. 1–10

[MVB13] Mann, Vijay ; Vishnoi, Anilkumar ; Bidkar, Sarvesh: Living on the edge: Monitoring network ﬂows at the edge in cloud data centers. In: 2013 Fifth Inter- national Conference on Communication Systems and Networks (COMSNETS) IEEE, 2013, S. 1–9

[MVM09] Miller, Frederic P. ; Vandome, Agnes F. ; McBrewster, John: Advanced Encryption Standard. (2009)

[MVTG14] Medved, Jan ; Varga, Robert ; Tkacik, Anton ; Gray, Ken: Opendaylight: Towards a model-driven sdn controller architecture. In: IEEE 15th International Symposium on IEEE, 2014, S. 1–6

[MZSU08] Mandagere, NagaPramod ; Zhou, Pin ; Smith, Mark A. ; Uttamchan- dani, Sandeep: Demystifying data deduplication. In: Douglis, Fred (Hrsg.): Middleware (Companion), ACM, 2008, S. 12–17

[Nat01] National Crime Justice: A Guide for First Responders. In: Electronic Crime Scene Investigation 187736 (2001)

[Nat04] National Institute of Justice: Forensic examination of digital evidence: a guide for law enforcement. U.S. Dept. of Justice, Oﬃce of Justice Programs, National Institute of Justice, 2004 (NIJ special report)

[Net12] Netgear.com: GS716T and GS724T Gigabit Smart Switches Software Administration Manual. http://www.downloads.netgear.com/files/GDC/ GS716TV2/GS716T_GS724T-SWA-October2012.pdf. Version:2012. – Letzter Zugriﬀ: 28.06.2017

[Neu94] Neuman, B. C.: Scale in Distributed Systems. In: Readings in Distributed Computing Systems, IEEE Computer Society Press, 1994, S. 463–489

[NG13] Nadeau, Thomas D. ; Gray, Kenneth: SDN: software deﬁned networks. Se- bastopol : O’Reilly, 2013

264 Literaturverzeichnis

[NIS14] NIST Cloud Computing Forensic Science Working Group: NIST Cloud Computing Forensic Science Challenges / National Institute of Standards and Techniques. 2014. – Draft NISTIR 8006

[Nol15] Nolte, Susanne: Schnell verteilt. In: iX (2015), November, Nr. 11, S. 80–83

[Nox13] NoxRepo: The POX Controller. https://github.com/noxrepo/pox. Version:2013. – Letzter Zugriﬀ: 28.06.2017

[NSV16] Naik, Priyanka ; Shaw, Dilip K. ; Vutukuru, Mythili: NFVPerf: Online performance monitoring and bottleneck detection for NFV. In: IEEE Conference on Network Function Virtualization and Software Deﬁned Networks (NFV-SDN) IEEE, 2016, S. 154–160

[Odo13] Odom, Wendell: Cisco CCNA routing and switching ICND2 200-101 official cert guide. Cisco Certified Network Associate routing and switching ICND2 200-101 official certification guide. Indianapolis, IN : Cisco Press, 2013

[OH13] Obermann,K.; Horneffer, M.: Datennetztechnologien für Next Generation Networks: Ethernet, IP, MPLS und andere. Springer, 2013

[Ohi14] Ohira, Kenji: Performance Evaluation of an OpenFlow-based Mirroring Switch on a Laptop/Raspberry Pi. In: Proceedings of The Ninth International Confe- rence on Future Internet Technologies. New York, NY, USA : ACM, 2014 (CFI ’14), S. 20:1–20:2

[OON+03] Olbert, Arthur ; O’Neill, David ; Neufeld, Christopher u.a.: Managing multiple virtual machines. April 10 2003. – US Patent App. 10/413,440

[Ope14] Open Network Foundation: OpenFlow Switch Speciﬁcation. Online. https://www.opennetworking.org/images/stories/downloads/sdn- resources/onf-specifications/openflow/openflow-switch- v1.3.4.pdf. Version:2014. – Letzter Zugriﬀ: 28.06.2017

[Ope15] Openvswitch.org: Open vSwitch Manual. Online. http://openvswitch. org/support/dist-docs/ovs-vsctl.8.html. Version:2015. – Letzter Zu- griﬀ: 28.06.2017

[Ope16] Open Network Foundation: 2016 SDN Controller Landscape / 2016 SD- NCentral LLC. 2016. – Forschungsbericht

265 Literaturverzeichnis

[OR+04] Orebaugh, Angela D. ; Ramirez, Gilbert u.a.: Ethereal packet sniﬃng. (2004)

[Ora90] Oran, D.: RFC 1142: OSI IS-IS Intra-domain Routing Protocol. Februar 1990. – Status: INFORMATIONAL.

[Ora16] Oracle: Hard Partitioning with Oracle VM Server for x86. On- line. http://www.oracle.com/technetwork/server-storage/vm/ovm- hardpart-168217.pdf. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[PAPL06] Pang, Ruoming ; Allman, Mark ; Paxson, Vern ; Lee, Jason: The Devil and Packet Trace Anonymization. In: Computer Communication Review 36 (2006), Januar, Nr. 1, S. 29–38

[Pax99] Paxson, Vern: Bro: a system for detecting network intruders in real-time. In: Computer networks 31 (1999), Nr. 23, S. 2435–2463

[PBD13] Pfaff, Ben ; B. Davie, Ed.: The Open vSwitch Database Management Pro- tocol. Online. https://tools.ietf.org/html/rfc7047. Version:Dezember 2013. – Letzter Zugriﬀ: 28.06.2017

[PC93] Piscitello, David M. ; Chapin, A L.: Open systems networking: TCP/IP and OSI. Addison-Wesley, 1993

[PC01] Palmer, Gary ; Corporation, Mitre ; Air (Hrsg.) ; Information (Hrsg.): A Road Map for Digital Forensic Research / Digital Forensic Research Workshop. Utica, New York, August 2001 (1). – Forschungsbericht

[PCLC10] Peng, T. ; Chen, X. ; Liu, H. ; Chen, K.: Data Reduction for Network Forensics Using Manifold Learning. In: 2nd International Workshop on Database Technology and Applications, 2010, S. 1–5

[PDM+03] Prasad, Ravi S. ; Dovrolis, Constantinos ; Mah, Bruce u.a.: The eﬀect of layer-2 store-and-forward devices on per-hop capacity estimation. In: INFO- COM 2003. Twenty-Second Annual Joint Conference of the IEEE Computer and Communications. IEEE Societies Bd. 3 IEEE, 2003, S. 2090–2100

[Pep11] Pepple, Ken: Deploying OpenStack: Creating open source clouds. Sebastopol, Kalifornien : O’Reilly, 2011

[Pet09] Petrovic, Darko: Virtual Machine Replication. In: EDIC Research Proposal (2009), S. 1–8

266 Literaturverzeichnis

[Pet16] Pettit, Justin: [ovs-discuss] Port number of tap interface changes after reboot. Online. https://mail.openvswitch.org/pipermail/ovs-discuss/2016- September/042538.html. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[Pet17] Pettit, Justin: [ovs-discuss] connecting switches. https://mail. openvswitch.org/pipermail/ovs-discuss/2017-June/044757.html. Version:2017. – Letzter Zugriﬀ: 28.06.2017

[PF09] Pelaez, Juan C. ; Fernandez, Eduardo B.: Voip network forensic patterns. In: 2009 Fourth International Multi-Conference on Computing in the Global Information Technology IEEE, 2009, S. 175–180

[PGBW07] Ponec, Miroslav ; Giura, Paul ; Brönnimann, Hervé ; Wein, Joel: Highly eﬃcient techniques for network forensics. In: Ning, Peng (Hrsg.) ; De Ca- pitani di Vimercati,Sabrina (Hrsg.) ; Syverson, Paul (Hrsg.): the 14th ACM conference, 2007, S. 150

[PGP+10] Pettit, Justin ; Gross, Jesse ; Pfaff, Ben ; Casado, Martin ; Crosby, Simon: Virtual switching in an era of advanced edges. In: In 2nd Workshop on Data Center - Converged and Virtual Ethernet Switching (DC CAVES, 2010

[PH15] Pírko, Jiří ; Hat, Red: Implementing Open vSwitch datapath using TC. In: Proceedings of Netdev 0.1 (2015)

[PHRF16] Parry, Jack ; Hunter, Daniel ; Radke, Kenneth ; Fidge, Colin: A network forensics tool for precise data packet capture and replay in cyber-physical systems. In: Proceedings of the Australasian Computer Science Week Multicon- ference ACM, 2016, S. 22

[PJN10a] Pilli, Emmanuel S. ; Joshi, Ramesh C. ; Niyogi, Rajdeep: Network forensic frameworks: Survey and research challenges. In: Digital Investigation 7 (2010), Nr. 1, S. 14–27

[PJN10b] Pilli, Emmanuel S. ; Joshi, RC ; Niyogi, Rajdeep: A generic framework for network forensics. In: International Journal of Computer Applications 1 (2010), Nr. 11

[PJN11] Pilli, E. S. ; Joshi, R. C. ; Niyogi, R.: Data Reduction by Identiﬁcation and Correlation of TCP/IP Attack Attributes for Network Forensics. In: Proceedings of the International Conference & Workshop on Emerging Trends in Technology. New York, NY, USA : ACM, 2011 (ICWET ’11), S. 276–283

267 Literaturverzeichnis

[PLV16] PLVision: Fast and lite web application for monitoring OVSDB (Open_vSwitch Database). https://github.com/PLVision/open_ vmonitor. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[PMT13] Poisel, Rainer ; Malzer, Erich ; Tjoa, Simon: Evidence and cloud computing: The virtual machine introspection approach. In: Journal of Wireless Mo- bile Networks, Ubiquitous Computing and Dependable Applications, JoWUA 4 (2013), Nr. 2, S. 135–152

[PN12] Parate, Sudhakar ; Nirkhi, Smita: A Review of Network Forensics Techniques for the Analysis of Web Based Attack. In: International Journal of Advanced Computer Research (IJACR) 2 (2012)

[Pol07] Pollitt, Mark M.: An ad hoc review of digital forensic models. In: Syste- matic Approaches to Digital Forensic Engineering, 2007. SADFE 2007. Second International Workshop on IEEE, 2007, S. 43–54

[PP09] Pajek, Przemyslaw ; Pimenidis, Elias: Computer anti-forensics methods and their impact on computer forensic investigation. In: International Conference on Global Security, Safety, and Sustainability Springer, 2009, S. 145–155

[PPA+09] Pfaff, Ben ; Pettit, Justin ; Amidon, Keith ; Casado, Martin ; Koponen, Teemu ; Shenker, Scott: Extending Networking into the Virtualization Layer. In: Hotnets, 2009

[PPK+15] Pfaff, Ben ; Pettit, Justin ; Koponen, Teemu ; Jackson, Ethan J. ; Zhou, Andy ; Rajahalme, Jarno ; Gross, Jesse ; Wang, Alex ; Stringer, Joe ; Shelar, Pravin u.a.: The Design and Implementation of Open vSwitch. In: NSDI, 2015, S. 117–130

[Pro17] Project Floodlight: Floodlight. http://www.projectfloodlight.org/ floodlight/. Version:2017. – Letzter Zugriﬀ: 28.06.2017

[Puj15] Pujolle, Guy: SDN Software Deﬁned Networking. John Wiley & Sons, Inc., 2015

[QC14] Quick, Darren ; Choo, Kim-Kwang R.: Data reduction and data mining framework for digital forensic evidence: storage, intelligence, review and archive. (2014)

[QGP+10] Qiu, Tongqing ; Ge, Zihui ; Pei, Dan ; Wang, Jia ; Xu, Jun: What happened in my network: mining network events from router syslogs. In: Proceedings of

268 Literaturverzeichnis

the 10th ACM SIGCOMM conference on Internet measurement ACM, 2010, S. 472–484

[QTC+13] Qazi, Zafar A. ; Tu, Cheng-Chun ; Chiang, Luis ; Miao, Rui ; Sekar, Vyas ; Yu, Minlan: SIMPLE-fying middlebox policy enforcement using SDN. In: ACM SIGCOMM Computer Communication Review Bd. 43 ACM, 2013, S. 27–38

[Ran97] Ranum, Marcus J.: Network forensics and traﬃc monitoring. In: Computer Security Journal 13 (1997), Nr. 2, S. 35–39

[Ray01] Raymond, Jean-François: Traﬃc analysis: Protocols, attacks, design issues, and open problems. In: Designing Privacy Enhancing Technologies Springer, 2001, S. 10–29

[RBCK11] Ruan, Keyun ; Baggili, Ibrahim ; Carthy, Joe ; Kechadi, Tahar: Survey on cloud forensics and critical criteria for cloud forensic capability: A preliminary analysis. In: Proceedings of the Conference on Digital Forensics, Security and Law, 2011, S. 55–70

[RC12] Ruan, Keyun ; Carthy, Joe: Cloud Forensic Maturity Model. In: ICDF2C Bd. 114, Springer, 2012 (Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering), S. 22–41

[RCG02] Reith, Mark ; Carr, Clint ; Gunsch, Gregg: An examination of digital forensic models. In: International Journal of Digital Evidence 1 (2002), Nr. 3, S. 1–12

[RCKB13] Ruan, Keyun ; Carthy, Joe ; Kechadi, Tahar ; Baggili, Ibrahim: Cloud forensics deﬁnitions and critical criteria for cloud forensic capability: An overview of survey results. In: Digital Investigation 10 (2013), Nr. 1, S. 34–43

[rDG+11] 3rd, Donald E. E. ; Dutt, Dinesh G. ; Gai, Silvano ; Perlman, Radia ; Ghanwani, Anoop: Routing Bridges (RBridges): Base Protocol Speciﬁcation. RFC 6325, Juli 2011 (Request for Comments)

[RDKT13] Romão, Daniel ; Dijkhuizen, Niels van ; Konstantaras, Stavros ; Thes- salonikefs, George: Practical security analysis of OpenFlow / UNIVERSITY OF AMSTERDAM. 2013. – Forschungsbericht

[rel14] relaxdiego: Your own local Open vSwitch Lab! https://github.com/ relaxdiego/ovs-lab. Version:2014. – Letzter Zugriﬀ: 28.06.2017

269 Literaturverzeichnis

[RKV15] Ramos, Fernando M. ; Kreutz, Diego ; Verissimo, Paulo: Software-deﬁned networks: On the road to the softwarization of networking. In: Cutter IT journal (2015)

[RMI+04] Regnier, Greg ; Makineni, Srihari ; Illikkal, I ; Iyer, Ravi ; Minturn, Dave ; Huggahalli, Ram ; Newell, Don ; Cline, Linda ; Foong, Annie: TCP onloading for data center servers. In: Computer 37 (2004), Nr. 11, S. 48–58

[RMK+96] Rekhter, Y. ; Moskowitz, B. ; Karrenberg, D.; Groot, G. J. ; Lear, E.: Address Allocation for Private Internets. RFC 1918 (Best Current Practice). http://www.ietf.org/rfc/rfc1918.txt. Version:Februar 1996 (Request for Comments). – Updated by RFC 6761

[Ros91] Rose, Marshall T.: The simple book: an introduction to management of TCP/IP-based internets. Bd. 2. Prentice Hall Englewood Cliﬀs, NJ;, 1991

[RR06] Rosen, E. ; Rekhter, Y.: BGP/MPLS IP Virtual Private Networks (VPNs). RFC 4364 (Proposed Standard). http://www.ietf.org/rfc/rfc4364.txt. Version:Februar 2006 (Request for Comments). – Updated by RFCs 4577, 4684, 5462

[RSA78] Rivest, Ronald L. ; Shamir, Adi ; Adleman, Len: A method for obtaining digital signatures and public-key cryptosystems. In: Communications of the ACM 21 (1978), Nr. 2, S. 120–126

[RWJW13] Rajagopalan, Shriram ; Williams, Dan ; Jamjoom, Hani ; Warfield, Andrew: Split/Merge: System Support for Elastic Execution in Virtual Middle- boxes. In: NSDI, 2013, S. 227–240

[Ryu14] Ryu SDN Framework Community: Welcome to RYU the Net- work Operating System(NOS). https://ryu.readthedocs.io/en/latest/. Version:2014. – Letzter Zugriﬀ: 28.06.2017

[SAA+99] Savage, Stefan ; Anderson, Thomas ; Aggarwal, Amit ; Becker, David ; Cardwell, Neal ; Collins, Andy ; Hoffman, Eric ; Snell, John ; Vahdat, Amin ; Voelker, Geoﬀ u.a.: Detour: Informed Internet routing and transport. In: IEEE Micro 19 (1999), Nr. 1, S. 50–59

[Sav16] Savvius Inc.: Best Practices for 10G and 40G Network Forensics. 2016. – Forschungsbericht

270 Literaturverzeichnis

[SBS07] Sneed, H.M. ; Baumgartner, M. ; Seidl, R.: Der Systemtest: anforde- rungsbasiertes Testen von Software-Systemen. Hanser, 2007

[SC13] Stüttgen, Johannes ; Cohen, Michael: Anti-forensic resilient memory acquisition. In: Digital investigation 10 (2013), S. 105–115

[Sch06a] Schmidt, Klaus: High availability and disaster recovery : concepts, design, implementation. Berlin, London : Springer, 2006

[Sch06b] Schwenkler, T.: Sicheres Netzwerkmanagement: Konzepte, Protokolle, Tools. Springer, 2006 (X.systems.press)

[Sch13] Schneier, Bruce: Attacking Tor: how the NSA targets users’ online anonymity. Online. http://www.theguardian.com/world/2013/oct/04/tor- attacks-nsa-users-online-anonymity. Version:Oktober 2013. – Letzter Zugriﬀ: 28.06.2017

[Sch15] Scherchel, Fabian A.: Hacker nutzen Imgur-Lücke beim Angriﬀ auf Reddit und 8chan. Online. http://www.heise.de/security/meldung/Hacker- nutzen-Imgur-Luecke-beim-Angriff-auf-Reddit-und-8chan- 2828142.html. Version:September 2015. – Letzter Zugriﬀ: 28.06.2017

[Sch16] Schirrmacher, Dennis ; heiseSecurity (Hrsg.): Hacker kopieren Nutzer-Daten von Mitfahrgelegenheit.de und Mitfahrzentrale.de. https: //www.heise.de/security/meldung/Hacker-kopieren-Nutzer-Daten- von-Mitfahrgelegenheit-de-und-Mitfahrzentrale-de-3507285.html. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[SDx15] SDxCentral ; sdxcentral.com (Hrsg.): 2015 SDN Controllers Landsca- pe Report. Online. https://www.sdxcentral.com/sdn/definitions/sdn- controllers/open-source-sdn-controllers/. Version:2015. – Letzter Zugriﬀ: 28.06.2017

[SE16a] Spiekermann, Daniel ; Eggendorfer, Tobias: Challenges of Network Foren- sic Investigation in Virtual Networks. In: Journal of Cyber Security and Mobility 5 (2016), Nr. 2, S. 15–46

[SE16b] Spiekermann, Daniel ; Eggendorfer, Tobias: Towards Digital Investigati- on in Virtual Networks: A Study of Challenges and Open Problems. In: 11th International Conference on Availability, Reliability and Security, ARES 2016, IEEE Computer Society, 2016, S. 406–413

271 Literaturverzeichnis

[Sei00] Seifert, Rich: The Switch Book: The Complete Guide to LAN Switching Technology. 1st. New York, NY, USA : John Wiley & Sons, Inc., 2000

[SEK15] Spiekermann, Daniel ; Eggendorfer, Tobias ; Keller, Jörg: Using network data to improve digital investigation in cloud computing environments. In: 2015 International Conference on High Performance Computing & Simulation (HPCS), IEEE, 2015, S. 98–105

[SFF+13] Shah, Syed A. ; Faiz, Jannet ; Farooq, Maham ; Shafi, Aamir ; Meh- di, Syed A.: An architectural evaluation of SDN controllers. In: 2013 IEEE International Conference on Communications (ICC) IEEE, 2013, S. 3504–3508

[SG12] Shin, Seungwon ; Gu, Guofei: CloudWatcher: Network security monitoring using OpenFlow in dynamic cloud networks (or: How to provide security monitoring as a service in clouds?). In: Network Protocols (ICNP), 2012 20th IEEE International Conference on IEEE, 2012, S. 1–6

[Sha12] Shalom, Nati: Mapping the Cloud/PaaS Stack. Online. http: //natishalom.typepad.com/nati_shaloms_blog/2012/05/mapping- the-cloudpaas-stack.html. Version:Mai 2012. – Letzter Zugriﬀ: 28.06.2017

[Sie15] Siegrist, Joe: LastPass Security Notice. Online. https://blog.lastpass. com/2015/06/lastpass-security-notice.html/. Version:September 2015. – Letzter Zugriﬀ: 28.06.2017

[Sit08] Siti Rahayu Selamat, Robiah Yusof, Shahrin Sahib: Mapping Process of Digital Forensics Investigation. http://paper.ijcsns.org/07\ textunderscorebook/200810/20081025.pdf. Version:2008. – Letzter Zu- griﬀ: 28.06.2017

[SJ07] Sammes, Tony ; Jenkinson, Brian: Forensic computing. Springer, 2007

[SK13] Spyridopoulos, Theodoros ; Katos, Vasilios: Data Recovery Strategies for Cloud Environments. In: Cybercrime and Cloud Forensics: Applications for In- vestigation Processes (2013)

[SKE17] Spiekermann, Daniel ; Keller, Jörg ; Eggendorfer, Tobias: Network forensic investigation in OpenFlow networks with ForCon. In: Digital Investigation 20 (2017), S. 66–74

272 Literaturverzeichnis

[SKSD12] Sarda, S. ; Kotecha, R. ; Shetty, P. ; Dhoot, S.: Secure Co-resident virtualization in multicore systems by VM pinning and page coloring. In: 2012 International Conference on Cloud Computing Technologies, Applications and Management (ICCCTAM), 2012, S. 1–7

[SLL05] Slagell, Adam J. ; Li, Yifan ; Luo, Katherine: Sharing network logs for computer forensics: A new tool for the anonymization of netﬂow records. In: Workshop of the 1st International Conference on Security and Privacy for Emer- ging Areas in Communication Networks, 2005. IEEE, 2005, S. 37–42

[SLL12] Stamm, Matthew C. ; Lin, W S. ; Liu, KJ R.: Forensics vs. anti-forensics: A decision and game theoretic framework. In: IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP) IEEE, 2012, S. 1749–1752

[Soc03] Society, IEEE C. ; Electrical, The I. (Hrsg.) ; Electronics Engineers, Inc. (Hrsg.): 802.1q - Virtual Bridged Local Area Networks. IEEE Standards for Local and metropolitan area networks, 2003

[sof13] SoftSelect (Hrsg.): ERP Softwaretrends in Chemie und Pharma. Chemie & Pharma 2013 / 2014, 2013 (ERP Trend Report)

[Spi14] Spiekermann, Daniel: IT-Forensik bei Cloud-Services, Fernunivsität in Hagen, Diplomarbeit, 2014

[SRV08] Sánchez, Rafael ; Raptis, Lampros ; Vaxevanakis, Kostas: Ethernet as a carrier grade technology: developments and innovations. In: IEEE Communica- tions Magazine 46 (2008), Nr. 9, S. 88–94

[SSHC+13] Sezer, Sakir ; Scott-Hayward, Sandra ; Chouhan, Pushpinder K. ; Fra- ser, Barbara ; Lake, David ; Finnegan, Jim ; Viljoen, Niel ; Miller, Marc ; Rao, Navneet: Are we ready for SDN? Implementation challenges for software-deﬁned networks. In: IEEE Communications Magazine 51 (2013), Nr. 7, S. 36–43

[SSKW16] Sarker, Mitalee ; Siersch, Jan ; Khan, Arslan ; Wesner, Stefan: Towards a Method Integrating Virtual Switch Performance Into Data Centre Design. In: 3rd ACM Conference on Information-Centric Networking (ICN 2016) (2016), S. 25

[Sta99] Stallings, William: SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 (3rd Edition). 3rd ed. Reading, Mass. : Addison-Wesley, 1999

273 Literaturverzeichnis

[Sta13] Stallings, William: Software-Deﬁned Networks and OpenFlow. Onli- ne. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ ipj_16-1/161_sdn.html. Version:März 2013. – Letzter Zugriﬀ: 28.06.2017

[Ste02] Stephenson, Peter: Getting the Whole Picture, Collecting Evidence of a Com- puter Crime. In: Computer Fraud & Security 11 (2002), November. – Elsevier

[Ste09] Stephenson, Peter: Structural Investigation of Digital Incidents in Complex Computing Environments. In: Global Environment for Network Innovations (2009)

[Ste11] Stemmer, Michael: Cloud-orientierte Service-Marktplätze, Integrationsplatt- formen für moderne Dienstleistungen und IT-Dienste. (2011)

[Ste14] Stein, Lincoln D.: VM::EC2::Instance. Online. http://search.cpan. org/~lds/VM-EC2-1.10/lib/VM/EC2/Instance.pm. Version: 2014, Abruf: 17.01.2014. – Letzter Zugriﬀ: 28.06.2017

[SWC12] Shin, Dongwan ; Wang, Ying ; Claycomb, William: A policy-based decen- tralized authorization management framework for cloud computing. In: SAC, ACM, 2012, S. 465–470

[SYS08] Selamat, Siti R. ; Yusof, Robiah ; Sahib, Shahrin: Mapping process of digital forensic investigation framework. In: International Journal of Computer Science and Network Security 8 (2008), Nr. 10, S. 163–169

[SZZ+13] Shalimov, Alexander ; Zuikov, Dmitry ; Zimarina, Daria ; Pashkov, Vasi- ly ; Smeliansky, Ruslan: Advanced Study of SDN/OpenFlow Controllers. In: Proceedings of the 9th Central Eastern European Software Engineering Confe- rence in Russia. New York, NY, USA : ACM, 2013 (CEE-SECR ’13), S. 1–6

[Tan03] Tanenbaum, Andrew S.: Computernetzwerke (4. Auﬂ.). Pearson Studium, 2003

[Tha15] Thales: 2015 Global Encryption and Key Management Trends Study. In: Thales e-security (2015)

[The07] The Institute of Electrical and Electronics Engineers, Inc.: IEEE standard for local and metropolitan area networks: Media access control (MAC) bridges. New York : IETF, 2007

274 Literaturverzeichnis

[TM12] Tripathi, Shweta ; Meshram, Bandu B.: Digital Evidence for Database Tamper Detection. In: Journal of Information Security 3 (2012), Nr. 2, S. 113

[TRG+13] Thorpe, Sean S. E. ; Ray, Indrajit ; Grandison, Tyrone ; Barbir, Abbie ; France, Robert B.: Hypervisor Event Logs as a Source of Consistent Virtual Machine Evidence for Forensic Cloud Investigations. In: DBSec, 2013, S. 97–112

[TS07] Tanenbaum, Andrew S. ; Steen, Maarten van: Verteilte Systeme. 2., Auﬂ. Pearson Studium, 2007

[Tur14] Turnbull, James: The Docker Book: Containerization is the new virtualization. James Turnbull, 2014

[VADK14] Van Adrichem, Niels L. ; Doerr, Christian ; Kuipers, Fernando A.: Open- netmon: Network monitoring in openﬂow software-deﬁned networks. In: Network Operations and Management Symposium (NOMS), 2014 IEEE IEEE, 2014, S. 1–8

[Ver17] Veryx: Veryx vTAP. http://www.veryxtech.com/wp-content/uploads/ 2017/03/Datasheet-Veryx-vTAP.pdf. Version:2017

[VLDWF12] Von Laszewski, Gregor ; Diaz, Javier ; Wang, Fugang ; Fox, Geoﬀrey C.: Comparison of multiple cloud frameworks. In: 2012 IEEE 5th International Conference on Cloud Computing (CLOUD) IEEE, 2012, S. 734–741

[VN10] Vishwanath, Kashi V. ; Nagappan, Nachiappan: Characterizing cloud computing hardware reliability. In: Proceedings of the 1st ACM symposium on Cloud computing ACM, 2010, S. 193–204

[VS16] Venish, A ; Sankar, K S.: Study of Chunking Algorithm in Data Deduplicati- on. In: Proceedings of the International Conference on Soft Computing Systems Springer, 2016, S. 13–20

[VVE10] Velte, Toby ; Velte, Anthony ; Elsenpeter, Robert: Cloud Computing, A Practical Approach. 1. Auﬂ. New York, NY, USA : McGraw-Hill, 2010

[VYA13] VYATTA, INC: Segmenting Virtual Networks with Virtual Rou- ters. Online. https://community.brocade.com/dtscp75322/ attachments/dtscp75322/CampusNetworks/67/1/Segmenting% 20Virtual%20Networks.pdf. Version:2013. – Letzter Zugriﬀ: 28.06.2017

[Wal02] Wald, Egbert: Backup & disaster recovery. Mitp, 2002

275 Literaturverzeichnis

[Was11] Wasserman, M.: Using the NETCONF Protocol over Secure Shell (SSH). RFC 6242 (Proposed Standard). http://www.ietf.org/rfc/rfc6242.txt. Version:Juni 2011 (Request for Comments)

[WC06] Wu, Zhong-Zhen ; Chen, Han-Chiang: Design and Implementation of TCP/IP Oﬄoad Engine System over Gigabit Ethernet. In: 2006 Proceedings.15th In- ternational Conference on Computer Communications and Networks (ICCCN), 2006, S. 245–250

[WGL+12] Wen, Xiaolong ; Gu, Genqiang ; Li, Qingchun ; Gao, Yun ; Zhang, Xuejie: Comparison of open-source cloud management platforms: OpenStack and Open- Nebula. In: 2012 9th International Conference on Fuzzy Systems and Knowledge Discovery (FSKD) IEEE, 2012, S. 2457–2461

[Wha01] Whalen, Sean: An introduction to arp spooﬁng. In: Node99 (2001), April

[Wil12] WildPackets Inc.: Network Forensics in a 10G World. On- line. http://www.wildpackets.com/elements/whitepapers/network_ forensics_in_a_10_g_world.pdf. Version:2012. – Letzter Zugriﬀ: 28.06.2017

[Wit10] Witt, B.C.: Datenschutz kompakt und verständlich: Eine praxisorientierte Ein- führung. Vieweg+Teubner Verlag, 2010 (Edition kes)

[WKB+10] Wustrow, Eric ; Karir, Manish ; Bailey, Michael ; Jahanian, Farnam ; Huston, Geoﬀ: Internet background radiation revisited. In: Proceedings of the 10th ACM SIGCOMM conference on Internet measurement ACM, 2010, S. 62–74

[WLL04] Wang, Mea ; Li, Baochun ; Li, Zongpeng: sFlow: Towards resource-eﬃcient and agile service federation in service overlay networks. In: 24th International Conference on Distributed Computing Systems IEEE, 2004, S. 628–635

[WLLS11] Walls, Robert J. ; Levine, Brian N. ; Liberatore, Marc ; Shields, Clay: Eﬀective Digital Forensics Research Is Investigator-Centric. In: HotSec, 2011

[Wu10] Wu, Yu A.: Beneﬁts of virtualization in security lab design. In: Inroads 1 (2010), Nr. 4, S. 38–42

[WZZ09] Wang, Lianhai ; Zhang, Ruichao ; Zhang, Shuhui: A model of computer live forensics based on physical memory analysis. In: 2009 First International Conference on Information Science and Engineering IEEE, 2009, S. 4647–4649

276 Literaturverzeichnis

[Xan16] Xang, Hui: [ovs-discuss] port mirroring on veth peer device. http: //www.mail-archive.com/[email protected]/msg18749.html. Version:2016. – Letzter Zugriﬀ: 28.06.2017

[Yad13] Yadav, Sonali: Comparative Study on Open Source Software for Cloud Compu- ting Platform: Eucalyptus, Openstack and Opennebula. In: International Journal of Engineering And Science 3 (2013), Nr. 10, S. 51–54

[Yan12] Yang, Yang: Understanding Switch Latency. Online. http: //www.cisco.com/c/en/us/products/collateral/switches/nexus- 3000-series-switches/white_paper_c11-661939.pdf. Version:Juni 2012. – Letzter Zugriﬀ: 28.06.2017

[Yat10] Yates, Maynard: Practical Investigations of Digital Forensics Tools for Mobile Devices. In: Information Security Curriculum Development Conference. New York, NY, USA : ACM, 2010 (InfoSecCD ’10), S. 156–162

[YCM+02] Yeh, Eric ; Chao, Herman ; Mannem, Venu ; Gervais, Joe ; Booth, Br- adley: Introduction to TCP/IP oﬄoad engine (TOE). In: 10 Gigabit Ethernet Alliance (10GEA) (2002)

[YDAG04] Yang, L. ; Dantu, R. ; Anderson, T. ; Gopal, R.: Forwarding and Control Element Separation (ForCES) Framework. RFC 3746 (Informational). http://www.ietf.org/rfc/rfc3746.txt. Version:April 2004 (Request for Comments)

[YF03] Younis, Ossama ; Fahmy, Sonia: Constraint-Based Routing in the Internet: Basic Principles and Recent Research. In: IEEE Communications Surveys & Tutorials 5 (2003), Nr. 1, S. 2–13

[YJS+09] Yu, Xian ; Jiang, Lie-Hui ; Shu, Hui ; Yin, Qing ; Liu, Tie-Ming: A process model for forensic analysis of Symbian smart phones. In: International Confe- rence on Advanced Software Engineering and Its Applications Springer, 2009, S. 86–93

[YM05] Yamanishi, Kenji ; Maruyama, Yuko: Dynamic syslog mining for network failure monitoring. In: Proceedings of the eleventh ACM SIGKDD international conference on Knowledge discovery in data mining ACM, 2005, S. 499–508

[YQL14] Yu, Ye ; Qian, Chen ; Li, Xin: Distributed and Collaborative Traﬃc Monitoring in Software Deﬁned Networks. In: Proceedings of the Third Workshop on Hot

277 Literaturverzeichnis

Topics in Software Deﬁned Networking. New York, NY, USA : ACM, 2014 (HotSDN ’14), S. 85–90

[YSC07] Ye, Shuiming ; Sun, Qibin ; Chang, Ee-Chien: Detecting digital image forge- ries by measuring inconsistencies of blocking artifact. In: Multimedia and Expo, 2007 IEEE International Conference on IEEE, 2007, S. 12–15

[ZE+11] Zikopoulos, Paul ; Eaton, Chris u. a.: Understanding big data: Analytics for enterprise class hadoop and streaming data. McGraw-Hill, 2011

[ZFM07] Zhang, Lixia ; Fall, Kevin ; Meyer, David: Report from the IAB Workshop on Routing and Addressing. RFC 4984 (Request for Comments)

[ZGL12] Zarek, Adam ; Ganjali, Y ; Lie, D: Openﬂow timeouts demystiﬁed / De- partment of Computer Science University of Toronto. 2012. – Forschungsbericht

[ZH13] Zawoad, Shams ; Hasan, Ragib: Cloud Forensics: A Meta-Study of Chal- lenges, Approaches, and Open Problems. In: Computing Research Repository (2013)

[ZHS+04] Zhao, B. Y. ; Huang, L. ; Stribling, J. ; Rhea, S. C. ; Joseph, A. D. ; Kubiatowicz, J. D.: Tapestry: A Resilient Global-Scale Overlay for Service Deployment. In: IEEE Journal on Selected Areas in Communications 22 (2004), Nr. 1, S. 41–53

[Zim80] Zimmermann, Hubert: OSI Reference Model — The ISO Model of Architecture for Open Systems Interconnection. In: IEEE Transactions on Communications 28 (1980), April, Nr. 4, S. 425–432

[ZKVM12] Zeng, Hongyi ; Kazemian, Peyman ; Varghese, George ; McKeown, Nick: Automatic test packet generation. In: Proceedings of the 8th international conference on Emerging networking experiments and technologies ACM, 2012, S. 241–252

278 Abbildungsverzeichnis

2.1 Ethernetframe ...... 14 2.2 TCP-Header...... 16 2.3 UDP-Header...... 16 2.4 Prognostizierte Entwicklung des Umsatzes im Cloud-Computing,[PMT13] . . . . 22 2.5 Cloud-Stack,inAnlehnungan[Sha12] ...... 23 2.6 3-Tier-Architektur ...... 27 2.7 Fat-Tree-Implementierung Leaf-Spine ...... 27 2.8 NutzungredundanterPfade...... 29 2.9 VLAN-TagimEthernetframe ...... 37 2.10MPLS-Stack...... 38 2.11 KapselungvonNetzwerkdaten ...... 40 2.12 QinQEncapsulation ...... 41 2.13VXLAN-Kapselung ...... 42 2.14 TunnelungdurchNVGRE ...... 43 2.15STTEncapsulation ...... 43 2.16 KapselungdurchGENEVE ...... 44 2.17 DatenverkehrsrichtunginSDN ...... 49 2.18 OpenFlow speziﬁsche Headerinformationen ...... 51 2.19 Open vSwitch Architektur, nach [PPK+15] ...... 60

3.1 Entwicklung des Einsatzes von Verschlüsselungen in Unternehmen, nach [Tha15] 70

4.1 LebenszykluseinerVM,[Spi14] ...... 85 4.2 Multitierarchitektur für Systeme ohne Anbindung an externeNetzwerke . . . . . 91

6.1 DFRWSVorgehensmodell...... 129 6.2 VorgehensmodelldesBSI[Bun11] ...... 130 6.3 Vorgehensmodellnach[PJN10a] ...... 130 6.4 Vorgehensmodell der Netzwerkforensik in virtuellen Umgebungen ...... 133

7.1 ÜbergeordneteElterninstanz ...... 148 7.2 ParallelevSwitch-Instanz ...... 150 7.3 TestaufbauPort-Mirror ...... 152

279 Abbildungsverzeichnis

7.4 Anbindung des Mirrorports an VXLAN-basierte Vernetzung...... 162 7.5 ProgrammablaufOVSF ...... 176

8.1 KlassendiagrammForCon ...... 199 8.2 InitialerNachrichtenaustausch ...... 203 8.3 Nachrichtenaustausch aufgrund einer Änderung im Netzwerk ...... 203 8.4 TestaufbauForCon ...... 205 8.5 VXLAN-TunnelzurDatenausleitung ...... 208

9.1 TestumgebungzurEvaluation...... 213 9.2 Schematische Darstellung der OpenStack-Infrastruktur ...... 228 9.3 Struktur der virtuellen OpenStack-Umgebung ...... 228

9.4 Schematische Darstellung der Netzwerktopologie zur Aufzeichnung der VMt . . . 230 9.5 Integration von ForCon in einer OpenStack-Umgebung ...... 232

280 Tabellenverzeichnis

0.1 ListederPublikationen ...... XIV

2.1 ReferenzmodelleimVergleich ...... 13 2.2 HeaderfelderIPv4 ...... 14 2.3 HeaderfelderIPv6 ...... 15 2.4 EinigeProtokolleder Anwendungsschicht ...... 17 2.5 Forensische Relevanz der Schichten des OSI-Modells ...... 18 2.6 Optionale Komponenten der OpenStack-Umgebung ...... 33 2.7 VLAN-Header ...... 37 2.8 MPLS-Header ...... 38 2.9 Adressierbare Headerfelder des OpenFlow-Protokolls ...... 52 2.10 FormateinerFlow-Table ...... 53 2.11 Controller-to-SwitchNachrichten ...... 54 2.12 AsynchroneNachrichten...... 54 2.13 SymmetrischeNachrichten ...... 55

4.1 ForensischeRelevanzder Netzwerkdaten ...... 103 4.2 Bewertung netzwerkforensischer Werkzeuge ...... 106 4.3 Problemklassiﬁzierung nach Phase und Risikopotential ...... 112

5.1 Anforderungsmodell ...... 125

6.1 Vergleich der Vorgehensmodelle mit den Anforderungen ...... 140

7.1 OVSDB-ManagementProtokoll...... 145 7.2 Eignung virtueller Interfaces zur Anbindung an eine Elterninstanz...... 149 7.3 Vergleich der Datenausleitungsmöglichkeiten ...... 151 7.4 TestumgebungPlainundVLAN ...... 153 7.5 TestumgebungVXLAN ...... 161 7.6 DatenquellenzurÜberwachung ...... 167 7.7 Maximale Anzahl der vNICs nach Hypervisor ...... 170

8.1 Relevanz der Parameter von OpenFlow-Flowentries ...... 190

281 Tabellenverzeichnis

8.2 NachrichtentypenForCon ...... 201 8.3 StatuscodesForCon ...... 201 8.4 TestumgebungOpenFlow ...... 205 8.5 ProblemederOpenFlow-Forensik ...... 209

9.1 Erste Messreihe zum Nachweis der vollständigen Paketaufzeichnung ...... 214 9.2 Nachweis der vollständigen Paketaufzeichnung ...... 216 9.3 Paketmitschnitte bei steigender Clientanzahl ...... 216 9.4 VollständigkeitindenSzenarien...... 218 9.5 PhasendesVNFPbeiOVSFundForCon...... 227

282 Verzeichnis der Listings

7.1 Aktivierungdes RemotezugriﬀsaufOVSDB ...... 145 7.2 ErmittlungangeschlossenervPorts ...... 154 7.3 ExemplarischeAbfrage derUUID der vNIC tap3 ...... 154 7.4 AbfragederCAM-Table ...... 155 7.5 ExtraktionderMAC-Adressen...... 155 7.6 ErstellungMirrorport ...... 157 7.7 JSON-RPCzurMirrorerstellung...... 157 7.8 Aufzeichnung von VLAN-separiertem Datenverkehr ...... 159 7.9 Datenaufzeichnung von untagged-VLAN Datenverkehr ...... 160 7.10 Datenaufzeichnung von tagged-VLAN Datenverkehr ...... 160 7.11 VXLAN-Konﬁguration(Ausgabe gekürzt) ...... 161 7.12 Ausgabe per OVSDB-Monitoring beim Start einer VM ...... 168 7.13 Reduzierte Ausgabe per OVSDB-Monitoring ...... 168 7.14 HinzufügenzusätzlicherMirrorport ...... 171 7.15 LoggingrelevanterAktionen ...... 173 7.16 LoggingderMirrorportaktionen ...... 173

8.1 Extrahierte Flows, implementiert von Floodlight-Controller ...... 182 8.2 Extrahierte Flows, implementiert vom POX-Controller ...... 183 8.3 Controllerunabhängige Extraktion von Switch-Informationen zur Laufzeit . . . . . 188 8.4 ExtraktiongültigerFlowsausvSwitch ...... 189

9.1 HashvergleichderMitschnitts...... 219 9.2 Extraktion Zeitstempel der einzelnen Frames ...... 220 9.3 Entfernen der führenden 40 Byte aus Netzwerkmitschnitt ...... 221 9.4 Vergleich der Hashwertenach Angleichung ...... 222 9.5 Abfrage von Instanzdetails der Ziel-VM (Ausgabe gekürzt) ...... 229 9.6 Aufzeichnung der Daten in der Modellumgebung ...... 231

283

Abkürzungsverzeichnis

AAA Authentication, Authorization, Accounting

API Application Programming Interface

ARP Address Resolution Protocol

ATM Asynchronous Transfer Mode

BPF BSD Packet Filter

BSI Bundesamt für Sicherheit in der Informationstechnik

C-VID Customer VLAN ID

CAM Content Addressable Memory

CC Cloud Controller

CLI Command Line Interface

CMP Cloud Management Platform

CN Compute Node

CSP Cloud Service Provider

DBaaS Database-as-a-Service

DFRWS Digital Forensic Research Workshop

DHCP Dynamic Host Conﬁguration Protocol

DMZ Demilitarisierte Zone

DNS Domain Name System

285 Abkürzungsverzeichnis

DPI Deep Packet Inspection

EID Endpoint Identiﬁer

ESP Encrypted Security Payload

FCP ForCon-Protokoll

FCS Frame Check Sequence

FDB Forwarding Database

FIB Forwarding Information Base

GENEVE Generic Network Virtualization Encapsulation

GNFP Generic Network Forensic Process

GRE Generic Routing Encapsulation

HDLC High-Level Data Link Control

IaaS Infrastructure-as-a-Service

ICMP Internet Control Message Protocol

IDS Intrusion Detection System

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protokoll

IPS Intrusion Prevention System

IS-IS Intermediate System to Intermediate System

JSON JavaScript Object Notation

LAN Local Area Network

LER Label Edge Router

LISP Locator / ID Separator-Protocol

286 LSR Label Switch Router

MAC Media Access Control

MITM Man-in-the-Middle

MPLS Multi Protocol Label Switching

MTU Maximum Transmission Unit

NAC Network Access Control

NAS Network Attached Storage

NAT Network Address Translation

NFV Network Function Virtualization

NFV-MANO NFV Management and Operations

NFVI NFV Infrastructure

NIC Network Interface Card

NIDS Networkbased IDS

NSM Network Security Management

NVGRE Network Virtualization using Generic Routing Encapsulation

ON Overlay-Netzwerk

OVS Open vSwitch

OVSDB Open vSwitch DataBase

PaaS Platform-as-a-Service

PDU Packet Data Unit pNIC physische NIC

PoC Proof-of-Concept

287 Abkürzungsverzeichnis

QoS Quality of Service

RBAC Role-Based-Access-Control

RFC Request for Comments

RLOC Routing Locator

RPC Remote Procedure Call

RZ Rechenzentrum

S-VID Service VLAN ID

SAN Storage Area Network

SDN Software Deﬁned Network

SNMP Simple Network Management Protocol

SPB Shortest Path Bridging

STP Spanning-Tree-Protokoll

STT Stateless Transport Tunneling

TAP Test Access Port

TCP Transmission Control Protocol

TKG Telekommunikationsgesetz

TKÜ Telekommunikationsüberwachung

TRILL Transparent Interconnection of Lots of Links

TTL Time-to-live

UDP User Datagram Protocol

UUID Universally Unique Identiﬁer

VLAN Virtual LAN

288 VM Virtuelle Maschine

VMM Virtual Machine Monitor

VNF Virtualised Network Function

VNFP Virtual Network Forensic Process

VNI VXLAN Network Identiﬁer vNIC Virtual NIC

VoIP Voice over IP

VPN Virtual Private Network vPort Virtual Port vRouter Virtual Router vSwitch Virtual Switch

VTEP VXLAN Tunnel Endpoint

VXLAN Virtual eXtensible LAN

WAN Wide Area Network

WLAN Wireless LAN

289