Belajar Linux - Linux Hardening & Security Best Practices Production

#Pendahuluan

Setelah di episode 24 sebelumnya kita membahas system performance tuning & troubleshooting — bagaimana membuat server tetap cepat, membaca bottleneck dengan benar, dan menyelamatkan sistem saat down — pada episode kali ini kita membahas sisi yang sama pentingnya di dunia production: keamanan. Server yang cepat tapi mudah ditembus itu seperti mobil sport tanpa kunci — kencang, tapi hanya masalah waktu sampai ada yang membawanya pergi.

Keamanan bukanlah satu fitur yang diinstall, melainkan hasil dari kumpulan keputusan kecil yang saling melengkapi. Bayangkan rumah yang ingin kalian jaga: pintu yang terkunci, pagar yang cukup tinggi, kamera di sudut-sudut, tetangga yang waspada. Tidak ada satu pun dari elemen itu yang membuat rumah "anti pencuri" sendirian — tetapi bersama-sama, mereka membuat pencuri memilih target lain. Di dunia server, prinsip yang sama disebut defense in depth: banyak lapisan keamanan yang saling menutupi kelemahan satu sama lain.

Realitas yang tidak bisa dihindari: setiap server yang terekspos ke internet akan diserang. Botnet memindai internet 24 jam untuk mencari port SSH yang terbuka, mencoba ribuan kombinasi password per detik, dan mengeksploitasi layanan yang konfigurasinya lemah. Ini bukan skenario teoretis — ini yang terjadi setiap hari pada server yang bahkan tidak pernah dikenal siapa pun. Pertanyaannya bukan apakah diserang, melainkan seberapa kuat pertahanan saat serangan datang.

Pada episode ini kita akan membahas hardening Linux secara menyeluruh: prinsip memperkecil permukaan serangan dan least privilege, mengamankan SSH dengan kunci dan fail2ban, memahami Mandatory Access Control (SELinux dan AppArmor), melakukan audit keamanan dengan Lynis, dan menutup dengan checklist hardening untuk server Ubuntu baru beserta jebakan yang paling sering menjatuhkan admin.

#Pembahasan Utama

#Prinsip Hardening: Kecilkan Permukaan Serangan

Istilah teknis yang wajib kalian pahami sejak awal adalah attack surface — permukaan serangan, yaitu semua titik yang bisa disentuh penyerang: port yang terbuka, service yang berjalan, user yang ada, dan aplikasi yang terpasang. Prinsip hardening yang paling fundamental sederhana saja: semakin kecil permukaan serangan, semakin sedikit celah yang bisa dieksploitasi.

Setiap service yang berjalan adalah potensi pintu masuk. Setiap port yang terbuka adalah pintu yang bisa didobrak. Setiap user dengan hak tinggi adalah kunci cadangan yang bisa dicuri. Instalasi Linux default yang "nyaman" biasanya terlalu terbuka untuk production: SSH dengan password, banyak service yang tidak dipakai tetap berjalan, dan update keamanan tidak otomatis. Hardening adalah proses menyempitkan semua itu ke minimum yang benar-benar dibutuhkan.

Ada satu analogi yang selalu saya pakai: pesawat terbang. Pesawat tidak punya hal-hal yang tidak diperlukan — setiap sistem ada karena berkontribusi pada keselamatan penerbangan. Semakin banyak "barang" yang dibawa tanpa peran jelas, semakin besar risiko dan semakin rumit perawatan. Server production yang baik seperti pesawat: ringkas, setiap komponen punya alasan keberadaan, dan tidak ada yang disisakan karena "mungkin berguna suatu saat".

#Matikan Service yang Tidak Dipakai & Prinsip Least Privilege

Langkah pertama yang bisa langsung kalian lakukan adalah mengaudit service yang berjalan. Pertanyaan sederhananya: service ini saya pakai untuk apa? Jika tidak ada jawaban yang jelas, service itu sebaiknya dimatikan.

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

systemctl list-units menunjukkan service yang berjalan; ss -tlnp menunjukkan semua port yang sedang mendengarkan (listening). Cocokkan keduanya: service mana yang membuka port? Port mana yang seharusnya tidak terbuka? Pada server minimalis, kalian seharusnya hanya melihat port yang benar-benar dibutuhkan — misalnya 22 (SSH) dan 80/443 (web). Port lain yang tidak jelas adalah alarm.

Prinsip kedua adalah least privilege — beri setiap user dan proses hak sesedikit mungkin untuk menjalankan tugasnya. Ini bukan soal kepercayaan, melainkan soal pembatasan kerusakan: jika satu akun tertembus, seberapa jauh penyerang bisa bergerak? Praktiknya:

• Jangan login atau menjalankan aplikasi sebagai root; gunakan user biasa dan sudo saat perlu (kembali ke episode 10).
• Setiap aplikasi berjalan dengan user khususnya sendiri — misal nginx, mysql, www-data — bukan sebagai root.
• Batasi akses sudo dengan aturan spesifik di sudoers, bukan memberikan hak penuh secara serampangan.

#Kunci SSH: dari Password ke Kunci

Serangan paling umum yang dialami setiap server publik adalah SSH brute-force — mencoba jutaan kombinasi username/password secara otomatis. Server yang mengizinkan login SSH dengan password adalah target empuk, karena password lemah tinggal menunggu waktu untuk ditebak atau dibocorkan lewat phishing.

Solusinya sudah kita singgung di episode SSH: autentikasi dengan kunci publik. Kunci SSH bersifat kriptografis — praktis mustahil ditebak — dan tidak bisa dipalsukan lewat serangan kamus. Perubahan konfigurasi yang wajib dilakukan di /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes

Perhatikan diff di atas. PermitRootLogin no mematikan login langsung sebagai root — penyerang tidak punya nama user paling jelas untuk ditebak. Dan PasswordAuthentication no mematikan login berbasis password sepenuhnya — satu-satunya jalan masuk adalah kunci. Tapi ada syarat yang tidak bisa ditawar: pastikan kunci kalian sudah terpasang dan teruji sebelum menonaktifkan password, atau kalian akan terkunci di luar server sendiri.

Setelah mengubah konfigurasi, validasi dan restart dengan aman:

sudo sshd -t
sudo systemctl restart sshd

sshd -t memvalidasi syntax konfigurasi sebelum diterapkan — menyelamatkan kalian dari file config yang salah yang membuat SSH mati total.

#Fail2ban: Benteng untuk SSH Brute-Force

Kunci SSH sudah mematikan serangan brute-force terhadap password — tetapi server kalian tetap bisa diganggu: penyerang tetap mencoba login berulang kali, membanjiri log dengan percobaan gagal, dan membuang resource CPU dan bandwidth. Di sinilah fail2ban bekerja: ia memantau log, mendeteksi pola percobaan berulang, dan memblokir IP penyerang di firewall selama jangka waktu tertentu.

Cara kerja fail2ban bisa dianalogikan dengan penjaga pintu yang punya ingatan: jika orang yang sama mencoba masuk dengan kunci yang salah beberapa kali, penjaga mencatat wajahnya dan melarangnya masuk ke gedung selama beberapa jam. Persis itu yang dilakukan fail2ban terhadap IP — berdasarkan aturan yang mendefinisikan "berapa kali percobaan dalam berapa menit" dianggap mencurigakan.

Install fail2ban di Debian/Ubuntu:

sudo apt update
sudo apt install -y fail2ban

Konfigurasi utama ada di /etc/fail2ban/jail.conf, tetapi jangan mengedit file itu langsung — package update akan menimpanya. Pola yang benar adalah menulis override di /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8
 
[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3

Interpretasinya: dalam jendela findtime 600 detik (10 menit), jika ada lebih dari maxretry percobaan gagal (default 5, untuk SSH kita persempit jadi 3), IP tersebut di-ban selama bantime 3600 detik (1 jam). ignoreip memastikan IP internal tidak pernah terblokir — penting agar tim tidak terkunci saat mencoba berulang kali. logpath menunjuk ke file log autentikasi — /var/log/auth.log di Debian/Ubuntu atau /var/log/secure di RHEL/Rocky.

Setelah konfigurasi dibuat, aktifkan dan periksa statusnya:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Output fail2ban-client status sshd menunjukkan jumlah IP yang sedang di-ban dan statistik kegagalan. Setelah itu, seluruh percobaan brute-force yang memenuhi aturan otomatis diblokir — dan kalian bisa melihatnya di log:

sudo grep "Ban" /var/log/fail2ban.log | tail -20

#MAC: SELinux dan AppArmor

Sejauh ini kita membahas keamanan berbasis DAC (Discretionary Access Control) — kontrol akses yang ditentukan oleh pemilik file (permission rwx yang sudah kita pelajari). Tetapi jika proses aplikasi berhasil diambil alih penyerang, proses itu mewarisi semua hak user-nya — dan jika itu user database, penyerang bisa membaca semua data. Di sinilah MAC (Mandatory Access Control) masuk: lapisan yang membatasi apa yang boleh dilakukan sebuah proses terlepas dari hak user-nya.

Ada dua implementasi MAC utama di dunia Linux: SELinux (keluarga RHEL/Rocky) dan AppArmor (Ubuntu/Debian).

SELinux bekerja dengan memberikan label ke setiap file, proses, dan port, lalu menerapkan policy yang menentukan interaksi antar label. Mode yang bisa dijalankan ada tiga:

Periksa status SELinux dengan sestatus, dan ubah mode sementara dengan setenforce:

Periksa status SELinux

sestatus
getenforce

sudo setenforce 0   # Permissive (uji coba)
sudo setenforce 1   # Enforcing (ketat)

AppArmor di sisi Ubuntu bekerja dengan pendekatan berbeda: alih-alih label global, setiap program punya profile yang mendeskripsikan file dan network apa yang boleh diaksesnya. Profil diaktifkan/dinonaktifkan per program, dan daftarnya bisa dilihat dengan aa-status:

sudo aa-status

Kesalahan paling umum di sini adalah kebingungan "SELinux vs AppArmor" — keduanya tidak bisa dipertukarkan dan ditangani dengan tool yang berbeda. Server RHEL/Rocky menggunakan SELinux (periksa dengan sestatus); server Ubuntu menggunakan AppArmor (aa-status). Ketika sebuah aplikasi anehnya "tidak bisa mengakses file" padahal permission sudah benar, kemungkinan besar ini kerja MAC: di RHEL, cek ausearch -m avc -ts recent; di Ubuntu, periksa journal atau /var/log/kern.log.

#Audit Keamanan dengan Lynis

Hardening tanpa verifikasi hanyalah klaim. Bagaimana kalian tahu bahwa konfigurasi sudah benar? Di sinilah Lynis — scanner audit keamanan open source — berperan. Lynis memindai ratusan kontrol: konfigurasi SSH, permission file, service yang berjalan, update keamanan, user accounts, dan banyak lagi, lalu memberikan skor hardening index beserta rekomendasi perbaikan.

Install dan jalankan audit:

sudo apt install -y lynis

sudo lynis audit system

Output Lynis sangat panjang — ada bagian penting yang harus kalian cari di akhir laporan:

  [+] Security
  ...
  Hardening index : 62 [############.....]
  Tests performed : 238
  Suggestions     : 12
  Warnings        : 3

Kunci membacanya: Hardening index adalah skor komprehensif (semakin tinggi semakin baik), sedangkan Warnings dan Suggestions adalah daftar hal yang harus diperbaiki — untuk melihat detailnya, gulir ke bagian akhir laporan atau baca file /var/log/lynis-report.dat. Laporan lengkap tersimpan di /var/log/lynis.log.

Lynis tidak memperbaiki apa pun — ia menemukan masalah dan memberi rekomendasi. Tugas kalianlah yang menerapkannya satu per satu, lalu menjalankan audit ulang untuk melihat skor naik. Inilah siklus yang sehat: audit → perbaiki → audit ulang. Skor yang stagnan berarti hardening kalian tidak berkembang.

#Praktik: Checklist Hardening Server Ubuntu Baru

Saatnya menggabungkan semua prinsip menjadi satu checklist yang bisa langsung dipraktikkan pada server Ubuntu baru. Ikuti berurutan — setiap langkah membangun di atas langkah sebelumnya:

1. Update sistem. Server baru yang belum di-update adalah ladang kerentanan yang sudah diketahui. Ini langkah pertama yang tidak bisa ditawar:

sudo apt update && sudo apt upgrade -y

2. Buat user admin, non-root. Login sebagai root itu berbahaya (episode 10); buat user biasa dengan akses sudo:

sudo adduser arman
sudo usermod -aG sudo arman

3. Pasang kunci SSH, matikan password. Dari mesin lokal: salin kunci publik, lalu di server set PasswordAuthentication no di /etc/ssh/sshd_config (ikuti pola dari bagian Kunci SSH di atas).

4. Konfigurasi firewall (UFW). Buka hanya port yang dibutuhkan — SSH (22) dan web (80/443) — lalu aktifkan:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

5. Pasang fail2ban. Ikuti konfigurasi jail.local dari bagian sebelumnya, dengan ignoreip yang memuat IP manajemen kalian.

6. Aktifkan update keamanan otomatis. Kerentanan ditambal oleh vendor lebih cepat daripada kalian meng-update manual. unattended-upgrades memasang patch keamanan secara otomatis di latar belakang:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

7. Audit hasilnya. Tutup siklus dengan verifikasi: lynis audit system untuk skor keseluruhan, dan cek bahwa hanya port yang diizinkan yang terbuka:

ss -tlnp

Jalankan seluruh checklist ini dalam satu sesi yang tenang, bukan di tengah insiden. Server yang di-hardening dengan cara ini membutuhkan usaha sekali, tetapi hasilnya bertahan lama — dan setiap kali ada server baru, checklist yang sama bisa dipakai ulang persis, konsisten, dan teruji.

Ingat pula bahwa checklist adalah awal, bukan akhir. Server di production terus berubah: aplikasi baru menambah port, update vendor mengubah perilaku, tim baru menambah user. Hardening adalah proses yang harus di-review berkala — jadwalkan audit ulang bulanan dan perbarui checklist saat infrastruktur berevolusi. Checklist yang tidak pernah di-review adalah dokumentasi yang membusuk.

#Kesalahan Umum (Common Pitfalls)

1. setenforce 0 yang menjadi permanen. Mengubah /etc/selinux/config menjadi SELINUX=disabled untuk "menyelesaikan" masalah aplikasi adalah kesalahan yang paling mahal — seluruh lapisan MAC hilang tanpa disadari sampai terjadi insiden. Perbaiki policy-nya, bukan mematikan MAC.

2. Menganggap SELinux dan AppArmor itu sama. Keduanya adalah MAC tapi dengan tool, filosofi, dan log yang berbeda. sestatus untuk RHEL/Rocky, aa-status untuk Ubuntu. Salah mengecek membuat kalian mencari masalah di tempat yang salah.

3. Konfigurasi fail2ban yang mengunci diri sendiri. maxretry terlalu rendah, ignoreip tidak memuat IP manajemen, atau bantime terlalu lama — kombinasi yang membuat tim terkunci dari server. Uji di staging dan pastikan ada jalur pemulihan (misal console cloud) sebelum terapkan.

4. Menonaktifkan password SSH sebelum kunci terpasang. Urutan salah = lockout total. Pasang kunci, uji login, baru matikan PasswordAuthentication.

5. Lupa lapisan yang saling melengkapi. Memasang fail2ban tetapi tidak mengunci SSH, atau meng-update sekali lalu tidak pernah lagi. Hardening adalah berlapis dan berkelanjutan — satu lapisan saja tidak cukup, dan satu titik lemah mengalahkan semua lapisan lain.

#Penutup

Pada episode 25 ini, kalian telah membangun fondasi keamanan Linux menuju standar production. Kita membahas prinsip memperkecil attack surface dan least privilege, mengaudit service yang berjalan dan mematikan yang tidak dipakai, mengamankan SSH dengan kunci publik dan PasswordAuthentication no, memasang fail2ban untuk memblokir brute-force, memahami SELinux dan AppArmor sebagai lapisan MAC, melakukan audit dengan Lynis, dan menutup dengan checklist hardening server Ubuntu baru yang berurutan.

Poin kunci yang perlu kalian bawa:

• Hardening adalah memperkecil permukaan serangan dan membatasi kerusakan — bukan sekadar memasang tool.
• Autentikasi SSH berbasis kunci adalah kewajiban; aktifkan hanya setelah kunci teruji.
• fail2ban memblokir IP penyerang di firewall — tetapi salah konfigurasi bisa mengunci tim sendiri.
• SELinux (RHEL/Rocky) dan AppArmor (Ubuntu) adalah dua MAC yang berbeda; jangan pernah "menyelesaikan" masalah dengan mematikan MAC secara permanen.
• Lynis mengubah klaim keamanan menjadi skor yang bisa diukur dan dipertahankan.
• Checklist hardening adalah proses yang harus di-review berkala, bukan acara sekali jalan.

Sekarang server kalian sudah cepat (episode 24) dan aman (episode 25). Namun ada satu hal yang belum kita bicarakan: apa yang terjadi ketika semuanya gagal? Di episode 26 selanjutnya kita akan membahas Backup & Restore Strategy — prinsip 3-2-1, memilih tool yang tepat (rsync, tar, restic, borgbackup), backup database dengan benar, dan prosedur restore yang teruji. Karena pertahanan terbaik sekalipun tidak berarti tanpa rencana pemulihan. Pastikan tetap semangat!