Fail2ban læser logfiler, tæller træf mod et regulært udtryk og tilføjer en firewallregel, når tælleren når loftet. Hele nytten ligger i opsætningen — efter installationen er kun ét jail aktivt, og det gælder SSH.

Hvor indstillingerne skal ligge

Filen /etc/fail2ban/jail.conf må ikke røres — den overskrives ved pakkeopdatering. Dine egne værdier hører hjemme i /etc/fail2ban/jail.local, som kun behøver at indeholde det, du ændrer.

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

ignoreip er den linje, du skriver først. Uden den blokerer du før eller siden din egen adresse, og så kræves konsoladgang via hostingpanelet for at komme ind igen.

Om bantime

Standardværdien på ti minutter er i praksis meningsløs: en automatisk adgangskodegætter vender tilbage og fortsætter. Et døgn er et rimeligt minimum. Endnu bedre er trinvis forøgelse:

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

Så får den, der vender tilbage, stadig længere blokeringer, mens et enkelt mislykket login fra en rigtig bruger ikke straffes hårdt.

Jails der er værd at slå til

sshd kører allerede. Har du slået adgangskodelogin helt fra, gør jailet ikke megen nytte, men det skader heller ikke.

Webserverens godkendelse. Hvis noget er adgangskodebeskyttet via serveren:

[nginx-http-auth]
enabled = true

[apache-auth]
enabled = true

Loginformularen i din applikation. Her findes intet færdigt filter — hjemmesidens adgangskodeformular skriver til applikationens egen logfil i sit eget format. Filteret skriver du selv i /etc/fail2ban/filter.d/, og det er det jail, der giver mest, da det er præcis der, adgangskoder gættes.

Postfix og Dovecot, hvis serveren håndterer e-mail. E-mailporte udsættes for mindst lige så meget gætteri som SSH.

recidive — et jail, der læser Fail2bans egen logfil og giver lange blokeringer til adresser, der allerede er blokeret flere gange:

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

Kontrollér at det rent 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 sidste kommando er den vigtigste og bruges alt for sjældent. Den viser, hvor mange linjer i logfilen filteret rent faktisk rammer. Nul træf betyder, at jailet kører uden at gøre noget — enten er stien til logfilen forkert, eller også passer formatet ikke.

Det er også den hyppigste grund til, at Fail2ban ser ud til at virke uden at blokere nogen: på Debian 12 og Ubuntu 24.04 findes /var/log/auth.log ikke længere som standard. Løsningen er enten at installere rsyslog eller at pege jailet mod journalen:

[sshd]
backend = systemd

At låse sig selv op

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

Værd at vide på forhånd, ikke i det øjeblik du står udenfor.

Hvad Fail2ban ikke klarer

Det arbejder på frekvens fra én og samme adresse. Et distribueret angreb — tusind adresser med ét forsøg hver — går lige igennem, for ingen tæller når sit loft. Det er en principiel begrænsning, ikke en opsætningsfejl.

Det stopper heller ikke en sårbarhed i applikationen. En forespørgsel, der udnytter et hul i en udvidelse, lykkes første gang og efterlader intet mislykket login. Fail2ban fjerner baggrundsstøjen; det erstatter ikke opdateringer i tide.

Den praktiske værdi viser sig i tallene over tid: hvor mange adresser der er blokeret nu, hvilket jail der udløses oftest, om antallet pludselig har ændret sig. Et jail, der er holdt op med at ramme noget, er et tegn på, at en logfil har flyttet sig — og det bemærkes kun, hvis nogen ser efter. Hvordan det ser ud på én side, viser demonstrationen nedenfor.