Cari amici, se non volete avere la sgradita sorpresa di aprire un giorno il vostro sito e ritrovarvelo così …

… per poi correre ai ripari nella disperazione più totale, ripercorrendo le revisioni del post alla ricerca del vostro sudato articolo al fine di ripristinarlo,

credo sia utile tornare a parlare di sicurezza ma, notate bene, non è mia intenzione darvi in pasto l’ennesimo articolo sulle 10 cose da fare o i 30 consigli per difendere un sito Wp dalle intrusioni perché in rete ci sono già tante autorevoli fonti che ne parlano, essendo gli autori, professionisti del settore.

No, io voglio dirvi le cose dal mio punto di vista – di persona meno esperta, che fa mille altre cose nella vita e a cui piace “smanettare” sul proprio blog per fare esperienza – parlandovi di quei problemi che per altri sono talmente scontati che non vale la pena spendersi!

A cominciare dall’errore di installare WordPress su un server Windows cosicché ogni volta che cerco informazioni per inserire un data istruzione nel mio blog, trovo un sacco di “pezzetti” di codice da aggiungere al file htaccess – quel magico file di configurazione che permette di, visualizzare, spostare, nascondere, reindirizzare … – che funziona solo su server Linux!
Quasi nessuno vi dice che in alternativa all’htaccess c’è il web.config, che è l’analogo file per Windows.
Sapere questo, è fondamentale soprattutto per impostare il redirect da HTTP a HTTPS (di cui vi parlerò più avanti).

Se spostate e rinominate la cartella wp-content vi può essere utile questa guida, creata per chi ha un hosting Aruba, cui aggiungo un ulteriore passaggio omesso dall’autore, che ho trovato su Flavioweb:
«aprire il file wp-config.php (scaricando in locale la versione aggiornata dal sito con FileZilla)
posizionarsi appena prima del commento  /* Finito, interrompere le modifiche! Buon blogging. */
e inserire queste righe di codice:

/* path alla nuova directory wp-content */
define( ‘WP_CONTENT_DIR’, ABSPATH . ‘nuova-cartella/alias-wp-content’ );
/* URI completo della nuova directory  */
define( ‘WP_CONTENT_URL’, ‘http://www.tuosito.it/nuova-cartella/alias-wp-content’);

Sostituire nuova-cartella con il nome scelto e fare la stessa cosa con la cartella alias-wp-content.
Salvare il file e caricarlo via FTP sovrascrivendo il vecchio.»

Anche qui, mi permetto di segnalarvi una cosa non troppo scontata: attenzione agli apici!!! Si, perché quando fate il copia-incolla di un testo da Internet è possibile che gli apici del font usato siano diversi da quelli accettati dal php per cui quando salvate e fate l’upload del file con FileZilla: BAM! vi compare pagina bianca con un bel “parse error” e voi non sapete a chi dire grazie!
Perciò, occhio alla sintassi. Io ho imparato a verificare sempre gli snippet di codice copiati sul web, inserendoli prima su Dreamweaver così se ci sono errori, il programma me li segnala ed evito di causare crash al sito.

Inoltre, se scegliete questa misura di sicurezza, ogni volta che farete l’aggiornamento di WP (manualmente) dovrete ricordarvi di sostituire il default-constants.php della cartella wp-includes con quello da voi modificato. Perché aggiornamento manuale? Sarà che io preferisco avere tutto sotto controllo, e fare aggiornamenti automatici mi pone nella condizione di non sapere cosa accade nel mio sito, salvo poi non sapere dove mettere le mani in caso di malfunzionamenti. Perciò, fin da quando è nato Meryweb, ho recuperato le istruzioni per aggiornare WP di persona. È una guida del 2012 ma funziona sempre a meraviglia a dispetto di altre più recenti che sono molto più confuse e complicate!

Quello che può capitare quando si mettono le mani nei file php – senza sufficiente padronanza – è di lasciare delle righe vuote al di fuori delle sezioni contrassegnate dai simboli di apertura <? e chiusura ?> del php o spazi bianchi esterni alle dichiarazioni di inizio o fine file. A quanto ho capito, non sono veri e propri errori, infatti il php non li rileva ma l’Xml invece non li accetta.
Risultato? Non si visualizzano più i feed e le sitemap. Io, dopo aver perso un’infinità di tempo per rintracciare l’errore, ho trovato un Feed validator che mi ha aiutata a capire cosa dovevo cercare e mi ha permesso di individuare il problema nel function.php.

Premetto che sono molto restìa ad installare plugin perché l’esperienza mi dice che si possono ottenere le stesse cose con un minimo di fatica, operando direttamente sul codice (ormai le fonti in rete sono tante e complete) e perché appesantiscono il database con una quantità industriale di tabelle. L’ultimo che ho installato per la sicurezza (Wordfense) – proprio perché volevo evitare di perdere 2 mesi a capire come farlo da sola – ha popolato il Db con la bellezza di 23 tabelle! Oltre al fatto che non mi funzionavano più le statistiche di Jetpack … Comunque, queste sono opinioni personali dalle quali potreste dissentire.

Ciò detto, ci sono 3 plugin che mi sento di consigliarvi:

1. WPS Hide Login, un plugin molto “leggero” che vi consente di cambiare (senza rinominare) l’url del modulo di accesso con una parola a vostra scelta;
2. Google Authenticator – Two Factor Authentication di miniOrange che impone una doppia autenticazione al login – come per le banche – e andrà a sostituire progressivamente Clef (la mia 1° scelta) che sarà dismesso il prossimo 6 giugno;
   
3. Brocken link checker che periodicamente (ogni quanto, lo stabilite voi) setaccia tutto il sito in cerca di link non funzionanti e ve li segnala per mail. Utilissimo se, come me, inserite molti link esterni nei vostri post, perché a distanza di anni i siti possono chiudere o cambiare indirizzo. E questo ha aggiunto solo 4 tabelle al Db.

L’altro passo fondamentale è cambiare il prefisso alle tabelle del Db, che di default è wp_. Cosa che si dovrebbe fare in fase di installazione di wordpress, ma se uno non lo sa … lo dovrà fare a sito avviato prendendosi un bel mal di pancia!
In realtà, seguendo le indicazioni di EveMilano è stato un gioco da ragazzi. Il sito è rimasto off-line solo per una decina di minuti e, a manovra completata, ha ripreso a funzionare al primo colpo. Nell’eseguire quest’operazione consiglio di controllare anche le altre tabelle, perché a seconda dei plugin installati potrebbero essercene alcune da rinominare che non sono menzionate nella guida. Questo scrupolo mi ha permesso di individuare delle tabelle sospette – aggiunte dall’hacker – che andavano eliminate.

Altre buone pratiche sono:

• cambiare il nome utente operando direttamente sul Db (l’importante che prima ne abbiate salvato una copia di backup), che non deve essere “admin” e nemmeno il vostro nome o quello del vostro sito (troppo facili da intuire);
• nascondere la versione Wp in uso;
• settare correttamente i permessi aggiungendo al file wp-config.php queste 2 semplici righe di codice:
  define(‘FS_CHMOD_FILE’,644);
  define(‘FS_CHMOD_DIR’,755);

Concludendo, l’applicazione di tutte queste misure di sicurezza di certo non risolve il problema delle intrusioni – anche perché Wp è una piattaforma libera e talmente diffusa che tutto ciò di cui abbiamo parlato finora, lo sappiamo noi come lo sanno gli hacker – ma almeno non lasciamo le porte aperte e li invitiamo ad entrare!