Fail2ban leser logger, teller treff mot et regulært uttrykk og legger til en brannmurregel når telleren når taket. Hele nytten ligger i oppsettet — etter installasjonen er bare ett jail aktivt, og det gjelder SSH.

Hvor innstillingene skal ligge

Filen /etc/fail2ban/jail.conf skal ikke røres — den overskrives ved pakkeoppdatering. Dine egne verdier hører hjemme i /etc/fail2ban/jail.local, som bare trenger å inneholde det du endrer.

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

ignoreip er linjen du skriver først. Uten den blokkerer du før eller siden din egen adresse, og da trengs konsolltilgang via hostingpanelet for å komme inn igjen.

Om bantime

Standardverdien på ti minutter er i praksis meningsløs: en automatisk passordgjetter kommer tilbake og fortsetter. Ett døgn er et rimelig minimum. Enda bedre er trinnvis økning:

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

Da får den som kommer tilbake stadig lengre blokkeringer, mens en enkelt mislykket innlogging fra en ekte bruker ikke straffes hardt.

Jails som er verdt å slå på

sshd kjører allerede. Har du slått av passordinnlogging helt, gjør jailet lite nytte, men det skader heller ikke.

Webserverens autentisering. Hvis noe er passordbeskyttet via serveren:

[nginx-http-auth]
enabled = true

[apache-auth]
enabled = true

Innloggingsskjemaet i applikasjonen din. Her finnes det ikke noe ferdig filter — nettstedets passordskjema skriver til applikasjonens egen logg i eget format. Filteret skriver du selv i /etc/fail2ban/filter.d/, og det er det jailet som gir mest, siden det er nettopp der passord gjettes.

Postfix og Dovecot, dersom serveren håndterer e-post. E-postporter utsettes for minst like mye gjetting som SSH.

recidive — et jail som leser Fail2bans egen logg og gir lange blokkeringer til adresser som allerede er blokkert flere ganger:

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

Kontroller at det faktisk virker

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

Den siste kommandoen er den viktigste og brukes altfor sjelden. Den viser hvor mange linjer i loggen filteret faktisk treffer. Null treff betyr at jailet kjører uten å gjøre noe — enten er stien til loggen feil, eller så passer ikke formatet.

Det er også den vanligste grunnen til at Fail2ban ser ut til å virke uten å blokkere noen: på Debian 12 og Ubuntu 24.04 finnes /var/log/auth.log ikke lenger som standard. Løsningen er enten å installere rsyslog eller å peke jailet mot journalen:

[sshd]
backend = systemd

Å låse opp seg selv

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

Verdt å vite på forhånd, ikke i det øyeblikket du står utenfor.

Hva Fail2ban ikke klarer

Det arbeider på frekvens fra én og samme adresse. Et distribuert angrep — tusen adresser med ett forsøk hver — går rett gjennom, for ingen teller når taket sitt. Det er en prinsipiell begrensning, ikke en oppsettsfeil.

Det stopper heller ikke en sårbarhet i applikasjonen. En forespørsel som utnytter et hull i en utvidelse, lykkes første gang og etterlater ingen mislykket innlogging. Fail2ban fjerner bakgrunnsstøyen; det erstatter ikke oppdateringer i tide.

Den praktiske verdien viser seg i tallene over tid: hvor mange adresser som er blokkert nå, hvilket jail som utløses oftest, om antallet plutselig har endret seg. Et jail som har sluttet å treffe noe, er et tegn på at en logg har flyttet seg — og det merkes bare hvis noen ser etter. Hvordan det ser ut på én side, viser demonstrasjonen nedenfor.