36.Espiar nuestra red

Vamos a procesar el tráfico de nuestra red mediante dos tipos de técnicas:

• La monitorización del tráfico. Trabaja a alto nivel: se limita a tomar medidas agregadas, los llamados contadores. Por ejemplo, total de bytes enviados o recibidos en un interfaz, agrupados por puerto de origen o destino. La monitorización es habitual en las empresas porque:

1. Resulta fácil de activar en toda la red dado que son los propios equipos los que facilitan esta información sobre sus interfaces.
2. Genera relativamente poca información para transmitir y procesar.
3. Es suficiente para conocer la disponibilidad de la red o el tipo de tráfico que transita. Por ejemplo, conocer el porcentaje de tráfico HTTP de nuestra red nos puede llevar a instalar un proxy .

• El análisis del tráfico. Trabaja a bajo nivel: captura todos los paquetes que transitan por una interfaz (los conocidos sniffer de red). Los paquetes solo son leídos, no interceptados: el paquete continúa su camino. El procesamiento de estos paquetes leídos permite generar medidas agregadas, pero sobre todo interesa analizar las conversaciones entre los equipos, comprobando que se ajustan al comportamiento esperado en el protocolo estándar (analizador de protocolos). Aunque esta información es mucho más rica que los simples contadores, la captura es muy costosa de activar en toda la red, porque se dispara la cantidad de información que hay que transmitir y procesar (la mayoría de los puertos ya tienen velocidad gigabit); por este motivo, solo se utiliza en situaciones concretas que no se pueden abordar con el estudio de contadores, como es la detección de ataques.

Necesitaremos herramientas que nos ayuden a recoger, procesar, analizar
y presentar toda la información disponible.

Con estas herramientas hay que tener cuidado para conseguir un equilibrio entre los objetivos de seguridad y la carga extra que supone tratar esta información (CPU de los equipos de red, tráfico que ocupa en la red enviar los contadores o capturas hasta la herramienta, CPU del servidor de la herramienta, coste del software especializado, dedicación de personal de soporte a consultar los informes y tomar decisiones, etc.).

Los problemas típicos que nos harán aplicar estas técnicas pueden ser tan sencillos como una tormenta de broadcast (demasiados paquetes de tipo broadcast), que podemos detectar en las estadísticas de una interfaz. Y tan complejos como un DoS (Denial of Service, denegación de servicio).

Además de la monitorización del tráfico y el análisis del mismo, hay un tercer elemento para el control de la red: la sonda. Una sonda (en inglés probe) es un equipo de la red que está programado para comportarse como un cliente normal de alguno de los servicios que tenemos desplegados. La sonda ejecuta sus operaciones periódicamente, de manera que, si alguna falla, podemos suponer que también le fallará al usuario y debemos corregir el problema.
Como hemos señalado con anterioridad, la monitorización del tráfico es relativamente fácil de activar en una red, porque los equipos suelen estar preparados para facilitarnos la información sobre sus contadores y basta con preguntarles periódicamente. En cambio, la captura de conversaciones es más compleja de activar. Las opciones son:

• Conseguir el control sobre alguno de los extremos de la conexión para poder utilizar alguna de las herramientas que veremos a continuación (tcpdump, wireshark).

• Interceptar la conexión misma desde algún equipo de red por donde pasen los paquetes intercambiados. Si este equipo tiene cierta inteligencia, seguramente incorporará funcionalidades avanzadas, como el port mirroring; incluso puede ser un router Linux, con lo que tendremos a nuestro alcance todas las herramientas que veremos para los extremos.

• Como último recurso podríamos conectar de manera temporal un hub en el puerto que queremos vigilar (Fig. 7.14), pero esto supone desplazamientos de personal y equipos que no siempre están disponibles (por ejemplo, el switch de LAN está en Barcelona, pero el departamento de soporte está en Madrid). Utilizamos un hub y no un switch porque el hub repite el tráfico de cada puerto a todos los demás, justo lo que necesitamos.

tcpdump

tcpdump es una herramienta sencilla disponible en Linux que permite hacer un volcado de todo el tráfico que llega a una tarjeta de red. Captura todo el tráfico, no solo el tráfico TCP, como aparece en su nombre. Los paquetes leídos se muestran en pantalla o se pueden almacenar en un fichero del disco para ser tratados posteriormente por esta misma herramienta u otra más avanzada. Se necesitan privilegios para ejecutarla, porque necesitamos poner la tarjeta en modo promiscuo para que acepte todos los paquetes, no solo los destinados a suMAC.

La captura con tcpdump se puede hacer en uno de los extremos si la conversación que estamos estudiando ocurre entre una máquina Unix y otra máquina Unix/Windows/etc.
(hay versiones de tcpdump para Windows, pero aquí es mejor WireShark). Aunque también lo utilizaremos muchas veces para capturar las conversaciones que atraviesan un router Linux. En la distribución representada en la Figura 7.15 podremos capturar las comunicaciones entre los ordenadores de las dos VLAN y todas las conexiones a Internet, aunque no podremos conocer qué hablan entre sí los ordenadores de una misma VLAN.

WireShark

WireShark es la herramienta más extendida en Windows para realizar capturas de tráfico y analizar los resultados. Es una evolución de una herramienta anterior llamada Ethereal. Para la captura de paquetes utiliza la librería pcap, que también aparece en otros sniffer, como tcpdump. La interfaz de usuario es muy potente, así como el número de protocolos que es capaz de analizar.

Port mirroring

Los switch gestionables suelen incorporar esta funcionalidad. Consiste en modificar la configuración del switch para que replique todo el tráfico de un puerto a otro. En el segundo puerto conectaremos el sniffer. El equipo o equipos conectados en el primer puerto funcionan con normalidad, no saben que están siendo espiados.
Generalmente se puede elegir el tipo de tráfico: entrante (desde el equipo hasta el switch), saliente (desde el switch hasta el equipo) o ambos. En algunos modelos podemos hacer que varios puertos vuelquen su tráfico a un mismo puerto, aunque habrá que vigilar las prestaciones del conjunto porque pueden desbordar el ancho de banda de la interfaz o la capacidad de captura del sniffer, lo que ocasionaría la pérdida de paquetes, invalidando el análisis posterior.

IDS/IPS. Snort

Aunque dispongamos de personal tan cualificado, no es humanamente posible revisar una a una todas las conversaciones que ocurren a diario en una red normal. Sobre todo porque la mayoría son interacciones normales, libres de
toda sospecha. Los expertos hay que reservarlos para los casos difíciles.
Para solucionar ambos problemas existen los sistemas IDS/IPS (Intrusion Detection System / Intrusion Prevention System). Los IDS detectan los ataques y los IPS actúan contra ellos. Tenemos dos tipos de IDS/IPS:

• NIDS/NIPS (Network Intrusion y Network Prevention). Buscan ataques sobre servicios de comunicaciones. Se basan en el análisis de los paquetes que forman parte de la comunicación entre dos máquinas, comprobando que se ajustan al protocolo estándar.

• HIDS/HIPS (Host Intrusion y Host Prevention). Buscan ataques sobre las aplicaciones y el sistema operativo de la máquina. Se basan en el análisis de los procesos actuales (ocupación de CPU y memoria, puertos abiertos) y la configuración y el log de cada uno de los servicios.

En este tema vamos a referirnos a los NIDS/NIPS. Estos sistemas procesan un fichero de captura de tráfico (o la realizan ellos mismos) y buscan patrones de comportamiento en los paquetes intercambiados entre los equipos. No se limitan a revisar las cabeceras del protocolo, sino que también miran en el contenido del paquete (payload). Cuando detectan un posible ataque, si es un IDS solo avisa al usuario (como mínimo, fichero de log) y si es un IPS solo responde al ataque (también se puede hacer que los IPS avisen).

La respuesta de un IPS puede ser impedir que ese paquete y los siguientes de esa conexión lleguen a su destino. En los más avanzados se puede configurar que permitan que el paquete llegue, pero adecuadamente modificado para que no prospere el ataque.

La inteligencia de estas herramientas suele residir en un conjunto de reglas que se cargan en el programa desde un fichero de configuración. Las reglas son elaboradas por expertos en seguridad que, cuando han identificado un nuevo tipo de ataque, escriben la regla que permitirá al IDS detectarlo.

Los problemas de los IDS son dos:

• Rendimiento. El número de reglas es creciente (hay nuevos ataques y no podemos descartar los antiguos) y el volumen de tráfico también, por lo que necesitamos un hardware muy potente para tener funcionando un IDS sobre capturas de tráfico en tiempo real. En determinados momentos, la cola de paquetes pendientes de examinar será tan larga que la interfaz estará a punto de empezar a descartarlos; para evitarlo, el IDS los dejará pasar, a sabiendas de que puede ser un ataque (si no los deja pasar, nosotros mismos estaremos ejecutando un ataque). Pero si nos limitamos a procesar ficheros de captura antiguos, puede que encontremos ataques que ya han ocurrido y sea tarde para reaccionar.

• Falsos positivos. Las reglas no son perfectas y puede que estemos alertando sobre comunicaciones que son perfectamente legales. Conviene probar muy bien una regla antes de meterla en un IPS.