La maggior parte dei proprietari di siti WordPress ha dei backup. Quasi nessuno ha backup che ha davvero testato. La differenza diventa brutalmente evidente nel momento peggiore possibile: il giorno in cui servono. Questo articolo descrive un caso reale tratto da un recente incidente di un’agenzia di Sydney, in cui la questione dei backup ha quasi trasformato un ripristino difficile in un quasi disastro, e cosa abbiamo cambiato per assicurarci che non succeda più.
L’incidente
L’agenzia gestisce un portfolio di siti di piccole imprese clienti su un unico hosting condiviso. Uno di essi, il sito dell’agenzia stessa, è stato compromesso. Un attacco di cloaking SEO aveva depositato in silenzio file dannosi nella document root, imitando i nomi reali delle pagine WordPress con contenuti controllati dall’attaccante. La pulizia in sé è stata semplice una volta identificato il punto d’ingresso. La parte più difficile è stata decidere fino a che punto tornare indietro.
L’analisi forense suggeriva che l’attaccante fosse sul sito da almeno qualche settimana prima della scoperta. Per sicurezza, il piano di ripristino prevedeva un ripristino da un backup precedente alla data d’ingresso sospetta. Più era pulita la base di partenza precedente all’incidente, minore era la probabilità che una sottile backdoor sopravvivesse alla pulizia.
La prima sorpresa
Il plugin di backup era stato installato e configurato al lancio del sito, due anni prima. Il piano prevedeva backup giornalieri del database e backup completi settimanali, entrambi caricati su un account di cloud storage esterno. Quando il titolare dell’agenzia è andato a recuperare un backup di sei settimane prima dell’incidente, la risposta è stata scomoda: il backup più recente nel cloud storage risaliva a dodici mesi prima.
Il plugin di backup falliva in silenzio da almeno un anno. L’agenzia non ne aveva idea. Le notifiche dei fallimenti venivano inviate a un indirizzo e-mail non più monitorato. A nessuno era venuto in mente di controllare lo storage di destinazione per confermare che i file arrivassero davvero. Il sistema era rotto in silenzio da ben più tempo dell’incidente di sicurezza vero e proprio.
La seconda sorpresa
L’agenzia si è rivolta all’hosting come ripiego. Molti host gestiti conservano i propri backup, indipendenti da qualsiasi plugin. In questo caso, la conservazione dei backup dell’host era di 30 giorni. Si sospettava che la compromissione fosse iniziata circa 45 giorni prima della scoperta. I backup dell’host erano all’interno della finestra di compromissione, non prima.
Qualsiasi backup che l’host potesse fornire aveva una forte probabilità di contenere i file dell’attaccante. Ripristinare da quelli avrebbe semplicemente azzerato il cronometro. Non c’era alcun punto pulito precedente all’incidente a cui ripristinare.
Il percorso di ripristino che ha funzionato
Senza alcun backup pulito, il ripristino è dovuto avvenire file per file. L’istantanea forense del sito attuale è stata confrontata con un download fresco del core di WordPress, i file del tema sono stati verificati rispetto al controllo di versione dove esisteva, i plugin sono stati reinstallati dalle loro fonti ufficiali anziché riutilizzati dal codice compromesso, e il database è stato ripulito dai pattern dannosi noti senza essere riportato indietro.
Ha richiesto diverse volte più tempo di un semplice ripristino. Ogni passaggio è dovuto essere verificato. Il costo totale è stato consistente, e diverse migliorie del sito sono andate perse perché il codice del tema verificabile più recente proveniva da un’esportazione di mesi prima anziché dallo stato live. La pulizia ha funzionato, ma il costo è stato molto più alto di quanto avrebbe dovuto essere.
Il nuovo assetto di backup
Dopo l’incidente, l’agenzia è passata a un assetto di backup che usiamo sui siti WordPress che gestiamo. Le caratteristiche contano, quindi vale la pena essere precisi.
Backup incrementali giornalieri sia dei file sia del database. Backup completi settimanali. Tutti i backup archiviati fuori sede, in un account di storage non accessibile dal sito WordPress stesso, così che una compromissione non possa cancellare i backup insieme al sito live.
La conservazione è impostata affinché i backup restino disponibili per almeno 90 giorni. Questo offre una finestra pulita precedente all’incidente anche per compromissioni a lenta combustione.
Le notifiche di allerta per i backup falliti vanno a una casella aziendale monitorata, non a un’e-mail personale. Due persone ricevono gli avvisi, così che le ferie di una sola persona non possano mascherare un fallimento.
Un test di ripristino trimestrale viene eseguito su un ambiente di staging. Il backup viene scaricato, ripristinato e verificato rispetto al sito live. Se qualcosa è rotto, viene corretto prima del trimestre successivo.
Cosa puoi fare oggi
Se questo caso ti suona scomodamente familiare, ecco un breve elenco di passaggi che puoi eseguire questa settimana. Ognuno richiede pochi minuti.
Accedi a qualunque destinazione ricevano i tuoi backup. Conferma che il file più recente sia di oggi o di ieri. Conferma che i file siano arrivati con costanza negli ultimi 90 giorni. Apri l’indirizzo e-mail che dovrebbe ricevere le notifiche di fallimento dei backup e conferma che sia ancora monitorato.
Scegli il backup più recente. Scaricalo. Prova a ripristinarlo su un sito di staging o in un ambiente locale. Assicurati che funzioni davvero come backup, non solo come file.
Controlla la conservazione dei backup del tuo host. La finestra di conservazione è abbastanza lunga da coprire una compromissione lenta? Se no, integrala con una soluzione esterna a conservazione più lunga.
Il principio
Un backup è reale solo una volta che lo hai ripristinato. Fino ad allora è un’ipotesi. Il costo del test è piccolo. Il costo di scoprirlo nel modo più duro è abbastanza grande da minacciare il ripristino stesso. Tratta la verifica dei backup come parte della tua routine, non come una cosa a cui arriveresti un giorno.
Ti serve una mano?
Se il tuo assetto di backup WordPress ha delle lacune, in Defyn possiamo verificarlo, impostare backup esterni affidabili con la giusta conservazione, eseguire un test di ripristino per verificare che funzioni e assicurarci che gli avvisi arrivino a persone che li vedranno. Contattaci e ti daremo un assetto di backup su cui poter davvero contare.
