Herramientas Open Source para monitoreo de red e implementación de herramientas en la red PUCE SD by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Disertación de Grado previa la obtención del título de Ingeniero en Sistemas y Computación.

ESTUDIO DE HERRAMIENTAS OPEN SOURCE, PARA MONITOREO DE RED E IMPLEMENTACIÓN DE LA HERRAMIENTA MÁS ÓPTIMA EN LA RED DE LA PUCE SD

AUTORES:

JORGE LUIS ESPINOZA LUGO JAVIER EMILIANO SOLÓRZANO NEIRA

DIRECTOR: MS. RODOLFO CÓRDOVA

SANTO DOMINGO- ECUADOR, 2011

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO APROBACIÓN DE LA DISERTACIÓN DE GRADO ESTUDIO DE HERRAMIENTAS OPEN SOURCE, PARA MONITOREO DE RED E IMPLEMENTACIÓN DE LA HERRAMIENTA MÁS ÓPTIMA EN LA RED DE LA PUCE SD AUTORES:

JORGE LUIS ESPINOZA LUGO JAVIER EMILIANO SOLÓRZANO NEIRA TRIBUNAL

MS. RODOLFO CÓRDOVA

MS. MILTON ANDRADE

ING. MARGARETH HURTADO

Santo Domingo, noviembre del 2011

III

DEDICATORIA A Dios… A mi madre, Patricia Neira, de quien aprendí mis mejores valores y principios, todo lo bueno en mi proviene de ella, mi impulsadora personal… A mi padre, Emiliano Solórzano, cuyo ejemplo de superación profesional en contra de las adversidades de su vida, reprendas, me enseñaron lo afortunado que soy de poder estudiar, buscar y alcanzar lo que quiero… A mis hermanas, Ivón y Génesis, quienes me acompañan y apoyan desde siempre, siendo las personas más importantes de mi vida… A toda mi extensa familia: tíos, tías, primos, primas, ya que soy un poco de cada uno de ellos… A la memoria de mi abuelita, Virginia Neira, cuyo admirable matriarcado es modelo de lucha constante y progreso…

JAVIER EMILIANO SOLÓRZANO NEIRA

DEDICATORIA A Dios, absolutamente por todo… A mi padre Jorge W. Espinoza, cuyo sacrificio y constancia en su vida han sido el mejor ejemplo a seguir… A mi madre Patricia Lugo, quien ha sabido guiarme e impulsarme a través de todos estos años en las distintas etapas de mi vida… A mis hermanas María Fernanda y Glenda, compañeras de mi niñez; gracias por soportarme… A mi esposa Andrea Carrión, por todo su amor e impulso… A todos los que de manera directa e indirecta me han apoyado…

JORGE LUIS ESPINOZA LUGO

AGRADECIMIENTOS A nuestras familias, por su constante apoyo, que han sido pilar fundamental en este largo camino de progreso. A la Pontificia Universidad Católica del Ecuador, Sede Santo Domingo por proporcionarnos el camino al triunfo académico. Al Magister Rodolfo Córdova por su guía. A las personas que integran el Subárea de Redes de la PUCE SD, por su colaboración en la implementación del proyecto.

RESUMEN El presente proyecto se lo realizó con el objetivo de apoyar la estabilidad y confiabilidad de la transmisión de datos, los recursos de los servidores y servicios de red informática pertenecientes a la PUCE SD, ya que la Subárea de Redes del CITIC, responsable del funcionamiento y mantenimiento de la infraestructura de red no contaba con una herramienta que detecte problemas y envíe alertas a los administradores de manera automática. Se realizó el levantamiento de información en las instalaciones de la red informática de la PUCE SD obteniendo los parámetros a cumplir por la herramienta de monitoreo, con esta información se procedió a investigar y estudiar varias herramientas open source de monitoreo de red, y después de una evaluación con criterios de auditoría propia, se seleccionó la herramienta más óptima para que funcione dentro de los parámetros de red que utiliza la universidad, la cual fue Nagios versión 3.2.3, misma que fue instalada sobre la plataforma GNU/Linux CentOS 5.5 en el servidor adquirido y ensamblado por los investigadores. Se configuró en Nagios el monitoreo de: conectividad de los dispositivos de red, recursos de los servidores, servicios de red internos y externos de la PUCE SD, y las notificaciones mediante emails y mensajes SMS a los dispositivos móviles de los administradores de red, las cuales se generan al momento que Nagios detecta un mal funcionamiento de los dispositivos o servicios. Adicionalmente se crearon los manuales de instalación, configuración y usuario, para el óptimo manejo de la herramienta; finalmente se realizaron las pruebas de funcionamiento, confirmando así la detección de problemas y envío de alertas por parte de Nagios. El desarrollo del proyecto demostró que el monitoreo de redes a través de la herramienta de monitoreo Nagios asegura la disponibilidad de los servicios de red, siendo un elemento vital e importante para su administración, ya que permite supervisar y alertar de eventualidades de los dispositivos y servicios. Nagios implementado y funcionando en la red informática de la PUCE SD, mediante el despliegue de información almacenada durante la actividad de monitoreo, representada también mediante gráficos en su interfaz web otorgó un nuevo enfoque a la resolución de problemas e incidencia dentro de la red.

VII

ABSTRACT This project was performed in order to support the stability and reliability of data transmission, the resources of servers and computer network services belonging to PUCE SD, being that the sub area network of CITIC, responsible for operating and maintaining of the network infrastructure did not have a tool to detect problems and send alerts to administrators in a way fully automatic. Was performed the gathering of information on the facilities of the computer network in PUCE SD obtaining parameters to fulfill by the monitoring tool, with this information we proceeded to investigate and study several open source tools for network monitoring, and after an audit evaluation criteria of its own, was selected the best tool to work within the network parameters used by the university, which was Nagios version 3.2.3, it was installed on the platform GNU / Linux CentOS 5.5 on a server purchased and assembled by the researchers. We configured Nagios for monitoring: connectivity of network devices, server resources, network services internal and external of the PUCE SD, and the notifications through emails and SMS messages to mobile devices from the network administrators, which are generated when Nagios detects a malfunction of the devices or services. Additionally, were created the installation, configuration and user manuals, for optimal management of the tool; finally they were tested for performance of the tool, confirming the detection of problems and sending alerts from Nagios. The development of the project proved that monitoring the network throughout the Nagios monitoring tool ensures the availability of network services, being a vital element and important for its administration, since it lets you monitor and alert of any contingencies of devices and services. Nagios deployed and working on the network computer of the PUCE SD, through the deployment of stored information for monitoring activity, also represented by graphs in its web interface provided a new approach to solving problems and advocacy within the network.

VIII

ÍNDICE DE CONTENIDOS APROBACIÓN DE LA DISERTACIÓN DE GRADO......................................................................... II DEDICATORIA.................................................................................................................................. III AGRADECIMIENTOS ........................................................................................................................ V RESUMEN......................................................................................................................................... VI ABSTRACT ...................................................................................................................................... VII LISTA DE CUADROS E ILUSTRACIONES. .................................................................................... XI ANTECEDENTES Y JUSTIFICACIÓN ............................................................................................ 13

1.1. INTRODUCCIÓN. .................................................................................................13 1.2. PROBLEMÁTICA. ................................................................................................14 1.3. JUSTIFICACIÓN. .................................................................................................14 1.4. BENEFICIOS. ......................................................................................................15 1.5. BENEFICIARIOS. ................................................................................................15 1.6. OBJETIVO GENERAL. ........................................................................................15 1.7. OBJETIVOS ESPECÍFICOS. ...............................................................................15 1.8. MARCO INSTITUCIONAL. ...................................................................................16 1.9. ANÁLISIS DE IMPACTOS. ..................................................................................16 MARCO TEÓRICO .......................................................................................................................... 21

2.1. SÍNTESIS DE ANTECEDENTES. .........................................................................21 2.1.1. GESTIÓN DE RED. ................................................................................................21 2.1.2. ARQUITECTURA DE GESTIÓN DE RED. ...................................................................21 2.1.3. PARADIGMA GESTOR AGENTE. .............................................................................22 2.1.4. ÁREAS FUNCIONALES DE LA GESTIÓN DE RED. ......................................................23 2.1.4.1. LA GESTIÓN DE CONFIGURACIÓN. ......................................................................23 2.1.4.2. LA GESTIÓN DE PRESTACIONES. ........................................................................23 2.1.4.3. LA GESTIÓN DE FALLOS. ...................................................................................24 2.1.4.4. LA GESTIÓN DE SEGURIDAD. .............................................................................24 2.1.4.5. LA GESTIÓN DE CONTABILIDAD..........................................................................24 2.2. BASES TEÓRICAS CIENTÍFICAS. ......................................................................24 2.2.1. MONITOREO DE REDES INFORMÁTICAS. ................................................................24 2.2.2. SISTEMA DE MONITOREO DE RED. .........................................................................25 2.2.3. BASE DE INFORMACIÓN DE MANEJO. ....................................................................26 2.2.3.1. EJEMPLO DE UN ÁRBOL MIB. ............................................................................28 2.2.4. PROTOCOLO SIMPLE DE ADMINISTRACIÓN DE RED................................................30 2.2.4.1. VERSIONES DE SNMP. .....................................................................................30 2.2.4.2. COMPONENTES DE UNA RED SNMP. .................................................................31 2.2.5. PROGRAMAS OPEN SOURCE.................................................................................33 2.3. DEFINICIÓN DE TÉRMINOS................................................................................35 2.3.1. PÁGINA WEB. ......................................................................................................35 2.3.2. PROTOCOLOS. ....................................................................................................35 2.3.2.1. HTTP. .............................................................................................................36 2.3.2.2. ICMP. .............................................................................................................36 2.3.2.3. POP3. .............................................................................................................36

2.3.2.4. SMTP. ............................................................................................................36 2.3.2.5. TCP/IP. ...........................................................................................................36 2.3.3. RED INFORMÁTICA...............................................................................................36 2.3.4. RED LAN............................................................................................................37 2.3.5. RED WAN. .........................................................................................................37 2.3.6. RED DE ÁREA LOCAL VIRTUAL. ...........................................................................37 2.3.7. SERVIDOR...........................................................................................................37 2.3.8. SERVIDOR DE CORREO ELECTRÓNICO...................................................................37 2.3.9. SERVIDOR PROXY. ...............................................................................................37 2.3.10. SERVIDOR WEB. ................................................................................................38 2.3.11. SERVICIOS DE RED. ...........................................................................................38 METODOLOGÍA .............................................................................................................................. 39

3.1. METODOLOGÍA DE INVESTIGACIÓN CUALITATIVA O ESTRUCTURAL. ........39 3.2. TÉCNICAS DE INVESTIGACIÓN. ........................................................................39 3.2.1. ENTREVISTA SEMIESTRUCTURADA........................................................................39 3.2.2. REQUERIMIENTO DE INFORMACIÓN. ......................................................................40 3.2.3. ANÁLISIS DE DOCUMENTOS. .................................................................................41 3.2.4. INTERNET............................................................................................................41 3.2.5. OBSERVACIÓN CIENTÍFICA. ..................................................................................42 3.2.6. EXPERIMENTACIÓN CIENTÍFICA. ............................................................................43 RESULTADOS Y DISCUSIÓN ........................................................................................................ 44

4.1. MATRIZ DE SELECCIÓN DE LA MEJOR HERRAMIENTA DE MONITOREO. ....44 4.1.1. ANÁLISIS DE REQUERIMIENTOS DE LA HERRAMIENTA DE MONITOREO. ....................44 4.1.1.1. TOPOLOGÍA DE RED. .........................................................................................44 4.1.1.1.1. DIAGRAMA GENERAL DE RED DE LA PUCE SD................................................45 4.1.1.1.2. TOPOLOGÍA DE RED DEL CUARTO DE SERVIDORES DEL EDIFICIO SAN LIBORIO. .46 4.1.1.1.3. TOPOLOGÍA DE RED DEL CUARTO DE SERVIDORES DEL EDIFICIO EMILIO LORENZO ESTEHLE. .....................................................................................................48 4.1.1.1.4. TOPOLOGÍA DE RED DEL EDIFICIO DAPONTE....................................................49 4.1.1.1.5. TOPOLOGÍA DE RED DEL EDIFICIO MISEREOR PLANTA BAJA. ............................50 4.1.1.2. LISTA DE DISPOSITIVOS CONECTADOS A LA RED. ................................................50 4.1.2. INVESTIGACIÓN DE LAS HERRAMIENTAS DE MONITOREO EN INTERNET. ...................51 4.1.3. EVALUACIÓN DE LAS HERRAMIENTAS DE MONITOREO. ...........................................59 4.1.3.1. ELIMINACIÓN PRELIMINAR DE LAS HERRAMIENTAS DE MONITOREO. .....................59 4.1.3.2. COMPARACIÓN Y EVALUACIÓN DE LAS HERRAMIENTAS DE MONITOREO. ..............63 4.1.3.2.1. ESTRUCTURA DE EVALUACIÓN. ......................................................................64 4.1.3.2.2. MÉTODOS DE LOS PROCESOS DE EVALUACIÓN. ...............................................65 4.1.3.2.2.1. REGLA DE TRES SIMPLE. .............................................................................65 4.1.3.2.3. REGLA DE TRES INVERSA. ..............................................................................65 4.1.3.2.3.1. RELACIÓN CONDICIONAL.............................................................................66 4.1.3.2.4. PROCESO DE INSTALACIÓN. ...........................................................................66 4.1.3.2.5. PROCESO DE CONFIGURACIÓN. ......................................................................71 4.1.3.2.6. CARACTERÍSTICAS GENERALES. ....................................................................74 4.1.3.2.7. EVALUACIÓN FINAL. ......................................................................................80

4.2. HERRAMIENTA DE MONITOREO PREPARADA PARA SU CONFIGURACIÓN. ....................................................................................................................82 4.2.1. ADQUISICIÓN Y ENSAMBLADO DE LOS COMPONENTES DEL SERVIDOR. ....................82 4.2.1.1. COMPONENTES. ...............................................................................................82 4.2.1.2. VERIFICACIÓN Y CUIDADO .................................................................................85 4.2.1.3. HERRAMIENTAS ...............................................................................................86 4.2.1.4. PREPARATIVOS PREVIOS AL ENSAMBLAJE .........................................................87 4.2.1.5. ELEMENTOS PRINCIPALES E INSTALACIÓN DE MAINBOARD ..................................88 4.2.2. INSTALACIÓN Y CONFIGURACIÓN DEL SISTEMA OPERATIVO CENTOS 5.5. ...............92 4.2.3. INSTALACIÓN DE LA HERRAMIENTA DE MONITOREO NAGIOS. .................................92 4.3. MONITOREO DE LOS DISPOSITIVOS DE RED Y SUS SERVICIOS. ..................92 4.3.1. CONFIGURACIÓN DE MONITOREO DE DISPOSITIVOS DE RED Y SUS RECURSOS. ........94 4.3.2. CONFIGURACIÓN DEL MONITOREO DE LOS SERVICIOS DE RED ................................99 4.3.2.1. CONFIGURACIÓN DEL MONITOREO DE UN SERVICIO DE RED. .............................100 4.3.2.1.1. CONFIGURACIÓN DEL MONITOREO DEL SERVICIO DE RED HTTP.....................100 4.3.2.1.2. CONFIGURACIÓN DE MONITOREO DEL SERVICIO DE RED SSH. ........................102 4.3.2.1.3. CONFIGURACIÓN DE MONITOREO DEL SERVICIO DE RED SMTP. .....................103 4.3.2.1.4. CONFIGURACIÓN DEL MONITOREO DEL SERVICIO DE RED SQUID...................104 4.3.2.1.5. CONFIGURACIÓN DEL MONITOREO DEL SERVICIO DE RED DNS. .....................106 4.3.2.1.6. CONFIGURACIÓN DEL MONITOREO DEL SERVICIO DE RED SMB. .....................107 4.3.2.1.7. CONFIGURACIÓN DEL MONITOREO DEL SERVICIO DE RED MYSQL. ................108 4.3.3. CONFIGURACIÓN DEL ENVÍO DE ALERTAS ...........................................................109 4.4. MANUALES DE LA HERRAMIENTA NAGIOS. .................................................111 4.4.1. ELABORACIÓN DEL MANUAL DE INSTALACIÓN DE LA HERRAMIENTA NAGIOS. ........111 4.4.2. ELABORACIÓN DEL MANUAL DE CONFIGURACIÓN DE LA HERRAMIENTA NAGIOS ....112 4.4.3. ELABORACIÓN DEL MANUAL DE USUARIO DE LA HERRAMIENTA NAGIOS. ..............113 4.5. PRUEBAS DE FUNCIONAMIENTO DE LA HERRAMIENTA OPEN SOURCE NAGIOS, VERSIÓN 3.2.3..........................................................................113 4.5.1. EJECUCIÓN DE PRUEBAS. ..................................................................................113 4.5.2. PRUEBAS DE CAJA NEGRA. ...............................................................................114 4.5.3. ESTRATEGIAS DE PRUEBAS. ..............................................................................115 CONCLUSIONES Y RECOMENDACIONES ................................................................................ 119

CONCLUSIONES. ....................................................................................................119 RECOMENDACIONES. ............................................................................................120 BIBLIOGRAFÍA.............................................................................................................................. 121 GLOSARIO .................................................................................................................................... 128 LISTA DE ANEXOS ....................................................................................................................... 135

LISTA DE CUADROS E ILUSTRACIONES. Cuadro 1. Matriz de impacto en la productividad de los servicios y dispositivos de red. ..17 Cuadro 2. Impacto tecnológico. .......................................................................................18 Cuadro 3. Matriz de impacto social. .................................................................................19 Cuadro 4. Matriz de impacto general. ..............................................................................20 Cuadro 5. Requerimientos de la herramienta de monitoreo. ............................................51 Cuadro 6. Preselección de las herramientas de monitoreo open source. .........................61 Cuadro 7. Porcentajes de la evaluación final. ..................................................................64 Cuadro 8. Ejemplo del cuadro de valoración. ...................................................................64 Cuadro 9. Ejemplo del cuadro de evaluación. ..................................................................65 Cuadro 10. Valoración del proceso de instalación. ..........................................................69 Cuadro 11. Evaluación del proceso de instalación. ..........................................................69 Cuadro 12. Valoración de la configuración de monitoreo. ................................................73 Cuadro 13. Evaluación de la configuración de monitoreo. ...............................................73 Cuadro 14. Valoración de las características generales por si o no .................................78 Cuadro 15. Valoración de las características generales por rango de dígitos. .................78 Cuadro 16. Evaluación de las características generales ..................................................79 Cuadro 17. Valoración de la evaluación final ...................................................................80 Cuadro 18. Evaluación final. ............................................................................................81 Cuadro 19. Estrategias de pruebas................................................................................115 Ilustración 1. Estructura en árbol de un MIB. ...................................................................29 Ilustración 2. Ejemplo de una red SNMP..........................................................................32 Ilustración 3. Logo de los programas open source. ..........................................................34 Ilustración 4. Diagrama general de red ............................................................................45 Ilustración 5. Leyenda de los diagramas de red ...............................................................46 Ilustración 6. Topología de red en el edificio San Liborio. ................................................48 Ilustración 7. Topología de red en el edificio Emilio Lorenzo Stehle. ................................49 Ilustración 8. Topología de red en el edificio Daponte. .....................................................49 Ilustración 9. Topología de red en el edificio Misereor planta baja. ..................................50 Ilustración 10. Logo de la página web de Cacti ................................................................51 Ilustración 11. Encabezado de la página web de Centreon ..............................................52 Ilustración 12. Encabezado de la página web de Co-Pilot ................................................52 Ilustración 13. Encabezado de la página web de Ganglia ................................................53 Ilustración 14. Encabezado de la página web de JFFNMS ..............................................53 Ilustración 15. Encabezado de la página web de Munin...................................................54 Ilustración 16. Encabezado de la página web de Nagios .................................................55 Ilustración 17. Encabezado de la página web de Opsview ...............................................55 Ilustración 18. Encabezado de la página web de Opsview ...............................................56 Ilustración 19. Encabezado de la página web de Pandora FMS ......................................57 Ilustración 20. Encabezado de la página web de Zabbix ..................................................58 Ilustración 21. Encabezado de la página web de Zenoss .................................................59 Ilustración 22. Gráfico estadístico del cuadro de evaluación del proceso de instalación. .70

XII

Ilustración 23. Gráfico estadístico de la evaluación total del proceso de instalación. .......70 Ilustración 24. Gráfica de la evaluación de parámetros del proceso de configuración. .....73 Ilustración 25. Gráfica de la evaluación total del proceso de configuración. .....................74 Ilustración 26. Gráfica de la evaluación de las Características de las Herramientas. .......79 Ilustración 27. Gráfica de la evaluación total de las características de las herramientas de monitoreo.........................................................................................................................80 Ilustración 28. Gráfica de la evaluación de los procesos y características. ......................81 Ilustración 29. Gráfica de la evaluación final de las herramientas de monitoreo...............81 Ilustración 30. Componentes adquiridos para armar el servidor. ......................................83 Ilustración 31. Componentes adquiridos detallados. ........................................................84 Ilustración 32. Procesador, detalles. ................................................................................85 Ilustración 33. Herramientas necesarias para ensamblar el servidor. ..............................86 Ilustración 34: Case, componentes y uso de pulsera antiestática. ...................................87 Ilustración 35: Partes principales del mainboard ..............................................................88 Ilustración 36: Acoplamiento de mainboard y componentes principales. ..........................89 Ilustración 37: Componentes instalados en mainboard. ...................................................90 Ilustración 38. Servidor ensamblado completamente. ......................................................91 Ilustración 39. Esquema del proceso de monitoreo de Nagios. ........................................94 Ilustración 40. Ejemplo de envío de notificaciones de Nagios. .......................................111

ANTECEDENTES Y JUSTIFICACIÓN 1.1. INTRODUCCIÓN. El mundo actual se encuentra vinculado a servicios proporcionados por redes informáticas y por los equipos que las conforman, pertenecientes a alguna institución o empresa, a pesar de que la mayoría de los usuarios ni siquiera se percatan de todos los elementos que existen y permiten el funcionamiento de los servicios, hacemos uso de los mismos al hablar por dispositivos móviles, obtener dinero de cajeros automáticos, utilizar sistemas informáticos en nuestros trabajos, comunicarnos por medio de programas de mensajería instantánea como por ejemplo: windows live messenger o yahoo messenger, navegar por sitios web en internet desde nuestros hogares, lugares de trabajo, restaurantes, gasolineras, centros comerciales, universidades, entre otros; realizando algunas e incluso todas estas actividades sin problemas. ¿Pero qué sucede cuando no podemos realizar una llamada porque la red está ocupada?, ¿Cuándo nos encontramos frente al cajero automático con el mensaje de: ―su banco se encuentra fuera de línea‖?, ¿Cuándo no hay sistema en las entidades de servicios públicas y/o privadas? o ¿Cuándo falla la conexión a internet?, es en esos momentos cuando nos percatamos de como el correcto funcionamiento de estos servicios facilitan nuestras actividades e incluso lo dependientes que somos de los mismos. Detrás de estos servicios existen personas como los técnicos y administradores de red, las cuales son muy conscientes acerca de la importancia tanto de la calidad como la disponibilidad de los servicios y dispositivos en las redes informáticas, que se encuentran bajo su responsabilidad. Para realizar este trabajo de manera más eficiente se han creado los Sistemas de Administración de Red, NMS (Network Management System), un sistema NMS ejecuta aplicaciones que monitorean y administran la red de forma integral, por lo tanto se lo considera un sistema importante dentro de cualquier red informática cuyo desempeño afecta de manera directa o indirecta a la productividad y eficiencia de sus usuarios. La Pontificia Universidad Católica del Ecuador sede Santo Domingo (PUCE SD) posee

una infraestructura de red que contiene varios servidores, dispositivos y servicios de red, además de una comunidad de usuarios conformada por el personal que labora en la universidad, estudiantes, entre otros; la red se encuentra administrada por la Subárea de Redes del CITIC; con el fin de brindar un mayor soporte a la disponibilidad y productividad de la infraestructura de red, y siguiendo la tendencia de la universidad y del mundo en utilizar programas de código abierto (Open Source), se desarrolló el presente proyecto denominado: ―Estudio de herramientas Open Source, para monitoreo de red e implementación de la herramienta más óptima en la red de la PUCE SD‖.

1.2. PROBLEMÁTICA. La Subárea de Redes del CITIC de la PUCE SD, utiliza la herramienta Cacti con licencia GPL, versión 0.8.7d, para el monitoreo de los recursos de los servidores de las redes DMZ y LAN, mediante el cual obtienen gráficas estadísticas (ver anexo 1), a través de la herramienta MRTG (Multi Router Traffic Grapher) obtiene los datos RRDtool (Round Robin Data Base Tool) a graficar, de los recursos de los servidores, en base al protocolo SNMP y éstas gráficas son evaluadas por una persona asignada a dicha tarea. Los problemas ocurren cuando se origina un evento crítico, como por ejemplo interrupción del servicio de página web, del servicio de internet, de correo electrónico, entre otros, la herramienta implementada actualmente no envía ningún tipo de alerta, razón por la cuál es necesario que el personal este accediendo a la herramienta rutinariamente, pero: ¿Qué sucede en el horario fuera de trabajo?, ¿En el periodo de vacaciones?, ¿Sí el responsable se encuentra realizando otras actividades?. Por lo expuesto el monitoreo actual es dependiente, reactivo y podría realizarse de una manera más óptima.

1.3. JUSTIFICACIÓN. Se requiere que la herramienta de monitoreo a más de que realice gráficas estadísticas de recursos de los servidores y servicios como http, smtp, entre otros; envíe alertas sí sucede algún evento crítico al personal encargado de cada servidor y servicio de red, los mensajes se enviarán a través de internet (e-mail) y/o mensajes a dispositivos móviles (SMS). Buscando la solución a la problemática planteada se desarrolló el presente proyecto que consistió en: investigación de herramientas de monitoreo de red open source disponibles y una vez recopilada toda la información necesaria se procedió a comparar y evaluar las

herramientas, obteniendo la más óptima y adecuada para la infraestructura de red de la PUCE SD, a continuación se realizó su instalación, configuración de monitoreo, envío de alertas y finalmente las pruebas de funcionamiento.

1.4. BENEFICIOS. Los beneficios a corto plazo serán el monitoreo automático de: servicios de red http, smtp, ssh, squid, dhcp, dns, monitoreo de las bases de datos mysql y oracle; recursos de servidores y estaciones de trabajo como carga del procesador, carga de la memoria RAM y swap o memoria virtual, espacio de disco duro, además del monitoreo de dispositivos de red. Independencia del monitoreo presencial, permanente y cotidiano, obteniendo una reducción de los tiempos de reacción ante eventos críticos de los servicios de red, aumentando la disponibilidad 24x71 y la operación continua. A largo plazo permitirá una óptima administración de los recursos de los servidores y servicios, brindando así confiabilidad de los servicios de red prestados por la universidad.

1.5. BENEFICIARIOS. El beneficiario directo es la Subárea de Redes del CITIC, los beneficiarios indirectos son los diferentes estamentos de la PUCE SD y todas las personas que utilicen los servicios proporcionados por la red.

1.6. OBJETIVO GENERAL. Apoyar la estabilidad y confiabilidad de la transmisión de datos de la red, los recursos de los servidores y servicios de red informática perteneciente a la PUCE SD, realizando el estudio de herramientas open source, para monitoreo de red e implementación de la herramienta más óptima.

1.7. OBJETIVOS ESPECÍFICOS. 

Estudiar y comparar las diferentes herramientas open source de monitoreo.



Ensamblar el servidor de monitoreo e instalar el software necesario para su posterior configuración.

 1

Monitorear los recursos y servicios de los servidores, el estado activo de los

Las 24 horas de los 7 días de la semana.

dispositivos de red, y configurar el envío de mensajes de texto vía e-mail y SMS, a los responsables o administradores de los equipos. 

Elaborar los manuales de instalación, configuración y de usuario de la herramienta de monitoreo.



Comprobar y documentar el correcto funcionamiento de la herramienta de monitoreo instalada.

1.8. MARCO INSTITUCIONAL. Actualmente el monitoreo de red es una actividad muy importante y crítica; esto debido a que las redes se han vuelto más complejas y exigentes en sus operaciones; gracias al avance de la tecnología y la considerable reducción en costos de los equipos y herramientas que hacen posible la realización de dicha actividad, las empresas integran a su departamento de sistemas un servidor de monitoreo de red. El hecho de que las redes informáticas estén distribuidas en todo el mundo, nos deja claro y sin lugar a dudas, que el monitoreo de los recursos de los servidores, la disponibilidad y desempeño de los servicios, es una actividad realizada a nivel mundial. El uso de herramientas de monitoreo se viene implementando por empresas que se preocupan y que incluso su existencia depende del buen funcionamiento de su red informática y todos los elementos que la componen, desde grandes compañías de software como McAfee, empresas de comunicaciones como AT&T, empresas multinacionales de comidas rápidas como Domino’s Pizza, empresas internacionales con asiento en Ecuador como la empresas DHL, Oracle y Linksys, empresas locales como la sucursal de Punto Net en la provincia de Santo Domingo de los Tsáchilas.

1.9. ANÁLISIS DE IMPACTOS. El tipo de análisis de impacto que se utilizó fue el prospectivo, puesto que al momento de la recopilación de datos no existía información necesaria para poder contrastar con los datos generados por la herramienta de monitoreo implementada. Los análisis de impactos realizados fueron: Impacto en la Productividad de los Servicios y Dispositivos de Red, Impacto Tecnológico, Impacto Social; los mismos que nos permitieron obtener un Análisis de Impacto General.

Para la valoración de los indicadores dentro de las Matrices de Análisis de Impacto se utilizaron los siguientes niveles numéricos: -3

Impacto alto negativo

-2

Impacto medio negativo

-1

Impacto bajo negativo

No existe impacto

Impacto bajo positivo

Impacto medio positivo

Impacto alto positivo

A continuación se detallan las matrices de Impacto:

IMPACTO EN LA PRODUCTIVIDAD DE LOS SERVICIOS Y DISPOSITIVOS DE RED NIVELES DE IMPACTO Indicador - Reducción del tiempo de resolución de problemas - Disponibilidad - Rendimiento TOTAL

-3

-2

-1

x 2 =

3 x x 6 8

 Nivel de impacto en la productividad = de los servicios y dispositivos de red Número de Indicadores 8 Nivel de impacto = = 2,67 3 Nivel de impacto en la productividad de los servicios y dispositivos de red

Impacto Alto Positivo

Cuadro 1. Matriz de impacto en la productividad de los servicios y dispositivos de red. Análisis:  En relación a la reducción del tiempo de resolución de problemas se considera que el impacto es alto positivo, porque el funcionamiento de la herramienta de monitoreo permite detectar los problemas de red y automáticamente enviar una alerta al

responsable del servicio o dispositivo, ocasionando que los problemas se resuelvan en menor tiempo.  En relación al nivel de disponibilidad se considera que el impacto es alto positivo, ya que la disponibilidad de los dispositivos y servicios de red aumentará debido al monitoreo constante implementado por la herramienta.  Respecto al nivel de rendimiento se prevé un impacto medio positivo, debido a que la ejecución del proyecto permitirá que los dispositivos y servicios de red mantengan un rendimiento normal al reducirse su tiempo de resolución de problemas y aumentar su disponibilidad. IMPACTO TECNOLÓGICO NIVELES DE IMPACTO Indicador - Automatización de procesos - Aporte tecnológico - Administración tecnológica TOTAL

-3

Nivel de impacto tecnológico

-1

x 0 4 3  7

 Número de Indicadores

Nivel de impacto tecnológico = Nivel de impacto =

-2

7 3

= 2,33

2 x x



= Impacto Medio Positivo

Cuadro 2. Impacto tecnológico.

Análisis.  Respecto al nivel de automatización de procesos se estima un impacto medio positivo, debido a que la herramienta de monitoreo implementada para el proyecto aportará automatizando algunos de los procesos de supervisión de los servicios y dispositivos de red como son la recolección de información de monitoreo y el envío de alertas de manera automática.

 En relación al nivel de aporte tecnológico se considera que el impacto es medio positivo, porque se contribuye con una nueva herramienta a las tecnologías ya

implementada en la Universidad.  Para el nivel de administración tecnológica se estima un impacto alto positivo, ya que es una característica propia de la herramienta de monitoreo implementada, mejorar la administración de los dispositivos y servicios de red.

IMPACTO SOCIAL NIVELES DE IMPACTO Indicador - Confianza de los usuarios en los servicios de red - Prestigio de la universidad - Aporte Investigativo TOTAL

Nivel de Impacto Social

Nivel de Impacto en la Sociedad

-2

-1

2 3 x x x 0 6 0 = 6

 Número de Indicadores

Nivel de Impacto =

-3

6 3

= 2

= Impacto Medio Positivo

Cuadro 3. Matriz de impacto social.

Análisis.  Respecto al nivel de confianza de los usuarios en los servicios de red, se considera un impacto medio positivo, ya que la herramienta de monitoreo implementada para el proyecto permitirá apoyar la estabilidad y confiabilidad de la red informática, principalmente de los servicios de red, proporcionando al usuario servicios de red disponibles y funcionando el mayor tiempo posible, aumentando la confianza en el uso de los mismos.

 En relación al nivel de prestigio de la universidad, se estima un impacto medio positivo porque la herramienta de monitoreo aumentará la disponibilidad y estabilidad en los servicios de red lo que se reflejará en la productividad y eficiencia general del funcionamiento de la Universidad, aumentando así el prestigio en su comunidad de usuarios y en la sociedad.

 En relación al nivel de aporte investigativo, se estima un impacto medio positivo, porque la documentación del proyecto al permanecer en la biblioteca de la PUCE SD es considerado de acceso público, por lo que representa un aporte investigativo para la sociedad. IMPACTO GENERAL NIVELES DE IMPACTO Indicador - IMPACTO EN LA PRODUCTIVIDAD DE LOS SERVICIOS Y DISPOSITIVOS DE RED - IMPACTO TECNOLÓGICO

-3

Nivel de Impacto General

 Número de Indicadores

= 7 3

x 0 4 3  7 

 

= 2,33

x 0

NI =

-1

- IMPACTO SOCIAL TOTAL

Nivel de impacto general

-2

Impacto Medio Positivo

Cuadro 4. Matriz de impacto general.

Análisis.  Elaboradas las matrices de impacto para cada área, se obtuvieron los siguientes resultados: el valor de 2,67 en el impacto en la productividad de los servicios de red que representa un impacto alto positivo, el valor de 2,33 en el impacto tecnológico que representa un impacto medio positivo y el valor de 2 en el impacto social, que significa un impacto medio positivo; aplicando los resultados de los impactos mencionados como indicadores en la matriz de impacto general y después de aplicar la fórmula correspondiente se obtiene un impacto general de 2,33 , que significa que el proyecto implementado tendrá un impacto en un nivel medio positivo.

I MARCO TEÓRICO 2.1. SÍNTESIS DE ANTECEDENTES. 2.1.1. Gestión de red. Según Antonio Martín Montes en su obra ―Gestión de Redes‖, citada textualmente es: ―Conjunto de tareas de monitorización, información y control necesarias para operar efectivamente en una red. Estas tareas pueden estar distribuidas sobre diferentes nodos de la red, lo cual puede requerir repetidas acciones de recogida de datos y análisis cada vez que sucede un nuevo evento en la red. Las tareas de gestión de red se lleva a cabo por el personal responsable o por procesos automáticos de gestión‖, también expresa que: ―El objetivo final de la gestión de red es garantizar un nivel de servicio en los sistemas de una organización el máximo tiempo posible, minimizando la perdida que ocasionaría un parada o funcionamiento incorrecto del sistema.‖ Otra definición de gestión de redes según T. Saydam y T. Magedanz, ―From Networks and Network Management into Service and Service Management‖, Journal of Networks and Systems Management, Vol. 4, No. 4, citada textualmente es: ―La gestión de redes incluye el despliegue, integración y coordinación del hardware, software y los elementos humanos para monitorizar, probar, sondear, configurar, analizar, evaluar y controlar los recursos de la red para conseguir los requerimientos de tiempo real, desempeño operacional y calidad de servicio a un precio razonable‖. De las definiciones dadas se concluye que la gestión de redes se trata de la tarea que cubre todas las precauciones y actividades que aseguren el uso eficiente y efectivo de procesos y recursos de una red informática.

2.1.2. Arquitectura de gestión de red. En cuanto a la arquitectura de gestión de red según Ramón Jesús Millán Tejedor, el artículo Gestión de Red publicado en su página web ―www.ramonmillan.com‖ lo define como: ―un centro de gestión, donde se controla y vigila el correcto funcionamiento de

todos los equipos integrados en las distintas redes de la empresa en cuestión. Un centro de gestión de red dispone de tres tipos principales de recursos: Métodos de gestión. Definen las pautas de comportamiento de los demás componentes del centro de gestión de red ante determinadas circunstancias. Recursos humanos. Personal encargado del correcto funcionamiento del centro de gestión de red. Herramientas de apoyo. Herramientas que facilitan las tareas de gestión a los operadores humanos y posibilitan minimizar el número de éstos.‖

2.1.3. Paradigma gestor agente. Este paradigma definido por TMN (Telecommunications Management Network) hace más de veinte años sigue siendo utilizado por los principales modelos de gestión de red de nuestros días, que es la estructura básica que utilizan los sistemas de gestión cuyo funcionamiento reside en el intercambio de información de gestión entre nodos gestores y nodos gestionados, una aplicación real de este paradigma se basa en distribuir agentes en la infraestructura de red a monitorizar, los mismos se encargan de recolectar eventos y enviarlos a un gestor central para su presentación y/o procesamiento. Según

artículo

Ramón

Millan

página

web

http://www.ramonmillan.com/tutoriales/gestionred.php los elementos del sistema de gestión de red bajo el paradigma gestor-agente, pueden clasificarse en: Los gestores son los elementos del sistema de gestión que interaccionan con los operadores humanos y desencadenan acciones necesarias para llevar a cabo las tareas por ellos invocadas. Los agentes, por otra parte, son los componentes del sistema de gestión invocados por el gestor o gestores de la red. También menciona que los componentes de los sistemas de gestión son: - Interfaz con el operador de la red. Es una pieza imprescindible. Permite declarar la realización de operaciones de control y atención de los recursos que se encuentren bajo su incumbencia. Tiene la posibilidad de componerse de alarmas y alertas, análisis gráficos y reportes de actividad.

- Elementos hardware y software distribuidos entre los varios componentes de la red.

2.1.4. Áreas funcionales de la gestión de red. La ISO clasifica las tareas de los sistemas de gestión en cinco áreas funcionales: 

Gestión de Configuración.



Gestión de Prestaciones.



Gestión de Seguridad.



Gestión de Fallos.



Gestión de Contabilidad.

2.1.4.1. La gestión de configuración. La Gestión de Configuración es el proceso de obtención de datos de la red y utilización de los mismos para incorporar, mantener y retirar los diferentes componentes y recursos que la integran.

2.1.4.2. La gestión de prestaciones. La Gestión de Prestaciones tiene como principal objetivo el mantenimiento del nivel de servicio de la red. La gestión de prestaciones basa sus tareas en la definición de unos indicadores de funcionamiento. Es decir, es necesario fijar una serie de criterios que permitan conocer cuál es el grado de utilización de un recurso. Los indicadores más utilizados se clasifican en dos grandes grupos: Parámetros de funcionamiento orientados al servicio, los cuales miden el grado de satisfacción del usuario al acceder a los recursos, los más importantes son la disponibilidad, el tiempo de respuesta y la tasa de error. Parámetros de funcionamiento orientados a la eficiencia, estos miden el grado de utilización de los recursos, básicamente son la productividad y la utilización.

2.1.4.3. La gestión de fallos. La gestión de fallos tiene como objetivo fundamental la localización y recuperación de los problemas de la red. Abarca dos tareas principales:  Detección e identificación de fallos.  Corrección del problema. Las herramientas de monitoreo están vinculadas directamente a esta área, ya que son un apoyo tecnológico, siendo una vez implementadas protagonistas directas para la detección e identificación de los fallos.

2.1.4.4. La gestión de seguridad. El objetivo de la Gestión de Seguridad es ofrecer mecanismos que faciliten el mantenimiento de políticas de seguridad.

2.1.4.5. La gestión de contabilidad. La Gestión de Contabilidad tiene como misión la recolección de estadísticas que permitan generar informes de tarificación que reflejen la utilización de los recursos por parte de los usuarios.

2.2. BASES TEÓRICAS CIENTÍFICAS. 2.2.1. Monitoreo de redes informáticas. El monitoreo de redes informáticas es la actividad que al menos un servidor o conjunto de servidores, con varias herramientas de monitoreo correctamente funcionando, deben estar haciendo automáticamente, mientras los demás servidores realizan sus funciones vitales. El monitoreo de red se puede comparar a la vigilancia policial en el funcionamiento de la red. Se define como el conjunto de actividades dedicadas al control y vigilancia de recursos de la red informática. Su principal objetivo es garantizar que todos sus elementos proporcionen un buen nivel de servicio. El término monitoreo de red también se refiere al uso de un sistema que constantemente monitorea o supervisa una red informática en busca de componentes defectuosos o con

mal funcionamiento, para luego alertar a los administradores de redes mediante correo electrónico, mensaje de texto u otros medios, los mensajes de problema de red deben ser tomados como la más alta prioridad por los administradores, formando parte de un subconjunto muy importante de la administración de redes. Es una función crítica del gobierno de la Tecnología de la Información (IT), que puede ahorrar dinero en rendimiento de las redes, productividad de los empleados, costos de infraestructura inactiva, entre otros. Monitorear una red puede lograrse usando varios programas o una combinación de dispositivos de software y hardware. Virtualmente cualquier tipo de red puede ser monitoreada, no importa si es cableada o inalámbrica, si es una LAN corporativa, VPN o red WAN. Se puede monitorear dispositivos con diferentes sistemas operativos que pueden contener una multitud de funciones, pueden ser desde dispositivos celulares como blackberrys, hasta servidores, routers y switches. Monitoreo de red puede ser tan básico y específico como solo monitorear el funcionamiento de una página web, de la misma se puede rastrear el flujo de visitantes hacia y desde un sitio web, rastrear estadísticas como visitas, número de páginas visitadas en el sitio. Otro tipo de monitoreo puede ser el que se implementa con un sistema de detección de intrusos, el cual monitorea una red en busca de amenazas del exterior (externas a la red), o por último si se necesita seguir solo la eficiencia del enlace de subida, se implementa una medición de tráfico de red. Estos tipos de monitoreo de red no necesariamente son de la clase que reportan problemas, al menos que el administrador de red lo programe así, mejor dicho, solo rastrean y reportan su actividad para que en un futuro puedan ser analizadas, se consideran monitoreo pasivo.

2.2.2. Sistema de monitoreo de red. El sistema de monitoreo de red (Network Monitoring System - NMS), se refiere al programa que tiene la finalidad de monitorear y administrar una red informática, es una solución de software que ejecuta aplicaciones, comandos, plugins, entre otros, que supervisan y controlan a los dispositivos y servicios de red. Al menos un NMS debe existir en cualquier red, que se quiera mantener activa y siempre eficiente. Un NMS requiere que varias tareas de administración de red se unan en un solo software, este tipo de sistemas se encargan de automatizar los procesos de auditoría, gestión de ciclo de vida de los dispositivos de red, inventario de los dispositivos, entre otros, cada NMS en el mercado tiene sus propios fines y se especializan en diversas

áreas. Los NMS cuando tratan de determinar el estado de un servidor web, por ejemplo: el funcionamiento del servidor apache, puede enviar periódicamente peticiones HTTP para obtener páginas, si obtiene una página web significa que el servidor está activo y funcionando correctamente, si se trata de un servidor de correo electrónico, envía mensajes mediante SMTP, para luego ser retirados vía IMAP o POP3. Lo que evalúan los NMS normalmente es el tiempo de respuesta y disponibilidad, para así obtener estadística de consistencia y fiabilidad. El problema en instalar un NMS en una red WAN, es la visibilidad de ida y de vuelta entre los dispositivos de red monitoreados y el equipo donde reside el NMS. Fallas de peticiones de estado, como la conexión no pudo ser establecida o tiempo de espera agotado, entre otros, usualmente produce una acción del NMS. Estas acciones pueden variar:

una

alarma

puede

ser

enviada

administrador,

puede

ejecutar

automáticamente un mecanismo de control de falla, entre otros, la configuración de preferencia de los NMS es alertar al administrador para que él, con su experiencia y sabiduría, solucione los problemas de red, se prefiere la intervención de la inteligencia humana.

2.2.3. Base de información de manejo. La Base de Información de Manejo (Management Information Base – MIB), se deriva del modelo de administración OSI/ISO, y es una especie de base de datos utilizada para la gestión de los dispositivos conectados a una red informática. Comprende una colección de objetos en una base de datos virtual usada para gestionar las entidades dentro de una red, como routers, switches o wireless access point. Los objetos en el MIB son definidos usando un subconjunto de la notación sintáctica abstracta (Abstract Syntax Notation OneASN.1) llamado la segunda versión de la estructura de la información gestionada (Structure of Management Information Versión 2-SMIv2). Las MIB se implementan en dispositivos, donde los fabricantes crean necesaria la opción de ser supervisados, facilitan la toma de decisión sobre la administración de red y almacenan, administran y mantienen información de los diferentes dispositivos conectados a la red. El conjunto de información que almacenan, llamados objetos, contienen datos sobre funcionamiento y configuración de dispositivos informáticos, los cuales dependen del fabricante del dispositivo y sus intereses, su contenido están

debidamente publicadas en sus RFC, pero generalmente puede incluir: información de encaminamiento, información de protocolo, estadísticas de red, número de paquetes transmitidos, número de conexiones intentadas, datos de contabilidad, entre otros. Los MIB contienen en orden jerárquico todos los objetos manejados, cada objeto tiene un identificador único, el identificador incluye el tipo (tal como contador, secuencia, o dirección), el nivel de acceso (tal como read/write), restricciones del tamaño, y la información del objeto. La documentación de internet, expone y discute los MIB, en particular el RFC 1155: Estructura e identificación de la información sobre la gestión para TCP / IP basados en Internet (Structure and Identification of Management Information for TCP/IP based internet), RFC 1213: Base de Información Manejada para Administración de red para TCP / IP basados en Internet

(Management

Information

Base

for

Network

Management of TCP/IP-based internets), y el RFC 1157: A Simple Network Management Protocol. Existen MIB para cada serie de entidades relacionadas con la red, por ejemplo, existen definiciones MIB específicas para AppleTalk, Fiber Distributed-Data Interface y objetos de red RS-232C. Desarrolladores de dispositivos pueden crear y registrar nuevas extensiones MIB dedicadas para sus creaciones. Algunas compañías crearon extensiones MIB para su conjunto de productos como Cisco, Fore, IBM, Novell, QMS y Onramp. Los MIB son actualizados periódicamente para añadir nuevas funcionalidades, eliminar ambigüedades y fijar los defectos. Estos cambios se realizan en conformidad con el artículo 10 del RFC 2578, el cual menciona las condiciones para realizar cambios en los MIB, como por ejemplo que no se puede cambiar el nombre de un módulo, dicho artículo contiene tres subcapítulos que son: asignación de objeto, definición de objeto, definición de notificación; un ejemplo de un MIB que se ha actualizado muchas veces es el importante conjunto de objetos que se había definido en el RFC 1213 ―MIB-II‖. Este MIB desde entonces se ha dividido y se puede encontrar en los RFC 4293 ―Management Information Base for the Internet Protocol (IP)", RFC 4022 "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4113 "Management Information Base for the User Datagram Protocol (UDP)", RFC 2863 "The Interfaces Group MIB", y el RFC 3418 "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)".

2.2.3.1. Ejemplo de un árbol MIB. En la cima del árbol MIB (ver ilustración 1), se encuentra la mayoría de la información general disponible sobre una red, y cada rama inferior contiene más detalles acerca de dispositivos y servicios específicos. El RFC 1155 Structure and Identification of Management Information for TCP/IP-based Internets expone el nodo raíz en sí, no tiene etiqueta, pero tiene al menos tres hijos directamente debajo de ella: un nodo es administrado por la Organización Internacional de Normalización, etiquetado en el árbol como iso (1), ubicado debajo de la etiqueta root (.), otro es administrado por el Comité Consultivo Internacional de Telégrafos y Teléfonos (International Telegraph and Telephone Consultative Committee), etiquetado como ccitt (0), y el tercero es administrado conjuntamente por la ISO y el CCITT, etiquetado como joint-iso-ccitt (2). Existen muchos niveles debajo de los tres nodos principales. Debajo del nodo iso (1), la ISO ha designado un subárbol para uso de otras organizaciones nacionales o internacionales llamado org (3). De los nodos hijos, dos han sido asignados para el Instituto Nacional de Normas y Tecnologías (U.S. National Institutes of Standards and Technology). Uno de estos subárboles ha sido transferido Al Departamento de Defensa de los Estados Unidos (U.S. Department of Defense), llamado dod (6). El subárbol directory (1) se reserva para uso futuro del directorio OSI, el subárbol mgmt (2) es usado para identificar objetos definidos por documentos aprobados por IAB (Internet Activity Board), la administración del subárbol mgmt (2) está delegada al Internet Assigned Numbers Authority for the Internet, el subárbol experimental (3) es usado para identificar objetos usados en experimentos de internet, la administración de este nodo esta delegado al Internet Assigned Numbers Authority del internet. El subárbol private (4) es usado para identificar los objetos definidos unilateralmente, la administración de

este nodo es delegada por la IAB a la IANA Internet Assigned

Numbers Authority para el internet, el subárbol private (4) tiene por lo menos un nodo hijo llamado enterprises (1), el mismo que es usado entre otras cosas para que las empresas registren modelos de sus productos. El subárbol mib-2 (1) representa base de datos común para la gestión de equipos en internet y se compone entre otros de los siguientes nodos estructurales:

System (1): De este nodo cuelgan objetos que proporcionan información genérica del sistema gestionado. Por ejemplo, dónde se encuentra el sistema, quién lo administra, entre otros. Interfaces (2): En este grupo se almacena la información de las interfaces de red presentes en el sistema. Incorpora estadísticas de los eventos ocurridos en el mismo. At (3): Este nodo es obsoleto, pero se mantiene para preservar la compatibilidad con la MIB-I. En él se almacenan las direcciones de nivel de enlace correspondientes a una dirección IP. Ip (4): En este grupo se almacena la información relativa a la capa IP, tanto de configuración como de estadísticas. Icmp (5): En este nodo se almacenan contadores de los paquetes ICMP entrantes y salientes. Tcp: En este grupo está la información relativa a la configuración, estadísticas y estado actual del protocolo TCP. Udp: En este nodo está la información relativa a la configuración, estadísticas del protocolo UDP.

Ilustración 1. Estructura en árbol de un MIB.

2.2.4. Protocolo Simple de Administración de Red. El Protocolo Simple de Administración de Red (Simple Network Management Protocol – SNMP), es un protocolo tipo UDP, que no se necesita iniciar sesión, consiste en un conjunto de estándares para administración de red, incluyendo un protocolo de capa de aplicación, un esquema de base de datos y un conjunto de objetos tipo datos. Este protocolo es usado principalmente por Sistemas de Administración de Red para monitorear o supervisar dispositivos o servicios que por su naturaleza, requieran atención administrativa, es un elemento de la Suite de Protocolo de Internet (en inglés Internet Protocol Suite) definido por la organización Internet Engineering Task Force – IETF. SNMP es un protocolo cliente/servidor cuya función es la comunicación con los dispositivos de red, recolectando información mediante el envío y recepción de paquetes, permitiendo a los administradores mantener registro de sus redes. El protocolo SNMP permite reunir información usando menos ancho de banda, memoria y lo más importante automáticamente. Existen herramientas de monitoreo que usan el protocolo SNMP para vigilar frecuentemente cientos de dispositivos simultáneamente con facilidad.

2.2.4.1. Versiones de SNMP. Actualmente existen tres versiones del protocolo SNMP, versión 1 (SNMPv1), versión 2 (SNMPv2) y versión 3 (SNMPv3). La versión 1 es la implementación inicial del protocolo SNMP, su descripción completa se encuentra en las RFC 1155, 1157 y 1212 del IETF, opera sobre los protocolos: User Datagram Protocol UDP, Connection Less Network Service CLNS, AppleTalk DatagramDelivery Protocol DDP y Novell Internet Packet Exchange IPX. La versión 1 es la más usada y es el protocolo de administración de red que por defecto utiliza la comunidad de internet, por lo que se distribuye en muchos dispositivos. La autenticación de clientes se basa en una palabra tipo cadena llamada comunidad, que es una especie de contraseña transmitida como texto sin cifrar. En la versión 2 se incluye mejoras en las áreas de rendimiento, seguridad, confidencialidad, se define en las RFC 1441-1452 del IETF. Introduce tres nuevas operaciones de protocolo: GetBulk para recuperar de una forma eficiente grandes cantidades de información de administración en una petición única; Inform para enviar

información espontánea al gestor y recibir una confirmación; y Report para enviar de forma espontánea excepciones y errores de protocolo. Reduce la carga de tráfico adicional para la monitorización y soluciona los problemas de monitorización remota o distribuida. La versión 2 provee seguridad extra, ya que todo lo que se transmite en los paquetes de datos está encriptado con excepción de la dirección de destino. El protocolo SNMP versión 3 fortalece las prestaciones de seguridad, incluyendo autentificación, privacidad y control de acceso, proporciona mayor modularidad y la posibilidad de configuración remota, se define en las RFC 1902-1908 y 2271-2275. Esta versión no reemplaza a SNMPv1 o SNMPv2, sino que define un conjunto de capacidades adicionales de seguridad y administración. El gestor y el agente comparten una clave secreta configurada previamente, utilizando un algoritmo de encriptación llamado CBC (Cipher Block Chaining). El modelo de control de acceso basado en vistas o VCAM (Views-Based Access Control Model) permite proporcionar diferentes niveles de acceso a las MIB de los agentes para los distintos gestores, consistiendo básicamente en una tabla que detalla los privilegios de acceso para los distintos gestores autorizados.

2.2.4.2. Componentes de una red SNMP. Una red SNMP (ver ilustración 2) consiste de 3 componentes principales: 

Dispositivo administrado.



Agente.



Sistemas de administración de red o NMS (Network Management System).

El dispositivo administrado es un periférico conectado a la red y que implementa el protocolo SNMP, los mismos que pueden ser: switches, servidores, routers, bridges, hubs, teléfonos IP, video cámaras IP, estaciones de trabajo, UPS, impresoras en red, etc. El agente es una aplicación o conjunto de aplicaciones que se encuentran en el dispositivo administrado, su función es recolectar información de administración del sistema y transmitir esta información al NMS. El agente transmite información al NMS central de la red acerca de: notificación de problemas datos de diagnóstico, identificador del nodo y características del nodo. El NMS es un programa, llamado en español herramienta de monitoreo, que forma una terminal a través del cual los administradores de la red pueden llevar a cabo tareas de

administración, observar el estado de la red, siendo un punto central al cual se dirigen los mensajes que requieren acción o que contienen información solicitada por el NMS al agente, creando una conexión virtual.

. Ilustración 2. Ejemplo de una red SNMP Los tipos de mensajes SNMP que se intercambian entre los Agentes y los NMS son: - Get Request Una petición del NMS al Agente para que envíe los valores contenidos en el MIB (base de datos). - Get Next Request Una petición del NMS al Agente para que envíe los valores contenidos en el MIB referente al objeto siguiente al especificado anteriormente.

- Get Response La respuesta del Agente a la petición de información lanzada por el NMS. - Set Request Una petición del NMS al Agente para que cambie el valor contenido en el MIB referente a un determinado objeto. - Trap Un mensaje espontáneo enviado por el NMS al Administrador, al detectar una condición predeterminada, como es la conexión/desconexión de una estación o una alarma. - GetBulkRequest Este mensaje es la versión optimizada de GetNextRequest y es usado a partir de la versión 2 del protocolo SNMP, se utiliza cuando es requerida una larga transmisión de datos, tal como la recuperación de largas tablas. - InformRequest Mensaje compatible a partir de la versión 2 del protocolo SNMP, transmite un mensaje con formato de mensaje Trap entre NMS con las mismas características, con el objetivo de notificar información sobre objetos administrados, la entrega es confirmada y los paquetes perdidos son reportados. - Report Este mensaje fue definido desde la versión 2 pero no fue implementada hasta la versión 3, su función es la de permitir la comunicación entre agentes, principalmente para reportar problemas con el proceso de mensajes SNMP.

2.2.5. Programas open source. Según la página oficial de la iniciativa Open Source (www.opensource.org), en español código abierto, define a Open Source (ver ilustración 3) como: ―un método de desarrollo de software que aprovecha el poder de distribuir la revisión minuciosa y transparente de los procesos. La promesa de Open Source es de mejor calidad, mayor fiabilidad, más flexibilidad, menor costo, y el fin del depredador encadenamiento a los vendedores‖.

Ilustración 3. Logo de los programas open source2. Para que un programa sea considerado open source, en su licencia debe cumplir las siguientes condiciones3: 1. Libre redistribución: el software debe poder ser entregado o vendido libremente. 2. Código fuente: el código fuente debe estar incluido u obtenerse libremente. 3. Trabajos derivados: la redistribución de modificaciones debe estar permitida. 4. Integridad del código fuente del autor: las licencias pueden requerir que las modificaciones sean redistribuidas sólo como parches. 5. Sin discriminación de personas o grupos: nadie puede dejarse fuera. 6. Sin discriminación de áreas de iniciativa: los usuarios comerciales no pueden ser excluidos. 7. Distribución de la licencia: deben aplicarse los mismos derechos a todo el que reciba el programa. 8. La licencia no debe ser específica de un producto: el programa no puede licenciarse solo como parte de una distribución mayor. 9. La licencia no debe restringir otro software: la licencia no puede obligar a que algún otro software que sea distribuido como software abierto deba también ser de código abierto. 10. La licencia debe ser tecnológicamente neutral: no debe requerirse la aceptación de la licencia por medio de un acceso por clic de ratón o de otra forma específica del medio de soporte del software. La idea que divulga la iniciativa open source es que sí los programadores pueden leer, 2 3

Imagen tomada de www.opensource.org Condiciones tomadas de la página oficial del movimiento open source www.opensource.org/docs/osd

modificar y redistribuir el código fuente de un programa, éste evoluciona, se desarrolla y mejora. Los usuarios pueden adaptarlo según sus necesidades, corrigen sus errores y esto puede ocurrir a tal velocidad que deja atrás a los programas comerciales. El software libre es distribuido y desarrollado libremente, su punto de vista es orientado a los beneficios prácticos de compartir el código, su fuerte es desarrollar y compartir el software en comunidad, por lo que tiende a ser de calidad superior al software propietario. Algunos ejemplos de programas open source se listan a continuación: 

Linux - Sistema Operativo basado en UNIX.



Apache - Servidor Web.



Mozilla Firefox - Navegador de internet.



Mozilla Thunderbird - Cliente de E mail.



OpenOffice - Suite para oficina.



Symbian - Sistema Operativo en tiempo real.



Mediawiki - Servidor de software wiki, el software que ejecuta Wikipedia.

2.3. DEFINICIÓN DE TÉRMINOS. 2.3.1. Página web. Página web o página de internet es un documento electrónico adecuado para la web, contiene información específica (texto o multimedia), hiperenlaces, puede contener datos de estilo para especificar su visualización y aplicaciones incrustadas con la finalidad de convertirla en interactiva, comúnmente las páginas web son almacenadas en un servidor web y pueden ser accedidas a través de un navegador.

2.3.2. Protocolos. En redes, es el conjunto de reglas y normas que especifican de manera formal el intercambio de información entre dispositivos, los protocolos más usados son:

2.3.2.1. HTTP. Protocolo de Transferencia de Hipertexto (HyperText Transfer Protocol); es un protocolo de capa de aplicación, mediante el cual se realiza el intercambio de información entre el navegador de internet (Internet Explorer, Mozilla Firefox, Google Chrome, entre otros) y el servidor web.

2.3.2.2. ICMP. Protocolo de Mensajes de Control de Internet (Internet Control Message Protocol), protocolo de la capa de red que permite notificar errores de los equipos en red y proporcionar información pertinente para el procesamiento de paquetes IP. Usado para enviar mensajes de control y de error, indicando por ejemplo si un servicio de red no se encuentra disponible o que un router o host no puede ser localizado.

2.3.2.3. POP3. Protocolo de Oficina de Correos versión 3 (Post Office Protocol 3); utilizado por los clientes para la recepción del correo almacenado en un servidor.

2.3.2.4. SMTP. Protocolo Simple de Transferencia de Correo (Simple Mail Transfer Protocol), perteneciente a la capa de aplicación, es empleado para transporte y entrega de correo electrónico entre dispositivos que soporten dicho protocolo.

2.3.2.5. TCP/IP. Protocolo de Control de Transmisión / Protocolo de Internet (Transmisión Control Protocol / Internet Protocol), es en sí un conjunto de protocolos que permiten la creación de redes interconectadas, y su conmutación de datos entre las mismas.

2.3.2.6. Red informática. Conjunto de equipos

como computadoras y/o dispositivos conectados por medio de

cables, señales (análogas y digitales), ondas o cualquier otro medio de transporte de datos, que comparten información , recursos y servicios para un determinado fin.

2.3.3. Red LAN. Red de Área Local (Local Area Network), red informática que abarca un área geográficamente pequeña (miles de metros) y limitada, usualmente interconecta estaciones de trabajo, dispositivos periféricos y demás unidades capaces de ser conectadas a una red, con la finalidad de compartir recursos e intercambiar información y aplicaciones.

2.3.4. Red WAN. Red de Área Extensa (Wide Area Network), son redes capaces de cubrir grandes distancias desde 100 km hasta 1000 km, su función es la interconexión de redes o equipos terminales remotos; un ejemplo es internet.

2.3.5. Red de Área Local Virtual. Una Red de Área Local Virtual, en ingles Virtual Local Area Network – VLAN, es una red de área local que agrupa un conjunto de dispositivos de manera lógica y no física, permite crear redes lógicamente independientes dentro de una misma red física. Varias VLANs pueden coexistir en un único switch físico o red, reducen el tamaño de dominio de difusión y ayudan en la administración de la red separando segmentos lógicos de una red de área local que no deberían intercambiar datos usando la red local.

2.3.6. Servidor. Computador en el cuál se ejecuta uno o varios servicios que cumplen tareas específicas.

2.3.7. Servidor de correo electrónico. Permite el intercambio de mensajes electrónicos entre los usuarios finales, mediante diferentes tipos de redes usando diversos protocolos de red.

2.3.8. Servidor proxy. Servidor intermediario entre programas cliente (navegadores) y servidores de destino, utilizado comúnmente para incrementar el rendimiento de la navegación hacia la red de internet, generalmente un proxy tiene dos tarjetas de red una con dirección IP pública para conectarse a Internet y otra tarjeta de red con IP privada para conectarse a la red LAN.

2.3.9. Servidor web. Un servidor web puede referirse al hardware o software que ayuda a entregar contenido que puede ser accedido a través del internet. Un servidor web hace posible acceder a contenido como páginas web u otro tipo de información como textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música, siempre y cuando el servidor esté conectado al internet. La parte de hardware almacena el contenido mientras el software hace posible que se acceda a la información a través de internet.

2.3.10. Servicios de red. Son los proporcionados por algún servidor, los cuales comúnmente son accedidos por los clientes o usuarios, es una tecnología que facilita el uso de las aplicaciones y recursos. Entre los servicios más comunes se tienen: 

Servicios WEB: apache, IIS.



Servicios DNS: BIND, Windows DNS.



Servicio de correo electrónico: Sendmail, Postfix.



Seguridad y acceso a Internet: Proxy, cortafuegos, accesos remotos (CITRIX, Terminal Services).



Servicios de ficheros (samba, FTP y SFTP): Linux y Windows.



Servicios de WMS: Mapserver.



Servicios de impresión SMB.

II METODOLOGÍA En el desarrollo del proyecto se puede distinguir la investigación y la ejecución, varias fases donde es necesario el proceso de investigación exhaustivo siguiendo un conjunto de métodos y técnicas, con el objetivo de obtener información concreta y vital para el desarrollo del proyecto, información como: la topología de la red, requisitos de monitoreo que debe cumplir la herramienta de monitoreo (tipos de dispositivos, tipos de servicios red); o realizar actividades como: elaboración manuales, pruebas de funcionamiento, comprobar el correcto funcionamiento de la herramienta; la metodología está dedicada a especificar los métodos, estrategias y técnicas seguidas por los investigadores durante el desarrollo del proyecto, realizando un análisis de cada uno de ellos, explicando principalmente en que actividades se las utilizó y exponiendo sus resultados, plasmados en los anexos correspondientes.

3.1. METODOLOGÍA DE INVESTIGACIÓN CUALITATIVA O ESTRUCTURAL. De acuerdo a los resultados planteados y la necesidad de obtener información de la estructura y funcionamiento de la red informática de la Universidad, para estudiar, seleccionar e implantar una herramienta de monitoreo, nuestra investigación se basó en la metodología cualitativa, debido a que las técnica finales que utilizamos en el proceso investigativo, las mismas que detallaremos en líneas posteriores, buscan conocer todas las características de un tema. La metodología cualitativa es una estrategia de investigación, que tiene como objetivo la descripción de las cualidades de un fenómeno pero tomado como un todo, siguiendo la visión holística y global, a través de un planteamiento científico fenomenológico, busca obtener información relacionada a su profundidad, detalles.

3.2. TÉCNICAS DE INVESTIGACIÓN. 3.2.1. Entrevista semiestructurada. Técnica dominante en el proceso investigativo, es un acto de comunicación oral que se establece entre dos o más personas con el fin de obtener una información específica.

Una entrevista no es casual sino que es un diálogo interesado, con un acuerdo previo y unos intereses y expectativas por ambas partes. La entrevista nos permite: recoger información por medio de preguntas abiertas, reflexivas y circulares, las cuales podrán revelar las categorías de interés para la investigación ya que clarifica conductas. Durante el desarrollo del proyecto se realizaron varias entrevistas semiestructuradas y casuales entre los investigadores y las personas que integran la Subárea de Redes y Subárea de Software de la unidad del CITIC de la PUCE SD, ubicados en el edificio Mons. Emilio Lorenzo Stehle del campus de la universidad, dicha unidad tiene como objetivo central promover y consolidar una cultura de investigación y desarrollo tecnológico en la PUCE SD. Se entrevistó a dichas áreas debido a que manejan los servidores de la universidad y por lo tanto los servicios de red que proporcionan, de esta manera y conjuntamente con las técnicas mencionadas en este capítulo se recopiló la información necesaria para registrar la lista de dispositivos a monitorear de la red informática de la PUCE SD (ver anexo 2), y se realizó el levantamiento de información de los documentos esenciales para el desarrollo y cumplimento del proyecto, los mismos que se detallan a continuación: Documento de Levantamiento de Información (ver anexo 5), Documento de requisitos de la Herramienta de Monitoreo Open Source (ver anexo 6), Documento de actualización del levantamiento de información (ver anexo 7).

3.2.2. Requerimiento de información. La técnica de requerimiento de información es una técnica formal, que significa exactamente lo que se entiende de su nombre, pedir o requerir mediante un documento formal, que se entregue información necesaria a la institución, departamento, área, entre otros, aquella que sea poseedora de los ítems buscados en la investigación. Se usa esta técnica cuando la información no es pública, nos referimos a que no es de libre acceso, a veces secreta y clasificada, con esto también se logra documentar formalmente el pedido de información y la respuesta ha dicho pedido. Se utilizó esta técnica debido a que es una política de los administradores de red para mantener la seguridad de la información, considerar confidencial todos los datos relacionados a la infraestructura, topología, dispositivos de red y servidores conectados a la de red informática de la PUCE SD, ya que la universidad utiliza sistemas y servidores

con información sensible, como son los correos electrónicos en el servidor de correo, la información de los sistemas en los servidores de bases de datos, el servidor de página web, entre otros. Además, se eligió realizar un pedido o requerimiento de información, con el fin de que se documente el estado actual de la red, dispositivos, servidores y servicios de red configurados debido a que el proyecto se aplica en un tiempo específico, según la configuración de la red informática de la universidad en el momento de desarrollo de la disertación, la responsabilidad de futuros cambios en la red y la modificación de la configuración en la herramienta de monitoreo corresponde a la unidad del CITIC. La lista de la información requerida (ver anexo 3) inició el proceso investigativo, porque al hacer el pedido, como respuesta se especificó una reunión donde se debatió los ítems del requerimiento con todas las personas relacionadas, llegando a la conclusión que dicha información no estaba documentada, dando paso al uso de las técnicas de entrevista estructurada y observación científica, con el objetivo de obtener la información requerida formalmente.

3.2.3. Análisis de documentos. El análisis consiste en la separación de las partes de un todo a fin de estudiarlas por separado así como examinar las relaciones entre ellas. Con documentos nos referimos a libros, e-books, revistas, artículos, páginas web, blog, videos, o cualquier elemento con capacidad de albergar información. El análisis de documentos se basa en la lectura (textual o visual), que a diferencia de la lectura común debe realizarse siguiendo el método científico, es decir, debe ser sistemática, objetiva, replicable y válida. Esta técnica nos permitió examinar exhaustivamente documentos, que en general fueron e-books, foros de discusión, posts, blogs, revistas y un gran número de artículos de varias páginas web, relacionados al proyecto, dichos documentos se nombran en la parte correspondiente a bibliografía.

3.2.4. Internet. Se ha clasificado como técnica porque actualmente es la forma más común de investigación; los libros, los periódicos, cualquier medio que no sea digital poco a poco se transforman al mundo de ceros y unos, como se puede observar en los e-book (libros enteros en formato *.pdf), libros hablados (libros transformados en multimedia tipo audio), revistas y periódicos, que se transmiten y se publican por internet.

El motor de búsqueda principal en la investigación fue Google, pero también se investigó a través de Yahoo, MSN, Altavista y Ask, todos motores de búsqueda; el browser para acceder a internet fue Mozilla Firefox 3.5.5.

3.2.5. Observación científica. La observación científica significa observar con un objetivo claro, definido y preciso. El investigador sabe qué es lo que desea observar y para qué quiere hacerlo, lo cual implica que debe preparar cuidadosamente la observación. Observar científicamente es definida como el medio para percibir activamente la realidad exterior con el propósito de obtener los datos que han sido definidos de interés para nuestra investigación. La observación científica es considerada un método tipo empírico, puesto que radica en la percepción directa del objeto de la investigación y del problema de la investigación, que para el proyecto es investigar las herramientas open source de monitoreo de red y la ineficiencia y acción reactiva a los problemas relacionados a los servicios y dispositivos de la red de la universidad. Con el fin de obtener la información necesaria para la implementación del servidor de monitoreo y como es una característica propia de la observación científica se definió los ítems a recolectar, los objetivos de interés, para así proseguir al trabajo de campo visitando las instalaciones de la red de la universidad, principalmente fueron: dos cuartos de servidores, oficinas de las áreas del CITIC: redes, software y soporte; los laboratorios de la universidad: el laboratorio general, de software y de hardware; el edificio de los directores de escuela, el edificio donde se ubica la biblioteca y el edificio administrativo, en fin se visitó y recolecto datos de todos los edificios y lugares donde se encuentre instalado algún tipo de dispositivo conectado a la red informática. Toda esta observación científica y apoyándonos en la técnica de la entrevista no estructurada, definida anteriormente, permitió obtener la información detallada de la red plasmada en el documento levantamiento de Información (ver anexo 5) y documento de actualización del levantamiento de información (ver anexo 7), los cuales, entre otros aspectos contienen las normas y parámetros de monitoreo que la herramienta de debe cumplir, como: tipo de servicios de red, tipo de topología red, tipos de dispositivos conectados, entre otros, estatutos esenciales en la etapa de análisis, estudio y selección de la mejor herramienta.

En la etapa de pruebas de funcionamiento de la herramienta de monitoreo se utilizó la técnica de observación científica para comprobar el desempeño de la herramienta ante el curso natural, normal y cotidiano del funcionamiento de la red.

3.2.6. Experimentación científica. Esta técnica se usa cuando es necesario alterar controladamente las condiciones naturales del ambiente a investigar, de tal forma que el investigador crea modelos, reproducirá condiciones, abstraerá rasgos distintivos del objeto o del problema, todo esto con el fin de observar atentamente y recolectar la información del nuevo sistema alterado. La experimentación depende del grado de conocimiento del investigador, a la naturaleza, a las circunstancias del objeto y al problema de investigación, es decir no siempre se podrá realizar experimentos controlados. La etapa pruebas de funcionamiento se basó en la experimentación científica, puesto que se alteró controladamente las condiciones normales del funcionamiento de los servicios de red y estado de los dispositivos conectados a la red, creando un modelo de estados crítico, es decir parando y reiniciando servicios de red, desconectando puntos y dispositivos de la red, apagando dispositivos, entre otros, con lo cual se demostró el funcionamiento eficiente de la herramienta de monitoreo y se creó el documento de Pruebas de funcionamiento de la Herramienta de Monitoreo Open Source Nagios (ver anexo 8).

III RESULTADOS Y DISCUSIÓN 4.1. MATRIZ

SELECCIÓN

MEJOR

HERRAMIENTA

MONITOREO. La matriz final de selección y todos los procesos de evaluación permitió obtener la herramienta de monitoreo de red adecuada a los requerimientos de la red informática de la Universidad, para lo cual se realizó un análisis de requerimientos de la herramienta de monitoreo, dando inicio a la investigación y estudio previo recolectando las herramientas de monitoreo más utilizadas y recomendadas en el proceso de investigación, obtenida la lista de herramientas, se procedió a evaluarlas generando varias matrices, las mismas que exponen los parámetros de evaluación, que son de auditoría propia y el puntaje obtenido por cada herramienta.

4.1.1. Análisis de requerimientos de la herramienta de monitoreo. El análisis de requerimientos se llevó a cabo en base a las entrevistas realizadas al personal que conforma la Subárea de Redes de la unidad del CITIC y de la Subárea de Software de la de la PUCE SD y en base a la observación científica realizada en los dos cuartos de servidores ubicados en el edificio San Liborio y Emilio Lorenzo Estehle. En la actividad de análisis de requerimientos se busca establecer y documentar la situación actual de la red, exponiendo la topología de la red, y definir la lista de dispositivos conectados a la red, para obtener los dispositivos de red, servidores, servicios y recursos que debe monitorear la herramienta. En esta etapa se revisó y se aprobó por la Subárea de Redes del CITIC dos documentos: Documento de Levantamiento de Información (ver anexo 5) y Documento de requisitos de la Herramienta de Monitoreo Open Source (ver anexo 6).

4.1.1.1. Topología de red. Para realizar los diagramas de topología de red, se obtuvo los permisos correspondientes

y el acceso físico hacia los distintos cuartos de servidores, edificios y oficinas de la red informática de la PUCE SD; se procedió a realizar el levantamiento de información para así poder obtener las gráficas de la topología de red. La información presentada de la topología de la red implementada en la PUCE SD, es la necesaria para el desarrollo del proyecto, es decir; no se plasma toda la topología de red existente al momento del levantamiento de información y realización de los diagramas en las distintas locaciones internas, por razones de seguridad de la red. El análisis de la infraestructura de la red dio como resultado los siguientes diagramas:

4.1.1.1.1. Diagrama general de red de la PUCE SD. En este diagrama (ilustración 4) se puede observar cómo se encuentran interconectados los edificios y otras locaciones de manera general, y a su vez como la universidad se comunica con el mundo (Internet) a través de un ISP por medio de la red pública, la universidad de forma interna maneja una red privada, estas redes son administradas por el departamento de redes del CITIC, aclarando que la Red Pública que se origina desde el router denominado ISP hacia internet es responsabilidad del proveedor de servicio de Internet.

Ilustración 4. Diagrama general de red

La leyenda a utilizarse en todos los diagramas de red donde indican la representación de los tipos de dispositivos que se utilizan en la red informática, tipo de conexión, de red y las ubicaciones físicas, se expone a continuación:

Ilustración 5. Leyenda de los diagramas de red

4.1.1.1.2. Topología de red del cuarto de servidores del edificio San Liborio. En la ilustración 6 se aprecia que dentro del edificio San Liborio se encuentra el cuarto de servidores principal de la PUCE SD, el cual además de conectar a toda la red con el ISP hacia internet, contiene en sus servidores los servicios primordiales que brinda para las distintas actividades relacionadas con la comunidad universitaria y todo su personal, como son: página web, proxy, correo electrónico, sistema contable, dominio, entre otros. Se puede observar que la universidad tiene una granja de servidores con IP públicas a los que acceden externamente, el servidor de nombre monitoreo marcado con un círculo representa al servidor a implementarse para el proyecto y se ubica en este segmento de la red porque el acceso al servidor debe ser mediante de la red externa o de internet, ya que la administración del software de monitoreo debe ser vía una interfaz web, los servidores de la red pública que deben ser monitoreados son los siguientes:

Servidor firewall: Servidor ubicado entre la red privada y pública que realiza una inspección del tráfico entrante y saliente para impedir ataques, es decir, prohibir que las conexiones no autorizados accedan a ciertos recursos de la red privada. Servidor de Correo Electrónico: Servidor que tiene implementado el agente de transporte de correo Sendmail, cuya tarea es mover y almacenar el correo electrónico a través de la red privada o pública y a través de internet, encaminando los mensajes de correo para que lleguen a su destino, el uso del servidor de correo es específicamente para la comunidad de usuarios de la PUCE SD. Servidor ROA - Repositorio de Objetos de Aprendizaje: Servidor que almacena objetos de aprendizaje de contenido educativo en formato digital, contribuyendo al desarrollo académico utilizando las nuevas tecnologías de la información y comunicación en la PUCE SD. Servidor de Monitoreo Cacti: Servidor que ejecuta la herramienta de graficado de red Cacti para supervisión de las tarjetas de red de los servidores de la red de la PUCE SD. Servidor de Página Web: Servidor que proporciona disponibilidad a la página web de la PUCE SD: www.pucesd.edu.ec, a través del servidor web open source Apache. Servidor de Monitoreo: En este servidor se implementará la herramienta de monitoreo más óptima para el supervisión de los dispositivo y servicios de red de la PUCE SD. La granja de servidores de la red privada contiene los siguientes servidores a monitorear: Servidor de Producción: Servidor que contiene la base de datos de los diferentes sistemas que utiliza la PUCE SD, implementada a través de Oracle 10g. Servidor de Aplicaciones: Este servidor se encarga de almacenar información en una ubicación centralizada, con la finalidad de que los usuarios de la red interna de la PUCE SD accedan a los archivos del servidor remotamente. Servidor de Dominio: Servidor que implementa un controlador de dominio que administra toda la información correspondiente a usuarios y recursos, almacenando de forma centralizada todas las contraseñas de los usuarios de la red; adicionalmente provee servicio DHCP y DNS a las estaciones de trabajo de la PUCE SD. Servidor Secretarias: Sirve como proxy para un segmento de la red interna.

Servidor Impresión: Servidor que permite conectar las impresoras a la red informática y gestionar los trabajos de impresión de toda la red, permitiendo que todos los usuarios, independientemente de la ubicación física de su estación y del sistema operativo, puedan imprimir en una impresora determinada. Servidor Actualizaciones: Servidor para almacenar las actualizaciones de los equipos que tienen implementado el sistema operativo Windows.

Ilustración 6. Topología de red en el edificio San Liborio.

4.1.1.1.3. Topología de red del cuarto de servidores del edificio Emilio Lorenzo Estehle. La infraestructura Emilio Lorenzo Estehle (ilustración 7) alberga el segundo cuarto de servidores de la universidad, donde se ubica un servidor proxy para el servicio de internet del hogar de los misioneros identes, llamado misioneros, y los servidores donde se

implementa el sistema Thinclient de nombres Micropc. Se puede observar que este edificio sirve de interconexión al Aulario 1 y a las instalaciones de Directores y secretarias de Escuelas donde solo se encuentran estaciones de trabajo.

Ilustración 7. Topología de red en el edificio Emilio Lorenzo Stehle.

4.1.1.1.4. Topología de red del edificio Daponte. Como se puede apreciar en la ilustración 8, la topología de red que contiene es sencilla y tiene como objetivo proveer internet a todos los usuarios de los laboratorios de Software, Hardware y Sala de Computo III, a los cuales el servicio de internet llega por medio de fibra óptica.

Ilustración 8. Topología de red en el edificio Daponte.

4.1.1.1.5. Topología de red del edificio Misereor planta baja. Desde el edificio San Liborio llegan la red privada, que es utilizada dentro de la sala de lectura por medio de un AP Access Point (Punto de Acceso) que permite el uso del servicio de internet de forma inalámbrica (wireless) ya sea a través de estaciones de escritorio (desktop) proporcionadas por la universidad con tarjetas de red compatibles con este tipo de conexión, o dispositivos móviles como pueden ser: laptops, PDAs, celulares, entre otros.

Ilustración 9. Topología de red en el edificio Misereor planta baja.

4.1.1.2. Lista de dispositivos conectados a la red. Para implementar una herramienta de monitoreo óptima se debe tomar en cuenta y registrar todos los tipos de dispositivos de red y servicios que se quieren monitorear, por lo cual se realizaron las entrevistas correspondiente y después de ser aprobado el documento de levantamiento de información por la Subárea de Redes del CITIC (Anexo 5), se tiene la lista oficial de dispositivos conectados a la red informática de la PUCE SD al momento del desarrollo del proyecto y que por razones de seguridad no se publicaron las columnas que muestran la dirección ip, el sistema operativo de los dispositivos o las versiones de las aplicaciones de los dispositivos. De la lista de dispositivos conectados a la red, elaborada a través de investigación y recolección de información de la red informática de la universidad PUCE SD, se obtiene los requisitos de monitoreo que debe cumplir la herramienta, los cuales son los servicios: SQUID, SSH, Oracle, SMB, HTTP, SMTP, mysql, DHCP y DNS; dispositivos de red: AP wireless, impresoras, switchs, routers y cpu; recursos de los servidores y equipos de trabajo: carga del procesador, carga de la memoria RAM, swap o virtual y espacio de disco duro; requerimientos que se resumen en el siguiente cuadro:

SERVICIOS DE RED DISPOSITIVOS DE RED RECURSOS DE LOS SERVIDORES

DHCP

DNS

HTTP

Ap wireless

CPU

Impresora

Carga de la memoria RAM

Mysql

Carga de la memoria virtual

Oracle

SQUID

Switchs

Carga del procesador

Espacio de disco duro

Tráfico de red de enlaces troncales

RECURSOS DE IMPRESORAS

Nivel de tinta

Tráfico de red de la interfaz LAN

SMTP

Router

RECURSOS DE LOS SWITCHS

RECURSOS DE ACCESS POINT

SMB

SSH

Tráfico de red de la interfaz wireless

Cuadro 5. Requerimientos de la herramienta de monitoreo.

4.1.2. Investigación de las herramientas de monitoreo en internet. Valiéndonos del programa Mozilla Firefox versión 3.6.13 y de varios motores de búsqueda como Google, Altavista; se ingresó a varias páginas web como: foros, discusión, posts, noticias, revistas, blogs, entre otros, independientemente del idioma en que estén publicadas, referentes a temas sobre las herramientas de monitoreo de red que se están utilizando actualmente, aquellas con gran número de funciones, de mayor renombre, con alto grado de discusión por sus métodos de instalación y utilización, entre otros, obtenidos los nombres de las herramientas se accedió a sus páginas oficiales y se seleccionó aquellas que en su descripción y requerimientos, cumplan en un principio con las condiciones de ser distribuidas como software open source y que se instalen, ejecuten y operen sobre la distro CentOS 5.5 del Sistema Operativo Linux. De las herramientas sobresalientes, que se acoplen al documento de levantamiento de información, es decir; que funcionen bajo la topología y puedan monitorear los tipos de dispositivos de la red y que cumplen con lo especificado en el documento de requerimientos del software de monitoreo open source acordado con la unidad de redes del CITIC (ver anexo 6), se enumera y registra en orden alfabético la siguiente información: el nombre de la herramienta, el número de su última versión, el tipo de licencia, el url de la página oficial, el encabezado gráfico de su página web oficial, y una breve descripción, aclarando que la información completa y detallada de las mismas se encuentra a lo largo de su portal web oficial. 1. Cacti - Versión 0.8.7g , Url: http://cacti.net/, licencia: General Public License (GPL)

Ilustración 10. Logo de la página web de Cacti

Descripción. Cacti es una completa solución de graficado en red, diseñada para aprovechar el poder de almacenamiento y la funcionalidad de graficar que poseen las RRDtool. Esta herramienta, desarrollada en PHP, provee un pooler ágil, plantillas de gráficos avanzadas, múltiples métodos para la recopilación de datos, y manejo de usuarios. Tiene una interfaz de usuario fácil de usar, que resulta conveniente para instalaciones del tamaño de una LAN, así como también para redes complejas con cientos de dispositivos. 2. Centreon – Versión 2.0.2, Url: http://www.centreon.com/, licencia: General Public License (GPL).

Ilustración 11. Encabezado de la página web de Centreon Descripción. Centreon es el software de monitoreo de mayor flexibilidad y desempeño bajo la licencia GPL. Pensada para todo tipo de usuarios, Centreon cumple con los indicadores de sistemas, redes y aplicaciones. Centreon tiene funciones que son esenciales para el monitoreo de infraestructuras críticas. Siendo modular, puede evolucionar dependiendo de sus necesidades permitiendo esto extender su funcionabilidad. 3. Co-Pilot – Versión 3.5.0, Url: http://oss.sgi.com/projects/pcp/index.html, licencia: GNU Lesser General Public.

Ilustración 12. Encabezado de la página web de Co-Pilot Descripción. Co-Pilot provee un marco de trabajo y servicios para dar soporte al monitoreo y administración del desempeño de diferentes niveles de sistemas. Presenta una abstracción para unificar todos los datos de rendimiento en un sistema, y muchas

herramientas para el filtrado, la recuperación y procesamiento de esos datos. La herramienta Co-Pilot posee características maduras, extensibles, con herramientas de apoyo multi-plataforma, soportando tanto análisis directo como retrospectivo. La arquitectura distribuida de Co-Pilot le hace especialmente útil para aquellos que buscan el seguimiento centralizado de procesamiento distribuido, los servicios ofrecidos son especialmente atractivos para aquellos problemas difíciles de rendimiento. 4. Ganglia – Versión 3.1.7, Url: http://ganglia.info/, licencia: Berkeley Software Distribution (BSD).

Ilustración 13. Encabezado de la página web de Ganglia Descripción. Ganglia es un software que provee monitoreo en tiempo real y ejecución de ambientes, usado por cientos de universidades tanto privadas como gubernamentales. Desarrollada inicialmente en la Universidad de Berkeley por la división de ciencias computacionales como manera de enlazar clúster entre los campus de manera lógica. Ganglia fue desarrollado en un ambiente universitario y es completamente open-source y no tiene componentes adicionales que pertenezcan a propietarios. Todos los datos son intercambiados definidamente por XML y XDR, para un máximo de extensibilidad y portabilidad respectivamente. El monitor core permite monitorear cualquier número de métrica de un host en tiempo real. En el presente el monitor core puede correr bajo sistemas operativos como Linux, FreeBSD, Solaris, AIX, Tru64, y IRIX. 5. JFFNMS – Versión 0.8.5, Url: http://www.jffnms.org/, licencia: General Public License (GPL).

Ilustración 14. Encabezado de la página web de JFFNMS

Descripción. El JFFNMS es un software desarrollado por Javier Szyszlican, en el año 2002, para monitoreo de dispositivos, que integra varias utilidades que interrogan y capturan los datos de los dispositivos. Los programas utilizados por JFFNMS para el monitoreo, son los siguientes: Utiliza programas como nmap, fping y otros para probar conectividad, puertos abiertos y otros parámetros de red. En tal sentido, JFFNMS es un sistema integrador para el monitoreo. JFFNMS requiere de una base de datos robusta para almacenarlos (PostgreSQL ó MySQL), un Servidor Web para presentarlos (Apache), el intérprete PHP bajo el cual se ejecutará JFFNMS, utilidades y programas para generar gráficos (RRDtool, Graphviz, entre otros) JFFNMS se distribuye bajo la licencia GPL. 6. Munin – Versión 1.4.5, Url: http://munin.projects.linpro.no/, licencia: General Public License (GPL).

Ilustración 15. Encabezado de la página web de Munin Descripción. Es una aplicación de monitoreo de redes y sistemas que presenta como salida gráficos en una interfaz web. Se destaca por su simple puesta en marcha. Hay disponible una gran cantidad de plugins de monitoreo. Con la utilización de Munin se puede monitorear fácilmente computadoras, redes, SANs, o cualquier otra aplicación. Permite identificar "que es distinto hoy" cuando un problema de desempeño es detectado. Munin utiliza RRDtool escrito en Perl. Munin trabaja con una arquitectura maestro/nodo. El maestro se conecta a intervalos regulares de tiempo a los nodos para tomar los muestreos y actualizar los gráficos. Crear plugins para Munin no es difícil lo que permite una fácil adaptación a cualquier requerimiento.

7. Nagios - Versión 3.1.3, Url: http://www.nagios.org/, licencia: General Public License (GPL).

Ilustración 16. Encabezado de la página web de Nagios Descripción. Nagios es un sistema open source de monitorización de redes ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no sea el deseado. Entre sus características principales figuran la monitorización de servicios de red, la monitorización de los recursos de sistemas hardware, independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados ó SSH, y la posibilidad de programar plugins específicos para nuevos sistemas. Se trata de un software que proporciona una gran versatilidad para consultar prácticamente cualquier parámetro de interés de un sistema y generar alertas cuando estos parámetros exceden de los márgenes definidos por el administrador de red, que pueden ser recibidas por los responsables correspondientes mediante correo electrónico y mensajes SMS. 8. OpsView – Versión 3.10, Url: http://www.opsview.org/, licencia: General Public License (GPL).

Ilustración 17. Encabezado de la página web de Opsview Descripción. Opsview es una gama de aplicaciones maduras, estables y escalares utilizadas para controlar los sistemas TI vitales empresariales en una amplia gama de organizaciones, como Allianz, Brittany Ferries, Irish Revenue, Plusnet, Winterflood Securities y la

Universidad de Surrey. Opsview es posee código abierto, y está disponible según la licencia de público general GNU. Opsview proporciona un importante ahorro de costes frente a los programas de monitoreo pagadas y proporciona los mismos beneficios empresariales. Opsview proporciona un control centralizado, avanzando frente a la lucha contra los ataques repentinos hasta la planificación futura. El control a largo plazo de las tendencias y niveles de servicio facilita una capacidad más precisa y su realización de presupuestos, ahorrando tiempo y dinero. Opsview proporciona capacidades adicionales como: marco de gráficos de rendimiento, almacenamiento de datos mejorado, rendimiento mejorado, incluyendo recargas más rápidas, integración de la herramienta Nagvis, mejora de la configuración ―lista para su uso‖, entre otros. 9. Osmius -

Versión 9.01, Url: http://www.osmius.net/es/index.php, licencia: General

Public License (GPL).

Ilustración 18. Encabezado de la página web de Opsview Descripción. Osmius es un software open source que permite monitorizar cualquier elemento que esté conectado en red, elementos como equipos de red, routers o switches, hasta instancias de más alto nivel como aplicaciones complejas, temperaturas o producción en una central eléctrica o el valor de las acciones de la compañía. Supervisa sistemas, añade funciones de monitorización, de gestión de alertas, visualización, informes, gestión de infraestructura y auditoría. La herramienta Osmius está compuesta por un servidor central, los agentes maestros y los agentes. Utiliza una arquitectura basada en agentes que monitorizan el entorno de red y envían eventos o alertas que se pueden consultar y gestionar de forma centralizada. Proporciona una visión técnica sobre el dispositivo que tiene problemas, cuenta con diferentes vistas, por ejemplo, vistas técnicas orientadas a eventos.

A las capacidades de robustez y escalabilidad que ofrece Osmius para la monitorización en tiempo real se agrega una interfaz gráfica sencilla e intuitiva, que permite gestionar toda la infraestructura a golpe de clic, mostrando la información en diferentes capas, desde una visión operacional hasta un completo cuadro de mando, pasando por la disposición de los servicios y elementos de manera geográfica apoyándose en una herramienta GIS. El motor de Osmius permite una monitorización no intrusiva (usando ―preguntas‖ remotas como pings, SNMP gets, entre otros) o distribuida mediante agentes, y para el motor de agentes se utiliza el framework ACE en C++ orientado a rendimiento casi en tiempo real, cuyas principales características son: optimización en el rendimiento de ejecución, ejecución en mayor número de sistemas operativos y hardware,

capacidad de

adaptación, entre otros. Otra gran diferencia respecto a otros productos que utilizan scripts en Perl o programas Java; para tamaños medios se comportan bien pero está en entredicho su escalabilidad y el impacto en los servidores y elementos monitorizados. 10. Pandora FMS – Versión

2.1, Url: http://pandorafms.org/, licencia: General Public

License (GPL).

Ilustración 19. Encabezado de la página web de Pandora FMS Descripción. Pandora FMS es un software de Código Abierto que sirve para monitorizar y medir todo tipo de elementos. Monitoriza sistemas, aplicaciones o dispositivos. Permite saber el estado de cada elemento de un sistema a lo largo del tiempo. Pandora FMS puede detectar si una interfaz de red se ha caído, un ataque de defacement en una web, una pérdida de memoria en algún servidor de aplicaciones. Pandora FMS puede recoger información de cualquier sistema operativo, con agentes, específicos para cada plataforma, que recolectan datos y los envía al servidor. Hay agentes específicos para GNU/Linux, AIX, SUN Solaris, HP-UX, BSD/IPSO y Windows 2000, XP y 2003.

Pandora FMS también puede monitorizar cualquier tipo de servicio TCP/IP, sin necesidad de instalar agentes, y monitorizar sistemas de red como balanceadores de carga, routers, switches, sistemas operativos, aplicaciones o impresoras si se necesita hacerlo de forma remota. Pandora FMS también soporta WMI para comunicarse directamente con sistemas windows de forma remota y SNMP para recolectar datos o recibir traps. Algunos ejemplos de recursos comunes que pueden ser monitorizados con Pandora FMS son, la carga del procesador, el uso de disco y memoria, procesos que están corriendo en el sistema, eventos determinados en un log, factores ambientales como la temperatura, la luz o la humedad, valores de aplicaciones como determinados textos en una página web, y en general cualquier cosa que se pueda recolectar de forma automatizada. 11. Zabbix – Versión 1.6.5, Url: http://www.zabbix.com/, licencia: General Public License (GPL).

Ilustración 20. Encabezado de la página web de Zabbix Descripción. ZABBIX es una solución de monitorización 24x7 sin alto costo. Es un software para el monitoreo de aplicaciones, redes y servidores, soporta tanto polling como las técnicas de recolección de datos de monitoreo de hosts. Un flexible mecanismo de notificación permite configurar fácil y rápidamente los diferentes tipos de notificaciones de eventos predefinidos. ZABBIX ofrece funcionalidad que hará que los recursos de TI más transparentes y ayudará a identificar fácilmente los problemas de rendimiento y disponibilidad. Aumenta enormemente la productividad de los administradores de sistemas, proporcionando un sistema de monitoreo fácil de usar. Es una aplicación open source que permite monitorizar servidores vía web. Permite un acceso centralizado a toda la información obtenida de nodos de nuestra red. Encuentra automáticamente, mediante un rango de IPs, servicios y SNMP, y empieza a monitorizarlos automáticamente. Tiene una buena escalabilidad, ha sido testeado contra 5000 servidores y dispositivos. Permite una administración sencilla, guardándose los

datos en BD (Oracle, MySQL, PostgreSQL o SQLite). Monitorización en tiempo real, mandando avisos mediante email, SMS o Jabber. 12. Zenoss Core – Versión 2.4, Url: http://www.zenoss.com/, licencia: General Public License (GPL).

Ilustración 21. Encabezado de la página web de Zenoss Descripción. Zenoss es una aplicación de código abierto, servidor y es una plataforma de administración de red basada en la aplicación servidor Zope. Es liberado bajo la licencia GNU General Public License (GPL) versión 2. Zenoss Core proporciona una interfaz web que permite a los administradores de sistemas controlar la disponibilidad, inventario, configuración, rendimiento y eventos. En la actualidad, es el proyecto de administración más popular en sourceforge.net, su código fuente está disponible para descargas gratuitas. Los actuales foros de la comunidad Zenoss tienen más de 50.000 miembros registrados que se ayudan mutuamente en la instalación, configuración y solución de problemas sobre Zenoss Core. La comunidad también comparte ideas entre sí sobre las mejores prácticas de administración del gobierno de las tecnologías de la información. La herramienta Zenoss contiene una arquitectura abierta con APIs para integrarse a productos de terceros (ya sea traer datos en Zenoss o exportar datos Zenoss a otros productos), ofrece monitoreo de red, servidores, aplicaciones y de cualquier dispositivo activo SNMP en un solo producto, envía alertas en tiempo real cuando se produzcan interrupciones o demoras. Todas las capacidades que ofrece Zennos se visualizan en una consola única de eventos, que contiene alertas y registro de eventos.

4.1.3. Evaluación de las herramientas de monitoreo. 4.1.3.1. Eliminación preliminar de las herramientas de monitoreo. Se realizó una preselección de las herramientas de monitoreo antes de realizar el proceso de evaluación, con la finalidad de seleccionar y evaluar solo las herramientas más óptimas, la preselección se basa en el nivel de desarrollo en áreas específicas de las

herramientas, cada calificación fue asignada por los desarrolladores del proyecto y se basa en la información de cada página oficial y de la comunidad de la herramienta, las calificaciones se realizan por los niveles: ninguno, bajo, medio, alto. A continuación se detalla cada columna del cuadro de preselección: Herramienta de monitoreo: Nombre de la herramienta. Nivel de comunidad: El nivel de aporte y participación de la comunidad de usuarios que tiene la herramienta, la comunidad es un aspecto importante cuando se habla de herramientas open source. Nivel de documentación: Que nivel de información de su comunidad o de la página oficial se encuentra sobre la herramienta de monitoreo open source, referente a su instalación, configuración, personalización y soporte técnico. Nivel de madurez: Etapa en la que se encuentra el desarrollo de la herramienta, es decir el nivel de la versión de la herramienta, el nivel de utilización por la comunidad de usuarios. Envío de notificaciones: Nivel de desarrollo de la herramienta referente al envío de notificaciones de alerta a los administradores en caso de un evento crítico de la red informática supervisada. Monitoreo de servicios de red: Nivel de desarrollo de la herramienta referente a la supervisión y monitoreo de los servicios de red. Monitoreo de Dispositivos: Nivel de desarrollo de la herramienta referente al monitoreo de los dispositivos de red y sus recursos. Totales: Es un promedio de los niveles, primero se asignó un valor a los niveles según: ninguno es 0, bajo es 1, medio es 2, alto es 3; se obtiene un promedio de los valores reemplazados y se convierte el resultado a niveles utilizando la siguiente escala: 0 a 0.4 es ninguno, de 0.5 a 1.4 es bajo, de 1.5 a 2.4 es medio y mayor de 2.4 es alto.

HERRAMIENTA

CACTI CENTREON CO - PILOT GANGLIA JFFNMS MUNIN NAGIOS OPSVIEW OSMIUS PANDORA FMS ZABBIX ZENOSS

NIVEL DE COMUNIDAD

NIVEL DE DOCUMENTACIÓN

NIVEL DE MADUREZ

ENVÍO DE NOTIFICACIONES

MONITOREO DE SERVICIOS DE RED

MONITOREO DE DISPOSITIVOS

TOTALES

MEDIO BAJO BAJO MEDIO MEDIO BAJO ALTO BAJO MEDIO

MEDIO MEDIO BAJO MEDIO BAJO BAJO ALTO MEDIO MEDIO

ALTO MEDIO BAJO MEDIO BAJO BAJO ALTO MEDIO MEDIO

NINGUNO ALTO BAJO BAJO MEDIO NINGUNO ALTO ALTO ALTO

NINGUNO ALTO NINGUNO BAJO MEDIO BAJO ALTO ALTO NINGUNO

MEDIO ALTO MEDIO ALTO MEDIO BAJO ALTO ALTO ALTO

MEDIO MEDIO BAJO MEDIO MEDIO BAJO ALTO MEDIO MEDIO

ALTO ALTO ALTO

Cuadro 6. Preselección de las herramientas de monitoreo open source. Las herramientas de monitoreo de más alta especialización en el monitoreo de dispositivos y servicios de red fueron: Nagios, Pandora FMS, Zabbix y Zenoss, por lo cual estas herramientas serán evaluadas y contrastadas detalladamente para obtener la herramienta a implementar en la red informática de la PUCE SD. Las demás herramientas eliminadas se detallan a continuación: 1. Cacti. Cacti no es una herramienta orientada al monitoreo y envío de alarmas, es una solución de graficado en red cuya gran funcionalidad radica en el almacenamiento histórico de los datos que recolecta, su ágil acceso y despliegue de información al momento de consultar los mismos; es altamente recomendado el uso de esta herramienta con una de monitoreo, ya que por medio de los datos almacenados por Cacti podríamos llegar a determinar las causas del problema del cual alertó la herramienta NMS. 2. Centreon. Centreon es un programa basado en web, el cual simplemente permite la configuración de Nagios a través de una interfaz web, a esto se añade la poca información que se puede encontrar; se pudo también observar que la mayoría de su comunidad es francesa y esto deriva en una dificultad del soporte y el aporte de esta misma comunidad, por ejemplo en los foros de Centreon se puede observar la mezcla entre francés e inglés; dicho esto se llega a la conclusión de que no es una herramienta de monitoreo como tal, sino más bien se la podría considerar como front end de Nagios cuyo objetivo es simplificar la configuración del mismo.

3. Co-Pilot y Munin. Tanto el programa Co-Pilot y Munin tienen los mismos inconvenientes, son de un proyecto que está en inicios, es decir el nivel de madurez de las herramientas es muy baja comparadas a las demás, aunque permita el monitoreo de redes, necesita de modificaciones, mejoras y no existe datos en la web sobre discusiones de instalación o configuración, por último la página web oficial es muy pobre y poca informativa, la principal razón de la eliminación de este programa es la falta total de información en internet sobre la misma y por poseer herramientas muy limitadas de análisis. 4. Ganglia. Ganglia es una herramienta orientada específicamente al monitorio de los recursos utilizados de los computadores y no permite monitorear los servicios de red, objetivo principal de nuestro proyecto. Por lo expuesto Ganglia no se perfila como candidato para por enfocarse mayormente a la utilización del protocolo SNMP, y descuidando los otros aspectos necesarios para cumplir nuestro objetivo. 5. JFFNMS. La herramienta JFFNMS desarrollado por una sola persona, cuya última versión estable menor a 1.0, presenta una configuración compleja, dificultad inicial en el proceso de adaptación a GNU/Linux y escasez de documentación. 6. Opsview. Opsview es un conjunto de paquetes integrados para funcionar como una sola herramienta, OpsView usa el motor de monitoreo de Nagios e incorpora Nagvis (se lo encuentra como un addon en el sitio web de Nagios exchance) como su interfaz web, NagiosGraph, MRTG y net-snmp; en conclusión es una configuración de Nagios personalizada y por lo tanto no se la podría considerar como una herramienta de monitoreo por si misma ya que depende directamente de Nagios. 7. Osmius. Si bien la herramienta Osmius tiene por objeto la monitorización de sistemas informáticos a fin de mantener un férreo control y supervisión de todo lo que se conecte a una red, se encuentran dos problemas radicales al respecto. Primero, su principal característica se encuentra en el monitoreo de domótica, ya que está pensado para un control de sensores

como presión, temperatura, paneles solares, válvulas, entre otros; por lo que no se ajusta a nuestro objetivo de monitorear los servicios y recursos de red. Segunda, según la página oficial de Osmius recién ―ha superado con éxito la fase preliminar de análisis y la definición de la arquitectura de todo el sistema‖, actualmente se encuentra en fase de desarrollo y pruebas, demostrando que no está listo para un uso serio. Por lo expuesto queda eliminado del proceso de comparación.

4.1.3.2. Comparación y evaluación de las herramientas de monitoreo. El proceso de evaluación de las herramientas de monitoreo se realizó utilizando el software de virtualización de recursos VMware Server Versión 2.0.1,

de distribución

gratuita para evaluación e investigación, el cual permite crear máquinas o equipos virtuales; se utilizó VMware como medio para la evaluación porque la mayoría de las herramientas ofrecen una máquina virtual de prueba creada en VMware, descargable desde sus páginas oficiales, donde por defecto viene instalado el sistema operativo y la última versión de la herramienta. Con la finalidad de evaluar y calificar las herramientas se creó una máquina virtual con los siguientes requerimientos: dos procesadores de 2.4 GHZ, 1000 MB de memoria, 8GB de disco duro, una tarjeta de red, un DVD drive y un controlador USB, ya que son los requerimientos recomendados por los manuales oficiales de instalación para el óptimo funcionamiento de las herramientas de monitoreo. En la máquina virtual se instaló el sistema operativo CentOS 5.5 y utilizando la particularidad de que se puede copiar la máquina virtual sin alterar sus características, la misma fue copiada las veces necesarias para evaluar todas las herramientas de monitoreo, una máquina virtual para cada herramienta, con este proceso, se obtuvo las mismas condiciones físicas para evaluarlas, se procedió a instalar y configurar cada herramienta usando el mismo ancho de banda de conexión a internet. Para la comparación y evaluación de las herramientas de monitoreo, se tomó en cuenta tres particularidades esenciales, que son el proceso de instalación, el proceso de configuración y las características generales de las herramientas de monitoreo, estos aspectos de evaluación son de autoría de los desarrolladores del proyecto, cada aspecto es evaluado por separado y tiene asignado un peso, el peso representa el porcentaje de relevancia en la calificación final. El puntaje final de cada herramienta representado por la fila Calificación Final, puede ser apreciado en el siguiente cuadro:

Parámetros de Evaluación Proceso de Instalación Proceso de Configuración Características Generales Calificación Final

Pesos 15% 55% 35% 100%

Cuadro 7. Porcentajes de la evaluación final. Los parámetros de evaluación se calificaron sobre cien por ciento individualmente, utilizando la estructura de evaluación detallada a continuación:

4.1.3.2.1. Estructura de evaluación. Se elaboraron dos cuadros, el primero denominado Cuadro de Valoración, el cual contiene tres secciones: los pesos, parámetros y valoración de las herramientas.

PESOS

PARÁMETROS

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Cuadro 8. Ejemplo del cuadro de valoración. La primera columna contiene a los pesos de los parámetros que representan el porcentaje de relevancia del conjunto de parámetros a ser evaluados y fueron asignados por los investigadores de acuerdo a su grado de importancia según su experiencia. La segunda sección representada por la segunda columna contiene a los parámetros que se valoraron, los mismos que fueron obtenidos a base de estudios de las características generales y los procesos de instalación y configuración de las herramientas de monitoreo. Las columnas de la tercera sección contienen el valor asignado al parámetro por cada herramienta de monitoreo, esta calificación es asignada por los desarrolladores y se basa en su experiencia con las herramientas. El segundo cuadro de nombre Cuadro de Evaluación contiene dos secciones, la primera conformada por los parámetros evaluados, que son los mismos del cuadro de Valoración y la segunda sección expone la evaluación porcentual obtenida aplicando distintos procesos de evaluación, la fila evaluación representa la calificación final de cada la herramienta.

PARÁMETROS

NAGIOS

EVALUACIÓN PORCENTUAL PANDORA FMS ZABBIX

ZENOSS

EVALUACIÓN TOTAL: Cuadro 9. Ejemplo del cuadro de evaluación.

4.1.3.2.2. Métodos de los procesos de evaluación. 4.1.3.2.2.1. Regla de tres simple. La regla de tres simple es un método para hallar una cantidad que forma una proporción con otras cantidades conocidas de dos o más magnitudes directamente proporcionales, dos magnitudes son directamente proporcionales cuando al aumentar una cantidad aumenta la otra, por ejemplo:

A más A menos

más. menos.

Por ejemplo: ¿Si 2 impresoras imprimen conjuntamente 20 hojas por minuto, cuántas impresoras se necesitan para imprimir 60 hojas por minuto? Relación: 20 es a 2 como 60 es a X, Desarrollo:

20  2 60  x X= 6 impresoras

4.1.3.2.3. Regla de tres inversa. La regla de tres inversa es un método para hallar una cantidad que forma proporción con otras cantidades conocidas de dos o más magnitudes inversamente proporcionales, dos magnitudes son inversamente proporcionales cuando al aumentar una cantidad disminuye la otra, por ejemplo:

A más A menos

menos. más.

Por ejemplo: ¿Si 2 procesadores virtuales se demoran 30 segundos en iniciar el sistema operativo windows 7, cuando demorarían 4 procesadores virtuales? 2  30 Relación: 2 es a 30 como 4 es a X, 4  x Desarrollo:

x= 15 segundos

4.1.3.2.3.1. Relación condicional. Es la asignación de un valor de acuerdo al cumplimiento de una condición previamente establecida, se utiliza cuando no se puede dar un valor numérico a un parámetro, existen casos en los que simplemente debe cumplir o no una condición. Ejemplo: ¿La herramienta de monitoreo tiene la capacidad de almacenar datos? La respuesta es sí o no, ya que no se puede asignar un valor numérico, cuando la respuesta es sí se le asigna el valor del peso, el peso de este parámetro es 7, entonces en el cuadro de evaluación el valor será de 7, si en un supuesto no cumple con la característica de almacenar datos el valor seria de 0.

4.1.3.2.4. Proceso de instalación. Se instaló por consola cada una de las herramientas siguiendo el manual oficial y la información proporcionada por su comunidad, a partir de esta instalación se seleccionaron parámetros esenciales para evaluar este proceso, se les asignó un rango de valores y se determinó en el apartado Evaluación un método de evaluación, el método especifica la fórmula y los valores que se utilizaron para calcular las cantidades del Cuadro de Evaluación, a continuación se detalla cada aspecto de los parámetros:

1.1. Manual de Instalación: Calificación de los investigadores al manual oficial de instalación de la herramienta, considerando los siguientes aspectos: estructura organizacional del manual, sencillez, claridad y la guía detallada de la instalación. 1.2. Rango de Valores: 0 a 10. 1.3. Evaluación: Regla de tres simple, relación: 10 es a 25% como valoración es a X, donde 10 representa el puntaje máximo, 25% es el peso asignado al parámetro y valoración es la calificación del parámetro. 1.1. Aporte de la comunidad: Calificación de los investigadores al aporte de la comunidad sobre el proceso de instalación, ya que para una herramienta open source el apoyo y aporte de la comunidad es una característica de vital importancia. 1.2. Rango de Valores: 0 a 10. 1.3. Evaluación: Regla de tres simple, relación: 10 es a 25% como valoración es a X, donde 10 representa el puntaje máximo, 25% es el peso asignado al parámetro y valoración es la calificación del parámetro.

3.1. Facilidad de Instalación: Calificación de los investigadores al grado de facilidad de todo el proceso de instalación de la herramienta, a menos complejidad más puntaje. 3.2. Rango de Valores: 0 a 10. 3.3. Evaluación: Regla de tres simple, relación: 10 es a 20% como valoración es a X, donde 10 representa el puntaje máximo, 20 es el peso asignado al parámetro y valoración es la calificación del parámetro.

4.1. Dependencia de paquetes: Número de paquetes que depende la herramienta de monitoreo para su correcto funcionamiento, los paquetes se instalan y resuelven dependencia antes de la instalación de la herramienta, se evalúa este parámetro porque determina si la herramienta puede subsistir por sí sola.

4.2. Rango de Valores: El rango fue determinado por el número de paquetes instalados para cada herramienta; el valor mínimo del número de paquetes entre las cuatro herramientas, fue determinado por la fórmula de Excel MIN(número1;[número2];….)4. 4.3. Evaluación: Regla de tres inversa, relación: mínimo es a 10% como valoración es a X, donde mínimo representa el mejor puntaje, 10% es el peso asignado al parámetro y valoración es el número de paquetes.

5.1. Comandos de Instalación y Configuración: Número de líneas de comandos que se deben ejecutar para instalar la herramienta, después de instalar los paquetes dependientes, más el número de líneas de comando para configurar correctamente al servidor. 5.2. Rango de Valores: El rango lo determina el número de comandos de cada herramienta, donde mínimo es el resultado de aplicar la fórmula de Excel MIN(número1;[número2];….). 5.3. Evaluación: Regla de tres inversa, relación mínimo es a 15% como valoración es a X, donde mínimo representa el mejor puntaje, 15% es el peso asignado al parámetro y valoración es el número de comandos. 6.1. Tiempo de Instalación: Tiempo en minutos que dura la instalación de la herramienta de monitoreo mediante consola. 6.2. Rango de Valores: El rango lo determina el tiempo de instalación de cada herramienta, el mínimo tiempo lo determina la fórmula de Excel. 6.3. Evaluación: Regla de tres inversa, relación: mínimo es a 5% como valoración es a X, donde mínimo representa el mejor puntaje, 5% es el peso asignado al parámetro y valoración es el número de minutos de la instalación. Terminado el proceso de instalación de las herramientas de monitoreo, calificando cada parámetro de evaluación expuesto en líneas anteriores, se obtuvo el Cuadro de Valoración y consecuentemente el Cuadro de Evaluación, dichos cuadros se exponen a continuación:

La fórmula devuelve el valor mínimo de una lista de valores. Omite los valores lógicos y el texto.

PESOS

PARÁMETROS

25% 25% 20% 10%

MANUAL DE INSTALACIÓN APORTE DE LA COMUNIDAD FACILIDAD DE INSTALACIÓN DEPENDENCIA DE PAQUETES COMANDOS DE INSTALACIÓN 15% Y CONFIGURACIÓN 5% TIEMPO DE INSTALACIÓN 100,00%

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS PANDORA FMS ZABBIX ZENOSS 9 8 8 9 9 6 8 8 9 6 8 10 4 6 13 6 19 7

33 11

58 10

7 8

Cuadro 10. Valoración del proceso de instalación.

PARÁMETROS MANUAL DE INSTALACIÓN APORTE DE COMUNIDAD FACILIDAD DE INSTALACIÓN DEPENDENCIA DE PAQUETES COMANDOS DE INSTALACIÓN Y CONFIGURACIÓN TIEMPO DE INSTALACIÓN EVALUACIÓN TOTAL:

NAGIOS 22,50% 22,50% 18,00% 10,00% 5,53% 5,00% 83,53%

EVALUACIÓN PORCENTUAL PANDORA FMS ZABBIX 20,00% 20,00% 15,00% 20,00% 12,00% 16,00% 6,67% 3,08% 3,18% 1,81% 3,18% 3,50% 60,03% 64,39%

ZENOSS 22,50% 20,00% 20,00% 6,67% 15,00% 4,38% 88,54%

Cuadro 11. Evaluación del proceso de instalación. A partir del Cuadro de Evaluación se obtuvieron dos gráficas estadísticas tipo columna, el primer gráfico expone todos los parámetros y sus valores (ver ilustración 22), el segundo únicamente visualiza la evaluación total, es decir, la sumatoria de los parámetros (ver ilustración 23).

Evaluación de parámetros del Proceso de Instalación 25,00%

20,00%

15,00%

10,00%

5,00%

0,00% MANUAL DE INSTALACIÓN

APORTE DE COMUNIDAD

FACILIDAD DE INSTALACIÓN

DEPENDENCIA DE PAQUETES

NAGIOS

PANDORA FMS

ZABBIX

COMANDOS DE INSTALACIÓN Y CONFIGURACIÓN

TIEMPO DE INSTALACIÓN

ZENOSS

Ilustración 22. Gráfico estadístico del cuadro de evaluación del proceso de instalación.

Evaluación total del Proceso de Instalación

90,00%

88,54%

83,53%

80,00%

60,03%

70,00%

64,39%

60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Ilustración 23. Gráfico estadístico de la evaluación total del proceso de instalación. Como se puede apreciar la herramienta de monitoreo Zenoss obtuvo el mejor puntaje de evaluación para el Proceso de Instalación con 88,54% y la herramienta Pandora FMS obtuvo la puntuación más baja con 60,03%.

4.1.3.2.5. Proceso de configuración. Para evaluar al proceso de configuración de las herramientas de monitoreo se procedió a realizar las configuraciones necesarias para que monitoreen una infraestructura de red LAN de prueba, con los siguientes dispositivos, recursos y servicios: Dispositivos. 1. Servidor funcionando con el sistema operativo Windows 2003 server. 2. Servidor funcionando con el sistema operativo CentOS 5.5. 3. Estación de trabajo con el sistema Operativo Windows XP. 4. Router. 5. Ap Wireless. Recursos. 1. Carga del procesador. 2. Carga de la memoria RAM. 3. Carga de la memoria swap o virtual. 4. Espacio de disco duro. Servicios. 1. Paquete Squid, que proporciona el servicio proxy. 2. Programa Apache que proporciona el servicio http. 3. Servicio DNS y DHCP proporcionados por el sistema operativo Windows 2003 Server. 4. Servicio SSH. Configurados los dispositivos se elaboraron los cuadros de Valoración y Evaluación, el apartado de evaluación especifica el método de cada parámetro, donde consta la fórmula

y los valores que se utilizaron para calcular las cantidades del Cuadro de Evaluación, estos cuadros contienen los siguientes parámetros: 1.1. Manual de Configuración: Calificación de los investigadores a los capítulos dedicados a la configuración del monitoreo de los dispositivos del manual oficial de la herramienta, considerandos los siguientes aspectos: estructura organizacional, sencillez, claridad y la guía detallada de la configuración.

1.2. Rango de Valores: 0 a 10 1.3. Evaluación: Regla de tres simple, relación: 10 es a 30% como valoración es a X, donde 10 representa el puntaje máximo, 30% es el peso asignado al parámetro y valoración es la calificación del parámetro.

2.1. Facilidad de Configuración: Calificación de los investigadores al grado de facilidad al proceso de configuración del monitoreo de dispositivos de cada herramienta, a menos complejidad más puntaje. 2.2. Rango de Valores: 0 a 10. 2.3. Evaluación: Regla de tres simple, relación: 10 es a 40% como valoración es a X, donde 10 representa el puntaje máximo, 40% es el peso asignado al parámetro y valoración es la calificación del parámetro.

3.1. Aporte de la comunidad: Calificación de los investigadores al aporte de la comunidad sobre el proceso de configuración del monitoreo de dispositivos. 3.2. Rango de Valores: 0 a 10. 3.3. Evaluación: Regla de tres simple, relación: 10 es a 30% como valoración es a X, donde 10 representa el puntaje máximo, 30% es el peso asignado al parámetro y valoración es la calificación del parámetro. Concluido el proceso de configuración del monitoreo de los dispositivos, recursos y servicios, calificando el conjunto de parámetros de evaluación expuesto en líneas

anteriores se obtuvo el Cuadro de Valoración y consecuentemente el Cuadro de Evaluación, dichos cuadros y sus respectivas gráficas se exponen a continuación:

PESOS

PARÁMETROS

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS PANDORA FMS ZABBIX ZENOSS 9 8 8 9 9 6 8 9 9,5 5 8 8

30% MANUAL DE CONFIGURACIÓN 40% FACILIDAD DE CONFIGURACIÓN 30% APORTE DE COMUNIDAD 100% Cuadro 12. Valoración de la configuración de monitoreo. PARÁMETROS MANUAL DE INSTALACIÓN FACILIDAD DE INSTALACIÓN APORTE DE COMUNIDAD EVALUACIÓN:

EVALUACIÓN PORCENTUAL NAGIOS PANDORA FMS ZABBIX ZENOSS 27,00% 24,00% 24,00% 27,00% 36,00% 24,00% 32,00% 36,00% 28,50% 15,00% 24,00% 24,00% 91,50% 63,00% 80,00% 87,00%

Cuadro 13. Evaluación de la configuración de monitoreo.

A partir del Cuadro de Evaluación se obtuvieron dos gráficas estadísticas tipo columna, el primer gráfico expone todos los parámetros y sus valores (ver ilustración 24), el segundo únicamente visualiza la evaluación total, es decir, la sumatoria de los parámetros (ver ilustración 25). Evaluación de parámetros del Proceso de Configuración 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% MANUAL DE INSTALACIÓN NAGIOS

FACILIDAD DE INSTALACIÓN PANDORA FMS

ZABBIX

APORTE DE COMUNIDAD

ZENOSS

Ilustración 24. Gráfica de la evaluación de parámetros del proceso de configuración.

Evaluación total del proceso de configuración

100,00% 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00%

91,50% 80,00%

87,00%

63,00%

NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Ilustración 25. Gráfica de la evaluación total del proceso de configuración. Como se puede apreciar la herramienta de monitoreo Nagios obtuvo el mejor puntaje de evaluación en el proceso de Configuración con 91,50% y la herramienta Pandora FMS obtuvo la puntuación más baja con 63,00%.

4.1.3.2.6. Características generales. En este apartado se evaluaron las características importantes y necesarias de las herramientas de monitoreo para que ejecuten un óptimo desempeño de monitoreo dentro de la Infraestructura de red de la PUCE SD, los parámetros evaluados tienen la misma estructura que los Procesos de Instalación y Configuración, en la mayoría de parámetros se utilizó el método de relación condicional debido a que no se puede dar un valor al parámetro, cada parámetro se define a continuación: 1.1. Almacenamiento de Datos: Capacidad de la herramienta para almacenar datos relacionados a la actividad de monitoreo, por ejemplo: rendimiento, disponibilidad, entre otros. La información de monitoreo específica depende de la herramienta y su configuración. 1.2. Rango de Valores: Si o No. 1.3. Evaluación: Relación condicional, Si representa 7% y No el 0%, donde 7% es el valor del peso, Si o No es la valoración del parámetro.

2.1. Aplicación web: Calificación de los investigadores a la facilidad de manejo, del panel de control vía web denominada aplicación web. 2.2. Rango de Valores: 0 a 10. 2.3. Evaluación: Regla de tres simple, relación: 10 es a 5% como valoración es a X, donde 10 representa el puntaje máximo, 5% es el peso asignado al parámetro y valoración es la calificación del parámetro.

3.1. Soporte y creación de plugins: Capacidad de la herramienta para integrar plugins en su funcionamiento de monitoreo, facilidad de escribir y personalizar nuevos complementos, los mismos extienden las capacidades de las herramientas. 3.2. Rango de Valores: SI o No. 3.3. Evaluación: Relación condicional, Si representa 8 y No el 0, donde 8 es el valor del peso, Si o No es la valoración del parámetro. 4.1. Número de complementos ya creados: Esta característica representa el número de complementos oficiales creados y en uso de cada herramienta. 4.2. Rango de Valores: El rango lo determina el número de complementos publicados en la página web de cada herramienta, el valor máximo fue determinado por la fórmula de Excel MAX(número1;[número2];….)5. 4.3. Evaluación: Regla de tres simple, relación: máximo es a 7% como valoración es a X, donde máximo representa el mejor puntaje, 7% es el peso asignado al parámetro y valoración es la calificación del parámetro.

5.1. Gráficas y estadísticas: Capacidad de las herramienta para generar informes o representaciones gráficas que permite vigilar tendencias históricas de disponibilidad, de tráfico, parámetros de rendimiento, entre otros; y la creación de estadísticas a partir de los datos de monitoreo almacenados. 5.2. Rango de Valores: SI o No. 5

La fórmula devuelve el valor máximo de una lista de valores. Omite los valores lógicos y el texto.

5.3. Evaluaciรณn: Relaciรณn condicional, Si representa 7 y No el 0, donde 7 es el valor del peso y Si o No es la valoraciรณn del parรกmetro.

6.1. Madurez: Calificaciรณn de los investigadores al nivel en que la herramienta ha sido probada y desarrollada, con menor cantidad posible de fallos o bugs, caracterรญstica de vital importancia en programas open source. 6.2. Rango de Valores: 0 a 10. 6.3. Evaluaciรณn: Regla de tres simple, relaciรณn: 10 es a 15% como valoraciรณn es a X, donde 10 representa el puntaje mรกximo, 15% es el peso asignado al parรกmetro y valoraciรณn es la calificaciรณn del parรกmetro.

7.1. Manejador de Eventos: Capacidad de la herramienta para ejecutar un conjunto de comandos (archivo tipo scripts o ejecutables) local o remotamente, dicha caracterรญstica se utiliza para la resoluciรณn automรกtica de problemas de red, por ejemplo si un servicio falla remotamente la herramienta lo manda a reiniciar. 7.2. Rango de Valores: SI o No. 7.3. Evaluaciรณn: Relaciรณn condicional, Si representa 6 y No el 0, donde 6 es el valor del peso y Si o No es la valoraciรณn del parรกmetro.

8.1. Monitorizaciรณn Distribuida: Capacidad de las herramientas para implementar varios sistemas de monitoreo en diferentes servidores, actuando uno como central y los demรกs llamados distribuidos. 8.2. Rango de Valores: SI o No. 8.3. Evaluaciรณn: Relaciรณn condicional, Si representa 6 y No el 0, donde 6 es el valor del peso y Si o No es la valoraciรณn del parรกmetro.

9.1. Reportes: Capacidad de generar reportes a base de los datos de monitoreo.

9.2. Rango de Valores: SI o No. 9.3. Evaluación: Relación condicional, Si representa 4 y No el 0, donde 4 es el valor del peso y Si o No es la valoración del parámetro.

10.1. Seguridad: Calificación de los investigadores para evaluar las características de seguridad de las herramientas, como implementación de rol de usuarios, autenticación de ingreso e uso de https, entre otros, cada característica depende de la herramienta de monitoreo y su configuración, también se tomó en cuenta el informe de vulnerabilidades generado por la herramienta Nessus, versión 4.4.1. 10.2. Rango de Valores: 0 a 10. 10.3. Evaluación: Regla de tres simple, relación: 10 es a 15% como valoración es a X, donde 10 representa el puntaje máximo, 15% es el peso asignado al parámetro y valoración es la calificación del parámetro. 11.1. Soporte de la Comunidad: Calificación de los investigadores para evaluar a la comunidad activa de la herramienta de monitoreo, como información en internet, videos, tutoriales, aportes de plugins y foros de ayuda, es decir, toda la información de la comunidad que se puede encontrar a través de internet. 11.2. Rango de Valores: 0 a 10. 11.3. Evaluación: Regla de tres simple, relación: 10 es a 12% como valoración es a X, donde 10 representa el puntaje máximo, 12% es el peso asignado al parámetro y valoración es la calificación del parámetro. 12.1. Soporte SNMP: Capacidad de las herramientas para implementar el monitoreo usando el protocolo SNMP. 12.2. Rango de Valores: Si o No. 12.3. Evaluación: Relación condicional, Si representa 7 y No el 0, donde 7 es el valor del peso y Si o No es la valoración del parámetro.

13.1. Uso de Agentes: Capacidad de las herramientas para implementar el monitoreo

usando agentes externos, se llaman agentes a los programas instalados en los equipos a ser monitoreados cuya función es de recolectar información de funcionamiento. 13.2. Rango de Valores: Si o No. 13.3. Evaluación: Relación condicional, Si representa 4 y No el 0, donde 4 es el valor del peso y Si o No es la valoración del parámetro. La calificación de los investigadores a los parámetros antes registrados se resumen en dos cuadros de Valoración y un cuadro de Evaluación, por motivos de que en el primer cuadro de valoración se valora cualitativamente (si o no) y en el segundo cuadro de Valoración se valora cuantitativamente y utilizando los dos cuadros anteriormente explicados se obtiene el cuadro de Evaluación de las características generales.

PESOS 7% 8% 7% 6% 6% 4% 7% 4%

PARÁMETROS Almacenamiento de datos Soporte y creación de plugins Gráficas y estadísticas Manejador de Eventos Monitorización distribuida Reportes Soporte SNMP Uso de agentes

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

SI SI SI SI SI SI SI SI

Cuadro 14. Valoración de las características generales por si o no PESOS

PARÁMETROS

5% 7% 15% 12% 12%

Aplicación web Numero de complementos ya creados Madurez Seguridad Soporte de la comunidad

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

8 1689 9 9 9

5 63 8 9 7

8 31 7 9 8

9 262 8 9 9

Cuadro 15. Valoración de las características generales por rango de dígitos.

EVALUACIÓN PORCENTUAL

PARÁMETROS Almacenamiento de datos Aplicación web Soporte y creación de complementos (plugins) Número de complementos ya creados Gráficas y estadísticas Madurez Manejador de Eventos Monitorización distribuida Reportes Seguridad Soporte de la comunidad Soporte SNMP Uso de agentes EVALUACIÓN

NAGIOS PANDORA FMS

ZABBIX

ZENOSS

7,00% 4,00% 8,00% 7,00% 7,00% 13,50% 6,00% 6,00% 4,00% 10,80% 10,80% 7,00% 4,00% 95,10%

7,00% 4,00% 8,00% 0,13% 7,00% 10,50% 6,00% 6,00% 4,00% 10,80% 9,60% 7,00% 4,00% 84,03%

7,00% 4,50% 8,00% 1,09% 7,00% 12,00% 6,00% 6,00% 4,00% 10,80% 10,80% 7,00% 4,00% 88,19%

7,00% 2,50% 8,00% 0,26% 7,00% 12,00% 6,00% 6,00% 4,00% 10,80% 8,40% 7,00% 4,00% 82,96%

Cuadro 16. Evaluación de las características generales

Evaluación de las Características de las Herramientas 14,00% 12,00% 10,00% 8,00% 6,00% 4,00% 2,00% 0,00%

NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Ilustración 26. Gráfica de la evaluación de las Características de las Herramientas.

Evaluación total de las características de las herramientas

95,10% 96,00% 94,00% 92,00%

88,19%

90,00% 88,00% 86,00%

82,96%

84,03%

84,00% 82,00% 80,00% 78,00% 76,00% NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Ilustración 27. Gráfica de la evaluación total de las características de las herramientas de monitoreo. Como se puede apreciar la herramienta de monitoreo Nagios obtuvo el mejor puntaje de evaluación de las características generales con 95,10% y la herramienta Pandora FMS obtuvo la puntuación más baja con 82,96%.

4.1.3.2.7. Evaluación Final. La evaluación del proceso de instalación, de configuración y de las características de las herramientas se resume en el siguiente cuadro.

PESOS

PARÁMETROS

VALORACIÓN DE LAS HERRAMIENTAS NAGIOS PANDORA FMS ZABBIX ZENOSS 83,53% 60,03% 64,39% 88,54% 91,50% 63,00% 80,00% 87,00% 95,10% 82,96% 84,03% 88,19%

15,00% PROCESO DE INSTALACIÓN 55,00% PROCESO DE CONFIGURACIÓN 30,00% CARACTERÍSTICAS DE LA HERRAMIENTAS 100,00% Cuadro 17. Valoración de la evaluación final

A partir del cuadro de valoración se obtiene los valores del cuadro de Evaluación multiplicando la valoración por el valor de su peso.

EVALUACIÓN PORCENTUAL

PARÁMETROS

NAGIOS PANDORA FMS PROCESO DE INSTALACIÓN 12,53% 9,00% PROCESO DE CONFIGURACIÓN 50,33% 34,65% CARACTERÍSTICAS DE LA HERRAMIENTAS 28,53% 24,89% EVALUACIÓN 91,38% 68,54% Cuadro 18. Evaluación final.

ZABBIX 9,66% 44,00% 25,21% 78,87%

ZENOSS 13,28% 47,85% 26,46% 87,59%

Evaluación de los Procesos y Características 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% PROCESO DE INSTALACIÓN NAGIOS

PROCESO DE CONFIGURACIÓN PANDORA FMS

CARACTERÍSTICAS DE LA HERRAMIENTAS

ZABBIX

ZENOSS

Ilustración 28. Gráfica de la evaluación de los procesos y características.

Evaluación Final 100,00%

91,38% 78,87%

90,00%

87,59%

68,54%

80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% NAGIOS

PANDORA FMS

ZABBIX

ZENOSS

Ilustración 29. Gráfica de la evaluación final de las herramientas de monitoreo.

El mayor puntaje obtenido en la evaluación de las herramientas de monitoreo open source, es del programa Nagios versión 3.2., con 91,38%, por lo cual es seleccionado como la herramienta de monitoreo más óptima para la implementación en la red de la Universidad.

4.2. HERRAMIENTA

MONITOREO

PREPARADA

PARA

CONFIGURACIÓN. Para este resultado, se realizaron todas las actividades necesarias para obtener la herramienta de monitoreo Nagios instalada de forma estándar y lista para su posterior configuración, actividades que se detallan a continuación:

4.2.1. Adquisición y ensamblado de los componentes del servidor. 4.2.1.1. Componentes. La adquisición de los componentes para el ensamblaje del servidor sobre el cual se instaló la herramienta de monitoreo Nagios 3.2.3, se realizó de acuerdo a la documentación oficial de Nagios 3.2.3, dentro de la misma en su apartado ―requerimientos de sistema”6 se aprecia: Nagios necesita cualquier equipo que este ejecutando Linux o una variante de Unix y con compilador C‖; siendo CentOS 5.5 el sistema operativo sobre el cual funciona Nagios 3.2.3, los requisitos mínimos son: 

Memoria RAM 128 Mb (mínimo) 512 Mb (recomendado).



Disco Duro de 1 Gb (mínimo) – 2 Gb (recomendado).



Procesador Intel x86 –compatible (32 bits) (Intel Pentium I/II/III/IV/Celeron/Xeon, AMD K6/II/III, AMD Duron, Athlon/XP/MP), también procesadores de 64 bits.

Los componentes escogidos para el servidor fueron:



Procesador Dual Core de 2.5 GHz.



Disco Duro de 160 Gb de almacenamiento.



Memoria RAM de 2 Gb.



Mainboard compatible con los componentes anteriormente mencionados.

http://nagios.sourceforge.net/docs/3_0/about.html#requirements



Case compatible con mainboard y fuente de por lo menos 500w.

En base a la información expuesta se decidió realizar la compra de los componentes, los cuales se pueden observar en la Ilustración 30: un case marca Ares acompañado de parlantes, mouse y teclado, un mainboard marca Intel, un procesador marca Intel y un disco duro marca Samsung.

A1.2

A1.1 A2 A1.3 A3 A4 A1.4 Ilustración 30. Componentes adquiridos para armar el servidor. A1) Case marca Ares. A1.1) Case. A1.2) Parlantes. A1.3) Mouse. A1.4) Teclado. A2) Mainboard marca Intel. A3) Procesador marca Intel. A4) Disco duro marca Samsung. En la Ilustración 31 se aprecia con más detalle los siguientes componentes: un case Ares HB6002 con fuente de poder ATX P4 de 500w, un par de parlantes Ares HB-128 de 400w P.M.P.O. multimedia, un teclado Ares multimedia USB Smart keyboard, un mouse óptico

Ares con rueda y 3 botones, un procesador Intel Pentium dual core E5200 de 2.5 GHz, un mainboard Intel classic series DG31PR, una memoria RAM DIMMS A-DATA de 2 Gb PC800 DDR2, un disco duro Samsung con capacidad para 160 Gb SATA a 7200 RPM y un set de cables SATA e IDE para transferencia de datos.

B2 B9

B6 B4 B3

B5 B7

Ilustraci贸n 31. Componentes adquiridos detallados. B1) Case Ares HB6002 con fuente de poder ATX P4 de 500w. B2) Parlantes Ares HB-128 de 400w P.M.P.O. multimedia. B3) Teclado Ares multimedia USB smart keyboard. B4) Mouse 贸ptico Ares con rueda y 3 botones. B5) Procesador Intel Pentium dual core E5200 2.5 GHz. B6) Mainboard Intel classic series DG31PR. B7) Memoria RAM DIMMS A-DATA 2 Gb. PC-800 DDR2. B8) Disco duro (HDD) Samsung 160 Gb. Sata 7200 RPM. B9) Cables SATA e IDE para transferencia de datos.

La Ilustración 32 muestra los dos componentes que conforman el procesador Intel E5200: un disipador de calor y un chip de procesamiento.

Ilustración 32. Procesador, detalles. C1) Disipador de calor. C2) Chip de procesamiento.

4.2.1.2. Verificación y cuidado. Una vez revisado que todo esté en buen estado y completo, se realizó la lectura de los respectivos manuales de cada componente antes de comenzar con su manipulación y posterior ensamblaje. Al momento de manipular los componentes electrónicos es importante eliminar la carga electrostática que puede generar nuestro cuerpo, ya que al contacto con estos podemos dañarlos de forma permanente y anular su garantía. Para evitar caer en un escenario similar se utilizó las herramientas básicas adecuadas para el ensamblaje del servidor, según la Ilustración 33. Nota: Se debe tratar de utilizar la pulsera antiestática siempre que se manipule componentes electrónicos, ya que la garantía de estos no cubre este tipo de daños, por tratarse de una negligencia por parte de la persona que manipula los componentes.

4.2.1.3. Herramientas.

D2 D1

D4 D3

Ilustración 33. Herramientas necesarias para ensamblar el servidor. D1) Multímetro. D2) Pulsera antiestática. D3) Destornillador estrella estándar. D4) Juego de destornilladores de precisión. El multímetro fue una herramienta de ayuda a la hora de comprobar varios aspectos de las conexiones y componentes necesarios para el correcto funcionamiento del servidor, como fueron: 

Voltaje de corriente alterna (AC), desde la toma de corriente de pared (120 v).



Voltaje de corriente continua (CC), para comprobar las distintas intensidades de corriente que emana la fuente de poder ATX de 500w de nuestro case, las cuales vienen especificadas en la etiqueta de la misma.



Comprobar conexión a tierra; se recomienda de manera prioritaria el uso de un corta picos o mejor aún de ser posible un UPS para la conexión a corriente alterna (AC) del servidor.

La pulsera antiestática fue la herramienta que nos permitió eliminar la posible carga

electrostática de nuestro cuerpo y manipular los componentes sin temor a dañarlos. El uso correcto de la pulsera al momento de ensamblar los componentes hacia el chasis del case se puede observar en la Ilustración 34.

4.2.1.4. Preparativos previos al ensamblaje.

E6 E2 E3 E5

E1 E4

Ilustración 34: Case, componentes y uso de pulsera antiestática. E1) Placa para montaje de mainboard. E2) Fuente de poder ATX P4 de 500w. E3) Cables de corriente continua de la fuente de poder. E4) Cable de corriente alterna para suministro de fuente de poder y tornillos para acoplamiento de mainboard en el chasis. E5) Conector de pulsera antiestática. E6) Pinza de pulsera antiestática conectada en el case. Antes de proceder al montaje del mainboard sobre la placa del case (E1), se debió cerciorar que los componentes expuestos en la ilustración 34 se encuentren presentes. En nuestro caso el case contaba con la fuente (E2) de poder ya instalada y lista para

usarse (E3), también se contó con el cable de alimentación AC (E4) de la misma, y por último los tornillos (E5) necesarios para el acoplamiento del mainboard.

4.2.1.5. Elementos principales e instalación de mainboard. F5

F1 F6 F1 F1 F1

Ilustración 35: Partes principales del mainboard F1) Puntos de sujeción. F2) Ranura de procesador. F3) Ranuras de memorias RAM. F4) Conectores SATA. F5) Pines de conexión para botones Power y Reset. F6) Conectores PCI. Para ubicar el mainboard sobre la placa del case, se debió reconocer y familiarizar sus componentes principales que se encuentran en la Ilustración 35: los puntos de sujeción (F1) del mainboard para el correcto acoplamiento sobre la placa del case, la ranura de procesador (F2), donde como su nombre lo indica irá ubicado el procesador Intel E5200,

es importante leer el manual tanto del mainboard como del procesador antes de proceder a su acoplamiento, también debemos tener en cuenta que estos dos componentes deben ser compatibles7; ranuras de memoria RAM (F3), de manera similar al procesador deberemos estar seguros que la memoria RAM y el mainboard sean compatibles, generalmente estas indicaciones se encuentran en la caja del mainboard y de manera más detallada en su manual; conectores SATA (F4), que sirven para la comunicación entre el mainboard y dispositivos como discos duros, lectores de CD, DVD, DVD-RW, entre otros; pines de conexión para botones Power y Reset (F5), que son utilizados para poder realizar las funciones de encendido, apagado y reinicio del mainboard; finalmente los conectores PCI (F6), estos son de mucha utilidad al momento de querer expandir las características de nuestro CPU como por ejemplo: agregar tarjetas NIC, puertos usb, puertos paralelos, tarjetas PCI de video, tarjetas PCI SATA, wireless, entre otros.

G2 G1 G3 G6

G4 G5

Ilustración 36: Acoplamiento de mainboard y componentes principales. G1) Puntos de sujeción. G2) Ranura de procesador. G3) Ranuras de memorias RAM (2).

En la dirección http://processormatch.intel.com/CompDB/SearchResult.aspx?Boardname= dg31pr se encuentra información muy detallada sobre la compatibilidad entre el mainboard y el procesador.

G4) Conectores SATA (4). G5) Pines de conexión para botones Power y Reset. G6) Conectores PCI (2). Una vez familiarizados con los componentes, se continuó con el montaje del mainboard sobre la placa del case; para ello primero se encajó las ranuras de sujeción de la placa con los puntos de sujeción del mainboard, para seguidamente mediante los tornillos respectivos acoplar estos dos componentes; como se indica en la Ilustración 37.

H3 H2

H1 H4 H5

Ilustración 37: Componentes instalados en mainboard. H1) Procesador (1). H2) Memoria RAM (1). H3) Disco duro (HDD) (1). H4) Cable SATA conectando disco duro con mainboard (1). H5) Cables conectando botones Power y Reset con mainboard. En la Ilustración 37 se puede identificar como quedaron instalados todos los

componentes internos del mainboard y este a su vez acoplado en la placa del case del servidor. El procesador (H1) se encuentra son su respectivo disipador de calor y conectado al mainboard; la tarjeta de memoria RAM (H2) instalada en el primer socket de los dos que tiene el mainboard; el disco duro (H3) atornillado a la bahía de discos duros, interconectado con el mainboard por medio de del cable SATA (H4); finalmente podemos observar los cables de los botones Power y Reset (H5) del case conectados con el mainboard para realizar las funciones correspondientes de encendido, apagado y reinicio.

I1 I1

Ilustración 38. Servidor ensamblado completamente. I1)

Cables de fuente de poder conectados a la mainboard.

La Ilustración 38 resalta como se encuentran conectados los cables de la fuente de poder a la mainboard. Finalmente se procedió al cierre del case del servidor y a la conexión de los periféricos básicos de entrada (mouse y teclado) y salida (monitor), para seguidamente empezar con la instalación del sistema operativo.

4.2.2. Instalación y configuración del sistema operativo CentOS 5.5. La herramienta de monitoreo Nagios funciona sobre un sistema operativo tipo Linux, por esta razón en el servidor adquirido y armado para el proyecto, llamado servidor de monitoreo, se instaló el sistema operativo CentOS, en su versión más reciente y estable, CentOS 5.5. Se seleccionó el sistema operativo CentOS por ser el de mayor utilización en los servidores implementados en la red de la PUCE SD, por lo tanto de mayor familiarización por los administradores de red. Además de la correcta instalación de CentOS se procedió a realizar la configuración para que realice las funciones de servidor de monitoreo, comprobar y configurar parámetros de red, parámetros de seguridad (firewall), actualizaciones automáticas, entre otros, características que por seguridad, debido a que el servidor de monitoreo está conectado y funcionando en la red informática de la universidad, no se menciona ni se transcribe información alguna. El procedimiento de instalación del sistema operativo CentOS se puede revisar en el Anexo 4.

4.2.3. Instalación de la herramienta de monitoreo Nagios. Para la instalación de la herramienta de monitoreo Nagios, versión 3.2.3, en el servidor ensamblado para el proyecto, el mismo que ejecuta el sistema operativo CentOS 5.5, se descargó de la página web oficial de Nagios (www.nagios.org) los instaladores y manuales de instalación y configuración, dichos manuales se encuentran en el idioma Inglés, idioma natal de los desarrolladores. En la instalación de Nagios se utilizó toda la información de su comunidad activa, es decir, cualquier página web, artículo o e-book, que contenga información sobre la instalación de la herramienta. Todo el proceso de instalación y el Manual de Instalación creado por los investigadores, se puede apreciar en el Anexo 15. El manual creado para el proyecto se siguió al pie de la letra, con el fin de obtener la herramienta Nagios versión 3.2.3 instalada en su manera estándar y lista para seguir con su posterior configuración y personalización.

4.3. MONITOREO DE LOS DISPOSITIVOS DE RED Y SUS SERVICIOS. Para realizar el monitoreo, Nagios utiliza un archivo principal de configuración llamado nagios.cfg que contiene la dirección de los archivos de objetos definidos, ubicados en: /usr/local/nagios/etc/objetos, de donde obtiene la información de los parámetros de los dispositivos, servicios y recursos, como: dirección IP, nombre de comunidad snmp,

valores de alerta, nombre del recurso, entre otros; estos parámetros se transmiten por medio de los objetos definidos dentro del archivo comandos.cfg (ver anexo 11) del cual lee las líneas de comandos que Nagios ejecuta usando sus plugins; de los plugins se obtiene la información de estado de cada dispositivo, servicio y recurso monitoreado, Nagios compara estos datos con los criterios de configuración y de ser necesario envía las alertas correspondientes acorde a los periodos de monitoreo y periodos de notificación establecidos en el archivo periodos_de_tiempo.cfg (ver anexo 14). El proceso de monitoreo que realiza Nagios se puede apreciar en la ilustración 39. Una característica especial de Nagios es su flexibilidad de monitoreo, ya que no realiza el monitoreo directamente desde su funcionamiento, es decir, no incluye ningún mecanismo para monitorear el estado de dispositivos y servicios de la red, sino que se basa en programas externos, llamados plugins. Los plugins son ejecutables compilados o scripts, que pueden ser ejecutados desde una línea de comando para chequear el estado de un dispositivo o servicio de red. Nagios ejecutará un plugin cuando exista la necesidad de monitorear el estado de un dispositivo o servicio, los plugins realizan el chequeo del equipo y devuelven simplemente a Nagios el estado, el cual utiliza la información que devuelven los plugins y realiza una acción, que puede ser enviar o no una notificación. La distribución oficial de Nagios viene con plugins que pueden ser utilizados para monitorear una variedad de servicios y dispositivos, existen 1939 plugins creados por la comunidad de usuarios que pueden ser localizados en la página oficial de Nagios: http://exchange.nagios.org/directory/Plugins, adicionalmente se pueden utilizar plugins ubicados en diferentes paginas no oficiales de Nagios, por ejemplo la página http://nagios.manubulon.com/, por último recurso, si no existe un plugin apropiado para los dispositivos a monitorear, se puede crear plugins siguiendo los manuales de creación de plugins. Para configurar el monitoreo de los dispositivos de red y sus servicios se dividieron tres actividades, diferenciadas y en orden secuencial, inicialmente se configuró el monitoreo de los dispositivos de red y sus recursos donde la herramienta de monitoreo Nagios verifica la conectividad de los dispositivos de red supervisando las NIC (Network Interface Card) de cada dispositivo, disco duro, memoria RAM, memoria virtual, procesados, niveles de tinta, entre otros; la siguiente actividad fue la configuración del monitoreo de los servicios de red de la PUCE SD, donde Nagios comprueba el correcto funcionamiento

de cada servicio de red como: SSH, HTTP, SMTP, PROXY, DNS, DHCP, entre otros; para concluir este resultado se procedió a la configuración de envío de alertas que realizará Nagios en caso de que suceda algún evento irregular en los recursos de los dispositivos y los servicios de red.

Ilustración 39. Esquema del proceso de monitoreo de Nagios.

4.3.1. Configuración de monitoreo de dispositivos de red y sus recursos. Según el documento de Levantamiento de Información (ver anexo 5) y su respectiva actualización (ver anexo 7) se obtienen los tipos de dispositivos y los recursos a ser monitoreados por Nagios (ver cuadro 5), para la configuración del monitoreo de los servidores de la red y sus respectivos recursos: memoria virtual, memoria RAM, espacio de disco duro, entre otros; primero se creó un archivo de configuración dentro del directorio correspondiente en Nagios: /usr/local/nagios/etc/objetos, con la extensión *.cfg llamado equipos.cfg (ver anexo 9); se crea este archivo porque Nagios necesita hacer referencia a una dirección ip del dispositivo a ser monitoreado, por lo tanto, se define un objeto por cada dirección ip, en el caso de los switchs administrables se configura un objeto por la dirección ip de administración, en segundo lugar se creó otro archivo con la misma extensión *.cfg nombrado monitoreo.cfg (ver anexo 10), que contiene la configuración de los recursos y servicios a ser monitoreados para cada uno de los objetos definidos en el archivo equipos.cfg.

Para una mejor estructura y facilidad de manejo del archivo que contiene los objetos a monitorear se dispuso agruparlos por su ubicación geográfica; algunos objetos tienen dos o más interfaces de red, y para asegurarnos de su correcto funcionamiento se monitorean todas. Los nombres y direcciones ip utilizadas se han cambiado por razones de salvaguardar la integridad y seguridad de los dispositivos de red. Según los dispositivos del documento de actualización del levantamiento de información sobre la red (ver anexo 7), se definió un objeto por cada ip perteneciente a un dispositivo, a continuación se listan todos los objetos creados: Objetos Edificio San Liborio – Cuarto de servidores:  Servidor Página Web.  Servidor de Aplicaciones.  Servidor Cacti.  Servidor Correo.  Servidor DMZ.  Servidor de Dominio.  Servidor de Impresoras.  Servidor Nagios.  Servidor Producción.  Servidor Actualizaciones.  Servidor ROA.  Servidor Secretarias.  Switch HP2.  Switch SWOZ.  Router Admin.

 Router ISP. Objetos Edificio San Liborio – Información:  Impresora Información. Objetos Edificio Emilio Lorenzo Sthele – Cuarto de Servidores:  Servidor Sistema Micropc 1.  Servidor Sistema Micropc 2.  Servidor Misioneros.  Switch HP1.  Switch SW1T.  Access Point Sala de Cómputo. Objetos Edificio Daponte - Biblioteca: 

Access Point Biblioteca.

Objetos Departamento de Idiomas:  Impresora Departamento de Idiomas. Objetos Dicom:  Impresora Dicom. La definición de cada objeto en el archivo equipos.cfg sigue el siguiente formato: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents

servidor-linux Servidor Correo Servidor de Correo A.B.C.D 24x7 24x7 d,u,r administrador correo mail_server.gif mail_server.gd2 Servidor Nagios

}

La explicación de las variables de cada objeto se encuentra en la sección 4.9 Agregando Equipos del manual de configuración (ver anexo 16). La definición de todos los objetos por cada ip realizada para configurar el monitoreo de los dispositivos de la PUCE SD se puede apreciar en el anexo 12. Identificados y creados todos los objetos: servidores, switchs, routers, access points e impresoras, se procedió a crear otro archivo de configuración llamado comandos.cfg, este archivo es importante, ya que contiene las definiciones de los comandos necesarios para que Nagios interactúe con los distintos plugins, de los cuales se vale para realizar la actividad de monitoreo. Se configura a Nagios para que envíe los parámetros necesarios a los plugins y estos puedan realizar su trabajo y obtener los datos de los estados de los dispositivos a ser monitoreados. Los datos recolectados por los plugins serán contrastados con los parámetros de evaluación pasados junto con el resto de parámetros, devolviendo así uno de los posibles estados que maneja la herramienta de monitoreo para evaluar el correcto funcionamiento de los recursos y servicios, estos son: 

ok (bien).



warning (alerta).



critical (crítico).



unknown (desconocido).

Ejemplo de una supervisión de Nagios: Esta es una definición dentro del archivo de configuración comandos.cfg, este comando será utilizado para verificar el espacio utilizado de un disco duro, como se puede observar los comandos se componen generalmente de dos elementos: nombre del comando (command_name) y la línea de comando a ejecutar (command_line). define command{ command_name verificar_dd command_line $USER1$/check_snmp_storage.pl -H $HOSTADDRESS$ -C $ARG1$ -w $ARG2$ -c $ARG3$ -m $ARG4$ }

El nombre es utilizado para identificar el comando y poder llamarlo desde otros archivos y la línea de comando contiene el nombre del plugin, en este caso check_snmp_storage.pl, seguido de los parámetros necesarios para su ejecución y criterio de evaluación, donde: -H recibe la dirección IP del equipo a través del argumento $HOSTADDRESS$, -C recibe la comunidad snmp en el argumento $ARG1$, -w para el criterio warning en $ARG2$, -c para el criterio critical en $ARG3$ y –m para la unidad de montaje del disco duro a ser evaluado en $ARG4$. Nagios obtiene los valores de los argumentos a ser transmitidos de la función que llama al comando y que se programaron, para este ejemplo los obtiene de la definición de un servicio para el servidor de correo, el cual obtiene el estado del disco duro de dicho servidor de la unidad de montaje ―/‖, con respecto al argumento $HOSTADDRESS$ Nagios lo obtiene haciendo referencia al nombre del equipo (host_name) donde este se encuentra configurado en el archivo equipos.cfg. define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico Servidor Correo 24x7 24x7 w,c,u,r admin3 Espacio Disco Duro verificar_dd!public!80!90!/

Como se puede observar dentro de la definición de este servicio, aunque se va a monitorizar un recurso, Nagios toma estas definiciones como servicios, se llama al comando verificar_dd definido previamente en el archivo comandos.cfg, y también se procede a pasar los parámetros necesarios para el funcionamiento del comando: la comunidad snmp public, el criterio warning 80, el criterio critical 90, donde los números 80 y 90 representan los parámetros de evaluación, los cuales son asignados por los disertantes y la unidad de montaje ―/”, por tratarse de un sistema Linux; todos estos parámetros se separan por el carácter ―!‖. En la práctica, una vez que el servicio denominado Espacio Disco Duro llama al comando verificar_dd pasando los respectivos argumentos, este último hará que el plugin check_snmp_storage.pl realice la acción solicitada y envíe el estado del recurso hacia Nagios.

Esta

sería

manera

como

plugin

ejecutaría

desde

directorio

/usr/local/nagios/libexec donde Nagios contiene los plugins instalados: ./check_snmp_storage.pl -H 192.168.4.6 -C public -w 80 -c 90 -m / El plugin devolverá, de acuerdo al espacio utilizado en el disco duro dentro de la unidad de montaje especificada los siguientes estados:  ok si el espacio ocupado del disco duro es menor al 80%.  warning si es mayor o igual al 80% y menor al 90%.  critical si es mayor o igual al 90%.  unknown si no pudo obtener ningún valor. Nagios repite el mismo funcionamiento según el equipo a monitorear y su comando de monitoreo, el archivo de configuración de los equipos se puede observar en el Anexo 9.

4.3.2. Configuración del monitoreo de los servicios de red. Teniendo monitoreados los dispositivos de red y sus recursos, se configuró en Nagios el monitoreo de los servicios de red, estos son:  Página web, HTTP.  Conexión, SSH.  Correo electrónico, SMTP.  Filtrado de contenido web, SQUID.  DNS.  SMB.  Mysql. La configuración del monitoreo de los servicios se realiza dentro del archivo monitoreo.cfg, también utilizado para definir la configuración del monitoreo de los recursos de los dispositivos, como se explicó en el apartado anterior.

100

El esquema de configuración de los servicios es similar al que se describe en el monitoreo de los recursos, debido a que todas las definiciones para la actividad de monitoreo ya sea para recursos, servicios y disponibilidad de dispositivos en la red, Nagios las toma como servicios.

4.3.2.1. Configuración del Monitoreo de un servicio de red. Para la explicación del proceso de configuración del monitoreo de un servicio de red, la configuración del monitoreo de servicio http, servirá como esquema general para el resto de configuraciones de monitoreo de servicios.

4.3.2.1.1. Configuración del Monitoreo del servicio de red HTTP. a. Definir el equipo a monitorear dentro del archivo equipos.cfg, en la ruta /usr/local/nagios/etc/objetos/, a continuación se expone la definición del servidor de la página web de la universidad: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-pag-web Servidor Pagina Web A.B.C.D 24x7 24x7 d,u,r admin2 linux.gif linux.gd2 swt-dmz

La definición de cada parámetro del equipo se ubica en el manual de configuración (ver anexo 16 sección 4.9), la definición de plantillas como servidor-linux se encuentran en el anexo 12. Por motivos de seguridad la dirección ip del servidor no se pública. b. Implementar la definición del comando; para el servicio http es verificar_http, ubicado en el archivo comandos.cfg, dentro de la ruta /usr/local/nagios/etc/objetos/, la definición del comando se describe a continuación: define command{ command_name command_line $ARG1$ $ARG2$ }

verificar_http $USER1$/check_http -I $HOSTADDRESS$ -p

101

La definición del comando verificar_htttp realiza el llamado al plugin check_http y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio http, los argumentos del plugin son:  HOSTADDRESS representa la dirección ip del servidor, el cual se obtiene del parámetro address de la definición del equipo.  ARG1 representa el puerto, este valor es el primer número después del símbolo ―!‖ del parámetro check_command de la definición del servicio.  ARG2 representa la versión del protocolo, este valor es el segundo número después del símbolo ―!‖ del parámetro check_command de la definición del servicio. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_http -I A.B.C.D –p 80 -4 Este plugin devuelve el estado del servicio http, estos pueden ser:  ok si el servicio de página web está funcionando correctamente a través del puerto 80.  warning si el servicio tiene algún tipo de retraso en la petición de información.  critical si el servicio no está escuchando las peticiones al puerto 80.  unknown si no se puede determinar su estado. c. Definir el servicio asociado al equipo dentro del archivo monitoreo.cfg, ubicado en la ruta /usr/local/nagios/etc/objetos/ , la definición del servicio se lo realizó de la siguiente manera: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-pag-web 24x7 24x7 w,u,c,r admin3 HTTP verificar_http!80!-4

102

La explicación de cada parámetro del servicio se lo ubica en el manual de configuración (ver anexo 16). La definición del servicio monitorea el servicio http, utiliza el comando verificar_http el cual envía el argumento 80, que representa el puerto que utiliza el servidor de página web para escuchar las peticiones realizadas a

la página de la

universidad y -4 significa la versión del protocolo de internet – IP.

4.3.2.1.2. Configuración de monitoreo del servicio de red SSH. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-pag-web Servidor Pagina Web A.B.C.D 24x7 24x7 d,u,r admin2 linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line $ARG2$ }

verificar_ssh $USER1$/check_ssh -H $HOSTADDRESS$ -p $ARG1$

En la definición del comando verificar_ssh realiza el llamado al plugin check_ssh y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio SSH, estos argumentos tienen el mismo funcionamiento que check_ssh, explicado anteriormente. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_ssh -H A.B.C.D –p 22 -4 Este plugin devuelve el estado del servicio ssh, estos pueden ser:  ok si el servicio de página web está funcionando correctamente a través del puerto 22.  warning si el servicio tiene algún tipo de retraso en la petición de información.

103

 critical si el servicio no está escuchando las peticiones al puerto 80.  unknown si no se puede determinar su estado. c. Definición del servicio: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-pag-web 24x7 24x7 w,u,c,r admin3 SSH verificar_ssh!22!-4

La definición del servicio utiliza el comando verificar_ssh el cual envía el argumento 22, que representa el puerto que utiliza el protocolo SSH en el servidor de página web, -4 significa la versión del protocolo de internet – IP.

4.3.2.1.3. Configuración de monitoreo del servicio de red SMTP. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-correo Servidor correo A.B.C.D 24x7 24x7 d,u,r admin2 linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line $ARG2$ }

verificar_smtp $USER1$/check_smtp -H $HOSTADDRESS$ -p $ARG1$

En la definición del comando verificar_smtp realiza el llamado al plugin check_smtp y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio SMTP,

104

estos argumentos tienen el mismo funcionamiento que check_smtp, explicado anteriormente. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_smtp -H A.B.C.D –p 25 -4 Este plugin devuelve el estado del servicio ssh, estos pueden ser:  ok si el servicio smtp está funcionando correctamente a través del puerto 25.  warning si el servicio tiene algún tipo de retraso en la petición de información.  critical si el servicio no está escuchando las peticiones al puerto 25.  unknown si no se puede determinar su estado. c. Definición del servicio: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-pag-web 24x7 24x7 w,u,c,r admin3 SMTP verificar_ssh!25!-4

La definición del servicio utiliza el comando verificar_smtp el cual envía el argumento 25, que representa el puerto que utiliza el protocolo SSH en el servidor de página web, -4 significa la versión del protocolo de internet – IP.

4.3.2.1.4. Configuración del Monitoreo del servicio de red SQUID. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options

servidor-linux srv-firewall Servidor DMZ VLAN A.B.C.D 24x7 24x7 d,u,r

105

contact_groups icon_image statusmap_image parents }

admin2, linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line $ARG1$ $ARG2$ }

verificar_squid $USER1$/check_squid -H $HOSTADDRESS$ -p

En la definición del comando verificar_squid realiza el llamado al plugin check_squid y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio squid. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_squid -H A.B.C.D –p 8080 -4 Este plugin devuelve el estado del servicio squid, estos pueden ser:  ok si el servicio de página web está funcionando correctamente a través del puerto 8080.  warning si el servicio tiene algún tipo de retraso en la petición de información.  critical si el servicio no está escuchando las peticiones al puerto 8080.  unknown si no se puede determinar su estado. c. Definición del servicio: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-firewall 24x7 24x7 w,u,c,r admin3 SQUID verificar_squid!8080!-4

La definición del servicio utiliza el comando verificar_squid el cual envía el argumento 8080, que representa el puerto que utiliza el servicio SQUID en el servidor de firewall, -4 significa la versión del protocolo de internet – IP.

106

4.3.2.1.5. Configuración del Monitoreo del servicio de red DNS. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-dominio Servidor Dominio A.B.C.D 24x7 24x7 d,u,r admin2, linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line -w 5 -c 10 }

verificar_dns $USER1$/check_dns -s $HOSTADDRESS$ -H $ARG1$

En la definición del comando verificar_dns realiza el llamado al plugin check_dns y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio dns. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_squid -s A.B.C.D –H www.yahoo.com –w 5 –c 10 Este plugin devuelve el estado del servicio dns, estos pueden ser:  ok si el servicio de dns está funcionando correctamente y tarda menos de 5 segundos en resolver la dirección www.yahoo.com.  warning si el servicio tarda entre 5 y 10 segundos en resolver.  critical si el servicio tarda más de 10 segundos en resolver la petición.  unknown si no se puede determinar su estado. c. Definición del servicio: define service{ use

servicio-generico

107

host_name check_period notification_period notification_options contact_groups service_description check_command }

srv-dominio horas-de-trabajo-4 horas-de-trabajo-4 w,u,c,r admin2 DNS verificar_dns!www.yahoo.com

La definición del servicio utiliza el comando verificar_dns el cual envía el argumento www.yahoo.com, para que el servicio resuelva el nombre y devuelva la dirección IP correspondiente dentro de los tiempos establecidos para su evaluación.

4.3.2.1.6. Configuración del Monitoreo del servicio de red SMB. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-actualizaciones Servidor Actualizaciones A.B.C.D 24x7 24x7 d,u,r admin2, linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line }

verificar_smb $USER1$/check_smb -H $HOSTADDRESS$

En la definición del comando verificar_smb realiza el llamado al plugin check_smb y envía los argumentos que necesita el plugin para realizar el monitoreo del servicio smb. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_smb -H A.B.C.D Este plugin devuelve el estado del servicio smb, estos pueden ser:  ok si el servicio de smb está funcionando correctamente.

108

 critical si el acceso al servicio smb resulta en error.  unknown si no se puede determinar su estado. c. Definición del servicio: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-actualizaciones horas-de-trabajo-4 horas-de-trabajo-4 w,u,c,r admin2 SMB verificar_smb!

La definición del servicio utiliza el comando verificar_smb el cual se conecta al servicio por medio de la dirección IP del host, y el mismo responda si se encuentra listo para compartir los archivos.

4.3.2.1.7. Configuración del Monitoreo del servicio de red MYSQL. a. Definición del equipo: define host{ use host_name alias address check_period notification_period notification_options contact_groups icon_image statusmap_image parents }

servidor-linux srv-pag-web Servidor DMZ VLAN A.B.C.D 24x7 24x7 d,u,r admin2, linux.gif linux.gd2 swt-dmz

b. Definición del comando: define command{ command_name command_line $ARG1$ $ARG2$ }

verificar_mysql $USER1$/check_mysql -H $HOSTADDRESS$ -p

En la definición del comando verificar_mysql realiza el llamado al plugin check_mysql y envía los argumentos que necesita el plugin para realizar el monitoreo de la base de

109

datos mysql, estos argumentos tienen el mismo funcionamiento que check_http, explicado anteriormente. Esta es la manera en la cual se ejecutaría el plugin por línea de comando: ./check_mysql -H A.B.C.D –p 3306 -4 Este plugin devuelve el estado de la base de datos mysql, estos pueden ser:  ok si la base de datos mysql está funcionando correctamente a través del puerto 3306.  warning si el servicio tiene algún tipo de retraso en la petición de información.  critical si el servicio no está escuchando las peticiones al puerto 3306.  unknown si no se puede determinar su estado. d. Definición del servicio: define service{ use host_name check_period notification_period notification_options contact_groups service_description check_command }

servicio-generico srv-pag-web 24x7 24x7 w,u,c,r admin3 MYSQL verificar_mysql!3306!-4

La definición del servicio utiliza el comando verificar_mysql el cual envía el argumento 3306, que representa el puerto que utiliza la base de datos mysql en el servidor de página web, -4 significa la versión del protocolo de internet – IP.

4.3.3. Configuración del envío de alertas. En la configuración del envío de alertas en la herramienta Nagios se creó el archivo contactos.cfg (ver anexo 13) en la ruta /usr/local/nagios/etc/objetos/ del servidor de monitoreo, este archivo contiene las definiciones de sus objetos y la información necesaria para el envío de alertas generadas hacia los responsables de los elementos monitoreados en la red, denominados como contactos.

110

Cabe destacar que la configuración del envío de alertas ya sea por e-mail o vía SMS, se la realizó de acuerdo a la necesidad de que estas se deban generar o no de acuerdo al criterio de sus administradores. A continuación se expone un ejemplo de la definición para un contacto: define contact{ contact_name use alias email pager }

Administrador contacto-generico Administrador de red ejemplo@pucesd.edu.ec 4000000@portafree.com

La estructura utilizada para la definición de un contacto es muy similar a las demás definiciones usadas anteriormente; los parámetros en común son: nombre (name), plantilla a usarse (use) y seudónimo (alias), email y pager fueron utilizados para especificar la dirección de correo electrónico y el número del dispositivo móvil (celular) respectivamente. Ejemplo de la definición del comando notificar-equipo-por-email: define command{ command_name notificar-equipo-por-email command_line /usr/bin/printf "%b" "***** Nagios *****\n\nTipo de Notificacion: $NOTIFICATIONTYPE$\nEquipo: $HOSTNAME$\nEstado: $HOSTSTATE$\nDireccion: $HOSTADDRESS$\nInformacion: $HOSTOUTPUT$\n\nFecha/Tiempo: $LONGDATETIME$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Alerta de Equipo: $HOSTNAME$ esta $HOSTSTATE$ **" $CONTACTEMAIL$ } Como se observa se utiliza la misma estructura con la que se define cualquier comando, esto es: command_name (nombre del comando) y command_line (línea de comando a ejecutar). Una vez que Nagios detecte un problema con el equipo y/o servicio, ejecutará el envío de alerta(s) al responsable(s) de los mismos, siempre y cuando estas se encuentren definidas en los objetos del equipo o servicio y al mismo tiempo activas. Ejemplo de una alerta enviada a un correo de hotmail:

111

Ilustración 40. Ejemplo de envío de notificaciones de Nagios.

4.4. MANUALES DE LA HERRAMIENTA NAGIOS. En este resultado se explica el proceso y las actividades para la creación de manuales personalizados de Nagios versión 3.2.3, los manuales necesarios para su óptima utilización son: instalación, configuración y usuario. Los manuales de Nagios se crearon debido a la generalización del manual oficial, ya que contiene los procesos de instalación y configuración en un solo manual, sin aprovechar la información generada por su comunidad, que es un aspecto importante tratándose de software open source, el manual no utiliza los comentarios y experiencia de los usuarios de Nagios y existe muy poca información sobre el uso de su interfaz de administración, es decir, no existe un manual usuario de Nagios. Por su extensión los manuales desarrollados para el proyecto se adjuntan como anexos.

4.4.1. Elaboración del manual de instalación de la herramienta Nagios. Un manual de instalación es aquel que explica los comandos o pasos que se siguen para obtener un software funcionando en su manera básica o estándar, este manual de instalación explica el procedimiento de instalación de la herramienta Nagios versión 3.2.3, sobre el sistema operativo CentOS 5.5, el manual de instalación está destinado a cualquier persona que necesite o requiera instalar Nagios 3.2.3 sobre el sistema operativo CentOS 5.5. El manual de instalación creado para el proyecto es un híbrido, porque combina, utiliza y aprovecha la información planteada en el manual original de Nagios, el cual no se centra

112

solo en la instalación, sino en todos los aspectos del software Nagios y se lo puede ubicar en la página oficial de Nagios (www.nagios.org), se toman en cuenta los libros y ―ebooks‖ dedicados a la herramienta Nagios, aunque no son numerosos, su aporte es fundamental, por último, se revisó varias páginas web que contenían información sobre el proceso de instalación, las mismas se pueden revisar en la bibliografía. El manual se creó por varias razones:  El idioma original del manual oficial es el inglés, por lo que se creó un manual de instalación en español.  El manual oficial es generalizado por lo que se necesita de un manual dedicado a la instalación, simplificando de una manera sencilla y de fácil comprensión todo el procedimiento de instalación de la herramienta Nagios.  Aprovechar e incluir en el manual de instalación la información de la comunidad de usuarios con relación a la instalación de la herramienta, los problemas típicos y recomendaciones. El manual de instalación de la herramienta Nagios creado para el proyecto se lo puede revisar en el Anexo 15.

4.4.2. Elaboración del manual de configuración de la herramienta Nagios. El manual de configuración abarca y explica los elementos, comandos, estructuras e implementación lógica a seguir para realizar una correcta configuración de la herramienta de monitoreo Nagios versión 3.2.3, e implementar el monitoreo activo sobre los dispositivos y servicios de red. El manual de configuración está orientado a los administradores de Nagios y a cualquier persona que requiera implementar su funcionamiento y monitoreo. Por tratarse de un manual de configuración, para el entendimiento del mismo es recomendable que el lector cuente con los conocimientos básicos y necesarios en áreas como: redes, sistemas operativos y programación. La creación del manual se basó en la documentación oficial y la experiencia del manejo de la herramienta, procurando que sea lo más práctico y entendible para el lector.

113

El manual de configuración de la herramienta Nagios 3.2.3 sobre la plataforma CentOS 5.5 se puede revisar en el Anexo 16.

4.4.3. Elaboración del manual de usuario de la herramienta Nagios. Se puede definir el manual de usuario (user guide) en el campo de la informática y computación, como un documento técnico de un determinado sistema que busca dar asistencia y soporte a las personas que de alguna forma tenga que usar dicho sistema, un manual de usuario debería poder ser entendido por cualquier usuario principiante, o avanzado. El manual de usuario creado para el proyecto es explícitamente para el uso de la herramienta de monitoreo Nagios versión 3.2.3, sobre la plataforma CentOS 5.5, y se basa en el manual oficial, e-books y de páginas web de la comunidad de usuarios que contienen información sobre el uso de la interfaz de Nagios. En el manual se explica el uso de la interfaz web de la herramienta, se describe el uso de todos los enlaces, las diferentes pantallas de la herramienta, informes y una

explicación completa de los

mismos. El manual de usuario de la herramienta Nagios desarrollado para el proyecto se lo puede revisar en el Anexo 17.

4.5. PRUEBAS DE FUNCIONAMIENTO DE LA HERRAMIENTA OPEN SOURCE NAGIOS, VERSIÓN 3.2.3. Este capítulo trata sobre las pruebas de funcionamiento de la herramienta de monitoreo open source Nagios implementada en la infraestructura de red de la PUCE SD, se exponen las pruebas realizadas por los desarrolladores conjuntamente con los administradores de red para comprobar la estabilidad y monitoreo de los dispositivos y servicios de red especificados en el documento de Actualización del Levantamiento de Información (ver anexo 8).

4.5.1. Ejecución de pruebas. La fase de ejecución de pruebas añade valor a la herramienta de monitoreo implementada, la configuración de programas open source pueden tener errores y la fase de pruebas los descubre y permite corregirlos, confirmando la garantía de calidad de la herramienta. El objetivo específico de la fase de pruebas es comprobar y registrar la

114

funcionalidad de la herramienta; se realizaran pruebas de la herramienta Nagios conectada a la red informática de la PUCE-SD, el servidor se ubicó en el cuarto de servidores del edificio Emilio Lorenzo Estehle, conjuntamente con la Subárea de Redes se validaron todos los requisitos del funcionamiento de la herramienta. 4.5.2. Pruebas de Caja Negra. La pruebas de caja negra comprueban qué es lo que hace un programa, pero sin dar importancia a cómo lo hace, no se precisa definir ni conocer los detalles internos de su funcionamiento, es decir, no se toma en cuenta el código y la estructura interna del programa. El tipo de pruebas que se realizaron a la herramienta de monitoreo son de caja negra porque si bien se conoce y se puede modificar el código fuente de la herramienta de monitoreo Nagios ya que se trata de software open source, el proyecto no se basa en el desarrollo del sistema, sino, en el estudio, comparación e instalación de la herramienta, por esta razón las pruebas se concentran en destacar y comprobar las características que van a interactuar con los administradores, proporcionando entradas controladas y estudiando las salidas para ver si son o no las esperadas, es decir, se prueba la correcta configuración y la funcionalidad del monitoreo de los dispositivos y servicios de red. Para probar que la herramienta Nagios realice el correcto monitoreo de los servicios y dispositivos de red de la infraestructura informática de la PUCE SD, se seleccionó conjuntamente con los administradores aquellos servidores, dispositivos y servicios de red que se encontraban en estado estable y funcional durante el tiempo de prueba, es decir, los dispositivos que no presenten problemas de configuración y funcionamiento. Las eventos críticos se simularon mediante cuatro procesos: parar un servicio de red, iniciar un servicio de red, desconectar un dispositivo de la red informática, conectar el dispositivo a la red informática; de esta manera se pudo registrar el tiempo en que Nagios detecta el cambio de estado, envía una notificación de alerta al correo y celulares, y se comprueba la llegada de las notificaciones. Se obtuvieron gráficas de funcionamiento (ver anexo 8) y la visualización del cambio de estado del monitoreo de dispositivos generada por la interfaz gráfica de Nagios. Las pruebas fuerzan a la herramienta de monitoreo a enviar notificaciones de alerta del mal funcionamiento de los dispositivos o servicios de red, las pruebas realizadas están destinadas a la detección de la llegada de los mensajes a los correos y celulares de los administradores de red.

115

4.5.3. Estrategias de pruebas. La estrategia de prueba se refiere a las técnicas usadas y el criterio de aceptación para considerar una prueba como cumplida.

Objetivo:

Verificar la llegada de mensajes de alerta generados por Nagios a los correos de los administradores y a los celulares.

Descripción de la Prueba:

Las pruebas miden tiempos de respuesta de Nagios y verifican la recepción de los mensajes. Se ejecuta por cada servicio de red y dispositivo en los servidores de la PUCE SD.

Técnica:

Se simulan los eventos críticos: parar e iniciar un servicio de red, desconectar y conectar un dispositivo a la red informática.

Criterio de completitud:

Tiempo prudente en detección de los cambios de estado por Nagios y en recepción de notificaciones por parte de los administradores.

Consideraciones

Registrar la no recepción de las notificaciones, para que

Especiales:

pueda ser corregida la configuración de la herramienta.

Cuadro 19. Estrategias de pruebas. La ejecución de las pruebas fueron revisadas y aprobadas por la Subárea de Redes del CITIC mediante el documento de pruebas de funcionamiento de la herramienta Nagios (ver anexo 8), la matriz de pruebas y sus columnas se detallan a continuación: Nombre: Nombre del servidor, switch, access point o router de prueba. Monitoreo: Nombre del servicio de prueba. Hora de Inicio: Hora de comienzo de la simulación del evento crítico.

116

Hora de respuesta de Nagios: Hora en que Nagios detecta el cambio de estado del servicio o equipo para el evento crítico. Estado del equipo o servicio en Nagios: Tipo de mensaje que muestra Nagios en la descripción del equipo o servicio. Hora Tiempo de recepción al celular: Hora de recepción en los celulares de los administradores del mensaje de notificación de Nagios. Gráfico de Monitoreo: Expone el número de gráfico según el documento de pruebas de funcionamiento de la herramienta Nagios (ver anexo 8), que corresponde a la evaluación del equipo o servicio.

Conectividad

Sala de Computo

Router admin

Enlace troncal

-----------

Conectividad

HP1

-----------

Conectividad

Micropc 2

-----------

Conectividad

21:50

-----------

Conectividad

DNS

21:25

-----------

Conectividad

Proxy

20:19

HTTP

20:39

19:33

SMTP

SSH

-----------

Hora de inicio

Conectividad

MONITOREO

Micropc 1

Dominio

Firewall

Correo

NOMBRE

-----------

21:53

-----------

21:28

20:42

-----------

20:25

19:39

-----------

Hora de respuesta de Nagios (Gráfico a.)

INICIAR UN SERVICIO DE RED

-----------

Critical

-----------

21:57

-----------

21:32

Critical

-----------

20:46

-----------

20:29

19:43

-----------

Critical

-----------

Critical

-----------

21:57

-----------

21:34

20:46

-----------

20:29

19:44

-----------

21:59

-----------

21:35

20:48

-----------

20:32

19:56

-----------

22:00

-----------

21:36

20:51

-----------

20:34

20:03

-----------

SWITCH

-----------

22:03

-----------

21:37

20:51

-----------

20:34

20:03

-----------

ROUTER

-----------

ACCESS POINT

-----------

22:00

-----------

21:36

20:51

-----------

20:34

20:03

-----------

SERVIDORES

22:33

17:21

22:20

22:10

22:35

17:29

22:31

22:11