Pubblicato originariamente nel 2013. Rielaborato il 23 ottobre 2026: questa revisione sostituisce le vecchie istruzioni.
Un livello di difesa, non una protezione assoluta
Fail2ban analizza eventi nei log e può applicare azioni quando corrispondono ai filtri configurati. Può aiutare contro tentativi ripetuti; non sostituisce autenticazione robusta, aggiornamenti e corretta esposizione dei servizi.
La prima versione dell’articolo risale al 2013. In questa revisione i vecchi percorsi e pacchetti Debian non sono presentati come una procedura attuale.
Verificare la sorgente dei log
Controlla come il servizio registra gli eventi. File di log e journal di systemd richiedono una configurazione appropriata del backend. Anche i formati possono cambiare tra versioni e distribuzioni.
Un filtro che non riconosce gli eventi reali può restare silenzioso. Uno troppo ampio può bloccare attività legittime.
Usare i file locali
Fail2ban prevede file .local e directory per le personalizzazioni. Usali per le impostazioni da modificare senza riscrivere in blocco i file distribuiti dal pacchetto.
maxretry, findtime e bantime indicano soglia di eventi, finestra di osservazione e durata del blocco. Vanno scelti considerando servizio e utenti.
Provare senza perdere l’accesso
Pianifica un canale di recupero prima di cambiare le regole di accesso. Verifica i filtri su eventi di prova e controlla le azioni effettive del firewall. Non generare tentativi contro sistemi di terzi.
Controllare i falsi positivi
Una verifica utile considera sia i tentativi da fermare sia gli accessi che devono continuare a funzionare. Documenta le scelte e torna sui log dopo il rilascio. La configurazione iniziale è l’inizio della manutenzione.