Ein Anti-DDoS-System im Netz eines Betreibers ist kein einzelnes Werkzeug, sondern eine Abfolge von Schutzstufen: von der Sichtbarkeit des Datenverkehrs im eigenen Netz über die Filterung am Edge-Router bis zur Zusammenarbeit mit Upstreams. Wir beschreiben die Stufen in der Reihenfolge, in der sie sich sinnvoll aufbauen lassen, am Beispiel des Systems LiveShield. Jede Stufe löst ein anderes Problem und erfordert vom Betreiber eine andere Entscheidung.
Was ist die Eskalationsleiter beim DDoS-Schutz?
Die Eskalationsleiter ist die Reihenfolge der Reaktionen auf einen Angriff: Wir beginnen mit dem, was der Betreiber lokal kontrolliert, und schalten externe Ressourcen erst auf höheren Stufen zu. Höhere Stufen bauen auf den niedrigeren auf, deshalb ist es nicht sinnvoll, von oben zu beginnen.
Ein Betreiber sollte lokal wissen, was sein Netz trifft. Der Upstream sieht nicht alles, besonders wenn das Netz mehrere Anbindungen hat. Auch ein externes Scrubbing-Center braucht lokale Erkennung, Reporting und Umleitung, um überhaupt zu funktionieren.
Schritt 1: Warum beginnt ein Anti-DDoS-System mit der Sichtbarkeit des Datenverkehrs?
Ohne schnelle Erkennung lässt sich ein Angriff weder filtern noch melden, deshalb ist die Sichtbarkeit des Datenverkehrs die erste und wichtigste Stufe. Der Betreiber muss sehen, was sein Netz trifft, und zwar innerhalb von Sekunden. Betreiber, die dem polnischen KSC-Gesetz (Nationales Cybersicherheitssystem) unterliegen, müssen außerdem Vorfälle bearbeiten und melden. Dafür müssen sie zuerst erkannt und dokumentiert werden.
Deshalb stützt LiveShield die Erkennung nicht auf NetFlow. NetFlow ist zu langsam, und nicht der gesamte Datenverkehr gelangt in die Analyse. Das System analysiert eine Kopie des Datenverkehrs aus einem Mirror: von einem SPAN-Port am Router oder Switch oder von einem optischen TAP in der Leitung. In einem Test lag die Reaktionszeit des Systems auf einen Angriff unter einer Sekunde.
Erfordert die Verkehrsanalyse teure Hardware?
Nein. Die Paketverarbeitung auf Basis von DPDK umgeht den Betriebssystemkern, daher bewältigt ein einzelner Server der Klasse Dell R430 mit einem Xeon-E5-v4-Prozessor 40G Datenverkehr, zu einem Preis von etwa 2000 PLN. Noch vor Kurzem erforderte diese Leistung ein Vielfaches teurere Hardware.
Schritt 2: Begrenzt der Edge-Router den Schutz vor DDoS?
Ja. Ein schwacher Edge-Router verursacht bei Angriffen Probleme, denn auf ihm landen die Filterregeln. Die Unterstützung von BGP FlowSpec ist hier eine Grundvoraussetzung, da FlowSpec der wichtigste Mechanismus ist, mit dem das System Regeln an den Router übergibt.
Ein Hardware-Router mit ASIC verarbeitet den Datenverkehr schnell, verfügt über TCAM und große Leistungsreserven. Ein Linux-Router ist nur eine Notlösung und ergibt nur mit VPP oder DPDK Sinn, weil der Betriebssystemkern für solchen Datenverkehr zu langsam ist. Ein solcher Router wirkt günstig, erfordert aber aufwendiges Tuning und bietet keine Leistungsgarantie.
Mikrotik nimmt FlowSpec-Regeln an, wendet sie aber nicht an, daher bleibt bei einem solchen Gerät nur Blackholing.
Schritt 3: Wie filtert man einen Angriff, ohne legitimen Datenverkehr abzuschneiden?
Wirksame Filterung kombiniert zwei Mechanismen: Prefiltering und Advanced Filtering. Das Ergebnis beider sind BGP-FlowSpec-Regeln, die an den Router gesendet werden, sodass legitimer Datenverkehr zur angegriffenen Adresse weiterfließt.
Prefiltering sind vordefinierte Regeln für die häufigsten Angriffsvektoren, z. B. NTP, DNS oder ICMP. Sie greifen sofort, ohne dass der Datenverkehr erst gelernt werden muss.
Advanced Filtering ist ein dynamisches Lernen des Datenverkehrs anhand des Paketinhalts. Es ist bei Botnetz-Angriffen unverzichtbar und bei Datenverkehr wie TCP oder UDP, den man nicht einfach abschneiden kann.
Selektives Blackholing ist die letzte Stufe, nicht die erste. Es ist vor allem für einzelne Adressen sinnvoll. Bei lang andauernden Carpet-Bombing-Angriffen funktioniert es nicht, und nicht jeder Upstream akzeptiert Präfixe, die kürzer als /32 sind. Wir schneiden den Datenverkehr nicht lokal ab: Datenverkehr von IXPs und direkten Peerings bleibt erhalten.
Bei einem Angriff, der sich über ein ganzes Subnetz verteilt (Carpet Bombing), zählen Schwellenwerte pro Subnetz, nicht nur pro IP-Adresse. Ohne Schwellenwerte pro Subnetz wird ein solcher Angriff nicht erkannt.
Schritt 4: Was sollte man vor einem Angriff bei den Upstreams prüfen?
Lokale Filterung genügt nicht, wenn ein Angriff die Leitung saturiert, bevor der Datenverkehr den Edge-Router erreicht. Deshalb ist die Wahl der Upstreams eine Beschaffungsentscheidung, die man vor dem ersten großen Angriff abschließen sollte.
Worauf man achten sollte:
Portbandbreite. 10G-Ports sind heute oft zu klein. Wo möglich, lohnt der Wechsel auf Ports mit höherer Bandbreite bei niedrigerem Commitment.
Steuerung des Datenverkehrs. Mix-Anbindungen erschweren die Steuerung des Datenverkehrs, weil unklar ist, woher und wie viel Datenverkehr kommt.
FlowSpec beim Upstream. Ein Upstream ohne FlowSpec ist bei jedem größeren Angriff ein Problem, besonders bei Carpet Bombing. Bietet ein Upstream FlowSpec oder RTBH an, lassen sich Regeln und Präfixe direkt an dessen Router senden. Das muss mit jedem Provider einzeln geklärt werden.
Optional ergänzend lässt sich ein externes Scrubbing-Center nutzen. LiveShield hat kein eigenes Scrubbing-Center, kann aber Datenverkehr dorthin umleiten, und die Schwelle für die Umleitung lässt sich an die Sättigung der Leitung koppeln. Das Scrubbing-Center ergänzt dann den lokalen Schutz und ersetzt ihn nicht.
Schritt 5: Was tun bei Angriffen, die wie legitimer Datenverkehr aussehen?
Solche Angriffe erfordern eine zustandsbehaftete Verkehrsanalyse, denn ein einzelnes Paket verrät nicht, dass es Teil eines Angriffs ist. Ein typisches Beispiel ist SYN-ACK-Reflection sowie eine Mischung verschiedener Vektoren gleichzeitig. Allein mit Schwellenwerten pro Protokoll lassen sie sich nicht wirksam stoppen, ohne das Risiko, legitime Verbindungen zu kappen.
Dafür dient LiveShield AIF. Es arbeitet inline, zwischen Edge-Router und BRAS bzw. Konzentrator, und verfolgt bidirektional den Zustand der TCP-Verbindungen. Es basiert auf DPDK und arbeitet daher mit hoher Geschwindigkeit.
AIF ersetzt keine Leitungskapazität. Ein Angriff, der die Leitung des Upstreams saturiert, muss weiterhin auf höheren Stufen behandelt werden: per FlowSpec oder RTBH bei den Upstreams.
Schritt 6: Wie dokumentiert und automatisiert man die Reaktion?
Ein Betreiber sollte jederzeit sehen, was das System tut, und es in eigenen Prozessen nutzen können. LiveShield zeigt alle während eines Angriffs aktiven Regeln, Diagramme mit Aufteilung pro Upstream und erstellt Berichte, darunter einen Bericht für das KSC. Der Bericht dient der Vorbereitung der Meldung, das System sendet ihn aber nicht automatisch.
Eigene Event-Pipelines ermöglichen E-Mail-Benachrichtigungen, Webhooks und Skripte. Ein Skript kann auch die Konfiguration von Netzwerkgeräten ändern, zum Beispiel die Ankündigung von Präfixen an ausgewählte Upstreams stoppen, den Datenverkehr auf ein Scrubbing-Center umschalten oder nur den Upstream behalten, der FlowSpec unterstützt.
Regeln lassen sich außerdem manuell erstellen, unabhängig von der automatischen Erkennung, und die Konfiguration lässt sich über die öffentliche API ändern.
Schritt 7: Wie geht man mit Angriffen über einen IXP um?
Einen Angriff über einen IXP kann man eindämmen, indem man seine Quelle ermittelt, statt den gesamten Austauschpunkt abzuschneiden. Dafür braucht man gute Diagramme pro Upstream und Verkehrsproben.
Das Vorgehen:
Auf den Diagrammen pro Upstream sieht man, dass der Datenverkehr über den IXP eintritt.
Aus den Verkehrsproben lesen wir die MAC-Adresse der Quelle aus.
Anhand der MAC ermitteln wir die IP-Adresse des Peers und seine ASN.
Wir senden an die gewählte ASN die Community do-not-announce, abhängig von den Regeln des jeweiligen IXP.
Der Datenverkehr dieses Peers gelangt dann nicht mehr über den IXP ins Netz, sondern über Transitwege.
Was sollte man im eigenen Netz prüfen, bevor ein Angriff auftritt?
Am schnellsten beginnt man mit Fragen, die keine Anschaffungen erfordern:
Lässt sich der Datenverkehr am Netzrand spiegeln (SPAN oder TAP)?
Unterstützt der Edge-Router BGP FlowSpec, und welche Modelle haben wir im Netz?
Bietet jeder Upstream FlowSpec oder RTBH an, und zu welchen Bedingungen?
Kennen wir die Schwellen, ab denen unsere Leitungen saturiert sind?
Wer reagiert wie, wenn ein Angriff das Netz außerhalb der Arbeitszeiten trifft?
Die Antworten zeigen, welche Stufe der Leiter heute die schwächste ist. Erst dann lohnt es sich, die Einführung eines Systems zu planen.
