SNMP (Simple Network Ma­na­ge­me­nt Protocol)

En una red en­co­n­tra­mos di­s­po­si­ti­vos de varios tipos desde or­de­na­do­res a im­pre­so­ras, pasando por se­r­vi­do­res, co­n­mu­ta­do­res o en­ru­ta­do­res. Cuanto mayor sea el número de pa­r­ti­ci­pa­n­tes, más esfuerzo y di­fi­cu­l­tad supondrá su gestión al ad­mi­ni­s­tra­dor. El uso de he­rra­mie­n­tas de gestión se ha co­n­ve­r­ti­do en una necesidad para ga­ra­n­ti­zar la fu­n­cio­na­li­dad y la seguridad de todos los sistemas a largo plazo. Un protocolo que muchas so­lu­cio­nes de software utilizan es el protocolo simple de ad­mi­ni­s­tra­ción de redes (SNMP), hoy en día uno de los pro­to­co­los estándar más im­po­r­ta­n­tes, admitido por casi todos los te­r­mi­na­les.

Después de apro­xi­ma­da­me­n­te dos años de de­sa­rro­llo, en mayo de 1990 se publicó la primera versión oficial del Simple Network Ma­na­ge­me­nt Protocol, abreviado como SNMP, en el RFC 1157. Los re­s­po­n­sa­bles de este protocolo de red, parte de la familia de pro­to­co­los de Internet y ahora también di­s­po­ni­ble en las versiones SNMPv2 y SNMPv3 son un grupo de trabajo de la IETF (Internet En­gi­nee­ri­ng Task Force). La función principal del SNMP protocol es pro­po­r­cio­nar mo­ni­to­ri­za­ción y control ce­n­tra­li­za­do de todos los co­m­po­ne­n­tes de una red in­fo­r­má­ti­ca. Con este objetivo, determina la es­tru­c­tu­ra de los paquetes de co­mu­ni­ca­ción que son ne­ce­sa­rios, así como la secuencia de co­mu­ni­ca­ción entre la estación central y los di­s­po­si­ti­vos in­di­vi­dua­les.

Para el tra­n­s­po­r­te de los paquetes se prevé el protocolo sin conexión UDP. Los datos y la in­fo­r­ma­ción tra­n­s­po­r­ta­da se almacenan en la de­no­mi­na­da base de ad­mi­ni­s­tra­ción de in­fo­r­ma­ción (MIB) en una es­tru­c­tu­ra je­rá­r­qui­ca en árbol.

La ad­mi­ni­s­tra­ción de red a través de SNMP se basa en un paradigma agente-gestor. La estación de ad­mi­ni­s­tra­ción central es el sistema desde el cual el ad­mi­ni­s­tra­dor observa y controla los distintos pa­r­ti­ci­pa­n­tes de la red. Para esta función integra un software de ad­mi­ni­s­tra­ción que permite la consulta de datos SNMP, así como el inicio de ciertas acciones. Los agentes, que a su vez son apli­ca­cio­nes, son el equi­va­le­n­te de los co­m­po­ne­n­tes de red in­di­vi­dua­les. Estos recopilan los datos re­le­va­n­tes en el host de destino y los tra­n­s­fie­ren a la estación de ad­mi­ni­s­tra­ción, pero también pueden realizar cambios en la co­n­fi­gu­ra­ción y des­en­ca­de­nar ciertas acciones. Estas apli­ca­cio­nes-agente ya están im­ple­me­n­ta­das de forma pre­de­te­r­mi­na­da en los sistemas más comunes de Windows y Linux, por ejemplo, en el SNMPD de Daemon (solo Linux).

Para la co­mu­ni­ca­ción entre el gestor y el agente, el SNMP protocol es­pe­ci­fi­ca siete tipos de mensajes posibles :

• Solicitud GET: las so­li­ci­tu­des GET son los mensajes pre­de­te­r­mi­na­dos para recuperar un registro pa­r­ti­cu­lar en el di­s­po­si­ti­vo de red deseado.
• Solicitud GETNEXT: este formato de mensaje es obli­ga­to­rio si también se quieren consultar registros de datos po­s­te­rio­res, por ejemplo, en tablas.
• Solicitud GETBULK: si un número definido de registros de datos se recupera con una sola solicitud, la apli­ca­ción del ad­mi­ni­s­tra­dor puede enviar una solicitud GETBULK (a partir de SNMPv2). Dicha solicitud es similar a múltiples so­li­ci­tu­des GETNEXT co­n­se­cu­ti­vas.
• Solicitud SET: las so­li­ci­tu­des SET permiten al ad­mi­ni­s­tra­dor modificar uno o más registros del di­s­po­si­ti­vo de red deseado o des­en­ca­de­nar acciones es­pe­cí­fi­cas. Un ejemplo de escenario en el que son ne­ce­sa­rios varios ajustes es la co­n­fi­gu­ra­ción de una dirección IP, que también requiere la es­pe­ci­fi­ca­ción de una máscara de red.
• Respuesta GET: si el gestor ha so­li­ci­ta­do uno o más registros o inicia acciones o cambios, el agente responde con re­s­pue­s­tas GET. Estos paquetes de respuesta contienen los datos so­li­ci­ta­dos, una co­n­fi­r­ma­ción de los ajustes o un mensaje de error si las so­li­ci­tu­des no pudieron re­s­po­n­de­r­se co­rre­c­ta­me­n­te.
• SNMP trap: las SNMP traps son mensajes de agentes enviados sin ser re­que­ri­dos por la estación del ad­mi­ni­s­tra­dor. Esto sucede cuando se produce un im­pre­vi­s­to. De­pe­n­die­n­do de qué tipo de im­pre­vi­s­to se trate, las trampas pueden di­s­ti­n­gui­r­se de dos maneras. La primera opción es la más simple y se trata de la in­co­r­po­ra­ción de un número de ide­n­ti­fi­ca­ción único: el ad­mi­ni­s­tra­dor puede buscar su si­g­ni­fi­ca­do en la base de datos de in­fo­r­ma­ción (MIB) ya me­n­cio­na­da. Con la opción número dos, la SNMP trap no solo informa sobre el im­pre­vi­s­to, sino que también contiene los datos co­rre­s­po­n­die­n­tes sin mostrar un número de ide­n­ti­fi­ca­ción es­pe­cí­fi­co.
• Solicitud INFORM: las so­li­ci­tu­des INFORM cumplen bá­si­ca­me­n­te la misma función que las SNMP traps. Sin embargo, a di­fe­re­n­cia de estas, los paquetes INFORM se ca­ra­c­te­ri­zan porque el ad­mi­ni­s­tra­dor confirma su recepción. Como resultado, el agente puede reenviar el mensaje si no llegó al ad­mi­ni­s­tra­dor en el primer intento.

Como ya me­n­cio­na­mos antes, el protocolo simple de ad­mi­ni­s­tra­ción de red prescribe el uso del protocolo de tra­n­s­po­r­te sin conexión UDP para la tra­n­s­mi­sión de los paquetes de mensajes. De esta manera, se garantiza una mo­ni­to­ri­za­ción de la red que ahorra recursos. SNMP usa el puerto UDP 161 para las diversas consultas GET que se envían a los agentes (in­clu­ye­n­do las re­s­pue­s­tas), mientras que las SNMP traps enviadas au­to­má­ti­ca­me­n­te utilizan el puerto UDP 162.

Ini­cia­l­me­n­te, SNMP no contaba con una po­si­bi­li­dad para que los gerentes se co­mu­ni­ca­ran entre sí, ni para que los agentes enviaran mensajes cuya llegada fuera co­n­fi­r­ma­da. Además, el soporte de muchas apli­ca­cio­nes ini­cia­l­me­n­te solo fu­n­cio­na­ba de manera parcial, a pesar de su enfoque de estándar abierto. Por lo tanto, las re­vi­sio­nes de los años si­guie­n­tes se centraron es­pe­cia­l­me­n­te en integrar los me­ca­ni­s­mos ne­ce­sa­rios en el simple network ma­na­ge­me­nt protoco. Otro esfuerzo im­po­r­ta­n­te del grupo de trabajo re­s­po­n­sa­ble del IETF, el cual se refleja en pa­r­ti­cu­lar en la tercera versión del protocolo, fue hacer que el pro­ce­di­mie­n­to de ad­mi­ni­s­tra­ción fuera más seguro desde el principio. Estos y otros pasos de op­ti­mi­za­ción del SNMP protocol se explican con más detalle en los si­guie­n­tes apartados, los cuales se centran en las versiones in­di­vi­dua­les SNMPv1, SNMPv2 y SNMPv3.

SNMPv1 es la primera versión del protocolo de ad­mi­ni­s­tra­ción de red que propone el modelo gestor-agente y la base para la co­mu­ni­ca­ción entre la estación del gestor y cada agente. El protocolo de gestión de red simple se describe como un protocolo sencillo que opera a nivel de apli­ca­ción y mediante UDP (User Datagram Protocol) y el protocolo de internet (IP), pero que también es co­m­pa­ti­ble con pro­to­co­los de red similares como Apple Talk DDP (protocolo de da­ta­gra­mas de entrega) o Internet Packet Exchange (IPX). El único mecanismo de seguridad integrado es el in­te­r­ca­m­bio de la de­no­mi­na­da cadena de comunidad, la cual se envía con las re­s­pe­c­ti­vas so­li­ci­tu­des.

Un problema im­po­r­ta­n­te con la primera versión del SNMP protocol es que la medida de seguridad de cadena de comunidad se transmite solo en texto sin formato. Por esta razón, los de­sa­rro­lla­do­res se pusieron a trabajar rá­pi­da­me­n­te en una nueva variante llamada Secure SNMP, en la que esta cadena se transmite en forma cifrada. Sin embargo, esta versión nunca se lanzó porque fue re­em­pla­za­da di­re­c­ta­me­n­te por SNMPv2. Otras mejoras respecto de la variante de protocolo original incluyen el manejo mejorado de errores, la capacidad de co­mu­ni­ca­ción de ad­mi­ni­s­tra­dor a ad­mi­ni­s­tra­dor y comandos SET más potentes. Sin embargo, la mayor ventaja sobre el SNMPv1 radica en los mensajes de tipo GETBULK (para consultar datos múltiples en una sola solicitud) e INFORM (para confirmar que se han recibido las re­s­pue­s­tas del agente).

Después de las primeras y más modestas ac­tua­li­za­cio­nes en la segunda versión del protocolo, el IETF se centró para el SNMPv3 co­m­ple­ta­me­n­te en la seguridad y reemplazó la cadena de la comunidad por el nombre de usuario y la co­n­tra­se­ña. Además, a di­fe­re­n­cia de sus pre­de­ce­so­res, el tercer protocolo incluye funciones para cifrar la tra­n­s­mi­sión de los paquetes SNMP. En general, SNMPv3 ofrece tres tipos di­fe­re­n­tes de au­te­n­ti­ca­ción y cifrado: