utomatisierung der Reaktion auf DDoS-Angriffe: Was nach der Erkennung eines Angriffs geschieht

Gespräche über Anti-DDoS-Schutz drehen sich meist um eine Frage: wie schnell das System einen Angriff erkennt und eine Filterregel anlegt. Diese Frage ist berechtigt, doch für das NOC-Team eines Betreibers ist die Sache damit selten erledigt. Eine erzeugte FlowSpec-Regel oder ein Blackholing ist in der Regel der Anfang des Verfahrens, nicht das Ende. Jemand muss benachrichtigt werden, der Vorfall muss protokolliert werden, manchmal muss der Kunde auf eine andere IP-Adresse umgeschaltet werden, manchmal muss ein Skript auf dem Edge-Gerät gestartet werden.

In vielen Netzen führt diese Schritte ohnehin ein Mensch aus. Er erhält einen Alarm, loggt sich in ein Panel ein, prüft, was passiert ist, und startet erst dann das Verfahren. Bei einem Angriff, der nur einige Dutzend Sekunden dauert, ist diese Verzögerung oft länger als die Zeit für Erkennung und Filterung zusammen.

Im Moment der Erkennung eines Angriffs verfügt das Anti-DDoS-System über alle Informationen, die für die weiteren Schritte nötig sind: Es kennt die IP-Adresse des Opfers, die Protokolle, die Größenordnung des Verkehrs und den genauen Moment der Schwellenwertüberschreitung. Die Frage ist, ob dieses Wissen mit der Erzeugung der Filterregel endet oder ob sich damit sofort mehr auslösen lässt.

In LiveShield dient dazu die Event Pipeline: eine Reihe von Aktionen, die an konkrete Ereignisse im Lebenszyklus eines Angriffs geknüpft sind, zum Beispiel „Blackholing started“ oder „Blackholing stopped“. An jedes dieser Ereignisse lässt sich der Aufruf eines eigenen Skripts, mit der angegriffenen IP-Adresse als Parameter, oder ein Webhook an eine angegebene URL anhängen.

Eine typische Konfiguration sieht so aus:

Für ein Präfix sind pps-/bps-Schwellenwerte gesetzt. Werden sie überschritten, erkennt das System einen Angriff mit bestimmten Protokollen und erzeugt FlowSpec-Regeln. Parallel werden höhere Schwellenwerte aus dem Blackholing-Profil geprüft, die sich summarisch pro IP oder getrennt für einzelne Protokolle setzen lassen. Werden auch diese höheren Schwellenwerte überschritten, wird das Blackholing ausgelöst.

Und hier greift die Pipeline. Im Moment des Blackholing-Aufrufs startet ein an das Ereignis „Blackholing started“ gebundenes Skript. Das kann zum Beispiel der Wechsel der IP-Adresse des Kunden auf eine Ersatzadresse sein. Lässt der Angriff nach und wird das Blackholing aufgehoben, löst das Ereignis „Blackholing stopped“ die umgekehrte Aktion aus, also die Wiederherstellung der ursprünglichen Adresse.

Dasselbe Schema funktioniert bei der Integration mit einem Scrubbing-Center. Statt den Verkehr lokal zu filtern, kann die Pipeline ihn bei der Eskalation des Angriffs an einen externen Reinigungspunkt umleiten und nach deren Ende zum Standard-Routing zurückkehren.

Die Trennung der Erkennungsschwellenwerte von den Blackholing-Schwellenwerten hat einen praktischen Sinn. Der niedrigere Schwellenwert löst eine präzise FlowSpec-Regel aus, die den Verkehr nach konkreten Parametern filtert: Protokoll, Port, Flags. Erst nach Überschreiten des zweiten, höheren Schwellenwerts erfolgt das Blackholing des gesamten Präfixes. Die meisten Angriffe, die kleineren und besser vorhersehbaren, werden ohne Verlust legitimen Verkehrs bewältigt. RTBH bleibt das Mittel für Situationen, in denen das weitere Aufrechterhalten des Verkehrs zu einer bestimmten Adresse die Stabilität des gesamten Netzes zu gefährden beginnt.

Für Adressen mit einem anderen Risikoprofil, etwa Dienstserver, die eine höhere Verfügbarkeit haben müssen, lassen sich dieselben Mechanismen separat konfigurieren. Es genügt, sie als spezifischeres Subnetz mit einem eigenen Satz von Schwellenwerten hinzuzufügen.

Nehmen Sie ein System zum Schutz vor DDoS-Angriffen in Ihrer Infrastruktur in Betrieb. Kontaktieren Sie uns: office@liveshield.net