Sophos Firewall CLI Troubleshooting: wichtige Befehle

Bei Sophos Firewall Troubleshooting reicht der Log Viewer oft für die erste Eingrenzung. Sobald ein Dienst nicht sauber startet, VPN-Verbindungen instabil sind, einzelne Pakete nicht ankommen oder der Support detaillierte Daten benötigt, wird die CLI wichtig.

Diese Übersicht zeigt die wichtigsten Befehle für den Alltag: wo man sie ausführt, was sie zeigen und wann man besser zu einem spezialisierten Artikel wechselt. Für den sicheren Zugriff per SSH sollte zuerst Sophos Firewall per SSH verbinden geprüft werden. Dabei sind Public Key, Host-Key-Prüfung und eine enge Device-Access-Freigabe wichtiger als ein schneller Login von irgendwo.

⚠️ Wichtig: CLI- und Advanced-Shell-Befehle sollten nur aus vertrauenswürdigen Admin-Netzen und mit klarer Zielsetzung ausgeführt werden. Besonders Debug, tcpdump, Dateioperationen und Service-Kommandos können Speicherplatz, Performance oder laufende Verbindungen beeinflussen.

Erst WebAdmin, dann CLI

Die CLI ist nicht immer der schnellste Einstieg. Wenn es um Regel-Matching, NAT oder einzelne Verbindungen geht, liefern Log Viewer, Policy Test und Packet Capture im WebAdmin oft schneller einen sauberen Befund.

Gute Einstiege:

• Welche Firewall-Regel greift? Zuerst Log Viewer, Policy Test und Packet Capture nutzen. CLI wird erst nötig, wenn der Log Viewer zu wenig Details zeigt oder Live-Logs benötigt werden.
• Kommen Pakete auf der Firewall an? Zuerst Packet Capture im WebAdmin verwenden. CLI ist sinnvoll, wenn ein enger Capture oder eine PCAP-Datei für Support gebraucht wird.
• Hat ein Dienst ein Problem? Zuerst Dashboard, Log Viewer und Service-Logs prüfen. CLI wird wichtig, wenn Dienststatus, Debug oder Logdateien direkt geprüft werden müssen.
• Wurde etwas geändert? Zuerst Audit Trail Logs prüfen. CLI hilft danach, wenn ein Konfigurationsunterschied mit Logs oder Backups verglichen wird.

Das Ziel ist nicht, möglichst schnell in die Advanced Shell zu springen. Besser ist ein nachvollziehbarer Ablauf: erst sichtbare Ereignisse prüfen, dann gezielt die passende Logdatei oder den passenden Capture öffnen.

CLI-Befunde verwertbar dokumentieren

CLI-Ausgaben sind nur dann hilfreich, wenn später noch klar ist, zu welchem Test sie gehören. Einzelne kopierte Fehlermeldungen ohne Zeitfenster, IP-Adressen oder betroffene Funktion führen oft zu Rückfragen und doppelter Analyse.

Eine kurze Notiz pro Test reicht meistens:

• Zeitfenster: Start, Ende und Zeitzone des Tests.
• Testflow: Source IP, Destination IP oder FQDN, Port, Benutzer oder VPN-Peer.
• Werkzeug: Device Console, Advanced Shell, Log Viewer oder Packet Capture.
• Befehl oder Filter: ausgeführter Befehl, verwendeter grep-Suchbegriff oder Capture-Filter.
• Ergebnis: Treffer, Fehlermeldung, fehlender Logeintrag, Paket sichtbar oder Paket nicht sichtbar.
• Nächster Schluss: zum Beispiel Regelproblem, DNS-Problem, Rückweg, Dienstfehler oder Supportfall.

Vor der Weitergabe an Support, Avanet oder externe Partner sollte man prüfen, ob Ausgaben sensible Daten enthalten: öffentliche IPs, interne Hostnamen, Benutzernamen, VPN-Parameter, Seriennummern, Token, E-Mail-Adressen oder Kundenbezeichnungen. Für eine technische Analyse müssen Daten nicht beliebig breit verteilt werden; wichtig ist der kleinste Ausschnitt, der den Befund belegt.

Vor dem ersten Befehl

CLI-Troubleshooting wird deutlich zuverlässiger, wenn der Rahmen vor dem ersten Befehl feststeht. Sonst entstehen schnell Logausschnitte ohne Zeitbezug, zu breite Captures oder Debug-Logs, die später niemand mehr sauber zuordnen kann.

Vor produktiven CLI-Tests sollte man festhalten:

• Problemzeit: Logs lassen sich gezielt nach dem Testfenster durchsuchen.
• Source IP, Destination IP und Port: grep, tcpdump und Packet Capture bleiben eng und lesbar.
• Betroffener Benutzer oder Peer: Authentifizierung, VPN und User Matching lassen sich besser zuordnen.
• Erwartetes Modul: Man sucht zuerst in der passenden Logdatei statt in allen Logs.
• Geplante Aktion: Debug, Service-Check oder Capture wird nicht aus Versehen zum Dauerzustand.
• Rollback oder Abbruchkriterium: Bei Last, vollem Speicher oder Nebenwirkungen wird der Test beendet.
• Aktuelles Backup bei Änderungsarbeiten: Service-Neustarts oder Konfigurationsänderungen lassen sich sauberer absichern.

Der erste Schritt sollte möglichst lesend sein: Log Viewer prüfen, passende Logdatei ansehen, service -S lesen oder einen engen Capture starten. Neustarts, Debug-Modus und breit laufende Mitschnitte gehören erst danach in ein bewusstes Testfenster.

Bei HA-Clustern sollte zusätzlich klar sein, welche Appliance gerade aktiv ist. Logs, Debug und Captures müssen auf dem Node geprüft werden, über den der relevante Traffic tatsächlich läuft.

Device Console oder Advanced Shell?

Sophos Firewall hat zwei unterschiedliche Konsolenbereiche. Viele Fehler entstehen, weil ein Befehl im falschen Bereich eingegeben wird.

Die Bereiche haben unterschiedliche Aufgaben:

• Device Console: Sophos CLI für Netzwerk-, System- und Diagnosebefehle. Typische Befehle sind ping, dnslookup, traceroute, tcpdump, drop-packet-capture und show.
• Advanced Shell: Linux-nahe Shell für Dateien, Logs, Prozesse und Service-Checks. Typische Befehle sind nslookup, cd /log, tail -f, grep, less, df -kh, service -S und conntrack.

Nach dem Login per SSH zeigt die Firewall zuerst das Konsolenmenü. Für die Device Console wählt man normalerweise 4. Device Console. Für die Advanced Shell verwendet man 5. Device Management > 3. Advanced Shell.

Der DNS-Test zeigt den Unterschied besonders gut. Die Befehle sind nicht austauschbar:

Device Console:

dnslookup host example.com

Advanced Shell:

nslookup example.com

Diese Meldung ist kein DNS-Testergebnis. Erscheint in der Advanced Shell /bin/sh: dnslookup: not found, ist dnslookup dort nicht verfügbar. Stattdessen nslookup verwenden; dessen Ausgabe zeigt anschliessend, ob die DNS-Auflösung funktioniert.

Die offizielle Sophos CLI-Hilfe unterstützt Tab und ? zur Syntaxprüfung. Das ist in der Device Console hilfreich, weil nicht jeder Befehl gleich aufgebaut ist.

Gerade in der Device Console sollte man Befehle nicht halb geraten ausführen. Sophos weist darauf hin, dass ein unvollständiger Befehl den access_server blockieren kann. Deshalb zuerst mit Tab oder ? die Syntax anzeigen lassen und dann den vollständigen Befehl bewusst ausführen.

Direkte Konfigurationsänderungen in der Advanced Shell sind nicht persistent und werden nicht in Backups übernommen. In dieser Anleitung wird sie deshalb nur für Diagnosebefehle verwendet.

Ein spezieller Notfallbefehl ist system appliance_access enable. Er übersteuert die Device-Access-Konfiguration und erlaubt Zugriff auf alle lokalen Firewall-Dienste, einschliesslich Legacy-Diensten wie Telnet. Wichtig: Solange dieser Modus aktiv ist, leitet die Firewall keinen ausgehenden Traffic mehr ins Internet weiter. Das ist kein normaler Troubleshooting-Schritt, sondern nur für kurze Notfälle gedacht. Vor der Aktivierung den Zustand prüfen:

system appliance_access show

Nach dem Test den Notfallmodus deaktivieren und den Zustand erneut prüfen:

system appliance_access disable
system appliance_access show

Wenn ein Befehl nicht erkannt wird, zuerst den Konsolenbereich prüfen. Ein falscher Bereich ist wahrscheinlicher als ein sofort defekter Befehl.

Logs in der Advanced Shell prüfen

Die wichtigsten Logdateien liegen unter /log. Für die erste Orientierung wechselt man in dieses Verzeichnis und listet die Dateien auf.

cd /log
ls -lah

Nützliche Basisbefehle:

• Log live verfolgen: tail -f /log/strongswan.log. Gut für reproduzierbare VPN-Fehler.
• Logdatei lesen: less /log/ips.log. Innerhalb von less kann man mit /Suchbegriff suchen.
• Nach Fehlern suchen: grep -i "error" /log/ips.log. -i ignoriert Gross- und Kleinschreibung.
• Treffer mit Zeilennummer: grep -n "192.0.2.10" /log/firewall_rule.log. Hilfreich für längere Dateien.
• Letzte Zeilen anzeigen: tail -n 100 /log/syslog.log. Schneller Überblick ohne Live-Modus.

Welche Logdatei zu welchem Modul gehört, ist in Sophos Firewall Troubleshooting: Services und Logs zusammengefasst.

Bei Live-Logs sollte man den Testzeitraum kurz halten und die Uhrzeit notieren. Das ist besonders wichtig, wenn später ein Logarchiv an Sophos Support oder Avanet gegeben wird.

Device Console für schnelle Netzwerkchecks

Die Device Console eignet sich für schnelle Tests aus Sicht der Firewall. Damit lässt sich prüfen, ob DNS, Routing oder Erreichbarkeit grundsätzlich funktionieren.

Schnelle Checks:

• Host erreichen: ping 192.0.2.10 count 4 prüft ICMP-Erreichbarkeit.
• DNS in der Device Console prüfen: dnslookup host example.com prüft die Namensauflösung aus Sicht der Firewall.
• Route prüfen: traceroute 192.0.2.10 zeigt den Pfad zum Ziel.
• Interface-Status ansehen: show interfaces zeigt Interface-Informationen.
• Drop Capture starten: drop-packet-capture 'host 192.0.2.10' zeigt Pakete, die von Firewall-Regeln verworfen werden.
• Paketmitschnitt starten: tcpdump 'host 192.0.2.10 and port 443' prüft, ob Pakete auf der Firewall sichtbar sind.

Für IPv6 stehen die entsprechenden Befehle ping6, dnslookup6 und traceroute6 zur Verfügung.

drop-packet-capture ist besonders nützlich, wenn unklar ist, ob die Firewall Pakete aktiv verwirft. Es ersetzt aber keine Applikationsanalyse. Wenn ein Server antwortet, aber die Anwendung trotzdem nicht funktioniert, braucht es zusätzlich Log Viewer, NAT-Prüfung, Packet Capture oder Applikationslogs.

Für längere Paketmitschnitte und PCAP-Dateien ist der eigene Artikel Sophos Firewall: Logs mit TCPDump für Analyse sammeln besser geeignet. Dort sollte man auch planen, wie gross die Datei werden darf, wo sie gespeichert wird und wie sie sicher übertragen wird.

Verbindungen und Paketfluss in der Advanced Shell prüfen

Wenn Log Viewer und Device Console noch keine klare Antwort liefern, helfen einige Advanced-Shell-Befehle bei der Einordnung des Paketflusses.

Verbindungen prüfen

Bevor Advanced-Shell-Werkzeuge eingesetzt werden, sollte der Flow unter Current activities > Live connections und Diagnostics > Connection list gefiltert werden. Diese dokumentierten WebAdmin-Ansichten zeigen Rule ID, NAT ID, Interfaces, Benutzer, Gateway und übersetzte Adressen, ohne die Session zu verändern.

In der Device Console ist system diagnostics utilities connections ein offiziell dokumentiertes Diagnosewerkzeug für Verbindungen. Die verfügbaren Optionen und die Ausgabe vorher mit ? prüfen.

conntrack ist ein supportnahes Werkzeug in der Advanced Shell und zeigt aktive Verbindungen, die der Stateful-Firewall-Pfad kennt. Die genaue Verfügbarkeit kann vom Firmwarestand abhängen.

conntrack -L | grep "192.0.2.10"

Ein fehlender Treffer ist nur ein Indiz, da Timing, Filterrichtung oder FastPath die Sichtbarkeit beeinflussen können. Deshalb das Ergebnis mit Log Viewer und Packet Capture abgleichen. Wenn ein Eintrag vorhanden ist, aber die Anwendung nicht funktioniert, zusätzlich prüfen, ob Antwortpakete zurückkommen und ob NAT, Policy oder Applikation korrekt arbeiten.

tcpdump in der Advanced Shell

Für schnelle Live-Prüfungen kann tcpdump auch in der Advanced Shell genutzt werden.

tcpdump -i any -nn host 192.0.2.10

Für produktive Analysen sollte der Filter möglichst eng sein. Breite Mitschnitte wie tcpdump -i any ohne Host, Port oder Count erzeugen schnell sehr viel Ausgabe und sind auf ausgelasteten Firewalls unpraktisch.

Ein sicherer Start ist ein kurzer Mitschnitt mit Host, Port und Paketlimit:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Wenn mehr Daten benötigt werden, sollte vorher Speicherplatz geprüft und ein PCAP-Ablageort bewusst gewählt werden.

Speicherplatz und Systemzustand prüfen

Vor Debug-Logging, grossen Logarchiven oder längeren Paketmitschnitten sollte der freie Speicherplatz geprüft werden.

Die Device Console bietet dafür lesende, offiziell dokumentierte Systemchecks:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

Für eine ergänzende Prüfung in der Advanced Shell stehen folgende Werkzeuge zur Verfügung; ihre Verfügbarkeit kann vom Firmwarestand abhängen:

df -kh
df -h /var

Weitere schnelle Checks:

uptime
top
service -S
service -S | grep strongswan

service -S zeigt den Status vieler Dienste. Einzelne Dienstnamen sind nicht immer selbsterklärend. Deshalb sollte man den Dienst mit der passenden Logdatei abgleichen, bevor man Neustarts oder Debug aktiviert.

Wenn Speicherplatz bereits knapp ist, sollte kein Debug-Logging und kein längerer Paketmitschnitt gestartet werden. Zuerst klären, welche Logs oder Reports sicher gesichert und bereinigt werden können.

Debug-Log gezielt aktivieren

Debug-Logging kann bei komplexen Fehlern helfen, sollte aber nur kurz und nur für den betroffenen Dienst aktiv sein. Debug erzeugt deutlich mehr Logdaten und kann bei langer Laufzeit Speicherplatz verbrauchen.

Für einen eindeutig kontrollierbaren On/Off-Ablauf verwendet man in der Device Console ein unterstütztes Subsystem. Die verfügbaren Namen zuerst mit system diagnostics subsystems ? anzeigen. Sophos dokumentiert beispielsweise folgenden Ablauf für Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

In der Advanced Shell dokumentiert Sophos zusätzlich folgenden IPS-Debug-Befehl:

service ips:debug -ds nosync

Für diese Advanced-Shell-Variante ist kein separater Befehl mit angehängtem off dokumentiert. Sie sollte deshalb nur verwendet werden, wenn Sophos Support den exakten Rückweg für den installierten Build bestätigt hat.

Das Bild zeigt auf SFOS 20.0.1, wie derselbe Befehl den IPS-Debug-Modus umschaltet und service -S | grep ips den Zustand vor und nach dem Test bestätigt. Bei aktuellen Versionen sollte dieser Toggle nicht ungeprüft vorausgesetzt werden.

Für Service-Neustarts und die Einordnung von Diensten passt zusätzlich Sophos Firewall Services neu starten. Bei Supportfällen sollte der genaue Zeitraum des Debug-Logs dokumentiert werden.

Vor einem Service-Neustart sollte geprüft werden, welche Funktion betroffen ist und ob gerade produktiver Traffic darüber läuft. Ein Neustart von VPN-, IPS-, Web- oder Authentifizierungsdiensten kann aktive Sitzungen oder Benutzeranmeldungen beeinflussen.

Logs sicher bereitstellen

Einzelne Logausschnitte reichen bei komplexen Fällen oft nicht aus. Für Sophos Support, Avanet oder eine externe Analyse ist ein vollständiges Logarchiv meistens sinnvoller.

Statt FTP-Zugangsdaten in Befehle zu schreiben, sollte man Logs über einen sicheren und nachvollziehbaren Weg übertragen, zum Beispiel per scp auf einen eigenen Server oder über ein Supportportal. Die passende Anleitung steht unter Sophos Firewall Logs für Support und Analyse sichern.

Logdateien können sensible Informationen enthalten: interne IP-Adressen, öffentliche IPs, Hostnamen, Benutzernamen, VPN-Parameter und Fehlermeldungen. Vor einer Weitergabe sollte klar sein, wer die Daten erhält und wie lange sie gespeichert werden.

Typische Fehler bei CLI-Troubleshooting

• Befehl im falschen Konsolenbereich: Device Console und Advanced Shell unterstützen unterschiedliche Syntax. Zuerst Bereich prüfen.
• Debug nach der Analyse aktiv lassen: Logs wachsen unnötig und können Speicherplatz verbrauchen. Debug direkt wieder deaktivieren.
• Breiter tcpdump ohne Filter: Sehr viel Ausgabe, hohe Last und schwer auswertbare Daten. Host, Port, Interface oder Count einschränken.
• FTP-Zugangsdaten in der Shell-History: Zugangsdaten können in Logs, Screenshots oder History landen. Sichere Übertragung und temporäre Credentials verwenden.
• Nur eine Logdatei prüfen: Viele Probleme betreffen mehrere Module. Log Viewer, passende Service-Logs und Packet Capture kombinieren.
• Zeitpunkt nicht dokumentieren: Support muss unnötig grosse Logbereiche durchsuchen. Uhrzeit, Testaktion und beteiligte IPs notieren.
• Nach dem Test nicht aufräumen: Debug, temporäre Dateien oder breite Zugänge bleiben aktiv. Debug ausschalten, Dateien prüfen und temporäre SSH-Freigaben entfernen.

Checkliste

• SSH-Zugriff nur aus vertrauenswürdigen Admin-Netzen erlaubt.
• SSH-Fingerprint und admin Zugriff vor der Analyse geprüft.
• Richtigen Konsolenbereich gewählt: Device Console oder Advanced Shell.
• Problemzeitpunkt, Quell-IP, Ziel-IP, Port und Benutzer dokumentiert.
• CLI-Befund mit Zeitfenster, Befehl, Filter und Ergebnis dokumentiert.
• Erst lesende Befehle genutzt, bevor Debug, Service-Neustarts oder längere Captures gestartet wurden.
• Log Viewer zuerst geprüft.
• Passende Logdatei unter /log identifiziert.
• tail, grep oder less mit engem Suchbegriff verwendet.
• Bei Netzwerkproblemen dnslookup in der Device Console oder nslookup in der Advanced Shell sowie ping, traceroute, drop-packet-capture oder tcpdump gezielt eingesetzt.
• Debug nur kurz aktiviert und mit dem dokumentierten Off-Befehl des gewählten Subsystems wieder deaktiviert.
• Speicherplatz vor Debug oder PCAP geprüft.
• Logarchiv sicher übertragen und temporäre Dateien entfernt.
• Temporäre Device-Access- oder SSH-Ausnahmen nach dem Supportfall entfernt.

FAQ