DDoS-Schutz im Betreibernetz: Auswahlkriterien

Die Entscheidung zur Einführung von DDoS-Schutz fällt selten unter ruhigen Bedingungen. Meist geht ihr ein Vorfall voraus: ein Angriff, der die Leitung verstopft oder die Kundenbetreuung für mehrere Stunden lahmgelegt hat. Unter Zeitdruck ist es leicht, eine Wahl zu treffen, die eher von den Marketingmaterialien des Anbieters als von den realen Bedürfnissen des Netzes bestimmt ist. Das Ergebnis ist mitunter ein System, das im Angebot gut aussieht, aber nicht zur Architektur des Betreibers passt oder Kosten verursacht, mit denen niemand gerechnet hat.

Nachfolgend haben wir die Kriterien zusammengestellt, die man vor der Entscheidung prüfen sollte, und zeigen, wie LiveShield im Vergleich dazu abschneidet.

Die erste Frage, die man sich stellen sollte, lautet: Wo finden Analyse und Filterung des Verkehrs tatsächlich statt? Ein Teil der Lösungen arbeitet On-Premise, direkt in der Infrastruktur des Betreibers: Der gesamte Verkehr bleibt im Netz, und die Filterentscheidungen fallen lokal. Andere leiten den Verkehr nach außen um, in ein vom Anbieter betriebenes Scrubbing-Center.

Der Unterschied ist nicht nur architektonisch. Die Umleitung des Verkehrs bedeutet zusätzliche Latenz, Abhängigkeit von der Verfügbarkeit eines externen Dienstes und Transferkosten, die bei einem großen volumetrischen Angriff überraschen können.

LiveShield ist als On-Premise-System konzipiert: Es wird direkt in der Infrastruktur des Betreibers installiert, ohne den Verkehr nach außen umzuleiten. Analyse und Mitigation finden lokal statt, was zusätzliche Latenz und die Abhängigkeit von einem externen Dienst beseitigt, und der Verkehr bleibt jederzeit unter der Kontrolle des Betreibers.

Ein Anti-DDoS-System, das sich nicht nativ in Ihr BGP integriert, ist ein System, das zusätzliche Integrationsarbeit erfordert. Man sollte prüfen, ob die Lösung einen eigenen BGP-Daemon hat oder von externer Software abhängt und ob sie sowohl BGP FlowSpec als auch RTBH (Remotely Triggered Blackholing) unterstützt.

FlowSpec erlaubt präzise, granulare Filterregeln, die direkt an die Edge-Router angekündigt werden, ohne manuelle ACL-Konfiguration. Blackholing ist ein einfacherer, gröberer Mechanismus, der wirksam ist, wenn eine angegriffene Adresse sofort abgeschnitten werden muss, auf Kosten ihrer vollständigen Nichterreichbarkeit.

LiveShield hat einen eigenen BGP-Daemon und unterstützt beide Mechanismen, FlowSpec und selektives RTBH, und wählt je nach Charakter des Angriffs den passenden, ohne dass der Betreiber manuell konfigurieren muss. Die Lösung ist auf der Hardware getestet, mit der die meisten ISPs in Polen arbeiten: Juniper-Routern (MX, PTX) sowie Cisco (ASR1k, ASR9k, NCS5500 in den SE-Varianten, Serie 8000). Das ist keine Konformitätserklärung mit dem Standard „auf dem Papier“, sondern eine Liste von Hardware, auf der die Konfiguration tatsächlich geprüft wurde.

Klassische Erkennung, die sich auf eine einzelne IP-Adresse konzentriert, kommt mit einem einfachen volumetrischen Angriff gut zurecht, verliert sich aber bei Angriffen vom Typ Carpet Bombing, die gleichzeitig auf viele Adressen oder ein ganzes Subnetz verteilt sind und bei denen der Verkehr auf jede einzelne IP für sich harmlos aussieht. Das ist ein immer häufigerer Vektor, weil er Mechanismen, die für ein einzelnes Ziel ausgelegt sind, wirksam umgeht.

LiveShield erkennt Angriffe sowohl pro IP als auch pro Subnetz und aggregiert auf viele Adressen verteilte Angriffe automatisch zu einer möglichst engen Filterregel, um die Auswirkungen auf Verkehr, der nicht Teil des Angriffs ist, zu begrenzen. Ein Anti-Overload-Mechanismus schützt zusätzlich das Erkennungssystem selbst vor Überlastung bei einer großen Zahl gleichzeitiger Vorfälle.

Betreiber, die dem Gesetz über das Nationale Cybersicherheitssystem unterliegen, sind zu einer dreistufigen Meldung eines schwerwiegenden Vorfalls an das zuständige CSIRT verpflichtet: Frühwarnung innerhalb von 24 Stunden nach Erkennung, vollständige Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats nach der Meldung. In der Praxis bedeutet das, dass während eines Angriffs jemand gleichzeitig operativ reagieren und Dokumentation gemäß diesen Fristen vorbereiten muss.

Das Berichtsmodul von LiveShield erzeugt eine fertige Zusammenstellung der Angriffsdaten, also Dauer, Vektor, Umfang und ergriffene Mitigationsmaßnahmen, in einer Form, die sich sofort bei der Vorbereitung der Meldung an das CSIRT verwenden lässt. Das verkürzt real die für die Dokumentation benötigte Zeit im 24-Stunden-Fenster, in dem jede Stunde zählt.

Man sollte es jedoch ehrlich benennen: Ein Modul, das Daten für den Bericht liefert, ist nicht dasselbe wie ein fertiges Compliance-Werkzeug. Die abschließende Bewertung der Konformität mit dem KSC und die Vorbereitung der Meldung bleiben beim Betreiber. LiveShield entlastet das Team im kritischen Moment, ersetzt aber nicht die regulatorische Verantwortung.

Die nächste Frage ist, worauf das System überhaupt laufen soll. Ein Teil der Lösungen erfordert eine dedizierte, geschlossene Appliance, was starre Einstiegskosten und mangelnde Flexibilität bei der Skalierung bedeutet. Andere laufen auf Standard-Serverhardware, sofern diese bestimmte Mindestanforderungen erfüllt.

LiveShield läuft auf Standard-x86-Hardware mit DPDK-Unterstützung, ohne dass in eine dedizierte Appliance investiert werden muss. Das Modul für die Paketverarbeitung in Echtzeit (Worker) erfordert eine physische Maschine, es ist die einzige Komponente mit dieser Anforderung. Die beiden übrigen Module, Manager und Analyser, können virtuell laufen, was die Anpassung der Einführung an die vorhandene Infrastruktur des Betreibers erleichtert.

Orientierende Hardware-Mindestanforderungen: Anzahl physischer Kerne nach der Formel Gbps ÷ 10 + 4 (nicht weniger als 8 Kerne), 32 GB+ RAM, NVMe-Festplatte ab 60 GB sowie eine DPDK-kompatible Netzwerkkarte. Empfohlene Modelle sind Intel X710, XXV710, E810 oder X520, gegebenenfalls Mellanox-ConnectX-Karten. Keine Abhängigkeit von einem einzelnen Hardwarehersteller.

Die Abrechnungsmodelle unterscheiden sich stark zwischen den Anbietern. Ein Teil rechnet nach der Netzwerkbandbreite ab: ein Parameter, ein Preis, alle Funktionen inklusive. Andere verwenden modulare Lizenzierung, bei der erweiterte Filterung, FlowSpec-Unterstützung oder Berichte eigene Kostenpositionen sind, die separat zugekauft werden.

Die LiveShield-Lizenz ist ausschließlich an den eingehenden Verkehr (Gbps) gebunden, ohne Aufteilung in Module, ohne Zusatzgebühren für FlowSpec, erweiterte Filterung oder Berichte. Die volle Funktionalität des Systems ist in einem Preis enthalten, was die Kostenplanung bei wachsendem Verkehr im Netz erleichtert.

Das letzte, oft übersehene Element ist das, was nach Vertragsunterzeichnung geschieht. Bietet der Anbieter Beratung während der eigenständigen Einführung an? Gibt es die Möglichkeit, die Lösung vor dem Kauf mit realem Verkehr zu testen? Wie sieht in der Praxis die Reaktionszeit auf technische Fragen aus, besonders auf jene, die bei der ersten Konfiguration der Erkennungsschwellenwerte gestellt werden, wenn falsche Einstellungen Fehlalarme oder, schlimmer, einen durchgelassenen Angriff bedeuten können?

Im Lizenzpreis von LiveShield bieten wir kostenlose Beratung während der Einführung sowie die Überprüfung der Korrektheit der Konfiguration durch unseren Ingenieur an. Außerdem steht eine Demolizenz zur Verfügung, um das System vor der Kaufentscheidung mit realem Verkehr zu testen.

Vor der Entscheidung sollte man auf jede der folgenden Fragen eine Antwort haben:

Auf jede dieser Fragen hat LiveShield eine konkrete, überprüfbare Antwort, und nicht nur eine Konformitätserklärung mit dem Standard.

Vollständige technische Dokumentation: docs.liveshield.net.
Technische Fragen: office@liveshield.net