Serangan DDoS: jenis, gejala dan mitigasi

17 Februari 2026 • 7 min read

DDoS bukan fenomena baharu, tetapi ia menjadi jauh lebih mudah, murah dan boleh diskalakan. Dahulu, beberapa pelayan yang tersalah konfigurasi atau botnet kecil sudah memadai untuk mengganggu sesuatu perkhidmatan. Hari ini kita sering melihat serangan yang boleh memenuhi pautan rangkaian dalam pecahan saat, membebankan firewall atau melumpuhkan aplikasi dengan permintaan yang nampak “normal”.

Artikel ini bukan untuk menakut-nakutkan. Tujuannya ialah memberi konteks: apa itu DDoS sebenarnya, kelas serangan mana yang penting dalam dunia sebenar, bagaimana mengesannya ketika operasi, dan langkah mitigasi yang benar-benar berbaloi.

Apa itu (D)DoS?

Dalam serangan Denial-of-Service (DoS), penyerang cuba menjadikan perkhidmatan tidak boleh digunakan bukan dengan mencuri data, tetapi dengan membanjiri atau menghabiskan sumbernya. Sasaran ialah ketersediaan: laman web tidak lagi memuat, API timeout, gateway VPN berhenti menerima sesi, atau resolver DNS tidak mampu mengejar.

“D” dalam Distributed bermaksud trafik tidak datang daripada satu sumber, tetapi daripada banyak sumber. Ia boleh berupa botnet peranti yang dikompromi, infrastruktur yang sah (reflection/amplification), atau gabungan keduanya. Bagi operator, hasilnya sama: bukan seorang penyerang, tetapi banjir trafik yang teragih.

Motivasi: mengapa serangan DDoS dilancarkan?

Motifnya selalunya tidak glamor, tetapi berkesan:

Pemerasan: “Bayar, atau kami tumbangkan semula.”
Aktivisme/politik: keterlihatan, mesej, gangguan.
Pengalihan perhatian: DDoS boleh menyibukkan pasukan sementara perkara lain berlaku serentak.
Persaingan/sabotaj: pada masa kritikal (ticketing, release, pelancaran), gangguan singkat pun memberi kesan.
Tekanan kos: tidak semua serangan mensasarkan outage penuh; kadangkala tujuan ialah menaikkan kos cloud, beban sokongan atau tekanan operasi.

Layer penting (dan kenapa ia penting)

DDoS sering diterangkan mengikut layer kerana layer menentukan isyarat apa yang perlu dilihat dan pertahanan apa yang mungkin dilakukan.

Layer 3 (IP): dari mana ia datang dan ke mana ia pergi.
Layer 4 (TCP/UDP): port, sambungan, handshake, state.
Layer 7 (Aplikasi): permintaan HTTP(S), API, endpoint perniagaan.
“Layer 8” (Logik perniagaan): tidak rasmi, tetapi nyata: logik mahal dalam aplikasi yang boleh dieksploitasi.

Intinya: pertahanan yang baik pada Layer 3/4 masih boleh gagal pada serangan Layer 7, kerana permintaan nampak sah dan hanya menjadi mahal apabila sampai ke aplikasi.

Kelas serangan 1: volume dan amplification (sering UDP)

Serangan volumetrik bertujuan menenggelamkan bandwidth atau pemprosesan paket (pps). Amplifier klasik ialah reflection/amplification:

Penyerang menghantar permintaan kecil kepada pelayan yang boleh dicapai secara awam (contohnya open DNS resolver).
Penyerang melakukan spoofing alamat sumber dan meletakkan IP mangsa sebagai “source”.
Pelayan tersebut menghantar respons yang jauh lebih besar kepada mangsa.

Jika permintaan 100 byte mencetuskan respons 1,000 byte, faktor 10 sudah tercapai. Bergantung pada protokol dan payload, faktor ini boleh jauh lebih tinggi. Yang menyusahkan: dari sisi mangsa, trafik datang daripada perkhidmatan “normal” yang biasanya sukar untuk disekat.

Poin penting: amplification biasanya bergantung pada spoofing IP sumber. Sebab itu ingress filtering (BCP 38) sangat penting. Jika penyedia rangkaian menyekat alamat sumber palsu di edge, vektor ini menjadi jauh lebih sukar.

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

Bukan semua DDoS tentang bandwidth maksimum. Selalunya lebih efisien untuk mencipta state pada sasaran sehingga jadual atau sumber penuh.

Contoh klasik ialah SYN flood terhadap TCP:

Biasanya TCP membina sambungan melalui three-way handshake (SYN -> SYN/ACK -> ACK).
Dalam SYN flood, penyerang menghantar SYN dalam jumlah besar tetapi ACK terakhir tidak pernah tiba.
Pelayan menyimpan banyak sambungan separuh terbuka (state) dan membuat retry sehingga timeout.

Ini menggunakan memori dan CPU serta boleh menjejaskan bandwidth keluar. Dan walaupun bandwidth besar: apabila session tracking penuh, servis akan “down”.

Kategori berkaitan ialah serangan low and slow: penyerang membuka sambungan sebenar dan mengekalkannya dengan trafik minimum sehingga web server atau load balancer mencapai had sambungan. Ini boleh jauh kurang ketara berbanding lonjakan bandwidth besar.

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

Serangan Layer 7 sering paling menjengkelkan kerana sukar dibezakan daripada trafik sah. Contoh:

HTTP flood: banyak permintaan ke halaman dinamik, endpoint carian atau aliran login.
Slowloris/slow headers: sambungan dikekalkan terbuka dengan menghantar header/body sangat perlahan.
Logik perniagaan “mahal”: endpoint yang mencetuskan query DB, panggilan API luaran, penjanaan PDF, kriptografi atau workflow AI/agent.

Triknya bukan semata-mata “lebih banyak trafik”, tetapi lebih banyak kerja per permintaan. Sedikit trafik yang tepat sasaran boleh lebih mahal daripada gelombang GET statik yang dicache.

Bagaimana mengesan DDoS di produksi?

Jika hanya melihat CPU dan RAM, sebahagian serangan akan dikesan terlalu lewat. Dalam amalan, baseline ditambah beberapa metrik yang kukuh sangat membantu:

Trafik: bps dan pps di edge (router, firewall, load balancer).
Metrik sambungan: sambungan baharu/s, sesi terbuka, SYN backlog, TLS handshake/s.
Metrik HTTP: RPS, latensi (p95/p99), nisbah 4xx/5xx, timeout.
Simptom upstream: packet loss, RTT meningkat, pautan tepu, event BGP.
Isyarat log dan WAF: path pelik, header tidak sah, banyak permintaan tidak lengkap, user-agent/pola mencurigakan.

Perkara paling penting adalah mudah: anda perlukan baseline. Tanpanya, semuanya nampak “banyak”. Dengan baseline, anda terus nampak deviasi besar seperti “paket kecil” atau “permintaan tidak lengkap”.

Mitigasi: apa yang benar-benar berkesan

Ada dua pendekatan asas: make (bina sendiri) atau buy (guna perkhidmatan). Untuk kebanyakan pasukan, “buy” lebih realistik kerana mitigasi DDoS cepat menjadi masalah besar yang sukar diurus sebagai kerja sampingan.

1) Letakkan sesuatu di hadapan aplikasi: CDN/WAF/penyedia DDoS

Untuk laman web dan API, ini sering paling berkesan:

Anycast mengagihkan trafik ke banyak lokasi.
Peraturan WAF boleh menapis pola Layer 7 yang jelas.
Bot management, rate limit dan challenge/response mengurangkan serangan “murah”.

Penting: tidak semua serangan adalah HTTP. Jika anda mengekspos VPN, VoIP, game server atau protokol lain berasaskan UDP, anda perlukan lapisan perlindungan lain mengikut setup.

2) Tetapkan rate limiting dan timeout dengan betul

Mudah, tetapi berkesan jika dibuat dengan betul:

ICMP/“ping”: hadkan, jangan larang terus (masih perlu untuk troubleshooting).
HTTP: hadkan mengikut IP/token/route, terutama endpoint mahal.
Permintaan perlahan: timeout tegas untuk header/body yang tidak lengkap.

Contoh (Nginx, sangat dipermudahkan) untuk limit pada sesuatu 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 ia mengubah ekonomi serangan: serangan “murah” menjadi lebih sukar.

3) Seni bina: asingkan kerja yang mahal

DDoS Layer 7 selalunya tidak menjejaskan bandwidth. Ia menjejaskan bahagian di mana satu permintaan sangat mahal. Dan dalam setup syarikat biasa, banyak contohnya: login, carian, eksport PDF, laporan, upload, query DB yang kompleks, atau panggilan API luaran.

Contoh lazim: portal pelanggan ada butang eksport (“invois sebagai PDF”, “jana laporan”, “muat turun semua sebagai ZIP”). Dalam operasi normal, ia digunakan sekali-sekala. Dalam serangan, endpoint itu dipanggil ratusan atau ribuan kali seminit. Masalahnya bukan bandwidth; tetapi CPU (rendering), DB (query) dan worker pool (thread/sambungan). Dari luar, nampak seperti “site perlahan”. Dari dalam, anda nampak timeout, queueing dan DB yang tidak mampu mengejar.

Berita baik: anda tidak perlu bina semula semuanya. Beberapa keputusan seni bina biasanya cukup untuk memisahkan bahagian mahal daripada request path dan menambah brek:

Caching (termasuk halaman ralat), TTL yang munasabah, edge caching.
Pemprosesan asinkron (queue) untuk job mahal: bukan “PDF sekarang”, tetapi trigger job dan hantar kemudian.
Validasi ketat dan early abort: hadkan kompleksiti dan tetapkan had per permintaan.
Perlindungan berasingan untuk login, carian, upload, eksport: rate limit/timeout khusus, dan jika perlu worker pool khusus.
Suis “degraded mode” (feature flag): matikan fungsi tertentu sementara tanpa stres deployment.

4) Pilihan upstream: filtering, scrubbing, pelan kecemasan

Jika skalanya benar-benar besar, anda perlu menapis trafik sebelum ia sampai ke sambungan anda:

Filtering di pihak penyedia / scrubbing center
Peraturan blok sementara (contoh: “kenapa UDP sampai ke web server saya?”)
Routing kecemasan (contoh: tukar ke IP “dilindungi”)

Ini hanya berkesan jika dibincangkan dengan penyedia lebih awal. Memulakan secara “ad hoc” ketika insiden sedang berlaku adalah mahal dan lambat.

Checklist pragmatik (untuk pasukan tanpa pakar DDoS)

Inventori: servis apa yang terbuka? HTTP, DNS, VPN, mail, gaming, VoIP?
Single point of failure: penyedia DNS, reverse proxy, load balancer, satu region sahaja?
Observability: bps/pps, RPS, latensi, ralat, kiraan sambungan, alert berasaskan baseline.
Harden default: timeout, limit, saiz maksimum header, limit sambungan, backpressure.
Pelan dengan penyedia: siapa scrubbing, siapa boleh filter, laluan eskalasi.
Runbook: “jika X berlaku, buat Y”, termasuk kontak, threshold dan suis (feature flag).
Latihan: load test terkawal dan drill insiden (legal dan diselaras).

Akhir sekali: uji, tetapi kekal legal dan berguna

Ujian DDoS ialah topik sensitif. Apa-apa yang menyentuh internet awam, sistem pihak ketiga atau infrastruktur tanpa kebenaran jelas adalah dilarang. Apa yang anda boleh dan patut lakukan:

Load test dalam staging sendiri (contohnya untuk endpoint mahal).
Chaos test untuk dependency (cache down, DB lambat, rate limit lebih ketat).
Latih proses respons: alert, komunikasi, eskalasi penyedia, langkah kecemasan.

Sumber dan bacaan lanjut

Sehingga kali seterusnya, Joe