blueredix logo
info vuln-class-dos

Denial of Service (DoS), verständlich erklärt

Bugs und Protokoll-Schwächen, mit denen Angreifer Ihren Dienst unerreichbar machen, vom volumetrischen DDoS über einzelne Protokoll- Lücken bis zu quadratischen Regex-Fallen. Was Angreifer davon haben, Sie offline zu nehmen, und was realistisch dagegen schützt.

Worum es geht

Eine Denial-of-Service-Schwachstelle ist jeder Bug, jede Fehlkonfiguration oder jede Protokoll-Schwäche, mit der ein Angreifer Ihren Dienst für legitime Nutzer:innen unerreichbar macht. Anders als bei Datendiebstahl oder Remote Code Execution geht es nicht um Zugriff, sondern darum, Sie offline zu nehmen. Der operative Schaden reicht von wenigen Minuten beeinträchtigter Performance bis zu einem vollständigen Ausfall, der so lange anhält wie der Angriff.

DoS-Befunde fallen in vier Kategorien, die unterschiedlich aussehen, aber dieselbe Wirkung haben:

  • Volumetrischer DDoS auf Netzwerkebene. Viele Quellen fluten Ihr Netz mit Traffic, bis Bandbreite oder Paketverarbeitung überlaufen. UDP-Amplification (DNS, NTP, memcached), Reflection-Angriffe und moderne Carpet-Bombing-Botnetze gehören hierher.
  • DoS auf Protokollebene. Ein einzelner, gültig wirkender Request nutzt eine Schwäche in der Protokoll-Implementierung aus, um unverhältnismäßig viel Server-Arbeit auszulösen. HTTP/2 Rapid Reset (CVE-2023-44487) ist das aktuelle Lehrbuch-Beispiel: jeder einzelne Stream ist billig, die Rate der RST_STREAM-Abbrüche erschöpft jedoch den Worker-Pool.
  • DoS auf Anwendungsebene / algorithmischer DoS. Ein Bug im Code bewirkt, dass eine kleine Eingabe viel Server-Arbeit auslöst. Catastrophic Regex Backtracking (ReDoS), quadratische JSON-Parser, Hash-Collision-Angriffe auf Eingabe-Dictionaries, XML “Billion Laughs”-Expansion, alles dieselbe Klasse.
  • Ressourcen-Erschöpfung über legitime Funktionen. Kein Bug, sondern eine teure Funktion ohne Rate Limit: der Passwort-Reset-Endpoint, der pro Aufruf eine Mail auslöst, der “Export als PDF”-Job, der Such-Endpoint, der pro Anfrage 100 MB alloziert.

Warum Angreifer DoS fahren

Reine Verfügbarkeitsangriffe bekommen selten die Aufmerksamkeit, die ein Datenleck bekommt, sie passieren aber aus konkreten Gründen:

  • Erpressung. “Zahlen Sie diesen Bitcoin-Betrag, sonst halten wir Sie offline.” Ransom-DDoS-Kampagnen treffen Handel, Zahlungsdienstleister und Gaming, sobald das Geschäft an Erreichbarkeit hängt.
  • Sabotage durch Wettbewerber. Besonders verbreitet bei Gaming, Glücksspiel und Ticketing während traffic-starker Phasen.
  • Ablenkung. Ein lauter netzwerkseitiger Angriff bindet die On-Call-Aufmerksamkeit, während parallel ein leiserer Einbruch läuft.
  • Hacktivismus. Öffentlich exponierte Dienste von Behörden, Medien und namentlich genannten Unternehmen während politisch aufgeladener Ereignisse.
  • Versehentlich. Eine legitime Person stellt eine Anfrage, die einen quadratischen Codepfad auslöst. Derselbe Ausfall, kein böswilliger Akteur nötig.

Konkrete Beispiele, die man kennen sollte

  • HTTP/2 Rapid Reset, CVE-2023-44487. Veröffentlicht im Oktober 2023, nachdem Cloudflare, AWS und Google rekordverdächtige Angriffe abgefedert hatten. Ein Client öffnet Streams und setzt sie sofort zurück, der Server leistet Arbeit, ohne dass der Client sein Quota verbraucht. nginx, Apache, Envoy und Gos net/http haben innerhalb einer Woche gepatcht. Wer auf einer ungepatchten Version sitzt, ist weiterhin verwundbar.
  • ReDoS durch katastrophales Regex-Backtracking. Ein Regex wie ^(a+)+$ gegen die Eingabe von 30 a gefolgt von ! braucht Sekunden, um zu scheitern. Der Angreifer übergibt den String in ein Profilfeld, das durch diesen Regex validiert wird. Ein HTTP- Request bindet eine CPU. Der Cloudflare-Ausfall 2019 war genau dieses Muster, der Regex stand in einer WAF-Regel.
  • Slowloris und Verwandte. Alt, gegen Apache mit Default- Konfiguration aber weiterhin wirksam: viele TCP-Verbindungen öffnen, Request-Zeile und einen Header pro Minute schicken, nie die abschließende Leerzeile. Der Server hält jede Verbindung am Leben und wartet auf den Abschluss.
  • XML Billion Laughs / quadratische Expansion. Ein 1 KB großes XML-Dokument mit verschachtelten Entity-Verweisen wächst beim Parsen auf Gigabytes. Defaults älterer XML-Parser sind weiterhin verwundbar.
  • Hash-Collision-Angriffe. Sorgfältig gewählte JSON-Schlüssel laufen alle in denselben Hash-Bucket. Aus dem O(1)-Lookup wird O(n²). Hash-Randomisierung in modernen Sprachen mildert das ab, in Legacy-Stacks taucht es weiterhin auf.

Wie ein DDoS abläuft

Die Ökonomie bestimmt die Form des Angriffs. DoS auf Protokoll- und Anwendungsebene braucht kaum Infrastruktur: ein VPS, ein Exploit-Skript, ein verwundbares Ziel. Volumetrische Angriffe skalieren, indem Kapazität bei einem Booter- bzw. Stresser-Dienst gemietet, aus kompromittierten IoT-Geräten ein Botnetz aufgebaut oder UDP-Amplifier (offene DNS-Resolver, exponiertes memcached) missbraucht werden. Moderne Angriffe kombinieren die Schichten: eine volumetrische Welle, die Mitigation-Kapazität bindet, plus ein Anwendungsangriff gegen den Origin, sobald die Verteidigung überstreckt ist.

Die Wiederherstellung ist operative Arbeit. Während der Angriff läuft, rate-limitet das Team, blockt ASNs, skaliert die WAF und koordiniert mit dem Upstream-Provider. Die Kosten einer Stunde Ausfall (verlorene Bestellungen, SLA-Strafen, Aufkommen im Support) sind der eigentliche Schaden.

Wie das behoben wird

Verteidigung in der Tiefe, aufgebaut bevor sie gebraucht wird:

Netzwerk- und Volumenschicht:

  • Hinter einem CDN oder DDoS-Schutz-Anbieter operieren, dessen Absorptionskapazität plausible Angriffsgrößen übersteigt. Cloudflare, Fastly, AWS Shield, Bunny, Akamai. Die Ökonomie ist für KMU günstig: Bandbreite im Großen ist beim Provider billig und für einzelne Betreiber unbezahlbar.
  • Konfiguration validieren. Ein CDN, das nur die öffentliche Domain schützt, während die Origin-IP direkt erreichbar bleibt, ist keine Verteidigung. Die Origin-Firewall sollte ausschließlich Traffic aus den veröffentlichten IP-Bereichen des CDN annehmen.

Protokoll- und Anwendungsschicht:

  • CVEs für DoS auf Protokollebene zügig patchen (HTTP/2 Rapid Reset, RangeSmash, ähnliche). Diese Klasse erfordert in der Regel nur ein Server-Upgrade.
  • Vernünftige Request-Limits im Reverse Proxy setzen: Header-Größe, Body-Größe, Idle-Timeout, Request-Rate pro IP. Die Defaults von nginx, Apache, Caddy und Traefik sind ein guter Ausgangspunkt, selten aber auf die konkrete Anwendung abgestimmt.
  • Eingabe-beeinflusste Regex auf Catastrophic-Backtracking-Muster prüfen. re2 (Go), re2-wasm in Node oder Tools wie eslint-plugin-redos verwenden. Wo das Runtime es erlaubt, eine Wallclock-Obergrenze auf Regex-Auswertung setzen.
  • Timeouts auf jedem externen Aufruf. Ein hängender Downstream- Dienst darf den Worker-Pool nicht erschöpfen. Circuit Breaker (Hystrix, resilience4j, Polly) sind das passende explizite Muster.

Anwendungs-Architektur:

  • Teure Endpoints pro Identifier (Konto, IP, API-Key) rate-limiten. Token-Bucket-Implementierungen sind weit verbreitet.
  • Schwere Operationen asynchron machen. PDF-Rendering, große Exporte, Bildverarbeitung gehören in eine Queue mit begrenztem Worker-Pool, nicht in den Request-Thread.
  • Aggressiv cachen. Eine am Edge gecachte Antwort bedient Angriffsverkehr, ohne den Origin überhaupt zu erreichen.

Wie blueredix DoS-Befunde meldet

Der Scanner meldet CVEs in Drittanbieter-Software, deren Beschreibung eine Denial-of-Service-Schwachstelle nennt, sowie exponierte amplifier-anfällige Dienste (offene DNS-Resolver, memcached über UDP, NTP-monlist) auf Ihrer Netz-Oberfläche. Wir fahren keine Live-DoS-Tests gegen Ihre Dienste. Echten Traffic in der nötigen Menge zu erzeugen, wäre selbst der Angriff. Das gehört in einen vereinbarten Pentest.

Mehr dazu