Comprendiendo El Protocolo SNMP

Protocolos y ServiciosEsc. Tcnica Superior de Ingenieros de Telecomunicacin Univ. de Las Palmas de Gran Canaria

Tutorial de NET-SNMP2006 Luis Hernndez Acosta

INDICE1. Sobre este tutorial

2. Qu es SNMP? 2.1. SNMPv1 2.2. SNMPv2 2.3. SNMPv3

3. Qu es NET-SNMP?

4. El agente SNMP (snmpd) 4.1. Qu es? 4.2. Cmo funciona? 4.3. Configuracin del agente 4.3.1. Ficheros de configuracin 4.3.2. Especificando informacin sobre nuestro sistema 4.3.3. Configuracin de acceso para SNMPv1 y SNMPv2c 4.3.4. Configuracin de acceso para SNMPv3 4.3.5. Envo de notificaciones 4.3.6. Configuracin de MIB extensible 4.3.7. Configuracin de proxy 4.3.8. Pasando el control a programas externos

5. Recepcin de notificaciones 5.1. Tipos de notificaciones 5.2. Funcionamiento del mecanismo de notificaciones 5.3. El demonio snmptrapd 5.3.1. Ficheros de configuracin 5.3.2. Ejecucin de programas para notificaciones entrantes 5.3.3. Formateo de notificaciones 5.3.4. Guardando notificaciones entrantes para consultas mediante SNMP 5.3.5. Creacin de usuarios 5.3.6. Reenvo de notificaciones 5.3.7. Directivas adicionales

Documento extrado del artculo: - Tutorial de NET-SNMP por Jorge Moreno Carreres

1


1. Sobre este tutorialEste tutorial pretende ser una gua rpida de configuracin para los demonios incluidos en elpaquete de gestin de red NET-SNMP (snmpd y snmptrapd). No es una gua de utilidades paralnea de comandos, ni tampoco pretende entrar en aspectos demasiado tericos sobre elfuncionamiento interno del protocolo de gestin de red SNMP. Solamente es un documento quepuede servir tanto para configurar los aspectos ms bsicos como los ms avanzados del agente(snmpd) y el demonio receptor de notificaciones (snmptrapd).El escenario de las pruebas ha sido una pequea red local, constituida por los siguientes hosts:

Un servidor que acta como pasarela de red, ejecutando una distribucin Debian, cuyonombre en la red local es averia. Este es el host en el que se ejecuta el agente SNMP.

Un cliente de red ejecutando una distribucin Debian, cuyo nombre en la red es truca.Aqu se ejecuta el demonio receptor de las notificaciones que manda averia.

2. Qu es SNMP?SNMP son las siglas de Simple Network Management Protocol y es un protocolo muy extendidoque trabaja en el nivel de aplicacin. Mediante SNMP podemos realizar tareas de monitorizacinde red, configuracin de dispositivos, deteccin de problemas y otras muchas cosas ms.

Para gestionar un dispositivo mediante SNMP, ste debe tener un agente que gestione lainformacin contenida en la MIB-II (Management Information Base). El protocolo funcionamediante un mecanismo de peticin-respuesta, es decir, nosotros mandamos una peticin u ordenal agente que gestiona un dispositivo concreto y ste nos responde con la informacin requerida oel resultado de la orden, o con un mensaje de error si nuestra peticin fue incorrecta.Actualmente existen tres versiones de este protocolo: SNMPv1, SNMPv2 y SNMPv3; cada unacon sus propias caractersticas y limitaciones. Nuestro objetivo principal ser abordar lasdiferencias entre estas tres versiones respecto a la autenticacin de las peticiones y rdenes.

2.1. SNMPv1

Cuando se utiliza SNMPv1, el agente emplea un sencillo sistema de autenticacin para determinarqu gestor puede acceder a qu variables de la MIB. Este esquema implica la especificacin deunas determinadas polticas de acceso, relacionadas con los conceptos de comunidad, modo deacceso y vista de la MIB. Una comunidad es un conjunto de hosts relacionados mediante unnombre de comunidad, que debe ser incluido en la peticin. El modo de acceso especificalos accesos permitidos para una determinada comunidad, que suelen ser none, read-write,read-only o write-only. Una vista de la MIB define uno o ms subrboles de la MIB a los queuna determinada comunidad puede acceder.

Cuando el agente recibe una peticin, verifica el nombre de comunidad junto con la IP del hostdesde el que se hizo la peticin para determinar que el host realmente pertenezca a esacomunidad. Si esta verificacin devuelve un resultado positivo, entonces comprueba que lacomunidad tenga acceso a las variables de la MIB solicitadas en la peticin. Si esto es correcto, elagente responder a la peticin. Si no, devolver el mensaje de error correspondiente al hostpeticionario.

En esta versin tambin se define la estructura bsica que debe tener la MIB, incluyendo losidentificadores de objeto (tanto numricos como textuales) de los objetos y tablas de uso mscomn, como ifTable, tcpConnTable, ipAddrTable, etc. Adems, se definen tres operacionesbsicas para el acceso a la informacin de gestin contenida en la MIB: Get, GetNext y Set. Sedefine tambin la operacin Trap para el envo de notificaciones.

2


2.2. SNMPv2

SNMPv2 es una extensin de SNMPv1. La abstraccin de SNMPv2 que permite el uso de losmismos elementos descritos para SNMPv1, es decir, los conceptos de comunidad, vista de laMIB y modo de acceso, es llamada SNMPv2c (Community-based SNMPv2), y es la que el agentede NET-SNMP implementa.

El formato de la PDU (mensaje) es el mismo, solo que se usa un nuevo nmero de versin. Encuanto a las operaciones de acceso a la MIB, adems de las definidas en SNMPv1, esta versindefine dos nuevas: GetBulk e Inform. GetBulk se usa para obtener de forma eficiente grandescantidades de datos, e Inform se usa para el envo de notificaciones con confirmacin por partedel receptor.

En cuanto a la MIB, en esta versin se definen nuevos tipos de objetos para mejorar la semntica.

2.3. SNMPv3

SNMPv3 aade capacidades de seguridad y configuracin remota a las versiones previas. Seintroduce la arquitectura del modelo de seguridad basado en usuarios o USM (User-basedSecurity Model), para aadir seguridad a los mensajes, y el modelo de control de accesobasado en vistas o VACM (View-based Access Control Model) para el control de acceso. Tambinintroduce la posibilidad de configurar remotamente el agente dando distintos valores a los objetosque representan la configuracin del agente.

La arquitectura soporta el uso simultneo de distintos modelos de control de acceso, seguridad yproceso de mensajes, entre los cuales hay que resaltar la autenticacin de usuarios medianteprotocolos seguros (como MD5 o SHA) y la privacidad en la comunicacin usandoalgoritmos de encriptacin como DES.

3. Qu es NET-SNMP?NET-SNMP es un conjunto de aplicaciones usado para implementar el protocolo SNMP usandoIPv4 e IPv6. Incluye:

Aplicaciones de lnea de comandos para:

tomar informacin de dispositivos capaces de manejar el protocolo SNMP,ya sea usando peticiones simples (snmpget, snmpgetnext) o mltiples(snmpwalk, snmptable, snmpdelta).

manipular informacin sobre la configuracin de dispositivos capaces demanejar SNMP (snmpset).

conseguir un conjunto de informaciones de un dispositivo con SNMP(snmpdf, snmpnetstat, snmpstatus).

traducir entre OIDs numricos y textuales de los objetos de la MIB, ymostrar el contenido y estructura de la MIB (snmptranslate).

Un navegador grfico de la MIB (tkmib), usando Tk/perl.

Un demonio para recibir notificaciones SNMP (snmptrapd). Las notificacionesseleccionadas pueden guardarse en un log (como syslog o un archivo de texto plano),ser reenviadas a otro sistema de gestin de SNMP, o ser pasadas a una aplicacinexterna.

3


Un agente configurable para responder a peticiones SNMP para informacin de gestin(snmpd). Incluye soporte para un amplio rango de mdulos de informacin de la MIB, ypuede ser extendido usando mdulos cargados dinmicamente, scripts externos ycomandos.

Una biblioteca para el desarrollo de nuevas aplicaciones SNMP, con APIs para C y Perl.

Si elegimos instalar el paquete correspondiente en un sistema basado en GNU/Linux, podemosinstalar el existente para nuestra distribucin. En las distribuciones basadas en Debiancorresponde con los paquetes llamados: snmp y snmpd.

4. El agente SNMP (snmpd)4.1. Qu es?

snmpd es un agente SNMP que escucha en el puerto 161 de UDP (por defecto), esperando lallegada de peticiones desde algn software de gestin SNMP. Cuando recibe una peticin,recopila la informacin y/o lleva a cabo las operaciones solicitadas, devolviendo la informacincorrespondiente al emisor de la peticin.

4.2. Cmo funciona?

El agente snmpd se ejecuta como demonio, permaneciendo en segundo plano durante toda suejecucin. Una vez instalado el paquete NET-SNMP, el agente se ejecutar al iniciar nuestro hostmediante el sistema de servicios estndar de GNU/Linux. Para iniciarlo, pararlo o recargarlomanualmente usaremos el comando:

# /etc/init.d/snmpd {start|stop|restart|reload|forcereload}usando una opcin u otra dependiendo de lo que queramos hacer. En su arranque, buscar suarchivo de configuracin (/etc/snmp/snmpd.conf). Dicho archivo describe el comportamiento delagente durante la ejecucin, aunque no es imprescindible para que el agente funcione y respondaa peticiones, puesto que dispone de una configuracin por defecto.

4.3. Configuracin del agente

A pesar de que podemos arrancar el agente incluyendo varias opciones en la lnea de comandos(ejecutar snmpd --help para una descripcin ms precisa), llevaremos a cabo la configuracinmediante el fichero snmpd.conf, puesto que de esta forma las opciones que escojamos quedarngrabadas de forma persistente para posteriores ejecuciones.4.3.1. Ficheros de configuracin

Existe un fichero llamado snmp.conf (usualmente en el directorio /etc/snmp) que contiene laconfiguracin referente al conjunto de programas que forman NET-SNMP. En l podemosespecificar aspectos como la localizacin fsica de los archivos de la MIB, los puertos por defectopara los demonios snmpd y snmptrapd, y el directorio donde estos dos demonios guardarn losarchivos persistentes que contienen sus datos (usualmente /var/lib/snmp).

4


El archivo snmpd.conf es especfico para el agente, y contiene una serie de directivas quedescribirn su comportamiento en diversos mbitos, y es el que vamos a construir poco a poco eneste punto del tutorial. En los siguientes apartados pasa a explicarse cada uno de los mbitosposibles de configuracin y las directivas correspondientes que pueden usarse.

4.3.2. Especificando informacin sobre nuestro sistema

Algunas de las siguientes directivas modifican el valor de varios objetos de la MIB, y otras slosirven para la propia configuracin del agente. Ntese que, en caso de darles un valor en elarchivo de configuracin del agente, se convertirn en objetos de slo lectura (obviamente,aquellos que sean de lectura y escritura inicialmente) y, por tanto, no podremos cambiar susvalores mediante el comando snmpset.

syslocation CADENA

Cambia el valor del objeto system.sysLocation de la MIB, usado para especificar lalocalizacin fsica del host en el que corre el agente.

En nuestro ejemplo, incluiremos la siguiente directiva:syslocation "Lab. de Prctias de Protocolos y Servicios"

syscontact CADENA

Especifica la informacin textual de contacto con la persona responsable del host(objeto system.sysContact). Podemos, por ejemplo, incluir lo siguiente en nuestroarchivo de configuracin:

syscontact "Profesor de Prcticas de Protocolos y Servicios"

sysname CADENA

Especifica el nombre del host, usualmente el nombre de dominio completo. El objetoreferido por esta directiva es system.sysName. Daremos un valor a este objeto con lasiguiente directiva:

sysname "averia.labpracts.dit.ulpgc.es"

sysservices NUMERO

El objeto system.sysServices indica el conjunto de niveles de la arquitectura OSI queel 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 host, sumamos asysServices el valor 2 elevado a L-1. En caso de que el host no soporte OSI (el casoms general), tendremos slo en cuenta los niveles 1 (fsico), 2 (enlace), 3 (red), 4(transporte) y 7 (aplicacin). Para un host, el valor recomendado es 72 (es decir,niveles de transporte y aplicacin). Vamos, pues, a incluir este valor en nuestro archivode configuracin:

sysservices 72

5


sysdescr CADENA

Especifica una descripcin textual del host (system.sysDescr).Convencionalmente contiene su nombre completo, una descripcin del hardware, delsistema operativo y del software de red.

La descripcin de nuestro host ser la siguiente:

sysdescr " averia.labpracts.dit.ulpgc.es Linux UbuntuPentium IV@3200_MHz 1024_MB_RAM"

sysobjectid OIDEl valor de system.sysObjectID debe contener una identificacin del subsistema degestin de red que contiene el dispositivo, proporcionada por el fabricante. Provee unaforma fcil y no ambigua de saber qu tipo de dispositivo estamos gestionando. Estevalor est ubicado dentro del subrbol enterprises de la MIB (1.3.6.1.4.1). Porejemplo, si el fabricante "PCs Inc." tiene asignado el subrbol 1.3.6.1.4.1.666, podraasignar el OID 1.3.6.1.4.1.666.1.1 a su router "DeLab 6780".

En nuestro caso lo dejaremos tal cual est, puesto que en este punto no tenemosningn subrbol asignado dentro de enterprises.

agentaddress [:][,...]

Por defecto, snmpd escucha en el puerto 161 de UDP de todas las interfaces de red.Mediante esta directiva podemos modificar este comportamiento.

Por ejemplo, si quisiramos que el agente escuchara en el puerto 161 de TCP y UDPpara todas las interfaces, y en el puerto 9161 en la interfaz de loopback (lo),incluiramos la siguiente directiva:

agentaddress 161,tcp:161,localhost:9161

agentgroup IDgrupo

Esta directiva provoca que el agente cambie su identificador de grupo despus de abrirel puerto en el que escucha. IDgrupo puede ser el nombre de un grupo o suidentificador numrico.

Si quisiramos que el agente se ejecutase con el ID de grupo jordi, incluiramos:agentgroup jordi

agentuser IDusuario

Funciona de forma anloga a la directiva anterior, solo que sta se refiere alidentificador de usuario.

Si queremos que nuestro agente se ejecute con el ID del usuario jordi, incluiremos:agentuser jordi

6


interface NOMBRE TIPO VELOCIDAD

Mediante esta directiva podemos especificar la informacin referente a aquellasinterfaces cuyos parmetros no sean bien detectados por el agente. Si, por ejemplo,disponemos de una interfaz eth0 de tipo Ethernet y con una velocidad de conexin de100 Mb/s, y por cualquier razn el agente no la detecta correctamente, podemos darlea ste los parmetros de nuestra interfaz:

interface eth0 6 10000000

ignoredisk CADENA

Cuando el agente escanea todos los dispositivos de disco disponibles, puede que sebloque, pudiendo producir un timeout cuando inspeccionemos la tabla de dispositivosmediante snmpwalk. Si esto ocurre, podemos usar esta directiva para forzar al agentea que no escane ciertos discos, pudiendo incluirla varias veces en el archivo deconfiguracin. El formato de CADENA puede seguir la sintaxis del bourne shell.

Si nuestro disco /dev/hda3 causa problemas al agente durante la deteccin, podemosobligarle a que no lo escanee:

ignoredisk /dev/hda3

storageUseNFS NUMERO

Cuando NUMERO=1, esta directiva causa que todos los sistemas de archivos NFSsean marcados como "Network Disks" en la tabla hrStorageTable (1.3.6.1.2.1.25.2.3).Si la directiva no se usa, o NUMERO=2, aparecern como "Fixed Disks".

Por claridad en las consultas, usaremos esta directiva en nuestro archivo:

storageUseNFS 1

override OID TIPO VALOR

Esta directiva permite sobreescribir un OID con un valor distinto, e incluso con un tipodistinto. Por ejemplo, podramos sobreescribir el valor y el tipo de system.sysDescrmediante la siguiente orden:

override sysDescr.0 octet_str "PC Lab. Protocolos y Servicios"

Con esto le estaramos cambiando el tipo a octet_str y su valor a la cadena encerradaentre comillas. Indirectamente, estamos haciendo tambin que sea modificablemediante snmpset, lo cual viola la especificacin de la MIB.

4.3.3. Configuracin de acceso para SNMPv1 y SNMPv2c

Usando las siguientes directivas podemos configurar los parmetros necesarios para controlar elacceso a nuestra MIB. Para SNMPv1 y SNMPv2c aplicaremos los conceptos de comunidad, vistay modo de acceso explicados en este tutorial. Este modo de acceso a la MIB es el llamado Modelode Control de Acceso Basado en Vistas o VACM (View-Based Access Control Model). Primero,tenemos que definir nombres de seguridad y asociarlos con nombres de comunidad y con unconjunto de hosts que pertenecern a dicha comunidad. Despus, asociaremos estos nombres deseguridad con nombres de grupos para, finalmente, definir vistas y asociar cada una de ellascon un grupo de los definidos anteriormente.

7


com2sec NOMBRE FUENTE COMUNIDAD

Esta directiva especifica la asociacin entre un nombre de seguridad, un host oconjunto de hosts (tpicamente definido por un conjunto de direcciones IP) y un nombrede comunidad. FUENTE puede ser un nombre de host, la palabra default o unadireccin de subred junto con los bits dedicados a la mscara de subred.Crearemos dos comunidades, una con acceso desde toda la red y otra con acceso slodesde la red local:

com2sec public_sec default publiccom2sec private_sec 192.168.0.0/24 private

com2sec6 NOMBRE FUENTE COMUNIDAD

Esta directiva es la versin de la anterior para direcciones IPv6. Slo ser vlida siespecificamos UDPIPv6 como dominio de transporte en la compilacin.

group NOMBRE MODELO SEGURIDAD

Esta directiva mapea un nombre de seguridad con un nombre de grupo, asignando adicho grupo un modelo de acceso que puede ser v1, v2c o usm (User-based SecurityModel, usado para SNMPv3).Vamos a crear dos grupos, asociados a los nombres de seguridad que hemosespecificado en la directiva anterior. Cada grupo podr acceder mediante peticionesSNMPv1 o SNMPv2:

group public_grp v1 public_secgroup public_grp v2c public_secgroup private_grp v1 private_secgroup private_grp v2c private_sec

access NOMBRE CONTEXTO MODELO NIVEL PREFIJO LEER ESCRIBIRNOTIFICAR

Define los accesos posibles de los grupos definidos anteriormente a las vistas quedefiniremos con la directiva view.

NOMBRE ser el nombre del grupo. CONTEXTO representa un nombre de contexto o grupo de nombres de

contexto. Para SNMPv1 y SNMPv2c su valor ser la cadena vaca. MODELO puede contener los mismos valores que en la directiva anterior

junto con la palabra any (cualquiera). NIVEL especifica el nivel de autenticacin necesario para este acceso, y

puede ser noauth, auth o priv. Para SNMPv1 y SNMPv2c debe valernoauth. Se entrar en detalle en el apartado referido a SNMPv3.

PREFIJO especifica la coincidencia que debe haber entre CONTEXTO y elcontexto de la PDU (mensaje) entrante. Puede valer exact o prefix.

LEER especifica la vista sobre la que se pueden realizar operaciones delectura en este acceso.

ESCRIBIR indica la vista de los objetos que podemos escribir mediante esteacceso.

NOTIFICAR define la vista sobre cuyos objetos podremos lanzarnotificaciones.

8


Definiremos los siguientes accesos para los grupos creados anteriormente: el grupopublic tendr acceso de slo lectura a toda la MIB y el grupo private tendr acceso delectura a toda la MIB, y de escritura a la vista parte, definida en la siguiente directiva.

access public_grp "" any noauth exact todo none noneaccess private_grp "" any noauth exact todo parte todo

view NOMBRE TIPO SUBARBOL [MASCARA]

Esta directiva nos permite definir vistas de la MIB, que no son ms que subconjuntosde sta. Estos subconjuntos pueden estar formados por una o ms ramas del rbol dela MIB, e incluso por la MIB entera. A menos que creemos vistas con una sola rama delrbol de la MIB, tendremos que usar varias de estas directivas para crear una nuevavista a nuestro gusto.

NOMBRE ser el nombre que queramos asignar a esta vista. Si la vista yaexiste, esta directiva la modificar conforme a los parmetros siguientes.

TIPO ser la accin que queramos realizar sobre esta vista. Puede valerincluded (incluido) o excluded (excluido).

SUBARBOL es el subrbol de la MIB que queramos incluir o excluir de estavista, dependiendo del valor del parmetro anterior.

MASCARA es una mscara de bits. Nos permite definir de forma sencilla elacceso a un conjunto de objetos en base al OID proporcionado en el campoSUBARBOL. Por ejemplo, en la directiva

view MiVista included 1.3.6.1.2.1.2.2.1.1.1 ff.a0

En este ejemplo usamos la mscara ff.a0, cuyo equivalente en binario sera11111111.10100000. El primer cero aparece en la mscara en la posicin 10, lo cualpermitir acceder mediante esta vista a todos los objetos cuyo OID se correspondacon 1.3.6.1.2.1.2.2.1.x.2, siendo x un valor cualquiera.

Para nuestro ejemplo, crearemos dos vistas: Una vista todo que cubrir toda la MIB yuna vista parte que cubrir toda la MIB, exceptuando el rbol de RMON.

view todo included .1 00view parte included .1 00view parte excluded .1.3.6.1.2.1.16

El siguiente ejemplo genrico nos ilustra sobre cmo conjuntar el uso de los nombres deseguridad, de comunidad y de grupo:

# nombre fuente comunidadcom2sec nombre_sec localhost mi_comunidad

# nombre modelo seguridadgroup mi_grupo v1 nombre_sec

# nombre tipo subarbol mascaraview vista included .1 80

# contexto modelo nivel prefijo leer escribir notificaraccess mi_grupo "" any noauth exact vista vista vista

9


Disponemos tambin de una serie de directivas ms fciles de usar, pero que son menos flexiblessi pretendemos crear configuraciones personalizadas. Estas directivas son las siguientes:

rocommunity COMUNIDAD [FUENTE [OID]]Crea una comunidad con permisos de lectura sobre el subrbol especificado por OID,cuyos miembros sern los hosts especificados por FUENTE.

Crearemos una comunidad con acceso de slo lectura sobre el rbol interfacesmediante la siguiente directiva:

rocommunity cotilla 192.168.0.0/24 .1.3.6.1.2.1.2

rwcommunity COMUNIDAD [FUENTE [OID]]Idntica a la anterior, pero creando una comunidad con permisos de lectura y escritura.Para crear una comunidad con estos derechos de acceso sobre el grupo system, ycon acceso solamente desde el localhost, usaramos:

rwcommunity hacker localhost .1.3.6.1.2.1.1

rocommunity6 COMUNIDAD [FUENTE [OID]] rwcommunity6 COMUNIDAD [FUENTE [OID]]

Estas dos directivas son las anlogas a las dos anteriores para el dominio detransporte UDPIPv6.

4.3.4. Configuracin de acceso para SNMPv3

Usando estas directivas podremos crear usuarios que puedan comunicarse con el agentemediante el protocolo SNMPv3 que, a diferencia de las dos anteriores versiones, soporta un modode acceso basado en usuarios y contraseas.

engineID CADENA

Con esta directiva daremos un identificador al agente, llamado engineID, que steusar para poder responder a mensajes SNMPv3. Si no le damos ningn valor, secalcular en base a un nmero aleatorio junto con la hora actual en segundos. El valorde CADENA puede ser cualquier combinacin de dgitos hexadecimales, como porejemplo:

engineID 001122334455AABBCCDD

rouser USUARIO [noauth|auth|priv [OID]]Crea un usuario SNMPv3 con derechos de slo lectura, especificando el nivel deautenticacin requerido (ver la directiva createUser para una explicacin) y el subrbolde la MIB al cual tendr acceso. Si el nivel de acceso escogido es auth o priv,tendremos que asociar contraseas a los usuarios creados mediante la directivacreateUser.

10


Vamos a crear un usuario con acceso de slo lectura a toda la MIB, sin necesidad deautenticacin en el acceso:

rouser manolito noauth .1

NOTA: para activar este usuario, tenemos que incluir una directiva createUser en elarchivo /var/lib/snmp/snmpd.conf, aunque no asignemos ninguna contrasea alusuario, de la siguiente forma:

createUser manolito

rwuser USUARIO [noauth|auth|priv [OID]]Idntica a la anterior, solo que da permisos de lectura y escritura al nuevo usuario.

Crearemos un usuario con acceso de lectura y escritura sobre el grupo system, y connivel de autenticacin auth:

rwuser alfredito auth system

createUser [-e ENGINEID] nombre (MD5|SHA) contrasea_auth [DES][contrasea_priv]Crea un nuevo usuario capaz de comunicarse con el agente mediante SNMPv3. Estenombre de usuario debe haberse definido previamente mediante una directiva rouser orwuser.

Cuando asociemos estos usuarios con nombres de grupo para asociarles vistas, elnombre especificado aqu es el que debe incluirse como nombre de seguridad en ladirectiva group descrita en el apartado anterior. Podemos escoger entre los algoritmosMD5 y SHA para los mensajes autenticados, si bien necesitamos tener instalado elpaquete OpenSSL para usar SHA. Para los mensajes encriptados slo podremos usarDES.

Disponemos de tres posibles modos de acceso:

noauth: cuando llegue una peticin de este usuario, no se requerirninguna contrasea para llevarla a cabo.

auth: se usa una contrasea solamente para la autenticacin del usuario, yasea mediante el protocolo MD5 o SHA.

priv: con este modo de acceso, las PDU (mensaje) que viajen por la redirn encriptadas mediante el algoritmo DES. Por ello, se requiere una claveadicional para el cifrado y descifrado.

Aqu definimos dos contraseas. La primera es la que se usar cuando el nivel deautenticacin sea auth, y la segunda cuando sea priv (ver la directiva access). Detodos modos, si la segunda est en blanco se tomar la primera tambin para el modode acceso priv.

11


Al usar esta directiva debemos tener en cuenta una cuestin: si la introducimos ennuestro archivo /etc/snmp/snmpd.conf cualquier usuario con permiso de lectura sobreeste archivo podra leer sin problemas los nombres de usuario y las contraseas, conlo que esta nueva poltica de acceso no nos servira para mucho. En lugar de esto,tenemos que incluirlas en el archivo /var/lib/snmp/snmpd.conf y justo despusreiniciar el agente. Esto causar que el agente vuelva a leer este archivo, creando losusuarios y borrando las lneas correspondientes (eliminando as las contraseas deldisco duro), para despus guardar en este mismo archivo las claves que se derivan deestas contraseas.

Ejemplo:Primero, detenemos el agente:

# /etc/init.d/snmpd stop

Ahora asignamos una contrasea de autenticacin al usuario alfredito que hemoscreado previamente con la directiva rouser, escribiendo la siguiente lnea en el archivo/var/lib/snmpd.conf:

createUser alfredito MD5 pass_alfredito

Ahora, volvemos a ejecutar el agente:# /etc/init.d/snmpd start.

Si editamos el archivo /var/lib/snmpd.conf, podremos comprobar que la directivaintroducida se ha transformado en lo siguiente:

usmUser 1 30x80001f880430303131323233333434353541414242434344440x616c6672656469746f00 0x616c6672656469746f00 NULL .1.3.6.1

A partir de ahora, podremos realizar peticiones SNMPv3 al agente mediante el nombrede usuario y la contrasea que acabamos de crear. Es importante sealar que hay queincluir el modo de acceso mediante la opcin -l, de la siguiente forma:

# snmpwalk v 3 u alfredito l authNoPriv a MD5 A pass_alfredito averia system

4.3.5. Envo de notificaciones

Una notificacin es un mensaje SNMP no solicitado que enva el agente a un receptordeterminado. Generalmente indica un cambio de estado en el dispositivo gestionado por elagente, o una condicin de alarma. SNMP define dos tipos de notificaciones: traps e informs.

Un trap es una notificacin no confirmada por el receptor. Esto hace que necesitemos unmecanismo para detectar la prdida de traps en la red si las notificaciones que enviamos son decarcter crtico.

Un inform es una notificacin que requiere confirmacin por parte del receptor, lo cual la hacems adecuada para situaciones crticas. Sin embargo, estas notificaciones no fueron incluidas enel protocolo hasta la versin SNMPv2c, con lo que no sern permitidas en agentes que soportensolamente la versin SNMPv1.

12


authtrapenable NUMERO

Cuando NUMERO=1, provoca el envo de traps ante fallos de autenticacin(comunidad incorrecta en la peticin, o intento de acceder a un objeto no pertenecientea la vista de la comunidad especificada). El objeto al que se refiere esta directiva essnmpEnableAuthenTraps, y el hecho de usarla provocar que sea de slo lectura.

Activaremos esta opcin en nuestro agente:

authtrapenable 1

trapcommunity CADENA

Especifica la comunidad por defecto que ser usada al enviar notificaciones. Estadirectiva debe aparecer en el archivo de configuracin antes que las cuatro siguientes.En nuestra configuracin, usaremos la comunidad por defecto private:

trapcommunity private

trapsink HOST [COMUNIDAD [PUERTO]]Especifica el host (y opcionalmente el puerto) que recibir los traps SNMPv1 enviados.Podemos especificar tambin la comunidad a usar en el envo, aunque si no lohacemos se usar la comunidad por defecto. Si usamos esta directiva, el agenteenviar traps tambin en los errores de autenticacin. Puede aparecer varias vecespara especificar mltiples destinos.

trap2sink HOST [COMUNIDAD [PUERTO]]Esta directiva es idntica a la anterior, solo que trabaja con los traps de SNMPv2c.

informsink HOST [COMUNIDAD [PUERTO]]

Es la equivalente a las dos anteriores para el envo de informs.

Vamos a usar estas tres ltimas directivas para mandar todo tipo de notificaciones alhost 192.168.0.3:

trapsink 192.168.0.3trap2sink 192.168.0.3informsink 192.168.0.3

trapsess [SNMPCMD_ARGS] HOST

Es una directiva genrica de configuracin que permite especificar cualquier destinocon cualquier versin de SNMP.

A partir de su quinta versin, el agente incorpora soporte DisMan (DistributedManagement Event MIB) para la MIB. Esta nueva caracterstica permite al agentemonitorizar sus propios datos en intervalos regulares, y/o mandar notificacionescuando se den ciertas condiciones. Estas notificaciones se mandarn la primera vezque se cumplan sus condiciones de envo, y para que vuelvan a enviarse debe ocurrirque las condiciones de envo vuelvan a ser falsas al menos una vez.

13


Segn la pgina del manual, este soporte no ha sido probado exhaustivamente y,adems, se sabe que no est completo. Sin embargo, las directivas aqu explicadasdeberan funcionar correctamente.

Si el agente fue compilado con soporte para DISMAN-EVENT-MIB, podremos usar lassiguientes directivas para monitorizar objetos y mandar notificaciones referentes aellos.

Enviaremos los traps SNMPv3, usando el nombre de usuario manolito, con nivel deautenticacin noAuthNoPriv, haciendo uso de la siguiente directiva:

trapsess v3 e 001122334455AABBCCDD l noAuthNoPriv u manolito 192.168.0.3

Si queremos hacer lo mismo, pero para el envo de informs:

trapsess Ci v3 l noAuthNoPriv u manolito 192.168.0.3

agentSecName NOMBRE

El soporte para DISMAN-EVENT-MIB requiere un nombre de usuario, mediante el cualescanear el agente. ste puede ser especificado mediante esta directiva o usando laopcin -u de la directiva monitor explicada a continuacin. El nombre queespecifiquemos debe estar declarado mediante una directiva rouser o rwuser.

El nombre de seguridad de nuestro agente ser el siguiente:

agentSecName manolito

monitor [OPCIONES] NOMBRE EXPRESION

Esta directiva manda al agente que se monitorice a s mismo en busca de problemasbasados en la expresin especificada. sta puede ser una expresin simple basada enun OID, un operador de comparacin (!=, ==, >=,


-o OID

Especifica nombres de objetos adicionales que sern incluidos en la notificacin,adems de los objetos referidos por la directiva. Esto puede ser til cuandoqueramos mandar toda una fila de una tabla, aunque monitoricemos slo una delas posiciones.

-e NOMBRE_EVENTO

Especifica un nombre de evento que describir qu hacer cuando la condicinse cumpla. Usualmente ser el nombre de un notificationEvent.

Podramos, por ejemplo, monitorizar la tabla hrSWRunPerfTable en busca deprocesos que consuman ms de 10 MB de memoria RAM, para devolver su nombre enun trap:

monitor o sysUpTime.0 o hrSWRunName "Procesos acaparadores"hrSWRunPerfMem > 10000

Si quisiramos monitorizar la tabla ifTable buscando aquellas interfaces de red quehayan recibido ms de diez tramas errneas, usaramos:

monitor o sysUpTime.0 e "Errorcito" o ifDescr "Interfaces gafes"ifInErrors > 10

notificationEvent NOMBRE NOTIFICACION [[-w] OID ...]Esta directiva crear un evento de notificacin, que ser disparado mediante unadirectiva monitor que se refiera a l con su opcin -e. NOTIFICACION debe ser el OIDde una notificacin, pudiendo incluirse OIDs adicionales, y ser el tipo de notificacinque se enviar. Por defecto se incluir al OID el sufijo de la columna u objetomonitorizado, a menos que incluyamos la opcin -w. Por ejemplo, si monitorizamos latabla ifTable y queremos incluir el valor de ifDescr para las filas que produzcannotificaciones, entonces no incluiremos la opcin w y se aadir automticamente elcampo INDEX. En cambio, si monitorizamos el objeto sysContact.0, ningn sufijodebe ser aadido y entonces s que usaremos dicha opcin.

Asociaremos a la ltima directiva monitor del punto anterior un evento para el envo deun trap de tipo linkDown mediante la siguiente directiva:

notificationEvent "Errorcito" .1.3.6.1.2.1.11.2

linkUpDownNotifications yes

Esta directiva har que el agente monitorice la tabla de interfaces (ifTable) paradeterminar cundo una interfaz es activada o desactivada. Cuando esto pase, selanzarn notificaciones linkUp o linkDown respectivamente.

Vamos a incluir esta directiva en nuestra configuracin:

linkUpDownNotifications yes

15


defaultMonitors yes

Activa las siguientes directivas monitor:

monitor o prNames o prErrMessage "process table" prErrorFlag != 0monitor o memErrorName o memSwapErrorMsg "memory" memSwapError != 0monitor o extNames o extOutput "extTable" extResult != 0monitor o dskPath o dskErrorMsg "dskTable" dskErrorFlag != 0monitor o laNames o laErrMessage "laTable" laErrorFlag != 0monitor o fileName o fileErrorMsg "fileTable" fileErrorFlag != 0

Tambin la incluiremos en nuestro archivo:

defaultMonitors yes

4.3.6. Configuracin de MIB extensible

El agente SNMP obtiene mucha de su informacin de la seccin 1.3.6.1.4.1.2021(.iso.org.dod.private.enterprises.ucdavis) del rbol de la MIB. Cada subseccin de esta MIBtiene los siguientes campos:

.ID.1 index

Es un ndice entero. Para escalares, siempre tiene el valor 1. Para tablas, es un ndicede filas.

.ID.2 name

Es el nombre de esta entrada de la tabla.

.ID.100 errorFlag

Es un flag que devuelve el valor 1 si se detect un error para esta entrada de la tabla.

.ID.101 errMessage

Es una cadena que describe el error que provoc que el campo anterior se pusiera auno.

.ID.102 errFix

Este objeto acta como un disparador. Si esta entrada vale 1, se ejecutar un programapasndole el nombre de la entrada de la tabla como argumento. El programa seespecifica en el campo errFixCmd.

Este convenio permite al agente examinar fcilmente ciertas circunstancias concretas poniendo elvalor de ID correspondiente a la seccin que se quiera monitorizar, y escaneando el valor de.ID.100 en busca de errores.

16


Las siguientes directivas pueden usarse en este apartado:

proc NOMBRE [MAX [MIN]]

Comprueba que el proceso cuyo nombre es NOMBRE est ejecutndose actualmente.MAX y MIN son el nmero mximo y mnimo de instancias de dicho proceso. Si noespecificamos ninguno de los dos valores, MAX se asume como infinito y MIN comouno. Si especificamos MAX pero no MIN, ste ltimo se asumir como cero. stos serefieren al nmero mximo y mnimo de instancias del proceso permitidas.

Podramos comprobar la existencia de un proceso llamado amule en nuestro sistema,y al mismo tiempo que no se est ejecutando ms de una vez, con la siguientedirectiva:

proc "amule" 1 1

procfix NOMBRE PROGRAMA ARGUMENTOS

Esta directiva registra un comando que sabr cmo arreglar los errores ocurridos conel proceso especificado por NOMBRE, obteniendo la informacin de ste de la tablaenterprises.ucdavis.procTable. Cuando hagamos un snmpset al campo prErrFixcorrespondiente, ponindolo a 1, se ejecutar el comando registrado.Podemos, por ejemplo, registrar en un log la muerte del proceso amule:

procfix "amule" /bin/sh /usr/local/bin/watchAmule.sh

exec [MIBNUM] NOMBRE PROGRAMA ARGUMENTOSSi MIBNUM no se incluye en esta directiva, el agente ejecutar PROGRAMA con losargumentos especificados, guardando el estado de salida y la primera lnea de la salidaestndar de dicho programa para futuras consultas a las columnas1.3.6.1.4.1.2021.8.1.100 y 1.3.6.1.4.1.2021.8.1.101, respectivamente. El resto de salidadel programa se omitir.

Si incluimos MIBNUM actuar de la misma forma, pero guardar el estado de salida enMIBNUM.100.0 y la salida completa del programa en MIBNUM.101. Cada lnea de lasalida se guardar en una fila de la tabla especificada (primera lnea enMIBNUM.101.1, segunda lnea en MIBNUM.101.2, etc). MIBNUM debe serespecificado en formato numrico. Hay que tener en cuenta que el agente guarda enuna cach interna el estado y la salida del programa durante unos treinta segundosantes de volcarlos a la MIB, para aumentar la eficiencia y la consistencia de lainformacin en peticiones consecutivas. Puede forzarse el volcado escribiendo un 1 enel objeto 1.3.6.1.4.1.2021.100.VERCLEARCACHE mediante una orden snmpset.Probaremos esta caracterstica haciendo que el agente ejecute un script que registreen un log la fecha y la hora de su ejecucin:

exec "inicia" /bin/sh /usr/local/bin/pruebaExec.sh

Podemos extender una rama de la MIB con la salida de un programa o script:

exec .1.3.6.1.4.1.666 "miComando" /bin/sh /usr/local/bin/miComando.sh

17


A partir de que reiniciemos el agente, las peticiones de lectura sobre ese OIDdevolvern lo siguiente:

$ snmpwalk v1 c public averia .1.3.6.1.4.1.666SNMPv2SMI::enterprises.666.1.1 = INTEGER: 1SNMPv2SMI::enterprises.666.2.1 = STRING: "miComando"SNMPv2SMI::enterprises.666.3.1 = STRING: "/bin/sh/usr/local/bin/miComando.sh"SNMPv2SMI::enterprises.666.100.1 = INTEGER: 0SNMPv2SMI::enterprises.666.101.1 = STRING: "unlugarMancha"SNMPv2SMI::enterprises.666.102.1 = INTEGER: 0SNMPv2SMI::enterprises.666.103.1 = ""

execfix NOMBRE PROGRAMA ARGUMENTOS

Trabaja igual que la directiva procfix, solo que en esta ocasin el agente monitorizarlos valores de la tabla enterprises.ucdavis.extTable, actuando cuando el campoextErrFix correspondiente est a 1.

Incluiremos la siguiente directiva para notificar los problemas ocurridos en la ejecucinde pruebaExec.sh:

execfix "inicia" /bin/sh /usr/local/bin/fixExec.sh

disk RUTA [ ESPACIO_MIN | PORCENT_MIN% ]Comprueba el espacio disponible en el disco montado en RUTA. Si el espacio esmenor que ESPACIO_MIN en KB o que PORCENT_MIN% en tanto por ciento, laentrada asociada en la tabla 1.3.6.1.4.1.2021.9.1.100 se pondr a 1 y se escribir elmensaje de error correspondiente en 1.3.6.1.4.1.2021.9.1.101.Vamos a comprobar que queden, al menos, 100 MB libres en la particin raz:

disk / 100000

includeAllDisks PORCENT_MIN%

Aade todos los discos que puedan ser encontrados en el sistema mediante lasllamadas al sistema setmntent y getmntent, o fopen y getmntent, o setfsent ygetfsent. Si ninguna de estas llamadas se encuentra en el sistema, aadir la particinraz usando la llamada statfs. Los parmetros especificados mediante la directiva disksobreescriben a los de esta directiva. Hay que tener en cuenta que slo incluir losdiscos que ya estn montados cuando el agente se inicie.

Monitorizaremos los discos duros para comprobar que les quede, al menos, un 10% deespacio libre:

includeAllDisks 10%

load [MAX1 [MAX5 [MAX15]]]

Devuelve un 1 en el objeto 1.3.6.1.4.1.2021.10.1.100 y un mensaje de error en1.3.6.1.4.1.2021.10.1.101 cuando las medias de uno, tres o quince minutos excedanlos valores mximos asociados en la llegada de una solicitud GET sobre el campolaLoad de la tabla private.enterprises.ucdavis.laTable.

18


Vamos a establecer las medias mximas en los siguientes valores:

load 1 2 4

file ARCHIVO [TAMAO_MAX]Monitoriza el tamao de ARCHIVO comprobando que no crezca ms all del tamaomximo especificado en KB, pero sin reportar errores al respecto. TAMAO_MAX esinfinito por defecto.

Comprobaremos que el archivo /var/log/messages no ocupe ms de 4 MB:

file /var/log/messages 4096

4.3.7. Configuracin de proxy

Mediante el soporte para proxy del agente podemos hacer que todas las peticiones sobre un OIDqueden delegadas a un host distinto.

proxy [-Cn NOMBRE_CONTEXTO] [ARGS_SNMPCMD] HOST OID [OID_REMOTO]

Cede el control del rbol de la MIB especificado por OID al HOST descrito. Si seincluye NOMBRE_CONTEXTO, asignar el rbol a un nombre de contexto particulardentro del agente local. La forma ms adecuada de hacer solicitudes a mltiplesagentes a travs de un slo proxy sera asignar a cada agente remoto un nombre decontexto. Entonces, podramos usar snmpwalk -n nombreContexto1 para preguntar aun agente remoto, y snmpwalk -n nombreContexto2 para preguntar a otro. En esteaspecto slo se soporta la versin SNMPv3 para las peticiones, puesto que losnombres de contexto no estn soportados para las versiones 1 y 2.

Podemos tambin mapear el OID local a un nuevo OID remoto, especificado porOID_REMOTO. Para la autenticacin en las consultas, debemos usar los argumentoscorrectos en ARGS_SNMPCMD.

Ejemplos:Podemos mapear el grupo system del host truca en el rbol experimental de la MIB deaveria, mediante la siguiente directiva:

proxy Cn truca1 v1 c public 192.168.0.3 .1.3.6.1.3.11 .1.3.6.1.2.1.1

As, haciendo uso del nombre de contexto truca1, podemos consultar el subrbolcreado de la siguiente manera:

# snmpwalk v3 u manolito n truca1 averia .1.3.6.1.3.11

Podemos tambin hacer que no sea necesario aadir el nombre de contexto a lasconsultas haciendo uso de una conexin SNMPv3 con truca, con la siguiente directiva:

proxy v3 u manolito 192.168.0.3 .1.3.6.1.3.10 .1.3.6.1.2.1.1

Con esta directiva, podremos hacer peticiones como la siguiente:

# snmpwalk v3 u manolito l noAuthNoPriv averia .1.3.6.1.3.10

19


4.3.8. Pasando el control a programas externos

Con estas directivas podremos hacer que las peticiones SET y GET a un OID dado se pasen alprograma que queramos.

pass OID EJECUTABLE

Esta directiva es la que usaremos para este fin. El programa especificado porEJECUTABLE puede ser llamado de las siguientes formas:

EJECUTABLE -g OID EJECUTABLE -n OID

Estas dos directivas se corresponden con las llamadas GET y GETNEXT. Elprograma especificado debe dar la respuesta esperada a las peticionesefectuadas a travs de su salida estndar, de la siguiente forma: la primeralnea debe ser el OID correspondiente a la peticin, la segunda lnea debeser el tipo del valor devuelto (string, integer, unsigned, objectid,timeticks, ipaddress, counter o gauge), y la tercera ser el valor del objetosolicitado. Por ejemplo, si un programa debe devolver el valor 42 al llegaruna peticin sobre el objeto .1.3.6.1.4.100, debera imprimir las siguientestres lneas por su salida estndar:

.1.3.6.1.4.100integer42

Para indicar que la peticin fue errnea, el programa no debe devolver nadapor su salida estndar. El agente generar entonces un mensaje de errorSNMP correspondiente a noSuchName.

EJECUTABLE -s OID TIPO VALOR

Esta ser la llamada usada para peticiones de tipo SET. TIPO puede contenerlos mismos valores que en la llamada anterior, e indica el tipo de objeto delVALOR especificado. Si el programa no devuelve nada, se asumir que laoperacin SET ha salido bien. Si no es as, tendr que devolver una de lascadenas de error not-writable o wrong-type, y el agente enviar elcorrespondiente mensaje de error al gestor que hizo la peticin.

Por defecto, la nica comunidad con permiso para este tipo de operaciones serprivate, o la segunda comunidad definida previamente en el archivo deconfiguracin en caso de no existir sta.

Para probar esta caracterstica, usaremos un script de ejemplo llamado passtest:pass .1.3.6.1.4.1.2021.255 /bin/sh /usr/local/bin/passtest

Ahora podremos hacer peticiones sobre el OID que maneja dicho script:# snmpwalk v2c c public averia .1.3.6.1.4.1.2021.255

pass_persist OID EJECUTABLE

Esta directiva es similar a la anterior, solo que en este caso el programa continuar suejecucin tras recibir la primera peticin.

20


Por convenio, en la inicializacin se pasar al programa la cadena "PING\n" por suentrada estndar, debiendo ste imprimir en su salida estndar la cadena "PONG\n".

Para peticiones GET y GETNEXT, el agente pasar al programa dos lneas, una con elcomando correspondiente (get o getnext) y otra con el OID correspondiente a lapeticin. El programa debe dar su salida en el mismo formato que para la directivaanterior. Para indicar que el programa no pudo procesar la peticin, deber devolver lacadena "NONE\n" a su salida estndar.

5. Recepcin de notificacionesSi antes hemos estudiamos las distintas posibilidades que ofrece el agente de NET-SNMP para elenvo de notificaciones, en este apartado abordaremos los aspectos de configuracin de lasherramientas que incluye NET-SNMP para la recepcin de stas notificaciones. Siguiendo lamisma filosofa, enfocaremos este estudio desde el punto de vista de la creacin de un fichero deconfiguracin persistente, para no tener que acudir a las pginas del manual o a este tutorial cadavez que queramos comenzar un estudio de las notificaciones recibidas en nuestro host.

5.1. Tipos de notificaciones

Este tema ya ha sido explicado en el punto 4.3.5 (envo de notificaciones) de este tutorial. Serecomienda la lectura de dicho punto antes de seguir con los siguientes apartados de estaseccin.

5.2. Funcionamiento del mecanismo de notificaciones

Los agentes SNMP tienen la capacidad de monitorizar objetos de la MIB y mandar notificacionescuando se den unas condiciones determinadas. Para que esto funcione, tiene que haber "alguien"escuchando en el otro extremo, es decir, debe haber una entidad capaz de recibir y procesardichas notificaciones. Esta entidad generalmente actuar como un servicio ms del sistema, y esla que vamos a configurar en esta seccin.

El uso de notificaciones mediante los protocolos SNMPv1 y v2c es sencillo, puesto que en estecaso el mensaje es mostrado tal cual al receptor. Sin embargo, cuando usamos SNMPv3 la cosacambia un poco, puesto que en esta versin se hace uso de la autenticacin mediante nombre deusuario y contrasea para la comunicacin con el proceso receptor de notificaciones. Por estotendremos que incluir previamente en la base de datos de usuarios a los usuarios que tendrnpermiso para enviarnos notificaciones, o el proceso receptor descartar silenciosamente lasnotificaciones entrantes.

Generalmente, un usuario queda identificado mediante su nombre (nombre de seguridad) y elidentificador (engineID) de la aplicacin receptora de la notificacin. Cuando usemos el resto deaplicaciones incluidas en el paquete NET-SNMP (snmpget, snmpwalk, etc), stas descubren elengineID remoto e introducen en la base de datos de usuarios asociada a este engineID elnombre de usuario, el engineID y el password. Esto facilitar el proceso de comunicacin enpeticiones futuras.

El mecanismo de informes para SNMPv3 opera con este mismo principio. Cuando enviamos uninforme mediante snmptrap usamos el engineID remoto, y la combinacin de este engineID conel nombre de seguridad que especifiquemos debe existir en la tabla de usuarios remota. Elprograma snmptrap detectar el engineID remoto y crear un mensaje SNMPv3 adecuado parael informe que estemos enviando. Entonces, lo nico que tendremos que hacer es crear unusuario en la aplicacin remota receptora de nuestros informes.

21


En cuanto al envo de traps SNMPv3, la cosa cambia un poco. La diferencia es que los trapsutilizan el engineID de la aplicacin local (la que enva el trap), en vez de el de la aplicacinremota (la receptora del trap). Esto quiere decir que, al crear usuarios en la aplicacin receptora,tendremos que crear uno para cada engineID desde el cual queramos recibir traps, aadiendouna directiva de este estilo en /var/lib/snmp/snmptrapd.conf:

createUser e nombre_usuario ...

5.3. El demonio snmptrapd

La aplicacin receptora de traps en el paquete NET-SNMP es el demonio snmptrapd. Se ejecutacomo un servicio ms del sistema, pudiendo detenerlo, ejecutarlo o reiniciarlo a nuestro antojo.Por defecto snmptrapd escucha en el puerto 162 de UDP.

5.3.1. Ficheros de configuracin

Tpicamente, el fichero de configuracin especfico para snmptrapd es/etc/snmp/snmptrapd.conf. Al igual que el agente, tambin leer las directivas de configuracingenerales para todas las aplicaciones de NET-SNMP (ubicadas en el fichero snmp.conf,), yguardar sus datos persistentes (como las directivas createUser explicadas ms abajo) en/var/lib/snmp/snmptrapd.conf. A continuacin pasamos a explicar las directivas que podemosincluir en el fichero especfico del demonio receptor de traps.

5.3.2. Ejecucin de programas para notificaciones entrantes traphandle OID|default PROGRAMA [ARGUMENTOS ...]

Esta directiva configura al demonio snmptrapd para que lance el programaespecificado cada vez que llegue una notificacin correspondiente a OID, o cualquiernotificacin cuyo OID no se corresponda con ninguna otra directiva traphandle siincluimos la palabra default en vez de un OID vlido. El programa recibir los detallesde la notificacin entrante a travs de su entrada estndar, con una entrada por lnea yen el siguiente formato:

HOSTNAME

El nombre del host que envi la notificacin.

IPADDRESS

La direccin IP del host que mand la notificacin.

VARBINDS

Una lista de variables que describen la notificacin y las variablesinvolucradas en sta. El primer elemento de la lnea (hasta el primer espacioen blanco) ser el OID, y el resto de la lnea ser su valor. El primer OIDdebe ser system.sysUpTime.0, el segundo ser snmpTrapOID.0 (quecontendr una cadena describiendo el tipo de notificacin recibida), y lossiguientes sern las variables asociadas a la notificacin. Para trapsSNMPv1, el ltimo OID ser snmpTrapEnterprise, con su valorcorrespondiente.

Vamos a usar un sencillo script para guardar las notificaciones entrantes en unarchivo, mediante la siguiente directiva:

traphandle default /usr/bin/traptofile file=/var/log/traptofile.log

22


5.3.3. Formateo de notificaciones

Mediante las siguientes directivas podremos aplicar un formato a las notificaciones entrantes.Puede usarse para especificar los campos de las notificaciones que mostraremos, e incluso elorden en que estos campos se mostrarn.

format1 formato

Esta directiva se usa para especificar el formato de los traps SNMPv1 entrantes.

Para mostrar la hora de llegada, el tipo de notificacin y el host remitente, usaramos:

format1 %02.2h:%02.2j TRAP%w.%q SNMPv1 desde %A\n format2 formato

Especifica el formato de los traps e informs SNMPv2 entrantes. Ntese que SNMPv3usa el mismo formato de notificacin que SNMPv2, con lo que tambin estaremosespecificando el formato de las notificaciones para esta versin.

Para usar el mismo formato que el descrito en la directiva anterior, usaramos:

format2 %02.2h:%02.2j TRAP%w.%q SNMPv2 desde %A\n5.3.4. Guardando notificaciones entrantes para consultas mediante SNMP

En las ltimas versiones de NET-SNMP, el demonio snmptrapd soporta la NOTIFICATION-LOG-MIB. Esto le sirve para registrar las ltimas notificaciones entrantes en las tablas nlmLogTable ynlmLogVariableTable, de forma que podremos acceder a esta informacin mediante comandoscomo snmptable y snmpwalk.

dontRetainLogs true

El uso de esta directiva significar la desactivacin de esta caracterstica en eldemonio, y por tanto la no retencin de traps entrantes en memoria.

5.3.5. Creacin de usuarios

La creacin de usuarios SNMPv3 en el demonio es idntica a la explicada para el agente. De igualforma, el uso recomendable de esta caracterstica es incluir las directivas de creacin de usuariosen el archivo /var/lib/snmp/snmptrapd.conf, con el fin de que no hallan archivos en el sistemaque contengan los nombres de usuarios y contraseas en claro. Los usuarios creados sernaquellos a los que permitiremos enviarnos notificaciones mediante el protocolo SNMPv3.

createUser nombre (MD5|SHA) auth_password [DES]El uso de esta directiva es idntico a su homnima para el fichero de configuracindel agente. Por ejemplo, para que truca reciba los traps SNMPv3 que averia lemande con el nombre de usuario manolito, hay que incluir esta directiva en suarchivo /var/lib/snmp/snmptrapd.conf:

createUser e 001122334455AABBCCDD manolito

Para la recepcin de informs, habra que aadir tambin:

createUser manolito

23


5.3.6. Reenvo de notificaciones

El demonio snmptrapd es capaz de reenviar ciertas notificaciones a otros hosts, lo cual es til siqueremos distribuir la gestin de estas notificaciones entre varias estaciones gestorasdependiendo de las variables involucradas en ellas.

forward OID|default DESTINOReenva las notificaciones relacionadas con el OID especificado al host DESTINO. Si envez de OID especificamos la palabra default, todas las notificaciones se reenviarn aDESTINO.

Si quisiramos reenviar los traps de tipo linkDown al host averia, usaramos:

forward .1.3.6.1.6.3.1.1.5.3 192.168.0.1

5.3.7. Directivas adicionales

ignoreAuthFailure (1 | yes | true | 0 | no | false)Ordena al demonio que ignore todas aquellas notificaciones entrantes referentes aerrores de autenticacin en el agente.

doNotLogTraps (1 | yes | true | 0 | no | false)Especificando yes, true 1, el demonio no guardar las notificaciones entrantes enningn archivo de log.

logOption CADENA 4

Especifica dnde se deben guardar las notificaciones entrantes. CADENA tiene elformato especificado en LOGGING OPTIONS.

Para registrar las notificaciones en la salida de error:

logOption e

Para registrar las notificaciones en la salida estndar:

logOption o

Para registrar las notificaciones va syslog, como demonio:

logOption s d

Para registrar las notificaciones en un archivo:

logOption f /var/log/traps_format.log

24


outputOption CADENA

Especifica las opciones para el formateo de la salida del demonio. El formato deCADENA puede especificarse mediante las opciones contenidas en OUTPUTOPTIONS.

Por ejemplo, si slo queremos que se muestren los nombres de los objetos y susvalores, usaramos:

outputOption s

Antes de usar esta directiva, el formato mostrado es el siguiente:

HOSTNAME: averia.localdomainIP_ADDRESS: 192.168.0.1

SNMPv2MIB::sysUpTime.0 = 0:0:11:44.56SNMPv2MIB::snmpTrapOID.0 = NETSNMPAGENTMIB::nsNotifyShutdownSNMPCOMMUNITYMIB::snmpTrapAddress.0 = 212.122.104.75SNMPCOMMUNITYMIB::snmpTrapCommunity.0 = private

Al incluirla en el archivo de configuracin y reiniciar el demonio, el formato de trapquedara as:

HOSTNAME: averia.localdomainIP_ADDRESS: UDP: [192.168.0.1]:34046sysUpTimeInstance = 0:0:04:04.69snmpTrapOID.0 = nsNotifyShutdownsnmpTrapAddress.0 = 212.122.104.75snmpTrapCommunity.0 = private

printEventNumbers (1 | 0)Especifica si se mostrarn los nmeros de evento en notificaciones de tipo alarma(cuando la alarma se dispare, cuando se desactive, etc).

printEventNumbers 1

doNotFork (1 | 0)Mediante esta directiva podemos ordenar al demonio que permanezca asociado alshell desde el cual se le llam.

doNotFork 0

pidFile CADENA

Especifica el archivo en el que queremos guardar el identificador de proceso para eldemonio.

pidFile /var/lib/snmp/snmptrapd.PID

25

Documents

Comprendiendo El Protocolo SNMP