Migrar de Sophos Firewall Mail Protection a Sophos Email

Esta migración traslada la inspección y las políticas de Sophos Firewall Mail Protection a Sophos Email en Sophos Fusion (antes Sophos Central). No es una copia de configuración: primero se asignan funciones y destinatarios, después se prepara Sophos Email sin alterar el enrutamiento productivo y, por último, se conmuta el flujo de forma controlada. La ruta anterior debe poder recuperarse hasta que termine el plazo de reversión acordado.

⚠️ No cambie a la vez MX, smart host saliente, DNAT y varias políticas sin probar. Antes de tocar el firewall o el enrutamiento, cree una copia actual de Sophos Firewall, registre los valores originales y compruebe un acceso de administración independiente.

1. Elegir arquitectura y criterios de parada

Microsoft 365 admite Sophos Mailflow o Sophos Gateway. Mailflow utiliza conectores y reglas de Microsoft 365; Gateway usa enrutamiento SMTP y normalmente cambia MX. Las demás plataformas usan Gateway. Consulte Planificar la arquitectura y el onboarding. Cada dominio debe tener una sola ruta productiva de inspección Sophos.

Defina ventana, responsables de Sophos Fusion, Sophos Firewall, DNS y servidor de correo, piloto y criterios de parada. Correo externo no entregable, relay abierto, doble procesamiento o un bucle obligan a revertir. La licencia de Sophos Email debe estar activa.

2. Conservar inventario, copia y ruta de retorno

Por dominio, documente:

• MTA Mode o Legacy Mode/transparent proxy actual;
• dominios, buzones, alias, listas y uso de SSP;
• MX entrante, smart host saliente, fuentes de relay, NAT, puertos SMTP y TLS;
• políticas SMTP, orden, excepciones, remitentes bloqueados, resúmenes de cuarentena y DKIM;
• acciones antispam/antimalware, archivos, Data Control, cifrado/SPX y banners;
• IDs de reglas NAT/firewall, objetos, zonas, logs, destino y ruta de retorno.

Exporte o capture todo, genere una copia actual de Sophos Firewall y escriba el orden exacto de restauración. Reduzca TTL solo mediante el procedimiento de cambios. No borre las reglas antiguas.

3. Asignar políticas y aprobar las funciones sin equivalente

Cree una fila para cada política de origen, conserve su orden y ámbito y configure realmente el destino:

• Spam de MTA Mode: en Email Security > Policies > [Email Security policy] > Settings > Anti-Spam, asigne None → Deliver, Warn → Tag subject line, Quarantine → Quarantine y Drop → Delete. Configure SPF, DKIM y DMARC en Authentication con la acción aprobada.
• Spam de transparent proxy: en el mismo destino Anti-Spam, asigne Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine y Drop → Delete. Reject y Change Recipient no tienen equivalente en Sophos Email; rediseñe el flujo o acepte expresamente el riesgo, sin sustituirlos silenciosamente por Deliver o Delete.
• File/Data Control: vuelva a crear las reglas de adjuntos en Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule con la plantilla Attachment file types (AFT). Rehaga las Data Control Lists personalizadas con Content control lists (CCLs) y las comprobaciones de tamaño/cabecera/origen con Message Attribute (MA). Elija y pruebe dirección entrante o saliente, acción y excepciones de cada regla; las listas del firewall no se migran automáticamente.
• Encryption/SPX: asigne SMTP TLS del firewall a Email Security > Policies > Secure Message: Base Policy – Secure Message o a una política más limitada en Add Rule > Secure Message. Una regla con ámbito necesita selecciones internas y externas. Push Encryption es la contraparte de cifrado PDF de SPX y Portal Encryption usa Sophos Secure Message; como el destinatario define las contraseñas, no se copian ajustes ni contraseñas SPX. Valide TLS entre el servidor y Sophos Email.
• Exceptions: asigne una excepción antispam de remitente/destinatario a una Email Security Policy limitada con Anti-Spam = Deliver; una excepción global va a Email Security > Settings > Inbound Allow/Block > Add allow como correo, dominio o IP y omite globalmente el control de spam. Asigne excepciones SPF/DKIM a Authentication en una política limitada, Intelix a Anti-malware y Data/File excluyendo direcciones o Message Attributes en la regla Data control concreta. Revise las autorizaciones amplias en vez de copiarlas sin análisis.
• Sin equivalente directo: no se pueden configurar RBL personalizadas ni greylisting en Sophos Email; Sophos Email Advanced usa Sophos Delay Queue activada automáticamente, no greylisting del cliente. Los secretos BATV y el comportamiento BATV del firewall no tienen un ajuste que migrar a este servicio cloud. POP/IMAP scanning no está disponible. Novell eDirectory/OpenLDAP no tienen migración idéntica, SNMP se sustituye por notificaciones/informes de Sophos Fusion con responsables, y Hardware Monitoring del firewall continúa como tarea separada.

No continúe hasta que cada fila tenga un destino probado o una función sin equivalente documentada y con aceptación explícita del riesgo.

4. Preparar Sophos Email por completo

Añada o sincronice dominios y todos los destinatarios; concilie alias y grupos con el inventario. Prepare SSP, cuarentena administrativa y roles. Cree políticas de destino con ámbitos reducidos y el orden previsto, inicialmente en piloto o sin aplicar. Use Configurar Sophos Email Gateway o, para Microsoft 365, Configurar Sophos Email Mailflow.

Obtenga hosts, IP y DNS regionales exclusivamente de Configure External Dependencies en su tenant. No reutilice ejemplos ni tickets.

5. Preparar la interoperabilidad temporal del firewall

Este paso solo se necesita si Sophos Email debe entregar, después de la inspección cloud, a través de Sophos Firewall hacia un servidor local o de terceros. Omítalo para Microsoft 365 o Google Workspace si no requieren ese salto.

Cree explícitamente la regla DNAT desactivada: Original source = Sophos Delivery IPs regionales actuales de Configure External Dependencies; Original destination = interfaz/dirección WAN que recibe; Original service = puerto de entrega al que conecta Sophos Email; Translated destination (DNAT) = host/IP real del servidor interno; Translated service (PAT) = puerto SMTP donde escucha realmente el servidor (normalmente SMTP/25). Use PAT solo si esos servicios difieren y defina la interfaz entrante correspondiente. Nunca ponga el servidor interno en Original destination ni el objeto público/WAN en Translated destination.

Cree desactivada la regla firewall asociada y por encima de coincidencias generales: Source zones = zonas orientadas a WAN, Source networks and devices = esas Sophos Delivery IPs, Destination zones = zona post-NAT del servidor, Destination networks = destino WAN pre-NAT usado como Original destination en DNAT, y Services = servicio/puerto de entrega original aceptado en WAN, no el servicio SMTP/PAT traducido. Active logging. Los campos describen deliberadamente etapas pre-NAT y post-NAT diferentes; no los iguale por aparente coherencia. Confirme el retorno y limite el relay del servidor a la ruta Sophos prevista.

El nuevo salto no debe pasar otra vez por el MTA/proxy antiguo. El destino de Sophos Email no puede resolver al MX público de Sophos ni volver mediante un smart host. Defina una única salida: servidor/proveedor → Sophos Email → Internet.

6. Conmutar por etapas

Revise copia, destinatarios, políticas, alcance del destino, orden de reglas y autorización de rollback. Para un destino local, active primero DNAT/firewall y confirme el Rule Hit esperado. Para Mailflow, active conectores y reglas Microsoft tras resolver conflictos. Para Gateway, cambie ahora el MX público a los valores del tenant.

Pruebe primero la entrada. Solo cuando externo → Sophos Email → destino funcione claramente, cambie el smart host o conector saliente. Ajuste SPF, DKIM y DMARC para la ruta emisora final según el tenant y compruebe los tres en DNS y en las cabeceras recibidas. Congele otros cambios DNS, de reglas y políticas durante la aceptación.

7. Validar flujo y protección

Registre Message-ID y hora únicas por dominio:

1. entrada externa a un buzón personal;
2. mensaje a un alias o lista;
3. respuesta y mensaje saliente a una cuenta externa controlada;
4. pruebas inocuas autorizadas de spam, malware/archivo y Data Control;
5. controles de TLS, cuarentena, informes y SSP.

Demuestre cada mensaje en Message History y en Microsoft Message Trace, el trace del proveedor o logs del servidor. En Sophos Firewall compruebe IDs DNAT/firewall, puerto y destino. Éxito significa entrega final, exactamente una inspección Sophos y la acción prevista, no solo TCP abierto.

Diagnostique en orden: MX/DNS, estado de dominio/buzón, conector o smart host, DNAT y zona, orden e ID de regla, puerto/TLS, relay, ámbito de política y finalmente filtros. La ausencia en Message History suele ser enrutamiento, no motivo para una excepción amplia.

8. Revertir o retirar con seguridad

Al abortar, restaure primero el smart host/conector saliente anterior y publique los valores MX previos, pero trate el cambio DNS como asíncrono. Durante al menos el TTL MX anterior más la ventana de propagación DNS autoritativa, mantenga funcionales ambas rutas de aceptación entrante: el destino antiguo acepta tráfico de cachés con el MX antiguo; Sophos Email, su dominio/routing y cualquier ruta temporal DNAT/firewall/relay siguen aceptando tráfico de cachés con el MX nuevo. Ninguna ruta debe devolver mensajes a la otra. Envíe controles por ambas y mida tráfico con DNS, Message History y logs del servidor.

Desactive la nueva entrada solo cuando haya vencido la ventana de caché y los logs no muestren más entregas por ella; no desactive las reglas firewall temporales al volver a publicar el MX antiguo. Solo tras una ventana de rollback estable desactive las políticas SMTP antiguas. Después de otra aceptación, elimine NAT, reglas, objetos y permisos de relay innecesarios. Conserve copia, mapa de políticas, DNS, Message-ID y acta. No retire una ruta mientras dependan de ella respuestas MX almacenadas, POP/IMAP u otra función sin sustituir.