NetFlow y detección de DDoS: visibilidad real y mitigación automática en tu propia red

El problema no es el ancho de banda: es no saber qué está pasando

Un ataque DDoS no avisa. Un día tu servicio empieza a degradarse, los tiempos de respuesta se disparan y, cuando te das cuenta de qué está ocurriendo, ya llevas varios minutos fuera. Si dependes de ese tiempo de actividad para facturar —comercio electrónico, SaaS, infraestructura compartida— cada minuto tiene un coste concreto que no hace falta inventarse: pérdida de ventas, tickets de soporte acumulados y, en el peor caso, penalizaciones de SLA.

La raíz del problema rara vez es falta de capacidad de red. Es falta de visibilidad. Sin saber con precisión qué tráfico entra, de dónde viene y hacia qué servicios se dirige, cualquier respuesta es manual, lenta y propensa a errores. Ahí es donde entran los protocolos de análisis de flujos: NetFlow, IPFIX y sFlow.

Qué es un flujo de red y por qué importa más que un simple contador de tráfico

Un router o switch moderno puede exportar registros de flujo: resúmenes de cada conversación de red que pasa por él. No el contenido del tráfico —eso sería análisis de paquetes, mucho más costoso— sino los metadatos: IP origen y destino, puertos, protocolo, volumen, duración. Con millones de esos registros acumulados puedes responder preguntas que un simple gráfico de tráfico no puede: ¿qué host de tu red genera más salida? ¿Qué ASN está enviando un volumen anómalo de paquetes UDP en el puerto 123? ¿Cuándo empezó exactamente esta anomalía?

NetFlow es el protocolo original de Cisco, ampliamente soportado. IPFIX es su evolución estandarizada. sFlow es una alternativa por muestreo estadístico, más ligera en CPU pero con menor granularidad. La mayoría de equipos de red —MikroTik, Juniper, Cisco, incluso algunos switches gestionados de gama media— pueden exportar alguno de estos formatos con una configuración mínima.

De los datos de flujo a la mitigación automática: la cadena completa

Recopilar flujos es el primer paso. El valor real está en lo que haces con ellos a continuación. La cadena de respuesta ante un ataque tiene varios eslabones:

• Recolección: un colector recibe los registros de flujo de tus exportadores de red.
• Análisis: se comparan los patrones actuales contra una baseline de tráfico normal, identificando anomalías por volumen, tipo de tráfico o distribución geográfica.
• Detección: cuando un patrón supera los umbrales, se genera una alerta. No después de cinco minutos: en segundos.
• Mitigación: se actúa automáticamente sobre el plano de control de la red. Las dos opciones principales son RTBH (Remotely Triggered Black Hole, que descarta todo el tráfico hacia una IP atacada) y FlowSpec (que permite reglas más quirúrgicas: bloquear solo un tipo de tráfico desde ciertos orígenes, sin desconectar al cliente por completo).

La diferencia entre detectar y bloquear manualmente —con un tiempo típico de varios minutos si hay alguien mirando— y hacerlo de forma automática en menos de diez segundos es la diferencia entre una interrupción gestionada y una caída en producción con impacto real.

Las alternativas open-source: qué ofrecen y dónde se quedan cortas

La comunidad técnica tiene razón en señalar que herramientas como Telegraf, Grafana o la combinación FastNetMon + Akvorado pueden cubrir parte de este terreno. Telegraf puede recibir registros NetFlow y almacenarlos en cualquier base de datos de series temporales. Grafana puede visualizarlos y lanzar alertas vía webhook. FastNetMon lleva años siendo la referencia para detección de DDoS en entornos con BGP.

El argumento es válido, especialmente para equipos con experiencia operativa en ese stack. Pero hay matices importantes:

• Configurar Telegraf + InfluxDB + Grafana + FastNetMon + Akvorado con integración BGP funcional no es una tarde de trabajo. Son días, posiblemente semanas, dependiendo de tu infraestructura.
• Los exportadores de red reales se comportan de forma inesperada. Algunos equipos MikroTik envían el sampling rate con el byte order invertido. Ciertos dispositivos Juniper meten un único packet sample por datagrama. Algunos firewalls reportan la misma interfaz en ambas direcciones cuando hay NAT activo. Cada uno de esos casos necesita handling específico o los datos que ves en el dashboard no reflejan la realidad.
• El almacenamiento de flujos con garantía de exactamente-una-vez (sin duplicados, sin huecos) es un problema de ingeniería no trivial, especialmente cuando actualizas el sistema sin parar el colector.
• Un bug en la automatización BGP no produce una alerta de Grafana: produce que un grupo de clientes quede sin servicio. La fiabilidad del ciclo de mitigación tiene un coste de desarrollo que no es visible desde fuera.

Dicho esto, si ya tienes ese stack corriendo y un equipo que lo mantiene, no tiene sentido reemplazarlo. Las herramientas open-source son una opción legítima con sus propios trade-offs.

Heimnull: qué es y qué propone diferente

Heimnull es una solución self-hosted de análisis de flujos y mitigación de DDoS que empaqueta toda esa cadena en un único stack desplegable con docker compose up. Apuntas los exportadores NetFlow, IPFIX o sFlow de tus routers hacia él, y obtienes visibilidad de tráfico por host, aplicación, ASN e interfaz, tanto en tiempo real como retroactivamente durante meses.

Cuando detecta un ataque, puede actuar automáticamente vía BGP: empezar con FlowSpec para una respuesta quirúrgica y escalar a RTBH si el ataque supera lo que FlowSpec puede filtrar eficientemente. Todo sin intervención manual. El propio equipo describe un caso concreto: identificar que una IP de cliente está recibiendo una reflexión NTP y enviar la regla FlowSpec a los routers en menos de diez segundos.

Algunos puntos relevantes para evaluar si encaja en tu contexto:

• Datos en tu infraestructura: al ser completamente self-hosted, los registros de flujo nunca salen de tu red. Esto no es un detalle menor desde la perspectiva del RGPD ni desde la de la directiva NIS2, que sitúa la detección de anomalías de tráfico como parte del deber de diligencia para operadores de servicios esenciales.
• Escalabilidad real: el límite no es el ancho de banda en sí sino los flow records per second (FRPS), determinados por el sampling rate que configures en tus exportadores. Redes con tráfico pico de 20-30 Gbps pueden generar menos de 2.000 FRPS con un sampling rate razonable. El sistema ha sido probado en hardware convencional hasta 300.000 FRPS sin pérdida de registros.
• Modelo de licencia: cada instalación comienza con una prueba de 30 días de todas las funciones. Después continúa operativa en modo gratuito hasta 500 Mb/s con análisis completo, sin mitigación automática. Para entornos con más tráfico o con mitigación BGP activa, el precio se estructura por capacidad.

La comparativa de costes que nadie hace explícita

Cuando un usuario técnico cuestiona el modelo de precios, el argumento más honesto no es comparar con Grafana: es comparar con las alternativas reales para tu caso de uso. Un servicio de scrubbing externo para un ancho de banda de varios gigabits tiene un coste mensual recurrente que, según el proveedor y el nivel de servicio, puede superar fácilmente lo que cuesta una solución self-hosted al año. Un appliance DDoS dedicado tiene un coste de entrada más elevado aún y requiere mantenimiento de hardware.

La variable que más se omite en esa comparativa es el coste de la indisponibilidad. Una caída de varias horas en un servicio SaaS o e-commerce tiene un impacto que depende del negocio concreto, pero raramente es despreciable. Si tu MTTR actual frente a un ataque DDoS es de 15-30 minutos porque alguien tiene que detectarlo, escalar y actuar manualmente, reducirlo a menos de un minuto con mitigación automática cambia el cálculo de forma significativa.

Tres preguntas técnicas que conviene responder antes de desplegar

¿Cómo se integra con un SIEM existente?

Si ya tienes un SIEM como Wazuh o Splunk en tu infraestructura, la integración natural es vía alertas. Heimnull genera eventos cuando detecta anomalías; esos eventos pueden enviarse como webhooks o logs estructurados que el SIEM ingesta y correlaciona con otras fuentes —logs de firewall, autenticaciones, eventos de sistema—. La correlación es especialmente útil para distinguir un DDoS externo de una anomalía interna o un escaneo de reconocimiento que precede a un ataque más sofisticado. No es una integración nativa plug-and-play en todos los casos, pero es el enfoque habitual en entornos con stacks de seguridad heterogéneos.

¿Qué hardware necesita una instalación para 5-10 Gbps de tráfico?

Como se apuntaba antes, el dimensionamiento depende de los FRPS, no del tráfico bruto. Con un sampling rate de 1:1000 en un enlace de 10 Gbps, los registros por segundo son manejables en un servidor con recursos moderados. El propio equipo de Heimnull no publica una tabla de requisitos mínimos públicamente, pero el hecho de que sea un stack Docker implica que puede correr en hardware de servidor convencional, incluso en una máquina virtual con suficiente disco para retención histórica. Para producción real, una instancia dedicada con almacenamiento SSD es la recomendación lógica; la retención de meses de datos de flujo consume espacio de forma proporcional al volumen de registros.

¿Cómo se calibran los baselines para evitar falsos positivos?

Este es el problema más difícil de cualquier sistema de detección de anomalías. Una red con tráfico muy variable —picos en fechas comerciales, campañas de marketing, migraciones de datos programadas— genera patrones que un umbral estático interpreta como ataques. Los sistemas modernos de detección de flujos aprenden una baseline dinámica por ventanas temporales: no es el mismo tráfico normal un martes a las 3 de la mañana que un viernes a las 20:00. La recomendación práctica es dejar el sistema en modo observación durante al menos dos semanas antes de activar la mitigación automática, para que la baseline capture los ciclos habituales de tu red. Los falsos positivos al inicio no son un fallo del sistema: son la señal de que el aprendizaje aún no tiene suficiente historia.

Un caso de uso que ilustra el valor real: el homelab con BGP

Hay un perfil de usuario que resume bien el problema: alguien con infraestructura propia seria —varios switches de core, backbone de alta velocidad, BGP para ruteo con múltiples uplinks, VLANs segmentadas— que actualmente gestiona los ataques con scripts Python bajo cron, al estilo fail2ban. Reciben sondeos constantes desde rangos de direcciones variados y quieren saber, con precisión, qué es un ataque real, qué es una exploración de reconocimiento y qué podría ser un error de configuración propio.

Para ese perfil, la visibilidad de flujos no es un lujo: es la diferencia entre operar con información y operar con intuición. Y la automatización BGP no es comodidad: es la única forma de responder a la velocidad a la que actúan los ataques modernos.

Lo que esto significa para una infraestructura propia

La detección y mitigación de DDoS solía ser territorio exclusivo de grandes operadores con equipos y presupuestos dedicados. Los protocolos de análisis de flujos —con más de veinte años de historia— y las herramientas que los aprovechan, tanto open-source como productos integrados, han bajado ese umbral considerablemente.

La pregunta ya no es si una infraestructura de tamaño medio puede permitirse visibilidad de red. Es cuánto cuesta la alternativa: operar sin ella.

Si gestionas conectividad, servicios en producción o infraestructura compartida y todavía dependes de que alguien note manualmente que algo va mal, es buen momento para revisar cómo funciona hoy tu cadena de detección y qué pasaría si un ataque llegara fuera del horario habitual de trabajo.