Am 10. Oktober 2023 offenbarten Cloudflare, Google und AWS fast gleichzeitig eine Angriffsmethode, die das Internet seit Wochen plagte: HTTP/2 Rapid Reset (CVE-2023-44487). Statt auf die „Massenstrategie" eines Botnets zu bauen, missbrauchte sie ein Designmerkmal des HTTP/2-Protokolls selbst und trieb Application-Layer-(L7-)Fluten auf einen Spitzenwert von 398 Millionen Requests pro Sekunde (RPS). Dieser Artikel zerlegt das Ereignis, das man „das L7-DDoS-Schlachtfeld veränderte" nennt, in drei Schichten: Protokoll, Daten und Verteidigung.

1. Wie man mit wenig Kraft gewinnt

Eines der Hauptfeatures von HTTP/2 ist Multiplexing: über eine einzige TCP-Verbindung lassen sich viele gleichzeitige „Streams" öffnen. Rapid Reset missbraucht den Lebenszyklus eines Streams – konkret den RST_STREAM-Frame.

Das Vorgehen der Angreifer ist brutal einfach: pro Stream wird ein Request (HEADERS-Frame) gesendet, sofort ein RST_STREAM zum Abbrechen geschickt und der nächste geöffnet. Die Schleife „Request–Abbruch–Request–Abbruch" läuft mit hoher Geschwindigkeit. Zwar wird der Request abgebrochen, doch der Server hat bereits Speicher reserviert, HPACK dekodiert, geroutet und initialisiert – Kosten, die er erst danach zurückgewinnt.

Dies ist ein Krieg der Rechenasymmetrie: der Angreifer zahlt pro Runde nur etwa 20–30 Byte (9-Byte-HEADERS + 13-Byte-RST_STREAM), während der Server pro Runde Tausende Byte CPU- und Speicherarbeit leistet. Mit minimaler Bandbreite ist zuerst die Server-CPU erschöpft.

Cloudflares Zahlen sind aufschlussreich: ein Botnetz von nur 20.000 Knoten, das pro Knoten etwa 10.000 Mal pro Sekunde loopte, erzeugte 200 Millionen RPS. Vergleichen Sie das mit traditionellen IoT-Botnetzen mit hunderttausenden oder Millionen Geräten, die oft nur wenige Millionen RPS erreichen. Rapid Reset steigerte die Angriffskraft pro Knoten um Größenordnungen.

2. Reale Dimension: die Messwerte der drei Giganten

  • Google: Spitze 398 Millionen RPS – mehr als das 7-Fache des zuvor größten Angriffs in der Internetgeschichte.
  • Cloudflare: Spitze 201 Millionen RPS – das 3-Fache des Rekords von 71 Millionen RPS aus Februar 2023.
  • AWS: über ein Dutzend Angriffe in zwei Tagen, der größte bei 155 Millionen RPS.

Entscheidend: dies nutzt einen Designfehler aus, der in nahezu jeder HTTP/2-Implementierung vorhanden ist. Nginx, Apache HTTP Server, Apache Tomcat, Microsoft IIS, HAProxy, Envoy, gRPC, Node.js, Go net/http und .NET Kestrel benötigten alle Patches. Die koordinierte Offenlegung am 10. Oktober 2023 wurde „eines der größten synchronisierten Patch-Ereignisse der Internetgeschichte" genannt, und CISA gab die Warnung AA23-283A heraus.

3. Warum herkömmliche Verteidigung hier versagt

  1. Logs sehen den Angriff nicht: RST_STREAM bricht den Request ab, bevor der Server eine Antwort erzeugt; Zugriffslogs erfassen diese „unfertigen" Requests oft nicht. Während der Server zermalmt wird, sehen die Logs sauber aus.
  2. Abschlussbasierte Rate Limits greifen nicht: klassische Limits zählen fertige Requests; Rapid-Reset-Requests werden vor dem Abschluss abgebrochen, also wird das Limit nie erreicht.
  3. Volumetrische Mitigation ist nutzlos: dies ist kein volumetrischer Angriff – der Flaschenhals ist die CPU, nicht die Bandbreite. „Mehr Leitung" bewirkt nichts.

4. Der lange Schwanz 2024: Edge gepatcht, Internes bloßgestellt

Viele nahmen an, das Patchen sei das Ende. Doch im ersten Halbjahr 2024 wurden Finanz- und Fintech-Firmen weiter ins Visier genommen; einzelne Banken und Abwickler erreichten Spitzen von 50–100 Millionen RPS mit API-Gateway-Ausfällen, Transaktions-Timeouts und Mobile-Banking-Störungen. Die Wurzel: Organisationen patchten zwar ihre Edge-Reverse-Proxys, ließen aber interne Load Balancer und Legacy-Middleware mit ungepatchten HTTP/2-Implementierungen – der „lange Schwanz" der Schwachstelle blieb monate nach der Offenlegung ausnutzbar.

5. Verteidiger-Checkliste für Ingenieure

  • Frame-Ebene-Metriken statt Request-Zählung überwachen: das Schlüsselsignal ist das Verhältnis von RST_STREAM zu abgeschlossenen Antworten. Normalerweise sollte RST_STREAM unter 1 % der Stream-Schließungen liegen; ein Anstieg ist ein starker Angriffsindikator.
  • Stream-Obergrenzen pro Verbindung und RST-Rate-Limits am Edge erzwingen.
  • Jede HTTP/2-Komponente upgraden: Nginx 1.25.3+, Apache 2.4.58+, Node.js 18.18.2+/20.8.1+, Go 1.21.3+, HAProxy 2.8.4+ usw.
  • Bei L7 schlägt Verhaltensanalyse statische Regeln: erkenne die Anomalie „hohe Abbruchrate, niedrige Abschlussrate" gegen eine Baseline, statt IPs pauschal zu blockieren.

Fazit

Rapid Reset markiert einen Paradigmenwechsel im L7-DDoS: Angreifer verlassen sich nicht mehr auf Bandbreitenüberlegenheit, sondern nutzen Protokolldesignfehler für Rechenasymmetrie – kleine Kraft, große Wirkung. Für jede Organisation, die HTTP öffentlich im Internet bereitstellt, ist dies ein Weckruf: was du für „normales Protokollverhalten" hältst, könnte die Waffe von jemand anderem sein. Die Antwort der Verteidiger ist eine Architektur, die Frame-Ebene-Identifikation und autonome Mitigation am Protokoll-Edge bietet.