[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
Il protocollo SNMP (Simple network management protocol) ha lo scopo di consentire il controllo di apparecchiature raggiungibili attraverso la rete, fornendo un modo per pubblicare delle informazioni, che in parte possono anche essere rese modificabili.
Questo capitolo introduce all'uso del protocollo SNMP, allo scopo di interrogare genericamente il servizio e di attivare un servente SNMP, utilizzando NET SNMP(1) in un sistema GNU/Linux. Viene invece omessa la spiegazione di come attivare delle «trappole».
Le informazioni a cui è possibile accedere attraverso il protocollo SNMP sono strutturate ad albero, in modo tale da potervi fare riferimento attraverso l'indicazione di un percorso, secondo la forma ....a.b.c...., dove al posto delle lettere (a, b, c, ecc.), possono apparire dei nomi (stringhe alfanumeriche per le quali non conta la distinzione tra maiuscole e minuscole) o dei valori numerici interi. Naturalmente, l'associazione tra nomi e numeri, viene definita dagli standard che riguardano il protocollo SNMP.
Il percorso in questione si legge da sinistra verso destra, descrivendo con dettaglio sempre maggiore la variabile a cui si vuole fare riferimento. Un percorso «completo», inizia con un punto, a indicare la radice dell'albero che rappresenta la struttura complessiva delle variabili; un percorso che inizia senza punto, implica l'omissione di una porzione iniziale consueta del percorso stesso: .iso.org.dod.internet.mgmt.mib-2.
, ovvero .1.3.6.1.2.1.
.
I percorsi di esempio seguenti, sono da ritenere tutti uguali:
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0
.1.3.6.1.2.1.1.sysdescr.0
.1.3.6.1.2.1.1.1.0
system.sysDescr.0
1.sysdescr.0
1.1.0
Nella terminologia usata per il protocollo SNMP, si fa spesso riferimento alla sigla OID (Object identifier). Un OID è un percorso qualunque di quelli che riguardano le variabili gestite dal protocollo, che non arriva necessariamente al dettaglio di una sola variabile. Per esempio, è un OID il percorso .iso.org.dod.internet.mgmt.mib-2.system
, che rappresenta tutto ciò che appartiene a quella gerarchia, ma è un OID anche un percorso che arriva fino in fondo, a specificare una sola variabile.
Gli «oggetti» (nel senso di OID) gestibili attraverso il protocollo SNMP, sono raggruppati a insiemi denominati MIB (Management information base).
Il protocollo SNMP consente sostanzialmente di: richiedere a un servente la lettura di una certa variabile o di un gruppo di queste; modificare il contenuto delle variabili che il servente consente di alterare; di attivare delle «trappole» (trap) che scattino al verificarsi di certe condizioni, con le quali si vuole che alcune variabili (riferite al proprio nodo) siano inviate a un certo cliente SNMP.
Per queste funzioni, SNMP si avvale generalmente del protocollo UDP. Precisamente, per le operazioni di lettura e scrittura normali, ci si aspetta di trovare il servente in ascolto della porta 161 (161/UDP); invece, per l'invio di valori senza una richiesta preventiva (quando scattano delle trappole), ci si aspetta di trovare, presso la destinazione, un programma in ascolto della porta 162 (162/UDP).
Di norma, il servente SNMP viene chiamato «agente» (agent).
Il servente SNMP (ovvero l'agente) che riceve la richiesta di fornire delle informazioni, prima di rispondere, cerca di verificare che questa provenga da chi ha il diritto di ottenerle. Il servente può attuare una propria politica, basata sull'indirizzo di origine della richiesta (nel senso che si risponde solo a chi appartiene a un certo gruppo di indirizzi), ma nel protocollo stesso è prevista una qualche forma di riconoscimento.
Nelle versioni 1 e 2 del protocollo SNMP, il cliente si presenta al servente specificando il nome della «comunità» (community). In pratica, il servente risponde solo se il nome della comunità corrisponde a quello previsto (si distingue normalmente tra il nome da usare per la lettura delle variabili e quello da usare per la loro modifica). Tuttavia, occorre considerare che nella versione 1 del protocollo, il nome della comunità viene trasmesso in chiaro attraverso la rete, pertanto potrebbe essere individuato facilmente.
Nella versione 3 del protocollo SNMP, l'autenticazione può avvenire attraverso utenze e parole d'ordine individuali, ma questo meccanismo non viene descritto qui.
Notoriamente, la comunità predefinita, usata per la lettura delle variabili è public, mentre quella per la scrittura è private. Naturalmente, è molto importante modificare questi nomi quando si attiva un servizio SNMP; inoltre, è altrettanto importante verificare se le apparecchiature connesse in rete offrono anche un servizio SNMP, provvedendo eventualmente a cambiare i nomi delle comunità anche se non si intende usufruirne. |
|
Il pacchetto NET SNMP(2) contiene diversi programmi per l'interrogazione di un servizio SNMP, le cui opzioni principali sono condivise. Per verificare che un servizio SNMP sia attivo, si usa normalmente snmpwalk o snmpbulkwalk:
snmpwalk [opzioni] agente [percorso] |
snmpbulkwalk [opzioni] agente [percorso] |
Si osservi che nei modelli sintattici standard, al posto di percorso si indica la sigla OID. In pratica, il percorso non raggiunge necessariamente il dettaglio di una variabile singola.
La differenza tra i due programmi, sta nel fatto che il secondo (snmpbulkwalk si avvale specificatamente di funzionalità che sono disponibili a partire dalla versione 2 del protocollo SNMP, anche se il risultato apparente è lo stesso. Segue la descrizione di alcuni esempi.
$
snmpwalk -v 1 -c public localhost
[Invio]
Interroga il servizio SNMP presso l'elaboratore locale, utilizzando la versione 1 del protocollo e facendo riferimento alla comunità public, che di solito è quella predefinita per la lettura delle variabili. Se il servizio risponde, si ottiene l'elenco di tutte le variabili disponibili:
SNMPv2-MIB::sysDescr.0 = STRING: Linux nanohost 2.6.17.1 \ |
Come si può osservare, in questo caso i percorsi delle variabili sono abbreviati attraverso l'indicazione del MIB di riferimento.
$
snmpwalk -O f -v 2c -c public localhost
[Invio]
Rispetto all'esempio precedente, si richiede di visualizzare i percorsi secondo lo standard, usando i nomi rispettivi; inoltre si usa la versione 2 del protocollo.
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: Linux \ |
$
snmpbulkwalk -O f -v 2c -c public localhost
[Invio]
Si ottiene lo stesso risultato dell'esempio precedente.
$
snmpwalk -O n -v 2c -c public localhost
[Invio]
Si ottengono i percorsi in forma numerica.
.1.3.6.1.2.1.1.1.0 = STRING: Linux nanohost 2.6.17.1 #1 PREEMPT \ |
$
snmpwalk -O n -v 2c -c public localhost .1.3.6.1.2.1.1.9.1
[Invio]
Si ottengono le variabili, limitatamente a un certo OID.
.1.3.6.1.2.1.1.9.1.2.1 = OID: .1.3.6.1.2.1.31 .1.3.6.1.2.1.1.9.1.2.2 = OID: .1.3.6.1.6.3.1 .1.3.6.1.2.1.1.9.1.2.3 = OID: .1.3.6.1.2.1.49 ... .1.3.6.1.2.1.1.9.1.4.7 = Timeticks: (10) 0:00:00.10 .1.3.6.1.2.1.1.9.1.4.8 = Timeticks: (10) 0:00:00.10 .1.3.6.1.2.1.1.9.1.4.9 = Timeticks: (10) 0:00:00.10 |
Per leggere in modo particolare una sola variabile, si usa normalmente snmpget o snmpgetnext:
snmpget [opzioni] nodo variabile |
snmpgetnext [opzioni] nodo variabile |
Il risultato ottenuto dai due programmi è diverso, in quanto il primo mostra il contenuto della variabile indicata, mentre il secondo mostra quella successiva a quella indicata. Segue la descrizione di alcuni esempi, omettendo di precisare dettagli già descritti a proposito di quelli su snmpwalk e snmpbulkwalk, in quanto le opzioni usate sono equivalenti.
$
snmpget -O n -v 2c -c public localhost .1.3.6.1.2.1.1.1.0
[Invio]
Interroga la variabile .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0.
.1.3.6.1.2.1.1.1.0 = STRING: Linux nanohost 2.6.17.1 #1 \ |
$
snmpgetnext -O n -v 2c -c public localhost
\
\ .1.3.6.1.2.1.1.9.1.3.9
[Invio]
Interroga la variabile successiva a .iso.org.dod.internet.mgmt.mib-2.system.sysORTable.sysOREntry.sysORDescr.9
, che in questo caso corrisponde a .iso.org.dod.internet.mgmt.mib-2.system.sysORTable.sysOREntry.sysORUpTime.1
.
.1.3.6.1.2.1.1.9.1.4.1 = Timeticks: (10) 0:00:00.10 |
|
Il pacchetto NET SNMP(3) include anche qualche programma per l'interrogazione di un servizio SNMP, in riferimento a problemi specifici, mostrando il risultato in un modo conforme al problema stesso. Naturalmente, perché questi programmi possano mostrare le informazioni richieste, occorre che il servizio SNMP pubblichi le variabili necessarie.
snmpdf [opzioni] nodo |
Il programma snmpdf consente di ottenere informazioni sullo spazio utilizzato e disponibile nei dischi. In pratica, la sigla df fa volutamente riferimento al programma di un sistema Unix che di solito compie questa funzione. L'esempio seguente dovrebbe essere più che sufficiente per comprenderne il funzionamento:
$
snmpdf -v 2c -c public localhost
[Invio]
Description size (kB) Used Available Used% Memory Buffers 513204 50168 463036 9% Real Memory 513204 499240 13964 97% Swap Space 5148856 796 5148060 0% / 40679248 21106328 19572920 51% /sys 0 0 0 0% /proc/bus/usb 0 0 0 0% /home 193540640 98867424 94673216 51% |
Attraverso snmpnetstat è possibile interrogare lo stato delle connessioni, come si farebbe con il programma netstat:
snmpnetstat [opzioni] nodo |
Oltre alle opzioni comuni di NET SNMP, altre consentono di limitare la visualizzazione a una porzione di proprio interesse. L'esempio seguente esegue semplicemente un'interrogazione complessiva, visualizzando gli indirizzi in forma numerica (opzione -n):
$
snmpnetstat -v 2c -c public -n localhost
[Invio]
Active Internet (tcp) Connections Proto Local Address Remote Address (state) tcp 127.0.0.1.4221 127.0.0.1.5901 ESTABLISHED tcp 127.0.0.1.5901 127.0.0.1.4221 ESTABLISHED tcp 172.21.77.5.707 172.21.254.254.861 TIMEWAIT tcp 172.21.77.5.1023 172.21.254.254.2049 ESTABLISHED tcp 172.21.77.5.1651 62.123.24.21.22 ESTABLISHED tcp 172.21.77.5.3865 172.21.254.254.111 TIMEWAIT tcp 172.21.77.5.4165 62.123.24.21.22 ESTABLISHED Active Internet (udp) Connections Proto Local Address udp *.9 udp *.69 udp *.111 udp *.137 udp *.138 udp *.514 udp *.623 udp *.638 udp *.812 udp *.924 udp *.1025 udp *.1028 udp *.1031 udp *.1048 udp *.2049 udp *.3130 udp *.9676 udp 127.0.0.1.53 udp 127.0.0.1.161 udp 172.21.77.5.53 udp 172.21.77.5.137 udp 172.21.77.5.138 |
Con snmpstatus è possibile ottenere alcune informazioni statistiche:
snmpstatus [opzioni] nodo |
Ecco un esempio comune:
$
snmpstatus -v 2c -c public localhost
[Invio]
[UDP: [127.0.0.1]:161]=>[Linux nanohost 2.6.17.1 #1 PREEMPT \ |
NET SNMP include un demone per offrire un servizio SNMP presso un elaboratore:
snmpd [opzioni] |
Di norma, questo programma viene avviato attraverso la procedura di inizializzazione del sistema, pertanto si interviene con script appositi del proprio sistema operativo (per esempio /etc/init.d/snmpd
). Inoltre, il file di configurazione dovrebbe essere /etc/snmp/snmpd.conf
.
La predisposizione del file di configurazione non è semplice; di solito si parte da quello già predisposto dalla propria distribuzione del sistema operativo, attraverso modifiche più o meno intuitive, contando sulle descrizioni contenute nei commenti. Tuttavia, eventualmente, se le proprie esigenze sono limitate al controllo degli accessi in modo semplificato, è possibile utilizzare il programma snmpconf per generare un file di configurazione, da zero. Segue un esempio per ottenere semplicemente la configurazione degli accessi in sola lettura a partire dall'elaboratore locale:
$
snmpconf -g basic_setup
[Invio]
The following installed configuration files were found: 1: /etc/snmp/snmpd.conf Would you like me to read them in? Their content will be merged with the output files created by this session. Valid answer examples: "all", "none","3","1,2,5" |
Read in which (default = all):
all
[Invio]
************************************************ *** Beginning basic system information setup *** ************************************************ |
Do you want to configure the information returned in the
\
\system MIB group (contact info, etc)? (default = y):
y
[Invio]
Configuring: syslocation Description: The [typically physical] location of the system. Note that setting this value here means that when trying to perform an snmp SET operation to the sysLocation.0 variable will make the agent return the "notWritable" error code. IE, including this token in the snmpd.conf file will disable write access to the variable. arguments: location_string |
The location of the system:
ufficio
[Invio]
Configuring: syscontact Description: The contact information for the administrator Note that setting this value here means that when trying to perform an snmp SET operation to the sysContact.0 variable will make the agent return the "notWritable" error code. IE, including this token in the snmpd.conf file will disable write access to the variable. arguments: contact_string |
The contact information:
tizio@brot.dg
[Invio]
Finished Output: syscontact tizio@brot.dg |
Do you want to properly set the value of the sysServices.0 OID
\
\(if you don't know, just say no)? (default = y):
n
[Invio]
************************************** *** BEGINNING ACCESS CONTROL SETUP *** ************************************** |
Do you want to configure the agent's access control?
\
\(default = y):
y
[Invio]
Do you want to allow SNMPv3 read-write user based access
\
\(default = y):
n
[Invio]
Do you want to allow SNMPv3 read-only user based access
\
\(default = y):
n
[Invio]
Do you want to allow SNMPv1/v2c read-write community access
\
\(default = y):
n
[Invio]
Do you want to allow SNMPv1/v2c read-only community access (default = y):
y
[Invio]
Configuring: rocommunity Description: a SNMPv1/SNMPv2c read-only access community name arguments: community [default|hostname|network/bits] [oid] |
The community name to add read-only access for:
public
[Invio]
The hostname or network address to accept this community
\
\name from [RETURN for all]:
127.0.0.1
[Invio]
The OID that this community should be restricted to
\
\[RETURN for no-restriction]:
[Invio]
Finished Output: rocommunity public 127.0.0.1 |
Do another rocommunity line? (default = y):
n
[Invio]
**************************************** *** Beginning trap destination setup *** **************************************** |
Do you want to configure where and if the agent will send
\
\traps? (default = y):
n
[Invio]
********************************** *** Beginning monitoring setup *** ********************************** |
Do you want to configure the agent's ability to monitor various
\
\aspects of your system? (default = y):
n
[Invio]
The following files were created: snmpd.conf These files should be moved to ... ... |
In pratica, al termine dell'esempio, si ottiene il file snmpd.conf
nella directory corrente, che l'utente può copiare probabilmente in /etc/snmp/
, o in una posizione analoga, in base all'impostazione del proprio sistema. Ecco il contenuto del file, omettendo tutti i commenti:
|
Naturalmente, soprattutto se si intende offrire l'accesso a elaboratori esterni, può essere conveniente cambiare il nome della comunità.
NET-SNMP
Andrea Manzini, SNMP: tutta la rete in punta di Management Protocol, Linux&C., maggio 2006, 52, pag. 15
Andrea Manzini, Estensione di SNMPd e uso di MRTG, Linux&C., giugno 2006, 53, pag. 35
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_al_protocollo_snmp.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]