Verschaffen Sie sich einen Überblick über die
Werbung
Netzwerkanalyse mit Ethereal Von: Bendikt Arnold (11041025) [email protected] Christian Fehmer (11042419) [email protected] Ioannis Chouklis (11042438) [email protected] Dimitrios Ramnalis (11039518) Fachhochschule Köln Kommunikationstechnik 2 Prof. Dr. Stahl Netzwerkanalyse mit Ethereal 2 Kommunikationstechnik 2 Inhaltsverzeichnis .............................................................................................................................................................. 2 1 Vorbereitung...................................................................................................................................... 3 1.1 Was ist Ethereal? (www.ethereal.com)......................................................................................3 1.2 Wozu wird es verwendet?..........................................................................................................3 1.3 Welche Möglichkeiten bietet es?............................................................................................... 3 1.4 Wo finden wir Hilfen?............................................................................................................... 4 1.5 Welche Dateiformate werden unterstützt?.................................................................................4 1.6 Welche Konfigurationsparameter gibt es? ................................................................................5 2 Projektaufgabe................................................................................................................................... 5 2.1 Konzept......................................................................................................................................5 2.1.1 Analyse von verschiedenen Paketen.................................................................................. 5 2.1.2 Analyse einer POP3 Verbindung....................................................................................... 6 2.2 Lösung........................................................................................................................................7 2.2.1 Analyse von verschiedenen Paketen....................................................................................... 7 2.2.2 Analyse einer POP3 Verbindung.......................................................................................... 15 3 Querschnittsaufgaben...................................................................................................................... 25 3.1 Konzept....................................................................................................................................25 3.2 Lösung......................................................................................................................................25 3.2.1 Einrichtung eines Mailclient............................................................................................ 25 3.2.2 Einrichtung eines Webbrowser........................................................................................ 25 3.2.3 Konfiguration der Netzwerkschnittstelle über dhcp.........................................................25 Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 3 1 Vorbereitung 1 Vorbereitung 1.1 Was ist Ethereal? (www.ethereal.com) Ethereal ist ein kostenloser, Open Source Netzwerkprotokoll-Analysator mit Benutzeroberfläche (GUI) für Linux,UNIX und Windows. Es sammelt Netzwerkpakete und bietet die Möglichkeit, diese so detailliert wie gewünscht darzustellen. 1.2 Wozu wird es verwendet? Ethereal wird verwendet: • zur Problembehebung im Netzwerk • zum Überprüfen von Sicherheitsproblemen • zur Prüfung von Protokollimplementierungen • zur Software- und Protokollentwicklung • zum Erlernen der Arbeitsweise der Protokolle 1.3 Welche Möglichkeiten bietet es? Ethereal ermöglicht ein einfaches Durchsuchen von mitprotokollierten Daten die entweder in Echtzeit abgefangen werden oder von zuvor erzeugten tcpdump-Dateien stammen. Gekoppelt mit der Laufzeitfilterung für eine gezielte Suche sowie einer SNMPUnterstützung und der Möglichkeit, Daten über Standard-Ethernet, FDDI, PPP und Token Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 4 1 Vorbereitung Ring abzufangen, ist es eine gute Wahl. Des Weiteren können Details zu jedem einzelnen Paket angezeigt werden. Zusätzlich verfügt Ethereal über leistungsfähige Analyse- und Summary-Funktionen, sowie eine eigene Sprache zum Filtern von Netzwerkpaketen. 1.4 Wo finden wir Hilfen? Hilfe kann man im Internet unter der URL: http://www.ethereal.com/ oder in der Manpage von Ethereal (man 1 ethereal) unter einem UNIX System finden. Bild 2 – Ethereal’s website 1.5 Welche Dateiformate werden unterstützt? Ethereal kann die Capture-Files in folgendem Format speichern: • Ethereal und alle Formate die die libpcap Bibliothek verwenden (wie z.B. tcpdump) • Sun Snoop • Novell LANalyzer • Microsoft Network Monitor 1.x, 2.x • Network Associates Sniffer • Visual Networks traffic capture • Accellent 5Views capture • Network Instruments Observer version 9 Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 5 1 Vorbereitung Ebenfalls kann es Capture-Files in folgendem Format Importieren: • Libcap, tcpdump und andere Programme die die libpcap Bibliothek verwenden • Snoop und atmsnoop • AIX iptrace • pppd Logs • IPLog Format aus der Cisco Secure Intrusion Detection System • AG Group/WildPackets EtherPeek etc. • mehr kann man unter der manpage von ethereal finden 1.6 Welche Konfigurationsparameter gibt es? Es gibt viele Konfigurationsparameter zur Analyse des Netzwerkverkehrs einige (die wichtigsten) davon sind. • -k: Startet sofort das Sammelverfahren. • -i: Setzt den Name der Netzwerk Interface für die Sammelverfahren • -f: Setzt den Capture Filter Expression. • -b: Setzt die maximale Größe der Capture-File • -r: Liest Paketdaten aus einer Datei Da eine Grafische Oberfläche verfügbar ist, kann man diese und auch mehr Konfigurationsparameter mittels Menü anwenden, um das Programm zu konfigurieren. 2 Projektaufgabe 2.1 Konzept Das Labornetz ist durch einen Hub verbunden. So ist es im Promiscous-Modes möglich alle Pakete, auch die, die nicht an die eigene MAC adressiert sind mitzulesen. 2.1.1 Analyse von verschiedenen Paketen Wir erzeugen die jeweils zu untersuchenden Pakete auf einem zweiten Rechner mit den Programmen, die das jeweilige Paket erzeugen können: - Ethernet und ICMP Pakete erzeugen wir mit Ping. - IP Paket erzeugen wir, indem wir eine Anfrage an einen Webserver richten. - Ein UDP Paket lässt sich mit einer Nameserveranfrage erzeugen. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 6 2 Projektaufgabe Die Auswertung erfolgt jeweils durch Ethereal mit einem passend eingestellten Displayfilter. Ein Displayfilter filtert die Ausgabe des aufgezeichneten Netzwerkverkehrs (z.B nach Protokollen, IP-Adressen, MAC usw.). 2.1.2 Analyse einer POP3 Verbindung Wir stellen den Displayfilter so ein, dass nur Pakete mit Sender- oder Empfängeradresse angezeigt werden. Alle Pakete der zu analysierenden Schritte lassen sich durch das Abfragen von E-Mails mit einem passenden Client von einem POP3 Server erzeugen. Die ARP Anfrage kann fehlen, wenn sich die MAC Adresse des Servers im ARP Cache befindet. Erzwingen kann man eine erneute Anfrage durch Löschen des ARP Caches. Alle weiteren Schritte werden dokumentiert, indem wir die aufgezeichneten Pakete mit Ethereal analysieren. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 7 2 Projektaufgabe 2.2 Lösung 2.2.1 Analyse von verschiedenen Paketen 1. Analysieren Sie die Struktur eines Ethernet-Frames und setzen Sie die Header-Inhalte Bezug zu den verwendeten Rechnern. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address (contd.) | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP header, then TCP header, etc | | | ... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Abb. 1 – Ethernet-Frame Die Präambel Die Präambel ist ein 8 Byte langes Feld, das der Synchronisation der Netzwerkgeräte dient. Sie besteht aus einer alternierenden Bitfolge (abwechselnd Einsen und Nullen). So können sich die beteiligten Geräte im Netzwerk auf eine eingehende Datenübertragung vorbereiten und sich auf den Takt des Signals synchronisieren. Ziel- und Quell- MAC Adresse Die Zieladresse identifiziert den Zielrechner, der die Daten empfangen soll. Diese Adresse kann auch eine Multicast / Broadcast Adresse sein. Die Quelladresse identifiziert den Sender. Die MACAdresse hat eine Länge von sechs Byte. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 8 2 Projektaufgabe Das Type Feld Gibt Auskunft über das verwendete next-level Protokoll innerhalb der Nutzdaten. Die Nutzdaten Die Nutzdaten können pro Frame zwischen 0 und 1500 Byte lang sein. Sie sind die eigentlichen Informationen, die übertragen werden sollen. Ist das Nutzdaten Feld kleiner als 46 Byte, muss ein PAD Feld angehängt werden, um die Korrektheit des Ethernet II Frames sicherzustellen. Das PAD Feld Wird verwendet, wenn die Nutzdaten < 46 Byte sind, um den Ethernet II Rahmen auf die korrekte Minimalgröße von eben 64 Byte zu bringen. Dieser erstreckt sich von den beiden MAC-Adressen bis zur FCS. FCS (Frame Check Sequence) Das FCS Feld stellt eine 32Bit CRC-Prüfsumme dar. Wenn ein Paket beim Sender erstellt wird, wird eine CRC-Berechnung über die gesamte Bitfolge durchgeführt und die Prüfsumme an das Frame angehängt. Der Empfänger führt nach dem Empfang die selbe Berechnung aus und vergleicht sein Ergebnis mit dem Inhalt des FCS-Feldes. Stimmen die Werte nicht überein, geht der Empfänger von einer fehlerhaften Übertragung aus und das Frame wird verworfen. Als Beispiel betrachten wir folgendes Ethernet-Frame: Frame 5 (98 on wire, 98 captured) Arrival Time: May 27, 2005 19:33:05.617053000 Time delta from previous packet: 0.487764000 seconds Time relative to first packet: 5.478264000 seconds Frame Number: 5 Packet Length: 98 bytes Capture Length: 98 bytes Abb. 2 – Gefangenes Ethernet-Frame In Abbildung 2 ist leicht zu erkennen die Ankunftszeit des Frames, die Zeit vom vorhergehenden Paket, die Zeit im Verhältnis zu erstem Paket, die Frame-Nummer und die Paketlänge. Ethernet II Destination: 00:03:c9:3d:2a:d2 (TECOM_3d:2a:d2) Source: 00:0c:29:05:71:50 (00:0c:29:05:71:50) Type: IP (0x0800) Abb. 3 – Gefangenes Ethernet-Frame Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 9 2 Projektaufgabe In Abbildung 3 sind die Quell- Ziel-MAC-Adressen und den Typ des Protokolls. Internet Protocol, Src Addr: 192.168.0.13 (192.168.0.13), Dst Addr: 192.168.0.12 (192.168.0.12) 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: 84 Identification: 0x0000 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0xb93f (correct) Source: 192.168.0.13 (192.168.0.13) Destination: 192.168.0.12 (192.168.0.12) Internet Control Message Protocol Type: 8 (Echo (ping) reqest) Code: 0 Checksum: 0xff39 (correct) Identifier: 0x0705 Sequence number: 00:00 Data (56 bytes) Abb. 4 – Gefangenes Ethernet-Frame In Abbildung 4 die Inhalte des IP-Pakets, des ICMP-Pakets und die Nutzdaten. Man sieht, dass dieser Frame drei Header, eine Ethernet-, eine IP- und eine ICMP-Header hat. Die Informationen, die wir von dieser Frame erhalten, ist dass vom Rechner mit MAC-Adresse 00:0c:29:05:71:50 und IP-Adresse 192.168.0.13 ein echo-request zum Rechner mit MAC-Adresse 00:03:c9:3d:2a:d2 und IP-Adresse 192.168.0.12 zugeschickt ist. Das Frame ist nicht fragmentiert (.1.. = Don't fragment: Set) und ist auch das letzte Fragment was zugeschickt ist. 2. Analysieren Sie die Struktur eines kleinen und eines sehr großen ICMP-Pakets. Wie sehen die zugehörigen Ethernet-Frames aus? Zuerst schicken wir ein sehr kleines ICMP-Paket 1 byte groß. debian:~# ping –s 1 –c 1 192.168.0.12 PING 192.168.0.12 (192.168.0.12): 1 data bytes 9 bytes from 192.168.0.12: icmp_seq=0 ttl=128 --- 192.168.0.12 ping statistics --1 packets transmitted, 1 packets received, 0% packet loss Abb. 5 – Übertragung eines kleinen ICMP-Pakets Man sieht dass, das Paket in einem Frame geschickt wird. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 10 2 Projektaufgabe Internet Protocol, Src Addr: 192.168.0.13 (192.168.0.13), Dst Addr: 192.168.0.12 (192.168.0.12) 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: 29 Identification: 0x0000 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0xb976 (correct) Source: 192.168.0.13 (192.168.0.13) Destination: 192.168.0.12 (192.168.0.12) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0xf1fa (correct) Identifier: 0x0605 Sequence number: 00:00 Data (1 byte) Abb. 6 – Gefangenes ICMP-Paket Dieses geschieht, weil die maximale Länge eines Ethernet-Frames 1524 Bytes ist (einschließlich Header-Daten). Wir senden 1 Byte mit dem ping Befehl, also können die Daten in nur einen Frame gesendet werden. Man sieht auch dass, das Don’t fragment flag gesetzt ist. Das heißt, dass das Paket kann in nur einen Frame gesendet und ist keine Notwendigkeit in mehrere Fragmenten zersplittert zu werden. Als nächstens schicken wir ein sehr großes ICMP-Paket, 65000 bytes lang. debian:~# ping –s 65000 –c 1 192.168.0.12 PING 192.168.0.12 (192.168.0.12): 65000 data bytes 65008 bytes from 192.168.0.12: icmp_seq=0 ttl=128 time=2.7 ms --- 192.168.0.12 ping statistics --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 2.7/2.7/2.7 ms Abb. 7 – Übertragung eines großen ICMP-Pakets Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 11 2 Projektaufgabe Hier sind die ersten zwei Pakete der Datenübertragung: Internet Protocol, Src Addr: 192.168.0.13 (192.168.0.13), Dst Addr: 192.168.0.12 (192.168.0.12) 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: 1388 Identification: 0xea96 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 63640 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0xaa7d (correct) Source: 192.168.0.13 (192.168.0.13) Destination: 192.168.0.12 (192.168.0.12) Data (1368 bytes) Internet Protocol, Src Addr: 192.168.0.13 (192.168.0.13), Dst Addr: 192.168.0.12 (192.168.0.12) 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: 1500 Identification: 0xea96 Flags: 0x06 .1.. = Don't fragment: Set ..1. = More fragments: Set Fragment offset: 62160 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0x8ac6 (correct) Source: 192.168.0.13 (192.168.0.13) Destination: 192.168.0.12 (192.168.0.12) Data (1480 bytes) Abb. 8 – Gefangene ICMP-Pakete Bei einer größeren Transport Menge, sieht man dass, das Paket in mehreren Fragmenten gespaltet wird. In unserem Fall ist die Menge 65000 bytes und man sieht an Fragment offset wieviele Bytes bleiben, bis die Übertragung komplett ist. Man sieht auch dass, ab das zweite Frame der Flag More fragments gesetzt ist. Das heißt, dass eins oder mehrere Fragmente folgen. 3. Analysieren Sie die Struktur eines IP-Pakets und setzen sie die Header-Inhalte in Bezug zu den verwendenten Rechnern. Ein IP-Paket sieht wie folgt aus: Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 12 2 Projektaufgabe 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Abb. 9 – IP-Header Version: 4 bits Das Versionsfeld zeigt das Format der Internet-Überschrift an. IHL: 4 bits Internet Header Length ist die Länge der internet header in 32 Bitwörtern und zeigt folglich auf den Anfang der Daten. Der Mindestwert für eine korrekte Überschrift ist 5 bytes. Type of Service: 8 bits Type of Sevice liefert eine Hinweis über die abstrakten Parameter der Qualität des Services (Quality of Service) gewünscht. Total length: 16 bits Total length ist die Länge des Datagram, in Octets, einschließlich der Internet header und der Daten. Identification: 16 bits Ist ein kennzeichnender Wert zugewiesen durch den Absender. Es wird benutzt, wenn die Fragmente eines Datagram zusammengebaut werden. Flags: 3 bits Bit 0: reserviert, muss Null sein Bit 1: (DF) 0 = Fragmentiert, 1 = Nicht Fragmentiert Bit 2: (MF) 0 = Letztes Fragment, 1 = Mehrere Fragmente Fragment Offset: 13 bits Dieses Feld zeigt an, wo im Datagram dieses Fragment gehört. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 13 2 Projektaufgabe Time to Live: 8 bits Dieses Feld zeigt an, die maximale Zeit dass das Datagram im Internet-System bleibt. Protocol: 8 bits Dieses Feld zeigt das next level Protokoll an, das im Datenteil des Internet-Datengramms verwendet wird. Header checksum: 16 bits Eine Prüfsumme von der Header. Da einige Header (z.B., Time to Live) werden geändert, Die Prüfsumme wird neugerechnet und wird überprüft an jedem Punkt, daß die Internet-Header verarbeitet ist. Source Address Die Quelladresse. Destination Address Die Zieladresse Options Options können oder nicht in den Datengrammen erscheinen. Sie müssen durch alle IP modules (host und gateways) eingeführt werden. Was wahlweise freigestellt ist, ist ihr Übertragung in jedem bestimmten Datengramm, nicht ihre Implementierung. Als Beispiel betrachten wir das folgende Paket abgefangen von Ethereal: Internet Protocol, Src Addr: 192.168.0.13 (192.168.0.13), Dst Addr: 192.168.0.12 (192.168.0.12) 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: 1500 Identification: 0xea96 Flags: 0x06 .1.. = Don't fragment: Set ..1. = More fragments: Set Fragment offset: 13320 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0xa29f (correct) Source: 192.168.0.13 (192.168.0.13) Destination: 192.168.0.12 (192.168.0.12) Data (1480 bytes) Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 14 2 Projektaufgabe Abb. 10 – Gefangenes IP-Paket Die Informationen, die wir von diesem Paket erhalten, ist die verwendete IP version (4), die länge des Headers, Information über die Art des Services, die Gesamtlänge des Pakets (1500 bytes), das es ein Fragment ist und sie nicht das letzte ist und wo im Datengramm dieses Fragment gehört. Wir sehen auch das next-level Protokoll dieses Pakets (ICMP (0x01)), die Prüfsumme der Header, die Ziel- und Quell-IP-Adressen und am Ende die Daten. Kurz, ist ein ICMP-Paket vom Rechner mit IP 192.168.0.13 zum Rechner mit IP 192.168.0.12 zugeschickt. 4. Analysieren Sie die Struktur eines UDP-Pakets. 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... Abb. 11 – UDP-Header Source Port Source Port ist- ein wahlweise freigestelltes Feld, wenn sinnvoll, zeigt es das Port des sendenden Prozesses an und kann angenommen werden, um das Port zu sein, an das eine Antwort in Ermangelung aller möglicher anderen Informationen adressiert werden sollte. Destination Port Destination Port hat eine Bedeutung innerhalb des Kontextes einer bestimmten Internet-Zieladresse. Length Length ist die Länge in Octets des Datengramms einschließlich dieser Header und der Daten. Checksum Checksum ist die Prüfsumme der Header. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal 15 2 Projektaufgabe Kommunikationstechnik 2 2.2.2 Analyse einer POP3 Verbindung In diesem Teil analysieren wir eine beliebige POP3-Verbindung von einem beliebigen Client an den Mail-Server. Um die Möglichkeiten der Überwachung zu demonstrieren, haben wir jegliche (POP3-)Verbindungen zu dem Mailsserver (mail.intern.ktds-labor.de) mitgehört. Schwerpunk der Analyse ist, neben den Aufgaben zur Netzverwaltung (ARP/DNS) und protokolltechnischen Eigenschaften (Verbindungsaufbau mit 3-Way-Handshake/Verbindungsabbau), die Protokollierung der Nutzdaten. Wir wollen zeigen, das es möglich ist Zugriff auf fremde, vertrauliche Daten zu bekommen. Netzverkehr den unser Rechner (Überwacher) erzeugt wird nicht berücksichtigt. Die Bildschirmfotos von Ethereal beinhalten zum Teil nur Zusammenfassungen der Pakete. Versuchsaufbau: Rechner MAC IP Mailserver 00:50:56:10:60:17 10.23.60.17 Nameserver 00:50:56:10:60:14 10.23.60.14 Client 00:50:56:10:60:29 10.23.60.29 Überwacher 00:50:56:10:60:28 10.23.60.28 Vorbereitung Zuerst stellen wir sicher, dass der Mailserver funktioniert. Dann richten wir Ethereal wie folgt ein: Capture: Setze Netzwerkkarte in den Promiscuous Mode, Filtere alle Pakete, die mail.intern.ktdslabor.de als Source oder Destination haben. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal 16 2 Projektaufgabe Kommunikationstechnik 2 ARP Anfrage (Adress Resolution Protocol) Bei unserem Versuchsaufbau werden maximal 4 ARP-Anfragen gestellt: 1. Der Client erfragt die MAC des Nameservers 2. Der Nameserver erfragt die MAC des Clients 3. Der Client erfragt die MAC des Mailservers 4. Der Mailserver erfragt die MAC des Clients Dies ergibt sich, weil zwei beidseitige Verbindungen notwendig sind. Zuerst fragt der Client die IP des Mail-Servers vom Nameserver an. Dazu benötigt er die MAC des Nameservers (Anfrage 1). Der Nameserver schickt die Nachricht zurück, muss also auch die MAC des Client kennen (Anfrage 2). Das gleiche wiederholt sich bei der Kommunikation zwischen dem Client und dem Mailserver (Anfragen 3 und 4). Die ARP Anfrage kann fehlen, wenn der Rechner die MAC Adresse bereits im ARP Cache hat. Man kann die Anfrage provozieren, indem man den entsprechenden Eintrag im Cache löscht.. (Anzeige des Inhalts mit: arp, Löschen des Caches mit: arp -d) Wir analysieren beispielhaft die vierte ARP-Anfrage. ARP-Anfragen bestehen aus zwei EthernetPaketen. Die ARP-Anfragen und -Antworten sind in Ethernet-Paketen eingebunden, die bereits unter 2.2.1 beschrieben wurden. Wir beachten jetzt nur die Einträge des ARP: Paket 1 Paket 2 Das erste Paket sendet der Nachfrager an die MAC-Broadcast-Adresse ff:ff:ff:ff:ff:ff und fragt nach der Adresse 10.23.60.29 (Target IP address). Das es sich um eine Anfrage(request) handelt, steht im Opcode. Das zweite Paket ist die Antwort(reply), wiederum gekennzeichnet im Opcode. Die Zieladresse ist die MAC ...:17 (Dst im Ethernet-Frame). Das Ergebnis der Anfrage, sprich die gewünschte MACAdresse findet sich unter Sender MAC address. Dieses Paket kann theoretisch von jedem Rechner im Netzwerk kommen, der die MAC-Adresse weiß. In großen Netzwerken ist dies aber meist nicht implementiert, da sonst zu viele Antworten auf eine Nachfrage kommen würden. Hier antwortet nur der “angesprochende” Host selbst. Dies hat den Vorteil, das nicht noch Adressen von nicht mehr existierenden Rechnern ausgeliefert werden. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 17 2 Projektaufgabe DNS Anfrage (Domain Name System) Hier fallen wiederum 2 Anfragen an. 1. Der Client fragt die IP von mail.intern.ktds-labor.de an 2. Der Mailserver fragt den Namen vom Client an Dies ergibt sich, da der Client den Mailserver über einen Namen anspricht (siehe Konfiguration eines Mailsclienten Kapitel 3). Für die Verbindung wird aber die IP benötigt. Der Mailserver braucht den Namen des Clients für die Verbindung nicht, aber für interne Zwecke (z.B. Protokollierung) DNS-Anfragen sind in einem UDP-Paket eingebunden, welches bereits unter 2.2.1 analysiert und dokumentiert wurde. Wir befassen uns hier nur mit der DNS-Anfrage 2: Paket 1: Die Anfrage wird vom Mailserver zum DNS-Server gestellt, zu erkennen an den MAC-Adressen im Ethernet-Frame und an den Src Addr und Dst Addr im IP-Header. Die Anfrage wird am UDP-Port 1026 an den Port 53 (Domain) geschickt. Als Nutzdaten enthält das Paket die Art (Flags 0x0100 Standard Query) und die Anfragen(Queries) an sich. Das aufgezeichnete Paket enthält eine Anfrage, die Anfrage nach dem Namen des Clients. Diese Daten finden wir in der ersten Query: Name: 29.60.23.10.in-addr.arpa entspricht der IP 10.23.60.29. der Type gibt die Art des Eintrages im DNS an, hier also PTR, also eine Auflösung IP->Name. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 18 2 Projektaufgabe Paket 2: Die Antwort erfolgt vom DNS-Server zurück an den Mail-Server, wieder über IP(Auf den Bildschirmfoto abgeschnitten). Die Antwort ist wieder ein UDP-Paket auf der selben „Verbindung“ zurück (UDP Port 53->Port 1026). Wir beachten wieder die DNS Nutzdaten: Es handelt sich um eine Antwort, zu erkennen an den Flags (0x8580 Standard query response). In den Queries sind nochmal die Anfragen aus Paket 1 enthalten, um die Zuordnung herstellen zu können. Unter Answers finden wir am Ende der Zeile schließlich den Namen des Clients (p9.intern.ktds-labor.de). Desweiteren unter Authorative nameservers die Daten des antwortenden Nameservers. TCP 3-Way-Handshake Um eine Verbindung sicher aufzubauen sind 3 Schritte notwendig: 1. Der Client will eine Verbindung aufbauen, und sendet ein SYN-Paket (synchronize) 2. Der Server bestätigt dies (ACK) und initiiert seinerseits auch eine Verbindung (SYN) 3. Der Client bestätigt die Verbindung vom Server mit einem ACK (acknowledge) Durch den 3-Way-Handshake wird sichergestellt, das beide Parteien die Verbindung aufgebaut haben. Diese 3 Schritte sind bei jeder TCP-Verbindung notwending. Hier nun die 3 Pakete in unserem Testfall, Client verbindet sich mit dem Mailserver: Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 19 2 Projektaufgabe Paket 1 Paket vom Client (Src Addr im IP) an den Mailserver (Dsr Addr im IP). Eingebunden ist ein TCP Paket von Port 1033 (zufällig, aber >1024) an den Port 110(pop3). Das es sich hier um ein SYNPaket handelt erkennt man in den Flags (0x0002 SYN). Wichtig ist in den Nutzdaten noch die Sequenznummer, mit der die Verbindung erkannt wird (hier Seq: 0). Paket 2 Rückantwort vom Mailserver an den Client (siehe IP-Protokoll). Die Kommunikation erfolgt wieder auf der selben „Leitung“ also von Port 110->Port 1033. Es handelt sich hier wie erwartet um ein SYN/ACK Paket, zu erkennen in den Flags (0x0012 SYN,ACK). Die Sequenznummer ist eine eigene vom Server, hier allerdings auch 0. Die Ack-Nummer ist die Sequenznummer +1, also hier 1. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 20 2 Projektaufgabe Paket 3 Das dritte Paket geht wieder vom Client zum Server. Es handelt sich um ein ACK-Paket, wiederum an den Flags zu erkennen (0x0010 ACK). Die „Leitung“ ist wieder Port 1033->Port 110. Die Sequenznummer ist die erste Sequenznummer des Clienten +1, die Ack-Nummer die Sequenznummer des Servers +1. Als nächstes folgen die eigendlichen Daten, die über die Verbindung ausgetauscht werden sollen. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 21 2 Projektaufgabe Analyse des Transports der Dateninhalte Alle Daten der POP3-Verbindung gehen über die Aufgebaute TCP/IP Verbindung. Die POP3Pakete werden in TCP, IP und Ethernet-Pakete eingebunden. Die Ethernetpakete unterscheiden sich nur in den Quell- und Zieladressen, in unserem Fall also 1. Src: 00:50:56:10:60:17 Dst 00:50:56:10:60:29 Server->Client 2. Src: 00:50:56:10:60:29 Dst 00:50:56:10:60:17 Client->Server Die eingebetteten IP Pakete verhalten sich ähnlich: 1. Src Addr: 10.23.60.17 Dst Addr: 10.23.60.29 Server->Client 2. Src Addr: 10.23.60.29 Dst Addr: 10.23.60.17 Client->Server Die TCP-Pakete beinhalten Angaben über die Ports, und unterschiedliche ACK und SEQ: 1. Src Port: 110 Dst Port: 1033 Server->Client 2. Src Port: 1033 Dst Port: 110 Client->Server Die POP-Pakete beinhalten schließlich die Nutzdaten. Zur Auswertung der Daten benötigen wir nur die Inhalte der POP-Pakete mit der Angabe, welche Daten vom Client und welche vom Server kommen. Die Abbildung der einzelnen Pakete wird deswegen hier weggelassen. Dazu bietet uns Ethereal die Funktion Follow TCP stream. Die Ausgabe sieht wie folgt aus: +OK POP3 mail.intern.ktds-labor.de v2001.78 server ready AUTH +OK Supported authentication mechanisms: LOGIN . USER user1 +OK User name accepted, password please PASS user1 +OK Mailbox open, 5 messages LIST +OK Mailbox scan listing follows 1 922 2 633 3 630 4 646 5 658 . UIDL +OK Unique-ID listing follows 1 429c777600000001 2 429c777600000002 3 429c777600000003 4 429c777600000004 5 429c777600000005 . RETR 1 +OK 922 octets Return-Path: <[email protected]> Received: from there (kt2g1@[10.23.60.80]) .by debian (8.12.3/8.12.3/Debian-7.1) with SMTP id j4VEN7s2000551 .for <[email protected]>; Tue, 31 May 2005 16:23:08 +0200 Message-Id: <200505311423.j4VEN7s2000551@debian> Content-Type: text/plain; charset="iso-8859-1" From: Karl Ransaier <[email protected]> Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 22 2 Projektaufgabe Reply-To: [email protected] To: KTmailer <[email protected]> Subject: Re: banane Date: Tue, 31 May 2005 07:23:34 +0200 X-Mailer: KMail [version 1.3.2] References: <200505311422.j4VEM5s2000521@debian> <200505311422.j4VEMVs2000538@debian> In-Reply-To: <200505311422.j4VEMVs2000538@debian> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 132 Status: ... On Tuesday 31 May 2005 07:22, you wrote: > schoener foenOn Tuesday 31 May 2005 07:22, you wrote: > > .... > > > > fsdafsdfasdf . RETR 2 +OK 633 octets Return-Path: <[email protected]> Received: from there (kt2g1@[10.23.60.80]) .by debian (8.12.3/8.12.3/Debian-7.1) with SMTP id j4VEQQs2000572 .for <[email protected]>; Tue, 31 May 2005 16:26:26 +0200 Message-Id: <200505311426.j4VEQQs2000572@debian> Content-Type: text/plain; charset="iso-8859-1" From: Karl Ransaier <[email protected]> Reply-To: [email protected] To: [email protected] Date: Tue, 31 May 2005 07:26:50 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 11 Status: fghdsfgdsf . RETR 3 [...] RETR 4 [...] RETR 5 [...] DELE 1 +OK Message deleted DELE 2 +OK Message deleted DELE 3 +OK Message deleted DELE 4 +OK Message deleted DELE 5 +OK Message deleted QUIT +OK Sayonara Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 23 2 Projektaufgabe Wir sehen, dass alle Daten unverschlüsselt über das Netz gehen. In einem Netz mit einem Hub können diese Daten von uns mitgelesen werden. Nicht nur, dass wir die eMails dieser Sitzung mitlesen können, wir haben sogar den Benutzernamen und das Passwort des Clienten mitlesen können, und haben so Zugriff auf sein Postfach. Eine Abhilfe schafft die Verwendung von verschlüsselten Verbindungen (pop3s). Abbau der Verbindung Der Abbau der Verbindung muss ebenfalls sicher sein, also von beiden Seiten bestätigt werden. Analog zum Verbindungsaufbau nach dem 3-Way-Handshake Prinzip sind hier wieder 3 Schritte/Pakete notwendig: 1. Client will die Verbindung abbauen, sendet ein FINPakct an den Sever (finalize) 2. Server bestätigt das FIN mit einem ACK und sendet seinerseits wieder ein FIN, dieses kann in einem Paket zusammengefasst werden (FIN/ACK) 3. Der Client bestätigt den Abbau mit einem ACK. Paket 1: Paket vom Client (Src Addr im IP) an den Mailserver (Dsr Addr im IP). Eingebunden ist ein TCP Paket von Port 1033 an den Port 110(pop3). Das es sich hier um ein FIN-Paket handelt erkennt man in den Flags (0x0011 FIN, ACK). Wichtig ist in den Nutzdaten noch die Sequenznummer, mit der die Verbindung erkannt wird (hier Seq: 0). Das ACK ist für den Abbau nicht relevant. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 24 2 Projektaufgabe Paket 2: Rückantwort vom Mailserver an den Client (siehe IP-Protokoll). Die Kommunikation erfolgt wieder auf der selben „Leitung“ also von Port 110->Port 1033. Es handelt sich hier wie erwartet um ein FIN/ACK Paket, zu erkennen in den Flags (0x0011 FIN,ACK). Die Sequenznummer ist eine eigene vom Server, hier allerdings auch 0. Die Ack-Nummer ist die Sequenznummer +1, also hier 1. Paket 3: Das dritte Paket geht wieder vom Client zum Server. Es handelt sich um ein ACK-Paket, wiederum an den Flags zu erkennen (0x0010 ACK). Die „Leitung“ ist wieder Port 1033->Port 110. Die Sequenznummer ist die erste Sequenznummer des Clienten +1, die Ack-Nummer die Sequenznummer des Servers +1. Damit ist die Verbindung auf beiden Seiten abgebaut. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal 25 3 Querschnittsaufgaben Kommunikationstechnik 2 3 Querschnittsaufgaben 3.1 Konzept Wir richten unseren Rechner so ein, dass er seine Hostkonfiguration vom DHCP Server bezieht und in der Lage ist Namensanfragen an DNS Server zu richten. Des weiteren wird ein E-Mail Programm konfiguriert, um E-Mails über einen Server einer andren Gruppe zu senden und zu empfangen. Zu guter Letzt konfigurieren wir einen Browser so, dass er in der Lage ist eine Anfrage an einen HTTP Server zu stellen. 3.2 Lösung 3.2.1 Einrichtung eines Mailclient Folgende Benutzerdaten wurden uns von der Mailservergruppe zugeteilt: E-Mail Adresse: [email protected] Benutzername: user1 Passwort: user1 3.2.2 Einrichtung eines Webbrowser Mit lynx haben wir alle Adressen, die uns die Webserver-Gruppe zur Verfügung gestellt haben, getestet. (z.B. lynx praktikum.ktds-labor.de) Ausgabe: Welcome to Webserver W3 ! Welcome to our new Apache Web Server !!!! _________________________________________________________________ praktikum.ktds-labor.de www.praktikum.ktds-labor.de Links auf weitere Server: Virtual Server www.intern.ktds-labor.de Virtual Server intern.ktds-labor.de Virtual Server www.ktds-labor.de Virtual Server ktds-labor.de 3.2.3 Konfiguration der Netzwerkschnittstelle über dhcp Durch den Aufruf von dhclient werden die relevanten Informationen (IP-Adresse, Subnetzmaske, Gateway, Nameserver) an den Client übertragen. Die dhcp-Anfrage wird an die Broadcast-MAC (ff:ff:ff:ff:ff:ff) gesendet. Prüfen kann man die IP und Subnetzmaske mit ifconfig. debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:10:60:28 inet addr:10.23.60.28 Bcast:10.23.60.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:37672 errors:0 dropped:0 overruns:0 frame:0 TX packets:267 errors:0 dropped:0 overruns:0 carrier:0 Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis Netzwerkanalyse mit Ethereal Kommunikationstechnik 2 26 3 Querschnittsaufgaben collisions:0 txqueuelen:100 RX bytes:5611653 (5.3 MiB) TX bytes:24430 (23.8 KiB) Interrupt:18 Base address:0x1080 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:184 errors:0 dropped:0 overruns:0 frame:0 TX packets:184 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:12160 (11.8 KiB) TX bytes:12160 (11.8 KiB) Der Nameserver steht nach der dhclient Abfrage in der Datei /etc/resolv.conf debian:~# cat /etc/resolv.conf search intern.ktds-labor.de nameserver 10.23.60.14 Wenn eine Gatewayadresse übertragen wird, kann diese mit route erfahren werden. Benedikt Arnold - Christian Fehmer - Ioannis Chouklis - Dimitrios Ramnalis
