OSSEC

Los sistemas HIDS son sistemas de detección de anomalías.
La idea detrás de estos sistemas es mitigar riesgos de seguridad, ya sea tomando medidas preventivas o reactivas en un sistema.

En este post voy a presentarles un sistema en particular, OSSEC. No pretendo indicar que es el único, porque no lo es. Solo quiero mostrarles esta excelente herramienta que nos hace ahorrar mucho esfuerzo, dejando una comparación entre distintos sistemas HIDS
para un próximo post.

Ossec

Ossec es un sistema HIDS o sistema detector de intrusión de host compuesto por un analizador y correlacionador de logs, detector de rootkits, analizador de integridad de archivos, analizador de registro de Windows y un modulo de respuesta activa.
Cualquier sistema operativo tipo POSIX con un compilador ANSI C debería ser suficiente para ejecutar el sistema.

Fue testeado con éxito en (según se informa en la página de Ossec): www.ossec.net

• OpenBSD 3.5, 3.6, 3.7, 3.8 y 3.9,
• Slackware 10.1 y 10.2,
• FreeBSD 5.2.1, 4.10-BETA, 5.4-RELEASE, 6.0-STABLE,
• RedHat 8.0 y 9.0,
• RedHat Enterprise Linux 4,
• Ubuntu 5.04, 5.10 y 6.06,
• Debian 3.1 Sarge,
• Solaris 2.8, 2.9 (Sparc) y 10 (x86),
• AIX 5.2 ML-07,
• MacOSX 10,
• Fedora Core 2,3,4 and 5,
• Suse ES 9,
• Windows XP/2000 (solo agente).

Ossec tiene dos formas de funcionamiento, standalone (modo autónomo) y modo cliente – servidor.

En el modo standalone el host hace de cliente y de servidor, con una lógica de procesos mas simple, ya que no necesita comunicarse con el servidor, pero con las mismas características de funcionamiento, cumpliendo todas las funciones en un 100%.

Este modo es útil para servidores expuestos a internet o en ambientes restringidos, donde no se tiene comunicación con otros servidores.
La principal desventaja de este modo es que todos los registros quedan en el servidor, con lo cual, si necesitamos hacer un análisis forense, no podemos confiar en esos logs, ya que pueden haber sido comprometidos.

En el modo cliente-servidor, el agente (cliente) envía los logs y los resultados de los análisis de sistema y de rootkits al servidor y este responde con una orden al módulo de respuesta activa, si es necesario, o genera una alerta si hay algo fuera de lo normal.

En este modo la comunicación entre el agente y el server es realizada mediante mensajes UDP, es decir, no se establecen conexiones punto a punto. Los paquetes UDP van encriptados mediante una llave simétrica, con lo cual, se puede garantizar, en cierta manera, la confidencialidad de los mensajes transmitidos. La clave de encripción para cada agente es generada en el servidor y es ingresada
en el cliente al momento de configurarlo, teniendo que escribir la clave en el programa de instalación.

El agente mantiene sus archivos de configuración (bases de datos de rootkits y lista de archivos generada por syscheck) almacenadas en forma local, pero de todas maneras, se garantiza la integridad mediante una revisión de versionado periódica contra el servidor (syscheck genera la lista y la envía al servidor).

También es posible que el servidor reciba los mensajes de un syslog remoto para analizar.
En cuanto a la instalación, no hay nada de que preocuparse ya que funciona en cualquier sistema POSIX con un compilador ANSI C.

El sistema es distribuido en código fuente, siendo necesario compilarlo para instalarlo.
De todas maneras, todo el proceso de instalación es mediante un script que contempla la compilación, instalación y configuración inicial.

Todo se hace desde una interfaz respondiendo preguntas, o si se quiere hacer de forma mas tradicional, compilando en forma manual y copiando los binarios a los lugares correspondientes (existe una guía de instalación manual). Se podría decir que la instalación es trivial.

La configuración post instalación no es estrictamente necesaria, ya que con la configuración por defecto mas la generada por el script de instalación es suficiente para tener el sistema funcionando en forma eficiente, pero de todas maneras se recomienda ir ajustando las reglas de detección y correlación para mejorar la eficiencia del sistema y evitar falsos positivos.

Ossec soporta múltiples formatos de logs por defecto, pero siempre se puede extender y mejorar.

Algunos ejemplos de logs soportados son (según la wiki de ossec):
• sshd (OpenSSH)
• Solaris telnetd
• Samba
• Imapd and pop3d
• Postfi
• Microsoft Exchange
• Iptables firewall
• Solaris ipfilter firewall
• AIX ipsec/firewall
• Netscreen firewall
• Windows firewall
• Cisco PIX/ASA
• Cisco IOS IDS/IPS
• Snort IDS (snort full, snortfast y snort syslog)
• Windows event logs

Logcollector y Analisysd

El sistema tiene una colección (adaptable) de reglas para alertas y correlación, descritas en xml. A continuación hay una regla de análisis (Listado 1) y otra de correlación (Listado 2) para el demonio vs-ftpd.

Listado 1. Regla de anàlisis


11400
FAIL LOGIN: 
Login failed accessing the FTP
server.
authentication_failed,


11403

FTP brute force (multiple failed
logins).
authentication_failures,

Listado 2. Regla de correlación


11403

FTP brute force (multiple failed
logins).
authentication_failures,

Para que estas reglas tengan sentido, hay que escribir un decoder (Listado 3), que es donde se especifica la sintaxis de la línea a revisar.

Listado 3. Decodificador de sintaxis


^\(pam_unix\)|^pam_unix


pam
rhost=\S+\s+user=\S+
rhost=(\S+)\s+user=(\S+)
srcip, user

En el caso que alguien quiera ganar acceso al ftp por medio de un ataque del tipo de fuerza bruta, vamos a recibir una alerta de ossec notificándonos del evento y donde nos dice la regla que disparo la alerta y una descripción que contiene las líneas de log que dispararon la regla.

En el caso que tengamos el modulo de respuesta activa funcionando, el servidor ossec, al recibir las líneas de log y procesarlas, va a enviar una orden al agente para que bloquee el acceso, ya sea mediante una regla del firewall o por tcpwrappers (la acción es configurable).

Syscheckd

Otra funcionalidad interesante de Ossec es el detectorde rootkits. Este scanner utiliza dos metodologías para identificar rootkits:

• Identificación basada en firma,

• Identificación basada en anomalías.

Para la identificación basada en firmas se utilizan dos archivos donde se detallan características únicas de varios tipos de rootkits y troyanos, por ejemplo (Listado 4).

Listado 4. Algunas de las firmas de rootkits conocidos

#adore Worm
dev/.shit/red.tgz ! Adore Worm ::/rootkits/adorew.php
usr/lib/libt ! Adore Worm ::/rootkits/adorew.php
usr/bin/adore ! Adore Worm ::/rootkits/adorew.php
*/klogd.o ! Adore Worm ::/rootkits/adorew.php
*/red.tar ! Adore Worm ::/rootkits/adorew.php

La identificación basada en anomalías utiliza un enfoque mas inteligente ya que no busca rootkits conocidos, sino que busca anomalías en el sistema.
Las anomalías que busca son:

• Revisar /dev, solo deberían haber archivos de dispositivos y el script Makedev.
• Buscar en el file system archivos con anomalías de permisos, por ejemplo, archivos cuyo owner sea root pero que tengan permisos de escritura para otros, archivos con suid y archivos y directorios escondidos.
• Buscar procesos escondidos, utilizando getsuid() y kill() (que debería ser la misma) para hacer una lista de pid’s que están siendo usados para después compararla con la salida de ps, si hay diferencias puede existir un rootkit a nivel kernel o una versión modificada de ps.
• Buscar puertos escondidos mediante el uso de bind() contra cada puerto udp y tcp, si no se puede establecer
un vinculo con el puerto, netstat lo debería listar como puerto ocupado.
• Revisar todas las interfaces de red en búsqueda de interfaces en modo promiscuo y comparar esa lista con ifconfig.

Algo interesante respecto a esta funcionalidad, en el modo cliente-servidor es que solo tenemos que mantener la lista de rootkits y troyanos en el servidor ya que cada 10 minutos (por defecto) los agentes comparan la versión de la lista local con la del servidor, si la versión es distinta, el servidor envía una actualizada.

Analizador de integridad

Este modulo revisa el sistema en búsqueda de cambios en archivos, utilizando la siguiente metodología:
• En la primer ejecución genera una lista compuesta por:
• Nombre de archivo,
• Permisos,
• Tamaño,
• Hashes sha1 y md5,
• Ownership.
• La lista es enviada al servidor para ser resguardada.
• En cada ejecución, si alguno de los parámetros listados cambia, se genera una alerta, por ejemplo:

Received From: (agent1) 192.168.0.5->syscheck
Rule: 13 fired (level 8) -> "Integrity checksum of file
'/etc/sudoers' has changed."
Portion of the log(s):
Integrity checksum changed for: '/etc/sudoers'
Size changed from '757' to '736'
Old md5sum was: '344391acfb9ad9c68365a04676a3d81e'
New md5sum is : '5540cce7895b6128c27c8abbb6fbad2d'
Old sha1sum was: 'b581f3c379650223e4f25d8f618a5bbeae6
daa0b'
New sha1sum is : '2b20f8dea8c07e4a10e0ba52c6f51f2aa2f02f8

Execd

El modulo de respuesta activa utiliza un archivo de configuración donde se vinculan reglas (alertas) o niveles de severidad con respuestas (comandos) a ejecutar, por ejemplo:

Configuración de acción para respuesta activa



firewall-drop
local
6
600



host-deny
local
404,405
600

Según se puede ver, se asocia un comando, con un destino (donde se debe ejecutar el comando), un disparador (una regla o una alerta de cierto nivel) con un tiempo de castigo (el tiempo de duración del cambio introducido por el comando).

Existen mas parámetros para definir mejor un bloque de respuesta activa, pueden ser consultados en la documentación que esta en la pagina web.

La definición del comando también es mediante xml, asociando el nombre, el archivo a ejecutar, los parámetros necesarios y si el comando acepta o no el tiempo de timeout.
La definición de host-deny es la siguiente:

host-deny
host-deny.sh
srcip
yes

Conclusión

Como vemos, Ossec es una herramienta bastante completa que cumple su función.
Ossec nos permite saber que esta ocurriendo en nuestros servers en, casi, tiempo real y en forma eficiente.
También nos permite reaccionar a ataques en forma rápida. Teniendo en cuenta que es una herramienta muy adaptable, de muy fácil instalación y casi libre de mantenimiento, no cabe duda que Ossec esta pisando fuerte y esta haciendo pensar a herramientas pagas que ofrecen la misma o menos funcionalidad.

Particularmente yo lo vi instalado en un ambiente de 20 servidores (Windows y Linux) y me sorprendió lo bien que funcionaba ya que no solo permitía detectar abusos, sino que también permitía ver errores poco frecuentes mediante el análisis de los logs.

Personalmente yo ya incluí a Ossec en mi caja de herramientas de seguridad y monitoreo.

Un saludo.