Menyembunyikan IP Origin Server

"Perlukah saya memasang CDN di depannya?" adalah pertanyaan pertama yang ditanyakan kebanyakan orang setelah membeli server offshore, dan tidak ada jawaban tunggal untuknya, karena sebenarnya ini adalah dua pertanyaan yang mengenakan satu mantel yang sama. Menyerap serangan dan tetap tidak dapat ditemukan adalah dua masalah berbeda dengan solusi berbeda, dan susunan yang menyelesaikan satu masalah bisa diam-diam menggagalkan yang lain.

Kebingungan ini mahal harganya di kedua arah. Sebagian orang memasang CDN besar asal Amerika di depan konten yang justru mereka pilih hosting DMCA-ignored untuknya, dan menyerahkan kembali meja aduan kepada persis jenis perantara yang tadinya ingin mereka hindari. Sebagian lain melewatkan semuanya, terkena banjir permintaan di application layer yang memang tidak pernah dirancang untuk dilihat oleh network filtering, lalu menyimpulkan bahwa perlindungan DDoS-nya bohong. Panduan ini memisahkan kedua masalah tersebut, menjelaskan apa yang sungguh-sungguh dilakukan oleh masing-masing lapisan, dan menghabiskan sebagian besar isinya pada bagian yang menentukan hasil akhirnya: enam cara sebuah alamat origin tetap bocor meski semua yang lain sudah dikonfigurasi dengan benar.

Dua masalah yang tampak seperti satu

Apa pun yang Anda pasang di depan sebuah server sedang menjalankan salah satu dari dua tugas: menjauhkan serangan darinya, atau menjaga alamatnya tetap tidak diketahui. Keduanya cukup tumpang tindih untuk membingungkan, dan cukup berbeda sehingga menyelesaikan yang salah adalah pemborosan uang.

Bacalah baris terakhir itu dua kali, karena itulah yang paling sering menjebak orang. Semua hal lain di halaman ini adalah soal rekayasa teknis. Baris itu bukan.

Apa yang sudah dilakukan host Anda, dan di mana batasnya

Filtering layer 3 dan layer 4 sudah termasuk di setiap paket yang kami jual, tanpa biaya tambahan, dan ia berjalan di network edge, bukan di server Anda — satu-satunya tempat di mana ia bisa bekerja, karena uplink yang jenuh tidak bisa diperbaiki oleh apa pun yang berjalan di belakangnya. Bandwidth tidak dibatasi (unmetered), jadi sebuah serangan tidak berubah menjadi tagihan. Untuk sebagian besar hal yang disebut orang sebagai "DDoS", itulah keseluruhan ceritanya.

Yang tidak bisa dilihatnya adalah jenis yang satu lagi. Lima ratus permintaan per detik ke sebuah endpoint pencarian dari empat puluh ribu alamat residensial bukan lalu lintas yang cacat; itu tetap lalu lintas biasa. Koneksi Slowloris yang mengirim satu header setiap beberapa detik, secara individu, terlihat sopan-sopan saja. Formulir login yang dihajar dengan body POST sungguhan tidak bisa dibedakan pada level paket dari hari Senin yang sedang sibuk. Tidak ada packet filter yang membantu, karena tidak ada yang salah dengan paket-paketnya.

Ada satu arah lalu lintas yang memang kami tindak, dan ini layak dinyatakan secara terus terang: serangan dan spam massal yang berasal dari jaringan kami bisa saja di-null-route demi menjaga kesehatan infrastruktur yang lain. Itu adalah tindakan operasional, bukan tindakan terhadap konten — perbedaan yang dijelaskan lebih rinci di panduan DMCA-ignored hosting kami.

Apa yang disembunyikan CDN, dan meja aduan yang Anda warisi

Mekanismenya sederhana dan sungguh-sungguh efektif. Domain Anda me-resolve ke alamat milik provider, klien terhubung ke sana, dan provider itulah yang mengambil data dari origin Anda. Alamat asli tidak pernah muncul dalam koneksi klien, sehingga tidak bisa diserang oleh siapa pun yang hanya mengetahui domainnya. Trik yang sama inilah yang membuat CDN fronting bekerja untuk proxy tahan-sensor: sensor melihat lalu lintas menuju sebuah alamat yang tidak sanggup ia blokir.

Tiga hal datang bersamanya, dan tidak satu pun disembunyikan dalam cetakan kecil:

• Edge itu mengakhiri TLS Anda. Lalu lintas menjadi plaintext di dalam jaringan provider, memang begitu desainnya — begitulah cara kerja caching dan filtering. Apa pun yang diketik pengguna Anda sampai ke pihak ketiga sebelum sampai ke Anda.
• Kanal aduan yang sebelumnya tidak ada. Komplain bisa diajukan langsung terhadap CDN, dan CDN akan meresponsnya: dengan meneruskannya ke Anda, dengan menyebut nama hosting provider Anda, atau dengan menghentikan layanan Anda. Jika alasan Anda memilih offshore adalah agar komplain tidak sampai ke mana-mana, memasang perantara asal AS di depan justru menyambung kembali rantai yang sudah Anda bayar untuk diputus.
• Sebuah akun. Alamat email, metode pembayaran, sering juga nomor telepon, terikat pada domain Anda dan disimpan tanpa batas waktu. Lebih lanjut soal ini di bawah, karena biasanya inilah mata rantai paling lemah dalam keseluruhan susunan tersebut.

Tidak satu pun dari itu membuat CDN menjadi pilihan yang salah. Itu menjadikannya keputusan dengan dua sisi: sangat baik untuk toko atau aplikasi dengan pengguna sungguhan dan tekanan layer-7 yang nyata, tapi justru kontraproduktif untuk publishing yang memancing takedown. Jawaban kami sendiri atas pertanyaan ini di halaman DMCA-ignored hosting selalu merupakan versi singkat dari ini: untuk ketahanan terhadap takedown, gunakan network filtering yang sudah Anda miliki dan lewati saja CDN-nya.

Enam cara alamat origin tetap bocor

Inilah bagian yang benar-benar penting, karena penyamaran bukan produk yang Anda beli — itu adalah sifat yang harus Anda rawat atau yang akan Anda kehilangan, biasanya dalam hitungan hari, karena salah satu dari enam hal. Origin ditemukan setiap hari di balik konfigurasi CDN yang sebenarnya sudah sangat baik.

• Log Certificate Transparency. Setiap sertifikat tepercaya publik yang diterbitkan untuk domain Anda dipublikasikan ke log publik, permanen, dan bisa dicari, dalam hitungan menit. Log itu tidak mempublikasikan alamat Anda; ia mempublikasikan hostname Anda — staging, mail, vpn, subdomain yang pernah Anda buat sekali di 2024. Masing-masing adalah kandidat untuk di-resolve, dan satu saja record yang tidak mengarah ke front sudah mengakhiri seluruh usaha penyamaran itu.
• Riwayat DNS. Layanan passive-DNS mengarsipkan setiap alamat yang pernah menjadi hasil resolve domain Anda. Berpindah ke belakang CDN setelahnya tidak menghapus apa yang sudah tercatat — penyamaran harus dimulai sebelum domain pertama kali di-resolve, atau Anda butuh alamat baru, bukan sekadar front baru.
• Record yang tidak bisa diproksikan, dan yang Anda lupakan. Mail exchanger harus mengarah ke sesuatu yang bisa dijangkau. Begitu juga sebuah record AAAA yang tertinggal ketika Anda hanya memproksikan IPv4, hostname FTP atau panel lama, sebuah wildcard, atau host development "sementara" yang kini sudah berumur tiga tahun.
• Apa pun yang dikirim server. Email dari origin membawa alamatnya di header Received — sebuah pesan reset password adalah pengungkapan yang Anda lakukan sendiri. Webhook, pengambilan gambar keluar (outbound), pratinjau tautan, pingback, pengecekan update, dan crash reporter semuanya menghubungi dari alamat asli, dan siapa pun yang bisa membuat aplikasi Anda berbicara ke host yang mereka kendalikan akan mengetahuinya.
• Pemindaian seluruh internet. Setiap alamat IPv4 dipindai dan diindeks terus-menerus oleh layanan publik, dan hasilnya bisa dicari dalam hitungan detik. Jika origin Anda menjawab di port 443 dengan sertifikat Anda, atau menyajikan homepage Anda untuk Host header apa pun, mencocokkannya hanya perlu satu query terhadap body hash, fingerprint sertifikat, atau hash favicon. Begitulah cara kebanyakan origin ditemukan, dan itu tidak memakan biaya apa pun bagi yang mencarinya.
• Aplikasi yang membicarakan dirinya sendiri. URL absolut dan redirect yang memuat alamat mentah, endpoint status atau metrics yang dibiarkan terbuka, stack trace verbose yang menyebut nama host internal, header yang membocorkan backend-nya, dan default virtual host yang dengan senang hati menyajikan situs Anda kepada siapa pun yang memintanya lewat alamat.

Mengunci origin agar hanya front yang bisa menjangkaunya

Penyamaran yang bergantung pada tidak ada orang yang menebak alamatnya bukanlah penyamaran. Susunan ini hanya bertahan ketika origin menolak berbicara dengan siapa pun selain front, sehingga alamat yang bocor hanya menjadi gangguan kecil, bukan sebuah peristiwa.

• Default-deny, lalu izinkan front-nya saja. Terima port 80 dan 443 hanya dari rentang alamat yang dipublikasikan provider, dan perbarui daftar itu secara otomatis — rentangnya berubah, dan daftar yang basi bisa fail open atau fail closed pada saat yang paling buruk. Semua yang lain, termasuk SSH, sebaiknya berada di balik tunnel atau alamat manajemen, sebagaimana dijelaskan di checklist hardening jam pertama kami.
• Autentikasi front-nya. Sertifikat klien antara CDN dan origin Anda — biasa disebut authenticated origin pulls — membuat bahkan alamat yang benar plus Host header yang benar sekalipun tidak mendapatkan apa-apa tanpa sertifikat itu.
• Lebih baik lagi: tanpa port inbound sama sekali. Sebuah tunnel outbound-only dari origin menuju edge, baik memakai connector milik CDN sendiri maupun WireGuard menuju node yang Anda jalankan, membuat origin tidak pernah listening di interface publik. Pemindaian tidak bisa menemukan apa yang tidak menjawab, dan inilah versi paling kuat dari susunan ini.
• Satu virtual host, satu Host header. Server default seharusnya tidak mengembalikan apa pun yang berguna. Jika situs Anda tetap termuat ketika diakses lewat alamat, ia akan dicocokkan oleh scanner dalam waktu seminggu.
• Pindahkan mail dari web origin. Mail harus bisa dijangkau dan harus mengidentifikasi dirinya sendiri; simpan di mesin terpisah, sebagaimana diasumsikan oleh panduan mail server kami.
• Verifikasi dari luar. Setiap pengecekan di daftar ini tidak berarti apa-apa jika dijalankan dari server itu sendiri. Uji dari jaringan yang bukan milik Anda.

Front node Anda sendiri, sebagai pengganti CDN

Opsi ketiga ini sering dilewatkan karena tidak punya anggaran pemasaran: sebuah VPS kecil sebagai wajah publik, tunnel terenkripsi kembali ke mesin yang menyimpan data, dan nginx atau HAProxy yang meneruskan lalu lintas di antara keduanya. Dari luar, ia terlihat seperti web server pada umumnya. Server yang sesungguhnya berada di tempat lain, tanpa port inbound sama sekali.

Yang Anda dapatkan adalah penyamaran tanpa ada pihak lain dalam susunan itu — tidak ada akun pihak ketiga, tidak ada meja aduan eksternal, tidak ada orang asing yang mengakhiri TLS Anda. Anda juga mendapatkan pemisahan yurisdiksi yang sulit dibeli lewat cara lain: front di tempat para pengguna berada, data di tempat hukumnya menguntungkan Anda, dipilih dari tujuh lokasi kami. Dan karena tidak ada identitas yang dilekatkan saat pendaftaran, front-nya sekali pakai — alamat yang terbakar diganti dalam hitungan menit, bukan dinegosiasikan.

Yang tidak Anda dapatkan adalah kapasitas anycast. Satu node hanya punya kapasitas satu node, dan meski network filtering kami melindunginya persis seperti melindungi server lain mana pun, serangan volumetrik yang sungguh-sungguh besar adalah kontes bandwidth yang dimenangkan oleh jaringan global. Posisi jujurnya: front node adalah jawaban yang tepat untuk menyembunyikan backend yang berat atau mahal — storage array, mesin GPU, mail server, database — dan untuk memisahkan yurisdiksi. Ia bukan pengganti CDN di bawah tekanan layer-7 yang berkelanjutan.

Memilih, dalam satu tabel

Akun biasanya menjadi mata rantai paling lemah

Perhatikan apa yang terjadi ketika infrastrukturnya sempurna tapi dokumennya tidak. Server dibayar dengan Monero, tanpa dokumen identitas dan tanpa alamat email — susunan yang dijelaskan di halaman no-KYC hosting kami. Lalu sebuah akun CDN dibuka dengan kartu, alamat pribadi, dan nomor telepon, mencantumkan domain yang dilindunginya. Akun itu adalah catatan identitas yang jauh lebih kuat dan lebih tahan lama dibanding apa pun di server, dipegang oleh perusahaan yang menuruti panggilan pengadilan (subpoena), dan itu menggagalkan seluruh privasi pembayaran yang sudah dibangun.

Perbaikannya tidak rumit, hanya mudah terlupakan: jika tujuannya adalah anonimitas, front itu harus milik Anda sendiri, atau akun di depannya harus sekali pakai dan tidak terlacak, sama seperti server di belakangnya. Server OpSec kami membahas disiplin ini dengan tepat, dan jawaban jujur kami soal anonimitas offshore berterus terang soal mata rantai mana yang biasanya putus lebih dulu. Hampir tidak pernah itu mata rantai teknis.

Mengaudit eksposur Anda sendiri dalam sepuluh menit

Setiap poin di bawah ini adalah hal yang akan diperiksa pihak yang berkepentingan dalam beberapa menit pertama. Jalankan sendiri, dari mesin yang bukan server itu, sebelum Anda benar-benar membutuhkan jawabannya.

• Daftar semua hostname yang pernah Anda sertifikasi. Cari apex domain Anda di mesin pencari Certificate Transparency dan resolve setiap hasilnya. Apa pun yang tidak mengarah ke front adalah kebocoran, termasuk host yang sudah tidak Anda pakai lagi.
• Baca riwayat DNS Anda sendiri. Lookup passive-DNS menunjukkan alamat-alamat yang menjadi hasil resolve domain Anda sebelum ada CDN. Jika origin kemarin masih menjadi origin hari ini, penyamarannya memang tidak pernah nyata.
• Tanyakan langsung ke origin. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — jika situsnya menjawab, firewall Anda tidak membatasi ke front saja, dan siapa pun dengan alamat kandidat bisa mengonfirmasinya dalam satu permintaan.
• Tanyakan dengan kasar. curl -skI https://198.51.100.10/ seharusnya tidak mengembalikan apa pun yang bisa dikenali. Default virtual host yang menyajikan homepage Anda adalah satu kesalahan paling umum di halaman ini.
• Periksa setiap tipe record, bukan hanya A. dig +short AAAA example.com, dig +short MX example.com, dan yang sama untuk setiap subdomain yang terungkap lewat transparency log. IPv6 yang tertinggal tanpa proxy adalah kesalahan klasik.
• Kirim email ke diri sendiri dari aplikasi. Picu sebuah reset password dan baca rangkaian header Received secara lengkap. Jika alamat origin ada di situ, alamat itu juga ada di setiap pesan yang pernah Anda kirim.
• Pastikan port-nya tertutup. Dari jaringan yang tidak berhubungan, nmap -Pn -p80,443 198.51.100.10 seharusnya menunjukkan filtered, bukan open.
• Cari di scanner. Cari fingerprint sertifikat Anda dan hash favicon homepage Anda di indeks pemindaian internet publik. Jika origin Anda terindeks, begitulah cara ia akan ditemukan.

Ketika alamatnya sudah terbakar

Anggap saja alamat itu tetap terbakar. Alamat yang sudah muncul di passive DNS dan di indeks pemindaian sudah menjadi catatan publik permanen, dan tidak ada perubahan konfigurasi yang bisa menariknya kembali. Responsnya bersifat mekanis, bukan sesuatu yang perlu kepintaran khusus.

• Perbaiki dulu kebocorannya. Berpindah ke alamat baru tanpa menutup celahnya akan mengulang situasi yang sama dalam hitungan hari, dan Anda hanya menghabiskan sebuah migrasi tanpa mempelajari apa pun.
• Baru kemudian rotasi. Deploy penggantinya — di yurisdiksi yang berbeda jika alasannya hukum, bukan teknis — pulihkan datanya, lalu cut over. Karena tidak ada identitas yang melekat pada server pertama, ini adalah awal yang benar-benar baru, bukan sebuah negosiasi — itulah keuntungan praktis dan tidak glamor dari membeli server tanpa riwayat akun.
• Siapkan cutover-nya sebelum keadaan darurat terjadi. TTL DNS yang pendek, konfigurasi yang bisa Anda deploy ulang dari repository, dan restore yang sudah diuji, mengubah sore hari yang buruk menjadi hanya dua puluh menit. Tidak ada yang mengatur ini di tengah-tengah serangan.
• Pensiunkan alamat lama dengan benar. Jangan biarkan server lama tetap parkir di alamat lama sambil menyajikan konten yang sama; itu adalah konfirmasi langsung bagi siapa pun yang mengawasi, dan itu membuat catatannya tetap segar.

Versi singkatnya

Network-level filtering menangani serangan volumetrik, sudah termasuk bersama server, dan tidak menambah biaya. CDN menangani application layer dan menyembunyikan origin, dengan harga berupa perantara yang mengakhiri TLS Anda, menjawab komplain, dan tahu siapa Anda. Front node Anda sendiri membeli penyamaran tanpa perantara, tapi tanpa kapasitas global. Yurisdiksi yang menentukan soal hukum, dan tidak satu pun dari ketiganya menyentuh itu. Dan ketiganya bisa digagalkan oleh satu record yang tidak diproksikan, satu email dari origin, atau satu default virtual host.

Putuskan berdasarkan tujuan, bukan kebiasaan, lalu luangkan sepuluh menit untuk audit itu — ini menemukan lebih banyak eksposur nyata dibanding upgrade apa pun. Jika Anda menginginkan arsitektur ini tanpa pihak ketiga, sebuah VPS kecil sebagai front dan pekerjaan sesungguhnya di dedicated hardware di belakangnya adalah susunan yang paling sering kami lihat di antara orang-orang yang sudah pernah ditemukan sekali.