Alternative a Fail2Ban per i server Linux moderni

Verificare la superficie di attacco prima di scegliere l'utensile

A Alternativa a Fail2Ban può essere selezionato in modo sensato solo quando sono stati individuati i servizi effettivamente raggiungibili. SSH, SMTP, IMAP e un’applicazione HTTP presentano procedure di accesso, fonti di log e tipi di danno diversi. Un servizio di database accessibile pubblicamente, invece, di norma non dovrebbe necessitare di protezione tramite una lista di blocco Internet: la sua esposizione in rete deve essere limitata alle applicazioni necessarie e alle reti affidabili.

In caso di accessi amministrativi, si ha Limitazione dell'accesso e un sistema di autenticazione robusto ha la precedenza sui blocchi automatici degli indirizzi IP. Un servizio SSH dietro una VPN, un bastion host o reti di amministrazione fisse offre agli aggressori una superficie di attacco notevolmente più ridotta rispetto a una porta aperta a livello globale. Aggiornamenti di sicurezza regolari, account con privilegi separati e procedure di accesso con password attentamente valutate riducono i rischi che una semplice lista di blocco non è in grado di eliminare.

Se l'accesso SSH è volutamente pubblico, i limiti e i blocchi basati sui log possono ridurre il numero di tentativi ripetuti di inserimento della password. Tuttavia, rimangono una misura complementare: gli utenti dietro un gateway NAT condiviso possono utilizzare lo stesso indirizzo di origine, mentre gli attacchi distribuiti impiegano molti indirizzi. Per i servizi di posta elettronica è inoltre importante stabilire quali protocolli siano effettivamente accessibili agli utenti esterni e quali tentativi di accesso non riusciti vengano registrati.

Nelle applicazioni web occorre distinguere tra l'accessibilità del proxy inverso e quella dei servizi backend interni. Un Nginx pubblico può accettare richieste HTTP senza che il database, la cache o l'interfaccia di amministrazione debbano essere accessibili da Internet. Il Obiettivo di conservazione L'obiettivo non è quindi, in linea generale, quello di „bloccare gli indirizzi IP“, bensì di limitare gli accessi non autorizzati per ciascun servizio, garantire un utilizzo legittimo ed evitare autorizzazioni non necessarie.

Prima di ogni modifica, i responsabili dovrebbero individuare quali percorsi di accesso sono necessari in caso di emergenza e quali reti sorgente effettuano l’accesso in condizioni normali. Questa analisi della situazione impedisce che una regola del firewall troppo restrittiva blocchi l’accesso amministrativo o la manutenzione automatizzata. Solo in seguito è possibile decidere se sia più appropriata l’analisi dei log, la limitazione delle connessioni o un approccio a più livelli.

Inoltre, un blocco non risponde alla domanda se un servizio debba essere per forza pubblico. Chi inverte questa sequenza si concentra su connessioni sospette, sebbene l’esposizione di fondo rimanga invariata. Soprattutto nel caso di interfacce amministrative utilizzate raramente, un percorso di accesso privato è spesso più efficace e più semplice da gestire rispetto a regole di riconoscimento sempre più complesse.

Quattro approcci invece di un'alternativa a Fail2Ban

Anziché cercare un'unica soluzione sostitutiva, vale la pena separare il riconoscimento dalla reazione. CrowdSec elabora fonti di log configurabili tramite parser e scenari per valutare sequenze di eventi e generare decisioni. Il Security Engine non applica direttamente tali decisioni; a tal fine è necessario che un componente di correzione separato sia collegato e operativo.

Questa suddivisione è adeguata quando lo stesso meccanismo di rilevamento deve essere applicato in diversi punti. Un componente firewall può applicare le decisioni relative alle connessioni di rete, mentre i componenti per i server web o i proxy inversi intervengono sul traffico HTTP. Ciò comporta però anche un aumento dei requisiti: l'acquisizione dei log, i parser, le API locali, le autorizzazioni e l'applicazione concreta delle regole devono essere pianificati come una catena coerente.

SSHGuard è pensato per casi ben definiti. Lo strumento aggrega i log di sistema ed è in grado di bloccare, tramite i backend del firewall, le fonti che si rivelano ripetutamente sospette; il suo scopo comprende gli attacchi brute force su SSH e altri servizi. È quindi più adatto a gestire errori di autenticazione identificabili che a un’analisi completa delle richieste web.

Nativi Limitazione della velocità in nftables adotta un approccio diverso. I set dinamici e i contatori possono limitare le nuove connessioni TCP per indirizzo di origine e gestire le voci scadute. Ciò rallenta le sequenze di connessioni rapide prima dell’autenticazione, non richiede un analizzatore di log e, allo stesso tempo, non valuta se un login sia fallito o se una richiesta HTTP fosse malevola.

In questo contesto, la direzione della regola è importante: nftables distingue tra regole che accettano il traffico fino a una certa velocità e espressioni con over, che scartano il traffico al di sopra di una determinata soglia. Un limite deve quindi essere adeguato al servizio, al comportamento previsto degli utenti e agli indirizzi di origine condivisi. Non si tratta di una classificazione affidabile di ogni identità sospetta.

Per un singolo server con pochi servizi ben definiti, può essere sufficiente una protezione dei log essenziale o un limite moderato alle connessioni. La presenza di più host, fonti di log centralizzate o la necessità di diversi punti di applicazione rendono più indicata un’architettura modulare. Nessuna di queste opzioni sostituisce l’applicazione delle patch, l’autenticazione forte o un accesso alla rete restrittivo.

L'alternativa adeguata a Fail2Ban dipende quindi dai segnali disponibili e dal punto in cui deve avvenire la reazione. I modelli di log sono utili in caso di errori di accesso ripetuti; le regole sui pacchetti limitano la frequenza delle connessioni. Entrambi i metodi rilevano solo ciò per cui sono stati progettati la loro fonte di dati e le loro regole.

Separare nettamente il firewall dalla protezione HTTP

Un server Nginx o un reverse proxy collega due livelli di protezione che non devono essere confusi tra loro. Un blocco del firewall respinge o autorizza le connessioni provenienti da un determinato indirizzo di origine e può quindi riguardare contemporaneamente SSH, SMTP o l'accesso web. Tuttavia, non valuta singoli percorsi HTTP, intestazioni o contenuti delle richieste; queste informazioni si trovano a livello di applicazione.

Su CrowdSec ci sono Rilevamento e applicazione funzioni distinte. Il Log Processor analizza i dati di log e le richieste HTTP provenienti da server web compatibili. AppSec fa parte di questo Log Processor e filtra tali richieste HTTP. I Remediation Components, invece, hanno il compito di applicare le decisioni al livello selezionato, ad esempio su un firewall, un server web o un reverse proxy.

Per proteggersi da attacchi di tipo SQL injection, cross-site scripting o altri contenuti dannosi nelle richieste, un semplice componente firewall non è quindi sufficiente. Sono necessari un collegamento compatibile con il server web e un’adeguata configurazione AppSec con regole appropriate. La correzione deve essere tenuta separata dal punto di vista tecnico: essa attua le decisioni nel punto di applicazione selezionato.

Entrambi i livelli possono essere utili se utilizzati in parallelo. Un blocco a livello di rete riduce l’ulteriore traffico proveniente da una fonte, mentre un Verifica HTTP valuta e filtra i server web compatibili con le richieste AppSec. Ciò non significa che il blocco di un indirizzo IP protegga automaticamente da attacchi di tipo SQL injection o cross-site scripting: senza la verifica delle richieste, il firewall non riconosce né i parametri né i dati utili.

D'altra parte, anche le misure basate sull'AppSec e sull'IP presentano dei limiti. Tentativi lenti al di sotto delle soglie, numerosi indirizzi di origine variabili o utenti legittimi dietro lo stesso indirizzo NAT rendono difficile prendere decisioni basate sull'IP di origine. Le regole dovrebbero quindi tenere conto dei falsi allarmi e non considerare in modo indiscriminato come attacchi l’accesso a moduli normali, API e integrazioni automatizzate.

Per facilitare la pianificazione, è utile una breve panoramica: La Livello firewall gestisce il traffico di rete in base ad indirizzi, porte e caratteristiche della connessione. AppSec elabora e filtra le richieste HTTP provenienti da server web compatibili nell’ambito del Log Processor. I componenti di correzione applicano le decisioni in modo mirato a un livello prestabilito.

Un sistema web pubblico richiede inoltre una chiara separazione delle responsabilità. Il proxy inverso deve poter accedere solo ai backend necessari, mentre gli endpoint amministrativi non dovrebbero rimanere accessibili al pubblico solo perché protetti da un filtro a monte. In questo modo, la segmentazione della rete, l’autenticazione sicura e le regole mirate si integrano a vicenda, senza attribuire a una singola tecnica di blocco un effetto protettivo superiore a quello che può effettivamente garantire.

Confronto tra server Linux tipici

Non è possibile scegliere un’alternativa a Fail2Ban basandosi esclusivamente sul numero di possibili blocchi. Sono determinanti i segnali che vengono analizzati e il punto in cui viene applicata la misura. CrowdSec separa il proprio motore di sicurezza dal componente che applica le decisioni al firewall, al proxy o al server web. SSHGuard, invece, analizza i log di sistema alla ricerca di tentativi di attacco ripetuti; nftables è in grado di limitare le nuove connessioni direttamente nel percorso dei pacchetti.

La tabella non rappresenta una classifica. Per un singolo servizio con tentativi di accesso chiaramente falliti, un’analisi semplificata dei log è una cosa diversa da un limite contro gli attacchi di tipo “connection flood”. Per un proxy inverso, occorre inoltre considerare se le richieste HTTP debbano essere filtrate da AppSec su una connessione compatibile. Il Punto di applicazione deve essere adeguata all'oggetto da proteggere: una regola del firewall non valuta i contenuti delle richieste, mentre i componenti di correzione applicano le decisioni al livello selezionato.

Anche la gestione centralizzata non è fine a se stessa. Può uniformare le decisioni e l’analisi dei log su più host, ma richiede un solido sistema di gestione degli accessi e di gestione dei guasti. Per un server piccolo e isolato, questa architettura aggiuntiva può, in alcuni casi, comportare un onere di manutenzione maggiore rispetto ai vantaggi in termini di sicurezza. Al contrario, servizi identici presenti su più host possono trarre vantaggio da un’installazione centrale di CrowdSec progettata in modo mirato.

Verificare accuratamente la configurazione e classificarla

Prima dell’attivazione, occorre innanzitutto stabilire quali messaggi raggiungono effettivamente il servizio. Nel caso di una soluzione basata sui log, verifica la fonte dei log, il parser e il formato specifico degli eventi SSH, di posta elettronica o proxy. Con CrowdSec, il semplice rilevamento dell’attività non è sufficiente: un componente di remediation registrato e raggiungibile deve inoltrare le decisioni alla connessione prevista al firewall o al proxy.

I comandi seguenti sono esclusivamente operazioni di verifica in modalità di sola lettura su un sistema Linux, sul quale potrebbero già essere presenti i rispettivi strumenti. Non modificano alcuna regola né installano alcun pacchetto. Consentono di visualizzare l'insieme attuale delle regole, i componenti CrowdSec registrati e i pacchetti candidati disponibili per Debian o Ubuntu.

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

L'output non garantisce ancora alcuna protezione. Verifica in nftables se la catena di input pertinente disponga dell'hook previsto e della politica predefinita appropriata, e se siano previste regole per le connessioni esistenti, il loopback, IPv4 e IPv6, nonché per la porta di servizio effettiva. Inoltre, un componente registrato potrebbe essere configurato per un punto di applicazione errato. Anche un pacchetto candidato visibile non garantisce che la sua versione, configurazione e parser siano compatibili con la distribuzione e con il proprio servizio.

I valori di soglia, i periodi di blocco e le eccezioni non devono essere applicati in produzione senza essere stati verificati, sulla base di semplici esempi. In particolare, gli indirizzi NAT condivisi, gli accessi da dispositivi mobili e i processi automatizzati possono altrimenti causare falsi allarmi. Per l’analisi degli eventi di rete e del comportamento del sistema è possibile, in aggiunta, Tracciamento eBPF per il monitoraggio di Linux aiutare; tuttavia, non sostituisce né la verifica della catena di log né la decisione tecnica relativa a un blocco.

La scelta giusta per quattro scenari operativi

Un singolo VPS con SSH accessibile da qualsiasi parte del mondo presenta esigenze di protezione ben definite. SSHGuard è in grado di segnalare a un firewall backend i tentativi falliti ripetuti, riconoscibili nei log corrispondenti. Un limite moderato di nftables può inoltre limitare le nuove connessioni, ma non valuta gli errori di accesso. La priorità va data a canali di amministrazione limitati e a un accesso forte; il blocco dell’IP rimane una misura complementare.

In un server di posta, SMTP, IMAP e Submission si integrano con diversi percorsi di autenticazione e di registrazione. Una risposta snella basata sui log ha senso solo se i messaggi rilevanti vengono registrati integralmente. CrowdSec diventa un’opzione valida quando è necessario consolidare le decisioni o l’analisi dei log provenienti da più sistemi. In assenza di questa esigenza, l’architettura centralizzata risulterebbe sproporzionata rispetto a una soluzione locale chiaramente delimitata.

Per Nginx o Traefik, da utilizzare a monte di un’applicazione web, uno strumento orientato esclusivamente a SSH non è sufficiente. In questo caso, una protezione a più livelli Accessi di rete dai controlli HTTP: CrowdSec AppSec fa parte del Log Processor ed è in grado di filtrare le richieste provenienti da server web compatibili. I componenti di remediation, invece, applicano le decisioni al livello selezionato, ad esempio sul server web o sul reverse proxy. Entrambe le attività devono essere integrate in modo adeguato e verificate separatamente.

Una piccola flotta con log centralizzati o Kubernetes può trarre vantaggio da un’API locale centralizzata o da log centralizzati. Ciò non semplifica automaticamente la gestione: è necessario pianificare le autorizzazioni, l’accessibilità delle interfacce, la segmentazione e il guasto di un componente centrale. Gli aspetti relativi all’elaborazione dei pacchetti e al bilanciamento del carico nelle reti Linux di grandi dimensioni sono trattati anche nell’articolo su Receive Side Scaling nelle reti di server Linux. Per un numero limitato di host senza un processo operativo comune, una soluzione locale risulta spesso più comprensibile.

Monitoraggio della logica di blocco durante il funzionamento

Una logica di blocco è comprensibile solo se si controllano separatamente tre fasi: l’acquisizione dei dati di log, la decisione che ne deriva e la sua applicazione tecnica. In CrowdSec, il motore di sicurezza legge le fonti di log configurate e genera decisioni sulla base di parser e scenari; il blocco vero e proprio, tuttavia, viene gestito da un componente di remediation separato.

Verifica innanzitutto se i messaggi attesi vengono effettivamente ricevuti. Per un servizio SSH sono rilevanti i tentativi di accesso falliti, per un server di posta i rispettivi protocolli di autenticazione e per un proxy i relativi log di accesso o di sicurezza. Gli eventi visibili di per sé non dimostrano ancora un effetto difensivo: solo la catena composta da ricezione del log, sequenza riconosciuta, decisione e regola efficace consente una diagnosi attendibile.

Verifica quindi separatamente le decisioni e il componente registrato. Se CrowdSec rileva eventi sospetti, ma nessun componente di remediation è collegato o funzionante, le decisioni rimangono senza conseguenze. La documentazione ufficiale sugli errori indica proprio questo scenario come causa del fatto che il motore di sicurezza sia attivo ma non avvenga alcun blocco. Il rilevamento non equivale a un blocco.

Nel caso della protezione web si aggiunge un ulteriore controllo. AppSec fa parte del Log Processor e filtra le richieste HTTP provenienti da server web compatibili. I Remediation Components applicano le decisioni al livello selezionato, ad esempio sul server web o sul reverse proxy. Durante il funzionamento dovrebbe quindi rimanere chiaro se un rifiuto deriva dal controllo HTTP o da una decisione già applicata, in modo da poter esaminare in modo mirato errori e falsi allarmi.

I falsi allarmi sono particolarmente gravi quando molte persone autorizzate utilizzano lo stesso indirizzo pubblico. I gateway NAT, le reti mobili e i sistemi CI possono raggruppare numerosi tentativi di accesso legittimi sotto un unico indirizzo IP di origine. Scegli quindi soglie, durate di blocco ed eccezioni in base alle reali modalità di accesso e rendi tracciabili le decisioni, compresi il motivo e la durata, invece di considerare una lunga lista di blocchi come un successo.

Testa innanzitutto le modifiche utilizzando log storici anonimizzati o in un ambiente di staging. In questo modo è possibile verificare se i parser rilevano i modelli previsti e se la correzione reagisce al livello previsto, senza compromettere gli accessi amministrativi. SSHGuard elabora i log di sistema ed è in grado di interagire con diversi backend di firewall; pertanto, la fonte dei log e il backend devono essere considerati congiuntamente nell’ambiente di installazione.

Una procedura controllata non sostituisce un test di attacco sul sistema di produzione. Documentare gli eventi previsti, le decisioni osservate e l'effetto delle regole che ne deriva; successivamente, rimuovere i dati di test o lasciare che le voci a tempo determinato scadano regolarmente. In questo modo, l'efficacia della protezione e i possibili danni collaterali rimangono verificabili, senza innescare intenzionalmente blocchi reali a carico degli utenti del sistema di produzione.

Risoluzione dei problemi relativi ai log e alle regole

Inizia sempre la ricerca degli errori dalla fonte del log e procedi poi fino all’applicazione delle regole. Se mancano i messaggi appropriati, né un log parser né una logica di scenario o di blocco possono reagire in modo affidabile. Verifica quindi il servizio, il lettore di log e il formato effettivo prima di modificare i valori di soglia o di sospettare che il problema sia dovuto alle regole del firewall.

In CrowdSec, il quadro del problema è chiaro quando gli eventi o le decisioni sono visibili, ma gli accessi rimangono comunque possibili: una decisione non viene applicata automaticamente dal motore. Verifica che un componente di remediation adeguato sia registrato, raggiungibile e effettivamente collegato al firewall, al server web o al proxy. Senza questo componente, nessuna regola di blocco viene applicata.

Nel caso di SSHGuard, la causa è spesso da ricercarsi a monte. Lo strumento aggrega i log di sistema, ma un lettore di log inadeguato o un formato di servizio che si discosta dal modello previsto non fornisce risultati utilizzabili. La configurazione di esempio presente nel repository mostra possibili impostazioni e opzioni, ma proviene dal ramo di sviluppo; confrontatela con la documentazione del pacchetto e con la versione installata, invece di applicarla così com’è.

Con nftables devi inoltre verificare che la regola si trovi nell'hook previsto nella chain pertinente, che copra la porta di servizio effettiva e che si applichi alle famiglie di protocolli richieste. Il set di regole di esempio separa IPv4 e IPv6 tramite catene dedicate, consentendo le connessioni già stabilite e quelle correlate, nonché il traffico loopback, prima delle autorizzazioni relative alle porte. Una protezione formulata esclusivamente per IPv4 non copre IPv6; allo stesso modo, una limitazione di velocità troppo restrittiva può influire sulle connessioni parallele autorizzate.

Un metro limita le nuove connessioni in base a una frequenza definita per ogni sorgente ed è in grado di gestire voci dinamiche con timeout. Tuttavia, ciò non tiene conto dei tentativi di accesso falliti. Se un attacco rimane al di sotto della frequenza, un mancato rilevamento non è quindi necessariamente indice di un difetto della regola, ma può rappresentare un limite dell’approccio scelto. Gancio, catena e punto di misurazione devono essere in linea con l'effetto previsto.

Apporta le modifiche una alla volta e, dopo ogni passaggio, ricontrolla l’ingresso nel log, la decisione e l’applicazione. Prima di apportare modifiche al firewall, assicurati di disporre di un accesso di emergenza indipendente, ad esempio tramite console, host bastione o una rete di amministrazione separata. Ciò impedisce che una regola inserita in modo errato o un'aggiunta IPv6 errata blocchi l'unico accesso al server.

Decisione in base al rischio e all'impegno richiesto

L'alternativa adeguata a Fail2Ban dipende dalla superficie di attacco esposta, non da una classifica generale. Verifica quali servizi sono accessibili pubblicamente, se gestiscono le registrazioni, quali log sono disponibili in modo affidabile e chi si occupa della configurazione su base permanente. Un servizio di database non accessibile pubblicamente non necessita di una lista di blocco Internet; la sua esposizione in rete rimane la decisione più importante in materia di sicurezza.

Per un singolo server di dimensioni contenute in cui si verificano ripetuti errori di accesso tramite SSH o alla posta elettronica, SSHGuard può rappresentare un approccio snello basato sui log. Il progetto è finalizzato alla protezione dagli attacchi brute force contro SSH e altri servizi e, a tal fine, utilizza i log di sistema e i backend del firewall. La copertura concreta dei log e i parametri di blocco devono tuttavia essere compatibili con la distribuzione installata e il formato del servizio.

Se si desidera limitare soprattutto le nuove connessioni veloci, un limite di velocità moderato in nftables rappresenta un’integrazione diretta. I misuratori possono limitare le connessioni per indirizzo di origine; le regole con over Rifiuta il traffico che supera la soglia stabilita. Ciò avviene prima dell'autenticazione, ma non fornisce alcuna indicazione semantica sul fatto che l'autenticazione sia fallita o che una richiesta HTTP fosse malevola.

CrowdSec è la soluzione ideale quando è necessario coordinare l'analisi dei log e l'applicazione delle politiche su più livelli o su più host. La sua architettura separa il motore dai componenti di correzione; sono possibili varianti distribuite con API locale centralizzata o log centralizzati. Questo vantaggio comporta requisiti aggiuntivi in termini di autorizzazioni, accessibilità, segmentazione e un piano di emergenza in caso di guasti. Operatività è quindi un criterio di selezione, oltre alla gamma di funzioni.

Nel caso delle applicazioni web pubbliche, un blocco tramite firewall non è sufficiente per la valutazione delle singole richieste HTTP. A tal fine è necessaria un’integrazione AppSec compatibile con regole adeguate. AppSec fa parte del Log Processor e filtra le richieste HTTP provenienti da server web compatibili; i Remediation Components applicano le decisioni nel punto di applicazione selezionato. È fondamentale stabilire se la necessità di protezione riguarda le connessioni, gli eventi di autenticazione o i contenuti HTTP.

Le misure basate sull'IP rimangono limitate: le botnet distribuiscono i tentativi su molte fonti, gli attacchi lenti possono rimanere al di sotto di una certa soglia e, in caso di blocco, gli indirizzi condivisi colpiscono anche chi non è coinvolto. Queste misure riducono il rumore automatizzato, ma non sostituiscono l’applicazione tempestiva delle patch, gli accessi amministrativi limitati e l’autenticazione forte. Soprattutto nel caso di SSH, l’autenticazione basata su chiave e l’accessibilità limitata hanno la precedenza su soglie di blocco sempre più aggressive.