Systemd Service Hardening: Mengamankan Layanan Linux Tanpa Mengganggu Aplikasi

Layanan yang berjalan di Linux sering membutuhkan akses ke berkas, jaringan, perangkat, dan kemampuan sistem agar dapat bekerja. Namun, ketika sebuah layanan diretas atau mengalami bug, izin yang terlalu luas bisa memperbesar dampaknya. Pada sistem yang menggunakan systemd, administrator dapat menerapkan service hardening untuk membatasi apa yang boleh dilakukan sebuah proses tanpa harus mengganti aplikasi atau membangun ulang server.

Pengaturan ini bukan tombol ajaib yang menjamin layanan kebal serangan. Tujuannya adalah mengurangi hak akses yang tidak diperlukan, membatasi area sistem yang dapat disentuh, dan membuat kompromi satu layanan tidak otomatis memberi akses ke seluruh mesin. Perubahan harus diuji karena layanan lama mungkin bergantung pada jalur berkas atau kemampuan yang sebelumnya tersedia.

Apa itu systemd service hardening?

systemd adalah sistem init dan pengelola layanan yang digunakan banyak distribusi Linux. Selain memulai dan menghentikan proses, unit service dapat menerapkan pembatasan keamanan seperti ruang sementara privat, perlindungan direktori sistem, pembatasan kemampuan kernel, dan larangan memperoleh hak istimewa baru.

Pengaturan tersebut biasanya ditempatkan sebagai drop-in override sehingga berkas unit bawaan paket tidak perlu diedit langsung. Cara ini lebih mudah ditinjau, dapat dibatalkan, dan cenderung tetap bertahan ketika paket aplikasi diperbarui.

1. Periksa layanan sebelum mengubahnya

Mulailah dengan memastikan nama unit dan cara kerjanya. Ganti example.service dengan nama layanan yang benar:

systemctl status example.service
systemctl cat example.service
systemctl show example.service --property=User,Group,ExecStart,ProtectSystem,NoNewPrivileges

Periksa pengguna yang menjalankan proses, direktori kerja, berkas konfigurasi, lokasi data, dan jalur yang perlu ditulis. Jika layanan sudah berjalan sebagai pengguna khusus tanpa hak root, pertahankan prinsip itu. Jangan langsung menambahkan pembatasan sebelum mengetahui kebutuhan aplikasi, termasuk apakah ia harus membuat berkas, membuka soket, atau mengakses direktori tertentu.

2. Gunakan override, bukan mengedit unit bawaan

Buat drop-in dengan perintah berikut:

sudo systemctl edit example.service

Editor akan membuka berkas override untuk unit tersebut. Contoh awal yang dapat dipertimbangkan adalah:

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=read-only
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictSUIDSGID=true
LockPersonality=true

Ini hanyalah titik awal, bukan konfigurasi universal. NoNewPrivileges=true mencegah proses memperoleh hak istimewa tambahan melalui mekanisme seperti bit set-user-ID. PrivateTmp=true memberi layanan ruang sementara terpisah. ProtectSystem=strict membuat hierarki sistem menjadi hanya-baca bagi layanan, sedangkan ProtectHome=read-only membatasi penulisan ke direktori rumah. Opsi perlindungan kernel, control group, SUID/SGID, dan personality menambah pembatasan pada area yang tidak semestinya diubah oleh aplikasi biasa.

3. Izinkan hanya jalur tulis yang benar-benar diperlukan

Mode ProtectSystem=strict dapat membuat aplikasi gagal jika ia perlu menulis ke direktori tertentu. Jangan mengatasinya dengan menonaktifkan seluruh perlindungan tanpa pemeriksaan. Identifikasi lokasi data yang memang harus ditulis, lalu tambahkan izin sesempit mungkin, misalnya:

ReadWritePaths=/var/lib/example

Gunakan jalur yang benar-benar digunakan aplikasi, bukan contoh di atas secara harfiah. Pastikan direktori dimiliki oleh pengguna layanan dan memiliki izin yang tepat. Hindari memberi akses tulis ke seluruh /var, /etc, atau direktori rumah hanya agar layanan kembali berjalan. Jika aplikasi menulis log ke lokasi khusus, pertimbangkan mekanisme logging standar atau direktori yang dirancang untuk data layanan.

4. Batasi perangkat, kemampuan, dan keluarga jaringan

Untuk layanan yang tidak membutuhkan perangkat fisik, PrivateDevices=true dapat mengurangi akses ke perangkat pada sistem host. Pembatasan kemampuan Linux melalui CapabilityBoundingSet= dapat menghapus kemampuan yang tidak diperlukan, tetapi daftar yang keliru dapat memutus fungsi penting. Demikian pula, RestrictAddressFamilies= bisa membatasi keluarga soket yang boleh digunakan proses. Jangan menyalin daftar kemampuan atau jaringan dari layanan lain tanpa memahami kebutuhan program.

Beberapa opsi, seperti MemoryDenyWriteExecute=true, dapat mengganggu runtime yang memerlukan pemetaan memori tertentu, termasuk sebagian mesin virtual atau aplikasi yang memakai JIT. Terapkan satu perubahan pada satu waktu dan uji fungsi inti, bukan hanya memastikan proses berhasil dimulai.

5. Uji konfigurasi dan cari alasan jika layanan gagal

Setelah menyimpan override, muat ulang konfigurasi systemd dan mulai ulang layanan pada waktu yang aman:

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl status example.service
systemd-analyze security example.service

systemd-analyze security memberikan penilaian paparan berdasarkan beberapa opsi sandboxing. Angka yang lebih baik bukan bukti bahwa layanan sepenuhnya aman, dan hasilnya harus dibaca bersama dokumentasi serta kebutuhan aplikasi.

Jika layanan gagal, periksa log dengan journalctl -u example.service --since "15 minutes ago". Artikel Nazuaf tentang cara membaca log Linux menggunakan journalctl dapat membantu menelusuri pesan kesalahan. Pulihkan hanya opsi yang terbukti menjadi penyebab, lalu ulangi pengujian. Catat perubahan agar tim dapat memahami alasan setiap pengecualian.

Checklist sebelum diterapkan di produksi

  • Pastikan layanan berjalan sebagai pengguna non-root bila memungkinkan.
  • Uji fungsi utama: permintaan jaringan, pembacaan konfigurasi, penulisan data, dan rotasi log.
  • Periksa apakah layanan perlu akses ke direktori rumah, perangkat, soket, atau kemampuan khusus.
  • Uji setelah restart dan setelah pembaruan paket di lingkungan yang aman.
  • Simpan catatan konfigurasi awal dan siapkan langkah rollback sebelum mengubah layanan produksi.

Kesimpulan

systemd service hardening membantu mengurangi dampak kompromi dengan membatasi hak akses proses sesuai kebutuhan sebenarnya. Mulailah dari inventarisasi layanan, terapkan beberapa pembatasan yang mudah dipahami, lalu uji perilaku aplikasi dan tinjau log. Tambahkan pengecualian hanya berdasarkan bukti, bukan sekadar untuk menghilangkan error. Pendekatan bertahap menghasilkan konfigurasi yang lebih aman sekaligus lebih mudah dipelihara.

Untuk detail dan kompatibilitas opsi, rujuk dokumentasi resmi systemd.exec dan systemd-analyze. Opsi yang tersedia dapat berbeda menurut versi systemd dan distribusi Linux.

PENGALAMAN BARU Coba tampilan baru Penasaran dengan pengalaman membaca Nazuaf versi modern? Coba tampilan baru yang dirancang agar nyaman dibaca dari ponsel dan pc. Buka versi modern dan lanjutkan membaca artikel ini. Jelajahi tampilan baru Nazuaf versi modern · Ketuk kartu untuk mencoba

Bagikan artikel ini

Tinggalkan komentar

Server Load: 23% · CMH · ⚡ --ms