Implantación y monitorización con SNMP

Implantación y monitorización
con SNMP
LEANDRO TERRÉS ROCAMORA
SERVICIOS DE RED E INTERNET
CURSO 2014/2015
2º ASIR
Última actualización: 2 de febrero de 2015 20:00:15

Implementación y monitorización con SNMP Curso 2014/2015 IES Las Espeñetas
Índice de contenido
1. INTRODUCCIÓN...........................................................................3
2. HISTORIA.....................................................................................4
3. EL PROTOCOLO SNMP.................................................................4
3.1 Base de información de administración SNMP (MIB)...................4
3.2 Detalles del Protocolo...................................................................6
3.3 Mensajes SNMP.............................................................................6
3.3.1. GetRequest...................................................................................................7
3.3.2. GetNextRequest...........................................................................................7
3.3.3. SetRequest...................................................................................................8
3.3.4. GetResponse.................................................................................................8
3.3.5. Trap..............................................................................................................8
3.3.6. GetBulkRequest...........................................................................................8
3.3.7. InformRequest.............................................................................................9
4. VERSIONES DE PROTOCOLO SNMP...........................................9
4.1. Versión 1.......................................................................................9
4.2. Versión 2.....................................................................................10
SNMPv1 y SNMPv2c interoperabilidad...............................................................10
Agentes de proxy..................................................................................................10
Sistema de gestión de la red bilingüe.................................................................10
4.3. Versión 3.....................................................................................11
5. MÁS INFORMACIÓN SOBRE EL PROTOCOLO..........................13
5.1. Cuestiones de Aplicación............................................................13
5.2. Indización de Recursos...............................................................13
5.3. Implicaciones de Seguridad.......................................................13
5.4. Descubrimiento Automático.......................................................14
6. SNMP EN LINUX COMO SERVICIO...........................................14
6.1. Instalación del software como servicio.......................................14
6.2 Configuración del demonio net-snmp.........................................15
6.3 Creación de un usuario para la versión 3....................................16
6.4 Probar el acceso a la información...............................................17
7. MONITORIZACIÓN REMOTA CON UN CLIENTE WEB.............19
7.1 Observium...................................................................................19
7.1.1 Requisitos previos.......................................................................................19
7.1.2 Descarga del software.................................................................................20
7.1.3 Instalación y configuración inicial.............................................................21
7.1.4 Creación de la base de datos......................................................................21
7.1.5 Configuración de Observium......................................................................22
7.1.6 Configuración del servidor Apache............................................................23
Leandro Terrés Rocamora 02/02/2015 Página 1 de 35

7.1.7 Descubrimiento y sondeo............................................................................24
7.1.8. Automatización del descubrimiento y el sondeo.......................................26
7.1.9. Acceso mediante el navegador web...........................................................27
7.2 Otros clientes..............................................................................29
7.2.1 Icinga/Nagios..............................................................................................29
7.2.2 Cacti............................................................................................................29
7.2.3 Otros clientes..............................................................................................32
9. CONCLUSIÓN.............................................................................33
Índice de imágenes
Ilustración 1: Árbol MIB..............................................................................5
Ilustración 2: Instalación de net-snmp.....................................................15
Ilustración 3: Edición del fichero snmpd.conf...........................................16
Ilustración 4: Creación de usuario SNMPv3..............................................16
Ilustración 5: Iniciación del servicio net-snmp.........................................17
Ilustración 6: snmpwalk sobre SNMPv2....................................................17
Ilustración 7: snmpget sobre SNMPv2......................................................18
Ilustración 8: snmpwalk sobre SNMPv3....................................................18
Ilustración 9: snmpget sobre SNMPv3......................................................18
Ilustración 10: Instalación de requisitos para Observium.........................20
Ilustración 11: Descarga de Observium...................................................20
Ilustración 12: Instalación y configuración del directorio.........................21
Ilustración 13: Fichero de configuración de Observium............................22
Ilustración 14: Añadir usuario Observium................................................23
Ilustración 15: Añadir dispositivo a Observium........................................24
Ilustración 16: Descubrimiento................................................................25
Ilustración 17: Sondeo.............................................................................26
Ilustración 18: Inicio de sesión en Observium..........................................27
Ilustración 19: Monitorización en tiempo real de Observium...................28
Ilustración 20: Interfaz web de Icinga 2...................................................29
Ilustración 21: Página de inicio de Cacti..................................................30
Ilustración 22: Dispositivos en Cacti........................................................31
Ilustración 23: Añadir gráficas en Cacti...................................................31
Ilustración 24: Gráficas en Cacti..............................................................32
Índice de tablas
Tabla 1: Puertos SNMP...............................................................................6
Tabla 2: Formato de paquetes SNMP..........................................................7
Tabla 3: Estructura del campo SNMP PDU..................................................7
Tabla 4: Formato de la PDU........................................................................8

1. INTRODUCCIÓN
El Protocolo Simple de Administración de Red o SNMP (en inglés Simple Network
Management Protocol) es un protocolo es un protocolo de la capa de aplicación que facilita
el intercambio de información de administración entre dispositivos de red. Los dispositivos
que normalmente soportan SNMP incluyen routers, switches, servidores, estaciones de
trabajo, impresoras, bastidores de módem y muchos más. Permite a los administradores
supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su
crecimiento.
SNMP es un componente de la suite de protocolo de Internet como se define por el IETF. Se
compone de un conjunto de normas para la gestión de la red, incluyendo una capa de
aplicación del protocolo , una base de datos de esquema , y un conjunto de objetos de datos .
Las versiones de SNMP más utilizadas son SNMP versión 1 (SNMPv1) y SNMP versión 2
(SNMPv2).
SNMP en su última versión (SNMPv3) posee cambios significativos con relación a sus
predecesores, sobre todo en aspectos de seguridad; sin embargo no ha sido
mayoritariamente aceptado en la industria.
En usos típicos SNMP, uno o más equipos administrativos, llamados gerentes, tienen la tarea
de supervisión o la gestión de un grupo de hosts o dispositivos de una red informática. En
cada sistema gestionado se ejecuta, en todo momento, un componente de software llamado
agente que reporta la información a través de SNMP con el gerente.
Los agentes SNMP exponen los datos de gestión en los sistemas administrados como
variables. El protocolo también permite realizar tareas de gestión de activos, tales como la
modificación y la aplicación de una nueva configuración a través de la modificación remota
de estas variables. Las variables accesibles a través de SNMP están organizadas en
jerarquías. Estas jerarquías, y otros metadatos (tales como el tipo y la descripción de la
variable), se describen por Bases de Información de Gestión (MIB).
Una red administrada a través de SNMP consta de tres componentes clave:
• Dispositivos administrados;
• Agentes;
• Sistemas administradores de red (Network Management Systems, NMS’s).
Un dispositivo administrado es un dispositivo que contiene un agente SNMP y reside en
una red administrada. Estos recogen y almacenan información de administración, la cual es
puesta a disposición de los NMS’s usando SNMP. Los dispositivos administrados, a veces
llamados elementos de red, pueden ser routers, servidores de acceso, switches, bridges,
hubs, computadores o impresoras.
Un agente es un módulo de software de administración de red que reside en un dispositivo
administrado. Un agente posee un conocimiento local de información de administración
(memoria libre, número de paquetes IP recibidos, rutas, etcétera), la cual es traducida a un
formato compatible con SNMP y organizada en jerarquías.
Un sistema administrador de red (NMS) ejecuta aplicaciones que supervisan y controlan
a los dispositivos administrados. Los NMS’s proporcionan el volumen de recursos de
procesamiento y memoria requeridos para la administración de la red. Uno o más NMS’s
deben existir en cualquier red administrada...

2. HISTORIA
La escala y el alcance de Internet, y un mayor uso de la tecnología en aplicaciones
comerciales, provocó la necesidad de un sistema de gestión de red común sobre TCP/IP.
Desafortunadamente, durante los primeros años no había un único estándar. En la década de
1980 se desarrollaron diferentes tecnologías por diferentes grupos de trabajo.
Se pusieron en marcha varias iniciativas para el desarrollo de la red. Tres de estos esfuerzos
que habían dado progresos significativos fueron el HEMS (High-Level Entity Management
System)/HEMP High-level Entity Management Protocol definido en los RFCs del 1021 al
1024, el SGMP (Simple Gateway Monitoring Protocol) definido en el RFC 1028 y el Protocolo
de Servicio/Gestión de información común (CMOP Common Management Information
Protocol) que es parte del actual OSI.
El Internet Engineering Task Force (IETF) reconoció la importancia de tener un estándar
unificado de gestión para TCP/IP, y en el año 1988 publicó el RFC 1052, IAB
Recomendaciones para el desarrollo de un estándar de gestión de red de Internet. Ésta nota
no es un estándar, más que una declaración de intenciones y documentación de una reunión
celebrada sobre este tema. La conclusión del RFC 1052 fue que SGMP fue usado como base
de un nuevo estándar de Internet que se llamó Simple Network Management Protocol
(SNMP) o Protocolo Simple de Gestión de Red. El desarrollo se lleva a cabo por el Grupo de
Trabajo SNMP.
Con el pasar de los años el protocolo SNMP fue evolucionando, surgiendo así nuevas
versiones del mismo. La primera versión de SNMP Framework, SNMPv1, incluida la primera
definición formal del protocolo SNMP, en el RFC 1067 (después revisado en los RFCs 1098 y
1157). Éste estándar redefine las operaciones del protocolo dadas en el documento de SGMP.
Ésto hace que el funcionamiento del Protocolo SNMP encaje en el marco general del
Framework SNMP, trabajando con objetos MIB formalmente definidos.
3. EL PROTOCOLO SNMP
Para comprender el funcionamiento del protocolo SNMP debemos conocer en detalle su
estructura, sus comandos, la base de información de administración y los mensajes propios
del protocolo de comunicación.
3.1 Base de información de administración SNMP
(MIB)
Una Base de Información de Administración (Management Information Base, MIB) es una
colección de información que está organizada jerárquicamente. Las MIB’s son accedidas
usando un protocolo de administración de red, como por ejemplo, SNMP.
Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de
cualquier número de características específicas de un dispositivo administrado. Los objetos
administrados están compuestos de una o más instancias de objeto, que son esencialmente
variables.
Existen dos tipos de objetos administrados: Escalares y tabulares. Los objetos escalares
definen una simple instancia de objeto. Los objetos tabulares definen múltiples instancias de
objeto relacionadas que están agrupadas conjuntamente en tablas MIB.

Un ejemplo de un objeto administrado es atInput, que es un objeto escalar que contiene una
simple instancia de objeto, el valor entero que indica el número total de paquetes AppleTalk
de entrada sobre una interfaz de un router.
Un identificador de objeto (object ID) identifica únicamente a un objeto administrado en la
jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz
anónima y los niveles, que son asignados por diferentes organizaciones.
El árbol MIB ilustra las variadas jerarquías asignadas por las diferentes organizaciones
Los identificadores de los objetos ubicados en la parte superior del árbol pertenecen a
diferentes organizaciones estándares, mientras los identificadores de los objetos ubicados en
la parte inferior del árbol son colocados por las organizaciones asociadas.
Los vendedores pueden definir ramas privadas que incluyen los objetos administrados para
sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están
localizadas en la rama experimental.
El objeto administrado atInput podría ser identificado por el nombre de objeto iso.identified-
organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput o por el
descriptor de objeto equivalente 1.3.6.1.4.1.9.3.3.1.
El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos, los cuales en
su conjunto son llamados mib-2. Los grupos son los siguientes:
• System (1);
• Interfaces (2);
• AT (3);
• IP (4);
• ICMP (5);
Ilustración 1: Árbol MIB

• TCP (6);
• UDP (7);
• EGP (8);
• Transmission (10);
• SNMP (11).
Es importante destacar que la estructura de una MIB se describe mediante el estándar
Notación Sintáctica Abstracta 1 (Abstract Syntax Notation One).
3.2 Detalles del Protocolo
SNMP opera en la capa de aplicación del conjunto de protocolos de Internet ( capa 7 del
modelo OSI ). El agente SNMP recibe solicitudes en el puerto UDP 161. El administrador
puede enviar solicitudes de cualquier puerto de origen disponible para el puerto 161 en el
agente. La respuesta del agente será enviado de vuelta al puerto de origen en el gestor. El
administrador recibe notificaciones ( Trampas e InformRequests ) en el puerto 162. El
agente puede generar notificaciones desde cualquier puerto disponible. Cuando se utiliza
con Transport Layer Security o datagramas de Transport Layer Security solicitudes se
reciben en el puerto 10161 y trampas se envían al puerto 10162. SNMPv1 especifica cinco
centrales unidades de datos de protocolo (PDU). Otros dos PDU, GetBulkRequest e
InformRequest se añadieron en SNMPv2 y prorrogados a SNMPv3.
Todas las PDU SNMP se construyen de la siguiente manera:
• Cabecera IP
• Encabezado UDP versión comunidad
• Tipo de PDU
• petición-id
• error de estado
• índice de errores
• enlaces de variables
3.3 Mensajes SNMP
Para realizar las operaciones básicas de administración anteriormente nombradas, el
protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un pequeño
grupo de mensajes (PDUs) entre los administradores y agentes. La utilización de un
mecanismo de este tipo asegura que las tareas de administración de red no afectarán al
rendimiento global de la misma, ya que se evita la utilización de mecanismos de control y
recuperación como los de un servicio orientado a la conexión, por ejemplo TCP.
Los puertos comúnmente utilizados para SNMP son los siguientes:
Número Descripción
161 SNMP
162 SNMP-trap
Tabla 1: Puertos SNMP

Los paquetes utilizados para enviar consultas y respuestas SNMP poseen el siguiente
formato:
Versión Comunidad SNMP PDU
Tabla 2: Formato de paquetes SNMP
• Versión: Número de versión de protocolo que se está utilizando (por ejemplo 1 para
SNMPv1);
• Comunidad: Nombre o palabra clave que se usa para la autenticación. Generalmente
existe una comunidad de lectura llamada "public" y una comunidad de escritura
llamada "private";
• SNMP PDU: Contenido de la unidad de datos del protocolo, el que depende de la
operación que se ejecute.
Los mensajes GetRequest, GetNextRequest, SetRequest y GetResponse utilizan la siguiente
estructura en el campo SNMP PDU:
Tipo Identificador Estado de error Índice de error Enlazado de variables
Tabla 3: Estructura del campo SNMP PDU
• Identificador: Es un número utilizado por el NMS y el agente para enviar solicitudes y
respuesta diferentes en forma simultánea;
• Estado e índice de error: Sólo se usan en los mensajes GetResponse´(en las consultas
siempre se utiliza cero). El campo "índice de error" sólo se usa cuando "estado de
error" es distinto de 0 y posee el objetivo de proporcionar información adicional sobre
la causa del problema. El campo "estado de error" puede tener los siguientes valores:
• 0: No hay error;
• 1: Demasiado grande;
• 2: No existe esa variable;
• 3: Valor incorrecto;
• 4: El valor es de solo lectura;
• 5: Error genérico.
• Enlazado de variables: Es una serie de nombres de variables con sus valores
correspondientes (codificados en ASN.1).
3.3.1. GetRequest
A través de este mensaje el NMS solicita al agente retornar el valor de un objeto de interés
mediante su nombre. En respuesta el agente envía una respuesta indicando el éxito o fracaso
de la petición. Si la petición fue correcta, el mensaje resultante también contendrá el valor
del objeto solicitado. Este mensaje puede ser usado para recoger un valor de un objeto, o
varios valores de varios objetos, a través del uso de listas.
3.3.2. GetNextRequest
Este mensaje es usado para recorrer una tabla de objetos. Una vez que se ha usado un
mensaje GetRequest para recoger el valor de un objeto, puede ser utilizado el mensaje
GetNextRequest para repetir la operación con el siguiente objeto de la tabla. Siempre el
resultado de la operación anterior será utilizado para la nueva consulta. De esta forma un
NMS puede recorrer una tabla de longitud variable hasta que haya extraído toda la

información para cada fila existente.
3.3.3. SetRequest
Este tipo de mensaje es utilizado por el NMS para solicitar a un agente modificar valores de
objetos. Para realizar esta operación el NMS envía al agente una lista de nombres de objetos
con sus correspondientes valores.
3.3.4. GetResponse
Este mensaje es usado por el agente para responder un mensaje GetRequest,
GetNextRequest, o SetRequest. En el campo "Identificador de Request" lleva el mismo
identificador que el "request" al que está respondiendo.
3.3.5. Trap
Una trap es generado por el agente para reportar ciertas condiciones y cambios de estado a
un proceso de administración. El formato de la PDU es diferente:
Tipo Enterprise
Dirección
del agente
Tipo genérico
de trap
Tipo específico
de trap
Timestamp
Enlazado de
variables
Tabla 4: Formato de la PDU
• Enterprise: Identificación del subsistema de gestión que ha emitido el trap;
• Dirección del agente: Dirección IP del agente que ha emitido el trap;
• Tipo genérico de trap:
• Cold start (0): Indica que el agente ha sido inicializado o reinicializado;
• Warm start (1): Indica que la configuración del agente ha cambiado;
• Link down (2): Indica que una interfaz de comunicación se encuentra fuera de
servicio (inactiva);
• Link up (3): Indica que una interfaz de comunicación se encuentra en servicio
(activa);
• Authentication failure (4): Indica que el agente ha recibido un requerimiento de
un NMS no autorizado (normalmente controlado por una comunidad);
• EGP neighbor loss (5): Indica que en sistemas en que los routers están
utilizando el protocolo EGP, un equipo colindante se encuentra fuera de servicio;
• Enterprise (6): En esta categoría se encuentran todos los nuevos traps incluidos
por los vendedores.
• Tipo específico de trap: Es usado para traps privados (de fabricantes), así como para
precisar la información de un determinado trap genérico;
• Timestamp: Indica el tiempo que ha transcurrido entre la reinicialización del agente y
la generación del trap;
• Enlazado de variables: Se utiliza para proporcionar información adicional sobre la
causa del mensaje.
3.3.6. GetBulkRequest
Este mensaje es usado por un NMS que utiliza la versión 2 ó 3 del protocolo SNMP
típicamente cuando es requerida una larga transmisión de datos, tal como la recuperación
de largas tablas. En este sentido es similar al mensaje GetNextRequest usado en la versión 1
del protocolo, sin embargo, GetBulkRequest es un mensaje que implica un método mucho
más rápido y eficiente, ya que a través de un solo mensaje es posible solicitar la totalidad de

la tabla.
3.3.7. InformRequest
Un NMS que utiliza la versión 2 ó 3 del protocolo SNMP transmite un mensaje de este tipo a
otro NMS con las mismas características, para notificar información sobre objetos
administrados.
4. VERSIONES DE PROTOCOLO SNMP
Para comprender como ha evolucionado el Protocolo SNMP y como funciona en la
actualidad, es necesario conocer las diferentes versiones del mismo, así como los RFCs en
los que está definido.
4.1. Versión 1
SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. SNMPv1 opera
a través de protocolos como el User Datagram Protocol (UDP), Protocolo de Internet (IP),
servicio de red sin conexión OSI (CLNS), AppleTalk Protocolo de datagramas de entrega
(DDP), y Novell Internet Packet Exchange (IPX).
SNMPv1 es ampliamente utilizado y es el de facto protocolo de gestión de red en la
comunidad de Internet. Los primeros RFCs para SNMP, ahora conocido como SNMPv1,
aparecieron en 1988:
• RFC 1065 - Estructura e identificación de información de gestión para Internet
basadas en TCP / IP.
• RFC 1066 - Base de información de gestión para la gestión de la red de Internet
• RFC 1067 - Un protocolo simple de administración de red.
Estos protocolos estaban obsoletos por:
1. RFC 1155 - Estructura e identificación de información de gestión para Internet
2. RFC 1156 - Base de información de gestión para la gestión de la red de Internet
3. RFC 1157 - Un protocolo simple de administración de red Después de un corto tiempo,
RFC 1156 (MIB-1) fue reemplazada por la más habitual:
4. RFC 1213 - Versión 2 de la base de información de gestión (MIB-2) para la gestión de
la red de Internet basadas en TCP / IP.
La Versión 1 ha sido criticada por su falta de seguridad. La autenticación de los clientes se
realiza sólo por una "cadena de comunidad", en efecto, un tipo de contraseña, que se
transmite en texto plano. El diseño de los años 80 de SNMP V1 fue realizado por un grupo de
colaboradores que vieron el MR / IETF / NSF patrocinado oficialmente (National Science
Foundation) esfuerzo (HEMS / CMIS / CMIP) ya que tanto inaplicable en las plataformas
informáticas de la época, así como potencialmente inviable.
SNMP se aprobó basándose en la creencia de que se trataba de un Protocolo provisional
necesaria para la toma de medidas para el despliegue a gran escala de Internet y su

comercialización. En ese período de tiempo de Internet estándar de autenticación /
seguridad era a la vez un sueño y desalentado por los grupos de diseño de protocolos
centrados.
4.2. Versión 2
SNMPv2 ( RFC 1441 - RFC 1452 ), revisa la versión 1 e incluye mejoras en las áreas de
comunicaciones de rendimiento, la seguridad, confidencialidad e-manager-a gerente.
Introdujo GetBulkRequest , una alternativa a GetNextRequests iterativos para recuperar
grandes cantidades de datos de gestión en una sola solicitud. Sin embargo, el nuevo sistema
de seguridad basado en partidos en SNMPv2, visto por muchos como demasiado complejo,
no fue ampliamente aceptada.
Esta versión de SNMP alcanzado el nivel de madurez de Norma, pero se consideró obsoleto
por las versiones posteriores. Simple basada en la comunidad la versión Network
Management Protocol 2 , o SNMPv2c , se define en el RFC 1901 - RFC 1908 . SNMPv2c
comprende SNMPv2 sin el nuevo modelo de seguridad de SNMP v2 controversial, utilizando
en su lugar el sistema de seguridad basado en la simple comunidad de SNMPv1. Esta versión
es una de las relativamente pocas normas para cumplir con el proyecto de nivel de madurez
estándar del IETF, y fue considerado el de facto estándar SNMPv2.
Es también estaba obsoleto después, por SNMPv3. Simple de usuario basada en la versión
Network Management Protocol 2 , o SNMPv2u , se define en el RFC 1909 - RFC 1910 . Este
es un compromiso que pretende ofrecer una mayor seguridad que SNMPv1, pero sin incurrir
en la alta complejidad de SNMPv2. Una variante de este se comercializó como SNMP v2 * , y
el mecanismo fue finalmente adoptado como uno de los dos marcos de seguridad de SNMP
v3.
SNMPv1 y SNMPv2c interoperabilidad
Tal como está actualmente especificada, SNMPv2c es incompatible con SNMPv1 en dos
áreas clave: los formatos de mensajes y operaciones de protocolo. Mensajes SNMPv2c
utilizan diferentes cabecera y la unidad de datos de protocolo (PDU) formatos de mensajes
SNMPv1. SNMPv2c también utiliza dos operaciones de protocolo que no están especificados
en SNMPv1. Además, RFC 2576 define dos posibles estrategias de coexistencia
SNMPv1/v2c: agentes de proxy y sistemas de gestión de red bilingües.
Agentes de proxy
Un agente SNMPv2 puede actuar como un agente proxy en nombre de dispositivos SNMPv1
administrados, de la siguiente manera:
• Un SNMPv2 NMS emite un comando destinado a un agente SNMPv1. • El NMS envía
el mensaje SNMP para el agente proxy SNMPv2.
• El agente proxy reenvía Cómo, GetNext y Set mensajes al agente SNMPv1 sin
cambios.
• Mensajes GetBulk son convertidas por el agente proxy de GetNext mensajes y luego se
envían al agente SNMPv1.
El agente proxy mapas de mensajes de captura SNMPv1 a SNMPv2 mensajes de captura y
luego las envía a los nuevos Estados miembros.
Sistema de gestión de la red bilingüe
Sistemas de gestión de red SNMPv2 Bilingües soportan tanto SNMPv1 y SNMPv2. Para
apoyar este entorno de gestión dual, una aplicación para la gestión de los nuevos Estados

miembros bilingües debe ponerse en contacto con un agente. El NMS examina la
información almacenada en una base de datos local para determinar si el agente es
compatible con SNMPv1 o SNMPv2. Sobre la base de la información en la base de datos, el
NMS se comunica con el agente utilizando la versión adecuada de SNMP.
4.3. Versión 3
Aunque SNMPv3 no realiza cambios en el protocolo, aparte de la adición de seguridad
criptográfica, se ve muy diferente debido a las convenciones nuevo texto, los conceptos y la
terminología.
SNMPv3 añadió principalmente la seguridad y mejoras de configuración remota SNMP.
Debido a la falta de seguridad con el uso de SNMP, los administradores de red se utilizan
otros medios, tales como telnet para la configuración, contabilidad y gestión de fallos.
SNMPv3 se ocupa de cuestiones relacionadas con el despliegue a gran escala de SNMP,
contabilidad y gestión de fallos. Actualmente, SNMP se utiliza principalmente para el control
y la gestión del rendimiento.
SNMPv3 define una versión segura de SNMP y también facilita la configuración remota de
las entidades SNMP. SNMPv3 ofrece un entorno seguro para la gestión de sistemas que
abarcan los siguientes:
• Identificación de las entidades SNMP para facilitar la comunicación sólo entre
entidades SNMP conocidas - Cada entidad SNMP tiene un identificador llamado
snmpEngineID y comunicación SNMP es posible sólo si la entidad SNMP conoce la
identidad de su interlocutor. Trampas y notificaciones son excepciones a esta regla.
• Soporte para los modelos de seguridad - Un modelo de seguridad puede definir la
política de seguridad dentro de un dominio administrativo o una Internet. SNMPv3
contiene las especificaciones para USM.
Definición de los objetivos de seguridad, donde los objetivos del servicio de autenticación de
mensajes incluyen la protección contra lo siguiente:
• Modificación de la información - Protección contra algunos no autorizados entidad que
altera SNMP en tránsito mensajes generados por un principal autorizado.
• Masquerade - Protección contra intentar operaciones de gestión no autorizadas por
algún director al asumir la identidad de otra principal que cuenta con las
autorizaciones correspondientes.
• Mensaje Corriente Modificación - Protección contra mensajes que consiguen
maliciosamente reordenado, retrasado, o reproducido para efectuar las operaciones de
gestión autorizadas.
• Divulgación - Protección contra escuchas en los intercambios entre los motores de
SNMP.
Especificación para USM - USM (Modelo de seguridad basada en el usuario) consiste en la
definición general de los siguientes mecanismos de comunicación disponibles:
• Comunicación sin autenticación y privacidad (noAuthNoPriv).
• La comunicación con la autenticación y sin privacidad (authNoPriv).

• La comunicación con la autenticación y la privacidad (authpriv).
• Definición de diferentes protocolos de autenticación y privacidad - Actualmente, los
protocolos de autenticación MD5 y SHA y los protocolos de privacidad y CBC_DES
CFB_AES_128 se admiten en la USM.
• Definición de un procedimiento de descubrimiento - Para encontrar el snmpEngineID
de una entidad SNMP para una dirección de transporte común y dirección de punto
final de transporte.
• Definición del procedimiento de sincronización de hora - Para facilitar la comunicación
autenticado entre las entidades SNMP.
• Definición del marco MIB SNMP - Para facilitar la configuración remota y
administración de la entidad SNMP.
• Definición de las MIB USM - Para facilitar la configuración remota y administración
del módulo de seguridad.
• Definición de las MIB VACM - Para facilitar la configuración remota y administración
del módulo de control de acceso.
El SNMPv3 se centra en dos aspectos principales, a saber, la seguridad y la administración.
El aspecto de seguridad se dirige, ofreciendo tanto una sólida autenticación y cifrado de
datos para la privacidad. El aspecto de la administración se centra en dos partes, a saber los
originadores de notificación y agentes proxy. SNMPv3 define una serie de capacidades
relacionadas con la seguridad. Las especificaciones iniciales definen la USM y VACM, que
más tarde fueron seguidos por un modelo de seguridad de transporte que proporciona apoyo
a través de SSH y SNMPv3 SNMPv3 en TLS y DTLS.
• USM (basado en usuarios Modelo de seguridad) proporciona funciones de
autenticación y privacidad (encriptación) y opera en el nivel de mensaje.
• VACM (Acceso basado Vista-Modelo de Control) determina si se permite a un director
dado acceso a un objeto MIB particular, para realizar funciones específicas y opera en
el nivel de PDU.
• TSM (Modo de Seguridad del Transporte) proporciona un método para la
autenticación y el cifrado de mensajes a través de los canales externos de seguridad.
Dos transportes, SSH y TLS / DTLS, han definido que hacen uso de la especificación
de TSM.
La seguridad ha sido la mayor debilidad de SNMP desde el principio. Autenticación en
versiones de SNMP 1 y 2 asciende a nada más que una contraseña (cadena de comunidad)
enviado en texto claro entre un gerente y agente. Cada mensaje SNMPv3 contiene los
parámetros de seguridad que están codificados como una cadena de octetos. El significado
de estos parámetros de seguridad depende del modelo de seguridad que se utiliza. SNMPv3
proporciona características de seguridad importantes:
• Confidencialidad - El cifrado de paquetes para impedir la obtención de una fuente no
autorizada.
• Integridad - Integridad de los mensajes para asegurar que un paquete no ha sido
alterado durante el tránsito que incluye un mecanismo de protección de repetición de
paquetes opcionales.
• Autenticación - para comprobar que el mensaje es de una fuente válida.
A partir de 2004 el IETF reconoce simple versión Protocolo de gestión de red 3 como se
define en el RFC 3411 - RFC 3418 (también conocido como STD0062) como la versión
estándar actual de SNMP. El IETF ha designado SNMPv3 un completo estándar de Internet ,
el más alto nivel de madurez de un RFC. Considera versiones anteriores sean obsoletos
(designándolos diversamente "histórico" o "Obsoleto"). En la práctica, las implementaciones
de SNMP menudo soportan múltiples versiones: Típicamente SNMPv1, SNMPv2c y SNMPv3.

5. MÁS INFORMACIÓN SOBRE EL PROTOCOLO
Además de lo expuesto anteriormente hay otras cuestiones y consideraciones a tener en
cuenta a cerca del protocolo que se exponen a continuación.
5.1. Cuestiones de Aplicación
Implementaciones SNMP varían entre los proveedores de plataformas. En algunos casos,
SNMP es una característica adicional, y no se toma suficientemente en serio como un
elemento del diseño de la base. Algunos de los principales proveedores de equipos tienden a
sobre-extender su propia interfaz de línea de comandos (CLI) de los sistemas de
configuración y control centrados.
Estructura de árbol y lineal aparentemente simple de indexación de SNMP no puede siempre
ser entendido lo suficientemente bien dentro de las estructuras de datos internas que son
elementos de diseño básico de una plataforma. En consecuencia, las consultas de
procesamiento de SNMP en determinados conjuntos de datos pueden dar lugar a la
utilización de CPU superior al necesario. Un ejemplo de esto sería las grandes tablas de
enrutamiento, como BGP o IGP .
5.2. Indización de Recursos
Dispositivos modulares pueden aumentar o disminuir sus índices de SNMP (aka instancias)
cada vez que se agrega o quita hardware ranurada de forma dinámica. Aunque esto es más
común con el hardware, interfaces virtuales tienen el mismo efecto. Los valores del índice se
suelen asignar al momento del arranque y permanecen fijos hasta el siguiente reinicio.
Hardware o entidades virtuales añadidas mientras el dispositivo está "en directo" pueden
tener sus índices asignados al final de la gama existente y posiblemente reasignados en el
siguiente reinicio. Herramientas de inventario y monitoreo de redes necesitan tener la
capacidad de actualización del dispositivo, haciendo reaccionar adecuadamente a la trampa
de arranque en frío desde el reinicio del dispositivo para evitar la corrupción y la falta de
coincidencia de los datos consultados.
Asignaciones de índice para una instancia de dispositivo SNMP pueden cambiar de encuesta
para sondear sobre todo como resultado de los cambios iniciados por el administrador del
sistema. Si se necesita información para una interfaz en particular, es imprescindible para
determinar el índice de SNMP antes de recuperar los datos necesarios. Generalmente, una
tabla de descripción como ifDescr asignará un nombre de usuario como la serie 0/1 (Blade 0,
puerto 1) a un índice SNMP.
5.3. Implicaciones de Seguridad
• SNMP versiones 1 y 2c están sujetos a la detección de paquetes de la cadena de
comunidad borre el texto del tráfico de red, ya que no implementan el cifradoss.
• Todas las versiones de SNMP están sujetos a la fuerza bruta y ataques de diccionario
para adivinar las cadenas de comunidad, cadenas de autenticación, las claves de
autenticación, cadenas de cifrado o claves de cifrado, ya que no implementan un
protocolo de enlace de desafío-respuesta .
• Aunque SNMP funciona sobre TCP y otros protocolos, se utiliza con mayor frecuencia
sobre UDP que está sin conexión y vulnerables a la suplantación de IP ataques. Por lo
tanto, todas las versiones están sujetos a pasar por las listas de acceso de dispositivos
que podrían haber sido implementadas para restringir el acceso SNMP, aunque otros
mecanismos de seguridad de SNMPv3 debe impedir un ataque exitoso.

• Potente configuración de SNMP (escritura) capacidades no están siendo plenamente
utilizados por muchos vendedores, en parte debido a la falta de seguridad en las
versiones de SNMP SNMPv3 antes y en parte debido a que muchos dispositivos,
simplemente no son capaces de ser configurado a través de cambios en los objetos
MIB individuales.
• SNMP encabeza la lista del Instituto SANS Común Defecto Problemas de
configuración con el tema de las cadenas de comunidad SNMP por defecto
establecidos en 'público' y 'privado' y era el número diez en la escala SANS Top 10
amenazas de seguridad de Internet más críticos para el año 2000.
5.4. Descubrimiento Automático
SNMP por sí mismo no es más que un protocolo para la recolección y organización de
información. La mayoría de los conjuntos de herramientas de aplicación SNMP ofrecen algún
tipo de mecanismo de descubrimiento, una recopilación normalizada de datos comunes a la
mayoría de las plataformas y dispositivos.
Una de estas características es a menudo una forma de descubrimiento automático, donde
los nuevos dispositivos detectados en la red se sondean automáticamente. Para SNMPv1 y
SNMPv2c, esto representa un riesgo de seguridad, ya que su lectura SNMP comunidades
serán transmitidos en texto plano para el dispositivo de destino.
Mientras que los requisitos de seguridad y perfiles de riesgo varían de una organización a
otra, se debe tener cuidado al usar una función como esta, con especial atención a los
entornos comunes, como los centros de datos mixtos e inquilinos, servidor de alojamiento y
las instalaciones de colocación, y ambientes similares.
6. SNMP EN LINUX COMO SERVICIO
Como se mencionaba anteriormente, el servicio SNMP se puede implantar en routers,
switches, servidores, estaciones de trabajo y otros dispositivos. En éste apartado voy a
explicar como se instala y configura el servicio en Linux, concreto sobre la distribución
openSuSE, aunque también se puede implementar de la misma manera en otras
distribuciones, tan sólo teniendo en cuenta que la localización de los ficheros de
configuración puede estar en otro ubicación.
6.1. Instalación del software como servicio
Hay diferentes paquetes de software para implementar el servicio SNMP en un ordenador
con Sistema Operativo basado en Linux. El paquete de software mas utilizado en éstos
sistemas se llama “net-snmp” y para poder instalar el servicio ejecutamos la siguiente
instrucción como usuario “root”.
# zypper in net-snmp
Durante la instalación del paquete a través del gestor de software del sistema se instalarán,
además, otros paquetes de software adicional que puedan ser necesarios. Gracias a ésta
medida, se puede disponer del servicio casi de inmediato.
En los manuales de instalación siempre se indica la forma de realizar el paso usando el

código fuente, para lo cual hay que instalar las dependencias propias de software, que
normalmente se requieren para una correcta compilación e instalación del mismo.
En la Ilustración 2: Instalación de net-snmp se muestra la salida del comando para realizar
dicha acción.
6.2 Configuración del demonio net-snmp
El siguiente paso es editar los ficheros de configuración para poder obtener el acceso y la
información del nuevo servicio sobre la máquina en la que lo hemos instalado. El primer
archivo que debemos editar es el fichero de configuración del demonio del servicio
“/etc/snmp/snmpd.conf”.
# nano /etc/snmp/snmpd.conf
En el archivo vienen varias variables para ser modificadas, la primera es syslocation, en
donde pondremos el nombre de la sala en donde esté el ordendor. La variable syscontact es
el nombre y la dirección de correo del administrador del servidor. La variable rocommunity
es un acceso de sólo lectura, por defecto viene con los parámetros public 127.0.0.1 que
indican el nombre de la comunidad y la dirección IP desde la que se pueden obtener los
datos como medida de seguridad.
Para poder tener el acceso en modo de lectura-escritura se utiliza la variable rwcommunity
con un nombre de comunidad creado por nosotros y la IP de origen. Éstas variables sólo se
utilizan para SNMPv2c, que se pueden dejar activas para probar la conexión y desactivar
para sólo utilizar posteriormente con SNMPv3, ya que nos permitirá crear usuarios con
contraseña para el acceso. Para usar SNMPv3 se utilizan las variables rouser y rwuser.
Además hay otras variables a tener en cuenta, como agentaddress con el que podemos
controlar el protocolo de transporte y la dirección de la interfaz de escucha. El protocolo de
transporte y el puerto por defecto son el UDP 161 en todas las interfaces de red.
Se pueden también añadir monitorización sobre procesos activos utilizando la variable proc
y el nombre del proceso, que puede ser httpd2-prefork para apache, mysqld para MySQL,
named para BIND DNS Server, etcétera.
Ilustración 2: Instalación de net-snmp

6.3 Creación de un usuario para la versión 3
Una vez guardado el fichero nos queda crear un usuario para poder acceder al servicio
usando el a través de la versión 3 del protocolo. Para ello utilizaremos el comando net-snmp-
create-v3-user, que se puede ejecutar sin comandos o con comandos. La opción -ro es para
indicar que es un usuario de sólo lectura. La opción -A contraseña es para indiciar la
contraseña del usuario. La opción -X contraseña es para poner una contraseña privada. La
opción -a tiene dos opciones para el hash de la contraseña MD5 o SHA, por defecto es MD5.
La opción -x es para el sistema de cifrado a usar, que tiene dos DES o AES, por defecto es
DES y por último el nombre del usuario.
Ejecutamos el comando y la salida sería la siguiente:
Como se muestra en la salida del comando se editan dos ficheros, en el primero se añade la
clave del usuario y en el segundo se añade la opción de lectura-escritura sobre el usuario, ya
que como no indicamos la opción -ro se añade la opción rwuser, en caso de usar dicha opción
sería rouser.
En éstos momentos iniciamos el servicio y lo activamos para que se inicie durante el
arranque del sistema de la siguiente forma:
Ilustración 3: Edición del fichero snmpd.conf
Ilustración 4: Creación de usuario SNMPv3

6.4 Probar el acceso a la información
Para probar el acceso a la información desde la línea de comandos disponemos de varios
comandos propios del paquete net-snmp con el que se puede obtener un recurso en concreto
o todos los recursos disponibles. El primer comando es snmpget y el segundo comando es
snmpwalk.
El comando snmpwalk muestra una salida de todas las OIDs con la información del sistema
como se muestra en la siguiente ilustración.
Ilustración 5: Iniciación del servicio net-snmp
Ilustración 6: snmpwalk sobre SNMPv2

El comando snmpget es para obtener un OID en concreto.
Para hacer la misma consulta, pero con la versión 3 del protocolo se utiliza el snmpwalk de
la siguiente forma:
Para obtener un recurso en concreto, pero con la versión 3 de protocolo se utiliza snmpget
de la siguiente forma:
Ilustración 7: snmpget sobre SNMPv2
Ilustración 8: snmpwalk sobre SNMPv3
Ilustración 9: snmpget sobre SNMPv3

7. MONITORIZACIÓN REMOTA CON UN CLIENTE
WEB
El último paso a realizar es instalar un software web para la monitorización del servicio, y
además nos mostrará gráficas de los datos que obtendrá del servicio para que podamos
monitorizar el servidor de forma continua.
7.1 Observium
Este cliente web es muy completo, pero su instalación es algo complicada. Voy a detallar los
pasos para la instalación y configuración, así como los requisitos de dependencias necesarias
para que el software funcione correctamente.
7.1.1 Requisitos previos
Los requisitos mínimos para éste software son los siguientes:
• Apache
• fping
• MySQL versión 5
• Net-SNMP versión 5.4
• RRDtool 1.3
• Graphviz
• PHP 5.4
Para instalar éstos requisitos se usa la siguiente instrucción por línea de comandos:
# zypper in apache2 apache2-mod_php5 apache2-utils php5 php5-snmp
php5-mysql mariadb mariadb-client mariadb-tools rrdtool graphviz
graphviz-php graphviz-gd impitool
• El nombre de los paquetes son apache2, y apache2-utils para el servidor web. Para
que tenga soporte PHP está el apache2-mod_php5.
• Para instalar PHP con algunas extensiones añade php5, php5-snmp para soporte
SNMP y php5-mysql para soporte de MySQL.
• En vez de usar MySQL Community Server, en openSuSE se seleccionan los paquetes
de mariadb que es un fork del servidor MySQL mas libre.
• El paquete rrdtool permitirá la recopilación de datos. El paquete graphviz es para la
creación de las gráficas que se nos mostraran durante la ejecucuión del software web.
Una muestra de la salida que genera el comando es la de la Ilustración 10: Instalación de
requisitos para Observium en la que se puede observar que indica que ya hay algunos de los
paquetes instalados y los omitirá durante la instalación. Además también hay algunos
paquetes que se actualización.

7.1.2 Descarga del software
Ilustración 10: Instalación de requisitos para Observium
Ilustración 11: Descarga de Observium

Descargamos el software usando el comando wget.
7.1.3 Instalación y configuración inicial
Cambiamos al directorio /src/www que es donde instalaremos el software y luego le
cambiaremos los permisos a los fichero para que el usuario propietario sobre el que corre
apache no tenga problemas para acceder a los datos, crear los ficheros necesarios para
crear las gráficas, etc.
7.1.4 Creación de la base de datos
Si es la primera vez que instalamos mariadb debemos ejecutar como root el comando
# mysql_secure_instalation
para crear una configuración inicial y reiniciar el directorio de almacenamiento. Luego
iniciamos el servicio con
# systemctl start mysql.service
y creamos una contraseña para el usuario root que nos permitirá crear una base de datos y
un usuario único para que el software trabaje sobre ella.
# mysqladmin -u root password 'micontraseña'
Creamos la base de datos y el usuario con las siguientes instrucciones:
# mysql -u root -p
En éste punto nos pide la contraseña.
mysql> CREATE DATABASE observium;
Creamos el usuario y le ponemos una contraseña.
mysql> GRANT ALL PRIVILGES ON observium.* TO 'observium'@'localhost'
IDENTIFIED BY 'claveobservium';
Para salir del interprete de mysql usamos la instrucción quit.
Ilustración 12: Instalación y configuración del directorio

7.1.5 Configuración de Observium
Entramos en el directorio /srv/www/observium y copiamos el fichero config.php.default como
config.php.
# cp config.php.default config.php
Y lo editamos. Cambiamos los parámetros que hacen referencia a la base de datos y ponemos
los nuestros. También tener en cuenta la ruta del directorio donde hemos descomprimido e
paquete, sino nos dará errores. Además añadimos dos lineas que harán referencia a la
posición del comando fping que será necesario para que observium detecte si está activo. El
fichero deberá quedar de la siguiente forma:
El siguiente paso es instalar la base de datos, para ello ejecutamos un script en php que nos
facilitará la tarea. Desde el directorio en el que nos encontramos ejecutamos la siguiente
instrucción:
# sudo -u wwwrun php includes/update/update.php
el proceso tardará un tiempo y dará algunos errores que debemos ignorar.
Creamos dos directorios, uno para los registros y otro para los rrd de las imágenes de los
gráficos con el siguiente comando.
# sudo -u wwwrun mkdir logs rrd
Ilustración 13: Fichero de configuración de Observium

7.1.6 Configuración del servidor Apache
Creamos un fichero de host virtual para que apunte al directorio html de observium para
poder acceder a la interfaz web. El fichero lo creamos dentro del directorio
/etc/apache2/vhosts.d con el nombre observium.conf. Éste fichero es para Apache 2.4+.
El contenido del fichero será el siguiente:
<VirtualHost *:81>
ServerAdmin admin@localhost
ServerName localhost
DocumentRoot /srv/www/observium/html
ErrorLog /srv/www/observium/logs/error_log
CustomLog /srv/www/observium/logs/access_log combined
HostnameLookups Off
UseCanonicalName Off
ServerSignature On
<Directory "/srv/www/observium/html">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Tenemos que añadir también una linea en el fichero /etc/apache2/listen.conf con el siguiente
contenido para que el servidor apache escuche en el puerto 81:
Listen 81
En éste punto reiniciamos el servidor apache con el comando:
# systemctl restart apache2
Volvemos al directorio /srv/www/observium si hemos salido de él y creamos un usuario con
permisos de administración con el siguiente comando, el 10 indice el nivel administrador:
# sudo -u wwwrun ./adduser.php admin administrador 10
Vamos a añadir un dispositivo para ser monitorizado, en nuestro caso el ordenador local para
el cual hemos instalado el net-snmp, pero antes de poder hacer ésto debemos cambiar los
permisos del comando fping porque sino no funcionará. Para hacer ésto ejecutamos el
siguiente comando:
# chmod +s /usr/sbin/fping*
Ilustración 14: Añadir usuario Observium

Ahora ejecutamos el comando para añadir el dispositivo.
7.1.7 Descubrimiento y sondeo
Una vez añadido un dispositivo hay que ejecutar dos comando para hacer el descubrimiento
y la recompilación de datos para nuevos dispositivos, para ello ejecutamos los siguientes
comandos desde el mismo directorio del observium.
# sudo -u wwwrun ./discovery.php -h all
# sudo -u wwwrun ./poller.php -h all
La salida del comando discovery.php se puede ver en la Ilustración 16: Descubrimiento.
Ilustración 15: Añadir dispositivo a Observium

Parte de la salida del comando poller.php se puede ver en la Ilustración 17: Sondeo.
Ilustración 16: Descubrimiento

7.1.8. Automatización del descubrimiento y el sondeo
Para automatizar la recepción de información por parte del programa añadiremos unas
lineas al programador de tareas CRON. Para ello creamos el fichero /etc/cron.d/observium
con el siguiente contenido:
Ilustración 17: Sondeo

33 */6 * * * wwwrun /srv/www/observium/discovery.php -h all >> /dev/null 2>&1
*/5 * * * * wwwrun /srv/www/observium/discovery.php -h new >> /dev/null 2>&1
*/5 * * * * wwwrun /srv/www/observium/poller-wrapper.py 2 >> /dev/null 2>&1
y para estar seguros de que se carga el fichero recargamos el demonio con el siguinte
comando:
# systemctl reload cron
Para que funcione el tercer comando es necesario tener instalado un módulo de python con
el siguietne comando:
# zypper install python-MySQL-python
7.1.9. Acceso mediante el navegador web
Ya estamos listos para usar la interfaz web de Observium, para ello apuntamo nuestro
navegador a la dirección http://localhost:81 y nos saldrá la siguiente pantalla de inicio:
Ilustración 18: Inicio de sesión en Observium

Podemos navegar por los dispositivos y las diferentes opciones de la interfaz, tardará un
tiempo en que se recopilen los datos suficientes para que se generen los gráficos, para
demostrar que se hace uso del mismo hay una opción de tiempo real sobre las interfaces de
red.
Ilustración 19: Monitorización en tiempo real de Observium

7.2 Otros clientes
Existen otros clientes SNMP con los que se puede acceder a la información proporcionada
por el servicio SNMP. Existen tanto clientes de escritorio, en su mayoría para sistemas
Windows, pero la mayoría de las interfaces gráficas de acceso es software para servidores al
estilo de Observium, que se instalan en servidores dedicados a recopilar y controlar los
servidores y dispositivos de red. Algunos de los clientes SNMP que voy a mencionar, también
incluyen sistemas de monitorización local de servicios que permiten reiniciar dichos
servicios en caso de fallo. Los más conocidos son:
7.2.1 Icinga/Nagios
Nagios es un software de monitorización de servicios que, además del protocolo SNMP,
permite monitorizar, tanto la maquina desde la que se ejecuta como otras máquinas remotas,
no sólo a usando SNMP, sino acceso remoto a través de SSH, por ejemplo. Nagios es la
versión comercial, aunque tiene una edición para la comunidad, para resolver posibles
discrepancias con la licencia se creó Icinga.
Aunque existen paquetes de instalación para ambos en openSuSE, su configuración es muy
complicada, y requiere conocer los OIDs para tener acceso a los recursos. Ésto es un trabajo
arduo para poder acceder a los recursos, por eso no lo he contemplado para ésta práctica.
7.2.2 Cacti
Al igual que Observium, Cacti es una interfaz web para monitorizar dispositivos de red, por
fortuna se puede instalar fácilmente a través de un paquete en openSuSE. Por desgracia me
dá algun fallo a la hora de añadir servidores linux con net-snmp, sin embargo, no tuve
problemas para añadir el swtich de clase y se puede monitorizar de forma simple el
ordenador local sobre el que esté instalado.
Una vez instalado se acceder a la programa mediante la URI http://localhost/cacti.
Ilustración 20: Interfaz web de Icinga 2

Para añadir dispositivos se pincha en el primer enlace de la página de inicio. Tras añadir el
switch de la clase se puede ver el listado de los dispositivos, en el que viene por defecto el
localhost, que es la máquina anfitrión.
Cualquier dispositivo soportado puede ser añadido, creo que por razones de compatibilidad,
algunos dispositivos net-snmp no se añaden porque los valores de los OIDs no son
compatibles, o puede que el software esté desactualizado y por ésta razón no haga
correctamente el descubrimiento de los servicios y dé errores a la hora de añadir un servidor
con éste software.
En la Ilustración 22: Dispositivos en Cacti se puede ver el listado de los dispositivos añadidos
a la base de datos y los servicios disponibles. También muestra la dirección IP o DNS y si el
dispositivo está activo o no.
Para realizar la actualización de la información, con la que genera las gráficas, cacti añade al
programador de tareas una entrada de actualización, al igual que hacía Observium, lo que le
permite mantener actualizados los datos.
La pena de éste software es que no dispone un monitor a tiempo real de la transferencia de
datos de las interfaces de red.
Ilustración 21: Página de inicio de Cacti

Para que Cacti genere éstas gráficas, hay que configurarlas, se deben añadir los campos que
se deben rellenar de entre las plantillas disponibles.
Ilustración 22: Dispositivos en Cacti
Ilustración 23: Añadir gráficas en Cacti

En la pestaña graphs, en la parte superior izquierda, se pueden acceder a las gráficas de los
datos obtenidos, en la que la página principal muestra en forma de árbol el listado de todos
los dispositivos y dentro de ellos las gráficas disponibles. Pinchando sobre las gráficas se
puede delimitar el tiempo para de la visualización de los datos, de forma que puedes ver los
períodos de tiempo en intervalos de minutos, horas, dias, etc.
7.2.3 Otros clientes
Existen muchos clientes, la mayoría de los que he encontrado son software propietario, de
echo, Observium tiene una versión de pago que te permite enviar comando a través del
protocolo SNMP.
No he profundizado en la búsqueda de software de monitorización SNMP con software
propietario pero a continuación pongo algunos de los que he encontrado.
• La empresa Paessler dispone de un monitor SNMP llamado PRTG Network Monitor. Es
un software para el sistema operativo Windows y tiene una interfaz similar a
Observium. La URI de la empresa es http://www.es.paessler.com.
• La empresa Uptrends Infra, ofrece un servicio de monitorización en la nube sobre
servidores, en las que se incluye el servicio SNMP. Es una opción a tener en cuenta si
no quieres complicarte con la instalación de un cliente SNMP vía web. La ventaja de
éste sistema es que puedes acceder a él desde cualquier dispositivo móvil con acceso
a Internet. La desventaja es que los datos de acceso a tus servidores están en un
tercero. La URI de la empresa es http://www.uptrendsinfra.com.
Ilustración 24: Gráficas en Cacti

9. CONCLUSIÓN
Gracias al servicio SNMP podemos monitorizar la actividad cualquier dispositivo de red que
incorpore ésta característica, ya sea un router, un switch, un servidor e incluso estaciones de
trabajo dentro de una o varias redes, e incluso a través de Internet y gracias a los clientes de
monitorización se puede agrupar la información obtenida de todos ellos de formas
diferentes, incluyendo si localización física, su posición o localización dentro del centro de
datos u oficina y por tipo de dispositivo o máquina.
Los servidores SNMP proporcionan la información necesaria a cerca de los servicios
disponibles en los dispositivos o máquinas, dependiendo de su configuración y ofrecen la
información en una estructura jerárquica a través de los OIDs que los clientes pueden
obtener para organizar la información obtenida.
Los clientes pueden solamente monitorizar los servidores, pero además, existe la función de
iniciar y detener servicios a través de SNMP. Para ello, SNMP incorpora, dentro de su
protocolo, la opción de hacer cambios en el sistema utilizando los mensajes de tipo
setRequest, que aunque no se han descrito en éste documento, permiten modificar los
objetos con sus correspondientes valores a los usuarios identificados con permisos de
lectura-escritura, de ahí la diferenciación entre éstos tipos de usuarios.
La mayoría de clientes, como los descritos en este documento, sólo permiten el acceso al
información para la monitorización de los dispositivos, pero existen otros muchos con la
opción de no sólo leer, sino también enviar cambios a los dispositivos para, por ejemplo,
reiniciar un servicio o cambiar el nombre de la maquina. Muchos de éstos clientes son
software comercial que tienen incluida la función de realizar cambios a través del protocolo
SNMP, pero existen algunos de software libre, que aunque puedan no ser lo suficientemente
amigables a la hora de instalarlos y/o configurarlos, cumplen con todas las expectativas
necesarias para su implantación en centros de datos, servidores o estaciones de trabajo.
Éste es el caso de Nagios/Icinga, que aunque su instalación y configuración puede ser
tediosa, se ha ganado la confianza de muchos de los servidores mas importantes de Internet,
ya que es utilizado ampliamente en sistemas servidores basados en Linux. Aunque no es un
software dedicado a la gestión a través de SNMP, sino mas bien dedicado al control de
servicios y del servidor, a través de extensiones o plugins, se le puede añadir soporte de
acceso a través de SNMP.
El cliente web Observium en su versión libre o de comunidad sólo permite la monitorización
de un sistema de forma básica y limitada, aunque tiene muchas opciones, la edición de
suscripción permite monitorizar también servicios como Apache, MySQL, NTPd, etcétera, a
través de un agente que se instala como servicio en el inetd que lee una serie de scripts y los
muestra a través de una conexión telnet, que el poller (actualizador) acceder a dicho puerto
y muestra la información. Además también permite realizar cambios a través de setRequest.
El cliente web Cacti, es una software mas simple y no tiene el soporte de envío de mensajes
a través de SNMP. Su instalación y configuración es bastante más sencilla en comparación a
Observium, aunque una vez iniciado el cliente por primera vez se deben añadir dispositivos y
configurar las gráficas de las que se desea obtener los resultados de las actualizaciones. En
el caso de añadir un servidor con net-snmp he tenido problemas, la razón por la que falla es
porque la obtención de los OIDs no son dinámicos, sino que tiene una plantilla de OIDs
genéricos que no coinciden con las últimas versiones de net-snmp, de ahí el error que dá a la
hora de añadir este tipo de servidores.
En definitiva, el uso de SNMP en una red extensa con muchos servidores y dispositivos es la
mejor forma de controlarlos y monitorizarlos, también para pequeños servidores aislados
gracias a los clientes web que se encargar de obtener la información y presentarla.

Implantación y monitorización con SNMP

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Implantación y monitorización con SNMP

Implantación y monitorización con SNMP