La alternativa. TAP significa `Test Access Port' (Puerto de Acceso de Pruebas). Los Network Taps (dispositivos de escucha de red) son dispositivos que permiten examinar el tráfico de red sin intervenir en el flujo de datos. Trabajan a nivel 1 de OSI, por lo que no realizan ninguna función de redirección o encaminamiento del tráfico.
Obviamente, los Network Taps son una solución más costosa que los cables UTP de sólo recepción, pero cuentan con muchas más ventajas. Por ejemplo, son más robustos y profesionales, suelen tener búfers para evitar pérdidas de datos, regeneran la señal, pueden monitorizar comunicaciones de fibra óptica, etc.
Hay varias compañías que desarrollan estos productos. Net Optics, Inc. [4], Shomiti Systems [5], Network Critical [6], Finisar [7], Intrusion Inc. [8], Datacom Systems Inc. [9], Comcraft [10] son algunas de ellas.
Es interesante mencionar que todos los fabricantes de Taps afirman que sus productos son seguros ante fallos (el enlace no se interrumpe con pérdidas de tensión). Esto es sólo parcialmente cierto, ya que existe un período de intercambio de entre 5 y 10 ms (una probabilidad de pérdida de 0 ó 1 paquetes). En la mayoría de los entornos esto puede ser aceptable, pero en una red de alta disponibilidad puede provocar efectos importantes como la renegociación de los enlaces entre routers y switches (VPN, Spanning tree, etc.) Al parecer, los 4x4 Taps son los únicos que ofrecen `cero' pérdidas de paquetes ante fallos de alimentación. Securicore [11] es una de las compañías que distribuye estos Taps, desarrollados por Network Critical.
Net Optics [4] ofrece Network Taps PCI para la monitorización full-duplex de redes 10/100 Mbps a través de una única interfaz de red (NIC).
El diagrama 11 describe dos formas de representar el esquema de conexiones de un Tap.
Un Tap captura el tráfico en ambos sentidos y lo envía a un dispositivo de monitorización, como un IDS o un generador de estadísticas de tráfico. Como se puede observar en la figura 11, se obtiene una línea de datos por cada sentido del tráfico. Por lo tanto, si aplicamos este esquema de conexiones a cables UTP, que son los que normalmente se utilizan en redes Ethernet, podemos deducir fácilmente los esquemas de la figura 12.
Construir un Tap de estas características es trivial. De hecho, ya existen instrucciones que indican cómo hacerlo, con un cable directo [12]. Esta solución requiere dos interfaces de red para analizar el tráfico (cada una recibe un sentido de la comunicación). Tenga presente que la potencia de la señal de un segmento de red no está preparada para ser compartida por más de dos interfaces de red (origen y destino). Por lo tanto, este diseño puede provocar pérdidas de señal (y de datos).
Otras soluciones para analizar el tráfico con Taps se comentan más adelante en el apartado 4.3 `Ejemplos de Implementación'.
Los Taps de adaptación (`Adaptive taps') están diseñados para hacer conversiones de señales, además de capturar tráfico. Por ejemplo, existen Taps que convierten señales de Gibabit-TX a Gibabit-SX, o de Gigabit-LX a Gigabit-SX.
La idea de los Taps de regeneración (`Regeneration Taps'), de Net Optics [4], consiste en generar múltiples flujos de tráficos de red a partir de un único punto de acceso. Actúan como varios Taps combinados en un sólo dispositivo, ahorrando en costes y espacio.
Los Taps de regeneración pueden ser utilizados en casos donde es necesario analizar tráfico de más de una forma y con diferentes máquinas. Por ejemplo, se podría llevar a cabo detección de intrusiones y análisis de protocolo. La figura 13 ilustra este concepto.
Otra forma de implementar un Tap de regeneración es utilizando dos o más Taps y disponerlos en una daisy-chain (cadena de margarita). El 4x4 Critical Tap en la figura 14 combina cuatro Taps individuales, y puede ser utilizado de esta forma. Aunque es posible hacer esto tanto con Taps de fibra o cobre, los Taps de fibra necesitan más cuidados con la pérdida de señal y deben ser ordenados según la relación de separación (split ratio) adecuada para preservar la integridad del flujo de datos.
Como vimos en la figura 11, cada sentido del tráfico es una señal de datos que hay que analizar. Por lo tanto, para poder monitorizar el tráfico de red es necesario tener dos interfaces de red. La novedad de estos Taps (`Aggregation Taps') ente otras características, es que reunen ambas señales de datos en una sola, permitiendo el análisis mediante una única interfaz de red. El AggregationTAP de Network Critical [11] permite además, de forma excepcional, inyectar paquetes TCP RESET en la red, eliminando aquellas conexiones que pueden ser hostiles. Esta característica lo hace especialmente útil en escenarios con NIDSs con capacidades de respuesta activa, o NIPSs (Sistemas de Prevención de Intrusiones).
Los puertos de un Tap y los puertos span de un conmutador se utilizan para monitorizar tráfico de red, pero hay diferencias importantes entre ambas tecnologías [14]:
Por otra parte, un puerto span de un conmutador no ve todo el tráfico. Los paquetes de red dañados, paquetes de tamaño por debajo del mínimo, y errores de nivel 1 y 2 son normalmente descartados por el conmutador.
Por el contrario, la arquitectura software de algunos conmutadores de bajo nivel introducen retrasos al copiar los paquetes para los puertos span. Peor aún, en muchos casos la información se envía a través de un puerto gigabit, introduciendo retrasos al convertir la señar de eléctrica a óptica.
Además, el acceso al tráfico del conmutador está limitado por la capacidad del puerto span. Si el tráfico es excesivo, dicho puerto descartará paquetes, por lo que se perderá información. Por ejemplo, para poder ver el tráfico full-duplex de un enlace de 100 Mbps, el puerto span debe tener una capacidad de hasta 200 Mbps.
Por el contrario, los puertos span consumen recursos del conmutador, disminuyendo su rendimiento.
La figura 15 representa una forma de analizar tráfico, utilizando un sensor con dos interfaces de red, una para cada sentido del tráfico. Además de las interfaces, es necesario instalar algún tipo de software que permita combinar los datos de ambas interfaces físicas en una única intefaz lógica. Se puede utilizar por ejemplo el software Sun Trunking [13], o el controlador de red de Linux bonding. En este último caso primero hay que compilar el controlador como módulo, y luego combinar las interfaces de red físicas en una interfaz lógica (bond0). Por ejemplo, si deseamos vincular las interfaces físicas eth1 y eth2 a la interfaz lógica bond0 con dirección IP 192.168.0.254/24:
[root@tap root]# modprobe bonding
[root@tap root]# ip addr add 192.168.0.254/24 brd + dev bond0
[root@tap root]# ifconfig eth1 promisc -arp up
[root@tap root]# ifconfig eth2 promisc -arp up
[root@tap root]# ifconfig bond0 promisc -arp up
[root@tap root]# ifenslave bond0 eth1
master has no hw address assigned; getting one from slave!
The interface eth1 is up, shutting it down it to enslave it.
[root@tap root]# ifenslave bond0 eth2
The interface eth2 is up, shutting it down it to enslave it.
[root@tap root]# ifconfig
bond0 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC MASTER MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:888 (888.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr XX:XX:XX:77:02:13
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:151 errors:0 dropped:0 overruns:0 frame:0
TX packets:113 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:69180 (67.5 Kb) TX bytes:17418 (17.0 Kb)
Interrupt:11 Base address:0x3400
eth1 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:444 (444.0 b) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0xd800
eth2 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:444 (444.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18863 errors:0 dropped:0 overruns:0 frame:0
TX packets:18863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1287600 (1.2 Mb) TX bytes:1287600 (1.2 Mb)
No hace falta decir que el soporte ARP está deshabilitado debido a que no es necesario en un dispositivo de sólo recepción. Como bond0 es una interfaz lógica, puede ser utilizada por tcpdump. La interfaz eth0 puede ser utilizada para controlar remotamente el sniffer, o para enviar alertas a una consola central. Se puede leer más información sobre bonding en el fichero Documentation/networking/bonding.txt del código fuente de Linux.
Por otra parte, si tenemos un conmutador con puertos span, podemos probar la implementación de la figura 16, de Jeff Natham [15]. Describe cómo analizar tráfico de red utilizando un puerto span de 100 Mbps o 1000 Mbps.
Cuando se monitoriza tráfico de alta velocidad (Gigabit en fibra óptica o mejor) es recomendable utilizar múltiples sistemas IDS y balancear la carga entre ellos. La figura 17 indica cómo implementar este tipo de configuración [16]. Netoptics también ofrece una detallada guía de instalación [17] para uno de sus Gigabit Taps de fibra.
