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

Architettura

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: 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 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 e 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 lagent o il subagent.

SNMP versione 1 Il protocollo SNMP nella sua prima versione (SNMPv1) è stato definito inizialmente nel 1988 in RFC 1067 e 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 e 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.

VersionCommunity SNMP PDU Formato PDU per i messaggi di richiesta SNMPv1 (Get-request/Get-next-request/Set-request): PDU Type Request ID 0 0 Variable Bindings Formato PDU per i messaggi di risposta SNMPv1 (Get-response): PDU Type Request ID Error status Error index Variable Bindings 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: PDU Type Enterprise Agent address Generic trap type Specific trap code Time stamp Variable bindings 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.

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

SNMP versione 2 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 e introduce due nuovi tipi di messaggi: 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.

VersionHeaderSecurity Context-ID Context-Name SNMP PDU

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 Non-repeaters Max-repetitions Variable bindings 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

Architettura di Gestione 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).

Sicurezza 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 sicurezzahttp://www.net130.com/tutorial/other/Internet%20Overview.pdf– Chapter8-Network Management: 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 e aggiunge al formato dei messaggi un campo digest per garantire l'autenticazione tra due entità.

SNMPv2c