Netzwerkprotokolle: Nachschlagewerk für Wireshark

Wenn es im Netzwerk knirscht, versuchen Admins den Fehler in Analyse-Tools wie Wireshark anhand von Paketmitschnitten einzukreisen. Jedoch hat der Herr viel mehr Netzwerkprotokolle gegeben, als sich ein Admin-­Hirn in allen Details merken kann. Eine Referenzdatei, die zahlreiche korrekte Protokoll­abläufe enthält, gibt Orientierung.

Wer den Netzwerkverkehr auf Kommunikationsfehler abklopfen muss, braucht bei der Analyse von Paketmitschnitten (Traces) reichlich Geduld. Abgelaufene Zertifikate, Inkompatibilitäten aufgrund verschiedener Versionen, fehlerhafte Implementierungen, abgelaufene Timer – der Fehler steckt oft im Detail.

Natürlich kann man einen Trace im Analysewerkzeug Wireshark öffnen und die Aufzeichnung Paket für Paket und Feld für Feld mit den Spezifikationen vergleichen. Ein Fehler springt aber eher ins Auge, wenn man einen funktionierenden Protokollablauf zum Vergleich heranzieht.

Manche Netzwerk-Admins sammeln daher Traces funktionierender Übertragungen, um sie später als Referenz zu verwenden. Auch der Autor dieses Beitrags hat wichtige Traces über Jahre hinweg gesammelt. Anstatt aber vor jeder Analyse die zugehörige Referenzdatei im händisch angelegten Archiv zu suchen, hat er die wichtigen Mitschnitte in ein einziges PCAP-­File gesteckt. Das kann man wie üblich mit einem Doppelklick in Wireshark öffnen und dann die mächtige Filtermaschine des Programms nutzen, um einen gesuchten Protokollablauf darzustellen.

In diesem Beitrag geht es um eine rund 9 MByte große Referenzdatei. Sie enthält aktuell über 60 Traces von Protokollen, die auf das Übertragungsmedium Ethernet aufsetzen; Sie finden sie über ct.de/yjkz.

Die meisten Beispiele sind sowohl für das moderne IPv6 als auch für das veraltete IPv4 ausgeführt. Unter anderem befinden sich in der Referenzdatei sowohl Abläufe grundlegender Protokolle wie DNS, HTTP oder ICMP als auch von Exoten wie Ciscos Unidirectional Link Detection (UDLD) oder vom langsam aussterbenden WHOIS. Die komplette Liste haben wir in einer ­Tabelle aufgeführt, die ebenfalls unter ct.de/yjkz zum Download bereitsteht.

In Wireshark kann man mit flexiblen Display-Filtern allen Verkehr ausblenden, der gerade nicht interessiert, und so ausschließlich die zu analysierende Kommunikation verfolgen. Bei vielen Protokollen hat man die Wahl zwischen zwei Filterarten: Setzt man zum Beispiel http oder dns ins Feld „Display-Filter“ ein, dann zeigt Wireshark nur die Pakete, die zum jeweiligen Applikationsprotokoll gehören.

Wenn man stattdessen auf den Zielport filtert, zeigt Wireshark zusätzlich den Transport Layer Overhead, der beim Verbindungsaufbau abläuft, inklusive Acknowledgements und etwaiger Retransmissions. Um also eine komplette Websession zu betrachten, gibt man tcp.port eq 80 ein.

Überblick

Die Kommunikation von Hosts mit dem Domain Name System (DNS) gehört zu den grundlegenden Anwendungen. Praktisch jedes internetfähige Programm benötigt zur Verbindungsaufnahme die Auflösung von Domainnamen zu A- oder AAAA-­Records mit ihren IP-Adressen, sodass solche Pakete in fast jedem Trace zu finden sind. Der Großteil der weltweiten DNS-Anfragen an die DNS-Resolver läuft unverschlüsselt ab, was auch die Referenzdatei widerspiegelt; verschlüsselnde Protokolle wie DNS-over-HTTPS und DNS-over-TLS fassen aber langsam Fuß und werden daher in einem kommenden Update der Referenzdatei berücksichtigt.

Um den DNS-Verkehr isoliert zu betrachten, gibt man im Display-Filter dns ein. Mit dem Filter tcp.port eq 53 or udp.port eq 53 sehen Sie die gesamte Kommunikation zur Namensauflösung, also auch etwaigen TCP-Overhead.

DNS-Probleme können vielfältig sein. Daher sind in der Referenzdatei allerlei DNS-Beispiele aufgeführt, angefangen von Paketen, die seltene Resource Records (RR) enthalten, bis hin zu kompletten Zone Transfers.

Außerdem finden Sie darin Besonderheiten wie Hostnamen, die Sonderzeichen enthalten (internationalized domain names, IDN), und Anfragen zu A- oder AAAA-Records mit bis zu 64 IPv4- oder IPv6-Adressen pro Host. Nicht zu vergessen DNSKEYs und RRSIGs der kryptografischen DNS-Absicherung DNSSEC sowie die zugehörigen Flags in den Antworten. Für Domain-Admins interessant: Dynamische DNS-Updates (nicht zu verwechseln mit DynDNS eines Heimrouters).

Bei genauem Hinsehen fallen neben klassischen UDP-Paketen auch IP-Fragmente sowie TCP-Sessions auf. Diese treten immer dann auf, wenn eine DNS-Antwort nicht mehr in ein UDP-Paket passt. Herkömmliche DNS-Antworten dürfen nicht länger als 512 Bytes sein, um mittels UDP übertragen werden zu können. Mit der Erweiterung EDNS(0) signalisiert ein Server, dass er mehr Nutzdaten verschickt (> 512 <= 1232 Bytes). Sollte die EDNS(0)-­Übertragung scheitern oder die Ober­grenze überschreiten, kann der Client den Server über das aufwendigere und langsamere TCP befragen.

Was wäre das Internet ohne HTTP? Klar, dass das Trace-File auch ein paar HTTP-Sessions enthält. Kleiner Wire­shark-­Tipp: Klicken Sie mit der rechten Maustaste auf ein HTTP-Paket und dann im Kontextmenü auf „Follow/HTTP ­Stream“. Daraufhin öffnet sich ein Fenster, das nur den Inhalt des HTTP-Headers und des Bodys anzeigt; etwaige komprimierte Inhalte werden automatisch dekomprimiert.

Wer HTTP-Verkehr im Unternehmensumfeld analysiert, muss mit Proxys rechnen. Eine häufige Frage ist daher: Wie kann man, abgesehen von der IP-Adresse des Proxys, auf reinen HTTP- oder Proxy-vermittelten Verkehr rückschließen? Ein Beispiel dafür liefert der Host mit der IP-Adresse 192.168.110.10 (Display-­Filter ip.addr == 192.168.110.10). Dieser hat eine Webseite sowohl direkt als auch per Proxy aufgerufen. Wenn er nur GET / sendet, kommuniziert er mit dem Webserver direkt. Schickt er hingegen GET http://<hostname>/, nutzt er den Proxy.

Doch der Webverkehr hat sich schon seit einiger Zeit überwiegend zu TLS-­verschlüsseltem HTTP verlagert, also HTTPS. Im Trace sind mehrere TLS-1.2- und -1.3-Sessions zu sehen.

Dabei ist zwar der Großteil der Kommunikation verschlüsselt, aber immerhin kann man leicht erkennen, welche Hostnamen ein Client aufruft (Server Name Indication, SNI). Mit dem Filter tls.handshake.extensions_server_name lassen sich alle Pakete isolieren, die ein SNI-Feld enthalten (siehe Screenshot oben). Sie möchten wissen, welche Server-Zertifikate im Trace stecken? Setzen Sie im Display-Filter tls.handshake.type == 11 ein.

Die Referenzdatei eignet sich auch zum Testen von Display-Filtern (1). Im obigen Screenshot sind gleich mehrere Beispiele für den Einsatz von logischen Operatoren wie and und or sowie Klammern mit mehreren Werten aufgeführt in { x y z }. Sie lassen sich auch in selbsterstellten Spalten, den „Custom Columns“ verwenden.

Die Spalte unter (2) wird per dns.qry.name or http.host or tls.handshake.extensions_­server_name erzeugt. So führt eine einzige Spalte die DNS-Pakete der angefragten Namen auf, dazu den per HTTP-Session angesprochenen Host und bei HTTPS-Verbindungen auch die Server Name Extension – sehr praktisch für einen schnellen Überblick über das Surfverhalten.

Zum Schluss sei unter den grundlegenden Protokollen das Internet Control Message Protocol (ICMP) genannt, es kommt beim täglich millionenfach genutzten Ping zum Einsatz. Damit versendet man Pakete vom Typ “echo-request” und erhält vom angepingten Host Antworten vom Typ “echo-reply”. Übliche Ping-Befehle zeigen nicht wirklich Überraschendes, aber durchaus der Traceroute-Befehl, der ICMP in Kombination mit inkrementierten Hop-Limits verwendet (bei IPv4 „TTL“), um Routern auf der Strecke zu einem Ziel Lebenszeichen zu entlocken.

Während der Windows-Befehl tracert die engen ICMP-Rahmenbedingungen weitgehend umsetzt, lassen sich mit den traceroute-Implementierungen von Unix-Betriebssystemen sogar beliebige TCP- oder UDP-Ports ansprechen und auch Netzwerkpfade hinter Firewalls identifizieren. In der Referenzdatei steckt ein solches Beispiel für den SMTP-Port TCP-25. Finden Sie es? Tipp: Die betreffende Traceroute-Session lief auf IPv6.

Routing-Protokolle

Das Rückgrat großer Netzwerke und des Internets bilden Routing-Protokolle, mit denen sich Backbone-Router gegenseitig ins Bild setzen, über welche Strecken sie bestimmte andere Netzwerke erreichen. In internen Netzen sind das Routing Information Protocol (RIP) beziehungsweise das Routing Information Protocol next generation für IPv6 (RIPng) gebräuchlich. Damit meldet jeder Router alle ihm bekannten Netzwerke periodisch an eine Multicast-Adresse und teilt sie so allen anderen Routern im privaten Netz mit.

Für komplexere Netze hat sich Open Shortest Path First (OSPF) durchgesetzt. Alle beteiligten Router senden periodisch ein Hello-Paket; Informationen über Router und angeschlossene Layer-3-Netze fließen nur bei Änderungen. Mit seinen zig verschiedenen Link State Advertisements (LSA) zählt das Protokoll zu den komplexen. Wie gut, dass Sie im PCAP diverse solcher LSA-Typen finden und erforschen können.

Internet-Router kommunizieren miteinander über das Border Gateway Protocol (BGP), das den TCP-Port 179 nutzt und manuell zwischen zwei Routern eingerichtet wird (BGP-Nachbarschaft, engl. Neigh­bors). Anschließend können sie Informationen über erreichbare IPv4- und IPv6-­Netze austauschen. Ob eine BGP-Session über IPv4 oder IPv6 aufgebaut wurde, spielt keine Rolle.

Zur gegenseitigen Authentifizierung haben sich einfache BGP-Passwörter in Form von Pre-Shared Keys etabliert; damit wird eine MD5-Prüfsumme über jedes BGP-Päckchen gebildet. Wer diese Prüfsumme am Ende des BGP-Pakets vermutet, wird jedoch nicht fündig, denn sie wird als TCP-Option übertragen und steckt daher vorn im TCP-Header.

Um in der Referenzdatei ausschließlich BGP-Nachrichten darzustellen, genügt es, bgp als Display-Filter zu verwenden. Möchten Sie den kompletten TCP-­Overhead sehen, verwenden Sie tcp.port eq 179.

IPv6-Crashkurs

Der Internet-Verkehr wird verschiedenen Statistiken zufolge mittlerweile zu mehr als 30 Prozent über IPv6 abgewickelt, für Deutschland meldete Google Ende Oktober 2020 schon 50 Prozent IPv6-Anteil (siehe ct.de/yjkz). In Firmenumgebungen ist der Anteil weit geringer, denn viele Unternehmen betreiben ihre Infrastruktur noch weitgehend nur mit IPv4. Moderne Betriebssysteme nutzen IPv6 aber zumindest im LAN (Layer 2, Link-lokal), sodass IPv6-­Pakete auch in vermeintlich reinen IPv4-­Umge­bungen übertragen werden. Manch ein Admin argwöhnt dann ein Fehlverhalten im Netz.

Die Referenzdatei kann auch hier Licht ins Dunkel bringen. Anwendungsprotokolle wie DNS, HTTPS oder SSH nehmen mit beiden IP-Protokollen vorlieb, bevorzugen aber IPv6. Um sich zu vergewissern, kann man beispielsweise nach ipv6 and http filtern und so etwa haus­interne IPv6-Kommunikation mit Druckern sehen (z. B. AirPrint), die sich Link-lokale IPv6-Adressen per Autokonfiguration erwürfelt haben.

Wer sich eingehend mit IPv6 beschäftigt, wird schnell auf eine Fülle von ICMPv6-Nachrichten stoßen. Diesem Thema widmet sich die Referenzdatei ganz am Anfang: Setzen Sie im Display Filter ipv6 ein. Die daraufhin eingeblendeten Kommunikationsabläufe kann man als kleinen IPv6-Crashkurs nutzen. Es geht los mit Paketnummer 32.

Zunächst ist der Ablauf der automatischen Adressvergabe per Stateless Address Autoconfiguration zu sehen (SLAAC). Ein frisch gebootetes Knoppix-Linux versorgt sich mit zwei IPv6-Adressen: einer Link-lokalen, die mit fe80:: beginnt und nur im lokalen Netz gilt, sowie einer Global Unicast Adresse (GUA), die weltweit gilt und eindeutig ist. Der Linux-Rechner ist über einen Speedport-Router an einem Telekom-Anschluss mit Dual-Stack-Konfiguration angeschlossen, kann darüber also sowohl per IPv4 als auch per IPv6 mit Internet-Hosts kommunizieren. Den Adressbereich (IPv6-Präfix) für seine GUA erhält er über den Router vom Provider, also von der Telekom.

Dabei laufen folgende Schritte ab:

1. Der PC sucht mittels Router Solicitation nach einem Router im LAN (Paket 39). Der Router schickt ein Router Advertisement (Paket 43) mit dem vom Provider zugewiesenen /64-Präfix. Der zugehörige Display-Filter lautet icmpv6.type in { 133 134 }.
2. Der Client erzeugt unter Verwendung seiner MAC-Adresse zwei IPv6-Adressen für sich selbst, die Link-lokale und die globale Adresse, abgeleitet aus dem Präfix. Bevor er sie nutzt, fragt er per Duplicate Address Detection (DAD) im Netzwerk nach, ob sie in Verwendung sind. Technisch gesehen handelt es sich um eine Neighbor Solicitation, gesendet von der Null-­Adresse (unspecified) “::”. Der Display-Filter lautet: icmpv6.type eq 135 && ipv6.src eq ::.
3. Nun fehlt dem Client noch ein DNS-­Server (Resolver) zur Namensauflösung. Solche IP-Adressen kann ein Client wahlweise per Router Advertisement beziehen (z. B. Paket 21190) oder per DHCPv6 (z. B. Pakete 44 und 45). Aber Achtung: Es handelt sich um „stateless DHCPv6“, also nur um die Bekanntmachung des Resolvers, nicht um die Vergabe von IPv6-Adressen.
4. Die Link-Layer Address Resolution ist das IPv6-Gegenstück zum Address Resolution Protocol von IPv4 (ARP): Ein Endgerät möchte zu einer IP-Adresse die zugehörige MAC-Adresse auf der Ethernet-­Schicht herausfinden. In der IPv6-Spezifikation gehört diese Funktion zu ICMPv6 und heißt Neighbor Discovery. Ein anfragender Client hängt die letzten 24 Bit der gesuchten Unicast- oder Anycast-Adresse an das Multicast-IPv6-Präfix ff02::1:ff00:0/104 an und schickt sie als Neighbor Solicitation ab. Die gesuchte Gegenstelle antwortet mit einem Neighbor Advertisement. Filter: icmpv6.type in { 135 136 }.
5. Die Multicast Listener Discovery (MLD) sollte eigentlich das IPv6-Gegenstück zum Internet Group Management Protocol (IGMP) auf IPv4 sein. Filter: icmpv6.type in { 130 131 132 143 }. Es gibt aber kaum Layer-2-Switche, die so etwas wie „MLD-Snooping“ verwenden. Das ist unüblich, weil fehleranfällig. Daher sind MLD-Pakete in der Praxis bedeutungslos und man kann sie ignorieren.

Spätestens jetzt ist klar: ICMPv6-­Pakete können sehr unterschiedliche Funktion haben. Etwas unkomfortabel erscheint daher, dass Wireshark in der Grundkonfiguration alle ICMPv6-Pakete gleich einfärbt (siehe linkes Fenster im Screenshot oben).

Die Wireshark-Färberei kann man aber auch konfigurieren. Das zugehörige Fenster mit diversen manuellen Regeln ist im obigen Screenshot auf der rechten Seite zu finden. In der Mitte des Screenshots sehen Sie das Einfärbeergebnis dieser Regeln: MLD-Pakete sind absichtlich kaum sichtbar (hellgrüne Schrift auf weißem Grund), Duplicate Address Detection ist grün unterlegt, Router Solicitation/Advertisement lila und die Neighbor Discovery türkis. Übliche Pings (Pakete 83 und 86) sind unauffällig pink.

Unverschlüsselt

Früher oder später kann es jeden Netzwerkadmin treffen: das Entsetzen darüber, dass eigene Netzwerkgeräte ungewollt unverschlüsselt kommunizieren. Beispielsweise treiben manche FTP-Clients auf PCs ihr Unwesen. Obwohl Serverbetreiber im Internet, beispielsweise für Webauftritte, die Wartungszugänge längst per TLS abgesichert haben, kommt es bei falschen Client-Einstellungen trotzdem zu Plaintext-Übertragungen – inklusive des Passworts. Autsch.

Wohl dem, der beispielsweise FileZilla einsetzt. Wenn möglich, nutzt das Programm FTP über TLS. Aber mancherorts sind noch veraltete FTP-Programme im Einsatz und auch der Windows Explorer von Windows 7 verschlüsselt seine FTP-­Kommunikation nicht. Wie das aussieht, finden Sie mit dem Display Filter ftp or ftp-data heraus.

Auch SMTP und IMAP können TLS-­abgesichert kommunizieren, aber ist das bei Ihren Servern der Fall? Manche Admins wähnen ihr Netz hinter der NAT ihres Routers in Sicherheit und betreiben interne SMTP- und IMAP-Server aus Bequemlichkeit unverschlüsselt – ein gefundenes Fressen für Emotet und andere Botnetze.

Bei den heute üblichen VoIP-Telefonaten ist die Lage vertrackt: Unter anderem kann man zwar SIP over TLS und sRTP zum Verschlüsseln von Steuer- und Nutzdaten verwenden, aber in Deutschland sind sie wenig verbreitet. Derzeit kann man nur VoIP-Konten der Telekom, EasyBell und Dus.net mit diesen beiden Protokollen absichern. Einige Router eignen sich bereits dafür, darunter Fritzboxen ab FritzOS 7.20 (siehe ct.de/yjkz).

Viele VoIP-Anbieter setzen die unverschlüsselten Protokolle SIP und RTP ein. Wenn Sie sich überzeugen wollen, wie einfach es ist, VoIP-Telefonate mitzuhören: Klicken Sie in Wireshark auf „Telephony/VoIP Calls“, wählen Sie einen der drei erkannten Anrufe aus und klicken Sie anschließend auf „Play Streams“.

Ausblick

„Ich weiß, dass ich nichts weiß“: Auch wenn diese Referenzdatei zahlreiche Protokolle enthält, kann sie nicht die Anforderungen aller Admins der Welt erfüllen. Sie lässt sich aber erweitern. In späteren Updates könnten die für Datacenter relevanten Protokolle MPLS, VXLAN oder ERSPAN hinzukommen, auch Klassiker wie POP3, LDAP oder NFS. Neuentwicklungen wie QUIC oder DNS-over-TLS sind ebenfalls spannende Kandidaten.

Dennoch sind die Anwendungsbereiche schon jetzt vielfältig: Man kann die Datei zum Vergleich mit einem lokalen Fehlerbild nutzen, zum Experimentieren mit Wireshark-Filtern, zum Testen von Netzwerk-Tools oder für Schulungs­zwecke. Möge sie auch Ihnen weiterhelfen.

Photo by Devon Divine on Unsplash.