Analyse eines verteilten Datenstromes auf Vollständigkeit

Lehrstuhl für
Datenverarbeitung
Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber
Studienarbeit S293
Analyse eines verteilten Datenstroms auf Vollständigkeit
In einem lokalen Netz ist es möglich mittels einer verteilten Datenakquisition ein Abbild
des gesamten Datenverkehrs zu erhalten. Folglich kann die Kommunikation zwischen
einzelnen Systemen nicht nur lokal an den beiden kommunizierenden Systemen, sondern
zusätzlich dezentral rekonstruiert werden.
Ziel dieser Arbeit ist es, verteilt aufgenommenen Datenstrom bzgl. der Vollständigkeit zu
analysieren. Dabei ist zwischen physikalischer und logischer Vollständigkeit zu
differenzieren. Physikalische Vollständigkeit bedeutet die Prüfung, ob alle transferierten
Datenpakete real aufgezeichnet worden sind. Logische Vollständigkeit bezieht sich auf
die Einhaltung einer definierten Kommunikation (Ablaufkontrolle) bzw. Einhaltung der
Protokollsyntax.
Für die Analyse ist es notwendig, den Gesamtdatenstrom in verschiedene Verbindungen
sequenziell zu klassifizieren. Fehlende Pakete müssen erkannt werden, ebenso
Verbindungen, welche lückenhaft oder unvollständig sind. Hierzu sind geeignete
Kriterien am Beispiel von TCP- und UDP-Verbindungen zu entwickeln und umzusetzen.
Das Ergebnis soll in eine Statistik die analysierten Pakete mit den entsprechenden
Verbindungen aufschlüsseln.
Die Analyse bzw. die Software ist durch Tests geeignet zu verifizieren.
Die Analysesoftware ist mit MS Visual C++ unter MS Windows NT/2000 zu realisieren.
Alle Entwicklungsschritte sind zudem projektbegleitend zu dokumentieren.
(Prof. Dr.-Ing. Wolfgang Weber)
Bearbeiter:
Matrikel-Nummer:
Betreuer:
Bearbeitungszeitraum:
cand.-Ing. Katrin Höper
108 096 210 773
Dipl.-Ing Thomas Droste
SS 2001 – WS 2001/02
Inhalt
Inhalt
1
2
Motivation ............................................................................................................... 3
Grundlagen .............................................................................................................. 4
2.1 Transmission Control Protocol/Internet Protocol ............................................... 4
2.1.1 Einordnung in die Schichtenmodelle........................................................... 4
2.1.2 Interaktionen der Protokollinstanzen........................................................... 5
2.2 Das Internet Protocol........................................................................................... 6
2.3 Das Transmission Control Protocol .................................................................... 9
2.3.1 Verbindungsablauf .................................................................................... 10
2.4 Das User Datagram Protocol............................................................................. 13
2.5 Das Hypertext Transfer Protocol ...................................................................... 14
2.6 Das File Transfer Protocol ................................................................................ 14
3
Die Quell-Datei ..................................................................................................... 16
3.1 Aufbau............................................................................................................... 16
3.2 Auswertung ....................................................................................................... 22
4
Das Programm....................................................................................................... 23
4.1 Ablauf................................................................................................................ 23
4.2 Behandlung von Verbindungen und Paketen.................................................... 25
4.2.1 TCP-Verbindungen und Pakete................................................................. 25
4.2.2 UDP-Verbindungen und Pakete ................................................................ 27
4.3 Die Analysefunktionen...................................................................................... 29
4.3.1 Analyse des allgemeinen Frame-Headers ................................................. 29
4.3.2 Analyse des IP-Headers............................................................................. 29
4.3.3 Analyse des TCP-Headers und der dazugehörigen Verbindung ............... 30
4.3.4 Analyse des UDP-Headers und der dazugehörigen Verbindung .............. 33
4.4 Die Ausgabe ...................................................................................................... 34
4.4.1 Protokollzähler........................................................................................... 35
4.4.2 Analysierten Verbindungen....................................................................... 35
4.5 Funktionen......................................................................................................... 37
4.5.1 Auslesen der Parameter der Quell-Datei ................................................... 37
4.5.2 Formatkonvertierung ................................................................................. 38
4.5.3 Auswertung der TCP-Flags ....................................................................... 38
4.5.4 Timeout-Abfrage ....................................................................................... 39
4.5.5 Einsortierung der TCP-Pakete................................................................... 39
4.5.6 Berechnung der Anzahl der Pakete einer TCP-Verbindung ..................... 41
5
Tests ...................................................................................................................... 42
1
Inhalt
6
7
Resümee und Ausblick.......................................................................................... 44
Literatur................................................................................................................. 46
2
Kapitel 1
Motivation
1 Motivation
Ziel dieser Studienarbeit ist es, den von einer Monitoringsoftware protokollierten
Datenstrom eines lokalen Netzes auszuwerten. Die Monitoringsoftware erstellt mittels
einer verteilten Datenakquisition ein Abbild des gesamten Datenverkehrs. Dabei trennt
sie die Protokoll-Header von den übermittelten Daten und schreibt die so extrahierten
Informationen in eine Datei, welche die Grundlage für weitere Verarbeitungen und
Analysen, und somit auch für diese Arbeit, bildet. Die so protokollierten Verbindungen sollen statistisch ausgewertet und auf Vollständigkeit überprüft werden.
Dies stellt gleichzeitig eine Kontrolle der bereits durchgeführten Protokollroutinen dar,
da nach der Aufbereitung der aufgezeichneten Daten z.B. keine Duplikate von Paketen
existieren sollten. Aus der von der Monitoringsoftware generierten Datei kann unter
anderem abgeleitet werden, welches Protokoll wie häufig verwendet worden ist und
wieviele Verbindungsaufbauversuche zustande gekommen oder erfolglos geblieben
sind.
Die Analyse soll fehlende Pakete sowie lückenhafte oder unvollständige
Verbindungen erkennen. Hierzu müssen entsprechende Algorithmen entworfen
werden, welche die Eigenschaften von TCP1- und UDP2-Verbindungen zur Untersuchung der protokollierten Verbindungen ausnutzen.
Da das TCP und das UDP die wohl am häufigsten verwendeten Protokolle in
Computernetzen sind und sowohl HTTP3 als auch FTP4 diese als Grundlage für ihre
Verbindungen verwenden, gibt die Betrachtung dieser beiden Services einen guten
Überblick über die Funktionsfähigkeit der Monitoringsoftware. Aus demselben Grund
kann die Analyse auch zur statistischen Auswertung der Zuverlässigkeit der Verbindungen im Netzwerk herangezogen werden.
1
TCP - Transmission Control Protocol
2
UDP - User Datagram Protocol
3
HTTP - Hyper Text Transfer Protocol
4
FTP - File Transfer Protocol
3
Kapitel 2
Grundlagen
2 Grundlagen
2.1 Transmission Control Protocol/Internet Protocol
Die TCP/IP-Protokollfamilie bildet die Grundlage für das Internet, denn sie ermöglicht
die weltweite Kommunikation in heterogenen Netzen. TCP/IP steht für eine Reihe von
Protokollen, der so genannten „Internet Protocol Suite“. Zu den größten Vorteilen bei
der Nutzung von TCP/IP- Protokollen gehören das einheitliche Adressierungsschema
und die standardisierte Schnittstelle (API - Application Program Interface) zu Anwendungsprogrammen. Die beiden wichtigsten Protokolle TCP und IP sind zum Synonym
für diese Familie geworden.
2.1.1 Einordnung in die Schichtenmodelle
In der Abbildung 2-1 ist die Einordnung einiger Internetprotokolle der TCP/IPProtokollfamilie in das TCP/IP-Schichtenmodell dargestellt. Auf der linken Seite der
Abbildung wird das Modell auf das ISO/OSI5-Schichtenmodell abgebildet, welches
aus sieben Schichten besteht. Es ist üblich in TCP/IP-Netzen das TCP/IP-Schichtenmodell zu verwenden, da es nur in vier Schichten unterteilt und für diese Gruppe von
Verbindungen ausgelegt ist. Die für eine spätere Analyse betrachteten Protokolle sind
grau hervorgehoben.
Das Address Resolution Protocol (ARP) unterstützt die Zuordnung von IP-Adressen in
der Internetschicht (bzw. der Vermittlungsschicht im ISO/OSI-Schichtenmodell) zu
den entsprechenden Adressen der darunterliegenden Schicht. Wobei das Reverse
Address Resolution Protocol (RARP) die Umkehrfunktion dieses Protokolls zur
Verfügung stellt.
Obwohl das Internet Control Message Protocol (ICMP) und das Internet Group
Management Protocol (IGMP) den IP-Dienst nutzen, werden sie dennoch der
Vermittlungsschicht im ISO/OSI- und der Internetschicht im TCP/IP-Schichtenmodell
(jeweils Schicht 3) zugeordnet. ICMP unterstützt den Austausch von Kontrollinformationen innerhalb dieser Schicht. IGMP ist für die Verwaltung von Kommunikationsgruppen zuständig.
Die anwendungsbezogenen Schichten 5-7 im ISO/OSI-Schichtenmodell (Kommunikationssteuerungs-, Darstellungs-, Anwendungsschicht) werden im TCP/IP-Schichten-
5
ISO / OSI - International Standardization Organization / Open Systems Interconnection
4
Kapitel 2
Grundlagen
modell zu einer Anwendungsschicht zusammengefasst. Ihr werden z.B. Protokolle wie
FTP, Telnet, HTTP oder SMTP6 zugeordnet, die im Internet eingesetzt werden.
Anwendungsbezogene
Schichten
5-7
Transportschicht
Telnet
HTTP
FTP
...
Anwendungsschicht
4
TCP
UDP
4
Transportschicht
3
IGMP
Vermittlungsschicht
3
ICMP
Internetschicht
IP
ARP
RARP
Datensicherungs- &
Bitübertragungsschicht
1-2
2
physikalische Schicht
1
Abbildung 2-1: Die Internetprotokolle im TCP/IP-Schichtenmodell auf das
ISO/OSI- Schichtenmodell abgebildet
2.1.2 Interaktionen der Protokollinstanzen
In Abbildung 2-2 sind die Interaktionen der im Kapitel 2.1.1 vorgestellten
Internetprotokolle im TCP/IP-Schichtenmodell dargestellt. Die für die spätere Analyse
betrachteten Protokolle sind grau hervorgehoben. Eine Kommunikation findet sowohl
zwischen den Schichten (hier zwischen den Schichten eins und zwei, sowie zwischen
Schicht zwei und drei) als auch innerhalb der Schichten (hier Schicht zwei) statt.
Der Ablauf der Sendung einer Nachricht kann z.B. nach Abbildung 2-2 wie folgt
skizziert werden: Die TCP- bzw. UDP-Instanz übergibt die zu übermittelnden Daten
zusammen mit der IP-Adresse des Empfängers (der genaue Ablauf sowie die
detaillierte Beschreibung der Protokolldaten folgt in Kapitel 2.3 und 2.4) an die IPInstanz innerhalb der Internetschicht. Hier beauftragt die IP-Instanz die ARP-Instanz
6
SMTP - Simple Mail Transfer Protocol
5
Kapitel 2
Grundlagen
mit der Ermittlung der entsprechenden MAC7-Adresse. Diese wird zusammen mit den
Daten und weiteren Protokolldaten an die darunterliegende Sicherungsschicht übergeben. Andersherum reicht die IP-Instanz empfangene Pakete an die TCP- bzw. UDPInstanz weiter.
Probleme während der Übermittlung können den Partenerinstanzen über ICMP-Meldungen mitgeteilt werde, wobei das IP zur Übertragung benutzt wird. Zur Übermittlung von Informationen über Gruppenzugehörigkeiten mittels IGMP wird ebenfalls
das IP genutzt.
Schicht 4
Anwendungsschicht
TCP
UDP
ICMP
ARP
IP
IGMP
RARP
Schicht 1
physikalische Schicht
Abbildung 2-2: Zusammenspiel der Protokolle im TCP/IP-Schichtenmodell
2.2 Das Internet Protocol
Das Internet Protocol (IP) ist ein verbindungsloses Protokoll der TCP/IP-Protokollfamilie und stellt die Grundlage zur Übermittlung von Daten zwischen Geräteeinheiten
in Netzwerken dar. Verbindungslos bedeutet, dass dieses Protokoll keinen Verbindungszustand kennt. Es ist also nicht notwendig, eine IP-Verbindung zu einem
Rechner zu "öffnen", bevor Daten zu diesem Rechner gesendet werden können. Der
Verbindungsaufbau und -abbau gehören nicht in den Zuständigkeitsbereich dieses
Protokolls.
7
MAC - Media Access Control
6
Kapitel 2
Grundlagen
Die Hauptaufgabe des IP ist es die Unterschiede zwischen den verschiedenen darunter
liegenden Netzwerkschichten zu verbergen und eine einheitliche Sicht auf die verschiedensten Netzwerktechnologien zu präsentieren. Eine weitere Aufgabe ist die Ermittlung und Realisierung des optimalen Weges zwischen Sender und Empfänger für
jedes Datenpaket. Um dies zu ermöglichen, werden vom IP ein einheitliches Adressierungsschema und ein Fragmentierungsmechanismus, der es ermöglicht große
Datenpakete durch Netze mit kleiner maximaler Paketgröße zu senden, genutzt.
Das IP-Paket kann ohne vorherige Verhandlungen mit dem Empfänger direkt an ihn
versandt werden. Es gibt keine Garantie, dass das versandte Paket beim gewünschten
Empfänger ankommt. Verlorene Pakete werden nicht automatisch neu versandt. Auch
die Reihenfolge in der dieser Empfänger die Pakete erhält, muss nicht der Reihenfolge
entsprechen, in der die Pakete verschickt worden sind. Es kann passieren, dass auf dem
Übertragungsweg IP-Pakete verloren gehen oder mehrfach ankommen. Sind Dienste
wie Ende-zu-Ende-Datensicherheit, Flußkontrolle, Datenabfolge und/oder Fehlererkennung erwünscht, müssen zusätzlich Protokolle aus höheren Schichten eingesetzt
werden.
In Abbildung 2-3 ist der IP-Header abgebildet, wobei die in der Quell-Datei aufgezeichneten Felder grau hervorgehoben sind. Im weiteren werden diese Felder kurz
erläutert. Für weiterführende Informationen zu diesem Thema sei auf [PFL01] und
[POS81] verwiesen.
1
4
Version
IHL
8
12
TOS
20
Flags
Identifikation
TTL
16
Protokoll
24
Paketlänge
28
32
Fragmentabstand
Prüfsumme
IP–Senderadresse
IP–Empfängeradresse
Optionen
Füllzeichen
Abbildung 2-3: IP-Header
• Version
In diesem 4 Bit grossem Feld befindet sich die Versionsnummer des verwendeten
Internet Protokolls. In dieser Arbeit wird nur Version 4 (IPv4) behandelt.
• Internet Header Length (IHL)
Das IHL-Feld ist 4 Bit lang und enthält die Länge des Protokollkopfes. Die Länge
wird in 32-Bit-Worten angegeben und ist abhängig von der Größe des OptionenFeldes.
7
Kapitel 2
Grundlagen
• Type of Service (TOS)
Das TOS-Feld ist 8 Bit lang. In ihm können mehrere Service-Qualitäten (Quality of
Service) festgelegt werden. Es wird zwischen low-delay, high-reliability und highthroughput unterschieden. Durch diese Klassifizierung können Diensten verschiedene Prioritäten zugeordnet werden.
• Flags
Dieses Feld ist drei Bit lang und enthält drei Kontroll-Flags. Das 1. Bit (MSB8) ist
reserviert und immer gleich null gesetzt. Das 2. Bit gibt an, ob fragmentiert werden
darf (=0) oder nicht (=1). Das 3. Kontroll-Flag ist gleich null, wenn es sich beim
Paket um das letzte Fragment handelt und gleich eins, wenn noch weitere
Fragmente folgen.
• Time to Live (TTL)
Das TTL-Feld ist 8 Bit lang. Es zeigt die maximale Zeit an, die ein Datenpaket in
einem Netzwerk existieren darf. Jede Station, die das Datenpaket bearbeitet (z.B.
weiterleitet), dekrementiert die TTL. Wird der Wert null erreicht, wird das Paket
verworfen.
• Protokoll
Das Protokoll-Feld ist 8 Bit lang und legt das Protokoll der höheren Schicht
(Transportschicht) fest. Diese wird zur Weiterverarbeitung des Paketes benutzt.
Eine Liste der hier relevanten Werte ist in Tabelle 2-1 aufgelistet, eine vollständige
Liste aller zugeordneten IP-Nummern ist in [REY94] angegeben.
Nummer
1
2
6
17
89
Protokoll
ICMP
IGMP
TCP
UDP
OSPF
Tabelle 2-1: IP nutzende Protokolle
• IP-Senderadresse
Das 32 Bit lange Feld enthält die IP-Adresse des Senders.
• IP-Empfängeradresse
Dieses 32 Bit lange Feld enthält die IP-Adresse des Empfängers.
8
MSB - Most significant bit / LSB - Least significant bit
8
Kapitel 2
Grundlagen
2.3 Das Transmission Control Protocol
Das Transmission Control Protocol (TCP) unterstützt im Gegensatz zum IP eine zuverlässige, verbindungsorientierte Datenübertragung. Verbindungsorientiert bedeutet,
dass das Protokoll eine logische Ende-zu-Ende-Verbindung herstellt. Das hohe Maß an
Zuverlässigkeit wird durch Bestätigungs-, Flusskontroll-, Zeitüberwachungs- und Verbindungssteuerungsmechanismen erreicht. Die transferierten Dateneinheiten (Pakete)
bestehen aus einem mindestens 20 Byte großen Protokollkopf und den zu übertragenden Nutzdaten. In jedem Paket ist eine Prüfsumme zur Fehlerkontrolle der Daten
enthalten. Im Falle einer fehlerfreien Übertragung sendet der Empfänger eine Empfangsbestätigung an den Sender, andernfalls wird das Datenpaket verworfen und
keine Empfangsbestätigung verschickt.
Wird nach einer bestimmten Zeitperiode (retransmission timeout, [STE94]) beim
Sender keine Empfangsbestätigung empfangen, verschickt der Sender das betreffende
Paket erneut.
In Abbildung 2-4 ist der TCP-Header abgebildet, wobei die für die Analyse verwendeten Felder grau hervorgehoben sind. Nähere Beschreibungen befinden sich unter
anderem in [PFL01] und [POT81].
1
Abstand
4
8
Sendeport
Reserviert
12
16
20
Sequenznummer
Acknowledgenummer
Kontrollbits
Prüfsumme
24
28
Empfangsport
32
Fenstergröße
Urgent-Zeiger
Optionen
Füllzeichen
Abbildung 2-4: TCP–Header
• Sendeport
Der Sendeport ist ein 16 Bit langes Feld, welcher die Portnummer der Quelldaten
enthält. Für die spätere Analyse ist er von Bedeutung, da an Hand des Wertes entschieden werden kann, welcher Service bei der Verbindung benutzt wird oder
werden soll (vgl. Kapitel 2.5 und 2.6).
• Empfangsport
Der Empfangsport ist ein 16 Bit langes Feld, welches den Zielport der zu
übertragenden Daten enthält. Er bleibt für die Dauer der Verbindung gleich.
9
Kapitel 2
Grundlagen
• Sequenznummer
Dieses Feld ist 32 Bit lang und enthält eine Nummer mit deren Hilfe die Position
eines Paketes innerhalb eines Datenstroms bestimmt werden kann. Ausgehend von
der ersten Sequenznummer einer Verbindung, die zufällig gewählt wird, erhalten
alle darauffolgenden Pakete (desselben Senders) eine inkrementierte Sequenznummer. So können fehlende Pakte erkannt werden.
• Acknowledgenummer
Mit dieser ebenfalls 32 Bit langen Zahl wird die Sequenznummer des nächsten
Paketes angegeben. Sie ist die inkrementierte Sequenznummer des letzten Paketes
des Kommunikationspartners. Gesendet wird die Acknowledgenummer als vom jeweiligen Empfänger. Beide Kommunikationspartner wählen jeweils eine zufällige
Sequenznummer die von der jeweiligen anderen Partei bestätigt wird. Der genaue
Ablauf wird im Kapitel 2.3.1 erläutert.
• Kontrollbits
Dieses 6 Bit lange Feld dient zur Kontrolle der Übertragung. Die 6 Kontrollbits
sind in Abbildung 2-5 aufgeführt, wobei die für die Analyse relevanten und verwendeten wieder grau hervorgehoben sind.
1
URG
2
ACK
3
PSH
4
RST
5
SYN
6
FIN
Abbildung 2-5: TCP-Kontrollbits
• Acknowledge (ACK)
Das ACK -Bit ist gesetzt (= eins) wenn eine Anfrage zum Verbindungsaufbau
oder -abbau bestätigt wird (vgl. Kapitel 2.3.1).
• Synchronize (SYN)
Das SYN-Bit ist bei der Verbindungsanfrage, also beim ersten Paket, gesetzt.
• Finish (FIN)
Das FIN-Bit ist übernimmt die Rolle des SYN-Bit beim Verbindungsabbau. Ist
es gesetzt, handelt es sich um die Anfrage zur Beendung der aktuellen TCPVerbindung.
2.3.1 Verbindungsablauf
Die festen TCP-Verbindungen werden über ein Dreiwege-Handshake (three way
handshake) aufgebaut. Über das Dreiwege-Handshake werden Steuerinformationen
ausgetauscht, welche die logische Ende-zu-Ende-Verbindung regeln. Auch der Abbau
einer TCP-Verbindung wird mittels eines Handshake-Protokolls realisiert.
10
Kapitel 2
Grundlagen
In Abbildung 2-6 wird beispielhaft eine TCP-Verbindung zwischen einem Client und
einem Server skizziert. Die Verbindung wird allgemein in drei Phasen unterschieden:
Verbindungsaufbau, Datenaustausch und Verbindungsabbau.
Client
Sequencenr.: 456
Acknowlegdenr.: beliebig
Sendeport: 1250
Empfängerport:80
Server
SYN=1
ACK=0
F
=0
K=1 FIN
C
A
1
=
SYN
Sequencenr.: 457
Acknowlegdenr.: 790
Sendeport: 1250
Empfängerport:80
ACK=1
F
IN=0
SYN=0
ACK=0
F
IN=1
SYN=0
ACK=1
F
Sequencenr.: 790 + n
Acknowlegdenr.:458 + n
Sendeport: 80
Empfängerport:1250
Verbindungsabbau
FIN=1
ACK=1
SYN=0
FIN=1
ACK=0
0
=
N
Y
S
Sequencenr.: 458 + n
Acknowlegdenr.: 791 + n
Sendeport: 1250
Empfängerport:80
Sequencenr.: 789
Acknowlegdenr.: 457
Sendeport: 80
Empfängerport:1250
Datenaustausch
Sequencenr.: 457 + n
Acknowlegdenr.: 790 + n
Sendeport: 1250
Empfängerport:80
SYN=0
Verbindungsaufbau
IN=0
IN=1
Abbildung 2-6: Beispielhafter Ablauf einer TCP-Verbindung
2.3.1.1 Verbindungsaufbau
Der Aufbau einer TCP-Verbindung zwischen Sender und Empfänger (in der Abbildung Server und Client) findet durch einen Dreiwege-Handshake statt. Wobei die drei,
für drei gesendete Pakete und Handshake für Anfrage und Bestätigung stehen.
11
Kapitel 2
Grundlagen
Im Beispiel aus Abbildung 2-6 möchte der Client eine Verbindung zum Server aufbauen. Hierzu schickt er ein Paket mit gesetzten SYN-Bit an den Server. Die
Sequenznummer für das erste Paket wird zufällig gewählt und liegt zwischen 0 und
232–1 (32 Bit). Der Wert für die Acknowledgenummer des ersten Paketes ist ebenfalls
zufällig, im weiteren Verlauf jedoch unwichtig und deshalb in der Abbildung als
beliebig bezeichnet. Der Sendeport des Clients liegt standardmäßig zwischen 1024 und
5000, im Beispiel bei 1250. Der Empfangsport der ersten Nachricht gibt (im
Normalfall) Aufschluß über den angeforderten Dienst. Er wird als „well-known-port“
bezeichnet, da es standardmäßige Zuordnungen von Portnummern und Diensten gibt
(die vollständige Liste dieser Zuordnungen ist in [REY94] angegeben). Der Empfangsport 80 bedeutet, dass der Client eine HTTP-Verbindung anfordert. Akzeptiert der
Empfänger die Anfrage, schickt er ein Antwortpaket an den Sender (Client) mit gesetzten SYN- und ACK-Bit. Hierbei wählt er ebenfalls eine zufällige Sequenznummer
zwischen 0 und 232-1. Im Acknowledgenummern-Feld des zweiten Paketes befindet
sich die inkrementierte Sequenznummer des ersten Paketes (also des Absenders).
Sende- und Empfangsport sind im Vergleich zum ersten Paket vertauscht, da auch
Sender und Empfänger nun ihre Rollen getauscht haben. Das dritte und somit letzte
Paket des Verbindungsaufbau quittiert wiederum den Erhalt des zweiten Paketes mit
einem gesetzten ACK-Bit. Der Client inkrementiert seine eigene Sequenznummer und
schreibt in das Acknowledgenummern-Feld die inkrementierte Sequenznummer des
empfangenen (zweiten) Paketes. Sende- und Empfangsport sind wie beim ersten Paket
gewählt. Mit dem dritten Paket ist der Verbindungsaufbau erfolgreich abgeschlossen
und es können gleichzeitig erste Nutzdaten übermittelt werden.
2.3.1.2 Datenaustausch
Über die etablierte TCP-Verbindung können Client und Server nun Daten austauschen.
Hierbei wird jedes empfangene Paket quittiert (mittels der Acknowledgenummer).
Client und Server werden abwechselnd zum Sender und Empfänger. Durch die
Sequenznummer können fehlende Pakete detektiert werden. Wird ein Paket nach einer
bestimmten Zeit nicht bestätigt, wird es erneut versendet. Nach einer festgelegten
Zeitspanne (timeout period) in der keine Pakete bestätigt oder empfangen worden sind,
wird die Verbindung beendet.
Wie am Beispiel zu erkennen ist, wählen Sender und Empfänger jeweils eine eigene
Sequenznummer, die beim senden des nächsten Paketes inkrementiert wird. Die Sequenznummer des anderen wird inkrementiert und in das Feld für die Acknowledgenummer geschrieben. Die Ports bleiben während der gesamten Verbindung unverändert und werden, je nach Rolle des Senders, getauscht.
12
Kapitel 2
Grundlagen
2.3.1.3 Verbindungsabbau
Zum Beenden der TCP-Verbindung wird wiederum ein Handshake-Protokoll ausgeführt. Da TCP-Verbindungen fullduplex Verbindungen sind, dass heißt es wird in
beide Richtungen gesendet und beide Rechner können die Rolle des Senders oder Empfängers übernehmen, muss die Verbindung für beide Richtungen einzeln abgebaut
werden. Dazu sendet der Teilnehmer, der die Verbindung beenden will, ein Paket mit
gesetzten FIN-Bit. Der Empfänger bestätigt mit einem Paket bei dem sowohl das FINals auch das ACK-Bit gesetzt sind. Soll auch die Verbindung in die andere Richtung
(als Sender) beendet, sendet der ein weiteres Paket mit gleicher Sequenz- und Acknowledgenummer und gesetztem FIN-Bit. Wird dieses letzte Paket wiederum mit gesetztem ACK- und FIN-Bit bestätigt, ist die Verbindung erfolgreich für beide Richtungen abgebaut und die TCP-Sitzung wird geschlossen.
2.4 Das User Datagram Protocol
Das User Datagram Protocol (UDP) bietet höheren Protokollen einen definierten
Dienst zum transaktionsorientierten Versand von Datenpaketen. Es setzt unmittelbar
auf dem IP auf. Das UDP verfügt nur über minimale Protokollmechanismen zur
Datenübertragung und bietet keine Ende-zu-Ende-Verbindung. Der Empfang des
Datenpakets sowie der von Duplikaten kann nicht erkannt werden. Die korrekte
Reihenfolge der Datenpakete auf der Empfängerseite ist nicht gewährleistet. Minimale
Protokollmechanismen haben einen dementsprechend kurzen Paket-Header zur Folge.
Daher wird UDP häufig als Datentransportdienst gewählt, wenn nur geringe Datenmengen zu übertragen sind. Werden geringe Datenmengen mit dem TCP übertragen,
kann es durchaus passieren, dass der Verwaltungsaufwand für die Herstellung der
Verbindung und das Sicherstellen einer korrekten Übertragung größer ist, als der
Aufwand für eine erneute Übertragung der gesamten Daten. In Abbildung 2-7 ist der
UDP-Header abgebildet, wobei die in der Quell-Datei protokollierten Felder grau
hervorgehoben sind. Nähere Beschreibungen befinden sich unter anderem in [JUN00]
und [PFL01].
1
4
8
Sendeport
Paketlänge
12
16
20
24
28
Empfangsport
Prüfsumme
32
Abbildung 2-7: UDP-Header
13
Kapitel 2
Grundlagen
• Sendeport
Der Sendeport ist ein 16 Bit großes Feld, welcher die Portnummer der Quelldaten
enthält. Er gibt bei der späteren Analyse Aufschluss über den angeforderten oder
bereits genutzten Dienst.
• Empfangsport
Der Empfangsport ist ein 16 Bit großes Feld, welcher den Zielport der Daten
enthält. Er gibt wie der Sendeport Aufschluss über den genutzten Dienst während
der Verbindung. Beide Ports bleiben während der Verbindung unverändert.
• Paketlänge
Die Paketlänge ist ein 16 Bit langes Feld, welche die Gesamtlänge, also Headerund Nutzdaten, des Paketes enthält.
2.5 Das Hypertext Transfer Protocol
Das Hypertext Transfer Protocol (HTTP) ist das wichtigste Transportprotokoll für
webbasierte Inhalte. Dieses Protokoll ermöglicht die Übertragung von Information in
Form von Internetseiten. Die Kommunikation zwischen Client und Webserver erfolgt
durch den Austausch von HTTP-Nachrichten. Diese übertragen die Anfragen und
Antworten zwischen Sender und Empfänger. Zum Austausch der Nachrichten wird im
Standardfall eine TCP-Verbindung auf Port 80, ein sogenannter „well-known-port“
aufgebaut. Der Client schickt eine Anfrage an den HTTP-Port des Servers und dieser
schickt seine Antwort an den Empfangsport des Clients, der im Normalfall zwischen
1024 und 5000 liegt. Die Request und Response genannten Nachrichten bestehen im
Wesentlichen aus zwei Teilen: Header und Daten. Der Header enthält Steuerinformationen, wie zum Beispiel die verwendete Methode und den gewünschten
URL9. Der Datenabschnitt der Nachricht selbst besteht aus einem HTML10-Dokument
oder Formulardaten, die der Client an den Server sendet.
2.6 Das File Transfer Protocol
Das File Transfer Protocol (FTP) wird im Internet zum Datentransfer zwischen zwei
Rechnern eingesetzt. Da nahezu jede Internetseite Dateien zum Download anbietet,
besteht laut [REI01] ungefähr die Hälfte des gesamten Datenaufkommens im Internet
aus FTP-Verbindungen. Das FTP baut zwischen Server und Client zwei Verbindungen
auf. Die Erste, auch Steuerkanal genannt, dient ausschließlich der Übermittlung von
FTP-Kommandos und den zugehörigen Antworten, die Zweite als Datenkanal. Über
9
URL - Uniform Resource Locator
10
HTML - Hypertext Markup Language
14
Kapitel 2
Grundlagen
den Steuerkanal tauschen beide Seiten Kommandos aus, die dann eine Datenübertragung über einen zweiten Kanal einleiten. Dabei werden in den Standardeinstellungen Port 21 für die Kommandos und Port 20 für die Dateiübertragung genutzt.
Leitet der Server den Datentransfer ein, gehorcht der Datentransferprozess des Clients
den Befehlen des Servers, bis die Daten vollständig übertragen worden sind. Das FTP
sieht dabei simultane Verbindungen vor. Die Kontrollverbindung muß während des
kompletten Datentransfers bestehen bleiben.
15
Kapitel 3
Die Quell-Datei
3 Die Quell-Datei
Die Grundlage der Analyse bildet die von der Monitoringsoftware generierte Datei
[BAU99], die im weiteren als Quell-Datei bezeichnet wird. Dort sind die Protokolldaten und Verbindungsinformationen aller aufgezeichneten Pakete aufgeführt. Die
Protokolldaten sind zuvor von den gesendeten Nutzdaten getrennt worden. Die Protokoll-Header der verwendeten Protokolle werden dabei ausgewertet, Informationen
daraus extrahiert und teilweise neu zusammengestellt.
3.1 Aufbau
Der allgemeine Aufbau der Datei wird mit Hilfe der Abbildungen 3-1 bis 3-12
dargestellt. Dabei handelt es sich um sogenannte Syntaxdiagramme, in denen Rechtecke als nicht-terminale und Kreise als terminale Symbole verwendet werden. Grau
unterlegte Felder stehen wieder für die von der Analyse benötigten Informationen.
Eine Zeile der Quell-Datei enthält jeweils alle zu einem Paket einer Verbindung
aufgezeichneten Informationen. Dabei sind die einzelnen Informationen durch ein
Semikolon getrennt, nach dem letzten Feld folgt ein Zeilenumbruch.
In Abbildung 3-1 wird der allgemeine Aufbau einer Zeile in der Quell-Datei
dargestellt. Die Zeilen bestehen aus dem allgemeinen Frameheader und dem nachfolgenden Frametype-Header. Allgemeiner Frameheader bedeutet, dass diese Information für jedes Paket aufgezeichnet und protokolliert werden und für alle verwendeten Protokolle im gleichen Format vorliegen. Handelt es sich beim FrametypeHeader um den IP-Header, folgt zusätzlich der Header des verwendeten IPProtokolls. Jede Zeile wird mit einem End-of-Line-Symbol abgeschlossen. Bei der
Analyse wird der untere Pfad des Syntaxdiagramms betrachtet, bei dem es sich um ein
Paket einer IP-Verbindung handelt.
Der allgemeine Frameheader (vgl. Abbildung 3-2) setzt sich für alle Pakete aus dem
Timestamp, mehreren MAC-Adressen und dem Frametype zusammen. Der Timestamp
besteht aus dem Datum und der Uhrzeit (vgl. Abbildung 3-3), wobei es sich bei den
Angaben um Zeit und Datum der Aufzeichnung des jeweiligen Paketes im Netzwerk
handelt. Die Datumsangabe besteht aus der vierstelligen Jahreszahl, dem Monat und
dem Tag, wobei diese Angaben durch einen Schrägstrich getrennt sind, wie in
Abbildung 3-4 zu sehen ist. Die Uhrzeit setzt sich aus den Stunden, Minuten und
Sekunden zusammen, wobei hier der Doppelpunkt als Seperator dient (vgl. Abbildung
3-5). Bei den angegebenen MAC-Adressen handelt es sich um die MAC-Adresse des
Hosts, auf dem die Protokollierung des Datenverkehrs stattgefunden hat, die MACAdresse des Senders und des Empfängers des jeweiligen Paketes (vgl. Abbildung 3-6).
16
Kapitel 3
Die Quell-Datei
allgemeiner Frameheader
;
Frametype-Header*
IP-Header
eol
IP-Protokoll-Header
;
Abbildung 3-1: allgemeines Format einer Quell-Datei
Timestamp
;
MAC-Adressen
;
Frametype
;
Abbildung 3-2: Format des allgemeinen Frameheaders
Datum
Zeit
Abbildung 3-3: Format des Timestamps
JJJJ
/
MM
/
DD
Abbildung 3-4: Format des Datums
HH
:
MM
SS
:
Abbildung 3-5: Format des Time-Feldes
Host-MAC
;
Source-MAC
;
Destination-MAC
Abbildung 3-6: Format des MAC-Adressen-Feldes
17
Kapitel 3
Die Quell-Datei
Im letzten Feld des allgemeinen Frameheaders steht die vierstellige Nummer des
Frametypes. Diese Zahlen sind bestimmten Protokollen zugeordnet, wobei die Zuordnungen aller aufgezeichneten Protokolle in Tabelle 3-1 angegeben sind.
Nummer
0800h
0806h
0835h
0805h
6001h
6004h
8137h
809bh
Frametype
IP
ARP
RARP
X.25 Level3
DECnet
DECLAT
IPX/SPX
AppleTalk
Tabelle 3-1: Frametypes und die zugehörigen hexadezimalen Zahlenwerte
Für die spätere Analyse ist nur die Frametype-Nummer 0800h von Interesse, da dies
für eine IP-Verbindung steht. Nach diesem Feld kann nur der zugehörige FrametypeHeader folgen. In Abbildung 3-7 ist dies durch nicht mehr zusammengeführte Pfeile
nach der Frametype-Nummer angedeutet.
In Abbildung 3-8 sind alle aufgezeichneten Protokoll-Header (ohne das IP)
aufgeführt. Da dessen Vorkommen nur gezählt wird und diese Verbindungen nicht
näher untersucht werden, wird an dieser Stelle darauf verzichtet die Struktur der
jeweiligen Header anzugeben.
Die Struktur der bei IP-Verbindungen aufgezeichneten Header-Informationen ist in
Abbildung 3-9 zu sehen. Der entsprechende Abschnitt in der Protokollzeile beginnt
immer mit [IP] und wird von der IP-Sender- und IP-Empfängeradresse gefolgt. Die
nachfolgende Zahl gibt an, um welche IP-Version es sich bei der aktuellen Verbindung
handelt. Gefolgt von den Feldern Internet Header Length, Type of Service, Flags, Time
to Live und Protokoll (vgl. Kapitel 2.2).
Im Protokollfeld des IP-Headers ist angegeben, welches höhere Protokoll für die Verbindung genutzt wird. In Tabelle 2-1 sind alle Werte und die zugehörigen Protokolle,
in Abbildung 3-10 der Aufbau innerhalb der Quell-Datei zu sehen. Da in der Analyse
nur TCP- und UDP-Verbindungen näher untersucht werden, sind in den Abbildungen
3-11 und 3-12 der Aufbau der TCP- und UDP-Header dargestellt.
Die aufgezeichneten TCP-Paketdaten beginnen jeweils mit [TCP] gefolgt vom Sendeund Empfangsport. Diese Ports lassen Rückschlüsse auf die angeforderten und verwendeten Dienste der Verbindung zu. Die Sequenznummer, die Acknowledgenummer
18
Kapitel 3
Die Quell-Datei
und die Flags werden für jedes TCP-Paket angegeben und werden für die Analyse
dieser Verbindungen benötigt.
0800h
0806h
0835h
0805h
6001h
6004h
809bh
8137h
Abbildung 3-7: Format des Frametype-Feldes
Die aufgezeichneten Informationen einer UDP-Verbindung fallen kürzer aus, da dieses
Protokoll (vgl. Kapitel 2.4) einen kürzeren Header verwendet. Die UDP-Daten beginnen jeweils mit [UDP] gefolgt von den zwei Ports. Im letztem Feld wird die Paketlänge angegeben.
19
Kapitel 3
Die Quell-Datei
ARP
RARP
X.25 Level 3
DECnet
DECLAT
AppleTalk
IPX/SPX
Abbildung 3-8: mögliche Frametypes einer Quell-Datei
[IP]
IP-Senderadresse
;
IP-Empfängeradresse
;
Version
;
IHL
;
TOS
;
Flags
;
TTL
;
Protokoll
Abbildung 3-9: Format des IP-Headers einer Quell-Datei
20
Kapitel 3
Die Quell-Datei
TCP-Header
UDP-Header
ICMP-Header
IGMP-Header
OSPF-Header
Abbildung 3-10 : mögliche IP-Protokolle einer Quell-Datei
[TCP]
Sendeport
;
Empfängerport
;
Sequenznummer
;
Acknowledgenummer
;
Flags
Abbildung 3-11:Format des TCP-Headers einer Quell-Datei
[UDP]
Sendeport
;
Empfängerport
;
Paketlänge
Abbildung 3-12 : Format des UDP-Headers einer Quell-Datei
21
Kapitel 3
Die Quell-Datei
In Abbildung 3-13 ist ein Ausschnitt von fünf Zeilen (entspricht fünf aufgezeichneten
Paketen) aus einer Quell-Datei abgebildet.
Abbildung 3-13: Auszug aus einer Quell-Datei
3.2 Auswertung
Die Auswertung der Quell-Datei findet zeilenweise statt, wobei das jeweilige Zeilenende am Zeilenumbruch erkannt wird. Die einzelnen Felder werden durch Semikolon
getrennt. Somit können die Informationen zwischen diesen Seperatoren bei Bedarf
zwischengespeichert und ausgewertet werden.
Durch die verwendeten Trennsymbole (Semikolon, Schrägstriche, Doppelpunkte, das
eol-Symbol) und den Symbolen der IP-Protokoll-Header wie z.B. [TCP] und [UDP]
wird die Analyse erheblich erleichtert, da direkt nach gewissen Schlüsselwörtern
innerhalb einer Zeile gescannt werden kann. Die Quell-Datei bleibt während und nach
Abschluß der Analyse in ihrer Ursprungsform erhalten.
22
Kapitel 4
Das Programm
4 Das Programm
Das Analyseprogramm ConnectionChecker ist in MS Visual C++ unter MS Windows
NT programmiert und dokumentiert worden. Zur Bedienung existiert eine einfache
Benutzeroberfläche (vgl. Abbildung 4-1) mit Ausgabefenster. In diesem Fenster wird
die analysierte Datei, die Statistik über alle Verbindungen, sowie die Auswertungen
der untersuchten Verbindungen inklusive ihrer Pakete ausgegeben. Im Programm wird
die zu untersuchende Quell-Datei zeilenweise eingelesen und ausgewertet. Dabei wird
das Vorkommen der verschiedenen Protokolle gezählt und insbesondere die TCP- und
UDP-Verbindungen genauer untersucht.
Abbildung 4-1: Benutzeroberfläche des ConnectionChecker
4.1 Ablauf
Das Programm wertet alle aufgezeichneten Pakete statistisch in Hinsicht auf die
verwendeten Protokolle aus. Dazu werden beim Programmaufruf Protokollzähler
initialisiert, die während der Analyse inkrementiert werden. Bestimmte Verbindungen
(hier TCP- und UDP-Verbindungen) werden genauer untersucht, indem die Pakete
nach Verbindungen sortiert und auf Vollständigkeit untersucht werden. Für jede dieser
Verbindungen wird geprüft, ob der Verbindungsaufbau und/oder Verbindungsabbau
23
Kapitel 4
Das Programm
erfolgreich war, ob Pakete verloren gegangen sind oder es einen timeout gab. Auch
diese Daten werden statistisch erfasst und ausgegeben.
Bei Programmaufruf wird aus einer Initialisierungs-Datei ausgelesen, in welchen
Verzeichnis sich die zu analysierende Datei befindet und welche Dateiendung sie
besitzt.
Nach dem Betätigen des CheckConnection-Buttons wird die Hauptroutine OnCheckConnections() aufgerufen. Zunächst wird das aktuelle Verzeichnis, der gesetzte DateiFilter und der Status der Quell-Datei (File open oder File not found) ausgegeben.
Konnte die Datei geöffnet werden, wird die erste Zeile ausgelesen, und ausgegeben.
Anschließend wird die Funktion FrameAnalyse aufgerufen, die die aktuelle Zeile
analysiert. Danach beginnt die Prozedur von vorne. Dies geschieht solange, bis das
Dateiende der Quell-Datei erreicht wird. Sind alle Zeilen analysiert, wird die Ausgaberoutine für die Protokollzähler CounterOutput und für die analysierten TCP(ConnectionOutput) und UDP-Verbindungen (UDPConnectionOutput) aufgerufen und
die Quell-Datei geschlossen. Die Abbildung 4-2 zeigt den Programmablaufplan des
beschriebenen Hauptprogramms. Einige der in dieser Funktion aufgerufenen Unterprogramme werden in den folgenden Kapitel näher erläutert.
Verzeichnispfad und Dateiendung für Quell-Datei festlegen
Öffnen der Datei
Datei konnte geöffnet werden
Wahr
Ausgabe: "Filename:"
Falsch
Ausgabe: "no files to
analyse found"
Dateiende nicht erreicht
neue Zeile einlesen
aktuelle Zeile ausgeben
aktuelle Zeile analysieren
%
Ausgabe Protokollzähler
Ausgabe analysierter Verbindungen
Schließen der Quell-Datei
Abbildung 4-2: Struktogramm der Funktion OnCheckConnection
24
Kapitel 4
Das Programm
4.2 Behandlung von Verbindungen und Paketen
Im Programm werden die TCP- und UDP-Verbindungen analysiert. Dazu werden
zunächst alle detektierten TCP- und UDP-Pakete nach Verbindungen sortiert. Sowohl
die Anzahl der Verbindungen als auch die Anzahl der Pakete pro Verbindung sind im
Programm dynamisch mittels Listen realisiert. Um ein Paket eindeutig einer bereits
bestehenden Verbindungen zuordnen zu können, müssen charakteristische Werte für
jede Verbindung definiert werden. Diese Werte stellen die „Visitenkarte“ der Verbindung dar. Um die Zugehörigkeit zu überprüfen, werden die Visitenkarten aller
offenen Verbindungen mit den entsprechenden Werten des aktuellen Paketes verglichen und werden ggf. der Verbindung zugeordnet. Kann ein Paket nicht zugeordnet
werden oder existiert noch keine Verbindung, wird eine neue Verbindung generiert
und gleichzeitig das aktuelle Paket als erstes zugewiesen. Dementsprechend enthält
jede Verbindung mindestens ein Paket. Das erste eingelesene Paket legt jeweils die
Visitenkarte der Verbindung fest. Zusätzlich zur Visitenkarte werden für jede Verbindung Status-Bits abgespeichert, die für die anschließende Analyse der gesamten
Verbindung von Bedeutung sind. Diese Status-Bits werden mit jedem neuen Paket,
welches in die Verbindung eingelesen wird, aktualisiert. Für jedes Paket werden
zusätzliche Informationen abgespeichert.
4.2.1 TCP-Verbindungen und Pakete
Ein TCP-Paket kann einer TCP-Verbindung zugeordnet werden, wenn sowohl die IPAdressen des Senders und Empfängers, als auch die Sende- und Empfangsports genau
oder vertauscht übereinstimmen. Diese Daten bilden dementsprechend die Visitenkarte
einer TCP-Verbindung. Die Status-Bits der TCP-Verbindung sind Flags, die gesetzt
werden, wenn die Pakete des Verbindungsaufbaus und -abbaus vorhanden sind.
Zusätzlich gibt es im Programm ein Status-Bit namens Timeout, welches gesetzt wird,
wenn die Verbindung auf Grund zu langer Wartezeiten (Timeout period wurde
überschritten) geschlossen worden ist. Wenn das Timeout-Bit gesetzt ist, können dieser
Verbindung keine weiteren Pakete mehr zugeordnet werden.
In Abbildung 4-3 ist die Behandlung von TCP-Verbindungen und ihren Paketen
dargestellt. Bei den dargestellten Verbindungen befinden sich die Werte der Visitenkarte oberhalb und die einzelnen Status-Bits unterhalb des Querstrichs. Diese Werte
sind im Programm stellvertretend für jede Verbindung abgespeichert und repräsentieren diese. Die für jedes Paket abgespeicherten Daten sind: IP-Sender- und IP-Empfängeradresse, Sende- und Empfangsport, Sequenz- und Acknowledgenummer, die
drei Kontroll-Bits ACK, SYN und FIN und der Timestamp. Die vier ersten Werte sind
charakteristisch für die zugehörige Verbindung und entsprechen genau oder jeweils
vertauscht der Visitenkarte der zugehörigen Verbindung. Sequenz- und Acknowledge25
Kapitel 4
Das Programm
nummer werden zur Sortierung der Pakete innerhalb der Verbindung verwendet. Da
diese Nummern jeweils beim nächsten Paket inkrementiert werden, können die Pakete
mittels dieser Werte in Reihenfolge gebracht werden. Die Herstellung der richtigen
Reihenfolge der Pakete wird für die spätere Analyse der gesamten Verbindung benötigt. Nur so kann festgestellt werden, ob und wieviele Pakete fehlen.
TCP-Verbindungen
Verbindung 2
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
___________________
1.Paket
2.Paket
3.Paket
vorletztes Paket letztes
Paket
Timeout
____________________________
Verbindung 1
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
1.Paket
Paket 1
2.Paket
IP-Senderadresse
IP-Empfängeradresse
3.Paket
Sendeport
Empfangsport
vorletztes Paket
Sequenznummer
letztes PaketAcknowledgenummer
ACK-Bit
Timeout SYN-Bit
FIN-Bit
Timestamp
Verbindung n-1
Verbindung n
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
___________________
1.Paket
2.Paket
3.Paket
vorletztes Paket letztes
Paket
Timeout
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
___________________
1.Paket
2.Paket
3.Paket
vorletztes Paket letztes
Paket
Timeout
Paket m2
Paket 1
Paket mn-1
Paket 1
Paket mn
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
Paket 1
Paket m1
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Sequenznummer
Acknowledgenummer
ACK-Bit
SYN-Bit
FIN-Bit
Timestamp
Abbildung 4-3: Behandlung von TCP-Verbindungen und Paketen im Programm
Da es bei TCP-Paketen eine Ordnung gibt, wird zwischen einlesen (Funktion Read()
im Programmcode) und einsortieren (Funktion insert) der Pakete unterschieden. Sind
die Pakete in der richtigen Reihenfolge angekommen, müssen sie nur in die bestehende Verbindung eingelesen werden. Das bedeutet, das aktuelle Paket wird als
letztes Paket der Verbindung angefügt (vgl. Abbildung 4-4).
26
Kapitel 4
Das Programm
V.1: aktuelles Paket
...
Sequenznummer
Acknowledgenummer
...
V.1:
V.1:
Paket 5
V.1: ...
Paket 4
V.1: ... Sequenznummer
Paket 3
Acknowledgenummer
V.1: ... Sequenznummer
Paket
2
...
Acknowledgenummer
V.1:
Paket
1
... Sequenznummer
...
Acknowledgenummer
... Sequenznummer
...
Acknowledgenummer
Sequenznummer
...
Acknowledgenummer
...
Paket 6
V.1: ...
Paket 5
V.1: ... Sequenznummer
Paket 4
Acknowledgenummer
V.1: ... Sequenznummer
Paket
3
...
Acknowledgenummer
V.1: ... Sequenznummer
Paket 2
Acknowledgenummer
V.1:
Paket
1 ...
... Sequenznummer
...
Acknowledgenummer
... Sequenznummer
...
Acknowledgenummer
Sequenznummer
...
Acknowledgenummer
...
Abbildung 4-4: Einlesen eines TCP-Paketes in eine Verbindung
Stimmt die Reihenfolge nicht, muss das Paket einsortiert werden. Anhand der
Sequenz- und Acknowledgenummer wird die Position bestimmt und das Paket an entsprechender Stelle eingefügt. Die Pakete, die in der Reihenfolge davorliegen, bleiben
unbeeinflusst, die dahinter liegenden werden eine Position nach hinten gerückt (vgl.
Abbildung 4-5).
V.1: aktuelles Paket
...
Sequenznummer
Acknowledgenummer
...
V.1:
V.1:
Paket 5
V.1: ...
Paket 4
V.1: ... Sequenznummer
Paket 3
Acknowledgenummer
V.1: ... Sequenznummer
Paket
2
Acknowledgenummer
V.1: ... Sequenznummer
Paket
1 ...
...
Acknowledgenummer
... Sequenznummer
...
Acknowledgenummer
Sequenznummer
...
Acknowledgenummer
...
Paket 6
V.1: ...
Paket 5
V.1: ... Sequenznummer
Paket 4
Acknowledgenummer
V.1: ... Sequenznummer
Paket
3
...
Acknowledgenummer
V.1: ... Sequenznummer
Paket 2
Acknowledgenummer
V.1:
Paket
1 ...
Sequenznummer
...
...
Acknowledgenummer
... Sequenznummer
...
Acknowledgenummer
Sequenznummer
...
Acknowledgenummer
...
Abbildung 4-5: Einsortieren eines TCP-Paketes in eine Verbindung
Die Kontroll-Bits werden zum setzen der Status-Bits der Verbindung benötigt. Der
Timestamp der Pakete wird für die Timeout-Abfrage der Verbindung verwendet.
4.2.2 UDP-Verbindungen und Pakete
Wie bei der Behandlung von TCP-Paketen können erkannte UDP-Pakete einer Verbindung zugeordnet werden, wenn sowohl die IP-Adressen des Senders und Empfängers, als auch die Sende- und Empfangsports genau oder vertauscht übereinstimmen. Diese Daten bilden wiederum die Visitenkarte der Verbindung. Das Timeout-Bit
ist hier das einzige Status-Bit, da UDP als verbindungsloses Protokoll keinen Ver27
Kapitel 4
Das Programm
bindungsaufbau und -abbau vorsieht und dementsprechend keine Flags dafür benötigt.
Ist das Timeout-Bit gesetzt, können der Verbindung keine weiteren Pakete zugeordnet
werden.
In Abbildung 4-6 ist die Behandlung von UDP-Verbindungen und den zugehörigen
Paketen dargestellt. Bei den dargestellten Verbindungen befindet sich die Visitenkarte
oberhalb und das Status-Bit unterhalb des Querstrichs. Diese Werte werden im
Programm stellvertretend für jede Verbindung abgespeichert und repräsentieren diese.
Der für jedes UDP-Paket zusätzlich zur Visitenkarte abgespeicherten Parameter ist der
Timestamp. Dieser Wert wird für die Timeout-Abfrage benötigt. Weitere Daten stehen
aus dem UDP-Header der Quell-Datei nicht zur Verfügung. Da es bei UDP-Paketen
keine spezifische Reihenfolge innerhalb einer Verbindung gibt, müssen diese auch
nicht einsortiert werden. Anders als bei TCP-Paketen, werden UDP-Pakete immer als
letzes Paket zur Verbindung hinzugefügt (entspricht dem Einlesen eines TCP-Paketes
in Abbildung 4-4). Es wird dementsprechend nur eine Funktion (Read()) im Programm
zum Einlesen benötigt.
UDP-Verbindungen
Verbindung 1
Verbindung 2
Verbindung n-1
Verbindung n
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
_________________
Timeout
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
_________________
Timeout
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
_________________
Timeout
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport Paket 1
IP-Senderadresse
____________________________
Timeout
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
Paket m2
Paket 1
Paket mn-1
Paket 1
Paket mn
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
Paket 1
Paket m1
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
IP-Senderadresse
IP-Empfängeradresse
Sendeport
Empfangsport
Timestamp
Abbildung 4-6: Behandlung von UDP-Verbindungen und Paketen im Programm
Da die Anzahl der Pakete einer UDP-Verbindung nicht bekannt ist, kann bei der
Analyse nicht ermittelt werden, ob und wieviele Pakete fehlen. Es kann nach Abschluss der Analyse die Anzahl der Pakete der analysierten offen und geschlossenen
(durch Timeout) Verbindungen ermittelt werden
28
Kapitel 4
Das Programm
4.3 Die Analysefunktionen
Nach dem Auslesen der ersten Zeile aus der Quell-Datei, wird diese analysiert. Es
werden nacheinander die einzelnen Felder der Zeile ausgelesen, wobei nur die TCPund UDP-Verbindungen vollständig analysiert werden. Von diesen wiederum können
in dieser Programmversion nur HTTP und FTP als benutzte Dienste erkannt werden.
Bei allen anderen Verbindungen wird nur der entsprechende Protokoll-Zähler
inkrementiert. Anschließend wird die Analyse dieser Zeile abgebrochen. Die verschiedenen Analysefunktionen werden in den folgenden Unterkapiteln ausführlich behandelt und mit Hilfe von Struktogrammen veranschaulicht (Abbildungen 4-7 bis 4-12).
4.3.1 Analyse des allgemeinen Frame-Headers
Die erste Analysefunktion FrameAnalyse (vgl. Struktogramm 4-7) liest alle Felder des
allgemeinen Frame-Headers der aktuellen Zeile in entsprechende Variablen ein. Je
nach Frametypenummer wird der entsprechende Protokollzähler inkrementiert. Handelt es sich bei der Nummer um 0800h, also der Frametypenummer für das IP (vgl.
Tabelle 3-1), wird die Analyse des Pakets weitergeführt. Bei allen anderen Protokollen
wird die Analyse nach der statistischen Erfassung abgebrochen.
Einlesen der Felder des allgemeinen Frame-Headers der aktuellen
Zeile
Wahr
Frametype= 0800h?
IP-Protokollzähler inkrementieren
Analyse des IP-Headers der aktuellen
Zeile
Falsch
entsprechenden
Protokollzähler
inkrementieren
Abbildung 4-7: Struktogramm der Analysefunktion FrameAnalyse
4.3.2 Analyse des IP-Headers
Handelt es sich bei der aktuellen Zeile um die aufgezeichneten Daten eines Paketes
einer IP-Verbindung, wird innerhalb der FrameAnalyse-Funktion die Funktion
AnalyseIPHeader (vgl. Abbildung 4-8) aufgerufen. Dieser Funktion wird die aktuelle
Zeile, ohne die bereits eingelesenen Felder, übergeben. Aus der so gekürzten Zeile
werden nun die einzelnen Felder des IP-Headers ausgelesen und in entsprechenden
Variablen gespeichert.
Wenn es sich beim verwendeten Internet Protokoll um die IPv4 handelt, wird die
Analyse fortgesetzt. Da IPv6 einen anderen Protokoll-Header und verschiedene Betriebs-Modi besitzt, kann dies hier nicht weiter behandelt werden. Bei der fortgeführ29
Kapitel 4
Das Programm
ten Analyse wird anschließend nach dem verwendeten IP-Protokoll sortiert. Nur
Zeilen mit den Werten 6 (TCP, vgl. Tabelle 2-1) oder 17 (UDP) im entsprechenden
Protokoll-Feld des IP-Headers, werden nach der Inkrementierung des entsprechenden
Protokollzählers noch weiter ausgewertet. Alle anderen IP-Protokolle werden statistisch erfasst, die Analyse der aktuellen Zeile an dieser Stelle abgebrochen und die
nächste Zeile der Quell-Datei eingelesen. Handelt es sich beim aktuellen Paket um ein
Paket einer TCP-Verbindung wird eine weitere Funktion zur Auswertung des TCPHeaders und anschließend zur Analyse der zugehörigen Verbindung aufgerufen. Handelt es sich um ein Paket einer UDP-Verbindung werden zwei äquivalente Funktionen
ausgeführt.
Einlesen der Felder des IP-Headers der aktuellen Zeile
IP-Version= 4?
Wahr
Falsch
switch (IP-Protokoll)
case 6
case 17
sonst
InkremenInkremenInkrementierung TCPtierung UDPtierung des
Protokollzähler Protokollzähler entsprechenden
Protokollzählers
Analyse des
TCPHeaders der
aktuellen
Zeile
Analyse des
UDPHeaders der
aktuellen
Zeile
Analyse der
aktuellen
TCPVerbindung
Analyse der
aktuellen
UDPVerbindung
%
%
Abbildung 4-8: Struktogramm der Analysefunktion AnalyseIPHeader
4.3.3 Analyse des TCP-Headers und der dazugehörigen Verbindung
Nach der Feststellung, dass es sich um ein TCP-Paket handelt, wird die Funktion
AnalyseTCPHeader aufgerufen (vgl. Struktogramm 4-9). Der Funktion wird die
gekürzte Zeile, mit den noch nicht ausgelesenen und ausgewerteten Feldern,
übergeben. Die Funktion liest die Felder des TCP-Headers aus und speichert sie in
entsprechenden Variablen. Anschließend werden einige Werte in andere Formate
konvertiert. Als nächstes werden die TCP-Kontroll-Flags ausgewertet. Für die Ver30
Kapitel 4
Das Programm
bindungsanalyse werden nur die Werte der ACK-, SYN- und FIN-Kontroll-Bits, die
sich an der 2., 5. und 6. Position (vgl. Abbildung 2-5) befinden, benötigt. Ob diese Bits
gesetzt sind oder nicht, wird in entsprechenden Variablen für die folgende Analyse der
kompletten TCP-Verbindung gespeichert.
Einlesen der Felder des TCP-Headers der aktuellen Zeile
Auswertung der TCP-Flags
Abbildung 4-9: Struktogramm der Analysefunktion AnalyseTCPHeader
Nach dem Auslesen der TCP-Headerdaten aus der aktuell betrachteten Zeile findet in
der AnalyseIPHeader der nächste Funktionsaufruf statt. Zur Einordnung des Paketes in
die zugehörige Verbindung und anschließende Analyse der Verbindung wird die
Funktion AnalyseTCPConnection (vgl. Struktogramm 4-10) aufgerufen.
In dieser Funktion wird zunächst abgefragt, ob bereits TCP-Verbindungen existieren.
Die Existenz einer solchen Verbindung bedeutet, dass bei der Analyse der Quell-Datei
bereits TCP-Pakete gefunden und entsprechenden TCP-Verbindungen zugeordnet
worden sind. Existiert mindestens eine solche Verbindung wird die Timeout-Abfrage
durchgeführt. Hiermit wird überprüft, ob bereits erfasste offene TCP-Verbindungen
schon zu lange auf das nächste Paket warten. Die sogenannte Timeout-Zeit bezeichnet
den Zeitraum, in der auf das nächste Paket der etablierten TCP-Verbindung gewartet
werden darf. Bei überschrittener Wartezeit wird die Verbindung geschlossen.
Anschließend wird versucht das aktuelle Paket einer offenen (kein Timeout), bereits
existierenden TCP-Verbindung zuzuordnen. Das Paket wird dabei mit den
Visitenkarten aller offenen Verbindungen verglichen. Wird die passende gefunden,
muss das Paket an richtiger Position in die Verbindung einsortiert werden. Die
Position eines Paketes wird an Hand der Acknowledge- und der Sequenznummer
bestimmt. Zunächst wird der einfachste Fall, das Paket kommt in der richtigen
Reihenfolge an, überprüft. Ist dies der Fall, wird das Paket in die zugehörige
Verbindung als letztes Paket mittels der Funktion Read() eingelesen. Anschließend
werden die Flags des Paketes mit dem der Verbindung abgeglichen. Hierbei wird ggf.
gespeichert, ob alle Pakete des Verbindungsaufbaus bzw. -abbaus vorhanden sind.
Nach dem Einlesen des Paketes wird die Schleife abgebrochen und die Funktion
beendet.
31
Kapitel 4
Das Programm
TCP-Verbindung/en existiert/existieren bereits
Wahr
Falsch
Timeout-Abfrage
alle Verbindungen durchsucht oder Paket einsortiert
Paket paßt zur akt. Verbindung
Wahr
Falsch
Paket in richtiger Reihenfolge
Wahr
Falsch
Paket in Verbindung
einlesen
%
Flags in Verbindung
setzen
alle Positionen durchsucht oder Paket
einsortiert
%
Paket in Reihenfolge
Wahr
Falsch
Paket in Verbindung
einsortieren
Flags in Verbindung
setzen
%
Position
dekrementieren
Paket nicht eingelesen
Wahr
Falsch
Paket an erster Pos.
in Verbindung
einsortieren
%
keine TCP-Verbindung existiert oder Paket konnte keiner
zugeordnet werden
Wahr
Falsch
neueTCP-Verbindung erzeugen
Paket in Verbindung einlesen
%
Flags in Verbindung setzen
Abbildung 4-10: Struktogramm der Analysefunktion AnalyseTCPConnection
32
Kapitel 4
Das Programm
Ist das Paket nicht in der richtigen Reihenfolge angekommen, wird es mit allen bereits
eingetroffenen Paketen der Verbindung verglichen, um die richtige Position innerhalb
der Verbindung zu finden. Das Paket wird anschließend an dieser Stelle mittels der
Funktion insert() eingefügt. Abschließend findet die Auswertung der Flags statt.
Danach wird die Schleife abgebrochen und die Funktion beendet.
Konnte das Paket keiner existierenden TCP-Verbindung zugeordnet werden oder
existiert noch keine, wird eine neue TCP-Verbindung erzeugt und das Paket in diese
mit Read() eingelesen. Abschließend wird die Bedeutung der Flags des Paketes für die
Verbindung ausgewertet und die Funktion beendet.
4.3.4 Analyse des UDP-Headers und der dazugehörigen Verbindung
Ähnlich wie bei der Behandlung von TCP-Paketen, wird nach der Feststellung, dass es
sich beim aktuellen Paket um ein Paket einer UDP-Verbindung handelt, die Funktion
AnalyseUDPHeader aufgerufen (vgl. Abbildung 4-11). An diese wird die gekürzte
aktuelle Zeile übergeben, wobei anschließend die Felder des UDP-Headers ausgelesen
und in Variablen gespeichert werden. Einige Werte werden in andere Formate konvertiert, danach findet in der übergeordneten Funktion AnalyseIPHeader der nächste
Funktionsaufruf statt.
Einlesen der Felder des UDP-Headers der aktuellen Zeile
Abbildung 4-11: Struktogramm der Funktion AnalyseUDPHeader
Dieser startet die Funktion AnalyseUDPConnection (vgl. Struktogramm 4-12) zur
Einsortierung des Paketes in die zugehörige Verbindung und zur anschließenden
Analyse der bereits bestehenden Verbindungen. Diese Analyse ist nicht so komplex
wie bei einer TCP-Verbindung, da das UDP verbindungslos ist. Dementsprechend
entfällt das Einsortieren der Pakete in bestimmte Positionen innerhalb einer
Verbindung. Es kann hier nur festgestellt werden, welches Paket zu welcher Verbindung gehört und ob es zu einem Timeout gekommen ist. Auch die Auswertung von
Flags entfällt, da es keinen Verbindungsaufbau und –abbau gibt.
Mit der ersten Abfrage in der Funktion wird überprüft, ob bereits eine oder mehrere
UDP-Verbindungen existieren. Existiert zumindest eine, wird untersucht, ob das
aktuelle Paket einer von ihnen zugeordnet werden kann. Zuvor findet, wie bei der
Analyse der TCP-Verbindungen, eine Timeoutabfrage statt. Warten offene Verbindungen schon zu lange (länger als die gesetzte Timeout-Zeit) auf das nächste Paket,
wird das Timeout-Flag gesetzt und die Verbindung für geschlossen erklärt. Anschliessend wird das Paket mit den Visitenkarten aller offenen Verbindungen verglichen. Bei
33
Kapitel 4
Das Programm
Übereinstimmung wird das Paket in die entsprechende Verbindung eingelesen. Konnte
das Paket keiner existierenden UDP-Verbindung zugeordnet werden oder existiert
noch keine, wird eine neue UDP-Verbindung erzeugt. Anschließend wird das aktuelle
Paket in diese Verbindung eingelesen.
UDP-Verbindung/en existiert/existieren
bereits
Wahr
Falsch
Timeout-Abfrage
alle Verbindungen durchsucht oder
Paket einsortiert
Wahr
Paket paßt zur akt.
Verbindung
Paket in
Verbindung
einlesen
%
Falsch
Zeiger auf
nächste
Verbindung
setzen
keine UDP-Verbindung existiert oder Paket
konnte keiner zugeordnet werden
Wahr
Falsch
neue UDP-Verbindung erzeugen
%
Paket in Verbindung einlesen
Abbildung 4-12: Struktogramm der Anaylsefunktion AnalyseUDPConnection
4.4 Die Ausgabe
Im Ausgabefenster der GUI11 (vgl. Abbildung 4-1) wird zunächst die zu analysierende
Quell-Datei mit Dateiendung und -pfad angegeben. Anschließend werden alle Zeilen
der gewählten Quell-Datei zur Kontrolle der Daten ausgegeben.
Nach der Auswertung aller Zeilen der gewählten Quell-Datei, werden die Ergebnisse
im Fenster der GUI dargestellt. Alle TCP- und UDP-Verbindungen werden separat mit
zugehörigen Paketen und Analyseergebnissen aufgeführt. Über die restlichen Verbindungen, die nur gezählt worden sind, wird eine zusammengefaßte Statistik ausgegeben.
11
GUI - Graphical User Interface
34
Kapitel 4
Das Programm
4.4.1 Protokollzähler
Nach vollständiger Analyse der Quell-Datei, wird im Hauptprogramm die Funktion
CounterOutput() zur Bildschirmausgabe der einzelnen Protokoll-Zähler aufgerufen.
Hier wird die Statistik aller Pakete nach ihren Protokollen sortiert ausgegeben
(Statistics of used protocols). Zunächst wird die Anzahl der Pakete der verschiedenen
Protokollen angegeben, die dann wiederum nach verwendeten IP-Protokollen, wie z.B.
TCP und UDP, aufgeschlüsselt werden (vgl. Abbildung 4-13). Die im Programm unbehandelten Protokolle werden jeweils mittels der Zähler unknown erfasst.
Abbildung 4-13: Beispiel für Ausgabe der Protokollzähler
4.4.2 Analysierten Verbindungen
Nach der Ausgabe der Protokoll-Zähler werden alle analysierten Verbindungen inklusive ihrer Pakete ausgegeben. Dabei wird zwischen der Ausgabe der TCP-Verbindungen (Aufruf der Funktion ConnectionOutput()) und der UDP-Verbindungen unterschieden (Aufruf der Funktion UDPConnectionOutput()).
4.4.2.1 Die TCP-Verbindungen
Die durchnumerierten TCP-Verbindungen werden mit ihren charakteristischen
Werten, Analyseergebnissen und allen zugeordneten Paketen der Reihe nach im
Fenster der GUI ausgegeben (vgl. Abbildung 4-14).
35
Kapitel 4
Das Programm
Abbildung 4-14: Beispiel für Ausgabe der TCP-Verbindungen inklusive ihrer
Pakete
Zu den charakteristischen Werten jeder Verbindung zählen die Visitenkarte und die
Kontroll-Bits (vgl. Abbildung 4-3). Zu den Analyseergebnissen gehören unter anderem die Auswertungen der Kontroll-Bits und des Ports.
Als ein Analyseergebnis wird der genutzte Dienst (used service) ausgegeben. In dieser
Version des Programms werden nur HTTP- und FTP-Verbindungen als solche erkannt.
Sind alle drei Pakete des Verbindungsaufbaus vorhanden, wird ausgegeben, dass der
Dreiwege-Handshake zum Verbindungsaufbau vollständig (Establishment complete),
ansonsten unvollständig war (Establishment incomplete). Das gleiche gilt für den Verbindungsabbau.
Danach wird die Anzahl der analysierten, der ursprünglichen und der evtl. fehlenden
Pakete der Verbindung ausgegeben. Ist die Anzahl der Pakete der vollständigen
Verbindung nicht berechenbar, wird dies gemeldet (# of total packets: unknown).
Anschließend folgen alle Pakete der Verbindung, die sortiert und durchnumeriert ausgegeben werden. Für jedes Paket werden beide IP-Adressen und Ports, sowie die
Sequenz- und Acknowledgenummer angegeben.
4.4.2.2 UDP-Verbindungen
Nach der Ausgabe aller analysierten TCP-Verbindungen, folgt die Ausgabe aller UDPVerbindungen. Zunächst wird die Anzahl der ermittelten UDP-Verbindungen angegeben (Total # of UDP-connections). Danach folgen die Angaben der einzelnen Ver36
Kapitel 4
Das Programm
bindungen, die aus der Visitenkarte und der Anzahl der Pakete der Verbindung, sowie
ihrem Status (open oder Timeout) bestehen. Danach wird der genutzte Dienst angezeigt, wobei in der derzeitigen Version ebenfalls nur FTP und HTTP als Service erkannt werden.
Abbildung 4-15:Beispiel für Ausgabe der UDP-Verbindungen inklusive ihrer Pakete
Abschließend folgen alle Pakete der aktuellen Verbindung. Für jedes Paket werden
Sende- und Empfangsport angegeben (vgl. Abbildung 4-15).
4.5 Funktionen
Im Programmcode müssen die Protokollabläufe von UDP und TCP in programmierbare Regeln umgesetzt werden, die für die Analyse genutzt werden können. Die
für die Analyse benötigten Daten müssen an richtiger Stelle aus der Quell-Datei ausgelesen und anschließend in ein auswertbares Format konvertiert werden.
4.5.1 Auslesen der Parameter der Quell-Datei
Zum Auslesen einzelner Parameter aus einer Zeile der Quell-Datei ist die Funktion
ExtractFirstParameter aus dem Programm PacketParser [DRO02] übernommen
worden. Diese Funktion nutzt aus, dass die einzelnen Felder durch Semikola getrennt
sind. Der Funktion wird die aktuelle Zeile übergeben. Sie extrahiert den ersten Parameter der Zeile, indem sie alle Daten bis zum ersten Semikolon ausliest. Die Funktion
gibt sowohl den ausgelesen Wert, sowie die um diesen gekürzte Zeile zurück. Der
37
Kapitel 4
Das Programm
ausgelesene Wert kann anschließend bei Bedarf in einer entsprechenden Variablen
zwischengespeichert werden. Die gekürzte Zeile wird zur weiteren Analyse verwendet, bis alle benötigten Parameter ausgelesen worden sind.
4.5.2 Formatkonvertierung
Im Programm wird die Konvertierung von einem Speichertyp in einen anderen aus
zwei Gründen benötigt. Einmal, um aus der Quell-Datei ausgelesene Parameter für die
Analyse weiterverwenden zu können und zweitens um Werte auszugeben.
Die aus der Quell-Datei ausgelesenen Zeilen liegen als CString im Programm vor.
Dementsprechend sind alle daraus ausgelesenen Parameter vom selben Datentyp.
Die Inhalte der Felder Frametype und IP-Protokoll müssen in integer-Werte umgewandelt werden, damit sie für case-Abfragen im Programm benutzt werden können.
Diese case-Abfragen werden benötigt, um zu entscheiden, welche Pakete weiter analysiert und welche nur für die Statistik gezählt werden.
Auch die Felder Sendeport, Empfangsport (für TCP- und UDP-Verbindungen),
Sequenznummer, Acknowledgenummer und Kontroll-Bits (für TCP-Verbindungen)
müssen in integer-Werte konvertiert werden. Bei den Portnummern muss überprüft
werden können, ob sie in einem bestimmten Intervall liegen. Die Sequenz- und
Acknowledgenummern müssen der Größe nach verglichen werden können und die
TCP-Kontrollbits in einen auswertbaren Format vorliegen (Vgl. Kapitel 4.5.3).
Eine weitere wichtige Formatierung stellt die Umwandlung des Timestamps in eine
entsprechende CTime-Variable dar. Mit diesen Datentyp können Daten verglichen und
sortiert werden. Außerdem kann so zwischen zwei Daten die Differenz gebildet
werden, was für die Timeout-Abfrage nötig ist.
Für die Bildschirmausgabe müssen alle zuvor umgewandelten Größen wieder in
CStrings konvertiert werden.
4.5.3 Auswertung der TCP-Flags
Nach ihrer Konvertierung liegen die Kontroll-Bits des TCP-Paketes als 6-stellige
Binärzahl vor. Da für die Analyse aber nur das 2. (ACK), 5. (SYN) und 6. (FIN) Bit
(vgl. Kapitel 4.3.3 und Abbildung 2-5) von Bedeutung sind, müssen diese Bits einzeln
betrachtet werden. Um herauszufinden, ob ein bestimmtes Bit innerhalb eines Bytes
gesetzt (=1) ist, muss das Byte mit einer bestimmten Binärzahl logisch UND-verknüpft werden. Prinzip und Wahrheitstabelle der UND-Verknüpfung in [WEB92].
Die Binärzahlen mit denen die TCP-Flag-Variable zur Auswertung der einzelnen
Kontrollbits UND-verknüpft werden, sind in Tabelle 4-1 angegeben. Zum Auswerten
des ACK-Bits wird die TCP-Flag-Variable mit der Binärzahl 10000b (entspricht der
Zahl 32 im Dezimalsystem) UND-verknüpft. Bei gesetztem ACK-Bit, ist das Ergebnis
38
Kapitel 4
Das Programm
der Verknüpfung eins und das entsprechende Kontroll-Bit wird im Programm gesetzt
und für das Paket zwischengespeichert. Dasselbe Verfahren wird auf das SYN- und das
FIN-Bit angewendet.
Flag X1 MSB X2
ACK 0
1
0
0
0
X6 LSB
0
SYN
FIN
0
0
0
0
1
0
0
1
0
0
0
0
X3
X4
X5
Tabelle 4-1: Binärzahlen der logischen UND-Verknüpfung mit dem TCP-Flags
4.5.4 Timeout-Abfrage
In realen Anwendungen findet die Timeout-Abfrage bei TCP- und UDP-Verbindungen
für jede Verbindung einzeln statt. Das bedeutet, dass der auf das nächste Paket wartende Teilnehmer einer Verbindung, die Verbindung für geschlossen erklärt, wenn
eine bestimmte Wartezeit (timeout period, [STE94]) überschritten wird. Da es aber für
das direkte Übernehmen dieser Methode nötig wäre, für alle offenen Verbindungen
eine Stoppuhr laufen zu lassen, ist es hier einfacher diese Abfrage etwas anders zu
gestalten.
Bevor im Programm ein Paket zugeordnet wird, findet sowohl bei einer UDP- als auch
bei einer TCP-Verbindung eine sogenannte Timeout-Abfrage (vgl. Abbildungen 4-10
und 4-12) statt. Hierbei wird der Timestamp des aktuellen Paketes sukzessive mit dem
Timstamp des letzten Paketes jeder offenen Verbindung verglichen. Ist die Differenz
beider Timestamps größer als die erlaubte Wartezeit (TCP- bzw. UDP-timeout period),
wird die Verbindung der das Paket angehört geschlossen. Der Timestamp des aktuell
betrachteten Paketes stellt die globale Uhr für alle offenen Verbindungen dar und das
Mitlaufen von Timern für jede Verbindung ist somit überflüssig. Die Timeout-Abfrage
muss stattfinden um ein Timeout zu erkennen. Es beschleunigt gleichzeitig die Analyse, da geschlossene Verbindungen nicht weiter betrachtet werden. Diese Verbindungen gehen als nicht vorschriftsmäßig abgebaut in die Statistik ein.
4.5.5 Einsortierung der TCP-Pakete
Die TCP-Pakete werden innerhalb ihrer Verbindungen an Hand der Sequenz- oder der
Acknowledgenummer sortiert. Beim Einlesen neuer Pakete werden zwei Fälle unterschieden:
1. Das letzte Paket der Verbindung und das neue haben denselben Sender und
Empfänger.
2. Sender und Empfänger der beiden Pakete sind vertauscht.
39
Kapitel 4
Das Programm
Im ersten Fall wird die Sequenznummer beider Pakete verglichen. Ist die des aktuellen
Paketes größer, ist die Reihenfolge richtig und das Paket kann eingelesen werden.
Im zweiten Fall wird die Acknowledgenummer des aktuellen Paketes mit der Sequenznummer des letzen Paketes verglichen. Ist die Acknowledgenummer größer als
die Sequenznummer, ist die Reihenfolge ebenfalls richtig und das Paket kann eingelesen werden.
Sind die Pakete nicht in der korrekten Reihenfolge angekommen, muss die richtige
Position des aktuellen Paketes in der Verbindung gesucht werden. Dazu wird die
Sequenz- bzw. Acknowledgenummer des Paketes sukzessive mit denen aller Pakete
der Verbindung verglichen. Beim letzen Paket der Verbindung beginnend, werden bei
jeden Schritt jeweils die beiden Fälle unterschieden und die entsprechenden Nummern
verglichen, bis die richtige Position gefunden worden ist. Mittels der Funktion insert()
wird das Paket dann an der richtigen Stelle in die Verbindung eingelesen.
Beim Vergleich der Sequenz- und Acknowledgenummern unter- und miteinander
muss der „Nulldurchgang“ der Zahlenwerte besonders beachtet werden. Dies bedeutet,
dass nach der Nummer 232-1 die Nummern 0-1-2 usw. folgen. Dies ist wichtig für die
Einsortierung der Pakete, da diese Pakete zwar einen kleineren Zahlenwert besitzen,
aber in der Reihenfolge trotzdem hinter den vorherigen Paketen liegen. Die
Schwierigkeit besteht in der Unterscheidung, ob bei der Sequenz- und/oder Acknowledgenummer ein Nulldurchgang stattgefunden hat oder das Paket nur in falscher
Reihenfolge in der Quell-Datei vorliegt. Ist die Differenz zweier Sequenz- bzw.
Acknowledgenummern einer Verbindung zu hoch um für die Anzahl der Pakete einer
Verbindung realistisch zu sein, wird davon ausgegangen, dass ein Nulldurchgang
stattgefunden hat. Zur Unterscheidung wird im Programm ein Schwellwert gewählt
(treshold). Wie in Gleichung 4.1 a)-d) zu sehen, werden vier Fälle unterschieden. Die
Gleichung 4.1 a) und c) werden verwendet, wenn der oben beschriebene erste Fall
(Sender und Empfänger gleich) vorliegt, die Gleichung 4.1 b) und d) entsprechend
beim zweitem.
a) ∆(Seqn, Seqcur) < t
Gleichung 4.1 a)-d)
b) ∆(Seqn, Ackcur) < t
c) ∆(Seqn, Seqcur) > t
d) ∆(Seqn, Ackcur) > t
Es wird jeweils die Differenz zwischen der Sequenznummer des letzten Paketes der
Verbindung und der Sequenznummer bzw. der Acknowledgenummer des aktuellen
gebildet und mit dem Schwellwert t verglichen. Ist die Differenz kleiner als der
Schwellwert (Gleichung 4.1 a) und b)) liegt der Normalfall vor und die entsprechen40
Kapitel 4
Das Programm
den Zahlen werden verglichen und aufsteigend einsortiert. Ist sie kleiner, liegt ein
Nulldurchgang vor und die Zahlen werden absteigend geordnet.
Da Pakete zwischendurch fehlen können, muss diese Abfrage bei der Einsortierung
sukzessive mit jedem Paket durchgeführt werden, bis die korrekte Position gefunden
worden ist.
4.5.6 Berechnung der Anzahl der Pakete einer TCP-Verbindung
Um die Anzahl der Pakete einer TCP-Verbindung berechnen zu können, müssen
mindestens ein Paket des Verbindungsaufbaus und eins des Verbindungsabbaus vorhanden sein, da sonst jegliche Bezugspunkte fehlen.
Stimmen die IP-Adressen des Senders und Empfängers des ersten und letzten Paketes
der Verbindung überein, berechnet sich die Anzahl der Pakete nach Gleichung 4-2.
2 ∆( Seq1, Seqn ) + 1 + µ
Gleichung 4-2
Wobei ∆(Seq1,Seqn) die Differenz der Sequenznummern des 1. und des letzen Paketes
bezeichnet. Die Variable µ, im Programmcode missingEnd genannt, berechnet sich aus
der Anzahl der fehlenden Pakete vor dem ersten und hinter dem letzten aufgezeichneten Paket der Verbindung. Dies können das 1. Paket oder das 1. und 2. Paket des
Verbindungsaufbaus und/oder das letzte Paket des Verbindungsabbaus sein.
Sind die IP-Adressen des Senders und Empfängers beim letzen und ersten Paket
vertauscht berechnet sich die Anzahl nach Gleichung 4-3.
2 ∆( Ackn, Seq1) + µ
Gleichung 4-3
Der Term ∆(Ackn,Seq1) bezeichnet in diesem Fall die Differenz der
Acknowledgenummer des letzen und der Sequenznummer des ersten Paketes.
Die Anzahl der fehlenden Pakete einer Verbindung kann anschließend aus der
Differenz der gerade bestimmten Anzahl der TCP-Pakete und der Anzahl der protokollierten Pakete der Verbindung bestimmt werden
Fehlen alle Pakete des Verbindungsaufbaus oder -abbaus ist keine Aussage über die
Anzahl der Pakete möglich. In diesem Fall kann auch nicht die Anzahl der fehlenden
Pakete berechnet werden.
41
Kapitel 5
Tests
5 Tests
Während der Programmierphase sind alle neuen Funktionen umgehend mit einer
entsprechend präparierten Quell-Datei getestet worden.
Zunächst ist das zeilenweise Auslesen der Quell-Datei mit einer gekürzten Datei (10
Pakete) getestet worden. Zur Überprüfung sind die eingelesenen Zeilen unverändert im
Ausgabefenster ausgegeben worden. Diese Funktionalität steht noch, bei Markierung
des entsprechenden Kontrollkästchens (Show Sourcefile), zur Verfügung.
Die Funktionen FrameAnalyse und AnalyseIPHeader, in der die Protokollzähler
inkrementiert werden, ist mit Hilfe einer Quell-Datei getestet worden, in der jedes
bekannte Protokoll sowie jeweils ein unbekanntes mindestens einmal vorgekommen
ist. Durch Ausgabe aller Zählerstände konnte die Funktionalität direkt überprüft
werden.
Da die Behandlung von UDP-Paketen einfacher als die von TCP-Paketen ausfällt, ist
zunächst die Erzeugung von UDP-Verbindungen und die Einordnung der UDP-Pakete
implementiert und getestet worden. Hierzu wird erst eine Quell-Datei mit mehreren
UDP-Verbindungen und jeweils einen zugehörigen Paket verwendet. Die im
Ausgabefenster ausgegebenen UDP-Verbindungen konnten sofort mit der Quell-Datei
verglichen werden. Anschließend ist die verwendete Test-Datei modifiziert worden,
um alle einzelnen Abfragen der Funktion AnalyseUDPConnection zu überprüfen.
Dazu gehören die Zugehörigkeit der Pakete zur gleichen Verbindung bei gleicher und
vertauschter Sender-Adresse (IP-Senderadresse und Sendeport) und EmpfängerAdresse (IP-Empfängeradresse und Empfangsport) sowie die Überprüfung eines
Timeouts der einzelnen Verbindungen.
Nach Implementierung der Funktion AnalyseTCPConnection sind dieselben
Funktionalitäten wie bei den UDP-Verbindungen mit entsprechend angepasster QuellDatei überprüft worden. Zusätzlich ist die korrekte Einordnung der Pakete innerhalb
einer Verbindung getestet worden. Dazu sind die Acknowledge- und Sequenznummern der TCP-Pakete innerhalb der verwendeten Test-Datei variiert worden. Erste
Tests haben ergeben, dass der Zahlenbereich dieser Nummern zu gering gewählt
worden ist und deshalb ein Variablen-Typ mit grösseren Wertebereich erforderlich ist.
Die Nummern sind anschließend innerhalb der Test-Datei so gewählt worden, dass
teilweise Pakete gefehlt und/oder in der falschen Reihenfolge vorgelegen haben.
Abschließend ist noch der Nulldurchgang der laufenden Sequenz- und/oder Acknowledgenummer unter gleichen Bedingungen getestet worden.
Nach Fertigstellung des Programms sind zwei abschließende Tests zur Überprüfung
der Gesamtfunktionalität durchgeführt worden. Erstens mit einer selbsterstellten
Quell-Datei die alle Protokolle und alle oben aufgeführten Fälle gemeinsam enthält
42
Kapitel 5
Tests
und zweitens mit einer von der Monitoringsoftware erzeugten Quell-Datei, die real
aufgezeichneten Datenverkehr eines Netzwerks enthält. Letztere Datei ist wesentlich
länger (10.000 Pakete) als die zuvor präparierten Test-Dateien und konnte somit
gleichzeitig zur Kontrolle der Analysegeschwindigkeit des Programms herangezogen
werden.
43
Kapitel 6
Resümee und Ausblick
6 Resümee und Ausblick
Das Programm ConnectionChecker analysiert bisher TCP- und UDP-Verbindungen
mittels dynamischer Speicherverwaltung im Detail, alle anderen Protokolle werden
bisher nur rudimentär behandelt. Auf Grund der dynamischen Speicherverwaltung
werden die im Programm verwendeten Listen automatisch in ihrer Größe angepasst.
Das bedeutet, die Anzahl der Verbindungen und Texte muss vor der Analyse nicht
festgelegt werden. Außerdem gewährleistet sie eine optimale Speicherplatzverwaltung.
Die Analyse der Quell-Datei findet zur Laufzeit statt, das bedeutet, die Datei muss
nicht erst komplett ausgelesen werden. Es wird zeilenweise ausgelesen und direkt
analysiert, so dass nur Daten relevanter Zeilen, hier Pakete der TCP- und UDPVerbindungen, gespeichert werden und die Analyse der anderen sofort abgebrochen
wird. Auf Grund der dynamischen Speicherverwaltung und der Laufzeitanalyse wird
das Programm hinsichtlich des Speicherplatzes und Laufzeit optimiert. Die allgemein
gehaltene Programmstruktur, ermöglicht das Programm leicht zu erweitern und
einzelne Komponenten, z.B. für andere Verbindungsprotokolle, wiederzuverwenden.
Wie schon in vorherigen Kapiteln angedeutet, ist die Erweiterung und/oder Modifikation des Programms ConnectionChecker an einigen Stellen möglich und sinnvoll.
Eine mögliche Erweiterung wäre, die Erkennbarkeit von genutzten Diensten auf eine
größere Anzahl auszuweiten. In der aktuellen Version des Programms wird in der
Funktion AnalyseService nur zwischen HTTP, FTP und sonstige Dienste unterschieden. Die Liste der Dienste kann leicht erweitert werden, da diese an Hand des „wellknown-ports“ mittels einer case-Abfrage unterschieden werden.
In der aktuellen Programm-Version ist die Behandlung der offenen Verbindungen bei
abgeschlossener Analyse einer Quell-Datei noch unbehandelt. Eine Quell-Datei enthält
eine Anzahl von Paketen, die über eine gewisse Zeitdauer im Netzwerk aufgezeichnet
worden sind. Die Quell-Datei enthält nur einen gewissen Ausschnitt des Netzwerkverkehrs ohne Anspruch auf Vollständigkeit der aufgezeichneten Verbindungen. Die
protokollierten Verbindungen können sich somit über mehrere Quell-Dateien erstrecken. Aus diesem Grund wäre es wünschenswert, dass mehrere Quell-Dateien hintereinander analysiert werden können und offene Verbindungen für die nächste QuellDatei weiter zur Verfügung stehen. Nur so können Pakete derselben Verbindung, die
aber in einer späteren Quell-Datei aufgezeichnet worden sind, auch der gleichen
Verbindung zugeordnet werden. Um diese Erweiterung zu ermöglichen, behalten
derzeit Verbindungen mit noch fehlenden Paketen, die kein Timeout erhalten haben,
ihren Status als offene Verbindung bei.
Eine weitere Verbesserung wäre das Speichern der Analyse-Ergebnisse in einer neuen
Datei. Die Ergebnisse werden im aktuellen Programm nur auf dem Bildschirm aus44
Kapitel 6
Resümee und Ausblick
gegeben, wobei bei Abspeicherung der Werte auch später auf vergangene Ergebnisse,
z.B. zum Vergleich, zurückgegriffen werden könnte.
Auch die einfach gehaltene GUI könnte in ihrer Funktionalität erweitert werden. Mit
Auswahl der zu analysierenden Quell-Dateien, Ein- bzw. Ausblendung von bestimmten Analyseergebnissen und zusätzlichen Funktionen.
Für die Zukunft absehbar ist, dass eine neue Version der Programmierumgebung die
Möglichkeit einer höheren Auflösung des Zeitstempels mit sich bringt. Der als CTimeVariable abgespeicherte Timestamp kann in der derzeitigen Version nur sekundengenau behandelt werden. Dies ist für die aufgezeichneten Pakete nicht ausreichend,
da die Übertragungsgeschwindigkeiten eine genauere Auflösung erfordern.
45
Kapitel 7
Literatur
7 Literatur
[BAU99]
Baumann, Heiko
Entwicklung eines Softwaretools zur Protokollierung und Analyse des
Datenstroms in Netzwerken
Diplomarbeit D344, Lehrstuhl für Datenverarbeitung
Ruhr-Universität Bochum, 1999
[CHA98]
Chapman, Davis
Visual C++6 in 21 Tagen
Haar bei München :SAMS, 1998
[CHE96]
Cheswick, William R. / Bellovin, Steven M.
Firewalls und Sicherheit im Internet
Schutz vernetzter Systeme vor cleveren Hackern
Addison-Wesley, Bonn, 1996
[DET97]
Deutsche Telekom
Glossar, Begriffe aus der Welt der Netze
http://www.t-lan.de/GLOSSAR/
[DRO02]
Droste, Thomas / Ruhl, Alexander
Aufgaben bei verteilter Datenakquisition und dessen Zusammenführung
für die Analyse
In: Horster, Patrick: Enterprise Security 2002
IT-Verlag, 2002
[JUN00]
Junker, Holger
TCP und UDP
Institut für Rechnerentwurf und Fehlertoleranz,
Proseminar Rechnerkommunikation und Telefon
Universität Karlsruhe, WS 2000/2001
http://goethe.ira.uka.de/seminare/rkt/tcp+udp/
[KAD01]
Kaderali,. Firoz
Network Security
Skript zur Vorlesung
Fernuniversität Hagen, 02.05.2001
46
Kapitel 7
Literatur
[KAUF99]
Kauffels, Franz-Joachim
Lokale Netze
MITP-Verlag GmbH, Bonn, 1999
[LIE01]
Lienemann, Gerhard
TCP/IP-Praxis
Dienste, Sicherheit, Troubleshooting, Kapitel 1: TCP/IP im Internet
Heinz Heise Verlag, März 2001
http://www.dpunkt.de/leseproben/3-88229-184-2/Kapitel_1.pdf
[PFL01]
Pfliegl, Konstantin
So funktioniert TCP/IP
tecChannel-Artikel vom 02.11.2001
http://www.tecchannel.de/internet/209/index.html
[POS81]
Postel, Jon
RFC: 791: Internet Protocol
Information Sciences Institute
University of Southern California, September 1981
http://www.ietf.org/rfc/rfc0791.txt
[POT81]
Postel, Jon
RFC: 793: Transmission Control Protocol
Information Sciences Institute
University of Southern California, September 1981
http://www.ietf.org/rfc/rfc0793.txt
[PRA92]
Prata, Stephen
C++
Einführung in die objektorientierte Programierung
Te-wi Verlag (Waite Group), 1992
[REB01]
Reibold, Holger
Hypertext Transfer Protocol
tecChannel-Artikel vom 30.08.2001
http://www.tecchannel.de/internet/208/index.html
47
Kapitel 7
[REI01]
Literatur
Reibold, Holger
File Transfer Protocol
tecChannel-Artikel vom 05.01.2000
http://www.tecchannel.de/internet/207/index.html
[REY94]
Reynolds, J. / Postel, J.
RFC: 1700: Assigned Numbers
ISI, Oktober 1994
http://www.ietf.org/rfc/rfc1700.txt
[STE94]
Stevens, W. Richard
TCP/IP, Illustred, Volume 1
Addison-Wesley, Reading, 1994
[THO99]
Thormählen, Thorsten
Entwicklung einer Internetkamera und deren Anbindung über PPP und
TCP/IP an das ISDN
Diplomarbeit, Fachgebiet Elektronische Bauelemente und Schaltungen
Gerhard-Mercator-Universität-Gesamthochschule Duisburg, 1999
http://www.thormahlen.de/diplhtml/thor_pri.html
[WAS94]
Washburn, Kevin / Evans, Jim
TCP/IP
Aufbau und Betrieb eines TCP/IP-Netzes
Addison-Wesley, Bonn, 1994
[WEB92]
Weber, Wolfgang / Alef, Andreas
Grundlagen der Datenverarbeitung
Lehrstuhl für Datenverarbeitung
Ruhr-Universität-Bochum, Bochum, 1992
[ZIT96]
Zitterbart, M.
Telematik 1
Skript Kapitel 8: Internet
Institut für Telematik, Universität Karlsruhe 1996
http://www.telematik.informatik.uni-karlsruhe.de/lehre/alt/vorlesungen/Tele1Folien_WS9697/K8-Inter/index.htm
48