Anycast bei DDoS: Was verteilt es – und was nicht?
Anycast verteilt Erreichbarkeit über mehrere Standorte, filtert aber keinen Angriff. So planen Sie Catchments, Kapazität, Route Withdrawal und Abnahme.
Anycast kann Anfragen und damit auch einen Teil des Angriffsverkehrs auf mehrere Standorte verteilen oder regional begrenzen. Es erkennt jedoch nicht, welche Pakete legitim sind, verwirft keinen Angriff automatisch und garantiert keine gleichmäßige Last. Deshalb ersetzt Anycast weder DDoS-Filterung noch ausreichende Kapazität, saubere Routing-Policy und einen getesteten Ausfallplan. Es ist ein Baustein der Architektur, nicht der Schutzmechanismus allein.
Eine Adresse, mehrere erreichbare Standorte
Bei Anycast wird dieselbe Service-Adresse an mehreren voneinander getrennten Standorten erreichbar gemacht. Das Routing wählt für einen Absender einen der angebotenen Wege. RFC 4786 nennt den topologischen Bereich, aus dem Verkehr zu einem bestimmten Anycast-Knoten gelangt, dessen Catchment. Welcher Knoten gewählt wird, folgt der Sicht und Policy der beteiligten Netze – nicht einer zentralen Messung von Serverlast, Antwortzeit oder freier Filterkapazität.
RFC 4786: Betrieb und Design von Anycast-Diensten
| Baustein | Entscheidung | Was er nicht automatisch leistet |
|---|---|---|
| Anycast-Routing | Welcher erreichbare Standort Verkehr für dieselbe Adresse erhält | Legitimen und schädlichen Verkehr unterscheiden |
| DDoS-Filterung | Welcher Verkehr nach der vereinbarten Schutz-Policy weitergeleitet oder verworfen wird | Globale Pfadwahl und Standortverteilung festlegen |
| Kapazitätsplanung | Welche Last Links, Router, Filter und Anwendungen je Standort bewältigen müssen | Verkehr ohne Messung oder Reserven gleichmäßig verteilen |
Warum Anycast kein präziser globaler Load Balancer ist
RFC 4786 beschreibt die Lastverteilung zwischen Anycast-Knoten ausdrücklich als typischerweise ungleichmäßig. BGP wählt Pfade anhand von Routinginformationen und Policies. Ein Knoten kann daher ein großes Catchment erhalten, obwohl ein anderer Standort freie Ressourcen hat. Auch „topologisch näher“ bedeutet nicht zwingend niedrigere Round-Trip-Zeit. Kapazität muss deshalb pro Standort und für plausible Verschiebungen geplant werden, nicht nur als Summe aller Knoten.
Anycast ist nicht Round-Robin-DNS
Bei Anycast bleibt die Service-Adresse gleich; das Routing entscheidet über den Zielknoten. DNS-basierte Verteilung liefert dagegen unterschiedliche Adressen oder Antworten. Beide Ansätze lassen sich kombinieren, haben aber andere Umschaltzeiten, Zustände und Fehlerbilder.
Was Anycast bei einem Angriff helfen kann
Verteilte Knoten können Angriffsverkehr aus verschiedenen Quellregionen an unterschiedlichen Stellen aufnehmen. RFC 4786 nennt das Lokalisieren nicht verteilter Angriffe und das regionale Begrenzen verteilter Angriffe oder Flash Crowds als mögliche Ziele. Die Aufgabe, legitimen von schädlichem Verkehr zu trennen, kann ebenfalls auf mehrere Knoten verteilt werden. Das ist ein Skalierungsvorteil – aber nur, wenn die betroffenen Standorte den ankommenden Verkehr tatsächlich transportieren, analysieren und filtern können.
RFC 4732: Denial-of-Service-Risiken und Teilmaßnahmen
Illustratives Szenario: drei Knoten, drei Catchments
Das folgende Beispiel verwendet ausschließlich Dokumentationswerte: Die Service-Adresse 192.0.2.53 wird von den Knoten Nord, West und Süd angekündigt. Nutzer und Angreifer erreichen je nach Routing einen dieser Knoten. Es handelt sich weder um eine reale AS51202-Route noch um bestätigte Standorte, Kapazitäten oder eine Betreiber-Policy.
| Ereignis | Mögliche Routingwirkung | Erforderliche Schutzentscheidung |
|---|---|---|
| Angriff aus mehreren Netzen | Quellen können in verschiedenen Catchments landen | Jeder betroffene Knoten braucht passende Filter und Reserven |
| Knoten West zieht die Route zurück | Sein Verkehr wechselt nach Konvergenz zu Nord oder Süd | Vorher prüfen, ob die verbleibenden Knoten diese Verschiebung verkraften |
| Anwendung fällt nur an Knoten Süd aus | Die Route kann ohne gekoppelte Gesundheitsprüfung weiter sichtbar bleiben | Servicezustand, Route und Rückfalllogik gemeinsam behandeln |
Das Beispiel zeigt, warum eine globale Gesamtkapazität allein wenig aussagt. Relevant ist, welche Quellen welchen Knoten erreichen, wo Engpässe liegen und was geschieht, wenn sich ein Catchment unter Last verschiebt.
Route Withdrawal kann den Angriff verschieben
Ein Route Withdrawal nimmt einen Knoten aus der Pfadauswahl, beseitigt den Verkehr aber nicht. RFC 7094 warnt davor, bei einem anhaltenden DoS-Angriff einfach die Anycast-Route eines betroffenen Knotens zurückzuziehen: Der Angriff kann dadurch zum nächsten Knoten wandern und eine Kaskade auslösen. Die Entscheidung braucht daher Schwellen, Haltezeiten, verbleibende Kapazität und einen klaren Rückfallplan. Schnelles wiederholtes Ankündigen und Zurückziehen kann zusätzlich Routinginstabilität erzeugen.
RFC 7094: Architekturelle Grenzen und DDoS-Auswirkungen von IP-Anycast
- Vor dem Withdrawal bestimmen, welche Catchments voraussichtlich zu welchen verbleibenden Knoten wechseln.
- Nicht allein auf Linkauslastung reagieren: Anwendung, Filter, Router und Upstream können unterschiedliche Engpässe haben.
- Eine Mindestwartezeit und eine kontrollierte Wiederankündigung vorsehen, damit ein instabiler Dienst keine Route-Flaps erzeugt.
- Manuelle Eingriffsmöglichkeiten und einen Abbruchpunkt festlegen, falls die Automatik den Angriff nur weiterreicht.
Route sichtbar heißt nicht: Dienst gesund
Ein BGP-Nachbar kann stabil sein, während die Anwendung, ein lokaler Load Balancer oder die Filterstrecke nicht mehr funktioniert. RFC 4786 empfiehlt deshalb eine Kopplung zwischen Serviceverfügbarkeit und Routinginformation, weist aber zugleich auf die Komplexität hin, wenn ein Präfix mehrere Dienste umfasst. Die Gesundheitsprüfung muss die tatsächlich benötigte Funktion abbilden und darf nicht bei jedem kurzen Messfehler die globale Route schalten.
Lange Sitzungen und zustandsbehaftete Systeme separat testen
Ändert sich der gewählte Anycast-Knoten während einer bestehenden Verbindung, besitzt der neue Knoten den bisherigen Sitzungszustand häufig nicht. Das kann TCP-Verbindungen unterbrechen; auch NAT, zustandsbehaftete Firewalls und Anwendungssitzungen benötigen ein bewusstes Design. Kurze unabhängige Anfragen verhalten sich anders als Downloads, Streams, VPNs oder andere langlebige Verbindungen. Anycast macht diese Zustände nicht automatisch synchron.
Kapazität und Filterung pro Knoten planen
- Ingress: Port, Upstream und Router müssen den Verkehr bis zur Filterung tragen können.
- Paketverarbeitung: Gbit/s und Pakete pro Sekunde getrennt betrachten; kleine Pakete belasten Systeme anders als große.
- Mitigation: Profil, Regeln und Ausnahmeverkehr müssen an jedem Knoten konsistent genug für den Dienst sein.
- Anwendung: Auch sauberer Restverkehr kann Backends, TLS-Endpunkte, DNS oder Datenbanken überlasten.
- Ausfallreserve: Den Verlust eines Knotens und die daraus folgende Catchment-Verschiebung als eigenes Szenario rechnen.
Für AS51202 gelten die bestätigten DDoS-Eigenschaften unabhängig von diesem Anycast-Grundsatz: eingehender Verkehr wird asymmetrisch gefiltert, automatisiertes Profiling erfasst legitimes Verhalten und adaptives Threshold Learning verwendet 95 % des legitimen Traffics als Lernbasis. Während eines Angriffs pausiert das Lernen, die Filterung bleibt aktiv. Daraus folgt weder eine Anycast-Funktion noch eine garantierte Schutzleistung für jede Architektur.
Monitoring braucht mehrere Blickwinkel
- Service-Probes aus mehreren repräsentativen Netzen, weil verschiedene Absender unterschiedliche Knoten sehen können.
- Eine Knotenkennung in Antworten oder Logs, damit Fehler einem konkreten Standort zugeordnet werden können.
- Routing-Sicht je Region: angekündigte Präfixe, AS-Pfade, Änderungen und unerwartete Origin-ASNs.
- Pro Knoten getrennte Werte für Verkehr, Paketrate, Filterereignisse, Verluste, Latenz und Anwendungsgesundheit.
- Eine gemeinsame Zeitachse für Route, Mitigation und Anwendung, damit Ursache und Folge nicht vertauscht werden.
Abnahme vor dem produktiven Einsatz
- 1Von mehreren Netzen aus dokumentieren, welcher Knoten für IPv4 und IPv6 antwortet und wie er identifiziert wird.
- 2Den Ausfall eines Dienstes ohne Linkausfall simulieren und prüfen, ob Gesundheitsprüfung und Routing wie vorgesehen reagieren.
- 3Einen kontrollierten Route Withdrawal durchführen, Konvergenz und Sitzungsabbrüche beobachten und die Lastverschiebung messen.
- 4Filterung mit legitimem Testverkehr und ausschließlich autorisierten Belastungstests prüfen; Angriffsverkehr nie ohne Freigabe erzeugen.
- 5Rückkehr eines Knotens, Mindestwartezeit, Alarme und manuellen Rückbau dokumentieren.
Welche Angaben in eine Schutzanfrage gehören
Nennen Sie Dienste und Protokolle, IPv4-/IPv6-Präfixe, aktuelle Origin-ASNs, vorhandene Anycast-Knoten, Upstreams und erwartete Catchments. Ergänzen Sie normale Bandbreite und Paketrate je Standort, legitime Spitzen, zustandsbehaftete Komponenten, gewünschtes Ausfallverhalten und verfügbare Telemetrie. Bei einer AS51202-Anfrage kommen Übergabestandort, Port, Commit und gewünschte Schutzstufe hinzu. So lässt sich klären, welche Aufgabe das Routing übernimmt und wo Filterung, Kapazität oder Anwendungsmaßnahmen erforderlich bleiben.