Archivo de la etiqueta: DoS

Podcast – 31 – Denegación de servicio vía HTTP

En el capítulo de hoy hablaremos de las diferentes maneras en la que se puede producir un ataque de denegación de servicio a una página o servicio web usando el propio protocolo HTTP/HTTPS. Aunque es muy probable que en un ataque real se utilicen diferentes técnicas de forma simultánea, incluyendo diferentes protocolos con el objetivo de evitar las diferentes medidas de protección, en este capítulo hablaremos de un ataque puramente web.

Micro con feed

Fuente imagen:PerfectYourPodcast

Empecemos por las bases. El protocolo HTTP (HyperText Transfer Protocol) tiene tres métodos de solicitud de información en las peticiones del cliente al servidor:

  1. El método HEAD (cabecera) sirve para el cliente solicite información básica sobre una web en concreto, pero no la página en sí. Se pensó en una época de recursos muy limitados para que el cliente supiera a qué atenerse (tamaño, velocidad, etc.) antes de descargar realmente el contenido. Hoy en día es el método menos usado. Tanto las peticiones como las respuestas son ligeras.
  2. El método GET es el más habitual en la navegación: el cliente solicita un recurso y el servidor se lo entrega. El cliente envía una petición pequeña (tan sólo una cadena de texto con el URI del recurso que solicita) mientras que el servidor puede enviar una gran cantidad de información (texto HTML, imágenes. audios o incluso vídeos). La aparición de las aplicaciones web dinámicas ha hecho que en las URL de las peticiones se puedan añadir variables y parámetros que el servidor debe analizar y gestionar para modificar su respuesta en función de estos. Así nos encontramos con una petición ligera, pero con una respuesta por parte del servidor que puede, o no, ser muy pesada (tanto por tamaño de la información como por los recursos de memoria y cálculo necesarios para generarla). Se trata del método de petición más habitual.
  3. El método POST permite el envío de información desde el cliente al servidor. Sería el método utilizado para enviar la información rellenada en un formulario hacia el servidor: un ejemplo sería que al escribir un comentario en un blog el texto es enviado mediante este tipo de petición a una dirección concreta del blog para que lo trate. Lo mismo pasa cuando adjuntamos un archivo a nuestro webcorreo: el archivo adjunto viaja en una petición POST desde nuestro navegador al servidor web. En esta comunicación nos encontramos con una petición que puede ser pesada (dependerá de la información que queramos enviar) y cuya respuesta directa suele ser ligera (una confirmación de la recepción) pero que puede implicar un procesamiento elevado en la parte del servidor (pensad en los conversores de formatos de audio, vídeo, etc. que hay en Internet).

Tras este rápido repaso a los métodos de petición definidos en el protocolo HTTP y, teniendo en cuenta que lo que queremos es saturar una aplicación web de tal forma que la dejemos inaccesible de cara a los usuarios legítimos veremos qué tipos de ataques de denegación de servicio, puramente web, podemos realizar.

Tipos de ataques de denegación de servicio usando HTTP

Saturación de su línea de datos

Se trataría del ataque de denegación de servicio más tradicional y que requiere menos conocimientos técnicos.
Uno de los recursos limitados que tiene cualquier servicio web es su ancho de banda disponible para sus usuarios. Cualquier petición debe llegar desde los clientes hasta los servidores web utilizando una línea de comunicaciones, por lo que el envío de peticiones HTTP de gran tamaño o bien que generen un gran tamaño en su respuesta puede hacer que el servicio quede inaccesible.
Tradicionalmente se solía lanzar múltiples conexiones de tipo POST con una gran cantidad de información de tal forma que se pudiera saturar la conexión a Internet de los servidores. Otra forma sería realizar peticiones GET a un recurso muy pesado (un vídeo, por ejemplo) de forma que se envié muchas veces llegando a saturar su propia línea.
Como veis se trata de conseguir atascar la conexión a Internet de la aplicación web a base de generar un gran volumen de tráfico. Las tecnologías “cloud” dificultan la posibilidad de saturación de un punto único por lo que son una gran defensa frente a este tipo de ataques de fuerza bruta. Los sistemas de caché permiten la distribución de elementos no dinámicos de forma eficiente y distribuida por lo que se reducirían las posibilidades de saturación.

Saturación de los servidores

Error de servidor no disponible.

Error de servidor no disponible. Fuente imagen: eHost.com

Cambiamos el enfoque a intentar dejar inoperativos los propios servidores web. Para ello intentaremos realizar peticiones, ya sean GET o POST, que impliquen una gran carga de trabajo en el servidor. Se trata de dejarlos sin memoria o capacidad de cálculo de forma que dejen de responder a peticiones legítimas. Probablemente el ejemplo que hemos indicado antes de los conversores de formato de audio online que hemos comentado antes sea perfecto para este punto: un atacante podría solicitar muchas veces la conversión de un audio muy largo (para maximizar el consumo de su petición) de tal forma que llegue a dejar sin recursos al sistema que se verá forzado a ignorar peticiones legítimas. Este tipo de ataque requiere un mínimo de análisis de la aplicación web a atacar para descubrir cuál sería el proceso que más consume y actuar sobre él.
El reparto de trabajo entre diferentes servidores web de una misma granja permite minimizar la exposición de este tipo de ataques (ya que al aumentar la capacidad de cálculo obliga al atacante a incrementar su esfuerzo) y hoy en día la capacidad de crecimiento dinámico, y automatizado, de las plataformas cloud dificultan seriamente este tipo de ataques, aunque el hecho de que luego haya que pagar al proveedor “cloud” por el número de servidores, memoria o CPU usadas puede hacer que el hecho de aguantar el ataque y dar servicio a sus clientes no sea económicamente rentable a corto plazo. Por esto generalmente las aplicaciones web tienen una capacidad de crecimiento limitadas.

Saturación de sus propias defensas

En este escenario buscaríamos que al activar las propias defensas antidenegación (anti-DDoS, IPS, etc.) se agravara el problema o, en el caso más elaborado, se enmascarase el verdadero ataque a la aplicación web. Los sistemas IPS que analizan el tráfico HTTP deben mantener una serie de sesiones para confirmar el correcto funcionamiento y la legitimidad del tráfico por lo que también son susceptibles de ser saturados. Cuando un IPS es saturado puede generar una sobrereacción que bloquee todo el tráfico web (consiguiendo una denegación de servicio autoinflingida) o bien activar un modo pasivo donde el sistema deja de analizar el tráfico al no poder gestionarlo. Si se llega a este segundo comportamiento un atacante malicioso podría utilizar esta ventana para lanzar inyecciones SQL o exfiltrar información sin ser detectado entre todo el tráfico malicioso ‘común’. Este comportamiento puede agravarse si tratamos con tráfico seguro (HTTPS) donde el servidor IPS deba descifrar y recifrar el tráfico para poder analizarlo, consumiendo una mayor cantidad de recursos propios. Así pues, un correcto dimensionamiento de estos sistemas de defensa es muy importante.

Podcast – 31 – Denegación de servicio vía HTTP

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

Se denomina como Open DNS Resolver a aquel servidor que resolverá cualquier petición recursiva de información sin importar el origen de la misma.

DNS logo

Fuente imagen: bleepingtech.com

El funcionamiento normal del protocolo DNS indica que si recibe una petición de un dominio que desconozca buscará dicha información (pidiéndosela a sus servidores DNS de referencia) y la entrega al cliente que la ha solicitado. Esto permite que cualquier ordenador pueda conectarse a cualquier sitio del mundo aunque no lo conozca previamente. El problema del Open DNS Resolver es que un tercero, que no tiene nada que ver con nuestra empresa, puede utilizar los recursos de nuestro servidor y nuestro ancho de banda para su propio beneficio. Ya no es sólo el mero hecho de asegurar la eficiencia del servicio al eliminar un uso externo ni previsto ni autorizado, sino que pueden utilizar nuestra infraestructura como parte de un ataque a un tercero e involucrarnos sin ni siquiera tener constancia de él.

Comparativa del tamaño relativo de una petición DNS válida y su respuesta

Comparativa del tamaño relativo de una petición DNS válida y la respuesta originada, que se envía a la víctima del ataque espejo. Fuente imagen: ArsTechnica

Los ataques de denegación de servicio mediante técnicas de espejo se basan en localizar la mayor cantidad de servicios no protegidos, a los que realizar peticiones aparentemente legítimas pero con la dirección IP originaría falseada por la de la víctima que quieren atacar. En nuestro caso un atacante solicitará la resolución de un nombre de dominio extraño, solicitando el máximo de información posible, de tal manera que la respuesta se envíe a la víctima. Este equipo víctima recibiría una gran cantidad de información desde diferentes fuentes de tal forma que sufriría un ataque DDoS. Si la víctima investiga el origen del atacante únicamente encontrará a los servidores DNS utilizados pero no el causante primario del ataque.

Cómo evitar tener un servidor Open DNS Resolver

Diagrama de un ataque de espejo

Diagrama de un ataque de espejo. Fuente imagen: Wikimedia

A continuación indicaremos las principales medidas de protección para que no nuestro sistema DNS no tenga esta debilidad y evitar así que se convierta en parte de un ataque DDoS en espejo:

  1. Deshabilitar la búsqueda recursiva. Tal cómo hemos indicado el propio funcionamiento del protocolo DNS hace que las búsquedas recursivas sean necesarias por lo que deshabilitarla no parece una opción práctica en la mayoría de situaciones. Quizás sí sea interesante si los servidores DNS públicos (aquellos que dan servicios a nuestras páginas web, sitios FTP, etc.) no son utilizados por nuestros trabajadores.
  2. Bloquear las peticiones externas. Al igual que en el caso anterior bloquear las peticiones externas, vía firewall o sistema similar, sólo sería útil si los servidores DNS son de uso interno exclusivo y son diferentes a los que dan servicio público.
  3. Limitar las peticiones de resolución con recursividad. La mayoría de sistemas DNS modernos permiten limitar desde qué redes es aceptable generar peticiones que incluyan resoluciones con recursividad. Así podemos configurar nuestro sistema DNS para que acepte las peticiones de las redes internas (las generadas por nuestros usuarios) mientras que descarte aquellas que provengan de redes externas que no controlemos. En la mayoría de empresas sería suficiente con indicar que sólo se permitan las direcciones IP de rangos privados.

Si bien las dos primeras opciones evitarían el uso de nuestros sistemas (tanto servidores, como anchos de banda, confiabilidad de nuestras direcciones IP, etc.) para formar parte de estos ataques es preferible configurar siempre las redes de confianza para realizar resoluciones con recursividad de tal forma que aunque debido a un fallo de configuración los servidores DNS quedarán expuestos a Internet tampoco pudieran usarse.

Podcast – 13 – DoS DHCP

En el capítulo de hoy hablaré sobre el protocolo DHCP (Dynamic Host Configuration Protocol)

Micro con feed

Fuente imagen:PerfectYourPodcast

y cómo podríamos realizar un ataque de denegación de servicio (DoS – Denial of Service) gracias a sus debilidades de funcionamiento y cómo podemos proteger el servicio.

Así el capítulo de hoy se reparte en tres secciones: cómo funciona el protocolo DHCP; cuáles son sus debilidades básicas; y cómo podemos protegerlo mediante otros elementos de red.

Por si la explicación hablada sobre cómo funciona DHCP no quedase clara podéis consultar el artículo sobre DHCP Snooping para aclarar algo más la inforamción. En caso de duda sólo tenéis que pedirmelo por aquí, correo, Twitter o Telegram 😉

Aprovecho para preguntar… ¿qué echáis en falta en nuestro diccionario de términos?

Descarga directa.