Lehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber

Transkript

1 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: cand.-ing. Thorsten Kisner Matrikel-Nummer: Betreuer: Dipl.-Ing Thomas Droste Bearbeitungszeitraum: WS 2001/02

2 Inhalt Inhalt 1 Einleitung Grundlagen der Netzwerkkommunikation Das OSI Schichtenmodell Network Driver Interface Specification (NDIS) Logical Layer (Layer 2) Beschreibung der Funktionen Ethernet Network Layer (Layer 3) Beschreibung der Funktionen Internet Protocol Transport Layer (Layer 4) Beschreibung der Funktionen Ports Transmission Control Protocol User Datagramm Protocol Internet Control Message Protocol Problemstellung Ethereal Beschreibung Windows Packet Capture Driver (WinPcap) Kernel Ebene: Packet Capture Driver Benutzer Ebene: Packet Capture Library Installation Kompilieren des Projektes Benötigte Pakete Zusätzliche Pakete Umgebungsvariabeln und Aufruf des Compilers Tethereal Capture-Filterregeln Tethereal Verbose-Ausgabe Ethereal Anzeigoptionen Analysefunktionen LibPcap Capture Format Beschreibung

3 Inhalt 5.2 LibPcap Format Arrival Time Capture Lenght und Packet Lenght Debug Informationen Analyseprogramm und Konvertierung in das Zielformat Extrahierte Informationen Beispiel einer Analyse eines ICMP-Datenpaketes Ausgabe des Analyseprogramms Dienste Allgemein Aufrufe von Programmen Alternative: srvany.exe Realisierung Programmstruktur EventLog Komponenten Installation Test Testumgebung Capture-Service Dateiübertragung Nutzung der maximalen Bandbreite Capture-Parser Ausblick Verbesserungen Schwächen Literatur

4 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

5 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 ISO 1 /OSI 2 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

6 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 NDIS 3 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 4. Transport NetBIOS-Treiber Redirector Server Winsock-Treiber Transport Driver Interface 3. Netzwerk Transport Protokolle Streams 2. Datenverbindung LLC MAC NDIS-Schnittstelle Treiber d. Netzwerkkarten NDIS- Netzwerkkartentreiber 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

7 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) 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: LLC, CSMA/CD, 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 Ethernet 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

8 Kapitel 2 Grundlagen der Netzwerkkommunikation Präambel Zieladresse Sendeadresse Typ Datenteil Framekontrollsequenz 8 Byte 6 Bytes 6 Bytes 2 Bytes max Bytes 4 Bytes Abbildung 2-3: Ethernet Frame 2.4 Network Layer (Layer 3) 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 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 ( ) will ein Paket an Host B ( ) senden. Diese Quellund Zieladressen werden in den Feldern des IP-Frames eingetragen. Er findet in seiner IP-Routingtabelle für das Zielnetz das Gateway 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

9 Kapitel 2 Grundlagen der Netzwerkkommunikation Host A MAC: 00:10:4B:45:B4:53 IP: IP-Routingtabelle Netzwerkziel Gateway Router MAC: 00:AF:C4:D6:3B:9C IP: MAC: 00::3C:42:4E:5B IP: IP-Routingtabelle Netzwerkziel Gateway Host B MAC: 00:80:C8:87:BB:EF IP: IP-Routingtabelle Netzwerkziel Gateway Ethernet 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 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 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

10 Kapitel 2 Grundlagen der Netzwerkkommunikation 2.5 Transport Layer (Layer 4) 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 Ports Speziell auf das TCP/IP Protokoll bezogen, sind Ports in der Transportschicht angesiedelt. Es sind 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 Webserver Service Access Point Sockets Socket Ports Transport Layer Abbildung 2-6: Ports und Sockets 9

11 Kapitel 2 Grundlagen der Netzwerkkommunikation 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 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 Sendeport Empfängerport Sequenznummer Quittungsnummer Abstand Reserviert Kontrollbits Fenstergröße Prüfsumme Urgent-Zeiger Optionen 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 DATENPAKET DATENPAKET Host B Sequenznummern werden vergeben DATE 1 NPAK 2 ET 3 Empfangsbestätigungen werden geschickt NPAK DATE ET Sequenznummern ergeben richtige Reihenfolge Abbildung 2-8: TCP Sequenznummern 10

12 Kapitel 2 Grundlagen der Netzwerkkommunikation 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 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

13 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

14 Kapitel 4 Ethereal 4 Ethereal 4.1 Beschreibung Ethereal ist ein Protokoll-Analysator für MS Windows und Unix. Es ist ein Open- Source 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

15 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 User Level Dynamic Link Library packet.dll Packet Capture Driver packet.sys NDIS Kernel Level Datenpaket 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 Biblio- 14

16 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 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 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 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

17 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 Include- Dateien und andere Programme lediglich als Hilfsmittel benötigt 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 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 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

18 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

19 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

20 Kapitel 4 Ethereal 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 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 DNS 4 -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

21 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 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 Verneinung des folgenden Ausdruckes && oder and UND-Verknüpfung oder or ODER-Verknüpfung Abbildung 4-11: Boolsche Verknüpfungen 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

22 Kapitel 4 Ethereal host A host A and host B host A and not (host B or host C) icmp and host A 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. src host A and (port 20 or port 21) Ausgehenden FTP-Verkehr von Host A. icmp[0] = 8 Nur ICMP Echo Requests. icmp[0]!= 8 and icmp[0]!= 0 ICMP-Pakete, die keine Echo Requests oder Replies sind. tcp[13] & 3!= 0 Start und Ende Pakete (SYN und FIN) einer TCP-Kommunikation. Abbildung 4-12: Beispiele für Filteregeln 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 Transmission Control Protocol Frame 1 (337 on wire, 337 captured) Arrival Time: Feb 22, :39: Time delta from previous packet: seconds Time relative to first packet: 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 ( ), Dst Addr: img.web.de ( ) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) = Differentiated Services Codepoint: Default (0x00) = ECN-Capable Transport (ECT): = ECN-CE: 0 Total Length: 323 Identification: 0xd571 Flags: 0x04 21