Come installare CSF su Ubuntu per proteggere il server

CSF, su Ubuntu, ha senso quando vuoi un firewall con una logica più “operativa” rispetto a una configurazione manuale fatta di eccezioni sparse. La parte importante non è installarlo in fretta, ma farlo senza tagliare fuori SSH, senza sovrapporlo male a UFW e senza lasciare aperto più del necessario. Se il server è già in produzione, tratta l’operazione come un change controllato: prima osservi lo stato attuale, poi applichi una configurazione minima, infine verifichi che servizi, porte e accessi siano ancora quelli attesi.

CSF funziona bene quando la baseline è chiara: quali porte devono restare esposte, quali servizi ascoltano davvero, quali IP amministrativi devono essere sempre autorizzati e quali log vuoi monitorare con LFD. Il vantaggio pratico è che puoi avere una politica di accesso coerente, con blocchi automatici su comportamenti sospetti e una gestione più leggibile delle whitelist. Il rischio, invece, è banale ma reale: una regola troppo aggressiva o una whitelist incompleta ti può impedire l’accesso al server in pochi secondi.

Prerequisiti da verificare prima di toccare il firewall

Prima di installare CSF, conviene confermare tre cose: che il server sia effettivamente Ubuntu, che tu abbia accesso con privilegi amministrativi e che esista un percorso di recupero nel caso qualcosa vada storto. Se stai lavorando su una macchina remota, tieni aperta una seconda sessione SSH o una console out-of-band, perché il rollback più rapido in caso di errore è poter rientrare senza dipendere dal firewall appena modificato.

Controlla anche se UFW è attivo. CSF non va usato in modo casuale insieme a un altro firewall host-based che gestisce le stesse porte, perché le regole possono diventare difficili da leggere e da diagnosticare. Non è obbligatorio disinstallare tutto a priori, ma devi sapere chiaramente quale strumento sta governando il traffico in ingresso e in uscita.

Verifica infine quali porte siano in ascolto, così non configuri a memoria servizi che non esistono. Su un server tipico puoi trovare SSH, HTTP, HTTPS, mail, database o pannelli di controllo; la lista reale va ricavata dalla macchina, non dall’idea che hai dello stack.

sudo ss -tulpn

L’output atteso è un elenco di socket in ascolto con porta, protocollo e processo associato. Se non vedi il servizio che ti aspetti, prima risolvi quello: CSF non deve diventare il modo per “nascondere” un problema di base.

Installazione di CSF su Ubuntu

Su Ubuntu la procedura standard è lineare. CSF non è pensato come un sostituto di tutto il resto, ma come uno strato di controllo del traffico e di reazione automatica ai pattern sospetti. Il punto critico è installarlo senza interrompere l’accesso esistente e senza applicare subito una politica troppo stretta.

Se il pacchetto è disponibile nei repository o nel metodo che usi abitualmente per l’ambiente, l’obiettivo è arrivare a un’installazione pulita, con file di configurazione leggibili e possibilità di test prima dell’abilitazione definitiva. Se preferisci il metodo upstream, assicurati di usare una fonte affidabile e di verificare l’integrità del contenuto scaricato secondo le procedure del tuo ambiente.

sudo apt update

Il primo comando serve solo ad aggiornare l’indice pacchetti, non modifica il sistema in modo distruttivo. L’output atteso è il refresh dei repository senza errori di risoluzione o firme non valide.

Se installi CSF da sorgente o da pacchetto locale, la struttura tipica prevede il posizionamento dei file in una directory di lavoro e poi l’esecuzione dello script di installazione. Il dettaglio esatto dipende dal metodo scelto, ma la logica resta la stessa: installi i binari e la configurazione base, poi testi prima di attivare il blocco.

sudo sh install.sh

Il comando sopra è rappresentativo del flusso di installazione più comune per CSF quando lavori da archivio estratto. Dopo l’installazione, devi sempre controllare i file creati e i moduli disponibili, non limitarti a verificare che lo script sia terminato senza errori.

Se invece il tuo ambiente usa un pacchetto già pronto, il principio non cambia: l’installazione deve portare a file di configurazione presenti e servizi avviabili senza attivazione immediata delle regole restrittive. In ogni caso, conserva una copia della configurazione originale prima di qualunque modifica.

Configurazione iniziale: porte, SSH e whitelist

La prima configurazione utile di CSF riguarda le porte consentite. Il file principale, di norma, è `csf.conf`. Qui non si lavora “a sentimento”: si parte dalle porte realmente necessarie, si aggiunge solo ciò che serve e si evita di aprire range ampi senza una ragione concreta. Per un server web tipico, le porte minime sono SSH, HTTP e HTTPS; tutto il resto va giustificato dal servizio che lo usa.

La regola più importante è non bloccare SSH prima di aver confermato che la tua sessione amministrativa è coperta da una whitelist affidabile. Se accedi dal tuo IP fisso, inseriscilo subito. Se lavori da più sedi o dietro IP dinamici, valuta un indirizzo di gestione dedicato o una VPN amministrativa invece di allargare troppo la superficie esposta.

Nel file `csf.conf` e nei file correlati puoi definire quali porte devono rimanere aperte e quali protocolli monitorare. Il vantaggio è la chiarezza; lo svantaggio è che una modifica sbagliata ha effetto immediato. Per questo conviene fare un backup del file prima di editarlo.

sudo cp /etc/csf/csf.conf /etc/csf/csf.conf.bak

Il rollback più semplice, in caso di problema, è ripristinare il file salvato e ricaricare CSF senza cambiare altro. Il blast radius di questa operazione è limitato alla configurazione del firewall host-based, ma l’effetto pratico può essere totale se blocchi SSH o i servizi pubblici.

Se vuoi aprire solo le porte essenziali, puoi intervenire sui parametri dedicati alla whitelist e alle porte consentite. La sintassi precisa dipende dalla versione e dal layout del file, ma il concetto resta invariato: autorizzi ciò che serve, non ciò che “forse potrebbe servire”.

Un caso tipico è l’accesso amministrativo da un singolo IP. In quel caso, l’IP va autorizzato nella whitelist prima dell’attivazione della policy restrittiva. Questo riduce la probabilità di auto-blocco e rende più semplice il troubleshooting se qualcosa smette di rispondere.

Verifica della configurazione prima dell’attivazione

Prima di accendere CSF in modalità operativa, usa il test di configurazione. È il passaggio che evita la maggior parte degli errori banali: porte scritte male, moduli mancanti, configurazione incoerente con il sistema o dipendenze non soddisfatte. Il test non sostituisce la verifica reale del traffico, ma ti dice se la configurazione è almeno sintatticamente valida.

sudo csf -t

L’output atteso è l’assenza di errori bloccanti. Se compaiono warning, leggili con attenzione: alcuni sono solo informativi, altri indicano porte non riconosciute o impostazioni incompatibili con il sistema. Non passare all’attivazione se il test segnala problemi strutturali.

A questo punto ha senso controllare anche lo stato del firewall e dei moduli LFD. Se il demone di blocco automatico non è attivo o non parte al boot, CSF perde una parte importante del suo valore operativo. Verifica sempre entrambi, non solo il firewall in senso stretto.

sudo csf -l

Con questo comando controlli le regole correnti. L’output atteso è una lista coerente con le porte che hai dichiarato in configurazione e con le eccezioni che hai previsto. Se vedi regole inattese, prima capisci da dove arrivano: installazioni precedenti, automazioni, altri strumenti di hardening o configurazioni residue.

Attivazione controllata e impatto sul traffico

L’attivazione va fatta in modo reversibile. Se stai intervenendo su un server in produzione, la sequenza corretta è: whitelist confermata, test superato, attivazione, verifica immediata da una seconda sessione. Non è il momento di “vedere dopo se funziona”: il firewall va validato mentre hai ancora accesso al piano di emergenza.

sudo csf -e

Con l’abilitazione, il rischio principale è interrompere connessioni legittime già stabilite o bloccare nuove connessioni da indirizzi non previsti. Il blast radius include SSH, web, mail e qualunque servizio esposto dal server. Per questo dopo l’attivazione devi controllare subito sia la tua sessione amministrativa sia almeno un endpoint pubblico.

Se qualcosa non risponde, non fare subito modifiche ampie. Prima distingui se il problema è di rete, di firewall o del servizio stesso. Un `curl -I` verso l’host, eseguito da un punto esterno autorizzato, può dirti se l’HTTP risponde almeno a livello di intestazioni; un test SSH da un IP whitelisted ti conferma che il canale amministrativo è ancora aperto.

curl -I https://tuodominio.example

Se ottieni una risposta coerente, il firewall non ha tagliato il traffico web. Se invece il timeout arriva subito dopo l’attivazione, il problema è probabilmente nella policy o nelle porte dichiarate. In quel caso il rollback più rapido è disattivare CSF, correggere la configurazione e riapplicare il test prima di una nuova attivazione.

LFD: blocchi automatici, log e falsi positivi

LFD è il pezzo che rende CSF più utile in pratica: osserva i log e reagisce a comportamenti sospetti, come tentativi ripetuti di accesso o pattern anomali. Il punto delicato è trovare il bilanciamento tra protezione e falsi positivi. Un server molto esposto, o con utenti legittimi dietro NAT condivisi, può generare blocchi indesiderati se la soglia è troppo aggressiva.

Qui la regola è semplice: prima osserva i log, poi regola le soglie. Non cambiare i limiti alla cieca. Cerca i file di log che LFD monitora realmente e verifica se gli eventi che vedi sono davvero attacchi o solo traffico legittimo che somiglia a un abuso. Questo è il punto in cui un amministratore prudente evita di “curare” con un’impostazione più dura un problema che andrebbe capito meglio.

Se un IP legittimo viene bloccato, la correzione deve essere mirata. Non abbassare subito tutte le soglie: valuta il singolo caso, autorizza l’indirizzo se necessario e poi revisione della policy. In ambienti con pannelli, proxy o CDN, il rischio di interpretare male l’origine del traffico è concreto.

Per la diagnosi, i log di CSF e LFD sono la prima fonte. Se non trovi l’informazione che ti serve, il passo corretto è capire quale log stia effettivamente alimentando la regola e se il formato dei log sia compatibile con il parser. Una protezione automatica che legge il log sbagliato non protegge: blocca e basta.

Integrazione con UFW, servizi esposti e pannelli di controllo

Se sul server esiste già UFW, devi decidere chi governa davvero le policy. Tenerli entrambi attivi con logiche sovrapposte è una ricetta per confondere troubleshooting e manutenzione. La scelta più pulita è usare un solo punto di controllo host-based per l’ingresso e, se serve, lasciare a UFW o ad altri strumenti un ruolo secondario ben definito. L’importante è non avere due livelli che fanno la stessa cosa senza una gerarchia chiara.

Con i pannelli di controllo la prudenza sale di livello, perché spesso aprono porte aggiuntive per servizi web, mail o gestione remota. Prima di applicare CSF, fai una mappa delle porte richieste dal pannello e dai servizi collegati. Se il pannello usa porte non standard, annotale nel file di configurazione e verifica che siano davvero raggiungibili dall’esterno solo dove serve.

La stessa attenzione vale per i servizi mail. SMTP, submission, IMAP e POP non vanno “indovinati”: vanno dichiarati con precisione, soprattutto se il server gestisce autenticazione di utenti reali. Un firewall troppo stretto può rompere invio e ricezione in modo intermittente, rendendo il problema difficile da ricondurre subito a CSF.

Controlli finali e manutenzione ordinaria

Dopo l’installazione, i controlli finali non sono opzionali. Devi confermare che il firewall sia attivo, che il test di configurazione sia pulito, che le porte pubbliche siano quelle previste e che i servizi amministrativi siano accessibili solo dagli IP autorizzati. Se hai una dashboard di monitoraggio, osserva anche error rate e tentativi di connessione rifiutati nelle prime ore dopo il cambio: è il modo più rapido per scoprire un falso positivo o una regola mancante.

La manutenzione ordinaria consiste nel rivedere periodicamente whitelist, porte aperte e soglie di blocco. Un server cambia nel tempo: si spostano servizi, si aggiungono endpoint, cambiano gli IP di amministrazione e cambiano anche gli schemi di attacco. Un firewall che non viene rivisto diventa presto una fotografia vecchia della macchina.

Se devi aggiornare la configurazione, lavora sempre con backup e diff chiari. Il comportamento corretto è: salvi lo stato attuale, modifichi un solo blocco per volta, testi, applichi e verifichi. Se qualcosa non torna, il rollback deve essere immediato e documentato, non improvvisato. In un contesto operativo serio, la sicurezza non è il numero di opzioni attivate: è la capacità di sapere esattamente cosa sta facendo ogni regola e di tornare indietro senza perdere controllo del server.