FLOD System

First Line Of Defense

Ein adaptives zweistufiges Gateway zur Abwehr volumetrischer DDoS-Angriffe auf Layer 4.

Autor: Abdullah Armiyao

Projekt: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis

Was es tut

Die meisten DDoS-Abwehrmaßnahmen verwenden feste Schwellenwerte: Alles wird blockiert, was mehr als eine fest codierte Anzahl von Paketen pro Sekunde sendet. Das schlägt in beide Richtungen fehl. Legitimer Datenverkehr spitzt sich während einer Auslastungsphase zu und echte Nutzer werden blockiert, oder ein Angreifer bleibt knapp unter der Grenze und kommt durch.

FLOD lernt, wie Ihr normaler Datenverkehr aussieht, und verschiebt seine eigenen Erkennungsgrenzen entsprechend. Es unterscheidet eine DDoS-Flut von einem Flash Crowd, einem legitimen Anstieg, ohne dass jemand einen Schwellenwert von Hand anpassen muss.

Es sitzt inline auf einem Gateway zwischen der Datenverkehrsquelle und den zu schützenden Hosts und verwirft oder drosselt angreifende Quellen im Kernel.

Das Dashboard benennt die blockierten Adressen als Angreifer, sodass jemand, der das Netzwerklayout nicht bereits kennt, erkennen kann, welche Absender feindlich gesinnt waren. Gedrosselte Adressen werden separat aufgeführt, da Drosselung auch als Vorsichtsmaßnahme eingesetzt und auf ganze Gruppen auf einmal angewendet wird.

Wie es aufgebaut ist

Stufe 1 ist ein Rust-Sensor auf dem Paketpfad. Er erfasst jedes Paket, das für einen geschützten Host bestimmt ist, berechnet Rate und Quellendiversität über kurze Zeitfenster und vergleicht sie mit einer selbst gepflegten Baseline. Er führt nur Arithmetik aus und steht dem Datenverkehr daher nicht im Weg.

Stufe 2 ist ein Python-Dienst. Er empfängt einmal pro Zeitfenster eine Zusammenfassung von Stufe 1, klassifiziert sie mit einem Random Forest und setzt Durchsetzungsmaßnahmen auf Kernel-Ebene über ipset und iptables durch. Ein Isolation Forest läuft parallel dazu bei jedem Zeitfenster und markiert Datenverkehr, der anders ist als alles, was eines der beiden Modelle gelernt hat, und wird als separater Zustand Anomalous angezeigt, statt die Durchsetzung zu steuern. Stufe 2 stellt außerdem das Web-Dashboard bereit.

Die beiden sind über einen Unix-Domain-Socket verbunden.

Lernen aus dem eigenen Datenverkehr

Die Modelle werden mit erfasstem, gelabeltem Datenverkehr trainiert, und eine Bereitstellung erfasst fortlaufend mehr. Zeitfenster, die der Isolation Forest als ungewohnt einstuft, und Zeitfenster, die der Random Forest mit hoher Zuversicht als DDoS einstuft, werden in Erfassungsdateien geschrieben. Ein periodischer Job bewertet sie mit dem Random Forest und einem zweiten, anders aufgebauten Modell neu und stellt eine Zeile nur dann zum Training bereit, wenn beide mit hoher Zuversicht dieselbe Klasse wählen und beide nach der Erfassung der Zeile trainiert wurden. Eine Überprüfungsseite im Dashboard zeigt die bereitgestellten Zeilen, 500 pro Seite, und eine Person entscheidet, ob sie in die Trainingsdaten übernommen oder verworfen werden. Nichts gelangt von selbst in den Trainingsdatensatz.

Geltungsbereich

FLOD wirkt auf volumetrische Fluten auf Layer 4, die allein aus Paket-Headern sichtbar sind: Rate, Entropie der Quell-IP, Protokollmix und wie stark der Datenverkehr auf seine verkehrsreichste Quelle konzentriert ist. In der Praxis bedeutet das Fluten, die sowohl hohes Volumen als auch konzentriert sind und von einer begrenzten Menge echter Adressen stammen.

Ein Punkt ist ausdrücklich außerhalb des Geltungsbereichs, und einer wird teilweise behandelt:

Angriffe auf Anwendungsebene. Es wird kein Anforderungsinhalt geparst, daher liegen langsame und schwache Anforderungsfluten und Verbindungserschöpfung außerhalb dessen, was ein rein headerbasiertes Merkmalsset beobachten kann.

Randomisiertes Quell-Spoofing. Das Fälschen einer neuen Quelladresse pro Paket erhöht die Entropie, statt sie zu senken, und kehrt damit das Signal um, nach dem die adressbasierten Merkmale suchen. Entropie der Quellports, TTL-Varianz und Vielfalt der TCP-SYN-Fingerabdrücke sind unter Adressfälschung invariant und schließen diese Erkennungslücke, aber eine gefälschte Flut zu erkennen ist ein engeres Problem als eine zu stoppen: Das Blockieren einer gefälschten Adresse bestraft immer noch denjenigen, dem sie wirklich gehört, sodass eine sichere Durchsetzung gegen diese Klasse offen bleibt. Siehe Detection und den Explainer.

Schnellstart

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

Der Installer baut Stage 1 und kopiert anschließend den Code und die virtuelle Umgebung von Stage 2 nach /opt/flod/stage2 (im Besitz von root) und richtet dort das Administratorkonto ein, da Stage 2 als root läuft und nichts aus dem Checkout ausführen darf, in das ein unprivilegiertes Konto noch schreiben kann. Veränderlicher Zustand, die Datenbank, die JSON-Konfiguration, trainierte Modelle, liegen in /var/lib/flod. Der Checkout selbst ist von hier an nur noch eine Quelle; ein erneutes Ausführen von scripts/install.sh oder scripts/update.sh aktualisiert die installierte Kopie daraus. Siehe Security für die Begründung.

Das Dashboard ist auf Port 8000 erreichbar, über HTTPS, sobald das selbst signierte Zertifikat des Installers eingerichtet ist. Vollständige Anweisungen, einschließlich des Netzwerklayouts, von dem dies abhängt, finden sich im wiki.

Der Installer richtet außerdem, wenn möglich, die eBPF-Build-Toolchain ein und passt sie an das LLVM an, das Ihre Distribution mitliefert. Dieser Teil ist optional: Ohne ihn lässt sich der Sensor weiterhin bauen und mit libpcap betreiben.

Der Sensor verfügt über zwei Capture-Backends. libpcap ist der Standard und funktioniert überall. Mit eingerichteter Toolchain zählt --capture-mode kernel Pakete im Treiberpfad über XDP und TC und weckt den User Space einmal pro Fenster statt einmal pro Paket. Die Erkennung ist in beiden Fällen identisch.

Die Erkennungsabstimmung wird gemessen statt geraten. scripts/calibrate.py liest das eigene Log des Sensors, tastet gewöhnlichen Datenverkehr ab und ermittelt, wo die Anomaliegrenzen in Ihrem Netzwerk liegen sollten.

Um es ohne Installation auszuprobieren, führen Sie es aus der Arbeitskopie aus:

sudo bash scripts/run.sh

Es fragt nach jedem benötigten Wert, bietet für jeden einen Standardwert an und fragt, ob auch Stage 2 gestartet werden soll. Fügen Sie --defaults hinzu, um alles ohne Nachfrage zu akzeptieren.

Um die Test-Suites auszuführen:

scripts/test.sh

Dokumentation

Wiki, zum Betrieb des Systems:

Seite	Behandelt
Installation	Voraussetzungen, Netzwerkplatzierung, erste Anmeldung
Konfiguration	Sensor-Flags, Feinabstimmung der Durchsetzung, Benachrichtigungen
Dashboard-Anleitung	Jede Seite in der Konsole
Fehlerbehebung	Wenn etwas nicht funktioniert

docs/, zum Verstehen oder Ändern: