Konfigurasi Firewall Otomatis untuk Menahan Brute Force di Server Linux

TL;DR

• Untuk host Linux yang terekspos internet, kombinasi ufw dan fail2ban biasanya cukup untuk menurunkan noise brute force tanpa membuat operasi harian menjadi rapuh.
• Desain yang sehat memakai ban temporer, allowlist yang eksplisit, dan verifikasi log path yang benar.
• Targetnya bukan memblokir seluruh internet, tetapi menjaga jalur admin tetap aman dan host tetap operable.

Pendahuluan

Server yang terekspos ke internet akan menerima noise hampir terus-menerus: percobaan login SSH, scan port, dan credential stuffing dasar. Banyak admin baru merespons ini dengan memblokir IP satu per satu atau memasang rule firewall yang terlalu kasar. Keduanya tidak skala. Yang dibutuhkan adalah model otomasi yang cukup agresif untuk menurunkan noise, tetapi tidak cukup bodoh untuk memblokir trafik sah saat log melonjak.

Brute force hardening yang sehat bukan hanya soal menambah deny rule. Ia bergantung pada kualitas sinyal, jendela waktu yang tepat, daftar allowlist yang disiplin, dan keputusan kapan blokir sementara lebih baik daripada blokir permanen.

Prerequisites

• Ubuntu 22.04 LTS atau distro Linux setara yang memakai systemd.
• Akses sudo atau root ke host target.
• SSH sudah aktif dan Anda punya minimal satu sesi shell lain yang tetap terbuka saat mengubah firewall.
• Paket dasar tersedia: openssh-server, ufw, fail2ban, journalctl.
• Jika server berada di belakang cloud firewall atau load balancer, Anda memahami IP sumber yang benar-benar muncul di log.

Problem di Production

Masalah di produksi bukan hanya banyaknya percobaan login, tetapi kecenderungan tim bereaksi berlebihan. Rule kasar yang tampak aman sering justru memblokir traffic sah, mengunci admin, atau memperburuk proses incident response saat akses darurat diperlukan. Noise yang tidak terkendali juga membuat sinyal serangan yang relevan tertutup banjir log yang monoton.

Mental Model

Anggap brute force sebagai persoalan rate, bukan identitas lawan. Sistem tidak perlu tahu siapa penyerang; sistem hanya perlu membedakan pola akses normal dari pola gagal yang berulang dalam window tertentu. Karena itu, desain yang baik bertumpu pada threshold, allowlist, dan expiry yang eksplisit.

Konsep Utama

Firewall statis tidak cukup

Rule dasar seperti hanya membuka port yang diperlukan memang wajib, tetapi brute force adalah masalah perilaku, bukan hanya exposure. Kita perlu layer yang bisa melihat percobaan gagal berulang lalu merespons otomatis.

Sumber sinyal harus jelas

Automation umumnya membaca log SSH, reverse proxy, atau service auth lain. Jika format log berubah, parsing rusak, atau timezone kacau, maka automation bisa diam saat dibutuhkan atau justru memblokir sumber yang salah.

Rate limit dan ban sementara sering lebih aman

Ban permanen terlihat tegas, tetapi sering menciptakan daftar yang menumpuk tanpa manfaat jangka panjang. Untuk serangan internet umum, rate limit dan ban sementara dengan TTL biasanya lebih waras.

Architecture / Context

Sistem yang kita bangun terdiri dari tiga lapisan. Lapisan pertama adalah host firewall untuk membatasi port yang memang boleh diakses. Lapisan kedua adalah SSH daemon sebagai service admin utama. Lapisan ketiga adalah automation berbasis log yang menambahkan temporary ban saat pola gagal melebihi threshold.

Dalam lingkungan produksi, pola ini biasanya duduk di bawah cloud security group atau provider firewall. Host firewall tetap penting karena ia memberi guardrail terakhir ketika cloud-side policy terlalu lebar, salah environment, atau tidak cukup granular untuk event lokal di host.

Arsitektur / Cara Kerja

Arsitektur minimal yang praktis untuk Linux biasanya terdiri dari:

1. firewall host dengan default deny untuk inbound yang tidak dipakai
2. service log yang konsisten
3. automation layer seperti fail2ban atau watcher log
4. allowlist untuk IP admin atau VPN ingress
5. alert sederhana agar blokir yang berlebihan cepat terlihat

Alur kerjanya sederhana tetapi efektif. Log auth dibaca terus-menerus. Jika threshold gagal tercapai dalam window tertentu, automation menambah ban sementara pada firewall backend. Setelah TTL habis, IP bisa keluar dari ban secara otomatis. Pola ini menahan noise tanpa membuat daftar block tumbuh tanpa kontrol.

Practical Implementation

Step 1: Install paket yang dibutuhkan

Tujuannya memastikan host punya firewall dan ban engine yang konsisten.

sudo apt update
sudo apt install -y ufw fail2ban

Step 2: Tentukan jalur admin yang sah

Sebelum mengaktifkan firewall, izinkan akses yang memang dibutuhkan. Jika Anda memakai VPN atau bastion, batasi ke source tersebut.

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

Jika SSH berjalan di port non-standar, ganti 22/tcp dengan port yang benar. Jangan aktifkan rule baru tanpa satu sesi shell cadangan.

Step 3: Buat konfigurasi jail lokal Fail2ban

Jangan mengubah file bawaan langsung. Simpan override di jail.local.

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd
ignoreip = 127.0.0.1/8 10.0.0.0/8 192.168.0.0/16

[sshd]
enabled = true
port    = 22
mode    = normal
logpath = %(sshd_log)s
EOF

Jika source IP asli datang dari reverse proxy atau bastion, sesuaikan ignoreip dan pastikan Anda tidak mem-ban jalur admin sendiri.

Step 4: Restart dan aktifkan Fail2ban

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Step 5: Keras-kan SSH agar surface area lebih kecil

Ban engine membantu, tetapi tetap lebih baik jika SSH sendiri dipersempit.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
PubkeyAuthentication yes
EOF
sudo systemctl restart ssh

Jangan menonaktifkan password authentication sebelum memastikan key-based login benar-benar berfungsi.

Step 6: Tambahkan status check yang mudah dipakai operator

Langkah ini bukan keharusan teknis, tetapi sangat membantu saat triage.

sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo journalctl -u fail2ban --since "15 min ago"

Verification

Lakukan verifikasi setelah perubahan, bukan hanya restart service.

sudo systemctl status ufw
sudo systemctl status fail2ban
sudo fail2ban-client ping
sudo fail2ban-client status sshd
sudo ss -tulpn | grep ':22 '

Tanda berhasil:

• ufw dan fail2ban berada pada status active (running).
• fail2ban-client ping mengembalikan Server replied: pong.
• jail sshd muncul sebagai enabled.
• port admin yang Anda izinkan tetap bisa diakses dari jalur yang benar.

Jika ingin menguji rule secara aman, lakukan beberapa login gagal dari host uji terpisah lalu cek apakah IP tersebut masuk daftar ban sementara.

Troubleshooting

Fail2ban aktif tetapi tidak pernah memban IP

Penyebab paling umum adalah backend atau logpath salah. Cek apakah host memakai systemd journal atau file log tradisional.

sudo journalctl -u ssh --since "10 min ago"
sudo fail2ban-regex systemd-journal sshd

Admin ikut terban

Biasanya ignoreip tidak memasukkan jalur admin yang sah, atau source IP sebenarnya berubah karena NAT/VPN.

sudo fail2ban-client set sshd unbanip 203.0.113.10
sudo fail2ban-client get sshd ignoreip

UFW aktif tetapi service sah ikut terblokir

Periksa rule ordering dan port yang sebenarnya dipakai aplikasi.

sudo ufw status numbered
sudo ss -tulpn

Production Notes

• Host firewall tidak menggantikan cloud firewall. Gunakan keduanya dengan boundary yang jelas.
• Kirim log fail2ban dan auth log ke central logging agar perubahan ban bisa diaudit.
• Pantau jumlah ban per jam. Lonjakan mendadak bisa berarti serangan meningkat atau konfigurasi terlalu sensitif.
• Untuk fleet besar, pertimbangkan policy terpusat di provider edge agar host tidak memikul seluruh beban noise internet.

Studi Kasus / Masalah Nyata

Admin ikut terkunci

Tanpa allowlist atau jalur VPN, admin yang salah mengetik password beberapa kali dapat memblokir dirinya sendiri. Saat itu terjadi di server tunggal tanpa akses out-of-band, gangguannya terasa sangat nyata.

Parsing log rusak setelah upgrade

Service auth diperbarui dan pola log berubah sedikit. Automation masih berjalan, tetapi tidak lagi mengenali kegagalan login. Dari luar terlihat semua aman, padahal layer otomatis sudah buta.

Rate limit terlalu sensitif

Sebuah aplikasi internal yang memakai password manager lama memicu beberapa retry sah, lalu diblokir seperti attacker. Ini contoh bahwa threshold harus mempertimbangkan perilaku user normal.

Trade-offs

• Threshold agresif menurunkan noise lebih cepat, tetapi menaikkan peluang false positive.
• Allowlist memudahkan operasi admin, tetapi perlu dijaga ketat agar tidak berubah menjadi bypass permanen.
• Host-based ban cepat dipasang, tetapi edge-based ban biasanya lebih hemat resource untuk skala trafik yang lebih besar.

Best Practices

Lindungi SSH dengan beberapa lapisan

Kurangi permukaan dengan key-based auth, user terbatas, dan jalur admin yang tidak langsung terbuka ke seluruh internet jika itu memungkinkan.

Jadikan automation bisa diaudit

Ban harus memiliki alasan, timestamp, dan TTL yang jelas. Jika tidak, troubleshooting akan berubah menjadi tebak-tebakan.

Bedakan internet noise dan serangan yang relevan

Banyak brute force internet hanya menambah log. Jangan sampai tim menghabiskan energi berlebihan untuk noise, tetapi juga jangan membiarkan noise tersebut mengaburkan sinyal insiden yang nyata.

Failure Modes

• Format log berubah setelah upgrade sehingga automation berhenti mendeteksi percobaan gagal.
• Admin ikut terban karena tidak ada allowlist atau jalur akses cadangan.
• Ban menumpuk terlalu lama dan menyulitkan troubleshooting karena status tidak pernah dibersihkan.

Kesalahan Umum

• membiarkan terlalu banyak port publik terbuka lalu berharap automation menyelesaikan semuanya
• memblokir permanen tanpa review atau expiry
• tidak punya allowlist untuk jalur admin yang sah
• menggantungkan keamanan hanya pada perubahan port SSH
• tidak memantau apakah automation masih membaca log dengan benar

Kesimpulan

Firewall otomatis yang sehat untuk brute force di Linux harus bertumpu pada log yang dapat dipercaya, ban sementara yang proporsional, dan jalur admin yang tetap aman. Tujuannya bukan menciptakan rule sebanyak mungkin, tetapi mengurangi noise dan menjaga service tetap dapat dioperasikan.