Kompania Google regjistroi sulmin më të madh DDoS ndaj infrastrukturës së saj, me intensitet prej 398 milion kërkesash në sekondë. Sulmi i ri është 7 herë më intensiv se sulmi rekord të kaluar, në të cilin sulmuesit arritën të formonin një fluks prej 47 milion kërkesash në sekondë. Për krahasim, tërë trafiku në Web këndvizohet në një nivel prej 1-3 miliard kërkesash në sekondë. Përveç Google, sulmi e përballuan gjithashtu kompanitë Amazon dhe Cloudflare. Mundësia e realizimit të një sulmi të ri lidhet me identifikimin e një ndjeshmërie në protokollin HTTP/2 (CVE-2023-44487), e cila lejon dërgimin e një fluksi të madh kërkesash në server me një ngarkesë minimale në klient.
Teknika e re e sulmit, e quajtur «Rapid Reset», përfshin përdorimin e mjeteve të ofruara në HTTP/2 për shumëkthimin e kanaleve të komunikimit, që lejon krijimin e një fluksi kërkesash në kuadër të një lidhjeje tashmë të vendosur, pa hapur lidhje të reja rrjetësh dhe pa pritur konfirmimin e marrjes së paketave. Ndjeshmëria konsiderohet si pasojë e një mangësie në protokollin HTTP/2, sipas specifikimeve të të cilit, kur përpiqet të hapë numra shumë të mëdha rrjedhash, duhet të anullohen vetëm rrjedhat që tejkalojnë limitin, por jo të mbyllet e gjithë lidhja e rrjetit.
Në përputhje me metodat e mëparshme të sulmeve ndaj HTTP/2, në sulmin e ri krijohet gjithashtu një numër i madh rrjedhash brenda një lidhjeje. Dallimi kyç i sulmit të ri është se, në vend të pritjes për një përgjigje pas çdo kërkese të dërguar, dërgohet një kornizë me flamurin RST_STREAM, e cila anulon menjëherë kërkesën. Anulimi i kërkesës në një fazë të hershme lejon shmangien e trafikës për në klient dhe kalimin përmes kufizimeve të pranishme në serverët HTTP për numrin maksimal të rrjedhash të hapura në kuadër të një lidhjeje në HTTP/2. Kështu, në sulmin e ri, volumi i kërkesave të dërguara në serverin HTTP nuk varet nga vonesat midis dërgimit të kërkesës dhe marrjes së përgjigjes (RTT, kohë e kthyer), por përqendrohet vetëm në kapacitetin e kanalit të komunikimit.
Duke pasur parasysh se për të realizuar sulmin nga ana e klientit mjafton të dërgohen kërkesa pa marrë përgjigje, sulmi mund të realizohet me shpenzime minimale. Për shembull, sulmi i regjistruar nga kompania Cloudflare me 201 milion kërkesa në sekondë u realizua me një botnet relativisht të vogël prej 20 mijë kompjuterësh. Në anën server shpenzimet për përpunimin e kërkesave të ardhura janë ndjeshëm më të larta, megjithëse ato anullohen, pasi duhet të kryhen operacione si alokimi i strukturave të dhënash për rrjedha të reja, analizimi i kërkesës, zhbllokimi i titullit dhe përputhja e URL-së me burimin. Në sulmin ndaj proxy-ve të prapme, sulmi mund të përhapet në backend, pasi proxy mund të arrijë të ridrejtojë kërkesën në backend para se korniza RST_STREAM të përpunojë.
Suli mund të bëhet vetëm mbi serverët e ndjeshëm që mbështesin HTTP/2 (skripti për të verifikuar manifestimin e ndjeshmërisë në servera, instrumenti për kryerjen e sulmit). Nuk janë regjistruar ende sulme mbi HTTP/3 dhe mundësitë për realizimin e tyre nuk janë analizuar plotësisht, por përfaqësuesit e Google rekomandojnë zhvilluesit servera të shtojnë në implementimet e HTTP/3 masa mbrojtëse të ngjashme me ato të realizuara për bllokimin e sulmeve ndaj HTTP/2.
Ndjeshmëria ndaj ndjeshmërisë dhe disponueshmëria e rregullimeve për serverët HTTP dhe proxy:
- nginx (njoftim, shpjegim se ndjeshmëria nuk manifeston plotësisht në nginx në konfigurimin e zakonshëm, pasi sulmi do behet në limitin e numrit të kërkesave për lidhje (p.sh. pas çdo 1000 kërkesash lidhja do të rinovohet). Rregullimi përfshin një mbrojtje shtesë për kufizimin e intensitetit të kërkesave përmes direktivës «limit_req»).
- Në HAProxy mbrojtja efektive ndaj kalimit të limitit të numrit të rrjedhash HTTP/2 u shtua që në vitin 2018 dhe funksionon që nga versioni 1.9-dev.
- Apache httpd (krijohet një ngarkesë e caktuar mbi httpd, por ajo nuk përhapet në backend dhe kufizohet me kufizimet që janë në fuqi që nga viti 2016 për lidhjet e klientëve).
- mod_h2 për Apache httpd.
- caddy
- envoy
- golang (problemi është zgjidhur në versionet Go 1.21.3 dhe 1.20.10).
- h2o (patch).
- grpc-go
- hyper (ndjeshmëria nuk manifestohet).
- jetty (e rregulluar në 12.0.2, 11.0.17, 10.0.17 dhe 9.4.53.v20231009).
- netty
- nghttp2 (e rregulluar në versionin 1.57.0).
- Facebook proxygen
- .NET dhe ASP.NET Core (ndjeshmëria i përket serverit http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (e rregulluar në versionin 1.28.0).
- Apache Tomcat (e rregulluar në versionet 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (e rregulluar në dega 9.2.x).
Burimi: opennet.ru
