Système FLOD

Première ligne de défense

Une passerelle d'atténuation DDoS volumétrique de couche 4 adaptative à deux étages.

Auteur : Abdullah Armiyao

Projet : Cadre adaptatif à deux étages pour l'atténuation DDoS volumétrique de couche 4 en quasi temps réel grâce à l'analyse comportementale du trafic

Ce qu'il fait

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 retrouvent bloqués, ou un attaquant reste juste sous la limite 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 flood DDoS d'un flash crowd, un pic 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 supprime 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 identifier quels expéditeurs é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.

Comment il est construit

L'étage 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 référence qu'il maintient lui-même. Il n'effectue que de l'arithmétique, il reste donc à l'écart du trafic.

L'étage 2 est un service Python. Il reçoit un résumé de l'étage 1 une fois par fenêtre, le classe avec une forêt aléatoire (Random Forest), et applique l'application au niveau du noyau via ipset et iptables. Une forêt d'isolement (Isolation Forest) 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 comme déclencheur d'application. L'étage 2 sert également le tableau de bord web.

Les deux sont reliés par une socket de domaine Unix.

Apprendre de son propre trafic

Les modèles sont entraînés sur du trafic capturé et étiqueté, et un déploiement continue d'en capturer davantage. Les fenêtres que la forêt d'isolement trouve inhabituelles, et les fenêtres que la forêt aléatoire qualifie avec confiance de DDoS, sont écrites dans des fichiers de capture. Une tâche périodique les réévalue avec la forêt aléatoire et un second modèle construit différemment, et prépare une ligne pour l'entraînement uniquement lorsque les deux choisissent la même classe avec une haute confiance et que les deux ont été entraînés après la capture de la ligne. Une page de révision dans le tableau de bord affiche les lignes préparées, 500 par page, et une personne décide de les fusionner dans les données d'entraînement ou de les écarter. Rien n'atteint l'ensemble d'entraînement de lui-même.

Périmètre

FLOD fonctionne sur les floods 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 concentration du trafic sur sa source la plus active. En pratique, cela signifie des floods à la fois de fort volume et concentrés, provenant d'un ensemble borné d'adresses réelles.

Une chose est explicitement hors périmètre, et une autre est partiellement traitée :

Attaques de couche applicative. Aucun contenu de requête n'est analysé, donc les floods de requêtes lents et de faible volume ainsi que l'épuisement de connexions sortent de ce qu'un ensemble de caractéristiques basé uniquement sur les en-têtes peut observer.

Usurpation de source aléatoire. Forger une nouvelle adresse source par paquet augmente l'entropie au lieu de la réduire, inversant le signal que recherchent les caractéristiques basées sur l'adresse. L'entropie des ports sources, la variance TTL et la diversité des empreintes TCP SYN sont invariantes sous la falsification d'adresse et comblent cette angle mort de détection, mais détecter un flood usurpé est un problème plus étroit que de l'arrêter : 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.

Démarrage rapide

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 et l'environnement virtuel de l'étape 2 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 le checkout dans lequel un compte non privilégié peut encore écrire. L'état mutable, la base de données, la configuration JSON, les modèles entraînés, résident dans /var/lib/flod. Le checkout lui-même n'est plus désormais qu'une source ; réexécuter scripts/install.sh ou scripts/update.sh rafraîchit la copie installée à partir de celui-ci. Voir Security pour en comprendre 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, se trouvent dans le wiki.

L'installateur configure également la chaîne d'outils de compilation eBPF lorsqu'il le peut, en fonction de la version de LLVM fournie par votre distribution. Cette partie est facultative : sans elle, le capteur se compile et fonctionne toujours sur libpcap.

Le capteur dispose de 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, en 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ù doivent se situer les seuils d'anomalie 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 également démarrer l'étape 2. Ajoutez --defaults pour tout accepter sans être interrogé.

Pour exécuter les suites de tests :

scripts/test.sh

Documentation

Wiki, pour exécuter le système :

Page	Contenu
Installation	Prérequis, placement réseau, première connexion
Configuration	Options du capteur, réglage de l'application des mesures, alertes
Guide du tableau de bord	Chaque page de la console
Dépannage	Quand quelque chose ne fonctionne pas