Check Network Device: plugin Nagios para chequear recursos en dispositivos de red
Desde hace un tiempo vengo trabajando en un plugin para Nagios que me permita chequear recursos básicos de dispositivos de red. Me focalicé en el monitoreo de dispositivos Cisco, con los cuales trabajo a diario y es mi principal interés, pero la idea es que soporte diversos dispositivos en el futuro.

El plugin permite chequear los siguientes recursos:
  • Carga de CPU
  • Temperaturas
  • Estados de los FANs
  • Uso de Memoria
  • Estado de interfaces de red (up/down)
  • Ancho de banda (input y output) en interfaces de red
Además de chequear el estado (con umbrales warning y critical), también retorna información contabilizable para poder graficar los resultados con PNP4Nagios u otros plugins. Los valores posibles de graficar son carga de CPU, memoria, temperatura y ancho de banda de las interfaces.

El monitoreo se realiza por SNMP, por lo cual este protocolo debe estar activo en los dispositivos y aceptar conexiones desde el servidor Nagios. Además, el script utiliza la versión en python de la librería Net-SNMP, la cual se encuentra en los siguientes paquetes:
  • python-netsnmp // debian
  • net-snmp-python // Red Hat
Actualmente el proyecto se encuentra en Launchpad y pueden descargar la última versión desde la siguiente dirección: https://launchpad.net/check-net-device/+download


Opciones

Se proveen varias opciones que pueden resultar abrumantes al principio, pero una vez que se entienden, no son complicadas..

El uso de check_net_device es el siguiente:
check_net_device -H <ip_address> -C <community> <-t -t device_type | -i interface_ID> [-o check_option] [-w warning] [-c critical] [-P log_path]
donde las opciones obligatorias son:
  • -H; --host <ip_address>:  es la IP del host a chequear.
  • -C; --community <community>: comunidad SNMP definida en el dispositivo.
  • -t; --type <device_type>: tipo de dipositivo a chequear. Los valores permitidos en la versión 0.4 son cisco y bc (de BlueCoat), pero sólo cisco está implementado.
  • -i; --interface <interface_id>: se utiliza para chequear estado de interfaces y anchos de banda. El ID dado por el fabricante a la interfaz que se desea chequear. El ID de la interfaz se puede encontrar consultando el OID 1.3.6.1.2.1.31.1.1.1.1 (ifName) con snmpwalk, y sólo la última parte del OID se necesita como parámetro. Ejemplo: snmpwalk -v2c -c <community> <host ip> 1.3.6.1.2.1.31.1.1.1.1
  • -o; --option <check_option>: especifica el recurso a chequear. 
  • Las opciones disponibles son con el argumento -t son:
    • env: check environmental status. On Cisco it includes temperatures and fan status.
    • cpu: check status and return CPU load.
    • memory: check memory status, and return percentage usage.
    Con el argumento -i, las opciones disponibles son:
    • ifstatus: check the interface status, returning OK or DOWN.
    • ifbw: check input/output bandwidth and return usage.
  • -w; --warning <value>: umbral para reportar un warning. Dependiendo del tipo de chequeo, puede ser un porcentaje o un número.
  • -c; --critical <value>: umbral para reportar un estado crítico. Dependiendo del tipo de chequeo, puede ser un porcentaje o un número.
  • -P; --log-path <path to dir>: necesario para utilizar la opción "-i <interface id> -o ifbw", dado que esta opción necesita un directorio donde guardar los valores de ancho de banda leídos. El usuario que ejecute este comando (usualmente llamado nagios) necesita permiso de escritura en el directorio especificado.
Nota:
  • -t y -i no se usan al mismo tiempo, dado que los chequeos de interfaces son independientes del tipo de dispositivo. Esta opción se puede utililizar para chequear cualquier tipo de dispositivo.
  • -w y -c son opcionales, dado que el script posee valores ya definidos para estados de warning y critical.

Ejemplos

Uso de CPU:
$ ./check_net_device.py -C public -H 192.168.0.1 -t cisco -o cpu
OK -  CPU Load: 1% | 'CPU Load'=1%;60;80
Ancho de banda:
$ ./check_net_device.py -C public -H 192.168.0.1 -i 2 -o ifbw -P /tmp/
OK -  In: 1.08 Mb/s, Out: 1.49 Mb/s | 'In'=1129850B;629145600;83886080  'Out'=1561893B;629145600;83886080
Estado de interfaces:
$ ./check_net_device.py -C public -H 192.168.0.1 -i 2,3,4,6
OK -  All Interfaces UP | Gi1/1: Up, Gi1/2: Up, Fa2/1: Up, Fa2/3: Up

Ejemplos de gráficos con PNP4Nagios, a partir de valores retornados por check_net_device:

Ancho de banda:


Carga de CPU:




Otro Plugin?

Alguno seguramente dirá, ya existen plugins para monitorear equipos de red. Pues si, pero desarrollé este script por tres grandes razones:
  • No encontré ningún plugin que realice todo esto junto:
    • Chequeo de estado de CPU, memoria, interfaces, ancho de banda, temperatura y fans.
    • Entrega de información de performance para poder graficar los valores obtenidos.
    • Sirva para múltiples dispositivos. Los que chequean múltiples tipos de dispositivos, no permiten muchos tipos de chequeos (por ejemplo check_snmp_environment).
  • Los plugins que vi están todos escritos en perl, y si bien perl me parece un lenguaje fantástico, se me hace difícil de seguir, con lo cual, me dificulta la posibilidad de agregar funcionalidad a scripts existentes. Creo que un script en python facilitará que muchos lo extiendan, ya que python es más fácil de aprender.
  • Me gusta programar =)
Espero que les sea útil. Si encuentran errores, por favor reportar, trataré de solucionarlos lo más rápido posible.
POODLE Attack (die SSLv3!)
Leyendo noticias de seguridad, me topé con este interesante ataque que afecta la versión SSLv3 y permite a un atacante desencriptar porciones de tráfico HTTPS, como por ejemplo cookies.

Últimamente al pobre protocolo no le ha ido muy bien, basta recordar el mortal Heartbleed descubierto hace unos meses, y otros ataques como BEAST y CRIME descubiertos hace un par de años, o Lucky-13, por citar algunos.

Una de las personas que participó en el descubrimiento de esta vulnerabilidad es Thai Duong, quien también participó (junto a Juliano Rizzo) en el descubrimiento de BEAST y CRIME. En este caso, Thai trabajó con otros empleados de Google (Bodo Möller y Krzysztof Kotowicz) para el descubrimiento.

Como mencioné al principio, el ataque afecta sólo a SSLv3, el cual está obsoleto desde hace unos años, pero que todavía es soportado por muchos servidores y browsers por compatibilidad. La versión más actual del protocolo es TLSv1.2, pero los clientes pueden negociar con el servidor una versión inferior del protocolo, en caso de no soportar esta última.

El ataque no es tan directo como Heartbleed, ya que es necesario realizar previamente un ataque Man-in-the-Middle (MiTM). Pero un ataque MiTM no es tan complejo si tenemos acceso a la red de la víctima, o si accedemos a una red WiFi pública (hoteles, bares, etc).

Los detalles del ataque los pueden leer en el paper original, pero básicamente explota la encripción CBC utilizada en SSLv3, debido a la forma en que este algoritmo utiliza los paddings para completar bloques.

Según comentan en el paper, la única forma de evitar este ataque es eliminando el uso de SSLv3. En el mismo, proponen utilizar el mecanismo TLS_FALLBACK_SCSV para la negociación, en clientes y servidores. Utilizando TLS_FALLBACK_SCSV, el servidor siempre utilizará la versión más actual del protocolo habilitada en el mismo, rechazando cualquier intento de conexión con una versión inferior. Obviamente, si el servidor no soporta una versión superior a SSLv3, entonces será vulnerable igual.

Existen varios mecanismos para averiguar qué versiones de SSL/TLS soporta un servidor. Les dejo un par para que verifiquen sus servidores.

Una forma simple, es utilizar la capacidad de ejecución de scripts de NMAP, el cual todo administrador de seguridad tiene instalado:
$ nmap --script ssl-enum-ciphers -p 443 <IP Servidor>
Algo más avanzado es utilizar una herramienta dedicada a chequear conexiones SSL, denominada SSLyze, la cual pueden descargar aquí. Esta herramienta está escrita en python y se puede ejecutar sin instalarse:
$ python sslyze.py --regular <IP Servidor>:443
Finalmente y también muy interesante, es la herramienta web provista por Qualys, la cual chequea múltiples vulnerabilidades SSL, así como lista los protocolos soportados y genera un reporte. La misma se accede aquí.
Nagios: generar gráficos con PNP4Nagios
Hace tiempo que estoy trabajando con Nagios y MRTG, como pudieron observar en Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows, y  Monitoreo de ancho de banda en routers/switches/etc usando MRTG. Ambas herramientas me resultaron excelentes y me ayudan mucho en el monitoreo diario de la infraestructura de red.
Desde hace un tiempo vengo buscando la forma de integrar más gráficos en Nagios, y me pareció interesante utilizar MRTG para hacerlo. Esto es perfectamente posible y hasta comencé a trabajar en ello, pero luego descubrí PNP4Nagios y cambié la perspectiva.

Tal como cita la página oficinal:
PNP es un addon para Nagios que analiza datos de performance (performance data) provistos por los plugins y los almacena en bases de datos RRD.
Oye, eso suena similar a lo que MRTG hace. Pues claro, el acercamiento es similar, almacenar datos en bases de datos RRD y luego graficar a partir de ellos utilizando rrdtool. De forma similar trabajan Ntop y otras herramientas.

PNP4Nagios tiene una interfaz web muy atractiva y simple de usar, permitiendo seleccionar intervalos de tiempo de forma dinámica, navegar fácilmente entre servicios de hosts, y generar reportes en PDF. Tal vez una de las características más interesantes es la posibilidad de definir templates propios para indicarle la forma de evaluar y generar los gráficos. Dado que trabaja directamente con RRDTool, brinda todas las facilidades de graficación que esta herramienta provee.

Cabe destacar que para poder graficar datos, los plugins deben retornar información en el campo performance_data, y no todos los plugins lo hacen. Por suerte, quienes diseñan buenos plugins si entregan datos de performance. Estos datos deben tener un formato especial para que PNP pueda parsearlos y almacenarlos, pero esa discusión la dejaré para algún artículo sobre creación de plugins.
Para saber fácilmente si un plugin entrega datos de performance, pueden ejecutarlo desde la consola y ver si incluye el caracter pipe "|" en el resultado impreso. Todo lo que venga luego del pipe son datos de performance. Por ejemplo:
  $./check_icmp -H 10.6.143.101
  OK - 10.6.143.101: rta 1,593ms, lost 0%|rta=1,593ms;200,000;500,000;0; pl=0%;40;80;; rtmax=4,541ms;;;; rtmin=0,832ms;;;;
Este plugin entrega 4 datos de performance:
  - rta: tiempo de respuesta,
  - pl: porcentaje de pérdida de paquetes,
  - rtmax: tiempo máximo de respuesta,
  - rtmin: tiempo mínimo de respuesta.
 

Integración con Nagios

PNP4Nagios provee varios modos de integrarse con Nagios, cada uno con sus ventajas y desventajas:

  • Synchronous: cada vez que Nagios ejecuta un plugin, luego llama el script process_perfdata.pl para actualizar los valores de la base de datos RRD y el archivo XML correspondiente. La mayor desventaja de esta forma de integración es que Nagios ejecuta process_perfdata.pl cada vez que realiza un check de host o servicio.
  • Bulk: este modo permite realizar múltiples actualizaciones de datos de performance juntos. Nagios escribe en un archivo temporal los datos obtenidos en cada check, y a intervalos definidos, Nagios ejecuta el script process_perfdata.pl.
  • Bulk with NPCD: desde el punto de vista de Nagios, es la mejor opción, dado que se independiza de la ejecución del script process_perfdata.pl. La ejecución de script queda a cargo del demonio NPCD (Nagios Performance C Daemon), el cual monitorea un directorio, donde deben ubicarse los datos de performance, a la espera de que un archivo sea creado. De esta forma, Nagios se encarga de guardar los datos de la ejecución de los plugins en archivos y luego mover los archivos al directorio donde los tomará NPCD.
  • Bulk with NPCD and npcdmod: el flujo de datos es igual a Bulk with NPCD, con la diferencia que simplifica la configuración de Nagios, ya que las definiciones de cómo procesar los datos se dejan al módulo npcdmod. El uso de este módulo se realiza definiendo un broker en la configuración de Nagios. Debe tenerse en cuenta que este modo no funciona con Nagios 4.
  • Gearman: se utiliza el módulo Gearman como agente intermediario entre Nagios y el procesamiento de los datos. Nagios se encarga de generar los datos y mod_gearman (broker para Nagios) se encarga de encolarlos para su procesamiento, utilizando el demonio gearmand. Luego el script process_perfdata.pl escanea esta cola en busca de datos. La mayor ventaja de este modo es que Nagios y PNP4Nagios pueden ejecutarse en máquinas distintas, ya que la conexión de Nagios con Gearman es a través de sockets. Además Gearman funciona con workers y puede tener múltiples workers trabajando a la vez. Este modo es el ideal para instalaciones de Nagios con hosts y servicios.

De las opciones listadas, elegí utilizar el modo Bulk with NPCD y npcdmod, dado lo fácil que es ponerlo en funcionamiento, y las ventajas que provee sobre el modo Synchronous. Si algún día utilizan Nagios 4, deberían utilizar otra opción como Bulk with NPCD o Gearman.


Instalación y Configuración

Instalar PNP4Nagios en debian y derivados es tan simple como ejecutar:
  # apt-get install pnp4nagios rrdtool
Existen paquetes para otras distribuciones como CentOS.
 
Luego de instalarlo, para integrarlo con Nagios utilizando el modo Bulk with NPCD y npcdmod, debe realizarse los siguientes pasos.

Setear la variable RUN en yes, en el archivo /etc/default/npcd, para habilitar en demonio NPCD.
RUN=yes
Editar el archivo /etc/nagios3/nagios.cfg de la siguiente manera:
# Habilita el procesamiento de datos de performance entregados por los plugins de chequeo
process_performance_data=1
# Hacer que Nagios comparta su información con la librería npcdmod
broker_module=/usr/lib/pnp4nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg
Recargar Nagios:
/etc/init.d/nagios3 reload
Gualá, ya está la integración, eso fue fácil.

Por defecto, PNP4Nagios se habilita en un directorio web distinto al de Nagios. Los gráficos se acceden apuntando a las siguientes direcciones:
http://<nombre servidor>/pnp4nagios/pnp4nagios/graph?host=<nombre del host>
http://<nombre servidor>/pnp4nagios/pnp4nagios/graph?host=<nombre del host>&srv=<descripción del servicio>
Como nombre de host debe utilizarse el nombre que se utilizó para definirlo en Nagios.


Una forma más directa de acceder a los gráficos, es agregar el link como un action_url en la definición de hosts en Nagios. El camino fácil es definir nuevos templates para hosts y servicios, de la siguiente manera:
define host {
 use generic-host
 name pnp-host
 action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_
 register 0
}
define service {
 name pnp-service
 action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
 register 0
}
Luego, para cada host o servicio que se desee ver gráficos, simplemente agregar pnp-host y pnp-service en la definición de hosts.


Pensamientos Finales

A diferencia de MRTG que utiliza consultas SNMP para obtener sus datos, PNP4Nagios utiliza los datos entregados por los plugins de Nagios... los cuales pueden sacar datos por SNMP o de muchas otras maneras. Esta funcionalidad me resultó mucho más abarcativa, y ya que igualmente necesito Nagios y estoy obteniendo datos con sus plugins, por qué no aprovecharlos para generar los gráficos.
Claro que es posible obtener con MRTG datos de otras fuentes que no sea SNMP, MRTG es muy flexible. Sería posible llegar a resultados similares a los obtenidos con Nagios y PNP, pero de una forma más laboriosa. No estoy diciendo que esta solución reemplace MRTG, sino que me parece mucho más completa. La elección de utilizar una u otra es de cada administrador.



Referencias

- PNP4Nagios Documentation
- Archivo /usr/share/doc/pnp4nagios/README.Debian