Configurar Sophos Firewall Mail Protection en modo MTA

En MTA mode, Sophos Firewall acepta los correos, los inspecciona y los entrega al servidor de correo interno o al siguiente mail hop. El flujo solo funciona si el registro MX, la regla MTA automática, la SMTP route and scan Policy, el relay, TLS y la verificación de destinatarios encajan entre sí.

La configuración consta de seis pasos: definir el flujo y la ruta de reversión, activar MTA mode, añadir el dominio de correo, crear la route and scan Policy, proteger el relay y cambiar el registro MX. Después se validan los flujos entrante y saliente mediante comandos externos, cuarentena, spool y logs.

Cuándo conviene MTA mode

Mail Protection en el firewall resulta especialmente útil en entornos on-premises e híbridos diseñados de forma consciente, en los que se debe proteger un Exchange local u otro servidor de correo. Para Microsoft 365, Google Workspace y muchos entornos exclusivamente cloud, Sophos Central Email u otro gateway de correo cloud suele ofrecer una arquitectura más clara. Encadenar dos gateways complica la cuarentena, los headers, TLS, SPF/DKIM/DMARC y el troubleshooting.

Se deben distinguir tres funciones de Sophos Firewall:

• MTA mode: el firewall acepta, inspecciona y enruta el correo.
• Legacy mode: procesamiento proxy transparente antiguo para entornos existentes.
• SMTP Relay en Device Access: controla desde qué zonas se puede alcanzar el MTA. El correo entrante desde Internet requiere WAN; el relay saliente se restringe además a servidores de correo internos concretos.

Se necesita una licencia válida de Email Protection, routing y DNS operativos, una IP pública conocida, el servidor de correo interno y su puerto de destino, además de estrategias definidas para TLS, cuarentena y reversión. Según la descripción actual de Sophos, MTA mode no está disponible en XGS 87/87w ni XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation y SXL2 Live Protection requieren acceso a Internet. El routing de correo, el análisis antimalware, el filtrado MIME y SPX pueden seguir funcionando con la licencia adecuada en un entorno airgap, pero un MTA activo no implica que allí estén disponibles todas las comprobaciones de protección.

Configurar MTA mode de principio a fin

1. Definir el flujo de correo y la ruta de reversión

Para el flujo entrante, el registro MX público apunta a la dirección en la que Sophos Firewall acepta TCP 25. El firewall inspecciona el mensaje y lo entrega al servidor interno. Una regla DNAT antigua no debe dejar dicho servidor accesible directamente desde Internet sin inspección, pues permitiría eludir el MTA. Publicar un servidor mediante DNAT explica la lógica general de DNAT.

Para el flujo saliente, solo el servidor previsto envía a través del firewall. La ruta de envío, el smarthost, PTR/rDNS, HELO, SPF, DKIM y DMARC deben corresponder a la identidad pública del remitente. Una regla general LAN to WAN es demasiado amplia; la base de reglas debe identificar claramente al remitente SMTP permitido. Entender las reglas de Sophos Firewall explica el orden de las reglas.

Antes de la migración se documentan:

• registro MX actual, prioridad y TTL;
• nueva dirección pública del firewall y servidor de destino interno;
• reglas DNAT y SMTP existentes y conectores del servidor de correo;
• remitentes de prueba entrante y saliente;
• registro MX o ruta de correo anteriores como reversión;
• monitorización de la cola del servidor, el spool del firewall y la cuarentena.

El TTL debe reducirse con antelación si puede ser necesaria una reversión rápida. Los cambios del MX productivo pertenecen a una ventana de mantenimiento.

2. Configurar MTA mode y los ajustes SMTP básicos

En Email > General settings, seleccionar Switch to MTA mode si es necesario. Sophos Firewall crea entonces la regla Any-to-Any Auto added firewall policy for MTA para SMTP y SMTPS. No se debe editar y debe permanecer al principio de la lista de reglas. Al cambiar a Legacy mode se elimina y al volver a MTA mode se crea de nuevo.

Después se configuran los ajustes básicos:

1. En SMTP hostname, introducir el nombre de dominio, por ejemplo example.com, no el hostname del servidor interno. El valor aparece en HELO y en el banner SMTP de las notificaciones generadas por el sistema.
2. Activar Reject based on IP reputation para rechazar conexiones de remitentes con mala reputación.
3. En SMTP TLS configuration, seleccionar un certificado de confianza pública y permitir Allow invalid certificate únicamente para excepciones documentadas.
4. Activar Disable legacy TLS protocols, salvo que haya sistemas antiguos documentados que lo impidan. Esta opción desactiva protocolos anteriores a TLS 1.1; no obliga automáticamente a usar solo versiones TLS actuales.
5. Activar Scan outgoing mails si también se deben inspeccionar los mensajes salientes.

Se debe usar Require TLS negotiation con precaución: si SFOS no puede establecer la conexión TLS exigida, descarta el correo al destino afectado o procedente del dominio remitente configurado. Además, el firewall valida SMTP TLS mediante la IP del dominio y no mediante su nombre. Varios dominios en una misma IP pueden provocar errores de certificado.

3. Añadir el dominio como Address Group

1. Abrir Email > Address group > Add.
2. Establecer Group type en Email address/domain y Type en Manual.
3. Añadir el dominio protegido, por ejemplo example.com.
4. Guardar el grupo.

Las nuevas SMTP route and scan Policies se diseñan con dominios, no con direcciones de destinatarios individuales. Las direcciones individuales migradas pueden seguir funcionando, pero no se pueden añadir ni editar en las policies actuales.

4. Crear una SMTP route and scan Policy

Abrir Email > Policies and exceptions > Add a policy > SMTP route and scan:

1. Introducir un nombre claro, por ejemplo Inbound example.com to Exchange.
2. En Protected domain, seleccionar la Address Group.
3. Elegir Route by:
   • Static host: IP fija del servidor interno; si falla, el firewall prueba el siguiente host de la lista.
   • DNS host: nombre DNS como mailserver.example.com; se utilizan varios registros A entre entregas y se omiten los servidores que fallen.
   • MX: entrega basada en un registro MX.
4. Para Static host, seleccionar el servidor en Host list. Si es necesario, crear su IP host en Hosts and services > IP host.
5. Establecer Global action en Accept.
6. Activar Spam protection y Malware protection según la política operativa.
7. Activar File protection y Data protection solo después de entender su efecto sobre adjuntos, mensajes grandes, SPX y DKIM.
8. Guardar la policy.

Con Route by MX, el MX resuelto por el firewall no debe apuntar de nuevo al propio firewall, pues se produciría un bucle de routing. El firewall debe resolver correctamente los destinos internos; para split DNS sirven las DNS Request Routes.

La opción Route inbound mail through gateway solo es necesaria para diseños especiales, por ejemplo servidores de destino en la zona WAN, aplicación de la regla original a destinos LAN/DMZ o selección de un gateway concreto con varias conexiones a Internet. No se debe activar sin un requisito real de routing.

5. Proteger el acceso entrante y el relay saliente

En Administration > Device access, permitir SMTP Relay desde todas las zonas que deban alcanzar el MTA. El correo entrante desde Internet requiere WAN; el saliente necesita además la zona del servidor interno, normalmente LAN o DMZ. Después, en Email > Relay settings > Host-based relay, restringir el acceso a servidores, escáneres o aplicaciones concretos.

Las autorizaciones amplias de hosts o redes crean un riesgo de open relay. Si impresoras o aplicaciones deben enviar correo, se documentan como objetos de host concretos. Proteger el acceso a Sophos Firewall explica los fundamentos de Device Access.

La SMTP route and scan Policy no admite SMTP AUTH. Para dispositivos, Host-based relay es por tanto la opción fiable. Existen además Authenticated relay settings separadas para usuarios y grupos; Sophos advierte de que no implementan un estándar SMTP Authentication conforme a RFC, por lo que se debe probar la compatibilidad del cliente. Esto es distinto de la autenticación del firewall ante un smarthost upstream, para la que SFOS admite PLAIN y LOGIN. Nunca se debe usar como smarthost una IP de interfaz del propio firewall, ya que crearía un bucle de routing.

6. Cambiar el registro MX

El MX público solo se cambia a la dirección del firewall cuando la regla MTA, el dominio, la policy, el relay y la ruta de entrega interna están preparados. Inmediatamente después se envía un mensaje externo de prueba y se comprueba que aparece en Log Viewer o Mail logs, se entrega al servidor interno y llega al buzón.

Si los remitentes externos no pueden alcanzar el firewall o se rechazan de forma generalizada mensajes legítimos, se restaura la ruta anterior documentada. Si el firewall acepta mensajes pero no los entrega, se comprueban primero routing, DNS, TLS, recipient verification y los logs del servidor.

Elegir conscientemente las protecciones

Spam protection es más que la acción aplicada al spam. Los fallos SPF y RBL se rechazan directamente y no siguen las acciones normales para spam o probable spam. Greylisting rechaza temporalmente un mensaje de forma intencionada y exige que el servidor remitente vuelva a intentarlo.

Recipient verification impide mensajes a destinatarios desconocidos:

• With callout: consulta el servidor de destino. Si no está disponible temporalmente, SFOS acepta destinatarios tras un periodo definido en vez de bloquear permanentemente todo el flujo.
• In Active Directory: comprueba mediante Simple, SSL o STARTTLS y tiene un timeout de 30 segundos.

Malware Protection puede usar análisis antivirus simple o doble. Para usar Zero-Day Protection con un solo antivirus, Sophos debe ser el motor principal. Sophos Firewall Zero-Day Protection explica los límites y las decisiones de liberación.

En mensajes salientes importa el orden del procesamiento. El cifrado SPX, los prefijos de asunto, File o Data Protection y los banners salientes pueden modificar el header o el body después de aplicar una firma DKIM. La validación DKIM falla entonces en el destinatario. Se debe decidir si firma el servidor interno, Sophos Firewall o un gateway posterior.

Configurar y probar el cifrado de correo SPX explica cómo se relacionan la plantilla, la prioridad de los activadores, el modelo de contraseña y el Reply Portal.

Validar el flujo de correo

Los siguientes comandos se ejecutan desde un sistema fuera de la red propia:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Sustituir example.com y mail.example.com por los valores reales. Los comandos prueban DNS, TCP 25 y STARTTLS, pero no la autorización de relay ni la entrega completa. openssl s_client permanece interactivo después del handshake; se detiene con Ctrl+C.

Probar al menos estos casos:

• mensaje externo a un destinatario válido;
• mensaje externo a un destinatario no válido;
• mensaje saliente a través del servidor previsto;
• prueba de spam o malware adecuada para la policy;
• STARTTLS y la cadena de certificados presentada;
• acción de cuarentena y entrega tras la liberación;
• intento de relay bloqueado desde una fuente no autorizada;
• ausencia de entrega directa que eluda el MTA mediante una regla DNAT antigua.

Para la primera revisión se utilizan Email > Mail logs, Email > Mail spool, Email > SMTP quarantine y Log Viewer. Para un análisis más profundo se anotan la hora de prueba, remitente, destinatario, asunto, IP de origen y Message-ID, y se correlacionan con estos archivos:

• MTA: smtpd_main.log
• rechazos: smtpd_reject.log
• errores de análisis: smtpd_error.log
• errores internos del MTA: smtpd_panic.log
• anti-spam: sasi.log
• proxy SMTP legacy: awarrensmtp.log
• proxy POP/IMAP: warren.log

Servicios y logs de Sophos Firewall explica la asignación y el acceso mediante Advanced Shell.

Operar la cuarentena y el Mail spool

En Email > SMTP quarantine, filtrar por periodo, remitente, destinatario, asunto y motivo de cuarentena:

• Release: entregar el mensaje.
• Delete: eliminar el mensaje.
• Release and report: liberar y notificar a SophosLabs solo falsos positivos clasificados como Spam o Probable spam.

Los mensajes infectados por virus o clasificados como maliciosos por Zero-Day Protection no se pueden liberar. Para eliminar entradas de Zero-Day Protection, el perfil de administrador necesita permisos de escritura para esa función. Cuando la cuarentena está llena, se purgan los mensajes más antiguos.

Solo reciben resúmenes de cuarentena los usuarios que se han autenticado al menos una vez en el firewall. Las direcciones alias se deben comprobar por separado en el diseño; los mensajes dirigidos a alias no aparecen en User Portal.

Email > Mail spool contiene mensajes aún no entregados o fallidos. SFOS reintenta la entrega durante tres días y descarta los mensajes después de otros cuatro; los mensajes descartados siguen visibles en Mail logs. Un spool creciente es, por tanto, una alerta de problemas de routing, DNS, TLS, policy o servidor, no un motivo para pulsar Retry repetidamente sin diagnóstico.

La cuarentena y el spool consumen almacenamiento local. Se deben monitorizar el espacio libre, el estado de la SSD y System Health; véanse Limpiar almacenamiento y reports y Comprobar SSD Health. En HA, los logs y reports son independientes por node y no se sincronizan, por lo que se deben comprobar ambos. Clústeres HA de Sophos Firewall explica los fundamentos.

Troubleshooting

No llega correo externo

Comprobar MX, A/AAAA, IP pública, TCP 25 y SMTP Relay desde WAN. Después verificar que MTA mode esté activo, que el dominio protegido coincida con la policy y que ninguna regla DNAT antigua o regla de mayor prioridad cambie la ruta esperada. Si smtpd_main.log no muestra ninguna conexión, el problema probablemente se encuentra antes de Mail Protection.

El firewall acepta el correo, pero no lo entrega

Comprobar el servidor interno, la ruta, DNS, puerto de destino, TLS y recipient verification. Static host, DNS host y MX usan rutas de resolución y failover distintas. Correlacionar los logs de rechazo y error del firewall con los del servidor.

Muchos mensajes permanecen en el spool

Revisar primero Email > Mail spool y los logs del MTA. Una causa frecuente es una regla situada por encima de la regla MTA automática que ya coincide con SMTP. En Rules and policies > Firewall rules, comprobar nuevas reglas con posición Top, reglas IPsec o hotspot generadas automáticamente y otros solapamientos. No mover ninguna regla a ciegas; lo decisivo es su match SMTP real.

SFOS 22.0 MR2 también corrige NC-177930, por el que los mensajes permanecían en el spool tras un crash de mailpoller. Si el problema aparece en una versión anterior, el firmware debe formar parte del diagnóstico.

Central muestra Invalid API request

En SFOS 22.0 MR1, Release y Delete podían fallar cuando el firewall se abría mediante Sophos Central. El workaround seguro es iniciar sesión directamente en el WebAdmin local y ejecutar la acción en Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 corrigió el problema. Si sigue fallando, comprobar por separado el perfil de administrador, el acceso de Central y los permisos locales.

No se puede activar Reject based on RBL

Sophos registra en NC-144563 un caso asociado específicamente a SFOS 20.0.2 MR2 Build 378: Si se han cambiado los nombres de los grupos RBL predeterminados en Email > Address group, no se puede activar Reject based on RBL al crear una política SMTP route and scan. En una política existente, la opción no se puede volver a activar después de deshabilitarla. La lista actual de Known Issues no indica una versión corregida.

Los grupos predeterminados se llaman Premium RBL services y Standard RBL services. Primero documentar el build exacto y los nombres actuales de los grupos. Si se cumplen ambas condiciones, restablecer los nombres originales de las RBL predeterminadas, volver a abrir la política y comprobar la opción. No confundir las RBL personalizadas con estos dos grupos del sistema.

En otros builds, o si los nombres predeterminados no han cambiado, una opción atenuada no demuestra NC-144563. Comprobar por separado el tipo de política, Spam protection, la licencia de Email Protection y el resto de la configuración.

Un remitente legítimo se clasifica como spam

Comprobar el dominio remitente, SPF/DKIM/DMARC, headers, reputación, policy match y destinatarios afectados. Solo entonces crear una excepción limitada y con fecha de revisión.

Los sistemas internos no pueden usar relay

Comprobar la zona de origen en Administration > Device access, el objeto de host en Email > Relay settings > Host-based relay y los logs del MTA. Si un escáner espera SMTP AUTH estándar, Host-based relay suele ser más fiable. El Authenticated relay separado, que no cumple RFC, debe probarse con el cliente concreto.

Lista de comprobación operativa

• Se han verificado licencia, compatibilidad del modelo, DNS y servicios de Internet necesarios.
• Se han documentado MX, TTL, rutas pública e interna y reversión.
• La regla MTA automática permanece sin cambios y al principio.
• Ninguna regla DNAT antigua elude Mail Protection.
• Address Group, destino de routing y policy match están probados.
• SMTP Relay entrante desde WAN y permisos de host salientes están correctamente separados.
• Se entienden los efectos de SPF/RBL, recipient verification, TLS, DKIM, SPX y banners.
• Se han realizado pruebas externas positivas y negativas.
• Se monitorizan cuarentena, spool, almacenamiento y logs.
• El flujo se vuelve a probar después de actualizaciones de firmware.

Para una retención y correlación más largas, utilizar Central Firewall Reporting o enviar logs de Sophos Firewall a un SIEM.

FAQ