ÍNDICE

CAPÍTULO 1. INTRODUCCIÓN 7

CAPÍTULO 2. GESTIÓN DEL PROYECTO 92.1 Descripción del proyecto 92.2 Objetivos del proyecto 92.3 Alcance del proyecto 10 2.4 Planificación temporal 112.5 Riesgos y planes de contingencia 132.6 Método de trabajo 142.7 Gestión real del proyecto 14

CAPÍTULO 3. DESCRIPCION DEL PROTOCOLO SNMP 193.1 Introducción 193.2 Evolución histórica del protocolo SNMP 193.3 Arquitectura de un sistema de gestión de red 21

3.3.1 Entidad gestora 213.3.2 Dispositivos a gestionar 213.3.3 Protocolo de gestión 22

3.4 Modelo de información 233.4.1 Estructura de la información de administración 233.4.2 MIB 243.4.3 Operaciones de SNMP 283.4.4 La seguridad en SNMP 31

3.5 Conclusiones 31

CAPÍTULO 4. DESARROLLO TEÓRICO 334.1 Introducción (finalidad del proyecto) 334.2 Captura de requerimientos hardware 334.3 Captura de requerimientos software 35

4.3.1 El Sistema Operativo 354.3.2 Los agentes 364.3.3 Análisis de herramientas de monitorización de datos 374.3.4 Servidor http 374.3.5 Análisis de herramientas para la comunicación de redes IP y GSM 38

4.4 Conclusiones 38

CAPÍTULO 5. DESARROLLO PRÁCTICO 395.1 Instalación, configuración y pruebas de los agentes 39

5.1.1 Linux – Debian (Net-SNMP) 395.1.2 Otros agentes SNMP para Linux 445.1.3 Windows 2000, Windows 2003 Server 45

5.2 Instalación y configuración de MRTG 495.3 Instalación y configuración del servidor HTTP, Apache 635.4 Instalación y configuración de Gnokii 655.5 Conclusiones 69

CAPÍTULO 6. CONCLUSIONES 71

1

CAPÍTULO 7. BIBLIOGRAFÍA 73

ÍNDICE DE FIGURAS

Figura 1. Diagrama EDT Figura 2. Diagrama de Gantt inicial Figura 3. Tareas y diagrama de Gantt real Figura 4. Ubicación del protocolo SNMP en el modelo OSI Figura 5. Componentes principales de una arquitectura de gestión de red Figura 6. Árbol de objetos MIB Figura 7. Implementación parcial del módulo systemFigura 8. Formato de las PDUs en SNMPv2Figura 9. Operaciones SNMPFigura 10. Instalación del paquete snmp a través del comando apt-getFigura 11. Definición de los nombres de comunidad y grupos asignadosFigura 12. Relación entre modelos de seguridad y gruposFigura 13. Definición de vistas y tipo de accesoFigura 14. Proceso snmp escuchando en el puerto 161 a través del protocolo UDPFigura 15. Salida del comando snmpgetFigura 16. Salida del comando snmpget con múltiples variablesFigura 17. Salida del comando snmpgetnextFigura 18. Salida del comando snmpwalkFigura 19. Utilización del comando snmpsetFigura 20. Salida del comando snmpstatusFigura 21. Salida del comando snmptranslateFigura 22. Salida del comando snmpnetstatFigura 23. Panel de instalación del agente SNMP en WindowsFigura 24. Estado del servicio SNMPFigura 25. Panel de propiedades del servicio SNMPFigura 26. Detalles de las opciones del menú ServicioFigura 27. Panel de configuración de Seguridad del servicio SNMPFigura 28. Instalación de los módulos necesarios para MRTGFigura 29. Opciones globales para el archivo mrtgcpu.cfgFigura 30. Implementación parcial del archivo de configuración mrtg.cfgFigura 31. Implementación parcial del archivo mrtgdiscos.cfgFigura 32. Implementación del script snmp_hdfreeFigura 33. Implementación parcial del archivo mrtgfreemem.cfgFigura 34. Implementación del script snmp_windowsmemfreeFigura 35. Implementación parcial del archivo mrtgnumprocses.cfgFigura 36. Implementación parcial del archivo mrtgonoff.cfgFigura 37. Implementación del script para comprobar el estado, on/off, de un

dispositivoFigura 38. Utilización del comando cfgmakerFigura 39. Implementación parcial del archivo mrtgredservers.cfg creado

mediante el comando cfgmakerFigura 40. Implementación parcial del archivo mrtgroutercisco.cfg creado

mediante el comando cfgmaker Figura 41. Implementación del script galarmaFigura 42. Implementación del script galarmaok Figura 43. “Compilación” de los archivos de configuración

2

Figura 44. Tareas a realizar de manera periódicaFigura 45. Utilización del comando indexmakerFigura 46. Menú principal de acceso a las gráficasFigura 47. Vista global de las gráficasFigura 48. Vista detallada de las gráficasFigura 49. Instalación del módulo apache2Figura 50. Configuración de apache2, permisos de acceso por IPFigura 51. Utilización del comando htpasswd2Figura 52. Configuración de apache2, autorizacionesFigura 53. Menú de acceso a las gráficasFigura 54. Conexión del cable de datos al teléfono móvilFigura 55. Instalación del modulo gnokiiFigura 56. Configuración de gnokii, modelo de móvil y conexiónFigura 57. Configuración de gnokii, tiempo de esperaFigura 58. Comprobación de la instalación de gnokii mediante el comando

gnokii –monitorFigura 59. Enviar sms a través de gnokiiFigura 60. Script galarmaFigura 61. Script galarmaokFigura 62. Recepción de una alerta

3

CAPÍTULO 1. INTRODUCCIÓN

Aquí comienza el desarrollo de este Proyecto Fin de Carrera (de aquí en adelante PFC), titulado “Implantación de un sistema de gestión de dispositivos de red, basado en el protocolo SNMP”, el cual se encuentra enmarcado dentro del amplio mundo de las redes informáticas.

El centro de formación Cebanc-Cdea, situado en San Sebastián, cuenta con su propia red informática formada por una gran cantidad de dispositivos informáticos diferentes. A los administradores informáticos de esta empresa, les resultaba algo incómodo y tedioso el hecho de tener que comprobar el funcionamiento de estos dispositivos además de sentir una cierta frustración cuando uno o varios de ellos fallaban sin conocer el motivo. De esta manera les surgió la idea de implantar en su red un sistema de gestión o control, de tal forma que fuera el propio sistema el que les avisara de los fallos en la red y evitarse así el tener que realizar ellos mismos periódicamente controles.

Mi gran pasión por las redes informáticas y el hecho de realizar prácticas en esta empresa durante el verano del año 2002, provocaron el comienzo del desarrollo de este proyecto. Para mí, consistía un gran reto y una ampliación en mis conocimientos informáticos, ya que desconocía casi por completo el mundo de las gestiones de las redes informáticas.

El presente documento tratará de explicar todos los pasos que se han llevado a cabo en la realización de este proyecto. Inicialmente se desarrollará el Documento de Objetivos del Proyecto (DOP), que reúne los objetivos a completar, los cuales obviamente han sido solicitados por la empresa Cebanc-Cdea, así como una serie de puntos sobre la gestión del propio proyecto. Posteriormente se pasa al aspecto más laborioso e importante de todo este documento donde se realiza el estudio y aprendizaje del protocolo de gestión de red utilizado, que servirá de base para el posterior desarrollo práctico. Para concluir se comentarán una serie de conclusiones personales obtenidas tras la finalización del proyecto.

Por último, me gustaría comentar, que este documento no pretende ser un manual global para implantar un sistema de gestión en una red informática, ya que existen múltiples maneras de gestionar una red, las cuales varían en función de los requerimientos y necesidades de las propias redes. No se intenta que el sistema de gestión que se desarrollará a continuación, sea mejor o peor que otros, sino que sea el óptimo para la red en la que se va a implantar.

4

CAPÍTULO 2. GESTIÓN DEL PROYECTO

En este capítulo se abordará todo lo relativo a la gestión de este PFC. Se explicará de una forma resumida en qué consiste el proyecto y cuáles son los objetivos que se pretenden conseguir. Seguidamente se desarrollará el alcance, la planificación temporal, una lista de riesgos junto con su plan de contingencia así como la metodología a seguir para la buena realización de este PFC. Finalmente se realizará un apartado sobre la gestión real del proyecto, en el que se incluirán todas aquellas modificaciones surgidas durante el desarrollo del PFC y que servirá para realizar un balance entre la gestión planificada al comienzo y la real.

2.1 Descripción del proyecto

Hoy en día una red está formada por una gran cantidad de elementos complejos, tanto de tipo hardware como software y que interactúan; desde enlaces, routers, servidores y otros dispositivos que componen la parte física de la red, hasta los diferentes protocolos que coordinan y controlan estos dispositivos. Cuando una organización reúne cientos o miles de estos componentes para formar una red, es normal que algunos no funcionen bien ocasionalmente, que los elementos de la red se desconfiguren, que los recursos de la red sean sobreexplotados, o que los componentes de la red sencillamente se rompan.

El administrador de red, cuyo trabajo es mantener la red con un funcionamiento óptimo, debe ser capaz de responder ante estos percances o incluso si se puede, evitarlos.

Este PFC consistirá en realizar la implantación de herramientas hardware y software que facilitarán el control de la red al administrador. Como es obvio pensar, se necesitará una red lo suficientemente amplia como para poder llevar a cabo el proyecto; para ello, este proyecto se desarrollará en el centro de formación Cebanc-Cdea, el cual cuenta con una red de aproximadamente 300 máquinas y unos 15 servidores, además de diferentes dispositivos para su conexión.

La aplicación final será capaz de monitorizar la información de los diferentes componentes de la red por medio de gráficas que facilitarán la comprensión del funcionamiento de la red al administrador.

2.2 Objetivos del proyecto

A continuación se detallarán los objetivos que se pretenden conseguir con la realización de este proyecto:

1. Aprendizaje del protocolo SNMP, Simple Network Management Protocol, para su uso posterior. SNMP es un protocolo de gestión de red, que nos va a permitir obtener datos concretos de los dispositivos que participan en la red (como por ejemplo, la tasa de CPU que se está utilizando en un servidor o el consumo de tráfico en las entradas/salidas de una interfaz de red). Se analizará su funcionamiento y la evolución desde su aparición.

5

2. Implantación de un sistema de control de red, que contará con las siguientes funcionalidades:

• Capacidad para monitorizar los resultados obtenidos por medio del protocolo SNMP. Este sistema presentará los resultados deseados por medio de unas gráficas.

• Almacenamiento de datos históricos para poder comparar la información obtenida en tiempo real con la información ya almacenada y así poder realizar un mejor análisis de los datos obtenidos.

• Y por último, disponibilidad para el envío de una alerta, a través de correo e-mail, a un teléfono móvil. Este enviará un mensaje (vía SMS), con el contenido del texto del e-mail, a otro teléfono móvil que estará en posesión del administrador. La alerta sólo se enviará en caso de anomalías críticas en la red (por ejemplo, en el bloqueo de un servidor).

También aparecen como objetivos indirectos un estudio básico de la red instalada en la empresa y del diferente software a utilizar para la realización de la aplicación.

2.3 Alcance del proyecto

En este punto se tratarán las tareas que implican este proyecto, y que las podemos dividir en tres grandes grupos:

• En el primero quedan englobadas todas aquellas que se basan en la recopilación de información (mediante la búsqueda por diferentes fuentes y a través de reuniones con el cliente).

• El segundo sirve de nexo entre el primero y el tercero. Aquí queda encuadrada la tarea de análisis de la información obtenida en las tareas anteriores, y que servirá para la realización de las tareas posteriores.

• Y en el tercero se encuentran todas las que implican el desarrollo del sistema (implantación y pruebas).

Cada una de las tareas puede subdividirse en otras más pequeñas como se muestra en el siguiente diagrama EDT:

6

(fig. 1, diagrama EDT)

2.4 Planificación temporal

Este apartado servirá para realizar una estimación del tiempo que se empleará en la realización del proyecto y sus diferentes tareas.

Inicialmente se prevé que la mayor parte del tiempo se dedique en la parte media y final del proyecto (en el análisis de la información e implantación de la aplicación).

El tiempo dedicado a la recopilación de la información dependerá de la calidad de esta. Esto es importante, ya que sin un buen material de partida es altamente probable que surjan problemas en las fases posteriores y que pueden llevar a reanalizar muchos conceptos que implicarán un aumento del tiempo en la realización del PFC.

Hay que tener en cuenta que durante el primer cuatrimestre me encontraré cursando asignaturas, de las que deberé examinarme a finales de enero y primeros de febrero. A partir de febrero, si no ocurre nada imprevisto, el tiempo que podré dedicar al proyecto será completo. De esta forma la planificación temporal del proyecto en un principio queda dividida de la siguiente manera:

• Hasta finales del mes de diciembre se realizarán las tareas de búsqueda de información y captura de requerimientos

• Tras la realización de los exámenes, a mediados de febrero, se continuará con el análisis, la implantación y las pruebas

Se espera finalizar el proyecto a primeros de mayo para realizar su posterior presentación en la convocatoria de junio.

Para ver una representación gráfica de la planificación expuesta se presenta a continuación su correspondiente diagrama de Gantt:

PFC

Gestión Búsqueda documentació

n

Captura de requisitos

Análisis de requisitos

Consulta en libros

Consulta en Internet

Consulta en manuales

Consulta en otras fuentes

Desarrollo

ImplantaciónConsultas con el cliente

Estudio de la red

Entregables de cada fase

Memoria final Pruebas

7

2.5 Riesgos y planes de contingencia

Al igual que en cualquier otro proyecto, este también cuenta con una serie de riesgos que de no detectarse a tiempo podrían afectar a su desarrollo. Se analizarán y se presentarán soluciones para poder evitarlos:

• Mala documentación. Es un riesgo importante a tener en cuenta ya que la información obtenida durante las primeras fases va a servir de base para el posterior desarrollo del proyecto. Una mala documentación podría llevar a su fracaso. También hay que tener en cuenta la alta probabilidad que existe de que mucha de la documentación necesaria se encuentre en inglés, idioma en el que el alumno no tiene un nivel muy alto.

o Solución: contrastar, con diferentes documentos, la información obtenida. Referente al idioma, el alumno espera no tener excesivos problemas, pero si se da el caso habrá que realizar uso de herramientas traductoras (traductores de páginas Web o sencillamente un diccionario).

• Falta de recursos humanos. Al ser este un PFC que se va a desarrollar en una empresa y por lo tanto va a contar con usuarios reales, el buen desarrollo del proyecto va a depender también del nivel de colaboración de los clientes, sobre todo en la fase de captura de requerimientos donde se pueden dar malentendidos de lo que se quiera realizar.

o Solución: mantener una comunicación regular, mediante reuniones personales o vía e-mail, con las dos partes implicadas en este proyecto (el tutor del mismo, D. José Antonio Lozano Alonso y el cliente, la empresa Cebanc-Cdea).Inicialmente no se cree que vaya a faltar colaboración por parte del cliente. Si esto no fuese así, los tiempos planificados para realizar las diferentes tareas del proyecto se podrían alargar, con lo cual habría que realizar una replanificación temporal del PFC.

• Falta de experiencia: es otro gran riesgo ya que es el primer proyecto, con una envergadura aceptable, al que el alumno se enfrenta solo. Esto puede provocar el retraso en el desarrollo del PFC o haciendo que los objetivos planteados en un principio deban ser menos ambiciosos.

o Solución: durante las primeras fases, documentarse lo máximo posible y a través de diferentes medios (libros, Internet o personas con conocimientos sobre el tema).

• Pérdida de la información: aunque hoy en día los problemas de seguridad y fiabilidad en los sistemas a nivel usuario no son excesivamente preocupantes, hay que tenerlos en cuenta. La pérdida parcial de la información podría provocar retrasos en las tareas, y la pérdida total el fracaso seguro.

o Solución: tener una política de backups (copias de seguridad). El alumno realizará copias de la información en dispositivos como CD-RW (CD’s regrabables) o en DVD-RW si fuese necesario (tienen mayor capacidad que los CD’s). Las copias se realizarán cuando el alumno lo estime oportuno (probablemente cada vez que se realice un importante avance en el desarrollo del proyecto).

8

Estos son los mayores problemas que se pueden detectar al comienzo de la realización de este PFC. Seguramente, durante su transcurso aparecerán muchos más. Todos ellos se recogerán en el apartado Gestión real del proyecto.

2.6 Método de trabajo

Para el buen desarrollo de este proyecto se intentará mantener un ritmo adecuado en la realización del mismo. Tal y como se ha adelantado en el punto de la planificación temporal, el alumno se encuentra cursando asignaturas del último año de carrera. Hasta febrero se le dará mayor prioridad a las asignaturas, pero sin dejar de lado el desarrollo del PFC. A partir de la finalización de los exámenes del primer cuatrimestre, y contando con que el alumno tendrá mas tiempo libre, se llevarán a cabo las tareas que a priori se cree que serán más laboriosas.

Al final de cada una de las fases en las que se divide el proyecto, se pretende generar un informe con lo que se ha realizado en dicha fase y que se entregará tanto al director del proyecto como al cliente. De esta manera se pretende conseguir un mayor control y seguimiento del proyecto de las tres partes implicadas (alumno, cliente y director).

También será importante mantener una buena comunicación. Puesto que el cliente ha ofrecido sus instalaciones al alumno para realizar el proyecto, la comunicación alumno-cliente será prácticamente diaria. Con respecto al profesor, además de mantenerle informado del desarrollo del proyecto por medio de los informes de cada fase, si alguna de las dos partes cree conveniente realizar alguna reunión se comunicarán vía e-mail para llevarla a cabo.

2.7 Gestión real del proyecto

Este último apartado de este capítulo, al contrario que los demás, se realiza una vez finalizado el proyecto, y se utiliza para realizar un balance de la gestión propuesta inicialmente para el desarrollo del mismo.

Comparando el diagrama de Gantt presentado al inicio de este proyecto, con el real, lo primero que destaca es el tiempo empleado. En un principio se había estimado la finalización hacia el mes de mayo, cumpliéndose ésta realmente en el mes de octubre. Se explicarán los motivos de este aumento de tiempo:

1. Debido a que los conocimientos del alumno sobre sistemas de gestión de red eran muy escasos, se tuvo que hacer una replanificación temporal de la fase de captación de requerimientos, ampliando el tiempo de esta, para poder asimilar mejor los conceptos que iban surgiendo, y de esta manera evitar acarrear problemas en las fases posteriores.

2. También se apuntó anteriormente, que durante los meses de enero y febrero el alumno se encontraría realizando exámenes. Debido a una imprevista nevada, algunos de estos exámenes se suspendieron hasta fechas posteriores, lo cual también incidió en la duración de la fase de captación de requerimientos.

9

3. Aunque se preveía que durante el segundo cuatrimestre el alumno no tuviera asignaturas que cursar, debió de realizar un examen en el mes de junio, lo que provocó una parada temporal en el desarrollo del proyecto.

4. Por último y provocado por una incompatibilidad en el calendario con el tutor del proyecto, la corrección del presente documento también se vió demorada durante un par de semanas en el mes de agosto.

Continuando con el análisis del diagrama de Gantt real, se observa que algunas tareas se han eliminado, las correspondientes a las entregas de los informes de cada fase. Esto se debió a que, el tutor del proyecto no está dedicado a la materia sobre la que se basa el proyecto (redes informáticas) y por lo tanto poco podía ayudar en la parte técnica. En cuanto al responsable del proyecto en la empresa Cebanc-Cdea, al no contar éste con suficiente tiempo como para revisar estos informes, el alumno le fue informando, prácticamente a diario y de una manera coloquial, de los avances que se iban realizando y de las dudas que iban surgiendo.

Para finalizar, también se observa que muchas de las fases se han solapado. No era algo previsto al inicio de este proyecto, debido a que el alumno en aquel momento desconocía cuál iba a ser el desarrollo del mismo. A medida que se iba avanzando, y como se observará en los capítulos posteriores, era necesario el realizar las tareas de esta manera.

10

CAPÍTULO 3. DESCRIPCIÓN DEL PROTOCOLO SNMP

La realización de este proyecto se basa en el uso del protocolo SNMP (Simple Network Management Protocol). Por ello, en este capítulo se tratará de explicar su funcionamiento, sus componentes, su arquitectura, así como su evolución en sus diferentes versiones desde su nacimiento en la década de los 80.

3.1 Introducción

A finales de los años 70 las redes de ordenadores experimentaron un espectacular crecimiento y comenzaron a conectarse entre sí. Pasaron de ser pequeñas redes a convertirse en grandes infraestructuras globales, lo que conllevó también al crecimiento en número de los componentes hardware y software. Debido a esto, cada vez se hacía más difícil el control y la gestión de dichos componentes por lo que tuvo que ser necesario el desarrollo de un sistema para poder mantener la gestión en la red.

Antes de que surgiera la necesidad de gestionar las redes, ya habían aparecido una serie de problemas a la hora de interconectarlas; estos mismos problemas se dieron también en el momento en el que se comenzaron a gestionar y como veremos la política que se utilizó para solucionarlos fue similar:

• Dispositivos diferentes: la interconexión de redes permite conectar diferentes dispositivos de distintas marcas comerciales que soportan el protocolo de transmisión de datos TCP/IP(Transmisión Control Protocol/Internet Protocol). A la hora de administrar una red esto se presenta como un problema. El uso de una tecnología de interconexión abierta fue la que dio solución a este problema, por lo que para administrar estas redes se hizo necesario también utilizar una tecnología de administración de redes abierta.

• Administraciones diferentes: hay que tener en cuenta que como se permite la interconexión de redes de diferente propósito, éstas también se encontrarán administradas y gestionadas de diferente forma.

3.2 Evolución histórica del protocolo SNMP

Tal y como se ha comentado en puntos anteriores, el gran aumento de las redes y sus componentes hizo necesario la creación de un sistema de comunicación que pudiera administrarlas y gestionarlas. Este sistema de comunicación se implementó en forma de protocolo tal y como se explica a continuación.

A mediados de los años 80 aparecen los primeros protocolos de gestión, SGMP (Simple Gateway Monitoring Protocol). Este protocolo definía una plataforma que servía para monitorizar el rendimiento de los dispositivos que unían las redes que se encontraban aisladas. Fue diseñado por un grupo de investigadores universitarios de redes, usuarios y gestores, que gracias a su experiencia y a la imperiosa necesidad que había por crear un sistema de administración de redes, pudieron diseñar e implementar el protocolo SNMP en unos pocos meses. En un principio el protocolo SNMP fue creado como una solución temporal hasta que llegaran protocolos de gestión de red con mejores diseños y más completos. Su primera versión, SNMPv1 (propuesto

11

originalmente en el Request For Comment, RFC, 1157)[1], contaba con un manejo muy simple que se basaba en el intercambio de información de red a través de mensajes o PDU´s (Protocol Data Unit). Era un protocolo que se podía extender fácilmente por toda la red. Pero no todo era perfecto, ya que no estaba pensado para poder gestionar las numerosas e innovadoras redes que cada día iban apareciendo. Además contaba con importantes deficiencias en materia de seguridad.

Paralelamente a la creación de SNMP, surgió otro protocolo de gestión, CMIP (Common Managment Information Protocol) del modelo ISO/OSI (Open System Interconnection), encargado del desarrollo de estándares en materias de comunicaciones de datos. CMIP, se encontraba mucho mejor organizado, contaba con muchas más funciones y subsanaba muchas de las deficiencias de SNMP. El precio de todo esto es que se convirtió en un sistema tan grande y complejo, que consumía muchos recursos en la red y tan solo las mejores equipadas podían soportarlo. De esta manera SNMP encontró una mejor aceptación entre los usuarios y se convirtió en la opción más factible para la gestión de redes.

Tras quedarse SNMP al frente de los protocolos de gestión de red, se hacía necesario subsanar todas aquellas carencias que habían surgido en su primera versión. Por este motivo, a principios de los años 90 se empieza a trabajar en una nueva versión del protocolo, SNMPv2 (RFCs 1441-1452)[1]. Las mayores innovaciones sobre las que se trabajaron en esta versión son:

• Mecanismos de seguridad, los cuales no existían en la primera versión. Se basaron en tres grandes conceptos dentro del mundo de la seguridad: privacidad de los datos, autenticación de los usuarios y control en el acceso.

• Estructuras de datos, que permitían un mejor manejo de éstos. Se abría la posibilidad de gestionar un número de datos y objetos mayor, de tal manera que el problema de gestionar grandes redes se iba solucionando.

Desafortunadamente muchas de estas innovaciones no se llegaron a implementar y se quedaron en pura teoría, como fue el caso de las referentes a la seguridad, provocando que esta versión sirviera como parche o extensión de la versión anterior.

Con la evolución del mundo de Internet estas versiones dejaban al descubierto las grandes deficiencias que surgían en torno a la seguridad. Por esta razón a finales de los 90, los grupos de expertos se reunieron para crear un nuevo conjunto de RFC´s (2271-2275, 2570-2575)[1], conocidos como SNMPv3, que se orientaban a solucionar estas deficiencias. Las principales ventajas que aparecieron en esta versión sobre sus predecesoras fueron las siguientes:

• Se implantan definitivamente los mecanismos de seguridad (privacidad, autenticación y autorización).

• El uso de LOO (Lenguajes Orientados a Objetos) como Java o C++ que ayudaron en la construcción de elementos propios del protocolo (objetos al fin y al cabo) y que sirvieron también para dar una mayor consistencia al protocolo lo cual equivalía a una mayor seguridad de éste.

[1] Consultar referencia en la Bibliografía[

[

12

Hoy en día, SNMP está considerado como el gran estándar dentro de los protocolos de gestión de red, algo que no ha pasado inadvertido para los fabricantes de dispositivos de red que diseñan la gran mayoría de sus productos para soportar este protocolo.

3.3 Arquitectura de un sistema de gestión de red

Dentro de la arquitectura de red del modelo OSI, el protocolo SNMP se sitúa en el tope del nivel de transporte, como se observa en la figura 4, por encima de la capa de protocolos de transporte como por ejemplo UDP (User Datagram Protocol).

AplicaciónSNMP

TransporteIP

Acceso a redFísico

(fig. 4, ubicación del protocolo SNMP en el modelo OSI)

En la propia arquitectura de gestión de red, existen tres componentes básicos que se pasarán a analizar seguidamente:

• La entidad gestora• Los dispositivos a gestionar• El protocolo de gestión de red

3.4.1 Entidad gestora

La entidad gestora es una aplicación que se ejecuta en una máquina que se encuentra en el centro de operaciones de red. Es desde esta máquina donde se va a controlar la gestión de la red: recolección, procesamiento y visualización de la información a gestionar. Desde aquí el administrador de red tendrá la capacidad de interactuar con los dispositivos que quiera controlar.

3.4.2 Dispositivos a gestionar

Los dispositivos a gestionar, son todos aquellos dispositivos que tienen algún tipo de capacidad de trabajo en red; puede ser un servidor, un router, un módem, una impresora, un hub, switches, etc.

Cada dispositivo contará con diferentes objetos a gestionar (managed objects), que son el hardware de los dispositivos que se gestionan (por ejemplo, en un servidor su tarjeta de red) y sus parámetros de configuración (bytes emitidos y recibidos en un router, por ejemplo).

En estos objetos se encuentra la información que el administrador de red puede controlar desde la entidad gestora. Esta información se almacena en una “base

13

de datos de información de gestión” (MIB; Manager Information Base), que se analizará más adelante.

Por último, en cada dispositivo existe un agente de gestión de red (de aquí en adelante agente), que es el proceso encargado de comunicarse con la entidad gestora proporcionando la información que ésta solicite. En la siguiente figura, se puede visualizar la arquitectura descrita.

Dispositivo a gestionar

Dispositivo a gestionar

Dispositivo a gestionar

Dispositivo a gestionar

Entidad Gestora

Agente

Agente

Agente

Agente

MIB

MIB

MIB

MIBMIB

SNMP

SNMP

SNM

P

SNMP

(fig. 5, componentes principales de una arquitectura de gestión de red)

3.4.3 Protocolo de gestión

Un buen sistema de gestión, será aquel que sea capaz de reconocer la gran diversidad de dispositivos a administrar que pueden aparecer en una red, ofreciendo un entorno de administración adecuado. Teniendo en cuenta esto, una de las características más importantes que se ha de cumplir a la hora de implantar un sistema de gestión en una red es que el impacto, en términos de rendimiento, que se produzca en los dispositivos gestionados sea mínimo.

Para poder llevar a cabo la comunicación entre los agentes de cada dispositivo y la entidad gestora va a ser necesario tener un protocolo, en este caso un protocolo de gestión (SNMP, CMIP, etc). A través del protocolo, la entidad gestora podrá realizar consultas sobre el estado de los dispositivos o indicar a los agentes de cada dispositivo las acciones que deben de llevar a cabo. De la misma manera, los agentes podrán utilizar el protocolo para informar a la entidad de cualquier anomalía que pudiera suceder en un dispositivo (por ejemplo la caída de un servidor).

Dentro del protocolo de gestión, va a ser importante la elección de un servicio de transporte adecuado, ya que el rendimiento del protocolo va a depender directamente de este servicio. Tal y como se ha comentado en el apartado anterior, la implantación de un sistema de control de red debe causar el menor impacto

14

posible en la propia red, característica que deberá de cumplir el servicio de transporte. Hay que tener en cuenta que en el momento en el que se den fallos en la red, la administración de ésta ha de seguir funcionando (será en ese instante cuando más se necesite tener la red controlada y administrada), por lo que el servicio de transporte seleccionado deberá de ser fiable para que no se provoque una pérdida de la información.

Los servicios de transporte los podemos clasificar en dos categorías: orientados y no orientados a conexión. Los orientados a conexión (por ejemplo TCP), son mas fiables, permiten la retransmisión de la información pero hacen un mayor uso de los recursos de la red; por ejemplo: si en un momento dado la red se encuentra congestionada y es difícil establecer una conexión, con un servicio de transporte orientado a conexión necesitaríamos tres pasos para establecer dicha conexión, mientras que con un servicio no orientado a conexión solo nos haría falta un paso. Si la red está perdiendo paquetes, será más sencillo establecer la conexión de ésta última forma.

Por todo esto, lo que se recomienda en los protocolos de gestión es el uso de un servicio de transporte no orientado a conexión. De hecho, para SNMP en el RFC 1906, se establece que UDP es el servicio de transporte más adecuado (lo cual no implica que no se pueda utilizar TCP).

3.5 Modelo de información

En este apartado se va a tratar la estructuración de la información en un entorno de gestión de red, así como la forma de comunicación de los datos.

3.5.1 Estructura de la información de administración

La estructura de la información de administración (Structure of Management Information, SMI) define las reglas para definir la información de administración; es el lenguaje que se utiliza para definir la información de gestión que reside en una entidad de red (en nuestro caso, los dispositivos a gestionar). Con este lenguaje nos aseguramos que la sintaxis y semántica de los datos de gestión de red se encuentren bien definidos y no sean ambiguos.

En el apartado 3.4.2 se ha comentado que cada dispositivo a gestionar cuenta con una serie de objetos que contienen información sobre el dispositivo, y que dicha información se almacena en una base de datos denominada MIB. SMI, se encarga de definir el esquema de esa base de datos.

SMI está basado en el lenguaje de definición de objetos Abstract Syntax Notation One (ASN.1), pero ya cuenta con los suficientes tipos de datos específicos como para que se le considere un lenguaje de definición de datos. Además también proporciona construcciones de lenguaje de alto nivel, entre las que destacan estas dos:

• OBJECT-TYPE: esta construcción se utiliza para especificar el tipo de datos, el estado y la semántica del objeto gestionado.

15

• MODULE-IDENTITY: esta otra construcción nos permite poder agrupar objetos relacionados dentro de lo que se denomina un “módulo de información”.

3.5.2 MIB

SNMP tiene definido una estructura estándar para los datos que gestiona, la base de información de gestión (Management Information Base; MIB). En esta estructura se definen los datos (objetos con valores) que contiene un dispositivo gestionado, al igual que las operaciones que permite. Esos valores van a poder ser consultados o modificados por una entidad de gestión enviando mensajes, a través del protocolo SNMP, al agente que se está ejecutando en el dispositivo a gestionar. Los objetos se especifican utilizando la construcción, comentada en el punto anterior, OBJECT-TYPE y se reúnen en módulos (módulos MIB) utilizando el constructor MODULE-IDENTITY. Se puede ver parte de la implementación de uno de estos módulos en la figura 7.

Debido a la gran diversidad de dispositivos de red y fabricantes que residen en el mercado informático, la IETF (Internet Engineering Task Force) tuvo que buscar una manera estándar de identificar a todos los dispositivos y de acceder a la información de gestión que contienen. Para ello, la IETF adoptó un entorno estandarizado de identificación que había sido propuesto por la ISO, de tal manera que se iba a poder identificar cualquier objeto de cualquier dispositivo, independientemente del fabricante.

La MIB mantiene una estructura de árbol, de tal manera que para acceder a un dato en concreto desde la raíz, sólo va a existir un único camino. En la parte superior del árbol se encuentra ISO y ITU-T (Internacional Telecommunication Union), las dos principales organizaciones de estandarización. Tal y como se observa en la figura 6, cada nodo del árbol contiene un nombre y un número, de tal forma que cada nodo va a ser identificable mediante una secuencia de nombres o de números. En nuestro caso, para acceder a los módulos MIB estándar podremos hacerlo de las siguientes dos maneras:

• mediante su nombre: .iso.org.dod.internet.management ó• a través de su representación numérica (también llamada OID, Object

IDentifier)1.3.6.1.2

16

(fig. 6, árbol de objetos MIB)

Las hojas del árbol MIB, son los objetos que contienen las variables que a su vez contienen información sobre el dispositivo.

La versión estándar actual de la MIB, es la MIB-II (1.3.6.1.2.1) especificada en el RFC 1213. Aquí se encuentran algunos de los módulos de información que más nos van a interesar para la gestión del dispositivo:

• system(1.3.6.2.1.1): incluye información sobre el fabricante y el tiempo sobre el último reinicio del sistema de gestión

• interface(1.3.6.2.1.2): información sobre los interfaces de red• address translation(1.3.6.2.1.3): contiene la dirección de red y sus

traducciones a direcciones físicas• ip(1.3.6.2.1.4): proporciona las tablas de rutas y estadísticas sobre los

datagramas IP recibidos• icmp(1.3.6.2.1.5): contiene información sobre los mensajes icmp

recibidos• tcp(1.3.6.2.1.6): muestra información sobre las conexiones TCP,

retransmisiones, etc.• udp(1.3.6.2.1.7): cuenta el número de datagramas UDP, enviados,

recibidos, etc.• egp(1.3.6.2.1.8): proporciona información acerca de los mensajes egp,

recibidos, enviados, etc.

A modo de nota informativa, comentar que en el RFC 3000[1] se encuentran enumerados todos los módulos MIB estandarizados.

[1] Consultar referencia en la Bibliografía

ITU-T (0)

ISO (1)

Joint ISO/ITU-T (2)

Standard (0)

Cuerpos miembros de ISO (1)

Organizaciones identificadas por ISO

(3)

US DoD (6)

Internet (1)

managment (2)

MIB-1 (2)

MIB-2 (1)

system (1)

interface (2)

address translation (3)

ip (4)

icmp (5)

tcp (6)

udp (7)

egp (8)

snmp (11)

17

En la figura 7, se muestra parte de la implementación de la MIB-II. En concreto, las definiciones de tres objetos del grupo o módulo system: sysDescr, sysObjectID y sysUpTime.

RFC1213-MIB DEFINITIONS ::= BEGIN

IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212;

-- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [14];

-- MIB-II (same prefix as MIB-I)

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

-- textual conventions

DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having

-- -- SIZE (0..255)

PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets.

-- groups in MIB-II

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }

at OBJECT IDENTIFIER ::= { mib-2 3 }

ip OBJECT IDENTIFIER ::= { mib-2 4 }

icmp OBJECT IDENTIFIER ::= { mib-2 5 }

18

tcp OBJECT IDENTIFIER ::= { mib-2 6 }

udp OBJECT IDENTIFIER ::= { mib-2 7 }

egp OBJECT IDENTIFIER ::= { mib-2 8 }

-- historical (some say hysterical) -- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

-- the System group

-- Implementation of the System group is mandatory for all -- systems. If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned.

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 }

sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred

19

Router'." ::= { system 2 }

sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 }

(fig. 7, implementación parcial del módulo system)

Por cada uno de los objetos, vemos que muestra:• su nombre o definición (OBJECT-TYPE)• la estructura de datos de ese objeto, “el tipo de dato que va a devolver

ese objeto” (SYNTAX)• el tipo de privilegio o acceso al objeto, “lectura, escritura, creación….”

(ACCESS)• su estado, que indica si esa definición es actual o antigua• y una descripción de lo que se obtiene de él (DESCRIPTION)

Además de la MIB estándar (MIB-II), otra MIB que también nos va a interesar es la HOST-RESOURCES-MIB (MIB de recursos del host con OID .1.3.6.1.2.1.25), de la cual podremos obtener información de recursos de servidores tales como la capacidad de disco duro, el número de usuarios del sistema, el uso de la memoria RAM, el número de procesos, software instalado, etc (la descripción de esta MIB se encuentra definida en el RFC 2790)[1].

Por último, comentar que muchas empresas y fabricantes informáticos se dedican también a crear sus propias MIBs (MIBs propietarias) para sus productos, de tal manera que el usuario final pueda obtener una mejor información y realizar una gestión adecuada de dicho producto.

3.5.3 Operaciones de SNMP

La forma más común de utilizar el protocolo SNMP es de la manera “petición –respuesta”, en el que la entidad gestora envía una petición a un agente (que se encuentra en un dispositivo a gestionar), la recibe, la trata y envía una respuesta a esa petición. Las peticiones se suelen utilizar para obtener (get) o modificar (set) valores de objetos MIB del dispositivo a gestionar.

Otra manera de utilizar el protocolo SNMP, es mediante “mensajes trampa” o “traps”. Aquí, la entidad gestora no envía ninguna petición, sino que es el propio agente del dispositivo que se está gestionando el que envía un mensaje a la entidad gestora. Estos traps se utilizan cuando se dan situaciones excepcionales, por

[1] Consultar referencia en la Bibliografía

20

ejemplo: el agente instalado en un servidor podría enviar un trap cuando el espacio libre de su disco duro alcance un determinado nivel.

Aunque se detallará más adelante, el sistema operativo Windows 2003 Server no soporta la última versión del protocolo (SNMPv3), por lo que la versión utilizada en este PFC será la 2 (SNMPv2), la cual tiene definidos siete tipos de mensajes o PDUs que se engloban en cinco grupos (el formato se puede observar en la figura 8):

• operaciones tipo “get”, que son enviadas desde la entidad gestora a un agente para obtener el valor de los objetos MIB del dispositivo a gestionar. Existen tres diferentes:

o GetRequest: utilizada para obtener el valor de uno o varios objetos MIB

o GetNextRequest: utilizada para obtener el valor del siguiente objeto MIB en una tabla (de esta manera evitamos tener que hacer múltiples GetRequest)

o GetBulkRequest: utilizada cuando se va a acceder a una tabla que contiene una gran cantidad de objetos MIB

• tipo “set”, enviadas desde la entidad gestora al agente del dispositivo gestionado para modificar el valor de uno o varios objetos MIB:

o SetRequest

• tipo “inform”, se envían desde la entidad gestora al agente de otra entidad gestora para notificar la información MIB que es remota a la entidad receptora (no se va a utilizar):

o InformRequest

• tipo “response”, se envían como respuesta a los mensajes expuestos anteriormente, desde el agente a la entidad gestora:

o Response

• mensajes trampa o “traps”, estos mensajes se envían desde el agente del dispositivo gestionado a la entidad gestora, para informar a esta de un evento excepcional sucedido en el dispositivo gestionado. El apelativo de “trampa”, se debe a que el agente envía el mensaje sin que la entidad gestora lo solicite.

21

Tipo PDU (0-3) id petición Estatus de error (0-5) Índice de error Nombre Valor Nombre Valor

Tipo PDU (4) Empresa Dirección agente Tipo trampa (0-7) Código específico Marca de tiempo Nombre Valor

Obtener/establecer cabecera Variables a obtener/establecer

Cabecera de trampa Información de trampa

PDU SNMP

(fig. 8, formato de las PDUs en SNMPv2)

Como ya se ha comentado, UDP es el principal protocolo de transporte para el envío de mensajes SNMP siendo el puerto 162 el usado para los mensajes trampa (la entidad gestora se queda a la escucha del puerto esperando recibir algún mensaje) y el 161 para el resto de mensajes como se muestra en la siguiente figura.

(fig. 9, operaciones SNMP)

Debido a que UDP ofrece un servicio de transporte no orientado a conexión, esto es, no fiable, no se va a poder obtener una garantía de que las peticiones, o sus respectivas respuestas, lleguen a su correspondiente destino. Por ello, la entidad gestora utiliza el campo ID Petición de las PDU para numerar las peticiones realizadas a un agente; éste, tomará la ID Petición de la petición recibida y la indicará en la PDU de respuesta. De esta manera la entidad gestora puede detectar las peticiones o respuestas perdidas. En el caso particular, de que la entidad gestora no recibiera la correspondiente respuesta a la petición enviada, el estándar SNMP actualmente no indica si se debe de seguir algún tipo de política (como por ejemplo, la retransmisión de la petición).

22

3.5.3 La seguridad en SNMP

En el apartado anterior hemos comprobado que los mensajes SNMP no se utilizan sólo para obtener información de los dispositivos gestionados, sino que también se puede modificar información de estos (con el mensaje SetRequest). Esto es algo peligroso, ya que un usuario no autorizado podría captar estos mensajes y modificarlos a su gusto originando graves problemas en la red.

Ya se ha comentado que la seguridad en las dos primeras versiones del protocolo SNMP era algo escasa. Se basa en el concepto de comunidad (community). Hay dos tipos de comunidades que indican los permisos de acceso y que pueden ser:

Read-only o sólo lectura, utilizada cuando solo se quiere obtener información de los dispositivos gestionados

Read-write o lectura-escritura, además de obtener información, se realizan cambios en la información del dispositivo

Cada una de estas, tiene una clave de acceso llamada nombre de comunidad (community name) y que se ha de indicar cuando se utilizan los mensajes SNMP. Por defecto son:

public para la comunidad read-only private para la read-write

Obviamente, para aumentar la seguridad de nuestro sistema lo primero que se debería de realizar es el cambio de estos nombres de comunidad. Ya que en este PFC se utiliza SNMPv2, en capítulos posteriores se explicará como realizar este paso.

Es en la versión 3 de SNMP cuando se introducen verdaderos mecanismos de seguridad. Esta seguridad se basa en los conceptos de autenticación y cifrado. Aparece también el concepto de usuario, que se identifica por un nombre de usuario y una clave de acceso. Para el cifrado o encriptación de la información, SNMPv3 utiliza el sistema de clave compartida DES (Data Encryption Standard), y para la autenticación también se suelen utilizar funciones de dispersión (lo más común es utilizar algoritmos como MD5 o SHA).

Todos estos mecanismos hacen de SNMPv3 la versión más segura del protocolo ofreciendo una gran confianza a sus usuarios aunque dependiendo de las necesidades de estos y de la gestión que se vaya a realizar de la red, se podrán seguir utilizando cualquiera de las otras dos versiones anteriores.

3.6 Conclusiones

El protocolo de gestión SNMP cuenta con un diseño simple lo que le hace tener también una implementación sencilla capaz de integrarse en grandes redes necesitando pocos recursos. La utilización de las MIB como “base de datos” de los dispositivos a gestionar, permite a los usuarios un acceso sencillo a la información que deseen conocer.

23

La popularidad la alcanzó al ser, prácticamente, el único protocolo de gestión que existió al principio, lo cual hizo que los fabricantes informáticos diseñaran sus productos para soportar SNMP. Siendo un protocolo tan popular, no se podía permitir las desventajas con las que contaba, las referentes a la seguridad, que cada vez se iban haciendo más latentes a medida que surgían redes más potentes. Por ello, los grupos de expertos se reunieron para introducir los mecanismos de seguridad, ofreciendo de esta manera un gran protocolo de gestión a los usuarios más exigentes.

24

CAPÍTULO 4. DESARROLLO TEÓRICO

En este capítulo se abordará de una manera global (sin entrar en detalles) el propio desarrollo del proyecto: se comentará de forma breve su finalidad, para pasar posteriormente a la captura y análisis de requerimientos necesarios para poder llevarlo a cabo:

• A nivel hardware, se enunciarán los dispositivos necesarios y sus características más relevantes.

• A nivel software, se realizará un pequeño análisis de los programas y paquetes informáticos utilizados.

También se comentarán las decisiones más relevantes tomadas durante la realización de este proyecto, que en general se han establecido en función de la arquitectura de la red informática sobre la que se ha implantado el sistema de gestión.

4.1 Introducción (finalidad del proyecto)

Este proyecto tiene como finalidad la implantación de un sistema de control o gestión de una red informática que pueda facilitar el control de ésta a su administrador.

Como características más relevantes de este sistema, se presentan la capacidad de monitorizar mediante gráficas, diferentes parámetros de los dispositivos que se encuentran en la red así como un almacenamiento “histórico” de los datos para su posterior análisis. En caso de producirse un evento importante en alguno de los dispositivos gestionados, el sistema también será capaz de generar una alerta que pueda enviarse mediante correo electrónico o vía SMS (Short Message Service, Servicio de Mensajes Cortos), pudiendo así el administrador realizar un control más cómodo de la red informática.

4.2 Captura de requerimientos hardware

Aunque pueda resultar una obviedad, lo primero que necesitaremos para llevar a cabo el proyecto es una red informática lo suficientemente amplia. Es por ello que este sistema se va a implantar en el centro de formación Cebanc-Cdea, el cual cuenta con una red de aproximadamente 300 máquinas y unos 15 servidores, además de múltiples dispositivos (routers, switches, hubs, etc.) para su interconexión.

En segundo lugar, y haciendo referencia al capítulo anterior, se utilizará como base un protocolo de gestión (SNMP) para el control de la red.

Centrándonos ya en la arquitectura del protocolo SNMP, lo primero será disponer de una máquina o un servidor que haga la función de entidad gestora. Para ello se cuenta con un servidor HP ProLiant ML 110, que presenta las siguientes características, las cuales se consideran suficientes como para llevar a cabo un buen control de la red:

• Procesador Intel Pentium 4 a 2.80 GHz• 512 MB de memoria SDRAM DDR PC 3200 A 400 MHz• Disco duro con capacidad para 40 GB (ATA/100 7200 rpm)

25

• Tarjeta de red Broadcom 5705 PCI Gigabit 10/100/1000 integrada con WOL (Wake on LAN). Desde esta interfaz habrá que tener conexión con los dispositivos a gestionar.

• Conexión a un SAI (Sistema de Alimentación Ininterrumpida), para evitar problemas en caso de cortes en el sistema eléctrico.

Hay que recordar, que del buen funcionamiento de esta máquina dependerá la buena gestión de la red, sobre todo en los momentos más críticos (cuando haya congestiones, cortes de luz, etc.). Por ello, es importante contar con una máquina lo más fiable posible y así poder obtener al final una mayor probabilidad de éxito en el control de la red.

Una vez que tenemos la máquina que trabajará como entidad gestora, el siguiente punto a tratar es la elección de los dispositivos de red a gestionar y sus parámetros. Tras consultarlo con el cliente de este proyecto, el administrador de sistemas de la empresa, se decide gestionar 11 de los servidores y 1 de los routers. Por motivos de seguridad para la empresa, no se detallarán en profundidad las características de estos dispositivos aunque sí se puede comentar que entre los servidores algunos ofrecen servicios típicos como:

• servicio de correo interno/externo• servicio web• acceso a la base de datos del centro• servicio de descarga de ficheros• gestión de dominios bajo Windows 2003 (DCs, Domain Controler)• cursos interactivos on-line

Los parámetros que se desean gestionar y monitorizar posteriormente son los siguientes:

• en cada uno de los servidores:o tráfico entrante/saliente en las tarjetas de redo espacio libre en los HD (Hard Disk, disco duro)o tasa de CPU utilizadao memoria RAM disponibleo numero de sesiones abiertaso numero de procesos en ejecucióno estado (encendido/apagado)

• en el router:o tráfico entrante/saliente en sus diferentes bocas

Ya se comentó en el capítulo anterior que a través de las MIB podemos monitorizar prácticamente todo aquello que se nos ocurra. Algunos parámetros interesantes que también se podrían haber gestionado pero que el cliente no consideró necesarios en estos momentos son: estado de los servicios/procesos (si se encuentran en ejecución o no), memoria utilizada por cada proceso, estado de los puertos, etc.

26

De los 11 servidores, 10 de ellos trabajan bajo el Sistema Operativo Windows 2003 Server y el restante, bajo Windows 2000. Esto será importante, a la hora de tener que instalar y configurar el agente de cada uno de los servidores.

Por último, para posibilitar a nuestro sistema la capacidad de envío de SMS, será necesario contar con un dispositivo móvil que permita el envío de este tipo de mensajes, así como su correspondiente cable de conexión de datos, para que la entidad gestora pueda comunicarse con él. La elección de estas herramientas se deja para un punto posterior, ya que se tomará una decisión en función del software a utilizar.

Todo lo explicado hasta ahora es referente al hardware necesario, a continuación se detallará el software. Antes de nada, resaltar que como finalidad indirecta del proyecto, también se quiere desarrollar e implantar el sistema con herramientas gratuitas y de libre distribución y esto se debe básicamente a dos motivos: primero, porque para su realización no se cuenta con ningún tipo de presupuesto económico y segundo porque se quiere demostrar que muchas de las herramientas de libre distribución son tan válidas y funcionales como las desarrolladas por las empresas privadas.

4.3 Captura de requerimientos software

4.3.1 El Sistema Operativo

A nivel software, la primera decisión a tomar es la elección de la plataforma bajo la que se desarrolla el control de la red. Principalmente existen dos grandes sistemas en el mercado, Windows y Linux. Además de tener en cuenta lo comentado en el punto anterior, también se toma en consideración las consultas realizadas con el cliente, quien me animó y me aconsejó a realizarlo bajo GNU/Linux, sistema que a nivel de servidores ofrece un mejor rendimiento y una mayor fiabilidad que Windows. Además, el tener los servidores a gestionar con Windows como sistema base, no nos presenta ningún tipo de problema.

Una vez decantados por el S.O. Linux, la siguiente decisión es la elección de la distribución a utilizar. Actualmente, existen múltiples distribuciones de este S.O., tales como Red Hat, Suse, Mandrake, Debian, etc. Todas ellas tienen en común el núcleo Linux, junto con sus bibliotecas y herramientas del proyecto GNU (proyecto para el desarrollo de herramientas totalmente libres), y difieren en el conjunto de aplicaciones que reúnen cada una. Es conocido, que la instalación de paquetes y programas bajo Linux no suele ser algo trivial y cómodo. Esto se presenta como un problema, ya que se prevé que durante este proyecto se tenga que instalar y configurar diferente software.

Se decide utilizar Debian (versión del núcleo 2.4.27), debido a que subsana los problemas comentados en el párrafo anterior. Gracias a su comando ‘apt-get’, se pueden instalar y actualizar de manera sencilla los paquetes y servicios que deseemos. Además se realiza una instalación ‘por red’, que nos permite decidir desde un principio los paquetes a instalar. Con una instalación desde CD tendremos una gran cantidad de paquetes instalados que no se van a utilizar, lo cual podría generar una sobrecarga en nuestra máquina de forma innecesaria. Otra ventaja con la que cuenta la distribución por red, es que en el

27

momento de la instalación contamos con las últimas versiones de todos los paquetes, y que a través del comando ‘apt-get update’ se podrán ir actualizando cómodamente.

4.3.2 Los agentes

Hasta el momento tenemos, por un lado el servidor o máquina que trabaja como entidad gestora y que funciona bajo Linux, utilizando la distribución Debian; por el otro los dispositivos a gestionar (11 servidores Windows y 1 router), y el protocolo SNMP para realizar la gestión entre la entidad y los dispositivos. Siguiendo la arquitectura del protocolo de gestión comentada en el capítulo 3, el siguiente paso es poner en funcionamiento a los agentes de cada dispositivo, que son los procesos encargados de comunicarse con la entidad gestora. Para llevar a cabo las primeras pruebas, además de realizar la instalación de los agentes en cada uno de los servidores a gestionar, también se instala el agente en la propia entidad gestora (de esta manera se detalla también la instalación y configuración de un agente en Linux). En este último caso nuestro servidor además de trabajar como entidad gestora, adquiere también la funcionalidad de dispositivo gestionable.

Para el caso del router (y el ejemplo serviría para otros dispositivos como switches o hubs), el fabricante (Cisco) le dio soporte para el protocolo SNMP, por lo que ya cuenta con el agente. Tan solo hay que consultar su manual, para poder configurarlo. Es interesante también, acceder a las páginas web de los fabricantes para poder comprobar si existen nuevas actualizaciones para el firmware de nuestros productos.

En la mayoría de las distribuciones Linux, se incluye un agente SNMP que es uno de los más desarrollados en la actualidad. Se trata de la librería NET-SNMP, antes denominada ucd-snmp. Más adelante se explicará su instalación, su configuración y las herramientas con las que cuenta.

Uno de los principales problemas durante la realización de este proyecto, surgió en el momento en el que se debía de analizar el agente con el que trabaja la plataforma Windows. Tras recopilar la información necesaria sobre los dispositivos a gestionar, y más concretamente sobre los agentes de Windows, se comprobó que estos ya partían con una desventaja importante: actualmente no soportan SNMPv3. Esto presenta un problema a nivel de seguridad, ya que los mensajes SNMP no pueden viajar cifrados ni se puede realizar una seguridad a nivel de usuario (tal y como se explicó en el capítulo anterior).

Tras consultar este problema con el cliente del proyecto, no se vio tampoco como un gran inconveniente, ya que toda la información SNMP va a viajar sólo a través de la Intranet (ó red interna) de la empresa y además ya se había decidido que los mensajes se iban a utilizar únicamente para obtener información. Es decir, se presentaron los riesgos al cliente, éste los evaluó y consideró que la seguridad que ofrece SNMPv2 era suficiente para la red de la empresa.

28

En compensación, el agente de Windows ofrece otro tipo de opciones en materias de seguridad para suplir de alguna manera esa carencia, que se verán más adelante.

Una vez que tenemos instalados y configurados los agentes en los diferentes servidores a gestionar, ya podemos realizar el control de éstos desde la entidad gestora. Ahora bien, queremos tener los datos representados de una manera “amigable”, vistosa y clara, utilizando por ejemplo la representación a través de gráficas. Para ello haremos uso de una herramienta de monitorización de datos, que será capaz de generar las gráficas en páginas HTML (HyperText Mark-Up Language), y que posteriormente podrán ser visibles desde otras máquinas, haciendo uso también de un servidor HTTP (HyperText Transfer Protocol).

4.3.3 Análisis de herramientas de monitorización de datos

Aunque inicialmente se preveía que el decidir el software a utilizar para monitorizar los datos fuese uno de los pasos más laboriosos, por existir multitud de software en el mercado y tener que realizar múltiples pruebas con cada una de las aplicaciones que nos pudieran interesar, resultó mucho más sencillo de lo que parecía.

Como se ha dicho, actualmente en el mercado, existen muchas herramientas de monitorización de dispositivos, pero descartando todas aquellas que no son de libre distribución y que no trabajan en el mundo Linux, básicamente nos podemos quedar con dos ya que son las más valoradas y usadas en el ámbito de la gestión de redes: MRTG (Multi Router Traffic Grapher) y Nagios. Se comenzó analizando Nagios, y rápidamente se descartó ya que aunque permite la captura de paquetes SNMP, no es un sistema de monitorización y gestión basado en SNMP sino que se basa en unos pequeños módulos software que realizan chequeos de la red.

Con lo cual, la elección fue sencilla: MRTG. Esta herramienta cuenta con todas las características necesarias para solventar los requerimientos de este proyecto: genera páginas HTML con los gráficos, es capaz también de generar alarmas (de esta manera no hace falta usar los mensajes trampa o “traps”, evitando tener el puerto 162 abierto), y es un sistema basado en SNMP (sus desarrolladores lo crearon para poder trabajar, básicamente, con SNMP, aunque permite otros métodos de obtención de datos, como se verá más adelante).

4.3.4 Servidor HTTP

Una vez que tenemos las páginas web con los gráficos de los dispositivos funcionando, se va a montar en nuestra máquina un servidor de páginas web, para que se pueda acceder a las gráficas desde otras máquinas. Para este proyecto se va a emplear el servidor HTTPD de Apache por diferentes motivos: disponibilidad del programa, facilidad de instalación, necesita muy pocos recursos y podemos obtenerlo de manera gratuita.

29

Actualmente se cuenta con dos versiones de este software, Apache 1.x y Apache 2.x. La versión 1.x aún se encuentra activa y en desarrollo, lo cual implica que no se hará obsoleta en pocos años. La versión 2.x, cuenta con una serie de funcionalidades nuevas que la hacen más eficiente en sistemas no Unix. Muchos de sus módulos han sido simplificados, al igual que el archivo de configuración principal. Instalando esta versión, nos evitamos también el tener que realizar una migración de la versión 1.x a la 2.x en un futuro.

Por todos los motivos explicados anteriormente, se decide instalar Apache2.

4.3.5 Análisis de herramientas para la comunicación de redes IP y GSM

Por último, nos hará falta un software o librería capaz de comunicar redes IP (Internet Protocol) con redes GSM (Global System for Mobile communications, Sistema Global para las Comunicaciones Móviles), de tal manera que podamos enviar alarmas (a través de mensajes SMS) sobre los eventos excepcionales ocurridos en los dispositivos, al teléfono móvil del administrador de la red.

En la distribución Debian, dos son las principales librerías que nos ofrecen este tipo de servicio: alamin y gnokii. Alamin es un proyecto español basado en el proyecto Gnokii. Su utilización más habitual, es la de pasarela para el envío de alarmas desde una red de ordenadores a un dispositivo móvil, informando de la gestión de la red. Otro uso muy común que se le da actualmente es, como aplicación para mostrar los SMS que los teleespectadores envían a los programas de televisión. Actualmente se encuentra en desarrollo, en espera de añadir nuevas funcionalidades, siendo un programa muy completo. Cuenta con la desventaja de que el número de dispositivos móviles que se ha testeado con este programa, aún no es muy amplio.

Gnokii es un programa de similares características, pero lleva más tiempo en desarrollo lo que lo hace más fiable además de contar con una configuración muy sencilla. Cuenta con un abanico de soporte de teléfonos móviles más amplio. Estas características hacen que seleccionemos Gnokii como software para la realización de este último punto.

4.4 Conclusiones

En este capítulo se ha tratado de recopilar de una manera global los requerimientos y las decisiones de este proyecto. Como se ha comprobado, la gran mayoría de estos requerimientos se han seleccionado en función de la propia topología de la red y de las necesidades del cliente. De aquí se puede deducir, que la manera de implantar un sistema de gestión de red no es única, lo que conlleva a que actualmente no exista un estándar para poder llevar a cabo esta tarea. Hay que tratar de realizar un buen estudio de la red y tener claras las capacidades con las que se quiere dotar al sistema de gestión, para que el funcionamiento del sistema sea lo más óptimo posible en nuestra red.

30

Una vez recopilados todos los requerimientos necesarios, en el siguiente capítulo se explicarán con más detalle cada uno de ellos. Se hará siguiendo el mismo orden en el que se ha realizado el proyecto.

31

CAPÍTULO 5. DESARROLLO PRÁCTICO

Este es el capítulo más práctico de todo el proyecto. Aquí se detallará paso a paso la configuración de todo el software que ha aparecido en capítulos anteriores. Como ya se ha explicado anteriormente, no se puede tratar como un manual global o estándar, sino de un manual para la red con la que se está trabajando en este proyecto. Aún así, también puede servir de punto de partida para implantar sistemas de gestión en otro tipo de redes.

Por motivos de seguridad para la red de Cebanc-Cdea, algunos de los archivos de configuración que se van detallar, no aparecen exactamente de la manera en la que se han implementado (como por ejemplo, los nombres de comunidades, grupos o direcciones IP).

El desarrollo de este capítulo se realizará en el siguiente orden: inicialmente se tratará la instalación y configuración de los agentes tanto en Linux como en Windows; posteriormente pasaremos a la instalación y configuración de la herramienta de monitorización (MRTG) y del servidor web (Apache). El capítulo concluye detallando el uso del software para comunicar redes IP y GSM (Gnokii).

5.1 Instalación, configuración y pruebas de los agentes

Como ya se ha comentado, cada dispositivo gestionado contará con un agente para poder comunicarse con la entidad gestora. En la propia entidad gestora también se instalará el agente, de tal manera que se puedan hacer pruebas en el propio servidor (utilizaremos nuestro servidor, como entidad gestora y dispositivo a gestionar). Además la configuración de este agente, será diferente a la del resto de dispositivos a gestionar, ya que este contará con un agente Linux, mientras que el resto utilizarán uno para Windows.

En el caso de los servidores (o máquinas terminales), los agentes y el servicio SNMP, no vienen instalados por defecto en el S.O. A continuación explicaremos los dos casos que se han utilizado en este proyecto.

5.1.1 Linux – Debian (Net-SNMP)

La librería Net-SNMP es una de las más conocidas y utilizadas en plataformas Linux. De hecho las distribuciones más importantes de este S.O. siempre la añaden entre sus aplicaciones. La versión utilizada, para la distribución en Debian, ha sido la 5.1.2. Esta librería cuenta con diferentes paquetes de los cuales nos interesan dos:

• snmp (5.1.2-6.1) Net-SNMP Apps: en este paquete se encuentran las aplicaciones NET-SNMP, que son una colección de comandos para los clientes, para poder publicar las peticiones SNMP a los agentes

• snmpd (5.1.2-6.1) Net-SNMP Agents: es el agente Net-SNMP. Es un servicio (en Linux también conocido como demonio) que se queda a la escucha de peticiones SNMP desde los clientes y proporciona respuestas.

32

Para realizar su instalación desde la línea de comandos, lo primero que se deberá hacer es acceder como superusuario a través del comando su, y luego ayudarnos del comando apt-get para la instalación del paquete, como se muestra en la figura 10.

rmartin@sojos:~$ suPassword:sojos:/home/rmartin# apt-get install snmp

(fig 10, instalación del paquete snmp a través del comando apt-get)

Una vez instalado el agente y sus aplicaciones, tan sólo habrá que configurarlo según las necesidades del equipo en el que va a estar instalado. La propia librería incluye suficiente documentación para describir los diferentes archivos de configuración. El fichero que más nos va a interesar es el snmpd.conf, que en nuestro caso se encuentra en /etc/snmp/

Las primeras definiciones en el archivo de configuración se refieren al modo de acceder al agente desde cualquier servidor. Su funcionamiento es un poco complejo, debido a que este agente da soporte para las 3 versiones del protocolo y si recordamos, la seguridad en las dos primeras versiones se basa en comunidades, mientras que en la última se realiza a través de usuarios.

Ya se explicó en el capítulo anterior que la versión del protocolo que se utilizará en este proyecto es la SNMPv2, por lo tanto realizaremos la configuración del agente basándonos en las comunidades.

Lo primero que se ha de definir son los nombres de comunidad en función de dónde se haga la petición y del grupo de seguridad. Se verá más claro con un ejemplo como el de la figura 11.

# Mapear el nombre de comunidad en un nombre de seguridad # (dependiendo de donde provenga la petición)

# sec.name source communitycom2sec readonly default publiccom2sec readwrite 127.0.0.1 private

(fig. 11, definición de los nombres de comunidad y grupos asignados)

En este caso, se está indicando que para acceder desde cualquier servidor a este se hará dentro del grupo readonly y con el nombre de comunidad public. El propio servidor (127.0.0.1) puede acceder a sí mismo a través del grupo readwrite y con el nombre de comunidad private. Ya se comentó, que los nombres de comunidad eran por defecto los que aparecen aquí. Es en este momento cuando se deben de cambiar los nombres por otros, para aumentar la seguridad de acceso al sistema.

A continuación se debe definir una relación entre modelos de seguridad y grupos, como se muestra en la figura 12.

Todos los accesos como comunidad public desde cualquier lugar se incluyen en el grupo MyROGroup, mientras que los accesos como comunidad private desde el propio servidor se añaden al grupo MyRWGroup.

33

# Asignacion de grupos (mapear los nombres de seguridad en grupos)group MyRWGroup v1 readwritegroup MyRWGroup v2c readwritegroup MyRWGroup usm readwrite

group MyROGroup v1 readonlygroup MyROGroup v2c readonlygroup MyROGroup usm readonly

(fig. 12, relación entre modelos de seguridad y grupos)

Para que quede más claro; hasta ahora tenemos dos grupos de acceso: MyROGroup y MyRWGroup y que están ligados a los grupos de seguridad readonly y readwrite, respectivamente. En readonly se encuentran todos los accesos que se hagan desde cualquier lugar y utilizando el nombre de comunidad public. Mientras que en readwrite sólo se encuentra el propio servidor que podrá acceder a sí mismo utilizando la comunidad private.

A continuación, se definen las vistas (figura 13). Con esto se indica a qué zonas de la MIB tiene acceso cada grupo.

# Vistas (accesos permitidos a la MIB)# incl/excl subtree mask view all included .1 80view system included .iso.org.dod.internet.mgmt.mib-2.system

# Especificar los permisos de los grupos# group context sec.model sec.level prefix read write notifaccess MyROGroup "" any noauth exact all none noneaccess MyRWGroup "" any noauth exact all all none

# Datos informativos de contactosyslocation Servidor Linux en dptoInformaticasyscontact Raul Martin (dptoinformatico@cebanc.com)

(fig. 13, definición de vistas y tipo de acceso) Con esta configuración se garantiza el acceso de escritura al grupo MyRWGroup

a cualquier zona de la MIB, mientras que sólo se permite leer dentro de la vista system al grupo MyROGroup que es de sólo lectura.

Con esto ya tenemos nuestro agente de Linux configurado. A continuación hay que lanzar el proceso snmpd y comprobar que se encuentra escuchando en el puerto 161, como se ve en la figura 14.

sojos:/home/rmartin# cd /etc/init.dsojos:/etc/init.d# snmpd startsojos:/etc/init.d# netstat -anp -uActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nameudp 0 0 0.0.0.0:9 0.0.0.0:* 1 167/inetdudp 0 0 0.0.0.0:161 0.0.0.0:* 1 178/snmpd

(fig. 14, proceso snmp escuchando en el puerto 161 a través del protocolo UDP)

34

Es importante tener en cuenta que cada vez que modifiquemos algo en este archivo de configuración, para que los cambios tengan efecto, se deberá de reiniciar el servicio. En Debian se puede realizar fácilmente con el comando restart.

Una vez que tenemos el agente configurado, y el proceso snmpd en ejecución, podemos comenzar a utilizar las herramientas de gestión incluidas en el paquete snmp. Con estas herramientas podremos utilizar todas esas funciones que se comentaron en el capítulo 3 (GetRequest, GetNextRequest, etc).

Las herramientas (o comandos) con las que contamos son las siguientes:

• snmpget: se utiliza para obtener datos de un dispositivo dado su nombre y un OID (figura 15).

sojos:/# snmpget -c 2nmp -v2c localhost system.sysUpTime.0SNMPv2-MIB::sysUpTime.0 = Timeticks: (197601694) 22 days, 20:53:36.94

(fig. 15, salida del comando snmpget)

En esta orden se indica, el nombre de la comunidad de acceso public, la versión a utilizar, la 2 (2c), el nombre del dispositivo que queremos gestionar (localhost o su IP 127.0.0.1) y el OID, system.sysUpTime.0

También podemos realizar múltiples consultas en una única orden (figura 16).

sojos:/# snmpget -c 2nmp -v2c localhost sysUpTime.0 sysName.0SNMPv2-MIB::sysUpTime.0 = Timeticks: (197604978) 22 days, 20:54:09.78SNMPv2-MIB::sysName.0 = STRING: sojos

(fig. 16, salida del comando snmpget con múltiples variables)

• snmpgetnext: este comando es similar al anterior, salvo que en vez de devolver el valor del OID que nosotros le indiquemos, nos devolverá el siguiente. Se suele utilizar para poder recorrer de forma manual el árbol MIB, indicando siempre el último OID solicitado (figura 17).

sojos:/# snmpgetnext -c 2nmp -v2c localhost sysUpTime.0SNMPv2-MIB::sysContact.0=STRING:Raul (dptoinformatico@cebanc.com)

(fig. 17, salida del comando snmpgetnext)

• snmpwalk: con este comando se realizan getnexts de manera automática. Es más cómodo para recorrer los valores del árbol MIB. En la figura 18 se muestra cómo recorrer sólo el módulo system.

sojos:/# snmpwalk -c 2nmp -v2c localhost systemSNMPv2-MIB::sysDescr.0 = STRING: Linux sojos 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10SNMPv2-MIB::sysUpTime.0 = Timeticks: (197612307) 22 days, 20:55:23.07SNMPv2-MIB::sysContact.0 = STRING: Raul Martin (rmartinr@euskalnet.net)SNMPv2-MIB::sysName.0 = STRING: sojosSNMPv2-MIB::sysLocation.0 = STRING: Servidor Linux en dptoInformatica

35

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (12) 0:00:00.12SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIBSNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIBSNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIBSNMPv2-MIB::sysORID.4 = OID: IP-MIB::ipSNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIBSNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroupSNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBComplianceSNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDComplianceSNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance...

(fig. 18, salida del comando snmpwalk)

• snmpset: este comando se utiliza para modificar información del dispositivo a gestionar (figura 19).

sojos:/# snmpget -v2c -c public localhost systContact.0SNMPv2-MIB::sysContact.0 = STRING: Raul Martin (dptoinformatico@cebanc.com)sojos:/# snmpset -v2c -c public localhost systContact.0 s "Administrador"SNMPv2-MIB::sysContact.0 = STRING: Administradorsojos:/# snmpget -v2c -c public localhost systContact.0SNMPv2-MIB::sysContact.0 = STRING: Administrador

(fig. 19, utilización del comando snmpset)

Vemos en la línea de comandos que antes de indicar el valor nuevo de la variable hay indicada una “s”; esto es para indicar el tipo del valor

de la variable (en este caso string). Para conocer el resto de tipos de variables podemos ejecutar el siguiente comando ‘snmpset –h | tail -4’

• snmpstatus: permite acceder al estado del agente (podemos comprobar si éste se encuentra activo, figura 20)

sojos:/# snmpstatus -v2c -c 2nmp localhost[127.0.0.1]=>[Linux sojos 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686] Up: 22 days, 21:10:28.03Interfaces: 0, Recv/Trans packets: 1206861/1206861 | IP: 3678133/4154461

(fig. 20, salida del comando snmpstatus)

• snmptranslate: con esta orden podemos pasar un OID a la variable que representa. Muy útil a la hora de explorar el árbol MIB (figura 21).

sojos:/# snmptranslate .1.3.6.1.2.1.1.3.0SNMPv2-MIB::sysUpTime.0

(fig. 21, salida del comando snmptranslate)

• snmpnetstat: comando similiar al ‘netstat’ de Linux, pero utilizando el agente SNMP para obtener la información (nos muestra una lista de los puertos abiertos en una máquina, figura 22).

36

sojos:/# snmpnetstat -v2c -c 2nmp localhostActive Internet (tcp) ConnectionsProto Local Address Foreign Address (state)tcp sojos.cebancdea.edu.ssh 192.16.51.18.1361 ESTABLISHEDActive Internet (udp) ConnectionsProto Local Addressudp *.discardudp *.sunrpcudp *.snmpudp *.947udp *.950udp *.10000udp *.46745

(fig. 22, salida del comando snmpnetstat)

Además de estos comandos, la librería Net-SNMP presenta algunos más que son menos conocidos y menos utilizados (‘snmpdelta’ o ‘snmptest’). Aquí se ha presentado la forma más sencilla y común de utilizarlos, pero cada comando presenta muchas opciones que se pueden consultar a través del parámetro --help (Ej: ‘snmpget –help’).

De todos los presentados aquí, para este proyecto los que más van a interesar son básicamente dos: snmpget y snmpwalk. El comando snmpset, suele ser también muy utilizado, pero tras consultarlo con el cliente y sus necesidades, no se consideró necesario usarlo. Además, teniendo en cuenta que vamos a utilizar la versión SNMPv2 con una seguridad sólo basada en comunidades, es interesante tener “desactivado” ese comando. En el archivo de configuración del agente (/etc/snmp/snmpd.conf), tenemos indicado que todas las consultas SNMP que se hagan desde cualquier máquina que no sea la propia (localhost o 127.0.0.1), sean solo de tipo lectura (sólo se podrán obtener datos, nunca modificarlos).

Como ya se ha comentado, la instalación de este agente en este proyecto, tan solo se ha utilizado para realizar las primeras pruebas sobre la propia máquina, y también para poder aprender como configurar un agente en Linux.

5.1.2 Otros agentes SNMP para Linux

Aunque el agente Net-SNMP es posiblemente el más utilizado y el que en más distribuciones aparece, no es el único dentro del mundo Linux. También existen otros como:

• SNMP++, programado en lenguaje C++ pero que sólo soporta las dos primeras versiones del protocolo SNMP, y cuya licencia de distribución no es libre.

• Agent++, basado en el anterior y de similares características salvo que soporta todas las versiones de SNMP.

• Opennms, es una librería en Java desarrollada por el proyecto Open Network Managment (Gestión Abierta de Redes). Se caracteriza por incluir varios agentes, desde el propio agente que se encarga de comunicarse con la entidad gestora, hasta agentes para poder procesar alarmas.

37

Una vez vistos los agentes para Linux, en el próximo apartado se comentará la configuración de los agentes de los dispositivos a gestionar (11 servidores con plataforma Windows: 1 con Windows 2000, 10 con Windows 2003).

5.1.3 Windows 2000, Windows 2003 Server

El agente que ofrece Windows es el mismo para las versiones 2000, 2003 Server y XP, por lo que su configuración es similar. El servicio SNMP en Windows, actualmente soporta, pero no incluye software de administración. El software de administración es el que debe de instalarse en la entidad gestora, para que se encargue de la administración. Aquí obtenemos otro motivo más, para haber utilizado en nuestra entidad gestora la plataforma Linux.

Para instalar el protocolo SNMP y su agente en Windows:

• Iniciar el Asistente para componentes de Windows al que se accede a través del menú Panel de Control -> Agregar o quitar programas -> Agregar o quitar componentes de Windows. Marcamos la opción Herramientas de administración y supervisión y vemos los detalles como muestra la figura 23.

(fig 23, panel de instalación del agente SNMP en Windows)

Marcamos la opción que incluye el agente. Tras la instalación el servicio SNMP se iniciará automáticamente. Lo podremos comprobar en la lista de

38

servicios a la que se accede desde el menú Herramientas Administrativas (figura 24).

(fig. 24, estado del servicio SNMP)

Accedemos a la configuración del servicio seleccionándolo y desde el menú Acción haciendo clic en Propiedades; se muestra en la siguiente figura.

(fig. 25, panel de propiedades del servicio SNMP)

En la ficha Agente, indicamos un nombre de contacto para el servidor y su ubicación. Las opciones del menú Servicio se detallan en la figura 26.

Teniendo en cuenta estas opciones, en nuestros servidores marcamos las opciones “Aplicaciones” y “De un extremo a otro” (ver figura 25).

39

(fig. 26, detalles de las opciones del menú Servicio)

40

(fig. 27, panel de configuración de Seguridad del servicio SNMP)

En la ficha Seguridad, que se muestra en la figura 27, se indican los nombres de comunidad y qué derechos tiene cada una de las comunidades que indiquemos. Como ya se ha comentado varias veces, en nuestro caso sólo se va a obtener información de estos dispositivos, por lo que los derechos de la comunidad serán de sólo lectura. Además también, podemos señalar desde qué máquinas se pueden aceptar paquetes SNMP. Aquí indicaremos la dirección IP (o el nombre) de nuestra entidad gestora. De esta forma nos aseguramos que sólo se va a poder gestionar el dispositivo desde nuestra entidad gestora. Marcamos también la opción “Enviar captura de autenticación”, que servirá para comprobar si los paquetes SNMP se reciben desde direcciones IP válidas. Si esto no fuera así, porque la dirección IP (o nombre de la máquina) o el nombre de la comunidad no son correctos, se enviaría desde el agente un mensaje de error hacia la entidad gestora.

En el resto de fichas, para las necesidades de este proyecto, no se hará prácticamente ninguna modificación:

41

o Capturas: se refiere a los ‘traps’ (alarmas de eventos excepcionales) comentados en el capítulo anterior. Más adelante se explicará como se realizan estas alarmas sin tener que utilizar estos mensajes trampa.

o Dependencias: muestra los servicios que dependen del servicio SNMP; útil cuando se va a detener o reiniciar el proceso.

o General: muestra información sobre el servicio (nombre, descripción, estado, etc)

o Iniciar sesión: esto es útil si se tienen diferentes cuentas de acceso en la máquina gestionada, para habilitar o deshabilitar el servicio a cada una de las cuentas

o Recuperación: muestra una serie de opciones a realizar en caso de que el servicio no funcione (indicamos que se vuelva a reiniciar el servicio)

Otro problema que surgió durante el desarrollo del proyecto, fue la disponibilidad de determinados datos en estos servidores. Con esta instalación, sólo se tiene acceso a los datos que ofrece la MIB estándar (MIB-II). Datos como el número de procesos o sesiones no se pueden obtener de esta MIB, por lo que fue necesario el uso y la instalación de dos MIBs nuevas:

• HOST-RESOURCES-MIB con OID 1.3.6.1.2.1.25 y que como su propio nombre indica es una MIB especialmente dedicada a recursos de servidores.

• SNMP4W2K-WINDOWS-2000-PERFORMANCE con OID 1.3.6.1.4.1.311.1.1.3 destinada a gestionar parámetros de máquinas con un S.O. Windows.

Generalmente las MIBs suelen ser librerías dinámicas (.dll) o archivos de texto (.txt, .mib) que se encuentran en la carpeta C:\Windows\System32.

En los sistemas Linux la gran mayoría son archivos con extensión .txt y se encuentran por defecto en la ruta /usr/share/snmp/mibs.

Una vez configurados los agentes de los servidores Windows, lo siguiente es realizar pruebas para comprobar que tenemos conexión vía SNMP. Las pruebas se realizan utilizando desde la entidad gestora los comandos indicados para Linux, indicando en este caso el nombre de la comunidad que hayamos definido en los agentes de Windows (por motivos de seguridad no se menciona en este documento), e indicando también la dirección IP del servidor que queramos gestionar.

Con todo esto, ya podemos administrar nuestros dispositivos. Surge un nuevo problema, y es que la solicitud y obtención de datos a través de la línea de comandos de Linux, no resulta muy atractiva y tampoco nos ofrece excesiva información. Es decir, por ejemplo, si solicitamos el espacio libre del disco duro de un servidor, este nos devolverá un número del tipo 256489127, lo cual no nos dice nada.

Llega el momento de monitorizar los datos, y para ello lo haremos mediante gráficas, y más concretamente con el paquete de libre distribución MRTG. Su configuración e instalación, se detallan a continuación.

42

5.2 Instalación y configuración de MRTG

Es una de las herramientas de monitorización de dispositivos más importantes para plataformas Linux. Se encuentra programado por Tobias Oetiker y Dave Rand en Perl y C. En el caso más general se utiliza tan sólo para monitorizar el tráfico en diferentes dispositivos, pero profundizando en su configuración, podemos representar todo aquello que el protocolo SNMP y las MIB nos ofrezcan (ó incluso datos que nos ofrezca otro programa externo).

Los gráficos que genera, además de ofrecer una vista diaria, representan también la información de la última semana, último mes y último año. Esto es posible, gracias a que MRTG contiene un archivo donde recopila los datos obtenidos del dispositivo de red durante un tiempo máximo de 2 años.

Al ser un software tan demandado y utilizado, muchas distribuciones Linux cuentan con esta librería, como es el caso de Debian. Como siempre para instalar los diferentes paquetes utilizaremos el comando ‘apt-get’ y siendo superusuario (comando ‘su’). Los paquetes necesarios son:

• mrtg (2.10.13-1.2): contiene el propio programa• mrtgutils (0.5): son las utilidades necesarias para que MRTG pueda

generar las estadísticas• mrtg-contrib (2.10.13-1.2): archivos necesarios, por ser MRTG un

programa libre, pero que depende de otros programas que no lo son

sojos:/# apt-get install mrtg mrtgutils mrtg-contrib

(fig. 28, instalación de los módulos necesarios para MRTG)

MRTG suele basar su configuración en el archivo /etc/mrtg.cfg. Por normal general, en este archivo se guarda toda la configuración de todos los dispositivos. En nuestro caso, al tener un número importante de dispositivos a gestionar y sobre todo una gran cantidad de parámetros de cada uno, se decidió realizar un archivo de configuración por cada tipo de parámetro a administrar. De esta forma, en nuestra entidad gestora, en el directorio /etc/ nos encontramos los siguientes archivos de configuración:

• mrtgcpu.cfg: archivo de configuración referente a la tasa de CPU utilizada por cada servidor gestionado

• mrtgdiscos.cfg: aquí se configura el espacio libre en los discos duros de cada servidor gestionado

• mrtgfreemem.cfg: archivo de configuración sobre la memoria RAM disponible en cada servidor gestionado

• mrtgnumprocses.cfg: archivo de configuración referente al número de procesos en ejecución y el número de sesiones abiertas en cada servidor gestionado

• mrtgonoff.cfg: en este archivo se configura el estado de los servidores (encendido ó apagado)

43

• mrtgredservers.cfg: desde aquí queda configurado el tráfico entrante/saliente de cada una de las interfaces de red de cada servidor (ya que hay servidores con más de una interfaz de red)

• mrtgroutercisco.cfg: configuración del tráfico de red entrante/saliente del router Cisco

A continuación se detallarán cada uno de estos archivos. Para no hacer un documento muy pesado, no se presentará todo el archivo (ya que en determinados casos es muy repetitivo), sino lo más importante de cada uno.

mrtgcpu.cfg

### Ultima actualizacion: 11/08/05

### mrtgcpu.cfg - Archivo de configuracion para representar el porcentaje de uso de cpu en los servidores, tanto por usuario como por el sistema

### Global Config Options# for DebianWorkDir: /var/www/mrtg

### Global Defaults

MaxBytes[_]: 100Unscaled[_]: ymwdShortLegend[_]: %YLengend[_]: Uso de CPULegend1[_]: Usuario CPU % (Load)Legend2[_]: Sistema CPU % (Load)LegendI[_]: UsuarioLegendO[_]: SistemaThreshMaxO[_]: 99ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarmaThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok Options[_]: growrigth,nopercent,unknaszero,gauge,noinfoWriteExpires: YesLanguage: spanishEnableIPv6: noInterval: 5Refresh: 300ThreshDir: /home/rmartin/mrtg/alarmas/threshdir

(fig. 29, opciones globales para el archive mrtgcpu.cfg)Las primeras líneas de cada uno de los archivos de configuración se utilizan para

indicar la última modificación del archivo y una breve descripción de lo que contiene.

La primera palabra clave que aparece es WorkDir. Aquí se especifica donde se crearán los archivos log (archivos de registro) y las páginas web.

Las siguientes opciones, son opciones globales para todos los dispositivos que aparezcan a continuación. En MaxBytes, indicamos el valor máximo que los dos parámetros supervisados (ya que por cada gráfico podemos representar dos parámetros) pueden alcanzar. En este caso hemos indicado un valor de 100, ya que estamos gestionando la tasa de uso de CPU, que nos devolverá unos valores que oscilarán entre 0 y 100.

44

Cada gráfico se escala verticalmente para hacer que los datos actuales sean visibles incluso cuando son muy inferiores a MaxBytes. Esto se puede suprimir utilizando la opción Unscaled. Se indican con una letra que gráfico no se quiere escalar (d=dia, w=semana, m=mes, y=año).

Las siguientes 6 opciones, se refieren a las leyendas que aparecerán posteriormente en el documento HTML que contiene las gráficas.

A continuación aparecen opciones más interesantes (el resto, son básicamente para configurar los gráficos). ThreshMaxO, este es el valor máximo aceptable para el parámetro Output o de salida (el segundo). En este caso cuando el parámetro Output supere el valor 99, se ejecutará el programa indicado en ThreshProgO. Cuando el parámetro Output, sea inferior a 99 se ejecutará el programa especificado en ThreshProgOKO. Para realizar lo mismo, pero con el primer parámetro (Input o de entrada), se utilizan ThreshMaxI, ThreshProgI y ThreshProgOKI.

En Options, se indican otro tipo de opciones para los gráficos: growright, para conseguir que el gráfico se desplace de derecha a izquierda (el valor más actual a la derecha del gráfico, y los históricos a su izquierda); nopercent, no imprime los porcentajes en las gráficas. En este caso no tiene mucho sentido volver a indicar los porcentajes, ya que los datos que estamos representando son porcentajes. En el caso, por ejemplo, del espacio libre en el disco duro, sí nos puede interesar además del valor en sí, cuál es el porcentaje libre con respecto al total; unknaszero, en caso de que se obtuviera un valor desconocido se registraría como un 0 en vez de repetir el último valor, que es la opción por defecto; gauge, trata los valores obtenidos como medidas del estado actual y no como incrementos; noinfo, suprime la información sobre el tiempo en funcionamiento y nombre del dispositivo en la página web generada.

Languaje, muestra las páginas web en el idioma que indiquemos (es=español).

EnableIPv6, MRTG soporta la versión 6 del protocolo IP. Nuestra red, actualmente utiliza la versión 4, por lo que desactivamos esta opción.

Interval, aquí se indica cada cuanto se testean o gestionan los datos, No se puede poner un valor inferior a 5 minutos (en parte es lógico, si estuviéramos testeando datos, por ejemplo cada minuto, podríamos saturar la red). Más adelante, comprobaremos que esto se puede especificar de otra forma.

Refresh, número de segundos que tardará la página web en actualizarse (minímo 300 segundos).

Threshdir, definiendo esta opción que apunta a un directorio escribible, MRTG solo alertará cuando se sobrepase algún límite del umbral. Por ejemplo, en este caso, si en un momento dado la CPU se satura y se obtiene un porcentaje de uso de 100, saltará la alarma, si en el próximo testeo (a los 5 minutos), sigue teniendo un uso de 100, no volverá a saltar. Esto es para evitar que se envíen gran cantidad de alarmas. Cuando el uso de CPU baje del umbral indicado (99), se enviará otra alarma (la especificada en ThreshProgOKO), indicando que el problema ya se encuentra resuelto.

45

A continuación se presentan las opciones dedicadas a cada servidor (figura 30). Como las opciones son similares, sólo se muestran las de los dos primeros servidores.

########################################################## Tasa de CPU por usuario y sistema en el servidor NTSQL2#########################################################Target[ntsql2-cpu]: 1.3.6.1.4.1.311.1.1.3.1.1.2.1.4.6.95.84.111.116.97.108&1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.6.95.84.111.116.97.108:nombrecomunidad@192.16.41.103Title[ntsql2-cpu]: NTSQL2 - CPU LOADPageTop[ntsql2-cpu]: <H1>NTSQL2 - CPU (Usuario y Sistema) Load %</H1>

########################################################### Tasa de CPU por usuario y sistema en el servidor NTMail2##########################################################Target[ntmail2-cpu]: 1.3.6.1.4.1.311.1.1.3.1.1.2.1.4.6.95.84.111.116.97.108&1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.6.95.84.111.116.97.108:nombrecomunidad@192.16.41.2Title[ntmail2-cpu]: NTMail2 - CPU LOADPageTop[ntmail2-cpu]: <H1>NTMAIL2 - CPU (Usuario y Sistema) Load %</H1>

(fig. 30, implementación parcial del archivo de configuración mrtgcpu.cfg)

En Target, se decide lo que debe monitorizar MRTG. En este caso, son dos OIDs en los que se encuentran el valor de uso de CPU por el usuario y por el sistema. El primero representa el valor de entrada (input) y el segundo el de salida (output). También hay que especificar el nombre de comunidad y la dirección IP del dispositivo. Entre corchetes se indica un nombre de etiqueta. Para este proyecto hemos decidido utilizar el nombre del servidor seguido del parámetro a gestionar.

Title sirve para especificar el título de la página HTML generado para el gráfico, y PageTop para la cabecera de título.

El resto de archivos tiene una configuración similar; a partir de ahora tan sólo se detallarán aquellas opciones nuevas que surjan y todo aquello que sea reseñable.

mrtgdiscos.cfg

### Ultima actualizacion: 28/07/05

### mrtgdiscos.cfg - Archivo de configuración para representar la capacidad de los discos duros

ThreshMinO[_]: 10%ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarmaThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok

################################################################## Espacio total y espacio libre del HD Datos del servidor NTMail2#################################################################Target[ntmail2-discoe]: `/home/rmartin/mrtg/snmpscripts/snmp_hdfree 192.16.41.2 nombrecomunidad 4`MaxBytes[ntmail2-discoe]: 62305316864

###################################################################

46

# Espacio total y espacio libre del HD Sistema del servidor NTMail2###################################################################Target[ntmail2-discoc]: `/home/rmartin/mrtg/snmpscripts/snmp_hdfree 192.16.41.2 nombrecomunidad 2`MaxBytes[ntmail2-discoc]: 10482400768

(fig. 31, implementación parcial del archivo mrtgdiscos.cfg)

Esto es parte del archivo de configuración, en el que se monitorizan por cada gráfica el espacio total de cada disco duro de cada servidor y el espacio libre. En este caso se utiliza la opción ThreshMinO, la alarma saltará cuando el valor obtenido sea menor que el indicado en esta opción. Vemos que el valor es un porcentaje, de esta forma conseguimos que las alarmas salten cuando quede menos del 10% de espacio libre.

Para obtener los datos, en esta ocasión se utiliza un script. A la hora de utilizar scripts en Target hay que tener en cuenta que debe devolver cuatro valores:

• 1: el estado actual del parámetro de entrada (en este caso el espacio total)• 2: el estado actual del parámetro de salida (el espacio libre)• 3: el tiempo de funcionamiento del dispositivo• 4: el nombre del dispositivo

En la figura 32 se muestra el código del script (snmp_hdfree) al que se le pasa como parámetros la dirección IP del dispositivo, el nombre de comunidad y un índice.

# Script para obtener el espacio libre del HD# Parametros de entrada: $1 direccion ip del dispositivo# $2 nombre de la comunidad de lectura del dispositivo# $3 indice del disco duro en el OID de la MIB

#Obtener el espacio totalHDTotal=`snmpget -v2c -c $2 $1 hrStorageSize.$3 | gawk '{print $4}'`#Obtener el espacio usadoHDUsado=`snmpget -v2c -c $2 $1 hrStorageUsed.$3 | gawk '{print $4}'`#Obtener las unidades en las que se miden los datos anterioresUnidad=`snmpget -v2c -c $2 $1 hrStorageAllocationUnits.$3 | gawk '{print $4}'`

#Obtener el espacio total, ya multiplicado por las unidadesespacioTotal=$(((HDTotal)*Unidad))

#Obtener el espacio libreespacioLibre=$(((HDTotal-HDUsado)*Unidad))

echo $espacioLibreecho $espacioTotal

#Obtener el tiempo de funcionamientoTiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`echo $Tiempo

#Obtener el nombre de la máquinaNombre=`snmpget -v2c -c $2 $1 sysName.0 | gawk '{print $4}'`echo $Nombre

(fig. 32, implementación del script snmp_hdfree)

mrtgfreemem.cfg

### Ultima actualizacion: 29/07/05

47

### mrtgfreemem.cfg - Archivo de configuracion para representar la memoria libre de los servidores

ThreshMinO[_]: 5%ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarmaThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok

########################### Memoria libre en NTMail2##########################Target[ntmail2-freemem]: `/home/rmartin/mrtg/snmpscripts/snmp_winmemfree 192.16.41.2 nombrecomunidad 6`Title[ntmail2-freemem]: NTMail2 - Memoria libre

########################### Memoria libre en NTWeb##########################Target[ntweb-freemem]: `/home/rmartin/mrtg/snmpscripts/snmp_winmemfree 192.16.41.108 nombrecomunidad 6`Title[ntweb-freemem]: NTWeb - Memoria libre

(fig. 33, implementación parcial del archive mrtgfreemem.cfg)

En este caso se trata de monitorizar la memoria RAM disponible en cada ordenador. Como hay que representar dos parámetros, monitorizamos también la memoria total. Y de esta forma se generan las alarmas cuando la memoria libre se encuentre por debajo del 5% del total. Al igual que en el caso anterior, aquí también se obtienen los datos a través del siguiente script , representado en la figura 34.

# snmp_winmemfree: script para obtener la memoria libre de un servidor windows# Parametros de entrada: $1 direccion ip del dispositivo# $2 nombre de la comunidad de lectura del dispositivo# $3 indice de la memoria RAM disponbile en el OID de la MIB

total=`snmpget -v2c -c $2 $1 .1.3.6.1.4.1.311.1.1.3.1.1.1.2.0 | gawk '{print $4}'`libre=`snmpget -v2c -c $2 $1 .1.3.6.1.4.1.311.1.1.3.1.1.1.2.$3 | gawk '{print $4}'`

echo $totalecho $libre

#Obtener el tiempo de funcionamientoTiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`echo $Tiempo

#Obtener el nombre de la máquinaNombre=`snmpget -v2c -c $2 $1 sysName.0 | gawk '{print $4}'`echo $Nombre

(fig 34, implementación del script snmp_winmemfree)

mrtgnumprocses.cfg

### Ultima actualizacion: 28/07/05

### mrtgnumprocses.cfg - Archivo de configuracion para representar el numero de procesos y sesiones abiertas de los servidores

48

############################################################################################################## Numero de procesos del sistema (hrSystemProcesses.0)# Numero de sesiones abiertas en el servidor NTMail2 (serverServerSessions.0 - Cargado de la MIB perfmib.mib)# -Windows+SNMP+SNMP4tPC#############################################################################################################Target[ntmail2-procses]: 1.3.6.1.2.1.25.1.6.0&1.3.6.1.4.1.311.1.1.3.1.1.8.16.0:nombrecomunidad@192.16.41.2MaxBytes[ntmail2-procses]: 100

(fig. 35, implementación parcial del archivo mrtgnumprocses.cfg)

En este archivo (figura 35) se configuran los números de procesos en ejecución y sesiones abiertas en cada servidor. Obtenemos los datos a través de los OIDs, proporcionados por la MIB SNMP4W2K-WINDOWS-2000-PERFORMANCE implementada en el archivo perfmib.mib.

En este caso, no se consideró necesario la gestión de alarmas, y el control de sus datos se realizará analizando las gráficas que genere.

mrtgonoff.cfg

### Ultima actualizacion: 28/07/05

### mrtgonoff.cfg - Archivo de configuración para representar el estado de los servidores: 1 encendido, 0 apagado

############################## Estado del servidor NTMail2#############################Target[ntmail2-onoff]: `/home/rmartin/mrtg/snmpscripts/snmp_onoff 192.16.41.2 nombrecomunidad`MaxBytes[ntmail2-onoff]: 1

(fig. 36, implementación parcial del archivo mrtgonoff.cfg)

Aquí se monitoriza el estado de los servidores, si se encuentran encendidos o apagados. Como se puede ver la alarma se genera cuando se obtiene un valor menor que 1. Para conocer el estado del servidor, se ha creado un script que puede devolver dos valores: 1, si el servidor se encuentra encendido, 0 si se encuentra apagado. Por lo tanto en estas gráficas sólo se generarán dos valores 0 ó 1. En la figura 37 se muestra el script para la obtención de los valores.

# Script que comprueba si un dispositivo se encuentra encendido o apagado# Parametros de entrada: $1 direccion ip del dispositivo# $2 nombre de la comunidad de lectura del dispositivo# Salida: 1 si esta encendido# 0 e.o.c

# variable que nos indicara si el dispositivo se encuentra encendido (1) o# apagado (0)estado=0

# recoger lo que que devuelve la consulta snmpget

49

resultado=`snmpget -v2c -c $2 $1 system.sysUpTime.0 | gawk '{print $2}'`

# si devuelve algo es porque el dispositivo se encuentra encendidoif test $resultado then

#si llego aqui es porque el dispositivo esta encendidoestado=1

fi

# Obtener dos veces el mismo parametro para que el MRTG pinte el mismo parametro de entrada y salidaecho $estadoecho $estado

#Obtener el tiempo de funcionamientoTiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`echo $Tiempo

#Obtener el nombre de la máquinaNombre=`snmpget -v2c -c $2 $1 sysName.0 | gawk '{print $4}'`echo $Nombre

(fig. 37, implementación del script para comprobar el estado, on/off, de un dispositivo)

mrtgredservers.cfg – mrtgroutercisco.cfg

En estos dos archivos, se encuentra la configuración referente al tráfico de entrada/salida de cada una de las interfaces de los servidores y del router Cisco. Mientras que el resto de archivos se ha tenido que editar manualmente, para obtener el archivo de configuración de tráfico de red, MRTG presenta el siguiente comando: cfgmaker. En la figura 38, se muestra su utilización.

sojos:/etc# cfgmaker nombrecomunidad@192.16.41.109 >> mrtgroutercisco.cfg

(fig. 38, utilización del comando cfgmaker)

Vemos que hay que indicar el nombre de comunidad y el nombre o dirección IP del dispositivo a gestionar, y todo lo que genere se redirecciona a los archivos de configuración.

### Ultima actualizacion: 27/07/05

### mrtgredservers.cfg - Archivo de configuración para representar el tráfico entrante/saliente en las interfaces de los servidores

###################################################################### System: NTMAIL2# Description: Hardware: x86 Family 6 Model 11 Stepping 1 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Uniprocessor Free)# Contact: Carlos Sanchez# Location: Dpto. Informatico######################################################################

### Interface 65539 >> Descr: 'HP-NC3163-Fast-Ethernet-NIC' | Name: '' | Ip: '192.16.41.2' | Eth: '00-08-02-46-1f-b8' ###

Target[192.16.41.2_65539]: 65539:nombrecomunidad@192.16.41.2:

50

SetEnv[192.16.41.2_65539]: MRTG_INT_IP="192.16.41.2" MRTG_INT_DESCR="HP-NC3163-Fast-Ethernet-NIC"MaxBytes[192.16.41.2_65539]: 60000Title[192.16.41.2_65539]: Análisis de Tráfico -- NTMAIL2PageTop[192.16.41.2_65539]: <H1>Análisis de Tráfico -- NTMAIL2</H1> <TABLE> <TR><TD>System:</TD> <TD>NTMAIL2 in Dpto. Informatico</TD></TR> <TR><TD>Maintainer:</TD> <TD>Carlos Sanchez</TD></TR> <TR><TD>Description:</TD><TD>HP-NC3163-Fast-Ethernet-NIC </TD></TR> <TR><TD>ifType:</TD> <TD>ethernetCsmacd (6)</TD></TR> <TR><TD>ifName:</TD> <TD></TD></TR> <TR><TD>Max Speed:</TD> <TD>12.5 MBytes/s</TD></TR> <TR><TD>Ip:</TD> <TD>192.16.41.2 (ntmail2.cebancdea.edu)</TD></TR> </TABLE>

(fig. 39, implementación parcial del archivo mrtgredservers.cfg creado mediante el comando cfgmaker)

Esta es una parte de lo generado en el archivo mrtgredservers.cfg tras utilizar el comando cfgmaker. A continuación se incluye una parte del archivo mrtgroutercisco.cfg

### Ultima actualizacion: 26/07/05

# Created by /usr/bin/cfgmaker nombrecomunidad@192.16.41.109

####################################################################### System: C1600_CDEA# Description: Cisco Internetwork Operating System Software # IOS (tm) 1600 Software (C1600-Y-M), Version 12.0(12), RELEASE SOFTWARE (fc1)# Copyright (c) 1986-2000 by cisco Systems, Inc.# Compiled Mon 10-Jul-00 19:59 by htseng# Contact: # Location: ######################################################################

### Interface 1 >> Descr: 'Ethernet0' | Name: 'Et0' | Ip: '192.16.41.109' | Eth: '00-02-b9-1d-7e-50' ###

Target[192.16.41.109_1]: 1:nombrecomunidad@192.16.41.109:SetEnv[192.16.41.109_1]: MRTG_INT_IP="192.16.41.109" MRTG_INT_DESCR="Ethernet0"MaxBytes[192.16.41.109_1]: 1250000Title[192.16.41.109_1]: Traffic Analysis for 1 -- C1600_CDEAPageTop[192.16.41.109_1]: <H1>Traffic Analysis for 1 -- C1600_CDEA</H1> <TABLE> <TR><TD>System:</TD> <TD>C1600_CDEA in </TD></TR> <TR><TD>Maintainer:</TD> <TD></TD></TR> <TR><TD>Description:</TD><TD>Ethernet0 JAC044368PU </TD></TR> <TR><TD>ifType:</TD> <TD>ethernetCsmacd (6)</TD></TR> <TR><TD>ifName:</TD> <TD>Et0</TD></TR> <TR><TD>Max Speed:</TD> <TD>1250.0 kBytes/s</TD></TR> <TR><TD>Ip:</TD> <TD>192.16.41.109 ()</TD></TR> </TABLE>

### Interface 2 >> Descr: 'Serial0' | Name: 'Se0' | Ip: '' | Eth: '' ###

51

Target[192.16.41.109_2]: 2:nombrecomunidad@192.16.41.109:SetEnv[192.16.41.109_2]: MRTG_INT_IP="" MRTG_INT_DESCR="Serial0"MaxBytes[192.16.41.109_2]: 193000Title[192.16.41.109_2]: Traffic Analysis for 2 -- C1600_CDEAPageTop[192.16.41.109_2]: <H1>Traffic Analysis for 2 -- C1600_CDEA</H1> <TABLE> <TR><TD>System:</TD> <TD>C1600_CDEA in </TD></TR> <TR><TD>Maintainer:</TD> <TD></TD></TR> <TR><TD>Description:</TD><TD>Serial0 </TD></TR> <TR><TD>ifType:</TD> <TD>frame-relay (32)</TD></TR> <TR><TD>ifName:</TD> <TD>Se0</TD></TR> <TR><TD>Max Speed:</TD> <TD>193.0 kBytes/s</TD></TR> </TABLE>

(fig. 40, implementación parcial del archivo mrtgroutercisco.cfg creado mediante el comando cfgmaker)

En este extracto se ha incluido la configuración de dos de las bocas del router Cisco (Interface1 e Interface2).

En todos los archivos de configuración, se tiene indicado que las variables ThreshProgI y ThresProgOKI (y análogamente ThreshProgO y ThreshProgOKO), ejecuten los programas externos galarma y galarmaok respectivamente. galarma se ejecutará cuando se produzca la alarma y galarmaok cuando el valor del parámetro vuelva a ser correcto. Estos dos scripts, básicamente lo que hacen es recoger los datos del MRTG (dispositivo-parametro, valor del umbral y el valor del parámetro actual), y los envía mediante el comando mail a las direcciones de correo que indiquemos (por ejemplo, a todo el departamento informático). En la figura 41 se muestra su código.

# Script que recoge los datos del MRTG, y crea la alarma que se envia por correo en un archivo# (que tiene por nombre lo que contenga $1)# Parámetros de entrada:# $1: contiene el nombre del dispositivo gestionado y el parámetro que ha hecho generar la alarma# $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente# $3: contiene el valor actual del parametro del dispositivo gestionado, por el cual ha generado la alarma#

# redireccionamos lo que genera la alarma del mrtg a un archivo (de nombre, lo que contenga $1)echo "problema en:" $1 "umbral sobrepasado:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1

# enviamos el archivo a una direccion de correo electrónicomail -s "Alarma desde MRTG" root@debian.raul.es raul@debian.raul.es < /home/raul/mrtg/alarmas/$1

(fig. 41, implementación del script galarma)

El siguiente es el código del archivo galarmaok que funciona de manera similar al anterior:

# Script que recoge los datos del MRTG, y crea la alarma de "problema solucionado" que se envia por correo en un archivo

52

# (que tiene por nombre lo que contenga $1)# Parámetros de entrada:# $1: contiene el nombre del dispositivo gestionado y el parámetro para el que se ha solucionado la alarma# $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente# $3: contiene el valor actual del parametro del dispositivo gestionado#

# redireccionamos lo que genera la alarma del mrtg a un archivoecho "problema solucionado en:" $1 "umbral:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1

# enviamos el archivo a una direccion de correo electrónicomail -s "Alarma CORREGIDA desde MRTG" raul@debian.raul.es < /home/raul/mrtg/alarmas

(fig. 42, implementación del script galarmaok)

Hasta aquí, se ha conseguido que las alarmas que se generen se envíen por correo electrónico. Otra de las capacidades con las que se quiere dotar al sistema de gestión, es la de que se puedan enviar también mediante SMS a un teléfono móvil. Esto se explicará en el último punto de este capítulo.

Una vez que tenemos todos los archivos configurados, lo siguiente es “compilarlos” con el comando mrtg (fig. 5.34). De esta forma, en caso de que hubiese algún error en alguno de los archivos, nos lo mostraría. Si los archivos están correctamente, la primera vez que se haga esto, aparecerán unos cuantos mensajes Warning. Ejecutaremos el mismo comando hasta que no aparezcan.

sojos:/etc# mrtg mrtgnumprocses.cfgsojos:/etc# mrtg mrtgroutercisco.cfgsojos:/etc# mrtg mrtgcpu.cfg...

(fig. 43, “compilación” de los archivos de configuración)

Y de esta misma manera, realizaríamos la compilación del resto de archivos de configuración.

Ahora podemos comprobar que se nos han generado las páginas web, en el directorio indicado en los archivos de configuración (WorkDir: /var/www/mrtg). Se habrán generado archivos html con el nombre que hayamos utilizado en las etiquetas dentro de los archivos de configuración (Ej: ntsql2-cpu.html, ntmail2-cpu.html, ntsql2-disco.html, etc.)

A partir de ahora el mrtg se ejecutará en cada archivo el tiempo que hayamos indicado en cada variable Interval. Podemos comprobarlo, viendo que se ha añadido en el archivo mrtg dentro de /etc/cron.d. Aquí encontraremos todas aquellas tareas que se ejecuten periódicamente (figura 44).

sojos:/etc/cron.d# more mrtg0-55/5 * * * * mrtg /etc/mrtg.cfg >> /var/log/mrtg/mrtg.log0-55/5 * * * * mrtg /etc/mrtgdiscos.cfg >> /var/log/mrtg/mrtgdiscos.log

53

0-55/5 * * * * mrtg /etc/mrtgnumprocses.cfg >> /var/log/mrtg/mrtgnumprocses.log0-55/5 * * * * mrtg /etc/mrtgredservers.cfg >> /var/log/mrtg/mrtgredservers.log0-55/5 * * * * mrtg /etc/mrtgroutercisco.cfg >> /var/log/mrtg/mrtgroutercisco.log0-55/5 * * * * mrtg /etc/mrtgfreemem.cfg >> /var/log/mrtg/mrtgfreemem.log0-55/5 * * * * mrtg /etc/mrtgcpu.cfg >> /var/log/mrtg/mrtgcpu.log0-55/5 * * * * mrtg /etc/mrtgonoff.cfg >> /var/log/mrtg/mrtgonoff.log

(fig. 44, tareas a realizar de manera periódica)

Como se puede observar, cada comando mrtg genera una salida que se redirecciona a unos ficheros de registro (.log). En caso de que sucediera algún problema a la hora de invocar el comando mrtg podremos revisar estos archivos, para detectar más fácilmente los errores.

En este proyecto el número de páginas html que se generan es bastante amplio, una por cada dispositivo/parámetro. Mediante el comando indexmaker podemos agrupar todas estas páginas, en una sola. En este caso se han recogido en función del tipo de parámetro, es decir, se mostrará una página web con todos los tráficos de red, otra con los espacios libres de los discos de los servidores, etc. El comando se utiliza como se indica en la figura 45.

sojos:/etc# indexmaker mrtgcpu.cfg > /var/www/mrtg/cpu.html

(fig. 45, utilización del comando indexmaker)

De esta manera, conseguimos agrupar todas las gráficas que se generan a partir de mrtgcpu.cfg en el archivo cpu.html. El resto de páginas creadas, se listan a continuación:

• discos.html• freemem.html• numprocses.html• onoff.html• redservsers.html• routercisco.html

A su vez, se ha creado otra página web “índice” (en /var/www/mrtg/index.html) para poder acceder a esas 7 páginas web (figura 46).

54

(fig. 46, Menú principal de acceso a las gráficas)

Desde este menú podremos acceder de forma cómoda a las gráficas generadas.Pinchando en uno de los enlaces obtendríamos las gráficas, similares a las que se muestran en la figura 47.

Pulsando con el ratón sobre cada una de estas gráficas, obtendríamos más detalles, como el histórico semanal, mensual y anual, además de los valores de los datos actuales, medios y máximos de cada gráfica (figura 48).

Con todo esto, ya tendríamos funcionando nuestras gráficas monitorizando los dispositivos y parámetros que se han indicado. En este momento, sólo tenemos acceso a las gráficas desde la propia entidad gestora. Se quiere que se puedan acceder también desde otras máquinas, por ejemplo, desde todos los ordenadores del departamento de informática. Esto se detalla en el siguiente punto.

55

(fig. 47, vista global de las gráficas)

Numero de procesos y sesiones en NTSQL2

Gráfico diario (5 minutos : Promedio)

Máx Procesos 48 Promedio Procesos 45 Actual Procesos 45 Máx Sesiones 25 Promedio Sesiones 9 Actual Sesiones 23 Gráfico semanal (30 minutos : Promedio)

Máx Procesos 47 Promedio Procesos 47 Actual Procesos 45

56

Máx Sesiones 26 Promedio Sesiones 7 Actual Sesiones 22 Gráfico mensual (2 horas : Promedio)

Máx Procesos 48 Promedio Procesos 47 Actual Procesos 45 Máx Sesiones 24 Promedio Sesiones 5 Actual Sesiones 11 Gráfico anual (1 día : Promedio)

Máx Procesos 48 Promedio Procesos 45 Actual Procesos 46 Máx Sesiones 9 Promedio Sesiones 4 Actual Sesiones 8

VERDE ### Numero de procesos

AZUL ### Numero de sesiones abiertas

(fig. 48, vista detallada de las gráficas)

5.3 Instalación y configuración del servidor HTTP, Apache

Para ello, utilizamos el comando apt-get, ya que esta librería se encuentra disponible en la distribución de Debian.

apt-get install apache2

(fig. 5.49, instalación del módulo apache2)

Una vez instalado el servidor web, se procede a realizar su configuración. Como se ha dicho, para esta versión de Apache, el archivo httpd.conf se ha simplificado bastante. Muchas de las opciones que incluía este archivo, en la nueva versión han pasado a /etc/apache2/sites-available/default. En este archivo introduciremos varias reglas de seguridad:

• acceso a las gráficas restringidas por IP (indicaremos qué máquinas tienen acceso a las gráficas, mediante su dirección IP)

• acceso restringido por usuario y password (también se deberán de indicar para el acceso un nombre de usuario y un password)

Para restringir el acceso por IP, introducimos las siguientes líneas en el archivo de configuración, como se muestra en la siguiente figura.

57

<Directory /var/www/>Options Indexes FollowSymLinks MultiViewsAllowOverride NoneOrder allow,denyallow from 192.16.41.23allow from 192.16.41.14allow from 127.0.0.1 # This directive allows us to have apache2's default start# page# in /apache2-default/, but still have / go to the right # placeRedirectMatch ^/$ /mrtg/

</Directory>

(fig. 50, configuración de apache2, permisos de acceso por IP)

Con la directiva allow from seguida de una dirección IP, damos permiso de acceso a la máquina con esa IP.

A continuación, crearemos un usuario y una contraseña para poder acceder a las gráficas, utilizando el comando htpasswd2 (figura 51).

sojos:/etc/init.d# htpasswd2 –c /etc/apache2/usuarios adminetNew passwordRe-type new passwordAdding password for user adminet

(fig. 51, utilización del comando htpasswd2)

Hay que indicar en el comando, el archivo en el que se guardará el usuario, y su nombre de acceso. Luego se solicitará el password para ese usuario. También añadiremos las siguientes líneas en el archivo de configuración default (figura52).

<Directory /var/www/>Options Indexes FollowSymLinks MultiViewsAllowOverride NoneOrder allow,denyallow from 192.16.41.107allow from 192.16.41.9allow from 127.0.0.1AuthType Basic

AuthName adminet AuthUserFile /etc/apache2/usuarios Require valid-user

# This directive allows us to have apache2's default start # page# in /apache2-default/, but still have / go to the right # placeRedirectMatch ^/$ /mrtg/

</Directory>

(fig. 52, configuración de apache2, autorizaciones)

Se añade, el tipo de autorización, el usuario y el archivo donde se encuentra ese nombre de usuario (podemos tener también más de un usuario con acceso).

58

De esta forma, cada vez que se quiera acceder a las gráficas desde alguna de las máquinas que hemos señalado en el archivo de configuración, se solicitará también un nombre de usuario y un password (figura 53).

(fig. 53, menú de acceso a las gráficas)

En este archivo de configuración aparece también otra directiva, DocumentRoot, en la que se debe indicar la raiz de las páginas web a mostrar. Para este proyecto, recordar que se hizo un índice y que se encuentra en /var/www/mrtg.

DocumentRoot /var/www/mrtg

Con esto, finalizamos la configuración del servidor Apache2. Contiene muchas más opciones, pero para este proyecto nos sirve con las restricciones añadidas.

5.4 Instalación y configuración de Gnokii

Llegamos al último paso de este proyecto. Nuestro sistema hasta ahora es capaz de monitorizar los dispositivos y parámetros que ya se han indicado, y de enviar alertas a través del correo electrónico cuando se suceden determinados eventos excepcionales.

Se solicitó que el sistema de gestión fuera capaz de enviar estas alertas por medio de un SMS a un teléfono móvil. Veremos como realizar este paso, de una manera muy sencilla. Para ello, necesitaremos un teléfono móvil conectado a nuestra entidad gestora, y un software que sea capaz de comunicarlos: Gnokii.

59

Antes de comenzar con la instalación necesitaremos: un móvil de los soportados y testeados por el proyecto Gnokii (se puede comprobar en la lista que ofrece en su página web, ver Bibliografía). En nuestro caso el móvil utilizado es un Nokia 3310. El tipo de conexión de este móvil con el ordenador, se realiza mediante un cable serie como el de la siguiente figura.

(fig. 54, conexión del cable de datos al teléfono móvil)

Conectamos el cable al teléfono móvil, y por el otro extremo al puerto serie de la entidad gestora.

Como ya se ha dicho, Debian contiene la librería gnokii (0.6.5), por lo tanto utilizaremos de nuevo el comando apt-get para su instalación.

sojos:/#apt-get install gnokii

(fig. 55, instalación del modulo gnokii)

A continuación accedemos al archivo de configuración /etc/gnokiirc y modificamos los parámetros que aparecen en la figura 56.

# Modelo del móvilmodel = 3310# Tipo de conexión entre ordenador y el móvilconenection = m2bus

(fig. 56, configuración de gnokii, modelo de móvil y conexión)

60

Y en el fichero /usr/bin/gnokii, también modificamos el siguiente parámetro:

# ya que el cable serie de conexión no es muy rápido, ponemos un # tiempo de espera amplio para la ejecución de los comandos del # progrma gnokiiTIMEOUT = 150

(fig. 57, configuración de gnokii, tiempo de espera)

Para comprobar que la instalación ha sido correcta ejecutamos el siguiente comando:

debian:/etc# gnokii –monitorGNOKII Version 0.6.5Entering monitor mode…RFLevel 100Battery: 82SIM: Used 5, Free 115Network: vodafone (Spain)

(fig. 58, comprobación de la instalación de gnokii mediante el commando gnokii –monitor)

Vemos que hay conexión entre el teléfono móvil y el ordenador. Con el siguiente comando podremos enviar nuestro primer mensaje:

sojos:/etc# /$echo \”hola mundo\” | gnokii –sendsms $num_telf

(fig. 59, enviar sms a través de gnokii)

Comprobamos que a través del comando gnokii –sendsms seguido del número de teléfono de envío, se realiza el envío de SMS.

Tan sólo queda conseguir que se envíen los mensajes de alarma que se generan a partir del MRTG. Se realiza de una manera muy sencilla. Incluímos el comando gnokii –sendsms en los scripts encargados de enviar las armas por correo (galarma, galarmaok), de tal manera que el mismo mensaje que se envía por correo electrónico se envía también por SMS a través del móvil.

A continuación se muestra el script galarma, tras haber realizado las modificaciones:

# Script que recoge los datos del MRTG, y crea la alarma que se envia por correo en un archivo# (que tiene por nombre lo que contenga $1)# Parámetros de entrada:# $1: contiene el nombre del dispositivo gestionado y el parámetro que ha hecho generar la alarma# $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente# $3: contiene el valor actual del parametro del dispositivo gestionado, por el cual ha generado la alarma#

# redireccionamos lo que genera la alarma del mrtg a un archivo (de nombre, lo que contenga $1)echo "problema en:" $1 "umbral sobrepasado:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1

61

# enviamos el archivo a una direccion de correo electrónicomail -s "Alarma desde MRTG" dptoinformatico@cebanc.com < /home/raul/mrtg/alarmas/$1

# se envia el contenido del fichero $1 via SMS al número # indicadocat /home/rmartin/alarmas/$1 | gnokii --sendsms 123456789

(fig. 60, script galarma)

Con el comando cat, se muestra lo que haya en el archivo indicado en el path; mediante una tubería conseguimos que ese contenido se redireccione al comando gnokii –sendsms encargado de enviar el SMS.

El funcionamiento es similar para el script galarmaok:

# Script que recoge los datos del MRTG, y crea la alarma de "problema solucionado" que se envia por correo en un archivo# (que tiene por nombre lo que contenga $1)# Parámetros de entrada:# $1: contiene el nombre del dispositivo gestionado y el parámetro para el que se ha solucionado la alarma# $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente# $3: contiene el valor actual del parametro del dispositivo gestionado#

# redireccionamos lo que genera la alarma del mrtg a un archivoecho "problema solucionado en:" $1 "umbral:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1

# enviamos el archivo a una direccion de correo electrónicomail -s "Alarma CORREGIDA dsde MRTG" dptoinformatitco@cebanc.com < /home/raul/mrtg/alarmas/$1

(fig. 61, script galarmaok)

62

De esta manera, se consigue tener la información de la gestión de la red en un teléfono móvil, lo cual ayuda al administrador de la red, a estar informado independientemente del lugar donde se encuentre.

(fig. 62, recepción de una alerta)

5.5 Conclusiones

Partiendo de las decisiones comentadas en el capítulo anterior, se han configurado e implantado todas las herramientas descritas.

SNMP y MRTG sumados al ingenio del administrador de red para implementar scripts, forman una herramienta muy interesante capaz de monitorizar la red en tiempo real, comprobando el uso de sus recursos informáticos y detectando sus anomalías.

Para dotar de una mayor facilidad de acceso a la información monitorizada, se utiliza un servidor web, que permite visionar la información a través de una página web, y una herramienta de comunicación entre redes IP y GSM, que permite conocer el estado de las anomalías surgidas desde un teléfono móvil..

Por último, hay que resaltar que la solución a los problemas surgidos para implantar dichas herramientas, no debe partir de realizar cambios en la red. Como ya se explicó en el capítulo 3, el impacto que han de sufrir las redes con la introducción de los sistemas de gestión, ha de ser mínimo. El sistema se debe adecuar a la red, y no la red al sistema.

63

CAPÍTULO 6. CONCLUSIONES

El sistema de gestión o control de red presentado en este proyecto, se ha basado en el uso del protocolo de gestión SNMP y la herramienta de software libre MRTG. Los elementos software desarrollados, como la configuración del protocolo o la obtención de datos por parte del MRTG, se han implementado mediante lenguaje script, lo cual implica una mayor robustez y fiabilidad en el sistema. Todo el software utilizado, incluso el sistema operativo, es de libre distribución, lo cual demuestra que este tipo de herramientas son tan válidas y funcionales como las que desarrollan y distribuyen las empresas privadas.

El uso de SNMP, como protocolo de gestión de red, se debe a su facilidad para poder monitorizar diferentes dispositivos de múltiples fabricantes, gracias a que es el estándar más extendido dentro de los protocolos de gestión de red.

A pesar de no poder contar con toda la seguridad que proporciona la última versión de SNMP, realizando una configuración óptima del protocolo (impidiendo la posibilidad de modificar datos en los dispositivos de red y utilizando los nombres de comunidad) y con el uso de otras herramientas de acceso a los datos (Apache), se puede asegurar un gran nivel de seguridad. Fijar este nivel dependerá de la propia constitución y funcionalidad de la red. Para el caso utilizado en este PFC, se considera el óptimo.

Algo similar ocurre con la utilización de MRTG como herramienta de monitorización de datos; aunque puedan existir herramientas más complejas y con más funcionalidades en el mercado, se considera que ésta es la adecuada para la red en la que se ha implantado ya que cumple totalmente con los requisitos solicitados. Se integra perfectamente con el protocolo SNMP, permitiendo una representación bastante clara de la información mediante gráficas. Además cuenta con un mecanismo sencillo para generar las alarmas que avisan de determinadas situaciones o anomalías que ocurran en los dispositivos. La posibilidad de que estas alarmas se puedan recibir en un teléfono móvil mediante el uso de mensajes SMS, ofreciendo al administrador de la red una mayor comodidad en su gestión, presenta una característica que no suelen ofrecer este tipo de sistemas.

En definitiva, además de cumplir todos los objetivos solicitados al inicio del desarrollo de este proyecto, se ha intentado también implantar, un sistema sencillo de ampliar, tanto a la hora de monitorizar nuevos datos como nuevos dispositivos, y de fácil utilización mediante su acceso a las gráficas vía web.

64

CAPÍTULO 7. BIBLIOGRAFÍA

Aldarias Raya, Paco. 2005. Estadísticas de red, router, cpu: MRTG.http://pacodebian.iespana.es/mrtg.html

Barrios J. 2005. Linux para todos: Como configurar SNMP.http://www.linuxparatodos.net/geeklog/article.php?story=borrador-como-snmpd-mar-10-2005

Fernández-Sanguino Peña, Javier. 2001. Linux Actual nº 17: Gestión SNMP con Linux.http://es.tldp.org/Articulos-periodisticos/jfs/snmp/snmp.html

Garzón Alcalde, Joaquín. 2005. Monitorización gráfica del tráfico de red y otros parámetros del sistema.http://www.diariolinux.com/tiki-read_article.php?articleId=6

JulHer. 2003. Libertonia: Monitorizando sistemas con MRTG y SNMP.http://libertonia.escomposlinux.org/story/2003/1/17/224253/241

Kot, Pawel; Borbely, Zoltan. gnokii.org. http://www.gnokii.org/

Kurose, J. F.; Ross, K. W. 2003. Redes de Computadores (Un enfoque descendente basado en Internet). COMPUTER NETWORKING. A Top-Down Approach Featuring the Internet, Second Edition by Kurose, J. F. and Ross, K. W. (cap. 8, pp 659-678)

Mora Porta, Gaspar; García, Ignacio; Benejam Torres, Santiago; 2004. Monitorización del tráfico con MRTG: Apuntes sobre Debian GNU/Linux.http://www.neozero.net/linux/manuales/mrtg/

Oetiker, Tobias; Rand, Dave. MRTG: The Multi Router Traffic Grapher.http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

Sanz, José Manuel. 2005. Envío de mails al móvil mediante gnokii.http://bulma.net/body.phtml?nIdNoticia=2178

Net-SNMP.http://net-snmp.sourceforge.net/

65

Seco Hernández, Andrés. Alamin GSM SMS Gateway.http://www.alamin.org/

Sobre las Peticiones de Comentarios (RFCs), existen copias de estos archivos en múltiples sitios de Internet. En la siguiente URL, http://www.rfc-es.org/ , se pueden obtener algunos de estos documentos traducidos al castellano. El encargado de publicar y supervisar estos documentos es el Editor de RFCs, http://www.rfc-editor.org/. Una URL completa que se puede utilizar como buscador de RFCs es: http://www.faqs.org/rfcs/ .

También se han utilizado los siguientes grupos de noticias para consultar dudas y obtener consejos sobre los diferentes temas que han aparecido en este proyecto:

• es.comp.os.linux.redes• es.comp.redes.misc• comp.protocols.snmp

66