Configurar Mail Protection de Sophos Firewall en el modo heredado

En el Legacy mode, Sophos Firewall funciona como proxy de correo transparente. El servidor de correo interno sigue siendo el endpoint SMTP real; el firewall reenvía el tráfico mediante las reglas de firewall y NAT existentes y, al mismo tiempo, lo analiza en busca de spam, malware, tipos de archivo o coincidencias de Data Control.

Esto es fundamentalmente distinto del MTA mode. El firewall no se convierte en un Mail Transfer Agent, no asume la entrega de correo mediante dominios protegidos ni ofrece un MTA mail spool para esta ruta. Por tanto, una prueba correcta del puerto SMTP no demuestra ni el análisis del proxy ni que se aplique la política correcta.

⚠️ Cambiar el SMTP Deployment Mode es una modificación global de la ruta de protección del correo. Antes del cambio deben estar documentados el backup, las políticas existentes, las reglas de firewall y NAT y una vía de recuperación probada. Un problema del MTA no justifica pasar al Legacy mode sin planificación.

Legacy mode en nueve pasos

1. Documentar la ruta SMTP entrante y saliente existente con direcciones IP, puertos, NAT y Firewall Rule IDs.
2. Comprobar si el proxy transparente encaja realmente mejor que el MTA mode.
3. Asegurar un backup de la configuración y un acceso de administración independiente.
4. En Email > General settings, seleccionar Switch to legacy mode.
5. Definir el límite de tamaño SMTP, la acción para mensajes demasiado grandes, IP Reputation, los límites DoS y el comportamiento TLS.
6. Crear solo las políticas SMTP malware y SMTP spam necesarias, o comprobar su orden.
7. Limitar las rutas DNAT entrantes y SNAT salientes al servidor de correo real.
8. Activar Scan SMTP o Scan SMTPS en las reglas de firewall que realmente coincidan.
9. Validar los mensajes de prueba entrantes y salientes con Rule ID, resultado de la política, certificado y logs del proxy heredado.

Elegir entre Legacy mode y MTA mode

Legacy mode encaja sobre todo en entornos existentes donde el servidor de correo interno ya está publicado directamente mediante NAT y se desea conservar esta ruta. SFOS se sitúa de forma transparente entre el peer remoto y el servidor. El destino MX, la aceptación SMTP y la lógica de entrega siguen perteneciendo al diseño del servidor de correo existente.

MTA mode es la opción más adecuada cuando el firewall debe aceptar los mensajes, enrutarlos por dominio protegido, retransmitirlos y mantenerlos en un spool durante errores temporales de entrega. Mail logs y mail spool pertenecen expresamente a este modelo operativo. La configuración completa se explica en Configurar Mail Protection en MTA mode.

Según la ayuda de SFOS 22, MTA mode no está disponible en XGS 87/87w ni XGS 88/88w. Sin embargo, esto no convierte automáticamente Legacy mode en una buena arquitectura de correo en la nube. Microsoft 365, Google Workspace y los servicios alojados modernos aplican sus propios requisitos de TLS, autenticación y protección contra abusos. Antes de usar un proxy transparente hay que confirmar su compatibilidad.

En resumen: MTA mode posee un flujo de correo propio. Legacy mode protege una ruta SMTP que ya funciona. Mezclar ambos modelos lleva a buscar en el log equivocado, en un destino NAT incorrecto o en un spool que no existe.

Topología de ejemplo y vía de recuperación

El ejemplo siguiente usa valores de documentación y debe adaptarse al entorno real antes de implementarlo:

• servidor de correo interno 10.20.30.25 en la zona DMZ
• dirección SMTP pública 192.0.2.25 en la ruta WAN
• servicio SMTP entrante TCP 25
• SMTPS opcional en TCP 465, solo si los peers y el servidor usan realmente esta variante
• reglas de firewall SMTP_In_Legacy y SMTP_Out_Legacy

192.0.2.25 pertenece al rango TEST-NET y no es un valor de producción. Antes del cambio se ejecutan una prueba externa de entrada y una prueba de salida con marca de tiempo. Se guardan las Rule IDs que coinciden actualmente, la dirección de origen pública usada por el servidor para la salida y la cadena de certificados.

La vía de recuperación no consiste únicamente en volver a cambiar el modo. También debe ser posible restaurar al estado anterior documentado las nuevas opciones de análisis, el orden de las políticas, DNAT, las reglas SNAT reflexivas o manuales y las pruebas temporales.

Definir la configuración SMTP global

Límite de tamaño, acción para mensajes grandes y protección DoS

En Email > General settings > SMTP settings, Don’t scan emails greater than define el tamaño máximo de los mensajes que se analizan. En la ruta SMTP, el valor 0 significa 51,200 KB según la ayuda de SFOS 22, no ilimitado. Para mensajes más grandes están disponibles Accept, Reject y Drop.

Accept entrega un mensaje demasiado grande sin analizarlo. Reject lo rechaza e informa al remitente, mientras que Drop lo descarta sin notificación. Esta elección es una decisión operativa y de riesgo consciente. Un Drop no probado dificulta el diagnóstico; un Accept no evaluado crea una brecha de análisis que debe documentarse.

Verify sender’s IP reputation comprueba la IP del remitente antes de los criterios de spam de la política SMTP. Los valores SMTP DoS limitan conexiones, mensajes y destinatarios. Los límites de producción se derivan del volumen real de correo y de una línea base, no se copian de un ejemplo genérico de internet.

Bypass spam check for SMTP/S authenticated connections omite globalmente el control de spam para las conexiones que el servidor de correo identifica como autenticadas. Solo es aceptable después de comprobar la autenticación, los orígenes permitidos y la protección contra abusos de esta ruta. Un inicio de sesión correcto no sustituye el análisis de malware ni una prueba negativa con una conexión no autenticada. Los dominios de Spam check exceptions también constituyen un bypass global y no se utilizan como sustituto rápido de una excepción de alcance restringido.

El banner de correo global ofrece Inline, no conversion, MIME part y Off. Solo aparece si el análisis SMTP o SMTPS está activo en la regla de firewall coincidente. Como la modificación del body puede invalidar una firma DKIM existente, la ruta saliente real se valida comprobando los headers en el destinatario.

No sobrevalorar TLS por una casilla

En SMTP TLS configuration se selecciona el certificado CA o de servidor previsto para el análisis. Allow invalid certificate permanece desactivado. Según la ayuda, Disable legacy TLS protocols solo desactiva protocolos anteriores a TLS 1.1 y no demuestra una sesión TLS 1.2 o TLS 1.3 concreta.

Sophos también señala una limitación importante del modo heredado: el firewall establece la conexión TLS mediante la dirección IP del dominio en lugar del nombre de dominio. Si varios dominios comparten una dirección IP, la validación del certificado puede fallar. En este caso, Sophos recomienda otra ruta de protección, como Sophos Email Security. La comprobación no se elude con Allow invalid certificate.

Require TLS negotiation exige TLS para los Remote Hosts o redes seleccionados; Require sender email domains lo exige para los dominios remitentes. Si no puede establecerse la conexión TLS, SFOS descarta los mensajes afectados. Skip TLS negotiation permite intencionadamente conexiones SMTP sin cifrar con los peers seleccionados y solo debe usarse en excepciones documentadas.

Aplicar las políticas de análisis de forma consciente

Tras activar la suscripción Email Protection, Sophos Firewall aplica automáticamente la política predeterminada default-smtp-av al tráfico SMTP en Legacy mode. Las políticas propias se crean en Email > Policies y se procesan en el orden de la lista. Por eso, primero hay que comprobar qué política existente coincide con el remitente y destinatario concretos.

SMTP malware scan

Una política SMTP malware scan controla los tipos de archivo bloqueados, las excepciones MIME, el análisis antivirus y las acciones de entrega. Con Single antivirus, según la ayuda, el motor elegido solo se aplica a mensajes entrantes; los salientes se analizan con ambos motores. Dual antivirus ejecuta los motores primario y secundario uno tras otro.

La acción Quarantine se combina con las acciones para destinatario y administrador. Don’t deliver, Deliver original y Remove and deliver tienen consecuencias muy diferentes. Un archivo adjunto protegido o no analizable no debe equipararse automáticamente a malware. Por ello, cada acción necesita un mensaje de prueba, un estado esperado para el destinatario y una vía de liberación documentada.

Quarantine no significa automáticamente que el destinatario no reciba ningún mensaje; la Delivery option for recipient sigue siendo decisiva. Según Sophos, Notify sender solo funciona junto con Don’t deliver. Los adjuntos protegidos no se analizan, pero pueden seguir generando una notificación. La acción separada del administrador determina si no se envía ninguna copia, se envía el original o un mensaje sin adjunto a los administradores. Estos cuatro resultados no se deducen de un único mensaje de prueba correcto.

SMTP spam scan

Una política SMTP spam scan puede coincidir con la clasificación de spam, el origen o destino, una RBL, el tamaño del mensaje, los headers o una Data Control List. Según la ruta, están disponibles las acciones Reject, Accept, Change recipient, Prefix subject, Drop y Quarantine.

El criterio Data control list y la asignación SPX de esta política solo se aplican a los mensajes salientes. En cambio, None aplica la acción elegida a todos los mensajes entre los grupos de remitentes y destinatarios indicados. Change recipient no entrega adicionalmente al destinatario original, sino que lo sustituye por el destino configurado. Estos tres alcances se prueban con un caso de destinatario positivo y otro negativo antes de colocar la política en el orden de producción.

Preparar tipos de archivo propios y Data Control

En Legacy mode se crean tipos de archivo propios en Email > Policies > File type > Add a partir de una plantilla, extensiones o tipos MIME. Las extensiones se escriben sin punto inicial y solo se pueden editar los tipos propios. Un tipo nuevo no se incorpora automáticamente a las policies existentes. Hay que abrir la scan policy afectada, añadir el tipo y volver a guardarla. Una prueba positiva con un adjunto y otra negativa similar muestran si se aplica realmente la acción prevista.

Una Data Control List se crea en Email > Data control list > Add a partir de las Content Control Lists necesarias. Los filtros Type y Region ayudan a seleccionar solo patrones adecuados de datos financieros, de identidad u otros datos sensibles. La coincidencia de la lista aún no define ninguna acción; esta se establece en la scan policy vinculada. Una lista piloto reducida con una prueba positiva y otra negativa es más segura que una colección amplia de CCLs sin verificar.

En Legacy mode se puede seleccionar SPX en esta política para los mensajes salientes. Sin embargo, el modelo de contraseña, el portal y la validación constituyen un flujo de seguridad propio; se describen en Configurar el cifrado de correo SPX. No se añade una Data Control List ni una asignación SPX a la primera prueba básica del proxy.

Una clasificación errónea confirmada no se corrige desactivando una política amplia. Crear y probar excepciones de correo de forma segura explica cómo omitir comprobaciones individuales para una combinación precisa de origen, remitente y destinatario, y cómo probar después el tráfico que no debe coincidir.

Utilizar el email journaling opcional respetando la protección de datos

En Email > General settings > Email journaling > Add, SFOS puede enviar copias de los mensajes SMTP/S entrantes de destinatarios o grupos de direcciones seleccionados a una dirección de journaling separada. La selección Any abarca todos los mensajes entrantes. La función solo se aplica a SMTP/S; no registra el tráfico POP ni IMAP.

El journaling crea una copia adicional del correo. No constituye automáticamente un archivo a prueba de manipulaciones ni demuestra el cumplimiento de las obligaciones legales de conservación. Antes de activarlo se definen la finalidad, los destinatarios autorizados, el acceso al buzón de journaling, el cifrado, el periodo de conservación, el espacio necesario y el responsable.

Para la primera prueba se selecciona un único buzón de prueba en lugar de Any. Un mensaje entrante dirigido a ese buzón debe aparecer en el destino normal y en el buzón de journaling; un mensaje para un destinatario no incluido no debe generar ninguna copia. La dirección de journaling no debe iniciar un flujo que devuelva la copia a SFOS y provoque un bucle.

La selección de destinatarios solo se amplía después de las pruebas positiva y negativa. Para el rollback se elimina la entrada de journaling o se restablece el estado anterior documentado. Las copias ya entregadas permanecen en el buzón de journaling y se gestionan de acuerdo con sus propias reglas de conservación.

Combinar NAT y reglas de firewall

Publicar la ruta SMTP entrante

Para los mensajes entrantes, una regla DNAT traduce la dirección WAN pública al servidor de correo interno. Original Source se limita tanto como permita el diseño de correo; Original Destination es la dirección pública prevista; Translated Destination es 10.20.30.25 o el servidor de correo real. Original service y translated service permanecen limitados a los puertos SMTP que realmente se ofrecen.

Una regla reflexiva crea además SNAT para la dirección opuesta. Solo se selecciona si esta identidad de origen pública exacta es la prevista para la ruta de salida. Varios enlaces WAN, smarthosts o rutas de proveedor diferentes necesitan su propio diseño de routing y SNAT. El orden general y la zona de destino después de NAT se explican en Publicar un servidor con DNAT.

Usar dos reglas de firewall limitadas

Para la validación, dos reglas separadas son más claras que una regla bidireccional con varias zonas y objetos Any:

• Entrante: WAN hacia la zona del servidor de correo interno, host de destino 10.20.30.25, solo los servicios SMTP necesarios, logging activado
• Saliente: zona y host del servidor de correo interno hacia WAN o el smarthost concreto, solo los servicios SMTP necesarios, logging activado

En Scan email content, se activa Scan SMTP en ambas direcciones necesarias y Scan SMTPS solo cuando se usa realmente SMTPS. Una casilla activada no añade automáticamente un servicio ausente a un diseño de seguridad correcto. El servicio, NAT, listener del servidor y opción de análisis deben describir la misma ruta de puerto.

Las reglas se colocan por encima de otras más generales que ya coinciden con el mismo tráfico. Después de guardar, la Firewall Rule ID registrada es decisiva. La estructura de reglas, la zona NAT y el orden se explican en Configurar reglas de Sophos Firewall de forma segura.

Validar el flujo de correo y el análisis del proxy

Primero se envía un mensaje externo pequeño a un buzón de prueba. A continuación, el servidor de correo interno envía un segundo mensaje a un destinatario externo controlado. Ambas pruebas reciben asuntos únicos y marcas de tiempo UTC.

Para STARTTLS en el puerto 25 y una conexión TLS directa en el puerto 465, pueden ayudar las siguientes comprobaciones de solo lectura desde un sistema de prueba autorizado:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net se sustituye por el FQDN real y solo se prueban puertos que se ofrezcan realmente. OpenSSL confirma la accesibilidad, la cadena de certificados y los parámetros TLS negociados. No demuestra la entrega correcta ni el análisis de malware, spam o Data Control.

En Log Viewer, el origen, destino, servicio, acción y Firewall Rule ID deben coincidir con las reglas nuevas. Para el proxy SMTP/S heredado se correlacionan awarrensmtp.log y awarrenmta.log con la misma marca de tiempo. Los archivos de log se explican en Servicios y logs de Sophos Firewall.

Después se realiza una prueba negativa. Un origen no previsto, un puerto no autorizado o un mensaje de prueba sin el criterio de política no deben recibir por error la misma ruta de protección. En la prueba de producción no se usa malware real; para validar el análisis se emplean patrones de prueba inofensivos establecidos y un buzón controlado.

Delimitar errores según el síntoma

SMTP funciona, pero la política no se aplica

Primero se comprueba la Firewall Rule ID. Si coincide otra regla, se corrigen el orden, origen, destino, objetivo NAT y servicio. Si coincide la regla esperada, Scan SMTP o Scan SMTPS, el orden de políticas y los grupos de remitentes y destinatarios deben ajustarse a la prueba. Una política por sí sola no activa el proxy transparente.

El correo entrante no llega al servidor

Se comprueban por separado la dirección de destino pública, el hit DNAT, el translated destination, la zona de destino, el listener del servidor y la ruta de retorno. Una conexión TCP abierta hasta el firewall no demuestra que DNAT y la regla de firewall lleguen al servidor interno. Packet Capture y Rule ID deben mostrar entrada y reenvío.

El correo saliente usa una dirección IP pública incorrecta

Se comprueban SNAT, la regla reflexiva, el gateway WAN, la ruta SD-WAN y el comportamiento de los reply packets. El proxy heredado no selecciona automáticamente la dirección de origen pública necesaria para SPF, RDNS o la autorización del proveedor. Antes de cambiar globalmente Route Precedence, se demuestra la ruta concreta.

TLS falla después de activar el análisis

Se registran el FQDN, la IP de destino, el certificado, el emisor, la cadena y la versión negociada. Con varios dominios en una dirección IP, la comprobación de certificados basada en IP que está documentada puede ser la causa. Allow invalid certificate no se activa como solución rápida.

Falta un mensaje y no aparece nada en MTA mail spool

Esto no es un criterio de éxito útil en Legacy mode, porque mail spool y los mail logs específicos de MTA pertenecen a MTA mode. La cadena relevante consta de la regla de firewall, NAT, logs del servidor SMTP, Log Viewer, awarrensmtp.log y awarrenmta.log. Los mensajes en cuarentena se comprueban por separado en Email > SMTP quarantine.

Realizar un rollback seguro

Para el rollback, primero se restauran las reglas piloto y las opciones de análisis al estado anterior documentado. Después se retiran las nuevas asignaciones de políticas o se restablece su orden. Las modificaciones temporales de DNAT, SNAT o certificados solo se eliminan si ningún otro servicio depende de ellas.

Solo entonces se restablece el SMTP Deployment Mode si el cambio incluía esa conmutación. El flujo de correo entrante y saliente original debe volver a funcionar con las Rule IDs, direcciones públicas y logs del servidor esperados. Como rollback estándar no se eliminan mensajes, contenido de la cuarentena ni logs del proxy.

Lista de comprobación operativa

• El proxy transparente es una elección consciente y se han descartado requisitos de MTA.
• Están documentados el backup, el acceso de administración y las Rule IDs originales.
• El límite de tamaño SMTP, la acción para mensajes grandes, IP Reputation y los límites DoS están justificados.
• Se han comprobado el certificado, las excepciones TLS y los dominios afectados.
• DNAT, SNAT, la zona de destino y los puertos reales del servidor coinciden.
• Las reglas entrante y saliente son limitadas, tienen logging y se ha demostrado que coinciden.
• Las políticas predeterminadas y propias poseen un orden comprensible.
• El journaling opcional está limitado a los destinatarios necesarios y tiene una finalidad documentada de protección y conservación de datos.
• Se han superado las pruebas positiva, negativa, TLS y de entrega.
• Los logs del proxy heredado y del servidor de correo pueden correlacionarse por tiempo.
• Están registrados el responsable, la fecha de revisión y la vía de recuperación completa.

FAQ