Capitolo 3 OpenNMS

(1)

Capitolo 3

OpenNMS

3.1 OpenNMS

Rilasciato sotto licenza GPL, OpenNMS rappresenta, come detto, la vera alternativa open source ai prodotti di Network Management proprietari ponendosi come obiettivo la scalabilità e la portabilità. Esso consente a uno o più utenti di accedere 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 potenzialità offerte dal protocollo SNMP dialogando con gli agents presenti, ognuno, sui vari nodi della rete secondo le modalità descritte nei capitoli precedenti.

(2)

riguardano il database (Postgresql) e i grafici (RRDtool), e ciò rende il prodotto eseguibile su qualsiasi piattaforma. I files di configurazione sono scritti in eXtensible Markup Language (XML) e i dettagli per l'installazione sono riportati in Appendice A.

Si accede al sistema mediante un browser web al seguente indirizzo http://127.0.0.1:8180/opennms,e dopo aver effettuato il login (admin/admin) viene visualizzata la home page (figura 3.1).

(3)

All'interno della home page è riportata, oltre ad un elenco dei nodi non funzionanti, 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 nodo e per ogni interfaccia riconosciuta, figura 3.2.

(4)

In particolare viene dedicata una pagina all'interno della quale si trovano tutte le informazioni che interessano un particolare nodo. Oltre ad una dettagliata cronologia degli avvenimenti che hanno interessato il nodo in questione sino a quel particolare 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 riguardante 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 localizzando tempestivamente eventuali malfunzionamenti. Vengono riportati di seguito alcuni links che si trovano frequentemente in OpenNMS:

✔ Admin : rimanda ad una pagina, riportata in figura 3.3, dove è possibile

aggiungere o rimuovere i nodi e modificare le procedure di interrogazione e notifica. Viene, inoltre, fornita una breve descrizione per ogni operazione eseguibile come ulteriore ausilio all'utilizzo.

✔ View Events : fornisce una lista di tutti gli avvenimenti verificatisi su un

particolare 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'utilizzo della CPU.

(5)

Fig. 3.3: Sezione 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 specifiche esigenze per la gestione della rete.

3.2 OpenNMS Discovery

(6)

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 rete. Tale procedura di ricerca è regolamentata dal contenuto del file discovery-configuration.xml presente nella cartella /etc/opennms. Il suo contenuto è riportato di seguito:

<discovery-configuration threads="1" packets-per-second="1" initial-sleep-time="300000" restart-sleep-time="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</include-url> </discovery-configuration>

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

secondo.

• Initial-sleep-time: è il tempo, espresso in millisecondi, che deve

trascorrere dopo l'avvio di OpenNMS perchè il processo di discovery possa iniziare.

(7)

discovery 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'indirizzo 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à:

• <specific>ip-address</specific>: dove ip-address è

l'indirizzo specifico che si vuole interrogare.

• <include-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </include-range> • <exclude-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </exclude-range> • <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. Il processo di discovery 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.

(8)

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 comunque in grado di rilevare una nuova entità.

3.3 OpenNMS Capsd

Mentre il processo di discovery si occupa solo di scoprire un nuovo nodo presente sulla rete, chi raccoglie le informazioni generiche relative alla nuova macchina è il demone capsd, il cui funzionamento è regolamentato dal file di configurazione capsd-configuration.xml.

Tramite questo demone, OpenNMS verifica l'esistenza di un particolare servizio 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

(9)

• TCP

Le prime prime righe che si incontrano in capsd-configuration.xml descrivono il suo funzionamento: <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 è stabilita 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”>

(10)

Ogni volta che un nuovo nodo viene aggiunto il demone capsd inizia ad interrogare la relativa interfaccia alla scoperta di tutti i servizi presenti in modo da monitorarne lo stato di funzionamento.

Un servizio o un protocollo che non sia stato scoperto o contemplato dal demone 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.4 OpenNMS Polling

Il processo di polling, già descritto all'inizio di questo capitolo, è configurabile in OpenNMS modificando opportunamente il file di configurazione poller-configuration.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

(11)

interfaccia remota e quindi verificare periodicamente che un determinato servizio restituisca una risposta.

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 guasti 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 inattivo.

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'interfaccia viene considerata inattiva e viene generato un evento chiamato “InterfaceDown”. Analogamente se tutte le interfacce di un nodo vengono dichiarate inattive allora anche il nodo è considerato inattivo e l'evento corrispondente è detto “NodeDown”. Se viene generato un “NodeDown” e il campo node-outage status="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 critical 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 stabilire dei livelli di servizio differenziati. Si può definire un poller package assegnando 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.

(12)

prendendo ad esempio il caso riguardante il servizio DNS:

</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="false") ed il polling per questo servizio è attivo (status="on").

3.5 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 gestire 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:

(13)

2. datacollection-config.xml

3.5.1 Snmp-config.xml

Snmp-config.xml stabilisce quali siano i contenuti dei parametri usati per dialogare con i vari agents SNMP presenti sulla rete:

<snmp-config retry="3" timeout="800"

read-community="public" write-community="private"> <definition version="v2c">

<definition read-community="pippo"

write-community="paperino">

</snmp-config>

I vari campi hanno i seguenti significati:

(14)

SNMP.

• Timeout: il tempo, espresso in ms, 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 scambio di informazioni. Tali soluzioni anche se non risolvono pienamente il problema sicurezza, sicuramente scoraggiano eventuali attacchi e quindi possono essere considerati dei buoni deterrenti.

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 specifica 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

(15)

numero che OpenNMS assegna a ciascun nodo monitorato, all'interno della quale sono contenuti 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 contenute 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 snmpStorageFlag può assumere due valori “all” o “primary” a seconda che si vogliano interrogare 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"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.13"

instance="ifIndex" alias="ifInDiscards" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.14"

instance="ifIndex" alias="ifInErrors" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.16"

instance="ifIndex" alias="ifOutOctets" type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.19"

instance="ifIndex" alias="ifOutDiscards type="counter"/> <mibObj oid=".1.3.6.1.2.1.2.2.1.20"

(16)

</group>

Ad ogni gruppo viene associato un nome e il tipo di interfaccia, stabilito nel campo ifType, che si intende interrogare per ottenere le informazioni relative agli OIDs riportati. I valori che può assumere ifType possono essere i seguenti:

• all: vengono interrogate tutte le interfacce.

• ignore: si usa quando l'informazione che si vuole ottenere riguarda una

caratteristica generale del nodo ed è quindi indipendente dall'interfaccia. I “systems” invece riguardano gli agent SNMP che si trovano sui nodi da monitorare, ad esempio riferendosi all'agent Net-SNMP, che verrà illustrato in maniera più approfondita nel seguito di questa tesi, si trova la seguente definizione:

<sysoidMask>.1.3.6.1.4.1.2021.250.</sysoidMask> <collect> <includeGroup>mib2-interfaces-net-snmp </includeGroup> <includeGroup>mib2-host-resources-storage </includeGroup> <includeGroup>mib2-host-resources-system </includeGroup> <includeGroup>mib2-host-resources-memory </includeGroup> <includeGroup>ucd-loadavg</includeGroup> </collect> </systemDef>

(17)

Il sysoidMask riguarda il system OID specifico per ogni agent. Come si nota vengono inclusi tutti i gruppi che interessano ai fini del monitoraggio. E' importante sottolineare la flessibilità che OpenNMS offre all'amministratore di rete in quanto si può usare, previa opportuna configurazione, qualsiasi tipo di agent SNMP personalizzando la raccolta delle statistiche secondo specifiche esigenze. In figura 3.4 sono riportati i grafici ottenibili con OpenNMS.

(18)

Fig. 3.4: Grafici delle statistiche raccolte tramite SNMP

Tali dati riguardano una macchina Linux equipaggiata con agent Net-SNMP e rappresentano una porzione delle informazioni che si possono raccogliere con OpenNMS tramite le operazioni definite dal protocollo SNMP, in particolare:

• Bits In/Out: le statistiche di traffico di ingresso e uscita espresse in

bit/sec.

• System Uptime: il periodo di tempo di accensione della macchina

espresso in numero di giorni e sue frazioni.

• Number of Processes: il numero di processi attivi.

(19)

su intervalli di 1, 5 e 15 minuti rispettivamente.

• CPU Use: l' utilizzo della CPU.

Nella figura 3.5 sono, invece, riportati i grafici, relativi allo stesso nodo, riguardanti però i tempi di risposta dei protocolli ICMP e SSH espressi rispettivamente in microsecondi ed in millisecondi.

Fig. 3.5: Grafici dei tempi di risposta di ICMP e SSH

3.6 Utilizzo delle risorse di rete

(20)

disponibile dovuto alla generazione di traffico all'interno della rete sia da parte della stazione di gestione che effettua le interrogazioni che da parte dei nodi amministrati che inviano le risposte. Utilizzando un software di “sniffing” quale Ethereal è stato valutato l'effettivo utilizzo delle risorse di rete, figura 3.6.

Fig. 3.6: Grafico del traffico SNMP e ICMP

La raccolta di informazioni e l'interrogazione dei servizi viene effettuata ogni 5 minuti, su un totale di 15 nodi equipaggiati con agent SNMP, producendo i picchi di maggiore entità. I picchi di minore entità sono, invece, dovuti all'aggiunta di nuovi nodi.

Il traffico medio registrato, su un intervallo di tempo di circa 30 minuti, è di circa 2Kb/s, figura 3.7. L'utilizzo del mezzo trasmissivo risulta, quindi, di modesta entità.

(21)

Si può infittire la raccolta delle informazioni diminuendo i timeouts contenuti nei files di configurazione visti in precedenza senza pregiudicare il corretto funzionamento dell'architettura e riducendo al tempo stesso i ritardi di visualizzazione e aggiornamento dei grafici.

(22)

Tali risultati dimostrano come OpenNMS può monitorare anche un numero elevato di nodi senza gravare troppo sulle risorse di rete.

3.7 Considerazioni

L'architettura di tutto il sistema, così come è concepito, può essere schematizzata come in figura 3.8:

(23)

OpenNMS è configurabile attraverso la sezione admin per l'invio di notifica tramite posta elettronica quando si verifica un malfunzionamento di grave entità. Integrando le e-mails, inviate da OpenNMS, con un servizio di SMS fornito da un operatore mobile o implementato con degli strumenti ad hoc sfruttando ad esempio un SMS Gateway, si ottiene uno strumento potente e vantaggioso che consente all'amministratore di rete di essere sicuro del funzionamento della stessa in qualsiasi momento, anche quando il sistema lavora autonomamente senza la presenza di un operatore umano.

Oltre alla notifica dei guasti, tramite posta elettronica, è possibile inviare dei rapporti periodici riguardanti il funzionamento generale dei servizi monitorati in formato pdf, come riportato in figura 3.9, con la possibilità di evidenziare i nodi e i servizi meno performanti.

(24)

OpenNMS consente all'amministratore di estendere l'accesso al sistema di gestione ad altri utenti ( gestione dell'accounting ), assegnando ad ognuno specifici privilegi. Considerato che il sistema di gestione lavora con le prime due versioni del protocollo SNMP c'è da tenere in conto il problema non banale riguardante la sicurezza. La trasmissione in chiaro del community name consente a qualsiasi utente non autorizzato di intrufolarsi nel sistema e avere accesso alle informazioni di gestione.

Un metodo per risolvere tale inconveniente può essere quello di integrare OpenNMS con un sistema di anti-intrusione come può essere il pacchetto Snort che ad esempio generi, in caso di allarme, un messaggio di trap ad-hoc destinato alla stazione di gestione.