Terakhir Kapan VPS Di-patch? Cara Mengatur Update Keamanan Otomatis

Ada satu pekerjaan di VPS yang paling gampang ditunda: menambal keamanan. Server dipasang sekali, aplikasi jalan, dan bulan-bulan berikutnya kita hanya menyentuhnya kalau ada yang rusak. Padahal celah yang dipakai penyerang hampir selalu celah lama — yang sebenarnya sudah ditambal pihak upstream berbulan-bulan sebelumnya, hanya belum masuk ke server kita. Di sinilah update keamanan otomatis VPS berperan: bukan fitur mewah, melainkan pengaman dasar yang seharusnya menyala sejak hari pertama.

Kabar baiknya, di Ubuntu mekanismenya sudah resmi dan bawaan, namanya unattended-upgrades. Oke, lanjuutt.. kita atur sama-sama supaya keamanan server tidak lagi bergantung pada ingatan kita.

Kenapa Patch Otomatis Penting untuk VPS yang Jarang Disentuh

Dokumentasi resmi Ubuntu Server menyebut hal ini tanpa basa-basi: Ubuntu menerapkan pembaruan keamanan secara otomatis tanpa interaksi pengguna, lewat paket unattended-upgrades yang sudah terpasang secara default. Jadi di banyak VPS Ubuntu, pekerjaan ini sebenarnya sudah berjalan di belakang layar sejak instalasi — kita cuma belum pernah memeriksanya.

Masalahnya, tidak semua kondisi seideal itu:

Image VPS bisa berbeda. Penyedia hosting kadang memakai image minimal, atau distribusi selain Ubuntu yang tidak mengaktifkannya secara bawaan.
Ada yang sengaja dimatikan. Banyak panduan lama menyarankan mematikan auto-update karena dianggap “bikin server restart sendiri”, lalu tidak pernah dinyalakan lagi.
Cakupannya terbatas. Patch otomatis hanya menyentuh paket sistem. Container Docker tidak ikut ter-update lewat jalur ini — itu ranah alat lain seperti Watchtower.
Setelan bawaannya konservatif. Yang otomatis hanyalah pembaruan keamanan, bukan fitur baru. Kalau kita butuh lebih, harus diatur manual.

Karena itu langkah pertamanya bukan menulis konfigurasi, melainkan memeriksa keadaan sekarang.

Cek Dulu: Apakah VPS Kita Sudah Diurus Otomatis?

Tiga perintah ini cukup untuk tahu posisi kita:


dpkg -l unattended-upgrades | tail -1
cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl list-timers 'apt-daily*'

Cara membaca hasilnya:

Baris pertama harus menampilkan paket dengan status ii (terpasang). Kalau kosong, paketnya belum ada.
20auto-upgrades berisi dua opsi: APT::Periodic::Update-Package-Lists dan APT::Periodic::Unattended-Upgrade. Nilai "1" berarti dijalankan sekali sehari, "0" berarti mati, "2" berarti setiap dua hari, dan seterusnya — angkanya dibaca sebagai jumlah hari.
systemctl list-timers memperlihatkan dua unit timer yang menggerakkan semuanya: apt-daily.timer (menyegarkan daftar paket, setara apt update) dan apt-daily-upgrade.timer (memasang pembaruan, setara apt upgrade). Keduanya menjalankan skrip /usr/lib/apt/apt.systemd.daily.

Satu perilaku yang perlu diketahui: kalau VPS mati saat jadwalnya tiba, timer akan mengejar jadwal yang terlewat begitu server menyala — masih dengan jeda acak RandomizedDelaySec. Untuk VPS yang sering dimatikan dan dinyalakan hanya untuk pekerjaan singkat, ini bisa merepotkan karena proses instalasi paket lain jadi menunggu. Obatnya ada di systemctl edit apt-daily.timer dan systemctl edit apt-daily-upgrade.timer, lalu tambahkan:


[Timer]
Persistent=false

Dengan begitu, jadwal yang terlewat tidak dikejar saat boot.

Langkah 1 — Pasang dan Aktifkan Paketnya

Kalau pengecekan tadi menunjukkan paketnya belum ada:


sudo apt update
sudo apt install unattended-upgrades

Di Debian, paket sering sudah terpasang tetapi belum diaktifkan. Wiki Debian menyarankan menjalankan:


sudo dpkg-reconfigure unattended-upgrades

Perintah itu memunculkan pertanyaan apakah pembaruan stabil mau diunduh dan dipasang otomatis. Jawab Yes — jawaban itu yang menuliskan opsi "1" ke 20auto-upgrades. Di Ubuntu, dokumentasinya menyebut setelah instalasi pembaruan keamanan langsung aktif, termasuk cakupan ESM (Expanded Security Maintenance) bila tersedia di sistem tersebut.

Langkah 2 — Kunci Jadwal di 20auto-upgrades

Berkas /etc/apt/apt.conf.d/20auto-upgrades mengatur kapan semuanya berjalan:


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

Isi default ini sudah benar untuk sebagian besar VPS. Yang perlu diwaspadai justru kebalikannya: kalau kita pernah mengikuti tutorial “matikan auto-update”, di sinilah kedua angka itu menjadi "0", dan seluruh mekanisme di artikel ini berhenti tanpa error apa pun. Sunyi, tanpa keluhan, dan baru ketahuan saat audit keamanan.

Langkah 3 — Tentukan Sumber Paket di 50unattended-upgrades

Berkas /etc/apt/apt.conf.d/50unattended-upgrades mengatur apa yang boleh dipasang otomatis. Bagian terpentingnya Allowed-Origins:


Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
//  "${distro_id}:${distro_codename}-updates";
//  "${distro_id}:${distro_codename}-proposed";
//  "${distro_id}:${distro_codename}-backports";
};

Tanda // adalah komentar, jadi baris -updates, -proposed, dan -backports tidak dievaluasi. Artinya: hanya pembaruan keamanan yang masuk otomatis. Kalau kita ingin pembaruan biasa ikut, hapus // di baris -updates — dengan konsekuensi risiko regresi yang lebih besar.

Kalau VPS-nya Debian, kunci yang dipakai bukan Allowed-Origins melainkan Unattended-Upgrade::Origins-Pattern, dan paket Debian sudah mengisinya dengan tiga baris: origin=Debian,codename=${distro_codename},label=Debian, origin=Debian,codename=${distro_codename},label=Debian-Security, dan origin=Debian,codename=${distro_codename}-security,label=Debian-Security. Jangan menimpanya dengan blok di atas. Dua baris pertama aktif secara bawaan, jadi di Debian pembaruan paket biasa pun ikut terpasang otomatis; kalau mau ketat keamanan saja, komentari baris label=Debian dan sisakan yang Debian-Security.Ini juga sumber kesalahpahaman yang paling sering terjadi: menambahkan repositori pihak ketiga tidak membuat paketnya ikut ter-update otomatis. Dokumentasi Ubuntu menegaskan hal itu secara khusus. Supaya sebuah PPA atau repo ikut dipantau, nilai Origin-nya harus ditambahkan ke daftar di atas. Nilai itu bisa dibaca dari berkas InRelease di /var/lib/apt/lists/ setelah apt update, pada baris yang diawali Origin:. Untuk PPA Launchpad formatnya LP-PPA-<user>-<nama>.

Langkah 4 — Blokir Paket yang Tidak Boleh Bergerak Sendiri

Ada kalanya satu paket lebih baik ditambal manual, misalnya karena aplikasi kritis kita bergantung pada versi tertentu. Gunakan Unattended-Upgrade::Package-Blacklist, isinya ekspresi reguler Python, satu per baris:


Unattended-Upgrade::Package-Blacklist {
    "libc6$";
    "libc-bin$";
};

Tanda $ menandai akhir nama paket, jadi libc6$ mengenai libc6 tetapi tidak mengenai glibc6. Pencocokan selalu dianggap diawali ^, sehingga "linux-" akan memblokir semua paket yang namanya diawali linux-. Hati-hati: memblokir satu paket bisa menahan pembaruan lain yang bergantung padanya, dan dokumentasinya memperingatkan hal itu secara eksplisit.

Langkah 5 — Putuskan Kebijakan Reboot

Sebagian pembaruan — kernel dan libc, umumnya — baru benar-benar berlaku setelah server restart. Di sinilah keputusan pentingnya:

Unattended-Upgrade::Automatic-Reboot "false"; — nilai default. Server tidak akan restart sendiri.
Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; — ini default-nya, artinya restart tetap dilakukan meski ada pengguna yang sedang login. Untuk server produksi, ini kandidat pertama yang perlu diubah.
Unattended-Upgrade::Automatic-Reboot-Time "now"; — waktu restart. Bisa "now", format hh:mm menurut zona waktu lokal server, atau offset seperti "+30" menit.

Pilihan yang sering dipakai: biarkan Automatic-Reboot menyala hanya kalau VPS benar-benar stateless dan kita punya monitoring yang bisa memastikan server hidup lagi. Kalau tidak, matikan reboot otomatis, lalu jadwalkan sendiri. Penandanya mudah dilihat: bila berkas /var/run/reboot-required ada, artinya ada pembaruan yang menunggu restart. Log resmi Ubuntu memperlihatkan baris WARNING Found /var/run/reboot-required, rebooting saat mekanisme ini bekerja.

Langkah 6 — Lindungi Layanan Kritis dari Restart Mendadak

Banyak pembaruan tidak butuh reboot, hanya butuh service di-restart agar memakai pustaka baru. Ini tugas paket needrestart, yang dipanggil unattended-upgrades setelah pemasangan selesai. Sejak Ubuntu 24.04 LTS, needrestart merestart service terdampak secara otomatis secara default.

Di VPS produksi, restart otomatis di jam yang tidak kita duga bisa jadi masalah tersendiri. Solusinya bukan mematikan semuanya, melainkan mengecualikan service tertentu lewat berkas di /etc/needrestart/conf.d/ — jangan mengedit needrestart.conf langsung:


$nrconf{override_rc} = {
    qr(^nginx\.service$) => 0,
};

Nilai 0 berarti service itu tidak boleh direstart otomatis; sisanya tetap ditangani. Kalau kita ingin semua restart dilakukan manual, setel $nrconf{restart} menjadi 'l' (hanya mendaftar) alih-alih 'a' (otomatis).

Langkah 7 — Uji Kering, Lalu Baca Log

Jangan menunggu jadwal besok pagi untuk tahu konfigurasi kita benar. Jalankan simulasi:


sudo unattended-upgrade --dry-run -v

Opsi --dry-run hanya memperagakan, tidak memasang apa pun, sedangkan -v menampilkan detail. Di keluarannya kita bisa membaca baris Allowed origins are: ... — di situlah terbukti apakah Origin yang kita tambahkan benar-benar terbaca. Untuk menelusuri masalah, sudo unattended-upgrade -d menulis debug tambahan ke log.

Dua berkas log yang wajib dikenal:

/var/log/unattended-upgrades/unattended-upgrades.log — catatan keputusan alat ini.
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log — keluaran dpkg saat paket benar-benar dipasang.

Notifikasi: Supaya Kita Tidak Buta

Auto-update yang berjalan diam-diam punya satu kelemahan: kalau gagal, tidak ada yang memberi tahu. Dua opsi di berkas yang sama menutup celah itu:


Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";

MailReport menerima tiga nilai: always (selalu kirim), only-on-error (hanya saat gagal), dan on-change (hanya saat ada paket terpasang) — yang terakhir adalah default-nya. Perlu diingat, pengiriman email ini butuh MTA yang berfungsi di server; kalau belum ada, ssmtp atau relay SMTP bisa dipakai lebih dulu. Kalau VPS kita punya alat monitoring seperti Healthchecks, laporan perubahan paket juga layak diteruskan ke sana supaya tercatat di satu tempat.

Kesimpulan

Update keamanan otomatis bukan berarti kita boleh berhenti peduli pada server. Justru sebaliknya: dengan unattended-upgrades menyala, kita memindahkan pekerjaan yang paling mudah terlupa ke mesin, dan menyisakan untuk diri kita hal yang memang butuh keputusan manusia — kebijakan reboot, paket mana yang dikecualikan, dan service mana yang tidak boleh disentuh tanpa pengawasan.

Empat hal yang layak dicek malam ini di VPS kita: paketnya terpasang, 20auto-upgrades bernilai "1", Allowed-Origins sudah mencakup repo yang kita pakai, dan log di /var/log/unattended-upgrades/ benar-benar bertambah. Sisanya, biarkan mesin yang mengingat. Server yang rutin ditambal memang tidak pernah terasa “keren” — tapi justru itu tanda ia dikelola dengan benar.