Problemi affrontati
- I server mantenevano impostazioni predefinite non riviste: servizi superflui attivi e accessi amministrativi troppo permissivi.
- I log restavano sui singoli host e andavano persi in caso di guasto, riavvio o manomissione.
- I tentativi ripetuti di accesso non venivano rilevati né limitati.
- Mancava una baseline verificabile: ogni server era configurato a mano, con differenze difficili da individuare.
Soluzione implementata
È stata definita una baseline di hardening applicata in modo uniforme ai server Debian: accesso SSH solo con chiavi, privilegi amministrativi limitati a un gruppo, servizi non necessari disattivati e aggiornamenti di sicurezza automatici. Un firewall nftables con politica restrittiva in ingresso e fail2ban contro i tentativi ripetuti completano la difesa a livello di host. I log di journald vengono inoltrati con rsyslog, su canale cifrato, a un collettore centrale con conservazione e rotazione definite. Prometheus monitora lo stato dei servizi e del flusso dei log e genera un avviso quando un host smette di inviare eventi.
Risultati
- I server condividono una configurazione di base coerente e verificabile, con meno differenze da un host all'altro.
- Gli eventi di sicurezza si consultano in un unico punto, anche dopo il riavvio o il guasto dell'host che li ha generati.
- I tentativi ripetuti di accesso vengono rallentati in modo automatico.
- L'assenza di log da un host genera un avviso, segnalando guasti o possibili manomissioni.
Descrizione tecnica
L'hardening riduce la superficie d'attacco dei singoli server; i log centralizzati permettono di accorgersi di ciò che accade e di ricostruirlo dopo un incidente. Questo progetto unisce le due attività in una baseline unica, applicata in modo uniforme e verificabile. Per scelta, le impostazioni di sicurezza non sono riportate nel dettaglio.
Baseline di hardening
La baseline riguarda i server Debian e si compone di pochi principi:
- accesso amministrativo via SSH solo con chiavi, senza login diretto dell'utente root e limitato a un gruppo dedicato;
- servizi superflui disattivati e porte in ascolto ridotte a quelle necessarie;
- firewall nftables con politica predefinita restrittiva in ingresso e sole eccezioni documentate;
- fail2ban contro i tentativi ripetuti di accesso, con esclusione del segmento di gestione per non bloccare l'amministratore;
- aggiornamenti di sicurezza automatici e orologi sincronizzati, requisito essenziale per correlare gli eventi.
Una checklist per SSH è nell'articolo Hardening di SSH su Debian: checklist pratica. La baseline è descritta come codice, con ruoli Ansible, e applicata ai nuovi server già al momento della creazione: gli scostamenti diventano differenze visibili tra versioni.
Pericolo
Prima di restringere SSH o il firewall, tenere aperta una sessione amministrativa già autenticata e verificare l'accesso da una seconda sessione: un errore può precludere l'accesso remoto al server.
Log centralizzati
Su ogni server journald conserva i log di sistema in modo persistente e li rende disponibili a rsyslog, che li inoltra a un collettore centrale su canale cifrato TLS. Il collettore li archivia per host, applica rotazione e conservazione e li rende consultabili anche se l'host d'origine è fermo o compromesso.
action(type="omfwd" target="logs.example.com" port="6514" protocol="tcp"
StreamDriver="gtls" StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="logs.example.com"
action.resumeRetryCount="-1"
queue.type="LinkedList" queue.filename="inoltro" queue.saveOnShutdown="on")La coda su disco evita perdite durante le interruzioni del collettore. Prometheus raccoglie metriche sullo stato dei servizi e del flusso dei log: un avviso scatta quando un host smette di inviare eventi, segno di un guasto o di una manomissione. Un riferimento è Prometheus e Grafana in LXC.
I log contengono dati sensibili: il collettore è quindi raggiungibile solo dal segmento di gestione e i dati sono conservati per il tempo strettamente necessario. Gli orologi sincronizzati permettono di ordinare su un'unica linea temporale gli eventi di host diversi.
Verifiche e collaudo
La baseline si controlla con verifiche ripetibili: elenco delle porte in ascolto, prova dell'accesso con e senza chiavi, simulazione di accessi falliti per verificare l'intervento di fail2ban, invio di un evento di prova fino al collettore e controllo dell'avviso quando l'invio viene interrotto.
Possibili evoluzioni
Audit di sistema con auditd, rilevazione delle modifiche ai file critici, analisi automatica dei log e verifica periodica della conformità rispetto a una baseline di riferimento.