Network Tap en NIDS

Uno de los problemas que surgen a la hora de implantar las sondas para la detección de intrusos a nivel de red (NIDS) es el lugar de conexión de ésta. Normalmente se suele conectar en las interfaces span o puerto espejo del Switch (conmutador) de la red donde queremos detectar las alertas, incluso para aquellas soluciones donde se dispone de un presupuesto reducido se emplean Hub (concentrador).

Pero dichas soluciones presentan un problema de perdidas de paquetes. En caso de un Hub es debido a las colisiones que se genera en el tráfico, donde en una red 10/100 la interfaz del NIDS puede llegar a tratar un máximo de 40 mbits/segundo. En caso de los Switch el problema surge con el coste computacional adicional de tener que procesar y replicar los paquetes de una o varias interfaces sobre la interfaz espejo, así como, no ser capaces de inyectar en una única interfaz el tráfico total que circula por las interfaces replicadas.

Es por ello que en el puerto espejo de un Switch 10/100 un NIDS es capaz de analizar un máximo de 60 a 80 mbits/segundo, mientras que en una red a giga el máximo estará entre 400 y 600 mbits/segundo.

Para solucionar estos problemas en entornos de carga elevada y críticos con full duplex se emplean Copper Test Access Ports o Taps, permitiendo obtener el tráfico que circula por un cable y replicarlo a a la interfaz del NIDS sin que el tráfico se vea afectado. 

¿Como hacer esto? imaginemos que se desea leer el tráfico que va entre dos dispositivos de red al que llamaremos A y B. Esos dispositivos de red se conectan por un cable (Cobre/RJ45 o Fibra). En la interfaz A tendremos la señal de recepción RX la cual se conecta al de transmisión TX de B, y así mismo, la interfaz de B tendrá el RX conectado a la TX de A. El TAP  se sitúa en medio de los dos cables, teniendo dos bocas donde en una se conecta A y en la otra a B como si se tratara de una prolongación del cable. A su vez coge la señal TX de A y de B y las lleva a dos bocas adicionales.  Veámoslo en un diagrama sencillo:

Es importante comprender que no se puede conectar el TX de A y el TX de B en la misma interfaz del NIDS, puesto que la interfaz encargada de leer el tráfico (la sonda del NIDS) solo puede leer por su RX y no leer tráfico por su TX, ya que es de transmisión y no de recepción (gracias Jose Luis :P). 

Existen diagramas sencillos para crearnos nuestro propio Tap 10/100 (pieza indispensable de un análisis forenses), a un precio más que asequible empleando únicamente cuatro anclajes para RJ45 y un cable RJ45. Claro este en entornos críticos a giga los tap no son tan sencillos y son realmente caros, del entorno de 2000 a 5000 euros.

Como se habrán dado cuenta el tráfico capturado por el Tap se encuentra dividio en las dos interfaces (TXA y TXB) donde una dirección del tráfico está en una interfaz y el de otra dirección en la otra. Por tanto es necesario juntar el tráfico de esas dos interfaces para poder leerlo como si lo estuviéramos haciendo directamente sobre el cable. Para ello se emplean Switch que permiten "unir" el tráfico de ambas interfaces en una única interfaz. Se puede pensar que es lo mismo que poner un Switch directamente sin el Tap como se comento al principio, pero no, por que en este caso el Switch solo tiene que replicar el tráfico en una única interfaz, así mismo, dicho proceso no influye en el funcionamiento del Switch de producción.

El problema de está solución es que en la tarjeta span puede recibir la mitad del tráfico máximo que puede circular en ambas interfaces, por ejemplo si el TX de A es a Giga y el TX de B es a Giga, si tengo que inyectar ese tráfico en una tarjeta a Giga en el peor de los casos podría llegar a perder la mitad del tráfico: TXA + TXB en TXSpan.

Para ello existe dos soluciones. La primera y más económica, pero nos obliga a emplear NIDS por software, es por software empleando para ello un servidor con dos interfaces que soporten el mismo tráfico, o más, que las interfaces TXA y TXB del Tap. El servidor deberá usar el sistema operativo linux y emplear bonding, mediante el comando ifenslave que permite agregar el tráfico de ambas interfaces en una. Si por ejemplo tenemos un tráfico a giga necesitaríamos un Tap que sea a Giga, un servidor con al menos 2 interfaces a giga y una tercera de gestión, donde conectaremos cada interfaz del Tap (TXA y TXB) a cada una de las interfaces giga del servidor y una vez conectado activaremos el Bonding. Si por ejemplo las interfaces a giga son Eth0 y Eth1 los comandos a ejecutar serán los siguientes:

# ifconfig bond0 promisc up
# ifconfig eth0 promisc up
# ifconfig eth1 promisc up
# ifenslave bond0 eth0
# ifenslave bond0 eth1

De esta forma podemos invertir en un servidor potente con fuente redundante que se encargue de la agregación por bonding y a su vez, del análisis de tráfico al instalar  alguna herramienta de detección de intrusos a nivel de red por software como puede ser Suricata o Snort, que hará la función de la sonda de detección de intrusos al leer el tráfico de la interfaz bond0.

Tal como hemos comentado, existe una segunda alternativa al bonding, mucho más cara y algo mejor, que es emplear el balanceador de tráfico de Top Layer, la cual se puede emplear con sondas por hardware como por software. Este dispositivo funciona conectando las dos interfaces del Tap al dispositivo y éste se encarga de balancear el tráfico de red a diferentes interfaces  manteniendo la sesión de la comunicación y siendo capaz de transmitir a las interfaces de red casi/la totalidad del tráfico que circule por la red (¡sin perdidas!). A su vez es capaz de asignar interfaces dedicadas a cierto tráfico como es el HTTP o SMTP permitiendo asegurar que no se producen perdidas en protocolos críticos. El funcionamiento sería el siguiente:
 

 

Por tanto, la solución para entornos de carga elevada sería emplear un Tap a giga o fibra, a poder ser de doble fuente redundante, y hacer la agregación por bonding empleando un NIDS por software como Snort o Suricata. Lógicamente usar el balanceador sería lo ideal, pero el precio se dispara, ya que, debemos tener en cuenta que el precio del Tap a Giga, del servidor para bonding + sonda tiene un precio aproximado ente 4000 y 7000 euros. 

Nos vemos en la próxima entrada.