Hoppa till innehållet
Avanet

Migrera från Sophos Firewall Mail Protection till Sophos Email

Migreringen flyttar e-postinspektion och policyer från Sophos Firewall Mail Protection till Sophos Email i Sophos Fusion (tidigare Sophos Central). Det är inte en direkt konfigurationskopiering: mappa först funktioner och mottagare, förbered sedan Sophos Email utan att ändra produktionsroutning och växla därefter kontrollerat. Den gamla vägen ska kunna återställas tills den överenskomna rollbackperioden är slut.

⚠️ Ändra aldrig MX, utgående smart host, DNAT och flera policyer samtidigt utan test. Ta före varje brandväggs- eller routningsändring en aktuell Sophos Firewall-backup, dokumentera originalvärdena och verifiera oberoende administrativ åtkomst.

1. Välj arkitektur och stoppkriterier

Microsoft 365 kan använda Sophos Mailflow eller Sophos Gateway. Mailflow använder Microsoft 365-connectors och regler; Gateway använder SMTP-routning och normalt en MX-ändring. Övriga plattformar använder Gateway. Se Planera Sophos Email-arkitektur och onboarding. En domän får bara ha en produktiv Sophos-inspektionsväg.

Fastställ ändringsfönster, ansvariga för Sophos Fusion, Sophos Firewall, DNS och e-postserver, pilot och stoppkriterier. Olevererbar extern e-post, öppet relay, dubbel bearbetning eller en routningsloop utlöser rollback. Sophos Email-licensen måste vara aktiv.

2. Bevara inventering, backup och returväg

Dokumentera per domän:

  • aktuellt MTA Mode eller Legacy Mode/transparent proxy;
  • domäner, brevlådor, alias, listor och SSP-användning;
  • inkommande MX, utgående smart host, relaykällor, NAT, SMTP-portar och TLS;
  • SMTP-policyer, ordning, undantag, blockerade avsändare, karantänsammanfattningar och DKIM;
  • spam-/malwareåtgärder, fil/Data Control, kryptering/SPX och banners;
  • NAT-/brandväggsregel-ID, objekt, zoner, loggning, servermål och returväg.

Exportera eller fånga värdena, skapa backupen och skriv exakt återställningsordning. Sänk TTL endast enligt ändringsrutinen. Radera inte gamla regler.

3. Mappa policyer och godkänn funktioner utan motsvarighet

Skapa en rad per källpolicy, behåll ordning och scope och konfigurera målet:

  • MTA Mode-spam: under Email Security > Policies > [Email Security policy] > Settings > Anti-Spam: None → Deliver, Warn → Tag subject line, Quarantine → Quarantine, Drop → Delete. Konfigurera SPF, DKIM och DMARC under Authentication.
  • Transparent proxy-spam: Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine, Drop → Delete. Reject och Change Recipient saknar motsvarighet; designa om eller acceptera risken uttryckligen, utan tyst ersättning med Deliver/Delete.
  • File/Data Control: återskapa bilagor under Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule med Attachment file types (AFT), listor med Content control lists (CCLs) och storlek/header/källa med Message Attribute (MA). Välj och testa inbound/outbound, åtgärd och undantag; brandväggslistor migreras inte automatiskt.
  • Encryption/SPX: mappa SMTP TLS till Email Security > Policies > Secure Message: Base Policy – Secure Message eller Add Rule > Secure Message. Interna och externa val krävs. Push Encryption motsvarar SPX PDF-kryptering; Portal Encryption använder Sophos Secure Message. Mottagaren bestämmer lösenord, så SPX-inställningar/lösenord kopieras inte. Validera TLS.
  • Exceptions: avsändare/mottagare → smal policy med Anti-Spam = Deliver; globalt → Email Security > Settings > Inbound Allow/Block > Add allow (e-post, domän eller IP), vilket kringgår spam globalt. SPF/DKIM under Authentication, Intelix under Anti-malware, Data/File som adress- eller Message Attributes-undantag i specifik Data control-regel. Granska breda allow.
  • Ingen motsvarighet: anpassade RBL och greylisting kan inte konfigureras; Sophos Email Advanced använder automatisk Sophos Delay Queue, inte kund-greylisting. BATV-hemligheter/-beteende har ingen inställning att migrera till molnet. POP/IMAP scanning saknas; Novell eDirectory/OpenLDAP migreras inte identiskt, SNMP kräver tilldelade Sophos Fusion-aviseringar/-rapporter och Hardware Monitoring förblir separat.

Gå inte live innan varje rad har ett testat mål eller dokumenterad avsaknad med riskacceptans.

4. Förbered Sophos Email fullständigt

Lägg till eller synkronisera domäner och alla mottagare; stäm av alias och grupper mot inventeringen. Förbered SSP, administratörskarantän och roller. Skapa målpolicyer med smalt scope och avsedd ordning, först för pilot eller utan enforcement. Följ Konfigurera Sophos Email Gateway eller för Microsoft 365 Konfigurera Sophos Email Mailflow.

Hämta regionala och tenantspecifika värdar, IP-adresser och DNS-värden enbart från Configure External Dependencies i den egna tenanten. Återanvänd inte exempel eller ärenden.

5. Förbered tillfällig brandväggssamverkan

Steget behövs bara när Sophos Email efter molninspektion ska leverera genom Sophos Firewall till en lokal eller extern e-postserver. Hoppa över det för Microsoft 365 eller Google Workspace utan nödvändigt brandväggshopp.

Skapa avstängd DNAT: Original source = regionala Sophos Delivery IPs från Configure External Dependencies; Original destination = mottagande WAN-gränssnitt/adress; Original service = leveransport som Sophos Email ansluter till; Translated destination (DNAT) = verklig intern server; Translated service (PAT) = faktisk SMTP-port (ofta SMTP/25). PAT endast när tjänsterna skiljer sig; ange inbound interface. Aldrig intern server i Original destination eller WAN-objekt i Translated destination.

Skapa avstängd brandväggsregel över breda träffar: Source zones = WAN, Source networks and devices = Sophos Delivery IPs, Destination zones = serverns post-NAT-zon, Destination networks = pre-NAT-WAN-målet från Original destination DNAT, Services = ursprunglig leveranstjänst/-port på WAN, inte översatt SMTP/PAT. Aktivera loggning. Fälten beskriver avsiktligt olika pre/post-NAT-steg. Kontrollera returväg och begränsa relay.

Det nya hoppet får inte bearbetas igen av gammal MTA/proxy. Sophos Email-målet får inte peka på publikt Sophos-MX eller via smart host gå tillbaka. Definiera en enda utgående väg: server/leverantör → Sophos Email → Internet.

6. Växla stegvis

Kontrollera åter backup, mottagare, policyer, nåbarhet, regelordning och rollbackgodkännande. För lokalt mål aktiveras DNAT/brandvägg först och förväntad Rule Hit bekräftas. För Mailflow aktiveras Microsoft-connectors och regler efter konfliktlösning. För Gateway ändras publikt MX först nu till tenantens värden.

Testa inkommande först och ändra sedan smart host/connector. Uppdatera SPF, DKIM och DMARC för slutlig sändväg och verifiera alla tre i DNS och mottagna headers. Frys andra ändringar.

7. Validera flöde och skydd

Registrera unika Message-ID och tider för: extern e-post till personlig brevlåda; alias eller lista; svar och nytt utgående meddelande till kontrollerat externt konto; ofarliga godkända spam-, malware/fil- och Data Control-tester; TLS, karantän, rapport och SSP.

Verifiera varje meddelande i Message History samt Microsoft Message Trace, leverantörsspårning eller serverlogg. På Sophos Firewall kontrolleras DNAT-/brandväggsregel-ID, port och mål. Framgång innebär slutlig leverans, exakt en Sophos-inspektion och avsedd åtgärd, inte bara öppen TCP.

Felsök i ordning: MX/DNS, domän-/brevlådestatus, connector eller smart host, DNAT och målzon, regelordning och ID, port/TLS, relay, policyscope och sist filter. Saknat Message History-resultat tyder oftast på routning, inte behov av brett undantag.

8. Återställ eller avveckla säkert

Vid avbrott återställ först gammal utgående smart host/connector och publicera gammalt MX, men DNS är asynkront. Under minst gammal MX-TTL plus auktoritativ spridning hålls båda inkommande vägarna fungerande: gammalt mål för cache med gammalt MX; Sophos Email, domän/routning och tillfällig DNAT/brandvägg/relay för cache med nytt MX. Vägarna får inte skicka tillbaka till varandra. Testa och mät via DNS, Message History och loggar.

Stäng av ny inkommande väg först efter cachefönstret och inga leveranser i loggar, inte när gammalt MX publiceras. Stäng av gamla SMTP-policyer efter rollbackperioden och ta sedan bort onödig NAT/regler/objekt/relay efter acceptans. Behåll bevis. Ta inte bort väg som krävs av cachelagrat MX, POP/IMAP eller ej ersatt funktion.