Università degli studi di Firenze Facoltà di Scienze Matematiche, Fisiche e Naturali. Laboratorio di Reti di Calcolatori

Transcript

1 Università degli studi di Firenze Facoltà di Scienze Matematiche, Fisiche e Naturali Laboratorio di Reti di Calcolatori SNMP Simple Network Management Protocol Santoro Umberto Roberto 21 febbraio

2 Introduzione Una rete di calcolatori consiste di molti parti complesse di hardware e software che interagiscano tra di loro: dai link, bridge, router, host ed altri dispositivi che comprendono componenti fisici della rete, ai molti protocolli(sia hardware sia software) che controllano e coordinano questi dispositivi. Quando centinaia o migliaia di questi dispositivi sono raggruppati insieme a formare una rete, non deve sorprendere che i componenti possono occasionalmente guastarsi, che gli elementi della rete possano perdere configurazione, che le risorse di rete possano essere sovrautilizzate o che i componenti della rete semplicemente si rompano (per esempio, un cavo potrebbe essere tagliato.) Il responsabile della rete, il cui lavoro è quello di mantenere la rete funzionante, deve essere in grado di rispondere a (e meglio ancora, evitare) questi incidenti. Con potenzialmente migliaia di componenti delle reti sparse su una grande area, il responsabile in un centro operativo di rete (NOC, Network Operations Center ) ha l assoluta necessità di attrezzi che lo aiutano in monitoraggio, gestione e controllo della rete. In questa relazione esamineremo l architettura, i protocolli e le informazioni base usate dal responsabile della rete per questi compiti. 2

3 Cos è la gestione della rete? Cominciamo con un semplice esempio. La figura 1.01 mostra una piccola rete che consiste di 4 router e di un paio di host. Anche in un rete così semplice ci sono molti scenari in cui un responsabile della rete può trarre enorme profitto dall avere gli appropriati attrezzi per la sua gestione: Figura 1.01 Un semplice scenario che illustra gli usi della gestione della rete. Guasto di una schede d interfaccia a un host o a un router. Con gli appropriati attrezzi di gestione della rete, un entità di rete (per esempio il router più a destra) può segnalare al responsabile della rete che una delle sue interfacce è fuori servizio. (Questo è certamente preferibile ad una chiamata telefonica 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 irascibilità dell utente rilevando in anticipo i problemi alle interfacce e sostituendo la scheda prima che si guasti. Questo può essere fatto, per esempio, se il responsabile ha notato un incremento degli errori di checksum nei frame che sono stati inviati attraverso l interfaccia prossima al guasto. 3

4 Monitoraggio degli host. Qui, il responsabile della rete può controllare periodicamente che tutti gli host della rete siano pronti e operativi. Ancora una volta, il responsabile della rete può essere in grado di anticipare la risposta ad un problema (un host fuori uso) prima che sia riferito ad un utente. Monitoraggio del traffico per aiutare la mobilitazione delle risorse. Un responsabile della rete può monitorare gli schemi del traffico da sorgente a destinazione e rilevare, per esempio, che attraverso la commutazione dei server fra i segmenti LAN, la quantità di traffico che attraversa molte LAN può diminuire significativamente. Attraverso il monitoraggio dell utilizzazione dei link, un responsabile della rete può determinare che un segmento LAN, o il link verso il mondo esterno sia sovraccarico e che è necessario un link con larghezza di banda superiore, che dovrà quindi essere approvvigionato. Il responsabile della rete può anche desiderare la notifica automatica nel caso in cui i livelli di congestione su un link eccedano un dato valore di soglia, per poter mettere a disposizione un link con larghezza di banda superiore prima che la congestione diventi seria. Rilevazione rapida dei cambiamenti nella tabella di instradamento. La fluttuazione dei percorsi (Variazioni frequenti nella tabella di instradamento) possono indicare instabilità nell instradamento o perdita di configurazione dei router. Certamente il responsabile della rete che ha impropriamente configurato un router preferirà scoprire da solo l errore, prima che la rete si blocchi. Monitoraggio degli SLA. Con l avvento dei contratti a livello di servizio (SLA, Services Level Agreements ) (contratti che definiscono specifiche prestazioni misurabili e accettabili livelli di prestazioni dei provider di rete per il rispetto delle stesse). Questi SLA comprendono disponibilità del servizio (o interruzione), latenza, throughput e requisiti di notificazione dell interruzione. E chiaro che se i criteri di prestazione devono essere parte di un contratto fra un provider 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 quanto traffico in rete arriva da o è diretto ad una sorgente sospetta (per esempio, host o 4

5 numero di porta). In modo analogo, il responsabile può desiderare rilevare (e in molti casi filtrare) l esistenza di certi tipi di traffico. L International Organization for Standards (ISO) ha creato un modello di gestione di rete che è utile per collocare gli scenari aneddotici descritti sopra in uno schema più strutturato. Sono definite cinque aree di gestione delle rete: 1. Gestione delle prestazioni. L obbiettivo della gestione delle prestazioni è di quantificare, misurare, stendere rapporti, analizzare e controllare le prestazioni di differenti componenti di rete. Questi componenti comprendono sia dispositivi singoli (per esempio, link, router, host ), sia astrazioni end-to-end come un percorso attraverso la rete. Gli standard del protocollo, come il protocollo semplice per la gestione delle reti (SNMP, Simple Network Management Protocol), hanno un ruolo centrale nella gestione delle prestazioni in Internet. 2. Gestione dei guasti. L obiettivo della gestione dei guasti è di registrare, rilevare e rispondere alle condizioni di guasto nella rete. La linea di separazione tra gestione dei guasti e gestione delle prestazioni è piuttosto confusa. Possiamo pensare alla gestione dei guasti come nell immediato intervento su un difetto transitorio della rete (per esempio, interruzione di in servizio di un link, un host o router, di hardware o software), mentre nella gestione delle prestazioni agisce in tempi più lunghi, per fornire livelli accettabili di prestazioni di fronte al variare delle richieste di traffico e all occasionale guasto di un dispositivo di rete. Come nella gestione delle prestazioni, il protocollo SNMP ha un ruolo centrale nella gestione dei guasti. 3. Gestione della contabilità (accounting). La gestione della contabilità permette al responsabile della rete di specificare registrazioni e controllare l accesso 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à. 4. Gestione della configurazione. La gestione delle configurazioni permette ad un responsabile di rete di seguire i dispositivi che appartengono alla rete gestita e di effettuare la configurazione hardware e software. 5

6 5. Gestione della sicurezza. L obbiettivo della gestione della sicurezza è di controllare gli accessi alle risorse di rete in accordo ad alcune politiche ben definite (per esempio, i firewall vengono utilizzati per monitorare e controllare i punti di accesso a una rete). Le infrastrutture di gestione della 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 di una rete. Poiché i dispositivi di rete sono distribuiti, questo richiederà come minimo che il responsabile della rete sia in grado di ottenere dati (per esempio, a scopo di monitoraggio) da un entità remota e di effettuare cambiamenti (per esempio, regolazione) su quella entità remota. L architettura di un sistema di gestione della rete è concettualmente identica alla semplice analogia di un organizzazione umana. Il settore della gestione della rete ha la sua terminologia specifica per i vari componenti dell architettura e qui la adotteremo. Come mostrato nella figura 1.02 ci sono tre componenti principali nell architettura di gestione della rete: un entità di gestione (il boss nella nostra analogia), i dispositivi da gestire (le filiali) e un protocollo di gestione della rete. Figura 1.02 Principali componenti dell architettura di gestione della rete. 6

7 L entità da 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 gestione della rete; essa controlla la raccolta, l elaborazione, l analisi e/o l esposizione delle informazioni di gestione. È da qui che partono le azioni per controllare il comportamento delle 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 sulla rete da gestire. Questa è la filiale nella nostra analogia umana. Un dispositivo da gestire può essere un host, un router, un bridge, un hub, un apparecchio di stampa o un modem. 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 scheda di interfaccia di rete) ed il set di parametri di configurazione per le parti hardware software (per esempio, un protocollo di instradamento). Questi oggetti da gestire hanno associato parti di informazioni che sono raccolti in una base di informazioni per la gestione (MIB, Management Information Base); vedremo che i valori di queste parti di informazione sono disponibili alle 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 tra l entità e la sede. Infine, residente 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 gestione, 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 nostra analogia umana. Il terzo pezzo in un architettura di gestione di una rete è il protocollo di gestione della rete. Il protocollo 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 di 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, guasto dei componenti o violazione della soglia di prestazione). È importante notare che il protocollo di gestione della rete non gestisce la rete di per sé; piuttosto esso fornisce un attrezzo con cui il responsabile può agire (monitorare, sondare, configurare, analizzare ) sulla rete. La presentazione precedente dell architettura della gestione della rete è stata generica e ampiamente applicabile a un grande numero di standard di gestione e agli sforzi proposti negli anni. Gli standard per la gestione della rete cominciarono a maturare nei tardi anni 80, con il CMISE/CMIP (elemento comunicante di servizio per la gestione/protocollo comune delle informazioni per la gestione, Common Management Service Element/ Common Management Information Protocol) dell OSI e il SNMP 7

8 (protocollo semplice per la gestione delle reti, Simple Network Management Protocol) che emergevano come i due standard più importanti. Entrambi erano progettati per essere indipendenti dalle specifiche dei produttori dei componenti della rete. Poiché l SNMP fu progettato velocemente e sviluppato in un tempo in cui le necessità di gestione della rete cominciavano ad essere penosamente chiare, esso incontrò un accoglienza e una diffusione molto ampia. Oggi, l SNMP è emerso come il modello per la gestione delle reti più usato e funzionante. La struttura di gestione della rete internet Contrariamente a ciò che il suo nome SNMP (protocollo semplice per la gestione delle reti) può suggerire, la gestione delle reti in Internet è molto più di un semplice protocollo per spostare i dati di gestione fra un entità di gestione e i suoi agenti, ed è arrivato ad essere molto più complesso di quanto la parola <<semplice>> potrebbe lasciar supporre. L attuale struttura standard di gestione di Internet (Internet standard management framework ) trae la sua origine dal protocollo semplice per il monitoraggio dei gateway (SGMP Simple Gateway Monitoring Protocol ) fu progettato da un gruppo di ricercatori universitari, utenti e manager, la cui esperienza con l SGMP permise loro di progettare, implementare e mettere in funzione l SNMP in pochi mesi, una bella differenza dagli attuali processi di standardizzazione piuttosto lunghi. Sin da allora, l SNMP si è evoluto dall SNMPv1 attraverso l SNMPv2 fino alla versione più recente l SNMPv3 dell aprile Nella descrizione di una qualsiasi struttura per la gestione delle rete, occorre inevitabilmente rispondere ad alcune domande: Che cosa, da un punto di vista semantico, deve essere monitorato? Qual è la forma specificata delle informazioni che devono essere comunicati e/o scambiate? Qual è il protocollo per lo scambio di informazioni? L Internet network management framework (INMF, struttura standard di gestione della rete in internet) risponde alle domande poste sopra. La struttura è composta da quattro parti. 1. Definizione degli oggetti da gestire della rete, conosciuti come oggetti MIB. Nella struttura di gestione della rete internet, le informazioni per la gestione sono rappresentate come una raccolta di oggetti da gestire, che insieme formano un deposito virtuale di informazioni conosciute come base di informazioni per la gestione. Un oggetto MIB può essere un contatore, come il numero di datagrammi IP scartati da un router a causa di un errore 8

9 nell intestazione del datagrammi IP. Gli oggetti MIB definiscono quindi le informazioni di gestione mantenute da un nodo gestito. Gli oggetti MIB affini sono raggruppati nei cosiddetti Moduli MIB. 2. La definizione di un linguaggio per i dati, conosciuto come SMI (Struttura delle informazione di gestione, Structure of Management Information), che definisce i tipi di dati, un oggetto modello e le regole per scrivere e aggiornare le informazioni di gestione. Gli oggetti MIB sono specificati in questo linguaggio per la definizione dei dati. 3. Un protocollo, SNMP per trasportare informazioni e comandi fra un entità di gestione e un agente che opera a nome di quella entità all interno di un dispositivo di rete da gestire. 4. Capacità di sicurezza e amministrazione. L aggiunta di queste funzionalità rappresenta il più consistente perfezionamento dell SNMPv3 rispetto all SNMPv2. La struttura per la gestione della rete in Internet è quindi modulare nel progetto, con una definizione del linguaggio dei dati e i MIB indipendenti dal protocollo. Nei paragrafi successivi vedremo in maggior dettaglio i componenti della struttura di gestione delle reti. Struttura delle informazioni di gestione SMI La Structure of Management Information (SMI) ha il compito di definire, in modo standard, come devono essere strutturati gli oggetti gestiti e la loro gerarchia per essere inseriti nel database MIB e quindi gestiti da una entità SNMP. La definizione degli oggetti gestiti può essere vista secondo tre aspetti fondamentali: Nome: Il nome, o object identifier (OID), definisce unicamente un oggetto gestito. I nomi vengono visualizzati comunemente in due forme: numerica e letterale. Tipo e sintassi: Il tipo di dato associato ad un oggetto gestito viene definito usando l Abstract Syntax Notation One (ASN. 1). Tale sintassi risulta indipendente dal tipo di macchina utilizzata e ciò rende tale notazione molto conveniente e altamente portabile. Encoding: Il meccanismo di codifica e decodifica del codice usato segue le regole del Basic Encoding Rules (BER). 9

10 Un agent possiede una lista contenente tutti gli oggetti che dovrà gestire e che potranno via via essere chiesti dalla stazione di gestione. Ad esempio, un oggetto può rappresentare lo stato di funzionamento di una interfaccia (up, down o testing). La Management Information Base (MIB) può essere pensata come un database di oggetti gestiti. Ogni tipo di informazione alla quale può accedere un sistema di gestione è definita in una MIB. In pratica come un dizionario raccoglie in se tutte le parole con i relativi significati, così una MIB definisce un nome per un oggetto e spiega il suo significato usando la sintassi SMI. Un esempio di oggetto gestito è il seguente: sysuptime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } Il costrutto OBJECT-TYPE è usato per specificare il tipo di dato, lo stato e la semantica di un oggetto da gestire. Il costrutto OBJECT-TYPE ha quattro frasi. La frase SYNTAX della definizione specifica il tipo di dati base associati all oggetto. La frase Access specifica se l oggetto può essere letto e/o scritto. La frase STATUS indica se la definizione dell oggetto è attuale e valida e/o obsoleta. La frase DESCRIPTION contiene una definizione testuale dell oggetto leggibile dall uomo. L'esempio riportato riguarda l'oggetto sysuptime, ovvero il tempo trascorso da quando il sistema che lo gestisce è stato riavviato. Gli oggetti gestiti sono organizzati secondo una gerarchia ad albero, come si può vedere in figura

11 Figura 1.03 Struttura ad albero della MIB Il nodo da cui parte tutta la struttura dell'albero viene denominato radice, root, mentre qualsiasi altro nodo all'interno dell'albero che non ha altri nodi sotto di sé viene detto nodo foglia o leaf node. Un OID è costituito da una serie di numeri interi identificanti i nodi dell'albero, separati da punti. Nella forma letterale di un OID al posto dei numeri interi troviamo delle parole, per cui la leggibilità può risultare migliore. Si possono usare, indifferentemente, sequenze di numeri o di parole. Come si vede in figura 1.03 ogni nodo ha un riferimento sia numerico che letterale, per cui, volendo fare un esempio, l'oid iso.org.dod.internet.mgmt è equivalente a Partendo dalla radice, possiamo individuare tre nodi : 1. L International Organization for Standardization (ISO), a cui è associato il numero(1). 2. Il Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T), numero (0). 3. Il Joint ISO / ITU- T (2), che mette a comune i due organismi citati. 11

12 Sotto uno dei rami dell ISO, in particolare quello relativo all ISO identified organization(3), si possono trovare le entries per gli standards pubblicati dalle organizzazioni dei vari paesi membri dell ISO. Uno di questi è rappresentato dal dod (6) (US DEPARTEMENT OF DEFENSE), dal quale deriva il nodo internet (object identifier = ). Al di sotto del nodo internet troviamo sette nodi tra cui i più importanti per l analisi di rete sono: 1. management: questo sottoalbero contiene le definizioni delle MIBs approvate dall IAB (Internal Activities Board). Osserviamo che attualmente esistono due versioni: la MIB-I definita nella RFC 1156; e la MIB-II definita nella RFC Entrambe sono identificate dallo stesso object identifier = experimental: utilizzato per identificare oggetti che non sono ancora standard. 3. private: utilizzato per identificare gli oggetti creati dai (Juniper, Cisco, IBM etc ) per gestire specifiche variabili presenti in un loro prodotto. Esiste una organizzazione, la Internet Assigned Numbers Authority (IANA), che gestisce e regolamenta le concessioni di spazi all'interno dell'albero, sotto il nodo private, per privati, istituzioni, organizzazioni e compagnie. Ad esempio Cisco ha uno spazio privato dove poter sperimentare e sviluppare le proprie soluzioni per la gestione SNMP sotto il ramo iso.org.dod. internet.private.enterprises.cisco o Uno sguardo al MIB-II MIB-II è un gruppo molto importante all'interno dell'albero, in quanto ogni Workstation che supporta SNMP deve anche supportare MIB-II. Essa rappresenta la seconda versione della base di informazioni di gestione e il suo sottoramo è suddiviso in più gruppi, ognuno dei quali presenta diverse informazioni per la gestione e l analisi della rete. La sua definizione può essere consultata all'interno della RFC La struttura ad albero contenente la MIB-II è riportata in figura 1.04, mentre la tabella 1.05 descrive cosa rappresentano i nodi che la compongono. 12

13 Figura 1.04 Struttura del MIB-II 13

14 Nomi dei MIB Groups OID Descrizione SYSTEM Definisce una lista di oggetti riguardati il sistema operativo INTERFACES Riporta lo stato di ogni interfaccia di una periferica gestita, raccogliendo informazioni sul traffico inviato e ricevuto, sugli eventuali errori verificatisi, etc. AT Rappresenta un gruppo non più utilizzato. IP Riguarda tutti gli aspetti relativi ad IP, incluso il Routine ICMP Raccoglie statistiche relative a ICMP TCP E' relativo al protocollo TCP, e tra le altre cose fornisce lo stato della connessione TCP ( closed, listen, etc.) UDP Raccoglie statistiche relative al protocollo UDP EGP Riguarda il protocollo EGP TRANSMISSION Non ci sono oggetti gestiti un questo gruppo SNMP Misura le performances e le statistiche riguardanti l'utilizzo delle risorse di rete necessarie al funzionamento del protocollo SNMP sulla periferica gestita. Figura 1.05 Nodi del MIB-II Funzionamento del protocollo SNMP 14

15 Per poter sfogliare la MIB e i relativi oggetti gestiti, disponibili su un determinato nodo della rete, e quindi far comunicare tra loro manager e agent, è necessario, come detto, utilizzare il protocollo SNMP. Con l'aumentare della complessità della rete, il numero di managers e agents può crescere sensibilmente e con esso anche la complessità delle relazioni tra le varie entità. Per tale motivo ogni agent deve proteggere e regolare l'accesso alle proprie MIB. Vi sono, quindi, due aspetti che caratterizzano questo tipo di controllo: L'authentication service: ogni stazione da gestire limita l'accesso alle proprie MIB solo ad alcuni managers autorizzati. L'access policy: ogni agent fornisce ai vari managers differenti privilegi di accesso alle informazioni di gestione. La prima versione di SNMP [RFC 1157] introduce una prima protezione nella comunicazione, introducendo il concetto di community. Una SNMP community definisce sia il metodo di autenticazione sia la politica di controllo degli accessi. Ad ogni community viene assegnato un nominativo unico (community name) che sarà noto a tutte le stazioni (manager e agent) coinvolte in quella particolare relazione. Per cui il community name svolge il ruolo di parola chiave nella comunicazione tra le varie Workstation, garantendo una limitata autenticazione nella richiesta di informazioni. Il community name è presente in ogni messaggio SNMP inviato e viene considerato valido nel momento in cui siano compatibili il nominativo di comunità della stazione trasmittente ed il nominativo di comunità della stazione ricevente. Ogni agent può, inoltre, definire più comunità associate ad un particolare sottoinsieme di MIB (SNMP MIB view) caratterizzate da una particolare modalità di accesso: o di sola lettura, o di lettura e scrittura. Formato del messaggio SNMP 15

16 Il Protocol Data Unit (PDU) rappresenta il messaggio che manager e agent utilizzano per scambiarsi informazioni. Esiste un formato PDU standard per ognuna delle seguenti operazioni SNMP: GetRequest GetNextRequest SetRequest GetResponse Trap In particolare il messaggio SNMP, come si vede in figura 1.06, è costituito dai seguenti campi: Version: specifica la versione del formato SNMP. Community Name: contiene il nominativo della comunità. Request Id: fornisce ad ogni particolare richiesta un unico identificativo. Error Status: è utilizzato per indicare che si è verificato un errore mentre veniva inviata o ricevuta una richiesta SNMP. I valori assumibili sono cinque: noerror(0), toobig(1), nosuchname(2), badvalue(3), readonly (4), generr(5). Error Index: identifica quale variabile nel campo Variable Bindings è errata quando il valore ricevuto nell'error status è diverso da zero. Variable Bindings: è una lista di vari nomi di oggetti con i rispettivi valori. Enterprise: identifica il sottosistema che ha generato un messaggio di tipo trap. Agent Addr: contiene l'indirizzo IP dell'agent che ha mandato un messaggio di tipo trap. Generic Trap: specifica il tipo di messaggio trap generato. Specific Trap: racchiude informazioni più specifiche sulla natura del messaggio di trap. Time-Stamp: è il tempo trascorso tra l'ultima reinizializzazione dell'entità che ha generato il messaggio di trap ed il messaggio stesso. 16

17 Figura 1.06 Struttura del pacchetto SNMP Un' entità SNMP per poter trasmettere uno dei cinque possibili tipi di PDU deve compiere delle operazioni secondo una determinata cronologia. In primo luogo è importante definire la notazione con cui la PDU viene costruita, e questa è definita da ASN. 1 e può essere osservata nella RFC Tramite questa notazione è possibile, dunque, descrivere e visualizzare varie tipologie di informazioni che un manager può richiedere. Dopo aver costruito la PDU, essa è passata, insieme agli indirizzi di sorgente, di destinazione ed un community name, ad un servizio di autenticazione. Quest'ultimo compie determinate operazioni (ad esempio l'inserimento di un codice di autenticazione) e fornisce il risultato ottenuto, che verrà inserito nel messaggio SNMP che conterrà inoltre sia la versione che il nominativo della comunità. Infine il messaggio verrà codificato usando le regole base di cifratura e passato ad un servizio di trasporto, come illustrato in figura Per quanto riguarda la ricezione di un messaggio SNMP, verrà inizialmente effettuato un controllo della sintassi e della versione del messaggio ricevuto, che può essere scartato qualora siano riscontrati errori, e in seguito sarà passata ad un servizio di autenticazione sia la porzione relativa al PDU che quella relativa agli indirizzi di sorgente e di destinazione. 17

18 Figura 1.07 Funzionamento del Protocollo SNMP GetRequestPDU Tale tipo di PDU viene inoltrato da una stazione di controllo ad un agent per ottenere il valore di una o più variabili. I nomi delle variabili richieste sono contenute nel campo variablebindings. La stazione ricevente risponde inviando un messaggio di risposta chiamato GetResponsePDU, contenente sia lo stesso campo request-id presente nella GetRequestPDU inoltrata che il campo variablebindings, all'interno del quale sono inseriti i valori delle variabili richieste, come illustrato in figura Quando una di queste variabili non può essere fornita al manager, nessun valore delle variabili richieste viene restituito; per questo motivo l'operazione GetRequestPDU viene detta atomica. 18

19 Figura 1.08 Messaggio GetRequestPDU I possibili errori che possono verificarsi sono i seguenti: Il nome di un oggetto incluso nel campo variablebindings non corrisponde ad alcun object identifier all'interno delle MIB gestite dall'agent. In questo caso, la PDU di risposta ha un error-status contenente il valore nosuchname, ed un valore all'interno del campo errorindex indicherà quale variabile ha generato tale situazione di errore. La dimensione della PDU di risposta risulta essere maggiore di una limitazione locale, in tal caso il campo error-status è impostato al valore toobig. La stazione ricevente non è capace di soddisfare tutte le richieste del manager per un motivo ignoto, in questo caso l'error-status contiene il valore generr. GetNextRequestPDU Questo tipo di PDU ha lo stesso formato della GetRequestPDU e si differenzia da quest'ultima solo per il fatto che, per ogni variabile presente nella lista presente nel campo variablebindings viene restituito il valore dell'elemento successivo nella MIB considerata. 19

20 Attraverso l'utilizzo di questa PDU, il manager può scoprire qual è la struttura di una MIB senza doverla conoscere a priori, ed inoltre può ottenere tutti i valori all'interno di una tabella, nonostante non conosca nulla riguardo ad essa, incluso il numero di righe e di colonne che la compongono. Il manager, infatti, si accorge della fine di una tabella nel momento in cui i nomi degli oggetti inclusi nella lista della PDU di risposta risultano essere differenti da quelli richiesti. Anche l'operazione di GetNextRequest, così come quella di GetRequest, viene detta atomica, ovvero vengono restituiti tutti i valori contenuti nel campo variablebindings, oppure, qualora si sia verificata una condizione di errore, nessuno di essi. SetRequestPDU Questa PDU, viene utilizzata dalla stazione di controllo, per assegnare un valore ad un elemento della MIB di un agent. Per svolgere questa operazione, il campo variablebindings contiene i nomi ed i relativi valori delle variabili che il manager vuole impostare. In figura 1.09 è riportata la struttura del messaggio SetRequestPDU. La stazione ricevente risponde con una GetResponsePDU contenente anche in questo caso, lo stesso request-id della PDU di richiesta. Nel caso in cui tutte le variabili vengano impostate correttamente ai valori voluti dal manager, il campo variablebindings conterrà i nomi delle variabili ed il rispettivo valore modificato, altrimenti, se uno dei valori non può essere variato, allora nessuno di essi può essere aggiornato, ed il campo variablebindings non conterrà alcun valore. Figura 1.09 Messaggio SetRequestPDU 20

21 Le possibili condizioni di errore sono le stesse delle altre PDU già descritte, con l'aggiunta del valore bad value, a cui viene impostato il campo error-status della PDU di risposta nel caso in cui venga riscontrata un inconsistenza tra il nome della variabile ed il relativo valore. TrapUDP Un messaggio di tipo Trap, rappresentato graficamente in figura 1.10, viene inviato dall'agent per avvisare il manager del verificarsi di una condizione anomala. Questo tipo di notifica è definita asincrona proprio per sottolineare la non periodicità di tali messaggi. Figura 1.10 Messaggio TrapUDP Come già accennato, il servizio di trasporto dei messaggi SNMP è basato su un protocollo non orientato alla connessione (UDP), è quindi possibile che un messaggio venga perso; ciò risulta disastroso per la notifica di errori o guasti. Per questo motivo ad una tecnica di tipo event reporting (come è appunto l'invio di messaggi Trap), viene affiancata una procedura periodica di polling, che risulta ovviamente più affidabile. 21

22 Il campo generic-trap può assumere uno dei seguenti valori: coldstart(0): l'agent si sta inizializzando; warmstart(1): l'agent si sta reinizializzando; linkdown(2): un'interfaccia, di cui segue l'identificativo, è stata disattivata; linkup(3): un'interfaccia è stata attivata; authenticationfailure(4): il messaggio ricevuto è stato inviato da un manager con il campo community non valido; egpneighborloss(5): un host EGP, di cui segue l'indirizzo IP, è stato disattivato; enterprisespecific(6): si è verificato un evento particolare, specificato nel campo specifictrap. SNMPv3 A partire dalla seconda metà del 1999 è disponibile una ulteriore versione del protocollo SNMP. Poiché le differenze con le precedenti sono notevoli, verranno analizzate le caratteristiche maggiormente innovative. Tale versione nasce, come detto, per sopperire alle mancanze dei suoi predecessori nell'ambito della sicurezza delle trasmissioni. Questo protocollo è stato pensato, inoltre, per essere scalabile, duraturo, per quanto riguarda la sua architettura, portabile e compatibile con le precedenti versioni utilizzando le stesse MIB. Nonostante ciò, la versione 3 non ha, almeno per ora, trovato grosso spazio sul mercato, dove continua ad essere adottata la prima versione perchè la maggiorazione delle funzionalità è andata a scapito della semplicità del protocollo. La classica architettura di tipo Manager/Agent è stata sostituita, in SNMPv3, da una più complessa, composta da SNMP Engine e SNMP Applications come riportato in figura

23 Figura 1.11 Il formato dei messaggi è sostanzialmente diverso da quello visto in precedenza e riguardante le prime due versioni del protocollo, infatti include anche alcuni parametri di sicurezza ed il controllo dell'accesso. A tal fine SNMPv3 consente di accettare messaggi solo nel caso in cui alcune interrogazioni ricevano una risposta affermativa o comunque valida. Tali politiche di sicurezza sono implementate tramite crittografia, funzioni di hash e alti strumenti che consentono l'autenticazione dei pacchetti, delle password e delle PDUs. Tramite diversi livelli di sicurezza si può stabilire se consentire un accesso senza autenticazione, con semplice autenticazione o con autenticazione e codifica dei dati. Link interessanti Adrem SNMP Manager è una console di gestione che permette di accedere in remoto e visualizzare tutti i dispositivi presenti in una rete (firewalls, routers, switches, stampanti, etc.). Supporta tutte e tre le versioni del protocollo SNMP v1,v2, v3 ; include la rivelazione dei nodi, ricezione/inoltro delle traps, visualizzatore MIB, compilazione, lettura, scrittura e walking. Il programma consente un facile accesso alle informazione del MIB con la possibilita di crearne e visualizzarne una istantanea dei valori correnti. 23