Nel precedente articolo sui log files abbiamo introdotto il concetto di log in Apache ed analizzato la memorizzazione delle richieste HTTP che giungono al server, il cosiddetto log degli accessi. In queste pagine prenderemo in considerazione la memorizzazione d'informazioni diagnostiche ed errori riscontrati nel processare tali richieste, ovvero il log degli errori. Come anticipato l'amministratore non ha, purtroppo, tutte le possibilità di personalizzazione descritte nella configurazione del file degli accessi. Non va comunque sottovalutata la sua importanza: se il server fa i capricci o la vostra applicazione web non funziona a dovere uno dei primi posti in cui guardare è sicuramente qui.
Error Log
Scorrendo il file di configurazione di Apache, httpd.conf, troviamo due direttive: ErrorLog e LogLevel. La prima definisce la posizione del file di registrazione, la seconda permette di stabilire che importanza debbano avere gli errori per essere memorizzati. Una tipica configurazione potrebbe essere la seguente:
ErrorLog logs/error_log LogLevel warn
In altri termini diciamo al nostro server di registrare le informazioni diagnostiche nel file error_log che si trova nella directory logs immediatamente sotto la ServerRoot, directory principale del nostro web server. Ad esempio /etc/httpd in un sistema linux e c:/Programmi/Apache Group/Apache2 in un sistema windows. Un percorso alternativo, che non faccia riferimento alla ServerRoot, può essere specificato fornendo il path completo. Il nome scelto per il file è quello tipico dei sistemi unix, sotto windows il default è error.log. L'altra informazione passata ad Apache è che deve memorizzare i messaggi d'importanza "warn", ovvero avvertimento. L'elenco delle possibili impostazioni è il seguente:
- emerg, messaggi di emergenza;
- alert, messaggi di allerta;
- crit, avviso di condizioni critiche;
- error, messaggi d'errore tipici per verificare il malfunzionamento degli script;
- warn, avvertimenti;
- notice, messaggi di notifica;
- info, messaggi informativi generici;
- debug, messaggi per il debug per agevolare il debug nello sviluppo di codice.
L'ordine con cui sono riportati è d'importanza decrescente. Stabilito un livello verranno registrati tutti gli eventi con rilevanza maggiore o uguale al valore prefissato. Ad esempio scegliendo warn verranno memorizzati anche gli eventi classificati error.
Leggiamo il file error_log
Il file è costituito da una riga per ciascuna segnalazione diagnostica, il formato di registrazione risulta piuttosto libero e descrittivo tuttavia alcune informazioni sono ricorrenti: la data, la severità dell'errore, la sua descrizione. Apriamolo con un editor di testo ed analizziamone il contenuto. I messaggi avranno un aspetto simile a questo:
[Fri Oct 28 21:04:50 2005] [error] [client 1.1.1.1] File does not exist: /var/www/html/undercon.php
- [Fri Oct 28 21:04:50 2005]: data e ora del messaggio;
- [error]: la severità del messaggio è a livello error;
- [client 1.1.1.1]: l'IP del client che ha generato l'errore;
- File does not exist: ......: la descrizione del problema, in questo caso il file richiesto non esiste.
Accenno brevemente al fatto che gli errori generati dall'esecuzione di CGI, Perl o, nel nostro caso, PHP possono essere visualizzati da Apache e forniscono un buon sistema di debug, eccone un esempio molto verboso:
[Fri Aug 05 13:36:19 2005] [error] [client 1.1.1.1] PHP Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /var/www/html/video/main.php on line 36, referer: http://www.miosito.it/elenco_audio.php
Si tenga presente che, in molte circostanze, esiste una corrispondenza tra registrazione nel file degli accessi e registrazione nel file degli errori. Nell'esempio che segue l'access_log riporterà una registrazione con un codice di stato 404, oggetto non trovato.
#error_log entry [Thu Mar 09 16:17:30 2006] [error] [client 1.1.1.1] File does not exist: /var/www/html/miapg.html #access_log entry 1.1.1.1 - - [09/Mar/2006:16:17:30 +0000] "GET /miapg.html HTTP/1.1" 404 290
Un piccolo avvertimento rispetto ai files non trovati. Alcuni browser richiedono sempre il file "favicon.ico", l'iconcina che compare nella barra dell'indirizzo per intenderci. Non trovandolo genereranno un errore "File does not exist". Per evitare di riempirsi di inutili segnalazioni conviene dotarsi di un favicon. Analogo discorso vale per la richiesta del file robots.txt da parte dei motori di ricerca.
Non solo files
Abbiamo fin qui parlato di file degli errori, in realtà Apache permette di indicare un'alternativa al file di puro testo per la registrazione degli eventi problematici. Sui sistemi unix è possibile fare riferimento alla funzione syslog alla quale inviano messaggi i daemon, ed anche Apache essendo tale. Basterà modificare la configurazione così (oltre eventualmente modificare /etc/syslog.conf secondo le proprie esigenze):
ErrorLog syslog
Analogamente si può sostituire il nome del file con una pipe verso il programma che gestirà le segnalazioni:
ErrorLog "|/usr/bin/mio_programma"
Se vogliamo abolire del tutto il logging, azione sconsigliata, possiamo procedere così:
ErrorLog /dev/null
Un'ultima osservazione già presentata nel precedente articolo: se il nostro server ospita più host virtuali, risulta fondamentale distinguere facilmente quale tra essi abbia generato l'errore per poter provvedere. In breve, se vogliamo definire error_log separati, basta utilizzare le direttive all'interno del contenitore <VirtualHost>:
<VirtualHost 192.168.0.1> ServerName www.miosito.com DocumentRoot /var/www/miosito ErrorLog /mypath_to_log/error_log CustomLog /mypath_to_log/access_log common .................. </VirtualHost>
Conclusioni
Con queste pagine e quanto esposto nel precedente articolo, abbiamo esplorato gli elementi essenziali del sistema di log in Apache. Consiglio di fare qualche prova, magari generando degli errori, ed andando successivamente a consultare access_log ed error_log per acquisire maggiore familiarità con essi.
Una buona parte dei tentativi di exploit del vostro server (si spera non riusciti) li ritroverete ben documentati nei file di log sotto forma di maliziose query string o richieste di (inesistenti) cgi o programmi che hanno larga diffusione sul web e di cui sono note le vulnerabilità.
Ribadisco che molte sono le problematiche strettamente collegate alla gestione dei log, quali ad esempio l'analisi statistica dei medesimi o la rotazione periodica per evitare files di dimensioni poco gestibili. Se l'argomento vi interessa continuate a seguirlo sulle pagine di HTML.IT.