Come mettere WordPress al sicuro

Come mettere WordPress al sicuro

WordPress è una delle piattaforme di blog più diffuse e, al tempo stesso, più colpite dal virus, malware e codice malevole: in molti casi l’utente medio tende a non considerare determinati aspetti di gestione, e questo facilita moltissimo il compito degli script malevoli e ne mette costantemente a rischio la gestione.

In linea di massima, il suggerimento più importante per tenere WordPress al sicuro è quello di:

  1. aggiornare theme e core sempre all’ultima versione disponibile;
  2. evitare di adottare plugin molto vecchi, sia perchè dismessi / non più aggiornati che per altre ragioni (molti utenti, ad esempio, tendono a lasciare attivi plugin di molti anni fa perchè le nuove versioni sono diventate a pagamento).

Sul primo bisogna capire bene le motivazioni: le ultime versioni sono allineate su bug e falle di sicurezza, e riducono al minimo l’impatto di queste problematiche. In certi casi, inoltre, le falle che vengono progressivamente pubblicate fanno riferimento a vecchie versioni di WP, per le quali c’è il rischio che rimangano falle aperte anche per molti mesi, o addirittura anni. Aggiornate sempre, quindi, visto che è soltanto così che potrete davvero stare tranquilli di essere al sicuro da defacciamenti, cancellazione di dati o accessi indebiti al vostro sito.

Sul secondo punto, invece, è necessario mettere a fuoco una specifica cattiva abitudine di molti utenti, i quali tendono a lasciare le vecchie versioni dei plugin dato che non è possibile ripristinarle in caso di errori. Ma questo è un preciso meccanismo di protezione del sistema che non dovrebbe mai essere aggirato: WordPress infatti (e non è un caso) sovrascrive i vecchi aggiornamenti con i più recenti, e da qualche tempo – al contrario di quanto avveniva anni fa – disattiva in automatico i plugin che creano problemi in fase di aggiornamento. Questo è inevitabile perchè, col tempo, cambiano le versioni di PHP, vengono riparate le falle di sistema che molti malware potrebbero sfruttare e l’ambiente subisce delle modifiche irrevocabili. I plugin vecchi, se non si possono aggiornare, andrebbero soltanto rimossi o al limite rimpiazzati con altri equivalenti, stabili e sicuri. Tenere attivi plugin vecchi solo perché “fanno funzionare il sito” (fino a prova contraria, di fatto), crea un enorme bug di sicurezza che può essere un pericolo serio per la stabilità del sito.

Seguire la sicurezza del proprio sito in WP non è banale, e può a volte richiedere l’intervento di un esperto: come misura di base per gli utenti comuni, potete sfruttare apposite strategie per potenziare la sicurezza di WordPress.

Nella maggioranza dei casi, inoltre, le falle note di WordPress vengono segnalate, di solito non appena sono disponibili gli aggiornamenti del caso, nella sezione sicurezza di questo sito.

Come migliorare la sicurezza di WP

Cercherò ora di riassumere quindi i passi principali da compiere per

  1. capire cosa sia un problema (o falla) di sicurezza in wordpress;
  2. sapere come intervenire su un sito WordPress hacked.

Cosa è esattamente un “problema di sicurezza” per WP?

Una security issue (detta anche security vulnerability o vulnerabilità di WordPress) non è altro che un bug di programmazione, a volte grossolano altre molto meno ovvio, di cui una versione di WordPress è affetta. Solitamente, per come viene gestito ed aggiornato il CMS, le ultime versioni sono quelle meno affette da problemi di sicurezza delle altre. Difficilmente si potrà arrivare a versioni di WP immuni da problemi del genere perchè, nel frattempo, cambieranno le versioni dei software e gli hardware sottostanti, costringendo così gli sviluppatori a rivedere, periodicamente, tutte (o quasi) le issue del caso. L’immagine di falle che si aprono e si chiudono periodicamente credo restituisca un’immagine efficace, e realistica, dello scenario in cui lavoriamo ogni giorno.

Una vulnerabilità di sicurezza non è altro che un bug (di solito) nel core di WordPress ma, per estensione, potrebbe riguardare anche un plugin o un theme che state utilizzando, qualora quest’ultimo presenti porzioni di codice (ad esempio criptate) che effettuino operazioni pericolose per la sicurezza o la stabilità del CMS, o che ad esempio vadano a creare delle “porte di accesso” (o backdoor) per eventuali attaccanti.

Come, quando e perchè segnalare un bug sulla sicurezza

È possibile segnalare eventuali problematiche di sicurezza, ammesso che abbiate la sfortuna di trovarne una per la prima volta (cercate su Google prima), tenendo a mente i seguenti punti:

  1. se il vostro WP è stato defacciato (“hacked“, più in generale) questo non è in generale un problematica di sicurezza (nel senso in cui ne parliamo qui), perchè essa presuppone che siate in grado di stabilire in che modo l’attaccante ha sfruttato un bug o una falla a proprio vantaggio. Bisogna contattare WP via email o forum solo nel caso in cui sappiate dare informazioni molto precise a riguardo.
  2. se avete dimenticato la password di WordPress non si tratta, neanche in questo caso, di un problema di sicurezza. Dovreste resettare la password facendovene inviare una via email oppure, a seconda dei casi, contattando l’amministratore del sito WP su cui state lavorando.
  3. Di solito i problemi di sicurezza di WP sono tutt’altro che banali da identificare e comprendere: attenzione, quindi, a segnalare problemi che siano effettivamente tali e soprattutto ignoti in precedenza.
  4. Dopo tutte le verifiche del caso scrivete a WP per segnalare un problema che avete scoperto, eventualmente, ed il forum per segnalare problemi in corso che sono riconducibili a qualcosa di noto (ad esempio una versione fallata di WP o un plugin anomalo).

Come segnalare un problema di sicurezza?

Ci sono modi chiari e ben codificati per farlo.

  • Per un problema di sicurezza relativo a WordPress.com bisogna consultare la pagina di Automattic;
  • per un problema di sicurezza su un plugin, scrivete una mail a plugins [at] wordpress.org aggiungendo il maggior numero possibile di dettagli e, se possibile, contattando lo sviluppatore in merito al problema riscontrato, via email o (più comunemente) via forum associato alla pagina del plugin.
  • Se il problema riguarda un theme, rimuovetelo quanto prima via FTP dal vostro file system ed installatene uno di default.
  • Se invece il problema riguarda la sicurezza di una versione che avete installato su un hosting, scrivete a security [at] wordpress.org allegando il maggior numero di dettagli possibile.

È davvero corretto rendere pubblici i dettagli di un problema di sicurezza?

Cosa interessante: WordPress suggerisce di non pubblicare in nessun caso i dettagli sulle debolezze informatiche del suo CMS, considerata come attività irresponsabile e poco professionale (irresponsible and unprofessional). Il problema è che, piuttosto, la prassi di questi casi sia l’esatto contrario: su siti come seclists.org vengono pubblicati bollettini pubblici ogni giorno, relativi a problemi di sicurezza, e con vari livelli di dettaglio, che potrebbero effettivamente essere sfruttati all’istante da utenti malintenzionati.

C’è da dire che in certi casi le segnalazioni sono vaghe, e che molti siti hanno la prontezza di tenere d’occhio da sè la lista e provvedere volta per volta. Da un lato ha ragione WordPress ad attuare tale politica cautelativa, per quanto il mio punto di vista sia che, nonostante tutto, quei bug sarebbero comunque circolati una volta scoperti, per cui tanto vale che siano pubblicati e, sperabilmente, risolti così più in fretta di quanto avverrebbe diversamente. Del resto i bug di Microsoft o Adobe (esempi di politiche aziendali chiuse, contrapposte all’open source) vengono resi pubblici solo dopo essere stati risolti, il che – se ci pensate – è decisamente più angosciante di quanto non sia sapere da subito che esiste un problema: è come stare in una stanza in cui, dopo mesi di permanenza, scopriamo che un nostro coinquilino fosse affetto da una malattia sconosciuta ai più. A saperlo, per intenderci, avremmo preso provvedimenti: disattivato il plugin o il theme, al limite messo il sito in stop finchè il problema non fosse stato risolto. Invece così facendo è tutto nelle mani di pochi che, a propria discrezione, decidono se e quando sia il caso di dire la verità (come avvenuto, in un caso recente, sulle webcam fallate di alcuni modelli di Mac).

Il paradigma security throught obscurity (adottato anche dalla Apple, peraltro) mi convince sempre meno, e vi preferisco da sempre il principio di Kerchoffs che afferma:

  • In un sistema crittografico è importante tener segreta la chiave, non l’algoritmo di crittazione.

In altri termini: piuttosto che sconfinare nella paranoia, pensiamo a usare password robuste su WordPress, evitiamo plugin fallati (di solito sono quelli più borderline a dare problemi), lavoriamo su hosting tenuti al  e restiamo sempre a contatto con gli esperti, ad esempio iscrivendo a qualche mailing list sull’argomento.

 Il mio sito in WordPress è stato violato / defacciato / hacked: cosa posso fare?

Sono molte le cose che si possono fare, potreste risolvere in pochi minuti o in qualche ora ma è richiesto un certo livello di esperienza. Come prima cosa, se possibile, installate un plugin come Exploit Scanner che potrebbe esservi di aiuto per identificare il problema, ammesso che riusciate ancora ad accedere come amministratori al sito.

Per il resto, in ordine sparso, quello che faccio di solito è riassumibile in questa lista.

  • cambiare le password di amministratori ed editori del sito, se possibile;
  • se non è possibile accedere al sito via browser, disattivare i record A o i nameserver del sito per cautela, e per impedire ulteriori danni all’attaccante;
  • cambiare la password FTP, o rimuovere la vecchia utenza e ricrearne una nuova da cPanel;
  • scaricare tutti i log di sistema e rimuoverli in seguito;
  • provare a reinstallare l’ultima versione di WordPress sovrascrivendola a quella fallata;
  • rimuovere theme e plugin e, a seconda dei casi, riattivarli uno per uno o verificare su Google se ci siano falle aperte note su ognuno di essi (vedi punto precedente: se non fosse possibile saperlo da Google, sarebbe decisamente complesso intervenire in questi casi!);
  • verificare i permessi sul filesystem mediante CHMOD;
  • verificare il file htaccess, in caso ricrearne uno di default;
  • rigenerare le chiavi di sicurezza di WP (vedi security keys).

Come riconoscere un attacco su WordPress (e difendersi)

La sicurezza di WP è ormai diventata una priorità da cui nessuno dovrebbe prescindere, ed è importante installare un qualche plugin per la sicurezza che ci permetta di evitare defacing, accessi illeciti al sito mediante backdoor ed i classici brute force attacks (tentativi, di solito automatici, di entrare nel vostro sito indovinando la vostra password mediante un dizionario).

Un esempio pratico

Quando si installa iThemes Security (che considero il migliore e più completo plugin per la sicurezza ad oggi), qualche giorno dopo averlo settato vi potrebbero arrivare ripetute notifiche via email come questa.

Screen 2014-07-06 alle 12.15.50

Una “Site lockout notification” serve a notificarvi che, in base alla vostra specifica politica di sicurezza, qualche bot, script o utente ha violato le vostre regole tentando di entrare illecitamente nel vostro sito (provando ad indovinare la password di WordPress, ad esempio). Non è il caso di allarmarsi poichè questo genere di attacchi, purtroppo, sono all’ordine del giorno: sul blog che sto segnalando mi stanno arrivando periodicamente, e questo mi ha spinto a ridurre la tolleranza ai tentativi abbassando le soglie numeriche entro cui, in pratica, scatta il meccanismo di protezione. Considerate poi che, in linea di massima, gli hosting sono sempre più “bravi” a prevenire questo genere di attacchi, ma è chiaro che anche noi dobbiamo impegnarci perchè queste cose diventino poco pericolose (ad esempio scegliendo per gli utenti e per noi stessi password robuste).

C’è da dire che, con questo plugin, quantomeno sappiamo che la cosa stia avvenendo – in particolare il blog del cliente credo sia stato preso di mira da qualche bot – ed è probabile che anche il vostro blog in WP sia affetto dallo stesso problema: per evitare di trovarvi defacciati da un giorno all’altro, iTheme Security è un plugin che vi permette quantomeno di arginare il problema. Un ban più robusto e meno tollerante del solito permetterà, quindi, di aggirare ogni difficoltà, unito alla cura di cambiare le vostre password periodicamente e, soprattutto, a sceglierle con criterio.

Come scansionare le vulnerabilità di WP con WPScan

Schermata 2013-07-08 alle 10.41.49La cosa più incredibile, e direi sottovalutata, annessa agli attacchi informatici via web (e non solo questi, per la verità) è che gli strumenti per eseguirli quasi in automatico sono quasi sempre disponibili liberamente in rete. È ad esempio il caso di WPScan, un tool per la ricerca di threat ed exploit di wordpress: nel frattempo qualcuno sostiene addirittura che determinate vulnerabilità (come il fatto di “far capire” all’attaccante se la username esista o meno) siano a conoscenza del team di sviluppo ma, per qualche motivo, non siano state risolte.

Per funzionare, WPScan – come molti altri plugin di WordPress – richiede obbligatoriamente un’installazione Linux ed il supporto a Ruby, RubyGems e Git: esso permette, dopo l’installazione da riga di comando, di effettuare la scansione di qualsiasi genere di dominio (su cui sia installato WP), verificando anzitutto se effettivamente sia presente questo famoso CMS. Una delle funzionalità più potenti di questo tool è legata all’enumerazione delle username del blog, ed alla rilevazione automatica dei due noti punti di potenziale debolezza di WP: i plugin ed i temi buggati, difettosi, obsoleti o corrotti.

Non ho ancora avuto il tempo di sperimentare il tool, e preciserei che non è chiaro se le username, ad esempio, possano essere rilevate sempre e comunque su qualsiasi blog oppure se si tratti di un comune tipo di attacco brute-force, dato che wordpress “fa capire”, quando si sbaglia username o password, quale delle due sia errata, facilitando le operazioni ad un potenziale attaccante specialmente se si utilizzano username standard come “admin”.

Non entro ulteriormente nel dettaglio dell’applicazione, che è piuttosto ben documentata, ma mi limito a riportare una serie di esempi che, secondo il suo autore, si possono attuare per rendere la vita complessa a chi utilizza WordPress per il proprio blog.

    1. Check semplice di un sito per raccogliere le informazioni basilari;
    2. test delle password in modalità brute force mediante multi-thread (significa che il tempo di esecuzione della procedura avviene “in parallelo” e quindi impiega meno tempo del dovuto);
    3. test delle password mantenendo la username fissa (ad esempio “admin”);
    4. enumerazione dei plugin installati sul sistema;

enumerazione dei plugin in genere più popolari tra i blogger, alla ricerca di quelli risaputamente fallati.

Photo by Damian Gadal

Ti piace questo articolo?

0 voti

Su Trovalost.it puntiamo sulla qualità dei contenuti da quando siamo nati: la tua sincera valutazione può aiutarci a migliorare ogni giorno.

Ti potrebbero interessare (Guide WordPress):

Cerca altro nel sito

Clicca sul box, e scegli la sezione per vederne i contenuti.