CrowdSec vs. Fail2Ban: differenze nell'uso pratico

Comprendere correttamente CrowdSec e Fail2Ban

La scelta giusta non dipende da quale strumento sia considerato più moderno, ma dal server, dai dati di log e dal punto di applicazione desiderato. Per un singolo servizio SSH con messaggi di errore chiari, Fail2Ban può rivelarsi una soluzione molto diretta. CrowdSec diventa interessante quando occorre analizzare e proteggere congiuntamente più fonti di log, diversi livelli di protezione o sistemi distribuiti.

Entrambe le soluzioni servono a Rilevamento degli attacchi basato su log: Analizzano eventi rilevanti per la sicurezza, come i tentativi di accesso falliti, li classificano in base a uno schema e possono provvedere al blocco di un indirizzo IP. A tal fine, Fail2Ban combina filtri e azioni in "jail". CrowdSec elabora i dati raccolti tramite il proprio motore di sicurezza e genera decisioni, la cui attuazione viene gestita da un componente di rimedio separato.

Ciò che conta è ciò che viene effettivamente registrato. Senza timestamp, un indirizzo IP di origine utilizzabile e una fonte di log adeguata, nessuno degli strumenti è in grado di attribuire un attacco in modo affidabile. Inoltre, un blocco offre protezione solo laddove è tecnicamente applicabile: una regola del firewall locale non è automaticamente efficace se il traffico dati passa prima attraverso un proxy inverso esterno o un bilanciatore di carico.

Come Prevenzione delle intrusioni Entrambi gli strumenti integrano un’architettura di sicurezza, ma non la sostituiscono. Gli aggiornamenti di sicurezza risolvono le vulnerabilità note, mentre un sistema di autenticazione forte e, se possibile, a più livelli limita l’uso improprio degli account; regole di base restrittive del firewall riducono i servizi accessibili. I backup limitano i danni a seguito di un incidente, mentre il monitoraggio continuo dei log rende visibili anche i problemi che non attivano alcun blocco.

La questione pratica è quindi la seguente: quali modelli devono essere riconosciuti, in quale punto deve avvenire la reazione e chi si occupa della gestione delle regole, delle eccezioni e dei log? Solo allora sarà possibile decidere in modo fondato se sia sufficiente una configurazione locale della jail di dimensioni contenute oppure se i componenti separati di CrowdSec apportino un valore aggiunto tangibile all’infrastruttura.

Come Fail2Ban associa le “jail” alle azioni

Fail2Ban gestisce il rilevamento e la risposta in Carceri. Con SSH, ad esempio, una “jail” legge i log di autenticazione o il registro di sistema. Un filtro cerca in essi i tentativi di accesso falliti provenienti da un determinato indirizzo IP di origine. Se, entro l’intervallo di tempo configurato, tale indirizzo supera il numero consentito di tentativi falliti, Fail2Ban considera il riscontro come un caso da bloccare.

L'azione successiva determina la reazione. Spesso integra una regola nel firewall locale, ma sono possibili anche altre azioni configurate. In questo modo la catena è tracciabile: la fonte di log fornisce le righe, il filtro riconosce gli eventi rilevanti, la jail li conta e l'azione attua la contromisura prevista. Ciò facilita la ricerca degli errori, a condizione che il formato del log e il filtro siano compatibili.

Una "jail" utilizza un solo filtro, ma può eseguire più azioni. Ad esempio, lo stesso caso di blocco SSH rilevato può attivare un'azione del firewall e, inoltre, generare una notifica. La presenza di più azioni rende la reazione più flessibile, ma non modifica la base del rilevamento: tutte dipendono dallo stesso filtro e dalla sua interpretazione delle righe di log.

Particolare attenzione va prestata ai testi scritti di proprio pugno Filtro Regex. La documentazione sui filtri disponibile è espressamente una guida allo sviluppo per Fail2Ban 0.9.0.dev e non costituisce una prova di funzionalità per una specifica versione stabile del pacchetto. Le vostre indicazioni generali rimangono utili per lo sviluppo dei filtri: è necessario coprire le varianti reali dei formati di log, mentre i modelli non devono essere troppo generici. I nuovi filtri dovrebbero quindi essere testati inizialmente con righe di esempio anonimizzate, prima di attivare eventuali blocchi.

Le modifiche locali vanno generalmente inserite in file con estensione .local, non in quelli consegnati .conf-file. In questo modo, i valori personalizzati relativi ai percorsi dei log, alle reti consentite o alle azioni rimangono più facilmente tracciabili in caso di aggiornamenti dei pacchetti e non vengono semplicemente sovrascritti. Prima del rollout, è inoltre opportuno verificare che la fonte di log selezionata esista effettivamente e contenga gli eventi previsti.

Il percorso di CrowdSec: dal log al blocco

CrowdSec separa in modo più netto il rilevamento e l’applicazione in singoli componenti. Innanzitutto, le fonti di acquisizione definiscono quali log o flussi di eventi vengono importati. I parser normalizzano questi dati; gli scenari valutano poi i modelli e i comportamenti. In caso di corrispondenza con un modello, viene generato un avviso. L’API locale può quindi generare una decisione sulla base dei profili configurati, ad esempio un blocco temporaneo dell’IP.

Un breve esempio illustra il processo: gli errori di autenticazione di un servizio vengono inoltrati all’Engine tramite l’Acquisition. I parser riconoscono campi quali l’ora, il servizio e l’IP di origine; uno scenario valuta i tentativi falliti ripetuti. L'allerta generata viene inoltrata all'API locale, che può creare una decisione utilizzando un profilo adeguato. Solo un sistema collegato Componente di bonifica applica questa decisione nel punto di protezione previsto.

Questo componente è tradizionalmente noto anche come “Bouncer”. A seconda della variante, può applicare le decisioni, ad esempio, su un firewall, un proxy inverso o un server web. Il Security Engine, da solo, rileva gli incidenti e gestisce gli avvisi e le decisioni tramite l’API locale, ma non blocca il traffico dati. Senza una Remediation Component correttamente collegata, una decisione generata rimane un’informazione senza alcun blocco attivo della rete o dell’applicazione.

In pratica, questa separazione consente di distribuire il rilevamento e il blocco su diversi punti dell’infrastruttura. Tuttavia, aumenta la complessità operativa: la fonte dei log, la connessione API locale, le autorizzazioni e l’assegnazione del Bouncer devono essere coordinate tra loro. Soprattutto in presenza di più servizi, è necessario verificare che il Remediation Component si trovi effettivamente a monte del servizio di cui deve bloccare gli accessi in base a una decisione.

Da distinguere dai risultati relativi a scenari locali è l’opzione Lista dei blocchi della community. In caso di partecipazione volontaria, è possibile fornire segnali e ottenere decisioni vagliate relative ad aggressori già noti. Si tratta di un’ulteriore fonte preventiva, ma non sostituisce il rilevamento locale né garantisce l’individuazione di aggressori nuovi o poco evidenti. L’origine di una decisione di blocco dovrebbe quindi rimanere tracciabile durante il funzionamento.

Confrontare gli strumenti in base al caso d'uso

La scelta tra CrowdSec e Fail2Ban parte dal punto di vista della protezione, non da un giudizio generale sulla qualità. Fail2Ban analizza le righe di log tramite filtri e le associa ad azioni all’interno delle “jail”. CrowdSec elabora le fonti di log tramite parser e scenari per generare avvisi; l’API locale può quindi utilizzare i profili per generare decisioni che vengono applicate da componenti di remediation separati. Entrambi dipendono da eventi registrati correttamente.

La tabella non è una classifica. Per pochi modelli di log ben compresi, spesso è più facile verificare una “jail” locale: la fonte del log, il filtro e l’azione del firewall sono vicini tra loro. Non appena sono coinvolte più fonti, sistemi a monte o diversi punti di applicazione, in CrowdSec può essere opportuno separare il rilevamento dalla risposta. Ciò richiede tuttavia anche una gestione trasparente delle relazioni tra i componenti.

Per quanto riguarda il criterio della protezione web, il livello tecnico è determinante. Un CrowdSec Firewall-Bouncer applica le decisioni a livello di rete, ma non analizza il contenuto HTTP. In una configurazione AppSec supportata, un Bouncer compatibile inoltra le richieste HTTP al componente AppSec del Security Engine, dove vengono valutate le regole AppSec. Questo controllo integra lo sviluppo sicuro e gli aggiornamenti tempestivi, anziché limitarsi a correggere le vulnerabilità note.

Caso pratico relativo a un singolo VPS con SSH

Su un piccolo VPS Linux con SSH e uno stack web di dimensioni contenute, Fail2Ban rappresenta spesso una scelta facilmente gestibile. Per prima cosa, verifica che i tentativi falliti di accesso SSH, con timestamp e IP di origine, vengano registrati in modo affidabile nel log o nel journal previsto. Senza questi dati, una jail non è in grado né di contare in modo affidabile i tentativi falliti né di trasmettere l'indirizzo corretto a un'azione.

Successivamente, scegli una SSH-Jail adeguata e verifica che i filtri, le fasce orarie, il numero massimo di tentativi falliti consentiti e la durata del blocco corrispondano alle tue effettive esigenze di accesso. Una jail associa un filtro a una o più azioni. In questo modo è possibile, ad esempio, delegare il blocco al firewall locale senza duplicare la logica di rilevamento. Per un singolo host, questa associazione rende il processo generalmente trasparente.

Le reti amministrative, gli accessi di emergenza e i sistemi di monitoraggio richiedono eccezioni definite in modo mirato. Queste dovrebbero essere strettamente limitate e non esentare in modo generalizzato le grandi reti dei provider. Verifica inoltre, prima dell’implementazione, quali regole del firewall vengono effettivamente create dall’operazione e se IPv4 e IPv6 sono compatibili con l’architettura del server. Un avvio controllato con monitoraggio dei log è più sicuro di un blocco immediato e di lunga durata.

Proprie Filtro Regex sono utili solo quando non esiste alcun filtro che copra quel formato di log specifico. La guida disponibile per lo sviluppo dei filtri è contrassegnata come documentazione relativa a Fail2Ban 0.9.0.dev e quindi non fa riferimento a una versione stabile come la 1.1.1. Le sue indicazioni di sviluppo sono comunque utili: verifica i nuovi modelli con righe di esempio reali ma anonimizzate e con righe simili ma legittime. Lo strumento di test fail2ban-regex serve a convalidare il filtro; non modifica alcun blocco di produzione.

Le impostazioni locali vanno inserite in .local-file, non quelli forniti .conf-file. In questo modo, le modifiche apportate durante gli aggiornamenti dei pacchetti rimangono tracciabili e non vengono sovrascritte accidentalmente. Dopo ogni modifica, controlla separatamente la voce di log, lo stato della jail e l'azione attivata; un servizio in esecuzione da solo non costituisce ancora una catena di blocco efficace.

Proxy, IP reali dei client e protezione web

Un CDN, un bilanciatore di carico o un proxy inverso modificano l’indirizzo che il server vede. Se il server web riceve solo l’IP del proxy e lo registra come client, nel peggiore dei casi un blocco basato sui log identificherà l’intermediario comune anziché il visitatore che sta sferrando l’attacco. Prima di ogni jail, di ogni scenario e di ogni regola WAF, è quindi necessario chiarire in che modo l’IP originale del client venga trasmesso, accettato e registrato in modo affidabile.

Questa catena di fiducia non deve semplicemente accettare qualsiasi header in entrata. Solo gli indirizzi proxy noti devono essere autorizzati a fornire un indirizzo inoltrato; in caso contrario, i client esterni potrebbero falsificare l’identità su cui si basano il riconoscimento e il blocco. Verifica, utilizzando estratti di log anonimizzati, se l’applicazione e il log di accesso mostrano lo stesso IP del client. Documenta inoltre il trasferimento delle intestazioni tra Edge e Origin. Solo dopo aver verificato l’IP del client è possibile interpretare in modo sensato una reazione a eventi HTTP sospetti.

A Blocco IP limita le connessioni a livello di firewall prima che raggiungano l’applicazione, ma non verifica il contenuto delle richieste. In una configurazione CrowdSec AppSec supportata, un Bouncer compatibile inoltra le richieste HTTP al componente AppSec del Security Engine; dove vengono verificate le regole AppSec pertinenti. Un Bouncer puramente firewall, invece, applica le decisioni a livello di rete e non effettua alcuna verifica HTTP. La scelta della variante più adatta dipende dal punto di ingresso effettivo del traffico e dai componenti utilizzati.

Il rilevamento basato sui log rimane inoltre un processo a posteriori: prima deve verificarsi un evento, che deve essere correttamente registrato e riconosciuto come modello. Non impedisce un singolo exploit riuscito senza un evento successivo evidente, né sostituisce le patch e l’autenticazione forte. I componenti a monte devono quindi integrarsi nell'architettura di sicurezza complessiva con i loro inoltri affidabili, i log e i punti di protezione.

In pratica, ciò significa: decidere innanzitutto se proteggere l’accesso alla rete, la richiesta HTTP o entrambi i livelli. Documentare quindi il percorso dall’indirizzo pubblico, passando per il proxy, fino alla voce di log e testare i blocchi utilizzando un indirizzo di prova autorizzato. In questo modo si evita che una soluzione apparentemente funzionante Prevenzione delle intrusioni colpisce solo il componente infrastrutturale errato.

Proteggere in modo controllato più server

Non appena sono coinvolti più host, container o log raccolti a livello centrale, la separazione tra rilevamento e applicazione delle misure correttive diventa pratica con CrowdSec. Il motore di sicurezza è in grado di analizzare gli eventi provenienti da fonti definite, mentre i componenti di correzione appropriati attuano le decisioni nei punti protetti di riferimento. A tal fine, CrowdSec documenta anche le implementazioni distribuite e l’integrazione accanto alle pipeline di log centralizzate.

Ciò non riduce automaticamente i costi operativi. Innanzitutto, per ogni fonte di log deve essere chiaro a quale servizio e a quale cliente sia assegnata. Successivamente, ogni bouncer necessita di una connessione chiaramente delimitata all’API locale e di una propria chiave di accesso. Un bouncer con proxy inverso, ad esempio, non protegge necessariamente un servizio SSH accessibile separatamente; il Assegnazione dei buttafuori deve seguire i percorsi effettivi dei dati.

Per il funzionamento, il monitoraggio deve quindi includere la gestione dei token, l’accessibilità dell’API, i log di attività e di errore, nonché la verifica dell’efficacia del blocco. Una decisione è solo un risultato di rilevamento finché il componente previsto non la recupera e la applica. In caso di modifiche ai container, ai proxy o alle regole del firewall, è opportuno verificare nuovamente questa catena, affinché un rilevamento funzionante non passi inosservato senza una reazione efficace.

Se esistono già catene e regole personalizzate, il Firewall-Bouncer può, nel Modalità "solo impostazione" gestire esclusivamente set creati in precedenza. La responsabilità delle regole e delle catene rimane quindi volutamente a carico dell’amministratore. Ciò si adatta a modelli di firewall controllati e ai requisiti di conformità, ma richiede una buona comprensione dell’ordine delle regole esistenti e non rappresenta una semplificazione per i principianti.

Verificare sistematicamente gli errori tipici

In assenza di un blocco, seguire una sequenza di controllo prestabilita è più utile di un cambio affrettato dell’utensile. Innanzitutto occorre verificare se l’evento atteso sia effettivamente pervenuto con timestamp plausibili. Successivamente, è necessario accertarsi che l’indirizzo registrato corrisponda effettivamente all’IP del client. Solo allora è possibile verificare in modo sensato se il filtro o lo scenario riconoscono il modello e se ne deriva una decisione di blocco.

In Fail2Ban, alla registrazione nel log seguono il controllo della “jail”, del filtro e il conteggio dei risultati. Una “jail” associa un filtro a una o più azioni; nel caso di percorsi di log basati su file, all’avvio vengono presi in considerazione solo i file già esistenti che corrispondono al modello Glob. Per i journal di systemd, è necessario verificare separatamente il backend e i diritti di accesso. Una «jail» apparentemente corretta non offre protezione se non legge la fonte effettiva.

Le espressioni regolari personalizzate richiedono particolare cautela. La guida ai filtri disponibile è contrassegnata come documentazione di sviluppo per Fail2Ban 0.9.0.dev e non deve essere interpretata come riferimento valido per la versione 1.1.1 di Fail2Ban. Per lo sviluppo di filtri personalizzati, tuttavia, la sua raccomandazione è utile: verificare innanzitutto i modelli con righe di esempio anonimizzate e rappresentative, nonché con righe volutamente non corrispondenti. In questo modo è possibile individuare le varianti del formato di log e possibili errori di classificazione prima di un blocco in produzione.

In CrowdSec, in caso di corrispondenza con uno scenario, occorre verificare anche l’intera catena di applicazione: se viene generato un allarme, l’API locale è in grado di generare una decisione sulla base di un profilo e questa raggiunge il componente di correzione previsto? Senza un Bouncer correttamente collegato, la decisione rimane senza un blocco attivo. Successivamente, è necessario verificare l’efficacia del firewall o del proxy nel punto di ingresso appropriato, senza bloccarsi l’accesso amministrativo.

Garantire il funzionamento a lungo termine della soluzione più adatta

Fail2Ban è spesso adatto a un singolo server con modelli di log chiari e locali, come ad esempio ripetuti tentativi falliti di accesso SSH. Le sue “jail”, i filtri e le azioni possono essere riferiti direttamente a un servizio ben definito. CrowdSec diventa più interessante quando occorre coordinare più fonti di log, diversi punti di applicazione delle regole o la protezione web con un componente adeguato. Ciò che conta è il percorso tracciabile dei dati, non un giudizio generico sullo strumento più moderno.

Entrambe le soluzioni richiedono un processo di modifica ben definito: assegnare una versione alle configurazioni, verificare inizialmente i nuovi filtri o scenari rispetto a esempi di log noti e monitorare i blocchi. Gli aggiornamenti meritano la stessa attenzione. Fail2Ban 1.1.1 è stato rilasciato il 15 agosto 2026. Prima di un aggiornamento, le personalizzazioni locali e le azioni del firewall effettivamente implementate dovrebbero essere allineate con l’ambiente di destinazione.

Prevenzione delle intrusioni integra le misure di sicurezza di base, ma non le sostituisce: aggiornamenti tempestivi, autenticazione forte e, se possibile, a più livelli, regole restrittive del firewall, backup e monitoraggio dei log rimangono indispensabili. Soprattutto negli ambienti di hosting, è importante mantenere aggiornato anche il runtime delle applicazioni. Il contributo su CloudLinux Alt-PHP e i suoi aspetti relativi alla sicurezza dimostra perché disporre di versioni di runtime separate e ben gestite sia parte integrante di un modello operativo solido.

Per quanto riguarda i servizi web, nella documentazione operativa deve essere incluso anche il percorso completo dal client all’origin, passando per il CDN o il reverse proxy. Le modifiche ai protocolli e ai percorsi di distribuzione possono influire su quale componente accetta le connessioni e su quale indirizzo compare nel log. L’articolo su HTTP/2 Server Push nell'hosting illustra, con un esempio, come il browser, il CDN e il server web interagiscano durante la distribuzione. Per quanto riguarda la logica di blocco, rimane comunque fondamentale che l’IP del client, trasmesso in modo affidabile, sia disponibile nel punto di protezione corretto.

La scelta a lungo termine rimane soggetta a verifica: se cambiano i formati dei log, i percorsi proxy, i servizi o il numero di server, un approccio che prima era adeguato potrebbe presentare delle lacune. Per questo motivo, è importante definire quali eventi devono essere rilevati, dove vengono applicate le decisioni e chi autorizza le eccezioni. Questi Disciplina sul lavoro trasforma il blocco di un indirizzo IP in una misura di protezione controllabile, anziché in una modifica del firewall effettuata senza supervisione.