Multipath TCP

Las organizaciones preocupadas por la optimización de recursos como ancho de banda, CPU y RAM, y por la disponibilidad de sus servicios, hacen que tenga que afrontar proyectos de implantación y optimización de balanceadores de carga aprendiendo nuevos conceptos y técnicas de balanceo. Uno de los últimos conceptos aprendido ha sido Multipath TCP.

Multipath TCP o MPTCP, que aún está en fase experimental por el IETF, permite al protocolo TCP utilizar varios caminos para la comunicación entre equipos, maximizando el uso de los recursos e incrementando la redundancia. Es decir, por ejemplo nos permite compartir la conexión a Internet mediante 3G y WiFi en un dispositivo móvil, utilizando los dos accesos en paralelo, proporcionándonos mayor ancho de banda y mayor redundancia en la conexión, ya que si se produce un corte en uno de los accesos, o alguno no está disponible, el servicio no se vería afectado y el usuario final no apreciaría ningún problema sobre el servicio. Algunos fabricantes como F5, Citrix y Apple ya han incorporado esta característica en sus sistemas, como por ejemplo podemos ver la compatibilidad de Multipath TCP en iOS 7.

 

Para aprovechar esta funcionalidad, también llamada multiplexación inversa, se necesita que las aplicaciones y equipos intermedios como balanceadores de carga y sistemas de seguridad se adapten a este nuevo estándar de conectividad. Además de la redundancia y el mejor aprovechamiento del ancho de banda, esta nueva forma de comunicarnos trae otras mejoras, como podemos ver por ejemplo en la multiplexación TCP realizada en la funcionalidad OneConnect de F5, que permite reutilizar las sesiones TCP de varios clientes contra los servidores, evitando la sobrecarga de los servidores al tener que abrir y cerrar muchas menos sesiones, a la vez que se entrega el servicio con mayor rapidez al no tener que renegociar el Handshake de TCP por cada petición. A continuación podemos ver el flujo de conexión si utilizamos multiplexación:

 

Ya veremos la penetración y adopción de este estándar en el mercado, pero todo apunta que ha llegado para quedarse, ya que grandes empresas como Google y Facebook también están apostando por ello para además integrarlo en la próxima versión del protocolo web HTTP/2.

Un saludo amigos y recuerda, los comentarios te esperan para cualquier idea que te surja.

Reto ISACA 2015

El año pasado tuve la oportunidad de presentar una propuesta y una idea en el I Concurso para Jóvenes Profesionales organizado por el capitulo de Madrid ISACA. Fue una experiencia enriquecedora y gratificante, ya que tuve la oportunidad de conocer a gente interesante con muchas ganas de hacer cosas en la temática de Auditoría, Seguridad Informática y Gobierno de las TIC. Mi propuesta trataba sobre la dependencia tecnológica que tiene actualmente España para proteger sus infraestructuras.

Desde mi punto de vista, este tipo de actividades pueden ayudar a evitar la dependencia tecnológica que tenemos actualmente, incentivando la innovación, proporcionando capacitación en Seguridad de la Información y fomentando la industria de las TIC, además que se obtienen productos de valor. Precisamente, el Reto ISACA está alineado con uno de los objetivos de la Estrategia de Ciberseguridad Nacional, donde se dice que “Es importante fomentar y potenciar las capacidades tecnológicas precisas para disponer de soluciones nacionales confiables que permitan proteger adecuadamente los sistemas frente a las diferentes amenazas” y concretamente intentando evitar el “riesgo que existe no sólo de ser excesivamente dependiente de los productos TIC procedentes del exterior, sino también de las soluciones de seguridad desarrolladas fuera de nuestras fronteras”, como indica la Estrategia de Ciberseguridad de la Unión Europea. 

En la primera edición del Reto ISACA tuve el placer de compartir cartel con grandes jóvenes profesionales:

• Ganadores: Daniel Echeverry Montoya & Ismael González D. por "Tortazo para la recolección de información y auditoria de repetidores en la red de TOR".
• Finalistas: Francisco Gómez, por "Sinfonier: Storm Builder for Security Intelligence" y David Meléndez, por "Mitigando ataques Wifi al control remoto de drones".
• Accésits: David Matesanz, por "Modelos de negocio de la “ciber-inseguridad"" y David Romero Trejo, por "¿Estamos vendidos?".
  
  
  

El II Concurso para Jóvenes Profesionales tiene los mismos requisitos que el primero, así que animo a todos los jóvenes profesionales menores de 35 años que se presenten a este Reto. Yo, ya estoy preparando mi propuesta, para ver si puedo contribuir en la mejora y protección de este mundo cibernético.

Un saludo amigos y muchas gracias a la organización ISACA por este tipo de iniciativas.

Phoenix: Buscando Botnets DGA

En la anterior entrada hablamos sobre Pleiades para detectar malware basado en DGA, es decir, en algoritmos de generación de dominios (DGA). Pleiades principalmente se basa en la búsqueda de respuestas NXDomains analizando el tráfico DNS para detectar dominios maliciosos que son generados aleatoriamente. En esta entrada me gustaría escribir sobre un nuevo sistema llamado Phoenix desarrollado por la Politécnica de Milán, que se basa principalmente en la lingüística y la fonética para detectar dominios maliciosos generados automáticamente por equipos zombies para conectarse a su servidor de Command & Control (C&C).

El sistema Phoenix utiliza sensores pasivos de DNS, preservando la privacidad de los equipos infectados sin afectarle los mecanismos de compartición de IPs, como NAT, que utilizan los operadores de telecomunicaciones.

En primer lugar, Phoenix crea un modelo lingüístico de los dominios benignos. A continuación, los dominios que violan el modelo son considerados como generados automáticamente, es decir, dominios DGA. Después, Phoenix agrupa estos dominios de acuerdo a las relaciones existente entre la IP y el dominio. Por último, Phoenix etiqueta los grupos, ya que todos los dominios de un mismo grupo pertenecerán a la misma botnet. Las etiquetas son importantes para ver la evolución de la botnet (por ejemplo si el servidor de C&C se migra de un sistemas autónomo a otro), y para identificar servidores de C&C no conocidos, es decir, para generar nuevas listas negras.

El sistema Phoenix está dividido en tres módulos. El módulo principal es el módulo de Descubrimiento de DGA, el cual identifica y modela los DGAs extrayendo los caracteres y palabras de los dominios. El módulo de Detección de dominios maliciosos recibe uno o más nombres de dominio con su correspondiente tráfico DNS, y usa el modelo construido por el módulo de Descubrimiento para decir si el nombre de dominio ha sido automáticamente generado. Si es así, este módulo etiqueta el dominio indicando que probablemente se trate de un dominio generado mediante DGA. A continuación el módulo de Inteligencia, correlaciona y monitoriza los resultados de los otros módulos para extraer información significativa de los datos obtenidos (por ejemplo si una botnet basada en DGA aún desconocida se está migrando entre sistemas autónomos, si un dominio previamente ignorado pertenece a una familia en particular de DGA, etc).

 

El módulo de Descubrimiento de DGA recibe flujos de tráfico de DNS (solicitudes y respuestas) desde el sensor de DNS Pasivo, además de nombres de dominios maliciosos desde un sistema de reputación para identificar DGA conocidos. Esta información es públicamente accesible y puede ser obtenida fácilmente desde listas negras o sistemas de reputación de dominios y desde monitores pasivos de DNS públicos que mantienen la privacidad de los usuarios (por ejemplo ISC/SIE).

Este módulo sigue los siguientes tres pasos para reconocer dominios utilizados por botnets basadas en DGA.

1. Filtrando DGA: Se extrae un conjunto de características lingüísticas desde los nombres de dominio. El objetivo es reconocer los nombres de dominio que parecen ser generados automáticamente. Por ejemplo, se puede diferenciar entre 5ybdiv.cn, que parece un DGA, y searchsmart.tk, que parece ser un dominio benigno o legítimo. Destacar que el sistema Phoenix está basado en la lingüística del idioma Inglés para la detección de DGAs. Ç
   La salida es un conjunto de dominios que han sido generados aleatoriamente, posiblemente generados por diferentes algoritmos.
   En este paso se supone que un dominio generado automáticamente tiene diferentes características lingüísticas que un dominio generado por un humano. Esta suposición es razonable ya que el objetivo principal de un dominio es que sea recordado fácilmente y pueda ser usado por los humanos.
   
   
2. Agrupando los DGA: Se extraen características basadas en la IP, desde el sensor de DNS, de los dominios que se han recibido en el Paso 1. Se usan estas características para agrupar los DGAs que resuelven al mismo conjunto de direcciones IP, es decir que resuelven a los mismos servidores de C&C. Estas agrupaciones se realizarán observando las respuestas DNS. Por ejemplo, si el dominio 5ybdiv.cn y hy093.cn resuelven a la misma IP, se agrupan. Aquí se asume que dominios generados por diferentes algoritmos serán utilizados en distintas botnets, o distintas variantes de malware, o al menos por distintos botmasters, quienes han personalizado el algoritmo a su estrategia de C&C. Por lo tanto, esta partición y agrupación reflejará los distintos grupos de botnets existentes.
   
   
3. Fingerprinting del DGA: Se extraen características de las agrupaciones de dominios realizadas en el paso 2 que definirán la huella o fingerprinting de los algoritmos DGAs. Es importante destacar que las características utilizadas son distintas a las del paso 2. El módulo de Detección usará estas huellas para buscar e identificar dominios aún no conocidos. Por ejemplo, los dominios epu.org y xmsyt.cn tendrán distinta huella.

El módulo de Detección de dominios maliciosos recibe nombres de dominios, lo cuales pueden ser benignos o maliciosos, y los hace pasar de nuevo por el filtrado para comprobar si han sido generados automáticamente. Los nombres de dominio que pasen este filtro se someten a otras comprobaciones, las cuales pueden hacer que finalmente no se categoricen como pertenecientes a un DGA (por ejemplo si no coincide con ninguna huella). Por lo tanto, en este paso, se puede llegar a etiquetar un dominio como benigno y no perteneciente a un DGA. Aunque es más importante no descartar dominios sospechosos. Por tanto, sólo para este módulo, se configura el filtrado con un umbral más bajo, para que no descartemos dominios que presenten, aunque ligeramente, las características lingüísticas que son típicamente de los dominios maliciosos. Es decir, si hay que monitorizar un dominio porque se piense que pueda ser malicioso se hará, en lugar de decidir y precisar si el dominio es maligno o no. Entonces, este módulo aprovecha las agrupaciones de dominios maliciosos y sus correspondientes huellas para encontrar nuevos algoritmos de generación de dominios maliciosos.

Una vez que un dominio ha sido etiquetado como malicioso, el módulo de Inteligencia puede registrar al dominio como perteneciente a un DGA conocido. Por lo tanto, la salida de los módulos anteriores permiten a este módulo extraer información simplificada y actualizada de los dominios. Con esta información, las direcciones de los servidores de C&C y las listas de dominios maliciosos se agrupan en pequeños conjuntos, lo que facilita el análisis considerándolas todas en una sola lista. Por ejemplo, si un analista sabe que 100 dominios son maliciosos, puede usar las etiquetas para dividirlos en conjuntos más pequeños: uno que contiene los nombres de dominios similares a 5ybdiv.cn y hy093.cn, y otro con dominios similares a epu.org. La similitud no significa que solamente tengan semejanzas lingüísticas, sino que también se considera otras características basadas en nombre de DNS e IP. El TLD tampoco es distintivo, aunque se usa como ejemplo. Con esta información, el analista puede rastrear por separado la evolución de las IPs de dos grupos de dominios distintos. Por ejemplo, detectar cuando un servidor de C&C se migra a un nuevo sistema autónomo es fácil cuando el conjunto de IPs y dominios es pequeño y las características del DGA son conocidas y uniformes.

Al igual que el sistema Pleiades tiene limitaciones, el sistema Phoenix también las tiene. En primer lugar, necesita previamente conocer dominios maliciosos generados aleatoriamente. Además, el estudio tan solo está hecho para la fonética y lingüística del idioma Inglés, lo que si intentamos analizar dominios de otras lenguas será ineficiente. Por último, si el dominio que genera el DGA es pronunciable, este sistema no lo detectaría como DGA.

Un saludo amigos y recuerda, los comentarios te esperan para cualquier idea que te surja.

Pleiades: Detectando Malware DGA

Los malos siempre van por delante, y esto hace que los investigadores de seguridad constantemente tengan que innovar en sus técnicas de detección y mitigación de intrusos. Lo que en un principio parecía una muy buena idea, tener una base de datos global categorizada por IP y dominios maliciosos al estilo CIF mediante un sistema de reputación dinámico donde se asigne la reputación de cada IP y dominio, ahora ya parece que se está quedando obsoleto con las nuevas técnicas de evasión utilizadas por los desarrolladores de malware, como Fast Flux y los Algoritmos de Generación de Dominios o DGA.

Actualmente botnets como Nugache, Storm, Waledac, Alureon o Zeus utilizan el protocolo P2P para comunicarse con su servidor de Command & Control (C&C), sin embargo cuando los zombies se encuentran tras una red empresarial donde se controla la salida a Internet y se bloquea el acceso a redes P2P, este tipo de malware contiene un plan de contingencia utilizando DGA para conectarse al C&C. Para detectar malware que haga uso de algoritmos DGA, el Instituto de Tecnología de Georgia ha desarrollado un sistema llamado Pleiades que se basa principalmente en el análisis del tráfico DNS.

El sistema Pleiades está compuesto por dos grandes módulos. El módulo de Descubrimiento de DGA, y el módulo Clasificador de DGA y de Detección de C&C.

El módulo de Descubrimiento de DGA obtiene y analiza el tráfico DNS buscando respuestas NXDomain o Name Error Responses, ya que un equipo infectado con DGA realizará muchas consultas a nombres de dominios inexistentes. Además, analiza la distribución de caracteres de los dominios solicitados, debido a que normalmente un malware basado en DGA realizará peticiones a nombres de dominios con características parecidas como misma longitud, mismo nivel de aleatoriedad, misma distribución de caracteres, etc. Finalmente, tras el análisis de las respuestas NXDomains y la distribución de los caracteres, Pleiades agrupa o clusteriza los dominios solicitados, ya que éstos pueden pertenecer a distintos algoritmos DGA.

Una vez agrupados los dominios mediante cluster, el módulo Clasificador de DGA realiza una clasificación, donde encontrará DGA conocidos y no conocidos. En el caso que nos ocupa, el sistema Pleiades descarta los DGA conocidos porque tan solo está interesado en los nuevos DGA. Además, el módulo Clasificador de DGA recibe los NXDomains generados por los equipos de la red monitorizada. Si uno de los dominios está marcado como que es DGA, diremos que el equipo está comprometido y añadiremos su IP y la etiqueta del DGA al informe de detección del malware.

Para realizar la clasificación de dominios, Pleiades se apoya en el módulo de modelado de DGA, que recibe una lista de 10000 dominios legítimos de Alexa.com, una lista de dominios DGA conocidos y el cluster de NXDomains desde el módulo de descubrimiento de DGA. Con toda esta información es capaz de construir un nuevo modelo de DGA.

Por último, el módulo de Detección de C&C recibe las solicitudes DNS realizadas por todos los equipos y cuando una máquina es etiquetada como comprometida, analiza sus consultas legítimas de DNS para detectar el servidor de C&C.

Es de destacar en el sistema Pleiades sus limitaciones, como por ejemplo la incapacidad de obtener el algoritmo de generación de dominios exacto utilizado por el DGA, a pesar de conseguir modelos estadísticos precisos, o la dificultad de diferenciar botnets que utilicen el mismo algoritmo DGA. Además tampoco es capaz de obtener el número de equipos infectados por la botnet, debido a que utiliza Passive DNS y normalmente existe un NAT tras el router de los operadores de Internet.

Pleiades es el primer sistema que conozco que trata de detectar malware basado en DGA, la técnica de detección es innovadora y estoy convencido que eficaz al analizar las respuestas de los servidores de DNS. Sin embargo, aunque sea capaz de detectar el comportamiento anómalo de un equipo infectado por DGA, la detección del C&C está comenzando a ser más difícil debido a que los malos han empezado a generar varias semillas dentro del mismo DGA, la buena que se utiliza para la conexión con el C&C, y otra simplemente para hacer ruido, así es más fácil despistar a los investigadores que intentan obtener la lista de dominios aleatorios mediante ingeniería inversa.

Un saludo amigos y recuerda, los comentarios te esperan para cualquier idea que te surja.