Mengamankan VPS baru di jam pertama

Perhatikan journalctl -u ssh pada server yang sudah online selama satu jam, dan volumenya akan terasa mengkhawatirkan saat pertama kali Anda melihatnya. Padahal seharusnya tidak. Yang sedang Anda lihat adalah radiasi latar belakang internet: segelintir operasi scanning, sebagian akademis, sebagian komersial, sebagian kriminal, yang menyisir seluruh ruang IPv4 secara terus-menerus dan menyerahkan hasilnya ke bot penebak kredensial. Alamat Anda dijangkau karena memang ada, dalam urutan numerik, dan akan dijangkau lagi beberapa jam kemudian apa pun yang Anda lakukan.

Ini mengubah bentuk masalahnya dengan cara yang menguntungkan. Anda tidak sedang bertahan dari musuh yang secara khusus memilih Anda dan akan beradaptasi; Anda sedang bertahan dari skrip dengan daftar tetap — root, admin, ubuntu, test, git, oracle, postgres, dan dua puluh ribu password yang pernah muncul di breach dump. Skrip itu tidak punya kesabaran, tidak punya kreativitas, dan tidak tertarik pada mesin yang tidak merespons di percobaan pertama. Mematikan autentikasi password tidak memperlambat penyerang ini. Itu menyingkirkannya sepenuhnya dari papan permainan.

Ada dua detail yang layak diketahui. Pertama, IPv6 jauh lebih sepi, karena /64 tidak mungkin disisir habis — tapi begitu record AAAA Anda menjadi publik, atau alamat mesin Anda muncul di header email atau di log certificate transparency, kesunyian itu berakhir. Jangan pernah menganggap IPv6 sebagai tempat bersembunyi; anggap saja sebagai tumpukan jerami yang lebih kecil. Kedua, alamat IPv4 punya masa lalu. Ada penyewa sebelum Anda, dan jika penyewa itu mengelola mail server dengan buruk atau meng-host sesuatu yang akhirnya masuk daftar blokir, Anda mewarisi reputasi itu sampai akhirnya memudar. Jika email penting bagi Anda, cek alamat itu di blocklist yang umum dipakai sebelum membangun apa pun di atasnya — pengecekan lima menit ini menghemat dua minggu debugging masalah deliverability.

Hampir semua kompromi nyata terhadap server kecil bermula dari salah satu dari dua hal: password yang bisa ditebak, atau service yang mendengarkan (listening) padahal seharusnya tidak. Perbaikan yang sesuai adalah PasswordAuthentication no dan firewall dengan default policy drop. Keduanya tidak terlihat mengesankan, hanya butuh lima belas menit jika dikerjakan bersamaan, dan nilainya lebih besar daripada seluruh kontrol lain di halaman ini digabung jadi satu.

Alasannya bersifat struktural, bukan statistik. Keduanya tertutup secara default — keduanya gagal ke arah yang aman. sshd yang hanya menerima kunci tidak bisa di-brute-force betapa pun banyaknya percobaan yang datang, karena tidak ada satu pun jalur kode yang menerima password. Firewall default-deny melindungi service yang bahkan belum Anda pasang, termasuk database yang akan Anda tambahkan tiga bulan lagi dan lupa Anda ikat ke localhost. Semua hal lain dalam checklist hardening hanyalah pendataan hal-hal buruk: daftar hal spesifik yang harus dimatikan, yang kelengkapannya hanya sebatas daftar itu sendiri.

Jadi kalau Anda hanya sempat membaca satu bagian lalu menutup tab ini, bacalah bagian ini, kerjakan langkah 2 sampai 5 di bawah, dan anggap jam itu sudah terpakai dengan baik. Sisanya benar-benar berguna, tapi benar-benar sekunder.

Di Debian 13 dan Ubuntu 24.04, /etc/ssh/sshd_config dibuka dengan baris Include /etc/ssh/sshd_config.d/*.conf, dan cloud image menyertakan sebuah file di direktori itu — biasanya 50-cloud-init.conf — yang sudah mengatur PasswordAuthentication. Mengedit file utama dan menambahkan directive Anda sendiri di bagian bawah terasa wajar, tapi menghasilkan konfigurasi yang tidak melakukan apa yang tertulis di dalamnya.

Aturannya adalah satu hal tentang sshd yang mengejutkan hampir semua orang: untuk setiap keyword, nilai pertama yang diperoleh yang menang. Ini kebalikan dari hampir semua sistem penggabungan konfigurasi lain yang pernah Anda pakai. Include berada dekat bagian atas file utama, sehingga drop-in dibaca sebelum isi sshd_config — dan di antara sesama drop-in, urutan alfabet yang memutuskan. File bernama 10-hardening.conf mengalahkan 50-cloud-init.conf. File bernama 60-hardening.conf kalah darinya, secara diam-diam, dan Anda tidak akan mengetahui hal ini dari restart yang melaporkan sukses.

Itulah sebabnya Anda tidak boleh pernah percaya begitu saja pada file yang baru saja Anda tulis. Tanyakan langsung ke daemon-nya apa yang sebenarnya sudah ia resolve:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T menampilkan konfigurasi efektif setelah semua include, override, dan default selesai di-resolve. Jika output itu menyatakan passwordauthentication yes, berarti autentikasi password sedang aktif, apa pun yang diklaim oleh file di disk. Tidak ada cara verifikasi lain yang berlaku.

Jebakan kedua masih satu keluarga dengan yang pertama. Ubuntu 24.04 menjalankan sshd lewat socket activation: ssh.socket yang memiliki port listening, dan Port di sshd_config diabaikan sepenuhnya. Periksa dengan systemctl is-enabled ssh.socket; jika itu enabled dan Anda ingin port yang berbeda, ubah dengan systemctl edit ssh.socket dan override ListenStream= — bukan di sshd_config, tempat pengaturan itu akan terlihat benar padahal tidak berpengaruh sama sekali.

Mari jujur soal yang satu ini, karena internet sendiri tidak jujur. Memindahkan sshd ke port 2222 atau 47000 tidak menghentikan satu pun attacker yang kompeten. Full TCP scan terhadap satu host hanya butuh hitungan detik, service itu mengumumkan dirinya sendiri lewat banner-nya, dan siapa pun yang sudah memutuskan untuk menyerang Anda secara spesifik akan menemukannya sebelum kopinya habis.

Yang benar-benar dilakukannya adalah memangkas log autentikasi Anda sekitar sembilan puluh lima persen, dan itu punya nilai nyata: itulah bedanya antara log yang cuma Anda lirik sekilas dengan log yang benar-benar Anda baca. Sinyal yang bisa Anda lihat mengalahkan sinyal yang terkubur. Kalau Anda memonitor apa pun sama sekali, auth.log yang sepi adalah cara termurah untuk membuat anomali jadi terlihat.

Biayanya kecil tapi nyata, dan itulah alasan kami menyebutnya opsional, bukan direkomendasikan. Anda akan lupa nomor port itu saat kembali delapan bulan kemudian. Port non-standar di atas 1024 secara prinsip bisa saja diklaim oleh proses tanpa privilege kalau sshd sedang tidak listening. Firewall outbound yang ketat di jaringan klien memblokir port-port yang tidak umum, jadi sesekali Anda tidak akan bisa menjangkau server Anda sendiri dari kantor atau hotel. Dan pada sistem yang diaktifkan lewat socket, Anda harus mengubahnya di tempat yang benar, sesuai bagian sebelumnya. Lakukan ini kalau log yang sepi penting bagi Anda. Jangan lakukan ini lalu merasa aman, dan jangan pernah melakukannya sebagai pengganti dari keys-only.

Firewall yang mendaftar apa yang harus diblokir hanyalah sistem pengarsipan. Firewall yang mendaftar apa yang boleh diizinkan adalah kontrol keamanan sungguhan. Perbedaan ini adalah keseluruhan intinya, karena hanya yang kedua yang mencakup service yang Anda pasang bulan depan, port debug yang Anda buka di suatu hari Jumat, dan container yang tiba-tiba memutuskan untuk mengekspos dirinya sendiri.

Di platform kami, Anda punya dua lapisan, dan keduanya independen. Edge filter sifatnya opsional, dikonfigurasi per server lewat panel dan diberlakukan di level hypervisor, sehingga traffic yang diblokir tidak pernah sampai ke guest Anda sama sekali — berguna untuk rule layer-4 yang ingin Anda terapkan sebelum kernel Anda membuang satu siklus pun untuk memprosesnya, dan untuk mencegah guest yang sudah dikompromikan tetap bisa dijangkau selagi Anda menanganinya. Firewall guest sepenuhnya milik Anda: nftables, iptables, pf, apa pun yang disertakan oleh image Anda. Kami tidak pernah menyentuhnya. Gunakan keduanya kalau mesin itu penting; gunakan setidaknya yang kedua, selalu.

Ada dua hal dalam ruleset di langkah 5 yang layak dijelaskan, karena kebanyakan ruleset hasil copy-paste salah menanganinya. Jangan drop semua ICMP. Rasanya rapi, tapi ini merusak path-MTU discovery, yang menghasilkan kelas bug terburuk yang ada: request kecil berjalan lancar, response besar menggantung, dan tidak ada satu pun di log Anda yang menyebut soal firewall. Terima minimal destination-unreachable, time-exceeded, dan parameter-problem. Jangan filter ICMPv6 berdasarkan tipe kecuali Anda tahu persis daftarnya. IPv6 bergantung pada ICMPv6 untuk neighbour discovery dan router advertisement; blokir secara luas dan konektivitas IPv6 Anda akan mati dengan cara yang terlihat seperti masalah routing. Menerima semua ICMPv6 pada satu host adalah kompromi yang masuk akal, dan itulah persis yang dilakukan ruleset di bawah ini.

Satu peringatan sebelum Anda menjalankan flush ruleset: kalau Docker terpasang, baris itu akan menghapus rule NAT dan filter yang ditulis Docker, dan networking container akan berhenti sampai systemctl restart docker mengembalikannya. Muat ruleset Anda dulu, baru restart Docker, dan baca bagian berikutnya sebelum Anda mempublikasikan satu pun port container.

Tanyakan langsung ke mesin itu, apa yang sedang ia dengarkan (listen). Bukan apa yang Anda kira sudah Anda pasang — tapi apa yang benar-benar sedang bound saat ini:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Semua yang lolos dari filter itu berarti bisa dijangkau dari tempat lain, bukan cuma dari mesin itu sendiri. Pada image bawaan, temuan yang biasa muncul adalah rpcbind di port 111 (tidak ada satu pun yang Anda jalankan yang membutuhkannya), listener exim4 sisa dari instalasi dasar, dan stub systemd-resolved yang tidak berbahaya kalau di loopback tapi menjadi open resolver kalau tidak. Yang benar-benar berbahaya muncul belakangan, seiring software yang sengaja Anda pasang: PostgreSQL di 0.0.0.0:5432 karena sebuah tutorial menyuruh Anda mengedit listen_addresses, Redis tanpa password karena Redis memang tidak punya password default selama sebagian besar masa hidupnya, node Elasticsearch, exporter Prometheus, notebook Jupyter. Masing-masing pernah menjadi langkah pertama dari breach sungguhan, berkali-kali.

Sekarang jebakan yang bahkan menjerat orang yang berhati-hati. Docker tidak meminta izin ke firewall Anda. Saat Anda menulis -p 5432:5432, Docker menyisipkan rule DNAT di chain PREROUTING pada tabel nat, yang dievaluasi kernel sebelum chain input Anda sempat melihat paket itu sama sekali; traffic itu kemudian diteruskan (forward) ke container. Policy input default-deny Anda sama sekali tidak dilibatkan, ufw status menunjukkan port itu tertutup, padahal database Anda ada di internet publik. Ini adalah perilaku Docker yang memang terdokumentasi, sudah begini selama satu dekade, dan sudah mengekspos database dalam jumlah yang sangat banyak.

Perbaikannya cuma satu string, dan inilah kebiasaan yang layak dibangun:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Terakhir, cari pendapat dari luar. Port scan dari server itu sendiri hanya memberi tahu Anda apa yang dipikirkan kernel; scan dari tempat lain memberi tahu Anda apa yang dilihat dunia luar, dan itulah satu-satunya angka yang benar-benar penting. Jalankan nmap -Pn -p- <your-ip> dari laptop Anda, bukan dari mesin itu sendiri, lalu bandingkan hasilnya dengan daftar yang Anda harapkan.

Celah waktu yang membuat server kecil terkompromi bukanlah zero-day. Justru empat minggu di antara sebuah CVE dipublikasikan lengkap dengan proof of concept yang berfungsi, dan waktu berikutnya Anda kebetulan login lagi. Tooling penyerangan menyerap bug remote baru hanya dalam hitungan hari; mesin yang Anda patch “kalau sempat” akan terekspos selama seluruh interval itu, dan setiap operator yang jujur tahu betul seberapa panjang interval itu sebenarnya.

Keberatan terhadap pembaruan otomatis biasanya rasa takut sesuatu akan rusak, dan itu layak dipertimbangkan serius — lalu dipersempit. Batasi otomatisasi hanya pada pocket security dari distro Anda, tempat maintainer melakukan backport perbaikan ke versi yang sudah Anda pakai, bukan merilis versi upstream yang baru. Pembaruan security Debian untuk openssl adalah build yang sudah diperbaiki dari versi yang sama dengan yang sudah Anda jalankan; risiko perubahan perilakunya jauh lebih kecil dibanding risiko membiarkan lubang yang bisa diakses dari jarak jauh terbuka selama sebulan. Upgrade fitur tetap manual, sebagaimana seharusnya.

Bagian yang sering dilewatkan orang adalah reboot. libssl yang sudah diperbaiki di disk tidak berguna apa-apa bagi proses yang sudah memetakan versi lamanya saat start-up, dan update kernel sama sekali tidak berpengaruh sampai Anda benar-benar boot ke dalamnya. Anda bisa menerima reboot tanpa pengawasan pada jendela waktu yang Anda pilih sendiri, atau memasang needrestart dan membiarkannya memberi tahu Anda service mana saja yang masih berjalan dengan library yang sudah terhapus — tapi lakukan salah satunya. “Pembaruan otomatis sudah aktif” sementara uptime menunjukkan 340 hari adalah ilusi yang menenangkan, dan itulah ilusi paling umum yang kami temui.

fail2ban membaca log Anda, mendeteksi kegagalan berulang dari satu alamat, dan mem-banned-nya untuk sementara waktu. CrowdSec melakukan hal yang sama dan membagikan verdict-nya lewat jaringan sesama pengguna, sehingga Anda bisa memblokir alamat yang sudah berulah di tempat lain bahkan sebelum ia sampai ke server Anda. Keduanya adalah software yang bagus. Tapi tidak satu pun benar-benar melakukan apa yang dikira kebanyakan orang, pada server SSH yang sudah keys-only.

Begitu PasswordAuthentication bernilai no, brute-force SSH tidak mungkin berhasil. Bukan “kecil kemungkinan berhasil” — tapi memang tidak ada jalur kode yang memungkinkannya. Karena itu, mem-banned alamat setelah lima kegagalan sama sekali tidak mencegah apa pun; itu hanya mengurangi volume log dan sedikit pemakaian CPU. Itu manfaat yang nyata, hanya saja bukan manfaat keamanan, dan kompromi ini tidak gratis: jail yang ditulis dengan buruk dan mengamati log yang salah justru sudah lebih sering mengunci administrator keluar dari server mereka sendiri, dibanding mengunci attacker.

Tempat di mana tool-tool ini benar-benar pantas digunakan adalah satu lapis di atasnya, pada service yang benar-benar Anda ekspos: form login, admin WordPress, API dengan rate limit, mail server dengan SMTP AUTH. Semua itu memang menerima password, memang bisa di-brute-force, dan ban list adalah kontrol yang tepat untuk itu. Jadi kesimpulan kami sempit dan spesifik. Lewati jail untuk SSH. Pasang CrowdSec atau fail2ban di depan sesuatu yang punya kolom password. Dan apa pun yang Anda pilih, whitelist dulu alamat manajemen Anda sendiri — ignoreip ada justru untuk malam yang kalau tidak, akan Anda kenang karena alasan yang salah.

Pencegahan adalah apa yang bisa Anda lakukan dalam satu jam. Deteksi adalah apa yang memberi tahu Anda bahwa satu jam itu ternyata tidak cukup. Tidak perlu rumit, dan pada satu server saja, tiga hal murah sudah mencakup sebagian besar kebutuhan.

Simpan log-nya. Pada banyak image, journal tersimpan di /run dan menguap saat reboot, artinya rekam jejak sebuah insiden justru hilang tepat saat reboot yang menyusul insiden itu. Membuat /var/log/journal adalah perbaikan satu baris dan hal paling bernilai di bagian ini.

Minta diberi tahu soal setiap login. Satu baris di /etc/ssh/sshrc yang memanggil logger di setiap awal sesi tidak memakan biaya apa pun dan memberi Anda rekam jejak yang bersih dan mudah di-grep, terpisah dari riuhnya log sshd sendiri. Ada satu catatan yang sering menjebak orang: sshd menjalankan ~/.ssh/rc alih-alih /etc/ssh/sshrc ketika user punya file itu, sehingga file system-wide justru dilewati tepat untuk akun yang paling mungkin memiliki dotfile custom. Kalau Anda butuh hook yang tidak bisa disembunyikan seperti ini, gunakan pam_exec sebagai gantinya.

Ketahui seperti apa filesystem Anda di hari pertama. AIDE mencatat hash dari binary, library, dan unit file Anda, lalu melaporkan apa saja yang berubah sejak itu. Masalah mendasarnya, yang biasanya diabaikan: database yang disimpan di mesin yang sedang ia awasi bisa saja dibuat ulang oleh siapa pun yang berhasil mengompromikannya, dan sejak saat itu pemeriksaan akan selamanya melaporkan “tidak ada perubahan”. Salin database itu keluar dari mesin, atau setidaknya catat hash-nya di tempat lain, dan tool ini baru sepadan dengan dua puluh menit yang Anda habiskan. Kalau dibiarkan begitu saja di tempatnya, itu cuma selimut penenang.

Prinsip umumnya layak dinyatakan tersendiri: log yang tidak bisa Anda percaya adalah log yang berada di mesin yang sudah dikompromikan. Apa pun yang benar-benar ingin Anda andalkan — journal, database integritas, backup — sebaiknya punya salinan di tempat yang tidak dikuasai oleh attacker yang sama. Server kecil kedua di yurisdiksi lain adalah jawaban yang sah untuk ini, dan yang seharga lima dolar pun sudah cukup.

Semua yang di atas adalah pekerjaan level perimeter, dan penting untuk jelas soal batasannya, supaya Anda tidak salah mengira pintu depan yang terkunci sebagai brankas.

Ini tidak melindungi data pada mesin yang sedang berjalan. Kernel yang sudah di-harden dan firewall yang tertutup sama sekali tidak relevan bagi siapa pun yang punya akses hypervisor, maupun terhadap isi RAM selama mesin itu menyala. Kalau kekhawatiran Anda adalah disk saat server dimatikan, disita, atau dinonaktifkan, itu ranahnya enkripsi disk, dan itu prosedur yang berbeda dengan mode kegagalan yang berbeda pula — lihat mengenkripsi disk VPS dengan LUKS.

Ini tidak membuat Anda anonim. Server bisa saja di-harden dengan sempurna dan tetap membocorkan siapa pemiliknya, lewat record WHOIS, SSH key yang dipakai ulang, tag analytics, client SSH yang connect dari rumah tanpa hop tambahan, atau sertifikat yang menghubungkan dua identitas sekaligus. Membayar dengan Monero lalu login dari alamat pribadi Anda sendiri membatalkan seluruh manfaat pembayaran itu. Mode kegagalan itu punya halamannya sendiri: kesalahan-kesalahan yang men-deanonimisasi Anda.

Ini tidak memperbaiki aplikasi Anda. SQL injection, admin endpoint tanpa autentikasi, atau dependency dengan backdoor sama sekali tidak peduli dengan pengaturan sshd Anda. Sebagian besar kompromi pada server yang dikelola dengan baik justru datang lewat port yang sengaja, dengan penuh kesadaran, Anda buka untuk service yang Anda tulis atau pasang sendiri.

Ini bukan backup. Ransomware, rm -rf dengan variabel yang ternyata kosong, dan upgrade yang gagal, semuanya berakhir dengan cara yang sama. Buat salinan, taruh di tempat lain, dan lakukan restore darinya setidaknya sekali sebelum Anda benar-benar membutuhkannya — disiplin yang sama yang membuat pindah ke host lain bisa dilalui dengan selamat, juga membuat hari Selasa yang buruk bisa dilalui dengan selamat.

Tidak satu pun dari ini menjadi alasan untuk tidak melakukan jam itu. Ini justru alasan untuk tahu persis apa yang sudah dibeli oleh jam itu.