Projektaufgabe 4 Netzüberwachung mit Ethereal

Projektaufgabe 4 Netzüberwachung mit Ethereal Seite Inhalt 2 Einleitung 2 Konfiguration 3 Struktur eines Ethernet-Frames 3 Sehr kleine und sehr große ICMP-Pakete 6 Struktur eines IP-Pakets 8 Struktur eines UDP-Pakets 9 POP3-Verbindungen 15 FTP-Verbindungen (Mitschneiden von Passwörtern mit Dsniff) 18 Zusammenfassung Seite 1

Einleitung Mit Hilfe der Analysewerkzeuge ethereal, tcpdump und dsniff sollte der Datenverkehr in lokalen Netzen (Labornetz) aufgezeichnet und untersucht werden. Die dafür nötige Testumgebung sollte erarbeitet, realisiert und dokumentiert werden. Speziell wurden dann folgende Analysen durchgeführt: - Struktur eines Ethernet-Frames - Sehr kleine und sehr große ICMP-Pakete - Struktur eines IP-Pakets - Struktur eines UDP-Pakets - POP3-Verbindungen - FTP-Verbindungen (Mitschneiden von Passwörtern mit Dsniff) Konfiguration Auf Grund von Sicherheitsaspekten simulierten wir mit Hilfe von VMware ein Linux- System mit dem wir unsere Analysen durchführen konnten, da wir hierbei root-rechte benötigten. Als erstes wurden die für unsere Analyse nötigen Pakete installiert. Nach der Installation erfolgte ausgiebiges Testen und Erforschen der zu benutzenden Programme. Ferner haben wir unser VMware-Image auf einen Laptop kopiert, um unabhängig von den Labor-Öffnungszeiten arbeiten zu können. Außerdem stellte sich recht schnell heraus, dass einige der geforderten Analysen wegen technischer Gegebenheiten im Labornetz nicht durchführbar waren. Es gab nämlich strikte Restriktionen, was den Datenverkehr nach Außen betraf. So blieb uns die Möglichkeit auf dem Laptop selbst oder direkt in der VMware Datenverkehr zu erzeugen, welchen wir analysierten. Außerdem installierten wir die Windows-Version von Ethereal, um auch unabhängig von der VMware agieren zu können. Aufgrund des gleichen Funktionsumfangs von TCPdump und Ethereal konnten wir alle geforderten Analysen mit beiden Programmen durchführen. Wir konnten somit TCPdump zur Aufzeichnung und Filterung der Pakete nutzen und bereiteten diese mittels Ethereal grafisch ansprechend und übersichtlich auf. Zu den Unterschieden zwischen beiden Tools lässt sich sagen, dass sich diese Grundsätzlich auf die Usability und Benutzerfreundlichkeit beschränkt: Dadurch, dass TCPdump Kommandozeilenbasiert arbeitet, ist es zwar weniger intuitiv und benutzerfreundlich in der Bedienung, aber dafür schneller und portabler. Vor allem lässt es sich von jedem Rechner aus bedienen. (insbesondere wichtig in Hinblick auf Remote-Administration) Ethereal hingegen ist benutzerfreundlicher und die Auswertung kann sehr übersichtlich erfolgen. Nachfolgend die Einzelnen Analysen im Detail. Seite 2

1. Struktur eines Ethernet-Frames Eine der ältesten Framestrukturen ist Ethernet II. Charakteristisches Merkmal von Ethernet II ist das Typfeld, das aus zwei Bytes im Anschluss an die Start- und Zieladressen besteht und der Unterscheidung verschiedener höherer Protokolle dient. Alle anderen Formate enthalten hier eine Längeninformation. Die Unterscheidung der anderen Frames von einem Ethernet-II-Frame kommt dadurch zu Stande, dass dessen Typ-Nummer immer größer ist als die maximale Paketgröße von 1518 Bytes (Z.B. 0800h für IP, 8137h für IPX, 0600h für XNS oder 809Bh für AppleTalk). Ein Datenpaket besteht aus 576 bis 12208 Bits und hat folgenden Aufbau: Frame Ethernet Version 2.0 Bitfolge Bitfolge 1010101010... 10101011 Preamble SFD 6 Byte Dest.- Addr. Ethernet-Frame, min. 64 Bytes, max. 1518 Bytes 6 Byte Source- Addr. 2 Byte Type min. 46 Bytes, max. 1500 Bytes Daten 4 Byte FCS Inter Frame Gap 9,6µs Die Präambel dient zur Synchronisation, sie besteht aus einer Folge von '10101010'- Bytes. Der SFD hat an der letzten Stelle eine '1' (10101011). Die Längen der einzelnen Teile (in Byte) sind in der Grafik eingetragen. Sind weniger als 46 Datenbytes zu übertragen, muss mit Füllbits ergänzt werden, um die minimale Slot-Time zu erreichen. Destination: ist die Zieladresse. Source: die Anfrageadresse in diesem Fall Wir. Unter Address ist die Mac-Adresse der jeweiligen Netzwerkkarte zu sehen. 2. Sehr kleine und sehr große ICMP-Pakete Das Internet Control Message Protocol (ICMP) benutzt wie TCP und UDP das Internet Protocol (IP), ist also ein Teil der Internetprotokollfamilie. Es dient in Netzwerken zum Austausch von Fehler- und Informationsmeldungen. Obwohl ICMP eine Ebene über IP angeordnet ist (im OSI-Modell die so genannte Vermittlungsschicht (Network Layer)), ist es in IP integriert. Es wird von jedem Router und jedem Rechner erwartet das ICMP-Protokoll zu unterstützen. Die meisten ICMP- Pakete enthalten Diagnose-Informationen. Sie werden vom Router zur Quelle zurückgeschickt, wenn der Router Pakete verwirft, z. B. weil das Ziel nicht erreichbar ist, die TTL abgelaufen ist, usw. Es gilt der Grundsatz, dass ein ICMP-Paket niemals ein anderes ICMP-Paket auslöst, d.h. die Tatsache, dass ein ICMP Paket nicht zugestellt werden konnte, wird nicht durch ein Weiteres signalisiert. Eine Ausnahme zu diesem Seite 3

Grundsatz bildet die Echo-Funktion. Echo-ICMP-Pakete werden z. B. durch das Programm Ping verschickt. ICMP-Nachrichten werden beim Versand im Datenteil von IP-Datagrammen eingekapselt. Dabei sind im IP-Header der Servicetyp immer 0 und die Protokollnummer immer 1. Sehr kleines ICMP request großes ICMP request Den Unterschied der gesendeten (request) Pakete zwischen sehr klein und groß erkennt man anhand der Bilder schon an der Größe Data (1 byte) zu Data (1400 byte). Anhand der Checksum sehen wir, dass die Übermittlung geglückt ist (correct). Seite 4

Sehr kleines ICMP reply großes ICMP reply Wie schon beim request ist auch beim reply der Unterschied die Größe der gesendeten Daten. Bei sehr klein sind es gerade mal 1 Byte wohingegen es beim großen schon 56 Bytes sind. Anhand des [correct] bei der Checksum sehen wir das auch diesmal alle Daten übertragen wurden. Um diese Auswertung durch zu führen, sendeten wir mehrere pings an die Adresse 64.233.183.103. Seite 5

Der Ethernetframe unter ICMP Wie man anhand der Bilder gut erkennen kann, gibt es auf den ersten Blick keine Unterschiede. Allerdings erkennt man, wenn man das Ganze im Hex-Editor betrachtet, dass beim großen request wesentlich mehr Daten übermittelt werden. Das liegt daran das im kleinen request nur die wesentlichen Daten übermittelt werden und beim großen noch zusätzliche Daten für das ICMP generiert werden. 3. Struktur eines IP-Pakets Das Internet Protokoll (IP) ist ein in Computernetzen weit verbreitetes Netzwerkprotokoll. Es ist eine (bzw. die) Implementierung der Internet-Schicht des TCP/IP-Modells bzw. der Vermittlungs-Schicht (Network Layer) des OSI-Modells. IP bildet die erste vom Übertragungsmedium unabhängige Schicht der Internet-Protokoll- Familie. Das bedeutet, dass mittels IP-Adresse und Subnetzmaske (subnet mask) Computer innerhalb eines Netzwerkes in logische Einheiten, so genannte Subnetze, gruppiert werden können. Auf dieser Basis ist es möglich, Computer in größeren Netzwerken zu adressieren und Verbindungen zu ihnen aufzubauen, da logische Seite 6

Adressierung die Grundlage für Routing (Wegewahl und Weiterleitung von Netzwerk- Paketen) ist. Das Internet Protokoll stellt somit die Grundlage des Internets dar. Am Anfang des Pakets steht immer die Versionsnummer, in diesen Fall ist es die Version 4. Der Header length, gibt die Länge des IP Headers in 32 Bit Worten ( =4 Byte) an. Die Länge des IP-Headers ist meistens konstant 20 Byte bzw. 5*32 Bit. Wird allerdings das Option-Feld verwendet, verändert sich die IP-Header Länge um einen variablen - von der jeweiligen Option abhängigen - Wert. Darum ist das Header Length Feld nötig, um den so erweiterten Header vom Datenteil des IP Pakets unterscheiden zu können. Mit seinen vier Bit kann das Header Length Feld maximal eine Länge von 2 4-1 (=15) darstellen; ein IP Header kann also nicht länger als 15*32 Bit (=60 Byte) lang sein. Das ist mitunter der Grund warum z.b. die Option Record Route auf maximal 4 Hops beschränkt - und damit praktisch nutzlos ist. Das Differentiated Services Field: Total Length kennzeichnet die Länge des gesamten IP Pakets, also Header plus Daten. Mit seinen sechzehn Bit kann das Total Length Feld eine maximale IP Paketlänge von 2 16-1 (=65.535) Bytes darstellen; das ist somit die maximale IP Paketgröße. Identification, ermöglicht die Zuordnung von Fragmenten zu einem Paket. Die Vergabe der ID erfolgt i.d.r. durch eine höhere Schicht (z.b. TCP) und wird als Parameter an IP übergeben. Flags: 0 1 2 D M 0 F F Bit 0: reserved, must be zero Bit 1: (DF) 0 = Paket darf fragmentiert werden, 1 = Paket darf nicht fragmentiert werden. Bit 2: (MF) 0 = dieses Fragment bildet das Ende einer Fragmentreihe, 1 = dieses Fragment hat einen Nachfolger. Fragment Offset, gibt die Position eines Fragments in Relation zum Anfang des ursprünglichen (unfragmentierten) Pakets an. Mit Hilfe des Fragment Offset kann der Empfänger alle zu einem Paket gehörenden Fragmente (identifizierbar durch den Seite 7

gemeinsamen Wert im Identification Feld) in die richtige Reihenfolge setzen um daraus das ursprüngliche Paket zurück zu gewinnen. Da das Fragment Offset 13 Bit lang ist und jede Einheit 8 Byte darstellt, können IP Pakete jeglicher Größe fragmentiert werden: 2 13 * 8 Byte = 8192 * 8 = 65536 = max. Total Length Time to Live (TTL), Werte: min=0, max=255 (Einheit: 'Sekunden') Ein Zählerfeld das pro passiertem Router um mind. 1 dekrementiert wird. Empfängt ein Router ein Paket mit einer TTL=0, verwirft er es. Protocol, in unserem Fall ICMP, in IPv4 kennzeichnet dieses Feld das nach dem IP Header folgende, nächst höhere Protokoll. Die zugewiesenen Protokollnummern[ EX ] werden von der IANA verwaltet. Header Checksum, enthält eine Prüfsumme, die nur den IP Header auf Fehler überprüft. Wird ein Paket geroutet, verändert sich die TTL und die Header Checksum muß neu berechnet werden. Source Address, wird durch den Router nicht verändert und ist die Start-Adresse. Destination Address, ist die Ziel-Adresse. 4. Struktur eines UDP-Pakets Das User Datagram Protocol (Abk. UDP) ist ein minimales, verbindungsloses Netzprotokoll das zur Transportschicht der Internetprotokollfamilie gehört. Aufgabe von UDP ist es, Daten, die über das Internet übertragen werden, der richtigen Anwendung zukommen zu lassen. Die Entwicklung von UDP begann 1977, als man für die Übertragung von Sprache ein einfacheres Protokoll benötigte als das bisherige verbindungsorientierte TCP. Es wurde ein Protokoll benötigt, das nur für die Adressierung zuständig war, ohne die Datenübertragung zu sichern, da dies zu Verzögerungen bei der Sprachübertragung führen würde. In diesem Versuch verwendeten wir den Webbrowser Mozilla und die URL www.google.de um zu unseren Ergebnissen zu gelangen. Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, können die Hosts schneller mit dem Datenaustausch beginnen. Dies fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen. Einfache Frage-Antwort-Protokolle wie das Domain Name System verwenden UDP um die Netzwerkbelastung gering zu halten und damit den Datendurchsatz zu erhöhen. Ein Drei-Wege-Handshake wie bei TCP für den Aufbau der Verbindung würde unnötigen Overhead erzeugen. 1. Auflösung der Adresse www.google.de durch das DNS Protokol. (UDP) 2. Antwort vom Server von www.google.de wiederum über das DNS Protokol (UDP) 3. TCP 4. TCP Seite 8

5. Verbinden mit der Website von www.google.de (http) 6. TCP 7. Aufbau der Internetseite. (http) 8. TCP Auf diesem Bild sieht man einmal unseren verwendeten Port (1038) und den des Ziels (53). Anhand des Werts [correct] der Checksum sieht man, dass die Übertragung erfolgreich war. 5. POP3-Verbindungen Bei POP3 (Post Office Protocol Version 3) handelt es sich um ein sehr bekanntes Übertragungsprotokoll, welches E-Mails von einem E-Mail-Server abholen kann. Standardmäßig läuft das Protokoll über Port 110 und die Steuerung der Datenübertragung erfolgt durch ASCII-Kommandos. POP3 ist ein sehr einfaches Protokoll und erlaubt nur Abholen und Löschen von E- Mails. Weitere Funktionalitäten darüber hinaus beherrscht dagegen erst IMAP. Hier eine Übersicht der wichtigsten Kommandos: Befehl USER username PASS password STAT RETR n DELE n LAST LIST [n] RSET TOP n 1 QUIT Funktion Der Account- oder Username des Benutzers Das Passwort des Benutzers Gibt die Anzahl ungelesener Nachrichten und ihre Größe in Byte aus Empfängt Nachricht n Löscht Nachricht n Gibt die Nummer der zuletzt im Zugriff befindlichen Nachricht aus Gibt die Größe von Nachricht n bzw. allen Nachrichten aus Hebt die Löschung aller Nachrichten auf (undelete) und setzt den Nachrichtenzeiger auf 1 Gibt die Header und die 1. Zeile von Nachricht n aus Beenden der POP3-Session Für die Untersuchung der POP3-Verbindung nutzten wir einen alten nicht mehr benutzten Email-Account und das Programm Microsoft Outlook. a. ARP-Anfrage Die ARP-Anfrage dient dazu die IP-Adresse in eine MAC-Adresse aufzulösen und den Empfänger zu finden. Die ARP-Anfrage kann auch fehlen, da die IP-Adresse sich im ARP-Cache befinden kann. Möchte man trotzdem eine provozieren kann man den ARP- Cache löschen und dann wird eine neue ARP-Anfrage gesendet. ARP wird als Broadcast gesendet: Seite 9

b. DNS-Request und Antwort des Name Servers (Da wir trotz mehrerer Versuche leider keine DNS-Anfrage bei unserem Mailserver erhielten, probierten wir einen anderen aus). Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Hauptaufgabe ist die Auflösung von Namen, d. h. auf Namensanfragen mit der zugehörigen IP-Adresse zu antworten. Hauptsächlich wird DNS zur Umsetzung von Domainnamen in IP-Adressen (forward lookup) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenkolonnen. Ein weiterer Vorteil ist, dass IP-Adressen etwa von Web-Servern relativ risikolos geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine rudimentäre Lastverteilung (Load Balancing) realisiert werden. Die Anfrage an den DNS-Server (Request): Die Antwort des DNS-Server (Reply/Response): Seite 10

Eine DNS-Anfrage (oder: DNS-Request) kann nach drei verschiedenen Verfahren beantwortet werden: autoritativ (der Server holt die Daten aus einer lokalen Zonendatei) nicht-autoritativ o rekursiv (der Server holt die Daten von einem anderen Nameserver) o iterativ (der Server antwortet mit einem Verweis auf andere Nameserver) Die rekursive Antwort Das Rekursionsverhalten wird durch weitere Flags bestimmt. Ein Resolver setzt im DNS- Request-Header das Recursion Desired Flag kurz RD genannt, wenn er eine rekursive Auflösung seines Requests wünscht. Der Nameserver setzt in seiner Antwort das Recursion Available Flag - RA -, wenn er grundsätzlich zur Rekursion bereit ist. Nur wenn sowohl bei einem Request, als auch bei der Response diese Flags gesetzt sind, wird bzw. wurde rekursiv gearbeitet. Ansonsten unterscheiden sich autoritative und rekursive Antwort nicht. Die iterative Antwort Eine iterative Antwort enthält anstelle der Daten (z. B. IP-Adresse) einen oder mehrere Verweise auf andere Nameserver. Ein derartiger Verweis enthält den Namen des anderen Servers, den Namen der Domäne und - falls bekannt - IP-Adresse(n). c. Three-Way Handshake Es ist die Bezeichnung für ein bestimmtes Verfahren, um eine in Bezug auf Übertragungsverluste sichere Datenübertragung zwischen zwei Instanzen zu ermöglichen. Obwohl überwiegend in der Netzwerktechnik verwendet, ist der Drei-Wege- Handshake nicht auf diese beschränkt. (Da wir im Hochschul-WLAN-Netz arbeiteten, konnten wir leider die Antwort des Servers nicht mit aufzeichnen) Zum Vorgang an sich: Seite 11

Der Rechner, der die Verbindung aufbauen will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Die Sequenznummern sind dabei für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist. Die Start- Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt. Die Gegenstelle empfängt das Paket und sendet in einem eigenen SYN-Paket im Gegenzug ihre Start-Sequenznummer y. Zugleich bestätigt sie den Erhalt des ersten SYN-Pakets, indem sie die Sequenznummer um den Wert Eins erhöht und x+1 im ACK- Teil des Headers zurückschickt. Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung ist damit aufgebaut. Beispiel: 1. SYN-SENT <SEQ=100><CTL=SYN> SYN- RECEIVED Seite 12

2. ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> SYN- RECEIVED 3. ESTABLISHED <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED d. Übertragung des POP3-Passworts Zuerst wird die User-ID übertragen und nachdem dies geschehen ist bekommt der Client eine Aufforderung das zu dazugehörige Passwort zu senden: Als Antwort wird dann direkt das Passwort gesendet: Anzumerken ist, dass dieses standardmäßig in Klartext übertragen wird. So lässt es sich sehr leicht abfangen: In diesem Fall lautet das Passwort: sonnenwende. Mit Hilfe von User-ID und Passwort ist es so ein leichtes Zugriff auf das Mail-Konto zu erhalten. e. Transport der Dateninhalte Der Client sendet zuerst einen entsprechenden Befehl zum Abruf der Dateninhalte (RETR 1): Danach liefert der Server die Antwort, in Form der Daten in Klartext: Seite 13

Es ist also leicht die übertragenen Mail-Inhalte in Erfahrung zu bringen. Man erkennt z.b. auf diesem Bild den genauen Absender, die Uhrzeit wann die Mail verschickt wurde und über welchen Server dies geschah. Weiter unten folgt dann der eigentliche Text der E-Mail. Damit zeigt sich, dass POP3 im Standard-Betrieb ein sehr unsicheres Protokoll ist, welches leicht abgefangen werden kann. Es besteht aber die Möglichkeit einer Verschlüsselung mit SSL/TLS. f. Abbau der Verbindung Zuerst wird von Seite des Clients ein QUIT gesendet, welches den Abbau der POP3- Verbindung einleitet: Die Antwort des Servers wird dabei nicht mitgeschnitten. Was vor allem an unserer Konfiguration (Laptop im Hochschul-WLAN-Netz) liegt. Stattdessen sieht man als nächstes direkt das [ACK]-Paket des Clients: Nachfolgend dann ein [FIN, ACK] Paket: Seite 14

Prinzipiell gibt es wieder einen Drei-Wege-Handshake, welcher folgendermaßen abläuft: Zuerst kommt von Seite A ein [FIN]-Paket, als Antwort von Seite B ein [ACK]. Danach ein eigenes [FIN]-Paket von Seite B, welches von der Gegenseite mit einem [ACK] bestätigt wird. Dies sind eigentlich Vier Wege, aber die [ACK] und [FIN]-Pakete, welche von Seite B ausgehen, werden als ein Weg gezählt. Zudem ist auch ein verkürztes Verfahren möglich, bei dem [FIN] und [ACK] genau wie beim Verbindungsaufbau im selben Paket untergebracht werden. Fehlende Schritte in der Aufzählung: Hierbei handelt sich um Schritte, welche zwischen An- und Abbau einer POP3- Verbindung wichtig sind, aber in der Aufgabenstellung nicht weiter genannt werden. Insbesondere wäre dies die Übertragung der User-ID, welche insbesondere für eine Authentifizierung des Benutzers benötigt wird: Dies geschieht direkt vor der Anfrage nach dem dazugehörigen Passwort. Aber auch die Auflistung vorhandener Nachrichten und deren Größe ist von Bedeutung für einen Reibungslosen Ablauf. (Befehl STAT und LIST) Denn darauf aufbauend fordert das Mail-Programm die Mails der Reihe nach mit RETR an. 6. FTP-Verbindungen (Mitschneiden von Passwörtern mit Dsniff) Im Folgenden haben wir uns mit dem Thema des Passwort-Sniffings beschäftigt. Dazu sollten wir uns auf den FTP-Server des KTDS-Labors mit unserem Benutzer und Passwort einloggen und dieses mit dem Programm dsniff abfangen. Da dies wegen verschiedener Restriktionen des KTDS-Netzwerkes nicht funktioniert hat, haben in einem eigenen Netzwerk eine FTP-Verbindung aufgebaut und mit dsniff den Benutzer und Passwort abgefangen und in einer Datei gespeichert. Um eine Näherung zur Aufgabenstellung zu erreichen, haben wir die VMWare mit dem entsprechenden Debian- Image verwendet. Seite 15

Betrachtung des Programms dsniff: Da dsniff ein Passwort-Sniffer ist, bietet es sich an, dieses Programm unter den Gesichtspunkten der Vertraulichkeit genauer zu betrachten. Dsniff ist eine Kollektion von Netzwerk-Tools zur Überwachung und zum Eindringen in Netzwerke, welche aus folgenden Programmen besteht, deren Verwendung kurz Vorgestellt wird, wobei die Methode des ARP-Spoofings und DNS-Spoofings genauer betrachtet wird: ARP-Spoofing: ARP-Spoofing ist eine Technik, die den ARP-Cach ändert. Dies geschieht folgendermaßen: Der ARP-Cache enthält Informationen über das Hardware-IP-Mapping. Man behält seine Hardware-Adresse bei, gibt aber vor, dass die IP-Addresse die eines vertrauenswürdigen Hosts sei. Dies wird gleichzeitig an das Ziel und den Cache gesendet. Nun werden die Pakete vom Ziel zur eigenen Hardware-Adresse geleitet. Mit anderen Worten: Das Ziel glaube nun, man sei der vertrauenswürdige Host. Dabei kann dieser Trick schief gehen, wenn zum Beispiel intelligente Hubs oder Router passiert werden müssen. Daher funktioniert ARP-Spoofing nur unter bestimmten Bedingungen zulässig und kann selbst dann auf lokale Netzwerksegmente beschränkt sein. Um die dennoch die Vertraulichkeit in einem Netzwerk zu wahren, gibt es Möglichkeiten ein ARP-Spoofing zu verhindern. Eine ist zum Beispiel die Adress- Mapping in Stein zu meißeln, was wiederum andere Nachteile hat, die Paul Buis in Names and Adresses so erläutert: Viele Betriebsysteme haben jedoch Vorkehrungen dafür, die Einträge in dem ARP-Cache statisch zu machen, so dass sie nicht alle paar Minuten ablaufen. Ich empfehle Ihnen diese Eigenschaft zur Abwehr von ARP- Spoofing zu benutzen. Allerdings müssen sie dann den Cache jedes Mal manuell aktualisieren, wenn sich eine Hardware-Adresse ändert. Eine andere Abwehrmaßname ist die Verwendung von ARPWATCH, welches die Änderungen der IP/Ethernet-Mappings überwacht und einem bei einer Änderungen eine Email schickt, so dass dies protokolliert werden kann und der Angreifer schnell erkannt wird. DNS-Spoofing: Beim DNS-Spoofing legt man den DNS-Server offen und ändert direkt die Tabellen zur Zuordnung von Hostnamen und IP-Adressen. Danach werden diese Änderungen in die Übersetzungstabellen-Datenbank auf dem DNS-Server geschrieben, so dass eine Auflösung eines Hostnamens eine gefälschte Adresse ergibt. Zwar ist die Wahrscheinlichkeit für einen solchen Angriff relativ gering, allerdings kann dies zu einer großen Gefährdung der Sicherheit führen. Daher gibt es ein paar Methoden um dennoch die Vertraulichkeit zu wahren. Wenn Sie einen der DNS-Server unter Verdacht haben sollte sie die anderen maßgeblichen DNS server des Netzwerks pollen. Wenn der ursprünglich betroffene Server nicht bereits seit einiger Zeit offen gelegt ist, wird es sofort Anzeichen dafür geben, dass er Opfer einer spoofing Attacke geworden ist. Andere maßgebliche Server werden Antwort geben, die von denen des geknackten DNS Servers abweichen. Da das pollen vielleicht nicht ausreicht (da zb der ursprünglich betroffene Server bereits seit längerem offen liegt und die gefälschten Tabellen bereits an andere DNS- Server des Netzwerks weitergeleitet worden sind), gibt es zum Beispiel ein Script- Utility namens DOC (domain obscenity control), welches das Fehlverhalten von Seite 16

Domains diagnostiziert, indem es Anfragen an die entsprechende Domain-Name- Server aussendet und die daraufhin erfolgten Ausgaben einer Reihe von Analysen unterzieht. dsniff ein Passwort-Sniffer für verschiedene Protokolle filesnarf speichert ausgewählte Dateien, aus dem NFS-Traffic macof überflutet das lokale Netzwerk mit zufälligen MAC-Adressen mailsnarf fängt Mails im lokalen Netzwerk ab und speichert sie msgsnarf zeichnet ausgewählte Nachrichten von Instant-Messengers sshmitm SSH Monkey-in-the-Middle. Snifft und Leitet SSH Traffic um. sshow SSH-Traffic Analysator tcpkill beendet spezielle (active) TCP-Verbindungen tcpnice verlangsamt ausgewählte (aktive) TXP-Verbindungen urlsnarf gibt ausgewählte URLs aus dem gesnifften http-traffic aus webmitm http/https monkey-in-the-middle. Transparenter Proxy webspy sendet abgefangene URLs vom Client zum lokalen Browser Entdecken eines Sniffers im Netzwerk Um die Vertraulichkeit in einem Netzwerk zu gewährleisten, ist es natürlich wichtig einen eventuell vorhandenen Sniffer im Netzwerk zu erkennen. Schicht-2: das oben beschriebene Programm arpwatch kann Änderungen im ARP- Mapping im lokalen Netzwerk finden, welche durch arpspoof oder macof verursacht werden. Schicht-3: ein programmierbarer Sniffer wie zum Beispiel NFR kann zum einen Anomalien im Netzwerk oder zum anderen einige Effekte eines aktiven dsniff-angriff aufdecken, wie zum Beispiel: o ICMP-Port ist unerreichbar für den lokalen DNS-Server, als Ergebnis des dnsspoofings, welches den Wettlauf beim Antworten auf die Anfrage einer DNS-Client-Tabelle mit gefälschten Daten gewinnt. o Exzessive oder out-of-window TCP RSTs oder ACK Überflutungen, welche durch tcpkill oder tcpnice hervorgerufen werden. Dsniff s passive Programme können mit dem Programm antisniff erkannt werden, wenn dieses regulär zur baseline-network-latency verwendet wird (und man mit der dadurch produzierte Informationsflut umgehen kann) Schutz des Netzwerks gegen Sniffer Da es ein Sniffer oft nicht sofort erkannt werden kann, ist es wichtig sich und seine Daten vor Sniffern zu schützen. Schicht 2: Aktivierung der Port-Security-Option eines Switches oder erzwingen von statischen ARP-Einträgen für jeweilige Host können gegen arpspoof Umleitungen helfen, wobei diese Gegenmaßname äußerst lästig sein kann. Schicht-3: IPSEC gepaart mit sicherem und authentisierten Name-Services (DNSSEC) kann die Umleitung durch dsnspoof und damit das triviale passive Sniffen verhindern. Unglücklicherweise ist IPSEC s IKE ein aufgeblähtes Schlüssel-Tausch Protokoll, welches die Pakete bzw. die Verbindung soweit aufbläht, dass die Verwendung im Internet in naher Zukunft undenkbar ist. Schicht-4: Der Verbot von unsicheren Programmen, Protokollen oder Klartext-Protokollen im Netzwerk, kann den Einsatz von Sniffern verhindern oder zumindest erschweren. Seite 17

Verschlüsselte Arbeitssitzungen stellen eine weitere Lösung dar, die eine gute Lösung des Problems darstellen. Daher gehen wir im folgenden näher darauf ein: Statt sich darüber Sorgen zu machen, dass Daten abgefangen werden, verschlüsselt man diese einfach bis hin zur Unkenntlichkeit. Die Vorteile dieser Methode liegen auf der Hand: Selbst wenn es einem Angreifer gelingen sollte die Daten innerhalb des Netzwerkes abzufangen, wird er mit diesen kaum etwas anfangen können. Die Nachteile sind leider schwerwiegend: Es gibt zwei hauptsächliche Probleme in Bezug auf Verschlüsselung; eines ist ein technisches und das andere ein menschliches Problem. Die technischen Fragen sind, ob die jeweilige Verschlüsselung stark genug ist und ob diese überhaupt unterstützt wird. Zum Beispiel ist eine 40-Bit- Verschlüsselung möglicherweise nicht ausreichend und nicht alle Programme bieten integrierte Verschlüsselungsunterstützung. Zudem sind Plattform-Übergreifende Verschlüsselungslösungen selten und in der Regel nur in spezialisierten Programmen verfügbar. Das menschliche Problem liegt darin, dass der Benutzer sich möglicherweise gegen die Verschlüsselung wehrt, da diese oft lästig ist. Zwar wird der Benutzer diesen Richtlinien im Sinne der Sicherheit zustimmen, aber selten halten diese sich auch daran. Zusammenfassung Wir haben erkannt, dass Sniffer ein bedeutendes Sicherheitsrisiko darstellen, da durch sie zum einen Zugang zu Passwörtern entsteht und so Fremde womöglich sogar durch ein Root- Passwort die Kontrolle über ein Netzwerk erlangen können. Zum anderen sind Sniffer nicht leicht zu entdecken. Das wichtigste bei diesem Punkt, wie bei allen anderen Sicherheits(Vertraulichkeits-)fragen, ist: Kenne deinen Feind Wenn man weiß, wie andere Sniffer gegen einen einsetzen, weiß man wie man sich dagegen schützen kann. (oder ist zumindest auf dem besten Wege dahin) Zum Schluss kann wohl gesagt werden, dass die besten Abwehrmaßnahmen eine sichere Netzwerktopologie und eine starke Verschlüsselung sind. Seite 18