Alternativer til Fail2Ban til moderne Linux-servere

Kontroller angrebsfladen, inden du vælger værktøj

En Alternativ til Fail2Ban kan først vælges på en meningsfuld måde, når det står klart, hvilke tjenester der rent faktisk kan nås. SSH, SMTP, IMAP og en HTTP-applikation har forskellige logon-procedurer, logkilder og skadesmønstre. En offentligt tilgængelig databasetjeneste bør derimod som regel ikke behøve at blive beskyttet af en internetblokeringsliste: Dens netværksadgang bør begrænses til nødvendige applikationer og pålidelige netværk.

Ved administrative tilgange har Adgangsbegrænsning og stærk autentificering har forrang frem for automatiske IP-blokeringer. En SSH-tjeneste bag et VPN, en bastion-host eller faste administrationsnetværk udgør et væsentligt mindre angrebsflade for angribere end en port, der er åben på verdensplan. Aktuelle sikkerhedsopdateringer, adskilte privilegerede konti og omhyggeligt afvejede adgangskoder reducerer de risici, som en blokeringsliste alene ikke kan fjerne.

Hvis SSH bevidst er offentligt tilgængeligt, kan begrænsninger og logbaserede spærringer dæmpe gentagne adgangskodeforsøg. De er dog kun et supplement: Personer bag en fælles NAT-gateway kan bruge den samme kildeadresse, mens distribuerede angreb anvender mange adresser. For e-mailtjenester er det desuden vigtigt, hvilke protokoller der rent faktisk er åbne for eksterne brugere, og hvilke fejlagtige loginforsøg der logges.

Når det gælder webapplikationer, skal man skelne mellem tilgængeligheden af reverse proxyen og de interne backend-tjenester. En offentlig Nginx kan modtage HTTP-anmodninger, uden at databasen, cachen eller administrationsgrænsefladen behøver at være tilgængelige fra internettet. Det Bevaringsmål Det handler derfor ikke generelt om at „blokere IP-adresser“, men om at begrænse uautoriseret adgang for hver enkelt tjeneste, opretholde legitim brug og undgå unødvendige tilladelser.

Inden enhver ændring bør de ansvarlige kortlægge, hvilke adgangsveje der er nødvendige i en nødsituation, og hvilke kildenetværk der har regelmæssig adgang. Denne kortlægning forhindrer, at en for restriktiv firewall-regel blokerer den egne administratoradgang eller automatiseret vedligeholdelse. Først derefter kan man afgøre, om loganalyse, forbindelsesbegrænsning eller et flertrinskoncept er passende.

En blokering besvarer desuden ikke spørgsmålet om, hvorvidt en tjeneste overhovedet skal være offentlig. Hvis man vender denne rækkefølge om, behandler man iøjnefaldende forbindelser, selvom den grundlæggende eksponering forbliver uændret. Især når det gælder sjældent anvendte administrationsgrænseflader, er en privat adgangsvej ofte mere effektiv og nemmere at administrere end stadig mere komplekse genkendelsesregler.

Fire tilgange i stedet for et alternativ til Fail2Ban

I stedet for at lede efter en enkelt erstatning er det en god idé at adskille detektering og reaktion. CrowdSec behandler konfigurerbare logkilder ved hjælp af parsere og scenarier for at analysere hændelsesforløb og træffe beslutninger. Security Engine gennemfører ikke selv disse beslutninger; til dette formål skal en separat Remediation Component være tilsluttet og funktionsdygtig.

Denne opdeling er velegnet, når den samme detektion skal fungere på forskellige steder. En firewall-komponent kan træffe beslutninger vedrørende netværksforbindelser, mens komponenter til webservere eller reverse proxyer håndterer HTTP-trafikken. Dette medfører dog også øgede krav: Logindsamling, parsere, lokale API'er, tilladelser og den konkrete håndhævelse skal planlægges som en sammenhængende kæde.

SSHGuard er beregnet til mere specifikt afgrænsede tilfælde. Værktøjet samler systemlogfiler og kan blokere kilder, der gentagne gange vækker mistanke, via firewall-backends; dets formål omfatter brute-force-angreb på SSH og andre tjenester. Det er derfor mere velegnet til at håndtere forståelige autentificeringsfejl end til en omfattende analyse af webforespørgsler.

Native nftables-hastighedsbegrænsning anvender en anden tilgang. Dynamiske sæt og målere kan begrænse antallet af nye TCP-forbindelser pr. kildeadresse og håndtere poster med tidsoverskridelse. Dette bremser hurtige forbindelsessekvenser før autentificering, kræver ingen logparser og vurderer samtidig ikke, om et login mislykkedes, eller om en HTTP-anmodning var ondsindet.

Regelretningen er her vigtig: nftables skelner mellem regler, der accepterer trafik op til en bestemt hastighed, og udtryk med over, der frasorterer trafik, der overstiger en bestemt hastighed. En grænseværdi skal derfor passe til tjenesten, den forventede brugeradfærd og fælles anvendte kildeadresser. Det er ikke en pålidelig klassificering af alle mistænkelige identiteter.

For en enkelt server med få, veldefinerede tjenester kan en enkel logbeskyttelse eller en moderat forbindelsesbegrænsning være tilstrækkelig. Flere værter, centrale logkilder eller behovet for forskellige håndhævelsespunkter taler snarere for en modulær arkitektur. Ingen af disse muligheder erstatter sikkerhedsopdateringer, stærk autentificering eller restriktiv netværksadgang.

Det rette alternativ til Fail2Ban afhænger således af, hvilke signaler der er tilgængelige, og hvor der skal reageres. Logmønstre er nyttige ved gentagne loginfejl; pakkereglene begrænser forbindelsesfrekvenserne. Begge metoder registrerer kun det, som deres datakilde og regler er indrettet til.

Adskil firewall og HTTP-beskyttelse klart fra hinanden

En Nginx-server eller reverse proxy forbinder to beskyttelseslag, som ikke bør forveksles. En firewall-blokering afviser eller tillader forbindelser fra en kildeadresse og kan dermed påvirke både SSH, SMTP og webadgang. Den vurderer dog ikke enkelte HTTP-stier, headere eller indholdet af anmodninger; disse oplysninger ligger på applikationsniveau.

Hos CrowdSec er Identificering og håndhævelse adskilte opgaver. Log Processor analyserer logdata og HTTP-anmodninger fra kompatible webservere. AppSec er en del af denne Log Processor og filtrerer sådanne HTTP-anmodninger. Remediation Components har derimod til opgave at gennemføre beslutninger på det valgte niveau, f.eks. på en firewall, en webserver eller en reverse proxy.

En ren firewall-komponent er derfor ikke tilstrækkelig til at beskytte mod SQL-injection, cross-site-scripting eller andet skadeligt indhold i forespørgsler. Der kræves en kompatibel webserverforbindelse samt en passende AppSec-konfiguration med de rette regler. Afhjælpningen skal holdes adskilt herfra rent fagligt: Den implementerer beslutninger på det valgte håndhævelsespunkt.

Begge niveauer kan være nyttige side om side. En netværksdækkende blokering begrænser yderligere trafik fra en kilde, mens en HTTP-kontrol vurderer og filtrerer webservere, der er kompatible med AppSec-forespørgsler. Det betyder ikke, at en IP-blokering automatisk beskytter mod SQL-injection eller cross-site-scripting: Uden kontrol af forespørgslerne genkender firewallen hverken parametre eller brugerdata.

Omvendt har også AppSec- og IP-baserede foranstaltninger deres begrænsninger. Langsomme forsøg under tærskelværdier, mange skiftende kildeadresser eller legitime brugere bag den samme NAT-adresse gør det vanskeligt at træffe beslutninger baseret på kilde-IP. Reglerne bør derfor tage højde for falske alarmer og ikke generelt betragte adgang til normale formularer, API'er og automatiserede integrationer som et angreb.

Til planlægningen er det nyttigt med en kort oversigt: Den Firewall-niveau styrer netværkstrafikken ud fra adresser, porte og forbindelsesegenskaber. AppSec behandler og filtrerer HTTP-anmodninger fra kompatible webservere som en del af logprocessoren. Remediation Components gennemfører beslutninger målrettet på et valgt niveau.

Et offentligt websystem kræver desuden en klar adskillelse af ansvarsområderne. Reverse-proxyen må kun have adgang til de nødvendige backend-systemer, og administrative endepunkter bør ikke forblive offentligt tilgængelige alene på grund af et forudgående filter. På denne måde supplerer netværkssegmentering, sikker login og målrettede regler hinanden, uden at man tillægger en enkelt spærreteknik større beskyttelseseffekt, end den kan yde.

Sammenligning af typiske Linux-servere

Man kan ikke på fornuftig vis vælge et alternativ til Fail2Ban alene ud fra antallet af mulige spærringer. Det afgørende er de signaler, der analyseres, og hvor de håndhæves. CrowdSec adskiller sin sikkerhedsmotor fra den komponent, der gennemfører beslutninger på firewall, proxy eller webserver. SSHGuard analyserer derimod systemlogfiler for gentagne angrebsforsøg; nftables kan begrænse nye forbindelser direkte i pakkestien.

Tabellen viser ikke nogen rangorden. For en enkelt tjeneste med tydelige mislykkede loginforsøg er en enkel loganalyse noget andet end en begrænsning mod forbindelsesstorm. For en reverse proxy spiller det desuden en rolle, om HTTP-anmodninger skal filtreres af AppSec på en kompatibel forbindelse. Det Gennemførelsespunkt skal passe til det beskyttede objekt: En firewall-regel vurderer ikke indholdet af anmodninger, mens Remediation Components gennemfører beslutninger på det valgte niveau.

Selv central administration er ikke et mål i sig selv. Den kan standardisere beslutninger og loganalyse på tværs af flere værter, men kræver en robust løsning for adgang og nedbrudshåndtering. For en lille, isoleret server kan denne ekstra arkitektur under visse omstændigheder medføre mere vedligeholdelsesarbejde end sikkerhedsgevinst. Omvendt kan identiske tjenester på flere værter drage fordel af en bevidst planlagt central CrowdSec-installation.

Kontroller og klassificer konfigurationen omhyggeligt

Inden aktivering skal det først fastslås, hvilke meddelelser der rent faktisk når frem til tjenesten. Ved en logbaseret løsning skal du kontrollere logkilden, parseren og det konkrete format for SSH-, e-mail- eller proxy-hændelser. Hos CrowdSec er det ikke nok, at der registreres aktivitet: En registreret og tilgængelig afhjælpningskomponent skal videresende beslutninger til den påtænkte firewall- eller proxy-forbindelse.

Følgende kommandoer er udelukkende til kontrolformål på et Linux-system, hvor de pågældende værktøjer muligvis allerede findes. De ændrer ikke regler og installerer ikke pakker. De hjælper med at få et overblik over de aktuelle regler, registrerede CrowdSec-komponenter og de pakkekandidater, der er tilgængelige for Debian eller Ubuntu.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

Udskriften giver endnu ingen beskyttelse. Kontroller i nftables, om den relevante input-kæde har den forventede hook og den passende standardpolitik, og om der er fastlagt regler for eksisterende forbindelser, loopback, IPv4 og IPv6 samt den faktiske serviceport. En registreret komponent kan desuden være konfigureret til det forkerte håndhævelsespunkt. Selv en synlig pakkekandidat siger intet om, hvorvidt dens version, konfiguration og parser passer til distributionen og til den pågældende tjeneste.

Tærskelværdier, spærreperioder og undtagelser bør ikke overføres uændret fra eksempler til produktionsmiljøet. Især delte NAT-adresser, mobiladgange og automatiserede opgaver kan ellers føre til falske alarmer. Til analyse af netværkshændelser og systemadfærd kan man desuden eBPF-sporing til Linux-overvågning hjælpe; det erstatter dog hverken gennemgangen af logkæden eller den faglige beslutning om en spærring.

Det rette valg til fire driftsscenarier

En enkelt VPS med SSH, der er tilgængelig på verdensplan, har et velafgrænset behov for beskyttelse. SSHGuard kan rapportere gentagne mislykkede forsøg – som kan genkendes i de relevante logfiler – til et firewall-backend. En moderat nftables-begrænsning kan yderligere dæmpe nye forbindelser, men vurderer ikke loginfejl. Begrænsede administrationsveje og stærk login har forrang; en IP-spærring forbliver et supplement.

På en mailserver møder SMTP, IMAP og Submission forskellige autentificerings- og logstier. En strømlinet, logbaseret reaktion giver kun mening, hvis de relevante meddelelser registreres fuldt ud. CrowdSec bliver en mulighed, når beslutninger eller loganalyse skal samles på tværs af flere systemer. Uden dette behov ville den centrale arkitektur være uforholdsmæssig i forhold til en klart afgrænset lokal løsning.

For Nginx eller Traefik foran en webapplikation er et værktøj, der udelukkende er orienteret mod SSH, ikke tilstrækkeligt. Her adskiller en flerstrenget sikring Netværksadgang fra HTTP-kontroller: CrowdSec AppSec er en del af Log Processoren og kan filtrere anmodninger fra kompatible webservere. Remediation Components gennemfører derimod beslutningerne på det valgte niveau, for eksempel på webserveren eller reverse proxyen. Begge opgaver skal integreres korrekt og kontrolleres hver for sig.

En lille flåde med centrale logfiler eller Kubernetes kan drage fordel af en central lokal API eller centraliserede logfiler. Det forenkler dog ikke automatisk driften: Der skal tages højde for adgangsrettigheder, grænsefladernes tilgængelighed, segmentering og nedbrud af en central komponent. Aspekter vedrørende pakkehåndtering og belastningsfordeling i større Linux-netværk behandles også i artiklen om Receive Side Scaling i Linux-servernetværk. For de få servere, der ikke kører en fælles proces, er en lokal løsning ofte mere overskuelig.

Overvågning af logiske funktioner under drift

En blokeringslogik er kun forståelig, hvis man kontrollerer tre trin hver for sig: indlæsningen af logdataene, den beslutning, der træffes på baggrund heraf, og den tekniske gennemførelse heraf. I CrowdSec læser sikkerhedsmotoren konfigurerede logkilder og genererer beslutninger ved hjælp af parsere og scenarier; selve blokeringen varetages dog af en separat afhjælpningskomponent.

Kontroller først, om de forventede meddelelser overhovedet kommer frem. For en SSH-tjeneste er mislykkede loginforsøg relevante, for en mailserver er det de respektive autentificeringsprotokoller, og for en proxy er det dens adgangs- eller sikkerhedslogfiler. Synlige hændelser alene er ikke i sig selv bevis på en effektiv beskyttelse: Først kombinationen af logindgang, genkendt sekvens, beslutning og en effektiv regel muliggør en pålidelig diagnose.

Kontroller derefter beslutningerne og den registrerede komponent hver for sig. Hvis CrowdSec registrerer mistænkelige hændelser, men der ikke er tilsluttet eller fungerer nogen afhjælpningskomponent, har beslutningerne ingen konsekvenser. Den officielle fejldokumentation angiver netop dette mønster som årsagen til, at sikkerhedsmotoren kører, men at der ikke finder nogen blokering sted. Registrering er ikke det samme som en spærring.

Webbeskyttelsen indebærer en yderligere kontrol. AppSec er en del af logprocessoren og filtrerer HTTP-anmodninger fra kompatible webservere. Remediation Components gennemfører beslutninger på det valgte niveau, f.eks. på webserveren eller reverse proxyen. Under drift bør det derfor være muligt at se, om en afvisning stammer fra HTTP-kontrollen eller fra en allerede gennemført beslutning, så fejl og falske alarmer kan undersøges målrettet.

Falske alarmer har særligt alvorlige konsekvenser, når mange berettigede personer bruger den samme offentlige adresse. NAT-gateways, mobilnetværk og CI-systemer kan samle adskillige legitime loginforsøg under én kilde-IP-adresse. Vælg derfor tærskelværdier, spærreperioder og undtagelser ud fra reelle adgangsveje, og sørg for, at beslutninger sammen med årsag og varighed er gennemsigtige, i stedet for at betragte en lang spærreliste som en succes.

Test ændringerne først med anonymiserede historiske logfiler eller i et testmiljø. På den måde kan man kontrollere, om parserne registrerer de forventede mønstre, og om afhjælpningen reagerer som forventet, uden at det udgør en risiko for administratoradgangene. SSHGuard behandler systemlogfiler og kan kommunikere med forskellige firewall-backends; derfor skal logkilden og backenden betragtes samlet i det installerede miljø.

En kontrolleret test kan ikke erstatte en angrebstest på produktionssystemet. Dokumenter forventede hændelser, observerede beslutninger og den deraf følgende regelvirkning; fjern derefter testdata, eller lad tidsbegrænsede poster udløbe som normalt. På den måde forbliver beskyttelseseffekten og eventuelle følgeskader kontrollerbare, uden at der bevidst udløses reelle spærringer mod produktive brugere.

Fejlfinding i logfiler og regler

Start altid fejlsøgningen ved logkilden, og arbejd dig derefter videre frem til håndhævelsen. Hvis der mangler relevante meddelelser, kan hverken en logparser, en scenarie- eller en spærrelogik reagere pålideligt. Kontroller derfor tjenesten, loglæseren og det faktiske format, før du ændrer tærskelværdier eller mistænker firewall-regler.

I CrowdSec er fejlbildet entydigt, når hændelser eller beslutninger er synlige, men adgang fortsat er mulig: En beslutning håndhæves ikke automatisk af motoren. Kontroller, om en passende afhjælpningskomponent er registreret, tilgængelig og faktisk forbundet til firewallen, webserveren eller proxyen. Uden denne komponent anvendes der ingen blokeringsregel.

Med SSHGuard ligger årsagen ofte her. Værktøjet samler systemlogfiler, men en uegnet loglæser eller et serviceformat, der afviger fra det forventede mønster, giver ingen brugbare resultater. Eksempelkonfigurationen i repositoriet viser mulige indtastninger og indstillinger, men stammer fra udviklingsgrenen; sammenlign dem med pakkedokumentationen og den installerede version, i stedet for at overtage dem uændret.

I nftables skal du desuden kontrollere, om reglen i den relevante kæde er placeret ved den forventede hook, omfatter den faktiske serviceport og gælder for de nødvendige protokolfamilier. Eksemplet på regelsættet adskiller IPv4 og IPv6 ved hjælp af separate kæder og tillader etablerede samt tilknyttede forbindelser og loopback-trafik, før portene frigives. En beskyttelse, der udelukkende er formuleret til IPv4, dækker ikke IPv6; ligeledes kan en for snæver hastighedsbegrænsning påvirke berettigede parallelle forbindelser.

En meter begrænser nye forbindelser ud fra en defineret hastighed pr. kilde og kan administrere dynamiske sæt-poster med timeout. Dette tager dog ikke højde for mislykkede loginforsøg. Hvis et angreb holder sig under denne hastighed, er et manglende hit derfor ikke nødvendigvis en fejl i reglen, men kan være en begrænsning ved den valgte tilgang. Krog, kæde og målepunkt skal stemme overens med den forventede virkning.

Foretag ændringer én ad gangen, og kontroller efter hvert trin igen logindgangen, beslutningen og gennemførelsen. Sørg for at have en uafhængig nødadgang, f.eks. via konsol, bastionhost eller et separat administrationsnetværk, inden du foretager justeringer af firewallen. Dette forhindrer, at en forkert placeret regel eller en fejlagtig IPv6-tilføjelse afskærer den eneste adgang til serveren.

Beslutning baseret på risiko og omkostninger

Det rette alternativ til Fail2Ban afhænger af det eksponerede angrebsareal, ikke af en generel rangliste. Afklar, hvilke tjenester der er offentligt tilgængelige, om de behandler log-ins, hvilke logfiler der er tilgængelige pålideligt, og hvem der varigt administrerer konfigurationen. En databasetjeneste uden offentlig tilgængelighed har ikke brug for en internet-blokkeringsliste; dens netværksadgang forbliver den vigtigste sikkerhedsbeslutning.

For en overskuelig enkeltstående server med gentagne SSH- eller e-mail-loginfejl kan SSHGuard være en enkel, logbaseret løsning. Projektet er rettet mod beskyttelse mod brute-force-angreb mod SSH og andre tjenester og benytter til dette formål systemlogfiler samt firewall-backends. Den konkrete logdækning og spærreparametrene skal dog passe til den installerede distribution og tjenesteformatet.

Hvis man især ønsker at dæmpe hurtige nye forbindelser, er en moderat nftables-hastighedsbegrænsning et direkte supplement. Meter kan begrænse antallet af forbindelser pr. kildeadresse; regler med over Afviser trafik, der overstiger den fastsatte grænse. Dette sker før en login-forsøg, men giver ingen semantisk information om, hvorvidt et login mislykkedes, eller om en HTTP-anmodning var ondsindet.

CrowdSec er velegnet, når loganalyse og håndhævelse skal koordineres på flere niveauer eller på flere værter. Dens arkitektur adskiller engine- og afhjælpningskomponenterne; distribuerede varianter med en central lokal API eller centraliserede logfiler er mulige. Denne fordel medfører yderligere krav til tilladelser, tilgængelighed, segmentering og en plan for nedbrud. Driftsdygtighed er derfor et udvælgelseskriterium ud over funktionsomfanget.

I forbindelse med offentlige webapplikationer er en firewall-blokering ikke tilstrækkelig til at vurdere individuelle HTTP-anmodninger. Til dette formål kræves der en kompatibel AppSec-integration med passende regler. AppSec er en del af Log Processor og filtrerer HTTP-anmodninger fra kompatible webservere; Remediation Components gennemfører beslutninger på det valgte håndhævelsespunkt. Det afgørende er, om beskyttelsesbehovet vedrører forbindelser, autentificeringshændelser eller HTTP-indhold.

IP-baserede foranstaltninger har fortsat begrænsninger: Botnet spreder forsøgene over mange kilder, langsomme angreb kan holde sig under en bestemt frekvens, og delte adresser rammer uskyldige brugere, hvis de blokeres. De reducerer automatiseret støj, men er ikke en erstatning for rettidige sikkerhedsopdateringer, begrænsede administratorrettigheder og stærk autentificering. Især ved SSH har nøglebaseret login og begrænset tilgængelighed forrang frem for stadig mere aggressive blokeringsgrænser.