SNMP, un protocolo de gestión de red «¿simple?»
Supongamos que queremos monitorizar servidores Linux vía SNMP desde un servidor central. Por ejemplo, uno de los programas más utilizados para esta labor, es CACTI, que nos permite graficar y analizar en el tiempo los datos obtenidos. Pero no vamos a abordar aquí cómo instalar CACTI, podría ser cualquier programa, simplemente se trata de obtener datos de una máquina vía SNMP.
Para hacerlo, el servicio snmp (demonio snmpd) viene normalmente instalado en las distribuciones Linux, pero desactivado por defecto. La configuración de este servicio SNMP se encuentra en el archivo:
/etc/snmp/snmpd.conf
Para no perder la configuración por defecto se recomienda salvar dicho fichero en otro llamado, por ejemplo snmpd.conf.OLD
Este fichero debe tener la forma siguiente:
#Lista de Control de Acceso(ACL)
com2sec local 127.0.0.1/32 MyPwd
com2sec nb_host IPServidor/32 MyPwd
#Se asigna ACL al grupo de Escritura
group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
#Se asigna ACL al grupo de Lectura
group MyROGroup v1 nb_host
group MyROGroup v2c nb_host
group MyROGroup usm nb_host
#Ramas MIB que se permiten ver
view all included .1 80
# Establece permisos de lectura y escritura
## group context sec.model sec.level prefix read write notif
access MyROGroup «» any noauth exact all none none
access MyRWGroup «» any noauth exact all all all
En la Lista de Control de Acceso (ACL) está nuestro propio host 127.0.0.1 y debemos añadir una línea con la sintaxis “com2sec <nb_host> <IP_host>/32 <Password> para cada host desde el que queramos realizar consultas remotas vía SNMP. Podríamos también asociar un nombre a un grupo de IPs, y de servidores por lo tanto. Lo que definimos aquí es Servidor (o grupo de servidores) y Contraseña SNMP asociada.
Después podemos configurar, mediante la sintaxis de “group”, qué servidores de los anteriores pertenecen a los grupos SNMP. Normalmente los grupos tendrán permisos de lectura o de lectura/escritura. En el ejemplo se crea el grupo MyRWGroup para que sea el grupo de permisos de lectura y escritura, y a él se añade el host local para SNMP versión 1, 2 y usm (v3). A continuación se crea el grupo MyROGroup, que tendrá permiso de sólo lectura y a él se añade el host nb_host, para que realice consultas SNMP
En las últimas sentencias “access” establecemos que MyROGroup efectivamente tenga permisos de sólo lectura y no reciba notificaciones, y que MyRWGroup sea el grupo de lectura/escritura, que recibirá notificaciones SNMP.
Con todo esto, observamos que es una práctica habitual, por seguridad, ya que SNMP es un protocolo muy débil desde el punto de vista de la seguridad, que el servidor que vaya realizar las consultas SNMP sólo pueda leer del servidor, ya que de lo contrario, podría alterar parámetros del sistema operativo. En el caso anterior, sólo está en el grupo de lectura/escritura el propio host.
En la última sentencia “view” las Ramas MIB que se permiten ver son todas, aunque se puede acortar la cantidad de cosas y datos que se puedan extraer vía SNMP.
Una vez guardado este archivo, para que los cambios tengan efecto, es necesario reiniciar el servicio, para lo que ejecutamos los comandos:
service snmpd stop
service snmpd start
Ya deberíamos poder obtener datos vía SNMP de este servidor. Sólo desde el servidor nb_host del ejemplo, por supuesto.
Ejecutaríamos desde él, por ejemplo, snmpwalk, que nos dice las MIBs que podemos consultar en el host remoto: snmpwalk –c <password> -v <version SNMP> <host> <MIBs Type>
./snmpwalk -c xxxxxxxxxx -v 2c host_snmp system
Este ejemplo se ha realizado en SNMP versión 2, es decir, un servidor pertenece a un grupo (o community) y conociendo la Password del grupo puede acceder al host SNMP con los permisos del grupo, y lo hace completamente en claro (público), sin cifrar esta comunicación.
Actualmente ya se emplea usm (User Security Model) o SNMP versión 3. En esta versión se añade el concepto de usuario, es decir, ya no está abierto SNMP para un servidor, sino que pueden crearse varios usuarios con diferentes permisos y contraseñas (autenticación, authkey) y la comunicación es privada (encriptación, decryptkey).
También sería interesante ver cosas como configurar SNMP en switches CISCO, configurar un servidor CACTI, o las configuraciones SNMPv3.
principia technologica 
Buenas tardes, una consulta (si es posible)
Tengo configurado snmp y creo un usuario con MD5 y DES auten/cifrado y funciona OK:
/var/lib/net-snmp/snmpd.conf:
createUser UserPrueba MD5 12345678 DES 87654321
/etc/snmp/snmpd.conf:
rouser UserPrueba auth
service snmp start
Test:
# snmpwalk -v3 localhost -a MD5 -A 12345678 -x DES -X 87654321 -l authPriv -u UserPrueba DISMAN-EVENT-MIB::sysUpTimeInstance
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12996) 0:02:09.96
Pero si lo creo con SHA y AES NO me funciona:
/var/lib/net-snmp/snmpd.conf:
createUser UserPrueba SHA 12345678 AES 87654321
/etc/snmp/snmpd.conf:
rouser UserPrueba auth
service snmpd start
Iniciando snmpd: [ OK ]
# snmpwalk -v3 localhost -a SHA -A 12345678 -x AES -X 87654321 -l authPriv -u UserPrueba DISMAN-EVENT-MIB::sysUpTimeInstance
No log handling enabled – turning on stderr logging
snmpwalk: Authentication failure (incorrect password, community or key)
¿Que puede pasar?
Tengo:
Centos 6.3
NET-SNMP v 5.5
Muchas gracias de antemano
Saludos
Domingo
Hola Domingo, como te está dando password incorrecto, sólo puedo recomendarte que metas comillas a las passwords, tanto cuando creas el usuario como cuando recorres el MIB:
createUser USERNAME SHA «PASSWORD»
A veces los sistemas operativos se hacen un lío con eso. Espero que te sirva.
Saludos y gracias por leer principiatechnologica.com
Hola, muchas gracias por la respuesta. En principio ese problema ya le tengo solucionado, era culpa mia, modificaba las claves pero sin «reiniciar» previamente snmp con claves vacias, es decir, cada vez que le quiero cambiar la clave, debo de parar snmp, quitar todas las claves, reiniciar, parar de nuevo y ya poner las nuevas claves y reiniciar de nuevo. (uffff, espero haberme explicado)
Ahora me pasa algo más curioso:
Si creo un usuario (auth o priv) y activo envio de traps sin tener ningun monitor funciona todo fenomenal:
rouser UserPrueba priv
createUser UserPrueba SHA 12345678 AES 87654321
agentSecName UserPrueba
Pero en cuanto meto la directiva «monitor» ya no me funciona el usuario/clave y si encima es «priv» me da «failed to run mteTrigger query». P.e. añado estas directivas y ya me deja de funcionar :
monitor -r 60 -e linkUpTrap «Generate linkUp» ifOperStatus != 2
monitor -r 60 -e linkDownTrap «Generate linkDown» ifOperStatus == 2
Seguro que de nuevo debo estar haciendo algo mal pero no se me ocurre que puede ser.
De nuevo, muchas gracias de antemano
Saludos
Domingo