Threat Feeds para firewalls: eficacia, límites y proveedores comparados

Internet está lleno de sistemas que escanean automáticamente las direcciones públicas. Buscan puertos abiertos, páginas de acceso, portales VPN, aplicaciones web conocidas y servicios vulnerables. Algunos pertenecen a investigadores de seguridad y buscadores de infraestructura; otros son bots y atacantes en busca de fallos aprovechables.

Si publicas un servicio mediante una WAF, una regla DNAT, una pasarela de correo o una página de acceso, antes o después aparecerás en esos escaneos. Una IP pública no implica por sí sola una intrusión. Pero cuando hay un servicio que responde, el ruido se convierte en trabajo real para la firewall, el IPS, la WAF, el servidor, la aplicación y los registros.

Como ingeniero de seguridad, este patrón me resulta familiar. En el trabajo vemos a menudo firewalls, WAF y servicios públicos que dedican buena parte de sus recursos al tráfico automatizado. Rara vez se trata de un ataque espectacular: normalmente es una mezcla constante de escaneos de puertos, intentos de acceso, rastreadores y pruebas de exploits.

Hace poco participé en el análisis de un caso cuya escala nos llamó la atención incluso a nosotros. Era una firewall de un centro de datos con un enlace de 10 Gbit/s y, en principio, capacidad suficiente. Sin embargo, parecía estar al límite: el enlace tenía una carga llamativa, la administración respondía lentamente y los servicios expuestos generaban eventos sin cesar.

Analizamos el tráfico por dirección, destino, puerto, intervalo y dirección de origen recurrente. Encontramos muchas peticiones automatizadas a los mismos servicios web, de correo y de acceso. La carga no depende solo del número de peticiones: descartar un paquete, completar una negociación TLS y procesar una petición compleja consumen recursos muy distintos.

Explicamos al cliente que gran parte de esa actividad eran bots y escaneos que volvían una y otra vez a los mismos servicios. Le mostramos qué podía aportar un Threat Feed, sus límites y el coste de la licencia adecuada, unos 350 dólares estadounidenses al año. Tras su aprobación, instalamos la lista en la firewall con unos pocos clics. La configuración llevó solo unos minutos.

Después, la interfaz de administración respondió mucho más rápido. El cliente también nos comunicó que sus sitios y aplicaciones cargaban sensiblemente antes. La mejora se notaba tanto al administrar el equipo como al utilizar los servicios.

Eso hace interesante el caso. Los Threat Feeds no son nuevos para mí, pero muchos administradores interpretan mal su alcance: unos los ven como simples archivos de IP; otros esperan que sustituyan al IPS, la WAF o el EDR. Importan el origen y la antigüedad de los indicadores, la eliminación de falsos positivos y el punto del flujo en que se aplica el bloqueo. Por eso quiero explicar la técnica además de mostrar las cifras.

El resultado en cifras

Los datos proceden de una firewall en producción. El feed de IP comenzó a aplicarse el 1 de septiembre de 2026 a las 10:01:05. El primer acierto llegó pocos segundos después. Hasta el 2 de septiembre a las 20:30 CEST se registraron 516.959 eventos de bloqueo.

En todo el periodo hubo una media de 249,9 intervenciones por minuto: 4,17 por segundo, o una cada 0,24 segundos. El minuto más activo sumó 775 eventos. El máximo fue de 107 eventos en un segundo y se repitió en dos segundos consecutivos.

Hablo deliberadamente de eventos bloqueados, aciertos o intentos de conexión. No son 516.959 ataques independientes dirigidos manualmente. Un escáner puede probar repetidamente el mismo servicio, un bot puede recorrer varios puertos y una conexión fallida puede generar paquetes posteriores.

¿Quién llamaba a la puerta?

En las 34 horas y 29 minutos de medición, 516.727 eventos fueron entrantes y solo 232 correspondieron a conexiones salientes impedidas. En este entorno, el 99,955 % de la actividad del feed afectó a orígenes de Internet.

Aparecieron 10.518 IP distintas incluidas en la lista. Esta contenía entonces 220.000 indicadores IPv4, por lo que aproximadamente un 4,8 % de la lista fue relevante en una sola firewall en unas 34 horas. La dirección más activa produjo 4.141 eventos; las diez primeras, unos 31.500 en conjunto; 767 direcciones aparecieron una sola vez.

Ese 4,8 % compara tamaños, no mide una tasa de detección. La lista cambia con cada actualización y el contador no incluye atacantes desconocidos ni direcciones ausentes del feed.

El análisis de puertos cubre una ventana móvil de 24 horas con aproximadamente 369.000 eventos detallados:

Alrededor del 56 % se dirigió a puertos web y el 40 % a puertos de correo, acorde con los servicios publicados. En esa ventana se alcanzaron 27 sistemas internos. Los nombres de servicio se infieren de los puertos de destino; no se verificaron mediante análisis del protocolo. Tampoco debe compararse esta ventana móvil con las primeras 24 horas tras la activación.

Los 232 aciertos salientes merecen atención: diez sistemas internos intentaron contactar con 17 destinos incluidos en la lista. Eso no demuestra una infección. También podría deberse a contenido de terceros, un indicador obsoleto o una IP reasignada a un servicio legítimo.

La mayor agilidad de la interfaz y los tiempos de carga comunicados por el cliente son observaciones posteriores al cambio. No identificamos de manera aislada el cuello de botella previo: podía estar en la firewall, los servidores web, las aplicaciones o la conexión. Los eventos acreditan el filtrado, pero no miden tiempos de carga ni ahorro de CPU. No permiten calcular una mejora porcentual del rendimiento.

Antes del cambio, las peticiones automatizadas llegaban efectivamente a los servidores web y de aplicaciones. Estos tenían que procesarlas y, por ejemplo, devolver errores para rutas inexistentes. El bloqueo temprano evitó ese trabajo posterior para las peticiones afectadas. La firewall también pudo descartarlas antes de reenviarlas y seguir procesándolas. La consulta de la lista consume recursos; la descarga viene del trabajo posterior que se evita.

El orden y el alcance de la comprobación dependen de la plataforma y la configuración, especialmente con WAF y servicios alojados en la propia firewall. El primer paquete sigue llegando a la interfaz WAN. Un descarte local puede evitar respuestas y tráfico posterior, pero no sustituye a una protección previa contra DDoS volumétrico.

Qué hace realmente un Threat Feed

Un feed sencillo suele ser un archivo de texto descargado por HTTPS. Muchos proveedores ofrecen IP, dominios y URL. Nosotros utilizamos principalmente IP porque aportan el efecto más relevante en nuestros casos de uso de firewall al bloquearlas temprano. La firewall actualiza los indicadores periódicamente y compara con ellos el tráfico aplicable. Según la configuración, registra o bloquea los aciertos.

La calidad depende de cómo se comprueban y mantienen las entradas:

• ¿El comportamiento era malicioso o solo inusual?
• ¿Cuándo se observó?
• ¿Lo corroboran fuentes independientes?
• ¿Cuándo se retira un indicador obsoleto?

Una lista larga no equivale a buena inteligencia. Importan la actualidad, la precisión y la limpieza. Las IP dinámicas de nube y alojamiento pueden volver a tener un uso legítimo. Una lista demasiado pequeña y conservadora reduce falsos positivos, pero quizá cubra poco ruido cotidiano.

Threat Feeds para firewalls

No voy a ocultar hasta el final el proveedor que usamos muchos compañeros y yo: Cybora. También lo uso para proteger servicios públicos en mis propios servidores cloud. La elección proviene de una comparación en producción, no de una demostración comercial.

Durante doce meses probamos más de 30 proveedores y fuentes públicas en 15 firewalls de clientes. Contratamos suscripciones, gastamos varios miles de dólares y examinamos desde feeds comunitarios gratuitos hasta paquetes cercanos a los 1.000 dólares mensuales. Algunos productos caros tenían listas mucho más pequeñas y justificaban su precio por su presunta actualidad y precisión.

Instalamos los feeds examinados en las 15 firewalls y los pusimos en modo Monitor: debían registrar aciertos sin bloquear. Investigamos las coincidencias en el tráfico real y los servicios afectados. Esa comparación prolongada es distinta del despliegue con bloqueo del centro de datos descrito antes.

Comparamos las fuentes detectadas y estudiamos actividad sospechosa y posibles falsos positivos con los registros disponibles de firewalls y aplicaciones. Valoramos la actividad maliciosa confirmada, la cobertura adicional, la actualidad y el coste operativo de las excepciones. El tamaño y el precio por sí solos no demostraban calidad. Agrupamos eventos repetidos para evitar que un escáner muy activo dominara el resultado y examinamos también conexiones legítimas que la lista habría impedido.

Fue una comparación en la operación diaria, no una prueba de laboratorio estandarizada. El orden de evaluación, las coincidencias entre listas y otras defensas activas pueden afectar a lo registrado. La ausencia de un evento no demuestra una laguna. Un benchmark reproducible necesitaría instantáneas fechadas de los feeds, configuración de evaluación y casos positivos y negativos confirmados; aquí no publicamos ese conjunto completo.

Estas once opciones son una selección editorial para firewalls, no una clasificación por popularidad ni una tabla de rendimiento. Combinan experiencia práctica y documentación. AbuseIPDB e IPsum se incluyen como alternativas sin atribuirles pruebas propias. Cybora va primero por nuestra experiencia; el resto no sigue una clasificación medida. Comprobamos los datos de Q-Feeds el 28 de septiembre de 2026 y los demás datos de producto el 8 de septiembre de 2026.

Cybora nos ofreció el mejor equilibrio entre cobertura, actualidad, aciertos útiles, carga de falsos positivos, integración, soporte y precio. Sus planes de entrada tienen un precio razonable. Ultimate actualiza cada 15 minutos, interesante para infraestructuras grandes y expuestas. Ese intervalo no indica cuánto tarda antes la detección y evaluación; también se suman la descarga y la importación. En los datos aparecen dos respuestas HTTP 429: la lista local siguió activa y la siguiente descarga recuperó la actualización. Hay que vigilar la antigüedad del feed y los fallos de actualización.

CrowdSec Blocklists combina un motor de seguridad de código abierto, señales comunitarias y listas curadas exportables a firewalls. Su telemetría productiva y sus listas especializadas son útiles; un feed para atacantes de CMS, proxies o un CVE concreto no es automáticamente una protección general del perímetro.

GreyNoise ofrece listas IP basadas en consultas GNQL que pueden aplicarse en firewalls. Permiten seleccionar actividad reciente o relacionada con ciertos CVE. El equipo debe definir y revisar las consultas y disponer de los módulos adecuados. Reducir GreyNoise a enriquecimiento de logs subestimaría su oferta.

Q-Feeds afirma curar indicadores de más de 2.500 fuentes comerciales, públicas y gubernamentales para feeds de IP, dominios y URL. Describe controles de calidad y eliminación de falsos positivos. Nuestra experiencia fue menos favorable: durante la primera hora de un despliegue con bloqueo se impidieron varias conexiones legítimas. Investigamos las afectadas y clasificamos los casos revisados como falsos positivos. El soporte retiró las entradas comunicadas con relativa rapidez. Aun así, el esfuerzo de investigación y reporte nos llevó a dejar de comunicar sistemáticamente casos posteriores.

El número de fuentes no explica por sí solo esos errores. Sin conocer el origen, el motivo y la reevaluación de cada IP, no pudimos establecer la causa. Para extender un feed de bloqueo a muchas firewalls de clientes, el volumen de excepciones y soporte observado nos pareció excesivo. Como fuente de monitorización o investigación podría aportar otro valor; esta valoración se refiere al bloqueo en nuestros entornos.

Spamhaus DROP es una lista conservadora de redes especialmente peligrosas para filtrado perimetral o decisiones de enrutamiento. Su umbral alto aporta fiabilidad, pero no pretende cubrir todos los escáneres efímeros.

ThreatFox de abuse.ch y Spamhaus se centra en indicadores de malware, incluida infraestructura de mando y control. Sirve bien para detección y threat hunting; es más específica que un feed general contra escaneos, fuerza bruta y exploits automatizados.

URLhaus de abuse.ch recopila URL que distribuyen malware. Resulta útil en filtros DNS, proxies, pasarelas web y herramientas de análisis, pero es una pieza especializada para bloqueo IP perimetral. Su API requiere Auth-Key; el acceso comunitario no supone uso comercial ilimitado.

DShield publica una lista recomendada compacta a partir de logs de firewall enviados. Otras colecciones de DShield sirven sobre todo para investigación y no deben importarse sin filtros como bloqueos.

FireHOL IP Lists agrega y observa listas públicas. Permite comparar tamaño, edad, actualizaciones y solapamientos, pero hereda debilidades de sus fuentes; una entrada redistribuida puede persistir demasiado tiempo.

AbuseIPDB ofrece reputación basada en reportes y una lista de texto con umbral de confianza ajustable. Un score alto no demuestra que toda conexión actual sea maliciosa. Importan la edad de los reportes, las IP compartidas y los límites de consulta del plan.

IPsum agrega diariamente más de 30 listas y permite fijar umbrales de coincidencia. Tres listas coincidentes no equivalen necesariamente a tres observaciones independientes si unas copian a otras. Su actualización diaria limita la reacción; es una fuente suplementaria transparente, no telemetría propia.

Gratis no significa malo ni comercial significa bueno. Muchas fuentes públicas destacan en su especialidad. Para un bloqueo general directo en el perímetro, nuestra experiencia favorece un feed curado continuamente, acompañado de fuentes especializadas cuando corresponda.

Por qué Cybora quedó primero en nuestra comparación

Por transparencia: este es mi blog personal y no recibo comisiones. Mi empleador sí revende Cybora y obtiene licencias con descuento para venderlas con margen. Esa relación comercial es contexto necesario para valorar mi recomendación. Nuestra elección se basó en la experiencia descrita, no en las condiciones de reventa.

En el caso analizado usamos primero Premium, por 349 dólares al año y actualizaciones cada hora. Según la descripción pública de Cybora, combina OSINT, fuentes comerciales, honeypots, sensores y telemetría real de firewalls. Valora actualidad, confianza y coincidencias, elimina duplicados y aplica exclusiones antes de publicar una lista HTTPS. En aquel momento Premium incluía 220.000 IP IPv4, 45.000 dominios y 25.000 URL. En la firewall medida, las IP estaban en Block y los dominios inicialmente en Monitor.

Una semana después el cliente pasó a Ultimate: más de 300.000 IPv4 y más de 100.000 dominios y URL de cada tipo, con actualización cada 15 minutos. El cliente informó de nuevas mejoras de rendimiento, pero el periodo medido terminó antes del cambio y no demuestra una ganancia adicional debida a Ultimate. El plan superior seguía costando mucho menos que una appliance mayor con su licencia. No todos necesitan el plan máximo: aquí la exposición de muchos servicios web, de correo y acceso, el enlace rápido y los seis dígitos de aciertos diarios justificaban estudiarlo.

Los datos de redes productivas complementan los sensores artificiales con otros servicios y perfiles de tráfico; no garantizan superioridad y otros proveedores también los utilizan. Nos interesaron más los orígenes adicionales detectados y su comportamiento. Encontramos repetidamente IP presentes entonces solo en Cybora; en logs de firewall y aplicación observamos secuencias de peticiones sospechosas, rutas URL inusuales e intentos automatizados de login o formularios. Un descarte IP temprano no revela rutas HTTP; esos indicios deben proceder de fases de observación o registros correlacionables. Una tasa alta tampoco prueba por sí sola un ataque: importan el comportamiento y el momento de inclusión en la lista.

Un caso de soporte mostró otro límite: una web necesaria quedó inaccesible porque compartía IP de alojamiento con infraestructura comprometida. La clasificación de la IP estaba justificada, pero perjudicó a una web legítima. Una regla IP no distingue sitios alojados en la misma dirección. Por eso contamos estos casos como falsos positivos operativos o carga de excepciones. Una excepción debería limitar usuarios y servicio cuando sea posible, revisarse después y no desbloquear toda la IP sin evaluar el resto del contenido. Una única interacción con soporte tampoco permite juzgar sus tiempos habituales.

El resultado técnico del procesamiento es sencillo: una dirección HTTPS y una lista, configurables en minutos en plataformas compatibles. Aplicar bloqueos responsablemente exige antes revisar el tráfico propio.

STIX y TAXII no son una lista de bloqueo

STIX (Structured Threat Information Expression) es un modelo estructurado que describe IP, malware, campañas, actores, técnicas, observaciones, periodos, confianza y sus relaciones. Permite expresar el contexto y el motivo de un indicador. TAXII (Trusted Automated Exchange of Intelligence Information) es el protocolo HTTPS para intercambiar esos datos: STIX define el contenido y TAXII su transporte o API.

Ese contexto sirve a plataformas de inteligencia, SIEM y SOC. Para cotejar IP rápidamente, una firewall suele necesitar solo un conjunto de direcciones derivado de esos datos. Lo descarga periódicamente y compara con su copia local; no interpreta STIX/TAXII por cada paquete. Una lista TXT ofrece menos contexto, pero puede derivarse de inteligencia estructurada para aplicar controles perimetrales.

Qué no puede hacer un Threat Feed

Este ejemplo y la cobertura IP evaluada son IPv4. Es el foco de los entornos que gestiono, pero no dice nada sobre cobertura IPv6. Si publicas también servicios por IPv6, debes comprobar el filtrado por separado: una lista IPv4 no cubre esas conexiones.

Un feed bloquea indicadores conocidos. No reconoce automáticamente un atacante nuevo en una IP limpia, un cliente malicioso en una nube legítima, un ataque detrás de una CDN ni fallos de tu propia aplicación. Las IP cambian, aparecen dominios nuevos y los sistemas comprometidos se limpian o reasignan. El feed no sustituye parches, MFA, IPS, WAF, EDR, buenas reglas ni registros. Añade una decisión temprana que puede evitar mucho ruido en DNAT, WAF, VPN y correo antes de controles más costosos.

Primero observaría cualquier feed nuevo, prepararía exclusiones, comprobaría intervalos de actualización y límites de capacidad y definiría un proceso para falsos positivos. La confianza se gana con el tráfico propio.

Mi conclusión

La medición no demuestra que una licencia sustituya un enlace de 10 Gbit/s ni una firewall mayor. Sí muestra que esta firewall detuvo temprano más de medio millón de eventos de conexión no deseados y conocidos en algo más de 34 horas. Para el cliente importó la mejora diaria: administración más fluida y, según informó, sitios y aplicaciones más rápidos. No se aisló el cuello de botella previo; los registros acreditan el filtrado, no una mejora porcentual.

Cybora fue el feed general que mejor funcionó para este uso en nuestra comparación de doce meses. CrowdSec, GreyNoise, Spamhaus, abuse.ch y otros siguen siendo valiosos, incluso superiores en sus especialidades. La pregunta útil es qué indicadores son actuales, precisos y seguros de aplicar a tus servicios expuestos.

Hasta la próxima,
Joe

Preguntas frecuentes