DDoS-Schutz im Netz eines Betreibers: Wie ein Anti-DDoS-System in der Praxis funktioniert

Ein DDoS-Angriff in einem Betreibernetz sieht selten so aus, wie ihn die Marketingmaterialien von Cloud-Anbietern darstellen. Es ist kein einzelner Vorfall auf einem einzelnen Server, sondern ein Problem auf der Ebene der Leitung, des Edge-Routers und des gesamten Adresspools der Kunden. Für einen ISP, ein Rechenzentrum oder einen Telekommunikationsbetreiber lautet die Frage nicht „ob es uns trifft“, sondern „was passiert, wenn 20 Gbps Müllverkehr mitten in der Nacht auf unserem Upstream eintreffen“. Dieser Artikel bietet einen praxisnahen Blick auf den DDoS-Schutz aus der Perspektive eines Betreibernetzes: welche Angriffsarten es gibt, wie Anti-DDoS auf Infrastrukturebene tatsächlich aussieht und warum ein Anti-DDoS-System, das On-Premise auf eigener Hardware läuft, für einen Betreiber eine andere Begründung hat als für ein einzelnes Unternehmen mit einer Website.

Ein DDoS-Angriff ist ein verteilter Denial-of-Service-Angriff: Verkehr, der gleichzeitig aus vielen Quellen erzeugt wird und darauf abzielt, Ressourcen zu erschöpfen, also Bandbreite, Verbindungstabelle oder CPU auf Edge-Geräten. Bei einem einzelnen Unternehmen ist das Opfer meist eine IP-Adresse oder eine Domain. Im Netz eines Betreibers hat das Problem eine andere Dimension: Ein Angriff kann eine einzelne Adresse aus dem Pool eines Kunden treffen und dennoch die gesamte Upstream-Leitung sättigen, sodass allen übrigen am selben Übergabepunkt angeschlossenen Kunden die Bandbreite entzogen wird. Dieses Phänomen, manchmal als „Collateral Damage“ bezeichnet, ist für einen ISP gravierender als die bloße Nichterreichbarkeit eines Dienstes, denn dafür zahlt das gesamte Netz und nicht nur der angegriffene Kunde.

Das zweite betreiberspezifische Problem ist das sogenannte Carpet Bombing: ein Angriff, bei dem der Verkehr auf viele IP-Adressen eines Subnetzes oder des gesamten Kundenblocks verteilt wird, sodass keine einzelne Adresse den Alarmschwellenwert überschreitet, die Summe des Verkehrs auf das gesamte Subnetz aber dennoch die Leitung überflutet. Klassische Systeme, die den Verkehr pro IP-Adresse überwachen, erkennen ein solches Muster nicht. Erforderlich ist eine Aggregation auf Präfixebene.

Volumetrische Angriffe sind am einfachsten zu verstehen und weiterhin am häufigsten. Ihr Ziel ist die Sättigung der Bandbreite: UDP-Flood, DNS-Amplification, NTP oder andere Reflection-/Amplification-Techniken, bei denen der Angreifer eine kleine Anfrage mit gefälschter Absenderadresse des Opfers sendet und die Antwort um ein Vielfaches größer zurückkommt. Die Abwehr dieser Angriffsart muss am Übergang zum Upstream ansetzen, bevor der Verkehr überhaupt ins Netz des Betreibers gelangt. Daher die Bedeutung von Mechanismen wie BGP FlowSpec und Blackholing.

Protokollangriffe zielen auf den Verbindungszustand, nicht auf die Bandbreite selbst. Ein klassischer SYN-Flood kann einen Router oder Server bei relativ geringem Verkehrsvolumen lahmlegen, weil er die Verbindungstabelle erschöpft und nicht die Leitung. Genau diese Angriffsart ist oft am heimtückischsten: Der Alarm auf Volumenbasis löst möglicherweise nicht aus, und der Dienst antwortet bereits nicht mehr.

Immer häufiger tritt auch eine Variante auf, die einen zustandsbehafteten Protokollangriff mit dem Versuch verbindet, den klassischen volumetrischen Schutz zu umgehen: eine Welle von SYN-ACK-, ACK- oder RST-Paketen ohne entsprechendes ausgehendes SYN, direkt auf den BRAS-/Konzentrator-Übergang gerichtet. Das Volumen ist manchmal zu gering, um eine Reaktion eines ausschließlich auf Verkehrsschwellenwerten basierenden Systems auszulösen, und kann dennoch den Verbindungszustand auf den Zugangsgeräten verstopfen.

Wirksamer DDoS-Schutz für einen Betreiber beruht auf mehreren einander ergänzenden Mechanismen und nicht auf einer einzigen universellen Lösung.

Erkennung durch Verkehrsanalyse. Ein Anti-DDoS-System muss den Verkehr sehen, um etwas zu erkennen, meist über einen SPAN-Port oder einen optischen Link-TAP, ausschließlich im Empfangsmodus aus Richtung Upstream, ohne Eingriff in den Paketpfad. Dadurch birgt die Erkennung kein Risiko für den Produktivverkehr: Fällt das Erkennungssystem selbst aus, läuft das Netz normal weiter.

Mitigation über BGP FlowSpec. Erkennt das System einen Angriff, erzeugt es FlowSpec-Regeln und übergibt sie über eine BGP-Session an den Edge-Router des Betreibers. Der Router programmiert die Regeln in die Hardware und filtert den Verkehr in einem frühen Stadium, bevor er die übrige Infrastruktur belastet. Diese Lösung arbeitet lokal zwischen dem Anti-DDoS-System und den eigenen Routern des Betreibers. Sie erfordert keine FlowSpec-Unterstützung durch den Upstream-Anbieter, es genügt, dass der Upstream die standardmäßigen Blackholing-Communitys berücksichtigt. Voraussetzung ist Hardware mit FlowSpec-Unterstützung in der Hardware; die bewährte Liste umfasst u. a. Juniper MX/PTX sowie Cisco ASR1k/9k/NCS5500 SE/8000. Bei anderer Hardware, z. B. Huawei, sollte Standard-RTBH funktionieren, die FlowSpec-Unterstützung muss jedoch pro Modell geprüft werden.

Blackholing und selektives RTBH. Wo FlowSpec nicht ausreicht, weil der Angriff die Möglichkeiten der Upstreams übersteigt oder die Hardware ihn nicht unterstützt, bleibt RTBH, also die Umleitung des Verkehrs zur angegriffenen Adresse in eine Null-Route. Der Unterschied zwischen einfachem Blackholing eines ganzen Subnetzes und selektivem Blackholing einzelner /32-Adressen ist für einen Betreiber entscheidend: Die zweite Variante erlaubt es, nur die tatsächlich angegriffene Adresse abzuschneiden, statt den gesamten Pool des Kunden zu opfern, einschließlich der Adressen, die gar nicht Ziel des Angriffs sind.

Schutz vor Carpet Bombing. Erfordert eine Aggregation des Verkehrs auf Präfixebene und nicht pro einzelner IP-Adresse, andernfalls bleibt ein verteilter Angriff auf das gesamte Subnetz unbemerkt, obwohl er in Summe die Leitung überflutet.

Zustandsbehaftete Inline-Filterung. Bei Protokollangriffen vom Typ SYN-ACK/ACK/RST ohne entsprechende ausgehende Verbindung genügt DDoS-Schutz auf FlowSpec- oder RTBH-Ebene nicht: Es ist ein Angriff auf den Verbindungszustand, nicht auf das Volumen. Hier wird eine Engine benötigt, die den Zustand von TCP-Verbindungen bidirektional verfolgt und Inline zwischen Edge-Router und BRAS bzw. Konzentrator platziert ist, und die Pakete verwirft, die zu keiner bekannten Session passen. Diese Lösung ist als ergänzende Schicht sinnvoll, nicht als Ersatz für volumetrischen Schutz: Sättigt der Angriff die Upstream-Leitung selbst, behebt kein zustandsbehafteter Filter das, solange RTBH die Leitung nicht entlastet.

Für ein Unternehmen mit einer Website ist ein Cloud-Dienst oft die natürliche Wahl: die Umleitung des Verkehrs über ein externes Rechenzentrum im Moment des Angriffs. Für einen Betreiber, der selbst Leitungsanbieter ist, sieht die Lage anders aus. Die Umleitung des gesamten Kundenverkehrs über externe Infrastruktur bedeutet zusätzliche Latenz, Abhängigkeit von einem Dritten und den Verlust der Kontrolle darüber, wie genau der Verkehr der eigenen Kunden gefiltert wird.

Ein Anti-DDoS-System, das On-Premise auf der Hardware des Betreibers läuft, löst dieses Problem anders: Erkennung und Mitigation finden im selben Netz statt, ohne den Verkehr nach außen zu leiten, und die Entscheidung, was ein Angriff ist und was nicht, trifft der Betreiber und nicht ein externer Anbieter. Dieser Ansatz erfordert eigene Hardware und Wartung, beseitigt aber die Abhängigkeit von einem Dritten im kritischsten Moment, nämlich während des Angriffs.

DDoS-Schutz ist heute nicht mehr nur eine Frage der Dienstverfügbarkeit, sondern auch eine regulatorische Pflicht. Betreiber wesentlicher und wichtiger Dienste, die unter die NIS2-Richtlinie und das nationale Gesetz über das nationale Cybersicherheitssystem fallen, müssen angemessene technische und organisatorische Maßnahmen im Risikomanagement umsetzen, und DDoS-Vorfälle in entsprechendem Ausmaß unterliegen der Meldepflicht an das CSIRT. Ein Anti-DDoS-System, das fertige Berichte im geforderten Datenumfang erzeugt, verkürzt die für die Erfüllung dieser Pflicht benötigte Zeit, doch die Einreichung der Meldung im CSIRT-System bleibt weiterhin Sache des Betreibers.

DDoS-Schutz für einen Betreiber ist nicht ein einzelnes Produkt, sondern ein Satz einander ergänzender Mechanismen, die auf die Angriffsschicht abgestimmt sind: FlowSpec und selektives RTBH auf Netzebene für volumetrische Angriffe, Aggregation pro Präfix für Carpet Bombing, zustandsbehaftete Inline-Filterung für Protokollangriffe, die klassische Volumenschwellenwerte umgehen. Ein Anti-DDoS-System, das On-Premise auf eigener Hardware und im eigenen Netz läuft, gibt dem Betreiber etwas, das ein Cloud-Dienst nicht bieten kann: volle Kontrolle darüber, wie und wann Verkehr gefiltert wird, ohne Vermittler im kritischsten Moment.

Wenn Sie sich fragen, wie die Einführung des Anti-DDoS-Systems LiveShield in Ihrem Netz aussieht, welche Hardware bei Ihrem Verkehrsvolumen nötig ist und welche Edge-Router FlowSpec unterstützen, ist der einfachste Ausgangspunkt ein Gespräch über Ihre konkrete Netztopologie.