Professional Documents
Culture Documents
00
Guía Unificada de Laboratorios
Página 1 de 25
1. Titulo
PRÁCTICA 2. CONFIGURACIÓN DEL PROTOCOLO SNMP EN CENTOS, WINDOWS,
CISCO Y MIKROTIK
Autor: Johrman Vides Niño y Cristina Satizabal
2. Objetivo
3. Marco Teórico
Este protocolo puede ser utilizado para supervisar y controlar: routers, switches, bridges y
hubs de la mayoría de fabricantes, además de servidores y estaciones Windows y Unix,
servidores de terminal, etc. [1]
En el mundo SNMP existen dos entidades: las estaciones que gestionan, denominadas
NMS (Network Management Station) y los dispositivos que son gestionados, denominados
Agentes.
Un NMS procesa y muestra información sobre el estado de los dispositivos y la red, que
obtiene de los Agentes usando un protocolo de administración de red (SNMP). En él se
ejecuta una aplicación mediante la cual el administrador es capaz de supervisar y controlar
a los dispositivos administrados (aquellos que poseen el agente de SNMP).
Los Agentes son módulos software que se instalan en los dispositivos que se desean
gestionar, y que obtienen información del estado del mismo desde la base de información
de administración (MIB). Puede ser un programa separado (un demonio, en el lenguaje
Unix), o puede ser incorporado en el sistema operativo (por ejemplo, en el Sistema
Operativo de un router CISCO). El agente se encarga de recopilar, mantener y enviar la
información de los dispositivos administrados al NMS, respondiendo a las solicitudes de
éste o, también es capaz de enviar alertas o “traps” cuando sea necesario. Dado que se
trata de alertas, son enviadas sin petición previa, de forma asíncrona, al NMS; quien por su
parte es adicionalmente responsable de realizar o ejecutar una acción basada en la
información que recibe del agente [1].
SNMP emplea UDP (User Datagram Protocol, RFC768) cómo protocolo de la capa de
transporte. Este aspecto lo hace poco fiable, ya que no existe conocimiento de la pérdida o
llegada de los datagramas. Pero ello supone un menor tamaño del segmento y, por tanto,
más rapidez a la hora de realizar operaciones y menor impacto en el rendimiento en general
de la red.
SNMP utiliza el puerto de UDP 161, para el envío y la recepción de solicitudes, y el 162,
para la recepción de “traps” de los Agentes, en los dispositivos administrados [1].
El requisito fundamental para el diseño de SNMP fue la sencillez, lo que si bien facilitó su
expansión, ha hecho necesarias varias revisiones para adaptar el protocolo a las
necesidades actuales, entre las que cabe destacar las exigencias en cuanto a la seguridad
del sistema [1]. En la Tabla 1 se describen las diferentes versiones de SNMP.
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 3 de 25
El conjunto de dispositivos que pueden acceder a la MIB de un Agente se define por una
lista de control de acceso que relaciona las direcciones IP con una palabra clave, la
comunidad.
3.1.5. SNMPv3
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 4 de 25
En esta versión, el Agente, al igual que el NMS, se definen como entidades SNMP, y
consisten de un motor SNMP (snmp engine) y aplicaciones SNMP (las operaciones SNMP
en sí). Un motor SNMP consta de los siguientes componentes:
Dispatcher: Envía y recibe mensajes SNMP. También trata de determinar la versión
de cada mensaje recibido (v1, v2, o v3) y, si se soporta la versión, entrega los
mensajes al subsistema de procesado de mensajes.
Subsistema de Procesado de Mensajes: Se encarga de preparar los mensajes para
ser enviados y extraer datos de aquellos recibidos.
Subsistema de Seguridad: Autentica, cifra y descifra los mensajes. La autenticación
puede usar tanto comunidades (SNMPv1 y SNMPv2) como USM de SNMPv3. La
autenticación basada en USM emplea los algoritmos MD5 o SHA para autenticar a
los usuarios sin enviar una contraseña en texto plano. El servicio de privacidad usa
el algoritmo DES para cifrar y descifrar los mensajes SNMP.
Subsistema de Control de Acceso: Determina a cuales usuarios y operaciones se
les permite el acceso a los objetos administrados de la MIB.
La MIB (Management Information Base) se puede considerar como una base de datos que
almacena información (los OIDs con su descripción) de los dispositivos administrados. Al
igual que el agente reside en cada uno de los dispositivos gestionados. Las MIBs contienen
objetos que representan parámetros o variables de los equipos gestionados y se ordenan
de forma jerárquica siguiendo un esquema de árbol. Estas colecciones de objetos
relacionados, definidos como módulos de MIB, están escritas en un lenguaje especial,
definido en el estándar de Internet STD 58, y en los RFCs 2578, 2579 y 2580.
Cada elemento del árbol MIB se identifica por un OID (Object Identifier) numérico o de texto.
La lista completa de los objetos y su definición correspondiente está definida en el RFC
1212. En la Figura 1 se muestra el árbol y un ejemplo de representación numérica y en
modo texto del OID [1].
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 5 de 25
3.1.7. MIB-II
Un agente puede implementar varias MIBs, pero todos ellos implementan una en particular
llamada MIB-II (RFC1213). El principal objetivo de MIB-II es proporcionar una MIB
estandarizada capaz de almacenar datos comunes de gestión: información del sistema,
interfaces, protocolos, etc. para redes TCP/IP.
Los mensajes utilizados por SNMP poseen el formato mostrado en la Figura 3[1]:
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.
SNMP PDU: Indica el contenido de la PDU, el que depende de la operación que se
ejecute, que puede ser algún tipo de Request (como GetRequest, GetNextRequest
y SetRequest), un GetResponse o un Trap.
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 9 de 25
S Usado para distinguir una solicitud con una identificación única, entre las demás
solicitudes.
Error-status: Usado para indicar que ha habido una excepción mientras se
procesaba una solicitud.
Error-índice: Cuando el error-status es diferente de cero (hubo error) puede
proporcionar información adicional indicando que variable causó la excepción.
Campos variables: Una lista de nombre de variables con sus correspondientes
valores. Normalmente contiene los datos solicitados por una operación Get o Trap.
Como se aprecia en la Figura 3 un mensaje de tipo Trap tiene una estructura diferente:
Si se quisiera obtener información acerca de una red como un todo se deberían realizar
sucesivas consultas individuales a cada nodo conectado en la red. Esto supone un mayor
consumo de recursos de la red (tiempo de procesamiento en agentes y el gestor, y ancho
de banda consumido por las constantes consultas/respuestas SNMP). Con este motivo
surge RMON, un protocolo para la monitorización de redes como un conjunto.
RMON trabaja mediante un analizador de red, denominado monitor o sonda RMON. Está
diseñado para la monitorización “basada en el flujo”, mientras que SNMP para la
administración “basada en el dispositivo”. La sonda se encarga de solicitar, recoger y
guardar información sobre paquetes enviados o perdidos, velocidad de las líneas,
estadísticas del tráfico, etc. sobre el segmento de red en el que se encuentra (o una LAN o
WAN enteras), y ponerla a disposición del NMS.
La MIB de RMON se diseñó para permitir a las sondas RMON correr de forma offline, esto
es, sin necesidad de un NMS para recoger información sobre la red constantemente. Se
trata básicamente de una extensión a la MIB-II, lo que implica que para que RMON funcione,
SNMP debe estar habilitado y convenientemente configurado [1].
RMON1 definido en RFC 2819 (RMON2 en RFC 2021).
SMON, versión para redes conmutadas está definido en RFC 2613.
Se trata de una herramienta para monitorizar diversos parámetros de red y generar páginas
HTML que contienen imágenes (con formato PNG) que proporcionan una representación
gráfica en vivo de los datos que obtiene del protocolo SNMP o de scripts.
MRTG consiste en un script de Perl que utiliza el protocolo SNMP para controlar cualquier
variable que se elija, y un rápido programa en C que registra el tráfico de datos y crea los
gráficos para representarlos. Estos gráficos se incrustan entonces en páginas Web [1].
The Dude es software libre, no es necesario comprar. The Dude es una aplicación de
MikroTik que puede ayuda drásticamente la forma en que administra su entorno de red.
Analizará automáticamente todos los dispositivos dentro de las subredes especificadas,
dibujará y diseñará un mapa de sus redes, supervisará los servicios de sus dispositivos y
lo alertará en caso de que algún servicio tenga problemas.
Windows, Linux, MacOS y acceder al servidor The Dude que está ejecutándose en un
RouterOS. Es la opción recomendada.
Antes de la versión V4b3, The Dude era capaz de ejecutarse sin la necesidad de un
RouterOS, solo instalando una aplicación en Windows, Linux o MacOS era capaz de
reconocer y monitorear la red, pero debido a esta gran potencialidad muchas personas se
estaban beneficiando de las bondades de The Dude sin tener un Mikrotik con RouterOS por
lo que la compañía Mikrotik decidió quitar el lado del servidor en la aplicación. La última
versión estable de The Dude para operar con el lado del servidor en Windows fue la versión
3.6 que en la actualidad no se encuentra en desarrollo.
3.4. WIRESHARK
Wireshark es software libre, y se ejecuta sobre la mayoría de sistemas operativos Unix y
compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Android, y Mac OS
X, así como en Microsoft Windows.
Wireshark, antes conocido como Ethereal, es un analizador de protocolos utilizado para
realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de
software y protocolos, y como una herramienta didáctica. Cuenta con todas las
características estándar de un analizador de protocolos de forma únicamente hueca.
Características:
Mantenido bajo la licencia GPL.
Muy robusto, tanto en modo promiscuo como en modo no promiscuo.
Puede capturar datos de la red o leer datos almacenados en un archivo (de una
captura previa).
Basado en la librería pcap.
Tiene una interfaz muy flexible.
Gran capacidad de filtrado.
Admite el formato estándar de archivos tcpdump.
Reconstrucción de sesiones TCP
Se ejecuta en más de 20 plataformas.
Es compatible con más de 480 protocolos.
Puede leer archivos de captura de más de 20 productos.
Puede traducir protocolos TCP IP
Genera TSM y SUX momentáneamente
Wireshark permite al usuario colocar los controladores (drivers) de interfaz de red en modo
promiscuo (si es compatible con el controlador de interfaz de red) para que puedan ver todo
el tráfico visible en esa interfaz, incluido el tráfico de unidifusión no enviado a la dirección
MAC del controlador de esa interfaz de red. Sin embargo, al capturar con un analizador de
paquetes en modo promiscuo en un puerto de un conmutador de red, no todo el tráfico a
través del conmutador se envía necesariamente al puerto donde se realiza la captura, por
lo que capturar en modo promiscuo no es necesariamente suficiente para ver toda la red
tráfico. Duplicación de puertos o varios grifos de redextender la captura a cualquier punto
de la red. Los grifos pasivos simples son extremadamente resistentes a la manipulación.
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 12 de 25
5. Reactivos
Ninguno
6. Procedimiento
Nota general: En la presente guía se debe averiguar cada uno de los comandos y llenarlos
en el cuadro designado. Consisten en Implementar:
los agentes SNMP en router, switch, computador corriendo de forma independiente
una máquina virtual CentOS, computador con Windows 7 como Sistema Operativo
anfitrión.
Monitorear a los agentes como máquinas virtuales configuradas como NMS
corriendo en servidorNMS (ver Figura 4). OJO. Los NMS no correrán juntos, se
deben apagar uno para iniciar el otro. La configuración de los NMS se realizará en:
o Centos (ver sección 1 parte B).
o Windows server 2012 (ver sección 2).
o Mikrotik RouterOSx86 (ver sección 3 partes A y B).
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 13 de 25
1
Reemplaza X por la versión actual de los paquetes.
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 14 de 25
8. Una vez instalado, proceda a verificar si la instalación fue exitosa, para ello, use los
comandos consultados en el paso 5. Si efectivamente se instalaron los paquetes
deberá visualizar lo siguiente:
9. Una vez instalado los paquetes anteriores, se debe configurar el agente SNMPD. El
archivo de configuración se llama snmpd.conf. Consulte como acceder a este
archivo usando getedit nano o vim:
root@cliente:/# vim/etc/snmp/snmp.conf
A visualizar el archivo snmpd.conf verá que hay muchas opciones para configurarlo
además cada línea tiene comentarios, es recomendable crear un fichero nuevo y
vacío, pero se debe realizar un backup del archivo viejo para restaurar en caso de
problemas. Primero copie el archivo snmpd.conf snmpd.conf.BACKUP. Consulte
como copiar un archivo en CentOS y renombrarlo en una sola línea de comando.
cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig
mv /etc/snmp/snmpd.conf/etc/snmp/snmpd.conf.original
Verifique si el archivo snmpd.conf se ha copiado y renombrado con el comando
ls, sí la copia y el renombre fue exitoso deberá imprimir esto:
Ahora procederemos a dejar en blanco el archivo snmpd.conf, para ello, podemos usar
getedit, nano o vim: y borrar todo su contenido o bien es posible usar el siguiente para
crear un archivo snmpd.conf vacío.
touch snmpd.conf
de Acceso (ACL) local y miredlocal, la asignación de las ACLs a los grupos para
establecer las versiones de SNMP que tienen acceso, las ramas del árbol MIB que
pueden tener acceso los grupos creados y los permisos de acceso a cada grupo.
Escriba las líneas que se muestran en la siguiente figura. En los comentarios (#) se
explica qué quieren decir las diferentes líneas de código.
Como se puede observar en la figura anterior, la red en la que van a estar los equipos a los
que se van a monitorizar es la 192.168.1.0/24, a la que se le ha dado el nombre de
“miredlocal” y permiso de solo lectura. La contraseña o community string para dicha red
es “public”, aunque se puede cambiar por la que se desee.
Una vez introduzca las líneas de código señaladas en la Figura 7, guarde los cambios y
cierre el archivo snmpd.conf.
12. Reinicie el servicio de snmpd en CentOS para aplicar los cambios del archivo de
configuración. Consulte el comando:
13. Agregue el servicio snmpd a los servicios que se ejecutan en cuanto se inicia el
sistema operativo. Consulte el comando:
15. Después de instalar y verificar la ejecución, el siguiente paso que debe hacerse es
abrir el puerto del firewall, el protocolo snmp se ejecuta en el puerto UDP 161. Abra
el puerto usando el comando firewall-cmd consulte como se usa:
systemctl unmask firewalld
systemctl enable firewalld
systemctl START firewalld
# firewall-cmd --get-icmptypes
17. Reinicie el servicio de firewall para aplicar las configuraciones anteriores con el
comando
firewall-cmd –reload
18. Para verificar que la configuración funciona, ingrese en el Terminal los siguientes
comandos que deben devolver información acerca del sistema consultado
(reemplazar <DirIPCentOS> por la dirección IP asigna en el paso 11).
19. Investigue: ¿Qué información le entregan los dos comandos anteriores y qué
significa dicha información? ¿En qué directorio del SO se guardan las MIBs en
CentOS? ¿Qué otros comandos se pueden utilizar para verificar el funcionamiento
de SNMP y qué hacen dichos comandos?
20. Inicie la otra máquina virtual de CentOS que hará las veces de NMS y repita en ella
los pasos del 4 al 10 de esta guía.
21. Ya que esta máquina virtual va a servir como NMS, se le debe instalar el paquete
MRTG, para poder observar la información que llega a través de SNMP de manera
gráfica. Para ello, primero verifique si dicho paquete ya está instalado, utilizando el
comando. Consulte como usar el comando rpm para verificar la instalación del
servicio mrtg
23. Realice los pasos del 12 al 18 de esta guía. Conecte los dos computadores con las
máquinas virtuales a un switch Cisco.
24. Ahora se debe generar el directorio de trabajo de MRTG. Los pasos de configuración
del MRTG fueron obtenidos de [2]. Para ello, en el Terminal, introduzca el comando:
mkdir –p /var/www/mrtg/miredlocal
26. Para generar un nuevo archivo de configuración mrtg.cfg para supervisar las
direcciones IP <DirIPCentOS> y <DirIPservidorNMS>, se utiliza el siguiente
comando, donde “public” es la clave de acceso (community string) definida en la
configuración de SNMP (reemplace <DirIPCentOS> y <DirIPservidorNMS>
por las direcciones IPs asignadas):
cfgmaker --global "workdir: /var/www/mrtg/miredlocal" --global
"Options[_]: bits,growright" --output /etc/mrtg/mrtg.cfg
public@<DirIPservidorNMS> public@<DirIPservidorNMS>
27. Edite el archivo mrtg.cfg, creado en el punto anterior, a través del comando:
gedit /etc/mrtg/mrtg.cfg
28. Observe que dicho archivo se encuentra dividido en dos secciones principales,
delimitadas por “##########”, una correspondiente a la máquina virtual con la
dirección <DirIPservidorNMS> y la otra correspondiente a la máquina virtual con
la dirección <DirIPCentOS>, donde se especifica la información de Análisis de
Tráfico de cada máquina virtual que será desplegada por el mrtg.
29. Es hora de agregar algunos componentes de hardware para que sean visualizados
en el MRTG, se agregará la visualización del consumo de la memoria RAM y la
carga del sistema. Transcriba las líneas correspondientes a la memoria RAM y la
carga del sistema, al final de la sección de cada equipo monitoreado, reemplazando
la palabra <DirIPCentOS> por la dirección IP del equipo (192.168.1.X o
192.168.1.X según corresponda), para que se puedan monitorear la memoria RAM
y la carga del sistema en cada equipo. Además, debe consultar para reemplazar:
####RAM
LoadMIBs: /usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Target[<DirIPCentOS>_mem]: <OIDtotalMemoriaRAMusada>&<OIDtotalMemoriaRAMinstalada>:public@<DirIPCentOS>
PageTop[<DirIPCentOS>_mem]:<h1>Memoria RAM libre </h1>
Options[<DirIPCentOS>_mem]: nopercent,gauge,growright
Title[<DirIPCentOS>_mem]: Memoria Libre
MaxBytes[<DirIPCentOS>_mem]: 265300000000
YLegend[<DirIPCentOS>_mem]: bytes
ShortLegend[<DirIPCentOS>_mem]: bytes
LegendI[<DirIPCentOS>_mem]: Libre
Legend0[<DirIPCentOS>_mem]: Total
Legend1[<DirIPCentOS>_mem]: Memoria libre
Legend2[<DirIPCentOS>_mem]: Memoria total
30. Como los gráficos generados por mrtg se pueden visualizar a través de páginas
web, se debe tener instalado el paquete httpd. Verifique que está instalado a través
del comando:
rpm –q httpd
De lo contrario, instale este paquete como se hizo con los paquetes anteriores.
31. Para crear la página web index.html con el archivo de configuración MRTG
especificado, se ejecuta el siguiente comando:
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 23 de 25
32. El paquete de MRTG incluye un guión para crond, el cual se instala en la ruta
/etc/cron.d/mrtg, de modo que éste ejecute MRTG, de forma automática, cada 5
minutos. Si se quiere comprobar la configuración solo es necesario esperar algunos minutos
y consultar los resultados. Si se quiere generar un reporte en el momento, utilice el siguiente
comando:
env LANG=C mrtg /etc/mrtg/mrtg.cfg
33. Se debe reiniciar el servico httpd (Apache) a fin de cargar la configuración necesaria
y especificada en el archivo /etc/httpd/conf.d/mrtg.conf, la que permitirá
acceder hacia los reportes de MRTG a través de interfaz por protocolo http. Esto se
hace a través del comando:
34. Se pueden observar los resultados con cualquier navegador web examinando el
directorio /var/www/mrtg/miredlocal/index.html del sistema de archivos o bien
accediendo a través de http://127.0.0.1/mrtg/miredlocal/index.html, como se
muestra en la siguiente figura. ¿Qué información se despliega al hacer clic sobre
cada una de las gráficas?
35. Genere tráfico en las dos máquinas virtuales y utilice diferentes aplicaciones y
verifique cómo van cambiando las gráficas. Use el comando para que las graficas
las actualice MRTG
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 24 de 25
40. Investigue cómo configurar JFFNMS en la máquina virtual de Windows Server 2012.
A partir de la red implementada en Figura 4 desconecte la máquina virtual CentOS
de servidorNMS e inicie en ese mismo computador la máquina virtual de Windows
Server 2012 y monitoree los PCs (CentOS y Windows 7) y los dispositivos de red
que hacen parte de la red desde el NMS en Windows Server 2012 (JFFNMS)
Login: admin
Password: (en blanco)
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 25 de 25
Acceda a la terminal de Mikrotik para proceder a configurarla por comandos, recuerde que
la interfaz gráfica que ofrece WinBox está muy ligada al orden de los comandos.
45. Asigne la dirección IP y la máscara, en este caso, la Mikrotik virtualizada puede tener
un puerto Ethernet, ya que se recomienda que cada puerto del Mikrotikx86 este en
adaptador puente con una interfaz física diferente. Consulte el comando para
asignar una dirección IP con mascara de subred a una interfaz en Mikrotik.
46. Realice la descarga del paquete NPK The Dude Server de la página oficial de
Mikrotik de acuerdo al tipo de plataforma y la versión que se esté ejecutando, ver la
siguiente figura. Consulte cuál es el comando para obtener la versión de RouterOS.
48. Habilite el The Dude Server con el comando y verifique que este corriendo
49. Estando el servidor The Dude activado, nos conectaremos a él usando la aplicación
cliente que nos es más que una interfaz de visualización y gestión del The Dude
Server. Antes de ello se debe descargar la aplicación dude-install-6.40.3.exe de la
página oficial e instalarse.
50. Una vez instalado The Dude Client, debemos asignar una dirección IP al equipo
donde esté instalado de The Dude Client de forma que quede en LAN con el
RouterOS que ejecuta The Dude Server.
51. Conectado The Dude Client al The Dude Server, solo resta realizar un escaneo de
la red y a media que vaya encontrando dispositivos los va listando de forma gráfica.
En la siguiente figura se muestra como se debe realizar la configuración del primer
descubrimiento.
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 27 de 25
52. Consulte:
¿Cómo se instalan nuevas MIB en The Dude?
¿Cómo se modifican o se agregan los community string en The Dude Server?
53. Cumpla el reto de monitorear un enlace fijo con dispositivos Ubiquiti NanoLocoM2
(ver siguiente imagen) conectados al Switch1. Debe Instalar descargar la MIBs de
Ubiquiti NanoLocoM2 e instalarlas en The Dude Server.
54. El The Dude Server debe ser capaz de monitorear Router1, Switch1, Centos,
Windows7, Ubiquiti 1 y Ubiquiti 2 a través de los agentes SNMP activados
anteriormente. El docente le ayudará a configurar el agente SNMP en los
dispositivos ubiquit.
7. Nivel de Riesgo
Bajo
Código FLA-23 v.00
Guía Unificada de Laboratorios
Página 28 de 25
8. Bibliografía