--- title: "Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti" description: "L'hardening dei server è essenziale per prevenire attacchi informatici devastanti. Scopri perché devi adottarlo immediatamente nella tua azienda." canonical: "https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html" author: "Maurizio Fonte" date: "2025-05-22T09:05:47+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Informatica" tags: ["Sicurezza Informatica", "Linux & Server"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) # [Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html) Giovedì 22 Mag 2025, alle 09:05 ![Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/image/001250200-hardening-server-protezione-attacchi-informatici.jpg) 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](https://www.verizon.com/business/resources/reports/dbir/) 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](https://www.cisecurity.org/benchmark/debian_linux), 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](https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html) 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: ```text 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](https://github.com/fail2ban/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](https://www.mauriziofonte.it/blog/post/fail2ban-emergenza-vps-laravel-intervento-rapido.html) 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`: ```ini 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`: ```text 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: ```text Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; }; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "04:00"; Unattended-Upgrade::Mail "admin@example.com"; ``` 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](https://cisofy.com/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](https://www.mauriziofonte.it/blog/post/hardening-urgente-mysql-laravel-vps.html) e l'[hardening applicativo per NIS2](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html) 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](https://www.mauriziofonte.it/pages/about). 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](https://www.mauriziofonte.it/pages/contattami) - partiamo da un assessment del tuo stato attuale. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteKubernetes per applicativi PHP: dal manifest all'autoscaling22 Mag 2025](https://www.mauriziofonte.it/blog/post/kubernetes-orchestrazione-container-vantaggi-azienda.html)[Articolo successivo »Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto23 Mag 2025](https://www.mauriziofonte.it/blog/post/rischi-codice-obsoleto-php8-vantaggi-sicurezza-performance.html) ### Articoli correlati a Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti - [Configurare firewall avanzati con nftables su VPS gestite senza personale tecnico qualificato: guida operativa Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/configurare-firewall-nftables-vps-senza-personale-tecnico.html) Un VPS con MySQL esposto su porta 3306 a tutto internet e nessun firewall attivo: 23.000 tentativi di connessione in 48 ore. Configuro nftables · 11 Luglio 2025 ![Configurare firewall avanzati con nftables su VPS gestite senza personale tecnico qualificato: guida operativa Debian e Ubuntu](https://www.mauriziofonte.it/image/002070070-configurare-firewall-nftables-vps-senza-personale-tecnico.jpg) - [Server Debian e Ubuntu per applicativi PHP: perché l'hardening è cruciale per la sicurezza dei software gestionali e e-commerce delle PMI](https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html) Il tuo applicativo PHP poggia su un server Debian o Ubuntu: quanto è sicuro? L'hardening specifico per lo stack PHP PHP FPM, web server, permessi, · 29 Gennaio 2025 ![Server Debian e Ubuntu per applicativi PHP: perché l'hardening è cruciale per la sicurezza dei software gestionali e e-commerce delle PMI](https://www.mauriziofonte.it/image/001310070-hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.jpg) - [Gestione urgente di intrusioni su VPS: guida al ripristino rapido e sicuro per server Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/gestione-urgente-intrusioni-vps-unmanaged-debian-ubuntu.html) VPS compromesso: CPU al 100 , login SSH a forza bruta riusciti, un cryptominer nascosto in /dev/shm camuffato da thread del kernel. Il playbook · 8 Luglio 2025 ![Gestione urgente di intrusioni su VPS: guida al ripristino rapido e sicuro per server Debian e Ubuntu](https://www.mauriziofonte.it/image/002010070-gestione-urgente-intrusioni-vps-unmanaged-debian-ubuntu.jpg) - [Le 5 CVE che devi aver patchato sul VPS entro ottobre 2026](https://www.mauriziofonte.it/blog/post/cve-2026-da-patchare-vps-linux-ottobre.html) Due CVE del kernel Linux sono entrate nel catalogo delle vulnerabilità attivamente sfruttate della CISA nel 2026, e altre tre hanno exploit pubblici · 8 Ottobre 2026 ![Le 5 CVE che devi aver patchato sul VPS entro ottobre 2026](https://www.mauriziofonte.it/image/005660070-cve-2026-da-patchare-vps-linux-ottobre.jpg) - [Perché dopo l'upgrade a Debian 13 il backup notturno fallisce con /tmp in RAM](https://www.mauriziofonte.it/blog/post/tmp-tmpfs-debian-13-backup-notturno-fallisce-no-space-left.html) L'upgrade a Debian 13 è andato liscio, i servizi sono ripartiti, e giorni dopo il backup notturno muore con No space left on device mentre il · 6 Ottobre 2026 ![Perché dopo l'upgrade a Debian 13 il backup notturno fallisce con /tmp in RAM](https://www.mauriziofonte.it/image/005640070-tmp-tmpfs-debian-13-backup-notturno-fallisce-no-space-left.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html Pubblicato: 2025-05-22 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.