Network Hunting con Zeek e Suricata: deployment, tuning delle regole, parsing TLS e processi Alert-to-Case

Network-Hunting con Zeek e Suricata è particolarmente efficace quando non viene inteso come «un altro sensore», ma come disciplina operativa: architettura di capture pulita, tuning controllato delle regole, metadati TLS affidabili e un processo che trasformi gli alert in casi tracciabili. Zeek (Network Security Monitor, genera metadati strutturati di protocollo e flow) e Suricata (motore IDS/IPS, verifica il traffico rispetto a firme e regole di protocollo) si completano molto bene – ma solo se deployment e percorso dei dati sono corretti.

Questo contributo si rivolge ad amministratori e operatori che vogliono partire in modo pragmatico: quale topologia di sensori funziona nella pratica? Come evitare che 10.000 alert al giorno paralizzino i team? Cosa è ancora possibile nell’analisi del TLS, pur con i contenuti cifrati? E come costruire un processo alert-to-case che regga in audit, incident response e nella gestione quotidiana?

Network-Hunting con Zeek e Suricata nella pratica

Zeek è potente quando si vuole ricavare rapidamente metadati utilizzabili dai pacchetti grezzi: dati di connessione (5-Tuple, durata, byte), eventi di protocollo (ad es. query DNS, header HTTP, dati del TLS-Handshake) e metadati dei file. Suricata è efficace quando si vogliono riconoscere pattern noti: firme (classiche «Rules»), decoder di protocollo, rilevamento di anomalie e – a seconda della modalità operativa – anche il blocco inline come IPS.

Nei setup di hunting Suricata è spesso più indicata come IDS (passiva), perché un IPS inline può introdurre rapidamente rischi di disponibilità: drop false-positive, routing asimmetrico, problemi di ricostruzione delle sessioni. Zeek rimane passivo ed è spesso più «onesto» nella qualità dei dati – a condizione che capture e timestamp siano corretti.

Importante è gestire le aspettative: con TLS di norma non si vedono i contenuti, ma molti segnali derivano dall’handshake e dal comportamento della connessione. Questo è sufficiente per molte analisi (indicatori C2, catene di destinazione insolite, SNI sospette, anomalie nei certificati), ma non sostituisce la telemetria host.

Architettura di deployment: TAP vs. SPAN, posizionamento dei sensori e strategia di fallback

La principale fonte di errori nel deployment dei sensori non è il software, ma l’accesso alla rete. Per Zeek/Suricata è necessario Packet Capture (PCAP) o rilevamento basato su AF_PACKET/DPDK. Determinanti sono: visibilità completa, assenza di perdita di pacchetti e sincronizzazione temporale corretta.

TAP o SPAN?

Un TAP (Test Access Point) è una diramazione fisica che tipicamente è più stabile: riflette i bit senza «interpretazione» dello switch. Un SPAN/Mirror-Port sugli switch è spesso più rapidamente disponibile, ma introduce insidie tipiche: oversubscription (più traffico di quanto il mirror port possa sostenere), visibilità VLAN incompleta, bursting di pacchetti e – a seconda della piattaforma – effetti di filtraggio sottili.

• TAP: migliore per la forense affidabile, costi hardware più elevati, ma operatività più riproducibile.
• SPAN: rapido, economico, ma è necessario verificare attivamente il rischio di drop e la completezza dei dati.

Dove posizionare?

Per l’avvio sono pratici tre punti:

• Edge Internet / Perimetro: buona visibilità su ingressi e uscite (Egress è spesso più importante dell’Ingress per l’hunting).
• Aggregazione del data center: traffico East-West tra reti server – rilevante per il movimento laterale.
• Segmento con „gioielli di corona“: database, back-end ERP/CRM, file service centrali – ideale per il focus-hunting.

Compromesso tipico: avviate con un sensore perimetrale (copertura massima) e aggiungete successivamente sensori di segmento mirati, quando saprete dove risiedono le ipotesi più importanti.

Strategia di rollback già in fase di progettazione

Anche con sensori passivi potete disturbare la produzione: le configurazioni mirror possono essere impostate in modo errato, le NIC dei sensori possono saturare le porte dello switch (p.es. in caso di loop), lo storage può esaurirsi e i sistemi di monitoring possono crollare a causa di tempeste di log. Pianificate quindi:

• Mirror/TAP disattivabile rapidamente (change-plan, porte etichettate in modo univoco).
• Gestire i sensori in modalità „fail-open“ (passiva); IPS solo con autorizzazione separata.
• Rate-limit e backpressure nella pipeline di log (queue, batch, drop-policy).
• Limiti di capacità: PCAP-ringbuffer, rotazione dei log, soglie di allerta dello storage.

Base hardware e prestazioni: evitare perdite prima di ottimizzare le regole

Il tuning delle regole è inutile se i vostri sensori perdono pacchetti. La perdita di pacchetti genera artefatti: handshake TLS troncati, transazioni HTTP mancanti, riassemblaggio dei flussi errato – da ciò derivano ghost-alert e punti ciechi.

Checklist minima per gli host sensore

• NIC: NIC del server con driver stabile; RSS (Receive Side Scaling) attivo, dimensione del ringbuffer adeguata.
• CPU: core sufficienti, pinning/modello worker adeguato; evitare „tutto su Core 0“.
• Storage: volumi separati per log/PCAP; riserva IOPS per i picchi; logrotate testato.
• Tempo: NTP/Chrony stabile; la deriva temporale distrugge la correlazione e la timeline del caso.

Passaggi di verifica: pacchetti scartati, overflow delle code, integrità della cattura

Non verificate solo „il servizio è in esecuzione“, ma se „stiamo processando tutto il traffico“. A seconda del capture-backend le metriche differiscono. Due test di base pratici sono: statistiche dell’interfaccia (kernel) e statistiche del sensore (applicazione).

# Interface-Statistiken (Drops, Errors) – Ausgangspunkt
ip -s link show dev eth1

# Kernel- und Treiberzähler (je nach Treiber aussagekräftig)
ethtool -S eth1 | egrep -i 'drop|dropped|miss|error|fifo'

# Ringbuffer/RX-Tuning prüfen
ethtool -g eth1

# CPU/Softirq-Last im Blick: wenn ksoftirqd hoch geht, drohen Drops
top -H

Se qui notate già drop dei pacchetti, le contromisure tipiche sono: ridurre il carico del mirror (SPAN selettivo), cambiare il backend di cattura (AF_PACKET vs. DPDK), aumentare il RX-Ring, impostare correttamente l’IRQ-Balancing o utilizzare hardware sensore dedicato.

Deployment di Suricata: EVE JSON, set di regole e disciplina sicura degli aggiornamenti

Suricata produce tipicamente i suoi risultati come EVE JSON (eventi strutturati in formato JSON). Per l’operatività e le integrazioni è ideale: SIEM, gestione dei log, message-bus o sistemi di case possono effettuare il parsing degli eventi in modo robusto.

Principi di configurazione che aiutano nella pratica quotidiana

• Separare il percorso operativo da quello di analisi: Suricata scrive localmente, un forwarder (es. Filebeat/Fluent Bit/Vector) inoltra.
• Versionare le regole: repository Git o artifact-registry; non eseguire gli aggiornamenti direttamente „sul sensore“ tramite click.
• Finestra di aggiornamento: gli aggiornamenti delle regole sono di fatto modifiche al codice – con Change-Record e rollback.

Eseguire l’aggiornamento delle regole in modo controllato (flusso di esempio)

# Esempio: aggiornare le regole (Distribution/Tooling varia a seconda dell'ambiente)
# 1) Prima: effettuare il backup delle regole correnti
sudo tar -C /etc/suricata -czf /var/backups/suricata-rules_$(date +%F).tar.gz rules

# 2) Aggiornamento da fonte controllata (es. repo interno / pacchetto firmato)
# (Qui come segnaposto – nella pratica tramite package manager o suricata-update)
# sudo suricata-update --no-test --reload-command 'systemctl reload suricata'

# 3) Controllo sintassi/caricamento e successivo reload
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata

# 4) Rollback: in caso di ondata di allarmi o errori
# sudo tar -C /etc/suricata -xzf /var/backups/suricata-rules_YYYY-MM-DD.tar.gz
# sudo systemctl reload suricata

Perché questo flusso funziona: separate il test (verifica di configurazione/regole) dall’attivazione. E disponete di un’opzione di rollback rapida prima che la pipeline venga sovraccaricata da firme errate.

Deployment di Zeek: metadati come base per l’hunting e ritaglio log sensato

Zeek genera molti tipi di log (es. conn, dns, http, ssl/tls). Per l’operatività spesso vale il principio „meno è più“: se attivate „tutto“, aumentano il carico su storage e parsing e i team perdono la visibilità. Iniziate con un set di base che copra le ipotesi tipiche:

• conn: connessioni di base (chi comunica con chi, quando, quanto).
• dns: risoluzione dei nomi (domini C2, sospetto DGA, esfiltrazione via DNS).
• tls/ssl: metadati del handshake (SNI, certificato, versioni, ALPN).
• files (opzionale): metadati dei file (hash) – solo se sostenete il carico I/O.

Un ostacolo frequente è la correlazione tra sensori: se gestite più sensori avete bisogno di ID sensore univoci e fonti temporali coerenti. Altrimenti due eventi possono diventare „due verità“.

Passi di verifica: Zeek-Health e rotazione dei log

# Zeek è in esecuzione e scrive log?
sudo systemctl status zeek
ls -lh /opt/zeek/logs/current/

# Verificare rotazione/archiviazione (percorso dipende dall'installazione)
find /opt/zeek/logs -maxdepth 2 -type d -name "20*" | tail

# Controllo di plausibilità grezzo: conn.log, dns.log, tls/ssl.log stanno crescendo?
for f in conn.log dns.log ssl.log tls.log; do
  test -f "/opt/zeek/logs/current/$f" && echo "OK: $f" || echo "MISS: $f";
done

Se i log non vengono ruotati o gli archivi non vengono ripuliti, non si tratta di un problema estetico: filesystem pieni portano a perdita di dati e, nel peggiore dei casi, a sensori instabili.

Ottimizzazione delle regole in Suricata: dalla valanga di allarmi a segnali affidabili

Ottimizzazione delle regole non significa “disattivare tutto finché non cala il rumore”, ma: definire aspettative, creare baseline, aggiungere contesto e poi affinare in modo iterativo. L’obiettivo è un rapporto segnale-rumore che un team possa effettivamente gestire.

Cause tipiche dei falsi positivi

• Reti incompatibili: le regole scattano su monitoring interno, backup, vulnerability scanner o traffico di proxy.
• TLS ovunque: molte signature pensate per protocolli in chiaro vengono «colpite a metà» dal TLS (SNI/handshake) senza evidenza reale.
• Normalizzazione dei protocolli: reverse-proxy, NAT, load-balancer alterano la visibilità e portano a flussi «strani».
• Riassemblaggio incompleto: perdita di pacchetti o routing asimmetrico generano eventi del decoder fuorvianti.

Workflow pratico di tuning (3 fasi)

1. Fase 1: ridurre il rumore – esclusioni chiare per scanner noti, server di aggiornamento interni, reti di gestione. Questo non è un «filtrare via gli attacchi», ma rimuovere il fuoco continuo che nessuno gestisce.
2. Fase 2: imporre il contesto – generare alert solo quando più condizioni sono vere (p. es. zona di destinazione + protocollo + destinazione rara + porta anomala).
3. Fase 3: integrare nel processo – a ogni regola residua viene assegnata ownership (chi la mantiene?) e un ritmo di revisione.

Importante: il tuning deve sempre basarsi sui dati. Se disattivate regole, documentate il motivo e impostate una data di riesame. Altrimenti si accumulano «passività» che in seguito generano punti ciechi.

Parsing TLS: cosa si può usare in modo affidabile senza decrittazione

Parsing TLS significa analizzare la parte non cifrata dell’handshake TLS. Tra questi rientrano, tra gli altri, SNI (Server Name Indication – l’hostname richiesto), la catena dei certificati, versione/scelta delle cipher e le extension. Zeek e Suricata possono fornire metadati preziosi anche quando il payload è cifrato.

Quali segnali TLS sono utili nella pratica?

• SNI: spesso il più forte indicatore per relazioni di destinazione. Fallisce con IP-only, ESNI/ECH (SNI offuscata) o tunnel TLS.
• Certificato: issuer, subject, validità, self-signed, pattern SAN insoliti. Attenzione: Let’s Encrypt non è «malevolo», ma occorre una buona baseline.
• JA3/JA3S: fingerprint basati sui parametri dell’handshake client/server. Utili per raggruppamenti, ma non come unico «prova di malware», perché i fingerprint collidono e possono cambiare.
• ALPN: negoziazione di HTTP/2, HTTP/1.1 ecc. Aiuta nei profili di protocollo.

Quando il parsing TLS fallisce: con ECH (Encrypted ClientHello) il valore aggiunto classico di SNI si riduce. Inoltre, le middlebox (Proxies) possono „uniformare“ il comportamento TLS visibile, così rischiate di fingerprintare più il proxy che il client.

Insidie: mondi dei Proxy e intercettazione dei certificati

In molte aziende un Proxy termina il TLS e stabilisce una nuova connessione verso la destinazione. Allora al perimetro non vedrete il vero fingerprint del client, ma quello del Proxy. Questo non è „male“, ma dovete adattare le vostre ipotesi: Hunting su „il dispositivo parla direttamente con X“ non funzionerà; Hunting su „il Proxy stabilisce connessioni anomale“ invece può funzionare molto bene.

Alert-to-Case: dagli eventi a processi gestibili

Un alert è un evento tecnico. Un Case è un processo con contesto, responsabilità, timeline e decisione. Senza questa transizione il Network-Hunting spesso finisce come una discarica di allarmi o come progetto una tantum.

Dataset minimo per il Case che si è dimostrato efficace

• Identità: Case-ID, sensore, finestra temporale, asset coinvolti (IP, Hostname, utente se presente).
• Motivazione: quale regola/euristica ha scatenato l’evento, quale evidenza è allegata (righe di log Zeek, alert Suricata, riferimento PCAP).
• Contesto: criticità degli asset, change-ticket noti, finestre di manutenzione, lista IP dei scanner.
• Decisione: True/False Positive, gravità, azione successiva (contain, observe, close).
• Follow-up: task di tuning sì/no, proprietario della regola, promemoria.

Progettazione pragmatica della correlazione

In pratica non correlate „tutto con tutto“, ma costruite poche connessioni robuste:

• Suricata Alert → Zeek Kontext: stesso 5-Tuple (sorgente/destinazione/porte/proto) + finestra temporale.
• Zeek TLS/DNS → Asset-DB: IP/Hostname verso CMDB/inventario (che server è?).
• PCAP on demand: solo per Case escalati; altrimenti metadati sufficienti.

Questo riduce i costi: registrare PCAP continuamente è oneroso (storage, privacy, gestione). Un „PCAP-Ringbuffer per 2–6 ore“ è spesso un buon compromesso per poter tornare indietro in caso di incidente, senza conservare tutto continuamente.

Log-Pipeline e conservazione dei dati: robustezza prima del „bel dashboard“

La maggior parte dei guasti avviene tra sensore e analisi: Log-Forwarder bloccato, coda che si riempie, Indexer sovraccarico, timestamp errati, campi che cambiano dopo gli update. Trattate la pipeline come un sistema produttivo.

Best Practices per Forwarding e Backpressure

• Spooling locale: il Forwarder deve poter bufferizzare (Disk-Queue), altrimenti perdete eventi in caso di interruzioni brevi.
• Controllo dello schema: versionare EVE JSON/Zeek-Logs; testare le modifiche ai parser prima di portarle in produzione.
• Separazione tra „hot“ e „cold“: ricerca attiva nell’indice veloce, conservazione a lungo termine come archivi compressi.

Passi di verifica: correlazione temporale e stabilità dei campi

Se fate Hunting, il „tempo“ è una funzione centrale. Verificate regolarmente:

• Drift tra sensore, Log-Collector, SIEM-Indexer (stato NTP).
• Fusi orari (UTC vs ora locale) in tutti i livelli.
• Nomi/tipi dei campi dopo gli update (p. es. campi EVE di Suricata, formati dei log Zeek).

Troubleshooting: quando i risultati non corrispondono alla vostra realtà

È normale che le prime settimane appaiano „strane“. È fondamentale verificare in modo sistematico se il problema risiede nella rete, nella cattura, nel parsing o nel processo.

Sintomo: molti alert TLS, ma nessuna traccia DNS corrispondente

• CAUSA: il DNS viene risolto/accodato internamente (resolver), i client usano DoH/DoT (DNS over HTTPS/TLS) o un proxy effettua la risoluzione.
• VERIFICA: Si vede il traffico sulle porte 53/853? Ci sono connessioni DoH verso resolver noti? Tutto passa attraverso un proxy?
• CONTROMISURA: posizionare il sensore più vicino ai client/ai resolver o formulare ipotesi a livello di proxy.

Sintomo: regole che scattano su “tutto”, soprattutto durante backup/scansioni

• CAUSA: scanner e strumenti di backup generano pattern simili a scan di exploit (molte destinazioni/porte/richieste).
• VERIFICA: identificare l’IP sorgente, confrontare finestre di manutenzione e lista degli strumenti.
• CONTROMISURA: esclusioni con documentazione chiara; una policy separata per il „rumore“ nelle reti di management.

Sintomo: log di protocollo mancanti o instabili

• CAUSA: packet drop, routing asimmetrico, mirror VLAN errato, MTU/fragmentazione.
• VERIFICA: drop/errori come sopra, configurazione SPAN, confronto con NetFlow/log firewall.
• CONTROMISURA: usare TAP, selezionare SPAN, adeguare Sensor-NIC/CPU/Backend.

Proposta di implementazione: in 14 giorni verso un hunting operativo

Un piano praticabile vale più di “installiamo e vediamo”. Il seguente flusso si è dimostrato realistico senza sovraccaricare i team:

Fase 1 (Giorno 1–3): visibilità e stabilità

• Installare il sensore al perimetro o sul punto di aggregazione (passivo).
• Assicurare NTP/Chrony, definire policy di storage e rotazione.
• Verificare l’elaborazione senza drop (testare nei periodi di picco).

Fase 2 (Giorno 4–7): rendere i dati utilizzabili

• Portare Suricata EVE JSON e i log core di Zeek nel logging centrale.
• Primi dashboard/query: destinazioni principali, domini nuovi, SNI poco frequenti, porte insolite.
• Misurare il flusso di alert: Top-10 regole, Top-10 sorgenti, Top-10 destinazioni.

Fase 3 (Giorno 8–14): tuning e processo dei casi

• Riduzione del rumore con esclusioni documentate.
• Definire un template per i case (campi, responsabilità, SLA su piccola scala).
• Review settimanale: quali regole producono valore, quali no, quali ipotesi mancano.

Conclusione: l’hunting è operatività – e Zeek/Suricata sono la vostra sensoristica

Zeek e Suricata forniscono insieme una base molto solida per il network-hunting se prima si assicura la qualità della capture, poi si ottimizzano le regole in modo iterativo e si classificano correttamente i metadati TLS. La leva principale alla fine non è „più regole“, ma il processo alert-to-case: responsabilità chiare, evidenze riproducibili e un feedback loop che migliora continuamente tuning e qualità dei dati.

Se desiderate approfondire il tema in ambito di sicurezza API, gestione centrale dei secret o logging degli accessi remoti, il passo successivo deve essere sempre lo stesso: aumentare la visibilità in modo mirato, ma solo dove potete anche operationalizzare i riscontri.

Per questo tema sono inoltre importanti l’architettura Ids/Nsm e il rule-tuning di Suricata. Il contributo inquadra questi aspetti in modo comprensibile e mostra su cosa occorre concentrarsi nella pratica quotidiana.