Produkte

AI Adoption & Privacy

AI Workspace
Preise

Network Security Preise

Network DDoS Protection
Partner
Über Myra
Login
WAAP (Myra App) AI Workspace EU CAPTCHA Partnerportal
Deutsch English Français
Notfall Demo
Produkte
Application Security DDoS Protection Web Application Firewall CDN Bot Management CAPTCHA Network Security Network DDoS Protection (cloud) Network DDoS Protection (on-prem) Network DDoS Protection (hybrid)

AI Adoption & Privacy

AI Workspace
Preise

Application Security Preise

DDoS Protection, WAF, CDN, Bot Management EU CAPTCHA

Network Security Preise

Network DDoS Protection
Partner
Über Myra

Unternehmen

Über uns Karriere News & Insights Eventplan 2026 Presse

Warum Myra?

Referenzen & Case Studies Zertifizierungen Migration Integrationen DSGVO-Konformität Digitale Souveränität

Myra im Vergleich

Myra vs. Wettbewerber Cloudflare Alternative Akamai Alternative F5 Alternative
Login WAAP Login AI Workspace Login EU CAPTCHA Partnerportal English Français
Notfall Demo

Aktualisiert am 11.10.2026

DDoS-Schutz für Rechenzentren und IP-Netze: Cloud-Scrubbing, On-Premise oder hybrid

Ein ganzes IP-Netz schützen Sie per Cloud-Scrubbing, bei dem ein Dienstleister den Verkehr per BGP in sein Scrubbing-Center holt und bereinigt zurückschickt, mit einer Filtereinheit im eigenen Rechenzentrum (On-Premise) oder hybrid mit beidem. Meist entscheidet das Ihre Leitung. Ist der Angriff größer als der Uplink, muss davor gefiltert werden, und umleiten lässt sich per BGP nur ein Präfix, das der Rest des Internets annimmt (Stand: Oktober 2026).

Warum die eigene Leitung die Grenze zieht

Schon ein Angriff auf eine einzelne IP-Adresse kann laut RFC 7999 die Leitungen zu den Nachbarnetzen verstopfen. Was sich vor Ihrem Edge-Router staut, sieht die Appliance dahinter nie, sie filtert also höchstens so viel weg, wie Ihre Anbindung (und die Appliance selbst) hergibt. Alles, was darüber liegt, muss vorher jemand abfangen, der Upstream-Provider etwa oder ein Scrubbing-Center.

Cloud-Scrubbing funktioniert, weil der Dienstleister einen Teil Ihres Adressraums aus seinem eigenen Netz ankündigt, und zwar spezifischer als Sie. Nehmen wir an, Sie kündigen ein /22 über zwei Upstreams an, A und B. Jemand greift eine Adresse im dritten /24 an, also kündigt der Dienstleister genau dieses /24 an. Weil Router laut RFC 1812 die spezifischste passende Route nehmen müssen (Longest Match), landet der Verkehr zu dem /24 bei ihm, gleich ob er vorher über A oder über B hereinkam. Die anderen drei /24 laufen ganz normal weiter. Denselben Ablauf, mit Rückweg über eine eigene Verbindung, spielt RFC 9319 als Beispiel durch.

Kündigt der Dienstleister dagegen dasselbe /22 an wie Sie, greift kein Longest Match. Jeder BGP-Router wählt dann nach RFC 4271 eine Route aus, zuerst nach lokaler Policy, bei Gleichstand unter anderem nach dem kürzeren AS-Pfad. Ein Teil des Angriffs kommt also weiter direkt über A oder B. Verlässlich wird es erst, wenn Sie das /22 bei A und B zurückziehen, und dann läuft das ganze /22 über den Dienstleister.

On-Premise heißt: Die Scrubbing-Einheit sitzt hinter Ihren Edge-Routern. Die Umschaltzeit fällt weg, die Erkennungszeit bleibt. Bei Hybrid nimmt die lokale Einheit kleinere und mittlere Angriffe, wird es mehr, kommt die Umleitung in die Cloud dazu.

Entscheidungstabelle

Kriterium Cloud-Scrubbing (BGP) On-Premise Hybrid
Angriff größer als die eigene Anbindung bis zur Kapazität des Dienstleisters nicht abwehrbar, Leitung vorher voll über die Cloud-Umleitung
Kleine und mittlere Angriffe On-Demand erst nach der Umleitung, Always-on ohne Umschaltung ohne Umleitung, nur Erkennungszeit lokal, ohne Umleitung
Kleinstes schützbares Netz im Internet üblich: /24 (IPv4), /48 (IPv6) keine Routing-Grenze lokal keine; Cloud-Teil klären
Hardware im eigenen RZ keine Scrubbing-Hardware, aber Flow-Collector und Tunnelendpunkt ja (Rack, Strom, Einbindung) ja
Verkehr über fremde Rechenzentren eingehend: Always-on dauerhaft, On-Demand im Angriffsfall nein nur bei großen Angriffen
Umschaltzeit On-Demand: Erkennung plus BGP-Umleitung entfällt lokal entfällt sie, zur Cloud wie On-Demand
Vorarbeit ROA, Route-Objekte, Absprache mit dem Provider, Rückweg testen Platz, Betrieb, Kapazitätsplanung beides
Passt zu eigenem Adressraum ab /24, Angriffen über Leitungskapazität kleinen Netzen, vielen kleineren Angriffen schneller lokaler Reaktion plus Reserve

Zur Kapazität: Das BSI hat bei der Qualifizierung von DDoS-Mitigation-Dienstleistern „bewusst auf die Bewertung von Bandbreiten verzichtet“, weil sich Angriffsbandbreiten dynamisch entwickeln und die nötige Schutzkapazität vom Ziel abhängt. Die Mitigationsleistung besprechen Sie mit dem Anbieter.

Always-on oder On-Demand

Das BSI fragt in Kriterium 4.3.2, ob die Umleitung „dauerhaft, also auch zu Zeiten, wo kein DDoS-Angriff stattfindet“ besteht oder nur im Angriffsfall. Always-on spart die Umschaltung. Dafür läuft der gesamte eingehende Verkehr zu Ihren Präfixen ständig über die Rechenzentren des Dienstleisters; Ihr ausgehender Verkehr nimmt weiter den eigenen Weg. Wo diese Rechenzentren stehen, betrifft Sie dann jeden Tag. Das BSI führt die Beschränkung auf Rechenzentren in Deutschland oder der EU als eigenes Kriterium 4.2.4, weil der Verkehr „zumindest im Falle einer Mitigation“ über die Rechenzentren des Dienstleisters fließt.

Mit On-Demand fassen Sie im Alltag am Routing nichts an. Der Haken ist die Zeit im Ernstfall, und die verteilt sich auf vier Etappen, die man getrennt betrachten sollte. Etappe eins: Die Flow-Daten müssen zum Analysesystem, die Schwelle muss anschlagen. Das hängt zum guten Teil an Ihren eigenen Exportern. Etappe zwei: Startet die Mitigation von selbst, oder wartet sie auf einen manuellen Start oder Ihre Anweisung? Genau das fragt BSI-Kriterium 4.3.3 ab. Etappe drei ist BGP, also die Zeit, bis sich die neue Ankündigung bei den Nachbarnetzen durchgesetzt hat, Etappe vier der Rückweg, der sofort Pakete in voller Größe tragen muss. Zahlen dafür schreibt kein Standard vor, und eine einzelne Gesamtzahl hilft Ihnen wenig, weil man ihr nicht ansieht, wo die Sekunden hängen bleiben. Fragen Sie nach gemessenen Werten je Etappe.

Mindestnetzgröße: warum /24 und /48

Das more specific hilft Ihnen nur, solange die anderen Netze es auch annehmen, und genau da wird es eng. RFC 7454 (BCP 194, von 2015) beruft sich auf die RIPE-Community, nach der IPv4-Präfixe länger als /24 und IPv6-Präfixe länger als /48 im Internet „generally neither announced nor accepted“ werden; dass sich das ändern kann, schreibt der RFC gleich dazu. Bei IPv6 im PA-Adressraum nennt RIPE-532 /48 als die Grenze, bis zu der die Mehrheit der Provider annimmt. Beim /24 lohnt ein Blick in RIPE-399: Es entspricht der Größe des früheren Class-C-Netzes, und dass die meisten Provider genau dort filtern, nennt das Dokument selbst kaum belegt.

Mit einem /22 haben Sie Spielraum: Umgeleitet wird nur das angegriffene /24, die ROA muss es abdecken (RFC 9319 zeigt das mit maxLength 24). Ist Ihr Netz genau ein /24, gibt es kein längeres Präfix mehr, das sich durchsetzt. Dann bleibt der Fall mit gleichem Präfix von oben oder eine andere Lösung des Anbieters, fragen Sie konkret nach. Mit einem /25 oder ein paar Adressen aus dem Netz Ihres Providers leiten Sie gar nichts um; da bleiben lokaler Schutz und Filterung beim Provider. Das BSI weist in Kriterium 4.1.3 darauf hin, dass je nach Größe des umzuleitenden Netzes „verschiedene Voraussetzungen und Absprachen“ mit dem Provider nötig sind.

Zwei Dinge gehören vor den Ernstfall. Erstens die ROA für das AS des Dienstleisters. Gibt es nur Ihre eigene, ist seine Ankündigung laut RFC 9319 ungültig. Weil neue RPKI-Objekte sich deutlich langsamer verbreiten als BGP-Updates, muss sie in der Regel „well in advance“ existieren. Der RFC nennt auch den Preis: Solange niemand das Präfix im Normalbetrieb ankündigt, ist es über diese ROA für einen forged-origin sub-prefix hijack angreifbar. Zweitens die Filter der anderen. Netze können Präfixfilter aus der Internet Routing Registry bauen (RFC 7454); klären Sie, welche Route-Objekte hinterlegt sein müssen.

Erkennung per NetFlow, IPFIX und sFlow

Ihre Edge-Router exportieren Flow-Daten an ein Analysesystem, das Paket- und Datenraten je Ziel gegen Schwellen prüft. NetFlow Version 9 steht in RFC 3954; laut IESG-Hinweis wurde es der IETF als Grundlage für die weitere Arbeit der IPFIX-Arbeitsgruppe vorgelegt. IPFIX (RFC 7011) ist der IETF-Standard dafür. sFlow (RFC 3176) sampelt statistisch und schickt die Stichproben sofort an den Collector.

Wie schnell Sie einen Angriff sehen, entscheidet eher die Konfiguration. Ein NetFlow-Exporter meldet einen Flow nach einem Inaktivitäts-Timeout oder, bei lang laufenden Flows, in regelmäßigen Abständen; beide Werte sind laut RFC 3954 einstellbar. Steht der zweite hoch, erfährt der Collector entsprechend spät vom Angriff. Prüfen Sie Timeouts und Schwellen zusammen, bevor Sie sich auf automatisches Umschalten verlassen.

Zwei Hebel stecken im BGP selbst. Mit Flowspec nach RFC 8955 (das RFC 5575 ablöst; IPv6 regelt RFC 8956) schicken Sie Filter- und Rate-Limit-Regeln an Router, zum Beispiel an die Ihres Providers, sofern der mitspielt. Blackholing mit der BLACKHOLE-Community nach RFC 7999 bittet Nachbarnetze, allen Verkehr zu einem Präfix zu verwerfen, typischerweise zu einem /32 oder /128. Die angegriffene Adresse ist damit offline, der Rest bleibt erreichbar. Bei bilateralem Peering muss das vorher vereinbart sein, an Route-Servern entscheidet jedes Netz nach eigener Policy.

Rückweg per GRE oder Direktverbindung

Solange umgeleitet wird, landet der Verkehr zu Ihrem Präfix beim Dienstleister, und von dort braucht er einen eigenen Weg zu Ihnen, den RFC 9319 „backhaul link“ nennt. Üblich sind ein GRE-Tunnel (RFC 2784) über das Internet oder eine direkte Verbindung im selben Rechenzentrum oder Carrier-Netz. Beim Tunnel kostet der zusätzliche Header Platz im Paket, und RFC 4459 beschreibt, was daraus folgt: Werden große Pakete fragmentiert, und funktioniert Path MTU Discovery überhaupt? MSS-Clamping hilft laut RFC 4459 bei TCP nur unter bestimmten Bedingungen und bei UDP gar nicht. Außerdem geht der RFC davon aus, dass der gesamte Verkehr durch die Tunnelendpunkte läuft, die das MSS heruntersetzen. Im /22-Beispiel trifft genau das nicht zu, denn hereinkommend läuft der Verkehr zum angegriffenen /24 durch den Tunnel, Ihre Antworten gehen aber über A und B direkt hinaus. Ein Test mit voll großen Paketen gehört deshalb in den regelmäßigen Betrieb und nicht erst in den Angriff.

Was im Angriffsfall passiert

Spielen wir das /22 hinter A und B einmal mit Flow-Erkennung und On-Demand-Umleitung durch. Die Paketrate auf eine Adresse im dritten /24 springt hoch, der Uplink zu A läuft voll, und der Collector meldet die überschrittene Schwelle, sobald die Exporter ihre Flow-Datensätze geschickt haben, also abhängig von den Timeouts oben. Je nach Vereinbarung startet die Mitigation dann automatisch, oder die Rufbereitschaft gibt sie frei; wer das darf, steht im Notfallplan. Bei Hybrid versucht es zunächst die lokale Einheit. Reicht das nicht, kündigt der Dienstleister das /24 an, für das die ROA längst angelegt ist, und sobald die Nachbarnetze die Route übernommen haben, endet der Angriff im Scrubbing-Center, während der bereinigte Rest über Tunnel oder Direktverbindung bei Ihnen ankommt. Ob das /24 erreichbar ist, prüft Ihr Monitoring von außen. Klingt der Angriff ab, zieht der Dienstleister das /24 zurück, und für alle Adressen gilt wieder das /22 über A und B. In die Auswertung gehören zwei Fragen: Haben die Schwellen gepasst, und wie lange hat jede der vier Etappen gedauert? Wie die Angriffsarten selbst funktionieren, steht unter Was ist ein DDoS-Angriff.

Network DDoS Protection von Myra

Myra ist ein vom BSI qualifizierter DDoS-Mitigation-Dienstleister und bietet alle drei Bauformen an. Network DDoS Protection (cloud) läuft on-demand oder always-on. Im Angriffsfall leitet ein automatisch ausgelöstes „more specific BGP announcement“ den Verkehr auf die Myra-Infrastruktur um. Sie hat mehr als 50 Tbps Abwehrkapazität. Umleiten lassen sich IPv4-Präfixe ab /24, also ein einzelnes /24 ebenso wie ein /23 oder /22. Der bereinigte Verkehr kommt per Direct Connect, GRE-Tunnel oder VLAN zurück, optional per IPsec. Umschalten können Sie automatisiert oder manuell, per Dashboard, API oder Terraform-Provider. Bei einem Angriff werden Sie sofort benachrichtigt, der Incident Report folgt innerhalb von 48 Stunden (werktags).

Network DDoS Protection (on-prem) sind von Myra betriebene Scrubbing-Einheiten in Ihrem Rechenzentrum. Bei Network DDoS Protection (hybrid) erfolgt die Abwehr im mittleren Lastbereich lokal, und liegt ein Angriff oberhalb der lokalen Kapazität, wird automatisch auf das Cloud Scrubbing erweitert. Erkannt wird mit Flow Monitoring, das auf einem virtuellen Server in Ihrem Netz läuft. Es liest NetFlow, sFlow, jFlow und NetStream von Ihren Edge-Routern, und überschreitet die Paket- oder Datenrate eine Schwelle, löst es optional Scrubbing oder Blackholing aus. Betreut wird das Ganze vom Myra Security Operations Center in München.

Network DDoS Protection (cloud) läuft auf BSI-C5-Typ-2-testierter Myra-Infrastruktur, mit Datenverarbeitung in der EU, auf Wunsch ausschließlich in Deutschland. Dazu kommt 24/7-Notfall-Support je nach Vertrag. Wie lange die Umschaltung bei Ihnen dauert, klären wir im Gespräch.

Häufige Fragen

Ab welcher Netzgröße funktioniert DDoS-Schutz per BGP-Umleitung?

Die Umleitung braucht ein Präfix, das andere Netze annehmen. Laut RFC 7454 (BCP 194) werden IPv4-Präfixe länger als /24 und IPv6-Präfixe länger als /48 im Internet in der Regel weder angekündigt noch angenommen; laut dem RFC von 2015 kann sich das ändern. Kleinere Netze schützen Sie lokal oder in Absprache mit dem Upstream-Provider.

Was ist der Unterschied zwischen Always-on und On-Demand beim Cloud-Scrubbing?

Bei Always-on läuft der eingehende Verkehr zu Ihren Präfixen dauerhaft über die Rechenzentren des Dienstleisters, eine Umschaltung im Angriffsfall entfällt. Bei On-Demand wird erst umgeleitet, wenn ein Angriff erkannt ist. Das BSI fragt diese Wahl in Kriterium 4.3.2 für qualifizierte DDoS-Mitigation-Dienstleister ab.

Reicht eine DDoS-Appliance im eigenen Rechenzentrum?

Höchstens bis zur Kapazität Ihrer Internetanbindung und der Appliance selbst. RFC 7999 hält fest, dass Angriffe auf eine IP-Adresse die Leitungen zu den Nachbarnetzen verstopfen können. Gegen größere Angriffe hilft nur Filterung vor der eigenen Leitung, beim Provider oder im Scrubbing-Center.

Ist Blackholing ein DDoS-Schutz?

Eher eine Notbremse. Mit der BLACKHOLE-Community nach RFC 7999 bitten Sie Nachbarnetze, allen Verkehr zum markierten Präfix zu verwerfen. Das angegriffene Ziel ist dann nicht mehr erreichbar, der Rest Ihres Netzes bleibt es. Bei bilateralem Peering muss die Nutzung vorher vereinbart sein, bei multilateralem Peering entscheidet jedes Netz nach eigener Routing-Policy.

Quellen