Diplomarbeit - Institut für Angewandte Mikroelektronik und

Universität Rostock
Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
Diplomarbeit
Entwicklung einer Struktur zur Zustandsüberwachung
verbindungsorientierter Kommunikationsprotokolle
Bearbeiter:
cand. Ing. Martin Siemroth
Studiengang:
Elektrotechnik
Matrikelnummer:
000201620
Tag der Ausgabe:
01.12.2006
Tag der Abgabe:
31.05.2007
Betreuer:
Dipl.-Ing. Harald Widiger
Dipl.-Ing. Stephan Kubisch
Betreuender Hochschullehrer:
Prof. Dr.-Ing. Dirk Timmermann
Danksagung
An dieser Stelle möchte ich den Mitarbeitern des Instituts für Angewandte Mikroelektronik und Datentechnik der Universität Rostock danken, die durch ihre fachliche und
persönliche Unterstützung zum Gelingen dieser Diplomarbeit beigetragen haben.
Besonderer Dank gebührt meinen Eltern, die mir dieses Studium durch ihre Unterstützung ermöglicht haben.
i
Aufgabenstellung
Entwicklung einer Struktur zur Zustandsüberwachung
verbindungsorientierter Kommunikationsprotokolle
Die Anforderungen an moderne Netzwerkkomponenten, insbesondere im Bereich der
Access Netzwerke, nehmen stetig zu. Mit zunehmender Bandbreite von Teilnehmeranschlüssen durch VDSL oder „Ethernet on The First Mile“ (EFM) und der gleichzeitig
zunehmenden Anzahl von Diensten, die Internet Service Provider anbieten, nimmt die
Notwendigkeit des Einsatzes spezialisierter Hardwarelösungen stark zu, da Softwareäquivalente zukünftig nicht genügend Performance bieten können. Durch den „always-on“Trend in Wirtschaft, Gesellschaft und alltäglichem Leben nimmt das Bedürfnis nach
Sicherheitsmaßnahmen im selben Maße zu. Ziel dieser Arbeit ist die Entwicklung einer
Hardwarelösung, die es ermöglicht, die spezifizierten Zustände von Kommunikationsverbindungen zu überwachen und nicht erlaubte Übergänge und bestimmte Angriffe auf
bzw. durch Nutzer netzwerkseitig zu unterbinden. Diese Lösung soll am Beispiel eines
State-Oberservers für TCP- oder SIP-Verbindungen entwickelt und prototypisch implementiert werden. Anhand dieses Systems sind Abschätzungen über eine Anwendbarkeit
solcher Systeme in Zugangsnetzwerken vorzunehmen.
Im Rahmen der Diplomarbeit sind folgende Teilaufgaben zu lösen:
• Entwurf eines allgemeinen Konzepts zur State-Observation für eine größere Anzahl
von Nutzern, bzw. Kommunikationsverbindungen.
• Analyse typischer Angriffsszenarien auf das TCP-Protokoll und Einschätzung von
Möglichkeiten der Angriffsabwehr durch einen oben beschriebenen Mechanismus.
• Abhängig von den Analyseergebnissen, prototypische Implementierung eines TCPoder eines SIP-State-Observers. Dies geschieht unter Berücksichtigung von GPSOrtsinformationen, die innerhalb einer IP-Option des IP-Protokolls vorliegen.
• Untersuchung und Aufwandsabschätzung der Anbindung eines GPS-Moduls an ein
ii
Aufgabenstellung
ML405-Evaluation Board, zur Erzeugung von IP-Frames mit GPS-Ortsinformationen
in einer IP-Option.
• Ggf. Anbindung eines GPS-Moduls an ein ML405-Evaluation Board. Dazu sind
bereits entwickelte Komponenten zur IP-Paketerweiterung zu verwenden und ggf.
zu erweitern.
iii
Inhaltsverzeichnis
Danksagung
i
Aufgabenstellung
ii
Einleitung
I
xii
Grundlagen
1
1 Protokollübersicht
2
1.1
ISO-OSI 7 Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
TCP/IP Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Internetprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4
Internet Control Message Protocol . . . . . . . . . . . . . . . . . . . . . .
7
1.5
Transmission Control Protocoll . . . . . . . . . . . . . . . . . . . . . . .
9
1.5.1
TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.5.2
Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.5.3
Datenübertragung
. . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5.4
Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2 Angriffe auf Internetverbindungen
16
2.1
Informationsgewinnung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2
Denial of Service Attacken . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
Angriffe auf einzelne TCP-Verbindungen . . . . . . . . . . . . . . . . . .
19
2.4
Schutzmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3 Global Positioning System
21
II Konzept
22
iv
Inhaltsverzeichnis
4 Anforderungen an das Observermodul
23
5 Zustandsmodell zur Verbindungsüberwachnung
25
5.1
Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2
Datenversand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.3
Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.4
Benötigte Paketinformationen . . . . . . . . . . . . . . . . . . . . . . . .
29
5.4.1
Informationen aus dem IP-Header . . . . . . . . . . . . . . . . . .
29
5.4.2
Informationen aus dem TCP-Header . . . . . . . . . . . . . . . .
30
6 Hardwarekonzipierung
6.1
6.2
6.3
6.4
32
Datenpfadlogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.1.1
Schnittstellen der Datenpfadlogik zu anderen Modulen . . . . . .
33
6.1.2
Aufgaben und Konzept der Datenpfadlogik . . . . . . . . . . . . .
34
Up-Down-Arbitrierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2.1
Schnittstellen des Arbitrierers zu anderen Modulen . . . . . . . .
39
6.2.2
Aufgabe und Konzept des Arbitrierers . . . . . . . . . . . . . . .
40
Protokollüberwachungslogik . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.3.1
Schnittstellen der Protokollüberwachungslogik zu anderen Modulen 42
6.3.2
Aufgabe und Konzept der Protokollüberwachungslogik . . . . . .
44
Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.4.1
Die Wahl des Suchverfahrens . . . . . . . . . . . . . . . . . . . . .
49
6.4.2
Realisierung des Speichers . . . . . . . . . . . . . . . . . . . . . .
52
6.4.3
Alterungsalgorithmus . . . . . . . . . . . . . . . . . . . . . . . . .
52
III Realisierung und Verifikation
55
7 Realisierung in VHDL
56
7.1
Zwei Prozess Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
7.2
Typdefinition und Informationsübergänge
. . . . . . . . . . . . . . . . .
57
7.3
Realisierung einzelner Elemente der Module . . . . . . . . . . . . . . . .
59
7.3.1
Zwischenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
7.3.2
Überprüfung eines Paketes . . . . . . . . . . . . . . . . . . . . . .
61
8 Verifikation mit SystemC
8.1
62
Struktur der Testbenches unter SystemC . . . . . . . . . . . . . . . . . .
v
62
Inhaltsverzeichnis
8.2
Verifikation der Komponenten . . . . . . . . . . . . . . . . . . . . . . . .
62
IV Zusammenfassung und Ergebnis
65
9 Zusammenfassung
66
9.1
Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.1.1
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.1.2
Version mit vermindertem Funktionsumfang . . . . . . . . . . . .
67
9.1.3
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Selbstständigkeitserklärung
70
vi
Tabellenverzeichnis
1.1
ICMP Nachrichtentypen . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
6.1
Schnittstellen der Datenpfadlogik . . . . . . . . . . . . . . . . . . . . . .
34
6.2
Datenpfadlogic, rcv info fsm . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.3
Schnittstellen des Arbitrierers . . . . . . . . . . . . . . . . . . . . . . . .
40
6.4
Schnittstellen der Protokollüberwachungslogik . . . . . . . . . . . . . . .
43
vii
Abbildungsverzeichnis
1.1
ISO-OSI 7 Schichtenmodell, TCP/IP Referenzmodell . . . . . . . . . . .
4
1.2
Beispiel der Protokollkapselung . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
IPv4 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4
Aufbau einer mit IP transportierten ICMP-Nachricht . . . . . . . . . . .
8
1.5
TCP Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.6
TCP 3-Wege Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . .
11
1.7
Datenübertragung mit TCP . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.8
Flusskontrolle und Timermanagement . . . . . . . . . . . . . . . . . . . .
13
1.9
TCP 3-Wege Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . .
15
4.1
Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.1
Zustandsmodell; Bereich Verbindungsaufbau . . . . . . . . . . . . . . . .
26
5.2
Zustandsmodell; Bereich Verbindungsabbau . . . . . . . . . . . . . . . .
28
5.3
Benötigte Informationen aus dem IP-Header . . . . . . . . . . . . . . . .
30
5.4
Benötigte Informationen aus dem TCP-Header . . . . . . . . . . . . . . .
30
6.1
Aufbau des Überwachungsmoduls, Schnittstellen zwischen den einzelnen
Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
6.2
Aufbau der Datenpfadlogik . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.3
Zustandsmaschine zur Bearbeitung der Netzwerkschicht . . . . . . . . . .
35
6.4
Vereinfachte Zustandsmaschine: Auslesen der Paketinformationen . . . .
37
6.5
FSM: Datenpfadlogik, Zwischenspeichern der Pakete
. . . . . . . . . . .
38
6.6
FSM: Datenpfadlogik, Bereitstellen der Paketinformationen . . . . . . . .
38
6.7
FSM: Datenpfadlogik, Versenden/Verwerfen des Paketes . . . . . . . . .
39
6.8
Aufbau des Arbitrierers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.9
FSM: Arbitrierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.10 Ablauf der Arbitrierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.11 FSM: Protokollüberwachungslogik . . . . . . . . . . . . . . . . . . . . . .
45
viii
Abbildungsverzeichnis
6.12 Funktionsdiagramm: Überprüfung der Pakete . . . . . . . . . . . . . . .
46
6.13 a) allgemeiner Schlüssel zur Verbindungsidentifizierung b) Schlüssel für
Paket aus dem Westen c) Schlüssel für Paket aus dem Osten . . . . . . .
46
6.14 Aufteilung des Sequenznummernbereiches . . . . . . . . . . . . . . . . . .
47
6.15 Inhalt der Verbindungsinformationen . . . . . . . . . . . . . . . . . . . .
50
6.16 Vergleich von a) sequentieller Suche und b) binärer Suche . . . . . . . . .
51
6.17 Einfügen eines Elementes in den Speicher1: a) Ausgangszustand b) Einfügevorgang c) Endzustand . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.18 Löschen eines Elementes aus dem Speicher1: a) Ausgangszustand b) Löschvorgang c) Endzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.19 Alterungsalgorithmus im Speichermodul . . . . . . . . . . . . . . . . . .
54
7.1
Prinzip der 2-Prozess Methode . . . . . . . . . . . . . . . . . . . . . . . .
56
7.2
Realisierung eines Fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
8.1
Struktur Datenpfadlogik TB . . . . . . . . . . . . . . . . . . . . . . . . .
62
8.2
Struktur Protokollüberwachungslogik TB . . . . . . . . . . . . . . . . . .
63
ix
Glossar
ACK
Acknowledge
BFM
Bus-functional Model
Broadcastadresse
IP-Adresse für eine Rundnachricht an mehrere Empfänger
DDoS
Distributed Denial of Service
DoS
Denial of Service
DuT
Device under Test
ECN
Explicit Congestion Notification
EOF
End of Frame
FIN
Finalize
FTP
File Transfer Protocol
GPS
Global Positioning System
Host
Verbindungsteilnehmer
HTTP
HyperText Transfer Protocol
ICMP
Internet Control Message Protocol
IP
Internet Protokoll
IP-Spoofing
Generierung von IP-Paketen mit gefälschten IPAdressen
IPv4
Internetprotokoll in der Version 4
IPv6
Internetprotokoll in der Version 6
ISO
International Organzition for Standradization
x
Glossar
MPLS
Multi Protocol Label Switching
NMEA
National Marine Electronics Association, Nationale
Vereinigung für Marineelektronik
OSI
Open Systems Interconnect
POP
Post Office Protocol
RFC
Request for Comments
RST
Reset
RTO
Retransmission Timeout
RTT
Roundtriptime
SOF
Start of Frame
SYN
Synchronisation
TB
Testbench
TCP
Transmision Control Protocoll
UDP
User Datagram Protocol
VHDL
Very High Speed Integrated Circuit Hardware Description Language
VLAN
Virtual Local Area Network
xi
Einleitung
Sicherheitsaspekte bei der Internetanbindung haben heute eine immer größer werdende
Bedeutung. Dies ist auf die steigende Anzahl an Benutzern, Geräten mit Internetzugang
und angeboten Diensten zurückzuführen. Telefonieren über IP und Fernsehstreams über
einen Breitbandinternetanschluss sind Beispiele dafür. Die Zusatzinformationen die bis
vor ein paar Jahren über einen Faxabruf oder auf postalischen Weg zu erhalten waren,
werden heute im Internet angeboten. Der „always-on“ Trend wird vorausgesetzt und ist
nicht mehr wegzudenken. Für den Schutz vor Angriffen muss allerdings individuell gesorgt werden.
Hier setzt die vorliegende Arbeit an. Es soll ein zusätzlicher Schutz zugangsnetzwerkseitig gewährleistet werden. Ziel dabei ist die Zustandsüberwachung von TCP Verbindungen, unter Verwendung von GPS-Ortsinformationen, als ein zusätzliches Sicherheitsmerkmal. Diese Informationen sind in den IP-Optionen enthalten und lassen eine Zuordnung
von IP und geografischen Ort zu. Diese Funktionalität soll aus Geschwindigkeitsgründen
in Hardware umgesetzt werden.
Zunächst wird in dieser Arbeit auf die verwendeten Kommunikationsprotokolle und die
Angriffsarten eingegangen. Daraufhin wird ein Konzept für eine Zustandsüberwachung
entwickelt, welches im Anschluss in VHDL implementiert wird. Abschließend werden die
Vor- und Nachteile des entwickelten Moduls erläutert.
xii
Teil I
Grundlagen
1
1 Protokollübersicht
Unter Protokollen sind Regeln zu verstehen, die das Verhalten sowie den Nachrichtenaustausch zwischen Kommunikationspartnern spezifizieren. Als ein sehr einfaches Protokoll
kann die Vorgehensweise bei der direkten Kommunikation zwischen zwei Personen angesehen werden. Hierbei sollte jeder den anderen ausreden lassen, damit einander verstanden
wird und keine Informationen verloren gehen. In der Kommunikationstechnik sind Protokolle weitaus komplexer und ermöglichen eine Kommunikation zwischen Instanzen in
einem Netzwerk. Aufgrund dieser Komplexität werden die benötigten Funktionen hier
nicht mit einem einzigen Protokoll realisiert, sondern auf mehrere Protokolle verteilt. Diese Protokolle sind in Schichten mit unterschiedlichen Aufgaben organisiert. Grundlage
dafür bildet das Open Systems Interconnect (OSI) 7 Schichtenmodell der International
Organzition for Standradization (ISO), das in [6] spezifiziert ist. Ein weiteres Modell ist
das TCP/IP Referenzmodell, welches für den Einsatz im Internet bestimmt ist.
1.1 ISO-OSI 7 Schichtenmodell
Mit der Zielstellung eine herstellerunabhängige Kommunikation zu ermöglichen, werden
nach diesem Modell die Funktionen auf 7 unabhängige Schichten verteilt. Die Realisierungen dieser Funktionen sind nicht Bestandteil der Spezifikation. Einzelne Schichten
können ausgetauscht werden und sind für die übergeordneten transparent. Wie in Abbildung 1.1 zu sehen, sind die Schichten in transportorientierte (1-4) und anwendungsorientierte (5-7) unterteilt. Die Funktionen der einzelnen Schichten werden im Folgenden
beschrieben.
Bitübertragungsschicht (physical layer)
Dies ist die unterste Schicht und beschreibt die physikalischen Parameter der Übertragung. Die Protokolle dieser Ebene beziehen sich auf die Darstellung der Daten
als elektrische Signale, optische Signale oder Funkwellen für das jeweils eingesetzte
Übertragungsmedium.
2
1 Protokollübersicht
Sicherungsschicht (datalink layer)
Die Hauptfunktionen liegen hier bei der Fehlerkontrolle und den damit verbundenen Korrekturmechanismen. Des Weiteren realisiert diese dieser Schicht die Flusskontrolle, die den Zugriff auf das Übertragungsmedium regelt.
Vermittlungsschicht (network layer)
Aufgabe dieser Schicht ist die Steuerung und Verwaltung der Verbindung zwischen
Quelle und Ziel. Das wichtigste Element ist hier das Routing, wodurch die Information auf einem der möglichen Wege von der Quelle zum Ziel geleitet wird.
Transportschicht (transport layer)
Die Aufgaben dieser Schicht liegen in der Segmentierung und Reassemblierung der
Daten, sowie in der Zuordnung von eintreffenden Datenpaketen zur Zielanwendung.
Kommunikationsschicht (session layer)
Die Aufgabe dieser Schicht ist die Steuerung logischer Verbindungen durch die
Bereitstellung von Diensten zum geordneten und synchronisierten Datenaustausch.
Darstellungsschicht (presentation layer)
In dieser Schicht wird die systemabhängige Datendarstellung in eine systemunabhängige umgesetzt. Die Darstellung der Daten in einer von der Codierung der
darüber liegenden Schicht unabhängigen Form ermöglicht die Kommunikation unterschiedlicher Systeme.
Anwendungsschicht (application layer)
Die Protokolle dieser Ebene werden den Anwendungen zur Verfügung gestellt, beziehungsweise von den Anwendungen spezifiziert.
1.2 TCP/IP Referenzmodell
Das TCP/IP Referenzmodell ist ein Schichtenmodell, welches das ISO-OSI Modell auf
4 Ebenen abbildet. Benannt ist es nach den primär genutzten Protokollen Transmission
Control Protocol (TCP) und Internet Protocol (IP), allerdings schließt das Modell alle
im Internet verwendeten Protokolle ein. Ein Vergleich zum ISO-OSI 7 Schichtenmodell,
sowie eine Zuordnung der Schichten ist in Abbildung 1.1 zu sehen. Auf eine kurze Erläuterung dieses Modells folgt in den nächsten Kapiteln eine genauere Betrachtung der
Protokolle IP und TCP.
3
1 Protokollübersicht
transport-orientiert
anwendungsorientiert
OSI 7 Schichtenmodell
TCP/IP Modell
Protokollbeispiele
Anwendungsschicht
HTTP, FTP, POP3,
Telnet, SSH
7
Anwendungsschicht
6
Dartellungsschicht
5
Kommunikationsschicht
4
Transportschicht
Transportschicht
TCP, UDP
3
Vermittlungsschicht
Internetschicht
IP
2
Sicherungsschicht
Netzwerkschicht
Ethernet, WLAN,
PPP
1
Bitübertragungsschicht
Abbildung 1.1: ISO-OSI 7 Schichtenmodell, TCP/IP Referenzmodell
Netzwerkschicht (network layer)
Diese Schicht stellt das Übertragungsmedium dar, spezielle Funktionen werden im
Referenzmodell nicht beschrieben. Als Beispiele sollen hier nur die Übermittlung
von IP-Paketen über Ethernet oder WLAN aufgeführt werden.
Internetschicht (internet layer)
Die Weitervermittlung und das Routing (Wegfindung) der Pakete werden in dieser
Schicht realisiert. Zur Anwendung kommt hier das Internetprotokoll (IP).
Transportschicht (transport layer)
Wie in dem ISO-OSI 7 Schichtenmodell ermöglicht diese Schicht die Kommunikation zwischen Quell- und Zielsystem durch Segmentierung und Reassemblierung.
TCP und UDP (User Datagram Protocol) sind Protokolle dieser Schicht.
Anwendungsschicht (application layer)
In dieser Schicht sind Protokolle vereinbart, über die die Anwendungen auf den
Protokollstapel zugreifen und ihre Daten versenden. Beispiele für Protokolle dieser
Schicht sind: HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol)
oder POP (Post Office Protocol).
Am Beispiel dieses Referenzmodells soll hier das Prinzip der Protokollkapselung näher
betrachtet werden. Ein Segment hat in jeder Ebene den gleichen Aufbau, es besteht aus
einem Protokollkopf (Header) und den Nutzdaten (Payload). In dem Protokollkopf befinden sich Informationen, die für die Realisierung der Funktionen benötigt werden und
4
1 Protokollübersicht
Schicht 4
HTTP-Header
Schicht 3
Payload
TCP-Header
Schicht 2
Payload
IP-Header
Schicht 1
Payload
MAC-Header
Payload
Abbildung 1.2: Beispiel der Protokollkapselung
31
24
Version
IHL
16
Type of Service
0
Packet Length
Identification
TTL
8
Flags
Protocol
Fragment-Offset
Header Checksum
Source IP Address
Destination IP Address
Options
Padding
Abbildung 1.3: IPv4 Header
Schicht- und Protokollabhängig sind. Ein Segment wird an die darunter liegende Schicht
weitergegeben, dort als Nutzdaten betrachtet und der Protokollkopf des dort verwendeten Protokolls vorangestellt. In Abbildung 1.2 wird ein Schicht 4 HTTP-Segment über
die Transport- und Internetschicht zu der Netzwerkschicht weitergegeben. Dabei vergrößert sich das Segment von Schicht zu Schicht um die jeweilige Größe des Protokollkopfes.
Auf dem Weg zum Empfänger und dort angekommen werden in umgekehrter Reihenfolge
zunächst der MAC-Header, dann der IP-Header gefolgt vom TCP-Header ausgewertet
und entfernt, so dass in Schicht 4 wieder das originale Paket eintrifft.
1.3 Internetprotokoll
Das Internetprotokoll, welches in der Internetschicht des TCP/IP-Referenzmodells zum
Einsatz kommt, existiert in unterschiedlichen Versionen. Bei Entstehen dieser Arbeit
liegt der Standard bei IP in der Version 4 (IPv4), welche 1981 in RFC791 [10] spezifiziert wurde. Die Version 6 (IPv6) des Internetprotokolls ist bereits spezifiziert, aber
5
1 Protokollübersicht
in der Nutzung nicht weit verbreitet. Der Grund für die Entwicklung eines neuen Standards liegt in der knapper werdenden Anzahl der IP-Adressen, sowie in einigen Defiziten
betreffend Sicherheit, Mobilität und Qualität von IPv4. Nach Version 4 des Protokolls
hat eine Adresse eine Länge von 32 Bit und begrenzt die Anzahl der Internetbenutzer
auf 4 Milliarden. Durch IPv6 wird das Problem der Knappheit von IP-Adressen gelöst,
da die Adresslänge auf 128 Bit erhöht wurde. Das entspricht einer Benutzeranzahl von
über 3 ∗ 103 8. Im Folgenden wird nur auf IPv4 eingegangen, zu IPv6 sei auf RFC2460
[5] verwiesen. Die Aufgaben, die mit IP gelöst werden, umfassen die Adressierung der
Verbindungsteilnehmer, die Fragmentierung von Paketen, sowie die Wegfindung und das
Weiterleiten der Pakete von der Quelle zum Ziel. Das Internetprotokoll ist ein Verbindungsloses Protokoll, es wird keine Ende-zu-Ende Verbindung zwischen den Teilnehmern
aufgebaut. Deshalb ist eine garantiere Zustellung der Daten mit diesem Protokoll nicht
möglich und muss durch andere Schichten gewährleistet werden. Der Protokollkopf ist
in Abbildung 1.3 gezeigt und die einzelnen Felder haben folgende Bedeutung.
Version (Versionsnummer)
Dieses Feld enthält die Versionsnummer des verwendeten Internetprotokolls. Momentan ist dies meist die Version 4.
IHL (Internet Header Länge)
Da der Header auch optionale Felder enthalten kann, wird in diesem Feld die
Länge des Protokollkopfes des aktuellen Paketes in Vielfachen von 32Bit-Worten
angegeben. Der Mindestwert beträgt 5, da die Headerlänge ohne optionale Felder
5x32 Bit beträgt.
Type of Service (Übertragungskriterien)
Dieses Feld wird seltener genutzt, bietet aber die Möglichkeit das Paket nach bestimmten Kriterien zu kategorisieren. Die Übertragungseigenschaften betreffen die
Zuverlässigkeit, den Durchsatz sowie die Verzögerung.
Length (Länge)
Hier wird die Gesamtlänge des IP-Paketes eingetragen, die den Paketkopf sowie
die Nutzdaten umfasst.
Identification (Datenzugehörigkeit)
Werden die Daten auf IP-Ebene fragmentiert, so kann der Empfänger an Hand der
Identifikationsnummer feststellen zu welchen Daten das Fragment gehört.
6
1 Protokollübersicht
Offset (Fragmentposition)
Dieses Feld beschreibt die Position des aktuellen Fragmentes in den Daten. In Verbindung mit der Identifikationsnummer ist es somit möglich die Gesamtinformation
aus den Fragmenten wiederherzustellen.
TTL (Time to live)
Dieser Wert dient als Zähler zur Begrenzung der Lebensdauer eines Paketes wird.
In RFC791 wurde ursprünglich die Einheit Sekunden definiert, wodurch eine maximale Lebensdauer von 255 Sekunden bei der gegebenen Feldbreite von 8Bit resultierte. Die reale Implementierung weicht allerdings von dieser Definition ab. Auf
dem Weg zum Ziel wird dieser Wert in jedem Netzknoten erniedrigt. Erreicht der
Inhalt dieses Feldes den Wert Null, so wird das Paket verworfen.
Protocol (Protokoll der nächsten Schicht)
Dieser Wert kennzeichnet das im Datenbereich transportierte Protokoll und ist
für die weitere Interpretation der Daten von Bedeutung. Die Verwendung von
TCP in Schicht 3 des TCP/IP Referenzmodells wird mit der Protokollnummer 6
gekennzeichnet.
Source, Destination IP Address (Quell-,Ziel IP Adresse)
Diese Felder enthalten die Quell- und Zielinternetadressen und sind als Absender
und Adressat des Paketes zu verstehen. IP-Adressen sind im Internet eindeutig
zuzuordnen und haben nach IPv4 eine Länge von 32Bit.
Options (zusätzliche Optionen)
In dieses optionale Feld variabler Länge können zusätzliche Informationen an den
Protokollkopf angehängt werden. Diese Informationen haben ein bestimmtes Format, welches in RFC791 näher beschrieben ist. Die Länge dieser Optionen wird
implizit mit dem Wert im Feld IHL festgelegt und is somit auf 10x32Bit begrenzt.
1.4 Internet Control Message Protocol
Das Internet Control Message Protocol (ICMP) ist eng mit IP verbunden und ist in [11]
spezifiziert. Bei Problemen im Versand von IP-Paketen werden diese Steuernachrichten an den Absender versendet. Des Weiteren werden dadurch Netzwerkanalysemöglichkeiten angeboten, wie beispielsweise Laufzeitenermittlung. ICMP-Nachrichten werden
gekapselt in IP-Paketen versendet, obwohl ICMP auf der gleichen Ebene im TCP/IP
7
1 Protokollübersicht
31
24
IP-Header
Version
16
IHL
8
Type of Service
Packet Length
Identification
TTL
Flags
Protocol
Fragment-Offset
Header Checksum
Source IP Address
Destination IP Address
Options
ICMP-Message
0
ICMP Type
Padding
Code
Typespecific
Typespecific
Internet Header + 64Bit of Original Datagram
Abbildung 1.4: Aufbau einer mit IP transportierten ICMP-Nachricht
ICMP Typ
Nummer
0
Echo Reply
3
Destination Unreachable
4
Source Quench
5
Redirect
8
Echo
11
Time Exceeded
12
Parameter Problem
13
Timestamp
14
Timestamp Reply
Tabelle 1.1: ICMP Nachrichtentypen
Referenzmodell angesiedelt ist. Das heißt, diese Nachrichten werden nicht an die Transportschicht weiter gereicht, sondern schon in der Internetschicht verarbeitet. Wie in
Abbildung 1.4 zu sehen, ist im Datenbereich des IP-Paketes die ICMP-Nachricht enthalten. Es gibt mehrere Typen von ICMP-Nachrichten, die unterschiedliche Probleme im
Netzwerk beschreiben. Der Aufbau eines ICMP-Paketes ist abhängig vom Typ. Bezieht
sich die Steuermeldung auf ein IP-Paket, so ist die ICMP Nachricht wie in der Abbildung aufgebaut. Aus dem Typfeld lassen sich die davon abhängigen spezifischen Felder
ableiten. Der IP-Header und die ersten 64 Datenbits des diese Meldung auslösenden
Originalpaketes sind an diese Informationen angehängt. Einige ICMP-Typen sind in Tabelle 1.1 aufgeführt, wobei die Typen 3, 4, 5, 11 und 12 den in der Abbildung gezeigten
Aufbau haben.
8
1 Protokollübersicht
31
24
16
Source Port
8
0
Destination Port
Sequence Number
Acknowledgement Number
Offset
Reserved
Flags
Window
Checksum
Urgent Pointer
Options
Padding
Data
Abbildung 1.5: TCP Segment
1.5 Transmission Control Protocoll
Das Transmission Control Protocoll gehört zur Familie der Internetprotokolle und realisiert die Funktionen der Transportschicht des TCP/IP-Referenzmodells. Es ist ein verbindungsorientiertes Transportprotokoll und dient nach dem Verbindungsaufbau der korrekten Datenübertragung und darauf folgendem Verbindungsabbau zwischen Netzwerkgeräten. Eine erste Standardisierung erfolgte 1981 mit [12], welches später durch [13]
eine Aktualisierung erfuhr.
Bei einer TCP-Verbindung wird ein virtueller Kanal zwischen zwei Verbindungsteilnehmern, den so genannten Sockets, hergestellt. Ein Socket identifiziert sich durch ein geordnetes Paar aus IP-Adresse zur Identifikation des Rechners und Portnummer zur Zuordnung der kommunizierenden Anwendung. Eine einzelne TCP-Verbindung wird identifiziert durch ein Socketpaar, also einem Quadrupel von IP’s und Ports. Durch die Einzigartigkeit von IP-Adressen im Internet ist somit eine eindeutige Identifizierung einer
TCP-Verbindung möglich.
1.5.1 TCP Header
Der Aufbau eines TCP-Paketes ist in Abbildung 1.5 gezeigt. Es umfasst einen Header
mit einer Länge von 20 bis 64 Byte mit darauf folgenden Nutzdaten. Die nachfolgend beschriebenen ersten 20 Byte im TCP-Header enthalten Standardfelder, die verbleibenden
44 Byte können als Speicherplatz für optionale Informationen dienen.
Source-, Destinationport (Quell- und Zielportadresse)
Diese 16 Bit breiten Adressen bezeichnen die lokalen Endpunkte der Verbindung
und sind Teil des Socketpaares.
Sequence, Acknowledgment Number (Sequenznummer und Bestätigungsnummer)
9
1 Protokollübersicht
Die Bytes, beziehungsweise Oktetts, die bei einer TCP-Verbindung übertragen
werden, sind durchnummeriert. Die Sequenznummer gibt die Folgenummer des
ersten in diesem Segment übertragenen Byte an. Die Bestätigungsnummer gibt
das als nächstes erwartete Byte an. Die beiden Felder sind jeweils 32 Bit breit.
Offset (TCP-Headerlänge)
Da der TCP-Header eine variable Länge hat, wird diese in diesem Feld angeben.
Dieses Feld ist 4 Bit breit und bezieht sich in der Angabe auf die Anzahl der
32Bit-Wörter im Header, woraus sich die Maximallänge von 64 Byte ergibt.
Reserved (reservierter Bereich)
Dieses Feld bietet Raum für Erweiterungen, mit RFC3168 wurden 2 neue Flags
eingeführt. Mit den zusätzlichen Flags: CWR und ECE wird in Verbindung mit IP
Explicit Congestion Notification (ECN) unterstützt. Über diese Flags wird TCP
über Gedrängtheit im Datenpfad informiert.
Flags (6 Bits)
Die in diesem Bereich enthaltenen Informationen dienen der Steuerung der Verbindung und umfassen 6 Flags mit unterschiedlicher Bedeutung. Das URG- und
das PSH-Flag dienen bei Empfang der schnellen Weitergabe der Daten an die Anwendung. Das ACK-Flag bestätigt zusammen mit der Bestätigungsnummer die
bis dahin empfangenen Daten und fordert gleichzeitig Daten ab dem angegebenen Byte an. Durch das RST-Flag wird eine Verbindung zurückgesetzt. Ein mit
dem SYN-Flag gekennzeichnetes Segment dient dem Verbindungsaufbau und ein
FIN-gekennzeichnetes dient dem Verbindungsabbau.
Window (Fenstergröße)
Die Fenstergröße gibt die Anzahl der Byte an, die der Empfänger bereit ist zu
empfangen. Dieses Feld ist 16Bit breit und ist somit für heutige Anwendungen
zum Teil zu klein. Aus diesem Grund gibt es die Möglichkeit das Fenster auf ein
in den Optionen angegebenes Vielfaches dieses Wertes festzulegen.
Checksum (Prüfsumme)
Dieses Feld dient zur Erkennung von Übertragungsfehlern und wird aus dem Header, den Daten und einem Pseudoheader berechnet.
Urgent Pointer (Dringlichkeitszeiger)
Dieses Feld ergibt zusammen mit der Sequenznummer die Position der dringlichen
10
1 Protokollübersicht
Daten, falls das URG-Flag gesetzt ist.
1.5.2 Verbindungsaufbau
H
O
S
T
1
syn, seq=x
syn/ack, ack=x+1, seq=y
ack=y+1, seq=x+1
H
O
S
T
2
Abbildung 1.6: TCP 3-Wege Verbindungsaufbau
Der Aufbau einer TCP-Verbindung erfolgt nach dem unter anderem in [15] beschriebenem 3 Wege Handshake Verfahren. Dieses ist ein allgemeines Verfahren und wurde nicht
für TCP entwickelt, ist aber für TCP im RFC793 als Verfahren festgelegt. Es wird ein
Request von einem Teilnehmer (Host) an den anderen geschickt, das bestätigt werden
muss. Mit der Bestätigung wird eine eigene Anforderung versendet, auf die wiederum
eine Antwort erwartet wird. Der Standardablauf beim Aufbau einer TCP-Verbindung
ist in Abbildung 1.6 dargestellt. Bevor die Verbindung aufgebaut werden kann, muss der
Initiator einen TCP-Socket aus seiner eigenen IP-Adresse und dem Port generieren. Des
Weiteren muss der Endpunkt der Gegenstelle bekannt sein, um ein so genanntes SYNPaket zu versenden. In diesem SYN-Paket ist eine zufällige Synchronisationsnummer im
Sequenznummernfeld enthalten, sowie das SYN-Flag gesetzt. Die Ziel-IP in Verbindung
mit dem angegebenen Port bilden den Endpunkt beim gewünschten Verbindungsteilnehmer. Dieser verschickt, nach Eintreffen eines solchen Paketes, seinerseits ein Paket mit
folgendem Inhalt. Die Antwort enthält eine eigene Sequenznummer, eine Bestätigungsnummer, die gleich der um eins erhöhten empfangenen Sequenznummer ist, sowie die
gesetzten Flags ACK und SYN. Bei Ablauf des 3 Wege Handshake Verfahrens können
einzelne Sonderfälle, wie das gleichzeitige Öffnen der Verbindung, auftreten. In diesem
Fall trifft nach Versand eines SYN-Paketes ein SYN-Paket der Gegenstelle ein, worauf
mit einem Bestätigungspaket geantwortet wird. In dem ist das ACK- und SYN-Flag
gesetzt, eine Sequenznummer gleich der in dem zuvor versandten SYN-Paket, sowie
ein Bestätigungsnummer, wie oben beschrieben, enthalten. Der 3-Wege-Handshake zum
Verbindungsaufbau basiert also auf dem Austausch von Sequenznummern und deren Be-
11
1 Protokollübersicht
stätigung. Bestimmte Probleme können durch verloren gehen von Synchronisations und
Bestätigungspaketen oder doppeltes Versenden von Paketen entstehen, welche durch das
TCP-Protokoll gelöst werden und in der Spezifiaktion RFC793, sowie in [15] beschrieben
sind.
1.5.3 Datenübertragung
H
O
S
T
1
seq=0, 1kB Data
syn=200, ack=1024, 512Byte Data
seq=1024 ,ack=712, 1kB Data
H
O
S
T
2
Abbildung 1.7: Datenübertragung mit TCP
Die Übertragung der Daten während einer TCP-Verbindung basiert auch auf dem Versenden von Paketen und deren Bestätigung. Die wichtigsten Merkmale bei der Regelung
einer korrekten Übertragung sind die Sequenz- und Bestätigungsnummern, sowie das
Fenster- und Timermanagement. Das Prinzip der Paketbestätigung soll mit Hilfe der
Abbildung 1.7 erläutert werden. Jedem Byte der übertragenen Daten wird eine Sequenznummer zugeordnet, wobei die im Header angegebene die Nummer des ersten Bytes
im aktuellen Paket ist. In dem Paket von Host 1 zu Host 2 ist in diesem Beispiel die
Sequenznummer gleich Null. Dieses Paket enthält Daten mit einer Länge von 1024 Byte
(1kB), die Nummer des ersten Bytes ist also 0 und die des letzten 1023. Host 2 bestätigt
das Paket mit gesetztem ACK-Flag und der Bestätigungsnummer 1024, was dem als
nächstes erwarteten Byte entspricht. Gleichzeitig werden 512 Byte Daten übertragen,
die Sequenznummer des ersten Bytes ist 200. Trifft das Paket von Host 2 bei Host 1
ein, so werden die empfangenen Daten bestätigt und wiederum gleichzeitig der nächste
Datenblock übertragen. Während einer Übertragung muss nicht jedes Paket einzeln bestätigt werden. Wird beispielsweise nach Empfang eines Paketes ein weiteres erwartet,
so kann ein Host auf das Eintreffen warten und mit Bestätigung des zweiten Paketes
implizit das erste auch bestätigen. Wie viele Byte ein Sender ohne Empfang einer Bestätigung versenden darf, hängt von der Fenstergröße ab die der Empfänger mit jeder
Bestätigungsnachricht im gleichnamigen Headerfeld angibt. Die Verbindungsteilnehmer
12
1 Protokollübersicht
Empfangspuffer
1.
2.
Fenstermax
3.
Timerablauf
H 4.
o
s
t
1
seq=0, 1kB Data
seq=1024, 1kB Data
seq=2048, 1kB Data
seq=0, 1kB Data
ack=3072, Window=0
ack=3072, Window=1024
7.
H
o
5. s
t
6.
leer
1k
1k
1k
1k
1k
1k
1k
voll
1k
1k
1k
1k
Datenverarbeitung
1k
2
1k
1k
Datenverarbeitung
seq=3072, 1kB Data
ack=4096, Window=2048
1k
8.
1k
2k
Abbildung 1.8: Flusskontrolle und Timermanagement
verfügen über einen Buffer mit einer bestimmten Größe und können nur genau so viele
Daten empfangen. Diese Vorgehensweise nennt sich Flusskontrolle und hat den Vorteil,
dass ein schnellerer Host davon abgehalten wird zu viele Pakete zu verschicken, die
sonst verloren gehen würden und somit unnötig Bandbreite im Netz belegen. Zum anderen kann durch ein großes Fenster die Bandbreite einer Verbindung erhöht werden, wenn
die Verzögerungszeiten bis zum Ziel sehr hoch sind. Wenn das Fenster in diesem Fall
sehr klein ist, dann hat der sendende Host schnell die maximale Paketanzahl versendet
und muss lange auf eine Bestätigung warten. Ist das Fenster größer, können mehr Daten
verschickt werden, der Host muss nicht so oft warten und erhält im besten Fall nur eine Bestätigungsnachricht. Des Weiteren werden vom Empfänger nur Pakete verarbeitet,
deren Sequenznummer auch im Fenster liegt. Weil Pakete im Internet verloren gehen
können, müssen diese unter Umständen mehrfach versendet werden. Darum wird für
jedes versandte Paket ein Timer, der so genannte Retransmissiontimer, gestartet. Trifft
vor Ablauf dieses Timers keine Bestätigung für das Paket ein, so wird es ein weiteres Mal
verschickt. Dies kann für alle Pakete solange wiederholt werden, bis die maximale Anzahl
an Sendewiederholungen erreicht ist, danach wird die Verbindung beendet. Der Grund
für die Sendewiederholung kann entweder im versandten Paket oder im verloren gegangenen Bestätigungspaket des Empfängers liegen. Verlorene Bestätigungen lösen sich durch
die Sendewiederholung der Daten auf. Deshalb wird für sie kein Retransmissiontimer gestartet und keine weitere Bestätigung erwartet. Die Wahl des Retransmissiontimers und
der maximalen Anzahl an Sendewiederholungen ist von der TCP-Implementierung ab-
13
1 Protokollübersicht
hängig und nicht in der Protokollspezifikation festgelegt. Der Retransmissiontimer wird
beispielsweise während der Verbindung ständig angepasst und variiert, er ist abhängig
von der Roundtriptime (RTT). Dies ist die Zeit, die vom Versenden der Nachricht bis
zum Eintreffen der Bestätigung vergeht. Zur Bestimmung der Fenstergröße und zum Update der Timer während der Verbindung existieren die Überlastmechanismen: slow start,
congestion avoidance, fast retransmit und fast recovery, die in [8], sowie in [7] genau
beschrieben werden. Durch slowstart und congestion avoidance tastet sich ein Sender an
die maximale Durchsatzfähigkeit des Netzes heran. Die Anzahl der versendeten Pakete
ohne Bestätigung wird schrittweise erhöht, bis ein Fehler in der Übertragung auftritt.
Fast retransmit ist eine Möglichkeit, durch die der Empfänger direkt fehlende Pakete
anfordern kann. Bei Empfang eines Paketes mit falscher Sequenznummer sendet der
Empfänger sofort eine doppelte Bestätigung, mit Bestätigungsnummer des erwarteten
Paketes. Dadurch muss der Sender mit dem wiederholten Senden nicht warten bis der
RTO abgelaufen ist.
Am Beispiel in Abbildung 1.8 soll das Timer- und Fenstermanagement nochmals verdeutlicht werden. Hier haben sich die Hosts auf einen Empfangspuffer von 3kB bei Host2
geeinigt. Host1 verschickt 3 Pakete, die zusammen der Fenstergröße entsprechen und wartet daraufhin auf eine Bestätigung. Diese trifft nicht vor Timerablauf ein, da das erste
Paket verloren ging. Also beginnt Host1 die Pakete ein zweites Mal zu verschicken (Zeitpunkt 4), während dessen die Bestätigung für alle 3 Pakete eintrifft. Host2 gibt mit dieser
Bestätigung an, dass sein Puffer voll ist und setzt die Fenstergröße auf Null. Nachdem
die übergeordnete Anwendung beginnt die Daten zu verarbeiten aktualisiert Host2 zum
Zeitpunkt 6 die Fenstergröße und Host1 setzt den Datenversand fort.
1.5.4 Verbindungsabbau
Auch der Verbindungsabbau läuft nach dem 3-Wege-Handshakeverfahren ab. Der Unterschied zum Aufbau der Verbindung liegt darin, dass ein einseitiger Abbau möglich ist.
Der Versand von Datenpaketen ist danach nur noch in eine Richtung möglich. Wurden
von einem Host alle Datenpakete versandt, so kann dieser den Abbau der Verbindung
mit einem FIN-Paket einleiten. Wie in Abbildung 1.9 zu sehen ist, wird ein Paket mit
gesetztem FIN-Flag wie jedes andere Datenpaket bestätigt. In diesem Fall wünscht auch
der Server einen Verbindungsabbau und schickt mit der Bestätigung (ACK-Flag) gleichzeitig ein FIN, welches wiederum vom Client bestätigt wird. Das Timermanagement ist
14
1 Protokollübersicht
H
O
S
T
1
fin, seq=x
fin, ack=x+1, seq=y
ack=y+1
H
O
S
T
2
Abbildung 1.9: TCP 3-Wege Verbindungsabbau
bei FIN-Paketen das gleiche wie beim Datenversand, bei Nichtbestätigung erfolgt ein
weiterer Versand. Da auch hier die Bestätigungsnachrichten nicht quittiert werden, startet der Host, der nach dem 3-Wege-Handshake das letzte ACK versendet, einen Timer.
Läuft dieser aus, so wird der Empfang durch die Gegenstelle angenommen und die Verbindungsinformationen werden aus dem Speicher gelöscht. Nach Versand und Empfang
aller Daten ist es nicht vorgeschrieben, dass die Verbindung abgebaut werden muss. Sie
bleibt solange bestehen, wie die Hosts die Verbindungsdaten im Speicher behalten. In
der Zeit belegt das die Ressourcen der Verbindungsteilnehmer und es kann jeder Zeit mit
dem Versenden von Daten fortgefahren werden, ohne die Verbindung neu aufzubauen.
15
2 Angriffe auf Internetverbindungen
Im Folgenden soll auf verschiedene Angriffe auf TCP-Verbindungen eingegangen werden,
da mit dem zu entwickelnden Modul das Ziel verfolgt wird diese abzuwehren. Die Angriffe
teilen sich in drei Kategorien.
• angriffsvorbereitende Informationsgewinnung
• Denial of Service (DoS) Attacken, zur Blockierung eines angebotenen Dienstes
• Angriffe auf einzelne TCP-Verbindungen
2.1 Informationsgewinnung
Zur reinen Informationsgewinnung dienen die so genannten Adress- und Portscans. Hierbei werden bestimmte Pakete an Ports des möglichen Angriffziels oder mehreren Zielen
in einem Netzwerk gesendet. Erhält man eine Antwort, so hat man eine mögliche Angriffsstelle beim Ziel gefunden. Anhand der Reaktion eines Ziels, lassen sich Rückschlüsse auf das verwendete Betriebssystem, die Sicherheitseinstellungen und den Status der
Ports ziehen. Bekannte Sicherheitslücken können somit in folgenden Angriffen gezielt
ausgenutzt werden. Portscans können eingeteilt werden in Stealthscans und Half open
Portscans.
Bei ersteren findet keine im Protokoll spezifizierte Kommunikation zwischen Angreifer
und Opfer statt. Der Angreifer schickt ein beliebiges Paket an einen Port des Opfers,
wartet auf eine Antwort und wertet diese ohne weitere Kommunikation aus. Die gesendeten Pakete unterscheiden sich hinsichtlich der gesetzten Flags im TCP-Header. Als
populäre Scans sind folgende zu nennen:
• FIN-Scan: Ein Paket mit gesetztem FIN-Flag wird an einen Port des Opfers geschickt.
• Xmas-Scan: Bei dieser Art des Scans sind mehrere Flags (FIN, URG, PSH) gesetzt.
16
2 Angriffe auf Internetverbindungen
• Null-Scan: Alle Flags sind in diesen Paketen Null.
• Syn/Ack-Scan: Die Flags SYN und ACK sind bei diesem Scan gesetzt.
Die genannten Pakete sind als einzelne Pakete, in einer nicht bestehenden oder sich im
Aufbau befindlichen Verbindung, nicht korrekt. Beim Half open Portscan wird ein Verbindungsaufbau mit einem SYN-Paket initiiert. Bei Erhalt einer Antwort mit gesetztem
SYN und ACK Flag wird die Verbindung sofort wieder getrennt. Des Weiteren sendet
ein Server auch einige Informationen beim Verbindungsaufbau, so genannte Bannertexte.
In der Gesamtheit bilden diese Informationen also einen spezifischen Fingerabdruck des
Zielsystems und dienen der Planung der weiteren Vorgehensweise bei den Angriffen.
2.2 Denial of Service Attacken
Diese Art der Angriffe zielt darauf ab, die Verfügbarkeit von bestimmten Rechnern
oder Diensten einzuschränken. Dies kann beispielsweise die Nichterreichbarkeit einer
Internetseite zur Folge haben. Es gibt drei unterschiedliche Vorgehensweisen bei der
Durchführung dieser Angriffe:
• Bandbreitensättigung
• Ressourcensättigung
• Herbeiführung von Systemabstürzen
Bei der Bandbreitensättigung wird durch so genanntes Flooding mehr Verkehr im Zielnetzwerk erzeugt als dieses verarbeiten kann, wodurch reguläre Anfragen wegen der
Überlastung abgewiesen werden. Diesen Verkehr kann der Angreifer selbst erzeugen
oder erzeugen lassen, beispielsweise durch eine Smurf Attacke. Hier wird ein bestimmtes
ICMP-Paket, ein Pingrequest, an eine Broadcastadresse im Zielnetzwerk geschickt auf
das alle Rechner antworten. Die Antworten gehen an die Quelle des ursprünglichen Paketes. Da der Angreifer als Quelladresse die IP des Opfers angegeben hat, wird dieses
mit Paketen überflutet und regulärer Netzwerkverkehr ist nicht mehr möglich.
Unter Ressourcensättigung ist die Belegung von Systemressourcen auf dem Zielrechner
zu verstehen. Dies kann den Arbeitsspeicher oder auch die Rechenzeit des Zielsystems
betreffen. Die Anzahl Verbindungen, die ein Server gleichzeitig geöffnet haben kann, hängen vom Arbeitsspeicher oder den lokalen Einstellungen ab. Dies nimmt Synflooding als
17
2 Angriffe auf Internetverbindungen
Angriffspunkt, da für jede Verbindung Platz im Speicher benötigt wird. Bei diesem Angriff werden nun so viele Verbindungen initiiert, dass der Speicher des Opfers voll läuft
und reguläre Verbindungen abgewiesen werden müssen. Die TCP-Pakete mit gesetztem
SYN-Flag besitzen gefälschte und unterschiedliche IP-Adressen, diesen Vorgang nennt
man IP-Spoofing.
Für die bisher genannten Angriffe ist es für den Angreifer wichtig eine hohe Bandbreite zur Verfügung zu haben, um viele Pakete in kurzer Zeit schicken zu können. Diese
kann er auch durch den Einsatz eines verteilten Angriffs, dem so genannten Distributed
Denial of Service (DDoS) [3], erlangen. Bei diesem Vorgehen werden zunächst versteckte
Programme bei vielen Internetbenutzern installiert, die dann gleichzeitig mit dem Versand von Angriffspaketen starten. Ein weiterer Nachteil bei dieser Strategie ist, dass
diese Attacken sehr schwierig auf den eigentlichen Angreifer zurückzuverfolgen sind.
Die im Folgenden beschriebenen Angriffe können den Absturz des Zielrechners zur
Folge haben.
• Ping of Death: Hier wird ein überlanges ICMP-Paket verschickt, welches nach der
Reassemblierung einen Speicherüberlauf produziert und so beim Zielrechner einen
Absturz oder Neustart verursacht.
• Teardrop: Auch bei diesem Angriff ist die Fragmentierung des IP-Paketes nicht
korrekt.
• Landattacke: Bei dieser Attacke wir ein Paket verschickt, bei dem Quell- und ZielIP, sowie Ports gleich sind. Die Antwort auf dieses Paket trifft also umgehend
wieder beim Opfer ein. Dies kann zu einer Schleife führen, womit der Rechner
überfordert ist.
• WinNuke: Ein TCP-Paket mit gesetztem URG-Flag wird hier an den Port 139
eines Rechners geschickt, was bei älteren Betriebssystemen zum Systemabsturz
führt.
Die Nichtverfügbarkeit eines Dienstes durch hohes Verkehrsaufkommen muss allerdings
nicht immer kriminellen Ursprungs sein. Ein Beispiel dafür ist der Slashdot Effekt, bei
dem ein Internetdienst auf einer stark frequentierten Internetseite verlinkt ist. Ist dieser
Anbieter der ungewöhnlich hohen Nutzeranzahl, die dem Link folgen nicht gewachsen,
18
2 Angriffe auf Internetverbindungen
so werden seine Ressourcen oder Bandbreite gesättigt und weitere Anfragen müssen
zurückgewiesen werden.
2.3 Angriffe auf einzelne TCP-Verbindungen
Direkte Angriffen auf TCP-Verbindungen unterschiedet man in Manipulation der Verbindung durch ICMP Steuerpakete und Manipulation oder Übernahme der Verbindung
durch Generierung anscheinend korrekter TCP-Pakete. Zum einen kann durch ICMPNachrichten eine Verbindung zurückgesetzt werden, zum anderen ist es möglich verschieden Übertragungsparameter zu ändern. Diese Änderungen bewirken meist eine Reduzierung der Übertragungsgeschwindigkeit durch Änderung der Fragmentierung oder
der TCP-Fenstergröße. Der Angreifer muss zum Versand einer als regulär angesehenen
ICMP Nachricht nur die IPs und Ports der Verbindungsteilnehmer wissen, um diese korrekt im Datenbereich zu integrieren. Der Check auf die Verbindungsidentifikation fällt
somit beim Opfer positiv aus und die Übertragungsparameter werden angepasst.
Angriffe durch generierte TCP-Pakete basieren darauf, sich als Verbindungspartner
auszugeben. Dies passiert durch so genanntes Spoofing, bei dem der Angreifer zunächst
die Verbindungsinformationen ausspioniert und daraufhin Pakete mit den entsprechenden IPs und Ports der Zielverbindung verschickt. Des Weiteren muss sein Paket eine
gültige Sequenznummer besitzen, damit es vom Opfer anerkannt wird. Mit diesen generierten Paketen kann die Verbindung durch gesetztes RST-Flag zurückgesetzt werden
oder der Angreifer gibt sich weiterhin als Verbindungspartner aus um weitere Informationen zu erhalten oder weiterführende Manipulationen am Zielrechner durchzuführen.
2.4 Schutzmechanismen
Der Schutz vor Angriffen liegt in der Verantwortung des Anwenders oder Netzwerkadministrators, deren Einsatzmittel hierbei Firewalls und Systeme zum Aufspüren von
Eindringlingen (Intrusion Detection System - IDS) sind. Eine Firewall lässt aufgrund
bestimmter Regeln den Netzwerkverkehr zu oder blockiert ihn. Sie werden in Paketfilter und Firewalls auf Anwendungsebene unterschieden [16]. Paketfilter analysieren
die die Rohdaten und treffen ihre Entscheidung auf Grund Headerinformationen der
Netzzugangs-, Netzwerk- und Transportschicht. Dadurch ist es möglich, Pakete mit bestimmten Protokolltypen oder Adressen zu blockieren. Nutzen Paketfilter nicht nur Infor-
19
2 Angriffe auf Internetverbindungen
mationen über das aktuelle Paket, sondern auch über andere Pakete und Verbindungen,
so spricht man von zustandsbehafteten Paketfiltern. Firewalls auf Anwendungsebene
beschränken sich nicht auf die Headerauswertung, sondern analysieren zusätzlich die
Nutzdaten auf Anwendungsebene. Diese Firewalls werden auch Proxys genannt und verwalten die Internetverbindungen für den geschützten Bereich. Alle Verbindungen laufen
indirekt über den Proxy ab, er dient als Stellvertreter für die Hosts. Für einen guten
Schutz werden Firewallsysteme aus den unterschiedlichen Komponenten aufgebaut. ([9])
Eine Schwachstelle beim Einsatz von Firewalls ist der Anwender. Es sind umfangreiche
Konfigurationen nötig, um ein Netz gegen Angriffe zu sichern und gleichzeitig den regulären Netzwerkverkehr nicht einzuschränken. Besonders im Bereich der Privatanwender
gibt es keine Sicherheit, dass diese die Schutzmechanismen einsetzen. Unsichere Computer und Netze sind nicht nur Angriffsziele, sondern können von Angreifern auch für
ihre Zwecke ausgenutzt werden und als Ausgangspunkt für weitere Angriffen, wie die
Verbreitung von schädlicher Software und DDoS Attacken, dienen.
20
3 Global Positioning System
Das Global Positioning System (GPS) wird heutzutage in vielen Bereichen zur Positionsbestimmung und Navigation genutzt. So wird beispielsweise die Navigation in Seeund Luftfahrt, sowie im Auto durch GPS unterstützt. Grundlage zur Positionsbestimmung sind GPS-Satelliten in der Erdumlaufbahn, die stetig ihre aktuelle Position, beziehungsweise Positionsänderung und Uhrzeit ausstrahlen. Zur Positionsbestimmung genügt der Kontakt mit 3 Satelliten, handelsübliche GPS-Empfänger benötigen allerdings
die Signale von mindestens 4 Satelliten. Die aufbereiteten Informationen stellt der GPSEmpfänger über eine Schnittstelle im standardisierten Datenformat NMEA-0183 zur
Verfügung. Die ausgegebenen Informationen unterscheiden sich herstellerspezifisch, sollten aber einen Grundumfang bieten. Darin enthalten sind unter anderem die Uhrzeit,
die nördliche Breite, östliche Länge und die Geschwindigkeit. Zur Genauigkeit der Positionsbestimmung lässt sich sagen, dass in 90% der Messungen der Fehler geringer als
10m beträgt.
21
Teil II
Konzept
22
4 Anforderungen an das
Observermodul
In diesem Kapitel werden zunächst die allgemeinen Anforderungen an ein TCP Überwachungsmodul betrachtet. Unter Beachtung einiger Sicherheitsaspekte, sowie Bedingungen, die sich bei der Kommunikation über Ethernet ergeben, wird dann ein Konzept für
die Umsetzung diesen Moduls in VHDL erarbeitet.
Das Überwachungsmodul soll für jede TCP-Verbindung den Zustand überwachen und
nicht zugelassene TCP-Pakete filtern. Es ist somit ein zustandsbehaftetes Paketfilter und
beschränkt sich bei der Analyse auf die Netzwerk-, Internet- und Transportschicht des
TCP/IP-Referenzmodells. Da vom Aufbau bis zum Abbau der Verbinung unterschiedliche Paketarten zugelassen sind, muss ein Zustandsmodell entwickelt werden. Das in [12]
beschriebene Modell für eine TCP-Implementierung kann hierbei nicht übernommen
werden, da bei der Überwachung die Pakete beider Quellen verifiziert werden müssen.
Das Modul darf deshalb den Datenverkehr im Up- und Downstream nicht unabhängig
voneinander analysieren, da Pakete aus beiden Richtungen eine Zustandsänderung im
Modul hervorrufen können. Die reguläre Kommunikation über TCP und andere Protokolle darf dabei nicht behindert werden, es muss transparent für den Netzwerkverkehr
sein. Daraus ergeben sich Anforderungen an die Robustheit. Das Modul sollte in der
Lage sein so viele TCP-Verbindungen zu überwachen, wie es die vorhandene NetzinfraUpstream
H
O
S
T
1
Westen
Analyse
Downstream
Abbildung 4.1: Observer
23
Osten
H
O
S
T
2
4 Anforderungen an das Observermodul
struktur zulässt. Dabei darf es nicht abstürzen und muss gegen Angriffe geschützt sein.
Die Überwachung der TCP-Verbindungen kann nur gewährleistet werden, wenn keine
Pakete an dem Modul vorbei geleitet werden können. Dies ist notwendig, damit die Zustandsinformationen im Speicher konsistent mit dem Zustand der Verbindung bleiben,
keine korrekten Pakete verworfen werden und keine Angriffe unentdeckt bleiben.
24
5 Zustandsmodell zur
Verbindungsüberwachnung
Die TCP-Verbindung vom Verbindungsaufbau über den Datenaustausch bis zum Verbindungsabbau läuft bei jedem Host nach dem Modell einer Zustandmaschine ab. Bestimmte Ereignisse, eintreffende Pakete oder Befehle von der Anwendungsschicht, führen
jeweils in einen Folgezustand. Die Zustandsänderungen sind in dem Überwachungsmodul hingegen abhängig von den Paketen im Up- und Downstream, wobei es für die
Verifikation wichtig ist aus welcher Richtung die Pakete kommen. Wird beispielsweise
die Verbindung einseitig abgebaut, so können weiterhin Datenpakete aus der anderen
Richtung eintreffen. Pakete im Downstream kommen in der folgenden Betrachtung aus
dem Westen und Pakete im Upstream kommen aus dem Osten, wie es in Abbildung 4.1
veranschaulicht ist. Die im Folgenden erörterten Verbindungszustände werden mit den
Verbindungsdaten abgespeichert und stellen nicht die Zustände des Überwachungsmoduls dar.
5.1 Verbindungsaufbau
In Abbildung 5.1 ist das Zustandsmodell für den Verbindungsaufbau vereinfacht dargestellt und zeigt nur Ereignisse, die einen Zustandswechsel zur Folge haben. Beim ersten
Paket zum Aufbau einer TCP-Verbindung ist das SYN-Flag gesetzt. Der Verbindungsstatus ist dann, abhängig von der Richtung, wsyn_rcv oder esyn_rcv. Trifft nach Empfang
eines SYNs ein weiteres aus der entgegengesetzten Richtung ein, wird die Verbindung
synchron von beiden Seiten aus geöffnet und der Folgezustand ist sync_open. Nach dem
3-Wege-Handshake Verfahren müssen die Synchronisationspakete aus beiden Richtungen
bestätigt werden. Trifft eine Bestätigung aus dem Westen ein, so wird in den Zustand
eack_wait gewechselt und auf eine Bestätigung aus dem Osten gewartet. Durch die
letzte Bestätigung befindet sich die Verbindung aus Sicht des Überwachungsmoduls im
Zustand established. Das bedeutet nicht, dass die Verbindungsteilnehmer sich auch in
25
5 Zustandsmodell zur Verbindungsüberwachnung
esyn
no state
esyn_rcv
wsyn
wsyn
esyn
wsyn_rcv
sync_open
wsyn_ack
esyn_ack
wfin
efin
wsyn_ack, ack esyn_ack, ack
eack_wait
wack_wait
wrst
erst
esyn_ack
wfin
established
wsyn_ack
efin
erst
wrst
efin
wfin_rcv
wrst
wfin
wfin
wrst
efin
erst
wrst_rcv
efin_rcv
erst
erst_rcv
Abbildung 5.1: Zustandsmodell; Bereich Verbindungsaufbau
26
5 Zustandsmodell zur Verbindungsüberwachnung
diesem Zustand befinden, da die Pakete auf dem weiteren Weg zum Ziel verloren gehen können. Das ist wichtig für die Verifikation der Pakete, denn deshalb müssen im
Zustand established weiterhin Synchronisations- und Bestätigungspakete weitergeleitet
werden, um die TCP-Verbindung nicht zu behindern. Beim Verbindungsaufbau kann es
vorkommen, dass die Verbindung zurückgesetzt oder beendet wird. Das geschieht durch
den Versand von Paketen mit gesetztem RST oder FIN Flag. Daraufhin wird in die im
Zustandsdiagramm gezeigten Zustände gewechselt.
5.2 Datenversand
Befindet sich die Verbindung im Zustand established, so bewirken nur Pakete mit gesetztem FIN oder RST-Flag eine Zustandsänderung. Die Folgezustände sind dann wfin_rcv
bzw. efin_rcv oder wrst_rcv bzw. erst_rcv, und sind abhängig von der Richtung aus der
das Paket eingetroffen ist. Reguläre Datenkommunikation läuft nach dem in Abschnitt
?? beschriebenem Verfahren ab und hat keine Zustandsänderung zur Folge. Die Verbindungsdaten im Speicher werden dennoch aktualisiert, um die Verifikation der Sequenzund Bestätigungsnummern eintreffender Pakete vornehmen zu können.
5.3 Verbindungsabbau
Hat ein Host keine weiteren Daten zu versenden, so kann er den Verbindungsabbau mit
Versand eines FIN-Paketes einleiten. Die Richtung des FIN-Paketes muss beachtet werden, da der Verbindungsabbau einseitig möglich ist, und in dem Fall der Datenverkehr
in die andere Richtung weiter läuft. Trifft ein FIN Paket vom westlichen Host ein, so
wird in den Zustand wfin_rcv gewechselt. Analog gilt dies für ein FIN aus dem Osten
und dem Folgezustand efin_rcv. Nach Bestätigung des FINs (w-/elack) werden Daten
nur noch aus einer Richtung akzeptiert und im Zustand wfin_wait bzw. efin_wait auf
das FIN aus dem Westen bzw. Osten gewartet. Wird auch der Abbau der verbleibenden Richtung mit dem entsprechenden FIN eingeleitet, so muss dieses mit einem letzten
ACK-Paket bestätigt werden. Aus dem Zustand elack_wait oder wlack_wait wird dann
in den Zustand timed_wait gewechselt. Falls die letzte Bestätigung auf dem Weg zum
Host verloren geht und der andere Host eine Sendewiederholung für das FIN durchführt,
so wird das in diesem Zustand noch weitergeleitet. Da beide Hosts zu diesem Zeitpunkt
keine Daten mehr zu senden haben und alle Daten korrekt empfangen haben, werden die
Verbindungsdaten nach Ablauf eines Timers aus dem Speicher gelöscht. Der Fall eines
27
5 Zustandsmodell zur Verbindungsüberwachnung
wrst
efin_rcv
erst
established
efin
wfin
wfin
efin
wfin_rcv
sync_close
wlack
elack
wsyn_ack, ack esyn_ack, ack
wfin_wait
efin_wait
wrst
erst
erst
wfin
elack_wait
wrst
elack
wlack
timed_wait
wrst
efin
wlack_wait
wrst
erst
erst
wrst_rcv
erst_rcv
Abbildung 5.2: Zustandsmodell; Bereich Verbindungsabbau
28
5 Zustandsmodell zur Verbindungsüberwachnung
synchronen Verbindungsabbaus wird, wie in Bild 5.2 zu sehen, mit dem Übergangszustand sync_close abgearbeitet.
Der Verbindungsabbau kann auch durch RST-Pakete ausgelöst werden. In dem Fall
wird ein Handshake durchgeführt. Nach Verifikation des eintreffenden Resets wird in die
Zustände wrst_rcv oder erst_rcv gewechselt. Diese Zustände ähneln dem Zustand timed_wait, denn hier werden die Verbindungsdaten auch nach dem Timerablauf gelöscht.
Wenn ein oder beide Verbindungsteilnehmer ausfallen und das Modul die Verbindungsdaten nicht mehr aktualisiert, müssen die Verbindungsinformationen manuell aus dem
Speicher gelöscht werden. Für diesen Zweck muss ein konfigurierbarer Timer implementiert werden.
5.4 Benötigte Paketinformationen
Für die Analyse der Pakete und Verwaltung der Verbindungen werden Informationen
benötigt. Welche Paketinformationen ausgelesen werden müssen, wird in diesem Kapitel beschrieben. Hierbei wird sich nicht nur auf die aus den Grundlagen bekannten
Headerinformationen beschränkt, es werden zusätzlich GPS-Daten der Verbindungsteilnehmer bereitgestellt. Diese sind als Optionen im IP-Header enthalten (vgl. Abbildung
1.3). Durch die Benutzung dieser Informationen als ein zusätzliches Verifikationsmerkmal soll Angriffe durch IP-Spoofing verhindern. Die benötigten Informationen werden
in 2 Kategorien eingeteilt. Zum einen gibt es die Paketinformationen, die aus dem eintreffenden Paket ausgelesen werden müssen um das Paket zu verifizieren. Zum anderen
gibt es die Verbindungsinformationen mit dem aktuellen Status, die zur Verwaltung abgespeichert werden und sich aus den Paketinformationen des Westens und des Ostens
zusammensetzen. Die auzulesenden Informationen umfassen Headerbereiche der Internetund Transportschicht.
5.4.1 Informationen aus dem IP-Header
Aus dem IP-Header müssen die in Bild 5.3 gezeigten Informationen ausgelesen werden. Die Länge des gesamten Paketes wird benötigt, um spätere Berechnungen mit den
Sequenz- und Bestätigungsnummern durchführen zu können. Um die Länge der reinen
Nutzdaten zu erhalten muss dieser Wert um die IP- und TCP-Headerlänge erniedrigt
29
5 Zustandsmodell zur Verbindungsüberwachnung
31
24
Version
IHL
16
8
Type of Service
Packet Length
Identification
TTL
0
Flags
Protocol
Fragment-Offset
Header Checksum
Source IP Address
Destination IP Address
Options
Padding
Abbildung 5.3: Benötigte Informationen aus dem IP-Header
werden. Da eine TCP-Verbindung sich durch das Quadrupel aus IP-Adresse und Port
der Teilnehmer identifiziert, müssen hier die Quell- und Zieladresse des IP-Paketes ausgelesen werden. Als weiteres Identifikationsmerkmal sollen die GPS-Ortsinformationen
herangezogen werden. Die GPS-Daten der Quelle sind im Optionsteil des IP-Headers gespeichert. Wird ein Paket von Westen nach Osten geschickt, so sind die Daten des westlichen Hosts enthalten. Um diese Informationen auch vom anderen Host nutzen zu können,
muss auf ein Paket aus dem Osten gewartete werden. Die zur Verbindungsverwaltung
abzuspeichernden Informationen sind die IP-Adressen, sowie die GPS-Informationen der
Teilnehmer.
5.4.2 Informationen aus dem TCP-Header
31
24
16
Source Port
8
0
Destination Port
Sequence Number
Acknowledgement Number
Offset
Reserved
Flags
Window
Checksum
Urgent Pointer
Options
Padding
Data
Abbildung 5.4: Benötigte Informationen aus dem TCP-Header
Die im TCP-Header angegebenen Quell- und Zielportnummern sind Bestandteil der
benötigten Informationen für eine eindeutige Identifikation der TCP-Verbindung und
müssen deshalb ausgelesen und zur Verbindungsverwaltung abgespeichert werden. Die
Sequenz- und Bestätigungsnummern werden zur Paketverifikation benötigt, denn nur
Pakete mit Nummern in einem bestimmten Bereich können eine Veränderung der Verbindungsinformationen bewirken. Dieser Bereich ist durch das Fenstermanagement gege-
30
5 Zustandsmodell zur Verbindungsüberwachnung
ben, weshalb es wichtig ist die Fenstergröße aus dem TCP-Header auszulesen. Die wichtigsten Informationen zur Steuerung der TCP-Verbindung sind die TCP-Flags, die die
Grundlage für die Zustandsänderungen bilden aber nicht zur Verbindungsverwaltung abgespeichert werden müssen. Die Portnummern, die Sequenz- und Bestätigungsnummern,
sowie die Fenstergröße beider Verbindungsteilnehmer sind hingegen Bestandteil der abzuspeichernden Verbindungsdaten. Die auszulesenden Headerfelder sind in Abbildung
5.4 nochmal dargestellt.
31
6 Hardwarekonzipierung
Überwachungsmodul
Data_path_west_out
Data_path_logic
to_out valid
Data_path_east_in
Frame
next
info
uBuffer_stat
Up_Down_Arbiter
u_rcv
rdy
up_down
Mem_if_in
Protocol_check_logic
Memory
Mem_if_out
d_rcv
dBuffer_stat
next
Data_path_west_in
Frame
valid to_out
info
Data_path_logic
Data_path_east_out
Abbildung 6.1: Aufbau des Überwachungsmoduls, Schnittstellen zwischen den einzelnen
Modulen
Das Überwachungsmodul, mit seinen Ein- und Ausgängen im Datenpfad, wird in mehrere Komponenten zerlegt, die unterschiedliche Teilfunktionen realisieren. Diese Vorgehensweise hat den Vorteil, dass man einzelne Komponenten wiederverwenden oder gegen
optimiert Versionen mit derselben Funktionalität austauschen kann. Ein weiterer Vorteil
ist die schrittweise Verifikation der Komponenten, da man beim Testen von kleineren
Funktionseinheiten Fehler schneller findet und behebt.
Die Komponenten des Überwachungsmoduls sind in Abbildung 6.1 gezeigt und haben
die im Folgenden beschriebene Aufgaben. Die Datenpfadlogik extrahiert die benötigten
Informationen aus den Paketen und speichert diese bis sie an die Protokollüberwachungslogik weiter gegeben werden. Die Pakete selbst werden hier auch zwischengespeichert,
32
6 Hardwarekonzipierung
Data_path_logic
crit
next Frame info Frame_info_valid
To_protokoll_FSM
rcv
To_out
wr_en
data_in
wr_addr
InfoFIFO
rd_en
data_out
rd_addr
FrameInfo_FSM
Data_path_in
Push_frame
FSM
wr_en
data_in
wr_addr
DatenFIFO
rd_en
data_out
rd_addr
To_out_FSM
Data_path_out
Abbildung 6.2: Aufbau der Datenpfadlogik
bis sie entweder verworfen oder weitergeleitet werden. Die Protokollüberwachungslogik
verifiziert die Pakete anhand der bereitgestellten Paketinformationen und im Speicher
abgelegten Verbindungsinformationen und gibt den Versand- oder Löschauftrag an die
Datenpfadlogik weiter. Da ein einzelnes Modul den Up- und den Downstream überwacht, wird ein Arbitrierer benötigt, der die Protokollüberwachungslogik dem jeweiligen
Stream zuteilt. Durch Verknüpfung dieser Module über definierte Schnittstellen wird die
Gesamtfunktionalität des Überwachungsmoduls erreicht.
6.1 Datenpfadlogik
6.1.1 Schnittstellen der Datenpfadlogik zu anderen Modulen
Die Ein- und Ausgänge der Datenpfadlogik sind in der Tabelle 6.1 aufgeführt und werden im Folgenden nochmals erläutert. Die Schnittstellen des Überwachungsmoduls im
Datenpfad, über die die Pakete empfangen und versendet werden, sind direkt mit dem
Datenpfadmodul verbunden. Ein Datenpfadmodul besitzt nur einen Ein- und einen Ausgang für die Daten, da jeweils ein Modul im Up- und Downstream die Pakete aus dem
Westen bzw. dem Osten verarbeitet. Die Daten treffen byteweise mit zwei zusätzlichen
Steuerleitungen an dem Modul ein und werden in der gleichen Weise wieder verschickt.
Über weitere Schnittstellen kommuniziert das Modul mit dem Arbitrierer und der Protokollüberwachungslogik. Über eine einfache Leitung signalisiert die Datenpfadlogik dem
33
6 Hardwarekonzipierung
Port
Richtung
Aufgabe
clk
in
Taktsignaleingang
rst
in
asynchroner Reset
data_in
in
Eingangsdatenstrom
observer_next
in
Protokollüberwachung fordert Paketinformationen an
observer_send
in
verwerfen/versenden des Paketes
buffer_crit
out
meldet kritischen Bufferfüllstand an Arbitrierer
arbiter_rcv
out
meldet empfangenes Paket an Arbitrierer
data_out
out
Ausgangsdatenstrom
frame_info_out
out
Übergabe der Paketinformationen an die
Protokollüberwachung
frame_info_valid out
Handshake mit Protokollüberwachung
Tabelle 6.1: Schnittstellen der Datenpfadlogik
Arbitrierer den Empfang eines Paketes und über eine weitere das Erreichen eines kritischen Zwischenspeicherfüllstandes. Über ein einfaches Signal fordert die Protokollüberwachungslogik neue Paketinformationen an, die dann parallel über eine weitere Schnittstelle
übergeben und mit einer Steuerleitung als gültig signalisiert werden. Das Versenden oder
Verwerfen des Paketes wird über eine zwei Bit breite Schnittstelle initiiert.
6.1.2 Aufgaben und Konzept der Datenpfadlogik
Die Aufgabengebiete diesen Moduls umfassen das Auslesen der Paketinformationen, das
Zwischenspeichern der Pakete, die Bereitstellung der Paketinformationen, sowie das Versenden oder Verwerfen der Pakete. Da diese Aufgaben unabhängig voneinander ablaufen, werden in dem Modul mehrere Zustandsmaschinen eingesetzt. Für das Auslesen
der Paketinformationen sind zwei Zustandmaschinen zuständig, eine für den Bereich der
Netzwerkschicht und eine für den Bereich der Internet- und Transportschicht.
Wenn ein Paket eintrifft, beginnt die erste mit der Verarbeitung des MAC-Headers, wie
in Abbildung 6.3 gezeigt. Sie bearbeitet MPLS- und VLAN-Bereiche, entscheidet ob es
sich um ein IP-Paket handelt und ließt das erste Byte des IP-Headers aus, um der zweiten Zustandsmaschine die IP-Headerlänge bereitzustellen. Ein Paket ohne VLAN und
MPLS-Bereiche wird folgendermaßen abgearbeitet. Trifft ein Paket ein, wird zunächst
in den Zustand wait_type gewechselt und auf das erste Byte der Typbeschreibung gewartet. Stimmt das Byte mit der Beschreibung für IP überein, so wird im nächsten
34
6 Hardwarekonzipierung
data = 0x81
vlan_2nd
data = 0x88
wait_type
mpls_2nd
data = 0x00
sof = ‚1'
data = 0x08
mac_type_2nd
get_mpls_3rd
idle
data \= 0x00
wait_ihl
get_mpls_2nd
get_mpls_4th
get_mpls_1st
Abbildung 6.3: Zustandsmaschine zur Bearbeitung der Netzwerkschicht
Zustand mac_type_2nd das zweite Byte verglichen. Wenn das Protokoll der Internetschicht IP ist, wird im Zustand wait_ihl auf das erste Byte des IP-Headers gewartet und
die Headerlänge ausgelesen. Ergibt die Auswertung des Typfeldes, dass kein IP-Paket
im Datenbereich enthalten ist, so wechselt die Zustandsmaschine wieder nach idle.
Die zweite Zustandsmaschine beginnt mit der Verarbeitung, wenn die erste festgestellt hat, ob ein IP-Paket enthalten ist oder nicht. Enthält das eingehende Paket kein
IP-Paket, also auch keinen TCP-Bereich, so wird in den Zustand got_info gewechselt
und die Paketinformationen werden in einen Zwischenspeicher geschrieben. Ist in den
Nutzdaten ein IP-Paket enthalten, beginnt die Zustandsmaschine mit dem Auslesen der
Informationen aus dem IP-Header, wie in der Abbildung 6.4 durch den Wechsel in den
Zustand get_ip_information dargestellt. Die abgebildete Zustandsmaschine stellt den
Ablauf beim Auslesen der Pakete vereinfacht dar und enthält in den Zuständen weitere
Zustände zum Auslesen der Headerinformationen. Alle Zustände und Zustandsübergänge, mit der Zuordnung zur Abbildung, sind in Tabelle 6.2 aufgeführt.
Die wichtigsten Übergänge und Abhängigkeiten sind jedoch in der Abbildung zu sehen. Wenn das IP-Paket ein TCP-Segment im Nutzdatenbereich enthält, werden im
35
6 Hardwarekonzipierung
Zustand lt. Abbildung
idle
Zustand
idle
Ereignis
is IP
Folgezustand
wait_length
is not IP got_information
get_ip_information
wait_length
get_length2nd
wait_protocoll
isTCP
wait_ip
isICMP
wait_icmp
isOther
got_info
IHL=20
get_ports
IHL>20
get_ip_opt
wait_ip
get_src_ip2nd-4th
get_dst_ip1st-3rd
get_dst_ip4th
get_ip_opt
get_opt_len
wait_next_opt
get_gps
get_gps1st-8th
wait_end_ih
get_tcp_information
get_ports
get_src_p2nd
get_dst_p1st
get_dst_p2nd
get_seq_num1st-4th
get_ack_num1st-4th
tcp_offset
get_flags
get_window
get_window2nd
get_icmp_information
got_info
wait_icmp
wait_icmp_data
if IP
get_icmp
if not IP
got_info
get_icmp
got_info
wait_length
got_info
reset_info
idle
Tabelle 6.2: Datenpfadlogic, rcv info fsm
36
6 Hardwarekonzipierung
get_ip_information
isTCP
isICMP
isIP
isIP
get_tcp_information
noTCP
idle
get_icmp_information
noIP
noIP
got_info
Abbildung 6.4: Vereinfachte Zustandsmaschine: Auslesen der Paketinformationen
Zustand get_ip_information nacheinander die in Kapitel 5.4.1 erarbeiteten Informationen ausgelesen. Diese Entscheidung wird im Zustand wait_protocol getroffen, wo der
Protokolltyp des transportierten Paketes ausgelesen wird. Wenn die Typnummer mit
der für TCP übereinstimmt, werden zunächst die IPs, dann die IP-Optionen ausgelesen und vorhandene GPS-Informationen abgespeichert. Bei einem ICMP-Paket wird in
den Zustand get_icmp_information gewechselt, auf das Ende des IP-Headers gewartet
und die ICMP-Bereiche werden abgearbeitet. Ist die Ursache für die Internetkontrollnachricht ein IP-Paket und sind somit der IP-Header plus 64Bit des Originalpaketes im
Anhang enthalten, wird die neue Headerlänge ausgelesen und wieder in den Zustand
get_ip_information gewechselt. Beim Auslesen der Paket-Informationen aus dem Datenbereich des ICMP-Paketes muss man darauf achten, die Quell- und Zieladressen zu
vertauschen, da das Paket ursprünglich aus der anderen Richtung gekommen sein muss
und dies für die späteren Verifikation wichtig ist. Ist in den IP-Nutzdaten ein TCPPaket enthalten und das Ende des IP-Headers erreicht, wird mit dem Auslesen der in
Kapitel 5.4.2 beschriebenen Informationen fortgefahren. Nach Erhalt des zweiten Bytes
der Empfangfenstergröße im Zustand get_window2nd wechselt die Zustandsmaschine zu
got_info und schreibt die Paketinformationen in einen Zwischenspeicher.
Die Zustandsmaschine zum Zwischenspeichern der eintreffenden Pakete enthält zwei
Zustände, wie in dem Bild 6.5 gezeigt. Wenn die Steuerleitung sof den Anfang eines
Paketes kennzeichnet, beginnt die Zustandsmaschine das Paket byteweise in einem Zwischenspeicher abzulegen und wechselt von idle nach push_frame. Dort kopiert sie die
37
6 Hardwarekonzipierung
sof = 1
idle
error
push_frame
eof = 1
Abbildung 6.5: FSM: Datenpfadlogik, Zwischenspeichern der Pakete
observer_next = 1
idle
Info_wait
Push_info
Abbildung 6.6: FSM: Datenpfadlogik, Bereitstellen der Paketinformationen
eintreffenden Bytes so lange in den Zwischenspeicher, bis die Steuerleitung eof das Ende
des Paketes kennzeichnet, oder ein Fehler (error) auftritt. Die Speicherung der eintreffenden Pakete erfolgt nur, wenn im Zwischenspeicher noch Platz für ein Paket maximaler
Länge ist. Dadurch muss die Datenpfadlogik mit der Empfangssignalisierung an den
Arbitrierer nicht warten bis das gesamte Paket eingetroffen ist und die Protokollüberwachungslogik kann die Bearbeitung der Paketinformationen während des Empfangs der
Nutzdaten durchführen. Durch diese Vorgehensweise wird der Zwischenspeicher zwar
nicht komplett ausgelastet, allerdings wird dadurch die Verzögerung der Pakete im Überwachungsmodul geringer.
Wenn die Protokollüberwachungslogik neue Paketinformationen anfordert, so bearbeitet dies die Zustandsmaschine info_to_obeserver, deren Zustandsdiagramm in Abbildung 6.6 gezeigt ist. Zunächst werden die Paketinformationen im Zustand info_wait
aus dem Zwischenspeicher gelesen und danach im Zustand push_info an die Protokollüberwachungslogik übergeben. Nachdem die Gültigkeit der Daten mit einer zusätzlichen
Steuerleitung (info_valid) gekennzeichnet wurde, wechselt die Zustandsmaschine wieder
in den idle Modus.
Das Verwerfen oder Versenden von Paketen wird von der Protokollüberwachungslogik
38
6 Hardwarekonzipierung
Transmit_wait
Discard_wait
send
discard
idle
eof
eof
transmit
discard
Abbildung 6.7: FSM: Datenpfadlogik, Versenden/Verwerfen des Paketes
über die to_out Steuerleitungen initiiert und von der frame_output Zustandsmaschine
bearbeitet. Das Zustandsdiagramm ist in Abbildung 6.7 gezeigt und enthält zwei Richtungen der Abarbeitung, eine für das Versenden in Richtung transmit, die andere für das
Verwerfen der Pakete. In beiden Richtungen wird ein Paket aus dem Zwischenspeicher
gelesen, in den Zuständen wait_transmit und transmit an den Ausgang weitergeleitet
und in den Zuständen wait_discard und discard verworfen.
Die Zwischenspeicher für die Pakete und die Paketinformationen haben die Funktion eines FIFOs (first in first out), damit die Reihenfolge der Pakete im Stream sich
nicht verändert. Des Weiteren ist die Zuordnung der bearbeiteten Informationen zu den
entsprechenden Paketen durch die Nutzung des DatenFIFO und InfoFIFO, wie in Abbildung 6.2, gewährleistet, denn die ersten Informationen im InfoFIFO gehören zu dem
ersten Paket im DatenFIFO.
6.2 Up-Down-Arbitrierer
6.2.1 Schnittstellen des Arbitrierers zu anderen Modulen
Der Arbitrierer besitzt Schnittstellen zu den Modulen der Datenpfadlogik, sowie zur
Protokollüberwachungslogik. Je zwei Steuersignale von der Datenpfadlogik des Up- und
Downstreams informieren den Arbitrierer über den Empfang eines Paketes und den Zustand des Datenspeichers. Dadurch ist es möglich auf einen kritischen Datenspeicherfüllstand zu reagieren und den entsprechenden Stream bei der Arbitrierung zu bevorzugen.
39
6 Hardwarekonzipierung
Up_down_Arbiter
push
logic
uTcp_rcv
dTcp_rcv
counter
Up
down
fifo
rdy
logic,
algorithm
Up_down(1 downto 0)
uBufferfull
dBufferfull
Abbildung 6.8: Aufbau des Arbitrierers
Richtung
Port
Aufgabe
clk
in
Taktsignaleingang
rst
in
asynchroner Reset
uRcv
in
Paket im Upstream empfangen
dRcv
in
Paket im Downstream empfangen
uBufferfull
in
kritischer Bufferfüllstand im Upstream
dBufferfull
in
kritischer Bufferfüllstand im Downstream
observer_rdy
in
Bereitschaft der Protokollüberwachung
up_down
out
Bearbeitung des Up- oder Downstreams
Tabelle 6.3: Schnittstellen des Arbitrierers
Über eine Leitung signalisiert die Protokollüberwachungslogik, ob sie arbeitet oder bereit zur Bearbeitung eines neuen Paketes ist. Über einen zwei Bit breiten Ausgang weist
der Arbitrierer die Bearbeitung des Up- oder Downstreams an. Eine Übersicht der Ports,
deren Richtung und Bedeutung gibt die Tabelle 6.3.
6.2.2 Aufgabe und Konzept des Arbitrierers
Das Überwachungsmodul benötigt einen Arbitrierer, da die Protokollüberwachungslogik
die Paketeinformationen des Up- und Downstream bearbeitet, die eintreffenden Pakete
konkurrieren um Bearbeitungszeit. Die Aufgabe des Arbitrierers liegt darin die Bearbeitungsreihenfolge der Pakete so zu wählen, dass die Zwischenspeicher in den Daten-
40
6 Hardwarekonzipierung
observer_rdy = 1
paketspending > 0
idle
wait_busy
observer_rdy = 0
Abbildung 6.9: FSM: Arbitrierer
pfadlogiken nicht überlaufen und Pakete schon am Eingang verworfen werden müssen.
Das Ziel ist eine schnelle Bearbeitung der Pakete, um die Verzögerung zu minimieren.
Der Up- und der Downstream sind in diesem Modul gleichberechtigt und es wird keine
Richtung bevorzugt verarbeitet. Deshalb arbeitet der Arbitrierer nach dem Prinzip first
come first serve, wonach sich die Bearbeitung der Pakete nach der Reihenfolge ihres Eintreffens richtet, also die Pakete, die das Modul zuerst erreichen auch zuerst bearbeitet
werden. Sollte der Füllstand des Zwischenspeichers in einem der Datenpfadmodule einen
kritischen Wert erreichen, weicht der Arbitrierer von dem Prinzip ab und priorisiert Pakete aus dem kritischen Stream höher. Wird vorausgesetzt, dass die Pakete byteweise
mit jedem Takt eintreffen und die Mindestlänge der Pakete 60 Byte beträgt, so treffen
Paketinformationen in einem Stream mit einer Rate von 1/60 Takte ein. Da Up- und
Downstream bearbeitet werden müssen, beträgt die maximale zulässige Bearbeitungsdauer pro Paket 30 Takte, damit ein Speicherüberlauf auszuschließen ist.
Der Arbitrierer verwaltet Informationen über die Anzahl der Pakete, die noch bearbeitet werden müssen und über die Reihenfolge in der die Pakete an dem Modul eintreffen.
Zur Speicherung der Reihenfolge benutzt der Arbitrierer einen FIFO, in den eine Eins
geschrieben wird, wenn ein Paket im Upstream eintrifft und eine Null für ein Paket im
Downstream. Gleichzeitig erhöht er jeweils einen Zähler für Pakete des Up- bzw. Downstreams. Die Arbitrierung erfolgt nach dem folgenden Ablauf und ist in Abbildung 6.10
gezeigt. Wenn die Protokollüberwachungslogik bereit ist und zur Verarbeitung ausstehende Elemente im FIFO vorhanden sind, nimmt der Arbitrierer das erste aus dem
FIFO, legt die entsprechenden Signale am Ausgang an, erniedrigt den jeweiligen Zähler
und wechselt in den Zustand wait_busy (s.Abbildung 6.9). Der Arbitrierer wechselt wieder in den Zustand idle, sobal die Protokollüberwachungslogik den Bearbeitungsbeginn
signalisiert. Wenn der Speicherfüllstand einer Datenpfadlogik kritisch und die Protokollüberwachungslogik bereit zur Bearbeitung ist, wird ein Paket des entsprechenden
Streams in Auftrag gegeben. Voraussetzung dafür ist, dass noch zu bearbeitende Informationen für den Stream vorhanden sind, der entsprechende Zähler also nicht Null ist.
41
6 Hardwarekonzipierung
false
Arbiter_rdy
&counter>0
true
upstream
F(buffercrit)
false
downstream
false
Ucounter > 0
Up_down = down
Dcounter=Dcounter-1
true
false
Dcounter > 0
Up_down = up
Ucounter=Ucounter-1
true
Up_down = down
Dcounter=Dcounter-1
Up_down = Read(FIFO)
Counter = counter-1
Arbiter_rdy
true
Abbildung 6.10: Ablauf der Arbitrierung
Wenn ein Paket außer der Reihe bearbeitet wird, also nicht dem ersten Element im FIFO
entspricht, muss das Element später verworfen werden, wenn es an der Reihe wäre. Für
diesen Zweck werden zwei zusätzliche Zähler für die zu verwerfenden Pakete benötigt,
um die Reihenfolge und Anzahl mit den Paketen in den Datenpfadlogiken konsistent zu
halten.
6.3 Protokollüberwachungslogik
6.3.1 Schnittstellen der Protokollüberwachungslogik zu anderen
Modulen
Die Protokollüberwachungslogik ist das Kernelement des TCP-Überwachungsmoduls
und besitzt die in Tabelle 6.4 aufgeführten Schnittstellen zu allen weiteren Modulen. Sie
signalisiert dem Arbiter die Bereitschaft zur Bearbeitung eines Streams über eine Signal-
42
6 Hardwarekonzipierung
Port
Richtung
Aufgabe
clk
in
Taktsignaleingang
rst
in
asynchroner Reset
uframe_info
in
Paketinformationen Upstream
uframe_info_v
in
Handshake Upstream
dframe_info
in
Paketinformationen Downstream
dframe_info_v
in
Handshake Downstream
up_down
in
Anweisung vom Arbitrierer
mem_in_access_type
in
durchgeführter Zugriff auf Speicher
mem_in_key
in
Schlüssel zu den ausgegebenen Daten
mem_in_data
in
Daten
mem_in_dv
in
Handshake
mem_data_exists
in
Daten enthalten oder nicht
mem_ack_in
in
Handshake
unext
out
Anfordern von Informationen vom Upstream
usend
out
Versenden oder Verwerfen von Paketen
dnext
out
Anfordern von Informationen vom Downstream
dsend
out
Versenden oder Verwerfen
to_arbiter_rdy
out
signalisiere Bereitschaft
mem_out_access_type
out
Speicherzugriffstyp
mem_out_key
out
Schlüssel zu den Daten
mem_out_data
out
Daten
mem_out_dv
out
Handshake
mem_ack_out
out
Handshake
Tabelle 6.4: Schnittstellen der Protokollüberwachungslogik
43
6 Hardwarekonzipierung
leitung und erhält von ihm Informationen darüber, welcher Stream bearbeitet werden
soll. Zu den Datenpfadlogiken sind jeweils zwei Ausgangssignale vorhanden, über die
neue Paketinformationen angefordert werden und nach der Bearbeitung das Versenden
oder Verwerfen des Paketes eingeleitet wird. Es sind jeweils Eingänge zum Übernehmen
der Paketinformationen vom Up- bzw. Downstream vorgesehen. Zum Abspeichern der
Verbindungsinformationen besitzt die Überwachungslogik Schnittstellen zu dem Memorymodul. Über Accessleitungen wird die Zugriffsart auf den Speicher gesteuert, und mit
dem Schlüssel (key) ein bestimmter Datensatz angesprochen. Nach Anlegen der Daten
an den Datenleitungen wird die Gültigkeit von Zugriffstyp, Schlüssel und Daten über
eine Datavalidleitung signalisiert und vom Speichermodul über die ack-Leitung bestätigt. Daten vom Speicher erhält das Modul über die Eingänge Access, Key, Data und
Datavalid und quittiert den Empfang über eine weitere ack-Leitung. Bei einem Lesezugriff auf den Speicher signalisiert der über dataexists, ob ein entsprechender Datensatz
vorhanden ist oder nicht.
6.3.2 Aufgabe und Konzept der Protokollüberwachungslogik
Dieser Bereich des Überwachungsmoduls wertet die Paketinformationen aus und entscheidet, unter Verwendung der Verbindungsinformationen, über den weiteren Weg der
Pakete. Es werden nur TCP Pakete und ICMP Pakete, die durch ein TCP Paket ausgelöst wurden, kontrolliert, alle anderen werden ohne Kontrolle weiter gesendet. Die
Auswertung der Paketinformationen erfolgt in zwei Schritten, nach dem Zustandsmodell
in Abbildung 6.11, wobei entweder der Weg für die Bearbeitung des Upstream oder der
Weg für die Bearbeitung des Downstream gewählt wird. Das Modul wartet im Zustand
idle, solange es nicht durch den Arbitrierer zur Bearbeitung angewiesen wird. Trifft dieses
Ereignis ein, fordert die Protokollüberwachungslogik neue Paketinformationen von der
Datenpfadlogik des Up- bzw. Downstream an und wechselt in den Zustand uwait_info
bzw. dwait_info.
In diesem Zustand wartet das Modul bis gültige Paketinformationen an den Eingängen anliegen und beginnt daraufhin mit Tests auf Korrektheit, die schon anhand der
Paketinformationen durchgeführt werden können. Die erste Überprüfung bezieht sich
auf die IP-Adressen und verhindert Landattacken. Wenn die Quell-IP gleich der Ziel-IP
ist, signalisiert das Modul der Datenpfadlogik, dass das Paket verworfen werden soll und
wechselt zurück in den Zustand idle. Für den zweiten Test ist es notwendig, dass das
44
6 Hardwarekonzipierung
uwait_info
dwait_info
Updown = 11
Updown = 10
error
isTCP = true
error
idle
uwait_connection_info
isTCP = true
dwait_connection_info
Abbildung 6.11: FSM: Protokollüberwachungslogik
Modul Informationen über den IP-Bereich im Osten besitzt. Die Quell-IPs der Pakete
im Upstream müssen und die Quell-IPs der Pakete im Downstream dürfen nicht in dem
angegebenen Bereich liegen, damit sie weiter verarbeitet werden. Pakete mit falschen
Quell-IPs weisen auf einen Angriff hin, werden verworfen und das Modul wechselt wieder in den idle Zustand. Wenn das Paket diese beiden Tests besteht, wird eine Anfrage
an den Speicher gestartet und in den nächsten Zustand gewechselt. Die Überprüfung
der IP-Adressen ist in dem Funktionsdiagramm 6.12 zur Verifikation der Pakete zum
Entscheidungspunkt fit IP-Range zusammengefasst.
Als Schlüssel für die Speicheranfrage dient das Quadrupel aus IPs und Ports, da
dieses die TCP-Verbindung eindeutig identifiziert. Für die Verwaltung der Verbindungen
wird eine einheitliche Reihenfolge der Werte gewählt, um die Generierung von zwei
Schlüsseln für dieselbe Verbindung zu verhindern. Der Schlüssel wird einheitlich wie
in Abbildung 6.13 generiert. Dementsprechend wird bei der Schlüsselgenerierung für
die unterschiedlichen Streamrichtungen Quell- und Zieladressen, sowie Ports gewählt
werden.
In den Zuständen u- und dwait_connectioninfo wartet die Protokollüberwachungslogik
zunächst auf eine Antwort vom Speicher und überprüft danach die Paketinformationen.
Signalisiert der Speicher, dass zu dem angegebenen Schlüssel keine Daten existieren,
besteht keine entsprechende TCP-Verbindung. In den Paketinformationen werden daraufhin die Flags überprüft. Wenn das Paket ein SYN-Paket zum Verbindungsaufbau
ist, werden aus den Paketinformationen die bisher möglichen Verbindungsinformationen
gewonnen und die GPS-Daten, die Sequenznummer, sowie die Empfangsfenstergröße
des anderen Verbindungsteilnehmers mit Null initialisiert. Die Verbindungsdaten wer-
45
6 Hardwarekonzipierung
true
true
fit IP-Range
isTCP
false
send
false
true
true
dataexists
isICMP
false
isICMP
false
false
true
true
correctGPS
send
Case(connection_state)
Case(flags)
check
false
Flags = SYN
true
false
Connectioninfo = f(paketinfo)
Mem_write
discard
discard
passCheck
false
true
send
discard
Abbildung 6.12: Funktionsdiagramm: Überprüfung der Pakete
a)
b)
c)
95
63
West-IP
95
47
West-Port
63
Quell-IP
95
47
Quell-Port
15
47
Ziel-Port
0
Ost-Port
Ziel-IP
63
Ziel-IP
15
Ost-IP
0
Ziel-Port
15
Quell-IP
0
Quell-Port
Abbildung 6.13: a) allgemeiner Schlüssel zur Verbindungsidentifizierung b) Schlüssel für
Paket aus dem Westen c) Schlüssel für Paket aus dem Osten
46
6 Hardwarekonzipierung
seq_una
schon bestätigt
seq_next
noch nicht bestätigt
ack_num
seq_una + rcv_window
als nächstes erwartet
nicht erlaubt
seq_num
Abbildung 6.14: Aufteilung des Sequenznummernbereiches
den dann zu Schlüssel und Datenbereich geteilt und ein Schreibzugriff auf den Speicher
durchgeführt. Wenn das Paket kein SYN-Paket ist, wird der Datenpfadlogik signalisiert
es zu verwerfen.
Wenn Daten zu dem Schlüssel im Speicher vorhanden sind, besteht bereits eine TCPVerbindung und die Protokollüberwachungslogik übernimmt die Verbindungsdaten vom
Speicher. Beziehen sich die Paketinformationen auf ein ICMP-Paket, so werden die GPSDaten des Ziels mit den aktuell ausgelesenen GPS-Daten verglichen. Dies geschieht bei
ICMP-Paketen auf diese Weise, da die ausgelesenen Paketinformationen sich auf das
Originalpaket beziehen, das die ICMP-Nachricht auslöste und aus der entgegengesetzten Richtung kam. Sind die GPS-Daten nicht korrekt, wird das ICMP-Paket verworfen.
Die Überprüfung von TCP-Paketen teilt sich in mehrere Fälle auf und ist abhängig vom
Status der Verbindung und den Flags der aktuellen Paketinformationen, da in unterschiedlichen Verbindungsstadien unterschiedliche Pakete zugelassen sind, wobei Pakete
mit falschen GPS-Informationen immer verworfen werden. Pakete zum Versand der Daten und deren Bestätigung werden weiter geleitet, wenn die GPS-Informationen übereinstimmen, jedoch bewirkt nur eine Untermenge dieser Pakete eine Aktualisierung der Verbindungsinformationen. Diese Untermenge ergibt sich aus Paketen, die die im nächsten
Kapitel beschriebenen Sequenz- und Bestätigungsnummerntests bestehen. FIN-Pakete
hingegen werden nur weiter geleitet, wenn sie alle Tests bestehen.
Überprüfung der Sequenz- und Bestätigungsnummern
Da ein Teilnehmer einer TCP-Verbindung nur Pakete mit gültiger Sequenz- und Bestätigungsnummer akzeptiert darf auch nicht jedes Paket eine Aktualisierung der Verbindungsdaten im Überwachungsmodul auslösen. Deshalb verwaltet das Modul zwei Sequenznummernbereiche in den Verbindungsinformationen, jeweils einen für jede Richtung.
47
6 Hardwarekonzipierung
Wie in Abbildung 6.14 dargestellt, wird ein Sequenznummernbereich in vier Bereiche
unterteilt, die durch drei Zeiger begrenzt werden. Das aktuelle Sendefenster ergibt sich
aus den Bereichen noch nicht bestätigt und als nächstes erwartet. Der Zeiger seq_una
zeigt dabei auf die erste noch nicht durch den Empfänger bestätigte Sequenznummer
und begrenzt das Fenster nach unten hin. Der Zeiger seq_una + rcv_window zeigt auf
die letzte Sequenznummer im Fenster, wobei rcv_window die Empfangsfenstergröße des
Empfängers ist. Der Zeiger seq_next zeigt auf die als nächstes erwartete Sequenznummer
des Senders. Die Zeiger zur Verwaltung des Sequenznummernbereiches für eine Richtung
sind also abhängig von beiden Verbindungsteilnehmern, von der ersten noch nicht bestätigten Sequenznummer und der Empfangsfenstergröße des einen Hosts, sowie von der
als nächstes erwarteten Sequenznummer des anderen.
Die Aktualisierung des seq_una Zeigers hat eine Verschiebung des Sendefensters und
der akzeptierten Sequenznummern zur Folge. Damit dieser Zeiger aktualisiert wird, muss
die Sequenznummer des aktuellen Paketes (seq_num) im Bereich der als nächstes erwarteten sein und die Bestätigungsnummer (ack_num) im Bereich der noch nicht bestätigten. Das ist in der Abbildung noch einmal mit den gleichnamigen Zeigern verdeutlicht.
Pakete mit kleineren Sequenznummern als seq_next können keine neuen Verbindungsinformationen enthalten, weil die Sequenznummern fortlaufend gewählt werden und solche
Pakete somit älter sind. Pakete mit Bestätigungsnummern größer als seq_next würden
etwas bestätigen, was noch nicht versendet wurde und müssen als Fehler angesehen werden. Bei den Berechnungen für die Nummernüberprüfung muss darauf geachtet werden,
dass der Sequenznummernbereich kontinuierlich durchlaufen wird und danach wieder
von Null begonnen wird. Deshalb werden diese Berechnungen zu Modulo 232 durchgeführt. Für die Überprüfung der Nummern eines Paketes aus dem Osten müssen folgende
Gleichungen erfüllt werden. Die Sequenznummer seq_num des aktuellen Paketes liegt
im akzeptierten Bereich, wenn die Gleichung 6.1 und die Bestätigungsnummer ack_num
liegt im akzeptierten Bereich, wenn die Gleichung 6.2 erfüllt ist.
(seq_num−eseq_next) mod 232 ≤ (eseq_una+wwindow−eseq_next) mod 232 (6.1)
(ack_num − wseq_una) mod 232 ≤ (wseq_next − wseq_una) mod 232
(6.2)
In einigen Verbindungsstadien müssen die Sequenz oder Bestätigungsnummern nicht
nur in einem bestimmten Bereich liegen, sondern genaue Werte annehmen, um eine
Aktualisierung der Verbindungsinformationen zu bewirken. Befindet sich die Verbindung
im Zustand e- oder wsyn_rcv, so muss die Bestätigungsnummer eines Paketes aus der
48
6 Hardwarekonzipierung
anderen Richtung das Syn bestätigen. Empfängt das Modul ein korrektes FIN-Paket
zum Abbau der Verbindung, muss im folgenden Verbindungszustand e- oder wfin_rcv
überprüft werden, ob eine Bestätigung das FIN oder nur vorherige Datenpakete bestätigt.
In diesen beiden Fällen muss die Bestätigungsnummer folgender Gleichung genügen.
ack_num = seq_next
(6.3)
Wenn das Paket die Sequenz- und Bestätigungsnummerntest bestanden hat, wird der
Zeiger seq_una auf den Wert der aktuellen Bestätigungsnummer ack_num gesetzt.
seq_una = ack_num
(6.4)
Die Aktualisierung von seq_next ist abhängig von zwei Werten des Paketes. Zum einen
von der Sequenznummer seq_num und zum anderen von der Größe der Nutzdaten im
TCP-Paket, da die Byte der TCP-Daten fortlaufend nummeriert sind. Für die Aktualisierung von seq_next ergibt sich somit die Gleichung 6.5.
seq_next = seq_num + length
(6.5)
6.4 Speicherverwaltung
Das Modul zur Speicherverwaltung übernimmt die Aufgaben der Suche eines Eintrags,
das Speichern neuer Einträge und das Löschen von Einträgen. Des Weiteren wird in dem
Modul ein Algorithmus zur Alterung integriert, damit Einträge, die keine Aktualisierung
mehr erfahren, gelöscht werden. Die Verwendung eines zusätzlichen Moduls für diese Aufgaben hat den Vorteil, dass die Protokollüberwachungslogik andere Aufgaben während
der Speicherverwaltung abarbeiten kann. Ein Eintrag umfasst die in Abbildung 6.15 gezeigten Informationen und setzt sich aus den in Kapitel 5.4 erarbeiteten Headerbereichen
zusammen.
6.4.1 Die Wahl des Suchverfahrens
Bei der Datenverwaltung haben Sortier- und Suchalgorithmen ([14] eine große Bedeutung, da die Laufzeit für die Suche in den Daten bei zunehmender Datenmenge zunimmt.
Diese Zunahme ist abhängig von dem verwendeten Algorithmus und kann linear oder
auch logarithmisch sein. Bei der Speicherverwaltung sind nur die Suchverfahren von Bedeutung, da ein neues Element zwar einsortiert wird, der Algorithmus dafür aber auf der
49
6 Hardwarekonzipierung
31
24
16
8
0
key
wIP
wPort
eIP...
...eIP
ePort
wGPS
eGPS
data
wwindow
ewindow
Wseq_next
Eseq_next
Wseq_una
Eseq_una
Conn_state
T
Abbildung 6.15: Inhalt der Verbindungsinformationen
Suche der richtigen Stelle basiert. Sortierverfahren hingegen beschäftigen sich mit der
Sortierung von vorhandenen Mengen. Damit man ein Suchverfahren erfolgreich anwenden kann, muss ein eindeutiger Suchschlüssel definiert werden. Bei der Verwaltung von
TCP-Verbindungen wird dafür das Quadrupel aus den IP-Adressen und Portnummern
der Verbindungsteilnehmer gewählt, da das die eindeutige Kennung der TCP-Verbindung
ist. Im Folgenden werden zwei Suchverfahren im Hinblick auf die Verwendung zur Speicherverwaltung aufgezeigt.
Sequentielle Suche
Die Datensätze werden bei diesem Verfahren in einem Feld organisiert, wobei keine sortierte Menge vorhanden sein muss und neue Elemente an das Ende geschrieben werden.
Das Abspeichern benötigt zunächst nur ein Zugriff auf den Speicher, da die Adresse des
letzten Elementes vorhanden ist. Da keine Einträge mit demselben Schlüssel im Speicher
vorhanden sein dürfen, muss vor dem Abspeichern die vorhandene Menge durchsucht werden. Die Suche ist bei diesem Verfahren allerdings linear von der Anzahl der Elemente
abhängig. Eine erfolglose Suche, wie es bei Einfügen eines neuen Elementes der Fall ist,
benötigt bei N Elementen N +1 Vergleiche, da jedes Element sequenziell überprüft wird.
Die erfolgreiche Suche nach einem Eintrag erfordert im Mittel ungefähr N/2 Vergleiche.
Summiert man nun die Laufzeiten für den Ablauf bei der Protokollüberprüfung, erhält man folgende Ergebnisse. Zunächst erhält der Speicher eine Anfrage nach einem
50
6 Hardwarekonzipierung
1
a)
2
1
3
2
4
5
5
9
6
11
7
15
8
22
9
29
10
33
11
44
1
b)
1
2
5
9
11
15
22
29
12
56
67
2
33
44
68
89
95
123
134
155
89
95
123
134
155
3
56
67
68
4
Abbildung 6.16: Vergleich von a) sequentieller Suche und b) binärer Suche
Element, danach soll das Element abgespeichert werden. Die Summe der Laufzeiten beträgt für diesen Vorgang N/2 + N/2 = N . Wird eine neue TCP-Verbindung aufgebaut,
erhöht sich die Laufzeit sogar auf ungefähr N + N = 2N . Diese Laufzeiten können noch
halbiert werden, wenn das Speichermodul so realisiert ist, dass es die gefundene Adresse nach einem Lesevorgang zwischenspeichert und so beim Schreiben keine neue Suche
durchführen muss.
Binäre Suche
Dieses Suchverfahren arbeitet nach dem Prinzip Teile und Herrsche und ist nur anwendbar auf eine sortierte Menge. Man vergleicht dabei den Suchschlüssel mit dem mittleren
Element der Menge und sucht in der Teilmenge weiter, in der das Element erwartet wird.
Von dieser Teilmenge nimmt man wieder das mittlere Element, vergleicht es mit dem
Suchschlüssel und fährt solange fort, bis man das Element gefunden hat. Die Suche nach
einem Element erfordert mit diesem Verfahren maximal log2 n + 1 Vergleiche. Dabei ist
es nicht von Bedeutung, ob eine erfolglose oder erfolgreiche Suche durchgeführt wird.
Die Summe der Laufzeiten für eine Folge von Speicherzugriffen bei der Protokollüberprüfung ergibt folgende Ergebnisse. Bei einer existierenden und einer neuen Verbindung
sind die Ergebnisse mit diesem Suchverfahren gleich: (log2 n +1)+(log2 n +1). Wenn das
Speichermodul die Methode der Adresszwischenspeicherung nutzt, wird auch in diesem
Fall die Laufzeit halbiert.
Der Unterschied und der Ablauf der beiden Suchverfahren ist in Abbildung 6.16 noch
einmal gezeigt. In dem Beispiel wird das Element mit dem Wert 67 gesucht. Für diesen
Vorgang benötigt man mit der sequentiellen Suche 12 Vergleiche und mit der binären
Suche nur 4.
51
6 Hardwarekonzipierung
a)
1
2
5
9
15
33
56
67
68
89
95
123
23
1
2
3
4
5
6
7
8
b)
1
2
5
9
15
33
56
67
68
89
95
123
c)
1
2
5
9
15
23
33
56
67
68
89
95
123
Abbildung 6.17: Einfügen eines Elementes in den Speicher1: a) Ausgangszustand b) Einfügevorgang c) Endzustand
6.4.2 Realisierung des Speichers
In dem Modul wird wegen den Geschwindigkeitsvorteilen die Binäre Suche gewählt, deren
Vorgang im vorangegangenem Kapitel erläutert wurde. Hier sollen nun die Funktionen
zum Einfügen und Löschen näher betrachtet werden. In Hardware wird die sortierte Liste
als Array von Informationselementen dargestellt. Beim Einfügen eines neuen Elementes
zwischen zwei vorhandenen Elementen muss dieser Platz zunächst freigegeben werden,
indem alle folgenden Elemente nach hinten verschoben werden. In Abbildung 6.17 ist
dies durch Einfügen der Zahl 23 dargestellt. Die Dauer für das Einfügen eines Elementes
entspricht also der Summe aus Zeit für die Suche und Aufrücken der folgenden Elemente
(Gleichung 6.6).
Dauer = Suche + Aufrücken der folgenden Elemente
(6.6)
Das Löschen eines Elementes ist dem Ablauf des Einfügens ähnlich. Ein Element wird
gelöscht indem alle folgende Elemente nach vorne verschoben werden, wie in Abbildung
6.18 durch Löschen der 33 gezeigt.
Nimmt man für die Schiebevorgänge im Mittel eine Anzahl an Speicherzugriffen von
N/2 an, so ergibt sich Gleichung 6.7 für die Gesamtanzahl G an Speicherzugriffen bei
Einfügen oder Löschen eines Elementes in einer Menge von N Elementen.
G = log2 n +
N
2
(6.7)
6.4.3 Alterungsalgorithmus
Ein Alterungsalgorithmus wird in dem Überwachungsmodul integriert, damit die Informationen von inaktiven TCP-Verbindungen aus dem Speicher gelöscht werden, um Res-
52
6 Hardwarekonzipierung
a)
1
2
5
9
15
33
56
1
67
2
68
3
89
4
95
5
123
6
b)
1
2
5
9
15
33
56
67
68
89
95
c)
1
2
5
9
15
56
67
68
89
95
123
123
Abbildung 6.18: Löschen eines Elementes aus dem Speicher1: a) Ausgangszustand b)
Löschvorgang c) Endzustand
sourcen zu sparen. Die Protokollüberwachungslogik verwaltet zwar die Verbindungen,
greift aber indirekt über einen Schlüssel auf den Speicher zu und hat keine Kenntnis
darüber, welche Verbindungen abgespeichert sind. Ohne Paketinformationen ist kein
Schlüssel für die Anfrage vorhanden und die Protokollüberwachung müsste sequentiell
alle Schlüssel testen, auch wenn dazu keine Informationen im Speicher vorhanden sind.
Deshalb wird der Alterungsalgorithmus, das Timeout der Verbindung, in dem Speichermodul integriert. Dieses hat direkten Zugriff auf die Einträge und überprüft diese periodisch auf Aktualität.
Dafür wird den Verbindungsinformationen ein Zustandsbit hinzugefügt, das die Protokollüberwachungslogik bei einem Schreibzugriff auf Eins setzt. Das Speichermodul überprüft nach Ablauf eines konfigurierbaren Timers jeden Speichereintrag nach diesem Bit.
Wenn das Bit den Wert Eins besitzt, wird es auf Null gesetzt. Ist das Bit in einem
der Einträge gleich Null, dann bedeutet dies, dass der Speichereintrag seit dem letzten
Timerablauf nicht aktualisiert wurde und wird gelöscht.
53
6 Hardwarekonzipierung
timer = 0
false
timer = timer-1
true
read(addr)
addr = addr+1
true
1
status_bit
write(0, addr)
0
delete(addr)
false
addr_max
Abbildung 6.19: Alterungsalgorithmus im Speichermodul
54
Teil III
Realisierung und Verifikation
55
7 Realisierung in VHDL
7.1 Zwei Prozess Methode
r
rin
Combinational
Process
Seqential
Process
r = rin
rin = f(r,in)
IN
registered, unregistered OUT
clk
rst
Abbildung 7.1: Prinzip der 2-Prozess Methode
Die Module des Überwachungsmoduls werden nach der 2-Prozess Methode entwickelt
[4]. Diese Methode des VHDL Entwurfes bietet einige Vorteile gegenüber dem traditionellen Entwurf. Beim traditionellen Entwurf existieren oft viele parallele Anweisungen,
Prozesse und Signale. Dadurch ist der realisierte Algorithmus oder die realisierte Funktionalität schwer zu erkennen und die Fehlersuche im Design wird erschwert. Durch die
parallelen Anweisungen besteht die erhöhte Gefahr der ungewollten Generierung von
Latches oder Mehrfachtreibern.
Wie in Abbildung 7.1 enthält ein Modul nach der 2-Prozess Methode nur zwei Prozesse mit übersichtlicher Funktionalität. Der getaktete sequentielle Prozess ist für den
Reset und die Registeraktualisierung (r=rin) zuständig. Der kombinatorische Prozess
enthält die gesamte Kombinatorik der Entität und treibt die abgetakteten (registered)
und kombinatorischen (unregistered) Ausgänge. Alle benötigten Register werden zu einem record zusammengefasst und werden im Design mit den zwei lokalen Signalen r und
56
7 Realisierung in VHDL
rin dargestellt. Dies hat den Vorteil, dass später neue Register leicht hinzugefügt oder
Änderungen vorgenommen werden können. Das Signal r stellt den aktuellen Zustand
dar und rin den neuen Zustand. Die Berechnung von rin wird mit Hilfe einer Variable
v im kombinatorischen Prozess vorgenommen, wobei rin vom aktuellen Zustand und
den Eingängen abhängt: rin=f(r,in). Zu Beginn des Prozesses werden der Variablen die
aktuellen Registerwerte zugewiesen. In den darauf folgenden sequentiellen Anweisungen
dürfen die neu berechneten Registerwerte zunächst nur der Variablen v zugewiesen werden und zum Ende des Prozesses werden dem Signal rin die neuen Registerwerte von
v zugewiesen. Den abgetakteten Ausgängen werden die aktuellen Registerinhalte von r
zugewiesen, wodurch Latches und Mehrfachtreiber ausgeschlossen werden.
7.2 Typdefinition und Informationsübergänge
Ein weiterer Schritt zu einem gut lesbaren und verständlichen Quellcode ist die Definition von gemeinsamen Typen, gerade im Bereich der Schnittstellen zwischen den
einzelnen Modulen. Dies wird bei den ausgelesenen Paketinformationen angewendet, da
dort mehrere Bereiche der Pakete zusammen von der Datenpfadlogik an die Protokollüberwachungslogik übergeben werden müssen. Die gesamten Informationen werden zu
einem record, mit folgendem Inhalt, zusammengefasst:
type info_type is record
isTCP
: boolean;
isICMP
: boolean;
isGPS
: boolean;
src_ip
: std_logic_vector(31 downto 0);
dst_ip
: std_logic_vector(31 downto 0);
gps_info
: std_logic_vector(63 downto 0);
src_port
: std_logic_vector(15 downto 0);
dst_port
: std_logic_vector(15 downto 0);
seq_num
: std_logic_vector(31 downto 0);
ack_num
: std_logic_vector(31 downto 0);
tcp_flags : std_logic_vector(5 downto 0);
window
: std_logic_vector(15 downto 0);
length
: std_logic_vector(15 downto 0);
end record;
Das hat den Vorteil, dass wiederum die Anzahl der Signale im Design verringert wird und ein
einheitlicher Zugriff auf die Informationen vorgegeben ist. Eine Realisierung mit einem Logik-
57
7 Realisierung in VHDL
vektor der entsprechenden Länge und dem Zugriff auf dessen Bereiche wäre unübersichtlich und
sehr fehleranfällig, da bei jedem Zugriff die Bereichsgrenzen angegeben werden müssen. Durch
die Verwendung des Records kann auf die einzelnen Elemente direkt zugegriffen werden und bei
aussagekräftiger Namensgebung wird der Code lesbarer, sowie einfacher wartbar. Bei späterer
Erweiterung diesen Typs müssen wenige weiterführende Änderungen am gesamten Quellcode
vorgenommen werden. Deshalb gibt man umfangreiche Informationen innerhalb eines Designs
in abstrakter Form weiter, wie dies mit den Paketinformationen von der Datenpfadlogik zur
Protokollüberwachungslogik geschieht.
Für die Verbindungsinformationen wird auch ein Record Typ definiert, der aber nur innerhalb
der Protokollüberwachungslogik verwendet wird. Die Übergabe der Verbindungsinformationen
geschieht nicht in abstrakter Form, da das Speichermodul zum einen allgemeine Schnittstellen
in Form von Logikvektoren besitzt und zum anderen die Übergabe geteilt in Schlüssel und
Daten erfolgt. Von diesem Typ existiert nur eine Variable in der Protokollüberwachungslogik.
Den Feldern dieser Variablen werden durch eine Konvertierungsfunktion aus dem Schlüssel und
den Daten die entsprechenden Bereiche der Logikvektoren zugewiesen. Dadurch ist der Zugriff
auf die einzelnen Elemente der Verbindungsinformationen während der Paketüberprüfung sehr
übersichtlich. Bei Anfragen an das Speichermodul extrahieren weitere Funktionen die Schlüssel
und Datenbereiche aus dem record. Durch Verwendung von Funktionen für diese Aufgaben,
verringert man die Redundanz im Quellcode und Änderungen an dem Typ erfordern nur zentrale
Änderungen an diesen Funktionen und keine Änderungen im gesamten Quellcode.
type connection_info_type is record
w_ip
: std_logic_vector(31 downto 0);
--West-IP
w_port
: std_logic_vector(15 downto 0);
--West-Port
e_ip
: std_logic_vector(31 downto 0);
--Ost-IP
e_port
: std_logic_vector(15 downto 0);
--Ost-Port
wgps_info
: std_logic_vector(63 downto 0);
--West-GPS
egps_info
: std_logic_vector(63 downto 0);
--Ost-GPS
wseq_una
: std_logic_vector(31 downto 0);
--Sequenznummern
eseq_una
: std_logic_vector(31 downto 0);
--für die
wseq_next
: std_logic_vector(31 downto 0);
--Bereichs-
eseq_next
: std_logic_vector(31 downto 0);
--überprüfung
wwindow
: std_logic_vector(15 downto 0);
--rcv_window
ewindow
: std_logic_vector(15 downto 0);
--rcv_window
connection_state : connection_state_type;
--Verbindungsstatus
valid
: std_logic;
--nicht genutzt
timeout
: std_logic;
--Bit für Alterung
58
7 Realisierung in VHDL
end record;
Für die Zustandskodierung der verschiedenen Zustandsmaschinen in dem Design wird jeweils
ein Aufzählungstyp definiert. Im folgenden ist ein Beispiel für die Zustandsmaschine zum Speichern des Paketes im Zwischenspeicher (vgl. Kapitel 6.1.2, Abbildung 6.5 auf Seite 38) zu sehen.
Diese Codierung ist verständlicher, als wenn man im Quellcode einen Wert auf Eins oder Null
abfragt.
type push_frame_state_type is(idle,
push_frame);
Die Zustandskodierung für den Verbindungsstatus weicht von dieser Methode ab, da man
in dem gezeigten Beispiel keine Kenntnis über die entgültige Codierung der Zustände hat.
Beim Verbindungsstatus benötigt man jedoch die Darstellung des Zustandes als Logikvektor,
da die Schnittstellen zum Speichermodul nur diesen Typ unterstützt. Damit die Lesbarkeit des
Quellcodes dadurch nicht beeinflusst wird, wird ein subtyp und mehrere Konstanten definiert.
constant width : positive
subtype
:= 4;
connection_state_type is std_logic_vector(width-1 downto 0);
constant wsyn_rcv
: connection_state_type := "0000";
constant esyn_rcv
: connection_state_type := "0001";
.
.
.
Durch diese Methode der Zustandskodierung kann man als Designer eine bestimmte Darstellung der Zustände im Design erzwingen und Optimierungen vornehmen.
7.3 Realisierung einzelner Elemente der Module
Die Realisierung der einzelnen Module wird anhand der im Konzept erarbeiteten Zustandsmaschinen durchgeführt. Auf die Einzelnen Zustände soll hier nicht eingegangen werden, herausgestellt werden sollen in diesem Kapitel die Umsetzung der Zwischenspeicher, sowie ein Beispiel
für die Paketverifizierung.
7.3.1 Zwischenspeicher
Für die Zwischenspeicherung der Pakete und Paketinformationen werden FIFOs implementiert.
Als Speicher für die FIFOs wird ein Rammodul verwendet, dass die Einträge in einem Array aus
Logikvektoren speichert und den Zugriff über Adressleitungen ermöglicht. In der Datenpfadlogik
59
7 Realisierung in VHDL
0
rd
gefüllt
wr
leer
rd~
Abbildung 7.2: Realisierung eines Fifo
werden für jeden FIFO zwei Adressen verwaltet, eine Leseadresse und eine Schreibadresse. Diese
Adressen haben nach dem Reset den gleichen Wert. Bei einem Schreibvorgang werden Daten
an die Schreibadresse geschrieben und die Adresse danach erhöht. Die Leseadresse erhöht sich
analog bei einem Lesezugriff auf das Rammodul. Wie in Abbildung 7.2 dargestellt, werden die
Adressen stetig erhöht und durchlaufen dabei den gesamten Adressraum. In der Abbildung ist
zu sehen, dass der Adressraum der Zeiger doppelt so groß ausgelegt ist, wie der Speicher. Die
Adresszeiger sind also um ein Bit breiter als die am Rammodul angeschlossenen Adressleitungen.
Das ist für die Verwaltung des FIFO nötig, damit erkennbar ist wann der FIFO voll und wann
er leer ist. Der FIFO ist leer, wenn der Lesezeiger (rd ) der Schreibzeiger (wr ) eingeholt hat.
In dem Fall besitzen beide Zeiger den gleichen Wert. Erreicht der wr Zeiger die Position rd˜,
ist der FIFO voll. In dem Fall unterscheiden sich die Zeiger nur im höchstwertigsten Bit. Die
im Beispielcode gezeigten Abfragen werden benötigt, damit keine Daten überschrieben werden
und die Pakete im Modul keine Veränderung erfahren. Wenn der Zwischenspeicher gefüllt ist,
werden eintreffende Pakete erworfen.
if (r.wr(log2_ceil(frame_mem_size)-1 downto 0)
=r.rd(log2_ceil(frame_mem_size)-1 downto 0)) then
if (r.wr(r.frame_mem_wr_address’high)
/= r.rd(r.frame_mem_rd_address_comp’high)) then
frame_mem_full := true;
else
frame_mem_empty := true;
end if;
end if;
60
7 Realisierung in VHDL
7.3.2 Überprüfung eines Paketes
Die Überprüfung der Paketinformationen wird in mehreren Einzelschritten in der Protokollüberwachungslogik durchgeführt (vgl. Kapitel 6.3). Der gezeigte Codeauszug zeigt die Überprüfung
eines ACK Paketes im Status established. Zunächst vergleicht die Überwachungslogik die gespeicherten GPS Informationen mit den im Paket enthaltenen. Wenn das Paket diesen Test besteht,
wird es für den Versand frei gegeben, um eine Aktualisierung der Verbindungsinformationen
zuzulassen müssen die Sequenz- und Bestätigungsnummern in den entsprechenden Bereichen
liegen. Die Überprüfungen in den letzten beiden if-Anweisungen stimmt mit den Gleichungen
6.1 und 6.2 auf Seite 48 bis auf die Moduloberechnung überein. Die Moduloberechnungen sind in
dieser Implementierung nicht nötig, die Datentypen vorzeichenlos sind der Überlauf bei diesen
Typen genau der gewünschten Funktionalität entspricht.
if connection_info.egps_info = r.frame_info.gps_info then
v.usend := "11";
if unsigned(r.frame_info.seq_num) - unsigned(connection_info.eseq_next)
<=unsigned(connection_info.eseq_una) + unsigned(connection_info.wwindow)
- unsigned(connection_info.eseq_next) then
if unsigned(r.frame_info.ack_num) - unsigned(connection_info.wseq_una)
<= unsigned(connection_info.wseq_next)
- unsigned(connection_info.wseq_una) then
61
8 Verifikation mit SystemC
8.1 Struktur der Testbenches unter SystemC
Die Verifikation der einzelnen komponenten, sowie des gesamten Design, erfolgt mit einer Mixed
Language Simulation und dem Verifikationstool ModelSim [2]. Eine Mixed Language Simulation
ist der Aufbau einer Simulationsumgebung mit unterschiedluchen Programmiersprachen. Die
Simulationsumgebungen werden in der SystemC entwickelt und instantiieren jeweils das zu
testende VHDL Modell. SystemC ist eine Klassenbibliothek für C++ und erweitert die Sprache
um Elemente und Methoden aus Hardwarebeschreibgungssprachen [1]. Dazu gehören getaktete
Prozesse und Typen zur Bitdarstellung. Die Verwendung von SystemC in der Verifikation ist
der hohe Abstraktionsgrad, den die Sprache C++ bietet, sowie die Verbreitung dieser Sprache.
8.2 Verifikation der Komponenten
Zur Verifikatinion der Datenpfadlogik wird eine Struktur benutzt, die an das ISO-OSI 7 Schichtenmodell angelehnt ist. Diese Struktur simuliert die einzelnen Schichten und erweitert die Nachrichten um den jeweiligen Header. An die Schnittstellen im Datenpfad werden Bus-functional
Models (BFM) angeschlossen, die das Kommunikationsprotokoll auf Signalebene realisieren.
Von einem Generator wird ein Paket über die Transport- Vermittlungs und Sicherungsschicht
an das BFM übergeben, das es an das Device under Test (DuT) überträgt. Damit der Gene-
info
FIFO
Monitor
datalinklayer
crit
networklayer
transportlayer
Generator
BFM
Data_path_in
rcv
next
Frame info info_valid
Data_path_logic
Abbildung 8.1: Struktur Datenpfadlogik TB
62
To_out
Data_path_out
8 Verifikation mit SystemC
BFM
to_out valid
rdy
generator
up_down
Protocol_check_logic
DUT
next
FIFO
FIFO
Frame
next
info
Mem_if_in
memory
Mem_if_out
Frame
valid to_out
info
BFM
Abbildung 8.2: Struktur Protokollüberwachungslogik TB
rator die Kontrolle über die jeweiligen Headerinhalte in den Schichten hat, Beim Aufruf des
Sendeservice einer Schicht besteht die Möglichkeit, neben des zu versendenden Paketes weitere
Informationen zu übergeben. Diese Informationen enthalten die Headerinhalte der jeweiligen
Schichten, wodurch der Generator die Kontrolle über die generierten Pakete hat. Das Generatormodul ist mit den in der Abbildung gezeigten Schnittstellen verknüpft und über einen
FIFO mit dem Monitor verbunden. In den FIFO schreibt der Generator die Headerinformationen, mit denen der Monitor die von der Datenpfadlogik ausgelesenen Informationen vergleicht.
Zusätzlich müssen einige Grenzfälle verifiziert werden, in denen die korrekte Arbeitsweise bei
unterschiedlichen Zwischenspeicherfüllständen überprüft wird.
Auch die Protokollüberwachungslogik muss umfangreichen Tests unterzogen werden, da sie
die eigentliche Verifikation der Pakete vornimmt. Der Generator in dieser Testbench ist wie in
Abbildung ... mit dem DUT verknüpft. Er simuliert den Arbitrierer und signalisiert der Protokollüberwachungslogik, von welchem Stream sie die Paketinformationen anfordern soll. Diese
generiert die Testbench und der Generator übergibt sie an das DUT. Ein weiteres Element dieser Testbench ist das Memorymodul, das die Kommunikation der Protokollüberwachungslogik
mit dem Speicher simuliert. Dieses Modul erhält über einen FIFO die Informationen, die es
bei einem Lesezugriff an das DUT übergeben soll. Des Weiteren nimt das Memorymodul die
63
8 Verifikation mit SystemC
Daten bei einem Schreibzugriff entgegen und gibt diese auf der Konsole in ModelSim aus. Auf
diese Weise ist es möglich eine Verbindung in jeden Zustand zu versetzen, dann verschiedene
Paketeinformationen zu übergeben und Reaktionen des DUT zu überwachen.
In den vorangegangen Testbenches wird die visuelle Verifikation mit Hilfe des Waveformviewer unter ModelSim zur Unterstützung durchgeführt. Bei der Überprüfung der Funktionalität
von Speicher und Arbitrierer erfolgt die Überprüfung nur mit dieser Methode, da bei diesen
Modulen die internen Abläufe überprüft werden und diese unter ModelSim übersichtlich darstellbar sind.
64
Teil IV
Zusammenfassung und Ergebnis
65
9 Zusammenfassung
9.1 Ergebnis
Das Ziel dieser Arbeit, die Entwicklung einer Struktur zur Zustandsüberwachung verbindungsorientierter Kommunikationsprotokolle, wurde am Beispiel des TCP-Protokolls erreicht. Das
entwickelte Modul benutzt zusätzlich bereitgestellte GPS-Ortsinformationen der Verbindungsteilnehmer, um eine erweiterte Überprüfung der Pakete durchzuführen. Dadurch werden IPSpoofing Attacken auf bestehende Verbindungen erkannt und die entsprechenden Pakete werden verworfen. IP-Spoofingpakete, die aus dem gleichen Zugangsbereich kommen und die gleichen GPS-Informationen enthalten werden nicht erkannt. Einen präventiven Schutz gegen IPSpoofing bietet die Überprüfung des IP-Bereiches, da auf diese Weise nur Pakete mit korrekten IP-Adressen weitergeleitet werden. Stealthportscans werden durch das Modul verhindert,
indem nur SYN-Pakete weitergeleitet werden, wenn keine entsprechende Verbindung im Speicher existiert. Die Zustandsüberwachung des TCP-Protokolls führt nicht zu einer maßgeblichen
Verbesserung des Verbindungsschutzes. Das ist darauf zurückzuführen, dass viele Pakete meistens nur verworfen werden dürfen, wenn die GPS-Information nicht korrekt ist. Pakete, die
auf Grund falscher Sequenz- und Bestätigungsnummern nicht zur Verbindung gehören, dürfen
nicht verworfen werden. Die Ursache dafür können abgestürzte Verbindungsteilnehmer sein und
das TCP-Protokoll bietet dafür selbst Lösungen und versendet die entsprechenden Pakete. Aus
diesen Gründen ist der Einsatz einer Zustandsüberwachung für TCP nicht zu empfehlen, da
der erwartetet Gewinn an Sicherheit nicht zu erkennen ist.
9.1.1 Probleme
Ein Problem bei der vorhandenen Version des Moduls ist der Schutz gegen Synflooding, da
SYN-Pakete das Ablegen neuer Verbindungsinformationen im Speicher verursachen. Wenn der
Speicher voll läuft, wird der Aufbau weiterer Verbindungen verhindert und der reguläre Datenverkehr gestört.
Eine Lösung wäre, das Timeout für die Verbindungen im Speichermodul so gering zu wählen,
dass diese Einträge schneller wieder aus dem Speicher gelöscht werden. Dies hätte aber den
66
9 Zusammenfassung
Nachteil, dass auch reguläre Verbindungen betroffen sein könnten. Des weiteren benötigt der
Vorgang des Löschens aus dem Speicher viel Zeit, in der ein Zugriff auf den Speicher nicht
möglich ist.
Eine weitere Überlegung zum Schutz vor SYN-Flooding betrifft die Richtung, aus der Verbindungen aufgebaut werden können. Verbindungen werden nach der Überlegung nur im Speicher
abgelegt, wenn aus der vertrauenswürdigeren Richtung SYNs oder SYN/ACKs eintreffen. Die
SYN/ACKs werden dabei als reguläre Antworten auf SYNs interpretiert und im Zustandsdiagramm für den Verbindungsstatus wird gleich in den Zustand ack_rcv gewechselt. Eine hohe
Frequenz an SYN/ACKs von einer Quelle würde nach dieser Überlegung auf einen Angriff hinweisen. Die Anzahl an Verbindung von der Quelle könnte in dem Fall vorübergehend begrenzt
werden. Diese Methode würde den betroffenen Host zwar nicht schützen, aber den Speicher des
Moduls nicht voll laufen lassen.
Ein weiteres Problem besteht bei dem Vergleich der GPS-Informationen. Befindet sich die
Verbindung im Zustand syn_rcved, sind nur die GPS-Informationen des Initiators verfügbar.
Wenn ein Angriff mit einem IP-Spoofing Paket in dieser Phase des Verbindungsaufbaus durchgeführt wird, bieten die GPS-Informationen keinen Schutz. In dem Fall wird sogar der Aufbau
der Regulären Verbindung verhindert, da die Pakete von der regulären Quelle als Angriffe
angesehen werden.
9.1.2 Version mit vermindertem Funktionsumfang
Da Speicherbedarf und Speicherzugriffe kritische Faktoren bei dem entwickelten Modul darstellen, könnte man den Funktionsumfang senken. Ein Modul ohne angeschlossenen externen
Speicher würde wenig Funktionalität bieten. Solch ein Modul würde ein statisches Filter darstellen und gegen einige Portscans, Landattacken und IP-Bereichsverletzungen schützen. Veringert
man die Verbindungsinformationen, so dass nur die IPs Ports und GPS Informationen gespeichert werden, würde das schon den Schutz vor IP-Spoofing ermöglichen. Dieser Schutz würde
dann ohne die Zustandsüberwachung der Verbindung geboten und könnte leicht an unterschiedliche Protokolle angepasst werden.
9.1.3 Ausblick
Wenn auch die Zustandsüberwachung zunächst keinen Vorteil in der Sicherheit bringt, so werden Sicherheitslösungen auf Hardwarebasis sicher zunehmen. Bei der Benutzung von GPSInformationen als zusätzliches Sicherheitsmerkmal wird der Grad Granularisierung von Bedeutung sein. Wichtig dabei ist, dass Angreifer auf dieses Merkmal keinen Zugriff haben und diese
67
9 Zusammenfassung
Informationen nicht fälschen können. Dann eröffnet sich die Möglichkeit der Definition von vertrauenswürdigen oder zu blockierenden Bereichen. Beim Hinzufügen der GPS-Informationen
zu den IP-Optionen ist eine Anbindung eines GPS-Empfängers nicht nötig. Es ist eher denkbar
das Entsprechende Modul bei der Installation auf den jeweiligen Standort zu konfigurieren.
68
Literaturverzeichnis
[1] SystemC Version 2.0 User’s Guide Updated for SystemC 2.0.1 .
[2] ModelSim SE User’s Manual Version 6.1f , 2006.
[3] CiscoSytems: Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks
; Document ID: 13634 , 2007.
[4] Hecht, R.: VHDL-Synthese für Fortgeschrittene, 2004.
[5] Hinden, S. D. . R.: RFC2460, Internet Protocol Version 6 , 1998.
[6] JTC1: ISO/IEC 7498-1:1994 .
[7] Orlamünder, H.: Paket-basierte Kommunikationsprotokolle. Hüthig Telekommunikation/Bonn, 2005.
[8] Paxson, M. A. . V.: RFC2581, TCP Congestion Control , 1999.
[9] Pohlmann, N.: Firewall-Systeme, 4. aktualisierte und erweiterte Ausgabe. MITP-Verlag
GmbH, 2001.
[10] Postel, J.: RFC791, Internet Protocol , 1981.
[11] Postel, J.: RFC792, Internet Control Message Protocol , 1981.
[12] Postel, J.: RFC793, Transmission Control Protocol , 1981.
[13] Ramakrishnan, K.: RFC3168, The Addition of Explicit Congestion Notification (ECN)
to IP , 2001.
[14] Sedgewick, R.: Algorithmen, 2.Auflage. Addison-Wesley, 2002.
[15] Tanenbaum, A. S.: Computernetzwerke. Prentice Hall Verlag GmbH, 1997.
[16] Ullmann, U.: Check Point FireWall-1/VPN-1 . MITP-Verlag GmbH, 2001.
69
Selbstständigkeitserklärung
Ich erkläre hiermit, diese Arbeit selbstständig angefertigt und die benutzten Quellen vollständig
angegeben zu haben.
Rostock, 31.05.2007
70