Sophos Firewall Konfigurationsänderungen mit Audit Trail prüfen

Mit Configuration Audit lässt sich ab SFOS 22 nachvollziehen, wer eine unterstützte Konfiguration wann und mit welchen Vorher-/Nachher-Werten geändert hat. Das ist der richtige Einstieg, wenn nach einem Change eine Firewall-Regel, ein Host-Objekt oder ein Interface anders aussieht als erwartet.

Der schnellste Ablauf ist: Status in der Device Console prüfen, configuration-audit.log herunterladen oder in der Advanced Shell durchsuchen, Änderung mit Ticket und Zeitfenster abgleichen und die technische Wirkung separat testen.

⚠️ Der Audit Trail zeigt eine protokollierte Änderung. Er beweist nicht automatisch, dass diese genehmigt, fachlich korrekt oder erfolgreich getestet war, und ersetzt weder Backup noch Change-Dokumentation.

Configuration Audit in vier Schritten prüfen

1. Status in der Device Console kontrollieren

Configuration Audit ist standardmässig aktiv. Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell.

system configuration-audit show

Falls die Funktion deaktiviert ist:

system configuration-audit enable

Das Deaktivieren ist technisch möglich, sollte in produktiven Umgebungen aber nur begründet und zeitlich begrenzt erfolgen:

system configuration-audit disable

⚠️ Audit Logging nicht als erste Massnahme deaktivieren, nur weil die Datei gross oder schwer lesbar wirkt. Gerade nach einer Störung können diese Einträge der entscheidende Change-Nachweis sein.

2. Logdatei im WebAdmin herunterladen

Die Datei heisst configuration-audit.log. Im WebAdmin findet man sie unter:

Diagnostics > Tools > Troubleshooting logs

Für eine gezielte Analyse die einzelne Datei auswählen und herunterladen. Ein Consolidated troubleshooting report (CTR) ist sinnvoll, wenn Sophos Support zusätzlich Systemzustand und weitere Logs benötigt; bestimmte Service-Subsystem-Logs im CTR können jedoch durch das konfigurierte Zeilenlimit begrenzt sein.

3. Logdatei in der Advanced Shell durchsuchen

Nach der SSH-Anmeldung 5. Device Management und danach 3. Advanced Shell wählen. Ein Objektname lässt sich beispielsweise so suchen:

grep -i 'LAN_to_WAN' /log/configuration-audit.log

LAN_to_WAN durch den tatsächlichen Regel-, Host- oder Interface-Namen ersetzen. Neue Einträge lassen sich damit live mitlesen:

tail -f /log/configuration-audit.log

Die Live-Ausgabe mit Ctrl+C beenden. Für eine ruhige, seitenweise Ansicht kann less /log/configuration-audit.log verwendet werden. Die XML-Ausgabe kann lang sein; für einen Supportfall nur den relevanten Ausschnitt samt Zeitstempel sichern.

4. Änderung und Wirkung getrennt prüfen

Der Audit Trail beantwortet zuerst: Was wurde geändert? Danach muss ein Funktionstest zeigen, ob die Änderung den erwarteten Effekt hat. Bei Traffic-Problemen deshalb zusätzlich Log Viewer, Policy Test und Packet Capture verwenden. Der Ablauf steht in Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Was configuration-audit protokolliert

configuration-audit.log erfasst unterstützte Änderungen aus WebAdmin und CLI im XML-Format. Ein Eintrag kann enthalten:

• Konfiguration vor und nach der Änderung
• Zeitstempel
• Administrator-Identität und Quell-IP
• verwendete Konsole beziehungsweise Zugriffsmethode

Die aktuelle Ausbaustufe umfasst insbesondere Firewall-Regeln, IP Hosts beziehungsweise Hosts and services sowie Netzwerk-Interfaces. Bei Interfaces nennt Sophos physische, virtuelle, drahtlose und Cellular-WAN-Interfaces. Nicht jede Konfigurationsseite bietet dieselbe Detailtiefe; für NAT, Routing, VPN oder andere Funktionen darf kein vollständiger Audit-Trail-Scope vorausgesetzt werden.

Eine Description oder ein Ticket erklärt, warum ein Objekt existieren soll. Der Audit Trail zeigt, was an einem unterstützten Objekt tatsächlich geändert wurde. Für einen vollständigen Nachweis werden beide Informationen benötigt.

Was der Audit Trail nicht ersetzt

• Traffic-Analyse: Für erlaubte oder verworfene Verbindungen bleiben Log Viewer und Packet Capture entscheidend.
• Backup und Rollback: Vor grösseren Änderungen braucht es weiterhin ein aktuelles Backup und einen Rückweg.
• Vollständiges Change Management: Genehmigung, Verantwortlichkeit, Test und Abnahme gehören in Ticket oder Wartungsprotokoll.
• Konfigurationsvergleich: Sophos Firewall Config Studio vergleicht vollständige Konfigurationsexporte, liest aber nicht configuration-audit.log aus.

Eine Änderung belastbar auswerten

Änderung finden und belegen

Ein effizienter Prüfablauf:

1. Problem- oder Change-Zeitpunkt mit Zeitzone festlegen.
2. Betroffenes Objekt bestimmen, beispielsweise Regelname, Host, Interface oder VLAN.
3. configuration-audit.log nach Objektname, Administrator, IP-Adresse oder Zeitfenster durchsuchen.
4. Alten und neuen Wert vergleichen.
5. Änderung mit Ticket, Wartungsfenster und verantwortlichem Admin abgleichen.
6. Relevanten XML-Ausschnitt zusammen mit Zeitfenster und Objektname sichern.

Bei einer Firewall-Regel können beispielsweise Quelle, Ziel, Dienst, Regelposition oder aktivierte Schutzfunktionen verändert worden sein. Die konkrete Änderung muss aus dem Eintrag gelesen werden; die Liste ist keine Garantie, dass jedes Unterfeld in jedem Build identisch dargestellt wird.

Für Sophos Support sind folgende Angaben besonders hilfreich:

• exakte Uhrzeit mit Zeitzone
• betroffenes Objekt und erwarteter Zustand
• tatsächliches Fehlerbild
• beteiligter Admin oder Central-Benutzer
• relevanter Vorher-/Nachher-Wert
• Ticketnummer und durchgeführter Funktionstest

Die vollständige XML-Datei kann interne IP-Adressen, Objektnamen und Administratordaten enthalten. Exporte deshalb zugriffsgeschützt speichern und vor der Weitergabe auf unnötige Kundendaten prüfen. Weitere Hinweise enthält Sophos Firewall Logs für Support und Analyse sichern.

Technische Wirkung testen

Nach einer Änderung an Regel, Host oder Interface nicht beim Logfund stehen bleiben:

1. Aktuelle Konfiguration im WebAdmin prüfen.
2. Definierten Testtraffic erzeugen.
3. Regel-ID, NAT, Route und Rückweg im passenden Werkzeug kontrollieren.
4. Bei HA zusätzlich Rollenstatus und Synchronisation prüfen.
5. Ergebnis und allfällige Abweichungen im Change dokumentieren.

Bei NAT-, Routing- oder VPN-Änderungen kann configuration-audit.log nur unterstützte beteiligte Objekte zeigen. Die Funktion selbst muss über ihre aktuelle Konfiguration, Event- und Service-Logs sowie bei Bedarf Packet Capture validiert werden.

Änderungen über Sophos Central einordnen

Seit SFOS 22.0 MR1 wird bei Änderungen an einer einzelnen Firewall über Sophos Central die Central-Benutzeridentität protokolliert. Sophos bestätigt diese Information im Firewall Log Viewer sowie in Sophos Central Logs and Reports. Daraus folgt nicht automatisch, dass die Central-Identität in jedem Fall in configuration-audit.log steht.

Die Central Audit Logs befinden sich unter:

Reports > General logs > Audit Logs

Die Ansicht zeigt standardmässig 7 Tage und kann Aktivitäten bis 90 Tage anzeigen. Die Suche ist auf IP address und Modified by ausgerichtet. Beim Export gilt:

• CSV/PDF of current view: übernimmt die aktuell gesetzten Filter.
• CSV/PDF of past 90 days: exportiert die letzten 90 Tage; der Suchfilter gilt, der ausgewählte Datumsbereich nicht.

Für längere Nachweise müssen die Exporte regelmässig erstellt und geschützt archiviert werden. Central Firewall Reporting verlängert die 90-Tage-Grenze der allgemeinen Central Audit Logs nicht.

Wann die Task Queue hilft

Die Task Queue ist kein allgemeiner Nachweis für jede Central-Änderung. Der richtige Prüfpfad hängt vom Auftrag ab:

• Direkt geöffnete Einzel-Firewall: Central Audit Logs und Firewall Log Viewer prüfen; bei unterstützten Objekten zusätzlich configuration-audit.log.
• Firewall-Gruppenrichtlinie: Status in der Sophos Central Firewall Management Task Queue prüfen. Kommt der Gruppenrichtlinien-Push lokal nicht an, zusätzlich fwcm-updaterd.log auswerten.
• MDR Settings oder MDR IOCs aus der Firewall Configuration API: Firewall Task Queue und bei Bedarf fwcm-api-executor.log verwenden.

Named Central-Benutzer ermöglichen eine belastbare Zuordnung. Passende Rollen und MFA schützen die administrativen Zugänge. Die Rollen werden in Sophos Central administrative Rollen für Firewall Management erklärt.

HA und Aufbewahrung beachten

Sophos dokumentiert, dass Audit Logs nur erzeugt werden, wenn ein Gerät Active ist. Das ist je nach HA-Modus unterschiedlich zu bewerten:

• Bei Active-Passive ist normalerweise die zum Change-Zeitpunkt aktive Appliance relevant.
• Bei Active-Active kann auch die Auxiliary Appliance aktiv sein und relevante node-lokale Logs besitzen.
• Nach einem Failover können benötigte Zeitfenster auf verschiedenen Geräten liegen.

Logs und Reports werden zwischen HA-Nodes nicht synchronisiert. Für eine vollständige Analyse daher HA-Modus, Rollenwechsel und Zeitfenster dokumentieren und die Troubleshooting Logs der relevanten Appliances separat laden. Die Konfigurationsverwaltung und Synchronisation des Clusters beschreibt Sophos Firewall High Availability einrichten.

Auch lokal gibt es keine dokumentierte feste Aufbewahrung von 7, 30 oder 90 Tagen für configuration-audit.log. Troubleshooting Logs rotieren abhängig von Komponente, Modell und zugewiesenem Speicherplatz; alte Rotationen können komprimiert und später gelöscht werden. Für Audit- oder Compliance-Nachweise die benötigten Dateien deshalb rechtzeitig exportieren.

Betriebscheckliste

• system configuration-audit show regelmässig prüfen und Audit Logging aktiviert lassen.
• Persönliche Admin-Konten, passende Rollen und MFA für administrative Zugänge verwenden. Den vollständigen Lebenszyklus erklärt Sophos Firewall Administratoren und Profile sicher einrichten.
• Changes mit Ticket, Zeitfenster, Objekt und erwartetem Test dokumentieren.
• Vor grösseren Änderungen Backup und Rollback-Plan bereitstellen.
• configuration-audit.log nach Zeitfenster, Objekt und Admin durchsuchen.
• Vorher-/Nachher-Werte mit dem genehmigten Change abgleichen.
• Die technische Wirkung mit Log Viewer und echtem Testtraffic validieren.
• Bei Central je nach Auftrag Audit Logs, Log Viewer oder die passende Queue verwenden.
• Bei HA relevante Nodes und Failover-Zeitpunkt berücksichtigen.
• Benötigte Auditdaten vor der Rotation geschützt exportieren.

FAQ