• No se han encontrado resultados

Propuesta de configuraciones para el sistema de gestión de los servicios y los recursos de la Intranet de la UCLV

N/A
N/A
Protected

Academic year: 2020

Share "Propuesta de configuraciones para el sistema de gestión de los servicios y los recursos de la Intranet de la UCLV"

Copied!
93
0
0

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y Electrónica. TRABAJO DE DIPLOMA. “Propuesta de configuraciones para el sistema de gestión de los servicios y los recursos de la Intranet de la UCLV” Autor: Maidel Gómez Muñoz. Tutor: MSc. Ramón Torres Rojas. Santa Clara 2009 "Año del 50 Aniversario del Triunfo de la Revolución".

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y Electrónica. TRABAJO DE DIPLOMA “Propuestas de configuraciones para el sistema de gestión de los servicios y los recursos de la Intranet de la UCLV” Autor: Maidel Gómez Muñoz E-mail: [email protected]. Tutor: MSc. Ramón Torres Rojas E-mail: [email protected]. Santa Clara 2009 "Año del 50 Aniversario del Triunfo de la Revolución".

(3) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(4) i. DEDICATORIA. A mis padres, por la confianza que siempre depositaron en mí. A mi familia. A Daimí, mi guantanamera, por ser única..

(5) ii. AGRADECIMIENTOS. A Ramón Torres por sus sabios consejos en todo momento. A la Revolución Cubana por haberme forjado. A mis compañeros de aula por las terapias anti-stress (el taquito). A Daimí por su apoyo constante y sus clases de metodología. A mis familiares por su ayuda incondicional. A todos los que colaboraron de una forma u otra con este trabajo..

(6) iii. TAREA TÉCNICA. 1. Búsqueda bibliográfica y estudio de trabajos precedentes sobre el tema de Gestión; específicamente sobre software libre y su aplicación. 2. Una vez obtenidos los programas y demás recursos disponibles, instalar y analizar las variantes a escala de laboratorio. 3. Concretar las propuestas finales.. Firma del Autor. Firma del Tutor.

(7) iv. RESUMEN. La gestión de redes es un tema de obligatorio conocimiento para optimizar o mejorar el funcionamiento de cualquier red de computadoras. Ya que incluye métodos que permiten sustentar y mantener un eficaz aprovechamiento en sus dispositivos y servicios. La Intranet de la Universidad, constituida por la interconexión de más de 3000 computadoras, da soporte a muchos aplicaciones que usan constantemente alrededor de 13 000 usuarios, por lo que es imprescindible el perfecto estado de sus recursos físicos y lógicos. Para garantizar el buen desempeño. de la red se han implementado estrategias de gestión pero. inevitablemente aun no se monitorean y se controlan todos los servicios que lo requieren. Por ello en el siguiente trabajo se hace un estudio exhaustivo de varios estándares y soluciones para la gestión de redes con el objetivo de proponer nuevas estrategias que permitan supervisar y controlar mejor las entidades de la Intranet. Como resultado se exponen las particularidades del sistema Nagios y herramientas como Nconf y NagiosGraph que elevan los niveles de prestaciones al personal encargado de la administración de la red. Se proponen y se explican la manera de implementar un sistema de gestión distribuido y un servidor de Nagios redundante..

(8) v. TABLA DE CONTENIDOS. DEDICATORIA ................................................................................................................. i AGRADECIMIENTOS ...................................................................................................... ii TAREA TÉCNICA ...........................................................................................................iii RESUMEN ....................................................................................................................... iv TABLA DE CONTENIDOS .............................................................................................. v INTRODUCCIÓN ............................................................................................................. 1 CAPÍTULO 1.. Gestión de redes de computadoras ........................................................... 5. 1.1. Arquitectura del Modelo de Gestión .................................................................... 5. 1.2. Implementaciones del modelo de gestión ............................................................ 7. 1.2.1. Sistema de administración de red para el modelo OSI .................................. 7. 1.2.2. Arquitectura de administración de red de la IEEE ........................................ 8. 1.2.3. Estructura de administración de red de Internet ........................................... 9. 1.3. Áreas funcionales de la Gestión de redes ........................................................... 10. 1.4. El modelo SNMP .............................................................................................. 11. 1.5. Estructura de la información ............................................................................. 13. 1.5.1. ASN.1 ....................................................................................................... 13. 1.5.2. Nombres de objetos ................................................................................... 14. 1.5.3. Tipo y Sintaxis .......................................................................................... 17.

(9) vi 1.5.4. Codificación .............................................................................................. 17. 1.5.5. Las MIBs .................................................................................................. 18. 1.5.6. La MIB del estándar RMON. .................................................................... 20. 1.6. Operación del protocolo SNMP ........................................................................ 21. 1.7. Versión dos de SNMP ....................................................................................... 24. 1.8. Versión tres de SNMP....................................................................................... 27. 1.9. Arquitectura para la gestión de la red ................................................................ 28. 1.10. Software de gestión ........................................................................................... 30. 1.11. Conclusiones del capítulo .................................................................................. 31. CAPÍTULO 2.. Gestión de la Intranet UCLV ................................................................. 33. 2.1. La intranet UCLV ............................................................................................. 33. 2.2. Servicios y aplicaciones de la Intranet ............................................................... 35. 2.3. Generalidades en gestión de la intranet UCLV .................................................. 36. 2.3.1. Sistema de gestión Nagios ......................................................................... 36. 2.3.2. Herramienta Munin ................................................................................... 42. 2.4. Consideraciones de seguridad ........................................................................... 45. 2.5. Necesidades actuales del sistema de gestión ...................................................... 46. 2.6. Conclusiones del Capítulo ................................................................................. 47. CAPÍTULO 3.. Propuesta de configuraciones para el sistema de gestión de los servicios y. los recursos en la intranet de la UCLV .............................................................................. 48 3.1. Configuraciones SNMP .................................................................................... 48. 3.1.1. Encuestas SNMP para el sistema de gestión .............................................. 49. 3.1.2. Configuraciones SNMP para los dispositivos de conmutación de la red ..... 51. 3.2. Visualización de comportamientos históricos a partir de gráficos ..................... 52. 3.2.1. NagiosGraph ............................................................................................. 53.

(10) vii 3.2.2 3.3. Instalación y configuración........................................................................ 54. Extensión del sistema de Gestión a los nodos secundarios de la Intranet ............ 59. 3.3.1. Gestión distribuida .................................................................................... 60. 3.3.2. Configuración de los servidores distribuidos ............................................. 62. 3.3.3. Configuración del servidor Central ............................................................ 63. 3.3.4. Autonomía de la gestión distribuida........................................................... 63. 3.4. Alternativas de configuración vía web ............................................................... 65. 3.4.1. Nconf ........................................................................................................ 65. 3.4.2. Proceso de instalación de Nconf. ............................................................... 66. 3.4.3. Configuración de Nconf ............................................................................ 68. 3.5. Servidor de gestión redundante ......................................................................... 69. 3.5.1 3.6. Modo de trabajo ........................................................................................ 70. Conclusiones del capítulo. ................................................................................. 71. CONCLUSIONES ........................................................................................................... 72 RECOMENDACIONES .................................................................................................. 74 REFERENCIAS BIBLIOGRÁFICAS .............................................................................. 75 ANEXOS ......................................................................................................................... 77 Glosario ........................................................................................................................... 81.

(11) INTRODUCCIÓN. 1. INTRODUCCIÓN. El vertiginoso avance tecnológico ha experimentado un notable desarrollo en el área de los sistemas computacionales permitiendo una interacción casi imprescindible del hombre con las computadoras. Muchos usuarios han hecho de ellas sus instrumentos de trabajo, medios para la investigación, para la producción y en especial para la comunicación.. Con la misma rapidez que se han modificado las computadoras como estaciones de trabajo o como complejos sistemas que dan soporte a otras tareas, han ido creciendo las redes de telecomunicaciones. En la década de los 70 las características de estas permitían tan solo contar con redes. centralizadas, de muy bajas velocidades de transmisión y de modo. asincrónico. Ya en los años 80 con la aparición de los microprocesadores, el aumento del número de microcomputadoras y la aparición de nuevas tecnologías para las redes de enlace, como los circuitos de tipo T, posibilitaron la difusión de redes LAN (Local Area Network, Redes de Área Local) y el escalamiento a redes distribuidas.. Las redes WAN (Wide Area Network, Redes de Área Amplia) se han visto favorecidas por la aparición y desarrollos de tecnologías subyacentes como ATM (Asynchronous Transfer Mode, Modo de Transmisión Asincrónico), SMDS (Switched Multimegabit Data Service), y Frame Relay que permiten la transmisión de grandes flujos de datos y la conexión a nivel mundial de todas las pequeñas redes.. La mayoría de las redes LAN sustentan aplicaciones de uso muy difundido para el hombre y su vida cotidiana. Entre ellas están el correo electrónico, la transferencia de ficheros, el.

(12) INTRODUCCIÓN. 2. acceso a información desde una estación remota, el almacenamiento y consulta de archivos, y servicio de mensajería instantánea. Para suministrar de manera constante todos estos servicios y mantener satisfechos a los usuarios, no basta con tan solo contar con recursos de hardware de última generación, es necesario tener una buena planificación, supervisión, configuración y monitoreo de estos. Por las razones anteriormente expuestas y por cuestiones económicas se le presta gran atención a la gestión de redes. Este es un tema que se ha desarrollado históricamente al mismo paso que las propias redes, y se han creado con este objetivo múltiples sistemas y plataformas que permiten la administración sobre los más heterogéneos dispositivos y software, asegurando así el óptimo aprovechamiento de los recursos físicos y lógicos.. La Intranet de la universidad, constituida por la interconexión de más de 3000 computadoras, se ha convertido en el soporte de estos múltiples servicios, utilizados por alrededor de 13 000 usuarios. Un grupo de personas especializadas en el tema se encarga de crear e implementar soluciones para sustentar el buen estado de todas las aplicaciones de la Intranet, para lo cual se han desarrollado ya varios trabajos investigativos que han arrojado como resultado, nuevas estrategias que optimizan en ciertos sentidos el funcionamiento de la red. A pesar de las prestaciones que se han logrado, el sistema de gestión actual presenta irregularidades que devienen en problemas a los cuales hay que darle solución. En presencia de esta problemática surgen las interrogantes científicas siguientes: ¿Cuál es la situación actual en el desarrollo de soluciones de gestión implementadas en la red UCLV? ¿Qué necesidades en materia de gestión de la Intranet fundamentan la búsqueda de nuevas soluciones? ¿Cuáles serían las posibles herramientas de software y configuraciones a analizar en pruebas pilotos? ¿Cuál sería la propuesta final de infraestructura de gestión para la Intranet?.

(13) INTRODUCCIÓN. 3. Para darle solución a estas interrogantes se ha desarrollado la presente investigación donde se persigue proponer nuevas soluciones que ayuden a mejorar la gestión de los recursos de red y los servicios de la Intranet de la UCLV. Dicha tentativa se traduce en los siguientes objetivos específicos:. 1. Hacer un estudio teórico sobre gestión de redes en cuanto a los conceptos, estándares y consideraciones para su implementación. 2. Conocer las particularidades de los servicios, aplicaciones y la plataforma de gestión de la Intranet. 3. Determinar las deficiencias del Sistema de Gestión actual. 4. Evaluar y elegir varias de las estrategias y herramientas de gestión de redes que más se adecuen a la Intranet. 5. Hacer pruebas de implementación de aplicaciones de gestión (Software) a pequeña escala, basadas en los estudios preliminares, para analizar los resultados y concretar la propuesta final para la Intranet.. De la presente investigación se ha. elaborado un informe que aporta toda los datos. necesaria para llegar a comprender y aplicar los resultados. La estrutura del mismo está formada por la introducción, el curpo de tres capítulos, conclusions, recomendaciones, referencias bibliográficas y anexos.. El capítulo uno se dedica al análisis de la información necesaria para comprender los conceptos y principios de la gestión de redes. Se dedica a introducir los estándares (protocolos) y el estado del arte en general. En esta parte se demuestra la relativa madurez y estabilidad alcanzada en el tema, se resalta el hecho de que existe una base sólida para lograr la implementación e interoperatividad de una plataforma de gestión.. En el capítulo dos se realiza una discusión panorámica del campo de estudio, en este caso la Intranet UCLV, se da una sintetizada reseña histórica de su evolución, su estructura y.

(14) INTRODUCCIÓN. 4. topología actual. Se describen detalladamente los servicios que esta soporta y se enfatiza en aquellos que necesitan más una solución de gestión y se caracteriza al sistema de gestión existente.. El capítulo tres. presenta detalladamente los sistemas y/o herramientas elegidas, los. resultados alcanzados en las pruebas hechas con ellos, y se presenta la propuesta de nuevas configuraciones al sistema de gestión.. Finalmente en las conclusiones se alistan los resultados más relevantes del trabajo y se hacen recomendaciones que se creen prudentes y necesarias para darle un uso apropiado a estos resultados o para ampliar el conocimiento en el tema..

(15) CAPÍTULO 1. Gestión de redes de computadoras. 5. CAPÍTULO 1. Gestión de redes de computadoras. La. gestión de una red comprende la administración de los diferentes recursos que la. constituyen. Para ello se basa en la supervisión, la obtención de información y el control de los dispositivos inteligentes que la conforman, cuyo objetivo fundamental es asegurar un óptimo funcionamiento de la red como un todo y en especial de los servicios que esta brinda a los usuarios finales.. La gestión asegura la operatividad necesaria entre las. subredes que se interconectan bajo un mismo dominio. Para el aseguramiento de esta tarea se usan múltiples herramientas, sistemas, y técnicas que minimizan la carga de trabajo del personal encargado. (Abeck, 2008) 1.1. Arquitectura del Modelo de Gestión. Para llevar a cabo las diferentes tareas que comprenden la gestión de una red, es necesario conocer primeramente los elementos de un sistema de gestión y la relación entre ellos. Estos elementos se definen en el modelo conocido como modelo administrador/agente (manager/agente model) que está integrado por el sistema administrador (gestor), sistema administrado, la base de datos de la información de administración y un protocolo de comunicación. En la figura 1.1 se presenta dicho modelo..

(16) CAPÍTULO 1. Gestión de redes de computadoras. 6. Sistema Administrado. Sistema Administrador comandos. Proceso Gestor. Proceso Agente respuestas. MIB. MIB notificaciones. Objetos Administrables. Objetos Administrables. Figura 1.1 Modelo del sistema de gestión.. El sistema administrador brinda una interfaz entre el usuario y el dispositivo que está siendo administrado, provee además un proceso gestor que desarrolla tareas tales como el tratamiento de tráfico en algún segmento de una red LAN, o chequea las velocidades de transmisión de un puerto de entrada y/o salida de un enrutador (ruter). Este componente del modelo también incluye algún tipo de salida, usualmente gráfica para mostrar datos. Un ejemplo muy común de ello es un mapa que muestre la topología de una parte de la red. (Soriano, 2008). El sistema administrado está integrado por un proceso nombrado agente y los objetos administrados. El agente realiza operaciones como la modificación de parámetros a los objetos administrados, que residen en los equipos o entidades a los cuales controla dicho agente, tales dispositivos pueden ser estaciones de trabajo, servidores, conmutadores y concentradores (hubs), entre otros equipos de comunicación. (Soriano, 2008).

(17) CAPÍTULO 1. Gestión de redes de computadoras. 7. La base de datos de información de administración es conocida como MIB (management information base), y está asociada tanto al sistema administrador como al sistema administrado. La MIB tiene la estructura de una base de datos numérica, que permite el almacenamiento y tratamiento de datos, la MIB tiene una organización bien definida. Esta organización lógica es conocida como SMI (structure of management information). (Soriano, 2008). El protocolo de administración de red dicta la manera en que se comunican el sistema administrador, los objetos administrados y el agente. Para estructurar el proceso de comunicación, el protocolo define mensajes específicos. Los posibles mensajes son comandos, respuestas y notificaciones. El administrador usa estos mensajes para solicitar determinada información contenida en la MIB del dispositivo administrado y el agente los usa para responder a dichas solicitudes. (Soriano, 2008) 1.2. Implementaciones del modelo de gestión. Con la estructura del modelo de gestión, se han realizado diferentes implementaciones que en menor o mayor cuantía han sido adoptadas por los disímiles vendedores de dispositivos y equipos de redes de computadoras. Tales implementaciones son: el sistema de administración de red para el modelo OSI (Open Systems Interconnection); la arquitectura de administración de red de la IEEE (Institute of Electrical and Electronics Engineers); y la estructura de administración de red de Internet. (Miller, 1997). 1.2.1 Sistema de administración de red para el modelo OSI La estructura del modelo OSI de gestión, define los roles de cada una de las componentes que lo forman. En la literatura, se divide el ambiente OSI de gestión en tres submodelos: 1- Modelo Organizacional 2- Modelo Informacional 3- Modelo Funcional.

(18) CAPÍTULO 1. Gestión de redes de computadoras. 8. El modelo organizacional usa el concepto de dominio de administración, e indica que un sistema de gestión esta compuesto por un dominio de administración que incluye, uno o varios sistemas de administración, uno ovarios sistemas administrados y que cada sistema administrado incluye, uno o varios objetos administrables. Cada objeto administrable puede ser controlado por uno o varios sistemas administradores del dominio en cuestión. (Miller, 1997). El modelo Informacional define la estructura de la información de administración y la estructura de la base de datos de la información de administración (MIB). Los objetos que comparten características similares se agrupan en clases en una estructura en forma de árbol. En este árbol cada objeto representa una entrada, donde cada entrada tiene atributos y valores bien definidos. (Miller, 1997). El modelo Funcional define cinco áreas de trabajo a las cuales se dedica la gestión de redes en forma generar y su mayor aporte ha sido desde el punto de vista conceptual ya que estas aéreas son usadas por otras implementaciones del modelo de sistema de gestión.. 1.2.2 Arquitectura de administración de red de la IEEE El estándar de gestión de la IEEE para redes LAN y MAN usa el protocolo CMIP (Common Management Information Protocol) definido por la ISO para el trabajo con las capas superiores a la capa de enlace de datos. Esta arquitectura incluye además tres elementos nuevos que complementan su trabajo con los elementos mencionados para el estándar anterior. Estos nuevos elementos son: los servicios de administración (LAN/MAN Management Service, LMMS), las entidades de administración de protocolo (LMMPE, LAN/MAN Management Protocol Entity), y las entidades de convergencia del protocolo de administración (CPE,Convergence Protocol Entity). (Miller, 1997).. En comparación con el estándar de la ISO este tiene la ventaja que el protocolo CMIP se corre directamente sobre una subcapa de la capa de enlace por lo que no son necesarias.

(19) CAPÍTULO 1. Gestión de redes de computadoras. 9. tantos requerimientos de memoria para la instalación de los agentes, pero con la desventaja de que al perder muchas de las funcionalidades de las capas superiores, no se puede implementar el estándar en la red de redes. (Miller, 1997). 1.2.3 Estructura de administración de red de Internet A diferencia de los modelos anteriores, la implementación de este modelo adoptado para la Internet, surge como la necesidad de tener control sobre la creciente Internet y otras redes subyacentes sin un estudio teórico anterior de sus detalles antes de su implementación.. En la década de los ochenta la IAB (Internet Activities Board) orientó sus investigaciones a tres propósitos fundamentales. Estos fueron: Los sistemas de administración de entidades de alto nivel (HEMS), un sistema basado en el estándar de la ISO usando CMIS (Common Management Information System) y CMIP, y una extensión al existente SGMP (Simple Gateway Monitoring Protocol).De aquí surgieron dos soluciones, la primera fue obtenida de cambios y extensiones del SGMP que dieron origen al SNMP (Simple Network Management Protocol). La segunda fue derivada de los estándares CMIS y CMIP y dio origen al termino CMOT (Common Management Information Protocol over TCP/IP). (Miller, 1997). El SNMP esta basado en el modelo administrador /agente de la figura 1.1. Se refiere a este protocolo como simple, porque el agente requiere un mínimo de software para realizar sus funciones mientras que la mayor carga computacional y de almacenamiento reside en el sistema administrador. Además el protocolo solo cuenta con un número pequeño de comandos y respuestas con los cuales se realizan todas las operaciones necesarias sobre los objetos administrados. (Miller, 1997). Dentro del modelo de referencia TCP/IP, este es un protocolo de aplicación, lo que brinda ciertas ventajas en comparación con otros protocolos de administración que funcionaban a nivel de enlace. En este caso el protocolo se puede diseñar sin observar el hardware de red.

(20) CAPÍTULO 1. Gestión de redes de computadoras. 10. subyacente, las facilidades que brinda el protocolo pueden usarse para todos los dispositivos de administración y los administrables. Con esto se consigue una determinada uniformidad sobre la red, ya que todos los equipos responden a un mismo conjunto de comandos, además como el software de administración usa IP para comunicarse, se pueden controlar enrutadores y dispositivos que no estén conectados directamente al hardware administrador. (Tannenbaum, 2002). 1.3. Áreas funcionales de la Gestión de redes. Para cualquiera de las implementaciones, las tareas se realiza un sistema de gestión están orientadas dentro de una de las siguientes áreas funcionales (Group, 1994): 1- Gestión de fallas (Fault management) 2- Gestión de configuración (Configuration management) 3- Gestión de contabilidad (Accounting management) 4- Gestión de desempeño (Performance management) 5- Gestión de seguridad (Security management). La gestión de fallas son las cuestiones relacionadas con la detección, el diagnóstico y la reparación de algún comportamiento anormal en los servicios o dispositivos de red. Para ello el sistema brinda algún tipo de notificación o alerta. (Group, 1994). La gestión de configuración tiene como objetivo tener un control total sobre los cambios que se hacen a los parámetros que determinan la forma de funcionamiento de un servicio o dispositivo. Aquí se tienen en cuenta alarmas del sistema cuando se accede a los datos de inicialización de un dispositivo, recolección y cambios de la información de configuración. (Group, 1994). La gestión de contabilidad consiste en las actividades de recolección de información relacionada con el uso de los recursos de red. También incluye tareas como el.

(21) CAPÍTULO 1. Gestión de redes de computadoras. 11. establecimiento de cotas y capacidades, para compartir los recursos y la supervisión, para que no se sobrepasen limites preestablecidos por los administradores de sistema. (Group, 1994). La gestión de desempeño se encarga de ordenar y evaluar información del comportamiento de los servicios y dispositivos en un orden temporal. Esto se hace bajo condiciones normales de trabajo de la red y también en condiciones de anomalías. Estas tareas ayudan a construir modelos estadísticos de comportamiento con los cuales se pueden determinar las condiciones óptimas de trabajo de la red. Esto ayuda en muchos casos a determinar cuando se está cerca de la ocurrencia de fallas. (Group, 1994). La gestión de seguridad se encarga de dos aspectos fundamentales, uno es lograr la integridad de los recursos físicos y lógicos de la red. Esto incluye la implementación de herramientas de seguridad tales como sistemas de detección de intrusos, sistemas de prevención de intrusos, antivirus y firewall entre otros. El segundo aspecto se encarga de la propia seguridad del sistema de gestión, esto incluye la autentificación de los usuarios y aplicaciones que acceden a la información de gestión. (Group, 1994). 1.4. El modelo SNMP. El modelo SNMP fue introducido en 1988 como un estándar de Internet, desde entonces se le han echo modificaciones que han fortalecido su estructura. Su implementación se ha generalizado en los equipos de múltiples vendedores y actualmente es la solución más difundida en la gestión de redes de computadoras. Aunque su uso es más conocido en dispositivos de red, como enrutadores (ruters), conmutadores (switches), y las propias computadoras, este puede ser usado para administrar cualquier dispositivo que incluya un software capaz de tratar información de administración. Comercialmente se ha incluido en racks de módems, fuentes de alimentación, impresoras entre otros. (Mauro, 2005).

(22) CAPÍTULO 1. Gestión de redes de computadoras. 12. El estándar SNMP fue definido por el IETF (Internet Engineering Task Force) y como protocolo forma parte del stack de protocolos TCP/IP, actualmente va por la versión tres y la documentación correspondiente esta archivada en más de una veintena de RFCs (Request for Comments).. La primera versión del estándar es ya historical pero muchas de las partes de las demás versiones no son más que mejoras hechas a esta, por lo que es de marcada importancia entender cada detalle de esta versión. Además fue la primera versión que se implementó por los vendedores, sus mecanismos de seguridad están basados en password con los que se definen diferentes grupos a los que se les otorgan privilegios sobre la información de gestión. Esta es aún la versión más difundida del estándar. Esta versión inicial está definida en la RFC 1157. (Mauro, 2005). La segunda versión usa similares mecanismos de seguridad que la primera, los principales aportes de esta versión son la creación de nuevos tipos de objetos administrables, nuevas convenciones en la representación textual y nuevas operaciones del protocolo. Esta versión esta definida fundamentalmente en las RFC 3416, RFC 3417 y RFC 3418.. La tercera versión es desde 1992 un full standar pero a pesar de ello no es muy popular aun. Sus principales aportes son cuestiones relativas a la seguridad. Las RFCs que contienen la definición de las distintas partes del estándar son las siguientes: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418 y RFC 2576.. SNMP en su versión uno y dos usa el término “comunidades SNMP”. Las comunidades SNMP son la manera de establecer un mecanismo de autenticación entre los agentes y los sistemas administradores. Las tres posibles comunidades son read-only, read-write y trap con las cuales se configuran un agente en un dispositivo; en la práctica las comunidades son password. Cada comunidad garantiza un determinado número de operaciones. Pertenecer a.

(23) CAPÍTULO 1. Gestión de redes de computadoras. 13. la comunidad read-write de un agente da la posibilidad de leer información de gestión y además modificarla con nuevos valores. Cuando desde un sistema administrador se envía un mensaje a un agente este password viaja en el mensaje en texto plano lo que significa un gran riesgo para la seguridad del sistema. Por esta razón es aconsejable configurar a cada agente para que envíe una notificación cada vez que haya un intento acceder a él desde cualquier sistema remoto. (Mauro, 2005). 1.5. Estructura de la información. La estructura de la información de administración (SMI, structure of management information) es la parte del estándar que define las reglas a seguir para la identificación de los objetos administrables que residen en un agente, de manera que estos sean físicamente accesible. También se debe garantizar que la información sea lógicamente accesible, esto significa que la información pueda ser retribuida y modificada por el gestor o sistema administrador. Para asegurar la accesibilidad lógica la SMI plantea que cada objeto esta compuesto por un nombre, un tipo de objeto y. sintaxis, y una codificación. Las. recomendaciones sobre SMI están descritas fundamentalmente en la RFC 1155, RFC 1212 y RFC 1215. (Mauro, 2005). 1.5.1 ASN.1 Para que sea posible la comunicación entre un agente y un administrador. existe un. consenso en la representación de los datos que conforman la información de gestión de manera que ambas partes entienden los datos; para lograr esto, la SMI de Internet plantea el uso de ASN.1 (Abstract Syntax Notation One). (Miller, 1997). En las definiciones de la ASN.1 se exponen dos conceptos importantes: sintaxis abstracta (abstract syntax) y sintaxis de transferencia (transfer syntax). El primero de los términos define la estructura de los datos almacenados, brinda un lenguaje de descripción del formato de los mensajes dentro de una máquina, con sus posibles componentes y las.

(24) CAPÍTULO 1. Gestión de redes de computadoras. 14. posibles combinaciones de estas componentes. El segundo término define como debe ser la codificación de los elementos de la abstract syntax para que estos sean transmitidos por la red. (Miller, 1997) Aunque el estándar es muy difícil de entender para los usuarios, por su complejidad; este ofrece un método robusto para el tratamiento de la información sin ambigüedad alguna. ASN.1 define sus tipos de datos como un conjunto de bits mediante un lenguaje de alto nivel. Los posibles datos son enteros (intergers), cadena de caracteres (strings) o combinaciones de estos dos. La representación de los datos según el estándar es independiente de la forma que la máquina los representa en la memoria física. Las reglas básicas de codificación (BER) dictan la manera de convertir los datos en un arreglo de bits para la transmisión ya que la forma en que estos se definen en el lenguaje de alto nivel es una forma legible solo para el usuario. ASN.1 usa algunos términos y palabras reservadas los cuales hay que conocer para poder interpretar la descripción de un objeto. (Millar, 1997). 1.5.2 Nombres de objetos Cada objeto administrable, así sea un dispositivo físico o una característica de este, tiene un identificador (OID, Object Identified) único. El esquema de nombres usado por Internet para el modelo SNMP se deriva de una jerarquía de nombres en forma de árbol. El identificador de cada objeto se escribe como una serie de números separados por puntos y es la forma en que cada objeto se representa dentro de un agente. Cada número corresponde al nodo del nivel suprior. Otra forma de nombrar cada objeto es poner el nombre de cada nodo separado por el carácter punto (.). En la figura 1.2 se muestra una parte de de esta jerarquía, donde se omiten algunas ramas del árbol ya que estas no conciernen al modelo SNMP de Internet..

(25) CAPÍTULO 1. Gestión de redes de computadoras. 15. Nodo-Raíz. iso(1). ccitt(0). joint(2). org(3). dod(6). Internet(1). directory(1). mgmt(2). experimental(3). private(4). Figura 1.2 Identificadores de Objetos (OID) en estructura de árbol. Como se muestra en la figura todas las ramas se derivan de un nodo que se conoce como nodo raíz (root), de los tres nodos del segundo nivel solo interesan los objetos que se derivan del nodo iso pues en las ramas subyacentes se encuentran los objetos administrados con SNMP. Cada nodo tiene un equivalente numérico para el caso de iso le corresponde el numero uno. En la misma figura se muestran en el último nivel los objetos directory(1), mgmt(2), experimental(3), y private(4). Todos se derivan de internet(1) cuyo identificador (OID) es iso.org.dod.internet o de la forma numérica 1.3.6.1. La rama directory(1), está en desuso. La rama experimental experimental(3) se usa para propósitos investigativos. La rama. private(4) contiene los objetos creados por distintas. organizaciones o empresas comerciales, un objeto derivada de esta rama es enterprise (1) donde se le da la posibilidad a los vendedores de definir sus propios objetos. (Mauro, 2005).

(26) CAPÍTULO 1. Gestión de redes de computadoras. 16. En la rama management o mgmt(2) es donde se encuentran definidos la mayoría de los objetos estándares que se administran en la Internet. La forma en que se definen estos objetos usando el lenguaje ASN.1 es la siguiente: internet. OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }. directory. OBJECT IDENTIFIER ::= { internet 1 }. mgmt. OBJECT IDENTIFIER ::= { internet 2 }. experimental OBJECT IDENTIFIER ::= { internet 3 } private. OBJECT IDENTIFIER ::= { internet 4 }. En la definición de mgmt lo que significa “{internet 2}” es que el objeto mgmt es el nodo dos que se deriva del nodo superior internet. De la misma manera un objeto se puede definir usando el equivalente numérico: sysDescr OBJECT IDENTIFIER ::= { 1.3.6.1.2.1.1.1 }. Además de definir un objeto con su identificador es necesario agregar un sufijo al final del nombre para hacer alusión a la instancia del objeto. Por ejemplo en el caso de la variable u objeto que se definió anteriormente, como sysDescr, se hizo referencia a la descripción del dispositivo que se está administrando, la descripción del dispositivo es única, o sea una variable escalar. Por lo tanto para referirnos a ella al final del OID se agrega el sufijo punto cero (.0) para indicar que la variable ocurre una sola vez, y queda de la manera siguiente: {1.3.6.1.2.1.1.1.0.}. Hay objetos que no son escalares, como una tabla formada por varias columnas. En este caso habría que poner un sufijo que indicara a que instancia de la variable tabla se hace referencia. Algunos de los sufijos pueden ser “.1, .2, un número IP” entre otros. Al conjunto OID + sufijo se le conoce como nombre de variable..

(27) CAPÍTULO 1. Gestión de redes de computadoras. 17. 1.5.3 Tipo y Sintaxis La sintaxis puede verse como la manera de representar cada objeto mediante una serie de líneas de código escritas en ASN.1. Para referirse a un objeto siempre se sigue la estructura siguiente: Nombre del Objeto OBJECT-TYPE SYNTAX Tipo de dato ACCESS Interacción STATUS Da la vigencia ::= { El OID }. El nombre del objeto está definido en las distintas bases de datos. El ACCES caracteriza la interacción sobre el objeto. Las opciones son read only, Read-write, write-only, además puede que el objeto sea también not-accessible. En el caso del STATUS las posibilidades son mandatory, optional, obsolete, y deprecated. El tipo de objeto no es más que la forma de especificar cual es el contenido de la información que cada objeto retiene. Existen tres clases de tipos de datos, los primitivos (primitive), los constructores (Constructor), y los definidos (Defined). (Mauro, 2005). 1.5.4 Codificación En caso de que una máquina (host) o cualquier otro dispositivo administrable necesiten transmitir información de gestión a través de la red, luego de ubicar internamente los datos a enviar, se prosigue a estructurar estos de manera que puedan viajar por el medio físico, llegar al receptor y ser interpretado su contenido de manera correcta. Para que esto sea posible se usan reglas básicas de codificación (BER). (Stalling, 1998). Las BER que define el estándar para la representación externa de la información de gestión se conocen como codificación de tipo-longitud-valor (Type-Length-Value encoding). Primeramente se define que en cada octeto primero se transmite el bit más significativo.

(28) CAPÍTULO 1. Gestión de redes de computadoras. 18. (MSB) al que se le asigna el numero ocho, por último el bit menos significativo (LSB) como el número uno. La cadena de bits codificada, está formada por tres campos: tipo, longitud y valor.. El campo tipo consiste en el primer octeto de la estructura, se divide en tres subcampos, y brinda todos los datos necesarios para que el receptor sepa como interpretar los datos. Los dos primeros bits (7 y 8) especifican la clase (class) y las opciones son Universal, Application-wide, Context-specific y Private use. El bit seis (P/C) especifica si los datos son Primitivos o Constructores. Los restantes cinco bits constituyen el subcampo número de etiqueta (Number of Tag). El valor que tiene el Número de Etiqueta depende de la clase que se especifique en el subcampo Clase; o sea primero se especifica la clase del tipo de datos y luego con. el valor de la etiqueta se especifica si el dato es INTERGER,. SEQUENCE, OBJECT IDENTIFIER o el que corresponda. Si la clase que se especifica es Context-specific entonces el valor del Número de Etiqueta especifica uno de los cinco mensajes que el SNMP usa para su operación. (Stalling, 1998). 1.5.5 Las MIBs Las bases de datos de administración ( MIB,Management Information Bases) son grupos de objetos administrables, que se definen bajo un mismo nodo en la jerarquía de nombres de objetos y caracterizan a un propietario en específico o a un área de trabajo. Existen muchos tipos de MIBs, algunas de ellas como los estándares de Internet son públicas, otras son privadas y se implementan solo en los productos del vendedor propietario. (Mauro, 2005). Un agente es capaz de almacenar información de todos los objetos que pertenezcan a la MIB que el atienda. En la mayoría de los casos un agente tiene más de una MIB bajo su poder por lo que es muy amplio el número de variables de los que puede retribuir información. Como es tan amplia la cantidad de MIBs es posible que en algún caso una entidad gestora pida información a algún agente de un objeto que no sea reconocido por este último, en este caso se devuelve un mensaje de error..

(29) CAPÍTULO 1. Gestión de redes de computadoras. 19. Dentro de las múltiples implementaciones de MIBs, la MIB-II definida en la RFC 1213, es de necesario conocimiento ya que esta está soportada por todos los agentes que usan el protocolo SNMP. MIB-II contiene 171 objetos que pertenecen a los distintos grupos que se organizan de la manera que se muestra a continuación:. mgmt(2). mib-2(1). system(1). interfaces(2). at(3). ip(4). icmp(5). tcp(6). udp(7). egp(8). transmission(10). snmp(11). Figura 1.3 Estructura de la MIB-II.. Cualquiera de estos grupos comienza con el OID {1.3.6.1.2.1} que heredan de MIB-II y se identifican de la manera siguiente: mib-2. OBJECT IDENTIFIER ::= { mgmt 1 }. system. OBJECT IDENTIFIER ::= { mib-2 1 }. interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at. OBJECT IDENTIFIER ::= { mib-2 3 }. ip. OBJECT IDENTIFIER ::= { mib-2 4 }. icmp. OBJECT IDENTIFIER ::= { mib-2 5 }. tcp. OBJECT IDENTIFIER ::= { mib-2 6 }. udp. OBJECT IDENTIFIER ::= { mib-2 7 }. egp. OBJECT IDENTIFIER ::= { mib-2 8 }. transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp. OBJECT IDENTIFIER ::= { mib-2 11 }.

(30) CAPÍTULO 1. Gestión de redes de computadoras. 20. Desde el punto de vista práctico es muy importante chequear los parámetros lógicos y físicos de una computadora, en especial si esta da soporte a algún servicio destinado a los usuarios. Para esto se implementó la MIB Host Resources MIB que define los siguientes grupos: host. OBJECT IDENTIFIER ::= { mib-2 25 }. hrSystem. OBJECT IDENTIFIER ::= { host 1 }. hrStorage. OBJECT IDENTIFIER ::= { host 2 }. hrDevice. OBJECT IDENTIFIER ::= { host 3 }. hrSWRun hrSWRunPerf. OBJECT IDENTIFIER ::= { host 4 } OBJECT IDENTIFIER ::= { host 5 }. hrSWInstalled OBJECT IDENTIFIER ::= { host 6 }. Cada uno de estos grupos contiene objetos que caracterizan estados o funciones de una estación de trabajo. Por ejemplo en hrSystem se recolecta información propia del sistema en cuestión como la fecha y hora, el número de usuarios en el sistema y los procesos que se están ejecutando. (Mauro, 2005). 1.5.6 La MIB del estándar RMON. El término RMON (Remote Monitoring) significa monitoreo remoto. En el tema de la gestión de redes RMON es un estándar que se define en la RFC 2819 en su versión uno (RMONv1) y que luego es mejorado por una nueva versión que se definió en la RFC 2021 y conocido como RMON Versión 2 (RMONv2). Este estándar brinda determinadas funciones que permiten a un sistema gestor contar con estadísticas a nivel de paquetes acerca del funcionamiento de la red como un todo, o de un segmento de esta. Para que esto sea posible es necesario que algunos dispositivos de red como enrutadores y conmutadores exporten dichas funcionalidades. En caso de que así sea la MIB RMON fue diseñada para almacenar información sobre el comportamiento de estas estadísticas de red para que estas sean luego encuestadas. (Stalling, 1998; Mauro, 2005).

(31) CAPÍTULO 1. Gestión de redes de computadoras. 21. La RMON MIB se define de la manera siguiente: rmon. OBJECT IDENTIFIER ::= { mib-2 16 }. statistics. OBJECT IDENTIFIER ::= { rmon 1 }. history. OBJECT IDENTIFIER ::= { rmon 2 }. alarm. OBJECT IDENTIFIER ::= { rmon 3 }. hosts. OBJECT IDENTIFIER ::= { rmon 4 }. hostTopN matrix filter. 1.6. OBJECT IDENTIFIER ::= { rmon 5 } OBJECT IDENTIFIER ::= { rmon 6 } OBJECT IDENTIFIER ::= { rmon 7 }. capture. OBJECT IDENTIFIER ::= { rmon 8 }. event. OBJECT IDENTIFIER ::= { rmon 9 }. Operación del protocolo SNMP. El SNMP es un protocolo de la capa de aplicación, que usa el protocolo UDP de la capa de transporte, por lo que la comunicación entre el gestor y el agente es no orientada a la conexión, los mecanismos de control de error quedan sujetos a la aplicación, este problema se resuelve con un tiempo de espera y la retransmisión de los mensajes. El tiempo de espera y el número de retransmisiones son configurables. La comunicación se realiza a través de los puertos 161 y 162. (Miller, 1997). Algunos dispositivos como los ruters aunque no tienen integrados las funcionalidades de la capa de aplicación, son capaces de interactuar con el modelo SNMP e implementar las facilidades de este protocolo. Para esto basta con que el procesador físico del dispositivo sea capaz de correr el software que actúe como agente. Los distintos módulos del software agente que realicen funcionalidades distintas se conocen como entidades del protocolo..

(32) CAPÍTULO 1. Gestión de redes de computadoras. Las distintas operaciones SNMP se realizan mediante. el intercambio de. 22 mensajes. conocidos como PDU (Protocol Data Unit), los cuales usan los nombres de variables (OID + sufijo) para la búsqueda y obtención de valores de los objetos.. Los mensajes SNMP se encapsulan en los datagramas UDP. En el encabezado UDP se indica que el contenido de su área de dato es un mensaje SNMP lo que permite identificar el software que procesará este en el extremo receptor.. Los mensajes del protocolo se dividen internamente en dos partes, la primera parte es un encabezado de autenticación que está compuesto por un identificador de la versión y la comunidad y seguido de esto se encuentran los PDUs.. Figura 1.4 Formato de los mensajes SNMP..

(33) CAPÍTULO 1. Gestión de redes de computadoras. 23. El campo Comunidad es un dato de tipo OCTEC STRING. Antes de procesar el mensaje el agente comprueba si el tipo de comunidad más el número IP de donde proviene el mensaje coinciden con la información que el tiene almacenada al respecto en su archivo community profile; en caso de no coincidir se detiene el procesamiento del mensaje y se envía al gestor la notificación del suceso. Esto último es intento fallido de autenticación.. Los posibles tipos de PDU definidos en la versión uno de SNMP (SNMPv1) son los siguientes: GetRequest, GetNextRequest, GetResponse, SetRequest y Trap. Los cuatro primeros tienen una misma estructura dentro de una trama, pero los Traps cuentan con una estructura única diferente. (Miller, 1997). El mensaje GetRequest lo genera el gestor para solicitar el valor de algún objeto que pertenece a un agente determinado. El mensaje GetResponse lo genera un agente para responder a un mensaje GetRequest en el cual devuelve el valor del objeto que se le solicito. El mensaje GetNextRequest se usa para cuando queremos solicitar los valores de una lista de objetos que se encuentran uno a continuación de otro, el caso típico son los objetos de una tabla. El mensaje SetRequest lo utiliza el sistema administrador (gestor) para otorgar o cambiar el valor de algún objeto que resida en un agente. (Miller, 1997). Los tipos de mensajes anteriores son la manera de operar el gestor sobre un agente. El agente siempre es quien espera por el puerto 161 algún tipo se solicitud o de comando del gestor. Las traps por otra parte son mensajes que usa un agente para notificar al gestor la ocurrencia de algún evento especificado con anterioridad. Estos se pueden generar de manera inesperada y el gestor recibe estos mensajes por el puerto 162. Algunos de las situaciones que se pueden informar mediante traps son el estado de fuera de servicio de una interfaz de red, el retorno de esta a su estado normal, la caída de algún servicio, intentos fallidos de autenticación de alguna entidad, estas, entre otras muchas anomalías. (Miller, 1997).

(34) CAPÍTULO 1. Gestión de redes de computadoras. 24. El sistema administrador (gestor) se auxilia de los diferentes mensajes (PDUs) para a través de la red demandar información sobre los objetos administrados. Estos objetos tienen un identificador único definido mediante la SMI (structure of management information). Los objetos pueden ser estados de una tarjeta de red, capacidad de un disco duro, números de paquetes entrantes o salientes de un puerto o tiempo que ha pasado desde que se inició un sistema, entre otros. Estos objetos se manejan como variables con sus correspondientes valores, y todos residen almacenados de forma organizada dentro del objeto superior MIB (management information base). Cada agente puede contener una MIB o muchas de ellas. Los gestores además de encuestar de manera remota los valores de estas variables, los puede cambiar. (Miller, 1997). En lo adelante se analizaran brevemente versiones nuevas del estándar SNMP y los cambios que estas plantean al esquema formulado hasta aquí.. 1.7. Versión dos de SNMP. La segunda versión hace una extensión del esquema de nombres para definir nuevos objetos. Aunque en un inicio se definieron dos nuevas ramas al nodo Internet (la security {1.3.6.1.5} y snmpV2 {1.3.6.1.6}) con sus respectivas descendencias, la mayoría de los objetos implementados quedaron en la rama snmpModules como se muestra en la figura 1.5..

(35) CAPÍTULO 1. Gestión de redes de computadoras. 25. Internet(1) mgmt(2). mib-2(1). snmpV2(6). snmpModules(3). snmpMIB(1). snmpMIBObjects(0). Figura 1.5 Extensión de los nombres de objetos en SNMPv2.. Además de los nuevos objetos el estándar define nuevos tipos de datos para estos objetos. Los nuevos tipos de datos son Integer32, Counter32, Gauge32, Unsigned32, Counter64 y BITS. (Miller, 1997). La nueva estructura define también nuevos tipos de Traps llamados NOTIFICATIONTYPE e introduce además otras convenciones textuales que permiten crear objetos de manera más abstracta que posibilitan al usuario entender el significado de los datos. La operación del protocolo se realiza básicamente como en la primera versión. La interacción entre un agente y un gestor o entre sistemas administradores, se realiza mediante el intercambio de mensajes que contienen los PDU (protocol data unit) aunque estos pueden usar otros protocolos de transporte a diferencia de SNMPv1 que solo se soportaba en el.

(36) CAPÍTULO 1. Gestión de redes de computadoras. 26. protocolo UDP. SNMPv2 adiciona tres nuevos PDU y nuevos códigos de errores. Los nuevos PDU son GetBulkRequest (con PDU Type =5), InformRequest (con PDU Type = 6), y Report (con PDU Typeb =8).. El mensaje GetBulkRequest se usa para solicitar información de varios elementos de una tabla de una sola vez, inclusive puede ser usado para obtener información de más se una MIB en un mismo mensaje. En caso se de que no se pueda devolver toda la información por problemas de tamaño, el agente puede devolver solo parte de la respuesta. (Stalling, 1998). El mensaje InformRequest da la posibilidad a una entidad gestora enviarle información de administración a otra entidad gestora dentro de la red. El mensaje Report no está plementado en la versión dos, aunque se definió originalmente en esta versión es parte de SNMPv3. En el caso de las Traps, esta versión hace modificaciones con el objetivo de de estandarizar su formato, dando origen a los mensajes SNMPv2-Trap (SNMP Notification) con PDU Type = 7. Las Traps definidas en la primera versión con PDU Type = 4, se consideran obsoletas y en la RFC 1908 se expone con detalles la estructura de las SNMPv2Traps. (Mauro, 2005). Para hacer compatibles las dos versiones en una misma red existen dos métodos. El primero de ellos se conoce como proxy agent que es una especie de traductor que se implementa en un punto intermedio de la comunicación entre gestor y agente y permite la traducción apropiada de los PDUs para que estos sean entendidos por las entidades de ambas partes. Los mensajes de tipo GetBulkRequest se transforman en mensajes GetNextRequest. La otra solución es contar con gestores bilingües que sean capaces de elegir la versión con la que deben comunicarse con cada agente e implementar todas las funciones de ambas versiones..

(37) CAPÍTULO 1. Gestión de redes de computadoras. 1.8. 27. Versión tres de SNMP. La tercera versión del protocolo SNMP no adiciona cambios significativos a las versiones anteriores. Las principales modificaciones están asociadas a los mecanismos de seguridad que brindan una mayor protección a los sistemas de gestión. Snmpv3 crea también nuevas convenciones textuales, pero estas tienen como objetivo hacer más fácil la comprensión de los tipos de datos ya existentes. A pesar de las novedades de esta versión no es muy popular su implementación en dispositivos comerciales.. La tercera versión del protocolo define nuevos términos que están relacionados con la necesidad de asumir otra arquitectura conceptual que se asocie más a los mecanismos de seguridad. El sistema gestor y el agente son tratados simplemente como entidades SNMP que están conformadas por un controlador principal (Engine) y una o más aplicaciones. Los servicios de autenticación se basan en las comunidades usadas en las primeras versiones o en la autenticación basada en usuarios de la tercera versión (Snmpv3 Usher-basad autenticación). (Mauro, 2005). Los mecanismos implementados en la tercera versión usan los algoritmos MD5 (Mensaje Digest 5) o SHA (Escure Ash Algoritmo 1) para identificar usuarios sin enviar los password en textos planos por la red. El servicio de privacidad se realiza encriptando los mensajes SNMP usando el algoritmo DES. (Mauro, 2005). Las aplicaciones que forman parte de las entidades según el estándar, se refieren a agrupaciones de las distintas tareas que se realizan cuando se implementa el protocolo SNMP. En Snmpv3 aunque no se crea ningún nuevo PDU el formato de los mensajes tiene una nueva estructura que le permite transportar toda la información necesaria para implementar los mecanismos de seguridad..

(38) CAPÍTULO 1. Gestión de redes de computadoras. 28. Para Snmpv3 el USM (Usher-based Security Model) y VACM (View Access Control Model) especifican los detalles de los posibles niveles de seguridad y los requisitos a cumplir para implementar cada modelo. El USM se refiere a la seguridad que se le otorga a un mensaje SNMP en la red y a la información que se transporta en los distintos campos para poder identificar a cada usuario de forma inequívoca. En cada entidad SNMP (gestor o agente) existe una tabla que se llenan con datos de los usuarios que tienen acceso a estas, estos datos se comparan con los obtenidos en cada mensaje que se recibe. VACM se usa para controlar el acceso a los objetos de las MIB mediante funciones del Access Control Subsystem que usa valores de los campos msgFlags, msgSecurityModel, y scopedPDU para determinar que privilegios tiene un usuario sobre determinados objetos. (Mauro, 2005). 1.9. Arquitectura para la gestión de la red. Es importante conocer la forma en que los elementos que componen un sistema de gestión deben distribuirse en la red para lograr la mayor eficiencia posible. Algunos aspectos a tener en cuenta son la cantidad de nodos que se quieran administrar, la topología de la red, el personal encargado en estas tareas, la frecuencia con que se encuestará cada nodo, y la cantidad de información que se almacenará en cada encuesta. (Abeck, 2008). La arquitectura más simple es contar con un solo NMS (network management station) con el cual se administren todos los nodos de modo que a partir de este se tenga un control total sobre el funcionamiento de de todos los objetos administrables. Esta alternativa brinda la posibilidad de tener concentrada la información y que sea más fácil el análisis de esta para la toma de decisiones. Para una red pequeña en extensión y con pocos nodos administrables esta alternativa trabaja bien. (Abeck, 2008).

(39) CAPÍTULO 1. Gestión de redes de computadoras. 29. Cuando se cuenta con una red muy extensa y con muchos nodos administrables, tener un NMS único es realmente un problema. Los mensajes intercambiados entre cada agente y el gestor tendrían que viajar por toda la red para alcanzar su destino. Al tener que encuestar muchos nodos es imposible hacerlo con alta frecuencia para un mismo agente, por lo que pueda que ante la existencia de un problema en el extremo remoto el sistema gestor no tenga notificación de la evolución del mismo. Otra situación a destacar es que se necesitaría de mucho personal capaz de atender cada contingencia para un área tan grande. Para evitar estas situaciones lo aconsejable es tener una arquitectura distribuida. Esta consiste en tener varios NMS y que cada uno atienda los nodos administrables del área en que se encuentren. De este modo disminuyen el número de mensajes intercambiados entre agentes y gestores y puede aumentar la frecuencia de encuestas. Se pueden interconectar los NMS par el intercambio de información en caso de que fuera necesario, una alternativa recomendada es hacerlo por canales privados. (Abeck, 2008). Un aspecto de gran importancia en el tema, son la características que se deben elegir para un NMS. Los requerimientos de memoria para el almacenamiento dependen de muchos factores, pero se pueden estimar varios de ellos. Si por ejemplo se cuenta con 1000 nodos en la red y se encuesta cada uno de ellos cada un minuto, y se obtiene un 1KB de información, esto trae como resultado que se necesite una capacidad de 40 GB de disco para aproximadamente un mes. Lo que lleva a pensar que es necesario minimizar la información que se necesita tener en cada encuesta o disminuir la frecuencia con que esta se demanda. Además con mucha información para procesar se necesita de mayor tiempo de CPU para hacerlo. Otras características como la capacidad de RAM, y la velocidad del procesador dependen mucho de las características que tengan los programas que se usan como administradores por lo que es preciso hacer una elección bien detallada de estos..

(40) CAPÍTULO 1. Gestión de redes de computadoras. 30. 1.10 Software de gestión Los softwares son las herramientas que permiten al usuario tener acceso a las particularidades del protocolo de gestión, estos se encuentran en los dispositivos administrables y en la estación de administración. Las características de estos determinan en muchos casos las facilidades y vulnerabilidades del sistema de gestión que se vaya a implementar ya que no todos optimizan su funcionamiento en todas las áreas de gestión de redes.. Aunque en su mayoría estos se encuentran estructurados siguiendo el modelo cliente/agente no solo soportan SNMP ya que este estándar aunque es el más usado no logra cubrir todas las necesidades en materia de gestión, de aquí que muchos programas además de soportar SNMP, como una de sus facilidades,. utilizan otros protocolos de aplicación en sus. funciones de monitoreo. En el caso de que la entidad superpisada brinde servicios públicos de red con HTTP, SMTP, y FTP, entre otros, el software gestor se vale del propio protocolo para chequear la disponibilidad del servicio en cuestión y algunas particularidades de este. Otros métodos de supervisión se basan en el uso de ICMP, en caso más simple se usa un ping para conocer estados de conexión y RTA. En el caso de los servicios privados de una entidad, como son parámetros de funcionamiento y de estado de un hardware o de su sistema operativo, lo más común es usar el estándar SNMP, pero en muchos casos se usan protocolos propietarios del software que establecen un método particular de chequear las entidades administradas. (Misna, 2004). Los sistemas gestores más usados se componen internamente por un proceso central y varios módulos apartes conocidos como plugnis, que pueden venir o no en la misma distribución del programa. El proceso central tiene funciones típicas como brindar una interfaz visual al usuario y la graficación de parámetros. Mientras que los plugins son los encargados de la comunicación con los agentes y son los que realmente realizan las encuestas y devuelven valores al proceso central. Existen otros módulos de software conocidos como addons que son herramientas implementadas por otro desarrollador que.

(41) CAPÍTULO 1. Gestión de redes de computadoras. 31. permiten interactuar con el gestor o con los sofwares agentes y extender sus funcionalidades para mejorarlos algún sentido.. En el mercado y en la comunidad de software libre de Internet existen innumerables programas de gestión entre los cuales se podrían encontrar los que mejor se adecuen a una red determinada. Algunos programas son de uso libre y otros no, algunos ocupan un espacio del orden de los Kilobytes y otros hasta los Gigabytes, las plataformas sobre las cuales corren pueden ser muchas al igual que los lenguajes con los cuales se construyeron de aquí que la elección de cuales usar, debe realizarse teniendo en cuenta todos estos detalles. En el Anexo I se expone una lista con algunos de los gestores y agentes disponibles en Internet.. 1.11 Conclusiones del capítulo En el presente capitulo se expuso el significado de la gestión de redes de computadoras y las distintas áreas de trabajo en las que se orienta la gestión de redes. Se presentó la arquitectura de un sistema de gestión con cada una de sus partes y funciones.. De las diferentes implementaciones de esta arquitectura se enfatizó en la estructura de administración adoptada para la Internet donde el modelo SNMP es la solución más generalizada para los vendedores y la más popular entre los usuarios. Del modelo SNMP se explicó con detalles su funcionamiento y la relación de este protocolo con las diferentes capas del modelo de referencia OSI.. En las últimas secciones se brindó información sobre los disímiles softwares disponibles en el mercado y en la comunidad de software libre que implementan SNMP y otros métodos no estandarizados para administrar las redes..

(42) CAPÍTULO 1. Gestión de redes de computadoras. Con todos los aspectos tratados en el capítulo se ha brindado la información fundamentos teóricos que permitirán proseguir con la investigación.. 32 y los.

(43) CAPÍTULO 2. MATERIALES Y METODOS. 33. CAPÍTULO 2. Gestión de la Intranet UCLV. Con el primer capítulo se sentaron las bases teóricas, que permitieron comprender los principios básicos a tener en cuenta, para implementar un sistema de gestión sobre una red de manera genérica. El presente capítulo se enmarcará en una red específica, de cuyas características depende la solución que se adopte para administrar de la manera más eficiente sus recursos físicos y lógicos. La investigación en esta etapa está orientada a presentar de manera detallada los elementos que la componen y los servicios que esta soporta, para identificar los objetos que necesitan ser gestionados para un mejor desempeño de la red, de igual manera se hará una valoración exhaustiva de la solución de gestión actual para partir de aquí,. proponer los cambios necesarios y la adición de nuevas. estrategias que optimicen la plataforma de gestión existente.. 2.1. La intranet UCLV. La Universidad Central “Marta Abreu” de Las Villas (UCLV) cuenta con una red de área local con una extensión geográfica de 8Km cuadrados y está constituida por la interconexión de más de 3000 computadoras, que se distribuyen en 14 áreas dentro de las cuales se encuentran las distintas facultades y centros de investigación. La red tiene topología de estrella y el Backbone principal interconecta 2 enrutadores y 14 conmutadores que son los nodos de acceso a las distintas áreas. Estas conexiones se realizan usando principalmente fibra óptica del tipo multimodo 62.5/125 lo que en conjunto con los conmutadores permiten velocidades de transmisión de 1 Gbit/segundos. En la figura 2.1 se muestra lo explicado anteriormente, así como los nombres con los que se manejan los dispositivos que constituyen el Backbone..

(44) CAPÍTULO 2. MATERIALES Y METODOS. 34. CISCO 1005 GRU-SW. CISCO. Servidores Centrales. Redes externas FIE-SW. FCE-SW. X900 CORE FC-SW. CDICT-SW. FIM-SW. U4-SW. CEI-SW SOC-SW. FCA-SW. MFC-SW. QF-SW. RECT-SW. Figura 2.1 Mapa topológico del Backbone de la Intranet UCLV.. La conexión a las redes externas se realiza mediante 4 enlaces Frame Relay con flujos de 2Mbps cada uno. Uno de los enlaces es con las redes del MES (Ministerio de educación superior) a través de ruter CISCO 1005, los restantes son a través del ruter CISCO. Uno de esos flujos es compartido en dos enlaces de 1Mbps para acceso a Internet y para la conexión con las Sedes Universitarias Municipales (SUM) por MODEM-Ruter. Los últimos 4Mbps son también hacia la red del MES. Existen además alrededor de 40 puntos de acceso inalámbricos (AP) distribuidos por toda la red, en su gran mayoría son de tecnología Wi-Fi y soportan el protocolo SNMP..

(45) CAPÍTULO 2. MATERIALES Y METODOS. 35. Los conmutadores son mayormente de la serie AT-8724XL de la empresa Allied Telesyn International de 24 puertos para conexión 10Base Tx y 100Base TX. Permiten la conexión de dos de dos enlaces a 1Gbps. Brindan conmutación de paquetes en la capa 2 y capa 3, filtrado de paquetes en ambas capas y soportan QoS. Soportan SNMPv1 y SNMPv2c para las MIBs estándares. Cuentan además con MIB propietario.. La Intranet pertenece a la red del ministerio de educación que es de clase A privada. La Universidad tiene asignada el esquema de direccionamiento 10.12.0.0/16. El dominio de la red es UCLV.EDU.CU al cual pertenecen 12 subdominios que dan nombre a todas las dependencias.. 2.2. Servicios y aplicaciones de la Intranet. Muchos de los servicios y aplicaciones están centralizados, y los servidores residen físicamente en un único local (ver figura 2.1) donde se cuenta con condiciones especiales de hardware y respaldo eléctrico, de esta manera se brinda mayor estabilidad del servicio. Esta centralización de servicios también trae consigo un aumento del tráfico en el Backbone. En el nodo central existen 10 Servidores DELL R-200, seis Servidores DELL 2950 III, 17 Estaciones mejoradas y un dispositivo de almacenamiento, todos estos dispositivos se reparten en dos Locales de Servidores. La conexión a las redes externas se realiza a través de dos servidores proxy instalados sobre el sistema operativo Debían, uno para la conexión con la red nacional y el otro para Internet. Hay además un servidor de DNS externo en la primera de estas estaciones. Los servidores de correo interno son Exchange 2007 y residen sobre tres estaciones montadas sobre Windows 2003. El nodo central cuenta con dos MTA (Agentes de transferencia de correo) sobre Debían, los cuales contienen servidores de DNS externos así como los servicios de mensajería instantánea con alcance nacional. Los controladores de dominio se.

(46) CAPÍTULO 2. MATERIALES Y METODOS. 36. encuentran en dos computadoras, que albergan además los DNS internos y el Active Directory, estos. utilizan Windows Server 2003. Además de estos servidores,. hay. estaciones mejoradas con función servidores de transferencia de archivos, servidores de sitios WEB, servidores de multimedia y servidores de bases de datos con información docente. 2.3. Generalidades en gestión de la intranet UCLV. Luego de analizar la estructura de Intranet y los servicios y aplicaciones que soporta la red es urge la necesidad de monitorear como mínimo la disponibilidad de los servidores centrales que se encuentran en La Puerta, el estado de los servicios que ellos brindan y la disponibilidad también de los switches que sirven como puertas de enlaces a las distintas áreas.. 2.3.1 Sistema de gestión Nagios Como solución a las necesidades de tener control sobre el funcionamiento de la red, desde el 2004 está implementado un sistema de gestión cuya plataforma principal es Nagios. Este tiene la habilidad de monitorear servidores y los correspondientes servicios de los cuales ofrece notificaciones. Corre sobre los sistemas operativos Unix y Linux. Es fácil de compilar y de instalar mediante comandos. Lo más difícil de su uso es lo complejo de su configuración, pues después de instalar el cliente, es necesario realizar cambios en varios de sus ficheros en modo de texto para adaptar el sistema a las particularidades de la red. (Nagios, 2009). Una vez instalado el gestor se procede a instalar los agentes en todas los dispositivos que se van a monitorear, o configurar los servicios SNMP en el caso de los enrutadores, los conmutadores y los AP (access point). En la tabla 2.1 se da una relación de los distintos ficheros de configuración del gestor Nagios y la función de cada uno de estos. En el Anexo II se muestra una guía con los pasos a seguir para la instalación de Nagios en un sistema operativo Linux/Debian..

(47) CAPÍTULO 2. MATERIALES Y METODOS. 37. Tabla 2.1 Ficheros de configuración de Nagios. nagios.cfg. Es el fichero principal, en el se encuentran las referencias a los demás ficheros. Incluye la ubicación de los ficheros logs y los descriptores del daemon nagios.. services.cfg. Contiene la declaración de los servicios que se desean monitorear a nivel de estaciones. Y los datos que regulan este monitoreo.. hosts.cfg. Incluye las direcciones IP, responsables, descripción de las estaciones a las que se les va a monitorear algún servicio. También es el que brinda la información de la estructura física de la red.. hostgroups.cfg. Permite agrupar estaciones que compartan características similares de algún modo.. contacts.cfg. Es aquí donde se definen los nombres y los datos básicos de los responsables de la administración de la red.. contactgroups.cfg. Al igual que hostsgroups.cfg este fichero permite agrupar los contactos.. cgi.cfg. Orientado a regular el acceso al nagios desde un navegador Web..

Figure

Figura 1.1 Modelo del sistema de gestión.
Figura 1.2 Identificadores de Objetos (OID) en estructura de árbol.
Figura 1.3 Estructura de la MIB-II.
Figura 1.4 Formato de los mensajes SNMP.
+7

Referencias

Documento similar

You may wish to take a note of your Organisation ID, which, in addition to the organisation name, can be used to search for an organisation you will need to affiliate with when you

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)