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 di mitigazione DDoS volumetrico di Livello 4 a due stadi.
Autore: Abdullah Armiyao
Progetto: Framework Adattivo a Due Stadi per la Mitigazione DDoS Volumetrica di Livello 4 Quasi in Tempo Reale tramite Analisi Comportamentale del Traffico
La maggior parte delle mitigazioni DDoS utilizza soglie fisse: blocca tutto ciò che invia più di un certo numero predefinito di pacchetti al secondo. 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 impara 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 debba regolare 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 viene usata anche come precauzione e viene applicata a interi gruppi contemporaneamente.
Lo Stadio 1 è un sensore in Rust sul percorso dei pacchetti. Cattura ogni pacchetto diretto verso 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 operazioni aritmetiche, 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, e applica l'enforcement a livello kernel tramite ipset e iptables. Un Isolation Forest viene eseguito in parallelo su ogni finestra, segnalando traffico diverso da qualsiasi cosa entrambi i modelli abbiano appreso, esposto come stato Anomalous separato anziché guidare l'enforcement. Lo Stadio 2 serve anche la dashboard web.
I due sono collegati da un socket di dominio Unix.
FLOD opera su flood volumetrici di Livello 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 questo 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 delle richieste viene analizzato, quindi flood di richieste low and slow ed esaurimento delle connessioni sono al di fuori di ciò che un set di feature basato solo sugli header può osservare.
Spoofing di sorgenti randomizzate. Falsificare un nuovo indirizzo sorgente per ogni pacchetto aumenta l'entropia invece di ridurla, invertendo il segnale che le feature basate sull'indirizzo cercano. L'entropia delle porte sorgente, la varianza del TTL, e la diversità delle impronte TCP SYN sono invarianti rispetto alla falsificazione degli indirizzi e chiudono questo punto cieco del rilevamento, ma rilevare un flood falsificato è un problema più ristretto rispetto a fermarlo: bloccare un indirizzo falsificato punisce comunque chi lo possiede realmente, quindi l'enforcement sicuro contro questa classe rimane aperto. 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 Stadio 1, poi copia il codice dello Stadio 2 e l'ambiente virtuale in /opt/flod/stage2 (di proprietà di root) e configura l'account amministrativo lì, poiché lo Stadio 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. Il checkout stesso è da qui in poi solo una sorgente; rieseguire scripts/install.sh o scripts/update.sh aggiorna la copia installata da esso. Vedi Security per il motivo.
La dashboard è sulla porta 8000, su HTTPS una volta che il certificato auto-firmato dell'installer è in posizione. Le istruzioni complete, inclusa la disposizione di rete da cui dipende, sono nella wiki.
L'installer configura anche la toolchain di build eBPF quando può, in base a quale LLVM distribuisce la tua distribuzione. Quella parte è opzionale: senza di essa il sensore si compila e funziona comunque su libpcap.
Il sensore ha due backend di cattura. libpcap è il predefinito e funziona ovunque. Con la toolchain in posizione, --capture-mode kernel conta i pacchetti nel percorso del driver tramite XDP e TC invece, risvegliando lo spazio utente una volta per finestra anziché una volta per pacchetto. Il rilevamento è identico in entrambi i casi.
La messa a punto del rilevamento è misurata anziché ipotizzata. scripts/calibrate.py legge il log del sensore stesso, campiona il traffico ordinario, e determina dove devono trovarsi i confini 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 lo Stadio 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 | Copre |
|---|---|
| Installation | Requisiti, posizionamento in rete, primo accesso |
| Configuration | Flag del sensore, messa a punto dell'enforcement, avvisi |
| Dashboard Guide | Ogni pagina della console |
| Troubleshooting | Quando qualcosa non funziona |
docs/, per comprenderlo o modificarlo:
| Documento | Copre |
|---|---|
| Architecture | La pipeline, il threading, la messa a punto della cattura, la misurazione dell'egress |
| Detection | Welford, EWMA, entropia, confini di anomalia, persistenza della baseline |
| Explainer | Ogni termine e ogni campo del formato wire, spiegato per un lettore non tecnico |
| IPC | Il formato wire del vettore di feature |
| Enforcement | Classificazione, i quattro livelli di mitigazione, gestione NAT |
| Training | Catturare dati etichettati e addestrare il modello |
| Testing | Eseguire entrambe le suite di test |
| Security | La passata di hardening e il modello di minaccia |
| Roadmap | Versioni completate e pianificate |
| Benchmark Results | FLOD vs. una soglia fissa: hardware, metodologia, output completo |
| Lessons Learned | Bug reali trovati durante lo sviluppo, conservati per ciò a cui generalizzano |
CONTRIBUTING.md copre la configurazione dello sviluppo e le convenzioni. SECURITY.md copre la segnalazione delle vulnerabilità.
Questo progetto è mio. Il concetto, l'architettura, il design a due stadi, l'approccio di rilevamento, la politica di enforcement, il set di feature, e ogni decisione funzionale in tutte le versioni sono nati da me. L'ho costruito come esercizio di apprendimento in sicurezza di rete, rilevamento statistico, e programmazione di sistemi, e ne ho diretto il design e l'evoluzione per tutto il tempo.
Ho usato l'IA come assistente di programmazione durante l'implementazione, scrivendo e rifattorizzando codice secondo le mie specifiche e fungendo da spalla per il confronto mentre elaboravo i compromessi di design. Le decisioni su cosa costruire, perché, e come il sistema dovrebbe comportarsi sono state mie.
Un progetto personale, open source, e un sistema funzionante, ma non uno che abbia superato il test avversariale di cui ha bisogno un prodotto di sicurezza di produzione. Distribuiscilo su una rete di laboratorio o da qualche parte dove puoi permetterti che si sbagli.
Vedi LICENSE.