Fail2ban läser loggar, räknar träffar mot ett reguljärt uttryck och lägger till en brandväggsregel när räknaren slår i taket. Hela nyttan sitter i konfigurationen — efter installationen är bara ett jail aktivt, och det för SSH.

Var inställningarna ska ligga

Filen /etc/fail2ban/jail.conf ska inte röras — den skrivs över vid paketuppdatering. Dina egna värden hör hemma i /etc/fail2ban/jail.local, som bara behöver innehålla det du ändrar.

[DEFAULT]
bantime  = 24h
findtime = 1h
maxretry = 5
ignoreip = 127.0.0.1/8 203.0.113.25

ignoreip är den rad du skriver först. Utan den blockerar du förr eller senare din egen adress, och sedan behövs konsolåtkomst via hostingpanelen för att komma in igen.

Om bantime

Standardvärdet på tio minuter är i praktiken meningslöst: en automatiserad lösenordsgissare kommer tillbaka och fortsätter. Ett dygn är ett rimligt minimum. Ännu bättre är stegvis ökning:

bantime.increment = true
bantime.factor    = 2
bantime.maxtime   = 30d

Då får den som återkommer allt längre blockeringar, medan en enstaka felslagen inloggning från en riktig användare inte straffas hårt.

Jails som är värda att slå på

sshd är redan igång. Har du stängt av lösenordsinloggning helt gör jailet ingen större nytta, men det skadar inte heller.

Webbserverns autentisering. Om något är skyddat med lösenord via servern:

[nginx-http-auth]
enabled = true

[apache-auth]
enabled = true

Inloggningsformuläret i din applikation. Här finns inget färdigt filter — sajtens lösenordsformulär skriver till applikationens egen logg i ett eget format. Filtret skriver du själv i /etc/fail2ban/filter.d/, och det är det jail som ger mest, eftersom det är precis där lösenord gissas.

Postfix och Dovecot, om servern hanterar e-post. E-postportar utsätts för minst lika mycket gissande som SSH.

recidive — ett jail som läser Fail2bans egen logg och ger långa blockeringar åt adresser som redan blockerats flera gånger:

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

Kontrollera att det verkligen fungerar

sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Det sista kommandot är det viktigaste och används alldeles för sällan. Det visar hur många rader i loggen filtret faktiskt matchar. Noll träffar betyder att jailet är igång men inte gör någonting — antingen är sökvägen till loggen fel eller så passar inte formatet.

Det är också den vanligaste orsaken till att Fail2ban ser ut att fungera men aldrig blockerar någon: på Debian 12 och Ubuntu 24.04 finns /var/log/auth.log inte längre som standard. Lösningen är antingen att installera rsyslog eller att peka jailet mot journalen:

[sshd]
backend = systemd

Att låsa upp sig själv

sudo fail2ban-client set sshd unbanip 203.0.113.25
sudo fail2ban-client unban --all

Värt att veta i förväg, inte i det ögonblick du är utelåst.

Vad Fail2ban inte klarar

Det arbetar på frekvens från en och samma adress. Ett distribuerat angrepp — tusen adresser med ett försök var — går rakt igenom, för ingen räknare når sitt tak. Det är en principiell begränsning, inte ett konfigurationsfel.

Det stoppar inte heller en sårbarhet i applikationen. En begäran som utnyttjar ett hål i ett tillägg lyckas första gången och lämnar ingen misslyckad inloggning efter sig. Fail2ban tar bort bakgrundsbruset; det ersätter inte uppdateringar i tid.

Det praktiska värdet syns i siffrorna över tid: hur många adresser som är blockerade nu, vilket jail som utlöses oftast, om antalet plötsligt ändrats. En jail som slutat träffa något är ett tecken på att en logg bytt plats — och det märks bara om någon tittar. Hur det ser ut på en sida visar demonstrationen nedan.