HTTP/2 Rapid Reset, Teknik DDoS yang Memecahkan Rekor

HTTP/2 Rapid Reset adalah teknik serangan DDoS yang menyalahgunakan fitur pembatalan stream di protokol HTTP/2. Penyerang membuka banyak request di satu koneksi lalu langsung membatalkannya, berulang-ulang, sehingga server sibuk menyiapkan pekerjaan yang tidak pernah selesai. Celahnya tercatat sebagai CVE-2023-44487 dengan skor CVSS 7.5, dan diumumkan bersama oleh Google, Cloudflare, dan AWS pada 10 Oktober 2023.

Taruhannya besar karena ini bukan bug satu merek. Kelemahannya ada di cara protokol HTTP/2 dirancang, sehingga hampir semua web server, proxy, load balancer, dan library yang mendukung HTTP/2 perlu diperiksa. Salah menilai risikonya bisa berarti website tumbang padahal server terlihat sehat.

Seberapa besar serangan yang tercatat?

Gelombang serangan dimulai akhir Agustus 2023 dan terus berlanjut sampai September. Tiga penyedia besar melaporkan angka puncak yang berbeda dari jaringan masing-masing.

Google menggambarkan skalanya dengan perbandingan yang mudah dibayangkan: serangan selama dua menit menghasilkan lebih banyak request daripada seluruh tayangan artikel Wikipedia sepanjang September 2023. Yang lebih mengejutkan, Cloudflare menyebut serangan rekornya hanya memakai botnet sekitar 20.000 mesin. Itu tergolong kecil untuk serangan sebesar itu.

Bagaimana Rapid Reset bekerja?

Multiplexing, fitur yang jadi senjata

Di HTTP/1.1, satu koneksi menangani satu request dalam satu waktu. HTTP/2 memperkenalkan multiplexing: satu koneksi TCP bisa membawa banyak "stream" sekaligus, masing-masing satu request. Server biasanya membatasi jumlah stream yang aktif bersamaan, misalnya 100 atau 128 per koneksi.

Protokol juga mengizinkan klien membatalkan stream kapan saja dengan frame RST_STREAM. Fitur ini wajar, misalnya saat pengguna menutup tab sebelum halaman selesai dimuat.

Membatalkan lebih cepat dari batasnya

Celahnya ada di sini. Begitu stream dibatalkan, ia tidak lagi dihitung sebagai stream aktif, sehingga klien boleh langsung membuka stream baru. Penyerang mengirim header request, langsung mengirim RST_STREAM, lalu mengulanginya ribuan kali tanpa menunggu jawaban.

Dari sisi klien, pekerjaannya sangat ringan. Dari sisi server, setiap request baru tetap memicu kerja: mengurai header, mengalokasikan memori, kadang meneruskan request ke aplikasi di belakangnya. Batas stream bersamaan tidak pernah tersentuh, tapi jumlah request per detik meledak. Itulah sebabnya botnet kecil bisa menghasilkan angka rekor.

Apakah server kamu terdampak?

Jawabannya tergantung perangkat lunak dan konfigurasinya. Beberapa contoh dari pengumuman resmi vendor:

• Nginx. Menurut F5, nginx dengan pengaturan bawaan sudah cukup tahan karena batas keepalive_requests (bawaan 1000) menutup koneksi yang mengirim terlalu banyak request. Risiko naik bila nilai itu dinaikkan jauh di atas bawaan. Patch nginx membatasi stream baru per putaran event menjadi dua kali http2_max_concurrent_streams.
• Load balancer dan CDN. Penyedia besar sudah menambal di sisi mereka sejak 2023. Kalau websitemu berada di balik layanan seperti ini, lapisan depan biasanya sudah terlindungi, tapi server asal tetap perlu ditambal.
• Aplikasi dengan server HTTP/2 bawaan. Aplikasi Go, Java, Node.js, atau .NET yang langsung melayani HTTP/2 bergantung pada library-nya. Pastikan runtime dan library sudah versi yang memuat perbaikan CVE-2023-44487.

Mitigasi di server sendiri

Untuk VPS atau server yang menjalankan nginx sendiri, langkah yang masuk akal:

http {
    keepalive_requests 1000;            # biarkan di nilai bawaan
    http2_max_concurrent_streams 128;   # biarkan di nilai bawaan

    limit_conn_zone $binary_remote_addr zone=peraddr:10m;
    limit_req_zone  $binary_remote_addr zone=reqaddr:10m rate=20r/s;

    server {
        limit_conn peraddr 20;
        limit_req  zone=reqaddr burst=40 nodelay;
    }
}

Angka limit_conn dan limit_req di atas hanya contoh. Sesuaikan dengan pola trafik websitemu, karena halaman dengan banyak gambar atau aplikasi berbasis API bisa wajar mengirim puluhan request sekaligus. Setelah mengubah konfigurasi, uji dengan sudo nginx -t lalu muat ulang.

Selain itu, perbarui nginx atau web server lain ke rilis terbaru dari repositori resmi. Panduan pengerasan lain ada di hardening Nginx untuk server produksi.

Kapan cukup patch, kapan butuh perlindungan di depan?

Patch dan pembatasan request cukup untuk website kecil yang jarang menjadi sasaran. Server tidak lagi mudah dihabiskan sumber dayanya oleh satu klien nakal, dan serangan kecil akan terpotong oleh batas koneksi.

Namun patch tidak menghentikan banjir trafik. Ratusan juta request per detik akan memenuhi bandwidth dan CPU server mana pun sebelum aturan nginx sempat bekerja. Untuk toko online, layanan publik, atau website yang pernah diserang, perlindungan DDoS di depan server (CDN, WAF, atau proxy anti-DDoS) jauh lebih efektif. Cloudflare sendiri menyarankan perlindungan DDoS ditempatkan di luar data center, karena trafik yang sudah sampai ke server sulit disaring. Gambaran lengkap jenis serangan dan cara menangkalnya ada di anti-DDoS VPS, dan pilihan WAF dibahas di apa itu WAF.