LiveShield und Scrubbing Center - wie lokaler DDoS-Schutz und Scrubbing Center sich gegenseitig ergänzen können

LiveShield und ein Scrubbing Center sind keine Lösungen, zwischen denen sich ein Betreiber ein für alle Mal entscheiden muss - es handelt sich um zwei verschiedene Schutzebenen gegen DDoS, die in unterschiedlichen Situationen greifen und zusammenarbeiten können: LiveShield filtert die meisten Angriffe lokal, in Echtzeit und ohne zusätzliche Verzögerung, während das Scrubbing Center jene Fälle übernimmt, in denen die lokale Filterung nicht mehr ausreicht - etwa bei einem Angriff, der die Uplink-Kapazität übersteigt, oder bei Angriffen, die eine tiefergehende, zustandsbehaftete (stateful) Verkehrsanalyse erfordern.

Diese Frage stellt sich zunehmend bei ISP-Betreibern, die bereits ein eigenes Scrubbing Center in Erwägung ziehen oder aufbauen, und sich fragen, ob dies einen Verzicht auf den lokalen Schutz bedeutet oder vielmehr dessen Erweiterung.

Ein Scrubbing Center ist eine externe Infrastruktur, an die im Angriffsfall der auf die Zieladresse gerichtete Traffic umgeleitet wird - dort wird er von den Angriffspaketen bereinigt, und erst der „saubere" Traffic kehrt zum Zielnetz zurück. On-Premise-Schutz, wie LiveShield, funktioniert umgekehrt: Analyse und Filterung erfolgen lokal, auf der Hardware des Betreibers, ohne Umleitung des Traffics nach außen.

Jedes dieser Modelle hat ein anderes Kosten- und Latenzprofil. Die Umleitung des Traffics zum Scrubbing Center führt zu einem zusätzlichen Hop im Pfad (Routing über eine externe Infrastruktur), der bei latenzsensiblen Diensten auch über die Dauer des Angriffs hinaus relevant sein kann, sofern die Umleitung dauerhaft besteht. Die lokale Filterung führt diesen zusätzlichen Schritt nicht ein - legitimer Traffic folgt seinem normalen Pfad und wird nur dann und nur dort verändert, wo tatsächlich ein Angriff erkannt wurde.

Andererseits verfügt ein Scrubbing Center über eine Ressource, die ein einzelner lokaler Betreiber in der Regel nicht besitzt - eine deutlich größere, aggregierte Bandbreite, die einen Angriff absorbieren kann, der die Kapazität einer einzelnen Uplink-Verbindung übersteigt.

Die überwiegende Mehrheit der DDoS-Angriffe, mit denen ISP-Betreiber konfrontiert sind, erfordert keine Umleitung des Traffics nach außen - eine präzise, schnelle lokale Filterung genügt, die LiveShield über BGP FlowSpec realisiert und durch Blackholing (RTBH) ergänzt, wenn die lokale Filterung für eine bestimmte Verbindung nicht mehr ausreicht. Jeden noch so kleinen Angriff zu einem externen Scrubbing Center zu leiten, wäre ineffizient - es entstehen Verzögerung und Kosten genau dort, wo eine lokale FlowSpec-Regel ebenso wirksam und schneller wäre.

Ein Scrubbing Center ist als zweite Schutzebene sinnvoll, die selektiv aktiviert wird - für jene Minderheit von Fällen, in denen die lokale Filterung tatsächlich nicht ausreicht: vor allem bei Angriffen, die die Uplink-Kapazität übersteigen, sowie bei Angriffen, die eine zustandsbehaftete Verkehrsanalyse erfordern, die über das hinausgeht, was mit FlowSpec-Regeln auf der Edge-Hardware des Betreibers realisierbar ist.

LiveShield arbeitet standardmäßig nicht im Scrubbing-Center-Modell - es leitet den Traffic nicht standardmäßig zur Reinigung nach außen um, sondern mitigiert Angriffe lokal, auf den eigenen Edge-Routern des Betreibers, mittels FlowSpec und RTBH. Das System bietet jedoch einen Event-Pipeline-Mechanismus, also die Möglichkeit, beliebige Aktionen und Skripte als Reaktion auf einen erkannten Angriff auszuführen.

Hat der Betreiber einen Vertrag mit einem externen Scrubbing Center, lässt sich LiveShield entsprechend konfigurieren, sodass es unter bestimmten Bedingungen - etwa wenn ein Angriff einen definierten Traffic-Schwellenwert überschreitet, den die lokale Filterung nicht mehr wirksam bewältigen kann - automatisch die Umleitung des betreffenden Präfixes an dieses Scrubbing Center auslöst. Es handelt sich dabei nicht um eine fertige „Out-of-the-box"-Integration für einen beliebigen Scrubbing-Anbieter - sie erfordert eine auf die jeweilige Umgebung und den konkreten Partnervertrag abgestimmte Konfiguration -, aber die Funktionalität der Event Pipeline erlaubt dies grundsätzlich vollständig.

In der Praxis bedeutet dies eine Rollenaufteilung: LiveShield ist für die Erkennung des Angriffs, die erste, schnelle Mitigationsentscheidung und - falls nötig - die Weiterleitung des Signals zuständig, während das Scrubbing Center erst dann eingreift, wenn es tatsächlich benötigt wird, statt der erste und einzige Anlaufpunkt für jeden Traffic zu sein.

Eine Architektur, die lokale Filterung mit einem Backup-Kanal zum Scrubbing Center kombiniert, ist vor allem dort sinnvoll, wo ein Betreiber gleichzeitig volle Kontrolle und minimale Latenz für normalen Traffic und die meisten Angriffe bewahren möchte, aber auch mit dem Szenario eines Angriffs rechnet, der die Kapazität der eigenen Uplink-Verbindungen übersteigt. Genau in dieser Situation befinden sich heute viele kleinere und mittlere ISP-Betreiber angesichts der wachsenden Größenordnung volumetrischer Angriffe - daher rühren auch Initiativen zum Aufbau gemeinsamer, community-basierter Scrubbing Center an Internet-Knotenpunkten.

Für einen Betreiber, der gerade erst mit dem Aufbau von DDoS-Schutz beginnt, ist die sinnvolle Reihenfolge üblicherweise: zunächst lokale, schnelle Filterung (FlowSpec/RTBH), die die überwiegende Mehrheit realer Angriffe abdeckt, und erst danach, je nach Bedarf und Skalierung, die Erweiterung um einen Scrubbing-Center-Vertrag als Absicherung gegen Angriffe, die die lokale Kapazität übersteigen.

LiveShield und ein Scrubbing Center konkurrieren nicht miteinander, sondern decken unterschiedliche Schutzebenen gegen DDoS ab: die lokale, schnelle FlowSpec/RTBH-Filterung bewältigt die überwiegende Mehrheit der Angriffe ohne zusätzliche Verzögerung und Umleitungskosten, während das Scrubbing Center eine Reserveebene für Angriffe darstellt, die die Möglichkeiten der lokalen Infrastruktur übersteigen. Der Event-Pipeline-Mechanismus in LiveShield erlaubt es, beide Ansätze zu einer kohärenten Architektur zu verbinden - die automatische Umleitung zum Scrubbing Center wird erst dann ausgelöst, wenn sie tatsächlich benötigt wird, und nicht als Standardpfad für jeden Traffic.

Ersetzt LiveShield ein Scrubbing Center? Nein, das ist nicht seine Rolle. LiveShield mitigiert Angriffe standardmäßig lokal, auf den Edge-Routern des Betreibers, mittels FlowSpec und RTBH - das ist ein anderes, ergänzendes Modell zum Scrubbing Center, kein Ersatz für jedes Szenario.

Kann LiveShield mit einem externen Scrubbing Center verbunden werden? Ja. Der Event-Pipeline-Mechanismus erlaubt es, die automatische Umleitung des Traffics an ein externes Scrubbing Center als Reaktion auf einen erkannten Angriff zu konfigurieren, sofern der Betreiber einen entsprechenden Vertrag hat - dies erfordert eine individuelle, auf die jeweilige Umgebung abgestimmte Konfiguration.

Wann sollte man neben dem lokalen DDoS-Schutz ein Scrubbing Center in Betracht ziehen? Vor allem dann, wenn der Betreiber mit dem Szenario eines Angriffs rechnet, der die Kapazität der eigenen Uplink-Verbindung übersteigt - in einem solchen Fall kann die lokale Filterung die Verbindung physisch nicht entlasten, und die Lösung ist entweder RTBH zum Upstream-Provider oder die Umleitung zu einem Scrubbing Center.

Sollte jeder Angriff zu einem Scrubbing Center geleitet werden? Nein. Die überwiegende Mehrheit der DDoS-Angriffe lässt sich wirksam und schneller durch lokale FlowSpec-Filterung bewältigen, ohne die zusätzliche Verzögerung durch eine Umleitung des Traffics nach außen. Ein Scrubbing Center ist als selektive Reserveebene sinnvoll, nicht als Standardpfad für jeden Traffic.