Archivo de la categoría: Podcast

Podcast – 42 – R U Dead Yet?

R U Dead Yet?o simplemente R.U.D.Y. es una herramienta que busca la denegación de un servicio web a la página web a reservar recursos para una conexión absurdamente lenta. Mientras la mayoría de ataques de denegación de servicio se basan en el envío de una gran cantidad de conexiones rápidas para conseguir la saturación, RUDY utiliza un enfoque opuesto: ‘relativamente’ pocas conexiones de gran duración que lleguen a agotar los recursos del servidor al no permitirle liberarlos por mucho tiempo.

Esta herramienta tiene un funcionamiento muy sencillo que permite que cualquiera la utilice sin requerir conocimiento alguno: simplemente hay que indicarle la dirección de la web que queremos atacar y darle al botón y lanzamos el ataque. Debido a su funcionamiento cualquier web que tenga un formulario es susceptible de ser atacada mediante esta técnica.

Funcionamiento

Fuente imagen: Riverbed

Veamos cómo funciona esta herramienta:

  1. El programa R.U.D.Y. revisa la web indicada en busca de un formulario. Sirve cualquier formulario: uno sencillo de contacto es suficiente.
  2. Ahora la herramienta establece una primera conexión con un mensaje HTTP POST, pero indicándole al servidor destino que el tamaño del mensaje es muy grande (10,100MB, 20GB.). Esto hará que el servidor reserve espacio de memoria suficiente para recibir esta información tan voluminosa.
  3. Una vez establecida la primera conexión, ahora la herramienta empieza a enviar datos a una velocidad exageradamente lenta. Piensa que puede enviar un único byte por paquete a intervalos de aproximadamente 10 segundos.
  4. La herramienta seguirá enviando información lentamente y el servidor, al ir recibiendo actualizaciones, no cerrará la sesión pues creerá que se trata simplemente de un usuario con una mala conexión.

Si combinas múltiples sesiones de R.U.D.Y. es posible agotar los recursos del servidor atacado al llegar a saturar el espacio de memoria disponible o bien, más probablemente, el número de sesiones simultáneas que el servidor puede manejar. Así pues, si se combina un ataque R.U.D.Y desde varios orígenes, se puede obtener una denegación de servicio distribuida (o DDoS).

Protecciones

Al contrario que otros tipos de ataques de denegación de servicio, un ataque tipo R.U.D.Y es mucho más silencioso y sutil, por lo que es más difícil de detectar.

En las primeras versiones de la herramienta los paquetes se enviaban de forma continua cada 10 segundos, por lo que los sistemas IDS podían detectarlos con relativa facilidad, pero ahora mismo este envío de información se realiza de forma semialeatoria: a estos 10 segundos fijos se le añaden o restan un número aleatorio de segundos para evitar ser detectado por esta regla estática.

La forma más habitual para evitar este tipo de ataques es simplemente cerrar este tipo de conexiones tan lentas. Aunque esto hará que usuarios legítimos con conexiones muy lentas se verán impedidos de acceder a nuestro servicio web.

Otra defensa es el uso de proxys inversos que controlen y gestionen del tráfico de datos de tal forma que sean estos los que realicen las reservas de recursos para gestionar las conexiones lentas y no los propios servidores web.

Descarga directa.

Podcast – 41 – DHCP Snooping

En el capítulo de hoy, convertimos en audio el artículo sobre DHCP Snooping de este mismo blog.

Son poco más de 9 minutos. Espero que os guste 🙂

Logo DHCP
Logo DHCP Fuente imagen: IES Haría

Como el servicio DHCP es utilizado por los equipos que se conectan a una red y desconocen todo de ella, no podemos delegar en ellos mismos las funciones de seguridad. De igual forma, al no saber qué hay o no hay en la red no podemos reposar la seguridad en los servidores de la red, porque el equipo nuevo no sabe que debe consultarles a ellos. Así pues, la seguridad del protocolo DHCP descansa en los propios equipos de red.

Para asegurar que los nuevos usuarios sólo reciben la información del servidor DHCP oficial de la red los switches inspeccionan el tráfico de este protocolo y bloquean aquel que no cumpla las características especificadas por los administradores de red.

Descarga directa.

Podcast – 40 – Whaling

En el capítulo de hoy recupero un artículo de 2016 para convertirlo en audio para los seguidores del podcast. Como los oyentes de podcast no suelen acceder al blog, pues aquí les traigo el blog en audio.

Whaling
Fuente imagen: condiesit.co.uk

La definición de whaling sería aquel conjunto de técnicas de phishing que buscan atacar objetivos concretos de gran valor, pero para no repetirme os dejo el audio.

Descarga directa.

Podcast – 39 – Deep Packet Inspection

El capítulo de hoy ha surgido tras atender una charla comercial vía videoconferencia donde el presentador repetía una y otra vez la gran capacidad de Deep Packet Inspection de su solución. Pero, ¿seguro qué sabía lo que es, en realidad, Deep Packet Inspection?

Fuente imagen: AltenCalSoftLabs

Técnicamente hablando la denominación Deep Packet Inspection, que ha ganado bastante fuerza en el mundillo comercial y del marketing, debe utilizarse para una familia de técnicas de análisis de tráfico en el que lo que se examina no es la cabecera sino la información enviada en el paquete de datos.

Un firewall tradicional, de lo que sólo miran la tupla clásica (es decir, IP origen/destino, los puertos origen y destino; y el protocolo utilizado) tiene suficiente con mirar las cabeceras para tener toda la información necesaria para realizar su trabajo, así que estos equipos no revisan el campo de datos de los paquetes IP que gestionan. En cambio, los actuales firewalls con capacidad de seguimiento de protocolos, o lo que comercialmente se llama Next Generation Firewall, al analizar el comportamiento del protocolo necesitan analizar el campo de datos de los paquetes para tener la información necesaria. Por ejemplo, un Next Generation Firewall al gestionar el protocolo FTP permite la primera conexión al puerto 21 y luego analizará esa conexión para saber qué puerto aleatorio se ha elegido para empezar la transmisión. Así el firewall permitirá una conexión en un puerto aleatorio que, en situación normal no hubiera permitido.

Otros ejemplos clásicos son los sistemas de seguridad WAF o IDS/IPS, ya que su función es precisamente analizar las peticiones que llegan a los sistemas y revisa si las solicitudes son correctas o malintencionadas. Así que estos sistemas deben revisar el campo de datos de los paquetes y datagramas que circulan por la red.

Los proxies de navegación pueden parecer un ejemplo claro de inspección de profunda de paquetes, ya que su función es revisar las direcciones web consultadas para poder aplicar las políticas definidas por los administradores (control de acceso, categorización, etc.), su inclusión o no dentro de esta categoría en función de la arquitectura de uso. Es decir, si en nuestra empresa tenemos un proxy de navegación conocido por todos y nuestros sistemas operativos están configurados para utilizarlo, no podemos considerar que ese proxy entre dentro de la categoría ya que no se está analizando el tráfico de la red, sino que se lo enviamos conscientemente. Aquí tenemos una comunicación cliente-servidor tradicional. Si configuramos un proxy de navegación transparente que capture el tráfico sin que el cliente lo sepa, sí que entraríamos en nuestra categoría: tenemos un equipo no detectado por cliente o servidor que analiza los campos de datos y no sólo la cabecera.

Obviamente las capacidades de obtención de información de análisis los sistemas de Análisis Profundo de Paquetes son muy útiles en funciones de seguridad y, por ello, se utilizan mucho, pero la próxima vez que un comercial os cante las bondades de la Deep Packet Inspection.. preguntadle qué hace exactamente su sistema y porqué es novedoso… porque muchas veces las técnicas de recolección de datos son las mismas y lo que cambia de una solución a otra es cómo trata la información y qué hace con ella.

Descarga directa.