Lección 1
Gestión de Red: modelo de gestión SNMP
Índice ¿Qué es Gestión de Red? .................................................................................. 2 Áreas funcionales de Gestión de Red ........................... ............. ........................... .......................... ........................ ........... 3 Gestión del rendimiento (prestaciones): ......................................................... 3 Gestión de los fallos: ...................................................................................... 3 Gestión de la configuración: ........................................................................... 4 Gestión de la contabilidad (accounting): ......................................................... 4 Gestión de la seguridad: ................................................................................. 5 Arquitectura genérica de un sistema sistema de Gestión de Red .......................... ............. ...................... ......... 6 Historia de la gestión de red ............................................................................... 8 GESTIÓN SNMP, MODELO DE GESTIÓN EN INTERNET......................... ............ .................. ..... 9 Introducción .................................................................................................... 9 Arquitectura del modelo de gestión gestión de Internet .................................. ...................... ...................... .......... 10 GESTIÓN SNMP: Modelo de Información ......................... ............ .......................... .......................... ............... 14 1 SMI: Estructura de la MIB ................................................................... 16 2 SMI: TIPOS DE DATOS Y SINTÁXIS ................................................. 20 3 SMI: Reglas de codificación ................................................................ 29 ¿Para qué sirve todo esto? ........................................................................... 31 Gestión SNMP: Modelo de comunicación..................................................... 34 1 Operaciones ....................................................................................... 35 2 Comunidades ...................................................................................... 36 3 Identificación de Instancias ................................................................. 37 4 Formato del mensaje SNMP ............................................................... 39 Evolución de SNMP ...................................................................................... 42 Monitorización Remota RMON .............................................................. 45 Caso Práctico - Gestión de Internet: SNMP ..................................................... 47 Introducción En este bloque se pretende en primer lugar proporcionar una introducción introducción a lo que es la gestión de red y sus áreas funcionales. En segundo lugar se estudiará en detalle el modelo de gestión de red en Internet (que utiliza el protocolo SNMP), ya que es el más ampliamente utilizado. Es importante que el 1
alumno se familiarice con la arquitectura del sistema de gestión de red y sus modelos de información y comunicación. Por último, se muestra un breve resumen de la evolución del protocolo SNMP.
Objetivos Conocer en profundidad un modelo de gestión de red, en este caso el de Internet, SNMP. Apartados
¿Qué es Gestión de Red? Una red consiste en muchas piezas de hardware y software, desde enlaces, puentes, routers, hosts, hosts, etc, que son los componentes físicos de la red hasta hasta muchos protocolos (implementados tanto en software como en hardware) que controlan y coordinan dichos dispositivos. Cuando cientos o miles de estos componentes son utilizados juntos por una organización para formar una red, es natural que los componentes de vez en cuando no funcionen bien, que los elementos de la red se desconfiguren, que los recursos de la red estén sobreutilizados, o que simplemente algún componente de la red se estropee (un cable cortado, una coca-cola que cae sobre un router, etc). Con tantos componentes de red dispersos en una zona extensa, el administrador de red en su centro de operaciones de red (NOC Network Operation Center), necesita herramientas que le ayuden a monitorizar, gestionar y controlar la red. En este bloque se describirá la arquitectura, protocolos e información básica usada por el administrador de red para esta tarea. Existen muchas definiciones de gestión de red, una de ellas es la dada por Saydam Magedanz (1996) que dice:
2
alumno se familiarice con la arquitectura del sistema de gestión de red y sus modelos de información y comunicación. Por último, se muestra un breve resumen de la evolución del protocolo SNMP.
Objetivos Conocer en profundidad un modelo de gestión de red, en este caso el de Internet, SNMP. Apartados
¿Qué es Gestión de Red? Una red consiste en muchas piezas de hardware y software, desde enlaces, puentes, routers, hosts, hosts, etc, que son los componentes físicos de la red hasta hasta muchos protocolos (implementados tanto en software como en hardware) que controlan y coordinan dichos dispositivos. Cuando cientos o miles de estos componentes son utilizados juntos por una organización para formar una red, es natural que los componentes de vez en cuando no funcionen bien, que los elementos de la red se desconfiguren, que los recursos de la red estén sobreutilizados, o que simplemente algún componente de la red se estropee (un cable cortado, una coca-cola que cae sobre un router, etc). Con tantos componentes de red dispersos en una zona extensa, el administrador de red en su centro de operaciones de red (NOC Network Operation Center), necesita herramientas que le ayuden a monitorizar, gestionar y controlar la red. En este bloque se describirá la arquitectura, protocolos e información básica usada por el administrador de red para esta tarea. Existen muchas definiciones de gestión de red, una de ellas es la dada por Saydam Magedanz (1996) que dice:
2
“La gestión gestión de red incluye el desarrollo, integración y coordinación de hardware, software y elementos humanos para monitorizar, testar, configurar, analizar, evaluar y controlar la red y sus recursos para alcanzar los requerimientos de tiempo-real, operacional, rendimiento y Calidad de Servicio con un coste razonable”
Áreas funcionales de Gestión de Red La ISO (International Organization for Standards) ha definido 5 áreas funcionales dentro de la gestión de red, es decir qué es lo que se gestiona dentro de una red, que son: Gestión del rendimiento (prestaciones): El objetivo es medir, cuantificar, analizar y controlar las prestaciones de los distintos componentes de red, desde dispositivos individuales como enlaces, routers, hosts hasta una ruta, camino dentro de la red, para poder ajustar los parámetros de la red. En Internet Internet el
protocolo SNMP (Simple Network
Managament Protocol) es importante para conseguir esta gestión. Algunas cuestiones que que atañen a esta gestión gestión son:
¿Cuál es la utilización de la red?
¿Hay un tráfico excesivo?
¿Existen cuellos de botella?, ¿está aumentando el tiempo tiempo de de respuesta? respuesta?
Gestión de los fallos: El objetivo es registrar, detectar y responder a las situaciones de fallo en la red. Un fallo en la red trae como consecuencia que el usuario no pueda utilizar algún servicio, por lo que es deseable su pronta detección y corrección. El papel de SNMP también es importante en esta área funcional. Es importante distinguir entre fallo y error:
Error: Un evento aislado, p. e. e. Se pierde un paquete o no llega correctamente.
3
Fallo: un funcionamiento anormal que requiere una intervención para ser subsanado. El fallo se manifiesta por un funcionamiento incorrecto (se corta la línea física) o por exceso de errores (pérdida de muchos paquetes).
Los objetivos de la gestión de fallos son:
Detección, aislamiento y corrección de fallos.
Cuando ocurre un fallo, tan pronto como sea posible: o
Determinar exactamente donde está el fallo
o
Aislar el resto de la red, para que pueda seguir operando sin interferencia.
o
Reconfigurar la red para minimizar el impacto de operar sin el componente averiado.
o
Reparar o reemplazar el componente averiado para devolver la red al estado inicial.
Gestión de la configuración: Permite al administrador conocer qué dispositivos hay en la red y el hardware y configuraciones software de dichos dispositivos, esto se logra mediante:
Capacidad de leer y/o modificar los parámetros de configuración de los dispositivos.
Capacidad para detectar nuevos dispositivos.
Conocer en cada momento la topología de la red.
Gestión de la contabilidad1 (accounting): Permite al administrador especificar, registrar y controlar el acceso de usuarios y dispositivos a los recursos de la red. Establecer cuotas de uso, costes de usos de la red y asignación de privilegios de acceso a los recursos son parte de la gestión de contabilidad. Dependiendo del sistema gestionado, los costes pueden convertirse en facturas, en el caso de redes de una empresa, los usuarios de los recursos son internos y no se cobra ni se paga por la utilización de los servicios, pero aún cuando no es así esta gestión es interesante por: 1
Algunos autores utilizan el término "gestión de las cuentas".
4
Conocer la rentabilidad de la inversión realizada en los recursos de comunicaciones.
Un usuario puede abusar de sus privilegios de acceso y cargando la red a expensas de los demás usuarios.
Los usuarios pueden estar haciendo un uso ineficiente de la red y el gestor puede ayudarle a modificar su modo de trabajo y obtener mejores prestaciones.
El gestor de la red está en una mejor situación para planificar el crecimiento de la red si la actividad de los usuarios se conoce con un nivel de detalle suficiente.
Gestión de la seguridad: El objetivo es controlar el acceso a los recursos de la red. Se incluyen dentro de la gestión de seguridad:
Monitorización y control de los accesos a las computadoras de la red.
Uso de firewalls para monitorizar y controlar los puntos de acceso externos a la red
Generación, distribución y encriptación de claves y otras autorizaciones de acceso.
Los historiales (archivos log) son una herramienta importante para la gestión de la seguridad. Aunque se distinguen estas cinco áreas y se describen de forma separada, es importante tener en cuenta que, en la práctica, los cometidos de unas y otras se solapan e interactúan. Por ejemplo, si hay un fallo se producirá una disminución del rendimiento; el abuso de la red por parte de un usuario puede ser mitigado por medio de las herramientas de seguridad; para corregir un fallo es posible que tengamos que consultar la configuración inicial y restablecerla, etc. Al igual que ocurre con las áreas funcionales, también las herramientas utilizadas en gestión de red pueden cubrir desde parte de una hasta varias de dichas áreas. No hay ninguna herramienta que resuelva por sí sola los
5
problemas de gestión de red y es tarea del administrador (del gestor) elegir aquellas más adecuadas y hacerlas funcionar coordinadamente e integradas.
Arquitectura genérica de un sistema de Gestión de Red La gestión de red tiene que monitorizar, configurar, controlar,..., el hardware y software y los componentes de una red. Como los dispositivos de red están distribuidos, esto obliga a que el administrador de red pueda recolectar datos (p.e para monitorizarlos) de entidades remotas y pueda realizar cambios en las entidades remotas (configuración). La arquitectura de un sistema de gestión de red consta de tres componentes principales: Sistema gestor, los dispositivos a gestionar y un protocolo de gestión de red. Esta arquitectura es genérica y ha sido aplicada a varios estándares de gestión de red propuestos a lo largo de los años que se verán en el siguiente apartado. 1. El sistema gestor es una aplicación, utilizada por el administrador, ejecutándose en una estación del centro de operaciones de red (NOC). Este sistema es el foco de actividad para la gestión de red; controla la recogida, procesado, análisis, y/o visualización de la información de gestión de red. Es aquí donde se inician las acciones para controlar el comportamiento de la red y donde el administrador de red interactúa con los dispositivos de red.
6
2. Dispositivo a gestionar es un componente de la red (incluido su software) a gestionar. Puede ser un host, un router, una impresora, etc. Dentro de un dispositivo gestionable, puede haber varios objetos gestionables. Estos objetos gestionables son piezas de hardware dentro del dispositivo gestionable (p.e: una tarjeta de red), y el conjunto de parámetros de configuración para las piezas de hardware y software (por ejemplo el protocolo RIP -Routing Information Protocol-, la tabla de rutas del router, el número de paquetes ICMP echo (request) recibidos). Estos objetos gestionables tienen información asociada que se recopila en una Base de
Infomación de Gestión que se denomina MIB (Management Information Base); esta información está disponible para el sistema gestor (y en algunos casos puede modificarla). Además, en cada dispositivo gestionable hay residente un agente, que actúa sobre el dispositivo gestionable bajo el control del gestor. Un agente, es en resumen un software para la gestión de red contenido en los nodos y que realiza las siguientes tareas: Recoge estadísticas generalmente sobre actividades relacionadas con la
red y las almacena localmente en su MIB (Management Information Base) Responde a órdenes recibidas desde el centro de control de la red:
o
Transmite las estadísticas recolectadas al centro de control
o
Cambia un parámetro (p.e. activar o desactivar una alarma cuando se produce un fallo de autentificación)
o
Ofrece información de estado (p.e. configuración, enlaces activos)
o
Genera tráfico artificial para realizar una prueba
Envía mensajes al centro de control cuando las condiciones locales sufren un cambio significativo.
3. El protocolo de gestión de red: es el protocolo utilizado entre el sistema gestor y los agentes de los dispositivos gestionables, permitiendo al sistema gestor preguntar el estado de los dispositivos e indirectamente realizar acciones en ellos. Además, los agentes utilizan el protocolo para informar al sistema gestor de eventos (fallo de componentes, superado un límite de 7
rendimiento, etc...). Es importante resaltar que el protocolo de gestión de red, no gestiona por sí mismo la red. Proporciona una herramienta con la cual el administrador de red puede gestionar (monitorizar, testear, sondear, configurar, analizar, evaluar y controlar) la red.
Historia de la gestión de red La primera herramienta para gestión de Internet fue ICMP (Internet Control Message Protocol). Se trata de un protocolo y una especificación muy sencilla
para detectar cómo pasan los paquetes de datos a través de la red, los routers intermedios que atraviesan y comprobar si llegan o no a su destino.
Mensajes de control entre routers y hosts.
Gestión en ICMP: mensajes de petición/respuesta de eco.
Se puede comprobar la conectividad y estimar retardos y fiabilidad de una ruta en la red. Programas PING (Packet Internet Groper) y traceroute.
ICMP fue una solución para la gestión de redes durante varios años, pero a finales de los 80 Internet crece explosivamente, e ICMP se queda corto. En 1987 se propone SGMP (Simple Gateway Monitoring Protocol): para monitorizar routers. En 1988 en un ámbito más general se proponen dos aproximaciones:
Simple Network Management Protocol
(SNMP), versión extendida de
SGMP, para redes TCP/IP y diseñado con el fin de utilizarlo sólo a corto plazo.
CMIP (Common Management Information Protocol) en desarrollo en ISO/OSI, para redes OSI, como solución “definitiva” a largo plazo
(cuando el modelo OSI (Open System Interconnection) se impusiera a TCP/IP, cosa que nunca ocurrió). Para facilitar la convergencia futura de SNMP a CMIP, ambas utilizarían una misma base de datos para los objetos gestionados. Además, ambos fueron diseñados para ser independientes de los distintos vendedores.
8
La evolución de SNMP es comparable a la de TCP/IP. Cómo SNMP fue ágilmente diseñado y desarrollado, en un momento en que la necesidad de la gestión de red empezaba a ser crítica, SNMP fue aceptado rápidamente y se extendió muy pronto su uso, debido también en gran medida a la proliferación de las redes basadas en TCP/IP. Además la gestión OSI es mucho más compleja y aún no están terminadas todas las normas. SNMP se ha impuesto mientras que el uso de CMIP es muy inferior. SNMP lejos de desaparecer, como se había previsto en su nacimiento, se ha afianzado como el estándar de gestión más importante de los que se emplean en la actualidad. Los principales vendedores de computadoras, switches, routers, concentradores, etc. incorporan SNMP en sus dispositivos. Actualmente, también la tecnología Web se está empezando a aplicar en gestión de redes. Utilizando un servidor Web en el dispositivo a gestionar y los navegadores Web como estaciones gestoras, con la gran ventaja de poder acceder a la información desde cualquier punto, donde tengamos un navegador y conexión a Internet (no estamos limitados al NOC). Cómo es una tecnología en evolución no existe actualmente ningún estándar al respecto.
GESTIÓN SNMP, MODELO DE GESTIÓN EN INTERNET Introducción La gestión SNMP también se denomina gestión de Internet. Cualquier red que utilice los protocolos TCP/IP es gestionable por SNMP. (Incluso redes que no utilizan TCP/IP se pueden gestionar con SNMP por medio de agentes denominados proxy). La gestión SNMP es la más usada. La mayoría de los componentes utilizados en las empresas llevan incorporados agentes que responden a un sistema gestor SNMP. Por lo tanto, si añadimos un nuevo componente a la red (un router, puente, host) que incluye agente SNMP, el sistema gestor puede automáticamente empezar a monitorizar el nuevo componente.
9
En la actualidad el término "SNMP" se usa para referirse al conjunto de especificaciones para gestión de red, que incluyen el protocolo SNMP en sí, la definición de las estructuras de datos y los conceptos asociados. Los estándares de Internet se definen en los RFCs (Request For Comments), los principales para la gestión SNMP son:
MIB (Management Information Base): RFC 1156, RFC 1123, describen los objetos contenidos en la MIB.
SMI (Structure of Management Information Base): RFC 1155, describe cómo se definen los objetos contenidos en la MIB.
SNMP(Simple Network Management Protocol): RFC 1157, define el protocolo SNMP, la forma de interacción agente-gestor, tipos de mensajes, formato del mensaje, etc...).
Arquitectura del modelo de gestión de Internet El modelo de gestión de Internet sigue el esquema básico que se vio para gestión de redes que consta de:
La estación gestora
Dispositivos gestionables que contienen el agente y la Base de Información de gestión (MIB)
El protocolo de gestión de red, en este caso SNMP
10
SNMP es un protocolo de nivel de aplicación, que funciona sobre UDP (no orientado a conexión, no garantiza la entrega confiable), por lo tanto SNMP no establece, ni mantiene, conexiones entre el sistema gestor y los agentes (de esta manera sobrecarga menos la red y la implementación es más sencilla). En el sistema gestor se ejecutará un proceso gestor que accederá a la MIB central del sistema y proporciona un interfaz al administrador de la red. Este proceso se comunicará con los procesos agentes de los dispositivos gestionables usando el protocolo SNMP. Cada agente, dentro de los dispositivos a gestionar, tiene también que implementar SNMP, UDP, e IP. El proceso agente interpreta los mensajes SNMP y controla la MIB del dispositivo. • Los agentes escuchan en el puerto 161 • Las estaciones gestoras escuchan en el puerto 162
En amarillo aparecen los elementos gestionados y en azul los elementos de gestión. Cómo el propio nombre indica, el protocolo SNMP f ue diseñado para ser simple y versátil, lo cual seguramente ha influido en su éxito. La comunicación de la 11
información de gestión entre las entidades se realiza a través del intercambió de sólo 3 tipos de mensajes de protocolo.
get: la estación gestora extrae ( lee) el valor de un objeto del agente.
set: la estación gestora fija ( escribe) el valor de un objeto del agente.
trap: permite a un agente notificar a la estación gestora eventos significativos.
Estos tres tipos se concretan en 5 posibles mensajes, la aplicación gestora puede solicitar estos mensajes: GetRequest , GetNextRequest y SetRequest , que serán reconocidos por el
agente y respondidos mediante el mensaje GetResponse. Además el agente, puede enviar un mensaje Trap en respuesta a un evento ocurrido en el dispositivo gestionable. Los distintos mensajes se verán con más profundidad en el apartado que trata el modelo de comunicación de este tema.
Trap-Directed Polling Si una estación gestora es responsable de un gran número de agentes y cada agente mantiene un gran número de objetos no es práctico que la estación gestora sondee todos sus agentes para obtener datos constantemente. Lo que 12
hace SNMP, es diseñar el gestor para que utilice la técnica
trap-directed
polling:
Esta técnica consiste en que la estación gestora realiza un sondeo inicial y a intervalos poco frecuentes (p.e. una vez al día) para recoger información clave (características del interfaz y estadísticas básicas, como número de paquetes enviados y recibidos por una interfaz). Además, se configuran los agentes para que notifiquen a la estación gestora los eventos no usuales (p.e., el agente cae y se reactiva, un enlace falla, condición de sobrecarga). La comunicación de estos eventos se realiza mediante traps. Una vez alertada, la estación gestora puede iniciar una consulta (poll) sobre el agente para diagnosticar el problema y llevar a cabo las acciones necesarias.
Proxy En una situación ideal todos los componentes de la red incluyen un agente SNMP, para poder ser gestionable. Pero esto no siempre es así:
Hay componentes que no soportan SNMP, salen más baratos.
Hay sistemas que se sobrecargarían excesivamente con el agente SNMP (controladores programables que tienen TCP/IP para sus aplicaciones, pero no se quiere cargarlos con SNMP, el agente y el mantenimiento de la MIB).
Componentes que no soportan TCP/IP
Para gestionar mediante SNMP estos dispositivos que no implementan SNMP, uno de los agentes en la configuración hace de proxy para uno o varios componentes
Cuando un nodo hace de prox y, actúa de parte de otro u otros.
Si un gestor quiere información de (o controlar a) ese componente tiene que comunicarse con su proxy.
13
El agente proxy traduce la petición del gestor a la forma adecuada para el nodo en cuestión.
GESTIÓN SNMP: Modelo de Información El objetivo de la información de gestión es referenciar recursos en un sistema remoto para gestionarlos, para conseguirlo se plantean las siguientes cuestiones:
¿Cómo llegar al sistema remoto? Esto es tarea del Protocolo IP
¿Cómo llegar al proceso de gestión de red en el sistema remoto? Esto
es tarea del Protocolo SNMP ¿Cómo llegar al recurso del sistema remoto? Es necesario un método común para nombrar los objetos: Object Identifiers (OID)
Como se ha visto en la estructura de gestión de red de Internet la información a gestionar se representa como una colección de objetos que se llama MIB (Management Information Base). Cada recurso gestionable es un objeto
(variable), p.e. un objeto puede ser un contador de número de datagramas IP descartados, el número de interfaces de un router, la tabla de rutas, etc. La MIB es una colección de objetos que tiene estructura de árbol. Cada sistema gestionable mantiene una MIB con información sobre sus propios recursos y la estación gestora monitoriza los recursos de la red leyendo los valores de los objetos en la MIB y puede controlar los recursos modificando esos valores
14
El objeto usado para representar un recurso particular debe ser el mismo en todos los sistemas. Ejemplo: El número de conexiones TCP abiertas en un periodo: conexiones abiertas = conexiones pasivas + conexiones activas Una apertura pasiva es la que se produce cuando una aplicación informa al sistema operativo de que está dispuesta a aceptar una comunicación entrante. Se produce una asignación de puerto para ella, y queda en espera. Basta con almacenar dos de los tres. La definición de MIB especifica que se deben almacenar las conexiones pasivas y activas Se definen los objetos tcpActiveOpens y tcpPassiveOpens
Ocupan las posiciones en el árbol 1.3.6.1.2.1.6.5 y 1.3.6.1.2.1.6.6 , dentro de la MIB.
Son de tipo counter (entero 32 bits)
Debe utilizarse un esquema de representación común (estándar) para soportar la interoperabilidad
1
SMI: STRUCTURE OF MANAGEMENT INFORMATION (RFC 1155)
SMI es un lenguaje usado para definir la información de gestión. Está basado en ASN.1 (Abstract Syntax Notation One). Es necesario para asegurar que la sintaxis y semántica de los datos de gestión de red están definidas de forma inequívoca. SMI no define información concreta de una tarjeta de red, de un router o de cualquier dispositivo gestionable, si no que define el lenguaje en el que esa información se especifica. Para proporcionar una forma estandarizada de representar la información de gestión, SMI proporciona:
una técnica estándar para definir la estructura de una MIB
una técnica estándar para definir objetos individuales (sintaxis y su valor)
una técnica estándar para codificar los valores de los objetos 15
1 SMI: Estructura de la MIB Como ya se ha comentado anteriormente, la estructura de la MIB es en forma de árbol, denominado "árbol OID". Los objetos forman las hojas del árbol: representan un recurso, una actividad o información relacionada que va a ser gestionada. Dentro del árbol, los objetos se agrupan en grupos (ramas) relacionados (Grupos de objetos IP, grupos de objetos TCP, ...). A cada objeto de una MIB se le asocia un identificador del tipo ASN.1 OBJECT
IDENTIFIER, consistente en una secuencia de números enteros separados por comas. El identificador sirve para nombrar el objeto, además como el valor asociado con el tipo OBJECT IDENTIFIER (OID) es jerárquico: secuencia de enteros. Ej: 1.3.6.1.4.1.9.1.25, el nombre sirve también para identificar la posición que ocupa el objeto dentro del árbol. Ahora lo veremos con más claridad.
Árbol OID Es un árbol jerárquico definido por una secuencia de números enteros no negativos separados por puntos:
En la página web http://www.alvestrand.no//objectid/top.html , se puede recorrer todo el árbol, es una página no oficial. 16
Como se puede observar existen tres nodos en el primer nivel: iso (representado con el número entero "1"), ccitt (comité que organiza los estándares
de
comunicación
internacional,
telefónico
y
telegráfico,
representado con el número "0") y joint-iso-ccitt (unión de los dos anteriores, representado con el número "2"). Dentro del nodo iso hay un subárbol para las organizaciones org (representado con el número "3") y dentro de éste un subárbol para el Department of Defense de USA (dod, representado con el número 6). El subárbol de internet (identificado con un "1", y que contiene todos los elementos de una red basada en TCP/IP que se monitorizarán con SNMP) es un nodo que cuelga de dod. Se identifica (partiendo desde arriba de la jerarquía) mediante: internet OBJECT IDENTIFIER::{ iso (1) org (3) dod (6) internet (1)} Este valor sirve como prefijo de los nodos en niveles inferiores (todos los parámetros relacionados con Internet que se pueden monitorizar empezarán con 1.3.6.1). SMI define cuatro nodos bajo el nodo internet:
directory (1) o
Reservado para uso futuro
o
Previsto que contenga información sobre el servicio de directorio OSI, X.500
experimental (3) o
Protocolos y MIBs experimentales, aún no son estándar.
private (4) o
MIBs particulares de empresas (añaden funcionalidad).
o
Cada empresa tiene su propio árbol a partir de private.
o
Se hacen públicas en www.isi.edu (ftp://ftp.isi.edu/mib/)
mgmt(2)
17
Debajo de management están definidos los módulos mib
o
estandarizados. Se han desarrollado 2 versiones, mib-1(RFC1056) y mib-2 (RFC1213), la segunda es una extensión de la primera y es la que se está utilizando actualmente. El OID de mgmt se puede indicar: {iso (1) org (3) dod (6) internet (1) mgmt(2) } o 1.3.6.1.2 Grupos de mib estándar definidas en mgmt
El grupo mib-2 se subdivide en los siguientes grupos:
system: información general del sistema.
interfaces: interfaces de red del sistema.
at: (deprecated: reemplazado) ha quedado vacío en MIB II, pasando sus objetos a otros grupos.
ip: implementación y ejecución de IP en el sistema.
icmp: implementación y ejecución de ICMP en el sistema.
tcp: implementación y ejecución de TCP en el sistema.
udp: implementación y ejecución de UCP en el sistema.
egp: implementación y ejecución de EGP(exterior gateway protocol) en el sistema (no se utiliza)
dot3: esquemas de transmisión y protocolos de acceso.
SNMP: implementación y ejecución de SNMP en el sistema.
El grupo system (1.3.6.1.2.1.1) contiene Información sobre el sistema en el que está el agente. Los objetos gestionables definidos en este grupo son: _ sysObjectID: identificador asignado por el fabricante (en private) 18
formato: 1.3.6.1.4.1.ve.vs.vs –ve: número de la empresa –vs: código específico del producto
Ejemplo: El router 2509 de Cisco (ve = 9) 1.3.6.1.4.1.9.1.25 _ sysServices: servicios (niveles OSI) que ofrece el sistema _ susUptime: tiempo funcionando desde última inicialización _ sysDescr: descripción del sistema _ sysLocation: localización física _ sysContact: persona responsable del sistema _ sysName: nombre del dispositivo
interfaces (1.3.6.1.2.1.2) Información sobre cada interfaz en un dispositivo de red. _ Objetos que definen la tabla de interfaces: _ ifNumber (1): número de interfaces de la entidad _ ifTable (2): tabla de interfaces de la entidad (ver figura debajo). _ ifEntry(2.1): información sobre un interfaz específico (ver figura debajo).
ifOperStatus:estado operacional (up1/down2/testing3) _ ifAdminStatus: estado administrativo (up1/down2/testing3) _ ifLastChange: tiempo desde cambio a estado operacional _ ifDescr: nombre de la interfaz (eth0) _ ifType: tipo de interfaz, (6 = “ethernet-CSMA/CD”)
_ ifMtu: máximo tamaño de la trama. _ ifSpeed: velocidad en la interfaz en un momento dado (útil para 19
interfaces que cambian de velocidad como modem) _ ifInDiscard/ifOutputDiscard: paquetes descartados (error, no conocido...) _ ifInErrors/ifOutErrors: paquetes con error _ ifInOctets/ifOutOctets: bytes recibidos/enviados _ ifInUcastPkts/ ifOutUcastPkts: paquetes unicast _ ifInNUcastPkts/ ifOutNUcastPkts: paquetes no unicast _ ifInUnknownProtos: paquetes recibidos de protocolo desconocido _ ifOutQLen: paquetes en la cola de salida En la plataforma tenéis a vuestra disposición el anexo uno con todos los objetos definidos en mib-2, también podéis familiarizaros con la mib-2 a través de los sistemas gestores que se van a utilizar: getif y mib-browser. Mibs privadas Los fabricantes pueden crear objetos específicos para gestionar sus productos. El uso de SMI y un esquema de identificadores de objetos estándar permite que se pueda acceder fácilmente a esos objetos. Se cargan dentro de subárbol private (1.3.6.4.1) y más concretamente dentro de la rama enterprises (1.3.6.1.4.1). Una estación gestora solo puede acceder a la información cuya existencia conoce y sobre la que puede preguntar. Para que la estación gestora pueda gestionar objetos MIB privados, su estructura debe ser cargada en la estación gestora. Esto es importante, si se va a gestionar con SNMP un router cisco lo normal es que el sistema gestor traiga las mibs más habituales pero no de fabricantes concretos, por lo que hay que descargar la mib que utilice el router en concreto para que desde el sistema gestor se puedan ref erenciar los objetos gestionables que ha especificado cisco para ese router (se verá en la parte práctica). 2 SMI: TIPOS DE DATOS Y SINTÁXIS
20
Los tipos de datos que se usan en SNMP están basados en los de ASN.1, que como ya dijimos es un lenguaje para definir estructuras de datos, con el que definíamos:
una técnica estándar para definir la estructura de una MIB (tratado en el apartado anterior).
una técnica estándar para definir objetos individuales (sintaxis y su valor) (es el tema de este apartado).
una técnica estándar para codificar los valores de los objetos en sintaxis concreta de transferencia: BER(Basic Encoder Rules).
Podrían valer las definiciones de C (p.e.), pero carecen de una codificación en bits estandarizada: – Por ejemplo: para que una estación de 32 bits, little endian de complemento a
2 pueda comunicarse con otra de 16 bits, big endian y complemento a uno (por ejemplo, SNMP) Este apartado es un poco tedioso, basta con que hagáis una lectura rápida, lo que os permitirá poder entender los ficheros en los que se definen las mibs.
Reglas de sintaxis
La sintaxis distingue entre mayúsculas y minúsculas.
Los nombres de tipo empiezan con mayúscula.
Los nombres de los tipos primitivos se escriben con mayúscula.
Los nombres de valores y de los campos de un tipo estructurado se escriben con minúscula.
El valor nulo se expresa con NULL.
Se puede poner comentario en una línea desde la marca "--" hasta final de línea.
21
Tipos de datos definidos en SMI Los tipos de datos que se usan en SNMP están basados en los de ASN.1 Todos los tipos ASN.1, tienen una etiqueta asociada. La etiqueta consiste en el nombre de la clase y un número no negativo. La etiqueta se utiliza a la hora de codificar los datos para transmitirlos. Hay cuatro clases de tipos de datos en ASN.1: – UNIVERSAL: tipos básicos de ASN.1 (independientes de la aplicación) – APPLICATION: relevantes a una aplicación particular (por ejemplo, SNMP) – CONTEXT-SPECIFIC: igual que antes pero aplicables en un contexto
limitado – PRIVATE: definidos por los usuarios. No estandarizados
SMI: Tipos de datos universales Los tipos de la clase UNIVERSAL de ASN.1 que se usan en SNMP son
Nombre
Etiqueta
INTEGER
UNIVERSAL 2
OCTETSTRING
UNIVERSAL 4
NULL
UNIVERSAL 5
OBJECT IDENTIFIER
UNIVERSAL 6
SEQUENCE,SEQUENCE-OF
UNIVERSAL 16
En ASN.1 hay más: BOOLEAN, ENUMERATED,REAL, SET, ... pero no se usan en SNMP. SMI: Tipos de datos universales:
INTEGER:
32 bits en complemento a dos
Una variable de este tipo puede adoptar cualquier valor entero, pero se puede limitar
Por ejemplo: cuenta INTEGER ::= 100 -- valor inicial opcional Estado ::= INTEGER {up(1), down(2), unknown(3)} -- subtipo
22
PacketSize ::= INTEGER {0..1023} --subtipo
OCTETSTRING: Cadena de octetos. Puede definirse la longitud de la cadena y un valor inicial Casi toda la información de gestión que representa un texto es de este
tipo. Se utiliza también DisplayString que es equivalente pero sólo puede
contener caracteres NVT ASCII (máximo 255 caracteres). También PhysAddress es equivalente.
OBJECT IDENTIFIER Se utiliza para identificar y describir objetos en el árbol OID El identificador del objeto se puede expresar de varias formas:
Secuencia de números que determinan la posición dentro de la estructura del árbol mib2: OBJECT IDENTIFIER ::= {1 3 6 1 2 1} (identifica a mib2)
Con un nombre equivalente al entero: OBJECT IDENTIFIER ::= {iso org dod internet mgmt mib2}
Con un nombre y el entero equivalente entre paréntesis.
mib2 OBJECT IDENTIFIER ::= {iso org dod internet(6) mgmt(2) 1} Ejemplo: ip OBJECT IDENTIFIER ::={mib-2 4}
SEQUENCE es una lista ordenada de tipos. SEQUENCE-OF es un vector de una sola dimensión de un solo tipo. Hemos visto los tipos de datos primitivos, universales de ASN.1 utilizados en SMI, ahora vamos a ver los tipos de aplicación, que corresponden a la clase APPLICATION de asn.1, son tipos de datos relevantes para una aplicación en particular, en este caso SNMP.
23
Tipos de datos de aplicación definidos en SMI:
IpAddres s: dirección de 32 bits, formato IP versión 4. Es un OCTETSTRING de 4 bytes.
Counter: entero no negativo de 32 bits que puede ser incrementado pero no decrementado. Cuando alcanza el valor máximo comienza por 0. Ejemplos de aplicación:
o
contar el número de paquetes u octetos enviados o recibidos.
o
contar el número de errores de un cierto tipo.
Gauge: entero no negativo de 32 bits que puede ser incrementado o decrementado. Cuando alcanza el valor máximo se queda bloqueado en ese valor hasta que se pone a cero. o
el número de paquetes almacenados en una cola en un instante.
o
almacenar la diferencia en el valor de algo desde el principio al final de un intervalo de tiempo.
TimeTicks: entero no negativo que cuenta tiempo en centésimas de segundo (tiempo relativo).
Opaque: define datos arbitrarios codificados como OCTET STRING, prácticamente no se utiliza.
Sintaxis de declaración de objetos: macro OBJECT TYPE Se han visto los tipos de datos, universales y de aplicación definidos por SMI que se pueden utilizar en la MIB. Para poder definir los objetos gestionables de la MIB se ha creado una macro denominada OBJECT-TYPE, como siempre con formato ASN.1. OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type(ObjectSyntax) "ACCESS" Access
24
"STATUS" Status DescrPart ReferPart IndexPart DefValPart VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Status ::= "mandatory" | "optional" | "obsolete" | "deprecated" DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty ReferPart ::= "REFERENCE" value (reference DisplayString) | empty IndexPart ::= "INDEX" "{" IndexTypes "}" | empty IndexTypes ::= IndexType | IndexTypes "," IndexType IndexType ::= value (indexobject ObjectName) | type (indextype) DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}" | empty END Por lo tanto, como se verá en los ficheros donde se definen las mibs, para definir un objeto se utiliza siempre esta estructura. Cada objeto dentro de una MIB de SNMP tiene una definición formal, que especifica entre otros:
el tipo de datos asociados con el objeto
el rango de valores que puede tomar
su relación con otros objetos de la MIB (su posición dentro del árbol)
Se usa la sintaxis ASN.1
El significado de los posibles campos con los que se define un objeto es:
SYNTAX: tipo de datos, corresponde a un tipo universal (INTEGER,
OCTETSTRING) o a un tipo de aplicación (IpAddress, counter, ..) ACCESS: modo de acceso a una instancia de un objeto (read-only, read-write, write-only, not-accesible).
25
STATUS: requisitos de implementación, define si este objeto debe ser necesariamente incluido en la implementación de la MIB:
Mandatory: obligatorio. Optional: opcional.
Deprecated: debe ser soportado, pero será quitado en la
siguiente versión de MIBs.
Obsolete: ya no es necesario implementarlo.
DescrPart: (opcional) descripción textual de la semántica del objeto, una definición de para que sirve el objeto, dirigido al usuario. ReferPart: (opcional) referencia cruzada textual a un objeto definido en otra MIB.
IndexPart: define índices de las tablas.
DefValPart: (opcional) valor por defecto usado cuando se crea una instancia del objeto.
VALUE NOTATION: OID asignado al objeto. Indica el nombre que se usa para acceder a este objeto vía SNMP.
Ejemplos de declaraciones de objetos La definición dentro de la mib-2 del objeto sysDesc es la siguiente: sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } La definición dentro de la mib-2 del objeto fNumber es la siguiente: ifNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory 26
DESCRIPTION "The number of network interfaces (regardless of their current state) present on this system." ::= { interfaces 1 } Definición de tablas SMI sólo soporta una forma de estructurar los datos que es mediante una tabla de dos dimensiones de valores escalares. Para definir una tabla se declara: _ Nombre de la tabla: Table _ Entry: tableEntry _ Los elementos columnares. _ El índice. Cada tabla consiste en SEQUENCE OF TableEntry. Cada fila (TableEntry) consiste en una SEQUENCE de elementos columnares. Ejemplo de tabla: ipRoutingTable ipRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's IP Routing table." ::= { ip 21 } Entry y declaración del Indice: ipRouteEntry OBJECT-TYPE SYNTAX IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A route to a particular destination." INDEX { ipRouteDest } 27
::= { ipRouteTable 1 } Objetos columnares: IpRouteEntry ::= SEQUENCE { ipRouteDest IpAddress, ipRouteIfIndex INTEGER, ipRouteMetric1 INTEGER, ipRouteMetric2 INTEGER, ipRouteMetric3 INTEGER, ipRouteMetric4 INTEGER, ipRouteNextHop IpAddress, ipRouteType INTEGER, ipRouteProto INTEGER, ipRouteAge INTEGER, ipRouteMask IpAddress ipRouteMetric5 INTEGER, ipRouteInfo OBJECT IDENTIFIER } Definición de los objetos:
28
Además estarían las definiciones de los objetos ipRouteProto, ip Route Age, e ipRouteMask. En la plataforma tenéis la mib-2 en el anexo 2, examinar el fichero y comprobaréis la utilidad de todo lo visto en este apartado. 3 SMI: Reglas de codificación Por último, además de especificar un lenguaje de descripción de datos también se especifica como las instancias de los objetos, que han sido definidas
29
mediante ASN.1, tienen que ser enviadas por la red mediante BER (Basic Encode Rules). BER (Basic Encode Rules) define cómo codificar los valores definidos en ASN.1 para ser transmitidos. BER utiliza una técnica denominada TLV(Type, Longitud, Valor) para codificar los datos a transmitir. Para cada dato a transmitir, se envía el tipo de dato, la longitud del dato y el valor. La codificación de cada campo consta de tres o cuatro campos:
Tipo: etiqueta que identifica el valor.
Longitud: del valor en octetos.
Valor : (OPCIONAL) codificado según el tipo.
Ejemplo de codificación En la figura se muestran dos datos a enviar. El emisor quiere enviar la cadena de caracteres " smith” seguida por el valor decimal “259”(en binario 00000001 0000011, en bytes 1 seguido de 3) El primer byte enviado tiene el valor de 4, indicando el tipo de dato que le sigue es un OCTET STRING;(corresponde con la T de la codificación TLV). El segundo byte del flujo contiene la representación ASCII de la letra “s”. Los valores T,L, y V del siguiente item son:
2 (la etiqueta correspondiente a INTEGER)
2(la longitud del entero son dos bytes)
30
Los dos bytes que representan el valor de 259 decimal.
¿Para qué sirve todo esto? A partir de la información que almacenamos en las MIB y que el gestor solicita al agente de los dispositivos a gestionar, se pueden sacar datos interesantes desde el punto de vista de gestión. Por ejemplo en el área funcional de las prestaciones, podemos tener una herramienta, que a partir de los datos que nos envía el agente, nos calcule diferentes medidas de la "salud" de la red y las interfaces de cada dispositivo, como se muestra a continuación:
Ejemplo de aplicaciones con interfaces:
31
Los paquetes descartados y los errores en un interfaz indican problemas en el interfaz o el medio. Porcentaje de errores en un interfaz: % input errors = ifInError/(ifInUcastPkts+ifInNUcastPkts) % output errors = ifOutError/(ifOutUcastPkts+ifOutNUcastPkts) ifIn(Out)Errors: paquetes con error ifIn(Out)UcastPkts: paquetes unicast ifIn(Out)NUcastPkts: paquetes no unicast Porcentaje de paquetes descartados en un interface: similar al caso anterior pero utilizando: ifInDiscards:paquetes descartados de entrada. ifOutDiscards:paquetes descartados de salida. Si ifInDiscard crece al mismo ritmo que ifInUnknownProtos. Los paquetes se descartan por protocolo desconocido. El problema no es del interfaz. Utilización de un interfaz: Total de bytes que pasan por el interfaz por segundo: Bytes/s= [(ifInOctects j –ifInOctects i ) + (ifOutOctects j –ifOutOctects i )]/(j-i) Donde j e i son dos instantes de tiempo. Utilización = (Bytes/s*8)/ifSpeed Indicador de problemas en un interfaz con ifOutQLen: Si crece la longitud de la cola de salida del interfaz, indica problemas en éste. Si permanece con un valor elevado indica congestión de interfaz. Indicador de congestión en la red: Aumenta ifOutDiscard (paquetes descartados sin error conocido) y baja ifOutOctets.
Ejemplo de aplicaciones con IP ip : velocidades de datagramas con distintas circunstancias: ipInReceives: recibidos. ipInHdrErrors/pInAddrErrors: errores de cabecera/dirección ipForwDatagrams: reenviados. ipInUnknownProtos: recibidos con protocolo desconocido. ipInDiscards: recibidos y descartados. ipInDelivers: recibidos (sin error).
32
ipOutRequests: enviados, no se cuentan los reenviados ipOutDiscards: datagramas de salida descartados ipOutNoRuotes: descartados por falta de información de rutas ipRoutingDiscards: entradas de encaminamiento descartadas ipReasmReqds: recibidos necesitando reensamblamiento ipReasmOKs: suficientemente reensamblados ipReasmFails: fragmentos con error en el reensamblado ipFragCreates: fragmentos generados ipFragOks: fragmentos realizados con éxito ipFragFails: fragmentos con errores Ejemplos de aplicaciones con IP para medir las prestaciones:
Porcentaje de datagramas IP recibidos:
Suma: ifInNUcastPkts + ifInUcastPkts por cada interfaz divide ipInReceives por la suma anterior.
Indicador de falta de recursos:
ipInDiscard o ipOutDiscard
Carga del sistema si se produce un gran porcentaje de errores:
% erroresIN = (ipInDiscards+ipInHdrErrors+ipInAddrErrors)/ipInReceives
Un elevado porcentaje de fragmentaciones carga el sistema.
ipRoutingDiscard puede decir si la entidad descarta paquetes por falta de recursos.
Velocidad de reenvío: dos medidas en instantes i y j.
Ip-forwarding-rate = (ipForwDatagram j - ipForwDatagram i )/j-i
Velocidad de paquetes recibidos: dos medidas en instantes i y j.
Ip-input-rate = (ipInReceives j - ipInReceives i )/j-i
Si Ip-forwarding-rate es similar a Ip-input-rate, buenas prestaciones.
Ejemplos de aplicaciones con ICMP: Un alto porcentaje de paquetes icmp procesados reduce el rendimiento: % icmp = (icmpIn(Out)Msgs)/(total de paquetes ). icmpOutSrcQuenchs elevado indica falta de recursos (peticiones que un equipo envía a otro para indicarle, mediante el protocolo ICMP que baje la velocidad de envío de datos, ya que el equipo destinatario, el que envía esta petición, no puede procesar la información por falta de recursos).
Ejemplos de aplicaciones con TCP Indicador de fiabilidad de la red (rechazos de conexión): tcpAttemptFails: nº de intentos fallidos para abrir una conexión.
33
tcpEstabResets: nº de resets para una conexión establecida. tcpRetransSegs: número de segmentos retransmitidos (fiabilidad). tcpInErrs: número de paquetes recibidos con error (indicador de problemas). tcpOutRsts: nº de intentos de hacer reset en una conexión indica un problema que afecta a la fiabilidad. Velocidad de segmentos: recibidos (tcpInSegs) o enviados (tcpOutSegs), es un indicador de rendimiento.
Ejemplo de aplicaciones con UDP udpIn(Out)Datagrams: velocidad de datagramas recibidos (enviados). udpNoPorts: datagramas no enviados a una aplicación puerto válida (contabiliza la “ basura”
procedente de aplicaciones con IP broadcast). udpInErrors: datagramas recibidos con error (indica problemas).
Ejemplo de aplicaciones con la información almacenada sobre SNMP Se contabiliza el porcentaje de paquetes de cada tipo para estudiar su influencia en las prestaciones de la red. _ SNMPIn(Out)Pkts: paquetes SNMP recibidos (enviados). _ SNMPInTotalReqVars: paquetes “Get” y “Get -Next” recibidos. _ SNMPInTotalSetVars: paquetes “Set-Request” recibidos. _ SNMPIn(Out)GetRequests: paquetes “Get -Request” recibidos (enviados). _ SNMPIn(Out)GetNexts: paquetes “Get -Next-Request” recibidos (enviados). _ SNMPIn(Out)SetRequests: paquetes “Set -Request” recibidos (enviados). _ SNMPIn(Out)GetResponses: paquetes “Get -Response” recibidos (enviados). _ SNMPIn(Out)Traps: paquetes “Trap” recibidos (enviados).
Gestión SNMP: Modelo de comunicación En el apartado anterior se ha estudiado el modelo de información, con el que consigue una visión común de los recursos por parte de gestores y agentes. Además, también es necesario definir un mecanismo que permita el intercambio de dicha información, esto es lo que se define en el modelo de comunicación de SNMP. Por lo tanto, el protocolo de gestión de red, SNMP, especifica las normas de comunicación entre un sistema gestor y un agente. 34
Cabría esperar que tuviera una gran cantidad de comandos diferentes para poder realizar un gran número de operaciones diferentes: reinicializar el equipo, cambiar el encaminamiento, activar una línea, etc. Este ha sido el patrón de diseño de muchos protocolos de gestión, que hace que sean poco flexibles para la incorporación de nuevos comandos y sobre todo complejos. El protocolo SNMP se diseñó de una forma totalmente distinta. En vez de definir un gran número de comandos diferentes, se emplea la fórmula de tomaralmacenar (fech-store) sobre el conjunto de valores defin idos en la mib. Por tanto, SNMP emplea principalmente dos comandos, uno para obtener información de las variables, y otro para almacenar información en las variables. Todas las demás operaciones se producen como efectos colaterales de estas dos, por ejemplo. Para reinicializar un dispositivo, pude definirse una variable que contenga el tiempo que ha de transcurrir hasta el próximo reinicio. Si se permite al agente almacenar un cero el dicha variable, el efecto será el mismo que el de enviar un comando específico para reinicializar el dispositivo. La principal ventaja de este diseño reside en la simplicidad y estabilidad del protocolo. Aunque se añadan nuevas variables a la mib el protocolo SNMP permanecerá estable. Recordar que la estrategia que utiliza SNMP es la interrogación periódica de las variables de la MIB por el Gestor y la notificación asíncrona de determinados eventos por el agente. SNMP utiliza como protocolo de la capa de transporte UDP (no confiable, no orientado a conexión) siguiendo con la simplicidad del modelo y reduciendo así el tráfico. 1 Operaciones El protocolo SNMP dispone de las siguientes operaciones:
GetRequest:el gestor realiza una petición de valores específicos de la MIB del agente. GetNextRequest: el gestor realiza una petición del objeto siguiente a uno dado en la MIB del agente, siguiendo un orden lexicográfico. SetRequest: el gestor permite asignar un valor a una variable en el sistema del agente. 35
GetResponse: el agente devuelve los valores solicitados por la operaciones anteriores del gestor. Es la respuesta a un SetRequest, GetRequest o GetNextRequest. Traps: el agente informa de un suceso inusual predefinido.
2 Comunidades Una comunidad es una relación entre un agente SNMP y un conjunto de gestores que define autenticación, control de acceso. La forma de autentificación es utilizar el mismo nombre para la comunidad, en el agente y en el gestor. Cada mensaje (get o set) request de un gestor a un agente incluye un nombre de comunidad, este nombre funciona como un password. Si el agente no tiene definido ese nombre de comunidad el mensaje se contestará con un error de autentificación. Además, cada comunidad tiene asociado un modo de acceso, que puede ser sólo lectura o lectura y escritura. No confundir con el acceso especificado al
definir un objeto. Un objeto puede tener acceso de lectura y escritura, pero si nosotros nos comunicamos con el agente mediante una comunidad que sólo tiene acceso de lectura, no podremos modificar el valor del objeto (aunque esté es escribible). Por defecto la comunidad de sólo lectura tiene como nombre public y la de lectura y escritura es private. Obviamente, lo primero que debemos hacer en nuestra red es cambiar el nombre de las comunidades (porque cualquiera conoce que, por defecto, serán public y private), aún así la versión 1 de SNMP es bastante insegura ya que los nombres de las comunidades no se encriptan en los mensajes con lo que cualquiera que escuche en nuestra red puede hacerse con estos valores. La siguiente imagen es una captura de un mensaje 36
SNMP en el que se puede comprobar que el nombre de la comunidad no está encriptado.
3 Identificación de Instancias Como ya se ha explicado, cada objeto en una MIB tiene un identificador de objeto único, que está definido por la posición del objeto en la estructura del árbol de la MIB. Hay que distinguir entre objeto e instancia, cuando accedemos vía SNMP, lo que solicitamos es una determinada instancia de un objeto, no el objeto en sí. Para los objetos que aparecen en las tablas, el identificador el objeto no es suficiente para identificar la instancia ya que habrá un valor para ese objeto para cada fila de la tabla. Cómo identificar las instancias no está definido en la MIB, es responsabilidad del protocolo de gestión especificarlo. En el caso de SNMP, utiliza una columna de la tabla cuyo valor sea diferente para cada fila como índice, con lo que el identificador de la instancia se forma con el identificador del objeto + el índice. Por ejemplo, para la tabla de rutas IP, en SNMP se ha elegido como columna que no se repite ipRouteDest (la ruta destino). En la siguiente figura hay una captura de una tabla de rutas obtenida por SNMP, el identificador de la instancia IpRouteNextHop de la tercera fila se obtiene añadiendo al identificador del objeto IpRouteNextHop el valor del objeto ipRouteDest de la misma fila. Así, tendremos: 37
Identificador del Objeto IpRouteNextHop: 1.3.6.1.2.1.4.21.1.7 Valor de ipRouteDest en la fila 3: 193.146.96.0 Identificador
de
la
instancia
IpRouteNextHop(fila3):
1.3.6.1.2.1.4.21.1.7.193.146.96.0
Hay casos en los que no existe una única columna que pueda servir como índice, en ese caso se escoge una combinación de columnas q identifique de manera única una fila, p.e en la siguiente figura se muestra la tabla de conexiones TCP, para identificar una instancia se utiliza la combinación de cuatro
columnas
tcpConnLocaladdres+tcpConnLocalPort+tcpC tcpConnLocaladdres+tcpConnLocalPort+tcpConnRemAddress+tcp onnRemAddress+tcpConnRemP ConnRemP
ort como se puede apreciar en la primera columna de la tabla que muestra el identificador (no olvidar que delante iría el identificador del objeto en concreto que se solicita, por lo que el identificador de tcpConnState fila 2 sería: Identificador de objeto tcpConnState: 1.3.6.1.2.1.6.13.1.1 Identificador de la instancia tcpConnState (fila 2): 1.3.6.1.2.1.6.13.1.1.0.0.0.0.135.0.0.0.0.2112 Las instancias de los objetos escalares para seguir la misma convención, se identifican con el identificador del objeto más un cero. Por ejemplo: Identificador del objeto sysDescr: 1.3.6.1.2.1.1.1 Identificador de la instancia sysDescr: 1.3.6.1.2.1.1.1.0 38
4 Formato del mensaje SNMP Un mensaje de SNMP consiste en un identificador de la versión, un nombre de la comunidad SNMP y un PDU (Protocol Data Unit). Toda implementación de SNMP debe soportar las siguientes cinco PDUs:
GetRequest., GetNextRequest, , SetRequest, , GetResponse, Trap
Significado de los campos del mensaje: Versión: versión del protocolo SNMP. Comunity: comunidad que permite la autenticación del gestor ante el agente y el control de acceso.
Type: GetRequest, GetNextRequest, SetRequest, GetResponse, Trap. Request-id: identificador único para cada petición, es el mismo en la respuesta correspondiente. Permite relacionar petición con respuesta y detectar duplicados (esto es necesario hacerlo ya que el protocolo UDP no es confiable) y o peticiones perdidas. Corresponde a la entidad gestora decidir si retransmite una solicitud si no recibe r ecibe respuesta pasado un determinado tiempo.
Error-status: indica si ha ocurrido un error cuando procesa una petición. Los códigos son: noError (0), tooBig (1), noSuchName (3), badValue (4), readOnly (4), genErr (5). o
(0). noError (0). 39
tooBig (1): el tamaño del mensaje de respuesta no cabe en el tamaño máximo de datos UDP impuesto por el sistema.
o
noSuchName(2),: OID no referencia a una instancia o no se encuentra en la vista.
o
BadValue(3): el valor de una variable en variable binding no corresponde con el tipo, longitud esperado.
o
o
readOnly (4)
o
genErr(5): cualquier otro motivo.
Siempre vale 0 en el caso en caso de getRequest, getNextRequest y setRequest.
Error-index: cuando se ha producido un error, puede aportar información, indicando qué instancia de la lista de variablebindings ha producido el error. Vale 0 en caso de getRequest, getNextRequest y setRequest.
Variablebindings: lista de nombres de variables (OIDs) y sus correspondientes valores. Permite solicitar simultáneamente múltiples variables, con el mismo tipo de operación. La respuesta debe ser atómica, es decir, si una petición falla: o
o
No se devuelve el resultado de ninguna. Error-index apunta al name (varible-bindings) que ha producido el fallo. Ejem: si falla el segundo name, error-index = 2.
Los valores son nulos (NULL) en casos como GetRequest, GetNextRequest o GetResponse con error. La siguiente imagen muestra la captura de un mensaje GetRequest en el que se solicita el valor del objeto sysDescr (OID 1.3.6.1.2.1.1.1) y en el que se pueden apreciar todas las cabeceras que añade SNMP.
40
La respuesta a este mensaje se muestra en la siguiente imagen, un mensaje GetResponse en el que en el campo value se ha añadido el valor del objeto descripción del sistema, en este caso un ordenador personal.
Pdu tipo trap: Enterprise: tipo de sistema que genera el trap, basado en sysObjectID. Agent-addr : dirección IP del agente que genera el trap. Generic-trap: código de trap genérico (los códigos se indican a continuación). Specific-trap: código de trap específico.
41
Time-stamp: tiempo desde la última (re)inicialización del agente y la generación del trap (valor de sysUpTime). Generic Traps puede contener los siguientes códigos: coldStart (0): reinicio inesperado debido a algún tipo de fallo. warmStart (1): reinicio en caliente, normalmente programado. linkDown (2): fallo en uno de los enlaces del sistema. linkUp (3): uno de los enlaces se ha iniciado, activado. authenticationFailure (4): se ha recibido un mensaje SNMP con error de autenticación. egpNeighborLoss (5): se ha perdido la relación con un vecino EGP (EGP es un protocolo de routing). enterpriseSpecific (6): se ha producido algún evento específico de empresa (no estandarizado) especificado en specific-trap. Evolución de SNMP Cómo ya se ha dicho anteriormente, SNMP se diseñó como una solución simple y provisional para redes TCP/IP mientras se diseñaba la solución OSI. Entre las mayores ventajas de SNMP se pueden destacar:
Es un protocolo maduro, estándar de facto aceptado por la industria. Está disponible en gran cantidad de productos. Es fácil de implementar y requiere pocos recursos del sistema.
Por otro lado, el mayor inconveniente de SNMP es su escasa seguridad: El nombre de comunidad en la cabecera de cada mensaje SNMP no es suficiente, ya que la identificación de la comunidad viaja tal cual. Por este motivo, muchos fabricantes no implementan la orden Set o si la implementan los administradores de red no la utilizan, con lo que el sistema de gestión se convierte en un sistema de monitorización (obtener información de los dispositivos gestionados). Esta primera versión de SNMP, conocida como SNMPv1 se publicó en 1988 y como ya se ha comentado ha tenido una gran aceptación y se sigue utilizando ampliamente, sobre todo para monitorización.
42
Debido a las deficiencias de seguridad de SNMPv1 en 1993 se publica una versión mejorada SNMPv2, pero el sistema de seguridad que incorpora es demasiado complejo por lo que la versión es rechazada y no se llega a utilizar. En 1996 se publica una revisión de SNMPv2 (RFC1901..1908) que es aceptada pero no incorpora ningún incremento de la seguridad, las principales mejoras introducidas son:
Estructura: además de comunicación agente-gestor aparece el esquema gestor-gestor donde un gestor solicita información a otro y
este responde.
Nuevas PDUs: o getBulkRequest: permite la transferencia de bloques de información
de forma eficiente. informRequest: un gestor envía un informe a otro con OIDs y sus valores. Tiene el mismo formato que setRequest y se responde con getResponse .Amplia los códigos de respuesta de error. Nuevos tipos: Unsigned32, Counter64. o
o
En 1998 se publica SNMPv3, extensión de SNMP que aborda especialmente deficiencias de seguridad.
Se define una arquitectura general de gestión SNMP. Nuevos servicios de seguridad: autenticación, privacidad y control de acceso. RFCs 2271..2275
Lo que antes se denominaba agentes y gestores SNMP ahora se llaman entidades SNMP. Una enti dad SNMP está formada por un “motor SNMP” y “aplicaciones SNMP” como se muestra en la siguiente f igura.
43
Una PDU pasa por el motor SNMP antes de ser enviada vía la capa de transporte adecuada. El motor se divide en cuatro módulos: dispatcher, subsistema de proceso de mensajes, subsistema de seguridad y subsistema de control de acceso.
Dispatcher: responsable de enviar y recibir mensajes. Cuando se recibe un mensaje, determina la versión y lo pasa al Modelo de Procesamiento de Mensajes adecuado, SNMPv3, o v2 o v1.
Subsistema de procesamiento de mensajes: Se compone de uno o varios Modelos de Procesamiento de Mensajes. Se encarga de preparar los mensajes
que deben ser enviados y extraer los datos de los mensajes recibidos.
44
Ejempl o: el Dispatcher recibe un mensaje SNMPv3 válido y determina la
versión: 3
Lo envía al Modelo de Procesamiento de mensajes SNMPv3 donde se extrae el mensaje. Éste llama al Subsistema de Seguridad para descifrarlo (si es necesario) y autentificarlo. Envía el mensaje a la aplicación adecuada
Subsistema de seguridad
Autentifica los mensajes. Cifra/descifra los mensajes
El modelo de seguridad de SNMPv3 se basa actualmente en:
Protocolos de autenticación HMAC-MD5-96 y HMAC-SHA-96: Verificar que el contenido del mensaje no ha sido alterado Verificar la fuente del mensaje Protocolo de privacidad (cifrado) CBC-DES (Cipher Block ChainingData Encrytion Standard) o o
Subsistema de control de acceso:
Determina si se debe permitir o no el acceso a un objeto de la MIB. Actualmente sólo hay definido un modelo de control de acceso: ViewBased Access Control Model (VACM).
Cuando se procesa una operación Get,Get-Next, Get-Bulk o Set hay que comprobar que se tiene acceso a los objetos referenciados.
Monitorización Remota RMON
45
La información que se obtiene con la MIB-II definida para SNMP es local a cada dispositivo gestionado donde se ejecuta el agente. Si queremos obtener información acerca de una red como un todo hay que hacer sucesivas consultas individuales a cada nodo de la red. Esto supone un gran consumo de recursos (tiempo de procesamiento en agentes y el gestor, y ancho de banda consumido por las consultas/respuestas SNMP). Con esa motivación surge RMON. RMON consiste básicamente en la definición de una MIB de monitorización remota como extensión a la MIB-II. Además, para poder monitorizar la red de forma global, en cada subred se coloca un monitor RMON (también denominado agente RMON o sonda) que recogerá y analizará (tiene más capacidades que un agente SNMP) información
de
gestión,
principalmente
estadísticas del tráfico sobre la red y las pondrá a disposición de las estaciones de gestión. Resaltar que el protocolo de comunicación entre la sonda y el sistema gestor sigue siendo SNMP. La sonda puede ser un dispositivo dedicado (hardware) o una función disponible en un sistema (por ejemplo software instalado en un switch, es muy habitual que los switch, los que tienen ya un poco de nivel, implementen una sonda o agente RMON) Se han definido dos MIBs para monitorización Remota:
RFC1757 (2/95): MIB de monitorización remota. RFC2021 (1/97): MIB-2 de monitorización remota.
Como se puede apreciar en la figura la MIB de RMON cuelga del nodo mib-2. Conclusión Como resumen se puede afirmar que, después de dos décadas de existencia, la gestión SNMP es ampliamente utilizada y aceptada. Sin embargo, su uso más extendido es el de monitorización, debido en gran parte a la falta de seguridad de su primera versión que hizo que se limitará el uso de SNMP a la 46
recolección de información omitiendo las utilidades de modificación y configuración. Aunque en la versión tres la seguridad ha sido ampliamente reforzada, su aceptación y uso ha sido menor debido a su mayor complejidad.
Caso Práctico - Gestión de Internet: SNMP
El principal objetivo de este caso es trabajar con ejemplos los principales conceptos vistos en teoría, así se pretende que el alumno entienda la estructura del árbol OID (Object Identifier) donde se almacenan de forma estructurada los objetos a gestionar; se familiarice con los objetos de la mib-2, examine la definición de varias mibs recordando la sintaxis y tipos de datos de SMI; visualice y compile mibs privadas; active y configure un agente SNMP; maneje dos sistemas gestores SNMP, realice capturas de los mensajes intercambiados entre agentes y sistema gestores para comprobar la estructura de los mensajes SNMP, etc. Equipamiento para realizar el caso2
Para realizar la gran mayoría del caso práctico sólo es necesario un equipo con sistema operativo Windows en el que se instalará tanto el agente como los sistemas gestores. El problema de utilizar un solo ordenador viene a la hora de capturar los mensajes intercambiados entre ambos, el analizador de protocolos de red que utilizamos, Wireshark, no puede capturar mensajes recibidos y enviados en el mismo ordenador (una gracieta del Windows con la tarjeta de loopback http://wiki.wireshark.org/CaptureSetup/Loopback). Para los que sólo dispongáis de un equipo hemos guardado la captura para que podáis visualizarla si queréis, se os indica a lo largo del caso).
2
Los linuxeros que no quieran tocar Windows pueden hacer la práctica utilizando agentes SNMP de Linux y el mg-soft mib-browser tiene versión de Linux con lo que todo lo que se hace con el getif (sólo tiene versión windows) lo pueden hacer con el mg-soft mib-browser.
47
Resumiendo, el que disponga de más de un ordenador instalará en equipos diferentes el agente SNMP y los sistemas gestores. El que no los tenga puede virtualizar otro Windows en su equipo (aunque para este caso práctico no merece la pena) o simplemente en vez de capturar los mensajes utilizar nuestra captura. Agente SNMP en Windows
Obviamente para poder gestionar un dispositivo por SNMP es necesario que el dispositivo sea gestionable por SNMP, es decir que disponga de un agente SNMP instalado. Puede que muchos de vosotros tengáis en vuestro entorno de trabajo dispositivos con agentes SNMP (routers, impresoras, switches, etc.) pero para asegurarnos de que la mayoría podáis hacer el caso hemos elegido como dispositivo a gestionar un ordenador con el sistema operativo Windows (en principio con cualquier versión a partir del 2000). Para instalar un agente SNMP en Windows (si no lo tenéis ya instalado). Windows 2000/XP: 1. Desde el panel de control->agregar o quitar programas>agregar o quitar componentes de Windows 2. Seleccionar herramientas de administración y supervisión. 3. Seleccione el protocolo SNMP. 4. Termina la instalación. Windows Vista: 1. Desde el panel de control->programas y características>activar o desactivar las características de Windows>Característica SNMP 2. Termina la instalación. Una vez instalado para configurar las opciones e iniciar/detener el agente (las capturas pertenecen a Windows XP): 1. Desde el panel de control-> Herramientas administrativas-> Servicios-> Hacer clic en Servicio SNMP.
48
2. Aparecen las opciones de configuración del agente SNMP
3. En la pestaña seguridad se configuran los nombres de las comunidades y las direcciones IP o nombres de host que se pueden comunicar con nuestro agente. 3
3
Para mejorar la seguridad de nuestro sistemas es recomendable usar nombres de comunidad distintas de public y private ya que son las que traen por defecto la mayor parte de los sistemas gestores y además, permitir el acceso a nuestro agente sólo al equipo desde el que gestionamos la red, donde tengamos instalado el software de gestión (en nuestro caso práctico agente SNMP (dispositivo a gestionar) y sistema gestor coinciden).
49
Añadir public como comunidad de lectura y private como comunidad con permisos de lectura y escritura. Como medida de seguridad adicional indicaremos la dirección IP de los equipos que se pueden comunicar con nuestro agente, en este caso añadir la dirección IP donde instalaréis el sistema gestor (getif).
En la pestaña capturas indicamos como nombre de comunidad public y destino de la captura la IP del sistema gestor. Cuando se produzca un evento de los contemplados en SNMP el agente enviará un trap al sistema gestor.
50
4. Iniciar el servicio.
Ya tenemos un dispositivo a gestionar por SNMP, ahora vamos a instalar una herramienta sencilla que nos permita comunicarnos con el agente, un sistema gestor SNMP muy básico, getif. GETIF (http://www.wtcs.org/SNMP4tpc/getif.htm)
Getif es un programa freeware para Windows, que nos permite comunicarnos
mediante
el
protocolo
SNMP
con
dispositivos
(ordenadores, routers, switch, etc) que contengan un agente SNMP. Lo tenéis disponible en la plataforma, en herramientas, el fichero getif1.zip. El proceso de instalación es muy simple, es un ejecutable. En la siguiente figura se muestra la ventana de inicio de getif, en el que se puede comprobar que aparece por defecto como nombre de comunidad de lectura public y de escritura private. 51
Introducir en getif->Host Name la dirección del ordenador en el que has configurado el agente SNMP y pulsar el botón Start , si aparece “no SNMP Response from …” es que en dicho ordenador no hay instalado un agente SNMP o no está iniciado. Si getif conecta correctamente con el agente en la parte inferior aparece SysInfo variables OK y muestra en la pantalla los objetos de la rama system de la mib-2 (nombre del sistema, contacto, descripción del sistema, etc.) y el número de interfaces que tiene el dispositivo
52
Ir a la pestaña Mbrowser que permite visualizar y en algunos casos modificar los valores de los objetos gestionados.
Desplegar e inspeccionar el árbol, comprobar que la estructura coincide con la vista en el temario, la mib-II (RFC1213). 53
En la siguiente imagen se ha obtenido el número de interfaces del dispositivo. Observar que el identificador de la instancia, al ser un objeto escalar, se forma, como se vio en teoría, añadiendo al identificador del objeto un cero.
Si pulsáis Walk sobre un nodo que contiene una tabla, por ejemplo la tabla de interfaces, getif solicita todos los valores de la tabla:
54
Obtener:
El nombre del equipo. La tabla de rutas (IP). El número de mensajes ICMP que ha recibido el equipo. La tabla de conexiones TCP. Número de mensajes SNMP recibidos.
Hasta ahora estamos obteniendo información (monitorizando) el dispositivo a gestionar, si queremos
modificar su configuración
utilizaremos el botón Set que hará que getif envié mensajes SetRequest al agente. Vamos a aprovechar para recordar la estructura de un mensaje SNMP para ello utilizaremos el capturador de paquetes Wireshark, es de libre distribución y de esta manera también trabajamos con otra herramienta muy utilizada en gestión de redes, los capturadores/analizadores de paquetes. Wireshark es de libre distribución y lo podéis descargar de su página Web: 55
http://www.wireshark.org/download.html (bajar la versión 1.2.11 ya que en la última versión tiene un bug a la hora de decodificar los mensajes SNMP), también lo tenéis disponible desde la plataforma en herramientas. El proceso de instalación es muy sencillo, debéis marcar la opción de instalar Winpcap, aplicación necesaria para que Wireshark pueda capturar los paquetes. En la ventana principal de la aplicación se mostrarán los paquetes capturados. Wireshark muestra la información capturada en tres secciones principales.
En la primera sección aparece un listado de los paquetes capturados con su información más relevante. En la segunda sección podemos observar los detalles del mensaje seleccionado en la sección 1. En la última sección se muestran los paquetes en bruto, es decir, tal y como fueron capturados por la tarjeta de red. Para capturar paquetes, menú Capture->interfaces, aparece una ventana con las tarjetas de red disponibles, pulsáis start sobre la tarjeta con la que estéis trabajando, en la figura se selecciona el cable de red Ethernet.
56
Cuando queráis terminar la captura de paquetes pulsáis el botón Stop the running live capture y buscáis entre los mensajes capturados los que son de vuestro interés, en este caso serán todos con protocolo SNMP.
Cómo habíamos dicho vamos a modificar la configuración, por ejemplo modificando el nombre de la persona de contacto. Para ello seleccionamos el objeto sysContact, escribimos en nuevo nombre en el recuadro de abajo y pulsamos el botón Set (no olvidéis arrancar la captura de mensajes antes de pulsar el botón para poder visualizar el mensaje que envía getif al agente y el de respuesta del agente).
57
Para comprobar que el valor se ha cambiado pulsar el botón Walk para obtener el nuevo valor de sysContact.
En la figura podéis comprobar las cabeceras que añade SNMP, versión, comunidad (en este caso ha incluido private ya que es una operación de escritura), es un set-request, el identificador de 58
conversación (request-id) y en variable-bindings el OID del objeto seleccionado (sysContact) y el valor que queremos que tome (Carmen). También podéis comprobar que el puerto destino es el 161 que es en que escuchan por defecto los agentes SNMP. Para los que no puedan capturar el mensaje pueden abrir mi captura con el Wireshark, fichero set_syscontact.pcap (en la plataforma dentro de capturas_wireshark.zip). A continuación vamos a cambiar el nombre a la comunidad de escritura de nuestro agente SNMP, vamos a el panel de control-> Herramientas administrativas-> Servicios-> Hacer clic en Servicio SNMP . En la pestaña seguridad cambiamos el nombre de la comunidad de lectura y escritura, por ejemplo ponemos secwrite . Recordar que en la primera pestaña de getif introducimos los nombres de las comunidades con las que queremos que nuestro sistema se comunique con el agente y que tenemos puestas las de por defecto, public y private. Procedemos a repetir el ejercicio anterior, cambiar el nombre de la persona de contacto. Comprobamos que ahora no podemos hacerlo ya que el nombre de la comunidad no es el correcto. Al no coincidir la comunidad de escritura del sistema gestor, getif, que es private con la del agente (secwrite), el agente no modifica el valor del objeto y además envía un trap al sistema gestor avisándole del fallo de autentificación, lo que puede alertar al responsable de la red de que hay algún intruso intentando hacer travesuras en la red. En la imagen se muestra la captura del trap, los que no podáis realizar la captura podéis cargar mi captura en Wireshark (fichero trap_bad_comunity). Se observa que el puerto destino es el 162, en el que el sistema gestor escucha la recepción de traps. Y la estructura 59
de las cabeceras SNMP son las vistas para un trap: Enterprise 311.1.1.3.1 (es el identifcador del agente SNMP de Microsoft Windows), la dirección del agente que ha enviado el trap y el tipo de trap que en este caso es fallo de autentificación.
Para los que no puedan capturar el mensaje pueden abrir mi captura con el Wireshark, fichero trap_bad_comunity.pcap (en la plataforma dentro de capturas_wireshark.zip). Con el Wireshark vemos que el uso de las comunidades es una medida de seguridad muy débil ya que el nombre de la comunidad viaja sin encriptar, cualquier analizador de paquetes puede leer nuestro nuevo nombre de comunidad. Por eso siempre es recomendable si utilizáis la versión 1 de SNMP no dejar las comunidades por defecto. (No os olvidéis de volver a poner private en la comunidad de lectura y escritura de vuestro agente).
60
Con el siguiente ejercicio vamos a reforzar otro concepto visto en la teoría: para que un sistema gestor pueda acceder/modificar la información de los objetos gestionables de un agente tiene que tener cargada la mib que define la estructura de esos objetos gestionables. A continuación, vamos a intentar obtener a través de getif el software instalado en el equipo que estamos gestionando. Explorar el árbol de getif buscando algún objeto que represente dicha información.
El resultado de la exploración es que con las mibs que tiene cargadas actualmente getif no se puede acceder a esa información aunque el agente la tenga disponible. En la carpeta C:\Archivos de programa\Getif 2.2\Mibs podéis comprobar las mibs que tiene cargadas getif. En esa C:\Archivos de programa\Getif está el archivo MIBS-2K.ZIP, donde se almacenan un grupo de mibs adicionales. Abrir el fichero RFC1514-HOST.MIB con un editor de texto, p.e. editplus, y comprobar los objetos definidos en esta mib, así también os familiarizáis con la sintaxis y tipos de datos definidos en SMI vistos en teoría.
61
Cerrar el programa getif, extraer del zip el fichero RFC1514HOST.MIB en la carpeta Mibs y borrar el fichero .index y reiniciar getif. Al explorar de nuevo el árbol OID podéis comprobar que debajo de mib-2 aparece un nuevo nodo host .
Desplegando el árbol si solicitamos el valor del objeto hrSWInstalledName obtendremos el software instalado en nuestro equipo.
62
Luego ahora podemos acceder/modificar toda la información definida en esta mib. Familiarizarse con la MIB-host, obtener:
Los procesos/software que se están ejecutando en el equipo El número de cuentas de usuario que tiene el equipo. Etc.
En http://www.wtcs.org/SNMP4tpc/FILES/Tools/SNMP/getif/GETIFMIBS.ZIP hay una recolección de más de 600 MIBs disponibles, de CISCO, ATM, etc. Aunque lo más recomendable es que cuando tengáis un dispositivo gestionable por SNMP, por ejemplo un router cisco 3640, del que no tenéis la mib con los objetos que se pueden gestionar los bajéis de la web del fabricante (las mibs de cisco las tenéis disponibles en http://www.cisco.com/public/swcenter/netmgmt/cmtk/mibs.shtml), en la parte de teoría tenéis un enlace donde se indican donde tienen las mibs cisco, hp, etc. Recordar que las mibs de empresas privadas no aparecen en el árbol debajo
de
mgmt,
sino 63
que
aparecen
en
.iso.org.dod.internet.private.enterprises como se puede ver en la figura.
Getif también permite visualizar en una gráfica como van variando los valores que toman los objetos (cuyo valor es de tipo entero). Para visualizar el valor de un objeto: 1. Seleccionar 2. 3. 4. 5. 6.
en
el
árbol
el
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInUcastPkts).
objeto
(por
ejemplo
Pulsar wal k. Pulsar sobre el valor obtenido en la ventana inferior. Pulsar sobre el botón añadir al gráfico. Cambiar a la pestaña graph Presionar start para que empieze a mostrar los valores que van tomando los objetos seleccionados (accede a través del navegador a diferentes sitios Web para generar tráfico)
64
Getif, es un programa gratuito que nos ha permitido ver en la práctica gran parte de los contenidos desarrollados en la teoría, a continuación vamos a ver otro sistema gestor, más profesional, con un entorno más amigable a la hora de visualizar los objetos de las MIBs (se nota especialmente en el caso de las tablas) y con más opciones, por ejemplo puede monitorizar varios agentes simultáneamente, guardar los datos en ficheros logs, mostrar los traps que envían los agentes, mostrar todos los agentes SNMP activos en nuestra red, soporta SNMPv1, v2 y v3, etc. MG-SOFT MIB BROWSER
El programa MG-SOFT Mib browser permite (entre otras cosas) explorar de forma amigable la estructura de una MIB, enviar peticiones (get/set) a un agente SNMP, mostrar los traps recibidos. Aunque es un programa de pago tiene una versión de evaluación (pasada el periodo de evaluación podéis seguir utilizándolo si 65
cambiáis la fecha del ordenador) que tiene algunas limitaciones frente a la versión con licencia. Lo podéis descargar de http://www.mg-soft.com/index.html o de la plataforma en herramientas. Al instalarlo os pedirá una licence key que podéis encontrar también en la plataforma. Arrancar el programa PROGRAMAS->MG-SOFT MIB BROWSER->MIB BROWSER. En la siguiente figura se muestra el entorno de trabajo:
El MIB-Browser tiene 4 áreas principales que están remarcadas en la figura. 1. El primer área contiene al Menu principal con los submenus (File, Edit,.. Help). 66
2. El segundo área está constituida por un menú basado en iconos. Estos sirven para agilizar algunas de las tareas más utilizadas del MIB-Browser. 3. La tercera área es el área de trabajo y contiene tres pestañas que permiten realizar 3 actividades distintas (Query, MIB, Ping). 4. Finalmente, el cuarto área es la barra de estado. En esta área se presenta al usuario de forma visual información acerca del estado de las conexiones y de las peticiones.
Dentro del área de trabajo, nos interesan principalmente las 2 primeras pestañas: Presentación de las consultas
El área de consulta (Query) es la que está capturada en la figura anterior. La finalidad de esta área de trabajo es la de permitir al usuario explorar de forma gráfica (abriendo / cerrando los nodos del árbol) los objetos de una MIB. Hay que indicar la dirección del agente del que queremos obtener/modificar información en el campo “Remote SNMP agent”. Una vez que se ha escrito la dirección, la
exploración es iniciada pulsando la tecla de retorno de carro o presionando el botón Contact Remote Agent del menú de iconos. Si contactamos correctamente o no con el agente lo vemos en la parte inferior de la ventana, en la barra de estado. Una vez que se ha contactado con un agente, se puede pedir información de los objetos de la MIB primero seleccionándolos y pulsando el botón de información o con el botón derecho del ratón (obtener el identificador de objeto, el valor del objeto, una vista amigable de las tablas, etc..). También se puede modificar los valores de los objetos que son escribibles. Selección de la mib
Cómo su nombre indica esta área sirve para que el usuario seleccione las MIBs con la que se va a trabajar(recordar que para que un
67
sistema gestor pueda obtener información sobre una mib tiene que
tenerla cargada). El aspecto de esta área es el siguiente: Desde la pestaña MIB puedes ver: 1.
Las MIBs que tiene el programa cargadas (en la versión de evaluación sólo puedes tener 3 mibs cargadas simultáneamente). 2. Las MIB de las que dispone el programa pero no están cargadas.
Desde esta pestaña podemos cargar las MIBs que necesitemos mediante las flechas de arriba y abajo (controles de selección de MIB). Por ejemplo probar a cargar la mib HOST-RESOURCES-MIB (necesitarás antes descargar una de las que hay, quita la SNMPv2), comprobar el antes y el después en la ventana de exploración de la MIB, al igual que con el getif hasta que no cargamos esta MIB no podemos acceder a los objetos gestionables del tipo, software instalado, software ejecutándose, capacidad de almacenamiento, cuentas de usuario, etc.
68
Conéctate mediante el mib browser al agente de Windows con el que trabajamos anteriormente, explora las distintas opciones del programa para acceder y visualizar la información del agente remoto. Por ejemplo obtén la descripción del sistema.
69
La tabla de interfaces:
Como se puede apreciar el entorno es mucho más amigable que el anterior (también es de pago).
70
Remote SNMP Agent Discovery
Esta herramienta permite encontrar todos los agentes que existan dentro de un rango de direcciones IP. En la figura se muestra los agentes SNMP que están activos en mi red. Si estáis en el trabajo podéis probar a introducir un rango de IPs de vuestra red para comprobar si hay más agentes SNMP aparte del vuestro.
SNMP Trap ringer console
Esta utilidad permite visualizar los traps que nos envían los agentes SNMP de nuestra red. Para ello, como ya vimos, tenemos que configura el agente SNMP para que envié los traps a la IP de nuestro sistema gestor.
71
Abrir la ventana SNMP trap ringer console. Para probarlo podéis desconectar el cable de la tarjeta de red del ordenador donde está el agente y volver a conectarla, deberían apareceros dos traps como se puede apreciar en la siguiente figura. También podéis hacer algún set o get con un nombre comunidad erróneo y os llegará un trap de fallo de autentificación. En la versión de evaluación sólo podréis visualizar 5 traps (salvo que cerréis y volváis a abrir la aplicación).
2 COMPILAR LAS MIBS
Si necesitáis una MIB que no venga con el software tendréis que descargarla de la página del fabricante y antes de cargarla al sistema hay que transformarla a un formato específico para las mibs que utiliza mg-soft, denominado smidb, a esta operación se le denomina compilar la mib.
Descargar una mib de : http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml 72
Frecuentemente para compilar una MIB son necesarios objetos definidos en otras MIBs, por lo que yo os he bajado ya dos MIBs de Cisco para el que no quiera tener que buscar. Los tenéis en la plataforma, fichero cisco-mibs. Desde esta página se pueden acceder a las mib desarrolladas por cisco ordenadas por producto y versión del sistema operativo. Abrir el fichero para seguir familiarizándoos con la sintaxis del lenguaje y la estructura de los objetos. Compilar las mib. Desde el menú: Action-> Run mib compiler. Una vez arrancado el mib compiler:
Abrir el fichero CISCO-SYSLOG-MIB.my Compilar, os pedirá la ubicación del otro fichero. Guardarlos a la carpeta que aparece por defecto.
Volver a mib browser, cargar en el mib browser la mib CISCO-SMI y CISCO-PROCESS-MIB, para actualizar la vista de las mib disponibles para cargar: Action ->refresh mib modules. Comprobar, desde la pestaña de navegación, que tenéis disponibles las MIBs. Recordar que las MIBS privadas se cargan debajo del nodo private->enterprises. No podréis obtener información de estos objetos ya que nuestro agente no está gestionando un router (no contempla esos objetos). Si tenéis algún dispositivo distinto de un ordenador gestionable por SNMP podéis probar a descargar sus MIBS y obtener información.
73
Para quién esté interesado en profundizar más en el funcionamiento de MG-SOFT MIB BROWSER tiene a su disposición el manual de ayuda en la plataforma y en la página web de la herramienta. Por ejemplo se pueden configurar perfiles de varios agentes para no tener que configurarlo cada vez que accedamos a ellos:
Otra herramienta te permite configurar múltiples operaciones (get, getnext, set, trap, etc) y puedes ejecutarlas en un agente concreto con un simple click. El estado de las operaciones se muestra en el panel de la izquierda y los valores obtenidos en la parte izquierda de abajo. Esta herramienta es muy útil para tareas repetitivas.
74
También tiene disponible una herramienta (Performance Graph window) que te permite obtener gráficos de los objetos numéricos.
75
