Analyse eines verteilten Datenstromes auf Vollständigkeit · Die Analysesoftware ist mit MS Visual C++ unter MS Windows NT/2000 zu realisieren. Alle Entwicklungsschritte sind zudem

Studienarbeit S293

Analyse eines verteilten Datenstroms auf Vollständigkeit

In einem lokalen Netz ist es möglich mittels einer verteilten Datenakquisition ein Abbilddes gesamten Datenverkehrs zu erhalten. Folglich kann die Kommunikation zwischeneinzelnen Systemen nicht nur lokal an den beiden kommunizierenden Systemen, sondernzusätzlich dezentral rekonstruiert werden.

Ziel dieser Arbeit ist es, verteilt aufgenommenen Datenstrom bzgl. der Vollständigkeit zuanalysieren. Dabei ist zwischen physikalischer und logischer Vollständigkeit zudifferenzieren. Physikalische Vollständigkeit bedeutet die Prüfung, ob alle transferiertenDatenpakete real aufgezeichnet worden sind. Logische Vollständigkeit bezieht sich aufdie Einhaltung einer definierten Kommunikation (Ablaufkontrolle) bzw. Einhaltung derProtokollsyntax.Für die Analyse ist es notwendig, den Gesamtdatenstrom in verschiedene Verbindungensequenziell zu klassifizieren. Fehlende Pakete müssen erkannt werden, ebensoVerbindungen, welche lückenhaft oder unvollständig sind. Hierzu sind geeigneteKriterien am Beispiel von TCP- und UDP-Verbindungen zu entwickeln und umzusetzen.Das Ergebnis soll in eine Statistik die analysierten Pakete mit den entsprechendenVerbindungen 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)

Lehrstuhl fürDatenverarbeitungProf. Dr.-Ing. Dr. E.h. Wolfgang Weber

Bearbeiter: cand.-Ing. Katrin HöperMatrikel-Nummer: 108 096 210 773Betreuer: Dipl.-Ing Thomas DrosteBearbeitungszeitraum: SS 2001 – WS 2001/02

Inhalt

1

Inhalt

1 Motivation ...............................................................................................................32 Grundlagen ..............................................................................................................4

2.1 Transmission Control Protocol/Internet Protocol ...............................................42.1.1 Einordnung in die Schichtenmodelle...........................................................42.1.2 Interaktionen der Protokollinstanzen...........................................................5

2.2 Das Internet Protocol...........................................................................................62.3 Das Transmission Control Protocol ....................................................................9

2.3.1 Verbindungsablauf ....................................................................................102.4 Das User Datagram Protocol.............................................................................132.5 Das Hypertext Transfer Protocol ......................................................................142.6 Das File Transfer Protocol ................................................................................14

3 Die Quell-Datei .....................................................................................................163.1 Aufbau...............................................................................................................163.2 Auswertung .......................................................................................................22

4 Das Programm.......................................................................................................234.1 Ablauf................................................................................................................234.2 Behandlung von Verbindungen und Paketen....................................................25

4.2.1 TCP-Verbindungen und Pakete.................................................................254.2.2 UDP-Verbindungen und Pakete ................................................................27

4.3 Die Analysefunktionen......................................................................................294.3.1 Analyse des allgemeinen Frame-Headers .................................................294.3.2 Analyse des IP-Headers.............................................................................294.3.3 Analyse des TCP-Headers und der dazugehörigen Verbindung...............304.3.4 Analyse des UDP-Headers und der dazugehörigen Verbindung ..............33

4.4 Die Ausgabe ......................................................................................................344.4.1 Protokollzähler...........................................................................................354.4.2 Analysierten Verbindungen.......................................................................35

4.5 Funktionen.........................................................................................................374.5.1 Auslesen der Parameter der Quell-Datei ...................................................374.5.2 Formatkonvertierung .................................................................................384.5.3 Auswertung der TCP-Flags .......................................................................384.5.4 Timeout-Abfrage .......................................................................................394.5.5 Einsortierung der TCP-Pakete...................................................................394.5.6 Berechnung der Anzahl der Pakete einer TCP-Verbindung .....................41

5 Tests ......................................................................................................................42

Inhalt

2

6 Resümee und Ausblick..........................................................................................447 Literatur.................................................................................................................46

Kapitel 1 Motivation

3

1 Motivation

Ziel dieser Studienarbeit ist es, den von einer Monitoringsoftware protokolliertenDatenstrom eines lokalen Netzes auszuwerten. Die Monitoringsoftware erstellt mittelseiner verteilten Datenakquisition ein Abbild des gesamten Datenverkehrs. Dabei trenntsie die Protokoll-Header von den übermittelten Daten und schreibt die so extrahiertenInformationen in eine Datei, welche die Grundlage für weitere Verarbeitungen undAnalysen, und somit auch für diese Arbeit, bildet. Die so protokollierten Ver-bindungen 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 Paketenexistieren sollten. Aus der von der Monitoringsoftware generierten Datei kann unteranderem abgeleitet werden, welches Protokoll wie häufig verwendet worden ist undwieviele Verbindungsaufbauversuche zustande gekommen oder erfolglos gebliebensind.Die Analyse soll fehlende Pakete sowie lückenhafte oder unvollständigeVerbindungen erkennen. Hierzu müssen entsprechende Algorithmen entworfenwerden, welche die Eigenschaften von TCP1- und UDP2-Verbindungen zur Unter-suchung der protokollierten Verbindungen ausnutzen.Da das TCP und das UDP die wohl am häufigsten verwendeten Protokolle inComputernetzen sind und sowohl HTTP3 als auch FTP4 diese als Grundlage für ihreVerbindungen verwenden, gibt die Betrachtung dieser beiden Services einen gutenÜberblick über die Funktionsfähigkeit der Monitoringsoftware. Aus demselben Grundkann die Analyse auch zur statistischen Auswertung der Zuverlässigkeit der Ver-bindungen im Netzwerk herangezogen werden.

1 TCP - Transmission Control Protocol2 UDP - User Datagram Protocol3 HTTP - Hyper Text Transfer Protocol4 FTP - File Transfer Protocol

Kapitel 2 Grundlagen

4

2 Grundlagen

2.1 Transmission Control Protocol/Internet Protocol

Die TCP/IP-Protokollfamilie bildet die Grundlage für das Internet, denn sie ermöglichtdie weltweite Kommunikation in heterogenen Netzen. TCP/IP steht für eine Reihe vonProtokollen, der so genannten „Internet Protocol Suite“. Zu den größten Vorteilen beider Nutzung von TCP/IP- Protokollen gehören das einheitliche Adressierungsschemaund die standardisierte Schnittstelle (API - Application Program Interface) zu Anwen-dungsprogrammen. Die beiden wichtigsten Protokolle TCP und IP sind zum Synonymfür diese Familie geworden.

2.1.1 Einordnung in die SchichtenmodelleIn der Abbildung 2-1 ist die Einordnung einiger Internetprotokolle der TCP/IP-Protokollfamilie in das TCP/IP-Schichtenmodell dargestellt. Auf der linken Seite derAbbildung wird das Modell auf das ISO/OSI5-Schichtenmodell abgebildet, welchesaus sieben Schichten besteht. Es ist üblich in TCP/IP-Netzen das TCP/IP-Schichten-modell zu verwenden, da es nur in vier Schichten unterteilt und für diese Gruppe vonVerbindungen ausgelegt ist. Die für eine spätere Analyse betrachteten Protokolle sindgrau hervorgehoben.Das Address Resolution Protocol (ARP) unterstützt die Zuordnung von IP-Adressen inder Internetschicht (bzw. der Vermittlungsschicht im ISO/OSI-Schichtenmodell) zuden entsprechenden Adressen der darunterliegenden Schicht. Wobei das ReverseAddress Resolution Protocol (RARP) die Umkehrfunktion dieses Protokolls zurVerfügung stellt.Obwohl das Internet Control Message Protocol (ICMP) und das Internet GroupManagement Protocol (IGMP) den IP-Dienst nutzen, werden sie dennoch derVermittlungsschicht im ISO/OSI- und der Internetschicht im TCP/IP-Schichtenmodell(jeweils Schicht 3) zugeordnet. ICMP unterstützt den Austausch von Kontroll-informationen innerhalb dieser Schicht. IGMP ist für die Verwaltung von Kommuni-kationsgruppen zuständig.Die anwendungsbezogenen Schichten 5-7 im ISO/OSI-Schichtenmodell (Kommunika-tionssteuerungs-, Darstellungs-, Anwendungsschicht) werden im TCP/IP-Schichten-

5ISO / OSI - International Standardization Organization / Open Systems Interconnection


5

modell zu einer Anwendungsschicht zusammengefasst. Ihr werden z.B. Protokolle wieFTP, Telnet, HTTP oder SMTP6 zugeordnet, die im Internet eingesetzt werden.

Abbildung 2-1: Die Internetprotokolle im TCP/IP-Schichtenmodell auf dasISO/OSI- Schichtenmodell abgebildet

2.1.2 Interaktionen der ProtokollinstanzenIn Abbildung 2-2 sind die Interaktionen der im Kapitel 2.1.1 vorgestelltenInternetprotokolle im TCP/IP-Schichtenmodell dargestellt. Die für die spätere Analysebetrachteten Protokolle sind grau hervorgehoben. Eine Kommunikation findet sowohlzwischen den Schichten (hier zwischen den Schichten eins und zwei, sowie zwischenSchicht 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 folgtskizziert werden: Die TCP- bzw. UDP-Instanz übergibt die zu übermittelnden Datenzusammen mit der IP-Adresse des Empfängers (der genaue Ablauf sowie diedetaillierte Beschreibung der Protokolldaten folgt in Kapitel 2.3 und 2.4) an die IP-Instanz innerhalb der Internetschicht. Hier beauftragt die IP-Instanz die ARP-Instanz

6 SMTP - Simple Mail Transfer Protocol

AnwendungsbezogeneSchichten

Transportschicht

Vermittlungsschicht

5 - 7

4

3

TCP UDP

IGMP ICMP

IP

ARP RARP

1-2

Datensicherungs- &Bitübertragungsschicht

Anwendungsschicht

4

Transportschicht

3

Internetschicht

2

1physikalische Schicht

...

HTTP

FTP

Telnet


6

mit der Ermittlung der entsprechenden MAC7-Adresse. Diese wird zusammen mit denDaten und weiteren Protokolldaten an die darunterliegende Sicherungsschicht über-geben. Andersherum reicht die IP-Instanz empfangene Pakete an die TCP- bzw. UDP-Instanz weiter.Probleme während der Übermittlung können den Partenerinstanzen über ICMP-Mel-dungen mitgeteilt werde, wobei das IP zur Übertragung benutzt wird. Zur Übermitt-lung von Informationen über Gruppenzugehörigkeiten mittels IGMP wird ebenfallsdas IP genutzt.

Schicht 1physikalische Schicht

UDP

ICMP

IGMPIP

TCP

Schicht 4Anwendungsschicht

ARP

RARP

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-Protokoll-familie und stellt die Grundlage zur Übermittlung von Daten zwischen Geräteeinheitenin Netzwerken dar. Verbindungslos bedeutet, dass dieses Protokoll keinen Verbin-dungszustand kennt. Es ist also nicht notwendig, eine IP-Verbindung zu einemRechner zu "öffnen", bevor Daten zu diesem Rechner gesendet werden können. DerVerbindungsaufbau und -abbau gehören nicht in den Zuständigkeitsbereich diesesProtokolls.

7 MAC - Media Access Control


7

Die Hauptaufgabe des IP ist es die Unterschiede zwischen den verschiedenen darunterliegenden Netzwerkschichten zu verbergen und eine einheitliche Sicht auf die ver-schiedensten Netzwerktechnologien zu präsentieren. Eine weitere Aufgabe ist die Er-mittlung und Realisierung des optimalen Weges zwischen Sender und Empfänger fürjedes Datenpaket. Um dies zu ermöglichen, werden vom IP ein einheitliches Adres-sierungsschema und ein Fragmentierungsmechanismus, der es ermöglicht großeDatenpakete durch Netze mit kleiner maximaler Paketgröße zu senden, genutzt.Das IP-Paket kann ohne vorherige Verhandlungen mit dem Empfänger direkt an ihnversandt werden. Es gibt keine Garantie, dass das versandte Paket beim gewünschtenEmpfänger ankommt. Verlorene Pakete werden nicht automatisch neu versandt. Auchdie Reihenfolge in der dieser Empfänger die Pakete erhält, muss nicht der Reihenfolgeentsprechen, in der die Pakete verschickt worden sind. Es kann passieren, dass auf demÜbertragungsweg IP-Pakete verloren gehen oder mehrfach ankommen. Sind Dienstewie Ende-zu-Ende-Datensicherheit, Flußkontrolle, Datenabfolge und/oder Fehler-erkennung erwünscht, müssen zusätzlich Protokolle aus höheren Schichten eingesetztwerden.In Abbildung 2-3 ist der IP-Header abgebildet, wobei die in der Quell-Datei auf-gezeichneten Felder grau hervorgehoben sind. Im weiteren werden diese Felder kurzerläutert. Für weiterführende Informationen zu diesem Thema sei auf [PFL01] und[POS81] verwiesen.

1 4 8 12 16 20 24 28 32Version IHL TOS Paketlänge

Identifikation Flags FragmentabstandTTL Protokoll Prüfsumme

IP–SenderadresseIP–Empfängeradresse

Optionen Füllzeichen

Abbildung 2-3: IP-Header

• VersionIn diesem 4 Bit grossem Feld befindet sich die Versionsnummer des verwendetenInternet 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ängewird in 32-Bit-Worten angegeben und ist abhängig von der Größe des Optionen-Feldes.


8

• Type of Service (TOS)Das TOS-Feld ist 8 Bit lang. In ihm können mehrere Service-Qualitäten (Quality ofService) festgelegt werden. Es wird zwischen low-delay, high-reliability und high-throughput unterschieden. Durch diese Klassifizierung können Diensten verschie-dene Prioritäten zugeordnet werden.

• FlagsDieses Feld ist drei Bit lang und enthält drei Kontroll-Flags. Das 1. Bit (MSB8) istreserviert und immer gleich null gesetzt. Das 2. Bit gibt an, ob fragmentiert werdendarf (=0) oder nicht (=1). Das 3. Kontroll-Flag ist gleich null, wenn es sich beimPaket um das letzte Fragment handelt und gleich eins, wenn noch weitereFragmente folgen.

• Time to Live (TTL)Das TTL-Feld ist 8 Bit lang. Es zeigt die maximale Zeit an, die ein Datenpaket ineinem Netzwerk existieren darf. Jede Station, die das Datenpaket bearbeitet (z.B.weiterleitet), dekrementiert die TTL. Wird der Wert null erreicht, wird das Paketverworfen.

• ProtokollDas 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ändigeListe aller zugeordneten IP-Nummern ist in [REY94] angegeben.

Nummer Protokoll1 ICMP2 IGMP6 TCP17 UDP89 OSPF

Tabelle 2-1: IP nutzende Protokolle

• IP-SenderadresseDas 32 Bit lange Feld enthält die IP-Adresse des Senders.

• IP-EmpfängeradresseDieses 32 Bit lange Feld enthält die IP-Adresse des Empfängers.

8 MSB - Most significant bit / LSB - Least significant bit


9

2.3 Das Transmission Control Protocol

Das Transmission Control Protocol (TCP) unterstützt im Gegensatz zum IP eine zu-verlässige, verbindungsorientierte Datenübertragung. Verbindungsorientiert bedeutet,dass das Protokoll eine logische Ende-zu-Ende-Verbindung herstellt. Das hohe Maß anZuverlässigkeit wird durch Bestätigungs-, Flusskontroll-, Zeitüberwachungs- und Ver-bindungssteuerungsmechanismen erreicht. Die transferierten Dateneinheiten (Pakete)bestehen aus einem mindestens 20 Byte großen Protokollkopf und den zu über-tragenden Nutzdaten. In jedem Paket ist eine Prüfsumme zur Fehlerkontrolle der Datenenthalten. Im Falle einer fehlerfreien Übertragung sendet der Empfänger eine Em-pfangsbestätigung an den Sender, andernfalls wird das Datenpaket verworfen undkeine Empfangsbestätigung verschickt.Wird nach einer bestimmten Zeitperiode (retransmission timeout, [STE94]) beimSender keine Empfangsbestätigung empfangen, verschickt der Sender das betreffendePaket erneut.In Abbildung 2-4 ist der TCP-Header abgebildet, wobei die für die Analyse ver-wendeten Felder grau hervorgehoben sind. Nähere Beschreibungen befinden sich unteranderem in [PFL01] und [POT81].

1 4 8 12 16 20 24 28 32Sendeport Empfangsport

SequenznummerAcknowledgenummer

Abstand Reserviert Kontrollbits FenstergrößePrüfsumme Urgent-Zeiger

Optionen Füllzeichen

Abbildung 2-4: TCP–Header

• SendeportDer Sendeport ist ein 16 Bit langes Feld, welcher die Portnummer der Quelldatenenthält. Für die spätere Analyse ist er von Bedeutung, da an Hand des Wertes ent-schieden werden kann, welcher Service bei der Verbindung benutzt wird oderwerden soll (vgl. Kapitel 2.5 und 2.6).

• EmpfangsportDer 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.


10

• SequenznummerDieses Feld ist 32 Bit lang und enthält eine Nummer mit deren Hilfe die Positioneines Paketes innerhalb eines Datenstroms bestimmt werden kann. Ausgehend vonder ersten Sequenznummer einer Verbindung, die zufällig gewählt wird, erhaltenalle darauffolgenden Pakete (desselben Senders) eine inkrementierte Sequenz-nummer. So können fehlende Pakte erkannt werden.

• AcknowledgenummerMit dieser ebenfalls 32 Bit langen Zahl wird die Sequenznummer des nächstenPaketes angegeben. Sie ist die inkrementierte Sequenznummer des letzten Paketesdes Kommunikationspartners. Gesendet wird die Acknowledgenummer als vom je-weiligen Empfänger. Beide Kommunikationspartner wählen jeweils eine zufälligeSequenznummer die von der jeweiligen anderen Partei bestätigt wird. Der genaueAblauf wird im Kapitel 2.3.1 erläutert.

• KontrollbitsDieses 6 Bit lange Feld dient zur Kontrolle der Übertragung. Die 6 Kontrollbitssind in Abbildung 2-5 aufgeführt, wobei die für die Analyse relevanten und ver-wendeten wieder grau hervorgehoben sind.

1 2 3 4 5 6URG ACK PSH RST SYN FIN

Abbildung 2-5: TCP-Kontrollbits

• Acknowledge (ACK)Das ACK -Bit ist gesetzt (= eins) wenn eine Anfrage zum Verbindungsaufbauoder -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. Istes gesetzt, handelt es sich um die Anfrage zur Beendung der aktuellen TCP-Verbindung.

2.3.1 VerbindungsablaufDie festen TCP-Verbindungen werden über ein Dreiwege-Handshake (three wayhandshake) aufgebaut. Über das Dreiwege-Handshake werden Steuerinformationenausgetauscht, welche die logische Ende-zu-Ende-Verbindung regeln. Auch der Abbaueiner TCP-Verbindung wird mittels eines Handshake-Protokolls realisiert.


11

In Abbildung 2-6 wird beispielhaft eine TCP-Verbindung zwischen einem Client undeinem Server skizziert. Die Verbindung wird allgemein in drei Phasen unterschieden:Verbindungsaufbau, Datenaustausch und Verbindungsabbau.

Abbildung 2-6: Beispielhafter Ablauf einer TCP-Verbindung

2.3.1.1 VerbindungsaufbauDer Aufbau einer TCP-Verbindung zwischen Sender und Empfänger (in der Abbil-dung 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.

Client Server

Sequencenr.: 456Acknowlegdenr.: beliebigSendeport: 1250Empfängerport:80

Sequencenr.: 789Acknowlegdenr.: 457Sendeport: 80Empfängerport:1250

Sequencenr.: 457Acknowlegdenr.: 790Sendeport: 1250Empfängerport:80

SYN=1 ACK=0 FIN=0

SYN=1 ACK=1 FIN=0

SYN=0 ACK=1 FIN=0

Sequencenr.: 457 + nAcknowlegdenr.: 790 + nSendeport: 1250Empfängerport:80

SYN=0 ACK=0 FIN=1

Sequencenr.: 790 + nAcknowlegdenr.:458 + nSendeport: 80Empfängerport:1250SYN=0 ACK=1 FIN=1

SYN=0 ACK=0 FIN=1

SYN=0 ACK=1 FIN=1

Sequencenr.: 458 + nAcknowlegdenr.: 791 + nSendeport: 1250Empfängerport:80

Verbindungsaufbau

Daten-

austauschV

erbindungsabbau


12

Im Beispiel aus Abbildung 2-6 möchte der Client eine Verbindung zum Server auf-bauen. Hierzu schickt er ein Paket mit gesetzten SYN-Bit an den Server. DieSequenznummer für das erste Paket wird zufällig gewählt und liegt zwischen 0 und232–1 (32 Bit). Der Wert für die Acknowledgenummer des ersten Paketes ist ebenfallszufällig, im weiteren Verlauf jedoch unwichtig und deshalb in der Abbildung alsbeliebig bezeichnet. Der Sendeport des Clients liegt standardmäßig zwischen 1024 und5000, im Beispiel bei 1250. Der Empfangsport der ersten Nachricht gibt (imNormalfall) 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 Empfangs-port 80 bedeutet, dass der Client eine HTTP-Verbindung anfordert. Akzeptiert derEmpfänger die Anfrage, schickt er ein Antwortpaket an den Sender (Client) mit ge-setzten SYN- und ACK-Bit. Hierbei wählt er ebenfalls eine zufällige Sequenznummerzwischen 0 und 232-1. Im Acknowledgenummern-Feld des zweiten Paketes befindetsich die inkrementierte Sequenznummer des ersten Paketes (also des Absenders).Sende- und Empfangsport sind im Vergleich zum ersten Paket vertauscht, da auchSender und Empfänger nun ihre Rollen getauscht haben. Das dritte und somit letztePaket des Verbindungsaufbau quittiert wiederum den Erhalt des zweiten Paketes miteinem gesetzten ACK-Bit. Der Client inkrementiert seine eigene Sequenznummer undschreibt in das Acknowledgenummern-Feld die inkrementierte Sequenznummer desempfangenen (zweiten) Paketes. Sende- und Empfangsport sind wie beim ersten Paketgewählt. Mit dem dritten Paket ist der Verbindungsaufbau erfolgreich abgeschlossenund 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 dieSequenznummer können fehlende Pakete detektiert werden. Wird ein Paket nach einerbestimmten Zeit nicht bestätigt, wird es erneut versendet. Nach einer festgelegtenZeitspanne (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 eigeneSequenznummer, die beim senden des nächsten Paketes inkrementiert wird. Die Se-quenznummer des anderen wird inkrementiert und in das Feld für die Acknowledge-nummer geschrieben. Die Ports bleiben während der gesamten Verbindung unver-ändert und werden, je nach Rolle des Senders, getauscht.


13

2.3.1.3 VerbindungsabbauZum Beenden der TCP-Verbindung wird wiederum ein Handshake-Protokoll aus-geführt. Da TCP-Verbindungen fullduplex Verbindungen sind, dass heißt es wird inbeide Richtungen gesendet und beide Rechner können die Rolle des Senders oder Em-pfängers übernehmen, muss die Verbindung für beide Richtungen einzeln abgebautwerden. Dazu sendet der Teilnehmer, der die Verbindung beenden will, ein Paket mitgesetzten FIN-Bit. Der Empfänger bestätigt mit einem Paket bei dem sowohl das FIN-als 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 Ack-nowledgenummer und gesetztem FIN-Bit. Wird dieses letzte Paket wiederum mit ge-setztem ACK- und FIN-Bit bestätigt, ist die Verbindung erfolgreich für beide Rich-tungen abgebaut und die TCP-Sitzung wird geschlossen.

2.4 Das User Datagram Protocol

Das User Datagram Protocol (UDP) bietet höheren Protokollen einen definiertenDienst zum transaktionsorientierten Versand von Datenpaketen. Es setzt unmittelbarauf dem IP auf. Das UDP verfügt nur über minimale Protokollmechanismen zurDatenübertragung und bietet keine Ende-zu-Ende-Verbindung. Der Empfang desDatenpakets sowie der von Duplikaten kann nicht erkannt werden. Die korrekteReihenfolge der Datenpakete auf der Empfängerseite ist nicht gewährleistet. MinimaleProtokollmechanismen haben einen dementsprechend kurzen Paket-Header zur Folge.Daher wird UDP häufig als Datentransportdienst gewählt, wenn nur geringe Daten-mengen zu übertragen sind. Werden geringe Datenmengen mit dem TCP übertragen,kann es durchaus passieren, dass der Verwaltungsaufwand für die Herstellung derVerbindung und das Sicherstellen einer korrekten Übertragung größer ist, als derAufwand für eine erneute Übertragung der gesamten Daten. In Abbildung 2-7 ist derUDP-Header abgebildet, wobei die in der Quell-Datei protokollierten Felder grauhervorgehoben sind. Nähere Beschreibungen befinden sich unter anderem in [JUN00]und [PFL01].

1 4 8 12 16 20 24 28 32Sendeport EmpfangsportPaketlänge Prüfsumme

Abbildung 2-7: UDP-Header


14

• SendeportDer Sendeport ist ein 16 Bit großes Feld, welcher die Portnummer der Quelldatenenthält. Er gibt bei der späteren Analyse Aufschluss über den angeforderten oderbereits genutzten Dienst.

• EmpfangsportDer Empfangsport ist ein 16 Bit großes Feld, welcher den Zielport der Datenenthält. Er gibt wie der Sendeport Aufschluss über den genutzten Dienst währendder Verbindung. Beide Ports bleiben während der Verbindung unverändert.

• PaketlängeDie Paketlänge ist ein 16 Bit langes Feld, welche die Gesamtlänge, also Header-und Nutzdaten, des Paketes enthält.

2.5 Das Hypertext Transfer Protocol

Das Hypertext Transfer Protocol (HTTP) ist das wichtigste Transportprotokoll fürwebbasierte Inhalte. Dieses Protokoll ermöglicht die Übertragung von Information inForm von Internetseiten. Die Kommunikation zwischen Client und Webserver erfolgtdurch den Austausch von HTTP-Nachrichten. Diese übertragen die Anfragen undAntworten zwischen Sender und Empfänger. Zum Austausch der Nachrichten wird imStandardfall eine TCP-Verbindung auf Port 80, ein sogenannter „well-known-port“aufgebaut. Der Client schickt eine Anfrage an den HTTP-Port des Servers und dieserschickt seine Antwort an den Empfangsport des Clients, der im Normalfall zwischen1024 und 5000 liegt. Die Request und Response genannten Nachrichten bestehen imWesentlichen aus zwei Teilen: Header und Daten. Der Header enthält Steuer-informationen, wie zum Beispiel die verwendete Methode und den gewünschtenURL9. Der Datenabschnitt der Nachricht selbst besteht aus einem HTML10-Dokumentoder 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 zweiRechnern eingesetzt. Da nahezu jede Internetseite Dateien zum Download anbietet,besteht laut [REI01] ungefähr die Hälfte des gesamten Datenaufkommens im Internetaus FTP-Verbindungen. Das FTP baut zwischen Server und Client zwei Verbindungenauf. Die Erste, auch Steuerkanal genannt, dient ausschließlich der Übermittlung vonFTP-Kommandos und den zugehörigen Antworten, die Zweite als Datenkanal. Über

9 URL - Uniform Resource Locator10 HTML - Hypertext Markup Language


15

den Steuerkanal tauschen beide Seiten Kommandos aus, die dann eine Daten-übertragung über einen zweiten Kanal einleiten. Dabei werden in den Standardein-stellungen 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 Clientsden Befehlen des Servers, bis die Daten vollständig übertragen worden sind. Das FTPsieht dabei simultane Verbindungen vor. Die Kontrollverbindung muß während deskompletten Datentransfers bestehen bleiben.

Kapitel 3 Die Quell-Datei

16

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 Protokoll-daten und Verbindungsinformationen aller aufgezeichneten Pakete aufgeführt. DieProtokolldaten sind zuvor von den gesendeten Nutzdaten getrennt worden. Die Proto-koll-Header der verwendeten Protokolle werden dabei ausgewertet, Informationendaraus extrahiert und teilweise neu zusammengestellt.

3.1 Aufbau

Der allgemeine Aufbau der Datei wird mit Hilfe der Abbildungen 3-1 bis 3-12dargestellt. Dabei handelt es sich um sogenannte Syntaxdiagramme, in denen Recht-ecke als nicht-terminale und Kreise als terminale Symbole verwendet werden. Grauunterlegte 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 Verbindungaufgezeichneten Informationen. Dabei sind die einzelnen Informationen durch einSemikolon getrennt, nach dem letzten Feld folgt ein Zeilenumbruch.In Abbildung 3-1 wird der allgemeine Aufbau einer Zeile in der Quell-Dateidargestellt. Die Zeilen bestehen aus dem allgemeinen Frameheader und dem nach-folgenden Frametype-Header. Allgemeiner Frameheader bedeutet, dass diese Infor-mation für jedes Paket aufgezeichnet und protokolliert werden und für alle verwen-deten Protokolle im gleichen Format vorliegen. Handelt es sich beim Frametype-Header um den IP-Header, folgt zusätzlich der Header des verwendeten IP-Protokolls. Jede Zeile wird mit einem End-of-Line-Symbol abgeschlossen. Bei derAnalyse wird der untere Pfad des Syntaxdiagramms betrachtet, bei dem es sich um einPaket einer IP-Verbindung handelt.Der allgemeine Frameheader (vgl. Abbildung 3-2) setzt sich für alle Pakete aus demTimestamp, mehreren MAC-Adressen und dem Frametype zusammen. Der Timestampbesteht aus dem Datum und der Uhrzeit (vgl. Abbildung 3-3), wobei es sich bei denAngaben um Zeit und Datum der Aufzeichnung des jeweiligen Paketes im Netzwerkhandelt. Die Datumsangabe besteht aus der vierstelligen Jahreszahl, dem Monat unddem Tag, wobei diese Angaben durch einen Schrägstrich getrennt sind, wie inAbbildung 3-4 zu sehen ist. Die Uhrzeit setzt sich aus den Stunden, Minuten undSekunden zusammen, wobei hier der Doppelpunkt als Seperator dient (vgl. Abbildung3-5). Bei den angegebenen MAC-Adressen handelt es sich um die MAC-Adresse desHosts, auf dem die Protokollierung des Datenverkehrs stattgefunden hat, die MAC-Adresse des Senders und des Empfängers des jeweiligen Paketes (vgl. Abbildung 3-6).


17

Abbildung 3-1: allgemeines Format einer Quell-Datei

Abbildung 3-2: Format des allgemeinen Frameheaders

Abbildung 3-3: Format des Timestamps

Abbildung 3-4: Format des Datums

Abbildung 3-5: Format des Time-Feldes

Abbildung 3-6: Format des MAC-Adressen-Feldes

FrametypeMAC-AdressenTimestamp ;; ;

JJJJ / MM DD/

HH MM SS: :

Host-MAC Source-MAC Destination-MAC; ;

allgemeiner Frameheader Frametype-Header*

IP-Protokoll-HeaderIP-Header ;

; eol

Datum Zeit


18

Im letzten Feld des allgemeinen Frameheaders steht die vierstellige Nummer desFrametypes. Diese Zahlen sind bestimmten Protokollen zugeordnet, wobei die Zuord-nungen aller aufgezeichneten Protokolle in Tabelle 3-1 angegeben sind.

Nummer Frametype0800h IP0806h ARP0835h RARP0805h X.25 Level36001h DECnet6004h DECLAT8137h IPX/SPX809bh 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 diesfür eine IP-Verbindung steht. Nach diesem Feld kann nur der zugehörige Frametype-Header folgen. In Abbildung 3-7 ist dies durch nicht mehr zusammengeführte Pfeilenach 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 nichtnäher untersucht werden, wird an dieser Stelle darauf verzichtet die Struktur derjeweiligen Header anzugeben.Die Struktur der bei IP-Verbindungen aufgezeichneten Header-Informationen ist inAbbildung 3-9 zu sehen. Der entsprechende Abschnitt in der Protokollzeile beginntimmer mit [IP] und wird von der IP-Sender- und IP-Empfängeradresse gefolgt. Dienachfolgende Zahl gibt an, um welche IP-Version es sich bei der aktuellen Verbindunghandelt. Gefolgt von den Feldern Internet Header Length, Type of Service, Flags, Timeto Live und Protokoll (vgl. Kapitel 2.2).Im Protokollfeld des IP-Headers ist angegeben, welches höhere Protokoll für die Ver-bindung 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 Analysenur TCP- und UDP-Verbindungen näher untersucht werden, sind in den Abbildungen3-11 und 3-12 der Aufbau der TCP- und UDP-Header dargestellt.Die aufgezeichneten TCP-Paketdaten beginnen jeweils mit [TCP] gefolgt vom Sende-und Empfangsport. Diese Ports lassen Rückschlüsse auf die angeforderten und ver-wendeten Dienste der Verbindung zu. Die Sequenznummer, die Acknowledgenummer


19

und die Flags werden für jedes TCP-Paket angegeben und werden für die Analysedieser Verbindungen benötigt.

Abbildung 3-7: Format des Frametype-Feldes

Die aufgezeichneten Informationen einer UDP-Verbindung fallen kürzer aus, da diesesProtokoll (vgl. Kapitel 2.4) einen kürzeren Header verwendet. Die UDP-Daten be-ginnen jeweils mit [UDP] gefolgt von den zwei Ports. Im letztem Feld wird die Paket-länge angegeben.

0806h

6004h

6001h

0835h

0805h

809bh

8137h

0800h


20

Abbildung 3-8: mögliche Frametypes einer Quell-Datei

Abbildung 3-9: Format des IP-Headers einer Quell-Datei

ARP

RARP

X.25 Level 3

DECnet

AppleTalk

DECLAT

IPX/SPX

IP-Senderadresse IP-Empfängeradresse Version IHL TOS Flags TTL Proto-koll[IP] ; ; ; ; ; ; ;


21

Abbildung 3-10 : mögliche IP-Protokolle einer Quell-Datei

Abbildung 3-11:Format des TCP-Headers einer Quell-Datei

Abbildung 3-12 : Format des UDP-Headers einer Quell-Datei

Sendeport Empfängerport Sequenznummer Acknowledgenummer Flags[TCP] ; ; ; ;

Paket-längeSendeport Empfängerport[UDP] ; ;

TCP-Header

UDP-Header

ICMP-Header

IGMP-Header

OSPF-Header


22

In Abbildung 3-13 ist ein Ausschnitt von fünf Zeilen (entspricht fünf aufgezeichnetenPaketen) 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 Zeilen-ende am Zeilenumbruch erkannt wird. Die einzelnen Felder werden durch Semikolongetrennt. Somit können die Informationen zwischen diesen Seperatoren bei Bedarfzwischengespeichert und ausgewertet werden.Durch die verwendeten Trennsymbole (Semikolon, Schrägstriche, Doppelpunkte, daseol-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örterninnerhalb einer Zeile gescannt werden kann. Die Quell-Datei bleibt während und nachAbschluß der Analyse in ihrer Ursprungsform erhalten.

Kapitel 4 Das Programm

23

4 Das Programm

Das Analyseprogramm ConnectionChecker ist in MS Visual C++ unter MS WindowsNT programmiert und dokumentiert worden. Zur Bedienung existiert eine einfacheBenutzeroberfläche (vgl. Abbildung 4-1) mit Ausgabefenster. In diesem Fenster wirddie analysierte Datei, die Statistik über alle Verbindungen, sowie die Auswertungender untersuchten Verbindungen inklusive ihrer Pakete ausgegeben. Im Programm wirddie zu untersuchende Quell-Datei zeilenweise eingelesen und ausgewertet. Dabei wirddas Vorkommen der verschiedenen Protokolle gezählt und insbesondere die TCP- undUDP-Verbindungen genauer untersucht.

Abbildung 4-1: Benutzeroberfläche des ConnectionChecker

4.1 Ablauf

Das Programm wertet alle aufgezeichneten Pakete statistisch in Hinsicht auf dieverwendeten Protokolle aus. Dazu werden beim Programmaufruf Protokollzählerinitialisiert, die während der Analyse inkrementiert werden. Bestimmte Verbindungen(hier TCP- und UDP-Verbindungen) werden genauer untersucht, indem die Paketenach Verbindungen sortiert und auf Vollständigkeit untersucht werden. Für jede dieserVerbindungen wird geprüft, ob der Verbindungsaufbau und/oder Verbindungsabbau


24

erfolgreich war, ob Pakete verloren gegangen sind oder es einen timeout gab. Auchdiese Daten werden statistisch erfasst und ausgegeben.Bei Programmaufruf wird aus einer Initialisierungs-Datei ausgelesen, in welchenVerzeichnis sich die zu analysierende Datei befindet und welche Dateiendung siebesitzt.Nach dem Betätigen des CheckConnection-Buttons wird die Hauptroutine OnCheck-Connections() aufgerufen. Zunächst wird das aktuelle Verzeichnis, der gesetzte Datei-Filter 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 Zeileanalysiert. Danach beginnt die Prozedur von vorne. Dies geschieht solange, bis dasDateiende der Quell-Datei erreicht wird. Sind alle Zeilen analysiert, wird die Ausgabe-routine für die Protokollzähler CounterOutput und für die analysierten TCP-(ConnectionOutput) und UDP-Verbindungen (UDPConnectionOutput) aufgerufen unddie Quell-Datei geschlossen. Die Abbildung 4-2 zeigt den Programmablaufplan desbeschriebenen Hauptprogramms. Einige der in dieser Funktion aufgerufenen Unter-programme werden in den folgenden Kapitel näher erläutert.

Abbildung 4-2: Struktogramm der Funktion OnCheckConnection

%

Verzeichnispfad und Dateiendung für Quell-Datei festlegenÖffnen der Datei

Datei konnte geöffnet werdenFalschWahr

Ausgabe: "Filename:" Ausgabe: "no files toanalyse found"

Dateiende nicht erreicht

Ausgabe Protokollzähler

Ausgabe analysierter Verbindungen

Schließen der Quell-Datei

neue Zeile einlesen

aktuelle Zeile ausgeben

aktuelle Zeile analysieren


25

4.2 Behandlung von Verbindungen und Paketen

Im Programm werden die TCP- und UDP-Verbindungen analysiert. Dazu werdenzunächst alle detektierten TCP- und UDP-Pakete nach Verbindungen sortiert. Sowohldie Anzahl der Verbindungen als auch die Anzahl der Pakete pro Verbindung sind imProgramm dynamisch mittels Listen realisiert. Um ein Paket eindeutig einer bereitsbestehenden Verbindungen zuordnen zu können, müssen charakteristische Werte fürjede Verbindung definiert werden. Diese Werte stellen die „Visitenkarte“ der Ver-bindung dar. Um die Zugehörigkeit zu überprüfen, werden die Visitenkarten alleroffenen Verbindungen mit den entsprechenden Werten des aktuellen Paketes ver-glichen und werden ggf. der Verbindung zugeordnet. Kann ein Paket nicht zugeordnetwerden oder existiert noch keine Verbindung, wird eine neue Verbindung generiertund gleichzeitig das aktuelle Paket als erstes zugewiesen. Dementsprechend enthältjede Verbindung mindestens ein Paket. Das erste eingelesene Paket legt jeweils dieVisitenkarte der Verbindung fest. Zusätzlich zur Visitenkarte werden für jede Ver-bindung Status-Bits abgespeichert, die für die anschließende Analyse der gesamtenVerbindung von Bedeutung sind. Diese Status-Bits werden mit jedem neuen Paket,welches in die Verbindung eingelesen wird, aktualisiert. Für jedes Paket werdenzusätzliche Informationen abgespeichert.

4.2.1 TCP-Verbindungen und PaketeEin TCP-Paket kann einer TCP-Verbindung zugeordnet werden, wenn sowohl die IP-Adressen des Senders und Empfängers, als auch die Sende- und Empfangsports genauoder vertauscht übereinstimmen. Diese Daten bilden dementsprechend die Visitenkarteeiner TCP-Verbindung. Die Status-Bits der TCP-Verbindung sind Flags, die gesetztwerden, 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 dieserVerbindung keine weiteren Pakete mehr zugeordnet werden.In Abbildung 4-3 ist die Behandlung von TCP-Verbindungen und ihren Paketendargestellt. Bei den dargestellten Verbindungen befinden sich die Werte der Visiten-karte oberhalb und die einzelnen Status-Bits unterhalb des Querstrichs. Diese Wertesind im Programm stellvertretend für jede Verbindung abgespeichert und repräsen-tieren diese. Die für jedes Paket abgespeicherten Daten sind: IP-Sender- und IP-Em-pfängeradresse, Sende- und Empfangsport, Sequenz- und Acknowledgenummer, diedrei Kontroll-Bits ACK, SYN und FIN und der Timestamp. Die vier ersten Werte sindcharakteristisch für die zugehörige Verbindung und entsprechen genau oder jeweilsvertauscht der Visitenkarte der zugehörigen Verbindung. Sequenz- und Acknowledge-


26

nummer werden zur Sortierung der Pakete innerhalb der Verbindung verwendet. Dadiese Nummern jeweils beim nächsten Paket inkrementiert werden, können die Paketemittels dieser Werte in Reihenfolge gebracht werden. Die Herstellung der richtigenReihenfolge der Pakete wird für die spätere Analyse der gesamten Verbindung benö-tigt. Nur so kann festgestellt werden, ob und wieviele Pakete fehlen.

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. Sinddie Pakete in der richtigen Reihenfolge angekommen, müssen sie nur in die be-stehende Verbindung eingelesen werden. Das bedeutet, das aktuelle Paket wird alsletztes Paket der Verbindung angefügt (vgl. Abbildung 4-4).

Paket 1

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsportSequenznummerAcknowledgenummerACK-BitSYN-BitFIN-BitTimestamp

Paket m2


Verbindung 2

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsport___________________1.Paket2.Paket3.Paketvorletztes Paket letztesPaketTimeout

TCP-Verbindungen

Paket m1


Verbindung n


Verbindung 1

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsport____________________________

1.Paket2.Paket3.Paketvorletztes Paketletztes PaketTimeout

Paket 1


Verbindung n-1


Paket 1


Paket mn


Paket 1


Paket mn-1



27

Abbildung 4-4: Einlesen eines TCP-Paketes in eine Verbindung

Stimmt die Reihenfolge nicht, muss das Paket einsortiert werden. Anhand derSequenz- und Acknowledgenummer wird die Position bestimmt und das Paket an ent-sprechender Stelle eingefügt. Die Pakete, die in der Reihenfolge davorliegen, bleibenunbeeinflusst, die dahinter liegenden werden eine Position nach hinten gerückt (vgl.Abbildung 4-5).

Abbildung 4-5: Einsortieren eines TCP-Paketes in eine Verbindung

Die Kontroll-Bits werden zum setzen der Status-Bits der Verbindung benötigt. DerTimestamp der Pakete wird für die Timeout-Abfrage der Verbindung verwendet.

4.2.2 UDP-Verbindungen und PaketeWie bei der Behandlung von TCP-Paketen können erkannte UDP-Pakete einer Ver-bindung zugeordnet werden, wenn sowohl die IP-Adressen des Senders und Em-pfängers, als auch die Sende- und Empfangsports genau oder vertauscht übereinstim-men. Diese Daten bilden wiederum die Visitenkarte der Verbindung. Das Timeout-Bitist hier das einzige Status-Bit, da UDP als verbindungsloses Protokoll keinen Ver-

V.1: Paket 5

...SequenznummerAcknowledgenummer...

V.1: Paket 4



V.1: Paket 3V.1: Paket 2


V.1: Paket 1


V.1: aktuelles Paket...SequenznummerAcknowledgenummer...

V.1: Paket 6


V.1: Paket 5


V.1: Paket 4





V.1: Paket 1


V.1: aktuelles Paket...SequenznummerAcknowledgenummer...

V.1: Paket 5


V.1: Paket 4





V.1: Paket 1


V.1: Paket 6


V.1: Paket 5


V.1: Paket 4





V.1: Paket 1



28

bindungsaufbau und -abbau vorsieht und dementsprechend keine Flags dafür benötigt.Ist das Timeout-Bit gesetzt, können der Verbindung keine weiteren Pakete zugeordnetwerden.In Abbildung 4-6 ist die Behandlung von UDP-Verbindungen und den zugehörigenPaketen dargestellt. Bei den dargestellten Verbindungen befindet sich die Visitenkarteoberhalb und das Status-Bit unterhalb des Querstrichs. Diese Werte werden imProgramm stellvertretend für jede Verbindung abgespeichert und repräsentieren diese.Der für jedes UDP-Paket zusätzlich zur Visitenkarte abgespeicherten Parameter ist derTimestamp. Dieser Wert wird für die Timeout-Abfrage benötigt. Weitere Daten stehenaus dem UDP-Header der Quell-Datei nicht zur Verfügung. Da es bei UDP-Paketenkeine spezifische Reihenfolge innerhalb einer Verbindung gibt, müssen diese auchnicht einsortiert werden. Anders als bei TCP-Paketen, werden UDP-Pakete immer alsletzes Paket zur Verbindung hinzugefügt (entspricht dem Einlesen eines TCP-Paketesin Abbildung 4-4). Es wird dementsprechend nur eine Funktion (Read()) im Programmzum Einlesen benötigt.

Abbildung 4-6: Behandlung von UDP-Verbindungen und Paketen im Programm

Da die Anzahl der Pakete einer UDP-Verbindung nicht bekannt ist, kann bei derAnalyse nicht ermittelt werden, ob und wieviele Pakete fehlen. Es kann nach Ab-schluss der Analyse die Anzahl der Pakete der analysierten offen und geschlossenen(durch Timeout) Verbindungen ermittelt werden

Verbindung 2

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsport_________________Timeout

Paket m2

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsportTimestamp

Paket 1


UDP-Verbindungen

Verbindung 1

IP-SenderadresseIP-EmpfängeradresseSendeportEmpfangsport____________________________

Timeout

Verbindung n-1


Verbindung n


Paket 1


Paket m1


Paket mn-1


Paket 1


Paket mn


Paket 1



29

4.3 Die Analysefunktionen

Nach dem Auslesen der ersten Zeile aus der Quell-Datei, wird diese analysiert. Eswerden nacheinander die einzelnen Felder der Zeile ausgelesen, wobei nur die TCP-und UDP-Verbindungen vollständig analysiert werden. Von diesen wiederum könnenin dieser Programmversion nur HTTP und FTP als benutzte Dienste erkannt werden.Bei allen anderen Verbindungen wird nur der entsprechende Protokoll-Zählerinkrementiert. Anschließend wird die Analyse dieser Zeile abgebrochen. Die verschie-denen Analysefunktionen werden in den folgenden Unterkapiteln ausführlich behan-delt und mit Hilfe von Struktogrammen veranschaulicht (Abbildungen 4-7 bis 4-12).

4.3.1 Analyse des allgemeinen Frame-HeadersDie erste Analysefunktion FrameAnalyse (vgl. Struktogramm 4-7) liest alle Felder desallgemeinen Frame-Headers der aktuellen Zeile in entsprechende Variablen ein. Jenach Frametypenummer wird der entsprechende Protokollzähler inkrementiert. Han-delt 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 Protokollenwird die Analyse nach der statistischen Erfassung abgebrochen.

Abbildung 4-7: Struktogramm der Analysefunktion FrameAnalyse

4.3.2 Analyse des IP-HeadersHandelt es sich bei der aktuellen Zeile um die aufgezeichneten Daten eines Paketeseiner IP-Verbindung, wird innerhalb der FrameAnalyse-Funktion die FunktionAnalyseIPHeader (vgl. Abbildung 4-8) aufgerufen. Dieser Funktion wird die aktuelleZeile, ohne die bereits eingelesenen Felder, übergeben. Aus der so gekürzten Zeilewerden nun die einzelnen Felder des IP-Headers ausgelesen und in entsprechendenVariablen gespeichert.Wenn es sich beim verwendeten Internet Protokoll um die IPv4 handelt, wird dieAnalyse fortgesetzt. Da IPv6 einen anderen Protokoll-Header und verschiedene Be-triebs-Modi besitzt, kann dies hier nicht weiter behandelt werden. Bei der fortgeführ-

Frametype= 0800h?FalschWahr

IP-Protokollzähler inkrementieren

Analyse des IP-Headers der aktuellenZeile

entsprechendenProtokollzählerinkrementieren

Einlesen der Felder des allgemeinen Frame-Headers der aktuellenZeile


30

ten Analyse wird anschließend nach dem verwendeten IP-Protokoll sortiert. NurZeilen mit den Werten 6 (TCP, vgl. Tabelle 2-1) oder 17 (UDP) im entsprechendenProtokoll-Feld des IP-Headers, werden nach der Inkrementierung des entsprechendenProtokollzählers noch weiter ausgewertet. Alle anderen IP-Protokolle werden statis-tisch erfasst, die Analyse der aktuellen Zeile an dieser Stelle abgebrochen und dienächste Zeile der Quell-Datei eingelesen. Handelt es sich beim aktuellen Paket um einPaket einer TCP-Verbindung wird eine weitere Funktion zur Auswertung des TCP-Headers und anschließend zur Analyse der zugehörigen Verbindung aufgerufen. Han-delt es sich um ein Paket einer UDP-Verbindung werden zwei äquivalente Funktionenausgeführt.

Abbildung 4-8: Struktogramm der Analysefunktion AnalyseIPHeader

4.3.3 Analyse des TCP-Headers und der dazugehörigen VerbindungNach der Feststellung, dass es sich um ein TCP-Paket handelt, wird die FunktionAnalyseTCPHeader aufgerufen (vgl. Struktogramm 4-9). Der Funktion wird diegekürzte Zeile, mit den noch nicht ausgelesenen und ausgewerteten Feldern,übergeben. Die Funktion liest die Felder des TCP-Headers aus und speichert sie inentsprechenden Variablen. Anschließend werden einige Werte in andere Formatekonvertiert. Als nächstes werden die TCP-Kontroll-Flags ausgewertet. Für die Ver-

Einlesen der Felder des IP-Headers der aktuellen Zeile

%Analyse desTCP-Headers deraktuellenZeile

Analyse desUDP-Headers deraktuellenZeile

%Analyse deraktuellenTCP-Verbindung

Analyse deraktuellenUDP-Verbindung

case 6

Inkremen-tierung TCP-Protokollzähler

case 17

Inkremen-tierung UDP-Protokollzähler

sonst

Inkremen-tierung desentsprechendenProtokoll-zählers

switch (IP-Protokoll)

IP-Version= 4?Wahr Falsch


31

bindungsanalyse werden nur die Werte der ACK-, SYN- und FIN-Kontroll-Bits, diesich an der 2., 5. und 6. Position (vgl. Abbildung 2-5) befinden, benötigt. Ob diese Bitsgesetzt sind oder nicht, wird in entsprechenden Variablen für die folgende Analyse derkompletten TCP-Verbindung gespeichert.

Abbildung 4-9: Struktogramm der Analysefunktion AnalyseTCPHeader

Nach dem Auslesen der TCP-Headerdaten aus der aktuell betrachteten Zeile findet inder AnalyseIPHeader der nächste Funktionsaufruf statt. Zur Einordnung des Paketes indie zugehörige Verbindung und anschließende Analyse der Verbindung wird dieFunktion 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-Dateibereits TCP-Pakete gefunden und entsprechenden TCP-Verbindungen zugeordnetworden sind. Existiert mindestens eine solche Verbindung wird die Timeout-Abfragedurchgeführt. Hiermit wird überprüft, ob bereits erfasste offene TCP-Verbindungenschon zu lange auf das nächste Paket warten. Die sogenannte Timeout-Zeit bezeichnetden Zeitraum, in der auf das nächste Paket der etablierten TCP-Verbindung gewartetwerden darf. Bei überschrittener Wartezeit wird die Verbindung geschlossen.Anschließend wird versucht das aktuelle Paket einer offenen (kein Timeout), bereitsexistierenden TCP-Verbindung zuzuordnen. Das Paket wird dabei mit denVisitenkarten aller offenen Verbindungen verglichen. Wird die passende gefunden,muss das Paket an richtiger Position in die Verbindung einsortiert werden. DiePosition eines Paketes wird an Hand der Acknowledge- und der Sequenznummerbestimmt. Zunächst wird der einfachste Fall, das Paket kommt in der richtigenReihenfolge an, überprüft. Ist dies der Fall, wird das Paket in die zugehörigeVerbindung als letztes Paket mittels der Funktion Read() eingelesen. Anschließendwerden 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 Funktionbeendet.

Einlesen der Felder des TCP-Headers der aktuellen Zeile

Auswertung der TCP-Flags


32

Abbildung 4-10: Struktogramm der Analysefunktion AnalyseTCPConnection

Paket in richtiger Reihenfolge

Wahr Falsch

Paket in Verbindungeinlesen

Flags in Verbindungsetzen

TCP-Verbindung/en existiert/existieren bereits

Wahr Falsch

%

Timeout-Abfrage

alle Verbindungen durchsucht oder Paket einsortiert

Paket paßt zur akt. Verbindung

FalschWahr

%

%

alle Positionen durchsucht oder Paketeinsortiert

Paket in Reihenfolge

Wahr Falsch

Paket in Verbindungeinsortieren

Flags in Verbindungsetzen

Positiondekremen-tieren

Paket nicht eingelesen

Wahr Falsch

Paket an erster Pos.in Verbindungeinsortieren

%

keine TCP-Verbindung existiert oder Paket konnte keinerzugeordnet werden

Wahr Falsch

neueTCP-Verbindung erzeugen

Paket in Verbindung einlesen %

Flags in Verbindung setzen


33

Ist das Paket nicht in der richtigen Reihenfolge angekommen, wird es mit allen bereitseingetroffenen Paketen der Verbindung verglichen, um die richtige Position innerhalbder Verbindung zu finden. Das Paket wird anschließend an dieser Stelle mittels derFunktion 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 oderexistiert noch keine, wird eine neue TCP-Verbindung erzeugt und das Paket in diesemit Read() eingelesen. Abschließend wird die Bedeutung der Flags des Paketes für dieVerbindung 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 essich beim aktuellen Paket um ein Paket einer UDP-Verbindung handelt, die FunktionAnalyseUDPHeader aufgerufen (vgl. Abbildung 4-11). An diese wird die gekürzteaktuelle Zeile übergeben, wobei anschließend die Felder des UDP-Headers ausgelesenund in Variablen gespeichert werden. Einige Werte werden in andere Formate kon-vertiert, danach findet in der übergeordneten Funktion AnalyseIPHeader der nächsteFunktionsaufruf statt.

Abbildung 4-11: Struktogramm der Funktion AnalyseUDPHeader

Dieser startet die Funktion AnalyseUDPConnection (vgl. Struktogramm 4-12) zurEinsortierung des Paketes in die zugehörige Verbindung und zur anschließendenAnalyse der bereits bestehenden Verbindungen. Diese Analyse ist nicht so komplexwie bei einer TCP-Verbindung, da das UDP verbindungslos ist. Dementsprechendentfällt das Einsortieren der Pakete in bestimmte Positionen innerhalb einerVerbindung. Es kann hier nur festgestellt werden, welches Paket zu welcher Ver-bindung gehört und ob es zu einem Timeout gekommen ist. Auch die Auswertung vonFlags entfällt, da es keinen Verbindungsaufbau und –abbau gibt.Mit der ersten Abfrage in der Funktion wird überprüft, ob bereits eine oder mehrereUDP-Verbindungen existieren. Existiert zumindest eine, wird untersucht, ob dasaktuelle Paket einer von ihnen zugeordnet werden kann. Zuvor findet, wie bei derAnalyse der TCP-Verbindungen, eine Timeoutabfrage statt. Warten offene Ver-bindungen 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. Anschlies-send wird das Paket mit den Visitenkarten aller offenen Verbindungen verglichen. Bei

Einlesen der Felder des UDP-Headers der aktuellen Zeile


34

Übereinstimmung wird das Paket in die entsprechende Verbindung eingelesen. Konntedas Paket keiner existierenden UDP-Verbindung zugeordnet werden oder existiertnoch keine, wird eine neue UDP-Verbindung erzeugt. Anschließend wird das aktuellePaket in diese Verbindung eingelesen.

Abbildung 4-12: Struktogramm der Anaylsefunktion AnalyseUDPConnection

4.4 Die Ausgabe

Im Ausgabefenster der GUI11 (vgl. Abbildung 4-1) wird zunächst die zu analysierendeQuell-Datei mit Dateiendung und -pfad angegeben. Anschließend werden alle Zeilender gewählten Quell-Datei zur Kontrolle der Daten ausgegeben.Nach der Auswertung aller Zeilen der gewählten Quell-Datei, werden die Ergebnisseim Fenster der GUI dargestellt. Alle TCP- und UDP-Verbindungen werden separat mitzugehörigen Paketen und Analyseergebnissen aufgeführt. Über die restlichen Verbin-dungen, die nur gezählt worden sind, wird eine zusammengefaßte Statistik ausge-geben.

11 GUI - Graphical User Interface

UDP-Verbindung/en existiert/existierenbereits

Wahr Falsch

Timeout-Abfrage

alle Verbindungen durchsucht oderPaket einsortiert

Paket paßt zur akt.Verbindung FalschWahr

Paket inVerbindungeinlesen

Zeiger aufnächsteVerbindungsetzen

%

keine UDP-Verbindung existiert oder Paketkonnte keiner zugeordnet werden

Wahr Falsch

neue UDP-Verbindung erzeugen

Paket in Verbindung einlesen%


35

4.4.1 ProtokollzählerNach vollständiger Analyse der Quell-Datei, wird im Hauptprogramm die FunktionCounterOutput() 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 verschiedenenProtokollen angegeben, die dann wiederum nach verwendeten IP-Protokollen, wie z.B.TCP und UDP, aufgeschlüsselt werden (vgl. Abbildung 4-13). Die im Programm un-behandelten Protokolle werden jeweils mittels der Zähler unknown erfasst.

Abbildung 4-13: Beispiel für Ausgabe der Protokollzähler

4.4.2 Analysierten VerbindungenNach der Ausgabe der Protokoll-Zähler werden alle analysierten Verbindungen inklu-sive ihrer Pakete ausgegeben. Dabei wird zwischen der Ausgabe der TCP-Verbin-dungen (Aufruf der Funktion ConnectionOutput()) und der UDP-Verbindungen unter-schieden (Aufruf der Funktion UDPConnectionOutput()).

4.4.2.1 Die TCP-VerbindungenDie durchnumerierten TCP-Verbindungen werden mit ihren charakteristischenWerten, Analyseergebnissen und allen zugeordneten Paketen der Reihe nach imFenster der GUI ausgegeben (vgl. Abbildung 4-14).


36

Abbildung 4-14: Beispiel für Ausgabe der TCP-Verbindungen inklusive ihrerPakete

Zu den charakteristischen Werten jeder Verbindung zählen die Visitenkarte und dieKontroll-Bits (vgl. Abbildung 4-3). Zu den Analyseergebnissen gehören unter ande-rem die Auswertungen der Kontroll-Bits und des Ports.Als ein Analyseergebnis wird der genutzte Dienst (used service) ausgegeben. In dieserVersion des Programms werden nur HTTP- und FTP-Verbindungen als solche er-kannt.Sind alle drei Pakete des Verbindungsaufbaus vorhanden, wird ausgegeben, dass derDreiwege-Handshake zum Verbindungsaufbau vollständig (Establishment complete),ansonsten unvollständig war (Establishment incomplete). Das gleiche gilt für den Ver-bindungsabbau.Danach wird die Anzahl der analysierten, der ursprünglichen und der evtl. fehlendenPakete der Verbindung ausgegeben. Ist die Anzahl der Pakete der vollständigenVerbindung nicht berechenbar, wird dies gemeldet (# of total packets: unknown).Anschließend folgen alle Pakete der Verbindung, die sortiert und durchnumeriert aus-gegeben werden. Für jedes Paket werden beide IP-Adressen und Ports, sowie dieSequenz- und Acknowledgenummer angegeben.

4.4.2.2 UDP-VerbindungenNach der Ausgabe aller analysierten TCP-Verbindungen, folgt die Ausgabe aller UDP-Verbindungen. Zunächst wird die Anzahl der ermittelten UDP-Verbindungen ange-geben (Total # of UDP-connections). Danach folgen die Angaben der einzelnen Ver-


37

bindungen, die aus der Visitenkarte und der Anzahl der Pakete der Verbindung, sowieihrem Status (open oder Timeout) bestehen. Danach wird der genutzte Dienst ange-zeigt, wobei in der derzeitigen Version ebenfalls nur FTP und HTTP als Service er-kannt 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 werdenSende- und Empfangsport angegeben (vgl. Abbildung 4-15).

4.5 Funktionen

Im Programmcode müssen die Protokollabläufe von UDP und TCP in program-mierbare Regeln umgesetzt werden, die für die Analyse genutzt werden können. Diefür die Analyse benötigten Daten müssen an richtiger Stelle aus der Quell-Datei aus-gelesen und anschließend in ein auswertbares Format konvertiert werden.

4.5.1 Auslesen der Parameter der Quell-DateiZum Auslesen einzelner Parameter aus einer Zeile der Quell-Datei ist die FunktionExtractFirstParameter aus dem Programm PacketParser [DRO02] übernommenworden. Diese Funktion nutzt aus, dass die einzelnen Felder durch Semikola getrenntsind. Der Funktion wird die aktuelle Zeile übergeben. Sie extrahiert den ersten Para-meter der Zeile, indem sie alle Daten bis zum ersten Semikolon ausliest. Die Funktiongibt sowohl den ausgelesen Wert, sowie die um diesen gekürzte Zeile zurück. Der


38

ausgelesene Wert kann anschließend bei Bedarf in einer entsprechenden Variablenzwischengespeichert werden. Die gekürzte Zeile wird zur weiteren Analyse ver-wendet, bis alle benötigten Parameter ausgelesen worden sind.

4.5.2 FormatkonvertierungIm Programm wird die Konvertierung von einem Speichertyp in einen anderen auszwei Gründen benötigt. Einmal, um aus der Quell-Datei ausgelesene Parameter für dieAnalyse 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 umge-wandelt 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 an-alysiert 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üftwerden können, ob sie in einem bestimmten Intervall liegen. Die Sequenz- undAcknowledgenummern müssen der Größe nach verglichen werden können und dieTCP-Kontrollbits in einen auswertbaren Format vorliegen (Vgl. Kapitel 4.5.3).Eine weitere wichtige Formatierung stellt die Umwandlung des Timestamps in eineentsprechende CTime-Variable dar. Mit diesen Datentyp können Daten verglichen undsortiert werden. Außerdem kann so zwischen zwei Daten die Differenz gebildetwerden, was für die Timeout-Abfrage nötig ist.Für die Bildschirmausgabe müssen alle zuvor umgewandelten Größen wieder inCStrings konvertiert werden.

4.5.3 Auswertung der TCP-FlagsNach ihrer Konvertierung liegen die Kontroll-Bits des TCP-Paketes als 6-stelligeBinä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 einzelnbetrachtet werden. Um herauszufinden, ob ein bestimmtes Bit innerhalb eines Bytesgesetzt (=1) ist, muss das Byte mit einer bestimmten Binärzahl logisch UND-ver-knüpft werden. Prinzip und Wahrheitstabelle der UND-Verknüpfung in [WEB92].Die Binärzahlen mit denen die TCP-Flag-Variable zur Auswertung der einzelnenKontrollbits UND-verknüpft werden, sind in Tabelle 4-1 angegeben. Zum Auswertendes ACK-Bits wird die TCP-Flag-Variable mit der Binärzahl 10000b (entspricht derZahl 32 im Dezimalsystem) UND-verknüpft. Bei gesetztem ACK-Bit, ist das Ergebnis


39

der Verknüpfung eins und das entsprechende Kontroll-Bit wird im Programm gesetztund für das Paket zwischengespeichert. Dasselbe Verfahren wird auf das SYN- und dasFIN-Bit angewendet.

Flag X1 MSB X2 X3 X4 X5 X6 LSB

ACK 0 1 0 0 0 0SYN 0 0 0 0 1 0FIN 0 0 0 0 0 1

Tabelle 4-1: Binärzahlen der logischen UND-Verknüpfung mit dem TCP-Flags

4.5.4 Timeout-AbfrageIn realen Anwendungen findet die Timeout-Abfrage bei TCP- und UDP-Verbindungenfür jede Verbindung einzeln statt. Das bedeutet, dass der auf das nächste Paket war-tende Teilnehmer einer Verbindung, die Verbindung für geschlossen erklärt, wenneine bestimmte Wartezeit (timeout period, [STE94]) überschritten wird. Da es aber fürdas direkte Übernehmen dieser Methode nötig wäre, für alle offenen Verbindungeneine Stoppuhr laufen zu lassen, ist es hier einfacher diese Abfrage etwas anders zugestalten.Bevor im Programm ein Paket zugeordnet wird, findet sowohl bei einer UDP- als auchbei einer TCP-Verbindung eine sogenannte Timeout-Abfrage (vgl. Abbildungen 4-10und 4-12) statt. Hierbei wird der Timestamp des aktuellen Paketes sukzessive mit demTimstamp des letzten Paketes jeder offenen Verbindung verglichen. Ist die Differenzbeider Timestamps größer als die erlaubte Wartezeit (TCP- bzw. UDP-timeout period),wird die Verbindung der das Paket angehört geschlossen. Der Timestamp des aktuellbetrachteten Paketes stellt die globale Uhr für alle offenen Verbindungen dar und dasMitlaufen von Timern für jede Verbindung ist somit überflüssig. Die Timeout-Abfragemuss stattfinden um ein Timeout zu erkennen. Es beschleunigt gleichzeitig die Ana-lyse, da geschlossene Verbindungen nicht weiter betrachtet werden. Diese Verbin-dungen gehen als nicht vorschriftsmäßig abgebaut in die Statistik ein.

4.5.5 Einsortierung der TCP-PaketeDie TCP-Pakete werden innerhalb ihrer Verbindungen an Hand der Sequenz- oder derAcknowledgenummer sortiert. Beim Einlesen neuer Pakete werden zwei Fälle unter-schieden:

1. Das letzte Paket der Verbindung und das neue haben denselben Sender undEmpfänger.

2. Sender und Empfänger der beiden Pakete sind vertauscht.


40

Im ersten Fall wird die Sequenznummer beider Pakete verglichen. Ist die des aktuellenPaketes größer, ist die Reihenfolge richtig und das Paket kann eingelesen werden.Im zweiten Fall wird die Acknowledgenummer des aktuellen Paketes mit der Se-quenznummer des letzen Paketes verglichen. Ist die Acknowledgenummer größer alsdie Sequenznummer, ist die Reihenfolge ebenfalls richtig und das Paket kann ein-gelesen werden.Sind die Pakete nicht in der korrekten Reihenfolge angekommen, muss die richtigePosition des aktuellen Paketes in der Verbindung gesucht werden. Dazu wird dieSequenz- bzw. Acknowledgenummer des Paketes sukzessive mit denen aller Paketeder Verbindung verglichen. Beim letzen Paket der Verbindung beginnend, werden beijeden Schritt jeweils die beiden Fälle unterschieden und die entsprechenden Nummernverglichen, 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 miteinandermuss 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 dieEinsortierung der Pakete, da diese Pakete zwar einen kleineren Zahlenwert besitzen,aber in der Reihenfolge trotzdem hinter den vorherigen Paketen liegen. DieSchwierigkeit besteht in der Unterscheidung, ob bei der Sequenz- und/oder Ack-nowledgenummer ein Nulldurchgang stattgefunden hat oder das Paket nur in falscherReihenfolge in der Quell-Datei vorliegt. Ist die Differenz zweier Sequenz- bzw.Acknowledgenummern einer Verbindung zu hoch um für die Anzahl der Pakete einerVerbindung realistisch zu sein, wird davon ausgegangen, dass ein Nulldurchgangstattgefunden 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. DieGleichung 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) entsprechendbeim zweitem.

t)Ack,∆(Seq d)t)Seq,∆(Seq c)t)Ack,∆(Seq b)

t)Seq,∆(Seq a)

curn

curn

curn

curn

>><

< Gleichung 4.1 a)-d)

Es wird jeweils die Differenz zwischen der Sequenznummer des letzten Paketes derVerbindung und der Sequenznummer bzw. der Acknowledgenummer des aktuellengebildet und mit dem Schwellwert t verglichen. Ist die Differenz kleiner als derSchwellwert (Gleichung 4.1 a) und b)) liegt der Normalfall vor und die entsprechen-


41

den Zahlen werden verglichen und aufsteigend einsortiert. Ist sie kleiner, liegt einNulldurchgang vor und die Zahlen werden absteigend geordnet.Da Pakete zwischendurch fehlen können, muss diese Abfrage bei der Einsortierungsukzessive mit jedem Paket durchgeführt werden, bis die korrekte Position gefundenworden ist.

4.5.6 Berechnung der Anzahl der Pakete einer TCP-VerbindungUm die Anzahl der Pakete einer TCP-Verbindung berechnen zu können, müssenmindestens ein Paket des Verbindungsaufbaus und eins des Verbindungsabbaus vor-handen sein, da sonst jegliche Bezugspunkte fehlen.Stimmen die IP-Adressen des Senders und Empfängers des ersten und letzten Paketesder Verbindung überein, berechnet sich die Anzahl der Pakete nach Gleichung 4-2.

µ++∆ 1),(2 1 nSeqSeq Gleichung 4-2

Wobei ∆(Seq1,Seqn) die Differenz der Sequenznummern des 1. und des letzen Paketesbezeichnet. Die Variable µ, im Programmcode missingEnd genannt, berechnet sich ausder Anzahl der fehlenden Pakete vor dem ersten und hinter dem letzten aufgezeich-neten Paket der Verbindung. Dies können das 1. Paket oder das 1. und 2. Paket desVerbindungsaufbaus und/oder das letzte Paket des Verbindungsabbaus sein.Sind die IP-Adressen des Senders und Empfängers beim letzen und ersten Paketvertauscht berechnet sich die Anzahl nach Gleichung 4-3.

µ+∆ ),(2 1SeqAckn Gleichung 4-3

Der Term ∆(Ackn,Seq1) bezeichnet in diesem Fall die Differenz derAcknowledgenummer des letzen und der Sequenznummer des ersten Paketes.Die Anzahl der fehlenden Pakete einer Verbindung kann anschließend aus derDifferenz der gerade bestimmten Anzahl der TCP-Pakete und der Anzahl der protokol-lierten Pakete der Verbindung bestimmt werdenFehlen alle Pakete des Verbindungsaufbaus oder -abbaus ist keine Aussage über dieAnzahl der Pakete möglich. In diesem Fall kann auch nicht die Anzahl der fehlendenPakete berechnet werden.

Kapitel 5 Tests

42

5 Tests

Während der Programmierphase sind alle neuen Funktionen umgehend mit einerentsprechend präparierten Quell-Datei getestet worden.Zunächst ist das zeilenweise Auslesen der Quell-Datei mit einer gekürzten Datei (10Pakete) getestet worden. Zur Überprüfung sind die eingelesenen Zeilen unverändert imAusgabefenster ausgegeben worden. Diese Funktionalität steht noch, bei Markierungdes entsprechenden Kontrollkästchens (Show Sourcefile), zur Verfügung.Die Funktionen FrameAnalyse und AnalyseIPHeader, in der die Protokollzählerinkrementiert werden, ist mit Hilfe einer Quell-Datei getestet worden, in der jedesbekannte Protokoll sowie jeweils ein unbekanntes mindestens einmal vorgekommenist. Durch Ausgabe aller Zählerstände konnte die Funktionalität direkt überprüftwerden.Da die Behandlung von UDP-Paketen einfacher als die von TCP-Paketen ausfällt, istzunächst die Erzeugung von UDP-Verbindungen und die Einordnung der UDP-Paketeimplementiert und getestet worden. Hierzu wird erst eine Quell-Datei mit mehrerenUDP-Verbindungen und jeweils einen zugehörigen Paket verwendet. Die imAusgabefenster ausgegebenen UDP-Verbindungen konnten sofort mit der Quell-Dateiverglichen 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 undvertauschter Sender-Adresse (IP-Senderadresse und Sendeport) und Empfänger-Adresse (IP-Empfängeradresse und Empfangsport) sowie die Überprüfung einesTimeouts der einzelnen Verbindungen.Nach Implementierung der Funktion AnalyseTCPConnection sind dieselbenFunktionalitäten wie bei den UDP-Verbindungen mit entsprechend angepasster Quell-Datei überprüft worden. Zusätzlich ist die korrekte Einordnung der Pakete innerhalbeiner Verbindung getestet worden. Dazu sind die Acknowledge- und Sequenz-nummern der TCP-Pakete innerhalb der verwendeten Test-Datei variiert worden. ErsteTests haben ergeben, dass der Zahlenbereich dieser Nummern zu gering gewähltworden 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, dassteilweise Pakete gefehlt und/oder in der falschen Reihenfolge vorgelegen haben.Abschließend ist noch der Nulldurchgang der laufenden Sequenz- und/oder Acknow-ledgenummer unter gleichen Bedingungen getestet worden.Nach Fertigstellung des Programms sind zwei abschließende Tests zur Überprüfungder Gesamtfunktionalität durchgeführt worden. Erstens mit einer selbsterstelltenQuell-Datei die alle Protokolle und alle oben aufgeführten Fälle gemeinsam enthält

Kapitel 5 Tests

43

und zweitens mit einer von der Monitoringsoftware erzeugten Quell-Datei, die realaufgezeichneten Datenverkehr eines Netzwerks enthält. Letztere Datei ist wesentlichlänger (10.000 Pakete) als die zuvor präparierten Test-Dateien und konnte somitgleichzeitig zur Kontrolle der Analysegeschwindigkeit des Programms herangezogenwerden.

Kapitel 6 Resümee und Ausblick

44

6 Resümee und Ausblick

Das Programm ConnectionChecker analysiert bisher TCP- und UDP-Verbindungenmittels dynamischer Speicherverwaltung im Detail, alle anderen Protokolle werdenbisher nur rudimentär behandelt. Auf Grund der dynamischen Speicherverwaltungwerden die im Programm verwendeten Listen automatisch in ihrer Größe angepasst.Das bedeutet, die Anzahl der Verbindungen und Texte muss vor der Analyse nichtfestgelegt werden. Außerdem gewährleistet sie eine optimale Speicherplatzverwaltung.Die Analyse der Quell-Datei findet zur Laufzeit statt, das bedeutet, die Datei mussnicht erst komplett ausgelesen werden. Es wird zeilenweise ausgelesen und direktanalysiert, so dass nur Daten relevanter Zeilen, hier Pakete der TCP- und UDP-Verbindungen, gespeichert werden und die Analyse der anderen sofort abgebrochenwird. Auf Grund der dynamischen Speicherverwaltung und der Laufzeitanalyse wirddas Programm hinsichtlich des Speicherplatzes und Laufzeit optimiert. Die allgemeingehaltene Programmstruktur, ermöglicht das Programm leicht zu erweitern undeinzelne Komponenten, z.B. für andere Verbindungsprotokolle, wiederzuverwenden.Wie schon in vorherigen Kapiteln angedeutet, ist die Erweiterung und/oder Modi-fikation des Programms ConnectionChecker an einigen Stellen möglich und sinnvoll.Eine mögliche Erweiterung wäre, die Erkennbarkeit von genutzten Diensten auf einegrößere Anzahl auszuweiten. In der aktuellen Version des Programms wird in derFunktion AnalyseService nur zwischen HTTP, FTP und sonstige Dienste unterschie-den. Die Liste der Dienste kann leicht erweitert werden, da diese an Hand des „well-known-ports“ mittels einer case-Abfrage unterschieden werden.In der aktuellen Programm-Version ist die Behandlung der offenen Verbindungen beiabgeschlossener Analyse einer Quell-Datei noch unbehandelt. Eine Quell-Datei enthälteine Anzahl von Paketen, die über eine gewisse Zeitdauer im Netzwerk aufgezeichnetworden sind. Die Quell-Datei enthält nur einen gewissen Ausschnitt des Netzwerk-verkehrs ohne Anspruch auf Vollständigkeit der aufgezeichneten Verbindungen. Dieprotokollierten Verbindungen können sich somit über mehrere Quell-Dateien erstreck-en. Aus diesem Grund wäre es wünschenswert, dass mehrere Quell-Dateien hinter-einander analysiert werden können und offene Verbindungen für die nächste Quell-Datei weiter zur Verfügung stehen. Nur so können Pakete derselben Verbindung, dieaber in einer späteren Quell-Datei aufgezeichnet worden sind, auch der gleichenVerbindung zugeordnet werden. Um diese Erweiterung zu ermöglichen, behaltenderzeit 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 neuenDatei. Die Ergebnisse werden im aktuellen Programm nur auf dem Bildschirm aus-

Kapitel 6 Resümee und Ausblick

45

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. MitAuswahl der zu analysierenden Quell-Dateien, Ein- bzw. Ausblendung von bestimm-ten Analyseergebnissen und zusätzlichen Funktionen.Für die Zukunft absehbar ist, dass eine neue Version der Programmierumgebung dieMöglichkeit einer höheren Auflösung des Zeitstempels mit sich bringt. Der als CTime-Variable abgespeicherte Timestamp kann in der derzeitigen Version nur sekun-dengenau behandelt werden. Dies ist für die aufgezeichneten Pakete nicht ausreichend,da die Übertragungsgeschwindigkeiten eine genauere Auflösung erfordern.

Kapitel 7 Literatur

46

7 Literatur

[BAU99] Baumann, HeikoEntwicklung eines Softwaretools zur Protokollierung und Analyse desDatenstroms in NetzwerkenDiplomarbeit D344, Lehrstuhl für DatenverarbeitungRuhr-Universität Bochum, 1999

[CHA98] Chapman, DavisVisual C++6 in 21 TagenHaar bei München :SAMS, 1998

[CHE96] Cheswick, William R. / Bellovin, Steven M.Firewalls und Sicherheit im InternetSchutz vernetzter Systeme vor cleveren HackernAddison-Wesley, Bonn, 1996

[DET97] Deutsche TelekomGlossar, Begriffe aus der Welt der Netzehttp://www.t-lan.de/GLOSSAR/

[DRO02] Droste, Thomas / Ruhl, AlexanderAufgaben bei verteilter Datenakquisition und dessen Zusammenführungfür die AnalyseIn: Horster, Patrick: Enterprise Security 2002IT-Verlag, 2002

[JUN00] Junker, HolgerTCP und UDPInstitut für Rechnerentwurf und Fehlertoleranz,Proseminar Rechnerkommunikation und TelefonUniversität Karlsruhe, WS 2000/2001http://goethe.ira.uka.de/seminare/rkt/tcp+udp/

[KAD01] Kaderali,. FirozNetwork SecuritySkript zur VorlesungFernuniversität Hagen, 02.05.2001

Kapitel 7 Literatur

47

[KAUF99] Kauffels, Franz-JoachimLokale NetzeMITP-Verlag GmbH, Bonn, 1999

[LIE01] Lienemann, GerhardTCP/IP-PraxisDienste, Sicherheit, Troubleshooting, Kapitel 1: TCP/IP im InternetHeinz Heise Verlag, März 2001http://www.dpunkt.de/leseproben/3-88229-184-2/Kapitel_1.pdf

[PFL01] Pfliegl, KonstantinSo funktioniert TCP/IPtecChannel-Artikel vom 02.11.2001http://www.tecchannel.de/internet/209/index.html

[POS81] Postel, JonRFC: 791: Internet ProtocolInformation Sciences InstituteUniversity of Southern California, September 1981http://www.ietf.org/rfc/rfc0791.txt

[POT81] Postel, JonRFC: 793: Transmission Control ProtocolInformation Sciences InstituteUniversity of Southern California, September 1981http://www.ietf.org/rfc/rfc0793.txt

[PRA92] Prata, StephenC++Einführung in die objektorientierte ProgramierungTe-wi Verlag (Waite Group), 1992

[REB01] Reibold, HolgerHypertext Transfer ProtocoltecChannel-Artikel vom 30.08.2001http://www.tecchannel.de/internet/208/index.html

Kapitel 7 Literatur

48

[REI01] Reibold, HolgerFile Transfer ProtocoltecChannel-Artikel vom 05.01.2000http://www.tecchannel.de/internet/207/index.html

[REY94] Reynolds, J. / Postel, J.RFC: 1700: Assigned NumbersISI, Oktober 1994http://www.ietf.org/rfc/rfc1700.txt

[STE94] Stevens, W. RichardTCP/IP, Illustred, Volume 1Addison-Wesley, Reading, 1994

[THO99] Thormählen, ThorstenEntwicklung einer Internetkamera und deren Anbindung über PPP undTCP/IP an das ISDNDiplomarbeit, Fachgebiet Elektronische Bauelemente und SchaltungenGerhard-Mercator-Universität-Gesamthochschule Duisburg, 1999http://www.thormahlen.de/diplhtml/thor_pri.html

[WAS94] Washburn, Kevin / Evans, JimTCP/IPAufbau und Betrieb eines TCP/IP-NetzesAddison-Wesley, Bonn, 1994

[WEB92] Weber, Wolfgang / Alef, AndreasGrundlagen der DatenverarbeitungLehrstuhl für DatenverarbeitungRuhr-Universität-Bochum, Bochum, 1992

[ZIT96] Zitterbart, M.Telematik 1Skript Kapitel 8: InternetInstitut für Telematik, Universität Karlsruhe 1996http://www.telematik.informatik.uni-karlsruhe.de/lehre/alt/vorlesungen/Tele1-

Folien_WS9697/K8-Inter/index.htm

Documents

Analyse eines verteilten Datenstromes auf Vollständigkeit · Die Analysesoftware ist mit MS Visual C++ unter MS Windows NT/2000 zu realisieren. Alle Entwicklungsschritte sind zudem