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

Terminamos con éste la serie de artículos sobre la implantación de un IDS en un entorno con una alta tasa de tráfico, donde veremos las soluciones que se han tomado para el problema de los paquetes descartados y la escritura en base de datos.

Según dejamos el tema en el artículo anterior, el problema parece residir en que Snort, hasta que no termina de escribir la alerta en la base de datos, no procesa el siguiente paquete. La escritura en base de datos se realiza mediante una conexión TCP que precisa del handshake y de la escritura del INSERT en la misma; es por esto que constituye un proceso muy lento. Para solucionarlo, vamos a tomar cuatro pequeñas medidas que reducirán considerablemente el tiempo que necesita Snort en generar una alerta:

Escritura en disco local de la alerta y uso del formato unified2. La escritura en local es mucho más rápida que la escritura en red y si utilizamos un formato binario que ocupa muy poco espacio, se tardará mucho menos tiempo en generar la alerta. El formato binario unified2 es una evolución del formato unified introducido en Snort v.2.8. Se trata de un formato extensible formado por una cabecera que define el tipo de registro y su longitud, y que permite guardar en un mismo fichero diversos tipos de eventos como, por ejemplo, alertas IPv6, estadísticas o información de escaneos.

Para configurar esta salida se debe configurar la siguiente línea en el fichero snort.conf:

output unified2: filename snort.log, limit 256

(NOTA: En la versión 2.8.6 las salidas alert_unified2 y log_unified2 no funcionan correctamente, por lo que se debe almacenar todo en un mismo fichero. Se dice que este error ha sido resuelto en la versión 2.9.)

La estructura es similar a la siguiente:

Este formato binario permite una escritura más rápida en disco al tener un tamaño más definido y un espacio menor, pero ahora necesitamos “alguien” que entienda este formato e inserte las alertas en la base de datos. Es entonces cuando entra en juego Barnyard2 como tercer paso de la solución. Según indican en el propio proyecto, Barnyard2 cuenta con las siguientes características:

• Extrae el proceso de salida de Snort a un proceso dedicado, minimizando el descarte de paquetes en Snort.
• Trabaja con archivos unified2.
• Soporta todos los plugins de salida de Snort (excepto alert_sf_socket) así como Sguil y CEF.

Al realizar una escritura diferida, Snort termina antes de procesar y puede empezar a procesar el siguiente paquete, añadiendo más robustez en caso de que la base de datos tenga mucha carga y no pueda procesar las entradas en ese instante, mientras que Barnyard2 va a su ritmo insertando alertas.

Este era el último punto. Cuando se producían drops en Snort en el momento de consultar a la base de datos, era un indicativo de la estrecha dependencia que tenían el uno de la otra. Utilizando Barnyard2 y llevando la base de datos a otra máquina se consigue romper esa dependencia y las consultas no interfieren en el análisis de los paquetes. Recordar que la configuración del output que tenía cada Snort debe comentarse y copiarse en cada Barnyard para que se siga conservando la consistencia de cada “sensor”.

Por último, agradecer a mis compañeros que descubrieron una opción en Snort que permitía un algoritmo más rápido llamado ac-bnfa (configurando la opción “config detection: search-method ac-split, search optimize” en el fichero de configuración).

Finalmente, mostramos un esquema de cómo quedó el sistema después de todos los cambios necesario:

Después de todo esto, quedó un largo proceso de afinamiento de la configuración de preprocesadores, reglas repetidas, configuración de thresholds para minimizar las alertas, que quedan fuera de este artículo y darían para muchos otros más, pero lo dejamos aquí: con nuestra granja de cerdos con sus cuatro cercas (en inglés, barnyard) para que no se nos escapen.

En resumen, empezamos el artículo perdiendo el 70% de los paquetes y en la actualidad tenemos picos del 10% de manera puntual. No es perfecto, pero se considera un valor aceptable teniendo en cuenta el tráfico y la gran cantidad de alertas que se generan. En la versión 2.9 de Snort se incluye una nueva librería de acceso a la tarjeta de red que permite leer directamente del espacio de kernel, en lugar de copiar los paquetes al espacio de usuario, lo que reduce el número de copias y el tiempo de lectura. Probaremos la librería Data AcQuisition (DAQ) e informaremos si vemos mejoras frente al uso de Libpcap.