6. Oktober 2026
·
13 Min. Lesezeit
DDoS-Angriffe erkennen: Port-Mirroring mit DPDK sieht 100 % der Pakete, RTBH nach etwa 1 s, Filterung nach 6–10 s; NetFlow, sFlow und IPFIX erst nach 35–95 s.
Kurz gesagt: Wer einen DDoS-Angriff erkennen will, hat zwei Methodenfamilien zur Wahl. Die Paketanalyse an einem gespiegelten Port (SPAN oder passiver TAP) mit DPDK sieht 100 % des Verkehrs mit Leitungsgeschwindigkeit: RTBH greift nach etwa 1 s, die selektive Filterung nach 6–10 s. Die Flow-Analyse (NetFlow, sFlow, IPFIX) nutzt gesampelte Datensätze, die der Router ohnehin exportiert: Sie ist deutlich günstiger und deckt das gesamte Netz ab, reagiert aber erst nach 35–95 s. Dieser Zeitunterschied entscheidet darüber, ob Kunden den Angriff überhaupt bemerken.
Was heißt es eigentlich, einen DDoS-Angriff zu erkennen?
Erkennung ist der Prozess, einen laufenden Distributed-Denial-of-Service-Angriff festzustellen: Das System profiliert den Verkehr fortlaufend und löst einen Alarm aus, sobald Volumen, Protokollverteilung oder Paketgröße in einem Subnetz von der erlernten Baseline abweichen. Es beantwortet eine einzige Frage, und zwar schnell: normaler Verkehr oder Angriff?
Erkennung ist nicht dasselbe wie die Reaktion auf einen Angriff, aber das eine existiert nicht ohne das andere. Kein Filter, keine BGP-FlowSpec-Regel und keine RTBH-Sperre einer Adresse verwirft auch nur ein einziges Paket, solange der Detektor nicht meldet, dass es etwas zu verwerfen gibt. Die gesamte Abwehrkette ist so schnell wie ihr erstes Glied.
Womit Sie den Detektor speisen, mit Paketkopien oder exportierten Flows, legt zwei Dinge zugleich fest: die Reaktionszeit und die Kosten der Netzabdeckung. Das ist die einzige wirklich schwierige Entscheidung beim Entwurf eines Erkennungssystems.
Warum entscheidet die Erkennungszeit, ob Kunden den Angriff bemerken?
Weil heutige volumetrische Angriffe einen Uplink in wenigen Dutzend Sekunden sättigen, nicht in Minuten. Cloudflare meldete in seinem Bericht für das vierte Quartal 2025 einen Anstieg der DDoS-Angriffe um 121 % gegenüber dem Vorjahr; der größte blockierte Angriff mit 31,4 Tbps dauerte nur 35 Sekunden. Die am häufigsten angegriffene Branche bei hypervolumetrischen Angriffen waren Telekommunikationsbetreiber und Service Provider, also genau das Netzprofil, um das es hier geht.
Diese Zahl verdient einen zweiten Blick: 35 Sekunden von Anfang bis Ende. Eine Erkennungsmethode, die nach 35–95 s reagiert, kann einen solchen Angriff vollständig verpassen oder ihn erst sehen, wenn die Leitung bereits verstopft ist und Kunden längst Timeouts erhalten. Der Alarm kommt dann nicht als Warnung, sondern als Bestätigung des Ausfalls.
Parallele Daten von NETSCOUT für das zweite Halbjahr 2025 nennen über 8 Millionen DDoS-Angriffe in 203 Ländern, wobei rund 42 % zwei bis fünf Vektoren gleichzeitig nutzten. Ein kurzer Multivektor-Angriff ist der Musterfall, in dem langsame, gesampelte Erkennung schlicht nicht mithält: Bis sich die Statistik zu einer Anomalie verdichtet, hat der Vektor bereits gewechselt.
Die Faustregel, nach der wir arbeiten, lautet: Die Zeit bis zur Erkennung muss kürzer sein als die Zeit bis zur Sättigung der Leitung. An einem ausgelasteten 100GE-Netzrand bemisst sich dieses Budget in Sekunden. Wie das aus Sicht der Bereitschaft im NOC aussieht, haben wir im Beitrag über einen DDoS-Angriff auf einen ISP beschrieben: Dort legten wenige Dutzend Sekunden Verkehr das Netz lahm.
Wie funktioniert die Erkennung per Port-Mirroring (DPDK)?
Die paketbasierte Erkennung analysiert eine vollständige Kopie des Verkehrs. Eine SPAN- oder Mirror-Session auf dem Switch oder Router, oder ein passiver optischer TAP, wenn Sie das Produktivgerät nicht belasten wollen, dupliziert jedes Paket auf einen Monitoring-Port. Dort erfasst der Packet Sensor von WanGuard den Verkehr im User Space mithilfe von DPDK (Data Plane Development Kit) mit Leitungsgeschwindigkeit.
Wesentlich ist: Hier wird nichts geschätzt. Der Sensor sieht jeden Header, jedes TCP-Flag, jedes Protokoll und jedes Fragment direkt. Es gibt keine statistische Rekonstruktion und keine Sampling-Rate, mit der das Ergebnis hochgerechnet werden muss.
DPDK macht diesen Ansatz auf schnellen Leitungen praktikabel. Es umgeht den Netzwerkstack des Linux-Kernels, nutzt Treiber im Poll Mode und Hugepages, wodurch der Overhead pro Paket auf ein Minimum sinkt. Ergebnis: Ein gewöhnlicher x86-Server kann Dutzende, bei passender Konfiguration Hunderte Gbps analysieren.
Der Gewinn ist einer, und er ist konkret: Reaktionszeit. In ITORO-Implementierungen erkennt das System einen volumetrischen Angriff per Port-Mirroring und löst RTBH nach etwa 1 s aus. Eine präzise Filterung mit Regeln per BGP FlowSpec greift nach 6–10 s.
Der Preis ist die Reichweite. Sie benötigen Mirror-Kapazität und einen Sensor an jedem Messpunkt, daher wird die Abdeckung von zehn oder mehr geografisch verteilten PoPs mit vollständiger Paketanalyse teuer, und meist ist sie auch nicht sinnvoll. Port-Mirroring setzen Sie dort ein, wo Sekunden tatsächlich Geld kosten: an den am stärksten ausgelasteten Netzrändern und bei den Kunden mit dem höchsten Wert.
Was Port-Mirroring vom Gerät verlangt
Bevor Sie eine Implementierung planen, prüfen Sie drei Dinge. Erstens: ob das Gerät eine Mirror-Session überhaupt ohne Auswirkung auf das Forwarding verkraftet (auf Hardware mit begrenztem PFE-Budget kann Mirroring teuer sein). Zweitens: ob der Monitoring-Port genug Bandbreite für die Verkehrsspitze in beiden Richtungen hat; ein Mirror von 2 × 10GE passt nicht auf einen 10GE-Port, und Sie verlieren Pakete genau dann, wenn sie am wichtigsten sind. Drittens: ob ein passiver TAP oder ein Packet Broker, der denselben Datenstrom auf mehrere Werkzeuge verteilt, nicht günstiger ist.
Wie funktioniert die Erkennung auf Basis von NetFlow, sFlow und IPFIX?
Die flowbasierte Erkennung analysiert zusammenfassende Datensätze, die Ihre Router ohnehin exportieren. Sie brauchen weder Mirror noch TAP. Der Flow Sensor sammelt diese Datensätze, rekonstruiert daraus ein statistisches Bild des Verkehrs pro Subnetz und meldet eine Anomalie, wenn dieses Bild von der Baseline abweicht.
Drei Exportformate dominieren, und sie funktionieren nicht gleich, auch wenn umgangssprachlich alles „NetFlow“ heißt.
NetFlow und IPFIX: Export aus dem Flow-Cache
NetFlow (Herkunft Cisco, Versionen v5 und v9) und sein IETF-Standard IPFIX (RFC 7011) führen auf dem Router einen Flow-Cache. Das Gerät fasst Pakete zu Flows zusammen und exportiert einen Datensatz erst, wenn der Flow endet oder ein Timer abläuft. Der Active Flow Timeout bestimmt, wie schnell ein lang andauernder Angriff gemeldet wird, und sein Standardwert liegt auf vielen Plattformen bei etwa 60 Sekunden. Auf den meisten Geräten lässt er sich senken, und das sollten Sie auch tun; je niedriger Sie gehen, desto mehr exportierte Datensätze und desto höhere Last auf dem Collector nehmen Sie allerdings in Kauf.
Dieser eine Timer ist der Hauptgrund, warum die flowbasierte Erkennung im Bereich von 35–95 s landet.
sFlow: Paket-Sampling
sFlow geht einen anderen Weg. Es sampelt 1 von N Paketen und sendet diese Samples fortlaufend als Datagramme: Es gibt keinen Cache, der ablaufen müsste. Obwohl sFlow nicht auf das Ende eines Flows wartet, liegt die Erkennung auch hier in der Praxis bei 35–95 s. Es bleibt zudem gesampelt und tauscht damit Vollständigkeit gegen eine fortlaufende Lieferung der Samples.
Gemeinsame Ökonomie aller drei
Flow-Export ist bandbreitenunabhängig: Sie senden Datensätze, keine Kopie des Verkehrs. Er deckt jeden Router ab, der das Protokoll bereits spricht, und skaliert mit geringen Kosten bis in den Terabit-Bereich. Der Preis dafür sind Zeit und Detailtiefe: Die Datensätze sind gesampelt (auf schnellen Leitungen meist 1:1.000 oder 1:2.000) und werden oft im Exportfenster aggregiert. Deshalb liegt die flowbasierte Erkennung im Produktivbetrieb typischerweise bei 35–95 s und liefert ein deutlich gröberes Bild als die Paketanalyse.
Port-Mirroring oder NetFlow, sFlow und IPFIX: der Vergleich
Eine faire Gegenüberstellung sieht so aus. Keine der Methoden ist losgelöst vom Kontext „besser“: Jede gewinnt eine andere Aufgabe, und deshalb arbeiten an einem ausgereiften Netzrand meist beide gleichzeitig.
| Kriterium | Port-Mirroring (DPDK Packet Sensor) | NetFlow / IPFIX | sFlow |
|---|---|---|---|
| Was erfasst wird | 100 % der Pakete | gesampelte Datensätze aus dem Flow-Cache | gesampelte Paket-Header |
| Sampling | keines (vollständige Analyse) | ja + Aggregation im Cache | ja (1 von N) |
| Typische Erkennungszeit | RTBH nach ~1 s, selektive Filterung nach 6–10 s | ~35–95 s (Grenze: Active Timeout) | ~35–95 s, gesampelt |
| Abdeckungsmodell | pro Messpunkt (TAP/SPAN) | jeder exportierende Router | jeder exportierende Router |
| Bandbreitenbedarf | erfordert Mirror-/TAP-Kapazität | bandbreitenunabhängig | bandbreitenunabhängig |
| Relative Kosten | höher pro Standort | niedrig | niedrig |
| Blinde Flecken | praktisch keine | Angriffe mit geringem Volumen, Fragmente, Sampling-Lücken | Sampling-Lücken |
| Am besten geeignet für | ausgelastete Netzränder, kritische Leitungen | breite Abdeckung vieler PoPs | breite Abdeckung mit fortlaufendem Export |
Sichtbarkeit auf Ebene einzelner Pakete lässt sich gut mit Streaming-Telemetrie von Juniper MX kombinieren: Das NOC sieht denselben Angriff und dieselbe Filterung auf einem Dashboard, unabhängig davon, welcher Sensor den Alarm ausgelöst hat.
Wo erzeugt Sampling blinde Flecken?
Sampling erzeugt blinde Flecken, weil der Flow Sensor den Verkehr statistisch aus einem Bruchteil der Pakete rekonstruiert. Alles, was in die Lücken zwischen den Samples fällt, wird leicht zu niedrig gezählt oder falsch klassifiziert.
Bei 1:1.000 kann ein Muster mit geringer Intensität, aber realem Schaden (ein langsamer Flood auf Anwendungsebene, eine gezielte Erschöpfung der State-Tabelle) schlicht nicht genug Samples sammeln, um die Schwelle rechtzeitig zu überschreiten. Der Angriff wirkt, der Kunde ruft an, und die Grafik ist flach.
Fragment-Floods sind das klassische Beispiel. Nicht-initiale IP-Fragmente tragen keinen Layer-4-Header und damit keine Information über TCP/UDP-Ports (RFC 791). Flow-Datensätze können sie deshalb falsch einsortieren oder ignorieren, und Sampling verzerrt dieses Bild zusätzlich. Ein Packet Sensor auf DPDK-Basis sieht jedes Fragment direkt und kann es exakt zählen oder wieder zusammensetzen.
Dieselbe Logik gilt für kurze Angriffe: Ein Angriff von 35 Sekunden lässt einem Active Timeout von 60 Sekunden keine Chance. Der Datensatz wird nachträglich exportiert, wenn es nichts mehr zu verteidigen gibt.
Das heißt nicht, dass flowbasierte Erkennung nutzlos ist: Im Gegenteil, in den meisten Netzen liefert gerade sie die Reichweite. Es heißt nur, dass Sie sie dort einsetzen, wo ihre blinden Flecken keine Rolle spielen, und dort mit Paketanalyse ergänzen, wo sie eine Rolle spielen.
Wann setzt man welche Methode ein?
Wählen Sie die Methode nach dem Wert und dem Zeitbudget der jeweiligen Leitung, und in den meisten realen Netzen bedeutet das: beide. Es gibt keinen alleinigen Sieger, sondern einen technischen Kompromiss zwischen Reaktionszeit und den Kosten, das gesamte Netz mit vollständiger Paketanalyse abzudecken.
- Port-Mirroring (DPDK): an den am stärksten ausgelasteten Netzrändern, an Peering- und Transit-Uplinks sowie in Kundensegmenten mit dem höchsten Wert. Überall dort, wo wenige Sekunden darüber entscheiden, ob die Leitung gesättigt ist, bevor Sie reagieren.
- Flow (NetFlow/sFlow/IPFIX): für eine breite, wirtschaftliche Abdeckung vieler PoPs und interner Router, wo ein TAP an jeder Stelle unpraktikabel und ein etwas späterer Alarm akzeptabel ist.
- Beide gleichzeitig: der Normalfall in ausgereiften Netzen. Paketanalyse für Geschwindigkeit, wo sie zählt, Flow für Reichweite an den übrigen Stellen und eine Konsole, die beides korreliert.
Genau so kalkulieren und planen wir DDoS-Schutz-Dienstleistungen: Wir ordnen jeder Leitung eine Erkennungsmethode nach ihrem Risiko zu, statt überall dasselbe Schema auszurollen. Den Implementierungsumfang und die daraus folgenden Kosten finden Sie in der aktuellen Preisübersicht mit Kalkulator.
Wie WanGuard beide Erkennungsmethoden unterstützt
WanGuard ist genau um dieses duale Modell herum gebaut, und das ist der Grund, warum wir darauf standardisieren. Der Packet Sensor erfasst den Mirror-Verkehr über DPDK bei voller Sichtbarkeit, erkennt einen Angriff und löst RTBH nach etwa 1 s aus; die selektive Filterung greift nach 6–10 s. Der Flow Sensor nimmt NetFlow (v5/v9), sFlow (v5) und IPFIX an und bietet bandbreitenunabhängige Abdeckung im Terabit-Maßstab.
Beide speisen dieselbe Detection Engine und dieselbe Konsole, sodass ein Alarm aus einer der beiden Quellen dieselbe automatische Reaktion auslöst. Eine kürzere Beschreibung der Architektur finden Sie auf der Seite zu WanGuard, eine Einführung für Einsteiger im Beitrag Was ist WanGuard?.
In der Praxis bedeutet das, dass Sie sich nicht für ein Lager entscheiden und mit dessen blinden Flecken leben müssen. Sie setzen Port-Mirroring mit DPDK auf Leitungen ein, auf denen RTBH nach etwa 1 s und selektive Filterung nach 6–10 s nicht verhandelbar sind, verteilen Flow-Sensoren für die Reichweite über den breiteren Netzrand, und ein System korreliert beides, erkennt den Angriff und übergibt ihn an die Filterung (zuerst BGP FlowSpec, RTBH nur als letztes Mittel).
Dabei muss klar gesagt werden: Die Erkennungsgenauigkeit hängt weiterhin vom Tuning ab. Baselines pro Subnetz, Ausnahmen für bekannte Kunden mit hohem Verkehrsaufkommen, sinnvoll gesetzte Schwellenwerte. Richtig umgesetzt liefern beide Methoden treffende, automatische Alarme. Falsch umgesetzt erzeugt jede von ihnen Fehlalarme, Port-Mirroring nur schneller.
ITORO ist weltweiter Gold Partner von Andrisoft, mit Erfahrung in WanGuard-Implementierungen seit 2014. Wir installieren, tunen und betreiben beide Erkennungsmodi als Managed Service, von Anfang bis Ende, weltweit zum selben Preis.
Häufige Fragen
Welche Methode erkennt DDoS-Angriffe am schnellsten?
Am schnellsten ist die Erkennung an einem gespiegelten Port mit DPDK: RTBH greift nach etwa 1 s, die selektive Filterung nach 6–10 s. Sie analysiert 100 % der Pakete mit Leitungsgeschwindigkeit über eine SPAN-/Mirror-Session oder einen optischen TAP, nichts wird gesampelt oder geschätzt. Flowbasierte Erkennung (NetFlow/sFlow/IPFIX) ist günstiger und deckt mehr Router ab, reagiert aber meist erst nach 35–95 s.
Worin unterscheidet sich Port-Mirroring von der Erkennung per NetFlow?
Port-Mirroring analysiert über DPDK eine vollständige Kopie jedes Pakets und sieht also den gesamten Verkehr mit Leitungsgeschwindigkeit: RTBH greift nach etwa 1 s, die selektive Filterung nach 6–10 s. NetFlow analysiert gesampelte Sammeldatensätze aus dem Flow-Cache des Routers: bandbreitenunabhängig und günstig, aber langsamer (begrenzt durch den Active Flow Timeout, häufig ca. 60 Sekunden) und weniger detailliert.
Ist sFlow bei der DDoS-Erkennung schneller als NetFlow?
Das kann sein. sFlow sendet gesampelte Paket-Header fortlaufend und hat keinen Cache, der ablaufen müsste; es wartet also nicht wie klassisches NetFlow und IPFIX auf einen Flow-Timeout. Beide sind jedoch gesampelt, bleiben daher langsamer und ungenauer als die vollständige Paketanalyse mit DPDK und teilen dieselben blinden Flecken bei Angriffen mit geringem Volumen und bei Fragment-Floods.
Warum ist die Erkennungszeit so wichtig?
Weil heutige volumetrische Angriffe einen Uplink in wenigen Dutzend Sekunden sättigen. Cloudflare verzeichnete einen Rekordangriff mit 31,4 Tbps, der 35 Sekunden dauerte (Februar 2026). Wenn Ihre Erkennung erst nach 35–95 s reagiert, kann ein kurzer Angriff bereits vorbei oder die Leitung verstopft sein, bevor die Filterung überhaupt startet.
Kann flowbasierte Erkennung einen Angriff verpassen, den Port-Mirroring erfasst?
Ja. Flow-Daten sind gesampelt (meist 1:1.000), daher können Angriffe mit geringer Intensität und kurze Bursts unter der statistischen Schwelle bleiben. Fragment-Floods sind zusätzlich schwer zu klassifizieren, weil nicht-initiale Fragmente keine Portinformation der Schicht 4 tragen. Ein Packet Sensor auf DPDK-Basis sieht jedes Paket und jedes Fragment direkt; deshalb deckt man zeitkritische Leitungen mit beiden Methoden gleichzeitig ab.
Lässt sich die Erkennungszeit allein mit NetFlow verkürzen?
Teilweise. Ein niedrigerer Active Flow Timeout (z. B. von 60 auf 10–15 Sekunden) und ein kürzeres Exportintervall beschleunigen den Alarm spürbar, auf Kosten von mehr Datensätzen und höherer Last auf Router und Collector. Eine höhere Sampling-Dichte verbessert die Genauigkeit, erhöht aber ebenfalls die Kosten. Selbst nach dem Tuning erreichen Sie nicht das Niveau der Paketanalyse: Ein Flow beschreibt den Verkehr per Definition, er zeigt ihn nicht.
Quellen
- Cloudflare: Q4 2025 DDoS Threat Report (Februar 2026): https://blog.cloudflare.com/ddos-threat-report-2025-q4/
- NETSCOUT: DDoS Threat Intelligence Report, Issue 16 / 2H 2025 (März 2026): https://www.netscout.com/threatreport/
- IETF: RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol: https://www.rfc-editor.org/rfc/rfc7011
- IETF: RFC 3176, InMon Corporation’s sFlow: https://www.rfc-editor.org/rfc/rfc3176
- IETF: RFC 791, Internet Protocol (IP-Fragmentierung): https://www.rfc-editor.org/rfc/rfc791
- DPDK: Dokumentation des Data Plane Development Kit: https://doc.dpdk.org/guides/
- Andrisoft: WanGuard, Produktdokumentation: https://www.andrisoft.com/software/wanguard
