Speicherformat zur Datenakquisition in verteilten Systemen

Lehrstuhl für
Datenverarbeitung
Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber
Studienarbeit S294
Speicherformat zur Datenakquisition in verteilten Systemen
Ein zuverlässiger und vollständiger Datenmitschnitt ist Voraussetzung für ein spätere
Analyse. Bereits in der Diplomarbeit D344 ist ein Monitoringsoftware zum
Datenmitschnitt des Netzwerkverkehrs entwickelt worden, welcher in dieser Arbeit durch
Nutzung einer anderen –bereits existierenden– Lösung verifiziert werden soll.
Ziel ist es, das binäre Speicherformat einer alternativen Monitoringsoftware zu
analysieren und eine entsprechende Formatkonvertierung durchzuführen. Dazu muss das
Speicherformat an das im verteilten Sicherheitssystem genutzte angepasst und modifiziert
werden.
Die Realisierung, als Einbindung der alternativen Monitoringsoftware in einen Dienst, ist
ein weiteres Ziel. Automatisiert soll hierbei der Datenmitschnitt von der Netzwerkkarte
in kontinuierlichen Intervallen durchgeführt werden.
Die Aufnahme des Datenverkehrs selbst und die Formatkonvertierung sollen dabei
entkoppelt voneinander in zwei getrennten Projekten stattfinden.
Die Software 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. Thorsten Kisner
108 096 220 557
Dipl.-Ing Thomas Droste
WS 2001/02
Inhalt
Inhalt
1
2
Einleitung ................................................................................................................ 3
Grundlagen der Netzwerkkommunikation .............................................................. 4
2.1
Das OSI Schichtenmodell ............................................................................... 4
2.2
Network Driver Interface Specification (NDIS) ............................................. 5
2.3
Logical Layer (Layer 2)................................................................................... 6
2.3.1 Beschreibung der Funktionen...................................................................... 6
2.3.2 Ethernet 802.3 ............................................................................................. 6
2.4
Network Layer (Layer 3)................................................................................. 7
2.4.1 Beschreibung der Funktionen...................................................................... 7
2.4.2 Internet Protocol.......................................................................................... 7
2.5
Transport Layer (Layer 4) ............................................................................... 9
2.5.1 Beschreibung der Funktionen...................................................................... 9
2.5.2 Ports............................................................................................................. 9
2.5.3 Transmission Control Protocol.................................................................. 10
2.5.4 User Datagramm Protocol ......................................................................... 11
2.5.5 Internet Control Message Protocol............................................................ 11
3
Problemstellung..................................................................................................... 12
4
Ethereal.................................................................................................................. 13
4.1
Beschreibung................................................................................................. 13
4.2
Windows Packet Capture Driver (WinPcap)................................................. 14
4.2.1 Kernel Ebene: Packet Capture Driver ....................................................... 15
4.2.2 Benutzer Ebene: Packet Capture Library .................................................. 15
4.2.3 Installation................................................................................................. 15
4.3
Kompilieren des Projektes ............................................................................ 16
4.3.1 Benötigte Pakete........................................................................................ 16
4.3.2 Zusätzliche Pakete..................................................................................... 16
4.3.3 Umgebungsvariabeln und Aufruf des Compilers...................................... 16
4.4
Tethereal........................................................................................................ 17
4.4.1 Capture-Filterregeln .................................................................................. 19
4.4.2 Tethereal Verbose-Ausgabe ...................................................................... 21
4.5
Ethereal.......................................................................................................... 24
4.5.1 Anzeigoptionen ......................................................................................... 25
4.5.2 Analysefunktionen .................................................................................... 28
5
LibPcap Capture Format ....................................................................................... 34
5.1
Beschreibung................................................................................................. 34
1
Inhalt
6
7
8
9
5.2
LibPcap Format ............................................................................................. 34
5.2.1 Arrival Time.............................................................................................. 35
5.2.2 Capture Lenght und Packet Lenght........................................................... 35
5.2.3 Debug Informationen ................................................................................ 36
5.3
Analyseprogramm und Konvertierung in das Zielformat ............................. 36
5.3.1 Extrahierte Informationen ......................................................................... 39
5.3.2 Beispiel einer Analyse eines ICMP-Datenpaketes.................................... 42
5.3.3 Ausgabe des Analyseprogramms .............................................................. 44
Dienste................................................................................................................... 45
6.1
Allgemein ...................................................................................................... 45
6.2
Aufrufe von Programmen.............................................................................. 45
6.3
Alternative: srvany.exe.................................................................................. 46
6.4
Realisierung................................................................................................... 48
6.4.1 Programmstruktur...................................................................................... 48
6.4.2 EventLog Komponenten ........................................................................... 50
6.4.3 Installation................................................................................................. 50
Test ........................................................................................................................ 53
7.1
Testumgebung ............................................................................................... 53
7.2
Capture-Service............................................................................................. 53
7.2.1 Dateiübertragung....................................................................................... 54
7.2.2 Nutzung der maximalen Bandbreite.......................................................... 55
7.3
Capture-Parser............................................................................................... 56
Ausblick ................................................................................................................ 57
8.1
Verbesserungen ............................................................................................. 57
8.2
Schwächen..................................................................................................... 57
Literatur................................................................................................................. 59
2
Kapitel 1
Einleitung
1 Einleitung
Ein Bestandteil von Netzwerksicherheit ist die Kontrolle der über Netzwerke
gesendeten Daten. Diese Kontrolle ist nur durch entsprechendes Beobachten des
Netzwerkmediums möglich. Und zwar ohne die Kommunikation in irgendeiner Weise
zu beeinflussen. Dazu muss jedes Paket unabhängig von Quelle und Ziel berücksichtigt
und aufgezeichnet werden.
Eine weitere Schwierigkeit ist die große Anzahl von Protokollen und die immer mehr
zunehmende Geschwindigkeit in Netzwerken. An dieser Stelle ist die Performance der
Monitoring Applikation von entscheidender Bedeutung, um den Paketverlust vor allem
in Hochgeschwindigkeitsnetzen zu vermeiden oder auf eine Minimum zu reduzieren.
Ziel dieser Studienarbeit ist es, zu einer bereits existierenden Monitoring Software eine
unabhängige Lösung zu bieten, um die Ergebnisse der vorhandenen Software zu
verifizieren. Dabei wird auf die ebenfalls vorhandene Software Ethereal zurückgegriffen. Diese Software wird als NT-Dienst implementiert und die Ausgabe des
Programms an das gewünschte Zielformat angepasst.
3
Kapitel 2
Grundlagen der Netzwerkkommunikation
2 Grundlagen der Netzwerkkommunikation
Wesentliche Grundlage für die Entwicklung des Analyseprogramms sind die
Protokollschichten des in Kapitel 2.1 besprochenen OSI Schichtenmodells.
In den weiteren Unterkapiteln werden die Header der benötigten Protokolle der
Schichten zwei bis vier dargestellt. Diese Beschreibung gibt lediglich eine Übersicht
über die Struktur der einzelnen Datenpakete, genaue Definitionen können in [Bau99]
nachgeschlagen werden.
2.1 Das OSI Schichtenmodell
7.
Application Layer (Anwendungschicht)
6.
Presantation Layer (Präsentationsschicht)
5.
Session Layer (Sitzungschicht)
4.
Transport Layer (Transportschicht)
3.
Network Layer (Netzwerkschicht)
2.
Logical Layer (Datenverbindungschicht)
1.
Physical Layer (Physiche Schicht)
Abbildung 2-1: ISO/OSI Schichtrnmodell
Wichtig für das Verständnis von Netzwerkverbindungen ist das in Abbildung 2-1
gezeigte ISO1/OSI2 – Schichtenmodell.
Definiert sind die Schnittstellen zwischen den einzelnen Schichten (Service Access
Points, SAP). Das Schichtmodell gibt keinerlei Vorgaben über die Implementierung
einer einzelnen Schicht, sondern beschreibt lediglich die Schnittstellen zwischen den
Schichten.
1
ISO - International Standardisation Organisation
2
OSI - Open System Interconnect
4
Kapitel 2
Grundlagen der Netzwerkkommunikation
2.2 Network Driver Interface Specification (NDIS)
Die Abbildung 2-2 zeigt die Implementierung des in Abbildung 2-1 dargestellten
ISO/OSI – Schichtenmodells, wie in [MIC00] nachzulesen ist. Wesentlich für den
Mitschnitt von Paketen auf einem Netzwerkmedium ist die NDIS3 Schnittstelle. Diese
ist wesentlicher Bestandteil des Netzwerkkodes von Win32-Systemen. NDIS ist für die
Kommunikation zwischen Netzwerkadaptern bzw. den Treibern dieser Adapter und
den darüber liegenden Transport Protokollen verantwortlich. Es wird eine Methode
bereitgestellt, die es erlaubt, Daten auf einem Netzwerk zu senden oder zu empfangen,
ohne genaue Kenntnis über die einzelnen Netzwerkadapter zu besitzen.
7. Anwendung
RPC
Provider
Named Pipes
6. Präsentation
5. Sitzung
NetBIOS-Treiber
4. Transport
Redirector
Server
Winsock-Treiber
Transport Driver Interface
3. Netzwerk
Transport Protokolle
Streams
2. Datenverbindung
LLC
MAC
NDIS-Schnittstelle
NDISNetzwerkkartentreiber
Treiber d. Netzwerkkarten
1. Physisch
Netzwerkkarten
Abbildung 2-2: Microsoft Windows NT-Netzwerkarchitektur
Es werden drei Arten von NDIS Schnittstellen unterstützt:
• Netzwerkkartentreiber
An dieser Stelle können vollständige Netzwerkkartentreiber implementiert
werden. Diese beinhalten alle hardwarespezifische Informationen zum Senden,
Synchronisieren und Empfangen von Daten und der Weiterleitung an die
Transport Protokolle.
• Zwischentreiber
Ein Zwischentreiber ist das Bindeglied zwischen den Transportprotokollen und
den eigentlichen Netzwerkkartentreibern. Für eine Transportprotokoll sieht
dieser Treiber wie eine Netzwerkkarte aus, ein Netzwerkkartentreiber kommuniziert mit diesem Zwischentreiber wie mit einem Transportprotokoll.
3
NDIS - Network Driver Interface Specification
5
Kapitel 2
Grundlagen der Netzwerkkommunikation
• Protokolltreiber
An dieser Stelle können Netzwerkprotokolle definiert werden. Diese stellen die
Dienste direkt den Netzwerkkarten zur Verfügung.
Die NDIS Implementierung als Zwischentreiber ist für die spätere Betrachtung des
Packet Capture Drivers in Kapitel 4.2 von Bedeutung.
2.3 Logical Layer (Layer 2)
2.3.1 Beschreibung der Funktionen
Die Datenverbindungsschicht sorgt für eine fehlerfreie Übertragung der Daten-Frames
über die physische Schicht. Unterschieden wird diese Schicht in eine Media Access
Control (MAC) und Logical Link Control (LLC) Unterschicht in den Projekt 802
Definitionen. Diese beinhalten unter anderem noch weitere Kategorien: 802.2 LLC,
802.3 CSMA/CD, 802.5 Token Ring.
Funktionen der LLC Schicht:
• Auf- und Abbau von logischen Verbindungen
• Frame-Flußkontrolle
Funktionen der MAC Schicht:
• Verwalten des Medienzugriffs
• Überprüfen der Frames auf Fehler
• Prüfen der Zieladresse und Entscheidung ob das Datenpaket an eine höhere
Schicht weitergegeben wird.
Die MAC-Schicht ist in den Netzwerkkartentreiben implementiert, die LLC Schicht ist
den NDIS-(Network Device Interface) Spezifikationen zugeordnet.
2.3.2 Ethernet 802.3
Das Ethernet hat sich in den letzen Jahren als Standard in lokalen Netzwerken (LAN,
Local Area Network) etabliert. Nicht zuletzt durch einfach handhabbare Hardwarekomponenten und günstige Preise hat es andere Protokolle aus dem Massenmarkt verdrängt.
Die Abbildung 2-3 zeigt den Aufbau eines Frames im Ethernet. Neben Quell- und Zieladresse und dem eigentlichen Datenteil sind 2 Byte für den Typ des übergeordneten
Protokolls spezifiziert. Die Präambel signalisiert der Beginn der Verbindung und ist im
Carrier Sense Multiple Access / Collision Detect (CSMA/CD) – Protokoll spezifiziert.
Die Framekontrollsequenz beinhaltet eine Prüfsumme der übertragenden Daten, um
Fehler zu korrigieren oder eine erneute Sendung des Frames anzufordern.
6
Kapitel 2
Grundlagen der Netzwerkkommunikation
Präambel Zieladresse Sendeadresse
8 Byte
6 Bytes
6 Bytes
Typ
Datenteil
2 Bytes
max. 1500 Bytes
Framekontrollsequenz
4 Bytes
Abbildung 2-3: Ethernet Frame
2.4 Network Layer (Layer 3)
2.4.1 Beschreibung der Funktionen
Die Netzwerkschicht basiert auf der Datenverbindungsschicht und bestimmt die
physischen Wege, auf denen die Daten verschickt werden. Diese Schicht stellt
folgende Funktionen zur Verfügung:
• Unterteilen des Netzes in logische Subnetze
• Weiterleitung der Frames an Router
• Aufteilen der Frames in mehrere Blöcke, falls ein maximale Größe (MTU,
Maximum Transfer Unit) erreicht ist
• Auflösen der logischen Adresse eines Netzknotens in eine physikalische
Netzwerkadresse
Das Internet Protokoll (IP) ist nur ein Beispiel für ein Protokoll der Ebene 3. In den
letzten Jahren hat es sich allerdings als das bedeutsamste herausgestellt. Weitere, hier
nicht behandelte Protokolle, sind z.B. Apple Talk oder NetBEUI.
2.4.2 Internet Protocol
Die wichtigste Funktion des Internet Protokolls (IP) ist zweifellos das Routing. Jedes
Datenpaket, in dieser Schicht auch Datagramm genannt, beinhaltet die IP-Sende- und
Empfängeradresse. Anders als in der Datenverbindungsschicht bleiben diese Adressen
unverändert. Die Abbildung 2-4 zeigt dieses an einem einfachen Routingbeispiel. Host
A (192.168.111.100) will ein Paket an Host B (192.168.222.2) senden. Diese Quellund Zieladressen werden in den Feldern des IP-Frames eingetragen. Er findet in seiner
IP-Routingtabelle für das Zielnetz 192.168.222.0 das Gateway 192.168.111.1. Nun
kommen die MAC Adressen hinzu. Quelladresse ist die von Host A, Zieladresse ist
jedoch die des Routers.
Der Router bekommt nun das Paket und entscheidet anhand der IP-Zieladresse, dass er
es über sein anderes Netzwerkinterface versenden muss. Die MAC-Adressen werden
entsprechend der neuen Adressen dieses Netzes entsprechend geändert.
7
Kapitel 2
Grundlagen der Netzwerkkommunikation
Router
Host A
MAC: 00:10:4B:45:B4:53
IP: 192.168.111.100
IP-Routingtabelle
Netzwerkziel
192.168.111.0
192.168.222.0
Gateway
192.168.111.100
192.168.111.1
MAC: 00:AF:C4:D6:3B:9C
IP: 192.168.111.1
MAC: 00::3C:42:4E:5B
IP: 192.168.222.1
Host B
IP-Routingtabelle
Netzwerkziel
192.168.222.0
192.168.111.0
IP-Routingtabelle
Netzwerkziel
192.168.222.0
192.168.111.0
MAC: 00:80:C8:87:BB:EF
IP: 192.168.222.2
Gateway
192.168.222.1
192.168.111.1
Ethernet
Gateway
192.168.222.2
192.168.222.1
Ethernet
SrcMAC
DstMAC
SrcMAC
DstMAC
00:10:4B:45:B4:53
00:AF:C4:D6:3B:90
00::3C:42:4E:5B
00:80:C8:87:BB:EF
SrcIP
DstIP
SrcIP
DstIP
192.168.111.100
192.168.222.2
192.168.111.100
192.168.222.2
Abbildung 2-4: Routingbeispiel IP
Die Abbildung 2-5 zeigt die Struktur eines IP-Headers. Im Beispiel oben sind nur die
Informationen IP-Sendeadresse und IP-Empfängeradresse berücksichtigt worden.
Diese jeweiligen 4 Byte können an den entsprechenden Stellen ausgelesen werden. Das
Feld Protokoll gibt wiederum den Typ des übergeordneten Protokolls an. Im IP-Header
wird sowohl die Länge des Headers selbst (Internet Header Lenght, IHL) als auch die
gesamten Paketlänge angegeben. Dies ist notwendig, da beide Längen variieren
können.
1-8
9-16
17-24
25-32
Version
IHL
Type of Service
Paketlänge
Identifikation
Flags
Fragmentabstand
TTL
Protokoll
Prüfsumme
IP-Sendeadresse
IP-Empfängeradresse
Optionen
Füllzeichen
Abbildung 2-5: IP Header
8
Kapitel 2
Grundlagen der Netzwerkkommunikation
2.5 Transport Layer (Layer 4)
2.5.1 Beschreibung der Funktionen
Die Transportschicht kümmert sich um die richtige Reihenfolge der ankommenden
Daten. Damit nimmt sie höheren Schichten die Verantwortung für die Kontrolle der
Integrität der Daten ab. Da die Transportschicht Daten unbegrenzter Größe bearbeiten
kann, in darunter liegenden Schichten jedoch Größenbeschränkungen vorliegen,
erfolgt hier eine Unterteilung der Daten in Frames. Darüber hinaus stellt diese Schicht
folgende Dienste zur Verfügung:
• Vollständige und fehlerfreie Übertragung der Daten durch Bestätigungen des
Empfängers
• Annahme der Daten von oberen Schichten und Unterteilung in Frames
• Anweisung zum Unterbrechen des Datenstroms, falls der Empfangspuffer belegt ist
2.5.2 Ports
Speziell auf das TCP/IP Protokoll bezogen, sind Ports in der Transportschicht
angesiedelt. Es sind 65535 Ports vorhanden, wobei die ersten 1023 reserviert sind.
Aufgabe der Ports ist es, ankommende Datenpakete an die richtigen überliegenden
Schichten (bzw. die richtigen Anwendungen) zu transportieren. Anfragen an Port 80
werden z.B. an den Webserver-Dienst weitergeleitet.
Wie in Abbildung 2-6 gezeigt, bilden die Sockets den SAP zwischen der Transportschicht und der Sitzungsschicht. Hier wird von der Anwendung ein Socket erzeugt und
an einen Port gebunden. Ein Webserver hört z.B. den Port 80 ab und reagiert auf den
über das Socket empfangenden String.
Session Layer
Ports
Socket
Service Access Point
Sockets
Webserver
0
1
2
...
80
...
65535
Transport Layer
Abbildung 2-6: Ports und Sockets
9
Kapitel 2
Grundlagen der Netzwerkkommunikation
2.5.3 Transmission Control Protocol
Der Header eines TCP Paketes ist in Abbildung 2-7 gezeigt. Die Länge eines Feldes
für Sende- und Empfängerports haben jeweils die Größe von 2 Byte. Dies ergibt die im
vorigen Kapitel angegebene maximale Portgröße von 65535. Für die oben
angegebenen Funktionen dieser Schicht sind die darauffolgenden Felder von großer
Bedeutung. Durch die Sequenznummer kann ein einzelner Frame an die richtige Stelle
des Übertragungsstromes eingeordnet werden. Die Länge des Paketes ist durch das
Feld Abstand definiert, die Prüfsumme ermöglicht eine Fehlererkennung und –
beseitigung.
1-8
9-16
17-24
Sendeport
Abstand
25-32
Empfängerport
Sequenznummer
Quittungsnummer
Kontrollbits
Reserviert
Prüfsumme
Optionen
Fenstergröße
Urgent-Zeiger
Füllzeichen
Abbildung 2-7: TCP Header
Die Abbildung 2-8 zeigt das Zusammenfügen der Daten durch die Sequenznummern
anhand einem stark vereinfachten Beispiel. Die unterschiedliche Empfangsreihenfolge
der Daten kann z.B. durch unterschiedliche Netzwerkrouten hervorgerufen werden.
Host A
Sequenznummern
werden vergeben
DATENPAKET
DATENPAKET
DATE
1
NPAK
2
ET
3
Empfangsbestätigungen
werden geschickt
2
NPAK
1
DATE
3
ET
Host B
Sequenznummern
ergeben richtige
Reihenfolge
Abbildung 2-8: TCP Sequenznummern
10
Kapitel 2
Grundlagen der Netzwerkkommunikation
2.5.4 User Datagramm Protocol
Die Verwendung des User Datagramm Protocol (UDP) entspricht einer verbindungslosen Kommunikation. Weder korrekte Reihenfolge der Pakte noch der Empfang eines
Paketes überhaupt kann sichergestellt werden. Als Fehlererkennung dient lediglich die
Prüfsumme. Die Abbildung 2-9 zeigt den sehr kleinen Header eines UDP Paketes.
Lediglich Sende- und Empfängerport, Paketlänge und Prüfsumme sind im Vergleich
zu einem TCP Header vorhanden.
Durch die fehlenden Empfangsbestätigungen ist dieses Protokoll jedoch äußerst
schnell und eignet sich vor allem für zeitkritische Übertragungen von Sprache und
Bild, bei denen einzelne fehlende Pakete keine signifikanten Fehler hervorrufen.
Sendeport (2 Byte)
Paketlänge (2 Byte)
Empfängerport (2 Byte)
Prüfsumme (2 Byte)
Abbildung 2-9: UDP Header
2.5.5 Internet Control Message Protocol
Das Internet Control Message Protocol (ICMP) ist ein Verwaltungsprotokoll, dessen
Daten über die IP-Schicht transportiert werden. Besonderes Augenmerk liegt bei der
Diagnose von Verbindungsproblemen in der IP Kommunikation. Das Protokoll stellt
folgende Funktionen zur Verfügung:
• Diagnosemöglichkeiten über die Dienstprogramme ping und tracert (bzw.
traceroute)
• Erstellen und Verwalten von Routing-Tabellen
• Ermitteln der PMTU
Die verschiedenen Funktionen sind im Feld Typ des ICMP-Headers (vgl. Abbildung
2-10) kodiert. Typ 8 entspricht beispielsweise einer Echo-Anfrage (echo request) und
Typ 0 einer Antwort (echo reply).
Typ (1 Byte)
Code (1 Byte)
Prüfsumme (2 Byte)
Unbenutzt (4 Byte)
IP-Header + 64 Bit des ursprünglichen Datagramms (4 Byte)
Abbildung 2-10: ICMP-Header
11
Kapitel 3
Problemstellung
3 Problemstellung
In dieser Studienarbeit solle ein Software entwickelt werden, die automatisiert Datenmitschnitte des Netzwerkverkehres erstellt. Dabei soll auf die frei verfügbare Software
Ethereal zurückgegriffen werden. Die Aufgabe lässt sich damit in zwei voneinander
unabhängige Bereiche unterteilen. Die Schnittstelle zwischen beiden Bereichen ist das
Dateiformat LibPcap.
Die Datenakquisition ist als NT-Dienst zu implementieren und gibt, bedingt durch die
Verwendung von Ethereal, eine Binärdatei im LibPcap Format aus. Dieses muss in
einem zweiten Schritt in das gewünschte Zielformat konvertiert werden.
Der wesentliche Grund für die Unterteilung in zwei verschiedene Bereiche ist die
Vermeidung des Verlustes von Paketen. Eine integrierte Lösung würde während der
Datenaufnahme die Pakete analysieren und dann bereits im gewünschten Format ausgeben, dies jedoch auf Kosten der Systemressourcen.
12
Kapitel 4
Ethereal
4 Ethereal
4.1 Beschreibung
Ethereal ist ein Protokoll-Analysator für MS Windows und Unix. Es ist ein OpenSource Produkt und unter der Gnu Public Licence (GPL) verfügbar. Das Programm
ermöglich Mitschnitt, Darstellung und Analyse des gesamten Datenverkehrs bezogen
auf ein oder mehrere Netzwerk-Interfaces.
Das Programm ist in einer graphischen Benutzeroberfläche Ethereal und als Konsolenanwendung Tethereal verfügbar. Beide Anwendungen haben im Kern den identischen
Funktionsumfang: Mitschnitt der Datenpakete, Im- und Exportfunktionen in verschiedene Formate, Analyse und Filterung der Daten. Filterregeln unterscheiden sich in
sogenannte Capture-Filter und Read- bzw. Display-Filter
Die Möglichkeiten der Konsolenanwendung, besonders in Hinblick auf die Analyse
des Datenstroms, sind durch die fehlende graphische Benutzeroberfläche natürlich
begrenzt.
Abbildung 4-1: Ethereal
Die Abbildung 4-1 und Abbildung 4-2 zeigen die beiden Programme Ethereal und die
Hilfe-Ausgabe von Tethereal.
13
Kapitel 4
Ethereal
Abbildung 4-2: Tethereal
4.2 Windows Packet Capture Driver (WinPcap)
Ethereal benötigt zwingend den Windows Packet Capture Driver. Dieser stellt eine
Schnittstelle zwischen der eigentlichen Applikation Tethereal (bzw. Ethereal) und dem
Netzwerkadapter dar.
Application
Tetheral.exe
libpcap.dll
Dynamic Link Library
Packet Capture Driver
User Level
packet.dll
packet.sys
NDIS
Datenpaket
Kernel Level
Network Adapter
Abbildung 4-3: Struktur des Capture-Stacks
Wie in Abbildung 4-3 gezeigt ist diese Schnittstelle auf zwei verschiedenen Ebenen
der Win32-Netzwerkarchitektur verteilt. Auf Benutzerebene ist die dynamische Biblio14
Kapitel 4
Ethereal
thek packet.dll und die in der Applikation enthaltenen statischen Bibliothek wpcap.dll
zu finden, auf Kernel Ebene der Capture Drivers packet.sys. Beide Ebenen sind getrennt und unabhängig voneinander.
4.2.1 Kernel Ebene: Packet Capture Driver
Hauptaufgabe dieses NDIS Treibers ist die Aufnahme der Daten aus der Datenverbindungsschicht und Weitergabe an die Applikation. Während eines Datenmitschnittes
muss sich die Netzwerkkarte in einem besonderen Modus (promiscuous mode)
befinden, der es erlaubt, alle Pakete an übergeordnete Schichten weiterzuleiten. Im
normalen Modus der Netzwerkkarte werden nur Pakete weitergeleitet, die z.B. im
Ethernet an speziell diese Media Access Control (MAC) Adresse oder an Broadcast
Adressen adressiert sind.
Der Packet Capture Driver muss dafür sorgen, dass alle Pakete ohne Veränderungen
an übergeordnete Schichten weitergeleitet werden ohne den Netzwerkverkehr in
irgendeiner Weise zu beeinflussen. Der Treiber ist stark Betriebssystem abhängig und
unter Windows NT als Kernel Treiber (packet.sys) und unter Windows 9x als virtueller
Gerätetreiber (packet.vxd) implementiert.
4.2.2 Benutzer Ebene: Packet Capture Library
An oberster Stelle des Protokollstacks steht, wie in Abbildung 4-3 gezeigt, die
Applikation selbst. Tethereal benutz für den Datenmitschnitt die statische Bibliothek
libpcap.dll. Diese Bibliothek ist fest mit der Anwendung verbunden und identisch mit
der UNIX Packet Capture Library (LibPcap) für das Programm Tcpdump. Tethereal
kommuniziert nicht mit der Hardware, sondern nutzt lediglich die Funktionen wie die
Datenaufnahme oder Filterregeln, die die Bibliothek zu Verfügung stellt. Da der
Packet Capture Driver auf Kernel Ebene systemabhängig ist, ist zwischen diesem und
der Packet Capture Library der Applikation noch eine weitere Bibliothek angeordnet.
Die dynamische Bibliothek packet.dll ermöglicht eine systemunabhängige Implementierung der Applikation.
4.2.3 Installation
Der Windows Packet Capture Driver ist unter [Pcap01] sowohl als Installations- als
auch als Quellkodeversion verfügbar. Die Installation erfolgt ohne weitere Parametereingabe, alle Applikationen, die diesen Treiber benötigen sind danach direkt einsetzbar.
15
Kapitel 4
Ethereal
4.3 Kompilieren des Projektes
Ethereal ist für die MS Windows Plattform ebenfalls als Quellcode und als ausführbare
Datei erhältlich. Beide Versionen benötigen den in Kapitel 4.2 beschriebenen Windows
Packet Capture Driver. Zusätzlich werden verschiedene Pakete direkt als IncludeDateien und andere Programme lediglich als Hilfsmittel benötigt.
4.3.1 Benötigte Pakete
Zur Kompilation von Ethereal sind folgende Pakete zwingend notwendig.
• Ethereal (ethereal-0.9.1)
Der Quellcode von Ethereal selbst.
• Windows Packet Capture Driver (WinPcap)
Neben dem installierten Packet Capture Treibers zur Ausführung von Ethereal
sind zur Kompilation von Ethereal auch die Quelldateien notwendig. Der
Capture Driver wird an dieser Stelle allerdings nicht mitkompiliert, sondern es
wird lediglich die statische Bibliothek libpcap für Ethereal benötigt.
• GTK+
Das Gimp Toolkit stellt eine plattformunabhängige Lösung zum Erstellen von
graphischen Benutzungsoberflächen bereit.
• GLib
Stellt mehrere Bibliotheken für das Gimp Toolkit zur Verfügung.
• ZLib
Diese Bibliothek stellt Routinen zur Kompression von Daten bereit.
4.3.2 Zusätzliche Pakete
Einige generierte Quellen benötigen klassische UNIX-Tools (z.B. sed). Hierzu empfiehlt es sich, das Paket „cygwin“ zu installieren. Dieses installiert eine UNIX-Umgebung und stellt die benötigten Tools zur Verfügung.
• Cygwin – Eine Unix-Umgebung für Windows
• Sed – Ein Stream Editor
• Bison – Ein Parser Generator
• Flex – Ein schneller lexikalischer Analysator
• Bash – Die GNU Bourne Again Shell
• Grep – Das GNU Utility grep
• Python – Eine objektorientierte Skriptsprache
4.3.3 Umgebungsvariabeln und Aufruf des Compilers
Ethereal wird über die Kommandozeile kompiliert. Vorher ist eine Anpassung der
Pfade für die notwendigen Pakete in der Datei „config.nmake“ erforderlich.
16
Kapitel 4
Ethereal
Abbildung 4-4: Anpassung von config.nmake
Danach erfolgt die Kompilierung über den Kommandozeilenaufruf nmake -f
makefile.nmake. Hierzu müssen allerdings die Umgebungsvariablen so eingestellt
sein, dass ein Aufruf Microsoft Visual C++ von der Kommandozeile her möglich ist,
Dies kann durch einen Aufruf der Batch-Datei „vcvars32.bar“ im Visual C++ Verzeichnis erreicht werden.
4.4 Tethereal
In diesem Kapitel werden die Funktionen beschrieben, die Tethereal bereitstellt. Wie
in Abbildung 4-2 bereits gezeigt, ist Tethereal eine Kommandozeilenapplikation, deren
Verhalten durch im Programmaufruf übergebene Parameter gesteuert wird.
Im Falle mehrerer Netzwerkschnittstellen wird immer die erste Schnittstelle genutzt,
der Programmaufruf (tethereal –D) listet wie in Abbildung 4-5 dargestellt alle
verfügbaren Netzwerkschnittstellen auf.
Abbildung 4-5: Tethereal: Auflistung der Netzwerkschnittstellen
17
Kapitel 4
Ethereal
Ein Aufruf von Tethereal – im einfachsten Fall ohne Parameterübergabe – startet
Tethereal und zeigt verschiedenen Informationen der übertragenen Frames an.
Die erste Zeile gibt immer Auskunft über das gerade verwendete Netzwerkinterface an.
In den weiteren Zeilen folgen die einzelnen Frames. Je nach Protokolltyp werden verschiedene Informationen angezeigt. Im Falle des Ineternet Protokolls sind es Angaben
über Quell-IP- und Ziel-IP-Nummern. Der verwendete Protokolltyp der Ebene 4 ist
ebenfalls dargestellt und in Abhängigkeit davon werden auch hier verschiedene Informationen aufgeschlüsselt.
Die Fehlermeldung in den letzten beiden Zeilen im abgebildeten Beispiel in Abbildung
4-6 ist auf einen manuellen Abbruch des Programms über STRG+C zurückzuführen.
Abbildung 4-6: Tethereal
Weitere Optionen zum Start von Tethereal sind in Abbildung 4-7 dargestellt:
Befehl
Bedeutung
-c (count)
Gibt die Anzahl von Paketen an, die aufgezeichnet werden
sollen. Ist diese Anzahl erreicht, wird Tethereal beendet
-i (interface)
Gibt die zu benutzende Netzwerkschnittstelle an.
-s (snapshot) Gibt die Grenze an, bis zu der Pakete maximal protokolliert werden.
-w (write)
Gibt eine Datei an, in die der Daten-Mitschnitt geschrieben werden
soll.
-F (Format)
Gibt das Format der ausgegebene Datei an.
-f (filter)
Nach dieser Option können Capture-Filterregeln angegeben werden.
Abbildung 4-7: Startoptionen von Tethereal
18
Kapitel 4
Ethereal
4.4.1 Capture-Filterregeln
Dieser Teil der Filterregeln bezieht sich sowohl auf Ethereal als auch auf Tethereal.
Die Syntax der Filterregeln ist identisch zu denen von TcpDump unter UNIX. Ein
Blick auf den Capture-Stack in Abbildung 4-3 verdeutlicht den Grund: Beide Programme beinhalten die identische Packet Capture Library (LibPcap).
Eine detaillierte Darstellung der Regeln ist in der Dokumentation zu TcpDump
[TCP97] zu finden.
4.4.1.1 Primitive Elemente
Die einzelnen Elemente beziehen sich auf die Datenverbindungsschicht, Netzwerkschicht und Transportschicht. Zusätzlich können Filterregeln bezüglich der Länge der
Pakete erstellt werden. Jede einzelne Regel gibt den Wahrheitswert true oder false
zurück. Ist der Wert der gesamten Filterregel true, wird das Paket aufgezeichnet.
Das Format für die in Abbildung 4-8 gezeigte Ethernetadresse ehost muss in der Form
xx:xx:xx:xx:xx:xx erfolgen.
ether dst ehost Die Zieladresse entspricht ehost.
ether src ehost Die Quelladresse entspricht ehost.
ether host ehost Die Adresse ehost ist entweder Ziel oder Quelle.
Abbildung 4-8: Filter im Ethernet (Layer 2)
Der Platzhalter host in Abbildung 4-9 steht für eine IP-Adresse im Format
xxx.xxx.xxx.xxx. Alternativ kann der Name des Hosts angegeben werden. Dieser wird
dann durch eine DNS4-Abfrage aufgelöst.
dst host host
src host host
host host
dest net net
src net net
net net
tcp, udp, icmp
Die Zieladresse entspricht host.
Die Quelladresse entspricht host.
Die Adresse host ist entweder Ziel oder Quelle.
Das Zielnetz wird mit net definiert
Das Quellnetz entspricht net.
Das Netz ist entweder Quelle oder Ziel
Der Protokolltyp IP-Paketes entspricht tcp, udp oder icmp
Abbildung 4-9: Filter im IP-Protokoll (Layer 3)
4
DNS - Domain Name Service
19
Kapitel 4
Ethereal
Der Platzhalter port in Abbildung 4-10 gibt die Portnummer als dezimale Zahl an.
Alternativ können die Namen der Ports verwendet werden. Die Verwendung von
„domain“ entspricht beispielsweise der Portnummer „53“. Die Länge lenght muss als
Dezimalzahl angegeben werden.
dst port port
src port port
port port
less lenght
greater lenght
Ein TCP oder UDP Paket mit dem Ziel-Port port.
Ein TCP oder UDP Paket mit dem Quell-Port port.
Ein TCP oder UDP Paket mit dem Quell- oder Ziel-Port
port.
Das gesamte Paket ist kleiner als lenght.
Das gesamte Paket ist größer als lenght.
Abbildung 4-10: Weitere Filterregeln
4.4.1.2 Boolsche Operatoren
Alle oben genannten Filterregeln lassen sich beliebig mit Boolschen Operatoren
verknüpfen. Einzelne Regeln lassen sich durch Klammern zusammenfassen. Hierbei ist
die jeweilige Interpretation der Klammer innerhalb des verwendeten Kommandointerpreters zu berücksichtigen. Bei Verwendung einer UNIX-Shell sind alle
Klammerausdrücke mit einer Escape-Sequenz “\)“ zu versehen.
! oder not
&& oder and
|| oder or
Verneinung des folgenden Ausdruckes
UND-Verknüpfung
ODER-Verknüpfung
Abbildung 4-11: Boolsche Verknüpfungen
4.4.1.3 Beispiele
Während des Aufrufes von Tethereal ist die Angabe des Filterausdrucks in Anführungszeichen zu beachten: tethereal –f “Filterausdruck“
Abbildung 4-12 zeigt einige Beispiele der Filteregeln. Die Abkürzungen A, B und C
stehen für IP-Adressen.
Die letzten drei Beispiele in Abbildung 4-12 zeigen, dass diese Filterregeln auch auf
einzelne Bytes des Datenstroms angewandt werden können.
20
Kapitel 4
Ethereal
host A
host A and host B
host A and not (host B or host C)
icmp and host A
src host A and (port 20 or port 21)
icmp[0] = 8
icmp[0] != 8 and icmp[0] != 0
tcp[13] & 3 != 0
Alle ausgehenden und ankommenden Pakete.
IP-Verkehr zwischen A und B
Alle Daten von A außer der Kommunikation
mit B oder C.
Alle ICMP-Pakete die von Host A verschickt
oder empfangen werden.
Ausgehenden FTP-Verkehr von Host A.
Nur ICMP Echo Requests.
ICMP-Pakete, die keine Echo Requests oder
Replies sind.
Start und Ende Pakete (SYN und FIN) einer
TCP-Kommunikation.
Abbildung 4-12: Beispiele für Filteregeln
4.4.2 Tethereal Verbose-Ausgabe
Tethereal kann in einem sogenannten „Verbose-Mode“ (tethereal –V) gestartet
werden. In diesem Modus wird jedes Datenpaket einzeln ausgegeben. Jede Netzwerkbzw. Protokollebene wird in einem eigenen Abschnitt angezeigt. Netzwerkadressen
werden aufgelöst, zusätzlich werden Adressen aufgelöst und einzelne Flags interpretiert ausgegeben. Im Folgenden sind die Ausgaben für die Pakete der Typen TCP,
UDP und ICMP aufgelistet. Für die spätere Verarbeitung interessierende Daten sind
gelb hinterlegt.
4.4.2.1 Transmission Control Protocol
Frame 1 (337 on wire, 337 captured)
Arrival Time: Feb 22, 2002 12:39:47.721488000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 337 bytes
Capture Length: 337 bytes
Ethernet II
Destination: 00:10:4b:45:b4:53 (3Com_45:b4:53)
Source: 00:a0:c9:cd:81:a1 (Intel_cd:81:a1)
Type: IP (0x0800)
Internet Protocol, Src Addr: thor.kisner.local (192.168.111.101), Dst
Addr: img.web.de (217.72.195.84)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 323
Identification: 0xd571
Flags: 0x04
21
Kapitel 4
Ethereal
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x5798 (correct)
Source: thor.kisner.local (192.168.111.101)
Destination: img.web.de (217.72.195.84)
Transmission Control Protocol, Src Port: 1911 (1911), Dst Port: http (80),
Seq: 408086031, Ack: 1313334976
Source port: 1911 (1911)
Destination port: http (80)
Sequence number: 408086031
Next sequence number: 408086314
Acknowledgement number: 1313334976
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 17424
Checksum: 0x4559 (correct)
Hypertext Transfer Protocol
GET /web/img/v4/home/club_icon_30.gif HTTP/1.1\r\n
Accept: */*\r\n
Referer: http://web.de/?id=V00-020222--2n7P-00\r\n
Accept-Language: de\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
Q312461; DT)\r\n
Host: img.web.de\r\n
Connection: Keep-Alive\r\n
\r\n
4.4.2.2 User Datagramm Protocol
Frame 1 (86 on wire, 86 captured)
Arrival Time: Feb 22, 2002 12:30:06.185166000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 86 bytes
Capture Length: 86 bytes
Ethernet II
Destination: 00:10:4b:45:b4:53 (3Com_45:b4:53)
Source: 00:a0:c9:cd:81:a1 (Intel_cd:81:a1)
Type: IP (0x0800)
Internet Protocol, Src Addr: thor.kisner.local (192.168.111.101), Dst
Addr: diz.kisner.local (192.168.111.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 72
Identification: 0xb4ad
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
22
Kapitel 4
Ethereal
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x2640 (correct)
Source: thor.kisner.local (192.168.111.101)
Destination: diz.kisner.local (192.168.111.1)
User Datagram Protocol, Src Port: 1880 (1880), Dst Port: domain (53)
Source port: 1880 (1880)
Destination port: domain (53)
Length: 52
Checksum: 0xd893 (correct)
Domain Name System (query)
Transaction ID: 0x0001
Flags: 0x0100 (Standard query)
0... .... .... .... = Query
.000 0... .... .... = Standard query
.... ..0. .... .... = Message is not truncated
.... ...1 .... .... = Do query recursively
.... .... ...0 .... = Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
1.111.168.192.in-addr.arpa: type PTR, class inet
Name: 1.111.168.192.in-addr.arpa
Type: Domain name pointer
Class: inet
4.4.2.3 Internet Control Message Protocol
Frame 1 (74 on wire, 74 captured)
Arrival Time: Feb 19, 2002 13:07:52.598908000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 74 bytes
Capture Length: 74 bytes
Ethernet II
Destination: 00:10:4b:45:b4:53 (3Com_45:b4:53)
Source: 00:a0:c9:cd:81:a1 (Intel_cd:81:a1)
Type: IP (0x0800)
Internet Protocol, Src Addr: thor.kisner.local (192.168.111.101), Dst
Addr: DIZ (192.168.111.111)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 60
Identification: 0x76be
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: ICMP (0x01)
Header checksum: 0x63dd (correct)
Source: thor.kisner.local (192.168.111.101)
Destination: DIZ (192.168.111.111)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x1358 (correct)
Identifier: 0x0200
Sequence number: 38:04
23
Kapitel 4
Ethereal
Data (32 bytes)
0000
0010
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
abcdefghijklmnop
qrstuvwabcdefghi
4.5 Ethereal
Ethereal ist nicht nur eine mit einer graphischen Benutzungsoberfläche versehene
Version von Tethereal, sonder um einige Merkmale erweitert. Die Abbildung 4-13
zeigt die Oberfläche mit einem Beispielhaften ICMP Paket. Dieses Paket ist zum Vergleich der Darstellungen ebenfalls in Kapitel 4.4.2.3 und Kapitel 5.3.2 behandelt.
Die Benutzungsoberfläche ist in drei Teile geteilt. Im oberen Teil erfolgt eine tabellenartige Zusammenfassung der Pakte, wie sie auch in Tethereal (vgl. Abbildung 4-6)
gegeben ist. Im mittleren Teil lassen sich Detailinformationen in einer Baumstruktur
einsehen. Beispielhaft sind die Informationen zum Ethernet angezeigt. Eine gesamte
Auflistung aller Baumelemente ergibt die Informationen, wie sie auch im VerboseMode von Tethereal in Kapitel 4.4.2.3 zu finden sind.
Der untere Teil stellt den aktuell markierten Frame in eine hexadezimalen Schreibweise dar.
Abbildung 4-13:Darstellung eines ICMP Paketes in Ethereal
Für die weitere Betrachtung von Ethereal ist ein Datenstrom aufgezeichnet, der einen
Aufruf der Startseite der Ruhr-Universität Bochum darstellt (http://www.ruhr-unibochum.de/).
Die Abbildung 4-14 zeigt den resultierenden Datenstrom. Die ersten beiden Pakte
zeigen eine DNS-Abfrage des Hostnamens www.ruhr-uni-bochum.de, die restlichen
Pakete den TCP-Datenverkehr mit dem Webserver.
24
Kapitel 4
Ethereal
Abbildung 4-14: Aufruf der Startseite der Ruhr-Universität Bochum
4.5.1 Anzeigoptionen
Ethereal bietet eine Vielzahl von Anzeigeoptionen. Kern jeder Anzeigeoption ist die
Möglichkeit, die Daten zu filtern. Es lassen sich generelle Anzeigefilter definieren,
aber auch die Darstellung entsprechende den Optionen einfärben.
4.5.1.1 Filter
Die Anzeigefilter in Ethereal sind wesentlich umfangreicher als die in Kapitel 4.4.1
besprochenen Capture Filter und unterscheiden sich von der Syntax. Ethereal bietet an
dieser Stelle allerdings eine komfortable Möglichkeit, diese Regeln über Dialogfelder
zusammenzustellen. Die Abbildung 4-15 zeigt das Auswahlmenü für diese Anzeigefilter.
Über den Button Add Expression können sehr leicht eigene Filter definiert werden. Die
Abbildung 4-16 zeigt die Zusammenstellung einer Filterregel, die alle Pakete zeigt, bei
denen das Flag SYN im TCP Protokoll gesetzt ist. Eine Bestätigung stellt die Regel in
der entsprechenden Syntax zusammen: tcp.flags.syn == 1
25
Kapitel 4
Ethereal
Abbildung 4-15: Auswahl von Display Filter
Abbildung 4-16: Zusammensetzung einer einfachen Filterregel
26
Kapitel 4
Ethereal
Eine auf die Regel angewandte Darstellung von Ethereal ist in Abbildung 4-17 gezeigt.
Abbildung 4-17: Angewandte Filteregel TCP SYN
4.5.1.2 Farbfilter
Die tabellarische Zusammenstellung im Hauptfenster von Ethereal kann durch Farbunterlegungen dargestellt werden. Falls auf eine Zeile eine Filterregel zutrifft, wird sie
den Angaben nach farblich dargestellt.
Abbildung 4-18 zeigt zwei Farbfilter. Alle Pakete, die DNS-Abfragen beinhalten
werden rot hinterlegt und aller HTTP-Daternverkehr wird auf grünem Hintergrund dargestellt. Abbildung 4-19 zeigt die Anwendung dieser Farbfilter auf den BeispielDatenmitschnitt „Startseite der Ruhr-Universität-Bochum“.
Abbildung 4-18: Einfache Farbfilter
27
Kapitel 4
Ethereal
Abbildung 4-19: Anwendung der Farbfilter aus Abbildung 4-18
4.5.2 Analysefunktionen
Ethereal bietet eine Vielzahl an Analysefunktionen. Die Abbildung 4-20 zeigt eine einfache Zusammenfassung eines Datenmitschnittes.
Abbildung 4-20: Zusammenfassung
28
Kapitel 4
Ethereal
Die Informationen in Abbildung 4-21 sind schon detaillierter. Neben der Anzahl der
Pakete, wird dargestellt welchen Anteil die einzelnen Protokollebenen an der Gesamtanzahl haben. Aus der Abbildung ist ersichtlich, dass alle Pakete auf der Datenverbindungsschicht über Ethernet und auf der Netzwerkschicht über das Internet Protokoll
verschickt worden sind. In der Transportschicht sind zwei Pakete mit dem User
Datagram Protocol und die restlichen 79 mit dem Transmission Control Protocol verschickt worden. Die Daten der Transportschicht werden teilweise noch weiter in den
höheren Schichten aufgeschlüsselt. Wie oben bereits erwähnt, stellen die ersten beiden
Pakete eine DNS-Abfrage dar. Im Zweig Transmission Control Protocol sind 53
Pakete über das Hypertext Transfer Protocol verschickt worden. Die restlichen 26
Pakete haben Informationen für den Verbindungsauf- und abbau oder Bestätigungsmeldungen für empfangene Pakete als Inhalt.
Abbildung 4-21: Analysefunktion: Protocol Hierarchy Statistics
29
Kapitel 4
Ethereal
Eine weitere interessante Funktion verbirgt sich hinter dem Menüpunkt Follow TCP
Stream des Tools-Menü von Ethereal. Die Abbildung 4-22 zeigt diese Funktion. Rot
eingefärbt sind gesendete, blau eingefärbt sind empfangene Daten. Der gesamte Datenverkehr wird in logisch richtiger Weise zusammengesetzt. Genutzt werden bei dieser
Funktion die Sequenz- und Quittungsnummern im TCP Protokoll.
Abbildung 4-22: Follow TCP Stream
30
Kapitel 4
Ethereal
Weitere auf TCP-Datenstöme bezogene Funktionen sind unter TCP Stream Analysis zu
finden. Die Aussagekraft der Graphen sind allerdings auf den Datenmitschnitt „Startseite der Ruhr-Uni-Bochum“ recht begrenzt. Daher beziehen sich die folgenden
Abbildung 4-23 bis Abbildung 4-25 auf einen Mittschnitt von 100K Paketen, überwiegend Kommunikation über das SMB-Protokoll im lokalen Netzwerk an einem
10/100 Mbit Dual Speed Hub. Dateiübertragungen fanden zwischen einem MS
Windows 2000 Server (100Mbit) und sowohl einer MS Windows 2000 Professional
Workstation (100Mbit) und einem Windows 95-System (10Mbit) statt.
Abbildung 4-23: TCP Analysefunktion Time/Sequence Graph
Die Abbildung 4-23 zeigt die benutzen Sequenznummern aufgetragen über der Zeit.
Die aufgetragenen Nummern sind relativ zur ersten benutzen Nummer aufgetragen.
Deutlich zu erkennen ist ein inkrementeller Anstieg der Sequenznummern. Die Steigung des Graphen kann bei – in diesem Szenario gerechtfertigter – Annahme ähnlich
großer Datenpakete als Durchsatz interpretiert werden. Die Abbildung 4-24 zeigt den
Graphen für den Durchsatz über der Zeit an. Die Vermutung ausbleibenden Datenverkehres in der Unterbrechung des Time/Sequence Graphen in der Zeit von 13s bis
31
Kapitel 4
Ethereal
16s wird durch die Anzeige des Durchsatzes in Abbildung 4-24 bestätigt. Ebenso der
große Anstieg des Time/Sequence Graphen in der Zeit um 50s. Der Durchsatz-Graph
zeigt in dieser Zeit einen erhöhten Durchsatz an.
Abbildung 4-24: Analysefunktion Throughput Graph
Die letzte Möglichkeit der graphischen Auswertung ist der Round Trip Time Graph
(vgl. Abbildung 4-25). Aufgetragen ist die Verzögerungszeit über der Sequenznummer. Sichtbar ist in einem breitem Bereich der Sequenznummern die Anordnung
der Punkte im Bereich des Nulldurchganges (<10ms). Zwei Dateiübertragungen sind
mit einem Notebook und einer 10 Mbit Netzwerkkarte durchgeführt worden. Diese
Übertragungen sind mit einer sichtbaren Verzögerungszeiten von 10-12ms zu erkennen. Die besonders lange Antwortzeit um die Sequenznummer 450000 ist durch
eine Kommunikation mit Webservern im Internet zu begründen.
32
Kapitel 4
Ethereal
Abbildung 4-25: Analysefunktion RTT Graph
33
Kapitel 5
LibPcap Capture Format
5 LibPcap Capture Format
5.1 Beschreibung
Das LibPcap Capture Format wird von allen Programmen genutzt, die diese Bibliothek
beinhalten. Sowohl Tethereal als auch Ethereal ermöglichen eine Abspeicherung des
Datenmitschnittes in einer binären Datei. Abbildung 5-1 zeigt einen Mitschnitt, angezeigt in einem Hex-Editor, an. Markiert ist genau ein Frame.
Beide Programme bieten die Möglichkeit, abgespeicherte Binärdateien einzulesen und
mit diesen eine Analyse durchzuführen.
Abbildung 5-1: Screenshot der binären Protokolldatei
5.2 LibPcap Format
Das Format enthält neben dem eigentlichen Frame noch drei weitere Felder (vgl.
Abbildung 5-2). Zuerst wird die Ankunftszeit des Frames in einem 8 Byte großem Feld
gespeichert. Die nächsten beiden Felder geben die Größe des Frames an. Das Feld
Frame hat die Größe der aufgezeichneten Länge Capture Lenght.
Arrival Time
8 Byte
Capture Lenght
4 Byte
Packet Lenght
4 Byte
Frame
Capture Lenght
Abbildung 5-2: LibPcap-Format
34
Kapitel 5
LibPcap Capture Format
5.2.1 Arrival Time
Die Zeit wird im Unix Time Format (UTF) abgespeichert. Dieses Format gibt die seit
dem 1. Januar 1970 00:00:00 GMT vergangenen Sekunden an.
Sekunden
4 Byte
20
28
Millisekunden
4 Byte
216
2 24
20
28
216
2 24
Abbildung 5-3: UTF
Die ersten 4 Byte geben die vergangenen Sekunden, die nächsten 4 Byte die
Zeitdifferenz in Millisekunden an. Die einzelnen der 4 Bytes entsprechen den wie oben
angedeuteten Gewichtungen mit Potenzen von zwei, die in dem Beispiel in Abbildung
5-4 verdeutlicht werden. Das Ergebnis ist gleich der Addition der gewichteten Größen.
Sekunden
16
55
C5
197 ⋅ 2
0
22 ⋅ 2
8
16
85 ⋅ 2
3C
60 ⋅ 2
Millisekunden
FC
00
E1
24
225 ⋅ 2
0
252 ⋅ 2
1012209349
8
16
0⋅2
00
0 ⋅ 2 24
064,737
Abbildung 5-4: Beispiel für den 28. Januar 2002 10:15:49.064737000
5.2.2 Capture Lenght und Packet Lenght
Diese beiden Felder geben die tatsächliche Länge des Datenpaketes (Packet Lenght)
und die von Tethereal tatsächlich aufgezeichnete Länge (Capture Lenght) an.
Unterschieden werden diese Angaben aufgrund der Möglichkeit von Tethereal, die
Pakete lediglich bis zu einer bestimmten Länge zu protokollieren, um z.B. nur die
Header Informationen zu speichern. Danach werden weitere im Frame enthaltene
Informationen verworfen.
Capture Lenght
4 Byte
20
28
216
Packet Lenght
4 Byte
2 32
20
28
216
2 32
Abbildung 5-5: Capture und Packet Lenght
35
Kapitel 5
LibPcap Capture Format
5.2.3 Debug Informationen
Das Analyseprogramm kann in mit verschiedenen Debug-Leveln kompiliert werden.
Dabei lassen sich gezielt Informationen zu der Datenverbindungs-, Netzwerk- und
Transportschicht anzeigen. Zusätzlich können, wie in Abbildung 5-6 gezeigt, Informationen des LibPcap Formates angezeigt werden.
Abbildung 5-6: Debug-Informationen eines LibPcap-Headers
5.3 Analyseprogramm und Konvertierung in das Zielformat
Das Analyseprogramm CaptureParser erwartet eine Capture Datei im LibPcap Format.
Die Programmstruktur ist in Abbildung 5-9 dargestellt. Die Abbildung 5-22 zeigt
dieses an einem konkretem Beispiel für ein ICMP Paket.
Das Programm prüft nach dem Start, ob alle Eingabeparameter vorhanden sind,
andernfalls wird die Eingabesyntax wie in Abbildung 5-7 gezeigt ausgegeben.
Abbildung 5-7: Syntax von CaptureParser.
In den Eingabeparameter wird sowohl die Angabe der Ein- und Ausgabedatei als auch
das Vorhandensein der Eingabedatei überprüft. Danach wird überprüft, ob ein nächster
Frame vorhanden ist. Diese Stelle dient gleichzeitig als Sprungstelle, nachdem ein
einzelner Frame analysiert worden ist. Ist kein Frame vorhanden, beendet sich das
Programm mit Ausgabe seiner Programminformationen wie in Abbildung 5-8 dargestellt. Neben den Eingabeparametern wird auch die Anzahl der Pakete und die Dateilänge angezeigt.
36
Kapitel 5
LibPcap Capture Format
Abbildung 5-8: Ausgabe von CaptureParser
Ist ein Frame vorhanden, wird automatisch ein Ethernet Frame angenommen. Aus
diesem werden alle Informationen analysiert und in die Zieldatei geschrieben. Zusätzlich enthält der Ethernet Header die Information über das übergeordnete Programm. Mit dieser Information verzweigt das Analyseprogramm in den Abschnitt, der
das entsprechenden Layer 3 Protokoll enthält. Ist das Protokoll unbekannt, wird dies
protokolliert und der nächste Frame wird untersucht. Handelt es sich um einen IPHeader, wird zusätzlich die Transportschicht untersucht. Hier wird aus dem entsprechenden Feld der IP-Header der Typ übergeordneten Protokolls der Netzwerkebene 4 herausgelesen und das Programm verzweigt an diese Stelle. Ist auch hier ein
unbekanntes Protokoll, wird dies ebenfalls vermerkt und das Programm fährt mit dem
nächsten Frame fort.
Diese Programmstruktur des Analyseprogramms ist in Abbildung 5-9 gezeigt.
37
Kapitel 5
LibPcap Capture Format
Start
Eingabeparameter
vorhanden?
nein
Programm abbrechen
nein
Programm beenden
ja
nächster Frame
vorhanden?
ja
Protokolliere Ethernet II
Headerinformationen
Layer 3?
Protokolliere [??]
unbekannt
Protokolliere [??]
ARP
Protokolliere ARP
Headerinformationen
IP
Protokolliere IP
Headerinformationen
unbekannt
Protokolliere TCP
Headerinformationen
TCP
Protokolliere UDP
Headerinformationen
UDP
Protokolliere ICMP
Headerinformationen
ICMP
Protokolliere OSPF
Headerinformationen
OSPF
Layer 4?
Abbildung 5-9: Programmstruktur
38
Kapitel 5
LibPcap Capture Format
5.3.1 Extrahierte Informationen
Aus den in der Protokolldatei verfügbaren Informationen werden meist nur Teile
benötigt. Diese sind jeweils in den zugehörigen Tabellen zusammengefasst. Die erste
Zeile einer Tabelle gibt jeweils eine Erklärung der einzelnen Felder an, die mittlere
Zeile zeigt die relative Position der Bytes bezüglich des Frame-Anfangs. In der letzten
Zeile wird an einem Beispiel gezeigt, wie diese Informationen bezüglich dieses
Headers ausgegeben werden.
Ausgewertet werden neben dem Ethernet 802.2 die Protokolle IP, TCP, UDP und
ICMP. Die Protokolle ARP und OSPF werden erkannt, aber nicht detailliert aufgeschlüsselt, sondern lediglich mit der Kennung [ARP] bzw. [OSPF] versehen.
Die fettgedruckten Zahlen in der zweiten Zeile jeder Tabelle geben jeweils die Position
der Informationen bezogen auf den Anfang jedes Header an. Setzt sich eine Information aus mehreren Stellen zusammen, ist der Bereich angegeben. Ist ein Wert gewichtet, ist eine Multiplikation mit der Gewichtung im Dezimalformat und gegebenenfalls eine Addition mit einer anderen Stelle angegeben.
Die dritte Zeile gibt ein Beispiel für die Ausgabe im Zielformat an.
5.3.1.1 Ethernet 802.2
Im LibPcap Format werden an dieser Stelle die Informationen zu Sende- und
Empfängeradresse des Ethernets sowie dem Typ gespeichert. Die im Ethernet 802.2
definierten Felder Präambel und Framekontrollsequenz fehlen, werden in der weiteren
Auswertung auch nicht benötigt.
Sende MAC
Empfänger MAC
Typ
Datenteil
6 - 11
12 – 13
max. 1500 Byte
0–6
00:10:4B:45:B4:53;00:A0:C9:CD:81:A1;0800
Abbildung 5-10: Ausgewertete Daten im Ethernet-Frame
Die Abbildung 5-10 zeigt die ausgelesenen Felder des Header eines Ethernet Frames,
diese Informationen können mit den Debug Informationen des Analyseprogramms in
Abbildung 5-11 verglichen werden.
Abbildung 5-11: Debug Informationen Ethernet
39
Kapitel 5
LibPcap Capture Format
5.3.1.2 Internet Protocol
In dieser Protokollschicht werden alle verfügbaren Informationen im LibPcap Format
gespeichert. Abbildung 4-13 zeigt die Positionen der einzelnen Informationen im IP
Header. Die Informationen IP Version, Internet Header Length (IHL) und Flags
beziehen sich jedoch nicht auf ein einzelnes Byte, sondern auf bestimmte Bits
innerhalb dieses Bytes. Durch bitweise UND-Verknüpfung mit der entsprechenden
Maske lassen sich diese Informationen leicht extrahieren.
Src IP
Dst IP IPVersion
IHL
TOS
Flags
TTL
L4-Prot
12 - 15
16 - 19
0 & F0
0 & 0F
6 & E0
1
8
9
[IP];192.168.111.101;192.168.111.111;4;05;00;00;80;1
Abbildung 5-12: Ausgewertete Daten im Internet Protocol
Feld
IP Version
IHL
Flags
Wert
0x45
0x45
0x00
Maske
11110000
00001111
11100000
Ergebnis
4
5
0
Abbildung 5-13: UND-Verknüpfung der Felder
Die Abbildung 5-13 zeigt die detaillierten UND-Verknüpfung um die Felder IP
Version, IHL und Flags aus dem entsprechenden Byte herauszulesen. Das Datenbeispiel kann mit Abbildung 5-14 verglichen werden.
Abbildung 5-14:Debug Informationen IP
5.3.1.3 Transmission Control Protocol
Die Abbildung 5-15 zeigt die Aufschlüsselung des TCP Header. Beide Port Informationen sind auf zwei Bytes aufgeteilt und entsprechend gewichtet. Die Informationen zum Feld Kontrollflag stehen in den untersten 6 Bits des 13. Byte.
40
Kapitel 5
Src Port
0 · 256 + 1
LibPcap Capture Format
Dst Port
Seq. Number
Ack. Number
2 · 256 + 3
4-7
8 - 11
[TCP];1910;80;1852E60F;4E47E6C0;18
Kontrollflag
13 & 3F
Abbildung 5-15: Ausgewertete Daten im Transmission Control Protocol
Die Abbildung 5-15 und Abbildung 5-16 können mit der detaillierten Programmausgabe von Tethereal in Kapitel 4.4.2.1 verglichen werden.
Abbildung 5-16: Debug Informationen TCP
5.3.1.4 User Datagramm Protocol
Src Port
0 · 256 + 1
Dst Port
2 · 256 + 3
[UDP];1880;53;52
Paketlänge
4 · 256 + 5
Abbildung 5-17: Ausgewertete Daten im User Datagramm Protocol
Die in Abbildung 5-17 gezeigten Debug Informationen können mit den in Kapitel
4.4.2.2 ausführlich dargestellten Informationen der Ausgabe von Tethereal verglichen
werden. Zusätzlich zeigt Abbildung 5-18 die kompakten Informationen des Analyseprogramms.
Abbildung 5-18: Debug-Informationen UDP
41
Kapitel 5
LibPcap Capture Format
5.3.1.5 Internet Control Message Protocol
Die Übersicht des ICMP Header ist in Abbildung 5-19 gegeben. Dieses Datenpaket ist
im Kapitel 5.3.2 ausführlich beschrieben. Zum Vergleich stehen die Ausgabeinformationen des Analyseprogramms in Abbildung 5-20 zur Verfügung.
ICMP Typ
0
Code
1
[ICMP];08;00;1385
Checksum
2 · 256 + 3
Abbildung 5-19: Ausgewertete Daten im Internet Control Message Protocol
Abbildung 5-20: Debug Informationen ICMP
5.3.2 Beispiel einer Analyse eines ICMP-Datenpaketes
In diesem Beispiel wird das in Abbildung 5-21 dargestellte Datenpaket betrachtet. Zum
Vergleich sind die ausführliche Informationen in der Ausgabe von Tethereal im
Kapitel 4.4.2.3 angegeben.
Abbildung 5-21: Beispiel ICMP
Die detaillierte Analyse dieses Datenpaketes ist in Abbildung 5-22 dargestellt.
42
Kapitel 5
Frame
LibPcap Capture Format
18
00
00
6f
67
77
40
10
3c
6f
68
61
72
4b
76
08
69
62
3c
45
be
00
6a
63
7c
b4
00
13
6b
64
23
53
00
58
6c
65
09
00
80
02
6d
66
Frame
00 4a
a0 c9
01 63
00 38
6e 6f
67 68
Output
00
cd
dd
04
70
69
00
81
c0
61
71
xx
00
a1
a8
62
72
xx
4a
08
6f
63
73
xx
00
00
65
64
74
xx
00
45
c0
65
75
xx
00
00
a8
66
76
xx
LibPcap
UTF-Zeit
CaptureLenght PacketLenght
18 40 72 3c 7c 23 09 00 4a 00 00 00 4a 00 00 00
Output
20020219;130752598;
[RECHNERNAME];
Daten
Ethernet 802.3
00
00
6f
67
77
10
3c
6f
68
61
4b
76
08
69
62
45
be
00
6a
63
b4
00
13
6b
64
53
00
58
6c
65
00
80
02
6d
66
a0
01
00
6e
67
c9
63
38
6f
68
cd
dd
04
70
69
81
c0
61
71
a1
a8
62
72
08
6f
63
73
00
65
64
74
45
c0
65
75
00
a8
66
76
Ethernet
Src MAC
Dst MAC
L3-Protokoll
00 10 4b 45 b4 53 00 a0 c9 cd 81 a1
08 00
Daten
45
c0
65
75
00
a8
66
76
00
6f
67
77
3c
6f
68
61
76
08
69
62
be
00
6a
63
00
13
6b
64
00
58
6c
65
80
02
6d
66
01
00
6e
67
63
38
6f
68
Output
00:10:4B:45:B4:53;
00:A0:C9:CD:81:A1;
0800;[IP];
dd c0 a8 6f 65
04 61 62 63 64
70 71 72 73 74
69
Layer 3
IP
Version
IHL
4
5
TTL
80
TOS Paketlänge Identifikation Flags Fragmentab
00
3c
76 be
Protokoll Prüfsumme
01
63 dd
Src IP
000
00000
00000000
Src IP
Output
192.168.111.101;192.1
68.111.111;4;05;00;00;
80;1;[ICMP];
c0 a8 6f 65 c0 a8 6f 6f
Daten
08 00 13 58 02 00 38 04 61 62 63 64 65 66 67 68
69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61
62 63 64 65 66 67 68 69
Layer 4
ICMP
Typ
Code
Prüfsumme
unbenutzt
08
00
13 58
02 00 38 04
Output
08;00;1358
Daten
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
Abbildung 5-22: Analyse eines ICMP-Paketes
43
Kapitel 5
LibPcap Capture Format
Ausgehend von einem Frame-Beginn werden im ersten Schritt die Informationen des
LibPcap Header ausgewertet. Die „xx xx xx xx xx xx“ deuten Daten des nächsten
Frames an. In die Zieldatei wird an dieser Stelle Datum und Uhrzeit geschrieben. Das
Feld CaptureLenght gibt nun die genau Länge des Frames an. Diese Daten werden der
Analyseeinheit für Ethernet übergeben. In der Ausgabedatei werden die MAC
Adressen sowie das Layer 3 Protokoll hinzugefügt. Die restlichen Daten, sowie die
Information über den Layer 3 Protkoll werden im nächsten Schritt benötigt. Der Typ
entscheidet über die weitere Analysestruktur. Das Feld Protokoll verzweigt im
nächsten Schritt auf die Analysefunktion eines ICMP Headers.
5.3.3 Ausgabe des Analyseprogramms
Das Analyseprogramm liest die Capture Dateien im LibPcap Format ein und gibt die
benötigten Informationen im gewünschten Format wieder aus. Abbildung 5-23 zeigt
eine solche Ausgabedatei an. Die Zeilenumbrüche sind eingefügt worden, um die
Lesbarkeit zu verbessern. Die erste Zeile jedes Datenpaketes gibt Datum und Uhrzeit,
Rechnername, Sende- und Empfänger-MAC-Adresse sowie den Typ des übergeordneten Protokolls an. Die nächste Zeile gibt in diesem Fall die Informationen des IP
Protokolls, die letzte Zeile die des TCP Protokolls wieder.
Abbildung 5-23: Ausgabe von CaptureParser
44
Kapitel 6
Dienste
6 Dienste
6.1 Allgemein
Dienste laufen als eigenständige Prozesse im Hintergrund ab, ohne dass Benutzereingaben möglich oder notwendig sind. Die auf dem Ethereal Projekt aufbauende
Monitoring Software soll als NT Dienst konzipiert sein. Aufgrund der hohen Komplexität von Ethereal ist es mit angemessenem Aufwand nicht möglich, Ethereal selbst
als Dienst anzupassen. Auch wäre es so nicht möglich, die ständige Weiterentwicklung
von Ethereal zu berücksichtigen. Stattdessen besteht die Möglichkeit, die Kommandozeilenversion Tethereal im Hintergrund aus einem NT Dienst heraus zu starten und den
Datenmitschnitt als binäre Protokolldatei zu speichern. Die Auswertung der Daten
geschieht explizit nicht in diesem Schritt, um an dieser Stelle keine weiteren CPU
Ressourcen zu nutzen.
Tethereal erkennt die Anzahl der nicht berücksichtigten Pakete und gibt dieses als
Meldung „packets dropped“ an. Dies tritt bei sehr hohem Datendurchsatz und vielen
IO Operationen des Rechners auf. In Abbildung 6-1 ist dieser Fall durch sehr starke
Nutzung der lokalen Festplatte simuliert worden. Diese Information sollte nicht
verloren gehen.
Abbildung 6-1: Paketverluste von Tethereal
6.2 Aufrufe von Programmen
Ein Aufruf von anderen Programmen kann über mehrere Verfahren erfolgen. Für die
vorliegende Problemstellung sind zwei Kriterien von wesentlicher Bedeutung:
• Parameterübergabe an das Programm
• Protokollierung der Programmausgabe
Die Realisierung mit einfachen spawn Befehlen unter C++ ist nicht möglich, da mit
diesem Befehl die Ausgabe von Tethereal verloren geht.
Eine Möglichkeit, dieses zu umgehen, liegt im Befehl popen. Hierbei wird ein
Programmaufruf initiiert und gleichzeitig eine Pipe mit der Ausgabe stdout dieses
45
Kapitel 6
Dienste
Programms verbunden. Das Problem ist jedoch, dass Tethereal die gewünschten
Informationen nicht an stdout, sondern an stderr weitergibt.
Letztendlich konnte das Problem mit dem Befehl system gelöst werden. Dieser
Befehl startet einen Systenaufruf, dessen stderr-Ausgabe mit „2>“ in eine Datei umgelenkt werden kann.
Ein Aufruf von Tethereal hat beispielsweise folgende Syntax:
tethereal.exe –c 1000 –w log.bin 2> log.txt
6.3 Alternative: srvany.exe
Eine weitere Möglichkeit, zum Aufruf eines Programmes aus einem Dienst heraus
bietet das Tool „srvany.exe“ aus dem Microsoft Windows NT Server 4.0 Resource Kit.
Mit diesem Tool ist es nicht nötig, das ursprüngliche Programm als Dienst zu
realisieren, es reicht eine übliche Kommandozeilenapplikation. Der eigentliche Dienst
ist bereits in srvany.exe implementiert. Srvany.exe läuft als Dienst und ruft das
Kommandozeilenprogramm auf.
Die Installation von srvany.exe ist einfach. Das Programm „instsrv.exe“ aus dem
Resource Kit registriert beliebige Dienste im Service Control Manager (SCM).
Abbildung 6-2: Hilfetext von instsrv.exe
Das oben aufgeführte Beispiel würde das Programm „DiskService“ unter dem
Dienstnamen „MyService“ installieren.
In Verbindung mit srvany.exe ist folgender Aufruf der Form instsrv Capture
C:\winnt\srvany.exe notwendig. An dieser Stelle ist der Dienst srvany.exe mit
dem Dienstnamen Capture installiert. Wiederzufinden ist dieser Dienst unter „Dienste
und Anwendungen“ und in der Systemregistrierung unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Capture.
46
Kapitel 6
Dienste
Abbildung 6-3: Dienst „Capture“ unter Windows 2000
Im weiteren muss das Programm spezifiziert werden, dass die eigentliche Aufgabe
ausführen soll. Dies geschieht in der Systemregistrierung im oben angegebenen
Bereich. Eingefügt werden muss eine Zeichenfolge mit Namen „Application“ von Typ
REG_SZ, die den vollen Pfadnamen des Programmes enthalten muss.
Abbildung 6-4: „Capture“ in der Systemregistrierung
Ein Nachteil dieser Lösung ist erhöhte Ressourcenverbrauch durch den Dienst
srvany.exe. Durch den kaskadierten Aufrufe von Programmen ist auch mit einer
verlangsamten Verarbeitungsgeschwindigkeit und einer erhöhten Fehleranfälligkeit zu
rechnen.
srvany.exe
ruft auf
capture.exe
ruft auf
tethereal.exe
Abbildung 6-5: Kaskadierter Aufruf von Prgrammen
47
Kapitel 6
Dienste
6.4 Realisierung
Um diesen kaskadierten Aufruf nicht durchführen zu müssen und um über erweiterte
Möglichkeiten der Dienststeuerung und Protokollierung zu verfügen, ist das Programm
als eigenständiger NT Dienst realisiert worden.
In ein festgelegtes Zielverzeichnis werden sowohl die binären Protokollmitschnitte als
auch die zugehörige Ausgabe von Tethereal gespeichert. Jede Datei trägt als Dateinamen das aktuelle Datum und die aktuelle Uhrzeit. Abbildung 6-6 zeigt Beispiele für
die Syntax JJJJMMTTHHMMSS.
Abbildung 6-6: Protokollverzeichnis von Capture-Service
6.4.1 Programmstruktur
Die Programmstruktur des Dienstes ist in Abbildung 6-7 gezeigt. Ausgehend von
einem Startbefehl des Service Control Managers (SCM) startet der Dienst und registriert sich sowohl beim SCM als auch bei der Ereignisanzeige. Beiden Instanzen
wird der Startbefehl mitgeteilt. Ist der Dienst gestartet, wirkt der SCM direkt auf die
boolsche Variable bRun. Ist diese Variable false, wird der Dienst gestoppt und das
Ereignis wird der Ereignisanzeige und dem SCM mitgeteilt.
Ist der Wert true, wird der Thread gestartet, der letztendlich Tethereal aufruft. Nach
jedem Durchlauf von Tethereal wird bei gleichzeitigem true der Variablen bRun ein
48
Kapitel 6
Dienste
weiterer Thread gestartet und danach der ursprüngliche Thread beendet. Erreicht die
Variable den Wert false, wird kein weiterer Thread gestartet.
START_SERVICE_EVENT
start
main()
registriert
Dienst
START
PENDING
SERVICE
RUNNING
Dienst wird gestartet
Thread starten
register Event
Handles
Dienst gestartet
Event
Log
SCM
true
Tethereal starten
true
bRun
Tethereal beendet
false
STOP
PENDING
STOPPED
Dienst wird gestoppt
unregister Event
Handles
Dienst beendet
SERVICE_STOPPED_EVENT
bRun
true
false
Thread beenden
ServiceMain
Thread
Abbildung 6-7: Programmstruktur des Dienstes
Die fettgedruckten Linien in Abbildung 6-7 zeigen die aktiv vom SCM ausgehenden
Befehle. Eine Meldung an die Prozedur main() startet den Dienst, die Dienststeuerung
erfolgt durch direktes Einwirken auf die Variable bRun, die den Wert true bei aktiven
Dienst und den Wert false bei ausgeschaltetem Dienst annimmt.
Die beiden Hauptkomponenten, die ServiceMain Routine des Dienstes selbst und der
Thread, der die Aufrufe von Tethereal übernimmt, sind mit grauen Kästchen hinterlegt.
49
Kapitel 6
Dienste
Die weiteren externen Instanzen Ereignisanzeige (EventLog) und Service Control
Manager (SCM) sind in den Rechtecken an der linken Seite verdeutlicht.
6.4.2 EventLog Komponenten
Zusätzlich zum Dienst wird eine Dynamic Link Library benötigt, die die Textelemente
enthält, die letztendlich im EventLog protokolliert werden. Dazu muss eine MessageDatei angelegt werden, die zu jedem symbolischen Namen den Text des Ereignisses
bereitstellt (vgl. Abbildung 6-8).
Abbildung 6-8: Message Datei
6.4.3 Installation
Die Installation erfolgt in zwei Teilschritten. Zuerst muss der Dienst registriert werden,
danach muss dem Ereignisprotokolldienst mitgeteilt werden, an welcher Stelle das
Event-Message File gesucht werden muss.
6.4.3.1 NT Dienst
Der NT Dienst NP-Suite: CaptureParser-Service wird über die Installationsroutine
ServiceInstall.exe installiert. Die Syntax ist in Abbildung 6-9 angegeben.
50
Kapitel 6
Dienste
Abbildung 6-9: Syntax von ServiceInstall.exe
Nach erfolgreicher Installation ist der markierte Eintrag in der Dienstanzeige wie in
Abbildung 6-10 hinzugefügt worden.
Abbildung 6-10: Dienst Capture-Service
Nach dem Start des Dienstes sind im Task Manager die Prozesse NPs_cs.exe und
Tethereal.exe bemerkbar.
6.4.3.2 Ereignisanzeige
Damit der Dienst Einträge in die Ereignisanzeige schreiben kann, muss der Ereignisanzeige selbst der Pfad für die benötigte Message Datei übergeben werden. Anhand
dieser werden symbolische Namen in Ereignistexte umgesetzt. Der Eintrag in der
Systemregistrierung ist in Abbildung 6-11 gezeigt.
51
Kapitel 6
Dienste
Abbildung 6-11: Registrierung der EventLog Komponenten
Statusmeldungen des Dienstes werden wie in Abbildung 6-12 in die Ereignisanzeige
geschrieben.
Abbildung 6-12:Ereignisanzeige
52
Kapitel 7
Test
7 Test
7.1 Testumgebung
Die Testumgebung besteht aus 3 Computern, die über einen 3Com SuperStack II Dual
Speed Hub verbunden sind. Auf allein drei Rechnern werden ausschließlich die
Protokolle Ethernet und TCP/IP benutzt.
Die Merkmale der Computer ist in Abbildung 7-1 zusammengefasst. Die einzelnen
Rechner werden im weiteren Kapitel mit Fileserver, Workstation und Webserver
bezeichnet.
Fileserver
Microsoft Windows 2000
Server SP2
1024 MB RAM
Dual Pentium III 500 MHz
3Com Etherlink XL 10/100
IBM DTLA-305040
Workstation
Microsoft Windows 2000
Professional SP2
256 MB RAM
Pentium II 350 MHz
Intel Management Pro 100
IBM DJNA-352030
Webserver
Suse Linux 7.3
256 MB RAM
Celeron 1GHz
Intel Management Pro 100
IC35L040AVER07-0
Abbildung 7-1: Testumgebung
7.2 Capture-Service
Der Systemprozess NPc_cs.exe benötigt sowohl bei geringen als auch bei hohen
Netzwerkauslastungen kaum CPU Ressourcen. Tethereal hingegen abhängig vom
Netzwerkverkehr nimmt doch erhebliche Ressourcen in Anspruch.
Untersucht werden zwei Arten von Netzwerkverkehr: eine Dateiübertragung einer 100
MB Datei über FTP und bei maximaler Auslastung der Bandbreite.
Jeder Fall wird durch vier weitere Kombinationen untersucht. Abbildung 7-2 zeigt die
verschieden Aufzeichnungsmöglichkeiten. Die waagerechten Pfeile geben die an der
Datenübertragung beteiligten Rechner an, der senkrechte Pfeil jeweils den Computer,
auf dem der Datenmitschnitt erfolgt. Der Testfall „Benutzer arbeitet“ wird sowohl
durch die Nutzung von Microsoft Office als auch die Verwendung von Matlab
simuliert.
53
Kapitel 7
Test
Fileserver
Workstation
Webserver
Ethernet
1.
Passiv
Fremder Stream
2.
Aktiv
Fremder Stream
Benutzer arbeitet
3.
Aktiv
Eigener Stream
4.
Aktiv
Eigener Stream
Abbildung 7-2: Testfälle
7.2.1 Dateiübertragung
Simuliert wird die Dateiübertragung durch eine Übertragung einer 102 MB großen
Datei. Bereitgestellt wird sie auf dem Webserver durch einen ProFTPD 1.2.2 Server.
Die Anzahl der Pakete dieser Datei beträgt ungefähr 120.000. Die Abbildung 7-3 zeigt
die während dieser Übertragung aufgenommene CPU-Nutzung und die verlorenen
Pakete.
Testfall
Beschreibung
1 Fileserver
Fileserver
zeichnet
fremden
Stream auf
1 Workstation Workstation
zeichnet
fremden
Stream auf
Verlauf der CPU-Nutzung
Verlorene
Pakete
0
125
54
Kapitel 7
Testfall
Test
Beschreibung
2 Word
Workstation
zeichnet
fremden
Stream auf
2 Matlab
Workstation
zeichnet
fremden
Stream auf
3 Fileserver
Fileserver
zeichnet
eigenen
Stream auf
4 Workstation Workstation
zeichnet
eigenen
Stream auf
Verlauf der CPU-Nutzung
Verlorene
Pakete
1.423
26.324
1.124
58.547
Abbildung 7-3: Dateiübertragung FTP
7.2.2 Nutzung der maximalen Bandbreite
In diesem Testfall kann auf eine detaillierte Darstellung der CPU-Ressourcen
verzichtet werden. Diese liegt in allen Testfällen auf dem Maximum. Generiert werden
die Pakete auf dem Webserver mit Hilfe des Dienstprogramms „bing“. Die Mittelwerte
aus jeweils fünf Messungen ergeben die Tabelle in Abbildung 7-4. Die Anzahl der
verlorenen Pakete bezieht sich auf 1.000.000 aufgezeichnete Pakete.
Testfall
1 Fileserver
1 Workstation
2 Word
2 Matlab
3 Fileserver
4 Workstation
Beschreibung
Fileserver zeichnet fremden Stream auf
Workstation zeichnet fremden Stream auf
Workstation zeichnet fremden Stream auf
Workstation zeichnet fremden Stream auf
Fileserver zeichnet eigenen Stream auf
Workstation zeichnet eigenen Stream auf
Verlorene Pakete
547.550
1.121.312
2.427.635
3.212.214
687.245
3.545.931
Abbildung 7-4: Paketverluste im Grenzfall
55
Kapitel 7
Test
Es zeigt sich deutlich eine stark reduzierte Leistung bei erhöhter Rechnernutzung. Ein
Vergleich von „1 Workstation“ mit „4 Workstation“ zeigt eine deutlichen Anstieg der
Paketverluste bei angestiegener CPU-Nutzung durch das Beantworten der ECHOPakete. Der Vergleich von „1 Fileserver“ mit „3 Fileserver“ zeigt nur einen geringen
Anstieg der Paketverluste. In diesem Fall konnten notwendige CPU Ressourcen durch
den zweiten Prozessor bereitgestellt werden.
Drastischer erhöhen sich die Paketverluste bei direkter Benutzung des aktiven Systems.
Hier zeigt sich besonders eine Anstieg der Paketverluste bei mehrfachen Festplattenzugriffen.
7.3 Capture-Parser
Im Gegensatz zum NT-Dienst kommt es bei diesem Programm nicht auf eine
schonende Auslastung der CPU Ressourcen an. Das Programm liest die Eingabedatei
ein und verarbeitet mit maximaler Geschwindigkeit die Daten, um sie in der Ausgabedatei abzuspeichern.
Die benötigte Zeit für eine Binärdatei im LibPcap Format mit einer Länge von
1.000.000 Pakten bewegt sich auf dem Fileserver bei ungefähr 9 Minuten. Die Dateigröße der Eingabedatei betrug 1.1 GB, die der Ausgabedatei lediglich 156 MB. Dies
ergibt eine durchschnittliche Zeit pro Paket von 0,54 Millisekunden.
56
Kapitel 8
Ausblick
8 Ausblick
8.1 Verbesserungen
Eine Verbesserungswunsch ist die Vermeidung der Paketverluste bei hohem Netzwerkverkehr. Da jedoch die Datenaufnahme allein durch das Programm Tethereal
geschieht, ist an dieser Stelle keine Optimierung möglich. An dieser Stelle kann jedoch
Tethereal mit anderen verfügbaren Programmen wie WinDump verglichen werden.
8.2 Schwächen
Der NT Dienst NP-Suite: CaptureParser-Service lässt sich nur mit im Programm fest
verankerten Parametern aufrufen. An dieser Stelle scheitert besonders der Versuch, die
in C++ vorhandenen Routinen GetPrivateProfileInt() bzw. GetPrivateProfileString() in den Dienst zu implementieren. Diese ermögliche ein Einlesen
von INI-Dateien wie in Abbildung 8-1.
Abbildung 8-1: INI-Datei
Die Abbildung 8-2 zeigt ein einfaches funktionierendes Beispiel wie dieser Einlesevorgang in C++ definiert wird. Dieses Beispiel lässt sich jedoch nicht in den NTDienst übernehmen.
#include <stdio.h>
#include <windows.h>
char *FileNameINI = "C:\\capture.ini";
int AnzahlPakete;
char PfadTetherealEXE[255];
char LogDir[255];
int main(int argc, char *argv[])
{
AnzahlPakete=GetPrivateProfileInt(("Parameter"),("Pakete"),60,
57
Kapitel 8
Ausblick
(FileNameINI));
GetPrivateProfileString(("Pfade"),("Tethereal"),
"default",PfadTetherealEXE,50, (FileNameINI));
GetPrivateProfileString(("Pfade"),("LogDir"), "default",LogDir,50,
(FileNameINI));
printf("Pfad Tethereal
printf("Pfad LogDir
printf("Anzahl der Pakete
%s\n",PfadTetherealEXE);
%s\n",LogDir);
%d\n",AnzahlPakete);
return 0;
}
Abbildung 8-2: ReadINI
58
Kapitel 9
Literatur
9 Literatur
[MIC00] Microsoft Corporation
MS Windows NT 4 Server: Die technische Referenz, Netzwerk
Microsoft Press, Redmond 1996
[MIC01] Microsoft Corporation
MS Windows 2000 Server: Die technische Referenz, Verteilte Systeme
Microsoft Press, Redmond 2000
[MIL98] Miller, Kevin
Professional NT Services
Wrox Press, Birmingham 1998
[WIL97] Willms, Gerhard
C++, Das Grundlagenbuch
Data Becker, Düsseldorf 1997
[CIS99] Cisco Systems, Inc.
Internetworking Technology Overview, June 1999
http://www.cisco.com
[BAU99] Baumann, Heiko
Entwicklung eines Softwaretools zur Protokollierung und Analyse des
Datenstroms in Netzwerken
Diplomarbeit D344, Lehrstuhl für Datenverarbeitung
Ruhr-Universität Bochum,
Bochum 1999
[KIS01] Kisner, Thorsten
Redundanz bei der Kommunikation im Internet
Seminar Datenverarbeitung SS 01, Lehrstuhl für Datenverarbeitung
Ruhr-Universität Bochum, Bochum 2001
[Eth02]
Ethereal – A free network protocol analyzer for Unix and Windows.
http://www.ethereal.com
[Pcap01] WinPcap – The Free Packet Capture Architecture for Windows
http://netgroup-serv.polito.it/winpcap
59
Kapitel 9
Literatur
[TCP97] TCPDUMP
http://www.ethereal.com/tcpdump.8.html
60