Chi gestisce un server esposto su Internet conosce la stessa, monotona realtà: bot, scanner di vulnerabilità, tentativi di brute-force SSH e crawler malevoli bussano alla porta di continuo giorno e notte. La risposta classica si chiama Fail2Ban, un piccolo strumento scritto in Python che legge i log, applica regex e banna gli IP dopo un certo numero di tentativi falliti. Funziona, ma è una difesa solitaria, dove ogni server combatte la sua battaglia ignorando quella di tutti gli altri.
CrowdSec, nato in Francia nel 2020 e scritto interamente in Go, è un IDS/IPS open source che fa esattamente ciò che fa Fail2Ban, ma in più condivide in forma anonima gli indirizzi IP malevoli rilevati con una rete globale di altre installazioni. Quando il tuo server scopre un attacco, lo segnala alla Central API di CrowdSec; in cambio, riceve una blocklist comunitaria aggregata da decine di migliaia di altre macchine. Il risultato è che un IP che oggi sta attaccando un VPS in Giappone viene bloccato preventivamente sul tuo server a Roma, prima ancora che provi la sua prima richiesta.
L’idea ha già attirato oltre 150.000 istanze attive in tutto il mondo e nelle ultime release integra anche un componente AppSec capace di trasformare CrowdSec in un vero web application firewall. Vediamo come installarlo, configurarlo e perché vale la pena di provarlo al posto del vecchio Fail2Ban.
L’intelligenza collettiva applicata alla sicurezza
Gli attacchi su Internet non sono casuali, perché gli stessi indirizzi IP, intere botnet o reti compromesse, scansionano sistematicamente migliaia di server alla ricerca di vulnerabilità note. Se ogni amministratore tiene per sé l’elenco degli IP che lo hanno attaccato, sta sprecando un’informazione preziosa. Se invece tutti la condividono, ogni server beneficia in tempo reale del lavoro di tutti gli altri.
Tecnicamente parlando, CrowdSec consuma in media tra 100 e 200 MB di RAM e poca CPU, restando quindi adatto sia a un VPS economico, sia a una macchina più grossa.
La sua architettura è modulare. C’è un motore di rilevazione che analizza i log delle applicazioni da proteggere (SSH, Nginx, Apache, Traefik, Postfix, e molto altro), un database locale dove vengono memorizzate le decisioni, una API locale per far parlare i componenti tra loro, e i cosiddetti bouncer, ovvero i moduli che applicano effettivamente i blocchi a livello di firewall, reverse proxy o CDN.
Mentre Fail2Ban ti chiede di scrivere o copiare regex per ogni pattern che vuoi rilevare, CrowdSec, invece, separa nettamente due livelli, cioè i parser, che capiscono e normalizzano i log, e gli scenari, che descrivono comportamenti malevoli in un formato dichiarativo basato su YAML (tipicamente con un meccanismo “leaky bucket“, ovvero un certo numero di tentativi in un certo numero di secondi).
Parser e scenari sono distribuiti tramite un Hub centralizzato e si installano con un comando solo, esattamente come si fa con i pacchetti Linux. Quando la community pubblica un nuovo scenario, ti basta aggiornare per averlo a disposizione, senza modificare una riga di configurazione.
I quattro mattoncini che fanno funzionare CrowdSec
CrowdSec è composto da quattro pezzi che lavorano in modo coordinato.
Il primo è il Security Engine, ossia il vero e proprio motore di rilevazione. Si occupa di leggere i log delle applicazioni (può farlo da file, da journald o da syslog), passarli ai parser appropriati e valutarli contro gli scenari attivi. Quando uno scenario scatta, il motore crea una decisione, tipicamente un ban di quattro ore per l’IP colpevole. Tutte queste decisioni vengono salvate in un database locale, che di default è SQLite e per installazioni più grandi può diventare PostgreSQL.
Il secondo elemento è la Local API (LAPI). Si tratta dell’interfaccia REST che mette in comunicazione il motore di rilevazione con il resto del sistema. Se hai un solo server, la LAPI vive nella stessa macchina del motore. Ma se ne hai più di uno, puoi centralizzare le decisioni, perché tutti gli agenti puntano alla stessa LAPI, e il cervello della tua infrastruttura sa in ogni momento chi è bloccato e chi no, indipendentemente da quale server abbia rilevato per primo l’attacco.
Il terzo è il bouncer. Il motore di rilevazione, da solo, non blocca nulla, perché ti dice soltanto “questo IP è cattivo“. Per agire serve un bouncer, e ne esistono di vari tipi, dal cs-firewall-bouncer per iptables e nftables, ai plugin per Nginx, Caddy, Traefik e HAProxy, fino ai bouncer per Cloudflare e AWS WAF, che lavorano a livello CDN bloccando il traffico ancora prima che raggiunga il tuo server.
Infine, opzionale ma molto comodo, c’è la Console. È la dashboard SaaS gratuita su app.crowdsec.net dove puoi vedere alert, decisioni, metriche e blocklist da browser, anche con notifiche e collegamenti tra più macchine. Non è obbligatoria, ma se gestisci più server vale il costo dei due minuti di setup.
Installazione su un server Linux
Vediamo come attivarlo su una macchina Debian o Ubuntu. Il repository ufficiale offre pacchetti aggiornati per tutte le distribuzioni principali, e di fatto la procedura è semplice.
curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsecAl termine, il servizio è già attivo e dovrebbe aver rilevato automaticamente i log presenti sulla macchina, compresi quelli di SSH. Per controllare cosa sta osservando puoi usare la CLI dedicata.
sudo cscli metrics
sudo cscli collections list
sudo cscli scenarios listA questo punto manca il pezzo che applica i blocchi. La scelta più semplice, su un host stand-alone, è il firewall bouncer.
sudo apt install crowdsec-firewall-bouncer-iptablesL’installer si occupa di configurare iptables (o nftables, se preferisci la variante nftables del pacchetto) e di registrare automaticamente il bouncer presso la LAPI locale. Se invece davanti ai tuoi container fai girare Traefik, ti conviene installare il bouncer dedicato come middleware, in modo da bloccare le richieste direttamente nel reverse proxy senza nemmeno toccare il firewall del sistema operativo.
Una volta tutto in piedi, vale la pena collegare l’istanza alla Console. Dopo aver creato un account gratuito su app.crowdsec.net, ti basta lanciare un comando con la chiave d’iscrizione che la dashboard ti fornisce.
sudo cscli console enroll <chiave>In pochi minuti vedrai apparire il tuo server nell’elenco, con alert, decisioni e metriche aggiornate in tempo reale. Da qui in avanti, il sistema lavora da solo. La community blocklist viene scaricata e applicata automaticamente, gli scenari standard coprono SSH, HTTP, scanner di vulnerabilità noti e molto altro, e il tuo server diventa parte della rete senza bisogno di altri interventi manuali.
cscli, il coltellino svizzero dell’admin
Tutto il sistema si gestisce da una singola CLI, cscli. Vale la pena imparare quattro comandi che userai quotidianamente, perché ti permettono di tenere sotto controllo cosa sta succedendo senza dover aprire la dashboard ogni volta.
Per vedere chi è bloccato in questo momento.
sudo cscli decisions listPer vedere gli alert generati dalla tua macchina.
sudo cscli alerts listPer aggiungere manualmente un IP alla lista nera (utile se sai che un certo IP va fermato a prescindere).
sudo cscli decisions add --ip 198.51.100.42 --duration 24h --reason "blocco manuale"Per rimuovere un blocco, ad esempio se ti sei chiuso fuori dal tuo stesso server dopo qualche tentativo SSH andato male.
sudo cscli decisions delete --ip 203.0.113.10Una cosa che ti suggerisco di fare appena puoi è installare la collezione di scenari che corrisponde ai servizi che effettivamente esponi. Se per esempio hai un Nginx davanti a un blog WordPress, una buona base di partenza è la seguente.
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/wordpress
sudo systemctl reload crowdsecAllo stesso modo, se usi Traefik come reverse proxy davanti ai container.
sudo cscli collections install crowdsecurity/traefikL’Hub ufficiale è cresciuto molto negli ultimi due anni e copre ormai praticamente qualsiasi servizio diffuso, dai server di gioco a Vaultwarden, fino ad Authentik e ai container Docker generici. Una rapida occhiata su hub.crowdsec.net ti mostra l’elenco completo, organizzato per categorie. Nella maggior parte dei casi è sufficiente aggiornare e installare.
AppSec, da IPS a web application firewall
Una delle novità più rilevanti delle release recenti è il componente AppSec, introdotto con la versione 1.6 e maturato nella linea 1.7. La logica è semplice ma cambia molto le cose, perché invece di limitarsi ad analizzare i log delle applicazioni a posteriori, CrowdSec può ora ricevere direttamente le richieste HTTP dal reverse proxy e restituire un verdetto pass/block prima che la richiesta raggiunga l’applicazione protetta. In altre parole, agisce come un vero e proprio web application firewall.
A livello tecnico, AppSec usa Coraza, un engine WAF compatibile con il formato SecRules di ModSecurity. Questo è importante per due motivi. Da un lato, il futuro di ModSecurity è incerto e CrowdSec adotta da subito una base più moderna, scritta in Go, senza dipendere da Apache o da moduli specifici. Dall’altro, tutta l’enorme conoscenza accumulata negli anni dalle regole ModSecurity, dal Core Rule Set di OWASP in giù, è riutilizzabile praticamente senza modifiche.
Per attivare AppSec su un’installazione che usa Traefik o Nginx, l’unica cosa da fare è installare le collezioni dedicate e collegarle al bouncer. Le due più importanti sono le seguenti.
sudo cscli collections install crowdsecurity/appsec-virtual-patching
sudo cscli collections install crowdsecurity/appsec-generic-rules
sudo systemctl reload crowdsecLa prima si occupa di virtual patching, ovvero ogni volta che esce una CVE pesante su un software diffuso (un plugin WordPress vulnerabile, un nuovo problema in PHP), la community pubblica una regola che intercetta i payload d’attacco specifici e li blocca direttamente sul WAF. Per i tuoi server è come avere una patch immediata anche quando il software non è ancora stato aggiornato.
La seconda contiene regole generiche contro SQL injection, XSS, path traversal e gli altri grandi classici dell’OWASP Top 10. Il tutto con un’attenzione esplicita ai falsi positivi, che sono da sempre il tallone d’Achille dei WAF. L’intento dichiarato di CrowdSec è una soglia molto bassa di blocchi accidentali, anche a costo di lasciar passare qualche pattern marginale.
CrowdSec è una valida alternativa a Fail2Ban
Sebbene CrowdSec sia un progetto open source e copra praticamente tutti gli scenari per un homelab o per un piccolo gruppo di server, alcune funzioni più avanzate, in particolare quelle pensate per grosse infrastrutture, sono dietro un piano a pagamento, tra cui blocklist premium tematiche, gestione multi-account con ruoli e permessi, audit log estesi e così via. La buona notizia è che per un singolo amministratore l’edizione gratuita rimane più che sufficiente e include la community blocklist completa, che è la vera ragione per cui si sceglie CrowdSec.
La blocklist che ricevi gratuitamente è quella comunitaria, aggregata da tutte le 150.000+ istanze di CrowdSec che partecipano al progetto. Le blocklist premium a pagamento sono curate manualmente dagli analisti, organizzate per tema (WordPress, e-commerce, mail server) e con falsi positivi filtrati secondo loro regole interne. Se ti dà fastidio che gli IP degli attacchi inviati al tuo server vadano ad alimentare anche la blocklist a pagamento di CrowdSec, sappi che puoi disabilitare la telemetria condivisa.
Se la sensazione, dopo anni di Fail2Ban, è che proteggere un server esposto sia un lavoro solitario e ripetitivo, CrowdSec è probabilmente la prima alternativa seria a cambiarti il punto di vista. Non è una bacchetta magica e non sostituisce le buone pratiche di base, tra cui SSH con chiavi, aggiornamenti regolari e firewall ben configurati. In cambio di un’ora scarsa di setup ti regala però due cose che il vecchio approccio non potrà mai avere, ovvero una rete di sensori globale che lavora ventiquattr’ore al giorno, e un livello di sicurezza moderno per gestire rilevazione e blocchi.
Il consiglio pratico è di partire piano, ovvero installa CrowdSec su un singolo server, accendi solo le collezioni dei servizi che usi, e prenditi qualche giorno per capire come legge i tuoi log e che alert genera. Poi, quando ti sentirai a tuo agio, aggiungi AppSec davanti alle applicazioni più esposte e, da lì in avanti, il sistema lavorerà al tuo posto, imparando dagli attacchi del resto della rete prima ancora che i tuoi server li vedano.
