Was ist ein DDoS-Angriff?
Ein Distributed-Denial-of-Service-Angriff ist genau das, was der Name sagt: eine koordinierte Aktion vieler Endpunkte, um ein einzelnes Ziel mit Datenverkehr zu überwältigen, eine Ressource zu erschöpfen (Netzwerkbandbreite, Kernel-Verbindungsstatus, Anwendungsthreads, Datenbankverbindungen) und den Dienst unverfügbar zu machen. Moderne DDoS-Angriffe fallen in drei Klassen, die sich darin unterscheiden, wie sie das Ziel ausnutzen.
Volumetrische Angriffe erschöpfen die rohe Netzwerkbandbreite. Die klassische Variante ist Reflexions-Verstärkung – der Angreifer sendet gefälschte UDP-Pakete an öffentliche Server (DNS, NTP, Memcached, CLDAP), die mit viel größeren Antworten antworten und die Bandbreite des Angreifers je nach Protokoll um das 50- bis 50.000-fache vervielfachen. Volumetrische Angriffe werden in Bits pro Sekunde gemessen, und die größten öffentlich bekannt gewordenen Ereignisse haben 3 Tbps überschritten. Die Abwehr erfolgt am Netzwerkrand, bevor der Datenverkehr Ihren Server erreicht.
Protokollangriffe erschöpfen den Verbindungsstatus auf Kernel-Ebene. SYN-Fluten (halb offene TCP-Verbindungen), ACK-Fluten und verschiedene Angriffe mit fehlerhaften Paketen fallen in diese Kategorie. Sie werden in Paketen pro Sekunde gemessen. Die Abwehr erfolgt sowohl am Rand (mit zustandslosen Filtern) als auch auf dem Server (mit Kernel-Tuning, SYN-Cookies, fail2ban-artiger automatischer Blockierung).
Angriffe auf Anwendungsebene (L7) erschöpfen Ressourcen auf Anwendungsebene. HTTP-Fluten, die teure Endpunkte angreifen, Slowloris-Angriffe, die Verbindungen offen halten, GraphQL-Abfragen, die in N+1-Muster explodieren. Gemessen in Anfragen pro Sekunde; die Abwehr erfordert Verständnis Ihrer Anwendungsoberfläche und ist selten rein am Netzwerkrand möglich – normalerweise sind Ratenbegrenzung auf Anwendungsebene, Abfragebudgets, CDN-Caching oder eine WAF erforderlich.
Jede Klasse erfordert eine andere Abwehr; moderne Schutzstapel kombinieren alle drei. Die Gbps-Zahlen im Marketing von Offshore-Hosts beziehen sich auf die volumetrische Kapazität, aber volumetrische Angriffe sind nur eine der drei Bedrohungen – die anderen beiden erfordern technische Arbeit auf Ihrer Seite.
Wie modernes DDoS-Scrubbing funktioniert
Die Infrastruktur, die volumetrische Angriffe absorbiert, wird als „Scrubbing Center“ bezeichnet, und die Architektur ist bei allen großen Anbietern (Cloudflare, Akamai, Imperva, NTT) und bei den meisten Offshore-Hosts mit eigenem Edge konsistent.
Datenverkehr, der für Ihre IP bestimmt ist, wird über Anycast von mehreren geografischen Punkten angekündigt. Anycast ermöglicht es, dieselbe IP von vielen Standorten aus zu erreichen; Routing-Protokolle liefern jedes Paket automatisch an den nächsten Edge. Wenn ein Angriff läuft, wird der Angriffsverkehr auf viele Edge-Punkte verteilt (weil die Angreifer selbst geografisch verteilt sind), und jeder Edge-Punkt sieht nur einen Bruchteil des Gesamtvolumens.
An jedem Edge-Punkt klassifizieren Scrubbing-Filter den Datenverkehr in Echtzeit. Legitimer Datenverkehr wird an Ihren Ursprung weitergeleitet; Angriffsverkehr wird am Edge verworfen. Die Klassifizierung verwendet eine Mischung aus zustandslosen Regeln (gefaälschte Quell-IPs verwerfen, ungewöhnliche Paketstrukturen verwerfen), zustandsbehafteten Heuristiken (Verbindungsstatus verfolgen und unvollständige Handshakes verwerfen) und Verhaltensanalyse (Quellen verwerfen, die bekannten Botnet-Mustern entsprechen).
Die gesamte Architektur ist präventiv – keine Reaktionszeit mit menschlichem Eingriff, kein „Aktivieren“ der Abwehr. Sobald Ihre IP auf der geschützten Anycast-Ankündigung ist, ist der Schutz immer aktiv. MurmurHost-Pläne enthalten dies standardmäßig; die DDoS-Schutz-Feature-Seite dokumentiert die Kapazität pro Stufe.
Welche Kapazität ist genug?
Diese Frage stellen die meisten Kunden, und die Antwort ist differenzierter, als das Marketing vermuten lässt.
Für die meisten persönlichen Projekte (ein Blog, ein kleines Forum, eine Hobby-Mastodon-Instanz) reichen 10 Gbps Scrubbing. Angriffe auf persönliche Projekte sind typischerweise opportunistisch – Script-Kiddie-Niveau, unter 10 Gbps, dauern Minuten bis Stunden. Unsere Einstiegspläne VPS-1 und VPS-2 enthalten 10 Gbps Scrubbing, und das hat jeden Angriff abgedeckt, den wir im letzten Jahr gegen Kunden mit persönlichen Projekten gesehen haben.
Für bescheidene kommerzielle Betriebe (einen Nischen-Onlineshop, ein kleines SaaS, ein stark besuchtes Forum) ist 50–100 Gbps die richtige Stufe. Angriffe auf dieser Ebene sind typischerweise motiviert – Konkurrenzbelästigung, Lösegeldforderungen, ideologisch motivierte Angriffe auf bestimmte Kommentare – und sie halten manchmal Stunden oder Tage an. Die mittleren Pläne VPS-4 und VPS-8 enthalten 100 Gbps Scrubbing.
Für Workloads mit hoher Bandbreite oder hohem Zielwert (Streaming, Adult, Spieleserver, VPN-Ausgangsknoten) sind 200–400 Gbps angemessen. Angriffe auf diese Workloads sind tendenziell sowohl größer (kommerzielle DDoS-Mietmärkte zielen ausdrücklich auf Streaming und Adult) als auch länger (über Tage, manchmal Wochen anhaltend). Unsere dedizierte Stufe – DS-Mid, DS-Pro – enthält 400 Gbps Scrubbing.
Für Enterprise-Workloads mit anhaltender gegnerischer Aufmerksamkeit (beobachtete Angriffe mit 1+ Tbps) ist die Standardpraxis, Cloudflare oder BunnyCDN vor den Offshore-Ursprung zu schalten und sich auf die viel größere Absorptionskapazität des CDN (multi-Tbps global) für L3/L4-Schutz zu verlassen. Cloudflares kostenlose Stufe enthält nützlichen Schutz; die kostenpflichtigen Stufen fügen WAF- und Bot-Management-Funktionen hinzu. Wir unterstützen dieses Muster ausdrücklich – siehe unsere DDoS-Schutz-Feature-Seite.
Die folgende Tabelle fasst die MurmurHost-Schutzstufen zusammen:
| Plan-Stufe | Volumetrisches Scrubbing | Anwendung |
|---|---|---|
| Shared, VPS-1, VPS-2 | 10 Gbps | Persönlich, Hobby |
| VPS-4, VPS-8, RDP-Pro | 100 Gbps | Kommerziell, mittlerer Verkehr |
| VPS-16, DS-Lite | 200 Gbps | Hoher Verkehr |
| DS-Mid, DS-Pro, DS-Beast, GPU-Pläne | 400 Gbps | Streaming, Adult, anhaltend |
| Kundenspezifisch Enterprise | 1+ Tbps | Sovereign-Level, Cross-CDN |
Edge-Taktiken – Regeln auf Anwendungsebene, Ratenbegrenzung
Die volumetrische Scrubbing-Stufe behandelt L3/L4-Angriffe. Angriffe auf Anwendungsebene erfordern technische Arbeit an Ihrem Anwendungs-Edge. Drei Muster sind am wichtigsten:
Ratenbegrenzung. Begrenzen Sie Anfragen pro IP, pro Sitzung oder pro Endpunkt. Die einfachste Implementierung erfolgt über Nginx (limit_req_zone), HAProxy oder die Middleware Ihrer Anwendung. Anspruchsvollere Ansätze – Token-Bucket pro Identität, gleitendes Fenster pro Endpunkt – erfordern mehr Einrichtung, absorbieren Burst-Angriffe aber eleganter. Das richtige Verhältnis hängt von Ihren normalen Verkehrsmustern ab: Wenn Ihr aktivster legitimer Benutzer 50 Anfragen pro Minute macht, setzen Sie das Limit auf 200/Minute, nicht auf 30.
WAF-Regeln. Eine Web Application Firewall inspiziert Anfrage-Payloads und blockiert Muster, die bekannten Angriffssignaturen entsprechen (SQL-Injection, XSS, häufige Bot-Fingerabdrücke). Cloudflares WAF, modsecurity (mit dem OWASP Core Rule Set) und BunnyCDNs WAF funktionieren alle für Offshore-Hosts. Die WAF lebt an Ihrem CDN-Edge, falls Sie einen haben, oder vor Ihrem Anwendungsserver, falls nicht.
Cloudflare oder BunnyCDN davor. Über die WAF hinaus absorbiert ein CDN den Angriff auf einer Ebene, die viel weiter skaliert als jeder einzelne Ursprung. Cloudflare insbesondere ist seit einem Jahrzehnt Standardpraxis im Offshore-Hosting – es funktioniert gut vor einem Niederlande- oder Island-Ursprung, und die kostenlose Stufe bietet allein schon sinnvollen Schutz. Wir dokumentieren die kanonische Cloudflare-plus-Offshore-Ursprung-Konfiguration auf unserer Feature-Seite.
Tarpitting und Challenge-Mechanismen
Bei anhaltenden L7-Angriffen mit geringem Volumen (raffinierte Bots, Scraper, skriptgesteuerte Account-Übernahmen) werden explizite Challenge-Mechanismen nützlich.
JS-Challenge. Cloudflares „I'm Under Attack“-Modus und ähnliche Funktionen injizieren eine kleine JavaScript-Challenge, die legitime Browser automatisch bestehen; Bots, die kein JS ausführen, werden herausgefiltert. Günstig, effektiv, für legitime Benutzer transparent.
CAPTCHA-Gates. Wenn die JS-Challenge nicht ausreicht, filtert ein echtes CAPTCHA auf den verdächtigen Endpunkten Menschen von fortgeschrittenen Bots. Die Reibungskosten sind real – die Abbruchraten steigen – also sparsam einsetzen und nur auf Endpunkten, die unter anhaltendem Angriff stehen.
Proof-of-Work-Challenges. mCaptcha, Anubis und ähnliche Tools verlangen vom Client, einen kleinen Proof-of-Work zu berechnen, bevor die Anfrage verarbeitet wird. Die wirtschaftlichen Kosten für den Angreifer skalieren linear mit der Angriffsrate; die Kosten für einen legitimen Benutzer sind unsichtbar (im schlimmsten Fall ein paar hundert Millisekunden). Dieses Muster hat 2025–2026 insbesondere gegen KI-Scraping und Credential-Stuffing-Kampagnen an Bedeutung gewonnen.
Tarpitting. Verlangsamen Sie Antworten auf verdächtigen Verkehr, ohne ihn explizit abzulehnen. Effektiv gegen einfache Bots, die Verbindungen offen halten, bis sie eine Antwort erhalten; weniger effektiv gegen moderne Angriffswerkzeuge, die ein Timeout abwarten und weitermachen.
DDoS-Ökonomie: Wer zahlt für was
Die Ökonomie des DDoS-Schutzes ist für Kunden normalerweise undurchsichtig. Ungefähr:
- Volumetrische Scrubbing-Kapazität ist die teuerste Ebene für den Host. Eine 10-Gbps-Scrubbing-Stufe kostet den Anbieter im Maßstab etwa 0,01–0,10 $ pro geschütztem GB Angriffsverkehr, was sich bei Workloads mit hohem Zielwert zu erheblichem Overhead summiert. Die meisten Anbieter enthalten eine Basisebene in der Planpreisgestaltung und verlangen für „Premium“-Kapazität darüber hinaus.
- Anycast-Peering ist mäßig teuer – Sie benötigen Standorte an mehreren Internet-Knotenpunkten. Meistens Fixkosten.
- WAF-Regeln und L7-Schutz sind im Vergleich zum Scrubbing günstig – der größte Teil der Kosten liegt in der Pflege der Regelsätze, nicht in der CPU.
MurmurHost enthält die vollständige Basisebene auf jedem Plan. Premium-Scrubbing (über der Plan-Kapazität, für anhaltende 1+ Tbps-Angriffe) ist ein Enterprise-Upgrade-Gespräch, keine Gebühr pro Angriff. Wir berechnen nicht nach Angriffsvolumen; anhaltende Angriffe über der Plankapazität lösen ein Kundengespräch über ein Upgrade der Planstufe aus, keine überraschende Rechnung.
Was Sie auf Anwendungsebene tun können
Der effektivste DDoS-Schutz ist, kein Ziel zu sein, und der zweitwirksamste ist, Ihre Anwendung kostengünstig zu bedienen. Spezifische Hebel:
Aggressiv cachen. Statische Inhalte, die von einem CDN (oder sogar von lokalem Nginx mit einer Cache-Direktive) bereitgestellt werden, kosten den Ursprung nichts. Dynamische Inhalte, die für kurze Fenster (5–60 Sekunden für die meisten Seiten) zwischengespeichert werden, absorbieren Verkehrsspitzen, ohne dass eine vollständige Ursprungsverarbeitung erforderlich ist.
Dynamische Endpunkte günstig machen. Eine Anfrage, die bei jedem Seitenaufruf die Datenbank trifft, ist viel anfälliger als eine, die Redis trifft. Verschieben Sie teure Berechnungen in Hintergrundarbeiter, geben Sie zwischengespeicherte oder letztendlich konsistente Daten auf dem Anforderungspfad zurück.
Abfragebudgets festlegen. GraphQL-APIs sind besonders anfällig für Verstärkungsangriffe – eine einzelne Angreiferanfrage kann Tausende von Datenbankabfragen auslösen. Legen Sie Abfragetiefenlimits, Abfragekomplexitätslimits und Abfragebudgets pro IP fest.
Lese- und Schreibpfade trennen. Lesestarker Verkehr sollte niemals mit schreibstarkem Verkehr um denselben Datenbankverbindungspool konkurrieren. Read Replicas behandeln Leseangriffe elegant; Schreibangriffe sind volumenmäßig kleiner und leichter zu ratenbegrenzen.
Überwachen und alarmieren. Ein 10-minütiger Angriff, den Sie nicht bemerken, ist meist kein Ereignis. Ein 10-minütiger Angriff, den Sie bemerken, gibt Ihnen Zeit, Schutzmaßnahmen zu aktivieren (Cloudflares I'm-Under-Attack-Modus umschalten, Notfall-WAF-Regeln bereitstellen, Support kontaktieren). Selbst grundlegende Überwachung (Serverlast, Anforderungsrate, 5xx-Fehlerrate) reicht für die erste Reaktion.
Pläne mit integriertem DDoS-Schutz
Ausgewählte MurmurHost-Pläne, sortiert nach typischem Anwendungsfall:
- Persönliche Projekte, Hobby: VPS-1 (8 $/Monat, 10 Gbps), Shared Pro (7,99 $/Monat, 10 Gbps).
- Kommerziell, Kleinunternehmen: VPS-2 (16 $/Monat, 10 Gbps), VPS-4 (32 $/Monat, 100 Gbps).
- Streaming, Adult, Seedboxes: VPS-8 (64 $/Monat, 100 Gbps), Stream-1 (High-Bandwidth-Stufe).
- Spieleserver: Game-M (Game-grade-UDP-Filter), Game-L.
- Anhaltend hohes Ziel, dediziert: DS-Mid (149 $/Monat, 400 Gbps), DS-Pro, DS-Beast.
- GPU-Inferenz und ML: GPU-Pro, GPU-Beast – geschützt durch 400 Gbps Scrubbing wie bei dedizierten Servern.
Das vollständige Menü finden Sie unter /pricing und die Aufschlüsselung der Funktionen unter /features/ddos-protection.
Fazit
DDoS-Schutz ist auf der volumetrischen Ebene ein gelöstes Problem – jeder glaubwürdige Offshore-Host im Jahr 2026 enthält standardmäßig erhebliche Scrubbing-Kapazität. Die verbleibende Arbeit findet auf der Anwendungsebene statt, wo günstiges Caching, Ratenbegrenzung, Abfragebudgets und grundlegende Überwachung den größten Teil der Restfläche schließen. Die richtige Planstufe wird mehr durch Ihren Anwendungsfall bestimmt als durch Angriffsgrößenprognosen: Persönliche Projekte benötigen 10 Gbps, mittlerer kommerzieller Verkehr 100 Gbps und Workloads mit hohem Zielwert 400 Gbps mit Cloudflare davor. Wählen Sie die Stufe, die zu Ihrem Workload passt, von der Preisseite, und kombinieren Sie sie mit sinnvoller technischer Arbeit auf Anwendungsebene. Für die Bedrohungsmodelle, die es rechtfertigen, deckt die DDoS-Schutz-Feature-Seite die Kapazität pro Stufe im Detail ab.