Sicurezza server: hardening di base in 10 step

L hardening di un server e l'insieme di operazioni che riducono la superficie d'attacco dell'host. Seguendo dieci step di base si copre la stragrande maggioranza dei rischi noti: configurazioni di default, servizi superflui, password deboli, mancata segregazione dei privilegi. Vediamo una checklist applicabile su qualsiasi distribuzione Linux.

I 10 step di hardening

1. Aggiornamenti tempestivi: abilita patch di sicurezza automatiche (unattended-upgrades su Debian/Ubuntu, dnf-automatic su Rocky/Alma).
2. Utenti e sudo: disabilita login root via SSH, crea utenti nominali con privilegi sudo dedicati e password robuste.
3. SSH a chiavi pubbliche: PasswordAuthentication no, PubkeyAuthentication yes, AllowUsers admin, MaxAuthTries 3, eventuale 2FA con google-authenticator.
4. Firewall restrittivo: UFW o nftables con default deny incoming; aperture solo per le porte effettivamente necessarie.
5. fail2ban: regole per SSH, web, mail, pannelli amministrativi.
6. Servizi minimi: systemctl list-unit-files --state=enabled, disabilita cio che non serve (avahi, cups, bluetooth).
7. Kernel hardening: tune di sysctl (net.ipv4.tcp_syncookies=1, kernel.dmesg_restrict=1), abilita SELinux o AppArmor.
8. Logging e auditing: journald persistente, auditd per syscall sensibili, invio log a un server centralizzato (rsyslog, journald-forward, Loki).
9. Backup off-site cifrati: backup quotidiani con restic o Borg verso destinazione esterna.
10. Audit periodici: esegui Lynis mensilmente, controlla CVE delle versioni installate, ruota le chiavi SSH e segreti.

Strumenti consigliati

Per automatizzare il processo si usano playbook Ansible (roles come dev-sec.os-hardening) o Chef/Puppet. Lo standard di riferimento e il CIS Benchmark per la distribuzione adottata: applicalo gradualmente, testando ogni cambiamento. Per la verifica passiva ci sono OpenSCAP e Wazuh.

Procedura passo-passo operativa

1. Esegui Lynis sul sistema corrente e annota i warning.
2. Applica gli step 1-5 in un'orario di manutenzione.
3. Verifica la raggiungibilita SSH da una console alternativa prima di chiudere la sessione.
4. Procedi con gli step 6-7 dopo aver mappato i servizi necessari.
5. Imposta logging e backup (step 8-9).
6. Pianifica audit ricorrenti (step 10).

Errori comuni e come risolverli

• Cambiare configurazione SSH senza testare: tieni una sessione attiva mentre testi la nuova policy.
• Abilitare SELinux in enforcing senza policy: parti in permissive e analizza i denials.
• Affidarsi solo al firewall: e necessario ma non sufficiente, aggiungi WAF e fail2ban.
• Dimenticare la rotazione delle chiavi: pianifica audit semestrali.

Domande frequenti

D: Devo davvero cambiare la porta SSH?
R: Riduce il rumore di scan automatici ma non aumenta la sicurezza reale; le chiavi e fail2ban contano molto di più.

D: Quanto spesso fare audit?
R: Tecnici mensili, completi (terze parti) annuali per progetti critici.

D: 2FA su SSH e gestibile?
R: Si con google-authenticator o Yubikey; per team distribuiti vale l'investimento.

Approfondimento tecnico: CIS Benchmark e Lynis

I CIS Benchmark sono le checklist di sicurezza più autorevoli, sviluppate dal Center for Internet Security. Coprono RHEL, Ubuntu, Debian, CentOS Stream con centinaia di controlli classificati per livello (1 base, 2 avanzato). Esistono playbook Ansible aperti (es. ansible-lockdown) che applicano i controlli in modo idempotente. Lynis e l'auditor open source di facto: esegue centinaia di check e produce un hardening index da 0 a 100 con raccomandazioni concrete.

Per il kernel hardening, parametri sysctl rilevanti includono kernel.kptr_restrict=2, kernel.yama.ptrace_scope=2, net.ipv4.conf.all.rp_filter=1, kernel.unprivileged_bpf_disabled=1. Su SELinux/AppArmor inizia con permissive mode loggando le violazioni, poi passa a enforcing.

Scenari d'uso reali

Una società di consulenza certifica i suoi server clienti con CIS Level 1 + audit Lynis trimestrale: documentazione vendibile e riduzione concreta del rischio.

Un hosting WordPress applica hardening con ModSecurity, fail2ban, file integrity monitoring (AIDE) e backup immutabili: protezione layered contro le minacce più comuni.

Un server PCI-DSS per pagamenti deve passare ASV scan trimestrali: hardening rigoroso e prerequisito tecnico.

Checklist operativa di hardening

• Esegui Lynis e ottieni hardening index baseline.
• Applica CIS Benchmark Level 1 minimo, Level 2 dove possibile.
• Disabilita servizi non necessari (analisi con systemctl).
• Imposta password policy robusta + MFA per accessi privilegiati.
• Centralizza i log in un server SIEM.
• File integrity monitoring (AIDE, Tripwire).
• Audit trimestrale e rivalutazione delle eccezioni.

Risorse e riferimenti

CIS Benchmarks su cisecurity.org, OpenSCAP per audit automatizzato, Lynis su cisofy.com. Le linee guida NIST 800-53 e NIST 800-171 forniscono framework completo. Per ambienti enterprise, Wazuh SIEM open source integra HIDS, log analysis e compliance reporting.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su sicurezza server richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.