Tutorial Net SNMP PDF
Tutorial Net SNMP PDF
Tutorial Net SNMP PDF
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Tutorial de NET-SNMP
2006 © Luis Hernández Acosta
INDICE
1. Sobre este tutorial
2. ¿Qué es SNMP?
2.1. SNMPv1
2.2. SNMPv2
2.3. SNMPv3
3. ¿Qué es NET-SNMP?
5. Recepción de notificaciones
5.1. Tipos de notificaciones
5.2. Funcionamiento del mecanismo de notificaciones
5.3. El demonio snmptrapd
5.3.1. Ficheros de configuración
5.3.2. Ejecución de programas para notificaciones entrantes
5.3.3. Formateo de notificaciones
5.3.4. Guardando notificaciones entrantes para consultas mediante SNMP
5.3.5. Creación de usuarios
5.3.6. Reenvío de notificaciones
5.3.7. Directivas adicionales
1
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
1. Sobre este tutorial
Este tutorial pretende ser una guía rápida de configuración para los demonios incluidos en el
paquete de gestión de red NET-SNMP (snmpd y snmptrapd). No es una guía de utilidades para
línea de comandos, ni tampoco pretende entrar en aspectos demasiado teóricos sobre el
funcionamiento interno del protocolo de gestión de red SNMP. Solamente es un documento que
puede servir tanto para configurar los aspectos más básicos como los más avanzados del agente
(snmpd) y el demonio receptor de notificaciones (snmptrapd).
El escenario de las pruebas ha sido una pequeña red local, constituida por los siguientes hosts:
– Un servidor que actúa como pasarela de red, ejecutando una distribución Debian, cuyo
nombre en la red local es averia. Este es el host en el que se ejecuta el agente SNMP.
– Un cliente de red ejecutando una distribución 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 extendido
que trabaja en el nivel de aplicación. Mediante SNMP podemos realizar tareas de monitorización
de red, configuración de dispositivos, detección de problemas y otras muchas cosas más.
Para gestionar un dispositivo mediante SNMP, éste debe tener un agente que gestione la
información contenida en la MIB-II ( Management Information Base). El protocolo funciona
mediante un mecanismo de petición-respuesta, es decir, nosotros mandamos una petición u orden
al agente que gestiona un dispositivo concreto y éste nos responde con la información requerida o
el resultado de la orden, o con un mensaje de error si nuestra petición fue incorrecta.
Actualmente existen tres versiones de este protocolo: SNMPv1, SNMPv2 y SNMPv3; cada una
con sus propias características y limitaciones. Nuestro objetivo principal será abordar las
diferencias entre estas tres versiones respecto a la autenticación de las peticiones y órdenes.
2.1. SNMPv1
Cuando se utiliza SNMPv1, el agente emplea un sencillo sistema de autenticación para determinar
qué gestor puede acceder a qué variables de la MIB. Este esquema implica la especificación de
unas determinadas políticas de acceso, relacionadas con los conceptos de comunidad, modo de
acceso y vista de la MIB. Una comunidad es un conjunto de hosts relacionados mediante un
nombre de comunidad, que debe ser incluido en la petición. El modo de acceso especifica
los 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 más subárboles de la MIB a los que
una determinada comunidad puede acceder.
Cuando el agente recibe una petición, verifica el nombre de comunidad junto con la IP del host
desde el que se hizo la petición para determinar que el host realmente pertenezca a esa
comunidad. Si esta verificación devuelve un resultado positivo, entonces comprueba que la
comunidad tenga acceso a las variables de la MIB solicitadas en la petición. Si esto es correcto, el
agente responderá a la petición. Si no, devolverá el mensaje de error correspondiente al host
peticionario.
En esta versión también se define la estructura básica que debe tener la MIB, incluyendo los
identificadores de objeto (tanto numéricos como textuales) de los objetos y tablas de uso más
común, como ifTable, tcpConnTable, ipAddrTable, etc. Además, se definen tres operaciones
básicas para el acceso a la información de gestión contenida en la MIB: Get, GetNext y Set. Se
define también la operación Trap para el envío de notificaciones.
2
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
2.2. SNMPv2
SNMPv2 es una extensión de SNMPv1. La abstracción de SNMPv2 que permite el uso de los
mismos elementos descritos para SNMPv1, es decir, los conceptos de comunidad, vista de la
MIB y modo de acceso, es llamada SNMPv2c (Community-based SNMPv2), y es la que el agente
de NET-SNMP implementa.
El formato de la PDU (mensaje) es el mismo, solo que se usa un nuevo número de versión. En
cuanto a las operaciones de acceso a la MIB, además de las definidas en SNMPv1, esta versión
define dos nuevas: GetBulk e Inform. GetBulk se usa para obtener de forma eficiente grandes
cantidades de datos, e Inform se usa para el envío de notificaciones con confirmación por parte
del receptor.
En cuanto a la MIB, en esta versión se definen nuevos tipos de objetos para mejorar la semántica.
2.3. SNMPv3
3. ¿Qué es NET-SNMP?
NET-SNMP es un conjunto de aplicaciones usado para implementar el protocolo SNMP usando
IPv4 e IPv6. Incluye:
3
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– Una biblioteca para el desarrollo de nuevas aplicaciones SNMP, con APIs para C y Perl.
snmpd es un agente SNMP que escucha en el puerto 161 de UDP (por defecto), esperando la
llegada de peticiones desde algún software de gestión SNMP. Cuando recibe una petición,
recopila la información y/o lleva a cabo las operaciones solicitadas, devolviendo la información
correspondiente al emisor de la petición.
El agente snmpd se ejecuta como demonio, permaneciendo en segundo plano durante toda su
ejecución. Una vez instalado el paquete NET-SNMP, el agente se ejecutará al iniciar nuestro host
mediante el sistema de servicios estándar de GNU/Linux. Para iniciarlo, pararlo o recargarlo
manualmente usaremos el comando:
# /etc/init.d/snmpd {start|stop|restart|reload|forcereload}
usando una opción u otra dependiendo de lo que queramos hacer. En su arranque, buscará su
archivo de configuración (/etc/snmp/snmpd.conf). Dicho archivo describe el comportamiento del
agente durante la ejecución, aunque no es imprescindible para que el agente funcione y responda
a peticiones, puesto que dispone de una configuración por defecto.
A pesar de que podemos arrancar el agente incluyendo varias opciones en la línea de comandos
(ejecutar snmpd --help para una descripción más precisa), llevaremos a cabo la configuración
mediante el fichero snmpd.conf, puesto que de esta forma las opciones que escojamos quedarán
grabadas de forma persistente para posteriores ejecuciones.
4
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
El archivo snmpd.conf es específico para el agente, y contiene una serie de directivas que
describirán su comportamiento en diversos ámbitos, y es el que vamos a construir poco a poco en
este punto del tutorial. En los siguientes apartados pasa a explicarse cada uno de los ámbitos
posibles de configuración y las directivas correspondientes que pueden usarse.
Algunas de las siguientes directivas modifican el valor de varios objetos de la MIB, y otras sólo
sirven para la propia configuración del agente. Nótese que, en caso de darles un valor en el
archivo de configuración del agente, se convertirán en objetos de sólo lectura (obviamente,
aquellos que sean de lectura y escritura inicialmente) y, por tanto, no podremos cambiar sus
valores mediante el comando snmpset.
– syslocation CADENA
– syscontact CADENA
– sysname CADENA
sysname "averia.labpracts.dit.ulpgc.es"
– sysservices NUMERO
sysservices 72
5
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– sysdescr CADENA
– sysobjectid OID
En nuestro caso lo dejaremos tal cual está, puesto que en este punto no tenemos
ningún subárbol asignado dentro de enterprises.
– agentaddress [<especificadorDeTransporte>:]<direcciónDeTransporte>[,...]
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 quisiéramos que el agente escuchara en el puerto 161 de TCP y UDP
para todas las interfaces, y en el puerto 9161 en la interfaz de loopback (lo),
incluiríamos la siguiente directiva:
agentaddress 161,tcp:161,localhost:9161
– agentgroup IDgrupo
Esta directiva provoca que el agente cambie su identificador de grupo después de abrir
el puerto en el que escucha. IDgrupo puede ser el nombre de un grupo o su
identificador numérico.
agentgroup jordi
– agentuser IDusuario
Si queremos que nuestro agente se ejecute con el ID del usuario jordi, incluiremos:
agentuser jordi
6
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– interface NOMBRE TIPO VELOCIDAD
– ignoredisk CADENA
Cuando el agente escanea todos los dispositivos de disco disponibles, puede que se
bloqueé, pudiendo producir un timeout cuando inspeccionemos la tabla de dispositivos
mediante snmpwalk. Si esto ocurre, podemos usar esta directiva para forzar al agente
a que no escaneé ciertos discos, pudiendo incluirla varias veces en el archivo de
configuración. El formato de CADENA puede seguir la sintaxis del “bourne shell”.
ignoredisk /dev/hda3
– storageUseNFS NUMERO
Cuando NUMERO=1, esta directiva causa que todos los sistemas de archivos NFS
sean 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, aparecerán como "Fixed Disks".
storageUseNFS 1
Esta directiva permite sobreescribir un OID con un valor distinto, e incluso con un tipo
distinto. Por ejemplo, podríamos sobreescribir el valor y el tipo de system.sysDescr
mediante la siguiente orden:
Usando las siguientes directivas podemos configurar los parámetros necesarios para controlar el
acceso a nuestra MIB. Para SNMPv1 y SNMPv2c aplicaremos los conceptos de comunidad, vista
y modo de acceso explicados en este tutorial. Este modo de acceso a la MIB es el llamado Modelo
de 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 un
conjunto de hosts que pertenecerán a dicha comunidad. Después, asociaremos estos nombres de
seguridad con nombres de grupos para, finalmente, definir vistas y asociar cada una de ellas
con un grupo de los definidos anteriormente.
7
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– com2sec NOMBRE FUENTE COMUNIDAD
Crearemos dos comunidades, una con acceso desde toda la red y otra con acceso sólo
desde la red local:
Esta directiva es la versión de la anterior para direcciones IPv6. Sólo será válida si
especificamos UDPIPv6 como dominio de transporte en la compilación.
Vamos a crear dos grupos, asociados a los nombres de seguridad que hemos
especificado en la directiva anterior. Cada grupo podrá acceder mediante peticiones
SNMPv1 o SNMPv2:
Define los accesos posibles de los grupos definidos anteriormente a las vistas que
definiremos con la directiva view.
8
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Definiremos los siguientes accesos para los grupos creados anteriormente: el grupo
public tendrá acceso de sólo lectura a toda la MIB y el grupo private tendrá acceso de
lectura a toda la MIB, y de escritura a la vista parte, definida en la siguiente directiva.
Esta directiva nos permite definir vistas de la MIB, que no son más que subconjuntos
de ésta. Estos subconjuntos pueden estar formados por una o más ramas del árbol de
la MIB, e incluso por la MIB entera. A menos que creemos vistas con una sola rama del
árbol de la MIB, tendremos que usar varias de estas directivas para crear una nueva
vista a nuestro gusto.
Para nuestro ejemplo, crearemos dos vistas: Una vista todo que cubrirá toda la MIB y
una vista parte que cubrirá toda la MIB, exceptuando el árbol de RMON.
El siguiente ejemplo genérico nos ilustra sobre cómo conjuntar el uso de los nombres de
seguridad, de comunidad y de grupo:
9
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Disponemos también de una serie de directivas más fáciles de usar, pero que son menos flexibles
si pretendemos crear configuraciones personalizadas. Estas directivas son las siguientes:
Crea una comunidad con permisos de lectura sobre el subárbol especificado por OID,
cuyos miembros serán los hosts especificados por FUENTE.
Crearemos una comunidad con acceso de sólo lectura sobre el árbol interfaces
mediante la siguiente directiva:
Idéntica 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, y
con acceso solamente desde el localhost, usaríamos:
Estas dos directivas son las análogas a las dos anteriores para el dominio de
transporte UDPIPv6.
Usando estas directivas podremos crear usuarios que puedan comunicarse con el agente
mediante el protocolo SNMPv3 que, a diferencia de las dos anteriores versiones, soporta un modo
de acceso basado en usuarios y contraseñas.
– engineID CADENA
Con esta directiva daremos un identificador al agente, llamado engineID, que éste
usará para poder responder a mensajes SNMPv3. Si no le damos ningún valor, se
calculará en base a un número aleatorio junto con la hora actual en segundos. El valor
de CADENA puede ser cualquier combinación de dígitos hexadecimales, como por
ejemplo:
engineID 001122334455AABBCCDD
10
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Vamos a crear un usuario con acceso de sólo lectura a toda la MIB, sin necesidad de
autenticación en el acceso:
NOTA: para activar este usuario, tenemos que incluir una directiva createUser en el
archivo /var/lib/snmp/snmpd.conf, aunque no asignemos ninguna contraseña al
usuario, de la siguiente forma:
createUser manolito
Crearemos un usuario con acceso de lectura y escritura sobre el grupo system, y con
nivel de autenticación auth:
Crea un nuevo usuario capaz de comunicarse con el agente mediante SNMPv3. Este
nombre de usuario debe haberse definido previamente mediante una directiva rouser o
rwuser.
Cuando asociemos estos usuarios con nombres de grupo para asociarles vistas, el
nombre especificado aquí es el que debe incluirse como nombre de seguridad en la
directiva group descrita en el apartado anterior. Podemos escoger entre los algoritmos
MD5 y SHA para los mensajes autenticados, si bien necesitamos tener instalado el
paquete OpenSSL para usar SHA. Para los mensajes encriptados sólo podremos usar
DES.
11
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Al usar esta directiva debemos tener en cuenta una cuestión: si la introducimos en
nuestro archivo /etc/snmp/snmpd.conf cualquier usuario con permiso de lectura sobre
este archivo podría leer sin problemas los nombres de usuario y las contraseñas, con
lo que esta nueva política de acceso no nos serviría para mucho. En lugar de esto,
tenemos que incluirlas en el archivo /var/lib/snmp/snmpd.conf y justo después
reiniciar el agente. Esto causará que el agente vuelva a leer este archivo, creando los
usuarios y borrando las líneas correspondientes (eliminando así las contraseñas del
disco duro), para después guardar en este mismo archivo las claves que se derivan de
estas contraseñas.
Ejemplo:
# /etc/init.d/snmpd stop
# /etc/init.d/snmpd start.
usmUser 1 3
0x80001f88043030313132323333343435354141424243434444
0x616c6672656469746f00 0x616c6672656469746f00 NULL .1.3.6.1
Un trap es una notificación no confirmada por el receptor. Esto hace que necesitemos un
mecanismo para detectar la pérdida de traps en la red si las notificaciones que enviamos son de
carácter crítico.
Un inform es una notificación que requiere confirmación por parte del receptor, lo cual la hace
más adecuada para situaciones críticas. Sin embargo, estas notificaciones no fueron incluidas en
el protocolo hasta la versión SNMPv2c, con lo que no serán permitidas en agentes que soporten
solamente la versión SNMPv1.
12
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– authtrapenable NUMERO
authtrapenable 1
– trapcommunity CADENA
Especifica la comunidad por defecto que será usada al enviar notificaciones. Esta
directiva debe aparecer en el archivo de configuración antes que las cuatro siguientes.
En nuestra configuración, usaremos la comunidad por defecto private:
trapcommunity private
Especifica el host (y opcionalmente el puerto) que recibirá los traps SNMPv1 enviados.
Podemos especificar también la comunidad a usar en el envío, aunque si no lo
hacemos se usará la comunidad por defecto. Si usamos esta directiva, el agente
enviará traps también en los errores de autenticación. Puede aparecer varias veces
para especificar múltiples destinos.
Esta directiva es idéntica a la anterior, solo que trabaja con los traps de SNMPv2c.
Vamos a usar estas tres últimas directivas para mandar todo tipo de notificaciones al
host 192.168.0.3:
trapsink 192.168.0.3
trap2sink 192.168.0.3
informsink 192.168.0.3
13
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Según la página del manual, este soporte no ha sido probado exhaustivamente y,
además, se sabe que no está completo. Sin embargo, las directivas aquí explicadas
deberían funcionar correctamente.
Si el agente fue compilado con soporte para DISMAN-EVENT-MIB, podremos usar las
siguientes directivas para monitorizar objetos y mandar notificaciones referentes a
ellos.
Enviaremos los traps SNMPv3, usando el nombre de usuario manolito, con nivel de
autenticación noAuthNoPriv, haciendo uso de la siguiente directiva:
– agentSecName NOMBRE
agentSecName manolito
-t
-r FRECUENCIA
-u NOMBRE_SEGURIDAD
14
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
-o OID
-e NOMBRE_EVENTO
Esta directiva creará un evento de notificación, que será disparado mediante una
directiva monitor que se refiera a él con su opción -e. NOTIFICACION debe ser el OID
de una notificación, pudiendo incluirse OIDs adicionales, y será el tipo de notificación
que se enviará. Por defecto se incluirá al OID el sufijo de la columna u objeto
monitorizado, a menos que incluyamos la opción -w. Por ejemplo, si monitorizamos la
tabla ifTable y queremos incluir el valor de ifDescr para las filas que produzcan
notificaciones, entonces no incluiremos la opción –w y se añadirá automáticamente el
campo INDEX. En cambio, si monitorizamos el objeto sysContact.0, ningún sufijo
debe ser añadido y entonces sí que usaremos dicha opción.
Asociaremos a la última directiva monitor del punto anterior un evento para el envío de
un trap de tipo linkDown mediante la siguiente directiva:
– linkUpDownNotifications yes
Esta directiva hará que el agente monitorice la tabla de interfaces (ifTable) para
determinar cuándo una interfaz es activada o desactivada. Cuando esto pase, se
lanzarán notificaciones linkUp o linkDown respectivamente.
linkUpDownNotifications yes
15
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– defaultMonitors yes
defaultMonitors yes
.ID.1 index
Es un índice entero. Para escalares, siempre tiene el valor 1. Para tablas, es un índice
de filas.
.ID.2 name
.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 a
uno.
.ID.102 errFix
Este objeto actúa como un disparador. Si esta entrada vale 1, se ejecutará un programa
pasándole el nombre de la entrada de la tabla como argumento. El programa se
especifica en el campo errFixCmd.
Este convenio permite al agente examinar fácilmente ciertas circunstancias concretas poniendo el
valor de ID correspondiente a la sección que se quiera monitorizar, y escaneando el valor de
.ID.100 en busca de errores.
16
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Las siguientes directivas pueden usarse en este apartado:
proc "amule" 1 1
Esta directiva registra un comando que sabrá cómo arreglar los errores ocurridos con
el proceso especificado por NOMBRE, obteniendo la información de éste de la tabla
enterprises.ucdavis.procTable. Cuando hagamos un snmpset al campo prErrFix
correspondiente, poniéndolo a 1, se ejecutará el comando registrado.
Probaremos esta característica haciendo que el agente ejecute un script que registre
en un log la fecha y la hora de su ejecución:
17
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
A partir de que reiniciemos el agente, las peticiones de lectura sobre ese OID
devolverán lo siguiente:
Trabaja igual que la directiva procfix, solo que en esta ocasión el agente monitorizará
los valores de la tabla enterprises.ucdavis.extTable, actuando cuando el campo
extErrFix correspondiente esté a 1.
disk / 100000
– includeAllDisks PORCENT_MIN%
Añade todos los discos que puedan ser encontrados en el sistema mediante las
llamadas al sistema setmntent y getmntent, o fopen y getmntent, o setfsent y
getfsent. Si ninguna de estas llamadas se encuentra en el sistema, añadirá la partición
raíz usando la llamada statfs. Los parámetros especificados mediante la directiva disk
sobreescriben a los de esta directiva. Hay que tener en cuenta que sólo incluirá los
discos que ya estén montados cuando el agente se inicie.
Monitorizaremos los discos duros para comprobar que les quede, al menos, un 10% de
espacio libre:
includeAllDisks 10%
18
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Vamos a establecer las medias máximas en los siguientes valores:
load 1 2 4
Monitoriza el tamaño de ARCHIVO comprobando que no crezca más allá del tamaño
máximo especificado en KB, pero sin reportar errores al respecto. TAMAÑO_MAX es
infinito por defecto.
Mediante el soporte para proxy del agente podemos hacer que todas las peticiones sobre un OID
queden delegadas a un host distinto.
Cede el control del árbol de la MIB especificado por OID al HOST descrito. Si se
incluye NOMBRE_CONTEXTO, asignará el árbol a un nombre de contexto particular
dentro del agente local. La forma más adecuada de hacer solicitudes a múltiples
agentes a través de un sólo proxy sería asignar a cada agente remoto un nombre de
contexto. Entonces, podríamos usar snmpwalk -n nombreContexto1 para preguntar a
un agente remoto, y snmpwalk -n nombreContexto2 para preguntar a otro. En este
aspecto sólo se soporta la versión SNMPv3 para las peticiones, puesto que los
nombres de contexto no están soportados para las versiones 1 y 2.
Podemos también mapear el OID local a un nuevo OID remoto, especificado por
OID_REMOTO. Para la autenticación en las consultas, debemos usar los argumentos
correctos en ARGS_SNMPCMD.
Ejemplos:
Podemos mapear el grupo system del host truca en el árbol experimental de la MIB de
averia, mediante la siguiente directiva:
Así, haciendo uso del nombre de contexto truca1, podemos consultar el subárbol
creado de la siguiente manera:
Podemos también hacer que no sea necesario añadir el nombre de contexto a las
consultas haciendo uso de una conexión SNMPv3 con truca, con la siguiente directiva:
19
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
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 al
programa que queramos.
Esta directiva es la que usaremos para este fin. El programa especificado por
EJECUTABLE puede ser llamado de las siguientes formas:
EJECUTABLE -g OID
EJECUTABLE -n OID
.1.3.6.1.4.100
integer
42
Para indicar que la petición fue errónea, el programa no debe devolver nada
por su salida estándar. El agente generará entonces un mensaje de error
SNMP correspondiente a noSuchName.
Esta será la llamada usada para peticiones de tipo SET. TIPO puede contener
los mismos valores que en la llamada anterior, e indica el tipo de objeto del
VALOR especificado. Si el programa no devuelve nada, se asumirá que la
operación SET ha salido bien. Si no es así, tendrá que devolver una de las
cadenas de error not-writable o wrong-type, y el agente enviará el
correspondiente mensaje de error al gestor que hizo la petición.
Por defecto, la única comunidad con permiso para este tipo de operaciones será
private, o la segunda comunidad definida previamente en el archivo de
configuración en caso de no existir ésta.
Ahora podremos hacer peticiones sobre el OID que maneja dicho script:
Esta directiva es similar a la anterior, solo que en este caso el programa continuará su
ejecución tras recibir la primera petición.
20
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
Por convenio, en la inicialización se pasará al programa la cadena "PING\n" por su
entrada estándar, debiendo éste imprimir en su salida estándar la cadena "PONG\n".
Para peticiones GET y GETNEXT, el agente pasará al programa dos líneas, una con el
comando correspondiente (get o getnext) y otra con el OID correspondiente a la
petición. El programa debe dar su salida en el mismo formato que para la directiva
anterior. Para indicar que el programa no pudo procesar la petición, deberá devolver la
cadena "NONE\n" a su salida estándar.
5. Recepción de notificaciones
Si antes hemos estudiamos las distintas posibilidades que ofrece el agente de NET-SNMP para el
envío de notificaciones, en este apartado abordaremos los aspectos de configuración de las
herramientas que incluye NET-SNMP para la recepción de éstas notificaciones. Siguiendo la
misma filosofía, enfocaremos este estudio desde el punto de vista de la creación de un fichero de
configuración persistente, para no tener que acudir a las páginas del manual o a este tutorial cada
vez que queramos comenzar un estudio de las notificaciones recibidas en nuestro host.
Este tema ya ha sido explicado en el punto 4.3.5 (envío de notificaciones) de este tutorial. Se
recomienda la lectura de dicho punto antes de seguir con los siguientes apartados de esta
sección.
Los agentes SNMP tienen la capacidad de monitorizar objetos de la MIB y mandar notificaciones
cuando 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 procesar
dichas notificaciones. Esta entidad generalmente actuará como un servicio más del sistema, y es
la que vamos a configurar en esta sección.
El uso de notificaciones mediante los protocolos SNMPv1 y v2c es sencillo, puesto que en este
caso el mensaje es mostrado tal cual al receptor. Sin embargo, cuando usamos SNMPv3 la cosa
cambia un poco, puesto que en esta versión se hace uso de la autenticación mediante nombre de
usuario y contraseña para la comunicación con el proceso receptor de notificaciones. Por esto
tendremos que incluir previamente en la base de datos de usuarios a los usuarios que tendrán
permiso para enviarnos notificaciones, o el proceso receptor descartará silenciosamente las
notificaciones entrantes.
El mecanismo de informes para SNMPv3 opera con este mismo principio. Cuando enviamos un
informe mediante snmptrap usamos el engineID remoto, y la combinación de este engineID con
el nombre de seguridad que especifiquemos debe existir en la tabla de usuarios remota. El
programa snmptrap detectará el engineID remoto y creará un mensaje SNMPv3 adecuado para
el informe que estemos enviando. Entonces, lo único que tendremos que hacer es crear un
usuario en la aplicación remota receptora de nuestros informes.
21
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
En cuanto al envío de traps SNMPv3, la cosa cambia un poco. La diferencia es que los traps
utilizan el engineID de la aplicación local (la que envía el trap), en vez de el de la aplicación
remota (la receptora del trap). Esto quiere decir que, al crear usuarios en la aplicación receptora,
tendremos que crear uno para cada engineID desde el cual queramos recibir traps, añadiendo
una directiva de este estilo en /var/lib/snmp/snmptrapd.conf:
HOSTNAME
IPADDRESS
VARBINDS
22
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
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 el
orden en que estos campos se mostrarán.
– format1 formato
Esta directiva se usa para especificar el formato de los traps SNMPv1 entrantes.
– format2 formato
Especifica el formato de los traps e informs SNMPv2 entrantes. Nótese que SNMPv3
usa el mismo formato de notificación que SNMPv2, con lo que también estaremos
especificando el formato de las notificaciones para esta versión.
– dontRetainLogs true
createUser manolito
23
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
5.3.6. Reenvío de notificaciones
El demonio snmptrapd es capaz de reenviar ciertas notificaciones a otros hosts, lo cual es útil si
queremos distribuir la gestión de estas notificaciones entre varias estaciones gestoras
dependiendo de las variables involucradas en ellas.
– logOption CADENA 4
logOption e
logOption o
logOption s d
logOption f /var/log/traps_format.log
24
Protocolos y Servicios
Esc. Técnica Superior de Ingenieros de Telecomunicación Univ. de Las Palmas de Gran Canaria
– outputOption CADENA
Por ejemplo, si sólo queremos que se muestren los nombres de los objetos y sus
valores, usaríamos:
outputOption s
HOSTNAME: averia.localdomain
IP_ADDRESS: 192.168.0.1
SNMPv2MIB::sysUpTime.0 = 0:0:11:44.56
SNMPv2MIB::snmpTrapOID.0 = NETSNMPAGENT
MIB::nsNotifyShutdown
SNMPCOMMUNITYMIB::snmpTrapAddress.0 = 212.122.104.75
SNMPCOMMUNITYMIB::snmpTrapCommunity.0 = private
HOSTNAME: averia.localdomain
IP_ADDRESS: UDP: [192.168.0.1]:34046
sysUpTimeInstance = 0:0:04:04.69
snmpTrapOID.0 = nsNotifyShutdown
snmpTrapAddress.0 = 212.122.104.75
snmpTrapCommunity.0 = private
– printEventNumbers (1 | 0)
printEventNumbers 1
– doNotFork (1 | 0)
doNotFork 0
– pidFile CADENA
pidFile /var/lib/snmp/snmptrapd.PID
25