Sophos Firewall tcpdump sicher einsetzen

tcpdump ist das richtige Werkzeug, wenn man auf der Sophos Firewall genauer sehen muss, welche Pakete wirklich ankommen, über welches Interface sie laufen und ob ein Problem vor, auf oder hinter der Firewall entsteht. Es ergänzt Log Viewer, WebAdmin Packet Capture und Service-Logs, ersetzt sie aber nicht.

Für schnelle Browser-Analysen ist Sophos Firewall Packet Capture im WebAdmin verwenden oft angenehmer. Für längere Mitschnitte, sehr genaue Filter, PCAP-Dateien oder Supportfälle ist tcpdump über SSH meist besser geeignet.

⚠️ Wichtig: Paketmitschnitte können sensible Daten enthalten: interne IP-Adressen, Hostnamen, Benutzernamen, DNS-Anfragen, Zertifikatsdetails oder unverschlüsselte Nutzdaten. Deshalb sollten sie eng gefiltert, nur so lange wie nötig aufgezeichnet, dokumentiert und nur über sichere Kanäle weitergegeben werden. Ein ungefilterter Mitschnitt auf any kann auf produktiven Firewalls sehr viele Daten erzeugen.

Werkzeugwahl und Voraussetzungen

Bevor man tcpdump startet, sollte klar sein, ob wirklich ein CLI-Mitschnitt benötigt wird. Viele Fragen lassen sich schneller mit Log Viewer oder Packet Capture im WebAdmin beantworten. tcpdump wird dann wertvoll, wenn ein längerer Mitschnitt, ein sehr genauer Filter oder eine PCAP-Datei benötigt wird.

Welcher Artikel passt?

tcpdump ist nicht der erste Schritt für jede Analyse. Je nach Frage ist ein anderer Einstieg schneller:

• Schnell im WebAdmin sehen, ob Pakete ankommen, weitergeleitet oder verworfen werden: Sophos Firewall Packet Capture im WebAdmin verwenden.
• Firewall-Regel mit Log Viewer, Policy tester und Packet Capture validieren: Sophos Firewall-Regel sauber testen.
• Fokus auf Drop, Violation, Rule ID, NAT ID oder Drop-Gründe: Sophos Firewall verworfene Pakete analysieren.
• Passende lokale Logdatei für VPN, Web, IPS, GUI oder Systemdienste suchen: Sophos Firewall Service-Logs richtig zuordnen.
• SSH oder Advanced Shell vorbereiten: Sophos Firewall per SSH verbinden.
• Supportfall mit /log-Archiv, IPsec-Daten oder Debug-Logs vorbereiten: Sophos Firewall Logs für Support und Analyse sichern.
• PCAP-Datei, langer Mitschnitt oder sehr genaue CLI-Filter nötig: Dieser Artikel.

Diese Trennung spart Zeit und reduziert Risiko. tcpdump liefert starke Paketdaten, aber keine Sophos-spezifische Policy-Entscheidung. Rule ID, NAT ID, Drop-Grund, Web Policy, IPS oder SSL/TLS inspection müssen parallel im Log Viewer, im WebAdmin Packet Capture oder in den passenden Logdateien geprüft werden.

Voraussetzungen

Für diese Anleitung benötigt man:

• Administrativen Zugriff auf die Sophos Firewall.
• SSH-Zugriff auf die Firewall oder Zugriff auf die Advanced Shell.
• Die Quell-IP, Ziel-IP, Zielport und das betroffene Protokoll.
• Genügend freien Speicherplatz, wenn eine PCAP-Datei geschrieben wird.
• Wireshark oder ein anderes Analysewerkzeug auf dem Admin-Client, wenn eine PCAP-Datei ausgewertet werden soll.

Wie man SSH sicher vorbereitet, steht in Sophos Firewall per SSH verbinden. Für allgemeine CLI-Grundlagen passt zusätzlich Sophos Firewall CLI Troubleshooting: wichtige Befehle.

Wann tcpdump der richtige nächste Schritt ist

tcpdump sollte nicht automatisch der erste Schritt sein. Wenn man nur wissen möchte, welche Firewall-Regel, NAT-Regel, Web Policy oder SSL/TLS-inspection-Regel entschieden hat, ist der Log Viewer schneller und besser lesbar. Wenn man im Browser sehen möchte, ob einzelne Pakete ankommen, weitergeleitet oder verworfen werden, reicht oft Packet Capture im WebAdmin.

tcpdump wird vor allem dann sinnvoll, wenn einer dieser Punkte zutrifft:

• Der Mitschnitt soll als PCAP-Datei in Wireshark oder durch Support ausgewertet werden.
• Der WebAdmin-Capture ist zu kurz, zu unübersichtlich oder der Buffer läuft voll.
• Der Test muss während eines Wartungsfensters, eines Telefonats oder eines reproduzierbaren Benutzerfehlers länger laufen.
• Es braucht präzise CLI-Filter, zum Beispiel für VoIP, DNS, IPsec, mehrere Hosts oder Portbereiche.
• Der relevante Traffic soll zuerst auf any und danach auf einem konkreten Interface verglichen werden.

Wichtig ist die Erwartung: tcpdump zeigt Pakete, aber keine Sophos-spezifische Rule ID, NAT ID, Drop Reason oder Web-Policy-Entscheidung. Diese Informationen müssen parallel über Log Viewer, WebAdmin Packet Capture oder passende Logdateien geprüft werden.

Advanced Shell oder Device Console?

tcpdump kann auf Sophos Firewall in zwei CLI-Kontexten auftauchen. Die Sophos Device Console enthält einen eigenen tcpdump-Befehl mit Sophos-Syntax und Optionen wie filedump. Die Advanced Shell bietet zusätzlich das vertraute Linux-nahe tcpdump, das in Supportfällen oft praktischer ist, weil man mit Prozesssteuerung, scp, /tmp und weiteren Shell-Werkzeugen arbeiten kann.

Diese Unterscheidung ist wichtig:

• Device Console: Geeignet für den Sophos-CLI-Befehl tcpdump. Vor der Ausführung sollte man mit Tab oder ? die Syntax prüfen. Eine Ausgabe per filedump landet gemäss Sophos unter /tmp.
• Advanced Shell: Geeignet für klassische Shell-Workflows mit tcpdump, ps, df, grep, scp, Dateizugriff und gezieltem Stoppen laufender Prozesse.

Dieser Artikel verwendet bewusst die Advanced Shell, weil PCAP-Dateien, Hintergrundprozesse, scp und Aufräumarbeiten dort nachvollziehbarer zusammenhängen. Wenn man tcpdump in der Device Console nutzt, gelten dieselben Grundregeln: enge Filter, kurzer Zeitraum, Speicherplatz prüfen und Ergebnis parallel mit Log Viewer oder WebAdmin Packet Capture abgleichen.

Wenn unklar ist, in welcher Konsole man sich befindet, hilft die Übersicht Sophos Firewall Troubleshooting: Services und Logs.

Capture vorbereiten

Ein guter Mitschnitt beginnt nicht mit dem Befehl, sondern mit einer klaren Fragestellung. Je genauer Quelle, Ziel, Port und Testzeitpunkt bekannt sind, desto kleiner und nützlicher wird das Ergebnis.

Vor dem Start eingrenzen

Vor einem Capture sollte man die Analyseparameter notieren:

• Source IP: zum Beispiel 172.16.10.25.
• Destination IP: zum Beispiel 198.51.100.20.
• Protokoll: zum Beispiel TCP.
• Destination Port: zum Beispiel 443.
• Erwartetes Interface: LAN, WAN oder VPN-Interface.
• Testzeitpunkt: genaue Uhrzeit mit Zeitzone.
• Erwartetes Ergebnis: Verbindung erlaubt, blockiert, DNAT, SNAT, VPN oder Drop.
• Parallelprüfung: Log Viewer, Packet Capture, Service-Log oder Support-Ticket.

Je enger der Filter, desto besser ist das Ergebnis. Ein Capture ohne Filter ist meistens nur auf sehr ruhigen Firewalls sinnvoll.

Der Test sollte reproduzierbar sein. Wenn mehrere Personen gleichzeitig Einstellungen ändern oder mehrere Clients testen, wird der Mitschnitt schwer interpretierbar. Besser ist ein einzelner Testclient, ein enger Zeitrahmen und eine klare Frage: Kommt das Paket an? Geht es raus? Kommt die Antwort zurück? Welche Regel, NAT-Regel oder Policy war parallel sichtbar?

Für Regeltests passt ergänzend Sophos Firewall Regel testen mit Log Viewer und Packet Capture. Wenn es vor allem um Drop, Violation, Rule ID oder NAT ID geht, ist Sophos Firewall verworfene Pakete analysieren der bessere Anschlussartikel.

tcpdump ausführen

Für den ersten Test reicht meistens ein Live-Capture. Wenn der Mitschnitt später analysiert oder an Support weitergegeben werden soll, schreibt man eine PCAP-Datei. Hintergrundprozesse sollten nur verwendet werden, wenn der Test nicht direkt in derselben SSH-Sitzung begleitet werden kann.

tcpdump live ausführen

Für einen ersten Live-Check reicht oft ein Host-Filter:

tcpdump -i any -nn host 198.51.100.20

Die Parameter:

• -i any: auf allen Interfaces mitschneiden.
• -nn: keine DNS- oder Portnamen-Auflösung durchführen.
• host 198.51.100.20: nur Pakete von oder zu dieser IP anzeigen.

Für einen Webtest ist ein zusätzlicher Portfilter sinnvoll:

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Filterausdrücke mit and, or oder not sollten in einfache Anführungszeichen gesetzt werden. Dadurch bleibt der Ausdruck sauber zusammen und wird nicht von der Shell zerlegt.

Häufige Filterbeispiele

• Bestimmter Host: tcpdump -i any -nn 'host 198.51.100.20'
• Bestimmte Source IP: tcpdump -i any -nn 'src host 172.16.10.25'
• Bestimmte Destination IP: tcpdump -i any -nn 'dst host 198.51.100.20'
• Bestimmtes Netz: tcpdump -i any -nn 'net 172.16.10.0/24'
• Bestimmter Port: tcpdump -i any -nn 'port 443'
• Host und Port: tcpdump -i any -nn 'host 198.51.100.20 and port 443'
• ICMP / Ping: tcpdump -i any -nn 'proto ICMP'
• DNS: tcpdump -i any -nn 'port 53'
• Alle Ports ausser SSH: tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

Bei VPN-, VLAN- oder Routing-Problemen kann es sinnvoll sein, nicht auf any, sondern auf ein konkretes Interface einzugrenzen. Die Interface-Namen müssen zur jeweiligen Firewall passen. Praktisch ist oft diese Reihenfolge:

1. Kurz auf any prüfen, ob der erwartete Host oder Port überhaupt sichtbar ist.
2. Danach auf dem vermuteten Eingangsinterface mitschneiden.
3. Danach auf dem vermuteten Ausgangsinterface mitschneiden.
4. Die drei Beobachtungen mit Log Viewer, NAT ID, Rule ID oder Drop Reason abgleichen.

So erkennt man schneller, ob der Traffic die Firewall nicht erreicht, auf der Firewall gestoppt wird oder die Antwort auf dem Rückweg fehlt.

Mitschnitt begrenzen

Ein Capture sollte begrenzt werden, damit er nicht unnötig lange läuft.

Mit -c stoppt tcpdump nach einer festen Anzahl Pakete:

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

Für kurze Tests ist das oft sauberer als ein Hintergrundprozess. Man startet den Capture, reproduziert das Problem und erhält danach automatisch die Ausgabe.

PCAP-Datei schreiben

Wenn der Mitschnitt später in Wireshark oder durch Support analysiert werden soll, schreibt man eine PCAP-Datei nach /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Wichtige Parameter:

• -s 0: vollständige Pakete mitschneiden.
• -w /tmp/sophos-capture.pcap: Ausgabe in eine PCAP-Datei schreiben.
• -nn: Namensauflösung deaktivieren.

-s 0 ist hilfreich, wenn ein vollständiger Mitschnitt benötigt wird. Gleichzeitig steigt damit das Datenschutzrisiko, weil mehr Paketinhalt erfasst wird. Für reine Flow- oder Header-Fragen reicht oft ein Live-Capture ohne PCAP-Datei oder ein kurzer Mitschnitt mit enger Filterung.

Vor grösseren Mitschnitten sollte der freie Speicherplatz geprüft werden:

df -h /tmp
df -h /var

Wenn das Problem nur kurz reproduziert werden muss, kann auch hier -c ergänzt werden:

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Nach dem Start sollte man den Test sofort reproduzieren und den Capture nicht unnötig weiterlaufen lassen. Ein PCAP, der fünf Minuten zu viel enthält, ist nicht nur grösser, sondern enthält oft auch mehr sensible Nebeninformationen.

Für Supportfälle sollte der Dateiname einen neutralen Kontext enthalten, aber keine Kundennamen, Benutzernamen oder vertraulichen Hostnamen. Besser sind Namen wie /tmp/ticket-12345-wan-443.pcap oder /tmp/vpn-test-20260629.pcap.

Hintergrundprozess starten und stoppen

Manchmal muss ein Capture laufen, während ein anderer Test ausgeführt wird. Dann kann tcpdump im Hintergrund gestartet werden.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Laufende Jobs anzeigen:

jobs

Job beenden:

kill %1

Wenn mehrere tcpdump-Prozesse laufen oder der Job nicht mehr in der aktuellen Shell sichtbar ist, zuerst Prozesse prüfen:

ps | grep tcpdump

Danach gezielt den passenden Prozess beenden. killall tcpdump sollte nur verwendet werden, wenn klar ist, dass keine anderen wichtigen Mitschnitte laufen.

Nach dem Stoppen sollte man prüfen, ob die PCAP-Datei geschrieben wurde und eine plausible Grösse hat:

ls -lh /tmp/*.pcap

Wenn ein Hintergrund-Capture für einen Supporttermin geplant ist, sollte vorher feststehen, wer ihn startet, wer ihn stoppt und wo die Datei danach landet. Ein vergessener Mitschnitt ist kein seltenes Troubleshooting-Problem, sondern ein vermeidbares Betriebsrisiko.

Beispiel: VoIP oder 3CX analysieren

Bei VoIP-Problemen sind SIP-Signalisierung und RTP-Medienstrom oft getrennt zu betrachten. Ein einzelner Capture auf port 5060 zeigt nur einen Teil des Problems.

Für einen ersten 3CX-Test kann man den PBX-Host mitschneiden:

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

Wenn der Traffic zu breit ist, kann man gezielter auf SIP eingrenzen:

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

Für Audio-Probleme muss zusätzlich der tatsächlich verwendete RTP-Portbereich geprüft werden. Dieser hängt von der Telefonanlage und deren Konfiguration ab.

Bei Sophos Firewall VoIP-Themen sollte zusätzlich Sophos Firewall VoIP Einstellungen optimieren geprüft werden.

Auswertung und Aufräumen

Nach dem Capture geht es um drei Dinge: Datei sicher übertragen, temporäre Daten entfernen und die Beobachtungen richtig einordnen. tcpdump zeigt den Paketfluss, aber nicht die komplette Sophos-Policy-Entscheidung.

PCAP-Datei herunterladen und aufräumen

Eine PCAP-Datei kann per scp auf einen internen Server kopiert werden:

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

Je nach Umgebung kann auch ein anderes sicheres Transferverfahren verwendet werden. FTP mit fest eingetragenen Zugangsdaten sollte vermieden werden.

Nach erfolgreicher Übertragung sollte die Datei auf der Firewall entfernt werden:

rm /tmp/sophos-capture.pcap

Für vollständige Logarchive und Supportfälle ist Sophos Firewall Logs für Support und Analyse sichern die passendere Anleitung.

Kontext für Support oder externe Analyse

Eine PCAP-Datei ohne Kontext ist schwer auszuwerten. Für Sophos Support, Avanet oder einen externen Analysepartner sollten mindestens diese Angaben mitgegeben werden:

• Zeitfenster: zum Beispiel 2026-06-29, 14:05-14:08 Europe/Zurich.
• Erwarteter Flow: zum Beispiel Client 172.16.10.25 zu Server 198.51.100.20:443.
• Betroffene Funktion: DNAT, IPsec, SSL VPN, Webfilter, VoIP, DNS oder Routing.
• Beobachtung: zum Beispiel SYN sichtbar, kein SYN-ACK, Drop im Log Viewer oder keine Antwort vom Ziel.
• Parallel geprüft: Rule ID, NAT ID, Packet Capture und relevante Service-Logs.
• Änderung vor dem Fehler: Firmware, Regeländerung, Providerwechsel, Zertifikat oder SD-WAN-Route.

Vor der Weitergabe sollte geprüft werden, ob die Datei interne Namen, private Adressen, öffentliche Kunden-IP-Adressen oder unverschlüsselte Inhalte enthält. Wenn der Inhalt nicht anonymisiert werden kann, müssen Empfänger, Übertragungsweg und Aufbewahrung bewusst entschieden werden.

tcpdump richtig auswerten

Bei der Auswertung geht es nicht nur darum, ob Pakete sichtbar sind. Entscheidend ist, was fehlt.

• Keine Pakete vom Client sichtbar: Problem liegt vor der Firewall. Client, VLAN, Gateway, Switch oder Routing zur Firewall prüfen.
• Pakete kommen rein, gehen aber nicht raus: Firewallregel, NAT, Routing, Security Feature oder Policy prüfen.
• Pakete gehen raus, aber keine Antwort kommt zurück: Zielsystem, Rückroute, Gegenfirewall, NAT oder Provider prüfen.
• Nur SYN, kein SYN-ACK: Ziel oder Rückweg antwortet nicht.
• ICMP Request sichtbar, Reply fehlt: Rückroute, Ziel-Firewall oder Gegenstelle prüfen.
• DNS-Anfrage sichtbar, keine Antwort: DNS-Server, Route, Regel oder Upstream prüfen.
• Paket nur auf any, aber nicht auf erwartetem Interface sichtbar: Interface-Annahme, Zone, Route oder Tunnelzuordnung prüfen.
• Paket auf Eingangsinterface sichtbar, aber nicht auf Ausgangsinterface: Regel, NAT, Route, Security Feature oder Drop-Grund prüfen.

tcpdump zeigt den Paketfluss. Die Policy-Entscheidung selbst prüft man parallel im Log Viewer. Bei Firewall- und NAT-Fragen ist oft die Kombination aus Log Viewer, Packet Capture und tcpdump am schnellsten.

Für NAT-Fehler sollte man zusätzlich verstehen, dass NAT den Traffic nur übersetzt, aber nicht erlaubt. Die passende Grundlage ist NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT. Bei IPsec-Tunneln helfen parallel Sophos Firewall IPsec VPN Troubleshooting und die passenden VPN-Logs.

Typische Fehler und Checkliste

Die häufigsten Probleme entstehen durch zu breite Filter, zu lange laufende Mitschnitte oder eine falsche Erwartung an das Werkzeug. Diese Punkte sollte man vor einem produktiven Capture prüfen.

Typische Fehler

• Capture ohne Filter: Zu viele Daten, schwer auswertbar. Immer mit Host, Netz, Port oder Protokoll eingrenzen.
• Capture nicht gestoppt: Speicherplatz und Performance können leiden. -c verwenden oder Hintergrundprozess sauber beenden.
• Nur any ausgewertet: Interface- oder Tunnelproblem bleibt verborgen. Nach dem ersten Treffer gezielt Eingangs- und Ausgangsinterface vergleichen.
• Nur Hinweg geprüft: Rückwegproblem wird übersehen. Beide Richtungen betrachten.
• Falsches Interface gewählt: Relevante Pakete fehlen. Zuerst any, danach gezielt Interface eingrenzen.
• PCAP unverschlüsselt geteilt: Sensible Daten können offengelegt werden. Sichere Übertragung und minimale Empfängergruppe verwenden.
• Datei nach Supportfall liegen gelassen: Unnötiger Speicherverbrauch und Datenrisiko. PCAP nach Übertragung löschen.

Checkliste

• Source IP, Destination IP, Port und Protokoll bekannt.
• SSH-Zugriff auf die Firewall sicher eingerichtet.
• Vorher entschieden, ob Log Viewer oder WebAdmin Packet Capture ausreichen würde.
• Filter so eng wie möglich gewählt.
• Capture mit -c oder klarem Stoppprozess begrenzt.
• PCAP-Datei nur bei Bedarf geschrieben.
• Bei Interface-Fragen erst any, danach Eingangs- und Ausgangsinterface verglichen.
• Problem während des Captures gezielt reproduziert.
• Uhrzeit des Tests dokumentiert.
• Log Viewer parallel geprüft.
• Rule ID, NAT ID, Drop Reason oder Service-Log notiert, falls sichtbar.
• PCAP sicher übertragen.
• Temporäre PCAP-Datei von der Firewall entfernt.

FAQ