Il protocollo SNMP Simple Network Management System

Transcript

1 Il protocollo SNMP Simple Network Management System Approfondimento per il corso di Reti di Calcolatori Prof. S. Balsamo Università Ca Foscari Venezia Anno Accademico Roberta Vettorel Giorgia Zanetti

2

3 INDICE 1. INTRODUZIONE Gestione delle performance di rete (dal PING alla nascita di SNMP) SNMP, CMIP, RMON : tre protocolli a confronto SNMP: dove va collocato nel modello TCP/IP 8 2. IL MODELLO SNMP : una visione d insieme Stazione di Gestione (NMS) Nodi Gestiti e Agente di Gestione (Agent) Informazioni di Gestione e MIB (Management Information Base) Protocollo di Gestione Problematiche IL MODELLO SNMP : una visione dettagliata Il modello Manager/Agent/Managed object Struttura delle informazioni di gestione(smi) Struttura dei MIB Definizione di oggetti scalari Definizione di tabelle Ordinamento degli OID MIBs Standard: MIB-II Il protocollo di gestione SNMP Comunicazione tra Manager ed Agente Formato dei messaggi SNMP Trasmissione di un messaggio SNMP Ricezione di un messaggio SNMP Scambio di messaggi SNMP EVOLUZIONE DEL PROTOCOLLO SNMP Limitazione dell SNMP Cenni su SNMPv Cenni su SNMPv Protocollo AgentX Uno sguardo al futuro 51

4 5. APPLICAZIONI PER LA GESTIONE DELLA RETE Scelta della stazione di gestione Dislocazione della NMS MRTG OPEN NMS SNMPc 61 APPENDICE A Note degli autori 64 B Bibliografia 65

5 INDICE DELLE FIGURE Fig 1 Schema logico dell architettura MANAGER/AGENT 10 Fig 2 Architettura del sistema di gestione SNMP 13 Fig 3 Comunicazione Manager/Agent 19 Fig 4 Rappresentazione delle interazioni nel modello Manager/Agent 19 Fig 5 Albero dei nomi degli oggetti SMI o struttura generica del MIB 22 Fig 6 Struttura di un MIB 24 Fig 7 Esempio di tabella 27 Fig 8 Rappresentazione ad albero della tabella di Fig 7 29 Fig 9 Identificazione di istanze in una tabella 30 Fig 10 Ordine lessico-grafico degli OID e visita dell albero MIB 31 Fig 11 Gruppi costituenti la MIB-II 32 Fig 12 Stack ISO/OSI 35 Fig 13 Generico sistema SNMP 36 Fig 14 Interazione Manager - Agente 36 Fig 15 Scambio di messaggi in SNMP 38 Fig 16 Formato di un generico messaggio SNMP 39 Fig 17 SNMP PDU GetRequest, GetNextRequest, SetRequest 39 Fig 18 SNMP PDU GetResponse 39 Fig 19 SNMP PDU Trap 39 Fig 20 Variable-bindings 40 Fig 21 Scambi di messaggi 42 Fig 22 SNMP e i documenti dello standard 47 Fig 23 Protocollo AgentX 49 Fig 24 Struttura di un agente Agent-X 50 Fig 25 Esempio di network distribuito 54 Fig 26 MRTG Esempi 57 Fig 27 OpenNMS Home 59 Fig 28 OpenNMS Esempi 60 Fig 29 Architettura di SNMPc 61 Fig 30 Esempi di mappa della rete 62 Fig 31 SNMPc - Trend Report 63 Fig 32 SNMPc - Esempi di grafici 63

6 CAPITOLO 1 INTRODUZIONE 1.1 GESTIONE DELLE PERFORMANCE DI RETE (Dal PING alla nascita di SNMP) Le reti ed i sistemi di elaborazione distribuiti stanno diventando sempre più importanti ed, allo stesso tempo, sempre più critici per il mondo dell Information Technology. Si sta infatti assistendo, ad ogni livello nella scala delle organizzazioni, alla nascita di reti sempre più complesse, che supportano un numero sempre più maggiore di utenti, di applicazioni e servizi offerti. Come conseguenza di ciò si hanno due possibili effetti che non è possibile tralasciare: La rete dell organizzazione diventa indispensabile per il corretto funzionamento di tutti i processi che ne delineano l attività. Di pari passo alla crescita delle reti, si ha inoltre l aumento degli aspetti critici di cui tener conto; come è ovvio, infatti, in una struttura complessa come può essere un sistema di rete, l interazione tra i vari componenti fa si che un piccolo guasto possa comportare un blocco totale della rete o di parte di essa, oppure degradare la performance a livelli inaccettabili. 1

7 Da ciò si deduce che un attività di amministrazione dei componenti della rete diviene sempre più indispensabile. Il concetto di amministrazione della rete è alquanto articolato. Esso implica attività quali l individuazione e la gestione dei vari elementi della rete (host,gateway,router,proxy ), il monitoraggio delle sue prestazioni, l inventario dell hardware e del software presente in una rete e molto altro ancora. Facciamo un esempio pratico. L amministratore di una rete locale vuole verificare se un nuovo anello di macchine appena installato opera in modo efficiente. Per far questo deve poter tenere sotto controllo il carico di rete nell anello, l utilizzo della larghezza di banda, il numero di pacchetti che si perdono, quelli rispediti a causa di eventuali problemi e via dicendo. Fino agli anni 80, la misurazione delle performance di una rete veniva effettuata attraverso semplici programmi a linea di comando: PING: il comando ping fa parte della dotazione standard di tutte le macchine Unix e Windows anche se con sintassi leggermente diverse. Esso invia una successione di pacchetti ICMP ECHO_REQUEST e attende la relativa risposta ECHO_REPLY (CONTROLLO DI RAGGIUNGIBILITA DI UN HOST). Misura il tempo che intercorre tra l invio e la ricezione di ogni pacchetto e riporta semplici statistiche. Ping serve principalmente a vedere se una certa macchina di rete è attiva oppure no. Il pacchetti ICMP sono usati da host, router e gateway per comunicare informazioni riguardanti il livello di rete, in particolare errori. ICMP è appunto un protocollo di supporto funzionale ad IP, ovvero il suo compito è di portare informazioni di controllo e notifica di errori e non di offrire direttamente servizi. Tenendo presente che i pacchetti ICMP viaggiano all interno di pacchetti IP, ICMP è considerato un protocollo di livello rete. 2

8 TRACEROUTE: il comando traceroute permette di capire per quali router passano i pacchetti IP quando sono diretti ad una data destinazione ovvero come si arriva ad un dispositivo remoto. Analizza il percorso dei pacchetti attraverso l invio di una serie di pacchetti ICMP con TTL crescente. E compreso nella dotazione standard dei sistemi Unix, mentre nei sistemi Windows il comando ha il nome tracert e sintassi leggermente differente. Traceroute è molto utile anche dal punto di vista didattico perché permette di mostrare il percorso dei pacchetti IP svelando un po della topologia nascosta di Internet. Poiché le tabelle di instradamento dei router non sono sempre corrette, è possibile che un pacchetto entri in cicli da cui non riesca ad uscire. Per evitare congestioni dovute a situazioni di questo tipo, si fissa un limite di tempo entro cui un pacchetto può restare sulla rete. Nei pacchetti IP il campo Time-To-Live (TTL) misura il tempo di vita rimanente al pacchetto. Ciascun router deve decrementare il TTL di almeno una unità. Nella pratica, i pacchetti raramente rimangono in un router per più di un secondo ed i router semplicemente decrementano di uno il TTL prima di instradare il pacchetto. Quindi indipendentemente dal nome, il TTL conta il numero di hop che il pacchetto può fare prima di giungere a destinazione o di essere scartato. I router controllano se il TTL è uguale a zero dopo il decremento, subito prima dell inoltro. Se il destinatario del pacchetto è il router stesso questo non viene mai scartato. Qual e' l'utilità' di questo programma? Per esempio, se notiamo che il collegamento verso un sito web o ftp (o qualunque altro servizio) e' lento, possiamo usare traceroute per vedere il percorso seguito dai pacchetti, e in base all'output di traceroute e' possibile capire se il problema dipende dal nostro provider, dalla macchina destinazione, da una macchina intermedia o da un tratto di linea fisica che unisce due di queste. Oppure, se dobbiamo scaricare un file piuttosto pesante e conosciamo almeno 2 siti ftp che lo contengono, con traceroute possiamo stabilire da quale sito conviene effettuare il download. 3

9 TCPDUMP: a differenza di traceroute che ha lo scopo di visualizzare un percorso, tcpdump traccia il traffico, cioè riesco a visualizzare i contenuti di tutti pacchetti che passano per la rete analizzata. Il comando viene utilizzato per motivi di sicurezza. Questo programma permette di vedere,analizzare e studiare il traffico di una rete. Tcpdump ha limitate capacità di visualizzazione, essenzialmente fa un dump del traffico e visualizza il contenuto dell intestazione dei pacchetti TCP. Il controllo dei (pochi) dispositivi collegati alla rete veniva svolto in modo manuale, o attraverso l esecuzione di script che automatizzavano l uso dei programmi appena visti, per il controllo di un insieme di appliances di rete. La crescita esponenziale delle reti, sia dal punto di vista quantitativo (numero di host, switch, router e linee di interconnessione) sia dal punto di vista qualitativo (tipologia e topologia della rete, variabilità di tecnologie sottostanti) determinarono la necessità di un protocollo standard per la misurazione ed il controllo dei dispositivi collegati alla rete. Definire un protocollo di rete sulla base del quale si possono costruire delle applicazioni capaci di affrontare una problematica così complessa, non è certo semplice. Ovviamente è d obbligo per uno strumento di tal genere, uno standard comune, che faccia dell INTEROPERABILITA una delle caratteristiche principali. Inoltre, uno strumento del genere, con queste pretese, deve poter essere applicato ad un numero sempre maggiore di prodotti (es. bridge, router, sistemi di telecomunicazione generale.). Si ha quindi il secondo aspetto fondamentale di questo strumento: l ESPANDIBILITA. Le risposte della comunità tecnologica a queste esigenze sono state svariate, con differenti livelli di complessità e di obiettivi. I due più famosi strumenti di tal genere sono stati lo standard CMIP (Common Management Information Protocol) delineato dall ISO e l SNMP (Simple Network Management System) dell IETF. 4

10 1.2 SNMP, CMIP, RMON: TRE PROTOCOLLI A CONFRONTO I protocolli standard sono Simple Network Management Protocol (SNMP), Common Management Information Protocol (CMIP) e RMON (Remote network MONitoring), e si riferiscono al modo in cui la stazione di management comunica con gli agenti in rete. In realtà ne sono stati ideati molti altri, ma i primi sono senza dubbio i più conosciuti. Pro SNMP Semplicità Notevole diffusione Tre protocolli a confronto Contro Contenute risorse di sistema Mancanza di sicurezza Minimamente dettagliato CMIP Standard ISO/OSI Considerevoli risorse di sistema Struttura sofisticata Completo RMON Gestione proattiva Ottimo per analisi e statistiche Difficile da implementare Necessita di un protocollo complementare In ordine temporale, il primo modello di monitoraggio venuto alla luce è stato l SNMP, acronimo per Simple Network Management Protocol, un protocollo di rete che permette di raccogliere dati, controllare e gestire il funzionamento degli elementi di una rete di tipo TCP/IP, attraverso la rete stessa. Lo sviluppo di questo strumento è gestito da sempre dall organizzazione sopranazionale IETF mediante l emanazione di diverse RFC ( Request For Comment ). Al fine di superare le deficienze di tale protocollo, l OSI Network Management Forum, una organizzazione costituita da molti utenti e venditori ha realizzato un protocollo per la gestione della rete basato sul modello di comunicazione ISO/OSI (Open System Interconnection) : CMIP ( Common Management Information Protocol ) nel documento standard

11 Delineando il modello CMIP l ISO ha voluto mettere a disposizione delle reti basate sul modello OSI ( Open Interconnection System ) uno strumento mediante il quale i seguenti aspetti della gestione di una rete sono guardati con attenzione: Fallimenti di un dispositivo (Fault Management) Configurazione (Configuration Management) Gestione delle risorse (Accounting Management) Gestione delle performance e QoS (Performance Management) Gestione della sicurezza (Security Management) Senza entrare nel dettaglio di questo particolareggiato protocollo, posto al livello applicazione del modello di riferimento OSI, possiamo dire che risulta essere una soluzione completa ad un problema complesso, basata su un modello ad oggetti che coinvolge: Entità da monitorare (oggetti e loro attributi) Entità attive di monitoraggio (manager) Entità intermediarie (agenti) Un ulteriore caratteristica qualificante del protocollo CMIP consiste nella possibilità di trasferire consistenti volumi di dati, per esempio quando si deve aggiornare una parte considerevole di informazioni residenti presso un agente (applicativo software di un dispositivo da controllare). Conseguentemente alla sua struttura complessa e alle sue ricche funzionalità, CMIP necessita di risorse di sistema di molto superiori a quelle richieste dal protocollo SNMP. Come molte volte accade nel mondo dell Information Technology, però, non sempre la tecnologia migliore vince. I rispettivi vantaggi e svantaggi sono chiaramente intuibili già ad una prima visione delle caratteristiche, dove come alla complessità e completezza si contrappone la semplicità (gia dal nome simple ) dell SNMP. 6

12 A causa anche delle diverse linee di sviluppo, più dinamica quella dell IETF e più lenta e precisa quella dell ISO, con inoltre l espansione e l adozione da parte delle reti mondiali del protocollo TCP/IP, SNMP ha avuto la meglio. Da notare che il progetto dell IETF CMOT ( CMIP over TCP/IP ), ossia un documento nel quale si voleva abbinare il CMIP allo stack TCP/IP non è attualmente arrivato a risultati concreti. Per quanto riguarda la storia dell SNMP, dunque, nel maggio del 1990, fu pubblicato l RFC 1157, che definiva la prima versione di SNMP. Insieme ad un manuale sulle informazioni di gestione (RFC 1155), SNMP definiva una maniera sistematica di controllare e gestire una rete di computer. Esso nasce come una evoluzione del protocollo SGMP ( Simple Gateway Monitoring Protocol ) progettato nel 1987 e limitato alla sola gestione di router e gateway. Successivamente, nel 1995, al fine di superare le imperfezioni venute alla luce, venne definito l SNMPv2 (negli RFC da 1441 a 1452). Ancora, nel 1998, l ultima versione fu rilasciata: l SNMPv3. Fin dalla sua nascita questo protocollo si è imposto come standard de facto per la gestione delle reti, ed è, come ogni standard, sempre in via di miglioramento. In aggiunta all SNMP puro, nel 1991 è stato altresì definito un supplemento dell SNMP, chiamato RMON, Remote Network Monitoring, (aggiornato dal 1995 a RMON2). Anche se è descritto come una specifica, RMON è, a tutti gli effetti, un protocollo specializzato per la gestione remota di dispositivi di rete. In generale viene utilizzato assieme ad SNMP, delle cui funzionalità è in sostanza complementare. L obiettivo del protocollo è consentire la formulazione di statistiche e analisi del traffico di rete, al fine di diagnosticare eventuali problemi, effettuare pianificazioni e mettere a punto le prestazioni. 7

13 RMON consente la gestione proattiva della rete tramite la sua potente funzionalità denominata "alarm group". RMON è supportato da dispositivi di monitoring detti probe o sonde, attraverso il software da installare nei dispositivi esistenti oppure da componenti hardware e software combinati. Negli agenti intelligenti, sistemati nei segmenti di LAN da controllare, vengono impostate le soglie relative ai parametri critici della rete (per esempio la percentuale di utilizzo di una linea di trasmissione dati oppure della CPU di un server); quando la soglia sta per essere raggiunta, sono loro a inviare le segnalazioni di allarme alla console centrale. RMON è prezioso anche come strumento di analisi: per esempio, uno switch dotato del modulo RMON può catturare le informazioni che sono d interesse, memorizzarle nel suo MIB, e mostrarle sotto forma grafica all amministratore della rete quando viene interpellato. Non è un protocollo concorrente di CMIP né tanto meno di SNMP, di cui è una naturale estensione, e si sta diffondendo rapidamente in quanto è snello - non richiede particolari risorse - e semplice da installare. 1.3 SNMP: dove va collocato nel modello TCP/IP SNMP è un protocollo di livello applicazione che usa UDP come protocollo di trasporto. E stato scelto UDP, e non TCP, in modo da minimizzare il traffico di rete: TCP, essendo orientato alla connessione, avrebbe richiesto più risorse di rete. Il lato negativo è che non si ha la certezza che il messaggio arrivi, o detto in altri termini, il protocollo sottostante (UDP) non garantisce la consegna di messaggi. Vedremo in seguito che questi problemi sono stati risolti dalle componenti di una rete che si basa sul protocollo SNMP (Stazione di gestione). Inoltre la scelta di UDP è stata dettata dalla considerazione che SNMP è nato per gestire le performance di rete. Un eventuale problema di congestione della rete sarebbe ulteriormente aggravato dall utilizzo di TCP e dal suo controllo di flusso. 8

14 CAPITOLO 2 IL MODELLO SNMP UNA VISIONE D INSIEME Il protocollo SNMP è stato creato per operare come protocollo di rete al livello applicativo dello stack TCP/IP. Si basa, per la comunicazione, sul protocollo UDP. L architettura di cui il protocollo SNMP fa parte, è detta Internet Network Management Framework. Il management di una rete include la distribuzione, l integrazione e la coordinazione di risorse hardware, software ed umane per monitorare, testare, configurare, analizzare, interrogare e controllare la rete e le sue risorse per valutarne le performance operative e la qualità. 1. L architettura si basa sul concetto di Manager/Agent: infatti per svolgere tali funzionalità il centro di gestione interagisce con i network element da gestire attraverso un infrastruttura di comunicazione dedicata al trasporto delle informazioni di gestione (rete di gestione sovrapposta alla rete gestita), oppure attraverso la stessa rete gestita. Tale colloquio si attua attraverso meccanismi di comunicazione che possono essere proprietari, cioè realizzati da un costruttore in modo specifico per la gestione dei propri apparati, oppure come nel nostro caso standardizzati attraverso un protocollo. 2. Alla base della gestione di rete c è l introduzione negli apparati di rete di una strumentazione sempre più completa e sofisticata, in grado di raccogliere una enorme quantità di dati dagli apparati: configurazione e parametri operativi dei singoli elementi che compongono ciascun dispositivo, dati di traffico, tassi di errore, ecc.. Il compito del gestore è quello di analizzare tale massa di informazioni, riconoscere eventuali stati di funzionamento anomalo ed effettuare le operazioni necessarie per ripristinare il corretto funzionamento della rete. 9

15 3. Alla base della gestione di rete c è quindi un colloquio tra la stazione di gestione e l apparato gestito. Tale colloquio si esplica in particolare tra due entità, realizzate per mezzo di processi software, denominate rispettivamente Manager, nel centro di gestione, ed Agent, nel nodo gestito. 4. Il trasferimento di informazioni tra Manager ed Agent avviene in accordo ad un insieme di regole, sintattiche e semantiche, che costituiscono il protocollo di gestione. Il protocollo di gestione è un protocollo di livello applicativo che si appoggia sulla pila protocollare sottostante. Uno schema logico di tale architettura è riportato di seguito: Fig 1 : Schema logico dell architettura Manager/Agent L architettura per la gestione di rete che si basa sul protocollo SNMP comprende essenzialmente i seguenti elementi: Stazione di Gestione (NMS o Manager) Nodi Gestiti e Agente di Gestione (AGENT) Management Information Base (MIB) Protocollo per la gestione di rete 10

16 2.1 STAZIONE DI GESTIONE (NMS) E tipicamente un dispositivo (o più) che funziona da interfaccia tra l amministratore di rete ed il sistema da gestire. Sono nella maggioranza dei casi normali calcolatori che seguono un software speciale di gestione. Tale stazione sarà costituita dai seguenti blocchi funzionali: Uno o più processi che comunicano con gli agenti sulla rete (vedi 2.2), inviando comandi e ricevendo risposte. Una interfaccia (console o grafica) attraverso la quale l amministratore può controllare lo stato della rete ed intervenire quando necessario. Un database contenente le informazioni (o, meglio, il tipo delle informazioni) che la stazione può ottenere dai vari dispositivi (attraverso gli agent). E il MIB (vedi 2.3). Presentare le informazioni in modo da essere immediatamente comprensibili all utente (es: attraverso dei grafici) La capacità di traslare le richieste effettuate dal sistema sovrastante (applicazione) in formato standard comprensibile per i vari agenti remoti Gestire le trap, ovvero le segnalazioni di errore da parte degli agenti Nel modello SNMP tutta l intelligenza è mantenuta nelle stazioni di gestione, in modo da tenere gli agenti il più possibile semplici e minimizzare l effetto sui dispositivi in cui girano. Secondo la teoria delle applicazioni client/server, il client è la componente che ha un ruolo proattivo (ovvero si occupa di iniziare le transazioni), mentre il server è la componente passiva (ovvero rimane in attesa delle richieste da parte del client). Una rete SNMP può essere vista come un sistema distribuito di tipo client/server atipico: i client (le stazioni di gestione) sono in numero molto minore rispetto ai server (agenti di gestione). Inoltre, il ruolo client/server si capovolge solo nel caso di eccezioni (trap) che si verificano negli agenti: è l agente stesso che notifica alle stazioni di gestione (server) un problema. 11

17 2.2 NODI GESTITI E AGENTE DI GESTIONE (AGENT) I nodi gestiti sono dispositivi di rete (bridges, router, hubs, stampanti etc...), workstation, server, applicazioni software: qualunque entità o nodo in grado di eseguire un particolare applicativo, agent. Quest ultimo è un processo presente sui vari dispositivi della rete che risponde alle richieste di informazioni da parte della stazione di gestione, ed esegue operazioni imposte da quest ultima. Inoltre può comunicare con essa in modo asincrono, generando eventi urgenti. Ogni agente mantiene un database locale (nel senso suddetto di database MIB) di variabili, che descrive lo stato del dispositivo e che influenza le sue operazioni. Scopi degli agenti sono: mantenere un insieme di variabili organizzate gerarchicamente. Tali variabili contengono lo stato e la storia del dispositivo, oppure consentono, se modificate, di intervenire sul comportamento del nodo stesso (Tenere traccia e modificare la configurazione del dispositivo). Consentire la letture o la modifica di queste variabili da parte dei processi autorizzati Rileva malfunzionamenti del dispositivo o azioni significative che lo interessando, segnalandolo alla stazione di gestione tramite l invio di eventi (TRAP). Risponde ai comandi inviati dalla stazione di gestione 12

18 Questo modello assume che ogni nodo gestito possa eseguire al proprio interno un agente SNMP. Ci sono alcuni dispositivi vecchi o che in origine non erano stati pensati per un utilizzo in rete che non hanno queste possibilità. Per gestirli SNMP definisce ciò che viene chiamato un agente proxy, di fatto un agente che controlla uno o più dispositivi non SNMP e che comunica con la stazione di gestione riguardo la loro affidabilità, e con dei dispositivi stessi mediante protocolli non standard. Fig 2 : Architettura del sistema di gestione SNMP 13

19 2.3 MANAGEMENT IFORMATION BASE (MIB) Come si è visto nei punti precedenti, di fondamentale importanza risulta essere la definizione di cosa e come queste informazioni di gestione devono essere scambiate. Si è parlato genericamente di database, vediamo nello specifico questi due aspetti del protocollo. La maggior parte delle reti nella realtà hanno componenti di provenienza diversa, con host di uno o più costruttori, bridge e router di altri produttori e stampanti di altri ancora. Per permettere ad una stazione di gestione (potenzialmente ancora di un altro produttore) di colloquiare con tutti questi componenti diversi, bisogna che l informazione mantenuta da essi sia rigidamente specificata. E inutile che una stazione di gestione chieda ad un router qual è il suo tasso di perdita di pacchetti, se il router non ne serba memoria. Perciò SNMP descrive l informazione precisa che ogni tipo di agente deve mantenere e il formato che gli deve essere fornito. In breve, ogni dispositivo conserva una o più variabili che descrivono il suo stato. Nella letteratura SNMP queste variabili sono dette OGGETTI, ma il termine è impreciso in quanto non sono oggetti nel senso di un sistema orientato agli oggetti dato che hanno solamente lo stato e nessun metodo (eccetto che per leggerne e scriverne il valore). Il database summenzionato è chiamato MIB ( Management Information Base ), e contiene la collezione di tutte le possibili informazioni (oggetti) prelevabili dalla rete da parte della stazione di gestione. Nel Manager è quindi contenuto l intero database MIB (o la parte afferente alla specifica rete). Negli Agent invece, è presente esclusivamente quella parte di MIB per la quale ha senso per l Agente mantenere lo stato. E interessante notare che le informazioni utilizzate dalla stazione di gestione sono memorizzate all interno dei MIB locali dei dispositivi gestiti, che costituiscono quindi un sistema distribuito. 14

20 Questo database MIB, come vedremo, non è una struttura piatta (ad esempio un puro elenco di voci ), bensì è organizzato in forma gerarchica ad albero, con ciascun oggetto afferente al sotto-albero che lo rappresenta meglio. E importante chiarire che, anche se nella terminologia comune si usa il termine database per definire il MIB, questo non è un database nel senso stretto del termine. Non contiene dati, non mantiene neanche i dati prelevati dai dispositivi monitorati. Semplicemente il MIB è la descrizione di cosa il Manager può richiedere. Si può vedere come una specie di contratto fra entità coinvolte, in modo da far sapere a tutti cosa è ottenibile e come. SMI ( Structured Management Information ) definisce le modalità con cui le informazioni di gestione sono strutturate internamente, si occupa quindi di definire le strutture o il formato dei dati di SNMP. 2.4 PROTOCOLLO DI GESTIONE La stazione di gestione interagisce con gli agenti mediante il protocollo SNMP. Questo protocollo permette alla stazione di gestione di richiedere lo stato degli oggetti locali di un agente, e di modificarli se necessario. Essenzialmente SNMP consiste in comunicazioni di tipo domanda-risposta. Presenta le seguenti caratteristiche: Consente alla stazione di gestione di recuperare dall Agente il valore degli oggetti mediante dei comandi di GET; Consente alla stazione di gestione di inizializzare il valore degli oggetti gestiti dall agente mediante dei comandi di SET; Consente all Agente di comunicare in modo asincrono alla stazione di gestione il verificarsi di determinati eventi significativi medianti comandi di TRAP; E un protocollo di tipo CLIENT/SERVER che sfrutta UDP come protocollo di trasporto 15

21 2.5 PROBLEMATICHE Il problema maggiore di SNMP riguarda la sicurezza e l autenticazione. Una stazione di gestione è in grado di assumere una grande quantità di informazioni su ogni nodo che controlla e anche di fare shut down di tutti. E quindi enormemente importante che gli agenti siano sicuri che le richieste che presumibilmente arrivano dalla stazione di gestione siano effettivamente inviate dalla stazione di gestione. Nel SNMP versione 1 è proprio la stazione di gestione che ha la sua identità inserendo una password (in chiaro) in ogni messaggio. Nel SNMP versione 2 la sicurezza è stata migliorata in maniera considerevole mediante tecniche moderne di crittografia. In ogni modo, questa aggiunta ha reso il protocollo ancora più pesante. Nel frattempo, per proteggere gli agenti da stazioni di gestione non autorizzate è necessario: Utilizzare firewall per filtrare il traffico SNMP proveniente dall esterno dell organizzazione (utilizzando un filtro sulle porte 161 e 162 usati di default dal protocollo) Contemporaneamente, limitare l accesso solo ai nodi con determinati indirizzi IP (ciò non è comunque sufficiente visto che con questo protocollo è possibile fare IP-spoofing). 16

22 CAPITOLO 3 IL MODELLO SNMP UNA VISIONE DETTAGLIATA Ricordando che SNMP è un protocollo di livello applicazione ma che sfrutta UDP come protocollo di trasporto si era precedentemente segnalato il suo lato negativo, ovvero la non certezza che il messaggio arrivi. Detto in altri termini, il fatto che il protocollo di trasporto UDP non garantisce la consegna dei messaggi. Questo problema può essere semplicemente risolto dalla stazione di gestione: dopo aver mandato il messaggio all agente, fa partire un timeout. Se alla scadenza dello stesso non è ancora giunta la risposta, la stazione di gestione spedisce nuovamente la richiesta. Inoltre la scelta di UDP è stata dettata dalla considerazione che SNMP è nato per gestire le performance di rete. La mancanza di affidabilità non può essere risolta sempre con i timeout. Come visto prima, se accadono certi eventi (es: caduta di connessioni, overload del server.) nel nodo monitorato, l agente può informare le proprie stazioni di controllo attraverso un messaggio chiamato trap. Se questo messaggio viene perso, non c è modo di recuperarlo visto che gli agenti non si aspettano un ack da parte delle NMS. Una soluzione a questo problema può essere fare polling costantemente anche per rilevare trap (polling orientato ai trap). Come proteggere gli agenti: le communities Le community sono le password usate per accedere alle variabili (oggetti) gestite da un agente. Esistono tre community, ciascuna per un differente privilegio di accesso: read, read/write,trap (per ricevere le notifiche degli eventi). E possibile specificare più di una community per ogni classe di accesso. Inoltre è possibile anche limitare l accesso in base all ip della stazione di controllo. Questo accorgimento non è sufficiente, in realtà: un utente malintenzionato potrebbe fare ip- spoofing, usando un indirizzo che presume trusted dall agente, e impostare a piacere le variabili con classe di accesso read/write- Non può leggere i valori poiché il PDU di ritorno è indirizzato all IP spoofed (non al malintenzionato). 17