In informatica e telecomunicazioni Simple Network Management Protocol (SNMP) è un protocollo di rete senza connessione che appartiene alla suite di protocolli Internet definito dalla IETF (Internet Engineering Task Force). Opera al livello 7 del modello OSI, utilizzando come protocollo del livello trasporto UDP sulle porte 161 e 162, consentendo di semplificare la configurazione, gestione e supervisione (monitoraggio) di apparati collegati in una rete (siano essi nodi interni di commutazione come i dispositivi di rete o nodi terminali di utenza), riguardo a tutti quegli aspetti che richiedono azioni di tipo amministrativo (management).

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^[1]:

1. sistema di gestione (manager);
2. agente di gestione (agent o master agent), attivo nel dispositivo, ed eventuali subagent;
3. 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 gestione e la struttura dell'oggetto gestito. Nell'architettura SNMP, per ogni sottosistema è definita una base di dati detta 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, "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.

L'accesso alla MIB (in lettura e scrittura) rappresenta l'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. 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.

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;
• Get-next-request, con cui recupera l'oggetto successivo (nell'ordinamento lessicografico definito nella MIB);
• Set-request, attraverso cui il manager assegna un valore ad un oggetto.

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.

Il formato generale dei messaggi SNMPv1 è il seguente.

Formato PDU per i messaggi di richiesta SNMPv1 (Get-request/Get-next-request/Set-request):

Formato PDU per i messaggi di risposta SNMPv1 (Get-response):

• Request ID: serve per associare le richieste e le risposte;
• Error status: indica un tipo di errore (per i comandi Get/GetNext/Set è posto a 0);
• Error index: associa l'errore ad una particolare variabile specificata nel campo Variable Bindings (per i comandi Get/GetNext/Set è posto a 0);
• Variable Bindings: associa il nome della variabile con il suo valore corrente.

Formato per le PDU SNMPv1 di tipo Trap:

• Enterprise: identifica il tipo dell'oggetto che ha generato la trap;
• Agent address: restituisce l'indirizzo di tale oggetto;
• Generic trap type: restituisce un tipo generico di trap;
• Specific trap code: restituisce il codice specifico della trap;
• Time stamp: restituisce il tempo intercorso tra la richiesta e la generazione della trap;
• Variable Bindings: genera una lista di variabili contenenti informazioni sulla trap.

Le specifiche del protocollo SNMPv1, definite dall'IETF, hanno subito numerosi aggiornamenti nel corso degli anni. Esse sono contenute in una serie di documenti RFC. I primi RFC riguardanti SNMPv1 risalgono al 1988:

• RFC 1065 — Structure and identification of management information for TCP/IP-based internets
• RFC 1066 — Management information base for network management of TCP/IP-based internets
• RFC 1067 — A simple network management protocol

Tali documenti sono stati successivamente (1990) resi obsoleti da:

• RFC 1155 — Structure and identification of management information for TCP/IP-based internets
• RFC 1156 — Management information base for network management of TCP/IP-based internets
• RFC 1157 — A simple network management protocol

Infine dopo un breve lasso di tempo, l'RFC 1156 è stato rimpiazzato dal documento:

• RFC 1213 — Version 2 of management information base (MIB-2) for network management of TCP/IP-based internets

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^[2]:

• 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.

I messaggi SNMPv2 hanno un diverso formato rispetto a quello definito per SNMPv1.

Il formato della PDU dei messaggi di tipo Inform è lo stesso di quello dei messaggi Get, Get-next e Set, mentre quello dei messaggi Get-bulk è differente, ed è riportato di seguito.

Formato PDU di tipo Get-bulk:

• PDU type, Request ID e Variable bindings hanno la stessa funzione della versione precedente
• Non-repeaters e Max-repetitions definiscono il numero di valori ritornati dalla richiesta

SNMPv2 supporta sia la gestione della rete centralizzata di SNMPv1, sia una nuova strategia distribuita, basate su interazioni manager-to-manager. In un'architettura distribuita, alcuni sistemi possono operare sia nel ruolo di manager sia nel ruolo di agent. Quando un sistema agisce da agent accetta comandi da un manager di livello superiore. Questi comandi possono richiedere informazioni memorizzate localmente nel manager che sta agendo come agent, oppure richiedere informazioni di un agent subordinato così da operare come intermediario (proxy).

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^[3]:

• 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;
• Message sequence and timing modification (in Italiano, modifica della sequenza e della temporizzazione dei messaggi): un'entità non autorizzata può riordinare, ritardare o copiare e rimandare un messaggio sfruttando l'inaffidabilità del protocollo di livello trasporto UDP;
• Disclosure (in Italiano, divulgazione): un'entità non autorizzata può apprendere i valori degli oggetti gestiti monitorando i messaggi scambiati tra manager e agent.

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à.

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.^[4]

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.

SNMPv3 è stato definito dall'IETF in una serie di RFC prodotti a partire dal 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^[5]:

• comunicazione senza autenticazione né privacy (NoAuthNoPriv);
• comunicazione con autenticazione e senza privacy (AuthNoPriv);
• comunicazione con autenticazione e privacy (AuthPriv).

Attraverso questi meccanismi, il protocollo è in grado di garantire:

• Integrità dei messaggi: assicura che i messaggi non vengano modificati durante il transito sulla rete;
• Autenticazione: il ricevente può controllare che il messaggio provenga da una fonte valida;
• Crittografia: il mittente cifra il contenuto del messaggio in modo che non sia comprensibile ad una terza parte non autorizzata.

La tabella di seguito riporta le possibili combinazioni dei modelli di sicurezza^[6].

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. Una prima serie di RFC relativi ad SNMPv3 fu prodotta nel 1998:

• RFC 2271 - An Architecture for Describing SNMP Management Frameworks
• RFC 2272 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
• RFC 2273 - SNMP Applications
• RFC 2274 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
• RFC 2275 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Si noti che RFC 2271 rimpiazzò a distanza di pochi giorni il precedente RFC 2261. Una seconda serie di RFC relativi ad SNMPv3 fu prodotta già nel 1999:

• RFC 2570 - Introduction to Version 3 of the Internet-standard Network Management Framework
• RFC 2571 - An Architecture for Describing SNMP Management Frameworks
• RFC 2572 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
• RFC 2573 - SNMP Applications
• RFC 2574 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
• RFC 2575 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
• RFC 2576 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Infine, una nuova sequenza di RFC fu prodotta nel 2002:

• RFC 3410 - Introduction to Version 3 of the Internet-standard Network Management Framework
• RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
• RFC 3412 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
• RFC 3413 - SNMP Applications
• RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
• RFC 3415 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
• RFC 3417 - Transport Mappings for the Simple Network Management Protocol (SNMP)

Il documento sulla coesistenza tra le diverse versioni di SNMP (originariamente RFC 2576) fu aggiornato come RFC 3584 nel 2003. Infine, nel 2009 altri RFC riguardanti SNMPv3 sono stati prodotti dall'IETF:

• RFC 5590 - Transport Subsystem for the Simple Network Management Protocol (SNMP)
• RFC 5591 - Transport Security Model for the Simple Network Management Protocol (SNMP)
• RFC 5592 - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)

Del protocollo SNMP esistono diverse implementazioni sia per il ruolo di manager che per quello di agent.

Svariate implementazioni sono nella forma di 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^[7] (Java, open-source)
• SNMP4J^[8] (Java, open-source)
• PySNMP^[9] (Python, open-source)
• #SNMP Library^[10] (C#, open-source)

Altre implementazioni sono nella forma di tool a riga di comando o con interfaccia grafica.

Una suite di tool open-source è Net-SNMP. Net-SNMP è una collezione di tool usabili a riga di comando sia in ambiente Unix/Linux che in Windows. Essa supporta le versioni v1-v2c-v3 del protocollo SNMP. Di seguito è riportato un semplice esempio di uso del comando snmpget incluso nel package Net-SNMP.

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.

snmpget -v 2c -c public 149.144.21.254 1.3.6.1.2.1.1.1.0

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).

• SunNet Manager^[11]
• IBM Tivoli NetView^[12]

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.

• J.Kurose e K.Ross, Reti di calcolatori e internet: Un approccio Top-Down, 6ª ed., Pearson, 2013, ISBN 978-88-7192-938-5.
• (EN) William Stallings, Security Comes to SNMP: The New SNMPv3 Proposed Internet Standards, in The Internet Protocol Journal, vol. 1, n. 3, Cisco, dicembre 1998. URL consultato il 5 luglio 2017.

• (EN) RFC 3410 — Introduction and Applicability Statements for Internet Standard Management Framework, su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3413 — Simple Network Management Protocol (SNMP) Applications, su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3415 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3417 — Transport Mappings for the Simple Network Management Protocol (SNMP), su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3418 — Management Information Base (MIB) for the Simple Network Management Protocol (SNMP), su datatracker.ietf.org, Internet Engineering Task Force.
• (EN) RFC 3512 — Configuring Networks and Devices with Simple Network Management Protocol (SNMP), su datatracker.ietf.org, Internet Engineering Task Force.

• Amministratore di sistema
• Amministratore di rete
• Management Information Base
• Gestione di rete

• Wikimedia Commons contiene immagini o altri file su Simple Network Management Protocol

• SNMP FAQ part 1 (TXT), su snmp.com.
• SNMP FAQ part 2 (TXT), su snmp.com.
• Open source SNMP implementation, su net-snmp.org.
• Netsnmpj: Open source SNMP for Java, su netsnmpj.sourceforge.net.
• OpenSNMP: multi-threaded SNMPv3 engine, su sourceforge.net.

Portale Telematica: accedi alle voci di Teknopedia che parlano di reti, telecomunicazioni e protocolli di rete