Fail2ban dipasang paling awal dan biasanya berhenti di situ juga: paket terpasang, layanan berjalan, sshd tampaknya sudah terlindungi. Enam bulan kemudian barulah ketahuan bahwa jail sedang membaca berkas yang tidak ada di sistem ini, dan semua sisanya — surat, panel kendali, formulir login situs — tidak pernah terlindungi sama sekali.

Mari kita telusuri apa yang layak diaktifkan pada VPS biasa dengan situs, angka berapa yang perlu dipasang, dan bagaimana memastikan jail benar-benar bekerja alih-alih sekadar hadir di berkas konfigurasi.

Periksa dulu apakah sshd menangkap sesuatu

Satu perintah:

sudo fail2ban-client status sshd

Keluarannya memuat baris Currently failed, Total failed dan Total banned. Kalau pada server yang sudah setidaknya sehari berada di internet nilai Total failed nol, berarti jail tidak bekerja. Bandingkan dengan kenyataan:

sudo lastb | wc -l

Ribuan percobaan gagal di lastb berbanding angka nol di Fail2ban hanya berarti satu hal: filter melihat ke tempat yang salah.

Penyebab paling umum adalah Debian 12. Ia tidak lagi memasang rsyslog secara bawaan, berkas /var/log/auth.log memang tidak ada, dan jail sshd standar justru disetel membaca berkas itu. Tidak ada galat apa pun yang memberi tahu soal ini: layanan menyala, status tampil, pencacah tetap nol. Perbaikannya adalah beralih ke jurnal systemd:

[sshd]
enabled = true
backend = systemd

Pilihan lain adalah mengembalikan rsyslog sebagai paket, kalau auth.log berupa teks biasa diperlukan perkakas lain. Ubuntu 24.04 berperilaku sama persis.

Di mana meletakkan pengaturan sendiri

Jangan sentuh /etc/fail2ban/jail.conf: saat paket diperbarui berkas itu ditimpa, dan setiap suntingan yang dibuat di sana suatu hari akan hilang diam-diam. Pengaturan Anda sendiri masuk ke /etc/fail2ban/jail.local — berkas ini dibaca terakhir dan mengalahkan berkas umum.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.25
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd

ignoreip dengan alamat Anda sendiri bukan kemewahan melainkan asuransi: mengunci diri sendiri di luar karena salah ketik lebih gampang daripada yang terdengar. Kalau tidak punya alamat tetap, sediakan jalan masuk kedua selain SSH — konsol penyedia atau VNC.

Jail yang mengubah gambaran: recidive

Jail biasa punya ingatan pendek: lima percobaan dalam sepuluh menit, blokir satu jam, lalu satu jam kemudian semuanya dimulai lagi. Bot hidup nyaman dengan itu dan akan kembali besok maupun lusa. recidive menutup persis celah itu: ia tidak membaca log sistem melainkan log Fail2ban sendiri, artinya ia memblokir siapa yang sudah diblokir Fail2ban.

[recidive]
enabled  = true
bantime  = 1w
findtime = 1d
maxretry = 5

Bacalah begini: «diblokir lima kali dalam sehari — pergi selama seminggu». Jail ini memerlukan berkas /var/log/fail2ban.log, jadi kalau Anda memindahkan pencatatan Fail2ban sendiri ke syslog maka recidive juga akan memerlukan backend = systemd.

Dalam praktiknya efek satu jail ini biasanya lebih terasa daripada menyetel halus semua yang lain: para pelanggan tetap berguguran dan di log tinggal latar belakang yang segar saja.

Apa lagi yang perlu diaktifkan kalau server punya situs

Menurut urutan kegunaan yang menurun:

  • nginx-http-auth atau apache-auth — penebakan kata sandi pada autentikasi dasar. Diperlukan kalau area admin atau situs staging berada di balik kata sandi server web;
  • nginx-botsearch — pencarian jalur yang sudah dikenal: /wp-login.php, /phpmyadmin, /.env. Itu bukan pembobolan melainkan pengintaian, dan itulah yang mendahului segalanya;
  • nginx-limit-req — hanya bekerja kalau di Nginx sendiri ada limit_req_zone; tanpa itu jail aktif tetapi tidak berguna;
  • postfix-sasl dan dovecot — wajib kalau Anda menjalankan surat sendiri. Penebakan kata sandi kotak surat berlangsung terus-menerus dan biasanya tidak diawasi siapa pun.
[nginx-botsearch]
enabled = true
logpath = /var/log/nginx/access.log

Formulir login situs sendiri adalah cerita tersendiri. Aplikasi tidak punya log login gagal miliknya sendiri, dan di access.log percobaan gagal terlihat seperti POST biasa dengan kode 200 atau 302 — tak terbedakan dari yang berhasil oleh filter umum mana pun. Ada dua jalan: minta aplikasi menulis kegagalan ke syslog (kebanyakan sistem manajemen konten punya plugin untuk itu), atau batasi laju permintaan ke halaman login. Yang kedua adalah pembatas, bukan pendeteksi, dan lebih baik mengetahui itu sejak awal.

Angka-angkanya

bantime = 10m adalah nilai bawaan yang membuat orang menganggap Fail2ban tidak berguna: sepuluh menit cukup bagi bot untuk kembali. Satu jam untuk blokir pertama ditambah recidive selama seminggu bekerja jauh lebih baik daripada blokir permanen, yang seiring waktu berubah menjadi daftar aturan sepanjang berkilo-kilo.

maxretry = 3 untuk SSH adalah cara andal mengunci diri sendiri di luar. Lima percobaan dalam sepuluh menit sama baiknya dalam memotong penebakan kata sandi.

Penebakan lambat — satu percobaan setiap lima menit — tidak akan pernah masuk ke dalam findtime. Itu bukan alasan untuk merentangkan jendela menjadi sehari: Anda akan mendapat blokir keliru terhadap rekan Anda sendiri. Yang mempan terhadap penebakan lambat bukanlah ambang batas melainkan mematikan autentikasi kata sandi.

Pastikan blokirnya sampai ke paket data

Fail2ban hanya memanggil sebuah perintah eksternal. Kalau banaction tidak cocok dengan apa yang benar-benar menyaring lalu lintas, log akan penuh baris Ban 198.51.100.7 yang riang sementara paket tetap berdatangan. Debian 12 secara bawaan memakai nftables, dan bila UFW aktif maka pilihan yang benar adalah banaction = ufw. Untuk memeriksa:

sudo nft list ruleset | grep -c f2b
sudo iptables -S | grep f2b

Setidaknya salah satu dari keduanya harus menampilkan aturan. Dan filternya sendiri bisa diuji tanpa menunggu serangan:

sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf

Di bagian bawah keluaran tertulis berapa baris yang cocok. Nol berarti filter dan log tidak bertemu, dan tidak ada gunanya menyetel apa pun lebih lanjut.

Yang tidak dilakukan Fail2ban

Ia tidak melindungi dari penebakan terdistribusi: seribu alamat dengan satu percobaan masing-masing tidak akan pernah mencapai ambang dengan pengaturan apa pun. Ia tidak menghilangkan penyebab — alamat yang diblokir tidak membatalkan kata sandi yang lemah. Dan ia tidak tahu apa-apa soal reputasi: alamat yang kemarin menghabiskan waktu membobol server orang lain masih bersih di matanya sampai ia mulai dengan Anda. Dari sinilah muncul kombinasi yang dipakai dalam praktik: kunci alih-alih kata sandi, Fail2ban sebagai pembatas kebisingan, dan daftar blokir bersama (CrowdSec) sebagai pengetahuan dari pengalaman orang lain.

Masalah tersendiri adalah semua ini sesekali perlu dilihat. Tidak ada yang mengetik fail2ban-client status untuk tiap jail selama berminggu-minggu, dan jumlah blokir yang meningkat baru diperhatikan ketika sesuatu sudah rusak. Pada halaman demo di bawah, data yang sama berada dalam satu halaman: daftar jail, siapa yang sedang diblokir, dan percobaan datang dari mana.