tcpdump und Netzwerk-Monitoring unter Debian 13 und CachyOS

Was tcpdump kann – und was nicht

tcpdump setzt auf libpcap auf und fängt Pakete auf der Ebene des Netzwerk-Interfaces ab. Der eigentliche Trick ist nicht das Ausgeben, sondern das Filtern im Kernel: Was nicht passt, wird nie in den Userspace kopiert. Deshalb kann ein einzelner Prozess auf einem 10-Gbit-Link mitschneiten, ohne die Last der Masse zu erzeugen.

Installation: Debian 13 und CachyOS

tcpdump gehört nicht zur Grundinstallation: auf unserem CachyOS-Testsystem war das Paket nicht vorhanden, und Debian 13 bringt es ebenfalls nicht mit. Beides ist schnell nachinstalliert:

# Debian 13 (Trixie)
sudo apt update && sudo apt install tcpdump

# CachyOS / Arch
sudo pacman -S tcpdump

Auf dem Testsystem läuft tcpdump 4.99.6 mit libpcap 1.11.0 – die Version verrät sich selbst, inklusive der Frage, mit welchem TLS-Stack das Binary gebaut wurde:

tcpdump --version

tcpdump version 4.99.6
libpcap version 1.11.0 (64-bit time_t, with TPACKET_V3)
OpenSSL 3.6.4 25 Aug 2026
64-bit build, 64-bit time_t

Interessant ist die Zeile with TPACKET_V3: Das ist der moderne Ringpuffer im Linux-Kernel, über den libpcap Pakete in Blöcken statt einzeln abholt. Deshalb ist das Mitschneiden heute deutlich ressourcenschonender als in der tcpdump-Zeit der 2000er.

Rechte: CAP_NET_RAW statt root

Der Rohzugriff auf das Interface ist eine Capability: CAP_NET_RAW. Ohne sie passiert genau das – ein Mitschnitt als normaler Benutzer scheitert mit einer sehr klaren Meldung:

tcpdump -nn -i enp17s0 -c 1

tcpdump: enp17s0: You don't have permission to perform this capture on that device
(Attempt to create packet socket failed - CAP_NET_RAW may be required)

Dasselbe gilt für iftop, das ebenfalls libpcap benutzt:

iftop -t -s 3

interface: enp17s0
IP address is: 192.168.178.25
MAC address is: 30:56:0f:42:50:2d
pcap_open_live(enp17s0): enp17s0: You don't have permission to perform this capture
on that device (Attempt to create packet socket failed - CAP_NET_RAW may be required)

Es gibt drei saubere Wege, das zu lösen – mit unterschiedlichen Konsequenzen:

setcap und getcap sind auf CachyOS vorhanden; getcap ist der schnellste Check, ob ein Binary die Capability trägt:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/tcpdump
getcap /usr/bin/tcpdump
/usr/bin/tcpdump cap_net_admin,cap_net_raw=eip

-Z (ausführlich --relinquish-privileges=user) greift genau dann: tcpdump startet als root, öffnet das Capture-Gerät, wechselt die Benutzerkennung – und öffnet danach erst die Ausgabedateien. So kommen Mitschnitte mit den Rechten des angegebenen Nutzers auf die Platte, während das Öffnen des Interfaces weiterhin privilegiert passiert.

Die erste Aufnahme

Vor dem Filter kommt die Schnittstelle. -D listet sie auf – auf einem Docker-Host ist die Liste länger als erwartet, weil auch die Bridges und die virtuellen Interfaces der Container auftauchen:

tcpdump -D

1.enp17s0 [Up, Running, Connected]
9.any (Pseudo-device that captures on all interfaces) [Up, Running]
10.lo [Up, Running, Loopback]
12.docker0 [Up, Disconnected]
13.wlan0 [Wireless, Not associated]
16.nflog (Linux netfilter log (NFLOG) interface) [none]
17.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
18.dbus-system (D-Bus system bus) [none]

Ein Mitschnitt startet man nie ohne Begrenzung. Die Grundform für die Diagnose ist immer dieselbe: Interface, keine Namensauflösung, ein Zähler, ein Filter.

# 20 Pakete auf allen Interfaces, ohne DNS-Lookups, ohne Byte-Grenze
sudo tcpdump -nn -i any -c 20

# Nur Loopback, mit Link-Layer-Kopf (MAC-Adressen)
sudo tcpdump -nn -e -i lo -c 10

# Direkt in eine Datei schreiben (später mit Wireshark & Co. öffnen)
sudo tcpdump -nn -i any -s 128 -w /tmp/mitschnitt.pcap

Ausgaben lesen

Ein Mitschnitt ohne Filter, aber mit -nn, sieht so aus:

tcpdump -nn -r test.pcap

22:26:40.000400 IP 192.168.178.25.41234 > 9.9.9.9.53: 6699+ A? huuu.biz. (26)
22:26:40.018400 IP 9.9.9.9.53 > 192.168.178.25.41234: 6699 1/0/0 A 203.0.113.7 (42)
22:26:40.020400 IP 192.168.178.25.52344 > 203.0.113.7.443: Flags [S], seq 1000, win 64240, length 0
22:26:40.029400 IP 203.0.113.7.443 > 192.168.178.25.52344: Flags [S.], seq 5000, ack 1001, win 64240, length 0
22:26:40.030400 IP 192.168.178.25.52344 > 203.0.113.7.443: Flags [.], ack 1, win 64240, length 0
22:26:40.033400 IP 192.168.178.25.52344 > 203.0.113.7.443: Flags [P.], seq 1:99, ack 1, win 64240, length 98
22:26:40.038400 IP 192.168.178.25 > 1.1.1.1: ICMP echo request, id 66, seq 1, length 28
22:26:40.049400 IP 1.1.1.1 > 192.168.178.25: ICMP echo reply, id 66, seq 1, length 28
22:26:40.053400 IP 192.168.178.25.60122 > 192.168.178.10.22: Flags [S], seq 2000, win 64240, length 0

Wer absolute Sequenznummern braucht, hängt -S an – dann steht in derselben Zeile seq 1001:1099, ack 5001 statt seq 1:99, ack 1. Mit -e kommt der Link-Layer-Kopf davor, inklusive MAC-Adressen und Ethertype:

tcpdump -nn -e -tttt -r test.pcap

2025-09-20 22:26:40.020400 30:56:0f:42:50:2d > a8:bb:50:c1:d2:e3, ethertype IPv4 (0x0800),
length 54: 192.168.178.25.52344 > 203.0.113.7.443: Flags [S], seq 1000, win 64240, length 0

Und wenn Nutzdaten wirklich lesbar sein sollen (HTTP im Klartext), ist -A die Abkürzung, -X die vollständige Variante mit Hexdump:

tcpdump -nn -A -r test.pcap 'tcp port 443 and tcp[13] & 8 != 0'

22:26:40.033400 IP 192.168.178.25.52344 > 203.0.113.7.443: Flags [P.], seq 1001:1099,
ack 5001, win 64240, length 98
E....4@.@.yp......q..x..........P.......GET /artikel-tcpdump-monitoring HTTP/1.1
Host: huuu.biz
User-Agent: curl/8.21.0
Accept: */*

Filter schreiben (BPF)

Filter sind der wichtigste Teil: Sie entscheiden, ob der Kernel ein Paket überhaupt nach oben kopiert. Die Bausteine sind wenige – und sie lassen sich mit and, or, not und Klammern beliebig kombinieren.

Der Handshake-Filter ist der nützlichste von allen, weil er bei jedem Verbindungsproblem die erste Frage beantwortet: Kommt überhaupt ein SYN an – und antwortet jemand? Im Testmitschnitt liefert er exakt und ausschließlich die beiden Verbindungsaufbauten:

tcpdump -nn -r test.pcap 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

22:26:40.020400 IP 192.168.178.25.52344 > 203.0.113.7.443: Flags [S], seq 1000, win 64240, length 0
22:26:40.053400 IP 192.168.178.25.60122 > 192.168.178.10.22: Flags [S], seq 2000, win 64240, length 0

Für die Praxis hilft noch ein Trick: die Ausgabe mit awk oder sort weiterverarbeiten, statt sie zu lesen. Wer wissen will, welche Adressen gerade am meisten sprechen, kommt so in einer Zeile zur Antwort:

# Top-Sprecher auf Port 443 (nach 500 Paketen abbrechen)
sudo tcpdump -nn -i any -c 500 'tcp port 443' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head

Was ein Filter wirklich tut

tcpdump kann den kompilierten Filter ausgeben – das ist die beste Erklärung dafür, warum ein Filter schnell ist und wo seine Grenzen liegen:

tcpdump -d 'tcp port 443'

Warning: assuming Ethernet
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2	jf 8
(002) ldb      [20]
(003) jeq      #0x6             jt 4	jf 19
(004) ldh      [54]
(005) jeq      #0x1bb           jt 18	jf 6
(006) ldh      [56]
(007) jeq      #0x1bb           jt 18	jf 19
(008) jeq      #0x800           jt 9	jf 19
(009) ldb      [23]
(010) jeq      #0x6             jt 11	jf 19
(011) ldh      [20]
(012) jset     #0x1fff          jt 19	jf 13
(013) ldxb     4*([14]&0xf)
(014) ldh      [x + 14]
(015) jeq      #0x1bb           jt 18	jf 16
(016) ldh      [x + 16]
(017) jeq      #0x1bb           jt 18	jf 19
(018) ret      #262144
(019) ret      #0

Das lässt sich Zeile für Zeile lesen – und erklärt drei Dinge auf einmal:

Die Länge dieses Programms ist der Grund, warum ein Filter im Kernel läuft: Der Kernel entscheidet Byte für Byte, ohne ein Paket zu kopieren, das er nicht braucht. Ein komplexer Filter (port 80 or port 443 or port 53) kostet nur wenige zusätzliche Instruktionen – der Unterschied liegt nicht im Filter, sondern in der Menge der Pakete, die er durchlässt.

Ein Tippfehler im Ausdruck wird übrigens klar gemeldet – nichts läuft stillschweigend schief:

tcpdump -nn -r test.pcap 'tcp port'
tcpdump: can't parse filter expression: syntax error

Mitschneiden mit Rotation

Für längere Mitschnitte schreibt man in Dateien. Schreiben und wieder lesen funktioniert dabei auch kombiniert – praktisch, um einen unübersichtlichen Mitschnitt auf das Wesentliche zu reduzieren:

# aus dem großen Mitschnitt nur den TLS-Verkehr herausfiltern
tcpdump -nn -r test.pcap -w nur-tls.pcap 'tcp and port 443'
# und wieder ansehen
tcpdump -nn -r nur-tls.pcap

# Ringpuffer: max. 12 Dateien à 100 MB, komprimiert – deckelt den Platz auf der Platte
sudo install -d -o tcpdump -g tcpdump -m 0700 /var/log/tcpdump
sudo tcpdump -i any -s 128 -C 100 -W 12 -z gzip -Z tcpdump \
     -w /var/log/tcpdump/cap.pcap 'not port 22'

# Oder: eine Datei pro Stunde, komprimiert – Aufräumen übernimmt ein Timer
sudo tcpdump -i any -s 128 -G 3600 -z gzip -Z tcpdump \
     -w '/var/log/tcpdump/cap-%Y%m%d-%H%M.pcap' 'udp port 53 or tcp port 853'

Mitschnitt als systemd-Dienst

Wer regelmäßig Fehlerbilder festhalten will, startet den Mitschnitt nicht von Hand, sondern als Unit. Auf Debian 13 und CachyOS ist der Ablauf identisch, weil beide systemd benutzen. Der elegante Weg kommt ohne setcap und ohne dauerhaftes root aus: systemd gibt dem Prozess genau eine Capability und wechselt vorher auf einen eigenen Benutzer.

# Benutzer und Verzeichnis
sudo useradd --system --no-create-home --shell /usr/sbin/nologin tcpdump
sudo install -d -o tcpdump -g tcpdump -m 0700 /var/log/tcpdump

# /etc/systemd/system/netcapture.service
[Unit]
Description=tcpdump-Ringmitschnitt (Netzwerkdiagnose)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/tcpdump -i any -s 128 -C 100 -W 12 -z gzip -Z tcpdump \
          -w /var/log/tcpdump/cap.pcap 'not port 22'
User=tcpdump
Group=tcpdump
AmbientCapabilities=CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_RAW
Nice=-5
IOSchedulingClass=idle
Restart=on-failure
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/log/tcpdump

[Install]
WantedBy=multi-user.target

# Aktivieren – auf beiden Distributionen gleich
sudo systemctl daemon-reload
sudo systemctl enable --now netcapture
systemctl status netcapture
journalctl -u netcapture -f

# Platzverbrauch und Dateien prüfen
du -sh /var/log/tcpdump/
ls -lt /var/log/tcpdump/ | head

Die Unit bringt drei Dinge mit, die eine Handstart-Version nicht hat: AmbientCapabilities ersetzt setcap (und übersteht Updates), Restart=on-failure fängt Abstürze ab, und IOSchedulingClass=idle sorgt dafür, dass das Schreiben der pcap-Dateien die Applikation nicht ausbremst. Wichtig ist der Filter im ExecStart: Ohne ihn schreibt der Dienst alles mit, was über das Interface läuft – inklusive SSH-Sitzungen und Passwörtern, die im Klartext übertragen werden.

Praxisrezepte

Die folgenden Rezepte decken die Fälle ab, die im Serveralltag wirklich auftreten.

Ein Rezept verdient Hervorhebung, weil es in der Praxis am häufigsten falsch gemacht wird: die Suche nach einem Verbindungsabbruch. Hier ist nicht das SYN interessant, sondern das RST – und wer testet, ob die Firewall zurücksetzt oder verwirft, sieht den Unterschied direkt im Mitschnitt:

# Setzt die Gegenseite zurück (RST) oder schweigt sie (Drop)?
sudo tcpdump -nn -i any -c 50 'tcp port 8080'
# RST sofort nach dem SYN  -> Firewall hat aktiv verworfen (REJECT)
# nichts nach dem SYN      -> Paket wird verworfen (DROP) oder Ziel ist aus

Monitoring ohne root

Für 90 % aller Fragen braucht es keinen Paketmitschnitt. Diese Werkzeuge gehören zur Grundausstattung und laufen ohne Sonderrechte, weil sie Zähler aus dem Kernel lesen:

Die Übersicht ist die schnellste erste Antwort auf „läuft alles normal?“:

ss -s

Total: 1939
TCP:   74 (estab 28, closed 27, orphaned 0, timewait 1)

Transport Total     IP        IPv6
RAW       1         0         1
UDP       67        36        31
TCP       47        37        10
INET      115       73        42

Die Zeile estab 28 ist die interessante: langsam wachsende oder nie abnehmende closed- und orphaned-Werte deuten auf Anwendungen, die Verbindungen nicht sauber schließen. Für einzelne Verbindungen liefert ss -tin die TCP-Interna – im Testsystem zum Beispiel:

ss -tin state established

cubic wscale:11,10 rto:231 rtt:30.412/0.094 ato:43 mss:1368 pmtu:1420 cwnd:10
bytes_sent:14678 bytes_acked:14679 bytes_received:9472 segs_out:368 segs_in:662
send 3598580bps pacing_rate 7197096bps delivery_rate 693136bps minrtt:29.642

Aus dieser einen Zeile lassen sich drei typische Fehlerbilder ablesen: ein hohes rtt mit kleinem cwnd (Bandbreite wird durch Latenz begrenzt), ein retrans-Feld, das nur erscheint, wenn es Retransmits gab, und ein app_limited-Marker, wenn die Anwendung selbst zu langsam Daten nachschiebt – nicht das Netz.

Die Interface-Zähler und die Kernel-Statistik sind das zweite Standbein. Die folgende Ausgabe stammt von einem Rechner, der seit dem letzten Start 1,23 GB empfangen hat – mit 3528 Verwerfungen, ein Wert, den man im Auge behalten sollte:

ip -s -s link show enp17s0

2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    RX:  bytes packets errors dropped  missed   mcast
    1226845829  896593      0    3362       0    2301
    TX:  bytes packets errors dropped carrier collsns
     138298598  386284      0       0       0       0

ethtool -S enp17s0 | head -5
NIC statistics:
     tx_packets: 386373
     rx_packets: 896593
     tx_errors: 0
     rx_errors: 0

Für die schnelle Frage „was passiert gerade auf Protokollebene?“ ist nstat -az der beste Einstieg – es zeigt absolute Zähler aus dem Kernel, ohne einen einzigen Paketmitschnitt:

nstat -az | head -12

IpInReceives                    1476152            0.0
IpInHdrErrors                   0                  0.0
IpInAddrErrors                  2                  0.0
IpForwDatagrams                 592041             0.0
IpInDiscards                    0                  0.0
IpInDelivers                    882596             0.0
IpOutRequests                   478462             0.0
IpOutNoRoutes                   0                  0.0

Interaktive Werkzeuge

Wenn man vor dem Terminal sitzt und „einfach mal sehen“ will, sind die Live-Werkzeuge schneller als jeder Mitschnitt. Sie alle brauchen außer nload und bmon die CAP_NET_RAW-Rechte – also ein sudo beim Start.

# Debian 13
sudo apt install iftop nethogs nload bmon iptraf-ng termshark bandwhich

# CachyOS / Arch
sudo pacman -S iftop nethogs nload bmon iptraf-ng termshark bandwhich

# Loslegen (iftop und nethogs brauchen die Capability)
sudo iftop -i enp17s0
sudo nethogs enp17s0
nload enp17s0

Verlauf und Auswertung

Mitschnitte sind Momentaufnahmen. Sobald die Frage „war das gestern auch schon so?“ lautet, braucht man Verlaufsdaten – und die liefern andere Werkzeuge, weil sie klein und dauerhaft mitschreiben:

# Debian 13
sudo apt install vnstat sysstat darkstat

# CachyOS / Arch
sudo pacman -S vnstat sysstat darkstat

# vnstat: Nutzung pro Stunde, Tag und Monat
sudo systemctl enable --now vnstat
vnstat -h          # Stunden
vnstat -d          # Tage
vnstat -m          # Monate
vnstat --live      # Live-Anzeige im Sekundentakt

Für die Auswertung eines Mitschnitts ist tshark das Werkzeug der Wahl, weil es dieselbe Bibliothek benutzt wie Wireshark, aber skriptbar ist:

# Verkehrsaufkommen pro Sekunde
tshark -r /var/log/tcpdump/cap.pcap -q -z io,stat,1

# Top-Gesprächspartner (TCP)
tshark -r cap.pcap -q -z conv,tcp

# Nur die DNS-Fragen auflisten
tshark -r cap.pcap -Y 'dns.flags.response == 0' -T fields -e dns.qry.name | sort | uniq -c | sort -rn

Durchsatz und Latenz messen

„Das Netz ist langsam“ ist eine Vermutung, keine Messung. Zwei Werkzeuge trennen die Ursachen sauber: iperf3 misst reinen Durchsatz zwischen zwei Endpunkten, curl zerlegt den Weg zur Antwort in Abschnitte – DNS, Verbindungsaufbau, TLS, erster Byte.

# iperf3: auf dem Server starten, auf dem Client messen
iperf3 -s
iperf3 -c server.example -t 10          # TCP, 10 Sekunden
iperf3 -c server.example -u -b 500M     # UDP mit 500 Mbit/s (Paketverlust sichtbar)

Die Latenz zerlegt curl mit -w – die folgende Ausgabe stammt von zwei Aufrufen direkt hintereinander. Der Unterschied zeigt, was DNS-Caching wirklich bringt:

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} \
tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com

dns=0.036961 connect=0.071372 tls=0.111542 ttfb=0.149867 total=0.149913   # erster Aufruf
dns=0.000828 connect=0.045902 tls=0.098911 ttfb=0.152365 total=0.152411   # direkt danach

Für die Wegstrecke zwischen zwei Hosts ist mtr der Klassiker – es kombiniert ping und traceroute über die Zeit und zeigt, an welchem Hop die Werte auseinanderlaufen:

mtr -n -c 20 server.example        # Debian: Paket mtr-tiny
mtr -n -c 20 -T -P 443 server.example   # als TCP-Test, wenn ICMP gefiltert wird

Fehlerbild → Befehl

Datenschutz und Aufbewahrung

Ein pcap ist kein technisches Artefakt, sondern eine personenbezogene Datensammlung: Es enthält IP-Adressen, Hostnamen, DNS-Anfragen, TLS-Server-Namen (SNI) – und bei unverschlüsselten Protokollen auch Inhalte wie HTTP-Header, Cookies oder E-Mail-Verkehr im Klartext.

Was hier nicht getestet wurde

Damit du einschätzen kannst, worauf die Angaben in diesem Artikel beruhen – und worauf nicht:

Fazit

tcpdump ist kein Monitoring-System, sondern ein Mikroskop. Der Unterschied entscheidet, ob man damit zwei Minuten oder zwei Stunden verbringt: Erst die Zähler (ss, nstat, vnstat, sar) zeigen, dass etwas nicht stimmt – dann zeigt tcpdump, was los ist. Und weil ein guter Filter mehr wert ist als jede Rechenleistung, gehört die Filterfrage vor die Aufnahmefrage.