Was passiert, wenn ein DDoS-Angriff die Bandbreite der Uplink-Verbindung übersteigt?

Übersteigt ein DDoS-Angriff die Bandbreite der Uplink-Verbindung, kann keine beim Betreiber lokal ausgeführte Filterung Abhilfe schaffen: Die Leitung ist bereits physisch gesättigt, bevor der Verkehr das Filtergerät erreicht. In einer solchen Situation ist der einzige wirksame Mechanismus RTBH (Remotely Triggered Black Hole), der in Richtung des Transit-Betreibers angekündigt wird und den Verkehr verwirft, noch bevor er auf die Leitung des Kunden gelangt.

Das ist eine der ersten Fragen in Gesprächen mit ISPs und Rechenzentrumsbetreibern über die Einführung von DDoS-Schutz, und zu Recht: Es ist kein theoretisches Szenario, sondern Alltag in Netzen, die Teilnehmerverkehr und Hosting bedienen.

Anti-DDoS-Systeme auf Basis von BGP FlowSpec, darunter LiveShield, analysieren den Verkehr und erzeugen präzise Filterregeln, die auf den Edge-Routern des Betreibers installiert werden. Dieser Mechanismus funktioniert sehr gut, solange das Problem die Art des Verkehrs ist und nicht seine Menge im Verhältnis zur verfügbaren Bandbreite.

Der kritische Punkt sieht so aus: FlowSpec wird lokal angekündigt, auf Routern, die sich bereits hinter der Uplink-Verbindung befinden. Erzeugt der Angriff mehr Verkehr, als die Leitung physisch transportiert, erreicht ein Teil dieses Verkehrs den Router mit der installierten FlowSpec-Regel nie: Die Leitung wird vorher gesättigt, unabhängig davon, wie präzise die Filterregel ist.

Anders gesagt: FlowSpec löst das Problem der Verkehrsqualität auf der Leitung, nicht das Problem der Verkehrsmenge oberhalb der Leitungsbandbreite.

In einem Szenario, in dem das Angriffsvolumen die Bandbreite des Uplinks übersteigt, ist der einzige Mechanismus, der die Leitung tatsächlich entlastet, RTBH (Remotely Triggered Black Hole), das nicht auf den eigenen Routern, sondern in Richtung des Transit-Betreibers (Upstream) angekündigt wird.

RTBH funktioniert nach einem völlig anderen Prinzip als FlowSpec: Statt konkrete Pakete präzise zu filtern, teilt es dem Netz des Transit-Betreibers mit, dass der gesamte an eine bestimmte IP-Adresse (meist /32) gerichtete Verkehr verworfen werden soll, noch bevor er auf die Leitung des Kunden gelangt. Das ist eine brachiale Lösung, denn sie schneidet auch legitimen Verkehr zur selben Adresse ab, aber sie ist dort wirksam, wo FlowSpec physisch keine Chance hat.

LiveShield erzeugt RTBH-Regeln automatisch auf Basis derselben Erkennungsschwellenwerte, die auch für FlowSpec zuständig sind, und kündigt sie über eine BGP-Session an, die mit dem Router des Betreibers konfiguriert ist. Entscheidend ist jedoch, dass die Wirksamkeit dieses Mechanismus davon abhängt, was danach geschieht, nämlich wie schnell und auf welche Weise der Transit-Betreiber auf diese Ankündigungen reagiert.

Da die endgültige Wirksamkeit von RTBH vom Upstream abhängt, entscheidet sich der Vorteil eines Anti-DDoS-Systems in der Phase, die der Betreiber tatsächlich kontrolliert: wie schnell der Angriff erkannt wird und wie schnell die korrekte RTBH-Regel beim Transit-Betreiber ankommt. Je kürzer diese Zeit, desto kürzer das Fenster, in dem die Leitung gesättigt bleibt, bevor der Upstream reagieren kann.

LiveShield analysiert den Verkehr Paket für Paket, in Echtzeit und im Arbeitsspeicher, statt sich auf aggregierte NetFlow- oder sFlow-Daten zu stützen, die naturgemäß ein Lagebild mit einer Verzögerung von einigen zehn Sekunden bis zu einigen Minuten liefern. In der Praxis bedeutet das, dass ein Angriff erkannt und die ersten Schutzregeln innerhalb von einzelnen Sekunden nach seinem Beginn erzeugt werden, und nicht erst im Nachhinein, wenn die Leitung schon längere Zeit gesättigt ist.

Das zweite Element, das die Reaktionszeit verkürzt, ist die Automatisierung. Der Event-Pipeline-Mechanismus erlaubt es, im Voraus genau festzulegen, was im Moment der Erkennung eines Angriffs, der einen bestimmten Schwellenwert überschreitet, geschehen soll: RTBH erzeugen und ankündigen, das NOC-Team benachrichtigen, ein externes Skript aufrufen (das z. B. Scrubbing startet) oder das Ereignis in ein Ticketsystem schreiben. Der Betreiber reagiert nicht manuell im Nachhinein, sondern hat ein fertiges, zuvor getestetes Szenario, das von selbst abläuft.

Für Betreiber, die bereits einen Vertrag mit einem externen Scrubbing-Center haben (oder planen), erlaubt die Event Pipeline von LiveShield, die Angriffserkennung mit einer automatischen Umleitung des Verkehrs in ein solches Center zu verknüpfen, statt die Adresse ausschließlich per RTBH zu blockieren. Das ist keine fertige Integration ab Werk: Sie erfordert eine Konfiguration für die konkrete Netztopologie und den konkreten Scrubbing-Anbieter, doch die Funktionalität der Event Pipeline erlaubt dies. LiveShield kann daher die Rolle der Erkennungs- und Entscheidungsschicht auch in einer Architektur übernehmen, die letztlich nicht bei RTBH endet.

Diese Unterscheidung sollte man vor der Einführung jedes Anti-DDoS-Systems verstehen, nicht nur von LiveShield: Das lokale System ist für die Erkennung des Angriffs und die Erzeugung einer korrekten RTBH-Regel zuständig. Wie schnell diese Regel den Verkehr vor dem Eintritt auf die Leitung tatsächlich abschneidet, hängt von der Konfiguration und der Richtlinie des Transit-Betreibers ab, nicht vom Anti-DDoS-System.

In der Praxis bedeutet das: Vor der Einführung von Schutz gegen volumetrische Angriffe, die die Kapazität der Leitung übersteigen, sollte der ISP direkt mit seinem Transit-Anbieter klären:

Ohne dieses Gespräch mit dem Upstream kann das Anti-DDoS-System korrekt arbeiten, also den Angriff erkennen und die Regel zur richtigen Zeit erzeugen, und dennoch die Leitung nicht schützen, wenn der Upstream die erhaltenen Ankündigungen nicht berücksichtigt oder zu langsam darauf reagiert.

Es gibt keine lokale Alternative. Übersteigt das Angriffsvolumen die Bandbreite der Uplink-Verbindung, besteht der einzige Weg darin, den Verkehr näher an der Quelle abzuschneiden, also auf der Seite des Transit-Betreibers oder noch weiter entfernt bei den nächsten Anbietern in der Kette. Lösungen, die ausschließlich lokal beim Kunden arbeiten, sind, unabhängig von Hersteller und Filtermechanismus, physisch nicht in der Lage, Verkehr zu verarbeiten, der nicht auf die Leitung passt.

Deshalb sollte man beim Entwurf des Anti-DDoS-Schutzes für ISP-Netze RTBH zum Upstream von Anfang an als integralen Bestandteil der Architektur behandeln und nicht als Ersatzmechanismus, der nur in Ausnahmefällen ausgelöst wird.

Ein DDoS-Angriff, der die Bandbreite der Uplink-Verbindung übersteigt, ist ein Szenario, in dem die lokale Verkehrsfilterung (FlowSpec) nicht mehr ausreicht, weil die Leitung gesättigt wird, bevor der Verkehr das Filtergerät erreicht. Der einzige wirksame Mechanismus ist in dieser Situation RTBH, das an den Transit-Betreiber angekündigt wird, und seine tatsächliche Wirksamkeit hängt von der Richtlinie und der Reaktionsgeschwindigkeit dieses Betreibers ab. Deshalb sollten Absprachen mit dem Transit-Anbieter Teil der Vorbereitung auf die Einführung von DDoS-Schutz sein und nicht ein Element, das bis zum ersten großen Angriff übergangen wird.

Stoppt FlowSpec einen Angriff, der größer ist als meine Uplink-Verbindung? Nein. FlowSpec wird auf den Routern des Kunden angekündigt, die sich bereits hinter der Uplink-Verbindung befinden. Sättigt der Angriff diese Leitung, erreicht ein Teil des Verkehrs die Filterregel nie.

Was ist RTBH und wie unterscheidet es sich von FlowSpec? RTBH (Remotely Triggered Black Hole) ist ein Mechanismus, der den gesamten an eine bestimmte IP-Adresse gerichteten Verkehr abschneidet und an den Transit-Betreiber angekündigt wird, sodass der Verkehr noch vor dem Eintritt auf die Leitung des Kunden verworfen wird. Im Gegensatz zu FlowSpec filtert es nicht präzise, sondern blockiert die Adresse vollständig, samt legitimem Verkehr.

Berücksichtigt jeder Transit-Betreiber RTBH-Ankündigungen? Das hängt vom jeweiligen Transit-Anbieter ab und muss direkt mit ihm geklärt werden, einschließlich der akzeptierten BGP-Community und der Reaktionszeit auf die Ankündigung.