Categorie
security wordpress

WordPress: preparare trappole per i furbetti

Se dopo esserti protetto dai tanti attacchi bruteforce continui a vedere nei log errori 404 a percorsi non convenzionali (es. phpmyadmin, phpinfo, test, cgi, register, admin, system, ecc…) è possibile che qualche BOT automatico stia facendo una scansione cercando potenziali falle.

Una delle possibili soluzioni è l’implementazione di una semplice blackhole in php. In pratica si tratta di una trappola che scatta ogni volta che si tenta di visitare alcune url.

Via .htaccess si effettua il redirect verso un specifico file php che si occupa tracciare l’ip e quante più informazioni possibili presentando poi una pagina in cui lo si informa che la cosa non ci è piaciuta.

Per chiudere il giro, ad ogni acesso controlleremo che l’IP non sia uno dei quelli precedentemente tracciatati e nel caso gli diremo che il suo IP è stato bloccato:

“You have been banned from this domain”

 

Per completezza devo dire che questa tecnica presenta dei problemi di perfomace nel caso, con il tempo, il numero di IP da controllare dovesse diventare molto grosso in quanto richiedere la lettura di una file ed il confronto di una stringa per ogni pageview.

Al momento l’unica alternativa che conosco è fail2ban ma non sempre è possibile chiedere al proprio servizio di hosting la sua implementazione.

Ecco come procedere:

  1. Scarichiamo dal sito di Perishable Press il file Blackhole.zip e scompattiamo in una directory nella root del nostro sito e modifichiamo le variabili che troviamo dentro index.php (mittente, destinatario,soggetto)
  2. Aggiungiamo le regole al nostro .htaccess per intercettare le url “maliziose”
  3. Facciamo in modo di caricare il file blackhole.php dentro il nostro fuctions.php

Se abbiamo fatto tutto bene, tentando di accedere ad una di quelle URL, dovremmo trovarci davanti a quella bella pagina rossa che vedete qui in alto e il nostro IP dovrebbe essere stato aggiunto al file blackhole.dat. (ricordatevi che poi è da togliere)

Qui sotto due piccoli snippets che spero possano esservi d’aiuto:

Nota: io aggiungo al soggetto della mail che ricevo anche il SERVER_NAME in modo che sappia su che sito è stato tentato l’accesso: $_SERVER['SERVER_NAME']

 

Categorie
featured wordpress

WordPress Hardening [wordcamp bologna 2012]

E per chi se lo è perso ecco le slide di sabato scorso al WordCamp Bologa dove si è parlato di WordPress e sicurezza.

WordPress Hardening from Maurizio Pelizzone

In breve si tratta di qualche semplice spunto per rendere più difficile l’utilizzo di un qualsiasi exploit che è possibile mettere in pratica senza l’installazione di plugins.
Questa è una versione aggiornata e migliorata rispetto a quella presentata il giugno scorso.

… e se le slide non vi bastano prossimamente saranno anche pubblicati i video dei singoli interventi.

update: qui il link per scaricare il file .htaccess di cui parlo nelle slide

 

 

Categorie
security wordpress

WordPress: Evitare “brute force” via .htaccess

Sempre più spesso dando un’occhiata ai log di sistema vedo attacchi “brute force” sulle pagina di login standard (wp-login.php) di WordPress.
Su alcuni sito sono arrivato ad avere centinaia di tentativi al giorno ma fortunatamente avendo password alfanumeriche da 12 caratteri e non usando l’utente “admin” di default non mi sono mai preoccupato più di tanto.

 

Nel tempo però mi sono reso conto di due grossi problemi problemi:

  1. Banda e sovraccarico del server: in questo caso e stato semplice intervenire e plugin come Simple Login Lockdown hanno reso la cosa molto semplice. In pratica dopo un numero configurabile di tentativi falliti, per un periodo di tempo altrettanto configurabile, viene bloccato l’IP impedendo l’accesso alla pagina.
    Io lo avevo configurato in modo che dopo 3 tentativi venisse bannato per 4 ore.
  2. Utenti Utonti: Questo è stato il problema più grave. Dato che nella maggior parte dei casi non sono io l’utilizzatore del sito ma il mio lavoro termina creado le credenziali per gli utenti che andranno ad operare, succede che per alcuni una password alfanumerica sia troppo complicata. Ecco quindi che di loro iniziativa la modificano con delle robe tipo “la data di nascita del figlio” perchè così è più facile da ricordare. La soluzione a questa “esigenza imprescindibile” l’ho trovata modificando e nascondendo l’url della pagina di login.
    Inizialmente ho usato “hide login” e successivamente anche “better security” ma alla fine ho preferito preparare uno snippet (che trovatre qui sotto) da mettere manualmente nel file .htaccess evitando in questo modo che il plugin possa essere disattivato.

Se volte implementarlo nel nostra installazione vi lascio solo alcune avvertenze in quanto prima di usarlo vanno modificate alcune variabili che sono dipendenti dal vostra configurazione.

[key] = chiave di controllo per il login – es. “0agw7afK” (2 sostituzioni)
[custom-login-path] = nuovo url per la pagina di login – es. “custom-login” (2 sostituzioni)

Attenzione: Prima di metterlo in produzione vi consiglio di provarlo localmente e di fare un backup del vostro precedente .htaccess. (non mi assumo responsabilità).

Rimango comunque disponibile nel caso doveste avere problemi o vogliate segnalarmi come migliorarlo.


update: maggio 2015
ho aggionto il file riducendo il numero di variabili

Categorie
wordpress

Il mio nuovo feedburner

E’ passato quasi un anno da quando Google ha acquisito Feedburner e nonostante qualche piccolo intoppo sembra che la migrazione sui nuovi server si stia per concludere.

Io nel frattempo ne ho approfittato per fare un po’ di ordine.

feedburner-google

Prima di tutto una cosa importante: l’indirizzo dei feed NON cambia.
Ho aggiornato il buon vecchio FeedSmith alla versione 2.3 ed modificato l’indirizzo a cui puntatava lo spyder di feedburner.

Questa versione non usa più il file .htaccess per effettuare il redirect ma modifica gli header impostando un 302.
Ho quindi approfittato per fare pulizia cancellando tutto il contenuto del mio .htaccess e facendo rigenerare a wordpress i permalink.

Poi ho messo a posto il problema delle immagini nei feed che come nel caso di cristian non venivano visualizzate per problemi di “permessi”.
Tempo fa avevo scritto qualcosa relativo allo spreco di banda anche se forse sarebbe più corretto parlare di hot-linking ed in quel’occasione non avevo usato un plugin ma ero interventuto creando un file .htaccess salvato sotto wp-content.

Per il momento ho aggiunto un paio di direttive che dovrebbero aver risolto il problema almento per quanto riguarda feedburner e/o più in generale google:

SetEnvIfNoCase Referer “^http://(.*)feedburner(.*)” ok_img
SetEnvIfNoCase Referer “^http://(.*)gogle(.*)” ok_img

Preso dallo slancio mi sono anche regalato un nuovo plugin: Add to feed.
Con questo piccolo aiuto posso aggiungere del teso all’interno del feed prima e dopo ogni item e dato che di questi tempi gli aggregatori crescono come funghi ho aggiunto un piccolo incipit: “Leggi l’orginale su http://maurizio.mavida.com“.

Concludo appuntandomi che questo è il nuovo link per accedere ai dati sugli accessi di feedburner tramite api. (nb: a differenza di quanto scritto nella documentazione nel parametro uri è sufficente mettere il numeutente)

Adesso non mi resta che verificare che tutto funzioni come dovrebbe e nel caso qualcuno notasse qualcosa di strano me lo faccia sapere. grazie.