devinblack001/ddos-reduction-systemGateway adaptativo de mitigação de DDoS na Camada 4 em dois estágios, utilizando análise comportamental de tráfego, classificação por Random Forest e aplicação em nível de kernel via ipset/iptables.
First Line Of Defense
Um gateway adaptativo de mitigação de DDoS volumétrico de Camada 4 em dois estágios.
Autor: Abdullah Armiyao
Projeto: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis
A maioria das mitigações de DDoS usa limites fixos: bloqueia tudo que envia mais do que algum número fixo de pacotes por segundo. Isso falha nos dois sentidos. Picos de tráfego legítimo durante um período movimentado e usuários reais são bloqueados, ou um atacante fica logo abaixo da linha e consegue passar.
O FLOD aprende como é o seu tráfego normal e move seus próprios limites de detecção para se adequar. Ele distingue um flood de DDoS de um flash crowd, um pico legítimo, sem que ninguém ajuste um limite manualmente.
Ele fica em linha em um gateway entre a origem do tráfego e os hosts que estão sendo protegidos, e descarta ou limita as origens infratoras no kernel.
O painel nomeia os endereços que bloqueou como atacantes, para que alguém que não conhece previamente o layout da rede possa identificar quais remetentes eram hostis. Endereços limitados são listados separadamente, porque a limitação também é usada como precaução e é aplicada a grupos inteiros de uma vez.
O Estágio 1 é um sensor em Rust no caminho dos pacotes. Ele captura cada pacote destinado a um host protegido, calcula taxa e diversidade de origem em janelas curtas, e as compara com uma linha de base que ele mesmo mantém. Ele faz apenas aritmética, então fica fora do caminho do tráfego.
O Estágio 2 é um serviço em Python. Ele recebe um resumo do Estágio 1 uma
vez por janela, o classifica com uma Random Forest, e emite aplicação em nível
de kernel através de ipset e iptables. Uma Isolation Forest roda ao lado dele
em cada janela, sinalizando tráfego diferente de tudo que qualquer um dos
modelos aprendeu, apresentado como um estado Anomalous separado em vez de
conduzir a aplicação. O Estágio 2 também serve o painel web.
Os dois são conectados por um socket de domínio Unix.
O FLOD funciona em floods volumétricos de Camada 4 visíveis apenas pelos cabeçalhos dos pacotes: taxa, entropia de IP de origem, mistura de protocolos, e quão concentrado o tráfego está em sua origem mais movimentada. Na prática, isso significa floods que são tanto de alto volume quanto concentrados, chegando de um conjunto limitado de endereços reais.
Uma coisa está explicitamente fora de escopo, e uma é parcialmente abordada:
Ataques de camada de aplicação. Nenhum conteúdo de requisição é analisado, então floods de requisições de baixo volume e lentos e esgotamento de conexões estão fora do que um conjunto de características baseado apenas em cabeçalhos consegue observar.
Spoofing de origem randomizado. Forjar um novo endereço de origem por pacote aumenta a entropia em vez de diminuí-la, invertendo o sinal que as características baseadas em endereço procuram. Entropia de porta de origem, variância de TTL, e diversidade de fingerprint de TCP SYN são invariantes sob falsificação de endereço e fecham esse ponto cego de detecção, mas detectar um flood falsificado é um problema mais restrito do que pará-lo: bloquear um endereço forjado ainda pune quem realmente o possui, então a aplicação segura contra essa classe permanece em aberto. Veja Detection e o 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
O instalador compila o Estágio 1, depois copia o código do Estágio 2 e o
ambiente virtual para /opt/flod/stage2 (de propriedade do root) e configura a
conta administrativa lá, já que o Estágio 2 roda como root e não deve executar
nada do checkout no qual uma conta sem privilégios ainda pode escrever. O
estado mutável, o banco de dados, a configuração JSON, os modelos treinados,
ficam em /var/lib/flod. O próprio checkout é apenas uma fonte daqui em
diante; reexecutar scripts/install.sh ou scripts/update.sh atualiza a cópia
instalada a partir dele. Veja Security para entender o
porquê.
O painel fica na porta 8000, sobre HTTPS assim que o certificado autoassinado do instalador estiver no lugar. Instruções completas, incluindo o layout de rede do qual isso depende, estão na wiki.
O instalador também configura o conjunto de ferramentas de compilação eBPF quando pode, correspondendo ao LLVM que sua distribuição fornece. Essa parte é opcional: sem ela o sensor ainda compila e roda com libpcap.
O sensor tem dois backends de captura. libpcap é o padrão e funciona em
qualquer lugar. Com o conjunto de ferramentas no lugar, --capture-mode kernel
conta pacotes no caminho do driver via XDP e TC, em vez disso, acordando o
espaço de usuário uma vez por janela em vez de uma vez por pacote. A detecção é
idêntica de qualquer forma.
O ajuste da detecção é medido em vez de adivinhado. scripts/calibrate.py lê o
próprio log do sensor, amostra tráfego comum, e descobre onde os limites de
anomalia devem ficar na sua rede.
Para experimentá-lo sem instalar nada, execute-o a partir da cópia de trabalho:
sudo bash scripts/run.sh
Ele pergunta cada valor de que precisa, oferece um padrão para cada um, e
pergunta se deve iniciar o Estágio 2 também. Adicione --defaults para aceitar
tudo sem ser perguntado.
Para executar as suítes de teste:
scripts/test.sh
Wiki, para executar o sistema:
| Página | Abrange |
|---|---|
| Installation | Requisitos, posicionamento na rede, primeiro login |
| Configuration | Flags do sensor, ajuste de aplicação, alertas |
| Dashboard Guide | Cada página no console |
| Troubleshooting | Quando algo não está funcionando |
docs/, para entendê-lo ou alterá-lo:
| Documento | Abrange |
|---|---|
| Architecture | O pipeline, threading, ajuste de captura, medição de egress |
| Detection | Welford, EWMA, entropia, limites de anomalia, persistência de linha de base |
| Explainer | Cada termo e cada campo de formato de transmissão, explicado para um leitor não técnico |
| IPC | O formato de transmissão do vetor de características |
| Enforcement | Classificação, os quatro níveis de mitigação, tratamento de NAT |
| Training | Captura de dados rotulados e treinamento do modelo |
| Testing | Execução de ambas as suítes de teste |
| Security | A passagem de hardening e o modelo de ameaças |
| Roadmap | Versões concluídas e planejadas |
| Benchmark Results | FLOD vs. um limite fixo: hardware, metodologia, saída completa |
| Lessons Learned | Bugs reais encontrados durante o desenvolvimento, mantidos pelo que eles generalizam |
CONTRIBUTING.md cobre a configuração de desenvolvimento e convenções. SECURITY.md cobre o relato de vulnerabilidades.
Este projeto é meu. O conceito, a arquitetura, o design em dois estágios, a abordagem de detecção, a política de aplicação, o conjunto de características, e cada decisão funcional em todas as versões se originaram de mim. Eu o construí como um exercício de aprendizado em segurança de redes, detecção estatística, e programação de sistemas, e dirigi seu design e evolução ao longo de todo o processo.
Usei IA como assistente de codificação durante a implementação, escrevendo e refatorando código conforme minhas especificações e atuando como uma caixa de ressonância enquanto eu trabalhava nas decisões de design. As decisões sobre o que construir, por quê, e como o sistema deveria se comportar foram minhas.
Um projeto pessoal, de código aberto, e um sistema funcional, mas não um que tenha passado pelos testes adversariais que um produto de segurança de produção exige. Implante-o em uma rede de laboratório ou em algum lugar onde você possa se dar ao luxo de que ele esteja errado.
Veja LICENSE.