Menjaga VPS tetap online saat diserang DDoS

“DDoS” menggambarkan sebuah niat, bukan sebuah mekanisme, dan mekanisme-mekanismenya nyaris tidak punya kesamaan sama sekali. Memilah-milahnya dengan benar bukan soal kepedantikan: itulah keseluruhan pekerjaannya, karena masing-masing hanya bisa dihentikan di tepat satu layer dan tidak terlihat sama sekali di layer lainnya.

Flood volumetrik menyasar bandwidth Anda. Amplifikasi UDP — DNS, NTP, memcached, dan belakangan ini apa pun yang menjawab pertanyaan kecil dengan jawaban besar — memungkinkan attacker mengubah 1 Gbps kapasitas mereka menjadi 50 Gbps yang diarahkan ke Anda. Targetnya adalah link, bukan server. CPU Anda akan bosan sepanjang waktu.

Serangan protokol dan state menyasar sebuah tabel terbatas di kernel Anda. SYN flood mencoba menghabiskan accept queue; flood paket-kecil generik mencoba menghabiskan connection tracking. Keduanya diukur dalam paket per detik, bukan bit per detik, dan keduanya bisa membunuh sebuah mesin pada link yang 97% menganggur. Inilah kelas serangan yang menjatuhkan server-server kecil, dan kelas yang paling sering dilewatkan oleh kebanyakan panduan.

Flood layer aplikasi menyasar CPU atau database Anda, memakai request yang tidak bisa dibedakan dari request asli karena request itu memang asli. Seratus request per detik ke sebuah endpoint pencarian bukan apa-apa bagi sebuah jaringan, tapi fatal bagi sebuah aplikasi PHP. Tidak ada scrubber upstream yang bisa menyaring ini untuk Anda: dari luar, semuanya terlihat persis seperti keberhasilan.

Ada hal keempat yang datang menyamar sebagai ketiganya, padahal sama sekali bukan serangan: sebuah link yang kebetulan sedang ramai di suatu tempat, klien Anda sendiri yang berulah, atau crawler yang tidak tahu sopan santun. Menyingkirkan kemungkinan ini lebih dulu tidak berbiaya apa pun, dan cukup memalukan betapa seringnya inilah jawabannya.

Kalau 60 Gbps diarahkan ke alamat Anda dan port Anda adalah port 1 Gbps, keputusan soal paket-paket itu dibuat di sebuah router yang berada di upstream Anda, beberapa hop sebelum apa pun yang Anda kelola. Firewall Anda tidak pernah melihatnya sama sekali. Memang tidak bisa: paket itu sudah dibuang untuk melindungi sebuah link yang bukan milik Anda. Inilah fakta struktural paling penting soal serangan volumetrik, dan alasan mengapa “perkuat firewall Anda melawan DDoS” sebagian besar omong kosong.

Jadi satu-satunya pertanyaan yang berarti adalah apa yang dilakukan provider Anda secara otomatis, dan di mana ambang batas mereka berada. Milik kami dipublikasikan, bukan sekadar dijanjikan: di bawah 10 Gbps diserap tanpa efek yang terlihat, 10–100 Gbps di-scrub di transit provider dan Anda mungkin akan melihat sedikit kenaikan latensi, dan di atas 100 Gbps prefix-nya diumumkan ke jalur scrubbing khusus — latensi naik lebih terasa, tapi layanan tetap bisa dijangkau. Null-route pada sebuah alamat hanya menjadi opsi untuk serangan yang berkelanjutan dan mengancam PoP yang lebih luas, dan kami memberi tahu Anda dalam hitungan menit kalau itu sampai terjadi. Tidak ada yang perlu dibeli, dan tidak ada yang perlu dinyalakan.

Ada dua hal soal scrubbing yang layak diketahui, yang jarang mau diungkap sukarela oleh vendor. Pertama, Anda dilindungi oleh lingkungan sekitar, bukan cuma oleh pertahanan Anda sendiri: serangan terhadap pelanggan lain yang berbagi /20 upstream yang sama dengan Anda sudah diserap sebelum sempat mencapai prefix siapa pun — flood ~340 Gbps yang diarahkan ke sebuah range tetangga di Paris lewat begitu saja tanpa dampak yang terukur pada milik kami, dan itulah persis hasil yang tidak akan disadari siapa pun. Kedua, scrubber hanyalah heuristik, dan heuristik kadang salah: pada jaringan yang sama, sebuah scrubber pernah menghabiskan sembilan menit mengirim TCP reset terhadap koneksi yang sah, sementara sedang menyaring serangan terhadap tetangga. Kedua insiden itu tercatat di log insiden publik. Kalau sesi Anda mati dengan cara yang terlihat seperti reset aktif dan bukan timeout, di tengah serangan yang menyasar orang lain, itu adalah mode kegagalan yang nyata dan lebih layak dilaporkan daripada didebug sendirian selama sejam.

Setiap respons DDoS yang salah selalu dimulai dari sebuah perubahan yang dilakukan sebelum ada yang benar-benar tahu apa yang sedang terjadi. Ambil empat angka dulu. Semuanya muat di satu layar, dan semuanya langsung menunjukkan di layer mana masalahnya berada.

# 1. bits vs packets  — which axis is saturated?
sar -n DEV 1 5            # or: ifstat -i eth0 1

# 2. socket states     — SYN-RECV piling up means a SYN flood
ss -s
ss -tan state syn-recv | wc -l

# 3. kernel drop counters (these are the ones that matter)
nstat -az | grep -E 'ListenDrops|ListenOverflows|SyncookiesSent|TCPReqQFullDrop'
dmesg -T | tail -20       # look for: nf_conntrack: table full, dropping packet

# 4. connection tracking headroom
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Baca semuanya sekaligus. Bit per detik tinggi, paket per detik rendah, CPU rendah berarti serangan volumetrik, dan tugas Anda cuma memastikannya lalu berhenti mengetik apa pun. Paket per detik tinggi, bit per detik rendah — banyak paket kecil-kecil — berarti serangan state; langsung lihat SyncookiesSent dan jumlah conntrack. Traffic yang sedang-sedang saja di kedua sumbu, dengan CPU yang mentok berarti layer 7, dan jawabannya ada di web server dan database Anda, bukan di firewall.

Ada satu pembacaan yang berlawanan dengan intuisi dan layak Anda tanamkan baik-baik: saat flood volumetrik yang sungguhan terjadi, interface Anda justru bisa terlihat nyaris tenang. Yang Anda lihat hanyalah yang selamat — apa yang masih muat lewat link yang sudah penuh, atau apa yang sudah diloloskan oleh scrubber upstream. Interface yang menunjukkan 900 Mbps di port 1 Gbps, sementara pengguna melaporkan situs sama sekali tidak terjangkau, bukanlah bukti bahwa tidak ada serangan. Itu justru bentuknya.

Setelah itu, periksa apakah traffic-nya memang bukan sekadar traffic asli. Jalankan tail -f pada access log Anda selama sepuluh detik: satu path yang diulang oleh ribuan alamat berbeda tanpa referrer sama sekali adalah tanda serangan; sebaran path normal dari browser normal adalah audiens sungguhan, dan me-rate-limit-nya justru akan menyelesaikan pekerjaan attacker untuk mereka.

Setiap port yang terbuka adalah sebuah queue yang bisa dipenuhi oleh attacker, dan setiap paket yang harus dilihat oleh guest Anda membebani Anda dengan CPU dan sebuah entri conntrack, bahkan ketika paket itu Anda buang sekalipun. Paket paling murah adalah paket yang tidak pernah diterima mesin Anda sama sekali, dan itulah yang membuat filtering di atas guest lebih bernilai daripada filtering di dalamnya.

Ada dua layer di sini, dan keduanya bukan hal yang sama. Edge filter sifatnya opsional, dikonfigurasi per server, stateful, dan drop-by-default, dan berjalan di hypervisor — traffic yang Anda tolak di situ tidak akan pernah sampai ke virtual NIC Anda sama sekali, jadi tidak membebani Anda dengan CPU, memori, ataupun entri tabel state. Guest firewall — ruleset nftables Anda — sepenuhnya milik Anda, dan kami tidak pernah menyentuhnya. Pola yang bertahan begitu benar-benar berhadapan dengan serangan adalah menyatakan kebenaran layer-4 yang kasar dan stabil di edge (“mesin ini melayani 80, 443, dan SSH dari alamat-alamat ini, dan tidak ada yang lain”), lalu menyimpan ruleset guest untuk pekerjaan yang lebih rinci dan berubah-ubah mengikuti aplikasi Anda. Keduanya dijelaskan di dokumentasi firewall.

Setelah itu, persempit apa yang tersisa. SSH yang dibatasi hanya untuk alamat-alamat yang benar-benar Anda pakai untuk administrasi bukan sekadar pemanis hardening di sini — ini menyingkirkan satu kelas penuh serangan connection-exhaustion dari mesin Anda. Database yang di-bind ke 127.0.0.1 atau ke alamat WireGuard sama sekali tidak bisa di-flood dari internet. Dan kalau Anda menjalankan control plane yang sifatnya murni internal, taruh itu di balik sebuah interface WireGuard, bukan di balik port publik dengan password.

SYN flood mengeksploitasi handshake: attacker mengirim aliran connection request dan tidak pernah menyelesaikannya, dan masing-masing menempati satu slot di SYN queue kernel sampai akhirnya timeout. Penuhi queue itu, dan handshake yang sah pun ikut dibuang — service Anda tetap up, tetap listening, tapi tidak bisa dijangkau.

Linux sudah punya jawaban yang bersih sejak era sembilan puluhan, dan itu aktif secara default. SYN cookies membuat kernel berhenti mengalokasikan memori untuk koneksi half-open sama sekali: ia meng-encode state koneksi ke dalam sequence number yang dikirimkan kembali, lalu merekonstruksinya kalau klien menyelesaikan handshake-nya. Pastikan hal ini, jangan cuma diasumsikan, dan beri queue-nya cukup ruang untuk bertahan dari satu lonjakan singkat:

# /etc/sysctl.d/99-flood.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_abort_on_overflow = 0

sysctl --system

tcp_synack_retries = 2 lebih penting daripada yang terlihat: nilai default lima berarti sebuah handshake palsu menempati kernel selama kurang lebih tiga menit, sementara nilai dua menurunkannya jadi sekitar tujuh detik saja. Menaikkan somaxconn cuma separuh dari pekerjaannya — kedalaman queue-nya adalah nilai minimum antara angka itu dan apa yang diminta oleh aplikasi, jadi nginx butuh listen 443 ssl backlog=8192; dan sebuah reload sebelum pengaturan kernel itu berarti apa-apa. Inilah contoh klasik sebuah sysctl yang terlihat sudah diterapkan padahal sama sekali tidak berpengaruh.

Kalau Anda ingin menghentikan flood-nya sebelum sempat mencapai aplikasi sama sekali, nftables bisa menyelesaikan handshake atas nama kernel dan hanya menyerahkan koneksi yang ternyata benar-benar asli:

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 80, 443 } ct state new synproxy mss 1460 wscale 7 timestamp sack-perm
    tcp dport { 80, 443 } accept
    ip protocol icmp icmp type echo-request limit rate 5/second accept
  }
}

Uji synproxy dulu di mesin yang masih bisa Anda jangkau lewat console sebelum Anda benar-benar mengandalkannya; kalau salah konfigurasi, ini adalah cara yang ampuh untuk mem-firewall diri Anda sendiri keluar dari server Anda sendiri. Bagi kebanyakan orang, blok sysctl di atas sudah cukup, dan urutan prioritas yang jujur adalah: syncookies dulu, backlog kedua, synproxy hanya kalau Anda sudah mengukur sendiri bahwa dua yang pertama belum cukup.

Inilah yang sering menjebak orang-orang berpengalaman. Firewall stateful harus mengingat setiap flow yang pernah dilihatnya, dan ingatan itu adalah nf_conntrack, sebuah tabel hash dengan ukuran tetap yang dipilih saat boot. Begitu penuh, kernel akan membuang koneksi baru — semuanya, milik attacker maupun milik pelanggan sama saja — dan mencatat satu baris ke dmesg yang tidak dilirik siapa pun:

nf_conntrack: table full, dropping packet

Alasan kenapa ini begitu efektif adalah soal aritmatika belaka. Tabel default pada VPS kecil menampung sekitar puluhan ribu entri saja, dan setiap paket dari alamat sumber baru menciptakan satu entri — termasuk paket UDP, termasuk paket yang Anda buang, termasuk flood itu sendiri. Dua puluh ribu paket per detik dari sumber yang dipalsukan (spoofed) sudah cukup memenuhinya dalam waktu kurang dari dua detik, pada link yang cuma membawa beberapa megabit. Grafik bandwidth Anda sama sekali tidak akan menunjukkan apa-apa.

# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_udp_timeout = 20

Timeout justru berjasa lebih besar daripada ukurannya. Masa hidup default untuk sebuah flow TCP established adalah lima hari, artinya server yang sudah up selama seminggu masih menyimpan state untuk koneksi yang sebenarnya sudah berakhir sejak hari Selasa; satu jam sudah lebih dari cukup untuk apa pun yang bukan sesi SSH yang sedang idle, dan net.ipv4.tcp_keepalive_time = 600 menjaga sesi itu tetap hidup secara semestinya, bukan cuma karena kebetulan. Perkirakan sekitar 300 byte memori kernel per entri saat menghitung ukurannya: 262.144 entri berarti sekitar 80 MB, yang masih wajar di mesin 4 GB, tapi tidak wajar kalau Anda mengaturnya jadi sepuluh juta cuma karena kata sebuah forum begitu.

Kalau Anda menjalankan sesuatu yang sifatnya benar-benar stateless dan volume tinggi — DNS server otoritatif, game server publik, relay Tor — jawaban yang lebih baik adalah berhenti melacaknya sama sekali. Connection tracking untuk sebuah service yang tidak punya koneksi yang benar-benar berarti hanyalah biaya murni:

table ip raw {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    udp dport 51820 notrack
    tcp dport 9001 notrack
  }
}

Ingat bahwa traffic semacam itu jadi melewati begitu saja rule ct state established Anda, sehingga ia butuh rule accept eksplisit di filter chain. Itulah pertukarannya: Anda melepas statefulness untuk port itu, dan sebagai gantinya Anda dapat tabel yang tidak mungkin penuh.

Serangan paling efisien terhadap server kecil sama sekali bukan sebuah flood. Serangan itu adalah beberapa ratus HTTP request per detik yang dipilih dengan cermat, masing-masing sepenuhnya valid, masing-masing menghantam satu-satunya endpoint yang menjalankan query tanpa index atau merender halaman yang tidak ter-cache. Ekonominya kejam: request itu cuma berbiaya beberapa ratus byte bagi attacker, tapi berbiaya 200 milidetik CPU dan satu koneksi database bagi Anda. Anda kalah dalam perlombaan itu pada volume berapa pun yang masih sanggup Anda layani.

Naluri pertama adalah memblokir attacker-nya. Melawan sebuah botnet yang tersebar di ribuan alamat residensial, masing-masing hanya mengirim dua request per detik, memblokir berdasarkan IP hanyalah teater — tidak ada rate limit per-alamat yang tetap mengizinkan pengguna asli Anda lolos yang akan pernah terpicu olehnya, dan Anda akan menghabiskan waktu pemadaman itu untuk terus menambah rule sementara situsnya tetap down. Langkah yang menang adalah mengubah biayanya, bukan jumlahnya.

Cache dulu, dan cache juga yang miss. Sebuah full-page cache mengubah request yang mahal menjadi sekadar pembacaan memori, dan directive yang paling penting saat serangan adalah yang menghentikan seribu miss yang terjadi bersamaan agar tidak berubah menjadi seribu query database yang terjadi bersamaan pula:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app:64m max_size=2g inactive=60m;

server {
  location / {
    proxy_cache app;
    proxy_cache_valid 200 301 302 10m;
    proxy_cache_lock on;              # one origin request per key, not a thousand
    proxy_cache_lock_timeout 5s;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on; # serve stale, refresh behind it
    add_header X-Cache $upstream_cache_status always;
    proxy_pass http://127.0.0.1:8080;
  }
}

proxy_cache_lock dan use_stale adalah dua baris yang menentukan apakah sebuah lonjakan traffic bisa selamat dilalui atau tidak. Tanpa keduanya, begitu satu hot key kedaluwarsa, setiap request yang sedang berjalan langsung berubah jadi request ke origin — stampede yang mengubah serangan yang sebenarnya masih bisa dikendalikan menjadi pemadaman total. Dengan keduanya, backend Anda hanya melayani satu request per key per interval, dan semua yang lain mendapat halaman yang sedikit basi, dan itulah pertukaran yang benar untuk setiap situasi di mana alternatifnya adalah tidak ada halaman sama sekali.

Lalu, rate-limit khusus path-path yang mahal, dengan longgar, dan dengan cara yang gagalnya terlihat jelas:

limit_req_zone $binary_remote_addr zone=general:16m rate=20r/s;
limit_req_zone $binary_remote_addr zone=costly:16m  rate=2r/s;
limit_conn_zone $binary_remote_addr zone=conn:16m;
limit_req_status 429;
limit_conn_status 429;

server {
  limit_req  zone=general burst=40 nodelay;
  limit_conn conn 24;

  location /search { limit_req zone=costly burst=5 nodelay; proxy_pass http://127.0.0.1:8080; }
  location /login  { limit_req zone=costly burst=3 nodelay; proxy_pass http://127.0.0.1:8080; }
}

burst tanpa nodelay akan mengantrekan kelebihan request, bukan menolaknya, yang saat serangan artinya nginx dengan sopan menahan ribuan koneksi tetap terbuka atas nama Anda — Anda baru saja mengubah request flood menjadi connection flood. Pakai nodelay, kembalikan 429 seketika, dan biarkan klien yang mengurus sendiri akibatnya. Dan di balik proxy apa pun, ingat bahwa $binary_remote_addr adalah alamat proxy itu sendiri, kecuali Anda sudah mengonfigurasi set_real_ip_from dan real_ip_header dengan benar; sebuah rate limit yang kuncinya adalah alamat front-end Anda sendiri akan mengunci semua pengguna sekaligus pada kali pertama ia terpicu.

Serangan bergaya Slowloris — banyak koneksi, masing-masing meneteskan satu request satu byte demi satu byte — nyaris tidak mengganggu event model nginx, tapi timeout-nya tetap layak diperketat: client_header_timeout 8s; client_body_timeout 8s; send_timeout 10s; reset_timedout_connection on;. Digabung dengan limit_conn, itulah keseluruhan pertahanannya.

fail2ban sungguh-sungguh berguna, tapi ia menyasar masalah yang berbeda. Ia membaca file log, memutuskan setelah N kegagalan dalam M menit, lalu menyisipkan sebuah rule firewall. Setiap bagian dari proses itu adalah bentuk yang salah untuk menghadapi flood.

Terlalu lambat: sebuah burst yang berlangsung empat puluh detik sudah selesai sebelum jendela ban-nya sempat menutup. Ia membaca log, jadi serangan itu sudah membebani Anda dengan harga penuh dari setiap request-nya — parsing-nya baru terjadi setelah kerusakannya terjadi. Ia mem-ban alamat satu per satu, jadi melawan sepuluh ribu sumber, ia akan tidak berbuat apa-apa atau malah menyisipkan sepuluh ribu rule linear, dan pada titik itu firewall itu sendiri yang jadi bottleneck, dan Anda baru saja menyelesaikan serangan itu atas nama attacker Anda sendiri. Dan ia digerakkan oleh log Anda, jadi sebuah flood yang cukup besar untuk memenuhi disk dengan baris-baris log bisa saja menjatuhkan server lewat jalur yang tidak pernah Anda pikirkan sama sekali.

Kalau Anda menginginkan blocking yang dinamis, lakukan itu di data plane, tempat lookup-nya adalah sebuah hash dan kedaluwarsanya otomatis. Sebuah dynamic set nftables bersifat O(1) berapa pun ukurannya, dan melupakan sendiri entrinya:

table inet filter {
  set flooders {
    type ipv4_addr
    flags dynamic, timeout
    timeout 10m
    size 65535
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr @flooders drop
    tcp dport { 80, 443 } ct state new add @flooders { ip saddr limit rate over 50/second burst 100 packets } drop
    tcp dport { 80, 443 } accept
  }
}

Baca rule-nya baik-baik, karena negasinya sering menjebak orang: alamatnya ditambahkan ke set dan dibuang hanya ketika rate-nya melebihi batas. Simpan fail2ban untuk hal yang memang jadi keahliannya — menebak kredensial secara lambat terhadap SSH dan login aplikasi, di mana ban dengan skala waktu manusia terhadap satu alamat spesifik justru sudah sangat tepat.

Setiap serangan volumetrik besar ditenagai oleh server-server yang operatornya sendiri tidak tahu kalau mereka sedang ikut ambil bagian. Mekanismenya adalah sebuah service UDP yang menjawab request kecil yang dipalsukan dengan balasan yang besar: sebuah open DNS resolver mengembalikan 50 kali lipat dari apa yang diminta, NTP dan memcached yang salah konfigurasi malah lebih parah lagi, dan protokol apa pun yang merespons sebelum sempat memverifikasi siapa yang bertanya adalah kandidat berikutnya.

Konsekuensinya menimpa Anda lebih dulu, sebelum menimpa korbannya. Uplink Anda dipenuhi oleh balasan outbound Anda sendiri, provider Anda melihat traffic yang bersifat abusive dan berkelanjutan keluar dari port Anda, dan para transit supplier yang menerimanya mulai me-null-route range asal traffic itu — itulah sebabnya kebijakan acceptable-use menarik garis tegas pada originasi serangan dan amplifikasi, sembari mengizinkan hampir semua hal lainnya. Menjadi reflector tanpa sadar adalah cara tercepat untuk kehilangan sebuah alamat yang sebenarnya tidak ada hubungannya sama sekali dengan apa pun yang ingin Anda jalankan.

# bind a recursive resolver to localhost, never 0.0.0.0
# unbound: interface: 127.0.0.1  +  access-control: 0.0.0.0/0 refuse

# what is actually listening on a public address?
ss -ulpn
ss -tlpn

# from another machine, confirm you do not answer strangers
dig @your.server.ip example.com +short          # must time out
ntpq -c rv your.server.ip                        # must fail

Kalau Anda memang sengaja menjalankan sebuah service UDP publik — game server, nameserver otoritatif, endpoint WireGuard — aturannya sama seperti di tempat lain: rate-limit response-nya, jangan pernah request-nya. bind maupun knot sama-sama mengimplementasikan response rate limiting; pakai itu, karena itulah bedanya antara melayani pengguna Anda dan mengirimkan serangan milik orang lain.

Semua yang di atas adalah damage control untuk serangan yang sudah menemukan alamat Anda. Itu tetap layak dilakukan, tapi itu cuma pilihan terbaik kedua. Sebuah origin yang namanya tidak diketahui siapa pun sama sekali tidak bisa diserang di layer 3 maupun 4, dan memisahkan alamat yang melayani traffic dari alamat yang diketahui dunia luar adalah hal dengan leverage paling tinggi di seluruh halaman ini.

Alamat origin nyaris tidak pernah bocor lewat serangan yang canggih. Alamat itu bocor lewat sejarah dan lewat kecerobohan, lewat daftar yang pendek dan sudah dikenal luas. Record DNS lama adalah biang keladi yang biasa: arsip passive-DNS mengingat A record yang dulu Anda pakai sebelum Anda memasang front-end, untuk selamanya. Log certificate transparency bersifat publik dan permanen, jadi sebuah sertifikat yang diterbitkan untuk hostname yang dulu langsung mengarah ke origin adalah catatan bertanda tangan dan berstempel waktu, tentang di mana Anda dulu “tinggal”. Email keluar membubuhkan alamat server pengirim ke header setiap pesan. Dan yang paling diam-diam: web server Anda sendiri yang menjawab di IP telanjangnya, yang membuat siapa pun yang menyisir ruang alamat untuk mencari HTML situs Anda bisa menemukan Anda lewat kontennya sendiri hanya dalam satu sore.

Yang terakhir itu perbaikannya cuma dua baris, dan nyaris tidak ada yang melakukannya. Buat server default menolak segala sesuatu yang datang tanpa hostname yang Anda layani:

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  ssl_reject_handshake on;      # nginx 1.19.4+: no certificate, no fingerprint
  return 444;                   # close without a response
}

Setelah itu, pilih sebuah front. CDN komersial adalah jawaban yang paling jelas dan datang dengan biaya nyata yang penting di sini: Anda menambahkan sebuah perusahaan yang meng-terminate TLS Anda, melihat plaintext Anda, tahu origin Anda, dan bisa disodori proses hukum di sebuah yurisdiksi yang bukan pilihan Anda sendiri — yang membatalkan sebagian besar alasan kenapa server itu dulu dibayar pakai kripto tanpa nama yang menempel padanya. Kalau Anda tetap melakukannya, pahami bahwa origin-nya tidak boleh pernah publik sama sekali, dan bahwa seluruh susunan ini gagal total begitu ada orang yang menemukan satu record lama saja.

Alternatif yang tetap mempertahankan properti yang sudah Anda bayar adalah menjadi front Anda sendiri. Sebuah instance $5 di region kedua yang menjalankan nginx sebagai reverse proxy, dengan edge filter origin-nya hanya menerima traffic dari satu alamat itu saja dan tidak ada yang lain, memberi Anda sebuah alamat pengorbanan yang bisa Anda renumber dalam lima menit, dan sebuah control plane yang hanya menjawab kepada Anda. Ini arsitektur yang sama persis, minus pihak ketiganya. Dan di tempat audiensnya bisa memakainya, sebuah onion service Tor menghilangkan IP dari persamaannya sama sekali — tidak ada alamat yang bisa di-flood, meskipun onion service punya attack surface-nya sendiri di introduction point, dan itulah sebabnya Tor versi modern sudah membawa pertahanan proof-of-work justru untuk hal ini.

Cepat atau lambat, akan ada yang mengusulkan untuk memblokir sebuah negara. Cara ini kasar, kadang-kadang benar, dan sebagian besar cuma cara untuk merasa sudah berbuat sesuatu.

Ini masuk akal kalau layanan Anda memang punya audiens yang benar-benar terbatas — game server regional, tool internal, sebuah control panel — dan Anda siap menanggung false positive-nya, termasuk pengguna Anda sendiri yang sedang bepergian dan siapa pun yang routing-nya kebetulan aneh. Ini nyaris tidak berguna melawan botnet modern, yang tersebar di koneksi residensial di hampir setiap negara, termasuk negara Anda sendiri, dan ini justru merugikan secara aktif untuk apa pun yang sifatnya publik: Anda akan diam-diam kehilangan orang-orang sungguhan dan tidak akan pernah tahu siapa saja yang pergi karenanya.

Memblokir berdasarkan ASN lebih tajam. Traffic serangan yang berasal dari segelintir hosting provider — range VPS murah yang disewa per jam — bisa dibuang berdasarkan prefix dengan korban jauh lebih sedikit dibanding blokir negara, karena pengguna biasa tidak browsing dari sebuah datacenter. Range datacenter juga, kebetulan, adalah asal dari scraping dan credential stuffing.

Tapi versi dari ide ini yang benar-benar tahan lama sama sekali bukan soal geografi: melainkan menyaring berdasarkan bentuk traffic-nya, bukan asalnya. Sebuah serangan biasanya berbagi sesuatu yang sifatnya struktural — user agent yang sama, header yang sama-sama hilang, URL yang sama dengan query parameter yang sama, TLS fingerprint yang sama, atau ketiadaan total dari request kedua yang selalu dilakukan oleh browser sungguhan. Temukan properti yang dibagi bersama itu, dan Anda bisa menulis satu rule yang tidak berbiaya apa pun dan tetap bertahan bahkan ketika attacker berganti-ganti alamat, yang akan mereka lakukan lebih cepat daripada yang bisa Anda daftar satu per satu.

# in an attack: what do these requests have in common?
awk '{print $1}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # addresses
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # user agents
awk '{print $7}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # paths

Kalau satu user agent saja menyumbang 90% dari semua request, Anda cuma butuh sembilan puluh detik untuk memperbaikinya. Kalau dua puluh alamat teratas masing-masing cuma menyumbang 2% dari traffic, berhentilah mencari-cari alamat — itu adalah serangan yang terdistribusi, dan jawabannya adalah caching dan rate limit.

Kadang-kadang serangannya bersifat tertarget, terus-menerus, dan diarahkan ke Anda secara pribadi, bukan ke alamat acak, dan respons yang benar adalah berhenti mempertahankan alamat itu dan meninggalkannya begitu saja. Ini bukan kekalahan; untuk layanan kecil, ini justru sering jadi hasil akhir yang paling murah, dan hanya akan terasa menyakitkan kalau Anda belum pernah melatihnya.

Yang membuatnya cepat sudah diputuskan jauh-jauh hari sebelumnya. Jaga DNS TTL tetap di 300 detik sebagai sikap baku Anda — biayanya nyaris tidak ada, dan manfaatnya adalah Anda bisa pindah dalam lima menit, bukan dalam sehari penuh. Jaga deployment Anda tetap reproducible, karena server yang bisa Anda bangun ulang adalah server yang bisa Anda pindahkan; kalau membangun ulang berarti harus mengingat-ingat apa yang Anda lakukan bulan Maret lalu, Anda bukan punya rencana, Anda punya sandera. Simpan backup yang bisa di-restore di region yang berbeda, dan ketahui dari drill sungguhan berapa lama waktu yang dibutuhkan sebuah restore.

Setelah itu, langkah sesungguhnya justru singkat: deploy di region lain, restore, verifikasi di alamat baru lewat hostname override sebelum Anda menyentuh DNS, ganti record-nya, dan biarkan server lama tetap berjalan cukup lama sampai resolver-resolver terakhir ikut menyusul. Panduan migrasi membahas urutannya secara mendetail, dan urutannya sama persis, entah Anda pindah demi performa atau pindah karena ada yang sedang marah.

Model billing-nya membuat latihan ini nyaris gratis: biaya dihitung prorata harian terhadap saldo Anda, jadi mesin kedua yang Anda deploy, uji, lalu hancurkan dalam satu sore saja cuma berbiaya beberapa sen, dan tidak ada kontrak, tidak ada kartu, dan tidak ada perpanjangan yang perlu dibatalkan. Tidak ada alasan bagi renumbering pertama Anda untuk terjadi justru saat sedang diserang.

Dua catatan penutup yang jujur, karena sisa halaman ini memang optimistis sejak dirancang.

Pertama, tidak ada host yang bisa menyerap segalanya, dan provider mana pun yang mengklaim sebaliknya sedang berjualan. Kapasitas itu terbatas, kapasitas scrubbing lebih terbatas lagi, dan pada skala yang cukup besar, tindakan yang secara ekonomi rasional bagi sebuah jaringan yang melindungi ribuan pelanggan adalah berhenti mengumumkan satu alamat. Kami memperlakukan itu sebagai upaya terakhir, hanya untuk serangan berkelanjutan yang mengancam PoP yang lebih luas, dan kami akan memberi tahu Anda, bukan membiarkan Anda mencari tahu sendiri lewat debugging — tapi janji bahwa itu tidak akan pernah terjadi sama sekali akan jadi kebohongan, dan Anda sebaiknya curiga pada host mana pun yang mengucapkan janji semacam itu.

Kedua, balas dendam bukanlah pilihan yang tersedia di sini. Layanan booter dan stresser adalah serangan-untuk-disewa yang menyamar sebagai tool pengujian, ilegal di hampir semua yurisdiksi yang relevan, dipantau secara ekstensif, dan akan membuat server Anda diterminasi di sini, di bawah kebijakan yang sebenarnya mengizinkan hampir segalanya. Asimetri yang membuat DDoS menarik bagi attacker adalah persis yang membuatnya tidak berguna bagi pihak yang bertahan: Anda tidak bisa mengalahkan flood dari seseorang yang tidak punya apa-apa untuk dirugikan. Serap, cache, pindah, dan biarkan semuanya jadi membosankan — yang, bagi siapa pun yang harus membayar traffic yang mereka kirim, cepat atau lambat memang akan terjadi.