Jurnal Keamanan Siber: Analisis DoS dan DDoS (Efek Kaca Bening)
Analisis Kerentanan Asimetris pada Protokol Aplikasi: Studi Kasus Serangan DoS dan DDoS melalui Manipulasi Open and Close Stream Berkelanjutan
Disusun untuk Keperluan Tinjauan Akademik dan Rekayasa Keamanan Siber
Departemen Penelitian Infrastruktur Jaringan & Keamanan Aplikasi Layer 7
Abstrak
Evolusi protokol web dari HTTP/1.1 menuju HTTP/2 dirancang untuk memecahkan masalah latensi dan efisiensi melalui fitur multiplexing, di mana banyak permintaan dapat dikirim melalui satu koneksi TCP tunggal (stream). Namun, transisi arsitektural ini memperkenalkan kerentanan state-management (manajemen status) baru. Makalah ini menganalisis kelas serangan Denial of Service (DoS) dan Distributed Denial of Service (DDoS) yang mengeksploitasi mekanisme pembuatan (open) dan penutupan (close) stream secara cepat dan terus-menerus, yang paling mematikan direpresentasikan oleh kerentanan HTTP/2 Rapid Reset (CVE-2023-44487). Kami membedah secara teoritis bagaimana asimetri konsumsi sumber daya antara penyerang (klien) dan korban (server) memungkinkan serangan bervolume rendah untuk melumpuhkan infrastruktur high-availability. Selanjutnya, makalah ini juga mengkaji kelelahan status di lapisan transport (TCP rapid connect-disconnect) dan memberikan rekomendasi strategis untuk mitigasi pada lapisan sistem operasi, web server, dan Web Application Firewall (WAF).
Kata Kunci: DDoS, DoS, HTTP/2 Rapid Reset, Multiplexing, RST_STREAM, Asymmetric Resource Exhaustion, CVE-2023-44487.
1. Pendahuluan
Ancaman Distributed Denial of Service (DDoS) telah mengalami pergeseran paradigma yang signifikan selama dekade terakhir. Secara historis, serangan DDoS didominasi oleh serangan volumetrik pada Lapisan 3 (Network Layer) dan Lapisan 4 (Transport Layer) dari model OSI. Vektor serangan seperti UDP Amplification (DNS, NTP, Memcached) bergantung pada penyediaan bandwidth yang masif untuk menyumbat pipa jaringan korban [1]. Namun, seiring dengan adopsi luas layanan perlindungan DDoS berbasis cloud (seperti Cloudflare, AWS Shield, dan Akamai) yang mampu menyerap serangan terabit-per-detik (Tbps), para penyerang mulai memfokuskan usaha mereka pada Lapisan 7 (Application Layer).
Serangan pada Lapisan 7 jauh lebih berbahaya dan efisien karena mereka membutuhkan bandwidth yang sangat kecil (seringkali kurang dari 100 Mbps) tetapi menargetkan sumber daya komputasi spesifik pada server: memori (RAM), siklus CPU, I/O disk, dan tabel status koneksi (connection state tables). Kemunculan standar HTTP/2 (RFC 7540) pada tahun 2015 memperkenalkan konsep multiplexed streams di atas satu koneksi TCP. Meskipun ini meningkatkan performa pemuatan halaman web secara drastis, kompleksitas mesin status (state machine) yang ditambahkan ke web server membuka celah bagi serangan logika, khususnya eksploitasi siklus hidup stream [2].
Fokus dari makalah ini adalah untuk melakukan analisis forensik dan rekayasa terhadap mekanisme serangan di mana klien nakal membuka (open) dan segera menutup (close) stream jaringan secara berulang tanpa henti. Fenomena ini mencapai puncaknya pada pertengahan tahun 2023 dengan ditemukannya teknik serangan HTTP/2 Rapid Reset yang menumbangkan rekor DDoS dalam sejarah internet, melampaui 398 juta requests per second (RPS) [3].
2. Kerangka Teoritis: Arsitektur TCP dan HTTP/2
2.1. Koneksi TCP dan Biaya Establishment
Sebelum membahas HTTP/2, penting untuk memahami batasan Transport Control Protocol (TCP). TCP beroperasi dengan jaminan pengiriman (stateful reliability). Untuk membuka koneksi, dilakukan Three-Way Handshake (SYN, SYN-ACK, ACK). Untuk menutup koneksi, dilakukan pertukaran paket FIN/ACK atau RST (Reset). Pada serangan TCP Connection Exhaustion (seperti SYN Flood atau Rapid Connect/Disconnect), penyerang mengirim paket SYN untuk membuka sesi, lalu segera mengirim RST. Server yang harus memelihara struktur data soket (biasanya Transmission Control Block / TCB di kernel Linux) membuang-buang memori dan interupsi CPU hanya untuk menangani koneksi yang tidak pernah menghasilkan data berguna [4].
2.2. Paradigma Baru HTTP/2: Streams, Messages, dan Frames
HTTP/2 mengubah data dari format teks biasa (seperti HTTP/1.1) menjadi bingkai-bingkai biner (binary frames). Untuk memahami kerentanan open and close stream, kita harus mendefinisikan tiga komponen utama arsitektur HTTP/2 [2]:
- Stream: Saluran aliran dua arah yang independen di dalam satu koneksi TCP. Setiap stream memiliki pengenal unik berupa integer (Stream ID).
- Message: Urutan lengkap dari frames yang memetakan ke sebuah pesan HTTP logis (seperti Request atau Response).
- Frame: Unit komunikasi terkecil dalam HTTP/2. Ada banyak tipe frame, tetapi yang paling krusial dalam konteks DoS ini adalah
HEADERS, DATA, SETTINGS, dan RST_STREAM.
2.3. Mekanisme Kontrol Konkurensi
Karena banyak stream berjalan di atas satu koneksi TCP, standar memandatkan adanya batas maksimum aliran yang boleh aktif secara bersamaan, diatur melalui frame SETTINGS dengan parameter SETTINGS_MAX_CONCURRENT_STREAMS. Praktik industri (seperti yang diimplementasikan pada Nginx, Apache, atau HAProxy) biasanya membatasi nilai ini menjadi 100 atau 128 aliran bersamaan untuk mencegah satu klien memonopoli server.
3. Analisis Mekanisme Serangan "Open and Close Stream" Berkelanjutan
Dalam teori keamanan sistem, serangan "Open and Close Stream" mengeksploitasi cacat logika pada bagaimana server membebaskan sumber daya setelah mencapai batas kontrol konkurensi. Vektor serangan ini diwujudkan dalam bentuk teknik HTTP/2 Rapid Reset.
3.1. Siklus Hidup Permintaan Normal vs Serangan
Dalam kondisi normal, peramban web (klien) meminta gambar dari server:
- Klien mengirim frame
HEADERS (Membuka stream, misal Stream ID = 1).
- Server menerima
HEADERS, menguraikan header, memanggil backend worker (misal PHP-FPM atau Node.js) atau membaca disk.
- Server membalas dengan frame
HEADERS dan DATA.
- Stream ID 1 selesai (Tertutup / Closed state).
Pada serangan Rapid Reset, penyerang menghilangkan langkah 3 dan 4 dari perspektif klien [5]. Alurnya menjadi:
- Penyerang (Botnet) menggunakan alat khusus (seperti varian h2load yang dimodifikasi atau klien berbasis Go) yang dapat memintas struktur pembatas klien.
- Penyerang mengirim frame
HEADERS untuk Stream ID = 1. (Open)
- Tanpa menunggu balasan apa pun, dalam hitungan mikrodetik (seringkali dikemas (pipelined) di dalam paket TCP jaringan yang sama), penyerang mengirim frame
RST_STREAM untuk Stream ID = 1 dengan kode kesalahan CANCEL. (Close)
- Penyerang segera mengulang langkah 2 dan 3 untuk Stream ID 3, 5, 7, hingga jutaan kali dalam detik yang sama pada koneksi TCP tunggal.
[Paket TCP Tunggal dari Penyerang (Client)]
+-------------------------------------------------+
| HEADERS (Stream 1) : GET / |
| RST_STREAM (Stream 1): CANCEL |
| HEADERS (Stream 3) : GET / |
| RST_STREAM (Stream 3): CANCEL |
| HEADERS (Stream 5) : GET / |
| RST_STREAM (Stream 5): CANCEL |
| ... (berulang ratusan kali dalam 1 MTU) ... |
+-------------------------------------------------+
Visualisasi payload serangan: Pipelining dari pembukaan dan pembatalan stream.
3.2. Mengapa Ini Melumpuhkan Server (Bypass Batas Konkurensi)?
Keindahan sekaligus bahaya dari serangan ini adalah ia dengan cerdas membypass fitur perlindungan SETTINGS_MAX_CONCURRENT_STREAMS. Jika server membatasi 100 stream bersamaan, penyerang tidak pernah melanggar aturan tersebut.
Ketika penyerang membuka Stream 1, konkurensi menjadi 1. Saat penyerang mengirim RST_STREAM untuk Stream 1, spesifikasi HTTP/2 mengharuskan server segera mengubah status Stream 1 menjadi "closed" dan mengurangi jumlah konkurensi. Karena stream dibatalkan begitu cepat, jumlah stream aktif penyerang di mata connection manager hampir selalu berada di angka 0 atau 1. Dengan demikian, penyerang dapat mengirim puluhan ribu permintaan dalam satu TCP tanpa pernah terkena pinalti pembatasan stream.
3.3. Asimetri Pemrosesan (Biaya Komputasi)
Kerentanan mendasar (root cause vulnerability) terletak pada asimetri biaya komputasi.
- Biaya Penyerang (Sangat Rendah): Membangkitkan puluhan byte frame biner acak (
HEADERS dan RST_STREAM) pada klien hanya membutuhkan instruksi CPU dasar dan memori minimal.
- Biaya Server (Sangat Tinggi): Ketika server menerima
HEADERS, parser HTTP/2 internal bekerja. Server melakukan dekompresi HPACK (algoritma kompresi header HTTP/2). Server mengalokasikan struktur memori (request context). Server mungkin telah meneruskan tugas ini ke lapisan aplikasi (proxy pass ke backend). Ketika RST_STREAM tiba milidetik kemudian, server harus melakukan interupsi. Server harus mencari dan menghentikan proses aplikasi (context switching yang mahal), menjalankan garbage collection untuk membersihkan memori HPACK, dan mencatat (logging) error tersebut.
Ketidakseimbangan inilah yang membuat skrip kecil dari satu Virtual Private Server (VPS) mampu menyebabkan CPU Nginx atau Apache korban langsung mencapai utilisasi 100%, mengakibatkan Denial of Service penuh [6].
4. Analisis Dampak pada Lapisan Infrastruktur
Serangan buka-tutup (open and close stream) tidak hanya merusak titik akhir (endpoint) web server tunggal, tetapi menciptakan efek beruntun (cascading failure) pada berbagai lapisan infrastruktur.
4.1. Efek pada Reverse Proxies dan Load Balancers
Komponen jaringan tepi (edge) seperti Nginx, HAProxy, atau Envoy sering kali bertindak sebagai penerminasi SSL (SSL terminators). Ketika serangan Rapid Reset masuk, reverse proxy ini harus memelihara tabel state machine untuk setiap stream HTTP/2. Beban untuk membongkar dan merakit ulang (teardown) struktur data ini secara instan menyebabkan kehabisan file descriptor dan worker pool exhaustion. Klien sah yang mencoba terhubung akan mengalami 502 Bad Gateway atau 503 Service Unavailable.
4.2. Kelemahan Kompresi HPACK (CVE-2016-1132 dan Varian)
Sifat HTTP/2 yang memelihara state dari header melalui HPACK Dynamic Table membuat serangan ini lebih parah. Meskipun stream segera ditutup dengan RST_STREAM, konteks kompresi header tetap harus dipelihara pada level koneksi TCP [2]. Pembukaan dan penutupan stream dengan header palsu secara terus-menerus akan memaksa alokasi dan pembaruan struktur data HPACK, menyebabkan kelelahan memori (Memory Exhaustion / OOM - Out of Memory).
4.3. Skala Dampak: Laporan Kasus Agustus - Oktober 2023
Berdasarkan laporan keamanan bersama dari Google Cloud, Cloudflare, dan Amazon Web Services (AWS), serangan berbasis manipulasi penutupan stream HTTP/2 ini memecahkan rekor global. Google mencatat insiden serangan yang memuncak pada 398.000.000 RPS (Requests Per Second). Ini secara signifikan melampaui rekor serangan botnet Meris sebelumnya (sekitar 46 juta RPS). Kecepatan penghasilan permintaan ini semata-mata diakibatkan oleh kemampuan melakukan pipeline pembukaan dan penutupan tanpa perlu menunggu waktu putaran jaringan (Round Trip Time / RTT) [3][5].
5. Strategi Mitigasi dan Arsitektur Pertahanan
Mencegah serangan DoS yang berbasis "open and close stream" sangat menantang karena frame RST_STREAM pada dasarnya adalah fungsi sah dan penting dari protokol HTTP/2. Klien harus diizinkan untuk membatalkan permintaan yang tidak lagi mereka butuhkan (misalnya pengguna menutup tab browser sebelum gambar termuat penuh). Pemblokiran total tidak dimungkinkan. Mitigasi harus berpusat pada penetapan ambang batas perilaku (behavioral rate limiting) dan pembaruan tingkat kernel/sistem.
5.1. Patching dan Pembaruan Web Server (Immediate Action)
Begitu CVE-2023-44487 dirilis secara luas, seluruh vendor web server dan proxy segera merilis perbaikan (patches). Cara kerja perbaikan ini adalah dengan melacak rasio atau frekuensi kemunculan RST_STREAM yang tidak wajar.
- Nginx: Memperkenalkan fitur limitasi
keepalive_requests pada HTTP/2. Nginx sekarang membatasi jumlah total request (baik yang selesai maupun yang dibatalkan oleh RST_STREAM) yang diizinkan dalam satu siklus koneksi TCP (default: 1000). Jika batas tercapai, Nginx akan secara paksa memutuskan koneksi TCP (mengirim TCP FIN/RST) ke klien [7].
- HAProxy: Mengurangi timeout dan melacak laju kesalahan pembatalan di sisi koneksi, membatasi pembukaan stream secara drastis jika klien menunjukkan perilaku pembatalan berulang yang aneh.
5.2. Konfigurasi Pertahanan pada Nginx (Contoh Implementasi)
Dalam merancang konfigurasi Nginx modern pasca-serangan Rapid Reset, administrator sistem harus memperketat parameter direktif HTTP/2.
# Konfigurasi Pertahanan Nginx terhadap DoS Open/Close Stream
http {
# Batasi jumlah aliran konkurensi (Default 128)
http2_max_concurrent_streams 128; # BATASAN KRITIS: Batasi total request per koneksi
# (Mencegah pipeline serangan tanpa henti)
keepalive_requests 1000;
# Kurangi waktu tunggu untuk klien yang lambat
# (Mencegah varian Slowloris HTTP/2)
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
# Rate Limiting berbasis IP
# (Mengurangi dampak jika penyerang dari sumber IP terbatas)
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=50r/s;
server {
listen 443 ssl http2;
server_name api.sistem-aman.com;
location / {
limit_req zone=api_limit burst=100 nodelay;
proxy_pass http://backend_pool;
}
}
}
Catatan Rekayasa: Meskipun
limit_req (Rate Limiting) standar Nginx berguna, pada kasus
Rapid Reset yang menargetkan parser HTTP/2 sebelum
request mencapai logika lokasi aplikasi, pembatasan
keepalive_requests di blok
http adalah satu-satunya mekanisme pemutusan (
kill-switch) yang menyelamatkan siklus CPU Nginx sebelum
rate limiter sempat bekerja [7].
5.3. Pemantauan Koneksi TCP (Transport Layer Defense)
Karena serangan sering kali memaksa proxy/server untuk menutup dan membuka koneksi (akibat mitigasi lapis 7), hal ini dapat memicu serangan sekunder berupa TCP Exhaustion. Penyerang akan memaksa server menciptakan ribuan koneksi dalam status TIME_WAIT. Mitigasi di tingkat sistem operasi (Linux Kernel) harus diterapkan:
# sysctl.conf: Mengoptimalkan penanganan tabel TCP terhadap koneksi cepatAktifkan proteksi SYN Cookies
net.ipv4.tcp_syncookies = 1
Kurangi waktu recycle untuk koneksi dalam status TIME_WAIT
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
Perbesar ukuran antrian backlogs untuk menampung burst dari DDoS
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
5.4. Pemanfaatan Web Application Firewall (WAF) Tepi
Sistem inspeksi pada level edge cloud (Cloudflare, AWS Shield) melakukan analisis perilaku terhadap setiap koneksi TCP. Mereka merancang algoritma deteksi statistik: jika rasio pengiriman RST_STREAM dari suatu alamat IP melampaui persentase tertentu (misalnya, lebih dari 30% dari total HEADERS yang dikirim), node WAF tepi akan secara diam-diam memblokir (drop) koneksi TCP (Blackhole routing atau RST termination) sebelum lintas batas jaringan (traffic) menyentuh origin server korban [5].
6. Kesimpulan
Serangan DoS dan DDoS melalui teknik pembukaan dan penutupan stream (Open and Close Stream) berkelanjutan mewakili evolusi canggih dalam eksploitasi protokol aplikasi lapisan ke-7. Dengan mengeksploitasi arsitektur multiplexing dari HTTP/2 dan memanipulasi frame RST_STREAM, penyerang dapat menghindari batasan konkurensi (max concurrent streams) dan menimbulkan asimetri biaya pemrosesan yang fatal bagi server target.
Studi analitik terhadap kerentanan CVE-2023-44487 (HTTP/2 Rapid Reset) membuktikan bahwa mekanisme perlindungan usang yang didasarkan murni pada analisis volumetrik (bandwidth) tidak lagi memadai. Keamanan infrastruktur web masa depan harus mengadopsi kontrol sesi koneksi holistik—membatasi jumlah permintaan per koneksi TCP (seperti parameter keepalive_requests), memonitor telemetri rasio pembatalan permintaan stream, serta penyesuaian penyetelan (tuning) kernel Linux secara masif untuk mempercepat pembersihan status memori (garbage collection). Kolaborasi pengungkapan kerentanan antara raksasa penyedia cloud juga menyoroti pentingnya desain protokol yang tidak hanya memprioritaskan performa throughput, tetapi juga ketahanan terhadap vektor serangan penipisan status (state exhaustion attacks).
7. Daftar Pustaka / Referensi
- Mirkovic, J., & Reiher, P. (2004). "A taxonomy of DDoS attack and DDoS defense mechanisms." ACM SIGCOMM Computer Communication Review, 34(2), 39-53.
- Belshe, M., Peon, R., & Thomson, M. (2015). "Hypertext Transfer Protocol Version 2 (HTTP/2)." RFC 7540, Internet Engineering Task Force (IETF). [Online]. Tersedia: https://datatracker.ietf.org/doc/html/rfc7540
- Google Cloud Security Team. (Oktober 2023). "How it works: The novel HTTP/2 'Rapid Reset' DDoS attack." Google Cloud Blog. [Online]. Tersedia: https://cloud.google.com/blog/products/identity-security/how-…
- Schuba, C. L., Krsul, I. V., Kuhn, M. G., Spafford, E. H., Sundaram, A., & Zamboni, D. (1997). "Analysis of a denial of service attack on TCP." Dalam Proceedings 1997 IEEE Symposium on Security and Privacy (hal. 208-223). IEEE.
- Cloudflare Threat Intel. (Oktober 2023). "HTTP/2 Rapid Reset: deconstructing the record-breaking attack." The Cloudflare Blog. [Online]. Tersedia: https://blog.cloudflare.com/technical-breakdown-http2-rapid-r…
- National Vulnerability Database (NVD). (2023). "CVE-2023-44487 Detail - HTTP/2 Rapid Reset Vulnerability." NIST. [Online]. Tersedia: https://nvd.nist.gov/vuln/detail/CVE-2023-44487
- Nginx Security Advisory. (Oktober 2023). "HTTP/2 Rapid Reset vulnerability (CVE-2023-44487)." NGINX / F5 Networks. [Online]. Tersedia: https://www.nginx.com/blog/http-2-rapid-reset-attack-impactin…
Dyskusja (0)