Lezione

7. Consultare-Analizzare i log

Torniamo alla parte operativa del nostro web server. Affrontiamo l’importante argomento dei log. Iniziamo con una piccola sezione di teoria, per poi capire dove sono e come vi si accede e, in fine, prendere famigliarità con i tool di analisi e rappresentazione dei log.

Qui è opportuno sottolineare che l’analisi dei log è strategica soprattutto nei casi d’uso professionali:

ci permettono di capire, dati alla mano, cosa viene cercato e acceduto nel nostro sito, aspetto determinante se abbiamo uno shop o vogliamo aumentare i nostri affezionati;
ci permette di vedere e scovare malintenzionati e possibili vulnerabilità del nostro sito;
in caso di danni e/o breach abbiamo la possibilità di dati e analisi anche ai fini delle compliance legali.

7.1. Log: la teoria

Apache HTTP Serve genera 4 file di log per ogni server virtuale definito nelle sue configurazioni: 2 per gli accessi in HTTP, 2 per gli accessi in HTTPS.

Un log è riservato per gli accessi. Il secondo per gli errori ed i warning.

La configurazione di default dei log è diventata, di fatto, uno standard. È possibile, in ogni caso, modificare la configurazione per rilevare più informazioni o ridurre quanto viene tracciato.

I log sono file di testo semplice che vengono scritti. Ciò significa che il server deve dedicare un certo numero di cicli processore a creare queste stringhe e spendere cicli di IO per la scrittura di questi sul disco. Finché si tratta di test o di un piccolo server con pochi accessi al minuto non vedremo nessun decremento nelle prestazioni. Ma in server con decine o miglia di accessi è un problema di assoluto rilievo che rallenta significativamente il server.

Data la loro natura i log sono file che crescono continuamente. È importante non farci ingannare dalle grandi capacità di memoria degli hard disk. Con un traffico medio-piccolo possiamo avere alcuni giga all’ora. Il che significa che avremo tera di log nell’arco di un paio di settimane e arrivare a riempire un disco in pochi mesi.

In ultima analisi i log sono una preziosa risorsa da usare con molta attenzione.

Ai fini di gestione, profilazione, promozione, ecc… vanno assolutamente usati ed elaborati con qualche tool specializzato.

Infine i sistemi *nix (Linux + Unix) di serie hanno una configurazione di rotazione dei log che controlla automaticamente la crescita dei log comprimendoli, controllando lo spazio totale occupato e cancellandoli periodicamente. Cosa fondamentale perché se il disco si riempie il web-server si blocca e gli utenti vedranno o un errore di time-out o un errore di risorsa-pagina non disponibile. In ogni caso una situazione imbarazzante per un sito serio.

7.2. Log: accesso, lettura e gestione

Quello che abbiamo costruito nella prima parte di questo manuale posiziona i file di log nella directory

/var/log/apache2/

Si tratta della posizione default per tutte le distribuzioni Debian e derivate come la Ubuntu. L’altro grande filone Linux (le Red Hat e derivate) mettono i log di default nella directory

/var/log/httpd/

Se abbiamo qualche dubbio è sufficiente cercare le parole chiave ErrorLog e CustomLognella nella configurazione di Apache. Nel nostro server, al momento, è definito il solo dominio default il cui file di configurazione è /etc/apache2/sites-enabled/000-default.conf .

A questo punto è opportuno anticipare l’argomento di “Let's Encrypt” e l’utility certbot . Si tratta della soluzione che crea i certificati SSL. L’utility crea un file di configurazione Apache per ogni dominio che mettiamo nel nostro server.

Ipotizzando di certificare con certbot il nostro dominio www.example.com troveremo il file di configurazione /etc/apache2/sites-enabled/001-example.com-le-ssl.conf in Apache.

Questa configurazione automatica prevede le seguenti due directory:

/var/www/digitaldsb.it/html
/var/www/digitaldsb.it/log

Il significato è piuttosto immediato:

html : contiene le pagine dei siti ed i file dei CMS per il dominio example.com ;
log : contiene i file dei log per il dominio example.com .

Se avessimo certificato il dominio www.pippopluto.it le directory previste dalla configurazione automatica di certbot sarebbero:

/var/www/pippopluto.it/html
/var/www/pippopluto.it/log

È arrivato il momento di aprire un file di log.

Useremo lo strumento less, storico tool presente in tutti i sistemi *nix. Si tratta di un programmino che mostra su un terminale il contenuto di un file di testo, senza modificarlo e offrendo alcune funzioni aggiuntive a corredo, come la ricerca, il salto a un punto preciso, ecc… una volta invocato per uscirne basta premere il tasto Q (=quit).

Invochiamolo:

less /var/log/apache2/access.log

Vedremo qualcosa di simile a quanto segue:

10.10.10.1 - - [25/May/2024:06:15:18 +0000] "GET /joomla HTTP/1.1" 200 3120 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"
10.10.10.1 - - [25/May/2024:08:12:01 +0000] "POST /joomla/index.php/component/ajax/?format=json HTTP/1.1" 200 1032 "http://www.example.com/joomla/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"
10.10.10.1 - - [25/May/2024:08:26:01 +0000] "POST /joomla/index.php/component/ajax/?format=json HTTP/1.1" 200 606 "http://www.example.com/joomla/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"

Facciamo la stessa operazione con il file error.log .

Apriamolo:

less /var/log/apache2/error.log

Vedremo qualcosa di simile a quanto segue:

[Sat May 25 06:08:58.551027 2024] [mpm_prefork:notice] [pid 830] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Sat May 25 06:08:58.551084 2024] [core:notice] [pid 830] AH00094: Command line: '/usr/sbin/apache2'
[Sat May 25 06:27:08.162712 2024] [mpm_prefork:notice] [pid 830] AH00170: caught SIGWINCH, shutting down gracefully

Anche senza spiegazioni qualcosa risulterà parlante per tutti, molte altre informazioni, invece, saranno piuttosto criptiche. Evidente è il fatto che si tratta di stringhe ricche di informazioni: come possiamo rendere tutto questo patrimonio informativo immediato e facile?

7.3. Log: tool di analisi

I tool di analisi log mirano a offrire una soluzione al nostro ultimo quesito: come rendere i log immediati e facili.

Una tradizionale soluzione è Awstats. Si tratta di un software che viene fatto girare tipicamente una volta al giorno, legge tutti i log e li trasforma in comode pagine HTML con grafici, numerosità, indici, geolocalizzazioni, ecc…

L’applicazione è adatta per piccoli server, con poco traffico e pochi accessi. L’elaborazione che fa Awstats impiega tempo, richiede calcolo e una buona quantità di RAM. Inoltre è in grado di lavorare solo su raccolte di dati e non permette di lavorare in tempo reale. Insomma: Awstats è una tecnica datata e abbandonata.

Una potente ed elegante soluzione è ELK ( https://www.elastic.co ): usa i tre programmi Elasticsearch, Logstash e Kibana. Lavora in tempo reale. Permette di analizzare tutti log. Una volta avviato permette ricerche avanzate nei log, permette di salvare query, evidenziare anomalie e molto, molto altro. Pur essendo una soluzione completamente open source (non ci sono costi di licenza, né limitazioni nelle funzioni) è una soluzione che richiede esperienza e competenza per assere correttamente configurata e attivata. Inoltre necessita di periodiche manutenzioni per controllare la crescita della base dati interna.

Questa complessità e qualche altro motivo strettamente tecnico ha portato a sviluppare soluzioni più semplici, ma altrettanto potenti. Grafana ( https://grafana.com ) è un progetto nato nel 2014, integra tecnologie più recenti e che permettono migliori performance e integra nativamente il supporto ai requisiti più avanzati (analisi big data, fonti eterogenee, funzionamento cluster, ecc…). Accanto a tutte queste meraviglie (ed altre ancora) è necessaria competenza ed un po’ di esperienza. È un prodotto ancora in crescita.

Un ottimo e semplice prodotto che unisce potenza e semplicità è Matomo ( https://matomo.org ). Scritto in PHP è concepito come un prodotto che legge gli accessi direttamente dal sito sotto osservazione, tramite un piccolo script in JavaScript da inserire nelle pagine. L’installazione è del tutto analogo all’installazione di Joomla o WordPress. Per inserire lo script nei CMS ci sono plugin per Joomla e per WordPress che rendono semplice l’operazione. Si tratta, sicuramente, del miglior compromesso possibile per avere un sistema open source con servizi di livello professionale e compliant con le normative europee ed italiane.

Infine è noto il software Analytics di Google. Molti lo usano per l’assenza di costi in diverse situazioni e per la facilità di implementazione. Funziona sulla stessa logica di Matomo, ma configurazioni, grafici, post elaborazione è tutto dentro Google. Sovranità dei dati (come principio e come reale possesso dei bit) non è possibile. Anche la compliance con le norme europee e italiane va analizzata con attenzione.

In conclusione se Matomo è il miglior compromesso e la scelta preferibile nello scenario affrontato in questo manuale non mancano alternative e prodotti con capacità superiori.