devinblack001/ddos-reduction-systemPasserelle d'atténuation DDoS de couche 4 adaptative à deux étages utilisant l'analyse comportementale du trafic, la classification par forêt aléatoire et l'application au niveau du noyau via ipset/iptables.
Première ligne de défense
Une passerelle adaptative d'atténuation DDoS volumétrique de couche 4 en deux étapes.
Auteur : Abdullah Armiyao
Projet : Cadre adaptatif en deux étapes pour l'atténuation DDoS volumétrique de couche 4 en quasi-temps réel par analyse comportementale du trafic
La plupart des atténuations DDoS utilisent des seuils fixes : bloquer tout ce qui envoie plus d'un nombre codé en dur de paquets par seconde. Cela échoue dans les deux sens. Un pic de trafic légitime pendant une période chargée et de vrais utilisateurs se font bloquer, ou un attaquant reste juste sous la ligne et passe.
FLOD apprend à quoi ressemble votre trafic normal et déplace ses propres frontières de détection pour s'y adapter. Il distingue un déluge DDoS d'un afflux soudain, une montée légitime, sans que personne n'ajuste un seuil à la main.
Il se place en ligne sur une passerelle entre la source du trafic et les hôtes protégés, et abandonne ou limite les sources fautives dans le noyau.
Le tableau de bord nomme les adresses qu'il a bloquées comme attaquants, afin que quelqu'un qui ne connaît pas déjà la topologie du réseau puisse dire quels émetteurs étaient hostiles. Les adresses limitées sont listées séparément, car la limitation est aussi utilisée par précaution et est appliquée à des groupes entiers à la fois.
L'étape 1 est un capteur Rust sur le chemin des paquets. Il capture chaque paquet destiné à un hôte protégé, calcule le débit et la diversité des sources sur de courtes fenêtres, et les compare à une ligne de base qu'il maintient lui-même. Il ne fait que de l'arithmétique, donc il reste à l'écart du trafic.
L'étape 2 est un service Python. Il reçoit un résumé de l'étape 1 une fois par fenêtre, le classe avec une forêt aléatoire, et émet une application au niveau du noyau via ipset et iptables. Une forêt d'isolement s'exécute en parallèle sur chaque fenêtre, signalant un trafic différent de tout ce que l'un ou l'autre modèle a appris, présenté comme un état Anomalous distinct plutôt que de déclencher l'application. L'étape 2 sert aussi le tableau de bord web.
Les deux sont reliés par un socket de domaine Unix.
FLOD fonctionne sur les déluges volumétriques de couche 4 visibles à partir des seuls en-têtes de paquets : débit, entropie des IP sources, mélange de protocoles, et à quel point le trafic est concentré sur sa source la plus active. En pratique, cela signifie des déluges qui sont à la fois à haut volume et concentrés, provenant d'un ensemble borné d'adresses réelles.
Une chose est explicitement hors périmètre, et une est partiellement traitée :
Attaques de couche applicative. Aucun contenu de requête n'est analysé, donc les déluges de requêtes lents et de faible volume et l'épuisement de connexions sont hors de ce qu'un ensemble de caractéristiques basé uniquement sur les en-têtes peut observer.
Usurpation de source randomisée. Forger une nouvelle adresse source par paquet augmente l'entropie au lieu de la diminuer, inversant le signal que les caractéristiques basées sur l'adresse recherchent. L'entropie des ports sources, la variance TTL, et la diversité des empreintes TCP SYN sont invariantes sous la falsification d'adresse et comblent cet angle mort de détection, mais détecter un déluge usurpé est un problème plus étroit que d'en arrêter un : bloquer une adresse forgée punit toujours celui qui la possède réellement, donc une application sûre contre cette classe reste ouverte. Voir Détection et 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'installateur construit l'étape 1, puis copie le code de l'étape 2 et son environnement virtuel dans /opt/flod/stage2 (appartenant à root) et y configure le compte administratif, puisque l'étape 2 s'exécute en tant que root et ne doit rien exécuter depuis la copie de travail qu'un compte non privilégié peut encore modifier. L'état mutable, la base de données, la configuration JSON, les modèles entraînés, résident dans /var/lib/flod. La copie de travail elle-même n'est plus qu'une source à partir de maintenant ; réexécuter scripts/install.sh ou scripts/update.sh rafraîchit la copie installée à partir de celle-ci. Voir Sécurité pour la raison.
Le tableau de bord est sur le port 8000, en HTTPS une fois le certificat auto-signé de l'installateur en place. Les instructions complètes, y compris la topologie réseau dont cela dépend, sont dans le wiki.
L'installateur configure aussi la chaîne d'outils de compilation eBPF quand il le peut, en correspondance avec le LLVM fourni par votre distribution. Cette partie est optionnelle : sans elle, le capteur se compile et fonctionne toujours sur libpcap.
Le capteur a deux backends de capture. libpcap est celui par défaut et fonctionne partout. Avec la chaîne d'outils en place, --capture-mode kernel compte les paquets dans le chemin du pilote via XDP et TC à la place, réveillant l'espace utilisateur une fois par fenêtre plutôt qu'une fois par paquet. La détection est identique dans les deux cas.
Le réglage de la détection est mesuré plutôt que deviné. scripts/calibrate.py lit le propre journal du capteur, échantillonne le trafic ordinaire, et détermine où les frontières d'anomalie doivent se situer sur votre réseau.
Pour l'essayer sans rien installer, exécutez-le depuis la copie de travail :
sudo bash scripts/run.sh
Il demande chaque valeur dont il a besoin, propose une valeur par défaut pour chacune, et demande s'il faut aussi démarrer l'étape 2. Ajoutez --defaults pour tout accepter sans être interrogé.
Pour exécuter les suites de tests :
scripts/test.sh
Wiki, pour faire fonctionner le système :
| Page | Couvre |
|---|---|
| Installation | Prérequis, placement réseau, première connexion |
| Configuration | Options du capteur, réglage de l'application, alertes |
| Guide du tableau de bord | Chaque page de la console |
| Dépannage | Quand quelque chose ne fonctionne pas |
docs/, pour le comprendre ou le modifier :
| Document | Couvre |
|---|---|
| Architecture | Le pipeline, le threading, le réglage de la capture, la mesure de sortie |
| Détection | Welford, EWMA, entropie, frontières d'anomalie, persistance de la ligne de base |
| Explainer | Chaque terme et chaque champ de format de transmission, expliqué pour un lecteur non technique |
| IPC | Le format de transmission du vecteur de caractéristiques |
| Application | Classification, les quatre niveaux d'atténuation, gestion du NAT |
| Entraînement | Capturer des données étiquetées et entraîner le modèle |
| Tests | Exécuter les deux suites de tests |
| Sécurité | La passe de durcissement et le modèle de menace |
| Feuille de route | Versions terminées et prévues |
| Résultats de référence | FLOD vs. un seuil fixe : matériel, méthodologie, sortie complète |
| Leçons apprises | Bogues réels trouvés pendant le développement, conservés pour ce qu'ils généralisent |
CONTRIBUTING.md couvre la configuration de développement et les conventions. SECURITY.md couvre le signalement des vulnérabilités.
Ce projet est le mien. Le concept, l'architecture, la conception en deux étapes, l'approche de détection, la politique d'application, l'ensemble de caractéristiques, et chaque décision fonctionnelle à travers toutes les versions sont de moi. Je l'ai construit comme un exercice d'apprentissage en sécurité réseau, détection statistique, et programmation système, et j'ai dirigé sa conception et son évolution tout au long.
J'ai utilisé l'IA comme assistant de codage pendant l'implémentation, écrivant et refactorisant le code selon mes spécifications et servant de caisse de résonance pendant que je réfléchissais aux compromis de conception. Les décisions sur quoi construire, pourquoi, et comment le système devait se comporter étaient les miennes.
Un projet personnel, open source, et un système fonctionnel, mais pas un qui a subi les tests adversariaux dont un produit de sécurité en production a besoin. Déployez-le sur un réseau de laboratoire ou quelque part où vous pouvez vous permettre qu'il se trompe.
Voir LICENSE.