Sophos Firewall Log Viewer richtig nutzen

Der Log Viewer ist in SFOS 22 oft der schnellste Einstieg in eine Störung: Welche Firewall-Regel hat den Traffic verarbeitet, welche NAT-Regel war beteiligt, welcher Benutzer wurde erkannt und welches Security-Modul hat blockiert? Damit die Antwort stimmt, müssen Modul, Zeitraum, Filter und Zeitpunkt des Logeintrags zusammenpassen.

Der Log Viewer zeigt protokollierte Ereignisse. Er ist kein Packet Capture und keine vollständige Verbindungshistorie. Ein fehlender Eintrag beweist deshalb weder einen Drop noch, dass das Paket die Firewall erreicht hat.

Für eine belastbare Analyse werden immer Source, Destination, Service, genaue Testzeit und erwartete Richtung notiert. Danach wird genau ein neuer Testflow erzeugt und in den passenden Modulen gesucht.

Einen Test in sieben Schritten auswerten

1. In der betroffenen Firewall-Regel Log firewall traffic beziehungsweise in der SSL/TLS-Regel Log connections prüfen.
2. Unter System services > Log settings sicherstellen, dass der benötigte Logtyp bei Local reporting aktiviert ist.
3. Oben rechts im WebAdmin Log viewer (SFOS 22) beziehungsweise Logs and policy test (SFOS 23) öffnen und danach das fachlich passende Logmodul wählen.
4. Zeitfilter setzen und über Add filter zuerst Source-IP, Destination-IP und Service eingrenzen.
5. Einen neuen, kurzen Testflow erzeugen und seine genaue Uhrzeit notieren.
6. In Detailed view Rule ID, NAT ID, Action, Interfaces, Benutzer und modulspezifische Felder prüfen.
7. Wenn Eintrag und beobachtetes Verhalten nicht zusammenpassen, denselben Test mit Packet Capture korrelieren, bevor eine Regel geändert wird.

Diese Reihenfolge trennt drei häufig vermischte Fragen: Wurde überhaupt ein Log erzeugt? Welche Policy hat entschieden? Und sind die Pakete tatsächlich ein- und wieder ausgegangen?

Logeinträge richtig lesen

Warum Logeinträge nicht immer sofort erscheinen

Der Log Viewer aktualisiert die Ansicht automatisch. Eine Firewall-Session wird jedoch normalerweise erst protokolliert, wenn die Firewall ein Destroy-Event erhält und die Verbindung schliesst. Bei einer langen Sitzung kann der Logeintrag deshalb später erscheinen als der erste Request.

Bricht eine Verbindung ab, ohne dass die Firewall ein Destroy-Event erhält, etwa bei einem Verlust der Internetverbindung, kann der erwartete Sessionlog ganz fehlen. SSL/TLS-Verbindungen werden nach erfolgreichem Handshake und beim Schliessen protokolliert. Für einen kurzen Test ist daher eine bewusst beendete Verbindung besser als eine dauerhaft offene Browser-, Streaming- oder HTTP/2-Session.

Ein Browser-Reload erzeugt nicht zwingend eine neue Verbindung. Für reproduzierbare Tests eignet sich je nach Anwendung ein privates Browserfenster, ein neu gestarteter Clientprozess oder ein kurzer Aufruf wie:

curl -I https://example.com/

Der Befehl läuft auf dem Testclient, nicht in der Firewall-Shell. example.com ist eine reservierte Beispieldomain und kann durch einen bekannten, erlaubten Dienst ersetzt werden.

Das richtige Modul wählen

Ein Datenstrom kann mehrere Logmodule berühren. Das Modul Firewall zeigt beispielsweise, dass eine LAN-to-WAN-Regel die Verbindung erlaubt. Ein Web filter, Application filter, IPS oder SSL/TLS inspection kann denselben Datenstrom später trotzdem blockieren oder anders behandeln.

Darum reicht ein einzelner grüner Firewall-Eintrag bei Web- oder Security-Problemen nicht. Die Module werden für denselben Testflow anhand des Testzeitraums und der Adressen korreliert:

• Firewall: Regelentscheidung, NAT, Interfaces, Ports und grundlegender Verbindungsstatus.
• Web filter: URL-, Kategorie- und Web-Policy-Entscheidungen.
• SSL/TLS inspection: Zertifikats-, Handshake- und Decryption-Entscheidungen.
• Application filter: erkannte Anwendung und Application-Control-Aktion.
• IPS: Signatur- oder Anomalieereignisse.
• VPN: Aufbau und Status der jeweiligen VPN-Komponente.
• Authentication: erkannter Benutzer sowie erfolgreiche oder fehlgeschlagene Anmeldung.
• System: System- und administratorausgelöste Ereignisse.
• SD-WAN: SD-WAN-Profil-, SLA- und Routennutzung.

Welche Logtypen lokal erscheinen, wird unter System services > Log settings in Local reporting festgelegt. Diese Event Logs sind nicht dasselbe wie On-box Reports. Central reporting und Syslog sind wiederum eigene Ziele und müssen separat aktiviert werden. Web-Policy-Ereignisse setzen ausserdem Log firewall traffic in der zugehörigen Firewall-Regel voraus. Wireless-Logs sind im Log Viewer nicht verfügbar; sie müssen an Sophos Fusion (ehemals Sophos Central) oder einen Syslog-Server gesendet werden.

Web-Proxy-Grenze: Bei HTTP- und HTTPS-Verkehr auf den Ports 80 und 443 übergibt eine passende Firewall-Regel mit Drop den Datenstrom an den Web Proxy. Ohne passende Web Exception zeigt der Firewall-Log dann Allowed, während der Web-Filter-Log Blocked zeigt. Konfigurierte Web Exceptions gelten weiterhin, sodass ein Request trotz Drop zugelassen werden kann. Reject beendet den Datenstrom dagegen vor der Proxy-Verarbeitung. Deshalb werden Firewall-Regel, Web Policy und Web Exceptions immer gemeinsam geprüft.

Allow-Regel und fehlender Heartbeat

Ein anderer Fall als Drop liegt vor, wenn die tatsächlich passende Firewall-Regel die Action Allow hat, Block clients with no Heartbeat aktiviert ist und der Endpoint keinen Heartbeat sendet. Für die beschriebenen Logbeobachtungen muss Log firewall traffic in dieser Regel aktiviert sein. Vor der Suche prüft man zusätzlich unter System services > Log settings die benötigten Logtypen bei Local reporting; ein aktiviertes externes Logziel allein reicht für die lokale Anzeige nicht.

• Andere Ports als 80 und 443: Die Firewall verwirft die Pakete dieses Endpoints. Der Firewall-Log zeigt dropped.
• Ports 80 und 443 im dokumentierten Web-Proxy-Pfad: Die Firewall nimmt die eingehenden Pakete an und übergibt sie an den Web Proxy. Weil der Endpoint keinen Heartbeat sendet, entscheidet das Heartbeat-System auf Blockieren; der Proxy liefert dem Benutzer eine Blockseite. Der Firewall-Log zeigt allowed, ein weiterer Firewall-Log Heartbeat blocked und der Web filter-Log blocked. Heartbeat blocked gehört hier also ebenfalls zum Firewall-Modul, nicht zu einem separaten Heartbeat-Logmodul.

Allowed allein beweist keinen erfolgreichen Zugriff. Vor einer Regeländerung korreliert man die Einträge anhand desselben Testflows: Testzeitraum, Source und Destination, Ports und passende Regel werden gemeinsam geprüft. Dabei sucht man nach dem separaten Heartbeat blocked-Eintrag und dem Web filter-Eintrag mit blocked. Eine feste Ereignisreihenfolge, identische Zeitstempel oder eine universelle Anzahl von Logzeilen sind dafür keine Voraussetzung; fehlen erwartete Einträge, werden zuerst Logging, lokale Ziele und Filter geprüft und bei Bedarf Packet Capture herangezogen.

Diese Einordnung gilt für genau diese Regeloption, einen Endpoint ohne Heartbeat und den beschriebenen Proxy-Pfad. Sie ist keine allgemeine Aussage über jede Allow-Regel, rote oder anderweitig ungesunde Endpoints oder andere Inspektionsmodi. Heartbeat-Erzwingung wird nicht als pauschale Fehlerbehebung deaktiviert; zuerst werden Regelmatch und fehlender Heartbeat geklärt.

Standard view und Detailed view unterscheiden

Die Standardansicht ist gut zum schnellen Lesen. Spalten können ein- und ausgeblendet werden, und ein Klick auf einen Wert kann ihn direkt als Filter übernehmen. Für technische Abnahmen ist die Detailed view wichtiger, weil sie die zugrunde liegenden Feldnamen und zusätzliche Werte zeigt.

Eine wichtige NAT-Besonderheit: Wird eine andere übersetzte Source-Adresse als die standardmässige MASQ-Adresse verwendet, kann die Standardansicht trotzdem die MASQ-Adresse als ausgehende Adresse anzeigen. Die tatsächlich übersetzte Source steht in der Detailed view im Feld src_trans_ip.

Typische Felder für einen Firewall-Test sind:

• Source- und Destination-IP sowie Source- und Destination-Port
• In interface und Out interface
• Firewall Rule ID und NAT Rule ID
• Action beziehungsweise Status
• Benutzername, falls eine Identität erkannt wurde
• übersetzte Source und Destination
• Log component und Log subtype

Ein Feldname oder eine ID erklärt die Ursache noch nicht automatisch. Die Rule ID wird mit der aktuellen Regelbasis abgeglichen, die NAT ID mit der passenden NAT-Regel und eine Security-Policy-ID mit dem jeweiligen Modul.

Ist unter Diagnostics > Packet capture gleichzeitig ein Packet Capture aktiv, kann Open PCAP beim passenden Logeintrag die zugehörigen Paketinformationen öffnen. Die Funktion verbindet Logentscheidung und Paketdetails, ersetzt aber keinen sauber begrenzten Capture-Filter: Source, Destination, Port und Testzeit müssen weiterhin zum untersuchten Flow passen.

Den richtigen Flow eingrenzen

Filter so setzen, dass der richtige Flow übrig bleibt

Im Log Viewer stehen vier Filterebenen zur Verfügung:

1. Module: Begrenzt die Ansicht auf Firewall, Web, IPS, VPN oder ein anderes Fachgebiet.
2. Time: Begrenzt die Ereignisse auf den Testzeitraum.
3. Add filter: Verknüpft ein konkretes Feld, eine Bedingung und einen Wert.
4. Free text search: Sucht beispielsweise nach Port, IP-Adresse, Benutzer oder Regelname und funktioniert auch mit anonymisierten Informationen.

Für einen normalen Verbindungstest beginnt man mit Source-IP, Destination-IP und Destination-Port. Danach wird mit Rule ID, Benutzer oder Action weiter eingegrenzt. Reset entfernt alle gesetzten Filter. Das ist wichtig, weil ein alter Zeit- oder Feldfilter leicht den Eindruck erweckt, der Viewer erhalte keine neuen Events.

Die Anzahl verfügbarer Einträge hängt von der Festplattengrösse und lokalen Aufbewahrung ab. Der Log Viewer ist deshalb kein Ersatz für eine langfristige, manipulationsgeschützte Ablage. Dafür passen Central Firewall Reporting oder Syslog an ein SIEM senden.

Pause, Refresh und CSV-Export richtig verwenden

Pause stoppt die automatische Aktualisierung der Ansicht. Das ist hilfreich, wenn eine Zeile in Ruhe gelesen oder kopiert werden soll. Es stoppt nicht die Protokollierung auf der Firewall. Refresh lädt die Ansicht manuell neu, und der Export lädt die aktuell verfügbaren Logs als CSV herunter.

Vor einem Export werden Modul, Zeitbereich und Filter dokumentiert. Die CSV kann interne IP-Adressen, Benutzernamen, URLs und Kommunikationsbeziehungen enthalten und gehört deshalb in einen geschützten Support- oder Analysepfad.

Wenn Data anonymization aktiv ist, werden identifizierende Werte wie Benutzername, IP-, MAC- und E-Mail-Adresse geschützt dargestellt. Sophos empfiehlt mindestens zwei berechtigte Personen: Ist die angemeldete Person selbst als Authorizer eingetragen, muss mindestens eine andere Person die Deanonymisierung freigeben. Ein Screenshot oder Export sollte trotzdem nur die für den Fall nötigen Zeilen enthalten.

Log suppression und Log occurrence verstehen

Unter System services > Log settings kann die Firewall aufeinanderfolgende, gleiche Firewall-Events unterdrücken. Das spart Speicher und Verarbeitung. Die Unterdrückung wirkt nicht nur lokal, sondern auch auf Sophos Fusion und konfigurierte Syslog-Ziele.

Im Log Viewer zeigt Log occurrence, wie oft ein zusammengefasstes Event aufgetreten ist. Eine einzelne Zeile kann deshalb viele Wiederholungen repräsentieren. Sie darf nicht automatisch als ein einzelnes Paket oder eine einzelne Verbindung gezählt werden.

Vor einer Änderung an Log suppression wird geprüft, ob das aktuelle Loggingvolumen wirklich die Ursache eines Problems ist. Für eine kurze Diagnose genügt meistens, Log occurrence bewusst zu lesen. Eine globale Abschaltung oder Aktivierung verändert auch die externen Logziele und sollte nicht nur für einen Screenshot erfolgen.

Befunde sicher einordnen

Invalid traffic richtig einordnen

Invalid traffic bedeutet, dass Conntrack ein Paket keiner aktuellen Verbindung zuordnen konnte. Das kann bei einem asymmetrischen Pfad, einer abgelaufenen Session, unerwarteten TCP-Flags oder zusätzlichen RST- und FIN-Paketen auftreten. Es ist nicht automatisch ein Angriff und nicht automatisch ein Firewall-Defekt.

Wenn gleichzeitig ein Verbindungsproblem besteht, werden beide Richtungen mit Packet Capture geprüft. Source, Destination, TCP-Flags, Interfaces und Zeitstempel müssen zum selben Flow gehören. Eine Erhöhung von Tcp Connection Establishment Idle Timeout kann die Anzahl solcher Logs reduzieren, behebt aber die zugrunde liegende Pfad- oder Sessionursache nicht. Der Wert wird deshalb nicht auf Verdacht geändert.

Den aktuellen globalen Wert zeigt in der Device Console der lesende Befehl show advanced-firewall; Sophos dokumentiert 10800 Sekunden beziehungsweise drei Stunden als Standard. Eine Änderung wirkt auf alle entsprechenden TCP-Sessions der Firewall. Vorher werden deshalb betroffene Anwendung, tatsächliche Leerlaufzeit und das Invalid-Traffic-Ereignis eindeutig korreliert. Ein höherer Timeout ist nur eine begründete Betriebsanpassung und keine Reparatur für asymmetrisches Routing oder verlorene Pakete.

Den vollständigen Drop-Ablauf mit Reason, Rule ID und der besonderen Firewall ID 0 erklärt Verworfene Pakete auf Sophos Firewall analysieren.

Regeln aus dem Log Viewer nur kontrolliert ändern

Der Log Viewer kann je nach Ereignis direkt zu Web Policies, Firewall-Regeln oder SSL/TLS-Regeln führen. Das ist praktisch, verkürzt aber nicht die technische Prüfung. Vor dem Bearbeiten werden Rule ID, Regelname, Position, Zonen, Objekte, Service, Benutzerbezug und vorhandene Sessions kontrolliert; zusätzlich werden die aktuellen Werte der zu ändernden Felder für den Rollback dokumentiert.

Bei SSL/TLS-Ereignissen führt Manage > Exclude je nach Match zu einer anderen Konfiguration: Domains und Subdomains landen in der Local TLS exclusion list, Webkategorien in den Ausnahmen der gewählten SSL/TLS-Regel und andere Eigenschaften in einer SSL/TLS-Regel mit passenden Benutzer- oder IP-Objekten. Für die Fehler-IDs 19004 und 19005 bietet der Log Viewer Exclude nicht an.

Ein Klick auf eine IPS Signature ID kann Disable signature for this IPS policy anbieten. Das ändert die aktive IPS Policy und nicht nur die Anzeige. Vorher werden betroffene Regel, Policy, Signatur, Schutzwirkung und Ausnahmeumfang dokumentiert; danach wird genau der bestätigte Flow erneut getestet.

Eine breite Allow-Regel, eine globale Web-Ausnahme oder deaktivierte TLS Inspection kann das Symptom verstecken und gleichzeitig eine neue Sicherheitslücke schaffen. Änderungen werden deshalb auf den bestätigten Flow begrenzt, in einem Wartungsfenster getestet und danach mit einem neuen Flow erneut im Log Viewer sowie bei Bedarf in Packet Capture abgenommen. Schlägt der Test fehl oder wird der Ausnahmeumfang zu gross, stellt man im verlinkten Regel- oder Policy-Objekt den zuvor dokumentierten Zustand wieder her und prüft erneut mit einem neuen Flow.

Wenn Logs fehlen oder auf dem anderen HA-Node liegen

Wenn erwartete Logs fehlen

Ein leerer Treffer wird in dieser Reihenfolge geprüft:

1. Pause, Modul, Zeitbereich und Filter kontrollieren, danach Reset und Refresh.
2. Rule Logging und Local reporting für den benötigten Logtyp prüfen.
3. Eine neue, bewusst beendete Verbindung mit bekannter Uhrzeit erzeugen.
4. Mit Packet Capture bestätigen, dass der Traffic die Firewall erreicht und welche Rule ID verarbeitet wird.
5. Andere Module auf Ereignisse desselben Flows prüfen.
6. Erst wenn die gesamte lokale Anzeige keine neuen Events erhält, den Viewer- oder Logdienstpfad untersuchen.

Der versionsgebundene Diagnosepfad für einen vollständig stehenden Viewer steht in Log Viewer zeigt keine neuen Logs. Ein Service-Restart oder Eingriff in die lokale Logdatenbank gehört nicht zu den allgemeinen Bedienungsschritten.

Log Viewer in HA-Umgebungen

Jeder HA-Node speichert nur die Logs und Reports des Traffics, den er selbst verarbeitet. Besonders bei Active-Active oder nach einem Failover kann der erwartete Eintrag deshalb auf dem anderen Node liegen. Zeitpunkt, Node-Rolle und Connection served by werden gemeinsam dokumentiert.

Für eine zentrale Sicht eignen sich Central Firewall Reporting oder Syslog. Sie ersetzen aber nicht die nodebezogene Prüfung, wenn es um einen konkreten HA-Rollenwechsel, einen lokalen Dienstfehler oder den Datenpfad zum Ereigniszeitpunkt geht.