Hardwareanforderungen für ein Anti-DDoS-System: Wie sich ein Server für DPDK auswählen lässt

Die Einführung eines On-Premise-Systems zum Schutz vor DDoS-Angriffen scheitert meist nicht bei der Wahl der Lösung, sondern bei der Auswahl der Hardware. Der Betreiber kauft eine Lizenz für die Anti-DDoS-Software und erhält die Dokumentation. Dann stellt sich heraus, dass der Server, der „mit Reserve“ ausreichen sollte, beim ersten größeren Angriff erstickt. Schuld ist nicht das System selbst, sondern das fehlende Verständnis dafür, dass DDoS-Schutz auf Basis von DPDK anderen Gesetzen folgt als eine typische Serveranwendung.

Dieses Problem betrifft im Grunde jede Einführung eines Anti-DDoS-Systems für einen Telekommunikationsbetreiber oder ein Rechenzentrum: Wie gut die Software auch ist, falsch gewählte Hardware darunter macht ihre Wirksamkeit zunichte. Nachfolgend beschreiben wir, worauf zu achten ist, damit der Schutz des Betreibernetzes vor DDoS-Angriffen vom ersten Tag an wie vorgesehen funktioniert.

Klassische Netzwerksoftware nutzt den Netzwerk-Stack des Betriebssystemkerns. Das ist bequem, aber langsam: Jedes Paket durchläuft mehrere Schichten des Datenkopierens und Kontextwechsel, bevor die Anwendung es sieht. Bei Verkehr von einigen bis einigen Dutzend Gb/s ist das kein Problem. Bei der Paket-für-Paket-Analyse in Echtzeit, auf dem Niveau, das nötig ist, um einen DDoS-Angriff innerhalb einer Sekunde zu erkennen, ist ein solcher Overhead nicht akzeptabel.

Deshalb basieren wirksame Anti-DDoS-Systeme, darunter LiveShield, auf DPDK (Data Plane Development Kit), einer Bibliothek, mit der eine Anwendung Pakete direkt von der Netzwerkkarte empfangen kann, am Kernel vorbei. Der DPDK-Ansatz für Anti-DDoS ist heute der Standard für DDoS-Schutzlösungen der nächsten Generation, die in Echtzeit arbeiten wollen und nicht mit einer Verzögerung von Minuten. Das löst das Leistungsproblem, stellt aber konkrete, starre Anforderungen an die Hardware. Nicht jeder Server und nicht jede Netzwerkkarte ist dafür geeignet.

LiveShield, als Anti-DDoS-System für Telekommunikationsbetreiber und Rechenzentren, arbeitet mit drei Modulen: Manager, Analyser und Worker. Manager und Analyser sind verwaltende und analytische Komponenten und können auf einer virtuellen Maschine laufen, da die Last hier vorhersehbar ist. Der Worker ist eine ganz andere Geschichte: Er führt die Paketverarbeitung mit DPDK aus und benötigt daher einen physischen Server. Virtualisierung fügt eine zusätzliche Schicht zwischen Netzwerkkarte und Anwendung ein, was in der Praxis den Verlust der Vorteile von DPDK bedeutet.

Konsequenz für die Planung der Einführung: Wenn Sie eine All-in-One-Umgebung auf einer Maschine vorsehen, muss die gesamte Maschine physisch sein. Wenn Sie die Module trennen, muss nur der Worker auf physischer Hardware stehen.

Die Anzahl der physischen CPU-Kerne hängt vom Durchsatz des zu analysierenden Verkehrs ab:

physische Kerne = Gbps ÷ 10 + 4

Beispiel: Für 40 Gb/s eingehenden Verkehr ergeben sich 8 Kerne für die Verarbeitung selbst plus 4 Basiskerne, also 12 physische Kerne.

Zwei Mindestschwellen, die unabhängig vom Ergebnis der Formel zu beachten sind:

Es sind physische Kerne, keine logischen Threads aus Hyperthreading. Bei der Paketverarbeitung im Poll-Mode, wie ihn DPDK verwendet, ist ein Kern zu 100 % ausgelastet, unabhängig davon, ob gerade Pakete zu bearbeiten sind. Wer mit HT-Threads rechnet, erhält ein falsches Bild der verfügbaren Leistung.

32 GB RAM oder mehr sind der Ausgangspunkt. DPDK nutzt Hugepages, also im Voraus reservierte Speicherblöcke, sodass man mehr Reserve braucht als das, was auf einem ähnlichen Server ohne Paketverarbeitung „üblicherweise reicht“. Für den Speicherplatz genügen 60 GB auf NVMe: Das System speichert nicht kontinuierlich den vollständigen Verkehr, daher gibt es hier nicht die Kapazitätsanforderungen, die für Tools zur vollständigen Verkehrsaufzeichnung typisch sind.

Das ist der Punkt, an dem die Planung des Einkaufs am häufigsten scheitert. DPDK unterstützt theoretisch eine breite Liste von Karten, in der Praxis bewähren sich aber konkrete Modelle mit dem passenden PMD-Treiber (Poll Mode Driver):

Onboard-Karten (auf dem Mainboard integriert) oder SoC-Lösungen erfordern eine gesonderte Prüfung, ob der Hersteller überhaupt einen PMD-Treiber dafür bereitstellt. Fehlt dieser Treiber, kann die Karte nicht im DPDK-Modus arbeiten, egal wie gut der Prozessor oder die Speichermenge ist. Das ist ein häufiger Fehler bei der Hardwareauswahl für Server: Einkaufsteams schauen auf den Durchsatz der Karte in Gb/s und übersehen die Treiberkompatibilität, die hier eine notwendige Bedingung ist.

Praktische Regel für die Wahl des Kartenherstellers: Unterhalb von 40 Gb/s Verkehr spielt der Unterschied zwischen Intel und Mellanox/NVIDIA keine größere Rolle, beide Familien bewähren sich gut. Oberhalb dieser Schwelle lohnt es sich, auf NVIDIA ConnectX-5 oder ein neueres Modell zu setzen.

Statt bei der reinen Theorie zu bleiben, zeigen wir, wie sich diese Leitlinien in konkrete Hardware übersetzen, die Betreibern bereits in der Phase der Infrastrukturauswahl empfohlen wurde.

Variante I, bis ca. 40 Gb/s: ein Server der Klasse Dell R430 mit Intel Xeon E5-2680 v4 Prozessor, 32 GB RAM, in Kombination mit einer Dual-Port-Karte Intel XL710-QDA2 (QSFP+, 40G). Das ist Hardware, die sich gebraucht für relativ wenig Geld kaufen lässt und die Verkehr auf diesem Niveau problemlos bewältigt.

Variante II, bis 100 Gb/s: Hier muss der Prozessor zu einem Intel Xeon Gold der Serie 63xx wechseln, vor allem wegen der PCIe-4.0-Unterstützung.

Wichtig: Die Intel-Netzwerkkarte E8xx-cqda2 teilt für diesen Durchsatz den PCIe-Bus physisch je zur Hälfte auf die Ports auf. Wenn also beide Ports gleichzeitig genutzt werden sollen, muss das Mainboard PCIe Bifurcation unterstützen. Ohne diese Unterstützung sieht das System nur einen Port der Karte. Ohne volles PCIe 4.0 ist die Karte auf ca. 50G pro Port begrenzt, unabhängig von der Zahl der genutzten Ports.

Für einen Betreiber, der den Schutz des eingehenden Verkehrs auf dem Niveau von 20 Gb/s plant, sieht die minimal sinnvolle Spezifikation für den Worker so aus:

Bei 100 Gb/s eingehendem Verkehr sind es allein aus der Formel bereits 14 physische Kerne, sodass die CPU-Auswahl noch stärker im Hinblick auf die NUMA-Architektur und die Zahl der Prozessorsockel geplant werden muss.

Das Sizing für ein Anti-DDoS-System auf DPDK-Basis ist kein Aufrunden einer typischen Serverspezifikation. Es ist eine eigene Kategorie von Anforderungen: ein physischer Server für das paketverarbeitende Modul, physische Kerne nach einer konkreten Formel berechnet, eine Netzwerkkarte, die vor der Aufnahme in die Bestellspezifikation auf den PMD-Treiber geprüft wurde. Wird einer dieser Punkte in der Planungsphase übergangen, endet das meist mit der Notwendigkeit, nach den Tests oder, schlimmer, nach dem ersten realen Angriff Hardware nachzukaufen.

Ein gut geplanter DDoS-Schutz für einen ISP oder ein Rechenzentrum ist im gleichen Maße eine Frage der richtigen Software wie der bewussten Auswahl der Infrastruktur, auf der diese Software laufen soll. Die vollständige, aktuelle Hardwarespezifikation sowie die Liste validierter Netzwerkkarten finden Sie in der Dokumentation: docs.liveshield.net.

Haben Sie bereits Hardware? Besprechen Sie sie mit uns: office@liveshield.net