Di episode #6 kita sudah kenal port, firewall, dan VPN dari sisi jaringan. Kali ini saya mau turun satu tingkat: ke mesinnya sendiri. Server Linux yang saya sewa ternyata dari pabriknya tidak “siap tempur” — service berjalan, port terbuka, login root masih boleh lewat password. Hardening menurut saya seperti menyiapkan rumah baru: sebelum pindah barang berharga, kita pasang kunci pintu, gerbang, dan CCTV dulu. Saya catat 5 lapis yang saya kerjakan berurutan.
1. SSH key-only — tutup pintu belakang
Pelajaran dari episode #3: password itu paling lemah saat penyerang bisa menebak tanpa batas. Di internet, SSH port 22 adalah pintu yang paling rutin diketuk bot sepanjang hari. Solusinya bukan password lebih rumit, tapi mengganti mekanismenya: kunci SSH. Server hanya menerima pemegang kunci privat yang cocok dengan authorized_keys-nya — tebak-menebak tidak berlaku lagi.
Empat baris di /etc/ssh/sshd_config yang saya ubah, lalu systemctl restart ssh:
PasswordAuthentication no PermitRootLogin prohibit-password PubkeyAuthentication yes MaxAuthTries 3
Nilai prohibit-password untuk root (alias lamanya without-password sudah deprecated) artinya root masih boleh login, tapi hanya dengan kunci — tidak pernah dengan password. Catatan versi: OpenSSH 10.6 rilis 6 Oktober 2026 dan di rilis-rilis terbaru mereka memperbaiki beberapa isu terkait opsi restrict di authorized_keys — jadi selain konfigurasi, pastikan paket OpenSSH-nya juga ikut di-update. Contoh kenapa ini penting: CVE-2024-6387 (“regreSSHion”, diumumkan Qualys 1 Juli 2024) adalah race condition di signal handler sshd yang berpotensi remote code execution sebagai root pada sistem Linux berbasis glibc — celah yang merupakan regresi dari masalah lama CVE-2006-5051. Update rutin = lapisan pertahanan yang murah.
2. Firewall (ufw) — hanya port yang sengaja dibuka
Di episode #6 firewall dijelaskan sebagai gerbang; di Ubuntu, gerbang itu bernama ufw. Prinsip yang saya pakai: default ditolak, izin diberikan satu per satu sesuai kebutuhan. Sederhana, tapi ini yang membuat server terasa “tidak terlihat” dari pemindai port.
ufw default deny incoming ufw default allow outgoing ufw allow 22/tcp # SSH, hanya kalau memang perlu ufw allow 80,443/tcp ufw enable ufw status verbose
Kebiasaan yang saya jaga: buka port SSH di jaringan kantor/rumah saja bila memungkinkan, bukan 0.0.0.0/0. Firewall menolak di lapisan jaringan — ia tidak peduli apakah login-nya sah atau tidak.
3. fail2ban — penjaga yang menghitung kegagalan
Firewall menolak semua yang tidak diizinkan, tapi bagaimana dengan IP yang terus mencoba password? Di sinilah fail2ban bekerja: ia membaca log login, menghitung kegagalan, lalu memblokir IP nakal sementara. Konsepnya satu “jail” = sumber log + filter (pola kegagalan) + aksi (blokir). Tiga angka mengatur semuanya — default di jail.conf: bantime 10 menit, findtime 10 menit, maxretry 5.
| Setting | Default | Makna |
|---|---|---|
| maxretry | 5 | Jumlah kegagalan yang diperbolehkan |
| findtime | 10m | Jendela waktu penghitungan kegagalan |
| bantime | 10m | Lama IP diblokir |
Aturan praktis yang saya pelajari dari dokumentasinya: jangan edit jail.conf langsung (akan ditimpa saat update paket) — tulis konfigurasi sendiri di /etc/fail2ban/jail.local atau file drop-in di /etc/fail2ban/jail.d/. Untuk server modern, set backend = systemd supaya fail2ban membaca kegagalan dari journal, bukan menunggu file /var/log/auth.log yang belum tentu ada. Dan jangan lupa masukkan IP admin sendiri ke ignoreip — pernah dengar cerita orang mengunci dirinya sendiri keluar server; itu pengalaman belajar yang mahal.
4. Permission ketat — siapa boleh baca apa
Lapis keempat bukan soal service, tapi soal file. Prinsip least privilege: hanya owner yang perlu, yang boleh menyentuh. File shadow dan private key seharusnya 600 (hanya owner), direktori web jangan 777 (semua orang boleh tulis — ini temuan klasik di instalasi CMS lama), dan proses web sebaiknya berjalan sebagai user non-root. Saya biasa cek cepat:
ls -la /etc/shadow ~/.ssh/id_ed25519 find /var/www -perm -o+w -type d # cari direktori world-writable
5. Audit log — bukti kalau tidak ada yang berubah
Pertahanan tanpa pengawasan ibarat rumah ber pagar tapi tanpa CCTV: kita tidak tahu apakah ada yang pernah masuk. Linux punya auditd yang mencatat aktivitas sistem di /var/log/audit/audit.log. Saya mulai dari aturan minimal — catat setiap eksekusi program dengan key supaya mudah dicari via ausearch:
# /etc/audit/rules.d/execve.conf -a always,exit -F arch=b64 -S execve -k exec_trace # lalu: augenrules --load && ausearch -k exec_trace
Catatan jujur: auditd ini gampang bikin log membesar, jadi saya hanya aktifkan aturan yang memang ingin saya awasi, bukan semuanya sekaligus. Log juga baru berguna kalau diamankan — kalau penyerang sudah masuk, log adalah hal pertama yang ia hapus. Itu sebabnya pengiriman log ke mesin lain (remote log) adalah langkah lanjutan yang layak dipelajari, dan kalau kita perlu memverifikasi bahwa sebuah file log belum diubah, di episode #13 kemarin kita sudah bahas hash dan tanda tangan digital — dua alat tepat untuk itu.
Yang saya dapat
Hardening bukan proyek sekali jadi, tapi daftar periksa yang kembali saya evaluasi tiap kali setup server baru. Lima lapis di atas tidak menjamin 100% aman — tidak ada yang bisa menjamin itu — tapi secara drastis menaikkan biaya penyerang. Bot otomatis yang dulu bisa menggedor pintu saya seharian sekarang berhenti di lapis pertama: tidak ada password untuk ditebak, dan IP-nya sudah diblokir fail2ban sebelum sempat mencoba serius. Di episode berikutnya kita naik satu level lagi: keamanan cloud, di mana tanggung jawab berbagi antara kita dan provider.
Sumber
- OpenSSH Release Notes — rilis 10.6 (6 Okt 2026) & catatan perubahan opsi sshd
- Qualys — regreSSHion (CVE-2024-6387), 1 Juli 2024
- fail2ban — jail.conf (default bantime/findtime/maxretry)
- Linux man page — audit.rules(7) sintaks aturan audit kernel
- Debian man page — auditctl(8) & ausearch(8)
- Ubuntu Wiki — UncomplicatedFirewall (ufw)
Komentar Terbaru