CrowdSec versus Fail2Ban: verschillen in de praktijk

CrowdSec en Fail2Ban op de juiste manier inperken

De juiste keuze hangt niet af van welke tool als moderner wordt beschouwd, maar van de server, de loggegevens en het gewenste handhavingspunt. Voor een enkele SSH-dienst met duidelijke foutmeldingen kan Fail2Ban zeer doeltreffend zijn. CrowdSec wordt interessant wanneer meerdere logbronnen, verschillende beveiligingsniveaus of gedistribueerde systemen gezamenlijk moeten worden geanalyseerd en beveiligd.

Beide oplossingen zijn bedoeld om op logbestanden gebaseerde detectie van aanvallen: Ze lezen beveiligingsgerelateerde gebeurtenissen, zoals mislukte inlogpogingen, wijzen deze aan een patroon toe en kunnen een IP-adres laten blokkeren. Fail2Ban combineert hiervoor filters en acties in ‘jails’. CrowdSec verwerkt de ingelezen gegevens via zijn Security Engine en neemt beslissingen, waarvan de uitvoering wordt overgenomen door een afzonderlijke Remediation Component.

Het komt erop aan wat er daadwerkelijk wordt gelogd. Zonder tijdstempel, bruikbaar bron-IP-adres en de juiste logbron kan geen van de tools een aanval betrouwbaar toewijzen. Een blokkering biedt bovendien alleen bescherming waar deze technisch van kracht is: een lokale firewallregel helpt niet automatisch als het dataverkeer eerst via een externe reverse proxy of load balancer verloopt.

Als Intrusiepreventie Beide tools vormen een aanvulling op een beveiligingsarchitectuur, maar vervangen deze niet. Beveiligingsupdates dichten bekende kwetsbaarheden, sterke en bij voorkeur meerlaagse aanmelding beperkt misbruik van accounts, en restrictieve basisregels voor de firewall beperken het aantal bereikbare diensten. Back-ups beperken de schade na een incident, terwijl continue logboekmonitoring ook problemen aan het licht brengt die geen blokkering activeren.

De praktische vraag luidt dan ook: welke patronen moeten worden herkend, op welk punt moet de reactie plaatsvinden en wie beheert de regels, uitzonderingen en logbestanden? Pas daarna kan een weloverwogen beslissing worden genomen of een overzichtelijke lokale jail-configuratie volstaat, of dat de afzonderlijke componenten van CrowdSec een aantoonbare meerwaarde bieden voor de infrastructuur.

Hoe Fail2Ban ‘jails’ en acties aan elkaar koppelt

Fail2Ban regelt de detectie en reactie in Gevangenissen. Bij SSH leest een jail bijvoorbeeld authenticatieprotocollen of het systeemlogboek. Een filter zoekt daarin naar mislukte inlogpogingen vanaf een bron-IP. Als het toegestane aantal mislukte pogingen binnen het geconfigureerde tijdsbestek wordt overschreden, behandelt Fail2Ban de treffer als een blokkeringsgeval.

De daaropvolgende actie bepaalt de reactie. Vaak vormt deze een aanvulling op een regel in de lokale firewall, maar ook andere geconfigureerde acties zijn mogelijk. Zo is de keten duidelijk te volgen: de logbron levert regels aan, het filter herkent relevante gebeurtenissen, de jail telt ze en de actie voert de beoogde tegenmaatregel uit. Dit vergemakkelijkt het opsporen van fouten, mits het logboekformaat en het filter op elkaar zijn afgestemd.

Een jail gebruikt precies één filter, maar kan meerdere acties uitvoeren. Zo kan hetzelfde vastgestelde SSH-blokkeringsgeval bijvoorbeeld een firewallactie activeren en daarnaast een melding in gang zetten. Meerdere acties maken de reactie flexibeler, maar veranderen niets aan de basis van de detectie: ze zijn allemaal gekoppeld aan hetzelfde filter en de interpretatie daarvan van de logregels.

Zelfgeschreven teksten vereisen bijzondere zorgvuldigheid Regex-filter. De beschikbare filterdocumentatie is uitdrukkelijk bedoeld als ontwikkelingshandleiding voor Fail2Ban 0.9.0.dev en vormt geen bewijs van functionaliteit voor een bepaalde stabiele pakketversie. Uw algemene opmerkingen blijven nuttig voor de ontwikkeling van filters: er moet rekening worden gehouden met variaties in de daadwerkelijke logboekformaten, terwijl patronen niet te ruim mogen zijn. Nieuwe filters moeten daarom eerst worden getest met geanonimiseerde voorbeeldregels, voordat ze blokkades activeren.

Lokale wijzigingen horen in principe thuis in bestanden met de extensie .local, niet in geleverde .conf-bestanden. Zo blijven eigen instellingen voor logpaden, toegestane netwerken of acties bij pakketupdates beter traceerbaar en worden ze niet zomaar overschreven. Voorafgaand aan de uitrol moet bovendien worden gecontroleerd of de gekozen logbron daadwerkelijk bestaat en de verwachte gebeurtenissen bevat.

De weg van CrowdSec: van logboek naar blokkering

CrowdSec maakt een duidelijker onderscheid tussen detectie en handhaving door deze in afzonderlijke componenten onder te brengen. Eerst bepalen acquisitiebronnen welke logbestanden of gebeurtenisstromen worden ingelezen. Parsers normaliseren deze gegevens; vervolgens beoordelen scenario’s patronen en gedrag. Bij een overeenkomend patroon wordt een waarschuwing gegenereerd. De Local API kan op basis van geconfigureerde profielen hieruit een beslissing nemen, bijvoorbeeld een tijdelijke IP-blokkering.

Een kort voorbeeld illustreert het proces: authenticatiefouten van een dienst worden via de acquisitie naar de engine gestuurd. Parsers herkennen velden zoals tijd, dienst en bron-IP; een scenario beoordeelt herhaalde mislukte pogingen. De hieruit gegenereerde waarschuwing wordt doorgegeven aan de Local API, die met een passend profiel een beslissing kan nemen. Pas een aangesloten Saneringscomponent voert dit besluit uit op het beoogde beschermingspunt.

Dit onderdeel wordt traditioneel ook wel ‘bouncer’ genoemd. Afhankelijk van de variant kan het bijvoorbeeld beslissingen afdwingen op een firewall, een reverse proxy of een webserver. De Security Engine detecteert op zichzelf incidenten en beheert via de Local API zowel waarschuwingen als beslissingen, maar blokkeert geen dataverkeer. Zonder een correct gekoppelde Remediation Component blijft een gegenereerde beslissing slechts informatie zonder actieve netwerk- of applicatieblokkering.

In de praktijk maakt deze scheiding het mogelijk om detectie en blokkering over verschillende infrastructuurpunten te verdelen. Het vergroot echter de omvang van de beheerwerkzaamheden: de logbron, de lokale API-verbinding, de machtigingen en de toewijzing aan de Bouncer moeten op elkaar zijn afgestemd. Vooral bij meerdere diensten moet worden gecontroleerd of de Remediation Component daadwerkelijk vóór de dienst staat waarvan de toegang ze op basis van een beslissing moet blokkeren.

Er moet een onderscheid worden gemaakt tussen lokale scenario-treffers en de optionele Blokkeerlijst van de community. Bij vrijwillige deelname kunnen signalen worden aangeleverd en kunnen gecontroleerde beslissingen over reeds bekende aanvallers worden opgevraagd. Dit is een aanvullende preventieve bron, maar vormt geen vervanging voor lokale detectie en biedt evenmin de garantie dat nieuwe of onopvallende aanvallers worden opgespoord. De herkomst van een blokkeringsbeslissing moet daarom tijdens het gebruik traceerbaar blijven.

De gereedschappen vergelijken op basis van de toepassing

De keuze tussen CrowdSec en Fail2Ban begint bij het beveiligingsdoel, niet bij een algemeen kwaliteitsoordeel. Fail2Ban analyseert logregels met behulp van filters en koppelt deze in ‘jails’ aan acties. CrowdSec verwerkt logbronnen via parsers en scenario’s tot waarschuwingen; de Local API kan daaruit met behulp van profielen beslissingen genereren, die door afzonderlijke herstelcomponenten worden uitgevoerd. Beide zijn afhankelijk van correct geregistreerde gebeurtenissen.

De tabel is geen ranglijst. Voor een klein aantal, goed begrepen logpatronen is een lokale jail vaak gemakkelijker te controleren: de logbron, het filter en de firewallactie liggen dicht bij elkaar. Zodra er meerdere bronnen, voorgeschakelde systemen of verschillende handhavingspunten bij betrokken zijn, kan het zinvol zijn om bij CrowdSec de detectie en reactie van elkaar te scheiden. Dit vereist echter ook dat de relaties tussen de componenten op een traceerbare manier worden beheerd.

Bij het criterium ‘webbeveiliging’ is het technische niveau doorslaggevend. Een CrowdSec Firewall-Bouncer voert beslissingen door op netwerkniveau, maar analyseert geen HTTP-inhoud. Bij een ondersteunde AppSec-configuratie stuurt een daarvoor geschikte Bouncer HTTP-verzoeken door naar de AppSec-component van de Security Engine; daar worden de AppSec-regels geëvalueerd. Deze controle vormt een aanvulling op veilige ontwikkeling en tijdige updates, in plaats van het verhelpen van bekende kwetsbaarheden.

Praktijkvoorbeeld van een afzonderlijke VPS met SSH

Op een kleine Linux-VPS met SSH en een overzichtelijke webstack is Fail2Ban vaak een goed beheersbare keuze. Controleer eerst of mislukte SSH-aanmeldingen, inclusief tijdstempel en bron-IP, betrouwbaar in het daarvoor bestemde logboek of journaal verschijnen. Zonder deze gegevens kan een jail mislukte pogingen niet op betrouwbare wijze tellen, noch het juiste adres doorgeven voor een actie.

Vervolgens kies je een geschikte SSH-jail en controleer je de filters, het tijdsvenster, het toegestane aantal mislukte pogingen en de blokkeringsduur aan de hand van je eigen inlogsituatie. Een jail koppelt een filter aan een of meer acties. Hierdoor kan de blokkering bijvoorbeeld worden gedelegeerd aan de lokale firewall, zonder dat de detectielogica hoeft te worden gedupliceerd. Voor een enkele host houdt deze koppeling het proces meestal transparant.

Beheernetwerken, noodtoegangen en monitoringsystemen hebben bewust gedefinieerde uitzonderingen nodig. Deze moeten strikt beperkt blijven en mogen niet zonder meer grote providernetwerken vrijstellen. Controleer bovendien vóór de uitrol welke firewallregels de actie daadwerkelijk aanmaakt en of IPv4 en IPv6 aansluiten bij het serverconcept. Een gecontroleerde start met logbestanden die worden geanalyseerd, is veiliger dan een onmiddellijke, langdurige blokkering.

Eigen Regex-filter zijn pas zinvol als er geen bestaand filter is dat het specifieke logformaat dekt. De beschikbare handleiding voor het ontwikkelen van filters is gemarkeerd als documentatie voor Fail2Ban 0.9.0.dev en heeft daarom geen betrekking op een stabiele versie zoals 1.1.1. De ontwikkelingsrichtlijnen zijn niettemin praktisch: test nieuwe patronen met geanonimiseerde echte voorbeeldregels en met vergelijkbare, maar legitieme regels. De testtool fail2ban-regex dient daarbij voor de validatie van het filter; het wijzigt geen productiebeperking.

Lokale instellingen horen thuis in .local-bestanden, niet in de geleverde .conf-bestanden. Zo blijven aanpassingen bij pakketupdates traceerbaar en worden ze niet per ongeluk overschreven. Na elke wijziging controleer je de logboekvermelding, de status van de jail en de geactiveerde actie afzonderlijk; een actieve dienst op zich vormt nog geen effectieve blokkeringsketen.

Proxyservers, het echte IP-adres van de client en webbeveiliging

Een CDN, load balancer of reverse proxy verandert het adres dat de server ziet. Als de webserver alleen het IP-adres van de proxy ontvangt en dit als client registreert, zal een op logbestanden gebaseerde blokkering in het ergste geval de tussenliggende server als doelwit aanmerken in plaats van de aanvallende bezoeker. Vóór elke jail, elk scenario en elke WAF-regel moet daarom duidelijk zijn hoe het oorspronkelijke client-IP-adres op betrouwbare wijze wordt doorgegeven, geaccepteerd en geregistreerd.

Deze vertrouwensketen mag niet zomaar elke inkomende header overnemen. Alleen bekende proxy-adressen mogen bevoegd zijn om een doorgegeven adres te leveren; anders zouden externe clients de identiteit kunnen vervalsen waarop de herkenning en blokkering zijn gebaseerd. Controleer aan de hand van geanonimiseerde logboekfragmenten of de applicatie- en toegangslogboeken hetzelfde client-IP-adres vermelden. Documenteer bovendien de doorsturing van headers tussen Edge en Origin. Pas na controle van het client-IP-adres kan een reactie op opvallende HTTP-gebeurtenissen op zinvolle wijze worden geïnterpreteerd.

A IP-blokkering beperkt verbindingen op firewallniveau voordat ze de applicatie bereiken, maar controleert de inhoud van verzoeken niet. Bij een ondersteunde CrowdSec-AppSec-configuratie stuurt een daarvoor geschikte bouncer HTTP-verzoeken door naar de AppSec-component van de Security Engine; waar de relevante AppSec-regels worden gecontroleerd. Een pure firewall-bouncer daarentegen voert beslissingen op netwerkniveau door en beschikt niet over HTTP-controle. Welke variant geschikt is, hangt af van het daadwerkelijke toegangspunt van het verkeer en de gebruikte componenten.

Logboekgebaseerde detectie is bovendien achteraf: er moet eerst een gebeurtenis plaatsvinden, correct worden geregistreerd en als patroon worden herkend. Het voorkomt noch een enkele succesvolle exploit zonder opvallende vervolggebeurtenis, noch vervangt het patches en sterke authenticatie. Upstream-componenten moeten daarom met hun betrouwbare doorsturingen, logbestanden en beveiligingspunten aansluiten bij de totale beveiligingsarchitectuur.

In de praktijk betekent dit: bepaal eerst of de netwerktoegang, het HTTP-verzoek of beide niveaus moeten worden beveiligd. Leg vervolgens het traject vast van het openbare adres via de proxy tot aan het logboekitem en test de blokkades met een goedgekeurd testadres. Zo voorkom je dat een schijnbaar goed werkende Intrusiepreventie alleen de verkeerde infrastructuurcomponent raakt.

Meerdere servers op een gecontroleerde manier beveiligen

Zodra er meerdere hosts, containers of centraal verzamelde logs bij betrokken zijn, wordt de scheiding tussen detectie en handhaving bij CrowdSec praktisch. De Security Engine kan gebeurtenissen uit gedefinieerde bronnen analyseren, terwijl de bijbehorende Remediation Components beslissingen uitvoeren op de betreffende beveiligde punten. CrowdSec documenteert hiervoor ook gedistribueerde implementaties en de integratie naast gecentraliseerde logpijplijnen.

Dat leidt niet automatisch tot lagere exploitatiekosten. Allereerst moet voor elke logbron duidelijk zijn aan welke dienst en welke klant deze is toegewezen. Vervolgens heeft elke bouncer een duidelijk afgebakende verbinding met de lokale API nodig, evenals een eigen toegangssleutel. Een reverse-proxy-bouncer beschermt bijvoorbeeld niet noodzakelijkerwijs een afzonderlijk bereikbare SSH-dienst; de Toewijzing van uitsmijters moet de daadwerkelijke gegevenspaden volgen.

Voor de bedrijfsvoering moeten daarom het tokenbeheer, de bereikbaarheid van de API, de logboeken van processen en fouten, evenals de controle van het blokkerende effect in de monitoring worden opgenomen. Een ‘Decision’ is slechts een detectieresultaat totdat de daarvoor bestemde component deze ophaalt en uitvoert. Bij wijzigingen aan containers, proxies of firewallregels moet deze keten opnieuw worden gecontroleerd, zodat een goed functionerende detectie niet onopgemerkt blijft zonder effectieve reactie.

Als er al eigen ketens en regels bestaan, kan de Firewall-Bouncer in de Alleen-instellen-modus uitsluitend vooraf aangemaakte sets beheren. De verantwoordelijkheid voor regels en ketens blijft dan bewust bij de beheerder liggen. Dit sluit aan bij gecontroleerde firewallconcepten en compliance-eisen, vereist echter inzicht in de bestaande volgorde van de regels en is geen vereenvoudiging voor beginners.

Typische fouten systematisch controleren

Als er geen blokkering optreedt, helpt een vaste controlevolgorde beter dan een overhaaste wisseling van het gereedschap. Eerst moet worden nagegaan of de verwachte gebeurtenis überhaupt met plausibele tijdstempels binnenkomt. Vervolgens moet het geregistreerde adres daadwerkelijk het IP-adres van de client zijn. Pas dan kan op zinvolle wijze worden gecontroleerd of het filter of het scenario het patroon herkent en daaruit een blokkeringsbeslissing voortvloeit.

Bij Fail2Ban volgt na het logboekitem de controle van de jail, het filter en de treffertelling. Een jail koppelt een filter aan een of meer acties; bij bestandsgebaseerde logpaden worden bij het opstarten alleen reeds bestaande bestanden in aanmerking genomen die aan het glob-patroon voldoen. Voor systemd-journaals moeten de backend en de toegangsrechten afzonderlijk worden gecontroleerd. Een jail die er correct uitziet, biedt geen bescherming als deze de daadwerkelijke bron niet leest.

Bij het gebruik van eigen reguliere expressies is bijzondere voorzichtigheid geboden. De beschikbare filterhandleiding is aangemerkt als ontwikkelingsdocumentatie voor Fail2Ban 0.9.0.dev en mag niet worden beschouwd als een gelijkwaardig document voor Fail2Ban 1.1.1. Voor het ontwikkelen van eigen filters is de aanbeveling daarin echter wel zinvol: test patronen eerst met geanonimiseerde, representatieve voorbeeldregels en met regels die bewust niet passen. Zo kunnen variaties in het logboekformaat en mogelijke verkeerde toewijzingen worden opgespoord voordat er een productieve blokkering plaatsvindt.

Bij CrowdSec moet na een treffer in een scenario bovendien de volledige handhavingsketen worden gecontroleerd: als er een waarschuwing ontstaat, kan de Local API op basis daarvan aan de hand van een profiel een beslissing genereren, en bereikt deze de beoogde remediatiecomponent? Zonder correct gekoppelde Bouncer blijft de beslissing op zichzelf staan, zonder actieve blokkering. Vervolgens moet de werking van de firewall of proxy op het juiste toegangspunt worden gecontroleerd, zonder dat men zichzelf de toegang ontzegt vanuit de eigen beheerdersaccount.

De juiste oplossing op lange termijn toepassen

Fail2Ban is vaak geschikt voor een enkele server met duidelijke, lokale logpatronen, zoals herhaalde mislukte SSH-pogingen. De ‘jails’, filters en acties kunnen rechtstreeks worden toegepast op een afgebakende dienst. CrowdSec wordt interessanter wanneer meerdere logbronnen, verschillende handhavingspunten of webbeveiliging met een geschikte component moeten worden gecoördineerd. Doorslaggevend is het aantoonbare gegevenspad, niet een algemeen oordeel over de modernere tool.

Beide oplossingen vereisen een gestructureerd wijzigingsproces: configuraties van een versienummer voorzien, nieuwe filters of scenario’s eerst toetsen aan bekende logvoorbeelden en blokkades monitoren. Updates verdienen dezelfde aandacht. Fail2Ban 1.1.1 werd op 15 augustus 2026 als release gepubliceerd. Lokale aanpassingen en de daadwerkelijk toegepaste firewallacties moeten vóór een update worden afgestemd op de doelomgeving.

Intrusiepreventie vormt een aanvulling op de beveiligingsbasis, maar vervangt deze niet: tijdige updates, sterke en bij voorkeur meerlaagse authenticatie, strenge firewallregels, back-ups en logboekmonitoring blijven noodzakelijk. Met name in hostingomgevingen moet ook de looptijd van de applicatie worden onderhouden. Het artikel over CloudLinux Alt-PHP en de bijbehorende beveiligingsaspecten laat zien waarom gescheiden en goed onderhouden runtime-versies deel uitmaken van een robuust bedrijfsmodel.

Bij webdiensten moet bovendien het volledige traject van de client via het CDN of de reverse proxy naar de origin in de operationele documentatie worden opgenomen. Wijzigingen in protocollen en leveringsroutes kunnen van invloed zijn op welke component verbindingen accepteert en welk adres in het logboek verschijnt. Het artikel over HTTP/2 Server Push bij hosting legt aan de hand van voorbeelden uit hoe de browser, het CDN en de webserver bij de levering samenwerken. Voor de blokkeerlogica blijft het, los daarvan, van cruciaal belang dat het op betrouwbare wijze doorgegeven client-IP-adres beschikbaar is op het juiste beveiligingspunt.

De definitieve keuze blijft controleerbaar: als logformaten, proxy-routes, diensten of het aantal servers veranderen, kan een concept dat voorheen geschikt was, hiaten vertonen. Leg daarom vast welke gebeurtenissen moeten worden gedetecteerd, waar beslissingen worden doorgevoerd en wie uitzonderingen goedkeurt. Dit Bedrijfsdiscipline maakt van een IP-blokkering een beheersbare beschermingsmaatregel in plaats van een onbewaakte wijziging van de firewall.