Fail2ban installeren op Ubuntu 24.04 tegen SSH bots

Wat Fail2ban daadwerkelijk doet

Fail2ban is een daemon die logbestanden uitleest. Het programma monitort uw SSH-authenticatieberichten en voert, na een aantal mislukte pogingen vanaf hetzelfde adres binnen een kort tijdsbestek, een firewall-commando uit dat dit adres tijdelijk blokkeert. Dat is het volledige concept. Het bestaat uit ongeveer dertig regels configuratie in één bestand, en op Ubuntu 24.04 is de installatie een enkel apt-commando waarmee u beschermd bent nog voordat u iets heeft aangepast.

Wees duidelijk over wat het wel en niet is. Fail2ban authenticeert niemand, versleutelt niets en stopt geen enkele vastberaden inlogpoging; het blokkeert enkel herhaalde pogingen vanaf dezelfde bron. Het is een ruisfilter en een rate-limiter, geen slot. De taak van het programma is om te voorkomen dat het constante achtergrondscannen van poort 22 uw CPU, bandbreedte en logruimte verspilt, en om aanvallers die vanaf één adres tegelijk moeten werken te vertragen.

Wat Fail2ban niet vervangt

Fail2ban is de derde verdedigingslinie, niet de eerste. Als uw server nog steeds SSH-wachtwoorden accepteert, kan een botnet dat verspreid is over duizenden adressen blijven gokken, omdat elk adres onder uw ban-drempel blijft en deze nooit overschrijdt. De werkelijke verdediging hiertegen is authenticatie uitsluitend via sleutels, waardoor het raden van wachtwoorden onmogelijk wordt, ongeacht het aantal pogingen. Fail2ban bovenop authenticatie via sleutels doet twee nuttige dingen: het verwijdert de ruis van brute-force-aanvallen uit uw logs en het verwijdert scanners vroegtijdig zodat ze stoppen met het bestoken van de poort. Beschouw het als gelaagde verdediging. Het bevindt zich achter sleutelauthenticatie en achter een firewall, nooit ervoor.

Vereisten en de realiteit van Ubuntu 24.04

U heeft een VPS nodig met Ubuntu 24.04, root- of sudo-toegang, en een werkende SSH-verbinding, bij voorkeur via authenticatie met sleutels. Fail2ban is zuinig: het verbruikt slechts enkele tientallen megabytes aan RAM en vereist geen aanpassing van limieten.

Nu het onderdeel waar veel oudere handleidingen de fout in gaan. Jarenlang was het standaardadvies: "installeer Fail2ban en voeg backend = systemd toe, omdat Ubuntu is gestopt met het schrijven naar /var/log/auth.log." Dat advies beschrijft een reële verandering; moderne server- en cloud-images worden geleverd zonder rsyslog, waardoor SSH alleen logt naar de systemd journal en dat tekstbestand niet meer bestaat. Op Ubuntu 24.04 houdt het Fail2ban-pakket hier echter al rekening mee. Het pakket plaatst /etc/fail2ban/jail.d/defaults-debian.conf, en dat bestand — niet de standaardinstellingen van de ontwikkelaar — is wat uw server daadwerkelijk uitvoert:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Lees dit zorgvuldig, want het beantwoordt twee vragen voordat u wijzigingen aanbrengt. backend = systemd betekent dat de SSH-jail de journal leest, waardoor het ontbreken van auth.log niet uitmaakt. banaction = nftables betekent dat bans worden afgedwongen via nftables, de firewall die Ubuntu 24.04 daadwerkelijk gebruikt in plaats van het verouderde iptables. En [sshd] enabled = true betekent dat de jail vanaf de eerste opstart actief is. De conclusie: een standaard apt install fail2ban op Ubuntu 24.04 blokkeert SSH brute-force aanvallen direct na installatie. Het meeste werk bestaat uit het bevestigen hiervan, het afstellen van het beleid en het waarborgen dat u uzelf niet buitensluit.

De oude auth.log-valkuil is nog steeds relevant in drie situaties, en het is nuttig deze te herkennen: u heeft Fail2ban geïnstalleerd met pip in plaats van apt, waardoor defaults-debian.conf ontbreekt; u bevindt zich in een container zonder privileges die geen systemd journal kan lezen; of u heeft een oude handleiding gevolgd en backend = auto in uw eigen jail.local geplakt, waardoor de werkende standaardinstelling wordt overschreven. De sectie over foutmodi laat precies zien hoe elk van deze situaties eruitziet.

Stap 1: Installeren en bevestigen dat het al blokkeert

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 levert Fail2ban 1.0.2 en het pakket installeert python3-systemd als een harde afhankelijkheid, waardoor de journal-backend over alles beschikt wat nodig is. De service schakelt zichzelf in en start automatisch:

sudo systemctl status fail2ban

U wilt active (running). Bekijk vervolgens de jail die zijn werk al doet:

sudo fail2ban-client status sshd

Op een publieke VPS die al enkele minuten bereikbaar is, ziet u vaak al mislukte pogingen en geblokkeerde adressen; het internet scant continu poort 22. Dat is het bewijs dat de standaardconfiguratie werkt. Vanaf hier verfijnt u de configuratie in plaats van deze vanaf nul op te bouwen.

Stap 2: Bewerk jail.local, nooit jail.conf

Fail2ban bewaart de standaardinstellingen in /etc/fail2ban/jail.conf. Bewerk dit bestand niet. Elke apt upgrade van het pakket kan dit bestand overschrijven, waardoor uw wijzigingen zonder waarschuwing verloren gaan. Fail2ban leest bestanden in een vaste volgorde: eerst jail.conf, daarna alles in jail.d/, en tot slot jail.local, waarbij de laatste waarde de voorgaande overschrijft. Het bestand .local is voor uw eigen configuratie en wordt door pakket-upgrades nooit aangepast. Dezelfde regel geldt voor filters, waarbij een *.local-bestand de meegeleverde filter.d/*.conf overrulet.

U schrijft daarom een klein jail.local-bestand dat alleen de instellingen overschrijft die u wilt wijzigen, terwijl u zowel jail.conf als de meegeleverde jail.d/defaults-debian.conf ongewijzigd laat als referentie.

Stap 3: Schrijf /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Plaats de volgende inhoud in het bestand en wijzig het adres op de regel ignoreip naar uw eigen publieke IP-adres:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Elke regel heeft een specifieke functie:

• bantime, findtime en maxretry bepalen het beleid. De standaardinstelling bantime is slechts tien minuten; een uur is een redelijker minimum. Vijf mislukte pogingen vanaf één adres binnen tien minuten leiden tot een blokkade. Echte gebruikers typen een wachtwoord wel eens één of twee keer verkeerd; vijf fouten in tien minuten wijzen op een script.
• ignoreip is uw veiligheidsmaatregel. Vul hier het publieke adres in vanwaar u verbinding maakt, zodat Fail2ban u nooit buitensluit van uw eigen server. Een thuisverbinding met een wisselend IP-adres is een reden om de voorkeur te geven aan de VPN-methode aan het einde van deze handleiding, niet om deze regel over te slaan.
• bantime.increment = true zorgt ervoor dat elke herhaalde blokkade langer duurt dan de vorige: één uur, dan twee, dan vier, tot aan bantime.maxtime. Adressen die blijven terugkeren, worden steeds langer buitengesloten.

Zoek het adres dat u wilt whitelisten op vanaf de machine vanwaar u SSH-verbinding maakt, niet vanaf de server zelf:

curl -s ifconfig.me

U kunt hier een jail.local genereren die is afgestemd op uw poorten en ban-beleid, en deze vervolgens in het bestand plakken:

Stap 4: Herstarten en verifiëren of het journal wordt gelezen

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

De -t voert eerst een configuratietest uit, waardoor een typefout in jail.local hier direct tot een foutmelding leidt in plaats van dat de service stilletjes uitvalt. Een gezonde status van de jail ziet er als volgt uit:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Het getal dat aantoont dat Fail2ban daadwerkelijk uw inlogpogingen leest, is Total failed. Als dit getal hoger is dan nul, of oploopt wanneer u bewust een inlogpoging vanaf een andere machine laat mislukken, dan wordt het journal gelezen en bent u klaar. Als het getal op 0 blijft staan, ongeacht hoe vaak u faalt, en u zeker weet dat u niet test vanaf het adres in ignoreip, ga dan naar de onderstaande storingsmodi.

Merk op dat de regel Journal matches nog steeds sshd.service vermeldt. Op Ubuntu heet de SSH-unit in werkelijkheid ssh.service, maar het meegeleverde filter matcht ook op _COMM=sshd, en OpenSSH op 24.04 logt zijn fouten vanuit een proces genaamd sshd, waardoor de match werkt. Dat detail is alleen van belang als u een nieuwere versie van OpenSSH gebruikt (9.8 of later, waarbij de worker per verbinding sshd-session heet); de storingsmodi behandelen dat scenario.

Stap 5: Een ban observeren of handmatig forceren om te testen

Echte bans verschijnen binnen enkele minuten vanzelf op elke publieke VPS. Gebruik tail op het logbestand om een ban te observeren:

sudo tail -f /var/log/fail2ban.log

Een ban ziet er als volgt uit:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Om de werking van het systeem volledig te verifiëren zonder te wachten, kunt u handmatig een documentatieadres bannen. Ban nooit uw eigen adres:

sudo fail2ban-client set sshd banip 10.0.0.66

Dit geeft 1 weer en het adres verschijnt onder Banned IP list in fail2ban-client status sshd. Bevestig nu dat de blokkade daadwerkelijk in de firewall aanwezig is. Op Ubuntu 24.04 is dit nftables, niet iptables:

sudo nft list table inet f2b-table

U ziet een set genaamd addr-set-sshd die 10.0.0.66 bevat, en een chain f2b-chain die elk bronadres in die set verwerpt. Als fail2ban-client aangeeft dat een adres geband is, maar er verschijnt niets in nft list, dan komt uw ban-actie niet overeen met uw firewallconfiguratie. Raadpleeg de opmerking over nftables/iptables in de sectie over foutmodi.

Stap 6: Uzelf deblokkeren en herstellen na buitensluiting

Als u per ongeluk een adres heeft verbannen dat u niet had moeten blokkeren, bijvoorbeeld uw eigen adres, verwijder dit dan als volgt:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Dit geeft 1 terug bij succes. Om elke ban in elke jail te wissen:

sudo fail2ban-client unban --all

Vertrouw er niet op dat een reeds geopende SSH-sessie u redt: de nftables-ban weigert elk pakket van het verbannen adres naar poort 22, inclusief bestaande verbindingen. Een actieve sessie bevriest dus op het moment dat de ban wordt geactiveerd. Als u uzelf verbant en geen ignoreip-regel heeft, bent u buitengesloten totdat de ban verloopt. Herstel de toegang via de webconsole van uw provider (VNC of serieel), aangezien deze niet via SSH verloopt. Wacht daarna tot bantime is verstreken of voer daar het unban-commando uit.

Stap 7: Bans persistent maken en escaleren

Fail2ban houdt actieve bans bij in een kleine SQLite-database op /var/lib/fail2ban/fail2ban.sqlite3, zodat deze een herstart van de service of het systeem overleven; u raakt ze dus niet kwijt. De bantime.increment-regels die u al heeft toegevoegd, zorgen ervoor dat recidivisten met een steeds langere ban worden geconfronteerd, waarbij de duur oploopt van ongeveer één uur tot één week.

Voor een systeembreed "three strikes"-beleid bovenop deze configuratie, levert Fail2ban een recidive-jail mee die zijn eigen /var/log/fail2ban.log in de gaten houdt en langdurige bans uitdeelt aan elk adres dat herhaaldelijk is verbannen in alle jails. Omdat uw [DEFAULT] nu de systemd-backend gebruikt, moet u deze jail koppelen aan het logbestand dat het is ontworpen om te lezen:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto met de expliciete logpath zorgt ervoor dat recidive het platte fail2ban.log-bestand blijft lezen. Dit is de locatie waar de Ban-regels die het telt daadwerkelijk verschijnen; de systemd-standaard die u globaal heeft ingesteld, zou de jail naar de journal verwijzen, waar deze regels niet voorkomen.

Stap 8: Combineer dit met SSH via uitsluitend sleutels, en bij voorkeur een VPN

Fail2ban bewijst zijn waarde pas echt in combinatie met authenticatie via sleutels. Stel in een drop-in bestand onder /etc/ssh/sshd_config.d/, bijvoorbeeld /etc/ssh/sshd_config.d/00-hardening.conf, het volgende in:

PasswordAuthentication no
KbdInteractiveAuthentication no

Voer daarna sudo systemctl restart ssh uit. Wanneer wachtwoorden zijn uitgeschakeld, kan brute force onmogelijk slagen; Fail2ban dient dan om log-ruis te verminderen en scanners vroegtijdig te weren. Nog sterker is het om SSH volledig van het openbare internet af te schermen: plaats SSH achter een zelfgehoste WireGuard VPN en blokkeer poort 22 in de firewall zodat deze alleen reageert via de tunnel. Niemand kan een poort brute-forcen die onbereikbaar is, waardoor Fail2ban fungeert als vangnet in plaats van als eerste verdedigingslinie.

Fail2ban is niet alleen bedoeld voor SSH. Elke service die mislukte aanmeldingen logt, kan worden voorzien van een jail, zoals een mailserver, een nginx-site of een zelfgehoste Vaultwarden wachtwoordmanager waarvan u de web-login liever niet blootstelt aan credential stuffing. Zodra een webapplicatie zich achter een nginx-site met een Let's Encrypt certificaat bevindt, kunt u een Fail2ban-filter op het bijbehorende access log richten, op dezelfde manier als de SSH-jail naar de journal verwijst.

Foutmodi, met de exacte meldingen die u zult zien

"Have not found any log file for sshd jail", en Fail2ban start niet. Dit is het oude auth.log-probleem. Op Ubuntu 24.04 komt dit alleen voor als de standaardinstellingen van het pakket zijn overschreven, bij een pip-installatie zonder defaults-debian.conf, in een container zonder journal, of door een verdwaalde backend = auto die u in jail.local heeft geplakt. Bij een file-backend zonder /var/log/auth.log kan de sshd-jail het logbestand niet vinden en breekt de gehele daemon af. fail2ban.log toont:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Omdat deze fout fataal is, start de service niet en rapporteert fail2ban-client status vervolgens het daaruit voortvloeiende symptoom:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Die "socket path"-regel betekent niet dat Fail2ban defect is; het betekent dat het nooit is gestart omdat één jail zijn logbestand niet kon vinden. Het instellen van backend = systemd in [DEFAULT], wat het Ubuntu-pakket al voor u doet, verhelpt beide meldingen tegelijk.

Jail is actief maar Total failed loopt niet op. De daemon draait en de journal wordt gelezen, maar echte mislukte inlogpogingen stapelen zich op in journalctl -u ssh terwijl de teller op 0 blijft staan. Sluit eerst het voor de hand liggende uit: u test vanaf een adres dat in ignoreip staat, waardoor uw eigen fouten volgens ontwerp zijn vrijgesteld. Als dat het niet is, gebruikt u een OpenSSH-build waarbij de per-verbinding worker sshd-session is (9.8 en later), waarvan de journal _COMM de waarde sshd-session heeft, niet sshd, waardoor de standaard match deze mist. Verbreed de match in het [sshd]-blok:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Herstart, forceer een mislukte inlog vanaf een adres dat niet in ignoreip staat, en bevestig dat Total failed eindelijk oploopt.

U heeft uzelf verbannen: Connection refused. U bent uw eigen adres vergeten op te nemen in ignoreip, heeft een paar keer foutief ingelogd, en nu:

ssh: connect to host 10.0.0.10 port 22: Connection refused

De weigering, in plaats van een stille time-out, is het standaard reject-oordeel van de nftables-actie die zijn werk doet op uw verbinding. Herstel dit zoals beschreven in Stap 6: hef de ban op vanuit een sessie op een ander, niet-verbannen adres, of via de console van de provider; een sessie die al openstond vanaf het verbannen adres bevriest namelijk ook. Voeg daarna uw adres toe aan ignoreip zodat dit niet opnieuw kan gebeuren.

Fail2ban zegt dat een adres verbannen is, maar het kan nog steeds verbinding maken. De teller in status sshd loopt op, maar het adres bereikt nog steeds poort 22. Dit is een mismatch tussen de ban-actie en de firewall. Op Ubuntu 24.04 betekent dit bijna altijd dat u de werkende banaction = nftables heeft overschreven met banaction = iptables-multiport uit een verouderde handleiding, op een systeem zonder iptables-laag. fail2ban.log toont:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Verwijder die overschrijving en gebruik de standaard nftables-actie, of, als u de firewall volledig via ufw beheert en wilt dat bans daar zichtbaar zijn, stel dan banaction = ufw in [DEFAULT] in. Herstart en bevestig dat de regel verschijnt met sudo nft list ruleset | grep f2b.

Fail2ban start niet na het bewerken van jail.local. Een typefout, een verdwaalde koptekst of een onjuiste tijdswaarde zorgt ervoor dat de service niet wil opstarten. Vraag Fail2ban om de configuratie te controleren voordat deze wordt uitgevoerd:

sudo fail2ban-client -t

Dit geeft het bestand en de jail met het probleem aan, bijvoorbeeld Errors in jail 'sshd'. Skipping..., zodat u de bron kunt herstellen in plaats van te gissen.

FAQ

Ban de standaardinstallatie van Fail2ban op Ubuntu 24.04 daadwerkelijk SSH-aanvallen?

Ja. Het pakket levert /etc/fail2ban/jail.d/defaults-debian.conf, waarmee de sshd jail wordt ingeschakeld, backend = systemd wordt ingesteld zodat het de systemd-journal leest in plaats van het ontbrekende /var/log/auth.log, en banaction = nftables wordt geconfigureerd zodat bans via de echte firewall van Ubuntu worden afgedwongen. Een standaard apt install fail2ban beschermt SSH vanaf de eerste opstart. Bevestig dit met sudo fail2ban-client status sshd en controleer of de waarde van Total failed niet nul is.

Waarom bant Fail2ban niets op mijn server?

Sluit de drie meest voorkomende oorzaken in volgorde uit. Mogelijk test u vanaf een adres in ignoreip, dat standaard is vrijgesteld. Mogelijk hebt u de werkende standaardinstellingen overschreven door backend = auto uit een verouderde handleiding in jail.local te plakken, wat het lezen van de journal op een image zonder auth.log verstoort. Of u bevindt zich in een container waar helemaal geen systemd-journal beschikbaar is. Controleer Total failed in fail2ban-client status sshd: als deze waarde nooit oploopt terwijl journalctl -u ssh echte mislukte inlogpogingen toont, leest de jail de verkeerde bron.

Hoe hef ik een ban op mijn eigen IP-adres op?

Voer sudo fail2ban-client set sshd unbanip YOUR.IP.HERE uit, wat 1 retourneert bij succes, of gebruik sudo fail2ban-client unban --all om alle bans te verwijderen. Als u bent buitengesloten van SSH, gebruik dan de web- of VNC-console van uw provider om hetzelfde commando uit te voeren; de ban weigert elk pakket van uw adres naar poort 22, waardoor zelfs een reeds geopende sessie stopt met werken. Voeg daarna uw adres toe aan ignoreip zodat dit niet opnieuw gebeurt.

Wat is het verschil tussen jail.conf en jail.local?

jail.conf bevat de standaardinstellingen van Fail2ban en wordt bij elke pakket-upgrade overschreven, waardoor wijzigingen daar uiteindelijk verloren gaan. Het Debian/Ubuntu-pakket past zijn eigen instellingen toe via jail.d/defaults-debian.conf. Uw wijzigingen horen thuis in jail.local, dat als laatste wordt gelezen, voorrang krijgt op beide andere bestanden en nooit wordt aangeraakt door upgrades. Laat jail.conf staan als alleen-lezen referentie.

Vervangt Fail2ban SSH-authenticatie op basis van sleutels?

Nee. Fail2ban beperkt het aantal mislukte pogingen vanaf één adres; het doet niets tegen een trage, gedistribueerde aanval waarbij elk adres onder de drempelwaarde blijft. Authenticatie uitsluitend via sleutels (PasswordAuthentication no) maakt het raden van wachtwoorden direct onmogelijk, waarna Fail2ban de logbestanden opschoont en scanners vroegtijdig verwijdert. Gebruik beide, en houd SSH bij voorkeur volledig afgeschermd van het publieke internet.