1. Strumenti di controllo



    1. Transparent Bridge



Un bridge è un device che, lavora al livello 2 della scala ISO OSI e basa il suo funzionamento esclusivamente sull' indirizzo fisico dei pacchetti dati. Il suo compito è riportare tutto il traffico in entrata su un'interfaccia, come traffico uscente da tutte le altre interfacce coinvolte nel bridge.

Il nostro particolare interesse verso l' utilizzo di un bridge, si deve al fatto che è possibile modificare il codice del bridge e farlo funzionare in modalità fire-walling.

E' importante capire che un bridge non è ne un router ne un firewall ma, insieme a ip forwarding, è possibile utilizzare delle 'regole' per modificare il traffico in transito sul dispositivo.

Un bridge può anche essere usato per adattare delle incompatibilità hardware tra interfacce 10BaseT e 100BaseTx.

Regole principali di bridging

Esistono delle regole che un bridge è costretto a seguire:

Esistono situazioni percui è necesario avere un IP associato al bridge. Si pensi ad esempio al caso in cui il bridge è utilizzato per aver statistiche sui pacchetti che ne transitano e/o si usino interfacce (GUI) web per la visualizzazione oppure ancora servizi tipo telnet ssh etc...



Il codice del kernel Linux per il bridge

Il bridge funziona in kernel-space e dunque va compilato nel kernel o utilizzato come modulo.Al momento in cui scrivo questo HOWTO, il kernel stabile di Linux è il 2.4.20.Tutto ciò che segue è stato testato su distribuzioni Red Hat 7.0/7.2 e 8.0.I kernel successivi al 2.2 (dal 2.4 e successivi) non hanno bisogno dell a patch perchè il codice è già integrato nell' archivio.Tuttavia è necessaria una patch per l'utilizzo del bridge firewalling (solo con iptables).In APPENDICE B è riportata l' installazione e configurazione del Linux Bridge anche in modalità firewalling.



    1. Traffic Shaping



      1. Concetti

Traffic Shaping è un generico termine assegnato ad una moltitudine di tecniche atte a sviluppare politiche di prioritizzazione del traffico di dati in una rete.

La maggiorn parte degli utenti di una rete hanno, prima o poi, sperimentato la frustrante esperienza della latenza e accodamento dei dati della rete internet.

Chi ha usato servizi come telnet o ssh su un collegamento lento come un dial-up PPP o SLIP, ha visto gli effetti che il file transfer ha sul traffico interattivo.

Il file transfer (download o uploda che sia) divora facilmente le risorse di larghezza di banda costringendo il servizio interattivo ad un lungo accodamento in attesa di uno slot libero prima di poter trasmettere.

Il problema è causato per il fatto che il flusso dei dati del file transfer ha uguale priorità rispetto a quello del servizio interattivo.

Il traffico è regolato da una coda FIFO (First In, First Out).

Il Traffic Shaping ci permette di implementare una specifica politica che altera il meccanismo secondo cui vengono accodati i dati in trasmissione.

E' necessario a questo punto chiarire che una politica di shaping può essere applicata solo al traffico in uscita da un' interfaccia.

Il traffico in arrivo, nel momento in cui è giunto all' interfaccia, ha ormai irrimediabilmente occupato una certa banda di trasmissione e non è piu possibile operare alcun incodamento straordinario.

Questo però non significa che sia impossbile modellare il traffico in download verso la nostra interfaccia.



      1. La struttura del kernel e i comando per il controllo del traffico

Linux offre un ricco set di funzioni per il controllo del traffico come i comandi tc , iptables , iproute e così via i quali si appoggiano su una struttura definita nel kernel del sistema operativo.

Cerchiamo di definire in che modo vengono elaborati i pacchetti all'interno delle macchine linux.

A livello più alto possibile possiamo immaginare una situazione come quella di figura:






La figura mostra come il kernel processi i dati ricevuti dalla rete e come esso possa generare nuovi dati che dovranno essere spediti sulla rete : i pacchetti entranti possono sia essere reindirizzati immediatamente sulla rete ( magari su diverese interfacce nel caso di un router ), sia essere passati al livello superiore della pila protocollare ( come ad esempio un protocollo di trasporto ) per essere processati.

Il Forwarding include la selezione dell'interfaccia di uscita , la selezione del prossimo salto, l'incapsulamento e così via. Una volta fatto questo i pacchetti sono accodati sulle rispettive interfacce dove vigeranno le discipline di accodamento per la gestione del traffico.



      1. Iproute2

Volendo esplorare più in profondità il problema cominciamo con l'analizzare il blocco denominato input de-multiplexing. Al suo interno possiamo immaginare la routing table relativa ai pacchetti provenienti dall' esterno e che devono essere reindirizzati . Il pacchetto per la gestione dell' indirizzamento è iproute2.

Questo risulta essre uno strumento molto flessibile e completo in quanto è possibile definire più tavole di routing da consultare a seconda della sorgente del pacchetto, della destinazione o semplicemente dell'utente che richiede l'utilizzazione della risorsa. Tra la miriade di comandi disponibili quelli di cui ha più senso parlare in questa sede sono:



      1. Traffic controller TC

Vediamo di analizzare ora la parte e di gestione della coda di uscita. Volendo comprendere più in profondità il controllo di traffico cominciamo ad introdurre i concetti chiave tramite i quali il kernel di Linux ragiona:

  1. Queuing discipline

A ogni dispositivo di rete può essere associata una disciplina di accodamento che effettua uno scheduling dei pacchetti in ingresso . Di default questa disciplina è una semplice FIFO.

  1. Classes

Le classi servono a definire le varie tipologie di traffico.Ogni classe e padrona di una coda la quale di default è una FIFO. Quando la disciplina di accodamento è chiamata questa applica i filtri per determinare la classe alla quale il pacchetto appartiene .

  1. Filters

I filtri si occupano di smistare il traffico nelle diverse classi . Il concetto di filtro è molto più libero di quella di classe , infatti più filtri possono essere associati alla stessa classe e quindi alla stessa coda.




      1. Tc qdisc

[root@virgo root]# tc qdisc help

Usage: tc qdisc [ add | del | replace | change | get ] dev STRING

[ handle QHANDLE ] [ root | ingress | parent CLASSID ]

[ estimator INTERVAL TIME_CONSTANT ]

[ [ QDISC_KIND ] [ help | OPTIONS ] ]


tc qdisc show [ dev STRING ] [ingress]

Where:

QDISC_KIND := { [p|b]fifo | tbf | prio | cbq | red | etc. }

OPTIONS := ... try tc qdisc add <desired QDISC_KIND> help


Con questo comando è possibile creare, cancellare, rimpiazzare o semplicemente cambiare qualche parametro a una disciplina di accodamento ( qdisc ).Non prenderemo in considerazioni le qdisc classless.



      1. Tc filter

[root@atlantide proj]# tc filter help

Usage: tc filter [ add | del | change | get ] dev STRING

[ pref PRIO ] [ protocol PROTO ]

[ estimator INTERVAL TIME_CONSTANT ]

[ root | classid CLASSID ] [ handle FILTERID ]

[ [ FILTER_TYPE ] [ help | OPTIONS ] ]


tc filter show [ dev STRING ] [ root | parent CLASSID ]

Where:

FILTER_TYPE := { rsvp | u32 | fw | route | etc. }

FILTERID := ... format depends on classifier, see there

OPTIONS := ... try tc filter add <desired FILTER_KIND> help


I filtri sono gli oggetti che effettivamente smistano il traffico. Sono in grado di guardare dentro il pacchetto il campo dell'header che contiene le informazioni discriminatorie e di associare al pacchetto la classe corrispondente o semplicemente il ramo corrispondente x:y di un albero.

Approfondiamo il filtro u32:

Basa la sua decisione sul confonto con un ben specificato campo allinterno dell'header ip del pacchetto.

Usage: ... u32 [ match SELECTOR ... ] [ link HTID ] [ classid CLASSID ]

[ police POLICE_SPEC ] [ offset OFFSET_SPEC ]

[ ht HTID ] [ hashkey HASHKEY_SPEC ]

[ sample SAMPLE ]

or u32 divisor DIVISOR

Where: SELECTOR := SAMPLE SAMPLE ...

SAMPLE := { ip | ip6 | udp | tcp | icmp | u{32|16|8} } SAMPLE_ARGS

FILTERID := X:Y:Z


Il funzionamento di questo discriminatore non è subito intuitivo e l'help in questo caso non aiuta a mettere chiarezza. Per cominciare ripassiamoci la struttura dell'header ip:




E' possibile , tramite una maschera , specificare un determinato campo dell'header ed il valore che devo confrontare. Ad esempio, volendo guardare nel campo TOS, specificherò gli otto bit corrispondenti in esadecimale come 00ff0000 at 0 (sulla riga 0 ) ed il valore da confrontare. Vediamo un esempio di comando:

# tc filter add eth0 protocol ip parent 1:0 pref 10 u32 \ match u32 00100000 00ff0000 at 0 flowid 1:0

A parte la prima riga la parola chiave è match. Viene specificato di confrontare un valore di riferimento di 32 bit in esadecimale 00100000 con quelli del pacchetto corrispondenti alla maschera 00ff0000 sulla prima riga dell'header così come schematizzato sopra . Se il confronto ha esito positivo si associa il pacchetto al ramo 1:0.


      1. Esempio di Tc

Poniamo di voler suddividere la banda a disposizione (10Mbit) della mia macchina (che poniamo funga anche da router ) come schematizzato:

10% della banda (1Mbit) assegnata al traffico web

30% della banda (3Mbit) assegnata al traffico telnet

60% della banda (6Mbit) assegnata al traffico rimanente

Aggiungiamo lo acheduler delle classi CBQ all'interfacia eth0:

# tc qdisc add dev eth0 root handle1: cbq bandwhidth 10Mbit avpkt 1000

quindi creiamo l'albero delle classi .Prima la classe radice:

# tc class add dev eth0 parent 1:0 classid 1:10 cbq bandwidth 10Mbit rate 10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000

Quindi le sottoclassi:

# tc class add dev eth0 parent 1:10 classid 1:11 cbq bandwidth 10Mbit rate 1Mbit allot 1514 weight 100kbit prio 5 maxburst 2o avpkt 1000

# tc class add dev eth0 parent 1:10 classid 1:12 cbq bandwidth 10Mbit rate 3Mbit allot 1514 weight 100kbit prio 5 maxburst 2o avpkt 1000

# tc class add dev eth0 parent 1:10 classid 1:13 cbq bandwidth 10Mbit rate 6Mbit allot 1514 weight 100kbit prio 5 maxburst 2o avpkt 1000



Ora dobbiamo associare le tre tipologie di traffico alle tre classi create. Dobbiamo quindi dichiarare tre filtri , uno per ogni flusso, che catturino i pacchetti che gli competono. I filtri come abbiamo visto guardano alcuni campi dell'header settati opportunamente . Se per esempio poniamo che sia stato settato il campo fw a 1 per il traffico http ,a 2 per il telnet e 3 per il resto i filtri dovranno così essere dichiarati:

# tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:11

# tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:12

# tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:13

La prima istruzione ad esmpio ci dice che i pacchetti marchiati 1 fw vengono associati alla classe 1:11.

Ora la questione aperta è capire come possiamo intervenire per marchiare i pacchetti o come intervenire sui campi dell'header per essere parte attiva nella definizione della QoS.

Con questo scopo andiamo a conoscere il comando iptables.

ATTENZIONE: tc tool (non solo HTB) usa sigle per definire le unità di misura di velocità di trasmissione:

kbps significa kilo-Bytes al secondo e kbit significa kilobits al secondo!

Questa è la FAQ più comune circa il tc in linux.


      1. Simple classless queuing disciplines

Come detto, con le queueing disciplines possiamo cambiare il modo in cui i dati vengono trasmessi. Le Classless queueing disciplines possono accettare i dati trasmessi e semplicemente spostarli su una diversa coda, ritardarli o eliminarli.

Vengono usate per effettuare lo shaping dell' intero traffico che insiste su un' iterfaccia di rete enza operare alcuna divisione.



      1. Classful queing disciplines

Classful qdiscs sono molto utili per offire differenti trattamenti a differenti tipi di traffico.

La più diffusa ma anche la più vecchia classful qdiscs è chiamata 'CBQ' , 'Class Based Queueing'.E' purtroppo anche la più complessa e non sempre riesce a soddisfare tutte le esigenze.



      1. CBQ - Class Based Queing

Questa classe permette di sagomare il tipo di traffico che dovrà trattare. Questa qualità si paga con una complessità che è di gran lunga maggiore delle altre qdisc . CBQ è anche lui uno shaper del traffico anche se sotto questo aspetto il suo funzionamento e di volta in volta è da mettere alla prova. Dovrebbe lavorare così:

se abbiamo una banda disponibile d'uscita di 10mbit/s che vogliamo limitare a 1 mbit/s allora lo shaper CBQ lavora in modo tale da lasciare all'interfacia d'uscita libera per il 90% del tempo.

Questo non è molto semplice da misurare e CBQ deriva questo tempo dal numero di microsecondi che passano dal momento della richiesta di dati allo strato hardware.

Questo, sotto certe circostanze, non raggiunge lo scopo.

Per esempio: CBQ fallisce se il driver di una interfaccia non è capace di trasmettere i pieni 100Mb/s su un collegamento 100baseTX.E questo è ciò che succede con una network card di tipo pcmcia a 16bit.

E la cosa può essere ancora peggiore se consideriamo le diffuse interfacce virtuali come PPPoE oppure PPTP over TCP/IP.

L'effettiva larghezza di banda è determinata dall'efficienza della pipe in userspace - che è enorme.

Quindi CBQ lavora in modo tale da essere sicura che il collegamento risulti libero per un tempo opportuno tanto da abbattere il rate trasmissivo fino alla limitazione configurata. Per fare ciò essa calcola il tempo medio,avgidle , che dovrebbe passare tra i pacchetti. Durante le operazioni questo tempo è misurato usando una media mobile esponenziale (EWMA) che considera più importante l'informazione relativa ai pacchetti più recenti. Se il tempo d'arrivo è maggiore di quanto calcolato il collegamento accumula crediti trasmissivi fino ad un tetto massimo mentre se questo tempo d'arrivo previsto è minore la CBQ chiude i battenti per un pò essendo in sovraccarico. In questa situazione la CBQ dovrebbe strozzare il canale per un tempo pari al avgidle calcolato quindi fare passare un pacchetto e richiudelo nuovamente. In realtà questo comportamento è gestito dal parametro maxburst.

Per queste limitazioni e per la mancanza di documentazione ufficiale, non tratteremo approfinditamente CBQ preferendo HTB.



      1. HTB (Hierarchical Token Bucket)

per la teoria vedere[http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm]

Per prima cosa, creaiamo una coda (queuing discipline) su entrambe le interfacce coinvolte nel progetto:

tc qdisc add dev eth0 root handle 1: htb default 10

tc qdisc add dev eth1 root handle 1: htb default 10

Ed ad ciascuna associamo una classe:

tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit

tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit

Sempre per ciascuna interfaccia, creaiamo le classi figlie



tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit

tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit

tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1mbps ceil 1mbps

tc class add dev eth1 parent 1:1 classid 1:11 htb rate 1mbps ceil 1mbps

tc class add dev eth0 parent 1:1 classid 1:12 htb rate 10kbps ceil 1kbps

tc class add dev eth1 parent 1:1 classid 1:12 htb rate 10kbps ceil 1kbps

Adesso creiamo i filtri, per le porte 80 e 110

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0xffff flowid 1:12

tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dport 110 0xffff flowid 1:12


      1. Filters

Per determinare quale classe processerà un pacchetto, il 'classifier chain' è chiamato ogni volta che una scelta deve essere fatta.

Questa chain è costituita da tutti i filtri attaccati alla classful qdisc che deve decidere.

La maggiorparte dei comandi di shaping presentati qui, iniziano con questo prambolo:

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..

Questi, sono detti 'u32' matches, che possono controllare il match su ogni parte del pacchetto.

  1. Corrispondenza su source/destination address

Source mask 'match ip src 1.2.3.0/24', destination mask 'match ip dst 4.3.2.0/24'.

Per controllare la corrispondenza con un singolo host, usere /32, o omettere la subnet mask.

  1. Corrispondenza su source/destination port (IP protocol)

Source: 'match ip sport 80 0xffff', 'match ip dport 0xffff'

  1. Corrispondenza su ip protocol (tcp, udp, icmp, gre, ipsec)

Usare i numeri da /etc/protocols, per esempio, icmp è 1: 'match ip protocol 1 0xff'.

  1. Corrispondenza su fwmark

E' possibile marcare i pacchetti con ipchains/iptables.

Esempio:

# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6

(il numero 6 è arbitrario)

e poi gestire il pacchetto marcato con:

tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1



  1. Corrispondenza sul TOS

To select interactive, minimum delay traffic:

# tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:4

Use 0x08 0xff for bulk traffic.

For more filtering commands, see the Advanced Filters chapter.



      1. U32 Filter

http://lartc.org/howto/lartc.adv-filter.html#LARTC.ADV-FILTER.U32

Questo è il più avanzato tra i filtri oggi disponibili.

E' interamente basato su tabelle hash che lo rendono robusto in presenza di numerosi filtri.

Nella sua forma più semplice, è una sequenza di records, ognuno composto da due campi:

un selettore e una azione.

I selettori sono comparati con il pacchetto IP sotto esame.Quando viene trovata una corrispondenza, viene eseguita l'azione ad esso associata.

La classica azione è quella di redirigere il pacchetto su una classe CBQ.

La sintassi del comando tc filter consiste di tre parti:

#tc filter add dev IF [ protocol PROTO ] [ (preference|priority) PRIO ] [ parent CBQ ]

protocol PROTO = protocollo (sempre IP nei casi che tratteremo)

(preference|priority) PRIO = priorità di processamento

parent CBQ = coda alla quale si attaccherà il filtro

Con U32 invece specifichiamo:

il pattern che andra confrontato con la parte del pacchetto di nostro interesse.

Precisamente si specifica quali bits andranno ad essere confrontati con il packet-header.

Esempio:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 match u32 00100000 00ff0000 at 0 flowid 1:10

Il campo esadecimale 0x00ff0000 rappresenta la 'maschera di confronto' (match mask) e ci indica esattamente quali bits confrontare.

Il comando 'at' significa che il confronto deve essere inziato da un preciso offset (in bytes) -- in questo caso è l' inizio del pacchetto.

In pratica, il filtro confronterà che il flag Type of Service del pacchetto abbia il bit `low delay' settato.

Questi selettori, definiscono il pattern, mask e offset e sebbene si possa confrontare qualsiasi parte dell' header del pacchetto, non sono molto semplici da scrivere o leggere.

La semplicitò di questi selettori, rende più facile la gestione e aumenta la leggibilità degli script di configurazione dei filtri.

Esempio:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 match ip tos 0x10 0xff flowid 1:4

L'esempio precedente, seleziona i pacchetti che hanno il TOS field di valore 0x10.

Prenderemo in considerazione soltanto questo tipo di filtri.


      1. Shaper Device

Per un certo periodo, lo shaper device è stato l' unico sistema di modellamento della banda supportato dal kernel linux. Questo sistema si occupava di limitare tutto il traffico uscente da una interfaccia. Inpratica si re-imposta la velocità di una scheda ethernet indipendentemente dalla sua capacità. Lo shaper device è ancora mantenuto nel kernel ed attivabile selezionando l' opzione Traffic Shaper (EXPERIMENTAL).



      1. Strumenti di amministrazione dello shaping - ll mio contributo al traffic Shaping

In assoluto c'è la mancanza tutta quella serie di programmi che gestiscono e monitorano il Linux Shaping.Per facilitare e velocizzare il lavoro sul traffic shaping, sono stati creati alcuni script perl. I principali sono:

avviaShaping - crea le code HTB e le classi di default a 10Mbit/s

insertClass - inserisce una nuova classe con caratteristiche quali Rate e Ceil

insertFilter - inserisce un filtro con porta da filtrare e classe di destinazione

showClass - mostra tutte le classi legate ad un' interfaccia di rete

showFilter - mostra tutti i filtri legati ad un'interfaccia di rete

showStats - mostra le statistiche di traffico (regola, parent, rate, ceil) su un'interfaccia

showRateCeil - mostra Rate e Ceil di una classe

makeStatus - crea uno stato delle regole, classi e filtri di shaping

loadStatus - ricarica uno stato precedentemente registrato

per un approfondimento degli script creati, si veda l' APPENDICE D









    1. Strumenti di Network Monitoring

Fondamentale è stato lo studio e sperimentazione degli strumenti di analisi del NETWORK TRAFFIC.Come spesso accade, esistono numerosi strumenti nel mondo Open Source ma è difficile trovare quello che risponde appieno alle nostre particolari esigenze. Abbiamo perciò dovuto adattare qualche programma e/o crearne nuovi qualore questi non fossero disponibili. In particolare mancava in assoluto tutta quella serie di programmi che gestiscono e monitorano il Linux Shaping.

Per facilitare e velocizzare il lavoro sul traffic shaping, sono stati creati alcuni script perl. I principali sono:

E' stata creato un tool grafico web-based di inserimento/cancellazione di regole di shaping sulle portehttp://members.optushome.com.au/emikulic/net/darkstat/).Tale tool è stato sviluppato partendo da un programma Open Source chiamato Darkstat ( .Tuttavia tale software è affetto da un impreciso algoritmo di gestione delle librerie libpcap e causa perdita di informazioni durante la fase di sniffing.



      1. TCPDUMP

E' un comando fondamentale per il Network Monitoring.

Cattura e mostra tutto ciò che viene 'sentito' dall' interfaccia di rete.Potente ma ostico come uso e interpretazione.











      1. IPTRAF

Sniffer con filtri ed analisi statistica con menù alfanumerici.Semplice ed intuitivo per un uso immediato.Si esegue in shell.








      1. ETHEREAL



Sniffer con filtri ed analisi statistica con menù grafici, cattura i dati che si possono esaminare comodamente off-line.




      1. NMAP e XNMAP

E' fondamentalmente un port scanning. Analizza una macchina o una rete remota per verificare le porte e i servizi attivi. Semplice da usare l' interfaccia in ambiente Xwindow (XNMAP)






      1. SNORT

Analizza i pacchetti e segnala situazioni anomale verificate attraverso regole. Di notevole complesità, è orientatoa ad analisi a lungo periodo



      1. NTOP

Ntop è un'ottimo traffic probe basato sulle librerie libpacap e compilabile sia su piattaforme *nix che win32.Ntop mostra l'uso della rete in vari modi similmente a come il comando unix top fa con i processi.In modalità interattiva, mostra lo stato della rete sul terminale dell'utente.In modalità web, offre un web server, creando pagine web con lo stato della rete.Support NetFlow/sFlow in modalità emitter/collector.

Le caratteristiche di Ntop sono:


Questo programma mantiene in memoria una tabella hash con i dati dei pacchetti sfniffati sulla rete.Tale tabella può crescere a dismisura e richiede notevoli quantità di memoria (RAM). Nel caso in esame, con Ntop inserito in ramo di 1500 hosts, la tabella richiedeva almeno 300MByte di RAM. Il web server sviluppato e incluso in ntop ha purttroppo numerosi bug. E' documentato che numerose sessioni, molto vicine nel tempo, mandano in crash il web server se il browser utilizzato è Microsoft Internet explorer.Una possibilità alternativa è usare Ntop insieme a netflow, disaccoppiando collector e probe. [http://www.ntop.org/netflow.html]



      1. NETFLOW

Netflow è una tecnologia sviluppata da Cisco.

Un router Cisco (with NetFlow support) ,esporta via UDP ad una macchina esterna le informazioni sul traffico appunto chiamate 'flows' flussi.

La macchina esterna raccoglie i flussi e li aggrega e analizza secondo necessità.








      1. Scotty - Tkined

(http://wwwhome.cs.utwente.nl/~schoenw/scotty)

Scotty è il nome di un pacchetto software che permette l'implementazione di software personalizzato per il network management usando API di alto livello basate su stringhe. Il software è basato sul Tool Command Language che semplifica lo sviluppo di scripts portabili finalizzati al network management. La distributione di scotty include due principali componenti: La prima è Tnm Tcl che provvede al sottinsieme di funzioni per l'accesso alle risorse di network management. La seconda, Tkined, è un componente che fornisceun estendibile framework per il network management system.



      1. Multi Router Traffic Grapher (MRTG)

MRTG è un tool grafico per il monitoraggio del carico di rete.Interrogando dispositivi SNMP, genera pagine HTML contenenti immagini in formato png (o gif) che danno una rappresentazione visuale del traffico. [http://www.mrtg.it]






      1. weatherMap

rdlog viene distribuito come contrib di mrtg.Tramite questa interfaccia web è possibile avere una visione macroscopica dello stato della rete. Ogni linea rappresenta un link fisico e cambia colore proporzionalmente al traffico che sopporta.

Questo programma prende in ingresso un file .fig (file grafico vettoriale associato all' applicativo xfig[http://www.xfig.org]) e disegna una immagine in formato gif con linee (link) di colore proporzionale alla quantità di traffico registrata da mrtg. Il risultato è un'immagine storico-istantanea del carico della rete. In effetti rdlog esegue una media aritmetica tra tutti i dati letti da mrtg.




      1. Darkstat - interfaccia web al traffic Shaping

Il nostro obiettivo è quello di poter dinamicamente aggiungere o variare, attraverso l'associazione di una porta ad un filtro del nostro shaper, la quantità di pacchetti in uscita da un' interfaccia di rete.

Per lo sviluppo della GUI (Graphic User Interface) per il controllo e settaggio del traffic shaping, abbiamo usato un progetto open source chiamato Darkstat reperibile al sito:

http://members.optushome.com.au/emikulic/net/darkstat/



Questo programma web-based da la possibilità di vedere statistiche sul traffico in transito; in particolare, mostra la lista delle porte che sono interessate dal maggior traffico.

Il mio compito è stato, a questo punto, quello di aggiungere una serie di strumenti visuali per poter, accanto ad ogni porta, vedere se esiste un filtro che gestisce il traffico di quella porta e la possibilità di modificarlo, cancellarlo oppure crearlo nel caso non esista.

La GUI sfrutta una serie di eseguibili realizzati in PERL che eseguono delle micro-azioni.Questi eseguibili sono:






18