Analizar y probar POP3 e IMAP en Sophos Firewall

Sophos Firewall puede analizar los mensajes cuando los clientes los recuperan mediante POP3, POP3S, IMAP e IMAPS. No basta con crear una política POP-IMAP. Solo una regla de firewall coincidente dirige el tráfico de correo por el proxy y activa los ajustes configurados de análisis y TLS.

Por tanto, la prueba de aceptación más importante no es un interruptor verde, sino una recuperación real desde el cliente previsto hacia el servidor de correo previsto. La Firewall Rule ID, el puerto, la cadena de certificados, la versión TLS negociada y warren.log deben corresponder al trayecto planificado.

⚠️ Sin Scan email content en la regla de firewall que realmente coincide, SFOS no aplica los ajustes ni las políticas POP/IMAP. Una política por sí sola no ofrece protección.

Análisis POP/IMAP en ocho pasos

1. Documentar la red cliente, el servidor de correo, los protocolos y los puertos utilizados realmente.
2. Seleccionar una única fuente piloto y probar su recuperación de correo actual.
3. Importar en Certificates > Certificate authorities la CA que emitió el certificado del servidor de correo si todavía no es de confianza.
4. Definir POP/S and IMAP/S settings y POP and IMAP TLS configuration en Email > General settings.
5. Solo si es necesario, crear en Email > Policies and exceptions una política POP-IMAP scan para remitentes, destinatarios o características del mensaje.
6. Crear una regla de firewall limitada y registrada para el cliente piloto y el servidor de correo y activar los protocolos necesarios en Scan email content.
7. Verificar la recuperación, la conexión TLS, la Firewall Rule ID y warren.log con un mensaje de prueba pequeño.
8. Incorporar más clientes solo después de las pruebas positiva y negativa y documentar la vía de reversión.

Qué protege el proxy POP/IMAP

POP3 e IMAP sirven para recuperar y administrar mensajes en un buzón. No son SMTP, que transporta mensajes entre un remitente, un MTA y un servidor de correo. Por eso, la guía del modo MTA explica MX, enrutamiento SMTP, relay, spool y cuarentena SMTP; esta guía se centra en la recuperación de correo de un cliente.

SFOS distingue los puertos sin cifrar o actualizados mediante STARTTLS de las variantes que usan TLS desde el principio:

• POP3: TCP 110, con actualización opcional a TLS mediante STARTTLS
• POP3S: TCP 995, TLS desde el inicio de la conexión
• IMAP: TCP 143, con actualización opcional a TLS mediante STARTTLS
• IMAPS: TCP 993, TLS desde el inicio de la conexión

Los diseños nuevos deberían usar conexiones cifradas para los clientes de correo. Sin embargo, seleccionar un protocolo en SFOS no cambia la configuración del cliente. Si el cliente utiliza otro puerto o evita la regla planificada, ese tráfico no queda protegido automáticamente por la opción estándar seleccionada.

El análisis POP/IMAP requiere una licencia válida de Email Protection. No sustituye la protección del servidor de correo ni el análisis cuando llega un mensaje por SMTP. Especialmente con servicios de correo en la nube, primero hay que confirmar si el proveedor permite la recuperación POP/IMAP convencional y si un proxy transparente es compatible con sus requisitos TLS y de autenticación.

Definir el ejemplo y el límite de prueba

Un piloto controlado evita que una configuración incorrecta de certificado o regla afecte a todos los clientes de correo a la vez. Este ejemplo utiliza valores de documentación:

• cliente piloto 10.20.30.50 en la zona LAN
• servidor de correo mail.example.net
• dirección de destino 192.0.2.25
• protocolo utilizado IMAPS en TCP 993
• regla de firewall Pilot_POP_IMAP_Scan

Se sustituyen 10.20.30.50, mail.example.net y 192.0.2.25 por los valores reales. La dirección de destino pertenece al rango de documentación TEST-NET y no debe usarse como dirección de un servidor de producción. El piloto debería utilizar un buzón de prueba propio y no la única cuenta de un administrador.

Antes del cambio, se recupera un mensaje y se anota el emisor actual del certificado. También se conservan la regla de firewall existente, su contador y la configuración del cliente. Así se puede distinguir después entre un problema de enrutamiento, TLS, análisis del proxy o servidor de correo.

Preparar TLS y los límites de análisis

CA y validación del certificado

En Certificates > Certificate authorities se añade la CA que emitió el certificado del servidor de correo si el firewall aún no confía en ella. Los archivos de CA privadas solo pueden proceder de la PKI propia o de otra fuente verificada. Importar certificados en Sophos Firewall explica la importación general y la comprobación de la cadena.

A continuación se selecciona el TLS certificate previsto en Email > General settings > POP and IMAP TLS configuration. Allow invalid certificate permanece desactivado. Desactivar la validación no repara un servidor remoto no válido, caducado o no fiable.

Según la ayuda de SFOS, Disable legacy TLS protocols desactiva los protocolos anteriores a TLS 1.1. La opción no demuestra que una sesión concreta utilice TLS 1.2 o TLS 1.3. Si la norma de seguridad exige como mínimo TLS 1.2, se debe verificar la versión negociada en el trayecto real del cliente. Si la combinación implementada no puede cumplir ese requisito, se detiene el despliegue y se evalúa otra arquitectura de protección.

Como el firewall procesa tráfico de correo cifrado para analizarlo, puede aparecer una advertencia de certificado en el cliente. Una advertencia nueva no se descarta sin más. Se comprueban el nombre presentado, el emisor, la cadena y la confianza del cliente y se corrige la causa antes de un despliegue amplio.

Tamaño del mensaje y cabeceras de destinatario

En POP/S and IMAP/S settings, Don’t scan emails greater than define el tamaño máximo del mensaje que se analiza. Para POP/IMAP, 0 no significa ilimitado; según la ayuda de SFOS, establece el límite en 10,240 KB. Los mensajes mayores no se analizan. El límite debe corresponder a los adjuntos habituales, el rendimiento disponible y el riesgo residual aceptado.

Las Recipient headers ayudan a SFOS a identificar destinatarios para las políticas POP/IMAP. De forma predeterminada, el firewall utiliza Delivered-To, Received y X-RCPT-TO. Solo se añade otra cabecera si el servidor de correo real la establece de manera fiable. Una cabecera inventada o eliminada posteriormente produce coincidencias de política difíciles de entender.

Crear una política POP-IMAP opcional

Con una suscripción Email Protection activa, SFOS aplica automáticamente la política predeterminada default-pop-av al tráfico POP3/S e IMAP/S. Elimina los archivos adjuntos infectados por virus y sustituye el cuerpo del mensaje por una notificación. Esta política básica automática debe tenerse en cuenta durante las pruebas y el diagnóstico antes de atribuir el comportamiento a una política propia.

Una política POP-IMAP añade criterios y avisos para el usuario. En Email > Policies and exceptions > Add a policy > POP-IMAP scan se definen primero el nombre y los grupos de remitentes y destinatarios. Después, la política puede reaccionar, entre otros criterios, a la clasificación de spam, la IP o red de origen, el tamaño del mensaje o una cabecera.

Las acciones documentadas son Accept y Prefix subject. Prefix subject entrega el mensaje y añade un aviso al asunto. Por tanto, la política no es una regla general de cuarentena o bloqueo. Si se selecciona None como criterio, la acción se aplica a todos los mensajes entre los remitentes y destinatarios indicados. Hay que revisar conscientemente este alcance antes de guardar.

La política adicional puede omitirse en la primera prueba técnica del proxy. Así queda claro si la cadena básica de TLS, regla de firewall y análisis ya funciona. Solo se añade una política cuando se necesita realmente una lógica de remitente, destinatario o cabecera.

Crear la regla de firewall para la recuperación de correo

La regla se crea en Rules and policies > Firewall rules. Solo debería contener la red cliente o el host piloto previsto, el destino del servidor de correo y los puertos de correo realmente necesarios. Una regla general de LAN a WAN con muchas funciones de seguridad dificulta la aceptación.

Para el ejemplo Pilot_POP_IMAP_Scan sirven estos valores:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: zona del trayecto al servidor de correo, normalmente WAN para un servidor externo
• Destination networks: objeto host para 192.0.2.25 o el servidor de correo real
• Services: IMAPS
• Log firewall traffic: activado

En Scan email content se activa Scan IMAPS. Si el entorno utiliza realmente otros protocolos, también se seleccionan Scan IMAP, Scan POP3 o Scan POP3S. Add ports añade los servicios correspondientes; después deben aparecer en Services dentro de la regla.

La regla se coloca por encima de otra más general que ya coincida con el mismo cliente y servidor de correo. Después de guardar, es decisiva la Firewall Rule ID real en Log Viewer, no la posición esperada en la tabla. Configurar reglas de Sophos Firewall de forma segura explica la estructura, el orden y la validación por Rule ID.

Probar el trayecto completo

Primero se deposita un mensaje pequeño e inocuo en el buzón de prueba privado. El cliente piloto lo recupera mediante el FQDN y el puerto previstos. En Log Viewer, IP de origen, IP de destino, servicio, acción y Firewall Rule ID deben corresponder a la regla nueva. El incremento del contador de otra regla es una condición de parada.

Para comprobar el certificado y TLS se pueden ejecutar, por ejemplo, estas conexiones de solo lectura desde un cliente de la misma red:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Solo se prueban los protocolos que ofrece realmente el servidor de correo. Se sustituye mail.example.net por el FQDN real. La salida confirma el certificado, la cadena y los parámetros TLS, pero no un inicio de sesión correcto ni el análisis del contenido. La conexión interactiva se termina con Ctrl+C después de revisarla.

Después se repite la recuperación con el cliente de correo real. Para analizar el proxy se utiliza warren.log; Log Viewer y Packet Capture muestran además la coincidencia de la regla y el trayecto de red. Se anotan conjuntamente la marca de tiempo, IP del cliente, IP del servidor, puerto y asunto de prueba. Servicios y logs de Sophos Firewall clasifica el archivo y explica un acceso seguro.

Una prueba de aceptación fiable incluye también un caso negativo. Un host piloto no autorizado o un puerto no seleccionado no debe recibir accidentalmente el mismo estado de protección mediante otra regla amplia de análisis. Si se dispone de un sistema de prueba preparado con una cadena de certificados no válida, debe fallar mientras Allow invalid certificate esté desactivado; no se crea un fallo de certificado en el sistema de producción para esta prueba.

Delimitar errores según el síntoma

La recuperación funciona, pero el proxy no analiza

Primero se comprueba la Firewall Rule ID. Si coincide una regla superior o más general, se corrigen orden, origen, destino y servicio. Si coincide la regla prevista, deben estar activos la opción correspondiente Scan IMAP/IMAPS/POP3/POP3S y el puerto en Services. Una política POP-IMAP por sí sola no activa el proxy.

El cliente de correo muestra un error de certificado tras la activación

Se registran el FQDN presentado, el emisor, la validez y la cadena completa. Después se comprueba la CA seleccionada en POP and IMAP TLS configuration y la confianza del cliente. Allow invalid certificate no se activa como solución permanente. Si sigue sin estar claro qué certificado presenta el proxy o el servidor, se revierte el piloto antes de afectar a más clientes.

STARTTLS funciona, pero POP3S o IMAPS no

Se comprueban por separado los puertos y modos de conexión. POP3 en 110 e IMAP en 143 cambian a una sesión cifrada solo mediante STARTTLS; POP3S en 995 e IMAPS en 993 empiezan con TLS. El cliente de correo, el listener del servidor, el servicio del firewall y la opción de análisis activada deben usar la misma variante.

Se entrega un mensaje grande, pero no se analiza

Se compara Don’t scan emails greater than con el tamaño real del mensaje. Incluso 0 limita el análisis POP/IMAP a 10,240 KB. El límite no se aumenta a ciegas por una única prueba sin valorar el efecto sobre el rendimiento y el riesgo aceptado.

Falta el prefijo del asunto

Se comprueban los grupos de remitentes y destinatarios, el tipo de coincidencia, el criterio y las Recipient headers. Es posible que el mensaje se haya analizado técnicamente aunque la política opcional no haya coincidido. Por eso se evalúan por separado el funcionamiento del proxy y la acción de la política.

Operación y reversión

Después de un piloto correcto se incorporan más clientes gradualmente. Durante el despliegue se observan los contadores de regla, warren.log, errores TLS y avisos del soporte técnico. Los cambios de certificado del servidor de correo, FQDN, puerto o perfil de cliente pertenecen después al mismo proceso de cambio porque modifican el trayecto validado.

Para revertir, primero se elimina el piloto de la regla limitada o se desactiva la opción de análisis correspondiente. Después debe funcionar de nuevo la recuperación original y coincidir la regla anterior prevista. Una CA importada o un ajuste POP/IMAP global solo se elimina si ningún otro servicio lo utiliza. Los mensajes, logs o certificados no se borran como paso estándar de reversión.

FAQ