Cara Mengamankan VPS: 10 Langkah Hardening Berurutan

Cara mengamankan VPS adalah rangkaian langkah berurutan, bukan satu pengaturan tunggal: buat pengguna non-root berhak sudo, pindah ke autentikasi kunci SSH lalu matikan login kata sandi, batasi port dengan firewall, pasang fail2ban, aktifkan pembaruan keamanan otomatis, lalu jadwalkan backup dan audit. Urutannya penting karena setiap langkah menutup celah yang ditinggalkan langkah sebelumnya.

Mengapa VPS Baru Perlu Diamankan Sejak Jam Pertama?

Begitu VPS Anda aktif dan mendapat alamat IP publik, ia langsung terlihat oleh pemindai otomatis yang menyisir seluruh ruang alamat internet. Percobaan login SSH ke akun root dengan kata sandi umum biasanya mulai muncul di log dalam hitungan menit, bukan hari, dan itu terjadi tanpa ada yang menargetkan Anda secara khusus.

Panduan keamanan server dari NIST menempatkan pengerasan konfigurasi, pembatasan layanan, dan pemantauan log sebagai fondasi, bukan sebagai penyempurnaan yang bisa ditunda (NIST SP 800-123). Logikanya sederhana: server yang sudah dibobol tidak bisa diamankan dengan menambah aturan, ia harus dibangun ulang.

Dari pengalaman tim kami menangani VPS klien, urutan kejadian yang paling sering terjadi bukan peretasan canggih, melainkan kombinasi paling membosankan: root masih bisa login dengan kata sandi, kata sandinya dipakai ulang dari layanan lain, dan tidak ada yang membaca log. Tiga hal itu bisa ditutup dalam waktu kurang dari satu jam.

Prioritas Langkah: Dampak Dibanding Usaha

Kalau waktu Anda terbatas, kerjakan dari atas tabel ini. Empat baris pertama sudah menutup sebagian besar jalur serangan otomatis yang benar-benar terjadi setiap hari.

Langkah 1: Membuat Pengguna Non-root dengan Hak Sudo

Bekerja sebagai root sepanjang waktu menghapus jaring pengaman terakhir Anda. Satu salah ketik pada perintah penghapusan berkas langsung berlaku ke seluruh sistem, dan tidak ada catatan siapa yang menjalankan apa karena semuanya tercatat sebagai root.

Buat pengguna baru, masukkan ke grup sudo, lalu tirukan kunci SSH yang sudah ada:

sudo adduser namapengguna
sudo usermod -aG sudo namapengguna
sudo rsync --archive --chown=namapengguna:namapengguna ~/.ssh /home/namapengguna

Baris ketiga penting dan sering dilupakan. Kalau kunci SSH tidak ikut disalin, Anda akan mematikan login root sebelum pengguna baru bisa masuk, dan hasilnya Anda terkunci dari server sendiri. Buka sesi terminal kedua untuk menguji login pengguna baru sebelum menutup sesi yang sedang berjalan.

Langkah 2: Mengunci SSH dengan Kunci Publik

Autentikasi kunci publik menggantikan kata sandi yang bisa ditebak dengan pasangan kunci kriptografi. Buat pasangan kunci di komputer Anda, bukan di server, memakai ssh-keygen dari OpenSSH (man ssh-keygen):

ssh-keygen -t ed25519 -C "laptop-kerja"
ssh-copy-id namapengguna@alamat-ip-vps

Beri frasa sandi pada kunci privatnya. Kunci tanpa frasa sandi berarti siapa pun yang menyalin berkas kunci dari laptop Anda langsung mendapat akses penuh ke server. Setelah login dengan kunci terbukti berhasil, baru lanjut ke langkah berikutnya.

Langkah 3: Mengeraskan Konfigurasi sshd

Semua pengaturan berikut ada di /etc/ssh/sshd_config. Nilai bawaannya sengaja permisif supaya server baru bisa diakses siapa pun yang punya kata sandi, dan itulah yang perlu Anda ubah.

Nilai bawaan pada tabel di atas mengikuti dokumentasi resmi OpenSSH (man sshd_config, versi Ubuntu tersedia di manpages.ubuntu.com). Perhatikan bahwa PermitRootLogin bawaannya sudah prohibit-password, artinya root tidak bisa masuk dengan kata sandi tapi masih bisa dengan kunci. Menyetelnya ke no menutup sisa celah itu.

Setelah menyunting, uji sintaksnya sebelum memuat ulang layanan:

sudo sshd -t
sudo systemctl reload ssh

Soal mengganti port SSH, jujur saja: itu keamanan lewat penyamaran, bukan keamanan sesungguhnya. Pemindai yang tekun akan menemukan port mana pun. Manfaat nyatanya adalah log Anda jadi jauh lebih bersih sehingga percobaan yang benar-benar bertarget lebih mudah terlihat. Kerjakan setelah tiga langkah pertama, bukan sebagai gantinya.

Langkah 4: Firewall dengan UFW atau nftables

Firewall memindahkan pertanyaan dari "layanan apa yang sedang mendengarkan" menjadi "port apa yang saya izinkan". Perbedaannya besar, karena layanan bisa muncul tanpa Anda sadari setelah memasang paket baru.

Pada Ubuntu, UFW menjadi lapisan pengelola aturan yang paling ringkas. Dokumentasi resmi Ubuntu Server menunjukkan perintah dasarnya berupa sudo ufw enable, sudo ufw allow 22, dan sudo ufw status verbose untuk memeriksa hasilnya (Ubuntu Server Guide: Firewalls). Urutan yang aman:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Izinkan port SSH sebelum mengaktifkan firewall, bukan sesudahnya. Kalau Anda mengaktifkan kebijakan tolak semua lebih dulu, sesi SSH yang sedang berjalan akan terputus dan Anda perlu masuk lewat konsol penyedia untuk memperbaikinya.

Perlu diingat bahwa firewall di dalam server tidak menahan serangan volumetrik. Paketnya tetap sampai ke antarmuka jaringan Anda dan tetap memakan bandwidth. Untuk itu Anda butuh mitigasi di sisi jaringan, seperti dibahas di panduan DDoS protection.

Langkah 5: Fail2ban untuk Menahan Percobaan Berulang

Fail2ban membaca berkas log, mengenali pola kegagalan autentikasi, lalu memblokir alamat IP sumbernya untuk sementara. Ini bukan pengganti kunci SSH, melainkan pengurang kebisingan dan beban sumber daya (situs resmi Fail2ban).

Jangan menyunting jail.conf secara langsung. Dokumentasinya menyebut berkas jail.local dan jail.d/*.local sebagai tempat menaruh penyesuaian Anda, sehingga tidak tertimpa saat paket diperbarui (man jail.conf). Tiga parameter yang perlu Anda pahami:

• maxretry: jumlah kegagalan yang harus terjadi sebelum sebuah IP diblokir.
• findtime: rentang waktu ke belakang tempat kegagalan itu dihitung.
• bantime: lama pemblokiran berlaku.

Contoh isi /etc/fail2ban/jail.local yang wajar untuk VPS pribadi:

[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h

Periksa hasilnya dengan sudo fail2ban-client status sshd. Kalau angka kegagalan tidak pernah bertambah padahal log penuh percobaan, biasanya penyebabnya salah menunjuk berkas log atau salah nama jail, bukan fail2ban yang tidak bekerja.

Langkah 6: Pembaruan Keamanan Otomatis

Celah yang paling sering dipakai bukan celah baru, melainkan celah lama yang tambalannya sudah tersedia tapi belum dipasang. Ubuntu sudah memasang paket unattended-upgrades secara bawaan dan menerapkan pembaruan keamanan tanpa campur tangan pengguna (Ubuntu Server Guide: Automatic updates).

Yang perlu Anda periksa adalah apakah fungsi itu benar-benar menyala. Dua opsi pengendalinya ada di /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Nilai berarti jumlah hari, dan nilai 0 mematikan fungsinya. Pilihan repositori sumber pembaruan diatur di bagian Allowed-Origins pada /etc/apt/apt.conf.d/50unattended-upgrades. Dokumentasi Ubuntu memberi peringatan penting: menambahkan repositori pihak ketiga ke sistem tidak otomatis membuatnya ikut diperbarui oleh unattended-upgrades, jadi paket dari repositori luar tetap perlu Anda pantau sendiri.

Pemicunya berupa timer systemd apt-daily.timer dan apt-daily-upgrade.timer, dan log terperincinya tersimpan di /var/log/unattended-upgrades. Baca log itu sebulan sekali. Pembaruan otomatis yang gagal berkali-kali secara diam-diam lebih berbahaya daripada tidak ada pembaruan otomatis, karena Anda merasa sudah aman.

Langkah 7: Mematikan Layanan yang Tidak Dipakai

Setiap layanan yang mendengarkan di sebuah port adalah pintu tambahan yang perlu Anda rawat. Image VPS bawaan sering menyertakan layanan yang tidak Anda butuhkan sama sekali. Mulai dengan melihat kenyataannya:

sudo ss -tulpn
systemctl list-units --type=service --state=running

Baca kolom alamat pada keluaran perintah pertama. Layanan yang terikat pada 127.0.0.1 hanya bisa diakses dari dalam server, sedangkan yang terikat pada 0.0.0.0 terbuka ke seluruh internet. Basis data adalah pelanggaran paling umum di sini: MySQL atau PostgreSQL yang mendengarkan di semua antarmuka padahal hanya dipakai aplikasi di mesin yang sama.

Untuk layanan yang memang tidak diperlukan, matikan sekaligus cegah menyala lagi setelah reboot dengan sudo systemctl disable --now namalayanan. Prinsip pembatasan layanan ke yang benar-benar dibutuhkan ini juga menjadi salah satu rekomendasi inti pada panduan keamanan server NIST yang dirujuk di atas.

Langkah 8: Backup Terjadwal yang Sudah Diuji Pulih

Backup adalah satu-satunya langkah pada daftar ini yang menolong Anda setelah semua langkah lain gagal. Karena itu ia layak diperlakukan sebagai kontrol keamanan, bukan sebagai urusan operasional biasa.

Tiga syarat yang membedakan backup berguna dari backup yang cuma menenangkan hati: salinannya berada di luar VPS yang sama, jadwalnya berjalan otomatis tanpa perlu diingat, dan proses pemulihannya pernah Anda coba sampai berhasil. Backup yang belum pernah diuji pulih statusnya masih hipotesis, bukan jaminan.

Perhatikan juga hak akses kredensial backup. Kalau kunci penyimpanan cadangan tersimpan di server yang sama dan bisa dipakai menghapus, penyerang yang masuk bisa menghapus backup Anda sekalian. Pakai kredensial dengan izin tambah saja, atau aktifkan penguncian versi di sisi penyimpanan. Langkah teknisnya bisa Anda ikuti di panduan backup website.

Langkah 9: Monitoring Login dan Perilaku Server

Pengerasan mencegah, pemantauan memberi tahu. Tanpa lapisan kedua, penyusupan yang berhasil bisa berlangsung berbulan-bulan tanpa terlihat. Yang paling sederhana dan paling berguna:

• Riwayat login: last -a untuk sesi yang berhasil dan sudo lastb untuk yang gagal.
• Log autentikasi: sudo journalctl -u ssh --since "24 hours ago".
• Sesi yang sedang aktif: who dan w.
• Perubahan sumber daya mendadak: lonjakan CPU atau trafik keluar tanpa sebab jelas sering menjadi tanda pertama server dipakai orang lain.

Yang membuat pemantauan bekerja adalah pemberitahuan, bukan dasbor yang harus Anda buka sendiri. Atur peringatan yang mengirim pesan ke email atau aplikasi obrolan Anda saat ada login berhasil dari alamat IP baru. Untuk penyiapannya, lihat panduan monitoring server.

Langkah 10: Audit Berkala dengan Lynis

Setelah semua langkah di atas, Anda butuh pemeriksa independen. Lynis adalah alat audit keamanan untuk sistem Linux dan Unix yang memeriksa konfigurasi lalu memberi daftar saran perbaikan (CISOfy Lynis). Jalankan pemindaian penuh dengan:

sudo lynis audit system

Keluarannya berupa peringatan dan saran, plus indeks pengerasan sebagai angka ringkas. Perlakukan angka itu sebagai penanda arah, bukan target yang harus dikejar. Beberapa saran tidak cocok untuk peran server Anda, dan menerapkannya membabi buta bisa mematikan layanan yang memang dibutuhkan. Baca alasan di balik setiap saran sebelum menuruti.

Frekuensi yang masuk akal: sekali setelah pengerasan awal sebagai garis dasar, lalu setiap kali Anda menambah layanan baru. Simpan laporannya supaya Anda bisa membandingkan perubahan konfigurasi antar waktu. Untuk cakupan yang lebih luas dari sisi aplikasi web, lengkapi dengan pemindaian malware dan langkah pada panduan keamanan website.

Kesimpulan

Mengamankan VPS bukan proyek sekali jadi, tapi empat langkah pertama pada tabel prioritas sudah menutup sebagian besar serangan otomatis yang benar-benar Anda hadapi setiap hari: kunci SSH, pengguna non-root, firewall tolak semua, dan pembaruan otomatis. Semuanya bisa dikerjakan dalam satu sesi kerja.

Setelah itu, yang menentukan justru kebiasaan: membaca log pembaruan otomatis, mengecek riwayat login, dan menguji pemulihan backup. Kalau server Anda pernah bermasalah, mulai dari langkah penanganan situs yang kena hack, lalu bangun ulang dengan urutan di artikel ini. Baru menyiapkan VPS baru? Ikuti panduan setup VPS Ubuntu lalu terapkan pengerasan ini sebelum memasang aplikasi apa pun.

Butuh VPS yang sudah siap dikeraskan dengan akses root penuh? Lihat pilihan paket di halaman VPS HostingEkspres. Kalau Anda juga berencana memakainya sebagai jalur akses tim, baca VPS untuk VPN pribadi.

Pertanyaan Umum (FAQ)