Penguatan Keamanan Layanan systemd (Hardening)

• systemd menyediakan fitur manajemen layanan yang kuat, tetapi konfigurasi default-nya dioptimalkan untuk kemudahan penggunaan alih-alih keamanan, sehingga perlu menerapkan opsi hardening secara terpisah
• Melalui perintah systemd-analyze security, Anda dapat menganalisis indikator paparan keamanan untuk seluruh layanan atau layanan tertentu, lalu menentukan prioritas
• Tersedia berbagai opsi keamanan yang dapat diterapkan pada unit layanan, dan ini bisa dimodifikasi satu per satu melalui /etc/systemd/system/ServiceName.service.d/override.conf dan sejenisnya
• Opsi utama mencakup ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute, dan lainnya yang membatasi hak proses serta akses ke sumber daya
• Daripada menargetkan keamanan yang sempurna, lebih efektif memprioritaskan hardening pada layanan yang terekspos ke luar untuk mengurangi risiko, dan ini juga sangat bermanfaat di lingkungan self-hosting

---

Gambaran umum systemd

• systemd menyediakan pendekatan yang sangat matang dan tangguh untuk manajemen layanan
• Namun, karena memprioritaskan kemudahan penggunaan langsung dibanding keamanan, konfigurasi default-nya dibuat cukup longgar
• Dokumen ini memperkenalkan berbagai opsi penguatan keamanan yang dapat diterapkan pada unit layanan systemd dan podman quadlet untuk mengurangi kemungkinan kompromi serta meminimalkan cakupan dampaknya saat kompromi terjadi
• Ini bukan panduan untuk diterapkan sekaligus ke semua layanan; diperlukan eksperimen terpisah, pemeriksaan log, dan penyesuaian sesuai karakteristik serta kebutuhan fungsi masing-masing layanan
• Tanggung jawab keamanan infrastruktur sepenuhnya berada pada operator, dan dokumen ini hanyalah alat referensi

Analisis keamanan systemd

• Dengan perintah systemd-analyze security, Anda dapat memeriksa status keamanan seluruh layanan atau menganalisis pengaturan detail layanan tertentu (misalnya sshd.service)
  • Output mencakup status pemeriksaan, nama fitur, penjelasan, dan skor Exposure; semakin tinggi Exposure, semakin besar risikonya
• Opsi keamanan dapat ditambahkan pada bagian [Service] (systemd) atau [Container] (podman quadlet)
• Disarankan membuat file override melalui systemctl edit ServiceName.service; jika gagal, periksa hak akses yang diperlukan lalu sesuaikan

Opsi keamanan layanan

• systemd menyediakan berbagai kata kunci opsi keamanan yang dapat dilihat melalui man systemd.exec 5, man capabilities 7, dan lainnya
• Opsi keamanan yang representatif
  • ProtectSystem → opsi untuk membatasi filesystem menjadi hanya-baca
  • ProtectHome → opsi untuk memblokir akses ke /home, /root, /run/user
  • PrivateDevices → opsi untuk memblokir akses ke perangkat fisik dan hanya mengizinkan perangkat virtual seperti /dev/null
  • ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → opsi untuk memblokir akses ke sumber daya kernel
  • NoNewPrivileges → opsi untuk mencegah perolehan hak baru melalui setuid/setgid dan sejenisnya
  • MemoryDenyWriteExecute → memblokir penggunaan memori yang dapat ditulis dan dieksekusi secara bersamaan; dapat menimbulkan masalah pada sebagian bahasa JIT
  • SystemCallFilter → opsi untuk membatasi system call yang diizinkan; jika dilanggar, proses dapat dihentikan atau mengembalikan EPERM

Penjelasan tiap opsi

• ProtectSystem: saat diatur ke strict, seluruh filesystem di-mount sebagai hanya-baca; /dev, /proc, /sys memerlukan opsi perlindungan terpisah
• ReadWritePaths: mengatur agar hanya beberapa path tertentu yang bisa ditulis kembali
• ProtectHome: memblokir akses ke /home, /root, /run/user
• PrivateDevices: menonaktifkan akses ke perangkat fisik, hanya mengizinkan perangkat pseudo seperti /dev/null
• ProtectKernelTunables: menjadikan /proc, /sys hanya-baca
• ProtectControlGroups: hanya mengizinkan akses baca ke cgroup
• ProtectKernelModules: melarang pemuatan eksplisit modul kernel
• ProtectKernelLogs: membatasi akses ke buffer log kernel
• ProtectProc: saat diatur ke invisible, proses milik pengguna lain disembunyikan dari /proc/
• ProcSubset: memblokir isi /proc selain item terkait PID tertentu
• NoNewPrivileges: memblokir eskalasi hak baru melalui setuid, setgid, dan capability filesystem
• ProtectClock: memblokir penulisan ke jam sistem/perangkat keras
• SystemCallArchitectures: saat diatur ke native, hanya mengizinkan syscall native seperti x86-64
• RestrictNamespaces: membatasi namespace yang khusus untuk kontainer
• RestrictSUIDSGID: memblokir pengaturan bit setuid dan setgid pada file
• LockPersonality: mencegah perubahan domain eksekusi (biasanya hanya diperlukan untuk aplikasi lama)
• RestrictRealtime: membatasi penjadwalan real-time (hanya diperlukan untuk sebagian layanan tujuan khusus)
• RestrictAddressFamilies: membatasi keluarga alamat soket yang diizinkan (misalnya menentukan AF_INET, AF_INET6, AF_UNIX, dll.)
• MemoryDenyWriteExecute: memblokir pembuatan tambahan area memori yang dapat ditulis+dieksekusi (layanan yang memakai JIT perlu berhati-hati)
• ProtectHostname: melarang penggunaan syscall sethostname, setdomainname
• SystemCallFilter: mengatur syscall yang diizinkan/diblokir per layanan, dengan pemfilteran yang sangat rinci
  • Dapat disesuaikan berdasarkan grup, syscall individual, serta metode izinkan/blokir
  • Saat terjadi pelanggaran, juga mendukung pengaturan agar mengembalikan kode error seperti EPERM alih-alih langsung dihentikan
  • Daftar lengkap dapat dilihat melalui systemd-analyze syscall-filter atau man systemd.exec(5)
  • Daftar dapat dinegasikan seluruhnya dengan prefiks ~ (misalnya CapabilityBoundingSet=~CAP_SETUID dan seterusnya)

Proses penyesuaian pembatasan SystemCallFilter

• Dengan auditd, Anda dapat memeriksa log syscall mana yang diblokir saat layanan gagal
  • Jalankan sudo ausearch -i -m SECCOMP -ts recent, lalu periksa nilai syscall
  • Tambahkan syscall tersebut atau grup terkait ke SystemCallFilter untuk menyelesaikan masalah secara bertahap

Prioritas penerapan hardening dan tips operasional

• Tidak perlu menerapkannya semua ke setiap layanan
• Threat model dan manajemen risiko adalah inti; khususnya layanan yang terekspos ke luar (httpd, nginx, ssh, dll.) wajib dipertimbangkan
• Penerapan proaktif juga efektif untuk custom command, unit timer (pengganti cron lama), dan sejenisnya
• Semakin sederhana sebuah layanan, semakin besar kemungkinan melakukan penyesuaian yang rinci

Checklist: kombinasi opsi keamanan yang direkomendasikan (prioritas awal penerapan)

• ProtectSystem=strict
• PrivateTmp=yes
• ProtectHome=yes atau ProtectHome=tmpfs
• ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
• RestrictSUIDGUID=yes
• UMask=0077
• LockPersonality=yes
• RestrictRealtime=yes
• MemoryDenyWriteExecute=yes
• DynamicUser=yes atau menetapkan User ke pengguna tertentu selain root

• Butir-butir di atas umumnya adalah kombinasi yang dapat digunakan dengan hampir tanpa mengganggu layanan
• Jika ingin menambahkan pemfilteran syscall (SystemCallFilter), diperlukan pengujian yang lebih rinci

Contoh konfigurasi Traefik

• Ini adalah contoh menjalankan layanan Traefik berbasis kontainer dengan systemd quadlet, sambil menerapkan banyak opsi keamanan
  • Menerapkan ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged, dan lainnya
  • Menghapus hak tertentu dengan CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP
  • Menerapkan pembatasan akses jaringan seperti RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK

Kesimpulan

• Opsi hardening keamanan systemd adalah sarana praktis yang layak dimiliki dalam kotak alat administrator sistem keluarga Unix
• Ini bukan solusi keamanan yang sempurna, melainkan alat untuk mengurangi risiko, dan tidak perlu menerapkan pengaturan keamanan secara sembarangan ke semua layanan
• Terutama bagi administrator di lingkungan self-hosting, ini dapat sangat membantu meningkatkan tingkat keamanan
• Dengan memprioritaskan “kepraktisan daripada kesempurnaan”, disarankan menerapkannya setidaknya sebagian dalam cakupan yang sesuai dengan pekerjaan dan lingkungan