Wireshark und tshark: Netzwerkverkehr systematisch auswerten

Wireshark ist der Standard zum Analysieren von Netzwerkverkehr. Im Alltag ist die Kommandozeilen-Variante tshark oft nützlicher, weil sie auf einem Server ohne grafische Oberfläche läuft und sich in Skripte einbauen lässt.

Wo man mitschneidet

Grundregel: So NAHE an der Fehlerstelle wie moeglich.
  Client  ---  Router  ---  Firewall  ---  Server
                  ^            ^            ^
             Hier schneiden die meisten mit. Besser:
             Auf beiden Enden gleichzeitig!

Der Vergleich ist das eigentliche Werkzeug:
  Kommt ein Paket am Server an, das der Client
  "schon abgeschickt" hat?
     ja  -> Problem liegt im Server oder zwischen
     nein -> Problem liegt auf dem Weg (Filter, NAT, Route)

Ohne diesen Vergleich raet man. Mit ihm findet man
die Ursache in Minuten.

Mitschneiden richtig gemacht

# Aufnahmen begrenzen - PFLICHT! Unbegrenztes Mitschneiden
# fuellt die Festplatte in Minuten und kann den Dienst
# erheblich verlangsamen.
tcpdump -i eth0 -s 0 -w /tmp/aufnahme.pcap -c 10000 -W 5 -C 50
#   -s 0        ganze Pakete (nicht kuerzen)
#   -w datei    in Datei schreiben
#   -c 10000    10.000 Pakete je Datei
#   -W 5        5 Dateien im Wechsel
#   -C 50       50 MB je Datei
#   -> maximal 250 MB, dann laeuft es im Kreis

# Lange Sitzung mit Zeitbegrenzung
timeout 300 tcpdump -i eth0 -w /tmp/aufnahme.pcap
#   Nach 5 Minuten von selbst beendet.

# Nur die Kopfzeilen (schnell, wenig Speicher)
tcpdump -i eth0 -s 96 -w /tmp/koepfe.pcap

# Gezielte Filter - je genauer, desto weniger Rauschen
tcpdump -i eth0 -n 'host 10.0.0.11 and tcp port 443'
tcpdump -i eth0 -n 'src 10.0.0.11 and not port 22'
tcpdump -i any -n 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'
tcpdump -i eth0 -n 'udp port 53'
tcpdump -i eth0 -n 'icmp'
tcpdump -i eth0 -n 'vlan'
tcpdump -i eth0 -n 'not arp and not broadcast and not multicast'

# Auf der Leitung lesen (keine Anzeige der Nutzdaten)
tcpdump -i eth0 -A -n 'port 80' | head -60

# Sehr praktisch: Nach HTTP-Anfragen filtern
tcpdump -i eth0 -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

# Als Root ohne tcpdump-Installation
ss -tanp | grep 443
strace -f -e trace=network -p          # Systemaufrufe der Anwendung

tshark: Auswertung ohne Oberfläche

# Alle Pakete einer Aufnahme auflisten
tshark -r /tmp/aufnahme.pcap

# Nur Felder ausgeben (gut fuer Skripte)
tshark -r /tmp/aufnahme.pcap -T fields \
  -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e tcp.flags -e tcp.analysis.retransmission

# Schwache Stellen: Wiederholungen
tshark -r /tmp/aufnahme.pcap -Y "tcp.analysis.retransmission" | head -30
tshark -r /tmp/aufnahme.pcap -Y "tcp.analysis.duplicate_ack"
tshark -r /tmp/aufnahme.pcap -Y "tcp.analysis.zero_window"      # Gegenstelle ueberlastet
tshark -r /tmp/aufnahme.pcap -Y "tcp.analysis.window_update"
tshark -r /tmp/aufnahme.pcap -Y "tcp.time_delta > 1"            # Pausen

# Verzoegerung der Anwendungsschicht
tshark -r /tmp/aufnahme.pcap -Y "http.time > 2" -T fields \
  -e http.request.method -e http.request.uri -e http.time

# DNS-Auswertung: Wie lange dauern Antworten?
tshark -r /tmp/aufnahme.pcap -Y "dns.flags.response == 1" -T fields \
  -e dns.qry.name -e dns.time | sort -k2 -rn | head -20

# TCP-Stream als Text rekonstruieren
tshark -r /tmp/aufnahme.pcap -q -z follow,tcp,ascii,0

# Statistiken
tshark -r /tmp/aufnahme.pcap -q -z io,stat,1
tshark -r /tmp/aufnahme.pcap -q -z conv,tcp          # Gespraechsuebersicht
tshark -r /tmp/aufnahme.pcap -q -z expert            # Hinweise und Warnungen

# Zertifikate aus dem TLS-Handshake
tshark -r /tmp/aufnahme.pcap -Y "tls.handshake.type == 11" \
  -T fields -e x509sat.printableString | sort -u

Ein typischer Ablauf bei der Fehlersuche

Aufgabe: Eine Anwendung "ist manchmal langsam". Niemand weiss warum.

1. Umfang eingrenzen (10 Minuten)
   # Auf Client und Server gleichzeitig mitschneiden (je 5 Minuten)
   #   Erster Schnitt: Wer ist langsam - Netz oder Anwendung?
   tshark -r client.pcap -q -z conv,tcp | head
   #   Ergebnis: Eine Verbindung mit 4 MB, die 30 Sekunden braucht.

2. Netz ausschliessen (5 Minuten)
   #   Wiederholungen und Nullfenster - die klassischen Netzbremse
   tshark -r client.pcap -Y "tcp.analysis.retransmission" | wc -l
   tshark -r client.pcap -Y "tcp.analysis.zero_window" | wc -l
   #   Ergebnis: Keine Wiederholungen, keine Nullfenster.
   #   -> Das Netz ist nicht das Problem.

3. Anwendung ansehen (10 Minuten)
   #   Zeit zwischen Anfrage und Antwort messen
   tshark -r client.pcap -Y "http.response" -T fields \
     -e http.request.uri -e http.time | sort -k2 -rn | head
   #   Ergebnis: Eine bestimmte Abfrage braucht 28 Sekunden.
   #   -> Die Anwendung ist das Problem, nicht das Netz.

Ergebnis: Ohne die Aufnahmen haette man tagelang
vermutet und vielleicht die Netzwerkkarte getauscht.

Prüfliste

Sind die Aufnahmen größen- und zeitbegrenzt (kein „läuft bis zum Vollaufen“)?
Wird auf beiden Enden gleichzeitig mitgeschnitten, statt zu raten?
Sind die Filter so eng wie möglich gefasst (kein Rauschen)?
Werden Aufnahmen mit Kennungen (Beauftragung, Ticket) abgelegt und nach der Analyse gelöscht?
Sind personenbezogene Daten in den Nutzdaten berücksichtigt (Mitlesen ist ein Eingriff!)?
Wird auf einem Spiegel-Port oder per tcpdump auf dem Ziel geschnitten – beides hat Grenzen?
Ist bekannt, dass der Schnitt selbst Last erzeugt (besonders bei hoher Rate)?
Wird der Ausschluss systematisch gemacht (erst Netz, dann Anwendung)?

Häufige Fehler

Kein Größenlimit. Die Aufnahme füllt die Platte und der Dienst fällt aus. -c, -C, -W oder timeout sind Pflicht.
Nur am Client schneiden. Dann weiß man nicht, ob die Pakete angekommen sind – genau das ist meist die entscheidende Frage.
Ohne Filter. Eine Aufnahme mit SSH-Datenverkehr und anderen Diensten ist unlesbar.
Aufnahmen im Klartext. Wer Nutzdaten mitschneidet, sieht Zugangsdaten und personenbezogene Daten. Aufnahmen sind sensibel: verschlüsseln, kurzfristig löschen, Zugriff beschränken.
Aufnahme vergessen. Ein vergessener Schnitt füllt die Platte über Nacht. Immer mit Zeitbegrenzung arbeiten.
Auf virtuellem Interface schneiden und wundern. Bei Containern und virtuellen Maschinen ist -i any nötig, weil das echte Interface an der Brücke vorbeigeht.
Auswertung ohne Struktur. Ohne die Reihenfolge „Netz ausschließen, dann Anwendung“ verliert man sich in Details.

Verwandte Grundlagen: tcpdump, TCP, ss und netstat.

Netzwerk: TCP/IP