Website tiba-tiba tidak bisa diakses, CPU server melonjak, dan jumlah request naik tajam? Salah satu kemungkinan yang perlu diperiksa adalah serangan Distributed Denial of Service (DDoS). Namun, lonjakan traffic juga bisa disebabkan promosi viral, crawler, kesalahan konfigurasi, atau aplikasi yang bermasalah. Pertolongan pertama harus dimulai dari membuktikan penyebab gangguan, bukan langsung memblokir seluruh negara atau menjalankan perintah firewall dari artikel lama.
Panduan ini menyajikan langkah tanggap insiden yang lebih relevan untuk pemilik WordPress, VPS, dan website bisnis pada 2026. Cerita asli penulis saat server dua blog terganggu pada 2018 beserta enam gambar dokumentasinya tetap disimpan sebagai arsip; instruksi iptables/ipset historis tidak disalin menjadi rekomendasi baru karena konfigurasi yang salah dapat memutus trafik pelanggan sah.
Checklist 15 menit pertama ketika website diduga kena DDoS
| Prioritas | Tindakan | Tujuan |
|---|---|---|
| 0–3 menit | Periksa monitoring dari dua lokasi/jaringan dan status penyedia hosting | Menghindari salah diagnosis ketika gangguan hanya berasal dari ISP atau aplikasi |
| 3–5 menit | Catat waktu, error, grafik request, CPU/RAM, dan bandwidth | Membuat baseline insiden |
| 5–8 menit | Hubungi penyedia hosting/CDN dan aktifkan mitigasi yang disarankan | Mengatasi traffic berbahaya di lapisan yang tepat |
| 8–12 menit | Evaluasi aturan WAF, rate limiting, dan perlindungan origin | Mengurangi beban sambil menjaga pengguna normal |
| 12–15 menit | Uji halaman penting, checkout, login, dan endpoint API | Memastikan mitigasi tidak memblokir fungsi bisnis |
1. Pastikan penyebab website down sebelum menyimpulkan DDoS
Periksa gejala dari log dan pemantauan
Bandingkan waktu downtime dengan trafik HTTP, jumlah koneksi aktif, error 5xx, kapasitas CPU, memory, network ingress/egress, serta log CDN dan origin. Pahami bandwidth dan perbedaan antara alamat IP pengguna, jaringan CDN, dan server origin agar tidak keliru membaca sumber traffic. Untuk pemeriksaan jaringan, lihat pula cara mengecek IP publik.
Lonjakan request ke satu endpoint dapat mengindikasikan serangan HTTP layer 7, sedangkan kejenuhan koneksi dan paket pada jaringan bisa mengarah pada masalah layer 3/4. Error 502 Bad Gateway belum tentu membuktikan serangan; ia juga dapat muncul karena upstream tidak merespons.
Bedakan bot normal, crawler, dan traffic yang merusak layanan
Bot mesin pencari dapat mengakses website secara sah. Pelajari konsep crawling website dan pengambilan data otomatis. Jangan sampai aturan keamanan justru memblokir pengguna dan bot pencarian yang valid tanpa bukti adanya penyalahgunaan.
2. Aktifkan mitigasi CDN/WAF, bukan sekadar menaikkan kapasitas server
Cloudflare Under Attack Mode sebagai opsi darurat
Cloudflare menyediakan Under Attack Mode yang menampilkan pemeriksaan keamanan tambahan untuk menahan sebagian traffic HTTP layer 7. Menurut dokumentasi Cloudflare yang diperbarui pada April 2026, fitur ini merupakan salah satu opsi terakhir saat zona sedang diserang; halaman interstitial dapat mengganggu sebagian pengunjung dan analitik. Aktifkan hanya selama diperlukan, pantau dampaknya, dan nonaktifkan setelah lalu lintas terkendali.
Jika hanya halaman tertentu yang diserang, pertimbangkan aturan yang lebih selektif ketimbang menantang seluruh pengunjung. Proses pengamanan harus memperhatikan pengalaman pengguna mobile serta alur login, formulir, checkout, webhook, dan API yang mungkin sensitif terhadap challenge.
Gunakan rate limiting dan managed rules secara hati-hati
Rate limiting membatasi pola request berlebih pada URL atau tindakan berisiko. WAF membantu mengidentifikasi lalu lintas mencurigakan. Namun, aturan terlalu agresif dapat memblokir pengguna yang berbagi jaringan, scraper sah, atau integrasi teknis. Mulailah dari mode observasi bila memungkinkan, lalu uji cakupan berdasarkan log dan kebutuhan aplikasi.
3. Hubungi hosting atau penyedia jaringan sejak awal
Jangan menunggu hingga VPS tidak bisa diakses melalui SSH. Tim hosting atau provider jaringan dapat melihat anomali pada layer yang tidak tampak dari dashboard WordPress. Berikan waktu kejadian, alamat domain, status layanan, cuplikan grafik, serta request-id bila tersedia. Pada serangan volumetrik, memblokir request di aplikasi saja sering terlambat karena bandwidth upstream sudah penuh.
Untuk mengerti mengapa lapisan perantara penting, baca fungsi proxy server dan cara kerja proxy; CDN dan reverse proxy dapat membantu memfilter request sebelum mencapai origin. Tidak semua traffic dan protokol otomatis terlindungi oleh konfigurasi HTTP proxy yang sama.
4. Lindungi IP origin dan periksa DNS
Jika website memakai Cloudflare, pastikan catatan DNS untuk HTTP yang seharusnya diproxy sudah benar. IP origin yang terbuka melalui subdomain, service lain, atau catatan DNS-only dapat memungkinkan serangan bypass langsung ke server. Audit konfigurasi dengan penyedia hosting sebelum membatasi akses jaringan; pemblokiran asal-asalan berisiko memutus komunikasi dari jaringan CDN sendiri.
Pemisahan komponen website dinamis, database, cache, dan layanan email dapat membantu memahami titik kegagalan. Jangan mengubah konfigurasi besar-besaran saat bukti insiden belum dikumpulkan.
5. Periksa firewall dan akses administratif tanpa membuat downtime baru
Artikel asli memuat langkah berbasis SSH, iptables, dan ipset termasuk pemblokiran IP berdasarkan negara. Untuk kebutuhan saat ini, konfigurasi firewall harus menyesuaikan sistem operasi, versi kernel, urutan rule, SSH allowlist, serta kebijakan jaringan provider. Memblokir seluruh IP dari satu negara bukan solusi menyeluruh: pelaku dapat memakai botnet lintas wilayah, dan banyak pengunjung sah dapat ikut terdampak.
Bila Anda tidak memiliki akses administrator berpengalaman, jangan menjalankan perintah yang ditemukan di internet pada server produksi. Simpan konfigurasi, sediakan jalur rollback out-of-band, dan minta bantuan provider. Untuk hardening dan pemulihan, periksa juga prinsip backup database; contoh perintah dalam artikel lain harus ditinjau sesuai lingkungan sistem terkini.
Pengalaman nyata saat dua server blog mengalami gangguan
Penulis pernah menerima email monitoring yang menyatakan catperku.com tidak bisa dimuat pada dini hari di Maret 2018. Dalam dokumentasi awal, terjadi lonjakan traffic dan pemakaian CPU pada infrastruktur yang dikelola saat itu. Kisah ini merupakan catatan pengalaman pada periode tersebut, bukan bukti bahwa pola serangan, sumber IP, atau langkah blokir historis cocok diterapkan pada server lain tahun 2026.
Catatan arsip: gambar peringatan Jetpack/Linode, grafik traffic, WHOIS, dan sesi SSH berikut dipertahankan sebagai dokumentasi asli. Identifikasi negara dari IP tidak cukup untuk menyimpulkan pelaku serangan.
6. Uji pemulihan, dampak SEO, dan pengalaman pelanggan
Setelah mitigasi, lakukan tes dari jaringan berbeda. Periksa halaman utama, halaman produk, formulir leads, login, dan transaksi. Pantau respons API, validasi cache, serta perbaikan error server. Situs yang berkali-kali tidak tersedia dapat mengganggu akses pengunjung serta kemampuan bot mengakses halaman, meskipun dampak pada ranking bergantung pada durasi dan kondisi gangguan.
Periksa sitemap XML, status indexing, dan URL penting setelah layanan pulih. Lanjutkan dengan audit SEO teknis serta pemulihan traffic organik jika sebelumnya ada dampak bisnis yang terukur.
7. Buat postmortem untuk mencegah insiden serupa
Dokumentasikan timeline, alarm pertama, metrik puncak, aturan yang diaktifkan, False Positive, dan lamanya pemulihan. Tentukan pemilik tindakan, lokasi backup, jalur eskalasi 24 jam, serta batas toleransi downtime. Jadwalkan uji aturan, pantau perubahan sistem, dan evaluasi apakah risiko membutuhkan layanan mitigasi tambahan. Rencana ini relevan untuk agensi, pemilik blog, dan pengelola toko online yang bergantung pada traffic pencarian.
FAQ: pertolongan pertama menghadapi DDoS
1. Apa itu DDoS attack?
Serangan yang membanjiri target dengan traffic atau request dari banyak sumber sehingga ketersediaan layanan terganggu.
2. Apakah website lambat berarti pasti kena DDoS?
Tidak. Hosting bermasalah, plugin, database, dan lonjakan pengunjung normal juga dapat membuat website lambat.
3. Apa yang harus dilakukan dalam lima menit pertama?
Verifikasi gangguan, simpan log dan waktu kejadian, lihat grafik, dan hubungi provider atau tim keamanan.
4. Apakah Cloudflare gratis dapat membantu?
Fitur dan batasan bergantung pada paket dan konfigurasi; penggunaan proxy serta proteksi yang benar dapat membantu mengurangi sebagian jenis traffic berbahaya.
5. Kapan Under Attack Mode sebaiknya digunakan?
Saat serangan HTTP layer 7 memerlukan pemeriksaan tambahan dan konsekuensi terhadap pengunjung sudah dipertimbangkan.
6. Apakah mode Under Attack boleh dibiarkan selamanya?
Tidak direkomendasikan sebagai pengaturan permanen tanpa alasan; pengaruhnya terhadap pengalaman pengguna perlu dievaluasi.
7. Apakah memblokir IP dari satu negara efektif?
Kadang dapat mengurangi traffic tertentu, tetapi bukan solusi lengkap dan bisa memblokir pengunjung sah.
8. Apakah harus menambah RAM atau upgrade VPS?
Belum tentu. Serangan jaringan perlu ditangani pada layer upstream/CDN; upgrade server saja bisa tidak cukup.
9. Mengapa IP origin penting dilindungi?
IP yang terekspos dapat memungkinkan traffic langsung ke server melewati filter CDN.
10. Apa hubungan DDoS dengan error 502?
DDoS bisa membuat upstream tidak responsif, tetapi 502 juga muncul karena konfigurasi atau gangguan backend biasa.
11. Apakah backup database menghentikan DDoS?
Tidak. Backup membantu pemulihan data dan keberlanjutan operasional, bukan memfilter request.
12. Kapan harus meminta bantuan ahli?
Segera ketika layanan bisnis penting terganggu, log menunjukkan serangan besar, atau perubahan firewall berisiko memutus akses.
Referensi resmi dan teknis
- Cloudflare — Under Attack mode (2026)
- Cloudflare — Protect your origin server
- AWS — Best Practices for DDoS Resiliency (2026)
- CISA — DDoS response guidance
walah,,,parah juga sih ya klo emg bener dr mrk.
Gue gak mau suudzon sih, tapi gue bangga kalau beneran dari mereka. Blogger kecil lawan raksasa XD
alhamdulillah saya belum pernah kena gituan, untung ada cloudflare ya. setahu saya biasanya mereka hanya orang iseng aja mas ngetest script yang mereka buat atau dapat. saya doakan semoga blognya aman kembali. salam
Kali ini enggak iseng kayaknya. Kalau iseng biasanya masih ringan. Ini serius deh 😀
Mumet mas baca scriptnya… ??
Tapi parah gila, yg salah siapa, yg marah siapa..
Pokoknya hajaarrr mereka..
Tau deh, padahal gue cuma blogger kecil euy~
Serem amat mas
emang, langsung pusing kemaren malem 😀
Bikin ketar ketir ini mas. Btw grup2 wa sekarang jg lagi diserang spam sama ucweb, masuk grup, nyepam trus keluar, n pelakunya pake banyak nomer, kayake sih jaringan gitu deh. Heran aja sih mainnya pada g elegan gini
wah, masak sih sampe segitunya? :O
Semangat mas fahmi. Smoga blog nya aman lagi aamiin
Amiiin 😀
Kaya orang ngutang malah dianya yg lebih galak dr yg ngutangin ya
hahahaa, mirip sih. tapi orang ngutang masih mau bayar biasanya. ini kagak 😀
mas, sumpah saya gak ngerti padahal baca dari awal sampe akhir. otak saya blm nyampe. kayaknya perlu belajar jg
pertarungan sengit.. mereka tampaknya salah pilih musuh jago IT gini. kalau aku mah udahlah ampuun
Untung wae mas yang diserang kamu. Kalo aku ya udah milih nyerah ganti server. hosting kena malware aja web-webku kukut :-D.
Keren euy tutorialnya. Tak bookmark siapa tau suatu hari aku ngalamin hal keren gini. Haha