In breve: chi vuole cambiare hoster dopo un incidente di sicurezza dovrebbe prima conservare le prove e chiarire l'incidente, poi trasferire solo dati verificati su un sistema installato da zero e solo dopo disdire il vecchio contratto. Il nuovo fornitore si sceglie in base a criteri di sicurezza: procedure di patch documentabili, separazione dei clienti, accesso ai log, backup e referenti chiari. Cambiare hoster ha senso quando mancano fiducia o prestazioni, ma non sostituisce la bonifica.
Quando la fiducia è venuta meno
Dopo PHP2Shell molte aziende hanno visto il proprio hoster sotto pressione per la prima volta. Alcune hanno ricevuto in fretta una risposta chiara sullo stato delle patch. Altre hanno atteso giorni una risposta, hanno ricevuto solo formule generiche o hanno scoperto che il loro sito girava su una versione di PHP obsoleta. Se a questo si aggiunge un incidente, il desiderio di cambiare è comprensibile.
Cambiare hoster, però, non è un passo della gestione dell'incidente, ma della riorganizzazione che viene dopo. Chi lo colloca nell'ordine sbagliato rischia, nel peggiore dei casi, di portarsi dietro l'aggressore e di perdere allo stesso tempo le tracce che mostrano cosa sia successo.
L'ordine corretto nel cambio
- Conservare le tracce finché ci sono. Log, file e database del vecchio sistema vanno in un backup prima che qualcosa venga cancellato o disdetto. Chieda espressamente al vecchio hoster i log di accesso e di errore a partire dal 20 ottobre 2026 e la loro durata di conservazione. Come procedere è descritto nell'articolo Conservare le prove prima di reinstallare.
- Circoscrivere l'incidente. Quali sistemi sono coinvolti, quali accessi sono stati usati, quali dati erano raggiungibili? Da ciò dipendono gli obblighi di notifica e la questione di cosa si possa portare con sé.
- Verificare gli obblighi di notifica. Se possono essere coinvolti dati personali, il termine per un'eventuale notifica GDPR decorre dal momento in cui si ha conoscenza dell'incidente, non dal trasloco. Il contesto è descritto in Obbligo di notifica GDPR: 72 ore.
- Costruire il nuovo sistema in modo pulito. Versione di PHP supportata, pacchetti aggiornati, configurazione rafforzata, prima di trasferire il primo file.
- Trasferire solo ciò che è stato verificato. Codice da una fonte pulita, database e contenuti multimediali dopo il controllo.
- Cambiare tutte le credenziali. Database, account amministrativi, SSH, FTP, chiavi API, comprese quelle nei file di configurazione.
- Passare al nuovo sistema e osservare. Cambio del DNS, poi per un certo periodo un monitoraggio più stretto.
- Chiudere il vecchio contratto. Solo quando log e backup sono al sicuro e il nuovo esercizio funziona in modo stabile.
Non disdica il vecchio contratto prima di avere in mano log e backup. Con la fine del contratto il fornitore può cancellare dati che servono all'assicuratore, alle autorità o al Suo stesso chiarimento.
Cosa non portare con sé
Sarebbe comodo copiare semplicemente l'intera directory web o un'immagine del server. È proprio questo, dopo un incidente, il rischio. Le webshell si mimetizzano da file innocui, le backdoor si nascondono in file di configurazione come .htaccess o .user.ini e il codice inserito abusivamente può trovarsi nei contenuti del database.
Trasferisca quindi il codice dell'applicazione da una fonte pulita, ad esempio il pacchetto del produttore nella versione corretta o il Suo sistema di controllo di versione. I contenuti multimediali li riprenda senza file eseguibili, il database dopo un controllo di contenuti anomali e di nuovi account amministratore. Quanto trovato sul vecchio sistema aiuta in questo controllo.
Pensi anche a tutto ciò che presso il vecchio fornitore sta accanto al sito. Caselle e-mail, record DNS, certificati e inoltri vengono facilmente dimenticati nel trasloco. Riduca la durata di validità dei record DNS alcuni giorni prima del passaggio, così che la modifica raggiunga rapidamente i visitatori. Se si trasferiscono anche le e-mail, pianifichi il cambio delle caselle separatamente, perché anche lì, dopo un incidente, le credenziali possono essere coinvolte.
Scegliere il nuovo hoster in base alla sicurezza
Prezzo e spazio su disco compaiono in ogni offerta. Le domande di sicurezza decisive di solito deve porle Lei stesso. L'elenco seguente aiuta nel confronto:
| Criterio | Domanda al fornitore | Perché conta |
|---|---|---|
| Procedura di patch | Come e con quali tempi vengono installati e riavviati gli aggiornamenti di sicurezza di PHP? | PHP2Shell ha mostrato quanto sia importante una procedura documentabile |
| Prova | Su richiesta ricevo una conferma scritta dello stato delle patch? | Base per la Sua documentazione |
| Versioni di PHP | Quali rami sono offerti e per quanto tempo ancora? | I vecchi rami senza aggiornamenti sono un rischio permanente |
| Separazione | Ogni sito gira con un utente proprio e un proprio processo PHP? | Limita i danni se un vicino viene attaccato |
| Log | Ho accesso ai log di accesso e di errore, per quanto tempo vengono conservati? | Senza log non c'è chiarimento |
| Backup | Con quale frequenza, per quanto tempo, separati dal server web, con test di ripristino? | Ripristino dopo un incidente |
| Contatto di emergenza | Come raggiungo una persona competente in caso di incidente? | Il tempo, nell'emergenza, è il fattore più scarso |
| Trattamento dei dati per conto del titolare | Esiste un contratto ai sensi del GDPR e un elenco dei sub-responsabili? | Obbligatorio in caso di dati personali |
Un modello per la domanda sullo stato delle patch è offerto dalla guida Chiedere all'hoster lo stato della patch. Serve anche a confrontare i fornitori prima della stipula del contratto.
Un altro modello di esercizio è la risposta migliore?
A volte il problema sta meno nell'hoster che nel modello di esercizio. Chi gestisce un server proprio senza manutenzione regolare sta spesso meglio con un'offerta managed ben assistita. Al contrario, un'azienda con IT interna può guadagnare più controllo sui momenti delle patch se gestisce da sé. Il confronto è descritto nell'articolo Managed hosting o server proprio?.
Indipendentemente dal modello vale questo: metta per iscritto la ripartizione dei compiti. Chi installa gli aggiornamenti di PHP, chi riavvia, chi verifica l'applicazione, chi si rivolge a chi in caso di emergenza? Con PHP2Shell molti ritardi sono nati proprio qui, perché ciascuna parte pensava che se ne occupasse l'altra.
Come aiuta concretamente PHP SOS?
- Conserviamo log e dati del vecchio sistema e chiariamo cosa è successo nell'incidente.
- Costruiamo il nuovo sistema con hardening e trasferiamo solo contenuti verificati da fonti pulite.
- Valutiamo le offerte dei nuovi fornitori in base ai criteri di sicurezza e poniamo le domande giuste.
- In caso di incidente in corso lavoriamo nell'ambito del nostro servizio di incident response, fino alla chiusura e alla documentazione dell'incidente.
Domande frequenti
Dopo un attacco devo cambiare subito hoster?
Non subito. Prima vanno conservate le tracce, circoscritto l'incidente e chiarita la causa. Un trasloco affrettato rischia di portarsi dietro il codice dannoso e può distruggere prove presso il vecchio fornitore.
La colpa è dell'hoster, se il mio sito è stato attaccato tramite PHP2Shell?
Dipende dal contratto e dal momento. Nell'hosting condiviso di norma l'hoster è responsabile degli aggiornamenti di PHP, nei server propri il gestore. Le patch sono uscite il 21 ottobre 2026; se e quando siano state installate si può chiarire solo con documenti. Per le questioni di responsabilità si rivolga a un legale.
Quali dati posso portare al nuovo hoster?
Solo contenuti verificati: database dopo il controllo di codice inserito abusivamente, contenuti multimediali senza file eseguibili e codice da una fonte pulita, come il pacchetto del produttore o il Suo sistema di controllo di versione. Immagini complete del server o directory web del sistema compromesso non vanno trasferite senza verifica.
Dopo un incidente devo coinvolgere la protezione dei dati?
Se possono essere coinvolti dati personali, può sussistere un obbligo di notifica ai sensi del GDPR, di norma entro 72 ore. Con il nuovo hoster Le serve inoltre un contratto di trattamento dei dati per conto del titolare. Lo chiarisca con il Suo responsabile della protezione dei dati; questa non è consulenza legale.