CrowdSec vs. Fail2Ban: Skillnader i praktisk användning

Att sätta CrowdSec och Fail2Ban i rätt sammanhang

Det rätta valet beror inte på vilket verktyg som anses vara modernast, utan på servern, loggdata och önskad tillämpningspunkt. För en enskild SSH-tjänst med tydliga felmeddelanden kan Fail2Ban vara ett mycket direkt val. CrowdSec blir intressant när flera loggkällor, olika skyddsnivåer eller distribuerade system ska utvärderas och säkras gemensamt.

Båda lösningarna syftar till att loggbaserad attackdetektering: De avläser säkerhetsrelaterade händelser, såsom misslyckade inloggningsförsök, klassificerar dem enligt ett mönster och kan se till att en IP-adress spärras. Fail2Ban kombinerar för detta ändamål filter och åtgärder i så kallade ”jails”. CrowdSec bearbetar insamlade data via sin säkerhetsmotor och fattar beslut, vars genomförande sköts av en separat åtgärdskomponent.

Det avgörande är vad som faktiskt loggas. Utan tidsstämpel, användbar käll-IP och rätt loggkälla kan inget av verktygen på ett tillförlitligt sätt identifiera varifrån en attack kommer. En blockering ger dessutom endast skydd där den tekniskt sett är effektiv: en lokal brandväggsregel hjälper inte automatiskt om datatrafiken först passerar en extern omvänd proxy eller lastbalanserare.

Som Intrångsskydd Båda verktygen kompletterar en säkerhetsarkitektur, men ersätter den inte. Säkerhetsuppdateringar åtgärdar kända sårbarheter, stark och helst flerstegsautentisering begränsar kontomisbruk, och restriktiva grundregler för brandväggen minskar antalet tillgängliga tjänster. Säkerhetskopior begränsar skadorna efter en incident, medan kontinuerlig loggövervakning även synliggör problem som inte utlöser någon spärr.

Den praktiska frågan lyder därför: Vilka mönster måste identifieras, var ska åtgärden vidtas och vem sköter regler, undantag och loggar? Först därefter går det att fatta ett välgrundat beslut om huruvida en överskådlig lokal jail-konfiguration räcker eller om CrowdSecs separata komponenter ger ett märkbart mervärde för infrastrukturen.

Hur Fail2Ban kopplar samman ”jails” och åtgärder

Fail2Ban hanterar detektering och åtgärder i Fängelser. Vid SSH läser en jail till exempel autentiseringsloggar eller systemloggen. Ett filter söker där efter misslyckade inloggningsförsök från en käll-IP. Om antalet misslyckade försök från denna IP överskrider det tillåtna antalet inom det konfigurerade tidsfönstret, behandlar Fail2Ban träffen som ett blockeringsfall.

Den efterföljande åtgärden avgör reaktionen. Ofta kompletterar den en regel i den lokala brandväggen, men även andra konfigurerade åtgärder är möjliga. På så sätt blir kedjan tydlig: loggkällan levererar rader, filtret identifierar relevanta händelser, jailen räknar dem och åtgärden genomför den avsedda motåtgärden. Detta underlättar felsökningen, förutsatt att loggformatet och filtret stämmer överens.

En jail använder exakt ett filter, men kan utföra flera åtgärder. På så sätt kan till exempel samma upptäckta SSH-blockering utlösa en brandväggsåtgärd och dessutom generera en avisering. Flera åtgärder gör reaktionen mer flexibel, men förändrar inte grunden för detekteringen: alla är kopplade till samma filter och dess tolkning av loggraderna.

Särskild omsorg krävs för texter som man skrivit själv Regex-filter. Den tillgängliga filterdokumentationen är uttryckligen en utvecklingsguide för Fail2Ban 0.9.0.dev och inte en funktionsbeskrivning för en specifik stabil paketversion. Dina allmänna anvisningar är fortfarande användbara för filterutvecklingen: Verkliga loggformatvarianter måste täckas in, samtidigt som mönstren inte får vara för generella. Nya filter bör därför först testas med anonymiserade exempelrader innan de utlöser blockeringar.

Lokala ändringar ska i princip göras i filer med filändelsen .local, inte i levererade .conf-filer. På så sätt blir egna inställningar för loggvägar, tillåtna nätverk eller åtgärder lättare att spåra vid paketuppdateringar och skrivs inte bara över. Innan lanseringen bör man dessutom kontrollera om den valda loggkällan verkligen finns och innehåller de förväntade händelserna.

CrowdSecs väg från logg till spärrning

CrowdSec separerar detektering och genomförande tydligare i enskilda komponenter. Först definierar insamlingskällorna vilka loggar eller händelseströmmar som ska läsas in. Parsrar normaliserar dessa data; därefter utvärderar scenarier mönster och beteenden. Om ett mönster stämmer överens genereras en varning. Det lokala API:et kan utifrån konfigurerade profiler fatta ett beslut, till exempel en tidsbegränsad IP-spärr.

Ett kort exempel illustrerar hur det går till: Autentiseringsfel från en tjänst skickas via Acquisition till motorn. Parsrar identifierar fält som tid, tjänst och käll-IP; ett scenario utvärderar upprepade misslyckade försök. Den varning som genereras därifrån vidarebefordras till Local API, som kan fatta ett beslut med hjälp av en lämplig profil. Först en ansluten Saneringskomponent genomför detta beslut vid den avsedda skyddspunkten.

Denna komponent kallas traditionellt även för ”Bouncer”. Beroende på variant kan den till exempel genomdriva beslut vid en brandvägg, en omvänd proxy eller en webbserver. Säkerhetsmotorn i sig själv upptäcker incidenter och hanterar varningar samt beslut via det lokala API:et, men blockerar inte någon datatrafik. Utan en korrekt ansluten åtgärdskomponent förblir ett genererat beslut endast information utan någon aktiv nätverks- eller applikationsblockering.

I praktiken gör denna uppdelning det möjligt att fördela identifiering och blockering på olika punkter i infrastrukturen. Det ökar dock omfattningen av driften: loggkälla, lokal API-anslutning, behörigheter och Bouncer-tilldelning måste stämma överens. Särskilt vid flera tjänster måste man kontrollera om Remediation Component verkligen ligger före den tjänst vars åtkomst den ska blockera på grund av ett beslut.

Man måste skilja mellan lokala scenarioträffar och den valfria Blocklista för communityn. Vid frivilligt deltagande kan signaler bidragas med och kuraterade beslut om redan kända angripare hämtas. Detta är en ytterligare förebyggande källa, men varken en ersättning för lokal detektering eller en garanti för att nya eller svårupptäckta angripare ska upptäckas. Ursprunget till ett spärrbeslut bör därför förbli spårbart i driften.

Jämföra verktygen utifrån användningsområdet

Valet mellan CrowdSec och Fail2Ban utgår från säkerhetsaspekten, inte från en allmän kvalitetsbedömning. Fail2Ban analyserar loggrader med hjälp av filter och kopplar dessa till åtgärder i så kallade ”jails”. CrowdSec bearbetar loggkällor via parsers och scenarier till varningar; det lokala API:et kan utifrån detta, med hjälp av profiler, generera beslut som genomförs av separata åtgärdskomponenter. Båda är beroende av korrekt registrerade händelser.

Tabellen är ingen ranglista. För ett fåtal, välkända loggmönster är det ofta enklare att granska en lokal jail: loggkällan, filtret och brandväggsåtgärden ligger nära varandra. Så snart flera källor, uppströms system eller olika tillämpningspunkter är inblandade kan det vara lämpligt att separera detektering och reaktion i CrowdSec. Det kräver dock också att relationerna mellan komponenterna hanteras på ett överskådligt sätt.

När det gäller kriteriet webbskydd är den tekniska nivån avgörande. En CrowdSec Firewall-Bouncer tillämpar beslut på nätverksnivå, men granskar inte HTTP-innehåll. Vid en stödd AppSec-konfiguration vidarebefordrar en lämplig Bouncer HTTP-förfrågningar till AppSec-komponenten i säkerhetsmotorn, där AppSec-reglerna utvärderas. Denna kontroll kompletterar säker utveckling och snabba uppdateringar, istället för att åtgärda kända sårbarheter.

Praktiskt exempel på en enskild VPS med SSH

På en liten Linux-VPS med SSH och en överskådlig webbstack är Fail2Ban ofta ett bra och lättkontrollerat val. Först kontrollerar du om misslyckade SSH-inloggningar med tidsstämpel och käll-IP pålitligt visas i den avsedda loggen eller journalen. Utan dessa uppgifter kan en jail varken räkna misslyckade försök på ett tillförlitligt sätt eller vidarebefordra rätt adress till en åtgärd.

Därefter väljer du en lämplig SSH-jail och kontrollerar filter, tidsfönster, tillåtna misslyckade inloggningsförsök och spärrtid mot din egen inloggningssituation. En jail kopplar samman ett filter med en eller flera åtgärder. På så sätt kan spärren till exempel delegeras till den lokala brandväggen utan att detekteringslogiken behöver dupliceras. För en enskild värd gör denna koppling oftast processen transparent.

Administrationsnät, nödåtkomst och övervakningssystem kräver medvetet definierade undantag. Dessa bör vara strikt begränsade och inte generellt undanta stora leverantörsnät. Kontrollera dessutom före driftsättningen vilka brandväggsregler åtgärden faktiskt skapar och om IPv4 och IPv6 passar in i serverkonceptet. En kontrollerad start med övervakade loggar är säkrare än en omedelbar, långvarig blockering.

Egen Regex-filter är endast meningsfulla om det inte finns något befintligt filter som täcker det specifika loggformatet. Den tillgängliga vägledningen för filterutveckling är märkt som dokumentation för Fail2Ban 0.9.0.dev och gäller därför inte någon stabil version som 1.1.1. Dess utvecklingsanvisningar är ändå praktiska: Testa nya mönster med anonymiserade verkliga exempelrader och med liknande, men legitima rader. Testverktyget fail2ban-regex används för att validera filtret; det ändrar inte någon produktionsspärr.

Lokala inställningar hör hemma i .local-filer, inte i de medföljande .conf-filer. På så sätt förblir justeringarna vid paketuppdateringar spårbara och riskerar inte att raderas av misstag. Efter varje ändring kontrollerar du loggposten, jail-statusen och den utlösta åtgärden separat; en pågående tjänst i sig utgör ännu inte en effektiv spärrkedja.

Proxyservrar, verklig klient-IP och webbskydd

Ett CDN, en lastbalanserare eller en omvänd proxy ändrar vilken adress servern ser. Om webbservern endast får proxyns IP-adress och loggar den som klient, kan en loggbaserad blockering i värsta fall felaktigt identifiera den gemensamma mellanhanden istället för den angripande besökaren. Innan varje jail, varje scenario och varje WAF-regel måste därför det klargöras hur den ursprungliga klient-IP-adressen på ett tillförlitligt sätt vidarebefordras, accepteras och loggas.

Denna förtroendekedja får inte utan vidare övertaga varje inkommande header. Endast kända proxyadresser får ha behörighet att tillhandahålla en vidarebefordrad adress; annars skulle externa klienter kunna förfalska den identitet som ligger till grund för identifiering och blockering. Kontrollera med anonymiserade loggutdrag om applikations- och åtkomstloggarna visar samma klient-IP. Dokumentera dessutom vidarebefordran av rubriker mellan Edge och Origin. Först efter kontroll av klient-IP:n kan en reaktion på misstänkta HTTP-händelser tolkas på ett meningsfullt sätt.

En IP-blockering begränsar anslutningar på brandväggsnivå innan de når applikationen, men kontrollerar inte innehållet i förfrågningarna. I en stödd CrowdSec-AppSec-konfiguration vidarebefordrar en lämplig ”bouncer” HTTP-förfrågningar till AppSec-komponenten i säkerhetsmotorn; där kontrolleras tillämpliga AppSec-regler. En ren brandväggsbouncer genomför däremot beslut på nätverksnivå och har ingen HTTP-kontroll. Vilken variant som passar beror på trafikens faktiska ingångspunkt och de komponenter som används.

Loggbaserad detektering är dessutom en efterhandsåtgärd: Först måste en händelse inträffa, loggas korrekt och identifieras som ett mönster. Den förhindrar varken en enskild lyckad attack utan någon märkbar efterföljande händelse, och ersätter inte heller säkerhetsuppdateringar och stark autentisering. Komponenter i tidigare led i kedjan måste därför passa in i den övergripande säkerhetsarkitekturen med sina tillförlitliga vidarebefordringar, loggar och skyddspunkter.

I praktiken innebär det följande: Bestäm först om nätverksåtkomst, HTTP-förfrågningar eller båda nivåerna ska skyddas. Dokumentera därefter vägen från den offentliga adressen via proxyservern till loggposten och testa blockeringarna med en godkänd testadress. På så sätt undviker du att en till synes fungerande Intrångsskydd endast den felaktiga infrastrukturkomponenten påverkas.

Säkra flera servrar på ett kontrollerat sätt

Så snart flera värdar, containrar eller centralt insamlade loggar är inblandade blir det praktiskt att separera detektering och genomförande i CrowdSec. Säkerhetsmotorn kan utvärdera händelser från definierade källor, medan lämpliga åtgärdskomponenter genomför beslut vid respektive skyddade punkter. CrowdSec dokumenterar även distribuerade installationer och integrationen vid sidan av centraliserade loggpipelines.

Det minskar inte automatiskt driftskostnaderna. Först måste det gå att spåra vilken tjänst och vilken klient varje loggkälla är tilldelad. Därefter behöver varje bouncer en tydligt avgränsad anslutning till det lokala API:et samt en egen åtkomstnyckel. En reverse-proxy-bouncer skyddar till exempel inte nödvändigtvis en separat tillgänglig SSH-tjänst; den Tilldelning av dörrvakter måste följa de faktiska datavägarna.

I driften bör därför tokenhantering, API:ets tillgänglighet, händelse- och felprotokoll samt kontroll av blockeringseffekten ingå i övervakningen. Ett beslut är endast ett identifieringsresultat tills den avsedda komponenten hämtar och verkställer det. Vid ändringar av containrar, proxyservrar eller brandväggsregler bör denna kedja kontrolleras på nytt, så att en fungerande detektering inte förblir obemärkt utan att leda till en effektiv reaktion.

Om det redan finns egna kedjor och regler kan Firewall-Bouncer i Läget ”Endast inställningar” hantera uteslutande tidigare skapade uppsättningar. Ansvaret för regler och kedjor ligger då medvetet kvar hos operatören. Detta passar väl in i kontrollerade brandväggskoncept och efterlevnadskrav, men kräver förståelse för den befintliga regelordningen och innebär ingen förenkling för nybörjare.

Systematiskt kontrollera vanliga fel

Om spärren uteblir är det bättre att följa en fast kontrollordning än att byta verktyg förhastat. Först måste man klargöra om den förväntade händelsen överhuvudtaget kommer in med rimliga tidsstämplar. Därefter måste den loggade adressen verkligen vara klientens IP-adress. Först då går det att på ett meningsfullt sätt kontrollera om filtret eller scenariot känner igen mönstret och om detta leder till ett beslut om blockering.

I Fail2Ban följer kontroll av jail, filter och träffräkning efter loggposten. En jail kopplar samman ett filter med en eller flera åtgärder; vid filbaserade loggvägar beaktas vid start endast befintliga filer som stämmer överens med glob-mönstret. För systemd-journaler måste backend och åtkomsträttigheter kontrolleras separat. En jail som ser korrekt ut ger inget skydd om den inte läser den faktiska källan.

Egna reguljära uttryck kräver särskild försiktighet. Den tillgängliga filterguiden är märkt som utvecklingsdokumentation för Fail2Ban 0.9.0.dev och ska inte tolkas som en version som motsvarar Fail2Ban 1.1.1. För utveckling av egna filter är dock rekommendationen ändå värdefull: Testa mönstren först med anonymiserade, representativa exempelrader och med rader som medvetet inte passar in. På så sätt kan man upptäcka variationer i loggformatet och eventuella felaktiga klassificeringar innan en spärr träder i kraft i produktionsmiljön.

I CrowdSec måste dessutom hela genomförandekedjan kontrolleras efter en träff mot ett scenario: Om en varning uppstår, kan Local API utifrån en profil generera ett beslut utifrån detta, och når beslutet den avsedda åtgärdskomponenten? Utan en korrekt ansluten Bouncer förblir beslutet enbart ett beslut utan aktiv spärr. Därefter måste brandväggens eller proxyns funktion kontrolleras vid rätt ingångspunkt, utan att man stänger ute sig själv från sin egen administrativa åtkomst.

Att driva den rätta lösningen på lång sikt

Fail2Ban passar ofta för en enskild server med tydliga, lokala loggmönster, till exempel upprepade misslyckade SSH-försök. Dess ”jails”, filter och åtgärder kan kopplas direkt till en avgränsad tjänst. CrowdSec blir ett mer intressant alternativ när flera loggkällor, olika tillämpningspunkter eller webbskydd ska samordnas med en lämplig komponent. Det avgörande är den verifierbara datavägen, inte en generell bedömning av vilket verktyg som är modernast.

Båda lösningarna kräver en strukturerad ändringsprocess: versionera konfigurationer, testa nya filter eller scenarier mot kända loggexempel i ett första steg och övervaka blockeringar. Uppdateringar bör behandlas på samma sätt. Fail2Ban 1.1.1 släpptes den 15 augusti 2026. Lokala anpassningar och de brandväggsåtgärder som faktiskt används bör jämföras med målmiljön innan en uppdatering genomförs.

Intrångsskydd kompletterar säkerhetsgrunden, men ersätter den inte: regelbundna uppdateringar, stark och helst flerstegsautentisering, restriktiva brandväggsregler, säkerhetskopiering och loggövervakning är fortfarande nödvändiga. Särskilt i webbhotellsmiljöer bör även applikationernas körtid underhållas. Artikeln om CloudLinux Alt-PHP och dess säkerhetsaspekter visar varför separata och välskötta runtime-versioner är en del av en robust driftsmodell.

När det gäller webbtjänster ska dessutom hela vägen från klienten via CDN eller omvänd proxy till ursprungsservern ingå i driftsdokumentationen. Ändringar av protokoll och leveransvägar kan påverka vilken komponent som tar emot anslutningar och vilken adress som visas i loggen. Artikeln om HTTP/2 Server Push vid webbhotell förklarar med hjälp av exempel hur webbläsare, CDN och webbserver samverkar vid leveransen. Oavsett detta är det avgörande för spärrlogiken att den på ett tillförlitligt sätt överförda klient-IP-adressen finns tillgänglig vid rätt skyddspunkt.

Det långsiktiga valet måste kunna granskas: Om loggformat, proxyvägar, tjänster eller antalet servrar förändras kan ett koncept som tidigare passade börja uppvisa brister. Dokumentera därför vilka händelser som ska identifieras, var beslut ska genomföras och vem som godkänner undantag. Dessa Arbetsdisciplin gör en IP-blockering till en kontrollerbara skyddsåtgärd istället för en obevakad ändring av brandväggen.