devinblack001/ddos-reduction-systemGateway adaptativo de mitigación DDoS de Capa 4 en dos etapas que utiliza análisis de tráfico conductual, clasificación con Random Forest y aplicación a nivel de kernel mediante ipset/iptables.
First Line Of Defense
Una puerta de enlace adaptativa de mitigación de DDoS volumétrico de Capa 4 en dos etapas.
Autor: Abdullah Armiyao
Proyecto: Marco Adaptativo de Dos Etapas para la Mitigación de DDoS Volumétrico de Capa 4 en Tiempo Casi Real Mediante Análisis de Tráfico Conductual
La mayoría de la mitigación de DDoS utiliza umbrales fijos: bloquear cualquier cosa que envíe más de un número codificado de forma rígida de paquetes por segundo. Eso falla en ambas direcciones. El tráfico legítimo se dispara durante un período de alta actividad y los usuarios reales quedan bloqueados, o un atacante se mantiene justo por debajo de la línea y logra pasar.
FLOD aprende cómo se ve tu tráfico normal y mueve sus propios límites de detección para ajustarse. Distingue una avalancha de DDoS de una multitud repentina, un pico legítimo, sin que nadie ajuste un umbral a mano.
Se sitúa en línea sobre una puerta de enlace entre la fuente del tráfico y los hosts que se protegen, y descarta o limita las fuentes infractoras en el kernel.
El panel nombra las direcciones que bloqueó como atacantes, de modo que alguien que no conoce de antemano la disposición de la red puede distinguir qué emisores fueron hostiles. Las direcciones limitadas se listan por separado, porque la limitación también se usa como precaución y se aplica a grupos enteros a la vez.
La Etapa 1 es un sensor en Rust sobre la ruta de los paquetes. Captura cada paquete dirigido a un host protegido, calcula la tasa y la diversidad de fuentes en ventanas cortas, y las compara con una línea base que mantiene por sí mismo. Solo hace aritmética, así que no interfiere con el tráfico.
La Etapa 2 es un servicio en Python. Recibe un resumen de la Etapa 1 una vez por ventana, lo clasifica con un Random Forest, y emite la aplicación a nivel de kernel mediante ipset e iptables. Un Isolation Forest se ejecuta junto a él en cada ventana, marcando tráfico distinto a cualquier cosa que cualquiera de los modelos haya aprendido, mostrado como un estado Anomalous separado en lugar de impulsar la aplicación. La Etapa 2 también sirve el panel web.
Ambas están conectadas por un socket de dominio Unix.
FLOD funciona sobre inundaciones volumétricas de Capa 4 visibles solo a partir de las cabeceras de los paquetes: tasa, entropía de IP de origen, mezcla de protocolos, y cuán concentrado está el tráfico en su fuente más activa. En la práctica, eso significa inundaciones que son tanto de alto volumen como concentradas, llegando desde un conjunto acotado de direcciones reales.
Una cosa está explícitamente fuera de alcance, y una está parcialmente abordada:
Ataques de capa de aplicación. No se analiza el contenido de las solicitudes, por lo que las inundaciones de solicitudes de baja intensidad y lentas y el agotamiento de conexiones quedan fuera de lo que un conjunto de características basado solo en cabeceras puede observar.
Suplantación de origen aleatorizada. Falsificar una nueva dirección de origen por paquete eleva la entropía en lugar de reducirla, invirtiendo la señal que buscan las características basadas en direcciones. La entropía del puerto de origen, la varianza del TTL, y la diversidad de huellas TCP SYN son invariantes ante la falsificación de direcciones y cierran este punto ciego de detección, pero detectar una inundación falsificada es un problema más acotado que detenerla: bloquear una dirección falsificada sigue castigando a quien realmente la posee, por lo que la aplicación segura contra esta clase permanece abierta. Ver Detección y el Explicador.
git clone https://github.com/DevInBlack001/ddos-reduction-system.git
cd ddos-reduction-system
sudo bash scripts/install.sh --interface <IFACE> --victim-ips <IP1>,<IP2>
sudo systemctl enable --now ddos-stage2
sudo systemctl enable --now ddos-stage1
El instalador compila la Etapa 1, luego copia el código de la Etapa 2 y el entorno virtual a /opt/flod/stage2 (propiedad de root) y configura la cuenta administrativa allí, ya que la Etapa 2 se ejecuta como root y no debe ejecutar nada desde el checkout en el que una cuenta sin privilegios aún puede escribir. El estado mutable, la base de datos, la configuración JSON, los modelos entrenados, residen en /var/lib/flod. El checkout en sí mismo solo es una fuente de aquí en adelante; volver a ejecutar scripts/install.sh o scripts/update.sh actualiza la copia instalada a partir de él. Ver Seguridad para saber por qué.
El panel está en el puerto 8000, sobre HTTPS una vez que el certificado autofirmado del instalador está en su lugar. Las instrucciones completas, incluida la disposición de red de la que depende, están en la wiki.
El instalador también configura la cadena de herramientas de compilación de eBPF cuando puede, coincidiendo con el LLVM que distribuya tu distribución. Esa parte es opcional: sin ella el sensor igual se compila y se ejecuta sobre libpcap.
El sensor tiene dos backends de captura. libpcap es el predeterminado y funciona en cualquier lugar. Con la cadena de herramientas en su lugar, --capture-mode kernel cuenta paquetes en la ruta del controlador mediante XDP y TC en su lugar, despertando al espacio de usuario una vez por ventana en lugar de una vez por paquete. La detección es idéntica de cualquier manera.
El ajuste de la detección se mide en lugar de adivinarse. scripts/calibrate.py lee el propio registro del sensor, muestrea tráfico ordinario, y determina dónde deben estar los límites de anomalía en tu red.
Para probarlo sin instalar nada, ejecútalo desde la copia de trabajo:
sudo bash scripts/run.sh
Pregunta por cada valor que necesita, ofrece un valor predeterminado para cada uno, y pregunta si también debe iniciar la Etapa 2. Añade --defaults para aceptar todo sin que se te pregunte.
Para ejecutar las suites de pruebas:
scripts/test.sh
Wiki, para ejecutar el sistema:
| Página | Cubre |
|---|---|
| Instalación | Requisitos, ubicación en la red, primer inicio de sesión |
| Configuración | Opciones del sensor, ajuste de la aplicación, alertas |
| Guía del Panel | Cada página de la consola |
| Solución de Problemas | Cuando algo no funciona |
docs/, para entenderlo o modificarlo:
| Documento | Cubre |
|---|---|
| Arquitectura | La canalización, hilos, ajuste de captura, medición de egreso |
| Detección | Welford, EWMA, entropía, límites de anomalía, persistencia de la línea base |
| Explicador | Cada término y cada campo del formato de transmisión, explicado para un lector no técnico |
| IPC | El formato de transmisión del vector de características |
| Aplicación | Clasificación, los cuatro niveles de mitigación, manejo de NAT |
| Entrenamiento | Capturar datos etiquetados y entrenar el modelo |
| Pruebas | Ejecutar ambas suites de pruebas |
| Seguridad | La pasada de endurecimiento y el modelo de amenazas |
| Hoja de Ruta | Versiones completadas y planificadas |
| Resultados de Referencia | FLOD vs. un umbral fijo: hardware, metodología, salida completa |
| Lecciones Aprendidas | Errores reales encontrados durante el desarrollo, conservados por lo que generalizan |
CONTRIBUTING.md cubre la configuración de desarrollo y las convenciones. SECURITY.md cubre el reporte de vulnerabilidades.
Este proyecto es mío. El concepto, la arquitectura, el diseño de dos etapas, el enfoque de detección, la política de aplicación, el conjunto de características, y cada decisión funcional a lo largo de todas las versiones se originaron conmigo. Lo construí como un ejercicio de aprendizaje en seguridad de redes, detección estadística, y programación de sistemas, y dirigí su diseño y evolución en todo momento.
Usé IA como asistente de programación durante la implementación, escribiendo y refactorizando código según mis especificaciones y actuando como caja de resonancia mientras trabajaba a través de las disyuntivas de diseño. Las decisiones sobre qué construir, por qué, y cómo debería comportarse el sistema fueron mías.
Un proyecto personal, de código abierto, y un sistema funcional, pero no uno que haya pasado por las pruebas adversarias que un producto de seguridad de producción necesita. Despliégalo en una red de laboratorio o en algún lugar donde puedas permitirte que se equivoque.
Ver LICENSE.