Guida ELK Stack: raccolta log, parsing e dashboard

Introduzione

ELK Stack è una delle soluzioni più solide per raccogliere, normalizzare e analizzare log provenienti da server, applicazioni, firewall, reverse proxy, database e servizi cloud. In ambito sicurezza non è solo uno strumento di consultazione: è un sistema di osservabilità che permette di individuare anomalie, correlare eventi, costruire alert e conservare evidenze utili per incident response e audit.

La forza di ELK non sta nel singolo componente, ma nel flusso completo: raccolta, parsing, indicizzazione, ricerca e visualizzazione. Se uno di questi passaggi è debole, il risultato finale perde valore. Per questo una buona implementazione parte sempre da una domanda semplice: quali log servono davvero, con quale livello di dettaglio e per quale scopo operativo?

Questa guida è pensata per chi gestisce server Linux, hosting, VPS, ambienti WordPress, pannelli di controllo e infrastrutture web dove la sicurezza passa anche dalla capacità di leggere i segnali prima che diventino incidenti.

Architettura di base

ELK significa Elastic Stack nelle versioni moderne, ma il concetto operativo resta lo stesso:

• Elasticsearch conserva e indicizza i dati.
• Logstash riceve, trasforma e arricchisce i log.
• Kibana visualizza, esplora e costruisce dashboard.

In molti scenari entra in gioco anche Beats, soprattutto Filebeat, che legge i file di log locali e li invia in modo efficiente verso Logstash o direttamente a Elasticsearch. Per ambienti moderni, Filebeat è spesso la scelta più semplice e affidabile per la raccolta iniziale.

Il flusso tipico è questo: il sistema genera log, Filebeat li raccoglie, Logstash li normalizza, Elasticsearch li archivia e Kibana li rende consultabili. La differenza tra una piattaforma utile e una confusa sta nella qualità del parsing e nella disciplina dei campi.

Quali log raccogliere davvero

Non tutto merita di essere inviato a un cluster di ricerca. Il primo errore comune è raccogliere troppo, senza uno scopo. In sicurezza conviene partire dai log che hanno maggior valore operativo.

• Log di sistema: autenticazioni, sudo, servizi, kernel, errori critici.
• Web server: access log e error log di Nginx, Apache, LiteSpeed.
• Applicazioni: log PHP, WordPress, framework, job scheduler.
• Database: slow query log, errori, connessioni fallite.
• Sicurezza: fail2ban, firewall, auditd, SSH, VPN, IDS.

Per un sito o un server hosting, i dati più utili sono spesso quelli che permettono di rispondere a tre domande: chi ha tentato l’accesso, cosa è successo, e quando è successo. Il resto è contesto. Il contesto è importante, ma va aggiunto con criterio.

Raccolta log con Filebeat

Filebeat è adatto a leggere file di log locali e inviarli con overhead basso. In un server web tipico si configura per monitorare i percorsi principali e assegnare metadati utili come hostname, ambiente, ruolo del nodo e servizio di origine.

Un approccio corretto prevede di separare i log per sorgente. Per esempio, non conviene mescolare in un unico flusso tutti i file di accesso e tutti gli errori. Meglio mantenere una distinzione chiara tra access, error, auth e application log.

Esempio di log da includere:

• /var/log/auth.log o /var/log/secure
• /var/log/nginx/access.log e /var/log/nginx/error.log
• /var/log/httpd/access_log e /var/log/httpd/error_log
• log applicativi in /var/www/.../logs

La raccolta deve tenere conto della rotazione dei log. Filebeat gestisce bene i file ruotati, ma solo se la configurazione è coerente e i path sono corretti. Se la rotazione è aggressiva o i file vengono compressi rapidamente, conviene verificare che non ci siano buchi di ingestione.

Esempio concettuale di input Filebeat

filebeat.inputs:
  - type: filestream
    id: nginx-access
    paths:
      - /var/log/nginx/access.log
    fields:
      service: nginx
      log_type: access
    fields_under_root: true

Questo approccio aggiunge campi utili già all’origine, semplificando le dashboard e i filtri successivi. Il principio è semplice: più il dato è strutturato all’ingresso, meno lavoro serve dopo.

Parsing: la parte che fa la differenza

Raccogliere log senza parsing corretto produce solo un archivio di testi. Il valore vero di ELK nasce quando i messaggi vengono trasformati in campi interrogabili: timestamp, IP, user agent, status code, URL, user, response time, facility, severity, host, process.

Il parsing si può fare in diversi modi:

• con grok in Logstash;
• con dissect per formati regolari e veloci;
• con ingest pipeline di Elasticsearch;
• con parsing lato applicazione, se i log sono già in JSON.

Se hai controllo sull’applicazione, il formato JSON è quasi sempre la scelta migliore. Riduce l’ambiguità, semplifica il parsing e rende più robusta l’analisi. Se invece lavori con log legacy di Apache, Nginx o sistemi misti, Logstash con grok resta una soluzione molto pratica.

Un esempio classico è l’access log web. Da una singola riga si possono estrarre almeno questi campi:

• client IP
• timestamp
• metodo HTTP
• URL
• status code
• bytes trasferiti
• referrer
• user agent

Una volta separati, questi campi diventano filtri, grafici e regole di alert. Senza parsing, invece, ogni analisi richiede regex manuali e tempo perso.

Esempio concettuale di pipeline Logstash

input {
  beats {
    port => 5044
  }
}

filter {
  if [service] == "nginx" and [log_type] == "access" {
    grok {
      match => { "message" => "%{IPORHOST:client_ip} - %{DATA:remote_user} \[%{HTTPDATE:timestamp}\] \"%{WORD:method} %{DATA:request} HTTP/%{NUMBER:http_version}\" %{NUMBER:status:int} %{NUMBER:bytes:int} \"%{DATA:referrer}\" \"%{DATA:user_agent}\"" }
    }
    date {
      match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://elasticsearch:9200"]
    index => "logs-%{+YYYY.MM.dd}"
  }
}

La struttura va sempre adattata al formato reale del log. Il punto non è copiare un pattern, ma costruire un parser che sia stabile, leggibile e verificabile.

Normalizzazione e campi utili per la sicurezza

In un contesto security, la normalizzazione è più importante della quantità di dati. I campi devono essere coerenti tra sorgenti diverse. Se un firewall, un web server e un sistema di autenticazione usano nomi diversi per lo stesso concetto, la correlazione diventa lenta e fragile.

Campi da standardizzare con priorità:

• @timestamp per la linea temporale.
• host.name per identificare il nodo.
• event.dataset o un campo simile per distinguere il tipo di dato.
• service.name per il servizio generatore.
• source.ip e destination.ip per analisi di rete.
• user.name per eventi di autenticazione.
• http.response.status_code per eventi web.

Se i campi sono coerenti, diventa possibile costruire dashboard riutilizzabili e alert trasversali. Ad esempio, un picco di 401 e 403 su SSH, pannello hosting e login WordPress può indicare un tentativo coordinato di brute force o credential stuffing.

Un altro punto fondamentale è il timezone. Se i log arrivano da sistemi con timezone differenti, la lettura cronologica delle anomalie diventa confusa. Conviene sempre lavorare in UTC a livello di archiviazione, lasciando a Kibana la conversione in visualizzazione.

Dashboard: cosa mostrare davvero

Una buona dashboard non è una raccolta di grafici decorativi. È uno strumento operativo che risponde rapidamente a domande concrete. Per la sicurezza e il troubleshooting, una dashboard utile dovrebbe mostrare almeno questi elementi:

• volume log per sorgente;
• errori per severità;
• tentativi di login falliti nel tempo;
• status code HTTP più frequenti;
• top IP sorgenti;
• top URL o endpoint coinvolti;
• eventi anomali per host;
• slow query o errori database, se presenti.

Per un server web, una dashboard efficace può avere tre livelli:

1. vista esecutiva: salute generale, errori, picchi, trend;
2. vista operativa: dettagli per servizio, host e intervallo temporale;
3. vista incident: timeline degli eventi e correlazione tra sorgenti.

In Kibana conviene creare dashboard separate per scopo. Una dashboard unica e troppo ricca rischia di diventare inutilizzabile. Meglio poche viste ben definite, ciascuna con metriche chiare e filtri rapidi.

Visualizzazioni utili

• line chart per trend temporali;
• bar chart per top offender;
• pie chart solo se il numero di categorie è basso;
• table con campi chiave e drill-down;
• heatmap per distribuzione di eventi su fascia oraria.

Per la sicurezza, le visualizzazioni migliori sono quelle che aiutano a riconoscere deviazioni rispetto al comportamento normale. Il valore non sta nel numero di grafici, ma nella capacità di vedere un cambiamento prima che diventi un problema serio.

Alerting: dalla consultazione alla prevenzione

ELK è utile anche quando smette di essere solo un archivio consultabile. Con alert ben progettati puoi trasformare la piattaforma in un sistema di allarme precoce. Le regole migliori sono semplici, misurabili e con un basso tasso di falsi positivi.

Esempi di alert pratici:

• più di N login falliti per lo stesso IP in un intervallo breve;
• incremento improvviso di 5xx su un sito web;
• assenza di log da un host atteso;
• errore ripetuto di un servizio critico;
• picco anomalo di 404 o 403 su un endpoint sensibile.

Un alert efficace deve includere contesto: host, servizio, intervallo temporale, soglia e valore osservato. Se l’alert non dice cosa controllare dopo, è solo rumore.

Per ambienti con elevato traffico, conviene evitare soglie statiche troppo rigide. In alcuni casi è meglio usare baseline storiche o percentuali di variazione rispetto alla media, così da adattarsi ai cicli normali del servizio.

Best practice di sicurezza

Centralizzare i log significa anche gestire dati sensibili. Nel flusso ELK possono transitare username, IP, URL con parametri, header, frammenti di payload e informazioni che non dovrebbero essere esposte liberamente. Serve quindi un approccio prudente.

• Least privilege: ogni componente deve vedere solo ciò che gli serve.
• Cifratura in transito: usa TLS tra agenti, Logstash ed Elasticsearch.
• Access control: limita gli accessi a Kibana e alle API.
• Retention: definisci tempi di conservazione coerenti con il rischio e con la normativa.
• Masking: rimuovi o offusca dati non necessari, come token e credenziali accidentalmente loggati.

In particolare, non è prudente conservare in chiaro segreti applicativi o dati personali non indispensabili. Se un log contiene informazioni sensibili, va filtrato alla fonte o in pipeline. La sicurezza non è solo protezione dell’infrastruttura, ma anche igiene del dato.

Conviene anche monitorare lo stato del cluster: spazio disco, heap, latenza di indicizzazione, coda di ingestione e documenti scartati. Un cluster saturo non è solo lento: rischia di perdere valore operativo proprio quando serve di più.

Performance e capacità

ELK può crescere rapidamente di dimensioni. Senza pianificazione, storage e memoria diventano il collo di bottiglia principale. Per questo è importante misurare alcuni indicatori fondamentali:

• CPU dei nodi Elasticsearch e Logstash;
• RAM e pressione heap;
• I/O disco e latenza di scrittura;
• dimensione degli indici;
• frequenza di segment merge;
• latenza di ingestione;
• dimensione delle code;
• tempo di risposta delle query in Kibana.

Se i log arrivano molto velocemente, è spesso più utile ottimizzare il parsing e il batching che aumentare subito le risorse. In molti casi il problema non è il volume assoluto, ma un filtro troppo pesante o un mapping mal progettato.

Una pratica valida è usare retention differenziata: log ad alta utilità per periodi lunghi, log rumorosi per periodi più brevi. Questo riduce il costo di storage e migliora la consultazione.

Troubleshooting essenziale

Quando qualcosa non funziona, conviene verificare la catena dal basso verso l’alto.

1. Verifica che il file di log esista e venga aggiornato.
2. Controlla che Filebeat o l’agente stia leggendo il file corretto.
3. Valida che Logstash o la pipeline stiano accettando gli eventi.
4. Controlla che Elasticsearch indicizzi senza errori.
5. Apri Kibana e verifica indice, mapping e filtri temporali.

I problemi più frequenti sono questi:

• timestamp errato e dati fuori finestra temporale;
• pattern grok troppo rigido;
• campi non coerenti tra sorgenti;
• mapping conflittuali;
• indici pieni o shard mal distribuiti;
• permessi errati sui file di log;
• rotazione log non compatibile con l’agente.

Se i dati non compaiono in Kibana, spesso il problema è un filtro temporale troppo stretto, un indice sbagliato o un parsing che scarta i messaggi. Prima di cambiare la pipeline, conviene verificare il punto esatto in cui il dato si ferma.

Approccio consigliato per ambienti hosting e WordPress

In ambienti hosting e CMS, ELK funziona molto bene se si parte da casi d’uso concreti. Per esempio:

• individuare brute force su login WordPress e pannelli di controllo;
• osservare errori PHP ricorrenti dopo un aggiornamento;
• identificare picchi di 502, 504 o 500;
• correlare errori database con rallentamenti applicativi;
• vedere tentativi di scansione su endpoint sensibili.

Il principio guida è questo: non costruire una piattaforma “perché si fa così”, ma perché risolve un problema reale. Se il team non usa le dashboard, la configurazione è troppo complessa o troppo generica.

Conclusione operativa

ELK Stack diventa davvero utile quando viene progettato come strumento di sicurezza e diagnostica, non come semplice contenitore di log. La qualità della soluzione dipende da cinque elementi: raccolta mirata, parsing affidabile, campi coerenti, dashboard essenziali e retention ragionata.

Parti da pochi log ad alto valore, costruisci una pipeline leggibile, standardizza i campi più importanti e crea dashboard che rispondano a domande operative. Quando questa base è solida, alert e analisi avanzate diventano molto più efficaci. In un’infrastruttura moderna, la differenza tra reagire e prevenire spesso nasce proprio da qui.

Una pipeline di log ben fatta non serve a mostrare tutto: serve a far emergere subito ciò che conta.