
Gateway 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.
Primeira Linha de Defesa
Um gateway adaptativo de mitigação de DDoS volumétrico de Camada 4 em dois estágios.
Autor: Abdullah Armiyao
Projeto: Framework Adaptativo de Dois Estágios para Mitigação de DDoS Volumétrico de Camada 4 em Tempo Quase Real Usando Análise Comportamental de Tráfego

A maioria das mitigações de DDoS usa limites fixos: bloqueia qualquer coisa que envie mais do que um número fixo de pacotes por segundo. Isso falha em ambas as direções. Picos legítimos de tráfego durante um período movimentado fazem usuários reais serem bloqueados, ou um atacante permanece 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 ajustar. Ele distingue um flood DDoS de um flash crowd, uma onda legítima, sem que ninguém ajuste um limite manualmente.
Ele fica inline em um gateway entre a origem do tráfego e os hosts 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 origens 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 é executada em paralelo a ele em cada
janela, sinalizando tráfego diferente de tudo que qualquer um dos modelos aprendeu, exibido como
um estado Anomalous separado em vez de acionar 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.
Os modelos são treinados com tráfego capturado e rotulado, e uma implantação continua capturando mais. Janelas que a Isolation Forest considera desconhecidas, e janelas que a Random Forest chama com confiança de DDoS, são gravadas em arquivos de captura. Uma tarefa periódica as reavalia com a Random Forest e um segundo modelo, construído de forma diferente, e prepara uma linha para treinamento apenas quando ambos escolhem a mesma classe com alta confiança e ambos foram treinados após a linha ter sido capturada. Uma página de revisão no painel mostra as linhas preparadas, 500 por página, e uma pessoa decide se deve mesclá-las aos dados de treinamento ou descartá-las. Nada chega ao conjunto de treinamento por conta própria.
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 do escopo, e uma é parcialmente abordada:
Ataques na camada de aplicação. Nenhum conteúdo de requisição é analisado, então floods de requisições lentos e de baixo volume e esgotamento de conexões estão fora do que um conjunto de características baseado apenas em cabeçalhos pode observar.
Falsificação de origem randomizada. Forjar um novo endereço de origem por pacote aumenta a entropia em vez de reduzi-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 impedir um: bloquear um endereço forjado ainda pune quem realmente o possui, então a aplicação segura contra essa classe permanece em aberto. Veja Detecção e o 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
O instalador compila o Stage 1 e depois copia o código e o ambiente
virtual do Stage 2 para /opt/flod/stage2 (propriedade de root) e configura
a conta administrativa nesse local, já que o Stage 2 é executado como root e não deve
executar nada a partir do checkout no qual uma conta sem privilégios ainda pode
escrever. O estado mutável, o banco de dados, a configuração JSON e os modelos treinados ficam
em /var/lib/flod. A partir daqui, o checkout é apenas uma fonte; executar novamente scripts/install.sh ou scripts/update.sh atualiza a
cópia instalada a partir dele. Consulte Security para entender o motivo.
O dashboard fica na porta 8000, sobre HTTPS depois que o certificado autoassinado do instalador estiver configurado. As 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 possível, correspondendo ao LLVM fornecido pela sua distribuição. Essa parte é opcional: sem ela, o sensor ainda compila e funciona com libpcap.
O sensor tem dois backends de captura. O libpcap é o padrão e funciona
em qualquer lugar. Com o conjunto de ferramentas configurado, --capture-mode kernel conta pacotes
no caminho do driver via XDP e TC, 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, não estimado. scripts/calibrate.py lê
o próprio log do sensor, amostra tráfego comum e determina 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 solicita cada valor de que precisa, oferece um padrão para cada um e pergunta
se deve iniciar também o Estágio 2. Adicione --defaults para aceitar tudo sem
ser questionado.
Para executar as suítes de teste:
scripts/test.sh
Wiki, para executar o sistema:
| Página | Abrange |
|---|---|
| Instalação | Requisitos, posicionamento na rede, primeiro login |
| Configuração | Flags do sensor, ajuste da aplicação de medidas, alertas |
| Guia do Dashboard | Todas as páginas da consola |
| Resolução de Problemas | Quando algo não está a funcionar |
docs/, para o compreender ou alterar: