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: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis
La mayoría de las mitigaciones de DDoS usan umbrales fijos: bloquean cualquier cosa que envíe más de algún número codificado de paquetes por segundo. Eso falla en ambas direcciones. El tráfico legítimo se dispara durante un periodo de alta actividad y los usuarios reales quedan bloqueados, o un atacante se mantiene justo por debajo del límite y logra pasar.
FLOD aprende cómo es tu tráfico normal y mueve sus propios límites de detección para adaptarse. Distingue una inundación DDoS de una flash crowd, una oleada legítima, 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, para que alguien que no conoce ya la disposición de la red pueda 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 en 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 dos 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.
Los modelos se entrenan con tráfico capturado y etiquetado, y un despliegue sigue capturando más. Las ventanas que el Isolation Forest encuentra desconocidas, y las ventanas que el Random Forest llama con confianza DDoS, se escriben en archivos de captura. Una tarea periódica las vuelve a puntuar con el Random Forest y un segundo modelo, construido de forma diferente, y prepara una fila para entrenamiento solo cuando ambos eligen la misma clase con alta confianza y ambos fueron entrenados después de que se capturara la fila. Una página de revisión en el panel muestra las filas preparadas, 500 por página, y una persona decide si fusionarlas con los datos de entrenamiento o descartarlas. Nada llega al conjunto de entrenamiento por sí solo.
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 ocupada. En la práctica, eso significa inundaciones que son tanto de alto volumen como concentradas, que llegan desde un conjunto acotado de direcciones reales.
Una cosa está explícitamente fuera de alcance, y otra se aborda parcialmente:
Ataques de capa de aplicación. No se analiza el contenido de las solicitudes, por lo que las inundaciones de solicitudes lentas y de bajo volumen 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 de 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 estrecho que detenerla: bloquear una dirección falsificada sigue castigando a quien realmente es su dueño, por lo que la aplicación segura contra esta clase sigue abierta. Véase Detección y el Explainer.
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 y luego copia el código y el entorno
virtual de la Etapa 2 en /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í solo es una fuente a partir de
este momento; volver a ejecutar scripts/install.sh o scripts/update.sh actualiza la
copia instalada a partir de él. Consulte Seguridad para saber por qué.
El panel de control 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 esto, están en la wiki.
El instalador también configura la cadena de herramientas de compilación de eBPF cuando puede, adaptándose a la versión de LLVM que distribuya su distribución. Esa parte es opcional: sin ella, el sensor aún 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 los 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 ubicarse
los límites de anomalía en su red.
Para probarlo sin instalar nada, ejecútelo 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 se debe iniciar la Etapa 2. Añade --defaults para aceptar todo sin que se le 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: