🚨 FastFlowIPs
Cómo comenzó todo
Código abierto o no código abierto - esa es la cuestión.
El dilema eterno entre tomar algo ya hecho y construir lo tuyo propio solo se ha vuelto más agudo en la era de las herramientas infinitas de IA. ¿Pero realmente deberías escribir algo tú mismo? No hay una respuesta universal. Sin embargo, si tiras tus miedos a /dev/null, la idea ya no parece tan loca.
Nuestra historia comenzó con una actualización de VyOS en routers de producción a 1.5.x (circinus). Después de este proceso ya de por sí estresante, descubrimos que parte de nuestras reglas de firewall se habían autoborrado silenciosamente. Y la parte divertida - era la misma parte específica en cada router. Así que a regañadientes abrimos VyOS Project Updates, donde nos topamos con esto: FastNetMon-based service ids ddos-protection is removed from rolling and deprecated in LTS releases (T7241):
For quite a while, we had a CLI for configuring FastNetMon — a DDoS detection daemon. However, that integration was never especially deep, and we do not see a path to significant improvement.
The long-term plan is to move FastNetMon to an addon, once we finalize a mechanism for allowing addons to extend the system CLI. As for built-in components, the approach will be “quality over quantity” — it’s better to have a smaller number of integrations that serve a large number of users and play well together, but to provide an option for everyone to install or develop integrations for their own needs.
El problema no era extremadamente urgente o crítico, pero como broker de IPv4 y proveedor de hosting, necesitábamos tal monitoreo. Por lo tanto, decidimos actuar inmediatamente.
Después del ciclo típico - negación, ira, negociación - finalmente aceptamos la pérdida de service ids ddos-protection e intentamos resucitar FastNetMon Community manualmente. Ahí es cuando llegó la depresión. La versión Community se negaba a instalarse por razones que, seamos honestos, todos ya sospechaban. Y nadie tenía prisa por comprar la versión comercial.
El problema no era catastrófico, pero para nosotros como broker de IPv4 y proveedor de hosting, tal monitoreo era esencial. Así que la decisión fue clara: actuar inmediatamente.
FastNetMon: Te amamos, pero…
Nuestra relación con FastNetMon comenzó no hace mucho, pero la herramienta rápidamente ganó nuestros corazones y entregó valor real - aunque consistentemente devoraba alrededor del 30% de nuestra CPU.
La visibilidad del tráfico era perfecta, Grafana brillaba con métricas, y la vida se sentía un poco más pacífica. ¿Y ahora? Ahora estamos mirando dashboards de tráfico vacíos y, por alguna razón, eligiendo voluntariamente la ruta de “hacer la vida más difícil”. Bueno… no voluntariamente. Más bien por la fuerza. Y como siempre, solo empiezas a recordar todas las fallas una vez que pierdes algo.
FastNetMon generalmente cumplió nuestras expectativas - e incluso las superó. Pero a pesar de todos sus beneficios, recopiló una pila masiva de datos absolutamente innecesarios, convirtiendo los dashboards en un carnaval ruidoso de números y gráficos. Y luego estaba esa carga de CPU - no catastrófica, pero lo suficientemente molesta. Así que nunca formamos un “sí” o “no” firme. El alma anhelaba simplicidad y ligereza, no otra suscripción y afinación cada vez que la herramienta estornudaba.
La idea de construir nuestra propia herramienta no llegó instantáneamente. La batalla por FastNetMon continuó - incluso intentamos revivirlo extrayendo un binario viejo de otro servidor. Sí, fue un enfoque un poco cuestionable, pero funcionó: FastNetMon volvió a la vida. Excepto… no había alegría en ello.
Se sentía como si hubiéramos cosido una versión taxidermizada de una mascota hace tiempo fallecida: técnicamente de pie, vagamente reconocible, pero vivir con ello se sentía… inquietante.
Así que estuvimos de acuerdo colectivamente: esto no puede continuar. Y ahí es cuando empezamos a construir nuestro propio protector DDoS impulsado por monitoreo con blackjack y carga mínima de CPU.
Y entonces las cosas escalaron
Así comenzó el desarrollo de nuestra propia herramienta. Las mentes más brillantes del equipo más un par de modelos de IA, por supuesto, se unieron a la sesión de lluvia de ideas, y así es como nació FastFlowIPs. FastFlowIPs es una herramienta de monitoreo de red de alto rendimiento basada en eBPF que rastrea estadísticas de tráfico por IP en tiempo real. Fue diseñada para entornos de producción con sobrecarga mínima.
La idea central es simple: captura el tráfico de red vía eBPF, calcula estadísticas por IP (PPS, Mbps), y puede bloquear automáticamente direcciones IP que excedan umbrales configurables. Las métricas se exportan vía protocolo Graphite y coinciden perfectamente con las expectativas de Grafana. Los dashboards resultantes son limpios, ligeros y rápidos de configurar.
FastFlowIPs ejecuta con un solo one-liner donde especificas -min-ips-pps y -min-flow-pps para exportar solo las métricas más significativas, más la red e interfaz a monitorear. El único requisito must-have es establecer explícitamente -graphite-host y -graphite-port si quieres enviar métricas.
Además, FastFlowIPs está optimizado para redes de alta carga: 75% menos operaciones mutex, 60% más rápido manejo de cadenas comparado con implementaciones típicas.
Un ejemplo de configuración se muestra a continuación:
# Interface and basics
-interface eth0 # Network interface (default: eth0)
-interval 5s # Collection interval
-show-stats # Display periodic tables
-verbose # Detailed logging
# Network filtering
-networks "192.168.1.0/24" # Monitor specific networks only
# IP banning thresholds
-ban-pps-rx 1000 # Ban if receiving > 1000 PPS
-ban-pps-tx 500 # Ban if sending > 500 PPS
-ban-mbps-rx 100 # Ban if receiving > 100 Mbps
-ban-mbps-tx 50 # Ban if sending > 50 Mbps
-ban-time 5m # How long to ban
-ban-script /path/script.sh # Script to execute on ban/unban
# Graphite export
-graphite-host localhost # Graphite server
-graphite-port 32003 # Graphite port
-min-flow-pps 10 # Only export flows > 10 PPS
-min-ips-pps 5 # Only export IPs > 5 PPS No había forma de omitir los Modos de Monitoreo - te permiten ajustar esta herramienta modesta a tu gusto personal:
- Modo silencioso (predeterminado): muestra solo eventos de bloqueo y mensajes de inicio. Perfecto para producción.
- Modo estadísticas (-show-stats): imprime tablas periódicas de tráfico, ordenadas por volumen.
- Modo verbose (-verbose): registro detallado, incluyendo estadísticas de exportación de Graphite.
Y la cereza del pastel - el script de bloqueo, que despiadadamente bloquea cualquier actividad sospechosa que cruce los umbrales definidos:
/path/to/script.sh ban 192.168.1.100 # IP exceeded threshold
/path/to/script.sh unban 192.168.1.100 # Ban expired Un ejemplo simple usando iptables:
#!/bin/bash
case $1 in
ban) iptables -I INPUT -s $2 -j DROP ;;
unban) iptables -D INPUT -s $2 -j DROP 2>/dev/null ;;
esac Pero en cualquier caso, siempre puedes ajustar el script y hacerlo más o menos agresivo - lo que sea que requiera tu infraestructura.
Y unas palabras sobre Graphite y métricas. Un dashboard de Grafana puede construirse en solo unos minutos usando dos tipos de métricas centrales:
Métricas de flujo: **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
Métricas de IP: **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}** Puedes encontrar más detalles sobre FastFlowIPs en el propio repositorio: https://github.com/denisix/fastflowips y siempre puedes apoyar al autor o contribuir a la evolución de esta herramienta pequeña pero ya poderosa.
Arquitectura en 3 párrafos (sin el sufrimiento)
Si describimos la herramienta en lenguaje humano, por dentro es un servicio Go pequeño y ordenado que escucha paquetes NetFlow, los analiza en componentes, y construye estadísticas simples por IP: pps, mbps, entrante/saliente - básicamente, quién está haciendo ruido en la red y por qué. Todas las matemáticas se hacen al vuelo - Go es perfecto para operaciones ligeras pero de alto rendimiento como esta.
Los datos se agregan en pequeñas estructuras en memoria, se ordenan, y se envían periódicamente hacia afuera: ya sea a Graphite/Grafana, o a cualquier otro sumidero que especifiques. El bloqueo de IP vía script externo se implementa a través de umbrales PPS/Mbps y una llamada a BanScript - solo por si alguien repentinamente decide hospedar un pequeño festival local de DDoS.
Lo mejor: es un binario limpio singular sin pila de dependencias y sin el usual “infierno de pequeño negocio open-source”. Las configuraciones se pasan a través de flags, las estadísticas se recopilan directamente, la lógica es transparente. Al final, obtuvimos una herramienta ligera y honesta que hace exactamente lo que necesitamos - sin magia excesiva, sin demonios pesados adjuntos.
Resultados después de un par de días
El proceso de depuración resultó ser mucho más largo y complicado que escribir la herramienta misma. Inicialmente, ni siquiera planeamos establecer valores de umbral para FastFlowIPs, así que varias veces (muchas) Grafana nerviosamente contuvo la respiración bajo el volumen puro de métricas y se negó a mostrárnoslas en absoluto. La leyenda del dashboard contenía tantas direcciones IP que podrías desplazarte durante horas y probablemente nunca llegar al final. Calculamos mal - ¿pero dónde?
La depuración siguió rompiendo cosas, luego estabilizándolas, luego rompiendo nuestro exhausto FastFlowIPs de nuevo, hasta que empezó a llorar silenciosamente en escenarios de casos límite. Había demasiadas métricas, o muy pocas, o ninguna en absoluto. Aparentemente por sobrecarga emocional. Además, el mayor misterio para nosotros resultaron ser las métricas Flows RX/TX, que se intercambiaron ligeramente, algo que era hermosamente visible en tiempo real en los routers VyOS. Las mentes más brillantes de nuestro equipo lucharon con esto, y eventualmente se alcanzó el objetivo: las métricas se estabilizaron, y Grafana se curó de su asma.
Hoy, tenemos métricas ordenadas, limpias e informativas que muestran exactamente el tráfico de red que necesitamos:




Cuándo es tiempo de construir tu propio mini-FastNetMon
Construir tus propias bicicletas es malo. Hasta que llega el momento en que simplemente no puedes avanzar sin una.
Escribir tu propia herramienta absolutamente tiene sentido cuando las soluciones existentes son demasiado pesadas o demasiado inteligentes para tu tarea específica. Cuando no necesitas 100500 características, integraciones con una estación espacial, y dashboards a través de 19 monitores - cuando solo necesitas números, rápido y sin dolores de cabeza.
También deberías considerar desarrollar tu propia solución si la situación demanda flexibilidad: necesitas agregar una métrica al vuelo, incrustar lógica anti-DDoS personalizada, hacer que el monitoreo funcione bien con tu hardware peculiar, o simplemente eludir limitaciones que fueron repentinamente removidas de tu firmware favorito (un cálido saludo a VyOS 1.5).
En resumen, construir tu propia herramienta es sobre control, velocidad, minimalismo, y no depender de componentes que repentinamente desaparecen de los repositorios. Lo principal es recordar la regla dorada: si puede hacerse más simple - hazlo más simple.
Y una regla más: si funciona - no lo toques.
El gran final
Al final, toda esta historia no es sobre tráfico, DDoS, o incluso FastNetMon. Es sobre el hecho de que a veces un equipo simplemente quiere una herramienta que funcione, no se rompa después de una actualización, y no convierta tu vida en una repetición de Sueño de fuga.
No reinventamos la bicicleta - construimos nuestro propio pequeño scooter que se ajusta perfectamente a nuestro camino. Y no hay nada malo en eso. En un mundo donde proyectos masivos de código abierto viven sus propias vidas impredecibles, es bueno tener algo propio - familiar, estable, y maravillosamente aburrido.
Así que si alguna vez has mirado otra herramienta “perfecta pero un poco demasiado perfecta” y pensado: “honestamente, sería más fácil escribirla yo mismo” - podrías estar en el camino correcto. Solo hazlo inteligentemente, con pruebas… y prepárate para sufrir un poco.




