Hardening Infrastruktur Linux untuk Sistem APAC

Sebagian besar sistem Linux produksi berjalan lebih dekat ke konfigurasi default daripada yang mau diakui siapa pun. Dokumen hardening ada, sering ditulis untuk audit bertahun-tahun lalu, tetapi server tidak sesuai dengannya. Celah antara “baseline terdokumentasi” dan “konfigurasi aktual” adalah tempat attacker hidup secara konsisten.

Hardening Linux adalah disiplin menutup celah itu, dan melakukannya dengan cara yang bertahan melewati deployment berikutnya.

Default adalah titik awal, bukan postur #

Instalasi Linux default mengutamakan kompatibilitas, bukan keamanan. Ia membawa layanan yang tak Anda pakai, fitur kernel yang tak Anda perlukan, dan logging yang cukup untuk desktop tetapi tidak untuk host produksi yang dikompromikan. Hardening adalah proses mengubah mesin serba-guna itu menjadi mesin yang dibangun untuk tujuan tertentu.

Pekerjaan beratnya terbagi beberapa kategori:

• Penyetelan kernel dan sysctl: proteksi jaringan (misal mengabaikan ICMP redirect, mengaktifkan source-route filtering), pembatasan filesystem, dan proteksi memori seperti address space layout randomisation.
• Minimalisasi layanan: menonaktifkan dan menghapus apa yang tidak dijalankan host, sehingga tak ada yang bisa dieksploit dan memang tak digunakan.
• Mandatory access control: SELinux atau AppArmor untuk membatasi apa yang boleh dilakukan sebuah proses, bahkan saat ia terkompromikan.
• Systemd dan container hardening: dropping capabilities, memblokir akses raw socket, dan membatasi syscall dengan profile seccomp.
• Audit dan logging: menangkap peristiwa yang penting, dikirim keluar host agar penyerang tak bisa menghapus jejaknya sendiri.

CIS Benchmarks tetap menjadi kodifikasi paling praktis dan paling luas dikenal atas kontrol-kontrol ini, dan OpenSCAP mengotomatisasi penerapan sekaligus auditnya.

Config as code, atau tidak ada #

Panduan hardening yang hidup di wiki hanyalah daftar harapan. Hardening yang hidup dalam kode (role Ansible, image Packer, admission policy Kubernetes) adalah fakta. Saat baseline menjadi kode, tiga hal berubah:

1. Ia reproducible. Setiap host baru mewarisi baseline, bukan hanya yang kebetulan diingat untuk dikonfigurasikan.
2. Ia testable. Compliance scan di CI menggagalkan build saat sebuah setting drift.
3. Ia reviewable. Perubahan baseline adalah pull request, dengan disiplin review yang sama seperti kode aplikasi.

Inilah beda antara hardening sebagai acara tahunan dan hardening sebagai properti platform.

Immutability sebagai tujuan akhir #

Kesimpulan logisnya adalah immutable infrastructure: host dan container tidak pernah di-patch di tempat, hanya diganti. Image baru dibangun, discan, dan di-deploy; yang lama dimusnahkan. Configuration drift menjadi mustahil karena tak ada yang bisa drift: sistem yang berjalan adalah artefak build.

Immutable infrastructure berpaduan alami dengan hardening-as-code. Anda tidak merawat baseline; Anda mengompilasi keamanan ke dalam image. Dan saat kerentanan muncul, solusinya adalah rebuild, bukan sesi SSH tengah malam.

Melampaui host #

Hardening tidak berhenti di sistem operasi. Disiplin yang sama terbentang ke beberapa arah, masing-masing dengan failure mode-nya sendiri.

Container mewarisi segalanya, lalu menambah risikonya sendiri. Image container yang dibangun dari base layer yang belum hardened membawa semua kelemahan level host ke setiap pod yang menjalankannya. Solusinya di hulu: base image minimal, discan di CI, dijalankan sebagai non-root dengan read-only filesystem, capabilities dicabut, dan seccomp profile yang membatasi syscall hanya untuk yang workload benar-benar butuhkan. Profil default seccomp sudah memblokir banyak; profil yang di-tune berdasarkan pola syscall yang terobservasi memblokir sisanya. Kubernetes admission policy menegakkan semuanya lintas fleet, sehingga deployment yang tidak patut bahkan tidak berhasil dijadwalkan.

Lingkungan OT menaikkan taruhan. Di lingkungan industri dan operational technology, hardening bertabrakan dengan availability dengan cara yang IT kantor tidak pernah alami. Satu kontrol CIS yang salah diterapkan pada building management system, jaringan PLC production line, atau segmen perangkat rumah sakit tidak menghasilkan finding: ia menghasilkan downtime, kadang-kadang dengan konsekuensi keselamatan jiwa. Karena itu hardening OT membalik urutannya: monitoring pasif dan inventaris didahulukan, perubahan dilakukan di maintenance window dengan rollback plan, dan kontrol dipilot di mirror produksi sebelum menyentuh apa pun yang nyata. IT bertanya “apakah sistem ini aman?”; OT harus bertanya “bisakah kita melindunginya tanpa menghentikannya?”

Drift detection menutup lingkaran. Baseline merosot lewat perubahan rutin: engineer membuka port untuk debug, installer mengaktifkan kembali sebuah service, hotfix tidak pernah masuk kembali ke kode. Tanpa deteksi, host yang hari ini hardened adalah host lunak tahun depan. Pola yang bekerja: pemindaian konfigurasi harian membandingkan live host dan image dengan baseline berkoding, dan temuan dirutekan sebagai alert langsung ke pemiliknya, bukan disimpan dalam laporan kuartalan yang tak dibaca siapa pun. Drift yang terdeteksi dalam sehari adalah tiket; drift yang terdeteksi setahun kemudian adalah investigasi insiden.

Host yang hardened di balik IAM role cloud yang terlalu longgar, atau di dalam container pipeline yang tidak discan, tetap terekspos. Postur paling tahan lama memperlakukan baseline host, container build chain, konfigurasi cloud, dan batas identitas sebagai satu permukaan berkesinambungan, dan memantaunya demikian.

Linux & Infrastructure Hardening kami menyerahkan baseline sebagai kode dan drift detection otomatis, dan Configuration & Architecture Assessment kami mereview lapisan cloud dan identitas di sekitar host. Untuk gambaran utuh, jadwalkan Engineering & Scoping Session.