Von Sophos Firewall Mail Protection zu Sophos Email migrieren

Die Migration verschiebt E-Mail-Prüfung und Richtlinien von Sophos Firewall Mail Protection zu Sophos Email in Sophos Fusion (ehemals Sophos Central). Sie ist kein direktes Kopieren der Firewall-Konfiguration: Zuerst werden Funktionen und Empfänger abgebildet, dann wird Sophos Email ohne produktive Routingänderung vorbereitet, anschliessend wird der Mailfluss kontrolliert umgeschaltet. Die alte Strecke bleibt bis zum Ende des vereinbarten Rollback-Fensters wiederherstellbar.

⚠️ Niemals gleichzeitig MX, ausgehenden Smart Host, DNAT und mehrere Policies ungeprüft ändern. Vor jeder Firewall- oder Routingänderung sind ein Sophos-Firewall-Backup, die Originalwerte und ein getesteter Managementzugang Pflicht.

1. Architektur und Abbruchkriterien festlegen

Für Microsoft 365 kann Sophos Mailflow oder Sophos Gateway gewählt werden; Mailflow arbeitet mit Microsoft-365-Connectors und -Regeln, Gateway mit SMTP-Routing und meist einer MX-Änderung. Andere Plattformen verwenden Gateway. Die Entscheidungshilfe steht unter Sophos Email: Architektur wählen und Onboarding planen. Für eine Domain darf nur ein produktiver Sophos-Prüfpfad bestehen.

Vor dem Start werden Change-Fenster, Owner für Sophos Fusion, Sophos Firewall, DNS und Mailserver, Pilotdomain oder Pilotpostfächer sowie Abbruchkriterien festgelegt. Beispiele sind nicht zustellbare externe Nachrichten, ein offenes Relay, Doppelverarbeitung oder eine Routing-Schleife. Eine gültige Sophos-Email-Lizenz muss bereits aktiv sein.

2. Bestand, Backup und Rückweg sichern

Pro Domain dokumentiert man:

• aktuellen Betriebsmodus: MTA Mode oder Legacy Mode/transparent proxy;
• geschützte Domains, Mailboxen, Aliase, Verteiler und SSP-Nutzung;
• eingehenden MX-Pfad, ausgehenden Smart Host, Relay-Quellen, NAT, SMTP-Ports und TLS-Anforderungen;
• SMTP-Policies, Policy-Reihenfolge, Ausnahmen, blockierte Absender, Quarantäne-Zusammenfassungen und DKIM;
• Spam-/Malware-Aktionen, Datei- und Data-Control-Regeln, Verschlüsselung/SPX und Banner;
• Firewall- und NAT-Rule-IDs, Objekte, Zonen, Logging sowie Mailserver-Ziel und Rückroute.

Man exportiert oder protokolliert die Werte, erstellt ein aktuelles Sophos-Firewall-Backup und hält die Wiederherstellungsreihenfolge schriftlich fest. DNS-TTL wird nur nach dem eigenen Change-Verfahren rechtzeitig reduziert. Alte Regeln werden nicht gelöscht.

3. Policies zuordnen und fehlende Entsprechungen freigeben

Für jede Quell-Policy wird eine Zeile mit Reihenfolge und Scope angelegt und das Ziel tatsächlich konfiguriert:

• MTA-Mode-Spam: Unter Email Security > Policies > [Email Security policy] > Settings > Anti-Spam gilt Firewall None → Deliver, Warn → Tag subject line, Quarantine → Quarantine und Drop → Delete. SPF, DKIM und DMARC werden unter Authentication mit der freigegebenen Aktion konfiguriert.
• Spam beim transparent proxy: Am selben Anti-Spam-Ziel gilt Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine und Drop → Delete. Für Reject und Change Recipient gibt es keine Sophos-Email-Entsprechung; der Ablauf muss neu entworfen oder das Risiko ausdrücklich akzeptiert werden. Deliver oder Delete dürfen nicht stillschweigend als Ersatz dienen.
• File/Data Control: Attachment-Regeln werden unter Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule mit der Vorlage Attachment file types (AFT) neu angelegt. Benutzerdefinierte Data Control Lists werden mit Content control lists (CCLs) und Grössen-/Header-/Quellprüfungen mit Message Attribute (MA) nachgebaut. Für jede Regel werden eingehende oder ausgehende Richtung, Aktion und Ausnahmen gewählt und getestet; eine Firewall-Liste wird nicht automatisch migriert.
• Encryption/SPX: Firewall SMTP TLS wird Email Security > Policies > Secure Message: Base Policy – Secure Message oder einer engeren Policy unter Add Rule > Secure Message zugeordnet. Für eine gescopte Regel sind interne und externe Auswahl erforderlich. Push Encryption entspricht funktional der PDF-Verschlüsselung von SPX, Portal Encryption verwendet Sophos Secure Message; da Empfänger Kennwörter festlegen, werden SPX-Einstellungen und -Kennwörter nicht kopiert. TLS zwischen Mailserver und Sophos Email wird geprüft.
• Exceptions: Eine Anti-Spam-Ausnahme für Absender/Empfänger wird einer eng gescopten Email Security Policy mit Anti-Spam = Deliver zugeordnet; eine globale Ausnahme kommt unter Email Security > Settings > Inbound Allow/Block > Add allow als E-Mail, Domain oder IP und umgeht Spam-Prüfungen global. SPF-/DKIM-Ausnahmen gehören in einer gescopten Policy unter Authentication, Intelix-Ausnahmen unter Anti-malware und Data-/File-Ausnahmen als Ausschluss der passenden Adressen oder Message Attributes in der konkreten Data-control-Regel. Breite Freigaben werden geprüft, nicht blind kopiert.
• Keine direkte Entsprechung: Benutzerdefinierte RBLs und Greylisting sind in Sophos Email nicht konfigurierbar; Sophos Email Advanced nutzt die automatisch aktivierte Sophos Delay Queue, nicht kundenseitiges Greylisting. BATV-Geheimnisse und Firewall-BATV-Verhalten haben in diesem Cloud-Dienst keine zu migrierende Einstellung. POP/IMAP scanning ist nicht verfügbar. Novell eDirectory/OpenLDAP haben keine identische Migration, SNMP wird durch verantwortete Sophos-Central-Benachrichtigungen/-Berichte ersetzt, und Firewall Hardware Monitoring bleibt eine separate Infrastrukturaufgabe.

Der Go-live erfolgt erst, wenn jede Zeile ein getestetes Ziel oder eine dokumentierte fehlende Entsprechung mit ausdrücklicher Risikoakzeptanz besitzt.

4. Sophos Email vollständig vorbereiten

Domains und sämtliche Empfänger werden angelegt oder synchronisiert; danach werden Aliase und Gruppen gegen die Soll-Liste geprüft. SSP, Administrator-Quarantäne und Rollen werden vorbereitet. Die Zielrichtlinien werden mit engen Scopes und in der vorgesehenen Reihenfolge angelegt, aber zunächst mit Pilotwirkung oder nicht erzwungen betrieben. Details zur Gateway-Strecke enthält Sophos Email Gateway einrichten; für Microsoft 365 steht Sophos Email Mailflow einrichten bereit.

Tenant- und regionsspezifische Hosts, IP-Adressen und DNS-Werte werden ausschliesslich aus Configure External Dependencies des eigenen Tenants übernommen. Beispielwerte aus Tickets werden nicht wiederverwendet.

5. Temporäre Firewall-Interoperabilität vorbereiten

Dieser Schritt ist nur nötig, wenn Sophos Email nach der Cloud-Prüfung weiterhin über die Sophos Firewall an einen lokalen oder Drittanbieter-Mailserver zustellen muss. Bei Microsoft 365 oder Google Workspace ohne erforderlichen Firewall-Hop wird er übersprungen.

Die deaktivierte DNAT-Regel wird eindeutig aufgebaut: Original source = aktuelle regionale Sophos Delivery IPs aus Configure External Dependencies; Original destination = WAN-Interface/-Adresse für die Zustellung; Original service = Zustellport, mit dem Sophos Email verbindet; Translated destination (DNAT) = realer interner Mailserver-Host/IP; Translated service (PAT) = SMTP-Port, auf dem der Server tatsächlich lauscht (häufig SMTP/25). PAT wird nur verwendet, wenn sich beide Services unterscheiden; dazu kommt das passende Inbound Interface. Der interne Server gehört nie in Original destination und das öffentliche/WAN-Objekt nie in Translated destination.

Die zugehörige Firewall-Regel wird deaktiviert und oberhalb allgemeiner Treffer angelegt: Source zones = WAN-seitige Zone(n), Source networks and devices = diese Sophos Delivery IPs, Destination zones = Post-NAT-Zone des Mailservers, Destination networks = Pre-NAT-WAN-Ziel aus Original destination der DNAT-Regel und Services = ursprünglicher am WAN angenommener Zustellservice/-port, nicht der übersetzte SMTP-/PAT-Service. Logging wird aktiviert. Diese Felder beschreiben absichtlich verschiedene Pre-/Post-NAT-Stufen und dürfen nicht der scheinbaren Konsistenz halber gleichgesetzt werden. Rückrouting wird geprüft; der Mailserver erlaubt Relay nur für die vorgesehene Sophos-Strecke.

Der neue Hop darf nicht erneut durch die alte MTA-/Proxy-Policy verarbeitet werden. Das Sophos-Email-Zustellziel darf weder auf den öffentlichen Sophos-MX noch über einen Smart Host zurück zu Sophos Email zeigen. Für ausgehende Mail wird genau ein Pfad Mailserver/Provider → Sophos Email → Internet festgelegt.

6. Gestuft umschalten

Vor dem Cutover werden Backup, Empfänger, Richtlinien, Zielerreichbarkeit, Regelreihenfolge und Rollback-Freigabe nochmals geprüft. Bei einem lokalen Ziel aktiviert man zuerst die vorbereiteten DNAT-/Firewall-Regeln und bestätigt den erwarteten Rule Hit. Bei Mailflow werden die vorbereiteten Microsoft-Regeln und Connectors konfliktfrei aktiviert. Bei Gateway wird der öffentliche MX erst jetzt auf die im Tenant angezeigten Sophos-Werte geändert.

Zuerst wird eingehend getestet. Erst wenn extern → Sophos Email → Ziel eindeutig funktioniert, wird der ausgehende Smart Host beziehungsweise Connector auf Sophos Email umgestellt. SPF, DKIM und DMARC werden für den endgültigen Sendepfad gemäss dem eigenen Tenant angepasst und alle drei in DNS und den Headern empfangener Nachrichten geprüft. Während der Abnahme bleiben parallele DNS-, Regel- und Policy-Changes eingefroren.

7. Mailfluss und Schutz abnehmen

Für jede Domain werden eindeutige Message-IDs und Zeitstempel erfasst:

1. externe Nachricht an eine persönliche Mailbox;
2. Nachricht an Alias oder Verteiler;
3. ausgehende Antwort und neue Nachricht an ein kontrolliertes externes Konto;
4. harmlose, autorisierte Tests für erwartete Spam-, Malware-/Datei- und Data-Control-Aktionen;
5. Kontrolle von TLS, Quarantäne, Bericht und SSP-Zugriff.

Jede Nachricht muss in Message History und zusätzlich im Microsoft Message Trace, Provider-Trace oder Mailserver-Log nachweisbar sein. Bei der Sophos Firewall werden DNAT- und Firewall-Rule-ID sowie Port und Ziel geprüft. Erfolg bedeutet endgültige Zustellung, genau eine Sophos-Verarbeitung und die erwartete Policy-Aktion – nicht nur eine erfolgreiche TCP-Verbindung.

Bei Fehlern prüft man in dieser Reihenfolge: MX/DNS-Verteilung, Domain- und Mailboxstatus, Connector oder Smart Host, DNAT und Zielzone, Regelreihenfolge und Rule ID, Port/TLS, Relay-Berechtigung, Policy-Scope und erst danach Filteraktionen. Fehlende Message-History-Einträge sind meist ein Routinghinweis, kein Grund für eine breite Ausnahme.

8. Rollback oder kontrollierter Rückbau

Beim Rollback wird zuerst der alte ausgehende Smart Host/Connector wiederhergestellt und anschliessend werden die vorherigen MX-Werte publiziert; die DNS-Änderung ist jedoch asynchron. Mindestens während der vorherigen MX-TTL plus der autoritativen DNS-Propagation bleiben beide eingehenden Annahmepfade funktionsfähig: Das alte Ziel nimmt Verkehr aus Caches mit altem MX an; zugleich bleiben Sophos Email, dessen Domain-/Routingkonfiguration und gegebenenfalls temporäre DNAT-/Firewall-/Relay-Strecke für Caches mit neuem MX aktiv. Kein Pfad darf in den anderen zurücksenden. Kontrollnachrichten laufen über beide Pfade; DNS-Beobachtung, Message History und Serverlogs zählen den Verkehr je Strecke.

Der neue Eingangspfad wird erst deaktiviert, wenn das Cache-Fenster abgelaufen ist und die Logs keine Zustellung mehr darüber zeigen; temporäre Firewall-Regeln werden nicht schon beim Rückpublizieren des alten MX abgeschaltet. Alte SMTP-Policies werden erst nach stabilem Betrieb über das vereinbarte Rollback-Fenster deaktiviert. Nach einer weiteren Abnahme können nicht mehr benötigte NAT-/Firewall-Regeln, Objekte und Relay-Freigaben entfernt werden. Backup, Policy-Mapping, DNS-Werte, Message-IDs und Abnahmeprotokoll bleiben erhalten. Kein Pfad wird entfernt, solange gecachte MX-Antworten, POP/IMAP oder eine nicht ersetzte Funktion davon abhängen.