1. Soluzioni attuabili



    1. Piattaforma di analisi: Linux Bridge



Trattandosi di una CAMPUS NETWORK (rete universitaria), non si sono potute applicare quelle soluzioni comuni ad una rete aziendale.

Inoltre gli apparati di trasmissione critici, cioè il router Cisco 2600 e lo switch Cisco catalyst 5000, sono di possesso del citicord.

Non appartenendo alla facoltà di ingegneria e non avendo ricevuto autorizzazioni a all' uso degli strumenti di manutenzione di questi apparati, si è dovuto aggirare il problema analizzando e intervenendo sul traffico prima che quest' ultimo arrivi sugli apparati citicord.

Questo è molto utile ai fini applicativi inquanto, nella stragrande maggioranza dei casi, la compagnia di telecomunicazioni che fornisce connettività ad una azienda, non permette l'accesso al controllo degli apparati finali di trasmissione/ricezione.

Questo lavoro dunque, aiuta tutte quelle realtà a controllare e modellare il traffico in ingresso/uscita alla propria LAN.



    1. Soluzioni Passive: monitoraggio e weatherMap

Al fine di rendere visibile il traffico generato/introdotto ai vari dipartimenti e/o locali della facoltà, abbiamo cominciato realizzare una mappa globale dello stato di salute della facoltà.

Abbiamo cioè ripreso e ampliato localmente il lavoro cominciato, a livello nazionale, dal GARR e visivile agli indirizzi:

http://www.noc.garr.it/mappe/backbone.shtml

http://www.noc.garr.it/mappe/romaRTG_01.shtml

http://www.noc.garr.it/mrtg/RTG_ROMA.garr.net/rtg-uniromai.rm.garr.net.html

La mappa disegnata ricalca la situazione presente in facoltà.


Dallo switch Catalyst500, centro stella del traffico di facoltà, partono 16 link in fibra ottica verso gli switch dipartimentali. I link rappresentati in figura cambiano colore in maniera proporzionale alla quantità di traffico in ingresso/uscita. Cliccando sul rettangolo [BANCA], e possibile vedere il dettaglio (tramite MRTG) del traffico visto dal relativo switch.La difficoltà di reperire collaborazione da parte dei singoli direttori di dipartimento e/o responsabili di quell' apparato, non ha permesso il completamento del lavoro. Lo sco

po sarebbe quello di rendere navigabile l' intera mappa.L' implementazione di tal tecnologia si basa su un plug-in chiamato rdlog e compreso nella sistribuzione di MRTG.

Al fine di creare la weatherMap, ad intervalli regolari (abbiamo utilizzato un cron di 5 minuti) rdlog legge i file generati da MRTG relativamente al traffico dello switch centro stella ed inoltre legge una mappa vettoriale da me disegnata.

Tale mappa è in formato fig, un formato vettoriale che utilizza file in plain text per la descrizione del disegno. Lo strumento utilizzato per la sua creazione è xfig [http://www.xfig.org]

Rdlog genera una immagine gif che resta a disposizione del web server per la sua visualizzazione.Nel disegno vettoriale è possibile specificare della aree considerate linkabili. E' possibile cioè linkare ogni rettangolo, che rappresenta un dipartimento sulla mappa, ad un ulteriore mappa o grafico MRTG che si riferiscano al dipartimento selezionato.



      1. Scelta del tool del TOP HOST

Come visto nel capitolo 3, esistono numerosi tools che possano tenere una lista ordinata degli host che generano/ricevono più traffico.

Le caratteristiche richieste sono

Ntop è un validissimo programma anche nella sua versione testuale InTop.

Purtroppo, allo stato attuale, Ntop risulta instabile quando esposto a grossi carichi di lavoro. Pere un esempio, Ntop utilizzato sul transparent bridge ed esposto al carico della facoltà di ingegneria (circa 1500 host), satura il processore e la memoria della macchina dopo appena 3 minuti di uso.Stesso discorso vale per InTop.

IpTraf si è dimostrato molto più stabile. Purtroppo la scelta delle librerie di sniffing non basate sulle standard libpcap non permette di utilizzare il bridge br0 come interfaccia di sniffing. Inoltre il sistema di visualizzazione è poco flessibile e non è possibile esporta la lista di host.

Queste circostanze unite alla curiosità di avere un riscontro oggettivo sulla correttezza delle misure dei programmi menzionati, mi ha spinto allo sviluppo di un software estremamente compatto hostMisure

Il programma esegue un parsing dell' output proveniente da tcpdump e mantiene in memoria una lista di N host che generano più traffico.Ogni record della lista ha anche un campo Age, Quando la lista è piena l' introduzione di un nuovo host, elimina quello con maggior Age.La lista viene periodicamente stampata su schermo o su un su un file html.

Il confronto con IpTraf non ha evidenziato differenze di misurazioni tra questi due programmi.

Dal momento che ho sviluppato il software, ho previsto la possibilità di mantenere una lista non su gli host ma sulle porte (appartenenti ad host interni alla facoltà) che generano più traffico.Mi riferirò a questo software con il nome di portMisure





    1. La soluzione per riconoscere il traffico generato dai p2p: le fingerPrint

Lo studio dei protocolli dei p2p mi ha portato alla conoscenza degli HEADERS di risposta di questi programmi.Utilizando questa caratteristica, sono stato ingrado di scrivere un algoritmo che permette di stabilire se su un host è in esecuzione un peer to peer e se se ne faccia un uso eccessivo di quest' ultimo.

L' algoritmo di base è:

  1. trovato un host H1 che genera molto traffico

  2. supposto che la porta sorgente maggiormente utilizzata da quel p2p sia la porta P1

  3. provare una connessione all'host H1 sulla porta P1. Se risponde, confrontare la sua risposta con le figerPrint conosciute.

  4. Se non risponde, provare sulle porte standard dei p2p.

  5. Se non risponde, ripetere il procedimento con il peer H2

Il p2pFinder dunque non analizza gli host (punto 1) che, nonostante abbiano in esecuzione un peer to peer, limitino la banda in uso.In questo modo si da comunque la possibilità di utilizzo del peer to peer.Il p2pFinder crea infine una BLACKLIST contenente gli host segnalati.Gli indirizzi contenuti in tale lista possono essere oggetto di provvedimenti successivi (shaping, blocking etc.. etc..)



    1. Soluzioni Attive: Blocking and Shaping

L' uso del transparent Bridge, ha permesso l' analisi e modifica del traffico in real-time.L' importanza di tale sistema è che sarà possibile implementare qualsiasi tipo di soluzione di Traffic Controlling semplicemente aggiungendo software e regole al Linux Bridge.

Inolte il transparent Bridge insieme al traffic Shaping rappresentano un ambiente di test e controllo del traffico.

La facoltà di ingegneria non offre ad utenti esterni particolari servizi web. Eccetto qualche web server che fornisce informazioni sui corsi e attività didattica/ricerca, l' unico servizio che dovrebbe fare un intenso uso della banda in uscita è la trasmissione di contenuti multimediali in multicast.

Dai grafici di MRTG invece si vede che la banda in uscita viene pesantemente sfruttata nelle ore diurne, superando la banda in entrata nelle ore notturne.

Il fatto che il traffico medio, nell' ultimo anno, sia stato del 44,6 % delle possibilità dell' infrastruttura contro il 29,2% di quello in ingresso, ci fa comprendere quanto sia importante limitare l' outgoing traffic.




      1. Blocco delle porte più trafficate

Un primo metodo atto alla risoluzione del problema consiste nel bloccare le porte utilizzate dai p2p per lo scambio dei dati.

Utilizzando il programma portMisure sul transparent bridge, ad intervalli regolari ho controllato, tramite il p2pFinder, le porte in testa alla lista.

Quelle che risultavano coinvolte su flussi di dati di filesharing sono state interdette.

Il sistema di blocco interessa l' Upper layer che nega il forwarding all' altra interfaccia del bridge.


Il comando utilizzato è:

iptables -A FORWARD -p tcp –source-port N -j DROP

con tale comando, si mette una regola nella tavola di FORWARDING che elimina (-j DROP) il traffico che ha come porta sorgente la numero N.

Tale metodo è efficace contro i p2p a porte fisse ma quasi inutile per i p2p a porte variabili.

Quest' ultimi infatti, dopo un tempo relativamente breve, non riuscendo più a comunicare con il network del relativo p2p, negoziano una porta alternativa.

Se si procede per questa strada, bloccando di volta in volta tutte le porte utilizzate dal p2p, si arriva ad un numero incredibilmente alto di porte chiuse.Al limite i p2p si assestano su porte associate a servizi leciti come HTTP (porta 80) SMTP (porta 25) FTP (porta 21) etc...

In questo modo risulta impossibile fermare il p2p senza chiudere il relativo servizio.

Riporto in appendice A l'uso di tale metodo applicato al filesharing GNUTELLA.


      1. Shaping su base porte

Lo shaping, cioè il modellamento della banda, risolve due grossi problemi introdotti con i blocchi coatti di porte o IP.

Poiche ci troviamo in una CAMPUS NETWORK, non possiamo deliberatamente mettere in una coda di shaping a bassa priorità tutte quelle applicazioni che utilizzano le porte NON STANDARD (per una lista delle porte definite STANDARD si veda http://www.iana.org/assignments/port-numbers).

Essendo l' università un luogo di ricerca e sviluppo, bisogna garantire piena funzionalità anche a chi utilizzi o generi network applications proprietarie che facciano uso di porte non standard.

Il problemi all'applicazione di tale metodo sono:

  1. 1) i p2p posso canalizzarsi su porte istituzionali (http,ftp etc..) il cui traffico non può essere accodato

  2. ) nonostante l'alto numero 'casuale' di porte utilizzate dai p2p, non è possibile generalizzare un insieme di porte sul quale applicare lo shaping.


      1. Shaping su base IP


Grazie alla realizzazione del software p2pFinder, abbiamo la possibilità di analizzare (sniffing) il flusso di dati sul transparent bridge e capire quali host stanno utilizzando un p2p.I flussi di dati di questi ultimi host vengono incanalati su code a bassa priorità.

Con questo metodo si sfruttano i pregi delle due soluzioni precedenti:

  1. ) lo shaping non influenza tutto il traffico di facoltà ma è limitato a coloro facciano diretto uso di un filesharing

  2. )Non bloccando le porte, gli utenti possono comunque disporre di uno strumento di scambio distribuito.

  3. ) E' possibile automatizzare il processo mantenendo una blacklist dei p2p trovati.






5