Sophos Firewall ATP: configurar X-Ops Threat Feeds

La antigua Advanced Threat Protection (ATP) se llama Sophos X-Ops Threat Feeds en las versiones actuales de SFOS. El firewall compara el tráfico saliente con una base de datos gestionada por Sophos que contiene direcciones IP, dominios y URL maliciosos conocidos. Así puede impedir, por ejemplo, que un cliente infectado contacte con un servidor de Command and Control conocido.

Para producción, el objetivo es Log and drop. La función está desactivada de forma predeterminada y, una vez activada, solo bloquea si se selecciona esta acción.

Configurar X-Ops Threat Feeds

Antes de activarlo, deben estar licenciados Network Protection y Web Protection. Ambos están incluidos en los bundles Standard y Xstream Protection; X-Ops no necesita una licencia adicional de Sophos Central.

1. Abrir System services > Log settings.
2. En la fila Active threat response, activar como mínimo Local reporting. Según el modelo operativo, seleccionar también el destino Syslog deseado y Central reporting.
3. Abrir Protect > Active threat response > Sophos X-Ops threat feeds.
4. Activar Sophos X-Ops threat feeds.
5. En Action, elegir Log only para un piloto breve y controlado o Log and drop para la protección productiva.
6. En Advanced security settings, decidir entre Inspect untrusted content e Inspect all content.
7. Guardar con Apply.
8. A continuación, comprobar la configuración, los destinos de logs y las excepciones existentes.

XGS 87/87w y 107/107w no admiten reporting local. En estos modelos se utiliza Central Reporting o un servidor Syslog. La columna Central reporting solo aparece después de activar Send reports and logs to Sophos Central en Sophos Central.

Sophos recomienda bloquear los IoC conocidos en lugar de limitarse a registrarlos. Aun así, en un entorno nuevo o que todavía no se monitoriza, Log only puede resultar útil durante una fase de observación breve y con una fecha de finalización clara. Esta fase necesita un responsable y una fecha para el cambio; de lo contrario, la función puede permanecer indefinidamente sin efecto de bloqueo.

Qué protege X-Ops y qué no

X-Ops comprueba destinos maliciosos conocidos en el tráfico saliente reenviado. Un evento típico se produce cuando un cliente o servidor intenta acceder a una IP, un dominio o una URL conocidos de malware, phishing o C2. Según la acción elegida, el intento solo se registra o se descarta directamente.

En cambio, X-Ops no admite Source Matches locales o remotos. Por tanto, no bloquea automáticamente direcciones IP de atacantes conocidas que acceden como origen a una publicación DNAT o WAF, al WebAdmin o a un VPN Portal. Para estos casos son más adecuados MDR, NDR o los Third-Party Threat Feeds, junto con reglas restrictivas de firewall, WAF y Device Access.

El IPS, Malware Scanning y Zero-Day Protection también cumplen otras funciones. X-Ops trabaja con indicadores: un destino debe conocerse ya como IoC malicioso. IPS, en cambio, detecta patrones de ataque conocidos en el tráfico. Ambas funciones se complementan, pero no se sustituyen.

Qué condiciones se necesitan para detectar eventos

La activación por sí sola no garantiza que el firewall pueda ver todos los indicadores de IP, dominio o URL. Lo decisivo es qué información resulta visible en la ruta de red correspondiente.

Direcciones IP

Para detectar una IP de destino, el tráfico saliente debe pasar por una regla de firewall adecuada. El firewall puede comparar directamente la dirección de destino con el feed de X-Ops; para ello no es necesario descifrar TLS.

Dominios

Para detectar dominios, la regla de firewall afectada debe tener activa Application Classification o una IPS Policy seleccionada. Si faltan ambas, puede no producirse la clasificación necesaria en esa ruta de tráfico.

URL completas mediante HTTPS

Una URL contiene, además del dominio, una ruta, por ejemplo https://example.invalid/download/payload.exe. En tráfico HTTPS cifrado, sin descifrado el firewall normalmente solo ve el dominio mediante SNI, pero no la ruta /download/payload.exe.

Para comprobar el indicador de URL completo se necesita Web Proxy con el descifrado HTTPS activado o una regla de SSL/TLS Inspection adecuada con Decrypt. TLS Inspection no debe activarse globalmente y sin control solo por X-Ops: la distribución de certificados, la privacidad, las excepciones, la compatibilidad de aplicaciones y el rendimiento forman parte de un despliegue específico.

Elegir conscientemente el alcance de la inspección

En Advanced security settings se define la amplitud con la que X-Ops inspecciona el tráfico:

• Inspect untrusted content limita la inspección al tráfico con orígenes o destinos no fiables. Esta opción consume menos recursos y constituye un punto de partida razonable cuando aún no se conocen la carga y los efectos secundarios.
• Inspect all content inspecciona tráfico fiable y no fiable. Ofrece mayor cobertura, pero puede afectar al rendimiento, sobre todo en entornos con mucho tráfico.

En redes de clientes, servidores o administración que requieren una protección especial, Inspect all content puede ser apropiado si el appliance tiene suficiente margen. El cambio debe realizarse durante una ventana de mantenimiento. Después se comparan la carga de CPU, la latencia, el rendimiento y las incidencias del helpdesk con el estado anterior.

Durante la introducción no conviene cambiar varias veces y al mismo tiempo la acción y el alcance de la inspección. Si primero se modifica la visibilidad y después la acción de bloqueo, resulta más fácil identificar qué ajuste ha provocado un problema.

Comprobar el efecto y el logging

Después de guardar no basta con comprobar si el interruptor está activo. Una verificación operativa sólida comprende tres niveles:

1. Configuración: X-Ops está activado y se han guardado la Action y el alcance de inspección deseados.
2. Visibilidad: la regla de firewall, Application Classification o IPS y, para URL HTTPS completas, el descifrado TLS se ajustan al tipo de indicador.
3. Evidencia: los eventos aparecen en Log viewer > Active threat response o en el destino configurado de Central o Syslog.

Para obtener un resumen local, se abre Reports > Network & threats > Active threat response. El widget del mismo nombre en el Control Center muestra el estado y el número de amenazas bloqueadas; la acción concreta y los detalles de conexión se comprueban en el informe o en Log Viewer.

El tipo técnico del log Syslog sigue llamándose ATP, aunque la interfaz actual utilice X-Ops y Active Threat Response. Según la ruta de procesamiento, log_component puede mostrar Firewall, DNS, IPS o Web. Para una investigación resultan especialmente útiles la marca temporal, la acción, Source, Destination, los puertos, el dominio o la URL, el Threat Name, el Feed Name y el Event ID.

En Advanced Shell, ips.log es el log principal del motor para Active Threat Response. garner.log ayuda a investigar el procesamiento y reenvío de eventos, especialmente cuando Central Reporting parece incompleto. La descripción de los servicios y logs de Sophos Firewall explica estos archivos y el acceso SSH seguro.

No existe un indicador de prueba inofensivo de X-Ops documentado de forma general. Por eso no se debe acceder deliberadamente a un dominio de malware real ni a una IP maliciosa conocida. Si se necesita una prueba reproducible, un Third-Party Pilot Feed propio con un destino controlado es el método más seguro. En X-Ops se comprueban la configuración y la visibilidad; el siguiente evento real analizado cuidadosamente confirma el efecto de bloqueo.

Investigar una alerta de X-Ops

Un IoC bloqueado es una señal importante, pero todavía no constituye un análisis completo del incidente. La dirección de destino puede haber sido contactada por malware, un enlace de phishing, una extensión de navegador comprometida o un servicio legítimo clasificado por error.

Un procedimiento útil es el siguiente:

1. Guardar la marca temporal, el firewall o nodo HA, la acción y todos los detalles del log.
2. Registrar Source IP, Destination IP, dominio o URL, puertos, protocolo, Threat Name y Feed Name.
3. Correlacionar los logs de firewall, DNS, IPS y Web del mismo intervalo.
4. Identificar el cliente interno mediante el DHCP Lease, la asignación de usuario o los datos del endpoint.
5. Buscar en el sistema afectado el proceso correspondiente, el historial del navegador, la descarga y otros eventos de seguridad.
6. Si se confirma una intrusión, aislar el sistema y tratarlo según el runbook interno de Incident Response.
7. Solo después del análisis decidir si se requiere limpieza, un bloqueo adicional o una excepción muy limitada.

Con Synchronized Security pueden aparecer además el usuario del proceso, el Endpoint ID y la ruta de ejecución en endpoints Windows compatibles. Estos detalles del proceso no están disponibles en macOS; allí la Source IP sigue siendo especialmente importante para la asignación.

Falsa alarma conocida en HA NC-170292

En un sistema HA con SFOS 21.5.1 MR1 Build 261, NC-170292 puede generar en Sophos Central una falsa alerta Advanced threat detected con Raw Logs. Al mismo tiempo, puede llegar un correo del firewall sin detalles aprovechables.

Esta limitación no se aplica de forma general a otros builds ni a firewalls standalone. Por eso, primero se guarda e investiga la alerta como se ha descrito. Si el sistema coincide exactamente con el build afectado y faltan datos concluyentes del evento, Sophos indica el reinicio del servicio Garner como solución temporal. Como la Known Issues List no especifica un comando CLI concreto para este error, el reinicio debe realizarse únicamente según un procedimiento de soporte o mantenimiento aprobado. Si las alertas se repiten, el estado HA, el firmware build, la marca temporal y garner.log deben incluirse en el caso de Sophos Support.

Añadir excepciones solo tras confirmar el análisis

En Protect > Active threat response > Add threat exclusions se pueden añadir Host and network exclusions y Threat exclusions para direcciones IP, dominios o URL. Una excepción de este tipo no se aplica solo a X-Ops, sino a todos los módulos de Active Threat Response. Por tanto, una excepción rápida puede debilitar al mismo tiempo la protección de MDR, NDR o Third-Party Threat Feeds.

Cuando se confirma un falso positivo, solo se debe excluir el indicador mínimo necesario. La excepción debe incluir un motivo, un ticket, una persona responsable y una fecha de revisión. Excluir preventivamente redes completas de clientes o amplios rangos de dominios elimina la alerta visible, pero también gran parte de la protección.

Después del cambio se vuelve a comprobar el mismo proceso de negocio y se verifica en Log Viewer que solo ha desaparecido el evento previsto. Los demás eventos de X-Ops deben seguir registrándose o bloqueándose.