Fail2ban installeren op Ubuntu 24.04

Wat Fail2ban precies doet

Fail2ban is een daemon die logbestanden leest. Het controleert uw SSH-authenticatieberichten. Wanneer een adres binnen een korte periode meerdere mislukte pogingen doet, voert het een firewall-commando uit. Dit commando blokkeert het betreffende adres voor een bepaalde tijd. Dit is de kern van de werking. Het vereist ongeveer dertig regels configuratie in één bestand. Op Ubuntu 24.04 is de installatie een enkele apt commando, waardoor u al beschermd bent voordat u instellingen aanpast.

Wees duidelijk over wat het wel en niet doet. Fail2ban voert geen authenticatie uit en versleutelt niets. Het stopt geen enkele doelgerichte inlogpoging, alleen herhaalde pogingen vanaf dezelfde bron. Het is een ruisfilter en een rate limiter, geen slot. De taak is om te voorkomen dat constante scans op port 22 uw CPU, bandbreedte en logruimte verspillen. Daarnaast vertraagt het aanvallers die slechts één adres tegelijk kunnen gebruiken.

Wat Fail2ban niet vervangt

Fail2ban is de derde laag, niet de eerste. Als uw server nog steeds SSH-wachtwoorden accepteert, kan een botnet verspreid over duizenden adressen blijven gokken. Dit gebeurt omdat elk adres onder uw ban-drempel blijft en deze nooit overschrijdt. De echte verdediging hiertegen is authenticatie via alleen keys. Hiermee is het gokken van wachtwoorden onmogelijk, ongeacht het aantal pogingen. Fail2ban bovenop key-only authenticatie biedt twee voordelen: het verwijdert brute-force ruis uit uw logs en het verwijdert scanners vroegtijdig zodat zij de port niet blijven bestoken. Beschouw dit als defence in depth. Het bevindt zich achter de key-authenticatie en achter een firewall, nooit ervoor.

Vereisten en de realiteit van Ubuntu 24.04

U heeft een VPS nodig met Ubuntu 24.04 met root- of sudo-rechten, en een werkende SSH-verbinding — bij voorkeur via sleutelauthenticatie. Fail2ban is zuinig: het verbruikt slechts enkele tientallen megabytes aan RAM en vereist geen handmatige limietinstellingen.

Hier volgt het onderdeel waar oudere handleidingen de fout in gaan. Jarenlang was het standaardadvies: "installeer Fail2ban en voeg backend = systemd toe, omdat Ubuntu is gestopt met het schrijven van /var/log/auth.log." Dit advies beschrijft een werkelijke verandering — moderne server- en cloud-images worden geleverd zonder rsyslog, waardoor SSH-logs alleen naar de systemd journal gaan en het tekstbestand niet meer bestaat — maar in Ubuntu 24.04 houdt het Fail2ban-pakket hier al rekening mee. Het pakket levert /etc/fail2ban/jail.d/defaults-debian.conf, en dat bestand bepaalt wat uw server daadwerkelijk uitvoert, niet de standaardinstellingen van de upstream-bron.

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

[sshd]
enabled = true

Lees dit zorgvuldig, omdat het twee vragen beantwoordt voordat u actie onderneemt. backend = systemd betekent dat de SSH jail de journal uitleest, dus het ontbreken van auth.log is niet relevant. banaction = nftables betekent dat bans worden afgedwongen via nftables, de firewall die Ubuntu 24.04 daadwerkelijk gebruikt in plaats van de verouderde iptables. En [sshd] enabled = true betekent dat de jail actief is vanaf de eerste boot. De conclusie: een standaard apt install fail2ban op Ubuntu 24.04 blokkeert SSH brute-force direct uit de doos. Het grootste deel van uw werk bestaat uit het bevestigen hiervan, het aanpassen van de regels en het waarborgen dat u uzelf niet buitengesloten.

De oude auth.log-valkuil is nog steeds relevant in drie situaties. Het is belangrijk 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 geplakt in uw eigen jail.local, waardoor de werkende standaardinstelling wordt overschreven. De sectie over foutmodi laat precies zien hoe elk scenario eruitziet.

Stap 1: Installeren en controleren of het blokkeren al actief is

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 bevat Fail2ban 1.0.2. Het pakket installeert python3-systemd als harde afhankelijkheid, waardoor de journal backend over alle benodigde componenten beschikt. De service wordt automatisch ingeschakeld en gestart:

sudo systemctl status fail2ban

U wilt active (running). Controleer vervolgens de jail die momenteel actief is:

sudo fail2ban-client status sshd

Op een publieke VPS die slechts enkele minuten bereikbaar is, ziet u vaak al mislukte pogingen en geblokkeerde adressen. Het internet scant continu poort 22. Dit bewijst dat de standaardconfiguratie werkt. U gaat de configuratie vanaf hier verfijnen, in plaats van deze vanaf nul op te bouwen.

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

Fail2ban bewaart de standaardinstellingen in /etc/fail2ban/jail.conf. Bewerk dit bestand niet. Elke apt upgrade van het pakket kan dit bestand vervangen, waardoor uw wijzigingen zonder waarschuwing verloren gaan. Fail2ban leest bestanden in een vaste volgorde — eerst jail.conf, daarna alles in jail.d/, en vervolgens jail.local — waarbij de laatste waarde wordt toegepast. Het .local bestand is van u en pakketupdates wijzigen dit nooit. Dezelfde regel geldt voor filters, waarbij een *.local bestand de meegeleverde filter.d/*.conf overschrijft.

Schrijf daarom een kleine jail.local die alleen de instellingen overschrijft die relevant zijn. Laat zowel jail.conf als het meegeleverde jail.d/defaults-debian.conf bestand ongewijzigd als referentie.

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

sudo nano /etc/fail2ban/jail.local

Voeg dit toe en pas het adres op de ignoreip regel aan naar uw eigen publieke IP:

[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, maxretry bepalen de beleidsregels. De standaardinstelling bantime is slechts tien minuten; een uur is een veiligere ondergrens. Vijf mislukte pogingen vanaf één adres binnen tien minuten leidt tot een ban. Echte gebruikers maken een of twee keer een typefout; vijf mislukte pogingen binnen tien minuten wijst op een script.
• ignoreip dient als veiligheidsmaatregel. Voer hier het publieke adres in waarmee u verbinding maakt, zodat Fail2ban u nooit de toegang tot uw eigen server ontzegt. Een thuisaansluiting met een wisselend IP-adres is een reden om de VPN-methode aan het einde te gebruiken, maar dit is geen reden om deze regel over te slaan.
• bantime.increment = true zorgt ervoor dat elke opeenvolgende ban langer duurt dan de vorige — eerst een uur, dan twee, dan vier — tot maximaal bantime.maxtime. Adressen die herhaaldelijk proberen in te loggen, worden progressief langer uitgesloten.

Zoek het adres dat u wilt whitelisten vanaf de machine waarmee u SSH gebruikt, niet vanaf de server:

curl -s ifconfig.me

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

Stap 4: Herstarten en controleren of de journal wordt uitgelezen

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

De -t voert eerst een configuratietest uit. Een typefout in jail.local zorgt hier voor een duidelijke foutmelding in plaats van een defecte service. Een correcte jail-status 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 bevestigt dat Fail2ban de logins daadwerkelijk leest, is Total failed. Als dit getal hoger is dan nul, of stijgt wanneer u bewust een login laat mislukken vanaf een ander apparaat, dan wordt de journal uitgelezen en is de configuratie voltooid. Als het getal op 0 blijft staan, ongeacht hoe vaak u een login laat mislukken — en u bent zeker dat u niet test vanaf het adres in ignoreip — ga dan naar de foutmodi hieronder.

Let op dat de Journal matches-regel nog steeds sshd.service vermeldt. Op Ubuntu is de SSH-unit eigenlijk ssh.service, maar de meegeleverde filter matcht ook op _COMM=sshd. OpenSSH op 24.04 logt fouten via een proces genaamd sshd, waardoor de match werkt. Dit detail is alleen relevant bij een nieuwere OpenSSH (9.8 of later, waarbij de per-connection worker sshd-session is); de foutmodi dekken dit scenario af.

Stap 5: Bekijk een echte ban of dwing een test-ban af

Echte bans verschijnen binnen enkele minuten op elke publieke VPS. Gebruik tail om het logbestand te volgen:

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 het proces direct te testen zonder te wachten, kunt u handmatig een documentatie-adres bannen — gebruik nooit uw eigen adres:

sudo fail2ban-client set sshd banip 10.0.0.66

Het systeem print 1 en het adres verschijnt onder Banned IP list in fail2ban-client status sshd. Controleer nu of de blokkade daadwerkelijk in de firewall staat. Op Ubuntu 24.04 is dit nftables, niet iptables:

sudo nft list table inet f2b-table

U ziet een set genaamd addr-set-sshd met 10.0.0.66, en een chain f2b-chain die elk bronadres in die set weigert. Als fail2ban-client aangeeft dat een adres geband is, maar er verschijnt niets in nft list, dan komt de ban-actie niet overeen met uw firewall — raadpleeg de nftables/iptables-notitie bij de foutmodi.

Stap 6: Blokkeren opheffen en herstellen bij een lockout

Als u een adres onterecht heeft geblokkeerd — bijvoorbeeld uw eigen adres — verwijder dit dan:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Bij succes wordt 1 geretourneerd. Om alle blokkades in alle jails te verwijderen:

sudo fail2ban-client unban --all

Vertrouw niet op een reeds actieve SSH-sessie om u te redden: de nftables-blokkade weigert elk pakket van het geblokkeerde adres naar poort 22 — inclusief bestaande verbindingen. Een actieve sessie bevriest direct zodra de blokkade wordt toegepast. Als u uzelf blokkeert en er is geen ignoreip-vermelding, bent u uitgesloten totdat de blokkade verloopt. Herstel dit via de webconsole van uw provider (VNC of serial); deze werkt niet via SSH. Wacht de bantime af of voer het unban-commando daar uit.

Stap 7: Bans persistent maken en escaleren

Fail2ban slaat actieve bans op in een kleine SQLite-database op /var/lib/fail2ban/fail2ban.sqlite3. Hierdoor blijven bans behouden na een service-restart of een reboot; u verliest deze niet. De bantime.increment regels die u al heeft toegevoegd, zorgen ervoor dat elke herhaalde overtreding leidt tot een langere ban — deze verdubbelt ongeveer elke keer, van één uur naar één week.

Voor een systeembrede "three strikes"-policy biedt Fail2ban een recidive jail aan. Deze jail controleert de eigen /var/log/fail2ban.log en geeft langere bans aan adressen die herhaaldelijk in alle jails zijn geband. Omdat uw [DEFAULT] nu de systemd-backend gebruikt, moet u deze jail koppelen aan het logbestand waarvoor deze is ontworpen:

[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 de gewone fail2ban.log blijft lezen. Dit is de plek waar de Ban regels die worden geteld daadwerkelijk verschijnen. De standaard systemd-instelling die u globaal heeft ingesteld, zou naar de journal verwijzen, waar deze regels niet staan.

Stap 8: Combineer met SSH met alleen sleutels, of nog beter een VPN

Fail2ban is alleen effectief in combinatie met sleutel-authenticatie. Stel dit in in een configuratiebestand onder /etc/ssh/sshd_config.d/ — bijvoorbeeld /etc/ssh/sshd_config.d/00-hardening.conf:

PasswordAuthentication no
KbdInteractiveAuthentication no

Voer daarna sudo systemctl restart ssh uit. Wanneer wachtwoorden zijn uitgeschakeld, kan een brute force-aanval niet slagen. Fail2ban dient dan enkel om logbestanden overzichtelijk te houden en scanners vroegtijdig te blokkeren. Nog veiliger is het om SSH volledig van het publieke internet te halen: plaats SSH achter een zelfgehoste WireGuard VPN en blokkeer poort 22 in de firewall, zodat deze alleen via de tunnel reageert. Een poort die niet bereikbaar is, kan niet worden aangevallen via brute force. Fail2ban fungeert dan als extra beveiliging in plaats van de primaire verdedigingslinie.

Fail2ban is niet alleen voor SSH. Elke dienst die mislukte inlogpogingen logt, kan een jail krijgen — zoals een mailserver, een nginx-site, of een zelfgehoste Vaultwarden wachtwoordbeheerder waarvan u de web-login liever niet openstel voor credential stuffing. Zodra een webapplicatie achter een nginx-site met een Let's Encrypt-certificaat draait, wijst u een Fail2ban-filter naar het access log, op dezelfde wijze als de SSH-jail naar de journal wijst.

Foutmodi, met de exacte strings 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 als een standaardinstelling uit het pakket is overschreven — een pip installatie zonder defaults-debian.conf, een container zonder journal, of een foutieve backend = auto die in jail.local is geplakt. Bij een file backend zonder /var/log/auth.log kan de sshd jail zijn logbestand niet vinden en stopt de gehele daemon. 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 gevolg:

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

De regel "socket path" betekent niet dat Fail2ban defect is — het betekent dat de service 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) lost beide meldingen tegelijkertijd op.

Jail is actief maar Total failed beweegt nooit. De daemon draait en de journal wordt gelezen, maar fouten stapelen zich op in journalctl -u ssh terwijl de teller op 0 blijft staan. Sluit eerst het overduidelijke uit: u test vanaf een adres dat in ignoreip staat, waardoor uw eigen fouten ontzien worden. Als dat niet de oorzaak is, gebruikt u een OpenSSH-versie waarbij de per-connection worker sshd-session is (9.8 en later). De journal _COMM van deze versie is sshd-session in plaats van sshd, waardoor de standaard match deze mist. Breid de match uit in de [sshd] block:

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

Herstart de service, veroorzaak opzettelijk een mislukte login vanaf een adres dat niet in ignoreip staat, en controleer of Total failed uiteindelijk stijgt.

U heeft uzelf verbannen: Connection refused. U heeft uw eigen adres niet opgenomen in ignoreip, enkele foutieve logins getest, en nu:

ssh: connect to host 10.0.0.10 port 22: Connection refused

De weigering is geen stille timeout, maar de standaard reject verdict van de nftables action die zijn werk doet — op u. Los dit op zoals in Stap 6: ontban uzelf via een sessie vanaf een ander, niet-verbannen adres, of via de console van de provider — een sessie die al open staat vanaf het verbannen adres bevriest namelijk ook. Voeg daarna uw adres toe aan ignoreip zodat dit niet opnieuw gebeurt.

Fail2ban zegt dat een adres verbannen is, maar er kan nog steeds verbinding worden gemaakt. De teller in status sshd stijgt, maar het adres bereikt nog steeds poort 22. Dit is een mismatch tussen de ban-action en de firewall. Op Ubuntu 24.04 betekent dit bijna altijd dat u de werkende banaction = nftables heeft overschreven met banaction = iptables-multiport gekopieerd 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 overschrijving en gebruik de standaard nftables action uit het pakket. Als u de firewall volledig via ufw beheert en wilt dat verboden adressen daar verschijnen, stel dan banaction = ufw in in [DEFAULT]. Herstart en controleer of de regel verschijnt met sudo nft list ruleset | grep f2b.

Fail2ban start niet na het bewerken van jail.local. Een typefout — een verkeerde heading of een foutieve tijdwaarde — zorgt ervoor dat de service niet start. Laat Fail2ban de configuratie controleren voordat de service draait:

sudo fail2ban-client -t

De output vermeldt het bestand en de jail met het probleem, bijvoorbeeld Errors in jail 'sshd'. Skipping..., zodat u de bron kunt herstellen in plaats van te gokken.

FAQ

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

Ja. Het pakket bevat /etc/fail2ban/jail.d/defaults-debian.conf. Dit activeert de sshd jail, stelt backend = systemd in zodat de systemd journal wordt gebruikt in plaats van de ontbrekende /var/log/auth.log, en stelt banaction = nftables in zodat blokkades via de Ubuntu firewall worden afgedwongen. Een standaard apt install fail2ban beschermt SSH vanaf de eerste boot. Controleer dit met sudo fail2ban-client status sshd en zoek naar een waarde die groter is dan 0 bij Total failed.

Waarom blokkeert Fail2ban niets op mijn systeem?

Controleer de drie meest voorkomende oorzaken in deze volgorde. U test mogelijk vanaf een adres in ignoreip, wat standaard is uitgesloten. U heeft mogelijk de werkende standaardinstellingen overschreven door backend = auto in jail.local te plakken uit een oude handleiding; dit voorkomt het lezen van de journal op een image zonder auth.log. Of u bevindt zich in een container zonder systemd journal om te lezen. Controleer Total failed in fail2ban-client status sshd: als deze waarde niet stijgt terwijl journalctl -u ssh daadwerkelijke fouten aangeeft, leest de jail de verkeerde locatie.

Hoe blokkeer ik 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 blokkades te verwijderen. Als u bent uitgesloten van SSH, gebruik dan de web- of VNC-console van uw provider om hetzelfde commando uit te voeren. De blokkade weigert elk pakket van uw adres naar poort 22, waardoor zelfs een reeds actieve sessie stopt met werken. Voeg uw adres vervolgens toe aan ignoreip om herhaling te voorkomen.

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

jail.conf bevat de standaardinstellingen van Fail2ban. Deze worden bij elke pakketupdate overschreven, waardoor wijzigingen in dit bestand verloren gaan. Het Debian/Ubuntu-pakket past eigen instellingen toe via jail.d/defaults-debian.conf. Uw wijzigingen horen in jail.local te staan. Dit bestand wordt als laatste gelezen en heeft voorrang op beide andere bestanden. Updates raken dit bestand nooit aan. Gebruik jail.conf enkel als leesbare referentie.

Vervangt Fail2ban de SSH-authenticatie met sleutels?

Nee. Fail2ban beperkt het aantal herhaalde mislukte pogingen vanaf één adres. Het biedt geen bescherming tegen langzame, gedistribueerde aanvallen waarbij elk adres onder de drempelwaarde blijft. Authenticatie met enkel sleutels (PasswordAuthentication no) maakt wachtwoordraden direct onmogelijk. Fail2ban vermindert in dat geval de log-ruis en verwijdert scanners vroegtijdig. Gebruik beide methoden en houd SSH bij voorkeur volledig buiten het publieke internet.