Come installare CSF su Debian 12 per proteggere il server

CSF (ConfigServer Security & Firewall) è una soluzione pratica per hardening e controllo del traffico su server Linux. Su Debian 12 il punto chiave non è solo l’installazione, ma verificare prima il backend firewall effettivo, perché Debian 12 usa nftables come stack moderno e CSF può lavorare con iptables tramite compatibilità o con integrazione adeguata a seconda del setup.

Se il server è in produzione, l’obiettivo non è “chiudere tutto”, ma ridurre l’esposizione senza interrompere SSH, pannelli, mail o servizi pubblici. Prima di toccare il firewall: capire quali porte devono restare aperte, da quali IP amministri il server e se hai accesso console fuori banda o KVM nel caso qualcosa vada storto.

Prima di installare: verifica del layer firewall

Su Debian 12 devi capire se il sistema usa nftables direttamente o se hai già regole iptables compatibili. Questo evita conflitti e lockout.

sudo nft list ruleset | head -n 40
sudo iptables -S 2>/dev/null | head -n 40
sudo systemctl status nftables --no-pager

Se vedi regole nftables già attive, non dare per scontato che CSF possa essere aggiunto senza impatto. Se il server è dietro un provider con firewall esterno o security group, considera quel layer prima del firewall locale: potresti vedere traffico bloccato fuori dal sistema, e CSF non risolverebbe nulla.

Controlla anche i servizi esposti:

sudo ss -tulpn

Annota porte e processi. Ti serve per costruire la whitelist minima: SSH, HTTP/HTTPS, mail, DNS, database solo se davvero esposti, e porte dei pannelli se presenti.

Installazione di CSF su Debian 12

La procedura classica consiste nel scaricare CSF, estrarlo e lanciare l’installer. Fallo solo dopo aver verificato che hai una sessione di accesso robusta e un piano di rollback.

cd /usr/src
sudo wget https://download.configserver.com/csf.tgz
sudo tar -xzf csf.tgz
cd csf
sudo sh install.sh

L’installer crea i binari in genere sotto /usr/local/csf/ e aggiunge gli script necessari. Al termine verifica che i file principali esistano:

ls -l /usr/local/csf/

Se il download fallisce, non inventare workaround: controlla connettività, DNS e TLS del server. Se l’installazione termina ma il firewall non parte, il problema spesso è la compatibilità con il backend o la presenza di regole preesistenti.

Configurazione iniziale: aprire solo ciò che serve

Il file principale è /etc/csf/csf.conf. Prima di modificarlo, fai un backup versionato:

sudo cp /etc/csf/csf.conf /etc/csf/csf.conf.bak.$(date +%F-%H%M)

Le impostazioni minime da controllare subito sono queste:

• TESTING: deve essere temporaneamente attivo durante i test iniziali, poi va disattivato.
• TCP_IN: porte in ingresso consentite.
• TCP_OUT: porte in uscita necessarie per aggiornamenti, mail, DNS, repository.
• UDP_IN: solo se servono servizi UDP pubblici.
• DENY_IP_LIMIT e parametri di rate limiting: valuta con cautela, perché possono bloccare client legittimi.

Apri il file e modifica solo il necessario. Esempio tipico per un web server con SSH, HTTP e HTTPS:

sudo nano /etc/csf/csf.conf

Valori indicativi da adattare al tuo caso:

TCP_IN = "22,80,443"
TCP_OUT = "20,21,22,25,53,80,443,587,993,995"
TESTING = "1"

Non prendere questi valori come universali. Se ospiti mail, DNS o pannelli, le porte cambiano. Se SSH è su porta diversa, inserisci quella reale prima di attivare il firewall.

Whitelist amministrativa e protezione da lockout

La parte più importante è non tagliarti fuori. Inserisci gli IP da cui amministri il server in /etc/csf/csf.allow oppure tramite gli strumenti CSF. Se hai IP statici, è la scelta più semplice; se hai IP dinamici, valuta una VPN o un accesso console alternativo.

sudo nano /etc/csf/csf.allow

Puoi anche gestire allow/deny con gli strumenti del pacchetto:

sudo csf -a 203.0.113.10 "admin office"
sudo csf -d 198.51.100.25 "temporary block"

Usa queste funzioni con disciplina: ogni eccezione va motivata e, se temporanea, rimossa. Un firewall pieno di eccezioni perde efficacia e diventa difficile da auditare.

Se gestisci più operatori, documenta gli IP autorizzati. Se lavori da rete variabile, non fare affidamento su una whitelist statica senza un canale di accesso alternativo.

Attivazione graduale e test

Con TESTING=1 CSF non applica in modo definitivo il blocco. Serve proprio per verificare che le regole non interrompano il servizio. Dopo aver salvato la configurazione, esegui il restart del firewall e controlla lo stato.

sudo csf -r
sudo csf -l
sudo csf -s

Verifica che il servizio sia attivo e che le regole risultino caricate. Se qualcosa non torna, controlla i log di CSF:

sudo tail -n 100 /var/log/lfd.log
sudo tail -n 100 /var/log/messages 2>/dev/null

Su Debian può essere utile anche interrogare il journal se il pacchetto integra systemd:

sudo journalctl -u csf -n 100 --no-pager

Testa dall’esterno le porte previste. Dal tuo client o da una rete esterna:

nmap -Pn -p 22,80,443 tuodominio.example

Atteso: solo le porte autorizzate devono risultare aperte. Se SSH non risponde, usa subito la console del provider o un accesso alternativo per correggere la configurazione.

Disattivazione di TESTING e messa in produzione

Solo quando hai confermato che l’accesso amministrativo è stabile e i servizi pubblici sono raggiungibili, imposta TESTING = "0". Questa è la vera attivazione operativa.

sudo sed -i 's/^TESTING = "1"/TESTING = "0"/' /etc/csf/csf.conf
sudo csf -r

Dopo il reload, ricontrolla la reachability. L’errore più comune è lasciare il firewall in modalità test e credere di essere protetti quando in realtà non lo sei pienamente. L’errore opposto è chiudere porte essenziali senza aver validato i flussi.

Se il server ospita un pannello di controllo, verifica anche le porte del pannello e degli agenti correlati. Se hai servizi mail, il test deve includere SMTP in ingresso e in uscita, IMAP/POP se usati, e la risoluzione DNS per l’invio.

Integrazione con l’anti-abuso LFD

CSF lavora insieme a LFD, il demone che monitora eventi e può bloccare IP sospetti. Questo è il pezzo utile per brute force, scansioni e pattern anomali, ma va tarato con attenzione per non colpire utenti legittimi.

Verifica che LFD sia attivo:

sudo systemctl status lfd --no-pager

Controlla i log per eventi di blocco e falsi positivi:

sudo grep -i "lfd" /var/log/lfd.log | tail -n 50

Per SSH, web login, mail e pannelli, imposta soglie coerenti con il tuo traffico. Se hai un sito con molti utenti dietro NAT, soglie troppo aggressive possono bloccare intere reti condivise. L’ottimizzazione va fatta osservando i log, non a sensazione.

Regole utili su un server web Debian 12

Un’installazione CSF fatta bene non è solo una lista di porte. Devi ragionare per servizio e per rischio.

• SSH: consenti solo IP amministrativi se possibile.
• HTTP/HTTPS: aperti al pubblico se il server ospita siti web.
• Mail: apri solo se il server invia o riceve posta.
• Database: non esporre mai su Internet se non strettamente necessario.
• FTP: meglio evitarlo; se presente, valuta alternative sicure.

Se il server è dietro reverse proxy o CDN, il firewall origin deve accettare solo gli IP del proxy/CDN sulle porte web. In quel caso la whitelist va costruita sui range del provider front-end, non sul traffico generico Internet.

Gestione dei blocchi e manutenzione

CSF mantiene una logica semplice: allow, deny, ignore, temporary blocks. La manutenzione quotidiana consiste nel controllare cosa è stato bloccato e capire se ci sono falsi positivi.

sudo csf -g 203.0.113.10
sudo csf -t
sudo csf -l

Usa csf -g per cercare un IP nei log e nello stato del firewall. csf -t mostra i blocchi temporanei. csf -l elenca le regole correnti. Sono i tre comandi che ti servono per un triage veloce.

Se devi rimuovere un blocco, fallo con attenzione e solo dopo aver capito il motivo:

sudo csf -dr 198.51.100.25

Non usare rimozioni di massa senza audit. Se c’è un attacco reale, rimuovere tutto annulla il vantaggio del firewall. Se invece il blocco è un falso positivo, correggi la soglia o l’eccezione, non solo il sintomo.

Rollback e piano di rientro

Ogni change firewall deve avere rollback. Il rollback minimo è ripristinare il file di configurazione salvato e ricaricare CSF. Se hai un backup del file originale, puoi tornare indietro in pochi secondi.

sudo cp /etc/csf/csf.conf.bak.YYYY-MM-DD-HHMM /etc/csf/csf.conf
sudo csf -r

Se il problema è più serio e il server resta irraggiungibile, usa la console del provider per disabilitare CSF o ripristinare accesso SSH. I dettagli dipendono dal provider e dalla distro, ma il principio è sempre lo stesso: avere un canale fuori banda prima di applicare un firewall restrittivo.

Se il pacchetto crea incompatibilità con il tuo stack di rete, puoi anche rimuoverlo, ma solo dopo aver ripristinato l’accesso amministrativo:

sudo sh /usr/local/csf/bin/removecsf

Usa questa strada solo se necessario e con un backup completo della configurazione.

Controllo finale operativo

Una configurazione CSF valida su Debian 12 deve soddisfare quattro condizioni: SSH raggiungibile dagli IP autorizzati, porte pubbliche attese aperte, porte non necessarie chiuse, LFD attivo e con log puliti da falsi positivi ripetuti.

Checklist minima:

1. Accesso admin: SSH funziona dalla tua rete autorizzata.
2. Servizi pubblici: HTTP/HTTPS rispondono correttamente.
3. Log: nessun blocco anomalo dei servizi legittimi in /var/log/lfd.log.
4. Stato: csf -s mostra firewall attivo e coerente con la policy.

Se un servizio non risponde dopo l’attivazione, non partire dalla disinstallazione. Parti da: porta prevista, IP sorgente, log CSF, log del servizio, eventuali regole del provider esterno. Quasi sempre il problema è in uno di questi livelli.

Assunzione operativa: il server espone almeno SSH e servizi web; le porte aggiuntive vanno aperte solo se richieste dal tuo stack reale e dopo aver verificato il piano di rollback.

Quando CSF non basta

CSF è utile, ma non sostituisce hardening di sistema, patching, gestione degli account, MFA, backup e monitoraggio. Se il server ha servizi esposti con credenziali deboli o software non aggiornato, il firewall riduce la superficie ma non risolve il problema alla radice.

Su Debian 12 conviene affiancare CSF a:

• aggiornamenti regolari di sicurezza;
• SSH con chiavi e, se possibile, accesso limitato per IP;
• disabilitazione di servizi inutili;
• monitoraggio dei log e alert sui blocchi ripetuti;
• backup testati e ripristinabili.

Se vuoi una protezione consistente, CSF deve stare dentro una strategia, non al posto della strategia. Il firewall è uno strato, non il sistema di sicurezza completo.