Sophos Firewall Audit Trail Logs prüfen

Audit Trail Logs helfen, Konfigurationsänderungen auf der Sophos Firewall nachzuvollziehen. Das ist wichtig, wenn nach einem Change plötzlich eine Regel anders greift, ein Interface verändert wurde, ein Host-Objekt fehlt oder im Audit gefragt wird, wer wann welche Einstellung angepasst hat.

Seit Sophos Firewall v22 schreibt SFOS dafür detaillierte Einträge in configuration-audit.log. Die Logs zeigen nicht nur, dass etwas geändert wurde, sondern auch Werte vor und nach der Änderung. Mit SFOS 22.0 MR1 wurde zusätzlich die Nachvollziehbarkeit bei Änderungen über Sophos Central verbessert, weil bei Einzel-Firewall-Änderungen die Sophos Central Benutzeridentität protokolliert wird.

Welcher Logging-Artikel passt?

Audit Trail Logs sind nur ein Teil der Fehlersuche. Je nach Frage ist ein anderer Einstieg schneller:

Diese Trennung verhindert falsche Erwartungen. Der Audit Trail beantwortet Change-Fragen. Für Paketfluss, NAT, VPN, Web Protection, IPS oder Dienstfehler braucht man weiterhin Log Viewer, Packet Capture, Service-Logs, Central Reporting oder Syslog.

Wann Audit Trail Logs helfen

Audit Logs sind besonders nützlich, wenn die Frage nicht lautet “warum wurde Traffic blockiert?”, sondern “wer oder was hat die Konfiguration verändert?”.

Typische Fälle:

• Eine Firewall-Regel wurde geändert, verschoben oder gelöscht.
• Ein IP Host, FQDN Host oder Netzwerkobjekt wurde angepasst.
• Ein Interface oder eine VLAN-Konfiguration sieht anders aus als dokumentiert.
• Nach einem Wartungsfenster ist unklar, welche Änderung ein Problem ausgelöst hat.
• Ein MSP oder internes Team muss Änderungen mehreren Administratoren zuordnen.
• Für Compliance, NIS2, ISO 27001 oder interne Change-Prozesse wird ein Nachweis benötigt.

Für normale Traffic-Analyse bleiben andere Werkzeuge wichtiger. Wenn man prüfen will, welche Regel eine Verbindung erlaubt oder verworfen hat, passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Audit Logs ergänzen diese Analyse, wenn eine Konfigurationsänderung als Ursache vermutet wird.

Was configuration-audit protokolliert

configuration-audit zeichnet Konfigurationsänderungen auf, die Administratoren im WebAdmin oder über die CLI vornehmen. Erfasst werden unter anderem:

• Konfiguration vor der Änderung.
• Konfiguration nach der Änderung.
• Zeitstempel.
• Administrator-Identität.
• IP-Adresse des Administrators.
• verwendete Konsole beziehungsweise Zugriffsmethode.

Die Einträge werden in configuration-audit.log gespeichert und im XML-Format geschrieben. Dadurch sind sie sehr detailliert, aber nicht immer angenehm zu lesen. Für eine schnelle Sichtprüfung reicht oft die Suche nach Objektname, Admin, IP-Adresse oder Zeitfenster. Für grössere Analysen kann es sinnvoll sein, die Datei extern zu durchsuchen oder in ein Loganalyse-Werkzeug zu übernehmen.

Aktueller Funktionsumfang

Der Audit Trail deckt aktuell wichtige Konfigurationsobjekte ab, insbesondere:

• IP Hosts.
• Firewall-Regeln.
• Netzwerk-Interfaces, einschliesslich physischer, virtueller, drahtloser und Cellular-WAN-Interfaces.
• Ab SFOS v22 gehört zusätzlich Hosts and services zu den unterstützten Bereichen.

Das ist für viele Change-Analysen bereits sehr hilfreich, aber noch kein vollständiges Change-Management-System. Audit Trail Logs ersetzen keine Change-Dokumentation, kein Ticket und kein Vier-Augen-Prinzip.

⚠️ Audit Logs beweisen, dass eine Änderung protokolliert wurde. Die Logs erklären aber nicht automatisch, ob die Änderung fachlich korrekt, genehmigt oder vollständig getestet war.

configuration-audit Status prüfen

Die Konfiguration erfolgt in der Device Console, nicht in der Advanced Shell.

Den Status prüft man mit:

system configuration-audit show

Wenn die Funktion aktiv ist, sollte die Firewall melden, dass Configuration Audit eingeschaltet ist. Wenn unklar ist, ob man in der richtigen Konsole arbeitet, hilft die Unterscheidung in Sophos Firewall Troubleshooting: Services und Logs.

Audit Trail aktivieren oder deaktivieren

Audit Logging ist standardmässig aktiviert. Falls es deaktiviert wurde, kann man es in der Device Console wieder einschalten:

system configuration-audit enable

Deaktivieren ist technisch möglich:

system configuration-audit disable

In produktiven Umgebungen sollte Audit Logging normalerweise aktiv bleiben. Wenn es aus einem bestimmten Grund deaktiviert wird, sollte das selbst dokumentiert und zeitlich begrenzt sein.

⚠️ Audit Logging sollte nicht als erste Massnahme deaktiviert werden, nur weil die Datei gross oder schwer lesbar wirkt. Gerade bei Störungen nach Changes sind diese Daten oft der entscheidende Nachweis.

configuration-audit.log herunterladen

Die Datei heisst:

configuration-audit.log

Der Download erfolgt über die Troubleshooting Logs. Der WebAdmin-Pfad lautet:

Diagnostics > Tools > Troubleshooting logs

Dort kann man einzelne Logdateien herunterladen oder einen Consolidated troubleshooting report (CTR) erzeugen. Für eine gezielte Audit-Analyse ist der einzelne Download der Audit-Datei oft praktischer als ein vollständiger CTR.

Wenn Logs für Support oder externe Analyse gesammelt werden sollen, passt zusätzlich Sophos Firewall Logs für Support und Analyse sichern. Für direkte Shell-Analysen ist Sophos Firewall per SSH verbinden relevant.

Audit Trail auswerten

Für eine saubere Analyse sollte man zuerst den Zeitraum eingrenzen.

Praktischer Ablauf:

1. Zeitpunkt des Problems oder Changes bestimmen.
2. configuration-audit.log herunterladen.
3. Nach Administrator, Objektname, Regelname, Interface oder IP-Adresse suchen.
4. Den Wert vor und nach der Änderung vergleichen.
5. Die Änderung mit Ticket, Wartungsfenster oder Change-Dokumentation abgleichen.
6. Bei Traffic-Problemen zusätzlich Log Viewer und Packet Capture prüfen.

Besonders hilfreich sind Audit Logs bei Regelwerksproblemen. Wenn eine Regel plötzlich nicht mehr greift, zeigt der Log Viewer nur den aktuellen Zustand. Der Audit Trail kann zeigen, ob kurz vorher Quelle, Ziel, Dienst, Security Feature, Regelposition oder Objektinhalt verändert wurde.

Audit Trail im Supportfall richtig verwenden

In Supportfällen ist der Audit Trail am stärksten, wenn er mit einem konkreten Zeitfenster und einem reproduzierbaren Symptom kombiniert wird. Eine komplette configuration-audit.log ohne Kontext ist schwer auszuwerten. Besser ist ein kurzes Change-Protokoll, das die wichtigsten Anker liefert.

Wenn eine Änderung über Sophos Central ausgelöst wurde, sollte zusätzlich die Central Task Queue geprüft werden. Die Task Queue zeigt, ob Central den Auftrag verarbeitet hat. Der Audit Trail zeigt danach, was lokal auf der Firewall nachvollziehbar ist.

Änderungen über Sophos Central

SFOS 22.0 MR1 verbessert die Nachvollziehbarkeit bei Konfigurationsänderungen über Sophos Central. Wenn eine einzelne Firewall über Sophos Central konfiguriert wird, erscheint die Sophos Central Benutzeridentität im Audit-Kontext. Diese Information ist im Log Viewer der Firewall sowie in Sophos Central Logs und Reports verfügbar.

Das ist wichtig für Umgebungen mit mehreren Administratoren oder MSP-Betrieb. Ein generischer Central-Zugriff reicht für saubere Nachvollziehbarkeit nicht aus. Es sollte klar sein:

• Welche Personen haben Zugriff auf Sophos Central?
• Arbeiten Admins mit eigenen Benutzerkonten statt geteilten Logins?
• Ist MFA in Sophos Central und auf der Firewall aktiv?
• Werden Central Logs ausreichend lange aufbewahrt?
• Gibt es einen Prozess, um Changes aus Central mit Tickets abzugleichen?

Die Verbindung zwischen Firewall und Central ist im Artikel Sophos Firewall mit Sophos Central verbinden eingeordnet. Für längere Logaufbewahrung passt Central Firewall Reporting aktivieren.

HA-Cluster beachten

In HA-Umgebungen erzeugt Sophos laut Dokumentation Audit Logs nur auf dem Gerät, das gerade aktiv ist. Bei Analysen nach einem Failover muss man deshalb auf den Rollenwechsel achten.

Wichtige Fragen:

• Welche Firewall war zum Zeitpunkt der Änderung aktiv?
• Gab es kurz vorher oder danach einen Failover?
• Sind Logdateien beider Geräte relevant?
• Wurde die Änderung sauber auf den Cluster synchronisiert?

Für HA-Betrieb und Loginterpretation passt Sophos Firewall High Availability einrichten.

Validierung nach einem Change

Der Audit Trail zeigt, dass ein Objekt geändert wurde. Danach muss aber geprüft werden, ob die Änderung den gewünschten Effekt hat und keine Nebenwirkung erzeugt. Gerade bei Firewall-Regeln, Interfaces, VPNs und Host-Objekten sollte man deshalb nicht beim Audit Log stehen bleiben.

Ein sinnvoller Ablauf nach kritischen Changes:

1. Änderung im Audit Trail nach Zeitfenster und Objektname finden.
2. Vorher-/Nachher-Wert mit Ticket oder Change-Dokumentation vergleichen.
3. Betroffene Firewall-Regel, NAT-Regel, Route oder Schnittstelle im WebAdmin prüfen.
4. Konkreten Testtraffic erzeugen.
5. Log Viewer, Policy Test und Packet Capture gegenprüfen.
6. Bei Central-Änderungen zusätzlich Task Queue und Central Logs prüfen.
7. Bei HA-Clustern Rollenstatus und Synchronisation kontrollieren.

Damit wird aus dem Audit Trail ein belastbarer Nachweis statt nur ein Logfund. Wenn der Audit Trail eine Änderung zeigt, der Testtraffic aber weiterhin falsch läuft, liegt die Ursache oft in Regelreihenfolge, NAT, Routing, Benutzerzuordnung, Security Feature oder Rückweg.

Grenzen und typische Stolperfallen

Audit Log ist kein Backup

Der Audit Trail zeigt Änderungen, ersetzt aber kein Konfigurationsbackup. Vor grösseren Änderungen braucht es weiterhin ein vollständiges Backup und einen Rollback-Plan. Das ist im Artikel Sophos Firewall Backup erstellen oder wiederherstellen beschrieben.

XML ist detailliert, aber nicht schön

Die Datei ist für Maschinen und genaue Vergleiche gut, für schnelle Lesbarkeit aber sperrig. Wenn man viele Changes vergleichen muss, kann Sophos Firewall Config Studio oder ein externes Diff-/Logwerkzeug sinnvoller sein.

Nicht jede Analyse gehört in den Audit Trail

Wenn eine Verbindung nicht funktioniert, zuerst den Traffic prüfen. Audit Logs sind dann relevant, wenn eine Änderung als Ursache infrage kommt. Für Live-Troubleshooting sind Log Viewer, Policy Test, Packet Capture und Service-Logs oft direkter.

Geteilte Admin-Konten schwächen den Nachweis

Wenn mehrere Personen denselben Admin-Account verwenden, ist der Audit Trail weniger aussagekräftig. Named Admins, Rollen, MFA und saubere Central-Benutzer sind deshalb Teil des Betriebsmodells, nicht nur ein Security-Extra.

Betriebscheckliste

• system configuration-audit show prüfen.
• Audit Logging aktiviert lassen.
• Named Admin Accounts statt geteilter Logins verwenden.
• MFA für WebAdmin, VPN Portal und Remote Access prüfen.
• Changes mit Ticket oder Wartungsfenster dokumentieren.
• Vor grösseren Änderungen Backup erstellen.
• Nach Problemen configuration-audit.log nach Zeitfenster und Objektname durchsuchen.
• Vorher-/Nachher-Werte mit der erwarteten Änderung vergleichen.
• Bei Regel-, NAT- oder VPN-Problemen Log Viewer und Packet Capture ergänzen.
• Bei HA-Clustern aktive Node und Failover-Zeitpunkt berücksichtigen.
• Central-Änderungen mit Sophos Central Logs und Reports abgleichen.

Für MFA auf der Firewall passt MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren. Für Management-Zugriffe sollte zusätzlich Device Access richtig konfigurieren geprüft werden.

FAQ