Sophos Firewall Konfiguration selektiv exportieren und importieren

Unter Backup and firmware > Import export kann Sophos Firewall die vollständige oder eine selektive Konfiguration exportieren. Der Export lässt sich auf einem geschützten Admin-System prüfen, kontrolliert anpassen und als .tar-Datei wieder importieren. Das eignet sich für klar abgegrenzte Objektänderungen, Migrationen und dokumentierte Massenanpassungen.

Ein Import ist jedoch kein Restore. Er ersetzt nicht die gesamte aktuelle Konfiguration, sondern ergänzt neue Einstellungen und überschreibt gleichnamige beziehungsweise übereinstimmende Einstellungen aus dem Importpaket. Nicht enthaltene Einstellungen bleiben bestehen. Vor jedem produktiven Import braucht es deshalb ein vollständiges Firewall-Backup samt Passwort und SSMK, einen Management-Rückweg und einen Testplan.

⚠️ Wichtig: Entities.xml kann Passwörter, Secrets, Benutzer, Netzobjekte, Regeln und weitere sensible Daten enthalten. Dateien nur auf einem vertrauenswürdigen Admin-System verarbeiten, nicht über unkontrollierte Cloudspeicher oder Messenger verteilen und nach dem Change geschützt archivieren oder löschen.

Selektiven Import in zehn Schritten durchführen

1. Ziel, betroffene Objekttypen und erwartete Änderungen schriftlich festhalten.
2. Vollständiges Restore-Backup erstellen und Backup-Passwort sowie Secure Storage Master Key prüfen.
3. Ziel-Firmware, Pattern-Version, Plattform, Portanzahl und Modellkompatibilität erfassen.
4. Unter Backup and firmware > Import export auf Export selective configuration wechseln.
5. Nur die benötigten Konfigurationstypen auswählen und Abhängigkeiten bewusst einbeziehen.
6. Exportierte .tar-Datei geschützt speichern und unverändert als Referenz behalten.
7. Paket entpacken, Entities.xml prüfen und nur die geplanten Felder ändern.
8. Entities.xml sowie vorhandene Begleitdateien wieder unverändert benannt als .tar verpacken.
9. Paket im Wartungsfenster importieren und den passenden SSMK eingeben, wenn SFOS danach fragt.
10. Objekte, abhängige Policies, erwartete Firewall Rule ID, Logs und echten Traffic prüfen.

Wenn der Import einen unerwarteten Umfang zeigt, eine Abhängigkeit fehlt oder die Zielplattform nicht eindeutig kompatibel ist, wird nicht produktiv importiert. Das unveränderte Exportpaket dient als Vergleich, das vollständige Backup als Rückweg.

Import/Export und Backup nicht verwechseln

Ein vollständiges Backup bildet die Firewall als Recovery-Paket ab. Beim Restore ersetzt es die aktuelle Konfiguration, aktiviert die im Backup enthaltene Managementadresse und startet die Firewall neu. Der Import/Export-Bereich arbeitet dagegen mit Konfigurationsobjekten:

• Neue Einstellungen aus dem Paket werden hinzugefügt.
• Vorhandene passende Einstellungen werden mit den importierten Werten aktualisiert.
• Einstellungen, die nicht im Paket stehen, bleiben unverändert.
• Ein selektiver Import entfernt daher nicht automatisch alte Objekte oder frühere Werte ausserhalb des importierten Objekts.
• Ein erfolgreicher Import beweist weder, dass alle Abhängigkeiten vorhanden sind, noch dass der Datenpfad funktioniert.

Für Hardwaretausch, Reimage, vollständige Wiederherstellung oder grossen Modellwechsel bleibt Backup und Restore der primäre Ablauf. Import/Export passt, wenn der Scope klar begrenzt, die Objektabhängigkeiten verstanden und die Wirkung einzeln abnehmbar ist.

Export vorbereiten

Scope und Abhängigkeiten festlegen

Für einen vollständigen Konfigurationsexport unter Backup and firmware > Import export die Option Export full configuration auswählen und danach Export wählen. Auch dieser Export ist kein Restore-Backup; die oben beschriebene Trennung zwischen Import/Export und Wiederherstellung bleibt bestehen.

Unter Export selective configuration werden die benötigten Konfigurationstypen ausgewählt. Include dependent entity nimmt abhängige Objekte mit auf. Diese Option ist hilfreich, ersetzt aber keine Inhaltskontrolle.

Als konkretes Beispiel für einen Benutzerexport: Im Suchfeld User eingeben, den Konfigurationstyp User markieren und Apply selected items wählen. Danach bei Bedarf Include dependent entity aktivieren und mit Export die .tar-Datei erzeugen. User bezeichnet hier einen Konfigurationstyp, nicht den Namen eines einzelnen Kontos; für einen anderen Scope wird nach dem passenden Typ gesucht.

Ein Beispiel ist eine Firewallregel, die auf Hosts, Services, Schedule, Web Policy oder NAT-Objekte verweist. Wird nur die Regel exportiert, können auf der Ziel-Firewall Abhängigkeiten fehlen oder auf anders benannte Objekte zeigen. Vor dem Export wird deshalb dokumentiert:

• welches Hauptobjekt geändert oder übertragen werden soll;
• welche Hosts, Netze, Services, Gruppen, Profile und Policies davon abhängen;
• welche gleichnamigen Objekte auf dem Ziel bereits existieren;
• welche produktiven Flows nach dem Import betroffen sein können;
• wie der Vorzustand wiederhergestellt wird.

Bei RED-Konfigurationen ist ein dokumentierter Sonderfall wichtig: REDDevice exportiert die benötigte DHCP-Serverkonfiguration nicht automatisch, auch wenn Include dependent entity aktiviert ist. Dafür muss zusätzlich DHCPServer ausgewählt oder der DHCP-Server nach dem Import kontrolliert neu erstellt werden.

Version und Zielplattform prüfen

Sophos unterstützt den Import auf derselben oder einer neueren Firmwareversion. Auch die Pattern-Version der Ziel-Firewall muss gleich oder neuer sein. Ist sie älter, werden zuerst die Pattern aktualisiert und danach der Import erneut geplant.

Selektive Konfigurationen lassen sich nur von einem kleineren auf ein gleiches oder höheres kompatibles Modell übertragen. Ohne Anpassung benötigt das Ziel mindestens gleich viele Ethernet-Ports. Für ein Ziel mit weniger Ports oder abweichenden Portnamen dokumentiert Sophos jedoch eine Ausnahme: Vor dem Import kann Entities.xml an die Zielports angepasst werden. Portzuordnung und betroffene Referenzen müssen vorab eindeutig geklärt sein; diese Ausnahme erlaubt keinen beliebigen Modell-Downgrade und hebt die Firmware-, Pattern- und Modellkompatibilitätsprüfung nicht auf. Nach dem Import Interfaces, abhängige Policies und echten Traffic prüfen, bevor der Change abgenommen wird. Weichen Plattformfunktionen ab, muss auch deren Übertragbarkeit vorab geklärt werden. Für solche Migrationen ist der Backup-Restore Assistant oft geeigneter als ein manueller XML-Umbau.

Für XGS 88w, 108w, 118w und 128w gelten genaue Wireless-Grenzen. Nutzen LocalWiFi0 und LocalWiFi1 dasselbe Frequenzband, importiert SFOS nur die Einstellungen von LocalWiFi0. In den folgenden Fällen werden zwar alle anderen Einstellungen importiert, die Konfiguration von LocalWiFi0 schlägt jedoch fehl:

• Eine SSID mit einem Security Mode vor WPA2 ist LocalWiFi0 oder LocalWiFi1 zugewiesen.
• Die Verschlüsselung einer zugewiesenen SSID steht auf TKIP oder TKIP/AES.
• Ein Wireless-Interface ist Mitglied einer physischen Bridge.
• LocalWiFi0 und LocalWiFi1 verwenden zusammen mehr als acht eindeutige SSIDs.

Ein erfolgreicher Teilimport beweist deshalb nicht, dass die Wireless-Konfiguration vollständig übernommen wurde. Die Zielkonfiguration wird objektweise geprüft. Eine importierte URL-Liste darf zudem höchstens 128 Domains enthalten.

SSMK und sensible Informationen einordnen

Beim Export wird der Secure Storage Master Key nicht eingegeben. Für den späteren Import ist er jedoch entscheidend, wenn das Paket sensible Informationen wie Passwörter, Secrets oder Schlüssel enthält.

• Damit sensible Informationen auf einer anderen Firewall oder nach Factory Reset beziehungsweise Reimage erhalten bleiben, muss die exportierte Konfiguration einen Master Key besitzen und beim Import der passende SSMK eingegeben werden.
• Besitzt die exportierte Konfiguration keinen Master Key oder wird der passende SSMK bei der Abfrage nicht eingegeben, kann SFOS den restlichen Import durchführen; sensible Informationen und abhängige Konfigurationen gehen jedoch verloren.
• Auf derselben Firewall bleiben sensible Informationen auch ohne erneute SSMK-Eingabe importierbar, solange die Firmware seit dem Export weder zurückgesetzt noch neu installiert wurde.
• Enthält der Export keine sensiblen Informationen, ist kein SSMK nötig.
• Ein Import ohne Fehlertext ist daher kein Beweis, dass alle Secrets und Abhängigkeiten übernommen wurden.

Der SSMK wird nicht zusammen mit der Exportdatei gespeichert. Export, vollständiges Backup, Backup-Passwort und SSMK werden getrennt geschützt, aber im Recovery-Fall eindeutig derselben Firewall und demselben Zeitraum zugeordnet.

Exportpaket sicher prüfen und anpassen

Paketinhalt verstehen

Nach dem Export liegt eine .tar-Datei vor. Ein Paket ohne sensible Informationen kann nur Entities.xml enthalten. Bei sensiblen Konfigurationen enthält es zusätzlich:

• hashFile.json
• propertyfile

Das Paket wird in ein eigenes Arbeitsverzeichnis entpackt:

tar -xvf sfos-users-export.tar

sfos-users-export.tar ist ein Beispielname und wird durch den Namen des eigenen Exports ersetzt. Platzhalter in spitzen Klammern stehen absichtlich nicht im Befehl, weil eine Shell < und > als Umleitungszeichen interpretieren kann.

Entities.xml wird nicht umbenannt. Sind hashFile.json und propertyfile vorhanden, bleiben auch diese Dateien erhalten und werden wieder mit eingepackt. Ein Dateiexport ist kein geeignetes Format für unkontrollierte globale Suchen-und-Ersetzen-Aktionen.

Änderungen nachvollziehbar vorbereiten

Für Reports, Vergleiche und eine strukturierte Vorbereitung kann Sophos Firewall Config Studio die Entities.xml lokal im Browser auswerten. Auch dort gilt: Eine erzeugte Konfiguration wird vor der Übernahme fachlich geprüft. Besonders Interfaces, Zonen, NAT, VPN, Device Access, Authentication, Zertifikate und HA benötigen eine eigene Abnahme.

Vor einer manuellen Änderung wird die unveränderte Entities.xml kopiert. Danach nur die geplanten Werte ändern und den Diff gegen das Original lesen. Elementnamen, IDs, Referenzen und Dateinamen werden nicht auf Verdacht umgebaut. Ist die Bedeutung eines Feldes unklar, endet der Ablauf vor dem Import.

Die Dateien werden wieder als TAR-Paket verpackt:

tar -cvf sfos-users-import.tar Entities.xml hashFile.json propertyfile

sfos-users-import.tar ist der anpassbare Name des neuen Pakets. Enthielt der ursprüngliche Export nur Entities.xml, wird nur diese Datei verpackt. Die Begleitdateien werden nicht erfunden, leer angelegt oder aus einem anderen Export übernommen.

Konfiguration importieren

1. Bestehende Full-Admin-Sitzung und alternativen Managementzugang offenhalten.
2. Wartungsfenster, Backup-Datei, Passwort, SSMK und Rollback-Entscheid bestätigen.
3. Backup and firmware > Import export öffnen.
4. Unter Import file ausschliesslich das vorbereitete .tar-Paket auswählen.
5. Import starten und den passenden SSMK eingeben, wenn SFOS danach fragt.
6. Erfolg, Warnungen und abgewiesene Objekte vollständig dokumentieren.
7. Vor weiteren Imports zuerst die Wirkung dieses Pakets prüfen.

Mehrere kleine, logisch getrennte Pakete sind für einen Change meist sicherer als ein grosser unspezifischer Import. Sie machen Fehlerumfang, Abhängigkeiten und Rückweg nachvollziehbarer. Das ist eine Betriebsentscheidung, keine Garantie, dass beliebige Objekte unabhängig voneinander importiert werden können.

Für wiederkehrende Automatisierung auf SFOS 22.0 MR2 oder neuer passt der getrennte Ablauf Konfiguration per Sophos Central API in Sophos Fusion (früher Sophos Central) exportieren und importieren. Der lokale WebAdmin-Import bleibt für gezielte manuelle Changes und die unabhängige Kontrolle relevant.

Import vollständig abnehmen

Die Abnahme beginnt beim Objekt und endet beim echten Datenpfad:

1. Importierte Objekte und ihre Werte im WebAdmin öffnen.
2. Abhängige Hosts, Services, Gruppen, Profile und Policies kontrollieren.
3. Bei Passwörtern, Secrets oder Schlüsseln die Funktion prüfen, nicht nur die sichtbare Objektzeile.
4. Betroffene Firewall-, NAT-, Web-, VPN- oder Authentication-Regel öffnen und Reihenfolge sowie Referenzen prüfen.
5. Einen kontrollierten positiven und negativen Test ausführen.
6. Im Log Viewer erwartete Firewall Rule ID, Action, Benutzer, Source, Destination und Service abgleichen.
7. Bei HA den Clusterzustand sowie die frische Funktion nach einem geplanten Rollenwechsel separat prüfen; keine Session-Fortsetzung voraussetzen.
8. Audit Trail, Zeitpunkt, Importdatei, Testergebnis und Rollback-Entscheid dokumentieren.

Für die mehrschichtige Policy-Abnahme hilft Firewall-Regeln systematisch testen. Bei Importfehlern sind apiparser.log, validation.log, validationError.log, applog.log und je nach Objekt der zugehörige Dienstlog relevant. Die Logzuordnung steht unter Sophos Firewall Services und Logs.

Typische Fehler sicher eingrenzen

Import meldet eine inkompatible Version

Aktive Firmware, Exportversion und Pattern-Stand beider Firewalls vergleichen. Nicht eine ältere Ziel-Firewall durch manuelle XML-Änderungen passend machen. Erst einen unterstützten Firmware- und Pattern-Stand herstellen oder den Migrationsweg neu planen.

Objekte fehlen trotz erfolgreichem Import

Prüfen, ob Include dependent entity verwendet wurde und welche Abhängigkeiten der Objekttyp tatsächlich besitzt. Bei RED zusätzlich DHCPServer kontrollieren. Fehlende Abhängigkeiten nicht mit breiten Ersatzobjekten oder Any kaschieren.

Benutzer, OTP oder Secrets fehlen

Extern authentifizierte Benutzer, die beim Sign-in automatisch lokal erschienen sind, werden nicht wie manuell angelegte Benutzer exportiert. Bei MFA exportiert OTPSettings die Einstellungen sowohl für manuell erstellte Benutzer als auch für Benutzer, die über einen externen Authentifizierungsserver automatisch zur Firewall hinzugefügt wurden; OTPTokens enthält nur ausgegebene Tokens für manuell erstellte lokale Benutzer. Zusätzlich SSMK und Importziel prüfen.

Fehlen sensible Informationen, wird nicht einfach ein neues Secret über das bestehende Objekt gelegt. Zuerst klären, ob der falsche SSMK, ein Export ohne SSMK-Schutz oder eine nicht exportierbare externe Identität die Ursache ist. Die Benutzer- und Gruppenwirkung danach mit einem frischen Sign-in testen. Der Lifecycle lokaler Konten steht unter Lokale Benutzer erstellen und verwalten.

TAR-Datei wird abgewiesen

Dateinamen und Paketinhalt prüfen. SFOS erwartet eine .tar-Datei; Entities.xml darf nicht umbenannt werden. Vorhandene hashFile.json und propertyfile müssen aus demselben Export stammen. Keine ZIP-Datei nur in .tar umbenennen.

Import war erfolgreich, Traffic funktioniert aber nicht

Objektreferenz, Zonen, Regelreihenfolge, NAT, Routing, Benutzer-/Gruppenkontext und erwartete Firewall Rule ID prüfen. Ein grüner Importstatus bestätigt nur den Konfigurationsvorgang, nicht die fachliche Wirkung.

Rollback und Checkliste

Ein selektiver Import besitzt keinen universellen Rückgängig-Schalter. Bei kleinen, vollständig dokumentierten Objektänderungen können die vorherigen Werte kontrolliert zurückgesetzt werden. Sind Umfang oder Abhängigkeiten unklar, wird der vorbereitete vollständige Restore-Pfad verwendet.

Vor Abschluss müssen folgende Punkte erfüllt sein:

• vollständiges Backup, Passwort und SSMK sind verfügbar;
• unverändertes Exportpaket und bearbeitete Version sind getrennt archiviert;
• Zielversion, Pattern und Modellkompatibilität sind bestätigt;
• nur benötigte Objekte und Abhängigkeiten wurden importiert;
• Warnungen und fehlgeschlagene Teilobjekte sind ausgewertet;
• Secrets und abhängige Funktionen wurden praktisch getestet;
• positiver und negativer Nutztraffic treffen die erwartete Regel;
• Logs und Audit Trail passen zum Change;
• bei HA ist der Zustand beider Nodes geprüft;
• Arbeitskopien liegen nicht ungeschützt auf dem Admin-System.

Häufige Fragen