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 SSMK eingeben, falls sensible Informationen betroffen sind.
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

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.

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. Das Ziel benötigt mindestens gleich viele Ethernet-Ports. Weichen Portnamen oder Plattformfunktionen ab, muss die Zuordnung vorab geklärt werden. Für solche Migrationen ist der Backup-Restore Assistant oft geeigneter als ein manueller XML-Umbau.

Wireless-Modelle besitzen zusätzliche Grenzen für LocalWiFi, Frequenzbänder, SSIDs, ältere Security Modes, TKIP und Bridge-Zuordnungen. Ein erfolgreicher Teilimport bedeutet nicht, dass jede Wireless-Konfiguration übernommen wurde. Die Zielkonfiguration wird deshalb objektweise geprüft.

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 Passwörter, Secrets, Schlüssel oder davon abhängige Konfigurationen enthält.

• Auf einer anderen Firewall oder nach Factory Reset beziehungsweise Reimage muss der zum Export gehörende SSMK eingegeben werden.
• Ohne passenden SSMK kann SFOS den restlichen Import durchführen, sensible Informationen und abhängige Konfigurationen gehen jedoch verloren.
• 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 <exportdatei>.tar

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 <importdatei>.tar Entities.xml hashFile.json propertyfile

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 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; 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