Come promesso, ho iniziato ad indagare su come riprendere il controllo di come vengano usati i contenuti offerti in questo sito da innumerevoli “servizi di pubblica utilità”. Ho messo le virgolette perché ho la sensazione, ed alcuni fatti me ne danno ragione, che della pubblica utilità non gliene importi granché.

Il primo passo è stato di installare un sistema di rilevazione delle visite, che mi permette di scoprire chi, da dove e come accede al sito e soprattutto ai feed.

Ho appurato che molti visitatori automatizzati (crawler, robot e spider) non rispettano il contenuto del file robots.txt che, secondo le regole che dovrebbero rendere più civile la convivenza su Internet, dovrebbe indicare a questi visitatori automatizzati dove possono ficcare il naso e dove non possono. Certo, nessuno ne fa un obbligo, si tratta di autoregolarsi. Ma, visto appunto che le regole servono a chi non sa regolarsi, quando il totale disprezzo della proprietà altrui è evidente, si inizia a prendere provvedimenti forti.

Altro dato che per quanto mi riguarda è atteso, ma dovrebbe far saltare sulla sedia chi ignora le più elementari regole per la sicurezza del proprio sito/blog, è rappresentato dal numero di spider in cerca di rogne. In meno di venti ore di raccolta dei dati, su 495 crawler/spider che hanno visitato il sito, 192 contenevano nello User Agent la stringa “libwww-perl”. E il sistema colleziona solo chi accede a pagine “regolari” del sito, non cataloga ad esempio chi tenta di accedere alle pagine “private” (tipo quella di modifica dei temi, o quella di amministrazione, o a quella dei plugin), per cui il numero di accessi preludio ad una intrusione è molto più alto.

Per chi non ne fosse al corrente, gran parte dei mentecatti in cerca di siti da violare usa script fatti in Perl, un linguaggio nato con tutt’altro scopo. Quando uno script Perl accede ad un server web si identifica con quella stringa particolare, appunto “libwww-perl”.

I tentativi fatti da questi script vanno dalla semplice lettura del feed, al tentativo di leggere il file /etc/passwd, ad innumerevoli tentativi differenti di RFI. Ne ho già parlato, ed i principali bersagli sono plugin affetti da problemi di sicurezza.

Il passo successivo, sperimentale, è stato di aggiungere qualche riga al mio file .htaccess, queste per la precisione:

RewriteEngine  on
RewriteCond %{HTTP_USER_AGENT}   ^NomeSpider.*
RewriteRule .+   -   [F]

con il seguente effetto: se il sito viene visitato da qualcosa il cui user agent ha un identificativo che inizia con la stringa NomeSpider, il visitatore ottiene in risposta un 403-Forbidden al posto di qualsiasi pagina contenuta nel sito. In questo modo si chiude in faccia la porta in modo selettivo agli spider “maleducati”.

Naturalmente è una misura di poco valore, per il semplice fatto che un mentecatto competente può in pochi secondi cambiare la stringa identificativa del proprio spider, rendendo inefficace la misura, strategia che ho visto con i miei occhi in molti script “pronti per l’uso” reperiti in Rete per fare birbonate: in qualcuno lo user agent è una stringa casuale, in altri è scelto a caso fra stringhe di browser normali, quali Firefox, Konqueror, Internet Explorer, Safari e via così.

Lo stesso WordPress Autotest opera in questa maniera, per poter attirare in trappola il codice malevolo iniettato nei blog colpiti: si presenta con differenti user agent allo scopo di costringere il malware a rivelarsi.

In ogni caso la regola può essere fatta anche con l’indirizzo IP dello spider, e questo può essere molto più efficace: al visitatore non basta cambiare il proprio user agent, deve proprio cambiare punto di accesso alla Rete, cosa non proprio banale. Ma, sempre parlando di “libwww-perl”, gli indirizzi IP da cui provengono le scansioni sono quasi tutti di fornitori di accesso Internet a privati, tradotto: sono computer di “guidatori sopra la media” compromessi ed usati dal nostro amico mentecatto, o da un suo affine, sempre mentecatto. Quindi anche l’inserimento di un indirizzo IP è una misura poco efficace, se vogliamo contrastare un possibile attacco mirato a violare il sito. Rimane efficace per “educare” crawler e spider poco rispettosi, appartenenti a società sempre a caccia di informazioni di qualsiasi genere da rivendere.

Riguardo alle stranezze di una certa classifica, non sono l’unico ad avere delle perplessità.

Due parole ancora per spiegare meglio il mio punto di vista. Sulle classifiche ho cambiato idea, non ho nessun problema a dirlo. All’inizio pensavo che fossero uno strumento utile a far conoscere il proprio sito e soprattutto a raggiungere meglio i possibili interessati agli argomenti che tratto. A distanza di molto tempo (informaticamente parlando), il risultato è non solo deludente, ma è evidente il vantaggio di chi conosce i meccanismi della classifica (quale che sia) e di come si faccia di tutto per scalare posizioni usando tutti i trucchi possibili ed immaginabili per “dopare” la propria posizione. La responsabilità non è della classifica e di chi la gestisce, ma se di un responsabile avete bisogno, guardatevi allo specchio e chiedetevi se non sia ancora una volta il solito vizietto di voler fare i furbetti a tutti i costi per primeggiare con poca fatica.

Ritengo tutto ciò, nel mio specifico caso, lesivo della mia immagine e del mio lavoro. Per cui mi opporrò in ogni maniera ad essere incluso in classifiche che vengono abusate dagli stessi membri, al solo scopo di rimediare qualche click in più, in cambio di nulla.

Riferimenti

• Documentazione sul mod_rewrite della Apache Foundation.
• Documentazione sul file .htaccess.

Tags: blog, classifiche, sicurezza dell'informazione, Wordpress