Insiden DDoS Massive: Koneksi Internasional Drop Total & Switch Rack Bermasalah — DRC Berhasil Menyelamatkan

Jam 11 malam, Sabtu. Paling tenang biasanya — klien pada liburan, support tickets sepi, Grup WA NOC lagi rame bahas game. Aku lagi mode santai, ngopi sambil setengah nonton Netflix di monitor kedua. Eh, tiba-tiba — BEEEP BEEEP BEEEP. Alarm Grafana meraung. Layar ijo dadi abang kabeh. Grafik inbound internasional nanjak vertikal — 5 Gbps, 10 Gbps, 20 Gbps, 40 Gbps — mentok di kapasitas link. “Lha, iki piye, ta?” batinku. Launching game baru opo piye? Ternyata, iki serangan DDoS massive yang gak pernah kita bayangin sebelumnya.

Lha kok iso? Siapa yang narget? We have no idea at that moment. Yang jelas, lima menit sebelumnya trafik internasional normal di angka 2-3 Gbps. Sekarang 40 Gbps full, dan masih naik. Packet loss langsung lompat dari 0.01% jadi 35% dalam hitungan menit. Ping ke server Singapore — yang biasanya 35ms — tiba-tiba 450ms. Beberapa malah timeout. API calls dari klien luar negeri mulai banyak yang gagal. Telegram group chat NOC mulai rame: “Mas, website gak bisa diakses dari Eropa!” “Koneksi VPN ke kantor putus!” “Email queue numpuk, piye iki?” Panik? Pasti. Tapi tenang, ana solusine — asal timnya siap, prosedure jelas, dan DRC-nya teruji.

Grafana dashboard berubah total dalam hitungan menit. Lima menit sebelumnya trafik internasional cuma 2-3 Gbps — normal banget untuk Sabtu malam. Sekarang? 40 Gbps full throttle. Yang bikin tambah runyam, ini bukan serangan biasa. Dari analisis netflow yang sempat ke-record sebelum tools-nya overload, kami lihat pola UDP flood campur SYN flood dari ribuan IP sumber berbeda. Ini distributed reflection attack (DRDoS) yang amplification factor-nya gede banget — mungkin pake protokol NTP atau CLDAP yang bandwidth multiplier-nya bisa sampe 10-50x. Artinya, attacker cuma butuh bandwidth kecil buat ngehasilin banjir trafik gede di target. Dan targetnya jelas — upstream provider utama kami. Dampak langsung: link internasional saturated total, BGP session mulai flap, dan rute-rute ke luar negeri banyak yang withdrawn. Klien dari Eropa, Amerika, Australia pada telepon — website mereka gak bisa diakses sama sekali. Revenue loss langsung kerasa buat yang bisnisnya online.

Tapi tunggu, masalah gak mandek sampe situ. Salah satu Site Lead nelpon dari DC-2 — ada switch rack yang mulai ngasih gejala aneh. Temperature sensor di salah satu switch utama naik drastis dari 37°C normal ke 58°C dalam 30 menit. Dua dari empat fan tray di switch itu mati — mungkin udah melemah dari sebelumnya, dan beban trafik DDoS yang numpah jadi trigger terakhir. Spanning Tree Protocol mulai kirim Topology Change Notification terus-terusan. Beberapa server di rack itu tiba-tiba disconnected trus reconnect dalam siklus 5 menit. Ini perfect storm beneran — serangan dari luar sekaligus hardware failure di dalam. Tim NOC harus split fokus: satu grup handle DDoS mitigation, grup lain handle switch rack emergency. Komunikasi via channel dedicated incident response — gak pake chat umum biar gak chaos dan history kejadian tercatat rapi.

Dua masalah besar dalam satu malam — DDoS massive yang nyerang upstream provider dan hardware failure di switch rack DC-2. Ini kombinasi yang jarang banget terjadi, tapi pas terjadi efeknya luar biasa. Bayangno: klien luar negeri gak bisa akses karena link internasional saturated, sementara server lokal di DC-2 juga ada yang drop karena switch-nya bermasalah. Beberapa klien yang hybrid — punya server di DC-2 plus akses dari luar negeri — kena dampak dobel. Support ticket masuk 50+ dalam 30 menit pertama. Tapi inilah momen dimana DRC (Disaster Recovery Center) diuji beneran. Prosedur, runbook, dan latihan yang udah dilakukan sebelumnya — sekarang waktunya dieksekusi. Nggih, iki dudu drill. Iki nyata. Dan tim harus bergerak cepet tapi tetep kalem — panik gak bakal bantu situasi apapun. Fokus, prioritas, execute.

Aktivasi DRC Protocol: Langkah Awal yang Krusial

Langkah pertama yang kami lakukan adalah aktivasi DRC protocol secara resmi. Ini bukan prosedur formalitas doang — ini ngatur siapa ngapain, channel komunikasi mana yang dipake, escalation path ke management kaya gimana, dan timing review progress. Tim NOC yang jaga malam itu cuma 3 orang — langsung di-reinforce dengan 2 orang dari tim senior yang di-call in. Dalam 10 menit, kita punya 5 orang di bridge call, terbagi dalam 2 task force: Tim Alpha fokus ke DDoS mitigation, Tim Bravo fokus ke switch rack issue. Masing-masing punya leader dan dokumentasi sendiri. Tool komunikasi utama: Slack dedicated channel + voice bridge biar gak ada miskomunikasi tulisan. Update diberikan setiap 15 menit — apa yang udah dilakukan, apa yang masih pending, apa blocker-nya.

BGP Traffic Rerouting: Mindahin Jalur di Tengah Badai

Kita punya backup upstream provider — throughput lebih kecil (10 Gbps vs 40 Gbps utama) tapi lumayan buat trafik prioritas. Masalahnya, secara default BGP routing bakal tetep milih path utama karena bandwidth lebih gede. Kita harus intervensi manual. Tim Alpha langsung login ke router edge — Juniper MX240 — dan apply route-map untuk set local-preference lebih tinggi buat rute dari backup provider. Dengan cara ini, trafik keluar (outbound) pake backup path. Tapi trafik masuk (inbound) lebih tricky — kita perlu koordinasi sama upstream utama buat advertise prefix kita via backup provider dengan AS path yang lebih pendek. Sambil itu, kita minta upstream utama lakukan RTBH (Remotely Triggered Black Hole) untuk IP-IP sumber serangan yang teridentifikasi. Efeknya? Dalam 5-10 menit, trafik inbound mulai turun — dari 40 Gbps ke sekitar 15 Gbps. Belum normal, tapi udah jauh lebih baik. Packet loss turun dari 35% ke 8%. Cukup buat klien-klien prioritas bisa akses lagi — meskipun masih lambat.

set policy-options policy-statement SET-BACKUP-PREF term 10 from protocol bgp
set policy-options policy-statement SET-BACKUP-PREF term 10 from neighbor 203.0.113.2
set policy-options policy-statement SET-BACKUP-PREF term 10 then local-preference 200
set policy-options policy-statement SET-BACKUP-PREF term 10 then accept
set policy-options policy-statement SET-BACKUP-PREF term 20 then reject
set routing-options router-id 192.0.2.1
set routing-options autonomous-system 65001

Edge Mitigation: FortiGate DDoS Protection

Sambil nunggu upstream filtering bekerja, kita enable DDoS protection profile di FortiGate 600D. Settings-nya kita set agresif — dalam situasi darurat, better safe than sorry. UDP flood threshold kita turunin dari 5000 pps ke 1000 pps per source IP. SYN flood dari 3000 ke 500. ICMP flood dari 2000 ke 200. Session limit per source kita set 1000 — jadi kalo ada IP yang bikin koneksi lebih dari 1000 simultan, langsung di-block. Efek sampingnya? Beberapa klien dengan koneksi legit yang padet bisa kena false positive. Tapi kita siapin whitelist untuk IP-IP klien prioritas yang udah terdaftar. Tim komunikasi langsung kirim notifikasi ke klien-klien besar — jelasin situasi dan minta mereka tenang sambil kita kerjakan mitigasi. Transparansi itu penting. Klien lebih tenang kalo mereka tau kita lagi ngapain.

config firewall ddos-policy
edit 1
set service "UDP"
set srcaddr "all"
set dstaddr "all"
set threshold 1000
set action block
next
edit 2
set service "SYN"
set srcaddr "all"
set dstaddr "all"
set threshold 500
set action block
next
edit 3
set service "ICMP"
set srcaddr "all"
set dstaddr "all"
set threshold 200
set action block
next
end

Switch Rack Emergency: Fisik Juga Kena Dampak

Sementara Tim Alpha sibuk dengan BGP dan firewall, Tim Bravo action ke DC-2. Physical check: dua fan tray di switch utama rack 12-C mati total. Temperature 58°C — nyaris nyentuh threshold critical 65°C. Kalo sampe overheat, switch bisa mati total dan butuh cooling dulu sebelum nyala lagi — bisa 30-60 menit. Keputusan: bypass routing via switch backup di rack yang sama, matikan switch utama, biarin cooling selama 15 menit. Switch backup memang punya kapasitas lebih kecil (48 port gigabit vs 96 port 10GbE), tapi cukup buat keep critical server tetap online. Proses cutover butuh waktu 20 menit — termasuk verifikasi kabel dan pastiin Spanning Tree udah stabil. Hasilnya: semua server di rack 12-C kembali online. Temperature switch utama turun ke 42°C setelah fan eksternal kita arahin. Masalah switch utama ditangani besoknya pas jam kerja — ganti fan tray dan full diagnostic.

Pemulihan Bertahap: Jangan Buru-Buru Balikin Trafik

Setelah sekitar 2 jam mitigasi intensif, situasi mulai terkendali. Trafik DDoS dari upstream utama udah difilter — dropped dari 40 Gbps ke 2-3 Gbps sisanya. Backup provider handle trafik prioritas dengan stabil. Switch rack udah aman. Tapi kami gak langsung balikin semua trafik ke path normal. Prinsipnya: gradual recovery sambil monitor ketat. Tahap 1 (30 menit): balikin trafik untuk klien-klien critical — yang bisnisnya real-time kayak payment gateway dan trading platform. Tahap 2 (30 menit berikutnya): balikin trafik klien menengah — VPS dan hosting biasa. Tahap 3 (1 jam): balikin semua trafik, termasuk yang non-priority. Setiap tahap di-review dulu — packet loss, latency, CPU utilization di router edge. Kalo ada anomaly, langsung rollback. Alhamdulillah (matur nuwun), semua tahap berjalan lancar. Total incident response time: 4 jam 20 menit dari deteksi pertama sampai full recovery.

Pelajaran Penting dari Insiden Ini

Barêng wis kelakon, kami review semua yang terjadi. Ada beberapa pelajaran kunci: pertama, DRC harus di-test secara berkala — bukan cuma dokumen di folder. Runbook yang gak pernah di-simulate bakal chaos pas kejadian nyata. Kedua, backup provider bukan cuma pelengkap — dia penyelamat kalo provider utama tumbang. Pastiin kapasitasnya cukup buat trafik prioritas, minimal 25% dari kapasitas utama. Ketiga, dedicated communication channel untuk incident response itu krusial. Jangan campur dengan chat harian — informasi penting bakal ketimbun meme dan stiker. Keempat, monitoring alerting harus proper — anomaly detection yang bisa bedain trafik normal vs attack. Alert threshold jangan terlalu sensitif (bakal noise) tapi juga jangan terlalu longgar (kebakaran baru tau). Tim kami langsung bikin post-mortem dan update beberapa runbook berdasarkan pengalaman iki.

Buat sampeyan yang ngelola datacenter — atau bahkan cuma punya beberapa server — pliss, jangan anggap remeh DRC. Insiden kaya gini bisa terjadi kapan aja, ke siapa aja. Gak peduli seberapa bagus infrastruktur sampeyan, kalo gak ada disaster recovery plan yang matang dan teruji, satu serangan bisa bikin semuanya berantakan. Investasi di DRC itu bukan biaya — itu asuransi buat bisnis. Luangkan waktu buat konfigurasi monitoring server yang proper, pastiin BGP redundancy jalan dengan bener, dan selalu update konfigurasi firewall sampeyan. Gak ada yang lebih berharga daripada pengalaman langsung — tapi akan lebih baik kalo pengalaman itu milik orang lain, bukan kita. Learn from others’ mistakes.

Piye, seru ta? Insiden kaya gini emang gak bisa dihindari — tapi persiapan yang matang bisa bikin perbedaan antara bencana besar sama insiden yang bisa di-handle. Monggo dipraktekno pelajaran dari artikel iki, dan pastiin DRC sampeyan siap kapan aja, gak cuma di atas kertas. Pernah ngalamin kasus DDoS yang lebih serem? Atau punya tips mitigasi lain? Share neng komentar ya — sopo ngerti iso bantu kanca-kanca liyane. Matur nuwun wis moco, good luck dan tetap semangat!