Hardening Server Linux

Bab 29 menutup Bagian VII dengan detail keamanan yang sengaja kita catat sebagai bekal menuju bab ini, yaitu container LXD yang berjalan secara unprivileged secara default pada Bagian 29.1.3. Sejak Bab 1 dan Bab 2, kita juga sudah berulang kali menyinggung istilah attack surface tanpa pernah membahasnya secara tuntas, termasuk janji eksplisit pada Bab 2 bahwa pembahasan lengkapnya menunggu di Bab 30 ini. Bagian VIII yang dimulai dari bab ini akhirnya menepati janji tersebut, membuka babak baru series yang berfokus penuh pada keamanan server, mulai dari prinsip paling dasar sampai firewall, intrusion prevention, mandatory access control, dan audit pada empat bab berikutnya. Hardening adalah proses sistematis memperkecil celah yang bisa dimanfaatkan Attacker untuk masuk atau merusak sistem, dan bab ini membangun fondasinya lewat empat pilar: prinsip minimal attack surface, menonaktifkan service yang tidak diperlukan, menjaga update tetap rutin sebagai lini pertahanan utama, serta mengenal konsep TPM-backed disk encryption untuk skenario server fisik maupun cloud.

30.1 Prinsip Minimal Attack Surface dan Defense in Depth

Sebelum menonaktifkan atau mengubah apa pun, kita perlu memahami dulu apa sebenarnya yang sedang kita perkecil, dan di mana posisinya di antara lapisan pertahanan lain yang akan kita pelajari sepanjang Bagian VIII.

30.1.1 Apa Itu Attack Surface

Attack surface adalah keseluruhan titik masuk yang berpotensi dimanfaatkan Attacker untuk mengakses, mengganggu, atau mengambil alih sebuah sistem, mulai dari port jaringan yang listening, service yang berjalan, package yang terpasang, hingga akun user yang punya akses ke server. Semakin banyak komponen yang aktif, semakin luas permukaan yang harus dijaga Sysadmin, dan semakin besar pula kemungkinan salah satu di antaranya menyimpan celah yang belum ditambal. Prinsip minimal attack surface yang sudah kita singgung sejak Bab 1 dan Bab 2 pada akhirnya sederhana: jangan menjalankan atau memasang apa pun yang tidak benar-benar dibutuhkan oleh peran server tersebut. Server yang hanya bertugas sebagai web server, misalnya, tidak perlu menjalankan service printing, Bluetooth, atau discovery jaringan lokal yang lazim ditemukan pada instalasi desktop.

30.1.2 Defense in Depth: Peta Lapisan Hardening di Series Ini

Meminimalkan attack surface adalah lapisan pertama, bukan satu-satunya lapisan pertahanan. Defense in depth adalah strategi menyusun beberapa lapisan pertahanan yang independen satu sama lain, sehingga kegagalan pada satu lapisan tidak langsung berarti seluruh sistem jebol. Series ini menyusun lapisan-lapisan tersebut secara bertahap sepanjang Bagian VIII, seperti terangkum pada tabel berikut.

Bab 30 ini fokus pada lapisan pertama dalam tabel di atas, yaitu mengecilkan apa yang bisa diserang lewat service yang aktif dan menutup celah yang sudah diketahui lewat update rutin, ditutup dengan pengenalan enkripsi disk sebagai pertahanan tambahan seandainya seluruh lapisan di atasnya tetap kebobolan dan disk server jatuh ke tangan yang salah.

30.1.3 Menghitung Baseline Attack Surface Server Kita

Sebelum menonaktifkan apa pun pada Bagian 30.2, ada baiknya kita mengukur dulu seberapa besar attack surface server yang sedang kita kelola, sehingga tersedia angka pembanding setelah proses hardening selesai.

Langkah Praktik

1. Hitung jumlah service yang sedang berjalan lewat systemd.

   systemctl list-units --type=service --state=running --no-legend | wc -l

2. Hitung jumlah package yang terpasang penuh di sistem.

   dpkg -l | grep -c ^ii

Verifikasi dan Troubleshooting

• Catat kedua angka ini sebagai baseline segera setelah instalasi awal selesai pada Bab 2, lalu bandingkan lagi secara berkala. Lonjakan signifikan tanpa alasan jelas layak diinvestigasi, entah karena Developer memasang tool debug dan lupa mencopotnya, atau lebih buruk, karena ada package asing yang tidak pernah kita pasang sendiri.
• Tidak ada satu angka "aman" yang berlaku universal untuk kedua metrik ini. Kebutuhan tiap server berbeda-beda; server database wajar menjalankan lebih sedikit service dibanding server yang merangkap banyak peran sekaligus, jadi gunakan angka ini sebagai pembanding terhadap dirinya sendiri dari waktu ke waktu, bukan terhadap server lain.

30.2 Menonaktifkan Service yang Tidak Diperlukan

Bagian 30.1 baru mengukur attack surface secara angka. Bagian ini masuk ke tindakan konkretnya: mengidentifikasi service mana saja yang sebenarnya tidak dibutuhkan oleh peran server kita, lalu menonaktifkannya dengan cara yang benar.

30.2.1 Mengidentifikasi Service dan Port yang Aktif

Setiap service yang listening di sebuah port berarti membuka jalur komunikasi yang bisa dicoba diakses dari luar, entah oleh User yang sah maupun Attacker yang sedang melakukan port scanning.

Langkah Praktik

1. Lihat seluruh port TCP/UDP yang listening beserta proses pemiliknya.

   sudo ss -tulnp

2. Bandingkan dengan daftar service yang sedang berjalan lewat systemd, sama seperti perintah yang sudah kita kenal di Bab 5.

   systemctl list-units --type=service --state=running

Verifikasi dan Troubleshooting

• Kolom Process pada output ss -tulnp menampilkan nama binary dan PID pemilik port. Jika nama service-nya tidak familiar, telusuri paket asalnya lewat dpkg -S /path/ke/binary sebelum memutuskan aman tidaknya untuk dinonaktifkan.
• Perintah netstat yang dulu populer untuk keperluan serupa sudah lama digantikan oleh ss, bagian dari paket iproute2, karena net-tools tempat netstat berasal sudah tidak dikembangkan aktif lagi di banyak distribusi modern termasuk Ubuntu.
• systemctl list-units --type=service --state=running hanya menampilkan service yang sedang menyala saat ini, bukan service yang akan ikut menyala pada boot berikutnya. Cek juga daftar service yang berstatus enabled lewat systemctl list-unit-files --type=service --state=enabled, karena service yang sedang berhenti tapi tetap enabled akan otomatis aktif lagi setelah reboot berikutnya, sebuah kondisi yang mudah luput dari audit sekilas.

30.2.2 Menonaktifkan, Masking, dan Menghapus Service

Systemd menyediakan tiga tingkat tindakan terhadap sebuah service yang tidak diperlukan, masing-masing dengan tingkat "keseriusan" berbeda.

Langkah Praktik

1. Hentikan sekaligus nonaktifkan service dari proses boot.

   sudo systemctl disable --now nama-service

2. Jika ingin memastikan service tersebut tidak bisa menyala lagi dengan cara apa pun, mask service-nya.

   sudo systemctl mask nama-service

3. Jika package terkait memang sama sekali tidak dibutuhkan, hapus sepenuhnya beserta dependency yang menyertainya.

   sudo apt purge nama-paket
   sudo apt autoremove

Verifikasi dan Troubleshooting

• Konfirmasikan status akhir service, harus bertuliskan masked atau inactive (dead), bukan failed.

  systemctl status nama-service

• Perintah systemctl mask secara teknis membuat symlink unit file ke /dev/null di /etc/systemd/system/, dapat diverifikasi langsung lewat ls -la /etc/systemd/system/nama-service.service.
• Catatan jujur soal risiko: apt purge ikut menghapus file konfigurasi, bukan sekadar binary-nya. Untuk service yang mungkin akan dipasang ulang di kemudian hari, misalnya database yang sedang tidak dipakai tapi berpotensi dibutuhkan lagi, gunakan systemctl disable --now atau mask saja tanpa purge, agar konfigurasi lama tidak ikut hilang.
• Jika ternyata sesuatu justru bergantung pada service yang baru dinonaktifkan, kembalikan dengan systemctl unmask nama-service diikuti systemctl enable --now nama-service.

30.2.3 Studi Kasus: Memangkas Service yang Sering Tertinggal

Beberapa service berikut kerap ikut terpasang lewat dependency recommends paket lain meski jarang benar-benar dibutuhkan sebuah server produksi. Selalu periksa dulu apakah service tersebut memang terpasang di server kita sebelum menonaktifkannya, karena tidak semua instalasi membawanya.

Langkah Praktik

1. Periksa dulu service mana dari daftar di atas yang benar-benar terpasang di server kita.

   dpkg -l | grep -E 'avahi-daemon|cups-browsed|modemmanager|bluetooth|rpcbind'

2. Nonaktifkan satu per satu service yang terpasang tapi memang tidak relevan dengan peran server kita, misalnya contoh berikut untuk avahi-daemon.

   sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

Verifikasi dan Troubleshooting

• Setelah menonaktifkan, uji fungsi utama server (misalnya akses web lewat Nginx, koneksi SSH) untuk memastikan tidak ada dependency tersembunyi yang ikut terganggu.
• Di lapangan, rpcbind adalah kandidat yang paling sering salah dinonaktifkan tanpa cek terlebih dahulu, karena Sysadmin lupa bahwa server tersebut ternyata masih menjadi NFS client untuk mount storage bersama seperti yang dibahas pada Bab 25. Selalu cek /etc/fstab dan showmount sebelum menyentuh service ini di server yang sudah lama berjalan.

30.3 Update Rutin sebagai Lini Pertahanan Utama

Menonaktifkan service yang tidak perlu menutup celah yang sudah kita ketahui keberadaannya sejak awal. Update rutin menutup celah yang baru ditemukan setelah server berjalan, dan karena kerentanan baru terus-menerus dipublikasikan, bagian ini sering kali menjadi faktor penentu apakah sebuah insiden benar-benar terjadi atau berhasil dicegah lebih dulu.

30.3.1 Mengapa Update adalah Kontrol Keamanan dengan Dampak Terbesar

Mayoritas insiden keamanan server bukan berasal dari zero-day exploit canggih yang belum pernah diketahui siapa pun, melainkan dari kerentanan lama yang sudah punya patch resmi tetapi belum sempat dipasang. Attacker umumnya tidak menargetkan satu server tertentu secara manual, melainkan menjalankan scanner otomatis yang mencari versi software dengan celah yang sudah dipublikasikan secara luas lewat basis data CVE. Server yang telat update, sekalipun sudah dilindungi firewall ketat pada Bab 31 nanti, tetap membuka kemungkinan besar untuk dieksploitasi lewat celah pada service yang memang sengaja diekspos, misalnya web server atau SSH itu sendiri. Bagian 6.3 sudah membekali kita dengan dua mekanisme automasi untuk hal ini, yaitu unattended-upgrades pada Bagian 6.3.1 untuk update package rutin dan Livepatch pada Bagian 6.3.2 untuk patch kernel tanpa reboot. Bagian ini tidak mengulang instalasinya, melainkan menambahkan kebiasaan audit yang perlu berjalan berdampingan dengan automasi tersebut.

30.3.2 Audit Cepat Status Patch Keamanan

Automasi seperti unattended-upgrades mengurangi beban kerja manual, tetapi Sysadmin yang bertanggung jawab tetap perlu sesekali memverifikasi sendiri bahwa server benar-benar berada pada kondisi ter-update, alih-alih mengandalkan asumsi bahwa automasi selalu berjalan mulus.

Langkah Praktik

1. Segarkan metadata repository, lalu lihat daftar package yang punya versi lebih baru.

   sudo apt update
   apt list --upgradable

2. Saring hanya update yang berasal dari origin keamanan, sama seperti origin yang diizinkan pada konfigurasi unattended-upgrades di Bagian 6.3.1.

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

Verifikasi dan Troubleshooting

• Daftar yang kosong pada langkah kedua menandakan tidak ada update keamanan tertunda, baik karena server memang sudah ter-update penuh, maupun karena unattended-upgrades sudah memasangnya lebih dulu secara otomatis.
• Daftar yang berisi banyak baris tanpa kata security umumnya adalah update fitur atau versi minor biasa, bukan celah yang mendesak. Prioritaskan tetap origin -security lebih dulu, dan jadwalkan update non-keamanan pada maintenance window terpisah agar tidak tercampur dengan urgensi patch keamanan.
• Untuk server dengan Ubuntu Pro aktif seperti dibahas pada Bagian 6.5, tool pro fix bisa menargetkan satu CVE spesifik secara langsung, berguna saat sebuah kerentanan kritis baru saja diumumkan dan kita ingin memastikan server sudah tertambal tanpa menunggu siklus unattended-upgrades berikutnya.

  sudo pro fix CVE-YYYY-NNNNN

30.3.3 Reboot Terjadwal untuk Kernel dan Komponen Kritis

Sebagian update, terutama kernel dan library inti seperti glibc, baru benar-benar aktif setelah proses yang memuatnya di memori dimulai ulang. Package terpasang bukan berarti patch-nya sudah berlaku.

Langkah Praktik

1. Periksa apakah server sedang menunggu reboot agar patch kritis benar-benar aktif.

   cat /var/run/reboot-required

2. Lihat package spesifik apa saja yang memicu kebutuhan reboot tersebut.

   cat /var/run/reboot-required.pkgs

Verifikasi dan Troubleshooting

• Kedua file di atas dibuat oleh hook dari package update-notifier-common setiap kali instalasi package tertentu diketahui membutuhkan reboot. Pesan No such file or directory pada server yang sedang tidak butuh reboot adalah hal normal, bukan error.
• Untuk komponen non-kernel yang sedang menggunakan library lama di memori tanpa membutuhkan reboot penuh, needrestart yang sudah kita kenal di Bagian 6.3.1 tetap menjadi cara paling praktis untuk me-restart proses yang bersangkutan saja, tanpa perlu reboot seluruh server.
• Keputusan reboot otomatis atau manual sudah pernah kita bahas lewat parameter Unattended-Upgrade::Automatic-Reboot pada Bagian 6.3.1. Untuk server database production atau layanan dengan target uptime tinggi, pantau /var/run/reboot-required secara berkala lewat monitoring (Bab 38) dan jadwalkan reboot manual pada maintenance window yang sudah disepakati, alih-alih membiarkannya menumpuk tanpa pernah dieksekusi.

30.4 TPM-backed Disk Encryption untuk Server dan Cloud

Tiga bagian sebelumnya menutup celah di level software, mulai dari service yang berjalan sampai patch yang terpasang. Bagian penutup bab ini membahas satu lapisan pertahanan yang berbeda sifatnya, tetap relevan sekalipun Attacker berhasil melewati seluruh lapisan software di atas, yaitu enkripsi data yang tersimpan secara fisik di disk.

30.4.1 Masalah Klasik LUKS Passphrase pada Server Headless

LUKS (Linux Unified Key Setup) adalah standar enkripsi disk penuh di Linux, bekerja di atas dm-crypt pada level kernel. Pendekatan klasiknya mengharuskan seseorang mengetikkan passphrase secara manual setiap kali server boot, sebelum sistem operasi sepenuhnya menyala dan jaringan tersedia. Pendekatan ini masuk akal untuk laptop yang selalu berada di depan pemiliknya, tetapi menjadi masalah nyata untuk server headless seperti yang sudah kita bahas sejak Bab 1. Server yang di-reboot dari jarak jauh, misalnya setelah patch kernel pada Bagian 30.3.3, akan tertahan menunggu passphrase yang tidak ada seorang pun ketikkan, kecuali Sysadmin sudah menyiapkan solusi tambahan seperti akses SSH ke dalam initramfs lewat dropbear-initramfs, yang menambah kerumitan operasional tersendiri.

30.4.2 Bagaimana TPM Menyegel Kunci Enkripsi

TPM (Trusted Platform Module) adalah chip keamanan khusus, tertanam di motherboard fisik atau disediakan sebagai virtual TPM (vTPM) pada platform virtualisasi modern, yang mampu menyimpan kunci kriptografi secara aman dan menyegelnya terhadap kondisi boot chain tertentu. Mekanismenya memanfaatkan measured boot: setiap tahap proses boot, mulai dari firmware, bootloader, hingga kernel, dicatat nilai hash-nya ke register khusus pada TPM yang disebut Platform Configuration Register (PCR). Kunci enkripsi LUKS disegel agar hanya bisa dibuka apabila nilai-nilai PCR tersebut cocok dengan kondisi saat penyegelan dilakukan. Selama boot chain tidak berubah, TPM melepaskan kunci secara otomatis tanpa memerlukan passphrase manual sama sekali, sehingga masalah reboot jarak jauh pada Bagian 30.4.1 pun teratasi. Sebaliknya, jika ada perubahan pada boot chain, misalnya firmware yang dimodifikasi Attacker atau disk yang dipindahkan ke hardware lain, proses unseal akan gagal dan sistem jatuh ke mekanisme recovery key sebagai fallback, sekaligus menjadi sinyal bahwa ada sesuatu yang berubah dan layak diperiksa.

Di ekosistem Linux, mekanisme pengikatan LUKS ke TPM2 ini umumnya dilakukan lewat systemd-cryptenroll, tool yang sudah menjadi bagian dari systemd sejak beberapa rilis terakhir. Sebagai ilustrasi mekanisme yang mendasarinya, dua perintah berikut mendaftarkan TPM yang terdeteksi lalu mengikat sebuah partisi LUKS ke PCR 7, yaitu register yang merekam status Secure Boot.

systemd-cryptenroll --tpm2-device=list
sudo systemd-cryptenroll /dev/sdXN --tpm2-device=auto --tpm2-pcrs=7

Sebelum mengandalkan mekanisme ini, pastikan dulu hardware atau platform virtualisasi yang kita pakai benar-benar menyediakan chip TPM, baik yang fisik maupun yang berbentuk vTPM.

ls /dev/tpm*

Munculnya /dev/tpm0 atau /dev/tpmrm0 menandakan kernel sudah mendeteksi dan memuat driver untuk TPM tersebut. Jika perintah di atas hanya mengembalikan pesan No such file or directory, server bersangkutan tidak memiliki TPM yang bisa dipakai, entah karena hardware fisik memang tidak dilengkapi chip tersebut, atau karena instance virtual belum mengaktifkan opsi vTPM pada level hypervisor maupun cloud provider.

Sebagai catatan kejujuran sesuai kaidah akurasi series ini, dukungan penuh TPM-backed disk encryption lewat wizard installer memang lebih dulu matang di Ubuntu Desktop sejak beberapa rilis terakhir dibanding di Ubuntu Server. Detail implementasi persis pada Ubuntu Server 26.04 LTS berpotensi berubah mengikuti rilis point release, sehingga langkah paling aman sebelum mengandalkannya penuh di server production adalah memverifikasi status dan cara aktivasinya lewat release notes resmi Ubuntu Server terbaru, bukan menganggap contoh perintah di atas sebagai satu-satunya cara baku yang sudah final.

30.4.3 Relevansi untuk Server Fisik vs Instance Cloud

Relevansi TPM-backed disk encryption ternyata cukup berbeda tergantung apakah server yang kita kelola berupa hardware fisik atau instance di cloud.

Untuk server fisik, baik yang duduk di ruang server milik sendiri maupun yang dititipkan di fasilitas colocation, ancaman utamanya adalah pencurian atau pelepasan disk secara fisik. Seseorang yang berhasil mencabut disk server dan memasangnya di komputer lain, tanpa enkripsi, bisa langsung membaca seluruh isinya. TPM-backed disk encryption menjawab ancaman ini tanpa mengorbankan kemudahan reboot dari jarak jauh, menjadikannya pilihan yang jauh lebih praktis dibanding LUKS passphrase manual untuk server fisik yang jarang dikunjungi secara langsung.

Untuk instance di cloud, situasinya sedikit berbeda. Penyedia cloud besar seperti AWS, Azure, dan GCP umumnya sudah menerapkan enkripsi data-at-rest di level storage backend mereka sendiri, seperti EBS encryption di AWS atau enkripsi default pada persistent disk di GCP, sehingga ancaman pencurian disk fisik oleh pihak luar praktis sudah ditangani provider tanpa perlu konfigurasi tambahan dari Sysadmin. Yang membuat TPM tetap relevan di cloud justru pergeseran fokus ke arah integritas boot chain, bukan sekadar kerahasiaan data. Fitur seperti NitroTPM di AWS, Trusted Launch di Azure, dan Shielded VM di GCP menyediakan vTPM yang memungkinkan verifikasi bahwa VM benar-benar boot dari komponen yang belum dimodifikasi, berguna sebagai lapisan pertahanan tambahan terhadap serangan level bootkit atau rootkit pada lingkungan multi-tenant, serta untuk memenuhi persyaratan compliance tertentu yang secara eksplisit mewajibkan enkripsi disk di level guest, terlepas dari jaminan enkripsi yang sudah diberikan provider.

Ringkasnya, disk encryption berbasis TPM paling bernilai untuk server fisik dengan risiko pencurian nyata dan kebutuhan reboot jarak jauh yang sering, sedangkan untuk instance cloud, nilainya lebih condong ke arah integritas boot chain dan pemenuhan compliance dibanding sekadar kerahasiaan data yang sering kali sudah ditangani provider.

Sampai di sini, kita sudah membangun fondasi hardening server lewat empat pilar: memahami dan mengukur attack surface, menonaktifkan service yang tidak diperlukan dengan cara yang benar, menjadikan update rutin sebagai kontrol keamanan berdampak besar alih-alih sekadar rutinitas administratif, hingga mengenal TPM-backed disk encryption sebagai lapisan pertahanan tambahan untuk skenario fisik maupun cloud. Bab 31 berikutnya melanjutkan ke lapisan kedua pada peta defense in depth yang sudah kita susun di Bagian 30.1.2, yaitu firewall tingkat lanjut, mulai dari iptables klasik, UFW sebagai frontend yang lebih ramah, hingga nftables sebagai arsitektur modern yang kini menjadi fondasi keduanya.