Impossibile raggiungere il sito.
Errore nello stabilire una connessione al database.
Errore 500.
Quelli citati all’inizio sono solo alcuni degli errori che in questi giorni hanno afflitto il sito blu. Restart del server e cambio di configurazione non hanno in alcuno modo risolto il problema. Così, appena ho trovato un po’ di tempo libero, ho deciso di capire cosa c’era che non andava.
Cominciamo dalle conclusioni. Il sito blu gira su WordPress, una delle piattaforme più famose per quanto riguarda la gestione e messa online di un sito. Essendo un pacchetto ben conosciuto, in rete esistono diversi strumenti e stratagemmi per “hackerare” il suo funzionamento, mandando offline tutti i suoi contenuti. Questo, in poche parole, è quanto accaduto al sito blu. È stato sotto attacco per diverse settimane; nonostante la macchina su cui gira sia comunque abbastanza potente e dotata di diversi sistemi cache, gli attacchi mirati riuscivano a metterla offline, “uccidendo” tutti i processi principali.
Dopo diversi restart, ho deciso di andare in fondo alla faccenda, per capire a cosa fosse dovuto il continuo down del sito. Fortunatamente non è stato difficile, basta sapere da dove e da cosa partire.
Ok, è ora di iniziare sul serio!
access.log e error.log
Ogni sito WordPress gira su un server e solitamente ogni server genera dei log (file con diverse informazioni relative agli accessi ed agli errori riscontrati). Sia Apache che Nginx, nella configurazione predefinita, salvano tutti gli eventi in due file separati. Il primo è chiamato access.log ed è il file dove vengono archiviati tutti gli accessi da parte delle risorse esterne. Il secondo, invece, è error.log e si occupa di archiviare gli accessi e tutte le informazioni relative agli errori riscontrati sul server. I log sono una miniera d’oro per ogni buon amministratore; è possibile trovarvi informazioni capaci di dare una risposta alla maggior parte dei problemi.
access.log e error.log generalmente sono posizionati nella cartella /var/log/{server_name}/
Supponendo di voler vedere in diretta cosa accade sul vostro server apache, potete utilizzare durante la sessione ssh il comando:
tail -f /var/log/apache2/access.log
Proteggere wp-login.php
Il file wp-login.php ricopre un ruolo di fondamentale importanza per WordPress. Esso, infatti, permette di accedere alla bacheca di amministrazione. Inoltre, andando più nel tecnico, è uno dei file più comuni che usufruisce dell’accesso al database. Ogni volta che proviamo a loggarci, il database riceve una qualche richiesta.
Questo, ovviamente, può far gola ai malintenzionati. Basta avviare un bot che effettui automaticamente delle richieste al file /wp-login.php per mandare su di giri il processo del database. E non solo! Con delle tecniche di forza bruta si potrebbe arrivare a scoprire la password di accesso al pannello di amministrazione.
Ecco, il primo problema riscontrato riguarda proprio il file wp-login.php. Dall’access.log del mio server, che utilizza varnish come proxy e cache
tail -f /var/log/varnish/access.log | grep 'wp-login'
si nota che gli accessi a tale risorsa erano dell’ordine di uno ogni qualche minuto (nessun problema dal punto di vista dell’efficienza) ma, comunque, rappresentavano un problema di sicurezza. Non utilizzavo alcun plugin per proteggere il sito da questo tipo di attacco e qualcuno ha ben pensato di sfruttare il deficit.
Esistono diverse soluzioni al problema. Le migliori sono tutte elencate nella documentazione ufficiale di WordPress. Per i più curiosi, ho adottato la soluzione descritta nel paragrafo “Password Protect wp-login.php“. Provate ad aprire l’indirizzo http://www.ilsitoblu.com/wp-login.php e vedete cosa accade 😉
Proteggere xmlrpc.php
Qui il problema era simile. xmlrpc.php è un altro file di WordPress visibile all’esterno, cosa che lo rende vulnerabile ad altri tipi di attacchi. Anche in questo caso, qualcuno ha ben pensato di venire a farci visita con una certa frequenza, riuscendo a scaldare il database in momenti specifici della giornata.
Il problema è noto e, come tale, trova diverse risoluzioni in rete. Io, ad esempio, ho reso il file xmlrpc.php inaccessibile alle risorse esterne, restituendo un bel 403 a chi ne faccia richiesta.
DDOS
Il sito blu si fa voler bene ed oltre agli stratagemmi citati in precedenza è risultato positivo agli attacchi DDOS. Da diversi IP, infatti, arrivava un’ingente quantità di richieste capaci di risucchiare tutte le risorse del server e metterlo offline. Per giungere a tale conclusione è necessario avere qualche conoscenza aggiuntiva dei sistemi unix e della command line.
Sempre grazie al file access.log è possibile ottenere gli indirizzi IP più attivi sul server. Ad esempio, per estrarre i 10 indirizzi IP con più ricorrenze sul server apache, basta scrivere:
cat /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -n | tail
Con tale comando, come si evince dall’immagine, viene visualizzato a schermo il numero di occorrenze per indirizzo IP. Utilizzando questa tecnica, più qualche tail e grep / zgrep qua e là si riesce a risalire alla radice degli attacchi DDOS, ovvero agli indirizzi IP delle risorse che attaccano il server. A quel punto, è possibile bloccare il traffico proveniente da tali risorse attraverso l’utilizzo di iptables. Continuando sulla scia degli esempi, per bloccare il traffico esterno da un determinato indirizzo IP basta digitare:
iptables -A INPUT -s [indirizzo-IP] -j DROP
Per visualizzare la lista di tutti gli indirizzi bloccati:
iptables -L
Quanto descritto risulta una soluzione temporanea al problema. Infatti, è possibile monitorare personalmente gli accessi per qualche minuto/ora dopodiché, viene naturale voler automatizzare il processo in modo da bloccare automaticamente gli attacchi DDOS.
In rete esistono tanti strumenti per gestire e bloccare gli attacchi di tipo DDOS. Una delle soluzioni più interessanti che ho trovato e adottato è file2ban. Tale strumento è capace di rilevare automaticamente gli indirizzi IP dai quali vengono effettuati gli accessi più frequenti e bloccarli in caso di abusi.
Conclusioni
Tappando le falle descritte, sono riuscito a riportare il server ad un funzionamento stabile. Ora, oltre ad avere un buon sistema cache basato sulla combo Apache + PHP + MySQL + APC + Varnish è molto meno vulnerabile agli attacchi da parte di agenti esterni malintenzionati. Non sarà ancora il top della sicurezza ma, di certo, fa il suo buon lavoro.
