índice capítulo 1. introducción 7 capítulo 2. gestión del proyecto 9

ÍNDICE
CAPÍTULO 1. INTRODUCCIÓN
7
CAPÍTULO 2. GESTIÓN DEL PROYECTO
9
2.1 Descripción del proyecto
2.2 Objetivos del proyecto
2.3 Alcance del proyecto
2.4 Planificación temporal
2.5 Riesgos y planes de contingencia
2.6 Método de trabajo
2.7 Gestión real del proyecto
CAPÍTULO 3. DESCRIPCION DEL PROTOCOLO SNMP
3.1 Introducción
3.2 Evolución histórica del protocolo SNMP
3.3 Arquitectura de un sistema de gestión de red
3.3.1 Entidad gestora
3.3.2 Dispositivos a gestionar
3.3.3 Protocolo de gestión
9
9
10
11
13
14
14
19
19
19
21
21
21
22
3.4 Modelo de información
23
3.4.1 Estructura de la información de administración
3.4.2 MIB
3.4.3 Operaciones de SNMP
3.4.4 La seguridad en SNMP
3.5 Conclusiones
23
24
28
31
31
CAPÍTULO 4. DESARROLLO TEÓRICO
4.1 Introducción (finalidad del proyecto)
4.2 Captura de requerimientos hardware
4.3 Captura de requerimientos software
4.3.1 El Sistema Operativo
4.3.2 Los agentes
4.3.3 Análisis de herramientas de monitorización de datos
4.3.4 Servidor http
4.3.5 Análisis de herramientas para la comunicación de redes IP y GSM
4.4 Conclusiones
33
33
33
35
35
36
37
37
38
38
CAPÍTULO 5. DESARROLLO PRÁCTICO
5.1 Instalación, configuración y pruebas de los agentes
5.1.1 Linux – Debian (Net-SNMP)
5.1.2 Otros agentes SNMP para Linux
5.1.3 Windows 2000, Windows 2003 Server
5.2 Instalación y configuración de MRTG
5.3 Instalación y configuración del servidor HTTP, Apache
5.4 Instalación y configuración de Gnokii
5.5 Conclusiones
CAPÍTULO 6. CONCLUSIONES
39
39
39
44
45
49
63
65
69
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 system
Figura 8. Formato de las PDUs en SNMPv2
Figura 9. Operaciones SNMP
Figura 10. Instalación del paquete snmp a través del comando apt-get
Figura 11. Definición de los nombres de comunidad y grupos asignados
Figura 12. Relación entre modelos de seguridad y grupos
Figura 13. Definición de vistas y tipo de acceso
Figura 14. Proceso snmp escuchando en el puerto 161 a través del protocolo UDP
Figura 15. Salida del comando snmpget
Figura 16. Salida del comando snmpget con múltiples variables
Figura 17. Salida del comando snmpgetnext
Figura 18. Salida del comando snmpwalk
Figura 19. Utilización del comando snmpset
Figura 20. Salida del comando snmpstatus
Figura 21. Salida del comando snmptranslate
Figura 22. Salida del comando snmpnetstat
Figura 23. Panel de instalación del agente SNMP en Windows
Figura 24. Estado del servicio SNMP
Figura 25. Panel de propiedades del servicio SNMP
Figura 26. Detalles de las opciones del menú Servicio
Figura 27. Panel de configuración de Seguridad del servicio SNMP
Figura 28. Instalación de los módulos necesarios para MRTG
Figura 29. Opciones globales para el archivo mrtgcpu.cfg
Figura 30. Implementación parcial del archivo de configuración mrtg.cfg
Figura 31. Implementación parcial del archivo mrtgdiscos.cfg
Figura 32. Implementación del script snmp_hdfree
Figura 33. Implementación parcial del archivo mrtgfreemem.cfg
Figura 34. Implementación del script snmp_windowsmemfree
Figura 35. Implementación parcial del archivo mrtgnumprocses.cfg
Figura 36. Implementación parcial del archivo mrtgonoff.cfg
Figura 37. Implementación del script para comprobar el estado, on/off, de un
dispositivo
Figura 38. Utilización del comando cfgmaker
Figura 39. Implementación parcial del archivo mrtgredservers.cfg creado
mediante el comando cfgmaker
Figura 40. Implementación parcial del archivo mrtgroutercisco.cfg creado
mediante el comando cfgmaker
Figura 41. Implementación del script galarma
Figura 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ódica
Figura 45. Utilización del comando indexmaker
Figura 46. Menú principal de acceso a las gráficas
Figura 47. Vista global de las gráficas
Figura 48. Vista detallada de las gráficas
Figura 49. Instalación del módulo apache2
Figura 50. Configuración de apache2, permisos de acceso por IP
Figura 51. Utilización del comando htpasswd2
Figura 52. Configuración de apache2, autorizaciones
Figura 53. Menú de acceso a las gráficas
Figura 54. Conexión del cable de datos al teléfono móvil
Figura 55. Instalación del modulo gnokii
Figura 56. Configuración de gnokii, modelo de móvil y conexión
Figura 57. Configuración de gnokii, tiempo de espera
Figura 58. Comprobación de la instalación de gnokii mediante el comando
gnokii –monitor
Figura 59. Enviar sms a través de gnokii
Figura 60. Script galarma
Figura 61. Script galarmaok
Figura 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
PFC
Búsqueda
Captura de
Análisis de
documentació
requisitos
requisitos
n
Consultas con
Entregables
Consulta en
el cliente
de cada fase
libros
Gestión
Memoria
final
Consulta en
Internet
Estudio de la
red
Desarrollo
Implantación
Pruebas
Consulta en
manuales
Consulta en
otras fuentes
(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:
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.
2.
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.
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.
4.
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.
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:
•
•
[1]
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.
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ón
SNMP
Transporte
IP
Acceso a red
Fí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.
Entidad
Gestora
MIB
SNMP
Agente
MIB
P
M
SN
P
M
SN MP
SN
Dispositivo a gestionar
Dispositivo a gestionar
Agente
MIB
Dispositivo a gestionar
Agente
Agente
MIB
MIB
Dispositivo a gestionar
(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, OBJECTTYPE y se reúnen en módulos (módulos MIB) utilizando el constructor MODULEIDENTITY. 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
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-2 (1)
system (1)
interface (2)
address
translation (3)
ip (4)
icmp (5)
MIB-1 (2)
tcp (6)
udp (7)
egp (8)
snmp (11)
(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
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
Obtener/establecer cabecera
Variables a obtener/establecer
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
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 red
o espacio libre en los HD (Hard Disk, disco duro)
o tasa de CPU utilizada
o memoria RAM disponible
o numero de sesiones abiertas
o numero de procesos en ejecución
o 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 NETSNMP, 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:~$ su
Password:
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 community
com2sec readonly default public
com2sec 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 readwrite
group MyRWGroup v2c readwrite
group MyRWGroup usm readwrite
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group 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 80
view 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 notif
access MyROGroup "" any noauth exact all none none
access MyRWGroup "" any noauth exact all all none
# Datos informativos de contacto
syslocation Servidor Linux en dptoInformatica
syscontact 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.d
sojos:/etc/init.d# snmpd start
sojos:/etc/init.d# netstat -anp -u
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address
Foreign Address
PID/Program name
udp
0
0 0.0.0.0:9
0.0.0.0:*
1
udp
0
0 0.0.0.0:161
0.0.0.0:*
1
State
167/inetd
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.0
SNMPv2-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.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (197604978) 22 days, 20:54:09.78
SNMPv2-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.0
SNMPv2-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 system
SNMPv2-MIB::sysDescr.0 = STRING: Linux sojos 2.4.27-1-386 #1 Fri Sep 3
06:24:46 UTC 2004 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (197612307) 22 days, 20:55:23.07
SNMPv2-MIB::sysContact.0 = STRING: Raul Martin (rmartinr@euskalnet.net)
SNMPv2-MIB::sysName.0 = STRING: sojos
SNMPv2-MIB::sysLocation.0 = STRING: Servidor Linux en dptoInformatica
35
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (12) 0:00:00.12
SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.6
=
OID:
SNMP-VIEW-BASED-ACMMIB::vacmBasicGroup
SNMPv2-MIB::sysORID.7
=
OID:
SNMP-FRAMEWORKMIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.9
=
OID:
SNMP-USER-BASED-SMMIB::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.0
SNMPv2-MIB::sysContact.0 = STRING: Raul Martin (dptoinformatico@cebanc.com)
sojos:/# snmpset -v2c -c public localhost systContact.0 s "Administrador"
SNMPv2-MIB::sysContact.0 = STRING: Administrador
sojos:/# snmpget -v2c -c public localhost systContact.0
SNMPv2-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.03
Interfaces:
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.0
SNMPv2-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 localhost
Active Internet (tcp) Connections
Proto Local Address
Foreign Address
tcp sojos.cebancdea.edu.ssh
192.16.51.18.1361
Active Internet (udp) Connections
Proto Local Address
udp *.discard
udp *.sunrpc
udp *.snmp
udp *.947
udp *.950
udp *.10000
udp *.46745
(state)
ESTABLISHED
(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 Debian
WorkDir: /var/www/mrtg
### Global Defaults
MaxBytes[_]: 100
Unscaled[_]: ymwd
ShortLegend[_]: %
YLengend[_]: Uso de CPU
Legend1[_]: Usuario CPU % (Load)
Legend2[_]: Sistema CPU % (Load)
LegendI[_]: Usuario
LegendO[_]: Sistema
ThreshMaxO[_]: 99
ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarma
ThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok
Options[_]: growrigth,nopercent,unknaszero,gauge,noinfo
WriteExpires: Yes
Language: spanish
EnableIPv6: no
Interval: 5
Refresh: 300
ThreshDir: /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.103
Title[ntsql2-cpu]: NTSQL2 - CPU LOAD
PageTop[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.2
Title[ntmail2-cpu]: NTMail2 - CPU LOAD
PageTop[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
capacidad de los discos duros
de
configuración
para
representar
la
ThreshMinO[_]: 10%
ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarma
ThreshProgOKO[_]: /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
# Parametros de entrada:
#
#
espacio libre del HD
$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 total
HDTotal=`snmpget -v2c -c $2 $1 hrStorageSize.$3 | gawk '{print $4}'`
#Obtener el espacio usado
HDUsado=`snmpget -v2c -c $2 $1 hrStorageUsed.$3 | gawk '{print $4}'`
#Obtener las unidades en las que se miden los datos anteriores
Unidad=`snmpget -v2c -c $2 $1 hrStorageAllocationUnits.$3 | gawk '{print $4}'`
#Obtener el espacio total, ya multiplicado por las unidades
espacioTotal=$(((HDTotal)*Unidad))
#Obtener el espacio libre
espacioLibre=$(((HDTotal-HDUsado)*Unidad))
echo $espacioLibre
echo $espacioTotal
#Obtener el tiempo de funcionamiento
Tiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`
echo $Tiempo
#Obtener el nombre de la máquina
Nombre=`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/galarma
ThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok
##########################
# Memoria libre en NTMail2
##########################
Target[ntmail2-freemem]:
`/home/rmartin/mrtg/snmpscripts/snmp_winmemfree
nombrecomunidad 6`
Title[ntmail2-freemem]: NTMail2 - Memoria libre
192.16.41.2
##########################
# 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 $total
echo $libre
#Obtener el tiempo de funcionamiento
Tiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`
echo $Tiempo
#Obtener el nombre de la máquina
Nombre=`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.2
MaxBytes[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
estado de los servidores: 1 encendido, 0 apagado
para
representar
el
#############################
# 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 encendido
if test $resultado
then
#si llego aqui es porque el dispositivo esta encendido
estado=1
fi
# Obtener dos veces el mismo parametro para que el MRTG pinte el mismo parametro de
entrada y salida
echo $estado
echo $estado
#Obtener el tiempo de funcionamiento
Tiempo=`snmpget -v2c -c $2 $1 sysUpTime.0 | gawk '{print $5, $6, $7}'`
echo $Tiempo
#Obtener el nombre de la máquina
Nombre=`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]: 60000
Title[192.16.41.2_65539]: Análisis de Tráfico -- NTMAIL2
PageTop[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' |
'192.16.41.109' | Eth: '00-02-b9-1d-7e-50' ###
Name:
'Et0'
|
Ip:
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]: 1250000
Title[192.16.41.109_1]: Traffic Analysis for 1 -- C1600_CDEA
PageTop[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]: 193000
Title[192.16.41.109_2]: Traffic Analysis for 2 -- C1600_CDEA
PageTop[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ónico
mail -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 archivo
echo "problema solucionado en:" $1 "umbral:" $2 "dato actual:" $3 >
/home/raul/mrtg/alarmas/$1
# enviamos el archivo a una direccion de correo electrónico
mail
-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.cfg
sojos:/etc# mrtg mrtgroutercisco.cfg
sojos:/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, ntsql2disco.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 mrtg
0-55/5 * * * * mrtg /etc/mrtg.cfg >> /var/log/mrtg/mrtg.log
0-55/5 * * * * mrtg /etc/mrtgdiscos.cfg >> /var/log/mrtg/mrtgdiscos.log
53
0-55/5
0-55/5
0-55/5
0-55/5
0-55/5
0-55/5
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
mrtg
mrtg
mrtg
mrtg
mrtg
mrtg
/etc/mrtgnumprocses.cfg >> /var/log/mrtg/mrtgnumprocses.log
/etc/mrtgredservers.cfg >> /var/log/mrtg/mrtgredservers.log
/etc/mrtgroutercisco.cfg >> /var/log/mrtg/mrtgroutercisco.log
/etc/mrtgfreemem.cfg >> /var/log/mrtg/mrtgfreemem.log
/etc/mrtgcpu.cfg >> /var/log/mrtg/mrtgcpu.log
/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
Máx Procesos 48
Máx Sesiones 25
Gráfico
Promedio Procesos 45 Actual Procesos 45
Promedio Sesiones 9
Actual Sesiones 23
semanal
(30
minutos
Máx Procesos 47
Promedio Procesos 47
Actual Procesos 45
56
:
Promedio)
:
Promedio)
Máx Sesiones 26
Gráfico
Promedio Sesiones 7
mensual
Actual Sesiones 22
(2
horas
Máx Procesos 48
Máx Sesiones 24
Gráfico
Promedio Procesos 47 Actual Procesos 45
Promedio Sesiones 5
Actual Sesiones 11
anual
(1
día
Máx Procesos 48
Máx Sesiones 9
Promedio Procesos 45
Promedio Sesiones 4
:
:
Promedio)
Promedio)
Actual Procesos 46
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 MultiViews
AllowOverride None
Order allow,deny
allow from 192.16.41.23
allow from 192.16.41.14
allow 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
# place
RedirectMatch ^/$ /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 adminet
New password
Re-type new password
Adding 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 MultiViews
AllowOverride None
Order allow,deny
allow from 192.16.41.107
allow from 192.16.41.9
allow from 127.0.0.1
AuthType 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
# place
RedirectMatch ^/$ /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óvil
model = 3310
# Tipo de conexión entre ordenador y el móvil
conenection = 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 gnokii
TIMEOUT = 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 –monitor
GNOKII Version 0.6.5
Entering monitor mode…
RFLevel 100
Battery: 82
SIM: Used 5, Free 115
Network: 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ónico
mail -s "Alarma desde MRTG" dptoinformatico@cebanc.com
< /home/raul/mrtg/alarmas/$1
# se envia el contenido del fichero $1 via SMS al
# indicado
cat /home/rmartin/alarmas/$1 | gnokii --sendsms 123456789
número
(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 archivo
echo "problema solucionado en:" $1 "umbral:" $2 "dato actual:"
$3 > /home/raul/mrtg/alarmas/$1
# enviamos el archivo a una direccion de correo electrónico
mail -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