CrowdSec vs. Fail2Ban: Forskelle i praksis

At sætte CrowdSec og Fail2Ban i den rette sammenhæng

Det rigtige valg afhænger ikke af, hvilket værktøj der anses for at være mest moderne, men af serveren, logdataene og det ønskede anvendelsespunkt. Til en enkelt SSH-tjeneste med klare fejlmeddelelser kan Fail2Ban være en meget direkte løsning. CrowdSec bliver interessant, når flere logkilder, forskellige beskyttelsesniveauer eller distribuerede systemer skal analyseres og sikres samlet.

Begge løsninger tjener til at logbaseret angrebsdetektering: De registrerer sikkerhedsrelevante hændelser, såsom mislykkede loginforsøg, klassificerer dem efter et mønster og kan få en IP-adresse blokeret. Fail2Ban kombinerer til dette formål filtre og handlinger i »jails«. CrowdSec behandler de indlæste data via sin sikkerhedsmotor og træffer beslutninger, hvis gennemførelse varetages af en separat afhjælpningskomponent.

Det afgørende er, hvad der rent faktisk logges. Uden tidsstempel, brugbar kilde-IP og den rette logkilde kan ingen af værktøjerne pålideligt tilskrive et angreb. Desuden yder en blokering kun beskyttelse dér, hvor den teknisk set virker: En lokal firewall-regel hjælper ikke automatisk, hvis datatrafikken først passerer gennem en ekstern reverse proxy eller load balancer.

Som Forebyggelse af indtrængen Begge værktøjer supplerer en sikkerhedsarkitektur, men erstatter den ikke. Sikkerhedsopdateringer lukker kendte sårbarheder, stærk og helst flerstrenget login begrænser misbrug af konti, og restriktive grundregler for firewallen reducerer antallet af tilgængelige tjenester. Sikkerhedskopier begrænser skaderne efter en hændelse, mens løbende logovervågning også afslører problemer, der ikke udløser en spærring.

Det praktiske spørgsmål lyder derfor: Hvilke mønstre skal genkendes, hvor skal reaktionen finde sted, og hvem vedligeholder regler, undtagelser og logfiler? Først derefter kan man træffe en velbegrundet beslutning om, hvorvidt en overskuelig lokal jail-konfiguration er tilstrækkelig, eller om CrowdSecs separate komponenter til infrastrukturen giver en mærkbar merværdi.

Hvordan Fail2Ban knytter »jails« og handlinger sammen

Fail2Ban styrer detektering og reaktion i Fængsler. Ved SSH læser en jail for eksempel godkendelseslogfiler eller systemloggen. Et filter søger heri efter mislykkede loginforsøg fra en kilde-IP. Hvis denne inden for det konfigurerede tidsvindue overskrider det tilladte antal mislykkede forsøg, behandler Fail2Ban fundet som en blokering.

Den efterfølgende handling bestemmer reaktionen. Ofte supplerer den en regel i den lokale firewall, men andre konfigurerede handlinger er også mulige. Dermed er forløbet overskueligt: Logkilden leverer linjer, filteret genkender relevante hændelser, jailen tæller dem, og handlingen iværksætter den fastlagte modforanstaltning. Dette letter fejlfinding, forudsat at logformatet og filteret passer sammen.

En jail bruger præcis ét filter, men kan udføre flere handlinger. Således kan den samme konstaterede SSH-spærring f.eks. udløse en firewall-handling og derudover udløse en notifikation. Flere handlinger gør reaktionen mere fleksibel, men ændrer ikke grundlaget for detekteringen: Alle er afhængige af det samme filter og dets fortolkning af loglinjerne.

Selvskrevne tekster kræver særlig omhu Regex-filter. Den tilgængelige filterdokumentation er udtrykkeligt en udviklingsvejledning til Fail2Ban 0.9.0.dev og ikke en funktionsbeskrivelse for en bestemt stabil pakkeversion. Dine generelle bemærkninger er stadig nyttige for filterudviklingen: Reelle logformatvarianter skal dækkes, mens mønstre ikke må passe for bredt. Nye filtre bør derfor først testes med anonymiserede eksempellinjer, før de udløser blokeringer.

Lokale ændringer skal som udgangspunkt gemmes i filer med filtypenavnet .local, ikke i leverede .conf-filer. På den måde forbliver egne indstillinger for logstier, tilladte netværk eller handlinger mere overskuelige ved pakkeopdateringer og bliver ikke blot overskrevet. Før implementeringen bør man desuden kontrollere, om den valgte logkilde rent faktisk eksisterer og indeholder de forventede hændelser.

CrowdSecs vej fra log til spærring

CrowdSec adskiller detektion og håndhævelse mere tydeligt i separate komponenter. Først definerer indsamlingskilder, hvilke logfiler eller hændelsesstrømme der skal indlæses. Parsere normaliserer disse data; derefter vurderer scenarier mønstre og adfærd. Hvis der findes et matchende mønster, udløses en alarm. Local API kan på baggrund af konfigurerede profiler generere en beslutning ud fra dette, f.eks. en tidsbegrænset IP-spærring.

Et kort eksempel illustrerer forløbet: Autentificeringsfejl fra en tjeneste sendes via Acquisition til Engine. Parsere genkender felter som tid, tjeneste og kilde-IP; et scenarie vurderer gentagne mislykkede forsøg. Den deraf genererede alarm videregives til Local API, som kan træffe en beslutning ved hjælp af en passende profil. Først en tilsluttet Saneringskomponent gennemfører denne beslutning på det fastsatte beskyttelsespunkt.

Denne komponent kaldes traditionelt også en »bouncer«. Afhængigt af varianten kan den f.eks. håndhæve beslutninger på en firewall, en reverse proxy eller en webserver. Security Engine alene registrerer hændelser og administrerer alarmer samt beslutninger via Local API, men blokerer ikke datatrafik. Uden en korrekt tilkoblet Remediation Component forbliver en genereret beslutning blot en information uden aktiv netværks- eller applikationsblokering.

I praksis gør denne opdeling det muligt at fordele identifikation og blokering på forskellige punkter i infrastrukturen. Det øger dog omfanget af driften: Logkilden, den lokale API-forbindelse, tilladelser og Bouncer-tildelingen skal passe sammen. Især ved flere tjenester skal det kontrolleres, om Remediation Component virkelig befinder sig foran den tjeneste, hvis adgang den skal blokere på baggrund af en beslutning.

Der skal skelnes mellem lokale scenarie-treffere og den valgfri Fællesskabets blokeringsliste. Ved frivillig deltagelse kan man bidrage med signaler og hente kuraterede beslutninger vedrørende allerede kendte angribere. Dette er en yderligere forebyggende kilde, men hverken en erstatning for lokal detektion eller en garanti for, at nye eller diskrete angribere bliver opdaget. Oprindelsen af en blokeringsbeslutning bør derfor forblive sporbar i driften.

Sammenlign værktøjerne efter anvendelsesformål

Valget mellem CrowdSec og Fail2Ban tager udgangspunkt i beskyttelsesaspektet, ikke i en generel kvalitetsvurdering. Fail2Ban analyserer loglinjer ved hjælp af filtre og knytter disse til handlinger i »jails«. CrowdSec behandler logkilder via parsere og scenarier til alarmer; Local API kan ud fra disse ved hjælp af profiler generere beslutninger, som gennemføres af separate afhjælpningskomponenter. Begge er afhængige af korrekt registrerede hændelser.

Tabellen er ikke en rangliste. For nogle få, velkendte logmønstre er det ofte nemmere at kontrollere en lokal jail: Logkilden, filteret og firewall-handlingen ligger tæt på hinanden. Så snart der er flere kilder, opstrøms systemer eller forskellige håndhævelsespunkter involveret, kan det være fornuftigt at adskille detektion og reaktion i CrowdSec. Det kræver dog også, at sammenhængene mellem komponenterne håndteres på en overskuelig måde.

Når det gælder kriteriet »webbeskyttelse«, er det det tekniske niveau, der er afgørende. En CrowdSec Firewall-Bouncer gennemfører beslutninger på netværksniveau, men analyserer ikke HTTP-indhold. I en understøttet AppSec-opsætning videresender en egnet Bouncer HTTP-anmodninger til AppSec-komponenten i Security Engine, hvor AppSec-reglerne evalueres. Denne kontrol supplerer sikker udvikling og rettidige opdateringer i stedet for at udbedre kendte sårbarheder.

Praktisk eksempel på en enkelt VPS med SSH

På en lille Linux-VPS med SSH og et overskueligt webstack er Fail2Ban ofte et godt og overskueligt valg. Først skal du kontrollere, om mislykkede SSH-login-forsøg med tidsstempel og kilde-IP pålideligt vises i den dertil beregnede log eller journal. Uden disse data kan en jail hverken tælle mislykkede forsøg på en pålidelig måde eller videregive den korrekte adresse til en handling.

Derefter vælger du en passende SSH-jail og kontrollerer filtre, tidsvinduer, tilladte fejlforsøg og spærreperiode i forhold til din egen logon-praksis. En jail forbinder et filter med en eller flere handlinger. Dermed kan spærringen f.eks. delegeres til den lokale firewall uden at duplikere detekteringslogikken. For en enkelt host gør denne sammenkobling forløbet som regel gennemsigtigt.

Administrationsnetværk, nødadgange og overvågningssystemer kræver bevidst definerede undtagelser. Disse bør være snævert afgrænsede og må ikke generelt undtage store udbydernetværk. Kontroller desuden inden implementeringen, hvilke firewall-regler foranstaltningen rent faktisk opretter, og om IPv4 og IPv6 passer til serverkonceptet. En kontrolleret opstart med overvågning af logfiler er sikrere end en øjeblikkelig, langvarig spærring.

Egne Regex-filter er kun nyttige, hvis der ikke findes et eksisterende filter, der dækker det konkrete logformat. Den tilgængelige vejledning til filterudvikling er mærket som dokumentation til Fail2Ban 0.9.0.dev og gælder derfor ikke for en stabil version som f.eks. 1.1.1. Dens udviklingsvejledning er ikke desto mindre praktisk: Test nye mønstre med anonymiserede, ægte eksempellinjer og med lignende, men legitime linjer. Testværktøjet fail2ban-regex Dette tjener til filtervalidering; det ændrer ikke produktionsspærringen.

Lokale indstillinger hører hjemme i .local-filer, ikke i de leverede .conf-filer. På den måde forbliver tilpasningerne ved pakkeopdateringer sporbare og bliver ikke ved et uheld overskrevet. Efter hver ændring kontrollerer du logindgangen, jail-status og den udløste handling hver for sig; en kørende tjeneste i sig selv udgør endnu ikke en effektiv spærrekæde.

Proxyservere, ægte klient-IP og webbeskyttelse

Et CDN, en load balancer eller en reverse proxy ændrer den adresse, som serveren ser. Hvis webserveren kun modtager proxyens IP-adresse og registrerer den som klient, vil en logbaseret spærring i værste fald ramme den fælles formidler i stedet for den angribende besøgende. Før hver jail, hvert scenarie og hver WAF-regel skal det derfor afklares, hvordan den oprindelige klient-IP pålideligt videregives, accepteres og logges.

Denne tillidskæde må ikke blot overtage enhver indgående header. Kun kendte proxy-adresser må have tilladelse til at levere en videresendt adresse; ellers kunne eksterne klienter forfalske den identitet, som genkendelsen og blokeringen bygger på. Kontroller ved hjælp af anonymiserede logudtræk, om applikations- og adgangsloggen viser den samme klient-IP. Dokumenter desuden videresendelsen af headere mellem Edge og Origin. Først efter kontrollen af klient-IP’en kan en reaktion på mistænkelige HTTP-hændelser fortolkes på en meningsfuld måde.

En IP-blokering begrænser forbindelser på firewall-niveau, før de når frem til applikationen, men kontrollerer ikke indholdet af anmodningerne. I en understøttet CrowdSec-AppSec-opsætning videresender en egnet Bouncer HTTP-anmodninger til AppSec-komponenten i Security Engine; hvor de relevante AppSec-regler kontrolleres. En ren firewall-bouncer gennemfører derimod beslutninger på netværksniveau og foretager ingen HTTP-kontrol. Hvilken variant der passer, afhænger af trafikkens faktiske indgangssted og de anvendte komponenter.

Logbaseret detektion er desuden en efterfølgende proces: Først skal der indtræde en hændelse, som skal logges korrekt og genkendes som et mønster. Den forhindrer hverken et enkelt vellykket angreb uden en iøjnefaldende efterfølgende hændelse, og den erstatter heller ikke sikkerhedsopdateringer og stærk autentificering. De forudgående komponenter skal derfor passe ind i den samlede sikkerhedsarkitektur med deres pålidelige videreformidlinger, logfiler og beskyttelsespunkter.

I praksis betyder det: Beslut først, om netværksadgangen, HTTP-forespørgslen eller begge niveauer skal beskyttes. Dokumenter derefter vejen fra den offentlige adresse via proxyen til logposten, og test blokeringerne med en godkendt testadresse. På den måde undgår du, at en tilsyneladende velfungerende Forebyggelse af indtrængen kun den forkerte infrastrukturkomponent rammes.

Kontrolleret sikring af flere servere

Så snart der er flere værter, containere eller centralt indsamlede logfiler involveret, bliver adskillelsen af detektion og håndhævelse i CrowdSec praktisk. Sikkerhedsmotoren kan analysere hændelser fra definerede kilder, mens de relevante afhjælpningskomponenter gennemfører beslutningerne på de respektive beskyttede punkter. CrowdSec dokumenterer i den forbindelse også distribuerede installationer og integrationen ved siden af centraliserede log-pipelines.

Det reducerer ikke automatisk driftsomkostningerne. Først skal det for hver logkilde være muligt at spore, hvilken tjeneste og hvilken klient den er tilknyttet. Derefter skal hver bouncer have en klart afgrænset forbindelse til den lokale API samt sin egen adgangsnøgle. En reverse-proxy-bouncer beskytter for eksempel ikke nødvendigvis en separat tilgængelig SSH-tjeneste; den Tildeling af dørmænd skal følge de faktiske dataveje.

I driften skal overvågningen derfor omfatte token-administration, API’ens tilgængelighed, logfiler over udløb og fejl samt kontrol af blokeringsvirkningen. En beslutning er kun et detekteringsresultat, indtil den pågældende komponent henter den og gennemfører den. Ved ændringer af containere, proxyservere eller firewall-regler bør denne kæde kontrolleres på ny, så en velfungerende detektion ikke forbliver ubemærket uden en effektiv reaktion.

Hvis der allerede findes egne kæder og regler, kan Firewall-Bouncer i "Set-only"-tilstand udelukkende administrere sæt, der er oprettet på forhånd. Ansvaret for regler og kæder forbliver så bevidst hos operatøren. Dette passer godt til kontrollerede firewall-koncepter og compliance-krav, men kræver dog forståelse for den eksisterende rækkefølge af regler og er ikke en forenkling for nybegyndere.

Systematisk kontrol af typiske fejl

Hvis der ikke opstår en blokering, er en fast kontrolrækkefølge mere nyttig end et forhastet skift af værktøjet. Først skal det afklares, om den forventede hændelse overhovedet modtages med plausible tidsstempler. Derefter skal den loggede adresse virkelig være klientens IP-adresse. Først da kan man på en meningsfuld måde kontrollere, om filteret eller scenariet genkender mønsteret, og om der deraf følger en beslutning om blokering.

I Fail2Ban følger kontrollen af jail, filter og hit-tælling efter logindlæsningen. En jail forbinder et filter med en eller flere handlinger; ved filbaserede logstier tages der ved opstart kun hensyn til allerede eksisterende filer, der passer til glob-mønsteret. For systemd-journaler skal backend og adgangsrettigheder kontrolleres separat. En jail, der ser korrekt ud, yder ingen beskyttelse, hvis den ikke læser den faktiske kilde.

Egne regulære udtryk kræver særlig forsigtighed. Den tilgængelige filtervejledning er mærket som udviklingsdokumentation for Fail2Ban 0.9.0.dev og skal ikke opfattes som en version, der svarer til Fail2Ban 1.1.1. Dens anbefalinger er dog stadig nyttige, når man udvikler egne filtre: Test mønstrene først med anonymiserede, repræsentative eksempellinjer og med linjer, der bevidst ikke passer. På den måde kan man opdage variationer i logformater og mulige fejlagtige klassificeringer, inden der foretages en produktiv blokering.

I CrowdSec skal man efter et scenarie-match desuden kontrollere hele håndhævelseskæden: Hvis der opstår en alarm, kan Local API på baggrund heraf generere en beslutning ved hjælp af en profil, og når denne beslutning frem til den tilsigtede afhjælpningskomponent? Uden en korrekt tilkoblet Bouncer forbliver beslutningen alene uden aktiv spærring. Derefter skal firewallens eller proxyens virkning kontrolleres ved det relevante indgangssted, uden at man spærrer sig selv ude fra sin egen administrative adgang.

At drive den rette løsning på lang sigt

Fail2Ban egner sig ofte til en enkelt server med klare, lokale logmønstre, f.eks. gentagne mislykkede SSH-forsøg. Dens »jails«, filtre og handlinger kan henføres direkte til en afgrænset tjeneste. CrowdSec bliver mere interessant, når flere logkilder, forskellige håndhævelsespunkter eller webbeskyttelse skal koordineres med en passende komponent. Det afgørende er den påviselige datavej, ikke en generel vurdering af, hvilket værktøj der er det mest moderne.

Begge løsninger kræver en struktureret ændringsproces: Konfigurationer skal versionsstyres, nye filtre eller scenarier skal først testes mod kendte logeksempler, og blokeringer skal overvåges. Opdateringer fortjener samme opmærksomhed. Fail2Ban 1.1.1 blev udgivet den 15. august 2026. Lokale tilpasninger og de faktisk anvendte firewall-handlinger bør afstemmes med målmiljøet inden en opdatering.

Forebyggelse af indtrængen supplerer sikkerhedsgrundlaget, men erstatter det ikke: løbende opdateringer, stærk og helst flertrins-login, restriktive firewall-regler, sikkerhedskopier og logovervågning er stadig nødvendige. Især i hosting-miljøer bør man også holde øje med applikationernes driftstid. Artiklen om CloudLinux Alt-PHP og dets sikkerhedsaspekter viser, hvorfor adskilte og velvedligeholdte runtime-versioner er en del af en robust driftsmodel.

Når det gælder webtjenester, skal den fulde vej fra klienten via CDN eller reverse proxy til origin desuden fremgå af driftsdokumentationen. Ændringer i protokoller og leveringsveje kan have indflydelse på, hvilken komponent der modtager forbindelser, og hvilken adresse der vises i loggen. Artiklen om HTTP/2 Server Push i hosting forklarer ved hjælp af eksempler, hvordan browseren, CDN’en og webserveren samarbejder om leveringen. Uanset dette er det afgørende for blokeringslogikken, at den pålideligt overførte klient-IP er tilgængelig på det rette beskyttelsespunkt.

Det langsigtede valg skal fortsat kunne kontrolleres: Hvis logformater, proxy-ruter, tjenester eller antallet af servere ændrer sig, kan et koncept, der tidligere var passende, få huller. Notér derfor, hvilke hændelser der skal registreres, hvor beslutninger skal gennemføres, og hvem der godkender undtagelser. Disse Arbejdsdisciplin gør en IP-blokering til en kontrollerbar beskyttelsesforanstaltning i stedet for en uovervåget ændring af firewallen.