Zum Inhalt springen
Avanet

Sophos Firewall Service-Logs richtig zuordnen

Sophos Firewall

Bei der Sophos Firewall gibt es drei wichtige Ebenen für Troubleshooting: Event Logs im Log viewer, Diagnosewerkzeuge im WebAdmin und Dienst- beziehungsweise Logdateien auf der Firewall. Der Log Viewer ist ideal für schnelle Fragen wie „wurde die Verbindung erlaubt oder blockiert?“. Die Dateien unter /log sind wichtiger, wenn ein Dienst nicht startet, ein VPN-Tunnel instabil ist, Webfilter unerwartet greifen oder der Support detaillierte Daten benötigt.

Dieser Artikel ordnet die wichtigsten Services und Logdateien nach typischen Admin-Problemen. Er hilft auch dann, wenn im Dashboard, in der Advanced Shell oder in einem Supportfall ein technischer Dienstname auftaucht und nicht sofort klar ist, welche Firewall-Funktion dahintersteckt. Namen wie zebra, warren, awed, garner oder strongswan sind im Alltag nicht selbsterklärend.

Werkzeugwahl und Voraussetzungen

Bevor man in Logdateien sucht, sollte klar sein, welches Werkzeug die schnellste Antwort liefert. Viele Fälle lassen sich bereits mit Log Viewer oder Packet Capture eingrenzen. Die Shell wird erst dann wirklich hilfreich, wenn ein Dienst selbst geprüft werden muss oder der Support detaillierte Logdaten benötigt.

Welches Troubleshooting-Werkzeug passt?

Nicht jedes Firewall-Problem beginnt mit einer Shell. Oft ist zuerst ein anderes Werkzeug schneller:

Die Reihenfolge ist wichtig. Der Log Viewer zeigt oft schneller, welche Regel oder welches Modul entschieden hat. Packet Capture beweist den Paketfluss im WebAdmin. tcpdump ist sinnvoll, wenn ein längerer Mitschnitt, eine PCAP-Datei oder ein sehr genauer CLI-Filter gebraucht wird. Service-Logs und Debug helfen, wenn ein bestimmter Dienst selbst das Problem ist oder wenn Daten für Sophos Support gesammelt werden müssen.

Schneller Einstieg nach Symptom

Wenn nicht klar ist, welcher Log relevant ist, hilft ein Start nach Symptom statt nach Dienstname.

  • Einzelne Verbindung funktioniert nicht: Zuerst Log Viewer mit Source, Destination, Service und Uhrzeit prüfen. Danach Packet Capture, firewall_rule.log und nat_rule.log verwenden.
  • VPN-Tunnel ist down oder instabil: VPN-Status, Peer-IP, Uhrzeit und Log Viewer prüfen. Danach strongswan.log, charon.log, sslvpn.log und IPsec-Diagnosedaten ansehen.
  • WebAdmin, User Portal oder SSH ist nicht erreichbar: Device Access, Local Service ACL und betroffene Zone prüfen. Danach apache.log, tomcat.log, sshd.log und Packet Capture auf den Zielport verwenden.
  • Webfilter, TLS Inspection oder IPS blockiert unerwartet: Log-Viewer-Modul und Policy-ID prüfen. Danach ips.log, awarrenhttp.log und Packet Capture vergleichen.
  • Sophos Fusion Aufgabe bleibt hängen: Central Task Queue und lokalen Status vergleichen. Danach centralmanagement.log, sophos-central.log und fwcm-api-executor.log prüfen.
  • HA verhält sich unterschiedlich pro Node: Aktiven Node, Auxiliary Node und betroffenen Traffic-Pfad bestimmen. Danach direkt auf dem betroffenen Node anmelden und HA-Logs prüfen.
  • Lokale Reports fehlen oder Speicher läuft voll: Report-Einstellungen, Speicherplatz und Central Reporting prüfen. Danach reportdb.log, garner.log und Speicherplatzanalyse verwenden.

Diese Sicht verhindert eine typische Falle: Man sucht in einer Dienstlogdatei, obwohl zuerst Regel-Matching, Device Access, NAT oder Routing bewiesen werden müsste.

Log Viewer oder Logdatei?

Den Log viewer öffnet man in der WebAdmin-Konsole oben rechts. Er aktualisiert sich automatisch, lässt sich nach Modul, Zeit, Feldwerten und Freitext filtern und kann Logs als CSV exportieren.

Sollen Benutzernamen, IP-, MAC- und E-Mail-Adressen in der täglichen Loganzeige geschützt werden, kann Data Anonymization für lokale Logs und Reports eingesetzt werden. Die Wirkung im Log Viewer beweist jedoch nicht automatisch, dass Dateien unter /log, CTR, Remote-Syslog oder Central dieselben Identitäten anonymisieren; jeder Ausgabeweg wird separat geprüft.

Troubleshooting-Logs liegen auf der Firewall im Verzeichnis /log. Der offiziell dokumentierte Weg führt über die CLI: anmelden, 5 Device Management und danach 3 Advanced Shell wählen. Für längere tail-, grep- oder less-Sitzungen ist SSH in der Praxis meist angenehmer. Wie man SSH sicher vorbereitet, steht in der Anleitung Sophos Firewall per SSH verbinden.

Vor längeren Shell-Sitzungen sollte klar sein, aus welchem Admin-Netz verbunden wird, ob der SSH-Fingerprint geprüft wurde und ob wirklich die Advanced Shell benötigt wird. Für viele erste Prüfungen reicht der Log Viewer oder Packet Capture im WebAdmin.

Als Faustregel hilft diese Reihenfolge:

  1. Einzelner Traffic-Flow ist betroffen: Log Viewer nach Source, Destination, Service und Uhrzeit filtern.
  2. Log Viewer zeigt keine Entscheidung: Packet Capture mit engem Filter starten.
  3. Packet Capture zeigt Incoming, aber keinen klaren Entscheid: Rule ID, NAT ID, Firewall ID 0, Rückweg und passende Logdatei prüfen.
  4. Ein konkreter Dienst wirkt instabil: Passende Datei unter /log mit tail -f beobachten.
  5. Ein Fehler ist sporadisch oder braucht Support: Zeitfenster, Filter, Logarchiv und gegebenenfalls tcpdump vorbereiten.
  6. Normale Logs reichen nicht: Debug nur für den betroffenen Dienst und nur kurz aktivieren.

Damit bleibt die Analyse klein genug. Man sammelt zuerst den sichtbaren Befund, wechselt dann zum Paketfluss und erst danach zu Dienstlogs oder Debug. Das reduziert die Gefahr, zu früh breite Debug-Logs zu aktivieren oder eine falsche Logdatei auszuwerten.

Logdateien in der Advanced Shell lesen

Bevor man in /log sucht, sollte der Testfall möglichst eng dokumentiert sein: lokale Zeit, betroffene Source-IP, Destination-IP, Port, Benutzer, Modul und erwartetes Verhalten. Diese Angaben machen den Unterschied zwischen einer brauchbaren Loganalyse und einer langen Suche durch alte Einträge.

  1. An der CLI anmelden, 5 Device Management und danach 3 Advanced Shell wählen.
  2. In das Log-Verzeichnis wechseln.
cd /log

Nützliche Befehle:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Die wichtigsten Befehle aus der Advanced Shell:

  • Live mitlesen: tail -f /log/<logfilename>.log, zum Beispiel tail -f /log/ips.log.
  • Statische Logdatei lesen: less /log/<logfilename>.log, zum Beispiel less /log/ips.log.
  • Nach Begriff suchen: grep <keyword> /log/<logfilename>.log, zum Beispiel grep error /log/ips.log.
  • Dienststatus lesen: service -S oder mit einem konkreten Namen eingrenzen, zum Beispiel service -S | grep ips. Dieser Check verändert den Dienst nicht.

Für Support oder eine spätere Analyse sollte man nicht nur einzelne Logzeilen kopieren. Besser sind ein klarer Zeitbereich, der reproduzierte Test, relevante Screenshots aus Log Viewer oder Packet Capture und bei Bedarf ein vollständiges Logarchiv. Lokale Logs rotieren; deshalb sollten wichtige Daten gesichert werden, solange das Ereignis noch im betroffenen Zeitraum vorhanden ist. Der Ablauf steht in Sophos Firewall Logs für externe Analyse sichern.

Troubleshooting-Logs im WebAdmin herunterladen

Nicht jede Logsammlung muss manuell in der Advanced Shell gebaut werden. Im WebAdmin lassen sich die Dateien unter Diagnostics > Tools sammeln.

In der Praxis gibt es zwei Wege:

  • Einzelne Logdateien: Diagnostics > Tools > Troubleshooting logs öffnen, betroffene Logdateien auswählen und als komprimierte Datei herunterladen.
  • Consolidated Troubleshooting Report (CTR): Diagnostics > Tools > Consolidated troubleshooting report verwenden, wenn Support alle Logs plus Systemzustand, Prozesse und Ressourcendaten in einem Paket benötigt.

Das ist praktisch, wenn ein Admin keine längere Shell-Sitzung öffnen möchte oder wenn nur ein klar abgegrenztes Logpaket benötigt wird. Der CTR ist dagegen besser, wenn Sophos Support einen breiten System-Snapshot braucht. Bei der Erzeugung wird ein nachvollziehbarer Grund eingetragen, zum Beispiel Ticketnummer, Zeitraum oder Fehlerbild. Der Report wird verschlüsselt heruntergeladen; sein Dateiname enthält ausserdem die Seriennummer der Firewall und gehört deshalb nicht in öffentliche Anhänge.

Ein CTR enthält standardmässig 10'000 Zeilen pro Service subsystem log. Der Wert kann in der Device Console nur auf 250 bis 10'000 Zeilen gesetzt, also gegenüber dem Default nur verkleinert werden. Default subsystem logs sind von diesem Limit ausgenommen und vollständig enthalten. Das Limit gilt ausschliesslich für den CTR: Vollständige einzelne Dateien erhält man über Troubleshooting logs oder die Advanced Shell.

Wichtig: Ein heruntergeladenes Logpaket ersetzt nicht die Kontextdaten. Support braucht weiterhin Uhrzeit mit Zeitzone, betroffene IPs, Benutzer, Tunnelname, Regel-ID, NAT-ID und eine kurze Beschreibung, was genau reproduziert wurde.

Bei HA-Clustern muss man zusätzlich beachten: Logs und Reports werden nicht einfach zwischen Primary und Auxiliary synchronisiert. Jeder Node enthält die Logs für den Traffic und die Dienste, die er selbst verarbeitet hat. Bei Node-spezifischen Fehlern muss deshalb der betroffene Node geprüft werden.

Logrotation und flüchtige Daten einordnen

Troubleshooting Logs entstehen zunächst im Arbeitsspeicher und werden von der Firewall ins Dateisystem geschrieben. Reagiert die Firewall nicht mehr, können Einträge verloren gehen, die bis dahin noch nicht auf das Dateisystem kopiert wurden. Ein unerwarteter Reboot oder Hang ist deshalb kein Grund, mit der Beweissicherung zu warten; vorhandene CTR-, Log- und Zeitdaten werden zuerst gesichert.

Jedes Subsystem hat abhängig von Kritikalität und Appliance-Modell eigene Grössen- und Speichergrenzen. Erreicht die aktive Datei ihre Grenze, komprimiert SFOS sie als .gz und schreibt unter dem ursprünglichen Dateinamen weiter. Sind auch die Rotationen am Subsystem-Limit, wird die älteste komprimierte Datei zuerst gelöscht. Die Zahl der Rotationen und die verfügbare Historie sind daher nicht für alle Dienste gleich.

Logdateien oder .gz-Rotationen werden nicht manuell umbenannt oder gelöscht. Für Speicheranalyse, Export und die dokumentierten Purge-Befehle gilt der Ablauf unter Speicherplatz und Reports kontrolliert verwalten.

Advanced Shell oder Device Console?

Bei Sophos Firewall gibt es zwei unterschiedliche Konsolenbereiche, die oft verwechselt werden:

  • Device Console: Sophos CLI für Firewall-spezifische Befehle, zum Beispiel Routing-Priorität, IPsec-Routen oder Systemoptionen.
  • Advanced Shell: Linux-nahe Shell für Dateisystem, Logdateien und lesende Befehle wie tail, grep, less oder service -S.

Nicht jeder Befehl funktioniert in beiden Bereichen. Wenn ein Artikel ausdrücklich Device Console erwähnt, sollte der Befehl dort ausgeführt werden. Wenn es um /log, tail -f, grep oder service -S geht, ist die Advanced Shell gemeint. Die dokumentierten system diagnostics ...-Befehle für CTR-Limits, Log-Purge und Subsystem-Debug gehören dagegen in die Device Console.

Diese Unterscheidung ist wichtig, weil viele Fehler nur dadurch entstehen, dass ein korrekter Befehl am falschen Ort eingegeben wird.

Logging muss aktiv sein

Nicht jede erwartete Information erscheint automatisch.

  • In Firewall Regeln muss Log firewall traffic aktiv sein.
  • In SSL/TLS inspection rules muss Logging aktiviert sein.
  • Unter System services > Log settings muss definiert sein, welche Logtypen lokal, an Sophos Fusion oder an Syslog gesendet werden.

Für langfristige Aufbewahrung ist ein Syslog-Server oder Sophos Central Firewall Reporting sinnvoll. Wie man externe Logserver oder ein SIEM anbinden kann, steht in Sophos Firewall Syslog an SIEM senden. Für Sophos Fusion ist Central Firewall Reporting aktivieren der passende Ablauf.

Debug nur gezielt aktivieren

Debug-Logging erzeugt deutlich mehr Daten, belegt Speicherplatz und kann vertrauliche Inhalte erfassen. Deshalb ist es kein sinnvoller erster Schritt. Zuerst werden normales Log, Zeitraum und reproduzierbarer Test festgelegt; Debug wird nur für das betroffene Subsystem und nur so lange wie nötig verwendet.

Sophos dokumentiert zwei unterschiedliche Wege. Der Advanced-Shell-Befehl service <service>:debug -ds nosync schaltet den Zustand um und kennt kein separates Argument on oder off. Für ein unterstütztes Service-Subsystem sind deshalb die expliziten Device-Console-Befehle von Sophos vorzuziehen: system diagnostics subsystems <subsystem> debug on, Fehler reproduzieren und Daten erfassen, danach system diagnostics subsystems <subsystem> debug off. Für Packet-Capture-Debug lautet der Subsystemname zum Beispiel Pktcapd. Debug ist standardmässig aus; vor jeder Änderung wird trotzdem geklärt, ob nicht bereits ein anderer Administrator oder Sophos Support Daten sammelt. Änderung protokollieren und nach der Erfassung prüfen, dass Debug ausgeschaltet ist.

CSC-System-Controller-Debug als separaten Umschalter behandeln

SFOS 22 dokumentiert für den System Controller (CSC) einen separaten Device-Console-Befehl:

system diagnostics subsystems CSC debug

Anders als die Service-Subsystem-Syntax oben hat dieser Befehl kein Argument on oder off: Jede Ausführung schaltet CSC-Debug um. Deshalb wird er als kontrollierte Änderung und nicht als Statusabfrage verwendet:

  1. Vorprüfung: Mit anderen Administratoren und Sophos Support klären, dass CSC-Debug nicht bereits aktiv oder Teil einer laufenden Datenerfassung ist. Firewall beziehungsweise HA-Knoten, Zeit, Grund und geplantes Erfassungsfenster protokollieren. Vor der Änderung eine Ausgangskopie des relevanten CSC-Logs sichern. Den Umschalter nicht ausführen, nur um seinen Zustand herauszufinden.
  2. Aktivieren und reproduzieren: Den Befehl in der Device Console genau einmal ausführen. Nur den eingegrenzten Fehler reproduzieren und die Testzeit mit Zeitzone notieren.
  3. Beweise sichern: Vor dem Rollback entweder das relevante einzelne Troubleshooting-Log herunterladen oder den CTR erzeugen und die fertiggestellte CTR-Datei herunterladen. Den verschlüsselten CTR und jedes Logarchiv geschützt aufbewahren, da sie vertrauliche Daten enthalten können; für den Fall benötigte Beweise nicht löschen oder überschreiben.
  4. Deaktivieren / Rollback: Zur Device Console zurückkehren und denselben Befehl genau einmal ausführen. Diese zweite, geplante Ausführung schaltet CSC-Debug wieder aus.
  5. Prüfen: Einen kurzen kontrollierten Test durchführen und in den neu geschriebenen CSC-Logzeilen bestätigen, dass keine Debug-Ausgabe mehr entsteht und das Log wieder mit normaler Rate wächst. Rollback-Zeit und Ergebnis protokollieren. Ist der Ausgangszustand oder die Nachprüfung unklar, den Umschalter nicht wiederholt ausführen, sondern den Zustand mit Sophos Support klären.

⚠️ WAF-Debug und reverseproxy.log: Sophos hat mit SFOS 22.0 MR2 Build 546 den Fehler NC-177457 behoben, bei dem bei aktiviertem WAF-Debugging ein Passwort in reverseproxy.log sichtbar war. Sophos nennt weder den Beginn der betroffenen Versionsspanne noch die Art des Passworts. Bereits erzeugte WAF-Debug-Logs, Troubleshooting-Archive und CTR-Dateien aus älteren oder unbekannten Builds sollten deshalb als Dateien behandelt werden, die potenziell Zugangsdaten enthalten.

Wenn Zugangsdaten im Klartext gefunden werden: Zugriff begrenzen, Vorfall dokumentieren und die betroffenen Zugangsdaten ändern. Logs nicht pauschal löschen, bevor Support-, Forensik- und Aufbewahrungsanforderungen geklärt sind.

Das Thema Debug-Logging und grundlegende CLI-Befehle ist ausführlicher im Artikel Sophos Firewall CLI Troubleshooting: wichtige Befehle beschrieben. Für den Neustart einzelner Dienste hilft zusätzlich Sophos Firewall Services sicher neu starten.

Typische Fehler bei der Logsuche

Viele Loganalysen dauern nicht wegen fehlender Daten lange, sondern weil zu früh im falschen Werkzeug gesucht wird.

  • Direkt Debug aktivieren: Erst Log Viewer, passende Logdatei und reproduzierbaren Test prüfen.
  • Nur nach Fehlermeldungen suchen: Zusätzlich Source, Destination, User, Rule ID, NAT Rule ID und Uhrzeit eingrenzen.
  • Packet Capture ignorieren: Wenn unklar ist, ob Pakete überhaupt ankommen oder weitergehen, früh Packet Capture verwenden.
  • Central Reporting als Live-Debug verstehen: Central Reporting für Verlauf und Reports nutzen, lokale Logs für Detailanalyse.
  • Support-Logs erst Tage später sichern: Logs, Uhrzeit und Reproduktionsschritte sichern, solange das Ereignis noch nachvollziehbar ist.
  • Debug nach dem Test laufen lassen: Debug wieder deaktivieren und Speicherplatz kontrollieren.

Ein guter Troubleshooting-Fall hat deshalb immer drei Dinge: einen engen Test, die passende Logquelle und eine dokumentierte Uhrzeit. Ohne diese Basis sieht man zwar viele Logzeilen, aber nicht zwingend die Ursache.

Logdateien nach Funktionsbereich

Die folgenden Listen sind als Nachschlagewerk gedacht. Am besten wählt man zuerst den betroffenen Funktionsbereich und prüft dann die passende Logdatei mit einem engen Zeitfenster.

Die primären Zuordnungen folgen der aktuellen SFOS-22.0-Dokumentation. Auf älteren Installationen oder in alten Supportarchiven können zusätzlich die früher verwendeten Namen app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log und crreportdb.log auftauchen. Sophos führt sie in der aktuellen SFOS-22.0-Logliste nicht mehr; deshalb sollte man sie auf einem aktuellen Build nicht voraussetzen.

System, Management und Basisdienste

  • Systemstart: sysinit.log; zuerst bei Boot- und Failsafe-Problemen prüfen.
  • Systemmeldungen: syslog.log; zusätzlich Zeit, Reboot und Interface-Events prüfen.
  • WebAdmin Webserver: apache.log, apache_access.log; zusätzlich Device Access und Local Service ACL prüfen.
  • WebAdmin Anwendung: tomcat.log; zusätzlich GUI-Fehler, hohe Last und Service-Status prüfen.
  • SSH: sshd.log; zusätzlich Device Access, Source-Netz und Public-Key-Login prüfen.
  • GUI/CLI Fehler: error_log.log; zusätzlich aktuelle Änderung, Browser und Admin-Aktion prüfen.
  • Konfigurationsänderungen: applog.log, csc.log; zusätzlich Audit Trail und Config Studio prüfen.
  • Konfigurationsdatenbank: postgres.log; zusätzlich Speicherplatz, Backup/Restore und Supportfall prüfen.
  • Kommunikationskanal zwischen bestimmten Komponenten und ihren Diensten: garner.log; bei Central Management und Reporting zusätzlich die jeweiligen Plugin-Einträge prüfen.
  • API: apiparser.log; zusätzlich validation.log, API-ACL, Token und Central Task Queue prüfen.
  • Validierung: validation.log, validationError.log; zusätzlich fehlerhafte Objekte oder Imports prüfen.
  • Lizenzierung: licensing.log; zusätzlich Lizenzstatus, Central Sync und Air-Gap-Sonderfall prüfen.
  • System Updates: u2d.log; zusätzlich Patternstatus, DNS/HTTPS und Speicherplatz prüfen.

Bei Management-Problemen sollte nicht nur die WebAdmin-Logdatei geprüft werden. Sehr oft entscheidet Device Access, eine Local Service ACL Exception Rule oder ein falsches Quellnetz darüber, ob WebAdmin, SSH, User Portal, VPN Portal, DNS oder SNMP erreichbar sind. Für diesen Teil ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren der bessere Einstieg.

Firewall, NAT und Packet Capture

  • Firewall-Regel-Matching: firewall_rule.log; zusätzlich Log Viewer Modul Firewall prüfen.
  • Allgemeine Firewall-Verarbeitung: fwlog.log; zusätzlich Packet Capture verwenden.
  • NAT-Regeln: nat_rule.log; zusätzlich NAT Rule ID im Log Viewer prüfen.
  • DNAT mit Link Load Balancing: zusätzlich dgd.log prüfen, wenn Gateway- oder Link-Auswahl beteiligt ist.
  • Packet Capture im WebAdmin: pktcapd.log; zusätzlich Diagnostics > Packet capture prüfen.
  • Bandwidth Management / QoS: bwm.log; zusätzlich Traffic Shaping Policy prüfen.
  • Virtual Host / ältere Serverpublikation: vhost.log; zusätzlich NAT und WAF prüfen.
  • Web Server Protection / WAF: reverseproxy.log; zusätzlich WAF-Regel, Hosted address und Backend-Erreichbarkeit prüfen.

Bei DNAT-Problemen immer Firewall Regel und NAT Regel gemeinsam prüfen. NAT übersetzt nur, erlaubt aber keinen Traffic. Mehr dazu: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Sophos Firewall nutzt für Firewall-Verbindungen unter anderem IP tables, ARP table, IPset und conntrack. Für QoS beziehungsweise Bandwidth Management kommt IMQ zum Einsatz. Diese Information ist hilfreich, wenn man Logmeldungen oder Supportausgaben mit technischen Begriffen aus dem Linux-Netzwerkpfad sieht.

IPS, Application Control und TLS Inspection

  • Intrusion Prevention: Service ips, Logdatei ips.log.
  • Application Control: Service ips / Application Filter, Logdatei ips.log.
  • DPI und TLS Inspection: DPI Engine, Logdatei ips.log.
  • Antivirus im Netzwerkpfad: Service avd, Logdatei avd.log.
  • Zero-Day Protection / Sandbox: Sandbox Service, Logdatei sandboxd.log.
  • Active Threat Response / X-Ops Threat Feeds: ATR im Netzwerkpfad; zuerst Log Viewer, je nach Modul zusätzlich ips.log.
  • MDR Threat Feeds: ATR / MDR-Feed-Status, Logdatei atr.log; Audit-ID, Task Queue und lokaler Traffic-Nachweis werden im Betriebsablauf zusammengeführt.
  • Signatur-Updates: Signature Updater, Logdatei sig_upgrade.log.
  • Signatur-Migration: Signature Migration, Logdatei sigmigration.log.

Viele moderne Schutzfunktionen sehen erst genug Details, wenn HTTPS entschlüsselt wird. Wenn TLS Inspection nicht greift, sind Webfilter, Application Control, IPS und Malware Scan je nach Traffic weniger aussagekräftig.

Wenn unklar ist, ob IPS überhaupt aktiv ist, welche Policy greift oder warum eine Signatur blockiert, hilft zuerst Sophos Firewall IPS einrichten und sicher testen. Danach kann man ips.log, Log Viewer und Packet Capture gezielter zusammenführen.

Wenn es um Anwendungserkennung, Application Filter oder unerwartete App-Control-Blocks geht, passt zuerst Sophos Firewall Application Control einrichten und testen.

Für Zero-Day Protection sollte man zusätzlich prüfen, ob Web Protection, TLS Inspection, Dateityp, Dateigrösse, Policy und Aktion zusammenpassen. Der passende Betriebsartikel ist Sophos Firewall Zero-Day Protection verstehen und betreiben. Für Threat Feeds passt Sophos Firewall Threat Feeds einrichten und sicher betreiben. Mehr zu TLS Inspection: TLS Inspection auf Sophos Firewall schrittweise ausrollen.

Web, Proxy, WAF und Webfilter

  • HTTPS Proxy: Service awarrenhttp, Logdatei awarrenhttp.log.
  • HTTPS Proxy Access: awarrenhttp Access Log, Logdatei awarrenhttp_access.log. Für SFOS 22/23 gilt: Einzelne Web-Proxy-Anfragen erscheinen hier nur, wenn awarrenhttp mit aktiviertem Debug läuft; den Erfassungsablauf unten beachten.
  • Web Categorization / Reputation: Service nSXLd, Logdatei nSXLd.log.
  • Kategorie-Updates (SFOS 22/23): Logdatei catUpdateLog – Gross-/Kleinschreibung beachten, ohne .log-Endung.
  • Legacy HTTP/FTP Proxy: Service skein, Logdatei skein.log.
  • FTP Proxy: Service ftpproxy, Logdatei ftpproxy.log.
  • Web Application Firewall: Reverse Proxy, Logdatei reverseproxy.log.

Für diese Access-Log-Erfassung zuerst den betroffenen Firewall-/HA-Knoten, Testfall, Uhrzeit und ein kurzes Erfassungsfenster festlegen, Speicherplatz prüfen und mit anderen Administratoren beziehungsweise Support bestätigen, dass Debug aus ist. Den Umschalter nicht als Statusabfrage verwenden. Dann in der Advanced Shell service awarrenhttp:debug -ds nosync genau einmal ausführen, den eingegrenzten Fehler reproduzieren und awarrenhttp_access.log geschützt sichern. Anschliessend denselben Befehl genau einmal ausführen, um Debug wieder auszuschalten. Mit einem kurzen kontrollierten Test prüfen, dass keine neuen Debug-Einträge entstehen und das normale Log wieder mit normaler Rate wächst; Rückweg und Speicherplatzkontrolle dokumentieren. Ist Ausgangszustand oder Nachprüfung unklar, nicht weiter umschalten, sondern mit Support klären. Diese Methode gilt hier für awarrenhttp in SFOS 22/23, nicht pauschal für alle Dienste oder Releases.

Bei einem vermuteten Proxy-Loop kann block_proxy_loop zusammen mit einem kurzzeitig aktivierten awarrenhttp-Debug die Meldung Duplicate Via header values, proxy loop liefern. Die genaue Voraussetzung, die globale Wirkung und den sicheren Rückweg erklärt HTTP Proxy Settings sicher prüfen. Debug bleibt nur für den reproduzierbaren Test aktiv und wird danach wieder ausgeschaltet.

Wenn Webtraffic im Log Viewer als blockiert erscheint, kann die Ursache in mehreren Modulen liegen: Web Policy, SSL/TLS inspection, Application Control, IPS oder WAF. Darum immer das konkrete Modul im Log Viewer auswählen und zusätzlich die passende Logdatei prüfen.

Sophos blockiert Webseiten der Kategorie highly objectionable criminal activity grundsätzlich und blendet den Domainnamen in Logs und Reports aus. Wenn ein Eintrag in diesem Bereich bewusst anonymisiert wirkt, kann dies also beabsichtigt sein.

Für Web-Kategorien, URL-Gruppen, Web Policies und Instant Alerts passt Sophos Firewall Web-Kategorien und Instant Alerts nutzen.

VPN

  • IPsec ab SFOS v17+: Services strongswan, charon; Logdateien strongswan.log, charon.log.
  • IPsec verbindungsspezifisch: einzelne IPsec Connection, Logdatei /log/ipsec_conn/ipsec_<connectionname>.log.
  • IPsec ältere Versionen: IPsec Service, Logdatei ipsec.log.
  • IPsec Monitoring: IPsec Monitor, Logdatei ipsec_monitor.log.
  • XFRM / route-based VPN: Service xfrmi, Logdatei xfrmi.log.
  • SSL VPN: SSL VPN / OpenVPN, Logdatei sslvpn.log.
  • SSL VPN Status: OpenVPN Status, Logdatei openvpn-status*.log.
  • VPN Portal: Logdatei vpnportal.log.
  • L2TP: Service l2tpd, Logdatei l2tpd.log. Einrichtung und Diagnose beschreibt L2TP Remote Access auf Sophos Firewall.
  • PPTP: PPTP VPN, Logdatei pptpvpn.log.
  • VPN Zertifikate: VPN Certificate Services, Logdatei vpncertificate.log.
  • Clientless SSL VPN: Clientless Access, Logdatei clientless_access.log.

Sophos Firewall verwendet strongSwan für IPsec VPN und OpenVPN für SSL VPN. Bei IPsec-Problemen sind Uhrzeit, Peer-IP, Proposal, Local/Remote Subnets, NAT-T, Routing und Firewall Regeln entscheidend.

Für IPsec-Probleme ist der Artikel Sophos Firewall IPsec Troubleshooting die bessere Schritt-für-Schritt-Anleitung. Wenn es um route-based VPN und manuelle IPsec-Routen geht, hilft IPsec Route auf Sophos Firewall erstellen.

Authentication, User Portal und SSO

  • Benutzer-Authentifizierung: Access Server / AAA, Logdatei access_server.log.
  • NTLM / NASM: Service nasm, Logdatei nasm.log.
  • Chromebook SSO: Chromebook SSO Backend, Logdatei chromebook-sso-backend.log.
  • OAuth SSO Captive Portal (SFOS 22): Logdatei oauth_sso_captive.log.
  • OAuth SSO WebAdmin (SFOS 22): Logdatei oauth_sso_webadmin.log.
  • OAuth SSO VPN (SFOS 22): Logdatei oauth_sso_vpn.log.
  • OAuth SSO (SFOS 23): oauth_sso_svc.log für SSO-Anmeldungen an WebAdmin, Captive Portal, VPN Portal, IPsec VPN und SSL VPN.
  • RADIUS SSO: Benutzer-IP-Zuordnung über Accounting in access_server.log. Einrichtung und Abnahme erklärt RADIUS SSO mit Accounting.
  • STAS: STAS / Access Server Kontext, je nach Dienstkontext und access_server.log.

Bei Benutzerregeln immer zuerst prüfen, ob der Benutzer überhaupt bekannt ist. Wenn Match known users aktiv ist und die Authentifizierung nicht funktioniert, matcht die Regel nicht. Für klassische Browser-Anmeldungen verbindet Sophos Firewall Captive Portal einrichten und testen Device Access, Benutzerregel, Live users, Log Viewer und access_server.log zu einem vollständigen Prüfweg.

Wenn noch unklar ist, ob Dienstwahl, Identität, Main Group, Quota oder erst der spätere Traffic-Pfad scheitert, führt Sophos Firewall Authentifizierungsfehler systematisch beheben diese Ebenen zu einem gemeinsamen Diagnoseweg zusammen.

Wenn Captive Portal mit Microsoft Entra ID SSO verwendet wird, hilft Microsoft Entra ID SSO für Sophos Firewall Captive Portal einrichten beim Abgleich von oauth_sso_captive.log (SFOS 22; in SFOS 23: oauth_sso_svc.log), Device Access, Gruppen und späterem Regel-Matching.

DNS, DHCP und Netzwerk

  • DNS Service: Service dnsd, Logdatei dnsd.log.
  • DNS Grabber: Service dnsgrabber, Logdatei dnsgrabber.log.
  • DNS Entity / weitere DNS-Komponenten: Services entity, eacd; Logdateien entity.log, eacd.log.
  • DHCP IPv4: Service dhcpd, Logdatei dhcpd.log.
  • DHCP IPv6: Logdatei dhcpd6.log.
  • Netzwerkdienst: Service networkd, Logdatei networkd.log.
  • FQDN Hosts: Service fqdnd, Logdatei fqdnd.log.
  • Dead Gateway Detection: Service dgd, Logdatei dgd.log.
  • Dynamic DNS: Dynamic DNS Client, Logdatei ddc.log.
  • NTP Client: Logdatei ntpclient.log.
  • IPv6 Router Advertisement: Service radvd, Logdatei radvd.log.

DNS- und DHCP-Probleme wirken oft wie Firewall-Probleme. Daher sollten zuerst IP-Adresse, Gateway, DNS-Server und die Frage geprüft werden, ob Clients die Firewall als DNS oder DHCP-Server verwenden sollen.

Wenn interne Domains nicht korrekt aufgelöst werden, ist meistens DNS request routes auf Sophos Firewall konfigurieren relevant. Für DHCP-Sonderoptionen gibt es den eigenen Artikel Sophos Firewall DHCP Options konfigurieren.

Cellular WAN

  • WWAN / USB-Modem: Einstecken und Entfernen von USB-Geräten in modemd.log prüfen.
  • Modem-Netzwerkkonfiguration: modembezogene Interfaces und IP-Konfiguration in networkd.log prüfen.
  • USB, Modem und PPP: Syslog-Meldungen zu USB, Modem und Point-to-Point Protocol in syslog.log prüfen.

Bei Cellular-WAN-Problemen sollte man zusätzlich prüfen, ob das Modem erkannt wird, ob PIN/SIM/APN korrekt sind und ob die Firewall ein passendes Gateway erstellt.

Routing

Bei Routing-Problemen zusätzlich Routing > SD-WAN routes, Gateways und Packet Capture prüfen. Der Policy tester ersetzt keinen echten Routing-Test.

Mehr dazu: Routing-Priorität auf Sophos Firewall anpassen.

GUI, CLI und Systemzugriff

Für WebAdmin, SSH, API und lokale Managementdienste steht die Basisliste weiter oben unter System, Management und Basisdienste. Wenn WebAdmin oder SSH nicht erreichbar ist, nicht nur apache.log, tomcat.log oder sshd.log prüfen. Lokaler Zugriff wird über Administration > Device access und Local Service ACL gesteuert.

Mehr dazu: SSH-Verbindung zur Sophos Firewall herstellen.

Sophos Fusion, Heartbeat und Central Management

  • Sophos Central Management: Central Management, Logdateien centralmanagement.log, sophos-central.log.
  • CSC: Services csc, cschelper, csd; Logdateien csc.log, cschelper.log, csd.log.
  • Security Heartbeat: Services heartbeatd, hbtrust; Logdateien heartbeatd.log, hbtrust.log.
  • Synchronized Application Control: Daten an SophosLabs in sac-feedback.log prüfen.
  • SAC-Datenbankoptimierung (SFOS 22/23): sac-vacuum.log protokolliert die wöchentliche Optimierung der Synchronized-Application-Control-Datenbank; sac-feedback.log bleibt das separate Log für Daten an SophosLabs.
  • Heartbeat zu Central: Services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; jeweilige Service-Logs prüfen.
  • Central API Executor: Service fwcm-api-executor, Logdatei fwcm-api-executor.log.
  • Active Threat Response: ATR-Kontext; je nach Version und Modul prüfen.

Bei Problemen mit Sophos Fusion zuerst prüfen, ob die Firewall registriert ist, Central Services aktiv sind und ob DNS/HTTPS ausgehend funktioniert. Wenn eine Änderung aus Sophos Fusion nicht lokal ankommt, sollte man die Sophos Fusion Firewall Task Queue mit den lokalen Logs vergleichen. Ein grüner Sophos-Fusion-Status allein beweist nicht, dass eine konkrete Policy lokal verarbeitet wurde.

High Availability

  • HA Status und Konfiguration: HA Application Log, Logdatei applog.log.
  • HA Pair Service: Service ha_pair, Logdatei ha_pair.log.
  • HA Tunnel: Service ha_tunnel, Logdatei ha_tunnel.log.
  • Conntrack Sync: Service ctsyncd, Logdatei ctsyncd.log.
  • Msync: Service msync, Logdatei msync.log.
  • HA-Aufbau und Statuswechsel: ha.log.
  • Dateisynchronisierung ausgewählter Dienste zum Auxiliary-Gerät: filesync.log.

HA-Logs und Reports werden nicht zwischen den Geräten synchronisiert. Jeder Node speichert nur Daten für Traffic, den er selbst verarbeitet hat. Log Viewer und Diagnostics > Tools > Troubleshooting logs werden deshalb auf jedem betroffenen Gerät geprüft. Für Troubleshooting-Logs des Auxiliary Device meldet man sich direkt über IP-Adresse oder FQDN seiner Administrationsschnittstelle an dessen CLI an. Sophos Central Firewall Reporting kann Reports beider Geräte zusammenführen, ersetzt aber keine Node-lokalen Troubleshooting-Dateien.

Mail und Anti-Spam

  • Antivirus: AV Service, Logdatei avd.log.
  • Antivirus Updates: Up2Date AV, Logdatei up2date_av.log.
  • Anti-Spam: Service sasi, Logdatei sasi.log.
  • Sandbox: Service sandboxd, Logdatei sandboxd.log.
  • SMTP MTA: Service smtpd, Logdatei smtpd_main.log.
  • SMTP Fehler: smtpd Error/Panic/Reject, Logdateien smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
  • Legacy SMTP/S Proxy: Services awarrensmtp, awarrenmta; Logdateien awarrensmtp.log, awarrenmta.log. Einrichtung und End-to-End-Test erklärt Mail Protection im Legacy Mode.
  • POP/IMAP Proxy: Service warren, Logdatei warren.log. Einrichtung und End-to-End-Test erklärt POP3 und IMAP auf Sophos Firewall scannen.

Bei Mailproblemen immer prüfen, ob MTA Mode, Firewall Regel, DNS, Zertifikate und Provider-Restriktionen zusammenpassen. Der Ablauf für Mailflow, Spool, Quarantäne und Relay ist in Sophos Firewall Mail Protection im MTA Mode einrichten beschrieben.

Sophos Firewall verwendet Avira und Sophos Antivirus. Der Anti-Spam-Dienst startet nur, wenn eine eingehende oder ausgehende Spam Policy vorhanden ist. Diese Abhängigkeit ist wichtig, wenn sasi.log leer bleibt oder der Anti-Spam-Service nicht läuft.

Wireless, RED, Hotspot und weitere Dienste

  • Wireless Controller: Service awed, Logdatei awed.log.
  • Wireless Clients: Kommunikation zwischen Client und AP/APX in wc_remote.log.
  • Hotspot: Services hostapd, hotspotd; Logdateien hostapd.log, hotspotd.log.
  • RED: RED Service, Logdatei red.log. Je nach RED-Typ und Instanz können zusätzlich red-<serial ID of RED>.log und red-<RED ID>.log erscheinen.
  • SNMP: Service snmpd, Logdatei snmpd.log.
  • Syslog Service: Logdatei syslog.log.
  • Licensing: Licensing Service, Logdatei licensing.log.
  • System Updates: Service u2d, Logdatei u2d.log.
  • VMware Tools: Service vmtool, Logdatei vmtool.log.

Bei Lizenz-, Air-Gap- oder Pattern-Problemen sind licensing.log und u2d.log die ersten technischen Anlaufstellen. Für den Betriebsablauf mit Lizenzdatei, 180-Tage-Fenster und manuellen Pattern-Updates passt Sophos Firewall Air-Gap-Lizenzierung und Pattern-Updates betreiben.

Datenbank und Reporting

  • Configuration database: Config DB, Logdatei postgres.log.
  • Postgres: Service postgres, Logdatei postgres.log.
  • Signature database: Service sigdb, Logdatei sigdb.log.
  • Report database: Report DB, Logdatei reportdb.log.
  • Migration database: Report Migration, Logdatei reportmigration.log.
  • Konfigurationsmigration (SFOS 22/23): Logdatei migration.log; nicht mit reportmigration.log für die Reportmigration verwechseln.
  • Garner: Service garner, Logdatei garner.log.
  • iView: Service iview, Logdatei iview.log.

Wenn Reports fehlen, langsam sind oder Speicherplatzprobleme auftreten, sind Reporting- und Datenbanklogs relevant. Zusätzlich sollte man prüfen, ob Reports lokal gespeichert oder an Sophos Fusion gesendet werden.

Weitere aktuelle SFOS-22-Logdateien

Die folgenden Dateien werden seltener im täglichen Traffic-Troubleshooting benötigt, gehören aber zur aktuellen SFOS-22-Zuordnung. Sie werden nach Funktion gruppiert, damit aus einem Dateinamen nicht vorschnell eine Ursache abgeleitet wird:

  • Audit, FIPS und Supportzugang: configuration-audit.log protokolliert Konfigurationsänderung, Administrator und Zeitpunkt; fips.log den Start im FIPS-Modus; uma.log den Support Access.
  • Logpipeline und lokale Datenpflege: syslog-ng.log zeigt die Unterdrückung aufeinanderfolgender Eventeinträge; reportdb_v9.log gehört zur alten Reportdatenbank. dbcleanup.log, readobject.log, fstrim.log und logrotate.log betreffen Datenbankbereinigung, interne Objektlesung, Dateisystem-Trimming und Logrotation.
  • ATR, NDR und FastPath: atr-service.log zeigt Start und Ende des ATR-Dienstes. ndr.log und ndr_agent.log decken NDR-Lizenz, Konfiguration, Agentstart und Metadatenverarbeitung ab; vfpdf.log gilt für NDR-Metadaten auf XGS 88/88w, 108/108w, 118/118w und 128/128w. setup_vf_dpdk.log protokolliert die FastPath-Speicherinitialisierung und gilt gerade nicht für diese vier Modellreihen.
  • TLS und SSL VPN: httplogd.log zeigt nicht entschlüsselte HTTPS-Verbindungen im DPI-Pfad. peruser_cert_sslvpn.log protokolliert benutzerspezifisch erzeugte SSL-VPN-Zertifikate; openvpn-status0.log, openvpn-status1.log und weitere nummerierte Dateien zeigen aktive SSL-VPN-Verbindungen je Prozess.
  • Netzwerk und HA: dhcprelay.log gehört zum DHCP Relay. ha.log zeigt Erfolg oder Fehler beim Aufbau von HA sowie Statuswechsel; filesync.log die Dateisynchronisierung ausgewählter Dienste zum Auxiliary-Gerät.
  • Central, Deployment und ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log und fwcm-frpcd.log decken an Central gesendete Zonen-/Interfaceinformationen, Verbindung, übertragene Konfiguration und Fast Reverse Proxy ab. ssod.log enthält Firmware- und Central-Backupinformationen, zt.log und zerotouch.log Zero-Touch-Varianten, ztna-connector.log den lokalen ZTNA Connector.
  • Backup, Firmware, Air Gap und Zertifikate: interfacemapping.log protokolliert die Interfacezuordnung beim Restore, legacyconversion.log Backups ohne Secure Storage Master Key und fwmgmt.log Firmwareinstallation und -verwaltung. u2d_airgap.log gilt für Air-Gap-Updates, cps_messages.log für Hotfixfehler und letsencrypt.log zusammen mit applog.log für Let’s-Encrypt-Zertifikate.
  • Hardware und Systemzustand: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log und xgs-pport-wait.log decken NPU-Start, -Kommunikation, -Firmware, Serial-Port, Gesundheit und physische Interfaceerstellung ab. raid.log zeigt Software-RAID, lcd.log die Hardwareanzeige. system-monitor/cpu_trigger.log hält Systemzustand bei hoher CPU fest; system-monitor/memory_trigger.log gilt in SFOS 22 für hohe Speicherlast.
  • Cloud- und Plattformdienste: iaasd.log protokolliert Provisioning und Lizenzprüfung in Azure, waagent.log den Azure-Agenten und dessen Health Monitoring; vmtool.log gehört zu VMware Tools.

Die Anwesenheit einer Datei beweist keinen Fehler in diesem Modul. Zuerst werden Ereigniszeit, betroffener Node, Plattform, Dienststatus und reproduzierbares Symptom zusammengeführt; erst danach wird mit einem engen Filter in der passenden Datei gesucht.

Analyseablauf

  1. Problem genau notieren: Uhrzeit mit Zeitzone, Client, Ziel, Port, User, Aktion.
  2. Entscheiden, ob es um Traffic, Dienststatus, Konfigurationsänderung oder Central-Synchronisation geht.
  3. Im Log Viewer nach Source IP, Destination IP, Modul und Uhrzeit filtern.
  4. Sichtbarkeit von Firewall Rule ID, NAT Rule ID, User, Gateway und Policy IDs prüfen.
  5. Packet Capture nutzen, wenn Paketfluss, Rückweg oder NAT-Sicht unklar ist.
  6. Passende Logdatei mit tail -f, less oder grep prüfen.
  7. Problem reproduzieren und den exakten Testzeitpunkt dokumentieren.
  8. Wenn nötig Debug nur für den betroffenen Dienst und nur kurz aktivieren.
  9. Debug wieder deaktivieren und Speicherplatz prüfen.
  10. Logs sichern, solange der Fehler frisch reproduziert wurde.

Für Supportfälle sollte man ausserdem alle Fehlermeldungen, Reproduktionsschritte und bereits ausgeführten Troubleshooting-Schritte dokumentieren. Genau diese Informationen beschleunigen Supportfälle deutlich. Der passende Ablauf steht in Sophos Supportticket eröffnen: Vorbereitung und Portal.

FAQ

Welche Logdatei ist bei Sophos Firewall am wichtigsten?

Das hängt vom Problem ab. Für Firewall-Regeln ist firewall_rule.log wichtig, für NAT nat_rule.log, für IPsec strongswan.log, für SSL VPN sslvpn.log, für IPS und Application Control häufig ips.log. Der Log Viewer bleibt trotzdem der beste erste Einstieg für einzelne Verbindungen.

Was ist CTR bei Sophos Firewall Logs?

CTR steht in vielen Sophos-Kontexten für Consolidated Troubleshooting Report. Für Admins ist wichtig: Ein CTR- oder Troubleshooting-Logpaket hilft dem Support, ersetzt aber keine saubere Fehlerbeschreibung mit Uhrzeit, betroffenen IPs, Benutzer, Tunnelname, Regel-ID und Reproduktionsschritten.

Wann braucht man die Advanced Shell?

Die Advanced Shell ist sinnvoll, wenn lokale Logdateien mit tail, grep oder less geprüft werden müssen, ein Dienststatus kontrolliert wird oder Sophos Support detaillierte Logdaten benötigt. Für viele erste Prüfungen reichen Log Viewer, Policy Test und Packet Capture im WebAdmin.

Sollte man Debug-Logging dauerhaft aktiv lassen?

Nein. Debug erzeugt viele Daten und kann Speicherplatz verbrauchen. Debug sollte nur für den betroffenen Dienst, für einen kurzen reproduzierbaren Test und mit anschliessender Deaktivierung genutzt werden.

Warum sieht man im Log Viewer keine erwarteten Firewall-Events?

Häufig ist Log firewall traffic in der betroffenen Regel nicht aktiv, der falsche Zeitraum oder Filter gewählt, oder der Traffic erreicht die Firewall nicht. Wenn der Paketfluss unklar ist, sollte man Log Viewer und Packet Capture gemeinsam verwenden.

Sind lokale Logs besser als Central Reporting oder Syslog?

Es sind unterschiedliche Werkzeuge. Lokale Logs helfen bei Detailanalyse direkt auf der Firewall. Central Reporting eignet sich für Sophos-Central-Reports und Verlauf. Syslog ist besser für eigene SIEM-, SOC- oder Langzeitaufbewahrung.