tcpdump-Tutorial fürs NOC: Pflicht-Filter für 80% der Fälle

Ein tcpdump-Tutorial fürs NOC ist dann wirklich hilfreich, wenn es sich auf die Pflicht-Filter konzentriert, die in 80% der Fälle schnell Klarheit bringen: „Kommt Traffic an? Geht Traffic raus? Welche Hosts und Ports sind beteiligt? Ist es DNS, ARP, TCP-Handshake, Retransmission, Reset, ICMP oder schlicht ein falsches Interface?“ tcpdump ist dabei eines der zuverlässigsten Werkzeuge, weil es direkt auf Paketebene arbeitet und sich auch in stressigen Incidents einsetzen lässt – vorausgesetzt, Sie filtern sauber und erzeugen Captures, die später in Wireshark oder in einer forensischen Pipeline auswertbar sind. Gleichzeitig ist tcpdump gefährlich, wenn es unkontrolliert läuft: Es kann produktive Systeme belasten, Datenträger füllen oder sensible Daten mitschneiden. Dieses Tutorial zeigt deshalb nicht nur „welche Filter“, sondern auch das Minimum an Setup-Disziplin (Interface-Auswahl, Snaplen, Rotation, Zeitstempel, Buffering), damit Sie im NOC schnell verwertbare Beweise sammeln. Der Fokus liegt auf praxiserprobten Filtern (BPF) für typische Incident-Klassen: Verbindungsaufbauprobleme, sporadischer Packet Loss, ARP-/L2-Themen, DNS-Ausfälle, Firewall-/Policy-Probleme, MTU/Fragmentierung, ECMP-Teilpfadfehler und „nur ein Teil kaputt“-Symptome.

Grundlagen: tcpdump, libpcap und BPF in einem Satz

tcpdump nutzt libpcap, um Pakete auf einem Interface zu erfassen, und filtert diese Pakete mit Berkeley Packet Filter (BPF) direkt im Kernel oder nahe am Capture-Pfad – dadurch sind gute Filter nicht nur übersichtlich, sondern auch performanter als „alles mitschneiden und später filtern“. Für die offizielle Referenz sind die tcpdump-Projektseite tcpdump.org sowie die Filter-Syntax in der Manual-Seite zu pcap-filter besonders hilfreich.

Vor dem ersten Capture: Minimaler Sicherheits- und Betriebsrahmen

Im NOC zählt Geschwindigkeit, aber ohne Leitplanken wird tcpdump schnell zum Risiko. Legen Sie daher drei Dinge immer fest: Scope (was genau wird beobachtet), Dauer (wie lange) und Speicherstrategie (wohin, wie groß).

• Datenschutz und Sensibilität: Captures können personenbezogene Daten enthalten (z. B. IPs, Hostnames, Cookies, Tokens). Sammeln Sie nur, was Sie wirklich brauchen, und bewahren Sie Dateien kontrolliert auf.
• Minimales Scope: Filtern Sie früh (Host/Netz/Port), statt „alles“ zu schreiben. Das reduziert Risiko und Last.
• Zeitfenster: Lieber 2–5 Minuten gezielt während des Problems als stundenlang „ins Blaue“.

Pflicht-Setup: Diese Optionen vermeiden die häufigsten Capture-Probleme

Viele Incidents scheitern nicht an fehlenden Filtern, sondern an einem Capture, das wegen falscher Optionen unbrauchbar wird (zu kleine Snaplen, falsches Interface, keine Rotation, DNS-Auflösung im Output). Die folgenden Prinzipien sind NOC-tauglich und hersteller-/plattformneutral.

Interface-Auswahl und „ich sehe nichts“-Fehler

• Richtiges Interface: Prüfen Sie vorab, wo der Traffic wirklich läuft (Bond, VLAN-Subinterface, VRF-Device, veth, Tunnel).
• Promiscuous Mode bewusst: Auf Servern kann Promisc sinnvoll sein, in virtuellen Umgebungen aber auch verwirren (Switching/Hypervisor entscheidet, was ankommt).
• Offloading: Features wie GRO/LRO/TSO können Captures „verformen“ (große zusammengefasste Segmente). Für saubere Analysen kann temporäres Abschalten sinnvoll sein, wenn es betrieblich vertretbar ist.

Snaplen und Vollständigkeit

Wenn Sie nur Header brauchen (z. B. 5-Tuple, Flags), reicht oft eine kleinere Snaplen. Wenn Sie aber TLS-Handshake, DNS-Details oder MTU-/Fragmentthemen prüfen, ist eine größere Snaplen sicherer. Die typische NOC-Praxis ist: lieber ausreichend groß wählen, aber durch Filter und Rotation die Datenmenge kontrollieren.

Rotation statt „Disk voll“

Nutzen Sie ringförmige Dateien oder zeitbasierte Rotation, damit tcpdump nicht unendlich schreibt. Das ist der wichtigste Schutz gegen Overshoot im Incident.

Datenmenge grob abschätzen (für schnelle Entscheidungen)

Wenn Sie die erwartete Capture-Datenrate r (Byte/s) und die geplante Dauer t (s) kennen, können Sie die grobe Dateigröße G schätzen:

$G=r\cdot t$

Für NOC-Zwecke reicht diese Überschlagsrechnung, um zu entscheiden, ob Sie Snaplen reduzieren, stärker filtern oder schneller rotieren müssen.

Pflicht-Filter 1: „Nur diesen Host“ und „nur dieses Netz“

Die häufigste NOC-Frage lautet: „Ist Host A überhaupt im Verkehr sichtbar?“ Dafür brauchen Sie keine komplexen Filter, sondern saubere Scope-Filter.

• Ein Host: host 10.0.0.10
• Zwei Hosts (Kommunikation A↔B): host 10.0.0.10 and host 10.0.0.20
• Nur Quelle: src host 10.0.0.10
• Nur Ziel: dst host 10.0.0.20
• Netz: net 10.0.0.0/24

Praxisregel: Beginnen Sie in Incidents fast immer mit host oder net. Alles Weitere baut darauf auf.

Pflicht-Filter 2: „Nur dieser Port“ und „nur dieses Protokoll“

Wenn ein Service betroffen ist, grenzt Port/Protokoll extrem schnell ein. Dadurch vermeiden Sie riesige Captures und fokussieren auf den relevanten Dienst.

• Ein Port: port 443
• Quelle oder Zielport (präziser): src port 443 oder dst port 443
• Portbereich: portrange 1024-65535
• Nur TCP: tcp
• Nur UDP: udp
• Kombination Host + Port: host 10.0.0.10 and port 53

Typischer 80%-Use-Case: host X and (port 53 or port 443), um DNS- und HTTPS-Themen schnell zu trennen.

Pflicht-Filter 3: DNS-Probleme in Minuten sichtbar machen

DNS ist eine der häufigsten Ursachen für „Service down“, obwohl IP-Connectivity ok ist. DNS-Probleme zeigen sich oft als fehlende Antworten, NXDOMAIN-Fluten, falsche Server oder Timeouts.

• DNS allgemein: udp port 53 or tcp port 53
• DNS für einen Client: host 10.0.0.10 and (udp port 53 or tcp port 53)
• Nur Queries (Client→Resolver): src host 10.0.0.10 and dst port 53
• Nur Responses (Resolver→Client): dst host 10.0.0.10 and src port 53

Wenn Queries rausgehen, aber Responses fehlen, ist das entweder ein Pfad-/Firewall-/Policy-Thema oder ein Resolver-Problem. Für DNS-Hintergrund ist RFC 1035 (DNS) eine solide Referenz.

Pflicht-Filter 4: ARP, ND und „Layer-2 wirkt komisch“

Viele „L3“-Tickets sind in Wahrheit L2: falsches VLAN, ARP-Flapping, Duplicate IP, Gateway nicht erreichbar. ARP-Captures sind dafür extrem effizient.

• ARP allgemein: arp
• ARP für einen Host: arp and host 10.0.0.10
• Gratuitous ARP (Indiz für IP-Konflikt/Failover): arp[6:2] = 1 (Interpretation abhängig vom Output; in der Praxis eher grafisch in Wireshark prüfen)

Für IPv6 ist Neighbor Discovery das Pendant. Wenn Ihr NOC IPv6 betreibt, ergänzen Sie ND-Checks (ICMPv6). Eine allgemeine Einordnung liefert Neighbor Discovery.

Pflicht-Filter 5: TCP-Handshakes, SYNs, Resets und „Verbindung kommt nicht hoch“

Der Klassiker: Client meldet „Connection timeout“ oder „Connection refused“. Ein kurzer tcpdump zeigt sofort, ob SYN rausgeht, SYN/ACK zurückkommt oder RST gesendet wird.

SYN/SYN-ACK/RST: die wichtigsten Muster

• SYN geht raus, keine Antwort: Pfad/Firewall/Policy, falsche IP/Port, Server down, asymmetrischer Rückweg.
• SYN, sofort RST: Port geschlossen oder Service verweigert (oder ein Middlebox-RST).
• SYN/SYN-ACK, aber kein ACK: Rückwegproblem zum Client oder lokale Client-Firewall/Stack-Thema.

Pflicht-Filter für TCP-Flags

• Nur SYNs: tcp[tcpflags] & tcp-syn != 0
• Nur SYN ohne ACK (Initial SYN): tcp[tcpflags] & (tcp-syn|tcp-ack) = tcp-syn
• Nur RST: tcp[tcpflags] & tcp-rst != 0
• Nur FIN (saubere Beendigung): tcp[tcpflags] & tcp-fin != 0

Diese Filter sind BPF-Klassiker und funktionieren in den meisten Umgebungen zuverlässig. Für tieferen TCP-Kontext ist RFC 9293 (TCP) eine belastbare Grundlage.

Pflicht-Filter 6: ICMP – Ping ist nicht gleich Path Health

ICMP ist im NOC nützlich, aber häufig missverstanden: ICMP kann rate-limited sein, und ein Host kann ICMP blockieren, obwohl TCP/UDP funktionieren. Trotzdem ist ICMP unverzichtbar, um MTU, Unreachables und Redirects zu sehen.

• ICMP allgemein: icmp
• ICMP Destination Unreachable: icmp[0] = 3
• ICMP Fragmentation Needed (PMTUD relevant): icmp[0] = 3 and icmp[1] = 4

Gerade „Fragmentation Needed“ ist ein schneller Beweis für MTU-/PMTUD-Probleme. Für ICMP-Details eignet sich RFC 792 (ICMP) als Referenz.

Pflicht-Filter 7: DHCP – „Client bekommt keine IP“

DHCP-Probleme wirken oft wie „Netzwerk down“, sind aber meist Broadcast-/Relay-/VLAN-Themen. Ein kurzer Capture zeigt sofort DISCOVER/OFFER/REQUEST/ACK und ob ein Relay im Spiel ist.

• DHCPv4: udp port 67 or udp port 68
• DHCP für einen Client (MAC/IP-Kombinationen je nach Situation): häufig kombiniert mit host oder VLAN-spezifischem Interface

Pflicht-Filter 8: VLAN, Trunks und „ich sehe das falsche Segment“

In Switch-Umgebungen ist der VLAN-Kontext oft entscheidend. Wenn Sie auf einem Trunk mitschneiden, sollten Sie VLAN-Tags sichtbar machen (sofern Plattform und Setup es hergeben). Praktisch bedeutet das: Trunk-Capture plus Filter nach VLAN-ID, wenn unterstützt.

• 802.1Q VLAN-Frames sichtbar machen: je nach Plattform/pcap-Handling; in der Praxis häufig über den Link-Layer-Typ und Wireshark-Auswertung
• VLAN-spezifisch capturen: oft besser über das VLAN-Subinterface (z. B. eth0.123) als über Filtertricks

Wenn Sie regelmäßig VLAN-Tagged-Traffic analysieren, hilft als Hintergrund IEEE 802.1Q.

Pflicht-Filter 9: „Noise rausfiltern“ – damit Captures lesbar bleiben

Ein großer Hebel im NOC ist das Entfernen typischer Hintergrundprotokolle, die das Bild vernebeln: SSH-Management, Monitoring-Polls, Chatty-Service-Discovery. Der Trick ist, nicht zu aggressiv zu filtern, damit Sie nicht aus Versehen das Problem entfernen.

• Alles außer SSH: not port 22
• Ohne Broadcast/Multicast (vorsichtig einsetzen, weil DHCP/ARP/ND betroffen sein können): not broadcast and not multicast
• Ohne NTP (wenn irrelevant): not port 123

Praxisregel: Noise-Filter erst dann ergänzen, wenn Sie sicher sind, dass das Problem nicht in genau diesen Protokollen steckt.

Pflicht-Filter 10: „Nur ein Teil kaputt“ – ECMP, asymmetrisches Routing, Firewall-State

Wenn nur manche Verbindungen funktionieren, liegt die Ursache häufig in Teilpfaden (ECMP/LAG), asymmetrischem Routing oder stateful Firewalls. tcpdump kann solche Fälle sichtbar machen, wenn Sie die Richtung und die Return-Flows bewusst betrachten.

Asymmetrie sichtbar machen

• Einwegverkehr: Sie sehen Requests, aber keine Responses (z. B. SYN ohne SYN/ACK, DNS Query ohne Response).
• Return Path fehlt: Responses tauchen auf einem anderen Interface auf oder gar nicht am Capture-Punkt.
• Stateful Firewall: Einwegverkehr endet oft in Drops, weil der Rückweg nicht durch dasselbe Device läuft.

Praktischer Filteransatz für „Request vs. Response“

• Requests (Client→Server): src host CLIENT and dst host SERVER
• Responses (Server→Client): src host SERVER and dst host CLIENT
• Beides, aber portbegrenzt: (host CLIENT and host SERVER) and port 443

Capture-Qualität: Drei Einstellungen, die später Stunden sparen

Ein NOC-Capture ist dann wertvoll, wenn er später reproduzierbar ausgewertet werden kann. Drei Disziplinen sind dafür entscheidend.

• Keine Namensauflösung im Capture: DNS-Lookups im Output können verzögern und Ergebnisse verfälschen. Nutzen Sie stattdessen IPs und lösen später auf.
• Saubere Zeitstempel: Präzise Zeitstempel sind für Korrelation mit Logs, Metrics und Firewall-Events entscheidend.
• PCAP statt nur Text: Textausgabe ist gut für Live-Diagnose, PCAP ist Pflicht für tiefe Analyse (Wireshark, Zeek, IDS).

Für die praktische Auswertung ist Wireshark das Standardwerkzeug, und die tcpdump-Optionen sind über tcpdump manpage zuverlässig dokumentiert.

Die 80%-Checkliste: Schnellstart-Filter nach Incident-Typ

Im Betrieb hilft eine kompakte Zuordnung „Incident-Typ → Filter“. Die folgenden Kombinationen decken typische NOC-Fälle mit minimalem Denkaufwand ab.

Service wirkt down (Web/API)

• host CLIENT and host SERVER and (tcp port 443 or tcp port 80)
• tcp[tcpflags] & (tcp-syn|tcp-rst) != 0 (Handshake/Refusal schnell sehen)

DNS-Resolution kaputt

• host CLIENT and (udp port 53 or tcp port 53)
• src host CLIENT and dst port 53 (Queries)
• dst host CLIENT and src port 53 (Responses)

IP-Konflikt oder L2 flapping vermutet

• arp and host 10.0.0.10
• bei IPv6 ergänzend ND/ICMPv6 auf dem betroffenen Segment

MTU/PMTUD-Probleme („kleine Pakete ok, große kaputt“)

• icmp and (icmp[0] = 3 and icmp[1] = 4)
• zusätzlich Traffic des betroffenen Dienstes (z. B. host A and host B and port 443)

DHCP klappt nicht

• udp port 67 or udp port 68

Sporadische Timeouts

• host A and host B (Scope klein halten)
• tcp[tcpflags] & tcp-rst != 0 (Resets)
• bei Verdacht auf Netzprobleme: parallel Interface-Drops/Errors prüfen (Monitoring/Telemetry)

Typische Fehler im NOC und wie Sie sie vermeiden

• Zu breit capturen: führt zu riesigen Dateien und dennoch wenig Erkenntnis. Lösung: erst Host/Port, dann erweitern.
• Falsches Interface: Capture ist „leer“. Lösung: Pfad klären (Bond/VLAN/Tunnel) und mit kleinem Testtraffic verifizieren.
• Snaplen zu klein: wichtige Felder fehlen. Lösung: Snaplen an Use-Case anpassen, lieber rotieren als amputieren.
• Interpretationsfehler bei Asymmetrie: „Ich sehe keine Antworten, also droppt das Netz.“ Lösung: Return Path/Firewall-State/ECMP berücksichtigen.
• Capture als alleinige Wahrheit: Offloading, SPAN/ERSPAN-Drops, Sampling können Bild verfälschen. Lösung: immer mit Logs, Countern und Flow-Daten korrelieren.

Outbound-Quellen für vertiefendes Verständnis

Für die offizielle Dokumentation von Optionen und Ausgabeformaten ist die tcpdump manpage die wichtigste Referenz. Für die Filter-Syntax und viele der hier genannten Pflicht-Filter ist pcap-filter besonders relevant. Für eine fundierte TCP-Einordnung (Handshake, Flags, Zustände) eignet sich RFC 9293 (TCP), und für DNS-Grundlagen RFC 1035 (DNS). Für die visuelle Analyse und Filterung nach dem Capture ist Wireshark das etablierte Standardwerkzeug im NOC- und Incident-Kontext.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.