Configurar y operar con seguridad Sophos Firewall Threat Feeds

Sophos Firewall Threat Feeds importan automáticamente direcciones IP, dominios y URL maliciosos conocidos como indicadores de compromiso (IoC). Para un despliegue seguro, primero se observa el feed en modo Monitor, se revisan los aciertos y los efectos secundarios, y solo entonces se cambia a Block.

Este artículo se centra principalmente en los Third-Party Threat Feeds, como los feeds de Cybora. La función se introdujo con Sophos Firewall v21.

Configurar un Threat Feed

Los Third-Party Threat Feeds requieren el Xstream Protection Bundle, pero no una licencia adicional de Sophos Fusion. El cortafuegos debe poder acceder a la URL del feed mediante DNS y HTTPS.

1. Abrir System services > Log settings.
2. En Active threat response, activar al menos un destino de log compatible. Local reporting almacena logs de eventos localmente para el Log Viewer; estos logs no son informes generados en el propio dispositivo. Como alternativa, utilizar Sophos Fusion (antes Sophos Central) o un servidor syslog como destino de log.
3. Para ver aciertos en tráfico DNAT y WAF entrante, activar también Remote source match (inbound traffic). Esta opción está desactivada de forma predeterminada.
4. Abrir Protect > Active threat response > Third-party threat feeds > Add.
5. Introducir un nombre y una descripción inequívocos, por ejemplo:
   • Piloto: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Feed de producción validado: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. En Indicator type, seleccionar IPv4 address, Domain o URL. Si una fuente proporciona varios tipos, se crea un feed separado para cada uno.
7. Establecer Action en Monitor durante la introducción. Tras un periodo de observación revisado, se puede cambiar a Block.
8. En Position, seleccionar Top para un feed piloto, de modo que otro feed de terceros no oculte su coincidencia. Bottom resulta adecuado para un feed de menor prioridad cuyos solapamientos ya se conocen.
9. En External URL, introducir la dirección adecuada de la lista de feeds de Avanet o del proveedor. La URL debe devolver directamente el archivo de texto plano. Si el endpoint responde, por ejemplo, con HTTP 302, SFOS lo clasifica como Connection error. El archivo contiene un indicador por línea.
10. En Authorization, seleccionar No authentication, API key o Basic authentication según lo indicado por el proveedor. Con API key, introducir por separado el nombre del header o parámetro especificado por el proveedor y el valor secreto; después, seleccionar Header o Query parameters como ubicación de envío. Si el proveedor exige, por ejemplo, el header X-API-Key, este es el nombre, no la clave secreta. Con Basic authentication, introducir el nombre de usuario y la contraseña. Tanto el valor de la API key como la contraseña admiten un máximo de 64 caracteres. Las credenciales no deben aparecer en tickets ni capturas de pantalla.
11. Activar Validate server certificate. Con un certificado público, la CA emisora debe estar disponible en Certificates > Certificate authorities; con una CA privada, primero se importa su certificado.
12. Elegir un Polling interval acorde con el intervalo de actualización del proveedor.
13. Ejecutar Test connection y guardar con Save.

A continuación, comprobar Sync status, Last updated, el número de Threat indicators y la Storage quota disponible. Success confirma una conexión o solicitud HTTP GET correcta, pero no la evaluación completa de la lista ni que el tráfico esperado se detecte o bloquee realmente. El contenido y el efecto deben validarse por separado.

Elegir correctamente el feed y la acción

Indicadores compatibles

Cada configuración de feed evalúa exactamente uno de estos tipos de indicadores:

• IPv4 address: escáneres, botnets, sistemas comprometidos o servidores C2
• Domain: dominios de malware, phishing o mando y control
• URL: rutas maliciosas concretas o enlaces de descarga

El feed debe ser un archivo de texto plano con un indicador por línea. Si el archivo del proveedor contiene varios tipos, SFOS solo tiene en cuenta el Indicator type seleccionado. Por tanto, cada tipo que se quiera utilizar requiere una configuración propia; no es necesario dividir un archivo mixto solo porque contenga varios tipos. Los rangos IP, las direcciones IPv6, las redes, los dominios comodín y las expresiones regulares no se utilizan en Third-Party Threat Feeds como sustitutos de IoC individuales compatibles.

Un ejemplo de formato exclusivamente IPv4 es:

192.0.2.10
198.51.100.20

Estas direcciones de documentación solo muestran el formato, no amenazas reales ni destinos de prueba accesibles. Para la prueba controlada que se describe más adelante, se utiliza en su lugar la dirección IPv4 individual del destino de prueba propio, no su red con un sufijo CIDR. En el caso de Cybora, se utilizan directamente los archivos de feed proporcionados.

SFOS no impone un número fijo de IoC por Third-Party Feed. El tamaño utilizable está limitado por la Storage quota dependiente del modelo. Después de la importación, comprobar conjuntamente la cuota libre, el número de Threat indicators y la descarga correcta.

Una lista grande no es automáticamente buena. El origen, la actualidad, el intervalo de actualización, el riesgo de falsos positivos y los aciertos en el entorno propio son más importantes que la cantidad de entradas. Un feed que no aporta utilidad duradera solo ocupa espacio. La integración no está limitada a una lista fija de proveedores: se puede integrar cualquier Third-Party Feed que cumpla los requisitos de archivo descritos. Sophos menciona, por ejemplo, GreyNoise Intelligence, CrowdSec y Q-Feeds como proveedores; esta mención no sustituye ni la comprobación del endpoint concreto ni un piloto propio en Monitor.

Monitor antes de Block

Monitor registra los aciertos, pero permite el tráfico. Así se observa qué fuentes, destinos y servicios se verían afectados. Block registra y descarta el tráfico coincidente.

Para un feed nuevo resulta útil este procedimiento:

1. Colocar el feed en la parte superior de la lista de Third-Party.
2. Empezar con Monitor.
3. Revisar los aciertos y posibles falsos positivos durante un periodo representativo.
4. Documentar a la persona responsable y el proceso de excepciones.
5. Solo entonces cambiar a Block.

Un feed IPv4 bien seleccionado para servicios muy expuestos puede ponerse en producción antes que un feed de dominios o URL. Estos últimos coinciden con más frecuencia con infraestructuras compartidas, CDN o redirecciones y, por tanto, requieren una revisión especialmente cuidadosa.

Antes de cambiar a Block, registrar el nombre del feed, el número de IoC, la posición y los aciertos observados hasta ese momento. Si el cambio causa una interrupción inesperada, devolver inmediatamente Action del mismo feed a Monitor y volver a probar el tráfico afectado. Un feed defectuoso o incontrolable puede desactivarse temporalmente. Una Threat Exclusion global no es un rollback equivalente, porque también afecta a MDR, NDR y Sophos X-Ops.

Orden y nombres

Active Threat Response procesa los módulos en este orden: MDR, NDR Essentials, Sophos X-Ops y después Third-Party Threat Feeds. Con Log and drop, un acierto en un módulo anterior detiene el resto de la comprobación. Con Log only o Monitor, en cambio, el cortafuegos registra eventos individuales para MDR, X-Ops y Third-Party Threat Feeds.

Dentro de Third-Party Threat Feeds, el cortafuegos evalúa las listas de Block y Monitor por separado y en el orden mostrado. Registra el primer acierto de cada lista y bloquea según el primer acierto de la lista Block. Por ello, los feeds productivos, los feeds piloto y las listas temporales de incidentes deben nombrarse y ordenarse claramente:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Un buen nombre indica el proveedor o la finalidad, el tipo de indicador y la acción. Esto ahorra tiempo al analizar logs y realizar revisiones.

Distinguir los módulos de Threat Feed

En Active threat response aparecen varias funciones con distintas finalidades y licencias:

• Sophos X-Ops Threat Feeds: indicadores propios de Sophos; requieren Network Protection y, para aplicarlos, también Web Protection. Ambos están incluidos en los bundles Standard o Xstream, o se pueden licenciar por separado.
• MDR Threat Feeds: IoC de Sophos MDR; requieren el Xstream Protection Bundle y MDR Essentials o MDR Complete en Sophos Fusion. La guía específica explica la integración con Sophos Fusion, la acción local, Audit ID, Task Queue y la validación del incidente.
• Third-Party Threat Feeds: listas externas de IPv4, dominios o URL; requieren el Xstream Protection Bundle.
• NDR Essentials: analiza el tráfico mediante aprendizaje automático. La tabla de licencias de los módulos indica Xstream Appliance Bundle, mientras que la guía de configuración indica Xstream Protection Bundle. Antes de comprar o implantar, consulte la comparación específica de licencias y fuentes de NDR Essentials y obtenga confirmación del derecho de uso para el firewall concreto.
• NDR Active Threat Intelligence: registra patrones NDR seleccionados por Sophos, requiere el Xstream Protection Bundle y debe activarse en cada regla de cortafuegos mediante Scan with NDR Active threat intelligence. XGS 87/87w y 88/88w no son compatibles.

Para Synchronized Security y el contexto adicional del endpoint en los registros de Active Threat Response, también se requiere una licencia de Intercept X en Sophos Fusion. Esta licencia no es un requisito del Threat Feed en sí, sino de la ampliación del evento con datos del host, el usuario y el proceso.

Synchronized Security es opcional para la comparación con Threat Feeds. Si un Sophos Endpoint administrado envía un Security Heartbeat rojo tras contactar con un servidor malicioso, una regla de Heartbeat correctamente configurada puede bloquear su tráfico; Lateral Movement Protection también puede aislar el endpoint comprometido de la red interna. Esta respuesta del endpoint complementa el feed y sus registros, pero no sustituye la configuración del feed ni la regla de cortafuegos.

Para NDR se utiliza la guía independiente Operar Sophos Firewall NDR y Active Threat Response.

Entender el efecto sobre el tráfico

Tráfico IPv4, de dominios y de URL

El tráfico IPv4 reenviado requiere una regla de cortafuegos que procese el tráfico afectado. El tráfico dirigido al sistema para servicios en Administration > Device access, como WebAdmin, VPN Portal y VPN, se compara por separado con los indicadores de IP de origen y no pasa por una regla de cortafuegos de tránsito.

Las solicitudes DNS a las que responde el propio cortafuegos como servidor DNS se comparan con los IoC de dominio mediante el módulo DNS. Si los clientes utilizan otro servidor DNS, IPS debe ver el tráfico DNS. Por tanto, un feed de dominios por sí solo no demuestra que se esté inspeccionando la ruta real de resolución DNS.

Para el tráfico reenviado, los feeds de dominios y URL requieren además Application Classification o una política IPS en la regla de cortafuegos. Application Classification está activada de forma predeterminada, pero aun así debe comprobarse en la ruta de reglas afectada.

En URL HTTPS completas, el cortafuegos también debe poder ver la ruta. En la ruta Web Proxy se seleccionan Use web proxy instead of DPI engine y Decrypt HTTPS during web proxy filtering en Web filtering dentro de la regla de cortafuegos. En la ruta DPI se desactiva Use web proxy instead of DPI engine y se añade una regla de inspección SSL/TLS adecuada con Action: Decrypt. Sin descifrado, el cortafuegos solo ve el dominio mediante SNI, no la ruta URL completa.

La ruta de inspección correspondiente es el módulo web para Web Proxy o IPS para DPI Engine con reglas de inspección SSL/TLS. Esto se aplica tanto a HTTPS cifrado como descifrado; los IoC que se pueden detectar siguen dependiendo de si solo es visible el dominio o también la ruta URL.

DNAT y WAF a partir de SFOS 22

Desde SFOS 22, el cortafuegos puede comparar la IP de origen del tráfico entrante reenviado para DNAT y WAF con MDR, NDR y Third-Party Threat Feeds. Esto permite detectar escáneres y botnets conocidos antes de que lleguen a los servicios publicados.

Para que estos aciertos aparezcan en el log de Active Threat Response, debe estar activada la opción Remote source match (inbound traffic) en System services > Log settings > Active threat response. Está desactivada de forma predeterminada. Sin este ajuste, el bloqueo puede funcionar aunque los eventos DNAT o WAF esperados no aparezcan en el Log Viewer.

Casos de uso habituales

Los Threat Feeds no solo protegen el tráfico saliente de los clientes. Los servicios de acceso público, en particular, suelen recibir escaneos automatizados en muy poco tiempo.

• DNAT a servidores internos: un feed IPv4 puede bloquear fuentes maliciosas conocidas antes de que lleguen al servidor publicado.
• Publicaciones WAF: los datos de reputación complementan las reglas WAF contra el tráfico de bots, los escaneos de CVE, los sondeos de CMS y el credential stuffing.
• VPN Portal, User Portal y WebAdmin: estos servicios se protegen primero mediante MFA, redes de origen y Device Access y Local Service ACL. Los Threat Feeds reducen además el tráfico de fuentes de ataque conocidas.
• Tráfico saliente de clientes: los feeds de dominios y URL pueden bloquear destinos conocidos de malware, phishing y C2.
• Direcciones WAN muy escaneadas: un buen feed IPv4 reduce el ruido automatizado y alivia la carga del cortafuegos y de los logs.

Los Threat Feeds complementan el hardening básico, pero no lo sustituyen. Los servicios publicados siguen necesitando reglas DNAT o WAF restrictivas, solo los puertos necesarios, limitaciones sensatas por origen o país, IPS o WAF y logging activado. Un feed no justifica reglas Any amplias. El proceso general se describe en el hub de hardening de Sophos Firewall.

Comprobar la sincronización y la operación

Probar por separado la descarga del feed y su efecto

Sync status: Success confirma una conexión o solicitud HTTP GET correcta a la External URL, no que estén presentes todos los indicadores esperados ni que todos se hayan evaluado correctamente. Test connection también es solo una comprobación de conexión. Una comprobación completa requiere tres niveles:

1. Descarga: Test connection, Sync status, Last updated y Storage quota son plausibles.
2. Contenido: en Threat indicators aparece un IoC esperado.
3. Efecto: un tráfico de prueba controlado genera un acierto en Log viewer > Active threat response o en el destino de Sophos Fusion o syslog configurado. Según la coincidencia, se pueden comprobar el nombre del feed, Log/Drop, la dirección de la coincidencia, el origen y el destino o la URL, el protocolo y los puertos.

Para una prueba reproducible, se puede utilizar un feed piloto breve y propio alojado en un servidor HTTPS controlado. Contiene la dirección IPv4 de un destino de prueba también controlado. El feed se mantiene en Monitor, un cliente de laboratorio establece una conexión con el destino de prueba y se revisa la entrada del log. No se deben abrir destinos de malware productivos ni sistemas ajenos para realizar pruebas.

Sincronización y Storage Quota

Estos valores de la vista de feeds son importantes para la operación continua:

• Success, Fetching o Disabled en Sync status
• la marca de tiempo esperada en Last updated
• una cantidad plausible de Threat indicators
• suficiente Storage quota disponible
• una actualización manual correcta mediante Synchronize now

El Summary muestra Active feeds como el número de feeds activos y el total de feeds configurados, Total threat indicators como el número de indicadores IPv4, de dominios y de URL, y Storage quota como el espacio ocupado dentro de la cuota dependiente del modelo. Los appliances más grandes disponen de más espacio que los modelos de sobremesa. Refresh solo actualiza estos contadores visibles. Synchronize now, en Manage, recupera inmediatamente el feed seleccionado. Los IoC individuales se pueden abrir y buscar mediante Threat indicators o a través del número en Total indicators del feed correspondiente. Fetching significa que la descarga está en curso; Disabled significa que el feed está desactivado.

En caso de Authentication error, comprobar primero el nombre de la API key, el valor secreto y la ubicación de envío, o el nombre de usuario y la contraseña. Si estos datos son correctos, investigar también un posible fallo del handshake TLS: comprobar el certificado y la cadena de confianza del servidor del feed y, si es necesario, aclararlo con el proveedor. No todos los errores de autenticación son errores TLS. Validate server certificate debe permanecer activado; la falta de confianza en la CA se resuelve con el certificado de CA correcto, no desactivando la comprobación.

En caso de Connection error, comprobar DNS, el acceso a Internet, el servidor del feed y el estado HTTP; 404, 500 y 302 también son posibles causas. SSL/TLS error es un estado específico para problemas de certificados. En caso de Failed, comprobar que el archivo realmente entregado sea texto plano, contenga un indicador por línea y utilice tipos compatibles adecuados; también puede haber otros errores. Tras corregir el problema, volver a ejecutar Test connection y Synchronize now, comprobar la marca de tiempo y el IoC esperado y, solo entonces, repetir la prueba de tráfico controlada. Si el error persiste, registrar el estado, el momento y los datos del feed depurados y sin secretos para el proveedor o el soporte.

Storage full significa que no hay espacio suficiente para la lista completa. El cortafuegos sigue recuperando el feed según el intervalo de polling configurado, pero solo vuelve a actualizar la lista de IoC almacenada cuando hay espacio disponible. Por tanto, se deben revisar el alcance, la calidad y la prioridad de los feeds en lugar de añadir más listas. En XGS 87/87w, 88/88w y 107/107w solo están disponibles los intervalos de polling 24h, 7d y 30d para Third-Party Threat Feeds. Un feed del proveedor con actualizaciones más frecuentes no elimina esta limitación del dispositivo.

Si no aparecen aciertos

Orden de comprobación recomendado:

1. Feed activado, Sync status: Success y el IoC esperado en Threat indicators
2. una detección MDR, NDR o X-Ops de mayor prioridad para el mismo IoC
3. logging de Active Threat Response y, para DNAT/WAF, Remote source match
4. la regla de cortafuegos correspondiente y su logging
5. para dominios y URL, Application Classification o una política IPS
6. para URL, Web Proxy o DPI y SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions y SSL/TLS Exclusion Lists

Para rastrear un IoC de dominio o URL permitido hasta la regla responsable, abrir Log viewer > Web filter, buscar el IoC en Category o directamente el dominio y abrir la vista detallada. Allí aparecen la Firewall Rule ID y la Web policy seleccionada en esa regla. Si la acción de la política coincidente es Allow, comprobar el orden de las reglas y de la política. Un bloqueo intencionado utiliza un URL Group limitado en una Web Policy de bloqueo asignada a una regla LAN-to-WAN de mayor prioridad. Después, repetir la misma prueba de tráfico.

Para la ruta DPI, abrir además Log viewer > SSL/TLS inspection, buscar la URL en Server name y comprobar Action y SSL/TLS rule. Un IoC de URL requiere Decrypt. Si la coincidencia muestra Don't decrypt, la Rule ID identifica la excepción o regla que omite el descifrado. Añadir un URL Group limitado a una regla Decrypt de mayor prioridad solo después de esta atribución. Desplegar TLS Inspection paso a paso describe el procedimiento controlado.

Si un feed no genera aciertos relevantes durante un periodo de observación representativo, se debe reconsiderar su utilidad. Primero, confirmar que la descarga y la ruta de inspección funcionan, y comprobar si MDR, NDR o X-Ops ya detectan los mismos IoC. Una prueba breve sin aciertos no es motivo para eliminarlo. Si después de estas comprobaciones el feed resulta realmente redundante, antes de eliminarlo se deben documentar el nombre, la URL, el tipo de indicador, la acción, la posición, el intervalo de polling y la ubicación segura de las credenciales. En Protect > Active threat response > Third-party threat feeds, eliminar el feed revisado para liberar espacio. A continuación, comprobar Refresh, Storage quota y Active feeds, y volver a recuperar mediante Synchronize now un feed que antes hubiera fallado con Storage full. Para revertir la eliminación, se vuelve a crear el feed con los valores documentados, inicialmente en Monitor. La desactivación temporal para un rollback es una medida distinta; no se considera una prueba de que se haya liberado espacio.

Tratar falsos positivos

Ante un bloqueo incorrecto, primero se abre la entrada del log y se documentan el nombre del feed, Log/Drop, la dirección de la coincidencia, el origen y el destino o la URL, el protocolo y los puertos. Después se confirma que el tráfico es legítimo, se informa al proveedor del feed sobre el indicador afectado y solo se crea una excepción lo más limitada posible, con motivo, responsable y fecha de revisión.

Una excepción amplia para redes completas no es una solución adecuada. En coincidencias de dominio o URL también pueden intervenir TLS Inspection, una Web Policy, DNS Protection u otra función de seguridad.

Una excepción controlada se crea en Protect > Active threat response > Add threat exclusions. En Host and network exclusions > Add new item, seleccionar objetos de host o red existentes. En Threat exclusions, introducir una sola dirección IP, dominio o URL; cada entrada puede tener como máximo 128 caracteres. Después de Add y Apply, repetir la misma prueba de tráfico y confirmar en el Log Viewer que solo deja de aparecer la detección esperada.

⚠️ Una Threat Exclusion se aplica a todos los módulos de Active Threat Response, no solo al feed que ha causado el falso positivo. Antes de Apply, evaluar el efecto sobre MDR, NDR, Sophos X-Ops y Third-Party Threat Feeds. Documentar la entrada, el motivo, el responsable y la fecha de revisión, y eliminar la exclusión cuando deje de ser necesaria.

Backup y restore

Un backup del cortafuegos contiene la configuración de Third-Party Threat Feeds, pero no las listas descargadas. Después de un restore, el cortafuegos vuelve a descargar las fuentes inmediatamente y aplica la acción configurada. Por tanto, DNS, el acceso a Internet, la validación de certificados y las credenciales deben funcionar justo después de la restauración.

Las configuraciones de Threat Feed no se pueden importar ni exportar por separado; las Threat Exclusions, en cambio, sí. Después de un restore se vuelven a comprobar la descarga del feed, el número de IoC y el efecto sobre el tráfico.

Automatizar ThirdPartyFeed mediante XML

Para automatizar la misma configuración del feed, la interfaz XML utiliza el objeto ThirdPartyFeed. Este configura la obtención y la acción, no los IoC individuales descargados. El acceso, la operación de escritura explícita, la estructura de la solicitud dependiente de la versión y la interpretación segura de la respuesta se explican en Proteger el acceso a la API XML. Los siguientes nombres de campo y límites corresponden a SFOS 22 y 23; por sí solos no constituyen una solicitud de escritura completa. Antes de utilizarlos, confirme la operación Add/Edit concreta y su payload en API help del build instalado. Si la sintaxis no está clara o hay un conflicto entre fuentes, no realice ninguna escritura; aclárelo con soporte.

Antes de realizar un cambio, identifique el feed existente por su Name en WebAdmin y guarde el nombre, el tipo de indicador, la URL, la acción, la activación, la posición y el intervalo de consulta. El nombre identifica la configuración del feed, no al proveedor ni a un IoC individual. Un mismo proveedor puede tener varias configuraciones con nombres distintos para IPv4, dominios y URL. No deduzca del nombre del objeto una semántica de cambio de nombre, upsert o sobrescritura que no se haya verificado.

• Identidad y origen: Name es obligatorio, admite como máximo 63 caracteres y solo permite letras, números, guiones bajos y guiones. Description es opcional y está limitado a 255 caracteres. ExternalURL es obligatorio y está limitado a 1024 caracteres; siga utilizando un feed HTTPS de texto plano accesible directamente, con un indicador por línea.
• Acción y orden: Action exige exactamente block o monitor, que corresponden a Block y Monitor en la UI, respectivamente. monitor registra las coincidencias sin aplicar el bloqueo del feed; block registra y bloquea. Las etiquetas Log only y Log and drop de otros módulos no son valores sustitutivos para este campo. Position admite top o bottom, que corresponden a Top y Bottom. Así se selecciona la posición dentro de Third-Party Feeds, no su prioridad frente a MDR, NDR Essentials o Sophos X-Ops. Las listas de bloqueo y de supervisión permanecen separadas; la primera coincidencia de cada lista es la determinante.
• Tipo de indicador: IndicatorType exige ip, domain o url, que corresponden a IPv4 address, Domain o URL. Aquí, ip no es un tipo IPv6, de red ni de rango. Cree una configuración independiente para cada tipo de indicador deseado.
• Autenticación: Authorization exige noAuthentication, basicAuthentication o apiKey. Solo con Basic Authentication se incluyen Username y Password, cada uno con un máximo de 64 caracteres. Solo con la autenticación mediante clave de API se incluyen Key, Value y AddTo: el nombre de la clave y el valor secreto están separados y cada uno está limitado a 64 caracteres; la ubicación de transmisión es exactamente header o queryParam, que corresponden a Header o Query parameters. Lo que determina la elección es el requisito del proveedor, no un valor predeterminado supuesto. Utilice únicamente los campos correspondientes al método; obtenga los secretos de un almacén de secretos protegido y manténgalos fuera de los archivos XML del repositorio, las URL en tickets, el historial del shell, las capturas de pantalla y los registros. Con los parámetros de consulta, preste especial atención al enmascaramiento de las URL de feeds registradas.
• Validación del certificado: ValidateServerCertificate es obligatorio; el ejemplo del objeto muestra true y false. Para un funcionamiento seguro, active explícitamente la validación y establezca previamente la confianza en la CA correspondiente. Un error de TLS o de autenticación no justifica desactivar la validación.
• Intervalo de consulta: PollingInterval es obligatorio y admite exclusivamente 5m, 15m, 30m, 1h, 6h, 24h, 7d o 30d. Son tokens fijos, no una cantidad de minutos que pueda elegirse libremente. En XGS 87/87w, 88/88w y 107/107w, la selección sigue limitada a 24h, 7d y 30d. Por ejemplo, 1h es adecuado para una actualización horaria del proveedor solo en un modelo que admita ese intervalo.
• Activación y valores predeterminados: Para Enabled, la tabla de parámetros indica 1 y 0, mientras que el ejemplo del objeto muestra true y false. Se trata de una diferencia de representación no resuelta, no de una prueba de que ambas formas sean intercambiables. Antes de intentar una escritura, aclare cuál es la forma válida en el build instalado. La tabla también indica monitor, top, ip y noAuthentication como valores predeterminados de los campos correspondientes. Comprobar el estado real del objeto de destino. Defina explícitamente la acción, la posición, el tipo y la autenticación en lugar de confiar en valores omitidos.

Interpretar de forma segura las respuestas de Add/Edit

Para Add Third-party threat feed y Edit Third-party threat feed están documentadas las siguientes correspondencias. Los valores Message.* son símbolos de mensaje no resueltos, no textos literales de error ni instrucciones suficientes por sí solas para actuar:

En particular, 409 / Message.CPResourceConflict corresponden a Add y 404 / Message.CPRecordNotFound a Edit. No equipare estas correspondencias específicas del objeto con los códigos XML generales ni con un estado de transporte HTTP; lo determinante es la respuesta real y Status Message Information en el build. Después de cada cambio, compare el feed guardado en WebAdmin con los valores previstos y revise el Audit Trail. En caso de error, tiempo de espera agotado o respuesta poco clara, compruebe primero el estado realmente guardado antes de volver a enviar un Add o Edit. No deduzca de un símbolo una repetición automática, un cambio de nombre ni una supuesta corrección del error.

Una respuesta de configuración adecuada no demuestra la obtención del feed, el contenido de los IoC ni el efecto sobre el tráfico. Después, siga comprobando Test connection, Synchronize now, Last updated, Storage quota, un IoC esperado y una prueba controlada de tráfico en Monitor. Cambie a Block solo después de esta comprobación; ante fallos inesperados, restablezca la acción guardada o desactive el feed de forma controlada como se ha descrito anteriormente, en lugar de establecer una Threat Exclusion global como sustituto.

Cybora Threat Feeds para Sophos Firewall

Cybora entrega sus feeds de IPv4, dominios y URL como archivos de texto mediante HTTPS, con un indicador por línea. Su descripción pública indica que combina fuentes OSINT y comunitarias, inteligencia de amenazas comercial, honeypots, sensores y señales de cortafuegos. Por tanto, el formato encaja directamente con la interfaz de terceros de SFOS, aunque un piloto en modo Monitor debe confirmar su utilidad en la red propia.

Cybora se utiliza aquí como ejemplo concreto de proveedor. A cualquier otro proveedor se le aplican los mismos criterios técnicos: tipos de indicadores adecuados, archivo descargable directamente, datos actuales, falsos positivos aceptables, aciertos trazables y un proceso accesible para corregirlos.

Comparar planes

Free (Basic) solo contiene indicadores IPv4 y se actualiza cada 24 horas, por lo que permite validar la entrega y la compatibilidad con SFOS antes de comprar. Standard proporciona IPv4 y un conjunto más reducido de dominios cada seis horas. Premium proporciona IPv4, dominios y URL cada hora, mientras que Ultimate ofrece los mismos tipos cada 15 minutos. Sin embargo, en XGS 87/87w, 88/88w y 107/107w el intervalo mínimo seleccionable en SFOS sigue siendo 24h, con independencia del plan del proveedor.

Además de la cantidad y el precio, importan la actualidad, los tipos de indicadores compatibles, la calidad de las fuentes, el intervalo de actualización, el riesgo de falsos positivos y la trazabilidad en el Log Viewer. El feed adecuado es el que genera aciertos relevantes con efectos secundarios aceptables en el entorno propio.

Avanet Firewall Network

Una parte del feed Premium procede de una red distribuida de cortafuegos. Esta perspectiva ayuda a identificar patrones de ataque que apenas se perciben en un solo cortafuegos.

En los ataques de fuerza bruta distribuidos, cada bot solo realiza unos pocos intentos fallidos de inicio de sesión y a menudo permanece por debajo de un umbral local. La combinación de señales anonimizadas revela direcciones IP que atacan de forma dirigida infraestructuras en varios sistemas. De ahí surge un Threat Intelligence Feed actualizado continuamente para la defensa automática.