3.16 Paketmitschnitt mit Wireshark, tcpdump, Dumpcap und Pktmon

Paketmitschnitte können enthalten:

• interne und öffentliche IP-Adressen,
• MAC-Adressen,
• Hostnamen,
• DNS-Anfragen,
• unverschlüsselte Nutzdaten,
• Cookies,
• Sitzungstoken,
• Benutzernamen,
• E-Mail-Inhalte,
• Dateiübertragungen,
• API-Daten,
• Authentifizierungsinformationen,
• Netzwerk- und Sicherheitsarchitektur.

Paketaufzeichnungen dürfen nur im genehmigten Umfang erstellt, gespeichert und weitergegeben werden.

Ein Paketmitschnitt zeigt nicht automatisch:

• welche Firewallregel entschieden hat,
• warum eine Anwendung einen Fehler erzeugt hat,
• ob ein Paket vor dem Messpunkt verworfen wurde,
• ob ein verschlüsselter Inhalt fachlich korrekt ist,
• ob ein Benutzer die richtige Berechtigung besitzt.

Die beste Diagnose kombiniert Paketmitschnitt, Systemprotokoll und Anwendungsergebnis.

Vor dem Start müssen mindestens diese Angaben bekannt sein:

Clienthostname:
Client-IP-Adresse:
Serverhostname:
Server-IP-Adresse:
Transportprotokoll:
Clientport:
Serverport:
Anwendungsprotokoll:
IPv4 oder IPv6:
Startzeitpunkt:
Fehlerauslöser:
Erwartetes Paketmuster:

Beispiel:

Client:       192.0.2.25
Server:       192.0.2.53
Transport:    TCP
Serverport:   443
Anwendung:    HTTPS
Fehler:       Verbindung läuft in einen Timeout

Passender enger Filter:

host 192.0.2.25 and host 192.0.2.53 and tcp port 443

Ein enger Filter reduziert Datenmenge und Datenschutzrisiko. Er kann jedoch wichtige Begleitprotokolle wie DNS, ARP, ICMP oder ICMPv6 ausblenden.

Client
  ↓
Access Point oder Switch
  ↓
Router beziehungsweise Firewall
  ↓
VPN oder WAN
  ↓
Servernetz
  ↓
Server
  ↓
Anwendung

Mögliche Messpunkte:

• direkt auf dem Client,
• direkt auf dem Server,
• auf dem Reverse Proxy,
• auf dem VPN-Gateway,
• auf der Firewall,
• auf dem Router,
• über einen Switch-Mirror-Port,
• über einen Network TAP,
• im Container,
• auf dem Containerhost,
• in der virtuellen Maschine,
• auf dem Hypervisor.

Leitfrage:

Welche Netzwerkkomponente baut die betroffene Verbindung tatsächlich auf?

Bei einem Reverse Proxy ist der Administrator-PC nicht der richtige Messpunkt für die Verbindung zwischen Proxy und Backend.

Einseitiger Mitschnitt:

Clientmitschnitt

Er zeigt nur, was am Client sichtbar ist.

Doppelseitiger Mitschnitt:

Clientmitschnitt
+
Servermitschnitt
+
synchronisierte Zeit

Damit lässt sich feststellen:

• ob ein Paket den Client verlässt,
• ob es den Server erreicht,
• ob der Server antwortet,
• ob die Antwort den Client erreicht,
• in welcher Richtung Verlust entsteht,
• wo zusätzliche Verzögerung auftritt,
• ob NAT oder Proxy Adressen verändert,
• ob ein Netzwerkgerät Pakete zurücksetzt.

Bei komplexen Problemen ist ein gleichzeitiger Mitschnitt an beiden Endpunkten wesentlich aussagekräftiger.

Für den Vergleich mehrerer Mitschnitte und Protokolle müssen Zeit und Zeitzone bekannt sein.

UTC-Zeit:

Windows:

[RO] (Get-Date).ToUniversalTime().ToString("o")

Linux und macOS:

[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"

Zu dokumentieren sind:

• Beginn der Aufzeichnung,
• Zeitpunkt der Fehlerauslösung,
• Ende der Aufzeichnung,
• Zeitzone,
• Zeitabweichung zwischen Messsystemen.

Eine Zeitabweichung von wenigen Sekunden kann die Zuordnung kurzer Verbindungsversuche erheblich erschweren.

Windows mit Dumpcap:

[RO] dumpcap -D

Windows-Netzwerkadapter:

[RO] Get-NetAdapter -IncludeHidden |
    Format-Table Name, InterfaceDescription, Status, MacAddress

Linux:

[RO] ip -br link

[RO] tcpdump -D

macOS:

[RO] networksetup -listallhardwareports

[RO] ifconfig

[RO] tcpdump -D

Zu prüfen sind:

• physische Schnittstelle,
• WLAN oder Ethernet,
• VPN-Tunnel,
• Bridge,
• VLAN-Interface,
• Container-Bridge,
• Loopback,
• virtuelle Maschine,
• aktive Route zum Ziel.

Route zum Ziel:

Mit any kann tcpdump gleichzeitig auf mehreren Linux-Schnittstellen aufzeichnen:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \
    -w capture.pcap

Vorteile:

• hilfreich bei unbekanntem Pfad,
• zeigt Verkehr auf mehreren Schnittstellen,
• geeignet für Router-, Proxy- und Containerhosts.

Einschränkungen:

• Link-Layer-Darstellung kann sich von einer konkreten Ethernetaufzeichnung unterscheiden,
• derselbe Datenfluss kann an mehreren Stellen erscheinen,
• Adressen können vor und nach NAT sichtbar sein,
• Reihenfolge und Interpretation werden komplexer,
• nicht jede hardwarenahe Information ist verfügbar.

Für eine präzise Layer-2-Analyse sollte möglichst die konkrete Schnittstelle gewählt werden.

Promiscuous Mode:

Eine Ethernet-Schnittstelle nimmt zusätzlich Frames an, die nicht direkt an ihre eigene MAC-Adresse adressiert sind. In einem geswitchten Netzwerk werden dadurch jedoch nicht automatisch alle Frames anderer Switchports sichtbar.

WLAN Monitor Mode:

Ein geeigneter WLAN-Adapter erfasst 802.11-Funkframes auf einem bestimmten Kanal beziehungsweise Frequenzbereich.

Monitor Mode kann die normale WLAN-Verbindung unterbrechen und wird nicht von jeder Hardware, jedem Treiber oder Betriebssystem unterstützt.

Ein Client an einem Switchport sieht normalerweise:

• eigenen Unicastverkehr,
• Broadcastverkehr im eigenen Broadcastbereich,
• relevanten Multicastverkehr,
• bestimmte Kontrollprotokolle.

Er sieht normalerweise nicht automatisch:

• Unicastverkehr zwischen zwei anderen Switchports,
• Verkehr in anderen VLANs,
• Pakete hinter einer Firewall,
• Verkehr eines anderen virtuellen Switches.

Für fremden Unicastverkehr sind abhängig von Infrastruktur und Berechtigung erforderlich:

• SPAN beziehungsweise Port Mirroring,
• Remote SPAN,
• Network TAP,
• Aufzeichnung direkt auf dem Zielsystem,
• Aufzeichnung auf Router oder Firewall.

Ein falsch konfigurierter Mirror-Port kann Pakete verlieren, wenn die gespiegelte Datenmenge seine Kapazität überschreitet.

Capture Filter:

host 192.0.2.20 and tcp port 443

Wireshark Display Filter:

ip.addr == 192.0.2.20 && tcp.port == 443

Die Syntax ist nicht austauschbar.

Grundentscheidung:

• enger Capture Filter bei Datenschutz- oder Speicheranforderungen,
• breiterer Capture Filter bei unklarer Ursache,
• Display Filter für schrittweise Auswertung.

Capture Filter verwenden die Syntax der Paketfilterbibliothek. Vor produktiven Aufzeichnungen sollte die lokale Unterstützung geprüft werden.

Alle Pakete einer Schnittstelle:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -w capture.pcap

Nur definierter Client und TCP-Port 443:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w https-test.pcap

DNS-Verkehr:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'port 53' \
    -w dns-test.pcap

DHCPv4:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'udp port 67 or udp port 68' \
    -w dhcp-test.pcap

Ohne Datei, direkt lesbar:

[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25 and tcp port 443'

-nn verhindert die Auflösung von Hostnamen und Dienstnamen. Dadurch wird die Ausgabe schneller und eindeutiger.

Zuerst die tatsächliche Schnittstelle ermitteln:

[RO] networksetup -listallhardwareports

Beispiel für Ethernet oder WLAN auf en0:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'host 192.0.2.25 and tcp port 443' \
    -w https-test.pcap

DNS-Verkehr:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \
    'port 53' \
    -w dns-test.pcap

VPN-Tunnel untersuchen:

[RO] ifconfig

Anschließend die tatsächlich ermittelte Tunnelschnittstelle verwenden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \
    'host INTERNES_ZIEL' \
    -w vpn-inner.pcap

Schnittstellennamen wie en0 oder utun0 dürfen nicht ohne vorherige Prüfung vorausgesetzt werden.

Dumpcap ist Bestandteil einer Wireshark-Installation und kann ohne grafische Oberfläche aufzeichnen.

Schnittstellen anzeigen:

[RO] dumpcap -D

Auf Schnittstelle 1 aufzeichnen:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -w capture.pcapng

Mit Capture Filter:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.25 and tcp port 443" `
    -w https-test.pcapng

Aufzeichnung nach 60 Sekunden beenden:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -a duration:60 `
    -w capture-60s.pcapng

Die Schnittstellennummer 1 ist nur ein Beispiel und muss vorher mit dumpcap -D ermittelt werden.

Pktmon ist ein in Windows integriertes Diagnosewerkzeug. Es kann Pakete an mehreren Stellen innerhalb des Windows-Netzwerkstacks erfassen und verworfene Pakete erkennen.

Vor Verwendung lokale Syntax prüfen:

[RO] pktmon help

Aktuellen Status anzeigen:

[RO][PRIV] pktmon status

Netzwerkkomponenten anzeigen:

[RO][PRIV][SENS] pktmon list

Aufzeichnung in eine ETL-Datei starten:

[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl

Fehler reproduzieren und Aufzeichnung beenden:

[TEST][PRIV][FILE][SENS] pktmon stop

ETL nach PCAPNG konvertieren:

[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng

Pktmon-Optionen können sich zwischen unterstützten Windows-Versionen unterscheiden. Vor einer produktiven Aufzeichnung müssen die lokale Hilfe und der geplante Umfang geprüft werden.

Pktmon kann zusätzlich Informationen über innerhalb des Windows-Netzwerkstacks verworfene Pakete erfassen.

Pktmon-Zähler anzeigen:

[RO][PRIV][SENS] pktmon counters

Nur als verworfen markierte Pakete konvertieren:

[RO][FILE][SENS] pktmon etl2pcap pktmon.etl ^
    --drop-only ^
    --out pktmon-drops.pcapng

Microsoft weist darauf hin, dass bei der PCAPNG-Konvertierung bestimmte Pktmon-Metadaten verloren gehen können. PCAPNG unterscheidet danach nicht automatisch zwischen regulär weitergeleiteten und verworfenen Paketen.

Deshalb sollten bei Bedarf getrennte Dateien erzeugt werden:

vollständige Aufzeichnung
+
separate Drop-Aufzeichnung
+
ursprüngliche ETL-Datei

Die ursprüngliche ETL-Datei muss geschützt aufbewahrt werden, wenn die zusätzlichen Pktmon-Informationen für die Diagnose benötigt werden.

Eine unbegrenzte Aufzeichnung kann den Datenträger füllen. Dumpcap unterstützt Ringspeicher mit mehreren Dateien.

Datei alle fünf Minuten wechseln und maximal zwölf Dateien behalten:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -b duration:300 `
    -b files:12 `
    -w ringbuffer.pcapng

Zusätzlich Capture Filter verwenden:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host 192.0.2.25" `
    -b duration:300 `
    -b files:12 `
    -w ringbuffer.pcapng

Damit werden ungefähr die letzten 60 Minuten in zwölf Fünf-Minuten-Dateien gehalten. Dateiverarbeitung und Wechselverhalten müssen mit der installierten Dumpcap-Version geprüft werden.

Datei nach ungefähr 100 Millionen Byte wechseln und maximal zehn Dateien verwenden:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -C 100 \
    -W 10 \
    -w capture.pcap

Mit Filter:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    'host 192.0.2.25' \
    -C 100 \
    -W 10 \
    -w capture.pcap

Die genaue Dateibenennung und Rotation hängt von der installierten tcpdump-Version ab. Vor einer Langzeitaufzeichnung lokale Hilfe prüfen:

[RO] tcpdump --help

oder:

[RO] man tcpdump

Die Capture-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden.

tcpdump – vollständige Pakete anfordern:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \
    -s 0 \
    -w capture.pcap

Bei aktuellen tcpdump-Versionen bedeutet -s 0, dass die vom Werkzeug unterstützte maximale Paketlänge erfasst wird.

Abwägung:

Für eine reine Headeranalyse sollte geprüft werden, ob eine begrenzte Capture-Länge ausreicht.

PCAP-Datei ohne Namensauflösung anzeigen:

[RO][SENS] tcpdump -nn -r capture.pcap

Nur TCP-Port 443 aus einer vorhandenen Datei anzeigen:

[RO][SENS] tcpdump -nn -r capture.pcap \
    'tcp port 443'

Zeitstempel ausführlicher anzeigen:

[RO][SENS] tcpdump -tttt -nn -r capture.pcap

Das nachträgliche Filter verändert die Originaldatei nicht.

TShark ist die Kommandozeilenversion der Wireshark-Protokollanalyse.

Schnittstellen anzeigen:

[RO] tshark -D

Vorhandene Datei lesen:

[RO][SENS] tshark -r capture.pcapng

Display Filter anwenden:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.port == 443'

DNS-Anfragen ausgeben:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'dns.flags.response == 0' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e dns.qry.name

TCP-Wiederholungen ausgeben:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'tcp.analysis.retransmission'

HTTP-Statuscodes:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'http.response' \
    -T fields \
    -e frame.time \
    -e ip.src \
    -e ip.dst \
    -e http.response.code

Capture Filter während der Aufzeichnung:

[TEST][PRIV][FILE][SENS] tshark -i INTERFACE \
    -f 'host 192.0.2.25 and tcp port 443' \
    -w capture.pcapng

Display Filter auf vorhandener Datei:

[RO][SENS] tshark -r capture.pcapng \
    -Y 'ip.addr == 192.0.2.25 && tcp.port == 443'

Zuordnung:

-f = Capture Filter
-Y = Display Filter

Ein Display Filter kann nicht als Capture Filter übernommen werden, wenn er eine Wireshark-spezifische Syntax verwendet.

capinfos gehört zur Wireshark-Werkzeugsammlung.

Grundinformationen:

[RO][SENS] capinfos capture.pcapng

Mögliche Angaben:

• Dateiformat,
• Anzahl der Pakete,
• Datenmenge,
• Startzeit,
• Endzeit,
• Aufzeichnungsdauer,
• durchschnittliche Paketrate,
• Datenrate,
• Schnittstelleninformationen.

Mehrere Dateien vergleichen:

[RO][SENS] capinfos client.pcapng server.pcapng

Damit lassen sich unter anderem Zeitbereiche und Größen vor einer Zusammenführung kontrollieren.

mergecap führt mehrere Capture-Dateien in eine neue Datei zusammen.

[RO][FILE][SENS] mergecap \
    -w combined.pcapng \
    client.pcapng \
    server.pcapng

Vorher müssen geprüft werden:

• Zeitstempel,
• Zeitzone,
• Uhrabweichung,
• unterschiedliche Schnittstellen,
• mögliche Paketduplikate,
• unterschiedliche Messpunkte,
• NAT- oder Proxyübersetzung.

Eine zusammengeführte Datei kann dasselbe Paket mehrfach enthalten, wenn es an mehreren Messpunkten erfasst wurde.

editcap kann Capture-Dateien bearbeiten, aufteilen oder zeitlich begrenzen.

Lokale Hilfe:

[RO] editcap --help

Erste 1.000 Pakete in neue Datei schreiben:

[RO][FILE][SENS] editcap -r capture.pcapng \
    capture-first-1000.pcapng \
    1-1000

Datei in Paketeinheiten aufteilen:

[RO][FILE][SENS] editcap -c 10000 \
    capture.pcapng \
    capture-part.pcapng

Vor dem Bearbeiten muss die Originaldatei unverändert aufbewahrt werden. Eine verkleinerte Datei kann für die Weitergabe sinnvoll sein, entfernt aber nicht automatisch alle sensiblen Inhalte.

In Wireshark sind wichtige Spalten:

Wichtig: Frame-Nummern gelten nur innerhalb der konkreten Datei. Nach Filterung, Zusammenführung oder Bearbeitung können sich Nummern ändern.

Für eine belastbare Dokumentation zusätzlich angeben:

• Dateiname,
• Zeitstempel,
• Quell- und Zieladresse,
• Protokoll,
• relevante Sequenz- oder Transaktionskennung.

Wireshark kann zusammengehörige Datenströme darstellen:

• Follow TCP Stream,
• Follow UDP Stream,
• Follow TLS Stream,
• Follow HTTP Stream,
• weitere protokollspezifische Streams.

Damit lassen sich beispielsweise betrachten:

• Anfragen und Antworten,
• Reihenfolge der Daten,
• Klartextprotokolle,
• Verbindungsabbrüche,
• HTTP-Fehler,
• Protokolldialoge.

Sicherheitswarnung: Follow Stream kann vollständige unverschlüsselte Anwendungsdaten und Zugangsinformationen anzeigen. Inhalte dürfen nicht ungeprüft kopiert oder weitergegeben werden.

Erfolgreicher Verbindungsaufbau:

Client → Server: SYN
Server → Client: SYN, ACK
Client → Server: ACK

Wireshark-Filter:

tcp.flags.syn == 1

Nur erste SYN-Pakete:

tcp.flags.syn == 1 && tcp.flags.ack == 0

Ein regulärer TCP-Abbau verwendet FIN- und ACK-Segmente. Ein RST beendet eine Verbindung unmittelbar.

Filter:

tcp.flags.fin == 1 || tcp.flags.reset == 1

Die Quelladresse eines RST allein beweist nicht immer seine tatsächliche Herkunft, da Sicherheitsgeräte Pakete im Namen eines Endpunkts erzeugen können.

Filter:

tcp.analysis.retransmission

Weitere Filter:

tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.lost_segment

Mögliche Ursachen:

• tatsächlicher Paketverlust,
• Paketverlust nur am Capture-Messpunkt,
• asymmetrisches Routing,
• NIC-Offloading,
• Start der Aufzeichnung mitten in der Verbindung,
• Pakete in anderer Reihenfolge,
• überlasteter Messrechner,
• Mirror-Port verwirft Pakete.

Wireshark-Analyseflags sind Interpretationen. Sie müssen mit Sequenznummern, ACKs und möglichst einem Mitschnitt der Gegenstelle überprüft werden.

Netzwerkadapter und Betriebssysteme können Verarbeitung auslagern:

• TCP Segmentation Offload,
• Large Send Offload,
• Generic Segmentation Offload,
• Generic Receive Offload,
• Checksum Offload.

Dadurch können lokale Mitschnitte zeigen:

• scheinbar falsche Prüfsummen,
• Pakete größer als die physische MTU,
• zusammengefasste Segmente,
• Segmentierung erst nach dem Capture-Punkt.

Typischer Hinweis:

Checksum incorrect

direkt auf dem sendenden Host bedeutet nicht automatisch, dass das Paket mit falscher Prüfsumme auf dem Netzwerk übertragen wurde. Die Netzwerkkarte kann die Prüfsumme erst nach dem lokalen Capture-Punkt berechnen.

Ein Mitschnitt auf der Gegenstelle oder einem externen TAP zeigt eher den tatsächlich übertragenen Zustand.

ARP-Filter:

arp

Typischer IPv4-Ablauf:

Who has 192.0.2.1?
192.0.2.1 is at 00:11:22:33:44:55

Zu prüfen sind:

• Anfrage sichtbar,
• Antwort sichtbar,
• richtige MAC-Adresse,
• mehrere Antworten,
• häufige Wiederholungen,
• Gratuitous ARP,
• Adresskonflikt.

IPv6 Neighbor Discovery:

icmpv6

Zu prüfen sind unter anderem:

• Neighbor Solicitation,
• Neighbor Advertisement,
• Router Solicitation,
• Router Advertisement,
• Duplicate Address Detection,
• Packet Too Big.

ICMPv6 darf nicht pauschal als unwichtiger Diagnoseverkehr betrachtet werden.

Capture Filter:

udp port 67 or udp port 68

Display Filter:

dhcp

Typischer Ablauf:

DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK

Bekannt als:

DORA

Capture Filter:

port 53

Display Filter:

dns

Nur DNS-Anfragen:

dns.flags.response == 0

Nur DNS-Antworten:

dns.flags.response == 1

Bestimmter Name:

dns.qry.name == "service.example.internal"

Zu prüfen sind:

• richtige Zieladresse des DNS-Servers,
• Anfrage über UDP oder TCP,
• Antwortzeit,
• Antwortcode,
• zurückgegebene A- und AAAA-Adressen,
• CNAME-Kette,
• Wiederholungen,
• Wechsel zu TCP,
• unterschiedliche Antworten verschiedener Resolver.

Typische Antwortcodes:

Filter:

tls.handshake

Typischer Ablauf kann enthalten:

Client Hello
Server Hello
Certificate
Schlüsselaustausch
Finished
Application Data

Zu prüfen sind:

• verwendeter Servername über SNI,
• angebotene TLS-Versionen,
• ausgewählte TLS-Version,
• Cipher Suites,
• präsentierte Zertifikate,
• TLS-Alerts,
• Zeitpunkt des Abbruchs,
• erfolgreiche Application Data nach dem Handshake.

TLS-Alerts:

tls.alert_message

Verschlüsselte Anwendungsdaten können ohne zulässige Sitzungsschlüssel nicht inhaltlich analysiert werden. Private Server-Schlüssel sind bei modernen Verfahren nicht automatisch ausreichend, um aufgezeichnete Sitzungen nachträglich zu entschlüsseln.

HTTP-Anfragen:

http.request

HTTP-Antworten:

http.response

Statuscode:

http.response.code

Proxy-CONNECT:

http.request.method == "CONNECT"

Zu prüfen sind:

• Hostheader,
• Methode,
• angefragter Pfad,
• Statuscode,
• Weiterleitungen,
• Proxy-Authentifizierung,
• Antwortzeit,
• Verbindungsabbruch,
• Reverse-Proxy-Header.

Bei HTTPS sind HTTP-Inhalte normalerweise verschlüsselt. Sichtbar bleiben abhängig vom Verfahren unter anderem IP-Adressen, Ports, TLS-Handshake und teilweise Servername.

Filter:

icmp || icmpv6

Mögliche Meldungen:

• Destination Unreachable,
• Port Unreachable,
• Network Unreachable,
• Host Unreachable,
• Administratively Prohibited,
• Time Exceeded,
• Fragmentation Needed,
• Packet Too Big,
• Redirect.

Diese Meldungen enthalten häufig Teile des ursprünglichen Pakets. Dadurch kann festgestellt werden, welche Verbindung die Fehlermeldung ausgelöst hat.

ICMP-Fehlermeldungen sind wichtige Bestandteile der Netzwerkfunktion und nicht nur Ping-Antworten.

Vor NAT:

192.168.10.25:53144 → 198.51.100.20:443

Nach SNAT:

203.0.113.10:62001 → 198.51.100.20:443

Vor DNAT:

198.51.100.25:54000 → 203.0.113.10:8443

Nach DNAT:

198.51.100.25:54000 → 192.168.10.50:443

Für die Zuordnung werden benötigt:

• Zeitstempel,
• Protokoll,
• ursprüngliche Quelladresse,
• übersetzte Quelladresse,
• ursprüngliche Zieladresse,
• übersetzte Zieladresse,
• Ports,
• TCP-Sequenznummern,
• NAT- beziehungsweise Conntrack-Eintrag.

Auf Containerhosts kann derselbe Datenfluss an Host-, Bridge- und Containerinterface mehrfach erscheinen.

Mögliche Messpunkte:

physischer Host
virtueller Switch
VM-Schnittstelle
Container-Bridge
Container-Netzwerk-Namespace
Anwendungscontainer

Zu prüfen sind:

• Wird NAT verwendet?
• Verwendet die VM Bridge- oder Host-Only-Networking?
• Ist der Containerport veröffentlicht?
• Baut ein Reverse Proxy die Backendverbindung auf?
• Existieren mehrere virtuelle Bridges?
• Sieht der Host den Verkehr vor oder nach NAT?
• Wird Hardware-Offloading eingesetzt?
• Greift eine Hypervisor- oder Cloud-Firewall?

Ein Mitschnitt auf dem Administrator-PC beantwortet keine Frage über eine interne Container-zu-Container-Verbindung.

Verschlüsselte Protokolle schützen die Nutzdaten:

• HTTPS beziehungsweise TLS,
• SSH,
• VPN,
• SMB-Verschlüsselung,
• IPsec,
• WireGuard,
• verschlüsselte Datenbankverbindungen.

Ohne zulässige Entschlüsselungsinformationen sind häufig trotzdem sichtbar:

• Quell- und Zieladressen,
• Ports,
• Paketgrößen,
• Zeitstempel,
• Verbindungsaufbau,
• Verbindungsabbau,
• Wiederholungen,
• TLS-Versionen,
• Zertifikate im Handshake,
• bestimmte Servernamen,
• Datenmengen,
• Antwortpausen.

Nicht durchführen:

• private Schlüssel exportieren,
• TLS-Prüfung umgehen,
• fremde Sitzungen entschlüsseln,
• produktive Geheimnisse in Wireshark hinterlegen,
• Schlüsselprotokolldateien ungeschützt speichern.

Ein Capture-System kann Pakete verlieren.

Mögliche Ursachen:

• zu hohe Paketrate,
• langsamer Datenträger,
• kleine Capture-Puffer,
• überlastete CPU,
• zu breite Aufzeichnung,
• Mirror-Port überlastet,
• mehrere gespiegelte Vollduplexlinks auf zu kleinem Zielport,
• virtuelle Capture-Schicht,
• Treiberproblem,
• USB-Netzwerkadapter,
• Remote-Capture-Verbindung.

Wireshark, Dumpcap oder tcpdump können Informationen über vom Capture-Prozess verworfene Pakete ausgeben.

Wichtig:

Im Mitschnitt fehlend
≠
sicher im Netzwerk verloren

Das Paket kann lediglich vom Messsystem nicht gespeichert worden sein.

Empfohlenes Schema:

DATUM_UHRZEIT_MESSPUNKT_QUELLE_ZIEL_PROTOKOLL.pcapng

Beispiel:

2026-07-31_143500_client01_web01_https.pcapng

Keine sensiblen Benutzernamen oder vollständigen personenbezogenen Angaben in Dateinamen verwenden.

Zusätzlich eine Textnotiz anlegen:

Dateiname:
Messpunkt:
Schnittstelle:
Capture Filter:
Startzeit:
Fehlerzeit:
Endzeit:
Client:
Server:
Testhandlung:
Zeitzone:
Bearbeiter:

Vor einer Weitergabe:

1. Originaldatei geschützt aufbewahren.
2. Nur relevanten Zeitbereich extrahieren.
3. Nur benötigte Pakete übernehmen.
4. Nutzdaten auf sensible Inhalte prüfen.
5. DNS-Namen, Adressen und Identitäten bewerten.
6. Unternehmensrichtlinien beachten.
7. Empfänger und Übertragungsweg festlegen.
8. Aufbewahrungsfrist dokumentieren.
9. Nicht mehr benötigte Kopien kontrolliert löschen.

Eine PCAP-Datei ist kein harmloser Screenshot. Sie kann vollständige Kommunikationsinhalte enthalten.

NUMMER, INTERFACE und IP müssen durch die zuvor ermittelten Werte ersetzt werden.

Störung:
Hypothese:
Erwartetes Paketmuster:
Zeitpunkt:
Zeitzone:

Clienthostname:
Client-IP:
Client-MAC:
Serverhostname:
Server-IP:
Serverport:
Transportprotokoll:
Anwendungsprotokoll:
IPv4 oder IPv6:

Messpunkt 1:
Messsystem 1:
Schnittstelle 1:
Capture Filter 1:
Dateiname 1:
Startzeit 1:
Endzeit 1:
Verworfene Capture-Pakete 1:

Messpunkt 2:
Messsystem 2:
Schnittstelle 2:
Capture Filter 2:
Dateiname 2:
Startzeit 2:
Endzeit 2:
Verworfene Capture-Pakete 2:

Fehler ausgelöst um:
Auslösende Handlung:
Beobachtete Fehlermeldung:

Relevanter Datenstrom:
Relevante Frame-Nummern:
Relevante Zeitstempel:
TCP-Handshake:
DNS-Ablauf:
TLS-Handshake:
HTTP-Status:
ICMP-Fehler:
Wiederholungen:
Verbindungsabbau:

Paket verlässt Client:
Paket erreicht Server:
Server antwortet:
Antwort erreicht Client:
Festgestellte Verluststelle:
Zusätzliche Systemprotokolle:
Festgestellte Ursache:

Datenschutzprüfung:
Originaldatei geschützt gespeichert:
Reduzierte Weitergabedatei:
Aufbewahrungsfrist:
Ergebnis der Nachprüfung:

• Wurde vorab eine konkrete Hypothese formuliert?
• Sind Quelle, Ziel, Protokoll und Port bekannt?
• Wurde die richtige Schnittstelle gewählt?
• Führt die Route tatsächlich über diese Schnittstelle?
• Ist der Messpunkt für die untersuchte Verbindung geeignet?
• Wurde zwischen Capture Filter und Display Filter unterschieden?
• Wurde der Aufzeichnungsumfang begrenzt?
• Wurde der Fehlerzeitpunkt exakt dokumentiert?
• Sind die Uhren der Messsysteme synchronisiert?
• Hat der Capture-Prozess selbst Pakete verworfen?
• Wurden NIC-Offloading-Effekte berücksichtigt?
• Wurde Zwischenhop- beziehungsweise Mirror-Port-Verlust berücksichtigt?
• Wurde ein Mitschnitt der Gegenstelle erstellt?
• Wurden IPv4 und IPv6 unterschieden?
• Wurden DNS, ARP und ICMP als Begleitprotokolle berücksichtigt?
• Wurde ein fehlendes Paket nicht vorschnell als Netzwerkverlust bewertet?
• Wurde ein Wireshark-Analyseflag als Interpretation und nicht als Beweis behandelt?
• Wurden System-, Firewall- und Anwendungsprotokolle abgeglichen?
• Enthält die Datei sensible Daten?
• Wurde nur der erforderliche Ausschnitt weitergegeben?
• Wurde die Originaldatei unverändert geschützt?
• Belegen konkrete Pakete beziehungsweise Zeitstempel die festgestellte Ursache?

• Wireshark – Benutzerhandbuch:
  https://www.wireshark.org/docs/wsug_html_chunked/

• Wireshark – Capture Filters:
  https://wiki.wireshark.org/CaptureFilters

• Wireshark – Display Filters:
  https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html

• Wireshark – Display Filter Reference:
  https://www.wireshark.org/docs/dfref/

• Wireshark – Kommandozeilen-Handbücher:
  https://www.wireshark.org/docs/man-pages/

• Wireshark – Dumpcap-Handbuch:
  https://www.wireshark.org/docs/man-pages/dumpcap.html

• Wireshark – TShark-Handbuch:
  https://www.wireshark.org/docs/man-pages/tshark.html

• Wireshark – Capinfos-Handbuch:
  https://www.wireshark.org/docs/man-pages/capinfos.html

• Wireshark – Mergecap-Handbuch:
  https://www.wireshark.org/docs/man-pages/mergecap.html

• Wireshark – Editcap-Handbuch:
  https://www.wireshark.org/docs/man-pages/editcap.html

• tcpdump – Projektseite und Dokumentation:
  https://www.tcpdump.org/

• libpcap – Capture-Filter-Syntax:
  https://www.tcpdump.org/manpages/pcap-filter.7.html

• Microsoft Learn – Packet Monitor Pktmon:
  https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon

• Microsoft Learn – Pktmon-Übersicht:
  https://learn.microsoft.com/windows-server/networking/technologies/pktmon/pktmon

• Microsoft Learn – Pktmon ETL nach PCAPNG konvertieren:
  https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon-etl2pcap

• RFC 9293 – Transmission Control Protocol:
  https://www.rfc-editor.org/rfc/rfc9293.html

• RFC 8200 – Internet Protocol Version 6:
  https://www.rfc-editor.org/rfc/rfc8200.html