Belajar Network Engineer - DDoS & Traffic Protection
Menghadapi serangan yang bertujuan melumpuhkan, bukan mencuri: taksonomi DDoS dari volumetrik, protokol, sampai application layer, mekanisme amplifikasi DNS dan memcached, lapisan mitigasi dari scrubbing center, anycast CDN, rate limiting, RTBH dan FlowSpec, serta praktik mengamankan edge jaringan
#Pendahuluan
Setelah di episode 19 koneksi kalian terenkripsi, kita hadapi ancaman yang tidak berusaha masuk sama sekali — ia hanya ingin semuanya lumpuh. Serangan DDoS (Distributed Denial of Service) adalah satu-satunya kategori insiden yang bisa menjatuhkan bank besar berjam-jam tanpa satu pun credential dicuri, dan edge jaringan kalian adalah medan pertempuran pertamanya.
Episode ini membahas taksonomi serangan, ekonomi amplifikasinya, lapisan-lapisan mitigasi dari upstream sampai server, ditutup checklist proteksi edge yang bisa langsung dipraktikkan.
#Anatomi Serangan DDoS
Bedakan dulu dua kata kuncinya:
- DoS: satu sumber menyerang satu target.
- DDoS: ribuan-jutaan host (botnet) serentak — sumber terdistribusi membuat blokir per-IP sia-sia.
- Amplification/reflection: attacker mengirim permintaan kecil ke server pihak ketiga dengan spoofed source IP = korban; jawaban raksasa menghantam korban. Botnet kecil menghasilkan tembakan raksasa.
#Tiga Kategori Utama
| Lapis | Target | Contoh | Ukuran Tipikal |
|---|---|---|---|
| Volumetrik | Bandwidth link | UDP flood, DNS/NTP/memcached amplification | Ratusan Gbps-Tbps |
| Protokol | State perangkat infra | SYN flood, ACK/PING flood | Menitri-Gbps |
| Application (L7) | Resource aplikasi/DB | HTTP GET/POST flood, slowloris | Kecil tapi mematikan |
Perhatikan asimetrisnya: volumetrik menyerang jalur (link penuh sebelum sampai ke kalian), protokol menyerang memori perangkat (SYN backlog table), L7 menyerang logika aplikasi (satu request mahal vs murah). Mitigasinya berbeda total — makanya klasifikasi adalah langkah pertama respons insiden.
#Matematika Amplifikasi
Kekuatan reflection dihitung sebagai response bytes / request bytes:
DNS open resolver : hingga ~50x (ANY query)
NTP monlist (lama) : hingga ~550x
Memcached (UDP) : hingga ~50.000x <- pemerkosa rekor 2018 (1.7 Tbps)Pelajaran arsitekturnya: layanan UDP publik tanpa autentikasi adalah amunisi siap pakai. Server kalian sendiri harus dicek menjadi bukan sumber amplifikasi (topik hygiene di bawah), bukan cuma dibekali pertahanan sebagai korban.
#Lapisan-Lapisan Mitigasi
Tidak ada satu kotak penyelamat; pertahanan DDoS adalah susunan lapisan sesuai letak serangan:
#Lapisan Upstream: Scrubbing & Anycast
Serangan volumetrik ratusan Gbps tidak mungkin dimitigasi di router kalian — link sudah mati sebelum trafik tiba. Solusinya menyerahkan penyaringan ke infrastruktur yang lebih besar:
- Scrubbing center (provider/Akamai/Cloudflare): trafik dialihkan (BGP redirect/DNS switch) ke fasilitas pembersih; trafik bersih dikirim balik via GRE.
- CDN + Anycast: konten didistribusikan ke puluhan lokasi; serangan tersebar alih-alih fokus satu IP. Untuk web modern ini pertahanan lapis pertama de facto.
Kontrak pentingnya: always-on vs on-demand. On-demand lebih murah tetapi butuh deteksi + aktivasi (menit-jam) — selama itu situs mati. Hitung toleransi downtime bisnis, bukan cuma harga bulanan.
#Lapisan Edge: Yang Bisa Dilakukan Router Kalian
Trafik yang lolos sampai edge harus disaring efisien:
- RTBH (Remotely Triggered Black Hole): saat prefix tertentu diserang, announce-nya ke null route upstream — seluruh IP dikorbankan demi selamatnya sisanya.
- BGP FlowSpec: versi halusnya — aturan filter (src/dst/port/paket) didorong via BGP ke router tepi, memblokir vektor spesifik tanpa blackhole total.
- uRPF (strict mode): paket dengan source IP mustahil dibuang sejak awal — merusak skema spoofing refleksi.
- ACL/rate-limit agresif di tepi: batasi ICMP/UDP tak dikenal, izinkan service resmi.
Contoh rate limiting ICMP pada Cisco-style edge:
access-list 110 permit icmp any any echo
class-map match-all ICMP-FLOOD
match access-group 110
policy-map EDGE-IN
class ICMP-FLOOD
police cir 2000000 conform-action transmit exceed-action drop
interface gi0/0
service-policy input EDGE-IN#Lapisan Host/Aplikasi: Bertahan Saat Trafik Sampai
Untuk vektor protokol & L7, pertahanan terakhir ada di sistem:
- SYN cookies: kernel tak menyimpan state untuk SYN setengah — SYN flood kehilangan daya lukanya.
- Rate limiting per-client di reverse proxy/LB (nginx
limit_req, HAProxy stick-table): HTTP flood dibuang sebelum menyentuh app server. - WAF/challenge (JS challenge, CAPTCHA): bot tanpa browser ditolak — sangat efektif untuk L7 flood generik.
- Autoscaling + queue: menyerap lonjakan sah sekaligus memberi waktu mitigasi.
#Mendeteksi Lebih Awal: Sinyal di Monitoring Kalian
Episode 10 kini bayar: indikator awal serangan terlihat di dashboard sebelum telepon user berbunyi:
- PPS/bandwidth inbound naik vertikal di luar baseline.
- Lonjakan SYN/SYN-ACK ratio atau TCP flags aneh.
- CPU/state-table firewall-router mendekati maksimum.
- Flow analysis (NetFlow!): satu destinasi, ribuan sumber UDP dari port acak.
Bangun alert threshold-nya SEKARANG — deteksi manual saat serangan adalah olahraga menit-menit yang kalah cepat.
Warning
Jangan rate-limit terlalu agresif "biar aman": NAT carrier-grade, proxy kantor besar, dan mobile CGNAT berbagi ribuan user di satu IP publik — memblokir satu IP bisa memblokir ribuan pelanggan sah. Gunakan ambang adaptif dan whitelist partner penting.
#Praktik: Checklist Proteksi Edge
Rangkuman aksi konkret untuk jaringan studi kasus kita — urut prioritas:
[ ] Audit layanan UDP publik: DNS recursion off utk dunia luar, NTP monlist off,
memcached TIDAK expose publik (cegah jadi sumber amplifikasi!)
[ ] Aktifkan uRPF strict pada interface customer-facing
[ ] Rate-limit ICMP/UDP tak-resmi di edge (contoh policy di atas)
[ ] Sinkronkan dengan ISP: apakah tersedia scrubbing on-demand? SLA aktivasinya?
[ ] Siapkan runbook RTBH: komunitas blackhole + prosedur eskalasi 24/7
[ ] Depan web publik: CDN/anycast + WAF + challenge layer
[ ] Kernel host: tcp_syncookies=1, conntrack sizing cukup
[ ] Reverse proxy: limit_req/limit_conn per endpoint sensitif (login!)
[ ] Uji berkala: load test sendiri + simulasi failover mitigasi
[ ] Kontak darurat ISP/security team tersimpan offline (serangan = internet pun chaos)Dua baris pertama layak digarisbawahi: hygiene jadi sumber adalah kontribusi kalian bagi ekosistem internet — dan audit keamanan formal akan menanyakannya.
#Common Pitfalls
- Membeli kotak anti-DDoS 10 Gbps padahal link 1 Gbps — serangan 100 Gbps tidak pernah menyentuh kotak itu; bandwidth link-lah yang mati duluan. Pertahanan volumetrik hidup di upstream, bukan di rack kalian.
- Blackhole sebagai solusi default — RTBH yang dipicu malas mengubah serangan jadi downtime yang diserang sendiri; gunakan sebagai last resort dengan prosedur jelas.
- Lupa L7 karena fokus angka Gbps — 5 Gbps HTTP flood ke endpoint login bisa lebih merusak daripada 100 Gbps UDP yang sudah disaring upstream; uji kedua lapisannya.
- Runbook cuma dokumen — saat serangan pukul 02.00, prosedur yang belum pernah direhepasi akan gagal; latih tabletop exercise minimal tiap semester.
#Penutup
Inti yang harus dibawa pulang:
- Tiga kategori serangan menyerang tiga hal berbeda — bandwidth (volumetrik), state perangkat (protokol), resource aplikasi (L7) — dan mitigasinya berlapis sesuai letaknya.
- Volumetrik besar hanya bisa dijawab upstream: scrubbing center, CDN/anycast, always-on vs on-demand adalah keputusan bisnis-downtime.
- Di edge kalian: uRPF, rate limiting, RTBH/FlowSpec; di host: SYN cookies, proxy rate-limit, WAF challenge.
- Deteksi dini datang dari monitoring episode 10; hygiene agar tak jadi sumber amplifikasi adalah tanggung jawab dasar engineer.
Di episode 21 kita kembali ke routing level tertinggi: BGP lanjutan — path attributes, route reflector, communities, peering IX versus transit, dan praktik multihoming dua ISP yang benar. Sampai jumpa!