Snort: Extracción avanzada de información en preprocesadores HTTP y SMTP (II)

En mi anterior post os comentaba unas mejoras que se habían introducido en las últimas versiones de Snort, y que si recordáis nos servían para obtener más información detallada acerca de las comunicaciones HTTP y SMTP, como pueden ser: dirección real detrás de los proxys, host y URI contactados, así como direcciones de origen y destino de correos electrónicos, o cabeceras SMTP entre otros.

Al final de la entrada nos quedamos con Snort configurado, pero sin poder extraer esta información tan importante ya que actualmente no se dispone de ninguna aplicación oficial o parche que utilice estas nuevas extensiones del formato Unified2. Por suerte, un usuario de Barnyard2 publicó en la lista de correo de desarrollo de Barnyard2 un parche con el que conseguir guardar esta información en una base de datos de tipo MySQL. Cabe destacar que el parche no es oficial, y ni el usuario que lo creó ni nosotros nos responsabilizamos de los problemas que su uso pueda ocasionar.

Este usuario realizó un parche para la versión 1.9 de Barnyard2 y otro para una snapshot del SVN de la versión en desarrollo. Por comodidad, vamos a utilizar el parche para la versión 1.9. Para instalarlo es necesario descargar Barnyard2, y ejecutar el parche desde la propia carpeta de Barnyard2 con la orden:

patch -p1 < barnyard2-1.9-extra-out.diff

Tras esto, se debe compilar Barnyard2 de la forma habitual, y ejecutar el script de creación del esquema de la base de datos MySQL (cuidado con no borrar bases de datos con información, ya que el script modificado elimina las tablas para crearlas de nuevo) para que ésta pueda albergar la información de las cabeceras extras.

El último paso consiste en modificar Barnyard2 para que, dentro del plugin de MySQL, utilice la “facility” alert-extra. De esta forma conseguimos guardar finalmente estos campos en la base de datos. La línea de configuración quedaría del siguiente modo:

output database: alert-extra, mysql, dbname=snort host=localhost user=snort 
         password=snort sensor_name=snort

Como detalle cabe comentar que durante el proceso de pruebas y gracias al usuario que creó el parche que hemos utilizado, dimos con una diferencia entre la forma en que Snort trata su salida estándar, y la forma en que lo hace Barnyard. En Snort, la “facility” alert guarda únicamente la información más relevante y la “facility” log guarda información extensiva acerca de las alertas generadas, mientras que Barnyard2 trata las “facility” en el modo inverso, enviando a alert información extensiva sobre las alertas generadas y a log únicamente una parte de la información.

Para aquellos más curiosos, el cambio principal que se realiza a la base de datos es la creación de una nueva tabla, llamada extra, que contiene los campos presentes en las cabeceras extra que hemos visto anteriormente. Los campos más relevantes son:

• sid y cid identifican la alerta asociada del mismo modo que en el resto de tablas.
• type indica el tipo de información que contiene la fila actual, según la clasificación mostrada en el post anterior.
• data muestra el campo finalmente obtenido.

A continuación se puede ver un extracto de esta tabla:

A partir de aquí podemos empezar a utilizar estos nuevos datos para obtener informes que nos resulten interesantes.

Por mostrar dos ejemplos, con la siguiente consulta se pueden obtener todas las alertas que disponen de cabeceras extra, mostrándolas:

select e.sid, e.cid, s.sig_name, e.timestamp, x.type, x.data from event e inner join 
      signature s on e.signature=s.sig_id inner join extra x on e.cid=x.cid and 
      e.sid=x.sid; 

La siguiente consulta nos muestra las firmas que están generando cabeceras extra:

select s.sig_name from event e inner join signature s on e.signature=s.sig_id inner join 
     extra x on e.cid=x.cid and e.sid=x.sid group by s.sig_name;

Por nuestra parte, vamos a utilizar esta información extra para tratar de descubrir los equipos detrás de proxys que tienen comportamiento anómalo (P2P, Malware, Spyware, etcétera), pero con el tiempo queremos ampliar su uso para conocer, por ejemplo:

• Qué nombres de equipo están comprometidos y sirviendo malware.
• A qué nombres de equipo se conectan los malware que tenemos en nuestra organización.
• Quienes son los usuarios que envian correos con contenido malicioso.
• Quienes son los usuarios que reciben correos con contenido malicioso.

¿Se os ocurren más usos de esta información? Si es así, escribidlo en los comentarios.