Dietro le Quinte di Internet: Vi Svelo il Dataset che Cambia Tutto sull’Analisi del Traffico di Rete!

Ciao a tutti, appassionati di tecnologia e misteri del web! Oggi voglio portarvi con me in un viaggio affascinante, un po’ come sbirciare dietro le quinte del grande spettacolo che è Internet. Parliamo di qualcosa che, per chi come me si occupa di reti e dati, è prezioso come l’oro: un dataset di traffico di rete reale. Sì, avete capito bene, non roba da laboratorio, ma dati veri, pulsanti, raccolti direttamente sul campo!

Vi siete mai chiesti come fanno i gestori di rete a sapere cosa succede, a prevedere i picchi di traffico, o come fanno gli esperti di sicurezza a scovare attività sospette? Beh, una grossa parte della risposta sta nell’analizzare i dati di traffico. Ma c’è un “ma”: per anni, molti di noi ricercatori abbiamo dovuto accontentarci di dataset creati in ambienti simulati. Immaginate di voler studiare il comportamento degli animali selvatici osservandoli solo allo zoo: utile, certo, ma non è la stessa cosa della savana, vero? Ecco, per il traffico Internet è un po’ la stessa storia.

L’Importanza di Dati “Veri”

Avere dati autentici è cruciale. Pensateci: la rete è un ecosistema vivo, in continua evoluzione, con milioni di utenti, comportamenti diversissimi, e caratteristiche che cambiano da un momento all’altro. I dataset da laboratorio, per quanto ben fatti, spesso non riescono a catturare questa complessità, questa “verità” della rete. E questo può portare a modelli di analisi che, una volta messi alla prova nel mondo reale, non funzionano come dovrebbero.

Il nostro obiettivo, quindi, è stato quello di creare uno schema di raccolta dati in-situ, cioè direttamente nell’ambiente reale, coinvolgendo un gran numero di dispositivi e utenti. Abbiamo voluto catturare il traffico così com’è, con tutte le sue sfumature, includendo sia quello crittografato (che è sempre di più!) sia quello non crittografato. Poi, con un attento lavoro di “pulizia”, anonimizzazione (la privacy prima di tutto!), ingegnerizzazione delle feature (cioè l’estrazione delle caratteristiche utili) e etichettatura, abbiamo messo a disposizione una base di dati aperta. La speranza è che possa dare una bella spinta alla ricerca accademica e alle applicazioni pratiche nel campo dell’analisi del traffico.

Perché Ne Avevamo Bisogno?

Internet è ormai la spina dorsale della nostra vita quotidiana e produttiva. Con l’integrazione delle reti cloud, l’espansione della sua scala e la miriade di applicazioni che usiamo ogni giorno (pensate solo a quanto traffico generano i video su TikTok ogni 10 minuti!), capire cosa succede “sotto il cofano” è fondamentale. Il traffico nelle reti urbane degli operatori cresce a un ritmo del 15% annuo! Questo ci dice che dobbiamo assolutamente comprendere le componenti informative chiave e i pattern di traffico.

Questa comprensione è vitale per:

• Migliorare il valore operativo delle reti.
• Potenziare le capacità di trasformazione dei dati.
• Abilitare operazioni automatizzate e intelligenti.
• E, non da ultimo, migliorare la soddisfazione di noi utenti!

Allo stesso tempo, non possiamo dimenticare i rischi per la sicurezza: attacchi denial of service, worm, ransomware… sono all’ordine del giorno. Estrarre automaticamente informazioni utili dalle applicazioni di servizio dal traffico esistente è una tendenza industriale che riflette la crescente domanda di comprensione dei pattern di traffico utente e di protezione della rete.

Il traffico di rete è come un fiume di dati che riflette come usiamo la rete. È facilmente accessibile, ma la sua mole è gigantesca. Sviluppare metodi e sistemi individuali per raccogliere questi dati sarebbe uno spreco di risorse enorme. Ecco perché sfruttare dataset pubblici, già puliti ed elaborati, è imperativo. Certo, esistono dataset pubblici validi come ISCXVPN016 e CSE-CIC-ISDS2018, ma sono spesso statici, raccolti in ambienti simulati e non aggiornati in tempo reale. I nostri dataset, invece, derivano da dati di traffico di interazione utente Internet in tempo reale, raccolti direttamente dalla rete vera, non da test su PC o dispositivi mobili.

Dopo aver anonimizzato le informazioni chiave degli utenti, i nostri modelli di elaborazione dati e classificazione delle applicazioni di servizio, implementati online su plugin o piattaforme, estraggono i dati di traffico originali e le etichette corrispondenti basate sulla dimensione del flusso di sessione. I dati processati vengono memorizzati in formati PCAP o CSV e raccolti quasi in tempo reale.

Come si “Etichettano” i Dati di Traffico? DPI e DFI a Confronto

Per addestrare i modelli e per l’analisi statistica, è cruciale capire a quale applicazione di servizio corrisponde ogni sessione di traffico. Quindi, bisogna etichettare i dati per sessione. Le etichette di solito hanno due livelli: la categoria principale (es. navigazione web, video) e sottocategorie specifiche (es. TikTok, YouTube).

Nell’industria si usano principalmente due tecnologie per annotare i dati: DPI (Deep Packet Inspection) e DFI (Deep Flow Inspection).

La DPI è nota per il suo algoritmo semplice e la rapida implementazione. Ha un’alta accuratezza nell’identificare le applicazioni, fino al 95% per i flussi HTTP, il che la rende lo standard prevalente. In pratica, la DPI “guarda dentro” il protocollo applicativo del traffico, monitorando i flussi TCP e HTTP per estrarre valori di campi essenziali, come l’host e lo user agent, che spesso contengono l’URL del sito con il nome dell’applicazione. Tuttavia, la DPI ha i suoi nei:

• Costi elevati: raccogliere e archiviare tutto lo spettro o in modalità mirror comporta l’archiviazione di enormi quantità di dati di servizio utente, molti dei quali con scarso valore analitico. Richiede anche una notevole infrastruttura server.
• Privacy: estrarre parole chiave dal traffico non crittografato significa analizzare tutti i dati utente, compromettendo potenzialmente la privacy.
• Traffico crittografato: circa il 60% del traffico di rete reale è crittografato (HTTPS, protocolli di tunneling). La DPI qui fa fatica, perché le informazioni critiche sono nascoste.

La DFI, invece, è un approccio emergente. Invece di stabilire regole fisse, la DFI estrae feature dai dati di traffico originali, le processa e le usa come input per addestrare modelli di machine learning. L’efficacia della DFI dipende dall’analisi e dall’elaborazione delle caratteristiche del traffico. Esistono due metodi principali di estrazione delle feature per la DFI:

• Metodi basati su statistiche delle feature: estraggono feature dalle caratteristiche statistiche delle informazioni laterali di ogni pacchetto in una sessione (es. lunghezza del pacchetto, intervallo di tempo). Usano modelli come random forest o gradient boosting. Consumano poche risorse, sono veloci e adatti per il real-time, ma meno per grandi moli di dati.
• Metodi basati su sequenze: possono usare la sequenza originale delle feature (es. lunghezza pacchetto) come input per modelli come LSTM o CNN monodimensionali; costruire mappe di feature basate su correlazioni multiple (per graph neural network); o convertire la sequenza di byte originali del payload in immagini per CNN bidimensionali. Questi metodi consumano più risorse e sono più lenti, ma usando modelli di deep learning sono adatti per l’elaborazione parallela di grandi quantità di traffico.

Viste le limitazioni della DPI, specialmente con il traffico crittografato, e i suoi costi, noi abbiamo deciso di sfruttare una combinazione di tecnologie DPI e DFI per il nostro dataset. La DPI è efficace per il traffico non crittografato, mentre per quello crittografato abbiamo usato l’annotazione manuale, coadiuvata dalla DPI per il non crittografato, per etichettare l’intero dataset e sviluppare un modello DFI. Successivamente, il modello DFI addestrato migliora l’identificazione del traffico non riconosciuto e crittografato, portando a un’accuratezza di classificazione superiore al 95%!

Uno Sguardo ai Nostri “Colleghi”: Altri Dataset Pubblici

Negli ultimi anni, sono nati numerosi dataset pubblici, ognuno focalizzato su scenari specifici: dataset per l’Internet of Things (IoT), per sistemi di rilevamento delle intrusioni (IDS), e così via. Ad esempio:

• ISCXVPN2016: per distinguere traffico VPN da quello non VPN.
• ISCXTOR2016: per distinguere traffico BitTorrent (BT) da quello non BT.
• CSE-CIC-IDS2018: cattura traffico da server Amazon e include scenari di attacco.
• CICDDoS2019: include attacchi DDoS comuni.
• CIC-Darknet2020: focalizzato sul traffico “dark network”, unendo ISCxTor2016 e ISCxVPN2016.
• CIC IoT Profiling Dataset 2022: un dataset IoT completo per analisi comportamentale e vulnerabilità.
• CIC IoT Distributed Denial of Service Dataset 2023: benchmark per attacchi su larga scala in ambienti IoT.

Questi dataset sono preziosi, ma spesso, come dicevo, sono generati in laboratorio, con una copertura frammentata e limitata. La raccolta dati in ambienti controllati porta a dati su piccola scala, che non rappresentano appieno la varietà di applicazioni a cui accedono gli utenti reali. Inoltre, sono dati statici, non aggiornati. Il nostro approccio, invece, raccogliendo dati da dispositivi edge su larga scala in ambienti di rete autentici, riflette in modo più accurato le diverse applicazioni di servizio utilizzate.

Come Abbiamo Raccolto i Dati: Il Nostro Framework

Il nostro framework di raccolta dati si basa su due componenti principali: l’acquisizione del traffico da dispositivi di accesso, specificamente il BRAS (Broadband Remote Access Server), e da dispositivi edge, in particolare l’ONU (Optical Network Unit). Il BRAS è il punto di accesso per la porta OLT (Optical Line Terminal) e gioca un ruolo cruciale nella ricezione e trasmissione del segnale ottico. L’ONU, o meglio il gateway domestico all’utente finale, è l’interfaccia tra l’equipaggiamento terminale e la rete ottica passiva (PON).

Quando numerose unità di rete come queste monitorano continuamente il traffico Internet, possono catturare pacchetti in tempo reale da un grande volume di utenti. Per sfruttare questi dati, sono necessarie una serie di elaborazioni. Inizialmente, un sistema di plugin installato nelle unità di rete esegue una pulizia dei dati per eliminare quelli errati o anomali. Dopo la pulizia e il calcolo delle feature, i dati vengono ulteriormente processati per generare file PCAP (formato standard per catturare il traffico di rete) e CSV (dati in forma tabellare, più facili da analizzare).

Questi file vengono archiviati su un server cloud. Da lì, vengono scaricati su un server locale dove vengono utilizzati per addestrare modelli di Intelligenza Artificiale. Questi modelli imparano le caratteristiche e i pattern del traffico di rete. Durante l’addestramento, il modello AI offre feedback per ottimizzare l’implementazione dei plugin, creando un meccanismo di elaborazione dati a ciclo chiuso che assicura un’ottimizzazione continua del sistema.

Per darvi un’idea della scala: per la raccolta su un dispositivo BRAS in una città di livello prefettizio, parliamo di 19.417 utenti online che generano un traffico bidirezionale di circa 45 Gbit/s durante le ore di punta, e circa 2,47 milioni di sessioni di rete ogni 5 minuti! Per i dispositivi ONU, un plugin può generare 400 log al secondo per unità, servendo 26.400 utenti attivi con una capacità di archiviazione giornaliera di 3.3TB.

Un dettaglio tecnico interessante: abbiamo scoperto sperimentalmente che per l’estrazione delle feature statistiche è ottimale catturare solo i primi 8 pacchetti di ogni flusso. Aumentare questo numero non portava a miglioramenti significativi nell’accuratezza della classificazione, ma aumentava il carico computazionale.

Le Feature che Contano

Una volta che i dati grezzi (file PCAP) sono pronti, inizia il processo di estrazione delle feature. Questo include:

1. Trattamento di purificazione: i file PCAP vengono divisi in sessioni basate sullo stesso quintuplo (IP sorgente/destinazione, porta sorgente/destinazione, protocollo).
2. Rimozione indirizzi IP invalidi.
3. Filtraggio pacchetti: selezione dei primi 8 pacchetti per sessione.
4. Divisione pacchetti: in uplink e downlink.
5. Selezione feature originali: da ogni pacchetto si estraggono due sequenze numeriche: intervallo di arrivo del pacchetto e numero di byte del pacchetto.
6. Calcolo statistiche: per ogni flusso si calcolano 8 valori statistici (minimo, massimo, media, deviazione assoluta mediana, deviazione standard, mediana, 25° percentile, 75° percentile). Questo porta a 48 feature totali.
7. Si aggiungono poi feature come il numero di pacchetti uplink, la codifica del protocollo di trasporto (TCP, UDP), e il numero di porte fisse 80/443 (HTTP/HTTPS).

In totale, abbiamo identificato 54 feature rappresentative. Le etichette delle applicazioni di servizio sono state standardizzate in nove categorie: archiviazione di rete, trasmissione di rete, video di rete, giochi web, messaggistica istantanea, sicurezza di rete, protocollo tunnel, servizio mail e navigazione web.

Dove Trovare i Dati e Validazione Tecnica

Il dataset che abbiamo creato è pubblicamente disponibile sul repository figshare (DOI: 10.6084/m9.figshare.28380347) e su GitHub (https://github.com/zqxfree/Real-network-datasets-for-application-analysis/blob/main/dataset). Troverete file PCAP grezzi (anonimizzati, ovviamente!) e file CSV con le feature estratte, sia per i dati raccolti dai BRAS (5.36 GB) che dagli ONU (5.05 GB).

Ma come facciamo a dire che questi dati sono “buoni”? Abbiamo fatto una validazione tecnica confrontando il nostro dataset con uno pubblico simile, l’ISCXVPN2016, su tre aspetti:

1. Qualità dei dati: entrambe le raccolte coprono le stesse sette principali categorie di applicazioni, e le dimensioni dei file e il numero di sessioni per categoria sono simili, suggerendo un’alta qualità.
2. Integrità dei dati: abbiamo esaminato l’integrità dei flussi TCP (completezza del three-way handshake) e le percentuali di perdita pacchetti per UDP. Il nostro dataset ha mostrato un’integrità dei flussi TCP superiore al 99% e tassi di perdita pacchetti UDP inferiori allo 0.05%, risultati migliori rispetto al dataset di confronto.
3. Autenticità dei dati: abbiamo condotto interviste a un campione di 10 utenti (su un totale di 45.803) e i loro comportamenti riflessi nei dati sono risultati coerenti con i pattern di utilizzo reali della rete.

In sintesi, possiamo dire con una certa sicurezza che il nostro dataset è di alta qualità, integro e autentico, pronto per essere utilizzato dalla comunità scientifica!

Una Nota sulla Privacy e il Futuro

È fondamentale sottolineare che, per garantire un’esperienza utente ottimale e una qualità del servizio (QoS) efficiente e stabile, il monitoraggio del traffico è indispensabile ed è esplicitamente stipulato negli Accordi sul Livello di Servizio (SLA). Questi accordi divulgano in modo trasparente i dettagli del monitoraggio. Inoltre, i dati di traffico degli utenti rimangono dissociati da informazioni personalmente identificabili (PII) come i numeri di telefono, quindi non sorgono preoccupazioni etiche.

Guardando al futuro, prevediamo di incorporare periodicamente nuovi dati di traffico per sostituire quelli obsoleti, mantenendo una stabilità relativa nel volume totale dei dati. Questo meccanismo di aggiornamento dinamico assicura la continua rilevanza e utilità del dataset. Spero davvero che questo lavoro possa aiutare molti ricercatori a fare passi avanti significativi nell’affascinante campo dell’analisi del traffico di rete!

Fonte: Springer