Rilevazione delle anomalie in flussi di traffico di rete con tecniche di analisi di Big Data - PDF\nRilevazione delle anomalie in flussi di traffico di rete con tecniche di analisi di Big Data\nDownload "Rilevazione delle anomalie in flussi di traffico di rete con tecniche di analisi di Big Data"\n1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea magistrale Rilevazione delle anomalie in flussi di traffico di rete con tecniche di analisi di Big Data Anno Accademico 2015/2016 relatore Ch.mo prof. Giorgio Ventre correlatore Ing. Alessio Botta Ing. Mauro Garofalo candidato Maurizio Cacace matr. M63/000559\n2 Ai miei genitori, che hanno creduto in me sin dall inizio. A chi lotta e non si arrende.\n3 Indice Introduzione 1 1 Anomaly Detection Network Anomaly Detection Il concetto di anomalia e normalità Attività anomale nelle reti DoS/DDoS e simili: Probe Attacks: Anomaly Detection Algorithm: difficoltà di progettazione Velocità e accuratezza Evadere la detection Falsi allarmi Scalabilità Tecniche di detection Dataset Metriche qualitative di performance Oltre le reti Dataset MAWI dataset Progetto MawiLab Report MawiLab Tassonomie Signatures Il concetto di Big Data Tecnologie: Apache Hadoop e Apache Spark iii\n4 3.1.1 Apache Spark Resilient Distributed Dataset - RDD Spark Streaming MapReduce e la programmazione funzionale Progettazione di un Anomaly Detector Definizione di flusso Studio preliminare Ground-truth e gold-standard Linguaggio di programmazione utilizzato Le basi dell algoritmo Step principali Netflow Analyzer: architetture realizzate Architettura 1: Spark Streaming Analisi delle performance di esecuzione - test locali Architettura 2: Batch con HDFS locale Analisi delle performance di esecuzione - test locali Archittura 3: Batch con S3 remoto Analisi delle performance di esecuzione - test locali Deployment dell algoritmo su Cloud Scelta dell ambiente operativo Tipi di Istanze EC Topologie EMR Configurazioni Preliminari Analisi dei risultati ottenuti Studio delle performance Scalabilità Analisi dei risultati sperimentali Processo di analisi completo Generazione della Confusion Matrix False Alarm Rate Analisi sui falsi positivi trovati Detection rate, precision e recall iv\n5 Applicazione delle signatures Andamento delle precision calcolate Port type analysis Analisi statistiche sulle tassonomie Conclusioni e sviluppi futuri 89 Ringraziamenti 91 A Appendice - Script Python 92 A.1 Deployment AWS EMR B Appendice - Scala 96 B.1 Architettura 1 - Spark Streaming B.2 Architettura 2 - Batch HDFS B.3 Architettura 3 - Batch S v\n6 Elenco delle figure Firewall Componenti fondamentali della Network Security Esempio di anomalia Tipi di anomalie Attacco DDoS TCP SYN flood Tipologie di attività di rete Quadro generale dei metodi di detection Rappresentazione grafica di una confusion-matrix Albero delle tassonomie Esempio di signature per un netscan Architettura di Hadoop Architettura di Spark Componenti dell architettura Spark Spark Streaming Word Count: Esempio grafico Map - Reduce Flow-Based Architecture Grafico del confronto Andamento anomalie negli anni (percentuali) Andamento anomalie negli anni (quantità) Andamento anomalie nei mesi Slice temporali Struttura dell algoritmo vi\n7 4.4.3 Intero Processo Comunicazione tra driver e cluster Kafka Cluster Topic Architettura 1 - Spark Streaming Architettura 2 - Batch con lo storage HDFS sorgente Architettura 3 - Batch con storage S3 sorgente Confronto tempi medi di esecuzione Cluster di Topologia2-1 Master e 4 Slave Confronti tempi di esecuzione utilizzando S3 dal cluster e fuori dal cluster Tipi di scalabilità Tempi di esecuzione sul cluster EMR Processo di analisi completo Confronti effettuati tra MawiLab e l algoritmo del rapporto per individuare falsi positivi/veri positivi Confronto delle precision, prima e dopo l applicazione delle signatures Confronto delle recall, prima e dopo l applicazione delle signatures Istogramma delle porte contattate unvicoamente da un IP falso positivo 84 vii\n8 Elenco delle tabelle 1.1 Possibili combinazioni di eventi di predizione e classificazione Metriche di performance Elenco delle tassonomie gestite dal progetto MawiLab Pacchetti e Aggregati Netflow Gold-standard (percentuali) Gold-standard (quantità) Calcolo Tempi Streaming Setup Calcolo Tempi Streaming Setup Calcolo tempi Batch da HDFS locale Calcolo tempi Batch da S3 remoto Modelli di VM Topologie Tempi topologia1: 1 master da 8Gb e 2 Slave da 16Gb Tempi topologia2: 1 master da 8Gb e 4 Slave da 8Gb Tempi topologia3: 1 master da 8Gb e 2 Slave da 8Gb Confusion matrix del caso di studio Statistiche sui falsi positivi Confusion Matrix generata usando come gold-standard MawiLab Parametri qualitativi Confusion Matrix generata usando come gold-standard MawiLab e aggiornata dopo l applicazione delle signatures Parametri qualitativi aggiornati dopo l applicazione delle signatures Statistiche percentuali degli IP anomalous/suspicious/notice rilevati da MawiLab e dal nostro algoritmo nel mese di Ottobre viii\n9 Introduzione Oggi, grazie ad una vera e propria rivoluzione tecnologica, il modo di comunicare e scambiare informazioni è completamente mutato. Si parla di realtà o mondo virtuale e di uno stravolgimento totale della vita quotidiana. Internet è usato: per effettuare pagamenti, in casa, nei negozi e per restare connessi con il mondo virtuale. Strutture mediche, di e-commerce, scuole ed infine il controllo del traffico aereo utilizzano la rete per lo scambio di dati e informazioni. Con la crescita e lo sviluppo di questi servizi è nato anche il bisogno di proteggere le stesse informazioni. Con il termine anomaly detection, si intende una tecnica applicabile in numerosi domini e in continua crescita e sviluppo. In particolare, riguarda l analisi e il monitoraggio di dati per rilevare eventuali comportamenti che non risultano essere conformi ad un modello di normalità definito. L obiettivo di questa tesi consiste nell implementare un algoritmo per la rilevazione delle anomalie nelle reti di calcolatori, monitorando e analizzando tracce di traffico reali mediante un infrastruttura performante ed in grado di suddividere il carico di lavoro su più processori, al fine di ottenere un significativo vantaggio nel caso in cui si debba lavorare con una quantità di dati molto grande. La tesi è strutturata come segue: Nel Capitolo 1 verrà introdotto il concetto dell anomaly detection applicato al mondo delle reti di calcolatori. Ci si sofferma sulle numerose tecniche sviluppatesi negli anni per contrastare diversi tipi di anomalie e sulla difficoltà nel progettare un buon algoritmo di detection, che risulti performante e allo stesso tempo accurato. Saranno infatti elencate le metriche qualitative di performance che ogni buon algoritmo di detection deve possedere, per permettere una corretta valutazione dei pattern anomali. Saranno infine analizzati domini differenti dal traffico di rete, dove è possibile applicare le tecniche dell anamoaly detection descritte. Nel Capitolo 2 sarà analizzato il dataset utilizzato dall algoritmo proposto per la rilevazione di pattern anomali nel traffico di rete. Ci si soffermerà in particolare sul dataset fornito da MAWI e sui vantaggi che quest ultimo comporta. Si 1\n10 definirà, inoltre, il progetto MawiLab associato, con brevi cenni alle tecniche di detection applicabili alle tracce di traffico. MawiLab, inoltre, svolgerà il ruolo di gold-standard per il nostro algoritmo. Nel Capitolo 3 ci soffermeremo sul concetto di big data. Verranno descritte le architetture su cui poggerà l algoritmo di detection proposto, in particolare Apache Hadoop, il framework Apache Spark e la loro interazione necessaria all analisi di dati di elevate dimensioni. Verrà descritto il modello di programmazione map-reduce, tipico degli algoritmi di programmazione funzionali. Il Capitolo 4 descriverà nel dettaglio il metodo sviluppato per la rilevazione di pattern anomali nelle reti, soffermandosi sulle diverse architetture realizzate per gestire al meglio la sua esecuzione in modalità differenti: batch e streaming (quest utltima con l ausilio di Apache Kakfa). Poichè l algoritmo è di tipo flowbased, sarà definito il concetto di flusso argomentando gli steps necessari per effettuare un adeguato pre-processing del dato. Sarà introdotto il linguaggio di programmazione funzionale utilizzato e i motivi per cui è stato scelto. Verrano rilevati i tempi di esecuzione dell algoritmo, per ogni architettura realizzata al fine di valutarne la scalabilità, ricorrendo anche ad alcuni confronti grafici. Successivamente verrà valutato il miglioramento ottenuto con l introduzione del calcolo parallelo. Poichè lo scopo finale è l esecuzione in ambiente cloud, saranno utilizzati i servizi di cloud computing forniti da Amazon (AWS EMR, S3). E possibile in questo modo creare diverse topologie di cluster, in un architettura master/slave. Il Capitolo 5 sposterà l attenzione sui risultati ottenuti e sugli IP che l algoritmo, sviluppato nel corso della tesi, ha classificato come anomali. Per effettuare analisi più approfondite, al fine di valutare alcune metriche di interesse come ad esempio la precision, o generare la matrice di confusione, è necessario confrontare i nostri riusultati con la gold-standard MawiLab descritta nel Capitolo 2. L analisi dei risultati ottenuti è importante al fine di valutare la bontà dell algoritmo proposto. L ultima sezione è dedicata alle conclusioni e agli sviluppi futuri includendo possibili miglioramenti da applicare alle metodologie descritte. In Appendice A e B sono riportati i codici più importanti di script o algoritmi impiegati per svolgere alcune delle attività descritte nei vari capitoli. 2\n11 Capitolo 1 Anomaly Detection Come viene descritto nel survey di Chandola del 2009 , il termine Anomaly Detection è usato per descrivere una particolare attività che consente di identificare elementi, eventi o osservazioni che non risultano essere conformi ad uno specifico pattern atteso dal nostro insieme di dati. Tale disciplina trova impiego in diversi domini applicativi ed è utilizzata per molteplici tipologie di dato come ad esempio geografico, temporale, spaziale e in particolare per dati provenienti dalla rete Internet. In generale, l anomaly detection si basa su due concetti fondamentali: 1. Capire cosa rappresenta per noi la normalità. 2. Utilizzare delle metodologie appropriate per analizzare i dati e riuscire quindi a distinguere le istanze anomale da quelle normali. Definire un modello di normalità è molto importante perchè esso determina la bontà della detection: tanto più il modello è preciso, maggiore sarà la precisione della detection. 1.1 Network Anomaly Detection Negli ultimi anni, gli attacchi contro le reti di calcolatori sono cresciuti in maniera allarmante: si parla dei cyber-attacks. Anche le più grandi aziende come Facebook, Twitter e Visa sono state vittime di attacchi informatici. Uno dei comportamenti più comuni di un attacco informatico è quello di trovare una vulnerabilità all interno di un sistema prima che lo sviluppatore o l amministratore dello stesso siano a conoscenza che tale vulnerabilità esista. Per proteggere i dispositivi da danni provocati da eventuali attacchi viene utilizzato il firewall, posizionato tra la rete locale e la rete untrusted (pubblica): è un metodo primitivo per filtrare traffico entrante e bloccare accessi non autorizzati. Fornisce protezione 3\n12 al perimetro e non ha elevate capacità di detection a causa dell enorme mole di traffico che deve gestire. Bensì fornisca protezione da eventuali pacchetti corrotti provenienti dall esterno, il firewall non è in grado di rilevare attacchi o intrusioni all interno del sistema. Si parla, in questo caso, di sistemi software molto più avanzati di un firewall: i Network Intrusion Detection System (NIDS). Figura 1.1.1: Firewall Un NIDS è un dispositivo software o hardware in grado di monitorare e analizzare il traffico di rete, rilevando eventuali intrusioni come ad esempio un Denial-of-Service (DoS), worms o virus. Quando un NIDS rileva un attacco, genera un alert per informare l amministratore di rete. In letteratura esistono numerosi studi che descrivono le diverse tipologie di NIDS e per quale scopo sono stati progettati. In base all analisi portata avanti da questi studi, possiamo affermare che i NIDS si distinguono in due macro categorie: 1. misuse-based 2. anomaly-based, adatti per rilevare anomalie e non attacchi. Un NIDS di tipo misuse-based usa una tecnica basata sul concetto di firme o regole (dette signatures), analoga a quella per il rilevamento dei virus. Un vantaggio di questi tipi di detectors è l efficienza nel rilevare attacchi di cui sono note le signatures o se ne conoscono i pattern. Purtroppo i limiti sono notevoli. Nuovi pattern di attacco non sono facilmente individuabili da questi sistemi, inoltre il database delle signatures necessita di essere aggiornato continuamente in modo da avere performance migliori. A causa di queste forti limitazioni, sono stati introdotti gli anomaly-based NIDS, i quali non usano signatures predefinite. Per individuare le anomalie di rete vengono usati gli anomaly-based NIDS. Il loro scopo è quello di riuscire ad identificare dei pattern eccezionali nel traffico di rete che non sono conformi ad un comportamento normale. Tali pattern non conformi sono 4\n13 spesso marcati come anomali, outliers o eccezioni . Un pattern anomalo nel traffico di rete potrebbe essere causato da un computer compromesso che invia dati sensibili verso un host non autorizzato. In generale, le anomalie nel traffico di rete possono essere causate da moltissimi fattori differenti. Per una rete costituita da centinaia o migliaia di computer, avere dei sistemi che permettano di individuare comportamenti anomali è oramai divenuto indispensabile. Figura 1.1.2: Componenti fondamentali della Network Security 1.2 Il concetto di anomalia e normalità Per comprendere cosa si intende per attività anomala o sospetta è necessario prima di tutto dare una definizione del concetto di normalità. Come descritto in  l idea alla base di un comportamento definito normale è tipicamente introdotta da un modello formale, il quale esprime le relazioni che sussistono tra le variabili fondamentali coinvolte nelle dinamiche del sistema di interesse. Di conseguenza, un evento o un oggetto è definito anomalo se il suo comportamento si discosta dal profilo comportamentale del sistema specificato nel modello di normalità . Esempio Immaginiamo di avere un sistema per l anaomaly detection denominato S. Esso può essere immaginato costituito da una coppia S = (M, D), dove M è il modello del comportamento normale del sistema e D è la misura del coefficente di variazione (COV) delle attività del modello M. Il modello viene usato dal modulo di detection al fine di comprendere se determinate attività (ad esempio nella rete) si discostano dal modello M e poterle quindi catalogare come anomalie o outliers. E la misura del COV che consente la classificazione di eventi o oggetti come anomali o outliers. Vengono definite quindi delle regioni che rappresentano il comportamento normale e vengono dichiarate anomale tutte quelle osservazioni che non appartengono alla regione definita. L analisi svolta da  in merito a questa tematica, ci fa capire quanto sia in realtà complesso e delicato questo aspetto: 5\n14 Il confine tra ciò che è normale e ciò che è anomalo è spesso impreciso: un osservazione che sembra essere normale ma si trova al confine della regione di normalità può essere in realtà anomala. Se il comportamento di un sistema monitorato ritenuto normale, cambia, il modello sottostante utilizzato deve essere aggiornato. Se questa operazione non viene svolta, attacchi sofisticati potrebbero eludere i detectors che accetterebbero il traffico anomalo come se fosse traffico normale. La definizione di anomalia cambia a seconda dei domini applicativi. Ad esempio, nel campo medico una piccola variazione del COV potrebbe essere sintomo di un anomalia, mentre in altri contesti una piccola variazione potrebbe non destare sospetti. Spesso i dati contengono rumore che tende a somigliare ad un anomalia; per questo motivo è difficile distinguerle e rimuoverle. Figura 1.2.1: Esempio di anomalia Il dataset riportato in Figura mostra due aree contenenti dati definiti normali, denominate rispettivamente S 1 ed S 2. Come si può notare la maggior parte dei dati presenta un comportamento normale. I punti in rosso possono essere definiti anomali o outliers proprio perchè sono significaticamente distanti dalle aree di interesse. Definito cosa per noi è normale, possiamo distinguere tre tipologie di attività che è possibile svolgere all interno di una rete di calcolatori: Attività legittime conformi al modello di normalità Attività malevola 6\n15 Attività sospette Una attività legittima è una qualsiasi attività che non produce danni a sistemi o persone. L attività legittima può però diventare sospetta se il traffico che viene generato da una applicazione è eccessivo; è necessario che tali attività vengano notate e monitorate dagli amministratori di rete. Ad esempio, un enorme numero di utenti legittimi che effettua richieste verso un server in un arco temporale molto piccolo, è da considerarsi un attività sospetta. Spesso può capitare che attività legittime abbiano effetti negativi nella rete o sui dispositivi, ad esempio: Flash Crowd: il fenomeno prende luogo quando un elevato numero di host crea connessioni verso un server sovraccaricandolo inintenzionalmente. Può capitare quando una mole di utenti spropositata cerca di scaricare da un sito web uno stesso file allo stesso istante temporale. La conseguenza è il crash del sito web. Le attività di questo tipo sono anche dette dirompenti. Dispositivi di rete mal configurati possono creare situazioni ambigue. Tali problemi devono essere risolti quanto più velocemente possibile dagli amministratori di rete, in quanto il traffico proveniente da dispositivi mal configurati o malfunzionanti potrebbe comportare problemi alle reti connesse da tali dispositivi, propagando il fenomeno di malfunzionamento generale. Ad esempio, un router potrebbe generare un elevato numero di tabelle di routing verso altri dispositivi di rete consumandone la memoria e rendendoli inaccessibili. Un attività malevola, invece, è un azione effettuata da un attaccante o da una macchina compromessa (zombie). Questi tipi di attività hanno lo scopo di acquisire, distruggere, modificare dati sensibili o accedere a una rete privata aziendale senza permessi, con il solo scopo di fare danni. Tipicamente un anomalia è legata ad un attività malevola. Nella sottosezione seguente analizzeremo i diversi tipi di anomalie che è possibile riscontrare nel traffico di rete. Come riportato in , le anomalie possono essere suddivise in tre categorie: Point anomalies: singole istanze separate dal resto dei dati. Il più semplice tipo di anomalia che è possibile riscontrare. Contextual anomalies: istanze del dato che sono etichettate come anomale solo in un determinato contesto, mentre in un altro potrebbero anche non essere considerate anomale. I dati di questa categoria hanno due attributi: comportamentali e di contesto. Gli attributi comportamentali denotano caratteristiche del dato che 7\n16 non sono legate ad un contesto preciso, mentre gli attributi di contesto spieagano le relazioni che sussitono tra i dati in quel contesto. In Figura è mostrato un esempio di questo tipo di anomalia: un calo delle temperature nei mesi invernali (Dicembre ad esempio) è da considerarsi normale, mentre un brusco calo delle temperature nei mesi estivi come Giugno è anomalo. Collective anomalies: un intero sottoinsieme del dataset di partenza è distaccato dalla regione di normalità e considerato, per questo motivo, anomalo. Se analizziamo l onda periodica mostrata in figura 1.2.2, la regione segnalata è definita anomala perchè lo stesso valore basso si presenta per un tempo abbastanza lungo da considerarsi anormale, rispetto al comportamento periodico classico. Se il valore fosse stato basso per un breve intervallo temporale, non sarebbe stato considerato anomalo. Sia le point anomalies che le collective anomalies possono essere trasformate in anomalie di contesto. Figura 1.2.2: Tipi di anomalie Attività anomale nelle reti Come descritto in , esistono due macro categorie di anomalie di rete: Anomalie legate alla performance Anomalie legate alla sicurezza Per quanto riguarda le anomalie del primo tipo, esse vengono riscontrate a causa di malfunzionamenti dovuti a dispositivi di rete mal configurati (router o switch). 8\n17 Le anomalie legate alla sicurezza, invece, vengono riscontrate a causa di attività malevole o attività che deviano dal normale funzionamento della rete, come ad esempio un utente malintenzionato che inonda la rete con traffico non necessario, al solo scopo di saturare la banda così che un utente legittimo non è in grado di navigare o ricevere un corretto servizio. Nel corso della tesi, focalizzeremo l attenzione alle anomalie legate alla sicurezza. Sono riportate di seguito le principali attività malevole legate alla sicurezza. Possiamo suddividerle in due famiglie. DoS/DDoS e Probe Attacks DoS/DDoS e simili: DoS/DDoS: un attacco DoS è un azione malevola volta a rendere non più disponibile una macchina (server) agli utenti che ne richiedono un servizio. Tipicamente è un interruzione temporanea di un servizio. Il più comune attacco DoS è quello del flooding, che consiste nell inondare la vittima con un numero elevato di richieste. Il sovraccarico prodotto rende il server inutilizzabile o comunque molto lento a rispondere a richieste provenienti da un traffico legittimo. Il DDoS ha lo stesso scopo di un DoS ma coinvolge un gruppo di attaccanti per aumentare la potenza di attacco del DoS. E un attacco coordinato, che viene effettuato utilizzando un elevato numero di host compromessi. In uno stadio iniziale, l attaccante identifica le vulnerabilità di alcuni host, in una o più reti (denominate botnet), con lo scopo di installare dei malware e per controllarle da postazioni remote. Successivamente, l attaccante prende possesso degli host compromessi per inoltrare pacchetti malevoli alla/alle macchina/macchine target, le quali sono situate tipicamente al di fuori della rete dove si trovano gli host infettati (detti anche zombies). Se l attaccante riesce ad infettare un elevato numero di host, una rete o un web server possono essere distrutti in poco tempo. 9\n18 Figura 1.2.3: Attacco DDoS TCP SYN flood: fa parte della famiglia dei classici attacchi DoS che sfruttano il three-way handshake del protocollo TCP. Lo scopo di un attacco SYN flood è quello di occupare la memoria di un host vittima inviando brutalmente un eccessivo numero di richieste TCP SYN con un idirizzo ip sorgente ottenuto tramite la tecnica dello spoofing, che consiste nel creare un pacchetto IP falsificando l indirizzo sorgente del mittente. Modificando il campo Source Address si può far credere che un pacchetto IP sia stato trasmesso da una macchina host diversa da quella dell attaccante. La vittima risponde con un pacchetto SYN-ACK, ma non ottiene mai l ACK finale in risposta perchè l indirizzo sorgente sa di non aver inviato un SYN e quindi la connessione rimarrà aperta a vuoto. A causa di questo incompleto three-way handshake, la memoria della vittima tende a diventare satura, soprattutto se l attaccante continua ad inviare numerosi pacchetti SYN, fino a quando il target non sarà più in grado di accettare connessioni per un determinato periodo di tempo. L utente che vorrebbe leggittimamente connettersi al server non riesce a farlo, a causa di un rifiuto da parte del server che rifiuta di aprire una nuova connessione, relizzando di fatto un attacco di denial of service. Figura 1.2.4: TCP SYN flood 10\n19 ICMP flood: attacco molto simile al SYN flood. Avviene quando un attaccante sovraccarica la vittima con un elevato numero di richieste ICMP (echo request) sfruttando la tecnica dello spoofing Probe Attacks: Tipicamente gli attacchi di questa tipologia mirano ad acquisire informazioni sul target. Sono portati avanti prima di effettuare un pericoloso e potente attacco definitivo come il DoS. E uno step preliminare fondamentale, che viene effettuato nella fase di scansione della rete in cerca di una potenziale vittima. L identificazione di un pattern anomalo che può essere ricondotto ad un attività di scanning è determinato dal target scelto, che può essere o una singola macchina o diversi hosts. Il primo caso corrisponde ad un port-scan, mentre il secondo caso corrisponde ad un net-scan. Port Scan: utilizzato per scoprire servizi vulnerabili forniti da un host. Vengono scansionate tutte le porte di un ridotto insieme di host, alla ricerca di una aperta così da poter compromettere il target. L attaccante può capire se l host target consente l accesso su una particolare porta aperta al traffico. Network Scan: non viene più scansionato un range di porte bensì una rete, con lo scopo di trovare host vivi che stanno eseguendo uno specifico servizio. Le sonde sono trasmesse verso un elevato numero di host su un insieme ridotto di porti. Se un attaccante vuole trovare un web server in una rete, invierà pacchetti al porto 80 (HTTP) di tutti gli host in quella rete. Gli host che rispondono con un messaggio di accettazione sono tipicamente dei web server. Si vuole dunque identificare una rete o identificare uno specifico servizio in esecuzione o la versione di un protocollo. Un altra tecnica di attacco riguarda gli Host Break-In Attack: un attaccante cerca di entrare nel sistema per ottenere l accesso o usarlo in modo non autorizzato da remoto. Il più comune metodo di intrusione è quello di cercare una falla nel sistema, tipicamente all interno di server eseguiti sulla macchina target. Analizzando il database delle vulnerabilità , è possibile comprendere quanto siano frequenti le vulnerabilità nei sistemi che usano le reti. 11\n20 1.3 Anomaly Detection Algorithm: difficoltà di progettazione Un sistema per il rilevamento delle anomalie può essere considerato efficace se e soltanto se l alert che genera è istantaneo, accurato e fornisce utili informazioni su come agire in caso di comportamenti che si discostano dal modello di normalità. Un anomaly detector, solitamente è in grado di rilevare anomalie e non attacchi definiti da regole e pattern noti apriori. Per questo motivo, tali sistemi non sono in grado di fornire spiegazioni dettagliate sul tipo di anomalia riscontrato e quindi agire di conseguenza con azioni repentine. E strettamente necessario un intervento manuale di un esperto se si ha a che fare con delle minacce potenziali o semplicemente per interpretare gli alert forniti. Esistono molti lavori di ricerca che ruotano intorno a questo argomento. Come spiegato in [6,7,8,9,10], la maggior parte dei lavori esistenti è volto ad individuare attacchi identificando per prima cosa le anomalie. Un altro ramo di ricerca propone un metodo che consiste nel distinguere anomalie leggittime, da anomalie di attacco. Bensì esistano molte tecniche differenti per costruire un engine che possa rilevare anomalie nel traffico di rete, un aspetto comune a tutti i NIDS è sicuramente il preprocessing del dato. Al fine di trovare attacchi ben noti o comportamenti inusuali, i più moderni sistemi di rilevazione di anomalie nel traffico di rete ispezionano il contenuto di ogni pacchetto (payload). Il problema dell ispezione dei pacchetti è che spesso diviene molto complicato da mettere in pratica e in alcuni casi, impossibile da eseguire a velocità che si avvicinano all unità di misura del gigabit per secondo. Un altro aspetto che rende difficile l implementazione di un algoritmo di detection payload-based è che spesso abbiamo a che fare con traffico opaco che è compresso o cifrato. Ciò richiede prestazioni elevate alla CPU, inoltre si è dimostrato che l 89% di pacchetti TCP è traffico opaco. E per questo motivo che è importante trovare alternative valide al metodo dell ispezione dei pacchetti. Una delle opzioni che attrae maggiormente i ricercatori è la tecnica flow-based. L argomento verrà ripreso nel Capitolo 4. Nella sezione (1.2) si è parlato del concetto generale di anomalia e come possono essere classificate le attività di rete svolte dagli utenti. Entrando nell ottica di un sistema di detection, classificare il traffico di rete come normale o anomalo non è sufficiente. E necessario introdurre altri due nuovi parametri: malevolo benigno 12\n21 Esistono dunque quattro possibili condizioni di predizione in merito a delle possibili attività di rete riscontrate: Tipo di Classificazione Benigno ma anomalo Benigno e non anomalo Malevolo ma non anomalo Malevolo e anomalo Difficoltà nel rivelarla Alta Bassa Alta Bassa Tabella 1.1: Possibili combinazioni di eventi di predizione e classificazione Attacchi silenziosi e duraturi possono confondere un detector che pian piano accetterà un comportamento malizioso come uno normale. La figura seguente mostra un quadro completo delle attività di rete e come possono essere classificate: Figura 1.3.1: Tipologie di attività di rete Un attività dirompente tende ad avere un comportamento differente da quello che possiamo definire normale. Per questo motivo un attività di questo tipo, anche se legittima e che non nasce per recare danni è considerata comunque anomala. (ad esempio il Flash Crowd - sezione 1.2 ) Velocità e accuratezza Una delle sfide di maggiore interesse riguarda la velocità con cui viene rilevato un comportamento anomalo da parte di un sistema di detection. E uno dei più importanti requisiti che devono essere soddisfatti per effettuare una rilevazione real-time con un elevata accuratezza. Molti attacchi sono sferrati componendo differenti tipi di payload e trasmessi simultaneamente. Ad esempio, con un attività di scanning ( ) vengono generati una sequenza di pacchetti sonda verso un insieme di destinazioni diverse 13\n22 o porti differenti. Come già accennato precedentemente, la fase di scanning è preliminare ad un attacco e riuscire ad invididuare velocemente un port-scan o un net-scan permetterebbe agli amministratori di rete di bloccare una scansione prima dell effettivo attacco. Appena viene individuato un host vulnerabile durante la fase di scanning, l attaccante trasmette immediatamente il payload di attacco verso il target individuato. In questo contesto è necessario settare in modo appropriato le soglie di tolleranza utili per individuare un anomalia: un corretto settaggio delle tresholds determina la bontà dell algoritmo di detection e dunque una migliore accuratezza nei risultati. Esempio Immaginiamo che uno scanner trasmette delle sonde verso 30 macchine differenti riuscendo a trovarne una vulnerabile. L algoritmo di detection ideato per rivelare dei net-scan, ha una soglia sul numero di connessioni impostata ad un valore maggiore di 20. Questo vuol dire che se un host sorgente ha un numero di flussi uscenti che supera il valore 20, l algoritmo solleva un alert. Nel nostro caso l attacco sarebbe stato bloccato in tempo. Se l algoritmo avesse una soglia pari a 35 ad esempio, l attacco non verrebbe notato. Maggiore è il numero di osservazioni necessario a settare la soglia in modo corretto, maggiore è il traffico malevolo che viene lasciato passare. Esiste un trade-off tra l accuratezza e la velocità con cui viene effettuata una detection, che complica il progetto di un algoritmo di questo tipo Evadere la detection Un attaccante, studiando in dettaglio come è stato progettato un algoritmo di detection, può forgiare ad arte un pacchetto o modificare il comportamento in modo da non farsi notare dal sistema. E necessario quindi che un algoritmo di detection sia resistente a possibili evasioni. Uno dei modi per evitare l insorgere di questo fenomeno è quello di definire delle rigide regole alle attività permesse così che solo un tipo di traffico ben definito può passare inosservato e risultare normale. Anche in questo modo però un attaccante potebbe trovare il modo di alterare il pattern di traffico Falsi allarmi Un falso allarme è un evento che si presenta quando un algoritmo di anomaly detection classifica incorrettamente un attività benigna come una malevola e viceversa generando dei falsi positivi. Esempio Quando un attaccante effettua lo spoofing di un indirizzo IP, il sistema di detection potrebbe erroneamente marcare come malevolo un host innocente. 14\n23 Un altra causa di falso allarme potrebbe essere dovuta alle policy di sicurezza impostate da un applicazione. Ad esempio nell ambito del p2p, i client scansionano i peer vicini per trovare il miglior peer da cui poter scaricare un file. Questa attività di scanning innocua può rientrare tra i pattern anomali per identificare la propagazione di worm. Identificare un client p2p come uno scanner può essere una detecition leggittima o un falso allarme Scalabilità Il traffico di rete che si intende analizzare determina la quantità di dati che un algoritmo di detection deve analizzare ed elaborare in tempo reale o offline. Come già accennato precedentemente, essendo la velocità una delle caratteristiche fondamentali che deve avere un algoritmo di detection, la scalabilità sarà una delle proprietà su cui ci soffermeremo nel corso di questa tesi. Lo studio portato avanti nel survey , analizza i fattori che possono impattare il carico della CPU del sistema e l uso della memoria. Quelli di maggior impatto sono il tipo di analisi, il tasso con cui arrivano i pacchetti al sistema di detection e il numero di connessioni che devono essere memorizzate. Sembrerebbe quindi indispensabile avere una gestione efficente delle risorse in modo da mantenere il sistema di detection operativo al crescere del volume di traffico che deve analizzare. 1.4 Tecniche di detection Nel corso degli anni sono state svilippate numerose tecniche volte a scoprire anomalie nelle reti. Alla base di ogni tecnica di anomaly detection vi è la natura del dato che si deve elaborare. Ogni istanza può essere descritta usando un insieme di attributi o features i quali possono essere binari, categorici o continui. Un istanza può avere un solo attributo e quindi denominata univariata o più attributi, dunque multivariata. E la natura di un attributo a determinare che tipo di tecnica può essere usata. Di seguito se ne riportano solo alcuni esempi: Approccio Statistico: quando viene sviluppato un algoritmo di detection di tipo statistico vuol dire che siamo interessati ad analizzare proprietà statistiche del traffico come ad esempio la media o la dimensione dei flussi, il rapporto tra flussi entranti e uscenti o la distribuzione degli indirizzi IP. Per scoprire cosa è anomalo, vengono osservate certe proprietà statistiche e se viene osservato un cambiamento delle stesse si può pensare che tale cambiamento sia causato da 15\n24 un anomalia. Al fine di comprendere se è avvenuta una variazione nei punti di interesse, possono essere utilizzate molte tecniche, tra cui i modelli regressivi o la Principal Component Analysis (PCA). I metodi statistici si basano sull assunzione che il comportamento normale avviene con un elevata probabilità mentre quello anomalo ha una bassa probabilità di accadere. Data Mining-based Methods: processo computazionale mediante il quale è possibile scoprire patterns all interno di un elevato numero di dati collezionati. Per rendere tale processo più rapido e automatizzato spesso vengono utilizzate tecniche di machine learning, una metodologia legata principalmente ad attributi di connessione come ad esempio porto sorgente, porto destinazione, indirizzo IP sorgente, indirizzo IP destinazione, protocollo e TCP flag. Consocendoli è possibile costruire un classificatore. E spesso richiesto un dataset pre-etichettato. Time Frequecy Analysis-based (TFA): Spesso utilizzato insieme all approccio statistico. La differenza è che un TFA analizza le informazioni nel dominio della frequenza invece che nel dominio del tempo come avviene con l approccio statistico. Tale metodo per prima cosa analizza un parametro statistico del traffico di rete, come ad esempio il tasso dei pacchetti. La TFA trasforma il parametro portandolo nel dominio della frequenza e successivamente cerca di rivelare eventuali anomalie. Quando viene rilevato qualcosa di strano nei pattern di traffico analizzati, viene alzato un alert (ad esempio, se si eccede uan soglia pre-impostata). Tale metodo, come anche quello statistico, non forniscono informazioni chiave circa le anomalie riscontrate che possono essere utili per applicare contromisure da parte degli amministratori di rete. Rule Based: un anomaly detector impara regole che descrivono il normale comportamento del sistema. Un evento che non rientra nelle regole così definite è da considerarsi anomalo. Il primo passo di questa metodologia consiste nell applicare un algoritmo di rule learning. Machine Learning: con il termine machine learning si intende l abilità che ha un programma di migliorare gradualmente le performance di un certo numero di attività che deve svolgere. Esistono numerosi metodi come ad esempio K-NN clustering, Support Vector Machine (SVM) e reti neurali. Approccio Ibrido: diventa sempre più comune combinare i diversi approcci in un singolo modello. L idea è qella di combinare i punti di forza dei differenti approcci descritti per massimizzare l accuratezza e minimizzare i falsi positivi. 16\n25 La figura seguente riassume quanto detto : Figura 1.4.1: Quadro generale dei metodi di detection Dataset Spesso è possibile avere nel dataset delle etichette, dette anche label, che permettono di comprendere se una determinata istanza è normale o anomala. Come descritto in , può essere molto costoso avere questo tipo di informazione. Tipicamente, avere un insieme etichettato di anomalie che riescono a coprire la maggior parte dei comportamenti anomali, è molto più difficile che avere le stesse etichette per catalogare un comportamento normale. In base all esistenza o meno di queste etichette, le tecniche dell anomaly detection possono essere catalogate in tre modi differenti: 1. Supervised: si assume che il dataset di partenza presenti delle istanze etichettate. Il processo di etichettamento può avvenire manualmente o tramite un tool automatizzato. Tale processo opera offline e utilizza la classificazione ottenuta per analizzare e classificare nuovo traffico. Sono previste tre tipologie di classi: normale, attacco e sconosciuto. Tale metodo ha un enorme vantaggio: la classificazione avviene solo una volta. Inoltre, è possibile avere una precisione abbastanza elevata producendo pochi falsi allarmi nel caso in cui i dati collezionati fanno parte della stessa rete, questo perchè esiste una conoscenza di traffico benigno grazie alle etichette, che aiuta a distinguere le attività benigne da quelle 17\n26 malevole. Lo svantaggio di tale metodologia è che i risultati e le performance dipendono strettamente dalla qualità del processo di etichettatura. Inoltre, questo metodo potrebbe non considerare nuove anomalie ancora sconosciute che hanno comportamenti differenti dalle anomalie già note. Un tipico approccio è quello di costruire un modello predittivo contenente la descrizione di ciò che possiamo ritenere normale o anomalo. I dati analizzati sono poi confrontati con questi modelli e classificati adeguatamente. 2. Semi-Supervised: Anche questo metodo prevede l utilizzo di un dataset preetichettato per la fase di addestramento del classificatore. E prevista solo una classe, definita normale. Dal momento che non è richiesta un etichetta per la classe che identifica un anomalia, è una metodologia che presenta una migliore applicabilità rispetto al metodo supervised. Un ulteriore vantaggio è che riesce a classificare nuove anomalie ancora sconosciute, questo perchè la detection delle anomalie avviene senza avere nessuna idea circa le caratteristiche delle anomalie in sè. Si lavora solo con dati ritenuti normali e successivamente viene creato un modello di comportamento anomalo. 3. Unsupervised: tale metodologia fu proposta per cercare di risolvere il problema di avere un dataset pre-etichettato, che non è facile da ottenere poichè raramente disponibile. Proprio per questo motivo, tecniche di questo tipo sono tra le più utilizzate. Le tecniche che rientrano in questa categoria assumono che il comportamento definito normale è quello più frequente rispetto a quello anomalo. Se tale assunzione non è più vera, allora tali tecniche non garantiscono una prestazione ottimale poichè scateneranno molti falsi allarmi, dal momento che non si ha idea di quale sia il traffico benigno, vista l assenza di un traffico pre-etichettato Metriche qualitative di performance Un buon algoritmo di detection deve presentare una serie di metriche qualitative, che dovrebbero essere rispettate al fine di garantire un certo livello di qualità nell analisi che effettua. In questa sezione vengono riportate alcune proprietà che ogni network anomaly detector deve avere per essere considerato di successo : 18\n27 Figura 1.4.2: Rappresentazione grafica di una confusion-matrix Se con il termine positivo ci riferiamo ad un comportamento anomalo e con il termine negativo ad un comportamento normale, possiamo individuare le seguenti combinazioni: VeroNegativo: evento classificato come normale e veramente lo è. VeroPositivo: evento classificato come anomalo e veramente lo è. FalsoNegativo: evento classificato come normale ma non lo è (errore del II tipo). FalsoPositivo: evento classificato come anomalo ma non lo è (erorre del I tipo). Definiti i valori della matrice di confusione è possibile specificare le metriche qualitative: 1. Detection Rate: Una delle proprietà più importanti, riguarda l abilità di rilevare correttamente tutte le anomalie che è possibile riscontrare nella rete. Per questo motivo, il tasso con cui un detector riscontra le anomalie deve essere elevato. Il termine detection rate è sinonimo di vero positivo (anche detto recall o sensitivity). In una situazione ideale ci si aspetta che un detector sia in grado di discriminare perfettamente due popolazioni mutuamente esclusive, ad esempio una proveniente dal modello di normalità e una che riguarda eventi anomali. In un caso reale, invece, potrebbe capitare che due popolazioni si sovrappongano in parte o totalmente e la detection identificherà come anomali alcuni soggetti non anomali (falsi positivi) e come normali alcuni soggetti anomali (falsi negativi). Il concetto verrà ripreso nel Capitolo 5. Matematicamente il detection rate o true positive rate è dato dal rapporto tra il numero di anomalie correttamente riscontrate e il numero totale delle anomalie: VeriPositivi VeriPositivi + FalsiNegativi (1.4.1) 2. False Alarm Rate: un falso allarme può essere definito anche con il termine di falso positivo, ovvero un evento che incorrettamente viene classificato anomalo 19\n28 da un network anomaly detector. I falsi positivi non sono elementi da prendere in considerazione e si deve cercare di limitare la loro incombenza. Un anomaly detector idealmente deve produrre un numero di falsi positivi tendente a 0 (pochi falsi allarmi). Matematicamente, il false alarm rate o false positive rate è definito come il rapporto tra le attività non anomale classificate erroneamente come anomale e il numero totale delle attività normali: FalsiPositivi FalsiPositivi +VeriNegativi (1.4.2) 3. Velocità: un altra proprietà rilevante da tenere in considerazione durante la fase di progetto di un algoritmo di detection è la velocità, intesa come tempo di calcolo, come già è stato accennato in Soffermandoci maggiormente sul concetto di velocità, possiamo sicuramente affermare che un algoritmo di detection lavora con i big data, ovvero una raccolta di dati così estesa in termini di volume, velocità e varietà da richiedere tecnologie e metodi analitici specifici per l estrazione del valore. Questo aspetto sarà approfondito nel Capitolo Flessibilità: un buon detector deve avere la capacità di poter essere eseguito in ogni ambiente senza troppe difficoltà. In questo contesto con flessibilità si intende la capacità di un algoritmo di poter essere riconfigurato con il minor numero possibile di parametri. 5. Output fornito: l output fornito da un algoritmo di detection deve poter essere utilizzato dagli amministratori di rete per prendere delle contromisure, come ad esempio bloccare o far calare il traffico anomalo. Le contromisure spesso richiedono importanti informazioni come ad esempio l indirizzo IP, la porta e il tipo di protocollo. Per usufruire delle potenzialità del firewall per bloccare traffico malevolo, un amministratore di rete necessita l indirizzo IP dell attaccante e questa informazione può ricavarla dai risultati dell algoritmo di detection. Molti tra i metodi descritti, come ad esempio quello statistico e il TFA-based, spesso non rispettano questo attributo di qualità. Le metriche che tipicamente vengono considerate per valutare la performance di un metodo di anomaly detection sono il detection rate e il false alarm rate menziontati precedentemente. Esistono due metriche addizionali, denominate true negative rate e false negative rate, definite rispettivamente: VeriNegativi VeriNegativi + FalsiPositivi (1.4.3) 20\n29 FalsiNegativi FalsiNegativi +VeriPositivi (1.4.4) Il true negative rate indica con quale probabilità eventi normali sono considerati tali. Il false negative rate indica con quale probabilità eventi anomali non sono considerati tali. I concetti saranno ripresi nel Capitolo 5. Riassumendo: Metrica Denominazione Formula True Positive Rate detection rate,recall,sensitivity V P V P+FN False Positive Rate false alarm rate FP FP+V N True Negative Rate specificity V N V N+FP False Negative Rate miss rate FN FN+V P Positive Predictive Value precision V P V P+FP Tabella 1.2: Metriche di performance 1.5 Oltre le reti Nelle sezioni precedenti sono state descritte le metodologie e gli approcci che sono alla base di un algoritmo di anomaly detection network-based, applicato al traffico di rete. Bensì rilevare anomalie nei flussi di rete sia una sfida molto complessa e in continua evoluzione (oltre ad essere oggetto di studio di questa tesi), non è l unico campo in cui possono essere rilevate. Ad esempio, con il termine intrusion ci si riferisce anche ad una attività malevola che interessa un computer. In questo caso si tratta di anomaly detection host-based. Un intrusione può essere considerata un anomalia, dal momento in cui ci si discosta dalle attività classica svolte da un sistema operativo. I sistemi hostbased tendono a monitorare le system call di un sistema oeprativo per capire se il modo di eseguire determinati programmi risulta essere diverso dal solito. Le intrusioni sono delle anomalie di tipo collettivo (1.2.1); si generano delle sottosequenze anomale di eventi che si traducono in programmi malevoli, accessi non autorizzati e violazione di policy di sicurezza. Le tecniche applicate in questo dominio devono essere progettate per avere a che fare con dati di natura puramente sequenziale, generati dalle system call. Con il termine fraud detection si itnende invece una tecnica che consiste nel rilevare attività criminali in domini commerciali e organizzativi come ad esempio banche, compagnie di carte di credito, compagnie telefoniche ecc. L utente malevolo potrebbe essere in realtà un cliente ordinario dell organizzazione o potrebbe fingersi un cliente. La frode si presenta quando questi utenti consumano le risorse fornite dall organizzazione in modo non autorizzato. In questo ambito ci possono essere conseguenze 21\n30 economiche disastrose per l azienda, le quali, per prevenire il più possibile i danni, spendono molto in algoritmi per il rilevamento di frodi. Una delle tecniche utilizzate è cercare di monitorare il profilo di ciascun cliente per rilevare eventuali scostamenti dal comportamento normale. Nel dominio delle frodi, le tecniche dell anomaly detection sono spesso applicate per rilevare un uso fraudolento delle carte di credito. In questo caso, le frodi tipicamente compaiono durante le transazioni bancarie e si parla dunque di point anomalies e corrispondono a pagamenti di alto calibro o pagamenti molto frequenti. Sono usate tecniche di clustering. Esistono numerosi altri domini dove può essere applicata l anomaly detection, come ad esempio nel ricnonscimento vocale, nel comportamento dei robot, rilevare minacce in web applications, o ancora, anomalie nei dati biologici, in dati astronomici o in distrurbi dell ecosistema.  22\n31 Capitolo 2 Dataset Prima di entrare nel merito dell algoritmo di detection proposto nell ambito di questa tesi, è necessario chiarire alcuni aspetti basilari, tra cui il dataset utilizzato per testarne l effettivo funzionamento. Gli approcci più comuni per ottenere un maggiore controllo sulle anomalie, prevedono l utilizzo delle cosiddette anomalie sintetiche. Con un metodo del genere infatti, risulterebbe molto più semplice verificare se un packet rate o un certo numero di indirizzi IP, si discostano dal modello di comportamento normale previsto. Sfortunatamente, valutare un detector con il metodo delle anomalie simulate non è un approccio ottimale, poichè viene identificato solo un numero ristretto di anomalie e non è una misura sufficiente per la valutazione di una performance. Nel nostro caso, non saranno usate anomalie sintetiche bensì tracce di traffico provenienti dal mondo reale. Il vantaggio di questo approccio, si può notare principalmente nell ambito di ricerca: con un algoritmo di detection che lavora su tracce di traffico reali, si riesce a dimostrare che il metodo sviluppato è in grado di rilevare anomalie riscontrabili nel mondo reale. Con l avvento di Internet negli anni 60 e il suo enorme sviluppo negli anni a seguire, è nata l esigenza, soprattutto in ambito militare, di costruire strumenti in grado di rilevare minacce e attacchi informatici. A questo scopo, sono stati sviluppati ambienti simulati e dataset che consentono di testare e sviluppare algoritmi per la detection. Di seguito sono riportati gli storici più importanti : DARPA 1998/1999 : il progetto DARPA era uno dei più utilizzati dataset per la valutazione delle performance di NIDs. Di uso prettamente militare, forniva traffico di rete simulato raccolto in cinque settimane e collezionato tra la rete US Air Force-based (rete LAN militare) e Internet. La rete veniva attaccata di proposito in un ambiente simulato. Le tracce di traffico erano memorizzate in formato.pcap e contenevano per lo più dati provenienti dai log del protocollo 23\n32 TCP.La caratteristica principale di tale dataset era che il traffico di rete della prima e terza settimana non presentava anomalie, mentre il traffico della seconda, quarta e quinta settimana conteneva sia traffico normale che anomalo simulato. Le anomalie simulate consistevano in 177 istanze con 59 tipi di attacco differente come ad esempio i DoS o i probe attacks, già discussi nel capitolo 1. Il progetto DARPA è stato considerato per molti anni la gold standard per la valutazione di algoritmi di intrusion detection ed è ancora oggi in continuo sviluppo e aggiornamento. KDD Cup 1999: il dataset in questione forniva un elevato numero di intrusioni simulate, ancora una volta per scopi militari. Non si parla di tracce di traffico ma di dati processati contenenti circa 4 milioni di record ognuno dei quali è un vettore con 41 proprietà estratte da un record di connessione e ogni record era etichettato come normale o con un particolare tipo di attacco. Utilizzato principalmente in ambito di ricerca, ma molto criticato poichè la distribuzione degli attacchi non era ritenuta sufficientemente realistica. Altri dataset più moderni, ma che citeremo solo, sono ad esempio: CAIDA, Abilene, ISOT e TD-SIM. 2.1 MAWI dataset Il dataset fornito da MAWI è quello scelto per valutare le performance dell algoritmo di detection proposto nell ambito di questa trattazione. MAWI fornisce un dataset di tracce di traffico provenienti da una rete backbone di pubblico accesso . Il dataset è gestito dal progetto WIDE e le tracce di traffico collezionate sono ottenute da diversi punti di interesse posizionati in luoghi geografici anche molto distanti tra loro. Il payload dei pacchetti è omesso e gli indirizzi IP sono opportunamente anonimizzati. Le tracce di traffico, hanno caratteristiche che le rendono tutte diverse dal punto di vista della dimensione e del volume di dati raccolto; questo dipende da quale punto di interesse avviene la cattura. In particolare è necessario distinguere diversi punti di interesse, denominati samplepoint, alcuni dei quali non più aggiornati e divenuti obsoleti. Di seguito se ne elencano le diverse tipologie: samplepoint-a: operativo dal 1999 fino al 2001, contiene oramai informazioni datate e obsolete. Operava su una linea del pacifico e catturava tracce della durata di un ora ciascuna. 24\n33 samplepoint-b: catturava tracce giornaliere su una linea del Pacifico differente da quella del samplepoint-a. Il 1 Luglio 2006 fu terminato e rimpiazzato dal samplepoint- F. samplepoint-c/d: forniscono tracce di traffico IPv6 su un collegamento IPv6 connesso ad un 6Bone e ad un WIDE-6Bone. Il dataset non è più aggiornato dal 2009 per entrambi. samplepoint-e: operativo da Dicembre 2001 fino al 2009, catturava tracce di traffico su una linea US-Japan (OC-3). samplepoint-f: punto di interesse attualmente in esercizio dal Fornisce tracce di traffico della durata di 15 minuti prelevate da una rete di backbone transpacifica tra America e Giappone, ogni giorno dell anno, in particolare dalle 14:00 alle 14:15. La capcità del link backbone su cui opera è di 1Gbps. Le tracce di traffico provenienti da questo punto di interesse sono le più utilizzate dai ricercatori che vogliono testare i metodi di anomaly detection sviluppati, questo perchè le tracce di traffico fornite, sono le più aggiornate che si possono avere e rappresentano dati di traffico reale. Per questo motivo, per valutare le performance dell algoritmo di detection che andremo ad analizzare nei capitoli successivi, utilizzeremo le tracce di traffico catturate dal samplepoint-f. Le tracce sono memorizzate in formato.dump. Il vantaggio principale nell utilizzare l archivio gestito da MAWI, è che è aggiornato quotidianamente e contiene traffico monitorato dal 2006 fino ai giorni nostri. Inizialmente il dataset fornito dal progetto MAWI non era etichettato. Come in tutti i casi di studio, il problema di fondo nel testare le performance di un anomaly detection system, è rappresentato dal fatto che è di fondamentale importanza avere una precisa conoscenza sulle anomalie esistenti nel traffico catturato e su cui si sta operando. A tale scopo è nato il progetto MawiLab, un database molto utile ai ricercatori e che fornisce delle label per le tracce di traffico catturate dal samplepoint-b e dal samplepoint-f. Si è già parlato nel Capitolo 1, sezione 1.4.1, dell importanza di avere nel dataset delle label che permettano di comprendere se una determinata istanza è normale oppure anomala. Il dataset fornito da MAWI viene dunque etichettato dal progetto MawiLab che può essere visto come una gold-standard (4.2.1) per le analisi successive che andremo ad effettuare, riguardanti lo studio dei risultati forniti dall algoritmo sviluppato. 25\n34 2.2 Progetto MawiLab Idelamente, il corretto funzionamento di un anomaly detector, dovrebbe essere valutato confrontando i risultati ottenuti con una ground-truth, utile a dimostrare o a confutare certe ipotesi e contenente informazioni sul traffico di rete reale. La ground-truth così definita dovrebbe essere pubblicamente disponibile per consentire a tutti i ricercatori di accedere alle stesse informazioni per poi comparare i risultati ottenuti. Inoltre, il dataset dovrebbe essere continuamente aggiornato in base all evoluzione del traffico di rete che viene catturato su Internet, includendo ad esempio traffico proveniente da nuove applicazioni emergenti. L obiettivo che si propone il progetto MawiLab  consiste nel trovare ed etichettare anomalie nel traffico catturato da MAWI e rendere tali informazioni disponibili a chiunque. Etichettare manualmente le anomalie in un dataset di così grandi dimensioni è sicuramente una sfida impraticabile; proprio per questo motivo MawiLab ha pensato di automatizzare il processo di etichettamento. Più nel dettaglio, la classificazione delle tracce fornita da MawiLab è ottenuta combinando quattro anomaly detectors (basati rispettivamente sulla trasformata di Hough, distribuzione Gamma, la divergenza di Kullback-Leibler e la Principal Component Analysis). La sinergia che si viene a creare tra i detectors che usano approcci di rilevazione differenti, consente di ottenere una maggiore accuratezza nel risultato finale. Inoltre, i risultati provenienti dai quattro detectors sono euristicamente combinati in modo da fornire una ground-truth da usare per successive analisi. Un problema che purtroppo emerge quando vengono usati quattro diversi tipi di detectors, è che i risultati forniti hanno una granularità di traffico differente e quindi sono difficilmente confrontabili. Il metodo ideato dal team del progetto MawiLab per etichettare il traffico di rete, può essere riassunto nei seguenti passi: 1. Diversi anomaly detectors analizzano il traffico e riportano gli alert riscontrati. 2. Vengono studiate le similarità tra gli alert sollevati, in particolare viene introdotto uno stimatore delle similarità che ne effettua un raggruppamento in base alle affinità. 3. Il combiner analizza i raggruppamenti effettuati nel passo precedente ed effettua una prima classificazione. Il combiner decide anche se un insieme di alert deve essere classificato come anomalo o può essere ignorato. 4. Le anomalie sono caratterizzate usando regole di associazione applicate sui risultati forniti dal combiner. E in questo stadio che avviene l etichettamento finale. 26\n35 Soffermandoci sull ultimo step, il processo di etichettamento avviene con 4 differenti labels: Anomalous: traffico considerato anomalo con alta probabilità e dovrebbe essere rilevato tale da qualsiasi efficente algoritmo di detection. Suspicious: traffico probabilmente anomalo ma non chiaramente identificato dai detectors utilizzati da MawiLab. Notice: tutto quel traffico che non è stato identificato come anomalo da Mawi- Lab ma è risultato comunque anomalo da almeno un detector utilizzato. Questo traffico non dovrebbe essere identificato anomalo da un algoritmo di detection. Non è stato classificato come benigno in quanto è stato sollevato un alert da uno dei detectors e di questo evento è utile tenerne traccia. Potrebbe trattarsi di attività legittime con comportamenti fuori dal normale. Di questa categoria fanno parte tipicamente gli alpha-flow, point-to-point, multipoint. Benign: tutto il traffico normale che non presenta comportamenti fuori dal comune. E importante inoltre tenere in conto la natura probabilistica della classificazione effettuata da MawiLab quando confronteremo i nostri risultati con quelli di MawiLab Report MawiLab E possibile studiare l analisi effettuata dai detector di MawiLab, tramite dei report generati dal sistema. Le anomalie (anomalous e suspicious) e il traffico classificato con notice (in un report apparte), sono riportati in un file con estensione.xml o.csv per ogni traccia e identificate con alcuni attributi. In particolare per il formato.xml abbiamo: AnomalyType: label di MawiLab assegnata all anomalia, può essere una delle tre riportate precedentemente. Value: Il valore contiene una stringa di informazioni seprate da virgola, in particolare alcune metriche di distanza risultanti dall algoritmo di classificazione riassunto precedentemente, un codice di tre cifre compreso tra 500 e 900. Se il valore di tale codice è inferiore a 500 vuol dire che il traffico anomalo sta usando porte sospette ben note (Netbios,smb, SSH attack) o contiene un numero spropositato di pacchetti con i flag TCP del tipo: SYN,RST o FIN. Se il valore è compreso tra 500 e 900, vuol dire che l anomalia è riscontrata su porti ben noti (FTP, HTTP, 27\n36 SSH). Infine se il codice ha un valore maggiore di 900, significa che l anomalia è riscontrata su porti sconosciuti. Un altro campo mostra quale detector e con quali parametri ha rilevato l anomalia. E un vettore di valori binari dove lo 0 indica che non sono stati riportati alert, 1 viceversa. Infine, nell ultimo campo vi è la tassonomia dell anomalia.. Slice: Contiene una serie di attributi, in particolare gli indirizzi IP sorgente e destinazione, porto destinazione e la durata dell attacco in secondi. Per quanto riguarda il formato.csv, ogni riga consite in un insieme di 4 tuple che descrivono le caratteristiche del traffico o informazioni aggiuntive come le euristiche e le tassonomie, in particolare: AnomalyID: identificativo dell anomalia riscontrata. Permette di indetificare le righe del file che si riferiscono alla stessa anomalia. srcip: indirizzo IP sorgente del traffico anomalo dstip: indirizzo destinazione del traffico anomalo. taxonomy: tassonomia dell anomalia riscontrata. heuristic: codice assegnato all anomalia usando lo stesso criterio visto per il file xml label: etichetta assegnata all anomalia. Può essere, anche in questo caso di tre tipi: anomalous, suspicious o notice. Le anomalie di rete sono estremamente diverse tra loro. Questo è dovuto al fatto che esistono molteplici comportamenti che possono essere considerati anormali. Questi comportamenti però, possono essere caratterizzati applicando un determinato criterio al traffico di rete. MawiLab propone una metodologia con cui classificare i comportamenti anomali per ottenere un insieme di tassonomie, da associare a comportamenti che non risultano essere conformi a determinate regole o signatures. L obiettivo è quello di caratterizzare completamente i comportamenti anomali. Nella sottosezione seguente viene descritto il processo di etichettamento e cosa si intende per tassonomia Tassonomie Dopo aver applicato una prima label che consente di classificare il traffico come anomalo, sospetto o notice, MawiLab propone una serie di tassonomie. Le tassonomie si concentrano sullo specifico tipo di anomalia, come ad esempio un DDoS, scan, o anomalie in generale. Non si riesce però ad avere una copertura completa di tutte 28\n37 le anomalie di rete esistenti. Lavori di ricerca portati avanti in questo ambito  hanno fatto passi avanti, riuscendo a ridurre il numero di anomalie classificate come unknown. La struttura delle tassonomie può essere definita come un albero, dove ogni nodo dell albero è etichettato. La figura seguente mostra una descrizione di alto livello della struttura ad albero: Figura 2.2.1: Albero delle tassonomie Come si può osservare, esistono due principali categorie di eventi: anomali e normali. Gli eventi anomali comprendono eventi che possono essere scatenati da un denial of service o da attività di scanning, mentre gli eventi normali includono i cosìdetti heavy hitter o alpha-flows, point-multipoint e altre tipologie di eventi come ad esempio tunnell, point-to-point flows, outages ecc. Alcuni eventi possono essere considerati legittimi o no a seconda del contesto: un attività di scanning può essere effettuata per un attività di ricerca o come fase preliminare di un attacco. Nel corso della tesi, gli scanner rilevati saranno classificati come anomali, utilizzando un approccio conservativo. MawiLab assegna una singola etichetta ad ogni evento. Per prima cosa tende ad assegnare un etichetta appartenente al sottoalbero la cui radice è etichettata come anomaly. Se non esiste nessuna corrispondenza, si ripete lo stesso procedimento nel sottoalbero la cui radice è etichettata con normal. Se ancora non viene trovata una corrispondenza, l evento è etichettato con unknown. Tale procedimento viene portato avanti utilizzando delle signatures gestite da MawiLab. Un evento può corrispondere a diverse signatures all interno di uno dei due sottoalberi: quando ciò avviene, viene scelta la corrispondenza più dettagliata, ovvero quella più lontana dalla radice. Questo consente all algoritmo di avere un accuratezza elevata nella scelta dell etichetta. La tabella seguente riassume l insieme di tassonomie fornite da MawiLab: 29\n38 Tipo di Anomalia/Normalità Unknown Other HTTP (Normale) Multi-Points (Normale) Alpha flow (Normale) IPv6 tunneling (Normale) Port scan Net scan ICMP Net scan UDP Net scan TCP DoS Tassonomia empty icmp_error,ttl_error,hostout alphlhttp, ptmphttp, mptphttp, ptmplahttp ptmp,mptp,mptmp alphfl, malphfl, salphfl, point_to_point, heavy_hitter ipv4gretun, ipv46tun (point-to-point traffic) posca, ptpposca ntscic, dntscic ntscudp, ptpposcaudp ntscack, ntscsyn, ntsctcp, ntscnull, ntscfin, dntscsyn DoS, distributed_dos, ptpdos, sptpdos, DDoS, rflat Tabella 2.1: Elenco delle tassonomie gestite dal progetto MawiLab Gli eventi ritenuti normali sono suddivisi in tre sotto classi : 1. Gli heavy hitters corrispondono al traffico point-to-point avente più di 1000 pacchetti, mentre lo small-volume point-to-point al traffico avente meno di 1000 pacchetti. 2. I point-multipoint rappresentano gli eventi legati al traffico tra server, in particolare il point to multipoint riguarda il traffico che parte da un server sorgente verso più destinazioni, mentre i multipoint to point descrivono il traffico che arriva ad un server destinazione e proveniente da più sorgenti. 3. Con la parola other, si intendono gli ICMP errors che possono distinguersi in: outages, expired time-to-live ecc. Infine, il traffico point-to-point è tipicamente quello dei tunnell (GRE o IPv4-IPv6) Signatures Ogni signature può essere composta da una o più regole che descrivono la natura del traffico di rete. Ad esempio, può essere utilizzato il numero di hosts sorgenti e il numero di hosts destinazione per caratterizzare un point-to-point distribuito o dei rapporti che misurano il tasso con cui determinati pacchetti entrano ed escono da una sorgente. La seguente figura mostra due esempi di signature che identificano un comportamento anomalo : 30\n39 Figura 2.2.2: Esempio di signature per un netscan UDP-NetScan: L attività malevola denominata net-scan è stata già descritta nel Capitolo 1, sezione Conoscendo l attività di scanning è possibile intuire quali signatures siano necessarie per identificare un UDP network scan. Vengono ispezionati i pacchetti con un numero piccolo di sorgenti, un elevato numero di destinazioni, un piccolo numero di pacchetti per ogni destinazione (rappresentanti le sonde), ed un elevato numero di pacchetti UDP ( 80%). UDP-NetScan.Response: Viene identificata da un numero ridotto di destinazioni, questo perchè consideriamo che la trasmissione della sonda malevola venga trasmessa da un solo host. La maggior parte dei pacchetti ( 80%) è di tipo ICMP, contenenti l informazione destination unreachable. La signature tiene in conto due casi: a) la rete/hosts sono irragiungibili o che l accesso è proibito a causa di un firewall. b) l host è attivo ma il protocollo/porta non è disponibile/aperta. Nel caso a) (marcato in rosso nella figura), è il gateway che invia pacchetti ICMP e quindi provengono da una sorgente singola. Nel caso b) (marcato in blu), invece, ogni macchina target risponde e quindi il numero di sorgenti è maggiore. Le ultime tre righe della signature descrivono il pacchetto UDP originario incapsulato in un pacchetto ICMP destination unreachable. 31\n40 Capitolo 3 Il concetto di Big Data Quando si ha a che fare con il networking o con Internet in generale, non si può non introdurre il concetto di Big Data. Nel Capitolo 2 è stato descritto il dataset che verrà utilizzato dal nostro algoritmo di detection. In questo capitolo, invece, cercheremo di comprendere la dimensione di quel dataset a quanto può ammontare e quindi il perchè di alcune scelte che sono state effettuate, nel costruire un infrastruttura che risultasse adeguata al tipo di dato che sarà processato. Il termine Big Data è ormai onnipresente in numerosi ambiti di ricerca riguardanti scenari variegati e non solo quello informatico, come ad esempio quello sociologico, medico, biologico, economico ecc. Tutti gli studi portati avanti su come trattare grandi moli di informazioni in tempi ragionevoli, convergono ad un unica definizione del termine: Big Data è usato per descrivere una raccolta di dati così estesa in termini di volume, velocità e varietà da richiedere tecnologie e metodi analitici specifici per l estrazione di valore . E facile comprendere dunque quanto possa essere complicato processare una collezione di dati così ampia con database o applicazioni tradizionali. E richiesto l utilizzo di calcoli paralleli, ovvero l esecuzione simultanea del codice sorgente di uno o più programmi, su più microprocessori (o più core dello stesso processore), allo scopo di aumentare le prestazioni di calcolo del sistema di elaborazione. Per capire lo scenario di cui stiamo parlando, basti pensare che nel mondo sono presenti 4.6 miliardi di dispositivi mobili e circa 3 miliardi di persone che posseggono l accesso ad Internet. In questo contesto, la mole dei dati è dell ordine degli Zettabyte, ovvero miliardi di Terabyte. L analisi congiunta di definizioni esistenti per il termine Big Data e i maggiori lavori di ricerca svolti in tale ambito, ci consentono di affermare che al centro di tale concetto ci sono una serie di aspetti da tenere in considerazione, tra cui: Volume, Velocità e Varietà, ovvero le dimensioni dell insieme di dati da me- 32\n41 morizzare e analizzare, la capacità di effettuare l analisi dei dati in tempo reale o quasi, senza mai sforare il limite di accettabilità e infine, le diverse tipologie di dati provenienti da fonti diverse. Teconologia e Metodo Analitico: tecnologie richieste per processare efficacemente grandi quantità di dati in tempi tollerabili. Veridicità: valore informativo che si riesce ad estrarre. Il dato deve poter essere compreso. I dati che devono essere gestiti in questo contesto hanno una dimensione troppo elevata per poter essere processati dai comuni software (tipcamente basi di dati relazionali) in tempi brevi. Per questo motivo non possono essere gestiti da database DBMS, RDBMS o ORDBMS. Le teconologie sviluppatesi negli anni sono numerose e in continuo miglioramento. Le principali architetture sono: SAP HANA, un sistema di gestione di basi di dati colonnare e in-memory sviluppato e commercializzato dalla società SAP. L architettura è progettata per gestire sia alti tassi di transazioni, che elaborazione di interrogazioni complesse nella stessa piattaforma. Apache Hadoop, un framework che supporta applicazioni distribuite con elevato accesso ai dati sotto una licenza libera; permette alle applicazioni di lavorare con migliaia di nodi e petabyte di dati. Google MapReduce, framework software brevettato e introdotto da Google per supportare la computazione distribuita su grandi quantità di dati in cluster di computer. Il framework è ispirato alle funzioni map e reduce usate nella programmazione funzionale Oracle Exalytics, una appliance completa per l analisi e la gestione dei dati inmemory, appositamente ingegnerizzata su hardware ad alte prestazioni per ridurre i costi e la complessità delle infrastrutture IT e incrementare al contempo la produttività e le performance delle applicazioni di data discovery, business intelligence, modellazione e pianificazione. Focalizzeremo l attenzione su Apache Hadoop, che rappresenterà il framework alla base dell algoritmo di detection sviluppato. 33\n42 3.1 Tecnologie: Apache Hadoop e Apache Spark Trattare i Big Data e contemporaneamente avere una velocità accettabile, comporta requisiti computazionali e di storage che un sistema informatico classico non è in grado di fornire. Hadoop è un framework open source che è stato progettato appositamente per trattare i Big Data. I componenti primari di Hadoop sono HDFS e MapReduce: entrambi furono originariamente sviluppati da Google, prima di diventare un progetto Apache. HDFS (Hadoop Distibuted File System) consente a diverse macchine remote di cooperare per raggiungere un obiettivo comune: velocizzare i tempi di calcolo. Mapreduce, invece, è un modello di programmazione il cui scopo primario è quello di suddividere efficacemente delle operazioni logiche computazionali su diverse unità separate tra loro. Hadoop e Mapreduce si sono dimostrati molto efficenti nel gestire moli di dati di elevate dimensioni. Alcune caratteristiche peculiari che fanno di Hadoop un framework di successo sono le seguenti: Velocità: Hadoop offre librerie che permettono la suddivisione dei dati da elaborare direttamente sui nodi di calcolo e permette di ridurre al minimo i tempi di accesso, questo perchè i dati sono immediatamente disponibili alle procedure senza pesanti trasferimenti in rete. Affidabilità: Il framework garansitsce un elevata affidabilità: le anomalie nel funzionamento e tutti gli eventuali problemi del sistema sono gestiti a livello applicativo anzichè usare sistemi hardware. Scalbilità: realizzabile aggiungendo nodi al cluster in esercizio. Figura 3.1.1: Architettura di Hadoop 34\n43 Come si può notare dall immagine, i componenti che costituiscono il nucleo centrale della piattaforma di calcolo distribuito sono : Hadoop Common: API di supporto ai vari moduli di Hadoop Map-Reduce: Un sistema basato su YARN per l elaborazione parallela di insiemi di dati, lavorando secondo il principio del divide-et-impera. Sarà approfondito nel corso del capitolo. YARN: Un framework per la pianificazione del lavoro (creazione di applicazioni o infrastrutture per il calcolo distribuito) e la gestione delle risorse del cluster (CPU, storage, memoria). HDFS: file system distribuito che fornisce un efficace modalità di accesso ai dati. Garantisce che i dati siani ridondanti nel cluster, in questo modo le operazioni su tali dati risultano immuni a fronte di un eventuale guasto ad un nodo. Inoltre, HDFS accetta dati in qualsiasi formato, strutturati e non. Intorno al nucleo centrale esistono altri componenti importanti, ma citeremo solo quelli di maggiore interesse, come ad esempio: Ambari: strumento web-bases per la gestione e il monitoraggio del cluster Apache Hadoop che include il supporto per Hadoop HDFS, Mapreduce, Hive, HCatalog, ZooKeeper, Zeppelin, OOzie, Pig ecc. Cassandra: un database multi-master scalabile senza single point of failure. ZooKeeper: fornisce un infrastruttura centralizzata e una serie di servizi che consentono la sincornizzazione di oggeti comuni nel cluster, ad esempio le configurazioni che devono essere presenti su tutti i nodi e che devono rimanere sincronizzate. Apache Kafka utilizza Zookeeper, ma ne riparleremo nei capitoli successivi Apache Spark Apache Spark è un framework open-source per il trattamento dei Big Data, costruito appositamente per essere veloce, semplice da utilizzare e al tempo stesso sofisticato. Hadoop e Spark non sono due prodotti direttamente confrontabili, nonostante le similarità che possiedono. Sviluppato dalla Apache Software Foundation, Spark si è recentemente imposto come framework, spodestando il primato di Hadoop. Entrambi forniscono noti strumenti essenziali per l elaborazione dei Big Data. Non hanno 35\n44 funzioni identiche nè sono mutuamente esclusivi poichè possono lavorare in sintonia. In alcune situazioni, Spark è ormai circa cento volte più veloce rispetto ad Hadoop MapReduce, ma ha lo svantaggio di non disporre di un proprio storage distribuito ed è proprio per questo motivo che molti progetti nel settore dei big data prevedenno la coesistenza dei due framework, in modo che Spark possa usare il file system distribuito di Hadoop (HDFS). Inoltre le distribuzioni commerciali all-inclusive, come ad esempio la Sandbox Hortonworks di cui parleremo nei capitoli successivi, offrono entrambi i framework, permettendo di combinare le funzionalità più appropriate alle proprie esigenze. La vera marcia in più di Spark è l efficenza computazionale: Spark esegue gran parte delle elaborazioni all interno della RAM (in-memory) che, come è noto, è più veloce dei dispositivi di memorizzazione non volatili. Le operazioni eseguite su Hadoop invece, necessitano che i dati vengano continuamente spostati da e verso il disco di memorizzazione, creando un collo di bottiglia, questo perchè ogni operazione che viene eseguita deve essere necessariamente memorizzata, prima che la prossima possa iniziare. Questa scelta fu inizialmente compiuta per garantire l integrità dei dati in caso di blocco. Spark aggira il problema organizzando i dati nella RAM in blocchi denominati RDD (Resilient Distributed Dataset), recuperabili in caso di errore. Figura 3.1.2: Architettura di Spark Spark consente di maneggiare una varietà di dati molto ampia, ad esempio testuale e grafico oppure consente di operare con dati batch e real-time (streaming data). E possibile scrivere applicazioni in diversi linguaggi di programmazione come Java (con le API di supporto), Scala o Python ed eseguirli tramite shell. Spark Streaming: può essere utilizzato per processare dati in tempo reale. Utilizza il concetto di DStream che consiste in una sequenza di RDD. La libreria 36\n45 sarà approfondita nella sezione Spark SQL: fornisce la capacità di operare con API JDBC e consente di eseguire delle query SQL sull architettura Spark. Spark MLlib: libreria per il machine learning, contenente una serie di algoritmi e utilities per il machine learning tra cui clustering, classificazione ecc. GraphX: una libreria per l analisi di grafi talmente grandi che non potrebbero essere analizzati su una singola macchina (ad esempio i grafi dei social network). Un grafo è una collezione di nodi (o vertici) collegati da archi. Ad esempio i nodi possono essere le persone e gli archi le amicizie. La libreria offre algoritmi come PageRank (per misurare quanto è "importante" ogni nodo di un grafo), il calcolo delle componenti connesse, il calcolo dei triangoli, ecc.. Spark può essere eseguito in modalità stand-alone server o può poggiare su un framework distribuito, ad esempio YARN, come mostrato nella figura seguente : Figura 3.1.3: Componenti dell architettura Spark Resilient Distributed Dataset - RDD Tutta l architettura di Spark ruota intorno al concetto di RDD, che consiste in una collezione di elementi di elevata affidabilità che possono operare in parallelo. Tutti i lavori svolti con Spark possono essere considerati come un caricamento di dati in un RDD, una trasformazione di RDD o azioni fatte su RDD per prendere dei risultati. Esistono due modi per creare gli RDDs: parallelizzare un esistente collezione di dati tramite uno dei linguaggi di programmazione disponibili dall architettura, oppure referenziare un dataset residente in un sistema di storage esterno come ad esempio S3, HDFS, HBase. L RDD può gestire qualsiasi tipo di dato ed è progettato per ottimizzare il 37\n46 data-processing. Sono immutabili e per modificare un RDD è possibile applicare due tipi di operazione: Trasformazioni: non torna un singolo valore ma un nuovo RDD modificato in base all operazione di trasformazione applicata. Alcune operazioni di trasformazione disponibili sono: map, filter, flatmap, groupbykey, reducebykey, aggregateby- Key, pipe e coalesce. Azioni: operazioni che ritornano un nuovo valore. Quando un operazione di questo tipo è invocata su un RDD, tutte le queries necessarie al processamento del dato sono eseguite allo stesso momento. Alcune azioni che è possibile effettuare sono: reduce, collect, count, first, take, countbykey e foreach. L unione di trasformazioni e azioni semplifica di molto la programmazione rispetto al modello MapReduce. Analizziamo alcune operazioni utilizzate nell algoritmo: map: ogni elemento dell RDD di partenza viene mappato in un elemento dell RDD di destinazione flatmap: simile a map, ma ogni elemento viene mappato in 0 o più elementi sull RDD di destinazione. filter: vengono mantenuti solo quegli elementi per cui è valida una certa condizione. reducebykey: gli elementi con la stessa chiave vengono ridotti in un solo elemento dove il valore dipende dai valori presenti nell RDD iniziale. mapvalues: cambia i valori lasciando inalterata la chiave. take(n): tutti gli elementi devono entrare nella memoria centrale di un singolo nodo (il driver) alrimenti fallisce il programma. Per ovviare a ciò sono presenti i metodi take(n) che restituiscono n elementi dell RDD. saveastextfile: consente di salvare l RDD su disco, usando la rappresentazione in stringa degli elementi. coalesce(): consente di inserire i risultati di un programma parallelo in un unico file e non su diversi file separati. 38\n47 Spark Streaming Come già detto precedentemente, l architettura su cui poggia Spark consente di scegliere due modalità con cui è possibile elaborare i dati: Batch e Streaming. Con streaming, si intende la capacità di elaborare i dati in tempo reale, a differenza della tecnica batch che invece, prevede un elaborazione statica off-line. Per molte compagnie, l elaborazione real-time è diventata una componente critica e da tenere in considerazione. Una delle librerie di supporto a questa tecnica fornita da Spark, è denominata Spark Streaming, un estensione delle API Spark Core. In questo contesto, il dato è visto come una sequenza continua di record generati da diverse sorgenti come ad esempio sensori, server ecc. Se intendiamo costruire un applicazione che colleziona, processa ed analizza dati streaming in tempo reale, bisogna tenere in considerazione differenti soluzioni di progetto. Nel nostro caso, siamo interessati ad un anomaly detector in grado di rilevare anomalie nel traffico di rete, è necessario quindi implementare un algoritmo che operi con flussi di dati continui. Il modo di operare di Spark Streaming consiste nel suddividere i dati streaming in sequenze batch chiamate microbatch, impostando un intervallo predefinito in secondi e successivamente trattare ogni batch di dato come un classico RDD. Successivamente è possibile elaborare gli RDDs risultanti utilizzando le classiche operazioni batch descritte nella sottosezione precedente. E importante settare in modo opportuno l intervallo temporale con cui vengono prelvati i dati streaming. Il settaggio dipende dall applicazione che si sta costruendo e dai requisiti di elaborazione dei dati: se il valore dell intervallo temporale N è troppo piccolo, allora i microbatches non avranno abbastanza dati da elaborare. I dati streaming possono provenire da numerose sorgenti differenti, come ad esempio Kafka, Flime, Twitter, Amazon s Kinesis. Nei successivi capitoli si porrà maggiore attenzione su Apache Kafka. Un altro vantaggio nell utilizzare Spark consiste nel combinare l elaborazione batch e quella streaming in un unico sistema. La figura seguente riassume l architettura Spark Streaming : 39\n48 Figura 3.1.4: Spark Streaming Spark Streaming riceve dati in tempo reale e divide i dati in batches che sono successivamente processati dallo Spark engine per generare il flusso finale. Spark Streaming fornisce un astrazione di alto livello chiamata discretized stream o DStream, che rappresenta un flusso continuo di dati. I DStream possono essere creati o da sorgenti come Kafka, Kinesis ecc o applicando operazioni di alto livello su altri DStream. Internamente un DStream è rappresentato come una sequenza di RDDs. Dettagli tecnici sulla realizzazione di un architettura operante con Spark Streaming e Apache Kafka, saranno discussi nei capitoli successivi. 3.2 MapReduce e la programmazione funzionale Figura 3.2.1: Word Count: Esempio grafico MapReduce è un framework brevettato e introdotto da Google, per supportare la computazione distribuita su grandi quantità di dati in cluster di computer. Il framework è ispirato alle primitive map e reduce, usate nella programmazione funzionale. Uno dei 40\n49 linguaggi di programmazione funzionale su cui ci sofferemeremo maggiormente nel corso della trattazione, è il linguaggio Scala, il quale sarà approfondito nel Capitolo In questa sezione viene descritto il funzionamento del modello di programmazione MapReduce e del suo enorme impatto nel mondo dell informatica. Con l utilizzo di tale framework, è possibile elaborare e generare grandi insiemi di dati. In particolare gli utenti possono specificare due primitive di base: Map() che elabora una coppia chiave/valore per generare un insieme intermedio di coppie chiave/valore Reduce() che unisce tutti i valori intermedi associati alla stessa chiave. Lavorare con coppie chiave/valore è molto frequente usando linguaggi di programmazione funzionale. Gli RDDs che operano su coppie chiave/valore sono un tipo di dato molto comune e spesso richiesto per molte operazioni in Spark. I programmi scritti in stile funzionale sono automaticamente parallelizzati e di facile esecuzione su un cluster multi processore. Tale approccio consente ai programmatori senza alcuna esperienza nel campo dei sitemi paralleli, di utilizzare facilmente le risorse di un sistema distribuito. Una delle proprietà più apprezzate di Mapreduce è la scalabilità: una tipica computazione di Mapreduce elabora molti terabyte di dati su migliaia di macchine. Per quanto riguarda il funzionamento del framework in analisi, la funzione map scritta dall utente prende una coppia di ingressi e produce un insieme di M coppie intermedie chiave/valore. Il processo di riduzione, successivamente, considera tutti gli M valori intermedi associati alla stessa chiave intermedia e li invia alla funzione reduce. Figura 3.2.2: Map - Reduce Esempio:WordCount Si vuole contare il numero di occorrenze di ogni parola in una grande collezione di documenti. La funzione map riceve in ingresso una coppia 41\n50 chiave/valore. La funzione, per ogni parola trovata nel documento, genera in uscita una coppia (parola,1) che rappresenta un insieme chiave/valore intermedio. Si iniziano a contare le occorrenze delle parole trovate. La funzione reduce riceve in ingresso i precedenti valori intermedi, quindi le coppie (parola,1). Si effettua una riduzione per chiave, cioè vengono raggruppare tutte le coppie che presentano la stessa chiave e si effettua la somma in uscita dei valori di ogni coppia, producendo come output finale una coppia contenente la parola (chiave) e la somma di tutte le occorrenze di quella parola (valore). La Figura mostra quando descritto. 42\n51 Capitolo 4 Progettazione di un Anomaly Detector In questo capitolo, andremo ad analizzare nel dettaglio l architettura e l implementazione del metodo di detection proposto. Nel Capitolo 1, sezione 1.3, si è parlato delle difficoltà che è possibile riscontrare nel progettare un algoritmo per il rilevamento delle anomalie. La tecnica che andremo ad utilizzare non ispeziona il contenuto (payload) di ogni pacchetto, poichè ciò comporterebbe numerosi problemi e imprecisioni e in alcuni casi sarebbe addirittura impossibile da applicare (1.3). Avendo scartato l approccio payload-based, l alternativa consiste nell utilizzare l approccio flow-based. Con questo metodo, i flussi vengono monitorati da moduli specializzati posizionati nei dispositivi di rete come ad esempio i routers. Tali moduli hanno la responsabilità di esportare i report contenenti le proprietà di un flusso verso un collector. Il flow-based detector (o flow-analyzer) analizzerà questi flussi per rilevare eventuali anomalie. Comparati con i tradizionali network intrusion detection systsems, i flow-based gestiscono una quantità di dati molto più ridotta, come dimostreremo successivamente nella sezione 4.2. L unico svantaggio nell utilizzare un approccio flow-based è che i flussi, essendo per loro natura degli aggregati, possono comportare una perdita di informazione. Per questo motivo i NIDs flow-based, non riescono a garantire una precisione elevata come avviene con i payload-based. 4.1 Definizione di flusso Negli ultimi dieci anni, il concetto di flusso è divenuto molto popolare nell ambito del monitoraggio delle reti. I maggiori vendors come Cisco, offrono dispositivi di rete flow-enabled come ad esempio i router Netflow. In letteratura, esistono numerose definizioni di flusso. In questa trattazione ci soffermeremo sulla definizione proposta da IPFIX : 43\n52 Definizione 1. Un flusso è definito come un insieme di pacchetti IP osservabili nella rete durante un certo intervallo temporale. Tutti i pacchetti che appartengono ad un particolare flusso hanno un insieme di proprietà comuni. Le proprietà comunemente usate per caratterizzare un flusso sono: (Ip Sorgente, Ip Destinazione, Porto Sorgente, Porto Destinazione, Protocollo) Possono essere aggiunti anche altri campi addizionali, a seconda delle diverse applicazioni. Nel nostro caso, il flusso è caratterizzato dai seguenti campi: (Timestamp, Ipsrc, Ipdst,Pacchetti,NumByte,Durata,PortoSrc,PortoDst,Protocollo) Un flusso non presenta restrizioni dovute alla dimensione: ogni comunicazione tra un host sorgente e uno destinazione genererà un flusso, anche se si tratta di un singolo pacchetto. I flussi possono essere anche unidiriezionali a differenza delle connessioni TCP, che sono per definizione bidirezionali. Ultimamente, anche per i flussi si è parlato di bidirezionalità, una nuova definizione introdotta da IETF, questo perchè dati bidirezionali possono migliorare l efficienza del processo di export e collection. Il processo per creare un flusso di dati è costituito da tre step principali, definiti rispettivamente: monitoring, exporting e collecting. Tali attività sono svolte da tre componenti, noti in letteratura con il termine di flow monitor, flow exporter e flow collector. La figura seguente mostra quanto detto [22,24]: Figura 4.1.1: Flow-Based Architecture Il componente flow monitor, detto anche punto di osservazione, estrae l header da ogni pacchetto IP che passa attraverso l interfaccia di monitoraggio. Ogni header è marcato con un timestamp che denota il momento della cattura. Successivamente l header è campionato o filtrato a seconda delle specifiche richieste e infine, si effettua l aggiornamento della flow-cache memorizzando un nuovo record di flusso. Il componente flow exporter, ha il compito di monitorare la flow-cache al fine di esportare verso il flow collector tutti i flussi definiti expired. Un flusso diviene expired se si verifca uno dei quattro casi di seguito riportati: 44\n53 1. non vengono più osservati pacchetti appartenenti al particolare flusso in analisi. Questo avviene impostando una soglia che determina l intervallo temporale, impostata a 15 secondi (Cisco Netflow ). Può essere settata in modo opportuno a seconda dei requisiti. 2. Il flusso raggiunge l active timeout, ovvero il suo tempo di vita massimo. Settato a 30 minuti da Cisco Netflow, ma spesso è facile trovare tale timeout impostato con valori più bassi. 3. Individuati dei flag FIN o RST in un flusso TCP che denotano la fine di una connessione TCP. 4. La flow-cache satura. In questo caso solo un sottoinsieme di flussi presenti nella cache viene esportato nel collector. Infine, il flow collector ha lo scopo di ricevere i flussi dal flow exporter e di memorizzarli, in modo da renderli disponibili per analisi o monitoraggi successivi. Poichè le tracce di traffico fornite dal dataset MAWI sono in formato.dump (Capitolo 2, sezione 2.1) e di grandi dimensioni, è necessario effettuare un pre-processing del dato, al fine di ottenere in uscita tracce di traffico in formato.pcap e splittarle (per velocizzare il processo) in un numero di chunk desiderato con il tool editcap. Successivamente è possibile realizzare lo scenario descritto dalla figura Per realizzare lo scenario in modo automatizzato sono stati utilizzati una serie di tool, in particolare: Softflowd: implementazione software di un flow monitor. Legge il traffico di rete sottoforma di tracce pcap e lo inoltra al demone di cattura nfcapd su una determinata porta su cui è in ascolto. Nfcapd: implementazione di un flow collector, legge i netflow provenienti da softflowd e li memorizza in file formato binario. I file di uscita sono auotmaticamente suddivisi ogni n minuti in base ad un timestamp. Il file in uscita sarà del tipo: nfcapd Nfdump: è necessario trasformare i file generati da nfcapd in un formato testuale leggibile per analisi successive. Il tool nfdump è usato per esportare i dati netflow binari, in formato ASCII testuale. La procedura è stata applicata per ogni traccia di traffico proveniente dal dataset MAWI che si intende analizzare, in particolare è stata applicata per tutte le tracce di traffico del mese di Ottobre Il mese è stato scelto valutando il numero di anomalie che 45\n54 sono state riscontrate da MawiLab. Inoltre, i report.xml o.csv forniti da MawiLab non coprono fedelmente tutti i giorni del mese e Ottobre, scartando solo 3 giorni (il 3, il 6 e il 14), è sembrato un giusto compromesso. 4.2 Studio preliminare Uno dei motivi per cui si è scelto di implementare un algoritmo di detection flow-based, riguarda la diminuzione del dataset che è possibile ottenere, aggregando i pacchetti in flussi. MAWI effettua statistiche per pacchetto riguardanti la percentuale di pacchetti, bytes e bytes/pkt scambiati utilizzando un determinato protocollo di rete. Prendendo in considerazione solo i protocolli TCP, UDP e ICMP (tipicamente i più frequenti) all interno delle tracce della settimana dal 9 al 15 Gennaio 2014, è stata effettuata una statistica calcolando la percentuale media di occorrenze di ciascun protocollo. Lo stesso studio è stato applicato agli aggregati netflow per poter poi confrontare i risultati ottenuti. In tabella sono riportati i valori medi percentuali ricavati: PROTOCOLLO PACCHETTI (MAWI) FLUSSI (Netflow) TCP 56.5% 8.09% ICMP 17.49% 73.39% UDP 22.38% 18.45% Tabella 4.1: Pacchetti e Aggregati Netflow Il grafico seguente mostra in maniera più chiara il fenomeno che stiamo valutando: Figura 4.2.1: Grafico del confronto 46\n55 Aggregando i pacchetti in flussi si ha una notevole diminuzione dei flussi TCP e una leggera diminuzione di quelli UDP. Le stesse considerazioni non possono essere fatte per il protocollo ICMP, che non potendo essere aggregato per definizione, aumenta la dimensione del dataset da analizzare. Si potrebbe pensare di lavorare quindi su tracce di traffico aggregate che non considerino il protocollo ICMP, ma è indispensabile prima di tutto capire se le anomalie che sfruttano il protocollo ICMP sono in numero talmente basso da poter essere escluse. Per verificare questo fenomeno è necessario fare uno studio approfondito sul tipo di anomalie che MawiLab è riuscito a rilevare. La sottosezione successiva si sofferma su questo aspetto Ground-truth e gold-standard Come spiegato nel Capitolo 2, è possibile studiare l analisi effettuata dai detector di MawiLab, tramite dei report generati dal sistema. Lo scopo è quello di capire l andamento delle anomalie negli anni a partire dal 2007 fino al 2016, soffermandoci principalmente sulle seguenti tassonomie: Netscan di tipo TCP, ICMP e UDP Portscan Dos Per automatizzare il processo, è stato realizzato uno script python che lavora sui report.csv ed effettua il conteggio sulle tassonomie rilevate negli anni. Dai risultati ottenuti è possibile costruire la ground-truth. Prima di procedere, è necessario chiarire alcuni aspetti: con il termine ground-truth ci si riferisce ad un modello statistico che mira a confermare o no determinate ipotesi di ricerca. E un insieme di misurazioni ritenute molto più accurate rispetto al sistema che stiamo testando e rappresenta dei valori di riferimento utilizzati per eventuali confronti. Il termine gold-standard invece, si riferisce ad un insieme di dati che sono disponibili sotto certe condizioni e possono essere visti come un modello sperimentale che è stato già testato ed ha la migliore accuratezza possibile. Non possiamo definire con il termine ground-truth i risultati forniti da MawiLab, questo perchè i detectors che impiega, applicando dei metodi stocastici, non riescono a rilevare tutte le anomalie in modo corretto, ma possiamo affermare che è il meglio che si possa avere. Il concetto verrà approfondito nel Capitolo 5, quando confronteremo i risultati ottenuti dal nostro algoritmo, con la gold-standard MawiLab. 47\n56 Le tabelle riportate di seguito mostrano i risultati ottenuti dallo script python realizzato, in termini quantitativi e percentuali, di tutte le anomalie riscontrate da MawiLab in 10 anni di monitoraggio: Anno PortScan ICMPNetScan TCPNetScan UDPNetScan DoS % 4.9% 56% 35% 2% % 2.5% 50% 30.1% 1.3% % 3.1% 64% 30% 1.32% % 2.1% 61% 30% 2.4% % 1.1% 58% 25% 11% % 0.7% 63% 26.8% 4.7% % 0.6% 65% 28% 1.6% % 0.1% 74% 21% 2.4% % 0.6% 72% 23% 2.2% % 0.8% 74% 32% 1.8% Tabella 4.2: Gold-standard (percentuali) Tassonomia PortScan ICMPNetScan TCPNetScan UDPNetScan DoS Tabella 4.3: Gold-standard (quantità) Utilizzando i risultati ottenuti precedentemente è stato possibile realizzare i seguenti grafici: Figura 4.2.2: Andamento anomalie negli anni (percentuali) 48\n57 Figura 4.2.3: Andamento anomalie negli anni (quantità) Si può notare, nel grafico di Figura 4.2.2, che la percentuale di anomalie che sfruttano il protoccolo ICMP è sempre al di sotto del 10%. E possibile quindi non considerare il protocollo ICMP nelle analisi successive che andremo ad effettuare. La fase di filtraggio di questo protocollo, avverrà durante il pre-processing del dato descritto in 4.1. Il processo di analisi sarà in questo modo notevolmente velocizzato, in quanto il dataset si riduce in modo considerevole. Ad esempio, la traccia del 9 Gennaio 2014 passerebbe da 38 milioni di flussi a soli 5 milioni. E stato realizzato anche un grafico che mostra l andamento delle anomalie di ogni mese a partire dall anno 2007 al 2016, aumentando così il livello di dettaglio: Figura 4.2.4: Andamento anomalie nei mesi 4.3 Linguaggio di programmazione utilizzato Poichè l algoritmo di detection è implementato interamente nel linguaggio di programmazione Scala è necessario approfondire alcuni aspetti. 49\n58 Scala è un linguaggio general purpose progettato per esprimere comuni pattern di programmazione in modo conciso, elegante e sicuro. Integra le caratteristiche tipiche dei linguaggi di programmazione funzionali e object-oriented, consentendo l integrazione con Pyhton e Java in maniera molto fluida e intuitiva. Le dimensioni del codice sono tipicamente ridotte se comparate a programmi equivalenti scritti ad esempio in Java. Per questi motivi, molte compagnie che dipendono da Java stanno iniziando a convertirsi a Scala per incrementare la produttività, la scalabilità delle loro applicazioni e l affidabilità . Scala è un puro linguaggio object-oriented nel senso che ogni valore è considerato un oggetto, ed è anche un linguaggio funzionale, nel senso che ogni funzione è un valore. Inoltre Scala presenta un integrazione nativa con l architettura Spark per l elaborazione di dati. Java è un linguaggio troppo verboso rispetto a Python o Scala e non supporta una shell interattiva. Mediante l uso di una shell interattiva come ad esempio la Spark Shell, è possibile accedere al dataset e creare prototipi di applicazioni in maniera molto semplice e dinamica. I motivi per cui è stato scelto Scala e non Python come linguaggio di programmazione funzionale per il nostro algoritmo di detection, sono i seguenti: 1. Python è in generale più lento di Scala. Un anomaly detector deve essere progettato pensando che la logica di elaborazione deve poter processare dati di elevate dimensioni in tempi ragionevoli (Capitolo 3) 2. Apache Spark è costruito su Scala. Se si commettono errori nel codice o il codice sorgente non ha il risultato atteso è più semplice fare debugging. 3. Quando Python invoca il codice Spark sottostante scritto in Scala ed eseguito su una JVM, la traduzione tra due ambienti e linguaggi diversi potrebbe causare problemi. 4. Essendo Spark implementato in Scala, usare lo stesso linguaggio di programmazione ci consente di accedere alle ultime novità. Inoltre gli aggiornamenti sono disponibili prima per Scala e successivamente portati in Python. 4.4 Le basi dell algoritmo Avendo descritto il tipo di linguaggio di programmazione usato è possibile ora soffermarsi sull algoritmo proposto. L approcio utilizzato è di tipo statistico, operante su un dataset non etichettato (unsupervised mode). L idea di base è quella di calcolare il rapporto tra i flussi di traffico 50\n59 uscenti ed entranti di un determinato indirizzo IP, ovvero, analizzando l intero dataset, capire quante volte un indirizzo ip è sorgente e quante volte è destinazione. Successivamente si studia il valore ottenuto dal rapporto delle occorrenze. Essendo interessati a rapporti molto grandi, quindi con un numero di flussi uscenti molto più elevato rispetto a quelli entranti, è stato applicato un filtro che seleziona in uscita solo i rapporti maggiori di 300. Viste le difficoltà nel comprendere se un indirizzo IP sta subendo o meno un attacco e valutare eventuali pattern anomali associati, l algoritmo è stato progettato in modo da selezionare solo gli IP sorgente che hanno un comportamento al di fuori del normale. Può capitare però che un IP destinazione ha un numero di flussi uscenti molto elevato e viene considerato comunque sorgente dall algoritmo.(capitolo 5-5.3) Un altro elemento da tenere in considerazione è il timestamp. Ogni traccia di traffico che viene elaborata, ha una durata di 15 minuti (900 secondi). E possibile suddividerla in slice temporali di un certo intervallo a scelta, prima però è necessario ridimensionare opportunamente il timestamp, espresso in formato epoch time, tipico delle tracce pcap. In questo modo è possibile capire in quale arco temporale all interno della traccia, si è presentato il pattern anomalo. Nel nostro caso la slice è stata impostata a 30 secondi. L algoritmo fornisce in uscita, un file contenente: [Timestamp, Indirizzo Ip Anomalo, Risultato del Rapporto] Figura 4.4.1: Slice temporali Step principali L algoritmo può essere schematizzato in 5 step, come mostrato in figura: 51\n60 Figura 4.4.2: Struttura dell algoritmo 1. Gli argomenti in ingresso sono: il valore della slice temporale, la soglia su cui filtrare i rapporti in uscita e la traccia di traffico da elaborare in formato.csv contenente i netflow, risultato del pre-processing e memorizzata o prelevata dinamicamente da HDFS o S3. 2. E effettuato un mapping sui flussi letti nel punto precedente. Vengono generate coppie chiave/valore intermedie, dove la chiave in questo caso è formata dal timestamp e dagli IP sorgente/destinazione. Si generano dunque tante coppie (timestamp ip,1). 3. Si effettua una riduzione per chiave, cioè vengono raggruppare tutte le coppie che presentano la stessa chiave e si effettua la somma in uscita dei valori di ogni coppia, producendo come output finale una nuova coppia contenente la chiave (timestamp ip) e la somma di tutte le occorrenze di quella chiave (valore). In questo modo sono state contate le occorrenze di flussi entranti e uscenti. 4. Viene calcolato il rapporto delle occorrenze calcolate nel punto Viene applicato un filtro sui rapporti calcolati, in modo tale che sono visualizzati nel file di output, solo i rapporti maggiori di una certa soglia. Il file è salvato nello storage HDFS, S3 o in uno storage locale a seconda di una delle tre architetture utilizzate - (sezione 4.5). Per maggiori dettagli sul codice, si veda l Appendice. La figura seguente riassume l intero sistema di anomaly detection ottenuto: 52\n61 Figura 4.4.3: Intero Processo Nel nostro caso, Internet è rappresentato dal dataset fornito da MAWI, già discusso nel Capitolo 2, mentre il componente Flow Storage può essere il servizio S3 di Amazon o HDFS, dipende dalle architetture realizzate, le quali saranno descritte nella sezione successiva. Il NetFlow Analyzer, invece, conterrà al suo interno una delle architetture proposte per far eseguire il codice Scala descritto in Figura Le analisi sui risultati forniti saranno oggetto di studio del Capitolo Netflow Analyzer: architetture realizzate Per poter eseguire in maniera efficace l algoritmo presentato nella sezione precedente, sono state create diverse architetture e ambienti di esecuzione. Lo scopo finale è l esecuzione dell algoritmo in ambiente cloud, al fine di poterne studiare la scalabilità e la velocità di esecuzione su diversi cluster. Sono state realizzate in totale tre architetture differenti, in particolare due batch molto simili tra loro e una streaming. Tutti i test locali sono stati eseguiti all interno dello stesso ambiente operativo, avente le seguenti proprietà: PC: Dell Inc. Piattaforma di esecuzione: Sanbox Hortonworks 2.5, con Hadoop Spark Version: 2.0 Kafka Version: Scala Version: Sistema Operativo: Ubuntu non virtualizzato 53\n62 Memoria RAM: 12 Gb CPU: Intel(R) Core(TM) i7-4710mq 2.50GHz, CPU cores: 4 Inoltre, ogni algoritmo è eseguito su Spark mediante lo script spark-submit, il quale prende in ingresso, oltre al.jar del programma Scala, una serie di parametri di configurazione, tra cui: driver-memory: il driver è il componente che gestisce l esecuzione di un programma Spark, decidendo i compiti da far svolgere ai processi executor in esecuzione nel cluster. In particolare, questo parametro dello script, indica la quantità di memoria usata dal processo driver per inizializzare l oggetto SparkContext, la cui istanza comunica con il gestore del cluster per richiedere un insieme di risorse (RAM,core,ecc) per gli executor. SparkContext inoltre, avvia i servizi interni principali e stabilisce la connessione con l ambiente di esecuzione di Spark. Agisce quindi come master per l applicazione che stiamo lanciando. executor-memory: Poichè l architettura è di tipo master/slave, esiste un processo coordinatore (il driver) e tanti processi executor.il parametro in questione rappresenta la memoria resa disponibile agli executor per eseguire l applicazione. num-executors: specifica il numero di esecutori da richiedere per l applicazione Spark executor-cores: specifica la quantità di core utilizzati da ogni executor deploy-mode: è possibile impostare la modalità client o cluster per eseguire il driver. Per l esecuzione sul cluster nel cloud sarà impostata la modalità cluster. Per i test locali, questo parametro è omesso. master: è il gestore del cluster a cui ci si vuole connettere. Impostando local[*], si esegue Spark localmente con il massimo numero di thread che è possibile eseguire sulla macchina locale. Impostando YARN, ci si connette al cluster YARN, in modalità client o cluster a seconda del valore settato in deploy-mode. Un applicazione Spark si compone di jobs, uno per ogni azione. Si ha cioè un job ogni qualvolta si vuole ottenere dal sistema il risultato di una computazione. Ogni job è composto da un insieme di stage che dipendono l un l altro, svolti in sequenza, ognuno dei quali viene eseguito da una multitudine di task, svolti parallelamente dagli executor. 54\n63 Figura 4.5.1: Comunicazione tra driver e cluster Architettura 1: Spark Streaming Prima di descrivere l architettura realizzata è necessario introdurre Apache Kafka più nel dettaglio . E un sistema di messaggistica distribuito e open source progettato secondo il modello di programmazione publish-subscriber, che consente di creare applicazioni in tempo reale tramite flussi di dati. I flussi di dati, ad esempio dati clickstream di siti Web, transazioni finanziarie o log di applicazioni, sono inviati al cluster Kafka denominato anche message broker, il quale memorizza i flussi in un buffer e li inoltra alle applicazioni per elaborarli, tipicamente basate su framework noti come Apache Spark Streaming ( ). Kafka è eseguito su un cluster in esecuzione su uno o più server. Il cluster memorizza flussi di dati all interno di strutture dati definite topics. Ogni record memorizzato consiste in una chiave, un valore e un timestamp. Kafka presenta alcune API interessanti come ad esempio: Producer API: consentono ad un applicazione di pubblicare uno stream di dati in uno o più topics. Counsumer API: consentono iscriversi ad un particolare topic di interesse e leggere i flussi prodotti su di essi. 55\n64 Figura 4.5.2: Kafka Cluster Le comunicazione tra client e server sono gestite dal protocollo TCP. Topic: un topic è una struttura dove viene pubblicato un dato o un flusso di dati. Uno stesso topic può avere più di un consumer. Internamente, un topic è suddiviso in più partizioni che rappresentano sequenze ordinate e immutabili di dati che sono continuamente aggiunti alla struttura. Ad un record interno alla partizione viene associato un id univoco chiamato offset. In Figura è mostrato quanto descritto: Figura 4.5.3: Topic La figura seguente mostra l architettura realizzata nel suo insieme. 56\n65 Figura 4.5.4: Architettura 1 - Spark Streaming Possiamo schematizzare le attività nei seguenti passi: Step0: La traccia di traffico viene caricata nell HDFS, in un apposita directory, con split di n righe alla volta tramite uno script python per evitare di inondare di richieste il listener. Contemporaneamente è avviato il Receiver Kafka. Step1: Spark Streaming si mette in ascolto sulla directory prevista per il caricamento e attende che un nuovo file venga caricato nell HDFS. Step2: La traccia viene elaborata secondo l algoritmo descritto in Figura e viene prodotto il risultato. Step3: Il risultato è prodotto su uno specifico topic Kafka. Step4: Il receiver Kafka consuma il risultato dal topic specifico. Step5: Il risultato finale è salvato su disco locale. In questo contesto, il programma Scala, oltre ad avere in ingresso la traccia di traffico, il valore della slice temporale e la soglia, prende in ingresso anche il broker Kafka da contattare, il nome del topic sul quale depositare il risultato e il percorso HDFS per mettersi in ascolto e prelevare nuovi flussi di dati real-time. Per dettagli sul codice, si veda l Appendice Analisi delle performance di esecuzione - test locali Sono stati prelevati i tempi di esecuzione dell algoritmo operante sull infrastruttura descritta nella sezione precedente. Per i test in locale, sono stati realizzati due setup differenti: Setup1: driver-memory impostato a 2 Gb, executor-memory 1 Gb 57\n66 Setup2: driver-memory impostato a 4 Gb, executor-memory 2 Gb BatchInterval: 8 secondi per entrambi i setup I tempi sono mediati su 3 esecuzioni elaborando tracce di dimensione crescente. 191Mb: Traccia singola 381Mb Traccia ottenuta aggregando due tracce singole 761Mb Traccia ottenuta aggregando 4 tracce singole In questo contesto, siamo interessati a capire qual è il limite massimo della traccia (in termini di Mb o Gb) che l infrastruttura realizzata riesce ad elaborare e in quanto tempo. Con tracce maggiori di 761Mb, i tempi di esecuzione sono risultati troppo elevati. Per questo motivo è necessario uno splitting preliminare. I risultati sono riportati nella seguente tabella: Dimensione Traccia Tempo Medio (sec) Minimo Massimo 191Mb 11.3 s 11 s 12 s 381Mb 15 s 13 s 17 s 761Mb 37.3 s 24 s 50 s Tabella 4.4: Calcolo Tempi Streaming Setup1 Dimensione Traccia Tempo Medio (sec) Minimo Massimo 191Mb 10.3 s 10 s 11 s 381Mb 14 s 13 s 15 s 761Mb 68 s 24 s 115 s Tabella 4.5: Calcolo Tempi Streaming Setup Architettura 2: Batch con HDFS locale Tale architettura non prevede l utilizzo di Apache Kafka nè di Spark Streaming. Il salvataggio del risultato finale può avvenire su HDFS o su S3, a seconda del percorso passato all algoritmo. La traccia di traffico può essere letta solo da HDFS non avendo utilizzato librerie proprietarie di S3, a differenza dell Architettura 3 di cui parleremo in seguito. Per rendere più dinamico l algoritmo è stato introdotto un file di configurazione contenente i percorsi HDFS di tutte le tracce di traffico che si intende elaborare. Modificando il file di configurazione è possibile aggiungere, rimuovere o modificare la traccia di traffico che si intende elaborare. 58\n67 Figura 4.5.5: Architettura 2 - Batch con lo storage HDFS sorgente Analisi delle performance di esecuzione - test locali Sono stati prelevati i tempi di esecuzione di quattro tracce di dimensione differente, mediando su 3 esecuzioni. I tempi sono mediati su 3 esecuzioni elaborando tracce di dimensione crescente. 191Mb: Traccia singola 381Mb Traccia ottenuta aggregando due tracce singole 761Mb Traccia ottenuta aggregando 4 tracce singole 1.5Gb Traccia ottenuta aggregando 8 tracce singole Il lancio del comando è stato effettuanto impostando executor-memory a 2Gb, omettendo il parametro driver-memory ed ottenendo i seguenti risultati: Dimensione Traccia Tempo Medio(sec) Minimo Massimo 191Mb 4.3 s 1s 11 s 381Mb 7.3 s 3 s 17 s 761Mb 19.3 s 8 s 47 s 1.5Gb 79.6 s 65 s 96 s Tabella 4.6: Calcolo tempi Batch da HDFS locale I tempi sono notevolmente più bassi rispetto all architettura che prevedeva l utilizzo della libreria Spark Streaming. Inoltre è stato possibile processare una traccia di traffico da 1.5 Gb in tempi ragionevoli. Per dettagli sul codice si veda l Appendice. 59\n68 4.5.3 Archittura 3: Batch con S3 remoto Poichè l architettura che andremo ad instanziare sul cloud Amazon (sezione 4.6), interagirà con lo storage S3, sono stati calcolati anche i tempi di esecuzione dell algoritmo che interagisce con esso. In questo ambito è possibile interagire solo con lo storage S3. L architettura ha la stessa struttura della precedente, aggiungendo come parametro di ingresso il bucket S3 e il path interno al bucket dal quale prelevare il file di configurazione. Per ulteriori dettagli sul codice si veda l Appendice. Figura 4.5.6: Architettura 3 - Batch con storage S3 sorgente Analisi delle performance di esecuzione - test locali Anche in questo caso, sono state elaborate 4 tracce di dimensione crescente. Lo scopo è capire quanto variano i tempi utilizzando due sistemi di storage differenti. Inoltre, questa architettura è di notevole interesse poichè rappresenta la stessa eseguita sul Cloud. I tempi sono mediati su 3 esecuzioni elaborando tracce di dimensione crescente. 191Mb: Traccia singola 381Mb Traccia ottenuta aggregando due tracce singole 761Mb Traccia ottenuta aggregando 4 tracce singole 1.5Gb Traccia ottenuta aggregando 8 tracce singole Dimensione Traccia Tempo Medio (sec) Minimo Massimo 191Mb 34.3 s 28 s 43 s 381Mb 56.6 s 54 s 59 s 761Mb s 107 s 109 s 1.5Gb s 204 s 210 s Tabella 4.7: Calcolo tempi Batch da S3 remoto 60\n69 Come si può notare, i tempi sono significativamente diversi usando lo storage S3. Graficando i risultati ottenuti dalle due architetture batch è possibile riscontrare ancora meglio quanto detto. Il grafico seguente mostra i risultati ottenuti: Figura 4.5.7: Confronto tempi medi di esecuzione Come si può osservare, l andamento è molto simile per entrambi gli storage: il tempo di esecuzione dell algoritmo aumenta linearmente con l aumentare della dimensione della traccia. Il collo di bottiglia risulta essere lo storage S3, infatti i tempi aumentano notevolmente quando si accede allo storage remoto offerto da Amazon, da locale. Solitamente si utilizza un cluster Amazon EC2 per accedere a dati memorizzati su S3, in modo da utilizzare la veloce rete interna di Amazon e non trasferire dati attraverso Internet, perdendo ordini di grandezza in termini di prestazioni o costo. Noteremo infatti come miglirano i tempi eseguendo l algoritmo direttamente sul cluster Amazon. 4.6 Deployment dell algoritmo su Cloud Le architetture proposte nelle sezioni precedenti, sono state eseguite in locale e se ne sono analizzate le performance. Per studiare la scalabilità dell algoritmo in ambiente cloud, è necessario creare opportunamente le infrastrutture più covenienti all analisi che si intende effettuare, in particolare la quantità di memoria RAM e numero di nodi slave impiegati. Uno dei maggiori benefici derivanti dall utilizzo di servizi di Cloud Computing è l estrema flessibilità che viene garantita al cliente. Inoltre sono presenti due aspetti fon- 61\n70 damentali che hanno maggiormente contribuito alla sua ampia diffusione: l eleasticità e la scalabilità. Il concetto di scalabilità sarà apprfondito nella sezione Scelta dell ambiente operativo Esistono diversi servizi web messi a disposizione per installare un ambiente operativo personalizzato sfruttando infrastrutture cloud, tra essi abbiamo: Amazon Web Service (EC2, EMR, S3 ecc) Microsoft Azure Google Cloud Platform Poichè l algoritmo è scritto in Scala che opera sul framework Apache Spark e Hadoop, è utile ai nostri scopi utilizzare servizi web che offrono supporto nativo per tale framework, come ad esempio Amazon EMR (Elastic MapReduce) ovvero una collezione di istanze EC2 con Hadoop pre-installato e pre-configurato. Si è dunque scelto il sistema AWS (Amazon Web Services) che offre un ampio set di servizi di calcolo, memorizzazione, database e applicativi, comprendenti funzionalità di tipo IaaS sia PaaS amministrati tramite un interfaccia web: la AWS Managment Console Tipi di Istanze EC2 Amazon EC2 offre un ampia gamma di tipi di istanze ottimizzate per soddisfare diversi casi d uso . Le VMs messe a disposizione sono adatte a molteplici contesti e possono essere suddivise in due famiglie: a prestazione fissa e variabile. Le prime sono usate in ambienti in cui è richiesta una capacità di calcolo costante e alta, per le seconde invece è stato progettato un sistema a crediti CPU. I crediti vengono accumulati quando la macchina è sottoutilizzata e utilizzati solo quando ci sono picchi di carico, determinando così l incremento delle sue prestazioni. Oltre a classificazione generale descritta, si hanno ulteriori macchine specializzate nel calcolo, nella memorizzazione, nelle risorse di rete o macchine adatte a più scopi. I tipi di istanze comprendono diverse combinazioni di capacità di CPU, memoria, storage e di rete, offrendo la flessibilità di poter scegliere la combinazione di risorse adeguata per le proprie applicazioni. Di seguito si descrivono le principali tipologie che possono essere prese in considerazione durante la fase di setup dell infrastruttura che si intende realizzare: M4: Istanze ad uso generico di ultima generazione. Processori Intel Xeon E v4 (Broadwell) da 2,3 GHz o Intel Xeon E v3 (Haswell) da 2,4 GHz. 62\n71 M3: Processori ad alta frequenza Intel Xeon E v2 (Ivy Bridge). Utilizzate per database di piccole e medie dimensioni, attività di elaborazione che richiedono più memoria, caching di flotte ed esecuzione di server back-end. C4/C3: Istanze per il calcolo ottimizzato. Processori ad alta frequenza Intel Xeon E v3 (Haswell) ottimizzati specificatamente per EC2. X1: Istanze ottimizzate per applicazioni in memoria su vasta scala per grandi aziende. Ideali per motori di elaborazione di Big Data come Apache Spark. R4: Ottimizzate per applicazioni che fanno uso intensivo di memoria. Processori ad alta frequenza Intel Xeon E v4. Consigliate per data mining, caching in memoria su scala Web ditrubuiti, applicazioni che eseguono in tempo reale di Big Daat non strutturati, cluster Hadoop e Spark Tipo Modello vcpu Mem (GiB) m4.large 2 8 m4.xlarge 4 16 M4 m4.2xlarge 8 32 m4.4xlarge m4.10xlarge m4.16xlarge m3.medium 1 3,75 M3 m3.large m3.xlarge 4 15 m3.2xlarge 8 30 c4.large 2 3,75 c4.xlarge 4 7,5 C4 c4.2xlarge 8 15 c4.4xlarge C3* c4.8xlarge 36/32* 60 X1 x1.32xlarge x1.16xlarge r4.large 2 15,25 r4.xlarge 4 30,5 R4 r4.2xlarge 8 61 r4.4xlarge r4.8xlarge r4.16xlarge Tabella 4.8: Modelli di VM Le istanze che andremo ad utilizzare per i nostri scopi, sono quelle evidenziate in rosso. 63\n72 4.6.3 Topologie EMR Il termine elasticità è il cuore di EMR (Elastic MapReduce). E un servizio web che fornisce capacità computazionale dinamica, ossia ridimensionabile secondo le esigenze del cliente. Per analizzare la scalabilità dell algoritmo è necessario creare diversi cluster con differenti topologie. configurate come segue: Nel nostro caso, l algoritmo è lanciato su tre diverse topologie Topologia Memoria Master # Core Slave Memoria Slave 1 8 Gb (m4.large) 2 16 Gb (m4.xlarge) 2 8 Gb (m4.large) 4 8 Gb (m4.large) 3 8 Gb (m4.large) 2 8 Gb (m4.large) Tabella 4.9: Topologie Di seguito è mostrata, per esempio, la topologia 2: Figura 4.6.1: Cluster di Topologia2-1 Master e 4 Slave Configurazioni Preliminari L architettura eseguita sul cluster EMR è quella descritta in Prima di lanciare lo script python che automatizza la creazione delle topologie ed esegue il programma su ognuna di esse è necessario: creare i ruoli di default che il cluster utilizzerà per eseguire il setup attaccare delle policy adeguate ai ruoli creati per consentire pieno accesso ad S3 64\n73 creare un bucket all interno di S3 e caricare al suo interno le tracce che si intende processare. E possibile a questo punto, lanciare lo script python passando in ingresso: 1. Il file delle topologie. In questo modo è possibile automatizzare il procedimento andando ad aggiungere/rimuovere/modificare le topologie come meglio crediamo. 2. File di configurazione di S3. Tale file contiene una o più path mediante le quali il programma Scala è in grado di prelevare le tracce di traffico dal bucket creato, per elaborarle. 3. Jar del programma Scala dell architettura 3 descritta precedentemente. Necessario per l esecuzione sul Master Node di una generica topologia. 4. Nome del bucket creato 5. KeyPair.pem se si intende creare un cluster al quale poi si vuole accedere tramite ssh o uploadare qualcosa. Lo script per prima cosa caricherà nel bucket il file di configurazione e il.jar da lanciare sul cluster. Successivamente legge dal file delle topologie, che tipo di cluster creare e lancerà il comando apposito mettendosi poi in attesa di eseguire il.jar. Al termine di una generica esecuzione, il Bucket conterrà un insieme di cartelle denominate Tempi* pari al numero di topologie scelto, con i tempi di ogni esecuzione di ogni traccia elaborata. Il bucket conterrà inoltre una serie di cartelle contenenti i risultati delle tracce che sono state elaborate dall algoritmo. Nel nostro caso avremo dunque 3 file in uscita (uno per ogni topologia) ciascuno contenente 12 valori temporali (3 esecuzioni di 4 tracce diverse) per un totale di 36 valori temporali. L ultima operazione dello script python consiste nel rimuovere dal bucket il file di configurazione e il.jar. Per maggiori dettagli sul codice, si veda l Appendice Analisi dei risultati ottenuti Le tracce processate dall algoritmo eseguito sul cluster sono le stesse che sono state analizzate e descritte in questa sezione: Di seguito sono riportate le tabelle per ogni topologia descritta in 4.9. L esecuzione è stata effettuata impostando l executor-memory a 4Gb. 65\n74 Dimensione Traccia Esecuzione Tempi (sec) Media Temporale 1 17 s 191Mb 2 2 s 7.3 s 3 3 s 1 4 s 381Mb 2 5 s 4 s 3 3 s 1 7 s 761Mb 2 6 s 6.3 s 3 6 s 1 9 s 1.5Gb 2 10 s 9.3 s 3 9 s Tabella 4.10: Tempi topologia1: 1 master da 8Gb e 2 Slave da 16Gb Dimensione Traccia Esecuzione Tempi (sec) Media Temporale 1 15 s 191Mb 2 3 s 7 s 3 3 s 1 5 s 381Mb 2 7 s 5.3 s 3 4 s 1 7 s 761Mb 2 8 s 7 s 3 6 s 1 10 s 1.5Gb 2 12 s 12.3 s 3 15 s Tabella 4.11: Tempi topologia2: 1 master da 8Gb e 4 Slave da 8Gb 66\n75 Dimensione Traccia Esecuzione Tempi (sec) Media Temporale 1 16 s 191Mb 2 3 s 7.3 s 3 3 s 1 5 s 381Mb 2 5 s 5 s 3 5 s 1 10 s 761Mb 2 10 s 9.6 s 3 9 s 1 19 s 1.5Gb 2 18 s 18.3 s 3 18 s Tabella 4.12: Tempi topologia3: 1 master da 8Gb e 2 Slave da 8Gb Nella sezione è stato effettuato un confronto di prestazioni dell algoritmo utilizzante HDFS e S3 e si era visto come S3 fosse di gran lunga più lento, quando acceduto da una macchina non presente sul cluster Amazon. Analizziamo ora gli stessi tempi di esecuzione presenti in Tabella 4.7 con quelli della topologia più scadente, riportati in Tabella Figura 4.6.2: Confronti tempi di esecuzione utilizzando S3 dal cluster e fuori dal cluster Come si può osservare dal grafico, i tempi di esecuzione dell algoritmo eseguito sul cluster e che si interfaccia con S3, risultano notevolmente ridotti rispetto ai test effettuati in locale. 67\n76 4.6.5 Studio delle performance Avendo a che fare con un architettura che opera con modelli di programmazione ottimizzati per il calcolo parallelo come il framework mapreduce e che suddivide il carico di lavoro su più slave ( o worker), è necessario introdurre alcuni concetti basilari . L obiettivo fondamentale del calcolo parallelo è quello di risolvere problemi di grandi dimensioni in tempi ragionevolmente brevi. I fattori che concorrono al raggiungimento di questo obiettivo sono molteplici, per esempio il tipo di hardware usato, il grado di parallelismo del problema e il tipo di modello usato. In questo ambito, per valutare le performance dell algoritmo e valutare come si comporta gestendo carichi differenti, è stato variato sia il numero di processori impiegati che la memoria asseganatali. Esistono una serie di indici per analizzare le performance di un algoritmo parallelo, definiti: Speedup, Efficienza e Scalabilità. Sono state definiti anche una serie di leggi come ad esempio la legge di Ahmdal utilizzata per definire i limiti del calcolo parallelo o la legge di Gustafson che suggerisce quando una parallelizzazione del codice può risultare efficiente. In questa trattazione siamo interessati a studiare la scalabilità dell algoritmo Scalabilità La scalabilità può essere definita come la capacità di essere efficiente su una macchina parallela e di incrementare la potenza di calcolo, definita come velocità di esecuzione, in maniera proporzionale all aumentare del numero di processori. Se si aumentasse la dimensione del problema e allo stesso tempo il numero di processori a disposizione, se il sistema è scalabile non si avrà perdita di efficienza. Possiamo distinguere due tipi di scalabilità: Scalabilità verticale: crescere in altezza, ovvero potenziare nodi di calcolo o istanze VMs preesistenti, mediante l aggiunta di più RAM o più core. Esiste sempre un limite alla scalabilità verticale a differenza di quella orizzontale. Scalabilità orizzontale: vuol dire crescere in larghezza, ovvero aumentare i nodi di calcolo parallelo nel cluster. Nell ambito del cloud computing si parla di istanze VMs (Virtual Machines) che aiutano a smistare il carico di lavoro tra più nodi generando una vera e propria architettura parallela. E possibile in questo modo aumentare le performance del sistema. 68\n77 Figura 4.6.3: Tipi di scalabilità Nel nostro caso, aumentiamo sia il numero di processori che la memoria disponibile per ognuno di essi. Di seguito si mostrano i risultati ottenuti: Figura 4.6.4: Tempi di esecuzione sul cluster EMR Come si evince dal grafico, per tracce di dimensioni ridotte, non sembrano esserci differenze significative nell andamento dei tempi medi di esecuzione. All aumentare della dimensione del problema, invece, la configurazione più veloce risulta essere quella del cluster di topologia1 (1 master e 2 Slave da 16Gb). I risultati evidenziano come l algoritmo sia in grado di gestire il trattamento di una mole di dati crescente in maniera lineare, senza cali bruschi di prestazioni. Si può affermare inoltre che la potenza di calcolo (velocità di esecuzione) aumenta in maniera proporzionale all aumentare della capacità e del numero dei processori. 69\nUniversita di Milano - Polo di Crema Novembre Session Hijacking. Marco Cremonini 1. Marco Cremonini - Corso Integrativo Network Security 1\nSession Hijacking Marco Cremonini 1 Marco Cremonini - Corso Integrativo Network Security 1 SESSION HIJACKING (lett. dirottare una sessione): una sessione attiva tra un client e un server viene dirottata\nStudio di reti di sensori con comportamento ciclico con il simulatore Castalia. Corso di Laurea in Informatica\nStudio di reti di sensori con comportamento ciclico con il simulatore Castalia Corso di Laurea in Informatica Candidato Andrea Di Saverio Relatori Maria Cristina Pinotti Alfredo Navarra Anno accademico\nla dimensione massima dell arena è di 30x30 m la dimensione massima dei marker è di 50x50 cm la dimensione minima dei marker è di 20x20 cm\nIl seguente documento formalizza le regole del contest Drone Vision Cup 2015, ideato e promosso dal MIVIA Lab, Laboratorio di Macchine Intelligenti per il riconoscimento di Immagini, Video e Audio, nell\nFirewall. Protezione perimetrale e sistemi anti intrusione\nFirewall Protezione perimetrale e sistemi anti intrusione Dispositivi di sicurezza Internet è un ambiente poco sicuro. Si rischia di subire ogni tipo di frode. Per l amministratore della rete di una organizzazione\ne applicazioni al dominio del Contact Management Andrea Brunello Università degli Studi di Udine\ne applicazioni al dominio del Contact Management Parte V: combinazione di Università degli Studi di Udine In collaborazione con dott. Enrico Marzano, CIO Gap srl progetto Active Contact System 1/10 Contenuti\nEsercizi di riepilogo: Processamento di traffico\nPolitecnico di Torino Corso di Tecnologie per Reti di Calcolatori Esercizi di riepilogo: Processamento di traffico Fulvio Risso October 18, 2010 Contents I. Esercizi 3 1. Esercizi 4 1.1. Definizione dell\nCONTINUOUS PERIMETER ASSESSMENT Descrizione del servizio e degli strumenti utilizzati\nCONTINUOUS PERIMETER ASSESSMENT Descrizione del servizio e degli strumenti utilizzati L ESIGENZA DA SODDISFARE Censimento delle classi di indirizzi IP Pubblici riconducibili alle società del gruppo Bancario\nHacker Frameworks & Risorse utili HACKER FRAMEWORKS\nHacker Frameworks & Risorse utili HACKER FRAMEWORKS In questo modulo vedremo sia i software framework più utilizzati in ambito di penetration testing sia le risorse, come ad esempio siti internet dedicati,\nI Virus Un virus, in informatica, è un software, appartenente alla categoria dei malware, che è in grado, una volta eseguito, di infettare dei file in modo da riprodursi facendo copie di se stesso, generalmente\nIENA Un modello alternativo per la rivelazione delle intrusioni in una rete locale.\nIENA Un modello alternativo per la rivelazione delle intrusioni in una rete locale. Marco Ramilli 1 OutLine. L odierna crescita di servizi distribuiti ha generato una vera e propria problematica nel settore\nSubsection 1. MapReduce\nMapReduce Subsection 1 MapReduce MapReduce La programmazione distribuita è molto pesante Soluzione: MapReduce MapReduce viene incontro alle sfide della programmazione distribuita. Le 3 regole Archivia\nOn AIR s.r.l. Tecniche di riconoscimento statistico Applicazioni alla lettura automatica di testi (OCR) Parte 10 Combinazione di classificatori Ennio Ottaviani On AIR srl ennio.ottaviani@onairweb.com http://www.onairweb.com/corsopr\nRiconoscimento automatico di oggetti (Pattern Recognition)\nRiconoscimento automatico di oggetti (Pattern Recognition) Scopo: definire un sistema per riconoscere automaticamente un oggetto data la descrizione di un oggetto che può appartenere ad una tra N classi\nIngegneria della Conoscenza e Sistemi Esperti Lezione 4: Alberi di Decisione\nIngegneria della Conoscenza e Sistemi Esperti Lezione 4: Alberi di Decisione Dipartimento di Elettronica e Informazione Apprendimento Supervisionato I dati considerati considerati degli esempi di un fenomeno\nCapitolo 1 Esercitazioni condotte in aula con Star-CCM+\nCapitolo 1 Esercitazioni condotte in aula con Star-CCM+ 1.1 Mixing Pipe Nella prima esercitazione è stato trattato il caso di un miscelatore nel quale sono stati iniettati 2 fluidi considerati ideali a\nTabella 1 Parametri del generatore di traffico\nTabella 1 Parametri del generatore di traffico 3.5 Bit error rate tests BER tests sono usati per determinare il tasso di errori in una trasmissione o in una rete punto-punto. Questi test sono effettuati\n[Giuseppe Alessandri, Appunti]\nPartendo da una differenziazione, oramai assodata, fra progettazione sul versante della razionalità tecnica e quello della complessità (Cristianini, tecnodid, 2001), è possibile sviluppare dei parallelismi