No, no estamos hablando de dejar esta vida ajetreada de las ciudades e irnos al campo a vivir y alimentarnos de lo que cultivamos y criamos. Tampoco hablamos de “invertir” nuestro tiempo libre en juegos de una determinada red social para aprender las labores del campo. Este post viene a explicar el proceso que hemos seguido para optimizar el rendimiento de un sistema de detección de intrusos (IDS) en redes con una tasa de tráfico alta.

Hace tiempo se nos propuso preparar para un cliente un sistema de detección de intrusos de alto rendimiento, capaz de procesar una gran cantidad de tráfico totalmente heterogéneo. Así que preparamos una máquina con muy buenas prestaciones para asegurarnos que, por hardware, no iba a ser; a saber, un procesador de 6 cores con 4 GB de memoria RAM, tarjetas Gigabit Ethernet y un sistema NAS para albergar toda la información generada en una red que, suponíamos, iba a ser muy complicada de manejar por la cantidad, la variedad y la naturaleza de su tráfico.

Se optó por una de las soluciones más extendidas en los sistemas de detección de intrusos de código abierto: Snort.

El primer escenario que planteamos consistía en conectar la máquina directamente al firewall a un puerto donde se hacía Port Mirroring con Snort escuchando todo ese tráfico, enviando las alertas a una base de datos MySQL ubicada en la misma máquina, y utilizar BASE para gestionarlas. Pronto nos dimos cuenta de que una máquina con Snort procesando entre 600 y 800 Mbps de tráfico y enviando tal cantidad de alertas necesitaba un buen proceso de puesta a punto.

Antes de nada, lo primero que se definió fue cómo íbamos a evaluar que el sistema estuviera trabajando como se esperaba, así que se configuraron los preprocesadores encargados de generar información sobre el rendimiento: Preprocessor Profiling para ver estadísticas de uso y tiempo de preprocesadores y Rule Profiling para las reglas. A continuación se puede ver las líneas de configuración:

## PROFILE#
Preprocesadores
config profile_preprocs: print all, sort avg_ticks,
filename /opt/snort/preprocs_20-avg_stats.log append
#Reglas
config profile_rules: print all, sort matches,
filename /opt/snort/rules_20-avg_stats.log append

Con el módulo Perfmon descubrimos que se estaban descartando entre el 50 y el 70 por cierto de los paquetes que pasaban por la red. Una cifra un tanto desoladora. ¿Qué estaba ocurriendo? ¿Dónde estaba el problema de rendimiento? Hacía falta averiguar por qué se descartaban tantos paquetes y dónde (en qué punto) teníamos el cuello de botella. Empezamos por investigar en la interfaz física o el kernel.

eth0
Link encap:Ethernet Hwaddd xx:xx:xx:xx:xx:xx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25212974798 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19297324454191 (19.2 TB) TX bytes:4303988140 (4.3 GB)
Interrupt:40 Memory:f2000000-f2012800


Con un simple ifconfig, cuyo resultado se muestra en la captura anterior, se pueden apreciar dos cosas: que efectivamente el kernel no está descartando paquetes (ya que el campo dropped de la tarjeta estaba a cero) y que la cantidad de tráfico que se procesa es realmente elevado (queda para más adelante del estudio, averiguar por qué se ha enviado 4′3 GB de tráfico por una tarjeta que no tiene IP).

Cabe destacar que toda la información generada por Snort se envía a una partición ubicada en la NAS para que, en caso de haber un fallo en el IDS, no se perdiera toda esa información que posteriormente pueda servir para investigar ataques o preparar estadísticas. Descartado como origen del problema la tarjeta de red y viendo que la CPU estaba constantemente al 100%, supusimos que el problema era que Snort no era capaz de procesar tanto tráfico. Así que decidimos tomar medidas.

En resumen: Snort no era capaz de absorber y analizar tal cantidad de tráfico a pesar de estar la CPU (sólo una) al 100%, llegando a descartar entre el 50 y el 70 por ciento del tráfico; el cuello de botella no se encontraba en la tarjeta ya que no perdía paquetes y a su vez se estaban generando del orden de cuatro millones de alertas al día.

Hasta aquí, la primera parte de este artículo. Se insta al lector a proponer ideas o cuestiones que conduzcan a la identificación real del problema (o ayuden a ello) o a la resolución del mismo. En el siguiente artículo veremos qué acciones se tomaron al respecto y cuáles fueron los resultados.

Por Nero Belda en http://www.securityartwork.es/2010/10/20/cuando-un-cerdo-no-es-suficiente-monta-una-granja/?utm_source=feedburner&utm_medium=feed&utm_campaig n=Feed%3A+SecurityArtWork+%28Security+Art+Work%29