Diseño e Implementación de un Sistema de Monitoreo basado en SNMP para una Red de Telefonía IP Asterisk

Transcripción

1 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

2 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

3 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.

4 Índice 1. Introducción Objetivos del Proyecto Protocolo SNMP Estaciones y Agentes Comunicación y Clases de Mensajes Métodos de Comunicación SNMP Mensajes SNMP y Protocol Data Units (PDUs) Clases de PDUs Arquitectura SMI Objetos versus Nombres Definición de un Objeto Extensión de SMI SNMP y UDP Comunidades RMON: Monitoreo Remoto Arquitecturas NMS Extensión de un Agente SNMP Seguridad en SNMP Primeros Pasos en SNMP Cambios en SNMPv iii

5 Motor SNMP Aplicaciones SNMP Convenciones definidas en SNMPv Modelo USM Aspectos Básicos Descubrir a su Motor Autoritario Puntualidad USM Autentificación Privacidad Tabla de Usuario USM Llaves Localizadas Control de Acceso basado en Vistas (VACM) Aspectos Básicos Tabla Context Tabla Security to Group Tabla Access Tabla View Tree Family Administración Distribuida (DisMan) Traps e Informs La Necesidad de Traps en SNMP Conceptos Básicos Traps SNMPv Informs SNMPv Net-SNMP Open Source SNMP System Instalación de Net-SNMP Configuración para Agente SNMP Aspectos Fundamentales para la Implementación iv

6 Creación de Usuarios SNMPv Inicio del Agente SNMP Configuración para Receptor de Notificaciones SNMP Funcionamiento del Mecanismo de Notificaciones Demonio snmptrapd Creación de Usuarios SNMPv Asterisk Open Source IP-PBX System Instalación de Asterisk Configuración del Subagente SNMP Usuarios SIP Creación del Dialplan Asterisk CLI Softphone X-lite Iniciación de Servicios Resultados y Conclusión Resultados Resumen sobre configuraciones Estadísticas en IP-PBX 3 a través de SNMP Reconocimiento de Fallas en Central IP-PBX Conclusiones Sistema de Monitoreo Sistema de Reconocimiento de Fallas Desarrollo Futuro A. Servicios para Linux: asterisk, snmpd y snmptrapd 90 A.1. Scripts de Inicio v

7 A.2. Instalación de Servicios A.3. Pruebas de Funcionamiento vi

8 Índice de Figuras 1.1. Mapa de Red de Telefonía IP del departamento de Electrónica Esquema Lógico de Administración de la Red de Telefonía IP Sistema de Monitoreo para una Red de Telefonía a través de SNMP Generación y procesamiento de alarmas con SNMP Relación entre NMS y agente Árbol de objetos SMI Árbol extendido en SMIv Modelo de comunicación TCP/IP y SNMP [3] Arquitectura simple de NMS [4] Arquitectura de Tipo Distribuida de NMS [4] Usando enlaces privados para administrar la red [4] Arquitectura para agentes extensibles Entidad SNMPv Flujo Lógico de VACM X-lite, configuración de parámetros SIP X-lite, Ventana principal Esquema Final de un Sistema de Administración para una Red de Telefonía IP Análisis de Tráfico Ethernet para IP-PBX Análisis de Uso de Canales Asterisk para IP-PBX vii

9 7.4. Análisis de Carga Promedio en CPU para IP-PBX Análisis de Temperatura para IP-PBX Análisis de Memoria en Uso para IP-PBX Zona de notificaciones en el sitio Web de administración viii

10 Índice de Tablas 2.1. Clases de PDU SNMP Tipos de datos definidos en SMIv Nuevos tipos de datos para SMIv Nuevos campos en definición de SNMPv Nuevos tipos de datos para SMIv Modelos y niveles de seguridad Conjunto de aplicaciones para SNMPv Convenciones para SNMPv Conceptos definidos en el modelo USM Formato de un mensaje SNMPv Parámetros de snmpsecurityparemeter Tabla de usuarios USM Traps genéricos Objetos monitoreados en la central IP-PBX Tipos de procesamientos para modelo VACM Formato de notificaciones para Net-SNMP Resumen de Configuraciones para IP-PBX Resumen de Configuraciones para IP-PBX Resumen de Configuraciones para NMS-ELO Descripción del Plan de Monitoreo ix

11 7.5. Tipos de canales disponibles en Asterisk Objetos MIB para análisis de memoria en uso A.1. Script para servicio Asterisk A.2. Script para servicio snmpd A.3. Script para servicio snmptrapd x

12 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

13 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 IP 1, 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 IP: Internet Protocol 2

14 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

15 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

16 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

17 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 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

18 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 Comunicación y Clases de Mensajes El principal objetivo de SNMP es que permite el intercambio de información administrativa en forma de objetos MIB 1 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 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 s; 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

19 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 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 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

20 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 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

21 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] 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 OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } 10

22 2. Protocolo SNMP La primera línea declara a internet con oid , 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 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

23 2. Protocolo SNMP 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 Descripción Integer Número de 32-bit usado para especificar tipos numéricos dentro del contexto de un simple objeto. Octet String 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. Counter Número de 32-bit con mínimo igual a 0 y máximo (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. Object Identifier Una cadena de tipo decimal que representa un objeto administrado dentro del árbol. Por ejemplo representa el OID de Cisco System. null Actualmente no es usado en SNMP. Sequence Define listas que contienen cero o mas tipos de datos ASN.1. Sequence Of Define un objeto administrado que se compone por una secuencia (Sequence) de tipos ASN.1. IpAddress Representa una dirección IPv4 de 32-bit. Ninguna de las dos versiones de SMI especifican sobre las direcciones IPv6 de 128-bit. NetworkAddress Puede representar diferentes tipos de dirección de red. Su formato es similar al tipo IpAddress. Gauge Número de 32-bit con mínimo igual a 0 y máximo (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. TimeTicks Número de 32-bit con mínimo igual a 0 y máximo (4,294,967,295) representado en centésimos de segundo. El tiempo activo en un dispositivo se representa con este tipo de dato. Opaque Permite que cualquier otro ASN.1 sea codificado como una secuencia de bytes (Octet String). 12

24 2. Protocolo SNMP 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 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 Descripción Integer32 Idéntico a Integer. Counter Idéntico a Counter. Gauge32 Idéntico a Gauge. Unsigned32 Representa valores decimales entre 0 y Counter64 Similar a Counter32, pero representa valores entre 0 y BITS Enumeración de no negativos denominada bits. 13

25 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

26 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

27 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

28 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] 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 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

29 2. Protocolo SNMP Tabla 2.5: Nuevos tipos de datos para SMIv2 Objeto OID Descripción statistics Contiene estadísticas sobre todas las interfaces Ethernet monitoreadas por el punto de prueba. history Almacena periódicamente muestras simples desde el grupo de estadística. alarm Permite a un usuario configurar un intervalo cualquiera de muestras y un umbral para cualquier objeto que el punto de prueba registre. hosts Almacena estadísticas sobre tráfico de cada host en la red. hosttopn Contiene estadísticas de hosts usadas para generar reportes sobre hosts que están dentro de una lista pedida para un parámetro dado. matrix Almacena errores e información de utilización para conjuntos de dos direcciones. filter 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. capture Permite capturar paquetes si ellos cumplen con un filtro dentro de un conjunto. event 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

30 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

31 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

32 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 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

33 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

34 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: noauth- NoPriv, AuthNoPriv, AuthPriv. La Tabla 3.1 describe las combinaciones posibles entre estos dos conceptos. Tabla 3.1: Modelos y niveles de seguridad Modelo Nivel Autentificación Encriptación v1 noauthnopriv Comunidad No v2c noauthnopriv Comunidad No v3 noauthnopriv Usuario No v3 authnopriv md5 o sha No v3 authpriv md5 o sha No 23

35 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

36 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 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

37 3. Seguridad en SNMP 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 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

38 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

39 3. Seguridad en SNMP 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

40 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] 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

41 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

42 3. Seguridad en SNMP 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 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) 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 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 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

43 3. Seguridad en SNMP Tabla 3.7: Tabla de usuarios USM Campo Username Authentication protocol Authentication key Privacy protocol Privacy key usmuserspinlock 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: usmnoauth- Protocol, usmhmacmd5authprotocol, y usmhmacs- HAAuthProtocol. 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 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 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

44 3. Seguridad en SNMP 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 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 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

45 3. Seguridad en SNMP vacmgroupname vacmaccesscontextmatch vacmaccesscontextprefix vacmaccesssecuritymodel vacmaccesssecuritylevel vacmaccesswriteviewname vacmaccessnotifyviewname 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 /24). Todas las vistas MIB son almacenadas en vacmviewtreefamily- Table. 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

46 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

47 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

48 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] 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

49 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 , pudiendo definir traps como nodos cuyo identificador sean , , y así sucesivamente 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

50 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) 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 EGP 1 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

51 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

52 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

53 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 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 pre-releases dado que contiene una completa implementación del protocolo SNMPv3 para el receptor de notificaciones y además soluciona algunos bugs 1 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

54 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

55 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 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

56 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 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

57 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

58 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 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

59 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 / ) o ip/bits (ej /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

60 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. ex act. 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

61 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 0x80001f v 3 \ -u pc120encrypter -l authpriv :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

62 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. a usente, 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

63 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 DISMAN- EVENT-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

64 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 monitor -r 60 -u root -o lmtempsensorsdevice.2 -I \ -s "lmtempcpu"lmtempsensorsvalue 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 objeto descripción latable laloadint.1-3 El porcentaje de carga promedio del procesador para 1, 5 y 15 min no debe sobrepasar de 80, 40 y 30 % respectivamente. lmtempcpu lmtempsensorsvalue.2 La temperatura de la CPU no debe sobrepasar los 50 o C. lmtempmotherboard lmtempsensorsvalue.1 La temperatura de la placa madre no debe sobrepasar los 40 o C. memory memavailswap, El uso en memoria Swap no memtotalswap debe sobrepasar los 256 KBytes. 53

65 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 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

66 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 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

67 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

68 5. Net-SNMP Open Source SNMP System 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: 0x ). 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

69 5. Net-SNMP Open Source SNMP System 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 Configuración para Receptor de Notificaciones SNMP Si en la sección 5.2 se describieron las distintas posibilidades que ofrece el agente Net- SNMP 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 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

70 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 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

71 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

72 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

73 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 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 * 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 * 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 SNMPv2- MIB::snmpTrapOID.0. El resto de las líneas contiene un lista de varbinds. Para traps SNMPv1, el oid final debería ser SNMPv2- MIB::snmpTrapEnterprise.0. Una alternativa para el registro de notificaciones en el sitio Web de 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

74 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 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 0x80001f 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 0x80001f \ pc120encrypter MD5 snmpencrypted DES snmpencrypted 63

75 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 voic 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

76 6. Asterisk Open Source VoIP PBX System Debido a que en la pagina oficial de Asterisk, http : // 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 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 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

77 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 -s $netsnmpdir/lib/libnetsnmpmibs.so.14 libnetsnmpmibs.so.14 ln -s $netsnmpdir/lib/libnetsnmpagent.so.14 libnetsnmpagent.so.14 ln -s $netsnmpdir/lib/libnetsnmphelpers.so.14 libnetsnmphelpers.so.14 ln -s $netsnmpdir/lib/libnetsnmp.so.14 libnetsnmp.so.14 66

78 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 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

79 6. Asterisk Open Source VoIP PBX System [general] port = 5060; puerto por el cual se~naliza SIP bindaddr = ; 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= ; context=from-internal; El usuario prueba permite establecer una conexión con la central IP-PBX 2 cuya dirección IP es , 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 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

80 6. Asterisk Open Source VoIP PBX System [general] static=yes; writeprotect=yes; [from-internal] include ruta; include ext-local; [ruta] exten exten 9XX,1,Dial(SIP/prueba/$EXTEN,30,r); 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 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

81 6. Asterisk Open Source VoIP PBX System ]# asterisk -r Asterisk 1.4.4, Copyright (C) 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 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 Secret Accountcode Def.Context ACL NAT from-internal No RFC

82 6. Asterisk Open Source VoIP PBX System pbx-bionico*cli sip show settings Global Signalling Settings: Codecs: 0xc (ulaw alaw) Codec Order: ulaw:20,alaw:20 T1 minimum: 100 Relax DTMF: No Compact SIP headers: No RTP Keepalive: 0 (Disabled) RTP Timeout: 0 (Disabled) RTP Hold Timeout: 0 (Disabled) MWI NOTIFY mime type: application/simple-message-summary DNS SRV lookup: No Pedantic SIP support: No Reg. min duration 60 secs Reg. max duration: 3600 secs Reg. default duration: 120 secs Outbound reg. timeout: 20 secs Outbound reg. attempts: 0 Notify ringing state: Yes Notify hold state: No SIP Transfer mode: open Max Call Bitrate: 384 kbps Auto-Framing: No Default Settings: Context: from-internal Nat: RFC3581 DTMF: rfc2833 Qualify: 0 Use ClientCode: No Progress inband: Never Language: (Defaults to English) MOH Interpret: default MOH Suggest: Voice Mail Extension: asterisk 71

83 6. Asterisk Open Source VoIP PBX System 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 Figura 6.1: X-lite, configuración de parámetros SIP La ventana mostrada en la Figura 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 Figura 6.2: X-lite, Ventana principal 72

84 6. Asterisk Open Source VoIP PBX System 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

85 6. Asterisk Open Source VoIP PBX System estado de la conexión AgentX cada vez que la aplicación es iniciada. ]# cat /var/log/snmpd.log Turning on AgentX master support. NET-SNMP versión 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 sistema 1. 1 Apéndice A: Servicios para Linux: asterisk, snmpd y snmptrapd 74

86 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

87 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 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 Asterisk ip-pbx 2 Nombre: ippbx-pstn Dirección IP: /24 LAN interna: Rango de Anexos: 4900 a 4999 Anexos de Prueba: 200, 900 Puerto FXO: Anexo UTFSM 4093 Puerto FXS: Anexo ZAP 4910 reglas de marcado Para acceder a clientes registrados en IP-PBX 1 marcar un anexo entre 4800 y 4899, por ejemplo Para acceder a clientes internos en IP-PBX 2 marcar un anexo entre 4900 y 4999, por ejemplo 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 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

88 7. Resultados y Conclusión Tabla 7.2: Resumen de Configuraciones para IP-PBX 3 Asterisk ip-pbx 3 Nombre: ippbx-snmp Dirección IP: /24 LAN interna: Rango de Anexos: 800 a 802 Usuario SNMPv3: pc120encrypter Monitor DisMan: root reglas de marcado y SNMP Para acceder a anexos de prueba en ip-pbx 2 marcar anexo 900. Para acceder a clientes internos ip-pbx 3 marcar un anexo entre 800 y 899, 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 Estación nms-elo01 Nombre: pcmag21 Dirección IP: /24 LAN interna: Consultas a: ip-pbx 3 Notificaciones de: ip-pbx 3 reglas de SNMP La estación solo recibe traps SNMPv3 desde usuarios registrados y que pertenecen a la red /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

89 7. Resultados y Conclusión 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 tabla mib objetos Tráfico Ethernet inentry ifinoctets.2, ifoutoctets.2 Uso de Canales Asterisk asteriskchannels astnumchannels.0, astchantypechannels.1-9 Hardware análisis de tabla mib objetos Temperatura lmtempsensors lmtempsensorsvalue.1-3 Carga Promedio latable laloadint.1-3 Memoria en Uso memory 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

90 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 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

91 7. Resultados y Conclusión Tabla 7.5: Tipos de canales disponibles en Asterisk canal descripción Agent Call Agent Proxy Channel Skinny Skinny Client Control Protocol (Skinny) Console OSS Console Channel Driver Phone Standard Linux Telephony API Driver IAX2 Inter Asterisk exchange Driver (Ver 2) Feature Feature Proxy Channel Driver Local Local Proxy Channel Driver SIP Session Initiation Protocol (SIP) MGCP Media Gateway Control Protocol (MGCP) La Figura 7.3 representa el estudio realizado para el uso de canales sip y iax2, debido a que en los otros casos no se dispone del hardware necesario para realizar 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

92 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

93 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

94 7. Resultados y Conclusión 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 (memory) disman:event:delta: Bool comparison: (0!= 0) 0 disman:event:trigger:monitor: Running trigger (latable) disman:event:delta: Bool comparison: (0!= 0) 0 disman:event:delta: Bool comparison: (0!= 0) 0 disman:event:delta: Bool comparison: (0!= 0) 0 disman:event:trigger:monitor: Running trigger (lmtempmotherboard) disman:event:trigger:monitor: Running trigger (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 sysdescr.0 83

95 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: (0x5D5F1772) dumph_recv: msgmaxsize Integer: (0xFFE3) dumph_recv: msgflags String:. dumph_recv: msgsecuritymodel Integer: 3 (0x03) dumph_recv: SM msgsecurityparameters dumph_recv: msgauthoritativeengineid String: dumph_recv: msgauthoritativeengineboots Integer: 180 (0xB4) dumph_recv: msgauthoritativeenginetime Integer: (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: dumph_recv: contextname String: dumph_recv: TRAP2 dumpv_recv: Command TRAP2 dumph_recv: request_id Integer: (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: (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 :49: [UDP: [ ]:32846]: sysuptimeinstance = Timeticks: ( ) 16:04:13.01 \ snmptrapoid.0 = OID: authenticationfailure \ snmptrapenterprise.0 = OID: netsnmpagentoids.10 84

96 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 SNMP Simple Network Management Protocol msgversion: snmpv3 (3) msgglobaldata msgid: msgmaxsize: msgflags: = Reportable: Set = Encrypted: Set = Authenticated: Set msgsecuritymodel: USM (3) msgauthoritativeengineid: 80001F = Engine ID Conformance: RFC3411 (SNMPv3) Engine Enterprise ID: net-snmp (8072) Engine ID Format: Text, administratively assigned (4) Engine ID Data: Text: msgauthoritativeengineboots: 12 msgauthoritativeenginetime: 31 msgusername: pc120encrypter msgauthenticationparameters: 16E B74E msgprivacyparameters: D271C msgdata: encryptedpdu (1) encryptedpdu: A17CC66CBB00C9F363FF2B2D5E8447AFFA0AB92E5A0A6D d0 8d b ff e % f E0C c f 04 0e e pc120encrypt c 16 e b7 4e er...t.np.g.r d 27 1c a1 7c c6 6c l 0090 bb 00 c9 f3 63 ff 2b 2d 5e af fa 0a b9 2e...c.+-^.G... 00a0 5a 0a 6d b4 20 ec 5f 98 d4 5a b5 e0 9d bd Z.m%t.._..Z... 00b a2 fd bf bd b9 4a bb 52 8c bb d2 V...D..J.R... 00c0 8f ec dc

97 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