Enrutamiento Multicast

Cuando tenemos que explicar, configurar y/o implantar un red Multicast, a los administradores de redes se nos da la vuelta el cerebro al cambiar completamente el concepto de Unicast. En el momento que estamos configurando una red enrutada por Multicast debemos saber que ya no importa hacia dónde va el paquete sino desde dónde viene el paquete. Es decir, cambiaremos la idea de fijarnos en la IP de destino del paquete por la IP origen, que la utilizaremos para consultar la tabla de enrutamiento Multicast, en lugar de la tabla Unicast, y así conocer el emisor y el grupo Multicast al cual reenviar los paquetes.

Este cambio de paradigma hace que el método de transmisión Multicast esté poco extendido en las redes actuales, al predominar el método Unicast y a la falta de conocimiento por parte de los administradores de redes y desarrolladores de software de las ventajas que nos puede aportar este tipo de arquitectura de multidifusión.

Entre las ventajas principales nos podemos encontrar la eficiencia en cuanto a CPU y memoria, ya que el emisor tan solo tiene que procesar una vez el paquete para enviarlo a múltiples dispositivos o receptores. Además conseguimos una mejora en el rendimiento de los equipos, aplicaciones y enlaces ya que con tan solo un envío del paquete alcanzaremos a todos los receptores que estén unidos al grupo Multicast. Este comportamiento de multidifusión permite utilizar aplicaciones distribuidas de manera eficiente como emisión de televisión y radio por Internet, videoconferencia, plataformas de e-learning y sistemas de videovigilancia CCTV sobre IP.

Por otra parte, Multicast tiene algunas desventajas como por ejemplo el uso del protocolo UDP que no mantiene una ventana de congestión como puede hacer TCP, haciendo que la voz y el vídeo lleguen más rápido a los receptores con el inconveniente de que se pueden perder paquetes por el camino, llegar desordenados y/o duplicados. Además al utilizar UDP y no establecerse sesiones es más complicado configurar filtros de seguridad para proteger la información de este tipo de redes de multidifusión.

Aunque nosotros no lo hayamos configurado, la mayoría de sistemas operativos implementan el protocolo IGMP para unirse a grupos Multicast de manera automática. Por ejemplo, para unirnos a dispositivos UPnP mediante el protocolo SSDP como se puede ver a continuación:

Para diseñar, implantar y administrar redes Multicast es importante tener algunos conceptos claros, como por ejemplo el funcionamiento de los árboles STP del camino más corto hacia el origen o los árboles compartidos, ya que estos son la base donde se apoya el protocolo PIM implementado por los routers para el aprendizaje de rutas Multicast. Además para realizar un diseño eficiente es imprescindible conocer los distintos métodos en los que puede operar PIM; Dense Mode basándose en inundación y poda cada 3 minutos, Sparse Mode utilizando un router que actuará como punto de encuentro (RP) o en algunos escenarios podemos incluso a llegar a implantar una arquitectura híbrida de Sparse-Dense Mode con varios routers RP.

Este cambio en el modo de enrutamiennto puede causarnos sobresalto y sorpresa, pero os puedo asegurar que una vez estudiado e implantado veremos claramente las ventajas que nos aporta una solución de multidifusión por Multicast.

Un saludo amigos y recuerda, lo primero que te venga a la cabeza ¡escríbelo en un comentario!

Multi-Chassis Link Aggregation

MC-LAG o Multi-Chassis Link Aggregation, otro término más en este mundillo de las redes, es una especie de LAG para combinar y agregar nodos en nuestra red proporcionando redundancia a nivel de chasis. El IEEE lo estandarizó dentro del 802.1aq como Shortest Path Bridging mientras que la mayoría de fabricantes han desarrollado su propia tecnología de Virtual Chasis o Virtual Switching para entregarnos el rendimiento y redundancia que necesitamos.

Esta tecnología nos va a facilitar el trabajo a todos los que nos dedicamos a las redes. Porque todos hemos tenido alguna vez que estudiar, entender y configurar todas las variedades de Spanning Tree para ver cuál es el que mejor se adapta a nuestra infraestructura, ya sea STP, RSTP o MSTP, también hemos tenido que entender los protocolos de redundancia HSRP, VRRP y GLBP, y además para proporcionar altas capacidades y un buen rendimiento hemos diseñado e implantado infraestructuras con agregaciones de enlaces bajo LACP o PAgP. Sin embargo, las redes siguen creciendo, cada vez existen más dispositivos conectados a Internet y con el Internet de las Cosas (IoT) parece que esto va en aumento. Por este motivo los fabricantes siguen innovando para hacer que nuestras redes tengan mayor rendimiento, menor coste de operación y por supuesto simplificarnos la gestión de la infraestructura que cada día se vuelve más grande y compleja.

Para poder “olvidarnos” de los bucles de la red y de protocolos de redundancia, fabricantes como Juniper, Cisco, HP o Extreme Networks han desarrollado tecnologías que nos permiten:

• Disponer de una gran alta disponibilidad: Si un chasis ya incorpora bastantes elementos para proporcionarnos alta disponibilidad como supervisoras redundantes, tarjetas redundantes, fuentes de alimentación redundantes, si además tenemos la posibilidad de disponer de varios chasis físicamente separados por una distancia de kilómetros coexistiendo todos ellos como un sólo virtual chasis conseguiremos una disponibilidad del 99.999%.

• Mejor rendimiento, escalabilidad y flexibilidad: Mediante soluciones de Virtual Chasis aprovecharemos todos los enlaces entregando mayor rendimiento, menor latencia y más ancho de banda al evitar Spanning Tree, no bloquear puertos y realizar agregación de enlaces de gran capacidad.

• Reducción de costes de operación: Al separar el Data Plane del Control Plane se puede gestionar varios dispositivos desde una sola consola de gestión ahorrando tiempo de configuración, y además al simplificar la arquitectura evitando protocolos de redundancia como HSRP, VRRP o GLBP y configuraciones de Spanning Tree podemos realizar troubleshooting eficientemente.

Cada fabricante ha llamado a esta tecnología de una manera distinta. Por ejemplo Juniper lo ha llamado Virtual Chassis permitiendo agregar hasta 10 chasis que se verán todos como un único chasis virtual, además la distancia entre los chasis puede alcanzar los 50 Km. Por otro lado Cisco lo llama Virtual Switching System o VSS que junto con Multi-chassis EtherChannel proporciona alto rendimiento aunque los chasis estén separados a 80 Km. HP también se ha subido al carro de esta tecnología con Intelligent Resilient Framework permitiendo unir hasta 9 chasis a una distancia de 70 Km. Por último, Extreme Networks con su tecnología Virtual Switch Bonding y Data Center Bridging permite configurar y gestionar hasta 8 switches desde el mismo virtual chasis.

Hemos conseguido unificar en un solo switch virtual la gestión y conmutación de varios chasis ofreciendo simplicidad, alta disponibilidad y elevados rendimientos ¿para cuando un Virtual Router que nos permita abandonar los protocolos de enrutamiento de interior como OSPF, EIGRP o IS-IS?

Un saludo amigos y recuerda, lo primero que te venga a la cabeza ¡escríbelo en un comentario!

¿Google nos escanea?

Leyendo la entrada en Security Art Work de ¿Gmail como server de C&C? Me vino a la cabeza de lo difícil y complicado que sería para una organización bloquear el envío de correos electrónicos a los servidores de Google. El correo electrónico, que para muchas empresas es ya una commodity y lo tienen externalizado a Google, es un servicio esencial para la operativa diaria de una organización y casi tan fundamental como el teléfono. Sin embargo, si sabemos que hay una botnet que se controla desde los servidores de correo de Gmail ¿cómo vamos a bloquear el acceso a estos servidores? Es una decisión difícil y complicada de tomar donde más vale que detectemos la infección del troyano al inicio de la propagación, ya que sabemos que una vez infectado, el atacante tendrá acceso a la máquina comprometida.

Tras esta reflexión recordé las últimas alarmas que están apareciendo en el servicio de monitorización de la seguridad de Ariolo, donde muchas de ellas tiene como IP origen direccionamiento del buscador de Google, ¿nos está atacando Google? Se trata de análisis de puertos procedentes del buscador de Google con puerto origen 443, o por lo menos así lo indica el sistema de detección de intrusos.

 

Concretamente la alarma la dispara un evento del IDS Snort que indica que se está realizando un análisis de puertos mediante la herramienta Nmap y los parámetros -sA. ¿Qué significa esto? Pues que el atacante está enviando paquetes con número de ACK 1 sin haber establecido previamente la sesión, es decir, no está siguiendo el protocolo de establecimiento de sesión que define TCP/IP. ¿Para qué? Estos parámetros en Nmap se suelen utilizar para comprobar si el cortafuegos que protege el perímetro de la red es del tipo stateful inspection, que analiza y comprueba los establecimientos de sesión antes de dejar pasar el tráfico, o por el contrario es un cortafuegos stateless que tan solo filtra paquetes sin comprobar las sesiones establecidas. A continuación podemos ver una captura de red en Wireshark donde se puede observar que estamos recibiendo paquetes con número de secuencia 1 y ACK 1.

¿Estamos hablando de un falso positivo? ¿o por el contrario Google está llamando a la puerta? Sea lo que sea será necesario analizarlo con más detalle porque ahora mismo no me imagino bloqueando el acceso al buscador de Google.

Un saludo amigos y recuerda, lo primero que te venga a la cabeza ¡escríbelo en un comentario!

Unidirectional Security Gateways

La mayoría de ingenieros que nos dedicamos a proteger y a optimizar los sistemas y las redes, normalmente entendemos que la seguridad de la información está centrada en asegurar la información alojada en los sistemas y los datos que circulan por las redes, sin embargo olvidamos la protección de infraestructuras críticas basadas en sistemas SCADA. Para proteger cualquier entorno de producción estamos acostumbrados a instalar cortafuegos de fabricantes tan reconocidos como Fortinet, CheckPoint o Palo Alto para controlar la entrada y salida de datos del perímetro de la red, sin embargo cuando hablamos de entornos industriales los requerimientos y la criticidad no son los mismos que para entornos corporativos. En entornos de infraestructuras críticas como sistemas de gestión de aguas, refinerías o plantas nucleares podemos estar hablando de cortafuegos unidireccionales de fabricantes como Waterfall, Nexor o Ksec.

Un cortafuegos unidireccional es un dispositivo que permite el tráfico de red en un sólo sentido, garantizando físicamente que no va a pasar tráfico en sentido contrario. Con este tipo de dispositivos podemos proteger entornos de alta criticidad que por requerimientos del negocio deben estar conectados a la red, ya sea para monitorizar remotamente sistemas de infraestructuras críticas o para evitar fugas de información confidencial. Podríamos realizar el símil con cableado de fibra óptica si tan solo enchufamos el conector de envío (TX) o recepción (RX) en el transceptor GBIC, aislando y evitando físicamente el tráfico de un sentido.

A continuación podemos ver un esquema de un ejemplo de despliegue de este tipo de sistema de seguridad:

Como podemos ver en el esquema anterior, este tipo de despliegue requiere dos cortafuegos unidireccionales: el equipo transmisor (TX) contiene un láser y el equipo receptor (RX) que contiene el receptor óptico. De esta manera la comunicación tan solo fluye en un sentido mediante diodos de datos. Además serán necesarios servidores o agentes conectores en ambos extremos de la red que soporten los servicios que corren por la red como por ejemplo agentes de sincronización de bases de datos, reenvío de eventos o compartición de ficheros e impresoras.

Otra arquitectura, otra forma de proteger los activos y otra posibilidad de proteger las infraestructuras críticas que nos proporcionan servicios tan necesarios como la luz y el agua, que utilizamos todos los días sin preguntarnos si mañana también tendremos estos servicios imprescindibles.

Un saludo y recuerda, lo primero que te venga a la cabeza ¡escríbelo en un comentario!

Algoritmo de Generación de Dominios

Los que nos dedicamos a la seguridad, y los que además tenemos el sombrero blanco, para proteger lo mejor que podemos las redes, sistemas y en definitiva los datos que es donde se encuentra en la mayoría de las veces lo realmente valioso, debemos saber primero cuáles son las técnicas que utilizan los “malos” para aplicar medidas que mitiguen la amenaza de que un atacante robe información o se haga con el control de nuestros sistemas. Es decir, como he dicho siempre, primero hay que saber cómo funcionan y trabajan los malos para saber defendernos.

Pensemos … los atacantes siempre están buscando formas de evadir sistemas de seguridad como listas negras, listas de reputación de IPs y dominios, filtros web, sistemas de prevención de intrusos, etc. ¿se puede eludir todas estas técnicas de detección y mitigación de intrusos? Pues analizando una de las últimas alarmas de la sonda Ariolo llegué al concepto DGA, que desconocía, y parece ser que ayuda bastante a los atacantes a evadir sistemas de seguridad perimetral.

 

DGA o Domain Generation Algorithm son algoritmos que utilizan los malwares para generar aleatoria y dinámicamente dominios donde se alojarán los servidores de C&C. Esta técnica junto con Domain Fluxing permite a un troyano generar una lista de por ejemplo 5000 dominios donde puede estar alojado el servidor de C&C y a los cuales intentará conectarse, de tal manera que el atacante lo único que tiene que hacer es registrar uno de esos dominios generados aleatoriamente, realizar las operaciones pertinentes, y volver a des-registrar el dominio. Como para cada operación que quiera realizar el atacante sobre la botnet puede utilizar un dominio diferente, y por tanto una IP diferente, los sistemas de detección basados en listas negras, listas de reputación y filtros web pueden ser evadidos sin problemas, ya que aunque hoy se catalogue como de baja reputación mañana el servidor de C&C tendrá otro dominio y otra IP, y por tanto se permitirá el acceso. Algunos de los malwares que utilizan esta técnica son el Conficker, Cryptolocker, Zeus, Murofet, BankPatch, Bonnana y Bobax.

La implementación de este tipo de evasión la podemos dividir en las siguientes cuatro fases:

 

• En primer lugar, el atacante genera una semilla, que será la utilizada por los troyanos para generar los dominios aleatorios. Por ejemplo puede ser la fecha del sistema.
• En segundo lugar, se incrusta el algoritmo DGA en el troyano para que utilizando la semilla genere aleatoriamente por ejemplo 1000 dominios todos los días.
• En tercer lugar, el equipo infectado intentará conectarse a cada uno de los dominios, donde tan solo uno será el válido y que habrá sido registrado previamente por el atacante, con total seguridad utilizando una tarjeta robada y datos personales falsos.
• Por último y en cuarto lugar, el atacante tendrá control sobre la botnet para dar nuevas ordenes, obtener información o desplegar actualizaciones del malware.

Una vez conocido cómo actúan los malos, ¿qué podemos hacer para que las máquinas infectadas no se comuniquen con los servidores de C&C? Por nuestra parte, mientras que los departamentos de análisis de malware realizan ingeniería inversa para conocer las semillas de cada uno de los troyanos que utilizan esta técnica y así tener la lista de dominios afectados, nosotros deberíamos realizar inspección de todo el tráfico, incluido SSL rompiendo el túnel en el perímetro de la red, para detectar reverse shell y comportamientos anómalos en las máquinas.

Espero que la entrada de hoy os haya sido interesante amigos y recuerda … cualquier comentario es bienvenido.