Alternativ till Fail2Ban för moderna Linux-servrar

Kontrollera attackytan innan verktygsvalet

En Alternativ till Fail2Ban kan endast väljas på ett meningsfullt sätt när de tjänster som faktiskt är tillgängliga har fastställts. SSH, SMTP, IMAP och en HTTP-applikation har olika inloggningsprocesser, loggkällor och skadebilder. En offentligt tillgänglig databastjänst bör däremot i regel inte behöva skyddas av en internetblockeringslista: dess nätverksåtkomst bör begränsas till nödvändiga applikationer och betrodda nätverk.

Vid administrativa tillskott har Åtkomstbegränsning och stark autentisering har företräde framför automatiserade IP-blockeringar. En SSH-tjänst bakom ett VPN, en bastionhost eller fasta administrationsnätverk erbjuder angripare en betydligt mindre yta än en port som är öppen för hela världen. Aktuella säkerhetsuppdateringar, separata privilegierade konton och noggrant avvägda lösenordsinloggningar minskar därvid riskerna, vilket en blockeringslista ensam inte kan eliminera.

Om SSH medvetet är tillgängligt för allmänheten kan begränsningar och loggbaserade spärrar dämpa upprepade inloggningsförsök. De förblir dock ett komplement: personer bakom en gemensam NAT-gateway kan använda samma källadress, medan distribuerade attacker utnyttjar många adresser. För e-posttjänster spelar det dessutom roll vilka protokoll som faktiskt är öppna för externa användare och vilka felaktiga inloggningsförsök som loggas.

När det gäller webbapplikationer måste man skilja mellan tillgängligheten till den omvända proxyn och de interna backend-tjänsterna. En offentlig Nginx-instans kan ta emot HTTP-förfrågningar utan att databasen, cachen eller administrationsgränssnittet behöver vara tillgängliga från internet. Det Bevarandemål Det handlar därför inte generellt om att „blockera IP-adresser“, utan om att för varje tjänst begränsa obehörig åtkomst, upprätthålla legitim användning och undvika onödiga tillstånd.

Innan varje ändring bör de ansvariga kartlägga vilka åtkomstvägar som behövs i en nödsituation och vilka källnät som har regelbunden åtkomst. Denna kartläggning förhindrar att en alltför snäv brandväggsregel blockerar den egna administratörsåtkomsten eller automatiserat underhåll. Först därefter kan man avgöra om logganalys, anslutningsbegränsning eller ett flerstegskoncept är lämpligt.

En spärr ger dessutom inget svar på frågan om en tjänst överhuvudtaget måste vara offentlig. Den som vänder på denna ordning hanterar iögonfallande kopplingar, trots att den grundläggande exponeringen förblir oförändrad. Särskilt när det gäller sällan använda administratörsgränssnitt är en privat åtkomstväg ofta effektivare och enklare att hantera än allt mer komplexa identifieringsregler.

Fyra metoder istället för ett alternativ till Fail2Ban

I stället för att leta efter en enda ersättning lönar det sig att skilja på identifiering och reaktion. CrowdSec bearbetar konfigurerbara loggkällor med hjälp av parsare och scenarier för att utvärdera händelseförlopp och generera beslut. Säkerhetsmotorn verkställer inte dessa beslut själv; för detta måste en separat åtgärdskomponent vara ansluten och i drift.

Denna uppdelning är lämplig när samma identifiering ska fungera på olika ställen. En brandväggskomponent kan tillämpa beslut för nätverksanslutningar, medan komponenter för webbservrar eller omvända proxyservrar hanterar HTTP-trafiken. Detta medför dock också ökade krav: logginsamling, parsare, lokala API:er, behörigheter och den konkreta tillämpningen måste planeras som en sammanhängande kedja.

SSHGuard är avsett för mer specifika fall. Verktyget sammanställer systemloggar och kan blockera källor som upprepade gånger uppvisar misstänkt beteende via brandväggsbackends; dess syfte omfattar brute force-attacker mot SSH och andra tjänster. Det lämpar sig därför bättre för att hantera identifierbara autentiseringsfel än för en omfattande analys av webbförfrågningar.

Inhemska nftables-hastighetsbegränsning använder en annan metod. Dynamiska uppsättningar och mätare kan begränsa antalet nya TCP-anslutningar per källadress och hantera poster som har överskridit tidsgränsen. Detta bromsar snabba anslutningssekvenser före autentisering, kräver ingen loggparser och bedömer samtidigt inte om en inloggning misslyckades eller om en HTTP-förfrågan var skadlig.

Regelriktningen är viktig här: nftables skiljer mellan regler som tillåter trafik upp till en viss hastighet och uttryck med over, som avvisar trafik som överstiger en viss nivå. En gräns måste därför vara anpassad till tjänsten, det förväntade användarbeteendet och gemensamt använda källadresser. Det är ingen tillförlitlig klassificering av varje misstänkt identitet.

För en enskild server med få tydligt definierade tjänster kan ett enkelt loggskydd eller en måttlig anslutningsbegränsning räcka. Flera värdar, centrala loggkällor eller behovet av olika tillämpningspunkter talar snarare för en modulär arkitektur. Inget av dessa alternativ ersätter säkerhetsuppdateringar, stark autentisering eller restriktiva nätverksbehörigheter.

Vilket alternativ till Fail2Ban som är lämpligt beror alltså på vilka signaler som finns tillgängliga och var en reaktion ska ske. Loggmönster är användbara vid upprepade inloggningsfel; paketregler begränsar anslutningsfrekvensen. Båda metoderna upptäcker endast det som deras datakälla och regler är utformade för.

Skillnad mellan brandvägg och HTTP-skydd

En Nginx-server eller omvänd proxy kopplar samman två skyddsnivåer som inte bör förväxlas. En brandvägg blockerar eller tillåter anslutningar från en källadress och kan därmed påverka både SSH, SMTP och webbåtkomst samtidigt. Den utvärderar dock inte enskilda HTTP-sökvägar, rubriker eller innehåll i förfrågningar; denna information ligger på applikationsnivå.

Hos CrowdSec är Upptäckt och tillämpning separata uppgifter. Log Processor analyserar loggdata och HTTP-förfrågningar från kompatibla webbservrar. AppSec ingår i denna Log Processor och filtrerar sådana HTTP-förfrågningar. Remediation Components har däremot till uppgift att genomföra beslut på den valda nivån, till exempel vid en brandvägg, en webbserver eller en omvänd proxy.

För att skydda mot SQL-injektion, cross-site-scripting eller annat skadligt innehåll i förfrågningar räcker det därför inte med en ren brandväggskomponent. Det krävs en kompatibel webbserveranslutning samt en lämplig AppSec-konfiguration med passande regler. Åtgärderna måste hållas tekniskt åtskilda från detta: de genomför beslut vid den valda tillämpningspunkten.

Båda nivåerna kan vara meningsfulla att använda parallellt. En nätverksomfattande blockering minskar ytterligare trafik från en källa, medan en HTTP-kontroll bedömer och filtrerar webbservrar som är kompatibla med AppSec-förfrågningar. Det innebär inte att en IP-blockering automatiskt skyddar mot SQL-injektion eller cross-site-scripting: Utan kontroll av förfrågningarna kan brandväggen varken identifiera parametrar eller använddata.

Å andra sidan har även AppSec- och IP-baserade åtgärder sina begränsningar. Långsamma försök under tröskelvärdena, många växlande källadresser eller legitima användare bakom samma NAT-adress försvårar beslut baserade på käll-IP. Reglerna bör därför ta hänsyn till falska larm och inte generellt betrakta åtkomst till vanliga formulär, API:er och automatiserade integrationer som en attack.

För planeringen är det bra med en kort översikt: Den Brandväggsnivå styr nätverkstrafiken utifrån adresser, portar och anslutningsegenskaper. AppSec bearbetar och filtrerar HTTP-förfrågningar från kompatibla webbservrar som en del av loggprocessorn. Remediation Components genomför beslut medvetet på en vald nivå.

Ett offentligt webbsystem kräver dessutom en tydlig åtskillnad mellan ansvarsområden. Reverse proxyn får endast nå de nödvändiga backend-servrarna, och administrativa slutpunkter bör inte förbli offentligt tillgängliga enbart på grund av ett uppströmsfilter. På så sätt kompletterar nätverkssegmentering, säker inloggning och riktade regler varandra, utan att en enskild spärrteknik tillskrivs större skyddseffekt än den faktiskt kan ge.

Jämförelse av typiska Linux-servrar

Ett alternativ till Fail2Ban kan inte väljas på ett meningsfullt sätt enbart utifrån antalet möjliga spärrar. Det avgörande är vilka signaler som analyseras och var åtgärderna genomförs. CrowdSec separerar sin säkerhetsmotor från den komponent som verkställer beslut i brandväggen, proxyservern eller webbservern. SSHGuard analyserar däremot systemloggar för upprepade attackförsök; nftables kan begränsa nya anslutningar direkt i paketflödet.

Tabellen visar ingen rangordning. För en enskild tjänst med uppenbara misslyckade inloggningsförsök är en enkel logganalys något annat än en begränsning mot anslutningsstormar. För en omvänd proxy spelar det dessutom roll om HTTP-förfrågningar ska filtreras av AppSec vid en kompatibel anslutning. Det Genomförandepunkt måste passa skyddsobjektet: En brandväggsregel utvärderar inte innehållet i en begäran, medan Remediation Components genomför beslut på den valda nivån.

Inte heller är central administration ett mål i sig. Den kan standardisera beslut och logganalys över flera värddatorer, men kräver en robust strategi för åtkomst och hantering av driftstörningar. För en liten, isolerad server kan denna extra arkitektur under vissa omständigheter medföra mer underhållsarbete än vad den ger i säkerhetsvinster. Å andra sidan kan identiska tjänster på flera värddatorer dra nytta av en medvetet planerad central CrowdSec-installation.

Kontrollera och klassificera konfigurationen noggrant

Innan aktiveringen måste man först fastställa vilka meddelanden som faktiskt når tjänsten. Vid en loggbaserad lösning bör du kontrollera loggkällan, parsern och det konkreta formatet för SSH-, e-post- eller proxyhändelser. Med CrowdSec räcker det inte med att aktivitet upptäcks: en registrerad och tillgänglig avhjälpningskomponent måste vidarebefordra beslut till den avsedda brandväggs- eller proxyanslutningen.

Följande kommandon är endast avsedda för läsning på ett Linux-system där de aktuella verktygen redan kan finnas installerade. De ändrar inga regler och installerar inga paket. De hjälper dig att se den aktuella regeluppsättningen, registrerade CrowdSec-komponenter och de paketkandidater som finns tillgängliga för Debian eller Ubuntu.

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

Utmatningen ger ännu ingen skyddseffekt. Kontrollera i nftables om den relevanta ingångskedjan har den förväntade hooken och rätt standardpolicy, samt om det finns regler för befintliga anslutningar, loopback, IPv4 och IPv6 samt den faktiska tjänsteporten. En registrerad komponent kan dessutom vara konfigurerad för fel tillämpningspunkt. Även en synlig paketkandidat säger ingenting om huruvida dess version, konfiguration och parser passar distributionen och den egna tjänsten.

Tröskelvärden, spärrtider och undantag bör inte införas i produktionsmiljön utan att först ha granskats utifrån exempel. I synnerhet delade NAT-adresser, mobilanslutningar och automatiserade jobb kan annars leda till falska larm. För utvärdering av nätverkshändelser och systembeteende kan dessutom eBPF-spårning för Linux-övervakning hjälpa; det ersätter dock varken granskningen av loggkedjan eller det sakliga beslutet om en spärr.

Ett lämpligt val för fyra driftscenarier

En enskild VPS med SSH som är tillgänglig globalt har ett väl avgränsat skyddsbehov. SSHGuard kan rapportera upprepade misslyckade inloggningsförsök – som kan identifieras i relevanta loggar – till en brandväggsbackend. En måttlig nftables-begränsning kan dessutom dämpa nya anslutningar, men utvärderar inte inloggningsfel. Prioritet ges åt begränsade administrationsvägar och stark autentisering; en IP-spärr förblir ett komplement.

I en e-postserver möter SMTP, IMAP och Submission olika autentiserings- och loggningsvägar. En smidig loggbaserad respons är endast meningsfull om de relevanta meddelandena registreras fullständigt. CrowdSec blir ett alternativ när beslut eller logganalys ska samordnas över flera system. Utan detta behov skulle den centrala arkitekturen vara oproportionerlig jämfört med en tydligt avgränsad lokal lösning.

För Nginx eller Traefik framför en webbapplikation räcker det inte med ett verktyg som enbart är inriktat på SSH. Här skiljer sig en flerskiktigt skydd Nätverksåtkomst från HTTP-kontroller: CrowdSec AppSec ingår i Log Processor och kan filtrera förfrågningar från kompatibla webbservrar. Remediation Components genomför däremot åtgärder på den valda nivån, till exempel på webbservern eller den omvända proxyn. Båda uppgifterna måste integreras på lämpligt sätt och granskas separat.

En mindre miljö med centrala loggar eller Kubernetes kan dra nytta av en central lokal API eller centraliserade loggar. Detta förenklar inte automatiskt driften: behörigheter, gränssnittens tillgänglighet, segmentering och avbrott i en central komponent måste planeras in. Aspekter av paketbehandling och lastfördelning i större Linux-nätverk behandlas även i artikeln om Receive Side Scaling i Linux-servernätverk. För ett fåtal värddatorer utan gemensam driftsprocess är en lokal lösning ofta lättare att förstå.

Övervaka spärrlogiken under drift

En spärrlogik är endast begriplig om man kontrollerar tre steg separat: mottagningen av loggdata, det beslut som fattas utifrån dessa och det tekniska genomförandet av beslutet. I CrowdSec läser säkerhetsmotorn konfigurerade loggkällor och genererar beslut med hjälp av parsare och scenarier; själva blockeringen sköts dock av en separat åtgärdskomponent.

Kontrollera först om de förväntade meddelandena överhuvudtaget kommer fram. För en SSH-tjänst är misslyckade inloggningar relevanta, för en e-postserver de respektive autentiseringsprotokollen och för en proxy dess åtkomst- eller säkerhetsloggar. Synliga händelser i sig är inte tillräckliga för att bevisa någon avvisande effekt: Det är först kedjan av logginskrivning, identifierad sekvens, beslut och effektiv regel som möjliggör en tillförlitlig diagnos.

Kontrollera därefter besluten och den registrerade komponenten separat. Om CrowdSec upptäcker misstänkta händelser, men ingen avhjälpningskomponent är ansluten eller fungerar, får besluten inga konsekvenser. I den officiella feldokumentationen anges just detta mönster som orsaken till att säkerhetsmotorn är igång men att ingen blockering sker. Upptäckt innebär inte att man spärras.

När det gäller webbskydd tillkommer ytterligare en kontroll. AppSec ingår i Log Processor och filtrerar HTTP-förfrågningar från kompatibla webbservrar. Remediation Components verkställer beslut på den valda nivån, till exempel på webbservern eller i den omvända proxyn. Under drift bör det därför vara möjligt att urskilja om ett avslag härrör från HTTP-kontrollen eller från ett beslut som redan har genomförts, så att fel och falska larm kan undersökas på ett målinriktat sätt.

Falska larm får särskilt allvarliga konsekvenser när många behöriga personer använder samma offentliga adress. NAT-gateways, mobilnät och CI-system kan sammanföra ett stort antal legitima inloggningsförsök under en och samma käll-IP-adress. Välj därför tröskelvärden, spärrtider och undantag utifrån verkliga åtkomstvägar och se till att beslut, inklusive orsak och giltighetstid, är spårbara, istället för att betrakta en lång spärllista som ett framgångstecken.

Testa först ändringarna med anonymiserade historiska loggar eller i en staging-miljö. På så sätt kan man kontrollera om parsrarna identifierar de avsedda mönstren och om avhjälpningsåtgärderna reagerar på den förväntade nivån, utan att äventyra administratörsåtkomsten. SSHGuard bearbetar systemloggar och kan kommunicera med olika brandväggsbackends; därför måste loggkällan och backenden betraktas tillsammans i den installerade miljön.

En kontrollerad process ersätter inte en penetrationstest på produktionssystemet. Dokumentera förväntade händelser, observerade beslut och den resulterande regeleffekten; ta därefter bort testdata eller låt tidsbegränsade poster löpa ut enligt plan. På så sätt kan skyddseffekten och eventuella följdskador fortfarande kontrolleras utan att avsiktligt utlösa verkliga spärrar mot produktiva användare.

Felsökning av loggar och regler

Börja alltid felsökningen vid loggkällan och arbeta dig sedan vidare fram till tillämpningen. Om det saknas lämpliga meddelanden kan varken en loggparser, en scenariologik eller en spärrlogik reagera på ett tillförlitligt sätt. Kontrollera därför tjänsten, loggläsaren och det faktiska formatet innan du ändrar tröskelvärden eller misstänker att brandväggsreglerna är orsaken.

I CrowdSec är felbilden tydlig när händelser eller beslut syns, men åtkomst fortfarande är möjlig: ett beslut verkställs inte automatiskt av motorn. Kontrollera om en lämplig åtgärdskomponent är registrerad, tillgänglig och faktiskt ansluten till brandväggen, webbservern eller proxyn. Utan denna komponent tillämpas ingen blockeringsregel.

När det gäller SSHGuard ligger orsaken ofta i detta. Verktyget sammanställer systemloggar, men en olämplig loggläsare eller ett tjänsteformat som avviker från det förväntade mönstret ger inga användbara träffar. Exempelkonfigurationen i arkivet visar möjliga inställningar och alternativ, men den kommer från utvecklingsgrenen; jämför den med paketdokumentationen och den installerade versionen istället för att använda den oförändrad.

I nftables kontrollerar du dessutom om regeln i den relevanta kedjan finns vid den förväntade hooken, om den täcker den faktiska tjänsteporten och om den gäller för de protokollfamiljer som krävs. Exemplet på regelverket separerar IPv4 och IPv6 i egna kedjor och tillåter etablerade samt tillhörande anslutningar och loopback-trafik innan portarna öppnas. Ett skydd som uteslutande är utformat för IPv4 täcker inte IPv6; på samma sätt kan en alltför snäv hastighetsbegränsning påverka berättigade parallella anslutningar.

En meter begränsar nya anslutningar utifrån en definierad hastighet per källa och kan hantera dynamiska inställningar med tidsgräns. Detta tar dock inte hänsyn till misslyckade inloggningar. Om en attack ligger under denna hastighet är en utebliven träff därför inte nödvändigtvis ett fel i regeln, utan kan vara en begränsning i den valda metoden. Krok, kedja och mätpunkt måste stämma överens med den förväntade effekten.

Gör ändringarna en i taget och kontrollera loggposter, beslut och tillämpning efter varje steg. Säkerställ en oberoende nödåtkomst innan du gör ändringar i brandväggen, till exempel via konsol, bastionhost eller ett separat administrationsnätverk. Detta förhindrar att en felplacerad regel eller ett felaktigt IPv6-tillägg blockerar den enda åtkomsten till servern.

Beslut utifrån risk och arbetsinsats

Det lämpliga alternativet till Fail2Ban beror på den exponerade ytan, inte på någon allmän rangordning. Ta reda på vilka tjänster som är offentliga, om de hanterar inloggningar, vilka loggar som finns tillgängliga på ett tillförlitligt sätt och vem som sköter konfigurationen på lång sikt. En databastjänst som inte är tillgänglig från internet behöver ingen blockeringslista; dess nätverksåtkomst förblir det viktigaste säkerhetsbeslutet.

För en överskådlig enskild server med återkommande inloggningsfel via SSH eller e-post kan SSHGuard vara en smidig, loggbaserad lösning. Projektet är inriktat på att skydda mot brute force-attacker mot SSH och andra tjänster och använder för detta ändamål systemloggar samt brandväggsbackends. Den konkreta loggtäckningen och spärrparametrarna måste dock passa den installerade distributionen och tjänstens format.

Om man framför allt vill dämpa snabba nya anslutningar är en måttlig nftables-hastighetsbegränsning ett direkt komplement. Mätare kan begränsa antalet anslutningar per källadress; regler med over avvisa trafik som överstiger den fastställda gränsen. Detta sker innan en inloggning, men ger ingen semantisk information om huruvida en inloggning misslyckades eller om en HTTP-förfrågan var skadlig.

CrowdSec är ett lämpligt val när logganalys och efterlevnad ska samordnas på flera nivåer eller på flera värddatorer. Arkitekturen separerar motor- och åtgärdskomponenterna; distribuerade varianter med ett centralt lokalt API eller centraliserade loggar är möjliga. Dessa fördelar medför ytterligare krav på behörigheter, tillgänglighet, segmentering och en plan för driftstörningar. Driftsduglighet är därför ett urvalskriterium vid sidan av funktionsomfånget.

För offentliga webbapplikationer räcker det inte med en brandvägg för att utvärdera enskilda HTTP-förfrågningar. För detta krävs en kompatibel AppSec-anslutning med lämpliga regler. AppSec ingår i Log Processor och filtrerar HTTP-förfrågningar från kompatibla webbservrar; Remediation Components verkställer beslut vid den valda tillämpningspunkten. Det avgörande är om skyddsbehovet gäller anslutningar, autentiseringshändelser eller HTTP-innehåll.

IP-baserade åtgärder har sina begränsningar: Botnät sprider sina försök över många källor, långsamma attacker kan ligga under en viss tröskel, och delade adresser drabbar oskyldiga användare om de blockeras. De minskar automatiserat brus, men ersätter inte snabba säkerhetsuppdateringar, begränsad administratörsåtkomst och stark autentisering. Särskilt när det gäller SSH har nyckelbaserad inloggning och begränsad tillgänglighet företräde framför alltmer aggressiva spärrtrösklar.