In breve: se reinstallare o bonificare un server dopo un hack dipende da quanto con certezza si conosce la portata dell'intrusione. Se l'aggressore può aver avuto privilegi di root, il momento dell'intrusione è incerto o mancano i log, una ricostruzione da fonti attendibili è la scelta più affidabile. Una bonifica entra in considerazione solo con un'infezione strettamente circoscritta e ben documentata. In entrambi i casi vale: prima conservare le prove e chiudere la falla, poi ripulire.
Perché questa domanda si pone così spesso dopo PHP2Shell
Secondo php.net, PHP2Shell consente l'esecuzione di codice dannoso da remoto senza autenticazione. Chi gestiva un server senza patch deve quindi chiedersi se nel periodo dal 17/10/2026, il primo tentativo di attacco osservato secondo i media, sia successo qualcosa. La patch non risponde a questa domanda, e non esistono Indicators of Compromise pubblicati e confermati.
Se poi si trova un file sospetto, un processo sconosciuto o un cronjob estraneo, si deve decidere. L'impulso è spesso cancellare in fretta o reinstallare subito. Entrambe le cose possono essere giuste, ma non come primo passo.
L'ordine prima della decisione
Prima di scegliere tra bonifica e reinstallazione vanno fatte tre cose. Valgono per entrambe le strade.
- Contenere: togliere il server dalla rete o limitare l'accesso allo stretto necessario, senza spegnerlo se si vuole ancora salvare la memoria.
- Conservare le prove: salvare log, file, database e possibilmente un'immagine del sistema, con data e checksum. Perché serve prima di ogni reinstallazione lo spiega Conservare le prove prima di reinstallare.
- Coinvolgere assicuratore e protezione dei dati: molte cyber-polizze si aspettano che i passaggi essenziali siano concordati. Indicazioni in Cyber-assicurazione: che cosa conta in caso di sinistro. Se esista un obbligo di notifica ai sensi del GDPR lo valutano il responsabile della protezione dei dati o l'avvocato.
Solo dopo vale la pena la vera ponderazione.
Reinstallare il server dopo l'hack o bonificare: i criteri
| Criterio | Bonificare | Reinstallare |
|---|---|---|
| Portata dell'intrusione | Strettamente circoscritta, documentata, ad esempio un file nella cartella degli upload senza altre tracce | Poco chiara o con indizi di accesso al sistema |
| Possibili privilegi di root dell'aggressore | Esclusi con buone prove | Non escludibili |
| Disponibilità dei log | Completi per il periodo rilevante | Lacunosi, sovrascritti o manipolabili |
| Impegno | Minore, se il riscontro è chiaro | Maggiore, ma meglio pianificabile |
| Incertezza residua | Maggiore, le backdoor nascoste sono difficili da escludere | Minore, se ricostruito in modo pulito da fonti attendibili |
| Tempo di fermo | Di solito più breve | Di solito più lungo, ben gestibile con la preparazione |
| Idoneità per sistemi legacy | Problematica se il sistema è comunque obsoleto | Buona occasione per passare a una versione PHP supportata |
Come regola pratica: meno si sa, più depone a favore della ricostruzione. Con una falla nell'interprete PHP che esegue codice nel contesto dell'utente del server web, un aggressore può sfruttare altre vulnerabilità per ottenere più privilegi. Senza un'indagine approfondita è difficile escluderlo.
Le due strade nella pratica
Che cosa significa davvero «reinstallare»
Reinstallare non significa copiare il vecchio backup su un server nuovo. Una ricostruzione inizia con un sistema operativo pulito da fonte ufficiale, pacchetti aggiornati e una versione PHP con patch. L'applicazione viene installata dall'originale del produttore, così come plugin e temi.
Solo allora si aggiungono i propri contenuti, e verificati. I file caricati non devono contenere script eseguibili, il database può contenere contenuti introdotti, come account admin nascosti o script negli articoli. I file di configurazione vengono riscritti anziché copiati. Tutte le credenziali vengono rinnovate: database, admin del CMS, chiavi SSH, chiavi API, pannello di hosting.
I backup hanno qui un ruolo importante, ma solo se il loro stato è precedente all'intrusione e se essi stessi non sono stati modificati. Più generazioni in luoghi separati lo rendono verificabile; di più in Backup secondo la regola 3-2-1.
Quando la bonifica è giustificabile
Una bonifica può avere senso se l'infezione è stata scoperta presto, esistono log completi e l'indagine non dà alcun indizio di ulteriori accessi. Allora i file trovati vengono rimossi dopo il salvataggio, cronjob, account utente e chiavi SSH vengono verificati e i file del core vengono confrontati con l'originale del produttore.
È importante una valutazione realistica: le webshell sono spesso poco appariscenti e nascoste in più punti. Come trovarle lo descrive Riconoscere e rimuovere le webshell. Dopo una bonifica il server dovrebbe essere osservato da vicino, perché una backdoor trascurata venga notata.
Non cancelli nulla prima che log e file siano stati salvati, e chiuda la falla prima che il server torni in rete. Altrimenti perde le tracce e invita la prossima intrusione.
Quando non serve un fornitore
Con un semplice sito su hosting condiviso, in cui l'hoster gestisce il sistema e conferma la patch PHP, la decisione spesso non spetta nemmeno a Lei. Può reinstallare l'applicazione dall'originale, verificare i contenuti e rinnovare le credenziali, con il supporto dell'hoster. Anche un team interno esperto può affrontare da sé una ricostruzione, se conservazione delle prove e documentazione sono a posto.
L'aiuto esterno conviene quando i privilegi di root non si possono escludere, potrebbero essere coinvolti dati personali, è coinvolta l'assicurazione o più sistemi sono collegati.
Come aiuta concretamente PHP SOS?
- Conserviamo log, file e database in modo probatorio, prima che qualcosa venga modificato.
- Valutiamo la portata dell'intrusione e consigliamo bonifica o ricostruzione con motivazione, distinguendo tra provato, probabile e ignoto.
- Ricostruiamo il server, se serve, da fonti attendibili, con versione PHP con patch e accessi rinnovati.
- Ci occupiamo della rimozione del malware dove una bonifica è giustificabile e documentiamo ogni passaggio.
Conclusione
La domanda «reinstallare o bonificare?» trova risposta attraverso la conoscenza dell'intrusione. Chi non ne conosce con sicurezza la portata ricostruisce. Chi può circoscriverla con buone prove può bonificare. In entrambi i casi vale lo stesso ordine: contenere, conservare, chiudere la falla, poi ripulire.
Domande frequenti
Reinstallare dopo un hack è sempre meglio?
Non sempre, ma spesso. Se non è chiaro fin dove sia arrivato l'aggressore, una ricostruzione da fonti attendibili è di solito la scelta più affidabile. In caso di infezione strettamente circoscritta e ben documentata può bastare una bonifica.
Posso semplicemente ripristinare un vecchio backup?
Solo se è certo che il backup sia stato creato prima dell'intrusione e non contenga backdoor. Inoltre la falla deve essere stata chiusa prima, altrimenti il server è subito di nuovo attaccabile. I dati più recenti vanno verificati a parte.
Che cosa devo conservare prima di reinstallare?
Log, una copia dei file e del database e, se possibile, un'immagine del sistema. Queste prove servono per l'analisi delle cause, per l'assicurazione e per un'eventuale notifica. Dopo la cancellazione non ci sono più.
Basta cancellare la webshell trovata?
Raramente. Gli aggressori creano spesso più backdoor, ad esempio cronjob, account utente o chiavi SSH. Chi cancella solo il file visibile lascia aperti gli altri accessi.