In breve: un inventario IT dei server web è un elenco di tutti i siti, portali, shop e server con i dati che servono subito quando arriva una segnalazione di sicurezza: dove gira, con quale versione e modalità di PHP, quale applicazione, chi è responsabile e quali dati sarebbero coinvolti. Senza questo elenco ogni reazione comincia con la ricerca. Con l'elenco, il confronto per una segnalazione come PHP2Shell richiede minuti invece di giorni.
La prima domanda è stata: dove gira PHP da noi?
Quando il progetto PHP ha pubblicato le patch il 21/10/2026 e il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha raccomandato di intervenire subito, l'indicazione era chiara: aggiornare PHP, riavviare tutti i processi. Per molte aziende, tuttavia, il primo passo non è stato l'aggiornamento, ma un inventario. Il sito principale era noto. Ma il portale per i rivenditori? La pagina delle carriere presso un altro fornitore? La landing page di una campagna di tre anni fa? La wiki interna?
La stampa specializzata e i servizi di misurazione hanno reso visibile la dimensione del problema. Palo Alto Networks (Unit 42) ha contato più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili. Tra queste ci saranno molti sistemi a cui i loro gestori semplicemente non pensano più.
Che cosa deve contenere un inventario IT dei server web
Un inventario utilizzabile è una tabella con una riga per ogni sito o applicazione. Queste colonne si sono dimostrate valide:
| Colonna | Esempio | A che serve |
|---|---|---|
| Indirizzo | shop.esempio.it | assegnazione univoca |
| Scopo e importanza | negozio online, critico per il fatturato | definizione delle priorità |
| Hoster o sede | server gestito presso il fornitore X | chi chiamare |
| Server e sistema operativo | vServer, Debian | canale di aggiornamento, fonti di sicurezza |
| Server web e modalità PHP | Nginx con PHP-FPM | rischio, ad es. mod_php |
| Versione PHP e stato del pacchetto | 8.3, pacchetto con data | confronto con le segnalazioni |
| Applicazione e versione | Shopware, plugin | segnalazioni dei produttori |
| Responsabile interno / esterno | responsabile IT / agenzia Y | chi interviene |
| Dati trattati | account clienti, ordini | obblighi di notifica, urgenza |
| Backup | giornaliero, esterno, ultimo test il … | ripristino |
| Ultima prova di patch | data e documento | prova verso terzi |
La modalità di esecuzione merita particolare attenzione. Con PHP2Shell il team di PHP ha classificato il rischio come massimo per Apache con mod_php. Chi sa quali sistemi funzionano così può occuparsene per primo. La colonna sullo stato del pacchetto è importante perché il numero di versione visualizzato spesso resta invariato dopo i backport; le indicazioni si trovano in Verificare correttamente versione PHP e livello di patch.
Trovare i sistemi dimenticati: come procedere
I sistemi noti si inseriscono in fretta. Il vero lavoro riguarda quelli sconosciuti. Queste fonti aiutano a scovarli:
- Domini e DNS: passare in rassegna tutti i domini dell'azienda e i loro sottodomini. Ogni voce che punta a un server web è un candidato.
- Fatture: la contabilità conosce ogni hoster, registrar e provider cloud che riceve denaro. Spesso è l'elenco più completo.
- Agenzie e reparti: marketing, vendite e personale commissionano volentieri siti direttamente. Chieda.
- Server noti: su ogni server la configurazione mostra quali siti serve davvero.
- Dispositivi con interfaccia web: NAS, router e appliance portano talvolta un proprio PHP, vedere PHP su NAS, router e appliance.
Per il passaggio 4, sui server Linux aiutano alcuni comandi di sola lettura. Mostrano i siti configurati, i servizi PHP e i pool FPM:
# Siti configurati (Apache o Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Servizi e processi PHP in esecuzione
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pool FPM su Debian e Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Se su un server girano più versioni di PHP in parallelo, ciascuna va inserita nell'elenco. Ognuna deve essere aggiornata e riavviata singolarmente.
Inserisca anche i sistemi che in realtà dovrebbero essere spenti. Proprio questi spesso sono ancora attivi, non vengono aggiornati da anni e vengono dimenticati. Con una voce «spegnere entro il …» il compito resta visibile.
Mantenere aggiornato l'inventario
Un inventario vale quanto il suo ultimo aggiornamento. Tre regole lo mantengono vivo. Primo: una persona è responsabile e viene informata per ogni nuovo sito, ogni trasferimento e ogni dismissione, anche quando il lavoro lo svolge un'agenzia. Secondo: una volta a trimestre l'elenco viene confrontato con DNS, fatture e configurazione dei server. Terzo: l'inventario fa parte del piano di emergenza ed è disponibile anche fuori dall'IT interna, ad esempio stampato.
Per le aziende con molti sistemi distribuiti, come portali per rivenditori, configuratori e accessi per fornitori, Sicurezza IT per PMI e industria descrive i luoghi tipici in cui cercare. Come integrare l'inventario nel piano di emergenza è spiegato in Creare un piano di emergenza IT per i server web.
Errori frequenti nell'inventario dei server web
Molti inventari esistono ma non aiutano nell'emergenza. Le cause si assomigliano:
- Solo server, nessun sito: l'elenco cita le macchine, ma non quali siti vi girano e chi ne è responsabile per la parte operativa. In caso di falla nessuno sa quale reparto sia coinvolto.
- Versione invece dello stato del pacchetto: «PHP 8.3» dice poco dopo PHP2Shell. Solo stato del pacchetto e data mostrano se la correzione è inclusa.
- Mancano i sistemi esterni: ciò che gira presso un'agenzia o un servizio di piattaforma viene omesso perché «lì non siamo competenti». La responsabilità per i dati resta comunque in azienda.
- Nessun referente: una voce senza nome e telefono del responsabile fa perdere tempo nell'emergenza.
- Azione una tantum: l'inventario viene creato in una settimana di crisi e poi non viene più aperto. Dopo un anno buona parte non corrisponde più.
Chi evita questi cinque punti avrà alla prossima segnalazione un elenco con cui si può davvero lavorare.
Come aiuta concretamente PHP SOS?
- Rileviamo insieme a Lei tutti i siti e i server, anche quelli dimenticati, tramite DNS, fatture, fornitori e configurazione dei server.
- Determiniamo per ogni sistema la modalità di esecuzione, la versione di PHP e l'effettivo stato del pacchetto.
- Diamo priorità ai sistemi in base a raggiungibilità, dati e modalità di esecuzione e indichiamo dove intervenire per primo.
- Dove PHP2Shell è ancora aperta, chiudiamo la falla con l'assistenza immediata PHP2Shell e inseriamo la prova nell'inventario.
Conclusione: l'inventario è la misura di sicurezza più discreta e allo stesso tempo più efficace. Chi sa che cosa gira può agire subito alla prossima segnalazione, invece di dover prima cercare.
Domande frequenti
Quali dati servono come minimo in un inventario dei server web?
Indirizzo del sito, server o hoster, modalità di esecuzione di PHP, versione di PHP con stato del pacchetto, applicazione con versione, responsabile interno ed esterno, tipo di dati trattati e luogo dei backup. Con questi dati ogni nuova segnalazione di sicurezza si confronta rapidamente.
Come trovo i siti di cui nessuno sa più nulla?
Attraverso più strade insieme: gestione dei domini e zone DNS, fatture di hoster e registrar, domande ad agenzie e reparti, oltre alla configurazione dei server noti. Vecchi siti di campagne, sistemi di test e sottodomini emergono così di solito.
Chi dovrebbe curare l'inventario?
Una persona designata, di solito nell'IT o presso il responsabile IT. È importante che ogni modifica a siti e server venga comunicata lì, anche quando la richiede un reparto o un'agenzia.
Basta una tabella o serve un software?
Per la maggior parte delle PMI basta una tabella ben tenuta. Un software conviene quando molti sistemi devono essere rilevati automaticamente. Conta l'aggiornamento, non lo strumento.