6. Oktober 2026
·
7 Min. Lesezeit
Port-Mirroring: RTBH nach etwa 1 s, Filterung nach 6–10 s; NetFlow erkennt DDoS-Angriffe erst nach 35–95 s. Vergleich von Reaktionszeit, Kosten und Routerlast.
Kurz gesagt: Bevor Sie einen DDoS-Schutz aufbauen, müssen Sie entscheiden, woher die Verkehrsdaten kommen. Port-Mirroring bietet volle Sichtbarkeit ohne Verzögerung und ermöglicht RTBH nach etwa 1 s sowie selektive Filterung nach 6–10 s, erfordert aber freie Ports und Verkabelung. NetFlow / IPFIX / sFlow benötigt keine zusätzlichen Ports und skaliert auf beliebig große Netze, kostet aber 35–95 s Verzögerung durch den Flow-Export und bringt einen Sampling-Fehler mit sich. In kleinen und mittleren Netzen sollten Sie Port-Mirroring überall dort einsetzen, wo Ports dafür frei sind; NetFlow bleibt für Stellen, an denen das Kopieren des gesamten Verkehrs physisch nicht machbar ist.
Das ist die erste Architekturentscheidung, kein Implementierungsdetail. Die Erfassungsmethode legt die Obergrenze dafür fest, wie schnell Sie überhaupt reagieren können: Kein Filter greift, bevor Sie von dem Angriff erfahren.
Warum ist die Erkennungszeit hier entscheidend?
Ein volumetrischer Angriff sättigt eine Leitung in einigen Dutzend Sekunden. Erreichen die Verkehrsdaten den Sensor mit einer Verzögerung, die der Dauer des Angriffs selbst entspricht, reagiert die Abwehr auf einen Trümmerhaufen. Ausführlich beschrieben haben wir das im Beitrag über einen DDoS-Angriff auf einen ISP aus Sicht des NOC.
Woher kommt die Verzögerung bei NetFlow? Der Router meldet ein Paket nicht sofort. Er legt Flow-Einträge im Speicher an, aggregiert sie und exportiert sie erst nach Ablauf definierter Timeouts: active flow timeout und inactive flow timeout. Hinzu kommt die Verarbeitungszeit der Datagramme auf Seiten des Sensors. In der Praxis vergehen zwischen dem ersten Angriffspaket und dem Moment, in dem das System es sehen kann, 35–95 s.
Beim Port-Mirroring entfällt dieser Schritt: Switch oder Router kopieren die Pakete im selben Moment auf den Monitoring-Port, in dem sie sie weiterleiten. Daher der Unterschied: RTBH nach etwa 1 s und selektive Filterung nach 6–10 s gegenüber 35–95 s. Bei kurzen Pulsangriffen unter 30 Sekunden entscheidet er darüber, ob der Angriff überhaupt bemerkt wird.
Worin unterscheiden sich Port-Mirroring und NetFlow?
| Kriterium | Port-Mirroring (Verkehrskopie) | NetFlow / IPFIX / sFlow / jFlow |
|---|---|---|
| Erkennungszeit | RTBH nach etwa 1 s, selektive Filterung nach 6–10 s | 35–95 s (Flow-Export) |
| Sichtbarkeit | 100 %, jedes Paket | gesampelt, jedes n-te Paket |
| Genauigkeit während eines Angriffs | vollständig | geringer Fehler, steigt mit der Sampling-Rate |
| Routerlast | minimal, passives Kopieren | spürbar, Flow-Erzeugung kostet CPU |
| Verkabelung | Ports + Kabel erforderlich | keine zusätzlichen Kabel |
| Schicht | funktioniert unabhängig von L3 | am einfachsten auf L3-Geräten |
| Skalierbarkeit | begrenzt durch die Anzahl der Ports | praktisch unbegrenzt |
| Pulsangriffe (<30 s) | werden erkannt | oft unsichtbar |
| Einführungskosten | Ports, Kabel, ggf. TAP | meist keine, Funktion des Geräts |
Zwei Dinge werden in der Planungsphase leicht übersehen.
Erstens kopiert Port-Mirroring den Verkehr in beide Richtungen. Eine Leitung mit 5 Gbit/s RX plus 5 Gbit/s TX ergibt 10 Gbit/s am Monitoring-Port. Hat der Monitoring-Port dieselbe Geschwindigkeit wie der überwachte Port, verlieren Sie bei Volllast Pakete. Das ist der häufigste Fehler beim ersten Deployment.
Zweitens unterliegt das gleichzeitige Spiegeln mehrerer Ports oder VLANs Plattformbeschränkungen: Anzahl der Sessions, unterstützte Richtungen, Koexistenz mit anderen Funktionen. Prüfen Sie die Dokumentation Ihrer Hardware (Cisco: SPAN/RSPAN/ERSPAN und Einschränkungen der Nexus-Plattformen; Juniper: Einschränkungen beim Port-Mirroring auf EX-Switches).
Wie groß ist der Fehler durch NetFlow-Sampling?
Kleiner, als die Intuition vermuten lässt. Laut dem Cisco-Live-Vortrag BRKSPG-3335 („DDoS Mitigation Deployment: Impact on your Architecture“, Nicolas Fevrier, Rajendra Chayapathi, Syed Hassan) hat eine Änderung der Sampling-Rate nur geringen Einfluss auf die Fähigkeit, einen Angriff zu erkennen, führt jedoch einen Messfehler ein. Für einen generischen Flood-Angriff (Pakete mit 84 B, verteilter Angriff mit 100 Mbit/s auf ein Router-Interface):
| Sampling | Fehler |
|---|---|
| 1:1.000 | 2,1 % |
| 1:2.000 | 2,9 % |
| 1:4.000 | 2,9 % |
| 1:10.000 | 6,5 % |
Praktische Schlussfolgerung: Bei einem großen, anhaltenden volumetrischen Angriff genügt selbst ein Sampling von 1:10.000, um festzustellen, dass „etwas passiert“. Das Problem ist also nicht die Genauigkeit des Volumens, sondern die Verzögerung und die Unsichtbarkeit seltener Ereignisse: Ein über ein ganzes Subnetz verteilter Angriff, bei dem keine einzelne Adresse den Schwellenwert überschreitet, kann bei aggressivem Sampling im Rauschen untergehen.
Was tun, wenn keine Ports frei sind?
Es gibt zwei Auswege, beide im Produktivbetrieb im Einsatz.
Optischer TAP, passiv oder aktiv. Sind die Ports ausgegangen oder funktioniert NetFlow nicht wie vorgesehen, liefert ein in die optische Strecke eingefügter TAP eine Verkehrskopie, ohne den Router einzubeziehen. Ein passiver TAP benötigt keine Stromversorgung und ist kein Single Point of Failure; ein aktiver bietet mehr Möglichkeiten (Signalregeneration, Aggregation der Richtungen), benötigt aber Strom. Um die Kopie auf mehrere Analysesysteme zu verteilen, kommt ein Packet Broker zum Einsatz.
Gesampelter Verkehr statt vollständiger Kopie. Ist das Netz groß und können Sie sich das Spiegeln jedes WAN-Ports nicht leisten, kann der Router jedes zehnte Paket an den Sensor senden; aus 30 Gbit/s werden dann 3 Gbit/s zur Analyse.
Die Analyse der Verkehrskopie erfordert auf dem Sensor eine Packet-Capture-Engine. WanGuard unterstützt mehrere Varianten, die sich in Durchsatz, Kosten und Komplexität der Einrichtung unterscheiden:
| Capture-Engine | Geschwindigkeiten | Kosten | Komplexität |
|---|---|---|---|
| Embedded LibPcap | 1–4 Gbit/s | keine | keine |
| System LibPcap | 1–4 Gbit/s | keine | keine |
| Myricom Sniffer 10G | 10 Gbit/s | Lizenz pro Karte | mittel |
| PF_RING | 10/40 Gbit/s | Lizenz pro MAC | zusätzliches Kernelmodul / mittel |
| Netmap | 10/40 Gbit/s | keine | zusätzliches Kernelmodul / hoch |
| DPDK | 10/40 Gbit/s | keine | zusätzliches Kernelmodul / hoch |
Faustregel: Bis 4 Gbit/s reicht ein gewöhnliches LibPcap. Darüber ist eine Engine nötig, die den Netzwerkstack des Kernels umgeht, sonst verliert der Sensor genau dann Pakete, wenn Sie ihn am dringendsten brauchen: während eines Angriffs. Die Rolle des Sensors in der Architektur beschreiben wir im Beitrag Was ist WanGuard?
Welche Methode passt zu Ihrem Netz?
Ausgangspunkt sind zwei Variablen: die Angriffstypen, mit denen Sie rechnen, und die Bandbreite, die Sie überwachen müssen. Eine vereinfachte Entscheidungsregel:
- Freie Ports und am Netzrand ein Verkehr im niedrigen zweistelligen Gbit/s-Bereich: Port-Mirroring. Kürzeste Erkennungszeit, geringste Routerlast, die wenigsten Überraschungen.
- Großes Netz, viele WAN-Ports, mehrere Dutzend Gbit/s: NetFlow / IPFIX, gegebenenfalls ergänzt durch Mirroring auf den kritischsten Leitungen.
- Keine freien Ports, und NetFlow verhält sich auffällig: optischer TAP.
- Schutz vor kurzen Pulsangriffen ist Ihnen wichtig: Mirroring oder gesampelter Verkehr. Klassisches NetFlow zeigt diese Angriffe schlicht nicht rechtzeitig an.
Die Lösungen schließen sich nicht gegenseitig aus. Ein typisches Deployment bei einem mittelgroßen ISP kombiniert beide: Mirroring dort, wo die Reaktionszeit zählt, NetFlow zur Abdeckung des übrigen Netzes und als Datenquelle für Reporting und Kapazitätsplanung. Wenn Sie unsicher sind, welche Variante zu Ihrer Topologie passt, schreiben Sie uns; die Wahl der Erfassungsmethode ist der erste Schritt jeder Einführung von WanGuard.
Häufig gestellte Fragen
Belastet Port-Mirroring den Router?
Nur geringfügig. Das Kopieren eines Frames auf den Monitoring-Port übernimmt in der Regel der Switching-Chip, nicht die CPU. Die Flow-Erzeugung für NetFlow ist deutlich aufwendiger, weil sie eine Flow-Tabelle und einen periodischen Export erfordert. Achten Sie auf Ausnahmen: Das gleichzeitige Spiegeln mehrerer VLANs oder Richtungen kann auf manchen Plattformen einen langsameren Verarbeitungspfad auslösen.
Wie viel Bandbreite braucht der Monitoring-Port?
So viel wie die Summe beider Richtungen der überwachten Leitung. Eine Leitung mit 5 Gbit/s RX + 5 Gbit/s TX ergibt 10 Gbit/s Kopie. Ein Monitoring-Port mit derselben Geschwindigkeit wie der überwachte Port verliert bei höherer Last Pakete; planen Sie daher mit Reserve oder verteilen Sie die Richtungen auf separate Ports.
Reicht sFlow zur Erkennung von DDoS-Angriffen?
Zur Erkennung eines großen volumetrischen Angriffs: ja. Das Sampling bringt einen Fehler von einigen Prozent mit sich, was die Feststellung, dass die Leitung gesättigt wird, nicht behindert. Zur Erkennung kurzer, volumenschwacher oder über ein ganzes Subnetz verteilter Angriffe: meist nicht. Dafür ist volle Sichtbarkeit nötig.
Wozu ein TAP, wenn ich Port-Mirroring habe?
Ein TAP ist in drei Situationen sinnvoll: wenn keine Ports mehr frei sind, wenn Sie ein Produktivgerät nicht mit einer zusätzlichen Funktion belasten wollen und wenn Sie eine Verkehrskopie benötigen, die unabhängig von der Router-Konfiguration ist. Ein passiver TAP arbeitet auch dann weiter, wenn das Gerät neu startet oder jemand die Mirroring-Session löscht.
