Network Analysis System - Analisi Intelligente del Traffico di Rete

Sistema di analisi del traffico di rete basato su Suricata e Large Language Models (LLM) per l'identificazione intelligente di minacce e anomalie.

📋 Indice

• Panoramica
• Architettura
• Componenti
  • 1. realtime.go
  • 2. tokrealtime.py
  • 3. Polar Proxy (Opzionale)
• Flusso di Elaborazione
• Installazione
• Configurazione
• Utilizzo
• Funzionalità Avanzate
• Output

🎯 Panoramica

Il sistema combina l'analisi tradizionale di Suricata con l'intelligenza artificiale per:

• Correlare flussi di rete e alert di sicurezza
• Identificare pattern sospetti e falsi positivi
• Fornire analisi contestuali con informazioni su vulnerabilità (CVE)
• Ridurre le allucinazioni del modello LLM attraverso guardrails e esempi few-shot

🏗️ Architettura

Il sistema è composto da due componenti principali che lavorano in pipeline (con Polar Proxy opzionale):

Architettura Base:

Suricata (eve.json) 
    ↓
[realtime.go] → Estrazione e correlazione flussi/alert
    ↓
flow_records_llm_ready.json
    ↓
[tokrealtime.py] → Analisi LLM con guardrails e RAG
    ↓
flow_rationale.txt + Analisi JSON

Architettura con Polar Proxy (Opzionale):

Traffico di Rete
    ↓
[Polar Proxy] → Decodifica TLS/SSL
    ↓
Traffico Decrittografato → Suricata
    ↓
eve.json
    ↓
[realtime.go] → Estrazione e correlazione flussi/alert
    ↓
flow_records_llm_ready.json
    ↓
[tokrealtime.py] → Analisi LLM con guardrails e RAG
    ↓
flow_rationale.txt + Analisi JSON

🔧 Componenti

1. realtime.go - Processore Flussi Suricata

Scopo: Legge i log di Suricata in tempo reale, estrae features dai flussi e correlazioni con gli alert, producendo rappresentazioni ottimizzate per l'analisi LLM.

Funzionalità principali:

• Lettura real-time: Monitora continuamente /var/log/suricata/eve.json
• Estrazione features:
  • Categorizzazione porte (http, https, ssh, dns, ecc.)
  • Classificazione durata (instant, short, medium, long, persistent)
  • Categorizzazione volume (minimal, small, medium, large, massive)
  • Classificazione IP (internal, external, loopback, multicast, reserved)
  • Generazione pattern signature basati su durata, volume, direzione, categoria porta e flag TCP
• Calcolo indicatori di rischio:
  • Analisi porte ad alto rischio (445, 135, 139, 1433, 3389)
  • Rilevamento burst di banda
  • Anomalie TCP (RST su SYN)
  • Attività IP sospetta (possibili DoS)
  • Cooldown per evitare allarmi ripetuti dallo stesso IP
• Correlazione flussi-alert: Raggruppa alert per flow_id
• Rappresentazione LLM: Genera rappresentazioni testuali e token compatte per l'analisi

Output: File JSON con flussi arricchiti (flow_records_llm_ready.json)

2. tokrealtime.py - Analizzatore LLM Intelligente

Scopo: Analizza i flussi processati utilizzando un LLM locale (Ollama) con tecniche avanzate per ridurre falsi positivi e allucinazioni.

Funzionalità principali:

2.1 Analisi Batch Intelligente

• Buffer temporale: Raccoglie flussi per 20 secondi (configurabile)
• Soglie minime: Richiede almeno 5 flussi per analisi batch
• Limite massimo: Analizza al massimo 15 flussi per batch

2.2 Guardrails per Riduzione Allucinazioni

La funzione _apply_guardrails() implementa:

• Whitelist falsi positivi: Pattern noti come benigni:

  • port_scan_known_fp: Scan di porte noti come falsi positivi
  • benign_browse: Navigazione web normale
  • legit_bruteforce: Tentativi di autenticazione legittimi

• Regole deterministiche:

  • Se Suricata severity ≥ 2 → livello minimo "high"
  • Se severity ≥ 3 o alert totali ≥ 10 → livello minimo "critical"
  • Pattern whitelist → abbassa livello a "medium"
  • Pattern critici (scan, flood, bruteforce, exploit) → aumenta a "high"

2.3 Esempi Few-Shot

Include nel prompt esempi esplicativi:

• Esempio 1: Falso positivo benigno (scan senza evidenze di attacco)
• Esempio 2: Allarme reale (brute force con evidenze multiple)

Questi esempi aiutano il modello a distinguere meglio tra falsi positivi e minacce reali.

2.4 Retrieval Augmented Generation (RAG) per CVE

• Caricamento CVE: Legge dati CVE da file JSON (NVD)
• Indicizzazione: Crea indici per servizio e porta
• Retrieval contestuale: Estrae CVE rilevanti per i flussi nel batch
• Ranking: Ordina CVE per:
  • CVSS score
  • Presenza in KEV (Known Exploited Vulnerabilities)
  • Numero di riferimenti
• Inclusione nel prompt: Aggiunge blocco <candidate_cves> con CVE più pertinenti

2.5 Memoria Contestuale

Mantiene traccia degli ultimi 4 batch analizzati per:

• Livelli di minaccia recenti (con peso decrescente)
• Pattern dominanti osservati
• Minacce confermate

2.6 Gestione Flussi ad Alto Rischio

• Flussi con ≥ 5 alert vengono marcati come "malicious" e scritti direttamente nel file rationale senza analisi LLM
• Flussi con severity > 3 possono essere analizzati immediatamente (se HIGH_RISK_IMMEDIATE = True)

3. Polar Proxy (Opzionale) - Decodifica Traffico TLS/SSL

Scopo: Polar Proxy è uno strumento opzionale che decodifica il traffico TLS/SSL, permettendo a Suricata di analizzare traffico HTTPS che altrimenti sarebbe opaco.

Quando utilizzarlo:

• Analisi di traffico HTTPS crittografato
• Necessità di ispezionare contenuti web per rilevare minacce
• Analisi di applicazioni che utilizzano TLS/SSL

Funzionalità:

• Decodifica TLS/SSL: Intercetta e decodifica connessioni TLS/SSL in tempo reale
• MITM (Man-in-the-Middle): Agisce come proxy trasparente per decrittografare traffico
• Output per Suricata: Fornisce traffico decrittografato a Suricata per analisi approfondita
• Logging: Genera log del traffico decrittografato

Integrazione con il sistema:

Con Polar Proxy, l'architettura diventa:

Traffico di Rete
    ↓
[Polar Proxy] → Decodifica TLS/SSL
    ↓
Traffico Decrittografato
    ↓
[Suricata] → Analisi IDS/IPS
    ↓
eve.json
    ↓
[realtime.go] → Estrazione e correlazione
    ↓
flow_records_llm_ready.json
    ↓
[tokrealtime.py] → Analisi LLM
    ↓
flow_rationale.txt

Configurazione:

1. Installazione Polar Proxy:

   • Scaricare da PolarProxy.com
   • Installare seguendo le istruzioni per il sistema operativo

2. Configurazione come Proxy:

   # Avvio Polar Proxy su porta 8080 (esempio)
   polarproxy --listen 0.0.0.0:8080 --cert cert.pem --key key.pem

3. Configurazione Suricata per ricevere da Polar Proxy:

   • Configurare Suricata per ascoltare sul traffico proveniente da Polar Proxy
   • Oppure configurare Polar Proxy per inoltrare a Suricata via mirroring

4. Configurazione Client/Server:

   • Configurare i client per utilizzare Polar Proxy come proxy HTTP/HTTPS
   • Oppure utilizzare tecniche di port mirroring/spanning

Note importanti:

• Polar Proxy richiede certificati SSL per funzionare (generati o forniti)
• Il traffico decrittografato può contenere informazioni sensibili
• Assicurarsi di rispettare le normative sulla privacy e la sicurezza dei dati
• Polar Proxy è uno strumento commerciale (con versione di prova disponibile)

Alternativa senza Polar Proxy: Il sistema funziona perfettamente anche senza Polar Proxy, analizzando:

• Metadati di connessione (IP, porte, durata, volume)
• Pattern di traffico (senza contenuto payload)
• Alert Suricata basati su signature e comportamenti
• Anomalie di rete rilevabili senza decodifica TLS

🔄 Flusso di Elaborazione

Fase 1: Estrazione e Correlazione (realtime.go)

1. Lettura real-time di eve.json (Suricata)
2. Parsing eventi:
   • flow: Estrae features del flusso
   • alert: Estrae informazioni di sicurezza
   • tls: Ignorato per ora
3. Calcolo metriche:
   • Durata, volume, ratio upload/download
   • Categorizzazioni (porta, durata, volume, IP)
   • Pattern signature
   • Indicatori di rischio
4. Correlazione: Raggruppa alert per flow_id
5. Scadenza flussi: Dopo 5 secondi di inattività, il flusso viene finalizzato
6. Output: Scrive record JSON arricchito

Fase 2: Analisi LLM (tokrealtime.py)

1. Lettura di flow_records_llm_ready.json
2. Buffering: Accumula flussi per 20 secondi o fino a 15 flussi
3. Preprocessing:
   • Estrazione CVE rilevanti (RAG)
   • Costruzione contesto memoria
   • Preparazione prompt con esempi few-shot
4. Analisi LLM: Invio a Ollama (modello llama3)
5. Post-processing:
   • Estrazione JSON dalla risposta
   • Applicazione guardrails
   • Logging risultati
6. Output: Scrive rationale in flow_rationale.txt

📦 Installazione

Prerequisiti

• Go 1.19+ (per realtime.go)
• Python 3.8+ (per tokrealtime.py)
• Ollama con modello llama3 installato
• Suricata configurato per scrivere eve.json
• Polar Proxy (opzionale) - Solo se si desidera analizzare traffico TLS/SSL decrittografato

Dipendenze Python

pip install requests

File CVE

Il sistema richiede un file JSON con dati CVE dal National Vulnerability Database (NVD):

• Path: /home/peppe/Desktop/go/combined_cve_data.json
• Formato: Array di oggetti CVE con campi:
  • id: ID CVE
  • description: Descrizione vulnerabilità
  • cvss: Oggetto con baseScore e vectorString
  • services: Array di servizi associati
  • references: Array di riferimenti
  • kev o cisaKnownExploited: Flag per vulnerabilità sfruttate

⚙️ Configurazione

realtime.go

Modificare le costanti all'inizio del file:

const (
    InputFile     = "/var/log/suricata/eve.json"
    OutputFile    = "/home/peppe/Desktop/suricata_output/flow_records_llm_ready.json"
    MaxPayloadLen = 100
)

E il tempo di scadenza flussi (nel main):

processor := NewLLMFlowProcessor(OutputFile, 5) // 5 secondi

tokrealtime.py

Modificare le variabili di configurazione:

INPUT_FILE = "/home/peppe/Desktop/suricata_output/flow_records_llm_ready.json"
LLAMA_API_URL = "http://localhost:11434/api/generate"
LLAMA_MODEL = "llama3"
CVE_DATA_FILE = "/home/peppe/Desktop/go/combined_cve_data.json"

BATCH_TIME_WINDOW = 20      # Analizza ogni 20 secondi
MIN_FLOWS_PER_BATCH = 5     # Minimo 5 flussi per batch
MAX_FLOWS_PER_BATCH = 15    # Limite massimo per analisi batch
HIGH_RISK_IMMEDIATE = False  # Analisi immediata per flussi ad alto rischio

🚀 Utilizzo

Avvio con Polar Proxy (Opzionale)

Se si desidera utilizzare Polar Proxy per decodificare traffico TLS/SSL:

1. Avviare Polar Proxy (prima di Suricata):

   # Esempio configurazione base
   polarproxy --listen 0.0.0.0:8080 --cert /path/to/cert.pem --key /path/to/key.pem

2. Configurare Suricata per analizzare il traffico proveniente da Polar Proxy

3. Avviare Suricata (vedi sezione seguente)

Avvio del Processore Flussi

cd live
go run realtime.go

Il processo rimane in esecuzione e monitora continuamente i log di Suricata.

Avvio dell'Analizzatore LLM

In un altro terminale:

cd live
python3 tokrealtime.py

Oppure dalla directory root:

python3 tokrealtime.py

Nota: Polar Proxy è completamente opzionale. Il sistema funziona correttamente anche senza di esso, analizzando metadati e pattern di traffico senza decodifica TLS.

Esecuzione in Background

# Processore flussi
nohup go run realtime.go > realtime.log 2>&1 &

# Analizzatore LLM
nohup python3 tokrealtime.py > analyzer.log 2>&1 &

🎯 Funzionalità Avanzate

Riduzione Falsi Positivi

Il sistema implementa diverse strategie:

1. Whitelist pattern: Pattern noti come benigni riducono automaticamente il livello di rischio
2. Guardrails deterministici: Regole hard-coded che sovrascrivono decisioni LLM errate
3. Esempi few-shot: Il modello impara da esempi di falsi positivi vs minacce reali
4. Cooldown IP: Evita allarmi ripetuti dallo stesso IP in finestre temporali brevi

Analisi Contestuale CVE

Per ogni batch di flussi:

• Identifica servizi e porte utilizzate
• Recupera CVE rilevanti dal database NVD
• Include CVE top-ranked nel prompt LLM
• Permette al modello di valutare plausibilità di exploit basati su vulnerabilità note

Memoria Contestuale

Il sistema mantiene memoria degli ultimi batch per:

• Rilevare pattern ricorrenti
• Evitare downgrade ingiustificati del livello di minaccia
• Fornire contesto temporale all'analisi

📊 Output

flow_records_llm_ready.json

File JSON con un record per riga, contenente:

• timestamp: Timestamp del flusso
• flow_id: ID univoco del flusso
• llm_representation: Rappresentazione testuale per LLM
• llm_tokens: Rappresentazione compatta tokenizzata
• raw_flow: Oggetto Flow completo con tutte le features
• correlated_alerts: Array di alert Suricata correlati
• alert_count: Numero totale di alert
• max_alert_severity: Severity massima tra gli alert

flow_rationale.txt

File di testo con una riga per flusso analizzato:

<flow_id> [<timestamp>]: <motivazione_analisi>

Esempio:

12345 [2024-01-15T10:30:00Z]: Pattern matches known benign behavior without Suricata evidence
67890 [2024-01-15T10:30:05Z]: High Suricata severity and repeated failures from same IP

Log Console

L'analizzatore LLM stampa su console:

• Livello di minaccia rilevato (con emoji: 🟢 low, 🟡 medium, 🟠 high, 🔴 critical)
• Risultati chiave
• Motivazioni per-flow
• Errori o problemi

🔍 Esempio di Analisi

Un batch tipico potrebbe contenere:

• 8 flussi HTTP/HTTPS
• 2 flussi SSH
• 1 flusso con pattern "short_small_upload_heavy_http_SYN_ACK"
• 1 alert Suricata severity 2

Il sistema:

1. Estrae CVE rilevanti per HTTP/HTTPS e SSH
2. Costruisce prompt con contesto, memoria, CVE ed esempi
3. Invia a LLM per analisi
4. Applica guardrails (severity 2 → minimo "high")
5. Se pattern è whitelist, abbassa a "medium"
6. Scrive rationale con motivazione

🛠️ Troubleshooting

Ollama non risponde

Verificare che Ollama sia in esecuzione:

curl http://localhost:11434/api/generate

Verificare che il modello sia installato:

ollama list

File CVE non trovato

Il sistema continuerà a funzionare senza CVE, ma senza contesto vulnerabilità. Verificare il path in CVE_DATA_FILE.

Suricata non genera log

Verificare che Suricata sia configurato per scrivere eve.json nel path specificato in InputFile.

Flussi non vengono analizzati

Verificare:

• Che realtime.go stia scrivendo in flow_records_llm_ready.json
• Che tokrealtime.py stia leggendo dallo stesso file
• Che ci siano almeno 5 flussi nel buffer per triggerare analisi batch

📝 Note

• Il sistema è progettato per analisi real-time, ma può essere adattato per analisi batch di file storici
• La configurazione attuale è ottimizzata per ridurre falsi positivi, ma può essere regolata modificando le guardrails
• Il modello LLM può essere cambiato modificando LLAMA_MODEL (richiede modello compatibile con Ollama)

🔐 Sicurezza

• Il sistema legge solo log di Suricata e non modifica configurazioni di rete
• I file di output contengono informazioni sensibili (IP, pattern di traffico) e dovrebbero essere protetti
• L'accesso a Ollama è locale e non espone dati all'esterno