Die Fehlersuche in IP-Netzwerken fällt nicht leicht, denn einem Netzwerkschluckauf können viele Ursachen zugrunde liegen. Profi-Admins kennen aber Wege, um das klassische und meist aufwendige Troubleshooting abzukürzen. Beispielsweise kann man Fehlerquellen anhand von ICMP-Rückmeldungen der Netzwerkgeräte eingrenzen, die an einem fehlgeschlagenen IP-Dialog beteiligt sind. Welche Meldungen das sind und wie man sie interpretiert, haben wir hier ausführlich beschrieben.

Am Ende dieses Beitrags haben wir vier Netzwerkanalyse-Aufgaben gestellt. Die Grundlage dafür bildet ein Verkehrsmitschnitt, den man mit dem Analysetool Wireshark öffnet und mit einem Display-Filter siebt. Hier folgen die Antworten zu den Aufgaben.

Fall 1

Display-Filter 1, udp.stream in {1177,1178}: Hier liefert dieselbe DNS-Anfrage (DNS-Query) anscheinend verschiedene Fehler. Was könnte der Grund dafür sein?

–> In beiden Fällen schickt ein Host eine DNS-Anfrage an den Server mit der IP-Adresse 85.215.94.29. Im ersten Fall antwortet der Server mit einem ICMP-Paket des Typs 3 (Destination Unreachable) und dem Code 3 (Port Unreachable). Das bedeutet: Der Zielport 53 ist auf dem betreffenden Server geschlossen. Fehlergrund: Entweder läuft der DNS-Dienst aktuell nicht oder der unter dieser IP-Adresse erreichbare Server war nie als DNS-Server gedacht – der Client wandte sich an die falsche Adresse.

Im zweiten Fall stammt das ICMP-Paket von einer bis dato unbekannten Quelladresse 192.168.110.33 und der Absender des ICMP-Pakets hat im Datenabschnitt Code 13 notiert: Communication administratively filtered. Das bedeutet: Auf dem Weg vom Client zum Server steht eine Firewall quer, die den Verkehr für den UDP-Port 53 unterbindet. Praktischerweise verwirft sie das DNS-Paket nicht stillschweigend, sondern meldet dem Client den Fehlergrund.

Fall 2

Display-Filter 2, udp.stream in {249,251}: Vergleichen Sie die Fehler. Was sind die Unterschiede? Was sticht beim zweiten Fall hervor?

–> Beide Fälle eint, dass eine NTP-Anfrage an einen NTP-Server ging, der brav mit einer Zeitangabe gemäß dem NTP-Protokoll antwortete. Warum aber bekam der Server daraufhin eine Fehlermeldung zurück, obwohl der Client den Server unmittelbar zuvor reibungslos ansprechen konnte?

Im ersten Fall enthält das ICMP-Paket den Fehlercode 0: No route to destination. Das bedeutet: Irgendein Router entlang des Pfads hatte keinen Routingeintrag für das Zielnetz 2804:214:8475:3403::/64. Da dieser Netzbereich laut der Datenbank „IPv6 Global Unicast Address Assignments“ der regionalen Internet Registry LACNIC zugeteilt ist, kann er regulär in Betrieb sein. In dem Fall liegt womöglich ein temporäres Problem beim Betreiber dieses Netzbereichs vor. Möglicherweise ist der BGP-Router ausgefallen, dem dieses Teilnetz zugeordnet worden ist. Aber man kann auch nicht gänzlich ausschließen, dass ein Angreifer den NTP-Server attackieren wollte und dafür seine Absenderadresse gefälscht hat.

Das andere ICMP-Paket meldet Fehler-Code 6: Reject route to destination. Dies ist eine Sonderform des Codes 1, bei dem zwar ebenfalls eine Firewall ein Paket verwirft, jedoch nicht aufgrund eines Filters, sondern wegen einer nicht routebaren Zieladresse. Was fällt nämlich bei der Quelladresse des Clients, also der Zieladresse des Antwortpakets, auf? Sie startet mit „fd“ und gehört somit zu den IPv6 Unique Local Addresses (ULA). Das ist ein IPv6-Adressbereich, der per Definition nicht im Internet geroutet wird, siehe RFC-Spezifikation 4193. Hier liegt entweder eine Wissenslücke des Netzwerkbetreibers vor, in dessen Netz der NTP-Client läuft, oder ein Versehen. Die IPv6-Funktion des Routers, der das Paket verworfen hat, ist jedenfalls korrekt implementiert.

Falls Sie zu diesem Thema Einzelheiten lesen möchten, suchen Sie im Web nach den Schlagworten „Bogons and Martians“, zu Deutsch in etwa: Unechte und Marsianer.

Fall 3

Display-Filter 3, udp.stream == 1178: Hier wurde auf dem Client, der die NTP-Anfrage stellt, mitgeschnitten. Wie weit entfernt war die Firewall? Tipp: TTL.

–> Hier liegt der Fehlercode 13 vor; erneut hat eine Firewall einen Verbindungsversuch unterbunden. Um zu ermitteln, wie weit sie sich netzwerktechnisch vom Client befindet, liest man den TTL-Wert des ICMP-Pakets aus (Time To Live, maximale Anzahl an Netzwerkstationen auf dem Pfad). TTL ist eine Technik, die verhindern soll, dass ein Paket in gelegentlich vorkommenden Netzwerkschleifen unendlich kreist. Dafür trägt der Absender eines Pakets einen TTL-Startwert von 64 oder 128 ein und jeder Router (Hop), der das Paket weiterreicht, reduziert die TTL um 1. Wenn sie null erreicht hat, wird das Paket verworfen.

Im ICMP-Zusammenhang ist die TTL allgemein nützlich, weil man daran die Anzahl der Hops ablesen kann, die ein Paket bis zur Fehlerstelle gereist ist. Und beim hier betrachteten Fehlerfall kann der Admin gleich einordnen, ob die Firewall im eigenen Zuständigkeitsbereich steht oder außerhalb.

Mit dem obigen Display-Filter bleiben zwei TTLs im Kescher, je ein Wert im ICMP-Päckchen und im mitgeschickten Päckchen, das die Firewall abgelehnt hat. Bei beiden handelt es sich um den Startwert. Daraus folgt: Da der Startwert unverändert ist, hat bereits der erste Hop das ursprüngliche Paket zurückgewiesen. Damit liegt die Firewall nur einen Hop entfernt, steht also vermutlich im Netzwerk des Admins, der nun dort nach dem Rechten sehen kann.

tshark Challenge

tshark-Aufgabe: Analysieren Sie mit tshark alle ICMP-Pakete mit der Meldung „Destination Unreachable“ vom Typ „Port Unreachable“, die an die IP-Adresse 194.247.5.12 geschickt worden sind. Setzen Sie Linux-Bordmittel ein, um doppelte Einträge automatisch zu entfernen. Von welchen Quell-IPv4-Adressen stammen die Fehlermeldungen?

–> Bevor Sie mit tshark die Statistik erzeugen, empfiehlt es sich, den zugehörigen Display-Filter in Wireshark zu bauen. Den nehmen Sie dann als Muster für tshark.

Um nach der Meldung „Destination Unreachable“ vom Typ „Port Unreachable“ zu suchen, die an eine bestimmte Zieladresse geschickt worden ist, konstruiert man den Display-Filter wie folgt: icmp.type eq 3 and icmp.code eq 3 and ip.dst eq 194.247.5.12.

Mit diesem Filter im Sinn bauen Sie den tshark-Befehl: Die Quelldatei, hier die PCAP-Datei, gibt man mit der Option -r an. Den Filter übergibt man mit der Option -Y. Setzen Sie dafür den soeben für Wireshark erzeugten Display-Filter ein. In der Ausgabe soll nur die Quell-IP-Adresse der jeweiligen ICMP-Meldung erscheinen. Das stellt man normalerweise mit den Optionen -T fields -e ip.src ein. Pro ICMP-Paket gibt es aber zwei Adressen, von denen Sie nur die erste brauchen. Das berücksichtigen Sie mit der Option -E occurrence=first. Um auf Linux die Ausgabe zu sortieren und doppelte Einträge zu entfernen, können Sie beispielsweise die Befehle sort und uniq mit einer Pipe verketten: | sort | uniq.

Hier folgt die gesamte Befehlskette und darunter die fünf Quell-IP-Adressen, von denen die Meldungen stammen:

Nun aber genug der Demos. Die nächste Challenge wartet in Ihrem eigenen Netzwerk. Wetten, dass? Schneiden Sie ein paar Stunden den Netzwerkverkehr an einem zentralen Punkt mit und gehen Sie den ICMP-Fehlermeldungen auf den Grund. Die Nutzer werden es Ihnen danken.

Soli Deo Gloria!

Photo by Olav Ahrens Røtne on Unsplash.