Netzwerk-Simulation mit Virtual Network User Mode Linux - VNUML ...

Netzwerk-Simulation mit Virtual Network User Mode Linux - VNUML Internet Message Control Protocol - ICMP Projekt-Praktikum Sommersemester 2005

Nadia Ettaous Andrew Kiprop ....................... Betreuer: Prof. Dr. Ch. Steigner Dipl.-Inf. Harald Dickel ....................... 31. August 2005

1

Inhaltsverzeichnis 1 Einleitung 1.1 ICMP 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 4 5 6 7 7 8 9 13

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13 14 15 16 18

3 ICMP Nachrichtentypen 3.1 Echo Request - Echo Reply . 3.2 Destination Unreachable . . . 3.3 Time Exceeded . . . . . . . . 3.4 Redirect . . . . . . . . . . . . 3.5 Source Quench . . . . . . . . 3.6 Parameter Problem . . . . . . 3.7 Information Request-Reply . . 3.8 Address Mask Request-Reply

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

18 19 21 22 22 24 24 25 25

. . . . . . Ping . . . Traceroute Netstat . Route . . Ifconfig . . Tcpdump Arp . . .

2 Beispielnetze 2.1 Dateiaufbau . 2.2 Beispielnetz 1 2.3 Beispielnetz 2 2.4 Beispielnetz 3

. . . .

. . . .

4 Ethereal

25

5 Schlusswort 29 5.1 ICMP Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6 Anhang 6.1 ICMP Tabelle . . . . . . . . . . . . 6.2 XML-Syntax des Beispiel-Szenarios 6.2.1 Syntax des Beispielnetzes 1 6.2.2 Syntax des Beispielnetzes 2 6.2.3 Syntax des Beispielnetzes 3 6.2.4 Syntax des Beispielnetzes 4 6.2.5 Syntax des Beispielnetzes 5 6.3 Aufgaben und L¨osungen . . . . . . 2

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

31 31 32 32 33 34 35 37 39

6.3.1 6.3.2

Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 39 L¨osungen . . . . . . . . . . . . . . . . . . . . . . . . . 42

3

1

Einleitung

In diesem Projekt-Praktikum wurde das Simulationspaket VNUML getestet. IcmpGroup besch¨aftigte sich mit dem Einsatz des Internet Control Message Protocols (ICMP) in der VNUML Umgebung. F¨ ur die kommenden Anwendungen wurde das Netz beispielnetz.xml benutzt. Die dazu geh¨orige XML-Datei finden Sie unter dem Kapitel Anhang 6.

Abbildung 1: Beispielnetz 1

1.1

ICMP

Das Internet Control Message Protocol (ICMP) benutzt wie TCP und UDP das Internet Protocol IP, ist also ein Teil der Internet-Protokoll-Familie. Es dient in Netzwerken zum Austausch von Fehler- und Informationsmeldungen. Obwohl ICMP eine Ebene u ¨ber IP angeordnet ist, ist es in IP integriert. Es wird von jedem Router und PC erwartet, ICM-Protokoll zu sprechen. Die 4

meisten ICMP- Pakete enthalten Diagnose-Informationen, sie werden vom Router zur Quelle (engl. source) zur¨ uckgeschickt, wenn der Router Pakete verwirft, z.B. weil das Ziel (engl. destination) nicht erreichbar ist, die TTL (Time-to-live) abgelaufen ist, usw. Es gilt der Grundsatz, dass ein ICMPPaket niemals ein anderes ICMP-Paket ausl¨ost, d.h. die Tatsache, dass ein ICMP Paket nicht zugestellt werden konnte wird nicht durch ein Weiteres signalisiert. Eine Ausnahme zu diesem 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. Der Aufbau einer ICMP-Nachricht l¨asst sich wie folgt darstellen:

Abbildung 2: Aufbau einer ICMP-Nachricht

In den n¨achsten Kapiteln werden anhand eines Beispielnetzes verschiedene Tools unter vnuml getestet und dokumentiert. 1.1.1

Ping

Ping ist ein Computerprogramm, mit dem u uft werden kann, ob ein be¨berpr¨ stimmter Host in einem IP-Netzwerk erreichbar ist. Entwickelt wurde Ping urspr¨ unglich Ende 1983 von Mike Muus. Funktionsweise Ping (in Anlehnung an das Ger¨ausch eines Sonars) sendet ein ICMP-EchoRequest-Paket an die Zieladresse des zu u ufenden Hosts. Der Empf¨anger ¨berpr¨ muss, insofern er das Protokoll unterst¨ utzt, laut Protokollspezifikation eine Antwort zur¨ ucksenden: ICMP Echo-Reply. Ist der Zielrechner nicht erreichbar, antwortet der Router: Network unreachable (Netzwerk nicht erreichbar) oder Host unreachable (Gegenstelle nicht erreichbar). Aus einer fehlenden Antwort kann man allerdings nicht eindeutig darauf schließen, dass die Gegenstelle nicht erreichbar ist. Manche Hosts sind n¨amlich so konfiguriert, dass sie ICMP-Pakete ignorieren und verwerfen. 5

¨ Ubergibt man dem ping-Kommando einen Hostnamen anstatt einer IP-Adresse, l¨asst das Programm diesen durch das Betriebssystem aufl¨osen. Bei fehlerhaften Konfigurationen (hosts-Datei, lmhosts-Datei, WINS, DNS) kann der Name nicht aufgel¨ost werden, worauf das Programm eine Fehlermeldung ausgibt. Einige Parameter sind bei Ping einstellbar. Zum Beispiel bestimmt die Wiederholrate, wie h¨aufig ein Paket gesendet wird. Die Paketgr¨osse bestimmt die Gr¨osse des ICMP-Echo-Request-Pakets. Beispiel host1:∼# ping 10.0.1.2 PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data. 64 bytes from 10.0.1.2: icmp seq=1 ttl=63 time=483 ms 64 bytes from 10.0.1.2: icmp seq=2 ttl=63 time=63.0 ms 64 bytes from 10.0.1.2: icmp seq=3 ttl=63 time=1.91 ms 64 bytes from 10.0.1.2: icmp seq=4 ttl=63 time=1.84 ms 64 bytes from 10.0.1.2: icmp seq=5 ttl=63 time=1.91 ms : Es werden Datenpakete an den Rechner Host2 (10.0.1.2) gesandt. Vom Program wird die Zeit gemessen, bis die Antwort des Hosts eintrifft. Die Zeitangabe sagt aus, wie lange es dauert, bis ein Datenpaket zum Host und wieder zur¨ uck braucht. Man kann daran grob erkennen, ob die Gegenstelle funktioniert und mit welcher Verz¨ogerung bei einer Verbindung zu rechnen ist. Die Angabe TimeToLive ist dazu da, um grob nachvollziehen zu k¨onnen, u ¨ber wie viele Router der Ping-Befehl gelaufen ist. 1.1.2

Traceroute

Traceroute ist ein Diagnose-Werkzeug, mit dem ermittelt werden kann, welche Router (Zwischensysteme) ein Datenpaket u ¨ber ein IP-Netz passiert, bis es bei einem bestimmten Host ankommt. Traceroute arbeitet u ¨blicherweise mit dem ICMP-Teil der IP-Spezifikation, u uckmeldungen gegeben ¨ber das R¨ werden. Dabei werden TCP-, UDP- oder ICMP-Pakete mit einem ver¨anderten und jeweils um 1 erh¨ohten Time-to-live (TTL) Wert, beginnend mit 1, gesendet. Ein Router im Netz, der ein Paket mit TTL=1 empf¨angt, dekrementiert die TTL, verwirft dieses und sendet die ICMP-Antwort Typ 11: ”Time-to-live exceeded”und Code 0: ”Time to life exceeded in transit”an den Absender mit seiner Adresse zur¨ uck. Die Summe der so gesammelten Adressen kennzeichnet dann den Weg durch das Netz. Die Anzeige von traceroute zeigt nicht immer den tats¨achlichen Weg, den die Datenpakete nehmen. Es wird beeinflusst von Firewalls, fehlerhaften Im6

plementierungen des IP-Stacks, Network Address Translation, Routing und anderen Faktoren. Beispiel host1:∼# traceroute 10.0.1.2 traceroute to 10.0.1.2 (10.0.1.2), 30 hops max, 38 byte packets 1 10.0.0.2 (10.0.0.2) 76.389 ms 1.900 ms 2.203 ms 2 10.0.1.2 (10.0.1.2) 9.530 ms 3.131 ms 2.941 ms :

1.1.3

Netstat

Anzeige der Netzverbindungen Netstat zeigt Protokollstatistiken und aktuelle Rechnernetz-Verbindungen an. Damit kann man erkennen zu welchen Rechnern direkte Verbindungen bestehen. Unter Umst¨anden kann man so die IP-Adresse der Gespr¨achspartner in Instant-Messaging-Programmen erkennen. Man kann damit aber auch herausfinden ob man mit einem Trojaner infiziert ist. Netstat ist ein Kommandozeilen-Programm, das bedeutet, dass es keine einen graphische Oberfl¨ache besitzt, sondern in einer sogenannten Shell (CLI) l¨auft. Beispiel host1:∼# netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp6 0 0 ::ffff:192.168.1.14:ssh ::ffff:192.168.1.1:1256 ESTABLISHED Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node Path unix 5 [ ] DGRAM 1245 /dev/log unix 2 [ ] DGRAM 1360 unix 2 [ ] DGRAM 1328 unix 2 [ ] DGRAM 1257

1.1.4

Route

Bestimmte Netzwerkhardware, wie z.B. ein Router oder eine Netzwerkkarte, beeinhalten eine Art ”Adress-Tabelle”-Routingtabelle (engl. Routing-Table)- welche zur Wegfindung beim Routing eingesetzt wird. Um die Routingtabelle einzusehen, benutzt man den Befehl route. Beispiel host1:∼# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface

7

192.168.1.144 10.0.0.0 10.0.1.0

1.1.5

* * 10.0.0.2

255.255.255.252 U 255.255.255.0 U 255.255.255.0 UG

0 0 0

0 0 0

0 0 0

eth0 eth1 eth1

Ifconfig

ifconfig (BSD): Netzwerkschnittstellenkonfiguration. Beispiel host1:∼# ifconfig

eth0

Link encap:Ethernet HWaddr FE:FD:00:00:01:01 inet addr:192.168.1.146 Bcast:192.168.1.255 Mask:255.255.255.252 inet6 addr: fe80::fcfd:ff:fe00:101/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:410 errors:0 dropped:0 overruns:0 frame:0 TX packets:275 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30221 (29.5 KiB) TX bytes:37458 (36.5 KiB) Interrupt:5

eth1

Link encap:Ethernet HWaddr FE:FD:00:00:01:01 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::fcfd:ff:fe00:101/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:32 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2368 (2.3 KiB) TX bytes:2818 (2.7 KiB) Interrupt:5

lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

8

1.1.6

Tcpdump

Anzeige von Netzwerkpacketen(Netzwerk-Sniffer). Anwendungen tcpdump -c anzahl Dieser Befehl zeigt je nach ”anzahl”an wieviel Paketverkehr ausgef¨ uhrt wird, ansonsten w¨ urde es endlos weiter gehen. Beispiel host1:∼# tcpdump -c 2 15:12:24.939048 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427121028:427121140(112) ack 2241214261 win 2664 15:12:25.008014 IP 192.168.1.145.1493 > 192.168.1.146.ssh: . ack 112 win 18848 2 packets captured 8 packets received by filter 0 packets dropped by kernel tcpdump -F file Dieser Befehl benutzt die Datei als Input f¨ ur die Filter expression. tcpdump -C filesize Dieser Befehl kontrolliert ob die zu speichernde Datei eventuell gr¨osser ist als filesize, sollte dies so sein, dann sollte die aktuelle Datei geschlossen werden und eine neue ge¨offnet werden. Beispiel host1:∼# tcpdump -C 10 -c 2 15:14:41.908222 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427481172:427481284(112) ack 2241217573 win 2664 15:14:41.948872 IP 192.168.1.145.1493 > 192.168.1.146.ssh: ack 112 win 32767 2 packets captured 8 packets received by filter 0 packets dropped by kernel tcpdump -i interface Dieser Befehl beobachtet nur die Schnittstelle ”Interface”. Beispiel host1:∼# tcpdump -i eth0 -c 2 15:15:36.772540 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427482916:427483028(112)

9

ack 2241218389 win 2664 15:15:36.814261 IP 192.168.1.145.1493 > 192.168.1.146.ssh: . ack 112 win 32767 2 packets captured 8 packets received by filter 0 packets dropped by kernel tcpdump -m module Damit werden MIB Module zu jeder Zeit ins tcpdump geladen. Beispiel host1:∼# tcpdump -m icmp -c 2 15:16:24.342569 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427485140:427485252(112) ack 2241219589 win 2664 15:16:24.383267 IP 192.168.1.145.1493 > 192.168.1.146.ssh: . ack 112 win 32767 2 packets captured 8 packets received by filter 0 packets dropped by kernel tcpdump -r file Hier wird eine Datei aus einer Netzwerk-Schnittstelle ausgelesen. tcpdump -s snaplen/zahl Beispiel host1:∼# tcpdump -s 2 -c 2 15:17:34.647659 [|ether] 15:17:34.655480 [|ether] 2 packets captured 8 packets received by filter 0 packets dropped by kernel tcpdump -T type Es wird nach einem Pakettyp spezifiziert, zum Beispiel rtp, rpc, oder snmp. Beispiel host1:∼# tcpdump -T rtp -c 2 15:18:59.756528 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427489860:427489972(112) ack 2241222469 win 2664 15:18:59.798882 IP 192.168.1.145.1493 > 192.168.1.146.ssh: . ack 112 win 32767 2 packets captured 8 packets received by filter

10

0 packets dropped by kernel tcpdump -w file Dieser Befehl speichert die Paket-Dateiein in einer Datei zur sp¨ateren Analyse. /home/projekt/IcmpGroup tcpdump -E algo:secret Beispiel host1:∼# tcpdump -E icmp -c 2 15:20:04.875562 IP 192.168.1.146.ssh > 192.168.1.145.1493: P 427492228:427492340(112) ack 2241223909 win 2664 15:20:04.916973 IP 192.168.1.145.1493 > 192.168.1.146.ssh: . ack 112 win 32767 2 packets captured 8 packets received by filter 0 packets dropped by kernel

Speichern tcpdump -i interface > Dateiname ¨ Bei der ”parallelen” Uberwachung von Host1 an der Schnittstelle eth0, ”Bsp. ping 10.0.0.2”, kann man diese als Textdatei speichern, oder als dumpfile *.dmp. Das Speichern muss vom Host aus erledigt werden. Dabei kann man den Verlauf nicht direkt einsehen, sondern erst in der gespeicherten Datei. Diese Datei befindet sich in dem aktuell benutzten Ordner, in unserem Fall: /home/projekt/IcmpGroup. Beispiel becks:/home/projekt/IcmpGroup# tcpdump -i Host1-eth0 > probe protocol decode listening on R1-eth0, link-type EN10MB (Ethernet), capture size 96 bytes 40 packets captured 40 packets received by filter 0 packets dropped by kernel Filtern tcpdump ’packet-type’ Damit werden nur Pakete beobachtet die in packet-type angeben werden. Parallel dazu sollte in einem anderen Terminal eine virtuelle Maschine angepingt werden. In diesem Beispiel befinden sich beide Terminals in Host1. Beispiel host1:∼# tcpdump -i eth1 ’icmp’ -c 2 15:31:32.211758 IP Host1 > 10.0.0.2: icmp 64: echo request seq 7 15:31:32.212657 IP 10.0.0.2 > Host1: icmp 64: echo reply seq 7

11

2 packets captured 2 packets received by filter 0 packets dropped by kernel Proto Mit diesem Befehl filtert man bestimmte Paketarten. Parallel muss ein virtueller Rechner angepingt werden. Man kann aber auch die Option ’icmp’ benutzen, anstatt proto.’icmp’ zeigt nur den Paketverkehr von icmp-Paketen an. Beispiel host1:∼# tcpdump -i eth1 ’icmp’ -c 2 15:32:55.162320 IP Host1 > 10.0.0.2: icmp 64: echo request seq 89 15:32:55.163392 IP 10.0.0.2 > Host1: icmp 64: echo reply seq 89 2 packets captured 2 packets received by filter 0 packets dropped by kernel Destination Hier wird wieder parallel ein virtueller Rechner angepingt werden. Als ip kann man nur die des pingenden Rechners und die des anzupingenden Rechners angeben. Diese Ausf¨ uhrung gibt request an. tcpdump dst host ip Beispiel host1:∼# tcpdump -i eth1 dst 10.0.0.2 15:36:08.620698 IP Host1 > 10.0.0.2: icmp 64: echo request seq 280 15:36:09.639860 IP Host1 > 10.0.0.2: icmp 64: echo request seq 281 Source Dieser Befehl gibt reply an und parallel muss ein virtueller Rechner angepingt werden. Als ip kann man nur die des pingenden Rechners und die des anzupingenden Rechners angeben. tcpdump src host ip Beispiel host1:∼# tcpdump -i eth1 src 10.0.0.2 15:35:30.131865 IP 10.0.0.2 > Host1: icmp 64: echo reply seq 242 15:35:31.147516 IP 10.0.0.2 > Host1: icmp 64: echo reply seq 243 Host Ein virtueller Rechner wird parallel angepingt. Als ip kann man nur die des pingenden Rechners und die des anzupingenden Rechners angeben. Es werden nursource und destination field der Pakete gefieltert. tcpdump host ip Beispiel host1:∼# tcpdump -i eth1 host 10.0.0.1 -c 2

12

15:46:35.987363 IP Host1 > 10.0.0.2: icmp 64: echo request seq 899 15:46:35.988250 IP 10.0.0.2 > Host1: icmp 64: echo reply seq 899 Falls eine Datei im Dateisystem einer VM gespeichert wurde, d¨ urfte das Auslesen von dort aus schwierig sein. Deshalb soll die Datei in einem eigenem Verzeichnis kopiert werden. Dies geht folgendermassen: • Wechsle von VM auf Host (mit ’exit’) host1:∼# exit logout Connection to Host1 closed. • Vom Host aus, auf VM zugreifen (mit deren PIN) und Datei auf einem beliebigen Ziel kopieren: nitrogen:/home/projekt# scp Host1:tee /home/projekt/IcmpGroup/ Password: tee 100 • Danach ist die Datei dann im eigenen Verzeichnis (hier: ./IcmpGroup/)

1.1.7

Arp

ARP (Address Resolution Protocol) ist ein Netzwerkprotokoll, das die Zuordnung von Internetadressen zu Hardwareadressen m¨oglich macht. Obwohl es nicht auf Ethernet- und IP-Protokolle beschr¨ankt ist, wird es fast ausschließlich im Zusammenhang mit IP-Adressierung auf Ethernet-Netzen verwendet. ARP geh¨ort zur Internetschicht der TCP/IP-Protokollfamilie. Beispiel host1:∼# arp Address HWtype HWaddress Flags Mask Iface 192.168.1.145 ether 00:FF:A7:F0:E7:04 C eth0

2

Beispielnetze

Nachdem einige M¨oglichkeiten zum Testen und u ufen des Datenverkehrs vor¨berpr¨ gestellt wurden, wird nun eine Einf¨ uhrung in das Erstellen von Netzen mit Hilfe von XML beschrieben. Die Nachrichtenbeispiele und Ausgaben wurden mit VNUML getestet und festgehalten. Inbesondere wird hier das Netzbeispiel-Szenario eingesetzt, dessen XMLSyntax im Anhang vor zu finden ist.

13

2.1

Dateiaufbau

Eine VNUML-Datei beginnt mit der Angabe der verwendeten XML-Version und dem Ort der VNUML-DTD-Datei, die die VNUML-Sprache definiert (Tag). Die Spezifikation der Simulation muss mit einem -Tag beginnen und mit dem schließenden -Tag enden. Zwischen diesen beiden Tags k¨onnen vier weitere Tags (, , und ) zum Definieren der Netzwerke und Rechner gesetzt werden. Der Rahmen einer VNUML-Datei sieht so aus: ... ...

global Die ”global”-Definitionen betreffen das gesamte Szenario und gelten somit f¨ ur alle Rechner des virtuellen Netzwerks. Mit dem Tag wird die Version der VNUML-DTD-Datei nur einmal angegeben. net Das Einf¨ uhren eines virtuellen Netzwerks geschieht mit dem Tag . Innerhalb dieses Tags muss ein eindeutiger Name (name=...) gesetzt werden. Zus¨atzlich sind u ¨ber das Attributtype zwei Netzwerke m¨oglich. • virtual bridge (Der Einsatz einer virtuellen Bridge zum Verbinden der virtuellen Rechner, die mit dem Netz verbunden sind. Hier sind root-Rechte n¨otig.) • uml switch (Zum Verbinden der virtuellen Rechner des Netzes erzeugt. Es sind keine root-Rechte n¨otig.) vm Virtuelle Rechner werden mit Hilfe des -Tags realisiert. Innerhalb dieses Tags werden weitere Tags zur Beschreibung der virtuellen Rechner ben¨otigt. • filesystem Gibt den Ort der Datei an. • mem Gibt die Gr¨osse des Arbeitsspeichers an. 14

• if Hier werden Netzwerk-Schnittstellen auf dem virtuellen Rechner angelegt. • route Erm¨oglicht das Konfigurieren von statischen Routen. • forwarding Erm¨oglicht das Weiterreichen von IP-Paketen. host Der -Tag ist a¨hnlich zum -Tag. Dieser Tag dient zum Definieren einer Verbindung zwischen einer Schnittstelle und einem Netz. Die Schnittstelle f¨ ur die neue virtuelle Verbindung wird auf dem Host automatisch erzeugt und hat stets den Namen des virtuellen Netzwerks, mit dem sie verbunden ist. In den folgenden Unterkapiteln werden verschiedene Netze veranschaulicht und deren XML-Dateien im Anhang pr¨asentiert.

2.2

Beispielnetz 1

Abbildung 3: Beispielnetz 1

15

Dieses einfache Netz enth¨alt zwei Hosts und einen Router. Host1 ist an net0 und Host2 an net1 angeschlossen. Alle Routen sind statisch vordefiniert.

2.3

Beispielnetz 2

Abbildung 4: Beispielnetz 2

Dieses Netz besteht aus ebenfalls zwei Host. Jedoch hat dieses Netz noch einen zus¨atzlichen Router, der hier als default-Router dient. Die Besonderheit dieses Routers ist, dass dieser die Aufgabe der Weiterleitung hat. Sollte ein Rechner einen anderen an pingen wollen, so gelangen die Daten erst an den default-Router und werden von diesem dann an das gew¨ unschte Ziel weitergeleitet. An diesem Netz wurde noch etwas ausprobiert dass in der Einleitung nicht vorgef¨ uhrt wurde. Angenommen man startet von Host1 und m¨ochte 10.0.2.2 an pingen. Anhand des Netzes weiss man, dass es unsinnig ist wenn der Weg zum Ziel 16

erst u ¨ber den default-Router geht. Aber was passiert wenn man diesen ping durchf¨ uhrt? -Ausgabe host1:∼# ping 10.0.2.2 PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data. >From 10.0.1.3: icmp seq=1 Redirect Host(New nexthop: 10.0.1.2) 64 bytes from 10.0.2.2: icmp seq=1 ttl=64 time=11.2 ms >From 10.0.1.3: icmp seq=2 Redirect Host(New nexthop: 10.0.1.2) 64 bytes from 10.0.2.2: icmp seq=2 ttl=64 time=2.01 ms >From 10.0.1.3: icmp seq=3 Redirect Host(New nexthop: 10.0.1.2) 64 bytes from 10.0.2.2: icmp seq=3 ttl=64 time=1.79 ms Hier sieht man das in der Ausgabe eine Wieterleitung (redirect) statt gefunden hat. Nachdem erkannt wurde dass der k¨ urzeste Weg nicht u ¨ber den default-Router geht, sondern u ¨ber den nexthop mit der ip 10.0.1.2. Somit gelangen wir schneller zum Ziel 10.0.2.2.

17

2.4

Beispielnetz 3

Abbildung 5: Beispielnetz 3

Dieses Netz ist etwas gr¨osser als die anderen beiden. Nun sind drei Router und f¨ unf Netze vorhanden. Die Besonderheit an diesem Netz ist das Deklarieren eines Host (ip 10.0.4.2).

3

ICMP Nachrichtentypen

ICMP ist zwar eine Ebene u ¨ber IP angeordnet aber in IP integriert. ICMPNachrichten werden beim Versand im Datenteil von IP-Datagrammen eingekapselt. Dabei sind im IP-Header der Servicetyp immer 0 und die Protokollnummer immer 1. Die wesentlichen Headers einer ICMP-Nachricht sind das Typfeld oder type, die die Klasse der ICMP-Nachricht angibt und das Codefeld odercode, die die Art der Nachricht spezifiziert. Beide sind jeweils 8 Bit lang und legen zusammen die Funktionalit¨at der einzelnen ICMP-Pakete 18

fest. Die eigentlichen Informationen werden im Nachrichtenfeld (ICMP Data) oder Daten festgehalten, die weitere Felder beinhalten k¨onnen. Man kann die Nachrichtentypen in zwei teilen: Die Anfragetypen und Fehlertypen. Die Anfragen werden von einem Rechner (oder in VNUML von einer virtuellen Maschine) versendet. Kein Rechner oder VM ist jedoch verpflichtet, ICMP-Nachrichten zu versenden, mit einer Ausnahme: jeder Rechner oder VM muss auf ein Echo Request immer mit einem Echo Reply antworten. (s.u.) Die Tabelle fasst alle Nachrichtentypen zusammen. Man liest die Tabelle wie folgendes: empf¨angt ein Rechner eine Nachricht mit Typ=3 und Code=2, so kann er bei Kenntnis dieser bestimmen, was die Fehler verursacht hat, in diesem Fall dass der Absender das vorher angesprochener Protokoll unbekannt war. Kennt dieser Rechner den Code nicht, so weiss er nur, dass der Absender aus irgendeinem Grund unerreichbar war. Wenn auch noch der Typ unbekannt, ist somit die Nachricht nutzlos. F¨ ur die folgenden Anwendungen wurde das Netzbeispiel 5 in der Abbildung 6 benutzt mit dazu geh¨origer XML-Datei:

3.1

Echo Request - Echo Reply

Die bekannteste Dienst, die auf ICMP basiert ist, ist ’ping’. Ping dient zum Versenden von Diagnose-Nachrichten. Es l¨ost ein Echo Request aus, die zum anderen Rechner geleitet wird. Dieser muss auf der Anfrage mit einem Echo Reply antworten. Sobald die Antwort beim ersten Rechner ankommt, erh¨alt der Benutzer eine entsprechende Ausgabe, die unten illustriert ist. Mit dieser ICMP-Nachricht kann eine Netzwerkverbindung getestet werden. Man kann zu jeder IP-Adresse eine Echo-Nachricht senden und der Empf¨anger muss den Inhalt dieser Nachricht dann in seiner Echo-reply-Nachricht zur¨ uckschicken. Dadurch wird festgestellt, ob ein bestimmter Rechner oder VM (genauer eine bestimmte IP-Adresse) erreichbar ist oder nicht. Auf Benutzerebene nutzt das Programm ping genau diesen ICMP-Dienst. Das ICMPTypfeld hat bei diesen Nachrichten den Wert 8 f¨ ur echo-Anforderungen und 0 f¨ ur echo-Antwort-Nachrichten. Host1 schickt eine Anfrage an Host2, der wiederum eine Antwort zuruckschickt. host1:∼# ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data. 64 bytes from 10.0.2.1: icmp seq=1 ttl=63 time=1.77 ms 64 bytes from 10.0.2.1: icmp seq=2 ttl=63 time=1.70 ms 64 bytes from 10.0.2.1: icmp seq=3 ttl=63 time=1.70 ms 19

Abbildung 6: Beispielnetz 4 Mit tcpdump k¨onnen auch Nachrichtentypen getestet und gefiltert werden wie folgendes: tcpdump -i [Schnittstelle] icmp[icmptype] [!= | == | =] icmp-[Icmp Typ]. Beispiele: icmp[icmptype] != icmp-echoreply icmp[icmptype] == icmp-icmp-echo icmp[icmptype] host1: icmp 64: echo reply seq 8 20

09:23:25.823965 IP 10.0.2.1 > host1: icmp 64: echo reply seq 9 : Oder nach Echo Request filtern. host1:∼# tcpdump -i eth1 icmp[icmptype] != icmp-echoreply : 09:25:30 IP host1 > 10.0.2.1: icmp 64: echo request seq 1 09:25:31 IP host1 > 10.0.2.1: icmp 64: echo request seq 2 :

3.2

Destination Unreachable

Eine Destination-Unreachable-Nachricht wird verschickt, wenn ein Paket nicht zustellbar ist, weil der Empf¨anger nicht erreichbar ist. Diese kann durch verschiedene Ursachen sein z.B. dass der Empf¨anger gar nicht existiert, kein passendes Protokoll geladen ist oder einfach das Routing nicht vollst¨andig war. Ein Ziel kann z.B. ein anderes Netz, Host, Port oder Protokoll sein. Wenn ein Netz (Typ=3 und Code=0) nicht erreichbar ist, folgt die Angabe von !N die RTT-Ausgabe. In unserem Beispiel existiert das Netz 10.0.4.0 nicht, und wird entsprechend als unerreichbar gemeldet. host1:∼# traceroute 10.0.4.1 traceroute to 10.0.4.1 (10.0.4.1), 30 hops max, 38 byte packets 1 10.0.0.2 (10.0.0.2) 49.681 ms 5.262 ms 1.940 ms 2 10.0.1.2 (10.0.1.2) 3.036 ms !N 4.168 ms !N 3.772 ms !N : Wenn ein Host (Typ=3 und Code=1) nicht erreichbar ist, folgt die Angabe von !H die RTT-Ausgabe. Im Beispeil ist weder ein Host noch ein Router mit der Adresse 10.0.0.3 vorhanden. host1:∼# traceroute 10.0.0.3 traceroute to 10.0.0.3 (10.0.0.3), 30 hops max, 38 byte packets 1 host1 (10.0.0.1) 3025.969 ms !H 2968.461 ms !H 3003.922 ms !H : Destination-Unreachable kann auch durch Abschaltung eines Hosts oder Routers provoziert werden. Host1 m¨ochte zum Beispiel mit Host2 kommunizieren. Dies passiert mithilfe von den beiden Router. Eine der Schnittstellen von Router2 kann man mit router2:∼# ifconfig [eth1 | eth2] down abschalten. Der Ping-Befehl (oder auch traceroute) wird dann diese Nachricht zur¨ uckgeben. 21

3.3

Time Exceeded

Wenn eine Nachricht sich so lange im Netz befunden hat, dass ’Time-ToLive’ (TTL) abgelaufen ist, dann wird eine Time-Exceeded-Nachricht verschickt. Das bedeutet, wenn das Time-to-Live-Feld in einem IP-Datagramm Null ist. Dabei hat das ICMP-Typ-Feld den Wert 11 und das Codefeld die Werte 0 oder 1. Null bedeutet Time-to-Live abgelaufen, eins bedeutet, dass die Reassemblierungszeit abgelaufen ist. Um diese Nachricht zu demonstrieren, wird versucht Kontakt mit einem (nicht-existierenden) Host 10.0.2.3 aufzunehmen. Beide Router werden gefragt ob dieser Host ihr bekannt ist. Traceroute-Ausgabe sieht folgendermaßen aus: host1:∼# traceroute 10.0.2.3 traceroute to 10.0.2.3 (10.0.2.3), 30 hops max, 38 byte packets 1 10.0.0.2 (10.0.0.2) 23.467 ms 2.139 ms 0.534 ms 2 10.0.1.2 (10.0.1.2) 0.685 ms 1.076 ms 0.590 ms 3 10.0.1.2 (10.0.1.2) 3010.687 ms !H 3012.818 ms !H 3013.455 ms !H.

Entsprechende ungefilterte Tcpdump-Ausgabe: host1:∼# tcpdump -i eth1 ’icmp’ : 18:29:28.115243 IP 10.0.0.2 > host1: 18:29:28.137446 IP 10.0.1.2 > host1: 18:29:28.142426 IP 10.0.1.2 > host1: 18:29:33.088509 IP 10.0.1.2 > host1: 18:29:33.089087 IP 10.0.1.2 > host1: 18:29:38.098084 IP 10.0.1.2 > host1: 18:29:38.098856 IP 10.0.0.2 > host1: 18:29:38.101195 IP 10.0.0.2 > host1: 18:29:38.102016 IP 10.0.1.2 > host1: 18:29:38.104582 IP 10.0.1.2 > host1: :

icmp icmp icmp icmp icmp icmp icmp icmp icmp icmp

46: 75: 75: 75: 75: 75: 46: 46: 46: 75:

time exceeded in-transit net 138.4.2.10 unreachable net 138.4.2.10 unreachable net 138.4.2.10 unreachable net 138.4.2.10 unreachable net 138.4.2.10 unreachable time exceeded in-transit time exceeded in-transit time exceeded in-transit net 138.4.2.10 unreachable

Durch Filterung kann man nur die gew¨ unschte Nachricht auslesen. host1:∼# tcpdump -i eth1 ’icmp[icmptype] == icmp-timxceed’ : 18:50:10.803676 IP 10.0.0.2 > host1: icmp 46: time exceeded in-transit 18:50:20.833712 IP 10.0.0.2 > host1: icmp 46: time exceeded in-transit 18:50:10.804150 IP 10.0.1.2 > host1: icmp 46: time exceeded in-transit : :

3.4

Redirect

Eine Redirect-Nachricht wird verschickt, wenn ein Router bemerkt, dass es einen besseren Weg gibt als u ¨ber den in der Routing-Tabelle. Er schickt also eine Empfehlung zur Nachrichtenquelle, das sie weitere Nachrichten zum 22

gleichen Ziel, u ¨ber den angegebenen Gateway-Adresse zu routen. Im Netzbeispiel in der Abbildung(7), host1 versucht host2 anzusprechen u ¨ber router2. Router2 aber kennt einen besseren Weg u ¨ber router1 nach host2 und teilt host1 dies mit. Danach l¨auft alle Nachrichten von host1 nach host2 u ¨ber router1. host1:∼# ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data. >From 10.0.1.3: icmp seq=1 Redirect Host(New nexthop: 10.0.1.2) 64 bytes from 10.0.2.1: icmp seq=1 ttl=63 time=49.6 ms >From 10.0.1.3: icmp seq=2 Redirect Host(New nexthop: 10.0.1.2) 64 bytes from 10.0.2.1: icmp seq=2 ttl=63 time=3.61 ms 64 bytes from 10.0.2.1: icmp seq=3 ttl=63 time=1.80 ms 64 bytes from 10.0.2.1: icmp seq=4 ttl=63 time=1.68 ms 64 bytes from 10.0.2.1: icmp seq=5 ttl=63 time=1.81 ms : : Entsprechende Tcpdump-Ausgabe: host1:∼# tcpdump -i eth1 ’icmp’ : 19:43:31.530198 IP host1 > 10.0.2.1: 19:43:31.626355 IP 10.0.1.3 > host1: 10.0.1.2 19:43:31.626381 IP 10.0.1.3 > host1: 19:43:31.676186 IP 10.0.2.1 > host1: 19:43:32.535229 IP host1 > 10.0.2.1: 19:43:32.535565 IP 10.0.1.3 > host1: 10.0.1.2 19:43:32.537288 IP 10.0.2.1 > host1: 19:43:33.550059 IP host1 > 10.0.2.1: 19:43:33.550572 IP 10.0.2.1 > host1: : :

icmp 64: echo request seq 1 icmp 92: redirect 10.0.2.1 to host icmp icmp icmp icmp

75: 64: 64: 92:

net 138.4.2.10 unreachable echo reply seq 1 echo request seq 2 redirect 10.0.2.1 to host

icmp 64: echo reply seq 2 icmp 64: echo request seq 3 icmp 64: echo reply seq 3

Die folgende 5 Nachrichtentypen wurden im Rahmen des Projektpraktikums nicht getestet. Sie werden trotzdem zur Vollst¨andigkeit kurz erw¨ahnt. Einige sind veraltet zum Beispiel Source Quench und Information Request/Reply und werden in der gegenw¨artigen Programentwiklung nicht immer ber¨ ucksichtigt. Die Timestamp Request - und Timestamp Reply-Nachrichten erm¨oglichen die Zeitsynchronisation zweier Rechner. Dadurch k¨onnen Versp¨atungen im 23

Abbildung 7: Redirect-Nachricht Beispielnetz 5 Datenverkehr erkannt werden. Timestamp Reply erm¨oglicht die Messung der Zeit, die ein Datagramm ben¨otigt. Der Sender des Timestamp Requests erh¨alt vom Empf¨anger ein Reply, in welchem Sendezeit und Empfangszeit sowie die Sendezeit des Timestamp Replys enthalten sind.

3.5

Source Quench

Hat ein Rechner Probleme, die ankommenden Pakete rechtzeitig zu verar¨ beiten (Uberlastung durch Sender oder Urpsrungshost), so sendet er eine Source Quench-Nachricht. Diese veranlaßt den Sender, die Rate seiner Pake¨ te zu vermindern. Der Sender kann danach die Ubertragungsrate erh¨ohen bis er wieder diese Nachricht empf¨angt. Der Sender (host oder Gateway) kann Source Quench schicken bereits vor das Erreichen des Limits, damit keine Nachricht verworfen werden muss.

24

3.6

Parameter Problem

Es ist ein Problem beim Auswerten der Nachricht aufgetreten, das auf fehlerhafte oder unbekannte Parameter im IP-Header zur¨ uckzuf¨ uhren ist. Die Ursache f¨ ur diesen Fehler k¨onnte ein falsch gesetztes Argument in den IPOptionen sein.

3.7

Information Request-Reply

Dieser Nachrichtentyp erm¨oglicht es einem Host, seine Netz-Adresse zu erfahren. Information Request(Informationsmeldung-Anforderung) mit der Zieladresse 0.0.0.0 wird gesendet, was dem eigenen Netzwerk entspricht. Ein beliebiger Rechner, der die Anforderung empf¨angt, sendet nun eine Antwort (Information Reply) mit der richtigen Netzwerkandresse als Sendeadresse. Dieses Verfahren wird als veraltet betrachtet und sollte nicht mehr verwendet werden.

3.8

Address Mask Request-Reply

Die Adressfeld-Format Nachrichten dienen dazu, die Subnetzmaske eines Netzwerkes herauszufinden. Ein Rechner sendet dazu eine Address Mask Request(Adressfeld-Format Anforderung) an den Router, und bekommt von diesem eine Antwort (Address Mask Reply), in der der Router dem Rechner im Feld ”Adress Mask” die Subnetzmaske mitteilt.

4

Ethereal

Ethereal ist eine Software zur Analyse von Netzwerkprotokollen. Sie wurde unter der General Public License als Open-Source-Software entwickelt. Das Werkzeug stellt nach dem Protokollieren des Datenverkehrs einer Netzwerkschnittstelle (zum Beispiel Ethernet-Netzwerkkarte) die Daten in Form einzelner Pakete dar. Dabei werden die hexadezimal codierten Daten u ¨bersichtlich und f¨ ur den Menschen nachvollziehbar analysiert. So k¨onnen zum Beispiel auch ICMP-Nachrichten analysiert werden. Ethereal ist f¨ ur fast alle g¨angige Betriebsysteme frei verf¨ ugbar. Allerdings ist auf (Suse) Linux einiges zu beachten, wie die Erkl¨arungen unten darstellen. Wer als Root auf seinem User-Desktop eine grafische Anwendung (dazu geh¨ort Ethereal) starten m¨ochte, k¨onnte statt einem neuen Fenster lediglich einen Hinweis der folgenden Art erhalten. (’nitrogen’ w¨are Name des Rechners):

25

Error: Can’t open display: :0.0. Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server oder: nitrogen:/home/projekt/IcmpGroup # ethereal Xlib: connection to ":0.0" refused by server Xlib: No protocol specified (ethereal:5965): Gtk-WARNING **: cannot open display: Diese Fehlermeldung wird von der Zugriffskontrolle des X-Window Systems ausgel¨ost. Die Kontrolle gestattet nur den Usern das Darstellen von Fenstern, die vom Eigent¨ umer des Desktops hierzu autorisiert worden sind. Autorisation kann durch das Tool xhost erfolgen: So gibt ein xhost +localhost (vom Eigner des X-Servers getippt) den X-Server frei. Es gilt jedoch f¨ ur die Verwendung von xhost: Der X-Server wird allgemein f¨ ur alle ge¨offnet, und nicht nur f¨ ur den gew¨ unschten User. Ist der X-Server offen, sollte man alleine am Rechner sitzen, unvernetzt sein, und nicht ins Internet gehen. Diese Sicherheitsgefahr wird nur dann gebannt, wenn man explizit den X-Server wieder sperrt. Dies erfolgt durch xhost -localhost oder Neustart des X-Window Systems erledigt. Um unproblematisch gezielt die Benutzung des X-Window freizugeben kann man das Tool xauth einsetzen. Dieses gestattet einem einzigen User den Zugriff auf den X-Server, der auch jederzeit wieder ausgesperrt werden kann. Der Einsatz erfolgt in der Art: Der Besitzer eines Desktops erh¨alt mit diesem die Datei ∼/.Xauthority; Diese beinhaltet einen oder mehrere ”Schl¨ ussel”, mittels derer der X-Server kontak¨ tiert werden kann. Ubergibt dieser User nun einen dieser Schl¨ ussel an einen anderen User, so kann dieser sie seiner ∼/.Xauthority hinzuf¨ ugen, und somit ebenfalls auf den X-Server zugreifen. Zwei Beispiele, um Rechte zu vergeben: (als ’user’ am Rechner ’nitrogen’). 1. projekt@nitrogen:∼> xauth extract schluessel $DISPLAY projekt@nitrogen:∼> su Password: nitrogen:∼# xauth merge /home/jo/schluessel xauth: creating new authority file /root/.Xauthority xauth: (argv):1: merge: unable to open file /home/jo/schluessel nitrogen:∼# xauth merge /home/projekt/schluessel xauth: creating new authority file /root/.Xauthority 26

nitrogen:∼# DISPLAY=:0.0; export DISPLAY nitrogen:∼# ethereal Starting ethereal... 2. Noch einfacher ist es beim Fremdzugriff als ’root’: Dieser kann einfach die ∼/.Xauthority des betreffenden Users u ¨ber die Variable $XAUTHORITY mitverwenden. Daf¨ ur reicht ein einziger Befehl: nitrogen:∼# XAUTHORITY=/home/user/.Xauthority; export XAUTHORITY Diese regelt die komplette Zugriffskontrolle, ist gleichzeitig weniger umst¨andlich. Angenommen Ethereal l¨auft endlich. Zuerst muss die zu beobachtender Schnittstelle eingestellt werden. Die Abbildung 8 unten zeigt diesen Vorgang. Dabei

Abbildung 8: Ethereal Schnittstellen-Einstellung erscheint eine Liste aller verf¨ ugbaren Schnittstellen in der Abbildung 9. Daraus kann man dan die gew¨ unschte w¨ahlen und vorbereiten (Art der Beobachtung, Zeitintervalle, u.s.w.).

27

Abbildung 9: Liste der verf¨ ugbaren Schnittstellen Die Abbildung 10 stellt das Abfangen der Nachrichten in einer Schnittstelle. Wie oben erw¨ahnt, Ethereal zeichnet alle m¨ogliche Protokollarten, die ¨ zur Ubersichtlichkeit gefiltert werden m¨ ussen. In diesem Fall wurden nur die ¨ ICMP Echo Request/Reply ausgeben. Ahnlich wie Tcpdump werden die Sendezeit, Quell- und Destinationsadressen sowie Protokoll ausgegeben. Ferner hat man die M¨oglichkeit noch detaillierte Informationen u ¨ber die u ¨bertragene Pakete zu erfahren. Dazu geh¨oren zum Beispiel die Gr¨osse der Rahmen die MAC-Adressen. Durch ’Live-Update’ Einstellung k¨onnen die Nachrichten auch in ’Echtzeit’ herausgelesen werden (Je nach eingestellte Zeitintervalle).

Dar¨ uber hinaus k¨onnen auch graphische Beobachtungen durchgef¨ uhrt werden. Statt alpha-numerische Daten k¨onnen mehrfarbige Graphen generiert werden. Sie werden auch je nach Zeitintervall durchgehend ausgegeben.

28

Abbildung 10: Ethereal Snapshot

5

Schlusswort

5.1

ICMP Nachteile

ICMP Protokoll hat jedoch einige Schwachpunkte, die mißbraucht werden k¨onnen. Ein Angriff kann z.B. durch das Versenden von k¨ unstlich falsche Fehlermeldungen. • Denial-of-Service Angriff Durch st¨andigen Empfang von ICMP-Nachrichten Time-Exceeded, Redirect und Destination Unreachable kann es zum Dienstausfall auf der angegriffenen Maschine kommen.

29

• Ping-to-Death Dieser Angriff f¨ uhrt ebenfalls zu Denial-of-Service. Ein Angreifer sendet ICMP-Pakete mit riesiger Nutzdategr¨oße. Dieser werden fragmentiert zum Zielsystem u ¨bertragen und dort wieder zusammengesetzt. Durch Inklusion des Ping-Headers u ¨berschreitet das IP-Paket die maximal ¨ zul¨assige Gr¨oße. Bei IP-Implementierungen, die solchen Uberlauf nicht abfangen k¨onnen, kommt es zum Systemabsturz. • Redirect Mit ICMP-Redirect-Meldungen kann ein Angreifer Zutritt zum System erlangen. Durch Versenden von Redirect-Meldungen kann ein Angreifer den gesamten Datenverkehr eines Netzes u ¨ber seinen Rechner laufen lassen. • ICMP-Dienste Echo - Echo Reply Durch die ICMP-Dienste Echo und Echo Reply kann sich ein Angreifer n¨ utzliche Informationen u ¨ber ein Netzwerk verschaffen (z.b. Anzahl der Maschinen, welche IP-Adressen gibt es). Dieses Wissen kann dann f¨ ur weitere Angriffe verwendet werden.

30

6 6.1

Anhang ICMP Tabelle

Abbildung 11: ICMP Tabelle

31

6.2 6.2.1

XML-Syntax des Beispiel-Szenarios Syntax des Beispielnetzes 1

Dieses Netz wurde bei der Darstellung der einzelnen Tools in Kapitel 1 verwendet. 1.5 beispielnetz /root/.ssh/id rsa.pub 100 /usr/local/share/vnuml/filesystems/root fs tutorial 50M 10.0.0.1 10.0.1.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.0.2 10.0.1.1 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.2 10.0.0.0/24

32

6.2.2

Syntax des Beispielnetzes 2

1.5 beispielnetz2 /root/.ssh/id rsa.pub 100 /usr/local/share/vnuml/filesystems/root fs tutorial 50M 10.0.1.1 default /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.2 10.0.2.2 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.3 10.0.2.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.2

33

default

6.2.3

Syntax des Beispielnetzes 3

1.5 beispielnetz3 /root/.ssh/id rsa.pub 100 /usr/local/share/vnuml/filesystems/root fs tutorial 50M 10.0.0.1 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.0.2 10.0.1.1 10.0.2.0/24 10.0.3.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.2 10.0.2.1 10.0.3.2 10.0.0.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.2.2 10.0.3.1 10.0.4.1 10.0.1.0/24 10.0.3.0/24 10.0.0.0/24 10.0.4.2 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24

6.2.4

Syntax des Beispielnetzes 4

1.5

35

beispiel2 /root/.ssh/id rsa.pub 100 /usr/local/share/vnuml/filesystems/root fs tutorial 50M 10.0.0.1 default /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.0.2 10.0.1.1 default /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.1.2 10.0.2.2 10.0.3.2 10.0.0.0/24 /usr/local/share/vnuml/filesystems/root fs tutorial 10.0.2.1 default

36