deposit_hagen
Mathematik und
Informatik
Dissertation
Netzwerkforensik in virtuellen Umgebungen
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
2. Gutachter:
Herr Prof. Dr. Tobias Eggendorfer (Hochschule Ravensburg-Weingarten) Vorsitzender der Prüfungskomission:
Herr Prof. Dr. Wolfram Schiffmann (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 flexible Umgebungen, die größtenteils eigenständig an die jeweiligen Bedürfnisse angepasst wer- den 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 flexible 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 Identifikation 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, definiert 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 schafft 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 tech- nology 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 environ- ment, 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 identification. Even the initial setup of a network forensic investigation within such an environment does not guarantee the capture of the entire network traffic. 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 defined. 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 first 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 ha- be. 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öffentlicht.
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 un- terschiedlicher Clouddienste zu identifizieren. Der Artikel wurde durch Daniel Spiekermann ge- schrieben. 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, offline und organisatorisch wurde genutzt, um die Probleme zu klassifizieren. 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.
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 ge- schrieben 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 vir- tuellen 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öffentlichungen mit den Kapiteln dieser Arbeit:
Tabelle 0.1: Liste der Publikationen
Publikation Kapitel Erläuterung
Using Network Data to Improve Di- gital Investigation in Cloud Compu- ting Environments
3.2 Die Analyse aufgezeichneter Netzwerkdaten ermöglicht die Erkennung genutzter Cloud- Dienste und stellt somit einen Baustein der Cloud-Forensik dar.
Towards Digital Investigation in Vir- tual Networks: A Study of Challen- ges and Open Problem
4 Die Probleme werden in dieser Arbeit klassifi- ziert, darüber hinaus erfolgt die Analyse mög- licher Probleme.
Challenges of Network Forensic In- vestigation in Virtual Networks
4 / 8 Diese Arbeit beschreibt detailliert ForCon und die Möglichkeiten der dynamischen Überwa- chung.
Network Forensic Investigation in OpenFlow Networks with ForCon
6.2 / 8 Das VNFP wurde im Paper kurz vorgestellt, in dieser Arbeit wird die Herleitung beschrieben und die notwendigen Phasen detailliert erläu- tert.
Towards Covert Channels in Cloud Environments: A Study of Imple- mentations in Virtual Networks
3.4 / 9.4 Diese Arbeit beschreibt die Entdeckung der antiforensischen Techniken mit Hilfe von For- Con.
Using Open Source Based Distribu- ted Agents to Perform Digital Inves- tigation in Virtual Environments
8.4 Diese Arbeit vertieft den agentenbasierten An- satzes von ForCon.
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 Bedeutung der Problemstellung . . . 6
1.4 Ziele der Arbeit . . . 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 Entwicklung der Softwareumgebung . . . 29
2.3 Netzwerkvirtualisierung . . . 34
2.3.1 Entstehung . . . 34
2.3.2 Overlay-Netzwerke . . . 39
2.4 Software Defined Networks . . . 46
2.4.1 Konzepte . . . 46
2.4.2 OpenFlow . . . 50
2.5 Network Function Virtualization . . . 55
2.5.1 NFV Framework . . . 55
2.5.2 Vorteile . . . 57
2.5.3 Open vSwitch . . . 58
2.6 Netzwerkforensik . . . 60
2.6.1 Definition . . . 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 Fokus der Strafverfolgung . . . 68
3.1.2 Metadatenanalyse . . . 69
3.1.3 Statistische Bewertung . . . 71
3.1.4 Datenmenge . . . 72
3.2.2 Containerforensik . . . 75
3.3 Forensik in virtuellen Netzwerken . . . 76
3.4 Vorgehensmodelle . . . 77
3.5 Antiforensik . . . 79
4 Problemanalyse 81 4.1 Bestimmung existenter Problemfelder . . . 81
4.1.1 Aufteilung nach Phasen . . . 82
4.1.2 Aufteilung nach Komponenten . . . 83
4.1.3 Aufteilung nach Prozessen . . . 84
4.2 Migration . . . 86
4.3 Nutzeranpassungen . . . 87
4.4 Virtuelle Netzwerkkarten . . . 88
4.4.1 Identifikation . . . 89
4.4.2 Aufzeichnungsproblem . . . 89
4.5 Multitenancy . . . 90
4.6 Interner Datenverkehr . . . 90
4.7 Physische Vernetzung . . . 91
4.8 Nichteindeutigkeit der MAC . . . 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 Overlapped IP-Addresses . . . 107
4.12 Linkauslastung . . . 108
4.13 Vielzahl der Controller . . . 109
4.14 Unvollständigkeit der Informationen . . . 110
4.15 Klassifizierung . . . 111
4.16 Zusammenfassung . . . 114
5 Entwicklung eines Anforderungsmodells 115 5.1 Etablierte Anforderung . . . 115
5.1.1 IT-Forensik . . . 115
5.1.2 Netzwerkforensik . . . 117
5.2 Spezifische Anforderungen . . . 118
5.2.1 Datenreduktion . . . 118
5.2.2 Dynamische Adaption . . . 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 Virtual Network Forensic Process . . . 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 Portidentifizierung . . . 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 geeigneten Datenbasis . . . 163
7.5.2 Implementierung der Überwachung . . . 167
7.5.3 Situative Differenzierung . . . 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 Vorhandene Flows . . . 182
8.2.2 Komplexität der Flows . . . 182
8.2.3 Controllerabhängigkeit . . . 183
8.2.4 Ergebnis . . . 184
8.3 Lösungsentwicklung . . . 184
8.3.1 Evaluierung der Zugriffsmöglichkeit . . . 185
8.3.2 Identifikation der Switchinstanz . . . 187
8.3.5 Überwachung . . . 194
8.4 Implementierung . . . 197
8.4.1 ForCon-Server . . . 199
8.4.2 Agenten . . . 200
8.4.3 ForCon Protocol . . . 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 Abgleich mit dem VNFP . . . 223
9.2.1 Identifikation . . . 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 Validierung in OpenStack-Umgebung . . . 227
9.3.1 Beschreibung der Modellumgebung . . . 227
9.3.2 Durchführung . . . 229
9.3.3 Optimierung . . . 232
9.3.4 Fazit . . . 234
9.4 Antiforensische Bewertung . . . 235
9.5 Zusammenfassung . . . 236
10 Fazit 237 10.1 Zusammenfassung . . . 237
10.2 Ausblick . . . 238
10.3 Eigene Leistung . . . 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 identifiziert 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.deundwww.mitfahrgelegenheit.dedeutlich die Probleme bei Untersuchun- gen in virtuellen Umgebungen. Bei dem Angriff 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 Webseitenwww.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 Konfigurations- 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 Datendefiniert.
implementierungen oder einer kompletten Multitierarchitektur auf Basis miteinander vernetzter virtueller Systeme. Entwickler und Unternehmen können sich so auf ihre Hauptaufgabe konzen- trieren, 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, konfiguriert und wartet der Provider die notwendigen Systeme, stellt Verfügbarkeit und Leistungsfähigkeit der angebo- tenen 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 in- nerhalb 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 konfiguriert, dass es wie ein alleinstehendes Netzwerk erscheint. Mit Hilfe neuer Netzwerkprotokolle werden dabei Limitierungen alter Protokolle aufgehoben, Techni- ken wie Software Defined 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 ver- schleiern 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 Angriffe nicht stattfinden 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.
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 auf- gezeichneten 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 Zugriff auf die Daten steht nur Teilnehmern zur Verfügung, die eigenes Material hochladen. Der Zugriff auf diese Server erfolgt dabei nicht von beliebigen Clients, sondern nur von Systemen, die innerhalb eines Virtual Private Network (VPN) vernetzt sind. Die beteilig- ten 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
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 verant- wortliche Netzwerkforensiker konfiguriert die Aufzeichnungssysteme wie gewohnt mit Hilfe vor- gegebener 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 Weboberfläche des Anbieters die VM neu konfiguriert 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.
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 unter- schiedlichen 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 auffindet. Innerhalb die- ser 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 finden, 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 Identifikationsmerkmale 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.
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 ge- speicherten 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 identifizierbar.
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 wer- den, um alle ankommenden und abgehenden Daten an ein Aufzeichnungssystem zu übertragen.
Hierdurch erhält ein Ermittler zusätzliche Hinweise über Kommunikationsteilnehmer, adminis- trative Zugriffe und möglicherweise auch die übertragenen Daten, sofern keine Verschlüsselung gewählt wurde.
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 Eingriffe 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 je- doch 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 Identifi- 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 ei- ner 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 hoch- automatisierte 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.
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äufige Nutzung der Netzwerke sowie die ausgetauschten Daten bieten für forensische Arbei- ten meist einen erheblichen Informationsgewinn. Häufig 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 flexibel 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 Zugriff auf die entfernt laufenden Systeme und Umgebungen immer über ein Netzwerk erfolgt.
Die Vergangenheit hat gezeigt, dass Cloud-Umgebungen immer wieder Ziele von Angriffen wer- den, 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 be- schrieben. 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 Identifizierung 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
1.5 Übersicht
automatisch angepasst wird und eine Analyse der anfallenden Netzwerkdaten innerhalb eines Cloudsystems ermöglicht.
1.5 Übersicht
Nach dieser Einleitung werden inKapitel 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 3liefert ein Überblick über den Stand der Technik hinsichtlich der aktuellen netzwerkfo- rensischen 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 betreffen. Diese Probleme werden inKapitel 4detailliert 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, aner- kannte Standards und allgemein gültige Vorgaben, die dieses strukturierte Vorgehen unterstützen.
Diese resultieren aus unterschiedlichen Anforderungen, deren Einhaltung eine korrekte Arbeit er- leichtern.Kapitel 5beschreibt allgemeine Anforderungen und führt in Verbindung mit speziellen Anforderungen der Netzwerkforensik in virtuellen Netzwerken zu einem Anforderungsmodell zu- sammen.
Vorgehensmodelle bieten Ermittlern Handlungsanweisungen und Hilfen bei der Durchführung fo- rensischer 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 6beschreibt 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 definiert Phasen, die auf die Besonderheiten der Netzwerkforensik in virtuellen Um- gebungen eingehen.Kapitel 7beschreibt ausgehend von diesem Modell eine Untersuchung vir- tueller Switchen auf Basis von Open vSwitch (OVS). Dies umfasst die Analyse der netzwerkfo- rensischen Möglichkeiten sowie die Beschreibung eines geeigneten Lösungsmodells, welches die
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 hoch- dynamischen Umgebungen auf Basis von OpenFlow. Dabei wird mit ForCon eine Lösung vorge- stellt, 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 imKapitel 9hinsicht- lich 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 10fasst die Arbeit zusammen und gibt einen Ausblick auf offene Themen.
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 profitiert.
Ein virtuelles Netzwerk ist dabei keine einzelne, klar definierte 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 Definition 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.
2.1.1 Referenzmodelle
2.1.1.1 OSI-Modell
Das OSI-Modell nach Zimmermann [Zim80] stellt ein theoretisches Schichtenmodell dar, wel- ches von der konkreten Verarbeitung unterschiedlicher Protokolle in Netzwerken abstrahiert. Das Modell besteht aus sieben Schichten, die jeweils unterschiedliche Aufgaben wahrnehmen und so- mit die gemeinsame Nutzung heterogener Techniken und Implementierungen ermöglichen. Jede Schicht definiert 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 zusam- mengefasst. 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 entspre- chen 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 definiert sind.
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
Netzzugang Sicherung
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 Klassifizierung 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 definiert, 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 weiter- geleitet, 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.
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- stellerkennzeichen3und 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 Wegefindung in Netzwerken. Das am häu- figsten 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 Version des folgenden IP-Pakets (hier 4) gering
Internet Header Length 4 Länge des IP-Headers gering
Type of Service 8 Festlegen der Priorität gering
Length 16 Länge des gesamten Pakets gering
Identification 16 Eindeutige Kennzeichnung des Pakets gering
Flags 3 Festlegung der Fragmentierung gering
Fragment Offset 13 Gibt die Position im Paket an, an der ein Fragment beginnt
gering Time to live 8 Maximale Anzahl von Routern auf dem Weg
zum Ziel
gering
Protocol 8 Folgeprotokoll im Payload hoch
Header Checksum 16 Prüfsumme über den gesamten Header gering
Source IP 32 IP-Adresse der Quelle hoch
Destination IP 32 IP-Adresse des Ziels hoch
3Dieser als Organizationally Unique Identifier (OUI) bezeichnete Zeichenkette wird von der Institute of Electrical and Electronics Engineers (IEEE) vergeben.
2.1 Netzwerktechnik
Die Einführung einer neuen IP-Version begann 1998 unter dem NamenIPng, 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 Version des folgenden IP-Pakets (hier 6) gering
Traffic Class 8 Prioritätssteuerung gering
Flow Label 20 Genutzt für Quality of Service (QoS) gering Payload Length 16 Länge der übertragenen Daten im IP-Paket gering Next Header 8 Identifikation des nächsten Headers hoch Hop Limit 8 Entspricht dem Feld Time-to-live (TTL) des
IPv4-Headers
gering
Source IP 128 IP-Adresse der Quelle hoch
Destination IP 128 IP-Adresse des Ziels 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, Multicast5und 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 je- doch 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.
9 8 7 6 5 4 3 2 1
0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
Source Port Destination Port
Length Windows
Options Sequenznumber Acknowledgenumber Offset U A P R S F
Checksum Urgent Pointer
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.
9 8 7 6 5 4 3 2 1
0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
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 eigent- liche 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-
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 an- deren 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 effektiver 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 befindlichen 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äufig 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 Hypertext Transfer Protocol * HTTPS Hypertext Transfer Protocol Secure SMTP Simple Mail Transfer Protocol * IMAP Internet Mail Access Protocol *
FTP File Transfer Protocol *
SSH Secure Shell
VNC Virtual Network Computing *
7Eine Zeichenkodierung des kyrillischen Alphabets, welches für die ukrainische Sprache genutzt wird.
2.1.2.8 Klassifizierung
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 er- mittelt 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 Klassifizierung 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
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 unterschied- lichen 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-
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 finden 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 ver- netzen. 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 Puffer.
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.
