Simple Network Management Protocol: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
fix
 
(4 versioni intermedie di 4 utenti non mostrate)
Riga 1:
In [[informatica]] e [[telecomunicazioni]] '''Simple Network Management Protocol''' ('''SNMP''') è un [[protocollo di rete]] senza [[connessione (informatica)|connessione]] che appartiene alla [[suite di protocolli Internet]] definito dalla [[Internet Engineering Task Force|IETF]] (''Internet Engineering Task Force''). Opera al [[livello applicazioni|livello 7]] del [[modello OSI]], utilizzando come protocollo del livello trasporto [[User Datagram Protocol|UDP]] sulle porte 161 e 162, consentendo di semplificare la [[configurazione (informatica)|configurazione]], gestione e supervisione (''[[monitoraggio|monitoring]]'') di apparati collegati in una [[Rete informatica|rete]] (siano essi [[nodoNodo (informaticatelecomunicazioni)|nodi]] interni di [[commutazione (telecomunicazioni)|commutazione]] come i [[dispositivi di rete]] o nodi [[terminale (informatica)|terminali]] di utenza), riguardo a tutti quegli aspetti che richiedono azioni di tipo amministrativo (''management'').
 
== Architettura ==
[[File:Snmp architecture v.2.png|thumb|upright=1.2|Interazione Manager-Agent in SNMP|400x400px]]
Il protocollo SNMP assume che la gestione di un dispositivo di rete sia possibile attraverso la lettura/scrittura di informazioni
elementari (nel seguito riferite con il termine inglese "managed objects") che rappresentano la configurazione corrente di un sistema.
Il [[framework]] concettuale definito dall'IETF per la gestione di reti TCP/IP prevede tre componenti fondamentali<ref>RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</ref>:
 
Il protocollo SNMP assume che la gestione di un dispositivo di rete sia possibile attraverso la lettura/scrittura di informazioni elementari (nel seguito riferite con il termine inglese "managed objects") che rappresentano la configurazione corrente di un sistema.
 
Il [[framework]] concettuale definito dall'IETF per la gestione di reti TCP/IP prevede tre componenti fondamentali<ref>RFC {{IETF|3411|An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks}}</ref>:
# sistema di gestione (''manager'');
# agente di gestione (''agent'' o ''master agent''), attivo nel dispositivo, ed eventuali ''subagent'';
# collezione di ''managed object''.
 
Ogni sistema gestito (per esempio un semplice nodo, un [[router]], una [[stampante]] o qualsiasi altro dispositivo che fornisca un'interfaccia di gestione SNMP) ospita un agente di gestione (''master agent'') e solitamente un certo numero di ''subagent''. Il master agent ha ''almeno'' il ruolo di intermediario fra il manager, applicazione remota che prende le decisioni di gestione, per esempio sotto il controllo diretto dell'operatore umano, e i ''subagent'', ''esecutori'' di tali decisioni. Ciascun ''subagent'' è incaricato di attuare le decisioni di gestione impartite dal manager nel contesto di un particolare sottosistema o relativamente a un particolare aspetto del sistema gestito. In sistemi che forniscono meccanismi di gestione particolarmente semplici, master agent e ''subagent'' possono confluire in un unico componente [[software]] capace sia di dialogare con il manager che di attuarne le decisioni; in questo caso si parlerà semplicemente di agent.
 
SNMP utilizza quindi una chiara separazione fra il [[protocollo di rete|protocollo]] di gestione e la struttura dell'oggetto gestito. Nell'architettura SNMP, per ogni sottosistema è definita una [[database|base di dati]] detta [[Management Information Base|MIB]] ([[Management Information Base]]), gestita dal corrispondente ''subagent'', la quale rappresenta lo stato del sottosistema gestito, o meglio, una proiezione di tale stato limitata agli aspetti di cui si vuole consentire la gestione. Si tratta di una base dati che si potrebbe definire, mutuando un termine dalla [[riflessione (informatica)|riflessione]], "causalmente connessa": in altre parole, ogni modifica alla MIB causa un corrispondente mutamento nello stato del sottosistema rappresentato, e viceversa. Garantire questa proprietà della MIB è la funzione principale del ''subagent'' che la gestisce.
 
[[File:Mib tree example.png|thumb|upright=1.2|Esempio di albero MIB|400x400px]]
 
L'accesso alla MIB (in lettura e scrittura) rappresenta l'[[interfaccia (informatica)|interfaccia]] fornita al manager per gestire il sistema. Ogni MIB, pur variando nei contenuti specifici, ha la medesima struttura generale a forma di albero ed i medesimi meccanismi generali di accesso da parte del manager (lettura e scrittura dei dati). Ogni oggetto nella MIB è identificato da un ''object'' ID (OID). Un OID si rappresenta mediante una sequenza di numeri interi separati da punti. Esso rappresenta il percorso all'interno dell'albero MIB per giungere dalla radice ad esso. I nodi foglia della MIB rappresentano i ''managed objects''.
Un OID si rappresenta mediante una sequenza di numeri interi separati da punti. Esso rappresenta il percorso all'interno dell'albero MIB per giungere dalla radice ad esso. I nodi foglia della MIB rappresentano i ''managed objects''.
Ad esempio, il nodo system della MIB SNMP è rappresentato dall'OID 1.3.6.1.2.1.1.
 
Grazie alla connessione causale della MIB, è quindi possibile al manager agire sullo stato del sottosistema in un modo che è largamente indipendente dalle procedure concrete che devono poi essere messe in atto (dal subagent) per estrarre le informazioni di stato rappresentate nella MIB, o attuare le modifiche di stato a seguito di cambiamenti dei contenuti della MIB. Così, per esempio, si potrebbe avere un dato di MIB che rappresenta l'[[indirizzo IP]] del sistema gestito; per modificare tale indirizzo, al manager è sufficiente accedere alla MIB sovrascrivendo il dato corrispondente, prescindendo dei dettagli di come una tale modifica venga poi concretamente "attuata" sul sistema gestito attraverso l{{'}}''agent'' o il ''subagent''.
 
== SNMP versione 1 ==
Il protocollo SNMP nella sua prima versione (SNMPv1) è stato definito inizialmente nel 1988 in RFC 1067 ed approvato come Internet Standard nel 1990 in RFC 1157. Lo schema di interazione fondamentale è di tipo richiesta-risposta.
 
Il protocollo prevede tre tipi di messaggi di richiesta, inviati dal manager agli agent dei sistemi gestiti:
* ''Get-request'', attraverso cui il manager recupera il valore di un oggetto;
Riga 32:
Ai tre tipi di messaggi di richiesta corrisponde un unico formato di messaggio di risposta: ''Get-response''.
 
Il protocollo prevede un ulteriore tipo di messaggio, ''Trap'', inviato da un agent SNMP ad un manager predefinito per la notifica asincrona di eventi:
* ''Trap'', per la notifica asincrona al manager di un evento.
 
I messaggi SNMPv1 sono costituiti da due parti: un'intestazione ed una ''[[Protocol Data Unit]] (PDU)''.
L'intestazione è costituita da:
* un numero di versione;
* un nome di ''comunità'' (''community string'').
Il nome di ''comunità'' è usato in SNMPv1 come forma elementare di autenticazione. SNMP assume che i dispositivi di una rete siano raggruppati in ''comunità'', ciascuna identificata da una stringa di 32 [[byte]].
Un singolo dispositivo può appartenere a più di una comunità. L'''agent'' SNMP accetta richieste solo da un manager della stessa comunità che si identifica con la medesima stringa.
Siccome la stringa ''comunità'' è trasmessa in chiaro nei messaggi SNMP, di fatto il protocollo SNMPv1 è considerato essere non sicuro e la maggior parte dei dispositivi impedisce operazioni di Set attraverso SNMPv1.
 
=== Formato dei messaggi SNMPv1 ===
Il formato generale dei messaggi SNMPv1 è il seguente.
 
Riga 89:
* Variable Bindings: genera una lista di variabili contenenti informazioni sulla trap.
 
[[File:Snmp-interaction v1.1.png|thumb|upright=1.2|Messaggi SNMPv1|400x400px]]
 
=== RFC relativi ad SNMPv1 ===
Le specifiche del protocollo SNMPv1, definite dall'IETF, hanno subito numerosi aggiornamenti nel corso degli anni. Esse sono contenute in una serie di documenti [[Request for Comments|RFC]]. I primi RFC riguardanti SNMPv1 risalgono al 1988:
 
Riga 111:
La versione 2 del protocollo SNMP (SNMPv2) fu proposta nel 1993 (RFC 1448), revisionata nel 1996 (RFC 1905) e successivamente modificata nel 2002 (RFC 3416).
 
SNMPv2 aggiunge nuovi meccanismi per la sicurezza, il supporto ad una nuova architettura di gestione distribuita ed introduce due nuovi tipi di messaggi<ref>RFC {{IETF|3416|Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)}}</ref>:
* ''Inform'': permette ad un manager di gestione di inviare tramite trap informazioni MIB ad un altro agente che risponde con una PDU response "No Error" come conferma di ricezione
* ''Get-bulk'': è usata dal manager per recuperare grandi quantità di dati evitando serie di Get e Get-Next ridondanti.
 
=== Formato dei messaggi SNMPv2 ===
I messaggi SNMPv2 hanno un diverso formato rispetto a quello definito per SNMPv1.
 
Riga 149:
SNMPv2 risolve il problema della mancanza d'autenticazione, la carenza di sicurezza più seria di SNMPv1. La mancanza di autenticazione costituisce un grave problema di sicurezza di SNMPv1, per effetto del quale SNMPv1 è utilizzato nelle reti aziendali per soli scopi monitoraggio (sole operazioni di tipo ''Get'').
 
SNMPv2 introduce meccanismi per prevenire i seguenti tipi di minacce alla sicurezza<ref>http://www.net130.com/tutorial/other/Internet%20Overview.pdf– Chapter8-Network Management</ref>:
* ''Masquerading'' (in Italiano, mascherarsi): un'entità non autorizzata può eseguire operazioni di gestione assumendo l'identità di un'entità autorizzata;
* ''Modification of information'' (in Italiano, modifica dell'informazione): un'entità non autorizzata può alterare un messaggio inviato da un'entità autorizzata;
Riga 157:
SNMPv2 consente la cifratura dei messaggi per garantire la riservatezza del contenuto ed aggiunge al formato dei messaggi un campo ''digest'' per garantire l'autenticazione tra due entità.
 
=== SNMPv2c ===
Community-Based Simple Network Management Protocol versione 2 (SNMPv2c), definito in RFC 1901, rimuove il complesso sistema di sicurezza introdotto da SNMPv2 riutilizzando la community-string della versione 1. SNMPv2c, così come descritto, è incompatibile con SNMPv1 per due motivi fondamentali: formato dei messaggi e operazioni. I messaggi di SNMPv2c, infatti, utilizzano un header e PDU differenti rispetto alla versione 1. Inoltre, SNMPv2c utilizza le operazioni ''GetBulk'' ed ''Inform'' non presenti nella versione precedente. Due possibili strategie per la coesistenza tra le due versioni sono: proxy agent e bilingual Network Management System.<ref>RFC {{IETF|3584|Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework}}</ref>
 
==== Proxy Agent ====
La soluzione tramite proxy deve essere utilizzata per abilitare la comunicazione tra entità che supportano differenti versioni dei messaggi SNMP. La comunicazione è garantita effettuando una traduzione delle PDU dei messaggi.
 
Nel caso in cui un messaggio SNMPv2 debba essere inviato ad un agente che supporta SNMPv1, si utilizzano le seguenti regole di traduzione:
* ''Get-Bulk-Request'' - L'agente proxy deve settare i campi NonRepeaters e MaxRepetitions a 0 e impostare il campo PDU Type dei messaggi a Get-Next-Request.
* ''Get-Response'' - Il proxy agent nel caso in cui non vi sono errori inoltra il messaggio inalterato, nel caso di errori seguire la procedura definita nell’RFC 3584.
* ''Trap'' - Il proxy agent effettua un mapping tra i messaggi della trap delle differenti versioni e inoltra il messaggio.
 
== SNMP versione 3 ==
SNMPv3 è stato definito dall'IETF in una serie di RFC prodotti a partire deldal 1998.
SNMPv3 non stravolge le precedenti versioni, ma aggiunge in RFC 3414 dei meccanismi che consentono i seguenti tre livelli di sicurezza nella comunicazione manager-agent<ref>RFC {{IETF|3414 - |User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}}</ref>:
* comunicazione senza autenticazione né privacy (''NoAuthNoPriv'');
* comunicazione con autenticazione e senza privacy (''AuthNoPriv'');
Line 210 ⟶ 211:
|}
 
=== RFC relativi ad SNMPv3 ===
Gli RFC relativi ad SNMPv3 sono molteplici.
Le specifiche del protocollo sono racchiuse in sequenze di RFC standard, che sono state soggette a modifiche nel corso degli anni.
Line 245 ⟶ 246:
* RFC 5592 - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
 
== Implementazioni ==
Del protocollo SNMP esistono diverse implementazioni sia per il ruolo di manager che per quello di agent.
 
=== Librerie SNMP ===
Svariate implementazioni sono nella forma di [[Libreria (software)|libreria di programmazione]], concepite per l'uso di SNMP in programmi più complessi.
Queste librerie sono disponibili per i più comuni linguaggi di programmazione.
 
* ''netsnmpj''<ref>http://netsnmpj.sourceforge.net/ netsnmpj: Open source SNMP for Java</ref> (Java, open-source)
* ''SNMP4J''<ref>http://www.snmp4j.org/ SNMP4J - The Object Oriented SNMP API for Java Managers and Agents</ref> (Java, open-source)
* ''PySNMP''<ref>http://pysnmp.sourceforge.net/ PySNMP</ref> (Python, open-source)
* ''#SNMP Library''<ref>https://www.nuget.org/packages/Lextm.SharpSnmpLib/ #SNMP Library</ref> (C#, open-source)
 
=== Tool SNMP ===
Altre implementazioni sono nella forma di tool a riga di comando o con interfaccia grafica.
 
Line 265 ⟶ 266:
snmpget -v 2c -c public 149.144.21.254 system.sysDescr.0
 
Il comando permette di recuperare il valore della variabile ''sysDescr'' dell'host 149.144.21.254. L'opzione -v specifica la versione del protocollo (in questo caso 2c), mentre l'opzione -c setta la community string per l'accesso al dispositivo (in questo caso public). È importante notare che ''system'' e ''sysDescr'' sono solo degli alias che permettono di accedere al valore della variabile, infatti ricordiamo che una MIB ha sempre una struttura ad albero e per accedere ad un nodo bisogna specificare il percorso per arrivare ad esso.
 
Il comando quindi può essere riscritto come segue specificando l'intero percorso utilizzando gli object-ID delle variabili.
Line 272 ⟶ 273:
Lo zero finale va sempre specificato perché le variabili potrebbero essere dei semplici scalari o delle tabelle (in tal caso andrebbe specificata la riga alla quale si vuole accedere).
 
=== Prodotti commerciali ===
* SunNet Manager<ref>https://docs.oracle.com/cd/E19957-01/802-4523/802-4523.pdf SunNet Manager 2.2.3 Reference Manual</ref>
* IBM Tivoli NetView<ref>https://www.ibm.com/us-en/marketplace/ibm-tivoli-netview-for-zos IBM Tivoli NetView for z/OS</ref>
Line 280 ⟶ 281:
Uno dei principali impieghi del SNMP è la sensoristica di monitoraggio ovvero la rilevazione continua di parametri relativi ad apparecchiature o servizi mediante sensori sia fisici che virtuali. Tale applicazione è ad esempio utilizzata nel monitoraggio di risorse informatiche.
 
== Note ==
<references/>
 
== Bibliografia ==
* {{cita libro | titolo= Reti di calcolatori e internet: Un approccio Top-Down | autore= J.Kurose | autore2= K.Ross | editore= Pearson | edizione= 6ª ed. | ISBN = 978-88-7192-938-5 | anno = 2013}}
* {{cita pubblicazione |nome= William|cognome= Stallings|titolo= Security Comes to SNMP: The New SNMPv3 Proposed Internet Standards|rivista= The Internet Protocol Journal|editore= Cisco|città= |volume= 1|numero= 3|anno= 1998|mese= dicembre|pp= |id= |pmid= |url= https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-20/snmpv3.html|lingua= Inglese|accesso= 5 luglio 2017|abstract= }}
 
=== Request for Comments ===
==Voci correlate==
* RFC {{IETF|3410 - |Introduction and Applicability Statements for Internet Standard Management Framework}}
* RFC {{IETF|3412 - Standard 62 - |Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}}
* RFC {{IETF|3413 - Standard 62 - |Simple Network Management Protocol (SNMP) ApplicationApplications}}
* RFC {{IETF|3414 - Standard 62 - |User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}}
* RFC {{IETF|3415 - Standard 62 - |View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}}
* RFC {{IETF|3417 - Standard 62 - |Transport Mappings for the Simple Network Management Protocol (SNMP)}}
* RFC {{IETF|3418 - Standard 62 - |Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)}}
* RFC {{IETF|3512 - |Configuring Networks and Devices with Simple Network Management Protocol (SNMP)}}
 
== Voci correlate ==
* [[Amministratore di sistema]]
* [[Amministratore di rete]]
Line 299 ⟶ 310:
* {{cita web|http://www.snmp.com/FAQs/snmp-faq-part1.txt|SNMP FAQ part 1}}
* {{cita web|http://www.snmp.com/FAQs/snmp-faq-part2.txt|SNMP FAQ part 2}}
* RFC 3410 - Introduction and Applicability Statements for Internet Standard Management Framework
* RFC 3412 - Standard 62 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
* RFC 3413 - Standard 62 - Simple Network Management Protocol (SNMP) Application
* RFC 3414 - Standard 62 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
* RFC 3415 - Standard 62 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
* RFC 3417 - Standard 62 - Transport Mappings for the Simple Network Management Protocol (SNMP)
* RFC 3418 - Standard 62 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
* RFC 3512 - Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
* {{cita web|http://www.net-snmp.org/| Open source SNMP implementation}}
* {{cita web|http://netsnmpj.sourceforge.net/|Netsnmpj: Open source SNMP for Java}}