Disen126 no e Implementacio19 on de un Sistema de...

Universidad Tecnica Federico Santa MarıaDepartamento de Electronica

———————————————————————

“Diseno e Implementacion de un Sistema deMonitoreo basado en SNMP para una Red de

Telefonıa IP Asterisk”

Memoria presentada por: Patricio E. Valle Vidalcomo requisito parcial para optar al tıtulo deIngeniero Civil ElectronicoMencion Computadores.

Profesor Guıa: Tomas Arredondo Vidal

Valparaıso, Agosto 2007———————————————————————

Universidad Tecnica Federico Santa MarıaDepartamento de Electronica

———————————————————————

“Diseno e Implementacion de un Sistema deMonitoreo basado en SNMP para una Red de

Telefonıa IP Asterisk”

Memoria presentada por: Patricio E. Valle Vidalcomo requisito parcial para optar al tıtulo deIngeniero Civil ElectronicoMencion Computadores.

Profesor Guıa: Tomas Arredondo VidalProfesor Coreferente: Agustın Gonzalez Valenzuela

Valparaıso, Agosto 2007———————————————————————

Diseno e Implementacion de un Sistema de Monitoreobasado en SNMP para una Red de Telefonıa IP Asterisk

Patricio Enrique Valle Vidal

Memoria para la obtencion del Tıtulo de Ingeniero Civil Electronico

Profesor Guıa: Tomas Arredondo Vidal

Agosto 2007

Resumen

Simple Network Management Protocol, o SNMP, es una aplicacion que permite ausuarios remotos revisar o manipular variables de administracion. SNMP es usado tıpi-camente para administrar redes de redes, o internets, que usan el conjunto de protocolosTCP/IP. En una red de telefonıa IP, la cual tiene una amplia tendencia al crecimien-to resulta difıcil proporcionar alta calidad de servicios y una administracion de redeficiente.

En esta tesis, se realiza un estudio sobre un sistema integral a modo de prueba queadministre una red local de manera sencilla y segura. En este caso la red cumple comofuncion principal, entregar a sus usuarios servicios de telefonıa IP, mediante la instala-cion de una central PBX llamada Asterisk. Este sistema esta construıdo empleando losrecursos de administracion definidos en el estandar SNMPv3 que se encuentran dispo-nibles en la plataforma Linux, y que se seran instalados en dos maquinas PC (PersonalComputer) ubicadas en el laboratorio ATM del departamento de Electronica. Se utili-zan agentes y subagentes ubicados en la central administrada y almacenan informacionespecificada en el estandar SNMP, que es recibida por el centro administrador (remoto)para organizarla y presentarla en un portal Web creado para este fin. Esta informacionse obtiene para dos fines: analisis de estadısticas y reconocimiento de fallas de los dife-rentes servicios disponibles por la central administrada.Se espera que este ambiente sea de gran utilidad para la administracion y seguridad dela red de telefonıa IP creada recientemente en el departamento de Electronica

Palabras claves – Simple Network Management Protocol (SNMP), agente, estacion,Linux, telefonıa IP, Linux, Net-SNMP, implementacion.

Indice

1. Introduccion 1

1.1. Objetivos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Protocolo SNMP 7

2.1. Estaciones y Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Comunicacion y Clases de Mensajes . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Metodos de Comunicacion SNMP . . . . . . . . . . . . . . . . . . 8

2.2.2. Mensajes SNMP y Protocol Data Units (PDUs) . . . . . . . . . 9

2.2.3. Clases de PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Arquitectura SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Objetos versus Nombres . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2. Definicion de un Objeto . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.3. Extension de SMI . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4. SNMP y UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5. Comunidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6. RMON: Monitoreo Remoto . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7. Arquitecturas NMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8. Extension de un Agente SNMP . . . . . . . . . . . . . . . . . . . . . . . 22

3. Seguridad en SNMP 24

3.1. Primeros Pasos en SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2. Cambios en SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii

3.2.1. Motor SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2. Aplicaciones SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.3. Convenciones definidas en SNMPv3 . . . . . . . . . . . . . . . . 29

3.3. Modelo USM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1. Aspectos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.2. Descubrir a su Motor Autoritario . . . . . . . . . . . . . . . . . . 32

3.3.3. Puntualidad USM . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.4. Autentificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.5. Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.6. Tabla de Usuario USM . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.7. Llaves Localizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4. Control de Acceso basado en Vistas (VACM) . . . . . . . . . . . . . . . 33

3.4.1. Aspectos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.2. Tabla Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.3. Tabla Security to Group . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.4. Tabla Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.5. Tabla View Tree Family . . . . . . . . . . . . . . . . . . . . . . . 35

3.5. Administracion Distribuida (DisMan) . . . . . . . . . . . . . . . . . . . 36

4. Traps e Informs 38

4.1. La Necesidad de Traps en SNMP . . . . . . . . . . . . . . . . . . . . . . 38

4.2. Conceptos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1. Traps SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.2. Informs SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5. Net-SNMPOpen Source SNMP System 42

5.1. Instalacion de Net-SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2. Configuracion para Agente SNMP . . . . . . . . . . . . . . . . . . . . . 45

5.2.1. Aspectos Fundamentales para la Implementacion . . . . . . . . . 45

iv

5.2.2. Creacion de Usuarios SNMPv3 . . . . . . . . . . . . . . . . . . . 58

5.2.3. Inicio del Agente SNMP . . . . . . . . . . . . . . . . . . . . . . . 59

5.3. Configuracion para Receptor de Notificaciones SNMP . . . . . . . . . . 59

5.3.1. Funcionamiento del Mecanismo de Notificaciones . . . . . . . . . 59

5.3.2. Demonio snmptrapd . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.3. Creacion de Usuarios SNMPv3 . . . . . . . . . . . . . . . . . . . 64

6. AsteriskOpen Source IP-PBX System 65

6.1. Instalacion de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2. Configuracion del Subagente SNMP . . . . . . . . . . . . . . . . . . . . 68

6.2.1. Usuarios SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.2. Creacion del Dialplan . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2.3. Asterisk CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.4. Softphone X-lite . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.5. Iniciacion de Servicios . . . . . . . . . . . . . . . . . . . . . . . . 74

7. Resultados y Conclusion 76

7.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1. Resumen sobre configuraciones . . . . . . . . . . . . . . . . . . . 77

7.1.2. Estadısticas en IP-PBX 3 a traves de SNMP . . . . . . . . . . . 79

7.1.3. Reconocimiento de Fallas en Central IP-PBX 3 . . . . . . . . . . 84

7.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.2.1. Sistema de Monitoreo . . . . . . . . . . . . . . . . . . . . . . . . 88

7.2.2. Sistema de Reconocimiento de Fallas . . . . . . . . . . . . . . . . 88

7.2.3. Desarrollo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A. Servicios para Linux:asterisk, snmpd y snmptrapd 90

A.1. Scripts de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

v

A.2. Instalacion de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.3. Pruebas de Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . 95

vi

Indice de Figuras

1.1. Mapa de Red de Telefonıa IP del departamento de Electronica . . . . . 2

1.2. Esquema Logico de Administracion de la Red de Telefonıa IP . . . . . . 3

1.3. Sistema de Monitoreo para una Red de Telefonıa a traves de SNMP . . 4

1.4. Generacion y procesamiento de alarmas con SNMP . . . . . . . . . . . . 6

2.1. Relacion entre NMS y agente . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Arbol de objetos SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Arbol extendido en SMIv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4. Modelo de comunicacion TCP/IP y SNMP [3] . . . . . . . . . . . . . . . 17

2.5. Arquitectura simple de NMS [4] . . . . . . . . . . . . . . . . . . . . . . . 20

2.6. Arquitectura de Tipo Distribuida de NMS [4] . . . . . . . . . . . . . . . 21

2.7. Usando enlaces privados para administrar la red [4] . . . . . . . . . . . . 22

2.8. Arquitectura para agentes extensibles . . . . . . . . . . . . . . . . . . . 23

3.1. Entidad SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2. Flujo Logico de VACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1. X-lite, configuracion de parametros SIP . . . . . . . . . . . . . . . . . . 73

6.2. X-lite, Ventana principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1. Esquema Final de un Sistema de Administracion para una Red de Tele-fonıa IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.2. Analisis de Trafico Ethernet para IP-PBX 3 . . . . . . . . . . . . . . . . 80

7.3. Analisis de Uso de Canales Asterisk para IP-PBX 3 . . . . . . . . . . . 81

vii

7.4. Analisis de Carga Promedio en CPU para IP-PBX 3 . . . . . . . . . . . 82

7.5. Analisis de Temperatura para IP-PBX 3 . . . . . . . . . . . . . . . . . . 82

7.6. Analisis de Memoria en Uso para IP-PBX 3 . . . . . . . . . . . . . . . . 83

7.7. Zona de notificaciones en el sitio Web de administracion . . . . . . . . . 87

viii

Indice de Tablas

2.1. Clases de PDU SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Tipos de datos definidos en SMIv1 . . . . . . . . . . . . . . . . . . . . . 13

2.3. Nuevos tipos de datos para SMIv2 . . . . . . . . . . . . . . . . . . . . . 14

2.4. Nuevos campos en definicion de SNMPv2 . . . . . . . . . . . . . . . . . 15

2.5. Nuevos tipos de datos para SMIv2 . . . . . . . . . . . . . . . . . . . . . 19

3.1. Modelos y niveles de seguridad . . . . . . . . . . . . . . . . . . . . . . . 24

3.2. Conjunto de aplicaciones para SNMPv3 . . . . . . . . . . . . . . . . . . 28

3.3. Convenciones para SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4. Conceptos definidos en el modelo USM . . . . . . . . . . . . . . . . . . . 30

3.5. Formato de un mensaje SNMPv3 . . . . . . . . . . . . . . . . . . . . . . 31

3.6. Parametros de snmpSecurityParemeter . . . . . . . . . . . . . . . . . . . 31

3.7. Tabla de usuarios USM . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1. Traps genericos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1. Objetos monitoreados en la central IP-PBX 3 . . . . . . . . . . . . . . . 54

5.2. Tipos de procesamientos para modelo VACM . . . . . . . . . . . . . . . 61

5.3. Formato de notificaciones para Net-SNMP . . . . . . . . . . . . . . . . . 63

7.1. Resumen de Configuraciones para IP-PBX 2 . . . . . . . . . . . . . . . . 77

7.2. Resumen de Configuraciones para IP-PBX 3 . . . . . . . . . . . . . . . . 78

7.3. Resumen de Configuraciones para NMS-ELO01 . . . . . . . . . . . . . . 78

7.4. Descripcion del Plan de Monitoreo . . . . . . . . . . . . . . . . . . . . . 79

ix

7.5. Tipos de canales disponibles en Asterisk . . . . . . . . . . . . . . . . . . 81

7.6. Objetos MIB para analisis de memoria en uso . . . . . . . . . . . . . . . 83

A.1. Script para servicio Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.2. Script para servicio snmpd . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.3. Script para servicio snmptrapd . . . . . . . . . . . . . . . . . . . . . . . 94

x

Capıtulo 1

Introduccion

El protocolo Simple Network Management Protocol (SNMP) [1] permite consultary alterar variables dentro del contexto de una red. SNMP es usado tıpicamente paratransportar informacion de la red entre sistemas de administracion y agentes en unrecurso de red ası como hosts, servidores, switches, routers, y gateways.

Internets o redes de redes, contienen importantes retos en el concepto de la admi-nistracion. SNMP fue disenado para el manejo de redes TCP/IP y es donde a menudose aplica, aun cuando se esta usando para administrar otras suites de protocolos de red.

SNMP se construyo gracias a la ayuda conjunta de investigadores, usuarios y admi-nistradores de red, y empresas de Telecomunicaciones. Los primeros disenadores estabaninvolucrados activamente en la administracion e investigacion de internets. Gracias a lamucha experiencia que tenıan es que SNMP se logro disenar, implementar y poner enmarcha en el corto tiempo. Finalmente, todas las propuestas de diseno fueron converti-das en prototipo y probadas mediante multiples implementaciones independientes.

En la actualidad el departamento de Electronica esta finalizando la implementandouna red de telefonıa IP la cual permite la comunicacion entre terminales IP, ademas deinterconectar los mundos IP y PSTN. La Figura 1.1 describe la arquitectura de esta redconformada por dos centrales IP-PBX instaladas con la aplicacion Asterisk que contieneun conjunto de herramientas para llevar a cabo todos los servicios requeridos para lacomunicacion.

1

1. Introduccion

Figura 1.1: Mapa de Red de Telefonıa IP del departamento de Electronica

El proyecto que es descrito a continuacion, implementa un sistema de administracionremota para una red de telefonıa IP1, incluyendo todos los conceptos de seguridad defi-nidos en la ultima version de SNMP (SNMPv3). Este sistema es solo modulo de pruebaconstruıdo para analizar la posibilidad de administrar a traves del estandar SNMPv3la red de computadores aplicada a servicios de telefonıa IP que tiene implementado eldepartamento de Electronica. Debido a que la red no ha sido completada y se requierede su manipulacion para configurar el sistema de administracion fue necesario acoplarel modulo de prueba, el cual consiste en una estacion de administracion y una centralIP-PBX ademas del conjunto de aplicaciones y configuraciones que fueron realizadaspara este fin tal como se representa en la Figura 1.2.

1IP: Internet Protocol

2

1. Introduccion

Figura 1.2: Esquema Logico de Administracion de la Red de Telefonıa IP

1.1. Objetivos del Proyecto

Este documento describe en detalle la implementacion realizada en base a los si-guientes objetivos:

Instalacion y configuracion del Modulo de Prueba

El primer paso consiste en instalar y configurar las entidades SNMP (agentes yestacion) que permitiran el traspaso de informacion relevante sobre la central IP-PBXde prueba. En este caso se utilizara la aplicacion Net-SNMP que es codigo abierto ycontiene un conjunto de aplicaciones que permiten administrar remotamente una redbasada en la especificacion SNMPv3.

Ademas se debe integrar este modulo de prueba a la red de Electronica ya existentepara analizar la compatibilidad entre versiones de la aplicacion Asterisk utilizada. Lasdos centrales existentes estan configuradas con la aplicacion Asterisk en su version dekernel 1.2, pero el modulo SNMP esta disponible solo para el kernel 1.4 por lo quesera necesaria la instalacion de la central en esta version y configurada para acoplarseal mapa de red existente.

3

1. Introduccion

Diseno de un Sistema de Monitoreo

Este objetivo se sustenta en el analisis temporal sobre servicios realizados en unacentral IP-PBX, construyendo una serie de graficos en tiempo real tales como: uso decanales de comunicacion, memoria en uso, temperatura y porcentaje de carga de laCPU, y trafico.

Figura 1.3: Sistema de Monitoreo para una Red de Telefonıa con SNMP

La estacion de administracion genera consultas SNMP a la central integrada, lascuales son almacenadas en una base de datos circular, permitiendo la generacion degraficos sobre estadısticas en tiempo real como por ejemplo sobre el uso de los canalesAsterisk. RRDTool (Roud Robin Database Tool), es un proyecto GNU que permitealmacenar y representar datos en intervalos temporales (ancho de banda, temperatura,...) [2]. La informacion recibida por el centro de administracion sera almacenada en unabase de datos que no crece en el tiempo, acomulando datos diarios, semanales, mensualesy anuales para crear graficos de calidad, los cuales seran desplegados en el portal Webde administracion creado para este proyecto tal como se describe en la Figura 1.3.

Diseno de un Sistema de Reconocimiento de Fallas

Este objetivo consiste en generar alarmas desde un equipo administrado para ser en-viadas a la estacion SNMP para su posterior procesamiento, permitiendo tomar accionesque den solucion al problema de fondo.

Consiste en configurar la central IP-PBX de prueba para que genere mensajes dealarmas al momento de detectar una falla en su sistema sobre ciertos servicios. Estacomunicacion tiene la particularidad de no ser de libre acceso, es decir, debe cumplircon el proceso de autentificacion, ademas de ser transmitido en forma encriptada paraevitar danos en su integridad, es decir, se usara el maximo de seguridad posible parael protocolo SNMP. Una vez que la estacion reciba estos mensajes, la accion tomadasera informar a traves de la generacion de registros para luego ser mostrados en unaconsola Linux (tty) y en el sitio Web de administracion desarrollado para este proyecto.

4

1. Introduccion

De esta manera el administrador siempre estara informado de los sucesos en la redpudiendo tomar acciones inmediatas en caso de fallas.

Figura 1.4: Generacion y procesamiento de alarmas con SNMP

5

Capıtulo 2

Protocolo SNMP

SNMP es un protocolo de la capa de aplicacion en el modelo OSI, que facilita elintercambio de informacion de tipo administrativa entre dispositivos de la red. De estamanera permite a los administradores manejar el desempeno de la red para encontrary resolver problemas, y planificar su crecimiento.

2.1. Estaciones y Agentes

En el ambiente SNMP hay dos tipos de entidades: administrador y agente. El admi-nistrador es un servidor con algun tipo de software que puede manejar tareas adminis-trativas para una red. En el lenguaje SNMP son referidos como Network ManagementStations (NMS), es decir, estaciones de administracion de redes. Una estacion es res-ponsable de generar consultas y de recibir notificaciones de agentes en la red. A travesde una consulta se obtiene informacion que mas tarde puede ser usada para determinarsi ha ocurrido algun evento crıtico. Por otro lado una notificacion permite al agentedar aviso que algo ha ocurrido. La estacion tiene la capacidad de realizar una accionbasado en la informacion que recibio del agente. Por ejemplo, cuando un circuito T1 deInternet esta caıdo el router puede enviar un mensaje a la estacion y una vez recibido,se pueden cambiar parametros que permitan volver a su normal funcionamiento. Estetipo de mensaje es enviado de forma asincronica, no como respuesta a una consultarealizada por una estacion.

El agente, por su parte es una aplicacion que corre en equipos de red (router, switch,servidores, etc). Puede ser independiente ası como un demonio en el lenguaje UNIX,o puede estar incorporado en el sistema operativo (por ejemplo, el sistema operativode Cisco, o de bajo nivel que controla una UPS). El agente provee informacion deadministracion a la estacion no perdiendo de vista los aspectos operacionales del equipo.Por ejemplo, el agente en un router es capaz de estar informado de los estados de cadauna de sus interfaces: cuales estan activas y cuales no, etc. La estacion puede consultarpor el estado de cada una de sus interfaces, y tomar acciones apropiadas si alguna

6

2. Protocolo SNMP

esta desactiva. Cuando el agente percibe que algo malo sucedio, el puede enviar unmensaje a la estacion para volver a su estado normal [3].

Figura 2.1: Relacion entre NMS y agente [3]

Cabe destacar que tanto las consultas como notificaciones pueden ocurrir al mismotiempo, no habiendo restriccion sobre el momento en que se transmiten estos tipos demensajes tal como se describe en la Figura 2.1.

2.2. Comunicacion y Clases de Mensajes

El principal objetivo de SNMP es que permite el intercambio de informacion admi-nistrativa en forma de objetos MIB1 para ser comunicada entre equipos de una red. Elprotocolo de operaciones de SNMP describe como se realiza esta comunicacion, indi-cando los metodos disponibles para el intercambio de informacion.

2.2.1. Metodos de Comunicacion SNMP

Se dispone de dos tecnicas de comunicacion, usadas en situaciones en que una entidadnecesita estar informada sobre el estado de otra entidad:

Interrogacion: Este termino se refiere cuando una entidad quiere informacionsobre otra. En SNMP, una estacion es la que deberıa pedir informacion necesariaa sus agentes. Un ejemplo cotidiano para este modelo de comunicacion serıa elservicio regular de e-mails; una persona cada dıa revisa su correo por si ha recibidomensajes nuevos.

Interrupcion: Este termino se refiere cuando un equipo necesita que otro obtengaparte de su informacion, entonces decide enviarsela. En SNMP, el agente le envıainformacion a una estacion sin ser previamente consultado. Un ejemplo real serıael modelo usado por la comunicacion vıa telefono.

1MIB: Management Information Base.

7

2. Protocolo SNMP

En caso de preguntarse cual metodo es mejor, no se podrıa llegar a ninguna conclu-sion, esto porque ambos modelos tienen sus pro y sus contras. Por esta razon que SNMPse diseno para usar ambos metodos. La interrogacion es usada para almacenar informa-cion periodica ası como por ejemplo para fines estadısticos o consultar sobre estado deun equipo. En cambio las interrupciones son usadas en forma de alarmas denominadasnotificaciones, las cuales pueden ser configuradas por un administrador para corregirfallas en los equipos de la red.

2.2.2. Mensajes SNMP y Protocol Data Units (PDUs)

En SNMP el intercambio de informacion es realizada de manera similar a muchosprotocolos de red, es decir, a traves del envıo y recepcion de mensajes. Este tipo de men-sajes recibe el nombre pdus, definido como una unidad de dato usada por el protocolo.Todos los mensajes SNMP tienen el sufijo -pdu para ser identificados.

En SNMP pdu y mensaje no tienen exactamente el mismo significado. pdu se definecomo el dato de la capa mas alta que es encapsulado por SNMP, descrito por el modeloOSI. En cambio el formato de un mensaje SNMP es la envoltura que encapsula un pdujunto con el encabezado. Sin embargo un mensaje se construye para enviar un pdu, porlo que son terminos bastante parecidos y que muchas veces pueden ser usados comosinonimos.

2.2.3. Clases de PDUs

Para la version 1 de SNMP se definen 6 pdus, los cuales fueron extendidos y cam-biados tanto en nombre como uso en las versiones 2c y 3. El marco SNMP usado en laactualidad categoriza los pdus en diferentes clases, las cuales describen las dos funcionesde un mensaje: tipo y forma de comunicacion, que se utilizan para realizar tareas deinterrogacion versus interrupcion.

La Tabla 2.1 describe las principales clases de pdus disponibles en SNMPv2c/SNMPv3indicando aquellos pdus que estan dentro de esa categorıa. Estas clases no son usadas enSNMPv1 pero son descritas de igual forma para establecer una asociacion y ası entendermejor sus funciones.

8

2. Protocolo SNMP

Tabla 2.1: Clases de PDU SNMP

Clase de PDU Descripcion

Read Permiten leer informacion desde un equipo administrado usandomecanismos de interrogacion.v1: GetRequest-PDU, GetNextRequest-PDUv2c/v3: GetRequest-PDU, GetNextRequest-PDU,

GetBulkRequest-PDU.Write Permite modificar la informacion en un equipo administrado y

ası pueda efectuar una operacion.v1: SetRequest-PDUv2c/v3: SetRequest-PDU.

Response Es enviado como respuesta a un previo requerimiento.v1: GetResponse-PDUv2c/v3: Response-PDU.

Notification Es usado por un equipo para enviar una interrupcion, ası comouna notificacion a una estacion.v1: Trap-PDUv2c/v3: Trapv2-PDU, InformRequest-PDU.

GetBulkRequest-pdu y InformRequest-pdu son pdus definidos en SNMPv2/v3. Encambio GetResponse-pdu solo fue renombrado a Response-pdu y tiene la propiedad deser un mensaje respuesta y no de peticion.

Existen otras tres clases especiales, que son definidas en la actual version de SNMPpero que son de menor interes dado que no son de uso activo. La clase Internal contieneun mensaje denominado Report-pdu definido por la comunicacion interna de SNMP. Ademas SNMP provee dos clases mas llamadas Confirmed y Unconfirmed, usadas paradefinir categorıas de mensajes basado en que sean o no reconocidos por el sistema. Losmensajes Report-pdu, Trapv2-pdu, y Response-pdu forman parte de la clase Confirmed,y el resto estan en la clase Unconfirmed.

2.3. Arquitectura SMI

“Informacion Administrativa” muchas veces es referida a los parametros operacio-nales que forman parte de un equipo de red con soporte SNMP. Sin embargo no logradescribir lo que realmente contiene y representa. El primer paso hacia entender que clasede informacion puede proporcionar un equipo de red, es comprender como estos datos serepresentan dentro del contexto SNMP. SMI (Structure of Management Information) esla estructura que permite asociar objetos administrados con tipos de datos [5]. Un objetose puede representar a traves de tres atributos, tal como se describe a continuacion.

9

2. Protocolo SNMP

NombreEl identificador (object identifier o OID), permite distinguir un objetode otro, pudiendo ser representados a traves de numeros o palabras.

Tipo y SintaxisEl tipo de dato de un objeto es definido a traves del lenguaje “AbstractSyntax Notation One” (ASN.1). Es un camino para especificar como losdatos son representados y transmitidos entre estacion y agente dentrodel contexto SNMP. La gran ventaja de ASN.1 es que la notacion esindependiente de la maquina, por ejemplo un PC cuyo sistema operativoes Windows 2000 puede comunicarse con otra que tenga Sun SPARC ysin tener que preocuparse de la clasificacion de bytes.

CodificacionLa instancia de un objeto es codificada en una cadena de bytes usandola regla de BER (Basic Encoding Rules), especificando la forma en quelos objetos son codificados para ser transmitidos por un medio ası comoEthernet y luego recibidos y decodificados para ser procesados por unadeterminada entidad [6].

2.3.1. Objetos versus Nombres

Los objetos administrados son organizados en una jerarquıa de arbol, que es la basedel esquema de nombres de SNMP [4]. Un identificador de objetos (oid) se construyede una serie de enteros que representan un nodo del arbol, separado por un punto (.).

El nodo mas alto de un arbol es su raız y todo lo que este por debajo ya sean sushijos y niveles inferiores se denomina subarbol. Por otro lado una hoja es un nodo queno tiene hijos. Por ejemplo en la Figura 2.2 la raız del arbol es Root-Node, sus subarbolesson ccitt(0), iso(1) y joint(2). El nodo iso(1) es el unico que contiene un subnivel,los otros dos nodos son solo hojas del arbol.

Descendiendo por el subarbol iso(1), el nodo directory no es usado actualmente, encambio mgmt define un conjunto estandar de objetos para Internet, y experimentalesta reservada para propositos de investigacion y pruebas. El subarbol private permitedefinir objetos unilateralmente, es decir, tanto individuos como organizaciones son res-ponsables de definir sus propios objetos. A continuacion se indica la definicion de los 4subarboles que forman parte del objeto internet.

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 }

10

2. Protocolo SNMP

La primera lınea declara a internet con oid 1.3.6.1, que es definido (::=, es eloperador de definicion) como un subarbol de iso.org.dod. El resto de las lıneas dedefinicion declaran los identificadores correspondientes para los subarboles restantes.

En la version actual de SNMP el subarbol private contiene el nodo enterprises usa-do exclusivamente para que vendedores de hardware y software puedan definir aquellosobjetos que permitan administrar sus dispositivos propios. La definicion SMI para estenodo es la que se indica a continuacion:

enterprises OBJECT IDENTIFIER ::= { private 1 }

Internet Assigned Numbers Authority (IANA), es la entidad que actualmente asignael numero privado de empresa para individuos, instituciones, organizaciones y companıasen Internet. Por ejemplo, Cisco System tiene como numero privado el 9, ası la basedel subarbol esta definida como iso.org.dod.internet.private.enterprises.cisco o1.3.6.1.4.1.9. El termino empresa privada puede ser usada para referirse al subarbolenterprise. Las companıas no son las unicas que pueden registrar un identificadorprivado, cualquiera puede hacerlo, esto porque el procedimiento es gratuito [7]. Con unidentificador de empresa propio se puede crear un MIB para monitorear determinadasvariables segun las necesidades que se tengan en la red.

Figura 2.2: Arbol de objetos SMI [4]

11

2. Protocolo SNMP

2.3.2. Definicion de un Objeto

El atributo syntax permite definir un objeto administrado a traves del lenguajeASN.1, entre varios tipos de datos estandares para la administracion de dispositivos deredes. Se debe tener en cuenta que estos tipos de datos son simplemente un camino paradefinir que tipo de informacion puede llevar a cabo un objeto [5].

Tabla 2.2: Tipos de datos definidos en SMIv1

Tipo de dato Descripcion

Integer Numero de 32-bit usado para especificar tipos numericos dentrodel contexto de un simple objeto.

Octet String Cadena de 0 o mas bytes usada generalmente para representar untexto, pero a veces es usada tambien para representar direccionesfısicas.

Counter Numero de 32-bit con mınimo igual a 0 y maximo 232 - 1(4,294,967,295). Cuando el valor maximo es alcanzado, se reini-cia la cuenta volviendo a 0. Este tipo se usa principalmente paradescribir informacion ası como la cantidad de bytes enviadas orecibidas por una interfaz de red. Su comportamiento natural esque siempre vaya aumentando, nunca decrecer.

Object Identifier Una cadena de tipo decimal que representa un objeto administra-do dentro del arbol. Por ejemplo 1.3.6.1.4.19 representa el OIDde Cisco System.

null Actualmente no es usado en SNMP.Sequence Define listas que contienen cero o mas tipos de datos ASN.1.Sequence Of Define un objeto administrado que se compone por una secuencia

(Sequence) de tipos ASN.1.IpAddress Representa una direccion IPv4 de 32-bit. Ninguna de las dos ver-

siones de SMI especifican sobre las direcciones IPv6 de 128-bit.NetworkAddress Puede representar diferentes tipos de direccion de red. Su formato

es similar al tipo IpAddress.Gauge Numero de 32-bit con mınimo igual a 0 y maximo 232 - 1

(4,294,967,295). A diferencia de Counter, estos objetos puedenaumentar y disminuir su valor, pero nunca excederse del maximo.La velocidad de una interfaz en un router se representa con estetipo de dato.

TimeTicks Numero de 32-bit con mınimo igual a 0 y maximo 232 - 1(4,294,967,295) representado en centesimos de segundo. El tiem-po activo en un dispositivo se representa con este tipo de dato.

Opaque Permite que cualquier otro ASN.1 sea codificado como una se-cuencia de bytes (Octet String).

12

2. Protocolo SNMP

2.3.3. Extension de SMI

SMIv2 extiende el arbol de objetos agregando el subarbol SNMPv2 al nodo inter-net(1). Este cambio significa tener nuevos tipos de datos y que algunos identificadoresde objetos tambien cambien. La Figura 2.3 muestra como este nuevo subarbol se ajustaa la arquitectura SMI; su OID es 1.3.6.1.6.3.1.1.

Figura 2.3: Arbol extendido en SMIv2 [4]

SMIv2 tambien define algunos tipos nuevos de datos, los cuales se pueden observaren la Tabla 2.3.

Tabla 2.3: Nuevos tipos de datos para SMIv2

Tipo de dato Descripcion

Integer32 Identico a Integer.Counter Identico a Counter.Gauge32 Identico a Gauge.Unsigned32 Representa valores decimales entre 0 y 232 − 1.Counter64 Similar a Counter32, pero representa valores entre 0 y 264 − 1.BITS Enumeracion de no negativos denominada bits.

13

2. Protocolo SNMP

La definicion de un objeto SNMPv2 cambia levemente con respecto a SMIv1 debidoa que se agregaron campos opcionales, dandole un mayor control sobre como un objetoes accedido, permitiendo agregar mas columnas, y generar mejores descripciones. Acontinuacion se define la sintaxis para definir un objeto SNMPv2, en donde la lıneadestacada corresponde a la extension realizada descrita en detalle en la Tabla 2.4.

<name> OBJECT-TYPESYNTAX <datatype>UnitsParts <Optional, see below>MAX-ACCESS <See below>STATUS <See below>DESCRIPTION‘‘Textual description describing this particular

managed object.’’AUGMENTS { <name of table> }::= { <Unique OID that defines this object> }

Tabla 2.4: Nuevos campos en definicion de SNMPv2

Definicion Descripcion

UnitsParts Describe una de las unidades (ej. seconds, miliseconds, etc.) usada pararepresentar al objeto.

Max-Access El acceso para un tipo de objeto puede ser Max-Access en SNMPv2.Las opciones validas son: read-only, read-write, read-create, not-accesible, y accesible-for-notify.

Status Esta clausula ha sido extendida para permitir las palabras: current,obsolete y deprecated. En SNMPv2 current es identico a mandatoryen un MIB SNMPv1.

Augments En algunos casos, es util para agregar una columna a una tabla exis-tente. La clausula augments permite extender una tabla agregandouna o mas columnas, representada por algun otro objeto. Se requiereel nombre de la tabla del objeto que sera modificada.

SMIv2 define un nuevo tipo de notificacion denominada Notification-Type, que sera dis-cutido mas adelante en este capıtulo, a demas se incluyen nuevas convenciones quepermiten crear objetos de maneras mas abstractas [8].

14

2. Protocolo SNMP

2.4. SNMP y UDP

SNMP usa el protocolo de transporte User Datagram Protocol (UDP) para inter-cambiar datos entre la estacion y el agente. UDP fue escogido en vez de TransmissionControl Protocol (TCP) debido a que no esta orientado a la conexion, es decir, no hayuna conexion punto a punto entre el agente y la estacion cuando los paquetes se envıande ida y vuelta. Este aspecto lo hace poco confiable, ya que no hay aviso en caso deperdidas de los datagramas. Para determinar si un paquete fue perdido se define untimeout la estacion envıa una peticion al agente y espera por la respuesta (el tiempode espera es configurable). Si el timeout es cumplido y la estacion no ha recibido nin-guna respuesta del agente entonces asume que el paquete se perdio y lo retransmite. Elnumero de veces que lo retransmite tambien es configurable [4].

En el caso de las notificaciones, la situacion es diferente. Si un agente envıa unmensaje y este nunca llega, la estacion no tiene manera de saber que fue enviado. Elagente no sabe que necesita reenviarlo, porque la estacion no tiene la obligacion deresponder a una notificacion (puede que no se tome una accion sobre el agente sino quesolo se lean las notificaciones para llevar una estadıstica).

Debido a la naturaleza no confiable de UDP es que no tiene un alto costo (overhead),ası el impacto en el funcionamiento de la red se reduce.

SNMP usa el puerto 161 UDP para enviar y recibir consultas, y el puerto 162 pararecibir notificaciones desde un agente. Cada equipo que implementa SNMP deberıausar estos puertos por defecto, pero esto no ocurre y es importante configurar tanto laestacion como el agente para que se comuniquen mediante los mismos puertos.

La Figura 2.4 muestra la suite de protocolos TCP/IP usada en SNMP. Hoy, cualquierrecurso que desee comunicar en Internet (ej. sistemas Windows NT, servidores Unix,routers Cisco, etc.) deberıa usar esta suite. Este modelo se describe como un stackde protocolos, en donde cada capa usa la informacion de su capa inferior y provee unservicio a su capa superior.

15

2. Protocolo SNMP

Figura 2.4: Modelo de comunicacion TCP/IP y SNMP [3]

2.5. Comunidades

SNMPv1 y SNMPv2 utilizan la nocion de comunidad para establecer la conexionsegura entre NMS y agente. Un agente se configura a traves de tres tipos de comunidad:solo-lectura, lectura/escritura, y notificacion. Los nombres de comunidad son contra-senas no habiendo diferencia alguna con aquella que se utiliza por ejemplo para teneracceso al PC. Los tres tipos de comunidad controlan diferentes tipos de actividad, deesta manera el tipo solo-lectura permite solo leer los datos, en cambio lectura/escriturapermite leer y modificar valores de los objetos, ası como por ejemplo cambiar la configu-racion de un router. Finalmente, las comunidades de tipo notificacion permiten recibirmensajes de alerta desde el agente.

El problema con este tipo de autentificacion es que los nombres de las comunidades seenvıan en texto plano, lo que hace que sea facil para otras personas interceptarlos y usardichos nombres para fines equivocados. Debido a esto que SNMPv3 da la posibilidad dedar integridad a los datos mediante niveles de autentificacion en la comunicacion entreequipos SNMP.

Ademas tal como se menciono, si una estacion tiene un nombre de comunidad paralectura/escritura sobre un agente, tiene la facultad de realizar modificaciones a deter-minados objetos (por ejemplo, configurar las interfaces de un router, desactivar puertos,o modificar las tablas).

16

2. Protocolo SNMP

Uno de los caminos para proteger la comunidad es usando Redes Privadas Virtuales(VPN) y ası asegurar que los mensajes se transmitan en un medio encriptado. Otraopcion es cambiar el nombre de la comunidad constantemente. Esta ultima opcion escomun para redes pequenas, pero para una red que tiene verdaderas ciudades de spanso maneja mas de cientos o miles de equipos, cambiar el nombre de comunidad puedeser un problema [4].

2.6. RMON: Monitoreo Remoto

RMON esta fuera del alcance de este proyecto pero explicaremos su relacion conSNMP, y ası tener una idea clara de su funcionamiento ya que muchos switches yrouters lo implementan. RMON se utiliza para crear puntos de pruebas que tıpicamenteson equipos independientes que miran el trafico en segmentos de la red en donde seproduce acumulacion. Algunas empresas implementan al menos un tipo de RMON ensus routers, hubs, o switches [3].

La version 1 RMON (RMONv1) se define en el RFC 2819; una mejora a este estandares RMONv2 definido en RFC 2021. RMONv1 provee a la estacion con paquetes de nivelestadıstico para una LAN o WAN. Una alternativa serıa colocar un punto de pruebaRMON en cada segmento de la red que se quiere monitorear. Muchos routers tienencapacidades limitadas de RMON, ası que solo se pueden usar sus funcionalidades paratareas de menor importancia (e.g. routers Cisco). Pero por ejemplo algunos switches3Com implementan la especificacion completa de RMON.

El objeto MIB (Management Information Base) RMON fue disenado para tenerun punto de prueba corriendo en modo offline que permita almacenar estadısticas dela red, pero sin la necesidad de consultar a una estacion constantemente. Puede darseel caso que la estacion quiera consultar a su punto de prueba por estadısticas que haalmacenado. Otra funcion y que muchos puntos de pruebas implementan es la habilidadde fijar los umbrales para varias condiciones de error y cuando cruza este umbral, alertaa la estacion generando una notificacion. El MIB RMON define 10 grupos de objetosdescritos en la Tabla 2.5.

17

2. Protocolo SNMP

Tabla 2.5: Nuevos tipos de datos para SMIv2

Objeto OID Descripcion

statistics 1.3.6.1.2.1.16.1 Contiene estadısticas sobre todas las interfaces Ether-net monitoreadas por el punto de prueba.

history 1.3.6.1.2.1.16.2 Almacena periodicamente muestras simples desde elgrupo de estadıstica.

alarm 1.3.6.1.2.1.16.3 Permite a un usuario configurar un intervalo cualquie-ra de muestras y un umbral para cualquier objeto queel punto de prueba registre.

hosts 1.3.6.1.2.1.16.4 Almacena estadısticas sobre trafico de cada host en lared.

hostTopN 1.3.6.1.2.1.16.5 Contiene estadısticas de hosts usadas para generar re-portes sobre hosts que estan dentro de una lista pedidapara un parametro dado.

matrix 1.3.6.1.2.1.16.6 Almacena errores e informacion de utilizacion paraconjuntos de dos direcciones.

filter 1.3.6.1.2.1.16.7 Recibe paquetes mediante una ecuacion de filtraje;cuando un paquete cumple con el filtro, el podrıa sercapturado o un evento podrıa ser generado.

capture 1.3.6.1.2.1.16.8 Permite capturar paquetes si ellos cumplen con un fil-tro dentro de un conjunto.

event 1.3.6.1.2.1.16.9 Controla la definicion de eventos de RMON.

En el caso del agente Net-SNMP [13] no hay un soporte real de RMON-MIB. Aunqueeste esta incluido como modulo, pero solo esta definido como una especie de templatepara los grupos estadısticos RMON-MIB, mas que un paquete completo. Se que laparte mas difıcil de implementar un MIB es sostener los datos para generar reportes.En RMON-MIB ocurre exactamente esto, ya que es posible almacenar (y analizar)grandes cantidades de paquetes sobre trafico en la red. Algunas de las funcionalidadesde RMON-MIB, ası como alarmas y grupos de eventos, han sido utilizadas por el grupoDisMan de IETF [16]. Este agente implementa estos modulos MIB, pero en el aspectode almacenamiento de estadısticas de RMON-MIB no esta totalmente disponible.

18

2. Protocolo SNMP

2.7. Arquitecturas NMS

Antes de construir un sistema de administracion remota, es importante planificarque tipo de arquitectura es mejor para manejar una determinada red. El prototipo dearquitectura mas simple consiste en una sola estacion de administracion, responsablede toda la red [4].

Figura 2.5: Arquitectura simple de NMS [4]

En el ejemplo de la Figura 2.5 se pueden apreciar la existencia de tres zonas: NewYork, Atlanta, y San Jose. Las notificaciones enviadas desde Atlanta o San Jose debenviajar por Internet, para llegar a su estacion en New York. Para pequenas redes, unaarquitectura ası puede trabajar bien. Sin embargo, la red puede crecer a un punto enque una sola estacion no es capaz manejar grandes cantidades de informacion, ası queeste modelo se convierte en un problema. La estacion en New York quizas no sea capazde almacenar datos de los sitios remotos, porque en ese instante debe procesar mu-cha informacion. Entonces cuando los problemas aumenten, los agentes podrıan no serconsiderados durante algun momento.

Otro factor importante es que muchas veces se producen fallas que deben ser in-tervenidas por personal interno mas la coordinacion necesaria. A veces no se tiene eltiempo completo para administrarlo, y se necesita de alguien con conocimiento que sepaque hacer en caso de que un equipo falle.

Para solucionar esto se dispone de un modelo distribuido de estaciones. La idea essimple: usar dos o mas estaciones de administracion y ubicarlas en los nodos que sonmanejados. En nuestro ejemplo serıa en las tres zonas: New York, San Jose y Atlanta.

19

2. Protocolo SNMP

Figura 2.6: Arquitectura de Tipo Distribuida de NMS [4]

En la Figura 2.6 se modifica el modelo anterior agregando dos nuevas estaciones. Unade las ventajas de hacer esto, es que las dos nuevas estaciones pueden actuar como enti-dades independientes, cada una con un staff suficiente para cumplir con las necesidadesde su zona, o simplemente reenviar los eventos a la estacion de New York. En la segundaalternativa, las dos nuevas estaciones proveen de algun tipo de interfaz de cliente paraver los eventos actuales en la estacion (traps recibidos, respuestas a consultas, etc.). Laestacion que adelanta los eventos a New York ya ha descubierto el problema, entonceseste ultimo solo tiene que tomar las medidas correctas para solucionar el problema, yno tener que ademas recibir notificaciones para saber de que se trata.

La otra ventaja es que si se presentan necesidades puedes poner un staff de operacio-nes para manejar cada una de las locaciones remotas. Si New York pierde conectividad aInternet, no serıa un gran problema porque las estaciones tienen la capacidad de actuarindependientemente.

Existe un tercer modelo denominado “hıbrido” [4] en donde el staff de operacionescentral en New York trabaja las 24 horas al dıa, los 7 dıas de las semana, pero tu staffen Atlanta y San Jose solo durante las horas de trabajo. De esta manera en horariosque no sean de trabajo, se confıa en la estacion de New York para notificar y manejarproblemas que se presenten, en el caso contrario, Atlanta y San Jose se encargan de suszonas.

La seguridad de la red es una consideracion importante, ya que en ambos modelosse usa la Internet para comunicar notificaciones y recibir paquetes de configuracion.Esta se ve afectada como tambien la confianza que se tiene del sistema. Una soluciones usar enlaces encriptados para ejecutar las funciones de administracion. La Figura 2.7muestra la arquitectura de NMS distribuido extendida para esta solucion.

20

2. Protocolo SNMP

Figura 2.7: Usando enlaces privados para administrar la red [4]

En este caso el router en New York es la base para toda la red. y establece enlacesprivados (enmarcados con negro en la Figura) entre San Jose y New York, y New Yorky Atlanta. San Jose no solo podra acceder a New York sino que tambien a Atlantavıa ese enlace, para trafico de administracion, aplicandose lo mismo para Atlanta. Laventaja que existe es que los nombres de comunidad (para SNMPv1/SNMPv2c) nuncaseran enviados por Internet. En caso de la existencia de una sola estacion la soluciontambien es aplicable. El problema que se puede presentar es que si la red corporativaconsiste solo de enlaces privados y las conexiones a Internet son solo dedicadas a traficode salida, entonces los enlaces privados pierden el sentido de comunicar informacionadministrativa.

2.8. Extension de un Agente SNMP

Extender las capacidades del agente usualmente tiene relacion a agregar o cambiarsu soporte MIB. La mayorıa de los agentes cubren solo un mınimo de objetos MIB,siendo frustrante si se tiene pensado automatizar la administracion de la red.

Actualizar la version de SNMP no ayuda a obtener mas informacion de un equiposi se usa SNMPv1. La informacion disponible por un equipo es definido en el MIB delagente siendo independiente del protocolo usado. La actual version agrega nuevas fun-ciones al protocolo principalmente en el aspecto de seguridad y opciones mas sofisticadaspara obtener y configurar valores [4].

21

2. Protocolo SNMP

Esta extension se puede definir como un programa o una ampliacion del conjuntode aplicaciones SNMP usada para aumentar la capacidad del MIB de un agente, en-tregando informacion desde una fuente externa (un script, programa o archivo). En lamayorıa de los casos el proceso es transparente para la estacion que esta consultandoo configurando a dicho agente, es decir, no diferencia entre el MIB nativo del agentey su extension. Muchas de las extensiones dan la capacidad de leer archivos, correrprogramas y devolver sus resultados, ası como por ejemplo tablas de informacion. Enalgunos casos se tienen opciones configurables que permiten correr programas externos,y funciones preestablecidas, ası como analizadores de discos [4].

En la Figura 2.8 se describe el funcionamiento de un agenteX. Su estructura consisteen una entidad de procesamiento denominada agente maestro y cero o mas entidadesdenominadas subagentes. Ambas entidades pueden residir en el mismo equipo o comu-nicarse mediante un proxy. El agente maestro se comunica con una estacion como sifuera un simple agente. Los subagentes tienen acceso directo a ciertos objetos MIB,no ası el maestro, realizando funciones de administracion en las variables, para luegocomunicarselas a su agente maestro a traves del protocolo AgentX, independiente aSNMP [9].

El conjunto de aplicaciones de Net-SNMP utilizada en el desarrollo practico de esteproyecto permite la configuracion de la extension del agente SNMP. En este caso nohace la distincion entre un agente maestro y la extension denominada esclavo; hay soloun agente de que preocuparse.

Figura 2.8: Arquitectura para agentes extensibles [4]

22

Capıtulo 3

Seguridad en SNMP

Simple Network Management Protocol version 3 (SNMPv3) es un protocolo basadoen estandares de interoperabilidad. Provee de accesos de seguridad para dispositivos dered (ej. routers, servidores) mediante una combinacion de paquetes de autentificacion yencriptacion sobre la red. Las principales caracterısticas de seguridad en SNMPv3 son:

Mensajes de integridad - Asegura que un paquete no haya sido manipulado en elcamino.

Autentificacion - Verifica si el mensaje viene de una fuente valida.

Encriptacion - Oculta el contenido de un paquete y ası evita que sea visto por unafuente no autorizada.

SNMPv3 especifica modelos y niveles de seguridad. Un modelo de seguridad es unaestrategia de autentificacion determinada para un usuario y grupo en que este resi-de. El segundo termino define el umbral permitido dentro del modelo de seguridad.La combinacion de un modelo y un nivel de seguridad determinara que mecanismosera empleado para intercambiar paquetes SNMP. Tres son los modelos de seguridaddisponibles: SNMPv1, SNMPv2 y SNMPv3, y tres son los niveles de seguridad: noAuth-NoPriv, AuthNoPriv, AuthPriv. La Tabla 3.1 describe las combinaciones posibles entreestos dos conceptos.

Tabla 3.1: Modelos y niveles de seguridad

Modelo Nivel Autentificacion Encriptacion

v1 noAuthNoPriv Comunidad Nov2c noAuthNoPriv Comunidad Nov3 noAuthNoPriv Usuario Nov3 authNoPriv md5 o sha Nov3 authPriv md5 o sha No

23

3. Seguridad en SNMP

Los Fundamentos de la seguridad en SNMPv3 se pueden describir a traves de los si-guientes puntos:

Cada usuario pertenece a un grupo.

Un grupo define sus polıticas de acceso para un conjunto de usuarios.

Una polıtica de acceso determina que objetos SNMP pueden ser accedidos paraleer, escribir y crear.

Un grupo determina que lista de notificaciones pueden escribir sus usuarios.

Un grupo tambien define el modelo y el nivel de seguridad para sus usuarios.

Beneficios:

Los datos pueden ser coleccionados en forma segura por equipos SNMP sin elmiedo de que hayan sido forzados o corrompidos.

Manejo de la informacion confidencial. Por ejemplo un conjunto de comandosSNMP que cambian la configuracion de un router pueden ser configurados paraprevenir la exposicion de su contenido en la red.

En SNMP existe la necesidad de tener seguridad, esto porque los objetos MIB queson comunicados contienen informacion crıtica de los equipos de la red. No se deseaque cualquier persona entre en la red para obtener direcciones IP, o informacion sobreel tiempo que los equipos han estado funcionando, o si los enlaces estan caıdos, en fintoda la informacion que hace referencia a la red. Esto es aun mas importante cuando seconfiguran los equipos a traves de SNMP con operaciones SetRequest Obviamente no sequiere que nadie mas pueda configurar o interferir con los equipos enviando comandospara cambiar objetos MIB que controlan la operacion de estos [4].

Una de las grandes debilidades en SNMP v1/v2c es la seguridad. En estas versionesla autentificacion no era mas que una contrasena basada en un nombre de comunidadenviada de forma de texto a una estacion. Su actual version (SNMPv3) se caracterizaprincipalmente por hacerle frente a este problema. No hay nuevas operaciones; SNMPv3soporta todas las operaciones definidas por la version 1 y 2c. Existen varias convencionesnuevas, pero solo son caminos diferentes para interpretar los tipos de datos, definidosen las versiones anteriores [3].

24


3.1. Primeros Pasos en SNMP

En SNMP v1, la seguridad incorporada era demasiado limitada; consistıa en unasola polıtica y una simple tecnologıa, descritas a continuacion.

Objetos debiles: SNMP fue creado pensando en que los objetos deben ser di-senados de tal forma que provoquen el menor dano posible en caso de presentarseuna falla en su funcionamiento. Los disenadores de SNMP usaron la polıtica de quelos objetos MIB que son normalmente leıdos no contengan informacion crıtica, encambio aquellos que son modificados no tengan el control sobre funciones crıticas.De esta manera, un objeto que es solo lectura y contiene descripcion del equipo esaceptado, no ası un objeto que mantiene informacion administrativa, ası como sucontrasena. De la misma forma, un objeto que puede ser leıdo y modificado puedecontrolar por ejemplo cuando un computador sera reiniciado, pero en ningun casotener el control sobre el reformateo de su disco duro.

Nombres de Comunidad: Una comunidad esta formada de todos aquellos equi-pos en la red que son administrados por un conjunto determinado de estacionesSNMP. Cada mensaje SNMPv1 enviado entre miembros de la comunidad es iden-tificado por un nombre que forma parte de su encabezado. Este nombre representauna simple contrasena evitando que un mensaje recibido con un nombre erroneosea aceptado.

Los nombres de comunidad protegen en situaciones en que se quiere forzar el sistemamediante el envıo de mensajes desautorizados. Sin embargo, esta simple contrasena seenvıa en texto plano y puede ser descubierta facilmente para luego ser usada para finesequivocados. En otras palabras con este modelo de seguridad se esta protegiendo la redde un agresor ocasional pero no del profesional.

3.2. Cambios en SNMPv3

Lo mas significativo de esta version es que abandona la nocion de estaciones yagentes. Ambos son llamadas entidades SNMP. Cada entidad consiste de un motor(engine) y una o mas aplicaciones, y permiten definir una arquitectura mas que unsimple conjunto de mensajes; la arquitectura genera una autonomıa de las piezas de unsistema SNMP, lo cual hace posible implementar aspectos de seguridad.

25


3.2.1. Motor SNMP

Un motor SNMP se compone a traves de 4 modulos: despachador, subsistema deprocesamiento de mensajes, subsistema de seguridad, y el subsistema de control deacceso [4].

El despachador tiene la funcion de enviar y recibir mensajes. Determinar la versionde cada uno de los mensajes (v1, v2c o v3) y, si la version es soportada, entonces losenvıa al subsistema para el procesamiento de mensajes. A demas tiene la facultadde enviar los mensajes recibidos a otras entidades.

El subsistema de procesamiento prepara los mensajes para ser enviados (encaso de consultas a otras entidades) o extrae los datos de aquellos mensajes que sonrecibidos desde alguna entidad en particular. Esta etapa contiene multiples modulosde procesamiento de mensajes. Por ejemplo, un subsistema puede tener modulos paraprocesar consultas SNMPv1, SNMPv2c y SNMPv3. Tambien puede tener un modulopara procesar otros modelos que puedan ser definidos a futuro.

El subsistema de seguridad provee servicios de autentificacion y privacidad. Laautentificacion puede ser basada en comunidades (v1 y v2c) o en usuarios (v3). Laautentificacion basada en usuarios usa los algoritmos MD5 o SHA [17] y ası evita enviaruna contrasena en texto plano. Para encriptar y desencriptar mensajes SNMP (conceptode privacidad) se usa el algoritmo DES. Actualmente DES ya no es el unico algoritmosoportado, en el caso del motor Net-SNMP tiene soporte DES y AES [18].

El subsistema de control de acceso es responsable de controlar el acceso haciaobjetos MIB. Es posible definir que objetos puede acceder un determinado usuario, yademas que operacion tiene permitido hacer sobre esos objetos. Por ejemplo, se podrıalimitar a un usuario con accesos de lectura-escritura para el subarbol mib-2 y para elresto del arbol solo puede realizar operaciones de lectura.

3.2.2. Aplicaciones SNMP

La Tabla 3.2 describe las aplicaciones disponibles en la version 3 de SNMP y querepresentan las acciones que pueden ser realizadas entre las entidades [4].

26


Tabla 3.2: Conjunto de aplicaciones para SNMPv3

Aplicacion Descripcion

Generador deconsultas

Genera las consultas Get, Getnext, Getbulk y Set, y ademas procesalas respuestas. Esta aplicacion la implementa una estacion, y de estamanera puede monitorear y configurar equipos de red (router, switch,hosts, etc).

Generador derespuestas

Responde a las consultas Get, Getnext, Getbulk, y Set. Esta aplica-cion es implementada en el agente (router, switch, host, etc).

Generador denotificaciones

Genera traps y notificaciones. Esta aplicacion es implementada en elagente (router, switch, host, etc).

Receptor denotificaciones

Recibe los traps y notificaciones. Esta aplicacion es implementadapor la estacion.

Proxy Permite facilitar el paso entre entidades. En otras palabras adelantalos mensajes de una entidad a otra. Puede ser implementada porambos NMS o agente.

La Figura 3.1 describe la distribucion de componentes dentro de cada una de lasentidades SNMP ya definidas [4].

Figura 3.1: Entidad SNMPv3 [4]

27


3.2.3. Convenciones definidas en SNMPv3

La Tabla 3.3 describe las convenciones que fueron agregadas en la version 3 deSNMP.

Tabla 3.3: Convenciones para SNMPv3

Convencion Descripcion

snmpEngineID Identificador unico para un motor SNMP. Los ob-jetos de este tipo se construyen para identificacion,y no para direccionamiento, aunque una direccionse puede usar para generar un valor especıfico (en-gineIDType y engineIDNic en Net-SNMP).

snmpSecurityModel Un nivel de seguridad SNMP (SNMPv1, SNMPv2co USM). USM se define como Modelo de seguri-dad basado en usuarios. que es implementado porSNMPv3.

snmpMessageProcessingModel Modelo de procesamiento de mensajes usado por elSubsistema para el Procesamiento de Mensajes.

snmpSecurityLevel Nivel de seguridad en que los mensajes son envia-dos, o en que las operaciones seran procesadas. Losvalores posibles son noAuthNoPriv (sin autentifica-cion, sin privacidad), authNoPriv (con autentifica-cion, sin privacidad), authPriv (con autenticaciony privacidad).

snmpAdminString Es un string que contiene informacion administra-tiva, preferentemente una palabra. Su largo puedeser mayor a 255 bytes.

snmpTagValue Es un string con un valor representativo. Este valorsegun el RFC 3413 puede ser entre otros: acme,router, y host.

snmpTagList Es un string que contiene una lista de valores re-presentativos (snmpTagValue).

KeyChange Objeto usado para cambiar las llaves de autentifi-cacion y privacidad.

28


3.3. Modelo USM

El Modelo de Seguridad basado en Usuarios (User-based Security Model o USM)y el Modelo de Vistas para el Control de Acceso (View-based Access Control Model oVACM) detallan la seguridad que implementa la version 3 de SNMP [4].

3.3.1. Aspectos Basicos

La Tabla 3.4 describe algunos de los terminos que forman parte del modelo USM enla version 3 de SNMP.

Tabla 3.4: Conceptos definidos en el modelo USM

Concepto Descripcion

snmpEngineID Identificador para un motor SNMP. La sintaxis para es-te identificador es OctetString y no puede tener un valornulo. Muchas aplicaciones SNMPv3 utilizan un valor deentrada para generar este identificador. Si no es especifi-cado entonces se usa una combinacion entre la enterpriseID y la IP o MAC.

snmpEngineBoots Contador del numero de veces que un motor SNMP esreiniciado.

snmpEngineTime El numero de segundos desde que el contador snmpEngi-neBoots cambio su valor por ultima vez.

snmpSecurityLevel Existen 3 niveles de seguridad, ya descritos en la seccionanterior: noAuthNoPriv, authNoPriv, y authPriv. Notaque puedes tener autentificacion sin privacidad pero noprivacidad sin autentificacion.

Motor SNMP autoritario Un motor no autoritario podrıa descubrir el snmpEngi-neID del motor autoritario con el que se esta comuni-cando. Si el motor SNMP requiere una respuesta (Get,Getnext, Bulk, Set o Inform) el receptor es el motor auto-ritario, en caso de requerir una respuesta (Trap o Report),el motor autoritario es quien envıa dicho mensaje. Gene-ralmente la estacion es el motor autoritario y el agente elmotor no autoritario.

Debido a la integracion de nuevos conceptos y polıticas, el formato SNMP ha sufridociertos cambios, agregando nuevos campos que son descritos en la Tabla 3.5.

29


Tabla 3.5: Formato de un mensaje SNMPv3

Campo Descripcion

msgVersion Version del mensaje.msgID Identificador usado entre NMS y agente para coordinar

mensajes de consulta y respuestas.msgMaxSize Tamano maximo del mensaje soportado.msgFlags Valor de 8-bits que especifica si un reporte debe ser gene-

rado, si se usa privacidad, y si se usa autentificacion.msgSecurityModel Especifica el modelo de seguridad usado.msgSecurityParameters Contiene informacion especıfica de seguridad.contextEngineID Identifica unicamente una entidad SNMP. Una entidad es

una combinacion entre el motor y aplicaciones SNMP. Endetalle se discute en la seccion siguiente.

scopedPDU Bloque de datos construido entre el campo contextEngi-neID, contextName, y el pdu.

La informacion de seguridad contenida en el campo snmpSecurityParameter se sub-divide en una serie de parametros que se describen en la Tabla 3.6, y permiten alreceptor entender dicho mensaje para ser procesado y luego llevar a cabo una accionsegun corresponda.

Tabla 3.6: Parametros de snmpSecurityParameter

Campo Descripcion

msgAuthoritativeEngineID snmpEngineID de un motor autoritario.msgAuthoritativeEngineBoots snmpEngineBoots de un motor autoritario.msgAuthoritativeEngineTime snmpEngineTime de un motor autoritario.msgUserName Usuario que puede ser autentificar y encriptar el

mensaje.msgAuthenticationParameters Es nulo si no hay autentificacion. En otro caso el

campo contiene el valor de la llave secreta (HMAC)para el mensaje. Actualmente se especifican los al-goritmos MD5 y SHA como alternativas de auten-tificacion.

msgPrivacyParameters Es nulo si no hay encriptacion. En otro caso su valores usado para formar el valor inicial del modo Cip-her Block Chaining del algoritmo Data EncryptionStandard (DES).

30


3.3.2. Descubrir a su Motor Autoritario

Antes de realizar cualquier consulta Get, Getnext o Set, el motor no autoritariodebe realizar el proceso de descubrir la informacion de seguridad del motor autoritario.Para ello se requiere que el campo msgSecurityParameter este definido con los valoresde los parametros snmpEngineID, snmpEngineBoots, y snmpEngineTime del motorautoritario.

3.3.3. Puntualidad USM

Una vez que el motor no autoritario conoce el valor de snmpEngineBoots y snmpEn-gineTime, debe tener la nocion que este valor puede cambiar, por lo que cada segundoque pase aumenta el valor que tiene contenido en snmpEngineTime y ası mantenerseactualizado con el motor autoritario. Este modulo esta preparado para actuar en casode que el valor de snmpEngineTime sufra un cambio abrupto (roll over).

3.3.4. Autentificacion

Los algoritmos MD5 y SHA1 pueden ser usados para autentificar mensajes SNMPv3.MD5 crea una palabra de 128-bits y SHA1 una de 160-bits. Ambas palabras no puedenser usadas solas, sino que en conjuncion con el algoritmo para generar llaves de autenti-ficacion (HMAC). La llave de autentificacion es compartida entre ambos motores antesque el mensaje sea procesado.

3.3.5. Privacidad

La encriptacion de datos SNMP es realizada usando el algoritmo CBC-DES. Ası comoen la autentificacion una llave debe ser conocida en ambos motores (autoritario y noautoritario), para realizar el proceso de encriptacion. Una tabla de usuario USM es usa-da para determinar la llave y descripcion que es transmitida con el paquete en el campomsgSecurityParameter.

3.3.6. Tabla de Usuario USM

Cada entidad mantiene una tabla que almacena todos los usuarios que tienen accesoal sistema vıa SNMP. Esta tabla incluye los siguientes elementos:

31


Tabla 3.7: Tabla de usuarios USM

Campo Descripcion

Username Nombre de usuario, a veces referido al nombre de seguri-dad.

Authentication protocol Especifica el protocolo de autentificacion si es que al-guno es usado. Los valores validos son: usmNoAuth-Protocol, usmHMACMD5AuthProtocol, y usmHMACS-HAAuthProtocol.

Authentication key y La frase clave usada para la autentificacion. Deberıa seral menos de 8-bits.

Privacy protocol Especifica el protocolo de privacidad usado. Los valoresvalidos son: usmNoPrivProtocol y usmDESPrivProtocol.

Privacy key La frase clave usada para la encriptacion. Deberıa ser almenos de 8-bits.

usmUserSpinLock Es un intento de bloqueo que permite coordinar multiplesintentos para modificar la tabla de usuario.

3.3.7. Llaves Localizadas

Una llave localizada permite a un usuario usar la misma llave de autentificacion y/oencriptacion en distintos motores SNMP. Es posible crear un administrador de llaves yası no tener que recordar la llave para cada motor que interactua con la entidad. Loscampos de tipo KeyChange permiten a los usuarios cambiar su llaves de seguridad.

3.4. Control de Acceso basado en Vistas (VACM)

Este modelo es usado para controlar el acceso a los objetos administrados. Estatarea se efectua en el subsistema de control de acceso que forma parte del motor SNMP.

3.4.1. Aspectos Basicos

Los campos del mensaje SNMPv3: msgFlags, msgSecurityModel, y scopedPDU sonusados por VACM para determinar los permisos sobre el objeto administrado. Si elusuario no tiene permitido acceder a un objeto particular entonces se genera un mensajede error que es retornado al motor dueno de la peticion. VACM usa 4 tablas de controlde acceso para diferentes aspectos.

A continuacion se hace una breve descripcion de cada tabla para entender su fun-cionamiento basico aplicado en la etapa de implementacion de este proyecto.

32


3.4.2. Tabla Context

La tabla vacmContextTable es un conjunto de objetos administrados que contienenderechos de acceso. Esta tabla almacena todos los contextos disponibles y es indexadapor el campo contextName.

vacmContextName Un nombre (caracterıstico) para el contexto.

3.4.3. Tabla Security to Group

La tabla vacmSecurityToGroupTable es usado para almacenar la informacion delgrupo. Un grupo es hecho desde cero o mediante la combinacion entre el modelo deseguridad (securityModel) y el nombre de seguridad (securityName). Esta combinaciondefine que objetos manejados pueden ser accedidos. Esta tabla es indexada mediantelos campos securityModel y securityName.

vacmSecurityModel Modelo de seguridad usado (ej. USM).vacmSecurityName Si se usa USM como modelo de seguridad, entonces se-

curityName and userName son identicos.vacmGroupName Nombre del grupo a que esta entrada de la tabla perte-

nece.

3.4.4. Tabla Access

La tabla vacmAccessTable es usado para almacenar los derechos de accesos definidospara los grupos. Esta tabla es indexada por groupName, contextPrefix, securityModel, ysecurityLevel.

33


vacmGroupName Nombre de un grupo con derechos de acceso.vacmAccessContextMatch Es una forma simple de especificar si el contextNa-

me debe ser considerado como exacto o como unprefijo. Si su valor es “exact” indica que el con-textName deberıa ser exactamente igual al valor envacmAccessContextPrefix. Si en cambio es “prefix”,contextName puede ser igual a los primeros carac-teres de vacmAccessContextPrefix.

vacmAccessContextPrefix ContextName deberıa ser igual a vacmAccessCon-textPrefix ya sea en forma parcial o exacta depen-diendo lo que indique vacmAccessContextMatch.

vacmAccessSecurityModel Modelo de seguridad (securityModel) que deberıaser usado para tener acceso.

vacmAccessSecurityLevel Define el nivel de seguridad (securityLevel) mınimopara tener acceso.

vacmAccessWriteViewName Nombre de la vista (viewName) MIB autorizadacon permiso de escritura para un grupo determina-do.

vacmAccessNotifyViewName Nombre de la vista (viewName) MIB autorizadacon permiso de notificacion para un grupo deter-minado.

3.4.5. Tabla View Tree Family

La tabla vacmViewTreeFamilyTable es usada para almacenar vistas MIB. Una vistaMIB es definida como una familia de vistas que representan un subarbol de objetos MIBcon un valor de mascara. La mascara indica que subidentificadores del subarbol asociadopor su OID es considerado en la definicion (se puede asociar a la mascara de una subred,ej. 192.168.28.0/24). Todas las vistas MIB son almacenadas en vacmViewTreeFamily-Table. Esta tabla es indexada por viewName y el identificador (OID) que representa alsubarbol MIB. El MIB VACM define un candado denominado vacmViewSpinLock, quees usado para permitir que varios motores SNMP pueden coordinar modificaciones aesta tabla.

vacmViewTreeFamilySubtree OID del subarbol que al combinarse con la mascara,define uno o mas vistas del subarbol MIB.

vacmViewTreeFamilyMask Su valor en conjunto con el correspondiente OID delsubarbol, define una o mas vistas del subarbol MIB.

vacmViewTreeFamilyType Indica si las correspondientes vistas del subarbolMIB definidas por la OID del subarbol y la mascarason incluidas o excluidas desde la vista MIB.

La Figura 3.2 permite comprender el flujo logico sobre el control de acceso a objetosMIB, describiendo aquellos campos que son fundamentales en cada etapa de procesa-miento de un mensaje SNMPv3.

34


Figura 3.2: Flujo Logico de VACM [4]

3.5. Administracion Distribuida (DisMan)

Un administrador de red distribuido es una aplicacion que actua en dos roles opues-tos; un rol de administrador realizando funciones de control, y un rol de agente quepuede ser configurado y observado remotamente.

Hoy en dıa con el crecimiento de las redes una administracion distribuida es vital,mas alla de si son manejadas por personas en forma directa o remotamente. Un aspectoimportante de como administrar es la capacidad que tiene un sistema de automonitoreoo que otro lo haga desde el exterior [12].

Este concepto se basa en el denominado MIB de eventos que provee la capacidadde supervisar objetos MIB en un sistema local o remoto y toma una accion cuandouna determinada condicion es encontrada. Este MIB fue pensado para evitar que unaestacion periodicamente consulte objetos para darse cuenta si surgio algun tipo de falla.De esta manera el equipo puede internamente supervisar objetos MIB y si por ejemploel valor de un objeto es modificado se puede generar una alarma que sera recibida porsu estacion.

35


MIB de eventos se desarrollo a traves de la experiencia con RMON, y provee unaserie de capacidades sobre alarmas y grupos de eventos. El gran aporte realizado sobrelo ya existente fue permitir que las alarmas sean generadas por objetos MIB que estanen otro elemento dentro de la red. Las alarmas definidas en RMON son definidas comotriggers en el MIB de eventos, pero el concepto es el mismo, ya que mantienen el manejode umbrales de RMON solo que le agregan el concepto de boleanos y en cuanto al envıode notificaciones en respuesta a las alarmas se agrega la capacidad de cambiar el valorde un objeto MIB.

36

Capıtulo 4

Traps e Informs

Traps e informs proveen un camino para que el agente de aviso a traves del envıo denotificaciones a una estacion cuando su estado no es el normal, o cuando sea necesariotener conocimiento de ello. Las notificaciones que sean generadas por un agente van adepender del soporte de MIBs que tenga. Para conocer cuales son los traps e informsdefinidos en el agente basta con buscar dentro de los archivos MIBs el termino trap-type (SMIv1) o notification-type (SMIv2).

La estacion puede ser configurada para responder a distintas notificaciones cuyarespuesta puede ser desde descartar el mensaje a correr una aplicacion que envıa uncorreo al administrador de la red dando aviso de lo ocurrido (o tomar una accion masdrastica, ası como apagar la fuente de alimentacion) [4].

4.1. La Necesidad de Traps en SNMP

En el caso de obtener informacion para fines de monitoreo, la interrogacion es untipo de comunicacion ideal. Por ejemplo, las consultas de tipo Get pueden ser usadaspara verificar la configuracion de un equipo, conocer la cantidad de errores generadosdurante un periodo de tiempo, o generar estadısticas. Ademas este tipo de comunicaciones el unico metodo para modificar el valor de los objetos en un equipo a traves de Set.

El problema de la interrogacion es que no esta adaptada para entregar la informacionen forma rapida. La razon es que este tipo de comunicacion es siempre iniciada porla estacion. Si algo importante ocurre en el agente, la estacion jamas se enterarıa amenos que se le consulte especıficamente por los datos que han sido modificados. Estosignificarıa que las variables necesitan ser comprobadas en cada momento por la estacionprovocando una sobrepoblacion de paquete SNMP en el caso de tener gran cantidad deequipos administrados. Para solucionar este problema, SNMP introdujo un nuevo tipode mensaje como es la interrupcion, cuya principal caracterıstica es que la comunicacionse inicia desde el agente [10].

37

4. Traps e Informs

4.2. Conceptos Basicos

Un trap es basicamente una notificacion asincronica enviado desde un agente auna estacion, a traves del protocolo de transporte UDP (puerto 162). Debido a que latransmision no es confiable el agente no puede saber si el trap ha llegado a destino, y laestacion tampoco puede asumir que ha recibido todas las notificaciones. Por supuesto,en una red poco congestionada, la mayorıa de los mensajes deberıan llegar a destino,pero si fuera el caso, entonces no hay razon para que sea administrada.

En detalle, los traps se pueden localizar en dos categorıas: genericos y especıficospara una empresa. Existen 7 tipos de traps enumerados de 0 a 6, tal como se indicaen la Tabla 4.1, permitiendo representar diferentes estados del sistema; desde reiniciodel sistema (coldStart) y cambios de estado de una interfaz (linkUp y linkDown) hastatrap especıficos dependiendo de la empresa (enterpriseSpecific). La razon de que lasnotificaciones sean un mecanismo de administracion poderoso, se debe a los traps es-pecıficos. Cualquier empresa con un numero de identificador MIB puede crear trapspara condiciones en que se considere vital supervisar. La nocion de un trap especıficoes extremadamente flexible porque las organizaciones permiten subdividir el subarbolMIB como ellas quieran. Por ejemplo, si el identificador de una empresa es 2789, su OIDcompleto es .13.6.1.4.1.2789, pudiendo definir traps como nodos cuyo identificador sean.1.3.6.1.4.1.2789.5000, .1.3.6.1.4.1.2789.5001, y ası sucesivamente.

4.2.1. Traps SNMPv2

En la version de SNMP los traps se definen como notification-type, eliminandola nocion de traps genericos, definiendolos como traps especıficos en MIBs publicos.

Un trap SNMPv2 es generado y transmitido por un agente en respuesta a unaalarma activada por una aplicacion. Luego sera usado para dar aviso a una estacion queun evento ha ocurrido o a una condicion presentada. Este mecanismo de envıo no tieneasociada una confirmacion por lo que el agente no espera una respuesta [11].

Es importante mencionar que en la version 3 de SNMP solo se agregaron aspectos deseguridad a su definicion en SNMPv2, ya sea en temas de autentificacion y privacidad.

38

4. Traps e Informs

Tabla 4.1: Traps genericos.

Nombre y numero Definicion

coldStart(0) Indica que el agente se ha reiniciado. Todas las variablesadministradas seran reiniciadas; variables de tipo Coun-ter y Gauge tendran valor 0. Este tipo de traps es util paraagregar un nuevo hardware a la red. Cuando un equipoes encendido, enviara un trap a su estacion la cual unavez recibido podra configurar sus parametros.

warmStart(1) Indica que el agente llevo a cabo su reinicio. Es este casola estacion no reiniciara sus variables.

linkDown(2) Se envıa cuando la interfaz de red de un equipo esta caıda.La primera variable enviada es el ındice de la interfaz(ifIndex).

linkUp(3) Se envıa cuando la interfaz vuelve a activarse. La primeravariable enviada es el ındice de la interfaz (ifIndex).

authenticationFailure(4) Indica que alguien ha tratado de consultar al agente perocon un identificacion incorrecta (comunidad o nombre deseguridad).

egpNeighborLoss(5) Indica que un vecino EGP1 este caıdo.enterpriseSpecific(6) Indica que el trap es especıfico de una empresa. Vende-

dores SNMP y usuarios pueden definir sus propios trapsbajo la rama private-enterprise del arbol MIB. Para pro-cesar este trap la estacion tiene que decodificar el numeroespecıfico del trap que es parte del mensaje SNMP.

4.2.2. Informs SNMPv2

SNMPv2 incorpora un segundo tipo de notificacion: InformRequest. Comparado conun trap no son lo mismo pero tienen dos aspectos que los relacionan: ambos mensajescomunican informacion mediante interrupcion y no interrogacion, y segundo, los dosmensajes pueden ser usados en conjuncion.

El proposito de un inform es facilitar la comunicacion entre estaciones generandomensajes de confirmacion ante la llegada de notificaciones. Si se desea que una estacioninforme a otra estacion entonces le envıa un mensaje de tipo InformRequest. Una vezrecibido el mensaje respondera enviandole un mensaje de tipo Response, y ası avisa queel mensaje fue recibido.

1Exterior Gateway Protocol, disenado para el uso entre redes, bajo el control de dos organizacionesdiferentes.

39

4. Traps e Informs

Un camino comun en que se usan ambos tipos de mensaje, es para diferenciaravisos cuando un trap ocurre. Por ejemplo un equipo administrado experimenta unafalla electrica, generando un Trapv2 que es enviado a la estacion #1. El administradordesea que los traps recibidos por la estacion #1 sean adelantados a la estacion #2, yde esta manera un mensaje InformRequest es usado para el enviar la informacion entreambas estaciones [10].

40

Capıtulo 5

Net-SNMPOpen Source SNMP System

Simple Network Management Protocol (SNMP) es un protocolo que permite super-visar los equipos que forman parte de una red. Net-SNMP es un conjunto de aplicacionesusadas para implementar los protocolos SNMPv1, SNMPv2c, SNMPv3 usando IPv4 eIPv6 [13]. Este conjunto incluye:

Aplicaciones de lınea de comandos para:

• Obtener informacion desde equipos capaces de manejar el protocolo SNMP,ya sea usando consultas simples (snmpwalk, snmpgetnext), o multiples reque-rimientos (snmpwalk, snmptable, snmpdelta).

• Manipular informacion sobre la configuracion de equipos SNMP (snmpset).• Obtener un conjunto de informacion desde un equipo SNMP (snmppdf, snmp-

netstat, snmpstatus).• Traducir objetos MIB entre OIDs numericos y textuales, y mostrar el conte-

nido y estructura de la MIB (snmptranslate).

Un explorador grafico de MIBs (tkmib), usando Tk/perl.

Un demonio para recibir notificaciones (snmptrapd). Las notificaciones pueden serguardadas en un log (como syslog o un archivo de texto plano), ser reenviadas aotro sistema de gestion de SNMP, o a una aplicacion externa.

Un agente configurable para responder a peticiones SNMP sobre informacion degestion (snmpd). Incluye el soporte para una amplia cantidad de modulos de infor-macion MIB, y puede ser aumentado usando carga dinamica de modulos, coman-dos y scripts externos, y los protocolos: SNMP multiplexing (SMUX) y AgentExtensibility (AgentX).

Una biblioteca para desarrollar nuevas aplicaciones SNMP, tanto en C como Perl.

41

5. Net-SNMP Open Source SNMP System

Net-SNMP esta disponible para muchos sistemas operativos Unix y tambien enMicrosoft Windows, siendo diferente su funcionamiento en cada uno de estos.

El proyecto Net-SNMP nace en 1992, en Carnegie-Mellon University. El grupo deRedes en CMU (dirigido por Steve Waldbusser) desarrollo la implementacion del pro-tocolo SNMP. Esta aplicacion contenıa una librerıa, un simple conjunto de comandos,y un agente (que entregaba mas del estandar de informacion administrativa definidaen RFC 1213). El codigo fue disponible publicamente, y usado por un gran numero depersonas (incluyendo varias companıas comerciales). En la actualidad muchos de loscodigos han sido contribucion de algunas fuentes abiertas de todo el mundo y mediantealgunos bug-patches de la comunidad, que ha provisto una ayuda importante para eldesarrollo de esta aplicacion.

5.1. Instalacion de Net-SNMP

En el sitio oficial de Net-SNMP se pueden encontrar los archivos ejecutables paralos diferentes sistemas operativos o si se desea, tambien esta disponible el codigo fuentepara su compilacion [13].

Debido a que esta implementacion requiere de funciones avanzadas tanto para elagente como para la estacion es necesario hacer uso del codigo fuente de esta aplicacion.Para ello, se recomienda leer los archivos de ayuda incluıdos en el paquete descargado,y ası entender mejor los pasos que se describen a continuacion:

Descargar la aplicacion y luego descomprimirla en un directorio cualquiera. Eneste caso, se utilizo la version no estable 5.4.1 pre-releases dado que contiene unacompleta implementacion del protocolo SNMPv3 para el receptor de notificacio-nes y ademas soluciona algunos bugs1 que se encontraron durante el periodo deadaptacion usando la version estable 5.4.

Entrar en el directorio creado, y ejecutar el script de configuracion configure.Dicho script chequeara nuestro sistema en busca de bibliotecas y paquetes quenecesita el sistema para compilar el codigo. Ademas, permite incluir una serie deopciones de compilacion que servira para activar los modulos necesarios para laimplementacion. La lınea comandos para el script de configuracion considerandolas opciones requeridas en la siguiente:

./configure --enable-embedded-perl --enable-shared--with-mib-modules=ucd-snmp/lmSensors --prefix=/usr/local/net-snmp

1bug: Error en un software o hardware que causa su mal funcionamiento.

42


Las opciones usadas permiten activar el soporte para Perl, cargar todas las fun-cionalidades disponibles para el receptor de notificaciones (en estacion), agregar elmodulo MIB llamado LM-Sensors para integrar informacion sobre el hardware dela central (en agente), y especificar la ruta en donde sera instalada la aplicacion.Definir la ruta de instalacion permite mantener un orden de la ubicacion de losdirectorios y ası facilitar a futuro el proceso de desinstalacion. La siguiente lıneade comandos permite obtener la lista completa de las opciones disponibles en elscript de configuracion:

./configure --help

El siguiente paso es compilar la aplicacion que permitira obtener en el directorioactual todos los archivos ejecutables.

make

El comando make traves de la opcion test permite realizar una prueba de compro-bacion para verificar si todos los modulos y librerıas seran cargados correctamenteuna vez finalizado el proceso de instalacion. La lınea de comandos completa paraeste caso es la siguiente:

make test

EL paso final es instalar los archivos ejecutables obtenidos en el proceso de com-pilacion, para lo cual se debe escribir como superusuario (root) la siguiente lıneade comandos:

make install

Al final de proceso se obtiene un conjunto de directorios que representan el con-junto de aplicaciones de Net-SNMP. Su ubicacion va a depender de la ruta espe-cificada como opcion en el script configure con la opcion --prefix. Desde estemomento la variable $netsnmpdir define la ruta de residencia del conjunto deaplicaciones de Net-SNMP (/usr/local/net-snmp).

Cabe destacar que durante el proceso de instalacion de Net-SNMP no se crean losscripts snmpd y snmptrapd en el directorio /etc/init.d, los cuales son necesarios parainiciar y finalizar los servicios SNMP (agente y receptor de notificaciones) mediante lasordenes/etc/init.d/snmpd{start|stop|} y /etc/init.d/snmptrapd{start|stop}. Una opcion serıaejecutar manualmente el agente y receptor de notificaciones mediante las lıneas $netsnmp-dir/sbin/snmpd y $netsnmpdir/sbin/snmptrapd respectivamente.

43


5.2. Configuracion para Agente SNMP

snmpd es un agente SNMP que escucha por el puerto UDP 161 (por defecto), es-perando la llegada de peticiones desde algun programa de gestion SNMP (estacion).Cuando recibe una peticion, recopila la informacion y lleva a cabo la operacion solici-tada.

EL agente se ejecuta como un demonio, es decir, permanece en segundo plano duran-te toda la ejecucion. En su arranque, buscara su archivo de configuracion snmpd.conf)en los directorios$netsnmpdir/etc/snmp, /usr/lib/snmp, $home/.snmp y /var/lib/snmp siguiendoeste mismo orden. Dicho archivo describe el comportamiento del agente durante la eje-cucion, aunque no es imprescindible para que este funcione y responda peticiones, yaque tiene por defecto una configuracion preestablecida.

En la secciones siguientes se describen algunas de las directivas que forman partede la configuracion del agente SNMP, las cuales forman parte primordial de esta imple-mentacion. Con el fin de usar al maximos las funciones del protocolo SNMPv3, es que elnivel de seguridad configurado sera authPriv, es decir, toda consulta sera autentificadaa traves de un nombre de seguridad y contrasena, y encriptada para evitar ataques sobrela configuracion de equipos.

5.2.1. Aspectos Fundamentales para la Implementacion

Informacion Basica del Sistema

Algunas de las siguientes directivas modifican el valor de varios objetos MIB, y otrassolo sirven para la propia configuracion del agente. En caso de configurar una de estasdirectivas, se convertira en un objeto de solo lectura y, por tanto no se podra cambiarsu valor a traves del comando snmpset.

∴ syslocation stringCambia el valor del objeto system.sysLocation, usado para especificar la localiza-cion fısica del host en donde se ejecuta el agente.

syslocation ‘‘Laboratorio ATMLab’’

∴ syscontact stringPermite definir la direccion de contacto de la persona responsable del equipo, atraves del objeto system.sysContact.

syscontact ‘‘[email protected]’’

44


∴ sysname stringEspecifica el nombre del equipo a traves del objeto system.sysName. Generalmentese refiere al nombre completo del dominio.

sysname ‘‘BIONICO-Server.atmlab.utfsm.cl’’

∴ sysservices numberEl objeto system.sysServices indica el conjunto de niveles de la arquitectura OSIque el host puede soportar. El valor del objeto es una suma que inicialmente valecero. Para cada capa L de la arquitectura OSI soportada por el equipo, sumamosa sysServices el valor de 2 elevado a L-1. En caso de que el equipo no soporte OSI(el caso mas general), solo se debe tener en cuenta los niveles 1 (fısico), 2 (enlace),3 (red), 4 (transporte) y 7 (aplicacion). De esta manera el valor recomendado paraun servidor (o central IP-PBX) es 72 (capa de transporte y aplicacion).

sysservices 72

∴ sysdescr stringCrea un breve descripcion del equipo editando el objeto system.sysDescr. Por con-vencion contiene un nombre completo, una descripcion del hardware, del sistemaoperativo y del software de red.

sysdescr ‘‘BIONICO-Server.atmlab.utfsm.cl Linux2.6.18-4-686’’

∴ agentgroup idgroupEsta directiva causa que el agente cambie su identificador de grupo despues deabrir el puerto en el que escucha. IDgroup puede ser el nombre de un grupo osu identificador numerico y corresponde en el caso de esta implementacion a ungrupo registrado en el sistema Linux.

agentgroup root

∴ agentuser idusuarioFunciona en forma analoga a la directiva agentgroup, solo que en este caso refiereal identificador de usuario del sistema Linux.

agentuser root

45


Las directivas agentuser y agentgroup hacen referencia a un usuario y grupo delsistema respectivamente, es decir, ambos deben existir para el sistema operativo.Es importante que el usuario tenga privilegios suficientes para ejecutar aplica-ciones del sistema, las cuales son fundamentales para implementar el sistema deadministracion distribuida (DisMan) descrito en detalle en la seccion 3.5 y quemas adelante se dan los pasos para su configuracion. Con el simplificar el proce-so, se utilizo al superusuario root ya que tiene todos los permisos para ejecutarlos comandos que seran invocados por el agente para realizar tareas de compara-cion sobre aquellos objetos MIB definidos en las reglas que contengan la directivamonitor.

Configuracion SNMPv3

Para responder a mensajes SNMPv3 se requiere definir un identificador unico parael agente SNMP denominado engineID. Este ID normalmente se determina automati-camente, usando dos valores que no son faciles de predecir: un valor aleatorio y lossegundos que el agente esta activo desde su ultima ejecucion. El metodo anterior seconsidera el recomendado, sin embargo existe la posibilidad de generar su ID a travesde un palabra cualquiera. Por motivos de seguridad se recomienda que la palabra seaescogida pensando como si fuera una contrasena, no siguiendo el ejemplo siguiente comoreferencia.

∴ engineID stringEl engineID es construido desde la palabra definida como String.

engineID 01020304050120

46


Control de Acceso

snmpd soporta View-Based Access Control Model (VACM) definido en el RFC 2575,descrito en detalle en la seccion 3.4 de este documento. Para este fin hay varias directivasrelacionadas con el control de acceso, las cuales se pueden representar en 4 gruposbasicos.

∴ rouser user [noauth|auth|priv [oid | -V view [context]]]

∴ rwuser user [noauth|auth|priv [oid | -V view [context]]] Especifica un usuarioSNMPv3 que tiene permisos de solo lectura (get y getnext) o lectura-escritura(get, getnext y set) respectivamente. Por defecto, permite el acceso a todo elarbol oid para requerimientos autentificados SNMPv3 (auth), usando el contexto“ ” por defecto. Una alternativa pero que entrega el mınimo nivel de seguridades usar “noauth” (permite requerimientos no autentificados), o el maximo de se-guridad a traves de “priv” (para forzar el uso de encriptacion). EL campo oidrestringe el acceso para ese usuario al subarbol cuya raız es oid, o la vista descritapor view. Opcionalmente se puede definir un contexto o un contexto.* para de-notar un prefijo del contexto. Si no se especifica el campo context (o la opcion* es usada), esta directiva no discriminara entre los contextos existente.

rouser root priv .1rwuser pc120encrypter priv .1

En este caso se definio el acceso de dos usuarios, en donde root corresponde al usua-rio del sistema para efectuar la tareas de la directiva monitor, y pc120encrypteres el medio de autentificacion para realizar consultas desde la estacion de admi-nistracion. El proceso de creacion se realiza en la directiva createUser descrita endetalle en la seccion 3.2.3.

∴ rocommunity community [source [oid]]

∴ rwcommunity community [source [oid]]Especifica una comunidad SNMPv1 o SNMPv2c cuyos permisos seran de sololectura (get y getnext) o lectura-escritura (get, getnext y set) respectiva-mente. Por defecto, se puede acceder al arbol completo, sin importar el origende las peticiones. source puede ser usada para restringir el acceso a peticionesdesde uno o mas sistemas especificados. El campo oid restringe el acceso para estacomunidad al subarbol cuya raız es el oid. Los contextos son tıpicamente menosrelevantes a las versiones SNMP basadas en comunidades, pero su comportamientose aplica de igual forma.

rwcommunity voipcommunity localhost

47


En cada caso, solo una directiva puede ser especificada para un usuario SNMPv3o comunidad dada. No es recomendable especificar ambas directivas : rwuser yrouser refiriendose al mismo usuario SNMPv3 (u opciones de comunidad equiva-lentes). La directiva rwuser provee todo el acceso de rouser (ademas del soporteset). Lo mismo se aplica para las directivas basadas en comunidad (rocommunityy rwcommunity).

∴ com2sec [-Cn context] secname source communityRelaciona una comunidad SNMPv1 o SNMPv2c a un nombre de seguridad - quepuede ser desde un rango determinado de fuentes (source), o en forma general(“default”). Una fuente restringida puede ser entre un determinado equipo (o di-reccion), o una subred - representada como ip/mask (ej. 10.10.10.0/255.255.255.0)o ip/bits (ej. 10.10.10.0/24).Una comunidad puede aparecer en varias directivas separadas (presumiblementecon diferentes fuentes (source), pero es la primera combinacion fuente/comunidadque se aplique a la peticion de entrada la que sera elegida.Varias combinaciones fuente/comunidad pueden ser relacionadas al mismo nom-bre de seguridad.Si se especifica context (usando -Cn), la comunidad sera relacionada a un nom-bre de seguridad en el contexto SNMPv3 escogido. En otro caso se usara el con-texto por defecto es (“ ”).

com2sec local localhost voipcommunity

∴ group group {v1|v2c|usm} secnameRelaciona un nombre de seguridad a un grupo especıfico. Un grupo puede estarrelacionado a varios nombres de seguridad apareciendo mas de una vez esta di-rectiva con el mismo nombre de grupo, permitiendo ası una sola configuracion deacceso aplicable a varios usuarios y/o comunidades.Los grupos pueden ser configurados en forma separada para dos modelos basa-dos en comunidad (ej. v1 y usm) - una sola directiva com2sec (o equivalente)sera tıpicamente acompanada por 2 directivas group.

group localgroup v1 localgroup localgroup v2c localgroup localgroup usm local

48


∴ view vname type oid [mask]Se define una vista como un conjunto de objetos del arbol oid. Varias de estasdirectivas pueden especificar un mismo nombre vname, para construir una colec-cion mas compleja de oids. El campo type puede ser include o excluded, quepermiten definir una vista mas compleja (ej. excluir ciertos objetos mas sensiblesdesde otro subarbol accesible).mask es una lista de octetos hexagesimales (opcionalmente separados por . o :)en donde los bits cuyo valor es 1 indican que subidentificadores oid se aplican ala vista. Si esto no se especifica, por defecto todos los bits tienen valor 1.

view all included .1 80view system included system feview mib2 included .iso.org.dod.internet.mgmt.mib-2 fc

∴ access group context {any|v1|v2c|usm} level prefx read write notifyRelaciona un grupo de usuarios/comunidades (con un particular nombre de se-guridad y mınimo nivel de seguridad, y en un contexto especıfico) a una o masvistas, dependiendo de la peticion que es procesada.El campo level puede ser “noauth”, “auth” o “priv”. prefx especifica como debeser aplicado context, el contexto de la peticion de entrada, ya sea como .exact.o

”prefx”. read, write y notify especifica la vista que sera usada para peticionesget*, set y trap/inform. Para accesos v1 o v2c, level necesariamente debeser “noauth”.

access localgroup v1 noauth exact system none noneaccess localgroup v2c noauth exact mib2 none noneaccess localgroup usm auth exact all all all

Monitoreo Activo

El agente SNMP normalmente espera por una peticion desde una estacion para pro-cesarla y luego responder. Si no ha recibido ninguna peticion, el agente no inicia ningunaaccion. En esta seccion se describen aquellas directivas que permiten hacer su rol muchomas activo y usar el mas alto nivel de seguridad en SNMPv3.

Estas directivas fueron configuradas para que el usuario pc120encrypter sea quienenvıe las notificaciones a su estacion de administracion. Ademas se activo la funcion degenerar mensajes de alarmas en caso de recibir consultas con fallas de autentificacion,es decir, nombre de seguridad, engineID y/o contrasena erronea.

49


∴ trapsess [snmpcmd args] hostPermite definir un metodo generico para definir el destino de las notificaciones.snmpcmd args son aquellas opciones usadas en los comandos: snmptrap o snm-pinform utilizados para enviar cualquier notificacion. La opcion -Ci puede serusada (con -v2c o -v3) para generar un informe.Esta directiva es muy util para definir receptores de traps SNMPv3.

trapsess -e 0x80001f88043031303230333034303530313230 -v 3 \-u pc120encrypter -l authPriv 192.168.28.101:162

nota: Para la generacion de traps v3 a traves de esta directiva es necesa-rio especificar su propio engineID, pero no ası aquellas opciones de autentifi-cacion y privacidad ya que son leıdas desde su archivo de creacion de usuarios(/var/net-snmp/snmpd.conf).

∴ authtrapenable {1 | 2}Si su valor es 1, activa la generacio de notificaciones por fallas de autentificacion(por defecto su valor es 2). Esta directiva al ser declarada, convierte el objeto MIBsnmpEnableAuthenTraps.0 en solo lectura (originalmente es lectura-escritura).

authtrapenable 1

DisMan Event MIB

Las directivas anteriores permiten definir donde seran enviadas las notificacionesgeneradas, pero no el instante en que seran enviadas, o quienes deben ser generados.Esto le corresponde al subarbol Event MIB desarrollado por Distributed Management(DisMan), grupo de trabajo de IETF.

∴ agentSecName name

∴ iquerySecName nameDefine al usuario SNMPv3 por defecto para realizar consultas internas sobre in-formacion necesaria, ya sea evaluar una expresion monitoreada o construir unanotificacion. Este usuario debe ser creado explıcitamente mediante la directivacreateUser y con accesos apropiados. Ademas debe ser un usuario registrado delsistema descrito a traves de las directivas agentuser y agentgroup.

nota: Si se usa cualquiera de las directivas de DisMan, especificar la directivaagentSecName de lo contrario el demonio generara errores sobre usuario requerido.

iquerySecName root

50


∴ monitor [options] name expressionDefine un objeto MIB de monitoreo. Si la condicion expression se cumple, en-tonces se acciona un determinado evento, luego puede enviar una notificacion oescribir un objeto previamente asignado (o ambos). El evento solo se activara unavez que la expresion se cumpla por primera vez, y no se volvera a activar hastaque dicha condicion sea falsa y luego se vuelva a cumplir. name es un nombre ad-ministrativo para esta expresion, y se usa para indexar la tabla mteTriggerTable(y derivados).

expressionExisten 3 tipos de expresion soportadas por el Event MIB: test de exis-tencia, booleano, y umbral.

oid — !oid — !=oiddefine un test de existencia(0). El oid especifica un test, que sera activadocuando (una instancia de) el oid es creado.La expresion !oid especifica un test .ausente”, que se activara cuando el oides eliminado.La forma !=oid especifica un test ”modificado”que se activara cuando el valorde oid cambie.

oid op valuedefine un test booleano(1). op puede ser uno de los operadores (! =,==, <,<=, >, >=) y value debe ser un valor entero para la comparacion.

oid min max [dmin dmax]define un test de umbral(3). min y max son valores enteros, que especifican losniveles mınimo y maximo respectivamente. Si el valor de oid no cumple conambos niveles entonces el monitor activara un determinado evento.Al aumentar el umbral el test sera actualizado cuando el valor monitoreadoesta por debajo de min. En el caso que el umbral disminuya el test se actualizacuando el valor pasa a max.Los parametros opcionales dmin y dmax crean pruebas similares, pero traba-jando con diferenciales entre muestras sucesivas.

51


optionsExisten varias opciones para controlar el comportamiento de la expresionmonitoreada. Estas son:

-dLa expresion debe ser evaluada usando el diferencial entre muestras.

-d oid-di oidEspecifica un marcador de discontinuidad para validar diferenciales. Si tiene lainstancia -di sera usado exactamente como esta dado. Pero si tiene -d se con-sidera como un subarbol. Si se especifica el flag -I , entonces no hay diferenciaentre esas dos opciones.

-e eventEvento que sera invocado cuando el monitor es activado. Si esta opcion no sedeclara, entonces se generara una de las notificaciones definidas en el DISMAN-EVENT-MIB.

-IIndica que la expresion monitoreada debe ser aplicada a un oid especıfico (nocomo un subarbol). Por defecto, el oid debe ser tratado como un subarbol yası el monitor cubre todas las instancias posibles.

-i oid-o oiddefine nombres de objetos adicionales que seran incluıdos en la notificacion,ademas de los objetos referidos para esta directiva. Puede ser util cuando sequiere enviar una fila completa de la tabla.Si no esta la opcion -I contenida en options, entonces cualquier objeto delsubarbol puede ser agregado usando la opcion -o y el oid padre, en cambiosi utilizamos -i entonces solo se considera la oid explicitamente. Si el flag -Iesta declarado entonces no hay diferencia entre ambas opciones.

-r frecuencyevalua la expresion cada frecuency segundos. Por defecto la expresionsera evaluada cada 600s (10min).

-SIndica que la expresion no deberıa ser evaluada cuando el agente se inicie sinocuando el periodo expire por primera vez.

52


-sIndica que la expresion debe ser evaluada al inicio del agente y esta definidopor defecto.

-u secnameEspecifica al usuario que se usara para escanear el sistema, en el caso de quesea diferente al definido en la directiva iquerySecName. Este usuario debe sercreado explıcitamente y con permisos de accesos adecuados.

A continuacion se describen las reglas usadas para la construccion del Sistemade Reconocimiento de Fallas, las cuales tienen como objetivo analizar aquellosservicios de mayor interes sobre un servidor que en este caso actuara como centralIP-PBX, tal como se detallan en la Tabla 5.1.

monitor -r 60 -e linkUpTrap -u root -s "Generate linkUp"\ifOperStatus.2 ==1

monitor -r 60 -e linkDownTrap -u root -s "Generate linkDown"\ifOperStatus.2 ==2

monitor -r 60 -u root -o memErrorName -o memSwapErrorMsg \-s "memory"memSwapError != 0

monitor -r 60 -u root -o laNames -o laErrMessage \-s "laTable"laErrorFlag != 0

monitor -r 60 -u root -o lmTempSensorsDevice.1 -I \-s "lmtempmotherboard"lmTempSensorsValue.1 20000 40000

monitor -r 60 -u root -o lmTempSensorsDevice.2 -I \-s "lmtempcpu"lmTempSensorsValue.2 40000 60000

Sobre el analisis de carga de la CPU y uso de memoria Swap, son necesarias lasdirectivas load y swap para describir los niveles maximos y mınimos permitidosy que en caso de no cumplirse se activara el flag de error segun corresponda. Acontinuacion se describen los valores definidos para esta implementacion.

Tabla 5.1: Objetos monitoreados en la central IP-PBX 3

item objeto descripcion

laTable laLoadInt.1-3 El porcentaje de carga promedio delprocesador para 1, 5 y 15 min no de-be sobrepasar de 80, 40 y 30 % res-pectivamente.

lmtempcpu lmTempSensorsValue.2 La temperatura de la CPU no debesobrepasar los 50 oC.

lmtempmotherboard lmTempSensorsValue.1 La temperatura de la placa madreno debe sobrepasar los 40 oC.

memory memAvailSwap, El uso en memoria Swap nomemTotalSwap debe sobrepasar los 256 KBytes.

53


∴ load max1 [max5 [max15]]Analiza la carga promedio del sistema, especificando los valores maximos para unpromedio de 1, 5 y 15 min. Si alguno de estos valores excede el maximo descritoentonces el correspondiente flag laErrorFlag tendra valor 1, describiendose dichoerror en el objeto laErrMessage. Cabe destacar que los valores descritos en estadirectiva son tratados como porcentajes.

load 80 40 30

∴ swap minAnaliza la cantidad de memoria Swap disponible en el sistema. En el caso deque este debajo de min kb, entonces el objeto memErrorSwap tendra valor 1,describiendose dicho error en el objeto memSwapErrorMsg.

swap 256

∴ notificationEvent ename notification [-n] [-i oid | -o oid ]*Define un evento para una notificacion cuyo nombre es ENAME. Este puede seractivado desde la directiva monitor especificando la opcion -e ename. notifica-tion debe ser un oid definido como notification-type para ser generada.Si se da la opcion -n, la notificacion incluira los objetos como esta especificadoen la clausula object de la definicion de mib de notificacion. Esta opcion debevenir despues de notification (y el archivo del mib debe estar disponible y car-gado por el agente). En otro caso estos objetos deberan ser listados explıcitamente(aca o en la correspondiente directiva monitor).Las opciones -i oid y -o oid especifican adicionales objetos para ser agregados alpayload de la notificacion, despues de la lista estandar. Si la entrada que activo es-te evento involucra una expresion * (se considera un subarbol de oids), el sufijode la instancia involucrada sera agregada a cualquier oid especificado usando -o,mientras que aquellos especificados con -i seran tratados como instancias exactas.Si la opcion -I fue especificada en la directiva monitor, entonces no existe diferen-cias entre ambas opciones.

54


Configuracion de subagentes AgentX

AgentX es un protocolo que permite al agente estar dividido en varios procesosseparados, ya sea un solo host o entre varios hosts de una red. Para el desarrollo de estaimplementacion se configuro este agente como maestro para ser el medio de intercambiode consultas entre la estacion de administracion y la aplicacion Asterisk.

Las operaciones internas de AgentX son totalmente transparentes para la estacionSNMP, es decir, cuando consulta al agente, siempre tendra la impresion de estar tratandocon un agente SNMP convencional.

∴ master agentxSe usa esta directiva para definir al agente como maestro dentro del protocoloAgentX.

∴ agentXSocket [<transport-specifier>:] <transport-address> [, ...]Esta directiva define la direccion en la que escucha el agente master. Por defectose define el archivo “/var/agentx/master”, que es un socket Unix accesible solodesde subagentes que tengan el mismo identificador de usuario que el maestro. Eneste caso se define la ruta que viene en la configuracion por defecto.

agentXSocket /var/agentx/master

∴ agentXperms sockperms [dirperms [user|iud [group|gid]]]Define al propietario y sus permisos de acceso para el socket AgentX Unix Domain,a demas de su directorio raız. sockperms y dirperms deben ser dıgitos de 8 bits.Por defecto este socket solo sera accesible por subagentes que tengan el mismouserid que el agente.

agentXperms 0660 0550 root root

∴ agentXTimeout numDefine el periodo de timeout (num segundos) para una consulta AgentX. Pordefecto es 1 segundo.

agentXTimeout 5

∴ agentXRetries numDefine el numero de intentos para una consulta AgentX. Por defecto num es 5.

agentXRetries 10

55


Carga Dinamica de Modulos

La carga dinamica de modulos es una forma de incluir un nuevo modulo MIB en elagente (o subagente) sin tener que recompilarlo. En la version de Net-SNMP utilizadatiene activada esta funcion por defecto, pero para hacerla en forma explıcita es necesarioagregar la opcion --with-mib-modules=ucd-snmp/dlmod al momento de ejecutar elscript configure.

Los pasos a seguir para la compilacion rapida de modulos en un agente SNMP son:

Guardar los archivos referentes al modulo en un directorio comun.

cp Makefile /home/grupovoip/snmp/dlmod/cp nstAgentPluginObject.c /home/grupovoip/snmp/dlmod/cp nstAgentPluginObject.h /home/grupovoip/snmp/dlmod/

Ejecutar el comando make para compilar dicho modulo.Como resultado se obtiene un archivo con extension .so que sera cargado mediantela directiva dlmod descrita mas adelante.

make nstAgentPluginObject.so

Copiar la especificacion del objeto MIB en el directorio /usr/share/snmp/mibsy ası acceder a el a traves de su OID textual.

cp NET-SNMP-TUTORIAL.txt $NETSNMPDIR/share/snmp/mibs/

Este punto se debe realizar principalmente en la entidad SNMP que realizara lasconsultas al objeto descrito por dicho modulo, es decir, en la estacion de adminis-tracion encargada de este agente. Para que pueda ser reconocido por el sistema esnecesario exportar el nuevo valor de la variable de entorno MIBS. Para sistemasLinux la lınea de comandos requerida es la siguiente:

export MIBS=all

∴ dlmod nombre rutaEsta directiva permite cargar el modulo MIB especificado mediante ruta (debeincluir la ruta y el nombre completo) bajo el nombre especificado por NOMBRE.

dlmod nstAgentPluginObject ∼/snmp/dlmod/nstAgentPluginObject.so

56


5.2.2. Creacion de Usuarios SNMPv3

Para activar un usuario descrito en el archivo de configuracion snmpd.conf (directi-vas: rouser, rwuser y com2sec) se debe incluir una directiva createUser aunque no tengaasignado ninguna contrasena. La sinopsis para esta directiva es la siguiente:

∴ createUser [-e engineid] username [md5|sha] authpassphrase [des|aes] [priv-passphrase]

Para la autentificacion se pueden usar los protocolos md5 o sha. En caso de privaci-dad las alternativas son: des y aes. Si no se especifica la clave de privacidad, se asumeque es la misma que para la autentificacion. Los usuarios creados solo seran usadossiempre y cuando sean agregados a las tablas de control de acceso vacm descritas masadelante.

Si se desea usar los protocolos sha para autentificacion y/o des/aes para privacidadse necesita la previa instalacion de las librerıas de OpenSSL. El tamano mınimo decaracteres aceptados es de 8 tanto para la clave de autentificacion como para privacidad.

Por seguridad esta directiva debe ir en el archivo de configuracion persistente ubi-cado en /var/net-snmp/snmpd.conf. La informacion que es leıda desde este archivo eseliminada (eliminando el repositorio del administrador de contrasenas para ese usuario)y reemplazada por una llave derivada de ella, la cual recibe el nombre de llave localizada,de esta manera si es robada no puede ser usada para acceder a otros agentes. En cambiosi la contrasena es robada si se puede tener acceso. Para localizar un usuario a travesde un determinado ID (engineID) (es comunmente usada en snmptrapd.conf), se usa laopcion -e especificando su valor en hexagesimal (ej: ”0x01020304”).

createUser pc120encrypter MD5 snmpencrypted DES snmpencrypted

Para las llaves localizadas privadas (des/aes) se espera que tengan el largo nece-sario por el algoritmo (128 bits para todos los algoritmos soportados). En cambio lasclaves maestras localizadas necesitan tener el largo requerido por el algoritmo de au-tentificacion y no el largo requerido por los algoritmos de encriptacion (md5: 16 bytes,sha: 20 bytes).

57


5.2.3. Inicio del Agente SNMP

Una vez que configurado todo correctamente, es tiempo de iniciar la aplicacion. Esimportante recordar que el objetivo de esta implementacion es administrar remotamentelos servicios de telefonıa IP en una central IP-PBX a traves de su agente SNMP, por loque antes de iniciar sus servicios, es necesario configurar el subagente SNMP disponibledentro de la aplicacion Asterisk y tiene como funcion responder a consultas sobre losservicios entregados por la aplicacion. Una vez finalizado ese proceso, se puede darinicio a los servicios de ambas aplicaciones para establecer la conexion entre agente ysubagente SNMP a traves del protocolo AgentX.

5.3. Configuracion para Receptor de Notificaciones SNMP

Si en la seccion 5.2 se describieron las distintas posibilidades que ofrece el agente Net-SNMP para el envıo de notificacion, esta seccion aborda los aspectos de configuracionpara la recepcion de estas notificaciones que forma parte de las principales funciones deuna estacion de administracion.

5.3.1. Funcionamiento del Mecanismo de Notificaciones

El uso de notificaciones mediante los protocolos SNMPv1 y SNMPv2c es sencillo,puesto que el mensaje es mostrado tal cual al receptor. Sin embargo, en SNMPv3 esdiferente, se hace uso de autentificacion mediante nombre de seguridad y contrasena parainiciar la comunicacion con el proceso receptor de notificaciones. Entonces se requiereincluir previamente en la base de datos de usuarios aquellos de los cuales esta permitidorecibir notificaciones.

Generalmente, un usuario queda identificado mediante su nombre de seguridad y elengineID del receptor de notificaciones. Para usar el resto de las aplicaciones incluıdasen el paquete Net-SNMP (snmpget, snmpwalk...), estas descubren el engineID remotoe introducen en la base de datos de usuarios asociada a este engineID el nombre deusuario, el engineID y la contrasena.

El mecanismo de informes para SNMPv3 opera con este principio. Cuando se envıaun informe mediante snmptrap se usa el engineID remoto, y la combinacion de este valormas el nombre de seguridad deben existir en la tabla de usuarios remota. El programasnmptrap detectara el engineID remoto y creara un mensaje SNMPv3 adecuado para elinforme que se envıa.

58


Para el envıo de traps SNMPv3 es diferente, ya que este tipo de notificacion utiliza elengineID del agente (quien envıa el mensaje), en vez de la estacion (aquel que recibe eltrap). Esto quiere decir que al crear usuarios en la estacion receptora, se debe especificarsu engineID, teniendo ası un usuario por cada agente que se quiere recibir traps. Elproceso de creacion sera descrito en detalle en la seccion 5.3.3.

5.3.2. Demonio snmptrapd

La aplicacion que permite la recepcion de notificaciones es el demonio snmptrapd. Seejecuta como un servicio mas del sistema requiriendo privilegios de superusuario paramanipularlo, y por defecto escucha en el puerto UDP 162.

Una de las caracterısticas que tiene este demonio, es que al momento de su inicio sepueden agregar opciones para su configuracion (ejecutar snmptrapd --help para unadescripcion mas precisa). Sin embargo esta configuracion no se grabara para futurasejecuciones por lo que se recomienda hacerlo a traves de su archivo de configuracionsnmptrapd.conf. Para esta implementacion se edito el archivo snmptrapd.conf ubicadoen el directorio $netsnmpdir/etc/snmp/.

El archivo snmptrapd.conf es especıfico para el receptor, y contiene una serie de di-rectivas que describen su comportamiento en diferente aspectos. Para esta implementa-cion el receptor de notificaciones solo tiene la funcion de registrar aquellas notificacionesque recibe desde la central IP-PBX 3 usando el maximo nivel de seguridad permitido enSNMPv3. A continuacion se describen solo aquellas directivas usadas y el resto de ellaspueden ser revisadas en la documentacion de Net-SNMP disponible en su sitio oficial.

Comportamiento del Demonio

∴ snmpTrapdAddr [<transport-specifier>:] <transport-address> [, ...]Define una lista de direcciones, por las cuales puede recibir notificaciones SNMP.Por defecto se considera el puerto 162 para escuchar todas las interfaces IPv4.Pero cabe destacar que en la version usada y en las anteriores se debe especificarel numero de puerto al momento de usar el comando snmptrap o snmpniform porel agente para enviar una notificacion.

∴ doNotRetainNotificationLogs yesDeshabilita el soporte para notification-log-mib. Normalmente el demoniomantiene un registro de las notificaciones recibidas, que puede ser obtenido con-sultando las tablas nlmLogTable y nlmLogvariableTable.

doNotRetainNotificationLogs yes

59


Control de Acceso

Desde la version 5.3 es necesario definir reglas de seguridad para el envıo de traps einformes (y que tipo de procesamiento es permitido). Se usa una extension del modeloVACM, descrita en la configuracion del agente SNMP. Actualmente existen 3 tipos deprocesamientos que son especificados en la Tabla 5.2.

Tabla 5.2: Tipos de procesamientos para modelo VACM

Tipo Descripcion

log registra la notificacion recibida en un archivo especificado, salida estandar(o estandar de error), o vıa syslog.

execute la notificacion es enviada como argumento a una aplicacion externa.net adelanta el mensaje a otro receptor de notificaciones.

En las siguientes directivas, types sera una lista separada por una ’,’ de uno omas tipos definidos en la Tabla 5.2. Comunmente, se usa log, execute, net para cubrircualquier tipo de procesamiento, pero perfectamente se puede limitar a ciertos tipos deprocesamiento.

∴ authUser types [-s model] user [level [oid | -v view]]Autoriza notificaciones SNMPv3 desde un usuario especificado para efectuar lostipos de procesamiento listados. Por defecto, la estacion aceptara consultas auten-tificadas (nivel de seguridad authNoPriv o authPriv). level es usado para definirel nivel de seguridad usado(noauth, auth, priv). oid (o -v view) permite filtraraquellos objetos MIB que seran procesados.nota: view esta relacionada solo con el valor de snmpTrapOID de la notificacionde entrada y no a los datos de los varbinds adjuntados dentro de la notificacion.

A continuacion se define la regla de recepcion que permite a la estacion recibirtraps v3 desde la central IP-PBX 3, con un nivel de seguridad authPriv. Los trapsrecibidos a traves de este usuario pueden ser registrados o enviados a un programaexterno, pero no adelantados por la red a otra estacion de administracion.

authUser log,execute -s usm pc120encrypter priv

60


Formato y Registro de Notificaciones

Mediante las siguientes directivas se puede modificar el formato a las notificacionesrecibidas en la estacion. Puede usarse para especificar los campos y el orden de lasnotificaciones que seran mostradas.

∴ format2 formatEspecifica el formato usado para registrar notificaciones SNMPv2c. Cabe destacarque SNMPv2c y SNMPv3 usan el mismo formato PDU SNMPv2.

∴ logOption stringEspecifica el destino de los registros para los traps recibidos hacia la salida estandar,estandar de error, un archivo especıfico o vıa syslog.

logOption s 0

La opcion “s 0” indica que las notificaciones seran enviadas al demonio syslogd atraves del subsistema local0 [15]. Luego para que todos los registros de notifica-ciones sean redireccionados a la consola Linux tty1 es necesario editar el archivode configuracion de este demonio (syslog.conf) agregando las siguientes lıneas:

local0.* /dev/tty1

∴ outputOption stringEspecifica varias caracterısticas de como deben ser mostrados los oids y otrosvalores.

outputOption s

Procesamiento de Notificaciones

En la seccion anterior se menciono que existen 3 alternativas para procesar unanotificacion, de las cuales solo se considerara el caso de registrar dichos mensajes ya quepara esta implementacion se cuenta con una sola estacion de administracion.

61


∴ traphandle oid|default program [ARGS ...]Invoca un programa especıfico (con los argumentos dados) cuando se recibe unanotificacion cuyo identificador es oid. Para notificaciones SNMPv2c y SNMPv3,oid sera comparado con el valor de snmpTrapOID tomado de la notificacion. Paraun trap SNMPv1, tanto su valor generico como el oid seran convertidos a un oidequivalente (valor numerico) siguiendo el RFC 2576.

Tıpicamente, el oid tomado sera el nombre (o oid numerico) del objeto notification-type, y el programa sera invocado para notificaciones que cumplan exactamentecon el valor de oid (no como subarbol). Sin embargo existe el soporte para com-parar ramas del arbol mediante el sufijo ’*’. Por ejemplo un oid de .1.3.6.1.4.1* sepodrıa efectuar el llamado a la aplicacion para cualquier notificacion que este den-tro de ese subarbol, incluyendo el valor exacto. En cambio un oid de .1.3.6.1.4.1.*trabaja de la misma manera considerando solo notificaciones que estan bajo esesubarbol. Si oid tiene el valor default el programa sera invocado para cualquiernotificacion.

Los detalles de la notificacion son entregados a la aplicacion por medio de laentrada estandar. Siempre se usara el formato de notificacion de SNMPv2c, sitenemos traps SNMPv1 su formato sera convertido mediante el RFC 2576 antesde ser pasados al programa. El formato de entrada es como se indica en la Tabla5.3.

Tabla 5.3: Formato de notificaciones para Net-SNMP

campos descripcion

hostname El nombre del host que envio la notificacion, determinado por get-hostbyaddr.

ipaddress Direccion IP del host que envio la notificacion.varbinds Una lista de varbinds describiendo el contenido de la notifica-

cion, uno por lınea. El primer token de cada lınea (hasta elprimer espacio) es el oid del varbind, y el resto de la lıneacorresponde a su valor. El formato del varbind se controla me-diante la directiva outputOption. El primer oid siempre de-berıa ser SNMPv2-MIB::sysUpTime.0, y el segundo SNMPv2-MIB::snmpTrapOID.0. El resto de las lıneas contiene un lista devarbinds. Para traps SNMPv1, el oid final deberıa ser SNMPv2-MIB::snmpTrapEnterprise.0.

Una alternativa para el registro de notificaciones en el sitio Web de administraciones crear un script que registre las notificaciones de manera mas sencilla, entendi-ble por el administrador que no tiene gran conocimiento en el formato original.Ademas este script almacena los mensajes segun la fecha de recepcion en un ar-chivo historial que luego sera leıdo y visualizado por el sitio Web.

62


traphandle default /usr/local/rrdtool/trap.sh

∴ forward oid|default destinationAdelanta las notificaciones que cumplen con el oid especificado a otro receptor denotificaciones ubicado en destination (direccion IP). La interpretacion de oid(y default) es el mismo que para la directiva traphandle.

5.3.3. Creacion de Usuarios SNMPv3

La creacion de usuarios SNMPv3 en el demonio es identica a la configuracion realiza-da en el agente. De igual forma, el uso recomendable de esta caracterıstica es incluir lasdirectivas de creacion de usuarios en el archivo /var/net-snmp/snmptrapd.conf, conel fin de que no hayan archivos en el sistema que contengan los nombres de usuarios ycontrasenas en texto plano. Los usuarios seran aquellos a los que recibiran notificacionesmediante el protocolo SNMPv3.

∴ createUser -e engineID username (md5|sha) authpassphrase [des|aes]El uso de esta directiva es identico a su homonimo para el fichero de configuraciondel agente, la unica diferencia que para recibir traps SNMPv3 es necesario registrarel engineID de cada agente que tendra permitido enviar notificaciones.Para obtener el engineID de un agente es necesario leer su archivo de configuracionpersistente (/var/net-snmp/snmpd.conf). La ultima lınea contiene la informacionen formato hexagesimal de su engineID, mostrando algo parecido a lo siguiente:

oldEngineID 0x80001f88043031303230333034303530313230

Dicho valor debe ser agregado a la directiva createUser al momento de registraral agente anteponiendo la opcion -e tal como lo indica su formato.

createUser -e 0x80001f88043031303230333034303530313230 \pc120encrypter MD5 snmpencrypted DES snmpencrypted

63

Capıtulo 6

AsteriskOpen Source IP-PBX System

Asterisk es un software de fuente abierta de un Voice Over IP PBX (IP-PBX) ini-cialmente creado por la empresa digium que proporciona los servicios, caracterısticas yfunciones de una PBX tradicional, y funciona sobre el Sistema Operativo Linux. Aste-risk implementa Voz sobre IP en varios protocolos y puede interactuar con equipos detelefonıa PSTN estandar basicas usando un hardware de facil instalacion y configura-cion.

Asterisk adicionalmente provee servicios de voicemail con directorios, conferencias,respuesta de voz interactivo IVR, llamadas en espera. Tiene el soporte de tres tipos deformas de llamadas: servicios de llamada con identificacion, ADSI, SIP y H323.

Asterisk apoya una amplia gama de protocolos TDM para el manejo y transmisionde interfaces de telefonıa tradicional. Asterisk apoya el tipo de senalizacion estandaramericano y europeo, permitiendo ser un nexo entre las redes integradas de datos devoz de siguiente generacion y la infraestructura existente. Asterisk no solo soporta alos equipos de telefonıa tradicionales sino que tambien los habilita con capacidadesadicionales.

Asterisk provee una base central de conmutacion, con 4 APIs para la carga modu-lar de los usos de telefonıa, interfaces del hardware, direccion del formato del archivoy CODECs, permite la conmutacion transparente de todas las interfaces soportadas,permitiendo que enlacen una diversidad de combinaciones de sistemas de telefonıa enuna sola red.

Asterisk fue originalmente escrito por Mark Spencer de DIGIUM, Inc. Los codigosfueron la contribucion de algunas fuentes abiertas de todo el mundo y probando algunosbug-patches de la comunidad, ha provisto importante ayuda para el desarrollo de estesoftware.

64

6. Asterisk Open Source VoIP PBX System

Debido a que en la pagina oficial de Asterisk, http : //www.asterisk.org, se encuentrantodos los manuales para la configuracion e implementacion del software como CentralTelefonica IP, en este capıtulo no se van detallar estos pasos, describiendo solo las etapasnecesarias para la instalacion y configuracion de la aplicacion integrada con el modulosnmp necesario para esta implementacion.

6.1. Instalacion de Asterisk

En el sitio oficial de Asterisk se pueden encontrar los paquetes con los archivosejecutables para ciertos sistemas operativos o si se desea tambien esta disponible elcodigo fuente de esta aplicacion.

Debido a que este proyecto integra los servicios de telefonıa IP y SNMP, es necesarioutilizar una version de asterisk que permita este desarrollo. El modulo SNMP de asteriskesta disponible desde su version 1.4, de la cual solo se puede acceder mediante su codigofuente. Se recomienda leer los archivos de ayuda incluıdos en el paquete descargado, yası entender mejor los pasos que se describen a continuacion:

Descargar la aplicacion y luego descomprimirla en un directorio cualquiera. Eneste caso, se utilizo su version estable 1.4.4 dado que tiene integrada el moduloque permite actuar como subagente SNMP permitiendo ası una comunicacion atraves del protocolo AgentX con el agente configurado en la seccion 5.2.

Entrar en el directorio creado, y ejecutar el script de configuracion configure, elcual chequeara nuestro sistema en busca de bibliotecas y paquetes que necesitael sistema para compilar el codigo. Ademas, permite incluir una serie de opcionesde compilacion que servira para activar ciertas caracterısticas necesarias para laimplementacion. El script fue ejecutado con las siguentes opciones:

./configure --with-netsnmp=/usr/local/net-snmp \--prefix=/usr/local/asterisk

Las opciones usadas permiten activar el modulo SNMP que permite actuar comoun subagente integrando el servicio de telefonıa IP al sistema de administracionremota, y especificar la ruta en donde sera instalada la aplicacion. Definir la rutade instalacion permite mantener un orden de la ubicacion de los directorios yası facilitar a futuro su proceso de desinstalacion. La siguiente lınea de comandospermite obtener la lista completa de las opciones disponibles en el script:

./configure --help

65


Compilar la aplicacion para obtener los archivos ejecutables que seran usados enel proceso de instalacion.

make

EL ultimo paso es instalar los archivos ejecutables obtenidos en la ruta especifi-cada, ejecutando como superusuario (root) la siguiente lınea de comandos:

make install

Finalmente se obtiene un conjunto de directorios que contienen las aplicacionesy archivos de configuracion para Asterisk. Su ubicacion va a depender de la rutaespecificada al ejecutar el script configure mediante la opcion --prefix. Desde estemomento la variable $asteriskdir describe la ruta de instalacion de Asterisk, yque para esta implementacion fue definida en /usr/local/asterisk.

Cabe destacar que durante el proceso de instalacion de Asterisk sus archivos deconfiguracion no son creados por defecto en el directorio /etc/asterisk, y permitendefinir las distintas capacidades segun a la realidad del servicio que se quiere prestar.La alternativa mas simple y rapida es ejecutar dentro del directorio fuente de Asteriskel script make samples para copiar los archivos de configuracion que vienen por defectocon la aplicacion.

El modulo de SNMP es cargado correctamente siempre y cuando obtenga del siste-ma las librerıas de Net-SNMP, para esto es necesario describirle la direccion en donderesiden. Por defecto Asterisk lee del directorio /usr/lib, pero dado que Net-SNMP fueinstalado mediante codigo fuente su ubicacion es otra. Entonces una solucion simplees crear ligas hacia su actual ubicacion ($netsnmpdir/lib). El comando Linux pararealizar este tipo de operacion es ln. A continuacion se indican las lıneas de comandosque deben ser ejecutadas como root y en el directorio /usr/lib para las cuatro librerıasrequeridas por Asterisk.

ln -s $netsnmpdir/lib/libnetsnmpmibs.so.14 libnetsnmpmibs.so.14ln -s $netsnmpdir/lib/libnetsnmpagent.so.14 libnetsnmpagent.so.14ln -s $netsnmpdir/lib/libnetsnmphelpers.so.14 libnetsnmphelpers.so.14ln -s $netsnmpdir/lib/libnetsnmp.so.14 libnetsnmp.so.14

66


6.2. Configuracion del Subagente SNMP

Las funciones de Asterisk sobre SNMP, pueden ser realizadas como agente o sub-agente, en donde este ultimo permite comunicarse con un agente maestro a traves delprotocolo AgentX. Los objetos MIB que tiene disponible son especıficos para el servicioque entrega la central IP-PBX, no integrando otros servicio que pueden ser de interesası como trafico, estado del hardware, etc. Los objetivos de esta implementacion hacennecesaria su configuracion como subagente SNMP y ası cuando la estacion consulte so-bre el servicio de telefonıa IP sea este el que responda a traves del agente. Para definireste comportamiento es necesario editar el archivo de configuracion descomentando laslıneas dentro de la seccion general, como lo indica el siguiente ejemplo:

[general]subagent yesenabled yes

El siguiente paso es configurar el conjunto de reglas que permitiran la integracioncon las centrales IP-PBX 1 y 2 disponibles en el Departamento de Electronica. Para ellolas siguientes secciones describen en detalle los archivos de configuracion que cumplenesta funcion.

6.2.1. Usuarios SIP

La red existente tiene la propiedad de comunicar a los usuarios a traves del protocolode senalizacion sip. Entonces para agregar la central IP-PBX 3 es necesario que sususuarios registrados cumplan con el mismo protocolo.Los usuarios sip deben ser creados en el archivo de configuracion sip.conf, en donde esposible determinar un sin fin de caracterısticas que permitiran un mejor uso del servicio.

En este archivo se debe especificar tanto los segmentos de red internos como lasdirecciones IPs que son permitidas para registrarse en el sistema. Ademas de puedeespecificar los codec soportados por el sistema y el contexto en el cual se procesanlas llamadas SIP. Este contexto permite agrupar las llamadas en grupos, para aplicarlesciertas caracterısticas o servicios, ası tambien se puede especificar y ordenar las llamadasprovenientes de distintos lugares. A continuacion se describe la configuracion usada paraesta implementacion:

67


[general]port = 5060; puerto por el cual se~naliza SIPbindaddr = 192.168.28.120; direccion del servidor de registrodisallow = all; se deshabilitan todos los codecsallow = ulaw; se permite el codec ulawallow = alaw; se permite el codec alawcontext = atmlab; contexto por el cual se envıan las llamadasSIP conocidas

[802]type=friend; peer|user|friend: tipo de usuario SIP.secret=802; contrase~na del usuario.username=802; medio de autentificacion para cliente SIP.host=dynamic; dominio o nombre para el servidor SIP.context=from-internal; nombre del contexto para llamadas deentrada y salida.nat=no;canreinvite=no;

[prueba]type=peer;host=192.168.28.125;context=from-internal;

El usuario prueba permite establecer una conexion con la central IP-PBX 2 cuyadireccion IP es 192.168.28.125, y ası intercambiar llamadas con sus usuarios registrados.De manera similar se creo un usuario sip en la central IP-PBX 2 tambien de tipo peerpara atender llamados desde esta central [14]. Por otra parte, el usuario 802 representaun cliente que puede hacer o recibir llamadas de otros usuarios registrados.

6.2.2. Creacion del Dialplan

El archivo extensions.conf contiene el dialplan de Asterisk, conocido como el planmaestro de control para todas sus operaciones. Define como seran manejadas y enrutadaslas llamadas de entrada y salida, es decir, se define el comportamiento de todas lasconexiones a traves de la central IP-PBX.El siguiente paso es crear las extensiones sip necesarias para permitir la comunicacionentre las centrales IP-PBX 2 y 3, y ademas entre los usuarios internos registrados.

68


[general]static=yes;writeprotect=yes;

[from-internal]include ruta;include ext-local;

[ruta]exten 9XX,1,Dial(SIP/prueba/$EXTEN,30,r);exten 9XX,2,Congestion;

[ext-local]exten 8XX,1,Dial(SIP/$EXTEN,30,r);exten 8XX,2,Congestion;

Despues de la categorıa [general], el resto del archivo contiene la definicion delDialplan. En este caso se definen 3 contextos de los cuales from-internal incluye elconjunto de extensiones de ruta y ext-local. El contexto ruta define que toda llamadade entrada dirigida a un anexo de 3 dıgitos que empiece con 9, sera redirigida a la centralIP-PBX 2. En cambio el contexto ext-local define que toda llamada de entrada dirigidaa un anexo de 3 dıgitos que empiece con 8, sera contestada por un usuario interno.En ambos contextos si la comunicacion falla entonces el usuario sera conectado a unaoperadora que le indicara que la llamada no se pudo establecer.

6.2.3. Asterisk CLI

Asterisk en su instalacion incluye una interfaz de comando llamada CLI (Commandline Interface), la cual permite manejar la central en forma completa y hacer debuggingdel sistema por linea de comando. Para acceder a CLI se debe ejecutar la siguiente lıneade comandos:

69


[root@BIONICO ∼]# asterisk -rAsterisk 1.4.4, Copyright (C) 1999 - 2006 Digium, Inc. andothers.Created by Mark Spencer <marksterdigium.com>Asterisk comes with ABSOLUTELY NO WARRANTY; type ’core showwarranty’ for details.This is free software, with components licensed under the GNUGeneral PublicLicense version 2 and other licenses; you are welcome toredistribute it undercertain conditions. Type ’core show license’ for details.=========================================================================== Parsing ’/etc/asterisk/asterisk.conf’: Found== Parsing ’/etc/asterisk/extconfig.conf’: FoundConnected to Asterisk 1.4.4 currently running on BIONICO-Server(pid = 7076)Verbosity was 0 and is now 3pbx-BIONICO*CLI

Dos ejemplos de comando de CLI son:

1. sip show users: muestra desde la base de datos del sistema la informacion delos usuarios registrados, incluyendo anexo, clave de registro y contexto para susllamadas.

2. sip show settings: especifica todas las configuraciones que estan funcionandoactualmente en el sistema.

El resultado obtenido al ejecutar estos dos comandos es el siguiente:

pbx-BIONICO*CLI sip show users

Username Secret Accountcode Def.Context ACL NAT802 802 from-internal No RFC3581

70


pbx-BIONICO*CLI sip show settingsGlobal Signalling Settings:---------------------------

Codecs: 0xc (ulaw|alaw)Codec Order: ulaw:20,alaw:20T1 minimum: 100Relax DTMF: NoCompact SIP headers: NoRTP Keepalive: 0 (Disabled)RTP Timeout: 0 (Disabled)RTP Hold Timeout: 0 (Disabled)MWI NOTIFY mime type: application/simple-message-summaryDNS SRV lookup: NoPedantic SIP support: NoReg. min duration 60 secsReg. max duration: 3600 secsReg. default duration: 120 secsOutbound reg. timeout: 20 secsOutbound reg. attempts: 0Notify ringing state: YesNotify hold state: NoSIP Transfer mode: openMax Call Bitrate: 384 kbpsAuto-Framing: No

Default Settings:-----------------

Context: from-internalNat: RFC3581DTMF: rfc2833Qualify: 0Use ClientCode: NoProgress inband: NeverLanguage: (Defaults to English)MOH Interpret: defaultMOH Suggest:Voice Mail Extension: asterisk

71


6.2.4. Softphone X-lite

Para efectuar pruebas de comunicacion entre clientes dentro de la red IP, se utiliza elsoftphone X-lite, la version libre de la empresa CounterPath y que puede ser instaladaen los sistemas operativos Windows, Mac OSX y Linux.

En la opcion Configuracion Avanzada, se debe ingresar el sip proxy y los parametros deusuario para su registro en el servidor, como se puede apreciar en la Figura 6.2.4, dondese ha configurado al usuario cuyo anexo es el 802 y pertenece al servidor de registroconfigurado previamente cuya direccion IP.es 192.168.28.120.

Figura 6.1: X-lite, configuracion de parametros SIP

La ventana mostrada en la Figura 6.2.4 se encuentra en Menu → System Setting →Sip Proxy, de las opciones del softphone. Una vez aceptado los cambios, en la ventanaprincipal del softphone aparecera un mensaje de registrado, tal como se puede apreciaren la Figura 6.2.4.

Figura 6.2: X-lite, Ventana principal

72


6.2.5. Iniciacion de Servicios

Una vez finalizado el proceso de configuracion tanto para la aplicacion Asterisk comopara el agente Net-SNMP, se puede dar comienzo a dichas aplicaciones. Cabe destacarque existe un cierto orden de ejecucion entre los servicios de administracion y de tele-fonıa IP, para establecer la conexion vıa protocolo AgentX entre maestro y subagente.

Los pasos que se listan a continuacion fueron efectuados en un sistema Linux comoDebian Etch, y deben ser respetados en el mismo orden como se encuentran:

Detener el servicio de Telefonıa IP a traves de su demonio asterisk, solo si previa-mente fue iniciado.

[root@BIONICO ∼]# /etc/init.d/asterisk stop

Detener el agente Net-SNMP a traves de su demonio snmpd, solo si previamentefue iniciado.

[root@BIONICO ∼]# /etc/init.d/snmpd stop

Iniciar la aplicacion de Asterisk, y luego al agente Net-SNMP.

[root@BIONICO ∼]# /etc/init.d/asterisk start[root@BIONICO ∼]# /etc/init.d/snmpd start

El siguiente paso serıa comprobar que ambos servicios esten funcionando correcta-mente. Un camino simple serıa comprobar que el proceso correspondiente para cadaaplicacion este activo, para ello se hace uso del comando Linux ps, dando el siguienteresultado:

[root@BIONICO ∼]# ps -C asteriskPID TTY TIME CMD3024 ? 00:00:09 asterisk

[root@BIONICO ∼]# ps -C snmpdPID TTY TIME CMD2750 ? 00:01:20 snmpd

nota: En caso que no se obtenga respuesta es porque se generaron fallas en su ejecuciony fueron canceladas. Para revisar cuales son las causas del problema es recomendableleer el archivo de registros que tiene cada aplicacion.

Finalmente se recomienda comprobar que la conexion entre agente y subagenteSNMP se haya establecido. En el archivo de registros de Net-SNMP se muestra el

73


estado de la conexion AgentX cada vez que la aplicacion es iniciada.

[root@BIONICO ∼]# cat /var/log/snmpd.logTurning on AgentX master support.NET-SNMP version 5.4.1.pre1

En secciones anteriores se hizo incapie que tanto Asterisk como Net-SNMP no tienenla posibilidad de ser iniciados como servicios del sistema. En el caso de Asterisk contieneun script que puede ser ejecutado solo en distribuciones RedHat para Linux, pero parael resto no es aplicable. Para dar simpleza al control de estas aplicaciones fue necesarioregistrar los demonios snmpd, snmptrapd y asterisk como servicios del sistema1.

1Apendice A: Servicios para Linux: asterisk, snmpd y snmptrapd

74

Capıtulo 7

Resultados y Conclusion

7.1. Resultados

La integracion de un sistema de administracion remota a traves de Net-SNMP yuna red de telefonıa IP servida por 3 IP PBX Asterisk propuesta en los objetivos dacomo resultado el esquema de red que representa la Figura 7.1.

Figura 7.1: Esquema Final de un Sistema de Administracion para una Red de Telefonıa IP

75

7. Resultados y Conclusion

La red construida permite dar servicios de telefonıa IP a todo el Departamento deElectronica a traves de las centrales IP-PBX 1 y 2. Como resultado de este proyectose integro un tercer servidor de prueba para estudiar la posibilidad de implementar unsistema de administracion remota SNMP. La central IP-PBX 3 es monitoreada por laestacion de administracion NMS-ELO01 sobre un conjunto de servicios como trafico,uso de los canales asterisk, hardware, entre otros.

7.1.1. Resumen sobre configuraciones

Las Tablas 7.1, 7.2 y 7.3 describen la configuracion de las IP PBX y el servidor deadministracion SNMP. Ademas se definen las reglas de marcado usadas para acceder alos distintos tipos de anexos, dependiendo de la ubicacion en que se encuentren.

Tabla 7.1: Resumen de Configuraciones para IP-PBX 2

Asterisk ip-pbx 2

Nombre: ippbx-pstnDireccion IP: 192.168.28.0/24LAN interna: 192.168.28.125Rango de Anexos: 4900 a 4999Anexos de Prueba: 200, 900Puerto FXO: Anexo UTFSM 4093Puerto FXS: Anexo ZAP 4910

reglas de marcado? Para acceder a clientes registrados en IP-PBX 1 marcar un anexo entre 4800 y4899, por ejemplo 4804.? Para acceder a clientes internos en IP-PBX 2 marcar un anexo entre 4900 y4999, por ejemplo 4910.? Para acceder a clientes registrados en IP-PBX 3 marcar un anexo entre 800 y899, por ejemplo 802.? Para acceder a clientes internos UTFSM marcar el anexo correspondiente, porejemplo 4759.? Para acceder a clientes internos a la PSTN anteponer “0” para acceder al troncalFXO y “9” para que la central permita la salida hacia la PSTN, luego se debemarcar el numero al que se desea llamar, por ejemplo 0-9-833004.

76


Tabla 7.2: Resumen de Configuraciones para IP-PBX 3

Asterisk ip-pbx 3

Nombre: ippbx-snmpDireccion IP: 192.168.28.0/24LAN interna: 192.168.28.120Rango de Anexos: 800 a 802Usuario SNMPv3: pc120encrypterMonitor DisMan: root

reglas de marcado y SNMP? Para acceder a anexos de prueba en ip-pbx 2 marcar anexo 900.? Para acceder a clientes internos ip-pbx 3 marcar un anexo entre 800 y 899, porejemplo 802.? El subagente SNMP en Asterisk esta conectado a su agente maestro a traves delprotocolo AgentX en el socket var/agentx/master con permisos para el usuarioroot del sistema.? Todas las consultas sobre el servicio asterisk son respondidas por el subagente,el cual envıa las respuesta a su agente maestro y luego este las adelanta a laestacion nms-elo01.? El agente maestro monitorea cada 5 min. por posibles fallas en el servicioasterisk mediante el usuario root. Una vez encontrada una anormalidad se envıauna notificacion a la estacion nms-elo01 para que tenga constancia del hecho.

Tabla 7.3: Resumen de Configuraciones para NMS-ELO01

Estacion nms-elo01

Nombre: pcmag21Direccion IP: 192.168.28.0/24LAN interna: 192.168.28.101Consultas a: ip-pbx 3Notificaciones de: ip-pbx 3

reglas de SNMP? La estacion solo recibe traps SNMPv3 desde usuarios registrados y que per-tenecen a la red 192.168.28.0/24. En este caso el unico usuario registrado espc120encrypter perteneciente a IP-PBX 3.? Todo trap enviado desde IP-PBX 3 es registrada en el archivo/var/log/snmptrapd.log y enviada a consola (tty1) mediante syslog.? Con el fin de generar graficos de estadısticas para ciertos servicios de ip-pbx 3se hacen consultas SNMPv3 a traves del usuario pc120encrypter registrado porel agente SNMP.

77


7.1.2. Estadısticas en IP-PBX 3 a traves de SNMP

Los beneficios del protocolo SNMP, es que se pueden hacer consultas remotas conel fin de generar estadısticas sobre servicios de interes, todo dependiendo del tipo deequipo que se esta administrando. En este caso se refiere a una central IP-PBX, por loque los principales aspectos a analizar tienen relacion con el estado de su hardware ya los servicios de comunicacion entregados. Estos aspectos se relacionan directamentecon cierto objetos MIB los cuales son descritos en detalle en la Tabla 7.4.

Tabla 7.4: Descripcion del Plan de Monitoreo

Serviciosanalisis de tabla mib objetos

Trafico Ethernet inEntry ifInOctets.2, ifOutOctets.2Uso de Canales Asterisk asteriskChannels astNumChannels.0,

astChanTypeChannels.1-9

Hardwareanalisis de tabla mib objetos

Temperatura lmTempSensors lmTempSensorsValue.1-3Carga Promedio laTable laLoadInt.1-3Memoria en Uso memory memTotalSwap, memTotalReal,

memAvailSwap, memAvailReal,Buffer, Cached.

En la actualidad existen muchas herramientas para la generacion de graficos entiempo real, ası como MRTG, Cacti, entre otras. En este caso se hizo uso de RRDTool,un sistema que permite almacenar y representar datos en intervalos temporales (anchode banda, temperatura, etc.). La forma en que almacena los datos es a traves de una basede datos que no crece en el tiempo, aun cuando se pueden guardar valores historicos(mensuales, anuales, etc) para luego generar graficos y conocer el comportamiento alargo plazo de un determinado servicio.

A continuacion se hace una descripcion de los resultados obtenidos por serviciomonitoreado en la central IP-PBX 3 para un periodo de 4 horas, almacenando muestrascada 5 min mediante consultas SNMPv3 desde NMS-ELO01.

78


Trafico Ethernet

La Figura 7.2 muestra el comportamiento del ancho de banda de entrada y salidamedido en bytes/sec a la interfaz de red eth0 de la central IP-PBX 3, cuya direccionIP es 192.168.28.120. Esta informacion se obtiene midiendo el cambio temporal de lacantidad total de bytes de entrada y salida consultada de los objetos MIB ifInOctets.2y ifOutOctets.2, respectivamente.

Figura 7.2: Analisis de Trafico Ethernet para IP-PBX 3

Cabe destacar que RRDTools, permite obtener datos de relevancia, ası como el valoractual, maximo y promedio de la medicion realizada durante el periodo de tiempo queesta considerando. A demas tiene muchas opciones que facilitan el analisis posterior delas estadısticas realizadas.

Uso de Canales Asterisk

El analisis propuesto para esta etapa consiste en medir el numero total de canalesactivos que tiene Asterisk en un tiempo determinado. Para ello el MIB integrado aAsterisk contiene informacion esencial sobre el uso de los diferentes tipo de canal dis-ponibles. Por una parte el objeto MIB astNumChannels.0 permite conocer el numerototal de canales en uso (vista general), en cambio del objeto astChanTypeChannels.1al astChanTypeChannels.9 se entrega el detalle para cada tipo de canal. La Tabla 7.5describe los 9 tipos de canal que Asterisk dispone, aunque cabe destacar que para estaimplementacion solo se dispone del canal SIP.

79


Tabla 7.5: Tipos de canales disponibles en Asterisk

canal descripcion

Agent Call Agent Proxy ChannelSkinny Skinny Client Control Protocol (Skinny)Console OSS Console Channel DriverPhone Standard Linux Telephony API DriverIAX2 Inter Asterisk eXchange Driver (Ver 2)Feature Feature Proxy Channel DriverLocal Local Proxy Channel DriverSIP Session Initiation Protocol (SIP)MGCP Media Gateway Control Protocol (MGCP)

La Figura 7.3 representa el estudio realizado para el uso de canales sip y iax2,debido a que en los otros casos no se dispone del hardware necesario para realizar dichasmediciones. Estos dos protocolos de senalizacion son simples en cuanto a arquitecturafısica, pueden ser probados a traves de softphones que para este caso se realizaronllamadas entre usuarios registrados en las centrales IP-PBX 2 y 3.

Figura 7.3: Analisis de Uso de Canales Asterisk para IP-PBX 3

Unidad de Procesamiento Central (CPU)

Para analizar esta componente se consideraron dos caracterısticas fundamentales,las cuales son: carga de procesamiento y temperatura. La carga de la CPU se mide enporcentaje y corresponde a valores promedios: 1, 5 y 10 min, de los cuales son obtenidosa traves de los objetos MIB laLoadInt.1, laLoadInt.2 y laLoadInt.3 respectivamente, yse representan en la Figura 7.4.

80


Figura 7.4: Analisis de Carga Promedio en CPU para IP-PBX 3

Otra caracterıstica medible desde la CPU es su temperatura, para ello fue necesariocargar dinamicamente el modulo MIB lm-sensors que contiene toda la informacionnecesaria ademas de otras que fueron usadas pero que no seran detalladas en este docu-mento. Ademas de la CPU tambien es posible medir la temperatura de la placa madre,la cual tambien fue agregada al analisis. De esta manera los objetos MIB lmTempSen-sorsValue.1 y lmTempSensorsValue.2 contienen los valores de temperatura de la placamadre y CPU respectivamente, tal como muestra en la Figura 7.5.

Figura 7.5: Analisis de Temperatura para IP-PBX 3

81


Uso de Memoria

La memoria en uso se refiere a la memoria fısica que puede estar siendo ocupada endiversas funciones. En este analisis se pretende considerar los usos mas generales, entrelos cuales estan: uso real, buffers, cache, y memoria swap. la Tabla 7.6 describe aquellosobjetos MIB necesarios para dicho analisis.

Tabla 7.6: Objetos MIB para analisis de memoria en uso

objeto descripcion

memTotalReal Total de memoria real/fısica en el equipo.memAvailReal Memoria real/fısica disponible actualmente.memBuffer Memoria real o virtual usada actualmente para buffers.memCached Memoria real o virtual usada actualmente como memoria cache.memTotalSwap Total de memoria swap configurada en el equipo.memAvailSwap Memoria swap disponible actualmente.

La Figura 7.6 describe el uso de memoria fısica del servidor, considerando soloaquellos que tienen mayor importancia a la hora de generarse fallas.

Figura 7.6: Analisis de Memoria en Uso para IP-PBX 3

82


7.1.3. Reconocimiento de Fallas en Central IP-PBX 3

En el capıtulo 5 se describio la configuracion realizada al agente y la estacion SNMP,en donde se determinaron las reglas de envıo y recepcion de notificacion. En esta seccionse entregaran los resultados obtenidos sobre las pruebas realizadas a dichas configura-ciones, las cuales tienen como objetivo informar a la estacion NMS-ELO01 en caso deuna determinada falla y solo procesarlas a traves de registros.

En el archivo de configuracion del agente snmpd.conf se indicaron las reglas demonitoreo DisMan, las cuales consistıan en analizar 4 aspectos fundamentales en basea sus respectivos objetos MIB, descritos en la Tabla 5.1.

El agente SNMP en la central IP-PBX 3 periodicamente realiza el analisis de lasreglas monitor de su archivo de configuracion, el cual puede ser observado a traves de sumodo depuracion (snmpd -Lo -f -Ddisman) cuando este es iniciado. A continuacion semuestra la salida estandar obtenida para un ciclo de tiempo en que realiza dicho analisis.

disman:event:trigger:monitor: Running trigger (memory)disman:event:delta: Bool comparison: (0 != 0) 0disman:event:trigger:monitor: Running trigger (laTable)disman:event:delta: Bool comparison: (0 != 0) 0disman:event:delta: Bool comparison: (0 != 0) 0disman:event:delta: Bool comparison: (0 != 0) 0disman:event:trigger:monitor: Running trigger (lmtempmotherboard)disman:event:trigger:monitor: Running trigger (lmtempcpu)

Con el fin de informar sobre los datos obtenidos por la estacion debido a un in-cumplimiento de las reglas monitor en el agente SNMP, se describira el caso en quese genera una notificacion por una falla de autentificacion en una consulta realizada adicho agente.

Fallas de Autentificacion

En el caso que la central IP-PBX 3 es consultada con un usuario SNMPv3 inco-rrecto, ya sea nombre de seguridad o contrasena, entonces el agente inmediatamente daaviso a la estacion NMS-ELO01 que hubo una falla de autentificacion a traves de unanotificacion de tipo trapv3. A continuacion se describe la consulta erronea que activa laregla authtrapenable 1 definida en el archivo de configuracion del agente.

snmpwalk -v 3 -u pc120encrypter -l authpriv -a MD5 -A snmpencrypte \-x DES -X snmpencrypted 192.168.28.120 sysDescr.0

83


Luego el trap recibido por la estacion adjunta el objeto MIB snmpTrapOID.0 cu-yo valor es authenticationFailure de esta manera le indica que el agente recibio unaconsulta con identificacion fallida adjuntandole informacion de tiempo para conocer elmomento en que ocurrio (sysUpTimeInstance). Esto se puede apreciar a traves del demo-nio snmptrapd ejecutandolo en modo depuracion (snmptrapd -Lo -Ddumph recv,dumpv recv) como se muestra en el siguiente cuadro:

dumph_recv: SNMPv3 Messagedumph_recv: SNMP Version Number Integer: 3 (0x03)dumph_recv: msgGlobalDatadumph_recv: msgID Integer: 1566513010 (0x5D5F1772)dumph_recv: msgMaxSize Integer: 65507 (0xFFE3)dumph_recv: msgFlags String: .dumph_recv: msgSecurityModel Integer: 3 (0x03)dumph_recv: SM msgSecurityParametersdumph_recv: msgAuthoritativeEngineID String: .....01020304050120dumph_recv: msgAuthoritativeEngineBoots Integer: 180 (0xB4)dumph_recv: msgAuthoritativeEngineTime Integer: 57859 (0xE203)dumph_recv: msgUserName String: pc120encrypterdumph_recv: msgAuthenticationParameters String: ..S4.Tc.M...dumph_recv: msgPrivacyParameters String: ....Iv&.dumph_recv: ScopedPDUdumph_recv: contextEngineID String: .....01020304050120dumph_recv: contextName String:dumph_recv: TRAP2dumpv_recv: Command TRAP2dumph_recv: request_id Integer: 1050224183 (0x3E992637)dumph_recv: error status Integer: 0 (0x00)dumph_recv: error index Integer: 0 (0x00)dumph_recv: VarBindListdumph_recv: VarBinddumph_recv: Name ObjID: sysUpTimeInstancedumph_recv: Value UInteger: 5785301 (0x5846D5)dumph_recv: VarBinddumph_recv: Name ObjID: snmpTrapOID.0dumph_recv: Value ObjID: authenticationFailuredumph_recv: VarBinddumph_recv: Name ObjID: snmpTrapEnterprise.0dumph_recv: Value ObjID: netSnmpAgentOIDs.102007-07-03 11:49:59 192.168.28.120 [UDP: [192.168.28.120]:32846]:sysUpTimeInstance = Timeticks: (5785301) 16:04:13.01 \snmpTrapOID.0 = OID: authenticationFailure \snmpTrapEnterprise.0 = OID: netSnmpAgentOIDs.10

84


Segun la configuracion realizada para el agente, en su directiva trapsses las noti-ficaciones enviadas corresponden a trap v3 cuyo nivel de seguridad es authPriv. Paracomprobar que la informacion transmitida es encriptada tal como se configuro fue ne-cesario el uso de una herramienta para captura de paquetes de red como ethereal, ybasado en el ejemplo anterior el mensaje capturado contiene la siguiente informacionSNMP:

No. Time Source Destination Protocol4 3.777434 192.168.28.101 192.168.28.120 SNMP

Simple Network Management ProtocolmsgVersion: snmpv3 (3)msgGlobalData

msgID: 634424755msgMaxSize: 65507msgFlags: 07.... .1.. = Reportable: Set.... ..1. = Encrypted: Set.... ...1 = Authenticated: SetmsgSecurityModel: USM (3)

msgAuthoritativeEngineID: 80001F880430313032303330343035303132301... .... = Engine ID Conformance: RFC3411 (SNMPv3)Engine Enterprise ID: net-snmp (8072)Engine ID Format: Text, administratively assigned (4)Engine ID Data: Text: 01020304050120msgAuthoritativeEngineBoots: 12msgAuthoritativeEngineTime: 31msgUserName: pc120encryptermsgAuthenticationParameters: 16E6060274B74E7017678552msgPrivacyParameters: 00000081938D271CmsgData: encryptedPDU (1)

encryptedPDU: A17CC66CBB00C9F363FF2B2D5E8447AFFA0AB92E5A0A6D25...

0030 30 11 02 04 25 d0 8d b3 02 03 00 ff e3 04 01 07 0...%...........0040 02 01 03 04 45 30 43 04 13 80 00 1f 88 04 30 31 ....E0C.......010050 30 32 30 33 30 34 30 35 30 31 32 30 02 01 0c 02 020304050120....0060 01 1f 04 0e 70 63 31 32 30 65 6e 63 72 79 70 74 ....pc120encrypt0070 65 72 04 0c 16 e6 06 02 74 b7 4e 70 17 67 85 52 er......t.Np.g.R0080 04 08 00 00 00 81 93 8d 27 1c 04 38 a1 7c c6 6c ........’..8.|.l0090 bb 00 c9 f3 63 ff 2b 2d 5e 84 47 af fa 0a b9 2e ....c.+-^.G.....00a0 5a 0a 6d 25 74 b4 20 ec 5f 98 d4 5a b5 e0 9d bd Z.m%t. ._..Z....00b0 56 93 a2 fd bf 17 99 44 bd b9 4a bb 52 8c bb d2 V......D..J.R...00c0 8f ec dc 80 ....

85


Lo anterior indica que los datos son enviados en el nivel mas alto de seguridad, man-teniendo en secreto informacion vital acerca de fallas en el sistema, lo cual es importanteen casos que se quieran adjuntar otros objetos MIB en la notificacion ası como valoresde configuracion del servidor. Ademas los valores de autentificacion que son enviadosen texto plano solo corresponden a datos basicos, es decir, su engineID y nombre deseguridad, en cambio el resto de la informacion como la contrasena es adjuntada en elpaquete de datos encriptado.

Finalmente el sistema de reconocimiento de fallas integrado en el sitio Web de ad-ministracion permite visualizar las ultimas 10 notificaciones recibidas por la estacionNMS-ELO01 desde sus agentes segun la configuracion realizada. Ademas se tiene dispo-nible un archivo historial (snmptrapd.historial.log) con todas las notificaciones recibidasen caso que el administrador lo requiera. La Figura 7.7 muestra un captura de pantallade la zona de notificaciones del sitio Web de administracion desarrollado.

Figura 7.7: Zona de notificaciones en el sitio Web de administracion

7.2. Conclusiones

Una de los aspectos que motivo el desarrollo de esta implementacion, fue integrarun sistema seguro de administracion utilizando todas las caracterısticas desarrolladasen la version 3 de SNMP, demostrando ası que es posible controlar un dispositivo quedispone de servicios especıficos como en este caso telefonıa IP. En lo que respecta aestrategias de administracion pensando en la utilizacion de la red se hizo uso del plande administracion distribuida, que es un concepto basado en la combinacion de losmetodos de obtencion de informacion. En el caso de fallas en un equipo administradoes su agente SNMP el que se encarga de la deteccion y no la estacion de administraciondado que en este ultimo caso existirıa un gasto de la red por el intercambio sucesivo depaquetes para reconocer el estado del equipo (pensado para una red de computadoresextensa). En cambio si lo que se desea es monitorear la red, entonces es necesaria la

86


consulta periodica de ciertos objetos MIB por parte de la estacion. En este proyecto cuyafinalidad era implementar un sistema sencillo de administrado basado en el monitoreo yreconocimiento de fallas en una central IP-PBX, se utilizo una arquitectura centralizada(una estacion de administracion) pero en casos en que se necesite administrar una grancantidad de equipos de red es necesario usar una arquitectura distribuida teniendovarias estaciones que puedan ser controladas por un maestro y ası no provocar flujosexcesivos de paquetes SNMP viajando por la red ademas de los requerimientos sobreprocesamiento para la maquina que juega el rol de administrador.

7.2.1. Sistema de Monitoreo

Uno de los aspectos mas importantes en la administracion es mantenerse informadode la situacion actual de los servicios que entrega una red. En este caso el objetivoconsistıa en desarrollar estadısticas en tiempo real, sobre la situacion de la IP-PBX deprueba integrada a la red de telefonıa IP.

Los ıtemes analizados para la IP-PBX forman parte de un conjunto de caracterısticasque a un administrador le interesarıa conocer. Se pudo demostrar que a traves de SNMPse puede monitorear un sin fin de caracterısticas, y a demas da seguridad por lo quese convierte en la actualidad en una herramienta de interes. A pesar que el esquemapresentado es a baja escala permite considerar la capacidad de desarrollar un sistemadistribuido de administracion pensando que en la industria de las telecomunicacionesexisten una gran diversidad de componentes de red ası como routers, UPS, etc.

Respecto a la intencion de desarrollar un sistema de monitoreo sobre una grancantidad de componentes se recomienda desarrollar un esquema distribuido de estacionesde administracion, debido a la excesiva cantidad de paquetes SNMP circulando por la reddebido a las contantes consultas. De esta manera integrando mas estaciones las cualesse encargan de sectores diferentes de la red provocarıa una disminucion considerable loque para una red de voz es un aspecto fundamental.

7.2.2. Sistema de Reconocimiento de Fallas

Disenar un sistema en que es el propio agente el que se analiza y puede dar aviso auna estacion sobre alguna falla ocurrida, es una de las grandes facultades que tiene elprotocolo SNMPv3 aparte de la integracion de niveles de seguridad para la proteccionde los datos. Esto porque si fuera la estacion la encargada de verificar fallas un equipogenerarıa en grandes redes un mal uso del ancho de banda, debido al intercambio deuna gran cantidad de paquetes SNMP. Con el metodo DisMan se logra darle un mejoruso al recurso, el cual es vital para servicios como telefonıa IP en donde se requiere delmaximo posible.

87


En cuando a la planificacion de este sistema, se hubiese querido integrar la generacionde traps referidos a fallas en los servicios entregados por Asterisk, pero se encontraronfallas en cuanto a la conexion entre maestro y subagente SNMP a la hora de iniciar losprocesos de analisis a traves de las directivas monitor. Por ello es que se hizo incapie enreconocer otro tipo de fallas y dejar como trabajo futuro la generacion de notificacionesrelacionadas a los servicios de Asterisk a traves de las directivas Event MIBl en laconfiguracion del agente.

7.2.3. Desarrollo Futuro

El proyecto sobre administracion remota de una red de telefonıa IP desarrollado eneste documento plantea la implementacion de una central IP-PBX de prueba integradaa la red existente con la capacidad de comunicarse a traves del protocolo SNMP yası ser monitoreada y controlada por una estacion de administracion. Luego de cumplircon estos objetivos existen ciertos ıtemes en los cuales se puede seguir explorando einvestigando, desarrollando proyectos sobre la base de que el control sobre servicios IPes factible y ya existe. A continuacion se indican algunos aspectos en los que se puedeseguir desarrollando sobre lo ya realizado.

Integracion de centrales IP-PBX a la red de administracion remota. Este puntose basa en desarrollar un plan de administracion para este tipo de servicio el cualesta tomando gran envergadura en el Departamento de Electronica en donde fuedesarrollado. Ademas se requiere actualizar el portal Web de administracion paratener acceso a la informacion de las nuevas centrales y equipos que se deseenadministrar.

Desarrollar implementaciones sobre otros tipos de dispositivos de red, ası comorouters que soporten el protocolo SNMPv3, y ası facilitar su administracion yasea configuracion y monitoreo.

Estudio sobre la posibilidad de integrar estrategias de monitoreo eficientes, yası evitar que la red se sature de paquetes SNMP provocando una disminucion enla calidad de servicios sobre todo si es una red de voz y video que se requiere desu maxima capacidad.

88

Apendice A

Servicios para Linux:asterisk, snmpd y snmptrapd

Un servicio se refiere generalmente a un demonio del sistema, es decir, es un progra-ma que permanece en segundo plano ejecutandose continuamente para dar algun tipode servicio. Ejemplos de demonio, son los servidores de correo, impresora, sistemas deconexion con redes, etc.

Cada uno de ellos tiene un archivo asociado en /etc/init.d, el cual es un scriptbash que acepta un argumento (podrıa ser, al menos, ”start.o ”stop”, aunque puedenser otros complementarios para proveer al usuario de opciones adicionales, por ejemplorestart”, ”status”...).

A.1. Scripts de Inicio

Un script de inicio es creado para iniciar una aplicacion en el caso del arranqueası como tambien en caso de apagado instantaneo del sistema, o debido a un cambioen el nivel de ejecucion [19]. En todo sistema Linux, especıficamente en el directorio/etc/init.d se encuentra el script skeleton que tiene la unica funcion de describir laestructura basica de un demonio. A la hora de crear scripts de inicio es aconsejable usareste archivo como base, y comenzar a modificar aquellas lıneas que requieren especificarla aplicacion que se quiere controlar.

A continuacion se describen las funciones que forman parte de la estructura de unscript de inicio. Algunas de ellas son requeridas y otras solo opcionales.

89

Apendice A - Servicios para Linux

Funciones Requeridas

start(): Incluye lo que ocurrira cuando el script arranque.

Funciones Opcionales

depend(): Se utiliza para determinar las dependencias del servicio, sedeben cumplir para que arranque el demonio (mas abajo hayun ejemplo)

stop(): Esto es lo que ocurrira cuando se ordene que el servicio separe.

restart(): Esto es lo que se tiene que hacer para parar y volver a iniciarel servicio.

A continuacion se entregan simples scripts que permiten definir los tres serviciospara el sistema, correspondientes a las aplicaciones: asterisk, snmpd y snmptrapd.

90


Tabla A.1: Script para servicio Asterisk

#! /bin/shDAEMON=/usr/local/asterisk/sbin/asteriskPIDFILE=/var/run/$NAME.pidSCRIPTNAME=/etc/init.d/$NAMEtest -x $DAEMON || exit 0case "$1" instart)

echo -n "Starting daemon: asterisk"start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -vvvvvvvvvvecho ".";;

stop)echo -n "Stopping daemon: asterisk"kill ‘cat $PIDFILE‘echo ".";;

restart|force-reload)echo -n "Restarting daemon: asterisk"kill ‘cat $PIDFILE‘sleep 1start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -vvvvvvvvvvecho ".";;

*)echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2exit 1;;

esacexit 0

El script descrito en la Tabla A.1 permite iniciar el demonio asterisk con el nivelmaximo de depuracion, y de esta manera cuando el administrador entre a su consolapodra conocer los detalles de cada accion acontecida, a traves del comando“asterisk -r”.

91


Tabla A.2: Script para servicio snmpd

#! /bin/shNAME=snmpdDAEMON=/usr/local/net-snmp/sbin/$NAMEPIDFILE=/var/run/$NAME.pidSCRIPTNAME=/etc/init.d/$NAMEtest -x $DAEMON || exit 0case "$1" instart)

echo -n "Starting daemon: $NAME"start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -f -Lf /var/log/snmpd.logecho ".";;

stop)echo -n "Stopping daemon: $NAME"kill ‘cat $PIDFILE‘echo ".";;

restart|force-reload)echo -n "Restarting daemon: $NAME"kill ‘cat $PIDFILE‘sleep 1start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -f -Lf /var/log/snmpd.logecho ".";;


esacexit 0

La lınea de ejecucion para el demonio snmpd definida en el script de la Tabla A.2permite almacenar en un archivo de texto (/var/log/snmpd.log) todos los registros pro-ducidos por el agente Net-SNMP.

92


Tabla A.3: Script para servicio snmptrapd

#! /bin/shNAME=snmptrapdDAEMON=/usr/local/net-snmp/sbin/$NAMEPIDFILE=/var/run/$NAME.pidSCRIPTNAME=/etc/init.d/$NAMEtest -x $DAEMON || exit 0case "$1" instart)

echo -n "Starting daemon: $NAME"start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -p $PIDFILEecho ".";;

stop)echo -n "Stopping daemon: $NAME"kill ‘cat $PIDFILEecho ".";;

restart|force-reload)echo -n "Restarting daemon: $NAME"kill ‘cat $PIDFILEsleep 1start-stop-daemon --start --quiet --background --make-pidfile \--pidfile $PIDFILE --exec $DAEMON -- -p $PIDFILEecho ".";;


esacexit 0

Debido a que el sistema por defecto no crea archivos con permisos de ejecucion esnecesario configurar los scripts para que puedan ser iniciados cuando sea necesario. Paraesto se debe usar el comando de Linux chmod, con los siguientes parametros para cadanuevo servicio.

[root@BIONICO ∼]# chmod 755 /etc/init.d/asterisk[root@BIONICO ∼]# chmod 755 /etc/init.d/snmpd[root@pcmag21 ∼]# chmod 755 /etc/init.d/snmptrapd

93


A.2. Instalacion de Servicios

El comando update-rc.d crea enlaces simbolicos apropiados para los demonios paraque cuando el sistema se inicie, estos sean ejecutados. En caso de que el sistema seadetenido, los demonios seran terminados. Para ejecutar este comando es necesario es-pecificar el nivel de ejecucion, y dado que son aplicaciones que dependen directamentede otras se deben escoger los niveles mas altos, que en este caso se usa 99.

[root@BIONICO ∼]# update-rc.d /etc/init.d/asterisk defaults 99[root@BIONICO ∼]# update-rc.d /etc/init.d/snmpd defaults 99[root@pcmag21 ∼]# update-rc.d /etc/init.d/snmptrapd defaults 99

Ahora se puede dar el caso que se quieran eliminar para que no sean iniciados entiempo de booteo. Para ello se debe utilizar el comando update-rc.d de la siguientemanera:

[root@BIONICO ∼]# update-rc.d -f /etc/init.d/asterisk remove[root@BIONICO ∼]# update-rc.d -f /etc/init.d/snmpd remove[root@pcmag21 ∼]# update-rc.d -f /etc/init.d/snmptrapd remove

A.3. Pruebas de Funcionamiento

Una vez agregados los servicios al sistema, se debe comprobar que estan funcionandocorrectamente. Para ello pueden ser iniciados ejecutando el script de inicio que corres-ponda (ej. /etc/init.d/asterisk start) o se puede reiniciar el sistema para que se seancargados junto con la configuracion general (boot time). Para corroborar que se ejecuta-ron correctamente se hace uso del comando de Linux ps -C servicio donde serviciocorresponde al nombre del demonio revisado. De esta manera a modo de ejemplo secomprobara la ejecucion de los 3 demonios requeridos.

[root@BIONICO ∼]# ps -C snmpdPID TTY TIME CMD2750 ? 00:01:53 snmpd

[root@BIONICO ∼]# ps -C asteriskPID TTY TIME CMD6317 ? 00:00:00 asterisk

[root@pcmag21 ∼]# ps -C snmptrapdPID TTY TIME CMD2529 ? 00:00:00 snmptrapd

94

Bibliografıa

[1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, andJames R. Davin. A Simple Network Management Protocol. Request ForCommentes 1089, DDN Network Information Center, SRI International,April 1989.

[2] RRDTool. Round Robin Database Tool<http://oss.oetiker.ch/rrdtool/index.en.html>.

[3] Douglas R. Mauro and Kevin J. Schmidt, Essential SNMP, FirstEdition. O’Reillly & Associates, July 2001.

[4] Douglas R. Mauro and Kevin J. Schmidt, Essential SNMP, 2ndEdition. O’Reillly & Associates, September 2005.

[5] Marshall T. Rose and Keith McCloghrie. Structure and identifi-cation of Management Information for TCP/IP-based Internets. Requestfor Comments 1155, Network Working Group, May 1990.

[6] BER implementation for SNMP. Basic Encoding Rules<http://www.vijaymukhi.com/vmis/ber.htm>.

[7] PEN. Private Enterprise Number Request Template<http://pen.iana.org>.

[8] Keith McCloghrie, David Perkins, and Juergen Schoenwael-der. Textual Conventions for SMIv2. Request for Comments 2579, Ne-twork Working Group, April 1999.

[9] Developers’ Corner. Systinet Server for Java 6.5.3 Product Documen-tation. Systinet Server for Java, Systinet Corporation, May 2006.

[10] Charles M. Kozierok. The TCP/IP Guide: A Comprehensive, Illus-trated Internet Protocols Reference. Published by No Starch Press, Sep-tember 2005.

[11] Randy Presuhn. Version 2 of the Protocol Operations for the SimpleNetwork Management Protocol (SNMP). Request for Comments 3416,Network Working Group, December 2002.

[12] Ramanathan Kavasseri. Event MIB. Request for Comments 2981, Ne-twork Working Group, October 2000.

[13] Net-SNMP. Suite of SNMP Aplications<http://net-snmp.sourceforge.net>.

[14] Tamara J. Ramirez Andrade y Jaime A Diaz Rojas. Desarrollode Aplicaciones en la Central Asterisk de Telefonıa IP en el Departamen-to de Electronica, UTFSM. Tesis (Ingenierıa Civil Electronica), Valpa-raıso, Chile, Universidad Tecnica Federico Santa Marıa, Departamentode Electronica, Julio 2007.

[15] El demonio syslogd<http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html>.

[16] IETF. The Internet Engineering Task Force <http://www.ietf.org>.

[17] The Hash Algorithm Directory. The Secure Hash Algorithm Direc-tory MD5, SHA-1 and HMAC Resources<http://www.secure-hash-algorithm-md5-sha-1.co.uk/>.

[18] The Secure Hash Algorithm Directory MD5, SHA-1 andHMAC Resources. <http://csrc.nist.gov/cryptval/des.htm>.

[19] Los scripts de inicio. SUSE LINUX – Manual de Administracion<http://www.l3jane.net/doc/linux/suse/suselinux-adminguide es/>.

Disen126 no e Implementacio19 on de un Sistema de...

Documents

Transcript of Disen126 no e Implementacio19 on de un Sistema de...