Il nome che si è deciso di dare alla soluzione descritta nelle sezioni precedenti è PySolv.
Quello che verrà esposto di seguito riguarda la gestione dei vari sottoprocessi all’interno di OVX e di PySolv, eseguiti in modo concorrente al normale funzionamento di OVX.
4.3. PYSOLV 61 Gestione e comportamento dei thread in OVX
Come già detto in precedenza, all’interno di OVX si è agito sulla classe PhysicalSwitch.java che rappresenta gli switch fisici della rete. Oltre al normale funzionamento di questa classe, si sono creati due thread: il primo per gestire lo scambio di informazioni con PySolv ed il secondo per inviare al relativo switch fisico il FlowMod. Il primo thread che si crea è chiamato InitConnectionThread ed ha la funzione di instaurare la connessione con PySolv. Più in particolare lo scambio iniziale che avviene tra questo thread e PysSolv è il seguente:
InitConnectionThread PySolv
Connect to PySolv (port 5500) Send "Port"
Return: port number toconnect (N) Connect to port N
InitConnectionThread close first connection
Inizialmente il thread si connette ad una porta prefissata di PySolv (5500 in questo caso), invia la stringa “Port” e PySolv risponde con un numero intero a quattro cifre contenente il numero di porta esclusivo per quel particolare switch. Infine il thread si connette a questa porta e, da questo punto in poi, restituisce la socket già connessa che PhysicalSwitch utilizzerà per comunicare direttamente con PySolv. Tutto questo avviene mentre l’intero sistema esegue il suo normale comportamento. Quindi, ogni volta che un PhysicalSwitch viene creato, si crea anche un InitConnectionThread con il compito di instaurare una connessione affidabile con PySolv. Creata quest’ultima, il thread viene terminato.
Una volta stabilita la connessione con PySolv sulla nuova porta, è possi- bile inviare tutti i pacchetti FlowMod che PhysicalSwitch invia agli switch fisici, anche verso la soluzione. OpenVirteX utilizza la nuova connessione che
InitConnectionThread restituisce, per inviare dati a PySolv. La struttura del messaggio è stata discussa nella Sezione 4.2. Sempre all’interno della classe PhysicalSwitch è presente il metodo sendMsg(...); questo metodo è utilizzato per inviare i pacchetti che arrivano dalla nortbound verso il piano dei dati. Quindi, se è presente la connessione con PySolv, ogni volta che il funzionamento standard della tecnologia invoca questo metodo, viene generato anche un flusso di informazioni verso l’esterno per fare in modo che venga controllato.
Tutte le volte che PySolv rileva un individuo da intercettare, crea un JSON da restituire a OVX contenente tutti i campi necessari per generare il FlowMod. Quest’azione di ricezione da parte di OVX viene fisicamente effettuata da un altro thread denominato InputStreamThread. Esso ha il compito di gestire tutti i dati che provengono da PySolv in modo da non interferire con il comportamento standard di OVX. L’ultima azione che esegue InitConnectionThread prima di terminare è creare questo thread. Ciò viene fatto in modo da consegnare a InputStreamThread la socket già connessa verso PySolv. Successivamente quello che avviene è descritto nella seguente immagine:
PhysicalSwitch.sendMsg(..) PySolv InputStreamThread
send packets
PySolv detects suspicious character
send info for FlowMo d
InputStreamThread generate FlowMod
• Tutte le volte che un pacchetto FlowMod sta per essere inviato al rispettivo switch fisico, il metodo sendMsg(...) invia anche una copia di questo pacchetto (con anche altre informazioni), verso PySolv.
4.3. PYSOLV 63 – Nel caso in cui queste informazioni non siano di interesse per gli scopi di controllo, allora non viene restituito nulla al InputStreamThread. – Nell’altro caso invece, PySolv crea un JSON da restituire al thread
con tutte le informazioni per intercettare il traffico.
• PySolv risponde al InputStreamThread nel caso in cui ci sia da generare un pacchetto FlowMod da inviare allo switch. In questo caso è stato creato un metodo apposta per generarlo chiamato createFlowMod(...)4.
Gestione e comportamento dei thread in PySolv
Dal lato di PySolv, il comportamento tenuto è il seguente. Dopo che è stata fatta partire la soluzione, le viene assegnato un indirizzo locale su una determinata porta per rimanere in attesa che qualcuno si connetta. Come già discusso in precedenza, all’interno di OVX è presente il thread InitConnectionThread, il quale si connette a questa porta per ricevere un altro numero di porta a cui successivamente si andrà a connettere per proseguire il funzionamento del sistema. PySolv gestisce ogni connessione attraverso la creazione di un thread, ogni volta che un InitConnectionThread richiede la porta alla quale connettersi successivamente. In questo modo tutti i thread che vogliono connettersi a PySolv vengono reindirizzati su una porta diversa, gestita da un thread separato ed eseguito in modo concorrente a tutti gli altri.
4Successivamente sono stati creati diversi metodi da utilizzare nella gestione di una particolare tipologia di pacchetti. Per maggiori informazioni si veda la Sezione 4.4
InitConnectionThread PySolv Thread Connect to port 5500
Send "Port"
Port number to connect(N)
PySolv create Thread
Connect to port N
InitConnectionThread close first connection
Quindi tutti i futuri scambi di informazioni avvengono tra questo il nuovo thread interno a PySolv, InputStreamThread che riceve dati da quest’ultimo e PhysicalSwitch (attraverso il metodo sendMsg(...)).
4.3.1
Come avviene l’intercettazione
Per fare in modo che i flussi appartenenti ad un host vengano intercettati si ha bisogno di un dispositivo (chiamato sniffer ), che li riceva e li elabori. La parte dell’elaborazione dei flussi esula da quello che è lo scopo della tesi ma, per completezza, si è deciso di fornire una soluzione per lo sniffer adibito all’intercettazione. Quest’ultimo deve essere un dispositivo connesso alla rete (in modo che riceva tutti i pacchetti del flusso), ed il suo indirizzo deve essere noto a PySolv. Questo perché è proprio PySolv che invia ad OVX tutti i dati per poi creare il FlowMod e, fra questi dati, ci deve essere anche l’indirizzo dello sniffer. Per implementare ciò, colui che andrà ad agire sull’infrastruttura per fare in modo che i dati vengano replicati, dovrà essere a conoscenza di tutti gli indirizzi degli host e di tutte le loro connessioni con i vari switch. Questo perché si fornisce a PySolv un file di configurazione (config.json) dentro al quale sono presenti tutte le informazioni per i dispositivi che devono ricevere i dati intercettati di tutte le virtual networks.
I campi principali di questo file di configurazione e riguardanti gli sniffer sono:
4.4. CASO DI STUDIO 65