Bertahan dari Serangan DDoS di VPS Anda

Ada dua momen ketika orang benar-benar memahami cara kerja mitigasi DDoS. Yang pertama terjadi dengan tenang, saat membeli, membaca daftar fitur yang bertuliskan "perlindungan DDoS termasuk" dan diam-diam beranggapan kalimat itu mencakup segalanya. Yang kedua terjadi pukul tiga pagi, ketika situsnya down, grafiknya terlihat salah dengan cara yang tidak masuk akal, dan perlindungan yang sudah termasuk itu — secara tepat, dan memang sesuai desainnya — sama sekali tidak melakukan apa-apa.

Kedua momen itu melibatkan produk yang sama dan kebenaran yang sama: sebuah hosting provider menyaring serangan yang datang sebagai volume mentah, karena merekalah yang memiliki pipa tempat paket-paket itu mengalir, bukan Anda. Ia tidak bisa menyaring serangan yang datang sebagai permintaan yang tampak biasa saja, karena dari sudut pandang network, itu memang permintaan yang tampak biasa saja. Garis itu — antara banjir yang diserap host Anda dan banjir yang harus Anda selamatkan sendiri — adalah keseluruhan inti pembahasan ini. Semua yang ada di bawah ini adalah soal mencari tahu di sisi mana Anda berada, dan apa yang harus dilakukan pada masing-masing sisi.

Dua serangan berbeda yang berbagi satu nama

"DDoS" adalah satu kata yang mencakup dua masalah yang nyaris tidak punya kesamaan apa pun kecuali akibatnya. Keduanya dihentikan di tempat yang berbeda, oleh pihak yang berbeda, dengan alat yang berbeda, dan kerancuan antara keduanya adalah alasan mengapa begitu banyak upaya mitigasi salah sasaran ke lapisan yang keliru.

Baca lagi dua baris terakhir itu, karena di situlah letak poin praktisnya. Jika interface-nya jenuh, apa pun yang Anda ketikkan di server tidak akan membantu: paket-paketnya sudah menghabiskan port itu, dan satu-satunya pihak yang bisa menjatuhkannya adalah pemilik router di upstream. Jika interface-nya tenang tapi situsnya tetap down, yang terjadi justru sebaliknya — host Anda tidak melihat ada yang salah karena, di lapisan mereka, memang tidak ada yang salah, dan perbaikannya sepenuhnya menjadi tanggung jawab Anda.

Apa yang sebenarnya Anda dapatkan dari "perlindungan DDoS termasuk"

Perlindungan di network layer itu nyata, berharga, dan hampir selalu disalahpahami. Ketika sebuah provider mengiklankan filtering L3/L4, maksudnya adalah network mereka memantau lalu lintas yang menuju alamat Anda, dan ketika sebuah banjir terdeteksi, lalu lintas itu dialihkan lewat scrubbing hardware yang menjatuhkan bagian yang berbahaya dan meneruskan yang tampak sah. Ini terjadi tanpa perlu tiket dukungan dan biasanya tanpa Anda menyadari lebih dari sekadar gangguan sekilas.

Satu kalimat itu menanggung banyak makna, jadi ada baiknya diurai apa yang tercakup dan apa yang tidak:

• Ia mencakup serangan yang tidak bisa Anda hadapi sendirian. Banjir amplifikasi 200 Gbps ke server dengan port 1 Gbps bukan soal konfigurasi. Itu soal aritmatika. Scrubbing di upstream adalah satu-satunya jawaban yang ada.
• Ia tidak mengenal keadaan aplikasi Anda. Filter itu tidak tahu URL mana yang mahal, pengunjung mana yang sedang login, atau bahwa satu permintaan ke endpoint pencarian Anda berbiaya empat ratus kali lipat dibanding satu permintaan ke logo Anda.
• Ia bereaksi terhadap ambang batas, bukan terhadap penderitaan Anda. Deteksi terpicu oleh volume lalu lintas. Serangan yang tidak pernah melewati ambang batas itu tidak akan pernah memicunya, tidak peduli seberapa total ia sudah melumpuhkan situs Anda.
• Ia bisa saja sesaat melakukan null-route dalam kasus ekstrem. Setiap network punya batas atasnya sendiri. Jika sebuah serangan mengancam infrastruktur bersama, alamat itu bisa saja dijatuhkan untuk sementara waktu — ini adalah praktik standar, berlaku di mana saja, dan lebih baik diketahui sebelum terjadi daripada saat sedang terjadi.

Pertama, pastikan dulu apakah ini benar-benar serangan

Sebagian besar insiden yang dicurigai sebagai DDoS sebenarnya adalah hal lain yang mengenakan mantel yang sama, dan cara mengatasinya tidak bisa saling dipertukarkan. Sebelum menerapkan rate limit pada apa pun, luangkan dua menit untuk menyingkirkan kemungkinan-kemungkinan palsu itu — salah diagnosis di sini bisa menghabiskan satu jam Anda, dan sesekali, pengguna sungguhan Anda.

• Anda jadi populer. Sebuah tautan di agregator besar menghasilkan bentuk lalu lintas yang persis seperti banjir L7, hanya saja referrer-nya sungguhan dan permintaannya menuju halaman yang memang diinginkan manusia. Ini adalah masalah kapasitas dengan penyebab yang menyenangkan; menerapkan rate limit padanya sama saja menyakiti diri sendiri.
• Sebuah crawler kehilangan sopan santunnya. Scraper yang agresif dan bot pelatihan AI bisa dengan mudah melampaui kemampuan server kecil. User-agent-nya biasanya mengaku sendiri, dan perbaikannya adalah robots.txt ditambah limit yang ditargetkan, bukan limit umum.
• Anda merusak sesuatu. Sebuah deployment yang menonaktifkan caching, cron job yang lepas kendali, database yang kehilangan index — semuanya tampil sebagai "load tiba-tiba, tanpa sebab yang jelas". Jika waktunya bertepatan dengan perubahan yang Anda buat, percayalah pada perubahan itu.
• Monitoring Anda sendiri adalah banjirnya. Jarang terjadi, memalukan, dan jauh lebih umum daripada yang mau diakui siapa pun. Sebuah loop health-check yang mencoba ulang tanpa backoff bisa menghasilkan laju permintaan yang benar-benar mengesankan.

Pertanyaan pembedanya sederhana: apakah lalu lintas ini menginginkan sesuatu? Load yang sungguhan — bahkan yang tampak bermusuhan sekalipun — punya bentuk. Ia menuju halaman yang memang ada, mengikuti tautan, memuat aset, dan datang dari sebaran network yang masuk akal. Serangan biasanya tidak repot-repot melakukan itu.

Membaca serangan langsung dari server

Anda tidak perlu dashboard untuk mengklasifikasikan apa yang sedang terjadi. Empat perintah, dijalankan berurutan, akan memberi tahu Anda sedang melawan di lapisan mana dalam kurang dari satu menit — dan mengetahui itu menentukan segala yang Anda lakukan setelahnya.

Apakah pipanya penuh? Perhatikan penghitung interface. Jika throughput tertahan mendekati batas atas port, Anda sedang menghadapi serangan volumetrik dan tugas Anda adalah membuka tiket dukungan, bukan mengubah konfigurasi:

• vnstat -tr 10 — throughput rata-rata selama sepuluh detik, pembacaan tercepat dan paling jujur soal kejenuhan.
• cat /proc/net/dev dua kali, berjarak satu detik — delta paket dan byte per interface, tanpa perlu tooling tambahan.

Apakah ini SYN flood? Koneksi half-open menumpuk di status SYN-RECV. Segelintir itu wajar; ribuan itu tidak:

• ss -s — baris ringkasan, jumlah koneksi per status sekilas pandang.
• ss -tn state syn-recv | wc -l — angka spesifik yang benar-benar penting.

Apakah ini layer 7? Jika bandwidth-nya biasa saja tapi semuanya lambat, hitung permintaan per klien di access log Anda. Satu alamat dengan puluhan ribu hit adalah amatir; seratus ribu alamat dengan masing-masing tiga hit adalah serangan sungguhan:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Ganti $1 dengan $7 untuk mengurutkan path yang diminta sebagai gantinya. Jika satu endpoint yang mahal mendominasi, Anda sudah menemukan targetnya sekaligus separuh dari solusinya.

Apa yang sebenarnya habis? Load average sendirian tidak banyak bercerita. Carilah batas atas spesifik yang sudah Anda tabrak: proses child PHP-FPM semuanya sibuk, koneksi database sudah di batasnya, file descriptor habis, atau worker yang tersangkut di status D menunggu disk. Batas atas itu — bukan lalu lintasnya — yang melumpuhkan situs Anda, dan menaikkannya sering kali lebih cepat daripada memfilter apa pun.

Sepuluh menit pertama

Di bawah tekanan, orang cenderung meraih tuas terbesar yang tersedia, dan tuas terbesar biasanya keliru. Inilah urutan yang membatasi kerusakan, kurang lebih dari yang tercepat-dan-teraman lebih dulu:

1. Klasifikasikan dulu sebelum bertindak. Interface yang jenuh berarti volumetrik; interface yang tenang dengan worker yang sibuk berarti layer 7. Tiga puluh detik yang dihabiskan di sini menyelamatkan Anda dari memperbaiki lapisan yang keliru selama satu jam penuh.
2. Jika ini volumetrik, segera buka tiket dan sertakan alamat tujuan, waktu mulainya, dan penghitung interface Anda. Setelah itu berhenti mengetik apa pun ke server — Anda tidak bisa memperbaiki ini dari dalamnya.
3. Jika ini layer 7, lakukan caching dulu. Menyalakan full-page caching yang agresif untuk pengunjung anonim adalah cara tercepat untuk mengubah outage menjadi sekadar gangguan kecil, dan ini satu-satunya langkah yang juga membantu terhadap lalu lintas sungguhan.
4. Baru kemudian terapkan rate limit — endpoint yang menjadi target lebih dulu, sisanya kemudian. Mulai dengan konservatif. Limit yang justru menjatuhkan pengguna Anda sendiri adalah kelanjutan serangan yang Anda timbulkan sendiri.
5. Blokir hanya yang benar-benar jelas. Selusin alamat dengan masing-masing seratus ribu permintaan, user-agent yang jelas-jelas palsu, satu negara yang tidak punya pengguna Anda. Tahan godaan untuk menulis aturan yang rumit saat sedang diserang; Anda tidak akan mengingatnya bulan depan.
6. Buang load secara sengaja jika memang perlu. Menyajikan halaman statis "sedang dalam perawatan" kepada pengunjung yang belum terautentikasi menjaga server tetap hidup, menjaga API Anda tetap jalan, dan membeli waktu untuk berpikir. Memutuskan sendiri apa yang dikorbankan lebih baik daripada dibiarkan diputuskan begitu saja.
7. Catat apa yang sudah Anda lakukan. Setiap aturan sementara yang Anda tambahkan adalah ranjau bagi diri Anda di masa depan. Aturan yang terbukti membantu jadikan permanen; sisanya cabut besok.

Rate limit yang benar-benar efektif, dan kesalahan yang dilakukan semua orang

Rate limiting adalah instrumen utama untuk layer 7, dan nginx melakukannya dengan baik lewat dua directive yang menyelesaikan dua masalah yang sungguh-sungguh berbeda. limit_req membatasi rate permintaan — seberapa sering satu klien boleh meminta. limit_conn membatasi concurrency — berapa banyak koneksi yang boleh dibuka satu klien secara bersamaan. Banjir permintaan butuh yang pertama; serangan slow-loris, yang menahan ribuan koneksi nyaris-idle untuk menghabiskan worker pool Anda, butuh yang kedua. Terapkan hanya satu saja dan Anda hanya terlindungi dari separuh masalah.

Tiga detail yang membedakan limit yang benar-benar bekerja dari yang hanya hiasan:

• Gunakan burst, dan gunakan nodelay. Browser sungguhan itu bersifat bursty — satu kali membuka halaman memicu selusin permintaan aset yang nyaris bersamaan. Limit tanpa ruang gerak akan menahan pengunjung sungguhan sementara penyerang yang mengatur temponya tepat di bawah ambang batas melenggang lolos.
• Batasi endpoint yang mahal secara terpisah. Halaman pencarian, form login, reset password, dan endpoint mana pun yang menulis ke database layak mendapat jatah yang jauh lebih ketat dibanding aset statis Anda. Penyerang menemukan endpoint ini tanpa perlu berusaha, karena merekalah yang paling menyakitkan.
• Kembalikan 429, bukan 503. Kode status ini adalah sinyal kepada klien yang berperilaku baik dan kepada mesin pencari bahwa ini adalah throttling, bukan kegagalan — dan itu mencegah sore hari yang buruk berubah menjadi masalah ranking.

Caching adalah mitigasi termurah yang pernah bisa Anda terapkan

Rate limit menolak pekerjaan. Cache membuat pekerjaan itu tidak perlu ada. Untuk apa pun yang dilihat pengunjung anonim, full-page caching mengubah ekonomi dari keseluruhan serangan: permintaan yang tadinya berbiaya satu round-trip database, satu render template, dan satu worker PHP berubah menjadi pembacaan file yang diukur dalam mikrodetik. Server yang sama yang tadinya kolaps di angka empat ratus permintaan dinamis per detik akan melayani puluhan ribu permintaan cache tanpa terasa.

Hal-hal yang penting saat Anda menyalakannya dalam kondisi genting:

• Cache hanya untuk pengunjung anonim. Lewati (bypass) jika ada session cookie. Menyajikan halaman satu pengguna yang sedang login kepada pengguna lain adalah insiden yang jauh lebih buruk dibanding outage yang sedang Anda perbaiki.
• Sajikan stale dengan sengaja. proxy_cache_use_stale milik nginx dengan updating error timeout membuat pengunjung mendapat halaman yang sedikit basi alih-alih error saat backend Anda kepayahan. Selama serangan, ini adalah perbedaan antara situs yang terlihat baik-baik saja dan situs yang terlihat mati.
• Gabungkan cache miss yang berduplikasi. proxy_cache_lock memastikan seribu permintaan simultan untuk halaman yang sama yang belum ter-cache hanya menghasilkan satu permintaan ke backend, bukan seribu. Tanpa ini, serangan cache-busting akan menembus cache begitu saja dan menghantam database Anda dengan kekuatan penuh.
• Netralkan query string cache-busting. Trik standarnya adalah menambahkan ? dan sebuah nilai acak sehingga setiap permintaan menjadi key yang unik dan selalu miss selamanya. Normalisasi cache key Anda supaya mengabaikan parameter query yang sebenarnya tidak dipakai aplikasi Anda.

Ada asimetri yang menyenangkan di sini dan layak untuk dihayati: setiap jam yang Anda habiskan untuk caching juga membuat situs lebih cepat pada hari terbaiknya, lebih murah dijalankan, dan lebih tangguh bertahan dari kesuksesan. Nyaris tidak ada lini pertahanan lain yang membayar dividen ketika tidak ada apa pun yang salah.

Batas atas yang menentukan apakah Anda akan tumbang

Sebagian besar server tidak mati karena kehabisan CPU. Mereka mati karena menabrak batas atas yang tidak terlihat, yang tidak sengaja diatur siapa pun — sebuah default dari satu dekade lalu yang dulu masuk akal di hardware yang sekarang sudah tidak dipakai siapa pun lagi. Saat diserang, inilah yang sebenarnya paling dulu jebol:

• Worker aplikasi. pm.max_children milik PHP-FPM, jumlah worker Python Anda, ukuran cluster Node Anda. Inilah batas concurrency sesungguhnya dari situs Anda. Ketika semuanya sibuk, setiap pengunjung tambahan mengantre, dan situsnya down tidak peduli seberapa idle CPU-nya terlihat. Naikkan hanya sejauh yang diizinkan memori — swapping lebih buruk daripada mengantre.
• Accept queue. net.core.somaxconn dan listen backlog Anda menentukan berapa banyak koneksi yang boleh menunggu untuk diterima. Backlog yang kecil mengubah lonjakan yang seharusnya bisa selamat menjadi koneksi yang ditolak.
• SYN cookies. net.ipv4.tcp_syncookies membiarkan kernel menjawab SYN flood tanpa perlu mengalokasikan state untuk koneksi yang tidak akan pernah selesai. Kernel modern mengaktifkannya secara default; verifikasi, jangan hanya berasumsi, karena tidak ada biayanya sama sekali dan ini menyelamatkan Anda dari banjir paling umum yang ada.
• File descriptor. Setiap koneksi adalah sebuah descriptor. Limit nofile default sering kali lebih rendah dari jumlah koneksi yang sedang Anda coba layani, dan mode kegagalannya — accept yang gagal padahal semuanya tampak sehat — benar-benar membingungkan pada jam tiga pagi.
• Koneksi database. Menaikkan jumlah worker tanpa menaikkan connection pool hanya memindahkan antrean itu ke tempat yang lebih sulit terlihat. Kedua angka ini harus disesuaikan bersamaan.

Setel ini semua di hari yang tenang, bukan saat insiden berlangsung. Gunanya mengetahui angka-angka ini adalah supaya saat situsnya tumbang, Anda bisa menyebut nama batas atas yang ditabraknya, bukan sekadar menebak — dan batas atas yang sudah punya nama adalah batas atas yang bisa diperbaiki.

Memasang sesuatu di depan origin

Semua yang di atas terjadi di server itu sendiri. Langkah berikutnya adalah memutuskan apakah server itu sebaiknya menjadi pihak yang menerima lalu lintas secara langsung sama sekali. Ada tiga opsi yang jujur, dan jawaban yang tepat jauh lebih bergantung pada apa yang Anda hosting dibanding apa yang bisa Anda bayar.

Front node yang dikelola sendiri layak mendapat perhatian lebih dibanding yang biasanya diberikan, terutama bagi siapa pun yang memilih hosting offshore karena alasan yang mungkin tidak akan disetujui oleh CDN besar. Polanya tidak muluk-muluk: node proxy murah di depan, origin di-firewall untuk hanya menerima koneksi dari node-node itu, DNS diarahkan ke front-front tersebut. Jika sebuah front diserang, Anda menggantinya dengan alamat baru dalam hitungan menit dan origin-nya sama sekali tidak menyadarinya. Versi lengkap dari arsitektur ini — termasuk enam cara alamat origin tetap bisa bocor — adalah pokok bahasan panduan kami soal menyembunyikan IP origin server Anda.

Origin yang tersembunyi lebih berharga daripada filter apa pun

Ini layak dikatakan secara terus terang, karena ini membalik prioritas yang biasa dipegang orang: mitigasi DDoS termurah yang tersedia bagi Anda adalah sebuah alamat yang tidak dimiliki penyerang. Filtering adalah yang Anda lakukan ketika hal itu sudah gagal duluan.

Ini lebih penting daripada kedengarannya, karena alamat origin bocor terus-menerus dan diam-diam. Record DNS historis dari sebelum Anda memasang proxy di depan tetap ada bertahun-tahun setelah perubahan itu. Mail yang dikirim langsung dari aplikasi membawa alamat itu di headernya. Sertifikat TLS yang diterbitkan untuk alamat mentah dipublikasikan secara permanen di log certificate transparency. Halaman error, sebuah redirect, atau subdomain tersembunyi yang tidak pernah diproksikan semuanya membocorkannya. Jika Anda memasang CDN di depan server yang dulu pernah terekspos, anggap saja alamat lamanya sudah diketahui sampai Anda benar-benar menggantinya.

Memilih hardware dan lokasi agar serangan tetap membosankan

Sebagian dari ini sudah ditentukan sebelum serangan itu terjadi, yaitu pada saat Anda memilih paket. Tiga properti ini jauh lebih penting daripada yang tersirat di lembar spesifikasi:

• Bandwidth unmetered. Pada paket metered, sebuah serangan bukan hanya outage — itu juga tagihan. Lalu lintas yang tidak pernah Anda minta dan tidak bisa Anda tolak tetap dihitung terhadap kuota Anda. Transfer unmetered mengubah risiko finansial menjadi risiko yang murni teknis, yang merupakan kelas masalah yang jauh lebih baik.
• Apakah port-nya milik Anda sendiri. Di host virtualisasi yang dipakai bersama, tetangga yang sedang diserang bisa menurunkan performa Anda, dan batas atas perlindungan Anda sendiri juga dipakai bersama. Dedicated hardware dengan port miliknya sendiri menghilangkan kedua efek itu. Untuk proyek yang memang mengantisipasi perhatian yang bermusuhan, inilah alasan paling jelas untuk naik kelas dari VPS — lebih dari sekadar soal core atau RAM.
• Di mana network itu berada. Network Eropa yang tersambung baik dengan kapasitas transit sungguhan menyerap banjir yang tidak akan sanggup diserap oleh network dengan peering yang buruk, dan yurisdiksi yang Anda pilih karena alasan hukum juga punya karakteristik network-nya sendiri. Ini layak dicek keduanya saat memilih dari lokasi-lokasi yang tersedia.

Ada juga argumen skala yang diam-diam berpihak pada kesederhanaan. Situs statis di balik cache pada server sederhana sangat sulit dijatuhkan; konten yang sama pada CMS berat dengan endpoint pencarian yang tidak ter-cache bisa dijatuhkan oleh satu orang yang cukup gigih dengan sebuah script. Mengurangi apa yang bersifat dinamis adalah mitigasi, dan itu gratis. Jika proyek Anda sungguh-sungguh hidup di bawah load yang berkelanjutan, catatan hosting untuk lalu lintas tinggi kami membahas sisi sizing dari pertanyaan yang sama.

Lima hal yang jangan dilakukan

Pola kegagalan di sini cukup konsisten untuk didaftar, dan masing-masing pernah menghabiskan akhir pekan seseorang:

• Jangan null-route diri Anda sendiri. Melakukan blackhole terhadap alamat Anda sendiri mengakhiri serangan itu dengan cara yang paling harfiah — tidak ada seorang pun yang bisa menjangkau Anda, termasuk pengguna Anda sendiri. Ini adalah alat pilihan terakhir milik provider Anda, bukan tindakan yang Anda ambil secara sukarela.
• Jangan anggap fail2ban sebagai perlindungan DDoS. Ini alat yang bagus untuk melawan percobaan brute-force dari segelintir alamat. Terhadap banjir yang terdistribusi, ia bereaksi dalam hitungan menit terhadap sesuatu yang datang dalam hitungan detik, dan sebuah rule yang memblokir ribuan alamat bisa menghabiskan lebih banyak resource pemrosesan firewall dibanding kerugian dari serangan itu sendiri.
• Jangan bayar tebusan. Sebagian besar email pemerasan yang mengancam serangan dahsyat datang dari orang-orang yang sama sekali tidak punya kemampuan dan hanya mengirim ribuan pesan yang identik. Sebagian kecil yang benar-benar sanggup menindaklanjuti akan kembali lagi, karena Anda sudah membuktikan bahwa Anda mau membayar.
• Jangan membalas. Selain ilegal di hampir semua tempat, sumber serangannya adalah pihak ketiga yang mesinnya sudah disusupi. Anda akan menyerang korban, dan melakukannya dari alamat yang jelas-jelas milik Anda sendiri.
• Jangan migrasi dalam kepanikan. Berpindah host di tengah serangan berarti alamat barunya akan publik dalam hitungan menit dan Anda belum punya konfigurasi yang berfungsi. Stabilkan dulu, baru berpindah dengan sengaja belakangan — dan jika Anda memang berpindah, panduan kami soal migrasi tanpa downtime ada persis untuk memastikan kepindahan itu tidak menjadi insiden kedua.

Versi singkatnya

Dilepas dari semua penalarannya, model kerjanya muat dalam delapan baris:

1. Klasifikasikan dulu. Interface yang jenuh berarti volumetrik dan menjadi urusan host Anda. Interface yang tenang dengan worker yang habis berarti layer 7 dan menjadi urusan Anda.
2. Untuk volumetrik, ajukan tiket dengan alamat, timestamp, dan penghitung Anda — lalu berhenti menyentuh server itu.
3. Lakukan caching secara agresif untuk pengunjung anonim, sajikan stale saat tertekan, dan gabungkan cache miss yang berduplikasi. Ini adalah perubahan dengan daya ungkit tertinggi yang bisa Anda buat.
4. Terapkan rate limit berdasarkan laju permintaan maupun concurrency, paling ketat pada endpoint yang paling mahal, dan kembalikan 429.
5. Perbaiki konfigurasi real-IP Anda sebelum semua yang lain, atau setiap limit per klien di balik proxy akan sia-sia atau justru bencana.
6. Kenali batas atas Anda — worker, backlog, descriptor, koneksi database — dan naikkan secara sengaja di hari yang tenang.
7. Jaga alamat origin tetap rahasia dan di-firewall hanya untuk front node Anda. Ini lebih berharga daripada semua filter digabung jadi satu.
8. Beli bandwidth unmetered supaya lalu lintas yang tidak Anda minta tidak pernah berubah menjadi tagihan juga.

Tidak satu pun dari ini membuat Anda kebal, dan siapa pun yang menjual kekebalan sedang menjual sesuatu yang lain. Yang benar-benar dilakukannya adalah memindahkan Anda keluar dari populasi yang bisa dijatuhkan oleh remaja iseng yang bosan, ke populasi yang membutuhkan resource sungguhan dan niat sungguhan untuk mengganggu — yang, bagi sebagian besar proyek, sudah nyaris tidak bisa dibedakan dari aman. Sisanya adalah pekerjaan tidak glamor yang sama, yang membuat sebuah server unggul dalam segala hal lainnya: di-harden sejak hari pertama, bisa dipulihkan pada hari terburuknya, dan berjalan di tempat yang memperlakukan lalu lintas Anda sebagai urusan Anda sendiri.