In breve: dopo l'allerta su PHP2Shell, in Germania sono stati spenti dei siti web, tra cui, secondo i media, il portale web della città di Magonza e pagine del governo regionale dell'Assia e del BKA (la polizia criminale federale tedesca). Si è trattato di prevenzione su raccomandazione del BSI (l'Ufficio federale tedesco per la sicurezza informatica), non di attacchi confermati. Le aziende ne possono ricavare questo: lo spegnimento è un'opzione legittima quando una patch non è subito possibile, e riesce meglio se è preparato.
Siti web spenti per PHP: che cosa è accaduto il 21 ottobre
Il giorno degli aggiornamenti di sicurezza di PHP, in Germania numerosi siti web pubblici non erano raggiungibili. Secondo i rapporti dei media, la città di Magonza ha spento in via precauzionale il proprio portale web centrale. Gli uffici sono rimasti raggiungibili per telefono e per e-mail.
In Assia, secondo hessenschau, tra gli altri erano temporaneamente offline pagine del governo regionale, della polizia criminale federale e delle città di Kassel e Wiesbaden. La cancelleria di Stato ha parlato di adeguamenti tecnici e non ha segnalato alcun attacco. I siti regionali erano di nuovo raggiungibili la sera. Secondo i rapporti, anche altri comuni, università e cliniche hanno portato offline in via precauzionale alcuni servizi.
Lo sfondo è la raccomandazione del BSI su PHP2Shell: aggiornare subito e, se non è subito possibile, scollegare temporaneamente dalla rete i server web interessati. Che cosa consigli nel dettaglio il BSI lo riassume la pagina Cosa raccomanda il BSI su PHP2Shell.
Spento non significa violato
Nei commenti e sui social network «offline» è diventato in fretta «hackerato». Per tutto ciò che si sa, è falso. Gli spegnimenti sono stati una misura di protezione in un momento in cui molti gestori non conoscevano ancora con certezza lo stato di patch dei propri server.
Per le aziende questa distinzione è importante due volte. Primo, verso l'esterno: chi spegne in via precauzionale dovrebbe dirlo così e non tacere. Secondo, verso l'interno: uno spegnimento non risponde alla domanda se il server sia stato attaccato in precedenza. Ferma solo ulteriori tentativi. La verifica delle tracce resta necessaria.
Un terzo punto è spesso trascurato: uno spegnimento non deve distruggere tracce. Chi, per spegnere, reinstalla semplicemente il server o cancella i log per fare spazio si toglie la possibilità di chiarire più tardi che cosa sia accaduto prima dello spegnimento. Meglio reindirizzare il server web a una pagina di emergenza oppure bloccare l'accesso dall'esterno e lasciare il server stesso, con tutti i log, invariato.
Perché proprio gli enti pubblici hanno reagito così
Le autorità gestiscono spesso molti siti web in parallelo: portale principale, portali tematici, servizi di moduli, pagine di singoli uffici e strutture. Spesso vi sono coinvolti più fornitori di servizi. Il giorno dell'allerta, per molte amministrazioni era semplicemente impossibile ottenere in poche ore, per ogni sistema, uno stato di patch documentato. Lo spegnimento precauzionale era in quella situazione la via più rapida per seguire la raccomandazione del BSI.
Per le aziende con un panorama IT cresciuto nel tempo la situazione è spesso simile. La domanda «È tutto aggiornato?» non fallisce per la tecnica, ma per la mancanza di visibilità d'insieme.
Degno di nota è anche quanto in fretta, secondo i rapporti, i siti regionali dell'Assia siano tornati: già la sera dello stesso giorno. Ciò mostra che uno spegnimento precauzionale non deve durare giorni. Chi conosce i propri sistemi e padroneggia il percorso di aggiornamento può applicare la patch, verificare e tornare online in poche ore. Lo spegnimento colma allora solo il tempo fino a quando si fa chiarezza.
Quando per le aziende uno spegnimento precauzionale ha senso
Le autorità si trovano in una situazione particolare: molti siti web, spesso gestiti in modo distribuito, e grande visibilità pubblica. La valutazione che hanno dovuto fare è però la stessa di qualsiasi azienda. La panoramica seguente aiuta a decidere:
| Situazione | Meglio spegnere | Meglio lasciare online |
|---|---|---|
| Stato della patch | poco chiaro o non confermato | corretto e documentato, processi riavviati |
| Versione PHP | 8.1 o precedente senza backport confermato | ramo supportato allo stato attuale |
| Modalità di esecuzione | Apache con mod_php | PHP-FPM con patch e misure transitorie applicate |
| Dati sul server | dati dei clienti, login, dati di pagamento | contenuti puramente statici |
| Disponibilità del fornitore di servizi | patch possibile solo tra qualche giorno | patch fissata a breve |
La scelta tra applicare la patch, spegnere e attendere è approfondita nell'articolo Applicare la patch, spegnere o attendere?. Che cosa sia tecnicamente possibile come soluzione ponte quando manca ancora l'aggiornamento è spiegato in Misure immediate senza patch.
Spegnere temporaneamente uno shop o un portale clienti costa fatturato. Un server compromesso con dati dei clienti può costare molto di più, fino agli obblighi di notifica. Prenda la decisione in modo consapevole e la metta per iscritto.
Come preparare uno spegnimento
Magonza ha mostrato che cosa conta: l'amministrazione è rimasta raggiungibile tramite altri canali. Ci si riesce solo se è preparato. Questi passaggi valgono la pena prima del prossimo caso grave:
- Tenere pronta una pagina di emergenza: una pagina HTML statica senza PHP, con una breve spiegazione, contatto telefonico e e-mail e, se necessario, indicazioni su ordini o appuntamenti in corso.
- Definire il percorso di commutazione: chi può reindirizzare il sito alla pagina di emergenza, tramite server web, DNS o un servizio a monte? Quanto ci vuole?
- Chiarire il potere decisionale: chi può ordinare uno spegnimento, anche fuori dall'orario di lavoro?
- Conoscere i servizi dipendenti: interfacce, app o partner dipendono dal sito? Chi va informato in anticipo?
- Definire i criteri per il ritorno: patch documentata, riavvio eseguito, prima verifica delle tracce senza riscontri.
- Preparare il messaggio: due o tre frasi per clienti, partner e stampa.
Come comunicare verso l'esterno in una situazione simile lo descrive la guida alla comunicazione di crisi.
Come aiuta concretamente PHP SOS?
- Base decisionale: rileviamo stato della patch, modalità di esecuzione e situazione dei dati dei Suoi server e Le diamo una valutazione chiara sull'opportunità di uno spegnimento.
- Spegnimento ordinato: passiamo a una pagina di emergenza statica, senza perdere log o tracce.
- Patch e verifica: aggiorniamo PHP, riavviamo tutti i processi e cerchiamo anomalie.
- Ritorno controllato: riportiamo il sito online solo quando i criteri concordati sono soddisfatti e documentati.
Lo svolgimento è descritto nel pronto intervento PHP2Shell.
Conclusione
Gli spegnimenti delle autorità non sono stati un segno di perdita di controllo, ma una consapevole misura di prudenza. Per le aziende è questa la vera lezione: andare offline è una decisione legittima quando lo stato della patch è poco chiaro. Chi ha preparato pagina di emergenza, responsabilità e criteri di ritorno la prende in minuti anziché in ore.
Domande frequenti
Perché i siti delle autorità sono stati spenti a causa di PHP?
Per PHP2Shell il BSI raccomanda l'aggiornamento immediato e, se questo non è subito possibile, di scollegare temporaneamente i server web dalla rete. Diverse autorità hanno seguito questa raccomandazione in via precauzionale, fino a quando i loro sistemi non sono stati verificati e aggiornati.
Un sito spento significa che è stato violato?
No. Uno spegnimento precauzionale è una misura di protezione. La cancelleria di Stato dell'Assia, ad esempio, secondo hessenschau ha espressamente dichiarato di non aver subito alcun attacco. Se un server fosse interessato prima dello spegnimento lo chiarisce solo una verifica.
Per quanto tempo un sito dovrebbe restare offline?
Fino a quando PHP non è a uno stato corretto, tutti i processi PHP non sono stati riavviati e una prima verifica delle tracce non ha dato anomalie. Non esiste una durata fissa; secondo i rapporti, i siti regionali dell'Assia erano di nuovo raggiungibili la sera dello stesso giorno.
Che cosa mostro ai visitatori mentre il sito è offline?
Meglio una semplice pagina di emergenza statica, senza PHP, con una breve spiegazione e i canali di contatto attraverso cui restate raggiungibili. Dovrebbe essere pronta prima di averne bisogno.