UFW vs Fail2Ban vs SSH Hardening: Kombinasi Wajib Keamanan Server Linux

Kalau kamu pegang server Linux (VPS, VM cloud, atau bare metal kecil), satu pertanyaan ini penting banget:

“Cukup nggak kalau cuma pasang firewall?”

Jawaban singkatnya: belum cukup.

Di lapangan, serangan yang paling sering itu bukan skenario film hacker super canggih, tapi hal-hal sederhana: brute force SSH, port terbuka yang kebablasan, service lupa di-hardening, atau kredensial bocor. Karena itu, pendekatan yang lebih aman bukan memilih satu tool saja, tapi menggabungkan beberapa lapis proteksi.

Di artikel ini kita bandingkan tiga komponen yang paling sering dipakai admin Linux:

UFW (firewall rule yang simpel)
Fail2Ban (auto-ban IP yang mencurigakan)
SSH Hardening (penguatan konfigurasi akses remote)

Kita bahas kelebihan, kekurangan, kapan dipakai, dan gimana menyusunnya jadi stack keamanan yang realistis buat production kecil-menengah.

Kalau kamu masih pemanasan di Linux CLI, baca dulu Linux Command Line Essential untuk Developer biar lebih gampang ngikutin command di bawah.

Kenapa pendekatan “berlapis” lebih aman?

Bayangin rumah:

UFW itu pagar + gerbang.
SSH hardening itu kunci pintu yang benar + aturan siapa boleh masuk.
Fail2Ban itu satpam yang langsung blok tamu mencurigakan.

Kalau cuma satu lapis, kebobolan lebih gampang. Kalau tiga lapis jalan bareng, attacker harus melewati banyak friksi.

Ini juga nyambung ke keyword cluster cybersecurity yang penting:

linux security hardening
secure shell scripting
basic incident response linux

Perbandingan cepat: UFW vs Fail2Ban vs SSH Hardening

Komponen	Fungsi utama	Kelebihan	Keterbatasan	Cocok untuk
UFW	Mengatur trafik masuk/keluar berbasis port/protokol	Mudah, cepat, minim salah konfigurasi dibanding iptables mentah	Tidak tahu konteks perilaku login	Semua server Linux
Fail2Ban	Mendeteksi pola gagal login lalu ban IP otomatis	Efektif lawan brute force	Perlu tuning regex/jail agar presisi	Server yang expose SSH/web auth
SSH Hardening	Menguatkan konfigurasi SSH (key auth, non-root, dsb)	Mengurangi attack surface paling signifikan	Salah setting bisa lockout admin sendiri	Wajib untuk server internet-facing

Kesimpulan cepat: bukan pilih salah satu. Kombinasi yang sehat adalah:

Hardening SSH dulu,
Batasi akses pakai UFW,
Tambah Fail2Ban untuk respons otomatis.

1) UFW: lapisan kontrol trafik paling cepat diterapkan

UFW (Uncomplicated Firewall) cocok banget buat baseline. Prinsipnya:

deny by default untuk incoming,
allow hanya port yang memang dipakai.

Contoh baseline aman:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Kalau SSH kamu pindah port (misalnya 2222), sesuaikan dulu rule UFW sebelum restart service SSH.

Praktik yang sering dilupakan

Batasi SSH hanya dari IP kantor/VPN kalau memungkinkan:

sudo ufw allow from 103.10.10.5 to any port 22 proto tcp

Cek port “nyasar” dari service lama.
Review rules berkala setelah deploy aplikasi baru.

Buat server yang juga handle reverse proxy, kamu bisa kaitkan ini dengan setup Nginx reverse proxy dan load balancer untuk production.

2) Fail2Ban: rem otomatis saat ada brute force

Fail2Ban mantau log (SSH, Nginx auth, dll), lalu ban IP yang melewati batas gagal login.

Install cepat:

sudo apt update
sudo apt install fail2ban -y

Buat konfigurasi lokal (jangan edit jail.conf langsung):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Contoh minimum untuk SSH di jail.local:

[sshd]
enabled = true
port = 22
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

Lalu restart:

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Tuning yang realistis

maxretry terlalu kecil bisa false positive (tim internal salah ketik password keban).
bantime terlalu pendek bikin attacker balik lagi cepat.
Mulai dari konservatif, lalu tuning pakai log nyata.

Kalau kamu suka notifikasi event security, kamu bisa adaptasi alur dari artikel Mail notification when SSH login untuk alert saat ban spike.

3) SSH Hardening: impact paling besar untuk menutup celah dasar

Banyak insiden kecil berawal dari SSH yang default banget. Ini checklist hardening yang aman buat mayoritas server:

Nonaktifkan root login
Paksa key-based authentication
Matikan password auth (kalau key sudah beres)
Batasi user yang boleh SSH
Opsional: ubah port SSH untuk kurangi noise bot

Contoh pengaturan di /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ops
MaxAuthTries 3
LoginGraceTime 30

Setelah ubah config:

sudo sshd -t
sudo systemctl restart ssh

Penting: selalu buka session SSH kedua sebelum restart service. Ini penyelamat kalau salah config.

Rekomendasi kombinasi berdasarkan kebutuhan

Skenario A: VPS kecil untuk blog/app pribadi

Wajib: UFW + SSH hardening
Tambahan: Fail2Ban untuk SSH
Monitoring: notifikasi login/ban harian

Skenario B: Server tim kecil (staging/production ringan)

Wajib: UFW + SSH hardening + Fail2Ban
Tambahan: restrict SSH by IP/VPN
Ops hygiene: audit user SSH per minggu

Skenario C: Host dengan banyak service publik

Wajib: tiga lapis + segmentasi jaringan
Tambahan: WAF/CDN, central log, alerting
Proses: playbook incident response dasar

Runbook implementasi 30 menit (praktis)

Urutan ini aman dan minim risiko lockout:

Pastikan SSH key sudah jalan untuk user non-root.
Terapkan UFW baseline dan pastikan port SSH yang benar sudah allow.
Terapkan SSH hardening bertahap (cek config tiap perubahan).
Install Fail2Ban dan aktifkan jail sshd.
Uji dari sisi client: login normal, login gagal berulang, verifikasi ban.
Simpan semua langkah dalam script idempotent.

Untuk langkah otomasi yang aman diulang, lihat pola di Idempotent Shell Script: Jalankan Berkali-kali Tanpa Bikin Berantakan.

Kesalahan umum yang bikin hardening gagal total

1) Menutup akses sendiri

Contoh klasik: ubah SSH config dulu, restart, ternyata UFW belum allow port yang benar.

Solusi: terapkan rule firewall dulu, verifikasi, baru restart SSH.

2) Gonta-ganti banyak setting sekaligus

Sulit tahu akar masalah saat error.

Solusi: ubah bertahap, satu blok per sekali uji.

3) Nggak ada rollback plan

Hardening tanpa recovery itu berjudi.

Solusi: simpan backup config:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

4) Nggak review log setelah deploy

Padahal log adalah feedback paling jujur.

Solusi: cek journal secara rutin:

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u fail2ban -n 100 --no-pager

Basic incident response Linux (versi ringkas)

Kalau kamu curiga ada brute force atau anomali:

Identifikasi cepat
- cek login gagal/sukses tak biasa,
- cek IP paling aktif,
- cek service yang restart berulang.
Containment
- ban IP mencurigakan,
- temporary close port non-kritis,
- rotate credential yang berisiko.
Eradication
- patch package,
- hardening ulang config lemah,
- bersihkan key/user yang tidak dikenal.
Recovery
- kembalikan service bertahap,
- pantau metrics dan log 24 jam.
Lessons learned
- update SOP,
- jadikan temuan sebagai checklist deploy berikutnya.

Tool sederhana seperti command di Linux shell command yang sering dipakai developer modern sangat bantu investigasi cepat di terminal.

Jadi, pilih yang mana?

Kalau harus jujur: pilih semuanya, tapi urutannya benar.

Mulai dari SSH hardening (impact paling besar).
Kunci trafik pakai UFW (baseline kuat).
Tambah Fail2Ban (deteksi + respon otomatis).

Untuk kebanyakan server Linux modern, kombinasi ini sudah memberi peningkatan keamanan yang signifikan tanpa kompleksitas berlebihan.

Mulai dari yang simpel, konsisten review, dan dokumentasikan konfigurasi supaya bisa diulang dengan aman.

FAQ

Apakah ubah port SSH wajib untuk keamanan?

Tidak wajib, tapi membantu mengurangi noise dari bot otomatis. Ini bukan pengganti key auth, firewall, dan hardening inti.

Lebih penting mana: UFW atau Fail2Ban?

Untuk baseline, UFW lebih dulu karena dia menentukan pintu masuk trafik. Fail2Ban melengkapi dengan respon dinamis terhadap perilaku mencurigakan.

Kalau PasswordAuthentication dimatikan, gimana akses darurat?

Siapkan minimal dua key aktif (misalnya laptop utama + key cadangan terenkripsi) dan simpan akses console/provider cloud sebagai jalur recovery.

Seberapa sering aturan keamanan harus direview?

Minimal bulanan, atau setiap ada perubahan arsitektur/deploy besar. Review cepat mingguan juga bagus untuk server publik.

Apakah stack ini cukup untuk production skala besar?

Untuk banyak use case, ini fondasi yang bagus. Tapi skala besar tetap butuh lapisan tambahan: central logging, IDS/IPS, WAF, SIEM, dan kontrol akses berbasis jaringan/VPN.