IDS/IPS on My personal blog

SIEM e correlazione: dai log sparsi all'allarme che conta

Sat, 12 Sep 2026 09:00:00 +0200

Perché conta

Ogni componente di sicurezza vede un frammento. L’IDS Suricata vede un pacchetto sospetto; il firewall vede una connessione bloccata; il server vede un login fallito; il DNS vede una query strana. Preso da solo, ogni evento è rumore. L’attacco reale vive nella relazione tra questi frammenti: un login da un paese insolito, seguito da una connessione verso un host mai visto, seguita da un trasferimento dati anomalo. Il SIEM (Security Information and Event Management) è il punto dove tutti i log confluiscono, vengono resi comparabili, e correlati in storie che un essere umano può leggere.

Le tre fasi: raccogliere, normalizzare, correlare

  flowchart LR
    F[Firewall] --> C[Collector]
    I[IDS/IPS] --> C
    S[Server / auth] --> C
    D[DNS] --> C
    C --> N["Normalizzazione<br/>(schema comune)"]
    N --> R["Motore di correlazione<br/>(regole)"]
    R --> A[Allarme prioritizzato]
    R --> St[(Storage ricercabile)]

Raccogliere: convogliare log eterogenei (syslog, JSON, eventi Windows) in un punto unico.
Normalizzare: mappare campi diversi su uno schema comune. L’IP sorgente si chiama src_ip ovunque, non source, client, ip.src a seconda del prodotto. Senza questo passo, la correlazione è impossibile.
Correlare: applicare regole che legano eventi di sorgenti diverse nel tempo.

La normalizzazione è la fase meno vistosa e la più importante: è ciò che permette di chiedere “tutti gli eventi da questo IP” e ottenere firewall, IDS e auth insieme.

Perché la correlazione cambia tutto

Un singolo login fallito è normale. Cento login falliti su un account, seguiti da uno riuscito, seguito da un accesso a dati sensibili, sono un attacco di brute force andato a segno. Nessuno dei tre eventi, da solo, farebbe scattare nulla; la loro sequenza sì.

regola: brute force riuscito
  QUANDO  >= 20 eventi "login fallito" (stesso account, finestra 5 min)
  SEGUITO DA  1 evento "login riuscito" (stesso account)
  ALLORA  allarme priorità ALTA, tecnica ATT&CK T1110

È la differenza tra guardare i pixel e vedere l’immagine. La correlazione temporale e per entità (stesso utente, stesso host, stesso IP) è il cuore del valore di un SIEM.

Scrivere detection: Sigma e ATT&CK

Le regole di detection si scrivono una volta e, idealmente, si eseguono su SIEM diversi. Sigma è un formato aperto che descrive la logica in YAML, indipendente dal prodotto, e si compila verso il linguaggio di query del SIEM specifico.

title: Login riuscito dopo molti fallimenti
logsource:
  category: authentication
detection:
  failures:
    event: login_failed
    count: '>=20'
  success:
    event: login_success
  timeframe: 5m
  condition: failures followed by success
level: high
tags:
  - attack.credential_access
  - attack.t1110        # Brute Force

Legare ogni regola a una tecnica MITRE ATT&CK (qui T1110) dà due vantaggi: un linguaggio condiviso tra chi scrive e chi risponde, e una mappa della copertura — quali tecniche d’attacco sapete rilevare e quali no.

Il nemico vero: i falsi positivi

Un SIEM che grida a ogni evento diventa rumore che nessuno guarda — ed è così che gli attacchi reali passano inosservati, sepolti sotto mille allarmi innocui. Il lavoro continuo di un SIEM non è scrivere regole, ma affinare quelle che ci sono: ridurre i falsi positivi con contesto (whitelist di host noti, soglie tarate sul traffico reale, arricchimento con threat intelligence). Una regola che genera 500 allarmi al giorno, di cui 2 veri, è peggio di nessuna regola: addestra l’analista a ignorarla.

Lab

Con uno stack SIEM da laboratorio (Wazuh, o Elastic Security, o un semplice Loki/OpenSearch):

Convogliate i log di un firewall (nftables), di Suricata e dell’autenticazione (auth.log) in un collector unico.
Verificate la normalizzazione: cercate un IP e controllate di vedere eventi da tutte e tre le fonti con campi coerenti.
Scrivete una regola di correlazione “brute force riuscito” come sopra.
Simulate l’attacco (molti login falliti via Hydra in laboratorio, poi uno riuscito) e verificate che scatti un solo allarme correlato, non venti.

Domanda: se ho già un IDS che genera allarmi, perché aggiungere un SIEM sopra?

Perché l'IDS vede solo la rete, e solo un evento alla volta. Suricata vi dice "pacchetto sospetto da X": non sa se quel pacchetto è arrivato dopo un login anomalo, né se lo stesso X sta anche fallendo autenticazioni su un altro server. Il SIEM esiste proprio per unire la vista di rete dell'IDS con quella di host, autenticazione e applicazioni, e per mettere in relazione eventi che nessuna singola sonda può collegare. In più, concentra in un posto la ricerca forense ("cosa ha fatto questo IP nelle ultime 24 ore, ovunque?") e la misura della copertura rispetto ad ATT&CK. L'IDS è una sorgente eccellente per il SIEM, non un suo sostituto: uno vede i pacchetti, l'altro vede la storia.

Conclusione

Un SIEM trasforma log sparsi e incomparabili in una vista unica e, soprattutto, correlata: è il luogo dove i frammenti visti da IDS, firewall, server e DNS diventano la storia di un attacco. Le tre fasi — raccogliere, normalizzare, correlare — culminano nel punto che conta: legare eventi innocui in un allarme che ha senso. Il formato Sigma e la mappa ATT&CK rendono le detection portabili e misurabili; e il lavoro infinito è tenere bassi i falsi positivi, perché un allarme ignorato è peggio di nessun allarme.

IDS e IPS con Suricata

Tue, 25 Aug 2026 09:00:00 +0200

Perché conta

Il firewall decide chi può parlare con chi. Ma una connessione permessa — un HTTP verso il server web in DMZ — può trasportare un exploit. Il firewall non lo vede: per lui è traffico sulla porta 443, consentito. Serve qualcosa che ispezioni il contenuto e riconosca gli schemi di un attacco. Questo è un IDS/IPS, e Suricata è lo strumento open source di riferimento.

IDS o IPS: dov’è sulla rete

La stessa macchina fa due mestieri diversi a seconda di dove la mettete.

  flowchart LR
    subgraph IDS["Modalità IDS — osserva"]
        T1[Traffico] --> SW[Switch<br/>port mirror] -.copia.-> S1[Suricata]
        T1 --> Dest1[Destinazione]
        S1 --> Alert1[Allarme]
    end
    subgraph IPS["Modalità IPS — blocca"]
        T2[Traffico] --> S2[Suricata<br/>inline] --> Dest2[Destinazione]
        S2 --> Drop[Scarta i pacchetti malevoli]
    end

IDS (Intrusion Detection System): Suricata riceve una copia del traffico (da una porta mirror dello switch) e genera allarmi. Non è nel percorso dei pacchetti: non può rallentare né bloccare nulla. Se va in crash, la rete non si ferma.
IPS (Intrusion Prevention System): Suricata è inline, cioè in mezzo al traffico. Può scartare i pacchetti malevoli, ma ogni pacchetto ci passa attraverso: diventa un punto di rallentamento e di possibile guasto.

La scelta è un compromesso tra sicurezza e rischio operativo. Spesso si parte in IDS per “ascoltare”, e si passa a IPS solo sulle regole di cui ci si fida.

Installare Suricata nel lab

Nel lab containerlab si aggiunge un nodo con Suricata. In IDS ascolta un’interfaccia; in IPS si mette tra due interfacce con nfqueue e una regola nftables che devia il traffico.

# IDS: ascolta eth1 e logga in formato EVE (JSON)
suricata -i eth1 -l /var/log/suricata

# aggiornare le regole (Emerging Threats Open)
suricata-update

Gli allarmi finiscono in /var/log/suricata/eve.json, una riga JSON per evento, pronta per essere letta da strumenti come EveBox o inviata a un sistema di log centralizzato — il tema del capitolo sull’osservabilità.

Anatomia di una regola

Una regola Suricata ha due parti: l’header (azione, protocollo, chi verso chi) e le opzioni tra parentesi (cosa cercare, come segnalarlo).

1
2
3

alert tcp any any -> 10.0.1.10 80 (msg:"Possibile SQL injection UNION SELECT"; \
    content:"UNION"; nocase; content:"SELECT"; nocase; distance:0; \
    flow:established,to_server; classtype:web-application-attack; sid:1000001; rev:1;)

Letta a pezzi:

alert tcp any any -> 10.0.1.10 80: genera un allarme per il traffico TCP da chiunque verso il server web (porta 80). In IPS, alert diventa drop.
content:"UNION"; nocase;: cerca la stringa UNION nel payload, ignorando maiuscole/minuscole.
distance:0; sul secondo content: SELECT deve comparire dopo UNION.
flow:established,to_server;: solo su connessioni già stabilite, nei pacchetti verso il server. Riduce i falsi positivi.
sid:1000001;: l’identificativo univoco della regola. I sid locali partono da 1000000.

Il formato è lo stesso di Snort, quindi gran parte delle regole è interscambiabile.

Riconoscere gli attacchi dei capitoli precedenti

Suricata non vede l’ARP spoofing del capitolo 02 con una regola sul contenuto — ARP è a livello 2 — ma ha un modulo dedicato che segnala quando lo stesso IP cambia MAC di continuo. Lo scan nmap -sS invece si riconosce dalla frequenza:

alert tcp any any -> $HOME_NET any (msg:"Possibile port scan SYN"; \
    flags:S; flow:to_server; \
    threshold:type both,track by_src,count 30,seconds 5; \
    classtype:attempted-recon; sid:1000002; rev:1;)

threshold è la chiave: non allarma su un singolo SYN (normale), ma su 30 SYN in 5 secondi dalla stessa sorgente, che è lo schema di uno scan. Senza soglia, una regola così genererebbe migliaia di falsi positivi.

Il problema vero: i falsi positivi

Un IDS che allarma su tutto è un IDS che nessuno guarda. La gestione di un IDS non è scrivere regole, è ridurre il rumore: alzare le soglie, limitare le regole al traffico che conta, disattivare quelle che non si applicano alla propria rete. Un ruleset Emerging Threats completo ha decine di migliaia di regole: attivarle tutte ciecamente seppellisce gli allarmi veri sotto quelli inutili.

Lab

Avviate Suricata in IDS sul nodo che riceve il traffico.
Dal nodo attacker, lanciate nmap -sS contro un altro nodo.
Aggiungete la regola sid:1000002 in un file local.rules, ricaricate e ripetete lo scan.
Leggete eve.json e trovate l’evento di tipo alert generato dallo scan: jq 'select(.event_type=="alert") | .alert.signature' /var/log/suricata/eve.json.

Domanda: perché in IDS Suricata non può bloccare lo scan che rileva?

Perché in modalità IDS riceve solo una copia del traffico da una porta mirror: i pacchetti veri hanno già raggiunto la destinazione quando Suricata li analizza. Può solo generare un allarme a posteriori. Per bloccare serve la modalità IPS, dove Suricata è inline e ogni pacchetto deve attraversarlo prima di proseguire: solo lì drop ha effetto. Il prezzo è che Suricata diventa un punto critico: se si satura o va in crash, blocca tutto il traffico.

Conclusione

Un IDS/IPS è il secondo strato della difesa in profondità: vede ciò che il firewall lascia passare. Ma vale solo quanto le sue regole e la cura con cui si combatte il rumore. Un IDS installato e dimenticato produce allarmi che nessuno legge.

Fin qui abbiamo lavorato su pacchetti in chiaro. Dal prossimo capitolo saliamo all’applicazione, dove entra la crittografia: come TLS protegge una connessione, e perché nemmeno un IPS inline può leggere dentro un flusso cifrato correttamente.

Prossimo nella serie: 06 · TLS 1.3 in profondità · Torna alla roadmap