Sophos Phish Threat: permitir remitentes, dominios e IP

Sophos Phish Threat solo puede proporcionar resultados realistas de las campañas si las simulaciones se entregan y los usuarios pueden acceder a las páginas de phishing y formación correspondientes. Para ello, los dominios de remitente, las direcciones IP y los destinos web proporcionados por Sophos deben permitirse en todos los puntos de control por los que realmente pasan. Sin embargo, no es necesario ni recomendable eludir de forma general la seguridad del correo electrónico o de la web.

Este proceso es independiente del proveedor. Se aplica a gateways de correo previos, Mail Transfer Agents, Secure Web Gateways, proxies, firewalls, filtros DNS y de URL, y productos que analizan automáticamente enlaces o archivos adjuntos. Los pasos específicos de cada producto se describen en las guías de entrega para Microsoft 365 y Google Workspace.

Obtener los valores actuales en Sophos Fusion (antes Sophos Central)

La lista vinculante debe obtenerse del tenant de Sophos Fusion afectado:

1. Hacer clic en el icono Global Settings.
2. Abrir Products and Services > Sophos Phish Threat.
3. Hacer clic en Sending domains and IPs.
4. Documentar todos los dominios de remitente, direcciones IP y destinos web mostrados, junto con la fecha de consulta.

Las direcciones IP de Sophos Mailflow regionales no deben añadirse de forma indiscriminada a la lista de permitidos de Phish Threat. Solo se utilizan para los conectores Mailflow de Microsoft 365 configurados automáticamente o para restaurarlos después de cambios en la configuración. Por tanto, estas redes deben introducirse exclusivamente como parte de la configuración documentada de los conectores Mailflow y solo para la región utilizada, no de forma preventiva en gateways previos, proxies o filtros web.

La lista puede contener valores para distintas funciones:

• direcciones IP y dominios para enviar los correos electrónicos de las campañas,
• dominios de remitente o de Return-Path,
• destinos de seguimiento y redirección para medir los clics,
• dominios para páginas simuladas de phishing o de inicio de sesión,
• páginas de formación y otros destinos web necesarios para el desarrollo de la campaña.

Los enlaces de Phish Threat pueden redirigir a través del destino de seguimiento de AWS awstrack.me documentado por Sophos. Esta redirección es normal para la medición de clics. Antes del envío piloto, compare los hosts realmente necesarios con la lista actual de Sophos y los destinos de la campaña concreta. No permita subdominios adicionales salvo que su necesidad esté acreditada allí o en la documentación del producto.

Registrar el flujo de datos antes de permitir el tráfico

La inclusión en la lista de permitidos se realiza en cada punto de control, no solo en el último servidor de correo. Primero debe documentarse la ruta real de un mensaje y un clic de prueba:

1. Sophos Phish Threat envía la simulación.
2. Un filtro en la nube previo, un Secure Email Gateway o un MTA acepta el mensaje.
3. Otros servicios antispam, antiphishing, de sandbox o de análisis de enlaces lo procesan.
4. El sistema de destino lo entrega al buzón.
5. Cuando el usuario hace clic, la solicitud pasa por filtros DNS, proxy, Secure Web Gateway, firewall y, en su caso, protección del navegador o del endpoint.
6. Las páginas de seguimiento, phishing y formación devuelven los eventos a Phish Threat.

Para cada paso, registre el producto, el propietario de la regla, el valor necesario, la excepción deseada, la fecha de caducidad o revisión y la vía de reversión. Si hay varios filtros consecutivos, deben tenerse en cuenta todos los relevantes. Permitir el tráfico únicamente en el buzón de destino no resuelve un bloqueo en el gateway previo.

Implementar la lista de permitidos con el menor alcance posible

La regla solo debe ser tan amplia como sea técnicamente necesario para la simulación. Se prefieren direcciones IP o nombres de host exactos, la lista actual de Phish Threat y los destinatarios de prueba previstos. Utilice un dominio completo, un patrón comodín o una excepción global del escáner únicamente si la configuración de la campaña o el producto no permiten una regla más restrictiva.

Algunos productos distinguen entre entrega, evaluación de spam, reescritura de URL, comprobación Time-of-Click, Attachment Sandboxing y acceso web. Una sola regla «Allow» no cubre automáticamente todas estas funciones. A la inversa, un permiso para la entrega de correo electrónico no debe excluir involuntariamente de todos los controles todos los archivos o URL del mismo remitente.

Permitir hosts variables solo cuando exista una necesidad demostrada

Al principio, añada de forma individual únicamente los hosts indicados en Sophos Fusion o en la documentación del producto y utilizados en la campaña. Si un destino concreto del producto o de la campaña utiliza de forma demostrable hosts variables y el permiso no puede limitarse técnicamente a nombres de host exactos, puede ser necesario un comodín. En ese caso, deben aplicarse controles adicionales:

• establecer el comodín únicamente por debajo del dominio base mostrado por Sophos,
• no permitir todo el dominio superior del proveedor,
• limitar la regla al tráfico de Phish Threat y, si es posible, a los destinatarios piloto,
• documentar el responsable y la fecha de revisión,
• comprobar antes de cada nueva plantilla de campaña si se utiliza un host adicional.

Un permiso muy amplio, como una plataforma compartida completa de nube o de envío, aumenta el riesgo de admitir tráfico ajeno. Si un producto no puede representar el alcance restringido necesario, este riesgo residual debe aceptarse antes del cambio o debe elegirse otra ruta de entrega.

Evitar falsos clics y archivos adjuntos abiertos automáticamente

Los productos de seguridad del correo suelen analizar los mensajes accediendo a las URL o abriendo los archivos adjuntos en una sandbox. Phish Threat puede interpretar dicha solicitud como una acción del usuario. Esto produce supuestos clics o archivos adjuntos abiertos aunque el destinatario todavía no haya interactuado con el mensaje.

Los indicios habituales de que un evento procede de un escáner y no de un usuario son:

• los eventos se producen antes de la entrega o inmediatamente al entregarse,
• muchos destinatarios muestran casi a la vez la misma acción,
• las direcciones de origen o los User-Agents pertenecen al servicio de seguridad,
• se abren varios enlaces del mismo mensaje en rápida sucesión,
• el patrón puede reproducirse con un mensaje piloto recién enviado.

La corrección debe realizarse en el escáner que causa el problema: añada las direcciones IP y los dominios actuales de Phish Threat a su lista prevista para simulaciones de phishing autorizadas o excepciones de análisis específicas. La excepción debe coincidir tanto con el origen identificado como con la función de análisis afectada. Permitir solo una dirección de remitente no es suficiente si el servicio abre cada URL de forma independiente en una sandbox.

La ausencia de eventos de clic suele tener la causa contraria. Los destinos de seguimiento pueden quedar bloqueados por Secure Web Gateways, filtros DNS o extensiones del navegador como los bloqueadores de anuncios. Por tanto, si falta telemetría, no reinicie inmediatamente la campaña; compruebe primero la cadena de redirección en el navegador y los registros del proxy, DNS y endpoint.

Encabezados de omisión de Microsoft 365 solo como excepción heredada

Las guías antiguas utilizan reglas de transporte con los encabezados X-MS-Exchange-Organization-SkipSafeLinksProcessing o X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Estas reglas no son la configuración de referencia para una nueva implantación. Para la entrega basada en SMTP a través de la canalización de transporte de Microsoft 365, Microsoft proporciona la Advanced Delivery Policy. Sin embargo, Sophos recomienda M365 Direct Delivery para nuevas implantaciones; esta ruta de entrega elude la canalización de transporte, por lo que Advanced Delivery no se aplica. La configuración concreta de Microsoft 365 debe seguir las instrucciones actuales de Sophos para la ruta de entrega elegida y queda fuera del alcance de este artículo.

Los encabezados heredados solo deben considerarse si un entorno existente sigue necesitándolos de forma demostrable, se ha comprobado el estado actual del soporte y existe un cambio aprobado con un alcance de IP/dominio restringido. La prioridad, el efecto y las consecuencias de seguridad de la regla deben probarse por separado. Las reglas antiguas de encabezados no deben mantenerse «por precaución» junto con un permiso de simulación actual.

Validar una campaña piloto

Empiece con un pequeño grupo piloto formado por cuentas de prueba controladas. Debe incluir al menos un buzón por cada ruta de entrega, grupo de políticas y ubicación relevantes. La prueba incluye un mensaje con un enlace y, si se utiliza operativamente, una campaña con archivo adjunto y formación.

Antes del envío, documente las marcas de tiempo, el ID de la campaña, los destinatarios, el remitente esperado, el dominio utilizado y los ID de las reglas modificadas. A continuación, compruebe lo siguiente:

1. El gateway acepta el mensaje y lo entrega exactamente una vez al buzón previsto.
2. Los valores que se usan realmente para la coincidencia prevista de la regla concuerdan con la lista actual de Sophos: el dominio From visible correspondiente o el dominio Envelope Sender/Return-Path y, si la regla se basa en IP, la IP de origen del sistema SMTP remitente que el gateway encargado de la comprobación registró como par de conexión. Compruebe estos campos por separado; la IP del servidor receptor no se puede usar como IP de origen del remitente.
3. El mensaje no termina en cuarentena ni, de forma inesperada, en la carpeta de correo no deseado.
4. No aparece ningún evento de clic o archivo adjunto en Phish Threat antes de que actúe un usuario.
5. Un clic controlado del usuario abre la página esperada de redirección, simulación o formación.
6. Esa acción exacta aparece en el resultado de la campaña a una hora plausible.
7. Los registros del proxy, firewall, DNS y escáner muestran la regla prevista, pero ningún bypass innecesariamente amplio.
8. Un mensaje externo de prueba normal y un destino web no permitido siguen analizándose conforme a las políticas de seguridad existentes.

El éxito no significa únicamente que «el correo llegó». Deben confirmarse conjuntamente la entrega, la medición correcta de la campaña, la accesibilidad de los destinos web y la continuidad de unos controles de seguridad eficaces. Solo entonces se ampliará la regla al grupo de destinatarios previsto.

Acotar los errores de forma sistemática

Si falla la entrega, compruebe hacia dentro desde el primer punto de aceptación: registro SMTP, gateway previo, cuarentena, regla de transporte posterior y buzón de destino. El error SMTP o el veredicto del producto indica dónde se rechazó el mensaje. Añadir excepciones amplias sin esta evidencia dificulta el análisis de la causa.

En caso de falsos clics, compare la cronología desde el envío hasta la entrega. Utilice los registros del escáner, la IP de origen y el User-Agent para atribuir una solicitud automática reproducible al producto que la causa. Si no se registran clics reales, compruebe la resolución DNS, la decisión del proxy, la conexión TLS, las redirecciones y las extensiones del navegador.

Si la causa sigue sin estar clara, detenga la campaña piloto. Una excepción no debe ampliarse paso a paso hasta que la entrega funcione por casualidad.

Revertir los cambios y mantenerlos de forma continua

Antes de la implementación, defina una reversión para cada regla: estado anterior, ID de regla, exportación o captura de pantalla, persona responsable y orden de reversión. Si se entregan inesperadamente mensajes ajenos, se eluden los controles de seguridad de forma demasiado amplia, se observan accesos sospechosos en el proxy o los datos de la campaña siguen distorsionados, desactive el cambio o restaure el último estado validado. Después, vuelva a revisar los registros de correo y web.

Para el funcionamiento continuo, aplique como mínimo los controles siguientes:

• comparar los valores actuales con Sophos Fusion antes de cada campaña importante,
• volver a probar las reglas tras un cambio de producto, enrutamiento o proveedor,
• revisar periódicamente si los comodines y las excepciones globales pueden tener un alcance más restringido,
• eliminar dominios, IP y reglas heredadas que ya no sean necesarios,
• asociar a cada excepción una fecha de revisión, un propietario y una justificación técnica,
• después de los cambios, ejecutar siempre una campaña piloto sin falsos clics automáticos.

FAQ