Network Traffic Anomaly Detection mediante analisi di flow IPv4 e metriche statistiche

[mluzzetti1-unipi]

Progetto di Gestione Reti Matteo Luzzetti.

[mluzzetti1-unipi]

Il progetto realizza una pipeline completa per l'analisi di traffico di rete a partire da una cattura PCAP.

L'applicazione ricostruisce i flow di rete, li aggrega in finestre temporali e calcola diverse metriche statistiche. Successivamente applica un algoritmo di Anomaly Detection basato sullo Z-score per individuare finestre temporali caratterizzate da comportamenti anomali rispetto al traffico normale.

L'obiettivo del progetto non è identificare automaticamente un attacco, ma evidenziare eventi statisticamente anomali che possano rappresentare un campanello d'allarme da approfondire mediante analisi successive.

Pipeline

L'applicazione è composta da cinque fasi principali.

PCAP
│
▼

1. Lettura dei pacchetti
   │
   ▼
2. Ricostruzione dei Flow
   │
   ▼
3. Aggregazione in finestre temporali
   │
   ▼
4. Anomaly Detection
   │
   ▼
5. Visualizzazione dei risultati

Per la validazione del progetto è stata realizzata una cattura PCAP comprendente differenti tipologie di traffico:

• traffico ICMP normale
• attività di Port Scanning tramite Nmap
• trasferimento dati mediante iperf3

L'algoritmo è stato in grado di individuare automaticamente le principali variazioni statistiche introdotte durante l'esperimento.

[lucaderi]

Analizzando il codice implementato leggo
``

Metrica	Obiettivo
New Flow Count	Individuazione di improvvisi aumenti di nuove connessioni
Distinct Destination Ports	Individuazione di attività di port scanning
Distinct Destination Hosts	Individuazione di scansioni verso host differenti
Port Entropy	Misura della dispersione della distribuzione delle porte di destinazione
Average Packets per Flow	Individuazione di trasferimenti anomali
Average Bytes per Flow	Individuazione di elevati volumi di traffico
Average Flow Duration	Individuazione di comunicazioni particolarmente lunghe
``

Vorrei capire come pensi di calcolare lo z-score se non tramite un analisi storica dei dati raccolti. E con metriche semplici come ad esempio il numero medio di pacchetti per flusso, immagino avrai molti falsi positivi.

In sintesi voglio capire il tuo ragionamento e voglio che tu mi spieghi perche' quanto sopra ha un senso pratico.

[mluzzetti1-unipi]

1. Per il calcolo dello z-score sono consapevole che, in un sistema reale, sarebbe opportuno disporre di una baseline costruita a partire da un’analisi storica del traffico della rete, in modo da stimare un comportamento normale nel tempo.
   Nel mio caso, però, avevo a disposizione una sola cattura PCAP. Ho quindi cercato di progettare l’esperimento in modo che la cattura fosse composta da una fase iniziale di traffico normale, seguita dal port scanning con Nmap, da una nuova fase di traffico normale e infine dal trasferimento con iperf3.
   Ho utilizzato esclusivamente le prime finestre temporali, corrispondenti al traffico normale, come baseline per stimare media e deviazione standard delle metriche. Successivamente ho confrontato tutte le finestre della cattura con questa baseline mediante lo z-score.

2. Concordo sul fatto che metriche considerate singolarmente, come il numero medio di pacchetti per flow, possano essere rumorose e generare numerosi falsi positivi.
   Proprio per questo motivo non considero anomala una finestra temporale quando una sola metrica supera la soglia dello z-score.
   Ho introdotto invece un anomaly score, che conta quante metriche risultano contemporaneamente anomale, e classifico una finestra come anomala solo quando almeno due metriche superano la soglia prefissata.
   L’obiettivo non è eliminare completamente i falsi positivi, ma ridurre il peso delle anomalie dovute a una singola metrica rumorosa e aumentare la probabilità che l’evento segnalato rappresenti un effettivo cambiamento del traffico.