Cómo defenderse contra ataques DDos

Si buscas en línea ataques DDoS (Denegación de servicio distribuido), te sorprenderá lo comunes que se han vuelto. El 2018 vio el mayor ataque DDoS registrado hasta la fecha a Github a 1.35Tbps; Afortunadamente, solo afectó la disponibilidad de su servicio durante unos diez minutos. El Ferrocarril Danés fue menos afortunado cuando un DDoS bloqueó su sistema de boletos por dos días, afectando a unos 15,000 pasajeros.

Existen muchas compañías con servicios y software diseñados para combatir los ataques DDoS y proteger tu sitio. Sin embargo, confiar únicamente en estas empresas no es suficiente. Especialmente contra un ataque DDoS en la capa de aplicación, donde las solicitudes que llegan se parecen al tráfico normal de tu sitio.

Te mostraré cinco áreas donde los ingenieros de software pueden desarrollar resiliencia en sus aplicaciones y servicios para defenderse mejor contra un ataque. Estas áreas son:

  • Cómo confiar en tu tráfico
  • Tasa limitando tus peticiones
  • Comprobación de límites de tus API
  • La importancia de una estrategia efectiva de interruptores.
  • Ser rápido de reparar

¿Qué es un ataque DDoS?

Una Denegación de Servicio Distribuida (DDoS) es un ataque dirigido a un sitio web o dispositivo donde se envía un flujo de tráfico malicioso desde múltiples fuentes.

Su objetivo es abrumar y degradar el sitio para que quede inutilizable. Hay muchos tipos diferentes de ataques DDoS. En este post, nos centraremos en el ataque a la capa de aplicación (HTTP flood).

Los atacantes buscan explotar las vulnerabilidades en tus páginas web y las interfaces de programación de aplicaciones (API) mediante el hacking de scripts o el uso de herramientas disponibles en Internet.

Para un sitio de comercio electrónico, el costo de tal ataque puede costar miles o incluso millones de dólares. Después de que derriben o degraden un sitio, algunos atacantes enviarán un correo electrónico de extorsión con una demanda de un pago en bitcoin para desactivar el ataque.

El siguiente diagrama muestra un mapa mundial de un ataque DDoS real que tuvo lugar recientemente en Vrbo. Los puntos muestran la naturaleza distribuida de donde se originó el ataque, el tamaño del punto representa el volumen del tráfico que se enviaba.

¿Qué pueden hacer los ingenieros?

Si bien los ingenieros de redes y seguridad están ocupados detectando y bloqueando anomalías en el borde de la red, tienen el difícil trabajo de mantener un buen tráfico.

Si tienes a cargo un sitio de comercio electrónico, no quieres bloquear accidentalmente a un cliente potencial para que no realice una compra en tu sitio. Ahí es donde los ingenieros de software pueden ayudar incorporando capas adicionales de resistencia en sus aplicaciones y servicios.

Debes esperar que cierta cantidad de tráfico malicioso pase a través de tu capa perimetral hacia tus capas de aplicación, servicio y base de datos. Cuando lo hagan, ¿puedes decir con seguridad que las aplicaciones y servicios críticos de tu sitio resistirán un ataque? Aquí hay cinco áreas donde los ingenieros pueden desarrollar una mayor capacidad de recuperación en su software.

1. Confiar en el tráfico correcto

Confiar en el tráfico de tu red es algo que generalmente se hace en la capa perimetral o en la puerta de enlace de la API. Cuando ocurre un ataque, tus equipos de red y del perímetro deben bloquear el tráfico ofensivo mediante direcciones de Protocolo de Internet (IP) y/o Números de sistema autónomo (ASN).

Pero esto puede agregar un riesgo comercial significativo si bloqueas el tráfico bueno con el malo. Para combatir esto, debes poder asignar el tráfico de tu red a los indicadores clave de rendimiento (KPI) de tu negocio. Cuando enriqueces tus eventos KPI con los datos de tráfico de red correspondientes, ahora puedes calificar cada combinación de ASN/IP según el valor comercial que aporta a tu empresa.

Si un atacante DDoS está utilizando una combinación ASN/IP con la que sabes que ha hecho poco o ningún negocio, puedes confiar en que el bloqueo de esta combinación de direcciones no debería afectar a tu empresa.

2. Limitar la tasa de tus solicitudes

Cuando estás bajo ataque, puedes escalar tu sistema elásticamente para manejar la carga incrementada. ¿Pero qué pasa si estás viendo cargas aumentadas por 10, 100 o 1000? En algún momento, sería bueno poder limitar las solicitudes entrantes de REST y Ajax, devolviendo la respuesta HTTP 429 (demasiadas solicitudes) cuando estás bajo presión.

Hay muchos casos de uso para el tráfico que limita la velocidad, pero cuando se trata de personas anónimas, esto se vuelve difícil. Utilizando tokens (como JWT) es una forma de aceptar una solicitud o limitar la frecuencia de la solicitud con un HTTP 429.

En última instancia, la limitación de la tasa se reduce a controlar las solicitudes altas por segundo, pero ¿cómo puedes medir tus solicitudes para administrar los tokens? La estrategia de limitación de velocidad que elijas depende de tus casos de uso individuales y de los datos disponibles con la solicitud.

Algunas formas comunes de medir la limitación de tu tasa son:

  • Usuarios conocidos vs clientes anónimos
  • Sesión
  • Solicitudes de fuerza bruta con identificadores o parámetros no válidos
  • Identificadores de red tales como IP’s /ASN’ss
  • Por cliente o a nivel de cuenta.
  • Por clasificacion bot

Este no es un sistema infalible, pero puede ser una buena herramienta defensiva para tener a tu disposición.

Advertencia:

La limitación de la tasa puede afectar tu negocio, por lo que no es necesario mantenerla activada en todo momento. Intenta utilizar configuraciones de tiempo de ejecución o incluso tu framework de prueba A/B para habilitar la limitación de velocidad rápidamente cuando estás bajo ataque.

Finalmente, con la creciente popularidad de las tecnologías de simplificación de API front-end como GraphQL y Falcor, cada solicitud de cliente puede ampliarse a N solicitudes en el servidor. Esto destaca la importancia de asegurar y limitar la velocidad de estos puntos finales.

3. Verificar los límites de tus API’s

¿Estás comprobando los límites de tus API’s contra posibles píldoras venenosas? Los valores numéricos, los numerales y los rangos de fechas se pueden usar para controlar los comportamientos de bucle y las consultas grandes en tus aplicaciones y servicios.

Basarse únicamente en las interfaces de usuario para aplicar la validación de campo no es suficiente. Hace unos años, un atacante saltó una interfaz de usuario y envió un Integer.MAX_VALUE para un campo particular, que equivale a un valor de 2,147,483,647.

Un valor de negocio válido para esta funcionalidad oscila de 1 a 100. Estos 2 mil millones de enteros se transfirió a cinco capas en el código de servicios internos, en el que maximizó la memoria en varios nodos y degradó parte del sitio hasta que no se pudo utilizar. Esto terminó siendo una solución de código muy simple, pero destaca la importancia de verificar los límites de tus API´s internas. La seguridad de Eggshell para las API’s internas no es suficiente para limitar a un atacante que explota tu sistema con valores sin sentido. Siempre debes adoptar una mentalidad de defender un ataque en capas.

4. Utilizar una estrategia de interruptor eficaz

Tener una estrategia de interruptor automático para la resiliencia a menudo se pasa por alto. En mi carrera anterior como electricista, evitaría mezclar circuitos eléctricos para diferentes casos de uso.

Por ejemplo, un refrigerador siempre tenía su propio circuito dedicado, separado de las tomas de corriente generales. En el caso de que algo en una toma de corriente general dispare su interruptor, el refrigerador no se verá afectado y su contenido no se estropeará.

Se pueden usar estrategias similares cuando se trata de interruptores automáticos como Hystrix en tus servicios. Algunas cosas a considerar incluyen:

  • ¿Cuál es la experiencia del usuario cuando se activan los interruptores de servicio?
  • ¿Qué otros servicios se ven afectados cuando se activa el interruptor?
  • ¿Cuál es tu estrategia de retroceso o acción correctiva?
  • ¿Es tu interruptor lo suficientemente distribuido para limitar el impacto?
  • ¿Estás midiendo con qué frecuencia se activan tus interruptores automáticos?

En un ataque DDoS reciente, un interruptor automático para un servicio que activó una API crítica para un cliente conectado externamente se disparó. Solo un cliente fue atacado, pero desafortunadamente, todos los socios se vieron afectados cuando se disparó el interruptor.

Tener una estrategia de interruptor más detallado en este caso hubiera resultado en una mejor experiencia para el usuario, limitando el radio de explosión.

5. Ser rápido para reparar

No puedo enfatizar la importancia de tener una arquitectura moderna CICD (integración continua, implementación continua) para defenderse de los ataques DDoS.

Cuando tu sitio está bajo ataque, solo entonces podría ser obvio que se necesita un parche rápido para combatir la avalancha de solicitudes.

Lo último que deseas es una solución simple que demorará horas o días en implementarse en producción, lo que lo obligará a superar el ataque. No creo que haya mucho más que decir sobre este tema, aparte de subrayar la importancia del software que puede ser “rápido de solucionar”.

Conclusiones

No se trata de si ocurrirá, sino de cuándo sufrirás un ataque DDoS en tu sitio web. No está bien dejarlo solo en manos de la red y los equipos de seguridad para defenderte del ataque en el perímetro.

Es responsabilidad de los equipos de ingeniería de aplicaciones y servicios crear capas adicionales de resistencia en tu arquitectura. Algunas áreas donde los ingenieros pueden concentrarse para disminuir el impacto en un ataque son:

  1. Confiar en el tráfico midiéndolo contra KPI’s de negocios
  2. La tasa que limita las peticiones cuando estás bajo ataque
  3. Verificación de límites de tus API´s contra las píldoras venenosas
  4. Implementar una estrategia efectiva de interruptor
  5. Siempre debes ser rápido para reparar

Cuando los ingenieros asumen la responsabilidad de defender tu arquitectura contra un ataque DDoS, hacen que el impacto de cualquier ataque sea menos efectivo. Recuerda que una defensa en capas es la mejor defensa.