Come aumentare la sicurezza di WordPress
Recentemente ho terminato di sviluppare un progetto per il quale ho utilizzato wordpress. Si tratta di un gestionale aziendale con moltissime funzionalità ed all’interno del quale vengono conservate informazioni di una certa confidenzialità; non numeri di carte di credito o codici di lancio di testate nucleari ma comunque dati che richiedono un’accresciuta attenzione.
Così ho fatto una ricerca approfondita su quali possono essere gli accorgimenti da mettere in atto per migliorare la sicurezza di wordpress ed ho pensato di condividere con voi quello che ho potuto raccogliere. Ho trovato cose che già sapevo e mettevo in atto, cose per le quali mi sono detto “… però, non ci avevo pensato..” ed altre che francamente trovo discutibili. Ma vediamole insieme iniziando dalle cose facili.
1. Qualità dell’hosting
Questa é una cosa che incredibilmente non ho trovato nelle mie ricerche, forse perché la danno tutti per scontata, ma non io. La prima linea di difesa da attacchi informatici é il server stesso.
Se ti serve sicurezza, di certo non la troverai in servizi che offrono hosting “professionale”(?!) per 2 euro l’anno. Da quando ho scritto la serie di tutorial sui pagamenti online, il 100% degli utenti che hanno avuto problemi utilizzavano servizi di hosting “popolari”.
Per fare lavori seri, ci vogliono strumenti seri. Cosa pensereste se andaste in ospedale per farvi operare e sul tavolo del chirurgo ci fosse una motosega, degli scalpelli ed un tagliere per il salame?
2. Permessi a livello di server
Permessi di scrittura
Un primo step per elevare la sicurezza é verificare i permessi di scrittura di files e cartelle che devono essere:
- 755 per le cartelle
- 644 per i files
Questa dovrebbe essere un’impostazione di default del server, in caso contrario modifica i permessi.
Impedire il browsing
Un altro step é impedire la navigazione nelle cartelle senza index, aggiungendo all’inizio del file .htaccess questa riga.
Options -Indexes
Ecco due operazioni tanto semplici quanto importanti, non dimenticarle.
3. Depistaggio
Quando scriviamo un’applicazione, una discreta parte di sicurezza é data dal fatto che il malintenzionato non sa nulla del codice, dell’organizzazione del database, delle procedure utilizzate, eccetera.
Ovviamente non possiamo contare su questa barriera quando utilizziamo del software open source; anzi il fatto che il funzionamento sia trasparente, fornisce una moltitudine di informazioni al malintenzionato. Per questo motivo dobbiamo evitare, per quanto possibile, che le forze del male possano trarre vantaggio dalla conoscenza di alcuni meccanismi.
Eliminare l’utente admin
Se installiamo wordpress così come ci viene proposto, non sarà un segreto per nessuno che:
- Nella tabella wp_users c’é un utente con diritti amministrativi
- Questo utente ha ID 1
- Questo utente – se in fase di installazione non avete scelto un nome diverso – si chiama admin
Così diamo un po’ troppo vantaggio alle forze del male, non credi?
Crea un nuovo utente con privilegi di amministratore ed un nome diverso e rimuovi l’utente admin.
Quello che dobbiamo evitare é che vi sia un utente con diritti amministrativi che si chiami admin e/o abbia id = 1, altrimenti é troppo facile
Modificare il prefisso delle tabelle del database
Se lasciamo che wordpress utilizzi il prefisso di default (wp_), tutto il mondo saprà il nome esatto delle tabelle contenute nel database. Questo evidentemente é una facilitazione per i malintenzionati che volessero tentare delle query injection.
Modificando il prefisso delle tabelle faremo un altro passo verso il miglioramento della sicurezza.
Questa operazione va fatta in fase di installazione modificando la costante nel file wp-config.php.
Per gli utenti più esperti é possibile fare questa modifica anche in un secondo tempo, ma bisogna sapere quello che si sta facendo!
Spostare il file wp-config.php
Dalla versione 2.6, é possibile spostare il file wp-config.php in una cartella superiore rispetto a quella dove risiede di default, e wordpress troverà comunque il file.
Questa procedura l’ho trovata citata più volte nelle mie ricerche ed ho sempre avuto dei seri dubbi sul come questo potesse migliorare la sicurezza.
Ho infine trovato, nella documentazione ufficiale di wordpress, che al riguardo c’é una controversia. C’é chi addirittura ritiene che questo possa peggiorare la sicurezza.
Secondo me non cambia nulla.
Nascondere la versione di wordpress
Per il malintenzionato, conoscere la versione di wordpress, può essere un piccolo vantaggio.
Nell’header normalmente la versione viene mostrata con questo metatag
<meta name="generator"; content="WordPress 3.4.2" />
Nel corso delle mie ricerche ho visto più volte citata la procedura per rimuovere questo metatag dall’header, che é la seguente:
// da aggiungere al file functions.php
function remove_wp_version() {
return '';
}
add_filter('the_generator', 'remove_wp_version');
Trovo questa procedura, messa in atto così com’é, semplicemente ridicola! Gli utenti più esperti sanno certamente che a qualsiasi script o foglio di stile per il quale, in fase di queuing non é stata definita una versione, verrà assegnata automaticamente la versione corrente di wordpress.
Dunque se ci si limita a questo, non serve a nulla. Bisogna anche rimuovere l’aggiunta automatica della versione che applica wordpress, ma questo é stato bellamente ignorato da tutti.
Aggiungi anche il seguente codice al file functions.php
add_filter( 'script_loader_src', 'remove_src_version' );
add_filter( 'style_loader_src', 'remove_src_version' );
function remove_src_version ( $src ) {
global $wp_version;
$version_str = '?ver='.$wp_version;
$version_str_offset = strlen( $src ) - strlen( $version_str );
if( substr( $src, $version_str_offset ) == $version_str )
return substr( $src, 0, $version_str_offset );
else
return $src;
}
Infine i nostri sforzi di nascondere la versione saranno stati vani se non cancelliamo i file leggimi.txt, leggimi.html, licenza.txt, licenza.html dalla root di wordpress. E ricorda di controllare dopo ogni aggiornamento; é probabile che questi files vengano riscritti.
4. Sicurezza password
Modificare le chiavi di salatura
Anche se dovrebbe essere scontato, non dimenticare di modificare le chiavi di salatura contenute nel file wp-config.php. La via migliore é quella di generarle tramite le apposite API di wordpress, semplicemente cliccando su questo link.
Password complesse
Anche qui siamo nel campo dell’ovvio. Se sei l’unico utente del sito non c’é problema, dipende solo da te. Ma se il tuo blog ha diversi utenti (come nel caso di yiw), chi può garantirti che gli altri utenti abbiano delle password sufficientemente robuste? Io ad esempio come password uso maurizio, se Nando lo sapesse mi ucciderebbe.
Per risolvere questo problema esistono dei plugin come questo, che obbligano gli utenti ad avere delle password complesse.
Prevenire gli attacchi “brute force”
Per bloccare questo tipo di attacchi é sufficiente installare uno dei numerosi plugin, ad esempio questo. È possibile impostare dopo quanti tentativi falliti di login dal medesimo IP far intervenire un blocco di una durata definibile. È un piccolo accorgimento che vale la pena di mettere in atto.
Proteggere la cartella wp-admin
Possiamo infine sottomettere l’intera cartella wp-admin all’autenticazione a livello di server (tramite file .htaccess come ho illustrato in questo articolo).
Chiaramente diventa un po’ scomodo in quanto bisognerà compilare due login per accedere al backend amministrativo, ma é stato dimostrato che questa tecnica aumenta notevolmente la sicurezza.
Prevenire gli attacchi MITM
E’ possibile prevenire gli attacchi MITM (Man in the middle) attivando il protocollo cifrato sul login e/o sull’area amministrativa aggiungendo a wp-config.php la seguente riga:
define('FORCE_SSL_LOGIN', true);
// per il solo login
define('FORCE_SSL_ADMIN', true);
// per il login e l’area amministrativa
Naturalmente in questo caso il server deve supportate il protocollo ssl (e qui ritorniamo al punto 1 di questo articolo) e bisogna disporre di un certificato.
Conclusione
In questo articolo abbiamo visto una serie di stratagemmi per rendere perlomeno la vita difficile alle forze del male. Possiamo aggiungere che mantenere aggiornato wordpress e i plugin é un ulteriore aiuto in questa eterna battaglia. A proposito di plugin, se ne hai le competenze, ti invito a dare sempre un’occhiata al codice. Non tutti i plugin sono scritti a regola d’arte e in alcuni casi introducono delle vulnerabilità.
Per concludere ti segnalo un plugin, Better WP Secutity, che provvede a svolgere diverse delle cose che abbiamo visto ed implementa anche funzioni di monitoraggio ed altro. L’unico problema: usa tante risorse.
E tu? Hai altri consigli da dare su questo argomento?
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
55 commenti
Trackback e pingback
-
Wordpress – Rendere sicuro il sito dagli attacchi di hacker | Sir Bit
[...] Un ottimo articolo su Your Inspiration Web sulla sicurezza in WordPress [...] -
Perché non sottovalutare la sicurezza del tuo sito Wordpress | Your Inspiration Web
[…] Tarchini proprio su YIW un anno fa avevamo visto alcune caratteristiche e best practices per rendere sicuro WordPress che…
Ora non ho tempo di leggerlo, ma sapendo chi l’ha scritto sarà sicuramente ottimo, feedback coming soon :D
Aspetto il feedback allora ;-)
Coinciso ed utile! :) bell’articolo.
Grazie Marco
Se WP è installato nella cartella root del sito (di solito chiamata ‘httpdocs’) ne consegue che il file wp-config.php può essere messo in una cartella che è al di sopra della cartella accessibile dal browser e questo migliora la sicurezza. Per fare questo bisogna oppurtamente configurare il server e avere la possibilità di poterlo fare: si ritorna sempre al punto 1 dell’articolo.
Era proprio l’intento, poter mettere il file di configurazione in una cartella non browsabile. Ed é appunto su questo che c’é la controversia.
Utile, chiaro e conciso! Articolo subito nei preferiti! Ho già detto utile?
Grazie Valerio
Ottimo articolo, molte delle cose descritte le uso, ho creato un file security da includere nel file functions.php così ho sempre tutto pronto. :)
Rispetto a quelli sopra citati uso anche questo piccolo snippet
add_filter( ‘login_errors’, create_function(‘$a’, “return null;”) );
in modo da nascondere eventuali messaggi di errore in fase di login.
Riguardo alla pagina di login non uso un doppio login ma ho installato questo plugin.
http://wordpress.org/extend/plugins/wsecure/ che aggiunge una chiave senza la quale non si può accedere a wp-admin.php. Secondo voi è comunque una buona soluzione?
Infine c’e’ anche il plugin autologout che effettua il logout dell’utente dopo un periodo di inattività.
Premetto che non ho provato wsecure. Ma la differenza é che proteggendo la cartella wp-admin tramite .htaccess non si protegge solo il login, ma l’intera cartella wp-admin
Un’ulteriore domanda, ho effettuato la protezione della directory wp-admin creando il file .htaccess e .htpasswd e come è normale che sia per poter accedere al login mi chiede di inserire user e password. Però se invece di accedere alla pagina di login tramite l’url miosito.it/wp-admin digito miosito.it/wp-login.php posso comunque accedere alla pagina di login. Non vorrei aver sbagliato qualcosa ma in questo modo effettivamente che pro ha l’uso di una tale protezione?
Sorry, come non detto era successo un mezzo pasticcio.
Articolo molto interessante, complimenti cercherò di condividerlo in giro.
Grazie mille!
Grazie a te Andrea
Ciao Maurizio,
Complimenti per l’articolo! Molto utile e interessante.
Ho visto che ad inizio articolo dici che hai sviluppato un gestionale con WordPress. Ti chiedo in merito come ti sei trovato e che limiti rilevi in termini di frubilità, prestazioni, sviluppo, ecc., in tale soluzione. Mi sto approcciando a un lavoro simile per un cliente e sono molto dubbioso in merito. Chiaramente se procedessi con WP i tuoi consigli sulla sicurezza sarebbero certamente messi in atto.
Complimenti e a presto
Andrea
Ho scelto wp perché é il cms che conosco meglio e l’unico con il quale riesco a fare tutto quello che voglio. tutto li :-)
Concordo sulla versatilità di WordPress e aggiungo anche che possiede la migliore amministrazione da fornire ai clienti (si risparmiano ore ed ore di formazione).
Ottimi suggerimenti, molti erano conosciuti ai più. Il file .htaccess era aggirabile se mal configurato, bisogna configurare ogni tipo di “Richiesta” e di richieste non sono solo GET e POST.
Se dichiari una document Root (su apache) non puoi andare sopra, quindi è fuori gestione webserver.
Vorrei prendere al volo quello che ha scritto Wido
add_filter( ‘login_errors’, create_function(‘$a’, “return null;”) );
invece di ritornare un errore null. Potremmo creare una funzione che logga gli accessi errati su file o mandi un email.
Eviterei il più possibile l’utilizzo di plugin. Per il resto un ottimo articolo.
Per quello c’è limit login attempts come scritto nell’articolo http://wordpress.org/extend/plugins/limit-login-attempts/ Tranne che l’idea è comunque l’invio di una email all’amministratore per ogni login fallita. In quel caso puoi benissimo usare la funzione wp_mail. Una cosa veloce veloce sarebbe questo snippet:
function login_errors_email()
{
wp_mail(’email@host.com’, ‘Errore login’, ‘errore login’);
}
add_filter(‘login_errors’, ‘login_errors_email’);
Per il salvataggio di login errati non saprei, per poter prelevare i valori nei campi di input necessiterebbe l’uso di javascript no? Non so se c’e’ già qualcosa messa a disposizione da wp.
Per gli indirizzi ip si potrebbe prelevarli da php sbaglio?
i valori dei campi li trovi in POST, gli indirizzi ip li trovi nell’array SERVER, indice REMOTE_ADDR.
Ma perché disturbare l’admin con un mail ad ogni tentativo di login fallito?
E perché reinventare la ruota?
limit login attempts registra già gli ip, fa i blocchi, e manda email solo se la cosa inizia a diventare sospetta. Non dopo un solo tentativo di login sbagliato
@Wido certo si potrebbero fare molte funzioni e utilizzare tutto il codice che vuoi. Per i dati puoi seguire le indicazioni di Maurizio.
@Maurizio l’uso di plugin esterni aumenta come dicevi tu stesso anche la possibilità di vulnerabilità nel sistema (http://wordpress.org/support/topic/scary-limit-login-attempts-lockout-bypassed) . Invece L’uso di script fatti ad hoc ne diminuisce la portata. Se ti da fastidio ricevere una mail, figurati quanto ti da fastidio un accesso non autorizzato. A me verrebbe la curiosità di sapere chi si logga da admin sul mio sito…poi se è un problema di email quanto tempo ci metti a dare dei limiti al tuo script?
@fabio io con limit login attempt mi trovo benissimo rispondevo solo al tuo commento.
Si sono d’accordo con @maurizio non c’e’ bisogno di reinventare la ruota ed io per primo mi infastidirei a ricevere una mail per ogni login errato.
Visto che si è preso l’argomento plugin una cosa che magari mi piacerebbe è poter rendere il tema creato completamente indipendente da plugins anche se ad alcuni certe funzionalità potrebbero non interessare vi sono comunque alcune che è un peccato non trovare già incluse su wp, ad esempio: un contact form integrato, predisposizione degli articoli per lo sharing o tutte le funzionalità di security. Per questo ho creato una serie di files da includere in functions.php riferito a security ed aggiunte. Creando una sezione options nel backend di wordpress tutto diventerebbe molto più portabile. Non so magari è una scemenza.
Molti degli snippets li prendo da questo sito http://wpsnipp.com/ che sicuramente voi già conoscete.
Domanda off-topic, dove DIAVOLO trovo una lista completa di tutti i filtri? Grazie! :D
@Sebastian nel Codex ;) http://codex.wordpress.org/Plugin_API/Filter_Reference
Grande Maurizio e grazie, non sapevo che WP assegnasse di default il numero di versione agli script. Userò il tuo snippet, grazie mille :-)
Su aruba l’opzione Options -Indexes mi genera un 500 internal server error
A me invece è la parola (A)ruba che genera errori 404, 505 e 666 nel cervello.
Pensa un po’: se in Aruba imposti i permessi delle cartelle a 755 e quelli dei files a 644 non va più nemmeno WordPress. Fuck Aruba.
Eh ho notato miseria. Ho dovuto reinstallare tutto il backup.
“Da quando ho scritto la serie di tutorial sui pagamenti online, il 100% degli utenti che hanno avuto problemi utilizzavano servizi di hosting “popolari” ” … ho omesso di dire che era sempre lo stesso servizio di hosting… non posso dire quale…
Io di solito creo per wp una cartella dal nome di fantasia e uso un plugin che si chiama BulletProof Security che però non protegge da server scarsi. C’è un modo per identificare la validità delle protezioni di un server ?
tempo fa, per la versione 2.7, circolava un plugin che consentiva di rinominare le cartelle wp-admin, wp-includes e wp-content (con effetti allora definiti positivi dal punto di vista della sicurezza) e che permetteva di editare automaticamente i plugin in modo che i richiami a date cartelle fossero sostituiti da variabili poi salvate nel config
in seguito, se non sbaglio, il plugin non è stato più aggiornato per le versioni successive, forse perché in molti si chiedevano se, oltre a rendere meno immediata l’identificazione dello script, ci fosse qualche reale vantaggio nel rinominare le cartelle
considerazioni in merito?
Salve a tutti e complimenti per l’articolo ben fatto. Personalmente oltre a tutti i vari accorgimenti manuali mi affido a BETTER SECURITY e lo trovo veramente ottimo. Altamente soddisfatto. di seguito il link. http://wordpress.org/extend/plugins/better-wp-security/
Ottimo articolo Maurizio da mettere sicuramente in pratica!
thanks
grazie marius
Una cosa che è stata ommessa nell’articolo ma che non è affatto scontata per molti: gli snippet di Maurizio per nascondere la versione di wordpress vanno messi all’inizio del file functions.php per sicurezza perché se messi nel posto sbagliato provocano un errore del sito e magari chi si è dimenticato di fare il backup si ritrova con molto lavoro perso.
Io l’ho provato oggi e mi è successo questo, per fortuna il sito era stato appena creato quindi ho disinstallato e rimesso wordpress, ma per chi ha un sito in piena carreggiata sarebbe un danno molto grave. Dunque mettete gli snippet per nascondere la versione di wordpress all’inizio del codice così
<?php(che è la prima parola che troverete nel codice functions.php)
Qui incollate tutte e due gli snippet
Credo proprio che si tratti di una coincidenza. Non vedo proprio come questo codice, se messo all’inizio funzioni, mentre se messo alla fine, addirittura danneggi il sito al punto tale da doverlo reinstallare (???!!!???!!!).
I filtri (e le azioni) accodano l’esecuzione di una funzione x in un punto y del flusso. Indipendentemente dal punto nel quale vengono invocati nel file functions.php
Per ulteriore completezza, nell’ultimo sito che ho sviluppato, questo codice si trova a riga 133 di un file che viene incluso alla fine del file functions.php
Io comunque non trovo i file leggimi.html, licenza.txt, licenza.html . Qualcuno saprebbe aiutarmi?
Questi file si trovano nella cartella radice di wp
C’e’ anche, se a qualcuno interessa la possibilità di disabilitare l’editor implementato nel backend tramite l’aggiunta al wp-config.php dell’istruzione define(‘DISALLOW_FILE_EDIT’, true);
Ciao,
io ho un istallazione wordpress dove la cartella wp-admin è protetta con password direttamente da plesk.
Fino ad oggi non ho avuto problemi con nessun plugin.
Da quando ho installato e attivato il plugin woocommerce, ad ogni pagina che visito (quando sono sloggato) mi esce il popup che richiede la password per entrare su wp-admin.
A questo punto vi chiedo, per poter utilizzare quel plugin devo per forza togliere la protezione alla cartella?
Non c’è un modo per consentire al plugin di poter superare il controllo?
La cartella wp-admin volevo continuare a mantenerla protetta visto che in passato mi hanno bucato il sito.
Grazie in anticipo!
PS: Bell’articolo ;)
Non so se sono nella sezione giusta. Vorrei capire perchè sul sito segnalato il plugin social funziona solo nella sezione divani e a volte nel resto del sito. Dipende dalla cache o da cosa? Può dipendere dalla velocità di pinging?
Ma se io volessi creare una cartella nella root con dei miei file dentro, tipo http://www.miodominio.it/miacartella/miofile.zip, come devo fare???
mi restituisce sempre l’errore 404…
Non ho capito la domanda, io per creare cartelle e inserire file uso filezzilla
io creo la cartella (miacartella) via FileZilla e metto dentro il file (miofile.zip).
Quando però digito nella barra dell’indirizzo http://www.miodominio.it/miacartella/miofile.zip, non mi fa scaricare il file, ma restituisce l’errore 404 (il percorso è giusto e il file esiste…), penso dipenda l’htaccess…
come risolvo?
grazie
Hai provato il classico Ctrl + F5?
Scusa, ma cosa c’entra Crtl+F5 :-|
è una questione di url rewriting di wordpress e dell’htaccess.
Un pò di pulizia non fa mai male :P
Mi fermo qui perchè non mi viene in mente niente…
Ciao,
ho provato ad inserire il codice per nascondere la versione della piattaforma, ed in effetti nell’html generato non si vede più.
Però con l’estensione di chrome “Wappalyzer”, che ti dice al volo su che piattaforma è il sito che stai visitando mi appare papale papale la versione di wordpress.
Anche su questa pagina, ad esempio, mi dice che usi la versione 3.6.
Da dove se lo va a pescare secondo voi?
Dai una lettura a questo articolo. Riguarda in parte anche la questione. http://codeseekah.com/2012/02/20/the-wordpress-meta-generator-tag-paranoia/
Alla fine tentare semplicemwnte di nascondere determinate informazioni risulta più una perdita di tempo.
Ciao, e grazie degli ottimi consigli, anche io ho scritto di recente di qualche trucco per mettere maggiormente in sicurezza WordPress, se può interessarti: http://www.mattiafrigeri.it/articoli/wordpress/wordpress-tutorial-trucchi-rendere-sicuro-sito-1/
Ciao, forse non è giusto inserire qui la mia domanda ma sono davvero disperato !!! Il mio sito (fatto in wordpress) viene visto da google come contenente codice malware ed il codice è sempre lo stesso , sono link del tipo http://www.miosito.com/?i=54/ . Tutti puntano alla home del sito, probabilmente perchè inizialmente era impostato IMPOSTAZIONI PERMALINK il predefinito. Come posso eliminare questi link ? Ho fatto anche la rimozione di questi url da STRUMENTI WEBMASTER di google ma puntualmente si ripresentano.
Ciao, un paio di domande…
Tutte queste modifiche vanno perse con gli aggiornamenti di WP o dei Temi?
Io mi sono creato un tema “child”… come mi comporto? Dove scrivo tali modifiche’