I CMS (“Content Management System” o Sistemi di gestione dei contenuti) sono utilizzati molto di frequente nella realizzazione dei siti per via di alcuni indubbi vantaggi che presentano, primo fra tutti l’aggiornabilità dei contenuti da parte dell’utente finale al quale non vengono richieste conoscenze di HTML o CSS.

WordPress ha assunto da qualche tempo un ruolo dominante nel campo dei CMS grazie alla sua relativa semplicità d’uso, superiore a quella di Joomla! il quale, tuttavia, risulta preferibile per lo sviluppo di siti professionali e più complessi.

E’ proprio su WordPress che concentreremo l’attenzione nell’ipotesi, sventurata ma tutt’altro che infrequente, che la nostra installazione venga hackerata: brutto neologismo che sta ad indicare il fatto che un pirata informatico sia riuscito ad entrare in qualche modo nel sito ed abbia modificato i files esistenti e/o ne abbia scritti di nuovi, inserendo codice dinamico generalmente finalizzato ad impiegare il server per inviare e-mail di spam.

In tale ipotesi, spesso il proprietario del sito non si accorge neppure dell’infezione poiché il front-end del sito, cioè la parte visibile da tutti su Internet, non presenta alterazioni.

Operano anche hacker con obiettivi meno sofisticati i quali si limitano a sostituire la homepage del sito con una contenente la propria firma: in tale caso, il ripristino del sito è più semplice poiché richiede solo di ripubblicare la pagina stessa nella sua versione corretta – ferma restando la necessità di individuare le falle di sicurezza che gli hanno permesso l’accesso.

Andiamo ad elencare innanzitutto i fattori che riducono la probabilità che un attacco al nostro sito su piattaforma WordPress abbia successo:

1. scegliamo un servizio di hosting affidabile, a costo di spendere qualche euro in più.
   Se il server del fornitore e/o il relativo MySQL non sono protetti adeguatamente, il pirata passerà proprio attraverso essi (come si suole dire brutalmente ma con efficacia, “bucherà il server“) e noi potremo adottare qualsiasi precauzione ma sarà tutto inutile perché le difese che avremo eretto saranno aggirate.
   Se questo accade, avremo per lo meno l’occasione di valutare la serietà professionale del fornitore stesso: alcuni si affanneranno a negare qualsivoglia responsabilità, in tale caso è certamente opportuno cambiare domiciliazione per il sito.
2. scegliamo solo plugin affidabili e sperimentati.
   Il repository ufficiale dei plugin di WordPress è molto efficiente e la comunità di utenti ampia e, in generale, competente sicché un plugin mal sviluppato risulterà rapidamente “bocciato” dalla stessa.
   Evitiamo le sperimentazioni e le versioni beta dei plugin; attendiamo che lo sviluppatore abbia corretto gli errori e le eventuali falle iniziali prima di sceglierli per il nostro sito.
   Consultiamo la pagina del supporto dei plugin ai quali siamo interessati per leggere i problemi incontrati dai precedenti utilizzatori, se ve ne sono stati.
3. manteniamo aggiornati WordPress ed i plugin.
   I CMS presentano grandi vantaggi ma la contropartita degli stessi è che risulta necessaria una manutenzione periodica, rappresentata appunto dagli aggiornamenti.
   Gli aggiornamenti minori, delle sottoversioni, cioè del tipo da: 4.7.x a 4.7.y verranno applicati automaticamente, a meno che abbiamo installato un plugin che li blocchi (o abbiamo inserito codice apposito nel file wp-config.php come spiegato qui: https://codex.wordpress.org/Editing_wp-config.php#Disable_WordPress_Auto_Updates).
   Gli altri aggiornamenti, cioè quelli della piattaforma in caso di release maggiori e quelli dei plugin, dovranno essere effettuati manualmente.
   Prima di procedere a qualsiasi update, è necessario disporre di copie di backup. Non è purtroppo così infrequente incappare in problemi dopo gli aggiornamenti dei plugin, a causa di incompatibilità precedentemente non esistenti: in tale ipotesi, il rollback cioè ritornare alla versione precedente del plugin rappresenta la soluzione più semplice (rammentiamo che nel repository dei plugin sul sito di WordPress sono disponibili quasi sempre le versioni precedenti degli stessi, nella scheda Developers della homepage del plugin) viceversa è necessario individuare il conflitto disattivando tutti gli altri plugin per riattivarli uno ad uno, rilevando quando esso inizia a presentarsi.
   Nell’ipotesi in cui un plugin sia stato customizzato, l’aggiornamento causerebbe la perdita delle modifiche: la cosa migliore da fare, in tale ipotesi, è editare il file principale dello stesso là dove sono presenti i riferimenti della versione incrementandone il numero, come nell’esempio che segue:
   da: Version: 3.1.10
   a: Version: 100.1.10
   In questo modo, non sarà mai rilevata in automatico la necessità di aggiornamento del plugin.
4. installiamo un plugin di firewall.
   Ce ne sono alcuni piuttosto efficienti, in grado di individuare e bloccare alcuni tipi di attacco tra i quali il brute force, vale a dire l’inserimento ripetuto di combinazioni username/password tipiche nella speranza di azzeccare quelli applicati dall’amministratore distratto, o determinate “iniezioni” di codice.
   Il firewall non è in grado di proteggere il nostro sito dagli attacchi diretti al server o al database, ovviamente: un caso tipico è quello in cui troviamo nell’elenco un nuovo utente (vedi sotto) avente un nome che abbiamo esplicitamente escluso nelle impostazioni del firewall stesso.
5. non usiamo username o password banali!
   MAI usare le username tipiche come admin, administrator, user ecc. né il titolo del sito.
   I bots degli hacker tentano di accedere usando quelle per prime; se poi la password è “1234” o “password” o simili … addio sicurezza!
6. backup, backup e poi ancora backup!
   Non si tratta ovviamente di una misura che possa prevenire l’attacco, tuttavia la disponibilità di copie di backup aggiornate e sicuramente funzionanti di 1) files di WP, 2) plugins e soprattutto 3) database renderà molto più facile e veloce il ripristino.
   Per ottenere 1) e 2) è ovviamente sufficiente una connessione FTP mentre per 3) si potrà ricorrere ai backup manuali tramite l’interfaccia phpMyAdmin o, preferibilmente, tramite un plugin.
   Meglio disporre di più copie, soprattutto del database perché è evento raro ma non impossibile che l’esecuzione del backup automatico da parte del plugin scelto generi un file corrotto e, quindi, inutilizzabile.

Ora, vediamo come capire che il nostro sito è stato attaccato ed infettato:

• presenza di utenti anomali nel back-end di WordPress.
  Gli attacchi creano uno o più utenti fasulli con credenziali di amministratore visibili nel relativo elenco.
  Questi utenti hanno di solito nome backup, admin, administrator o simili in base all’idea che possano passare via senza essere notati in caso di disamina superficiale da parte del proprietario del sito, specialmente se sono registrati molti utenti (in un sito che permette la registrazione da parte degli utenti come Sottoscrittori).
• dimensione dei files modificata.
  Comparando i files del sito tramite un programma FTP che mostra simultaneamente i files sul nostro PC e quelli remoti, noteremo facilmente che la dimensione in Kb di questi ultimi è nettamente maggiore perché vi è stato scritto dentro il codice malevolo.
• presenza di files precedentemente non esistenti.
  L’attacco potrebbe generare la creazione di uno o più files che non fanno parte originariamente del sito, facilmente individuabili anche in questo caso tramite il confronto dei files in locale ed in remoto.
  Un classico esempio, un file options.php scritto nella root del sito.
• front-end non più funzionante.
  Non è così frequente che l’infezione causi il malfunzionamento del sito, per un semplice motivo: se ciò accade, il suo proprietario di aziona per cercare le cause e rimuoverle.
  Se invece il sito continua a funzionare regolarmente, l’infezione può teoricamente proseguire la sua azione.
  A meno che …
• blocco del sito da parte di Google.
  L’ipotesi peggiore, una sorta di incubo, è che si arrivi al punto in cui l’accesso al sito viene bloccato da Google e/o vengano mostrati avvisi di “pericolo” nei risultati di ricerca.
  Non tutto è perduto ovviamente, nel senso che sarà possibile ripulire il sito e segnalare a Google stessa che non è più presente alcun pericolo, ottenendo il reinserimento regolare negli indici.
  E’ decisamente opportuno non attendere di arrivare a questo punto, effettuando controlli periodici del buon funzionamento e dell’integrità del nostro sito.

[Segue nell’articolo: come eliminare l’infezione e ripristinare il sito – di prossima pubblicazione]