HTTP/2 Rapid Reset: jak jeden frame wywołał rekordowy atak DDoS

Ataki DDoS na warstwę aplikacji (L7) rzadko biją rekordy — zwykle to wolumetryczne zalewy z warstwy sieciowej robią nagłówki. HTTP/2 Rapid Reset (CVE-2023-44487) był wyjątkiem: pozwolił osiągnąć rekordowe wartości rzędu setek milionów żądań na sekundę, wykorzystując nie lukę w kodzie, lecz cechę projektową protokołu HTTP/2. To świetny przykład, jak feature staje się bronią. Rozłóżmy go na części.

Krótkie przypomnienie: strumienie w HTTP/2

W HTTP/1.1 jedno połączenie TCP obsługiwało jedno żądanie naraz (albo pipelining, który w praktyce nie zadziałał). HTTP/2 wprowadził multipleksowanie: w obrębie jednego połączenia TCP działa wiele niezależnych strumieni (streams), a dane wędrują w ramkach (frames) — HEADERS, DATA, RST_STREAM i inne. Dzięki temu przeglądarka pobiera dziesiątki zasobów równolegle bez otwierania dziesiątek połączeń.

Serwer chroni się przed nadużyciem parametrem SETTINGS_MAX_CONCURRENT_STREAMS — maksymalną liczbą jednocześnie aktywnych strumieni na połączenie (typowo 100–128). Wygląda to jak wystarczające zabezpieczenie. I tu jest haczyk.

Mechanizm ataku: otwórz i natychmiast anuluj

Klient może w każdej chwili anulować strumień, wysyłając ramkę RST_STREAM. To normalne — przeglądarka robi tak, gdy np. użytkownik przerywa ładowanie. Rapid Reset nadużywa właśnie tego:

1. Atakujący otwiera strumień ramką HEADERS (pełne żądanie: metoda, ścieżka, nagłówki).
2. Natychmiast wysyła RST_STREAM, anulując ten strumień.
3. Ponieważ strumień jest już anulowany, nie liczy się do limitu MAX_CONCURRENT_STREAMS.
4. Atakujący może więc powtarzać krok 1–2 w pętli, tysiące razy na jednym połączeniu, bez ograniczenia limitem współbieżności.

Sedno problemu: serwer wykonuje pracę mimo anulowania. Zanim dotrze RST_STREAM, żądanie zostało już przyjęte, zparsowane, często przekazane do backendu lub aplikacji (praca po stronie proxy i origin). Atakujący płaci grosze (wysłanie dwóch małych ramek), a serwer płaci pełnym kosztem obsługi żądania — i tak miliony razy. Kilkaset połączeń wystarcza, by wygenerować wolumen, który wcześniej wymagałby ogromnego botnetu.

klient → serwer:  HEADERS (stream 1)   # żądanie
klient → serwer:  RST_STREAM (stream 1) # natychmiastowe anulowanie
klient → serwer:  HEADERS (stream 3)
klient → serwer:  RST_STREAM (stream 3)
...  (tysiące razy na jednym połączeniu)

Dlaczego to było tak groźne

Trzy czynniki złożyły się na rekord:

• Asymetria kosztów. Wysłanie żądania jest tanie, obsługa — droga. Rapid Reset maksymalizuje tę asymetrię.
• Ominięcie klasycznych limitów. Ograniczenia oparte na liczbie aktywnych strumieni albo połączeń nie łapią ataku, bo strumienie znikają natychmiast, a połączeń jest niewiele.
• Powszechność. Podatna była sama implementacja obsługi HTTP/2 w większości serwerów i proxy (nginx, Apache, serwery oparte na Go, Node, warstwy CDN), więc atak działał niemal wszędzie.

Warto podkreślić: to atak L7, uderzający w zasoby aplikacji (CPU, wątki, połączenia do backendu), a nie tylko w pasmo. Dlatego zwykłe „przepuszczanie ruchu” nie pomaga — trzeba odróżnić nadużycie od legalnego ruchu. Podobną logikę „mały wysiłek atakującego, duży koszt ofiary” widać w atakach na infrastrukturę krytyczną.

Obrona: co faktycznie działa

1. Aktualizacja oprogramowania. Dostawcy serwerów i proxy wydali poprawki, które zmieniają księgowanie strumieni i wykrywają nadużycie. To pierwszy, obowiązkowy krok — sprawdź, czy Twój serwer HTTP/2, reverse proxy i biblioteki są w wersji z łatką na CVE-2023-44487.

2. Limit resetów na połączenie. Kluczowa zmiana obronna: liczyć wskaźnik anulowanych strumieni. Jeśli na jednym połączeniu liczba RST_STREAM (zwłaszcza tuż po HEADERS) przekracza próg, połączenie należy zamknąć (GOAWAY). To odbiera atakowi jego dźwignię.

3. Limit łącznej liczby strumieni na połączenie. Nie tylko jednoczesnych, ale wszystkich w cyklu życia połączenia — po przekroczeniu zamykamy połączenie.

4. Warstwa CDN/WAF z ochroną HTTP/2 flood. Duzi dostawcy (Cloudflare, itp.) wdrożyli dedykowaną detekcję Rapid Reset. Jeśli korzystasz z CDN, upewnij się, że ta ochrona jest włączona — nasz skaner pokazuje m.in. obecność warstwy CDN/WAF przed Twoją domeną.

5. Rate limiting po stronie aplikacji. Ograniczenia per-IP i per-połączenie, choć niewystarczające same w sobie, podnoszą koszt ataku.

Kontynuacja historii: CONTINUATION flood

Warto znać następcę. W 2024 roku ujawniono rodzinę podatności HTTP/2 CONTINUATION flood: atakujący wysyła strumień ramek CONTINUATION (kontynuacja nagłówków) bez flagi END_HEADERS, zmuszając serwer do buforowania rosnącego zestawu nagłówków — co prowadzi do wyczerpania pamięci lub CPU. Mechanika inna, morał ten sam: stanowe protokoły multipleksujące mają nieoczywiste ścieżki nadużycia, a obrona wymaga twardych limitów na każdym etapie parsowania.

Wnioski dla zespołu

Rapid Reset pokazał, że bezpieczeństwo protokołu to nie tylko „czy jest luka w kodzie”, ale „jak feature zachowuje się pod złośliwym obciążeniem”. Praktyczne minimum:

• Utrzymuj serwery, proxy i biblioteki HTTP/2 w aktualnych wersjach — to część procesu zarządzania podatnościami.
• Wdroż limity resetów i łącznej liczby strumieni na połączenie.
• Postaw przed aplikacją warstwę z detekcją floodów L7.
• Testuj odporność aplikacji na nadużycia protokołu, nie tylko na klasyczne podatności — to element testu penetracyjnego infrastruktury.

Nagłówki bezpieczeństwa nie obronią przed DDoS, ale ich poprawna konfiguracja to fundament higieny warstwy web — więcej w przewodniku po nagłówkach HTTP. Jeśli chcesz sprawdzić odporność swojej infrastruktury na ataki L7, porozmawiajmy.

Najczęstsze pytania (FAQ)

Czy powinniśmy wyłączyć HTTP/2, żeby się zabezpieczyć? Nie. HTTP/2 (i HTTP/3) daje realne korzyści wydajnościowe, a wyłączanie go to cofanie się zamiast naprawy. Właściwą odpowiedzią jest aktualizacja oprogramowania i wdrożenie limitów resetów oraz strumieni — wszystkie liczące się implementacje mają już stosowne mechanizmy.

Czy zwykły firewall zatrzyma Rapid Reset? Klasyczny firewall sieciowy (L3/L4) nie — atak wygląda jak legalny, zaszyfrowany ruch HTTP/2 na porcie 443. Potrzebna jest ochrona rozumiejąca protokół warstwy aplikacji: zaktualizowany serwer, WAF lub CDN z detekcją floodów HTTP/2.

Jak sprawdzić, czy jesteśmy podatni? Zacznij od wersji: czy serwer, reverse proxy i biblioteki HTTP/2 mają łatkę na CVE-2023-44487. Następnie zweryfikuj konfigurację limitów strumieni i resetów oraz to, czy przed aplikacją stoi warstwa z ochroną L7. Test obciążeniowy symulujący wzorzec „open/reset” pokaże realną odporność.

Czy HTTP/3 rozwiązuje ten problem? HTTP/3 (nad QUIC) też multipleksuje strumienie i również wymaga poprawnego limitowania anulowań — nie jest z zasady odporny na tę klasę nadużyć. Bezpieczeństwo zależy od implementacji i konfiguracji, nie od numeru wersji protokołu.