Protocolo simple de administración de red
Familia	Familia de protocolos de Internet
Función	facilita el intercambio de información de administración entre dispositivos de red
Última versión	SNMPv3
Puertos	161/UDP, 162/UDP (Trap)
Ubicación en la pila de protocolos
Aplicación SNMP Transporte UDP y TCP Red IP (IPv4 y IPv6)
Estándares
RFC 1157 (SNMP, 1990) RFC 3410 (SNMPv3, 2002)
[editar datos en Wikidata]

El Protocolo simple de administración de red o SNMP (del inglés Simple Network Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre dispositivos de red. Los dispositivos que normalmente soportan SNMP incluyen routers, switches, servidores, estaciones de trabajo, impresoras, bastidores de módem y muchos más. Permite a los administradores supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su crecimiento.

SNMP es un componente de la suite de protocolos de Internet como se define por el IETF. Se compone de un conjunto de normas para la gestión de la red que incluye un protocolo de capa de aplicación, un esquema de bases de datos, y un conjunto de objetos de datos.^[1]​

Se han desarrollado tres versiones de SNMP:^[2]​

• SNMPv1 (lanzada en 1988), la versión original del protocolo;
• SNMPv2c (1993), la versión más utilizada;
• SNMPv3 (2002), la última versión, con mejoras de seguridad.

En usos típicos SNMP, uno o más equipos administrativos, llamados gerentes (managers), tienen la tarea de supervisión o la gestión de un grupo de hosts o dispositivos de una red informática. En cada sistema gestionado se ejecuta, en todo momento, un componente de software llamado agente que reporta la información al gerente a través de SNMP.

Los agentes SNMP exponen los datos de gestión en los sistemas administrados como variables. El protocolo también permite realizar tareas de gestión de activos, tales como la modificación y la aplicación de una nueva configuración a través de la modificación remota de estas variables. Las variables accesibles a través de SNMP están organizadas en jerarquías. Estas jerarquías y otros metadatos (tales como el tipo y la descripción de la variable), se describen por Bases de Información de Gestión (MIB).^{[cita requerida]}

Una red administrada a través de SNMP consta de tres componentes clave:

• Estaciones de administración de red (Network Management Stations, NMS);
• Dispositivos administrados;
• Agentes.

Estos componentes tienen las siguientes funciones:^{[cita requerida]}

Una estación de administración de red (NMS) ejecuta aplicaciones que supervisan y controlan a los dispositivos administrados. Los NMS proporcionan el volumen de recursos de procesamiento y memoria requeridos para la administración de la red. Puede haber uno o más NMS en una red administrada.

Un dispositivo administrado es un dispositivo que contiene un agente SNMP y reside en una red administrada. Estos recogen y almacenan información de administración, la cual es puesta a disposición de los NMS mediante SNMP. Los dispositivos administrados, a veces llamados elementos de red, pueden ser de muchos tipos, por ejemplo, routers, servidores de acceso, conmutadores de red, puentes de red, concentradores, computadores e impresoras.

Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Un agente posee un conocimiento local de información de administración (memoria libre, número de paquetes IP recibidos, rutas, etcétera), la cual es traducida a un formato compatible con SNMP y organizada en jerarquías.

Los dispositivos administrados son supervisados y controlados usando cuatro comandos SNMP básicos: lectura, escritura, notificación y operaciones transversales.^{[cita requerida]}

• El comando de lectura es usado por un NMS para supervisar elementos de red. El NMS examina diferentes variables que son mantenidas por los dispositivos administrados.
• El comando de escritura es usado por un NMS para controlar elementos de red. El NMS cambia los valores de las variables almacenadas dentro de los dispositivos administrados.
• El comando de notificación es usado por los dispositivos administrados para reportar eventos en forma asíncrona a un NMS. Cuando cierto tipo de evento ocurre, un dispositivo administrado envía una notificación al NMS.
• Las operaciones transversales son usadas por el NMS para determinar qué variables soporta un dispositivo administrado y para recoger secuencialmente información en tablas de variables, como por ejemplo, una tabla de rutas.

Una Base de Información de Administración (Management Information Base, MIB) es una colección de información organizada jerárquicamente. Las MIB son accedidas usando un protocolo de administración de red, como por ejemplo, SNMP.

Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de cualquier número de características específicas de un dispositivo administrado. Los objetos administrados están compuestos de una o más instancias de objeto, que son esencialmente variables.

Existen dos tipos de objetos administrados: escalares y tabulares. Los objetos escalares definen una simple instancia de objeto. Los objetos tabulares definen múltiples instancias de objeto relacionadas que están agrupadas conjuntamente en tablas MIB.

Un ejemplo de un objeto administrado es atInput, que es un objeto escalar que contiene una simple instancia de objeto, el valor entero que indica el número total de paquetes AppleTalk de entrada sobre una interfaz de un router.

Un identificador de objeto (object ID) identifica únicamente a un objeto administrado en la jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz anónima y los niveles, que son asignados por diferentes organizaciones.

El árbol MIB ilustra las variadas jerarquías asignadas por las diferentes organizaciones

Los identificadores de los objetos ubicados en la parte superior del árbol pertenecen a diferentes organizaciones estándares, mientras los identificadores de los objetos ubicados en la parte inferior del árbol son colocados por las organizaciones asociadas.

Los fabricantes pueden definir ramas privadas que incluyen los objetos administrados para sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están localizadas en la rama experimental.

El objeto administrado atInput podría ser identificado por el nombre de objeto iso.identified-organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput o por el descriptor de objeto equivalente 1.3.6.1.4.1.9.3.3.1.

El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos, los cuales en su conjunto son llamados mib-2. Los grupos son los siguientes:

• System (1);
• Interfaces (2);
• AT (3);
• IP (4);
• ICMP (5);
• TCP (6);
• UDP (7);
• EGP (8);
• Transmission (10);
• SNMP (11).

Es importante destacar que la estructura de una MIB se describe mediante el estándar ASN.1.

SNMP opera en la capa de aplicación del conjunto de protocolos de Internet (capa 7 del modelo OSI). El protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un pequeño grupo de mensajes (PDU) entre los administradores y agentes. La utilización de un mecanismo de este tipo asegura que las tareas de administración de red no afectarán al rendimiento global de la misma, ya que se evita la utilización de mecanismos de control y recuperación como los de un servicio orientado a la conexión, por ejemplo TCP.

Los puertos comúnmente utilizados para SNMP son los siguientes:

Número	Descripción
161	SNMP
162	SNMP-trap

El agente SNMP recibe solicitudes en el puerto UDP 161. El administrador puede enviar solicitudes de cualquier puerto de origen disponible para el puerto 161 en el agente. La respuesta del agente será enviado de vuelta al puerto de origen en el gestor. El administrador recibe notificaciones (Traps e InformRequests) en el puerto 162. El agente puede generar notificaciones desde cualquier puerto disponible. Cuando se utiliza con TLS, las solicitudes se reciben en el puerto 10161 y las notificaciones se envían al puerto 10162.

SNMPv1 especifica cinco unidades de datos de protocolo (PDU) centrales. Otros dos PDU, GetBulkRequest e InformRequest se añadieron en SNMPv2 y prorrogados a SNMPv3.^{[cita requerida]}

Todas las PDU de SNMP se construyen de la siguiente manera:

Cabecera IP

Cabecera UDP

Versión

Comunidad

Tipo de PDU

Id. de petición

Estado de error

Índice de error

Enlazado de variables

Para realizar las operaciones básicas de administración anteriormente nombradas, e

Los paquetes utilizados para enviar consultas y respuestas SNMP poseen el siguiente formato:

Versión

Comunidad

SNMP PDU

• Versión: Número de versión de protocolo que se está utilizando (por ejemplo 0 para SNMPv1, 1 para SNMPv2c, 2 para SNMPv2p y SNMPv2u, 3 para SNMPv3, ...);
• Comunidad: Nombre o palabra clave que se usa para la autenticación. Generalmente existe una comunidad de lectura llamada "public" y una comunidad de escritura llamada "private";
• SNMP PDU: Contenido de la Unidad de Datos de Protocolo, el que depende de la operación que se ejecute.

Los mensajes GetRequest, GetNextRequest, SetRequest y GetResponse utilizan la siguiente estructura en el campo SNMP PDU:

Tipo

Identificador

Estado de error

Índice de error

Enlazado de variables

• Identificador: Es un número utilizado por el NMS y el agente para enviar solicitudes y respuesta diferentes en forma simultánea;
• Estado e índice de error: Sólo se usan en los mensajes GetResponse´(en las consultas siempre se utiliza cero). El campo "índice de error" sólo se usa cuando "estado de error" es distinto de 0 y posee el objetivo de proporcionar información adicional sobre la causa del problema. El campo "estado de error" puede tener los siguientes valores:
  • 0: No hay error;
  • 1: Demasiado grande;
  • 2: No existe esa variable;
  • 3: Valor incorrecto;
  • 4: El valor es de solo lectura;
  • 5: Error genérico.
• Enlazado de variables: Es una serie de nombres de variables con sus valores correspondientes (codificados en ASN.1).

A través de este mensaje el NMS solicita al agente retornar el valor de un objeto de interés mediante su nombre. En respuesta el agente envía una respuesta indicando el éxito o fracaso de la petición. Si la petición fue correcta, el mensaje resultante también contendrá el valor del objeto solicitado. Este mensaje puede ser usado para recoger un valor de un objeto, o varios valores de varios objetos, a través del uso de listas.

Este mensaje es usado para recorrer una tabla de objetos. Una vez que se ha usado un mensaje GetRequest para recoger el valor de un objeto, puede ser utilizado el mensaje GetNextRequest para repetir la operación con el siguiente objeto de la tabla. Siempre el resultado de la operación anterior será utilizado para la nueva consulta. De esta forma un NMS puede recorrer una tabla de longitud variable hasta que haya extraído toda la información para cada fila existente.

Este tipo de mensaje es utilizado por el NMS para solicitar a un agente modificar valores de objetos. Para realizar esta operación el NMS envía al agente una lista de nombres de objetos con sus correspondientes valores.

Este mensaje es usado por el agente para responder un mensaje GetRequest, GetNextRequest, o SetRequest. En el campo "Identificador de Request" lleva el mismo identificador que el "request" al que está respondiendo.

Una trap es generado por el agente para reportar ciertas condiciones y cambios de estado a un proceso de administración. El formato de la PDU es diferente:

Tipo

Enterprise

Dirección del agente

Tipo genérico de trap

Tipo específico de trap

Timestamp

Enlazado de variables

• Enterprise: Identificación del subsistema de gestión que ha emitido el trap;
• Dirección del agente: Dirección IP del agente que ha emitido el trap;
• Tipo genérico de trap:
  • Cold start (0): Indica que el agente ha sido inicializado o reinicializado;
  • Warm start (1): Indica que la configuración del agente ha cambiado;
  • Link down (2): Indica que una interfaz de comunicación se encuentra fuera de servicio (inactiva);
  • Link up (3): Indica que una interfaz de comunicación se encuentra en servicio (activa);
  • Authentication failure (4): Indica que el agente ha recibido un requerimiento de un NMS no autorizado (normalmente controlado por una comunidad);
  • EGP neighbor loss (5): Indica que en sistemas en que los routers están utilizando el protocolo EGP, un equipo colindante se encuentra fuera de servicio;
  • Enterprise (6): En esta categoría se encuentran todos los nuevos traps incluidos por los vendedores.
• Tipo específico de trap: Es usado para traps privados (de fabricantes), así como para precisar la información de un determinado trap genérico;
• Timestamp: Indica el tiempo que ha transcurrido entre la reinicialización del agente y la generación del trap;
• Enlazado de variables: Se utiliza para proporcionar información adicional sobre la causa del mensaje.

Este mensaje es usado por un NMS que utiliza la versión 2 o 3 del protocolo SNMP típicamente cuando es requerida una larga transmisión de datos, tal como la recuperación de largas tablas. En este sentido es similar al mensaje GetNextRequest usado en la versión 1 del protocolo, sin embargo, GetBulkRequest es un mensaje que implica un método mucho más rápido y eficiente, ya que a través de un solo mensaje es posible solicitar la totalidad de la tabla.

Un NMS que utiliza la versión 2 o 3 del protocolo SNMP transmite un mensaje de este tipo a otro NMS con las mismas características, para notificar información sobre objetos administrados, utilizando el protocolo TCP, y enviara el InformRequest hasta que tenga un acuse de recibo.

SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. SNMPv1 opera a través de protocolos de la capa de transporte como UDP, IP, CLNS, DDP de AppleTalk e IPX de Novell. SNMPv1 es ampliamente utilizado y es el protocolo de gestión de red de facto en la comunidad de Internet.^[3]​

Los primeros RFC para SNMP, ahora conocido como SNMPv1, aparecieron en 1988:

• RFC 1065: Estructura e identificación de información de gestión para internet basadas en TCP / IP.
• RFC 1066: Base de información de gestión para la gestión de la red de internet basadas en TCP / IP.
• RFC 1067: Un protocolo simple de administración de red.
  

Estos protocolos estaban obsoletos por:

• RFC 1155: Estructura e identificación de información de gestión para internet basadas en TCP / IP.
• RFC 1156: Base de información de gestión para la gestión de la red de internet basadas en TCP / IP.
• RFC 1157: Un protocolo simple de administración de red.
  

Después de un corto tiempo, RFC 1156 (MIB-1) fue reemplazada por la más habitual:

• RFC 1213: Versión 2 de la base de información de gestión (MIB-2) para la gestión de la red de internet basadas en TCP / IP.

La versión 1 ha sido criticado por su falta de seguridad.^[4]​La autenticación de los clientes se realiza solo por una "cadena de comunidad", en efecto, un tipo de contraseña, la cual transmite en texto plano. El diseño de los años 80 de SNMPv1 fue realizado por un grupo de colaboradores que vieron que el producto patrocinado oficialmente (HEMS/CMIS/CMIP) por OSI/IETF/NSF eran tanto inaplicable en las plataformas informáticas de la época, así como potencialmente inviable. SNMP se aprobó basándose en la creencia de que se trataba de un protocolo provisional necesario para la toma de medidas del despliegue a gran escala de Internet y su comercialización. En esos tiempos, los estándares de autenticación y seguridad en Internet eran un sueño, a la vez desalentado por los grupos de diseño enfocados en protocolos.

SNMPv2 (definido por RFC 1441 y RFC 1452), revisa la versión 1 e incluye mejoras en las áreas de rendimiento, seguridad, y comunicación entre gestores. Introdujo GetBulkRequest, una alternativa a GetNextRequests iterativos para recuperar grandes cantidades de datos de gestión en una sola solicitud. Sin embargo, el nuevo sistema de seguridad basado en partes en SNMPv2, visto por muchos como demasiado complejo, no fue ampliamente aceptada.^[5]​Esta versión de SNMP alcanzado el nivel de madurez de Norma Propuesta, pero fue considerada obsoleta por las versiones posteriores.^[6]​

En la versión basada en la comunidad, Simple Network Management Protocol 2 o SNMPv2c, se define en los RFC 1901-RFC 1908. SNMPv2c comprende SNMPv2 sin el controvertido nuevo modelo de seguridad de SNMP v2, utilizando en su lugar el esquema simple de seguridad basado en la comunidad de SNMPv1. Esta versión es una de las relativamente pocas normas que alcanzan el nivel de madurez de «proyecto de norma» (draft standard) del IETF, y fue considerado de facto el estándar SNMPv2. Este también quedó obsoleto después por SNMPv3.^[7]​

En la versión de usuario Simple Network Management Protocol 2, o SNMPv2u, se define en el RFC 1909 y RFC 1910 . Este es un compromiso que pretende ofrecer una mayor seguridad que SNMPv1, pero sin incurrir en la alta complejidad de SNMPv2. Una variante de este se comercializó como SNMP v2 *, y el mecanismo fue finalmente adoptado como uno de los dos marcos de seguridad de SNMP v3.^[8]​

Tal como está actualmente especificada, SNMPv2c es incompatible con SNMPv1 en dos áreas clave: los formatos de mensajes y operaciones de protocolo. Mensajes SNMPv2c utilizan diferentes cabecera y la unidad de datos de protocolo (PDU) formatos de mensajes SNMPv1. SNMPv2c también utiliza dos operaciones de protocolo que no están especificados en SNMPv1. Además, RFC 3584 define dos posibles estrategias de coexistencia SNMPv1/v2c: agentes de proxy y sistemas de gestión de red bilingües.

Un agente SNMPv2 puede actuar como un agente proxy en nombre de dispositivos SNMPv1 administrados, de la siguiente manera:

• Un SNMPv2 NMS emite un comando destinado a un agente SNMPv1.
• El NMS envía el mensaje SNMP para el agente proxy SNMPv2.
• El agente proxy reenvía Cómo, GetNext y Set mensajes al agente SNMPv1 sin cambios.
• Mensajes GetBulk son convertidas por el agente proxy de GetNext mensajes y luego se envían al agente SNMPv1.

El agente proxy mapas de mensajes de captura SNMPv1 a SNMPv2 mensajes de captura y luego las envía al NMS.

Sistemas de gestión de red SNMPv2 Bilingües soportan tanto SNMPv1 y SNMPv2. Para apoyar este entorno de gestión dual, una aplicación para la gestión del NMS bilingües debe ponerse en contacto con un agente. El NMS examina la información almacenada en una base de datos local para determinar si el agente es compatible con SNMPv1 o SNMPv2. Sobre la base de la información en la base de datos, el NMS se comunica con el agente utilizando la versión adecuada de SNMP.

Aunque SNMPv3 no realiza cambios en el protocolo, aparte de la adición de seguridad criptográfica, da la impresión de ser muy diferente debido a las nuevas convenciones textuales, los conceptos y la terminología.^[9]​

SNMPv3 añadió principalmente la seguridad y mejoras de configuración remota SNMP. Debido a la falta de seguridad de las versiones previas de SNMP, los administradores de red usaban otros medios, tales como SSH para la configuración, contabilidad y gestión de fallos.

SNMPv3 se ocupa de cuestiones relacionadas con el despliegue a gran escala de SNMP, contabilidad y gestión de fallos. Actualmente, SNMP se utiliza principalmente para el control y la gestión del rendimiento.

SNMPv3 define una versión segura de SNMP y también facilita la configuración remota de las entidades SNMP. SNMPv3 ofrece un entorno seguro para la gestión de sistemas que abarcan los siguientes:

• Identificación de las entidades SNMP para facilitar la comunicación sólo entre entidades SNMP conocidas: Cada entidad SNMP tiene un identificador llamado snmpEngineID y comunicación SNMP es posible sólo si la entidad SNMP conoce la identidad de su interlocutor. Trampas y notificaciones son excepciones a esta regla.
• Soporte para los modelos de seguridad: Un modelo de seguridad puede definir la política de seguridad dentro de un dominio administrativo o una intranet. SNMPv3 contiene las especificaciones para USM.
• Definición de los objetivos de seguridad, donde los objetivos del servicio de autenticación de mensajes incluyen la protección contra lo siguiente:
  • Modificación de la información: Protección contra algunos no autorizados entidad que altera SNMP en tránsito mensajes generados por un principal autorizado.
  • Mascarada: Protección contra intentar operaciones de gestión no autorizadas por algún director al asumir la identidad de otra principal que cuenta con las autorizaciones correspondientes.
  • Modificación del flujo de mensajes: Protección contra mensajes que consiguen maliciosamente reordenado, retrasado, o reproducido para efectuar las operaciones de gestión autorizadas.
  • Divulgación: Protección contra escuchas en los intercambios entre los motores de SNMP.
• Especificación para el modelo de seguridad basada en el usuario (USM): consiste en la definición general de los siguientes mecanismos de comunicación disponibles:
  • Comunicación sin autenticación y privacidad (NoAuthNoPriv).
  • Comunicación con autenticación y sin privacidad (AuthNoPriv).
  • Comunicación con autenticación y privacidad (AuthPriv).

• Definición de diferentes protocolos de autenticación y privacidad: Actualmente, los protocolos de autenticación MD5, SHA y HMAC-SHA-2,^[10]​ y los protocolos de privacidad y CBC_DES CFB_AES_128 están admitidos en el USM.
• Definición de un procedimiento de descubrimiento: Para encontrar el SNMPEngineID de una entidad SNMP para una dirección de transporte común y dirección de punto final de transporte.
• Definición del procedimiento de sincronización de hora: Para facilitar la comunicación autenticado entre las entidades SNMP.
• Definición del marco MIB SNMP: Para facilitar la configuración remota y administración de la entidad SNMP.
• Definición de las MIB USM: Para facilitar la configuración remota y administración del módulo de seguridad.
• Definición de las MIB VACM: Para facilitar la configuración remota y administración del módulo de control de acceso.

El SNMPv3 se centra en dos aspectos principales, a saber, la seguridad y la administración. El aspecto de seguridad se dirige, ofreciendo tanto una sólida autenticación y cifrado de datos para la privacidad. El aspecto de la administración se centra en dos partes, a saber los originadores de notificación y agentes proxy. SNMPv3 define una serie de capacidades relacionadas con la seguridad. Las especificaciones iniciales definen la USM y VACM, que más tarde fueron seguidos por un modelo de seguridad de transporte que proporciona apoyo a través de SSH y SNMPv3 SNMPv3 en TLS y DTLS.

• USM (Modelo de Seguridad basado en Usuarios) proporciona funciones de autenticación y privacidad (encriptación) y opera en el nivel de mensaje.
• VACM (Modelo de Control de Acceso basado en Vista) determina si se permite a un director dado, acceso a un objeto MIB particular, para realizar funciones específicas y opera en el nivel de PDU.
• TSM (Modo de Seguridad del Transporte) proporciona un método para la autenticación y el cifrado de mensajes a través de los canales externos de seguridad. Dos transportes, SSH y TLS/DTLS, han definido que hacen uso de la especificación de TSM.

La seguridad ha sido la mayor debilidad de SNMP desde el principio. La autenticación en las versiones de SNMP 1 y 2 consiste sólo en una contraseña (cadena de comunidad) enviada en texto claro entre un gerente y agente. Cada mensaje SNMPv3 contiene los parámetros de seguridad que están codificados como una cadena de octetos. El significado de estos parámetros de seguridad depende del modelo de seguridad que se utiliza. SNMPv3 proporciona características de seguridad importantes:

• Confidencialidad: El cifrado de paquetes para impedir la escucha por una fuente no autorizada.
• Integridad: Integridad de los mensajes para asegurar que un paquete no ha sido alterado durante el tránsito que incluye un mecanismo opcional por repetición de paquetes.
• Autenticación: para comprobar que el mensaje es de una fuente válida.

A partir de 2004 el IETF reconoce el Protocolo de Gestión de Red Simple versión 3 como se define en los RFC 3411-RFC 3418^[11]​ (también conocido como STD0062) como la versión estándar actual de SNMP. El IETF ha designado SNMPv3 como un estándar completo de Internet,^[12]​ el más alto nivel de madurez de un RFC, y considera como obsoletas las versiones anteriores (designándolas diversamente "Histórico" u "Obsoleto"). En la práctica, las implementaciones de SNMP a menudo soportan múltiples versiones: Típicamente SNMPv1, SNMPv2c y SNMPv3.

SNMP se utiliza ampliamente en herramientas de monitorización como Nagios para recopilar datos sobre el estado y el rendimiento de los dispositivos de red.

Las implementaciones del protocolo SNMP pueden variar entre diferentes fabricantes. En algunos casos, SNMP es incorporado como característica adicional del sistema y no se considera seriamente como un elemento fundamental del diseño del mismo. Algunos de los principales fabricantes tienden a ampliar en exceso su interfaz de línea de comandos (siglas CLI en inglés) propietaria para configurar y controlar sus sistemas. En febrero de 2002 el Centro de Coordinación del Equipo de Respuesta de Emergencia de Computadores (CERT-CC) del Instituto de Ingeniería del Software Carnegie Mellon (CM-SEI) realizó un proceso consultivo sobre SNMPv1, el CA-2002-03, después, el Grupo de Programación Segura de la Universidad de Oulu dirigió un análisis sobre la gestión de mensajes SNMP. La mayor parte de implementaciones SNMP, independientemente de qué versión del protocolo, utilizan el mismo código de programación para descodificar las unidades de datos (PDU). Por ello muchos fabricantes han tenido que publicar parches para sus implementaciones de SNMP. Entre otros problemas que fueron encontrados en la decodificación de mensajes de trampa SNMP recibidos por la estación de gestión SNMP o las solicitudes recibidas por el agente SNMP en el dispositivo de la red.

Las potentes capacidades de escritura de SNMP, las cuales permiten la configuración de dispositivos de la red, no se han estado utilizado de forma masiva por muchos fabricantes, en parte por la falta de seguridad en las versiones SNMP anteriores a la v3, y por otra parte porque muchos dispositivos simplemente no son capaces de ser configurados a través de los cambios en los objetos MIB. Los requisitos de la operación Set de SNMP no son fáciles de implementar correctamente, y muchos fabricantes han optado por omitir el soporte de Set - probablemente para rebajar costes y reducir el tamaño del código, entre otras razones.^{[cita requerida]}

La estructura tipo árbol aparentemente simple y el indexado lineal del SNMP pueden no ser comprendidos suficientemente bien por las estructuras de datos que son elementos del diseño básico de la plataforma. En consecuencia, el procesamiento de consultas SNMP en ciertos conjuntos de datos pueden resultar en un uso más elevado de la CPU del necesario. Un ejemplo de esto serían las tablas de enrutamiento grandes, como BGP y IGP.^{[citation needed]}

Algunos valores de SNMP (en especial los valores tabulares) requieren conocimiento específico de esquemas de indexación de tablas, y estos valores de los índices no son necesariamente consistentes en todas las plataformas. Esto puede causar problemas de correlación cuando se recopila información de múltiples dispositivos que pueden no usan el mismo esquema de indexación de tablas (por ejemplo, al recopilar métricas sobre la utilización del disco, cuando un identificador de disco específico sea diferente entre plataformas).

Debido a que SNMP está diseñado para permitir a los administradores la configuración y monitorización de dispositivos de red de forma remota, puede utilizarse también para penetrar en una Red de Área Local (siglas LAN en inglés). Si SNMP no se va a utilizar en una red, debería deshabilitarse, porque aparte de crear una vulnerabilidad, consumirá ancho de banda disponible y ciclos de CPU innecesariamente. Un número significativo de herramientas de software podrían escanear la red completa a través de SNMP, por lo que errores de configuración del modo de lectura-escritura podrían hacer que una red fuese susceptible a los ataques.^[13]​^: 52

En el año 2001, Cisco publicó información que incluso en el modo de solo lectura la implementación de Cisco IOS 11.0 y 12.0 (el sistema operativo utilizado por los conmutadores y enrutadores de red) es vulnerable a ciertos ataques de denegación de servicio. Estos problemas de seguridad pueden arreglarse con una actualización de IOS.^[14]​ Cuando se configura el modo de solo lectura se debe prestar atención a la configuración del control de accesos y desde qué direcciones IP se aceptan mensajes SNMP. Si los servidores SNMP son identificados por su dirección IP, SNMP solo tiene permitido responder a estas IPs y deberán denegarse mensajes SNMP de otras direcciones. Sin embargo, la suplantación de identidad de direcciones IP sigue siendo una preocupación.^[13]​^: 54

SNMP está disponible en varias versiones, 1, 2 y 3; cada una tiene sus problemas de seguridad. SNMP v1 envía contraseñas en texto plano a través de la red. Por lo tanto, las contraseñas pueden leerse mediante detección de paquetes. SNMP v2 permite la descomposición de contraseñas con MD5, pero esto hay que configurarlo. Prácticamente todas las aplicaciones de administración de redes soportan SNMP v1, pero no necesariamente SNMP v2 o v3. SNMP v2 fue desarrollado específicamente para proporcionar seguridad en la información, esto es autenticación, privacidad y autorización, pero solamente la versión SNMP 2c obtuvo la aprobación del Grupo de Trabajo de Ingeniería de Internet (siglas IETF en inglés), mientras las versiones 2u y 2* no obtuvieron la aprobación de IETF debido a problemas de seguridad. SNMP v3 utiliza MD5, SHA y algoritmos de claves para asegurar la protección contra la modifiación de información no autorizada y ataques de enmascaramiento. Si se necesitara un nivel de seguridad superior, el algoritmo DES podría utilizarse opcionalmente en modo de encadenamiento de bloques de cifras. SNMP v3 está implementado desde publicación de la versión 12.0(3)T^: 52 de Cisco IOS.

SNMPv3 es susceptible a ataques de fuerza bruta y ataques de diccionario para adivinar las claves de autenticación, o encriptación, si estas claves se generan mediante contraseñas cortas (o débiles), o contraseñas que se puedan encontrar en un diccionario. SNMPv3 permite claves de encriptación distribuidas de forma aleatoria, y también generación de contraseñas suministradas por el usuario. El riesgo de la adivinación de cadenas de autenticación mediante los valores descompuestos transmitidos por la red depende de la función hash utilizada y de la longitud del valor descompuesto.^{[cita requerida]} SNMPv3 utiliza el protocolo de autenticación HMAC-SHA-2 para el Modelo de Seguridad del Usuario (siglas USM en inglés).^[15]​ El intercambio desafío-respuesta no fue utilizado para mejorar la seguridad. SNMPv3 (así como las otras versiones de SNMP) es un protocolo sin estado, y ha sido diseñado para minimizar la cantidad de interacciones entre el agente y el gestor. Por lo que la introducción de un intercambio desafío-respuesta para cada comando hubiera impuesto una carga sobre el agente (y probablemente sobre la red misma) que los diseñadores del protocolo consideraron excesivo e inaceptable.^{[cita requerida]}

Las deficiencias de seguridad en todas las versiones de SNMP pueden mitigarse mediante mecanismos de confidencialidad y autenticación IPsec. La implementación de SNMP sobre DTLS también está disponible.

Las aplicaciones de administración de redes basadas en SNMP envían las contraseña repetidamente durante las operaciones habituales a través de la red. Por lo tanto, las contraseñas de texto plano son un riesgo de seguridad significativo. Si se utiliza SNMP v2, los administradores de redes deben habilitar la encriptación de contraseñas en los dispositivos de la red, que son los servidores SNMP sobre los que se ejecuta. Esto puede hacerse con el comando snmp-server enable traps snmp authentication md5.^: 53

Muchas implementaciones de SNMP incluyen un tipo de descubrimiento automático cuando un nuevo componente de la red, como un conmutador o un enrutador, es descubierto y agrupado automáticamente. En SNMPv1 y v2c esto se realiza a través de una cadena comunitaria que es retransmitida en texto-plano a otros dispositivos. Es por este motivo que las cadenas comunitarias que están configuradas por defecto, son públicas para acceso de sólo lectura y privadas para acceso de lectura-escritura.^: 1874SNMP era el primero en la lista de Problemas de Configuración por Defecto Más Comunes del Instituto SANS y el número diez en la lista de Amenazas de Seguridad de Internet Más Críticas del año 2000.^[16]​ Los administradores de redes y sistemas no cambian estas configuraciones frecuentemente.^: 1874 La cadena comunitaria enviada por SNMP a través de la red no está encriptada. En cuanto se conociese la cadena de seguridad fuera de la organización podría convertirse en objetivo para un ataque. Para prevenir el descubrimiento de forma sencilla de la cadena comunitaria, SNMP debe configurarse para pasar las "trampas" de fallos de autenticación de nombres de comunidad y el dispositivo de gestión de SNMP necesita configurarse para reaccionar a la "trampa" de fallo de autenticación.^: 54

SNMPv1 y v2 son vulnerables a los ataques de suplantación de identidad de direcciones IP, tanto si se ejecuta sobre TCP o UDP, y los sujetos de traspaso de la lista de acceso de dispositivos han sido implementados para restringir el acceso SNMP. Los mecanismos de seguridad SNMPv3 cómo USM o TSM previenen el éxito de los ataques. Sería inútil emplear SNMPv3 VACM (Control de acceso basado en Vistas) sin asegurar los mensajes con USM o TSM.^{[cita requerida]}

• Monitoreo de red
• Anexo:Comparación de sistemas de monitorización de redes

• CMIP
• CMOT
• NETCONF

• Nagios
• Zenoss
• Zabbix
• NMIS

Los RFCs (Petición de comentarios en español) son propuestas oficiales para protocolos de red.

• RFC 1155 (STD 16) - Estructura e Identificación de Gestión de Información para los Internets basadas en TCP / IP-
• RFC 1156 (H) - Gestión de la Información Base para la administración de red de internets basadas en TCP / IP
• RFC 1157 (H) - Un protocolo simple de administración de redes (SNMP)
• RFC 1213 (STD 17) - Gestión de la Información Base para la administración de red de TCP / IP basados en internets: MIB-II
• RFC 1452 (Informativo) - La convivencia entre la versión 1 y la versión 2 del Marco de gestión de la Red de Internet estándar (obsoleto por RFC 1908 )
• RFC 1901 (Experimental) - Introducción a la SNMPv2 basado en la comunidad
• RFC 1902 (Proyecto de Norma) - Estructura de Gestión de Información para SNMPv2 (obsoleto por RFC 2578 )
• RFC 1908 (Normas Track) - convivencia entre la versión 1 y versión 2 del marco de gestión de red estándar de Internet
• RFC 2570 (Informativo) - Introducción a la Versión 3 del marco de gestión de red estándar de Internet (obsoleto por RFC 3410 )
• RFC 2578 (STD 58) - Estructura de la información Gestión de la versión 2 (SMIv2)
• RFC 3410 (Informativo) - Introducción y Aplicabilidad de las declaraciones de Marco de Gestión de Internet estándar
• RFC 3411 - Una arquitectura para describir los marcos Network Management Protocol (SNMP) simple de administración
• RFC 3412 - Mensaje Procesamiento y Despacho para el protocolo simple de administración de redes (SNMP)
• RFC 3413 - (SNMP) Aplicaciones Simple Network Management Protocol
• RFC 3414 - Modelo de seguridad basada en el usuario (USM) de la versión 3 del Protocolo simple de administración de redes (SNMPv3)
• RFC 3415 - Modelo basado View-Control de Acceso (VACM) para el protocolo simple de administración de redes (SNMP)
• RFC 3416 - Versión 2 del Protocolo de Operaciones del protocolo simple de administración de redes (SNMP)
• RFC 3417 - Transporte Mappings para el protocolo simple de administración de redes (SNMP)
• RFC 3418 - Management Information Base (MIB) para el protocolo simple de administración de redes (SNMP)
• RFC 3430 (Experimental) - Simple Network Management Protocol (SNMP) sobre Transmission Control Protocol (TCP) Transporte Cartografía
• RFC 3584 (BCP 74) - La convivencia entre la Versión 1, Versión 2 y Versión 3 del marco de gestión de red estándar de Internet
• RFC 3826 (propuesta) - El Advanced Encryption Standard (AES) algoritmo de cifrado en el SNMP basada en el usuario Modelo de seguridad
• RFC 5343 (Propuesta) - Simple Network Management Protocol (SNMP) Contexto EngineID Descubrimiento
• RFC 5590 (Proyecto) - Subsistema de transporte para el protocolo simple de administración de redes (SNMP)
• RFC 5591 (Proyecto) - Transporte Modelo de seguridad para el protocolo simple de administración de redes (SNMP)
• RFC 5592 (Propuesta) - Secure Shell Transport Modelo para el protocolo simple de administración de redes (SNMP)
• RFC 5608 (Propuesta) - autenticación remota Dial-In User Service (RADIUS) Uso para el protocolo simple de administración de redes (SNMP) Modelos de Transporte.
• RFC 6353 (Proyecto) - Transport Layer Security (TLS) para el modelo de transporte de Protocolo simple de administración de redes (SNMP)