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. Esto se aplica tanto en modo MTA como en modo Legacy; la ruta de menú hacia la política POP-IMAP opcional es diferente. Una política por sí sola no basta: 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 una política POP-IMAP scan para remitentes, destinatarios o características del mensaje: en Email > Policies and exceptions en modo MTA o en Email > Policies en modo Legacy.
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, en Email > General settings > POP and IMAP TLS configuration, se selecciona en TLS certificate la CA emisora del certificado del servidor de correo, previamente verificada e importada. Allow invalid certificate permanece desactivado. Desactivar la validación no repara un servidor remoto no válido, caducado o no fiable.

Se marca la casilla Disable legacy TLS protocols para desactivar los protocolos anteriores a TLS 1.1, según la ayuda de SFOS. 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 modo MTA, la ruta es Email > Policies and exceptions > Add policy > POP-IMAP scan; en modo Legacy, es Email > Policies > Add policy > POP-IMAP scan. Primero se definen 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.

Para remitentes y destinatarios se seleccionan grupos de direcciones de correo o de dominios y una coincidencia exacta o por palabra clave. Las direcciones de prueba individuales con coincidencia exacta permiten delimitar el piloto; los grupos de dominios o las palabras clave pueden ampliar el alcance previsto. Se comprueba el alcance real con mensajes coincidentes y no coincidentes, sin asumir reglas adicionales de comodines o de distinción entre mayúsculas y minúsculas.

• Inbound email is: seleccionar spam, probable spam, virus outbreak o probable virus outbreak como clasificación.
• Source IP/network address: indicar la dirección IP o de red del remitente.
• Message size: definir un límite superior o inferior del tamaño del mensaje. Este criterio de política no sustituye el límite global Don’t scan emails greater than.
• Message header: seleccionar la cabecera; para Other, introducir sus detalles. Después, elegir coincidencia exacta o por palabra clave e indicar el valor de palabra clave que se comparará.

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.

Un ejemplo de piloto inocuo utiliza los grupos de direcciones de prueba propios con coincidencia exacta y el criterio Message header: Other, detalles Subject, coincidencia exacta y valor de palabra clave Test email. Se configura Prefix subject con el prefijo libremente elegido Pilot y se guarda la política. En el mensaje coincidente, se espera que el asunto pase de Test email a Pilot: Test email. Un segundo mensaje entre las mismas direcciones de prueba con asunto Control email no coincide con el criterio de cabecera y no debería recibir este prefijo. Se adaptan las direcciones y el prefijo al piloto propio; se prueban ambos mensajes nuevos por el mismo trayecto de recuperación previsto. Otras políticas activas no deben distorsionar la comparación.

Para modificar una política POP-IMAP scan existente, abrir Email > Policies and exceptions en modo MTA o Email > Policies en modo Legacy. Seleccionar Edit en la política correspondiente, cambiar los ajustes necesarios y guardar la política. Después, volver a comprobar la recuperación de correo y el efecto de la política en el trayecto previsto del cliente.

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.

Jerarquía XML y límites de la automatización

Para la automatización, el objeto de política se denomina POPIMAPScanningPolicy. La siguiente explicación describe la estructura documentada para SFOS 22/23, no una solicitud POST probada ni lista para enviar. Proteger el acceso a la XML API explica cómo proteger el acceso y evaluar las respuestas XML. Las opciones de análisis de la regla de firewall que realmente coincide siguen siendo necesarias aunque la política se gestione mediante la API.

El ejemplo documentado distingue tres niveles:

• POPIMAPScanningPolicy/Name identifica la política que se va a gestionar. En cambio, POPIMAPScanningPolicy/After/Name identifica la otra política después de la cual se sitúa en el ejemplo. No deben confundirse el nombre de la política de destino y la referencia para el orden. El ejemplo demuestra esta estructura de posicionamiento, pero no un orden general de evaluación ni el comportamiento cuando falta la referencia o se omite After.
• Bajo POPIMAPScanningPolicy/EmailAddress se encuentran SenderEmail, SenderAction, RecipientEmail y RecipientAction. Por tanto, los valores de dirección y los operadores de coincidencia pertenecen al nodo padre común EmailAddress, no directamente al objeto de política. La descripción de los parámetros trata ambos valores de dirección como cadenas individuales; la selección de grupos en la interfaz no implica un nodo de lista XML adicional.
• En el ejemplo, FilterCriteria, Action, To y MatchIs se encuentran directamente bajo POPIMAPScanningPolicy, fuera de EmailAddress y After. Aquí, To contiene el prefijo del asunto para la acción de prefijo, no una dirección de destinatario. Según el criterio, MatchIs describe la clasificación de los mensajes entrantes o el valor de cabecera que se va a comparar.

La tabla de parámetros marca Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria y Action como obligatorios. Indica para Name un máximo de 255 caracteres, para To un máximo de 300 y para MatchIs un máximo de 750 caracteres. Estos límites describen campos, no el alcance permitido de la política; por ejemplo, el valor de dirección Any mostrado en el ejemplo no es una opción adecuada para un piloto limitado.

Otros parámetros específicos de cada criterio son Address para la IP o red de origen (array de cadenas, varios valores), MessageSizeOperator con MessageSize (número entero), así como MessageHeaderString (máximo de 765 caracteres) con MessageHeaderOperator para las comparaciones de cabeceras. La tabla de parámetros enumera estos campos, pero el ejemplo mostrado para mensajes entrantes no los incluye. Por tanto, no es una plantilla XML completa para filtros de IP de origen, tamaño o cabeceras; no se deducen de ella los nodos padre que faltan, las unidades de tamaño ni las dependencias de obligatoriedad.

⚠️ Algunos valores permitidos solo aparecen en la descripción de los parámetros como símbolos sin resolver, como $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} y $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Estos símbolos no son valores literales confirmados para un POST. Aunque el ejemplo muestra Contains, InboundEmailIs y Prefix Subject, no proporciona una correspondencia completa para todas las constantes. Para MessageHeaderOperator, la columna de valores predeterminados incluso indica GreaterThan, mientras que la descripción contempla Contains/Equals. No se debe resolver esta contradicción suponiendo un operador ni enviar etiquetas de la interfaz o nombres de símbolos como valores de API sin verificarlos.

Mientras no se aclaren los valores concretos y la estructura de filtro necesaria para la compilación utilizada, la configuración mediante la interfaz descrita arriba sigue siendo la vía segura documentada. Antes de un cambio mediante API que se autorice posteriormente, conservar los nombres, el orden, el alcance de las direcciones, el criterio y la acción; después, volver a leer el estado guardado o comprobarlo en la interfaz y recuperar de nuevo el par de mensajes de prueba coincidente y no coincidente. La referencia enumera los valores de estado XML 200, 500 y 502 para Add y Edit, pero no incluye mensajes explicativos. Por tanto, un resultado HTTP correcto por sí solo no confirma ni la política guardada ni su efecto. Aquí no se ha ejecutado ninguna llamada de escritura en un appliance.

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

La regla se crea en Rules and policies > Firewall rules. En modo MTA también se puede ampliar la regla de firewall MTA creada automáticamente; para un piloto claramente delimitado, una regla propia y restringida es más fácil de evaluar. En modo Legacy se crea una regla de firewall nueva. 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.

La recuperación, la Firewall Rule ID, los parámetros TLS y la correlación con warren.log demuestran conjuntamente el trayecto de recuperación y TLS previsto, no la eficacia del antivirus. Si se configura una política propia Prefix subject, también se debe probar el par de mensajes descrito arriba: Pilot: Test email para el mensaje coincidente y ningún prefijo Pilot para Control email. Se documentan los asuntos realmente entregados; incluso un prefijo correcto solo demuestra la acción de la política, no la eficacia del antivirus. Si el resultado difiere, se comprueban grupos, tipo de coincidencia, cabeceras y otras políticas activas, y se vuelven a probar ambos mensajes.

La prueba del trayecto incluye también un caso negativo. Para un host piloto no autorizado o un puerto no seleccionado, se define previamente el tratamiento esperado por las reglas y después se comprueban la Rule ID real y las opciones de análisis. Se corrige una segunda regla de análisis involuntariamente amplia; una protección alternativa planificada no es un defecto. La prueba no exige ni ausencia global de protección ni bloqueo indiscriminado. Si se dispone de un sistema de prueba preparado con una cadena de certificados no válida, el intento de conexión o recuperación debe fallar por la validación de esa cadena mientras Allow invalid certificate esté desactivado en el firewall; 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