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.
| Frage | Erster Einstieg | CLI erst dann, wenn … |
|---|---|---|
| Welche Firewall-Regel greift? | Log Viewer, Policy Test und Packet Capture | Log Viewer zu wenig Details zeigt oder Live-Logs benötigt werden |
| Kommen Pakete auf der Firewall an? | Packet Capture im WebAdmin | ein enger CLI-Capture oder PCAP für Support nötig ist |
| Hat ein Dienst ein Problem? | Dashboard, Log Viewer, Service-Logs | Dienststatus, Debug oder Logdateien direkt geprüft werden müssen |
| Wurde etwas geändert? | Audit Trail Logs | 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.
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:
| Punkt | Warum wichtig |
|---|---|
| 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.
| Bereich | Typische Verwendung | Beispiele |
|---|---|---|
| Device Console | Sophos CLI für Netzwerk-, System- und Diagnosebefehle | ping, dnslookup, traceroute, tcpdump, drop-packet-capture, show |
| Advanced Shell | Linux-nahe Shell für Dateien, Logs, Prozesse und Service-Checks | cd /log, tail -f, grep, less, df -kh, service -S, 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 > Advanced Shell.
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.
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:
| Aufgabe | Befehl | Hinweis |
|---|---|---|
| Log live verfolgen | tail -f /log/strongswan.log | gut für reproduzierbare VPN-Fehler |
| Logdatei lesen | less /log/ips.log | mit /Suchbegriff innerhalb von less 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.
| Ziel | Beispiel | Zweck |
|---|---|---|
| Host erreichen | ping 192.0.2.10 count 4 | prüft ICMP-Erreichbarkeit |
| DNS prüfen | dnslookup example.com | prüft 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 |
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.
Conntrack
conntrack zeigt aktive Verbindungen, die der Stateful-Firewall-Pfad kennt. Das ist hilfreich, wenn man prüfen möchte, ob eine Verbindung überhaupt im Connection Tracking auftaucht.
conntrack -L | grep "192.0.2.10"
Wenn ein Eintrag fehlt, kann das auf Routing, NAT, falsche Quelle, fehlende Firewallregel oder einen Test am falschen Pfad hindeuten. Wenn ein Eintrag vorhanden ist, aber die Anwendung nicht funktioniert, muss zusätzlich geprüft werden, 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.
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.
Beispiel für IPS-Debug:
service ips:debug -ds nosync
Problem reproduzieren, relevante Uhrzeit notieren und danach Debug wieder deaktivieren:
service ips:debug -ds nosync off
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
| Fehler | Warum problematisch | Besser |
|---|---|---|
| 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 aus, Dateien prüfen, temporäre SSH-Freigaben entfernen |
Checkliste
- SSH-Zugriff nur aus vertrauenswürdigen Admin-Netzen erlaubt.
- SSH-Fingerprint und
adminZugriff vor der Analyse geprüft. - Richtigen Konsolenbereich gewählt: Device Console oder Advanced Shell.
- Problemzeitpunkt, Quell-IP, Ziel-IP, Port und Benutzer dokumentiert.
- Erst lesende Befehle genutzt, bevor Debug, Service-Neustarts oder längere Captures gestartet wurden.
- Log Viewer zuerst geprüft.
- Passende Logdatei unter
/logidentifiziert. tail,grepoderlessmit engem Suchbegriff verwendet.- Bei Netzwerkproblemen
ping,dnslookup,traceroute,drop-packet-captureodertcpdumpgezielt eingesetzt. - Debug nur kurz aktiviert und 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
Welche Sophos Firewall CLI-Befehle sind für den Anfang am wichtigsten?
ping, dnslookup, traceroute, tcpdump, drop-packet-capture und show die wichtigsten Grundlagen. In der Advanced Shell sind tail, grep, less, df, service -S, conntrack und tcpdump besonders nützlich.Wann reicht der Log Viewer und wann braucht es die CLI?
Soll man Debug-Logging dauerhaft aktiv lassen?
Was sollte man vor CLI-Troubleshooting notieren?
grep, tail, Packet Capture und spätere Supportanalysen deutlich zielgerichteter.