Sophos Firewall ATP: configurar X-Ops Threat Feeds

La antigua Advanced Threat Protection (ATP) se llama Sophos X-Ops Threat Feeds en SFOS 22. 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.

Un Threat Feed es una lista de estos indicadores que se actualiza continuamente, denominados IoCs (Indicators of Compromise). X-Ops recibe automáticamente la base de datos global de SophosLabs; no se introduce una URL de feed propia. En Active Threat Response se pueden configurar uno o varios módulos: MDR Threat Feeds proporciona información de los analistas de MDR sobre amenazas activas en la propia red; NDR Essentials analiza el tráfico del firewall mediante machine learning, evalúa los IoCs detectados y los registra. En cambio, en Third-Party Threat Feeds se introducen URLs de feeds propias. Un módulo X-Ops activo no activa automáticamente los demás módulos.

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

El módulo X-Ops requiere Network Protection. Para implementar la inspección de threat feeds también se necesita Web Protection. Ambas licencias están incluidas en los bundles Standard y Xstream Protection o pueden adquirirse por separado; X-Ops no necesita una licencia adicional de Sophos Fusion (antes Sophos Central).

Antes de realizar cambios, se documentan la compilación del firmware, las licencias, la Action actual, el alcance de la inspección, los destinos de los registros y las excepciones. Para Synchronized Security también se requiere una licencia de Intercept X en Sophos Fusion o Sophos Central; la licencia de X-Ops por sí sola no proporciona integración con endpoints. También se comprueba si las reglas del firewall reaccionan a un Security Heartbeat rojo: en ese caso, el cambio de estado documentado en SFOS 23 puede afectar al acceso del endpoint, además de bloquear la conexión individual.

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. Guardar con Apply los destinos de logs compatibles con este modelo en la página Log settings. Volver a cargar la página y confirmar que los destinos seleccionados siguen configurados antes de pasar a la configuración de X-Ops. Los logs de eventos locales no equivalen a los informes locales; las alternativas para los modelos sin informes locales se indican a continuación.

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.

   SFOS 23: Log only registra el evento sin cambiar el estado de Security Heartbeat del endpoint. Log and drop registra el evento, bloquea la amenaza y cambia el estado de Security Heartbeat del endpoint a rojo.

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 88/88w 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 Fusion (antes 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.

La descripción general y la descripción de X-Ops presentan contradicciones: La matriz de tráfico de la descripción general de SFOS 22/23 indica que X-Ops no admite Destination Match, pero sí admite Source Match local. Sin embargo, la sección de configuración de X-Ops describe la comparación con direcciones IP, dominios y URLs maliciosos, en la que se basa la inspección de destinos de este artículo. Esta matriz contradictoria no permite deducir ni una garantía para todos los destinos del tráfico reenviado ni una cobertura fiable de Source Match local. Para delimitar este alcance, se necesita una confirmación para la compilación utilizada antes de sustituir las reglas de protección existentes. De forma coherente, la matriz no muestra protección de X-Ops para orígenes remotos en DNAT/WAF ni para orígenes del tráfico destinado al sistema hacia WebAdmin, VPN-Portal o VPN. Para estos servicios siguen siendo necesarias reglas restrictivas de firewall, WAF y Device Access; los feeds alternativos se analizan en el artículo sobre Third-Party Threat Feeds.

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.

Active Threat Response comprueba los módulos en este orden: MDR, NDR Essentials, Sophos X-Ops y, después, Third-Party Threat Feeds. Si un módulo anterior bloquea el mismo IoC, el firewall deja de comprobarlo. Por tanto, que no aparezca un log de X-Ops no significa automáticamente que no haya actuado ninguna protección. La guía de Third-Party Threat Feeds explica con más detalle el orden y los indicadores solapados.

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, los ajustes necesarios relacionados con IPS deben estar activos: Application Classification debe estar activada o debe haberse seleccionado una política IPS en la regla de firewall correspondiente. Según la documentación, Application Classification está activada de forma predeterminada; aun así, se comprueba su estado real. Aquí no debe entenderse como un interruptor adicional en cada regla de firewall. El requisito afecta especialmente a HTTPS y a las consultas DNS a resolutores externos mediante HTTP o HTTPS. Si falta la clasificación necesaria, puede que no se realice la comparación de dominios en la ruta de tráfico correspondiente.

Si el propio firewall responde a las consultas DNS de los clientes, el módulo DNS realiza la comparación del dominio. Si los clientes utilizan un resolver externo, esa ruta DNS también debe atravesar el firewall y ser visible con los ajustes de IPS necesarios. Cuando no aparece una detección de dominio, hay que comprobar la ruta del resolver que se utiliza realmente, no solo la regla del cliente hacia el destino Web.

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.

Con Web Proxy, en la regla de firewall correspondiente, se seleccionan las opciones Use web proxy instead of DPI engine y Decrypt HTTPS during web proxy filtering en Web filtering. En la ruta DPI, Use web proxy instead of DPI engine permanece desactivada; la regla de descifrado correspondiente se configura en Rules and policies > SSL/TLS inspection rules con Action Decrypt. Ambas rutas también necesitan los requisitos de clasificación mencionados anteriormente para una inspección completa de las URLs HTTPS. Solo se modifica la ruta de tráfico autorizada y, después, se comprueban la confianza en los certificados, el proceso de negocio habitual y la regla que realmente se aplica en Log Viewer.

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.

La documentación describe la diferencia de rendimiento entre los dos alcances de inspección como generalmente pequeña, aunque puede ser considerable cuando el tráfico es elevado. Antes del cambio, se registra el valor actual. Si la comparación muestra un deterioro relevante, se restablece el alcance de inspección anterior en Advanced security settings, se guarda con Apply y se vuelven a comprobar el proceso de negocio, la carga y el registro de eventos. Para ello no es necesario desactivar de forma general la acción de bloqueo.

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 Control Center muestra una visión general de los hosts afectados y los eventos de amenazas. MDR y X-Ops muestran el estado y las amenazas bloqueadas; NDR Essentials, el estado y las amenazas supervisadas; Third-Party Threat Feeds muestra además los feeds configurados y su estado de sincronización. Configure lleva a la configuración, Reports a los informes y More details amplía la vista del widget. En dispositivos sin informes locales no aparece el botón Reports; en ellos se utilizan los destinos de Central o Syslog configurados. Un recuento de amenazas supervisadas por NDR no demuestra que se hayan bloqueado. La acción concreta y los detalles de la conexión se comprueban en el informe o en Log Viewer. Para Third-Party Threat Feeds, el widget muestra también el número de amenazas bloqueadas por estos feeds.

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.

Si un IoC no se bloquea o no aparece un log de X-Ops

La comprobación debe comenzar por el tipo de indicador concreto y la ruta real del tráfico. Así se evitan excepciones amplias o cambios globales de TLS basados en suposiciones:

1. En Protect > Active threat response > Sophos X-Ops threat feeds, comprobar que X-Ops está activo y que Action está realmente en Log and drop. Log only solo crea una entrada.
2. En Log viewer > Active threat response, comprobar el módulo, la acción real y los detalles de la conexión para el mismo IoC. Solo una acción de bloqueo acreditada de un módulo anterior, como MDR con Log and drop, detiene las comprobaciones posteriores antes de llegar a X-Ops. NDR Essentials detecta y registra con Log threats, pero no bloquea. Un evento supervisado por NDR, por sí solo, no detiene la comprobación de X-Ops ni explica la ausencia de una entrada de X-Ops en el log.
3. Para una IP de destino, comprobar la regla LAN-to-WAN que se aplica realmente. Para un dominio, comprobar también Application Classification, la política IPS y la ruta del resolver.
4. Para una URL HTTPS completa, buscar el nombre del servidor en Log viewer > SSL/TLS inspection. Si la SSL/TLS rule correspondiente muestra Don't decrypt, X-Ops no puede ver la ruta de la URL. Solo después de identificar esa regla se debe planificar una regla Decrypt lo más limitada posible.
5. Buscar el dominio o la URL en Log viewer > Web filter; comprobar también la columna Category y la vista de detalles. Allí se identifican el ID de la regla de firewall y la política web seleccionada. Si la Web policy responsable muestra Allow, comprobar el orden de las reglas y las políticas. Para un dominio o una URL cuya naturaleza maliciosa se haya confirmado, se puede utilizar un grupo de URLs de alcance muy limitado con una acción de política web Block en una regla LAN-to-WAN adecuada, situada por encima de la regla que hasta entonces permitía el acceso. En la ruta de Web Proxy, comprobar además Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses y Source IP addresses pueden abarcar el indicador o el endpoint que realiza la solicitud. En la ruta DPI, revisar las SSL/TLS Exclusion Lists. No se elimina una excepción de forma indiscriminada; primero se aclaran su finalidad, el proceso de negocio afectado y la autorización.
6. En Protect > Active threat response > Add threat exclusions, buscar tanto el IoC como el host o la red que realiza la solicitud. Estas excepciones se aplican a todos los módulos.

Después de cada corrección se repite el mismo proceso de negocio y se comprueban los logs correspondientes. Si la causa sigue sin estar clara, se guardan la marca temporal, el ID de la regla de firewall, el ID de la regla Web o SSL/TLS y la vista detallada del evento Active Threat Response para el caso de soporte.

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 Fusion (antes 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 entrada de Threat exclusions puede contener como máximo 128 caracteres. 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.

Para una excepción autorizada, abrir Protect > Active threat response > Add threat exclusions y utilizar una de las siguientes alternativas según el tipo de excepción:

• Hosts o redes: En Host and network exclusions, hacer clic en Add new item y seleccionar únicamente los objetos de host o red autorizados.
• Indicador de amenaza: Como alternativa, introducir en Threat exclusions la dirección IP, el dominio o la URL autorizados y añadirlos a la lista con Add. Respetar el límite de 128 caracteres por entrada.

A continuación, guardar con Apply. Volver a abrir la página y comprobar que solo se han guardado las entradas previstas. Add new item o Add por sí solos no sustituyen este paso final de guardado.

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.

Para revertir los cambios, solo se deshace la última modificación realizada: el alcance de la inspección se establece en el valor anterior documentado y se guarda con Apply; una regla o excepción Web/SSL/TLS recién creada se revierte de forma específica, sin modificar las reglas existentes ni otras excepciones. A continuación, se vuelven a comprobar el proceso de negocio, la regla que realmente coincide y los logs. Si se revierte una excepción, la coincidencia correspondiente puede volver a bloquearse. Si una incidencia operativa exige temporalmente Log only, el bloqueo de X-Ops queda suspendido durante ese tiempo; se establecen los responsables y la hora de finalización, y se restablece Log and drop una vez aclarada la causa. Un módulo desactivado no es una forma equivalente de revertir los cambios, ya que también se pierde la inspección que realiza. Una prueba controlada con un feed piloto propio y dedicado en Third-Party Threat Feeds solo acredita la ruta del tráfico de ese feed, no la entrega de la base de datos de X-Ops ni la comprobación de coincidencias con ella.

XML API: tratar por separado la activación, la acción y las excepciones

Para automatizar X-Ops, hay que distinguir tres ajustes independientes en el objeto XML documentado ATP. La referencia de la API de SFOS 22/23 describe:

• ATP/ThreatProtectionStatus: interruptor escalar del módulo con Enable o Disable. Activa o desactiva X-Ops; no es ni la acción ante una coincidencia ni una excepción individual.
• ATP/Policy: acción escalar ante una coincidencia. La tabla de parámetros indica Log Only y Log and Drop, presenta Log Only como valor predeterminado y marca el campo como obligatorio cuando X-Ops está activado. Se trata de una indicación de la tabla de la API, no de una prueba del estado guardado en el propio firewall.
• ATP/InspectContent: alcance escalar de la inspección con all o untrusted. Un alcance de inspección distinto no equivale a Disable ni a un cambio de la acción ante una coincidencia.
• ATP/HostException/Host: lista de cadenas de texto para los hosts o las redes de origen que se deben excluir. El ejemplo contiene HostName; para añadir una entrada se necesita la referencia al objeto autorizado de la propia configuración.
• ATP/ThreatException/Threat: lista independiente de cadenas de texto para los indicadores de destino que se deben excluir. La tabla de la API menciona direcciones IP de destino y dominios. La introducción de URLs en la interfaz descrita anteriormente no demuestra por sí sola que exista una sintaxis de payload XML para URLs.

Por tanto, las dos listas de excepciones están anidadas bajo elementos padre distintos y pueden contener varias entradas. No son interruptores de desactivación global. La tabla de la API indica su efecto en X-Ops, MDR y Third-Party Threat Feeds; por eso siguen siendo importantes la advertencia más amplia sobre el efecto en todos los módulos y las reglas de autorización de la sección sobre excepciones.

Resolver la discrepancia de Policy antes de enviar una solicitud de escritura: El ejemplo XML utiliza el texto alert/drop para Policy, mientras que la tabla de parámetros indica Log Only y Log and Drop. Estas formas no se convierten implícitamente entre sí; tampoco la forma de escribir las etiquetas de la interfaz demuestra que un valor sea válido para la API. Antes de automatizar, se confirman el valor concreto y la estructura de la solicitud mediante la ayuda de la API de la compilación instalada o con Sophos Support. Hasta entonces, el ejemplo no es una solicitud lista para copiar cuyo funcionamiento se haya verificado.

La configuración segura de la XML API se trata por separado. Antes de realizar un cambio autorizado, se guarda una copia del estado del módulo, la acción, el alcance de la inspección y ambas listas de excepciones. Después, se vuelve a leer el estado realmente guardado o se abre la página de configuración y se comparan estas cinco áreas por separado. Si se produce un error, se comprueba primero el estado guardado antes de reintentar; una excepción o un alcance de inspección distinto no deben provocar una desactivación global involuntaria.