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

Jun 14, 2010

Xrdp: escritorio remoto Linux por Terminal Server

Para acceder a un escritorio remoto Linux a través de un sistema Windows, actualmente existen diferentes opciones: VNC, NX, etc. El problema de estas aplicaciones es que la mayoría de ellas son de pago y además, hay que instalar un software adicional en el equipo Windows (cliente).

Para evitar tener que instalar ningún tipo de software en las máquinas Windows y utilizar el Terminal Server (cliente nativo basado en el protocolo RDP que permite acceder a escritorios remotos), podemos instalar en Linux la aplicación xrdp combinado con VNC (TightVNC).

La instalación no tiene ningún misterio (yo la he realizado en una Ubuntu 10.04). Sólo hay que tener en cuenta que primero hay que instalar TightVNC y después xrdp; en caso contrario tendremos problemas.

root@ubuntu:~# aptitude install tightvncserver

root@ubuntu:~# aptitude install xrdp

root@ubuntu:~# reboot

En caso de distribuciones Linux con un escritorio Gnome, habrá que poner a false la variable /apps/gnome_settings_daemon/plugins/keyboard (para ello se puede emplear el editor gconf-editor).

Para conectarnos al escritorio Linux desde Windows, iremos a Inicio, Programas, Accesorios, Conexión a Escritorio remoto. En la aplicación tendremos que poner la dirección IP del equipo Linux.



A continuación obtendremos un nuevo cuadro de control (Login to xrdp) en el cual tendremos que seleccionar en el primer campo (Module) la opción sesman-Xvnc. En los campos username y password utilizaremos un usuario perteneciente al sistema Linux.



Lo único que no he conseguido configurar es el soporte del idioma español para el teclado. De momento xrdp no tiene soporte para este idioma, así que nos tendremos que conformar con un teclado en inglés.

Jun 7, 2010

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

En el artículo anterior se presentó e instaló la aplicación Opsi. En este segundo artículo vamos a ver cómo preparar el software a través del cual podremos instalar los agentes en las máquinas Windows.

En primer lugar descargaremos todos los paquetes de Opsi y a continuación los instalaremos. De esta manera generaremos la estructura de directorios donde residirán los distintos posibles agentes (Windows XP, Server, etc.).

root@opsiserver:/home/opsiproducts# wget -r -l1 -nd -nc -A '*.opsi' http://download.uib.de/opsi3.4/produkte/essential

root@opsiserver:/home/opsiproducts# opsi-package-manager -i *.opsi

Después de realizar esta operación, todo el software referente a los distintos clientes habrá quedado depositado en la siguiente ruta:

root@opsiserver:~# ls -l /opt/pcbin/install/
total 96
drwxrwx--- 3 opsiconfd pcpatch 4096 2010-05-27 13:12 hwaudit
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:12 hwinvent
drwxrwx--- 3 opsiconfd pcpatch 4096 2010-05-27 13:12 javavm
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:12 memtest86
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:12 ntfs-restore-image
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:12 ntfs-write-image
drwxrwx--- 9 opsiconfd pcpatch 4096 2010-05-27 13:12 opsi-adminutils
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:12 opsi-template
drwxrwx--- 3 opsiconfd pcpatch 4096 2010-05-27 13:12 opsi-winst
drwxrwx--- 4 opsiconfd pcpatch 4096 2010-05-27 13:12 preloginloader
drwxrwx--- 4 opsiconfd pcpatch 4096 2010-05-27 13:13 python
drwxrwx--- 2 opsiconfd pcpatch 4096 2010-05-27 13:13 shutdownwanted
drwxrwx--- 3 opsiconfd pcpatch 4096 2010-05-27 13:13 swaudit
drwxrwx--- 6 opsiconfd pcpatch 4096 2010-05-27 13:13 win2003
drwxrwx--- 7 opsiconfd pcpatch 4096 2010-05-27 13:13 win2008
drwxrwx--- 7 opsiconfd pcpatch 4096 2010-05-27 13:13 win2008-x64
drwxrwx--- 6 opsiconfd pcpatch 4096 2010-05-27 13:13 win2k
...

Por lo tanto lo que tendremos que hacer será dejar accesible a través de Samba dichos directorios, con el objetivo de que cuando vayamos a instalar un cliente de Opsi en un determinado sistema Windows, podamos acceder a él a través de NetBIOS.

root@opsiserver:~# cat /etc/samba/smb.conf
...
[opt_pcbin]
available = yes
comment = opsi depot share
path = /opt/pcbin
oplocks = no
level2 oplocks = no
writeable = yes
invalid users = root
...

root@opsiserver:~# service smbd restart

Ahora de esta forma si queremos instalar el cliente de Opsi en una máquina Windows, accederemos por NetBIOS a dicho compartido (\\opsiserver.ubuntu.local en mi caso) y dentro de la carpeta opt_pcbin\install\preloginloader\, ejecutaremos el script service_setup.cmd.