Sophos Fusion Firewall Groups und Full Sync sicher verwenden

Eine Firewall Group in Sophos Fusion (ehemals Sophos Central) ist eine gemeinsame Konfigurationsvorlage für mehrere Firewalls. Das spart Arbeit, verändert aber auch die Verantwortung: Sobald eine Firewall der Gruppe vollständig folgt, werden unterstützte Regeln, Objekte und Einstellungen zentral verwaltet.

Der kritische Entscheid fällt beim Hinzufügen der Firewall. Mit Full Sync verteilt Central die gesamte bereits vorhandene unterstützte Gruppenkonfiguration. Mit Skip full sync verteilt Central diesen vorhandenen Gruppenbestand beim Zuweisen nicht; danach angewendete Gruppenänderungen erreichen die Firewall trotzdem. Skip full sync ist deshalb keine dauerhafte Trennung von der Gruppe.

⚠️ Vor dem ersten Full Sync ein aktuelles Firewall-Backup erstellen, eine lokale Admin-Sitzung offenhalten und den Rückweg testen. Ein erfolgreicher Central-Task beweist noch nicht, dass Routing, NAT, Authentifizierung und produktiver Traffic korrekt funktionieren.

Voraussetzungen

Zum Erstellen einer Gruppe und zum Öffnen ihrer Policy benötigt man in Sophos Fusion die Rolle Admin oder Super Admin. Die Firewalls müssen bereits für Central Management registriert und freigegeben sein. Dafür verlangt Sophos eine aktive kostenpflichtige Firewall-Subscription ausser der Base License oder einen aktiven Supportvertrag; die Internetverbindung zu Central muss über IPv4 erfolgen. Den Registrierungs- und Freigabeablauf beschreibt Sophos Firewall mit Sophos Fusion verbinden.

Schnellweg für eine sichere Einführung

Eine repräsentative Pilotfirewall auswählen und ihre lokale Konfiguration, Regelreihenfolge und Abhängigkeiten inventarisieren.
Unter My Products > Firewall Management > Firewalls > Create New Group eine leere Gruppe erstellen.
Use Sophos default oder Import existing configuration bewusst wählen und die erzeugte Gruppenpolicy vor der Zuweisung prüfen.
Im Gruppenmenü Edit Group öffnen, die Pilotfirewall von Available Firewalls nach Assigned Firewalls verschieben und Skip full sync nur wählen, wenn ihr aktueller Bestand zunächst erhalten bleiben muss.
Eine kleine, eindeutig erkennbare Gruppenänderung ausrollen und die Task Queue prüfen.
Die Änderung lokal auf der Firewall und mit echtem Testtraffic abnehmen.
Erst danach weitere Firewalls, Untergruppen oder einen vollständigen Sync planen.

Was eine Firewall Group verwaltet

Die Gruppenpolicy wird über Manage Policy geöffnet. Sie ähnelt dem lokalen WebAdmin, gilt aber für alle zugewiesenen Firewalls. Unterstützte Objekte und Einstellungen werden von Central verteilt; rein lokale oder interfacebezogene Konfigurationen sind nicht automatisch Bestandteil der Vorlage.

Das ist besonders wichtig bei unterschiedlichen Standorten. Eine gemeinsame Regel kann nur funktionieren, wenn ihre Zonen, dynamischen Interfaces, Netze, Dienste und Abhängigkeiten auf jedem Zielsystem sinnvoll aufgelöst werden. Für individuelle Standortwerte eignen sich bewusst geplante Untergruppen oder Dynamic Objects besser als nachträgliche lokale Korrekturen.

Dynamic Zones und Dynamic Interfaces

Ein Dynamic Object übersetzt eine logische Zone oder ein logisches Interface der Gruppenpolicy in das passende lokale Objekt jeder Firewall. Man legt es unter My Products > Firewall Management > Dynamic Objects auf dem Tab Zones oder Interfaces an und hinterlegt die Zuordnung pro Firewall. Bei Dynamic Interfaces müssen IP Address Family und Interface Type zu den lokalen Interfaces passen.

Die Zuordnung Default (Any firewall) gilt auch für später hinzugefügte Firewalls. Sie ist daher nur sicher, wenn die gewählte Zone beziehungsweise das Interface auf jedem nicht einzeln zugeordneten Gerät existiert. Vor dem Rollout alle Mappings prüfen; über Usage References zeigt Central, welche Gruppe und welcher Policy-Teil das Dynamic Object verwendet.

Objekte, Einstellungen und Untergruppen

Objekte wie Firewall-Regeln, NAT-Regeln, FQDN Hosts und IP Hosts können in einer Gruppenpolicy erstellt und gelöscht werden. Untergruppen erben Objekte des übergeordneten Parents schreibgeschützt, können sie aber als Grundlage für eigene Regeln verwenden. Wird ein Parent-Objekt in einer Untergruppe verwendet, verhindert Central seine Löschung und zeigt die Abhängigkeit an.

Einstellungen mit einer Apply-Schaltfläche werden nur im obersten Parent konfiguriert und an alle Untergruppen vererbt. Eine Untergruppe kann diese Settings nicht separat überschreiben. Vor dem Aufbau einer Hierarchie sollte deshalb klar sein, welche Werte wirklich für alle Standorte gleich sein müssen.

Gruppe erstellen und Ausgangskonfiguration wählen

Unter My Products > Firewall Management > Firewalls > Create New Group stehen zwei Ausgangspunkte zur Verfügung:

Use Sophos default: erstellt eine neue Gruppenpolicy aus den Sophos-Standardwerten. Das ist für ein neues, bewusst zentral aufgebautes Design gut nachvollziehbar.
Import existing configuration: übernimmt die von Central unterstützte Konfiguration einer bestehenden Firewall als Vorlage. Interface- und andere lokale Konfigurationen werden nicht vollständig importiert.

Beim Import kann die Gruppenerstellung scheitern, wenn Firewall-Regeln nicht unterstützte Benutzertypen referenzieren. Sophos nennt AD-, Sophos-Live-, L2TP- und PPTP-Benutzer. Vor dem Import werden deshalb die betroffenen Regeln, Benutzerobjekte und die Task Queue geprüft; ein fehlgeschlagener Import wird nicht durch spontanes Löschen produktiver Regeln erzwungen.

Eine leere Gruppe ist oft der sicherste Start. Die Policy kann zuerst geprüft und vorbereitet werden, bevor eine Firewall zugewiesen wird.

Full Sync und Skip full sync richtig wählen

Full Sync

Full Sync verteilt die gesamte bereits vorhandene unterstützte Gruppenkonfiguration auf die Firewall. Dieser Weg passt, wenn die Gruppenpolicy der vorgesehene Sollzustand ist und ihre Wirkung auf den lokalen Bestand geprüft wurde.

Vor der Ausführung werden mindestens Firewall- und NAT-Regeln, Hosts, Services, Authentifizierungsabhängigkeiten, Zertifikate, VPNs, Web- und TLS-Policies sowie lokale Service-ACLs verglichen. Ein aktuelles Backup, Managementzugang und ein Wartungsfenster gehören zur Änderung.

Skip full sync

Mit Skip full sync verteilt Central die bereits vorhandenen Gruppenkonfigurationen beim Zuweisen nicht auf die Firewall. Sie kann deshalb von den anderen Gruppenmitgliedern abweichen. Danach angewendete Gruppenänderungen werden jedoch an alle Firewalls der Gruppe verteilt.

Central kennzeichnet die Firewall danach als Connected, obwohl zwischen Firewall und Gruppenpolicy ein Konfigurationsunterschied bestehen kann. Der Status allein ist deshalb kein Nachweis für identische Konfigurationen.

Der Modus passt für eine kontrollierte Übernahme zukünftiger Central-Änderungen, schafft aber kein unabhängiges lokales Ownership-Modell. Vor jeder Gruppenänderung muss deshalb klar sein, welche lokale Konfiguration sie beeinflusst und wie die Wirkung geprüft wird.

Ein späterer Force sync verteilt alle Gruppenkonfigurationen. Dazu klickt man unter Sync & Management auf den Status Connected und dann auf Force sync. Bei einem HA-Paar ist der Link nur für die aktive Firewall verfügbar. Die Aktion wird erst ausgelöst, wenn der Unterschied zwischen lokalem Bestand und Gruppenpolicy dokumentiert und technisch abgenommen ist.

Gruppenpolicy ändern und verteilen

In My Products > Firewall Management > Firewalls beim Gruppenmenü Manage Policy öffnen.
Nur die geplante Regel, das Objekt oder Setting ändern.
Zurück in Central unter My Products > Firewall Management > Tasks Queue den Auftrag aufklappen.
Status, betroffene Firewalls, Entity, Zeitpunkt und Fehlermeldung dokumentieren.
Erst nach Successful oder sauber geklärtem Teilstatus lokal prüfen.

Bei Firewall- und NAT-Regeln gelten Top und Bottom nur innerhalb der Central-Policy. Central-Regeln werden auf der Firewall oberhalb lokaler Regeln eingefügt. Eine gemischte Pflege kann dadurch andere Matches erzeugen als erwartet. Für zentral verwaltete Firewalls sollten zusammenhängende Regeln deshalb konsequent über Central gepflegt und anhand der tatsächlichen Firewall Rule ID beziehungsweise NAT Rule ID geprüft werden.

Wirkung lokal abnehmen

Ein erfolgreicher Task zeigt, dass Central den Auftrag verarbeitet hat. Die fachliche Abnahme erfolgt auf jeder betroffenen Firewall:

Ist das erwartete Objekt oder Setting sichtbar und vollständig?
Stimmt die effektive Regelreihenfolge?
Trifft ein definierter Testflow die erwartete Firewall- und NAT-Regel?
Funktionieren Hin- und Rückweg, DNS, Authentifizierung und abhängige Dienste?
Bleibt ein absichtlich nicht erlaubter Test blockiert?
Zeigt der Audit Trail den erwarteten Administrator, Zeitpunkt und Change?

Bei mehreren Standorten werden Erfolg und Fehler pro Firewall dokumentiert. Ein teilweise erfolgreicher Rollout wird nicht als Gruppenerfolg zusammengefasst. Für Rules, Policy Test, Log Viewer und Packet Capture hilft Sophos Firewall-Regeln testen.

Fehler sicher eingrenzen

Firewall bleibt unsynchronisiert

Zuerst Gruppenmitgliedschaft, Central-Verbindung, Lizenz, Task-Status und die konkrete Fehlermeldung prüfen. Retry wird erst nach behobener Ursache verwendet. Skip räumt nur den Task aus der Verarbeitung; die ausgelassene Konfiguration bleibt fachlich offen.

Lokale Regel verhält sich nach einem Push anders

Dann effektive Regelreihenfolge, Rule ID, Objektauflösung und NAT prüfen. Central-Regeln stehen oberhalb lokaler Regeln. Die Lösung ist nicht, weitere breite Allow-Regeln einzufügen, sondern Ownership und Reihenfolge des betroffenen Regelblocks eindeutig zu machen.

Import einer bestehenden Firewall scheitert

Die Fehlermeldung und referenzierten Entities sichern. Danach nicht unterstützte Benutzerreferenzen, lokale Interfaces und andere nicht importierbare Abhängigkeiten prüfen. Bleibt die Ursache unklar, mit Task-Daten und Firewall-Backup an Sophos Support eskalieren, statt produktive Objekte versuchsweise zu löschen.

Rollback und Betrieb

Eine Firewall kann aus der Gruppe entfernt werden; bereits aus Central verteilte Policies bleiben dabei auf der Firewall erhalten. Das Entfernen ist deshalb kein automatischer Rollback. Die zuvor dokumentierten Objekte werden lokal kontrolliert, bevor eine Regel oder ein Objekt gelöscht oder ersetzt wird.

Für einen sauberen Betrieb braucht jede Gruppenänderung einen Owner, eine Task-Referenz, einen lokalen Test und eine Rückfallentscheidung. Umfangreiche Änderungen werden zuerst auf einer Pilotfirewall oder Untergruppe geprüft. Audit Trail Logs und ein aktuelles Backup bleiben auch bei Central-Verwaltung notwendig.

Checkliste

Pilotfirewall und Management-Rückweg sind getestet.
Backup und Ausgangskonfiguration sind gesichert.
Use Sophos default oder Import existing configuration wurde bewusst gewählt.
Full Sync oder Skip full sync passt zum vorgesehenen Ownership-Modell.
Gruppenobjekte, Settings, Untergruppen und Abhängigkeiten sind geprüft.
Task Queue zeigt den erwarteten Status je Firewall.
Regelreihenfolge, Rule IDs und realer Traffic sind lokal abgenommen.
Rollback berücksichtigt, dass Central-Policies beim Entfernen aus der Gruppe erhalten bleiben.

FAQ

Ist Skip full sync eine dauerhafte Ausnahme von Gruppenänderungen?

Nein. Beim Zuweisen bleibt die bestehende Konfiguration zunächst erhalten, spätere Änderungen der Gruppenpolicy werden aber an die Firewall verteilt.

Setzt das Entfernen einer Firewall aus der Gruppe die Central-Änderungen zurück?

Nein. Bereits verteilte Policies bleiben auf der Firewall. Ein Rollback muss die betroffenen Regeln, Objekte und Settings ausdrücklich prüfen und kontrolliert zurückführen.