Praktikum Informations- und Medientechnik

Transkript

1 Institut für Organisation und Management von Informationssystemen Praktikum Informations- und Medientechnik Sommersemester 2007 Gruppe 4: Adelheid Grob & Christian Renz durchgeführt am: 2. Mai 2007

2 1 Fragen zur Vorbereitung 1.1 Zwecke Paketsniffing Paket-Sniffing wird zu Analyse von Protokollen und Datenverkehr eingesetzt. 1.2 Promiscuous-Mode In diesem Modus wird der gesamte Datenverkehr auf einer bestimmten Schnittstelle mitgelesen und zur Auswertung an ein entsprechendes Gerät/Programm weitergegeben. 1.3 Unterschied zwischen Hub, Switch und Router Ein Hub leitet einkommende Pakete an jeden Port weiter, ein Switch leitet die Pakete nur an den Port weiter, für den das Paket bestimmt ist. Während diese beiden Elemente verschiedene Endgeräte miteinander verbinden, ist ein Router dazu da, verschiedene Netze (!) miteinander zu verbinden. 1.4 Sniffer am Hub und am Switch Bei einem Hub ist es ohne weiteres für einen Sniffer möglich, den gesamten Verkeher mitzusniffen - da dieser ja jeweils an alle Ports geht. Bei einem Switch ist dies u.u. nicht möglich (port mirroring). 1.5 Sniffen in geswitchtem Netz Es gibt im wesentlichen zwei Methoden Man-In-The-Middle-Attack Ein häufig verwendetes tool zum Sniffen in Netzen mit Sniff ist ettercap. Dieses unterstützt Sniffen auf IP- und ARP-Ebene, somit kriegt man auch den Verkehr mit, der im gleichen Subnetz an andere Stationen adressiert ist. Es werden an Station A gefälschte ARP-Nachrichten gesendet, so daß diese Pakete für Station B an den Man in the Middle geschickt - dieser sendet die Pakete dann an die jeweilige Station (hier B) weiter. Speicher Overflow Man kann auch mit MAC-Adressen den Speicher des Switches füllen. Sobald dieser interne Speicher nämlich voll ist, sender der Switch wieder an alle Ports alle Daten. A. Grob C. Renz 1 Sommersemester 2007

3 1.6 Unterschied Telnet - SSH Bei SSH ist im Gegensatz zu Telnet die gesamte Datenübertragung verschlüsselt. 1.7 Ethernetframe Es gibt eine ganze Menge Versionen von Ethernet Frames, am häufigsten wird heutzutage der Ethernet Frame 2.0 verwendet. Dieser besteht aus einer Preamble, die zur Synchronisation dient (8 Byte lang). Danach folgt der eigentlich Ethernet-Frame mit mindestens 64 Byte und maximal 1518 Byte. Dieser teilt sich wie folgt auf: Ziel-Adresse/Destination Address - 6 Byte Quell-Adresse/Source Address - 6 Byte Typ/Type - 2 Byte, gibt Auskunft über das verwendete Protokoll der nächsthöheren Schicht der Daten Datenbytes/Data - mindestens 64 Byte, maximal 1500 Bytes Frame Check Sequence/FCS - Prüfsumme, 4 Byte Neben diesem Standard gibt es noch verschiedene Versionen wie z.b q, 802.3, raw, snap, tagged, 2.0 tagged. Bei diesen sind zusätzliche Felder vorgesehen, wie etwa eines zur Angabe der Länge, eines für.1q (VLAN), usw. 1.8 Informationen in einem IP-Paket In einem IP-Paket sind folgende Informationen enthalten: Version (4 Bit) - gibt an, ob es sich um IPv4 oder IPv6 handelt IP Header Length/IPL (4 Bit) - Länge des IP-Headers (alle Infos von Version bis Options and Paddings) in Vielfachen von 32 Bit Type of Service/ToS (8 Bit) - für Quality of Service interessant Total Length (16 Bit) - Gesamtlänge Identification (16 Bit) - steuert zusammen mit Flags und Fragment Offset die Zusammensetzung der zuvor fragmentierten Daten Flags (3 Bit) - gibt an, ob Fragmente folgen und ob anhängende Daten zerlegt werden dürfen oder nicht A. Grob C. Renz 2 Sommersemester 2007

4 Fragment Offset (13 Bit) - gibt die Nummer des anhängenden Datenfragments im Gesamtpaket an Time To Live (8 Bit) - gibt die Zeit an, die das Paket leben darf. Sie wird bei jedem Router um 1 verringert, erreicht sie Null, wird das Paket verworfen. So wird sichergestellt, daß Pakete nicht ewig im Netz rumideln. Protocol (8 Bit) - gibt Auskunft über das Folgeprotokoll Header Checksum (16 Bit) - Prüfsumme des Headers Source Address (32 Bit) - Quelladresse Destination Address (32 Bit) - Zieladresse Options and Paddings (32 Bit) - Zusatzinformationen Nutzdaten 1.9 DNS - Domain Name Service DNS wurde eingeführt, um menschenlesbare Adressen für Rechner usw. zu haben (die man sich auch leichter merken kann): z.b. heidi.in-ulm.de. Würde es diesen Dienst nicht geben, würde man die Webseite unter heidi.in-ulm.de wie folgt aufrufen müssen: Namen für DNS-Server Es macht keinen Sinn, einem DNS-Server einen leicht einzuprägenden Namen zu geben, da dieser ja nicht direkt angesprochen ist, sondern dafür zuständig ist, die entsprechenden Namen in seinem Gebiet (Zone) aufzulösen, außerdem würde ein solcher Name ja wiederum an einer anderen Stelle aufgelöst werden müssen. Allerdings ist es üblich, dem DNS-Server eine leicht zu merkende IP-Adresse zu geben, da diese immer wieder benötigt wird (z.b. in /etc/resolv.conf). So hat der Nameserver der Universität Ulm z.b. die IP primäre und sekundäre Nameserver Der primäre Nameserver erhält die DNS-Einträge für die Zonen, für die er autorisiert ist aus einer Datei auf seiner Festplatte. Autorisiert bedeutet, dass der primäre Nameserver die DNS- Information nicht mit einem weiteren Nameserver der Zone gegenprüfen muss. Es existiert nur ein primärer Nameserver für jede Zone. A. Grob C. Renz 3 Sommersemester 2007

5 Der sekundäre Nameserver besitzt eine schreibgeschützte Kopie der DNS-Datenbank des primären Nameservers, die nach einem bestimmten Standard aktualisiert wird. Der Kopiervorgang wird Zonentransfer genannt und bildet die Grundlage für die Aktualisierung der verteilten DNS-Datenbank einer Domäne. Sekundäre Nameserver übernehmen Aufgaben der Lastenverteilung und schaffen die Redundanz der DNS-Domäneninformation. Außerdem verteilt sich die Anzahl der Zugriffe somit auf zwei Server. Die Nachteile eines solchen Systems ist der erhöhte Pflegeaufwand, da man zwei Rechner benötigt. Zum anderen kann es nachteilig sein, wenn die Kopie auf dem sekundären Nameserver veraltet ist Caching-Nameserver Bei Caching-Nameservern kann das Problem auftauchen, daß Änderungen nicht sofort bemerkt werden Nachteile von dynamischen IP-Adressen Möchte man von außen auf einen Rechner o.ä. zugreifen, hat es durchaus große Vorteile, wenn dieser eine feste IP hat. Bei manchen großen Anbietern gibt es durch die Verwendung von dynamischen IP-Adressen zudem Zwangstrennungen, was dazu führt, daß eine Station kurz offline ist. Dies ist insbesondere bei laufenden Programmen über Netzwerk ein Problem. Ein weiterer Nachteil ist, daß Spammer, die wechselnde IP-Adressen verwenden, nur mit Hilfe des jeweiligen Anbieters zu ermitteln sind. Außerdem kann es passieren, dass der Vorbesitzer der jeweiligen IP auf Blacklists steht oder man erhält Zugriffe auf Ports von Diensten, die der vorherige Benutzer der IP verwendet hat. Man kann diese Nachteile umgehen, indem man entweder einen Anbieter wählt, der feste IP-Adressen. Abhilfe schafft auch die Verwendung eines IPIP-Tunnels oder von DynDNS. A. Grob C. Renz 4 Sommersemester 2007

6 2 Versuchsdurchführung 2.1 Versuchsteil 1: Ping im Detail Zunächst betrachten wir einen ping mit Hilfe von Wireshark Abb. 1: Screenshot Eatherreal PING Man kann an dem obigen Screenshot 1 die einzelnen Anfragen von meinem Rechner und die Antworten von Rechner sehen. A. Grob C. Renz 5 Sommersemester 2007

7 Nun haben wir den Inhalt eines ARP-Paketes (siehe 2) analysiert. Wir haben Requests, die von dem Rechner an den Rechner gesendet werden, protokolliert. Abb. 2: Screenshot Eatherreal ARP: Request A. Grob C. Renz 6 Sommersemester 2007

8 Die Antwort (reply) geht den umgekehrten Weg: es werden ARP-Reply-Pakete vom Rechner an gesendet. In der Antwort ist nun die gefragte MAC-Adresse des zweiten Rechners enthalten. Die ersten 6 Bit einer MAC-Adresse sind für die Angabe des Herstellers reserviert, deswegen kann Wireshark den Hersteller des Interfaces angeben (hier z.b. TyanComp) Abb. 3: Screenshot Eatherreal ARP: Reply A. Grob C. Renz 7 Sommersemester 2007

9 2.2 Versuchsteil 2: Erste Schritte mit Wireshark Webseite Als erstes rufen wir eine Webseite auf und schneiden den Datenverkehr mit. Das Ergebnis kann in Abb. 4 betrachtet werden. Abb. 4: Screenshot Eatherreal HTTP/TCP Wir haben diesen Mitschnitt mithilfe der Funktion Follow TCP String analysiert. Dabei sehen wir, daß die Übertragung per GET-Anfordnung gestartet wird und mittels TCP stattfindet. Außerdem kann man erkennen, daß www auf Port 80 läuft, wie lange die gesendete Sequenz ist (die wir ausgesucht haben) und daß das Paket korrekt übermittelt wurde (Checksum: correct). A. Grob C. Renz 8 Sommersemester 2007

10 Telnet-Session Als nächstes haben wir versucht, aus einer Telnet-Session das Passwort mitzuschneiden. Dies war problemlos möglich (siehe Abb. 7). Im untenstehenden Screenshot 5 kann man erkennen, daß man sich auch die weiteren gesendeten Daten im Plaintext anschauen kann. Abb. 5: Screenshot Eatherreal Telnet SSH-Session Im Vergleich zur Telnet-Sitzung kann man hier nun keine Daten im Plaintext mehr auslesen sondern erhält nur die verschlüsselten Datensequenzen (siehe Abb. 6) 2.3 Versuchsteil 3: Internet Protocol (IP) Die nächste Aufgabe bestand darin, sich den Header eines IP-Paketes anzuschauen (siehe Abb. 7) A. Grob C. Renz 9 Sommersemester 2007

11 Abb. 6: Screenshot Eatherreal SSH Man erkennt die verschiedenen Teile des Headers, wie in 1.8 geschildert. Es handelt sich bei unserem IP-Paket um IPv4, die Länge des Headers beträgt 20 Byte, die gesamte Länge des Pakets ist 213 Byte, es darf nicht fragmentiert werden, die verbliebene Time-To-Live beträgt 64. Außerdem wurde das Paket korrekt übertragen (checksum correct), es kam von der Adresse und war an addressiert. Welche Daten übertragen wurden, erkennt man an der genauen Analyse des TCP-Mitschnitts. Hier erkennt man, daß es sich um eine telnetsession auf Port 23 handelt. Der Inhalt der gesendeten Daten ist ganz unten im Bild zu erkennen - sowohl in hexadezimaler Schreibweise als auch in decodierter Weise. Man sieht hier im Übrigen auch den login und das passwort der Telnet-Sitzung im Klartext (praktikum/praktikum). Weiterhin haben wir mit Hilfe des Programms traceroute versucht, den Weg zu einem Ziel aufzuspüren. Leider haben wir hiervon keine Screenshots gemacht. Beim Nachverfolgen des Wegs zu ist uns aufgefallen, daß manche Rechner nicht erreichbar sind. Der Weg konnte aber dennoch weiterverfolgt werden, da das Paket in diesem Fall zurückgegeben wird und eine andere Route versucht wird. A. Grob C. Renz 10 Sommersemester 2007

12 Abb. 7: Screenshot Eatherreal IP Paket traceroute verwendet das TTL-Feld des IP-Headers, um den Weg zu einem Ziel herauszufinden, indem es Pakete mit jeweils um 1 erhöhter TTL zu einem Ziel sendet. Man erkennt in Wireshark, daß viele Pakete zurückkommen, deren TTL abgelaufen ist. Somit weiss traceroute, wieviele (und welche) Stationen durchlaufen worden sind. 2.4 Versuchsteil 4: Transmission Control Protocol (TCP) und User Datagramm Protocol (UDP) Im vierten Versuchsteil haben wir eine Webseite aufgerufen und uns den TCP-Verkehr mit Wireshark genauer angeschaut (siehe Abb. 8). Man erkennt an dem mitgeschnittenen Ausschnitt sehr gut den Ablauf der TCP-Verbindung. Zunächst werden Synchronisationsdaten ausgetauscht (SYN, ganz oben im Bild). Danach werden Pakete geschickt und per ACK (acknowledged) bestätigt. Am Ende der Übertragung (ganz unten im Bild) wird ein FIN-Segment gesendet. Unsere Übertragung war fehlerfrei, da wir keine NACKs in der Verbindung hatten. A. Grob C. Renz 11 Sommersemester 2007

13 Abb. 8: Screenshot Eatherreal TCP Im Vergleich zu UDP fällt auf, daß UDP keine Bestätigungs- oder Fehlernachrichten versendet. Ebenfalls fehlt die Synchronisationsinformatione. UDP ist also wesentlich schneller als TCP, was für manche Anwendungen sehr gut ist (z.b. VoIP). TCP dagegen ist verlässlicher, da fehlerhafte Pakete gemeldet und erneut geschickt werden. 2.5 Versuchsteil 5: Domain Name Service (DNS) Die letzte Aufgabe des zweiten Vorversuchs bestand darin, die Adresse imap.uni-ulm.de zu pingen und dabei herauszufinden, wie DNS genau funktioniert (siehe Abb. 9: DNS sendet einen Anfrage (Standard Query) und erhält vom Nameserver der Uni ( ) die entsprechende Antwort. Der Hostname des IMAP-Servers der Uni lautet mail.uni-ulm.de, dieser hat die IP-Adresse Mehrere Einträge für einen Rechner lassen sich über Pointer realisieren (PTR). Der Eintrag im Feld Time To Live ist 1 Tag, 19 Stunden, 39 Minuten und 16 Sekunden. Nach dieser Zeit wird das Paket verworfen. A. Grob C. Renz 12 Sommersemester 2007

14 Abb. 9: Screenshot Eatherreal DNS Zusätzlich zu den ICMP-Nachrichten, die wir durch PING erhalten, gibt es noch ICMP- Nachrichten die dazu dienen, anderer Fehler- oder Kontrollmeldungen zu versenden. Diese werden in Wireshark ebenfalls protokolliert. A. Grob C. Renz 13 Sommersemester 2007