snmp trapsess

Universidad Técnica Federico Santa Marı́a
Departamento de Electrónica
———————————————————————
“Diseño e Implementación de un Sistema de
Monitoreo basado en SNMP para una Red de
Telefonı́a IP Asterisk”
Memoria presentada por: Patricio E. Valle Vidal
como requisito parcial para optar al tı́tulo de
Ingeniero Civil Electrónico
Mención Computadores.
Profesor Guı́a: Tomás Arredondo Vidal
Valparaı́so, Agosto 2007
———————————————————————
Universidad Técnica Federico Santa Marı́a
Departamento de Electrónica
———————————————————————
“Diseño e Implementación de un Sistema de
Monitoreo basado en SNMP para una Red de
Telefonı́a IP Asterisk”
Memoria presentada por: Patricio E. Valle Vidal
como requisito parcial para optar al tı́tulo de
Ingeniero Civil Electrónico
Mención Computadores.
Profesor Guı́a: Tomás Arredondo Vidal
Profesor Coreferente: Agustı́n González Valenzuela
Valparaı́so, Agosto 2007
———————————————————————
Diseño e Implementación de un Sistema de Monitoreo
basado en SNMP para una Red de Telefonı́a IP Asterisk
Patricio Enrique Valle Vidal
Memoria para la obtención del Tı́tulo de Ingeniero Civil Electrónico
Profesor Guı́a: Tomás Arredondo Vidal
Agosto 2007
Resumen
Simple Network Management Protocol, o SNMP, es una aplicación que permite a
usuarios remotos revisar o manipular variables de administración. SNMP es usado tı́picamente para administrar redes de redes, o internets, que usan el conjunto de protocolos
TCP/IP. En una red de telefonı́a IP, la cual tiene una amplia tendencia al crecimiento resulta difı́cil proporcionar alta calidad de servicios y una administración de red
eficiente.
En esta tesis, se realiza un estudio sobre un sistema integral a modo de prueba que
administre una red local de manera sencilla y segura. En este caso la red cumple como
función principal, entregar a sus usuarios servicios de telefonı́a IP, mediante la instalación de una central PBX llamada Asterisk. Este sistema está construı́do empleando los
recursos de administración definidos en el estándar SNMPv3 que se encuentran disponibles en la plataforma Linux, y que se serán instalados en dos máquinas PC (Personal
Computer) ubicadas en el laboratorio ATM del departamento de Electrónica. Se utilizan agentes y subagentes ubicados en la central administrada y almacenan información
especificada en el estándar SNMP, que es recibida por el centro administrador (remoto)
para organizarla y presentarla en un portal Web creado para este fin. Esta información
se obtiene para dos fines: análisis de estadı́sticas y reconocimiento de fallas de los diferentes servicios disponibles por la central administrada.
Se espera que este ambiente sea de gran utilidad para la administración y seguridad de
la red de telefonı́a IP creada recientemente en el departamento de Electrónica
Palabras claves – Simple Network Management Protocol (SNMP), agente, estación,
Linux, telefonı́a IP, Linux, Net-SNMP, implementación.
Índice
1. Introducción
1
1.1. Objetivos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Protocolo SNMP
3
7
2.1. Estaciones y Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2. Comunicación y Clases de Mensajes . . . . . . . . . . . . . . . . . . . .
8
2.2.1. Métodos de Comunicación 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. Definición de un Objeto . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.3. Extensión 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. Extensión 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 Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3.2. Descubrir a su Motor Autoritario . . . . . . . . . . . . . . . . . .
32
3.3.3. Puntualidad USM . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.4. Autentificación . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . .
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. Administración Distribuida (DisMan) . . . . . . . . . . . . . . . . . . .
36
4. Traps e Informs
38
4.1. La Necesidad de Traps en SNMP . . . . . . . . . . . . . . . . . . . . . .
38
4.2. Conceptos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.1. Traps SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.2. Informs SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5. Net-SNMP
Open Source SNMP System
42
5.1. Instalación de Net-SNMP . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2. Configuración para Agente SNMP . . . . . . . . . . . . . . . . . . . . .
45
5.2.1. Aspectos Fundamentales para la Implementación . . . . . . . . .
45
iv
5.2.2. Creación de Usuarios SNMPv3 . . . . . . . . . . . . . . . . . . .
58
5.2.3. Inicio del Agente SNMP . . . . . . . . . . . . . . . . . . . . . . .
59
5.3. Configuración para Receptor de Notificaciones SNMP . . . . . . . . . .
59
5.3.1. Funcionamiento del Mecanismo de Notificaciones . . . . . . . . .
59
5.3.2. Demonio snmptrapd . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.3.3. Creación de Usuarios SNMPv3 . . . . . . . . . . . . . . . . . . .
64
6. Asterisk
Open Source IP-PBX System
65
6.1. Instalación de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.2. Configuración del Subagente SNMP . . . . . . . . . . . . . . . . . . . .
68
6.2.1. Usuarios SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.2.2. Creación del Dialplan . . . . . . . . . . . . . . . . . . . . . . . .
69
6.2.3. Asterisk CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.2.4. Softphone X-lite . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.2.5. Iniciación de Servicios . . . . . . . . . . . . . . . . . . . . . . . .
74
7. Resultados y Conclusión
76
7.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.1.1. Resumen sobre configuraciones . . . . . . . . . . . . . . . . . . .
77
7.1.2. Estadı́sticas en IP-PBX 3 a través 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
A.1. Scripts de Inicio
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
90
A.2. Instalación de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.3. Pruebas de Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . .
95
vi
Índice de Figuras
1.1. Mapa de Red de Telefonı́a IP del departamento de Electrónica . . . . .
2
1.2. Esquema Lógico de Administración de la Red de Telefonı́a IP . . . . . .
3
1.3. Sistema de Monitoreo para una Red de Telefonı́a a través de SNMP . .
4
1.4. Generación y procesamiento de alarmas con SNMP . . . . . . . . . . . .
6
2.1. Relación entre NMS y agente . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2. Árbol de objetos SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3. Árbol extendido en SMIv2 . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4. Modelo de comunicación 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 Lógico de VACM . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.1. X-lite, configuración de parámetros SIP . . . . . . . . . . . . . . . . . .
73
6.2. X-lite, Ventana principal . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.1. Esquema Final de un Sistema de Administración para una Red de Telefonı́a IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.2. Análisis de Tráfico Ethernet para IP-PBX 3 . . . . . . . . . . . . . . . .
80
7.3. Análisis de Uso de Canales Asterisk para IP-PBX 3
81
vii
. . . . . . . . . . .
7.4. Análisis de Carga Promedio en CPU para IP-PBX 3 . . . . . . . . . . .
82
7.5. Análisis de Temperatura para IP-PBX 3 . . . . . . . . . . . . . . . . . .
82
7.6. Análisis de Memoria en Uso para IP-PBX 3 . . . . . . . . . . . . . . . .
83
7.7. Zona de notificaciones en el sitio Web de administración . . . . . . . . .
87
viii
Índice 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 definición 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. Parámetros de snmpSecurityParemeter . . . . . . . . . . . . . . . . . . .
31
3.7. Tabla de usuarios USM . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.1. Traps genéricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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. Descripción del Plan de Monitoreo . . . . . . . . . . . . . . . . . . . . .
79
ix
7.5. Tipos de canales disponibles en Asterisk . . . . . . . . . . . . . . . . . .
81
7.6. Objetos MIB para análisis 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
Introducción
El protocolo Simple Network Management Protocol (SNMP) [1] permite consultar
y alterar variables dentro del contexto de una red. SNMP es usado tı́picamente para
transportar información de la red entre sistemas de administración y agentes en un
recurso de red ası́ como hosts, servidores, switches, routers, y gateways.
Internets o redes de redes, contienen importantes retos en el concepto de la administración. SNMP fue diseñado para el manejo de redes TCP/IP y es donde a menudo
se aplica, aún cuando se está usando para administrar otras suites de protocolos de red.
SNMP se construyó gracias a la ayuda conjunta de investigadores, usuarios y administradores de red, y empresas de Telecomunicaciones. Los primeros diseñadores estaban
involucrados activamente en la administración e investigación de internets. Gracias a la
mucha experiencia que tenı́an es que SNMP se logró diseñar, implementar y poner en
marcha en el corto tiempo. Finalmente, todas las propuestas de diseño fueron convertidas en prototipo y probadas mediante múltiples implementaciones independientes.
En la actualidad el departamento de Electrónica está finalizando la implementando
una red de telefonı́a IP la cual permite la comunicación entre terminales IP, además de
interconectar los mundos IP y PSTN. La Figura 1.1 describe la arquitectura de esta red
conformada por dos centrales IP-PBX instaladas con la aplicación Asterisk que contiene
un conjunto de herramientas para llevar a cabo todos los servicios requeridos para la
comunicación.
1
1. Introducción
Figura 1.1: Mapa de Red de Telefonı́a IP del departamento de Electrónica
El proyecto que es descrito a continuación, implementa un sistema de administración
remota para una red de telefonı́a IP1 , incluyendo todos los conceptos de seguridad definidos en la última versión de SNMP (SNMPv3). Este sistema es solo módulo de prueba
construı́do para analizar la posibilidad de administrar a través del estándar SNMPv3
la red de computadores aplicada a servicios de telefonı́a IP que tiene implementado el
departamento de Electrónica. Debido a que la red no ha sido completada y se requiere
de su manipulación para configurar el sistema de administración fue necesario acoplar
el módulo de prueba, el cual consiste en una estación de administración y una central
IP-PBX además del conjunto de aplicaciones y configuraciones que fueron realizadas
para este fin tal como se representa en la Figura 1.2.
1
IP: Internet Protocol
2
1. Introducción
Figura 1.2: Esquema Lógico de Administración de la Red de Telefonı́a IP
1.1.
Objetivos del Proyecto
Este documento describe en detalle la implementación realizada en base a los siguientes objetivos:
Instalación y configuración del Módulo de Prueba
El primer paso consiste en instalar y configurar las entidades SNMP (agentes y
estación) que permitirán el traspaso de información relevante sobre la central IP-PBX
de prueba. En este caso se utilizará la aplicación Net-SNMP que es código abierto y
contiene un conjunto de aplicaciones que permiten administrar remótamente una red
basada en la especificación SNMPv3.
Además se debe integrar este módulo de prueba a la red de Electrónica ya existente
para analizar la compatibilidad entre versiones de la aplicación Asterisk utilizada. Las
dos centrales existentes están configuradas con la aplicación Asterisk en su versión de
kernel 1.2, pero el módulo SNMP está disponible sólo para el kernel 1.4 por lo que
será necesaria la instalación de la central en esta versión y configurada para acoplarse
al mapa de red existente.
3
1. Introducción
Diseño de un Sistema de Monitoreo
Este objetivo se sustenta en el análisis temporal sobre servicios realizados en una
central IP-PBX, construyendo una serie de gráficos en tiempo real tales como: uso de
canales de comunicación, memoria en uso, temperatura y porcentaje de carga de la
CPU, y tráfico.
Figura 1.3: Sistema de Monitoreo para una Red de Telefonı́a con SNMP
La estación de administración genera consultas SNMP a la central integrada, las
cuales son almacenadas en una base de datos circular, permitiendo la generación de
gráficos sobre estadı́sticas en tiempo real como por ejemplo sobre el uso de los canales
Asterisk. RRDTool (Roud Robin Database Tool), es un proyecto GNU que permite
almacenar y representar datos en intervalos temporales (ancho de banda, temperatura,
...) [2]. La información recibida por el centro de administración será almacenada en una
base de datos que no crece en el tiempo, acomulando datos diarios, semanales, mensuales
y anuales para crear gráficos de calidad, los cuales serán desplegados en el portal Web
de administración creado para este proyecto tal como se describe en la Figura 1.3.
Diseño de un Sistema de Reconocimiento de Fallas
Este objetivo consiste en generar alarmas desde un equipo administrado para ser enviadas a la estación SNMP para su posterior procesamiento, permitiendo tomar acciones
que den solución al problema de fondo.
Consiste en configurar la central IP-PBX de prueba para que genere mensajes de
alarmas al momento de detectar una falla en su sistema sobre ciertos servicios. Esta
comunicación tiene la particularidad de no ser de libre acceso, es decir, debe cumplir
con el proceso de autentificación, además de ser transmitido en forma encriptada para
evitar daños en su integridad, es decir, se usará el máximo de seguridad posible para
el protocolo SNMP. Una vez que la estación reciba estos mensajes, la acción tomada
será informar a través de la generación de registros para luego ser mostrados en una
consola Linux (tty) y en el sitio Web de administración desarrollado para este proyecto.
4
1. Introducción
De esta manera el administrador siempre estará informado de los sucesos en la red
pudiendo tomar acciones inmediatas en caso de fallas.
Figura 1.4: Generación y procesamiento de alarmas con SNMP
5
Capı́tulo 2
Protocolo SNMP
SNMP es un protocolo de la capa de aplicación en el modelo OSI, que facilita el
intercambio de información de tipo administrativa entre dispositivos de la red. De esta
manera permite a los administradores manejar el desempeño de la red para encontrar
y resolver problemas, y planificar su crecimiento.
2.1.
Estaciones y Agentes
En el ambiente SNMP hay dos tipos de entidades: administrador y agente. El administrador es un servidor con algún tipo de software que puede manejar tareas administrativas para una red. En el lenguaje SNMP son referidos como Network Management
Stations (NMS), es decir, estaciones de administración de redes. Una estación es responsable de generar consultas y de recibir notificaciones de agentes en la red. A través
de una consulta se obtiene información que más tarde puede ser usada para determinar
si ha ocurrido algún evento crı́tico. Por otro lado una notificación permite al agente
dar aviso que algo ha ocurrido. La estación tiene la capacidad de realizar una acción
basado en la información que recibió del agente. Por ejemplo, cuando un circuito T1 de
Internet está caı́do el router puede enviar un mensaje a la estación y una vez recibido,
se pueden cambiar parámetros que permitan volver a su normal funcionamiento. Este
tipo de mensaje es enviado de forma asincrónica, no como respuesta a una consulta
realizada por una estación.
El agente, por su parte es una aplicación 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 operativo
de Cisco, o de bajo nivel que controla una UPS). El agente provee información de
administración a la estación 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 cada
una de sus interfaces: cuales están activas y cuales no, etc. La estación puede consultar
por el estado de cada una de sus interfaces, y tomar acciones apropiadas si alguna
6
2. Protocolo SNMP
está desactiva. Cuando el agente percibe que algo malo sucedió, él puede enviar un
mensaje a la estación para volver a su estado normal [3].
Figura 2.1: Relación entre NMS y agente [3]
Cabe destacar que tanto las consultas como notificaciones pueden ocurrir al mismo
tiempo, no habiendo restricción sobre el momento en que se transmiten estos tipos de
mensajes tal como se describe en la Figura 2.1.
2.2.
Comunicación y Clases de Mensajes
El principal objetivo de SNMP es que permite el intercambio de información administrativa en forma de objetos MIB1 para ser comunicada entre equipos de una red. El
protocolo de operaciones de SNMP describe cómo se realiza esta comunicación, indicando los métodos disponibles para el intercambio de información.
2.2.1.
Métodos de Comunicación SNMP
Se dispone de dos técnicas de comunicación, usadas en situaciones en que una entidad
necesita estar informada sobre el estado de otra entidad:
Interrogación: Este término se refiere cuando una entidad quiere información
sobre otra. En SNMP, una estación es la que deberı́a pedir información necesaria
a sus agentes. Un ejemplo cotidiano para este modelo de comunicación serı́a el
servicio regular de e-mails; una persona cada dı́a revisa su correo por si ha recibido
mensajes nuevos.
Interrupción: Este término se refiere cuando un equipo necesita que otro obtenga
parte de su información, entonces decide enviársela. En SNMP, el agente le envı́a
información a una estación sin ser previamente consultado. Un ejemplo real serı́a
el modelo usado por la comunicación vı́a teléfono.
1
MIB: Management Information Base.
7
2. Protocolo SNMP
En caso de preguntarse cuál método es mejor, no se podrı́a llegar a ninguna conclusión, esto porque ambos modelos tienen sus pro y sus contras. Por esta razón que SNMP
se diseñó para usar ambos métodos. La interrogación es usada para almacenar información periódica ası́ como por ejemplo para fines estadı́sticos o consultar sobre estado de
un equipo. En cambio las interrupciones son usadas en forma de alarmas denominadas
notificaciones, las cuales pueden ser configuradas por un administrador para corregir
fallas en los equipos de la red.
2.2.2.
Mensajes SNMP y Protocol Data Units (PDUs)
En SNMP el intercambio de información es realizada de manera similar a muchos
protocolos de red, es decir, a través del envı́o y recepción de mensajes. Este tipo de mensajes 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 define
como el dato de la capa más alta que es encapsulado por SNMP, descrito por el modelo
OSI. En cambio el formato de un mensaje SNMP es la envoltura que encapsula un pdu
junto con el encabezado. Sin embargo un mensaje se construye para enviar un pdu, por
lo que son términos bastante parecidos y que muchas veces pueden ser usados como
sinónimos.
2.2.3.
Clases de PDUs
Para la versión 1 de SNMP se definen 6 pdus, los cuales fueron extendidos y cambiados tanto en nombre como uso en las versiones 2c y 3. El marco SNMP usado en la
actualidad categoriza los pdus en diferentes clases, las cuales describen las dos funciones
de un mensaje: tipo y forma de comunicación, que se utilizan para realizar tareas de
interrogación versus interrupción.
La Tabla 2.1 describe las principales clases de pdus disponibles en SNMPv2c/SNMPv3
indicando aquellos pdus que están dentro de esa categorı́a. Estas clases no son usadas en
SNMPv1 pero son descritas de igual forma para establecer una asociación y ası́ entender
mejor sus funciones.
8
2. Protocolo SNMP
Tabla 2.1: Clases de PDU SNMP
Clase de PDU
Read
Write
Response
Notification
Descripción
Permiten leer información desde un equipo administrado usando
mecanismos de interrogación.
v1:
GetRequest-PDU, GetNextRequest-PDU
v2c/v3: GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU.
Permite modificar la información en un equipo administrado y
ası́ pueda efectuar una operación.
v1:
SetRequest-PDU
v2c/v3: SetRequest-PDU.
Es enviado como respuesta a un previo requerimiento.
v1:
GetResponse-PDU
v2c/v3: Response-PDU.
Es usado por un equipo para enviar una interrupción, ası́ como
una notificación a una estación.
v1:
Trap-PDU
v2c/v3: Trapv2-PDU, InformRequest-PDU.
GetBulkRequest-pdu y InformRequest-pdu son pdus definidos en SNMPv2/v3. En
cambio GetResponse-pdu sólo fue renombrado a Response-pdu y tiene la propiedad de
ser un mensaje respuesta y no de petición.
Existen otras tres clases especiales, que son definidas en la actual versión de SNMP
pero que son de menor interés dado que no son de uso activo. La clase Internal contiene
un mensaje denominado Report-pdu definido por la comunicación interna de SNMP. A
demás SNMP provee dos clases más llamadas Confirmed y Unconfirmed, usadas para
definir categorı́as de mensajes basado en que sean o no reconocidos por el sistema. Los
mensajes Report-pdu, Trapv2-pdu, y Response-pdu forman parte de la clase Confirmed,
y el resto están en la clase Unconfirmed.
2.3.
Arquitectura SMI
“Información Administrativa” muchas veces es referida a los parámetros operacionales que forman parte de un equipo de red con soporte SNMP. Sin embargo no logra
describir lo que realmente contiene y representa. El primer paso hacia entender que clase
de información puede proporcionar un equipo de red, es comprender cómo estos datos se
representan dentro del contexto SNMP. SMI (Structure of Management Information) es
la estructura que permite asociar objetos administrados con tipos de datos [5]. Un objeto
se puede representar a través de tres atributos, tal como se describe a continuación.
9
2. Protocolo SNMP
Nombre
El identificador (object identifier o OID), permite distinguir un objeto
de otro, pudiendo ser representados a través de números o palabras.
Tipo y Sintaxis
El tipo de dato de un objeto es definido a través del lenguaje “Abstract
Syntax Notation One” (ASN.1). Es un camino para especificar cómo los
datos son representados y transmitidos entre estación y agente dentro
del contexto SNMP. La gran ventaja de ASN.1 es que la notación es
independiente de la máquina, por ejemplo un PC cuyo sistema operativo
es Windows 2000 puede comunicarse con otra que tenga Sun SPARC y
sin tener que preocuparse de la clasificación de bytes.
Codificación
La instancia de un objeto es codificada en una cadena de bytes usando
la regla de BER (Basic Encoding Rules), especificando la forma en que
los objetos son codificados para ser transmitidos por un medio ası́ como
Ethernet y luego recibidos y decodificados para ser procesados por una
determinada entidad [6].
2.3.1.
Objetos versus Nombres
Los objetos administrados son organizados en una jerarquı́a de árbol, que es la base
del esquema de nombres de SNMP [4]. Un identificador de objetos (oid) se construye
de una serie de enteros que representan un nodo del árbol, separado por un punto (.).
El nodo más alto de un árbol es su raı́z y todo lo que esté por debajo ya sean sus
hijos y niveles inferiores se denomina subárbol. Por otro lado una hoja es un nodo que
no tiene hijos. Por ejemplo en la Figura 2.2 la raı́z del árbol es Root-Node, sus subárboles
son ccitt(0), iso(1) y joint(2). El nodo iso(1) es el único que contiene un subnivel,
los otros dos nodos son solo hojas del árbol.
Descendiendo por el subárbol iso(1), el nodo directory no es usado actualmente, en
cambio mgmt define un conjunto estándar de objetos para Internet, y experimental
está reservada para propósitos de investigación y pruebas. El subárbol private permite
definir objetos unilateralmente, es decir, tanto individuos como organizaciones son responsables de definir sus propios objetos. A continuación se indica la definición de los 4
subárboles que forman parte del objeto internet.
internet
directory
mgmt
experimental
private
OBJECT
OBJECT
OBJECT
OBJECT
OBJECT
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
IDENTIFIER
10
::=
::=
::=
::=
::=
{
{
{
{
{
iso org(3)
internet 1
internet 2
internet 3
internet 4
dod(6) 1 }
}
}
}
}
2. Protocolo SNMP
La primera lı́nea declara a internet con oid 1.3.6.1, que es definido (::=, es el
operador de definición) como un subárbol de iso.org.dod. El resto de las lı́neas de
definición declaran los identificadores correspondientes para los subárboles restantes.
En la versión actual de SNMP el subárbol private contiene el nodo enterprises usado exclusivamente para que vendedores de hardware y software puedan definir aquellos
objetos que permitan administrar sus dispositivos propios. La definición SMI para este
nodo es la que se indica a continuación:
enterprises
OBJECT IDENTIFIER ::= { private 1 }
Internet Assigned Numbers Authority (IANA), es la entidad que actualmente asigna
el número privado de empresa para individuos, instituciones, organizaciones y compañı́as
en Internet. Por ejemplo, Cisco System tiene como número privado el 9, ası́ la base
del subárbol está definida como iso.org.dod.internet.private.enterprises.cisco o
1.3.6.1.4.1.9. El término empresa privada puede ser usada para referirse al subárbol
enterprise. Las compañı́as no son las únicas que pueden registrar un identificador
privado, cualquiera puede hacerlo, esto porque el procedimiento es gratuito [7]. Con un
identificador de empresa propio se puede crear un MIB para monitorear determinadas
variables según las necesidades que se tengan en la red.
Figura 2.2: Árbol de objetos SMI [4]
11
2. Protocolo SNMP
2.3.2.
Definición de un Objeto
El atributo syntax permite definir un objeto administrado a través del lenguaje
ASN.1, entre varios tipos de datos estándares para la administración de dispositivos de
redes. Se debe tener en cuenta que estos tipos de datos son simplemente un camino para
definir qué tipo de información puede llevar a cabo un objeto [5].
Tabla 2.2: Tipos de datos definidos en SMIv1
Tipo de dato
Integer
Octet String
Counter
Object Identifier
null
Sequence
Sequence Of
IpAddress
NetworkAddress
Gauge
TimeTicks
Opaque
Descripción
Número de 32-bit usado para especificar tipos numéricos dentro
del contexto de un simple objeto.
Cadena de 0 o más bytes usada generalmente para representar un
texto, pero a veces es usada también para representar direcciones
fı́sicas.
Número de 32-bit con mı́nimo igual a 0 y máximo 232 - 1
(4,294,967,295). Cuando el valor máximo es alcanzado, se reinicia la cuenta volviendo a 0. Este tipo se usa principalmente para
describir información ası́ como la cantidad de bytes enviadas o
recibidas por una interfaz de red. Su comportamiento natural es
que siempre vaya aumentando, nunca decrecer.
Una cadena de tipo decimal que representa un objeto administrado dentro del árbol. Por ejemplo 1.3.6.1.4.19 representa el OID
de Cisco System.
Actualmente no es usado en SNMP.
Define listas que contienen cero o mas tipos de datos ASN.1.
Define un objeto administrado que se compone por una secuencia
(Sequence) de tipos ASN.1.
Representa una dirección IPv4 de 32-bit. Ninguna de las dos versiones de SMI especifican sobre las direcciones IPv6 de 128-bit.
Puede representar diferentes tipos de dirección de red. Su formato
es similar al tipo IpAddress.
Número de 32-bit con mı́nimo igual a 0 y máximo 232 - 1
(4,294,967,295). A diferencia de Counter, estos objetos pueden
aumentar y disminuir su valor, pero nunca excederse del máximo.
La velocidad de una interfaz en un router se representa con este
tipo de dato.
Número de 32-bit con mı́nimo igual a 0 y máximo 232 - 1
(4,294,967,295) representado en centésimos de segundo. El tiempo activo en un dispositivo se representa con este tipo de dato.
Permite que cualquier otro ASN.1 sea codificado como una secuencia de bytes (Octet String).
12
2. Protocolo SNMP
2.3.3.
Extensión de SMI
SMIv2 extiende el árbol de objetos agregando el subárbol SNMPv2 al nodo internet(1). Este cambio significa tener nuevos tipos de datos y que algunos identificadores
de objetos también cambien. La Figura 2.3 muestra como este nuevo subárbol se ajusta
a la arquitectura SMI; su OID es 1.3.6.1.6.3.1.1.
Figura 2.3: Árbol extendido en SMIv2 [4]
SMIv2 también define algunos tipos nuevos de datos, los cuales se pueden observar
en la Tabla 2.3.
Tabla 2.3: Nuevos tipos de datos para SMIv2
Tipo de dato
Integer32
Counter
Gauge32
Unsigned32
Counter64
BITS
Descripción
Idéntico a Integer.
Idéntico a Counter.
Idéntico a Gauge.
Representa valores decimales entre 0 y 232 − 1.
Similar a Counter32, pero representa valores entre 0 y 264 − 1.
Enumeración de no negativos denominada bits.
13
2. Protocolo SNMP
La definición de un objeto SNMPv2 cambia levemente con respecto a SMIv1 debido
a que se agregaron campos opcionales, dándole un mayor control sobre cómo un objeto
es accedido, permitiendo agregar más columnas, y generar mejores descripciones. A
continuación se define la sintaxis para definir un objeto SNMPv2, en donde la lı́nea
destacada corresponde a la extensión realizada descrita en detalle en la Tabla 2.4.
<name> OBJECT-TYPE
SYNTAX <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 definición de SNMPv2
Definición
UnitsParts
Max-Access
Status
Augments
Descripción
Describe una de las unidades (ej. seconds, miliseconds, etc.) usada para
representar al objeto.
El acceso para un tipo de objeto puede ser Max-Access en SNMPv2.
Las opciones válidas son: read-only, read-write, read-create, notaccesible, y accesible-for-notify.
Esta cláusula ha sido extendida para permitir las palabras: current,
obsolete y deprecated. En SNMPv2 current es idéntico a mandatory
en un MIB SNMPv1.
En algunos casos, es útil para agregar una columna a una tabla existente. La cláusula augments permite extender una tabla agregando
una o más columnas, representada por algún otro objeto. Se requiere
el nombre de la tabla del objeto que será modificada.
SMIv2 define un nuevo tipo de notificación denominada Notification-Type, que será discutido más adelante en este capı́tulo, a demás se incluyen nuevas convenciones que
permiten crear objetos de maneras más abstractas [8].
14
2. Protocolo SNMP
2.4.
SNMP y UDP
SNMP usa el protocolo de transporte User Datagram Protocol (UDP) para intercambiar datos entre la estación y el agente. UDP fue escogido en vez de Transmission
Control Protocol (TCP) debido a que no está orientado a la conexión, es decir, no hay
una conexión punto a punto entre el agente y la estación cuando los paquetes se envı́an
de ida y vuelta. Este aspecto lo hace poco confiable, ya que no hay aviso en caso de
pérdidas de los datagramas. Para determinar si un paquete fue perdido se define un
timeout la estación envı́a una petición al agente y espera por la respuesta (el tiempo
de espera es configurable). Si el timeout es cumplido y la estación no ha recibido ninguna respuesta del agente entonces asume que el paquete se perdió y lo retransmite. El
número de veces que lo retransmite también es configurable [4].
En el caso de las notificaciones, la situación es diferente. Si un agente envı́a un
mensaje y este nunca llega, la estación no tiene manera de saber que fue enviado. El
agente no sabe que necesita reenviarlo, porque la estación no tiene la obligación de
responder a una notificación (puede que no se tome una acción sobre el agente sino que
solo 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 para
recibir notificaciones desde un agente. Cada equipo que implementa SNMP deberı́a
usar estos puertos por defecto, pero esto no ocurre y es importante configurar tanto la
estación 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, cualquier
recurso 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 stack
de protocolos, en donde cada capa usa la información de su capa inferior y provee un
servicio a su capa superior.
15
2. Protocolo SNMP
Figura 2.4: Modelo de comunicación TCP/IP y SNMP [3]
2.5.
Comunidades
SNMPv1 y SNMPv2 utilizan la noción de comunidad para establecer la conexión
segura entre NMS y agente. Un agente se configura a través de tres tipos de comunidad:
solo-lectura, lectura/escritura, y notificación. Los nombres de comunidad son contraseñas no habiendo diferencia alguna con aquella que se utiliza por ejemplo para tener
acceso al PC. Los tres tipos de comunidad controlan diferentes tipos de actividad, de
esta manera el tipo solo-lectura permite sólo leer los datos, en cambio lectura/escritura
permite leer y modificar valores de los objetos, ası́ como por ejemplo cambiar la configuración de un router. Finalmente, las comunidades de tipo notificación permiten recibir
mensajes de alerta desde el agente.
El problema con este tipo de autentificación es que los nombres de las comunidades se
envı́an en texto plano, lo que hace que sea fácil para otras personas interceptarlos y usar
dichos nombres para fines equivocados. Debido a esto que SNMPv3 da la posibilidad de
dar integridad a los datos mediante niveles de autentificación en la comunicación entre
equipos SNMP.
Además tal como se mencionó, si una estación tiene un nombre de comunidad para
lectura/escritura sobre un agente, tiene la facultad de realizar modificaciones a determinados 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. Otra
opción es cambiar el nombre de la comunidad constantemente. Esta última opción es
común para redes pequeñas, pero para una red que tiene verdaderas ciudades de spans
o maneja más de cientos o miles de equipos, cambiar el nombre de comunidad puede
ser un problema [4].
2.6.
RMON: Monitoreo Remoto
RMON está fuera del alcance de este proyecto pero explicaremos su relación con
SNMP, y ası́ tener una idea clara de su funcionamiento ya que muchos switches y
routers lo implementan. RMON se utiliza para crear puntos de pruebas que tı́picamente
son equipos independientes que miran el tráfico en segmentos de la red en donde se
produce acumulación. Algunas empresas implementan al menos un tipo de RMON en
sus routers, hubs, o switches [3].
La versión 1 RMON (RMONv1) se define en el RFC 2819; una mejora a este estándar
es RMONv2 definido en RFC 2021. RMONv1 provee a la estación con paquetes de nivel
estadı́stico para una LAN o WAN. Una alternativa serı́a colocar un punto de prueba
RMON en cada segmento de la red que se quiere monitorear. Muchos routers tienen
capacidades limitadas de RMON, ası́ que sólo se pueden usar sus funcionalidades para
tareas de menor importancia (e.g. routers Cisco). Pero por ejemplo algunos switches
3Com implementan la especificación completa de RMON.
El objeto MIB (Management Information Base) RMON fue diseñado para tener
un punto de prueba corriendo en modo offline que permita almacenar estadı́sticas de
la red, pero sin la necesidad de consultar a una estación constantemente. Puede darse
el caso que la estación quiera consultar a su punto de prueba por estadı́sticas que ha
almacenado. Otra función y que muchos puntos de pruebas implementan es la habilidad
de fijar los umbrales para varias condiciones de error y cuando cruza este umbral, alerta
a la estación generando una notificación. El MIB RMON define 10 grupos de objetos
descritos en la Tabla 2.5.
17
2. Protocolo SNMP
Tabla 2.5: Nuevos tipos de datos para SMIv2
Objeto
statistics
OID
1.3.6.1.2.1.16.1
history
1.3.6.1.2.1.16.2
alarm
1.3.6.1.2.1.16.3
hosts
1.3.6.1.2.1.16.4
hostTopN
1.3.6.1.2.1.16.5
matrix
1.3.6.1.2.1.16.6
filter
1.3.6.1.2.1.16.7
capture
1.3.6.1.2.1.16.8
event
1.3.6.1.2.1.16.9
Descripción
Contiene estadı́sticas sobre todas las interfaces Ethernet monitoreadas por el punto de prueba.
Almacena periódicamente muestras simples desde el
grupo de estadı́stica.
Permite a un usuario configurar un intervalo cualquiera de muestras y un umbral para cualquier objeto que
el punto de prueba registre.
Almacena estadı́sticas sobre tráfico de cada host en la
red.
Contiene estadı́sticas de hosts usadas para generar reportes sobre hosts que están dentro de una lista pedida
para un parámetro dado.
Almacena errores e información de utilización para
conjuntos de dos direcciones.
Recibe paquetes mediante una ecuación de filtraje;
cuando un paquete cumple con el filtro, el podrı́a ser
capturado o un evento podrı́a ser generado.
Permite capturar paquetes si ellos cumplen con un filtro dentro de un conjunto.
Controla la definición de eventos de RMON.
En el caso del agente Net-SNMP [13] no hay un soporte real de RMON-MIB. Aunque
este está incluido como módulo, pero solo está definido como una especie de template
para los grupos estadı́sticos RMON-MIB, más que un paquete completo. Se que la
parte más 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 tráfico en la red. Algunas de las funcionalidades
de RMON-MIB, ası́ como alarmas y grupos de eventos, han sido utilizadas por el grupo
DisMan de IETF [16]. Este agente implementa estos módulos MIB, pero en el aspecto
de almacenamiento de estadı́sticas de RMON-MIB no está totalmente disponible.
18
2. Protocolo SNMP
2.7.
Arquitecturas NMS
Antes de construir un sistema de administración remota, es importante planificar
que tipo de arquitectura es mejor para manejar una determinada red. El prototipo de
arquitectura más simple consiste en una sola estación de administración, responsable
de 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: New
York, Atlanta, y San José. Las notificaciones enviadas desde Atlanta o San José deben
viajar por Internet, para llegar a su estación en New York. Para pequeñas redes, una
arquitectura ası́ puede trabajar bien. Sin embargo, la red puede crecer a un punto en
que una sola estación no es capaz manejar grandes cantidades de información, ası́ que
este modelo se convierte en un problema. La estación en New York quizás no sea capaz
de almacenar datos de los sitios remotos, porque en ese instante debe procesar mucha información. Entonces cuando los problemas aumenten, los agentes podrı́an no ser
considerados durante algún momento.
Otro factor importante es que muchas veces se producen fallas que deben ser intervenidas por personal interno más la coordinación necesaria. A veces no se tiene el
tiempo completo para administrarlo, y se necesita de alguien con conocimiento que sepa
que hacer en caso de que un equipo falle.
Para solucionar esto se dispone de un modelo distribuido de estaciones. La idea es
simple: usar dos o más estaciones de administración y ubicarlas en los nodos que son
manejados. En nuestro ejemplo serı́a en las tres zonas: New York, San José 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. Una
de las ventajas de hacer esto, es que las dos nuevas estaciones pueden actuar como entidades independientes, cada una con un staff suficiente para cumplir con las necesidades
de su zona, o simplemente reenviar los eventos a la estación de New York. En la segunda
alternativa, las dos nuevas estaciones proveen de algún tipo de interfaz de cliente para
ver los eventos actuales en la estación (traps recibidos, respuestas a consultas, etc.). La
estación que adelanta los eventos a New York ya ha descubierto el problema, entonces
este último solo tiene que tomar las medidas correctas para solucionar el problema, y
no tener que además recibir notificaciones para saber de que se trata.
La otra ventaja es que si se presentan necesidades puedes poner un staff de operaciones para manejar cada una de las locaciones remotas. Si New York pierde conectividad a
Internet, no serı́a un gran problema porque las estaciones tienen la capacidad de actuar
independientemente.
Existe un tercer modelo denominado “hı́brido” [4] en donde el staff de operaciones
central en New York trabaja las 24 horas al dı́a, los 7 dı́as de las semana, pero tu staff
en Atlanta y San José solo durante las horas de trabajo. De esta manera en horarios
que no sean de trabajo, se confı́a en la estación de New York para notificar y manejar
problemas que se presenten, en el caso contrario, Atlanta y San José se encargan de sus
zonas.
La seguridad de la red es una consideración importante, ya que en ambos modelos
se usa la Internet para comunicar notificaciones y recibir paquetes de configuración.
Esta se ve afectada como también la confianza que se tiene del sistema. Una solución
es usar enlaces encriptados para ejecutar las funciones de administración. La Figura 2.7
muestra la arquitectura de NMS distribuido extendida para esta solución.
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 enlaces
privados (enmarcados con negro en la Figura) entre San José y New York, y New York
y Atlanta. San José no sólo podrá acceder a New York sino que también a Atlanta
vı́a ese enlace, para tráfico de administración, aplicándose lo mismo para Atlanta. La
ventaja que existe es que los nombres de comunidad (para SNMPv1/SNMPv2c) nunca
serán enviados por Internet. En caso de la existencia de una sola estación la solución
también es aplicable. El problema que se puede presentar es que si la red corporativa
consiste sólo de enlaces privados y las conexiones a Internet son sólo dedicadas a tráfico
de salida, entonces los enlaces privados pierden el sentido de comunicar información
administrativa.
2.8.
Extensión de un Agente SNMP
Extender las capacidades del agente usualmente tiene relación a agregar o cambiar
su soporte MIB. La mayorı́a de los agentes cubren sólo un mı́nimo de objetos MIB,
siendo frustrante si se tiene pensado automatizar la administración de la red.
Actualizar la versión de SNMP no ayuda a obtener más información de un equipo
si se usa SNMPv1. La información disponible por un equipo es definido en el MIB del
agente siendo independiente del protocolo usado. La actual versión agrega nuevas funciones al protocolo principalmente en el aspecto de seguridad y opciones más sofisticadas
para obtener y configurar valores [4].
21
2. Protocolo SNMP
Esta extensión se puede definir como un programa o una ampliación del conjunto
de aplicaciones SNMP usada para aumentar la capacidad del MIB de un agente, entregando información desde una fuente externa (un script, programa o archivo). En la
mayorı́a de los casos el proceso es transparente para la estación que está consultando
o configurando a dicho agente, es decir, no diferencia entre el MIB nativo del agente
y su extensión. Muchas de las extensiones dan la capacidad de leer archivos, correr
programas y devolver sus resultados, ası́ como por ejemplo tablas de información. En
algunos 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 consiste
en una entidad de procesamiento denominada agente maestro y cero o más entidades
denominadas subagentes. Ambas entidades pueden residir en el mismo equipo o comunicarse mediante un proxy. El agente maestro se comunica con una estación como si
fuera un simple agente. Los subagentes tienen acceso directo a ciertos objetos MIB,
no ası́ el maestro, realizando funciones de administración en las variables, para luego
comunicárselas a su agente maestro a través del protocolo AgentX, independiente a
SNMP [9].
El conjunto de aplicaciones de Net-SNMP utilizada en el desarrollo práctico de este
proyecto permite la configuración de la extensión del agente SNMP. En este caso no
hace la distinción entre un agente maestro y la extensión denominada esclavo; hay sólo
un agente de que preocuparse.
Figura 2.8: Arquitectura para agentes extensibles [4]
22
Capı́tulo 3
Seguridad en SNMP
Simple Network Management Protocol versión 3 (SNMPv3) es un protocolo basado
en estándares de interoperabilidad. Provee de accesos de seguridad para dispositivos de
red (ej. routers, servidores) mediante una combinación de paquetes de autentificación y
encriptación sobre la red. Las principales caracterı́sticas de seguridad en SNMPv3 son:
Mensajes de integridad - Asegura que un paquete no haya sido manipulado en el
camino.
Autentificación - Verifica si el mensaje viene de una fuente válida.
Encriptación - Oculta el contenido de un paquete y ası́ evita que sea visto por una
fuente no autorizada.
SNMPv3 especifica modelos y niveles de seguridad. Un modelo de seguridad es una
estrategia de autentificación determinada para un usuario y grupo en que éste reside. El segundo término define el umbral permitido dentro del modelo de seguridad.
La combinación de un modelo y un nivel de seguridad determinará qué mecanismo
será empleado para intercambiar paquetes SNMP. Tres son los modelos de seguridad
disponibles: SNMPv1, SNMPv2 y SNMPv3, y tres son los niveles de seguridad: noAuthNoPriv, AuthNoPriv, AuthPriv. La Tabla 3.1 describe las combinaciones posibles entre
estos dos conceptos.
Tabla 3.1: Modelos y niveles de seguridad
Modelo
v1
v2c
v3
v3
v3
Nivel
noAuthNoPriv
noAuthNoPriv
noAuthNoPriv
authNoPriv
authPriv
Autentificación
Comunidad
Comunidad
Usuario
md5 o sha
md5 o sha
23
Encriptación
No
No
No
No
No
3. Seguridad en SNMP
Los Fundamentos de la seguridad en SNMPv3 se pueden describir a través de los siguientes 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 para
leer, escribir y crear.
Un grupo determina que lista de notificaciones pueden escribir sus usuarios.
Un grupo también define el modelo y el nivel de seguridad para sus usuarios.
Beneficios:
Los datos pueden ser coleccionados en forma segura por equipos SNMP sin el
miedo de que hayan sido forzados o corrompidos.
Manejo de la información confidencial. Por ejemplo un conjunto de comandos
SNMP que cambian la configuración de un router pueden ser configurados para
prevenir la exposición de su contenido en la red.
En SNMP existe la necesidad de tener seguridad, esto porque los objetos MIB que
son comunicados contienen información crı́tica de los equipos de la red. No se desea
que cualquier persona entre en la red para obtener direcciones IP, o información sobre
el tiempo que los equipos han estado funcionando, o si los enlaces están caı́dos, en fin
toda la información que hace referencia a la red. Esto es aún más importante cuando se
configuran los equipos a través de SNMP con operaciones SetRequest Obviamente no se
quiere que nadie más pueda configurar o interferir con los equipos enviando comandos
para cambiar objetos MIB que controlan la operación de estos [4].
Una de las grandes debilidades en SNMP v1/v2c es la seguridad. En estas versiones
la autentificación no era más que una contraseña basada en un nombre de comunidad
enviada de forma de texto a una estación. Su actual versión (SNMPv3) se caracteriza
principalmente por hacerle frente a este problema. No hay nuevas operaciones; SNMPv3
soporta todas las operaciones definidas por la versión 1 y 2c. Existen varias convenciones
nuevas, pero solo son caminos diferentes para interpretar los tipos de datos, definidos
en las versiones anteriores [3].
24
3. Seguridad en SNMP
3.1.
Primeros Pasos en SNMP
En SNMP v1, la seguridad incorporada era demasiado limitada; consistı́a en una
sola polı́tica y una simple tecnologı́a, descritas a continuación.
Objetos débiles: SNMP fue creado pensando en que los objetos deben ser diseñados de tal forma que provoquen el menor daño posible en caso de presentarse
una falla en su funcionamiento. Los diseñadores de SNMP usaron la polı́tica de que
los objetos MIB que son normalmente leı́dos no contengan información crı́tica, en
cambio aquellos que son modificados no tengan el control sobre funciones crı́ticas.
De esta manera, un objeto que es solo lectura y contiene descripción del equipo es
aceptado, no ası́ un objeto que mantiene información administrativa, ası́ como su
contraseña. De la misma forma, un objeto que puede ser leı́do y modificado puede
controlar por ejemplo cuando un computador será reiniciado, pero en ningún caso
tener el control sobre el reformateo de su disco duro.
Nombres de Comunidad: Una comunidad está formada de todos aquellos equipos en la red que son administrados por un conjunto determinado de estaciones
SNMP. Cada mensaje SNMPv1 enviado entre miembros de la comunidad es identificado por un nombre que forma parte de su encabezado. Este nombre representa
una simple contraseña evitando que un mensaje recibido con un nombre erróneo
sea aceptado.
Los nombres de comunidad protegen en situaciones en que se quiere forzar el sistema
mediante el envı́o de mensajes desautorizados. Sin embargo, esta simple contraseña se
envı́a en texto plano y puede ser descubierta fácilmente para luego ser usada para fines
equivocados. En otras palabras con este modelo de seguridad se está protegiendo la red
de un agresor ocasional pero no del profesional.
3.2.
Cambios en SNMPv3
Lo más significativo de esta versión es que abandona la noción de estaciones y
agentes. Ambos son llamadas entidades SNMP. Cada entidad consiste de un motor
(engine) y una o más aplicaciones, y permiten definir una arquitectura más que un
simple conjunto de mensajes; la arquitectura genera una autonomı́a de las piezas de un
sistema SNMP, lo cual hace posible implementar aspectos de seguridad.
25
3. Seguridad en SNMP
3.2.1.
Motor SNMP
Un motor SNMP se compone a través de 4 módulos: despachador, subsistema de
procesamiento de mensajes, subsistema de seguridad, y el subsistema de control de
acceso [4].
El despachador tiene la función de enviar y recibir mensajes. Determinar la versión
de cada uno de los mensajes (v1, v2c o v3) y, si la versión es soportada, entonces los
envı́a al subsistema para el procesamiento de mensajes. A demás tiene la facultad
de enviar los mensajes recibidos a otras entidades.
El subsistema de procesamiento prepara los mensajes para ser enviados (en
caso de consultas a otras entidades) o extrae los datos de aquellos mensajes que son
recibidos desde alguna entidad en particular. Esta etapa contiene múltiples módulos
de procesamiento de mensajes. Por ejemplo, un subsistema puede tener módulos para
procesar consultas SNMPv1, SNMPv2c y SNMPv3. También puede tener un módulo
para procesar otros modelos que puedan ser definidos a futuro.
El subsistema de seguridad provee servicios de autentificación y privacidad. La
autentificación puede ser basada en comunidades (v1 y v2c) o en usuarios (v3). La
autentificación basada en usuarios usa los algoritmos MD5 o SHA [17] y ası́ evita enviar
una contraseña en texto plano. Para encriptar y desencriptar mensajes SNMP (concepto
de privacidad) se usa el algoritmo DES. Actualmente DES ya no es el único algoritmo
soportado, 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 hacia
objetos MIB. Es posible definir qué objetos puede acceder un determinado usuario, y
además qué operación tiene permitido hacer sobre esos objetos. Por ejemplo, se podrı́a
limitar a un usuario con accesos de lectura-escritura para el subárbol mib-2 y para el
resto del árbol sólo puede realizar operaciones de lectura.
3.2.2.
Aplicaciones SNMP
La Tabla 3.2 describe las aplicaciones disponibles en la versión 3 de SNMP y que
representan las acciones que pueden ser realizadas entre las entidades [4].
26
3. Seguridad en SNMP
Tabla 3.2: Conjunto de aplicaciones para SNMPv3
Aplicación
Generador de
consultas
Generador de
respuestas
Generador de
notificaciones
Receptor de
notificaciones
Proxy
Descripción
Genera las consultas Get, Getnext, Getbulk y Set, y además procesa
las respuestas. Esta aplicación la implementa una estación, y de esta
manera puede monitorear y configurar equipos de red (router, switch,
hosts, etc).
Responde a las consultas Get, Getnext, Getbulk, y Set. Esta aplicación es implementada en el agente (router, switch, host, etc).
Genera traps y notificaciones. Esta aplicación es implementada en el
agente (router, switch, host, etc).
Recibe los traps y notificaciones. Esta aplicación es implementada
por la estación.
Permite facilitar el paso entre entidades. En otras palabras adelanta
los mensajes de una entidad a otra. Puede ser implementada por
ambos NMS o agente.
La Figura 3.1 describe la distribución de componentes dentro de cada una de las
entidades SNMP ya definidas [4].
Figura 3.1: Entidad SNMPv3 [4]
27
3. Seguridad en SNMP
3.2.3.
Convenciones definidas en SNMPv3
La Tabla 3.3 describe las convenciones que fueron agregadas en la versión 3 de
SNMP.
Tabla 3.3: Convenciones para SNMPv3
Convención
snmpEngineID
snmpSecurityModel
snmpMessageProcessingModel
snmpSecurityLevel
snmpAdminString
snmpTagValue
snmpTagList
KeyChange
Descripción
Identificador único para un motor SNMP. Los objetos de este tipo se construyen para identificación,
y no para direccionamiento, aunque una dirección
se puede usar para generar un valor especı́fico (engineIDType y engineIDNic en Net-SNMP).
Un nivel de seguridad SNMP (SNMPv1, SNMPv2c
o USM). USM se define como Modelo de seguridad basado en usuarios. que es implementado por
SNMPv3.
Modelo de procesamiento de mensajes usado por el
Subsistema para el Procesamiento de Mensajes.
Nivel de seguridad en que los mensajes son enviados, o en que las operaciones serán procesadas. Los
valores posibles son noAuthNoPriv (sin autentificación, sin privacidad), authNoPriv (con autentificación, sin privacidad), authPriv (con autenticación
y privacidad).
Es un string que contiene información administrativa, preferentemente una palabra. Su largo puede
ser mayor a 255 bytes.
Es un string con un valor representativo. Este valor
según el RFC 3413 puede ser entre otros: acme,
router, y host.
Es un string que contiene una lista de valores representativos (snmpTagValue).
Objeto usado para cambiar las llaves de autentificación y privacidad.
28
3. Seguridad en SNMP
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 o
VACM) detallan la seguridad que implementa la versión 3 de SNMP [4].
3.3.1.
Aspectos Básicos
La Tabla 3.4 describe algunos de los términos que forman parte del modelo USM en
la versión 3 de SNMP.
Tabla 3.4: Conceptos definidos en el modelo USM
Concepto
snmpEngineID
snmpEngineBoots
snmpEngineTime
snmpSecurityLevel
Motor SNMP autoritario
Descripción
Identificador para un motor SNMP. La sintaxis para este identificador es OctetString y no puede tener un valor
nulo. Muchas aplicaciones SNMPv3 utilizan un valor de
entrada para generar este identificador. Si no es especificado entonces se usa una combinación entre la enterprise
ID y la IP o MAC.
Contador del número de veces que un motor SNMP es
reiniciado.
El número de segundos desde que el contador snmpEngineBoots cambió su valor por última vez.
Existen 3 niveles de seguridad, ya descritos en la sección
anterior: noAuthNoPriv, authNoPriv, y authPriv. Nota
que puedes tener autentificación sin privacidad pero no
privacidad sin autentificación.
Un motor no autoritario podrı́a descubrir el snmpEngineID del motor autoritario con el que se está comunicando. Si el motor SNMP requiere una respuesta (Get,
Getnext, Bulk, Set o Inform) el receptor es el motor autoritario, en caso de requerir una respuesta (Trap o Report),
el motor autoritario es quien envı́a dicho mensaje. Generalmente la estación es el motor autoritario y el agente el
motor no autoritario.
Debido a la integración de nuevos conceptos y polı́ticas, el formato SNMP ha sufrido
ciertos cambios, agregando nuevos campos que son descritos en la Tabla 3.5.
29
3. Seguridad en SNMP
Tabla 3.5: Formato de un mensaje SNMPv3
Campo
msgVersion
msgID
msgMaxSize
msgFlags
msgSecurityModel
msgSecurityParameters
contextEngineID
scopedPDU
Descripción
Versión del mensaje.
Identificador usado entre NMS y agente para coordinar
mensajes de consulta y respuestas.
Tamaño máximo del mensaje soportado.
Valor de 8-bits que especifica si un reporte debe ser generado, si se usa privacidad, y si se usa autentificación.
Especifica el modelo de seguridad usado.
Contiene información especı́fica de seguridad.
Identifica únicamente una entidad SNMP. Una entidad es
una combinación entre el motor y aplicaciones SNMP. En
detalle se discute en la sección siguiente.
Bloque de datos construido entre el campo contextEngineID, contextName, y el pdu.
La información de seguridad contenida en el campo snmpSecurityParameter se subdivide en una serie de parámetros que se describen en la Tabla 3.6, y permiten al
receptor entender dicho mensaje para ser procesado y luego llevar a cabo una acción
según corresponda.
Tabla 3.6: Parámetros de snmpSecurityParameter
Campo
msgAuthoritativeEngineID
msgAuthoritativeEngineBoots
msgAuthoritativeEngineTime
msgUserName
msgAuthenticationParameters
msgPrivacyParameters
Descripción
snmpEngineID de un motor autoritario.
snmpEngineBoots de un motor autoritario.
snmpEngineTime de un motor autoritario.
Usuario que puede ser autentificar y encriptar el
mensaje.
Es nulo si no hay autentificación. En otro caso el
campo contiene el valor de la llave secreta (HMAC)
para el mensaje. Actualmente se especifican los algoritmos MD5 y SHA como alternativas de autentificación.
Es nulo si no hay encriptación. En otro caso su valor
es usado para formar el valor inicial del modo Cipher Block Chaining del algoritmo Data Encryption
Standard (DES).
30
3. Seguridad en SNMP
3.3.2.
Descubrir a su Motor Autoritario
Antes de realizar cualquier consulta Get, Getnext o Set, el motor no autoritario
debe realizar el proceso de descubrir la información de seguridad del motor autoritario.
Para ello se requiere que el campo msgSecurityParameter esté definido con los valores
de los parámetros snmpEngineID, snmpEngineBoots, y snmpEngineTime del motor
autoritario.
3.3.3.
Puntualidad USM
Una vez que el motor no autoritario conoce el valor de snmpEngineBoots y snmpEngineTime, debe tener la noción que este valor puede cambiar, por lo que cada segundo
que pase aumenta el valor que tiene contenido en snmpEngineTime y ası́ mantenerse
actualizado con el motor autoritario. Este módulo está preparado para actuar en caso
de que el valor de snmpEngineTime sufra un cambio abrupto (roll over).
3.3.4.
Autentificación
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 pueden
ser usadas solas, sino que en conjunción con el algoritmo para generar llaves de autentificación (HMAC). La llave de autentificación es compartida entre ambos motores antes
que el mensaje sea procesado.
3.3.5.
Privacidad
La encriptación de datos SNMP es realizada usando el algoritmo CBC-DES. Ası́ como
en la autentificación una llave debe ser conocida en ambos motores (autoritario y no
autoritario), para realizar el proceso de encriptación. Una tabla de usuario USM es usada para determinar la llave y descripción que es transmitida con el paquete en el campo
msgSecurityParameter.
3.3.6.
Tabla de Usuario USM
Cada entidad mantiene una tabla que almacena todos los usuarios que tienen acceso
al sistema vı́a SNMP. Esta tabla incluye los siguientes elementos:
31
3. Seguridad en SNMP
Tabla 3.7: Tabla de usuarios USM
Campo
Username
Authentication protocol
Authentication key
Privacy protocol
Privacy key
usmUserSpinLock
3.3.7.
Descripción
Nombre de usuario, a veces referido al nombre de seguridad.
Especifica el protocolo de autentificación si es que alguno es usado. Los valores válidos son: usmNoAuthProtocol, usmHMACMD5AuthProtocol, y usmHMACSHAAuthProtocol.
y La frase clave usada para la autentificación. Deberı́a ser
al menos de 8-bits.
Especifica el protocolo de privacidad usado. Los valores
válidos son: usmNoPrivProtocol y usmDESPrivProtocol.
La frase clave usada para la encriptación. Deberı́a ser al
menos de 8-bits.
Es un intento de bloqueo que permite coordinar múltiples
intentos para modificar la tabla de usuario.
Llaves Localizadas
Una llave localizada permite a un usuario usar la misma llave de autentificación y/o
encriptación en distintos motores SNMP. Es posible crear un administrador de llaves y
ası́ no tener que recordar la llave para cada motor que interactúa con la entidad. Los
campos 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. Esta
tarea se efectúa en el subsistema de control de acceso que forma parte del motor SNMP.
3.4.1.
Aspectos Básicos
Los campos del mensaje SNMPv3: msgFlags, msgSecurityModel, y scopedPDU son
usados por VACM para determinar los permisos sobre el objeto administrado. Si el
usuario no tiene permitido acceder a un objeto particular entonces se genera un mensaje
de error que es retornado al motor dueño de la petición. VACM usa 4 tablas de control
de acceso para diferentes aspectos.
A continuación se hace una breve descripción de cada tabla para entender su funcionamiento básico aplicado en la etapa de implementación de este proyecto.
32
3. Seguridad en SNMP
3.4.2.
Tabla Context
La tabla vacmContextTable es un conjunto de objetos administrados que contienen
derechos de acceso. Esta tabla almacena todos los contextos disponibles y es indexada
por el campo contextName.
vacmContextName
3.4.3.
Un nombre (caracterı́stico) para el contexto.
Tabla Security to Group
La tabla vacmSecurityToGroupTable es usado para almacenar la información del
grupo. Un grupo es hecho desde cero o mediante la combinación entre el modelo de
seguridad (securityModel) y el nombre de seguridad (securityName). Esta combinación
define que objetos manejados pueden ser accedidos. Esta tabla es indexada mediante
los campos securityModel y securityName.
vacmSecurityModel
vacmSecurityName
vacmGroupName
3.4.4.
Modelo de seguridad usado (ej. USM).
Si se usa USM como modelo de seguridad, entonces securityName and userName son idénticos.
Nombre del grupo a que esta entrada de la tabla pertenece.
Tabla Access
La tabla vacmAccessTable es usado para almacenar los derechos de accesos definidos
para los grupos. Esta tabla es indexada por groupName, contextPrefix, securityModel, y
securityLevel.
33
3. Seguridad en SNMP
vacmGroupName
vacmAccessContextMatch
vacmAccessContextPrefix
vacmAccessSecurityModel
vacmAccessSecurityLevel
vacmAccessWriteViewName
vacmAccessNotifyViewName
3.4.5.
Nombre de un grupo con derechos de acceso.
Es una forma simple de especificar si el contextName debe ser considerado como exacto o como un
prefijo. Si su valor es “exact” indica que el contextName deberı́a ser exactamente igual al valor en
vacmAccessContextPrefix. Si en cambio es “prefix”,
contextName puede ser igual a los primeros caracteres de vacmAccessContextPrefix.
ContextName deberı́a ser igual a vacmAccessContextPrefix ya sea en forma parcial o exacta dependiendo lo que indique vacmAccessContextMatch.
Modelo de seguridad (securityModel) que deberı́a
ser usado para tener acceso.
Define el nivel de seguridad (securityLevel) mı́nimo
para tener acceso.
Nombre de la vista (viewName) MIB autorizada
con permiso de escritura para un grupo determinado.
Nombre de la vista (viewName) MIB autorizada
con permiso de notificación para un grupo determinado.
Tabla View Tree Family
La tabla vacmViewTreeFamilyTable es usada para almacenar vistas MIB. Una vista
MIB es definida como una familia de vistas que representan un subárbol de objetos MIB
con un valor de máscara. La máscara indica que subidentificadores del subárbol asociado
por su OID es considerado en la definición (se puede asociar a la máscara de una subred,
ej. 192.168.28.0/24). Todas las vistas MIB son almacenadas en vacmViewTreeFamilyTable. Esta tabla es indexada por viewName y el identificador (OID) que representa al
subárbol MIB. El MIB VACM define un candado denominado vacmViewSpinLock, que
es usado para permitir que varios motores SNMP pueden coordinar modificaciones a
esta tabla.
vacmViewTreeFamilySubtree
vacmViewTreeFamilyMask
vacmViewTreeFamilyType
OID del subárbol que al combinarse con la máscara,
define uno o más vistas del subárbol MIB.
Su valor en conjunto con el correspondiente OID del
subárbol, define una o mas vistas del subárbol MIB.
Indica si las correspondientes vistas del subárbol
MIB definidas por la OID del subárbol y la máscara
son incluidas o excluidas desde la vista MIB.
La Figura 3.2 permite comprender el flujo lógico sobre el control de acceso a objetos
MIB, describiendo aquellos campos que son fundamentales en cada etapa de procesamiento de un mensaje SNMPv3.
34
3. Seguridad en SNMP
Figura 3.2: Flujo Lógico de VACM [4]
3.5.
Administración Distribuida (DisMan)
Un administrador de red distribuido es una aplicación que actúa en dos roles opuestos; un rol de administrador realizando funciones de control, y un rol de agente que
puede ser configurado y observado remotamente.
Hoy en dı́a con el crecimiento de las redes una administración distribuida es vital,
más allá de si son manejadas por personas en forma directa o remotamente. Un aspecto
importante de cómo administrar es la capacidad que tiene un sistema de automonitoreo
o que otro lo haga desde el exterior [12].
Este concepto se basa en el denominado MIB de eventos que provee la capacidad
de supervisar objetos MIB en un sistema local o remoto y toma una acción cuando
una determinada condición es encontrada. Este MIB fue pensado para evitar que una
estación periódicamente consulte objetos para darse cuenta si surgió algún tipo de falla.
De esta manera el equipo puede internamente supervisar objetos MIB y si por ejemplo
el valor de un objeto es modificado se puede generar una alarma que será recibida por
su estación.
35
3. Seguridad en SNMP
MIB de eventos se desarrolló a través de la experiencia con RMON, y provee una
serie de capacidades sobre alarmas y grupos de eventos. El gran aporte realizado sobre
lo ya existente fue permitir que las alarmas sean generadas por objetos MIB que están
en otro elemento dentro de la red. Las alarmas definidas en RMON son definidas como
triggers en el MIB de eventos, pero el concepto es el mismo, ya que mantienen el manejo
de umbrales de RMON solo que le agregan el concepto de boleanos y en cuanto al envı́o
de notificaciones en respuesta a las alarmas se agrega la capacidad de cambiar el valor
de un objeto MIB.
36
Capı́tulo 4
Traps e Informs
Traps e informs proveen un camino para que el agente de aviso a través del envı́o de
notificaciones a una estación cuando su estado no es el normal, o cuando sea necesario
tener conocimiento de ello. Las notificaciones que sean generadas por un agente van a
depender del soporte de MIBs que tenga. Para conocer cuáles son los traps e informs
definidos en el agente basta con buscar dentro de los archivos MIBs el término traptype (SMIv1) o notification-type (SMIv2).
La estación puede ser configurada para responder a distintas notificaciones cuya
respuesta puede ser desde descartar el mensaje a correr una aplicación que envı́a un
correo al administrador de la red dando aviso de lo ocurrido (o tomar una acción más
drástica, ası́ como apagar la fuente de alimentación) [4].
4.1.
La Necesidad de Traps en SNMP
En el caso de obtener información para fines de monitoreo, la interrogación es un
tipo de comunicación ideal. Por ejemplo, las consultas de tipo Get pueden ser usadas
para verificar la configuración de un equipo, conocer la cantidad de errores generados
durante un periodo de tiempo, o generar estadı́sticas. Además este tipo de comunicación
es el único método para modificar el valor de los objetos en un equipo a través de Set.
El problema de la interrogación es que no está adaptada para entregar la información
en forma rápida. La razón es que este tipo de comunicación es siempre iniciada por
la estación. Si algo importante ocurre en el agente, la estación jamás se enterarı́a a
menos que se le consulte especı́ficamente por los datos que han sido modificados. Esto
significarı́a que las variables necesitan ser comprobadas en cada momento por la estación
provocando una sobrepoblación de paquete SNMP en el caso de tener gran cantidad de
equipos administrados. Para solucionar este problema, SNMP introdujo un nuevo tipo
de mensaje como es la interrupción, cuya principal caracterı́stica es que la comunicación
se inicia desde el agente [10].
37
4. Traps e Informs
4.2.
Conceptos Básicos
Un trap es básicamente una notificación asincrónica enviado desde un agente a
una estación, a través del protocolo de transporte UDP (puerto 162). Debido a que la
transmisión no es confiable el agente no puede saber si el trap ha llegado a destino, y la
estación 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 razón para que sea administrada.
En detalle, los traps se pueden localizar en dos categorı́as: genéricos y especı́ficos
para una empresa. Existen 7 tipos de traps enumerados de 0 a 6, tal como se indica
en la Tabla 4.1, permitiendo representar diferentes estados del sistema; desde reinicio
del sistema (coldStart) y cambios de estado de una interfaz (linkUp y linkDown) hasta
trap especı́ficos dependiendo de la empresa (enterpriseSpecific). La razón de que las
notificaciones sean un mecanismo de administración poderoso, se debe a los traps especı́ficos. Cualquier empresa con un número de identificador MIB puede crear traps
para condiciones en que se considere vital supervisar. La noción de un trap especı́fico
es extremadamente flexible porque las organizaciones permiten subdividir el subárbol
MIB como ellas quieran. Por ejemplo, si el identificador de una empresa es 2789, su OID
completo 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 versión de SNMP los traps se definen como notification-type, eliminando
la noción de traps genéricos, definiéndolos como traps especı́ficos en MIBs públicos.
Un trap SNMPv2 es generado y transmitido por un agente en respuesta a una
alarma activada por una aplicación. Luego será usado para dar aviso a una estación que
un evento ha ocurrido o a una condición presentada. Este mecanismo de envı́o no tiene
asociada una confirmación por lo que el agente no espera una respuesta [11].
Es importante mencionar que en la versión 3 de SNMP sólo se agregaron aspectos de
seguridad a su definición en SNMPv2, ya sea en temas de autentificación y privacidad.
38
4. Traps e Informs
Tabla 4.1: Traps genéricos.
Nombre y número
coldStart(0)
warmStart(1)
linkDown(2)
linkUp(3)
authenticationFailure(4)
egpNeighborLoss(5)
enterpriseSpecific(6)
4.2.2.
Definición
Indica que el agente se ha reiniciado. Todas las variables
administradas serán reiniciadas; variables de tipo Counter y Gauge tendrán valor 0. Este tipo de traps es útil para
agregar un nuevo hardware a la red. Cuando un equipo
es encendido, enviará un trap a su estación la cual una
vez recibido podrá configurar sus parámetros.
Indica que el agente llevó a cabo su reinicio. Es este caso
la estación no reiniciará sus variables.
Se envı́a cuando la interfaz de red de un equipo está caı́da.
La primera variable enviada es el ı́ndice de la interfaz
(ifIndex).
Se envı́a cuando la interfaz vuelve a activarse. La primera
variable enviada es el ı́ndice de la interfaz (ifIndex).
Indica que alguien ha tratado de consultar al agente pero
con un identificación incorrecta (comunidad o nombre de
seguridad).
Indica que un vecino EGP1 esté caı́do.
Indica que el trap es especı́fico de una empresa. Vendedores SNMP y usuarios pueden definir sus propios traps
bajo la rama private-enterprise del árbol MIB. Para procesar este trap la estación tiene que decodificar el número
especı́fico del trap que es parte del mensaje SNMP.
Informs SNMPv2
SNMPv2 incorpora un segundo tipo de notificación: InformRequest. Comparado con
un trap no son lo mismo pero tienen dos aspectos que los relacionan: ambos mensajes
comunican información mediante interrupción y no interrogación, y segundo, los dos
mensajes pueden ser usados en conjunción.
El propósito de un inform es facilitar la comunicación entre estaciones generando
mensajes de confirmación ante la llegada de notificaciones. Si se desea que una estación
informe a otra estación entonces le envı́a un mensaje de tipo InformRequest. Una vez
recibido el mensaje responderá enviándole un mensaje de tipo Response, y ası́ avisa que
el mensaje fue recibido.
1
Exterior Gateway Protocol, diseñado para el uso entre redes, bajo el control de dos organizaciones
diferentes.
39
4. Traps e Informs
Un camino común en que se usan ambos tipos de mensaje, es para diferenciar
avisos cuando un trap ocurre. Por ejemplo un equipo administrado experimenta una
falla eléctrica, generando un Trapv2 que es enviado a la estación #1. El administrador
desea que los traps recibidos por la estación #1 sean adelantados a la estación #2, y
de esta manera un mensaje InformRequest es usado para el enviar la información entre
ambas estaciones [10].
40
Capı́tulo 5
Net-SNMP
Open Source SNMP System
Simple Network Management Protocol (SNMP) es un protocolo que permite supervisar los equipos que forman parte de una red. Net-SNMP es un conjunto de aplicaciones
usadas para implementar los protocolos SNMPv1, SNMPv2c, SNMPv3 usando IPv4 e
IPv6 [13]. Este conjunto incluye:
Aplicaciones de lı́nea de comandos para:
• Obtener información desde equipos capaces de manejar el protocolo SNMP,
ya sea usando consultas simples (snmpwalk, snmpgetnext), o múltiples requerimientos (snmpwalk, snmptable, snmpdelta).
• Manipular información sobre la configuración de equipos SNMP (snmpset).
• Obtener un conjunto de información desde un equipo SNMP (snmppdf, snmpnetstat, snmpstatus).
• Traducir objetos MIB entre OIDs numéricos y textuales, y mostrar el contenido y estructura de la MIB (snmptranslate).
Un explorador gráfico de MIBs (tkmib), usando Tk/perl.
Un demonio para recibir notificaciones (snmptrapd). Las notificaciones pueden ser
guardadas en un log (como syslog o un archivo de texto plano), ser reenviadas a
otro sistema de gestión de SNMP, o a una aplicación externa.
Un agente configurable para responder a peticiones SNMP sobre información de
gestión (snmpd). Incluye el soporte para una amplia cantidad de módulos de información MIB, y puede ser aumentado usando carga dinámica de módulos, comandos y scripts externos, y los protocolos: SNMP multiplexing (SMUX) y Agent
Extensibility (AgentX).
Una biblioteca para desarrollar nuevas aplicaciones SNMP, tanto en C como Perl.
41
5. Net-SNMP Open Source SNMP System
Net-SNMP está disponible para muchos sistemas operativos Unix y también en
Microsoft Windows, siendo diferente su funcionamiento en cada uno de estos.
El proyecto Net-SNMP nace en 1992, en Carnegie-Mellon University. El grupo de
Redes en CMU (dirigido por Steve Waldbusser) desarrolló la implementación del protocolo SNMP. Esta aplicación contenı́a una librerı́a, un simple conjunto de comandos,
y un agente (que entregaba más del estándar de información administrativa definida
en RFC 1213). El código fue disponible públicamente, y usado por un gran número de
personas (incluyendo varias compañı́as comerciales). En la actualidad muchos de los
códigos han sido contribución de algunas fuentes abiertas de todo el mundo y mediante
algunos bug-patches de la comunidad, que ha provisto una ayuda importante para el
desarrollo de esta aplicación.
5.1.
Instalación de Net-SNMP
En el sitio oficial de Net-SNMP se pueden encontrar los archivos ejecutables para
los diferentes sistemas operativos o si se desea, también está disponible el código fuente
para su compilación [13].
Debido a que esta implementación requiere de funciones avanzadas tanto para el
agente como para la estación es necesario hacer uso del código fuente de esta aplicación.
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 continuación:
Descargar la aplicación y luego descomprimirla en un directorio cualquiera. En
este caso, se utilizó la versión no estable 5.4.1 pre-releases dado que contiene una
completa implementación del protocolo SNMPv3 para el receptor de notificaciones y además soluciona algunos bugs1 que se encontraron durante el periodo de
adaptación usando la versión estable 5.4.
Entrar en el directorio creado, y ejecutar el script de configuración configure.
Dicho script chequeará nuestro sistema en busca de bibliotecas y paquetes que
necesita el sistema para compilar el código. Además, permite incluir una serie de
opciones de compilación que servirá para activar los módulos necesarios para la
implementación. La lı́nea comandos para el script de configuración considerando
las opciones requeridas en la siguiente:
./configure --enable-embedded-perl --enable-shared
--with-mib-modules=ucd-snmp/lmSensors --prefix=/usr/local/net-snmp
1
bug: Error en un software o hardware que causa su mal funcionamiento.
42
5. Net-SNMP Open Source SNMP System
Las opciones usadas permiten activar el soporte para Perl, cargar todas las funcionalidades disponibles para el receptor de notificaciones (en estación), agregar el
módulo MIB llamado LM-Sensors para integrar información sobre el hardware de
la central (en agente), y especificar la ruta en donde será instalada la aplicación.
Definir la ruta de instalación permite mantener un orden de la ubicación de los
directorios y ası́ facilitar a futuro el proceso de desinstalación. La siguiente lı́nea
de comandos permite obtener la lista completa de las opciones disponibles en el
script de configuración:
./configure --help
El siguiente paso es compilar la aplicación que permitirá obtener en el directorio
actual todos los archivos ejecutables.
make
El comando make través de la opción test permite realizar una prueba de comprobación para verificar si todos los módulos y librerı́as serán cargados correctamente
una vez finalizado el proceso de instalación. La lı́nea de comandos completa para
este caso es la siguiente:
make test
EL paso final es instalar los archivos ejecutables obtenidos en el proceso de compilación, para lo cual se debe escribir como superusuario (root) la siguiente lı́nea
de comandos:
make install
Al final de proceso se obtiene un conjunto de directorios que representan el conjunto de aplicaciones de Net-SNMP. Su ubicación va a depender de la ruta especificada como opción en el script configure con la opción --prefix. Desde este
momento la variable $netsnmpdir define la ruta de residencia del conjunto de
aplicaciones de Net-SNMP (/usr/local/net-snmp).
Cabe destacar que durante el proceso de instalación de Net-SNMP no se crean los
scripts snmpd y snmptrapd en el directorio /etc/init.d, los cuales son necesarios para
iniciar y finalizar los servicios SNMP (agente y receptor de notificaciones) mediante las
órdenes
/etc/init.d/snmpd{start|stop|} y /etc/init.d/snmptrapd{start|stop}. Una opción serı́a
ejecutar manualmente el agente y receptor de notificaciones mediante las lı́neas $netsnmpdir/sbin/snmpd y $netsnmpdir/sbin/snmptrapd respectivamente.
43
5. Net-SNMP Open Source SNMP System
5.2.
Configuración para Agente SNMP
snmpd es un agente SNMP que escucha por el puerto UDP 161 (por defecto), esperando la llegada de peticiones desde algún programa de gestión SNMP (estación).
Cuando recibe una petición, recopila la información y lleva a cabo la operación solicitada.
EL agente se ejecuta como un demonio, es decir, permanece en segundo plano durante toda la ejecución. En su arranque, buscará su archivo de configuración snmpd.conf)
en los directorios
$netsnmpdir/etc/snmp, /usr/lib/snmp, $home/.snmp y /var/lib/snmp siguiendo
este mismo orden. Dicho archivo describe el comportamiento del agente durante la ejecución, aunque no es imprescindible para que éste funcione y responda peticiones, ya
que tiene por defecto una configuración preestablecida.
En la secciones siguientes se describen algunas de las directivas que forman parte
de la configuración del agente SNMP, las cuales forman parte primordial de esta implementación. Con el fin de usar al máximos las funciones del protocolo SNMPv3, es que el
nivel de seguridad configurado será authPriv, es decir, toda consulta será autentificada
a través de un nombre de seguridad y contraseña, y encriptada para evitar ataques sobre
la configuración de equipos.
5.2.1.
Aspectos Fundamentales para la Implementación
Información Básica del Sistema
Algunas de las siguientes directivas modifican el valor de varios objetos MIB, y otras
sólo sirven para la propia configuración del agente. En caso de configurar una de estas
directivas, se convertirá en un objeto de sólo lectura y, por tanto no se podrá cambiar
su valor a través del comando snmpset.
∴ syslocation string
Cambia el valor del objeto system.sysLocation, usado para especificar la localización fı́sica del host en donde se ejecuta el agente.
syslocation ‘‘Laboratorio ATMLab’’
∴ syscontact string
Permite definir la dirección de contacto de la persona responsable del equipo, a
través del objeto system.sysContact.
syscontact ‘‘pvalle@atmlab.utfsm.cl’’
44
5. Net-SNMP Open Source SNMP System
∴ sysname string
Especifica el nombre del equipo a través del objeto system.sysName. Generalmente
se refiere al nombre completo del dominio.
sysname ‘‘BIONICO-Server.atmlab.utfsm.cl’’
∴ sysservices number
El objeto system.sysServices indica el conjunto de niveles de la arquitectura OSI
que el host puede soportar. El valor del objeto es una suma que inicialmente vale
cero. Para cada capa L de la arquitectura OSI soportada por el equipo, sumamos
a sysServices el valor de 2 elevado a L-1. En caso de que el equipo no soporte OSI
(el caso más general), sólo se debe tener en cuenta los niveles 1 (fı́sico), 2 (enlace),
3 (red), 4 (transporte) y 7 (aplicación). De esta manera el valor recomendado para
un servidor (o central IP-PBX) es 72 (capa de transporte y aplicación).
sysservices 72
∴ sysdescr string
Crea un breve descripción del equipo editando el objeto system.sysDescr. Por convención contiene un nombre completo, una descripción del hardware, del sistema
operativo y del software de red.
sysdescr ‘‘BIONICO-Server.atmlab.utfsm.cl Linux
2.6.18-4-686’’
∴ agentgroup idgroup
Esta directiva causa que el agente cambie su identificador de grupo después de
abrir el puerto en el que escucha. IDgroup puede ser el nombre de un grupo o
su identificador numérico y corresponde en el caso de esta implementación a un
grupo registrado en el sistema Linux.
agentgroup root
∴ agentuser idusuario
Funciona en forma análoga a la directiva agentgroup, sólo que en este caso refiere
al identificador de usuario del sistema Linux.
agentuser root
45
5. Net-SNMP Open Source SNMP System
Las directivas agentuser y agentgroup hacen referencia a un usuario y grupo del
sistema respectivamente, es decir, ambos deben existir para el sistema operativo.
Es importante que el usuario tenga privilegios suficientes para ejecutar aplicaciones del sistema, las cuales son fundamentales para implementar el sistema de
administración distribuida (DisMan) descrito en detalle en la sección 3.5 y que
más adelante se dan los pasos para su configuración. Con el simplificar el proceso, se utilizó al superusuario root ya que tiene todos los permisos para ejecutar
los comandos que serán invocados por el agente para realizar tareas de comparación sobre aquellos objetos MIB definidos en las reglas que contengan la directiva
monitor.
Configuración SNMPv3
Para responder a mensajes SNMPv3 se requiere definir un identificador único para
el agente SNMP denominado engineID. Este ID normalmente se determina automáticamente, usando dos valores que no son fáciles de predecir: un valor aleatorio y los
segundos que el agente está activo desde su última ejecución. El método anterior se
considera el recomendado, sin embargo existe la posibilidad de generar su ID a través
de un palabra cualquiera. Por motivos de seguridad se recomienda que la palabra sea
escogida pensando como si fuera una contraseña, no siguiendo el ejemplo siguiente como
referencia.
∴ engineID string
El engineID es construido desde la palabra definida como String.
engineID 01020304050120
46
5. Net-SNMP Open Source SNMP System
Control de Acceso
snmpd soporta View-Based Access Control Model (VACM) definido en el RFC 2575,
descrito en detalle en la sección 3.4 de este documento. Para este fin hay varias directivas
relacionadas con el control de acceso, las cuales se pueden representar en 4 grupos
básicos.
∴ rouser user [noauth|auth|priv [oid | -V view [context]]]
∴ rwuser user [noauth|auth|priv [oid | -V view [context]]] Especifica un usuario
SNMPv3 que tiene permisos de solo lectura (get y getnext) o lectura-escritura
(get, getnext y set) respectivamente. Por defecto, permite el acceso a todo el
árbol oid para requerimientos autentificados SNMPv3 (auth), usando el contexto
“ ” por defecto. Una alternativa pero que entrega el mı́nimo nivel de seguridad
es usar “noauth” (permite requerimientos no autentificados), o el máximo de seguridad a través de “priv” (para forzar el uso de encriptación). EL campo oid
restringe el acceso para ese usuario al subárbol cuya raı́z es oid, o la vista descrita
por view. Opcionalmente se puede definir un contexto o un contexto.* para denotar un prefijo del contexto. Si no se especifica el campo context (o la opción
* es usada), esta directiva no discriminará entre los contextos existente.
rouser root priv .1
rwuser pc120encrypter priv .1
En este caso se definió el acceso de dos usuarios, en donde root corresponde al usuario del sistema para efectuar la tareas de la directiva monitor, y pc120encrypter
es el medio de autentificación para realizar consultas desde la estación de administración. El proceso de creación se realiza en la directiva createUser descrita en
detalle en la sección 3.2.3.
∴ rocommunity community [source [oid]]
∴ rwcommunity community [source [oid]]
Especifica una comunidad SNMPv1 o SNMPv2c cuyos permisos serán de solo
lectura (get y getnext) o lectura-escritura (get, getnext y set) respectivamente. Por defecto, se puede acceder al árbol completo, sin importar el origen
de las peticiones. source puede ser usada para restringir el acceso a peticiones
desde uno o más sistemas especificados. El campo oid restringe el acceso para esta
comunidad al subárbol cuya raı́z es el oid. Los contextos son tı́picamente menos
relevantes a las versiones SNMP basadas en comunidades, pero su comportamiento
se aplica de igual forma.
rwcommunity voipcommunity localhost
47
5. Net-SNMP Open Source SNMP System
En cada caso, solo una directiva puede ser especificada para un usuario SNMPv3
o comunidad dada. No es recomendable especificar ambas directivas : rwuser y
rouser refiriéndose al mismo usuario SNMPv3 (u opciones de comunidad equivalentes). La directiva rwuser provee todo el acceso de rouser (además del soporte
set). Lo mismo se aplica para las directivas basadas en comunidad (rocommunity
y rwcommunity).
∴ com2sec [-Cn context] secname source community
Relaciona una comunidad SNMPv1 o SNMPv2c a un nombre de seguridad - que
puede ser desde un rango determinado de fuentes (source), o en forma general
(“default”). Una fuente restringida puede ser entre un determinado equipo (o dirección), 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 (presumiblemente
con diferentes fuentes (source), pero es la primera combinación fuente/comunidad
que se aplique a la petición de entrada la que será elegida.
Varias combinaciones fuente/comunidad pueden ser relacionadas al mismo nombre de seguridad.
Si se especifica context (usando -Cn), la comunidad será relacionada a un nombre de seguridad en el contexto SNMPv3 escogido. En otro caso se usará el contexto por defecto es (“ ”).
com2sec local localhost voipcommunity
∴ group group {v1|v2c|usm} secname
Relaciona un nombre de seguridad a un grupo especı́fico. Un grupo puede estar
relacionado a varios nombres de seguridad apareciendo más de una vez esta directiva con el mismo nombre de grupo, permitiendo ası́ una sola configuración de
acceso aplicable a varios usuarios y/o comunidades.
Los grupos pueden ser configurados en forma separada para dos modelos basados en comunidad (ej. v1 y usm) - una sola directiva com2sec (o equivalente)
será tı́picamente acompañada por 2 directivas group.
group localgroup v1 local
group localgroup v2c local
group localgroup usm local
48
5. Net-SNMP Open Source SNMP System
∴ view vname type oid [mask]
Se define una vista como un conjunto de objetos del árbol oid. Varias de estas
directivas pueden especificar un mismo nombre vname, para construir una colección más compleja de oids. El campo type puede ser include o excluded, que
permiten definir una vista más compleja (ej. excluir ciertos objetos más sensibles
desde otro subárbol accesible).
mask es una lista de octetos hexagesimales (opcionalmente separados por . o :)
en donde los bits cuyo valor es 1 indican qué subidentificadores oid se aplican a
la vista. Si esto no se especifica, por defecto todos los bits tienen valor 1.
view all included .1 80
view system included system fe
view mib2 included .iso.org.dod.internet.mgmt.mib-2 fc
∴ access group context {any|v1|v2c|usm} level prefx read write notify
Relaciona un grupo de usuarios/comunidades (con un particular nombre de seguridad y mı́nimo nivel de seguridad, y en un contexto especı́fico) a una o más
vistas, dependiendo de la petición que es procesada.
El campo level puede ser “noauth”, “auth” o “priv”. prefx especifica como debe
ser aplicado context, el contexto de la petición de entrada, ya sea como .exact.o
”prefx”. read, write y notify especifica la vista que será usada para peticiones
get*, set y trap/inform. Para accesos v1 o v2c, level necesariamente debe
ser “noauth”.
access localgroup
access localgroup
access localgroup
v1 noauth exact system none none
v2c noauth exact mib2 none none
usm auth exact all all all
Monitoreo Activo
El agente SNMP normalmente espera por una petición desde una estación para procesarla y luego responder. Si no ha recibido ninguna petición, el agente no inicia ninguna
acción. En esta sección se describen aquellas directivas que permiten hacer su rol mucho
más activo y usar el más alto nivel de seguridad en SNMPv3.
Estas directivas fueron configuradas para que el usuario pc120encrypter sea quien
envı́e las notificaciones a su estación de administración. Además se activó la función de
generar mensajes de alarmas en caso de recibir consultas con fallas de autentificación,
es decir, nombre de seguridad, engineID y/o contraseña errónea.
49
5. Net-SNMP Open Source SNMP System
∴ trapsess [snmpcmd args] host
Permite definir un método genérico para definir el destino de las notificaciones.
snmpcmd args son aquellas opciones usadas en los comandos: snmptrap o snmpinform utilizados para enviar cualquier notificación. La opción -Ci puede ser
usada (con -v2c o -v3) para generar un informe.
Esta directiva es muy útil para definir receptores de traps SNMPv3.
trapsess -e 0x80001f88043031303230333034303530313230 -v 3 \
-u pc120encrypter -l authPriv 192.168.28.101:162
nota: Para la generación de traps v3 a través de esta directiva es necesario especificar su propio engineID, pero no ası́ aquellas opciones de autentificación y privacidad ya que son leı́das desde su archivo de creación de usuarios
(/var/net-snmp/snmpd.conf).
∴ authtrapenable {1 | 2}
Si su valor es 1, activa la generació de notificaciones por fallas de autentificación
(por defecto su valor es 2). Esta directiva al ser declarada, convierte el objeto MIB
snmpEnableAuthenTraps.0 en sólo lectura (originalmente es lectura-escritura).
authtrapenable 1
DisMan Event MIB
Las directivas anteriores permiten definir donde serán enviadas las notificaciones
generadas, pero no el instante en que serán enviadas, o quiénes deben ser generados.
Esto le corresponde al subárbol Event MIB desarrollado por Distributed Management
(DisMan), grupo de trabajo de IETF.
∴ agentSecName name
∴ iquerySecName name
Define al usuario SNMPv3 por defecto para realizar consultas internas sobre información necesaria, ya sea evaluar una expresión monitoreada o construir una
notificación. Este usuario debe ser creado explı́citamente mediante la directiva
createUser y con accesos apropiados. Además debe ser un usuario registrado del
sistema descrito a través de las directivas agentuser y agentgroup.
nota: Si se usa cualquiera de las directivas de DisMan, especificar la directiva
agentSecName de lo contrario el demonio generará errores sobre usuario requerido.
iquerySecName root
50
5. Net-SNMP Open Source SNMP System
∴ monitor [options] name expression
Define un objeto MIB de monitoreo. Si la condición expression se cumple, entonces se acciona un determinado evento, luego puede enviar una notificación o
escribir un objeto previamente asignado (o ambos). El evento solo se activará una
vez que la expresión se cumpla por primera vez, y no se volverá a activar hasta
que dicha condición sea falsa y luego se vuelva a cumplir. name es un nombre administrativo para esta expresión, y se usa para indexar la tabla mteTriggerTable
(y derivados).
expression
Existen 3 tipos de expresión soportadas por el Event MIB: test de existencia, booleano, y umbral.
oid — !oid — !=oid
define un test de existencia(0). El oid especifica un test, que será activado
cuando (una instancia de) el oid es creado.
La expresión !oid especifica un test .ausente”, que se activará cuando el oid
es eliminado.
La forma !=oid especifica un test ”modificado”que se activará cuando el valor
de oid cambie.
oid op value
define un test booleano(1). op puede ser uno de los operadores (! =, ==, <
, <=, >, >=) y value debe ser un valor entero para la comparación.
oid min max [dmin dmax]
define un test de umbral(3). min y max son valores enteros, que especifican los
niveles mı́nimo y máximo respectivamente. Si el valor de oid no cumple con
ambos niveles entonces el monitor activará un determinado evento.
Al aumentar el umbral el test será actualizado cuando el valor monitoreado
esta por debajo de min. En el caso que el umbral disminuya el test se actualiza
cuando el valor pasa a max.
Los parametros opcionales dmin y dmax crean pruebas similares, pero trabajando con diferenciales entre muestras sucesivas.
51
5. Net-SNMP Open Source SNMP System
options
Existen varias opciones para controlar el comportamiento de la expresión
monitoreada. Estas son:
-d
La expresión debe ser evaluada usando el diferencial entre muestras.
-d oid
-di oid
Especifica un marcador de discontinuidad para validar diferenciales. Si tiene la
instancia -di será usado exactamente como está dado. Pero si tiene -d se considera como un subárbol. Si se especifica el flag -I , entonces no hay diferencia
entre esas dos opciones.
-e event
Evento que será invocado cuando el monitor es activado. Si esta opción no se
declara, entonces se generará una de las notificaciones definidas en el DISMANEVENT-MIB.
-I
Indica que la expresión monitoreada debe ser aplicada a un oid especı́fico (no
como un subárbol). Por defecto, el oid debe ser tratado como un subárbol y
ası́ el monitor cubre todas las instancias posibles.
-i oid
-o oid
define nombres de objetos adicionales que serán incluı́dos en la notificación,
además de los objetos referidos para esta directiva. Puede ser útil cuando se
quiere enviar una fila completa de la tabla.
Si no esta la opción -I contenida en options, entonces cualquier objeto del
subárbol puede ser agregado usando la opción -o y el oid padre, en cambio
si utilizamos -i entonces sólo se considera la oid explicitamente. Si el flag -I
está declarado entonces no hay diferencia entre ambas opciones.
-r frecuency
evalúa la expresión cada frecuency segundos. Por defecto la expresión
será evaluada cada 600s (10min).
-S
Indica que la expresión no deberı́a ser evaluada cuando el agente se inicie sino
cuando el periodo expire por primera vez.
52
5. Net-SNMP Open Source SNMP System
-s
Indica que la expresión debe ser evaluada al inicio del agente y está definido
por defecto.
-u secname
Especifica al usuario que se usará para escanear el sistema, en el caso de que
sea diferente al definido en la directiva iquerySecName. Este usuario debe ser
creado explı́citamente y con permisos de accesos adecuados.
A continuación se describen las reglas usadas para la construcción del Sistema
de Reconocimiento de Fallas, las cuales tienen como objetivo analizar aquellos
servicios de mayor interés sobre un servidor que en este caso actuará como central
IP-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 análisis de carga de la CPU y uso de memoria Swap, son necesarias las
directivas load y swap para describir los niveles máximos y mı́nimos permitidos
y que en caso de no cumplirse se activará el flag de error según corresponda. A
continuación se describen los valores definidos para esta implementación.
Tabla 5.1: Objetos monitoreados en la central IP-PBX 3
item
laTable
objeto
laLoadInt.1-3
lmtempcpu
lmTempSensorsValue.2
lmtempmotherboard
lmTempSensorsValue.1
memory
memAvailSwap,
memTotalSwap
53
descripción
El porcentaje de carga promedio del
procesador para 1, 5 y 15 min no debe sobrepasar de 80, 40 y 30 % respectivamente.
La temperatura de la CPU no debe
sobrepasar los 50 o C.
La temperatura de la placa madre
no debe sobrepasar los 40 o C.
El uso en memoria Swap no
debe sobrepasar los 256 KBytes.
5. Net-SNMP Open Source SNMP System
∴ load max1 [max5 [max15]]
Analiza la carga promedio del sistema, especificando los valores máximos para un
promedio de 1, 5 y 15 min. Si alguno de estos valores excede el máximo descrito
entonces el correspondiente flag laErrorFlag tendrá valor 1, describiéndose dicho
error en el objeto laErrMessage. Cabe destacar que los valores descritos en esta
directiva son tratados como porcentajes.
load 80 40 30
∴ swap min
Analiza la cantidad de memoria Swap disponible en el sistema. En el caso de
que esté debajo de min kb, entonces el objeto memErrorSwap tendrá valor 1,
describiéndose dicho error en el objeto memSwapErrorMsg.
swap 256
∴ notificationEvent ename notification [-n] [-i oid | -o oid ]*
Define un evento para una notificación cuyo nombre es ENAME. Este puede ser
activado desde la directiva monitor especificando la opción -e ename. notification debe ser un oid definido como notification-type para ser generada.
Si se da la opción -n, la notificación incluirá los objetos como está especificado
en la cláusula object de la definición de mib de notificación. Esta opción debe
venir después de notification (y el archivo del mib debe estar disponible y cargado por el agente). En otro caso estos objetos deberán ser listados explı́citamente
(acá o en la correspondiente directiva monitor).
Las opciones -i oid y -o oid especifican adicionales objetos para ser agregados al
payload de la notificación, después de la lista estándar. Si la entrada que activó este evento involucra una expresión * (se considera un subárbol de oids), el sufijo
de la instancia involucrada será agregada a cualquier oid especificado usando -o,
mientras que aquellos especificados con -i serán tratados como instancias exactas.
Si la opción -I fue especificada en la directiva monitor, entonces no existe diferencias entre ambas opciones.
54
5. Net-SNMP Open Source SNMP System
Configuración de subagentes AgentX
AgentX es un protocolo que permite al agente estar dividido en varios procesos
separados, ya sea un solo host o entre varios hosts de una red. Para el desarrollo de esta
implementación se configuró este agente como maestro para ser el medio de intercambio
de consultas entre la estación de administración y la aplicación Asterisk.
Las operaciones internas de AgentX son totalmente transparentes para la estación
SNMP, es decir, cuando consulta al agente, siempre tendrá la impresión de estar tratando
con un agente SNMP convencional.
∴ master agentx
Se usa esta directiva para definir al agente como maestro dentro del protocolo
AgentX.
∴ agentXSocket [<transport-specifier>:] <transport-address> [, ...]
Esta directiva define la dirección en la que escucha el agente master. Por defecto
se define el archivo “/var/agentx/master”, que es un socket Unix accesible sólo
desde subagentes que tengan el mismo identificador de usuario que el maestro. En
este caso se define la ruta que viene en la configuración 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 demás de su directorio raı́z. sockperms y dirperms deben ser dı́gitos de 8 bits.
Por defecto este socket sólo será accesible por subagentes que tengan el mismo
userid que el agente.
agentXperms 0660 0550 root root
∴ agentXTimeout num
Define el periodo de timeout (num segundos) para una consulta AgentX. Por
defecto es 1 segundo.
agentXTimeout 5
∴ agentXRetries num
Define el número de intentos para una consulta AgentX. Por defecto num es 5.
agentXRetries 10
55
5. Net-SNMP Open Source SNMP System
Carga Dinámica de Módulos
La carga dinámica de módulos es una forma de incluir un nuevo módulo MIB en el
agente (o subagente) sin tener que recompilarlo. En la versión de Net-SNMP utilizada
tiene activada esta función por defecto, pero para hacerla en forma explı́cita es necesario
agregar la opción --with-mib-modules=ucd-snmp/dlmod al momento de ejecutar el
script configure.
Los pasos a seguir para la compilación rápida de módulos en un agente SNMP son:
Guardar los archivos referentes al módulo en un directorio común.
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 módulo.
Como resultado se obtiene un archivo con extensión .so que será cargado mediante
la directiva dlmod descrita más adelante.
make nstAgentPluginObject.so
Copiar la especificación del objeto MIB en el directorio /usr/share/snmp/mibs
y ası́ acceder a él a través de su OID textual.
cp NET-SNMP-TUTORIAL.txt $NETSNMPDIR/share/snmp/mibs/
Este punto se debe realizar principalmente en la entidad SNMP que realizará las
consultas al objeto descrito por dicho módulo, es decir, en la estación de administración encargada de este agente. Para que pueda ser reconocido por el sistema es
necesario exportar el nuevo valor de la variable de entorno MIBS. Para sistemas
Linux la lı́nea de comandos requerida es la siguiente:
export MIBS=all
∴ dlmod nombre ruta
Esta directiva permite cargar el módulo MIB especificado mediante ruta (debe
incluir la ruta y el nombre completo) bajo el nombre especificado por NOMBRE.
dlmod nstAgentPluginObject ∼/snmp/dlmod/nstAgentPluginObject.so
56
5. Net-SNMP Open Source SNMP System
5.2.2.
Creación de Usuarios SNMPv3
Para activar un usuario descrito en el archivo de configuración snmpd.conf (directivas: rouser, rwuser y com2sec) se debe incluir una directiva createUser aunque no tenga
asignado ninguna contraseña. La sinopsis para esta directiva es la siguiente:
∴ createUser [-e engineid] username [md5|sha] authpassphrase [des|aes] [privpassphrase]
Para la autentificación se pueden usar los protocolos md5 o sha. En caso de privacidad las alternativas son: des y aes. Si no se especifica la clave de privacidad, se asume
que es la misma que para la autentificación. Los usuarios creados sólo serán usados
siempre y cuando sean agregados a las tablas de control de acceso vacm descritas mas
adelante.
Si se desea usar los protocolos sha para autentificación y/o des/aes para privacidad
se necesita la previa instalación de las librerı́as de OpenSSL. El tamaño mı́nimo de
caracteres aceptados es de 8 tanto para la clave de autentificación como para privacidad.
Por seguridad esta directiva debe ir en el archivo de configuración persistente ubicado en /var/net-snmp/snmpd.conf. La información que es leı́da desde este archivo es
eliminada (eliminando el repositorio del administrador de contraseñas 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 cambio
si la contraseña es robada si se puede tener acceso. Para localizar un usuario a través
de un determinado ID (engineID) (es comúnmente usada en snmptrapd.conf), se usa la
opción -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 necesario por el algoritmo (128 bits para todos los algoritmos soportados). En cambio las
claves maestras localizadas necesitan tener el largo requerido por el algoritmo de autentificación y no el largo requerido por los algoritmos de encriptación (md5: 16 bytes,
sha: 20 bytes).
57
5. Net-SNMP Open Source SNMP System
5.2.3.
Inicio del Agente SNMP
Una vez que configurado todo correctamente, es tiempo de iniciar la aplicación. Es
importante recordar que el objetivo de esta implementación es administrar remotamente
los servicios de telefonı́a IP en una central IP-PBX a través de su agente SNMP, por lo
que antes de iniciar sus servicios, es necesario configurar el subagente SNMP disponible
dentro de la aplicación Asterisk y tiene como función responder a consultas sobre los
servicios entregados por la aplicación. Una vez finalizado ese proceso, se puede dar
inicio a los servicios de ambas aplicaciones para establecer la conexión entre agente y
subagente SNMP a través del protocolo AgentX.
5.3.
Configuración para Receptor de Notificaciones SNMP
Si en la sección 5.2 se describieron las distintas posibilidades que ofrece el agente NetSNMP para el envı́o de notificación, esta sección aborda los aspectos de configuración
para la recepción de éstas notificaciones que forma parte de las principales funciones de
una estación de administración.
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 es
diferente, se hace uso de autentificación mediante nombre de seguridad y contraseña para
iniciar la comunicación con el proceso receptor de notificaciones. Entonces se requiere
incluir previamente en la base de datos de usuarios aquellos de los cuales está permitido
recibir notificaciones.
Generalmente, un usuario queda identificado mediante su nombre de seguridad y el
engineID del receptor de notificaciones. Para usar el resto de las aplicaciones incluı́das
en el paquete Net-SNMP (snmpget, snmpwalk...), éstas descubren el engineID remoto
e introducen en la base de datos de usuarios asociada a este engineID el nombre de
usuario, el engineID y la contraseña.
El mecanismo de informes para SNMPv3 opera con este principio. Cuando se envı́a
un informe mediante snmptrap se usa el engineID remoto, y la combinación de este valor
más el nombre de seguridad deben existir en la tabla de usuarios remota. El programa
snmptrap detectará el engineID remoto y creará un mensaje SNMPv3 adecuado para el
informe que se envı́a.
58
5. Net-SNMP Open Source SNMP System
Para el envı́o de traps SNMPv3 es diferente, ya que este tipo de notificación utiliza el
engineID del agente (quien envı́a el mensaje), en vez de la estación (aquel que recibe el
trap). Esto quiere decir que al crear usuarios en la estación receptora, se debe especificar
su engineID, teniendo ası́ un usuario por cada agente que se quiere recibir traps. El
proceso de creación será descrito en detalle en la sección 5.3.3.
5.3.2.
Demonio snmptrapd
La aplicación que permite la recepción de notificaciones es el demonio snmptrapd. Se
ejecuta como un servicio más del sistema requiriendo privilegios de superusuario para
manipularlo, 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 se
pueden agregar opciones para su configuración (ejecutar snmptrapd --help para una
descripción más precisa). Sin embargo esta configuración no se grabará para futuras
ejecuciones por lo que se recomienda hacerlo a través de su archivo de configuración
snmptrapd.conf. Para esta implementación se editó el archivo snmptrapd.conf ubicado
en el directorio $netsnmpdir/etc/snmp/.
El archivo snmptrapd.conf es especı́fico para el receptor, y contiene una serie de directivas que describen su comportamiento en diferente aspectos. Para esta implementación el receptor de notificaciones sólo tiene la función de registrar aquellas notificaciones
que recibe desde la central IP-PBX 3 usando el máximo nivel de seguridad permitido en
SNMPv3. A continuación se describen sólo aquellas directivas usadas y el resto de ellas
pueden ser revisadas en la documentación 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 versión usada y en las anteriores se debe especificar
el número de puerto al momento de usar el comando snmptrap o snmpniform por
el agente para enviar una notificación.
∴ doNotRetainNotificationLogs yes
Deshabilita el soporte para notification-log-mib. Normalmente el demonio
mantiene un registro de las notificaciones recibidas, que puede ser obtenido consultando las tablas nlmLogTable y nlmLogvariableTable.
doNotRetainNotificationLogs yes
59
5. Net-SNMP Open Source SNMP System
Control de Acceso
Desde la versión 5.3 es necesario definir reglas de seguridad para el envı́o de traps e
informes (y qué tipo de procesamiento es permitido). Se usa una extensión del modelo
VACM, descrita en la configuración del agente SNMP. Actualmente existen 3 tipos de
procesamientos que son especificados en la Tabla 5.2.
Tabla 5.2: Tipos de procesamientos para modelo VACM
Tipo
log
execute
net
Descripción
registra la notificación recibida en un archivo especificado, salida estándar
(o estándar de error), o vı́a syslog.
la notificación es enviada como argumento a una aplicación externa.
adelanta el mensaje a otro receptor de notificaciones.
En las siguientes directivas, types será una lista separada por una ’,’ de uno o
más tipos definidos en la Tabla 5.2. Comúnmente, se usa log, execute, net para cubrir
cualquier tipo de procesamiento, pero perfectamente se puede limitar a ciertos tipos de
procesamiento.
∴ authUser types [-s model] user [level [oid | -v view]]
Autoriza notificaciones SNMPv3 desde un usuario especificado para efectuar los
tipos de procesamiento listados. Por defecto, la estación aceptará consultas autentificadas (nivel de seguridad authNoPriv o authPriv). level es usado para definir
el nivel de seguridad usado(noauth, auth, priv). oid (o -v view) permite filtrar
aquellos objetos MIB que serán procesados.
nota: view está relacionada solo con el valor de snmpTrapOID de la notificación
de entrada y no a los datos de los varbinds adjuntados dentro de la notificación.
A continuación se define la regla de recepción que permite a la estación recibir
traps v3 desde la central IP-PBX 3, con un nivel de seguridad authPriv. Los traps
recibidos a través de este usuario pueden ser registrados o enviados a un programa
externo, pero no adelantados por la red a otra estación de administración.
authUser log,execute -s usm pc120encrypter priv
60
5. Net-SNMP Open Source SNMP System
Formato y Registro de Notificaciones
Mediante las siguientes directivas se puede modificar el formato a las notificaciones
recibidas en la estación. Puede usarse para especificar los campos y el orden de las
notificaciones que serán mostradas.
∴ format2 format
Especifica el formato usado para registrar notificaciones SNMPv2c. Cabe destacar
que SNMPv2c y SNMPv3 usan el mismo formato PDU SNMPv2.
∴ logOption string
Especifica el destino de los registros para los traps recibidos hacia la salida estándar,
estándar de error, un archivo especı́fico o vı́a syslog.
logOption s 0
La opción “s 0” indica que las notificaciones serán enviadas al demonio syslogd a
través del subsistema local0 [15]. Luego para que todos los registros de notificaciones sean redireccionados a la consola Linux tty1 es necesario editar el archivo
de configuración de este demonio (syslog.conf) agregando las siguientes lı́neas:
local0.*
/dev/tty1
∴ outputOption string
Especifica varias caracterı́sticas de como deben ser mostrados los oids y otros
valores.
outputOption s
Procesamiento de Notificaciones
En la sección anterior se mencionó que existen 3 alternativas para procesar una
notificación, de las cuales solo se considerará el caso de registrar dichos mensajes ya que
para esta implementación se cuenta con una sola estación de administración.
61
5. Net-SNMP Open Source SNMP System
∴ traphandle oid|default program [ARGS ...]
Invoca un programa especı́fico (con los argumentos dados) cuando se recibe una
notificación cuyo identificador es oid. Para notificaciones SNMPv2c y SNMPv3,
oid será comparado con el valor de snmpTrapOID tomado de la notificación. Para
un trap SNMPv1, tanto su valor genérico como el oid serán convertidos a un oid
equivalente (valor numérico) siguiendo el RFC 2576.
Tı́picamente, el oid tomado será el nombre (o oid numérico) del objeto notificationtype, y el programa será invocado para notificaciones que cumplan exactamente
con el valor de oid (no como subárbol). Sin embargo existe el soporte para comparar ramas del árbol mediante el sufijo ’*’. Por ejemplo un oid de .1.3.6.1.4.1* se
podrı́a efectuar el llamado a la aplicación para cualquier notificación que esté dentro de ese subárbol, incluyendo el valor exacto. En cambio un oid de .1.3.6.1.4.1.*
trabaja de la misma manera considerando sólo notificaciones que están bajo ese
subárbol. Si oid tiene el valor default el programa será invocado para cualquier
notificación.
Los detalles de la notificación son entregados a la aplicación por medio de la
entrada estándar. Siempre se usará el formato de notificación de SNMPv2c, si
tenemos traps SNMPv1 su formato será convertido mediante el RFC 2576 antes
de ser pasados al programa. El formato de entrada es como se indica en la Tabla
5.3.
Tabla 5.3: Formato de notificaciones para Net-SNMP
campos
hostname
ipaddress
varbinds
descripción
El nombre del host que envió la notificación, determinado por gethostbyaddr.
Dirección IP del host que envió la notificación.
Una lista de varbinds describiendo el contenido de la notificación, uno por lı́nea. El primer token de cada lı́nea (hasta el
primer espacio) es el oid del varbind, y el resto de la lı́nea
corresponde a su valor. El formato del varbind se controla mediante la directiva outputOption. El primer oid siempre deberı́a ser SNMPv2-MIB::sysUpTime.0, y el segundo SNMPv2MIB::snmpTrapOID.0. El resto de las lı́neas contiene un lista de
varbinds. Para traps SNMPv1, el oid final deberı́a ser SNMPv2MIB::snmpTrapEnterprise.0.
Una alternativa para el registro de notificaciones en el sitio Web de administración
es crear un script que registre las notificaciones de manera más sencilla, entendible por el administrador que no tiene gran conocimiento en el formato original.
Además este script almacena los mensajes según la fecha de recepción en un archivo historial que luego será leı́do y visualizado por el sitio Web.
62
5. Net-SNMP Open Source SNMP System
traphandle default /usr/local/rrdtool/trap.sh
∴ forward oid|default destination
Adelanta las notificaciones que cumplen con el oid especificado a otro receptor de
notificaciones ubicado en destination (dirección IP). La interpretación de oid
(y default) es el mismo que para la directiva traphandle.
5.3.3.
Creación de Usuarios SNMPv3
La creación de usuarios SNMPv3 en el demonio es idéntica a la configuración realizada en el agente. De igual forma, el uso recomendable de esta caracterı́stica es incluir las
directivas de creación de usuarios en el archivo /var/net-snmp/snmptrapd.conf, con
el fin de que no hayan archivos en el sistema que contengan los nombres de usuarios y
contraseñas en texto plano. Los usuarios serán aquellos a los que recibirán notificaciones
mediante el protocolo SNMPv3.
∴ createUser -e engineID username (md5|sha) authpassphrase [des|aes]
El uso de esta directiva es idéntico a su homónimo para el fichero de configuración
del agente, la única diferencia que para recibir traps SNMPv3 es necesario registrar
el engineID de cada agente que tendrá permitido enviar notificaciones.
Para obtener el engineID de un agente es necesario leer su archivo de configuración
persistente (/var/net-snmp/snmpd.conf). La última lı́nea contiene la información
en 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 registrar
al agente anteponiendo la opción -e tal como lo indica su formato.
createUser -e 0x80001f88043031303230333034303530313230 \
pc120encrypter MD5 snmpencrypted DES snmpencrypted
63
Capı́tulo 6
Asterisk
Open Source IP-PBX System
Asterisk es un software de fuente abierta de un Voice Over IP PBX (IP-PBX) inicialmente creado por la empresa digium que proporciona los servicios, caracterı́sticas y
funciones de una PBX tradicional, y funciona sobre el Sistema Operativo Linux. Asterisk implementa Voz sobre IP en varios protocolos y puede interactuar con equipos de
telefonı́a PSTN estándar básicas usando un hardware de fácil instalación y configuración.
Asterisk adicionalmente provee servicios de voicemail con directorios, conferencias,
respuesta de voz interactivo IVR, llamadas en espera. Tiene el soporte de tres tipos de
formas de llamadas: servicios de llamada con identificación, ADSI, SIP y H323.
Asterisk apoya una amplia gama de protocolos TDM para el manejo y transmisión
de interfaces de telefonı́a tradicional. Asterisk apoya el tipo de señalización estándar
americano y europeo, permitiendo ser un nexo entre las redes integradas de datos de
voz de siguiente generación y la infraestructura existente. Asterisk no sólo soporta a
los equipos de telefonı́a tradicionales sino que también los habilita con capacidades
adicionales.
Asterisk provee una base central de conmutación, con 4 APIs para la carga modular de los usos de telefonı́a, interfaces del hardware, dirección del formato del archivo
y CODECs, permite la conmutación transparente de todas las interfaces soportadas,
permitiendo que enlacen una diversidad de combinaciones de sistemas de telefonı́a en
una sola red.
Asterisk fue originalmente escrito por Mark Spencer de DIGIUM, Inc. Los códigos
fueron la contribución de algunas fuentes abiertas de todo el mundo y probando algunos
bug-patches de la comunidad, ha provisto importante ayuda para el desarrollo de este
software.
64
6. Asterisk Open Source VoIP PBX System
Debido a que en la pagina oficial de Asterisk, http : //www.asterisk.org, se encuentran
todos los manuales para la configuración e implementación del software como Central
Telefónica IP, en este capı́tulo no se van detallar estos pasos, describiendo sólo las etapas
necesarias para la instalación y configuración de la aplicación integrada con el módulo
snmp necesario para esta implementación.
6.1.
Instalación de Asterisk
En el sitio oficial de Asterisk se pueden encontrar los paquetes con los archivos
ejecutables para ciertos sistemas operativos o si se desea también está disponible el
código fuente de esta aplicación.
Debido a que este proyecto integra los servicios de telefonı́a IP y SNMP, es necesario
utilizar una versión de asterisk que permita este desarrollo. El módulo SNMP de asterisk
está disponible desde su versión 1.4, de la cual solo se puede acceder mediante su código
fuente. Se recomienda leer los archivos de ayuda incluı́dos en el paquete descargado, y
ası́ entender mejor los pasos que se describen a continuación:
Descargar la aplicación y luego descomprimirla en un directorio cualquiera. En
este caso, se utilizó su versión estable 1.4.4 dado que tiene integrada el módulo
que permite actuar como subagente SNMP permitiendo ası́ una comunicación a
través del protocolo AgentX con el agente configurado en la sección 5.2.
Entrar en el directorio creado, y ejecutar el script de configuración configure, el
cual chequeará nuestro sistema en busca de bibliotecas y paquetes que necesita
el sistema para compilar el código. Además, permite incluir una serie de opciones
de compilación que servirá para activar ciertas caracterı́sticas necesarias para la
implementación. 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 módulo SNMP que permite actuar como
un subagente integrando el servicio de telefonı́a IP al sistema de administración
remota, y especificar la ruta en donde será instalada la aplicación. Definir la ruta
de instalación permite mantener un orden de la ubicación de los directorios y
ası́ facilitar a futuro su proceso de desinstalación. La siguiente lı́nea de comandos
permite obtener la lista completa de las opciones disponibles en el script:
./configure --help
65
6. Asterisk Open Source VoIP PBX System
Compilar la aplicación para obtener los archivos ejecutables que serán usados en
el proceso de instalación.
make
EL último paso es instalar los archivos ejecutables obtenidos en la ruta especificada, ejecutando como superusuario (root) la siguiente lı́nea de comandos:
make install
Finalmente se obtiene un conjunto de directorios que contienen las aplicaciones
y archivos de configuración para Asterisk. Su ubicación va a depender de la ruta
especificada al ejecutar el script configure mediante la opción --prefix. Desde este
momento la variable $asteriskdir describe la ruta de instalación de Asterisk, y
que para esta implementación fue definida en /usr/local/asterisk.
Cabe destacar que durante el proceso de instalación de Asterisk sus archivos de
configuración no son creados por defecto en el directorio /etc/asterisk, y permiten
definir las distintas capacidades según a la realidad del servicio que se quiere prestar.
La alternativa más simple y rápida es ejecutar dentro del directorio fuente de Asterisk
el script make samples para copiar los archivos de configuración que vienen por defecto
con la aplicación.
El módulo de SNMP es cargado correctamente siempre y cuando obtenga del sistema las librerı́as de Net-SNMP, para esto es necesario describirle la dirección en donde
residen. Por defecto Asterisk lee del directorio /usr/lib, pero dado que Net-SNMP fue
instalado mediante código fuente su ubicación es otra. Entonces una solución simple
es crear ligas hacia su actual ubicación ($netsnmpdir/lib). El comando Linux para
realizar este tipo de operación es ln. A continuación se indican las lı́neas de comandos
que deben ser ejecutadas como root y en el directorio /usr/lib para las cuatro librerı́as
requeridas por Asterisk.
ln
ln
ln
ln
-s
-s
-s
-s
$netsnmpdir/lib/libnetsnmpmibs.so.14 libnetsnmpmibs.so.14
$netsnmpdir/lib/libnetsnmpagent.so.14 libnetsnmpagent.so.14
$netsnmpdir/lib/libnetsnmphelpers.so.14 libnetsnmphelpers.so.14
$netsnmpdir/lib/libnetsnmp.so.14 libnetsnmp.so.14
66
6. Asterisk Open Source VoIP PBX System
6.2.
Configuración del Subagente SNMP
Las funciones de Asterisk sobre SNMP, pueden ser realizadas como agente o subagente, en donde este último permite comunicarse con un agente maestro a través del
protocolo AgentX. Los objetos MIB que tiene disponible son especı́ficos para el servicio
que entrega la central IP-PBX, no integrando otros servicio que pueden ser de interés
ası́ como tráfico, estado del hardware, etc. Los objetivos de esta implementación hacen
necesaria su configuración como subagente SNMP y ası́ cuando la estación consulte sobre el servicio de telefonı́a IP sea éste el que responda a través del agente. Para definir
este comportamiento es necesario editar el archivo de configuración descomentando las
lı́neas dentro de la sección general, como lo indica el siguiente ejemplo:
[general]
subagent yes
enabled yes
El siguiente paso es configurar el conjunto de reglas que permitirán la integración
con las centrales IP-PBX 1 y 2 disponibles en el Departamento de Electrónica. Para ello
las siguientes secciones describen en detalle los archivos de configuración que cumplen
esta función.
6.2.1.
Usuarios SIP
La red existente tiene la propiedad de comunicar a los usuarios a través del protocolo
de señalización sip. Entonces para agregar la central IP-PBX 3 es necesario que sus
usuarios registrados cumplan con el mismo protocolo.
Los usuarios sip deben ser creados en el archivo de configuración sip.conf, en donde es
posible determinar un sin fin de caracterı́sticas que permitirán un mejor uso del servicio.
En este archivo se debe especificar tanto los segmentos de red internos como las
direcciones IPs que son permitidas para registrarse en el sistema. Además de puede
especificar los codec soportados por el sistema y el contexto en el cual se procesan
las llamadas SIP. Este contexto permite agrupar las llamadas en grupos, para aplicarles
ciertas caracterı́sticas o servicios, ası́ también se puede especificar y ordenar las llamadas
provenientes de distintos lugares. A continuación se describe la configuración usada para
esta implementación:
67
6. Asterisk Open Source VoIP PBX System
[general]
port = 5060; puerto por el cual se~
naliza SIP
bindaddr = 192.168.28.120; dirección del servidor de registro
disallow = all; se deshabilitan todos los codecs
allow = ulaw; se permite el codec ulaw
allow = alaw; se permite el codec alaw
context = atmlab; contexto por el cual se envı́an las llamadas
SIP conocidas
[802]
type=friend; peer|user|friend: tipo de usuario SIP.
secret=802; contrase~
na del usuario.
username=802; medio de autentificación para cliente SIP.
host=dynamic; dominio o nombre para el servidor SIP.
context=from-internal; nombre del contexto para llamadas de
entrada y salida.
nat=no;
canreinvite=no;
[prueba]
type=peer;
host=192.168.28.125;
context=from-internal;
El usuario prueba permite establecer una conexión con la central IP-PBX 2 cuya
dirección IP es 192.168.28.125, y ası́ intercambiar llamadas con sus usuarios registrados.
De manera similar se creó un usuario sip en la central IP-PBX 2 también de tipo peer
para atender llamados desde esta central [14]. Por otra parte, el usuario 802 representa
un cliente que puede hacer o recibir llamadas de otros usuarios registrados.
6.2.2.
Creación del Dialplan
El archivo extensions.conf contiene el dialplan de Asterisk, conocido como el plan
maestro de control para todas sus operaciones. Define como serán manejadas y enrutadas
las llamadas de entrada y salida, es decir, se define el comportamiento de todas las
conexiones a través de la central IP-PBX.
El siguiente paso es crear las extensiones sip necesarias para permitir la comunicación
entre las centrales IP-PBX 2 y 3, y además entre los usuarios internos registrados.
68
6. Asterisk Open Source VoIP PBX System
[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;
Después de la categorı́a [general], el resto del archivo contiene la definición del
Dialplan. En este caso se definen 3 contextos de los cuales from-internal incluye el
conjunto de extensiones de ruta y ext-local. El contexto ruta define que toda llamada
de entrada dirigida a un anexo de 3 dı́gitos que empiece con 9, será redirigida a la central
IP-PBX 2. En cambio el contexto ext-local define que toda llamada de entrada dirigida
a un anexo de 3 dı́gitos que empiece con 8, será contestada por un usuario interno.
En ambos contextos si la comunicación falla entonces el usuario será conectado a una
operadora que le indicará que la llamada no se pudo establecer.
6.2.3.
Asterisk CLI
Asterisk en su instalación incluye una interfaz de comando llamada CLI (Command
line Interface), la cual permite manejar la central en forma completa y hacer debugging
del sistema por linea de comando. Para acceder a CLI se debe ejecutar la siguiente lı́nea
de comandos:
69
6. Asterisk Open Source VoIP PBX System
[root@BIONICO ∼]# asterisk -r
Asterisk 1.4.4, Copyright (C) 1999 - 2006 Digium, Inc. and
others.
Created by Mark Spencer <marksterdigium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type ’core show
warranty’ for details.
This is free software, with components licensed under the GNU
General Public
License version 2 and other licenses; you are welcome to
redistribute it under
certain conditions. Type ’core show license’ for details.
=========================================================================
== Parsing ’/etc/asterisk/asterisk.conf’: Found
== Parsing ’/etc/asterisk/extconfig.conf’: Found
Connected to Asterisk 1.4.4 currently running on BIONICO-Server
(pid = 7076)
Verbosity was 0 and is now 3
pbx-BIONICO*CLI
Dos ejemplos de comando de CLI son:
1. sip show users: muestra desde la base de datos del sistema la información de
los usuarios registrados, incluyendo anexo, clave de registro y contexto para sus
llamadas.
2. sip show settings: especifica todas las configuraciones que están funcionando
actualmente en el sistema.
El resultado obtenido al ejecutar estos dos comandos es el siguiente:
pbx-BIONICO*CLI sip show users
Username
802
Secret
802
Accountcode
Def.Context
from-internal
70
ACL
No
NAT
RFC3581
6. Asterisk Open Source VoIP PBX System
pbx-BIONICO*CLI sip show settings
Global Signalling Settings:
--------------------------Codecs:
Codec Order:
T1 minimum:
Relax DTMF:
Compact SIP headers:
RTP Keepalive:
RTP Timeout:
RTP Hold Timeout:
MWI NOTIFY mime type:
DNS SRV lookup:
Pedantic SIP support:
Reg. min duration
Reg. max duration:
Reg. default duration:
Outbound reg. timeout:
Outbound reg. attempts:
Notify ringing state:
Notify hold state:
SIP Transfer mode:
Max Call Bitrate:
Auto-Framing:
0xc (ulaw|alaw)
ulaw:20,alaw:20
100
No
No
0 (Disabled)
0 (Disabled)
0 (Disabled)
application/simple-message-summary
No
No
60 secs
3600 secs
120 secs
20 secs
0
Yes
No
open
384 kbps
No
Default Settings:
----------------Context:
Nat:
DTMF:
Qualify:
Use ClientCode:
Progress inband:
Language:
MOH Interpret:
MOH Suggest:
Voice Mail Extension:
from-internal
RFC3581
rfc2833
0
No
Never
(Defaults to English)
default
asterisk
71
6. Asterisk Open Source VoIP PBX System
6.2.4.
Softphone X-lite
Para efectuar pruebas de comunicación entre clientes dentro de la red IP, se utiliza el
softphone X-lite, la versión libre de la empresa CounterPath y que puede ser instalada
en los sistemas operativos Windows, Mac OSX y Linux.
En la opción Configuración Avanzada, se debe ingresar el sip proxy y los parámetros de
usuario para su registro en el servidor, como se puede apreciar en la Figura 6.2.4, donde
se ha configurado al usuario cuyo anexo es el 802 y pertenece al servidor de registro
configurado previamente cuya dirección IP.es 192.168.28.120.
Figura 6.1: X-lite, configuración de parámetros SIP
La ventana mostrada en la Figura 6.2.4 se encuentra en Menú → System Setting →
Sip Proxy, de las opciones del softphone. Una vez aceptado los cambios, en la ventana
principal del softphone aparecerá un mensaje de registrado, tal como se puede apreciar
en la Figura 6.2.4.
Figura 6.2: X-lite, Ventana principal
72
6. Asterisk Open Source VoIP PBX System
6.2.5.
Iniciación de Servicios
Una vez finalizado el proceso de configuración tanto para la aplicación Asterisk como
para el agente Net-SNMP, se puede dar comienzo a dichas aplicaciones. Cabe destacar
que existe un cierto orden de ejecución entre los servicios de administración y de telefonı́a IP, para establecer la conexión vı́a protocolo AgentX entre maestro y subagente.
Los pasos que se listan a continuación fueron efectuados en un sistema Linux como
Debian Etch, y deben ser respetados en el mismo orden como se encuentran:
Detener el servicio de Telefonı́a IP a través de su demonio asterisk, sólo si previamente fue iniciado.
[root@BIONICO ∼]# /etc/init.d/asterisk stop
Detener el agente Net-SNMP a través de su demonio snmpd, sólo si previamente
fue iniciado.
[root@BIONICO ∼]# /etc/init.d/snmpd stop
Iniciar la aplicación 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 estén funcionando correctamente. Un camino simple serı́a comprobar que el proceso correspondiente para cada
aplicación esté activo, para ello se hace uso del comando Linux ps, dando el siguiente
resultado:
[root@BIONICO ∼]# ps -C asterisk
PID TTY TIME CMD
3024 ? 00:00:09 asterisk
[root@BIONICO ∼]# ps -C snmpd
PID TTY TIME CMD
2750 ? 00:01:20 snmpd
nota: En caso que no se obtenga respuesta es porque se generaron fallas en su ejecución
y fueron canceladas. Para revisar cuales son las causas del problema es recomendable
leer el archivo de registros que tiene cada aplicación.
Finalmente se recomienda comprobar que la conexión entre agente y subagente
SNMP se haya establecido. En el archivo de registros de Net-SNMP se muestra el
73
6. Asterisk Open Source VoIP PBX System
estado de la conexión AgentX cada vez que la aplicación es iniciada.
[root@BIONICO ∼]# cat /var/log/snmpd.log
Turning on AgentX master support.
NET-SNMP versión 5.4.1.pre1
En secciones anteriores se hizo incapié que tanto Asterisk como Net-SNMP no tienen
la posibilidad de ser iniciados como servicios del sistema. En el caso de Asterisk contiene
un script que puede ser ejecutado sólo en distribuciones RedHat para Linux, pero para
el resto no es aplicable. Para dar simpleza al control de estas aplicaciones fue necesario
registrar los demonios snmpd, snmptrapd y asterisk como servicios del sistema1 .
1
Apéndice A: Servicios para Linux: asterisk, snmpd y snmptrapd
74
Capı́tulo 7
Resultados y Conclusión
7.1.
Resultados
La integración de un sistema de administración remota a través de Net-SNMP y
una red de telefonı́a IP servida por 3 IP PBX Asterisk propuesta en los objetivos da
como resultado el esquema de red que representa la Figura 7.1.
Figura 7.1: Esquema Final de un Sistema de Administración para una Red de Telefonı́a IP
75
7. Resultados y Conclusión
La red construida permite dar servicios de telefonı́a IP a todo el Departamento de
Electrónica a través de las centrales IP-PBX 1 y 2. Como resultado de este proyecto
se integró un tercer servidor de prueba para estudiar la posibilidad de implementar un
sistema de administración remota SNMP. La central IP-PBX 3 es monitoreada por la
estación de administración NMS-ELO01 sobre un conjunto de servicios como tráfico,
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 configuración de las IP PBX y el servidor de
administración SNMP. Además se definen las reglas de marcado usadas para acceder a
los distintos tipos de anexos, dependiendo de la ubicación en que se encuentren.
Tabla 7.1: Resumen de Configuraciones para IP-PBX 2
Nombre:
Dirección IP:
LAN interna:
Rango de Anexos:
Anexos de Prueba:
Puerto FXO:
Puerto FXS:
Asterisk ip-pbx 2
ippbx-pstn
192.168.28.0/24
192.168.28.125
4900 a 4999
200, 900
Anexo UTFSM 4093
Anexo ZAP 4910
reglas de marcado
? Para acceder a clientes registrados en IP-PBX 1 marcar un anexo entre 4800 y
4899, por ejemplo 4804.
? Para acceder a clientes internos en IP-PBX 2 marcar un anexo entre 4900 y
4999, por ejemplo 4910.
? Para acceder a clientes registrados en IP-PBX 3 marcar un anexo entre 800 y
899, por ejemplo 802.
? Para acceder a clientes internos UTFSM marcar el anexo correspondiente, por
ejemplo 4759.
? Para acceder a clientes internos a la PSTN anteponer “0” para acceder al troncal
FXO y “9” para que la central permita la salida hacia la PSTN, luego se debe
marcar el número al que se desea llamar, por ejemplo 0-9-833004.
76
7. Resultados y Conclusión
Tabla 7.2: Resumen de Configuraciones para IP-PBX 3
Nombre:
Dirección IP:
LAN interna:
Rango de Anexos:
Usuario SNMPv3:
Monitor DisMan:
Asterisk ip-pbx 3
ippbx-snmp
192.168.28.0/24
192.168.28.120
800 a 802
pc120encrypter
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, por
ejemplo 802.
? El subagente SNMP en Asterisk está conectado a su agente maestro a través del
protocolo AgentX en el socket var/agentx/master con permisos para el usuario
root 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 éste las adelanta a la
estación nms-elo01.
? El agente maestro monitorea cada 5 min. por posibles fallas en el servicio
asterisk mediante el usuario root. Una vez encontrada una anormalidad se envı́a
una notificación a la estación nms-elo01 para que tenga constancia del hecho.
Tabla 7.3: Resumen de Configuraciones para NMS-ELO01
Nombre:
Dirección IP:
LAN interna:
Consultas a:
Notificaciones de:
Estación nms-elo01
pcmag21
192.168.28.0/24
192.168.28.101
ip-pbx 3
ip-pbx 3
reglas de SNMP
? La estación solo recibe traps SNMPv3 desde usuarios registrados y que pertenecen a la red 192.168.28.0/24. En este caso el único usuario registrado es
pc120encrypter 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 gráficos de estadı́sticas para ciertos servicios de ip-pbx 3
se hacen consultas SNMPv3 a través del usuario pc120encrypter registrado por
el agente SNMP.
77
7. Resultados y Conclusión
7.1.2.
Estadı́sticas en IP-PBX 3 a través de SNMP
Los beneficios del protocolo SNMP, es que se pueden hacer consultas remotas con
el fin de generar estadı́sticas sobre servicios de interés, todo dependiendo del tipo de
equipo que se está administrando. En este caso se refiere a una central IP-PBX, por lo
que los principales aspectos a analizar tienen relación con el estado de su hardware y
a los servicios de comunicación entregados. Estos aspectos se relacionan directamente
con cierto objetos MIB los cuales son descritos en detalle en la Tabla 7.4.
Tabla 7.4: Descripción del Plan de Monitoreo
Servicios
análisis de
Tráfico Ethernet
Uso de Canales Asterisk
tabla mib
inEntry
asteriskChannels
objetos
ifInOctets.2, ifOutOctets.2
astNumChannels.0,
astChanTypeChannels.1-9
Hardware
análisis de
Temperatura
Carga Promedio
Memoria en Uso
tabla mib
lmTempSensors
laTable
memory
objetos
lmTempSensorsValue.1-3
laLoadInt.1-3
memTotalSwap, memTotalReal,
memAvailSwap, memAvailReal,
Buffer, Cached.
En la actualidad existen muchas herramientas para la generación de gráficos en
tiempo 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 (ancho
de banda, temperatura, etc.). La forma en que almacena los datos es a través de una base
de datos que no crece en el tiempo, aún cuando se pueden guardar valores históricos
(mensuales, anuales, etc) para luego generar gráficos y conocer el comportamiento a
largo plazo de un determinado servicio.
A continuación se hace una descripción de los resultados obtenidos por servicio
monitoreado en la central IP-PBX 3 para un periodo de 4 horas, almacenando muestras
cada 5 min mediante consultas SNMPv3 desde NMS-ELO01.
78
7. Resultados y Conclusión
Tráfico Ethernet
La Figura 7.2 muestra el comportamiento del ancho de banda de entrada y salida
medido en bytes/sec a la interfaz de red eth0 de la central IP-PBX 3, cuya dirección
IP es 192.168.28.120. Esta información se obtiene midiendo el cambio temporal de la
cantidad total de bytes de entrada y salida consultada de los objetos MIB ifInOctets.2
y ifOutOctets.2, respectivamente.
Figura 7.2: Análisis de Tráfico Ethernet para IP-PBX 3
Cabe destacar que RRDTools, permite obtener datos de relevancia, ası́ como el valor
actual, máximo y promedio de la medición realizada durante el periodo de tiempo que
está considerando. A demás tiene muchas opciones que facilitan el análisis posterior de
las estadı́sticas realizadas.
Uso de Canales Asterisk
El análisis propuesto para esta etapa consiste en medir el número total de canales
activos que tiene Asterisk en un tiempo determinado. Para ello el MIB integrado a
Asterisk contiene información esencial sobre el uso de los diferentes tipo de canal disponibles. Por una parte el objeto MIB astNumChannels.0 permite conocer el número
total de canales en uso (vista general), en cambio del objeto astChanTypeChannels.1
al astChanTypeChannels.9 se entrega el detalle para cada tipo de canal. La Tabla 7.5
describe los 9 tipos de canal que Asterisk dispone, aunque cabe destacar que para esta
implementación sólo se dispone del canal SIP.
79
7. Resultados y Conclusión
Tabla 7.5: Tipos de canales disponibles en Asterisk
canal
Agent
Skinny
Console
Phone
IAX2
Feature
Local
SIP
MGCP
descripción
Call Agent Proxy Channel
Skinny Client Control Protocol (Skinny)
OSS Console Channel Driver
Standard Linux Telephony API Driver
Inter Asterisk eXchange Driver (Ver 2)
Feature Proxy Channel Driver
Local Proxy Channel Driver
Session Initiation Protocol (SIP)
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 dichas
mediciones. Estos dos protocolos de señalización son simples en cuanto a arquitectura
fı́sica, pueden ser probados a través de softphones que para este caso se realizaron
llamadas entre usuarios registrados en las centrales IP-PBX 2 y 3.
Figura 7.3: Análisis 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 en
porcentaje y corresponde a valores promedios: 1, 5 y 10 min, de los cuales son obtenidos
a través de los objetos MIB laLoadInt.1, laLoadInt.2 y laLoadInt.3 respectivamente, y
se representan en la Figura 7.4.
80
7. Resultados y Conclusión
Figura 7.4: Análisis de Carga Promedio en CPU para IP-PBX 3
Otra caracterı́stica medible desde la CPU es su temperatura, para ello fue necesario
cargar dinámicamente el módulo MIB lm-sensors que contiene toda la información
necesaria además de otras que fueron usadas pero que no serán detalladas en este documento. Además de la CPU también es posible medir la temperatura de la placa madre,
la cual también fue agregada al análisis. De esta manera los objetos MIB lmTempSensorsValue.1 y lmTempSensorsValue.2 contienen los valores de temperatura de la placa
madre y CPU respectivamente, tal como muestra en la Figura 7.5.
Figura 7.5: Análisis de Temperatura para IP-PBX 3
81
7. Resultados y Conclusión
Uso de Memoria
La memoria en uso se refiere a la memoria fı́sica que puede estar siendo ocupada en
diversas funciones. En este análisis se pretende considerar los usos más generales, entre
los cuales están: uso real, buffers, caché, y memoria swap. la Tabla 7.6 describe aquellos
objetos MIB necesarios para dicho análisis.
Tabla 7.6: Objetos MIB para análisis de memoria en uso
objeto
memTotalReal
memAvailReal
memBuffer
memCached
memTotalSwap
memAvailSwap
descripción
Total de memoria real/fı́sica en el equipo.
Memoria real/fı́sica disponible actualmente.
Memoria real o virtual usada actualmente para buffers.
Memoria real o virtual usada actualmente como memoria caché.
Total de memoria swap configurada en el equipo.
Memoria swap disponible actualmente.
La Figura 7.6 describe el uso de memoria fı́sica del servidor, considerando solo
aquellos que tienen mayor importancia a la hora de generarse fallas.
Figura 7.6: Análisis de Memoria en Uso para IP-PBX 3
82
7. Resultados y Conclusión
7.1.3.
Reconocimiento de Fallas en Central IP-PBX 3
En el capı́tulo 5 se describió la configuración realizada al agente y la estación SNMP,
en donde se determinaron las reglas de envı́o y recepción de notificación. En esta sección
se entregarán los resultados obtenidos sobre las pruebas realizadas a dichas configuraciones, las cuales tienen como objetivo informar a la estación NMS-ELO01 en caso de
una determinada falla y sólo procesarlas a través de registros.
En el archivo de configuración del agente snmpd.conf se indicaron las reglas de
monitoreo DisMan, las cuales consistı́an en analizar 4 aspectos fundamentales en base
a sus respectivos objetos MIB, descritos en la Tabla 5.1.
El agente SNMP en la central IP-PBX 3 periódicamente realiza el análisis de las
reglas monitor de su archivo de configuración, el cual puede ser observado a través de su
modo depuración (snmpd -Lo -f -Ddisman) cuando éste es iniciado. A continuación se
muestra la salida estándar obtenida para un ciclo de tiempo en que realiza dicho análisis.
disman:event:trigger:monitor: Running trigger
disman:event:delta: Bool comparison: (0 != 0)
disman:event:trigger:monitor: Running trigger
disman:event:delta: Bool comparison: (0 != 0)
disman:event:delta: Bool comparison: (0 != 0)
disman:event:delta: Bool comparison: (0 != 0)
disman:event:trigger:monitor: Running trigger
disman:event:trigger:monitor: Running trigger
(memory)
0
(laTable)
0
0
0
(lmtempmotherboard)
(lmtempcpu)
Con el fin de informar sobre los datos obtenidos por la estación debido a un incumplimiento de las reglas monitor en el agente SNMP, se describirá el caso en que
se genera una notificación por una falla de autentificación en una consulta realizada a
dicho agente.
Fallas de Autentificación
En el caso que la central IP-PBX 3 es consultada con un usuario SNMPv3 incorrecto, ya sea nombre de seguridad o contraseña, entonces el agente inmediatamente da
aviso a la estación NMS-ELO01 que hubo una falla de autentificación a través de una
notificación de tipo trapv3. A continuación se describe la consulta errónea que activa la
regla authtrapenable 1 definida en el archivo de configuración del agente.
snmpwalk -v 3 -u pc120encrypter -l authpriv -a MD5 -A snmpencrypte \
-x DES -X snmpencrypted 192.168.28.120 sysDescr.0
83
7. Resultados y Conclusión
Luego el trap recibido por la estación adjunta el objeto MIB snmpTrapOID.0 cuyo valor es authenticationFailure de esta manera le indica que el agente recibió una
consulta con identificación fallida adjuntándole información de tiempo para conocer el
momento en que ocurrió (sysUpTimeInstance). Esto se puede apreciar a través del demonio snmptrapd ejecutándolo en modo depuración (snmptrapd -Lo -Ddumph recv,
dumpv recv) como se muestra en el siguiente cuadro:
dumph_recv: SNMPv3 Message
dumph_recv:
SNMP Versión Number
Integer:
3 (0x03)
dumph_recv:
msgGlobalData
dumph_recv:
msgID
Integer:
1566513010 (0x5D5F1772)
dumph_recv:
msgMaxSize
Integer: 65507 (0xFFE3)
dumph_recv:
msgFlags
String:
.
dumph_recv:
msgSecurityModel
Integer:
3 (0x03)
dumph_recv:
SM msgSecurityParameters
dumph_recv:
msgAuthoritativeEngineID
String:
.....01020304050120
dumph_recv:
msgAuthoritativeEngineBoots
Integer: 180 (0xB4)
dumph_recv:
msgAuthoritativeEngineTime
Integer: 57859 (0xE203)
dumph_recv:
msgUserName
String: pc120encrypter
dumph_recv:
msgAuthenticationParameters
String: ..S4.Tc.M...
dumph_recv:
msgPrivacyParameters
String: ....Iv&.
dumph_recv:
ScopedPDU
dumph_recv:
contextEngineID
String:
.....01020304050120
dumph_recv:
contextName
String:
dumph_recv:
TRAP2
dumpv_recv:
Command TRAP2
dumph_recv:
request_id
Integer:
1050224183 (0x3E992637)
dumph_recv:
error status
Integer:
0 (0x00)
dumph_recv:
error index
Integer:
0 (0x00)
dumph_recv:
VarBindList
dumph_recv:
VarBind
dumph_recv:
Name
ObjID: sysUpTimeInstance
dumph_recv:
Value
UInteger:
5785301 (0x5846D5)
dumph_recv:
VarBind
dumph_recv:
Name
ObjID: snmpTrapOID.0
dumph_recv:
Value
ObjID: authenticationFailure
dumph_recv:
VarBind
dumph_recv:
Name
ObjID: snmpTrapEnterprise.0
dumph_recv:
Value
ObjID: netSnmpAgentOIDs.10
2007-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
7. Resultados y Conclusión
Según la configuración realizada para el agente, en su directiva trapsses las notificaciones enviadas corresponden a trap v3 cuyo nivel de seguridad es authPriv. Para
comprobar que la información transmitida es encriptada tal como se configuró fue necesario el uso de una herramienta para captura de paquetes de red como ethereal, y
basado en el ejemplo anterior el mensaje capturado contiene la siguiente información
SNMP:
No. Time
Source
Destination
Protocol
4
3.777434 192.168.28.101 192.168.28.120 SNMP
Simple Network Management Protocol
msgVersion: snmpv3 (3)
msgGlobalData
msgID: 634424755
msgMaxSize: 65507
msgFlags: 07
.... .1.. = Reportable: Set
.... ..1. = Encrypted: Set
.... ...1 = Authenticated: Set
msgSecurityModel: USM (3)
msgAuthoritativeEngineID: 80001F88043031303230333034303530313230
1... .... = Engine ID Conformance: RFC3411 (SNMPv3)
Engine Enterprise ID: net-snmp (8072)
Engine ID Format: Text, administratively assigned (4)
Engine ID Data: Text: 01020304050120
msgAuthoritativeEngineBoots: 12
msgAuthoritativeEngineTime: 31
msgUserName: pc120encrypter
msgAuthenticationParameters: 16E6060274B74E7017678552
msgPrivacyParameters: 00000081938D271C
msgData: encryptedPDU (1)
encryptedPDU: A17CC66CBB00C9F363FF2B2D5E8447AFFA0AB92E5A0A6D25...
0030
0040
0050
0060
0070
0080
0090
00a0
00b0
00c0
30
02
30
01
65
04
bb
5a
56
8f
11
01
32
1f
72
08
00
0a
93
ec
02
03
30
04
04
00
c9
6d
a2
dc
04
04
33
0e
0c
00
f3
25
fd
80
25
45
30
70
16
00
63
74
bf
d0
30
34
63
e6
81
ff
b4
17
8d
43
30
31
06
93
2b
20
99
b3
04
35
32
02
8d
2d
ec
44
02
13
30
30
74
27
5e
5f
bd
03
80
31
65
b7
1c
84
98
b9
00
00
32
6e
4e
04
47
d4
4a
85
ff
1f
30
63
70
38
af
5a
bb
e3
88
02
72
17
a1
fa
b5
52
04
04
01
79
67
7c
0a
e0
8c
01
30
0c
70
85
c6
b9
9d
bb
07
31
02
74
52
6c
2e
bd
d2
0...%...........
....E0C.......01
020304050120....
....pc120encrypt
er......t.Np.g.R
........’..8.|.l
....c.+-^.G.....
Z.m%t. ._..Z....
V......D..J.R...
....
7. Resultados y Conclusión
Lo anterior indica que los datos son enviados en el nivel más alto de seguridad, manteniendo en secreto información vital acerca de fallas en el sistema, lo cual es importante
en casos que se quieran adjuntar otros objetos MIB en la notificación ası́ como valores
de configuración del servidor. Además los valores de autentificación que son enviados
en texto plano sólo corresponden a datos básicos, es decir, su engineID y nombre de
seguridad, en cambio el resto de la información como la contraseña es adjuntada en el
paquete de datos encriptado.
Finalmente el sistema de reconocimiento de fallas integrado en el sitio Web de administración permite visualizar las últimas 10 notificaciones recibidas por la estación
NMS-ELO01 desde sus agentes según la configuración realizada. Además se tiene disponible un archivo historial (snmptrapd.historial.log) con todas las notificaciones recibidas
en caso que el administrador lo requiera. La Figura 7.7 muestra un captura de pantalla
de la zona de notificaciones del sitio Web de administración desarrollado.
Figura 7.7: Zona de notificaciones en el sitio Web de administración
7.2.
Conclusiones
Una de los aspectos que motivó el desarrollo de esta implementación, fue integrar
un sistema seguro de administración utilizando todas las caracterı́sticas desarrolladas
en la versión 3 de SNMP, demostrando ası́ que es posible controlar un dispositivo que
dispone de servicios especı́ficos como en este caso telefonı́a IP. En lo que respecta a
estrategias de administración pensando en la utilización de la red se hizo uso del plan
de administración distribuida, que es un concepto basado en la combinación de los
métodos de obtención de información. En el caso de fallas en un equipo administrado
es su agente SNMP el que se encarga de la detección y no la estación de administración
dado que en este último caso existirı́a un gasto de la red por el intercambio sucesivo de
paquetes para reconocer el estado del equipo (pensado para una red de computadores
extensa). En cambio si lo que se desea es monitorear la red, entonces es necesaria la
86
7. Resultados y Conclusión
consulta periódica de ciertos objetos MIB por parte de la estación. En este proyecto cuya
finalidad era implementar un sistema sencillo de administrado basado en el monitoreo y
reconocimiento de fallas en una central IP-PBX, se utilizó una arquitectura centralizada
(una estación de administración) pero en casos en que se necesite administrar una gran
cantidad de equipos de red es necesario usar una arquitectura distribuida teniendo
varias estaciones que puedan ser controladas por un maestro y ası́ no provocar flujos
excesivos de paquetes SNMP viajando por la red además de los requerimientos sobre
procesamiento para la máquina que juega el rol de administrador.
7.2.1.
Sistema de Monitoreo
Uno de los aspectos más importantes en la administración es mantenerse informado
de la situación actual de los servicios que entrega una red. En este caso el objetivo
consistı́a en desarrollar estadı́sticas en tiempo real, sobre la situación de la IP-PBX de
prueba integrada a la red de telefonı́a IP.
Los ı́temes analizados para la IP-PBX forman parte de un conjunto de caracterı́sticas
que a un administrador le interesarı́a conocer. Se pudo demostrar que a través de SNMP
se puede monitorear un sin fin de caracterı́sticas, y a demás da seguridad por lo que
se convierte en la actualidad en una herramienta de interés. A pesar que el esquema
presentado es a baja escala permite considerar la capacidad de desarrollar un sistema
distribuido de administración pensando que en la industria de las telecomunicaciones
existen una gran diversidad de componentes de red ası́ como routers, UPS, etc.
Respecto a la intención de desarrollar un sistema de monitoreo sobre una gran
cantidad de componentes se recomienda desarrollar un esquema distribuido de estaciones
de administración, debido a la excesiva cantidad de paquetes SNMP circulando por la red
debido a las contantes consultas. De esta manera integrando más estaciones las cuales
se encargan de sectores diferentes de la red provocarı́a una disminución considerable lo
que para una red de voz es un aspecto fundamental.
7.2.2.
Sistema de Reconocimiento de Fallas
Diseñar un sistema en que es el propio agente el que se analiza y puede dar aviso a
una estación sobre alguna falla ocurrida, es una de las grandes facultades que tiene el
protocolo SNMPv3 aparte de la integración de niveles de seguridad para la protección
de los datos. Esto porque si fuera la estación la encargada de verificar fallas un equipo
generarı́a en grandes redes un mal uso del ancho de banda, debido al intercambio de
una gran cantidad de paquetes SNMP. Con el método DisMan se logra darle un mejor
uso al recurso, el cual es vital para servicios como telefonı́a IP en donde se requiere del
máximo posible.
87
7. Resultados y Conclusión
En cuando a la planificación de este sistema, se hubiese querido integrar la generación
de traps referidos a fallas en los servicios entregados por Asterisk, pero se encontraron
fallas en cuanto a la conexión entre maestro y subagente SNMP a la hora de iniciar los
procesos de análisis a través de las directivas monitor. Por ello es que se hizo incapié en
reconocer otro tipo de fallas y dejar como trabajo futuro la generación de notificaciones
relacionadas a los servicios de Asterisk a través de las directivas Event MIBl en la
configuración del agente.
7.2.3.
Desarrollo Futuro
El proyecto sobre administración remota de una red de telefonı́a IP desarrollado en
este documento plantea la implementación de una central IP-PBX de prueba integrada
a la red existente con la capacidad de comunicarse a través del protocolo SNMP y
ası́ ser monitoreada y controlada por una estación de administración. Luego de cumplir
con estos objetivos existen ciertos ı́temes en los cuales se puede seguir explorando e
investigando, desarrollando proyectos sobre la base de que el control sobre servicios IP
es factible y ya existe. A continuación se indican algunos aspectos en los que se puede
seguir desarrollando sobre lo ya realizado.
Integración de centrales IP-PBX a la red de administración remota. Este punto
se basa en desarrollar un plan de administración para este tipo de servicio el cual
está tomando gran envergadura en el Departamento de Electrónica en donde fue
desarrollado. Además se requiere actualizar el portal Web de administración para
tener acceso a la información de las nuevas centrales y equipos que se deseen
administrar.
Desarrollar implementaciones sobre otros tipos de dispositivos de red, ası́ como
routers que soporten el protocolo SNMPv3, y ası́ facilitar su administración ya
sea configuración y monitoreo.
Estudio sobre la posibilidad de integrar estrategias de monitoreo eficientes, y
ası́ evitar que la red se sature de paquetes SNMP provocando una disminución en
la calidad de servicios sobre todo si es una red de voz y video que se requiere de
su máxima capacidad.
88
Apéndice A
Servicios para Linux:
asterisk, snmpd y snmptrapd
Un servicio se refiere generalmente a un demonio del sistema, es decir, es un programa que permanece en segundo plano ejecutándose continuamente para dar algún tipo
de servicio. Ejemplos de demonio, son los servidores de correo, impresora, sistemas de
conexion con redes, etc.
Cada uno de ellos tiene un archivo asociado en /etc/init.d, el cual es un script
bash que acepta un argumento (podrı́a ser, al menos, ”start.o ”stop”, aunque pueden
ser otros complementarios para proveer al usuario de opciones adicionales, por ejemplo
restart”, ”status”...).
A.1.
Scripts de Inicio
Un script de inicio es creado para iniciar una aplicación en el caso del arranque
ası́ como también en caso de apagado instantáneo del sistema, o debido a un cambio
en el nivel de ejecución [19]. En todo sistema Linux, especı́ficamente en el directorio
/etc/init.d se encuentra el script skeleton que tiene la única función de describir la
estructura básica de un demonio. A la hora de crear scripts de inicio es aconsejable usar
este archivo como base, y comenzar a modificar aquellas lı́neas que requieren especificar
la aplicación que se quiere controlar.
A continuación se describen las funciones que forman parte de la estructura de un
script de inicio. Algunas de ellas son requeridas y otras sólo opcionales.
89
Apéndice A - Servicios para Linux
Funciones Requeridas
start():
Incluye lo que ocurrirá cuando el script arranque.
Funciones Opcionales
depend():
stop():
restart():
Se utiliza para determinar las dependencias del servicio, se
deben cumplir para que arranque el demonio (más abajo hay
un ejemplo)
Esto es lo que ocurrirá cuando se ordene que el servicio se
pare.
Esto es lo que se tiene que hacer para parar y volver a iniciar
el servicio.
A continuación se entregan simples scripts que permiten definir los tres servicios
para el sistema, correspondientes a las aplicaciones: asterisk, snmpd y snmptrapd.
90
Apéndice A - Servicios para Linux
Tabla A.1: Script para servicio Asterisk
#! /bin/sh
DAEMON=/usr/local/asterisk/sbin/asterisk
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
case "$1" in
start)
echo -n "Starting daemon: asterisk"
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -vvvvvvvvvv
echo "."
;;
stop)
echo -n "Stopping daemon: asterisk"
kill ‘cat $PIDFILE‘
echo "."
;;
restart|force-reload)
echo -n "Restarting daemon: asterisk"
kill ‘cat $PIDFILE‘
sleep 1
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -vvvvvvvvvv
echo "."
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
El script descrito en la Tabla A.1 permite iniciar el demonio asterisk con el nivel
máximo de depuración, y de esta manera cuando el administrador entre a su consola
podrá conocer los detalles de cada acción acontecida, a través del comando
“asterisk -r”.
91
Apéndice A - Servicios para Linux
Tabla A.2: Script para servicio snmpd
#! /bin/sh
NAME=snmpd
DAEMON=/usr/local/net-snmp/sbin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
case "$1" in
start)
echo -n "Starting daemon: $NAME"
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -f -Lf /var/log/snmpd.log
echo "."
;;
stop)
echo -n "Stopping daemon: $NAME"
kill ‘cat $PIDFILE‘
echo "."
;;
restart|force-reload)
echo -n "Restarting daemon: $NAME"
kill ‘cat $PIDFILE‘
sleep 1
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -f -Lf /var/log/snmpd.log
echo "."
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
La lı́nea de ejecución para el demonio snmpd definida en el script de la Tabla A.2
permite almacenar en un archivo de texto (/var/log/snmpd.log) todos los registros producidos por el agente Net-SNMP.
92
Apéndice A - Servicios para Linux
Tabla A.3: Script para servicio snmptrapd
#! /bin/sh
NAME=snmptrapd
DAEMON=/usr/local/net-snmp/sbin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
case "$1" in
start)
echo -n "Starting daemon: $NAME"
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -p $PIDFILE
echo "."
;;
stop)
echo -n "Stopping daemon: $NAME"
kill ‘cat $PIDFILE
echo "."
;;
restart|force-reload)
echo -n "Restarting daemon: $NAME"
kill ‘cat $PIDFILE
sleep 1
start-stop-daemon --start --quiet --background --make-pidfile \
--pidfile $PIDFILE --exec $DAEMON -- -p $PIDFILE
echo "."
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
Debido a que el sistema por defecto no crea archivos con permisos de ejecución es
necesario configurar los scripts para que puedan ser iniciados cuando sea necesario. Para
esto se debe usar el comando de Linux chmod, con los siguientes parámetros para cada
nuevo 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
Apéndice A - Servicios para Linux
A.2.
Instalación de Servicios
El comando update-rc.d crea enlaces simbólicos apropiados para los demonios para
que cuando el sistema se inicie, estos sean ejecutados. En caso de que el sistema sea
detenido, los demonios serán terminados. Para ejecutar este comando es necesario especificar el nivel de ejecución, y dado que son aplicaciones que dependen directamente
de otras se deben escoger los niveles más 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 en
tiempo de booteo. Para ello se debe utilizar el comando update-rc.d de la siguiente
manera:
[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 están funcionando
correctamente. Para ello pueden ser iniciados ejecutando el script de inicio que corresponda (ej. /etc/init.d/asterisk start) o se puede reiniciar el sistema para que se sean
cargados junto con la configuración general (boot time). Para corroborar que se ejecutaron correctamente se hace uso del comando de Linux ps -C servicio donde servicio
corresponde al nombre del demonio revisado. De esta manera a modo de ejemplo se
comprobará la ejecución de los 3 demonios requeridos.
[root@BIONICO ∼]# ps -C snmpd
PID TTY TIME CMD
2750 ? 00:01:53 snmpd
[root@BIONICO ∼]# ps -C asterisk
PID TTY TIME CMD
6317 ? 00:00:00 asterisk
[root@pcmag21 ∼]# ps -C snmptrapd
PID TTY TIME CMD
2529 ? 00:00:00 snmptrapd
94
Bibliografı́a
[1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and
James R. Davin. A Simple Network Management Protocol. Request For
Commentes 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, First
Edition. O’Reillly & Associates, July 2001.
[4] Douglas R. Mauro and Kevin J. Schmidt, Essential SNMP, 2nd
Edition. O’Reillly & Associates, September 2005.
[5] Marshall T. Rose and Keith McCloghrie. Structure and identification of Management Information for TCP/IP-based Internets. Request
for 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 Schoenwaelder. Textual Conventions for SMIv2. Request for Comments 2579, Network Working Group, April 1999.
[9] Developers’ Corner. Systinet Server for Java 6.5.3 Product Documentation. Systinet Server for Java, Systinet Corporation, May 2006.
[10] Charles M. Kozierok. The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference. Published by No Starch Press, September 2005.
[11] Randy Presuhn. Version 2 of the Protocol Operations for the Simple
Network Management Protocol (SNMP). Request for Comments 3416,
Network Working Group, December 2002.
[12] Ramanathan Kavasseri. Event MIB. Request for Comments 2981, Network 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. Desarrollo
de Aplicaciones en la Central Asterisk de Telefonı́a IP en el Departamento de Electrónica, UTFSM. Tesis (Ingenierı́a Civil Electrónica), Valparaı́so, Chile, Universidad Técnica Federico Santa Marı́a, Departamento
de Electrónica, 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 Directory 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 and
HMAC Resources. <http://csrc.nist.gov/cryptval/des.htm>.
[19] Los scripts de inicio. SUSE LINUX – Manual de Administración
<http://www.l3jane.net/doc/linux/suse/suselinux-adminguide es/>.