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:

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.