Mit diesem Beitrag möchte ich einen Einstieg in die Analyse von Log-Files bieten, die mit tcpdump erzeugt werden. Man findet im Internet aus gutem Grund keine umfangreichen Anleitungen zur Fehleranalyse, da die Fehler vielfältig und die Lösungsansätze entsprechend speziell sind. Besonders wichtig ist eine Strategie bei der Fehlersuche, um potentielle Fehlerursachen systematisch nacheinander zu untersuchen.
Einige weitere hilfreiche Seiten habe ich am Ende des Beitrags verlinkt.
Der Aufbau eines TCP-Pakets
Die Organisation des Netzwerkverkehrs wird mittels eines Paketheaders sichergestellt. Die Bedeutung und Funktion der einzelnen Angaben ist für die Fehlersuche essentiell. Zudem muss man die Abfolge von Anfrage- und Antwortpaketen für ein bestimmtes Problemfeld kennen.
Das Netz im Ruhezustand
Schauen wir uns also erst mal das Netz im Ruhezustand an. Ruhezustand meint hier, dass Rechner im Netz laufen, ohne dass eine Software Netzwerkaktivitäten ausführt. Die nachfolgenden Ausgaben wurden erzeugt mit dem Aufruf
[-] # tcpdump -q -i net <ip-bereich>
Der <ip-bereich> könnte z.B. 10.0.0.0/24 oder 192.168.1.0/24 sein. Der Parameter -q erzeugt eine verkürzte Ausgabe.
IP <ip-address>.5353 > 224.0.0.xxx.5353: UDP, lenght xx
<ip-address> ist dabei immer eine IP-Adresse aus dem eigenen Netz und der Empfänger 224.0.0.xxx ist ein Multicast zur Verteilung der Daten von einem Sender an mehrere ausgewählte Empfänger (Local Network Control Block). Bei den Daten handelt es sich um -> MulticastDNS, die regelmässig verschickt werden.
ARP, Request who has <ip1/host1> tell <ip2/host2>, lenght xx
Das Address Resolution Protocol baut Tabellen auf, die den IP-Adressen die zugehörige MAC-Adresse zuordnet. Der obigen Broadcast-Anfrage an alle Systeme im Netz folgt die Antwort aller Systeme, die sie empfangen haben.
ARP, Reply <ip1/host1> at <MAC-address> (oui Unknown), lenghth xx
netbios-ns und netbios-dgm
NETBIOS (Network Basic Input Output System) ist als Protokoll weitgehend obsolet und die Pakete werden nur aus Kompatibilitätsgründen gesendet.
Ruft man tcpdump anstelle des Parameter -q mit -v , -vv oder -vvv auf, sind die Ausgaben wesentlich umfangreicher und man erhält auch die Werte aus dem Layer-3-Datagramm, zu dem man -> hier und -> hier ausführliche Beschreibungen bekommt.
10:04:07.075813 IP (tos 0x0, ttl 64, id 27844, offset 0, flags [DF], proto UDP (17), length 211)
Netzwerkverkehr analysieren
Für die Fehleranalyse muss man sich in tcpdump und die Abläufe der Netzwerk-Kommunikation einarbeiten. Da es hier unzählige Möglichkeiten gibt, kann ich das Vorgehen bei der Analyse nicht für jeden Fall beschreiben. Folgendes Beispiel zeigt daher exemplarisch die Vorgehensweise, wenn man vermutet, dass bereits der Verbindungsaufbau nicht funktioniert.
Das Log wurde hier mit folgendem Befehl erstellt:
[-] # tcpdump -v -i eth1 port xxxx
Es wird hier nur der Datenverkehr auf einem Port betrachtet und die Ausgabe erfolgt mit dem Parameter -v inklusive kompakt dargestellter IP-Paket-Header.
Hier fallen zunächst die Fehler bei der Checksum-Prüfung der Pakete auf. Die Ursache dafür ist, dass TCO (tcp offloading) für Sende- und Empfangsdaten eingeschaltet ist. Zum Zeitpunkt der Checksum-Prüfung liegt noch nicht das gesamte Datenpaket vor. Deaktiviert man TCO verschwindet zwar der Fehler, dafür sinkt aber die Performance. -> Hier gibt es eine ausführliche Erklärung dazu.
Diese Angabe ist also für die Fehlersuche belanglos.
tcpdump-flags
Die Flags eines Pakets zeigen an, welche Funktion es hat. Hier handelt es sich um ein IP-Paket zur Datenübertragung, wie man an der Angabe nach der timestamp sieht:
11:05:24.813179 IP (tos 0x0, ttl 64, id 2589, offset 0, flags [DF], proto TCP (6), length 58)
NAS.9453 > 10.0.0.2.57316: Flags [P.], cksum 0x154c (incorrect -> 0x3605), seq 4094532734:4094532740, ack 1535829653, win 939, options [nop,nop,TS val 1919312527 ecr 3342113842], length 6
Die Angabe hinter flags zeigt die Art des Pakets.
- [S] = SYN (Start Connection)
- [P] – PSH (Push Data)
- [F] = FIN (Finish Connection)
- [R] = RST (Reset Connection)
- [DF] = Don’t fragment
- [.] = ACK (Acknowledged)
Zur Fehleranalyse muss man nun folgendes wissen: Der Ablauf beim Verbindungsaufbau muss aus drei Paketen bestehen.
- IP1 sendet ein [S] für SYN (Start Connection), worauf
- IP2 ein [S.] für SYN-ACK (Acknowledged) zurückschickt.
- IP1 bestätigt den Empfang wiederum mit [.] für SYN-ACK-ACK (Acknowledged).
Sieht man im LOG nun mehrere nacheinander folgende [S]-Pakete an die gleiche IP-Adresse, denen kein ACK-Paket folgt, dann ist das ein Beleg dafür, dass kein Verbindungsaufbau erfolgt.
Allerdings sollte man berücksichtigen, dass auch bei einem erfolgreichen SYNC hier nur der Verkehr auf der Netzwerkkarte betrachtet wird. Man müsste in so einem Fall nun z.B. prüfen, ob z.B. iptables bzw. die eigenen Firewallregeln einen Verbindungsaufbau verhindern.
Recht gute Tipps zum Umgang mit tcpdump findet man bei -> https://hackertarget.com/tcpdump-examples/ (englische Seite).
Viele Anwendungsbeipiele gibt es bei -> https://danielmiessler.com/study/tcpdump/ (deutsche Seite).
Ähnliche Beiträge:
-> tcpdump auf einer QNAP NAS installieren
-> SSL-VPN mit OpenVPN in Ubuntu 18.04
