Cuando un cerdo no es suficiente, monta una granja

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.

Comments

  1. http://Jose%20L.%20Villalon says

    A la pregunta “Averiguar por qué se ha enviado 4′3 GB de tráfico por una tarjeta que no tiene IP”, la respuesta es a priori sencilla (quizas no única), y es por que no todo el tráfico es IP; si revisas la configuracion de la interfaz, correcto, no tiene IP asignada, pero si tiene MAC, por lo tanto, responde a ARP, tráfico que aumenta el número de bytes enviados.
    La solución es facil de probar; si lanzas un arpping veras con un tcpdump que la interfaz envía datos y por lo tanto, aumenta el número de bytes transmitidos; para evitar esto, puedes poner -arp en la configuracion de la interfaz (nos aparecerá así en la configuración):

    eth0 Link encap:Ethernet Hwaddd xx:xx:xx:xx:xx:xx
    UP BROADCAST RUNNING NOARP 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

    Si ahora lanzas el arpping, te aparecerá el mensaje “Interface “eth0″ is not ARPable”, y veras que no aumenta el número de bytes transmitidos :D

    Por otra parte, habría que ver las estadisticas de la interfaz remota (el switch) para ver si descarta o no tráfico.

  2. http://wolfinside says

    Que tal amigos,

    Esto es lo que yo probaría, la verdad, no se si se adapta a las necesidades pero creo que sería un punto de vista a tener en cuenta, tampoco se si daría problemas a la hora de su implementación, como digo es conceptual.

    Si el problema radica en la capacidad de analisis de trafico de Snort y dado que la tarjeta de red esta correctamente, intentaria no pasar el tráfico a traves de snort que esta realizando cuello de botella, debido a la necesidad de captura de tráfico para su posterior analisis.

    Para ello se podría utilizar el proyecto fwsnort, que convierte las reglas snort a iptables, por lo que casi seguro no habría descarte de paquetes y podría manejar de igual forma la retención de logs y las funciones de ips.

    Otra opción que se me ocurre, y que la verdad no he probado pero veo interesante, es la de utilizar como sniffer netsniff-ng, que evita que la captura de paquetes se tenga que pasar desde el espacio del kernel a espacio de usuario, por lo que optimizamos el rendimiento. Este sniffer que pase a snort los datos capturados y este se encarge de su evaluación.

    Enhorabuena por vuestro trabajo.

    Un fuerte saludo

  3. Que no tiene IP entiendo que es porque el equipo ha sido configurado como bridge, y que envíe por la tarjeta de red 4’3GB puede ser debido a que la partición del NAS donde snort guarda los logs esté montada mediante samba o nfs?

  4. Respecto al tema del tráfico enviado, ciertamente hay más tráfico más allá de IP, lo que llamaba la atención es la cantidad: 4GB. Posteriormente, teniendo en cuenta todo el tráfico recibido, eso sólo representa el 0,02%, una cifra no tan escandalosa.

    Respecto a no tener IP, es una práctica común utilizar una interfaz de servicio (donde se conectará al port mirroring) sin IP y otra interfaz de gestión. Las conexiones a la NAS se realizan por la segunda, no debería enviar tráfico a la NAS por la primera.

  5. Hola,

    he revisado una serie de IDS en entornos y el envío es muy inferior al mostrado en la captura:

    RX bytes:3307563355 (3.0 GiB) TX bytes:222 (222.0 b)

    Lógicamente tienen activado el bit de no ARP:
    UP BROADCAST RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1

    Pero claro por lo que leo, no tenéis el modo promiscuo puesto, ¿entiendo entonces que está en modo bridge transparente en modo IPS?

    Joer que bueb post Nelo!

Trackbacks

  1. […] Cuando un cerdo no es suficiente, monta una granja (…) 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… […]