Sophos Firewall Config Studio nutzen

Sophos Firewall Config Studio ist ein browserbasiertes Sophos Werkzeug, mit dem man Firewall-Konfigurationen anzeigen, vergleichen und vorbereiten kann. Besonders nützlich ist es, wenn man nicht nur wissen will, dass sich etwas geändert hat, sondern welche Regel, welches Objekt oder welche Einstellung betroffen ist.

In der Praxis passt Config Studio gut zu drei Situationen:

Vor und nach einem Wartungsfenster zwei Konfigurationen vergleichen.
Eine bestehende Firewall-Konfiguration für Review, Übergabe oder Audit lesbarer machen.
Änderungen vorbereiten, bevor sie auf einer produktiven Firewall umgesetzt werden.

Config Studio ersetzt aber kein Backup, keinen Change-Prozess und keinen Test. Es ist ein Analyse- und Vorbereitungstool. Änderungen müssen weiterhin kontrolliert geprüft, dokumentiert und mit einem Rollback-Plan abgesichert werden.

Videoanleitung

Das Video zeigt Config Studio als Werkzeug zum Anzeigen, Vergleichen und Vorbereiten von Sophos Firewall Konfigurationen.

Was Config Studio kann

Config Studio ist der Nachfolger beziehungsweise die Weiterentwicklung des früheren Sophos Firewall Configuration Viewer. Für den Betrieb sind vor allem drei Funktionen relevant:

Funktion	Nutzen im Alltag
Configuration report	Regeln, Policies und Einstellungen in einem zusammenhängenden Report ansehen
Compare configurations	Zwei Konfigurationen vergleichen und hinzugefügte, geänderte, entfernte oder unveränderte Einträge erkennen
Configuration editor	Konfigurationen vorbereiten und anschliessend als Konfigurationsdatei, API- oder `curl`-Format weiterverwenden

Der wichtigste Mehrwert liegt im Vergleich. Wer nach einem Update, einer Migration oder einem Change wissen muss, was sich wirklich geändert hat, kommt mit einem sichtbaren Diff deutlich schneller weiter als mit manuellem Lesen von Backup-Dateien.

Wann man Config Studio einsetzen sollte

Config Studio lohnt sich vor allem bei Änderungen, die mehrere Bereiche der Firewall betreffen.

Typische Beispiele:

Migration von XG auf XGS.
Restore auf andere Hardware oder eine virtuelle Appliance.
Review eines grossen Firewall-Regelwerks.
Vergleich vor und nach einem Firmware-Update.
Prüfung nach einem grösseren NAT- oder VPN-Umbau.
Übergabe einer Firewall von einem Team an ein anderes.
Analyse nach einem ungeplanten Change.

Wenn es nur um eine einzelne Live-Verbindung geht, sind andere Werkzeuge meist direkter. Für Traffic-Probleme passen Log Viewer, Policy Test und Packet Capture besser. Der Artikel Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture zeigt diesen Ablauf.

Vorher ein sauberes Backup erstellen

Config Studio arbeitet mit Konfigurationsdaten. Deshalb sollte zuerst ein vollständiges und aktuelles Backup der Firewall erstellt werden.

Der WebAdmin-Pfad lautet:

Backup & Firmware > Backup & Restore

Für produktive Arbeiten empfiehlt sich dieser Ablauf:

Aktuelles Backup der Firewall erstellen.
Backup ausserhalb der Firewall sicher ablegen.
Wenn ein Change geplant ist, zusätzlich den gewünschten Zielzustand dokumentieren.
Nach dem Change ein zweites Backup erstellen.
Beide Konfigurationen in Config Studio vergleichen.

Das eigentliche Backup- und Restore-Thema ist im Artikel Sophos Firewall Backup erstellen oder wiederherstellen beschrieben. Dort sind auch Secure Storage Master Key, Restore-Kompatibilität und Interface-Mapping eingeordnet.

⚠️ Firewall-Backups enthalten sensible Informationen über Netzstruktur, Regeln, Objekte, VPNs und Dienste. Vor der Nutzung eines Analysewerkzeugs sollte intern klar sein, wo die Datei verarbeitet wird, wer Zugriff hat und wie sie danach wieder gelöscht oder archiviert wird.

Entities.xml sicher behandeln

Config Studio arbeitet mit der exportierten Konfiguration. Die Verarbeitung findet im Browser des Endgeräts statt; Konfigurationsdaten werden dabei nicht an einen externen Dienst hochgeladen. Trotzdem bleibt die Datei sicherheitsrelevant, weil sie die Firewall-Struktur sehr detailliert beschreibt.

Für den Betrieb sollte man deshalb nicht nur den Download der Datei planen, sondern auch den Umgang danach:

Datei nur auf einem vertrauenswürdigen Admin-Gerät öffnen.
Datei nicht über private Cloudspeicher, Messenger oder unkontrollierte E-Mail-Verteiler weitergeben.
Zugriff auf Change-, Audit- oder Migrationsbeteiligte begrenzen.
Datei nach Abschluss der Analyse löschen oder in einem definierten, geschützten Ablageort archivieren.
Bei Weitergabe an Support oder externe Partner zuerst klären, welche Daten enthalten sind und ob eine Freigabe besteht.

Besonders bei Audits und Migrationen ist eine einfache Namenskonvention hilfreich. Beispiel: firewall-standort-vor-change-2026-06-21.xml und firewall-standort-nach-change-2026-06-21.xml. Dadurch wird später klarer, welche Datei welchen Zustand abbildet und ob sie vor oder nach einem Wartungsfenster erstellt wurde.

Konfiguration als Report prüfen

Der Configuration Report hilft, eine Firewall strukturiert zu lesen. Das ist besonders nützlich, wenn man eine bestehende Umgebung übernimmt oder vor einem Audit verstehen muss, welche Regeln und Objekte vorhanden sind.

Beim Review sollte man nicht einfach nach “vielen Regeln” suchen. Wichtiger sind konkrete Betriebsfragen:

Gibt es Regeln mit sehr breiten Quellen, Zielen oder Services?
Sind alte VPN-, NAT- oder WAF-Regeln noch aktiv?
Gibt es Objekte, die mehrfach ähnlich benannt sind?
Sind Management-Zugriffe sauber auf eigene Netze beschränkt?
Sind Logging, IPS, Web Protection, TLS Inspection oder NDR bewusst gesetzt?
Passen Regelgruppen, Namen und Beschreibungen zum tatsächlichen Betrieb?

Für Management-Zugriffe sollte man zusätzlich Device Access richtig konfigurieren prüfen. Normale Firewall-Regeln steuern nicht, wer auf lokale Dienste der Firewall wie WebAdmin, SSH, User Portal oder VPN Portal zugreifen darf.

Zwei Konfigurationen vergleichen

Der Vergleich ist der stärkste Anwendungsfall von Config Studio. Man lädt zwei Konfigurationsstände und prüft danach, welche Einträge hinzugefügt, entfernt oder geändert wurden.

Sinnvolle Vergleichspaare sind:

Vergleich	Ziel
Backup vor Change vs. Backup nach Change	Kontrollieren, ob nur die geplanten Änderungen umgesetzt wurden
Backup vor Firmware-Update vs. nach Firmware-Update	Unerwartete Konfigurationsänderungen erkennen
alte Hardware vs. neue Hardware	Migration, Interface-Mapping und Objektzustand prüfen
produktive Firewall vs. Referenzkonfiguration	Standardabweichungen sichtbar machen
vor Störung vs. nach Störung	Verdächtige Änderungen eingrenzen

Der Vergleich ersetzt nicht den Audit Trail. Config Studio zeigt, was zwischen zwei Konfigurationen anders ist. Der Audit Trail hilft dagegen, wer wann welche Änderung vorgenommen hat. In einer sauberen Analyse nutzt man beides: erst den Zeitraum und Verantwortlichen über Audit Logs eingrenzen, danach den Konfigurationsunterschied im Detail prüfen.

Diff-Ergebnis einordnen

Ein Konfigurationsvergleich ist nur dann hilfreich, wenn das Ergebnis triagiert wird. Nicht jede Änderung ist fachlich relevant, und nicht jede fehlende Änderung ist automatisch unkritisch.

Beim Review sollte man die Unterschiede in Gruppen sortieren:

Änderungstyp	Typische Bewertung
Geplante Änderung	Mit Change-Ziel und Ticket abgleichen
Automatische oder systembedingte Änderung	Version, Firmware, Zertifikat, Objekt-ID oder interne Referenz prüfen
Unerwartete Änderung	Mit Audit Trail, Admin-Konto und Zeitpunkt abgleichen
Fehlende Änderung	Kontrollieren, ob der Change wirklich gespeichert, synchronisiert oder importiert wurde
Entferntes Objekt	Abhängigkeiten in Regeln, NAT, VPN, WAF und Device Access prüfen

Besonders wichtig sind Änderungen an Firewall-Regeln, NAT-Regeln, Interfaces, VPNs, Zertifikaten, Authentication, Device Access und Hosts and services. Bei diesen Bereichen kann ein kleiner Unterschied direkt beeinflussen, ob ein Dienst erreichbar bleibt, ob ein VPN-Tunnel routet oder ob ein Admin-Zugang aus dem richtigen Netz möglich ist.

Für produktive Change Reviews sollte man nicht nur das Config-Studio-Ergebnis speichern. Sinnvoll ist eine kurze Notiz: geprüfte Backup-Dateien, auffällige Objekte, erwartete Änderungen, unerwartete Änderungen, offene Fragen und Entscheidung, ob der Change abgeschlossen ist oder nachgearbeitet werden muss.

Änderungen vorbereiten

Config Studio kann Konfigurationen auch editieren beziehungsweise Änderungen als API- oder curl-Format bereitstellen. Das ist mächtig, sollte aber nicht als Abkürzung für ungeprüfte Massenänderungen verstanden werden. Wenn solche Exporte produktiv genutzt werden, sollte vorher der XML API Zugriff sauber eingeschränkt sein.

Vorbereitete Änderungen sollten mindestens diese Prüfpunkte durchlaufen:

Änderung in Config Studio vorbereiten.
Betroffene Objekte, Regeln und Abhängigkeiten prüfen.
Änderung wenn möglich in einer Test- oder Ersatzumgebung validieren.
Backup und Rollback-Plan für die produktive Firewall vorbereiten.
Änderung im Wartungsfenster einspielen.
Danach Log Viewer, betroffene Dienste und Konfigurationsvergleich prüfen.

Besonders vorsichtig sollte man bei NAT, VPN, Interfaces, Device Access, Authentication und HA-Konfigurationen sein. Ein scheinbar kleiner Unterschied kann dort direkten Einfluss auf Erreichbarkeit oder Failover-Verhalten haben.

⚠️ Editor-Ausgaben aus Config Studio sollten nie direkt aus dem Browser in eine produktive Firewall kopiert werden, ohne Abhängigkeiten, Backup, Test und Rollback zu prüfen. Das gilt besonders für Massenänderungen an Objekten, Regeln, VPNs und Interfaces.

Einsatz bei Migrationen

Bei Migrationen ist Config Studio ein gutes Hilfsmittel, aber nicht der erste Schritt. Zuerst sollte geprüft werden, ob das Backup zur Zielplattform passt.

Wichtige Fragen:

Wird von XG auf XGS migriert?
Ändert sich die Anzahl oder Reihenfolge der Interfaces?
Wird von Hardware auf virtuell oder Cloud gewechselt?
Ist ein HA-Cluster beteiligt?
Muss nach dem Restore ein Interface-Mapping angepasst werden?
Gibt es alte VPN-, RED-, Wireless- oder Legacy-Konfigurationen?

Config Studio sollte in diesem Ablauf an der richtigen Stelle eingesetzt werden. Es zeigt Unterschiede und hilft beim Review, entscheidet aber nicht allein, ob ein Restore technisch unterstützt ist oder ob die neue Firewall nach der Migration wirklich sauber arbeitet.

Schritt	Wofür er gedacht ist
Backup- und Restore-Kompatibilität prüfen	Klären, ob Quelle, Zielplattform, Firmware und Interface-Zuordnung grundsätzlich zusammenpassen
Restore in Test- oder Wartungsfenster durchführen	Konfiguration kontrolliert auf die Ziel-Firewall bringen
Config Studio Vergleich auswerten	Abweichungen zwischen altem und neuem Stand sichtbar machen
Funktionstest durchführen	VPN, NAT, WAF, Routing, DHCP, DNS, HA und Management-Zugriff mit echten Tests prüfen

Für die Abnahme reicht deshalb kein grünes Bauchgefühl nach dem Import. Man sollte vorher definieren, welche Dienste nach der Migration zwingend funktionieren müssen, welche Regeln kritisch sind und welche Messpunkte geprüft werden. Dazu gehören mindestens Log Viewer, Policy Test, Packet Capture, zentrale Logs und die wichtigsten Benutzer- oder Standorttests.

Für XG-zu-XGS-Projekte passt zusätzlich Was ist der Unterschied zwischen einer XG und XGS Firewall?. Wenn ein HA-Cluster im Spiel ist, sollte vor dem Restore auch Sophos Firewall High Availability einrichten berücksichtigt werden.

Troubleshooting bei Config-Studio-Analysen

Import funktioniert nicht

Wenn Config Studio eine Datei nicht laden kann, sollte zuerst geprüft werden, ob wirklich die richtige Exportdatei verwendet wurde. Für Config Studio ist die Entities.xml aus Backup & Firmware > Import export relevant, nicht irgendein komprimiertes Backup oder ein Screenshot aus der Firewall.

Zusätzlich prüfen:

Datei wurde vollständig heruntergeladen.
Browser blockiert lokale Datei- oder JavaScript-Funktionen nicht.
Datei stammt von einer unterstützten Sophos-Firewall-Version.
Export wurde nicht nachträglich manuell bearbeitet.

Diff enthält sehr viele Änderungen

Viele Unterschiede bedeuten nicht automatisch, dass ein Change schlecht war. Bei Firmware-Updates, Migrationen oder Restore-Tests können systembedingte Änderungen auftauchen. Entscheidend ist, ob die fachlich relevanten Bereiche plausibel sind: Regeln, NAT, Interfaces, VPN, Zertifikate, Authentication, Hosts and services und Device Access.

Wenn der Vergleich unübersichtlich wird, sollte man zuerst nach Modulen filtern und nicht alles gleichzeitig bewerten. Für Störungen nach einem Change ist oft die Kombination aus Config Studio, Audit Trail, Log Viewer und Packet Capture schneller als ein vollständiger manueller Review aller Objekte.

Editor-Export passt nicht zum geplanten Import

Wenn ein vorbereiteter Export nicht wie erwartet passt, sollte die Änderung nicht improvisiert produktiv eingespielt werden. Zuerst prüfen:

Wurde die richtige Ausgangskonfiguration verwendet?
Gibt es abhängige Objekte, die im Zielsystem fehlen?
Stimmen Namen, Zonen, Interfaces und Services mit der Ziel-Firewall überein?
Ist der XML API Zugriff für das verwendete Konto erlaubt und ausreichend begrenzt?
Gibt es ein aktuelles Backup und einen Rückweg?

Bei API- oder curl-Ausgaben gehört die Prüfung des API-Kontos, der Quell-IP und der Rechte zum Change. Der Artikel Sophos Firewall XML API Zugriff absichern beschreibt diesen Teil genauer.

Typische Fehler

Fehler	Auswirkung
Kein frisches Backup vor dem Change	Der Vergleich ist unvollständig oder der Rollback unsicher
Backup-Dateien unkontrolliert weitergegeben	Sensible Firewall-Informationen landen ausserhalb des vorgesehenen Kreises
Diff wird ohne Kontext interpretiert	Automatische oder systembedingte Änderungen werden mit fachlichen Changes verwechselt
Editor-Ausgabe ungeprüft eingespielt	Falsche Abhängigkeiten können Regeln, NAT, VPN oder Interfaces stören
Audit Trail wird ignoriert	Es ist sichtbar, was anders ist, aber nicht sauber, wer es geändert hat
HA- oder Migrationskontext fehlt	Interface-Mapping, Rolle der Nodes oder Plattformunterschiede werden übersehen
Exportdateien werden schlecht benannt	Vorher-/Nachher-Stände werden verwechselt

Checkliste für Admins

Vor der Nutzung:

Aktuelles Backup erstellen.
Zugriff auf Backup-Dateien intern regeln.
Entities.xml nur auf einem vertrauenswürdigen Admin-Gerät verarbeiten.
Ziel der Analyse festlegen: Audit, Migration, Change Review oder Troubleshooting.
Relevante Zeitpunkte und Change-Tickets bereitlegen.

Beim Vergleich:

Richtige Backup-Versionen auswählen.
Hinzugefügte, entfernte und geänderte Einträge getrennt prüfen.
Firewall-Regeln, NAT, Interfaces, Hosts and services, VPN und Device Access besonders beachten.
Auffällige Änderungen mit configuration-audit.log abgleichen.
Unerwartete Änderungen dokumentieren und einer verantwortlichen Person zuordnen.

Nach der Analyse:

Ergebnis dokumentieren.
Unerwartete Unterschiede klären.
Bei produktiven Änderungen neuen Backup-Stand sichern.
Falls ein Restore oder Import geplant ist, vorher Rollback und Wartungsfenster festlegen.

FAQ

Was ist Sophos Firewall Config Studio?

Sophos Firewall Config Studio ist ein browserbasiertes Sophos Werkzeug zum Anzeigen, Vergleichen und Vorbereiten von Sophos-Firewall-Konfigurationen. Es ersetzt den früheren Configuration Viewer und ergänzt ihn um Vergleichs- und Editor-Funktionen.

Ersetzt Config Studio ein Firewall Backup?

Nein. Config Studio nutzt Konfigurationsdaten zur Analyse oder Vorbereitung. Ein sauberes Backup und ein Rollback-Plan bleiben vor Änderungen weiterhin Pflicht.

Wann ist der Konfigurationsvergleich besonders hilfreich?

Der Vergleich ist besonders hilfreich nach Wartungsfenstern, Firmware-Updates, Migrationen, Restore-Tests oder ungeplanten Änderungen. Man sieht dadurch schneller, welche Regeln, Objekte oder Einstellungen wirklich anders sind.

Was ist der Unterschied zwischen Config Studio und Audit Trail Logs?

Config Studio zeigt Unterschiede zwischen Konfigurationsständen. Audit Trail Logs zeigen, wann und durch wen bestimmte Änderungen vorgenommen wurden. Für Change-Analysen sind beide Werkzeuge zusammen am stärksten.

Kann man Änderungen direkt aus Config Studio produktiv übernehmen?

Änderungen können vorbereitet und je nach Workflow als Konfiguration, API- oder curl-Format weiterverwendet werden. Produktiv sollte das nur nach Prüfung, Backup, Test und Rollback-Plan erfolgen.