Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti

In un progetto per un'azienda del settore servizi digitali, sono stato chiamato dopo che un attaccante aveva ottenuto accesso root a un VPS Debian tramite brute force SSH - il server era configurato con autenticazione a password, porta 22 standard, nessun fail2ban, nessun firewall. L'attaccante aveva installato un cryptominer che saturava CPU e rete da tre settimane prima che qualcuno se ne accorgesse. Il server ospitava un applicativo gestionale con dati di clienti e fatturazione. Dopo il contenimento e il ripristino, abbiamo implementato un hardening completo: chiavi Ed25519, firewall UFW, fail2ban, aggiornamenti automatici, parametri kernel restrittivi. Nei due anni successivi, zero compromissioni.

Il Verizon Data Breach Investigations Report 2025 conferma che questo scenario non è un'eccezione: il 22% delle violazioni sfrutta credenziali rubate, il 20% vulnerabilità note non patchate, e il ransomware è presente nel 44% dei breach (in crescita dal 32% dell'anno precedente). Il tempo mediano di patching per le vulnerabilità critiche è di 32 giorni - un'eternità in cui il server resta esposto.

Cos'è l'hardening dei server e perché è la prima linea di difesa?

L'hardening è il processo sistematico di riduzione della superficie di attacco di un server: disabilitare servizi non necessari, configurare restrizioni di accesso, applicare parametri di sicurezza al kernel e al filesystem, e automatizzare gli aggiornamenti di sicurezza. L'obiettivo è trasformare un sistema operativo con configurazione di default - progettata per funzionare su qualsiasi scenario, quindi permissiva - in un sistema configurato per resistere specificamente alle minacce che affronta nel suo ruolo.

Per una PMI che gestisce applicativi web su VPS Debian o Ubuntu, l'hardening non è un optional tecnico - è un requisito operativo. I CIS Benchmarks, pubblicati dal Center for Internet Security, definiscono centinaia di controlli specifici per ogni distribuzione Linux (Debian 12 Benchmark v1.1.0, settembre 2024). Applicarli tutti non è sempre pratico, ma le categorie fondamentali - accesso SSH, firewall, aggiornamenti, kernel, filesystem - coprono la maggior parte dei vettori di attacco reali. Ho dettagliato un percorso di hardening specifico per server Debian e Ubuntu con applicativi PHP in un articolo dedicato.

SSH: la porta d'ingresso da blindare per prima

SSH è il servizio più esposto su un server Linux - è accessibile dall'esterno per definizione. La configurazione di default è troppo permissiva per un server di produzione:

Port 2222                              ; porta non standard (riduce log noise)
PermitRootLogin no                     ; mai accesso diretto come root
PasswordAuthentication no              ; solo chiavi crittografiche
PubkeyAuthentication yes               ; autenticazione a chiave pubblica
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3                         ; limita i tentativi
LoginGraceTime 30                      ; timeout connessione in secondi
AllowUsers deploy                      ; whitelist utenti esplicita
X11Forwarding no                       ; disabilita forwarding non necessario

La chiave è usare Ed25519 (ssh-keygen -t ed25519): offre sicurezza equivalente a RSA-3072 con chiavi più corte e operazioni più veloci. Disabilitare l'autenticazione a password elimina completamente il vettore brute force - un attaccante non può indovinare una chiave crittografica a 256 bit.

Fail2ban aggiunge un livello di difesa automatizzata: monitora i log di autenticazione e blocca temporaneamente gli IP che superano un numero configurabile di tentativi falliti. Anche con autenticazione a chiave, fail2ban è utile per ridurre il rumore nei log e il consumo di risorse causato da scanner automatizzati. Ho trattato la configurazione e il troubleshooting di fail2ban per applicazioni Laravel su VPS in un articolo specifico.

Firewall, kernel e filesystem: difesa in profondità

Il firewall è il secondo livello fondamentale. Su Debian 12 e Ubuntu 24.04, nftables è il backend kernel predefinito; UFW (Uncomplicated Firewall) ne fornisce un'interfaccia semplificata adeguata per la maggior parte dei VPS. La regola base: chiudere tutto, aprire solo ciò che serve (SSH sulla porta custom, HTTP/HTTPS, nient'altro).

I parametri kernel controllano il comportamento del sistema operativo a livello più basso. Una configurazione di hardening minima in /etc/sysctl.d/99-hardening.conf:

net.ipv4.tcp_syncookies = 1            ; protezione SYN flood
net.ipv4.conf.all.rp_filter = 1        ; reverse path filtering (anti-spoofing)
net.ipv4.conf.all.accept_redirects = 0 ; ignora ICMP redirect
net.ipv4.conf.all.send_redirects = 0   ; non inviare redirect
net.ipv4.ip_forward = 0                ; disabilita routing (non è un router)
net.ipv6.conf.all.accept_ra = 0        ; ignora router advertisement IPv6
kernel.randomize_va_space = 2           ; ASLR completo
fs.protected_hardlinks = 1             ; protezione hardlink
fs.protected_symlinks = 1              ; protezione symlink
kernel.kptr_restrict = 2               ; nascondi indirizzi kernel

Per il filesystem, le partizioni /tmp, /var/tmp e /dev/shm devono essere montate con le opzioni noexec,nosuid,nodev - questo impedisce l'esecuzione di binari da directory scrivibili, una tecnica comune negli exploit post-compromissione. La riga corrispondente in /etc/fstab:

tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev,size=2G 0 0

Aggiornamenti automatici: la difesa passiva indispensabile

Il 20% delle violazioni sfrutta vulnerabilità note con patch disponibili. Con un tempo mediano di patching di 32 giorni, ogni giorno senza aggiornamento è una finestra di esposizione. Il pacchetto unattended-upgrades su Debian e Ubuntu automatizza l'applicazione delle patch di sicurezza:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Mail "[email protected]";

Questa configurazione applica automaticamente solo le patch di sicurezza (non gli aggiornamenti generali che potrebbero introdurre regressioni), riavvia il server alle 4 di notte se necessario e notifica l'amministratore via email. Il rischio di un aggiornamento automatico che rompe qualcosa è infinitamente inferiore al rischio di un server non patchato esposto a CVE critiche.

Audit di sicurezza con Lynis

Verificare l'efficacia dell'hardening richiede strumenti specifici. Lynis è un tool open source di auditing che analizza la configurazione del sistema e produce un indice di hardening con suggerimenti operativi specifici. Un lynis audit system eseguito su un server appena installato restituisce tipicamente un punteggio tra 50 e 60 su 100; dopo un hardening completo, il target è superare 85.

Lynis verifica centinaia di controlli: permessi dei file, configurazione SSH, stato del firewall, parametri kernel, certificati TLS, log rotation, integrità dei pacchetti. Il report generato è la roadmap operativa per l'hardening - ogni warning indica un'azione specifica da intraprendere, con riferimento ai CIS Benchmark corrispondenti.

Errori frequenti nell'hardening dei server

L'errore più comune è applicare l'hardening una volta e dimenticarsene. La sicurezza è un processo continuo: nuove vulnerabilità vengono scoperte, nuovi servizi vengono installati, configurazioni vengono modificate per debugging e non ripristinate. Un audit Lynis trimestrale è il minimo per mantenere lo stato di hardening nel tempo.

Il secondo errore è hardenizzare il sistema operativo ignorando lo stack applicativo. Un server con SSH blindato ma un MySQL accessibile da remoto senza restrizioni, o un PHP-FPM che espone phpinfo(), ha una superficie di attacco ridotta solo parzialmente. L'hardening di MySQL e l'hardening applicativo per NIS2 sono complementi indispensabili.

Il terzo è non testare la configurazione. Un firewall che blocca SSH sulla porta custom, un fail2ban che banna l'IP dell'amministratore, un noexec su /tmp che impedisce a Composer di funzionare - sono problemi che si scoprono nel momento peggiore se non si testano in un ambiente controllato prima di applicarli in produzione.

L'hardening è un investimento a rendimento asimmetrico: poche ore di configurazione prevengono incidenti che costano giorni di downtime, perdita di dati e danni reputazionali. Per conoscere il mio approccio alla sicurezza dei sistemi, visita la mia pagina professionale. Se i tuoi server non sono mai stati sottoposti a un audit di sicurezza, o se vuoi verificare che l'hardening esistente sia adeguato alle minacce attuali, contattami per una consulenza dedicata - partiamo da un assessment del tuo stato attuale.