Keamanan

Serangan DDoS: Jenis, Deteksi Dini, dan Mitigasi pada VPS

31 October 2026 7 min baca
Serangan DDoS: Jenis, Deteksi Dini, dan Mitigasi pada VPS

Serangan distributed denial of service (DDoS) adalah serangan yang paling mudah dibeli dan paling sulit dilawan sendiri. Modusnya sederhana: membanjiri server dengan trafik sampai tidak bisa melayani pengguna asli. Artikel ini menjelaskan jenis serangan DDoS, cara mendeteksinya lebih awal, dan langkah mitigasi realistis untuk pemilik VPS di Indonesia.

1. Apa yang Sebenarnya Habis Saat Server "Tumbang"

DDoS tidak selalu menjatuhkan server. Yang lebih sering habis lebih dulu adalah salah satu dari empat sumber daya ini:

  • Bandwidth upstream — pipa dari provider ke server penuh; paket dibuang sebelum masuk VPS.
  • Tabel koneksi — kernel kehabisan slot untuk menyimpan koneksi setengah jadi.
  • Worker aplikasi — PHP-FPM, thread database, atau connection pool habis karena tiap request palsu memakan satu slot.
  • Resource CPU/RAM — habis oleh permintaan yang tampak sah tapi mahal, misalnya pencarian tanpa indeks.

Klasifikasi ini penting karena menentukan senjata mitigasi. Banjir bandwidth tidak bisa diselesaikan dengan menambah RAM; banjir aplikasi tidak bisa diselesaikan dengan menaikkan bandwidth.

2. Jenis Serangan DDoS dan Sidikannya

Lapisan 3/4: volume dan protokol

  • SYN flood — penyerang mengirim SYN tanpa menyelesaikan handshake. Sisi server: banyak koneksi SYN-RECV.
  • UDP flood / amplification — DNS, NTP, memcached, dan SSDP bisa dipakai memantul dengan rasio 1:50 sampai 1:50.000 karena paket respons jauh lebih besar dari permintaan.
  • ICMP flood — kuno, mudah dideteksi, masih efektif bila bandwidth kecil.

Lapisan 7: tiruan trafik nyata

  • HTTP flood — ribuan request GET ke halaman murah atau POST ke endpoint mahal, sering memakai user-agent browser sejati.
  • Slowloris / R.U.P.D.Y.-like — koneksi dibuka lalu dikirim byte per byte untuk menahan worker selama mungkin.
  • Cache-busting — query string acak membuat setiap request miss cache dan jatuh ke aplikasi.

Non-volume: serangan logika

  • Endpoint berat seperti ekspor laporan, thumbnails, atau pencarian penuh.
  • Autentikasi berulang dengan bcrypt/argon2 yang memang dirancang lambat.

Serangan kategori terakhir inilah yang paling sering disalahartikan sebagai "server sedang bermasalah", karena trafik totalnya kecil.

3. Deteksi Dini: Kenali Baseline Anda

Tanpa baseline, semua grafik terlihat menyeramkan. Catat minimal empat angka ini saat kondisi normal:

ss -s
cat /proc/net/snmp | grep -i "^Ip:"
iftop -i eth0 -L 20
nginx -V 2>/dev/null; tail -f /var/log/nginx/access.log | head

Perintah yang membedakan SYN flood dari trafik biasa:

ss -tan state syn-recv | wc -l
netstat -s | grep -iE "listen|syn"

Angka SYN-RECV ratusan itu normal di situs ramai; angka puluhan ribu hampir pasti banjir. Untuk HTTP flood, agregasi log lebih berguna daripada membaca satu per satu:

tail -n 200000 /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

tail -n 200000 /var/log/nginx/access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -15

Curigai satu IP dengan request mencurigakan tinggi, satu URL yang dominan, atau satu rentang ASN yang belum pernah muncul di analytics Anda.

4. Mitigasi Level Server: yang Bisa Anda Lakukan Sendiri

Naikkan ketahanan kernel terhadap koneksi setengah jadi:

cat > /etc/sysctl.d/99-anti-ddos.conf <<'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 32768
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_fin_timeout = 15
net.core.netdev_max_backlog = 32768
EOF
sysctl --system

Di sisi web server, batasi koneksi dan laju request per klien. Contoh nginx:

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;

server {
    listen 443 ssl;
    limit_req zone=perip burst=40 nodelay;
    limit_conn connperip 20;
    limit_req_status 429;

    location ~* /(wp-login.php|xmlrpc.php|admin-ajax.php) {
        limit_req zone=perip burst=5 nodelay;
    }
}

Tekankan 429, bukan 503, supaya pemantau uptime dan mesin pencari memahami ini penolakan sementara. Untuk serangan slow, kecilkan timeout:

client_body_timeout 5s;
client_header_timeout 5s;
send_timeout 5s;
keepalive_timeout 10s;

5. Mitigasi Level Network: Batas Realistis VPS

Perlu diakui terus terang: bila bandwidth Anda 1 Gbps dan serangan masuk 20 Gbps, tidak ada satu pun konfigurasi di dalam VPS yang bisa menolong. Paket dibuang di upstream. Yang bisa dilakukan pemilik VPS:

  • Minta provider menyaring di upstream — cek apakah paket Anda include mitigasi dasar dan apakah bisa diaktifkan lewat panel.
  • Pindahkan DNS ke provider yang punya anycast sehingga trafik dibuang sebelum menyentuh IP origin Anda.
  • Sembunyikan IP origin — jangan kirim email, jangan expose panel, dan jangan jalankan mail server di IP web yang sama.
  • Tahan dan naikkan — kalau IP Anda sudah masuk daftar serangan, ganti IP lebih murah daripada berperang.

6. CDN dan Reverse Proxy: Perisai Paling Hemat

Untuk sebagian besar situs, CDN adalah mitigasi DDoS lapis-7 dengan nilai terbaik: ia menyerap trafik statis, menambah cache, memberi rate limiting global, dan menyembunyikan IP origin di balik ribuan edge server. Cara memverifikasi bahwa origin benar-benar terlindungi:

  • Buka hanya port 80/443 dari rentang IP CDN di firewall VPS Anda.
  • Pastikan header X-Forwarded-For diverifikasi, bukan dipercaya mentah, agar IP klien yang dicatat tidak bisa dipalsukan.
  • Uji akses langsung ke IP origin: curl -k https://IP_ORIGIN harus gagal, bukan menyajikan situs.
  • Aktifkan mode "under attack" hanya saat perlu — bila menyala permanen, pengunjung sah ikut terganggu.

Aturan firewall untuk membatasi akses ke CDN saja dibahas di Firewall VPS: UFW, iptables, atau nftables?.

7. Runbook: 30 Menit Pertama Saat Diserang

Ketenangan saat insiden datang dari prosedur yang sudah ditulis sebelumnya. Urutan yang kami sarankan:

  1. Cek jenis gangguan: bandwidth penuh, worker habis, atau CPU tinggi? Lihat iftop, ss -s, dan top bergantian.
  2. Pisahkan gejala dari serangan: request yang sama bisa jadi berasal dari integrasi API internal Anda sendiri.
  3. Tahan yang paling murah: nyalakan cache agresif, batasi rate, matikan fitur berat sementara.
  4. Blokir pola, bukan seluruh negara: blokir rentang/ASN hanya bila buktinya kuat; pemblokiran luas sering menolak pelanggan asli.
  5. Hubungi provider dengan angka, bukan kesan: jam mulai, Gbps/pps terukur, dan grafik yang Anda kirim.
  6. Simpan bukti: potong 50 ribu baris log dan arsipkan; setelah serangan usai, tidak ada cara merekonstruksi apa yang terjadi.
  7. Pulihkan bertahap: lepas aturan pemblokiran satu per satu agar traffic asli kembali tanpa membuka kembali pintu.

Nyalakan pencatatan yang memadai sebelum butuh, karena saat insiden, log adalah satu-satunya saksi:

/var/log/auth.log
journalctl -k --since "-2 hours"
fail2ban-client status sshd

8. Menguji Ketahanan Tanpa Merusak Layanan

Jangan pernah melakukan stress test ke produksi. Uji di staging dengan pola terukur, misalnya wrk:

wrk -t8 -c200 -d60s --latency https://staging.domainanda.id/api/murah
wrk2 -R2000 -D60s -t4 --latency https://staging.domainanda.id/

Yang dinilai bukan hanya status 200, tetapi: kapan nginx mulai menolak dengan 429, apakah error rate naik sebelum CPU penuh, dan apa yang terjadi pada antrian database. Sertakan hasilnya sebagai catatan kapasitas bersama panduan pemilihan spesifikasi di Cara Memilih Spesifikasi VPS.

9. Preventif: Kontrak, Bukan Hanya Teknik

DDoS kadang bermotif pemerasan. Beberapa hal non-teknis yang menentukan cepat lambatnya pemulihan:

  • SLA uptime dan penjelasan mitigasi provider di kontrak Anda.
  • Nomor kontak support 24 jam yang sudah dites sebelumnya.
  • Backup terkini di lokasi lain, karena serangan besar sering kamuflase untuk mengalihkan perhatian dari percobaan intrusi — lihat Backup VPS Otomatis.
  • Prosedur komunikasi pelanggan, sehingga status halaman dan notifikasi siap dikirim tanpa panik.

Kesimpulan

DDoS tidak bisa "dipasang lalu lupa". Kombinasi yang bekerja untuk pemilik VPS: bandwidth yang cukup tapi realistis, sysctl dan limit nginx yang teruji, CDN di depan origin, firewall yang menutup akses langsung, serta runbook yang ditulis saat santai. Sisanya adalah mengenali anomali lebih cepat daripada penyerang menghabiskan kuota Anda. Perlu disadari juga bahwa mitigasi adalah pembagian peran: provider menjaga kapasitas upstream, Anda menjaga aplikasi — rinciannya di Model Tanggung Jawab Bersama Keamanan VPS.

Artikel terkait: Memahami Bandwidth Unmetered VPS | 10 Langkah Hardening VPS

Iklan

DDoS Security Mitigasi VPS Keamanan CDN Network nginx