Jul 26, 2010

Detección de rootkits con Rkhunter (Rootkit Hunter) (II)

Una vez presentadas las características de los rootkits y la herramienta que tenemos en Linux para combatirlos, vamos a pasar a instalar Rkhunter 1.3.6 en una máquina CentOS 5.4 de 64 bits.

Rkhunter puede instalarse de forma permanente en el sistema:

[root@centos ~]# tar zxf rkhunter-1.3.6.tar.gz

[root@centos ~]# cd rkhunter-1.3.6

[root@centos rkhunter-1.3.6]# ./installer.sh --install

O de forma temporal:

[root@centos ~]# mkdir /tmp/rkh

[root@centos ~]# cd /tmp/rkh

[root@centos rkh]# tar zxf rkhunter-1.3.6.tar.gz

[root@centos rkh/rkhunter-]# cd rkhunter-1.3.6

[root@centos rkhunter-1.3.6]# ./installer.sh --layout custom . --install

[root@centos rkhunter-1.3.6]# cd files

Para el caso del presente artículo emplearemos la forma temporal. Lo primero que haremos será actualizar las bases de datos con la información del malware actualizada por los desarrolladores de Rkhunter, y a continuación, crearemos una base de datos inicial (rkhunter.dat) con la información (MD5, permisos, etc.) de los principales binarios del sistema.

[root@centos files]# ./rkhunter --update
[ Rootkit Hunter version 1.3.6 ]

Checking rkhunter data files...
Checking file mirrors.dat [ No update ]
Checking file programs_bad.dat [ No update ]
...

[root@centos files]# ./rkhunter --propupd
[ Rootkit Hunter version 1.3.6 ]
File created: searched for 159 files, found 134, missing hashes 35

Si en algún momento alguno de los binarios sufre algún tipo de modificación, tendremos que volver a ejecutar la opción propupd.

Para realizar un escaneo ejecutaremos el siguiente comando (se ha obviado parte de la salida del comando):

[root@centos files]# ./rkhunter --check --sk
[ Rootkit Hunter version 1.3.6 ]

Checking system commands...

Performing 'strings' command checks
Checking 'strings' command [ OK ]

Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]

Performing file properties checks
Checking for prerequisites [ Warning ]
/bin/awk [ OK ]
/bin/basename [ OK ]
...
Checking for rootkits...

Performing check of known rootkit files and directories
55808 Trojan - Variant A [ Not found ]
ADM Worm [ Not found ]
...
Performing additional rootkit checks
Suckit Rookit additional checks [ OK ]
...
Performing malware checks
Checking running processes for suspicious files [ None found ]
...
Performing Linux specific checks
Checking loaded kernel modules [ OK ]
...
Checking the network...

Performing check for backdoor ports
Checking for TCP port 1524 [ Not found ]
Checking for TCP port 1984 [ Not found ]
...
Performing checks on the network interfaces
Checking for promiscuous interfaces [ None found ]

Checking the local host...

Performing system boot checks
Checking for local host name [ Found ]
...
Performing group and account checks
Checking for passwd file [ Found ]
...
Performing system configuration file checks
Checking for SSH configuration file [ Found ]
...
Performing filesystem checks
Checking /dev for suspicious file types [ None found ]
Checking for hidden files and directories [ Warning ]

Checking application versions...

Checking version of GnuPG [ OK ]
...
System checks summary
=====================

File properties checks...
Required commands check failed
Files checked: 134
Suspect files: 5

Rootkit checks...
Rootkits checked : 253
Possible rootkits: 0

Applications checks...
Applications checked: 4
Suspect applications: 2

Dentro del log (rkhunter.log) podremos encontrar información más detallada sobre los warnings y errores encontrados.

Rkhunter dispone de un fichero de configuración donde podremos definir distintas opciones del escaneo (por ejemplo si está permitido el acceso por SSH para root).

[root@centos files]# cat rkhunter.conf
...
ALLOW_SSH_ROOT_USER=yes


Jul 20, 2010

Scripts internos en Zabbix

Uno de los puntos fuertes de Zabbix es que a través de los agentes podemos ejecutar comandos o scripts dentro de los huéspedes o máquinas monitorizadas.

A diferencia de los scripts externos que son ejecutados por el servidor de Zabbix, los scripts internos serán lanzados por el propio agente dentro de la máquina monitorizada.

Vamos a mostrar un ejemplo sencillo, en donde un agente ejecutará periódicamente (cada 30 sg) un script encargado de volcar en un fichero (/tmp/file) el espacio ocupado por el directorio /etc. Este script devolverá el resultado de la operación (variable $?). Las pruebas serán realizadas en un CentOS 5.4 de 64 bits con Zabbix 1.8.1.

Lo primero que haremos será crear un directorio dentro del árbol de Zabbix para ubicar posteriormente nuestro script (script.sh).

[root@centos ~]# mkdir -p /etc/zabbix/internalscripts/

[root@centos ~]# vim /etc/zabbix/internalscripts/script.sh
#!/bin/bash
du -shx /etc >> /tmp/file
echo $?

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

[root@centos ~]# chmod 700 /etc/zabbix/internalscripts/script.sh

Después tendremos que editar el fichero de configuración del agente de Zabbix habilitando la posibilidad de ejecutar comandos remotos.

[root@centos ~]# cat /etc/zabbix/zabbix_agentd.conf
...
# Nombre del host (salida del comando hostname)
Hostname=centos.local

EnableRemoteCommands=1

[root@centos ~]# service zabbix-agent restart

Ahora ya podremos crear un item (desde el interfaz web de Zabbix) que utilice el script creado. Le llamaremos por ejemplo "script interno".



En la figura anterior puede verse que dicho item deberá ser de tipo Zabbix agent (active), y como clave (key) utilizaremos la función system.run para ejecutar el script. El script devolverá un número entero decimal (0 en caso de éxito y 1 en caso contrario); por lo tanto escogeremos como tipo de información Numeric (unsigned).

Un error típico que suele cometer la gente al crear un item de esta naturaleza consiste en establecer un tipo retornado incorrecto. Para el caso anterior hemos dicho que se trataba de un valor entero decimal. Si en dicho script no hubiésemos puesto la línea "echo $?", al poco tiempo de activar el item éste se hubiera deshabilitado, obteniendo un estado con el mensaje Not supported.

Analizando el log del agente de Zabbix hubiéramos visto una línea como la siguiente:

[root@centos ~]# tail -f /var/log/zabbix-agent/zabbix_agentd.log
...
796:20100629:174748.005 Active check [system.run[/etc/zabbix/internalscripts/script.sh]] is not supported. Disabled.


Jul 14, 2010

Detección de rootkits con Rkhunter (Rootkit Hunter) (I)

Los sistemas Linux no son vulnerables en absoluto a los virus informáticos, lo que ocurre es que existen muchos menos virus para Linux que para Windows, y además, una arquitectura basada en Linux es más robusta de cara a una posible infección.

De todas formas el concepto de virus es muy amplio, ya que abarca a una gran variedad de elementos dañinos para un sistema, como por ejemplo troyanos, gusanos, hoaxes, etc., y sus métodos de propagación también pueden llegar a ser innumerables: enlaces o URLs maliciosas, adjuntos en los correos electrónicos, solapados a otros ejecutables, aprovechamiento de vulnerabilidades, etc.

De todo el malware conocido, el único que presenta un peligro real para los sistemas Linux son los llamados rootkits o encubridores, que viene a ser un tipo de software que tiene la finalidad de permanecer oculto y permitir a un intruso (uno vez que ya ha atacado un sistema) volver a acceder posteriormente.

Por ejemplo, un atacante ha podido aprovechar una vulnerabilidad de Apache y a través de un exploit alcanzar privilegios de root. Con estos privilegios, el atacante ha podido instalar un rootkit con el que se garantizará futuros accesos, ya que dicha vulnerabilidad podrá ser corregida en cualquier momento.

Un rootkit puede llegar a instalarse en el kernel (a través de un nuevo código, un módulo, etc.) o bien dentro de una aplicación normal del sistema (un atacante puede eliminar el comando mount y reemplazarlo por otro mount con la misma funcionalidad, pero que además, contenga el backdoor).

Existe una herramienta open source llamada Rootkit Hunter, también conocido como RKhunter, el cual permite detectar rootkits, backdoors y exploits locales. Para ello Rkhunter emplea distintas técnicas de escaneo:
  • Algoritmo MD5: construye inicialmente, una base de datos con los MD5 de los principales binarios del sistema (bash, cp, mount, etc.). De esta forma, cada vez que realice un escaneo podrá comparar los valores MD5 de dichos archivos con los ya existentes en su base de datos, con el objetivo de poder detectar posibles alteraciones.

  • Archivos por defecto: escanea una serie de archivos y directorios que pueden ser utilizados por los rootkits.

  • Archivos ocultos: rastrea la existencia de ficheros ocultos en lugares que normalmente no deben estar.

  • Procesos existentes: compara los procesos obtenidos por el comando 'ps' con los realmente existentes dentro del directorio /proc.

  • Permisos de los archivos: comprueba que los permisos de los principales archivos del sistema no hayan sido modificados.

  • Módulos del kernel: verifica los módulos cargados en el kernel.

  • Puertos abiertos: escanea los puertos abiertos.

Jul 12, 2010

Hoy es un día grande para España

Después de tantos y tantos años esperando, parece que la Historia ha hecho justicia de una vez por todas con España...




Anoche, después de 120 minutos agónicos en donde la selección española se tuvo que enfrentar a un equipo de dos cañoneros y nueve carroñeros, se ha conseguido formar parte de ese elenco de equipos que alguna vez en su historia han logrado un Mundial de fútbol.

Y digo que se ha hecho justicia porque a lo largo de su trayectoria, España siempre ha tenido muy buenos jugadores, pero tal situación nunca se había visto reflejada con el triunfo en dicho campeonato.

Enhorabuena a todos y viva España!

Jul 5, 2010

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

En uno de los artículos anteriores vimos la forma de instalar el servidor de Zabbix desde su propio código fuente. En el presente artículo vamos a desarrollar la instalación del cliente Zabbix (1.8.2) en una máquina RHEL 5.5 de 32 bits.

Vamos a comenzar instalando en nuestro sistema el compilador gcc, necesario para generar el binario del cliente de Zabbix.

[root@rhel ~]# yum install -y gcc

A continuación descargaremos el código fuente de Zabbix, lo descomprimiremos y seguidamente lo compilaremos, generando los binarios correspondientes.

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

[root@rhel ~]# tar xvzf zabbix-1.8.2.tar.gz ; cd zabbix-1.8.2

[root@rhel zabbix-1.8.2]# ./configure --enable-agent

[root@rhel zabbix-1.8.2]# make ; make install

Si hubiéramos querido obtener un binario que incluyera las librerías de forma estática, tendríamos que haber añadido la opción --enable-static al script configure.

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@rhel zabbix-1.8.2]# mkdir -p /etc/zabbix/alert.d /var/log/zabbix-agent /var/run/zabbix-agent

[root@rhel zabbix-1.8.2]# adduser -r -d /var/run/zabbix-agent -s /sbin/nologin zabbix

[root@rhel zabbix-1.8.2]# cp -a misc/conf/zabbix_agentd.conf /etc/zabbix

[root@rhel zabbix-1.8.2]# cp -a misc/init.d/redhat/8.0/zabbix_agentd /etc/init.d

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

[root@rhel zabbix-1.8.2]# chown root:root /etc/init.d/zabbix_agentd

Una vez copiados los ficheros, modificaremos ciertos parámetros que por defecto vienen establecidos en dichos archivos.

[root@rhel zabbix-1.8.2]# 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 (salida del comando hostname)
Hostname=rhel.local

# Dirección IP del servidor Zabbix
Server=192.168.1.10


[root@rhel zabbix-1.8.2]# 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
...

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

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

Ahora sólo nos quedará por iniciar el agente y hacer que éste se inicie automáticamente al arrancar el sistema.

[root@rhel ~]# chkconfig zabbix_agentd on

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

[root@rhel ~]# service zabbix_agentd start

En caso de querer utilizar SELinux, recomiendo tenerlo activado (Enforcing) durante todo el proceso de instalación del cliente, ya que la primera vez que configuré el cliente de Zabbix tenía desabilitado SELinux (disabled), y al volver a reiniciar el sistema con SELinux activado (enforcing), tuve varios problemas.

Jun 28, 2010

Activar SNMP en VMware ESXi

En la versión 4.0 de VMware ESXi, el protocolo SNMP viene deshabilitado por defecto. Por lo tanto, no tendremos activado en la máquina ningún agente SNMP al cual le podamos realizar consultas o nos informe de ciertos eventos a través de traps.

Para activar el protocolo SNMP tendremos que conectarnos al VMware ESXi mediante SSH (service console) y editar el fichero snmp.xml con la siguiente configuración:

~ # cat /etc/vmware/snmp.xml
<config>
<snmpSettings>
<enable>true</enable>
<communities>public</communities>
<targets>192.168.1.150@161 public</targets>
</snmpSettings>
</config>

~ # /sbin/services.sh restart

En dicho fichero de configuración hemos definido una comunidad denominada public y una dirección IP que podrá realizar consultas. Por último, hemos reiniciado los servicios.

Para comprobar que funciona correctamente, solicitaremos el árbol de OIDs al VMware ESXi desde nuestra máquina Linux (target).

[root@centos ~]# snmpwalk -v 2c -c public 192.168.1.10
SNMPv2-MIB::sysDescr.0 = STRING: VMware ESX 4.0.0 build-219382 VMware, Inc. x86_64
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.6876.4.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5672) 0:00:56.72
SNMPv2-MIB::sysContact.0 = STRING: not set
SNMPv2-MIB::sysName.0 = STRING: esxi.local
...

Jun 21, 2010

Distribución automática de software con Opsi (III)

Para finalizar la entrega de artículos correspondientes a la distribución automática de software con Opsi, vamos a ver cómo se gestiona de forma remota una máquina con el agente instalado. Para ello vamos a suponer que hemos instalado el cliente en un equipo Windows XP.

Para acceder al interfaz web de administración de Opsi, teclearemos en un navegador web la siguiente URL: https://servername:4447/configed, donde servername será el nombre o dirección IP de nuestro servidor Opsi.

En la siguiente imagen podemos ver la pantalla principal de la consola de administración web del servidor Opsi. En ella puede verse que tenemos agregado un sistema Windows XP.



Si pulsamos sobre la pestaña Inventario de Hardware, nos saldrá un mensaje con el siguiente texto: Inventario de Hardware todavía no registrado (Activa producto "hwaudit" o producto Netboot "hwinvent"). Si vamos a la pestaña de Inventario de Software, también nos informará que debemos activar el producto "swaudit".

Por lo tanto lo que haremos será ir a la pestaña de Configuración de productos e instalar en el equipo Windows XP los módulos hwaudit y swaudit. Para ello, dentro de la columna "Acción en la cola" elegiremos la opción de "setup" para los dos módulos anteriormente mencionados. Por último, reiniciaremos la máquina Windows.

Ahora si acudimos de nuevo a la pestaña de Inventario de Software, podremos ver una lista detallada de todo el software instalado en el equipo.



Para instalar otro tipo de software, podemos acudir a la wiki de opsi y utilizar alguna de las plantillas de script ya existentes (Firefox, Adobe Flash Player, etc.).