--- title: "Server Debian e Ubuntu per applicativi PHP: perché l'hardening è cruciale per la sicurezza dei software gestionali e e-commerce delle PMI" description: "L'hardening dei server Debian/Ubuntu è la prima difesa per gli applicativi PHP della tua PMI. Scopri le pratiche essenziali per proteggere gestionali ed e-commerce." canonical: "https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html" author: "Maurizio Fonte" date: "2025-01-29T14:29:41+01:00" modified: "2026-04-14T17:48:55+02:00" section: "Linux & Server" tags: ["Linux & Server", "Sicurezza Informatica"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) # [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) Mercoledì 29 Gennaio 2025, alle 14:29 ![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/001310200-hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.jpg) In un progetto per un'azienda del settore servizi digitali, l'e-commerce Laravel serviva centinaia di ordini al giorno su un VPS Debian 11 con configurazione di default: PHP-FPM girava come `www-data` con tutti i pool che condividevano lo stesso utente, `open_basedir` non era configurato, `disable_functions` era vuoto, Nginx esponeva la versione del server negli header di risposta, e nessun security header HTTP era impostato. Un attaccante che avesse sfruttato una qualsiasi vulnerabilità applicativa avrebbe ottenuto accesso a tutti i file del server, non solo a quelli dell'applicativo. Dopo l'hardening - pool PHP-FPM isolati, `open_basedir` restrittivo, funzioni pericolose disabilitate, security headers completi, permessi filesystem corretti - la superficie di attacco si è ridotta drasticamente. L'[hardening a livello di sistema operativo](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html) (SSH, kernel, firewall, aggiornamenti automatici) è il prerequisito; questo articolo si concentra sullo strato applicativo specifico per PHP. ## Quali sono le aree critiche di hardening per un server che ospita applicativi PHP? Un server Debian o Ubuntu che ospita applicativi PHP presenta una superficie di attacco su tre livelli: il sistema operativo, lo stack web (Nginx/Apache + PHP-FPM) e l'applicativo stesso. L'hardening del sistema operativo - accesso SSH con chiavi Ed25519, firewall UFW/nftables, parametri kernel restrittivi, aggiornamenti automatici con `unattended-upgrades` - è trattato nella [guida all'hardening dei server](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html). Lo strato specifico per PHP riguarda la configurazione di PHP-FPM, il web server, i permessi del filesystem, e gli header HTTP di sicurezza - aree che spesso vengono ignorate perché "l'applicativo funziona" con la configurazione di default. Il [Verizon DBIR 2025](https://www.verizon.com/business/resources/reports/dbir/) conferma che il 20% delle violazioni sfrutta vulnerabilità note in componenti non aggiornati o mal configurati. Per una PMI, un server con PHP-FPM in configurazione di default che ospita un gestionale con dati di clienti e fatturazione rappresenta un rischio concreto: una vulnerabilità in una dipendenza Composer, o un file di upload non validato, può dare all'attaccante accesso non solo all'applicativo, ma all'intero server. ## PHP-FPM: isolamento dei pool e restrizioni di sicurezza La [configurazione di PHP-FPM](https://www.php.net/manual/en/install.fpm.configuration.php) è il punto di intervento con il maggiore impatto sulla sicurezza dello stack PHP. Le impostazioni critiche nel file pool del sito (tipicamente `/etc/php/8.3/fpm/pool.d/site.conf`): ```ini [site] user = site_user ; utente dedicato per ogni applicativo group = site_group listen = /run/php/php8.3-fpm-site.sock listen.owner = www-data listen.group = www-data listen.mode = 0660 pm = dynamic pm.max_children = 20 pm.start_servers = 5 pm.min_spare_servers = 3 pm.max_spare_servers = 10 php_admin_value[open_basedir] = /var/www/site/:/tmp/:/var/lib/php/sessions/ php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,pcntl_exec php_admin_value[upload_max_filesize] = 10M php_admin_value[post_max_size] = 12M php_admin_flag[expose_php] = off security.limit_extensions = .php ``` I punti chiave: ogni applicativo ha un utente di sistema dedicato (non `www-data` condiviso), `open_basedir` limita l'accesso al filesystem alla sola directory dell'applicativo, `disable_functions` rimuove le funzioni che permettono esecuzione di comandi di sistema (adattare la lista in base alle reali necessità dell'applicativo - Laravel non usa `exec` per default, ma alcune dipendenze potrebbero), `expose_php = off` nasconde la versione PHP negli header, e `security.limit_extensions` impedisce l'esecuzione di file con estensioni diverse da `.php`. ## Web server e security headers HTTP Il web server (Nginx o Apache) è il componente direttamente esposto a Internet. La configurazione di sicurezza minima per Nginx include la rimozione dell'header di versione e l'implementazione dei [security headers](https://owasp.org/www-project-secure-headers/) raccomandati da OWASP: ```text server { listen 443 ssl http2; server_name example.com; server_tokens off; ; nasconde versione Nginx ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; add_header X-Frame-Options "SAMEORIGIN" always; ; previene clickjacking add_header X-Content-Type-Options "nosniff" always; ; previene MIME sniffing add_header X-XSS-Protection "0" always; ; disabilita filtro XSS legacy add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; location ~ \.php$ { fastcgi_pass unix:/run/php/php8.3-fpm-site.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_hide_header X-Powered-By; ; nasconde header PHP } location ~ /\. { deny all; } ; blocca accesso a dotfiles location ~ /vendor/ { deny all; } ; blocca accesso a vendor/ location ~ /storage/logs/ { deny all; } ; blocca accesso ai log Laravel } ``` Il [Mozilla SSL Configuration Generator](https://ssl-config.mozilla.org/) genera configurazioni TLS ottimali per Nginx e Apache in base al profilo di compatibilità scelto (Modern, Intermediate, Old). L'[Observatory di Mozilla](https://developer.mozilla.org/en-US/observatory) verifica la completezza dei security headers di un sito in produzione. Per i permessi del filesystem, la regola base è: il web server legge, l'applicativo scrive solo dove necessario. I file dell'applicativo devono appartenere all'utente del pool PHP-FPM con permessi `644` per i file e `755` per le directory. La directory `storage/` e `bootstrap/cache/` (in Laravel) devono essere scrivibili dall'utente del pool ma non dal web server direttamente. ## Audit di sicurezza e manutenzione continua Verificare l'efficacia dell'hardening richiede strumenti specifici. [Lynis](https://cisofy.com/lynis/) analizza la configurazione del sistema e produce un indice di hardening con suggerimenti operativi - un server appena installato restituisce tipicamente un punteggio tra 50 e 60 su 100, dopo un hardening completo il target è superare 85. I [CIS Benchmarks](https://www.cisecurity.org/benchmark/debian_linux) per Debian e Ubuntu definiscono centinaia di controlli specifici con livelli di priorità. L'hardening non è un'operazione una tantum. 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. L'[osservabilità minima per applicazioni PHP legacy](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html) - logging strutturato, metriche operative e alert - è il complemento che trasforma l'hardening da difesa statica a difesa attiva. L'integrazione con il [checklist di hardening NIS2 per Laravel e Symfony](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html) copre anche gli aspetti di compliance normativa. L'hardening dello stack PHP è un investimento a rendimento asimmetrico: poche ore di configurazione prevengono incidenti che costano giorni di downtime e danni reputazionali. La sicurezza applicativa delle [API REST del gestionale](https://www.mauriziofonte.it/blog/post/api-rest-gestionali-laravel-sicurezza-pmi-vulnerabilita-legacy.html) e l'hardening del server su cui gira sono due facce della stessa medaglia - nessuna delle due è sufficiente da sola. Per conoscere il mio approccio alla sicurezza dei sistemi Linux e degli applicativi PHP, 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 specifico per lo stack PHP, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'analisi della configurazione 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 precedenteApplicativi Symfony e debito tecnico nelle PMI: come passare dalla configurazione legacy dei servizi all'efficienza di autowiring e attributi in Symfony 6 e 728 Gennaio 2025](https://www.mauriziofonte.it/blog/post/applicativi-symfony-pmi-debito-tecnico-configurazione-servizi-autowiring-attributi.html)[Articolo successivo »Applicativi PHP, GDPR e NIS2: come la tua PMI può garantire compliance e sicurezza con Laravel e Symfony30 Gennaio 2025](https://www.mauriziofonte.it/blog/post/applicativi-php-gdpr-nis2-pmi-compliance-sicurezza-laravel-symfony.html) ### Articoli correlati a Server Debian e Ubuntu per applicativi PHP: perché l'hardening è cruciale per la sicurezza dei software gestionali e e-commerce delle PMI - [Ansible per PMI: automatizzare il provisioning di VPS Linux senza DevOps dedicato](https://www.mauriziofonte.it/blog/post/ansible-provisioning-vps-linux-pmi-senza-devops.html) Ogni nuovo cliente porta un VPS da configurare: PHP, Nginx, MariaDB, certificati, cron, backup. Ripetere questi passaggi a mano richiedeva 3 · 25 Settembre 2025 ![Ansible per PMI: automatizzare il provisioning di VPS Linux senza DevOps dedicato](https://www.mauriziofonte.it/image/002990070-ansible-provisioning-vps-linux-pmi-senza-devops.jpg) - [Checklist essenziale per l'hardening di applicazioni Laravel e Symfony](https://www.mauriziofonte.it/blog/post/checklist-hardening-sicurezza-applicazioni-laravel-symfony-guida-pmi.html) La tua applicazione Laravel o Symfony è in produzione, ma quanto è davvero blindata? Questa checklist parte dai security header e dalla Content · 3 Gennaio 2025 ![Checklist essenziale per l'hardening di applicazioni Laravel e Symfony](https://www.mauriziofonte.it/image/001060070-checklist-hardening-sicurezza-applicazioni-laravel-symfony-guida-pmi.jpg) - [Certificato HTTPS scaduto o mal configurato su VPS con Laravel: diagnosi, fix e hardening TLS nel 2025](https://www.mauriziofonte.it/blog/post/https-compromesso-vps-laravel-protezione-urgente.html) Un portale B2B Laravel su Hetzner con certificato Let's Encrypt scaduto da 11 giorni il rinnovo automatico di Certbot falliva perché la porta · 4 Luglio 2025 ![Certificato HTTPS scaduto o mal configurato su VPS con Laravel: diagnosi, fix e hardening TLS nel 2025](https://www.mauriziofonte.it/image/001980070-https-compromesso-vps-laravel-protezione-urgente.jpg) - [Sviluppo Web con tecnologie LAMP su ambiente Windows con WSL2](https://www.mauriziofonte.it/blog/post/sviluppo-web-lamp-su-windows-wsl2.html) Lo sviluppo web con tecnologie puramente Linux Stack LAMP Linux, Apache, Mysql, PHP è diventato estremamente semplice su Windows 10. Infatti, · 25 Agosto 2022 ![Sviluppo Web con tecnologie LAMP su ambiente Windows con WSL2](https://www.mauriziofonte.it/image/000610070-sviluppo-web-lamp-su-windows-wsl2.jpg) - [Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html) Senza un efficace hardening dei server, la tua azienda è vulnerabile a gravi attacchi informatici. Scopri perché implementare subito questa strategia · 22 Mag 2025 ![Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/image/001250070-hardening-server-protezione-attacchi-informatici.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, "Server Debian e Ubuntu per applicativi PHP: perché l'hardening è cruciale per la sicurezza dei software gestionali e e-commerce delle PMI", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html Pubblicato: 2025-01-29 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.