In breve: cambiare CMS dopo un hack aiuta solo se il vecchio sistema era esso stesso la causa, ad esempio perché il produttore non fornisce più aggiornamenti di sicurezza o estensioni importanti non sono più mantenute. Se la causa stava in plugin obsoleti, accessi deboli o in una falla come PHP2Shell nel PHP sottostante, un cambio sposta soltanto l'impegno. In ogni caso vale: prima verificare i contenuti, poi trasferirli, altrimenti il codice dannoso migra con essi.
Quando la fiducia è venuta meno
Dopo un'intrusione l'umore è spesso inequivocabile: «Con questo sistema mai più.» È comprensibile. Il sito ha reindirizzato i visitatori verso siti esterni, Google ha lanciato un avviso, i clienti hanno chiesto spiegazioni. Un nuovo CMS sembra un nuovo inizio.
La situazione attorno a PHP2Shell mostra però perché questo riflesso può trarre in inganno. La falla si trova nell'interprete PHP, non in WordPress, TYPO3, Shopware o un altro sistema. Secondo drweb.de, WordPress.org non prevede perciò un proprio aggiornamento in merito. Chi ora passa da un CMS PHP a un altro CMS PHP ha alla fine la stessa dipendenza, solo con un logo diverso. Quali sistemi girano su PHP lo mostra il prospetto Quali CMS e sistemi di shop girano su PHP.
La causa decide
Prima di pensare a un cambio, la causa dell'intrusione deve essere chiarita. Le porte d'ingresso tipiche sono estensioni obsolete, password riutilizzate o deboli, mancanza di autenticazione a due fattori, un server senza patch o installazioni di test dimenticate. Nessuna di queste cause è legata a un determinato CMS.
Chi non conosce la causa rischia di portarla nel nuovo sistema. Un team che finora ha rimandato gli aggiornamenti farà lo stesso nel nuovo CMS. Un'agenzia che usava account admin condivisi lo ripeterà se nessuno cambia la procedura. La domanda è quindi meno «quale CMS?» e più «quale processo?».
Cambiare CMS dopo l'hack: la valutazione
| Criterio | Restare sul CMS esistente e fare hardening | Passare a un altro CMS |
|---|---|---|
| Causa dell'intrusione | Nota e rimediabile, ad esempio un plugin obsoleto | Sta nel sistema stesso, ad esempio aggiornamenti del produttore mancanti |
| Manutenzione del produttore | Gli aggiornamenti di sicurezza vengono forniti | Il produttore ha cessato la manutenzione |
| Dipendenza dalle estensioni | Poche estensioni, mantenute | Molte estensioni senza manutenzione attiva |
| Impegno | Bonifica, hardening, cambio di processo | Ricostruzione, migrazione, formazione, spesso nuovo design |
| Tempo fino al sito sicuro | Più breve | Più lungo, serve una soluzione transitoria |
| Protezione dalle falle PHP | Nessun cambiamento, PHP deve essere aggiornato con patch | Nessun cambiamento, finché il nuovo sistema usa PHP |
| Utilità a lungo termine | Alta, se i processi migliorano | Alta, se il vecchio sistema era comunque a fine vita |
Se nella Sua situazione la maggior parte delle righe finisce a sinistra, il cambio non conviene quasi mai. Restare, bonificare, fare hardening e migliorare la procedura di manutenzione porta più sicurezza con meno denaro. Per i gestori di WordPress WordPress e PHP2Shell riassume i passaggi principali.
Per questa decisione non serve sempre un fornitore. Se la causa era chiara, ad esempio un plugin noto con una falla pubblicata, e la Sua agenzia o il Suo admin ha reinstallato il sito in modo pulito, può decidere da solo. L'aiuto esterno conviene quando la causa resta poco chiara o potrebbero essere coinvolti dati personali.
Se cambia: non portarsi dietro il codice dannoso
Se si decide per un cambio, la migrazione stessa è un rischio di sicurezza. Gli aggressori lasciano tracce non solo nei file, ma anche nel database. Questi passaggi aiutano a traslocare in modo pulito:
- Mettere in sicurezza e isolare il vecchio sistema: backup completo come prova, poi togliere il vecchio sistema dalla rete o renderlo raggiungibile solo internamente.
- Esportare i contenuti in modo mirato: testi, struttura delle pagine e media, non l'intero database. Non trasferire gli account utente, ma crearli di nuovo.
- Verificare i contenuti: esaminare i testi alla ricerca di script introdotti, link nascosti e reindirizzamenti estranei. Come si fa lo descrive Verificare il database alla ricerca di codice introdotto.
- Filtrare i media: trasferire solo i tipi di file attesi, scartare file con doppia estensione o contenuto di script.
- Configurare il nuovo sistema in modo pulito: dalla fonte originale del produttore, su un server con PHP con patch, con nuove credenziali e autenticazione a due fattori.
- Pianificare i reindirizzamenti: reindirizzare i vecchi indirizzi verso i nuovi, perché motori di ricerca e visitatori arrivino a destinazione, senza che restino aperti i vecchi percorsi.
Un cambio di CMS non sostituisce la bonifica del vecchio server. Se il vecchio sistema continua a girare, ad esempio come copia dimenticata su un sottodominio, la backdoor resta aperta.
L'alternativa spesso trascurata
Alcune aziende dopo un hack si accorgono di non aver affatto bisogno delle funzioni di un grande CMS. Un sito aziendale con poche pagine, modificate di rado, funziona anche senza PHP sul server. Un generatore di pagine statiche produce file HTML pronti che non richiedono più alcuna logica di programma lato server. Quali vantaggi e svantaggi abbia lo descrive Siti web statici: meno PHP, meno superficie di attacco.
Al contrario, per shop, portali o siti con molti redattori di solito non è un'opzione. Qui un sistema dinamico resta sensato, e la sicurezza nasce da manutenzione, hardening e monitoraggio.
Chi è incerto se nel vecchio WordPress si annidino ancora accessi nascosti trova in Trovare le backdoor in WordPress i punti tipici in cui cercare. Aiuta anche a decidere se una bonifica sia realistica.
Come aiuta concretamente PHP SOS?
- Chiariamo innanzitutto la causa dell'intrusione e Le diciamo se dipende dal CMS o da processo e server.
- Bonifichiamo il sistema esistente nell'ambito della rimozione del malware oppure lo prepariamo come prova per una ricostruzione.
- In caso di cambio verifichiamo contenuti e media da trasferire alla ricerca di codice dannoso, prima che entrino nel nuovo sistema.
- Configuriamo il nuovo server con PHP con patch e configurazione sottoposta a hardening.
Conclusione
Un cambio di CMS dopo un hack è di rado la soluzione, ma a volte è l'occasione giusta. Se il vecchio sistema non è più mantenuto, il nuovo inizio vale la pena. Se la causa stava nei processi o nel server, lavorare sul processo porta più di un nuovo logo. In entrambi i casi vale: prima verificare, poi trasferire.
Domande frequenti
Cambiare CMS aiuta contro PHP2Shell?
No, finché il nuovo CMS gira anch'esso su PHP. PHP2Shell si trova nell'interprete PHP, non nel CMS. Decisivo è lo stato delle patch di PHP sul server, non il sistema sovrastante.
WordPress è meno sicuro di altri CMS?
In generale non si può dire. Molte intrusioni nascono da estensioni obsolete, accessi deboli o aggiornamenti mancanti, e queste cause esistono in ogni sistema. La diffusione rende però un CMS un bersaglio più frequente delle scansioni automatizzate.
Posso semplicemente esportare i contenuti dal CMS violato?
Solo dopo una verifica. Il database può contenere script introdotti, link nascosti o account admin estranei. I file caricati possono mascherare codice dannoso. Esporti i contenuti in modo mirato e li verifichi prima dell'importazione.
Quando un cambio di CMS è davvero sensato?
Quando il produttore non fornisce più aggiornamenti di sicurezza, quando il sito dipende da estensioni non più mantenute o quando il sistema semplicemente non è più adatto alle esigenze attuali. L'hack è allora l'occasione, non il motivo.