Cuando un cerdo no es suficiente, monta una granja (II)

Después de una semana para dejar pensar a nuestros lectores, seguimos con el artículo sobre la implantación de un sistema IDS en un entorno con una tasa de tráfico muy elevada.

Nos habíamos quedado en un momento donde la tasa de tráfico era tan elevada que, aunque la tarjeta no estaba perdiendo tráfico, Snort no era capaz de procesar todos los paquetes. Teniendo en cuenta la carga de CPU en el sistema, y revisando la documentación de Snort donde se indica que esta aplicación no es multi-hilo, no quedaba otra opción que montar la granja; es decir, levantar varias instancias de Snort y repartir el tráfico para que cada una de ellas analizara una tasa menor. Suponíamos que íbamos a conseguir un buen resultado ya que sólo se estaba utilizando un único core al 100% mientras que el resto no se utilizaba.

Para conseguir esto se deben tener en cuenta varios aspectos para que no entren en conflicto diferentes instancias en un mismo sistema. En resumen, se deben crear filtros BPF para especificar el tráfico que procesará cada instancia, puede haber uno o varios archivos de configuración, debe especificarse un sufijo diferente para el pidfile de cada instancia, debe especificarse un identificador (id) en cada instancia a la hora de escribir en la base de datos y un directorio diferente para almacenar los logs.

Vayamos por partes. El BPF (Berkeley Packet Filter) proporciona una interfaz de comunicación directa en la capa de enlace de datos mediante los cuales además se puede definir cuáles, de todos los paquetes que llegan a la interfaz, queremos procesar, reduciendo así los requisitos de CPU, el espacio del buffer necesario y la pérdida de paquetes. Se utiliza la misma nomenclatura que en otros filtros utilizados, como el conocido tcpdump. Mostramos una línea de ejemplo:

net 192.168.2.0/24 or net 172.16.0.0/16

Por tanto, se crearon cuatro archivos BPF con su configuración correspondiente pasándose como parámetro a Snort con la opción “-F bpf_file”. Tres de ellos contemplaban una parte de todo el rango a monitorizar mientras que el cuarto era la negación de la suma de los otros. Con esto conseguimos segregar el tráfico en segmentos de red con tasas similares para que fuera más manejable.

Para el resto de la configuración, el directorio donde se almacenarán los logs de cada instancia se debe especificar con la opción -l diferente para cada instancia; para especificar un identificador se usa la opción -G (SONDA1, SONDA2, SONDA3 y SONDA4, sin espacios). Para el pidfile se utiliza -R “sufijo”. Una idea conceptual de cómo está montado hasta el momento es la siguiente:

snort

Cuando se pusieron los cuatro Snort a trabajar, se consiguió una reducción significativa de la cantidad de tráfico descartado que se podía apreciar mediante las estadísticas creadas por el preprocesador PerfMon (apunte matemático: el porcentaje total de pérdidas no es igual a la suma de los porcentajes individuales, se debe ponderar por el tráfico procesado por cada Snort). A modo ilustrativo, indicar que si las pérdidas (drops) rondaban el 30%, 10%, 15% y del 20%, el total no era el 75% sino de un 20%, aproximadamente.

Bien, tenemos un 20% de paquetes descartados cuando al principio teníamos un 50-70% y se están utilizando cuatro cores entre el 80-100% en los momentos de mayor tráfico. Un gran avance, pero no era suficiente. Uno de cada cinco paquetes no se procesaba y eso seguía siendo inasumible pero, ¿por qué seguían produciéndose descartes? Daremos una pista: cuando se interactuaba con la base de datos mediante BASE, los descartes aumentaban.

Y con esta incógnita, cerramos la semana de Security Art Work hasta el martes que viene, al ser el próximo día 1 de noviembre festivo. Pasen un buen fin de semana, y tengan cuidado en la carretera, si tienen pensado viajar.

Comments

  1. http://Sergio. says

    Muy interesante. Gracias. Entonces, en una misma máquina / CPU si ejecutaron 4 instancias diferentes de Snort a la vez, cada uno con su snort.conf diferente, etc, a parte del filtro ?.

    Saludos.

  2. Muy buena Nelo, me está gustando mucho la entrada. Ya me imagino por donde irán los apuntes de la proxima entrada, esto ocurre también con los syslog centralizados que tiran contra BBDD :(.

  3. Efectivamente, Sergio.
    En una CPU con seis cores tenemos cuatro instancias de snort por lo que se aprovecha mejor la capacidad de la máquina, pero se podría añadir alguna más. Respecto al tema de los ficheros de configuración, tenemos sólo dos por las características de la red: en el que varía la configuración de determinados preprocesadores (uso de memoria) pero se puede tener un fichero por cada snort.

    Ximo, la escritura en base de datos es lenta si la comparamos con la escritura en local cuando hablamos muchas entradas por segundo. En breve veremos la solución, pero va por el mismo camino.

  4. Gracias nbelda. Después de algunas pruebecillas veo que las opciones -R y -G no parecen totalmente necesarias.

  5. Sergio, la opción -R es para identificar más fácilmente el PIDFILE de cada instancia a la hora de reiniciarlo, sino puede que haya colisión o no te deje arrancarlo, dependiendo del método que utilices. La opción -G sí es más necesaria ya que distinguirá entre varios “sensores” en la base de datos.

    En un entorno tan activo como el del artículo donde se escriben varias alertas por segundo, aparecían errores de duplicados en la base de datos. También es recomendable para identificar alertas de cada sensor.

    Un saludo.

Trackbacks

  1. […] Cuando un cerdo no es suficiente, monta una granja (II) (…) Teniendo en cuenta la carga de CPU en el sistema, y revisando la documentación de Snort donde se indica que esta aplicación no es multi-hilo, no quedaba otra opción que montar la granja; es decir, levantar varias instancias de Snort y repartir el tráfico para que cada una de ellas analizara una tasa menor… […]

  2. […] Hay muchas formas de mejorar el rendimiento de captura en IDS como Snort, por ejemplo y estre otros métodos, la escritura correcta y optimizada de reglas o el uso de barnyard2 y el formato unified2. También podemos usar archivos de filtros BPF para segmentar el tráfico o establecer que paquetes queremos que Snort procese. […]