Leggendo i log ho scoperto... #9 - Errori nella configurazione server

by Simone Carletti — Leave a Comment

… quanto sia facile accorgersi tempestivamente di configurazioni errate sul proprio server.

Torniamo indietro di qualche settimana quando Simone Cabrino mi segnalò un problema nella configurazione del sito. A causa di un errore nelle regole del file .htaccess, ogni richiesta inviata ad un URL specifico di questo blog era indirizzata ad un percorso invalido nel sito, composto dall’indirizzo del blog più l’indirizzo fisico di questo blog sul server.

Questo problema, oltre ad essere fastidioso e prevenire l’indicizzazione di alcune pagine del sito, è pericoloso poiché espone all’esterno informazioni preziose sull’archittura del sito e del server che potrebbero comprometterne la sicurezza.

Questo problema avrebbe potuto essere individuato prima se avessi analizzato più attentamente i log, eventualmente prevedendo una qualche utility che mi avvisi nel caso in cui qualche richiesta contenga dei percorsi anomali come il percorso fisico sul server.

$ zgrep '/home/simonecarletti/simonecarletti.com' access.log.*.gz
64.34.195.155 - - [15/Aug/2008:12:14:00 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 1963 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"
74.6.31.165 - - [15/Aug/2008:12:51:12 -0700] "GET /blog/home/simonecarletti/simonecarletti.com/blog HTTP/1.0" 200 1963 "-" "Mozilla/5.0 (compatible; Yahoo! DE Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
82.63.157.52 - - [27/Aug/2008:01:34:50 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 2000 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1"
82.63.157.52 - - [27/Aug/2008:01:36:01 -0700] "GET //home/simonecarletti/simonecarletti.com/code HTTP/1.1" 404 596 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1"
87.28.229.37 - - [27/Aug/2008:01:50:15 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 2000 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"
87.28.229.37 - - [27/Aug/2008:01:50:17 -0700] "GET /blog/styles.css HTTP/1.1" 200 4454 "https://simonecarletti.com/blog//home/simonecarletti/simonecarletti.com/blog" "Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"

Ad oggi, conoscendo l’errore e la causa, anche il problema appare molto più semplice. Vediamo come potrei procedere se mi trovassi di fronte a questo problema per la prima volta.

Come prima cosa è fondamentale ottenere le informazioni filtrate, da analizzare singolarmente. Possiamo procedere esportando la lista delle corrispondenze in un file chiamato, ad esempio, file.txt.

$ zgrep '/home/simonecarletti/simonecarletti.com' access.log.*.gz > file.txt

A questo punto, cominciamo a leggere il file alla ricerca di qualche dettaglio utile. A seconda del tipo di problema, oltre alla riga di log contenente l’errore potrei aver bisogno di tutte quelle correlate appartenenti alla sessione di navigazione.

In questo caso, ecco due righe di log che potrebbero fornirmi un indizio.

64.34.195.137 - - [15/Aug/2008:02:45:35 -0700] "GET /blog HTTP/1.1" 301 610 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"
64.34.195.137 - - [15/Aug/2008:02:45:36 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 1963 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"

Come potete osservare, in un client richiede la pagina /blog//home/simonecarletti/simonecarletti.com/blog. Immediatamente prima, lo stesso client ha inviato una richiesta al percorso /blog ottenendo in risposta un redirect 301.

A questo punto, conosco il problema e l’origine. Non mi resta che individuare la causa e correggerla.

In conclusione, analizzate sempre i log del server alla ricerca di richieste anomale. Se non sapete cosa cercare, cominciate con il verificare richieste che contengono all’interno percorsi a file fisici sul vostro server.

Related Posts