Checkliste vor der Einführung eines DDoS-Schutzes: schleifenfreies Routing, Verkehrserfassung, Server und Schwellenwerte. Für ISPs und Rechenzentren.
Kurz gesagt: Vor der Einführung eines DDoS-Schutzes mit Verkehrsfilterung müssen drei Dinge vorbereitet sein: ein Routing, das umgeleiteten Verkehr nicht in eine Schleife schickt, eine Methode zur Erfassung der Verkehrsdaten (Port-Mirroring, sFlow oder NetFlow/IPFIX) und Server für die Konsole sowie für Sensoren mit Filtern. Unterstützt der Router BGP FlowSpec, vereinfachen sich der erste und der dritte Punkt erheblich: VRFs, GRE-Tunnel und ein separater Filterserver entfallen. Nach unserer Erfahrung beansprucht gerade die Vorbereitung auf Kundenseite, nicht die Installation selbst, rund 90 % der Zeit des gesamten Projekts.
Dieser Text ist eine Checkliste. Gehen Sie sie vor dem ersten Termin durch: Das verkürzt die Einführung um Wochen.
Der Ausgangspunkt: Wie unterscheidet sich Schutz von RTBH?
Bevor Sie mit der Vorbereitung beginnen, klären Sie, was Sie eigentlich einführen. Die meisten Teams meinen mit „DDoS-Schutz“ RTBH (Remotely Triggered Black Hole), weil das der einzige Mechanismus ist, den sie zur Hand hatten.
RTBH ist kein Schutz. Es kappt den Verkehr zur angegriffenen Adresse; aus Sicht des Endkunden ist das Ergebnis dasselbe wie bei einem erfolgreichen Angriff: Der Dienst ist nicht erreichbar. Der Angreifer erreicht sein Ziel, nur durch Ihre Hand. RTBH ist sinnvoll, um den Rest des Netzes auf Kosten einer oder weniger Adressen zu retten, wenn nichts Besseres mehr möglich ist. Wann genau dieser Schritt angebracht ist, beschreiben wir im Beitrag über RTBH.
Was Ihre Kunden tatsächlich brauchen, ist Verkehrsfilterung: Die Angriffspakete werden entfernt, die Kommunikation läuft ohne Unterbrechung und ohne spürbare Verzögerung weiter.
Eine zweite typische Situation: Der Kunde nutzt bereits ein kostenloses Tool, das jedoch per Skript oder manuell durch einen Administrator ausgelöst wird. Das funktioniert genau so lange, wie jemand auf die Graphen schaut, also nicht um drei Uhr nachts und nicht am Wochenende. Der Umstieg auf automatische Erkennung und Filterung ist meist der Moment, in dem Netzwerkteams zu uns und zu WanGuard kommen.
Checkliste: Was vor der Einführung des DDoS-Schutzes vorbereitet sein muss
Drei Bereiche, in dieser Reihenfolge:
| Bereich | Was konkret | Wer ist zuständig |
|---|---|---|
| Routing | Möglichkeit, die Routing-Tabellen so zu trennen, dass umgeleiteter Verkehr nicht in eine Schleife zurückläuft, oder ein Router mit BGP FlowSpec, der dies nicht erfordert | Ihr Netzwerkteam |
| Verkehrserfassung | Port-Mirroring, sFlow oder NetFlow/IPFIX bis zum Sensor geführt; bei Port-Mirroring zusätzlich Karte und Port mit ausreichendem Durchsatz | Ihr Netzwerkteam |
| Server | eine Maschine für die Konsole sowie Maschinen für Sensoren mit Filtern; Fernzugriff für das Implementierungsteam | Ihr Team + ITORO |
Im Folgenden die Punkte im Detail, die in der Praxis die meisten Schwierigkeiten bereiten.
Warum droht bei der Verkehrsumleitung eine Routing-Schleife?
Das ist der schwierigste Teil einer Einführung in einem Netz ohne BGP FlowSpec und der häufigste Grund, warum sich ein Projekt in die Länge zieht.
Der Mechanismus ist einfach. Erkennt das System einen Angriff, sendet es ein BGP-Update an den Router, das den Verkehr zum angegriffenen Präfix auf den Filterserver umleitet. Der Server filtert den Angriff heraus und speist den bereinigten Verkehr zurück ins Netz ein. Das Problem: Dieser Verkehr landet in derselben Routing-Tabelle, in der die Umleitung zum Filterserver weiterhin gilt. Das Paket kehrt zum Filter zurück. Und noch einmal. Und noch einmal.
Die Lösung besteht darin, die Routing-Tabellen mithilfe von VRF (Virtual Routing and Forwarding) zu trennen. In einem typischen Design sind drei erforderlich:
- BGP-Edge-Tabelle: Hier landen alle Präfixe der Transit-Provider.
- Eingangstabelle des Filters: ein VRF mit einer Default-Route in Richtung Filterserver.
- Restliches Netz: Kunden-Subnetze und Dienste, ohne sichtbare globale Präfixe aus Punkt 1.
Eine Alternative ist die Umleitung über GRE-Tunnel, doch das löst das Problem nicht, sondern verlagert es nur an eine andere Stelle.
Der Punkt ist: Ein solcher Umbau des Routings ist eine Operation am offenen Herzen. Sie führen ihn in einem laufenden Netz durch, mit Produktionsverkehr und Diensten, die nicht unterbrochen werden dürfen. Das erfordert ein eigenes Wartungsfenster, einen Rollback-Plan und einige schlaflose Nächte. Wenn Sie diesen Absatz lesen und denken „Bei uns ist das in vertretbarer Zeit nicht machbar“, haben Sie recht, und genau deshalb gibt es den nächsten Abschnitt.
Was vereinfacht BGP FlowSpec?
Wenn Sie einen Router mit BGP FlowSpec haben oder einen solchen anschaffen wollen, können Sie den gesamten vorigen Abschnitt überspringen. FlowSpec löst zwei Hauptprobleme auf einmal:
- Das Schleifenproblem entfällt. Sie leiten den Verkehr nirgendwohin um, die Filterregel wird direkt auf dem Interface des Routers installiert. Es gibt nichts, was eine Schleife bilden könnte, also müssen auch keine VRFs aufgebaut werden.
- Der Filterserver entfällt. Die Filterung erfolgt in Hardware mit Interface-Geschwindigkeit. Ob 10, 40 oder 100 GE spielt keine Rolle: Die CPU-Last des Routers bleibt vernachlässigbar.
Das wirkt sich direkt auf das Budget aus: Sie kaufen weder Filterserver noch spezielle Netzwerkkarten, bauen das Routing nicht um und zahlen nicht für wochenlange Arbeit an einem Netzwerkprojekt. Wie eine FlowSpec-Regel in der Praxis aussieht und worauf sie matchen kann, lesen Sie im Beitrag über DDoS-Filterung mit BGP FlowSpec.
Ein Hinweis aus der Praxis: Dass ein Hersteller FlowSpec-Unterstützung angibt, reicht nicht aus. Verschiedene Plattformen programmieren Regeln unterschiedlich zuverlässig in die Hardware: Prüfen Sie das am konkreten Modell und an der konkreten Softwareversion, bevor Sie die Bestellung unterschreiben. Hersteller, bei denen FlowSpec in den Netzen unserer Kunden in der Praxis funktioniert, sind Arista, Cisco, Huawei, Juniper und Nokia.
Wie erfassen Sie die Verkehrsdaten?
Der Sensor muss den Verkehr sehen. Es gibt zwei Wege:
- Port-Mirroring: Eine Kopie des gesamten Verkehrs geht an die Karte des Sensors. Kürzeste Reaktionszeit, weil der Sensor die Pakete im selben Moment sieht wie der Router. Erfordert einen freien Port mit ausreichendem Durchsatz und eine Netzwerkkarte auf Serverseite.
- NetFlow / IPFIX / sFlow: Der Router exportiert Samples oder Flow-Zusammenfassungen. Günstiger und einfacher, doch der Export verursacht eine Verzögerung von 35–95 s, und das Sampling unterschätzt das Volumen kleiner Pakete.
Bei volumetrischen Angriffen ist dieser Unterschied entscheidend: Ein Netz kann binnen einiger Dutzend Sekunden ausfallen, also in der Zeit, in der NetFlow gerade erst die ersten Flows exportiert. Wenn Sie die Wahl haben, nehmen Sie Port-Mirroring und nutzen Sie NetFlow ergänzend für Reporting und die Kapazitätsplanung der Leitungen.
Installation und Tuning: was wir gemeinsam erledigen
Sind die Server bereit und erreicht der Verkehr den Sensor, ist die Installation selbst schnell erledigt. Der Arbeitsumfang sieht so aus:
- Installation der Komponenten: Konsole (GUI), Sensoren und Filter. Aufbau der BGP-Session zwischen dem Konsolenserver und den Routern (z. B. über ExaBGP). Details beschreiben wir in der Anleitung zur WanGuard-Installation.
- Definition der Subnetze und Schwellenwert-Vorlagen: getrennt für jeden Umgebungstyp (Endkunden, Hosting-Server, interne Dienste). Der Verkehr eines Endkundenanschlusses sieht anders aus als der eines Mailservers, und die Schwellenwerte müssen das abbilden.
- Ausnahmen: Manchmal müssen bestimmte Adressen oder Netze vom Schutz ausgenommen werden, um keine SLA-Verletzung zu riskieren. Typisches Beispiel: Google-Cache-Server oder andere Proxy-Systeme, die Daten mit hohen Raten über eine geschlossene oder Peering-Verbindung austauschen, die sicher genug ist, um eine solche Ausnahme zu rechtfertigen.
Die Anfangsschwellenwerte ändern sich immer. Das ist kein Mangel, sondern der normale Lebenszyklus einer Einführung. Die ersten Einstellungen sind ein Ausgangspunkt; in den folgenden Wochen passen Sie sie an die tatsächlichen Verkehrsmuster an, bis das System für jedes Netzsegment normales von anomalem Niveau unterscheidet. Ziel dieses Tunings ist es, Fehlalarme zu reduzieren, die unnötig RTBH oder Filterung auf sauberem Verkehr auslösen würden.
In Krisensituationen, bei Kunden unter einer Serie von Angriffen, die im Internet praktisch nicht mehr erreichbar waren, haben wir mit BGP FlowSpec eine funktionierende Filterung in weniger als 48 Stunden in Betrieb genommen. Die Voraussetzung war immer dieselbe: Server bereit, Port-Mirroring oder eine andere Methode der Verkehrserfassung angeschlossen und funktionsfähig.
Fazit: eine Frage vor dem ersten Gespräch
Bevor Sie Anti-DDoS-Lösungen vergleichen, beantworten Sie eine Frage: Unterstützt mein Edge-Router BGP FlowSpec? Die Antwort entscheidet darüber, ob die Einführung ein Netzwerkprojekt über mehrere Wochen oder eine Installation von wenigen Tagen wird.
Planen Sie in absehbarer Zeit einen Austausch der Edge-Hardware, sollte die Unterstützung von BGP FlowSpec ein Pflichtpunkt in der Spezifikation sein, unabhängig davon, ob Sie den Schutz jetzt oder in zwei Jahren einführen. Dieser eine Parameter spart später Server, einen Umbau des Routings und Zeit.
Mit diesem Punkt beginnen wir jedes Erstgespräch. Die aktuelle Preisliste mit Kalkulator, ohne „Preis auf Anfrage“, finden Sie auf der Seite Preise.
Häufig gestellte Fragen
Wie lange dauert die Einführung eines DDoS-Schutzes?
Das hängt fast ausschließlich vom Vorbereitungsstand des Netzes ab. Mit einem Router mit BGP FlowSpec, einem bereitstehenden Server und angeschlossener Verkehrserfassung kann eine funktionierende Filterung innerhalb weniger Tage starten, im Krisenmodus in weniger als 48 Stunden. Ohne FlowSpec kommt der Umbau des Routings mit VRFs hinzu, der für sich genommen ein eigenes Netzwerkprojekt ist.
Brauche ich einen Filterserver, wenn ich BGP FlowSpec habe?
Nein. Bei FlowSpec-basierter Filterung werden die Regeln direkt auf den Interfaces des Routers installiert und in Hardware ausgeführt; ein separater Filterserver und spezielle Netzwerkkarten sind daher überflüssig. Einen Server für Konsole und Sensor benötigen Sie weiterhin, doch das ist eine deutlich geringere Ausgabe.
Was eignet sich besser zur Erkennung: Port-Mirroring oder NetFlow?
Port-Mirroring, wenn es Ihnen auf die Reaktionszeit ankommt: Der Sensor sieht die Pakete sofort, ohne auf den Flow-Export zu warten. NetFlow, IPFIX und sFlow sind günstiger und einfacher in Betrieb zu nehmen, doch Exportverzögerung und Sampling führen dazu, dass die Reaktion bei schnellen volumetrischen Angriffen erst nach dem Schaden kommt. Viele Netze nutzen beide Methoden parallel.
Muss ich Adressen vom Schutz ausnehmen?
In manchen Fällen ja. Systeme mit sehr hohem, aber legitimem Volumen, etwa Cache-Server großer Content-Anbieter oder Proxy-Systeme, die Daten über Peering austauschen, können für die Erkennung wie eine Anomalie aussehen. Ist die Verbindung zu ihnen geschlossen oder ein Peering und ausreichend sicher, ist eine Ausnahme günstiger als das Erklären von Fehlalarmen.
Wann ist der beste Zeitpunkt, über DDoS-Schutz zu sprechen?
Am besten vor dem Austausch des Edge-Routers, nicht danach. Die Entscheidung für oder gegen Hardware mit BGP FlowSpec legt die Schutzarchitektur für die nächsten Jahre fest und bestimmt, was ihre Inbetriebnahme kostet. Ein zweiter guter Zeitpunkt ist die Budgetplanung: Dann lässt sich ein zusätzlicher Punkt am leichtesten in die Spezifikation aufnehmen.