In breve: chi vuole fare l'hardening del proprio server per PHP fa in modo che una singola vulnerabilità non apra l'intero server. Separiamo i siti web l'uno dall'altro, configuriamo PHP e il web server in modo sicuro, limitiamo privilegi e accessi e documentiamo ogni modifica. Così il danno resta più contenuto, se comunque accade qualcosa.
Perché dopo PHP2Shell l'hardening è diventato più importante
PHP2Shell ha mostrato con quanta rapidità una vulnerabilità in PHP stesso diventi un problema per tutti i siti web di un server. Con CVE-2026-109618 e CVE-2026-109619 gli aggressori possono eseguire codice senza autenticarsi. La patch chiude questa porta. L'hardening risponde a un'altra domanda: che cosa può fare chi riesce comunque a entrare, attraverso questa o la prossima vulnerabilità?
Su un server privo di hardening spesso tutti i siti web girano con lo stesso utente, PHP può eseguire comandi di sistema e le credenziali sono leggibili da tutti i processi. Un'intrusione in un piccolo sito secondario arriva allora fino al negozio online. Un buon hardening separa questi ambiti. Non è un'azione isolata, ma uno stato di base che deve essere mantenuto a ogni nuovo sito web e a ogni cambio di versione.
Hardening del server per PHP: che cosa modifichiamo in concreto
Isolamento per sito web
Ogni sito web riceve un proprio utente di sistema e un proprio pool PHP-FPM. Con open_basedir e permessi dei file adeguati, un'applicazione vede solo la propria directory. Maggiori informazioni alla pagina open_basedir e isolamento per ogni sito web.
Configurazione sicura di PHP
Impostiamo php.ini e la configurazione del pool in modo che le applicazioni non possano sovrascrivere da sole i valori rilevanti per la sicurezza. Un estratto di come può apparire in un pool FPM:
; impostare i valori in modo fisso nel pool FPM, non modificabili tramite ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Quali funzioni sia possibile bloccare in aggiunta dipende dall'applicazione. Indicazioni in merito si trovano alle pagine Configurare php.ini in modo sicuro e Usare correttamente disable_functions.
Permessi dei file e accesso in scrittura
Il web server può scrivere solo dove è necessario, ad esempio nella cartella degli upload. Nelle directory di upload l'esecuzione di PHP viene impedita. Il codice del programma appartiene a un utente diverso da quello con cui gira PHP. I principi sono spiegati alla pagina Permessi dei file sul web server.
Accessi, servizi e log
SSH solo con chiave, interfacce di amministrazione con autenticazione a due fattori, servizi e porte non necessari chiusi. I log vengono conservati e protetti in modo da esserci ancora dopo un incidente. I backup li verifichiamo per accertarne la ripristinabilità.
Web server e header di sicurezza
Anche il web server stesso fa parte dell'hardening: nascondere le indicazioni di versione, disattivare l'elenco delle directory, bloccare l'accesso a file di configurazione, di backup e di controllo di versione e proteggere ulteriormente le aree di amministrazione, ad esempio con un'abilitazione per indirizzo IP. Header di sicurezza come Content-Security-Policy o HSTS proteggono nel browser i visitatori del Suo sito web.
Che cosa troviamo spesso nell'inventario
Molte debolezze si ripetono da un server all'altro. Sono tipici più siti web sotto un utente comune, interfacce di database raggiungibili pubblicamente, vecchie installazioni di prova in sottocartelle, versioni di PHP dimenticate accanto a quella attuale e backup che si trovano nella directory web e sono scaricabili. Spesso manca inoltre qualsiasi registrazione degli accessi, oppure i log vengono cancellati dopo pochi giorni.
Nessuno di questi punti è di per sé spettacolare. Insieme, però, decidono se un'intrusione resta limitata a un sito web o riguarda l'intero server.
Come aiuta concretamente PHP SOS?
- Inventario: rileviamo sistema operativo, web server, versioni di PHP, siti web, utenti, servizi aperti e salvataggi esistenti.
- Piano di interventi: riceve un elenco in ordine di priorità, con impegno e possibili effetti per ogni punto. È Lei a decidere che cosa venga attuato.
- Attuazione a passi: modifichiamo le configurazioni previo accordo, testiamo i siti web dopo ogni passo e annotiamo come ogni modifica possa essere annullata.
- Controllo: dopo l'attuazione verifichiamo l'effetto, ad esempio se un sito web non possa davvero più leggere directory altrui.
- Consegna: riceve una documentazione del nuovo stato, comprensibile anche per il Suo hoster o la Sua agenzia.
Che cosa riceve e che cosa ci serve
Riceve un rapporto di hardening con situazione di partenza, misure attuate, punti lasciati consapevolmente aperti con relativa motivazione e una raccomandazione per il controllo periodico. Le modifiche ai file di configurazione sono documentate in modo verificabile.
Da Lei ci servono:
- accesso root o di amministratore al server, con i pannelli anche l'accesso al pannello
- un elenco delle applicazioni e delle loro particolarità, ad esempio upload, interfacce, cronjob
- un referente tecnico in grado di confermare le funzioni dopo le modifiche
- finestre di manutenzione per i riavvii
- un backup recente oppure l'incarico di eseguirne uno prima
Che cosa non promettiamo
L'hardening non rende un server inattaccabile. Riduce la superficie di attacco e limita i danni, ma non sostituisce né gli aggiornamenti né il monitoraggio. Una versione di PHP senza patch resta vulnerabile, per quanto bene sia impostato il resto. Per questo abbiniamo l'hardening al servizio di patch PHP e raccomandiamo poi un'assistenza continuativa con un contratto di manutenzione della sicurezza.
Con l'hosting condiviso molte cose non sono impostabili, perché la configurazione è stabilita dall'hoster. In tal caso mostriamo che cosa è possibile nell'ambito del Suo pacchetto e dove avrebbe senso passare a un server proprio o gestito.
Domande frequenti
Che cosa significa fare l'hardening di un server?
Hardening significa disattivare o limitare tutto ciò che non serve al funzionamento. Ne fanno parte servizi superflui, privilegi troppo ampi, porte aperte e impostazioni predefinite non sicure. L'obiettivo è che un singolo errore non apra subito l'intero server.
L'hardening avrebbe impedito PHP2Shell?
No, contro una vulnerabilità in PHP stesso aiuta solo la patch. L'hardening però limita ciò che un aggressore può ottenere dopo un'intrusione riuscita, ad esempio se può accedere ad altri siti o a credenziali.
Con l'hardening il mio sito web smette di funzionare?
Il rischio esiste se le impostazioni vengono modificate senza test. Applichiamo le modifiche a piccoli passi, verifichiamo le funzioni dopo ogni passaggio e annotiamo come ogni modifica possa essere annullata.
Ogni quanto andrebbe verificato l'hardening?
Al più tardi dopo grandi aggiornamenti, un cambio della versione di PHP o nuove applicazioni sul server. È sensato un controllo periodico nell'ambito della manutenzione continuativa.