Apr 27, 2010

Appliances de seguridad perimetral (II)

En el artículo anterior, Appliances de seguridad perimetral (I), se presentaron las características globales que debe presentar una solución de seguridad encargada de proteger los distintos segmentos de una red.

Para este tipo de dispositivos existen múltiples modelos hardware y software (comercializados por distintas entidades), algunos de ellos gratuitos y otros con un coste económico asociado.

Un modelo hardware suele ser por ejemplo una solución que incorpora tanto el appliance (máquina física) como el software preparado y optimizado para dicha plataforma. Existen varios fabricantes que ofrecen soluciones de esta índole en función de distintos parámetros, como por ejemplo el número de conexiones que deberá soportar la arquitectura que se quiere proteger, los niveles de seguridad que se desean contratar, etc. Los principales fabricantes que comercializan este tipo de tecnología son:
Un modelo software es una solución que aporta el programa o aplicaciones necesarias capaces de conformar una arquitectura All-In-One, y en este caso deberá ser el usuario final el que decida la plataforma hardware sobre la que se instalará. También se suelen ofrecer muchas veces como imágenes virtuales que podrán ser transportadas y levantadas en cualquier lugar independientemente del hardware subyacente.

Por lo general, la mayoría de estos productos son gratuitos y basados en sistemas Linux, y lo que habitualmente se comercializa es el soporte técnico o la posibilidad de adecuarlos a un hardware determinado. Decir también que las características ofertadas para esta clase de soluciones suelen ser bastantes inferiores a las ofrecidas por las empresas profesionales dedicadas exclusivamente a esta clase de tecnologías, pero en determinadas infraestructuras pueden llegar a ser una solución totalmente válida.

A continuación se exponen los principales productos de seguridad software ofrecidos a través de una licencia GPL (gratuitos):

Apr 21, 2010

Appliances de seguridad perimetral (I)

En la mayoría de las corporaciones, el único elemento de protección existente entre la red insegura (Internet) y las redes internas es un firewall como por ejemplo iptables, el cual filtra exclusivamente paquetes a nivel de red. Este dispositivo abrirá los puertos a los cuales haya que permitir su acceso y cerrará el resto.

Es un error muy grave el hecho de delegar a los puntos finales de la infraestructura (servidores, equipos de los usuarios, etc.) la seguridad de los servicios implicados. En cualquier caso, estas medidas internas deberían ser siempre el segundo elemento de protección encargado de frenar cualquier amenaza que hubiese conseguido atravesar la primera barrera: el punto de entrada a la red local a través del sistema de seguridad frontal.

Lo habitual es situar siempre como primer muro de protección a nuestra red, un elemento capaz de eliminar o atenuar la mayoría de dichas amenazas.

Estos dispositivos se conocen también como sistemas All-In-One o appliances de seguridad perimetral, y se denominan de esta forma porque son capaces de integrar en una única máquina todas las funcionalidades necesarias para salvaguardar la seguridad del perímetro. Por lo general, estamos ante sistemas que suelen ofrecer las siguientes características globales:
  • Firewall: previene accesos no autorizados hacia o desde una red privada, filtrando tanto a nivel de red como a nivel de aplicación. Todo el tráfico que entra o sale de la LAN pasa a través del firewall, el cual examina cada paquete y bloquea aquellos que no cumplen unos determinados umbrales de seguridad.

  • Servidor VPN: permite establecer redes privadas virtuales entre dos o más equipos conectados a través de una red insegura. Los usuarios se pueden conectar directamente entre ellos o a sus respectivas redes corporativas, estableciendo para ello túneles por los que la información viajará de forma segura (cifrada). Otra de las ventajas de las VPNs es que son más económicas que los enlaces dedicados, ya que son construidas sobre enlaces públicos compartidos, como por ejemplo Internet.

  • Sistema de Protección de Intrusos (IPS): inspecciona toda la actividad entrante y saliente de la red, identificando patrones sospechosos que puedan indicar la existencia de un posible intento de ataque. Ante estas situaciones, el sistema tiene la capacidad de bloquear dichos ataques (IPS – Intrusion Prevention System) o simplemente dejar constancia de ellos a través de registros o alertas (IDS – Intrusion Detection System).

  • Anti-malware: protección frente a virus, jokes, dialers, phishing, etc. Estos sistemas incorporan un motor antivirus capaz de interceptar todo tipo de malware en base a un fichero de firmas, el cual debe de ser actualizado periódicamente.

  • Anti-spam: protección frente a correos spam. Estos sistemas incorporan un motor anti-spam capaz de clasificar los correos electrónicos en base a su contenido. Suelen emplear diferentes tipos de técnicas de detección, como por ejemplo la actualización periódica de una base de datos con las catalogaciones de spam, listas RBL (Real-time Blackhole List), etc.

  • Filtrado web: restricción de aquellas páginas no permitidas.

  • Filtrado de contenidos: protección frente a aquellos contenidos que se consideran indebidos o peligrosos, como por ejemplo archivos protegidos por contraseña, archivos anidados con un índice superior a cierto límite, archivos que exceden un determinado tamaño, etc.



La principal diferencia entre un IDS (como por ejemplo Snort) y un IPS, es que el primero evalúa la intrusión sospechosa una vez que ésta se está produciendo o ya ha tenido lugar, alertando en ese momento del peligro existente. Es decir, estamos ante un sistema pasivo frente a otro activo. Este retardo temporal desde que se recibe el evento hasta que efectivamente se toma una medida, puede provocar en la mayoría de los casos consecuencias fatales para una organización.

El objetivo de incorporar el servicio VPN dentro de dicho dispositivo All-In-One no es otro que el de poder analizar la información que circula a través del túnel, ya que el hecho de que ésta viaje encriptada a través del enlace no es garantía suficiente de que no pueda contener características maliciosas.

En la siguiente figura se ofrece un esquema funcional de una arquitectura de tipo All-In-One. En él pueden observarse los distintos subsistemas de protección encargados de analizar la información proveniente de una red insegura.

Otras características que presentan esta clase de sistemas son la posibilidad de configurarlos en alta disponibilidad (activo/pasivo, activo/activo) y balanceo de carga, o incluso que realicen tareas a nivel de servidor tradicional: servicios de autenticación e impresión, archivos compartidos, correo, proxy, etc.

Apr 12, 2010

Incrementar los logs de NFS

Hace poco me encontré con que no podía montar por NFS un sistema de archivos, y el cliente de NFS lo único que me daba era un simple timeout.

[root@client ~]# mount -vv -t nfs server:/data /mnt/test
mount: trying 192.168.1.11 prog 100003 vers 3 prot tcp port 2049
mount: mount to NFS server '192.168.1.11' failed: timed out (retrying).
...

En el /var/log/messages del servidor tampoco se volcaba nada.

Buscando por Internet descubrí que para incrementar los logs del servicio nfsd, había que modificar el valor de ciertos ficheros del sistema, que por defecto están a 0.

[root@server ~]$  echo 32767 > /proc/sys/sunrpc/rpc_debug

[root@server ~]$ echo 32767 > /proc/sys/sunrpc/nfsd_debug

Y para incrementar los logs en el cliente NFS:

[root@client ~]$  echo 32767 > /proc/sys/sunrpc/nfs_debug

Repitiendo la prueba con los logs en modo debug en el servidor, el único mensaje legible a destacar que pude observar fue el siguiente:

[root@server ~]$  tail -f /var/log/messages
...
Mar 31 14:19:57 client kernel: nfsd: connect from unprivileged port: 192.168.1.10:24498
Mar 31 14:19:57 client kernel: nfsd: connect from 192.168.1.10:5fb2

Venía a decir algo como que el cliente NFS (mount) se estaba intentando conectar desde un puerto del cual no podía. Como esto me seguía sin decir nada, al final tuve que recurrir a la herramienta de red por excelencia: tcpdump.

[root@server ~]$  tcpdump -nni eth0 \(tcp or udp\) and host 192.168.1.10
...
14:52:56.461748 IP 192.168.1.10.18036 > 192.168.1.11.111: S 3772663234:3772663234(0) win 5840 <mss 1460,nop,nop,timestamp 2288725875 0,nop,wscale 9>
14:52:56.462668 IP 192.168.1.11.111 > 192.168.1.10.18036: S 2887405046:2887405046(0) ack 3772663235 win 5792 <mss 1460,nop,nop,timestamp 2048429110 2288725875,nop,wscale 2>
...
14:52:56.476846 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.477097 IP 192.168.1.10.61166 > 192.168.1.11.2049: F 45:45(0) ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.477761 IP 192.168.1.11.2049 > 192.168.1.10.61166: F 29:29(0) ack 46 win 1448 <nop,nop,timestamp 2048429126 2288725890>
14:52:56.478850 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 30 win 12 <nop,nop,timestamp 2288725892 2048429126>


[root@client ~]# tcpdump -nni eth0 \(tcp or udp\) and host 192.168.1.11
...
14:52:56.459882 IP 192.168.1.10.18036 > 192.168.1.11.111: S 3772663234:3772663234(0) win 5840 <mss 1460,sackOK,timestamp 2288725875 0,nop,wscale 9>
14:52:56.461103 IP 192.168.1.11.111 > 192.168.1.10.18036: S 2887405046:2887405046(0) ack 3772663235 win 5792 <mss 1460,nop,nop,timestamp 2048429110 2288725875,nop,wscale 2>
...
14:52:56.475095 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.475257 IP 192.168.1.10.61166 > 192.168.1.11.2049: F 44:44(0) ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.475400 IP 192.168.1.10.19867 > 192.168.1.11.111: UDP, length 56
14:52:56.477158 IP 192.168.1.11.2049 > 192.168.1.10.61166: F 29:29(0) ack 45 win 1448 <nop,nop,timestamp 2048429126 2288725890>
14:52:56.477173 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 30 win 12 <nop,nop,timestamp 2288725892 2048429126>

Pues bien, en la traza del cliente puede observarse cómo éste estaba intentando mandar un paquete a través del protocolo UDP, el cual nunca llegaba al servidor. Lo que estaba ocurriendo es que el firewall situado entre ambas máquinas estaba cortando el tráfico UDP.

Apr 5, 2010

Monitorización de VMware ESXi con Zabbix (II)

Una vez que hemos establecido la infraestructura necesaria para poder monitorizar VMware ESXi con Zabbix, vamos a configurar Zabbix para poder realizar tal tarea.

Lo que he hecho ha sido desarrollar una plantilla para Zabbix, la cual está formada por 41 items (elementos encargados de obtener datos concretos) y 9 gráficos (utilizan los valores proporcionados por los items para representar los datos). En el siguiente link puede descargarse la plantilla: Template_ESXi.

Por lo tanto lo que haremos en primer lugar será ir a Configuration, Export/Import, con el objetivo de importar dicha plantilla. Una vez que la hayamos importado, iremos a la sección de Configuration, Host groups, y accederemos a la pantalla de Templates. Si pulsamos sobre el enlace Items, podremos ver la lista de todos los items que conforman la plantilla.


Hay uno de los items llamado "ESXi resxtop" el cual utiliza el script externo resxtop_esxi.sh para generar el fichero CSV (archivo que contiene los valores proporcionados por resxtop - consumo de CPU, memoria, disco, etc.) del VMware ESXi pasado a través de la macro HOSTNAME. Este item se ejecutará cada 30 sg de Lunes a Domingo. El resto de items utilizarán el script get_field_esxi.sh para obtener un valor concreto dentro del fichero CSV.


De esta forma si analizamos un item cualquiera, por ejemplo "Memory (Free)", podremos ver que al script get_field_esxi.sh se le pasarán dos argumentos a través de la línea de órdenes: la dirección IP o nombre del VMware ESXi (a través de la macro HOSTNAME) y el parámetro que queramos obtener dentro del fichero CSV. Para este caso concreto, como se quiere obtener la memoria que queda libre se le ha pasado la cadena de texto "\\Free MBytes".

Este item, que se ejecutará cada 30 sg de Lunes a Domingo, devolverá como resultado un número entero decimal que se corresponderá con los MB libres de memoria RAM. Para otros items lo único que cambiará será por ejemplo el tipo de resultado devuelto o la clase de unidad.


Esta plantilla ha sido creada teniendo en cuenta 8 cores, de ahí a que haya por ejemplo 8 items de tipo "Physical Cpu(0...7) Util Time". Por lo tanto, si la plantilla se utiliza para monitorizar otros VMware ESXi con menos cores, se pueden desactivar aquellos items no necesarios, o si por el contrario se dispone de más cores, se pueden añadir (clonar) más items.

Lo mismo ocurre también para el caso de los dos items relacionados con los interfaces de red: "Network Received Traffic (eth0)" y "Network Transmitted Traffic (eth0)". Si se tuviera algún VMware ESXi con otro interfaz de red, habría que clonar esos dos items y cambiar la cadena de texto "eth0" por "eth1".

La plantilla también dispone de 9 gráficos que utilizarán los items anteriormente comentados.


Si abrimos por ejemplo el gráfico de "Disk", podremos ver que hace uso de dos items: "Disk (Read)" y "Disk (Write)".


En la siguiente imagen podemos ver una de las gráficas (Physical Cpu Util Time) obtenidas por la plantilla Template_ESXi una vez que ha sido asignada a un VMware ESXi (ESXI01.LOCAL).

Mar 29, 2010

Monitorización de VMware ESXi con Zabbix (I)

Uno de las principales desventajas de VMware ESXi es su difícil monitorización.

A través del cliente vSphere podemos hacer un seguimiento de distintos parámetros de la máquina (CPU, memoria, disco, etc.) durante la última hora, situación que generalmente es insuficiente si se necesita mantener registrados dichos valores de cara a la posible resolución de una incidencia. Además a través de dicho cliente, tampoco podemos generar ningún tipo de alerta.

Una de las posibles alternativas que se tienen consiste combinar la herramienta resxtop con uno de los mejores softwares open source existentes para la monitorización de equipos: Zabbix.

La idea va a consistir en lanzar resxtop en modo batch, con el objetivo de recopilar los parámetros que nosotros le indiquemos a través del fichero de configuración de resxtop. Esta operación devolverá como resultado un fichero CSV. La aplicación resxtop será gestionada a través de un script en bash, el cual recibirá como parámetro a través de la línea de órdenes el nombre o dirección IP del VMware ESXi del cual queramos obtener su informe CSV.

A través de Zabbix podremos generar posteriormente un item que tenga asociado este script, y el cual se encargue de obtener el informe CSV de forma periódica.

A continuación y a través de otro script en bash (el cual recibirá como argumentos el nombre o dirección IP del VMware ESXi y el parámetro que se desee obtener - consumo de CPU, memoria libre, etc.), podremos obtener el valor asociado a un argumento concreto. De esta forma y posteriormente en Zabbix, podremos generar varios items que se encarguen de obtener dichos valores utilizando el script.

Para hacer las pruebas vamos a emplear Zabbix 1.8.1 instalado sobre un CentOS 5.4 de 64 bits.

Primero vamos a crear un script en bash denominado resxtop_esxi.sh, el cual reciba por la línea de órdenes el nombre del VMware ESXi (o dirección IP) que se desee monitorizar a través de resxtop (habría que sustituir xxxxxx por la password de root del ESXi).

[root@centos ~]# mkdir -p /etc/zabbix/externalscripts/resxtop_esxi/reports

[root@centos ~]# cd /etc/zabbix/externalscripts

[root@centos externalscripts]# cat resxtop_esxi.sh
#!/bin/bash

PATH_RESXTOP="/etc/zabbix/externalscripts/resxtop_esxi"

if [ "$2" == "" ]; then
echo 1 ; exit 1
fi

mv $PATH_RESXTOP/reports/$2.csv.tmp $PATH_RESXTOP/reports/$2.csv

echo 0
$PATH_RESXTOP/resxtop -b -n 1 -c $PATH_RESXTOP/esxtop4rc --server $2 --username root > $PATH_RESXTOP/reports/$2.csv.tmp << eof
xxxxxx
eof

[root@centos externalscripts]# chmod 700 resxtop_esxi.sh

El script anterior depositará los resultados dentro del directorio reports.

Para instalar resxtop en la máquina CentOS, he descargado la versión de esta aplicación para 64 bits y la he descomprimido directamente dentro del directorio /etc/zabbix/externalscripts/resxtop_esxi. Al intentar instalarla utilizando el script que trae consigo (vmware-install.pl) me ha dado varios problemas, así que he optado por instalarla manualmente.

Éstos son los pasos que he seguido:

[root@centos resxtop_esxi]# tar xvzf VMware-vSphere-CLI-4.0.0-198790.x86_64.tar.gz

[root@centos resxtop_esxi]# mkdir -p /etc/vmware-vcli/

[root@centos resxtop_esxi]# cat /etc/vmware-vcli/locations
answer LIBDIR /usr/lib/vmware-vcli

[root@centos resxtop_esxi]# mkdir -p /usr/lib/vmware-vcli/lib

[root@centos resxtop_esxi]# cp -a vmware-vsphere-cli-distrib/lib/lib64/wrapper-gtk24.sh /usr/lib/vmware-vcli/lib/

[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/bin /usr/lib/vmware-vcli/

[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/lib64 /usr/lib/vmware-vcli/

[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/lib32 /usr/lib/vmware-vcli/

[root@centos resxtop_esxi]# cp -a vmware-vsphere-cli-distrib/bin/resxtop .

[root@centos resxtop_esxi]# rm -rf vmware-vsphere-cli-distrib/

Si tenemos activado SELinux, tendremos que ejecutar las dos siguientes órdenes:

[root@centos resxtop_esxi]# chcon -t textrel_shlib_t '/usr/lib/vmware-vcli/lib32/libvmacore.so.1.0/libvmacore.so.1.0'

[root@centos resxtop_esxi]# semanage fcontext -a -t textrel_shlib_t '/usr/lib/vmware-vcli/lib32/libvmacore.so.1.0/libvmacore.so.1.0'

El fichero de configuración de resxtop tendrá el siguiente contenido:

[root@centos resxtop_esxi]# cat esxtop4rc



AG

DHIJK

5c

De esta forma diremos a resxtop que obtenga los parámetros generales de CPU y memoria (dos primeras líneas en blanco) y los datos concretos para cada una de las unidades de disco e interfaces de red (líneas cuarta y sexta).

Si echamos un vistazo al fichero CSV que crea resxtop, podremos ver que se trata de una tabla con dos filas y múltiples columnas, una por cada uno de los datos registrados.

[root@centos resxtop_esxi]# resxtop -b -n 1 -c esxtop4rc --server esxi.local --username root > esxi.local.csv

[root@centos resxtop_esxi]# cat esxi.local.csv
"(PDH-CSV 4.0) (CET)(0)","\\esxi.local\Memory\Memory Overcommit (1 Minute Avg)","\\esxi.local\Memory\Memory Overcommit (5 Minute Avg)"...
...

[root@centos resxtop_esxi]# cat esxi.local.csv | cut -d',' -f 2
"\\esxi.local\Memory\Memory Overcommit (1 Minute Avg)"
"0.00"

Por lo tanto lo que vamos a hacer será un script en AWK que se encargue de obtener el valor del campo concreto que le indiquemos.

[root@centos resxtop_esxi]# cat parser_resxtop.awk
BEGIN {
FS = "," ; RS = ""
}

{
for (i = 1; i <= NF/2; i++)
if ( index($i, field) != 0 )
{
gsub("\"","",$(i + NF/2))
print $(i + NF/2)
break
}
}

[root@centos resxtop_esxi]# awk -v field="Memory Overcommit (1 Minute Avg)" -f parser_resxtop.awk reports/esxi.local.csv
0.00

Y por último, vamos a hacer un script llamado get_esxi_field.sh que recibirá dos argumentos por la línea de órdenes: el primero será el nombre o dirección IP del ESXi del cual se quiera obtener un cierto parámetro (CPU, memoria, etc.) y el segundo argumento será la cadena de texto que indique dicho argumento (Por ejemplo "Memory Overcommit (1 Minute Avg)").

[root@centos resxtop_esxi]# cd ..

[root@centos externalscripts]# cat get_esxi_field.sh
#!/bin/bash

PATH_SCRIPTS="/etc/zabbix/externalscripts/resxtop_esxi"

if [ "$2" == "" -o "$3" == "" ]; then
echo 1 ; exit 1
fi

echo "$(awk -v field="$3" -f $PATH_SCRIPTS/parser_resxtop.awk $PATH_SCRIPTS/reports/$2.csv)"

[root@centos externalscripts]# chmod +x get_esxi_field.sh

[root@centos externalscripts]# chown -R zabbix:zabbix /etc/zabbix/externalscripts

El árbol de ficheros y directorios de la estructura de monitorización que acabamos de crear quedaría de la siguiente forma:

[root@centos ~]# tree /etc/zabbix/externalscripts
/etc/zabbix/externalscripts
|-- get_esxi_field.sh
|-- resxtop_esxi
| |-- esxtop4rc
| |-- parser_resxtop.awk
| |-- reports
| `-- resxtop
`-- resxtop_esxi.sh

2 directories, 5 files

Mar 23, 2010

¿Estamos ante el fin de Microsoft Office en la Administración Pública?

Probablemente lo que voy a contar a continuación sea lo único bueno que he visto hacer a lo largo de los seis años de gobierno socialista que nos ha tocado (padecer) vivir a los españoles.

El 8 de Enero de 2010 se aprobó el Real Decreto 4/2010, donde se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, por el que se obliga a los organismos públicos a la utilización de estándares abiertos (artículo 11):

"1. Las Administraciones públicas usarán estándares abiertos, así como, en su caso y de forma complementaria, estándares que sean de uso generalizado por los ciudadanos, al objeto de garantizar la independencia en la elección de alternativas tecnológicas por los ciudadanos y las Administraciones públicas y la adaptabilidad al progreso de la tecnología y, de forma que:

a) Los documentos y servicios de administración electrónica que los órganos o Entidades de Derecho Público emisores pongan a disposición de los ciudadanos o de otras Administraciones públicas se encontrarán, como mínimo, disponibles mediante estándares abiertos.
...

2. En las relaciones con los ciudadanos y con otras Administraciones públicas, el uso en exclusiva de un estándar no abierto sin que se ofrezca una alternativa basada en un estándar abierto se limitará a aquellas circunstancias en las que no se disponga de un estándar abierto que satisfaga la funcionalidad satisfecha por el estándar no abierto en cuestión y sólo mientras dicha disponibilidad no se produzca.
"

Si ahora nos vamos al Glosario de términos, contenido en el ANEXO del documento, podemos ver la definición que el Real Decreto hace de "estándar abierto":

Estándar abierto: Aquél que reúne las siguientes condiciones:

a) Que sea público y su utilización sea disponible de manera gratuita o a un coste que no suponga una dificultad de acceso,

b) Que su uso y aplicación no esté condicionado al pago de un derecho de propiedad intelectual o industrial.

En base a la afirmación anterior podemos concluir que los formato utilizados por Microsoft no cumplen en ningún caso lo establecido por el Real Decreto 4/2010.

Microsoft Office nunca ha empleado un formato estándar hasta su versión 2007, ya que a partir de este producto empezó a utilizar como formato por defecto el OOXML (Office Open XML), el cual fue declarado como estándar ISO/IEC 29500 en el año 2008, después de diferentes procesos sospechosos y duras controversias.

En cambio OpenOffice emplea como formato para sus archivos el ODF (OpenDocument Format), desarrollado inicialmente por Sun Microsystems y aprobado como estándar ISO/IEC 26300 en el año 2005.

Los criterios de diseño para ODF fueron totalmente independientes de los vendedores, compatibles con la suite Office, accesibles para desarrolladores, se utilizaron estándares abiertos ya existentes y se implementó una estructura clara y extendible.

Si en la Administración Pública se consiguiera pasar completamente a OpenOffice, supondría alcanzar la antesala de una hipotética migración de todos los equipos de los usuarios a GNU Linux, ya que hoy en día el principal escollo que obliga a seguir utilizando Microsoft Windows como sistema operativo de trabajo es el empleo de Microsoft Office como suite ofimática.

Mar 17, 2010

Scripts externos en Zabbix

Zabbix trae de serie numerosas plantillas, también conocidas como templates, que permiten monitorizar diversas aplicaciones y sistemas.

Puede ocurrir que con esas plantillas no tengamos los suficientes recursos para monitorizar un determinado servicio. Ante esta situación podríamos crear un script personalizado que cumpla los requisitos solicitados, utilizar algún tipo de script que ya haya sido implementado por otra persona o utilizar por ejemplo plugins de Nagios, los cuales pueden ser llamados desde Zabbix encapsulándolos a través de un wrapper.

Un wrapper no es más que un envoltorio de un determinado plugin de Nagios, el cual se encarga de ejecutar dicho script y parsear sus resultados al formato de Zabbix.

Para poder utilizar scripts externos en Zabbix, lo primero que hay que hacer es definir en el fichero de configuración del servidor el directorio donde residirán los scripts.

[root@centos ~]# cat /etc/zabbix/zabbix_server.conf
...
ExternalScripts=/etc/zabbix/externalscripts

[root@centos ~]# chown zabbix:zabbix /etc/zabbix/externalscripts

A la hora de crear un item que utilice un script externo, tendremos que seleccionar como tipo (Type), External check.

Vamos a ver todo esto con un sencillo ejemplo: se va a crear un script externo en bash que monitorice el número de procesos Apache que hay levantados. El script se va a llamar check_status.sh y va a recibir como único argumento el nombre del proceso del cual debe obtenerse el número total de procesos existentes.

Como versión de Zabbix se va a emplear una 1.8.1 en un CentOS 5.4 de 64 bits.

Para ejecutar el script desde Zabbix utilizaremos la siguiente llamada como key: check_process.sh[httpd]. El tipo de dato que devolverá la función será un número entero decimal sin signo.


Para devolver un valor a Zabbix desde un script externo en bash, utilizaremos el comando echo. Por lo tanto, el script quedará de la siguiente forma:

[root@centos ~]# cat /etc/zabbix/externalscripts/check_process.sh
#!/bin/bash
echo $(pgrep $2 | wc -l)

[root@centos ~]# chmod +x /etc/zabbix/externalscripts/check_process.sh

Como argumento recibido a través de la línea de órdenes se tiene que empezar a utilizar a partir de $2, ya que $1 se corresponde siempre con la dirección IP de la máquina que ejecuta el script.

Si se necesitan pasar más parámetros, éstos deben estar separados por espacios en blanco (por ejemplo check_process.sh[httpd "memory limit"]).