Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red:
http://www.alcancelibre.org/Jabber ID: darkshram@jabber.org
Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
© 1999-2007 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.
Introducción.
Acerca de SNMP.
SNMP (Simple Network Management Protocol o Protocolo Simple de administración de red) es uno protocolos del conjunto definido por la Fuerza de Trabajo en Ingeniería de Internet (IETF o Internet Engineering Task Force), clasificada en el nivel de aplicación del modelo TCP/IP, y que está diseñado para facilitar el intercambio de información entre dispositivos de red y es ampliamente utilizado en la administración de redes para supervisar el desempeño, la salud y el bienestar de una red, equipo de computo y otros dispositivos.
URL:
http://tools.ietf.org/html/rfc1157.
Acerca de Net-SNMP.
Net-SNMP, el equipamiento lógio utilizado en este documento, es un conjunto de aplicaciones utilizados para implementar SNMP v1, SNMP v2c y SNMP v3 utilizando IPv4 y/o IPv6. El proyecto fue iniciado como un conjunto de herramientas SNMP por Steve Waldbusser en la CMU (Carnegie Mellon University), Pittsburgh, Pennsylvania, EE.UU., en 1992. Tras ser abandonado, fue retomado por Wes Hardaker en la UCDavis (University of California, Davis), renombrado como UCD-SNMP y mejorado para cubrir las necesidades del Departamento de Ingeniería Eléctrica de dicha institución. Tras dejar la universidad, Hardaker continuó el proyecto, cambiando el nombre de éste a Net-SNMP.
URL:
http://net-snmp.sourceforge.net/Equipamiento lógico necesario.
Instalación a través de yum.
Si utiliza CentOS 4 o White Box Enterprise Linux 4, solo se necesita realizar lo siguiente para instalar o actualizar el equipamiento lógico necesario:yum -y install net-snmp net-snmp-utils
Instalación a través de up2date.
Si se utiliza Red Hat™ Enterprise Linux 4, solo bastará realizar lo siguiente para instalar o actualizar el equipamiento lógico necesario:up2date -i net-snmp net-snmp-utils
Procedimientos
Fichero de configuración /etc/snmp/snmpd.conf.
El fichero /etc/snmp/snmpd.conf que se instala junto con el paquete, y puede resultar para algunos una verdadera maraña de comentarios y opciones de todo tipo. Lo más recomendable será crear un fichero nuevo y limpio de contenido para poder partir de algo más simple y funcional.cd /etc/snmp
mv snmpd.conf snmpd.conf-OLD
touch snmpd.conf
Listas de control de acceso.
Se deben crear las listas de control de acceso (ACL o Access Control List) correspondientes en el fichero /etc/snmp/snmpd.conf, las cuales servirán para definir lo que tendrá acceso hacia el servicio snmpd. A una de estas listas se le otorgará permiso de acceso de lectura y escritura, para lo que sea necesario en relación con administración, y a la otra de solo lectura. Por razones de seguridad solo la interfaz 127.0.0.1 estará en la lista de lectura escritura. Se otorgará permiso de acceso de solo lectura a una red o bien a una dirección IP en la otra lista de control de acceso.
Considerando lo anterior, se podrían agregar un par de líneas como las siguientes:com2sec local 127.0.0.1/32 Cl4v3-d3-Acc3s0
com2sec miredlocal 192.168.1.0/24 Cl4v3-d3-Acc3s0
En lo anterior la primera línea significa que habrá una lista de control de acceso denominada «local» y que corresponderá solo a 127.0.0.1/32, asignando Cl4v3-d3-Acc3s0 como clave de acceso. La segunda línea hace lo mismo pero definiendo a la red 192.168.1.0/24. Se puede definir lo que uno guste mientras no sea la clave de root, esto debido a que dicha clave se transmite a través de la red en forma de texto simple (es decir, sin cifrar).
Definición de grupos.
Se crean al menos dos grupos: MyRWGroup y MyROGroup. El primero será un grupo al que se asignarán más adelante permisos de lectura escritura y el segundo será un grupo al que posteriormente se asignarán permisos de solo lectura. Por cada grupo se asignan tres líneas que especifican el tipo de acceso que se permitirá en un momento dado a un grupo en particular. Es decir, MyRWGroup se asocia a local y MyROGroup a miredlocal.#Se asigna local al grupo de lectura escritura
group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
#Se asigna miredlocal al grupo de solo lectura
group MyROGroup v1 miredlocal
group MyROGroup v2c miredlocal
group MyROGroup usm miredlocal
Ramas permitidas.
Se especifican las ramas que se van a permitir ver a través del servicio. Lo más común, para, por ejemplo, utilizarse con MRTG, es lo siguiente:## name incl/excl subtree mask(optional)
view all included .1 80
Asignación de permisos a los grupos.
Se debe especificar que permisos tendrán los dos grupos, MyROGroup y MyRWGroup. Son de especial interés las últimas columnas.## 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
Parámetros de carácter informativo.
Se definen dos parámetros de carácter informativo para que cuando utilicen aplicaciones cliente como MRTG se incluya algo de información acerca de que sistema se está accediendo.syslocation Servidor Linux en SU-SERVIDOR.algun-dominio.net
syscontact Administrador (fulano@algun-dominio.net)
Un ejemplo funcional de configuración.
El ejemplo que mostramos a continuación se utiliza en todas los equipos que posee el autor en casa y en la oficina. Solo hay que reemplazar el valor redlocal por lo que uno considere apropiado y reemplazar el valor 192.168.1.0/24 por el valor de la red o la dirección IP desde donde se requiera acceder con un cliente snmp, como MRTG.# Listas de control de acceso (ACL)
## sec.name source community (alias clave de acceso)
com2sec local 127.0.0.1/32 Cl4v3-d3-Acc3s0
com2sec miredlocal 192.168.1.0/24 Cl4v3-d3-Acc3s0
#Se asigna ACL al grupo de lectura escritura
group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
#Se asigna ACL al grupo de solo lectura
group MyROGroup v1 miredlocal
group MyROGroup v2c miredlocal
group MyROGroup usm miredlocal
# Ramas MIB que se permiten ver
## name incl/excl subtree mask(optional)
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
# Información de Contacto del Sistema
syslocation Servidor Linux en amdk6.linuxparatodos.com.mx
syscontact Administrador (fulano@algun-dominio.net)
Si es necesario añadir más equipos para que accedan al servicio snmpd, solo hay que hacer lo siguiente:• Agregar una ACL con un nombre único. Ejemplo: com2sec micueva 192.168.1.251 Cl4v3-d3-Acc3s0
•
Agregar un juego reglas que asignen al grupo, en este caso micueva, con lo siguiente:group otrogrupo v1 local
group otrogrupo v2c local
group otrogrupo usm local
•
Agregar una línea donde se establece que permisos tendrá el grupo otrogrupo. En este ejemplo, va a ser de solo lectura:access MyROGroup "" any noauth exact all none none
Iniciar, detener y reiniciar el servicio snmpd.
Para ejecutar por primera vez el servicio snmpd, utilice:service snmpd start
Para hacer que los cambios hechos tras modificar la configuración surtan efecto, utilice:service snmpd restart
Para detener el servicio snmpd utilice:service snmpd stop
Agregar el servicio snmpd al arranque del sistema.
Para hacer que el servicio de snmpd esté activo con el siguiente inicio del sistema, en todos los niveles de corrida (2, 3, 4, y 5), se utiliza lo siguiente:chkconfig snmpd on
Comprobaciones.
Considerando, como ejemplo, que sea signó como clave de acceso Cl4v3-d3-Acc3s0 en un sistema cuya dirección IP es 192.168.1.254, para probar si la configuración funciona, solo hay que ejecutar los dos siguiente mandatos a fin verificar que devuelvan información acerca del sistema consultado.snmpwalk -v 1 192.168.1.254 \
-c Cl4v3-d3-Acc3s0 system
snmpwalk -v 1 192.168.1.254 \
-c Cl4v3-d3-Acc3s0 interfaces
Modificaciones necesarias en el muro cortafuegos.
Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir los puerto 161 y 162 por UDP (SNMP y SNMPTRAP, respectivamente).
Las reglas para el fichero /etc/shorewall/rules de Shorewall en un sistema con una zona (net), correspondería a lo siguiente:#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT PORT(S)1
ACCEPT net fw udp 161,162
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Las reglas para el fichero /etc/shorewall/rules de Shorewall en un sistema con dos zonas (net y loc), donde solo se va a permitir el acceso al servicio snmpd desde la red local, correspondería a lo siguiente:#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT PORT(S)1
ACCEPT loc fw udp 161,162
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
MRTG (multi router trafic graph) es una utilidad que nos sirve para representar datos. Aunque inicialmente fué creado para representar de forma gráfica el tráfico que atravesaba los interfaces de los routers, se puede usar para representar prácticamente cualquier dato.Como ejemplo de cosas que se pueden monitorizar con mrtg podemos ver los datos meterológicos del observatorio del Teide, o una monitorización completa de un sistema, incluyendo tráficos, carga de procesador, temperatura del micro...etc.
MRTG captura los datos de dos maneras: - mediante snmp
- mediate scripts de usuario
El método que yo uso es mediante snmp, por lo que las configuraciones que se mostrarán serán para este método, aunque al final comentaré un poco como se puede hacer con los scripts. Además para los que no se quieran complicar la vida, hay varios scripts ya hechos y listos para usar. INSTALACIÓN Y CONFIGURACIÓN DE SNMP
Primero, ¿que es snmp?
Pues snmp es el acrónimo de Simple Network Management Protocol, algo así como un protocolo que nos permite gestionar la red. Esto se hace de la siguiente manera: snmp mantiene y gestiona una base de datos, llamada mib, dentro de la cual están actualizados cientos de parámetros del sistema. Snmp permite hacer consultas a esta base de datos, e incluso modificar sus valores. Otro día escribiremos algo más de snmp, de momento simplemente se indica como instalarlo y que hay que poner en el fichero de configuración para que mrtg lo pueda usar.
Las instrucciones y las localizaciones de los archivos son válidos para debian woody, la que uso yo, aunque los usuarios de otras distribuciones no creo que lo tengan complicado para seguir los ejemplos.
Para los que quieran profundizar en snmp pueden ver este artículo
Lo primero que vamos a hacer es instalar el software:
#apt-get install snmp snmpd
Desempaquetando snmp (de .../archives/snmp_4.2.3-2_i386.deb) ...
Seleccionando el paquete snmpd previamente no seleccionado.
Desempaquetando snmpd (de .../snmpd_4.2.3-2_i386.deb) ...
Configurando snmp (4.2.3-2) ...
Configurando snmpd (4.2.3-2) ...
Debian now uses the UCD SNMP agent/daemon. Since the new agent uses
an entirely new configuration file format, any configuration you may
have previously had can not be automatically updated and must be
replaced. Consequently, a security-conscious configuration will be
installed by default. Please read the snmpd.conf(5) manual page and
then edit /etc/snmp/snmpd.conf accordingly to change the configuration
to suit your needs.
Starting network management services: snmpd snmptrapd.
Lo anterior viene a decir que los paquetes se han instalado y configurado, y que por defecto me ha puesto una configuración segura.
Ahora vamos a crear una comunidad de lectura para snmp, de esta manera podremos consultar al snmpd. Para ello en /etc/snmp/snmp.conf incluimos las siguiente línea en negrita en el apartado "Acces Control"
...
...
# rocommunity: a SNMPv1/SNMPv2c read-only access community name
# arguments: community [default|hostname|network/bits] [oid]
rocommunity miclave
...
...
De esta manera, hemos creado una comunidad de lectura cuya clave de acceso es miclave. En otras distribuciones puede que haya creadas por defecto dos comunidades con claves "public" y "private". Si es así es mejor cambiar las claves...
Activamos esta configuración ejecutando como root
#/etc/init.d/snmpd reload
para comprobar que snmp está trabajando bien, podemos ejecutar como usuario raso
$snmpwalk localhost miclave system
system.sysDescr.0 = Linux hradcany 2.4.18 #1 lun oct 14 23:25:43 CEST 2002 i586
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (21379) 0:03:33.79
system.sysContact.0 = Root (configure /etc/snmp/snmp.local.conf)
......
.....
.....
Vemos que salen un montón de variables de la mib y su valor. Cada una de esas variables nos da información acerca de algún parámetro del sistema, y esto es lo que aprovechará mrtg para obtener los valores a representar gráficamente.
Pues ya tenemos funcionando snmp y con una comunidad de lectura con clave de acceso. Ahora a por mrtg.
INSTALACIÓN Y CONFIGURACIÓN DE MRTG
Instalamos el software:
# apt-get install mrtg
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
mrtg
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/434kB of archives. After unpacking 1179kB will be used.
Preconfiguring packages ...
Seleccionando el paquete mrtg previamente no seleccionado.
(Leyendo la base de datos ...
52975 ficheros y directorios instalados actualmente.)
Desempaquetando mrtg (de .../mrtg_2.9.17-4_i386.deb) ...
Configurando mrtg (2.9.17-4) ...
Lo único que me preguntó en la configuración fué si quería cambiar el propietario del archivo de configuración, y simplemente le dejé la opción por defecto.
Para configurar mrtg usamos una utilidad del propio programa, llamada cfgmaker, que nos va a facilitar este paso. Suponemos que vamos a monitorizar nuestro propio ordenador, pero no habría ningún problema en monitorizar cualquier otro aparato, otro ordenador, un router..., que tuviera snmp. Además, al usar mrtgconfig podemos pasarle alguno parámetros interesantes, pero que no nos vamos a parar en ellos (ver el man):
#cfgmaker --community miclave --output /etc/mrtg.cfg localhost
--base: Get Device Info on miclave@localhost:
--base: Vendor Id:
--base: Populating confcache
--snpo: confcache miclave@localhost: Descr lo --> 1
--snpo: confcache miclave@localhost: Descr eth0 --> 2
--snpo: confcache miclave@localhost: Descr dummy0 --> 3
--snpo: confcache miclave@localhost: Descr tunl0 --> 4
--snpo: confcache miclave@localhost: Descr gre0 --> 5
--snpo: confcache miclave@localhost: Descr ipsec0 --> 6
...
... etc
Esto nos crea, en /etc/mrtg.cfg, el archivo de configuración que nos permitirá monitorizar el tráfico de red en todas las interfaces de localhost, o del sistema usado.
Esa monitorización se sigue a través de una página web. En mi caso he decidido que los archivos de esa página estén en /var/www/mrtg. Para crear las imágenes y una página html básica ejecutamos otra utilidad que viene con mrtg que se llama indexmaker:
#indexmaker --output /var/www/mrtg/index.html /etc/mrtg.cfg
Ya está... ahora podríamos esperar 5 o 10 minutos y con nuestro navegador favorito abrir esa página y ver la pinta que tiene. Mas tarde podremos personalizarlo un poco.
MONITORIZANDO CUALQUIER VARIABLE DE LA MIB
cfgmaker nos deja preparado el archivo de configuración para ver el tráfico en las interfaces de red, pero lo podemos ampliar para monitorizar cualquier cosa que esté contemplada por la mib. Lo vemos con un ejemplo: Vamos a seguir el tamaño ocupado en el disco duro a lo largo del tiempo.
Para ello vamos a ver que pinta tiene una entrada de monitorización del /etc/mrtg.cfg
### Interface 2 >> Descr: 'eth0' | Name: '' | Ip: '192.168.1.3' | Eth: '00-00-e8-ec-13-a3' ###
Target[localhost_2]: 2:miclave@localhost:
SetEnv[localhost_2]: MRTG_INT_IP="192.168.1.3" MRTG_INT_DESCR="eth0"
MaxBytes[localhost_2]: 1250000
Title[localhost_2]: Traffic Analysis for 2 -- hradcany
...
...
Vemos como define el objetivo a montorizar, el Target, con
Target[localhost_2]: 2:miclave@localhost:
Esto quiere decir que le va a preguntar al snmp por el tráfico del segundo interfaz (eth0), y es lo que va a representar. Como hemos dicho antes, por defecto, el cfgmaker nos prepara al mrtg para monitorizar tráfico de red. Pero en general, la forma de decirle que queremos que nos pinte cualquier variable de la mib, es así:
Target[etiqueta]: variable1&variable2:clave@host:
en donde etiqueta es un nombre que le ponemos nosotros, variable1 y variable2 son dos posibles variables de la mib a representar en el mismo gráfico, y clave y host son la clave de la community snmp y el host que queremos monitorizar.
Para que os hagáis una idea de la cantidad de información que puede gestionar snmp a través de la mib, podéis ejecutar:
$snmpwalk -On -v 1 192.168.10.1 -c p14180893 .
y veréis que hay de todo. Bueno, ya que estamos con la ocupación del disco, vamos a buscar algo por la mib:
$snmpwalk -v 1 192.168.10.1 -c p14180893 disk
$snmpwalk localhost miclave dsk
enterprises.ucdavis.dskTable.dskEntry.dskIndex.1 = 1
enterprises.ucdavis.dskTable.dskEntry.dskPath.1 = /
enterprises.ucdavis.dskTable.dskEntry.dskDevice.1 = /dev/hda1
enterprises.ucdavis.dskTable.dskEntry.dskMinimum.1 = 10000
enterprises.ucdavis.dskTable.dskEntry.dskMinPercent.1 = -1
enterprises.ucdavis.dskTable.dskEntry.dskTotal.1 = 1152828
enterprises.ucdavis.dskTable.dskEntry.dskAvail.1 = 674296
enterprises.ucdavis.dskTable.dskEntry.dskUsed.1 = 419972
enterprises.ucdavis.dskTable.dskEntry.dskPercent.1 = 38
enterprises.ucdavis.dskTable.dskEntry.dskPercentNode.1 = 19
enterprises.ucdavis.dskTable.dskEntry.dskErrorFlag.1 = 0
enterprises.ucdavis.dskTable.dskEntry.dskErrorMsg.1 =
Parece que la variable enterprises.ucdavis.dskTable.dskEntry.dskUsed.1 = 419972 nos da el tamaño del disco ocupado, casi 420 MB. Mrtg conoce algunas variables por su nombre, pero puede acceder a todas por su número, así mejor obtenemos el número de la variable que es...
$snmpwalk -On -v 1 192.168.10.1 -c p14180893 disk
.1.3.6.1.4.1.2021.9.1.1.1 = 1
.1.3.6.1.4.1.2021.9.1.2.1 = /
.1.3.6.1.4.1.2021.9.1.3.1 = /dev/hda1
.1.3.6.1.4.1.2021.9.1.4.1 = 10000
.1.3.6.1.4.1.2021.9.1.5.1 = -1
.1.3.6.1.4.1.2021.9.1.6.1 = 1152828
.1.3.6.1.4.1.2021.9.1.7.1 = 674264
.1.3.6.1.4.1.2021.9.1.8.1 = 420004
.1.3.6.1.4.1.2021.9.1.9.1 = 38
.1.3.6.1.4.1.2021.9.1.10.1 = 19
.1.3.6.1.4.1.2021.9.1.100.1 = 0
Esos números son los que entiende mrtg. Así nos prepararemos una entrada a medida para el /etc/mrtg.cfg, tomando como modelo otra entrada prefabricada por el cfgmaker, que será algo así:
Target[hda1]: 1.3.6.1.4.1.2021.9.1.8.1&1.3.6.1.4.1.2021.9.1.8.1:miclave@localhost:
SetEnv[hda1]: MRTG_INT_IP="192.168.1.3" MRTG_INT_DESCR="Disco ocupado"
Title[hda1]: Disco duro
Factor[hda1]: 1000
YTicsFactor[hda1]: 1000
MaxBytes[hda1]: 1152828
Options[hda1]: gauge, noinfo
YLegend[hda1]: Ocupado
ShortLegend[hda1]: bytes
Legend1[hda1]: Disco ocupado
....
.....
Nótese que al usar la misma variable dos veces, se va a pintar únicamente un gráfico. Lo normal es tener dos variables distintas y pintar dos gráficos en la misma imagen. Las opciones gauge y noinfo son para lo siguiente: gauge le dice a mrtg que su valor es un contador absoluto, o sea que su valor es siempre el que tiene que representar. En caso contrario, mrtg cree que es un contador normal, con lo cual resta el valor actual del valor anterior y toma esa resta como el valor que tiene que representar, y noinfo es para que no sea demasiado elocuente con la información que muestra. Ahora volvemos a ejecutar indexmaker y en unos minutos, en cuanto empiece a haber datos ya veremos una nueva gráfica.
MRTG CON SCRIPTS.
Además de snmp para monitorizar valores, podemos usar nuestro propio programa de captura de datos y pasarle estos datos a mrtg para que los represente gráficamente. Así, en vez de pasarle la variable de la mib a controlar, le pasamos el script de captura de datos de esta manera:
Target[ezwf]: `/usr/local/bin/nuestroscript`
Nuestro script debe devolver 4 líneas, la primera es el valor del contador para la primera variable, la segunda lo mismo para la segunda variable, la tercera una cadena indicando el tiempo de funcionamiento (uptime), y la cuarta el nombre de lo que estamos monitorizando.
Aunque nunca los he usado, comentar que hay unos paquetes, en debian se llaman mrtgutils y mrtg-contrib, que hacen uso de esta técnica para obtener diversos parámetros y representarlos con mrtg sin necesidad de usar snmp.
MAS INFORMACIÓN
Indispensable si se quiere profundizar en este tema:
man mrtg
man mrtgconfig
man indexmaker
y sobre todo, para el fichero de configuración de mrtg
man reference
Algunas cosas (no muchas) que monitorizo en el nodo novemesto de escomposlinux.org
P.D. Todo esto surgió porque SinnerP me "obligó" a escribirlo al comentar yo algo de la configuración de mi mrtg en el canal irc de ecol. Gracias Sinner.