Network monitoring tramite snmp
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Provvederemo ad abilitare il download, grazie per l'interesse!
    Are you sure you want to
    Your message goes here
  • Elaborato interessante.... mi piacerebbe avere una copia per leggerla offline. Complimenti.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
7,780
On Slideshare
7,777
From Embeds
3
Number of Embeds
2

Actions

Shares
Downloads
296
Comments
2
Likes
2

Embeds 3

http://cesena.ing2.unibo.it 2
http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ALMA MATER STUDIORUM UNIVERSITÀ DEGLI STUDI DI BOLOGNA SECONDA FACOLTÀ DI INGEGNERIA SEDE DI CESENA Corso di Laurea in Ingegneria Informatica STRUMENTI PER IL MONITORAGGIO DI RETE TRAMITE PROTOCOLLO SNMP Elaborato in RETI DI TELECOMUNICAZIONI L-B Relatore: Prof. Walter Cerroni Presentato da: Nicola Calisesi Sessione Prima Anno Accademico 2004/2005
  • 2. INDICE Introduzione 5 Capitolo 1 >> Network Management 1.1 Network Management (Gestione di rete) 6 1.2 Modello ISO 10 1.3 Infrastrutture di rete 12 Capitolo 2 >> Il Protocollo SNMP 2.1 Introduzione al protocollo SNMP 15 2.2 Considerazioni sul protocollo 17 2.3 Evoluzione del protocollo 19 2.3.1 SNMP v1 19 2.3.2 SNMP v2 22 2.3.3 SNMP v3 23 2.4 Standard SNMP 25 2.4.1 Formato dei messaggi 26 2.4.2 Messaggi TRAP 29 2.4.3 Standard per gli oggetti SNMP 30 2.4.4 Estensione delle funzioni SNMP 31 2.5 MIB 32 2.5.1 Classificazione MIB 34 2.5.1.1 Discrete MIB Objects 34 2.5.1.2 Table MIB Objects 35 2.5.2 Tipologie MIB 36 2
  • 3. INDICE 2.5.3 Valori di accesso ai MIB 39 2.5.4 Compilare un MIB 40 Capitolo 3 >> Software SNMP 3.1 Requisiti di un software SNMP 41 3.2 Installazione 44 3.2.1 Requisiti di sistema 44 3.2.2 Elenco dei pacchetti necessari 44 3.2.3 Installazione Java 45 3.2.4 Installazione RRDTool 46 3.2.5 Installazione PostgreSQL 46 3.2.6 Installazione Tomcat4 46 3.2.7 Configurazione PostgreSQL 47 3.2.8 Installazione e avvio OpenNMS 48 3.2.9 Possibili Problematiche 49 3.3 OpenNMS 50 3.3.1 OpenNMS Discovery 55 3.3.2 OpenNMS Capsd 58 3.3.3 OpenNMS Polling 60 3.4 OpenNMS SNMP 62 3.4.1 SNMP-Config.xml 63 3.4.2 DataCollection-Config.xml 65 3.5 Architettura 70 3.6 Altre funzioni 71 3
  • 4. INDICE Considerazioni finali 72 Bibliografia 73 Elenco delle figure 74 4
  • 5. Introduzione Introduzione Lo straordinario sviluppo delle reti di computer dell’ultimo decennio ha aper- to nuovi scenari per quanto riguarda l’utilizzo dei personal computer, si pensi a co- me si è modificato l’utilizzo di Internet grazie alla banda larga, e soprattutto a come è cambiata la concezione del personal computer, trasformando un computer isolato in uno strumento in grado di comunicare con tutto il mondo. Ovviamente lo sviluppo delle reti porta ad un inevitabile incremento delle lo- ro dimensioni e se fino a poco tempo fa il concetto di rete era legato ad ambiti a- ziendali o comunque locali, adesso le reti possono coprire intere aree geografiche. Questa crescita in dimensioni e in numero di host collegati crea agli amministratori notevoli problemi di gestione e manutenzione della rete; infatti se una rete di esten- de in un’area molto vasta non è detto che l’amministratore sia in grado di raggiun- gere fisicamente e in qualsiasi momento tutti gli host e tutti i nodi della rete, quindi per rimediare a questi problemi si utilizzano programmi che siano in grado di moni- torare la rete e di prevenire possibili guasti ai dispositivi collegati. Nel 1989 nasce il protocollo SNMP che viene pensato come punto di partenza su cui sviluppare dei sistemi che siano in grado di risolvere e prevedere tutti i pro- blemi che nascono dalla gestione di una rete. La versatilità di questo protocollo gli ha permesso di trovare da subito un riscontro positivo dal mondo degli sviluppatori e dalle aziende del settore, infatti dopo la prima versione ne sono state implementa- te altre due (anche se la prima continua ad essere la più utilizzata). Oggi lo standard SNMP è supportato da una grandissima quantità di dispositivi alcuni dei quali esu- lano dalla categoria dei componenti di rete come ad esempio alcune stampanti, sen- za dimenticare che viene sponsorizzato da aziende come HP e IBM che vendono i due software commerciali più diffusi. L’obiettivo di questa tesi è analizzare tutta la teoria che sta dietro a questo protocollo (nei primi capitoli) e analizzare un software open source in grado di ge- stire dei nodi che siano equipaggiati con agenti SNMP. 5
  • 6. Network Management Capitolo 1 Network Management 1.1 Network Management (Gestione di rete) Prima di immetterci nella reale gestione della rete, consideriamo alcuni scena- ri illustrativi del mondo reale, esterno alle reti, in cui un sistema complesso ha molti componenti che interagiscono e devono essere monitorati, gestiti e controllati da un responsabile. Le centrali elettriche (almeno per come sono rappresentate dai me-dia popolari) hanno una sala di controllo dove interruttori, manometri e luci monitorano a distanza lo stato (temperatura, pressione flusso) di valvole, tubi, cavi e altri com- ponenti dell'impianto. Questi dispositivi permettono all'operatore di monitorare i componenti principali dell'impianto e lo avvertono (la famosa luce rossa lampeg- giante di avvertimento) quando un guasto è imminente. L'operatore dell'impianto compie azioni per controllare questi componenti. In modo analogo, la cabina di pi- lotaggio di un aereo è strumentata per permettere al pilota di controllare e comanda- re i molti componenti che costituiscono un aeroplano. In questi due esempi, il "responsabile" effettua un monitoraggio sui dispositivi remoti e analizza i loro da-ti per assicurarsi che essi siano operativi e che funzionino entro i limiti prescritti, con- trolla reattivamente il sistema attraverso regolazioni in risposta alle variazioni che intervengono nel sistema stesso o nel suo ambiente, e gestisce efficacemente il siste- ma (per esempio, rilevando tendenze comportamenti anomali, permettendo di inter- venire prima che sorgano problemi seri). In questo senso, il responsabile della rete monitorerà attivamente, gestirà e controllerà il sistema che gli è affidato. Nei primi giorni del funzionamento delle reti, quando le reti di calcolatori era- no strumenti di ricerca e non ancora un'infrastruttura critica usata da milioni di per- sone al giorno, la "gestione della rete" era sconosciuta. Se si incontrava un proble- ma di rete, si metteva in funzione qualche ping per localizzare la fonte del problema e quindi modificare la regolazione del sistema, riparare hardware o software o chia- mare un collega in grado di farlo. (Un'esposizione ben fatta dedicata al primo 6
  • 7. Network Management "crash" serio dell'ARPAnet, del 27 otto- bre 1980, molto prima che gli strumenti per la gestione della rete fossero dispo- nibili, e degli sforzi fatti per risolvere e comprendere il guasto si trova nel [1]). Con la crescita di Internet pubblica e delle intranet private da piccole unità a un'enorme infrastruttura globale, è au- mentata anche la necessità di una gestio- ne più sistematica del gigantesco nume- Figura 1.1 Schema di rete ro di componenti hardware e software all'interno di queste reti. Per motivare il nostro studio della gestione delle reti, cominciamo con un semplice esempio in cui analizzeremo una piccola rete composta da tre router e da un certo numero di host e server in Figura 1.1. Anche in una rete così semplice ci sono molti scenari [2] in cui un responsabile del- la rete può trarre enorme profitto dall'avere gli appropriati strumenti per la sua ge- stione: • Rilevazione di un guasto di una scheda d'interfaccia a un host o a un router. Con appropriati strumenti di gestione della rete, un'entità di rete (per esem- pio il router A) può segnalare al responsabile della rete che una delle sue interfacce è fuori servizio. (Questo è certo preferibile a una chiamata telefo- nica al NOC (Network Operations Center) da parte di un utente irascibile che avverte che la connessione di rete non funziona!). Un responsabile che monitora e analizza attivamente il traffico sulla rete, in realtà può essere in grado di evitare l'irascibile utente rilevando in anticipo i problemi alle inter- facce e sostituendo la scheda prima che si guasti. Questo può essere fatto, per esempio, se il responsabile ha notato un incremento degli errori di che- cksum nei frame che sono stati inviati attraverso l'interfaccia prossima al guasto. 7
  • 8. Network Management • Monitoraggio degli host. Qui, il responsabile della rete può controllare pe- riodicamente che tutti gli host della rete siano accesi e operativi. Ancora una volta, il responsabile della rete può essere in grado di anticipare la risposta a un problema (un host fuori uso) prima che il guasto sia riferito da un utente. • Monitoraggio del traffico per aiutare nell'utilizzo delle risorse. Un respon- sabile della rete può monitorare gli schemi del traffico da sorgente a destina- zione e rilevare, per esempio, che attraverso la commutazione dei server fra i segmenti LAN, la quantità di traffico che attraversa molte LAN può dimi- nuire significativamente. Immaginate l'allegria generale (specialmente nei dirigenti amministrativi) quando si raggiungono migliori prestazioni senza costi di equipaggiamento. In modo analogo, attraverso il monitoraggio del- l'utilizzazione dei link, un responsabile della rete può determinare che un segmento LAN, o il link verso il mondo esterno sia sovraccarico e che è ne- cessario un link con una larghezza di banda superiore, che dovrà quindi es- sere approvvigionato (rappresentando un costo per l’azienda). Il responsabi- le della rete può anche desiderare la notifica automatica nel caso in cui i li- velli di congestione su un link eccedano un dato valore soglia, per poter met- tere a disposizione un link con larghezza di banda superiore prima che la congestione diventi seria. • Rilevazione rapida dei cambiamenti nelle tabelle di instradamento. La flut- tuazione dei percorsi (variazioni frequenti nelle tabelle di instradamento) possono indicare instabilità nell'instradamento o perdita di configurazione in un router. Certamente il responsabile della rete che ha impropriamente con- figurato un router preferirà scoprire da solo l'errore, prima che la rete si blocchi. • Monitoraggio per gli SLA. Con l'avvento degli accordi sul livello di servizio (SLA, Service Level Agreements, contratti che definiscono specifiche metri- che prestazionali e accettabili livelli di prestazioni dei 8
  • 9. Network Management provider di rete rispetto a tali metriche) l'interesse per il monitoraggio del traffico è aumentato in modo significativo negli ultimissimi anni. La UUnet e l'AT&T sono due dei principali provider che garantiscono gli SLA ai loro clienti. Questi SLA comprendono disponibilità del servizio (o interruzione), latenza, throughput e requisiti di notificazione dell’interruzione. È chiaro che se i criteri di prestazioni devono essere parte di un contratto fra un pro- vider di rete e i suoi utenti, allora le prestazioni di misura e di gestione sono di grande importanza per il responsabile della rete. • Rilevazione delle intrusioni. Un responsabile della rete può volere che gli sia notificato quando il traffico in rete arriva da o è diretto a una sorgente so- spetta (per esempio, host o numero di porta). In modo analogo, il responsa- bile può desidera-re rilevare (e in molti casi filtrare) l'esistenza di certi tipi di traffico (per esempio, pacchetti instradati da sorgente, o un grande numero di pacchetti SYN diretti a un dato host) che si sanno essere caratteristici di attacchi alla sicurezza. 9
  • 10. Modello ISO 1.2 Modello ISO L'International Organization for Standards (ISO) [3] ha creato un modello di gestione di rete per cercare di catalogare e collocare ogni scenario di rete possibile in uno schema più strutturato. Vengono così definite cinque aree di gestione della rete [2]: • Gestione delle prestazioni. L'obiettivo della gestione delle prestazioni è di quantificare, misurare, stendere rapporti, analizzare e controllare le presta- zioni (per esempio, utilizzazione, throughput) di differenti componenti di rete. Questi componenti comprendono sia dispositivi singoli (per esempio, link, router e host), sia astrazioni end-to-end come un percorso attraverso la rete. In seguito vedremo che gli standard protocollari, come il protocollo semplice per la gestione delle reti (SNMP, Simple Network Management Protocol) [4], hanno un ruolo centrale nella gestione delle prestazioni in Internet. • Gestione dei guasti. L'obiettivo della gestione dei guasti è di registrare, rile- vare e rispondere alle condizioni di guasto nella rete. La linea di separazione fra gestione dei guasti e gestione delle prestazioni è piuttosto confusa. Pos- siamo pensare alla gestione dei guasti come all'immediato intervento su un difetto transitorio della rete (per esempio, interruzione del servizio di un link di un host o di un router, di hardware o software), mentre la gestione delle prestazioni agisce in tempi più lunghi, per fornire livelli accettabili di presta- zioni di fronte al variare delle richieste di traffico e all'occasionale guasto di un dispositivo di rete. Come con la gestione delle prestazioni, il protocollo SNMP ha un ruolo centrale nella gestione dei guasti. • Gestione della configurazione. La gestione della configurazione permette a un responsabile di rete di seguire i dispositivi che appartengono alla rete ge- stita e di effettuarne la configurazione hardware e software. Una panoramica 10
  • 11. Modello ISO della gestione della configurazione e dei requisiti per le reti basate su IP si può trovare nel [22]. • Gestione della contabilità (accounting). La gestione della contabilità per- mette al responsabile della rete di specificare, registrare e controllare l'acces- so degli utenti e dei dispositivi alle risorse di rete. Quote di utilizzazione, addebiti basati sull’uso e privilegi di allocazione degli accessi alle risorse rientrano tutti nella gestione della contabilità. • Gestione della sicurezza. L'obiettivo della gestione della sicurezza è di con- trollare gli accessi alle risorse di rete in accordo ad alcune politiche ben defi- nite. Il centro di distribuzione delle chiavi e l'autorità di certificazione appar- tengono alla gestione della sicurezza. L'uso di firewall (letteralmente, barrie- re parafiamma) per monitorare e controllare i punti esterni di accesso a una rete. Dopo aver dato diverse definizioni sui vari aspetti della gestione di rete ci si potreb- be chiedere: "Che cos'è la gestione della rete?". L’esposizione precedente ha moti- vato la necessità di gestione della rete senza dare una definizione di gestione di rete, quindi adesso proviamo a farlo nella maniera più sintetica possibile: "La gestione della rete comprende l'azionamento, l'integrazione e il coordinamento di hardware, software ed elementi umani per monitorare, verificare, son-dare, con- figurare, analizzare, valutare e controllare la rete e le risorse degli ele-menti per soddisfare le prestazioni operative in tempo reale e i requisiti di qualità del servizio (QoS) a un costo ragionevole". [5] 11
  • 12. Infrastrutture di rete 1.3 Infrastrutture di rete Nel paragrafo precedente abbiamo visto che la gestione della rete richiede la possibilità di "monitorare, verificare, sondare, configurare,... e controllare" hardware e software e i componenti in una rete. Poiché i dispositivi di rete sono di- stribuiti, questo richiederà come minimo che il responsabile della rete sia in grado di ottenere dati (per esempio, a scopi di monitoraggio) da un'entità remota e di ef- fettuare cambiamenti all'entità remota (per esempio, regolazioni) su quella remota entità. Un'analogia umana risulterà utile per comprendere l'infrastruttura necessaria per la gestione della rete. Immaginate di essere a capo di una vasta organizzazione che ha filiali sparse in tutto il mondo. Il vostro lavoro è assicurare che tutti i pezzi della vostra organiz- zazione operino senza difficoltà. Come potete farlo? Come minimo, periodicamente raccogliete dati dalle filiali in forma di rapporti e di varie misure quantitative di atti- vità, produttività e budget. Occasionalmente (ma non sempre) vi sarà notificato e- splicitamente che c'è un problema in una delle filiali; il manager di una filiale che vuole salire i gradini della scala gerarchica della società può inviarvi un rapporto non sollecitato che indica come le cose funzionino senza problemi nella sua filiale. Voi ordinerete i rapporti ricevuti, sperando di trovare dovunque solo cose che fun- zionano bene, ma senza dubbio troverete problemi che richiederanno la vo-stra at- tenzione. Potrete iniziare un dialogo da-uno-a-uno con una delle filiali che ha pro- blemi, ottenere più dati per comprendere meglio il problema e quindi passare un ordine esecutivo ("Fate questi cambiamenti!") al manager della filiale. In questo scenario umano molto comune è implicita un'infrastruttura per con- trollare l'organizzazione: l’amministratore, il sito remoto sotto controllo (la filiale), il vostro agente remoto (il manager della filiale), i protocolli di comunicazione (per trasmettere i rapporti standard e il dialogo da-uno-a-uno) e i dati (il contenuto dei rapporti e le misure quantitative di attività, produttività e budget). Ciascuno di que- sti componenti nella gestione di un'organizzazione umana ha una controparte nella 12
  • 13. Infrastrutture di rete gestione della rete. L'architettura di un sistema di gestione della rete è concettualmente identica alla semplice analogia di organizzazione umana. Identifichiamo ora tre componenti principali nell'architettura di gestione della rete [2]: un'entità di gestione, i dispositi- vi da gestire e un protocollo di gestione della rete. L'entità di gestione è un'applicazione, che tipicamente coinvolge un uomo, funzionante in una stazione centralizzata di gestione della rete nel centro operativo di rete (NOC). L'entità di gestione è il sito di attività per la gestione della rete; essa controlla la raccolta, l'elaborazione, l'analisi e/o l'esposizione delle informazioni di ge-stione. È da qui che partono le azioni per controllare il comportamento della rete, ed è qui che i responsabili umani interagiscono con i dispositivi della rete. Un dispositivo da gestire è una parte dell'equipaggiamento di rete (compreso il suo software) che risiede sulle rete da gestire. Questa è la filiale nella nostra ana- logia umana. Un dispositivo da gestire può essere un host, un router, un bridge, ecc. All'interno di un dispositivo da gestire ci possono essere molti oggetti da gestire. Questi sono parti reali di hardware all'interno del dispositivo (per esempio, la sche- da di interfaccia di rete) e il set di parametri di configurazione per le parti di hardware e software (per esempio, un protocollo di instradamento intradominio co- me il RIP). Nella nostra analogia umana, gli oggetti da gestire possono essere gli uffici all'interno della filiale . Questi oggetti da gestire hanno associate parti di in- formazio-ni che sono raccolte in una base di informazioni per la gestione (MIB, Management Information Base) [6]; vedremo che i valori di queste parti di informa- zioni sono disponi-bili all’entità di gestione. Nella nostra analogia umana, il MIB corrisponde ai dati quantitativi (misure di attività, produttività e budget, con l'ultimo impostabile dall'entità di gestione!) scambiati fra la filiale e la sede. Infine, residen- te anch'esso in ciascun dispositivo da gestire, c'è un agente di gestione della rete, un processo funzionante nel dispositivo da gestire che comunica con l'entità di ge- stione, che compie azioni locali sul dispositivo da gestire su comando e controllo dell'entità di gestione. L'agente di gestione della rete è il manager della filiale nella 13
  • 14. Infrastrutture di rete nostra analogia umana. La terza parte di un'architettura è il protocollo di gestione della rete. Il proto- collo funziona tra l'entità di gestione e i dispositivi da gestire, permettendo all'entità di gestione di chiedere lo stato dei dispositivi da gestire e indirettamente di agire su essi attraverso i suoi agenti. Gli agenti possono usare il protocollo di gestione della rete per informare l'entità di gestione degli eventi eccezionali (per esempio, guasti dei componenti o violazione delle soglie di prestazione). È importante notare che il protocollo di gestione della rete non gestisce la rete di per sé; piuttosto esso fornisce uno strumento con cui il responsabile può agire ("monitorare, provare, sondare, configurare, analizzare, valutare e controllare") sulla rete. Questa è una sottile ma importante distinzione. 14
  • 15. Protocollo SNMP Capitolo 2 Il protocollo SNMP 2.1 Introduzione al protocollo SNMP SNMP nasce nel 1989 e viene definito dalla Internet Engineering Task Force (IETF)[7]; da quel momento SNMP diventa uno standard industriale per controllare gli apparati di rete tramite un’unica applicazione di controllo. SNMP rappresenta una serie di funzioni e protocolli per la gestione di rete che comunicano tra di loro attraverso l’Internet Protocol (IP), infatti la prima implementazione avviene su pro- tocollo TCP/IP, ma in seguito verrà sviluppato anche su reti IPX e AppleTalk. Que- sto protocollo permette agli amministratoti di rete di individuare ed inseguito isolare i componenti difettosi che si possono trovare su una rete, configurare i vari compo- nenti in remoto e monitorare lo stato e le performance della rete. SNMP è passato attraverso alcune revisioni fino all'attuale versione 3: • SNMPv1: descritto nelle [8] rappresenta la prima versione, utilizza l'invio dei nomi di community (utilizzati come password) in chiaro; • SNMPv2: descritto nelle [9] in cui sono state aggiunte nuove funzionalità tra cui la crittografia tramite MD5; • SNMPv3: descritto nelle [10] è lo standard finale, ma al momento raramente utilizzato; Come altri protocolli dello Strato di Applicazione del modello OSI (livello 7), SNMP utilizza normalmente l’UDP [11] (User Datagram Protocol) e un metodo di comunicazione client/server. SNMP è composto da due parti: • Manager, il manager è un’applicazione software che viene installata su un computer della rete che verrà utilizzato come stazione di controllo (Management Station) o Network Management Station (NMS); i software che si trovano in commercio e anche in rete, gratuitamente, sono diversi e 15
  • 16. Protocollo SNMP soprattutto si trovano per tutte le piattaforme più diffuse (UNIX, PC e Macin tosh) in modo da non obbligare l’amministratore di rete ad orientarsi su una determinata piattaforma. • Agenti e Agenti Proxy, gli agenti risiedono sui dispositivi della rete (switch, router,…) e generano informazioni come i vari indirizzi di rete del dispositivo oppure trasmettono statistiche sul traffico del nodo in cui sono installati. Le informazioni vengono memorizzate all’interno di Management Information Bases o MIBs. Gli agenti proxy svolgono le stesse funzioni di un agente normale ma operano per conto di dispositivi su cui non è implementato SNMP. SNMP è un’implementazione di tipo client/server. L’applicazione client, chia- mata Network Manager, crea una connessione virtuale verso un’altra applicazione server, chiamata SNMP Agent, che gira su un dispositivo remoto come uno switch o un router, vedi Figura 2. Figura 2.1 Implementazione Client/Server Il database che viene gestito dall’agente SNMP è più comunemente conosciuto co- me MIB (Management Information Base) ed è una raccolta di valori statistici e di controllo riferiti al dispositivo. SNMP permette di estendere questi valori standard con valori specifici per particolari necessità di un agente o di un utente sempre at- traverso l’utilizzo dei MIBs, che vedremo in dettaglio in seguito. 16
  • 17. Protocollo SNMP 2.2 Considerazioni sul protocollo Uno dei punti di forza di protocollo SNMP è la sua incredibile diffusione e la capacità di adattarsi a qualsiasi dispositivo che faccia parte di una rete di computer, infatti gli agenti SNMP si possono trovare su computer, bridge di rete, switch, rou- ter, modem e anche stampanti. Il motivo per cui SNMP è nato e per il quale tuttora è così diffuso è la sua interoperabilità. In più questo protocollo è flessibile ed esten- sibile in base alle necessità che si presentano. Siccome le funzioni degli agenti SNMP possono essere facilmente estese, per soddisfare le specifiche di ogni com- ponente hardware, e soprattutto esiste un meccanismo abbastanza semplice per svi- luppare le applicazioni software che poi dovranno interfacciarsi con certe tipologie di agenti, SNMP dispone un grande numero di specifiche per la gestione non stret- tamente legate alla gestione di apparati di rete, ma anche per esempio per la gestio- ne di una stampante. Dopo aver parlato dei motivi che hanno reso famoso questo protocollo, ora illustriamo anche i suoi punti deboli. Innanzitutto a discapito del nome Simple Network Management Protocol, SNMP è un protocollo molto complicato da imple- mentare, per stessa ammissione dei progettisti, un nome più appropriato sarebbe stato Moderate Network Management Protocol, ma anche questa definizione po- trebbe sembrare alquanto generosa se si pensa alla complessità delle regole che co- dificano questo protocollo. Un altro punto debole è l’efficienza del protocollo; in- fatti molta banda utilizzata viene in realtà sprecata con informazioni inutili come per esempio la versione del protocollo che viene trasmessa in tutti i pacchetti o altre informazioni sui data descriptors inserite in ogni pacchetto. Il modo con cui il pro- tocollo identifica le variabili (come le stringhe di byte, dove ogni byte corrisponde a un particolare nodo in una database MIB) comporta un inutile spreco di buona parte del messaggio. Sebbene anche questo protocollo sia oggetto di critiche e non privo di imper- fezioni, possiamo comunque dire che per quanto riguarda la complessità delle sue 17
  • 18. Protocollo SNMP regole, il problema è esclusivamente dei programmatori in quanto l’utente finale non sarà mai in grado di capire a fondo la complessità degli algoritmi con i suoi dati vengono trattati. Invece per quanto riguarda l’efficienza e l’occupazione di banda possiamo dire che lo sviluppo delle tecnologie di comunicazione può nascondere parzialmente il fatto che molte informazioni che viaggiano in pacchetti SNMP sono in sostanza inutili. Una delle critiche più difficili da spiegare sul protocollo SNMP nasce dalla domanda: “Perché SNMP sebbene non abbia una visibilità, come altri tool di gestio- ne di rete, è il più utilizzato?”. In effetti non esiste nessuna guida o nessun RFC il quale dica che SNMP è meglio di altri tool come “telnet” o “netstat”. Come è possi- bile che questo protocollo sia il più utilizzato senza avere alle spalle una serie di documenti che attestino la sua superiorità rispetto ad altri tool? Quando si utilizza telnet, si accede ad un dispositivo di rete e si scaricano tutte le informazioni neces- sarie, non è la stessa cosa che fa SNMP? Un altro problema che non chiarisce questa faccenda sono i venditori, infatti chi vende software basati su SNMP li presenta semplicemente come una alternativa alle shell remote piuttosto che un nuovo prodotto per la gestione e l’analisi della rete; infatti l’attenzione viene posta sulla GUI (Grafical User Interface) anziché sul sistema automatico di configurazione dei dispositivi, sulla raccolta di dati e sulla capacità di lavorare su grandi network. Per rispondere a tutte le domande che ci siamo posti, possiamo innanzitutto che in effetti esistono vie alternative a SNMP ma sono state soppiantate dalla gene- rale popolarità e interoperabilità di SNMP. La completezza di questo protocollo e la sua capacità di adattarsi ad ogni dispositivo per realizzare tutte le funzioni di ammi- nistrazione di rete, portano alla conclusione che di fatto non esistono alternativa a SNMP; un altro aspetto da non dimenticare è il fatto che SNMP sia oggi il metodo più efficace, e probabilmente il solo, per gestire network di grandi dimensioni. 18
  • 19. Evoluzione Protocollo SNMP 2.3 L’evoluzione del protocollo SNMP In questo paragrafo verrà fatta una panoramica abbastanza rapida sull’evolu- zione del protocollo SNMP, poi i concetti principali verranno ripresi in seguito. 2.3.1 SNMP v1 Le caratteristiche principali del protocollo che nascono e si mantengono tali anche dopo la realizzazione delle versioni successive sono: • I moduli Agent sono in ascolto sulla porta UDP 161; • Le risposte sono inviate alla Network Management Station (Manager) utiliz- zando un numero di porta casuale; • La dimensione massima del pacchetto SNMP è limitata solamente dalla mas- sima dimensione del payload UDP(65507 byte); • I messaggi di errore e le eccezioni (Trap) sono spediti dall'Agent al Manager in maniera asincrona utilizzando la porta UDP 162. Le principali operazioni del protocollo SNMPv1 sono: • GET: utilizzata dal Manager per reperire un valore dal MIB dell'Agent MANAGER AGENTE get MIB response 19
  • 20. Evoluzione Protocollo SNMP • GET-NEXT: utilizzata dal Manager per accedere ricorsivamente sul MIB. MANAGER AGENTE getNext MIB response • SET: utilizzata dal Manager per impostare un valore sul MIB. MANAGER AGENTE set MIB response • TRAP: utilizzata dall'Agent per inviare messaggi di errore al Manager. MANAGER AGENTE trap Figura 2.2 Scambio di messaggi SNMPv1 20
  • 21. Evoluzione Protocollo SNMP Il protocollo SNMP assume che i canali di comunicazione siano connection- less, quindi utilizza come protocollo di livello Transport, il protocollo UDP. Di con- seguenza, il protocollo SNMP non garantisce l'affidabilità dei pacchetti SNMP. Figura 2.3 Livello di scambio dei messaggi SNMP Per concludere il discorso sulla versione 1 mostriamo nella figura in seguito il formato del pacchetto SNMP che si articola in 3 parti: • Numero di versione. • Community String utilizzata come password. • Uno o più payload di tipo SNMP. Versione Community SNMP PDU SNMP Message Figura 2.4 Struttura Pacchetto SNMP 21
  • 22. Evoluzione Protocollo SNMP 2.3.2 SNMP v2 Nella versione 2 del protocollo non sono state apportate modifiche sostanziali, seb- bene la versione precedente del protocollo avesse molte limitazioni: presenza di re- gole non documentate; codici di errori limitati; tipi di dato limitati; scarse prestazio- ni; dipendenza dal protocollo di trasporto; assenza di gerarchia nell'architettura Ma- nager/Agent; scarsa sicurezza. Possiamo sintetizzare le modifiche principali mo- strando le due funzioni che sono state aggiunte GetBulk: MANAGER AGENTE getBulk MIB response E la funzione Inform che presenta una sostanziale novità dato che in questo caso è l’agente che interroga il manager per ottenere una informazione: MANAGER AGENTE inform response MIB Figura 2.5 Scambio di messaggi SNMPv2 22
  • 23. Evoluzione Protocollo SNMP 2.3.3 SNMP v3 A partire dalla seconda metà del 1999 è disponibile una ulteriore versione del protocollo SNMP, la versione 3. Poiché le differenze con le precedenti sono notevo- li, ne vediamo le caratteristiche maggiormente innovative. Si tratta della terza ver- sione del protocollo e nasce, in special modo, per sopperire alle mancanze dei suoi predecessori nell’ambito della sicurezza delle trasmissioni. Questo protocollo è sta- to pensato, inoltre, per essere scalabile, duraturo, per quanto riguarda la sua archi- tettura, portabile, compatibile con le precedenti versioni (usa gli stessi MIB). Nonostante ciò, la versione 3 non ha, almeno per ora, trovato grosso spazio sul mercato, dove continua a farla da padrone la versione 1, forse anche perchè, no- nostante fosse fra gli obiettivi di questa nuova versione, la maggiorazione del nume- ro delle caratteristiche è andato a scapito della semplicità del protocollo. La classica architettura di tipo Manager/Agent, nella versione 3, è stata sosti- tuita da una più complessa composta da Motore ed Applicazioni. Infatti, un’entità SNMP v.3 è composta da: • Snmp-Engine (Motore) che contiene un Dispatcher (smistatore di messaggi), un sottosistema per elaborare i messaggi, uno per la sicurezza e uno per il controllo dell’accesso; • Snmp-Applications (Applicazione): contiene un generatore di comandi, un ricettore di notifiche, un risponditore ai comandi e altre funzioni. Il formato dei messaggi di SNMP versione 3 è sostanzialmente diverso da quello delle precedenti versioni; infatti include anche alcuni parametri di sicurezza ed il controllo dell'accesso. Tramite appropriate politiche di sicurezza, SNMPv3 consente di accettare messaggi solo nel caso in cui alcune domande ricevano una risposta affermativa o, comunque, valida come ad esempio: • Il messaggio è autentico? • Chi vuole eseguire una certa operazione? (Usa l'autenticazione con chiavi di crittografia pubbliche e private) 23
  • 24. Evoluzione Protocollo SNMP • Quali oggetti sono coinvolti dall'operazione? • Quali diritti di accesso ha il richiedente sull'oggetto al quale vuole accedere? Queste politiche di sicurezza sono implementate tramite crittografia, funzioni di hash e altri strumenti che consentono l'autenticazione dei pacchetti (ad esempio contro un attacco di sniffing e ripetizione di pacchetto), delle password e, anche, delle PDU (le quali possono essere codificate). Tramite diversi livelli di sicurezza si può stabilire se consentire un accesso: • senza autenticazione (no pwd/no Priv) • con autenticazione (Pwd/no Priv) • con autenticazione e codifica dei dati (pwd/Priv). 24
  • 25. Standard SNMP 2.4 Standard SNMP Dopo fatto una breve panoramica sulle tre versione dell’SNMP e sulla sua evoluzione, passiamo adesso ad una analisi più dettagliata del protocollo e dei suoi standard. Ci sono molti modi in cui affrontare l’analisi dell’SNMP e uno di questi è vedere SNMP come tre standard distinti [12]: 1. Formato dei Messaggi, SNMP è un protocollo standard di comunicazione che definisce dei messaggi in formato UDP. Questa parte dello standard ha subito una notevole involuzione che non produce quasi nessuna conseguenza per l’utente, ma suscita grande interesse per il programmatore. 2. Set di Oggetti, Il set di Oggetti in questione non è altro che un insiemi di va- lori (che SNMP chiama “object), che possono essere richiesti a un dispositivo; in questo set ci sono i valori utili al monitoraggio TCP, IP, UDP,… Ogni og- getto è identificato da un nome ufficiale e con un identificatore numerico che è espresso in dot-notation (per esempio 1.2.1.3.12). 3. Metodo standard per la creazione di un oggetto, certamente questa proprie- tà è una della ragioni per cui si è affermato lo standard SNMP; infatti è possi- bile estendere il set degli oggetti definendone di nuovi ad-hoc per il proprio hardware in modo da poter così personalizzare i componenti prodotti. 25
  • 26. Standard SNMP 2.4.1 Formato dei messaggi Come abbiamo già visto in precedenza possono essere definite cinque tipolo- gie di messaggi SNMP che sono: la richiesta “get” che come valore di risposta rice- ve il nome dell’oggetto interrogato; la richiesta “get-next” richiede un altro nome o valore di un oggetto che si trova su un altro dispositivo, che abbia un nome SNMP valido; il comando “set” richiede a quale set di oggetti corrisponde un valore speci- fico; il comando “response” viene generato dal dispositivo agente e serve ad inviare i dati che sono stati richiesti dagli altri comandi; il comando “trap” viene generato anch’esso dal dispositivo agente (quindi dal device di rete) in maniera asincrona quando deve segnalare o notificare un evento speciale al network manager. Tutti questi messaggi viaggiano sulla rete incapsulati in PDUs (Protocol Data Unit) e lo scambio di questi tra i dispositivi avviene tramite protocollo SNMP. L’attuale formato di questi messaggi non si può definire semplice o conveniente, ma fortuna- tamente la loro complessità viene mascherata al manager dai software che li gesti- scono. Vediamo ora più in dettaglio questi comandi che sono stati creati per soddi- sfare ogni esigenza di un amministratore di rete: • GET REQUEST. L’amministratore può richiedere valori specifici tramite il comando get per determinare le prestazioni e le condizioni di funzionamento del dispositivo. Molti di questi valori possono essere determinati esclusiva- mente analizzando i messaggi generati dal protocollo SNMP senza la necessi- tà di creare un inutile overhead facendo il login sul dispositivo o stabilendo appositamente una connessione TCP. • GET NEXT REQUEST. Questo comando viene utilizzato dagli amministra- tori per “navigare” sulla rete alla ricerca di tutti i dispositivi che supportano il protocollo SNMP. Questa operazione di ricerca parte dal manager di rete e viene reiterata da ogni nodo SNMP che incontra, sempre attraverso lo stesso 26
  • 27. Standard SNMP comando, fino a quando non viene riscontrato qualche errore; a questo punto il manager è in grado di mappare tutti i nodi SNMP della rete di sua compe tenza. Siccome in inglese questo processo di ricerca viene definito “walk”, tutti i nomi degli oggetti MIB incontrati verranno definiti “walked”. • SET REQUEST. Questo comando mette a disposizione del manager un me- todo per effettuare delle operazioni associate al dispositivo di rete come ad esempio disabilitare l’interfaccia, disconnettere degli utenti, pulire i registri, ecc. In sostanza il “set” permette di configurare e controllare in modo remoto il dispositivo tramite SNMP. • GET RESPONSE. Questo comando viene utilizzato dal device di rete per rispondere alle richieste che gli vengono inoltrate tramite get, get-next e set. • TRAP MESSAGE. Un altro comando fornito dall’SNMP Standard che con- siste in un meccanismo attraverso il quale i dispositivi di rete possono manda- re delle comunicazioni sul loro stato ai network manager, generalmente questa funzione viene utilizzata per notificare degli errori. Per ricevere i pacchetti trap di solito è necessario configurare i vari dispositivi di rete in modo che questi restino in attesa della ricezione. Queste tipologie di messaggi appartengono alla prima versione del protocollo SNMP, infatti questi comandi vanno integrati con altri tre comandi che sono stati introdotti nella versione 2: • GET BULK REQUEST. Questo comando serve ad accumulare in una unica transazione request/response molte informazioni relative ad un dispositivo. In pratica il get-bulk si comporta come una serie di interazione GetNext request/ response, eccetto nel caso in cui sia sufficiente una singola interazione. 27
  • 28. Standard SNMP • SNMPv2 TRAP REQUEST. Nella seconda versione è stato introdotto una tipologia di messaggi trap che ha caratteristiche quasi identiche alla versione precedente ma con qualche piccola differenza, perciò si è resa necessaria la definizione di un nuovo messaggio trap. • INFORM REQUEST. Questo comando non comunica valori nuovi, ma ha solo la funzione di confermare la notifica di certi eventi al manager di rete. Per concludere la panoramica sui messaggi vediamo in Figura come questi PDUs vengono incapsulati dentro un messaggio Ethernet. Figura 2.6 Incapsulamento dei messaggi 28
  • 29. Standard SNMP 2.4.2 Messaggi TRAP I messaggi TRAP sono dei messaggi che vengono inviati in maniera asincrona da un Agente verso il Manager per segnalare degli eventi particolari. Le definizioni di questi eventi si trovano nel [13]. I seguenti messaggi TRAP sono quelli che pos- siamo incontrare più frequentemente: • ColdStart - l’agente si è autonomamente avviato o riavviato e i dati potrebbe- ro aver subito delle alterazioni. • WarmStart - l’agente si è autonomamente riavviato ma non c’è stata alcuna alterazione dei dati. • LinkDown - una interfaccia connessa è passata dallo stato di link UP allo sta- to DOWN • LinkUp - una interfaccia connessa è passata in uno stato di link UP • AuthenticationFailure - il nome della community per accedere al dispositivo è errato I messaggi seguenti sono altri messaggi TRAP, ma hanno un uso meno fre- quente e anche una rilevanza minore al fine della gestione della rete: • Enterprise - valore del sysObjectID (vedi oggetti MIB) dell’agente. • Agent-addr - valore dll’indirizzo di rete dell’agente. • Specific-trap - identificatore di un particolare messaggio TRAP. • Time-stamp - tempo trascorso dall’ultimo avvio dell’agente. • Variable-bindings - Lista di variabili contenenti informazioni sul messaggio TRAP. • Vendor-specific - specifici messaggi TRAP aggiunti dai produttori dei dispo- sitivi. 29
  • 30. Standard SNMP 2.4.3 Standard per gli oggetti SNMP La lista dei valori che un oggetto può supportare è spesso chiamata SNMP “Management Information Base” MIB. Capita di frequente che si senta abusare di questo termine per descrivere ogni oggetto SNMP o una parte della gerarchia del protocollo, mentre in realtà MIB è semplicemente un’astrazione come Database, a cui possono essere attribuiti molti significati, che possono ingannare gli utenti meno esperti. La grande varietà di valori SNMP nello standard MIB sono definiti nel RFC 1213. Lo standard MIB include molti oggetti (valori) per misurare e monitorare le attività IP, TCP e UDP, l’instradamento IP, le connessioni TCP, le interfacce e il sistema in generale. Tutti questi valori sono associati ad un nome ufficiale (come ad esempio sysUpTime, che misura da quanto tempo è acceso il device dall’ultimo av- vio) e un valore numerico ufficiale espresso in dot-notation ( il numero identificati- vo del sysUpTime è 1.3.6.1.2.1.1.3.0). Si può facilmente intuire che è preferibile esprimere le varie funzioni con il proprio nome piuttosto che in dot-notation, un po’ come succede con gli indirizzi di Internet dove è preferibile memorizzare un nome piuttosto che un indirizzo IP. Nel prossimo paragrafo poi si parlerà diffusamente dei MIB. Figura 2.7 Traduzione di un valore in dot-notation [14] 30
  • 31. Standard SNMP 2.4.4 Estensione delle funzioni SNMP Come si diceva in precedenza uno dei punti di forza del protocollo è la sua facilità di manipolazione ed estensione, infatti possiamo affermare che SNMP è di- ventato lo standard principale nella gestione delle reti per la sua capacità di aumen- tare l'insieme degli oggetti standard del MIB con nuovi valori specifici per le deter- minate applicazioni e determinati dispositivi. Una funzione può essere aggiunta sen- za particolari problemi, poiché è stato definito un metodo standard per incorporare nuove funzionalità nei dispositivi dello SNMP e nei software che gestiscono la rete; questo standard è di solito seguito da un il processo che solitamente viene chiamato "compiling new MIB” (compilare un nuovo MIB), che permette all'utente di ag- giungere le definizioni del nuovo MIB sul sistema. Queste definizioni sono fornite solitamente dai tutorial dell’azienda, che produce il device, in file di testo special- mente formattate usando la sintassi standard ASN.1. [15] (ASN.1 fa riferimento alla “Abstract Syntax Notation One”, che è un tipo linguaggio dichiarativo di non sem- plice comprensione, adottato da SNMP ed usato anche per altre applicazioni, come crittografia e CMIP protocol). Da notare che il MIB di un dispositivo SNMP è solitamente fisso; viene pro- gettato e implementato dalla casa produttrice del device e in genere non può essere aggiunta nessuna funzione o modificata una già esistente. Per questo motivo quando si parla di estendibilità SNMP ci si riferisce al software che amministra il protocollo SNMP, infatti è il software che può essere facilmente compilato o ricompilato per interfacciarsi con le funzioni aggiuntive del dispositivo di rete. 31
  • 32. MIB 2.5 MIB Per usare efficacemente SNMP, gli utenti devono conoscere SNMP Management Information Base (MIB), che definisce tutti i valori che il protocollo è in grado di leggere o di settare. Per diventare esperto in SNMP, un manager network deve per forza approfondire la sua conoscenza del MIB. SNMP MIB è organizzato con una struttura ad albero, molto simile a quella usata dai pc per organizzare i files in directory come si vede in Figura. Figura 2.8 Albero MIB – Root and Subtree Come si vede dalla figura la cartella radice (root) non ha nome, poi seguono le tre cartelle principali in cui sono contenuti tutti i sottoalberi che contengono le defini- zioni di tutti gli standard tra cui anche Internet che è contenuto in una sottocartella di ISO (International Organization for Standardization), il nostro interesse infatti cade sul contenuto del sottoalbero Internet. 32
  • 33. MIB L’insieme di standardizzazioni che riguardano Internet possono essere suddivise in quattro rami principali (come si vede nella Figura 2.9): • i rami “directory” e “experimental” sono sostanzialmente privi di valori e og- getti che abbiano un significato rilevante; • il ramo “management" è molto importante per il nostro studio e contiene tutti gli standard degli oggetti supportati da tutti i dispositivi della rete (o perlome- no la grande maggioranza); • il ramo "private" invece contiene le definizioni degli standard per gli oggetti SNMP creati dai vari produttori e implementati sui propri dispositivi. Figura 2.9 Albero MIB - Leaf La struttura ad albero descritta è una parte integrante dello standard SNMP, comunque le parti su cui porremo l’attenzione sono le “foglie” (leaf) di questo albe- ro, ossia gli standard che realmente definiscono le funzioni a disposizione dell’am- ministratore di rete. 33
  • 34. MIB 2.5.1 Classificazione MIB Generalmente, gli oggetti SNMP possono essere divisi in due categorie simili ma con piccole sostanziali differenze che riflettono l'organizzazione in una struttura ad albero[12]: 1. Discrete MIB Objects. Gli oggetti “discreti” SNMP contengono solamente una parte precisa e ben definita dei dati utili alla gestione. Questi oggetti sono spesso distinti dai Table Objects (descritti sotto) aggiungendo un'estensione “.0”(dot-zero) ai loro nomi (se l'estensione “.0” viene omessa da un nome di un oggetto SNMP, è sempre considerata implicita). 2. Table MIB Objects. Gli oggetti SNMP definiti “table”(tabella) contengono parti multiple di dati o valori per la gestione. Questa categoria di oggetti si distingue dagli oggetti “discrete” aggiungendo “.” (dot-extension) ai loro no- mi seguito da un numero che distingua unicamente il valore particolare a cui si fa riferimento. La dot-extension si riferisce in certa letteratura al numero dell’istanza dell’og- getto SNMP. Nel caso degli oggetti "discrete", questo numero sarà zero, mentre nel caso degli oggetti “table”, questo numero sarà l'indice nella tabella SNMP. 2.5.1.1 Discrete MIB Objects Molti oggetti SNMP sono discreti, questo significa che l'operatore deve sol- tanto conoscere il nome dell’oggetto e nessun’altra informazione. Gli oggetti discre- ti rappresentano spesso dei valori standard di un dispositivo, particolarmente utili per ricavare informazioni dalla rete al fine di monitorare e soprattutto confrontare le prestazioni dei dispositivi di vari produttori. Se l'estensione (numero dell’istanza) dell’oggetto non è specificata, esso viene presupposto come “0” (dot-zero). 34
  • 35. MIB 2.5.1.2 Table MIB Objects Le tabelle SNMP sono dei tipi speciali di oggetti SNMP, che permettono di raggruppare una serie di dati che un dispositivo deve supportare. Le tabelle vengono distinte dagli oggetti discreti, in quanto possono svilupparsi senza limiti. Per esem- pio, SNMP definisce l'oggetto “ifDescr” (come oggetto standard SNMP) che indica la descrizione testuale di ogni interfaccia supportata dal dispositivo in questione; visto che i vari dispositivi della rete possono essere configurati con più di un'inter- faccia, questo oggetto è ovvio che non può essere rappresentato con un singolo va- lore ma solo con un insieme di valori come un array. Per convenzione gli oggetti SNMP sono sempre raggruppati in una “Entry Directory”, all'interno della quale ogni oggetto viene definito con il suffisso “Table” (per esempio l'oggetto “ifDescr” descritto precedentemente si trova nella directory “ifEntry” contenuta a sua volta nella directory “ifTable”). Il protocollo prevede parecchi vincoli sugli oggetti SNMP come vedremo nel- l’elenco che segue: 1. Ogni oggetto dell’”Entry Directory” di una tabella deve contenere lo stesso numero di elementi come gli altri oggetti gli altri oggetti contenuti nella stessa “Entry Directory”, dove il numero delle istanze di tutti i valori è lo stesso. Gli oggetti della tabella si possono considerare come insiemi omogenei di dati. 2. Nella creazione di un nuovo oggetto Entry, SNMP richiede che un valore sia associato con ogni tabella Entry in un singolo messaggio SNMP (PDU). Ciò significa che per creare una riga in una tabella, tramite il comando SET, un valore deve essere specificato per ogni elemento della riga. 3. Se si vuole cancellare una riga della tabella, SNMP richiede che almeno un oggetto che abbia un elemento di controllo che sia in grado di realizzare la cancellazione desiderata. Questo procedura è necessaria solo quando si can- cella una riga e non quando si cancella una tabella SNMP. 35
  • 36. MIB 2.6 Tipologie di oggetti MIB Gli oggetti MIB sono caratterizzati da specifici tipi di valori e il protocollo è molto rigido nella definizione di questi “primitive types”: • Text Type MIB Objects. SNMP definisce un tipo “DisplayString” che può contenere qualsiasi tipo di informazione testuale (solitamente con un massimo di 256 caratteri). Il testo può contenere solo i caratteri stampabili. Gli esempi di questo tipo di oggetto includono il “sysDescr” e i valori “ifDescr”. Questo tipo di oggetto è abbastanza comune come oggetto MIB. • Counter Type MIB Objects. SNMP definisce contatore, quella tipologia di valori che possono essere solo incrementati. Il contatore è il tipo più diffuso di oggetto MIB standard ed include oggetti come “ipInReceives”, “ipOutRequests” e “snmpInPkts”. Il contatore può raggiungere un valore mas- simo e non può mai scendere sotto lo zero. • Gauge Type MIB Objects. SNMP definisce “gauge”, quei valori numerici che possono essere incrementati o decrementati. Questo tipo si trova soltanto in poche situazioni tra gli oggetti MIB, sebbene venga spesso riportato tra gli oggetti MIB “private” dei produttori). Gli esempi di questo tipo di oggetto includono il “tcpCurrEstab”. • Integer Type MIB Objects. SNMP definisce un tipo base di “integer” che può contenere valori positivi o negativi. Questo valore viene solitamente so- stituito con oggetti di tipo “gauge” o “counter”, ma a volte viene espresso tra i MIBs "private" sulle guide dei produttori. • EnumVal Type MIB Objects. SNMP definisce tipi di valori “enumerati”, quei valori che associano un'etichetta testuale con un valore numerico. Questo 36
  • 37. MIB tipo di dati è abbastanza comune nello standard MIB e tra questi troviamo “ifAdminStatus”,che ha come valori predefiniti “1=up”, “2=down” e “3=testing”. Generalmente questi valori vengono formattati affinché vengano secondo la convenzione “nome(numero)”. • Text Type MIB Objects. SNMP definisce un tipo di oggetti “TimeTicks” che rappresenta un tempo trascorso, che viene rilevato con una precisione al centesimo di secondo, anche se non viene mai utilizzato un dato con questa precisione dato che la notazione che si usa è questa “HH:MM:SS:hh”. Si noti che ogni oggetto “time” è sempre un tempo trascorso, per esempio, il valore del “sysUpTime” indica il tempo trascorso dall’ultimo avvio del dispositivo. • Object Type MIB Objects. SNMP definisce un tipo di oggetti “object” per contenere l’idenficatore di un altro oggetto SNMP. Se l'oggetto chiamato è compilato nel MIB, il nome visualizzato è uguale al nome dell'oggetto SNMP. Un esempio di questo tipo di oggetto è il “sysObjectID”. • IPAddr Type MIB Objects. SNMP definisce un tipo di oggetti “IP address” per identificare l’indirizzo IP di un dispositivo della rete. Questo tipo di og- getto viene visualizzato quasi sempre nella convenzionale dot-notation degli indirizzi IP. Gli esempi di questo tipo di oggetto includono “ipRouteDest”, “ipRouteNextHop” e “ipRouteMask”. • PhysAd Type MIB Objects. SNMP definisce un tipo di oggetti “phyisical address” (indirizzo fisico) dove vengono memorizzati gli indirizzi MAC del dispositivo della rete. I responsabili visualizzano spesso questo tipo di oggetto come una sequenza di valori esadecimali preceduti dalla parola “hex:” e sepa- rati da due punti. Questa tipologia di oggetti include “ifPhysAddress”. 37
  • 38. MIB • String Type MIB Objects. SNMP definisce un tipo di oggetti “stringa” per contenere stringhe di byte arbitrarie. Se la stringa di byte contiene soltanto i caratteri di ASCII, i manager visualizzano questo valore come stringa di testo. Altrimenti, i responsabili visualizzano questo tipo come sequenza dei valori esadecimali, premettendo “hex:” la parola chiave hex seguita dai due punti. Questo tipo di valore è raro, ma occasionalmente viene riportato negli oggetti MIBs “private” dei produttori. • Table Type MIB Objects. Il tipo “table” è un oggetto che contiene i valori di una tabella. Questo tipo di oggetti è sempre un nome intermedio che contiene il nome dell’Entry Directory a cui appartiene, che a sua volta contiene i vari Table Objects. • Branch Type MIB Objects. Il tipo “branch” (tradotto letteralmente significa ramo) è un oggetto che contiene delle “ramificazioni” addizionali degli ogget- ti elencati finora. 38
  • 39. MIB 2.5.3 Valori di accesso dei MIB Ogni oggetto dello SNMP è definito per avere un accesso particolare, uno “read-only”, “read/write”, “write-only” che determini se l'utente può leggere il valo- re dell'oggetto, leggere e scrivere il valore di un oggetto (usando il comando SET) o soltanto scrivere il valore. SNMP definisce una community per mettere in relazione un agente SNMP ed uno o più manager SNMP. Ogni ordine NMP ha associata la stringa della relativa community. I nomi delle stringhe vengono configurati dal manager della rete. Queste stringhe forniscono una misura di sicurezza per le informazioni conte- nute negli oggetti, anche se non possiamo definirle delle passwords; infatti le strin- ghe più comunemente usate sono “public” e “private”. Il dispositivo che riceve un comando SNMP prima controlla che la stringa community abbia un valore valido, dopo l’accesso agli oggetti richiesti verifica i permessi di read/write. Tuttavia, è consigliabile rendere questi nomi di community non visibili in mo- do da limitare la possibilità di avere accessi di utenti esterni o non autorizzati. 39
  • 40. MIB 2.5.4 Compilare un oggetto MIB Una delle componenti principali di cui non può fare a meno un buon respon- sabile di rete che utilizza SNMP è un “MIB Compiler” che permette di creare nuovi MIB da aggiungere al sistema di amministrazione. Questo concetto può confondere i nuovi utenti probabilmente a causa della strana nomenclatura legata a questo ter- mine. Quando un MIB viene compilato in un software SNMP Manager, l’ammini- stratore si deve accertare che questa funzione sia supportata dall’agente sulla rete. Il concetto è simile ad aggiungere un nuovo schema a un database. L'agente non è in- fluenzato dalla compilazione del MIB (poiché è già “informato” delle funzioni che può supportare). Ovviamente all’atto della compilazione del MIB, il responsabile deve sapere quali sono le funzioni speciali supportate dall'agente ed accede a questi oggetti come se fossero componenti standard del set di oggetti. Solitamente, quando un MIB è compilato su un sistema, il programmatore de- ve creare anche delle nuove directory che corrispondano agli oggetti. Questi indici possono essere visualizzati tramite un “MIB Browser", che è un componente di am- ministrazione SNMP molto comune e viene incorporato in tutti i sistemi di network management. Questi nuovi oggetti possono essere possono non essere accettati da una agente, che genera dei warning, e ne possono anche modificare le prestazioni. Gli oggetti MIB sono documentati con la sintassi ASN.1, che è un tipo di lin- guaggio dichiarativo non semplice da comprendere, adottato da SNMP ed usato in poche altre applicazioni. L'utente può ottenere le definizioni ASN.1 di un nuovo dispositivo o di nuovo agente SNMP, trasferendo il file che contiene queste defini- zioni sul proprio sistema e lanciando un “MIB Compiler” per tradurle. Teoricamen- te tutti gli agenti supportano le definizioni dei MIBs descritte nel [23] e la maggior parte dei agenti dispone anche di funzioni aggiuntive. 40
  • 41. Installazione Software SNMP Capitolo 3 Software SNMP 3.1 Requisiti di un software per SNMP Nei capitoli precedenti abbiamo mostrato le caratteristiche che descrivono il protocollo SNMP, ma ancora non abbiamo pienamente giustificato il fatto che SNMP sia preferibile ad altri tipi di protocolli d'amministrazione. La risposta più semplice a questo quesito sta nel fatto che SNMP è stato pro- gettato per cercare di uniformare l’accesso ai dispositivo di rete. SNMP è un Appli- cation Program Interface (API) verso la rete, in modo che i programmi general- purpose di network management possono essere scritti facilmente per lavorare con una grande varietà di dispositivi differenti. Senza SNMP, ci sarebbe certamente una miriade di applicazioni speciali e custom-written (scritte ad-hoc), in grado di opera- re soltanto con l'apparecchiatura specifica del produttore. In più SNMP è un modo economico di determinazione della condizione dei dispositivi senza l'esigenza del login remoto o dell'autenticazione, inoltre permette di reperire velocemente una grande mole di dati su reti anche su larga scala. Quali sono i componenti che non posso mancare in un buon software per la gestione del protocollo SNMP? • Alarm Polling Functions. Tutti i migliori software SNMP forniscono delle funzionalità per fissare delle soglie sui valori degli oggetti MIB SNMP e ri- spondono con un certo tipo di notifica quando queste soglie sono violate. Queste funzioni tengono costantemente sotto controllo la rete e l’integrità di tutti i dispositivi connessi, quindi la capacità di determinare quali dispositivi stanno rispondendo (cioè in linea) e quali dispositivi non stanno rispondendo (cioè off-line o faulted). 41
  • 42. Installazione Software SNMP • Trend Monitoring Function. Un’altra funzione fondamentale per un manager SNMP è la possibilità di monitorare un valore SNMP durante un pe- riodo prolungato, in modo da poter ricavare un range di tolleranza e soprattut- to cercare di individuare un trend di questo dato. Questo tipo di funzione può essere usato per determinare il carico della rete nel tempo guardando la quan- tità di traffico sulla banda a disposizione). Un tipico output di queste funzioni di amministrazione è un grafico dell’utilizzazione della rete durante un certo arco temporale (un giorno, una settimana,…) • Trap Monitoring Functions. Il manager SNMP deve essere in grado di rice- vere e filtrare i messaggi TRAP che gli arrivano dai componenti sulla rete. I traps SNMP sono una parte importante dello standard SNMP e permettono ai dispositivi di fare un’auto-analisi delle loro condizioni di funzionamento. Questi messaggi trap sono gestiti tipicamente dal manager di rete a cui giun- gono sottoforma di notifiche di eventi. Dato che i traps sono asincroni ed e- sterni al controllo del manager di rete, quest’ultimo può attivare delle funzioni di filtraggio dei messaggi per eliminare quelli non pertinenti o quelli comple- tamente inutili. • Management Tool Set. Tutti i software SNMP dispongono di un tool set. Il tool di gestione SNMP più comune è il MIB Browser, che permette che all’u- tente di controllare gli oggetti MIB di un dispositivo particolare; infatti spesso il MIB Browser è l'interfaccia principale per la regolazione dei valori SNMP di un agente e si può utilizzare per fare le opportune regolazioni sempre trami- te protocollo SNMP. • MIB Compiler. Il manager SNMP deve poter disporre di un oggetto MIB in grado di aggiungere delle funzioni al set già presente sui dispositivi della rete, ciò implica l'esigenza assoluta di un compilatore MIB in modo da potere inte- grare e utilizzare le funzioni speciali messe a disposizioni dai produttori di componenti di rete. 42
  • 43. Installazione Software SNMP E’ importante sottolineare che le suddette caratteristiche del software manager SNMP sono pensate specialmente per la visualizzazione a video e quindi per rende- re più leggibile la grande mole di dati prodotta da una rete di vaste dimensioni. La maggior parte degli oggetti MIB sono read-only e vengono sfruttati molto bene dal protocollo SNMP che ne ricava le informazioni sulla condizione della rete e determina la salute della rete; di contro diventa meno potente quando è necessario apportare delle modifiche alle impostazioni di rete, anche se il comando SET (spesso realizzato completamente da un browser MIB) permette di apportare qual- che correzione alle configurazioni dei dispositivi via SNMP. Dopo aver fatto queste premesse dobbiamo cercare un software in grado di mostrare come funzioni realmente un Manager SNMP. Ovviamente i software in commercio sono moltissimi sia commerciali sia open source. Tra i software com- merciali i due leader del settore sono OpenView di HP e Tivoli di IBM, mentre in ambito open source non ci sono software di spicco anche se uno tra quelli esaminati è sembrato molto interessanti: OpenNMS. La scelta è ricaduta su un software open source gratuito ovviamente e tra i due so- pra elencati OpenNMS sembrava quello più completo e con uno sviluppo maggiore; quindi tutto il resto del capitolo sarà dedicato a questo tool e verrà spiegato cosa richiede a livello di strumenti, come si installa, come si configura e quali sono le sue funzioni principali. 43
  • 44. Installazione Software SNMP 3.2 Installazione 3.2.1 Requisiti di sistema I requisiti minimi richiesti per l'installazione e l'esecuzione di OpenNMS pos- sono essere riassunti nei seguenti tre punti: • Processore: 1 Ghz o superiore. • Memoria RAM: 256MB, anche se è comunque consigliato un minimo di 512 MB. • Memoria su disco fisso: circa 25MB servono per l'installazione di base, per quanto riguarda lo spazio da riservare alle informazioni di gestione che ver- ranno raccolte nel tempo si può stimare, in maniera del tutto approssimativa, un minimo di 3MB per ogni interfaccia da interrogare. Considerati poi i file di logs del programma che crescono nel tempo si può ritenere che per una confi- gurazione minima lo spazio su disco a disposizione debba essere superiore ad 1 GB. 3.2.2 Elenco dei pacchetti necessari Il software di installazione è disponibile sul sito di SourceForge alla seguente pagina web: https://sourceforge.net/project/showfiles.php?group_id=4141. Le ver- sioni disponibili sono diverse a seconda del sistema operativo Linux che si intende utilizzare. In questo lavoro di tesi è stata scelta la distribuzione Fedora Core 3 e la versione di OpenNMS [16] è la 1.2.3. Prima di procedere ad installare OpenNMS bisogna corredare il nostro sistema Linux dei seguenti pacchetti: • Java: OpenNMS è scritto quasi interamente in linguaggio Java [17]. 44
  • 45. Installazione Software SNMP • Tomcat4 [18]: è un Java servlet engine. In pratica Tomcat è il server web che utilizza OpenNMS per garantire agli utenti l'accesso alle proprie risorse. • RRDtool [19]: consente una rapida memorizzazione dei dati raccolti in un pic- colo spazio di memoria e la rappresentazione degli stessi in modalità grafica. • PostgreSQL[20]: è il database di OpenNMS. • Curl: consente mediante uno script (/etc/init.d/opennms status) di sapere se tutti i componenti che costituiscono OpenNMS stanno funzionando corretta- mente. 3.2.3 Installazione Java È importante installare SDK anziché il JRE, poiché Tomcat dovrà compilare il codice del Java (che richiede javac il quale si trova in SDK). Dovrete usare la piattaforma del Java 2 della Sun, edizione standard, versioni 1.4 o successive (è consigliabile utilizzare la versione 1.4.2 o successive). Tutti i pacchetti sono scari- cabili dal sito http://java.sun.com. Una volta accettati i termini della licenza per l’utilizzo del software è possibi- le scaricare il pacchetto; siccome utilizziamo una versione di Linux (Fedora Core 3) che è RPM-based sarà sufficiente scaricare il pacchetto .rpm che ci interessa e in- stallarlo, senza dover fare ricorso al pacchetto .bin e in seguito al compilatore per installarlo. 45
  • 46. Installazione Software SNMP 3.2.4 Installazione RRDTool Questo tool è fondamentale per poi poter installare OpenNMS, infatti compa- re anche tra le dipendenze; questo pacchetto si può scaricare sul sito http:// people.ee.ethz.ch/~oetiker/webtools/rrdtool. Per l’installazione si possono fare due scelte. La prima è seguire l’installazio- ne sulla guida del sito sopra citato nella sezione Documentation -> rrdbuild, in que- sta procedura si utilizzano tutti i pacchetti con codice sorgente che deve poi essere compilato e installato, inoltre prima di poter installare rrdtool è necessario installare cinque librerie aggiuntive, è chiaro che questa procedura diventa lunga e abbastanza macchinosa. La seconda opzione è quella di scaricare rrdtool come pacchetto RPM dal sito http://dag.wieers.com/packages/rrdtool/ e installarlo semplicemente tramite il comando rpm. 3.2.5 Installazione PostgreSQL Per l’installazione del PostgreSQL si può provvedere in fase di installazione del sistema operativo selezionando semplicemente il pacchetto PostgreSQL oppure sul sito http://www.postgresql.org/download/ dove si trova tutto il necessario all’in- stallazione. 3.2.6 Installazione Tomcat4 Il pacchetto RPM del Tomcat4 per Fedora Core 3 si trova molto velocemente sull’FTP di OpenNMS ftp://ftp.opennms.org/pub/dependencies/tomcat4/, all’interno di questa directory ci sono due file da scaricare e installare entrambe: tomcat4- 4.1.18-full.1jpp.noarch.rpm and tomcat4-webapps-4.1.18-full.1jpp.noarch.rpm. 46
  • 47. Installazione Software SNMP 3.2.7 Configurazione PostgreSQL E' necessario, a questo punto, effettuare alcune modifiche sui files di configu- razione di PostgreSQL; tali files vengono creati una volta che viene lanciato Po- stgreSQL, per cui è necessario eseguire tale operazione prima. Si localizza la directory dei dati di PostgreSQL, di solito /var/lib/pgsql/data e si cercano i files postgresql.conf e pg_hba.conf. Nel file postgresql.conf bisogna cambiare tre parametri: • tcpip_socket = true (è necessario che non ci sia preposto il carattere di commento #, questo consentirà ad OpenNMS di interrogare il database) • max_connections = 256 • shared_buffers = 1024 Nel file pg_hba.conf invece bisogna modificare il file in modo che le uniche righe non commentate (e quindi senza # ) siano le seguenti: # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD local all all trust host all all 127.0.0.1 255.255.255.255 trust host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff trust 47
  • 48. Installazione Software SNMP 3.2.8 Installazione e avvio di OpenNMS A questo punto è possibile scaricare dal sito web https://sourceforge.net/ project/showfiles.php?group_id=4141 i file RPM per installare OpenNMS relativi al proprio sistema operativo, in questo caso Fedora Core 3. Per l’installazione è suf- ficiente seguire i seguenti comandi: # rpm -i opennms-1.2.3-0_<distribution>.<platform>.rpm # rpm -i opennms-webapp-1.2.3-0_<distribution>.<platform>.rpm # rpm -i opennms-docs-1.2.3-0_<distribution>.<platform>.rpm Prima di lanciare il programma è necessario settare alcuni path: • il path del JRE # $OPENNMS_HOME/bin/runjava -s <path JRE> • il path del postgreSQL # $OPENNMS_HOME/bin/install -disU • il path delle Web Application # $OPENNMS_HOME/bin/install -y -w $CA- TALINA_HOME/webapps -W $CATALINA_HOME/server/lib La procedura di installazione adesso è terminata, per avviare il programma: /etc/init.d/opennms start Aprendo un browser web, come Mozilla, alla pagina http://localhost:8080/opennms si effettua il login, come nome utente “admin” come password ”admin”, e si ha ac- cesso al software di Network Management. L'effettivo funzionamento del sistema può essere verificato tramite il comando: /etc/init.d/opennms status controllando che tutti i campi siano in modalità running. Quando si eseguono delle modifiche ai files di configurazione è necessario fermare il programma e farlo ripartire: /etc/init.d/opennms restart Il riavvio completo della macchina non è mai richiesto, però in alcuni casi può risul- tare necessario, considerata la natura “unstable” del prodotto utilizzato. 48
  • 49. Installazione Software SNMP 3.2.9 Possibili Problematiche Niente è perfetto, può quindi capitare che qualcosa non funzioni in tal caso la prima cosa da fare è cercare di capire dai files di log di OpenNMS quale può essere il problema. Tali files si trovano, di solito, in /var/log/opennms e gli eventuali pro- blemi sono da cercarsi nelle righe dove compaiono i campi FATAL e ERROR. Se non compare la home page di OpenNMS verificare che sia Tomcat che OpenNMS stiano funzionando correttamente, dopodichè se le cose continuano a non funzionare cambiare l'indirizzo ovvero utilizzare http://localhost:8080/ opennms. La maggior parte dei problemi è dovuta alle configurazioni degli applica- tivi Java e PostgreSQL. E' possibile chiedere supporto alla mailing list e alla documentazione ufficiale di OpenNMS. Gli indirizzi sono riportati di seguito: • http://www.opennms.org • http://sourceforge.net/docman/?group_id=4141 • https://sourceforge.net/mail/?group_id=4141 • http://wiki.opennms.org/tiki-list_faqs.php Bisogna tenere presente che il progetto OpenNMS evolve in maniera molto rapida e versioni successive a quella utilizzata in questa tesi si susseguono rapidamente, per cui bisogna fare estrema attenzione a ciò che si utilizza e alla documentazione che si consulta. 49
  • 50. OpenNMS 3.3 OpenNMS Rilasciato sotto licenza GPL, OpenNMS rappresenta, come detto, la vera al- ternativa open source ai prodotti di Network Management proprietari ponendosi come obiettivo la scalabilità e la portabilità. Esso consente a uno o più utenti di ac- cedere ai seguenti servizi: • Servizi Web: HTTP e HTTPS • Servizi di Posta: POP3, IMAP e SMTP • Database: Oracle, Sybase, Informix, SQLServer, MySQL e Postgres • Servizi di Rete: ICMP, SNMP, DNS, DHCP,FTP, SSH e LDAP • Altri Servizi: Citrix e Lotus Domino IIOP Per quel che riguarda il Network Management, OpenNMS sfrutta le potenzia- lità offerte dal protocollo SNMP dialogando con gli agenti presenti, ognuno, sui va- ri nodi della rete secondo le modalità descritte nei capitoli precedenti. OpenNMS è scritto quasi interamente in linguaggio Java, le uniche eccezioni riguardano il database (PostgreSQL) e i grafici (RRDtool), e ciò rende il prodotto eseguibile su qualsiasi piattaforma. I files di configurazione sono scritti in eXtensi- ble Markup Language (XML) e i dettagli per l'installazione sono riportati nei para- grafi precedenti. 50
  • 51. OpenNMS Si accede al sistema mediante un browser web al seguente indirizzo http:// localhost:8080/opennms e dopo aver effettuato il login “admin” e password “admin” viene visualizzata la home page. Figura 3.1 Schermata principale di OpenNMS All'interno della home page è riportata, oltre ad un elenco dei nodi non fun- zionanti, una situazione generale riguardante i servizi (Categories) presenti nella rete con le relative percentuali di funzionamento nelle ultime 24 ore. Come si vede dalla figura, sono presenti i links che consentono di visualizzare i tempi di risposta per tutti i nodi attivi presenti sulla rete e i dati prestazionali per quelli equipaggiati con l'agent SNMP. Navigando all'interno del sistema, attraverso links di facile comprensione, si trova una completa descrizione per ogni singolo no- do e per ogni interfaccia riconosciuta, come si vede in figura alla pagina seguente. 51
  • 52. OpenNMS Figura 3.2 Nodo Linux In particolare viene dedicata una pagina all'interno della quale si trovano tutte le informazioni che interessano un particolare nodo. Oltre ad una dettagliata crono- logia degli avvenimenti che hanno interessato il nodo in questione sino a quel parti- colare istante, nella stessa pagina vengono visualizzate le interfacce, identificate dal proprio indirizzo IP, con i relativi servizi associati. A fondo pagina sono riportate ulteriori due sezioni: una riguardante gli ultimi guasti che hanno interessato il nodo, con i relativi riferimenti temporali, e uno ri- guardante il tipo di software agent di cui il nodo è provvisto. L'amministratore avendo sempre una situazione chiara e precisa di ciò che sta avvenendo, può, da un'unica postazione, controllare tutti i nodi della rete localizzan- do tempestivamente eventuali malfunzionamenti. 52
  • 53. OpenNMS Vengono riportati di seguito alcuni collegamenti [21] che si trovano frequen- temente in OpenNMS: • Admin : rimanda ad una pagina, riportata in figura 3.3, dove è possibile ag- giungere o rimuovere i nodi e modificare le procedure di interrogazione e no- tifica. Viene, inoltre, fornita una breve descrizione per ogni operazione ese- guibile come ulteriore ausilio all'utilizzo. • View Events : fornisce una lista di tutti gli avvenimenti verificatisi su un par- ticolare nodo. • Asset Info : consente di scrivere o leggere informazioni di carattere generale relative al nodo. • Response Time : visualizza i grafici dei tempi di risposta relativi ad alcuni protocolli o servizi (DNS, ICMP, etc.). • SNMP Performance : visualizza i grafici dei dati SNMP raccolti riguardanti ad esempio il traffico in ingresso e in uscita, la memoria disponibile o l'utiliz- zo della CPU. • Rescan : effettua una nuova interrogazione di un nodo. 53
  • 54. OpenNMS Figura 3.3 Schermata Admin Si passa quindi ad un'analisi più dettagliata sulla metodologia di funzionamento di OpenNMS per poter effettuare le opportune modifiche atte a soddisfare le specifi- che esigenze per la gestione della rete. 54
  • 55. OpenNMS 3.3.1 OpenNMS Discovery Quando OpenNMS viene lanciato, automaticamente viene eseguita un proce- dura di discovery, che consiste nell'effettuare una serie di pings su un determinato range di indirizzi IP, per controllare la presenza di tutte le interfacce attive sulla re- te. Tale procedura di ricerca è regolamentata dal contenuto del file discoverycon- figuration.xml presente nella cartella /etc/opennms. Il suo contenuto è riportato di seguito: <discovery-configuration threads="1" packets-persecond="1" initial-sleep-time="300000" restart-sleeptime="86400000" retries="3" timeout="800"> <include-range retries="2" timeout="3000"> <begin>192.168.0.1</begin> <end>192.168.0.254</end> </include-range> <include-url> file:/opt/OpenNMS/etc/include </includeurl> </discovery-configuration> 55
  • 56. OpenNMS I campi contenuti in tale file hanno i seguenti significati: • Threads: rappresenta il numero delle volte in cui viene eseguito il processo di discovery. • Packets-per-second: rappresenta il numero di pacchetti ICMP inviati al se- condo. • Initial-sleep-time: è il tempo, espresso in millisecondi, che deve trascorrere dopo l'avvio di OpenNMS perchè il processo di discovery possa iniziare. • Restart-sleep-time: è il tempo che deve passare prima che il processo di di- scovery ricominci. • Timeout: rappresenta la soglia di tempo limite in cui il sistema aspetta una risposta da un particolare indirizzo IP. • Retries: indica il numero di tentativi effettuati prima di decidere che l'indiriz- zo IP interrogato in realtà non esiste. Resta da definire qual'è il range di indirizzi da scandagliare o quale quello da escludere, per far ciò esistono quattro modalità: 1. <specific>ip-address</specific>: dove ip-address è l'indirizzo specifico che si vuole interrogare. 2. Specificando l’indirizzo iniziale e quello finale <include-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </include-range> 56
  • 57. OpenNMS 3. Escludendo un certo range di indirizzi <exclude-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </exclude-range> 4. <include-url>file:filename</include-url>: dove filename indica un path in cui vi è un file di testo con una lista di indirizzi IP. Il processo di discovery può essere analizzato tramite il file discovery.log creato nella cartella /var/log/opennms, infatti questo processo può essere comunque evitato per poter aggiungere un nuovo nodo da monitorare, infatti si può fare in maniera immediata aggiungendo il nuovo indirizzo IP tramite l'interfaccia web nella sezione “admin” -> “add interface” seguendo le indicazioni riportate. Tuttavia la procedura di discovery è comunque valida in quanto in reti abbastanza estese è facile che si aggiungano nuovi nodi prima che l'amministratore ne venga a conoscenza. Per cui il sistema stesso, anche se con una certa latenza, risulta comun- que in grado di rilevare una nuova entità. 57
  • 58. OpenNMS 3.3.2 OpenNMS Capsd Mentre il processo di discovery si occupa solo di scoprire un nuovo nodo pre- sente sulla rete, chi raccoglie le informazioni generiche relative alla nuova macchi- na è il demone capsd, il cui funzionamento è regolamentato dal file di configurazio- ne capsd-configuration.xml. Tramite questo demone, OpenNMS verifica l'esistenza di un particolare servi- zio attraverso la ricerca dei seguenti protocolli e applicativi: • Citrix • DHCP • DNS • Domino IIOP • FTP • HTTPS • HTTP • ICMP • LDAP • Microsoft Exchange • Notes HTTP • POP3 • SMB • SMTP • SNMP • TCP 58
  • 59. OpenNMS Le prime righe che si incontrano in capsd-configuration.xml descrivono il suo fun- zionamento: <capsd-configuration rescan-frequency="86400000" initial-sleep-time="300000" management-policy="managed" max-suspect-thread-pool-size = "6" max-rescan-thread-pool-size = "3" abort-protocol-scans-if-no-route = "false"> Capsd effettua una ricerca continua su ogni interfaccia per verificare se nuovi servizi vengono aggiunti. La frequenza con cui tale ricerca viene effettuata è stabili- ta dal campo rescan-frequency espresso in millisecondi. Come per il processo di discovery, capsd aspetta un certo periodo di tempo, initial-sleep-time, per iniziare la sua raccolta dati dopo che OpenNMS è partito. Il parametro management-policy regolamenta il comportamento di capsd. In pratica “settando” tale campo al valore “managed” si fa in modo che capsd raccolga informazioni solo per quel range di indirizzi IP, definiti alla fine del file, che sono indicati con “managed”. All'interno di capsd-configuration.xml è contenuta una sezione per ognuno dei servizi sopra elencati. Ad esempio per il protocollo ICMP troviamo la seguente configurazione: <protocol-plugin protocol = "ICMP" class-name="org.opennms.netmgt.capsd.Icmp.Plugin" scan = "on" user-defined ="false"> <property key = "timeout" value = "2000"/> <property key = "retry" value = "2"/> </protocol-plugin> 59
  • 60. OpenNMS Ogni volta che un nuovo nodo viene aggiunto il demone capsd inizia ad inter- rogare la relativa interfaccia alla scoperta di tutti i servizi presenti in modo da moni- torarne lo stato di funzionamento. Un servizio o un protocollo che non sia stato scoperto o contemplato dal de- mone capsd non potrà essere gestito o monitorato da OpenNMS per cui è necessario verificare che tutti i nodi che vengono aggiunti nel sistema abbiano un indirizzo IP compreso nel range di indirizzi definito all'interno di capsd-configuration.xml. 3.3.3 OpenNMS Polling Il processo di polling, già descritto all'inizio di questo capitolo, è configurabi- le in OpenNMS modificando opportunamente il file di configurazione pollerconfi- guration.xml che si trova nella directory /etc/opennms. Esaminandone il contenuto si trova: <poller-configuration threads="30" serviceUnresponsiveEnabled="false"> <node-outage status="on" pollAllIfNoCriticalServiceDefined="true"> <critical-service name="ICMP"/> </node-outage> Il processo di polling consiste (mediante un numero massimo di tentativi o threads) nello stabilire una connessione con una particolare porta di una interfaccia remota e quindi verificare periodicamente che un determinato servizio restituisca una risposta. 60
  • 61. OpenNMS Se non si riceve tale risposta entro un certo periodo di tempo, o timeout, il servizio è considerato inattivo. Nelle reti più complesse possono succedersi dei gua- sti di modesta entità, quindi può verificarsi che una risposta non giunga entro il timeout prefissato senza però che il servizio a cui si riferisce sia effettivamente inat- tivo. Per evitare queste situazioni si setta il campo serviceUnresponsiveEnabled = “true” in modo che quando una risposta non giunge in tempo il sistema notifica tale evento come “service unresponsive” e non come guasto. Quando un servizio su un nodo viene considerato definitivamente inattivo si genera un evento chiamato “NodeLostService”. Se tutti i servizi associati ad una interfaccia sono inattivi allora anche l'inter- faccia viene considerata inattiva e viene generato un evento chiamato “InterfaceDown”. Analogamente se tutte le interfacce di un nodo vengono dichiara- te inattive allora anche il nodo è considerato inattivo e l'evento corrispondente è detto “NodeDown”. Se viene generato un “NodeDown” e il campo node-outage sta- tus="on" allora tutti gli eventi di “InterfaceDown” e “NodeLostService” vengono soppressi e viene visualizzato solo quello di “NodeDown”. In questo caso invece di interrogare tutti i servizi che erano associati al nodo se ne interroga solo uno, il cri- tical service che di default è ICMP. Quando tale servizio ritornerà attivo allora il processo di polling riprenderà ad interrogare anche gli altri. OpenNMS offre la possibilità di definire dei poller packages in modo da sta- bilire dei livelli di servizio differenziati. Si può definire un poller package assegnan- do un nominativo, i servizi che si vogliono monitorare e gli indirizzi IP dove tali servizi verranno cercati a seconda dell'importanza che ognuno riveste all'interno di tutta la rete. Per ogni servizio inoltre si possono impostare i parametri relativi al polling infatti prendendo ad esempio il caso riguardante il servizio DNS: 61
  • 62. OpenNMS <service name="DNS" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="3"/> <parameter key="timeout" value="5000"/> <parameter key="port" value="53"/> <parameter key="lookup" value="localhost"/> </service> Tale configurazione ha il seguente significato: il servizio DNS viene interrogato ogni 5 minuti (interval=“300000”), tale servizio non è stato definito dall'utente (user-defined=“false2) ed il polling per questo servizio è attivo (status=“on”). 3.4 OpenNMS SNMP Finora sono stati descritti i processi di discovery e polling con cui il sistema di Network Management interroga le risorse della rete alla ricerca di nodi e servizi presenti; una volta che tali risorse sono state acquisite resta il problema di come ge- stire le informazioni ad esse relative e stabilire quali dati sono di interesse strategico per la gestione. Tali compiti sono delegati, come visto nel capitolo precedente, al protocollo SNMP. La configurazione delle operazioni SNMP con OpenNMS è possibile tramite due file allocati nella directory /etc/opennms: 1. snmp-config.xml 2. datacollection-config.xml Vedremo nei prossimi due paragrafi come effettuare le varie configurazioni. 62
  • 63. OpenNMS 3.5.1 Snmp-config.xml Snmp-config.xml stabilisce quali siano i contenuti dei parametri usati per dia- logare con i vari agents SNMP presenti sulla rete: <snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition version="v2c"> <specific>192.168.0.1</specific> </definition> <definition retry="4" timeout="2000"> <range begin="192.168.1.1" end="192.168.1.254"/> <range begin="192.168.3.1" end="192.168.3.254"/> </definition> <definition read-community="pippo" write-community="paperino"> <range begin="192.168.2.1" end="192.168.2.254"/> </definition> <definition port="1161"> <specific>192.168.5.50</specific> </definition> </snmp-config> 63
  • 64. OpenNMS I vari campi hanno i seguenti significati: • Retry: numero di tentativi che vengono effettuati per connettersi all'agent SNMP. • Timeout: il tempo, espresso in millisecondi, che OpenNMS aspetta per una risposta da parte dell'agent. • Read-community: la “read-community” di default. • Write-community: la “write-community” di default; OpenNMS non prevede la possibilità di effettuare operazioni di set. • Version: versione di SNMP utilizzata. • Port: porta di comunicazione. Si ha la possibilità di personalizzare questi parametri per ogni specifico range di indirizzi. Ad esempio per ogni sottorete si possono definire delle communities differenti o addirittura modificare il numero di porta attraverso cui stabilire lo scam- bio di informazioni. Tali soluzioni anche se non risolvono pienamente il problema sicurezza, sicuramente scoraggiano eventuali attacchi e quindi possono essere con- siderati dei buoni deterrenti. 64
  • 65. OpenNMS 3.5.2 DataCollection-config.xml Datacollection-config.xml rappresenta uno dei file più importanti di tutto il sistema poiché stabilisce quanti e quali dati debbano essere acquisiti per ogni speci- fica interfaccia. Esaminandolo in maniera dettagliata si trova: <datacollection-config rrdRepository = "/var/opennms/rrd/snmp/"> Il percorso rrdRepository indica dove vengono memorizzati i dati SNMP raccolti. Per ogni risorsa di rete viene creata una specifica cartella, identificata dal numero che OpenNMS assegna a ciascun nodo monitorato, all'interno della quale sono con- tenuti i files .rrd relativi alle statistiche. <snmp-collection name="default" maxVarsPerPdu = "50" snmpStorageFlag = "all"> Il campo maxVarsPerPdu pone un limite superiore al numero di variabili con- tenute in un pacchetto di risposta ad una GetNextRequest (se si ha un agent lento si può pensare di ridurre tale valore per non sovraccaricarlo). Il campo snmpStorage- Flag può assumere due valori “all” o “primary” a seconda che si vogliano interroga- re tutte le interfacce di un dato nodo oppure solo quella indicata come primaria. Verranno ora analizzate le definizioni di “groups” e “systems”. I primi sono costituiti da un insieme di OIDs che fanno riferimento ad un particolare gruppo di statistiche, ad esempio riferendosi al group mib2-interfaces: <group name = "mib2-interfaces" ifType = "all"> <mibObj oid=".1.3.6.1.2.1.2.2.1.10" instance="ifIndex" alias="ifInOctets" type="counter"/> 65
  • 66. OpenNMS <mibObj oid=".1.3.6.1.2.1.2.2.1.13" instance="ifIndex" alias="ifInDiscards" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.14" instance="ifIndex" alias="ifInErrors" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.16" instance="ifIndex" alias="ifOutOctets" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.19" instance="ifIndex" alias="ifOutDiscards" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.20" instance="ifIndex" alias="ifOutErrors" type="counter"/> </group> Ad ogni gruppo viene associato un nome e il tipo di interfaccia, stabilito nel campo ifType, che si intende interrogare per ottenere le informazioni relative agli OIDs riportati. I valori che può assumere ifType possono essere i seguenti: • all: vengono interrogate tutte le interfacce. • ignore: si usa quando l'informazione che si vuole ottenere riguarda una carat- teristica generale del nodo ed è quindi indipendente dall'interfaccia. 66
  • 67. OpenNMS I “systems” invece riguardano gli agent SNMP che si trovano sui nodi da mo- nitorare, ad esempio riferendosi all'agent Net-SNMP, che verrà illustrato in maniera più approfondita nel seguito di questa tesi, si trova la seguente definizione: <systemDef name = "Net-SNMP"> <sysoidMask>.1.3.6.1.4.1.2021.250.</sysoidMask> <collect> <includeGroup>mib2-interfaces-net-snmp </includeGroup> <includeGroup>mib2-host-resources-storage </includeGroup> <includeGroup>mib2-host-resources-system </includeGroup> <includeGroup>mib2-host-resources-memory </includeGroup> <includeGroup>ucd-loadavg </includeGroup> </collect> </systemDef> Il sysoidMask riguarda il system OID specifico per ogni agent. Come si nota vengo- no inclusi tutti i gruppi che interessano ai fini del monitoraggio. E' importante sotto- lineare la flessibilità che OpenNMS offre all'amministratore di rete in quanto si può usare, previa opportuna configurazione, qualsiasi tipo di agent SNMP personaliz- zando la raccolta delle statistiche secondo specifiche esigenze. 67
  • 68. OpenNMS Nelle figure sottostanti sono riportati alcuni grafici ottenibili con OpenNMS. 68
  • 69. OpenNMS Figura 3.4 Snapshots di alcuni grafici di OpenNMS Tali dati riguardano una macchina Linux equipaggiata con agent Net-SNMP e rap- presentano una porzione delle informazioni che si possono raccogliere con O- penNMS tramite le operazioni definite dal protocollo SNMP, in particolare: • Bits In/Out: le statistiche di traffico di ingresso e uscita espresse in bit/sec. • System Uptime: il periodo di tempo di accensione della macchina espresso in numero di giorni e sue frazioni. • Number of Processes: il numero di processi attivi. • Load Average: le statistiche riguardanti i valori di traffico medio raccolti su intervalli di 1, 5 e 15 minuti rispettivamente. • CPU Use: l' utilizzo della CPU. 69
  • 70. OpenNMS 3.5 Architettura Per concludere la nostra panoramica su OpenNMS, mostriamo nella figura sottostante uno schema che rappresenta l’architettura di questo software. Figura 3.5 Architettura di OpenNMS 70
  • 71. OpenNMS 3.5 Altre funzioni OpenNMS è configurabile attraverso la sezione admin per l'invio di notifica tramite posta elettronica quando si verifica un malfunzionamento di grave entità. E’ possibile integrare il servizio di e-mail [21], inviate direttamente da OpenNMS, con un servizio di SMS fornito da un operatore mobile o implementato con degli stru- menti ad hoc sfruttando ad esempio un SMS Gateway; in questo modo si ottiene uno strumento potente e vantaggioso che consente all'amministratore di rete di esse- re sicuro del funzionamento della stessa in qualsiasi momento, anche quando il si- stema lavora autonomamente senza la presenza di un operatore umano. Oltre alla notifica dei guasti, tramite posta elettronica, è possibile inviare dei rapporti periodici riguardanti il funzionamento generale dei servizi monitorati in formato pdf con la possibilità di evidenziare i nodi e i servizi meno performanti. OpenNMS consente all'amministratore di estendere l'accesso al sistema di ge- stione ad altri utenti ( gestione dell'accounting ), assegnando ad ognuno specifici privilegi. Considerato che il sistema di gestione lavora con le prime due versioni del protocollo SNMP c'è da tenere in conto il problema non banale riguardante la sicu- rezza. La trasmissione in chiaro del community name consente a qualsiasi utente non autorizzato di introdursi nel sistema e avere accesso alle informazioni di gestio- ne. Un metodo per risolvere tale inconveniente può essere quello di integrare O- penNMS con un sistema di anti-intrusione come può essere il pacchetto Snort che ad esempio generi, in caso di allarme, un messaggio di trap ad-hoc destinato alla stazione di gestione. 71
  • 72. Considerazioni finali Considerazioni finali L’obiettivo di questa tesi è la creazione di un piccolo manuale che introduca il lettore alle basi del protocollo SNMP. Questo protocollo durante il percorso della tesi ha svelato tutte le sue potenzialità ed i motivi per cui è il protocollo più diffuso per la gestione di rete, infatti nei primi capitoli si parla diffusamente del perchè que- sto protocollo si sia affermato vincendo la concorrenza di altri tool di gestione di rete. Le basi teoriche che lo supportano sono molto solide e il fatto che si utilizzi ancora la prima versione (sebbene abbia diverse lacune) dopo sedici anni dalla sua nascita è sinonimo di una buona progettazione. La definizione di nuove funzioni utilizza un linguaggio dichiarativo (ASN.1) poco chiaro e soprattutto usato in po- chissime applicazioni, ma questa problematica rimane confinata al mondo degli svi- luppatori, mentre per gli utenti questo fatto non ha nessuna rilevanza. In realtà quando si parla di estendibilità di SNMP si fa riferimento più che altro ai program- mi Manager, che possono essere facilmente migliorati con nuove funzioni, mentre gli agenti forniti sui dispositivi generalmente non permettono modifiche al software interno. Il software esaminato, OpenNMS, funziona solo su sistemi Linux e si è rivela- to uno strumento molto potente di monitoraggio di rete, infatti oltre ad avere molte funzioni mirate per il protocollo SNMP, dispone di ottime funzionalità di monito- raggio. La rielaborazione di dati è molto accurata ed è facile ottenere informazioni e grafici in merito al lavoro svolto dalla rete. Inoltre è anche possibile effettuare delle modifiche di configurazione ai dispositivi da una postazione remota, in modo da assecondare i cambiamenti continui della morfologia della rete. Nella prima parte del terzo capitolo si trova anche una spiegazione dettagliata del software necessario per installare OpenNMS, poiché la sua esecuzione necessita di diversi tool. Unico neo del protocollo è la sicurezza, questo argomento è trattato marginal- mente nella tesi in quanto viene affrontato in maniera approfondita solo nella terza versione del protocollo che ancora oggi stenta a decollare e non viene supportata da quasi nessun dispositivo. 72
  • 73. Bibliografia Bibliografia [1] RFC 789 [2] J. F. Kurose, K.W. Ross “Internet e Reti di Calcolatori”, Seconda Ed., 2003 [3] http://www.iso.org [4] RFC 2570 [5] T. Saydam, T. Magedanz “From Networks and Network Management into Service and Service Management”, Journal of Network and System Management, 1996 [6] RFC 2788 - Network Services Monitoring MIB [7] www.ietf.org [8] RFC 1155, RFC 1156, RFC 1157 [9] RFC 1450, RFC 1451, RFC 1452 [10] RFC 2571, RFC 2572, RFC 2573, RFC 2574 [11] RFC 768 [12] “ACE-SNMP, an introductory overview on SNMP”, http://www.ddri.com. [13] RFC 1098 [14] “SNMP Devoloper’s Guide – HP OpenView Integration Series”, Cap. 2 “An Overview on SNMP” [15] RFC 3727 [16] http://www.opennms.org [17] http://www.sun.com [18] http://jakarta.apache.org/tomcat/ [19] http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ [20] http://www.postgresql.org/ [21] http://etd.adm.unipi.it/theses/available/etd-4062005-143133/unrestricted/ Capitolo3.pdf [22] RFC 3139 [23] RFC 1213 73
  • 74. Elenco delle figure Elenco delle figure Figura 1.1 Schema di rete Figura 2.1 Implementazione Client/Server Figura 2.2 Scambio di messaggi SNMPv1 Figura 2.3 Livello di scambio dei messaggi SNMP Figura 2.4 Struttura Pacchetto SNMP Figura 2.5 Scambio di messaggi SNMPv2 Figura 2.6 Incapsulamento dei messaggi Figura 2.7 Traduzione di un valore in dot-notation Figura 2.8 Albero MIB – Root and Subtree Figura 2.9 Albero MIB – Leaf Figura 3.1 Schermata principale di OpenNMS Figura 3.2 Nodo Linux Figura 3.3 Schermata Admin Figura 3.4 Snapshots di alcuni grafici di OpenNMS Figura 3.5 Architettura di OpenNMS 74