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

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

INDICE
Considerazioni finali 72

Bibliografia 73

Elenco delle figure 74

4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

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

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

• 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

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

• 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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Network monitoring tramite snmp

Network monitoring tramite snmp

Recomendados

Recomendados

Más contenido relacionado

Similar a Network monitoring tramite snmp

Similar a Network monitoring tramite snmp (20)

Más de Ce.Se.N.A. Security

Más de Ce.Se.N.A. Security (20)

Network monitoring tramite snmp