Capitolo 2
Il protocollo SNMP
2.1 Introduzione al protocollo SNMP
SNMP (Simple Network Management Protocol) è un protocollo a livello di applicazione definito per introdurre una semplice architettura per la gestione di reti basate sulla suite di protocolli UDP/IP [9], come si può osservare in figura 2.1. Tale protocollo definisce le modalità di scambio di informazioni tra apparecchiature di rete, consentendo agli amministratori di tenere sotto controllo le performances della rete e di accorgersi in tempo reale del manifestarsi di malfunzionamenti. Attualmente il protocollo presenta tre definizioni successive: SNMPv1, SNMPv2, SNMPv3.
La versione più recente introduce nel protocollo alcune nuove funzionalità e correzioni, soprattutto nel campo della sicurezza.
Il protocollo SNMP è attualmente quello più diffuso per la gestione delle reti di calcolatori ed è supportato praticamente da tutti i produttori di hardware ed apparecchiature di rete.
L'architettura di cui il protocollo SNMP fa parte, è detta Internet Network
Fig. 2.1: SNMP nella pila ISO-OSI
Tale architettura consente di gestire degli elementi di rete (che sono apparecchiature come router, switch, hub, pc, etc.) usando degli agents, cioè moduli software che risiedono sulle apparecchiature da gestire, come riportato in figura 2.2.
Tali agents comunicano con una stazione di gestione centralizzata (Network
Management Station) che, interagendo con i primi, può leggere o scrivere
informazioni e raccogliere eventuali segnalazioni di errore.
Le informazioni o caratteristiche che è possibile gestire per una particolare apparecchiatura, mediante il protocollo SNMP, verranno indicati come oggetti gestiti. L'insieme di questi oggetti costituisce un'astrazione di database detta
Fig. 2.2: Schema logico di un sistema di Network Management
2.2 La struttura delle informazioni di gestione
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 il 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).
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 sè 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, tratto da RFC 1213: 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 }
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 2.3.
Fig. 2.3: Struttura ad albero delle MIBs
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 2.3 ogni nodo ha un riferimento sia numerico che letterale, per cui, volendo fare un esempio, l'OID iso.org.dod.internet.mgmt è equivalente a 1.3.6.1.2.
Partendo dalla radice, possiamo individuare tre nodi :
– L’International Organization for Standardization (ISO), a cui è
associato il numero(1).
– Il Telecommunication Standardization Sector of the International
Telecommunication Union (ITU-T), numero (0).
– Il Joint ISO / ITU- T (2), che mette a comune i due organismi
citati.
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 = 1.3.6.1).
Al di sotto del nodo internet troviamo sette nodi tra cui i più importanti per l’analisi di rete sono:
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 1213. Entrambe sono identificate dallo stesso object identifier = 1.3.6.1.2.1.
- experimental: utilizzato per identificare oggetti che non sono ancora standard.
- private: utilizzato per identificare gli oggetti creati dai vendors (quali 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 1.3.6.1.4.1.9. Maggiori informazioni possono trovarsi su [7].
2.3 Uno sguardo alla 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 1213. La struttura ad albero contenente la MIB-II è riportata in figura 2.4, mentre la tabella 2.1 descrive cosa rappresentano i nodi che la compongono.
Nomi dei MIB-II
Groups
OID
Descrizione
system
1.3.6.1.2.1.1
Definisce una lista di oggetti
riguardanti il sistema operativo.
interfaces
1.3.6.1.2.1.2
Riporta lo stato di ogni interfaccia
di una periferica gestita,
raccogliendo informazioni sul
traffico inviato e ricevuto, sugli
eventuali errori verificatisi, etc.
at
1.3.6.1.2.1.3
Rappresenta un gruppo non più
utilizzato.
ip
1.3.6.1.2.1.4
Riguarda tutti gli aspetti relativi ad
IP, incluso il routing.
icmp
1.3.6.1.2.1.5
Raccoglie statistiche relative a
ICMP.
tcp
1.3.6.1.2.1.6
E' relativo al protocollo TCP, e tra
le altre cose fornisce lo stato della
connessione TCP ( closed, listen,
etc.)
udp
1.3.6.1.2.1.7
Raccoglie statistiche relative al
protocollo UDP.
egp
1.3.6.1.2.1.8
Riguarda il protocollo EGP
.transmission
1.3.6.1.2.1.10
Non ci sono oggetti gestiti in questo
gruppo.
snmp
1.3.6.1.2.1.11
Misura le performances e le
statistiche riguardanti l'utilizzo delle
risorse di rete necessarie al
funzionamento del protocollo
SNMP sulla periferica gestita.
2.4 Funzionamento del protocollo SNMP
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 MIBs.
Vi sono, quindi, due aspetti che caratterizzano questo tipo di controllo:
• L'authentication service: ogni stazione da gestire limita l'accesso alle
proprie MIBs 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 workstations, 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 MIBs (SNMP MIB view) caratterizzate da una particolare modalità di accesso: o di sola lettura, o di lettura e scrittura.
2.5 Formato di un messaggio SNMP
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 2.5, è 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
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.
Figura 2.5: 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 1157. Tramite questa notazione è
possibile, dunque, descrivere e visualizzare vari 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 2.6.
Fig. 2.6: Funzionamento del protocollo SNMP
Per quanto riguarda la ricezione di un messaggio SNMP, verrà inizialmente effettuato un controllo della sintassi e della versione del messaggio ricevuto, che
servizio di autenticazione sia la porzione relativa al PDU che quella relativa agli indirizzi di sorgente e di destinazione.
2.5.1 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 2.7.
Fig. 2.7: Messaggio GetRequestPDU
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.
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 error-index 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.
2.5.2 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.
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 a riguardo di 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.
2.5.3 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 2.8 è 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.
Le possibili condizioni di errore sono le stesse delle altre PDU già descritte, con l'aggiunta del valore badvalue, a cui viene impostato il campo error-status della PDU di risposta nel caso in cui venga riscontrata un'incosistenza tra il nome della variabile ed il relativo valore.
2.5.4 TrapPDU
Un messaggio di tipo Trap, rappresentato graficamente in figura 2.9, 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 2.9: Messaggio TrapPDU
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
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 specific-trap.
2.6 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 MIBs.
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 2.10.
Fig. 2.10: SNMPv3 entity
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.
