Approfondimento sul Parsing SYSLOG

Nel nostro ultimo blog su ELK, abbiamo configurato ELK (Elasticsearch, Logstash e Kibana) su Docker. Ora trasformeremo quei log complessi in mattoni che ti permetteranno di creare visualizzazioni in Kibana.

Se non hai ancora letto Hands-On Practice with the ELK Stack, puoi iniziare clonando il seguente repository GitHub per configurare il tuo ELK Stack: https://github.com/object1st/elk-stack.git

_{cd elk-stack}  

comando di esecuzione:

docker-compose up -d

Quindi, naviga nel tuo browser all'indirizzo IP o al nome DNS della tua VM (o localhost se lo stai facendo localmente) e sulla porta 5601, accedi a Kibana: http://myvm:5601

Parsing Syslog

Entro la fine di questo walkthrough, puoi aspettarti di avere:

• Analizzato un messaggio syslog complesso
• Creato una rilevazione intelligente delle minacce che individua automaticamente un indicatore di ransomware
• Costruito un dashboard per visualizzare l'allerta

La Sfida: Strutture di Log Complesse

Iniziamo con un messaggio syslog del mondo reale.

Esempio: Veeam Rilevazione Malware

Mar 20, 2025 @ 14:06:09.662 VBRSRV01 Veeam_MP: [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected for OIB: 0e54d3bf-add8-48eb-9122-fad3ac1e8fb3 (VM01), rule: Encrypted data by user: TECH\user1."]

Perché Questi Messaggi Sono Importanti

Troverai informazioni preziose in questo messaggio di log—prenditi un momento per esplorarlo.

Veeam messaggio:

• Attività potenziale di ransomware in corso
• Account utente specifico coinvolto (TECH\user1)
• Macchina virtuale interessata (VM01)
• Modello comportamentale (Attività Dati Cifrati)

Ma nel suo stato attuale, non puoi facilmente:

• Tracciare quali VM sono potenzialmente interessate.
• Correlare attività sospette nel tempo
• Generare report su questa attività

Passo 1: Inizia Semplice, Costruisci Intelligente

Ecco dove la maggior parte delle persone sbaglia: cercare di analizzare tutto in una volta e finire con una configurazione che non funziona.

Se desideri seguire, trova i file nella cartella “Esempi” del repository GitHub. Se hai già installato ELK in Docker da il post del blog precedente, copia semplicemente quei file nella tua configurazione. Mentre lavori attraverso questo blog, sostituisci i file esistenti con le versioni aggiornate fornite qui. Se commetti un errore o ti perdi mentre editi, puoi sempre riclonare il repository per ricominciare da capo.

1. Per utilizzare, elimina il logstash.conf nella pipeline sostituendolo con 

   logstash_version1.conf ($ cp ~/elk-stack/Examples/logstash_version1.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Riavvia il container logstash ($ docker-compose restart logstash).

Perché questo approccio funziona:

• Inizia con input/output funzionanti
• Usa stdout per vedere esattamente cosa riceve Logstash (verrà visualizzato nei log del container docker)
• I log grezzi vanno ancora a Elasticsearch (niente viene perso)
• Costruisci complessità gradualmente senza rompere le cose

Passo 2: Testa la Tua Configurazione

1. Invia i tuoi messaggi di esempio a Logstash e osserva l'output. Ecco alcuni metodi che puoi utilizzare per inviare un messaggio syslog tu stesso.
2. Utilizzando netcat:

• Copia e incolla il seguente comando nel tuo CLI (Veeam Messaggio Syslog):

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

• Dovresti vedere qualcosa del genere quando digiti docker logs logstash:

Questo è un problema perché tutto ciò che è prezioso è intrappolato in un unico enorme campo di messaggio:

“"message" =&gt; "<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId=\"31023\"] [categoryId=0 instanceId=41600 DetectionTimeUTC=\"03/20/2025 13:05:41\" OibID=\"0e54d3bf-add8-48eb-9122-fad3ac1e8fb3\" ActivityType=\"EncryptedData\" UserName=\"TECH\\user1\" ObjectName=\"VM01\" VbrHostName=\"vbrsrv01.tech.local\" Description=\"Potential malware activity detected\"]\n",”

Per affrontare questo problema, analizza i log per renderli più puliti.

Ecco dove le cose diventano interessanti (e leggermente spaventose se sei nuovo nel regex). Stiamo per dissezionare questo log e renderlo più facile da estrarre informazioni.

Prima di scrivere qualsiasi codice, comprendiamo con cosa stiamo lavorando:

Veeam Struttura: [timestamp] [hostname] [application]: [origin_data] [detection_data]

Passo 3: Parsing di Base

Copia il prossimo file logstash:

1. Per utilizzare, elimina il logstash.conf nella pipeline sostituendolo con logstash_version2.conf  ($ 

cp ~/elk-stack/Examples/logstash_version2.conf  ~/elk-stack/logstash/pipeline/logstash.conf) 

2. Riavvia il container logstash ($ docker-compose restart logstash)

Pattern Grok Decodificato:

• %{POSINT:priority} → Cattura numeri interi positivi come "priority"
• %{TIMESTAMP_ISO8601:timestamp} → Pattern integrato per timestamp ISO
• %{IPORHOST:host} → Indirizzo IP o nome host
• %{GREEDYDATA:raw_message} → Tutto il resto (analizzeremo questo successivamente)

Questo nuovo pattern Grok è progettato per suddividere i messaggi syslog grezzi in dati strutturati e utilizzabili. In particolare, separa i componenti di base di un messaggio syslog (come timestamp, hostname e livello di log), identifica l'applicazione sorgente che genera il log e contrassegna ogni messaggio per ulteriori elaborazioni lungo la pipeline. Questo passo fondamentale è ciò che consente un'analisi più avanzata, arricchimento e logica di allerta successivamente nel flusso di lavoro.

3. Testa di nuovo per vedere le differenze:

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

4. Quindi, controlla i log del container logstash ($ docker logs logstash).

I campi che abbiamo estratto:

_{priority → 0}

_{timestamp → 2025-03-20T14:06:09.662307+02:00}

_{host → ["172.19.0.1", "VBRSRV01"]}

_{application → "Veeam_MP"}

_{severity → "Emergency"}

_{severity_level → 0}

Passo 4: Approfondimento sul Parsing

Ora faremo ancora più parsing. Il file è troppo grande per essere stampato qui, ma si trova nella tua cartella “Esempi” come logstash_version3.conf.

1. Per utilizzare, elimina il logstash.conf nella pipeline sostituendolo con: logstash_version3.conf ($

   cp ~/elk-stack/Examples/logstash_version3.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Riavvia il container logstash ($ docker-compose restart logstash).
3. A questo punto, testa la tua configurazione. Dovresti vedere campi individuali invece di un grande blob di messaggio.
4. Esegui di nuovo lo stesso messaggio di test, quindi controlla i log del container logstash ($ docker logs logstash).

I campi che abbiamo estratto:

_{enterprise_id → "31023"}

_{category_id → 0 (convertito in intero)}

_{instance_id → 41600 (convertito in intero)}

_{detection_time_utc → "03/20/2025 13:05:41"}

_{detection_timestamp → 2025-03-20T13:05:41.000Z (timestamp correttamente analizzato)}

_{oib_id → "0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" (ID di allerta unico)}

_{activity_type → "EncryptedData" (indicatore di malware)}

_{username → "TECH\\user1"}

_{object_name → "VM01" (VM interessata)}

_{vbr_hostname → "vbrsrv01.tech.local"}

_{description → "Attività potenziale di malware rilevata"}

Passo 5: Veeam Intelligenza sulle minacce e gestione degli errori

Ultimo ma non meno importante, dobbiamo aggiungere intelligenza al nostro sistema e gestione degli errori per aiutarci a fare debug se necessario. Aggiungere intelligenza è importante perché consente il filtraggio per impatto aziendale, permette l'allerta basata su priorità, rende la creazione di dashboard intuitiva, fornisce raccomandazioni azionabili e riduce la fatica da allerta.

Ecco come aggiungere intelligenza e gestire gli errori:

1. Per utilizzare, eliminare il logstash.conf nella pipeline sostituendolo con: logstash_version4.conf ($ 

   cp ~/elk-stack/Examples/logstash_version4.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Riavviare il contenitore logstash ($ docker-compose restart logstash).
3. Attendere che la pipeline sia in esecuzione e poi inviare di nuovo il messaggio di test:

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

Quali nuovi campi abbiamo estratto:

_{threat_type → "potential_ransomware" (categorizzazione intelligente delle minacce)}

_{event_category → "malware" (classificazione della sicurezza)}

_{business_impact → "high" (valutazione del rischio)}

_{alert_priority → "critical" (priorità di escalation)}

_{recommendation → "Indagine immediata richiesta" (linee guida per la risposta)}

_{event_type → "security_event" (classificazione dell'evento)}

Riepilogo della sezione

In questa sezione, abbiamo completato con successo i seguenti passaggi:

• Aggiunto contesto aziendale agli eventi grezzi
• Creata classificazione della severità intelligente
• Costruito un sistema di categorizzazione delle minacce
• Abilitato l'allerta basata su priorità

Passo 6: Crea un modello di indice

Prima di iniziare a inviare dati in Elasticsearch, dobbiamo ottimizzarlo per il nostro caso d'uso specifico.

1. Nel repository GitHub, troverai il file index_template.json, che possiamo importare in Kibana.

2. Utilizziamo un comando curl per importare il nostro index_template.json dalla cartella “Esempi”.

Se hai problemi a copiare i comandi qui, puoi trovarli anche nel file README.md del repository github

curl -X PUT "localhost:9200/_index_template/veeam-syslog-template" \ -H "Content-Type: application/json" \ -d @index_template.json

3. Dovresti vedere questo messaggio se l'importazione è stata completata con successo.

4. Successivamente, creeremo un modello di indice (nelle versioni successive chiamato Data Views).

• Digita il seguente comando:

curl -X POST "localhost:5601/api/saved_objects/index-pattern/syslog-pattern" -H "Content-Type: application/json" -H "kbn-xsrf: true" -d '{"attributes":{"title":"syslog-*","timeFieldName":"@timestamp"}}'

• Puoi anche creare tramite la WebUI.

5. Controlla se il modello di indice è stato creato eseguendo le seguenti azioni:

• Vai a Gestione Stack
• Clicca su “Modelli di Indice” sotto “Kibana”
• Qui possiamo vedere il nostro nuovo modello di indice creato.

6. Successivamente, dobbiamo creare una visualizzazione.

• Clicca su “Libreria Visualizza.”
• Clicca sulla tile “Lens”.
• Dal menu a discesa, scegli “Metric.”

7. Nel campo filtro, digita: threat_type: “potential_ransomware”

8. Scegli “Overtime” in mezzo (questa è la tua scelta su come vuoi che appaia la dashboard).

9. Salva la visualizzazione cliccando sul pulsante "Salva” nell'angolo in alto a destra e aggiungi a una nuova dashboard:

10. Cambia il “Nome” sotto Metrics in “Alerts” e scegli Records a sinistra.

• Dovresti finire con questo:

11. Salva questo nella tua Libreria di Visualizzazione e scegli “Nessuna Dashboard” per ora.

12. Successivamente, crea un'altra visualizzazione che chiameremo “Macchine Affette.”

• Questa volta, scegli Tabella, non Metric, e utilizza il campo “Top values of object_name” e di nuovo record. Cambia i nomi delle colonne premendo sui nomi a destra e cambiando il nome di visualizzazione:

13. Salva di nuovo nella tua libreria.

14. Ora, creiamo un'altra visualizzazione a tabella—questa volta utilizzando il campo “Top Values of Username”. Questo può aiutare a identificare quali utenti potrebbero essere stati connessi durante l'attacco. Tieni presente che questo è puramente a scopo esplorativo e dimostra quanto creativamente puoi sfruttare i dati.

15. Infine crea una visualizzazione ad area—questa volta mostrando allerta e timeline.

16. Sentiti libero di creare di più o modificare quelli esistenti per avere un'idea di questo. Abbiamo creato alcune visualizzazioni molto basilari solo per spiegare il processo.

17. Infine, crea una dashboard e aggiungi queste visualizzazioni.

18. Salva la dashboard con il nome “Potenziale Ransomware.”

19. Per testare, inviamo un'altra allerta come se fosse da Veeam ma cambiamo alcuni dei componenti del messaggio in modo da poter vedere se viene ingerito correttamente.

20. Cambiamo il nome utente in Gustev e la VM in MainFrameSuper.

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="NASA\Gustev\" ObjectName="MainFrameSuper" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

• Come possiamo vedere, la nostra dashboard ci avvisa immediatamente al ricevimento del messaggio syslog:

Conclusione

Quando hai iniziato questa serie, ti sei trovato di fronte a un muro di testo criptico di 347 caratteri:

<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]

Ora, quel messaggio stesso attiva un sistema di monitoraggio della sicurezza intelligente che identifica immediatamente:

• Tipo di Minaccia: Attività potenziale di ransomware
• Livello di Priorità: Impatto aziendale critico
• Utente Affetto: TECH\user1 (identificato come umano, non come account di servizio)
• Risorsa Compromessa: macchina virtuale VM01

In questo blog, abbiamo fornito ai lettori un quadro più chiaro di ciò che deve accadere a un messaggio syslog grezzo prima che possa essere utile in un SIEM—specificamente all'interno dello stack ELK. Dalla parsing all'arricchimento, abbiamo scomposto i passaggi essenziali che trasformano i log rumorosi in intuizioni azionabili.

Nella prossima e ultima parte della nostra mini serie di blog su SIEM Elasticsearch, esamineremo brevemente l'utilizzo di Fluentd invece di Logstash e toccheremo Elastic Security.