6. Oktober 2026
·
13 Min. Lesezeit
DDoS-Schutz im eigenen Netz: RTBH nach etwa 1 s, Filterung nach 6–10 s, feste Kosten; Cloud-Scrubbing fängt Angriffe über der Uplink-Kapazität ab.
Kurz gesagt: Beim DDoS-Schutz im eigenen Netz wird Angriffsverkehr auf Ihren eigenen Routern erkannt und verworfen, mit RTBH nach etwa 1 s und selektiver Filterung nach 6–10 s, zu festen Kosten und ohne dass Verkehr das Netz verlässt. Ein Scrubbing-Center in der Cloud ist eine Einrichtung eines externen Anbieters, an die Sie Verkehr umleiten, damit er bereinigt und zurückgeschickt wird: Es ist genau dann im Vorteil, wenn der Angriff größer ist als Ihr Uplink. Für die meisten Betreiber lautet die ehrliche Antwort nicht „entweder oder“, sondern „das eine als erste Verteidigungslinie, das andere als Eskalation“.
Zwei Modelle, zwei verschiedene Stellen im Netz
Beide Ansätze lösen dasselbe Problem, aber an einem anderen Punkt der Topologie, und diese eine Unterscheidung erklärt praktisch alle Unterschiede, die Sie weiter unten sehen.
Filterung im eigenen Netz bedeutet, dass Erkennung und Reaktion auf Infrastruktur stattfinden, die Sie selbst betreiben: Der Sensor beobachtet Verkehr, der ohnehin durch Ihr Netz läuft, und die Filterregel landet auf Ihrem Edge-Router oder auf einem Filterserver. Der Verkehr ändert seinen Weg nicht.
Ein Scrubbing-Center ist ein entferntes Rechenzentrum mit sehr großer Backbone-Kapazität. Im Angriffsfall kündigen Sie Ihre Präfixe per BGP an (oder leiten den Verkehr per DNS um), der Verkehr läuft dorthin, wird bereinigt und kehrt über einen Tunnel oder eine dedizierte Leitung zu Ihnen zurück.
Die Wahl hängt an vier Hebeln: Reaktionszeit, Kostenmodell, Kontrolle über den Verkehrsweg und absorbierbare Kapazität. Keine der Optionen gewinnt bei allen vier.
Das Umfeld wird dabei zunehmend unbequem. Cloudflare berichtet, dass die Zahl der DDoS-Angriffe 2025 um 121 % gegenüber dem Vorjahr stieg und im Durchschnitt 5.376 Angriffe pro Stunde gefiltert wurden; Telekommunikation, Service Provider und Carrier waren bei Angriffen mit extrem hohem Volumen die am häufigsten angegriffene Branche (Cloudflare, Q4 2025 DDoS Threat Report, Februar 2026). NETSCOUT verzeichnete im zweiten Halbjahr 2025 über 8 Millionen Angriffe in 203 Ländern, von denen rund 42 % zwei bis fünf Vektoren gleichzeitig nutzten (NETSCOUT DDoS Threat Intelligence Report, Ausgabe 16, März 2026).
DDoS-Schutz im Vergleich: lokale Filterung oder Scrubbing in der Cloud
Die folgende Tabelle fasst die Kriterien zusammen, die bei ISPs, im Hosting und in Unternehmen mit eigenem Verkehr tatsächlich über die Wahl entscheiden.
| Kriterium | Im eigenen Netz (z. B. WanGuard) | Scrubbing-Center in der Cloud |
|---|---|---|
| Erkennungszeit | RTBH nach etwa 1 s, selektive Filterung nach 6–10 s mit Port-Mirroring / DPDK | Dutzende Sekunden bis Minuten (Umleitung + BGP-Konvergenz) |
| Ort der Filterung | Ihre Edge-Router | Rechenzentrum des externen Anbieters |
| Kostenmodell | Einmalige Implementierung + Lizenz + Support | Abrechnung pro Gbps / pro bereinigtem Verkehr: steigt mit der Angriffsgröße |
| Verkehrsweg | Der Verkehr verlässt Ihr Netz nicht | Der Verkehr läuft über einen Dritten |
| Datensouveränität | Vollständig, im Netz (NIS2, Telekommunikationsrecht) | Verkehr und Metadaten überschreiten die Grenze Ihrer Infrastruktur |
| Latenz im Normalbetrieb | Keine zusätzliche | Zusätzlich im Always-on-Modus; keine bei On-Demand |
| Volumetrische Obergrenze | Kapazität Ihrer Uplinks | Terabit-Maßstab, Backbone des Anbieters |
| Kontrolle und Tuning | Ihre Schwellenwerte, Ausnahmen und Richtlinien | Logik des Anbieters, gemeinsam genutzte Plattform |
Die Tabelle ist bewusst in beide Richtungen schonungslos. Es gibt keine Zeile, in der eine Spalte „insgesamt“ gewinnt: Es gibt Zeilen, in denen die eine gewinnt, und Zeilen, in denen die andere gewinnt.
Wie funktioniert die Filterung eines Angriffs im eigenen Netz?
Es handelt sich um Software (seltener um dedizierte Hardware), die Angriffsverkehr innerhalb Ihres Netzes erkennt und verwirft, auf Servern und Routern, die Sie verwalten. Eine Plattform wie WanGuard profiliert den Produktivverkehr, lernt eine Baseline des „Normalzustands“ pro Subnetz, pro Adresse und pro Decoder, meldet bei einer Abweichung eine Anomalie und greift dann auf den verfügbaren Filtermechanismus zurück. Nichts wird irgendwohin umgeleitet.
Die Reaktion erfolgt in der bestehenden Forwarding Plane:
- BGP FlowSpec: eine präzise Regel nach 5-Tupel, die auf dem Router mit Leitungsgeschwindigkeit ausgeführt wird. Ausführlich beschrieben im Beitrag zur Filterung von Angriffen mit BGP-FlowSpec-Regeln.
- RTBH: Blackholing als letzte Option, wenn sich der Angriff nicht mehr granular trennen lässt. Wann das sinnvoll ist und wann es einer Kapitulation gleichkommt, erläutern wir im Beitrag zu RTBH.
- DPDK-Filterserver, inline oder out-of-path, bei 10/40/100 GE.
Da Erkennung und Reaktion beide an Ihrem Netzrand angesiedelt sind, beträgt die Antwortzeit etwa 1 s für RTBH und 6–10 s für die selektive Filterung und hängt nicht von der Zeit ab, die das Umlenken von Verkehr im Internet benötigt. Dieses Modell implementiert und betreibt ITORO als Anti-DDoS-Dienstleistung auf Basis von WanGuard.
Eine ehrliche Einschränkung: Dieses Modell setzt voraus, dass bei Ihnen jemand das Netz versteht. Schwellenwerte müssen abgestimmt und Ausnahmen beschrieben werden, und die Umleitung von Verkehr auf einen Filterserver kann in einem Netz mit nur einem Router architektonisch schwierig sein. Es ist keine Box, die man einschaltet und vergisst.
Was ist ein Scrubbing-Center und was leistet es tatsächlich?
Ein Scrubbing-Center ist eine Einrichtung eines externen Anbieters mit großer Backbone-Kapazität, die Ihren Verkehr außerhalb Ihres Netzes filtert („schrubbt“). Beginnt ein Angriff, wird der Verkehr dorthin umgeleitet: meist durch Ankündigung der Präfixe per BGP, seltener per DNS-Umleitung. Das Center verwirft den Angriffsverkehr und schickt den bereinigten Datenstrom über einen Tunnel oder eine dedizierte Leitung zurück.
Ein Scrubbing-Center existiert vor allem aus einem Grund: Kapazität. Ein Anbieter mit einem Backbone von mehreren Terabit absorbiert einen Flood, der den Uplink eines einzelnen Betreibers in wenigen Sekunden sättigen würde. Das ist ein realer, gewichtiger Vorteil, und es gibt keinen Grund, ihn zu relativieren.
Der Preis für diesen Vorteil ist architektonisch, nicht nur finanziell:
- Der Verkehr läuft über Infrastruktur, die Sie nicht kontrollieren.
- Die Filterung wartet auf die Umleitung und die BGP-Konvergenz.
- Das kommerzielle Modell rechnet meist pro Gbps bereinigten Verkehrs ab: Die Rechnung wächst also mit der Größe des Angriffs, gegen den Sie sich verteidigen.
- Die Richtlinien legt der Anbieter fest, und sie gelten zugleich für andere Kunden. Ihr untypischer Verkehr (z. B. produktives UDP, Gaming, VoIP) wird mitunter fälschlich verworfen, und das Tuning läuft über ein Ticket, nicht über Ihre Konsole.
Wie viel Zeit verlieren Sie durch die Umleitung des Verkehrs?
Die Erkennungszeit ist der Faktor, den Betreiber unterschätzen und Angreifer ausnutzen.
Die Erkennung per Port-Mirroring analysiert eine Kopie jedes Pakets mit Leitungsgeschwindigkeit (DPDK, PF_RING), erkennt einen volumetrischen Flood daher sofort und löst RTBH nach etwa 1 s aus; die selektive Filterung greift nach 6–10 s. Die Erkennung per NetFlow / sFlow / IPFIX ist einfacher zu implementieren, kostet aber die Verzögerung des Flow-Exports aus dem Router, in der Praxis 35–95 s.
Ein Scrubbing-Center kann nichts tun, solange der Verkehr es nicht erreicht. Präfix-Ankündigung, Propagation, BGP-Konvergenz, Aufbau des Rückwegs: Das sind Dutzende Sekunden, manchmal Minuten, je nach Netzaufbau und davon abhängig, ob der Rücktunnel dauerhaft besteht.
Dieser Unterschied entscheidet über das Ergebnis. Wenn ein Rekord-Flood eine Spitze von 31,4 Tbps erreicht und 35 Sekunden dauert (Cloudflare, Februar 2026), kann ein Abwehrpfad, der eine halbe Minute zum Anlaufen braucht, den Angriff vollständig verpassen oder genau dann greifen, wenn der Angriff endet. Die lokale Filterung liegt bereits im Verkehrsweg: Es gibt keinen Schritt „umleiten“, auf den man warten müsste.
Es gibt zwei Zwischenvarianten, und beide haben ihren Preis:
- Always-on-Scrubbing beseitigt die Umleitungsverzögerung, fügt aber dem gesamten Verkehr eine dauerhafte Latenz und dauerhafte Kosten hinzu, weil der gesamte Verkehr ständig inspiziert wird.
- On-Demand-Scrubbing fügt im Normalbetrieb keine Latenz hinzu, bringt die Umleitungsverzögerung aber genau dann zurück, wenn die Lage am schlechtesten ist.
Die Filterung im eigenen Netz umgeht beide Probleme, allerdings nur für Angriffe, die in Ihren Uplink passen. Das ist der Kern des gesamten Vergleichs.
Kosten: feste Lizenz oder Rechnung pro Gbps
Die Kostenstrukturen unterscheiden sich grundlegend, und der Unterschied summiert sich genau in den Momenten, in denen Schutz gebraucht wird.
Das lokale Modell besteht aus einer einmaligen Implementierung plus Lizenz und Support-Stufe. Die Kosten sind unabhängig von der Angriffsgröße konstant, weil Sie die Filterkapazität bereits haben. Die Budgetplanung ist vorhersehbar: Ein größerer Angriff bedeutet keine höhere Rechnung. Hinzu kommt ein selten erwähnter Nebeneffekt: Der Sensor liefert Datenaufbewahrung und detaillierte Verkehrsberichte, sodass Sie nebenbei Daten für die Planung des Transit-Einkaufs erhalten.
Scrubbing wird meist pro Gbps bereinigten Verkehrs oder nach einer Burst-Kapazitätsschwelle abgerechnet. Das Modell ist flexibel, was attraktiv klingt, in der Praxis aber bedeutet, dass die Kosten mit der Angriffsgröße skalieren. Eine mehrtägige Kampagne oder eine Serie wiederholter Angriffe, wie wir sie bei Lösegelderpressungen sehen, macht aus einem planbaren Budgetposten eine Variable, die genau dann ihren Höchststand erreicht, wenn Sie unter dem größten Druck stehen.
Zur Vollständigkeit gehört die andere Seite: Das lokale Modell erfordert eine Investition im Voraus, bevor irgendetwas passiert, und Kompetenz für den Betrieb. Für eine Organisation ohne Netzwerkteam, die auch keines aufbauen will, kann ein Abonnement beim Anbieter eine rationale Entscheidung sein, selbst wenn es über einige Jahre teurer ausfällt.
Beträge nennen wir in Blogbeiträgen nicht, weil sich die Preisliste unabhängig davon weiterentwickelt. Aktuelle Preise und den Kalkulator finden Sie auf der Seite Preise.
Warum hat der Verkehrsweg regulatorische Bedeutung?
Wo Verkehr bereinigt wird, ist nicht nur eine Frage der Leistung. Es ist auch eine Frage von Compliance und Vertrauen.
Lokale Filterung hält jedes Paket und seine Metadaten innerhalb Ihres Netzes. Für ISPs, Telekommunikationsanbieter und regulierte Einrichtungen ist das relevant: Wer Kundenverkehr über ein Scrubbing-Center führt, schickt Teilnehmerdaten und Verkehrsmuster durch Infrastruktur, die er nicht kontrolliert. Unter NIS2 (in Deutschland umgesetzt durch das NIS2UmsuCG) und sektorspezifischen Vorschriften wirft das Fragen auf, deren Antworten in der Dokumentation stehen sollten, nicht erst im Gespräch mit dem Auditor.
Ähnlich verhält es sich mit der Kontrolle. Lokal haben Sie eigene Schwellenwerte, Ausnahmen und Richtlinien, auch für jenen unschönen, untypischen Verkehr, der beim Anbieter unter eine allgemeine Regel fallen würde. Eine gemeinsam genutzte Cloud-Plattform wendet vom Anbieter definierte Logik auf viele Kunden gleichzeitig an. Das ist effizient, für Ihr konkretes Netz aber weniger präzise.
Aus unserer Beobachtung: Die Betreiber, die am genauesten nach dem Verkehrsweg fragen, sind jene mit der stärksten regulatorischen Exposition. Für sie ist die Filterung im eigenen Netz keine Vorliebe, sondern eine Anforderung.
Wann ist Scrubbing in der Cloud tatsächlich im Vorteil?
Es hat einen ausschlaggebenden Vorteil: Es absorbiert Angriffe, die größer sind als Ihr Uplink. Das ist die ehrliche Grenze jeder lokalen Lösung, und kein Tuning hebt sie auf.
Sie können nicht mehr Verkehr filtern, als Ihre Leitungen physisch transportieren. Ein Flood, der die Leitung oberhalb Ihrer Router sättigt, verstopft sie, bevor Ihr Filter überhaupt freie Kapazität sieht. Physik lässt sich nicht überlisten, und jeder Anbieter, der etwas anderes behauptet, verkauft etwas anderes als Ingenieursarbeit.
Scrubbing (oder die Eskalation beim Transit-Provider) ist der richtige Schritt, wenn:
- der Flood den Terabit-Bereich erreicht oder schlicht die gebuchte Bandbreite übersteigt,
- der Angriff mehrere Vektoren nutzt und lange andauert und Sie kein Team haben, das ihn rund um die Uhr bearbeitet,
- Sie einen Dienst mit einem Profil betreiben, das regelmäßig große Volumina auf sich zieht (Gaming, öffentliches DNS, große Medienportale).
Ein glaubwürdiger Anbieter sagt Ihnen das vor der Vertragsunterzeichnung, nicht während eines Vorfalls.
Hinzu kommt eine dritte Variante, die viele Betreiber übersehen: Filterung beim Transit-Provider mit BGP-FlowSpec-Regeln. Einige Transit-Provider nehmen FlowSpec-Regeln von Kunden an und setzen sie an ihrem eigenen Netzrand um. Dann wird die Obergrenze dessen, was Sie verwerfen können, nicht mehr durch Ihren Uplink bestimmt, ohne Umleitung des Verkehrs und ohne Gebühr pro Gbps.
Fazit: erste Linie im eigenen Netz, Eskalation weiter oben
Für die meisten Betreiber gewinnt keines der Modelle allein; die belastbarste Architektur kombiniert beide.
Erste Ebene: Ihr Netz. RTBH nach etwa 1 s, selektive Filterung vor Ort nach 6–10 s, kein Verkehr nach außen, feste Kosten. Sie bewältigt die überwältigende Mehrheit der Angriffe, weil die Verteilung der Angriffe nach Volumen stark schief ist: Es dominieren kleine und mittlere Angriffe, die in den Uplink passen.
Zweite Ebene: Eskalation. Blackholing beim Upstream-Provider, eine nach oben weitergereichte FlowSpec-Regel oder ein Scrubbing-Center. Sie wird aktiviert, wenn das Volumen übersteigt, was die Leitungen transportieren.
Automatisierung sorgt dafür, dass das funktioniert. WanGuard filtert zunächst granular per BGP-FlowSpec-Regel, wechselt zu RTBH, wenn sich die Uplinks der Sättigung nähern, und signalisiert Eskalationsbedarf, wenn das Volumen die Leitungskapazität übersteigt. Sie erhalten im typischen Fall bei Erkennung per Port-Mirroring eine selektive Filterung nach 6–10 s (RTBH bei Bedarf nach etwa 1 s) und im seltenen Fall eine Absicherung im Terabit-Maßstab.
Was dieses Modell nicht bietet: die Garantie, dass jeder Angriff spurlos herausgefiltert wird. Das bietet niemand. Es sorgt aber dafür, dass der Dienst bei den meisten Vorfällen weiterläuft und Sie bei den seltenen, größten einen geplanten Pfad haben statt Improvisation um drei Uhr nachts.
ITORO, Gold Partner von Andrisoft, plant, implementiert und betreibt genau diese Architektur für ISPs, Hosting-Anbieter und Unternehmen. Details zur Architektur finden Sie auf der Seite zu WanGuard.
Häufige Fragen
Was ist besser: Filterung im eigenen Netz oder Scrubbing in der Cloud?
Das hängt von der Angriffsgröße ab. Lokale Filterung ist schneller (mit Port-Mirroring RTBH nach etwa 1 s, selektive Filterung nach 6–10 s), hat feste Kosten und lässt keinen Verkehr aus dem Netz, gewinnt also bei allem, was in den Uplink passt. Scrubbing gewinnt ausschließlich bei Floods, die die Leitungskapazität übersteigen. Die meisten Betreiber betreiben beide Ebenen parallel.
Was ist ein Scrubbing-Center?
Eine Einrichtung eines externen Anbieters mit großer Backbone-Kapazität, die Ihren Verkehr außerhalb Ihres Netzes filtert. Im Angriffsfall wird der Verkehr per BGP oder DNS dorthin umgeleitet, bereinigt und zurückgeschickt. Die Stärke liegt im Absorbieren von Floods im Terabit-Maßstab; der Preis: Umleitungsverzögerung, Abrechnung pro Gbps und Verkehr, der über einen Dritten läuft.
Wie viel schneller reagiert die Filterung in meinem Netz?
Bei Erkennung per Port-Mirroring greift RTBH nach etwa 1 s und die selektive Filterung nach 6–10 s, weil das System Verkehr analysiert, der bereits durch Ihr Netz fließt. Ein Scrubbing-Center muss den Verkehr erst übernehmen, und Umleitung plus BGP-Konvergenz dauern meist Dutzende Sekunden bis Minuten. Bei Rekord-Floods von 35 Sekunden Dauer (Cloudflare, Februar 2026) ist dieser Unterschied ausschlaggebend.
Stoppt die Filterung im eigenen Netz einen Angriff im Terabit-Maßstab?
Allein nicht. Sie ist durch die Kapazität Ihrer Uplinks begrenzt, daher muss ein Flood, der größer ist als die Leitungen, weiter oben gestoppt werden. Ein vernünftiges Design sieht deshalb zwei Ebenen vor: lokale Filterung für alles, was in die Leitung passt, und für den Rest die Eskalation zu Blackholing beim Upstream-Provider, zu einer FlowSpec-Regel an dessen Netzrand oder zu einem Scrubbing-Center.
Ist eine lokale Lösung teurer als ein Cloud-Abonnement?
Über einige Jahre betrachtet meist nicht. Lokal bedeutet einmalige Implementierung plus Lizenz und Support, feste Kosten unabhängig von der Angriffsgröße. Scrubbing wird pro Gbps bereinigten Verkehrs abgerechnet, wächst also mit dem Angriff und erreicht bei langen Kampagnen den Höchststand. Dafür erfordert das lokale Modell eine Anfangsinvestition und Kompetenz für den Betrieb. Aktuelle Preise finden Sie auf der Seite Preise.
Warum spielt der Verkehrsweg unter NIS2 eine Rolle?
Weil lokale Filterung jedes Paket innerhalb Ihres Netzes hält, während Scrubbing Ihren Verkehr samt Teilnehmerdaten und Verkehrsmustern über einen Dritten führt. Für ISPs, Telekommunikationsanbieter und regulierte Einrichtungen ist ein Verkehrsweg innerhalb des eigenen Netzes oft eine Compliance-Anforderung und nicht nur eine architektonische Vorliebe.
