Audit Keamanan VPS: Periksa Port, User, dan Update Otomatis

VPS yang baru dibeli biasanya langsung dipakai deploy aplikasi, lalu dilupakan. Padahal dalam hitungan jam, alamat IP VPS sudah mulai dipindai bot dari seluruh dunia. Mereka tidak menargetkan Anda secara khusus — mereka memindai semua orang, mencari port terbuka, password lemah, dan paket yang belum di-patch.

Audit berkala adalah cara termurah untuk menutup celah itu. Anda tidak butuh tool mahal. Tiga pemeriksaan di bawah ini cukup dilakukan sebulan sekali, dan semuanya bisa selesai dalam 15 menit.

1. Periksa port yang terbuka

Port yang terbuka adalah pintu masuk. Setiap port yang listen berarti ada layanan yang bisa diajak bicara dari luar. Prinsipnya sederhana: kalau tidak dipakai, tutup.

Lihat dulu apa saja yang sedang listen di server Anda:

sudo ss -tulpn

Outputnya menunjukkan protokol (TCP/UDP), alamat, port, dan proses pemiliknya. Yang perlu diperhatikan:

  • Port yang listen di 0.0.0.0 atau * berarti bisa diakses dari internet. Wajar untuk 80 (HTTP) dan 443 (HTTPS) kalau server melayani web, serta 22 (SSH) kalau Anda mengelolanya dari jauh.
  • Port yang listen di 127.0.0.1 hanya bisa diakses dari dalam server. Ini posisi yang benar untuk database, Redis, atau panel internal.
  • Port yang tidak Anda kenali adalah temuan audit. Cari tahu prosesnya (ps aux | grep <nama-proses>), lalu putuskan: dipakai atau dimatikan.

Contoh temuan yang sering muncul: database yang listen di 0.0.0.0:5432 atau 0.0.0.0:3306. Kalau database hanya dipakai aplikasi di server yang sama, ikat ke localhost lewat konfigurasinya. Jangan mengandalkan "tidak ada yang tahu IP saya" — bot memindai seluruh rentang IP, bukan menebak.

Setelah tahu apa yang listen, cocokkan dengan firewall:

sudo ufw status verbose

Kalau UFW belum aktif, ini saatnya mengaktifkannya. Aturan minimal yang masuk akal untuk server web:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Satu peringatan penting: pastikan aturan SSH (port 22, atau port kustom Anda) sudah diizinkan sebelum ufw enable. Salah urutan berarti Anda mengunci diri sendiri keluar dari server.

Untuk memastikan pandangan dari luar sama dengan yang Anda kira, cek juga dari internet. Dari laptop Anda, pindai port server dengan nmap:

nmap -Pn -p 22,80,443,3306,5432,6379 <IP-server-Anda>

Kalau ada port yang terbuka di hasil nmap tapi tidak Anda izinkan, itu temuan yang harus segera ditindaklanjuti.

2. Periksa user dan akses SSH

Celah kedua yang paling sering dieksploitasi adalah akun. Akun lama, akun percobaan, atau akun dengan password lemah adalah undangan terbuka.

Daftar semua user manusia di server (biasanya UID 1000 ke atas):

getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}'

Setiap nama di daftar itu harus bisa Anda jelaskan: siapa orangnya, untuk apa akunnya. Akun yang tidak dikenal, akun percobaan dari instalasi lama, atau akun mantan rekan kerja yang sudah tidak terlibat — kunci atau hapus:

sudo usermod -L <username>   # kunci login (bisa dibuka lagi)
sudo deluser --remove-home <username>  # hapus permanen, beserta home-nya

Perintah kedua bersifat destruktif, jadi pakai hanya kalau Anda yakin akun itu memang tidak dibutuhkan.

Selanjutnya, periksa siapa yang punya hak sudo:

getent group sudo

Hanya user yang benar-benar mengelolanya yang boleh ada di grup ini. Prinsipnya sama: hak akses diberikan seminimal mungkin.

Lalu periksa kunci SSH yang terdaftar. Setiap kunci di authorized_keys adalah sebuah pintu masuk tanpa password:

sudo grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

Untuk setiap kunci, tanyakan: perangkat siapa ini, masih dipakai atau tidak? Kunci dari laptop lama yang sudah dijual atau dari rekan yang sudah pergi harus dihapus dari file tersebut. Kunci SSH tidak kedaluwarsa sendiri — kalau Anda tidak membersihkannya, ia berlaku selamanya.

Terakhir, periksa konfigurasi SSH-nya sendiri di /etc/ssh/sshd_config. Tiga pengaturan ini layak Anda terapkan:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Artinya: login hanya dengan kunci SSH, root tidak boleh login dengan password. Setelah mengubah file, uji konfigurasinya dan restart layanannya:

sudo sshd -t
sudo systemctl restart ssh

Jangan menutup sesi SSH yang sedang aktif sebelum menguji login baru di terminal kedua. Kalau konfigurasi salah, sesi lama adalah jalan Anda kembali.

Untuk gambaran siapa saja yang belakangan login, periksa log autentikasi:

sudo grep "Accepted" /var/log/auth.log | tail -20
sudo last -20

Login dari IP atau jam yang tidak Anda kenali adalah sinyal untuk diselidiki lebih lanjut, bukan diabaikan.

3. Pastikan update keamanan berjalan otomatis

Celah ketiga adalah paket yang usang. Sebagian besar eksploitasi massal menyerang kerentanan yang patch-nya sudah tersedia berminggu-minggu — korbannya hanya server yang belum di-update.

Ubuntu menyediakan unattended-upgrades untuk ini. Periksa apakah ia terpasang dan aktif:

sudo apt install unattended-upgrades
sudo systemctl status unattended-upgrades --no-pager

Lalu pastikan konfigurasinya mengizinkan update keamanan otomatis. Buka /etc/apt/apt.conf.d/50unattended-upgrades dan pastikan baris berikut tidak dikomentari:

"${distro_id}:${distro_codename}-security";

Dan di /etc/apt/apt.conf.d/20auto-upgrades, pastikan jadwalnya aktif:

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

Artinya: daftar paket diperbarui setiap hari, dan update keamanan dipasang otomatis setiap hari. Kalau Anda ingin melihat apa yang sudah dipasang otomatis sejauh ini, lognya ada di /var/log/unattended-upgrades/.

Satu hal yang perlu dipahami: unattended-upgrades secara default hanya memasang update dari repositori keamanan. Update fitur dari aplikasi Anda tetap tanggung jawab Anda — dan itu memang seharusnya, karena update aplikasi bisa mengubah perilaku dan butuh pengujian. Tapi untuk patch keamanan sistem, otomatis adalah pilihan yang benar. Server yang patch-nya tertunda berbulan-bulan jauh lebih berisiko daripada server yang reboot sesekali karena kernel baru.

Periksa juga apakah ada update keamanan yang tertunda saat ini:

sudo apt update && apt list --upgradable 2>/dev/null | grep -i security

Kalau daftarnya panjang, itu backlog yang perlu dibereskan sekarang, bukan minggu depan. Untuk kernel dan paket sistem, pasang dan jadwalkan reboot di jam sepi:

sudo apt upgrade -y
sudo reboot

Checklist audit bulanan

Salin daftar ini dan jalankan sebulan sekali, atau simpan sebagai pengingat berulang:

  • ss -tulpn — tidak ada port tak dikenal yang listen di 0.0.0.0
  • ufw status verbose — firewall aktif, aturan sesuai kebutuhan
  • Daftar user UID ≥ 1000 — semua dikenal, tidak ada akun yatim
  • Grup sudo — hanya admin yang sah
  • authorized_keys — tidak ada kunci dari perangkat yang sudah tidak dipakai
  • sshd_config — login password mati, root tidak bisa login dengan password
  • Log auth.log dan last — tidak ada login mencurigakan
  • unattended-upgrades — aktif dan sudah memasang patch keamanan terbaru
  • Tidak ada backlog update keamanan yang tertunda

Sembilan baris itu tidak akan membuat server Anda kebal — tidak ada yang kebal. Tapi mereka menutup tiga jalur masuk yang paling sering dipakai bot dan penyerang oportunis: layanan yang tidak perlu, akun yang terlupakan, dan patch yang tertunda. Dan karena pemeriksaannya hanya 15 menit sebulan sekali, tidak ada alasan untuk melewatkannya.

Komentar

Posting Komentar