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 geldt alleen voor bepaalde images. Een standaard Ubuntu 24.04 server- of cloud-image installeert nog steeds rsyslog, waarvan de standaardregels auth,authpriv.* naar /var/log/auth.log schrijven. Op de meeste VPS-omgevingen komen SSH-fouten dus zowel in dat bestand als in de systemd journal terecht. Minimale images (de Ubuntu 24.04 minimal cloud image wordt geleverd zonder rsyslog) en de meeste containers loggen SSH alleen naar de journal, waardoor het tekstbestand daar inderdaad ontbreekt. Hoe dan ook, op Ubuntu 24.04 houdt het Fail2ban-pakket hier 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 ergens aan begint. backend = systemd betekent dat de SSH-jail de journal uitleest, dus het maakt niet uit of uw image wel of niet naar auth.log schrijft. 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 ervoor zorgen dat u uzelf niet buitensluit.

De oude auth.log-valkuil is nog steeds relevant in drie situaties, en het is nuttig om deze te herkennen: u heeft Fail2ban geïnstalleerd met pip in plaats van apt, waardoor defaults-debian.conf ontbreekt; u bevindt zich in een unprivileged container zonder systemd journal om uit te lezen; of u heeft een oude handleiding gevolgd en backend = auto in uw eigen jail.local geplakt, waardoor de werkende standaardinstelling wordt overschreven. De eerste en derde situatie verbreken SSH-blocking alleen op een image zonder rsyslog, zoals een minimale image, omdat waar rsyslog draait, de file-backend /var/log/auth.log vindt en correct functioneert. 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. Een pakketupdate kan het bestand overschrijven, zoals de koptekst van het bestand zelf waarschuwt, waardoor uw wijzigingen verloren gaan. Fail2ban leest bestanden in een vaste volgorde: eerst jail.conf, daarna jail.d/*.conf in alfabetische volgorde, vervolgens jail.local, daarna jail.d/*.local in alfabetische volgorde, waarbij de laatste waarde telt. Daarom overschrijft jail.local de meegeleverde defaults-debian.conf, maar elk *.local-bestand dat u in jail.d/ plaatst, wordt daarna gelezen en overschrijft deze op zijn beurt; bewaar uw aanpassingen op één plek zodat u weet welke waarde actief is. Het .local-bestand is van u en pakketupdates wijzigen dit nooit. Dezelfde regel geldt voor filters, waarbij een *.local-bestand het meegeleverde filter.d/*.conf overschrijft.

U schrijft dus een klein jail.local-bestand dat alleen de instellingen overschrijft die u wilt wijzigen, en u laat zowel jail.conf als de meegeleverde jail.d/defaults-debian.conf ongewijzigd 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 een 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:   203.0.113.66

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

Merk op dat de regel Journal matches nog steeds verwijst naar sshd.service. Op Ubuntu is 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 per-verbinding worker sshd-session is); de storingsmodi behandelen dat scenario.

Stap 5: Een ban in real-time observeren of handmatig afdwingen

Op een publieke VPS verschijnen bans vanzelf binnen enkele minuten. 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 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Om de werking van het systeem volledig te verifiëren zonder te wachten, kunt u handmatig een ban opleggen aan een documentatie-adres; gebruik hiervoor nooit uw eigen IP-adres. 203.0.113.66 bevindt zich in TEST-NET-3, een blok dat is gereserveerd voor documentatie. Dit adres kan dus geen echte host of een privaat adres binnen het netwerk van uw provider zijn:

sudo fail2ban-client set sshd banip 203.0.113.66

Het commando geeft 1 weer en het adres verschijnt onder Banned IP list in fail2ban-client status sshd. Controleer nu of de blokkade daadwerkelijk in de firewall aanwezig is. Op Ubuntu 24.04 wordt hiervoor nftables gebruikt, niet iptables:

sudo nft list table inet f2b-table

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

Stap 6: Uzelf deblokkeren en herstellen bij buitensluiting

Als u een adres heeft geblokkeerd dat u niet had moeten blokkeren, zoals uw eigen adres, verwijder de blokkering dan als volgt:

sudo fail2ban-client set sshd unbanip 203.0.113.66

Dit geeft 1 terug bij succes. Om alle blokkeringen voor elke jail te wissen:

sudo fail2ban-client unban --all

Vertrouw er niet op dat een reeds geopende SSH-sessie u redt: de nftables-blokkering weigert elk pakket van het geblokkeerde adres naar poort 22, inclusief bestaande verbindingen. Een actieve sessie bevriest dus op het moment dat de blokkering wordt toegepast. Als u uzelf blokkeert en geen ignoreip-toegang heeft, bent u buitengesloten totdat de blokkering verloopt. Herstel de toegang via de webconsole van uw provider (VNC of serieel), aangezien deze niet via SSH verloopt, en wacht tot bantime is verstreken of voer daar het deblokkeringscommando 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 treedt dit alleen op wanneer /var/log/auth.log niet bestaat (een image zonder rsyslog, zoals een minimale image of een container) en de journal niet wordt gelezen: een pip-installatie zonder defaults-debian.conf, een container zonder journal, of een verdwaalde backend = auto die u in jail.local heeft geplakt. Bij een file-backend zonder /var/log/auth.log kan de sshd-jail zijn logbestand niet vinden en wordt de gehele daemon afgebroken. 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 downstream-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 sshd-session is, en 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 inlogpoging 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 foutieve inlogpogingen getest, 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-vonnis 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 oudere 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 override en laat de meegeleverde nftables-actie staan, 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 starten. Vraag Fail2ban om de configuratie te controleren voordat deze wordt uitgevoerd:

sudo fail2ban-client -t

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

FAQ

Ban de standaard Fail2ban-installatie op Ubuntu 24.04 daadwerkelijk SSH-aanvallen?

Ja. Het pakket levert /etc/fail2ban/jail.d/defaults-debian.conf mee, wat de sshd jail inschakelt, backend = systemd instelt zodat het de systemd journal leest ongeacht of uw image /var/log/auth.log schrijft, en banaction = nftables instelt zodat bans worden afgedwongen via de echte firewall van Ubuntu. Een standaard apt install fail2ban beschermt SSH vanaf de eerste boot. Bevestig dit met sudo fail2ban-client status sshd en zoek naar een Total failed die niet nul is.

Waarom bant Fail2ban niets op mijn server?

Sluit de drie veelvoorkomende oorzaken in volgorde uit. Mogelijk test u vanaf een adres in ignoreip, dat opzettelijk door het ontwerp is vrijgesteld. Mogelijk heeft u de werkende standaardinstelling overschreven door backend = auto in jail.local te plakken vanuit een oude handleiding, wat SSH-banning op een image zonder rsyslog (en dus zonder auth.log) onklaar maakt. Of u bevindt zich in een container zonder systemd journal om uit te lezen. Controleer Total failed in fail2ban-client status sshd: als deze waarde nooit oploopt terwijl journalctl -u ssh echte mislukte pogingen toont, leest de jail op de verkeerde locatie.

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

Voer sudo fail2ban-client set sshd unbanip YOUR.IP.HERE uit, wat bij succes 1 retourneert, of sudo fail2ban-client unban --all om elke ban te wissen. 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 kan gebeuren.

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

jail.conf bevat de upstream-standaardinstellingen van Fail2ban en kan worden vervangen door een pakketupgrade, waardoor elke wijziging daar risico loopt. Het Debian/Ubuntu-pakket legt zijn eigen instellingen eroverheen via jail.d/defaults-debian.conf. Uw wijzigingen horen thuis in jail.local, dat na beide wordt gelezen en voorrang krijgt, en dat nooit door upgrades wordt aangeraakt. Alleen een *.local-bestand in jail.d/ wordt nog later gelezen, dus laat daar geen ongebruikte bestanden achter. Laat jail.conf als alleen-lezen referentie staan.

Vervangt Fail2ban SSH-authenticatie op basis van sleutels?

Nee. Fail2ban beperkt de snelheid van herhaalde mislukte pogingen vanaf één adres; het doet niets tegen een trage, gedistribueerde gokpoging waarbij elk adres onder de drempelwaarde blijft. Authenticatie uitsluitend via sleutels (PasswordAuthentication no) maakt het raden van wachtwoorden direct onmogelijk, en Fail2ban vermindert vervolgens de ruis in de logs en verwijdert scanners in een vroeg stadium. Gebruik beide, en houd SSH idealiter volledig buiten het publieke internet.