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"]).

Mar 8, 2010

Monitorización de VMware ESXi con resxtop/esxtop

VMware ESXi proporciona una herramienta similar al top de Linux denominada esxtop, la cual permite obtener en tiempo real, datos relativos al uso de CPU, memoria, disco, estado de los procesos, etc.

Para poder ejecutar esxtop hay que tener acceso a la service console (SSH) del VMware ESXi. La forma básica de ejecución de esxtop es la siguiente:

~# esxtop

3:25:30pm up 7 days 1:21, 172 worlds; CPU load average: 0.01, 0.01, 0.01
PCPU USED(%): 1.1 0.9 0.5 0.6 0.7 1.1 0.9 1.1 AVG: 0.9
PCPU UTIL(%): 1.6 1.3 0.8 1.0 1.1 1.5 1.4 1.6 AVG: 1.3

ID GID NAME NWLD %USED %RUN %SYS %WAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
1 1 idle 8 798.81 799.22 0.00 0.00 7.58 0.00 0.02 0.00 0.00 0.00
2 2 system 6 0.02 0.02 0.00 600.00 0.00 0.00 0.00 0.00 0.00 0.00
3 3 vim 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 0.00
6 6 helper 55 0.05 0.06 0.00 5500.00 0.01 0.00 0.00 0.00 0.00 0.00
...

La pantalla interactiva que nos ofrece esta orden nos permite ver los datos relativos al porcentaje de utilización de la CPU, tanto de los distintos cores físicos como el consumo de los procesos. A esta pantalla podremos regresar siempre que queramos pulsando la tecla 'c'.

En la pantalla anterior puede verse que el ESXi en cuestión dispone de ocho cores, ya que en el campo correspondiente al porcentaje de uso de cada una de las CPUs físicas (PCPU USED) se muestran ocho valores. El último campo (AVG) corresponde a la media de todos los cores físicos.

La línea que aparece debajo (PCPU UTIL) representa el porcentaje útil de uso de cada una de las CPUs. Este campo representa el porcentaje real de utilización de la CPU, ya que no se tiene en cuenta el tiempo idle. En cambio PCPU USED sí que tiene en cuenta este valor.

En la primera línea hay que destacar también el campo load average, que indica el número medio de procesos del sistema que durante los últimos 1, 5 y 15 minutos han estado esperando por algún recurso del sistema (CPU, acceso a disco, red, etc.).

La lista de datos que se muestra debajo de la cabecera inicial se corresponde con el estado de los distintos procesos del sistema. Los principales son: %USED es el porcentaje de utilización de las CPUs físicas (suma de de los porcentajes de todos los cores - %USED = %RUN + %SYS - %OVRLP). %RUN es el porcentaje empleado en la planificación. %SYS es el porcentaje de utilización de CPU por parte del VMKernel. %OVRLP es el porcentaje de uso de CPU por parte de los servicios del sistema.

Dentro de esta pantalla, si pulsamos la tecla 'm' accederemos al estado de la memoria (todos los valores representan MB, exceptuando los campos que comienzan por %).

~# esxtop

3:51:58pm up 7 days 1:47, 174 worlds; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM /MB: 8187 total: 716 vmk, 4091 other, 3379 free
VMKMEM/MB: 7790 managed: 467 minfree, 1285 rsvd, 6136 ursvd, high state
PSHARE/MB: 3794 shared, 1314 common: 2480 saving
SWAP /MB: 0 curr, 0 target: 0.00 r/s, 0.00 w/s
MEMCTL/MB: 0 curr, 0 target, 3992 max

GID NAME MEMSZ GRANT SZTGT TCHD %ACTV %ACTVS %ACTVF %ACTVN OVHDUW OVHD OVHDMAX
16 init.4189 2.40 0.11 2.40 0.11 0 0 0 0 0.00 0.00 0.00
159 busybox.4338 2.40 0.11 2.40 0.11 0 0 0 0 0.00 0.00 0.00
163 vmklogger.4342 2.45 0.09 2.45 0.09 0 0 0 0 0.00 0.00 0.00
...

En la primera línea de la pantalla anterior, MEM overcommit avg representa el exceso de memoria (media aritmética) durante los últimos 15, 5 y 1 minuto. Lo habitual es que estos valores sean siempre cero. Si son superiores significa que las máquinas virtuales están solicitando más memoria (física) de la disponible.

La línea PMEM hace referencia a la memoria física. total es la memoria física total disponible. vmk es la cantidad de memoria utilizada por el VMKernel. other es la memoria total empleada por las máquinas virtuales y free es la memoria que queda libre.

La línea VMKMEM hace referencia a la memoria administrada por el VMKernel. minfree es la cantidad de memoria que el VMKernel preferiría tener libre. rsvd es la cantidad de memoria actualmente reservada por el VMKernel y ursvd es la cantidad de memoria que no se encuentra reservada.

La línea PSHARE hace referencia a la memoria compartida. shared es la cantidad de memoria física que está siendo compartida. common es la cantidad de memoria común para todas las máquinas virtuales y saving es la cantidad de memoria guardada debido al intercambio (shared = common + saving).

Y la línea SWAP hace referencia a la memoria swap.

La lista de datos que se muestra debajo de la cabecera inicial se corresponde con la utilización de memoria por parte de los distintos procesos del sistema (o máquinas virtuales). MEMSZ es la cantidad de memoria reservada. GRANT es la cantidad de memoria concedida, SZTGT es la cantidad de memoria utilizada y TCHD es la cantidad de memoria recientemente empleada.

Dentro de esta pantalla, si pulsamos la tecla 'd' accederemos al estado de los distintos adaptadores del sistema. Para el caso del VMware ESXi utilizado, el adaptador vmhba0 se corresponde con un controlador IDE empleado por un CD-ROM. vmhba1 hace referencia al disco duro y vmhba32 no se está utilizando.

~# esxtop

4:37:30pm up 7 days 2:33, 176 worlds; CPU load average: 0.01, 0.01, 0.01

4:42:28pm up 7 days 2:38, 176 worlds; CPU load average: 0.01, 0.01, 0.01

ADAPTR CID TID LID NCHNS NTGTS NLUNS CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
vmhba0 - - - 2 1 1 1.98 0.00 0.00 0.00 0.00 1.01 0.01 1.03 0.00
vmhba1 - - - 1 1 1 8.32 2.77 5.55 0.08 0.07 0.25 0.01 0.26 0.00
vmhba32 - - - 2 0 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00

Dentro de esta pantalla destacaremos los siguientes valores: READS/s (número de comandos de lectura lanzados por segundo), WRITES/s (número de comandos de escritura lanzados por segundo), MBREAD/s (MB leídos por segundo) y MBWRTN/s (MB escritos por segundo).

Si se pulsa la tecla 'u' accederemos al estado de las diferentes unidades de almacenamiento. mpx.vmhba0:CO:T es la unidad de CD-ROM y mpx.vmhba1:CO:T el disco duro.

~# esxtop

10:54:40am up 7 days 19:50, 173 worlds; CPU load average: 0.01, 0.01, 0.01

DEVICE PATH/WORLD/PARTITION DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
mpx.vmhba0:C0:T - 16 - 0 0 0 0.00 1.95 0.00 0.00 0.00 0.00 1.00 0.02 1.02 0.01
mpx.vmhba1:C0:T - 32 - 0 0 0 0.00 14.42 10.91 3.51 0.32 0.12 0.32 0.01 0.32 0.00

Los valores más importantes son los mismos que los mostrados para los adaptadores del sistema.

Y por último, dentro de esta pantalla si pulsamos la tecla 'n' accederemos al estado de los diferentes interfaces de red. Management es un puerto interno. vnmnic0 se corresponde con el único interfaz físico de red (tarjeta) que dispone este VMware ESXi. vmk0 es un interfaz virtual utilizado por el VMKernel para realizar sus propias tareas (actualizaciones, operaciones de vmotion, etc.).

Y el resto de interfaces virtuales (CENTOS01.LOCAL y CENTOS02.local) se corresponden con las tarjetas virtuales que tienen configuradas esas dos máquinas virtuales.

Como puede observarse, los interfaces virtuales están enlazados con el interfaz físico vmnic0. A su vez, todos ellos están conectados a un switch virtual denominado vSwitch0.

~# esxtop

5:03:02pm up 7 days 2:58, 175 worlds; CPU load average: 0.01, 0.01, 0.01

PORT-ID USED-BY TEAM-PNIC DNAME PKTTX/s MbTX/s PKTRX/s MbRX/s %DRPTX %DRPRX
16777217 Management n/a vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00
16777218 vmnic0 - vSwitch0 1.98 0.00 15.06 0.02 0.00 0.00
16777219 vmk0 vmnic0 vSwitch0 0.40 0.00 6.94 0.01 0.00 0.00
16777220 10059:CENTOS01.LOCAL vmnic0 vSwitch0 1.59 0.00 8.12 0.01 0.00 0.00
16777221 11419:CENTOS02.LOCAL vmnic0 vSwitch0 0.00 0.00 6.54 0.01 0.00 0.00

PKTTX/s es el número de paquetes transmitidos por segundo. MbTX/s es el número de MB transmitidos por segundo. PKTRX/s es el número de paquetes recibidos por segundo. MbRX/s es el número de MB recibidos por segundo. %DRPTX es el porcentaje de paquetes transmitidos que han sido descartados y %DRPRX es el porcentaje de paquetes recibidos que han sido descartados.

Si al comando esxtop le añadimos el argumentos -a, ampliaremos las estadísticas mostradas.

Otra opción interesante es -b, que permite ejecutar el comando en modo batch. De esta forma podremos volcar los resultados a un fichero. Con la opción -n indicamos el número de iteraciones y con -d el retardo entre dichas iteraciones.

~# esxtop -b -n 2 -d 5 > file.csv

Si no disponemos de acceso SSH al VMware ESXi, podemos utilizar la versión remota de este comando: resxtop. Este comando se encuentra disponible instalando en un PC cliente (Linux o Windows) el vSphere CLI (Command-Line Interface).

[root@centos ~]# resxtop --server 192.168.1.10 --username root
...

Otra utilidad bastante interesante de estas herramientas es la posibilidad de utilizar un fichero de configuración a través de la opción -c. Cuando se lanza resxtop/esxtop, la utilidad trata de buscar siempre el fichero de configuración ~/.esxtop4rc. Si no existe, desplegará todos los campos, y si existe, mostrará sólo los campos que estén definidos dentro de dicho fichero. Para que no utilice por defecto dicho archivo, indicaremos con el parámetro -c la ruta al fichero que queremos utilizar.

Este fichero está formado por ocho líneas. Las siete primeras se corresponden a las pantallas de CPU (c), memoria (m), adaptadores (d), unidades de almacenamiento (u), discos virtuales (v) e interrupciones (i). La última indica la frecuencia de muestreo en segundo y la primera pantalla que se mostrará al ejecutar la herramienta (CPU, memoria, ...).

En cada una de las líneas se establecen las columnas a mostrar mediante letras mayúsculas.

[root@centos ~]# cat .esxtop4rc



AG

DHIJK

5c
...

Otra posibilidad de crear este fichero sería una vez que esteviésemos dentro de la pantalla de monitorización, configuraríamos los campos que quisiéramos visualizar y a continuación pulsaríamos la tecla 'W', para que la aplicación generase el fichero esxtop4rc.

Si queremos ampliar la información sobre los datos obtenidos por estos comandos, podemos recurrir al artículo Interpreting esxtop Statistics.

Feb 27, 2010

Instalación del servidor Zabbix a partir del código fuente

Zabbix es bajo mi punto de vista, el mejor sistema de monitorización existente en el mundo del software libre. Las mejores introducidas a partir de la versión 1.8 han sido bastante importantes.

A veces vamos a tener la necesidad de instalar Zabbix a partir de su código fuente, debido por ejemplo a que los repositorios de nuestra distribución Linux no dispongan de la última versión, o que por ejemplo, al compilarlo directamente en nuestro sistema queramos ganar en optimización y rendimiento, o habilitar alguna configuración que no venga a través del paquete base.

A continuación voy a mostrar cómo instalar Zabbix a partir de sus ficheros fuente. Para ello voy a utilizar una distribución CentOS 5.4 de 64 bits y una versión 1.8.1 de Zabbix.

Lo primero que vamos a hacer es instalar RPMForge, con el objetivo de agregar repositorios adicionales a las listas que por defecto trae CentOS. También actualizaremos el sistema.

[root@centos ~]# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

[root@centos ~]# rpm -Uhv rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

[root@centos ~]# yum update -y

A continuación instalaremos los paquetes adicionales que requiere Zabbix, como por ejemplo PHP y el servidor web Apache, y una base de datos, en nuestro caso elegiremos MySQL.

[root@centos ~]# yum install -y gcc mysql-server mysql-devel curl-devel httpd php php-mysql php-bcmath php-gd php-xml php-mbstring net-snmp-devel fping e2fsprogs-devel zlib-devel libgssapi-devel krb5-devel openssl-devel libidn-devel iksemel-devel

Después lanzaremos MySQL y haremos que el servicio de base de datos y Apache se inicien automáticamente al arrancar el sistema operativo. También ejecutaremos la aplicación mysql_secure_installation con el objetivo de establecer el password para el usuario 'root', remover el usuario 'anonymous' y eliminar la base de datos test.

[root@centos ~]# service mysqld start

[root@centos ~]# chkconfig mysqld on ; chkconfig httpd on

[root@centos ~]# mysql_secure_installation

Ahora bajaremos el código fuente de Zabbix y los descomprimiremos. Sólo nos quedará por compilarlo y generar los binarios correspondientes.

[root@centos ~]# wget http://downloads.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/1.8.1/zabbix-1.8.1.tar.gz?use_mirror=switch

[root@centos ~]# tar xvzf zabbix-1.8.1.tar.gz ; cd zabbix-1.8.1

[root@centos zabbix-1.8.1]# ./configure --enable-agent --enable-ipv6 --enable-proxy --enable-server --with-mysql --with-libcurl --with-net-snmp --with-jabber

[root@centos zabbix-1.8.1]# make ; make install

El siguiente paso consistirá en crear todos los directorios necesarios para Zabbix, añadir un usuario denominado 'zabbix' al sistema y copiar los archivos de arranque y configuración a sus respectivos directorios.

[root@centos zabbix-1.8.1]# mkdir -p /etc/zabbix/alert.d /etc/zabbix/externalscripts /var/log/zabbix-server /var/log/zabbix-agent /var/run/zabbix-server /var/run/zabbix-agent /usr/local/share/zabbix

[root@centos zabbix-1.8.1]# adduser -r -d /var/run/zabbix-server -s /sbin/nologin zabbix

[root@centos zabbix-1.8.1]# cp -a misc/conf/zabbix_server.conf misc/conf/zabbix_agentd.conf /etc/zabbix

[root@centos zabbix-1.8.1]# cp misc/init.d/redhat/8.0/zabbix_server misc/init.d/redhat/8.0/zabbix_agentd /etc/init.d

[root@centos zabbix-1.8.1]# chown -R zabbix:zabbix /var/run/zabbix* /var/log/zabbix* /etc/zabbix

Una vez depositado cada fichero en su lugar, modificaremos ciertos parámetros que por defecto vienen en dichos archivos.

[root@centos zabbix-1.8.1]# cat /etc/zabbix/zabbix_server.conf
...
# Nombre del archivo de log
LogFile=/var/log/zabbix-server/zabbix_server.log

# Nombre del archivo de PID
PidFile=/var/run/zabbix-server/zabbix_server.pid

# Password de la base de datos
DBPassword=xxxxxx

# Ubicación de los scripts de alerta
AlertScriptsPath=/etc/zabbix/alert.d/

# Ubicación de los scripts externos
ExternalScripts=/etc/zabbix/externalscripts


[root@centos zabbix-1.8.1]# cat /etc/zabbix/zabbix_agentd.conf
...
# Nombre del archivo de log
LogFile=/var/log/zabbix-agent/zabbix_agentd.log

# Habilitar el uso de comandos remotos
EnableRemoteCommands=1

# Número máximo de segundos para el procesamiento
Timeout=10

# Nombre del host (comando hostname)
Hostname=centos.local

# Dirección IP del servidor Zabbix
Server=::ffff:127.0.0.1


[root@centos zabbix-1.8.1]# cat /etc/init.d/zabbix_server
...
# Orden de arranque y apagado
# chkconfig: - 80 30

# Ubicación del binario
progdir="/usr/local/sbin/"

# Retardo de 5 sg para el reinicio
...
restart() {
stop
sleep 5
start
...


[root@centos zabbix-1.8.1]# cat /etc/init.d/zabbix_agentd
...
# Ubicación del binario
progdir="/usr/local/sbin/"

# Retardo de 5 sg para el reinicio
...
restart() {
stop
sleep 5
start
...

También estableceremos permisos de lectura y escritura para el fichero de configuración de Zabbix sólo para el propietario (hemos definido dentro del fichero la clave de administración de bases de datos para el usuario root).

[root@centos zabbix-1.8.1]# chmod 600 /etc/zabbix/zabbix_server.conf

En el fichero /etc/services definiremos los servicios para el agente y servidor de Zabbix.

[root@centos ~]# echo "zabbix-agent    10050/tcp  Zabbix Agent"   >> /etc/services
[root@centos ~]# echo "zabbix-agent 10050/udp Zabbix Agent" >> /etc/services
[root@centos ~]# echo "zabbix-trapper 10051/tcp Zabbix Trapper" >> /etc/services
[root@centos ~]# echo "zabbix-trapper 10051/udp Zabbix Trapper" >> /etc/services

Ahora vamos a configurar la parte web:

[root@centos ~]# cp -ar frontends/php/* /usr/local/share/zabbix

[root@centos ~]# chown -R zabbix:zabbix /usr/local/share/zabbix

[root@centos ~]# echo "Alias /zabbix /usr/local/share/zabbix" > /etc/httpd/conf.d/zabbix.conf

[root@centos ~]# service httpd start

Ahora sólo nos quedará que hacer que los servicios de Zabbix se arranquen automáticamente al iniciar la máquina. Iniciaremos también el agente de Zabbix.

[root@centos ~]# chkconfig zabbix_server on ; chkconfig zabbix_agentd on

[root@centos ~]# chmod +x /etc/init.d/zabbix_server /etc/init.d/zabbix_agentd

[root@centos ~]# service zabbix_agentd start

En este momento abriremos un navegador web y pondremos la siguiente URL: http://192.168.1.10/zabbix (192.168.1.10 es la dirección IP de mi servidor).

Si tenemos activado SELinux, veremos que éste nos impide el acceso. Esto se debe a que los contextos de los archivos PHP no están correctamente establecidos; lo arreglaremos con la siguiente sentencia. A su vez, también activaremos la variable booleana httpd_can_network_connect para permitir que scripts externos se puedan conectar al servidor Apache.

[root@centos ~]# chcon -R -t httpd_sys_content_t /usr/local/share/zabbix

[root@centos ~]# setsebool -P httpd_can_network_connect on

Lo primero que aparecerá será un asistente que comprobará los pre-requisitos de la instalación. Como puede verse en la siguiente imagen, hay varios puntos que no son correctos y que afectan al fichero php.ini.


Modificaremos los valores solicitados:

[root@centos ~]# cat /etc/php.ini
...
# Cantidad máxima de memoria que un script puede consumir
memory_limit = 256M

# Tamaño máximo del archivo que se puede subir al servidor web
post_max_size = 32M

# Tiempo máximo de ejecución para cada script
max_execution_time = 600

# Zona horaria
date.timezone = Europe/Madrid

# Soporte adicional para cadenas multi-byte
mbstring.func_overload = 2


[root@centos ~]# service httpd restart

Una vez establecidos dichos valores, pulsaremos sobre el botón Retry. En la siguiente pantalla de configuración el asistente nos indica que tenemos que crear la base de datos manualmente.


Crearemos una nueva base de datos en MySQL con el nombre 'zabbix', utilizando los esquemas que generamos durante la compilación.

[root@centos ~]# (echo "CREATE DATABASE zabbix;" ; echo "USE zabbix;" ; cat create/schema/mysql.sql ; cat create/data/data.sql ; cat create/data/images_mysql.sql) | mysql -h 127.0.0.1 -u root --password=xxxxxx

Al finalizar el asistente, se grabarán los datos de conexión con la base de datos en el fichero zabbix.conf.php. Debido a que este fichero contendrá la password de la base de datos, le asignaremos permisos de lectura-escritura sólo al propietario. También iniciaremos el servidor de Zabbix.

[root@centos ~]# chmod 600 /usr/local/share/zabbix/conf/zabbix.conf.php

[root@centos ~]# service zabbix_server start

Feb 22, 2010

Enjaular usuarios (chroot) por ssh/sftp/scp con jailkit

Enjaular a un usuario dentro de un sistema Linux viene a ser lo mismo que restringirle el acceso a un determinado árbol de directorios. Por ejemplo, podemos enjaular a un determinado usuario dentro de su propio home, y que no pueda acceder al resto de directorios de la raíz (/etc, /var, /bin, etc.).

La idea es construirle un entorno con una serie de comandos básicos (ls, cp, ...) que queramos que pueda usar, así como las librerías de las que dependen dichas órdenes.

En el presente artículo vamos a construir un directorio enjaulado (/srv/jail) en el que encerraremos al usuario user1 y le daremos acceso a través de SSH, SFTP y SCP. Para ello emplearemos la aplicación jailkit, disponible en los repositorios RPMForge. Utilizaremos una distribución CentOS 5.4 de 64 bits.

[root@centos ~]# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

[root@centos ~]# rpm -Uhv rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

[root@centos ~]# yum install jailkit

En primer lugar utilizaremos la herramienta jk_init para crear el directorio que definiremos como jaula y añadiremos las herramientas de conexión que se podrán utilizar. También copiaremos la shell que utilizará el usuario user1. Para ello emplearemos el comando jk_cp, ya que aparte de copiar la shell, copiará también las librerías necesarias.

[root@centos ~]# jk_init -v -j /srv/jail jk_lsh ssh sftp scp

[root@centos ~]# jk_cp -v -f /srv/jail /bin/bash

[root@centos ~]# ls -l /srv/jail/
total 48
drwxr-xr-x 2 root root 4096 feb 5 16:52 bin
drwxr-xr-x 2 root root 4096 feb 5 16:49 dev
drwxr-xr-x 3 root root 4096 feb 5 16:52 etc
drwxr-xr-x 2 root root 4096 feb 5 16:49 lib
drwxr-xr-x 2 root root 4096 feb 5 16:52 lib64
drwxr-xr-x 6 root root 4096 feb 5 16:49 usr

Después añadiremos al sistema el usuario user1 y le asignaremos una password. También será necesario añadir el registro generado en /etc/passwd dentro del fichero passwd que se habrá creado en el entorno enjaulado.

[root@centos ~]# useradd user1

[root@centos ~]# passwd user1

[root@centos ~]# cat /etc/passwd | grep user1
user1:x:501:501::/home/user1:/bin/bash

[root@centos ~]# cat /etc/passwd | grep user1 >> /srv/jail/etc/passwd

A continuación vamos a enjaular al usuario user1 dentro de la jaula. Veremos como cambia automáticamente el directorio home y la shell asignada previamente.

[root@centos ~]# jk_jailuser -m -j /srv/jail user1

[root@centos ~]# cat /etc/passwd | grep user1
user1:x:500:500::/srv/jail/./home/user1:/usr/sbin/jk_chrootsh

Por último, añadiremos la siguiente configuración al fichero jk_lsh.ini

[root@centos ~]# cat /srv/jail/etc/jailkit/jk_lsh.ini
[user1]
paths= /usr/bin, /usr/lib/
executables= /usr/bin/scp, /usr/libexec/openssh/sftp-server

Si en este momento intentamos acceder a través de una sesión SCP, veremos que tenemos varios fallos al iniciar la sesión. Esto se debe a que el cliente SCP utiliza varias herramientas (ls, groups, sh e id) que no hemos añadido a nuestro entorno enjaulado.

Para añadirlas, utilizaremos el comando jk_cp que ya vimos en los párrafos anteriores. Lo mismo para cualquier herramienta que necesitemos agregar.

[root@centos ~]# jk_cp -v -f /srv/jail /bin/ls /usr/bin/groups /bin/sh /usr/bin/id

Si sólo hubiéramos querido darle acceso al usuario user1 a través del protocolo SFTP, tendríamos que haber ejecutado las siguientes órdenes:

[root@centos ~]# jk_init -v -j /srv/jail jk_lsh sftp

[root@centos ~]# useradd user1

[root@centos ~]# passwd user1

[root@centos ~]# jk_jailuser -m -j /srv/jail user1

[root@centos ~]# cat /srv/jail/etc/jailkit/jk_lsh.ini
[user1]
paths= /usr/bin, /usr/lib/
executables= /usr/bin/scp, /usr/libexec/openssh/sftp-server

Feb 14, 2010

Arquitectura de seguridad local

Una vez analizados los principales rasgos de una arquitectura de seguridad perimetral, vamos a abordar las líneas maestras que debería seguir cualquier arquitectura de seguridad local.

En primer lugar vamos a tratar el tema de los servidores; es conveniente tener actualizados los servidores, no sólo a nivel de parches de seguridad, sino también a medida que van surgiendo nuevas actualizaciones de software, ya que de esta forma tendremos acceso a nuevas funcionalidades así como a mejoras en su rendimiento.

En entornos de producción es recomendable aplicar únicamente los parches de seguridad y de corrección de errores en el código (yum update en sistemas RHEL/Cent0S), y posponer las actualizaciones de versión a migraciones globales y planificadas de todos los sistemas.

Si se emplean versiones muy antiguas de los sistemas operativos, puede darse incluso la situación de que nos quedemos sin soporte alguno. Además es conveniente no utilizar ditintas clases de distribuciones y unificar todos los servidores en base a una única distribución, ya que esto facilitará las tareas de futuros administradores de la red.

A día de hoy, mi opinión personal es emplear la versión CentOS 5.4, ya que se trata de una distribución que a nivel binario es un clon de Red Hat Enterprise Linux, uno de los sistemas más estables y utilizados a nivel empresarial.

Con respecto a la seguridad de los servidores Linux, se debe de aprovechar todas las ventajas que ofrece este tipo de sistema operativo: NetFilter, SELinux context, TCP wrappers, Application control y SELinux boolean.

También es conveniente siempre que se pueda, paravirtualizar los distintos servicios a través de las diferentes tecnologías proporcionadas por VMware o Xen.

En la siguiente figura se muestra un ejemplo de paravirtualización de una máquina que realiza labores de FTP, DNS y SMTP. En dicha imagen puede observarse que se dispone de una única máquina física en la cual se encuentran levantados los tres servicios mencionados. Con el proceso de paravirtualización se crearían tres máquinas virtuales independientes en donde cada una de ellas albergaría un único servicio.


La paravirtualización es una generación de tecnología de virtualización que emplea un sistema más moderno y eficaz en la gestión de los recursos hardware. El sistema operativo virtualizado sabe que se ejecuta en un entorno virtualizado y se adapta a ello para aprovechar ese contexto. De esta forma se consigue que ciertas llamadas privilegiadas no tengan que pasar por la capa de virtualización. Con la paravirtualización se obtienen unas pérdidas de rendimiento de entorno a un 5%, en comparación a si se instalara un sistema operativo sin virtualizar directamente en el mismo hardware.

A continuación se exponen las principales ventajas que se consiguen con la virtualización:
  • Si alguno de los servidores es atacado y se consigue acceder al control de la máquina donde reside el servicio, el resto de servicios de la red permanecerán protegidos al estar emplazados en máquinas virtuales independientes.

  • Se puede establecer de una forma más sencilla y práctica, un sistema de Alta Disponibilidad que permita mantener la continuidad del servicio en situación de caída.

  • En caso de tener que restaurar un determinado servidor, al tenerlo virtualizado el proceso de restauración sería mucho más rápido y sencillo.

Una de las tareas más importantes a realizar por parte de cualquier administrador con el objetivo de securizar correctamente sus sistemas, es la de segmentar correctamente las distintas subredes. Es importante distinguir o delimitar las zonas de una red; de este modo se pueden aplicar diferentes directivas de seguridad que aíslen a las máquinas ante posibles ataques o infecciones.

En caso de que sea necesario configurar algún tipo de red privada virtual, se recomienda encarecidamente no utilizar PPTP. Este protocolo ha quedado obsoleto debido a sus numerosos fallos de seguridad; se recomienda la utilización del protocolo SSL a través de la aplicación OpenVPN. Además todo el tráfico que circule por las VPNs y que llegue a las redes internas, debe de pasar siempre por algún sistema de tipo All-In-One, con el objetivo de que sea previamente analizado.

Las VPNs que se utilicen nunca deben de establecerse a través de una clave compartida. Esta clase de autenticación corre el riesgo de ser rota mediante un ataque de fuerza bruta (debido a la longitud de las contraseñas). Por ello se propone también la implantación de una Autoridad de Certificación, encargada de emitir y administrar los certificados digitales empleados posteriormente para establecer los túneles privados. Los certificados digitales permiten recurrir claves de hasta 2048 bits.

También es recomendable instalar un servidor de monitorización (Zabbix) que se encargue de controlar en todo momento el estado de los servidores, tanto a nivel hardware (niveles de carga de CPU, memoria, disco, etc.) como a nivel software (estado de los distintos servicios, consumo de memoria, etc.).

Además también sería interesante el hecho de poder configurar un servidor de logs remoto, el cual recoja y almacene los logs de todos los servidores, con el objetivo de salvaguardar los eventos acaecidos ante un hipotético ataque.

Por último, decir que sería muy conveniente realizar auditorias periódicas de seguridad (Nessus Vulnerability Scanner) a los distintos sistemas que conforman nuestra infraestructura, ya que aunque una de las tareas de los administradores sea la de permanecer alerta ante cualquier tipo de vulnerabilidad publicada, siempre puede ocurrir que alguna de ellas sea pasada por alto.