3.16 Paketmitschnitt mit Wireshark, tcpdump, Dumpcap und Pktmon Ein Paketmitschnitt zeigt, welche Netzwerkpakete an einem bestimmten Messpunkt tatsächlich sichtbar sind. Damit lassen sich Vermutungen durch überprüfbare Beobachtungen ersetzen. Ein Mitschnitt beantwortet jedoch nur Fragen über den gewählten Messpunkt. Ein dort fehlendes Paket kann bereits vorher verloren gegangen sein, während ein sichtbares Paket hinter dem Messpunkt weiterhin verworfen werden kann. Die zentralen Fragen dieser Seite lauten: Welcher Datenfluss muss untersucht werden, an welchem Punkt muss dafür aufgezeichnet werden und welches Paketmuster würde die jeweilige Hypothese bestätigen oder widerlegen? 1. Sicherheits- und Aktionskennzeichnungen Kennzeichnung Bedeutung [RO] Rein lesender Befehl, der normalerweise keine Konfiguration verändert [TEST] Aktive Diagnose beziehungsweise Paketaufzeichnung [PRIV] Administrator- oder Root-Rechte können erforderlich sein [FILE] Der Befehl schreibt Ausgaben in eine Datei [SENS] Die Ausgabe kann sensible Informationen enthalten [CHANGE] Der Befehl verändert eine Konfiguration [DISRUPT] Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen 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. 2. Paketmitschnitt und Protokollierung unterscheiden Datenquelle Inhalt Paketmitschnitt Tatsächlich sichtbare Netzwerkframes beziehungsweise Pakete Betriebssystemprotokoll Interpretation und Ereignisse des Betriebssystems Firewallprotokoll Regelentscheidung wie Allow, Drop oder Reject Anwendungsprotokoll Verarbeitung innerhalb der Anwendung Proxyprotokoll Client-, Ziel-, Backend- und HTTP-Informationen Switchzähler Fehler, Drops, Auslastung und Portstatus Controllerprotokoll WLAN-, VPN- oder Infrastrukturereignisse Flow-Daten Zusammengefasste Informationen über Netzwerkflüsse SNMP-Messwert Zähler und Status eines Netzwerkgeräts 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. 3. Datenfluss vor der Aufzeichnung definieren 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. 4. Den richtigen Messpunkt auswählen 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. 5. Einseitigen und doppelseitigen Mitschnitt unterscheiden 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. 6. Zeit und Zeitzone synchronisieren Für den Vergleich mehrerer Mitschnitte und Protokolle müssen Zeit und Zeitzone bekannt sein. Betriebssystem Lokale Zeit Windows [RO] Get-Date -Format o Linux [RO] date --iso-8601=seconds macOS [RO] date "+%Y-%m-%dT%H:%M:%S%z" 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. 7. Aufzeichnungsschnittstelle eindeutig bestimmen 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: Betriebssystem Befehl Windows [RO] Find-NetRoute -RemoteIPAddress ZIEL_IP Linux [RO] ip route get ZIEL_IP macOS [RO] route -n get ZIEL_IP 8. Besonderheiten der Schnittstelle any unter Linux 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. 9. Promiscuous Mode und WLAN Monitor Mode unterscheiden 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. Modus Typische Verwendung Normaler WLAN-Clientmodus Verkehr des eigenen Clients untersuchen Promiscuous Mode Zusätzliche sichtbare Ethernetframes erfassen Monitor Mode WLAN-Management-, Kontroll- und Datenframes untersuchen Switch Port Mirroring Verkehr ausgewählter Switchports oder VLANs spiegeln Network TAP Physischer Messpunkt in einer Verbindung Monitor Mode kann die normale WLAN-Verbindung unterbrechen und wird nicht von jeder Hardware, jedem Treiber oder Betriebssystem unterstützt. 10. Grenzen eines Mitschnitts im geswitchten Netzwerk 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. 11. Capture Filter und Display Filter unterscheiden Filterart Zeitpunkt Wirkung Capture Filter während der Aufzeichnung Nur passende Pakete werden gespeichert Display Filter nach beziehungsweise während der Anzeige Alle gespeicherten Pakete bleiben erhalten, nur die Ansicht wird gefiltert 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. 12. Wichtige Capture Filter Aufgabe Capture Filter Einzelner Host host 192.0.2.20 Quelle src host 192.0.2.20 Ziel dst host 192.0.2.20 Zwei Hosts host 192.0.2.20 and host 192.0.2.53 Gesamtes IPv4-Netz net 192.0.2.0/24 TCP tcp UDP udp ICMP icmp ICMPv6 icmp6 TCP-Port 443 tcp port 443 UDP-Port 53 udp port 53 Quellport src port 443 Zielport dst port 443 DNS über TCP oder UDP port 53 DHCPv4 udp port 67 or udp port 68 DHCPv6 udp port 546 or udp port 547 ARP arp Host und Port host 192.0.2.20 and tcp port 443 Zwei Ports tcp port 80 or tcp port 443 Verkehr ohne SSH not tcp port 22 Capture Filter verwenden die Syntax der Paketfilterbibliothek. Vor produktiven Aufzeichnungen sollte die lokale Unterstützung geprüft werden. 13. Wichtige Wireshark Display Filter Aufgabe Display Filter IPv4-Adresse ip.addr == 192.0.2.20 IPv6-Adresse ipv6.addr == 2001:db8::20 Zwei IPv4-Systeme ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53 TCP-Port tcp.port == 443 UDP-Port udp.port == 53 DNS dns DHCPv4 dhcp DHCPv6 dhcpv6 ARP arp ICMP icmp ICMPv6 icmpv6 HTTP-Anfragen http.request HTTP-Antworten http.response HTTP-Status 502 http.response.code == 502 TLS-Handshake tls.handshake TCP-SYN tcp.flags.syn == 1 Erstes SYN ohne ACK tcp.flags.syn == 1 && tcp.flags.ack == 0 TCP-Reset tcp.flags.reset == 1 TCP-FIN tcp.flags.fin == 1 Wiederholungen tcp.analysis.retransmission Doppelte ACKs tcp.analysis.duplicate_ack Out-of-Order tcp.analysis.out_of_order Zero Window tcp.analysis.zero_window Vermutetes verlorenes Segment tcp.analysis.lost_segment 14. Linux mit tcpdump aufzeichnen 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. 15. macOS mit tcpdump aufzeichnen 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. 16. Windows mit Dumpcap aufzeichnen 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. 17. Windows mit Pktmon aufzeichnen 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. 18. Pktmon-Drop-Erkennung richtig behandeln 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. 19. Ringspeicher mit Dumpcap verwenden 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. 20. Größenbegrenzten Ringspeicher mit tcpdump verwenden 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 21. Capture-Länge und vollständige Pakete berücksichtigen 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: Kurze Capture-Länge Vollständige Pakete weniger Speicherbedarf höhere Datenmenge geringeres Datenschutzrisiko mehr Protokolldetails Nutzdaten möglicherweise abgeschnitten Nutzdaten möglicherweise vollständig enthalten Headeranalyse häufig möglich Anwendungsanalyse eher möglich Für eine reine Headeranalyse sollte geprüft werden, ob eine begrenzte Capture-Länge ausreicht. 22. tcpdump-Datei nachträglich lesen 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. 23. TShark für automatisierte Auswertung verwenden 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 24. Capture Filter und Display Filter bei TShark verwenden 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. 25. Dateien mit capinfos untersuchen 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. 26. Mitschnitte mit mergecap zusammenführen 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. 27. Mitschnitte mit editcap begrenzen 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. 28. Paketnamen und Frame-Nummern richtig verwenden In Wireshark sind wichtige Spalten: Spalte Bedeutung No. Frame-Nummer innerhalb der geöffneten Datei Time Zeitstempel beziehungsweise relative Zeit Source Quelladresse Destination Zieladresse Protocol erkannter Protokolldissektor Length Frame- beziehungsweise Paketlänge Info zusammengefasste Protokollinformation 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. 29. Wireshark Follow Stream verwenden 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. 30. TCP-Handshake analysieren 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 Paketmuster Typische Interpretation SYN, SYN-ACK, ACK TCP-Verbindung aufgebaut Wiederholte SYN ohne Antwort Drop, Verlust, falscher Rückweg oder Ziel nicht erreichbar SYN gefolgt von RST/ACK Ziel erreichbar, Port geschlossen oder aktiv abgelehnt SYN-ACK erreicht Client, ACK fehlt Clientseite oder Rückweg des ACK prüfen Handshake erfolgreich, danach RST Anwendung, Proxy oder Sicherheitskomponente beendet Verbindung Handshake erfolgreich, keine Nutzdaten Anwendung wartet oder Protokollablauf fehlerhaft 31. TCP-Verbindungsabbau analysieren 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 Beobachtung Mögliche Bedeutung FIN/ACK-Austausch geordneter Verbindungsabbau RST vom Client Clientanwendung oder lokales System bricht ab RST vom Server Serveranwendung oder Serverstack bricht ab RST von unbekannter Zwischenadresse Firewall, Proxy oder anderes Zwischensystem möglich FIN nach Anwendungserfolg häufig normal RST direkt nach TLS-Start TLS-, Richtlinien- oder Protokollproblem möglich Die Quelladresse eines RST allein beweist nicht immer seine tatsächliche Herkunft, da Sicherheitsgeräte Pakete im Namen eines Endpunkts erzeugen können. 32. TCP-Wiederholungen vorsichtig interpretieren 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. 33. NIC-Offloading und ungewöhnliche Paketgrößen berücksichtigen 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. 34. ARP und IPv6 Neighbor Discovery analysieren 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. 35. DHCPv4-Ablauf analysieren 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 Fehlendes Paket Mögliche Eingrenzung Kein Discover sichtbar Client oder falsche Schnittstelle prüfen Discover, kein Offer DHCP-Server, Relay, VLAN oder Filter prüfen Offer sichtbar, Client fordert nicht an Client, Auswahl oder fehlerhaftes Angebot Request, kein ACK Server, Adresspool, Richtlinie oder Relay DHCP NAK Adresse oder Netzzuordnung wird abgelehnt Mehrere unterschiedliche Offers mehrere DHCP-Server vorhanden 36. DNS-Ablauf analysieren 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: Code Bedeutung NOERROR Anfrage wurde ohne DNS-Fehler verarbeitet NXDOMAIN Name existiert laut Antwort nicht SERVFAIL Resolver konnte Anfrage nicht erfolgreich bearbeiten REFUSED Server verweigert die Anfrage 37. TLS-Handshake analysieren 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. 38. HTTP- und Proxyfehler analysieren 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. 39. ICMP- und ICMPv6-Fehler auswerten 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. 40. NAT-, Proxy- und Containerpfade vergleichen 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. 41. Virtuelle Maschinen und Container richtig erfassen 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. 42. Verschlüsselung und ihre Analysegrenzen 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. 43. Fehler bei der Aufzeichnung selbst erkennen 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. 44. Aussagekräftige Dateinamen verwenden 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: 45. Sichere Aufbewahrung und Weitergabe Vor einer Weitergabe: Originaldatei geschützt aufbewahren. Nur relevanten Zeitbereich extrahieren. Nur benötigte Pakete übernehmen. Nutzdaten auf sensible Inhalte prüfen. DNS-Namen, Adressen und Identitäten bewerten. Unternehmensrichtlinien beachten. Empfänger und Übertragungsweg festlegen. Aufbewahrungsfrist dokumentieren. Nicht mehr benötigte Kopien kontrolliert löschen. Eine PCAP-Datei ist kein harmloser Screenshot. Sie kann vollständige Kommunikationsinhalte enthalten. 46. Systematischer Ablauf einer Paketaufzeichnung Schritt Aufgabe Leitfrage 1 Fehlerhypothese formulieren Welches Paketmuster wird erwartet? 2 Datenfluss dokumentieren Welche Quelle kommuniziert mit welchem Ziel? 3 Messpunkt auswählen Wo muss das Paket sichtbar sein? 4 Schnittstelle bestimmen Über welches Interface führt die Route? 5 Zeit synchronisieren Können mehrere Datenquellen verglichen werden? 6 Datenschutzumfang festlegen Welche Daten dürfen aufgezeichnet werden? 7 Capture Filter wählen Welche Pakete werden wirklich benötigt? 8 Speicherbegrenzung planen Dauer, Größe oder Ringspeicher? 9 Aufzeichnung starten Läuft sie auf der richtigen Schnittstelle? 10 Fehler einmal reproduzieren Ist der Zeitpunkt exakt dokumentiert? 11 Aufzeichnung beenden Wurde unnötige weitere Erfassung vermieden? 12 Capture-Verluste prüfen Hat das Messsystem Pakete verworfen? 13 Display Filter anwenden Welcher einzelne Datenfluss ist relevant? 14 Protokollablauf untersuchen Wo weicht Ist vom Soll ab? 15 Gegenstelle vergleichen Ist Verlust oder Verzögerung lokalisierbar? 16 Systemprotokolle abgleichen Warum wurde das Paket abgelehnt? 17 Ergebnis dokumentieren Welche Frames belegen die Ursache? 18 Daten sichern oder bereinigen Welche Aufbewahrung ist erforderlich? 47. Kompakte Befehlstabelle Aufgabe Windows Linux macOS Schnittstellen anzeigen [RO] dumpcap -D [RO] tcpdump -D [RO] tcpdump -D Route zum Ziel [RO] Find-NetRoute -RemoteIPAddress IP [RO] ip route get IP [RO] route -n get IP Gesamte Aufzeichnung [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap Hostfilter [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "host IP" -w host.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap Portfilter [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "tcp port 443" -w https.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap 60 Sekunden [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -a duration:60 -w test.pcapng [TEST][PRIV][FILE][SENS] timeout 60 sudo tcpdump -i INTERFACE -nn -w test.pcap – Verfügbarkeit von timeout prüfen Beendigung kontrolliert per Tastatur oder Werkzeugoption planen Ringspeicher [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -b duration:300 -b files:12 -w ring.pcapng [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap PCAP lesen [RO][SENS] tshark -r capture.pcapng [RO][SENS] tcpdump -nn -r capture.pcap [RO][SENS] tcpdump -nn -r capture.pcap Display Filter [RO][SENS] tshark -r capture.pcapng -Y "tcp.port == 443" [RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443" [RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443" Dateiinformationen [RO][SENS] capinfos capture.pcapng [RO][SENS] capinfos capture.pcap [RO][SENS] capinfos capture.pcap Windows-Inbox-Capture [TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl Nicht zutreffend Nicht zutreffend Pktmon beenden [TEST][PRIV][FILE][SENS] pktmon stop Nicht zutreffend Nicht zutreffend Pktmon konvertieren [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng Nicht zutreffend Nicht zutreffend NUMMER , INTERFACE und IP müssen durch die zuvor ermittelten Werte ersetzt werden. 48. Dokumentationsvorlage für Paketmitschnitte 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: 49. Kontrollfragen nach der Analyse 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? 50. Quellen und weiterführende Dokumentation 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