El fichero de configuración ‘~/.my.cnf‘ o ‘/etc/my.cnf‘ podemos personalizar diferentes opciones de MYSQL.

Cambiar el prompt

[mysql]
prompt=\n\u@\h [\d]\n>\_

También podemos exportar como variable de entorno en el fichero ‘.bashrc‘ de la siguiente forma:

export MYSQL_PS1="\n\u@\h [\d]\n> "

Variables genéricas:

• \S displays semicolon
• \’ displays single quote
• \” displays double quote
• \v displays server version
• \p displays port
• \\ displays backslash
• \n displays newline
• \t displays tab
• \ displays space (there is a space after \ )
• \d displays default database
• \h displays default host
• \_ displays space (there is a underscore after \ )
• \c displays a mysql statement counter. keeps increasing as you type commands.
• \u displays username
• \U displays username@hostname accountname

Variables relativas a fechas:

• \D displays full current date (as shown in the above example)
• \w displays 3 letter day of the week (e.g. Mon)
• \y displays the two digit year
• \Y displays the four digit year
• \o displays month in number
• \O displays 3 letter month (e.g. Jan)
• \R displays current time in 24 HR format
• \r displays current time in 12 hour format
• \m displays the minutes
• \s displays the seconds
• \P displays AM or PM

Símbolos y entidades HTML útiles a tener a mano como referencia

En esta entrada voy a ir colocando configuraciones útiles (muchas deberían venir por defecto) que van dentro del fichero ~/.inputrc o en el global /etc/inputrc.

búsqueda de comandos en el history

Con estas líneas conseguimos que una vez tecleado parte del comando al pulsar el cursor arriba vaya buscando en el history todo lo que empiece igual, muy útil para repetir un comando anterior o parte del mismo. Ver también el siguiente truco de búsqueda con CTRL+R

"\e[A": history-search-backward
"\e[B": history-search-forward
set show-all-if-ambiguous on
set completion-ignore-case on

búsqueda de comandos utilizados en el history (CTRL+R)

Con estas líneas podemos buscar de otra forma en el history un comando pulsando primero CTRL+R y después nos permite ir tecleando y mientras tecleamos va buscando comandos (en el history) que vayan coincidiendo, si volvemos a pulsar CTRL+R busca la anterior coincidencia y así repetidamente.

...

La variable de entorno IFS que significa Internal Field Separator (separador de campos internos), sirve para indicar que valor se usa como separador. Puede usarse para varios trucos de los cuales pongo a continuación los más interesantes:

Separador en un bucle con espacios

Si en un bucle con un for nos aparece uno o más espacios, no nos saldrá la salida como esperamos ya que el for interpreta el espacio como un separador con lo cual en vez de tener un listado como este (es un mero ejemplo):

linea1
linea2
linea 3
linea4

obtendremos un listado como este:

linea1
linea2
linea
3
linea4

que está claro no es lo que buscamos .

Para solucionar esto solo tenemos que añadir una simple línea delante del for para que no trate los espacios como separador y obtengamos el listado como queremos:

export IFS=$'\n'
for LINEA in $(find _directorio_ _que_buscar_ )
do
echo $LINEA
done

Dividir una linea por un carácter (tipo split)

Un caso muy útil para la variable IFS que uso con frecuencia es la división de una IP en variables, por ejemplo:

ip="1.2.3.4"

# dividimos la IP en 4 variables
IFS=. read ip1 ip2 ip3 ip4 <<< "$ip"

echo "$ip1 $ip2 $ip3 $ip4"

obtenemos 1 2 3 4

Cuando en OSX creas un evento en Calendario, dispones de la opción de marcar ese evento para que tu Mac te avise previamente. Sin embargo, cuando se trata de un evento para todo el día, no hay una forma sencilla de cambiar la hora del día en la que recibirás esa notificación.
Para esto podemos modificar directamente el fichero EventAllDayAlarms.icsalarm que lo podemos encontrar en la carpeta Library de tu usuario (~/Library/Calendars/) dentro de una carpeta (la más moderna) con números y letras que contiene la carpeta ServerDefaultAlarms, por lo que el path completo sería: ~/Library/Calendars/XXXX/ServerDefaultAlarms/EventAllDayAlarms.icsalarm.
En este fichero debemos editar la línea que contiene: TRIGGER:-PT15H, -PT15H indica que te va a avisar 15 horas antes del día del evento (00:00 – 15 horas). Si queremos que nos avise a las 10 de la mañana del mismo día podemos usar PT10H.

Entre los cambios visibles en Microsoft 8 son el menú Inicio, el Explorador de Windows “ribbon”, y el Administrador de tareas, todos los cuales han sido totalmente renovada por parte de Microsoft que para muchos es pésimo por lo que preferimos seguir en windows 7, pero a veces no es tan fácil pasarnos a windows 7 si hemos comprado un ordenador que ya viene con windows 8.
Este truco es para aquellos que no les gusta la nueva interfaz de Windows 8, que incluye, el menú Inicio, el Explorador de Windows “ribbon”, y el Administrador de tareas y prefieren la forma de windows 7.

1. Abrimos el cuadro de diálogo Ejecutar (teclas Win + R) y escribimos regedit y pulsamos Enter. Esto abrirá el Editor del Registro.
2. Ahora navegamos hasta HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer desde la barra lateral izquierda.
3. En la parte derecha, doble clic en RPEnabled, cambiamos el valor DWORD a 0, y clic en Aceptar.
4. Ahora reiniciamos el Explorador de Windows o salimos del sistema y entramos de nuevo para ver el cambio. El inicio de Windows 8 orbe, menú de inicio, el Explorador de Windows y el Administrador de tareas será reemplazado por el de Windows 7. El usuario no será capaz de distinguir si está usando Windows 7 o Windows 8.
5. Para volver de nuevo al estilo de windows 8, cambiamos RPEnabled en el Editor del Registro por el valor a 1.

En muchos de nuestros proyectos, sobre todo personales, necesitamos tener una web segura con SSL pero no queremos pagar un certificados porque no lo necesitamos, en tal caso lo que podemos hacer un crearnos un certificado auto-firmado, esto son lo pasos a seguir: Leer más »

• sed -e ’1!G;h;$!d’ fichero
  Muestra el contenido fichero en orden inverso (cat inverso), la última línea la primera y la primera la última.
• cat fichero | sed -n ‘/cadena/!q; p’
  Muestra las primeras líneas que contengan la cadena “cadena“, es como un HEAD pero con un patrón.
• cat fichero | sed -ne ‘s/.*\(que_extraer\).*/\1/p’
  • -n: suprime la salida por defecto
  • \(que_extraer\) = lo que queremos extraer, puede ser cualquier expresión regular. Lo que va entre \( y \) será sustituido por \1
  • p
• ls -R | grep “:$” | sed -e ‘s/:$//’ -e ‘s/[^-][^\/]*\//–/g’ -e ‘s/^/ /’ -e ‘s/-/|/’
  Muestra el directorio actual en formato de árbol (al estilo del comando tree).

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.

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

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 -> %sn", thread_indent(1), probefunc())
}
probe module("ext3").function("*").return
{
   printf("%s <- %sn", 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 %-15sn",
         "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 %-15sn",
           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 %30sn","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 %30sn", 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.

NOTA: artículo original en el Blog forondarena.net.

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.

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 notificaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes.

Este primer artículo sólo va a describir la instalación de ossec. Dejamos para artículos 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 componentes. 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

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 artículo 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 ejemplo) en logs de ssh.

La segunda regla (5716) generará una alerta de nivel 5 cuando haya un intento de login erróneo.

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.