forondarenanet

Continúo la serie de posts sobre Hadoop describiendo, muy por encima, los componentes y la estructura que suelen tener este tipo de sistemas. Como ya he dicho en otros posts, este blog pretende ser sobre todo práctico, así que no me voy a extender demasiado.

Gráficamente un cluster Hadoop se puede parecer mucho a esto:

JobTracker:
En un cluster hay un único JobTracker. Su labor principal es la gestión de los TaskTrackers, entre los que distribuye los trabajos MapReduce que recibe. Es, por lo tanto, el interfaz principal que tienen los usuarios para acceder al cluster.

TaskTracker:
Un cluster tiene n TaskTrackers que se encargan de la ejecución de las tareas map y reduce en los nodos. Cada uno de los TaskTrackers gestiona la ejecución de estas tareas en una máquina del cluster. El JobTracker se encarga, a su vez, de controlarlos.

NameNode:
Las funciones principales del NameNode son el almacenamiento y la gestión de los metadatos del sistema de ficheros distribuido y ofrecer el interfaz principal que tiene el usuario para acceder al contenido HDFS. En un cluster hay un único proceso NameNode.
Sin los metadatos que mantiene el NameNode no se sabría en qué nodo está cada bloque, además de perderse la información sobre la estructura de directorios. Es, por lo tanto, el componente más importante del cluster, y debe estar redundado. Hadoop no ofrece de manera nativa ningún mecanismo de alta disponibilidad, pero sí dispone de herramientas que permiten replicar la información. Entre ellas está el NameNode secundario, que permite guardar una copia de los metadatos (en realidad hace más cosas) en una máquina diferente al NameNode. Eso sí, no es una copia en tiempo real, y no ofrece failover automático en caso de fallo del primario. Para esto necesitamos usar otro tipo de herramientas, entre las que destacan DRBD y Heartbeat.

DataNode:
Estos procesos ofrecen el servicio de almacenamiento de bloques para el sistema de ficheros distribuido. Son coordinados por el NameNode.

Estos son los procesos principales del sistema, pero hay otros, como el Balancer, que se encarga de equilibrar la distribución de los bloques entre los DataNodes, por ejemplo cuando se añade un nuevo servidor.

Mi laboratorio se limita a cuatro servidores: un NameNode+JobTracker y tres DataNode+TaskTracker, en cuatro máquinas virtuales de un core y 1G de memoria, para un total de 5G de almacenamiento.

hadoop@fn140:/usr/local/hadoop/conf$ hadoop dfsadmin -report
Configured Capacity: 8695013376 (8.1 GB)
Present Capacity: 5455364096 (5.08 GB)
DFS Remaining: 5455290368 (5.08 GB)
DFS Used: 73728 (72 KB)
DFS Used%: 0%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0

-------------------------------------------------
Datanodes available: 3 (3 total, 0 dead)

Name: 192.168.10.142:50010
Decommission Status : Normal
Configured Capacity: 2898337792 (2.7 GB)
DFS Used: 24576 (24 KB)
Non DFS Used: 1079918592 (1.01 GB)
DFS Remaining: 1818394624(1.69 GB)
DFS Used%: 0%
DFS Remaining%: 62.74%
Last contact: Sun Jan 31 16:10:58 CET 2010

Name: 192.168.10.143:50010
Decommission Status : Normal
Configured Capacity: 2898337792 (2.7 GB)
DFS Used: 24576 (24 KB)
Non DFS Used: 1080020992 (1.01 GB)
DFS Remaining: 1818292224(1.69 GB)
DFS Used%: 0%
DFS Remaining%: 62.74%
Last contact: Sun Jan 31 16:10:58 CET 2010

Name: 192.168.10.141:50010
Decommission Status : Normal
Configured Capacity: 2898337792 (2.7 GB)
DFS Used: 24576 (24 KB)
Non DFS Used: 1079709696 (1.01 GB)
DFS Remaining: 1818603520(1.69 GB)
DFS Used%: 0%
DFS Remaining%: 62.75%
Last contact: Sun Jan 31 16:10:56 CET 2010

En los próximos dos posts voy a dejar la “teoría” para pasar a la práctica, empezando por una de las aplicaciones más obvias de Hadoop, como es el tratamiento de logs; para seguir por una de las utilidades que existen para facilitar el desarrollo de aplicaciones MapReduce: pig.

foron linux hadoop, mapreduce

Allá por el año 2003, cuando Google ya dominaba el mundo de los buscadores, muchos administradores de sistemas nos preguntábamos por la tecnología que usarían para indexar páginas, calcular Pageranks, gestionar el almacenamiento ….

En ese momento Google publicó varios documentos al respecto, como este sobre MapReduce y este otro sobre su sistema de ficheros GFS (Google File System), que daban algunas pistas, y que a la larga han sido la base de varios proyectos, como Hadoop.

Pretendo que este blog sea sobre todo práctico, así que no voy a escribir demasiado ni sobre la teoría que hay detrás de MapReduce (programación funcional, map/reduce, bla bla bla) ni sobre Google y GFS. Para el que quiera leer algo más sobre la tecnología de Google recomiendo este excelente blog en el que se pueden encontrar varios posts sobre el buscador.

El problema
El problema es sencillo y se resume en el volumen de datos, cada vez mayor, que generan las aplicaciones; y que por supuesto hay que tratar. Por dar un ejemplo, en el 2008 Yahoo! gestionaba unos 5PB de almacenamiento para generar su “webmap”[1], que es uno de los componentes que usa su buscador.
Otro ejemplo es Rackspace, y su división de correo, Mailtrust, que genera más de 150GB de logs de correo al día. Por supuesto, además de ser mucho volumen acomulado, es fundamental que se pueda tratar de una forma ágil para dar una respuesta rápida a clientes que piden cosas como “el correo que me mandó fulanito hace 3 meses no me ha llegado” o “quiero todos los correos recibidos en mi dominio en los últimos 5 meses”. Esto es razonablemente sencillo cuando se controlan unos pocos cientos de GB, pero se hace mucho más difícil cuando la escala pasa al Tera.

El que haya nombrado estos dos ejemplos no es casual, ya que Yahoo! y Rackspace son dos de los usuarios más notables (junto a Facebook, LastFM, …) del software que voy a describir en los siguientes posts: Hadoop.

¿Qué es Hadoop?

Resumiendo mucho, Hadoop es un framework software que intenta implementar los conceptos de MapReduce y GFS que presentó Google. Está pensado, por lo tanto, para el tratamiento distribuido de grandes cantidades de datos en máquinas de bajo coste y con poca fiabilidad.

Partiendo de esta base, parece claro que hace falta un sistema de ficheros pensado para almacenar mucha información y con tolerancia ante fallos. Aquí es donde aparece HDFS (Hadoop Distributed File System). Algunas de sus características:

• El tamaño de bloque por defecto en este sistema de ficheros es de 64MB, pero muchas veces se aumenta a 128MB.
• Ofrece la mencionada disponibilidad al dejar varias copias de cada bloque en máquinas diferentes.
• Usa el concepto de “rack awareness”, para saber dónde está cada bloque y qué proceso de cálculo puede acceder más rápido a él.
• Su diseño facilita la lectura secuencial de datos (razonable en discos estándar de bajo coste), pero lo hace sacrificando otras características propias de los sistemas de ficheros POSIX. Por ejemplo, que nadie piense editar un fichero en HDFS y borrar la línea número 2000.

Por otro lado, el framework implementa el concepto MapReduce, que como ya he escrito consiste en dividir el trabajo entre n servidores para presentar el resultado después de forma coherente. Veamos un ejemplo:

Digamos[2] que tenemos un cluster de 4 máquinas Hadoop que guardan logs de apache de 40 servidores balanceados, para un total de 100GB al día. Nuestro objetivo es diseñar un trabajo MapReduce para sumar los accesos que ha hecho cada IP en todos los frontales.

Los logs van a ser sencillos y se van a limitar a “FECHA IP URL”.

Servidor 1:

FECHA 172.17.2.34 /index.html
FECHA 172.17.7.13 /contenido/futbol.html
FECHA 172.17.2.34 /img/banner.jpg
FECHA 172.17.2.42 /index.html

Servidor 2:

FECHA 172.17.2.34 /contenido/peliculas.html
FECHA 172.17.7.13 /img/futbol.jpg

Servidor 3:

FECHA 172.17.7.13 /index.html
FECHA 172.17.2.34 /peliculas/bladerunner.html
FECHA 172.17.2.42 /img/banner.jpg

Servidor 4:

FECHA 172.17.2.42 /contenido/series.html
FECHA 172.17.2.42 /img/series.jpg

A partir de estos datos Hadoop empezará la fase Map, que se ejecuta paralelamente en las máquinas del cluster, y que consiste en adaptar las líneas de log al formato clave< tabulador >valor.

Volviendo al ejemplo, la clave será la IP, y el valor la URL (no necesitamos la fecha).
El resultado de la fase Map es el siguiente[3]:

(172.17.2.34 [/index.html /img/banner.jpg /contenido/peliculas.html /peliculas/bladerunner.html])
(172.17.2.42 [/index.html /img/banner.jpg /contenido/series.html /img/series.jpg])
(172.17.7.13 [/contenido/futbol.html /img/futbol.jpg /index.html])

Hemos generado un listado ordenado por IP, en el que se identifican todos los accesos que ha habido.

Una vez hecho esto Hadoop entrega trozos de esta salida a n procesos Reduce, que en este sencillo ejemplo sólo tienen que contar las URL que aparecen en el valor, para generar algo como lo siguiente:

(172.17.2.34    4)
(172.17.2.42    4)
(172.17.7.13    3)

Esto no es más que un ejemplo. En la realidad, Hadoop se ha usado para cosas tan diversas como convertir 4TB de artículos de periódico escaneados en formato tiff en 11 millones de pdfs; todo usando unas 100 instancias de amazon y en menos de 24 horas, por un total de 240$ sin contar ancho de banda, como se puede ver aquí.

El próximo post describirá una instalación básica del sistema, y el siguiente será una prueba algo más interesante de uso con logs de postfix+amavis, muy al estilo Mailtrust, y usando perl y quizá alguno de los proyectos de apoyo que han surgido alrededor de Hadoop; como Hive, que fue desarrollado por Facebook para crear trabajos MapReduce desde una consola con sintaxis muy similar a SQL.

[1] En el 2008 el webmap de Yahoo! era un grafo de un trillón de vértices(enlaces web) y 100 billones de nodos (URL únicas).
[2] Los tres o cuatro lectores de este blog se enfadan si no uso al menos un “digamos” o “supongamos” en cada post.
[3] En realidad hay más fases, como sort-suffle.

foron linux hadoop, mapreduce

Bueno, en realidad el nombre del post no se corresponde con este pequeño artículo, en el que sólo voy a ejecutar un “dd” y un “hdparm” sobre un par de particiones, en discos diferentes, bajo un mismo grupo LVM.

Resumiendo:

Tengo dos discos SATA de 500G, baratos, de poco más de 50 euros cada uno. Cada disco tiene dos particiones de 100G independientes, y otras dos de 400G como particiones LVM, para dar un total de 800G disponibles para el gestor de volúmenes.

Una de las particiones de 100G la dejo vacía mientras no la necesite. La otra la uso para la raíz y /boot del sistema.

En un principio sólo pongo /home en LVM, y luego, según se valla llenando “/”, voy creando otros volúmenes, por ejemplo para /var. Todo un poco rebuscado, pero así mantengo fresco lo poco que sé sobre LVM.

La máquina es una i7 a 2.80GHz, con memoria de sobra. Además, está completamente idle. Como hago copias de seguridad a menudo no me preocupa demasiado que se fastidien los discos. Por lo tanto, me he ahorrado el fakeraid de la placa base y el raid por software de linux. Por cierto, esta prueba se ha hecho sobre una Debian Squeeze de 64 bits básica, y un kernel 2.6.32 compilado a mano.

La creación de los volúmenes no tiene misterio y usa los parámetros por defecto. En otros posts quizá publique pruebas diferentes:

pvcreate /dev/sda2
pvcreate /dev/sdb2

vgcreate vg_prueba /dev/sda2 /dev/sdb2

lvcreate -i2 -L200G -nlv_home vg_prueba

mkfs.ext3 /dev/mapper/vg_prueba-lv_home

mount /dev/mapper/vg_prueba-lv_home /home

Como se puede ver, he utilizado un stripe de 2 y he formateado la partición como ext3.
Ejecutamos ahora escrituras secuenciales con dd sobre ese punto de montaje:

# time dd if=/dev/zero of=/home/prueba/test_escritura bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1,1 GB) copied, 2,94397 s, 365 MB/s

real	0m2.945s
user	0m0.098s
sys	0m2.700s

Y ahora hdparm:

# hdparm -tT /dev/mapper/vg_prueba-lv_home 

/dev/mapper/vg_prueba-lv_home:
 Timing cached reads:   18472 MB in  2.00 seconds = 9245.75 MB/sec
 Timing buffered disk reads:  716 MB in  3.01 seconds = 238.02 MB/sec

Lo dicho, más adelante quizá publique alguna prueba más con diferentes sistemas de ficheros o parámetros LVM.

Update 1: He hecho una instalación de 32 bits para ver los resultados. En este caso el dd no llegaba ni remotamente a 250 MB/s.
Update 2: He hecho otra prueba con otros módulos de memoria que me han dejado, y los resultados son muuuy diferentes. Siempre hablo del más sencillo “dd” que se puede hacer, claro:

time dd if=/dev/zero of=/home/foron/test_escritura2 bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1,1 GB) copied, 1,97434 s, 544 MB/s

real	0m1.975s
user	0m0.097s
sys	0m1.863s

foron linux linux, LVM, rendimiento

A veces (seguro que pocas), nos encontramos ante una máquina que por algún motivo ha dejado de trabajar como se esperaba.
Digamos que el rendimiento o el IO del equipo baja, sin motivo visible. Digamos que no hay logs que indiquen problemas, ni errores del sistema. Nada.
Este es el momento para el kung fu, el voodoo o todo tipo de técnicas adivinatorias que tanto usamos los informáticos. Muchas veces es suficiente, pero no siempre, y no hay nada peor que no ser capaz de dar una explicación a un problema.

Supongamos que tenemos la arquitectura de la imagen, con un par de balanceadores de carga, unas cuantas máquinas iguales que pueden ser servidores web, ftp, pop, smtp o cualquier otra cosa, y un par de servidores de almacenamiento nfs.
Teniendo en cuenta que los balanceadores de carga suelen dar la posibilidad de asignar diferentes pesos a cada máquina balanceada, ¿Por qué no usar uno de estos servidores para la monitorización del sistema? Es perfectamente posible enviar un poco menos de tráfico a la máquina destinada a SystemTap, de tal manera que no afecte al rendimiento global, para que podamos darnos un mecanismo para tener nuestra infraestructura controlada.

En este post sólo voy a referenciar algunos scripts que están disponibles en la web y en el redpaper. Además, el propio software viene con muchos ejemplos. En CentOS se puede instalar el rpm “systemtap-testsuite” para probar varios scripts.

Vamos a empezar con un par de ejemplos para usar más en un entorno académico que en la práctica.

Digamos que queremos aprender “lo que pasa” cuando hacemos un “ls” en un directorio de una partición ext3. Con este sencillo script:

#! /usr/bin/env stap

probe module("ext3").function("*").call
{
   printf("%s -> %s\n", thread_indent(1), probefunc())
}
probe module("ext3").function("*").return
{
   printf("%s <- %s\n", thread_indent(-1), probefunc())
}

Vamos a hacer un printf cada vez que comience y termine la ejecución de cualquier función del módulo ext3. En el printf vamos a tabular el nombre de la función que se ha ejecutado. El resultado es algo así:

   ...
     2 ls(31789): <- ext3_permission
     0 ls(31789): -> ext3_dirty_inode
     8 ls(31789):  -> ext3_journal_start_sb
    21 ls(31789):  <- ext3_journal_start_sb
    26 ls(31789):  -> ext3_mark_inode_dirty
    31 ls(31789):   -> ext3_reserve_inode_write
    35 ls(31789):    -> ext3_get_inode_loc
    39 ls(31789):     -> __ext3_get_inode_loc
    52 ls(31789):     <- __ext3_get_inode_loc
    56 ls(31789):    <- ext3_get_inode_loc
    61 ls(31789):   <- ext3_reserve_inode_write
    67 ls(31789):   -> ext3_mark_iloc_dirty
    74 ls(31789):   <- ext3_mark_iloc_dirty
    77 ls(31789):  <- ext3_mark_inode_dirty
    83 ls(31789):  -> __ext3_journal_stop
    87 ls(31789):  <- __ext3_journal_stop
    90 ls(31789): <- ext3_dirty_inode
     0 ls(31789): -> ext3_permission
   ...

Como he dicho, no es algo demasiado práctico, pero puede servir a algún profesor para suspender a un buen porcentaje de pobres alumnos
Sigamos con algún otro ejemplo. Digamos que queremos programar un "nettop" que nos diga qué conexiones se están abriendo en una máquina en cada momento. Con un script similar al siguiente lo tendremos en unos minutos:

#! /usr/bin/env stap

global ifxmit, ifrecv

probe netdev.transmit
{
  ifxmit[pid(), dev_name, execname(), uid()] <<< length
}

probe netdev.receive
{
  ifrecv[pid(), dev_name, execname(), uid()] <<< length
}

function print_activity()
{
  printf("%5s %5s %-7s %7s %7s %7s %7s %-15s\n",
         "PID", "UID", "DEV", "XMIT_PK", "RECV_PK",
         "XMIT_KB", "RECV_KB", "COMMAND")

  foreach ([pid, dev, exec, uid] in ifrecv-) {
    n_xmit = @count(ifxmit[pid, dev, exec, uid])
    n_recv = @count(ifrecv[pid, dev, exec, uid])
    printf("%5d %5d %-7s %7d %7d %7d %7d %-15s\n",
           pid, uid, dev, n_xmit, n_recv,
           n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0,
           n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0,
           exec)
  }
  print("\n")
  delete ifxmit
  delete ifrecv
}

probe timer.ms(5000), end, error
{
  print_activity()
}

¿Qué es lo que hemos hecho? Hemos generado tres "probes". Por un lado, cuando se recibe o trasmite a través de la red añadimos a los arrays "ifxmit, ifrecv" información sobre qué proceso y en qué interfaz ha enviado o recibido. Por otro lado, cada 5000 ms o cuando haya un error o termine el script mostramos la información por pantalla. El resultado puede ser algo similar a lo siguiente:

  PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
31485   500 eth0          1       1       0       0 sshd           

y pasados unos miles de milisegundos ...

  PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
15337    48 eth0          4       5       5       0 httpd
31485   500 eth0          1       1       0       0 sshd

Como se ve, tengo una sesión ssh abierta permanentemente, y he consultado una página web en el servidor monitorizado.
Por supuesto, esto puede no ser muy práctico en servidores muy activos, pero puede dar alguna idea a algún administrador.
Igual que hemos hecho un "nettop", también podemos hacer un "disktop" que muestre un resultado como el siguiente:

Sat Apr 11 17:22:03 2009 , Average:   0Kb/sec, Read:       0Kb, Write:      0Kb
     UID      PID     PPID                       CMD   DEVICE    T        BYTES
      48    15342    15239                     httpd     dm-0    W          210
      48    15343    15239                     httpd     dm-0    W          210
      48    15337    15239                     httpd     dm-0    W          210
      48    15336    15239                     httpd     dm-0    W          210

Lo que hecho es hacer el mismo wget varias veces. Para el que tenga curiosidad, los procesos httpd (que por cierto usa el usuario id=48) ejecutando en el servidor son:

# pstree -p | grep http
        |-httpd(15239)-+-httpd(15336)
        |              |-httpd(15337)
        |              |-httpd(15338)
        |              |-httpd(15339)
        |              |-httpd(15340)
        |              |-httpd(15341)
        |              |-httpd(15342)
        |              `-httpd(15343)

El script disktop está disponible en "/usr/share/systemtap/testsuite/systemtap.examples/io" del rpm "systemtap-testsuite".

Volvamos al primer ejemplo del post. Teníamos un grupo de servidores que han dejado de funcionar como deben. Digamos que sospechamos de la velocidad con la que nuestros servidores nfs están sirviendo el contenido de los servidores web.
Podemos probar aquellos ficheros que necesiten más de 1 segundo para abrirse:

#!/usr/bin/stap

global open , names
probe begin {
        printf("%10s %12s %30s\n","Process" , "Open time(s)" , "File Name")
}
probe kernel.function("sys_open").return{
        open[execname(),task_tid(task_current()),$return] = gettimeofday_us()
        names[execname(),task_tid(task_current()),$return] = user_string($filename)
}
probe kernel.function("sys_close"){
        open_time_ms = (gettimeofday_us() - open[execname(),task_tid(task_current()), $fd])
        open_time_s = open_time_ms / 1000000
        if ((open_time_s >= 1) && (names[execname(),task_tid(task_current()), $fd] != "")) {
                printf("%10s %6d.%.5d %30s\n", execname(),
open_time_s,open_time_ms%1000000,names[execname(),task_tid(task_current()), $fd])
        }
}

Con este sencillo script estaría hecho:

   Process Open time(s)                      File Name
     httpd      8.471285 /var/www/html/lectura_lenta.html

En este caso al servidor web le ha costado 8.5 segundos servir el fichero lectura_lenta.html. Después será responsabilidad nuestra buscar los problemas.

En definitiva, systemtap es una herramienta muy completa, pero que como tal requiere algo de práctica para ser útil. No sé si alguna vez va a tener mucho éxito en entornos de producción, pero no está de más saber que existe.

foron linux kernel, linux, monitorizacion, systemtap

Empiezo otra serie de dos posts. En este caso sobre algo que tenía “pendiente” desde hace ya tiempo. De hecho, normalmente escribiría mis propios ejemplos para publicarlos aquí, pero para ir más rápido me voy a limitar a referenciar los scripts que usaré para mostrar las funcionalidades de ….. SystemTap.
SystemTap es una herramienta que sirve para monitorizar en tiempo real lo que está pasando con un kernel linux. Quitando el detalle de que el kernel tiene que tener ciertas opciones compiladas (luego las comento), SystemTap tiene la gran ventaja de no requerir ningún tipo de reinicio para empezar a trabajar.

¿Qué podemos monitorizar con SystemTap?
Pues ….. prácticamente todo lo que queramos. La segunda parte de este post tratará algunos ejemplos, pero por dar alguna pista, con este software podemos desde vigilar los procesos que más I/O están generando a programarnos un “nettop” que diga los procesos que más están usando la red.

¿Cómo funciona SystemTap?
Con SystemTap se le dice al kernel que ejecute una rutina cuando ocurre un evento, que puede basarse, por citar dos ejemplos, en el tiempo (cada n segundos) o en una llamada del sistema (al ejecutarse un vfs_read).
Para esto se usa un lenguaje de programación propio con el que se definen los “probe points” y las diferentes funciones. A pesar de ofrecer muchas posibilidades, el propio lenguaje tiene un control especial sobre los bucles infinitos, el acceso a memoria o la recursividad, por poner tres ejemplos. ¿Por qué tanto control? Pues porque a partir de este código se genera un módulo de kernel que se carga en el sistema. Claro, no hace falta decir las consecuencias de un bucle “mal hecho” a tan bajo nivel.

¿Qué necesita el kernel de linux para poder usar SystemTap?
Para empezar, cómo no, necesitamos un núcleo capaz de cargar módulos. Después, deberemos activar el soporte para los distintos tipos de debug que tiene el kernel, como el del sistema de ficheros, el del propio kernel o los kprobes. Traducido a formato .config, necesitamos las opciones CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_MODULES y CONFIG_MODULES_UNLOAD.
Algunas distribuciones incluyen kernels específicos con estas opciones ya activadas.

¿Por qué SystemTap y no strace o gdb?
Bueno, esta seguramente sea una buena pregunta, al menos hasta ver los ejemplos de la segunda parte de este post; pero resumiendo, con SystemTap podemos:

• Ver de forma integrada y unificada lo que pasa en el kernel y en las aplicaciones que ejecuta.
• Probar aplicaciones multihilo.
• Monitorizar aplicaciones multiproceso, como las cliente-servidor, en las que ambos componentes son procesos independientes.
• Monitorizar en tiempo real y a prácticamente la velocidad de ejecución original.
• Escribir nuestros propios monitores que den detalles que aplicaciones “generalistas” no son capaces de dar.

¿Cuáles son los aspectos negativos del invento?
Evidentemente, no todos son ventajas con SystemTap. Podríamos hablar de los inconvenientes técnicos, porque las opciones de debug del kernel ralentizan un poco la velocidad del sistema, pero yo creo que los mayores problemas vienen por el aprendizaje necesario para usar el software. Para empezar, hay que tener un cierto conocimiento del kernel de linux; después, hay que saber las posibilidades del lenguaje de programación, y por último hay que ser capaz de interpretar los resultados. Todo esto desmoralizará a más de uno, seguro, que preferirá seguir con top, htop, vmstat y demás familia antes de meterse en este embolado.
Afortunadamente, ya hay multitud de scripts disponibles en Internet para todo tipo de situaciones.

Suelo terminar los posts con una referencia bibliográfica. En este caso no creo que haya ningún libro sobre SystemTap, pero sí que hay un redpaper de IBM (que debería pasar a ser un redBOOK pronto ): SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems

foron linux kernel, linux, monitorizacion, systemtap

En este último post de la serie vamos a ver, como siempre muy por encima, la funcionalidad “active response” que ofrece ossec. En definitiva, se trata de ser capaces de ejecutar un script cuando se activa un evento. Esto normalmente se usa para añadir reglas en firewalls, para añadir reglas tcp wrapper o para bloquear usuarios, pero en el fondo se puede hacer cualquier cosa que se pueda escribir en un programa.
Por ejemplo, si una de las máquinas monitorizadas es un servidor de correo se podría añadir una IP que generase una alerta a una lista de acceso, o a una base de datos RBL. O también se podrían añadir reglas de modsecurity en un servidor web.

Para el ejemplo de este post, digamos que como administradores ya estamos usando psad para crear reglas en nuestro firewall. Digamos, además, que sólo queremos que sea psad el responsable de las reglas dinámicas en el cortafuegos.

Rootkits, accesos no permitidos, …. No parece necesario justificar la necesidad de tener el firewall monitorizado, ¿Verdad?

Nuestro objetivo es crear reglas para psad desde ossec.
Primero definimos el comando en ossec.conf para poder usarlo más adelante en la configuración de la respuesta activa.

<command>
  <name>psad</name>
  <executable>psad.sh</executable>
  <expect>user,srcip</expect>
</command>

El script “psad.sh” (que guardaremos en $ossec_instalacion/active-response/bin con permisos de ejecución) tiene el siguiente contenido:

#!/bin/bash
# Anyade una regla de psad usando la IP origen. Tambien pasamos el usuario, pero no lo vamos a usar.
# Entrada: user, srcip
# Salida: Nada. Ejecuta una regla psad
ACCION=$1
USUARIO=$2
IP=$3

psad -fw-block-ip $IP

Ahora sólo queda configurar la respuesta activa en ossec.conf.

<active-response>
  <disabled>no</disabled>
  <command>psad</command>
  <location>defined-agent</location>
  <agent_id>001</agent_id>
  <level>10</level>
  <rules_group>authentication_failures</rules_group>
</active-response>

Estamos diciendo que vamos a ejecutar en el agente 001 (el firewall) el comando psad cuando ocurra un evento de nivel 10 y del grupo authentication_failures (por ejemplo la regla 5720).

Veamos si funciona bien intentando loguearnos varias veces desde una máquina (después de haber recargado la configuración de ossec). Este es el resultado

Nov  9 00:50:03 firewall psad: added iptables auto-block against 192.168.10.133 for 3600 seconds

Chain PSAD_BLOCK (1 references)
target     prot opt source               destination
DROP       all  --  192.168.10.133       0.0.0.0/0

Como siempre, y para aquellos que quieran profundizar más, recomiendo el libro http://www.elsevierdirect.com/product.jsp?isbn=9781597492409.

foron seguridad firewall, ossec, psad, seguridad

En mi primer post sobre ossec he mostrado los pasos para hacer una instalación básica y completamente estándar de ossec. En este post vamos a ver lo que hay por debajo del software.

Ossec usa tres componentes: un detector de rootkits, una herramienta para revisar la integridad del sistema, y el analizador de logs. Todas ellas se configuran en el fichero ossec.conf.

Este fichero de configuración tiene una estructura muy clara, en formato xml, en el que se definen varios bloques.

En este post sólo voy a dar algunas ideas básicas sobre el formato con el que se definen las reglas que describen los eventos detectables en los logs.

Tanto el chequeo de integridad como el detector de rootkits se configuran de una forma muy similar, así que lo dejaré para que quien quiera se pelee con ello.

En ossec.conf se definen los logs que se quieren monitorizar dentro de secciones “localfile”. Un ejemplo:

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

En este caso se dice que queremos vigilar auth.log, del tipo syslog. Existen varios formatos definidos, como apache o snort-full, por citar dos ejemplos. Syslog se usa en los casos en los que se loguea un único evento por linea. Sort-full, por poner otro ejemplo, está adaptado al tipo de log que deja snort cuando usa el formato de salida full.

Una vez definidos los formatos, empezamos a hablar de reglas. El primer paso es que ossec detecte qué tipo de entrada de log es. Para esto se usan los decoders (decoder.xml) Veamos un ejemplo.

<decoder name="sshd">
<program_name>^sshd</program_name>
</decoder>

Este decoder “se activa” cuando la entrada de log es generada por el programa sshd (sshd[5493] en el siguiente ejemplo):

Feb  3 19:22:33 server sshd[5493]: Accepted publickey for prueba from 192.168.10.2 port 50560 ssh2

Pero, a pesar de la importancia de esta sencilla regla (después veremos por qué), necesitamos extender el decoder para que sea útil.

<decoder name="ssh-failed">
<parent>sshd</parent>
<prematch>^Failed \S+ </prematch>
  <regex offset="after_prematch">^for (\S+) from (\S+) port \d+ \w+$</regex>
  <order>user, srcip</order>
</decoder>

Gracias a la primera y simple regla “sshd” nos aseguramos que ossec sólo va a analizar la entrada de log contra esta segunda regla, mucho más compleja, si dicho log está relacionado con ssh. Esto es una gran mejora en el rendimiento del sistema.

Sin entrar en explicaciones detalladas, esta regla se cumple con este tipo de log:

Jul 26 22:06:10 server sshd[3727]: Failed password for prueba from 192.168.10.2 port 50519 ssh2

Y además crea dos “variables”; una con el usuario que ha intentado conectarse y otra con la IP origen.

Teniendo estos datos ya podemos empezar con las reglas “de verdad”. Veamos algo del fichero sshd_rules.xml

  <rule id="5700" level="0" noalert="1">
    <decoded_as>sshd</decoded_as>
    <description>SSHD messages grouped.</description>
  </rule>

<rule id="5716" level="5">
    <if_sid>5700</if_sid>
    <match>^Failed|^error: PAM: Authentication</match>
    <description>SSHD authentication failed.</description>
    <group>authentication_failed,</group>
  </rule>

De manera similar a los decoders, se define una primera regla básica para ssh, que ayudará a ossec en no tener que analizar reglas de apache (por ejmplo) en logs de ssh.

La segunda regla (5716) generará una alerta de nivel 5 cuando haya un intento de login erroneo.
Pero también se pueden crear reglas compuestas que activarán alertas de mayor nivel si hay x intentos fallidos desde una misma IP

  <rule id="5720" level="10" frequency="6">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip />
    <description>Multiple SSHD authentication failures.</description>
    <group>authentication_failures,</group>
  </rule>

Gracias al formato xml es muy sencillo añadir nuevas reglas. También se pueden enviar correos con las alertas a cuentas de correo diferentes en base, por ejemplo, al agente que ha generado la alerta o al nivel de la misma.

En el tercer y último post de la serie vamos a integrar ossec con psad.

foron seguridad ossec, seguridad

Antes de seguir con el segundo post sobre ossec, voy a dar un par de pistas sobre cómo ver el tráfico que pasa por una sesión tcp. Esto sí que es todo un mundo, así que me limito, como casi siempre, a dar cuatro detalles para que quien quiera se haga una idea de lo que se puede hacer y siga investigando.

Por supuesto, el que se pueda “espiar” lo que se está trasmitiendo no significa que debamos (ni podamos) hacerlo, al menos si no queremos tener problemas legales.

Vamos a empezar por lo básico. Necesitamos capturar tráfico para poderlo analizar después con cierta tranquilidad. Para esto usamos el conocido tcpdump, aunque podemos usar otros, como por ejemplo, snort.

tcpdump -n -i eth1 -s 1515 -U -w /tmp/captura.pcap '(tcp port 20) or (tcp port 21) or (tcp port 25)'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1515 bytes

Para saber lo que hacen los parámetros nada mejor que el manual

Dejamos esta terminal abierta y con el comando en ejecución. Vamos a ir analizando lo que se vuelca en captura.pcap en otra terminal.

Primera prueba.

Desde otra máquina vamos a hacer un telnet al puerto 25 y a mandar un correo.

telnet 192.168.10.1 25
Trying 192.168.10.1...
Connected to 192.168.10.1.
Escape character is '^]'.
220 smtp.example.com ESMTP Postfix
helo prueba.example.com
250 smtp.example.com
rset
250 2.0.0 Ok
helo prueba.example.com
250 smtp.example.com
mail from: prueba@example.com
250 2.1.0 Ok
rcpt to: prueba1@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: Titulo del correo
Este texto se ve en la captura
.
250 2.0.0 Ok: queued as 1F7426C420
quit
221 2.0.0 Bye
Connection closed by foreign host.

Nuestro volcado tiene datos…. vamos a ver que tiene usando tcpflow.

# tcpflow -r captura.pcap -c port 25
192.168.010.001.00025-192.168.010.002.41403: 220 smtp.example.com ESMTP Postfix
192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
192.168.010.002.41403-192.168.010.001.00025: rset
192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok
192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
192.168.010.002.41403-192.168.010.001.00025: mail from: prueba@example.com
192.168.010.001.00025-192.168.010.002.41403: 250 2.1.0 Ok
192.168.010.002.41403-192.168.010.001.00025: rcpt to: prueba1@example.com
192.168.010.001.00025-192.168.010.002.41403: 250 2.1.5 Ok
192.168.010.002.41403-192.168.010.001.00025: data
192.168.010.001.00025-192.168.010.002.41403: 354 End data with .
192.168.010.002.41403-192.168.010.001.00025: Subject: Titulo del correo
192.168.010.002.41403-192.168.010.001.00025: Este texto se ve en la captura
192.168.010.002.41403-192.168.010.001.00025: .
192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok: queued as 1F7426C420
192.168.010.002.41403-192.168.010.001.00025: quit
192.168.010.001.00025-192.168.010.002.41403: 221 2.0.0 Bye

Sorpresa, tcpflow ha generado, en esta caso por salida estándar (-c), todo lo que ha sido capturado en el puerto 25.

Segunda prueba.

Bien, vamos con algo un poco diferente, pero igual de fácil (recordad que esto no son más que ideas)

Ahora vamos a suponer que he programado un rootkit que se llama exploit, y que lo voy a subir por ftp a la máquina que estamos monitorizando.

ftp 192.168.10.1
Connected to 192.168.10.1.
220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
Name (192.168.10.1:prueba):
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put exploit
local: exploit remote: exploit
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 File receive OK.
101992 bytes sent in 0.00 secs (29433.1 kB/s)
ftp> quit
221 Goodbye.

Muy bien, ahora veamos lo que tenemos, empezando por el puerto 21, y después por el 20.

# tcpflow -r captura.pcap -c port 21
192.168.010.001.00021-192.168.010.002.50427: 220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
192.168.010.002.50427-192.168.010.001.00021: USER prueba
192.168.010.001.00021-192.168.010.002.50427: 331 Please specify the password.
192.168.010.002.50427-192.168.010.001.00021: PASS secreto
192.168.010.001.00021-192.168.010.002.50427: 230 Login successful.
192.168.010.002.50427-192.168.010.001.00021: SYST
192.168.010.001.00021-192.168.010.002.50427: 215 UNIX Type: L8
192.168.010.002.50427-192.168.010.001.00021: TYPE I
192.168.010.001.00021-192.168.010.002.50427: 200 Switching to Binary mode.
192.168.010.002.50427-192.168.010.001.00021: PORT 192,168,10,2,205,32
192.168.010.001.00021-192.168.010.002.50427: 200 PORT command successful. Consider using PASV.
192.168.010.002.50427-192.168.010.001.00021: STOR exploit
192.168.010.001.00021-192.168.010.002.50427: 150 Ok to send data.
192.168.010.001.00021-192.168.010.002.50427: 226 File receive OK.
192.168.010.002.50427-192.168.010.001.00021: QUIT
192.168.010.001.00021-192.168.010.002.50427: 221 Goodbye.

Vamos a hacer ahora que tcpflow genere un fichero con el tráfico del puerto 20. Para esto quitamos el parámetro -c.

# tcpflow -r captura.pcap  port 20
# file 192.168.010.002.52512-192.168.010.001.00020
192.168.010.002.52512-192.168.010.001.00020: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

Sorpresa, tenemos un fichero binario ….. con el exploit. Bueno, en realidad en una copia de /bin/ls, pero vale para el ejemplo

# strings 192.168.010.002.52512-192.168.010.001.00020

.......
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
  -b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
.......

¿Qué pasa en la realidad, cuando tenemos cientos o miles de sesiones de correo o ftp y queremos ver una concreta? Por un lado debemos guardar el tráfico que queremos investigar, claro, pero luego debemos saber qué sesiones se han establecido, a qué hora, cuánto tráfico ha pasado por ellas, entre que puertos, …. Para esto hay mucho software, pero un buen ejemplo es argus. A partir de aquí, podemos generar expresiones más elaboradas para usar en tcpflow (algo más que “port 20″)

foron seguridad seguridad, tcpdump, tcpflow

En el mundo del software libre hay multitud de proyectos que, debido a su calidad, han terminado siendo comprados por empresas para ser usados como parte de sus soluciones comerciales. Dos ejemplos son sguil y ossec.

En la próxima serie de dos posts voy a comentar muy por encima lo principal de ossec.

Ossec es un proyecto relacionado con la seguridad informática, y particularmente con lo que se suele llamar HIDS. Dicho de otra forma, y simplificando mucho, se trata de una aplicación que monitoriza una máquina, y que detecta las anomalías que puedan producirse en el sistema. Para hacer esto usa sobre todo una herramienta para la detección de rootkits, otra para revisar la integridad de ficheros y ejecutables del sistema, y por último un potente sistema para analizar logs.

En cuanto a la arquitectura del sistema, usa básicamente un modelo de servidor/agentes, con lo que tendremos una máquina (servidor) encargada de recibir y actuar en base a la información que reciba de los agentes que, en definitiva, son las máquinas que están siendo monitorizadas. La forma de actuar del servidor es, por una parte, enviando noficaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes.

Este primer post sólo va a describir la instalación de ossec. Dejamos para posts posteriores la configuración.

La instalación de ossec es muy sencilla. Es suficiente con ejecutar el típico install.sh del fichero de instalación que se puede descargar desde la web.

sh install.sh

Una vez seleccionamos el idioma de instalación empieza el tema.

1- What kind of installation do you want (server, agent, local or help)? server
  - Server installation chosen.
2- Setting up the installation environment.
  - Choose where to install the OSSEC HIDS [/var/ossec]:  /usr/local/ossec-1.6
     - Installation will be made at  /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
  3.1- Do you want e-mail notification? (y/n) [y]:
   - What's your e-mail address? zzz@yyyyyyy.net
   - We found your SMTP server as: mail.yyyyyyy.net.
   - Do you want to use it? (y/n) [y]:
   --- Using SMTP server:  mail.yyyyyyy.net.
  3.2- Do you want to run the integrity check daemon? (y/n) [y]:
   - Running syscheck (integrity check daemon).
  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
   - Running rootcheck (rootkit detection).
  3.4- Active response allows you to execute a specific
       command based on the events received. For example,
       you can block an IP address or disable access for
       a specific user.
       More information at:

http://www.ossec.net/en/manual.html#active-response

   - Do you want to enable active response? (y/n) [y]: n
     - Active response disabled.
  3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:
   - Remote syslog enabled.
  3.6- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/log/vsftpd.log
    -- /var/log/mail.info
    -- /var/log/dpkg.log
    -- /var/log/snort/alert (snort-full file)
    -- /var/log/apache2/error.log (apache log)
    -- /var/log/apache2/access.log (apache log)

   - If you want to monitor any other file, just change
     the ossec.conf and add a new localfile entry.
     Any questions about the configuration can be answered
     by visiting us online at http://www.ossec.net .

   --- Press ENTER to continue ---

A partir de aquí empieza a compilar los distintos componenetes. He elegido una instalación para el servidor que recibirá los eventos, y he activado tanto la detección de rootkits como la revisión de integridad, pero he dejado sin activar la respuesta activa, que básicamente se trata de añadir entradas a hosts.deny y reglas de firewall.

El syslog remoto lo vamos a usar para recibir mensajes desde los agentes.

Por cierto, mientras escribía estas líneas el sistema se ha terminado de compilar:

 - System is Debian (Ubuntu or derivative).
 - Init script modified to start OSSEC HIDS during boot.
 - Configuration finished properly.
 - To start OSSEC HIDS:
                /usr/local/ossec-1.6/bin/ossec-control start
 - To stop OSSEC HIDS:
                /usr/local/ossec-1.6/bin/ossec-control stop
 - The configuration can be viewed or modified at /usr/local/ossec-1.6/etc/ossec.conf
     Thanks for using the OSSEC HIDS.
     If you have any question, suggestion or if you find any bug,
     contact us at contact@ossec.net or using our public maillist at
     ossec-list@ossec.net
     ( http://www.ossec.net/main/support/ ).
     More information can be found at http://www.ossec.net
 ---  Press ENTER to finish (maybe more information below). ---

A partir de aquí, por un lado tendremos que configurar ossec (ossec.conf), y después tendremos que ir añadiendo los agentes con la utilidad /usr/local/ossec-1.6/bin/manage_agents.

Vamos a arrancar el servidor y a añadir un par de agentes, uno en linux y otro en windows. Bueno, el agente windows no lo voy a documentar aquí. Tiene un instalador gráfico que se descarga desde la web, y los pasos son muy similares.

/usr/local/ossec-1.6/bin/ossec-control start
Starting OSSEC HIDS v1.6 (by Third Brigade, Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

# ps aux | grep osse
ossecm    5579  0.0  0.0   2076   528 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild
ossec     5587  0.0  0.1   2664  1312 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-analysisd
root      5591  0.0  0.0   1796   468 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-logcollector
root      5603  2.5  0.0   1944   512 ?        D    17:45   0:04 /usr/local/ossec-1.6/bin/ossec-syscheckd
ossec     5607  0.0  0.0   1980   480 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-monitord
ossecm    5610  0.0  0.0   2076   300 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild

# ./manage_agents
***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your action: A,E,L,R or Q: A

- Adding a new agent (use '\q' to return to the main menu).
  Please provide the following:
    * A name for the new agent: agente1
    * The IP Address of the new agent: 172.17.0.131
    * An ID for the new agent[001]:
Agent information:
    ID:001
    Name:agente1
    IP Address:172.17.0.131
Confirm adding it?(y/n): y
Agent added.

# ./manage_agents

***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your action: A,E,L,R or Q: E

Available agents:
   ID: 001, Name: agente1, IP: 172.17.0.131
Provide the ID of the agent to extract the key (or '\q' to quit): 001
Agent key information for '001' is:
XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=

** Press ENTER to return to the main menu.

Y ya está. Ahora sólo queda instalar el agente en el servidor a monitorizar. La clave se usa para la comunicación agente/servidor.

# ./install.sh
...
1- What kind of installation do you want (server, agent, local or help)? agent
  - Agent(client) installation chosen.
2- Setting up the installation environment.
  - Choose where to install the OSSEC HIDS [/var/ossec]: /usr/local/ossec-1.6
    - Installation will be made at  /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
  3.1- What's the IP Address of the OSSEC HIDS server?: 172.17.0.1
    - Adding Server IP 172.17.0.1
  3.2- Do you want to run the integrity check daemon? (y/n) [y]:
    - Running syscheck (integrity check daemon).
  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
    - Running rootcheck (rootkit detection).
  3.4 - Do you want to enable active response? (y/n) [y]: n
    - Active response disabled.
  3.5- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/log/mail.info
    -- /var/log/dpkg.log
  - If you want to monitor any other file, just change
    the ossec.conf and add a new localfile entry.
    Any questions about the configuration can be answered
    by visiting us online at http://www.ossec.net .
--- Press ENTER to continue ---

Y ahora copiamos la clave pública que antes hemos sacado del servidor:

./bin/manage_agents

***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (I)mport key from the server (I).
   (Q)uit.
Choose your action: I or Q: I
* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.
Paste it here (or '\q' to quit): XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=
Agent information:
   ID:001
   Name:agente1
   IP Address:172.17.0.131
Confirm adding it?(y/n): y
Added.
** Press ENTER to return to the main menu.

Arrancamos el agente… y ya está.

/usr/local/ossec-1.6/bin/ossec-control start

Y no hay nada más que hacer para tener lo básico de ossec. Por supuesto, todo es muy configurable, y ampliable en base a lo que cada uno necesite.

Desde otra máquina, me intento conectar digamos que 10 veces usando ssh con usuarios invalidos….. sorpresa, recibo este correo.

OSSEC HIDS Notification.
2008 Sep 21 22:30:40

Received From: (agente1) 172.17.0.131->/var/log/auth.log
Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
Portion of the log(s):

Sep 21 19:06:32 fn131 sshd[5990]: Invalid user aaaaab from 172.17.0.2
Sep 21 19:06:26 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:23 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Failed none for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Invalid user aaaaa from 172.17.0.2
Sep 21 19:06:09 fn131 sshd[5984]: Failed password for invalid user aaaah from 172.17.0.2 port 39009 ssh2
Sep 21 19:06:06 fn131 sshd[5984]: Failed none for invalid user aaaah from 172.17.0.2 port 39009 ssh2

Algunos ejemplos con distintos tipos de eventos:

OSSEC HIDS Notification.
2008 Oct 09 21:29:03

Received From: servidor->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/etc/dovecot/dovecot.conf'
Size changed from '45438' to '45460'
Old md5sum was: 'bd5c81584dad9725045ec0e52eb0c15c'
New md5sum is : '439061951cdeb975c21d37b4cc5f8649'
Old sha1sum was: '8d7ade9a74b9e8ff4d6758c14bdb070ccb15b198'
New sha1sum is : '8e7d34ba6328a1e5d38645972b369e700f7d05b2'
 --END OF NOTIFICATION

OSSEC HIDS Notification.
2008 Oct 07 18:29:00

Received From: servidor->/var/log/dpkg.log
Rule: 2902 fired (level 7) -> "New dpkg (Debian Package) installed."
Portion of the log(s):

2008-10-07 18:29:00 status installed unzip 5.52-12
 --END OF NOTIFICATION

OSSEC HIDS Notification.
2008 Oct 05 17:42:23

Received From: agente1->/var/log/messages
Rule: 5104 fired (level 8 ) -> "Interface entered in promiscuous(sniffing) mode."
Portion of the log(s):

Oct  5 17:42:21 nurn kernel: device lo entered promiscuous mode
 --END OF NOTIFICATION

En el próximo post veremos un poco sobre la configuración de todas estas reglas.

foron seguridad ossec, seguridad

En el anterior post hemos visto lo más básico de psad. De hecho, he resumido alguna cosa tanto que los que ya conozcan el software pueden decir que no he sido todo lo riguroso que debiera. Un ejemplo, la parte relacionada con las variables IPT_AUTO_CHAINn. Mi objetivo, más que ser completamente riguroso, era dar una visión global del software.

En fin, dicho esto, vamos a ver alguna otra cosilla que se puede hacer con psad.

Recordemos el problema. Queremos poder añadir a nuestro firewall perimetral reglas que con el tiempo vayan expirando sin tener que estar encima. Queremos, además, que estas reglas se añadan en base a decisiones que tomen los servidores web o smtp en base a sus propios mecanismos, quitando al firewall perimetral la responsabilidad del análisis del tráfico del nivel de aplicación.

Hay varias formas de hacerlo. Lo más fácil es usar el propio comando psad. Por ejemplo:

# psad -fw-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will add the IP
    within 5 seconds.

Es tan sencillo como esto. Veamos el resultado:

# psad --fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords...

Chain PSAD_BLOCK (1 references)
 pkts bytes target     prot opt in     out     source               destination
     0     0 DROP       all  --  *      *       10.0.5.98            0.0.0.0/0

Para quitar esta IP es suficiente con esperar los 600 segundos configurados, o bien ejecutar:

# psad --fw-rm-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will remove the IP
    within 5 seconds.

# psad --fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords...

Chain PSAD_BLOCK (1 references)
 pkts bytes target     prot opt in     out     source               destination

A partir de aquí, seguro que a cada uno se le ocurren cinco formas de hacer que un servidor genere los comandos para que el firewall añada las reglas.

La forma en la que cada administrador gestiona lo que puede hacer con psad es particular de cada infraestructura, pero sin duda, una combinación de psad, fwsnort y otras técnicas como el port knocking añaden funcionalidades muy interesantes que en muchos casos ni siquera el software/hardware de pago ofrecen.

foron seguridad firewall, iptables, psad