Metodi e meccanismi per l'individuazione e l'analisi delle dipendenze nei sistemi distribuiti

Capitolo1
Introduzione
L’oggetto di questo lavoro di tesi  e stato la progettazione e l’implementazione
di DeDALO (DEpendency Discovery and AnaLisys using Online trac measu-
rement), un framework di analisi per la rilevazione di interdipendenze in siste-
mi distribuiti. Il tool  e progettato con lo scopo di automatizzare la rilevazione di
dipendenze, utilizzando metodi black-box
1
basati sull’analisi del traco di rete.
Studiare le dipendenze in un sistema distribuito,  e fondamentale per costruire
mappe logiche fra gli elementi che lo compongono, evidenziando quei componen-
ti strategici su cui si fonda il suo corretto funzionamento. Tale analisi  e denita
Dependency and Discovery Analysis (DDA) e costituisce uno strumento utile
per valutare l’impatto e la propagazione di eventi localizzati, descrivendo tramite
un grafo gli elementi maggiormente coinvolti. DeDALO implementa un algoritmo
di DDA orientato all’analisi delle serie temporali, caratterizzanti ussi di dati nel
traco IP.
Negli ultimi anni, le tecniche di DDA hanno ricevuto una crescente attenzione.
Vi sono sia prodotti commerciali, come IBM Tivoli [IBM], EMC Smarts [EMC] o
HP OpenView [HP], che risultati scientici, [CZMB08] [KCK08] [BCG
+
07], in cui
si suggeriscono modelli e metodologie per implementare DDA automatizzate. Il
concetto di dipendenza  e denito in [SJT02] come
A linkage or connection between two infrastructures, through which
the state of one infrastructure inuences or is correlated to the state of
the other
1
Nella teoria dei sistemi, un modello black-box  e un sistema che, similmente ad una scatola nera,
 e descrivibile solo per come reagisce
1
1.1. MOTIVAZIONI
ovvero, un legame fra componenti, in cui lo stato di uno inuenza lo stato dell’altro.
In [SJT02] sono identicati quattro tipi di dipendenze: siche, cyber, geograche
e logiche. Nel caso dei sistemi distribuiti, ne risalta una in particolare: la cyber
dipendenza. Questo tipo di dipendenza caratterizza lo stato di un sistema, in
funzione delle informazioni scambiate al suo interno (traco di rete).
Ci o che  e interessante, ai ni di questo lavoro,  e lo studio qualitativo e quanti-
tativo dell’interconnessione fra i componenti di un sistema distribuito, cercando
di evidenziare quelle situazioni di dipendenza che potrebbero mettere il sistema a
rischio.
1.1 Motivazioni
Automatizzare l’analisi delle dipendenze signica attuare delle tecniche di rile-
vazione tali da osservare un sistema e descriverne le dipendenze, operando
in totale autonomia verso chi lo amministra o lo utilizza. La sda, in questi ultimi
anni, consiste nella denizione di metodologie black-box, basate cio e su informazioni
rilevate a run-time ed indipendentemente dalla conoscenza o meno della struttura
del sistema. Ovviamente, tali metodi trovano un campo di impiego pi u ampio e aiu-
tano a scoprire quelle dipendenze non note, anche qualora si conoscesse la struttura
del sistema.
La scelta di implementare un tool automatizzato di rilevazione  e motivata dal
continuo interesse che questa disciplina ha visto crescere negli anni, avvicinandosi
a tematiche di sicurezza e gestione del rischio: la protezione di un sistema  e
un’attivit a che deve considerare sia le potenziali minacce esterne, con strumenti
tradizionali che ne proteggono il perimetro (rewall, Intrusion Detection System,
De-Militarized Zone), sia quelle interne (incompatibilit a, failure, cambiamenti) con
strumenti di analisi che ne studiano lo stato e ne traggono modelli di funzionamento.
I due tipi di minaccia sono in grado di causare dicolt a, malfunzionamenti o fai-
lure di sistema: un attacco hacker pu o avere le stesse conseguenze di una failure
che si origina localmente e si propaga con elevata velocit a , poich e sviluppatasi
su un nodo dal quale dipendono migliaia di altri nodi. Capire lo stato delle dipen-
denze aiuta a scoprire le vulnerabilit a di un sistema, costituendo una solida base per
anticipare, prevenire e/o intervenire su failure di livello globale.
Uno dei problemi, in caso di failure, spesso consiste nel capire l’origine di un
guasto, partendo da osservazioni periferiche o report generali. Con un grafo delle
2
1.1. MOTIVAZIONI
dipendenze questo  e possibile e semplice: analizzando quegli elementi che sono sta-
ti maggiormente danneggiati,  e possibile risalire dalla conseguenza alla causa,
applicando semplici regole della teoria dei gra.
Le infrastrutture critiche, come i sistemi di controllo o di distribuzione, sono
ormai altamente informatizzate e si compongono di migliaia di nodi che collabo-
rano per garantire la funzionalit a dell’intero sistema. Si parla di infrastrutture di
livello nazionale o regionale che coprono i pi u svariati ambiti ( utility, trasporti,
industria), a cui  e richiesto un altissimo livello di adabilit a e continuit a nel
funzionamento.
Se il sistema (informatico) di controllo fallisce, l’eetto pu o essere esteso e ca-
tastroco: mancate forniture, incidenti, perdita di produzione. La DDA aiuta a
connare queste problematiche, permettendo di individuare e gestire quel sottoin-
sieme di elementi da cui sia il sistema di controllo, che l’intera infrastruttura non
possono prescindere.
Grandi aziende, come IBM, HP o Microsoft, hanno speso considerevoli risorse
nella ricerca in questo campo, rilasciando prodotti di gestione (IBM Tivoli [IBM],
su tutti) per semplicare la visione di un amministratore di rete in relazione alle
interdipendenze nel sistema.
In letteratura si trovano moltissime soluzioni, teoriche o metodologiche, per con-
durre DDA di vario tipo, partendo da considerazioni e rappresentazioni diverse di
un sistema distribuito. Il funzionamento di DeDALO si basa su tecniche discus-
se in diversi articoli, analizzando vantaggi e dicolt a e arrivando a denire una
metodologia basata sull’analisi degli intertempi fra ussi di dati .
Scopo di DeDALO  e implementare una DDA automatizzata con un minimo
contenuto informativo evitando, cio e, di conoscere elementi strutturali come la
topologia, i sistemi operativi o i middleware in esecuzione. DeDALO acquisisce i
tracciati di rete scambiati nel sistema, in accordo con la denizione di [SJT02], e li
studia, cercando correlazioni fra ussi di dati , per valutare il grado di dipendenza
fra coppie di elementi.
Un’analisi basata sul traco, permette di non considerare la complessit a o l’ete-
rogeneit a dei vari sotto-sistemi (OS diversi, macchine virtuali, contesti applicativi),
in quanto si considera un elemento, come il traco IP, che  e denito nella sua
sintassi in maniera standard e univoca.
I contributi che questo lavoro apporta sono:
1. uno studio approfondito della letteratura sui modelli di DDA
3
1.2. ORGANIZZAZIONE DELLA TESI
2. l’identicazione degli approcci pi u appropriati
3. la progettazione di un framework basato sull’approccio descritto in [CZMB08]
4. la denizione di una metrica di dipendenza fra gli elementi individuati
5. la progettazione di un ambiente di simulazione per validare il framework
6. l’implementazione, valutazione e validazione del framework di DDA
1.2 Organizzazione della tesi
La tesi sar a organizzata in 7 capitoli:
 Nel capitolo 2  e descritta in dettaglio la problematica del Dependency
discovery, motivando la necessit a di automatizzare il processo e descri-
vendo alcune soluzioni disponibili. Viene, quindi, introdotta la soluzione alla
base di DeDALO, motivandone la scelta e descrivendo in dettaglio i punti di
forza, rispetto a prodotti commerciali o descritti in letteratura.
 Nel capitolo 3 viene presentato l’approccio scelto per denire DeDALO .
Saranno descritte le modalit a con cui osservare il sistema, valutare gli eventi
d’interesse ed analizzarli per estrarre le dipendenze.
 Nel capitolo 4 si descrive la struttura applicativa di DeDALO. Saranno
presentati gli elementi di cui si compone, gli algoritmi e le singole funzionalit a,
descrivendo come operano ed interagiscono per attuare la DDA.
 Nel capitolo 5 viene presentato l’ambiente di simulazione sviluppato per
testare DeDALO. Saranno illustrate le modalit a con cui condurre simulazioni
per analisi DDA. Sar a poi descritto l’ambiente di simulazione, introducendo
NS3 [Lac10], i modelli protocollari sviluppati e un’interfaccia graca per la
generazione di topologie.
 Nel capitolo 6 sono presentati i risultati dell’esecuzione di DeDALO
su scenari applicativi simulati. Si utilizzer a una stessa topologia, di medie
dimensioni, per eseguire alcune rilevazioni su applicazioni distribuite di diversa
complessit a. Tali scenari saranno descritti in forma di workow, denendo i
servizi utilizzati e le modalit a con cui accedervi.
 Il capitolo 7 chiude questo lavoro con conclusioni e riessioni su sviluppi
futuri.
4
Capitolo2
Le dipendenze nei sistemi
distribuiti e reti
In questo capitolo viene descritta in dettaglio la problematica del dependency
discovery in sistemi distribuiti, motivando la necessit a di automatizzare il processo
e descrivendo alcune soluzioni disponibili. Viene, quindi, introdotta la soluzione alla
base di DeDALO, motivandone la scelta e descrivendo in dettaglio i punti di forza
rispetto a prodotti commerciali o descritti in letteratura.
2.1 Problematica
Le grandi infrastrutture di rete sono composte da migliaia di elementi, che ope-
rano ed interagiscono all’interno di ambiti applicativi distribuiti. Le componenti
di un’applicazione sono dislocate su diversi nodi, i quali orono e fruiscono di servizi
comunicando attraverso la rete. Lo scambio di dati che ne  e alla base, lega fra loro
gli elementi del sistema, determinando schemi di dipendenza fra nodi o servizi
software.
La ricostruzione di tali schemi, Dependency Discovery,  e fondamentale per com-
prendere meglio il funzionamento del sistema e individuare gli elementi critici/-
strategici da cui non pu o prescindere. Una cattiva conoscenza del sistema, in tal
senso, rende il sistema stesso vulnerabile a congestioni e malfunzionamenti, dovuti
a cattive decisioni in materia di adeguamenti, sia infrastrutturali (server, router o
collegamenti di rete), che software (componenti di applicazioni distribuite).
Al contrario, una chiara visione delle interdipendenze, fa emergere quegli ele-
menti che, ad esempio, necessitano di pi u risorse, strutture di replicazione o migliore
5
2.2. DIPENDENZE
connettivit a. Un esempio, nel caso di un sistema distribuito,  e dato dalla relazione
fra applicazioni WEB e il DNS: una failure sul DNS pregiudica l’intera attivit a
dell’applicazione WEB, limitando le prestazioni dei servizi oerti. Analogamente,
il DNS  e legato al routing, poich e se un router perde, o instrada in maniera non
corretta, i pacchetti rende inaccessibile il DNS.
2.2 Dipendenze
Lo studio delle dipendenze nei sistemi distribuiti,  e stato inquadrato in diversi
lavori come un’analisi volta a caratterizzare l’interconnessione, e lo stato degli ele-
menti, in funzione dei dati che essi scambiano. In articoli di rilievo, come [SJT02],
la dipendenze in sistemi distribuiti, sono dette cyber dipendenze, aermando che
An infrastructure has a cyber interdependency if its state depends on
information transmitted through the information infrastructure
Volendo dare un valore meno astratto alla denizione data in [SJT02], si pu o denire
il concetto di dipendenza fra un elemento A e un elemento B, come la necessit a, da
parte di B, di fruire dei servizi di A per fornire a sua volta un servizio o completare
l’esecuzione di un task. La relazione  e detta di interdipendenza se  e bidirezionale,
ovverosia se i due elementi sono mutuamente dipendenti.
Quindi, la dipendenza fra due servizi  e una formalizzazione codicata della ne-
cessit a di fruire di un servizio S1 per poter accedere ad un servizio S2
Il concetto di cyber-dipendenza (d’ora in poi espressa come dipendenza)  e
strettamente correlato a un’infrastruttura ICT, come un sistema distribuito. Com-
prendere la struttura di tali sistemi  e fondamentale per caratterizzare sia le dipen-
denze che le metodologie per rilevarle. L’infrastruttura di un sistema distribuito
pu o essere descritta attraverso tre livelli architetturali: livello sico, livello di rete
e livello applicativo.
Ogni livello  e caratterizzato da funzionalit a speciche, hardware e/o software,
permettendo ai livelli superiori, o all’utente di fruire di servizi di vario genere. I
sistemi di interesse, in questa tesi, sono quelle infrastrutture basate su protocollo IP
(Internet), i cui livelli caratteristici riettono la struttura dello stack TCP/IP:
 Livello applicativo
 Livello IP (rete, routing, trasporto)
6
2.2. DIPENDENZE
Figura 2.1: Dipendenze fra i livelli di un sistema distribuito
 Livello sico (datalink, connetivit a)
all’interno del livello applicativo si ritrovano dei servizi di supporto, come il na-
ming (DNS), l’identity mangement (Kerberos) e la gestione di rete (ICMP), che
fungono da collegamento fra il livello applicativo e i livelli sottostanti. Ogni li-
vello si compone di elementi hardware e/o software che interagiscono scambiando
informazioni e servizi. E’ possibile inquadrare le entit a caratteristiche di un sistema
distribuito all’interno di ognuno dei tre livelli:
 Applicazioni software: WEB, DNS, DBMS.. (Livello applicativo)
 Router (Livello IP)
 Canali di comunicazione (Livello sico)
L’interazione fra elementi di uno stesso livello determina delle relazioni infra-livello,
ad es., strutture SOA, o protocolli di routing. L’interazione fra elementi di livelli di-
versi  e detta inter-livello, ad es. risoluzione di indirizzi IP (DNS) per accedere a un
7