Protocolo Simple de Manejo de Red (SNMP)

El Protocolo simple de administración de redes, Protocolo Simple de Manejo de Red o SNMP (Simple Network Management Protocol) es un protocolo estándar de Internet para recopilar y organizar información sobre dispositivos administrados en redes IP y para modificar esa información para cambiar el comportamiento del dispositivo. Los dispositivos que normalmente admiten SNMP incluyen módems de cable, enrutadores, conmutadores, servidores, estaciones de trabajo, impresoras y más.

SNMP se usa ampliamente en la administración de redes para el monitoreo de redes. SNMP expone datos de gestión en forma de variables en los sistemas gestionados organizados en una base de información de gestión (MIB) que describen el estado y la configuración del sistema. Estas variables se pueden consultar de forma remota (y, en algunas circunstancias, manipular) mediante la gestión de aplicaciones.

Se han desarrollado e implementado tres versiones importantes de SNMP. SNMPv1 es la versión original del protocolo. Las versiones más recientes, SNMPv2c y SNMPv3, presentan mejoras en el rendimiento, la flexibilidad y la seguridad.

SNMP es un componente del conjunto de protocolos de Internet según lo define el Grupo de trabajo de ingeniería de Internet (IETF). Consiste en un conjunto de estándares para la gestión de redes, incluido un protocolo de capa de aplicación, un esquema de base de datos y un conjunto de objetos de datos.

Resumen y conceptos básicos

En los usos típicos de SNMP, una o más computadoras administrativas llamadas administradores tienen la tarea de monitorear o administrar un grupo de hosts o dispositivos en una red de computadoras. Cada sistema administrado ejecuta un componente de software llamado agente que informa información a través de SNMP al administrador.

Una red administrada por SNMP consta de tres componentes clave:

• Dispositivos administrados
• Agente: software que se ejecuta en dispositivos administrados
• Estación de administración de red (NMS): software que se ejecuta en el administrador

Un dispositivo administrado es un nodo de red que implementa una interfaz SNMP que permite el acceso unidireccional (solo lectura) o bidireccional (lectura y escritura) a información específica del nodo. Los dispositivos administrados intercambian información específica del nodo con los NMS. A veces llamados elementos de red, los dispositivos administrados pueden ser cualquier tipo de dispositivo, incluidos, entre otros, enrutadores, servidores de acceso, conmutadores, módems de cable, puentes, concentradores, teléfonos IP, cámaras de video IP, hosts de computadora e impresoras.

Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Un agente tiene conocimiento local de la información de gestión y traduce esa información hacia o desde un formulario específico de SNMP.

Una estación de administración de red ejecuta aplicaciones que monitorean y controlan los dispositivos administrados. Los NMS proporcionan la mayor parte de los recursos de procesamiento y memoria necesarios para la gestión de la red. Uno o más NMS pueden existir en cualquier red administrada.

Base de datos de gestión

Los agentes SNMP exponen los datos de administración en los sistemas administrados como variables. El protocolo también permite realizar tareas de gestión activa, como cambios de configuración, mediante la modificación remota de estas variables. Las variables accesibles a través de SNMP están organizadas en jerarquías. SNMP en sí mismo no define qué variables debe ofrecer un sistema administrado. Más bien, SNMP utiliza un diseño extensible que permite que las aplicaciones definan sus propias jerarquías. Estas jerarquías se describen como una base de información de gestión (MIB). Los MIB describen la estructura de los datos de gestión de un subsistema de dispositivo; utilizan un espacio de nombres jerárquico que contiene identificadores de objetos (OID). Cada OID identifica una variable que se puede leer o configurar a través de SNMP. Las MIB utilizan la notación definida por la Estructura de la Información de Gestión Versión 2.0 (SMIv2,RFC 2578), un subconjunto de ASN.1.

Detalles del protocolo

SNMP opera en la capa de aplicación del conjunto de protocolos de Internet. Todos los mensajes SNMP se transportan a través del Protocolo de datagramas de usuario (UDP). El agente SNMP recibe solicitudes en el puerto UDP 161. El administrador puede enviar solicitudes desde cualquier puerto de origen disponible al puerto 161 del agente. La respuesta del agente se devuelve al puerto de origen en el administrador. El administrador recibe notificaciones (Traps e InformRequests) en el puerto 162. El agente puede generar notificaciones desde cualquier puerto disponible. Cuando se utiliza con Transport Layer Security o Datagram Transport Layer Security, 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. Se agregaron otras dos PDU, GetBulkRequest e InformRequest en SNMPv2 y la PDU de informe se agregó en SNMPv3. Todas las PDU de SNMP se construyen de la siguiente manera:

encabezado IP

Encabezado UDP

versión

comunidad

tipo PDU

ID de solicitud

estado de error

índice de error

enlaces variables

Los siete tipos de PDU de SNMP identificados por el campo de tipo de PDU son los siguientes:Obtener SolicitudUna solicitud de gerente a agente para recuperar el valor de una variable o lista de variables. Las variables deseadas se especifican en enlaces de variables (el campo de valor no se utiliza). El agente debe realizar la recuperación de los valores de las variables especificadas como una operación atómica. Se devuelve una respuesta con los valores actuales.Establecer solicitudUna solicitud de gerente a agente para cambiar el valor de una variable o lista de variables. Los enlaces de variables se especifican en el cuerpo de la solicitud. El agente debe realizar los cambios en todas las variables especificadas como una operación atómica. Se devuelve una respuesta con nuevos valores (actuales) para las variables.GetNextRequestUna solicitud de gerente a agente para descubrir las variables disponibles y sus valores. Devuelve una respuesta con enlace de variable para la siguiente variable lexicográficamente en la MIB. La MIB completa de un agente se puede recorrer mediante la aplicación iterativa de GetNextRequest a partir del OID 0. Las filas de una tabla se pueden leer especificando los OID de las columnas en los enlaces de variables de la solicitud.GetBulkRequestUna solicitud de administrador a agente para múltiples iteraciones de GetNextRequest. Una versión optimizada de GetNextRequest. Devuelve una respuesta con varios enlaces de variables caminados desde el enlace o enlaces de variables en la solicitud. Los campos de no repetidores y de repeticiones máximas específicos de PDU se utilizan para controlar el comportamiento de respuesta. GetBulkRequest se introdujo en SNMPv2.RespuestaDevuelve enlaces de variables y acuse de recibo del agente al administrador para GetRequest, SetRequest, GetNextRequest, GetBulkRequest e InformRequest. El informe de errores se proporciona mediante campos de estado de error y de índice de error. Aunque se usó como respuesta tanto para get como para sets, esta PDU se denominó GetResponse en SNMPv1.TrampaNotificación asíncrona de agente a gerente. Mientras que en otras comunicaciones SNMP, el administrador solicita activamente información al agente, estas son PDU que se envían desde el agente al administrador sin que se soliciten explícitamente. Las trampas SNMP permiten que un agente notifique a la estación de administración sobre eventos significativos mediante un mensaje SNMP no solicitado. Las PDU de captura incluyen el valor actual de sysUpTime, un OID que identifica el tipo de captura y enlaces de variables opcionales. El direccionamiento de destino para trampas se determina de una manera específica de la aplicación, generalmente a través de variables de configuración de trampas en la MIB. El formato del mensaje de trampa se cambió en SNMPv2 y la PDU pasó a llamarse SNMPv2-Trap.InformarSolicitudNotificación asincrónica reconocida. Esta PDU se introdujo en SNMPv2 y se definió originalmente como comunicación de administrador a administrador. Las implementaciones posteriores han aflojado la definición original para permitir que el agente se comunique con el administrador. Las notificaciones de administrador a administrador ya eran posibles en SNMPv1 usando una Trampa, pero como SNMP comúnmente se ejecuta sobre UDP donde la entrega no está asegurada y los paquetes perdidos no se informan, la entrega de una Trampa no estaba garantizada. InformRequest corrige esto ya que se devuelve un acuse de recibo.

RFC 1157 especifica que una implementación de SNMP debe aceptar un mensaje de al menos 484 bytes de longitud. En la práctica, las implementaciones de SNMP aceptan mensajes más largos. Si se implementa correctamente, un mensaje SNMP se descarta si falla la decodificación del mensaje y, por lo tanto, se ignoran las solicitudes SNMP mal formadas. Luego, una solicitud SNMP decodificada con éxito se autentica mediante la cadena comunitaria. Si falla la autenticación, se genera una trampa que indica un error de autenticación y se descarta el mensaje.

SNMPv1 y SNMPv2 usan comunidades para establecer confianza entre administradores y agentes. La mayoría de los agentes admiten tres nombres de comunidad, uno de solo lectura, uno de lectura y escritura y otro de captura. Estas tres cadenas comunitarias controlan diferentes tipos de actividades. La comunidad de solo lectura se aplica a las solicitudes de obtención. La cadena comunitaria de lectura y escritura se aplica a las solicitudes de configuración. La cadena trap community se aplica a la recepción de traps. SNMPv3 también usa cadenas comunitarias, pero permite la autenticación y comunicación seguras entre el administrador y el agente SNMP.

Versiones de protocolo

En la práctica, las implementaciones de SNMP a menudo admiten varias versiones: normalmente SNMPv1, SNMPv2c y SNMPv3.

Versión 1

SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. El diseño de SNMPv1 fue realizado en la década de 1980 por un grupo de colaboradores que vieron el esfuerzo patrocinado oficialmente por OSI/IETF/NSF (National Science Foundation) (HEMS/CMIS/CMIP) como inimplementable en las plataformas informáticas de la época y como potencialmente impracticable. SNMP fue aprobado en base a la creencia de que era un protocolo provisional necesario para dar pasos hacia el despliegue a gran escala de Internet y su comercialización.

La primera solicitud de comentarios (RFC) para SNMP, ahora conocida como SNMPv1, apareció en 1988:

• RFC 1065 — Estructura e identificación de la 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 redes de Internet basadas en TCP/IP
• RFC 1067: un protocolo de administración de red simple

En 1990, estos documentos fueron reemplazados por:

• RFC 1155 — Estructura e identificación de la 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 redes de Internet basadas en TCP/IP
• RFC 1157: un protocolo de administración de red simple

En 1991, el RFC 1156 (MIB-1) fue reemplazado por el más utilizado:

• RFC 1213: versión 2 de la base de información de gestión (MIB-2) para la gestión de redes de Internet basadas en TCP/IP

SNMPv1 se usa ampliamente y es el protocolo de administración de red de facto en la comunidad de Internet.

SNMPv1 puede ser transportado por protocolos de la capa de transporte, como el Protocolo de datagramas de usuario (UDP), el Protocolo de Internet (IP), el Servicio de red en modo sin conexión (CLNS) de OSI, el Protocolo de entrega de datagramas de AppleTalk (DDP) y el Intercambio de paquetes entre redes de Novell (IPX).

La versión 1 ha sido criticada por su poca seguridad. De hecho, la especificación permite el uso de autenticación personalizada, pero las implementaciones ampliamente utilizadas "solo admiten un servicio de autenticación trivial que identifica todos los mensajes SNMP como mensajes SNMP auténticos". La seguridad de los mensajes, por lo tanto, pasa a depender de la seguridad de los canales por los que se envían los mensajes. Por ejemplo, una organización puede considerar que su red interna es lo suficientemente segura como para no necesitar cifrado para sus mensajes SNMP. En tales casos, el "nombre de la comunidad", que se transmite en texto claro, tiende a verse como una contraseña de facto, a pesar de la especificación original.

Versión 2

SNMPv2, definido por RFC 1441 y RFC 1452, revisa la versión 1 e incluye mejoras en las áreas de rendimiento, seguridad y comunicaciones de administrador a administrador. Introdujo GetBulkRequest, una alternativa a las iterativas GetNextRequests para recuperar grandes cantidades de datos de gestión en una sola solicitud. El nuevo sistema de seguridad basado en fiestas introducido en SNMPv2, visto por muchos como demasiado complejo, no fue ampliamente adoptado. Esta versión de SNMP alcanzó el nivel de madurez del estándar propuesto, pero las versiones posteriores la consideraron obsoleta.

El protocolo de administración de red simple basado en la comunidad versión 2, o SNMPv2c, se define en RFC 1901 –RFC 1908. SNMPv2c comprende SNMPv2 sin el controvertido nuevo modelo de seguridad SNMP v2, utilizando en su lugar el esquema de seguridad simple basado en la comunidad de SNMPv1. Esta versión es uno de los relativamente pocos estándares que cumplen con el nivel de madurez del borrador del estándar del IETF, y fue ampliamente considerado como el estándar SNMPv2 de facto. Más tarde se reformuló como parte de SNMPv3.

El Protocolo simple de administración de red basado en el usuario versión 2, o SNMPv2u, se define en RFC 1909 – RFC 1910. Este es un compromiso que intenta ofrecer mayor seguridad que SNMPv1, pero sin incurrir en la alta complejidad de SNMPv2. Una variante de esto se comercializó como SNMP v2* y el mecanismo finalmente se adoptó como uno de los dos marcos de seguridad en SNMP v3.

Contadores de 64 bits

La versión 2 de SNMP introduce la opción para contadores de datos de 64 bits. La versión 1 fue diseñada solo con contadores de 32 bits que pueden almacenar valores enteros desde cero hasta 4290 millones (precisamente 4294967295). Un contador de versión 1 de 32 bits no puede almacenar la velocidad máxima de una interfaz de 10 gigabits o más, expresada en bits por segundo. Del mismo modo, las estadísticas de seguimiento de un contador de 32 bits para una interfaz de 10 gigabits o más pueden volver a cero en menos de un minuto, lo que puede ser un intervalo de tiempo más corto que el que se sondea un contador para leer su estado actual. Esto daría como resultado datos perdidos o no válidos debido a la transferencia de valores no detectados y la corrupción de los datos de seguimiento de tendencias.

El contador de la versión 2 de 64 bits puede almacenar valores de cero a 18,4 quintillones (precisamente 18 446 744 073 709 551 615) y, por lo tanto, es poco probable que experimente un cambio de contador entre eventos de sondeo. Por ejemplo, se prevé que Ethernet de 1,6 terabits esté disponible para 2025. Un contador de 64 bits que se incremente a una velocidad de 1,6 billones de bits por segundo podría retener información para dicha interfaz sin reinvertir durante 133 días.

Interoperabilidad SNMPv1 y SNMPv2c

SNMPv2c es incompatible con SNMPv1 en dos áreas clave: formatos de mensajes y operaciones de protocolo. Los mensajes SNMPv2c utilizan formatos de unidad de datos de protocolo (PDU) y encabezado diferentes a los de los mensajes SNMPv1. SNMPv2c también utiliza dos operaciones de protocolo que no se especifican en SNMPv1. Para superar la incompatibilidad, RFC 3584 define dos estrategias de coexistencia SNMPv1/v2c: agentes proxy y sistemas de gestión de red bilingües.

Agentes delegados

Un agente SNMPv2 puede actuar como agente proxy en nombre de los dispositivos administrados por SNMPv1. Cuando un NMS SNMPv2 emite un comando destinado a un agente SNMPv1, lo envía al agente proxy SNMPv2. El agente proxy reenvía los mensajes Get, GetNexty Setal agente SNMPv1 sin cambios. El agente proxy convierte los mensajes GetBulk en GetNextmensajes y luego se reenvían al agente SNMPv1. Además, el agente proxy recibe y asigna mensajes de captura SNMPv1 a mensajes de captura SNMPv2 y luego los reenvía al NMS.

Sistema de gestión de red bilingüe

Los sistemas de administración de red SNMPv2 bilingües admiten SNMPv1 y SNMPv2. Para admitir este entorno de administración dual, una aplicación de administración examina la información almacenada en una base de datos local para determinar si el agente admite SNMPv1 o SNMPv2. Según la información de la base de datos, el NMS se comunica con el agente mediante la versión adecuada de SNMP.

Versión 3

Aunque SNMPv3 no realiza cambios en el protocolo aparte de la adición de seguridad criptográfica, se ve muy diferente debido a las nuevas convenciones textuales, conceptos y terminología. El cambio más visible fue definir una versión segura de SNMP, agregando mejoras de seguridad y configuración remota a SNMP. El aspecto de la seguridad se aborda al ofrecer una autenticación sólida y el cifrado de datos para la privacidad. Para el aspecto de administración, SNMPv3 se enfoca en dos partes, a saber, los originadores de notificaciones y los reenviadores de proxy. Los cambios también facilitan la configuración y administración remotas de las entidades SNMP, además de abordar problemas relacionados con la implementación a gran escala, la contabilidad y la gestión de fallas.

Las funciones y mejoras incluyen:

• Identificación de entidades SNMP para facilitar la comunicación solo entre entidades SNMP conocidas: cada entidad SNMP tiene un identificador llamado SNMPEngineID, y la comunicación SNMP solo es posible si una entidad SNMP conoce la identidad de su par. Las trampas y las notificaciones son excepciones a esta regla.
• Compatibilidad con 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 un modelo de seguridad basado en el usuario (USM).
• Definición de objetivos de seguridad donde los objetivos del servicio de autenticación de mensajes incluyen protección contra lo siguiente:
  • Modificación de la información: protección contra alguna entidad SNMP no autorizada que altere los mensajes en tránsito generados por un principal autorizado.
  • Masquerade – Protección contra intentar operaciones de gestión no autorizadas por algún principal asumiendo la identidad de otro principal que tiene las autorizaciones apropiadas.
  • Modificación del flujo de mensajes: protección contra los mensajes que se reordenan, retrasan o reproducen maliciosamente para afectar las operaciones de administración no autorizadas.
  • Divulgación: protección contra escuchas en los intercambios entre motores SNMP.
• La especificación para USM – 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: los protocolos de autenticación MD5, SHA y HMAC-SHA-2 y los protocolos de privacidad CBC_DES y CFB_AES_128 son compatibles con el USM.
• Definición de un procedimiento de descubrimiento: para encontrar el SNMPEngineID de una entidad SNMP para una dirección de transporte y una dirección de punto final de transporte determinadas.
• Definición del procedimiento de sincronización horaria – Para facilitar la comunicación autenticada entre las entidades SNMP.
• Definición del marco MIB de SNMP: para facilitar la configuración y administración remotas de la entidad SNMP.
• Definición de las MIB de USM: para facilitar la configuración y administración remota del módulo de seguridad.
• Definición de las MIB del modelo de control de acceso basado en vistas (VACM): para facilitar la configuración y administración remotas del módulo de control de acceso.

La seguridad fue una de las mayores debilidades de SNMP hasta la v3. La autenticación en las versiones 1 y 2 de SNMP consiste en nada más que una contraseña (cadena comunitaria) enviada en texto claro entre un administrador y un agente. Cada mensaje SNMPv3 contiene parámetros de seguridad que se codifican como una cadena de octetos. El significado de estos parámetros de seguridad depende del modelo de seguridad que se utilice. El enfoque de seguridad en los objetivos v3:

• Confidencialidad: cifrado de paquetes para evitar la intromisión de una fuente no autorizada.
• Integridad: integridad del mensaje para garantizar que un paquete no haya sido manipulado durante el tránsito, incluido un mecanismo opcional de protección de reproducción de paquetes.
• Autenticación: para verificar que el mensaje proviene de una fuente válida.

v3 también define USM y VACM, que luego fueron seguidos por un modelo de seguridad de transporte (TSM) que brindó soporte para SNMPv3 sobre SSH y SNMPv3 sobre TLS y DTLS.

• USM (Modelo de seguridad basado en el usuario) proporciona funciones de autenticación y privacidad (cifrado) y opera a nivel de mensaje.
• VACM (Modelo de control de acceso basado en vista) determina si un principal dado tiene permitido el acceso a un objeto MIB en particular para realizar funciones específicas y opera a nivel de PDU.
• TSM (Modelo de seguridad de transporte) proporciona un método para autenticar y cifrar mensajes a través de canales de seguridad externos. Se han definido dos transportes, SSH y TLS/DTLS, que utilizan la especificación TSM.

A partir de 2004, el IETF reconoce el Protocolo simple de administración de redes, versión 3, tal como se define en RFC 3411– RFC 3418 (también conocido como STD0062), como la versión estándar actual de SNMP. El IETF ha designado a SNMPv3 como un estándar completo de Internet, el nivel de madurez más alto para un RFC. Considera que las versiones anteriores están obsoletas (designándolas de diversas formas como "Históricas" u "Obsoletas").

Problemas de implementación

Muchos proveedores no utilizan plenamente las potentes capacidades de escritura de SNMP, que permitirían la configuración de dispositivos de red, en parte debido a la falta de seguridad en las versiones de SNMP anteriores a SNMPv3, y en parte porque muchos dispositivos simplemente no pueden configurarse a través de dispositivos individuales. Cambios en el objeto MIB.

Algunos valores de SNMP (especialmente los valores tabulares) requieren un conocimiento específico de los esquemas de indexación de tablas y estos valores de índice no son necesariamente coherentes entre plataformas. Esto puede causar problemas de correlación al obtener información de varios dispositivos que pueden no emplear el mismo esquema de indexación de tablas (por ejemplo, obtener métricas de uso de disco, donde un identificador de disco específico es diferente entre plataformas).

Algunos proveedores de equipos importantes tienden a extender demasiado sus sistemas de control y configuración centrados en la interfaz de línea de comandos (CLI) patentada.

En febrero de 2002, el Centro de Coordinación del Equipo de Respuesta a Emergencias Informáticas (CERT-CC) del Instituto de Ingeniería de Software Carnegie Mellon (CM-SEI) emitió un Aviso sobre SNMPv1, luego de que el Grupo de Programación Segura de la Universidad de Oulu realizara un análisis exhaustivo del manejo de mensajes SNMP. La mayoría de las implementaciones de SNMP, independientemente de la versión del protocolo que admitan, usan el mismo código de programa para decodificar unidades de datos de protocolo (PDU) y se identificaron problemas en este código. Se encontraron otros problemas con la decodificación de mensajes de captura SNMP recibidos por la estación de administración SNMP o solicitudes recibidas por el agente SNMP en el dispositivo de red. Muchos proveedores tuvieron que emitir parches para sus implementaciones de SNMP.

Implicaciones de seguridad

Uso de SNMP para atacar una red

Debido a que SNMP está diseñado para permitir a los administradores monitorear y configurar dispositivos de red de forma remota, también se puede usar para penetrar en una red. Un número significativo de herramientas de software pueden escanear toda la red usando SNMP, por lo tanto, los errores en la configuración del modo de lectura y escritura pueden hacer que una red sea susceptible a ataques.

En 2001, Cisco publicó información que indicaba que, incluso en modo de solo lectura, la implementación SNMP de Cisco IOS es vulnerable a ciertos ataques de denegación de servicio. Estos problemas de seguridad se pueden solucionar mediante una actualización de IOS.

Si no se utiliza SNMP en una red, debe desactivarse en los dispositivos de red. Al configurar el modo de solo lectura de SNMP, se debe prestar mucha atención a la configuración del control de acceso y desde qué direcciones IP se aceptan los mensajes SNMP. Si los servidores SNMP se identifican por su IP, SNMP solo puede responder a estas IP y se denegarían los mensajes SNMP de otras direcciones IP. Sin embargo, la suplantación de direcciones IP sigue siendo un problema de seguridad.

Autenticación

SNMP está disponible en diferentes versiones, cada una tiene sus propios problemas de seguridad. SNMP v1 envía contraseñas en texto claro a través de la red. Por lo tanto, las contraseñas se pueden leer con el rastreo de paquetes. SNMP v2 permite el hash de contraseñas con MD5, pero esto debe configurarse. Prácticamente todo el software de administración de red es compatible con SNMP v1, pero no necesariamente con SNMP v2 o v3. SNMP v2 se desarrolló específicamente para proporcionar seguridad de datos, es decir, autenticación, privacidad y autorización, pero solo la versión 2c de SNMP obtuvo el respaldo del Grupo de Trabajo de Ingeniería de Internet (IETF), mientras que las versiones 2u y 2* no obtuvieron la aprobación de IETF debido a la seguridad. problemas. SNMP v3 utiliza MD5, Secure Hash Algorithm (SHA) y algoritmos con clave para ofrecer protección contra la modificación de datos no autorizada y los ataques de suplantación de identidad. Si se necesita un mayor nivel de seguridad, el Estándar de cifrado de datos (DES) se puede usar opcionalmente en el modo de encadenamiento de bloques de cifrado. SNMP v3 está implementado en Cisco IOS desde la versión 12.0(3)T.

SNMPv3 puede estar sujeto a ataques de fuerza bruta y de diccionario para adivinar las claves de autenticación o las claves de cifrado, si estas claves se generan a partir de contraseñas cortas (débiles) o contraseñas que se pueden encontrar en un diccionario. SNMPv3 permite proporcionar claves criptográficas aleatorias distribuidas uniformemente y generar claves criptográficas a partir de una contraseña proporcionada por el usuario. El riesgo de adivinar cadenas de autenticación a partir de valores hash transmitidos por la red depende de la función hash criptográfica utilizada y la longitud del valor hash. SNMPv3 utiliza el protocolo de autenticación HMAC-SHA-2 para el modelo de seguridad basado en el usuario (USM).SNMP no utiliza un protocolo de autenticación por desafío mutuo más seguro. SNMPv3 (al igual que otras versiones del protocolo SNMP) es un protocolo sin estado y ha sido diseñado con una cantidad mínima de interacciones entre el agente y el administrador. Por lo tanto, la introducción de un apretón de manos de desafío-respuesta para cada comando impondría una carga sobre el agente (y posiblemente sobre la propia red) que los diseñadores del protocolo consideraron excesiva e inaceptable.

Las deficiencias de seguridad de todas las versiones de SNMP pueden mitigarse mediante mecanismos de autenticación y confidencialidad de IPsec. SNMP también se puede transportar de forma segura a través de Datagram Transport Layer Security (DTLS).

Muchas implementaciones de SNMP incluyen un tipo de descubrimiento automático en el que un nuevo componente de red, como un conmutador o un enrutador, se descubre y sondea automáticamente. En SNMPv1 y SNMPv2c, esto se realiza a través de una cadena comunitaria que se transmite en texto claro a otros dispositivos. Las contraseñas de texto simple son un riesgo de seguridad significativo. Una vez que la cadena comunitaria se conoce fuera de la organización, podría convertirse en el objetivo de un ataque. Para alertar a los administradores de otros intentos de recopilar cadenas de comunidad, SNMP se puede configurar para pasar trampas de falla de autenticación de nombre de comunidad. Si se usa SNMPv2, el problema se puede evitar habilitando el cifrado de contraseña en los agentes SNMP de los dispositivos de red.

La configuración predeterminada común para cadenas comunitarias es "pública" para acceso de solo lectura y "privada" para lectura y escritura. Debido a los valores predeterminados bien conocidos, SNMP encabezó la lista de problemas comunes de configuración predeterminada del Instituto SANS y ocupó el décimo lugar en las 10 amenazas de seguridad de Internet más críticas de SANS para el año 2000. Los administradores de sistemas y redes con frecuencia no cambian estas configuraciones.

Ya sea que se ejecute sobre TCP o UDP, SNMPv1 y v2 son vulnerables a los ataques de suplantación de IP. Con la suplantación de identidad, los atacantes pueden eludir las listas de acceso de dispositivos en agentes que se implementan para restringir el acceso a SNMP. Los mecanismos de seguridad SNMPv3, como USM o TSM, evitan un ataque de suplantación de identidad.

Referencias RFC

• RFC 1155 (STD 16) — Estructura e identificación de la información de gestión para las Internet basadas en TCP/IP
• RFC 1156 (Histórico): base de información de administración para la administración de redes de Internet basadas en TCP/IP
• RFC 1157 (histórico): un protocolo simple de administración de red (SNMP)
• RFC 1213 (STD 17) — Base de información de gestión para la gestión de redes de Internet basadas en TCP/IP: MIB-II
• RFC 1452 (informativo): coexistencia entre la versión 1 y la versión 2 del marco de administración de red estándar de Internet (obsoleto por RFC 1908)
• RFC 1901 (Experimental): Introducción a SNMPv2 basado en la comunidad
• RFC 1902 (borrador de norma) — Estructura de la información de gestión para SNMPv2 (Obsoleto por RFC 2578)
• RFC 1908 (Standards Track): coexistencia entre la versión 1 y la 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 administración de red estándar de Internet (obsoleto por RFC 3410)
• RFC 2578 (STD 58): estructura de la información de gestión, versión 2 (SMIv2)
• RFC 3410 (informativo): introducción y declaraciones de aplicabilidad para el marco de gestión estándar de Internet
• STD 62 contiene los siguientes RFC:
  • RFC 3411: una arquitectura para describir marcos de administración de protocolo simple de administración de red (SNMP)
  • RFC 3412: Procesamiento y envío de mensajes para el Protocolo simple de administración de redes (SNMP)
  • RFC 3413 — Aplicaciones del protocolo simple de administración de red (SNMP)
  • RFC 3414: Modelo de seguridad basado en el usuario (USM) para la versión 3 del Protocolo simple de administración de redes (SNMPv3)
  • RFC 3415: Modelo de control de acceso basado en vistas (VACM) para el Protocolo simple de administración de redes (SNMP)
  • RFC 3416: versión 2 de las operaciones de protocolo para el protocolo simple de administración de red (SNMP)
  • RFC 3417 — Asignaciones de transporte para el Protocolo simple de administración de redes (SNMP)
  • RFC 3418 — Base de información de administración (MIB) para el Protocolo simple de administración de redes (SNMP)
• RFC 3430 (Experimental): Protocolo simple de administración de red (SNMP) sobre el mapeo de transporte del Protocolo de control de transmisión (TCP)
• RFC 3584 (BCP 74): coexistencia entre la versión 1, la versión 2 y la versión 3 del marco de gestión de red estándar de Internet
• RFC 3826 (propuesto): el algoritmo de cifrado del estándar de cifrado avanzado (AES) en el modelo de seguridad basado en el usuario de SNMP
• RFC 4789 (propuesto): Protocolo simple de administración de red (SNMP) sobre redes IEEE 802
• RFC 5343 (STD 78): detección de ID de motor de contexto de protocolo simple de administración de red (SNMP)
• RFC 5590 (STD 78): subsistema de transporte para el protocolo simple de administración de red (SNMP)
• RFC 5591 (STD 78): modelo de seguridad de transporte para el protocolo simple de administración de redes (SNMP)
• RFC 5592 (propuesto): modelo de transporte de shell seguro para el protocolo simple de administración de red (SNMP)
• RFC 5608 (propuesto): uso del servicio de usuario de acceso telefónico de autenticación remota (RADIUS) para modelos de transporte de protocolo simple de administración de redes (SNMP).
• RFC 6353 (STD 78): modelo de transporte de seguridad de la capa de transporte (TLS) para el protocolo simple de administración de redes (SNMP)
• RFC 7630 (propuesto): protocolos de autenticación HMAC-SHA-2 en el modelo de seguridad basado en el usuario (USM) para SNMPv3