Hispanopedia Wiki
Articulo de referencia

Protocolo simple de administración de red

El Protocolo Simple de Administración de Red ( SNMP ) es un protocolo estándar de Internet para recopilar y organizar información sobre dispositivos administrados en redes IP y ...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo Simple de Administración de Red ( SNMP ) es un protocolo estándar de Internet para recopilar y organizar información sobre dispositivos administrados en redes IP y para modificar dicha información con el fin de cambiar el comportamiento de los dispositivos. Los dispositivos que suelen ser compatibles con SNMP incluyen módems de cable , enrutadores , conmutadores de red , servidores, estaciones de trabajo, impresoras y otros. [ 1 ]

SNMP se utiliza ampliamente en la gestión de redes para la monitorización de las mismas . SNMP expone datos de gestión en forma de variables en los sistemas gestionados, organizadas en una base de información de gestión (MIB), que describe el estado y la configuración del sistema. Estas variables pueden ser consultadas remotamente (y, en algunos casos, manipuladas) por aplicaciones de gestión de red .

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, ofrecen mejoras en rendimiento, flexibilidad y seguridad.

SNMP es un componente del conjunto de protocolos de Internet definido por el Grupo de Trabajo de Ingeniería de Internet (IETF). Consta de un conjunto de estándares para la gestión de redes, que incluye un protocolo de capa de aplicación , un esquema de base de datos y un conjunto de objetos de datos . [ 2 ]

Descripción general y conceptos básicos

Principio de la comunicación SNMP

En los usos típicos de SNMP, uno o más ordenadores administrativos, denominados gestores, tienen la tarea de supervisar o gestionar un grupo de hosts o dispositivos en una red informática . Cada sistema gestionado ejecuta un componente de software llamado agente que envía información al gestor a través de SNMP.

Una red gestionada mediante SNMP consta de tres componentes clave:

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 sistemas de gestión de red (NMS). A veces denominados elementos de red, los dispositivos administrados pueden ser de cualquier tipo, incluyendo, entre otros, enrutadores , servidores de acceso , conmutadores , módems de cable , puentes , concentradores , teléfonos IP , cámaras de vídeo IP , ordenadores y impresoras .

Un agente es un módulo de software de gestión de red que reside en un dispositivo gestionado. Un agente posee conocimiento local de la información de gestión y la traduce a un formato específico de SNMP o la convierte desde él.

Una estación de administración de red ejecuta aplicaciones que supervisan y controlan los dispositivos administrados. Las estaciones de administración de red proporcionan la mayor parte de los recursos de procesamiento y memoria necesarios para la administración de la red. Puede haber una o más estaciones de administración de red en cualquier red administrada.

base de información de gestión

Los agentes SNMP exponen los datos de gestión de los sistemas gestionados como variables. El protocolo también permite 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 no define qué variables debe ofrecer un sistema gestionado. En cambio, SNMP utiliza un diseño extensible que permite a las aplicaciones definir sus propias jerarquías. Estas jerarquías se describen como una base de información de gestión (MIB). Las 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 objeto (OID). Cada OID identifica una variable que se puede leer o establecer a través de SNMP. Las MIB utilizan la notación definida por Structure of Management Information Version 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 mediante el 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 envía de vuelta al puerto de origen del 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 Seguridad de la Capa de Transporte o Seguridad de la Capa de Transporte de Datagramas , las solicitudes se reciben en el puerto 10161 y las notificaciones se envían al puerto 10162. [ 3 ]

SNMPv1 especifica cinco unidades de datos de protocolo (PDU) principales. En SNMPv2 se añadieron otras dos PDU, GetBulkRequest e InformRequest , y en SNMPv3 se añadió la PDU Report . Todas las PDU de SNMP se construyen de la siguiente manera:

Los siete tipos de PDU SNMP, identificados por el campo PDU-type , son los siguientes:

Obtener solicitud
Solicitud del administrador al agente para recuperar el valor de una variable o lista de variables. Las variables deseadas se especifican en las asignaciones de variables (el campo de valor no se utiliza). La recuperación de los valores de las variables especificadas se realiza como una operación atómica por parte del agente. Se devuelve una respuesta con los valores actuales.
SetRequest
Solicitud del administrador al agente para cambiar el valor de una variable o lista de variables. Las asignaciones de variables se especifican en el cuerpo de la solicitud. El agente realizará los cambios en todas las variables especificadas como una operación atómica. [ 4 ] Se devuelve una respuesta con los nuevos valores (actuales) de las variables.
ObtenerSiguienteSolicitud
Solicitud de administrador a agente para descubrir las variables disponibles y sus valores. Devuelve una respuesta con la vinculación de variables para la siguiente variable lexicográfica en la MIB. La MIB completa de un agente se puede recorrer mediante la aplicación iterativa de GetNextRequest a partir del OID 0. Se pueden leer filas de una tabla especificando los OID de las columnas en las vinculaciones de variables de la solicitud.
Obtener solicitud masiva
Una solicitud de administrador a agente para múltiples iteraciones de GetNextRequest . Una versión optimizada de GetNextRequest . Devuelve una respuesta con múltiples enlaces de variables recorridos desde el enlace o enlaces de variables en la solicitud. Los campos de no repetidores y repeticiones máximas específicos de PDU se utilizan para controlar el comportamiento de la respuesta. GetBulkRequest se introdujo en SNMPv2.
Respuesta
Devuelve las vinculaciones de variables y la confirmación del agente al administrador para GetRequest , SetRequest , GetNextRequest , GetBulkRequest e InformRequest . Los campos error-status y error-index proporcionan información sobre los errores . Aunque se utilizaba como respuesta tanto a las solicitudes get como a las set, esta PDU se denominaba GetResponse en SNMPv1.
Trampa
Notificación asíncrona del agente al administrador. Mientras que en otras comunicaciones SNMP el administrador solicita activamente información al agente, estas son PDU que el agente envía 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 importantes mediante un mensaje SNMP no solicitado. Las PDU de trampa incluyen el valor actual de sysUpTime , un OID que identifica el tipo de trampa y enlaces de variables opcionales. El direccionamiento de destino para las trampas se determina de una manera específica de la aplicación, normalmente a través de variables de configuración de trampa en la MIB. El formato del mensaje de trampa cambió en SNMPv2 y la PDU pasó a llamarse SNMPv2-Trap .
Solicitud de información
Notificación asíncrona confirmada. Esta PDU se introdujo en SNMPv2 y originalmente se definió como comunicación de administrador a administrador . [ 5 ] Implementaciones posteriores han flexibilizado la definición original para permitir comunicaciones de agente a administrador . [ 6 ] [ 7 ] [ 8 ] Las notificaciones de administrador a administrador ya eran posibles en SNMPv1 usando una Trap , pero como SNMP suele funcionar sobre UDP, donde la entrega no está asegurada y los paquetes perdidos no se informan, la entrega de una Trap no estaba garantizada. InformRequest soluciona esto, ya que se devuelve una confirmación al recibirla. [ 7 ]

RFC 1157 especifica que una implementación SNMP debe aceptar un mensaje de al menos 484 bytes de longitud. En la práctica, las implementaciones SNMP aceptan mensajes más largos. [ 9 ] : 1870 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. Una solicitud SNMP decodificada correctamente se autentica mediante la cadena de comunidad. Si la autenticación falla, se genera una trampa que indica un fallo de autenticación y se descarta el mensaje. [ 9 ] : 1871 

SNMPv1 y SNMPv2c utilizan comunidades para establecer la confianza entre administradores y agentes. La mayoría de los agentes admiten tres nombres de comunidad: uno para lectura, otro para lectura y escritura, y otro para trampas. Estas tres cadenas de comunidad controlan diferentes tipos de actividades. La comunidad de lectura se aplica a las solicitudes de obtención . La cadena de comunidad de lectura y escritura se aplica a las solicitudes de establecimiento . La cadena de comunidad de trampas se aplica a la recepción de trampas . SNMPv3 también utiliza cadenas de comunidad, pero permite la autenticación y comunicación seguras entre el administrador y el agente SNMP. [ 10 ]

Versiones del protocolo

En la práctica, las implementaciones de SNMP suelen admitir varias versiones: normalmente SNMPv1, SNMPv2c y SNMPv3. [ 11 ] [ 12 ]

Versión 1

SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. Su diseño se desarrolló en la década de 1980 por un grupo de colaboradores que consideraban que el proyecto HEMS/CMIS/CMIP, patrocinado oficialmente por la OSI/IETF/NSF ( Fundación Nacional de Ciencias ), era inviable en las plataformas informáticas de la época y potencialmente inviable. SNMP fue aprobado bajo la convicción de que se trataba de un protocolo provisional necesario para avanzar hacia el despliegue a gran escala de Internet y su comercialización.

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

  • RFC 1065 — Estructura e identificación de la información de gestión para redes basadas en TCP/IP  
  • RFC 1066 — Base de información de gestión para la administración de redes de Internet basadas en TCP/IP  
  • RFC 1067 — Un protocolo sencillo de gestión de red  

En 1990, estos documentos fueron reemplazados por:

  • RFC 1155 — Estructura e identificación de la información de gestión para redes basadas en TCP/IP  
  • RFC 1156 — Base de información de gestión para la administración de redes de Internet basadas en TCP/IP  
  • RFC 1157 — Un protocolo sencillo de gestión de red  

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 es ampliamente utilizado y es el protocolo de gestión de red de facto en la comunidad de Internet. [ 13 ]

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

La versión 1 ha sido criticada por su escasa seguridad. [ 14 ] De hecho, la especificación permite el uso de autenticación personalizada, pero las implementaciones más utilizadas "solo admiten un servicio de autenticación trivial que identifica todos los mensajes SNMP como mensajes SNMP auténticos". [ 15 ] Por lo tanto, la seguridad de los mensajes depende de la seguridad de los canales por los que se envían. Por ejemplo, una organización puede considerar que su red interna es lo suficientemente segura como para que no sea necesario el cifrado de sus mensajes SNMP. En tales casos, el nombre de la comunidad , que se transmite en texto plano , tiende a considerarse 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 entre administradores. Introdujo GetBulkRequest , una alternativa a las solicitudes iterativas GetNextRequest para recuperar grandes cantidades de datos de administración en una sola solicitud. El nuevo sistema de seguridad basado en partes introducido en SNMPv2, considerado por muchos como excesivamente complejo, no tuvo una amplia adopción. [ 14 ] Esta versión de SNMP alcanzó el nivel de madurez de Estándar Propuesto, pero fue considerada obsoleta por versiones posteriores. [ 16 ]  

El Protocolo simple de administración de red basado en la comunidad versión 2 , o SNMPv2c , se define en los RFC 1901 a 1908. SNMPv2c comprende SNMPv2 sin el controvertido modelo de seguridad SNMPv2, utilizando en su lugar el esquema de seguridad simple basado en la comunidad de SNMPv1. Esta versión es uno de los pocos estándares que cumplen con el nivel de madurez de Borrador de Estándar del IETF y fue ampliamente considerado el estándar SNMPv2 de facto . [ 16 ] Posteriormente se reformuló como parte de SNMPv3. [ 17 ]  

El protocolo SNMPv2u ( User-Based Network Management Protocol versión 2 ) se define en los RFC 1909 a 1910. Se trata de una solución intermedia que busca ofrecer mayor seguridad que SNMPv1, pero sin la alta complejidad de SNMPv2. Una variante de este protocolo se comercializó como SNMP v2* , y el mecanismo finalmente se adoptó como uno de los dos marcos de seguridad en SNMP v3. [ 18 ]  

contadores de 64 bits

La versión 2 de SNMP introduce la opción de contadores de datos de 64 bits. La versión 1 fue diseñada solo con contadores de 32 bits, que pueden almacenar valores enteros de cero a 4.29 mil millones (precisamente4 294 967 295 ). Un contador de 32 bits versión 1 no puede almacenar la velocidad máxima de una interfaz de 10 gigabits o superior, expresada en bits por segundo. De manera similar, un contador de 32 bits que registra estadísticas para una interfaz de 10 gigabits o superior puede volver a cero en menos de un minuto, lo que puede ser un intervalo de tiempo más corto que el de consulta del contador para leer su estado actual. Esto provocaría la pérdida o invalidez de datos debido al reinicio no detectado del valor y la corrupción de los datos de seguimiento de tendencias.

El contador de 64 bits versión 2 puede almacenar valores desde cero hasta 18,4 quintillones (precisamente 18.446.744.073.709.551.615), por lo que actualmente es improbable que se produzca un desbordamiento del 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 desbordarse durante 133 días.

Interoperabilidad entre SNMPv1 y SNMPv2c

SNMPv2c es incompatible con SNMPv1 en dos aspectos clave: formatos de mensajes y operaciones de protocolo. Los mensajes SNMPv2c utilizan un encabezado y un formato de unidad de datos de protocolo (PDU) diferentes a los de los mensajes SNMPv1. Además, SNMPv2c emplea dos operaciones de protocolo que no están especificadas en SNMPv1. Para superar esta incompatibilidad, el RFC 3584 define dos estrategias de coexistencia entre SNMPv1 y SNMPv2c: agentes proxy y sistemas de gestión de red bilingües. 

Agentes proxy

Un agente SNMPv2 puede actuar como agente proxy en nombre de dispositivos gestionados 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. GetBulkLos mensajes son convertidos por el agente proxy a GetNextmensajes y luego reenviados al agente SNMPv1. Además, el agente proxy recibe y asigna mensajes de trampa SNMPv1 a mensajes de trampa SNMPv2 y luego los reenvía al NMS.

Sistema de gestión de red bilingüe

Los sistemas de gestión de red bilingües SNMPv2 admiten tanto SNMPv1 como SNMPv2. Para dar soporte a este entorno de gestión dual, una aplicación de gestión examina la información almacenada en una base de datos local para determinar si el agente admite SNMPv1 o SNMPv2. En función de la información de la base de datos, el sistema de gestión de red se comunica con el agente utilizando la versión de SNMP adecuada.

Versión 3

Aunque SNMPv3 no introduce cambios en el protocolo, salvo la adición de seguridad criptográfica, su apariencia difiere notablemente debido a las nuevas convenciones textuales, conceptos y terminología. [ 1 ] El cambio más visible fue la definición de una versión segura de SNMP, mediante la incorporación de mejoras de seguridad y configuración remota. [ 19 ] La seguridad se aborda ofreciendo autenticación robusta y cifrado de datos para proteger la privacidad. En cuanto a la administración, SNMPv3 se centra en dos partes: los originadores de notificaciones y los reenviadores proxy. Estos cambios también facilitan la configuración y administración remota de las entidades SNMP, además de abordar cuestiones relacionadas con el despliegue a gran escala, la contabilidad y la gestión de fallos.

Las características y mejoras incluidas fueron:

  • Identificación de entidades SNMP para facilitar la comunicación únicamente 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 usuarios (USM).
  • Definición de 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 la alteración de mensajes en tránsito generados por una entidad principal autorizada por parte de alguna entidad SNMP no autorizada.
    • Suplantación de identidad: protección contra intentos de realizar operaciones de gestión no autorizadas para un mandante, asumiendo la identidad de otro mandante que sí cuenta con las autorizaciones adecuadas.
    • Modificación del flujo de mensajes: protección contra la reordenación, el retraso o la reproducción maliciosa de mensajes para afectar operaciones de gestión no autorizadas.
    • Divulgación: protección contra la interceptación de comunicaciones entre motores SNMP.
  • Especificación para USM – USM consiste en la definición general de los siguientes mecanismos de comunicación disponibles:
    • Comunicación sin autenticación ni 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 [ 20 ] y los protocolos de privacidad CBC_DES y CFB_AES_128 son compatibles con USM.
  • Definición de un procedimiento de descubrimiento: 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 de la MIB del marco SNMP: para facilitar la configuración y administración remota 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 remota del módulo de control de acceso.

La seguridad fue una de las mayores debilidades de SNMP hasta la versión 3. La autenticación en las versiones 1 y 2 de SNMP no es más que una contraseña (cadena de comunidad) enviada en texto plano entre un administrador y un agente. [ 1 ] 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. [ 21 ] El enfoque de seguridad en la versión 3 apunta a: [ 22 ]

  • Confidencialidad: cifrado de paquetes para evitar el espionaje por parte de una fuente no autorizada.
  • Integridad: Integridad del mensaje para garantizar que un paquete no haya sido manipulado durante su tránsito, incluyendo un mecanismo opcional de protección contra la repetición de paquetes.
  • Autenticación : para verificar que el mensaje proviene de una fuente válida.

La versión v3 también define el USM y el VACM, a los que posteriormente siguió un modelo de seguridad de transporte (TSM) que proporcionaba soporte para SNMPv3 sobre SSH y SNMPv3 sobre TLS y DTLS.

  • El modelo 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 vistas) determina si una entidad principal determinada tiene permitido el acceso a un objeto MIB específico para realizar funciones concretas y opera a nivel de PDU.
  • TSM (Transport Security Model) proporciona un método para autenticar y cifrar mensajes a través de canales de seguridad externos. Se han definido dos protocolos de transporte, SSH y TLS/DTLS, que utilizan la especificación TSM.

A partir de 2004El IETF reconoce el Protocolo Simple de Administración de Red versión 3, tal como se define en los RFC 3411 a 3418 [ 23 ] (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 [ 24 ] , el nivel de madurez más alto para un RFC. Considera que las versiones anteriores están obsoletas (designándolas indistintamente como Históricas u Obsoletas ) [ 16 ] .  

Problemas de implementación

Muchos proveedores no están aprovechando al máximo 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 mediante cambios individuales en los objetos MIB.

Algunos valores 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 consistentes 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, al obtener métricas de utilización del disco, donde un identificador de disco específico es diferente entre plataformas). [ 25 ]

Algunos de los principales proveedores de equipos tienden a extender en exceso sus sistemas de configuración y control centrados en la interfaz de línea de comandos (CLI) propietaria. [ 26 ]

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 de Carnegie Mellon (CM-SEI) emitió un Aviso sobre SNMPv1, [ 27 ] después 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, utilizan el mismo código de programa para decodificar las unidades de datos de protocolo (PDU), y se identificaron problemas en este código. También se encontraron problemas con la decodificación de los mensajes de trampa SNMP recibidos por la estación de administración SNMP o las solicitudes recibidas por el agente SNMP en el dispositivo de red. Muchos proveedores tuvieron que emitir parches para sus implementaciones de SNMP. [ 9 ] : 1875

Implicaciones de seguridad

Utilizar SNMP para atacar una red

Dado que SNMP está diseñado para permitir a los administradores supervisar y configurar dispositivos de red de forma remota, también puede utilizarse para penetrar en una red. Un número considerable de herramientas de software pueden escanear toda la red mediante SNMP; por lo tanto, los errores en la configuración del modo de lectura/escritura pueden hacer que una red sea vulnerable a ataques. [ 28 ] : 52

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. [ 29 ]

Si SNMP no se utiliza en una red, debe deshabilitarse en los dispositivos de red. Al configurar el modo de solo lectura de SNMP, se debe prestar especial atención a la configuración del control de acceso y a las direcciones IP desde las que se aceptan los mensajes SNMP. Si los servidores SNMP se identifican por sus direcciones IP, SNMP solo podrá responder a estas IP y se denegarán los mensajes SNMP provenientes de otras direcciones IP. Sin embargo, la suplantación de direcciones IP sigue siendo un problema de seguridad. [ 28 ] : 54

Autenticación

SNMP está disponible en diferentes versiones, y cada una presenta sus propios problemas de seguridad. SNMP v1 envía contraseñas en texto plano a través de la red, lo que permite su lectura mediante la interceptación de paquetes . SNMP v2 permite el hash de contraseñas con MD5 , pero requiere configuración. Prácticamente todo el software de gestión de red es compatible con SNMP v1, pero no necesariamente con SNMP v2 o v3. SNMP v2 se desarrolló específicamente para garantizar la seguridad de los datos , es decir, la autenticación , la privacidad y la autorización . Sin embargo, solo la versión 2c obtuvo la aprobación del Grupo de Trabajo de Ingeniería de Internet (IETF), mientras que las versiones 2u y 2* no la consiguieron debido a problemas de seguridad. SNMP v3 utiliza MD5, el Algoritmo de Hash Seguro (SHA) y algoritmos con clave para ofrecer protección contra la modificación no autorizada de datos y los ataques de suplantación de identidad . Si se requiere un mayor nivel de seguridad, se puede utilizar opcionalmente el Estándar de Cifrado de Datos (DES) en el modo de encadenamiento de bloques de cifrado . SNMP v3 está implementado en Cisco IOS desde la versión 12.0(3)T. [ 28 ] : 52

SNMPv3 puede ser vulnerable a ataques de fuerza bruta y de diccionario para adivinar las claves de autenticación o de cifrado, si estas se generan a partir de contraseñas cortas (débiles) o que se encuentran en un diccionario. SNMPv3 permite tanto proporcionar claves criptográficas aleatorias distribuidas uniformemente como generarlas a partir de una contraseña proporcionada por el usuario. El riesgo de adivinar las cadenas de autenticación a partir de los valores hash transmitidos por la red depende de la función hash criptográfica utilizada y de 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). [ 30 ] SNMP no utiliza un protocolo de autenticación de desafío-respuesta más seguro . SNMPv3 (al igual que otras versiones del protocolo SNMP) es un protocolo sin estado y se ha diseñado con una cantidad mínima de interacciones entre el agente y el gestor. Por lo tanto, introducir un protocolo de desafío-respuesta para cada comando impondría una carga al agente (y posiblemente a 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 IPsec . SNMP también puede transmitirse de forma segura a través de Datagram Transport Layer Security (DTLS). [ 11 ]

Muchas implementaciones de SNMP incluyen un tipo de descubrimiento automático donde un nuevo componente de red, como un conmutador o enrutador, se descubre y se consulta automáticamente. En SNMPv1 y SNMPv2c, esto se hace a través de una cadena de comunidad que se transmite en texto plano a otros dispositivos. [ 11 ] Las contraseñas en texto plano representan un riesgo de seguridad significativo. Una vez que la cadena de comunidad se conoce fuera de la organización, podría convertirse en objetivo de un ataque. Para alertar a los administradores sobre otros intentos de obtener cadenas de comunidad, SNMP se puede configurar para que envíe trampas de fallo de autenticación de nombre de comunidad. [ 28 ] : 54 Si se utiliza SNMPv2, el problema se puede evitar habilitando el cifrado de contraseñas en los agentes SNMP de los dispositivos de red.

La configuración predeterminada común para las cadenas de comunidad es "public" para acceso de solo lectura y "private" para lectura y escritura. [ 9 ] : 1874 Debido a las configuraciones predeterminadas bien conocidas, 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. [ 31 ] Los administradores de sistemas y redes con frecuencia no cambian estas configuraciones. [ 9 ] : 1874

Tanto si se ejecuta sobre TCP como sobre UDP, SNMPv1 y v2 son vulnerables a ataques de suplantación de IP . Mediante la suplantación, los atacantes pueden eludir las listas de acceso de dispositivos en los agentes implementados para restringir el acceso SNMP. Los mecanismos de seguridad de SNMPv3, como USM o TSM, pueden prevenir estos ataques.

Véase también

Referencias

  1. 1 2 3 Douglas R. Mauro y Kevin J. Schmidt. (2001). Essential SNMP (1.ª ed.). Sebastopol, CA: O'Reilly & Associates. 
  2. ↑ Una arquitectura para describir marcos de gestión del protocolo simple de gestión de red (SNMP) . IETF . doi : 10.17487/RFC3411 . RFC 3411 .
  3. ↑ RFC 6353 Sección 10 
  4. ↑ Mark Fedor; Martin Schoffstall; James R. Davin; Dr. Jeff D. Case (mayo de 1990). Un protocolo simple de administración de red (SNMP) . Grupo de trabajo de redes. doi : 10.17487/RFC1157 . RFC 1157 .Histórico. pág. 26. Deja obsoleto el RFC 1098. Cada asignación de variable especificada por la PDU SetRequest debe efectuarse como si se estableciera simultáneamente con respecto a todas las demás asignaciones especificadas en el mismo mensaje. 
  5. ↑ J. Case; K. McCloghrie; M. Rose; S. Waldbusser (abril de 1993). "RFC 1448 – Operaciones de protocolo para la versión 2 del Protocolo simple de administración de red (SNMPv2)" . Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC1448 . Se genera y transmite una PDU InformRequest a petición de una aplicación en una entidad SNMPv2 que actúa como administrador, que desea notificar a otra aplicación (en una entidad SNMPv2 que también actúa como administrador) información en la vista MIB de una parte local a la aplicación remitente.
  6. ↑ D. Levi; P. Meyer; B. Stewart (abril de 1999). "RFC 2573 – Aplicaciones SNMP" . Grupo de Trabajo de Ingeniería de Internet. doi : 10.17487/RFC2573 .
  7. 1 2 "Solicitudes de información SNMP" . Cisco . Consultado el 09/12/2011 .
  8. ↑ "Comprensión de la implementación de SNMP en el software JUNOS" . Juniper Networks . Consultado el 11 de febrero de 2013 .
  9. 1 2 3 4 5 Harold F. Tipton; Micki Krause (2007). Manual de gestión de la seguridad de la información, sexta edición . CRC Press. ISBN 9780849374951.
  10. ↑ Douglas Mauro; Kevin Schmidt (2005). Manual de gestión de seguridad de la información, sexta edición. SNMP esencial: ayuda para administradores de sistemas y redes . O'Reilly Media, Inc. págs. 21-22 . ISBN  9780596552770.
  11. 1 2 3 Stuart Jacobs (2015). Ingeniería de la seguridad de la información: La aplicación de conceptos de ingeniería de sistemas para lograr la garantía de la información . John Wiley & Sons. pág. 367. ISBN  9781119104797.
  12. ↑ RFC 3584 "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" 
  13. ↑ Wiley, John (1 de diciembre de 2015). Ingeniería de la seguridad de la información: La aplicación de conceptos de ingeniería de sistemas para lograr la garantía de la información . John Wiley & Sons. pág. 366. ISBN  9781119104711. Consultado el 14 de septiembre de 2017 .
  14. 1 2 "Seguridad en SNMPv3 frente a SNMPv1 o v2c" (PDF) . Archivado del original (PDF) el 29 de abril de 2013.
  15. ↑ RFC 1157 
  16. 1 2 3 "Detalle de búsqueda de RFC: RFC de snmpv2 de la pista de estándares" . El editor de RFC . Recuperado el 24 de febrero de 2014 .
  17. ↑ RFC 3416 
  18. ↑ SNMPv3 -- Modelo de seguridad de usuario , Dr. Dobbs , consultado el 9 de marzo de 2019
  19. ↑ En este número: SNMP versión 3 Archivado el 27/07/2017 en Wayback Machine The Simple Times ISSN 1060-6084 
  20. ↑ RFC 7860
  21. ↑ David Zeltserman (1999). Guía práctica de SNMPv3 y administración de redes . Upper Saddle River, NJ: Prentice Hall PTR.
  22. ↑ "SNMPv3" . Cisco Systems. Archivado del original el 19 de julio de 2011.
  23. ↑ "SNMP Versión 3" . Instituto de Sistemas Operativos y Redes Informáticas . Consultado el 7 de mayo de 2010 .
  24. ↑ Editor de RFC Archivado el 29/10/2007 en la Wayback Machine Lista de estándares de Internet (STD) actuales
  25. ↑ "Comprensión de los valores de índice de tabla en SNMP" .
  26. ↑ "Presentaciones de SNMP Research a favor de la gestión basada en estándares sobre las CLI propietarias" . SNMP Research . Consultado el 12 de octubre de 2010 .
  27. ↑ Aviso CERT CA-2002-03 Múltiples vulnerabilidades en numerosas implementaciones
  28. 1 2 3 4 Andrew G. Mason; Mark J. Newcomb (2001). Soluciones de seguridad de Internet seguras de Cisco . Cisco Press. ISBN 9781587050169.
  29. ↑ Andrew G. Mason; Mark J. Newcomb (2001). Soluciones de seguridad de Internet de Cisco Secure . Cisco Press. pp. 52. ISBN  9781587050169.
  30. ↑ Protocolos de autenticación HMAC-SHA-2 en el modelo de seguridad basado en el usuario (USM) para SNMPv3 . IETF . RFC 7630 . 
  31. ↑ "Instituto SANS - Controles Críticos de Seguridad CIS" .

Lecturas adicionales

  • Douglas Mauro; Kevin Schmidt (2005). Essential SNMP (Segunda  edición). O'Reilly Media. ISBN 978-0596008406.
  • William Stallings (1999). SNMP, SNMPv2, SNMPv3 y RMON 1 y 2. Addison Wesley Longman, Inc. ISBN 978-0201485349.
  • Marshall T. Rose (1996). El libro sencillo . Prentice Hall. ISBN 0-13-451659-1.
  • RFC 1155 (STD 16) — Estructura e identificación de la información de gestión para las redes de Internet basadas en TCP/IP  
  • RFC 1156 (Histórico) — Base de información de gestió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 administración de redes basadas en TCP/IP: MIB-II  
  • RFC 1452 (Informativo) — Coexistencia entre la versión 1 y la versión 2 del marco de gestió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 estándar) — Estructura de la información de gestión para SNMPv2 (Obsoleto por RFC 2578 )   
  • RFC 1908 (Vía de estándares) — 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 gestió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 de estándares de Internet  
  • La norma STD 62 contiene los siguientes RFC:
    • RFC 3411 — Una arquitectura para describir los marcos de administración del Protocolo simple de administración de red (SNMP)  
    • RFC 3412 — Procesamiento y envío de mensajes para el Protocolo simple de administración de red (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 red (SNMPv3)  
    • RFC 3415 — Modelo de control de acceso basado en vistas (VACM) para el protocolo simple de administración de red (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 red (SNMP)  
    • RFC 3418 — Base de información de gestión (MIB) para el protocolo simple de gestión de red (SNMP)  
  • RFC 3430 (Experimental) — Mapeo de transporte del Protocolo simple de administración de red (SNMP) sobre el 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 (Propuesta) — El algoritmo de cifrado del Estándar de Cifrado Avanzado (AES) en el modelo de seguridad basado en usuarios de SNMP  
  • RFC 4789 (Propuesta) — Protocolo simple de administración de red (SNMP) sobre redes IEEE 802  
  • RFC 5343 (STD 78) — Protocolo simple de administración de red (SNMP) Descubrimiento de EngineID de contexto  
  • 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 red (SNMP)  
  • RFC 5592 (Propuesta) — Modelo de transporte Secure Shell para el Protocolo simple de administración de red (SNMP)  
  • RFC 5608 (Propuesta) — Uso del Servicio de autenticación remota de usuarios por marcación (RADIUS) para modelos de transporte del Protocolo simple de administración de red (SNMP).  
  • RFC 6353 (STD 78) — Modelo de transporte de seguridad de la capa de transporte (TLS) para el protocolo simple de administración de red (SNMP)  
  • RFC 7630 (Propuesta|Histórica) — Protocolos de autenticación HMAC-SHA-2 en el modelo de seguridad basado en el usuario (USM) para SNMPv3  
  • RFC 7860 (Propuesta) — Protocolos de autenticación HMAC-SHA-2 en el modelo de seguridad basado en el usuario (USM) para SNMPv3