Server hardening
Il server hardening è il lavoro che trasforma una configurazione di default in una configurazione difendibile: riduce la superficie di attacco, limita i privilegi e rende visibile quello che accade. Rackone lo applica a hypervisor Proxmox VE, sistemi operativi e web server esposti, con una baseline documentata e verificata nel tempo, come Proxmox Gold Partner #1 in Italia.
Senza impegno · Ti risponde un sistemista, non un commerciale
- 700+ clienti attivi
- H24 supporto in italiano
- GDPR dati in Italia
Server hardening: perché la configurazione di fabbrica non basta
Un server appena installato è configurato per funzionare, non per resistere a un attacco. Distribuzioni e hypervisor arrivano con servizi attivi che nessuno userà, permessi più larghi del necessario, protocolli legacy abilitati per compatibilità e interfacce di gestione raggiungibili da chiunque sia sulla stessa rete. È una scelta ragionevole di chi produce il software, che deve partire al primo avvio in qualsiasi contesto; diventa un problema quando quel server entra in produzione e ci resta per cinque anni.
L'hardening si muove su tre assi:
- Ridurre la superficie di attacco: se un servizio non serve si spegne, se una porta non deve rispondere si chiude. Ogni componente attivo è codice che può contenere una vulnerabilità.
- Limitare i privilegi: utenti, processi e macchine virtuali hanno i permessi che servono al loro lavoro, e niente di più. Un accesso compromesso deve valere poco.
- Rendere visibile quello che accade: log centralizzati, audit degli accessi amministrativi, notifiche sugli eventi anomali. Un attacco che nessuno vede ha tutto il tempo di riuscire.
Non è un intervento che si fa una volta e si archivia: è una baseline documentata, applicata in modo uniforme su tutti i sistemi e verificata nel tempo, perché ogni aggiornamento, ogni nuovo servizio e ogni deroga concessa «solo per oggi» riportano il sistema verso la configurazione di partenza.
Come lavoriamo: le cinque fasi del server hardening
- Assessment: la fotografia dello stato attuale, cioè inventario dei sistemi, servizi esposti, versioni e livello di patch, utenze amministrative, regole firewall, gestione dei backup. Ne esce un report con le criticità ordinate per rischio e per sforzo di correzione.
- Baseline: si concorda lo standard di riferimento (CIS Benchmark, indicazioni del produttore, requisiti normativi) e si decide che cosa si applica davvero al contesto. Una baseline copiata senza adattarla rompe le applicazioni.
- Remediation: le configurazioni si applicano per gradi, in finestre concordate: prima gli interventi ad alto impatto e basso rischio, poi quelli che chiedono test applicativi.
- Verifica: rilettura dei sistemi, vulnerability assessment, test dei ripristini da backup. Quello che non si verifica non è stato fatto.
- Mantenimento: patch, revisione periodica delle deroghe, sistemi nuovi che nascono già conformi alla baseline, anche con l'assistenza sistemistica continuativa.
Hardening di Proxmox VE
L'hypervisor è il punto più sensibile dell'infrastruttura: chi ottiene l'accesso amministrativo al nodo ottiene tutte le macchine virtuali che ci girano sopra, i loro dischi e, se i backup non sono isolati, anche le copie. Proxmox VE ha gli strumenti per una configurazione robusta, ma di serie privilegia la semplicità di installazione: il lavoro è chiudere quello che l'installer lascia aperto.
Come Proxmox Gold Partner e Authorized Training Partner lavoriamo sulla piattaforma ogni giorno, e conosciamo il comportamento reale di ogni impostazione, comprese quelle che sulla carta sembrano innocue e in cluster creano problemi.
Checklist di hardening di Proxmox VE
| Area | Che cosa si fa |
|---|---|
| Separazione delle reti | Reti distinte per gestione, cluster (Corosync), storage e traffico delle VM; Corosync su una rete dedicata a bassa latenza, con link ridondato e mai in comune con lo storage; VLAN, e rete di gestione raggiungibile solo da postazioni amministrative o da un bastion host |
| Accesso alla gestione | Interfaccia web mai pubblicata su Internet, ma raggiungibile via VPN o dietro un reverse proxy con autenticazione a monte; servizi di gestione solo sull'interfaccia dedicata; certificati TLS validi (ACME o CA interna) al posto dell'autofirmato; SSH con chiavi, senza login diretto di root, limitato per sorgente e protetto dai tentativi ripetuti |
| Identità e privilegi | Active Directory o LDAP con account nominali, e root@pam solo come accesso di emergenza; autenticazione a due fattori (TOTP o WebAuthn) obbligatoria per gli amministratori; permessi sui ruoli di Proxmox, per pool e per risorsa; revisione periodica di utenze, token API e deroghe |
| Firewall integrato | Firewall di Proxmox VE attivo su datacenter, nodo e singola VM o container, con politica di default deny; regole esplicite per i servizi di cluster e per l'accesso amministrativo; security group riutilizzabili per profilo di macchina; piano di gestione protetto dal traffico delle VM |
| Aggiornamenti e repository | Sottoscrizione attiva e repository enterprise, con pacchetti validati più a lungo del repository no-subscription; patching con finestre, ordine dei nodi, verifica e rollback; host senza pacchetti e servizi inutili: è un hypervisor, non un server tuttofare |
| Cluster e quorum | Quorum configurato bene, con un QDevice dove il numero di nodi lo chiede; fencing e alta disponibilità testati, non solo configurati; procedure di manutenzione scritte, perché un intervento urgente non si improvvisa |
| Cifratura e storage | Dati cifrati a riposo dove il rischio o la norma lo chiedono (LUKS, cifratura nativa di ZFS); credenziali di accesso agli storage separate, un account per sistema; dischi dismessi con una procedura di cancellazione sicura |
| Backup con PBS | Proxmox Backup Server separato dall'hypervisor, con credenziali proprie e senza fiducia reciproca; namespace e permessi granulari; copia fuori sede e copia di ultima istanza su un supporto non riscrivibile, secondo la regola 3-2-1; verifica automatica dell'integrità e test di ripristino reali |
| Log, audit e notifiche | Log su un collettore esterno o un SIEM, perché quelli rimasti sul sistema compromesso non servono a nessuno; tracciamento delle operazioni amministrative e delle modifiche al cluster; notifiche su backup falliti, storage degradato, quorum perso, accessi anomali |
| VM e container | Container LXC non privilegiati, l'impostazione predefinita di Proxmox VE, con i profili AppArmor attivi; template già rafforzati, così ogni nuova VM nasce conforme; hardening dei sistemi guest, che resta una responsabilità distinta da quella dell'hypervisor |
Hardening dei web server e Web Application Firewall
Il web server è il servizio che quasi sempre resta esposto su Internet, e riceve traffico ostile di continuo: dai bot che scandagliano tutto quello che risponde sulla porta 443 agli attacchi mirati contro l'applicazione. Metterlo in sicurezza chiede due livelli di lavoro: il server e il servizio (configurazione, privilegi, TLS, controllo del traffico), poi l'applicazione, dove interviene il Web Application Firewall (WAF), che ispeziona le richieste HTTP e blocca quelle che corrispondono a schemi di attacco noti.
I due livelli non sono alternativi: un WAF davanti a un web server configurato male mette una toppa su un problema che resta, e un web server configurato bene non protegge da una SQL injection nel codice dell'applicazione.
Checklist di hardening del web server e del WAF
| Livello | Che cosa si fa |
|---|---|
| Base del servizio | Versioni supportate di Nginx o Apache, moduli inutili spenti; servizio con un'utenza non privilegiata, permessi del filesystem coerenti, processo isolato con le funzioni di systemd; via cartella di default, pagine di test e numeri di versione da risposte e pagine di errore; siti separati, così un'applicazione compromessa non apre le altre |
| TLS e certificati | Solo TLS 1.2 e 1.3, suite di cifratura scelte, protocolli obsoleti spenti; HSTS, redirect da HTTP a HTTPS, OCSP stapling; emissione e rinnovo dei certificati automatici, con la scadenza sotto controllo |
| Header di sicurezza | Content Security Policy costruita sull'applicazione reale, non copiata da un esempio; X-Content-Type-Options, Referrer-Policy, Permissions-Policy e framing controllato con frame-ancestors; cookie con Secure, HttpOnly e SameSite impostati bene |
| Controllo del traffico | Rate limiting per IP e per endpoint, più stretto su login e API; limiti alla dimensione delle richieste e timeout tarati contro le connessioni lente; filtro dei bot, reputazione delle sorgenti, blocchi geografici dove hanno senso; protezione anti DDoS a monte quando la disponibilità è un requisito stringente |
| Il WAF | ModSecurity o Coraza con l'OWASP Core Rule Set (injection, cross-site scripting, path traversal, inclusione di file, upload malevoli); prima in sola rilevazione, poi tuning sul traffico reale, e solo dopo il blocco; livello di paranoia calibrato, con esclusioni mirate e documentate; regole su misura e virtual patching; attenzione a gestionali e CMS con componenti di terze parti |
| Architettura | WAF su un reverse proxy dedicato davanti a più applicazioni, che centralizza regole, certificati e log, oppure WAF gestito, erogato come servizio da Rackone; indirizzo IP originale del client preservato fino all'applicazione, altrimenti log e blocchi diventano inutilizzabili |
| Log e reazione | Audit log del WAF conservati e correlati con quelli del web server e dell'applicazione; inoltro a un SIEM, con alert sugli schemi che contano e non su ogni regola scattata; regole riviste dopo ogni rilascio, perché un'applicazione che cambia produce falsi positivi nuovi |
Il virtual patching, cioè il blocco sul WAF di una vulnerabilità nota mentre si aspetta la patch del fornitore, è lo scenario in cui il WAF vale di più: copre la finestra fra la pubblicazione dell'exploit e l'aggiornamento del software. Un WAF messo in blocco il primo giorno, invece, genera falsi positivi e finisce per essere disattivato.
Server hardening: che cosa ricevi
- report di assessment con le criticità classificate per rischio;
- baseline di configurazione documentata, riutilizzabile sui sistemi futuri;
- piano di remediation con priorità, tempi e impatto sui servizi;
- interventi eseguiti in finestre concordate;
- verifica finale e documentazione aggiornata dell'infrastruttura.
In opzione: gestione continuativa, monitoraggio, aggiornamento delle regole del WAF, vulnerability assessment periodici e formazione del team interno con i corsi ufficiali Proxmox.
Vuoi sapere quanto è esposta la tua infrastruttura?
Hardening e obblighi normativi: NIS2, DORA, GDPR e ISO 27001
La normativa raramente prescrive impostazioni tecniche puntuali: chiede misure adeguate al rischio, e chiede di poterlo dimostrare. Una baseline di hardening documentata, applicata in modo uniforme e verificata nel tempo è l'evidenza che serve quando arriva un audit o quando un incidente va notificato.
- NIS2: il decreto legislativo 138/2024, che la recepisce in Italia, chiede ai soggetti essenziali e importanti misure che comprendono la sicurezza della manutenzione dei sistemi con la gestione delle vulnerabilità, l'igiene informatica di base, la crittografia, il controllo degli accessi e l'autenticazione a più fattori (articolo 24, comma 2, lettere e, g, h, i, l).
- DORA: il regolamento (UE) 2022/2554, applicabile dal 17 gennaio 2025, chiede alle entità finanziarie politiche su accessi, autenticazione forte, gestione delle modifiche, patch e aggiornamenti (articolo 9), e porta requisiti di sicurezza nei contratti con i loro fornitori ICT.
- GDPR: l'articolo 32 chiede misure tecniche adeguate al rischio e una procedura per testare, verificare e valutare regolarmente la loro efficacia.
- ISO/IEC 27001: i controlli sulla gestione delle vulnerabilità tecniche e delle configurazioni (Allegato A, 8.8 e 8.9); per la pubblica amministrazione, anche i requisiti di sicurezza che le chiedono le norme italiane.
Il server hardening aiuta a soddisfare queste misure, non le sostituisce: la conformità resta un percorso dell'organizzazione. Rackone è certificata ISO 9001 e ISO/IEC 27001.
Gestisci server per conto dei tuoi clienti?
L'hardening si fa anche in subfornitura, in white-label, con il nostro team alle spalle. Non contattiamo mai i tuoi clienti finali.
Domande frequenti sul server hardening
Il server hardening rallenta i sistemi?
No, nella maggior parte dei casi il server hardening non rallenta i sistemi. Alcuni controlli hanno un costo misurabile, come i log dettagliati o l'ispezione delle richieste da parte del WAF; la maggior parte no. Il punto è tarare le misure sul rischio reale del servizio: una baseline si adatta al contesto, non si applica alla cieca.
Per il server hardening serve fermare la produzione?
No, il server hardening non chiede di fermare la produzione: buona parte degli interventi si applica a caldo. Quelli che richiedono un riavvio si concentrano in finestre concordate, e le configurazioni si applicano per gradi, prima quelle ad alto impatto e basso rischio, poi quelle che chiedono test applicativi.
Ho già un firewall perimetrale: il server hardening serve lo stesso?
Sì, il server hardening serve anche con un firewall perimetrale. Il firewall filtra il traffico verso il servizio, ma non protegge dalla configurazione debole del servizio stesso, né dagli attacchi che passano su porte legittime, come la 443 di un web server. Hardening e firewall lavorano su livelli diversi, e servono tutti e due.
Un WAF sostituisce la correzione del codice?
No, un WAF non sostituisce la correzione del codice. Il Web Application Firewall guadagna tempo e blocca gli attacchi automatizzati, anche con il virtual patching di una vulnerabilità nota, ma la vulnerabilità resta nell'applicazione finché non viene corretta. Il WAF copre la finestra fra la scoperta del problema e l'aggiornamento del software.
Ogni quanto va rivista la baseline di server hardening?
La baseline di server hardening va rivista almeno una volta l'anno e a ogni cambiamento rilevante dell'infrastruttura: un nuovo servizio esposto, un aggiornamento importante, una migrazione. Nel mezzo contano la gestione delle patch e la revisione periodica delle deroghe, perché ogni eccezione concessa «solo per oggi» tende a diventare permanente.
Partiamo da una fotografia dello stato attuale
Un assessment iniziale dice in modo oggettivo dove sei e che cosa conviene affrontare per primo. Da lì costruiamo un piano che tiene conto dei tuoi vincoli operativi, non un elenco teorico di buone pratiche. Il resto della protezione è nella sezione Cyber Security.
Senza impegno · Ti risponde un sistemista, non un commerciale