Spiga

SNMPv3 - Configuración en Debian 6 Squeeze

¡Hola!

En las entradas anteriores, en las que hemos estudiado el protocolo SNMP, ya hemos hablado de que la gestión de la seguridad en las versiones 1 y 2 era prácticamente nula, ya que se basan en el concepto de comunidad y utilizan una cadena de texto, enviada en texto plano, para su gestión.

SNMPv3 sí ofrece un acceso seguro a los dispositivos, de forma que se puede acceder a los datos sin temor a que se modifiquen por el trayecto y, además, la información confidencial (como un cambio en la configuración de un router) puede ser cifrada para prevenir que su contenido quede expuesto en la red. Con SNMPv3 podemos tener, por tanto, las siguientes funcionalidades:

  • Integridad del mensaje: asegura que un paquete recibido no ha sido modificado.
  • Autenticación: determina que el mensaje proviene de una fuente válida.
  • Cifrado: asegura la confidencialidad del paquete, evitando que pueda ser leído por un usuario no autorizado.
Dentro de SNMPv3, tenemos 3 niveles de seguridad: noAuthnoPriv, authNoPriv y authPriv.


Un ejemplo práctico

Vamos a ver el protocolo en funcionamiento. Para ello usaremos las utilidades net-snmp, que ya vimos en la entrada anterior cómo instalar y configurar en una máquina Debian.

Para configurar el agente snmpd de la máquina Debian, de forma que se pueda usar SNMPv3 para el acceso a la información, tenemos que editar varios ficheros, pero es más sencillo si utilizamos el programa net-snmp-config.

Lo primero que tenemos que hacer es detener el agente para que podamos crear nuestro primer usuario y darle permisos para que pueda realizar consultas o llevar a cabo modificaciones de los objetos.

# /etc/init.d/snmpd stop

Con la siguiente orden creamos el usuario "prueba" con contraseña "asdasd123", utilizando MD5 y DES para la seguridad:
(NOTA: Debes tener openssl instalado)

# net-snmp-config --create-snmpv3-user -a asdasd123 prueba

Por defecto, el programa añade una línea al fichero /etc/snmp/snmpd.conf que concede al usuario creado acceso de lectura y escritura. Editando el fichero podemos cambiar los permisos.

Vamos a iniciar el agente de nuevo para poder probar su funcionamiento:

# /etc/init.d/snmpd start

La siguiente orden solicita al agente localhost el OID 1.3.6.1.2.1.1.4.0, que es sysContact, utilizando el usuario prueba:

$ snmpget -v 3 -u prueba -l authPriv -a MD5 -A asdasd123 -x DES -X asdasd123 localhost 1.3.6.1.2.1.1.4.0

iso.3.6.1.2.1.1.4.0 = STRING: "Chen "

Y esta otra orden solicita sysLocation:

$ snmpget -v 3 -u prueba -l authPriv -a MD5 -A asdasd123 -x DES -X asdasd123 localhost 1.3.6.1.2.1.1.6.0

iso.3.6.1.2.1.1.6.0 = STRING: "Instituto"

En la siguiente imagen podemos ver una captura con wireshark en la que se puede observar cómo, efectivamente, tras realizarse la autenticación, la información viaja cifrada, asegurando su integridad y confidencialidad:



¡Un saludo!

SNMP en Debian 6 Squeeze

¡Hola!

Siguiendo con esta serie de artículos sobre SNMP (Introducción, MIBs y mensajes), hoy vamos a ver cómo configurar un agente SNMP en Debian 6 Squeeze. Para instalar el servicio hay que instalar el paquete snmpd:

#aptitude install snmpd

El fichero de configuración que debemos editar para ajustar el agente a nuestros requisitos es /etc/snmp/snmpd.conf. Sin embargo, la sintaxis del fichero no es muy cómoda y la documentación que se puede encontrar en Internet está dirigida a versiones antiguas del paquete. Tras tirarme un rato trasteando con el fichero, mi compañero Alberto Molina me ha aconsejado que le echara un vistazo al archivo /usr/share/doc/snmpd/README.Debian, que contiene lo siguiente:

The default configuration for snmpd is rather paranoid for security
reasons. Edit /etc/snmp/snmpd.conf or run snmpconf to allow greater
access.

The snmpconf program provides a simple, menu driven way of configuring
the snmp applications and daemons.

La configuración por defecto de snmpd es bastante paranoica por
motivos de seguridad.

Edita el fichero /etc/snmp/snmpd.conf o ejecuta el script snmpconf
para permitir mayor acceso.


EL programa snmpconf ofrce una forma sencilla, basada en menús,
de configurar las aplicaciones
y daemons snmp.

Y la verdad es que la configuración del servicio utilizando snmpconf es mucho más sencilla. Para poder usarlo es necesario instalar el paquete snmp, que contiene varias utilidades:

#aptitude install snmp

Y ya podemos lanzarlo:

#snmpconf

El programa nos va realizando preguntas para ayudarnos a crear el fichero de configuración de acuerdo a nuestras necesidades. La primera pregunta es si queremos reutilizar el contenido de los ficheros de configuración ya existentes. Podemos reutilizar snmp.conf y snmptrapd.conf.


A continuación se nos pregunta por el fichero que queremos crear; en nuestro caso snmpd.conf. Y nos muestra las secciones de las que se compone el fichero para que vayamos configurándolo. Podemos comenzar por la sección de control de acceso:


Si vamos a trabajar con la versión 2 de SNMP (lo más habitual, pero mucho más inseguro que SNMPv3), tendremos que configurar las opciones 3 y/o 4, para crear una comunidad de lectura y otra de lectura y escritura.


Si elegimos la opción 3 nos pedirá el nombre de la comunidad, las direcciones de las máquinas desde las que se pueden realizar peticiones al agente snmpd y los objetos sobre los que se pueden realizar peticiones.


Y las mismas preguntas para la opción 4:


Esta sería una configuración muy básica (y muy insegura), pero que nos vale para comprobar el funcionamiento del protocolo en una máquina Linux. Ya podríamos ir saliendo de los menús para abandonar el programa:


Por último, tendríamos que reiniciar el servicio:

#/etc/init.d/snmpd restart

Podemos comprobar el correcto funcionamiento de nuestro agente con cualquier NMS o MIB Browser, como BlackOwl MIB Browser:


En las próximas entradas seguiremos estudiando el protocolo SNMP, centrándonos en los aspectos relacionados con su seguridad.

¡Un saludo!

Introducción a SNMP III

¡Hola!

En las entradas anteriores hemos realizado una introducción a SNMP, estudiando sus componentes y arquitectura, y hemos profundizado en los MIBs y el árbol de información de gestión. Hoy nos vamos a centrar en los mensajes SNMP.

Para alcanzar el objetivo de ser un protocolo simple, SNMP propuso un conjunto limitado de órdenes y respuestas de gestión. La versión inicial del protocolo tenía tan sólo 5 operadores:

  • Get, para obtener o leer el valor de una o más instancias de un objeto.
  • GetNext, muy similar a Get, se diferencia en que esta operación obtiene el valor del siguiente OID del árbol
  • Set, para escribir o establecer el valor de una o más instancias de un objeto.
  • Trap, que son mensajes enviados por los agentes a los NMS para informar de que se ha producido un cierto evento
  • Response, son las respuestas desde los agentes a los NMS que contienen los valores solicitados.

SNMPv2 introdujo 2 operadores nuevos:

  • GetBulk, se introdujo como una mejora de las peticiones Get Next, cuando hay que obtener datos de una tabla (como la información de las interfaces de red de un equipo o su tabla de encaminamiento).
  • Inform, un mensaje muy similar a trap pero que incluye una confirmación desde el NMS al recibir el mensaje.

GET⁄ GET NEXT⁄ GET BULK⁄ SET


TRAP


INFORM

Para ver el funcionamiento de SNMP en acción y poder realizar algunas capturas con WireShark, necesitamos un NMS y algún dispositivo SNMP. Para ello podéis usar vuestro router casero, un switch o vuestra propia máquina.

Yo voy a utilizar una máquina virtual Windows XP en la que he instalado el servicio SNMP (Inicio->Agregar o quitar programas -> agregar componentes de windows -> herramientas de administración y supervisión -> SNMP). Una vez instalado podemos configurar el agente y definir sus detalles. Por ejemplo, podemos establecer el nombre de contacto, que será la información contenida en el valor del objeto sysContact, o la localización, que será el valor de sysLoc, ambos del grupo System.



Si nos vamos a la pestaña seguridad, vemos que por defecto sólo se crea la comunidad public, que tiene derechos de sólo lectura. Una comunidad (community string) es algo parecido a una contraseña en texto plano (y por tanto muy insegura). En la próxima entrada hablaremos de la seguridad del protocolo y de SNMPv3.

Podemos crear una nueva comunidad con permisos de lectura y escritura:


Una vez realizados los cambios hay que reiniciar el servicio.

Como NMS vamos a usar la aplicación Blackowl MIB browser. En la imagen podéis ver cómo he seleccionado el equipo sobre el que quiero trabajar (escribiendo su IP en el campo Host), he ido navegando por el árbol hasta los objetos del grupo system y he realizado tres operaciones get para obtener el valor de los objetos sysdescr, sysContact y sysLocation. Como la comunidad de las operaciones de lectura está establecido por defecto a public, no hay que configurar nada:


Como podéis ver, los valores que nos devuelve el agente son los que establecimos previamente en el equipo.

Si os fijáis, el objeto sysLocation se puede modificar desde el NMS, ya que su acceso es readwrite. ¡Vamos a cambiarlo! Para ello, tenemos que facilitarle a nuestro NMS los datos de la comunidad de escritura del agente. Tenemos que irnos a las propiedades, seleccionar SNMPv2 y escribir el community string adecuado.




Si realizamos la operación Set sobre el objeto sysLocation, nos salta una nueva ventana solicitando el valor a escribir en el agente:


Si nos vamos al equipo y observamos las propiedades SNMP podemos comprobar que, efectivamente, el valor de SysLocation se ha modificado:


Para terminar os dejo un par de imágenes de la captura realizada con WireShark al realizar la operación get sobre el objeto sysContact y su respuesta desde el agente:



¡OJO! Después de realizar las pruebas, deberías deshabilitar o asegurar SNMP en tus equipos, no vaya a ser que tus equipos comiencen a hacer cosas raras...

En el próximo artículo hablaremos, precisamente, de la seguridad del protocolo y de SNMPv3.

¡Un saludo!


Fuentes:
http://www3.rad.com/networks/applications/snmp/comp.htm
http://www.manageengine.com/network-monitoring/what-is-snmp.html

Introducción a SNMP II

¡Hola!

En este post seguiremos estudiando el protocolo SNMP. Tras realizar una introducción histórica en la entrada anterior y estudiar los componentes y arquitectura del protocolo, hoy nos centraremos en los MIBs.

Ya vimos en el post anterior que cada dispositivo gestionado contiene un agente, que accede a la información del dispositivo físico y la hace accesible (y, en ocasiones, configurable) al NMS. Por ejemplo, un agente podría responder a una petición informando del número de bytes transmitidos por una interfaz. Estas variables que contienen esta información de los dispositivos son conocidas como objetos gestionados. Una colección de objetos gestionados descrita en un documento se llama MIB, por lo que podríamos decir que los ficheros MIB forman el conjunto de consultas que un NMS puede realizar a un agente.

El árbol de información de gestión

Toda la información de gestión está definida de forma que cada objeto gestionado en cualquier módulo MIB, ya sea estándar o privado, tiene un identificador único, llamado identificador del objeto (object identifier, OID). El OID es un string de enteros, separados por puntos, que coloca el objeto en un nodo de un árbol lógico conocido como el árbol de información de gestión. Los enteros representan los nodos en el camino desde la raíz hasta el propio objeto. Cada nodo tiene una etiqueta, que es el entero asociado al propio nodo, y una breve descripción.

Por razones históricas, se mantienen algunos nodos que son irrelevantes para nosotros y que hacen que los object identifiers sean más largos de lo necesario. En la siguiente figura podemos ver parte del árbol.


Los objetos que son de nuestro interés están bajo el nodo mib-2, bajo el nodo snmp v2 y los que se encuentren bajo el nodo enterprises. Veremos que los objetos gestionados que están relacionados se encuentran organizados en grupos y subgrupos, de manera que no tengamos miles de nodos colgando directamente del nodo mib-2, por ejemplo.

Para echar un vistazo al árbol de información de gestión, podemos descargar un MIB browser como tkmib, disponible en el repositorio de Debian y Ubuntu:

$sudo aptitude install tkmib
$
tkmib &


Si navegamos hasta el grupo system, dentro del nodo mib-2, veremos todos los objetos gestionados de este grupo, como sysDescr, sysUpTime, sysName, sysLocation...



En la imagen se puede observar cómo, al seleccionar el objeto SysDescr, podemos ver su OID, su tipo, su modo de acceso, su descripción...

Existen 2 tipos de objetos gestionados, escalares y tabulares:

  • Los objetos escalares, como el SysUpTime, son aquellos que sólo pueden devolver un resultado, ya que definen una instancia única de un objeto (una única hoja en el árbol).
  • Para los objetos tabulares, sin embargo, pueden aparecer múltiples instancias (múltiples hojas en el árbol). Pensemos, por ejemplo, en un dispositivo con varias tarjetas de red; en este caso habrá una instancia del objeto IfSpeed por cada una de las tarjetas del equipo.

En la próxima entrada seguiremos estudiando el protocolo SNMP, centrándonos en los mensajes de gestión y la seguridad del protocolo.

¡Un saludo!

Fuentes:
http://www3.rad.com/networks/applications/snmp/comp.htm
http://www.manageengine.com/network-monitoring/what-is-snmp.html

Introducción a SNMP

¡Hola!

Durante esta semana, voy a dedicar una serie de entradas a estudiar el protocolo SNMP, Simple Netowork Management Protocol - Protocolo de gestión simple de la red, basándonos en el genial artículo de Debby Koren, "Dean" RAD University.

Un repaso histórico

Antes de la aparición de SNMP, si querías gestionar un conjunto de dispositivos de red, debías tener estaciones dedicadas de gestión, quizás con varias ventanas para diferentes tipos de información (estadísticas, actividad, etc) que eran específicas de cada fabricante. De hecho, era raro que un fabricante tuviera una estación de gestión común para todos sus dispositivos.

No existía un protocolo común, sino una gran cantidad de protocolos propietarios. SNMP se desarrolló para tratar de resolver este problema, ofreciendo un protocolo de gestión de la red estandarizado de forma que se pudiera emplear una tecnología común para intercambiar información de forma consistente entre los diferentes dispositivos de la red, aunque fueran de fabricantes distintos.

Desde que se publicó el primer RFC de SNMP hace más de 20 años, SNMP ha sido actualizado varias veces y se ha convertido en un estándar que se implementa en prácticamente todos los dispositivos de red. Aunque se diseñó pensando en elementos de Internet, se pueden encontrar todo tipo de dispositivos que lo soportan, como equipos de aire acondicionado. También se puede usar SNMP para gestionar sistemas software. SNMP puede utilizarse para monitorizar, configurar y obtener información de dispositivos o programas usando impresionantes interfaces gráficas en equipos de gestión carísimos, o usando un software de gestión gratuito o, incluso, desde la CLI.

Componentes y Arquitectura

Hay 4 componentes básicos en SNMP:

  • Nodos gestionados o elementos de la red, que cuentan con un agente (agent).
  • Como mínimo, una estación de gestión de la red (NMS)
  • Información de gestión
  • Un protocolo de gestión de la red, que usan el NMS y los agentes para intercambiar la información de gestión
Un nodo gestionado puede ser cualquier sistema, incluyendo un sistema software, que tiene algún tipo de conectividad de red. De hecho, al comienzo del desarrollo de SNMP, con el objetivo de demostrar la versatilidad del protocolo, la compañía Epilogue mostró cómo se podía usar SNMP para gestionar una tostadora.

El agente que contiene cada nodo de gestión implementa el protocolo SNMP. El agente es capaz de enviar, recibir y parsear mensajes SNMP. El agente interactúa con el dispositivo físico y obtiene la información necesaria para responder las consultas del NMS y para enviar mensajes trap (mensajes de notificación). El agente también es capaz de realizar cambios en la configuración del dispositivo, siguiendo las instrucciones de las peticiones del NMS. Los agentes, por tanto, tienen que contar con una configuración de control de acceso, para gestionar los privilegios de lectura y escritura.

Una estación de gestión de la red (NMS) es un host que es capaz de enviar peticiones SNMP y de recibir y parsear respuestas SNMP y mensajes trap hacia/desde los nodos gestionados. Existen muchos NMS software comerciales que ofrecen muchas funcionalidades, como la capacidad de "descubrir" los nodos gestionables de la red, mostrar gráficamente los nodos en un mapa de la red, usar iconos para cada tipo de nodo, mostrar información del estado, estadísticas, etc.

El tercer componente de SNMP es la información de gestión, que es, evidentemente, la información que intercambian los agentes y el NMS. Usaremos el término objeto gestionado para referirnos a una unidad de información de gestión. ¡Ojo! No hay que confundir un objeto gestionado con un dispositivo gestionado, no es lo mismo. Un objeto gestionado es un concepto abstracto, es la definición de algún tipo de información. Por ejemplo, supongamos que tenemos un dispositivo que puede cambiar de color; podríamos definir un objeto gestionado llamado "color" y su definición correspondiente sería "el color del dispositivo".

A una colección de objetos gestionados relacionados, que se definen en un documento, se le llama módulo MIB (Management Information Base). Veremos que hay algunos módulos MIB estándar, a los que se les llama simplemente MIBs, que todos los dispositivos SNMP deben soportar. Hay otros módulos MIB estándar que deberían ser soportados sólo por dispositivos para los que el MIB es relevante, y otros MIB privados, específicos para un determinado fabricante, que contienen definiciones de objetos gestionados para sus equipos.

Por ejemplo, todos los dispositivos gestionables por SNMP deben contar con cierta información, como una dirección IP, para que se considere que cumplen con el protocolo SNMP; este tipo de información debería estar definida en un MIB estándar que todos los dispositivos deben soportar. Si el dispositivo tiene una interfaz Ethernet, entonces debería ser capaz de ofrecer cierta información, como el número de colisiones, y esta información se define en un MIB Ethernet, que todos los dispositivos con una interfaz Ethernet deben soportar. Por último, un fabricante de switches, por ejemplo, podría ofrecer una funcionalidad que hace sus dispositivos más atractivos a los clientes: el switch puede cambiar de color para mimetizarse con el armario. El fabricante tiene que ofrecer, por tanto, un MIB privado que contendría un objeto gestionado para este propósito.

Por tanto, los MIBs contienen los objetos gestionados que representan los recursos, la configuración, el estado, etc, de un sistema. Los objetos gestionados tienen valores asignados para representarlos, pero no son el propio valor. Por ejemplo, siguiendo con el ejemplo del objeto gestionado "color", su definición sería "el color del dispositivo" y su valor asignado podría ser 0 para negro, 1 para rosa, 2 para gris, 3 para verde, etc. En este caso, el objeto sería un entero, y el valor del entero representaría el color. Sería precisamente el valor del objeto gestionado lo que sería monitorizado y modificado por un NMS.

Y esto nos lleva al último componente de la arquitectura de gestión: el protocolo de gestión de la red. Pero, espera un momento, ¿no esto lo que llamamos 'SNMP'? ¿No es SNMP el protocolo de gestión de la red? SNMP es eso y más cosas, ya que define los MIBs, la arquitectura y el protocolo de intercambio de mensajes. A este último aspecto, el protocolo de intercambio de mensajes entre los nodos gestionados y el NMS, incluyendo el tipo de los mensajes y los formatos, es al que se llama protocolo de gestión de la red.

Veremos en la próxima entrada que hay varios tipos de mensajes SNMP, que permiten al NMS leer y/o escribir información, y permiten a los agentes enviar mensajes trap para notificar o alarmar de una cierta situación.


Arquitectura de gestión


SNMP emplea una arquitectura cliente-servidor tal y como se muestra en la figura siguiente:



Como es el NMS el que inicia las peticiones SNMP, mientras los agentes en los diferentes dispositivos gestionados (router, switch, servidor y tostadora) esperan de forma pasiva estas consultas, podemos decir que el NMS es el cliente y los agentes los servidores. Los agentes escuchan peticiones en el puerto UDP 161.

Sin embargo, SNMP contiene también el protocolo para la gestión de traps. Como ya se ha mencionado, traps son mensajes no solicitados por el NMS que se envían por los agentes para informar de eventos poco usuales o para alarmar sobre una cierta situación. Como el agentes es quien inicia la conexión, en este caso los agentes son los clientes y los NMS los servidores, que escuchan en el puerto UDP 162.


En las próximas entradas seguiremos hablando de SNMP, profundizando en los MIBs, los mensajes de gestión y la seguridad del protocolo.

¡Un saludo!