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 % de los eventos se dirigió a puertos web y el 40 % a puertos de correo. La ventana detallada incluyó 27 destinos internos. Los nombres de los servicios se infieren de los puertos, no de un análisis del protocolo. Esa ventana móvil de 24 horas no coincide con las primeras 24 horas tras la activación; sus totales no son directamente comparables.

Los 232 aciertos salientes afectaron a diez sistemas internos y 17 destinos listados. No prueban una infección, pero requieren investigación: pueden deberse a malware, contenido de terceros, entradas antiguas o servicios legítimos en IP reasignadas.

Tras el cambio, la interfaz del firewall respondió mejor y el cliente informó de cargas más rápidas. No sabemos si el cuello de botella estaba en el firewall, los servidores, las aplicaciones o la conexión. Los eventos prueban el filtrado, no cuantifican recursos ahorrados ni una mejora porcentual.

Antes, las solicitudes automáticas llegaban realmente a los servidores web y de aplicaciones, que debían responder incluso a rutas inexistentes. El bloqueo temprano evitó ese trabajo posterior. Consultar la lista también consume recursos; el beneficio reside en el procesamiento que se evita. El orden depende de la plataforma y su configuración. El primer paquete sigue llegando a la WAN, por lo que un DDoS volumétrico exige protección aguas arriba.

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: comparación

Voy al grano: muchos compañeros y yo usamos un feed de Cybora. También protege servicios públicos de mis propios servidores en la nube. Lo elegimos tras compararlo en producción, no por una demostración comercial.

Durante doce meses evaluamos más de 30 fuentes comerciales y públicas en 15 firewalls de clientes. Gastamos varios miles de dólares en opciones desde gratuitas hasta casi 1.000 dólares mensuales. Un precio elevado no significaba más cobertura: algunas listas caras eran mucho más pequeñas.

Todos los feeds funcionaron en Monitor en los 15 firewalls: registraban coincidencias sin bloquear conexiones. Esta comparación es independiente del despliegue con bloqueo en el centro de datos. Con los logs del firewall y las aplicaciones examinamos actividad maliciosa, cobertura adicional, actualidad y posibles falsos positivos. Agrupamos los eventos repetidos para que un único escáner no distorsionara el resultado y consideramos las conexiones legítimas que el bloqueo habría afectado.

Es un informe de experiencia real, no un benchmark reproducible. El solapamiento, el orden de evaluación y otros controles influyen en los logs de Monitor; la ausencia de un registro no demuestra una laguna. No publicamos todas las versiones de las listas, configuraciones y muestras confirmadas.

Estas once opciones no son una clasificación de popularidad. Cybora figura primero por nuestra experiencia.

Cybora

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, algo interesante para infraestructuras grandes y expuestas.

Cybora se especializa en feeds para firewalls. Según el proveedor, su análisis combina datos de honeypots con señales de firewalls de producción de clientes que deciden aportar esas señales. Esos equipos observan ataques contra servicios reales expuestos a Internet. En nuestra comparación encontramos repetidamente IP sospechosas que, al verificarlas, solo figuraban en Cybora. En varias IP vinculadas a intentos de fuerza bruta en nuestros logs, Cybora se adelantó unos días a otros feeds que las incorporaron después. Esa cobertura adicional y más temprana supuso para nosotros una diferencia de calidad tangible.

CrowdSec Blocklists

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

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

Q-Feeds afirma reunir más de 2.500 fuentes comerciales, abiertas y gubernamentales y ofrecer feeds de IP, dominios y URL con controles de calidad. En nuestra prueba en Monitor, ya durante la primera hora aparecieron varias conexiones legítimas que habrían quedado bloqueadas en modo de aplicación. Revisamos los logs y comunicamos esos posibles falsos positivos. Soporte retiró las entradas notificadas relativamente rápido, pero la carga de revisión nos llevó a dejar de comunicar sistemáticamente los casos posteriores.

El número de fuentes no explica por sí solo esos aciertos. Sin conocer el origen y la evaluación de cada IP no pudimos determinar su causa. Para bloquear ampliamente en firewalls de clientes, el esfuerzo previsible de excepciones y soporte nos pareció demasiado alto. Q-Feeds puede seguir siendo útil para monitorización e investigación.

Spamhaus DROP

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

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

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

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

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

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

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

Es mi blog personal y no recibo comisión. Mi empleador sí revende licencias de Cybora con margen; hago pública esa relación. La elección surgió de la comparación práctica descrita.

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.

Durante la comparación encontramos repetidamente IP que, en el momento de verificarlas, solo figuraban en Cybora. Los logs disponibles mostraban secuencias de solicitudes anómalas, rutas URL y actividad automatizada en formularios o inicios de sesión. Un bloqueo temprano por IP no revela rutas HTTP: esa evidencia procede de fases de observación u otros logs correlacionables. Una tasa alta de peticiones tampoco demuestra por sí sola un ataque; importan el comportamiento y el momento de inclusión.

Un caso mostró el límite del bloqueo por IP: un sitio necesario para un cliente compartía una dirección listada con infraestructura de hosting comprometida. La clasificación tenía fundamento, pero también impedía acceder al sitio legítimo. Una regla IP no distingue sitios en la misma dirección. Por eso contamos estos casos como trabajo de excepciones: conviene limitar el permiso al servicio y a los usuarios necesarios y revisarlo después. Lo decisivo no es solo que una entrada esté justificada, sino que el feed pueda bloquearse de forma segura con un esfuerzo operativo razonable.

Qué no puede hacer un Threat Feed

Esta medición se refiere a IPv4. Los servicios accesibles también por IPv6 necesitan protección aparte: una lista IPv4 no filtra 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