Repositorio Institucional de Documentos

Universidad de Zaragoza PROYECTO FIN DE CARRERA Ingenier´ıa de Telecomunicaci´on Implementaci´on autom´atica de un agente SNMP a partir de la definici´on formal de su MIB Juan Carlos Arribas Arribas Director: Nelia Lasierra Beamonte Ponente: ´ Alvaro Alesanco Iglesias Septiembre 2012 Curso 2011-2012 Agradecimientos En primer lugar, quiero dar las gracias a ´ Alvaro por brindarme la idea y la posibilidad de realizar este Proyecto Fin de Carrera en un ´areaquemellam´omucho la atenci´on durante las clases en su asignatura. No quiero ni mucho menos olvidarme de Nelia. Ella me ha ayudado en todo momento, me ha sacado siempre que ha podido de los momentos en los que me quedaba atascado y tambi´en me ha dado ´animos y me ha metido presi´on para sacar siempre lo mejor de m´ı. Siempre te estar´e muy agradecido. A mis padres y hermano, los cuales siempre me han apoyado y, sobre todo, me han aguantado en mis momentos de mayor estr´es y han sido un pilar fundamental durante toda la carrera. A mis amigos, por su inter´es y apoyo, por sus consejos, por regalarme el ocio y diversi´on aunque no os haya podido hacer mucho caso durante estas ´ultimas semanas: Jose yRicar, y en especial, Tere, la cual ha tenido que soportar m´as que nadie mi estr´es e historias aburridas de trabajo. Amiscompa˜neros de la universidad, quienes siempre me han apoyado y me han dado tantos buenos momentos a lo largo de la carrera y tambi´en durante este proyecto que hab´eis hecho que no extra˜nara mi ciudad: Diego,Aguilar,Sergio,Fran,Lourdes, Sandra,Pablo... y muchos otros que hab´eis estado conmigo en todo momento. “Implementaci´on autom´atica de un agente SNMP a partir de la definici´on formal de su MIB” RESUMEN En este proyecto se ha desarrollado un conjunto de herramientas que facilitan el desarrollo de agentes SNMP (Simple Network Management Protocol) as´ı como de las MIBs (Management Information Base) que implementa a partir de su definici´on formal. El sitema consta de tres bloques independientes entre s´ı, pero que est´an dise˜nados para funcionar conjuntamente. El primer bloque consta de un interfaz gr´afico con las herramientas necesarias para poder dise˜nar una MIB. El segundo bloque se encarga de transformar la definici´on formal de una MIB cualquiera en una estructura de tablas gen´ericas para su almacenamiento en una BBDD (base de datos). El ´ultimo bloque permite desarrollar un agente SNMP para establecer comunicaciones SNMP con un gestor externo y as´ı facilitar a este la gesti´on de la MIB implementada en la BBDD. Para la utilizaci´on de todos estos bloques se han implementado tres interfaces (uno por bloque) para que su uso por el usuario sea f´acil e intuitivo. El interfaz del primer bloque (MIB Builder) sirve para crear la definici´on formal de la MIB de forma gr´afica para evitar el empleo por parte del usuario del lenguaje SMI (Structure of Managed Information). El interfaz del segundo bloque (BBDD Creation) permite al usuario introducir el archivo de texto generado anteriormente con la definici´on formal de la MIB, e introducir la informaci´on de configuraci´on de la BBDD creada para que se genere la estructura de tablas gen´ericas en la BBDD que dan soporte a dicha MIB. Por ´ultimo, el interfaz del tercer bloque (Agente SNMP) permite gestionar las cuentas de usuario que tendr´an acceso al agente, adem´as de establecer comunicaciones SNMP con cualquier gestor externo mediante las tres versiones que se definen en la arquitectura. Finalmente, se ha realizado una fase de pruebas para verificar el correcto funcionamiento del sistema propuesto. Utilizando el primer bloque se han dise˜nado MIBs conocidas y nuevas demostrando as´ı la funcionalidad del interfaz para obtener su definici´on formal. Para demostrar el correcto funcionamiento del segundo bloque se han implementado tanto MIBs nuevas como MIBs conocidas y posteriormente mediante la utilizaci´on de un gestor comercial se han establecido comunicaciones SNMP con el agente desarrollado y accedido a la informaci´on contenida en las MIBs creadas. Se puede concluir que el conjunto de bloques desarrollado constituye un sistema integrado para el desarrollo de agentes partiendo de la idea inicial de una MIB, ya que se proporcionan todas las herramientas necesarias para conseguir este prop´osito. Tambi´en constituye una manera de implementar agentes SNMP de una manera est´andar donde la interoperabilidad con los gestores est´a garantizada. ´ Indice general 1 Introducci´on y Objetivos 1 1.1 Introducci´on ................................... 1 1.2 Estado del Arte ................................. 3 1.3 Propuesta .................................... 4 1.4 Objetivos .................................... 5 1.5 Materiales .................................... 7 1.6 Organizaci´on de la memoria .......................... 7 2 Caracter´ısticas de la arquitectura SNMP y lenguaje SMI 9 2.1 La arquitectura SNMP ............................. 9 2.1.1 Entidades SNMP ............................ 10 2.1.2 Mensajes SNMP ............................ 10 2.1.3 Bases de datos en SNMP: MIB .................... 12 2.1.4 Seguridad en SNMP: SNMPv3 .................... 13 2.2 El lenguaje SMI ................................ 15 2.2.1 Evoluci´on del lenguaje SMI ...................... 16 2.2.2 Estructura de una MIB con SMI ................... 17 3 Desarrollo Tecnol´ogico: Bloques implementados 21 3.1 Descripci´on general ............................... 21 3.2 MIB Builder ................................... 23 3.2.1 Dise˜no .................................. 23 3.2.2 Implementaci´on ............................. 25 3.3 BBDD Creation ................................. 26 3.3.1 Algoritmo de conversi´on ........................ 26 3.3.2 Implementaci´on ............................. 29 3.4 Agente SNMP .................................. 32 i ii ´ INDICE GENERAL 3.4.1 Implementaci´on ............................. 32 4 Pruebas y Resultados 35 4.1 Dise˜no de una MIB ............................... 35 4.2 Implementaci´on de la BBDD de una MIB .................. 38 4.2.1 Pruebas del bloque BBDD Creation ................. 39 4.3 Creaci´on del agente ............................... 40 4.3.1 Conexi´on versi´on 1 y 2c ........................ 42 4.3.2 Conexi´on versi´on 3 ........................... 43 5 Conclusiones y l´ıneas futuras 45 5.1 Conlusiones ................................... 45 5.2 L´ıneas de futuro ................................ 47 Bibliograf´ıa 49 AAcr´onimos 51 BGu´ıa de usuario para la creaci´on de una MIB con el MIB Builder 53 C Tablas de la BBDD 57 C.1 Estructura gen´erica de una Tabla Secundaria ................ 57 C.2 Estructura gen´erica de una Tabla de Control ................ 58 C.3 Estructura gen´erica de una Tabla de Datos ................. 59 C.4 Ejemplo: Tablas generadas para la MIB mib-2 ............... 59 D Insertar valor en agente SNMP 63 D.1 Insertar valor en tabla secundaria ....................... 63 D.2 Insertar valor en tabla de control (sin STATUS) ............... 63 D.3 Insertar valor en tabla de control (con STATUS) .............. 63 E Diagramas de flujo de la interacci´on agente SNMP - MIB 65 FGu´ıa de usuario del interfaz Agente SNMP 71 G Diagrama de Gantt 75 ´ Indice de figuras 1.1 Proceso del problema a resolver. ....................... 2 1.2 MIB Builder comerciales. ........................... 3 1.3 Esquema general propuesto y la interacci´on entre los bloques. ....... 5 2.1 Comunicaci´on SNMP entre agente y gestor. ................. 12 2.2 Estructura en ´arbol de una MIB. ....................... 13 2.3 Inicio comunicaci´on SNMPv3 (Caso AuthPriv). ............... 14 2.4 Definici´on del Objeto sysUpTime........................ 18 2.5 Definici´on de la Tabla atTable......................... 18 2.6 Definici´on de los campos de la Tabla atTable................. 18 3.1 Workflow del problema a resolver. ...................... 22 3.2 Zonas del Interfaz MIB Builder......................... 23 3.3 Definici´on del grupo sysUpTime........................ 24 3.4 Interfaz MIB Builder. ............................. 25 3.5 Funciones del algoritmo de conversi´on. .................... 26 3.6 Partes a almacenar de la MIB. ........................ 27 3.7 Relaci´on entre compontes y tablas creadas. ................. 28 3.8 Relaci´on entre definici´on formal y tablas creadas. .............. 29 3.9 Tablas creadas para la MIB propuesta. .................... 30 3.10 Interfaz BBDD Creation............................. 31 3.11 Proceso de env´ıo y recepci´on de un mensaje entre gestor y agente. .... 32 3.12 Interfaz Agente SNMP.............................. 33 4.1 Definici´on del nodo inicial mgmt........................ 35 4.2 Definici´on del Grupo atNetAddress....................... 36 4.3 MIB definida con ´exito. ............................ 36 4.4 Introducci´on de la MIB creada en un gestor. ................. 37 iii 21.1. Introducci´on Dadas las ventajas de gesti´on que ofrece SNMP, este proyecto fin de carrera se basa en el estudio y desarrollo de herramientas de esta arquitectura. Esta es hoy en d´ıa la m´as popular pero existen otras como pueden ser CORBA [2] (Common Object Request Broker Arquitecture) cuya caracter´ıstica principal es que esta arquitectura nos permite comunicar aplicaciones definidas en diferentes lenguajes y ejecutados en distintas plataformas de manera trasparente sin tener que realizar ning´un proceso intermedio. Otro protocolo existente actualmente es NETCONF [3], el cual se basa en XML [4]. A pesar de la popularidad y simplicidad de la arquitectura SNMP para gestionar redes, la implementaci´on de nuevas MIBs no es una tarea sencilla para los desarrolladores. Adem´as, hoy en d´ıa no existe una organizaci´on interna est´andar de las bases de datos que dan soporte a las MIBs y cada desarrollador dise˜na su propia base de datos de acuerdo a las caracter´ısticas espec´ıficas de su MIB. SNMP puede utilizarse para gestionar otros dispositivos distintos a los t´ıpicos de una red de comunicaciones como un switch o un hub y permite por tanto que se pueda utilizar para otros servicios de gesti´on. Por lo tanto el estudio de la automatizaci´on de este proceso resulta de gran inter´es. Un ejemplo, es el uso en dispositivos m´edicos para el intercambio de informaci´on de un determinado equipo situado en casa de un paciente al centro hospitalario. Una vez generada la estructura de tablas de la BBDD es necesario un m´odulo que facilite la interacci´on entre un agente SNMP y la BBDD creada. Este agente establecer´a comunicaciones SNMP con un gestor externo. Una vez recibidos los mensajes de petici´on de este, el agente interactuara con su MIB (BBDD creada) para darle a dicho gestor la informaci´on solicitada. La problem´atica de implementar MIBs en BBDD y agentes se traslada tambi´en a la definici´on formal de las mismas, ya que aunque existen diversos programas que te permiten generar el c´odigo de la definici´on formal de una MIB de una manera gr´afica e intuitiva, dicho software no es de libre distribuci´on y las licencias para su utilizaci´on son costosas para cualquier dise˜nador independiente que no trabaje en una gran empresa que se permita su adquisici´on. Por esto y porque es mucho m´as f´acil crear la definici´on de la MIB con ayuda de su visualizaci´on gr´afica, se propone implementar una herramienta que disponga de las funcionalidades de un MIB Builder, un BBDD Creation (algoritmo para el desarrollo de una BBDD gen´erica) y un agente que interact´ue con este ´ultimo modulo. Figura 1.1: Proceso del problema a resolver. Cap´ıtulo 1. Introducci´on y Objetivos 3 En la Figura 1.1 se muestra el proceso a desarrollar. Lo que se pretende es ofrecer un entorno de gesti´on completo basado en SNMP: una vez dise˜nada la MIB con el MIB Builder, el BBDD Creation generar´a la estructura de la BBDD con la cual interaccionar´a el agente SNMP para ofrecer la informaci´on solicitada a un gestor externo SNMP. 1.2 Estado del Arte Actualmente existen empresas que desarrollan MIB Builders como son MG-SOFT [5] y NuDESIGN [6]. Estos programas tienen una versi´on de evaluaci´on del producto, con la cual se ha trabajado para investigar su funcionamiento con el fin de que nos sirviera de punto de partida a la hora de realizar nuestro propio MIB Builder. Una visualizaci´on de como son estos dos programas, se muestra en la Figura 1.2. Figura 1.2: MIB Builder comerciales. Ambos interfaces muestran una zona en la que se va dibujando el diagrama de hojas y ramas que componen la MIB, y otra zona donde se editan los par´ametros de los componentes introducidos. Tambi´en hay otro espacio dedicado a ir mostrando la sintaxis formal de la MIB actualizada con cada cambio realizado. Estas caracter´ısticas que hemos destacado, han servido para inspirar el dise˜no del MIB Builder dise˜nado en este proyecto. Previamente al dise˜no del algoritmo de automatizaci´on de MIBs se realiz´o una b´usqueda de informaci´on sobre modelos de BBDD para la implementaci´on de MIBs. La mayor´ıa de las soluciones basadas en SNMP y el desarrollo de MIBs solo se centran en describir el dise˜no del contenido de la MIB pero ninguna se preocupa de como es la implementaci´on de dicha MIB ni existe ninguna propuesta de como debe ser la interacci´on con el agente ([7]-[11]). Por ejemplo, en [7], se cuenta de la importancia de las MIBs como una parte del total de un NMS (Network Management System), debido a que las MIBs tienen la capacidad de proporcionar informaci´on relevante para conocer el estado de la red y por tanto facilitar su gesti´on. En [8], se presenta que el tipo de 41.3. Propuesta BBDD (relacional u orientada a objetos) que se implementa en las MIBs es indiferente, pero tampoco detalla como es la implementaci´on. En [9]y[10] se centran en detallar los campos de la MIB y la descripci´on del sisitema. Por tanto, se lleg´o a la conclusi´on de que en base a la bibliograf´ıarevisadanohayningunapropuestaparalaimplementaci´on de MIBs en BBDD y cada fabricante de dispositivos elabora la BBDD en funci´on de cada dispositivo espec´ıfico, sin seguir ning´un tipo de reglas. El desarrollo de agentes es importante ya que no solo se utilizan para la gesti´on de redes en entornos LAN ([9]y[11]) sino que se emplean para otras aplicaciones como pueden ser la de gesti´on de dispositivos m´edicos ([10]). Por ello su desarrollo es interesante. Actualmente existen herramientas que facilitan su desarrollo (SNMP Agent Builder [12]), pero no hay una herramienta que genere el agente junto con el m´odulo de interacci´on a su MIB. 1.3 Propuesta En este proyecto se propone como objetivo principal el desarrollo de un sistema de gesti´on SNMP compuesto por tres m´odulos, cuyo n´ucleo central es el desarrollo de un algoritmo que implemente de manera autom´atica la creaci´on de la BBDD de una MIB gen´erica. Con todo esto, se pretende que su conjunto sirva para implementar el agente en un dispositivo partiendo de la base del dise˜no inicial de su MIB. Los tres m´odulos que componen el sistema propuesto son los siguientes: •MIB Builder (M´odulo de dise˜no): Este primer m´odulo ayudar´a a crear la definici´on formal de una MIB de una manera gr´afica e intuitiva de manera similar que los programas comerciales. •BBDD Creation (M´odulo de almacenamiento): Este segundo m´odulo es el m´as importante puesto que ser´a el encargado de crear la BBDD partiendo de la definici´on formal de la MIB. Este programa debe permitir transformar la definici´on formal de cualquier MIB en una BBDD independientemente de su organizaci´on de hojas y tablas y que maximice la eficiencia en el acceso a la misma. Por ello se desarrollar´a un algoritmo para la lectura de MIBs y su relaci´on con una estructura gen´erica en BBDD propuesta para su almacenamiento. •Agente SNMP (M´odulo de comunicaciones): Este tercer m´odulo constar´ade la implementaci´on de un agente SNMP, y nos permitir´a poder establecer las conexiones con un gestor externo a trav´es de SNMP y as´ı poder hacer pruebas con las que comprobar la robustez del algoritmo previamente creado. Para hacer m´as gen´erico el modo en que se puedan conectar al agente, el dise˜no de este agente dar´a soporte a las tres versiones (v1, v2c y v3) definidas en la arquitectura. Cap´ıtulo 1. Introducci´on y Objetivos 5 Para que todo este sistema global sea amigable al usuario final, se propone finalmente crear una serie de interfaces gr´aficos para interactuar con los programas creados. Por tanto y a modo de resumen, tal y como se puede ver en la Figura 1.3 se propone generar un interfaz compuesto por tres herramientas diferentes, que se puedan usar tambi´en por separado, y que nos permita en primer lugar obtener la definici´on formal de una MIB, en segundo lugar, generar la BBDD de una MIB y finalmente poner en marcha el agente para que el sistema quede completo. Figura 1.3: Esquema general propuesto y la interacci´on entre los bloques. 1.4 Objetivos El objetivo principal de este proyecto es el desarrollo de una herramienta de gesti´on SNMP completa que incorpore un modulo para el desarrollo de MIBs, un m´odulo para la implementaci´on autom´atica de MIBs en BBDD y un agente SNMP que interact´ue con dicha MIB y con el gestor externo. Para llevar a cabo la realizaci´on del proyecto se han completado los siguientes objetivos: 1. Para el m´odulo de dise˜no de MIBs: •Estudio y compresi´on del lenguaje SMI (lenguaje formal para la definici´on de MIBs) para conocer la base sint´actica de una MIB, conocer sus componentes y todas sus caracter´ısticas. 61.4. Objetivos •Desarrollo de un interfaz gr´afico con el que el usuario interact´ue para que pueda dise˜nar su MIB. •Creaci´on de un algoritmo que recoja la informaci´on introducida por el usuario y la transforme en el texto de la definici´on formal de la MIB dise˜nada. 2. Para el m´odulo de almacenamiento en BBDD: •Estudio y compresi´on del protocolo SMI para conocer la base sint´actica de una MIB, conocer sus componentes y caracter´ısticas relevantes a tener en cuenta a la hora de almacenarlas en la BBDD. •Estudio y recopilaci´on de los diferentes tipos de MIB existentes con el fin de proponer un sistema de almacenamiento gen´erico que sirva para todas ellas. •Proponer una organizaci´on de la informaci´on en diferentes tablas para tratar su gesti´on y almacenamiento en la BBDD. •Estudio del lenguaje SQL para poder crear y gestionar la BBDD. •Implementar y desarrollar un conjunto de clases Java para poder estructurar la informaci´on obtenida del fichero de texto introducido con la definici´on formal de la MIB. •Creaci´on de un algoritmo que recopile toda la informaci´on almacenada en las clases Java creadas previamente y cree la BBDD a partir de ellas. •Desarrollo de un interfaz gr´afico con el que el usuario pueda seleccionar la MIB a tratar y la informaci´on de control de su BBDD (nombre de usuario, password...). 3. Para el m´odulo de comunicaciones: •Estudio en profundidad de la arquitectura SNMP para adquirir los conocimientos necesarios para tratar el procesado de un mensaje o PDU (GET, GETNEXT, SET...), y poder dotar al sistema de la capacidad necesaria para su funcionamiento en las tres versiones existentes (v1, v2c y v3). •Estudio en profundidad de la arquitectura SNMP en su versi´on 3 para poder proporcionar al sistema de privacidad y seguridad. •Desarrollo de un algoritmo que procese las peticiones que nuestro agente reciba de un gestor e interact´ue con la BBDD para proporcionarle el dato requerido. •Desarrollo de un programa que pueda interaccionar con la BBDD para introducir datos con permisos exclusivos para el agente. •Desarrollo de un interfaz gr´afico con el que el usuario pueda interactuar con nuestro agente (administrar cuentas de usuario, puesta en marcha y detenci´on del agente). Cap´ıtulo 1. Introducci´on y Objetivos 7 4. Finalmente se crear´aun´unico interfaz gr´afico con el que interact´ue el usuario, que contenga los tres interfaces creados en cada uno de los bloques. 1.5 Materiales El lenguaje de programaci´on utilizado para el desarrollo del trabajo ha sido JAVA, lenguaje orientado a objetos que ofrece un marco potente de programaci´on basado en clases para el desarrollo de programas de gran eficiencia. Adem´as, hemos realizado la interacci´on con la BBDD de forma sencilla a trav´es de conexiones JDBC y la utilizaci´on de sentencias SQL. Se han empleado los siguientes programas software, todos ellos de libre distribuci´on (o en versiones de evaluaci´on gratuitas): •SDK Eclipse [13]. •MG SOFT MIB Browser [14]. •MySQL [15] (phpmyAdmin de Xamp). •La API SNMP4j [16]. 1.6 Organizaci´on de la memoria La memoria est´a estructurada de la siguiente manera: •Cap´ıtulo 1: Introducci´on. Es el cap´ıtulo actual y contiene una breve descripci´on del trabajo realizado, as´ı como sus principales objetivos. •Cap´ıtulo 2: Caracter´ısticas de la arquitectura SNMP y del lenguaje SMI. Este cap´ıtulo contiene una descripci´on de las principales caracter´ısticas del lenguaje formal que se emplea en las MIBs (el lenguaje SMI) y tambi´en se describen los elementos mas importantes de la arquitectura SNMP. •Cap´ıtulo 3: Desarrollo Tecnol´ogico: Bloques implementados. Este cap´ıtulo contiene una descripci´on de los bloques implementados: MIB Builder, BBDD Creation y Agente SNMP. •Cap´ıtulo 4: Pruebas y Resultados. Este cap´ıtulo contiene un informe completo de los resultados obtenidos de las pruebas a las que se ha sometido al programa. •Cap´ıtulo 5: Conclusiones y l´ıneas futuras. Este es el ´ultimo cap´ıtulo de la memoria y contiene las conclusiones que se han sacado en este proyecto y las posibles l´ıneas futuras que se podr´ıan seguir. 81.6. Organizaci´on de la memoria El contenido de los anexos incluidos es el siguiente: •En el anexo Ase tiene una lista de los acr´onimos utilizados en esta memoria. •En el anexo Bse tiene la gu´ıa de usuario para utilizar el MIB Builder desarrollado correctamente. •En el anexo Cse tiene la descripci´on de las tablas implementadas para la creaci´on de la BBDD de una MIB. •En el anexo Dse tiene la gu´ıa de usuario para introducir valores en la MIB por parte del agente implementado. •El anexo Econtiene los diagramas de flujo realizados para la implementaci´on del procesado de paquetes que le lleguen al agente implementado. •En el anexo Fse tiene la gu´ıa de usuario para utilizar el interfaz Agente SNMP desarrollado correctamente. •En el anexo Gse incluye el diagrama de Gantt del proyecto que describe el reparto temporal entre las diferentes tareas que han conformado el mismo. Cap´ıtulo 2 Caracter´ısticas de la arquitectura SNMP y lenguaje SMI El lenguaje formal que se usa para definir MIBs es el lenguaje SMI, el cual se ha tenido que estudiar en profundidad para la elaboraci´on de este proyecto fin de carrera. En este cap´ıtulo se describen las caracter´ısticas de dicho lenguaje y se presenta tambi´en la arquitectura SNMP. Se dan las claves te´oricas para facilitar la comprensi´on del desarrollo de los modulos del entorno de gesti´on presentado en el proyecto. 2.1 La arquitectura SNMP SNMP es la arquitectura de gesti´on de redes m´as utilizada en redes TCP/IP debido a su simplicidad y su escaso consumo de recursos. SNMP define un protocolo para el intercambio de informaci´on de gesti´on adem´as de definir un formato para la representaci´on de esa informaci´on y un marco para organizar sistemas distribuidos en gestores y agentes. La arquitectura SNMP puede ser descrita por los siguientes elementos claves: 1. Dos entidades SNMP: Una entidad gestionada (agente), y una entidad gestora (gestor). 2. Un conjunto de mensajes SNMP con los que funciona el protocolo de gesti´on de la red. 3. La MIB: BBDD del agente. La primera versi´on de SNMP (SNMPv1) presentaba debilidades tanto en t´erminos de seguridad de comunicaciones como en t´erminos de eficiencia ya que no pod´ıa proporcionar en un mismo paquete grandes cantidades de informaci´on. La segunda versi´on (SNMPv2c) solucionaba el problema de entregar grandes cantidades de informaci´on en un mismo 9 10 2.1. La arquitectura SNMP paquete creando un nuevo tipo de mensaje (GetBulk), pero segu´ıa teniendo los mismos problemas de seguridad. As´ı surge SNMPv3, como una evoluci´on de SNMPv2c ya que en cuanto al comportamiento funcional es el mismo, lo que cambia es que a˜nade seguridad y cifrado en la comunicaci´on. 2.1.1 Entidades SNMP La arquitectura SNMP se basa en la interacci´on de al menos dos entidades SNMP, un agente y un gestor (aunque pueden ser varios los gestores que intervengan). Cada una de estas entidades contiene un conjunto de m´odulos que interaccionan para proporcionar servicios. Cada entidad contiene un SNMP engine que es capaz de enviar y recibir mensajes SNMP. El papel de cada entidad SNMP ser´a determinado por los m´odulos implementados en ella misma. Cada entidad debe actuar como agente, gestor o una combinaci´on de ambas. SNMP permite a m´ultiples agentes interaccionar con m´ultiples gestores y esto nos permite tener m´ultiples gestores interaccionando con el mismo agente para intercambiar informaci´on. •Agente: Es la entidad SNMP situada en el equipo que se va a monitorizar, sus misiones son recopilar y guardar informaci´on local, as´ı como responder ante peticiones del gestor y enviar informaci´on de forma as´ıncrona cuando sucede alg´un evento. Toda esta informaci´on puede ser gestionada en el dispositivo y guardada en una base de datos externa dise˜nada llamada MIB. •Gestor: Es la entidad SNMP encargada de pedir informaci´on y modificarla seg´un las necesidades de funcionamiento de la m´aquina en la que reside el agente. El gestor o gestores de la red poseen un interfaz gr´afico para poder emitir comandos y examinar en forma de tablas los datos que les llegan de los agentes. Estos sistemas incluyen como m´ınimo aplicaciones para monitorizaci´on, control de configuraci´on y realizaci´on de informes. El SNMP engine proporciona servicio entre la capa de transporte y las aplicaciones SNMP. Un ejemplo es que encapsula el PDU (Protocol Data Units) dentro del mensaje para transmitirlo y tambi´en de manera inversa, para procesar informaci´on. 2.1.2 Mensajes SNMP El protocolo SNMP define una serie de mensajes para el intercambio de informaci´on, proporciona esencialmente cuatro tipos de mensajes: 1. Get: Permite al gestor recibir informaci´on del agente. 2. Set: Permite al gestor modificar alg´un valor en la MIB del agente. 3. Trap: Permite al agente enviar mensajes as´ıncronos al gestor. Cap´ıtulo 2. Caracter´ısticas de la arquitectura SNMP y lenguaje SMI 11 4. Inform: Permite al gestor enviar alg´un mensaje de alerta a otro gestor. Para implementar estos tipos de mensajes, SNMP especifica un conjunto de PDUs diferentes entre la comunicaci´on agente-gestor. Estos PDUs est´an encapsulados en los mensajes SNMP con la cabecera adecuada para la versi´on del protocolo implementada. •Mensajes enviados por el gestor al agente: –GetRequestPdu: petici´on de una o varias variables incluidas en el mensaje de respuesta Response. –GetNextRequestPdu: petici´on de la inmediatamente siguiente variable a la variable que mandamos y con valor no nulo, cuya respuesta se incluye tambi´en en un mensaje Response. Este comando se usa para recorrer la estructura en ´arbol de la MIB. –GetBulkRequestPdu: tipo de petici´on presente solo a partir de la versi´on 2 (SNMPv2c). Nos permite recibir una lista de variables consecutivas para cada variable que le mandamos nosotros. El n´umero de variables consecutivas viene determinado por el valor max-repetitions. Adem´as podemos pedir variables sin repetir, cuyo n´umero viene determinado por el valor non-repeaters. De este modo podemos pedir m´as informaci´on en una cantidad menor de mensajes, con lo que aumentamos la efectividad. Este comando se basa en realizar continuas operaciones GetNext hasta obtener la cantidad de datos a devolver. –SetRequestPdu: mensaje que modifica una variable de la MIB. Si ha habido alg´un error a la hora de modificar, el agente lo comunicar´a en el mensaje de respuesta mediante el c´odigo de error correspondiente. •Mensajes enviados por el agente al gestor: –GetResponsePdu: mensaje de respuesta para los mensajes que nos env´ıa el gestor. En ´el se incluyen los valores de las variables requeridas, y el c´odigo del error en caso de que ocurra alguno. –TrapPdu: mensaje generado y transmitido de forma as´ıncrona como respuesta a un evento excepcional. En ´el se incluye el sysUpTime, que es el tiempo que lleva encendido el dispositivo, adem´as de las variables que correspondan al tipo de trap generado. •Mensajes enviados de gestor a gestor: –InformationRequestPdu: mensaje para enviar una alerta de un gestor a otro, introducidoapartirdelaversi´on 2. La Figura 2.1 ilustra las operaciones a partir de SNMPv2c (ya que incluye el GetBulk), con la direcci´on respectiva: del gestor al agente o viceversa. 18 2.2. El lenguaje SMI –Se sigue definiendo el tipo de acceso del Objeto mediante la sintaxis ’MAXACCESS’o’ACCESS’ seguido del tipo de acceso (’not-accessible’, ’accessiblefor-notify’, ’read-only’, ’read-write’, ’read-create’). –A continuaci´on se pone el estado del Objeto poniendo ’STATUS’ seguido del estado (current, obsolete, deprecated). –Sigue con la zona de descripci´on: ’DESCRIPTION ’ seguido de la definici´on del Objeto. –Si el Objeto definido es el contenido de una Tabla ha de estar definida la sintaxis ’INDEX ’ indicando los ´ındices de la Tabla entre llaves. –Por ´ultimo ha de ponerse el nodo de donde cuelga el Objeto ’::={mib-2 2}’. Figura 2.4: Definici´on del Objeto sysUpTime. Figura 2.5: Definici´on de la Tabla atTable. Figura 2.6: Definici´on de los campos de la Tabla atTable. Cap´ıtulo 2. Caracter´ısticas de la arquitectura SNMP y lenguaje SMI 19 •Una MIB tambi´en puede tener definida una zona de notificaci´on para poder mandar informaci´on al gestor en caso de que se programe alg´un evento para tal fin: –Comienza con el nombre que se le da a la notificaci´on seguido de la sintaxis ’NOTIFICATION-TYPE’. –Ha de estar el campo ’STATUS’ seguido del estado (current, obsolete, deprecated). –Sigue con la zona de descripci´on: ’DESCRIPTION ’ seguido de la descripci´on de este campo. –Ha de finalizar poniendo el nodo de donde cuelga el Objeto ’::={mib-2 3}’. Cap´ıtulo 3 Desarrollo Tecnol´ogico: Bloques implementados 3.1 Descripci´on general El sistema se compone de diferentes bloques: •MIB Builder: El objetivo del MIB Builder es ayudar a crear la definici´on formal de la MIB a partir de un interfaz gr´afico. Es la parte previa al paso de crear la BBDD de la MIB y consta de una parte dedicada a la creaci´on del esquema en forma de ´arbol de la MIB donde se le pueden a˜nadir una serie de objetos determinados en otra parte del panel. El componente a˜nadido al esquema tendr´a una serie de par´ametros, los cuales se podr´an editar en la zona central del panel. Una vez que hemos terminado de dise˜nar el ´arbol de nuestra MIB, un programa desarrollado para tal fin convertir´ael´arbol dibujado de la MIB en un fichero de texto con su definici´on formal (en el lenguaje SMI). •BBDD Creation: El objetivo del BBDD Creation es crear una serie de tablas en la BBDD a partir de un fichero de texto en el que se encuentra la definici´on formal de la MIB. Para ello se ha desarrollado un programa que permite leer ese fichero de texto. Adem´as se ha desarrollado un algoritmo de conversi´on entre los elementos del lenguaje SMI y los m´odulos de la BBDD, una estructura gen´erica de la misma y un posterior algoritmo de lectura para facilitar la interacci´on del agente con su MIB. Se trata de reconocer las partes relevantes y fundamentales para la elaboraci´on de las tablas (cuya estructura se propone despu´es de hacer un estudio sobre la materia en cuesti´on) que componen la BBDD. Una vez que se reconoce la informaci´on deseada, se va almacenando en unas variables dependientes de una estructura de clases Java tambi´en dise˜nadas para tal fin. Con la informaci´on de control que proporciona el usuario en el interfaz sobre la BBDD y estas variables que contienen la informaci´on de las tablas de la BBDD, se genera dicha BBDD 21 22 3.1. Descripci´on general que dar´a soporte a la MIB. •Agente SNMP: Su objetivo es establecer comunicaciones SNMP con el gestor externo y poner a su disposici´on informaci´on almacenada dentro de la MIB que implementa. Consta de dos partes claramente diferenciadas, por una parte est´a una zona dedicada a gestionar las cuentas de usuarios que tendr´an acceso al agente, en la cual se pueden a˜nadir usuarios (definir que permisos tienen), mostrar los ya existentes o eliminarlos. Por otra parte est´alazonadepuestaenmarchadelagente que consta de campos donde se puede introducir el puerto y la direcci´on IP que va a tener. Figura 3.1: Workflow del problema a resolver. Cualquier gestor que quiera conectarse con el agente generado por nuestro sistema, lo har´aatrav´es de Internet mediante el protocolo SNMP. Pero para que dicho agente est´e implementado y puesto en marcha, debe seguirse el siguiente proceso a trav´es de nuestro programa: se ha de dise˜nar la estructura de la MIB en nuestro MIB Builder para obtener la definici´on formal de la MIB (o se puede tener ya escrita). A continuaci´on, debe introducirse el fichero de texto con la definici´on formal de la MIB en el siguiente m´odulo, Cap´ıtulo 3. Desarrollo Tecnol´ogico: Bloques implementados 23 el BBDD Creation, junto con los datos de control de la BBDD para poder conectarnos a ella. Finalmente se deber´a pasar al interfaz Agente SNMP , introducir los usuarios (con sus respectivos permisos) que podr´an tener acceso, y ponerlo en marcha d´andole al bot´on correspondiente. La Figura 3.1 trata de mostrar el proceso seguido para resolver el problema. 3.2 MIB Builder 3.2.1 Dise˜no El paso m´as importante para la resoluci´on del objetivo de crear el Mib Builder es la creaci´on del interfaz con el que interact´ue el usuario. El criterio de dise˜noqueseha tenido en cuenta es que cualquier usuario debe ser capaz de utilizar el programa de una manera f´acil e intuitiva. Como se puede ver el la Figura 3.2 el interfaz est´a dividido en tres zonas: •La zona 1 es la dedicada al dise˜no del ´arbol de la MIB. •La zona 2 se compone de una serie de objetos para la edici´on y dise˜no de la MIB. •La zona 3 es la dedicada para nombrar la MIB y poner la ubicaci´on del archivo de texto salida. Figura 3.2: Zonas del Interfaz MIB Builder. En la zona destinada para crear el dise˜no del ´arboldelaMIB,lazona1,sehapuesto una tabla inicialmente vac´ıa para permitir al usuario crear la estructura en ´arbol de una 24 3.2. MIB Builder manera sencilla. El anexo Bcontiene una gu´ıa de usuario en el que se detallan los pasos aseguirparalacreaci´on de una nueva MIB. En la zona 2 es donde hay que introducir los campos de cada componente cumpliendo con la sintaxis del lenguaje SMI. En la Figura 3.3 se puede ver la correlaci´on existente entre los campos de la zona de edici´on del Mib Builder y la definici´on formal de la MIB a trav´es del ejemplo de la definici´on del Objeto sysUpTime del grupo System de la mib-2. Figura 3.3: Definici´on del grupo sysUpTime. En cuanto a la zona donde se definen las caracter´ısticas de los objetos introducidos en el ´arbol de la MIB se tienen los siguientes campos: •En el campo Componet se pondr´a autom´aticamente el tipo de componente que se haya introducido en el esquem´aticodelaMIB.Esuntipoclaveparapoder identificar el tipo de componente ya que as´ı su posterior procesamiento ser´am´as sencillo debido a que cada tipo de componente tiene unas caracter´ısticas sem´anticas espec´ıficas en la definici´on formal de la MIB. •En el campo Name aparecer´a un nombre por defecto, dependiendo del tipo de componente del que se trate, pero que el usuario podr´amodificar. •El campo OID se va completando autom´aticamente partiendo del OID del grupoanterior,yelusuariopodr´amodificarel´ultimo trozo correspondiente al componente introducido si desea que sea un valor concreto. •Despu´es viene la zona donde se ha de especificar la sintaxis del componente que sea necesario (todos menos OBJECT IDENTIFIER). Se tienen dos opciones: –Que la sintaxis sea de un tipo de dato predefinido en cuyo caso se Cap´ıtulo 3. Desarrollo Tecnol´ogico: Bloques implementados 25 seleccionar´a esa opci´on (seleccionando el bot´on de su izquierda) y se elegir´a uno de esos tipos de datos. –Que el tipo de dato sea distinto de uno definido o para la creaci´on de una Tabla, en cuyo caso se ha de hacer uso de los campos New Syntax yFROM para definirlo. •Para rellenar el campo Max-Access yStatus se ha de seleccionar una de las opciones disponibles. •El campo Index solo hay que rellenarlo en el caso de definir una Tabla para indicarle el ´ındice o los ´ındices que posea dicha Tabla. •En el campo Description se pone la descripci´on que se desee decir para expilcar las caracter´ısticas del componente. Esta informaci´on introducida se puede editar en cualquier momento que se precise, antes de crear finalmente el archivo de texto de la MIB. En la ´ultima zona, la zona 3, se debe introducir el nombre de la MIB y la ubicaci´on de la carpeta de destino donde se quiera generar el archivo de texto de la definici´on formal de la MIB, para permitir al usuario elegir la carpeta contenedora del archivo. 3.2.2 Implementaci´on Para la implementaci´on de este bloque ha sido necesario crear varias clases Java adem´as de su interfaz, mostrado en la Figura 3.4. Figura 3.4: Interfaz MIB Builder. La primera clase Java que fue necesario crear se trata de la clase component, desarrollada especialmente para almacenar toda la informaci´on introducida en el interfaz 26 3.3. BBDD Creation con respecto al componente introducido en la zona de dise˜no del ´arbol. Esta clase contiene todos los campos de los que se pueden introducir informaci´on de cualquier componente. El ´arbol MIB es en definitiva un conjunto de componentes, por lo que se trata a efectos pr´acticos del programa de un array de la clase component. Para que la informaci´on de cada componente se haga efectiva es necesario pulsar el bot´on ’Apply’. Esto es as´ı porque al introducir un nuevo componente al ´arbol de la MIB, se genera autom´aticamente un nuevo elemento en el array que contiene los componentes del ´arbol. De esta manera, al pulsar el bot´on ’Apply’ le indicamos al programa que hemos completado o modificado la informaci´on de los campos que se genera autom´aticamente al a˜nadir el componente en el ´arbol y que la informaci´on que presentaba anteriormente ha quedado obsoleta. De igual manera, para modificar la informaci´on de cualquier componente ya introducido en el ´arbol, se han implementado varias funciones Java para obtener la informaci´on del array de componentes introducidos y poder modificarla. 3.3 BBDD Creation 3.3.1 Algoritmo de conversi´on Este bloque se encarga en primer lugar de leer la definici´on formal de la MIB y extraer de ella los componentes de la MIB. El fichero de texto que contiene la MIB se lee hasta detectar el comienzo, ya que suele ir precedida de una descripci´on hecha por el autor sobre dicha MIB. Una vez reconocido el inicio de la MIB (’DEFINITION::=BEGIN’) hemos de detectar todos los componentes existentes y los nodos para almacenarlos en un conjunto de variables y clases Java para poder automatizar el proceso de crear la BBDD. En la Figura 3.5 se muestra un resumen del proceso que realiza el algoritmo. Figura 3.5: Funciones del algoritmo de conversi´on. Cap´ıtulo 3. Desarrollo Tecnol´ogico: Bloques implementados 27 Lo primero de todo es almacenar la informaci´on de los grupos existentes en la MIB, ya que son los primeros en ser descritos en la definici´on formal de cualquier MIB. Puesto que se conoce el OID completo de los Grupos mgmt einternet (as´ı como todos los Grupos anteriores a ´estos), se almacena en un conjunto de variables espec´ıficamente dise˜nado para este fin (como si de una tabla se tratase) el nombre del Grupo y su OID completo. Cada vez que se reconoce un nuevo Grupo en la definici´on formal de la MIB se actualiza este conjunto de variables a˜nadiendo el nuevo Grupo reconocido con su OID, compuesto por el OID de un Grupo que ya tenemos m´as el nuevo n´umero introducido. A continuaci´on se reconocen los Objetos, las Tablas y los Objetos de las Tablas de la MIB. Los Objetos de la MIB se reconocen porque se definen con la sintaxis ’OBJECT-TYPE’. Las Tablas porque la definici´on del campo SYNTAX se define como ’SEQUENCE OF’ nombreTabla. Finalmente, los Objetos de Tabla son iguales que los Objetos y los identificamos porque en su OID el nodo precedente es el nombre de la Tabla. Pero no se trata solamente de reconocer estos campos, sino que tambi´en hay que almacenar toda esa informaci´on. En la Figura 3.6 se muestra la sintaxis clave detectada en la MIB y las partes almacenadas. Figura 3.6: Partes a almacenar de la MIB. Cap´ıtulo 4 Pruebas y Resultados Para comprobar el correcto funcionamiento del sistema se realizaron las pruebas que se recogen en este cap´ıtulo. 4.1 Dise˜no de una MIB Para comprobar el correcto funcionamiento del bloque MIB Builder se ha tratado de implementar una MIB que consta de los Grupos system yat de la mib-2,conelfin de comparar la definici´on formal de la MIB introducida con los trozos correspondientes a estos Grupos de la mib-2. Se han elegido estos Grupos porque contienen diferentes elementos como Objetos y Tablas. Tal y como se define en la gu´ıa de usuario del MIB Builder del anexo B, comenzamos definiendo el ´arbol de la MIB (que llamaremos subMIB-2) a partir del Grupo mgmt, seg´un se ve en la Figura 4.1. Figura 4.1: Definici´on del nodo inicial mgmt. 35 36 4.1. Dise˜no de una MIB Una vez introducidos en el ´arbol de dise˜no todos los componentes necesarios, la estructura dise˜nada queda de la forma que se puede ver en la Figura 4.2, donde tambi´en se puede observar la definici´on del ´ultimo Objeto de la Tabla atNetAddress,elnombre introducidoparaestaMIB(subMIB-2) y la carpeta donde se quiere guardar el fichero de texto con la definici´on formal de la MIB (en el escritorio): Figura 4.2: Definici´on del Grupo atNetAddress. Ahora que ya est´acreadoel´arbol de la MIB y se han introducido los par´ametros necesarios para la creaci´on del fichero de texto de la definici´on formal, se ha de pulsar el bot´on ’LANZAR’ y si todo ha funcionado correctamente nos saldr´a el aviso que podemos ver en la Figura 4.3, en caso contrario, si el fichero no se hubiera generado, saldr´ıa un mensaje de error. Figura 4.3: MIB definida con ´exito. Cap´ıtulo 4. Pruebas y Resultados 37 Una vez creado el fichero de texto con la definici´on formal de la MIB, se ha comprobado su correcta definici´on sint´actica agregando dicho fichero a un gestor comercial como es MIB-Browser a trav´es de su editor de MIBs (MIB Compiler [25]). Este proceso se muestra en la Figura 4.4: Figura 4.4: Introducci´on de la MIB creada en un gestor. Y por ´ultimo se muestra en la Figura 4.5 la MIB que hemos creado en el Bloque MIB Builder, en el gestor MIB-Browser: Figura 4.5: Visualizaci´on de la MIB creada en el gestor MIB Browser. 38 4.2. Implementaci´on de la BBDD de una MIB 4.2 Implementaci´on de la BBDD de una MIB Se emplea el bloque BBDD Creation dise˜nado para crear la BBDD de la MIB generada con el m´odulo anterior. Para activar el algoritmo de implementaci´on se han de rellenar previamente todos los campos presentes en el interfaz. Lo primero es seleccionar el archivo de texto generado en el bloque anterior (Figura 4.6). A continuaci´on se introduce la informaci´on de configuraci´on de la BBDD (Figura 4.7), posteriormente se selecciona la carpeta donde se guardar´a el archivo de salida con la informaci´on relevante obtenida del proceso de generar la BBDD y por ´ultimo se ejecuta el algoritmo desarrollado para crear la BBDD pulsando el bot´on ’START’. En la ventana de salida del interfaz se informa de todo este proceso y de su finalizaci´on (Figura 4.8). Figura 4.6: Introducci´on del fichero de la MIB en el bloque BBDD Creation. Figura 4.7: Informaci´on de acceso a la cuenta de la BBDD MySQL. Cap´ıtulo 4. Pruebas y Resultados 39 Figura 4.8: Mensaje sobre el estado de la creaci´on de la BBDD. 4.2.1 Pruebas del bloque BBDD Creation Con el fin de comprobar el correcto funcionamiento del bloque BBDD Creation, se ha creado un banco de pruebas para determinar con exactitud su comportamiento con los distintos tipos de MIBs existentes. Las pruebas se han realizado en un ordenador port´atil con un procesator intel core i3 en el entorno de una m´aquina virtual con sistema operativo Windows XP cuya memoria base era de 512 MB. Dichas pruebas han consistido en comprobar que el algoritmo de conversi´on de la definici´on formal de una MIB a una estructura de tablas para componer la BBDD funciona con todo tipo de MIBs, por lo que el banco de pruebas fue formado por las siquientes MIBs: •MIB-2:MIBp´ublica compuesta por Objetos y Tablas. Esta MIB se compone por los Grupos: system, interfaces, at, ip, icmp, tcp, udp, egp, transmission, snmp y host. •RMON :MIBp´ublica compuesta por Tablas con permisos especiales. Esta MIB se compone por los Grupos: statics, history, alarm, hosts, hostTopN, matrix, filter, capture, event yrmonConformance. •NETSCREEN-SET-EMAIL-MIB [26]: MIB privada de un dispositivo de red (switch). •MEDICALDEVICESMANAGER-MIB [10]: MIB privada de un dispositivo m´edico. •EjemploPrueba: MIB privada dise˜nada con nuestro MIB Builder. 40 4.3. Creaci´on del agente Adem´as de los motivos ya expuestos, se ha elegido la ’MIB-2’ para realizar las pruebas porque para el dise˜no de la estructura de tablas que componen la BBDD se emplearon los Grupos system einterfaces pertenecientes a esta MIB. De igual manera que de la MIB ’RMON’ se utiliz´o el Grupo alarm. Se han creado cinco BBDD en la misma cuenta de usuario MySQL (mib,rmon, netscreen,medical yprueba) para almacenar las BBDD implementadas al realizar las pruebas. Una vez ejecutado el programa con las cinco MIBs que componen la prueba, obtenemos los archivos de informaci´on creados a la vez que las BBDD, nos muestran la informaci´on mostrada en la Tabla 4.1 (donde NObj es el n´umero de Objetos, NTab el n´umero de Tablas, NObjTab el n´umero de Objetos de Tablas, Tobj el tiempo en reconocer los Objetos, Tcrear el tiempo en crear la BBDD y TMem el tama˜no de memoria), adem´as de informaci´on detallada de cada uno de los Objetos, de las Tablas y de los Objetos de Tabla (nombre, tipo de dato, OID...). MIB NObj NTab NObjTab Tob j (ms) Tcrear (ms) TMem (KB) MIB-2 113 8 69 251 11106 71,3 RMON 18 18 167 310 15232 108,6 NETSCREEN 5 0 0 250 451 7,8 MEDICAL 23 8 59 461 7481 48,5 EjemploPrueba 7 2 6 10 1342 16,2 Tabla 4.1: Resultados m´as relevantes obtenidos en las pruebas. Puede observarse que el tiempo que tarda en crearse la BBDD (Tcrear) no es muy elevado y que el tama˜no de memoria que ocupa al ser creada (TMem) es peque˜no. Tambi´en se puede observar que estos par´ametros dependen de manera directamente proporcional al n´umero de Objetos, Tablas y Objetos de Tabla que contengan. Hay que tener en cuenta que el tama˜no de memoria de la BBDD ser´a mayor cuando se introduzcan datos en las Tablas que contengan (ya que inicialmente est´an vac´ıas). 4.3 Creaci´on del agente Para comprobar el correcto funcionamiento de la BBDD implementada se ha desarrollado un agente que recibir´a las peticiones de informaci´on sobre la MIB de un gestor e interactuar´a con este. En el anexo Fse muestra la gu´ıa de usuario de este interfaz. En la Figura 4.9 se puede ver como se han introducido los usuarios public yprivate de la versi´on 1/2c, que tendr´an permisos de lectura y escritura respectivamente, y se ha introducido el usuario arribas de la versi´on 3 para que puedan conectarse a nuestro agente. Cap´ıtulo 4. Pruebas y Resultados 41 Figura 4.9: Usuarios definidos en el agente. Una vez se han configurado las cuentas de usuario, se lanza el agente para que escuche peticiones de los gestores. Despu´es de introducir la direcci´on IP del agente (la del dispositivo) y el puerto donde tiene que escuchar (normalmente el 161) se pulsa el bot´on ’START’, y si se pone en marcha correctamente, sale un mensaje de aviso y se pone la pantalla verde del monitor del interfaz (que seguir´a de ese color mientras el agente est´e activo) tal y como se ve en la Figura 4.10. Figura 4.10: Agente funcionando correctamente. Una vez que se tiene el agente a la escucha de los mensajes provenientes de los gestores, se dispone a verificar su correcto funcionamiento. Para ello se emplea un programa gestor (MIB-Browser) desde el cual se realizar´a la comunicaci´on con el agente. Se ha de comprobar que funciona con todas las versiones del protocolo SNMP (para ello se crearon usuarios de todas esas versiones). 42 4.3. Creaci´on del agente 4.3.1 Conexi´on versi´on 1 y 2c Puesto que la seguridad que ofrecen estas versiones es la misma, a modo de conexi´on es indiferente comprobar el funcionamiento de cualquiera de ellas, ya que la diferencia existente entre ellas es que con la versi´on 2c se pueden realizar peticiones de varios datos a la vez (GetBulk). En la Figura 4.11 se ve como se aplica la configuraci´on de usuarios para la versi´on 1 y en la Figura 4.12 se ve como se ha conectado correctamente. Figura 4.11: Configuraci´on de usuario de la versi´on 1 en el gestor. Figura 4.12: Conexi´on establecida entre el gestor y el agente. Una vez que se ha conectado el gestor con nuestro agente, se comprueba que posee todas las funcionalidades correctamente implementadas. En la Figura 4.13 se muestra como se ha introducido correctamente un dato en la MIB. Cap´ıtulo 4. Pruebas y Resultados 43 Figura 4.13: Hecho Set correctamente. 4.3.2 Conexi´on versi´on 3 Siguiendo con las pruebas del agente se pasa a verificar el correcto funcionamiento de la versi´on 3. Se ha de poner la informaci´on del usuario introducido en el agente para esta versi´on en el gestor (Figura 4.14), y en la Figura 4.15 se muestra como la conexi´on se ha realizado satisfactoriamente. Figura 4.14: Configuraci´on de usuario de la versi´on 3 en el gestor. 50 Bibliograf´ıa [12] MG-SOFT Agent Builder. http://www.mg-soft.si/builder.html. [13] The Eclipse Foundation. http://www.eclipse.org/. [14] MG-SOFT MIB Browser. http://www.mg-soft.si/mgMibBrowserPE.html. [15] MySQL. http://www.mysql.com/. [16] API-SNMP4J. http://www.snmp4j.org/. [17] MIB-2. http://www.ietf.org/rfc/rfc1213.txt. [18] William Stallings. ’SNMPv3: A Security Enhancement for SNMP’. IEEE Communicatios Surveys, 1(1):2–17, 1998. [19] Storage Networking Industry Association. http://www.snia.org/. [20] Storage Management Forum. http://www.snia.org/forums. [21] Technical Work Groups. https://www.snia.org/tech activities/work/twgs. [22] Conformance Testing Program. http://www.snia.org/ctp/. [23] RFC 2578: SMIv2. http://tools.ietf.org/html/rfc2578. [24] RMON. http://tools.ietf.org/html/rfc2819. [25] MG-SOFT Mib Compiler. http://www.mg-soft.si/mgmibc.html. [26] Juniper Networks. http://www.juniper.net/au/en/products-services/security/netscreen/.