Sophos Firewall Configuration Viewer: Konfig prüfen und vergleichen

19. Februar 2026 • 14 min read

Inhaltsverzeichnis

Hallo zusammen,

wer schon einmal eine Sophos-Firewall in einem echten Betrieb betreut hat, kennt das Dilemma: Die Konfiguration ist der “Single Source of Truth”. Aber sobald man sie außerhalb der Web-UI nachvollziehen, dokumentieren oder mit einem Vorher/Nachher vergleichen will, wird es mühsam.

Ja, du kannst Screenshots machen. Ja, du kannst einzelne Regeln exportieren. Aber sobald es um größere Änderungen geht (WAN-Migration, neue VLANs, Cleanup von Objekten, Umbau der NAT-Logik, “nur kurz” ein paar VPNs anpassen), willst du eigentlich nur zwei Dinge:

Eine Konfiguration, die lesbar ist.
Einen Vergleich, der nicht aus “XML diffen und weinen” besteht.

Genau hier setzt der Sophos Firewall Configuration Viewer an.

Das Tool nimmt dir nicht die Verantwortung ab, eine Konfiguration sauber zu designen oder Changes gut zu testen. Aber es nimmt dir etwas ab, das im Alltag unglaublich viel Zeit frisst: das Format-Problem. Aus einem Export, der normalerweise nach “technisch korrekt” aussieht, macht es eine Ansicht, mit der du wirklich arbeiten kannst.

Und ja: Ich bin da ziemlich pingelig. Wenn ich einen Change plane, will ich nicht nur wissen, dass ich etwas geändert habe, sondern was genau sich geändert hat, und ob ich aus Versehen irgendwo am Rand noch ein Objekt, eine NAT-Regel oder ein VPN-Setting angefasst habe. Der Viewer ist dafür ein erstaunlich pragmatischer Helfer.

Was ist der Sophos Firewall Configuration Viewer?

Der Sophos Firewall Configuration Viewer ist ein browserbasiertes Tool, das Sophos-Firewall-Konfigurationen in eine menschlich lesbare Darstellung umwandelt. Du kannst damit:

die Konfiguration filtern, sortieren und durchsuchen
gezielt nach Objekten/Hosts/FQDNs suchen und ihre Referenzen finden
zwei Konfigurationen gegeneinander vergleichen (Added/Modified/Removed)
die Ergebnisse als HTML-Report exportieren

Wichtig: Das ist ein Standalone-Tool, das du einfach im Browser öffnest. Du musst nichts installieren und kannst es prinzipiell von jedem Admin-Notebook aus nutzen. Genau das macht es für mich so attraktiv, weil es sich schnell in bestehende Abläufe einschleift.

Im Kern arbeitet der Viewer mit dem, was Sophos ohnehin bereitstellt: dem Konfig-Export als XML (typischerweise Entities.xml). Der Unterschied ist die Aufbereitung. Statt in XML-Strukturen zu starren, bekommst du eine Ansicht, die eher wie eine sehr gut sortierte Dokumentation wirkt.

Und der Viewer ist nicht nur “View”. In der Praxis sind es drei Funktionen, die immer wieder hängen bleiben:

Lesen: Konfiguration in Klartext-Struktur, filterbar.
Suchen/Referenzen: Objekte finden und sehen, wo sie verwendet werden.
Vergleichen: Vorher/Nachher oder Firewall A gegen Firewall B.

Der wichtigste Punkt für Security und Datenschutz: Sophos betont, dass die Daten lokal im Browser verarbeitet werden und nichts “hochgeladen” wird. Parsing, Analyse und Report-Generierung sollen auf deinem Gerät bleiben.

Das Tool findest du hier: Sophos Firewall Configuration Viewer

Wenn du lieber erst ein kurzes Walkthrough siehst, hier das TechVid von Sophos:

Ein Praxisfall aus dem KMU-Alltag

Freitag, 15:30 Uhr. Eine Firma mit etwa 80 Mitarbeitenden: neue Internetleitung, neue öffentliche IPs, parallel steht ein kleines Projekt an (neues CRM, neue Subnetze). Im Change-Request ist sauber beschrieben, welche NAT-Regeln, welche VPN-Endpoints und welche Firewall-Regeln angepasst werden.

In der Praxis kommt dann aber das, was immer kommt:

Ein Objekt wie WAN_Public_IPs hängt in drei NAT-Regeln, zwei Business-Application-Rules und in einer “historischen” WAF-Regel, die niemand mehr auf dem Radar hatte.
Ein FQDN-Objekt (SaaS) wurde irgendwann mal in eine Gruppe gepackt und taucht in zehn Regeln auf, aber nur zwei davon sind noch relevant.
Du willst aufräumen, aber du willst auch nicht am Montag den Anruf bekommen: “Seit dem Change geht unser X nicht mehr.”

Das ist der Punkt, an dem der Configuration Viewer richtig Zeit spart.

Mein typischer Ablauf in solchen Situationen:

Vorher exportieren (Baseline sichern)
Änderung umsetzen
Nachher exportieren
Im Viewer einen Diff ziehen und als HTML ins Ticket legen
Vor dem Löschen von Objekten: Usage Reference nutzen, um zu sehen, wo es wirklich noch hängt

Das ist nicht nur bequem, sondern es macht Änderungen nachvollziehbar. Und genau das wollen Audits, interne Freigaben und auch dein zukünftiges Ich.

So nutzt du das Tool praktisch

1) Konfiguration exportieren (Full oder Selective)

Du exportierst die Konfiguration direkt auf der Firewall:

WebAdmin: Backup & Firmware > Import / Export
Export: entweder Export full configuration (alles) oder Export selective configuration (gezielt, optional mit “Include dependent entity”)

Sophos gibt die Konfiguration als .tar aus, die du herunterlädst.

Ein paar Details, die in der Praxis den Unterschied machen:

Full export ist mein Standard für Change-Management (Baseline/Diff). Du bekommst wirklich alles und läufst weniger Gefahr, dass dir später eine Abhängigkeit fehlt.
Selective export nutze ich, wenn ich gezielt einen Bereich reviewen will (z. B. nur Interfaces + Routing) oder wenn ich etwas an Dritte geben muss (z. B. an einen ISP oder Vendor) und dabei bewusst minimieren will, was ich teile.
Include dependent entity ist bei selective exports oft entscheidend: Wenn du nur die Firewall-Regeln exportierst, willst du in der Regel auch die dazugehörigen Network/Service-Objekte dabei haben. Sonst wird der Export schnell unvollständig und du verlierst Kontext.

Pro Tipp für Vergleiche: Exportiere für “Compare” immer zwei Konfigurationen mit derselben Auswahl (Full vs Full oder Selective vs Selective mit identischen Häkchen). Wenn du Full gegen Selective vergleichst, sieht das Diff zwar spektakulär aus, ist aber für die Praxis meist wertlos.

2) TAR entpacken und `Entities.xml` finden

Aus der .tar musst du die Entities.xml extrahieren (je nach Export kann sie auch als entities.xml auftauchen).

Unter macOS/Linux:

tar -xvf backup.tar
ls -la

Unter Windows geht das z. B. mit 7-Zip.

Wenn du (so wie ich) vermeiden willst, dass solche Backups irgendwo im Downloads-Ordner versauern, kannst du dir dafür auch einen temporären Arbeitsordner anlegen. Beispiel unter macOS/Linux:

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

Am Ende kannst du den Ordner wieder löschen. Klingt banal, ist aber im Alltag genau die Art Hygiene, die verhindert, dass sensible Konfigs wochenlang herumliegen.

Wichtig für dein Security-Feeling: Laut Sophos-Doku enthält ein Export ohne sensitive Inhalte (z. B. nur Interfaces) oft nur Entities.xml. Sobald aber sensitive Informationen enthalten sind (z. B. Users), liegt im TAR zusätzlich u. a. hashFile.json und propertyfile.

Heisst in der Praxis: Behandle das komplette TAR so, als wäre es vertraulich.

3) Eine Konfiguration “lesbar” machen

Im Viewer wählst du “Single configuration” (oder ähnlich) und lädst die Entities.xml hoch. Danach bekommst du eine aufbereitete Ansicht.

Je nach Größe der Konfiguration dauert das Laden ein paar Sekunden. Danach hast du auf einen Blick etwas, was mir in der Web-UI oft fehlt: eine Art “Dokumentationssicht” über die Konfig, ohne dass du dich durch zig Menüs klicken musst.

Was ich daran mag: Du kannst links gezielt filtern. Wenn du gerade im Change an Routing/NAT bist, willst du nicht gleichzeitig durch jeden Report, jedes Log-Setting und jede Nebenfunktion scrollen. Du schaltest dir also gezielt die Bereiche an, die dich jetzt interessieren.

Typische Filter-Kombinationen in der Praxis:

nur Firewall-Regeln + NAT
nur Interfaces + Routing
nur VPN

Wenn ich eine Umgebung zum ersten Mal auditiere oder übernehme, arbeite ich mich meist in dieser Reihenfolge durch:

Interfaces/Zonen (wo ist innen, wo ist außen?)
Routing/SD-WAN (wie geht Traffic raus, wo kommen Rückrouten her?)
NAT (was wird veröffentlicht, was wird umgeschrieben?)
Firewall-Regeln (welche Flows sind wirklich erlaubt?)
VPN (Site-to-Site und Remote Access, je nach Setup)

Das ist nicht die einzige richtige Reihenfolge, aber sie verhindert, dass man Regeln bewertet, ohne die zugrunde liegende Topologie verstanden zu haben.

Und wenn du etwas für Doku oder Freigabe brauchst: Du kannst dir jederzeit einen HTML-Export ziehen.

Ich nutze das gern als “Review-Paket”: HTML exportieren, im Change-Ticket ablegen (oder intern in einem sicheren Doku-Ordner), und jemand anderes kann die Konfiguration lesen, ohne Zugriff auf die Firewall zu brauchen. Das ist gerade bei Vier-Augen-Prinzip, internen Freigaben oder externen Audits praktisch.

4) Usage Reference: “Wo wird dieses Objekt wirklich benutzt?”

Das ist für mich die Killer-Funktion.

Sophos-Konfigurationen leben von Objekten: Hosts, Netzwerke, Services, FQDNs, Gruppen. Das ist grundsätzlich super, weil du Dinge sauber wiederverwenden kannst. Der Haken: Nach ein paar Jahren Betrieb ist es oft nicht mehr offensichtlich, wo ein Objekt überall drin hängt.

Und genau da passieren die klassischen Fehler:

jemand löscht ein Objekt “weil es alt aussieht” und merkt erst später, dass es noch in einer NAT-Regel genutzt wurde
jemand ändert ein Objekt (z. B. IP-Bereich erweitert) und verändert damit unbemerkt mehrere Policies gleichzeitig

Die Usage-Reference im Viewer macht diese Abhängigkeiten sichtbar. Anstatt Objekte “auf Verdacht” in der UI zu suchen, nutzt du die Suche/Usage-Reference, um herauszufinden, wo ein Objekt oder ein Hostname referenziert wird.

Beispiel aus dem TechVid: Suche nach box und du siehst sofort, in welchen Policies/NAT-Regeln das FQDN-Objekt hängt.

Das Schöne daran ist die Click-Through-Logik: Du gehst von der Suche direkt auf das Objekt und siehst dann die Referenzen (z. B. welche Firewall-Policy oder welche NAT-Regel es verwendet). Wenn ich einen Cleanup-Change mache, exportiere ich mir diese Ansicht oft als HTML und lege sie zum Ticket. Dann ist später nachvollziehbar, warum ich ein Objekt gelöscht oder geändert habe.

Das ist perfekt für:

Cleanup (alte Objekte entfernen)
Change Planning (welche Regeln müssen wirklich angepasst werden)
Troubleshooting (warum greift eine Regel noch irgendwo)

5) Zwei Konfigurationen vergleichen (Vorher/Nachher)

Auf der Startseite des Tools kannst du statt “View” auch “Compare” wählen und zwei Entities.xml Dateien hochladen.

Das klingt simpel, ist aber ein extrem mächtiges Muster. Ich nutze es zum Beispiel für:

Vorher/Nachher bei Changes (mein Klassiker)
Vergleich von Test-/Staging-Firewall gegen Produktion, um “Drift” zu finden
Validierung nach Migrationen (z. B. neue WAN-Leitung, neue NAT-Logik, neues VPN)

Was ich an diesem Compare-Modus mag: Er ist nicht einfach ein Text-Diff, sondern versucht, Änderungen sinnvoll zu gruppieren. Du bekommst also nicht nur “da ist irgendwo XML anders”, sondern: Dieses Objekt wurde hinzugefügt, jene Regel wurde geändert, dieser Eintrag wurde entfernt.

Das Ergebnis ist genau das, was man für Change-Management braucht:

Summary: Was wurde entfernt, geändert, hinzugefügt?
Details pro Objekt/Regel
optional Roh-XML nebeneinander
HTML-Export für Ticket/Audit

Mein persönlicher Workflow ist hier ziemlich stumpf (aber effektiv):

Summary lesen: Stimmen die Mengenordnungen? (z. B. “ich habe 3 Regeln geändert” vs “irgendwie 200 Objekte modified”)
In die kritischen Bereiche drillen: Interfaces/WAN, Routing, NAT, VPN, Firewall-Regeln
HTML-Export speichern, solange alles frisch ist

Gerade Punkt 1 ist für mich der Stress-Reduzierer. Wenn ich nach einem Change sehe, dass nur die erwarteten Objekte betroffen sind, schlafe ich am Wochenende deutlich besser.

Wenn du dir angewöhnt, bei größeren Changes immer einen Vorher/Nachher-Diff zu sichern, machst du dir das Leben langfristig deutlich einfacher.

Funktionen und Features im Detail

Bis hierhin ist das Tool schon nutzbar. Aber wenn man es ein paar Mal eingesetzt hat, merkt man: Der Viewer ist weniger “nice to have” und mehr eine kleine Werkzeugkiste für typische Admin-Fragen. Hier sind die Funktionen, die ich im Alltag wirklich oft brauche, etwas ausführlicher.

Human-Readable View: endlich ohne UI-Klick-Marathon

In der Sophos-Web-UI sind Einstellungen oft logisch gruppiert, aber über viele Seiten verteilt. Für “mal eben” ist das okay. Für Audits oder Change-Planung ist es anstrengend, weil du dauernd den Kontext verlierst.

Der Viewer macht daraus eine kompakte Darstellung. Ich nutze das gern, um einen schnellen Reality-Check zu machen:

Welche Interfaces/Zonen gibt es wirklich?
Welche NAT-Regeln veröffentlichen welche Dienste?
Welche Regeln sind breit gefasst, weil sie in der Vergangenheit “funktionieren musste”?

Das ersetzt kein sauberes Design, aber es macht dir sichtbar, wie die Firewall am Ende wirklich beschrieben ist.

Filter: Fokus auf das, was gerade zählt

Die Filter links wirken erstmal banal, sind aber in der Praxis Gold wert. Bei den meisten Changes geht es nicht um die komplette Konfiguration, sondern um einen Bereich (WAN, NAT, VPN, Routing).

Wenn ich z. B. eine neue Internetleitung anbinde, blende ich alles aus und nehme nur:

Interfaces/WAN
Routing/SD-WAN
NAT
Firewall-Regeln (für die betroffenen Flows)

Das klingt simpel, aber es verhindert, dass man beim Review in “Nebenkriegsschauplätzen” hängen bleibt.

Suche: von “box” bis “10.20.30.0/24”

Die Suchfunktion ist ein guter Einstieg, wenn du aus dem Betrieb kommst und nur ein Signal hast:

“Unser Dienst zu box.com geht nicht mehr”
“Die neue Filiale 10.20.30.0/24 hat keinen Zugriff”
“Warum ist SMTP überhaupt noch offen?”

Du suchst nach dem Namen, der IP, dem FQDN oder dem Objekt, und landest schnell bei der Stelle, die du dann im Detail prüfen kannst.

Usage Reference: Impact sichtbar machen (bevor etwas weh tut)

Die Usage-Reference ist die Funktion, die bei mir am häufigsten darüber entscheidet, ob ein Cleanup “mutig” oder “verantwortbar” ist. Ich nutze sie vor allem für drei Fälle:

Objekte löschen: Erst checken, ob es wirklich nirgends referenziert wird.
Objekte ändern: Erst checken, wie viele Regeln/Policies indirekt betroffen wären.
Change planen: Erst checken, welche Regeln tatsächlich am gleichen Objekt hängen.

Wenn du das konsequent machst, sinkt die Zahl der “Ups, das hing ja auch noch da dran”-Momente massiv.

Compare + HTML-Export: mein Default für Change-Management

Der Compare-Modus ist für mich der “Beweis”, dass ein Change so gelaufen ist, wie er geplant war.

Ich mache es meist so:

Vorher exportieren
Nachher exportieren
Compare
HTML-Diff speichern und im Ticket ablegen

Das wirkt pedantisch, aber es kostet wenige Minuten und spart dir im Zweifel Stunden Diskussion, wenn später jemand fragt, was genau geändert wurde. Für Teams ist das außerdem ein super Review-Format: Du kannst jemanden bitten, den HTML-Diff zu lesen und nur die kritischen Punkte gegenzuchecken.

Sicherheit: Was ist gut, wo sind die Grenzen?

1) Privacy-first ist super, aber keine Ausrede für Sorglosigkeit

Dass laut Sophos nichts aus dem Browser heraus geteilt wird, ist ein großer Pluspunkt, gerade für Konfig-Daten.

Trotzdem gilt: Eine Firewall-Konfiguration ist fast immer sensibel. Selbst wenn keine Passwörter im Klartext drin wären, stehen dort in der Regel Dinge wie:

interne Netze, VLANs, IP-Schemas
NAT-Definitionen und öffentliche Endpunkte
VPN-Topologien
Objektgruppen (die oft mehr verraten als man denkt)

2) Der Export ist das eigentliche Risiko

Der Viewer hilft dir beim Lesen. Aber das Risiko entsteht meist vorher und nachher:

beim Download des TAR
beim Entpacken
beim Speichern/Teilen von HTML-Reports

Sophos dokumentiert explizit, dass Exporte mit sensitiven Informationen zusätzliche Dateien enthalten können und dass die Secure Storage Master Key Thematik bei Imports relevant wird.

Mein Rat für den Alltag:

Export-Dateien nur kurzlebig lokal halten (und danach sauber wegräumen)
Reports nicht in “offene” Tickets kippen
Wenn du mit Dritten arbeitest: lieber selective exports nutzen und nur das Notwendige teilen

3) SSH/Advanced Shell: Der Viewer sieht nur, was im Export landet

Ein Punkt, der in echten Umgebungen häufiger vorkommt als man zugibt: In einer Störung loggt sich jemand per SSH ein und “fixt schnell etwas” in der Advanced Shell.

Der wichtige Part hier ist weniger die Frage, ob so ein Fix den nächsten Reboot überlebt oder nicht, sondern: Wenn etwas nicht im Export (Entities.xml) landet, ist es im Viewer unsichtbar. Und genau das kann bei Advanced-Shell-/SSH-Anpassungen passieren, weil sie nicht immer als “normale” Konfiguration im Export auftauchen.

Wenn du also per SSH/Advanced Shell an der Firewall schraubst: dokumentiere es separat und plane, es sauber über die WebAdmin-Konfiguration abzubilden. Sonst ist der nächste Restore, HA-Failover oder Firmware-Update der Moment, in dem es dir wieder auf die Füße fällt, oder du übersiehst es schlicht im Diff.

4) Praktische Regeln, die im Betrieb helfen

Nutze für solche Aufgaben ein Browser-Profil ohne wilde Extensions.
Speichere TAR/HTML nur dort, wo du auch sonst vertrauliche Konfigs ablegst.
Wenn du etwas freigeben musst: exportiere minimal (selective) und denk an Abhängigkeiten.

Fazit

Der Sophos Firewall Configuration Viewer ist kein Feature, das Schlagzeilen macht. Aber ganz ehrlich: Genau solche Tools sind es, die dir im Alltag wirklich den Rücken freihalten.

Ich habe in den letzten Jahren genug Konfigurationen gesehen, bei denen der eigentliche Stress nicht “Technik” war, sondern Nachvollziehbarkeit: Was wurde wann geändert? Hängt dieses Objekt wirklich nirgendwo mehr? Haben wir mit dem Change aus Versehen noch etwas anderes angefasst? In der Web-UI lässt sich vieles finden, aber es ist selten schnell. Und XML-Exporte direkt zu lesen macht niemand freiwillig länger als fünf Minuten.

Der Viewer schließt diese Lücke ziemlich gut. Ich kann eine Konfiguration in Ruhe lesen, wie eine Doku behandeln, gezielt filtern, Referenzen prüfen und am Ende einen Diff als HTML ablegen. Das klingt nach “nice”, ist aber in Teams ein echter Hebel: Reviews werden leichter, Audits werden entspannter, und du hast weniger Überraschungen am Montagmorgen.

Wenn du nur eine Sache mitnimmst: Baue dir einen kleinen Reflex an.

Vor größeren Changes immer einmal exportieren, nach dem Change wieder exportieren, Compare laufen lassen, HTML-Diff ablegen. Das kostet ein paar Minuten, aber es ist eines der zuverlässigsten Mittel gegen “Gefühlt haben wir nur X geändert”.

Und wie immer gilt: Der Viewer macht Konfigs lesbarer, aber nicht automatisch sicher. Das Denken musst du weiter selbst übernehmen. Er sorgt nur dafür, dass du dafür endlich ein Werkzeug hast, das nicht gegen dich arbeitet.

Wenn du in der Vergangenheit Konfigs per SSH in der Advanced Shell “quick & dirty” angepasst hast: Behalte im Hinterkopf, dass das nicht zwingend im Backup auftaucht und damit auch nicht im Viewer sichtbar wird.

Quellen und weiterführende Links

Bis zum nächsten Mal, Euer Joe