WordPress Security

WordPress Security

WordPress Security

Ovvero come evitare che il sito in WordPress sia bucato, o morire nel tentativo di proteggerlo.

Anche se è decisamente OT, ho deciso di dedicare questo articolo alla sicurezza sul web; descrivo alcuni metodi che si usano per violare un sito WordPress, e le contromisure da applicare per difendersi.

Il Webserver

Per parlare la stessa lingua, dedico due parole al webserver. Se hai proprietà sull’argomento, passa al paragrafo successivo.

Un webserver è generalmente costituito da almeno tre componenti:

  • http server
  • application server
  • database server

Il server http è quello che si occupa di gestire il traffico web da e verso il sito, ovvero riceve le chiamate dei browser (request), quindi crea, impacchetta e invia le risposte (response); il traffico web si muove sul protocollo HTTP.

Le risposte del web server ad un client possono contenere risorse statiche, come immagini, fogli di stile, pagine html, oppure risorse dinamiche.

La creazione delle risorse dinamiche è delegata all’application server, che grazie a specifici programmi è in grado di confezionare pagine web con contenuti differenti in base alle richieste dei client. Gli application server più usati si programmano in PHP, Java, .NET, ma vi sono anche altri linguaggi.



L’application server è in grado di parlare con il database server per reperire i contenuti delle pagine web da servire ai client. Vi parla con un linguaggio chiamato SQL, con il quale è in grado si scegliere il contenuto richiesto da una serie di tabelle, che possono contenere migliaia di righe, impacchettarlo in una pagina html e spedirlo al client.

Ebbene, ognuno di questi sistemi può avere vulnerabilità che consentono a un malintenzionato di prendere il controllo di un sito, o peggio del server su cui viene eseguito.

Non parlerò degli attacchi diretti al webserver, perchè sono piuttosto complessi da attuare, e per comprenderli occorre una profonda conoscenza dei protocolli di cumunicazione di basso livello utilizzati e delle possibili falle da attaccare.

Parlerò invece di vulnerabilità sfruttabili con semplici tool, scaricabili da chiunque e di facile reperibilità sul web.

Remote command execution e code injection

Il linguaggo alla base di WordPress è PHP che, come qualsiasi linguaggio di programmazione lato server, è ingrado di interagire con il sistema che lo ospita (il server fisico o virtuale), e gestire alcune risorse, quali la creazione di file.

Grazie a queste caratterisriche è possibile creare siti web dinamici, ma è possibile che qualche malintenzionato le utilizzi per i propri scopi.

Tramite la tecnica del remote command execution è possibile che un attaccante riesca a far eseguire a PHP dei comandi di sistema, con i quali può importare direttamente nelle cartelle del sito codice malevolo eseguibile tramite PHP stesso.

A questo punto le possibilità dell’attaccante sono infinite: dall’inserimento di spam nelle pagine, alla violazione del database e la conseguente creazione di un utente amministratore, alla creazione di un relay verso altri siti, all’inserimento di un attacco DDOS verso un bersaglio terzo, insomma un completo disastro.

Sempre tramite il protocollo HTTP è possibile eseguire attacchi di code injection; un vero classico è l’SQL injection, ovvero l’iniezione di codice malevolo SQL (attraverso i parametri HTTP) al fine di violare il database del sito e rubarne o modificarne i contenuti. Da immaginare il dramma se nel database ci fossero i numeri delle carte di credito dei clienti.

Come proteggere il sito in WordPress?

Il primo passo in assoluto è aggiornare sempre il core di wordpress e tutti i moduli.

La gran parte della difesa da remote code execution e code injection viene attuata dal continuo sviluppo del team di WordPress, e da tutti i contributors che creano i moduli.

E’ possibile aggiungere sicurezza a WordPress con un semplice trucco: proteggere tramite il webserver (Apache HTTPD) l’accesso alla cartella /wp-admin con un file .htaccess.

Ovviamente questa non è la tecnica definitiva per proteggere WordPress, ma fornisce una valida scrematura per una buona parte di attacchi.



I file htaccess contengono istruzioni per il webserver, e si usano per cambiarne il comportamento, ad esempio per agli utenti un’autenticazione per alcuni percorsi. Spesso chi attacca cerca di intrufolarsi in alcuni file atti all’amministrazione del sito. Bloccando l’accesso a questi file, si blocca l’attacco alla radice.

In buona sostanza si crea un file chiamato .htaccess all’interno della cartella /wp-admin contenente il seguente codice:

AuthType Basic
AuthName "wp admin"
AuthUserFile /{path to}/wp-admin/.htpasswd
Require valid-user

<Files "admin-ajax.php">
	Require all granted
</Files>

Ovviamente {path to} va sostituito con il percorso reale al file.

A questo punto occorre creare il file che contiene user e password per l’accesso all’area protetta. Si deve chiamare .htpasswd e deve contenere un testo simile a questo:

user-name:password

Alcuni provider forniscono un servizio automatico per la creazione di file .htaccess e .htpasswd per la protezione di aree dei siti; possono essere utilizzati a patto di modificare il file .htaccess aggiungendo il seguente pezzo di codice, che serve per far funzionare liberamente il file admin-ajax.php utilizzato da alcuni moduli:

<Files "admin-ajax.php">
	Require all granted
</Files>

Fatto questo, il webserver chiederà un’autenticazione prima di mostrare la pagina di login.

Brute force attack

Anche l’attacco di tipo brute force è un classicone. Consiste semplicemente nel provare a passare alla pagina di login di WordPress migliaia di nomi utente e password, nel tentativo di trovare quello giusto.

Sembra un attacco banale, ma se le credenziali di amministrazione di WordPress fossero ‘admin’ con password ‘12345‘ sarebbe esattamente come non avere la password, perchè un attacco brute force la troverebbe in pochi tentativi.



La prima protezione da questo tipo di attacco è utilizzare nome diverso da ‘admin’ per le credenziali di amministrazione, con una password davvero robusta, contenente numeri, caratteri speciali, lettere maiuscole e minuscole.

Esistono anche moduli dedicati a mitigare questo tipo di attacco, aggiungendo captcha e limitando gli errori di login prima di bloccare un ip, ma se la password è debole, qualsiasi contromisura serve a poco.

mod_security2

Un cortibuto piuttosto importante alla sicurezza dei siti in generale è fornito dal mod_security, un firewall applicativo in grado di analizzare tutte le parti di una request e una response, e bloccare l’accesso incaso riscontri l’impornta di una minaccia.

Mod_security riesce a riconoscere una moltitudine di attacchi, e ad attuare le contromisure necessarie per bloccarli.

Il sistema è complesso, ed è disponibile solo se il provider lo fornisce, o se siete proprietari di una VM (Virtual Machine) su cui gestite anche l’aspetto della sicurezza.

Occorre effettuare un buon tuning del livello di sicurezza applicato, perchè potrebbero essere riscontrati falsi positivi che bloccano alcune funzionalità di WordPress.

Ho scritto un file di configurazione per il server Apache HTTPD + mod_security2 atto a minimizzare i rischi e a bloccare gli attacchi di tipo brute force, da aggiungere al file .htaccess presente nella root di WordPress. Ovviamente il file è inutile se il mod_security non è installato sul webserver.



Importante: la regola del mod_security applicata alla location /wp-login.php effettua un conteggio delle login errate sia per IP sia per nome utente, e blocca un ip dopo 10 tentativi di login falliti, e un nome utente dopo 5 per cinque minuti.

Il sistema protegge quindi da un attacco brute force sia in base all’IP (se fosse univoco durante tutto l’attacco, cosa non sempre vera), sia in base all’utente WordPress attaccato. Ovvero, se l’utente ‘admin’ venisse attaccato, l’attaccante verrebbe bloccato dopo 5 tentativi errati, ma non solo l’attaccante, chiunque cerchi di fare login su quell’utente.

Da qui l’importanza di utilizzare uno user name non standard per l’utente di amministrazione del sito.

Inoltre conoscendo la subnet con la quale ci si connette al sito, è possibile escluderla dalla regola di protezione contro attacco brute force, ed avere sempre accesso al sito (vedi ultime righe del file di configurazoine). Chiaramente il sito non sarebbe protetto da un attacco proveniente proprio da quella subnet.

La calda sicurezza di un backup

Bene, ho spiegato sommariamente alcuni tipi ti attacco che può subire un sito web, e proposto alcune soluzioni di protezione più o meno semplici.

Nel caso un attaccante riesca a sorpassare le vostre difese, esiste una sola soluzione: backup, backup e ancora backup!

Il backup dev’essere di tutti i file e del database. Esistono parecchi moduli che automatizzano questa operazione, chè può anche essere eseguita a manina.

Fate copie di sicurezza del vostro sito, distribuitele ad amici e parenti, salvatele in cloud, su pc, chiavette, dove vi pare, perchè il backup è l’unica via per ripristinare un sito corrotto.

root