PROTOCOLO DEL SNMP

1 – Introducción al protocolo SNMP

Para introducir el protocolo SNMP, es importante recordar que la informática está cada vez más presente en nuestra vida cotidiana. Ahora dependemos de los servicios que ofrecen las redes para el funcionamiento de nuestras herramientas informáticas, ya sea en las empresas, durante las transacciones bancarias, las teleconferencias, etc. Los servicios ofrecidos se han vuelto casi indispensables. Para garantizar que estos servicios sean adecuados, es necesario vigilar la red y actuar cuando se produzca un error.

En las redes físicas, es necesario vigilar muchos componentes: el uso del ancho de banda, el estado de funcionamiento de los enlaces, los posibles cuellos de botella, los problemas de cableado, el flujo adecuado de información entre las máquinas, etc. La red también debe ser vigilada para garantizar su correcto funcionamiento. Para ello se deben observar varios puntos estratégicos, como los enrutadores, los concentradores, los enlaces, las estaciones, las impresoras.

Así pues, en caso de fallo o mal funcionamiento de la red, el administrador debe ser capaz de interpretar la información recibida para identificar la fuente del problema. Se requiere un protocolo de gestión para realizar funciones de gestión en una red. Debe ser capaz de dialogar con todos los elementos de la red.

2 – Protocolo SNMP

2.1 – Presentación general

SNMP (Simple Network Management Protocol) es el protocolo de gestión de red propuesto por el IETF. Actualmente es el protocolo más utilizado para la gestión del equipo de red.

El SNMP es un protocolo relativamente simple. Sin embargo, todas sus funcionalidades son lo suficientemente potentes como para permitir la gestión de redes complejas y heterogéneas. También se utiliza para la gestión a distancia de aplicaciones: bases de datos, servidores, programas informáticos, etc. Es el protocolo más utilizado para la gestión de equipos de red.

El entorno de gestión del SNMP consta de varios componentes: la estación de vigilancia, los elementos activos de la red, las variables MIB y un protocolo. Los diferentes componentes del protocolo SNMP son los siguientes:

Los elementos activos de la red son el equipo o el software que queremos gestionar. Esto va desde una estación de trabajo hasta un hub, un router, un puente, etc. Los elementos activos de la red son el equipo o el software que se quiere gestionar. Cada elemento de la red tiene una entidad llamada agente que responde a las solicitudes de la estación de vigilancia. Los agentes son módulos que residen en elementos de la red. Buscan información de gestión como el número de paquetes recibidos o transmitidos.

  • La estación de supervisión (también llamada manager) ejecuta las aplicaciones de gestión que controlan los elementos de la red. Físicamente, la estación es una estación de trabajo.
  • La MIB (Base de Información de Gestión) es una colección de objetos que residen en una base de información virtual. Estas colecciones de objetos se definen en módulos específicos del MIB.
  • El protocolo, que permite a la estación de supervisión obtener información sobre los elementos de la red y recibir alertas de estos mismos elementos.

2.2 – Operación

El protocolo SNMP se basa en el funcionamiento asimétrico. Consiste en un conjunto de solicitudes, respuestas y un número limitado de alertas. El gerente envía solicitudes al agente, que devuelve las respuestas. Cuando ocurre un evento anormal en el elemento de la red, el agente envía una alerta (trampa) al administrador.

El SNMP utiliza el protocolo UDP [RFC 768]. El puerto 161 es utilizado por el agente para recibir solicitudes de la estación de gestión. El puerto 162 está reservado para que la estación gestora reciba las alertas de los agentes.

protocolo snmp

Consultas SNMP

Hay cuatro tipos de consultas: GetRequest, GetNextRequest, GetBulk, SetRequest.

  • La consulta GetRequest permite buscar una variable en un agente.
  • La consulta GetNextRequest permite buscar la siguiente variable.
  • La consulta GetBulk permite la búsqueda de un conjunto de variables agrupadas.
  • La consulta SetRequest permite cambiar el valor de una variable en un agente.

Las respuestas del SNMP

Siguiendo las solicitudes, el agente siempre responde por medio de GetResponse. Sin embargo, si la variable solicitada no está disponible, la Respuesta de Obtención se acompañará de un error de noSuchObject.

Alertas (trampas, notificaciones)

Se envían alertas cuando ocurre un evento inesperado en el agente. El agente informa a la estación de supervisión a través de una trampa. Las posibles alertas son: ColdStart, WarmStart, LinkDown, LinkUp, AuthenticationFailure.

2.3 – MIBS

La MIB (Management Information base) es la base de datos de información de gestión mantenida por el agente, a la que el gestor acudirá en busca de información.

Se han estandarizado dos MIB públicos: MIB I y MIB II (conocidos como 1 y 2). Un archivo MIB es un documento de texto escrito en lenguaje ASN.1 (Abstract Syntax Notation 1) que describe las variables, tablas y alarmas gestionadas dentro de un MIB.

La MIB es una estructura de árbol en la que cada nodo está definido por un número o OID (Object Identifier). Contiene una parte común a todos los agentes SNMP en general, una parte común a todos los agentes SNMP del mismo tipo de hardware y una parte específica de cada fabricante. Cada equipo a supervisar tiene su propio MIB. No sólo se ha estandarizado la estructura, sino también los nombres de los distintos encabezamientos.

Estas designaciones sólo están presentes para facilitar la lectura. En realidad, cada nivel de la jerarquía está identificado por un índice numérico y el SNMP utiliza sólo este índice para acceder a él.

Aquí hay un ejemplo de una estructura de tabla MIB:

Por lo tanto, para consultar las diferentes variables de actividad de un dispositivo, tendrás que explorar su árbol MIB. Esto es generalmente proporcionado por el fabricante, pero también es posible utilizar un explorador MIB como el «Getif MIB Browser».

Luego, para acceder a las variables deseadas, se utilizará el OID (Object Identification), que designa la ubicación de la variable a consultar en el MIB. Por ejemplo, en un conmutador Nortel Passport, el OID .1.3.6.1.4.1.2272.1.1.20 es la tasa de carga de la CPU.

Cuando una empresa quiera definir su propio conjunto de variables de gestión, registrará su número de objeto en el nodo iso.org.dod.internet.private.enterprise. Estos MIBs se llamarán privados. Corresponden a la raíz 1.3.6.1.4.1. Aquí está la lista de todas las asignaciones oficiales:

  • snmp enterprise id number 0 4998
  • número de identificación de negocios del snmp 5000 9999
  • número de identificación de negocio snmp 10000 14999
  • número de identificación de la compañía snmp 14999 19999
  • snmp business id número 20000 24999
  • snmp business id número 25000 27274

3 – Presentación, evolución de las versiones del SNMP

Aquí están las diferentes versiones de SNMP:

  • SNMPv1 (estándar antiguo): Esta es la primera versión del protocolo, como se define en el RFC 1157… Se dice que la seguridad de esta versión es trivial, porque la única verificación que se hace se basa en la cadena de «comunidad». Cadena SNMPsec (historia): Esta versión añade seguridad al protocolo SNMPv1. La seguridad se basa en grupos. Muy pocos o ningún fabricante ha usado esta versión que ahora está en gran parte olvidada.
  • RFC 1155
  • SNMPv2p (historia): Se ha hecho mucho trabajo para actualizar el SNMPv1, no sólo en lo que respecta a la seguridad. El resultado es una actualización de las operaciones del protocolo, nuevas operaciones, nuevos tipos de datos. La seguridad se basa en grupos SNMPsec.
  • SNMPv2c (experimental): Esta versión del protocolo se llama «SNMPv2 basado en cadenas comunitarias». Se trata de una mejora de las operaciones de protocolo y de los tipos de operación de SNMPv2p y utiliza la seguridad basada en cadenas de la «comunidad» de SNMPv1.
  • RFC – 1441
  • SNMPv2u (experimental): Esta versión del protocolo utiliza operaciones SNMPv2c, tipos de datos y seguridad basada en el usuario.
  • SNMPv2* (experimental): Esta versión combina lo mejor de SNMPv2p y SNMPv2u. Los documentos que describen esta versión nunca han sido publicados en 12 RFCs. Se pueden encontrar copias de estos documentos en el sitio web y en el SNMP Research (uno de los primeros en defender esta versión).
  • RFC – 1901
  • SNMPv3 (estándar actual): Esta versión incluye una combinación de seguridad basada en el usuario y tipos y operaciones de SNMPv2p, con la capacidad añadida de «proxies». La seguridad se basa en lo que hay en SNMPv2u y SNMPv2*.
  • RFC – 3411

4 – SNMPv1 y v2

La trama SNMPv1 está completamente codificada en ASN.1 [ISO 87]. Las solicitudes y las respuestas tienen el mismo formato

  • La versión más utilizada sigue siendo la versión 1. En los documentos de trabajo se han propuesto varias versiones 2, pero lamentablemente ninguna de ellas ha sido adoptada como estándar. La versión 3 está actualmente en proceso de adopción. Se coloca un valor de cero en el campo de versión para SNMPv1, y un valor de 3 para SNMPv3.
  • La comunidad permite la creación de dominios de administración. La comunidad está descrita por una cadena. Por defecto, la comunidad es «PÚBLICA».
  • La PDU (Unidad de Datos de Paquetes).

El «TYPE PDU» describe el tipo de consulta, respuesta o alerta. La tabla 2 muestra los valores asociados a estos campos.

  • PDU=0 : Get-request
  • PDU=1 : Get next-request
  • PDU=2 : Get response
  • PDU=3 : Set request
  • PDU=4 : Trap

El «Request ID» permite a la estación gestora asociar las respuestas a sus solicitudes.
El «Estado de error» es el indicador del tipo de error. Si no se ha producido ningún error, este campo se pone a cero. Las posibles respuestas negativas se describen en el siguiente cuadro:

  • Response=NoAcceso: Acceso no permitido
  • Respuesta=Longitud Equivocada: Error de longitud
  • Respuesta=ValorIncorrecto: Valor incorrecto
  • Respuesta=TipoMalo: Tipo Malo
  • Respuesta=Equivocación: Error de codificación
  • Respuesta=NoCreación: Objeto no creado
  • Respuesta=Solo lectura: No se permite escribir
  • Respuesta=NoEscribible: No se permite escribir
  • Answer=AuthrisationError: Error de autorización

4.1 – Debilidades del SNMPv1

Una de las mayores debilidades del protocolo SNMPv1 es la falta de un mecanismo adecuado para garantizar la confidencialidad y la seguridad de las funciones de gestión. Entre las debilidades también figuran la autenticación y el cifrado, además de la falta de un marco administrativo para la autorización y el control del acceso. Este problema hace que la seguridad en SNMPv1 sea del tipo «SHOW-AND-TELNET», es decir, SNMP se utiliza para la adquisición de datos de gestión pero no para el control mediante el protocolo Telnet.

El grupo de trabajo de la IETF que trabajó en SNMPv2 quería incluir la seguridad en la nueva versión. Lamentablemente, este grupo no pudo llegar a un consenso sobre el funcionamiento del mecanismo de seguridad. Sobre esta base se elaboraron dos propuestas (SNMPv2u y SNMPv2*). La mayoría de los expertos coinciden en que no pueden coexistir dos normas SNMP, y que no es una solución a largo plazo.

Se reunió todo el consenso del grupo de trabajo (sólo las mejoras no relacionadas con la seguridad), y el grupo de trabajo del IETF sobre SNMPv2 completó su labor con la publicación de una versión de SNMPv2 (llamada SNMPv2c, RFC 1901, RFC 1905 y RFC 1906) sin seguridad.

4.2 – Mejoras en el SNMPv2c

SNMPv2c ha introducido algunos tipos nuevos, pero su mayor novedad es la operación GETBULK, que permite a una plataforma de gestión solicitar varias variables consecutivas en el MIB del agente. Normalmente, se solicitan tantas variables como se puedan poner en un paquete SNMP. Esto resuelve un importante problema de rendimiento en SNMPv1: con la versión 1, la plataforma tiene que hacer un GETNEXT y esperar la respuesta para cada variable de gestión.

5 – SNMP v3

Esta nueva versión del protocolo SNMP tiene por objeto esencialmente incluir la seguridad de las transacciones. La seguridad incluye identificar a las partes que se comunican y asegurar que la conversación es privada, incluso si se realiza a través de una red pública.

Esta seguridad se basa en 2 conceptos:

  • USM (Modelo de Seguridad basado en el Usuario)
  • VACM (Modelo de Control de Acceso basado en la vista)

5.1 – Módulo de Seguridad del Usuario (USM)

Se utilizan tres mecanismos. Cada uno de estos mecanismos está diseñado para prevenir un tipo de ataque.

  • Autenticación: Evita que alguien cambie el paquete SNMPv3 en el camino y valide la contraseña de la persona que transmite la solicitud.
  • Cifrado: Evita que nadie lea la información de gestión contenida en un paquete SNMPv3.
  • Sellado de tiempo: Evita la reutilización de un paquete SNMPv3 válido que ya ha sido transmitido por otra persona.

5.1.1 – Autenticación

La función de la autenticación es asegurar que el paquete permanezca sin cambios durante la transmisión y que la contraseña sea válida para el usuario solicitante.

Para construir este mecanismo, uno debe ser consciente de las funciones de hachís unidireccionales. Ejemplos de estas funciones son : MD5 y SHA-1. Estas funciones toman como entrada una cadena de caracteres de longitud indefinida, y generan como salida una cadena de bytes de longitud finita (16 bytes para MD5, 20 bytes para SHA-1).

Para autentificar la información que se transmitirá, también hay que tener una contraseña que sea «compartida». Por lo tanto, la contraseña sólo debe ser conocida por las dos entidades que se envían los mensajes entre sí, y preferiblemente por nadie más.

En la figura siguiente se muestra el mecanismo de autenticación:

Los pasos de autenticación son los siguientes:

  • El transmisor agrupa la información a transmitir con la contraseña
  • Este grupo pasa a la función de hachís de un solo sentido.
  • Los datos y el código hash se transmiten a través de la red.
  • El receptor toma el bloque de datos y le añade la contraseña.
  • Este grupo pasa a la función de hachís unidireccional.
  • Si el código hash es idéntico al código hash transmitido, el transmisor se autentica.

Con esta técnica, la contraseña se valida sin que se haya transmitido por la red. Alguien que introduce los paquetes SNMPv3 que pasan por la red no puede encontrar fácilmente la contraseña.

En el caso de SNMPv3, la autenticación se realiza mediante HMAC-MD5-96 o HMAC-SHA-96, lo que es un poco más complicado de lo que se describe aquí. El resultado de la función hash se coloca en el bloque de parámetros de seguridad del paquete SNMPv3.

La autentificación se hace en todo el paquete.

El paso de autenticación no tiene por objeto ocultar la existencia del paquete o el cifrado. Si sólo se utiliza la autenticación, las personas que capturan los paquetes que pasan por la red pueden seguir viendo el contenido del paquete. Sin embargo, no pueden cambiar el contenido sin conocer la contraseña.

5.1.2 – Cifrado

El propósito del cifrado es impedir que alguien obtenga información de gestión escuchando en la red las solicitudes y respuestas de otra persona.

Con SNMPv3, la encriptación básica se hace con una contraseña «compartida» entre el gerente y el agente. Esta contraseña no debe ser conocida por nadie más. Por razones de seguridad, SNMPv3 utiliza dos contraseñas: una para la autenticación y otra para la encriptación. Esto permite que el sistema de autenticación y el sistema de cifrado sean independientes. Un sistema no puede comprometer al otro.

El SNMPv3 se basa en el DES (Data Encryption Standard) para realizar la encriptación.

Se utiliza una clave de 64 bits (8 de los 64 bits son paridades, por lo que la clave real tiene una longitud de 56 bits) y el cifrado DES de 64 bits al mismo tiempo. Dado que la información a cifrar es más larga de 8 bytes, se utiliza el encadenamiento de bloques DES de 64 bits.

Una combinación de la contraseña, una cadena aleatoria y otra información forma el «Vector de Inicialización». Cada uno de los bloques de 64 bits pasa por el DES y se encadena con el bloque anterior con un XOR. El primer bloque está encadenado por un XOR al vector de inicialización. El vector de inicialización se transmite con cada paquete en los «Ajustes de seguridad», un campo que forma parte del paquete SNMPv3.

A diferencia de la autenticación, que se aplica a todo el paquete, la encriptación sólo se aplica a la PDU.

En la RFC 3826 «El algoritmo de cifrado del Estándar de Cifrado Avanzado (AES) en el modelo de seguridad basado en el usuario del SNMP» se describe la integración del AES en el SNMP. Esto refuerza la encriptación como reemplazo del DES. Sin embargo, por el momento, esta RFC está en proceso de validación y por lo tanto aún no se ha oficializado.

5.1.3 – Sello de tiempo

Si se transmite una solicitud, los mecanismos de autenticación y cifrado no impiden que alguien capture un paquete SNMPv3 válido de la red e intente reutilizarlo más tarde sin modificaciones.

Por ejemplo, si el administrador está realizando la operación de actualización de un equipo, alguien puede capturar este paquete e intentar retransmitirlo al equipo cada vez que esa persona desee realizar una actualización ilegal del mismo. Incluso si la persona no tiene la autorización necesaria, envía un paquete, autenticado y cifrado correctamente para la administración del equipo.

Este tipo de ataque se llama «Ataque de Repetición». Para prevenir esto, la hora está estampada en cada paquete. Cuando se recibe un paquete SNMPv3, la hora actual se compara con la hora del paquete. Si la diferencia es de más de 150 segundos, el paquete es ignorado.

El SNMPv3 no utiliza el tiempo estándar. En su lugar, se utiliza un reloj diferente en cada agente. Estos llevan un registro del número de segundos que han pasado desde que se encendió el agente. También tienen un contador para ver cuántas veces se ha encendido el equipo. Estos contadores se llaman BOOTS (Número de veces que se ha encendido el equipo) y TIME (Número de segundos desde la última vez que se encendió el equipo).

La combinación de BOTAS y TIEMPO da un valor que siempre aumenta, y puede ser usado para estampar. Como cada agente tiene su propio valor de BOTAS/HORA, la plataforma de gestión debe tener un reloj que debe estar sincronizado para cada agente con el que se pone en contacto. En el momento del contacto inicial, la plataforma obtiene el valor de BOTAS/HORA del agente y sincroniza un reloj separado.

5.2 – VACM (Ver modelo de control de acceso)

Permite el control de acceso al MIB. Así, es posible restringir el acceso de lectura y/o escritura para un grupo o por un usuario.

5.3 – El marco SNMPv3

El formato de trama SNMPv3 es muy diferente del formato SNMPv1, pero ambos están codificados en el formato ASN.1 [ISO 87]. Esto asegura la compatibilidad de los tipos de datos entre computadoras de diferentes arquitecturas.

Para facilitar la distinción entre las versiones, el número de versión del SNMP se coloca al principio del paquete. Sin embargo, el contenido de cada campo varía según la situación. Dependiendo de si se envía una solicitud, una respuesta o un mensaje de error, la información colocada en el paquete sigue unas reglas bien definidas en la norma. Así es como se rellenan los campos de un paquete SNMPv3:

  • Versión SNMP: Para SNMPv3, el valor 3 se coloca en este campo. Para un paquete SNMPv1, ponga 0.
  • Identificador del mensaje: Este campo se deja a la discreción del motor SNMP. A menudo se encuentran algoritmos en los que el primer mensaje de solicitud se envía con un número aleatorio y los siguientes con incrementos de 1. Los paquetes que se envían en respuesta a una solicitud llevan la misma identificación que el paquete de solicitud.
  • Tamaño máximo: El motor escoge el tamaño máximo de una respuesta a una solicitud basándose en su capacidad de buffer y sus límites para decodificar paquetes largos. Cuando se envía una respuesta a una solicitud, se debe tener cuidado de no exceder el tamaño máximo.
  • Banderas: Tres bits se utilizan para indicar..:
    • Si se espera una respuesta cuando se reciba este paquete. (Bandera reportable)
    • Si se utilizó un modelo de cifrado (Bandera de Privacidad)
    • Si se utilizó una plantilla de autenticación (Bandera de autenticación)
  • El modelo de seguridad: Este módulo identifica el tipo de seguridad que se utiliza para encriptar el resto del paquete. Este identificador debe identificar de manera única cada módulo de seguridad. Actualmente, el algoritmo de encriptación del Estándar de Cifrado de Datos (DES) y el algoritmo de autenticación HMAC-MD5-96 han sido elegidos como los algoritmos usados en SNMPv3. HMAC-SHA-96 es opcional.
  • Información de seguridad: Esta información no está descrita en el estándar SNMPv3, este bloque se deja a los módulos de seguridad. De un módulo de seguridad a otro, esta información será diferente. El módulo de seguridad DES ha estandarizado el contenido de este bloque.
  • Identificadores de contexto: Con el SNMPv1, era posible tener sólo una base de información (MIB) por agente. Esto no es suficiente para algunos equipos que pueden contener varias veces las mismas variables. Por ejemplo, un interruptor de cajero automático contiene varias tarjetas que tienen cada una su propio MIB. El contexto permite distinguir entre varias bases de información e incluso varios agentes. Distinguimos entre los agentes, por ejemplo, cuando tenemos un motor que actúa como pasarela entre SNMPv3 y SNMPv1, de modo que enviamos un paquete SNMPv3 identificando a qué agente SNMPv1 queremos que se retranscriba el paquete.

6 – Ejemplo de cuadro SNMP

Descargue el marco SNMP de muestra

7 – Conclusión

Cabe destacar la evidente falta de seguridad que sigue existiendo en las primeras versiones del SNMP (v1 y v2). La última versión (v3) del SNMP ha sido desarrollada con esto en mente. Desde 2002, esta versión ha sido decretada como la norma de este protocolo. Sin embargo, la versión 1 sigue siendo muy utilizada y pocas empresas evolucionan cambiando a la última versión.

Categorías Red

Deja un comentario

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Más info

aceptar