devinblack001/ddos-reduction-systemGateway adattivo a due stadi per la mitigazione DDoS di Livello 4 che utilizza analisi comportamentale del traffico, classificazione Random Forest e applicazione a livello kernel tramite ipset/iptables.
First Line Of Defense
Un gateway adattivo per la mitigazione DDoS volumetrica di Layer 4 a due stadi.
Autore: Abdullah Armiyao
Progetto: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis
La maggior parte della mitigazione DDoS utilizza soglie fisse: blocca qualsiasi cosa invii più di un numero di pacchetti al secondo codificato in modo rigido. Questo fallisce in entrambe le direzioni. Picchi di traffico legittimo durante un periodo intenso e gli utenti reali vengono bloccati, oppure un attaccante rimane appena sotto la soglia e riesce a passare.
FLOD apprende come appare il tuo traffico normale e sposta i propri confini di rilevamento per adattarsi. Distingue un flood DDoS da un flash crowd, un picco legittimo, senza che nessuno regoli una soglia manualmente.
Si colloca inline su un gateway tra la sorgente del traffico e gli host da proteggere, e scarta o limita le sorgenti offensive nel kernel.
La dashboard identifica gli indirizzi che ha bloccato come attaccanti, così chi non conosce già la disposizione della rete può capire quali mittenti erano ostili. Gli indirizzi limitati sono elencati separatamente, perché la limitazione è usata anche come precauzione e viene applicata a interi gruppi contemporaneamente.
Lo Stadio 1 è un sensore Rust sul percorso dei pacchetti. Cattura ogni pacchetto diretto a un host protetto, calcola la frequenza e la diversità delle sorgenti su finestre brevi, e le confronta con una baseline che mantiene autonomamente. Esegue solo aritmetica, quindi non interferisce con il traffico.
Lo Stadio 2 è un servizio Python. Riceve un riepilogo dallo Stadio 1 una volta per
finestra, lo classifica con una Random Forest, ed emette l'applicazione a livello di kernel
tramite ipset e iptables. Una Isolation Forest viene eseguita parallelamente su ogni
finestra, segnalando traffico diverso da qualsiasi cosa che uno dei due modelli abbia appreso, esposto come
uno stato Anomalous separato anziché guidare l'applicazione. Lo Stadio 2 serve anche
la dashboard web.
I due sono collegati da un socket di dominio Unix.
I modelli sono addestrati su traffico catturato ed etichettato, e un deployment continua a catturarne altro. Le finestre che l'Isolation Forest trova non familiari, e le finestre che la Random Forest chiama con sicurezza DDoS, vengono scritte in file di cattura. Un job periodico le rivaluta con la Random Forest e un secondo modello, costruito diversamente, e prepara una riga per l'addestramento solo quando entrambi scelgono la stessa classe con alta confidenza ed entrambi sono stati addestrati dopo la cattura della riga. Una pagina di revisione nella dashboard mostra le righe preparate, 500 per pagina, e una persona decide se unirle ai dati di addestramento o scartarle. Nulla raggiunge il set di addestramento da solo.
FLOD funziona su flood volumetrici di Layer 4 visibili dai soli header dei pacchetti: frequenza, entropia degli IP sorgente, mix di protocolli, e quanto il traffico è concentrato sulla sua sorgente più attiva. In pratica ciò significa flood che sono sia ad alto volume che concentrati, provenienti da un insieme limitato di indirizzi reali.
Una cosa è esplicitamente fuori ambito, e una è parzialmente affrontata:
Attacchi a livello applicativo. Nessun contenuto della richiesta viene analizzato, quindi flood di richieste low and slow e esaurimento delle connessioni sono al di fuori di ciò che un set di feature basato solo sugli header può osservare.
Spoofing delle sorgenti randomizzato. Falsificare un nuovo indirizzo sorgente per pacchetto aumenta l'entropia invece di ridurla, invertendo il segnale che le feature basate sull'indirizzo cercano. L'entropia della porta sorgente, la varianza del TTL e la diversità delle impronte TCP SYN sono invarianti sotto la falsificazione degli indirizzi e chiudono questo punto cieco del rilevamento, ma rilevare un flood falsificato è un problema più ristretto che fermarne uno: bloccare un indirizzo falsificato punisce comunque chi ne è realmente proprietario, quindi l'applicazione sicura contro questa classe rimane aperta. Vedi Detection e l'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
L'installer compila lo Stage 1, poi copia il codice e l'ambiente virtuale dello Stage 2 in /opt/flod/stage2 (di proprietà di root) e vi configura l'account amministrativo, poiché lo Stage 2 viene eseguito come root e non deve eseguire nulla dal checkout su cui un account non privilegiato può ancora scrivere. Lo stato mutabile, il database, la configurazione JSON, i modelli addestrati, risiedono in /var/lib/flod. Da questo momento il checkout è soltanto una fonte; rieseguire scripts/install.sh o scripts/update.sh aggiorna la copia installata a partire da esso. Consultare Security per il motivo.
La dashboard è sulla porta 8000, in HTTPS una volta installato il certificato autofirmato dell'installer. Le istruzioni complete, inclusa la configurazione di rete da cui dipende, sono nella wiki.
L'installer configura anche la toolchain di compilazione eBPF quando possibile, in base alla versione di LLVM fornita dalla distribuzione. Questa parte è opzionale: senza di essa il sensore viene comunque compilato ed eseguito su libpcap.
Il sensore dispone di due backend di cattura. libpcap è quello predefinito e funziona ovunque. Con la toolchain installata, --capture-mode kernel conta invece i pacchetti nel percorso del driver tramite XDP e TC, risvegliando lo spazio utente una volta per finestra anziché una volta per pacchetto. Il rilevamento è identico in entrambi i casi.
La taratura del rilevamento è misurata anziché stimata. scripts/calibrate.py legge il log del sensore stesso, campiona il traffico ordinario e determina dove devono collocarsi le soglie di anomalia sulla tua rete.
Per provarlo senza installare nulla, eseguilo dalla copia di lavoro:
sudo bash scripts/run.sh
Chiede ogni valore di cui ha bisogno, offre un valore predefinito per ognuno e chiede
se avviare anche la Fase 2. Aggiungi --defaults per accettare tutto senza
che venga chiesto.
Per eseguire le suite di test:
scripts/test.sh
Wiki, per eseguire il sistema:
| Pagina | Contenuto |
|---|---|
| Installazione | Requisiti, posizionamento in rete, primo accesso |
| Configurazione | Flag del sensore, ottimizzazione dell'enforcement, avvisi |
| Guida alla dashboard | Ogni pagina della console |
| Risoluzione dei problemi | Quando qualcosa non funziona |
docs/, per comprenderlo o modificarlo: