Serangan DDoS: jenis, gejala, dan mitigasi

17 Februari 2026 • 7 min read

DDoS bukan fenomena baru, tetapi kini jauh lebih mudah, murah, dan skalabel. Dulu, beberapa server yang salah konfigurasi atau botnet kecil saja sudah cukup untuk mengganggu sebuah layanan. Sekarang kita sering melihat serangan yang bisa memenuhi link dalam hitungan sepersekian detik, membebani firewall, atau melumpuhkan aplikasi dengan request yang terlihat “normal”.

Artikel ini bukan untuk menakut-nakuti. Tujuannya memberi konteks: apa itu DDoS sebenarnya, kelas serangan mana yang relevan dalam praktik, bagaimana mendeteksinya saat operasi, dan countermeasure apa yang benar-benar layak diterapkan.

Apa itu (D)DoS?

Dalam serangan Denial-of-Service (DoS), penyerang mencoba membuat layanan tidak bisa digunakan bukan dengan mencuri data, melainkan dengan membanjiri atau menghabiskan sumber dayanya. Targetnya adalah availability: website tidak bisa dibuka, API timeout, gateway VPN berhenti menerima sesi, atau resolver DNS tidak mampu mengejar.

“D” pada Distributed berarti traffic tidak berasal dari satu sumber, melainkan dari banyak sumber. Bisa berupa botnet perangkat yang terkompromi, infrastruktur yang sah (reflection/amplification), atau gabungan keduanya. Bagi operator, hasilnya sama: kamu tidak berhadapan dengan satu penyerang, tetapi banjir traffic terdistribusi.

Motivasi: kenapa serangan DDoS diluncurkan?

Motifnya sering kali membosankan, tapi efektif:

Pemerasan: “Bayar, atau kami tumbangkan lagi.”
Aktivisme/politik: visibilitas, pesan, gangguan.
Pengalihan perhatian: DDoS bisa menyita tim saat hal lain terjadi paralel.
Kompetisi/sabotase: di momen kritis (ticketing, rilis, launch), downtime singkat pun terasa.
Tekanan biaya: tidak semua serangan mengejar outage total; kadang tujuannya menaikkan biaya cloud, beban support, atau stres operasional.

Layer penting (dan kenapa ini penting)

DDoS sering dijelaskan lewat layer karena layer menentukan sinyal apa yang harus dilihat dan pertahanan apa yang mungkin dilakukan.

Layer 3 (IP): dari mana dan ke mana paket pergi.
Layer 4 (TCP/UDP): port, koneksi, handshake, state.
Layer 7 (Aplikasi): request HTTP(S), API, endpoint bisnis.
“Layer 8” (Logika bisnis): tidak resmi, tapi nyata: logika mahal di aplikasi yang bisa disalahgunakan.

Intinya: pertahanan yang kuat di Layer 3/4 tetap bisa gagal menghadapi serangan Layer 7, karena request terlihat sah dan baru menjadi mahal saat masuk ke aplikasi.

Kelas serangan 1: volume dan amplification (sering UDP)

Serangan volumetrik bertujuan menghancurkan bandwidth atau pemrosesan paket (pps). Amplifier klasik adalah reflection/amplification:

Penyerang mengirim request kecil ke server yang dapat diakses publik (misalnya open DNS resolver).
Penyerang melakukan spoofing alamat sumber dan memakai IP korban sebagai “source”.
Server tersebut mengirim respons yang jauh lebih besar ke korban.

Jika request 100 byte memicu respons 1.000 byte, kamu sudah punya faktor 10. Tergantung protokol dan payload, faktor ini bisa jauh lebih besar. Bagian menyebalkan: dari sisi korban, traffic datang dari layanan “normal” yang biasanya tidak ingin kamu blokir.

Poin penting: amplification biasanya bergantung pada source IP spoofing. Karena itu ingress filtering (BCP 38) sangat penting. Jika provider konsisten memblokir alamat sumber palsu di edge, vektor serangan ini menjadi jauh lebih sulit.

Kelas serangan 2: protocol dan state exhaustion (TCP/Layer 4)

Tidak semua DDoS soal bandwidth maksimum. Sering kali lebih efisien membuat state di target sampai tabel atau resource penuh.

Contoh klasik adalah SYN flood pada TCP:

Normalnya TCP membangun koneksi lewat three-way handshake (SYN -> SYN/ACK -> ACK).
Dalam SYN flood, penyerang mengirim SYN dalam jumlah besar, tetapi ACK terakhir tidak pernah dikirim.
Server menahan banyak koneksi setengah terbuka (state) dan melakukan retry sampai timeout.

Ini menghabiskan memori dan CPU, serta bisa berdampak pada bandwidth keluar. Dan walau bandwidth besar: ketika session tracking penuh, layanan akan “down”.

Kategori yang berdekatan adalah serangan low and slow: penyerang membuka koneksi sungguhan lalu menahannya tetap terbuka dengan traffic minimal sampai web server atau load balancer mencapai batas koneksi. Ini bisa jauh lebih tidak terlihat dibanding spike bandwidth besar.

Kelas serangan 3: Layer 7 dan “Layer 8” (HTTP, API, endpoint mahal)

Serangan Layer 7 sering paling menyebalkan karena sulit dibedakan dari traffic sah. Contohnya:

HTTP flood: request masif ke halaman dinamis, endpoint pencarian, atau alur login.
Slowloris/slow headers: koneksi dipertahankan dengan mengirim header/body sangat pelan.
Logika bisnis “mahal”: endpoint yang memicu query database, panggilan API eksternal, pembuatan PDF, kriptografi, atau bahkan workflow AI/agent.

Triknya bukan selalu “lebih banyak traffic”, tetapi lebih banyak kerja per request. Sejumlah kecil traffic yang tepat sasaran bisa lebih mahal daripada gelombang besar GET statis yang sudah tercache.

Bagaimana mendeteksi DDoS di produksi?

Kalau kamu hanya melihat CPU dan RAM, beberapa serangan akan terlihat terlambat. Dalam praktik, baseline plus beberapa metrik yang kuat sangat membantu:

Traffic: bps dan pps di edge (router, firewall, load balancer).
Metrik koneksi: koneksi baru/s, sesi terbuka, SYN backlog, TLS handshake/s.
Metrik HTTP: RPS, latensi (p95/p99), rasio 4xx/5xx, timeout.
Gejala upstream: packet loss, RTT meningkat, link jenuh, event BGP.
Sinyal dari log dan WAF: path tidak biasa, header tidak valid, banyak request yang tidak lengkap, user-agent/pola mencurigakan.

Bagian terpenting itu sederhana: kamu butuh baseline. Tanpanya, semuanya terlihat “ramai”. Dengan baseline, kamu langsung melihat deviasi besar seperti “paket kecil” atau “request tidak lengkap”.

Mitigasi: apa yang benar-benar bekerja

Ada dua pendekatan dasar: make (bangun sendiri) atau buy (pakai layanan). Bagi kebanyakan tim, “buy” lebih realistis karena mitigasi DDoS cepat menjadi masalah besar yang tidak bisa dikelola sambil lalu.

1) Taruh sesuatu di depan aplikasi: CDN/WAF/penyedia DDoS

Untuk website dan API, ini sering paling efektif:

Anycast menyebarkan traffic ke banyak lokasi.
Aturan WAF bisa memfilter pola Layer 7 yang jelas.
Bot management, rate limit, dan challenge/response menekan serangan “murah”.

Penting: tidak semua serangan adalah HTTP. Jika kamu mengekspos VPN, VoIP, game server, atau protokol lain berbasis UDP, kamu butuh lapisan perlindungan berbeda tergantung setup.

2) Atur rate limiting dan timeout dengan benar

Sederhana, tapi efektif bila diterapkan dengan benar:

ICMP/“ping”: batasi, jangan larang total (masih dibutuhkan untuk troubleshooting).
HTTP: batasi per IP/token/route, terutama endpoint mahal.
Slow request: timeout tegas untuk header/body yang tidak lengkap.

Contoh (Nginx, sangat disederhanakan) untuk limit di suatu route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Ini bukan peluru perak, tetapi mengubah ekonominya: serangan “murah” menjadi lebih sulit.

3) Arsitektur: pisahkan pekerjaan yang mahal

DDoS Layer 7 sering tidak mengenai bandwidth. Ia mengenai bagian-bagian di mana satu request sangat mahal. Dan pada setup perusahaan “normal” hal ini sering ada: login, search, export PDF, laporan, upload, query database yang kompleks, atau panggilan API eksternal.

Contoh nyata: portal pelanggan punya tombol export (“invoice sebagai PDF”, “buat report”, “download semuanya sebagai ZIP”). Dalam kondisi normal, tombol itu dipakai sesekali. Saat diserang, endpoint tersebut dipanggil ratusan atau ribuan kali per menit. Masalahnya bukan bandwidth; melainkan CPU (rendering), database (query), dan worker pool (thread/koneksi). Dari luar terlihat “situs lambat”. Dari dalam kamu melihat timeout, antrean, dan database yang tidak sanggup mengejar.

Kabar baiknya: kamu tidak harus membangun ulang semuanya. Beberapa pilihan arsitektur sering cukup untuk memisahkan bagian mahal dari request path dan menambahkan rem:

Caching (termasuk error page), TTL yang masuk akal, edge caching.
Pemrosesan asinkron (queue) untuk job mahal: alih-alih “PDF sekarang”, trigger job dan kirim nanti.
Validasi ketat dan early abort: batasi kompleksitas, limit tegas per request.
Perlindungan terpisah untuk login, search, upload, export: rate limit/timeout khusus dan bila perlu worker pool khusus.
Tombol “degraded mode” (feature flag): matikan fitur tertentu sementara tanpa stres deploy.

4) Opsi upstream: filtering, scrubbing, rencana darurat

Jika skalanya benar-benar besar, kamu harus memfilter traffic sebelum mencapai koneksimu:

Filtering di sisi provider / scrubbing center
Aturan blok sementara (misalnya: “kenapa ada UDP ke web server saya?”)
Routing darurat (misalnya: pindahkan traffic ke IP “protected”)

Ini hanya bekerja jika sudah dibahas dengan provider sebelumnya. Memulai “ad hoc” di tengah insiden itu mahal dan lambat.

Checklist pragmatis (untuk tim tanpa spesialis DDoS)

Inventaris: layanan apa yang publik? HTTP, DNS, VPN, mail, gaming, VoIP?
Single point of failure: DNS provider, reverse proxy, load balancer, hanya satu region?
Observability: bps/pps, RPS, latensi, error, jumlah koneksi, alert berbasis baseline.
Harden default: timeout, limit, ukuran header maksimum, limit koneksi, backpressure.
Rencana dengan provider: siapa yang scrubbing, siapa yang bisa filter, jalur eskalasi.
Runbook: “jika X terjadi, lakukan Y”, termasuk kontak, threshold, dan switch (feature flag).
Latihan: load test terkontrol dan drill insiden (legal dan terkoordinasi).

Terakhir: uji, tapi tetap legal dan bermanfaat

Menguji DDoS adalah topik sensitif. Apa pun yang menyentuh internet publik, sistem pihak ketiga, atau infrastruktur tanpa izin jelas adalah off limits. Yang bisa dan seharusnya kamu lakukan:

Load test di staging milikmu sendiri (misalnya untuk endpoint mahal).
Chaos test untuk dependency (cache down, DB lambat, rate limit lebih ketat).
Latih proses respons: alert, komunikasi, eskalasi provider, langkah darurat.

Sumber dan bacaan lanjutan

Sampai jumpa lagi, Joe