Sophos Firewall Log Viewer richtig nutzen
Der Log Viewer ist 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
- In der betroffenen Firewall-Regel Log firewall traffic beziehungsweise in der SSL/TLS-Regel Log connections prüfen.
- Unter System services > Log settings sicherstellen, dass der benötigte Logtyp bei Local reporting aktiviert ist.
- Oben rechts im WebAdmin Log viewer öffnen und das fachlich passende Modul wählen.
- Zeitfilter setzen und über Add filter zuerst Source-IP, Destination-IP und Service eingrenzen.
- Einen neuen, kurzen Testflow erzeugen und seine genaue Uhrzeit notieren.
- In Detailed view Rule ID, NAT ID, Action, Interfaces, Benutzer und modulspezifische Felder prüfen.
- 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?
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 Zeitstempel und dieselben 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.
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.
Filter so setzen, dass der richtige Flow übrig bleibt
Im Log Viewer stehen vier Filterebenen zur Verfügung:
- Module: Begrenzt die Ansicht auf Firewall, Web, IPS, VPN oder ein anderes Fachgebiet.
- Time: Begrenzt die Ereignisse auf den Testzeitraum.
- Add filter: Verknüpft ein konkretes Feld, eine Bedingung und einen Wert.
- 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. Zur Deanonymisierung braucht es eine berechtigte Person und deren Anmeldedaten. 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 Central 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.
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 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.
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.
Wenn erwartete Logs fehlen
Ein leerer Treffer wird in dieser Reihenfolge geprüft:
- Pause, Modul, Zeitbereich und Filter kontrollieren, danach Reset und Refresh.
- Rule Logging und Local reporting für den benötigten Logtyp prüfen.
- Eine neue, bewusst beendete Verbindung mit bekannter Uhrzeit erzeugen.
- Mit Packet Capture bestätigen, dass der Traffic die Firewall erreicht und welche Rule ID verarbeitet wird.
- Andere Module auf Ereignisse desselben Flows prüfen.
- 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.
Warum erscheint eine erlaubte Verbindung erst später im Log Viewer?
Destroy-Event protokolliert, wenn die Verbindung endet. Eine lange oder wiederverwendete Session kann deshalb erst verspätet erscheinen. Für den Test wird eine neue, kurze und bewusst beendete Verbindung erzeugt.