Wie ein DDoS-Angriff Schritt für Schritt aussieht: von der Erkennung bis zur Mitigation

Die meisten Materialien zum DDoS-Schutz beschreiben das Thema auf allgemeiner Ebene: „Das System erkennt den Angriff und blockiert ihn.“ In der Praxis geschehen zwischen dem ersten Angriffspaket und seiner wirksamen Mitigation mehrere konkrete technische Schritte, und wie schnell und präzise sie ausgeführt werden, entscheidet über die tatsächlichen Auswirkungen des Angriffs auf das Netz. Nachfolgend zerlegen wir diesen Prozess in Phasen, so wie er in der Umgebung eines ISP oder Rechenzentrumsbetreibers aussieht.

Bevor man überhaupt von der Erkennung eines Angriffs sprechen kann, muss das Schutzsystem wissen, wie der Verkehr im jeweiligen Netz unter normalen Bedingungen aussieht, für einzelne IP-Adressen ebenso wie für ganze Subnetze. Ohne diesen Bezugspunkt wäre jede Entscheidung darüber, was eine Anomalie und was eine gewöhnliche Verkehrsspitze ist (z. B. die abendliche Lastspitze bei einem Internetanbieter), reine Spekulation. Diese Phase läuft im Hintergrund, ständig, unabhängig davon, ob gerade ein Angriff stattfindet.

Ein DDoS-Angriff zeigt selten ein einziges, klar erkennbares Muster. In der Praxis gehört er meist zu einer von mehreren Kategorien:

Aus Sicht des Netzes des Opfers ist das erste Signal meist ein Anstieg der Paket- oder Sessionzahl, eine Verschiebung der Protokollverteilung oder eine ungewöhnliche Verkehrsverteilung auf vielen Adressen gleichzeitig.

Das ist der Moment, in dem die Qualität des Schutzsystems den größten Unterschied macht. Zwei Ansätze unterscheiden sich grundlegend in der Reaktionszeit:

Der Schwellenwert allein genügt nicht: Eine wirksame Erkennung muss außerdem einen auf viele Adressen verteilten Angriff von einem gewöhnlichen Verkehrsanstieg im gesamten Netz unterscheiden. Hier kommt die Aggregation pro Subnetz ins Spiel: Das System muss Hunderte scheinbar unabhängiger, kleiner Anomalien auf einzelnen IPs zu einem Vorfall zusammenführen können.

Nach der Erkennung einer Anomalie muss das System entscheiden, wie es darauf reagiert. Dabei kommen zwei einander ergänzende Mechanismen ins Spiel, beide auf BGP-Basis:

BGP FlowSpec: Verteilung präziser Filterregeln (z. B. Blockade eines bestimmten Protokolls, Ports oder Paketmusters) direkt an die Edge-Router, ohne manuelle Konfiguration von ACLs. Bei TCP-/UDP-Angriffen analysiert das System gesampelte Pakete und erzeugt eine auf das konkrete Angriffsmuster zugeschnittene Regel. In der Praxis bedeutet das die Blockade des bösartigen Verkehrs bei Erhalt des normalen Verkehrs auf derselben Adresse und demselben Protokoll.

Blackholing (RTBH): ein drastischerer Mechanismus, bei dem der Verkehr zur angegriffenen Adresse ins Nichts geleitet wird. Wirksam und sofort, aber auf Kosten auch des legitimen Verkehrs zu dieser Adresse. Klassisches, vollständiges Blackholing hat jedoch eine klare Wirtschaftlichkeitsgrenze: Die Blockade einer einzelnen angegriffenen IP-Adresse ist ein akzeptabler Preis, doch wenn der Angriff auf mehrere Hundert Adressen im selben Subnetz verteilt ist (Carpet Bombing), bedeutet das Blackholing des gesamten Bereichs die Abschaltung aller Kunden in diesem Subnetz, also praktisch genau die Wirkung, die der Angreifer erzielen wollte, nur durch die Hände des Betreibers ausgeführt.

Deshalb wird bei Volumina, die eine Sättigung der Leitungen drohen, statt des Blackholings des gesamten angegriffenen Bereichs selektives Blackholing eingesetzt: begrenzt auf die tatsächlich angegriffenen Adressen oder eine engere Teilmenge von Präfixen innerhalb des Subnetzes, gegebenenfalls nur an ausgewählte BGP-Sessions angekündigt (z. B. an den konkreten Upstream, über den der Angriff eintrifft), statt gleichzeitig an alle Peers. Dadurch bleibt der Verkehr zu den Adressen im selben Subnetz, die tatsächlich nicht Ziel des Angriffs sind, unberührt, und das Blackholing behält seinen Hauptvorteil, die Sofortigkeit, ohne dass der gesamte Adressbereich abgeschnitten werden muss.

Ein gut konzipiertes System wählt nicht automatisch die drastischste Option: Es bemüht sich zunächst um eine möglichst enge FlowSpec-Regel und behandelt Blackholing als Mechanismus für Situationen, in denen die präzise Anpassung mit dem Ausmaß des Angriffs nicht Schritt hält.

Die bloße Klassifizierung „das ist ein Angriff“ genügt nicht, um eine präzise Regel anzuwenden. Man muss auch wissen, wie genau der Verkehr aussieht, der blockiert werden soll. Hier haben die meisten Systeme auf Basis statischer Signaturen ein Problem: Eine für eine Angriffsvariante geschriebene Signatur erfasst eine modifizierte Variante nicht, und Angreifer verändern ihre Vektoren im Laufe der Zeit, um bekannte Regeln zu umgehen.

Statt sich ausschließlich auf fertige Signaturen zu verlassen, analysiert das System gesampelte Angriffspakete in Echtzeit und baut laufend dessen Charakteristik auf: Protokoll, Ports, Größe und Flags der Pakete, Verteilung der Quelladressen. Die erste Regel wird sofort auf Basis einer vorläufigen Klassifizierung angewendet (z. B. „blockiere UDP-Flood auf diese Adresse“), in den folgenden Sekunden aber mit dem Eintreffen weiterer Stichproben präzisiert, sodass sie am Ende ein möglichst enges, tatsächliches Angriffsmuster abdeckt und nicht den gesamten Verkehr des jeweiligen Protokolls.

Dasselbe Lernen ist für die Verfolgung des Angriffs über die Zeit zuständig: Ändert der Angreifer während des Vorfalls Ziel oder Vektor, aktualisiert das System die Regel, statt an der ursprünglichen Klassifizierung festzuhalten. Bei Angriffen vom Typ Carpet Bombing führt das auch zu einer dynamischen Erweiterung oder Verengung der Maske des geschützten Subnetzes, sodass sie der tatsächlichen Reichweite des Angriffs folgt und nicht seinem Zustand in der ersten Sekunde.

Die erzeugte Regel muss in die Netzinfrastruktur gelangen. Das geschieht über eine BGP-Session zwischen dem Schutzsystem und den Edge-Routern des Betreibers: FlowSpec-Regeln oder Blackhole-Routen werden über den Standardmechanismus von BGP propagiert, ohne dass man sich auf jedem Gerät einzeln einloggen muss. Das ist in Netzen mit mehreren Übergabepunkten (PoP) wichtig: Eine einzige Entscheidung des Schutzsystems wird gleichzeitig an alle relevanten Router propagiert.

Die in den ersten Sekunden angewendete Regel ist nicht endgültig: Solange der Vorfall andauert, überprüft und korrigiert der Mechanismus zum Lernen des Musters (Phase 3b) sie laufend. Ein System, das eine Regel nur einmal anwendet und den Vorfall dann „vergisst“, kommt hier also nicht in Frage: Die Filterung bleibt während der gesamten Dauer des Angriffs an dessen tatsächliches Verhalten angepasst und nicht nur an den Moment der Erkennung.

Parallel zur Mitigation sollte das System die zuständigen Personen informieren (E-Mail, Webhook), am besten mit der Möglichkeit, die Benachrichtigungen auf verschiedene Kundengruppen oder Präfixe aufzuteilen, damit das NOC-Team nicht manuell herausfiltern muss, welchen Kunden ein Alarm betrifft. Für Betreiber, die unter das nationale Cybersicherheitssystem bzw. NIS2 fallen, ist außerdem wichtig, dass die Daten zum Vorfall (Zeit, Vektor, Volumen) in einer Form verfügbar sind, die die spätere Meldung an das CSIRT erleichtert. Zu betonen ist: Ein solches Modul unterstützt den Meldeprozess, ersetzt aber für sich genommen kein vollständiges NIS2-Compliance-Programm.

Kehrt der Verkehr zum Profil vor dem Angriff zurück, sollten die Filterregeln automatisch zurückgenommen werden. Blackholing oder enge FlowSpec-Regeln ohne Grund länger als nötig aufrechtzuerhalten, belastet die Infrastruktur und erschwert die Diagnose weiterer, nicht damit zusammenhängender Ereignisse.

Wirksamer DDoS-Schutz ist keine einzelne Funktion, sondern eine Kette von Entscheidungen, die innerhalb von Sekunden getroffen werden: Verkehrsprofil, Erkennung, Klassifizierung, Lernen des Angriffsmusters, Wahl zwischen FlowSpec und Blackholing, Verteilung der Regeln, Aufrechterhaltung einer an den sich ändernden Vektor angepassten Filterung und schließlich die Rücknahme der Mitigation. Jedes Glied dieser Kette, das langsamer oder weniger präzise arbeitet, führt zu einer längeren Nichtverfügbarkeit des Dienstes oder zu einem größeren Umfang blockierten legitimen Verkehrs.

Eine vollständige Beschreibung der Architektur, der BGP-Konfiguration und der Filtermechanismen finden Sie in der technischen Dokumentation: docs.liveshield.net. Die Funktionsweise des Systems lässt sich außerdem unverbindlich in der Demoversion prüfen: demo.liveshield.net.