Cómo NGINX App Protect Denial of Service se adapta a un panorama de ataques en constante evolución

NGINX | 06 de julio de 2021

A medida que trasladamos cada vez más aspectos de nuestra vida cotidiana al entorno digital, los ciberatacantes redoblan sus esfuerzos por degradar el nivel de servicio que ofrecen las aplicaciones de las que dependemos. Sus motivaciones son numerosas y van desde la venganza hasta influir en la cotización bursátil de las empresas afectadas o crear una cortina de humo que distraiga a los equipos de seguridad de las filtraciones de datos.

En una entrada anterior del blog, describimos cómo, en el pasado, los equipos de seguridad tenían que desarrollar continuamente nuevas defensas contra los ataques volumétricos de denegación de servicio (DoS) y de denegación de servicio distribuido (DDoS) en los niveles de red y transporte (capas 3 y 4), que agotan el ancho de banda disponible de los servidores inundándolos con solicitudes de conexión TCP/UDP. Ahora, los atacantes han añadido una nueva herramienta a su arsenal: ataques DoS y DDoS que utilizan solicitudes HTTP o llamadas a API para agotar los recursos en el nivel de aplicación (capa 7).

Las protecciones tradicionales contra ataques DoS volumétricos y de red no son eficaces frente a los ataques de capa 7 porque, en la capa de aplicación, las solicitudes maliciosas suelen parecerse a las legítimas. Además, los ataques HTTP de capa 7 pueden causar daños con una frecuencia y un volumen de solicitudes mucho menores que los ataques en la capa de red. La protección contra ataques DoS de capa 7 debe ser más sensible para responder a un conjunto de requisitos completamente nuevo:

  • Distinguir los ataques de los patrones de tráfico habituales
  • Evaluación del estado del servidor bajo carga
  • Determinar cuándo comenzó un ataque y si ya ha terminado
  • Mitigar los ataques sin afectar a los usuarios legítimos
  • Determinar si los cambios en el comportamiento de la aplicación se deben a un ataque o a actualizaciones de sus funcionalidades
  • Resistir un ataque prolongado sin perder eficacia de detección

NGINX App Protect Denial of Service (DoS) aborda todos estos retos para garantizar una protección frente a vulnerabilidades de día cero que sea ágil, fácil de implementar y que proporcione una configuración de políticas adaptativa y sin intervención.

Cómo se adapta NGINX App Protect DoS para detener ataques automáticamente

NGINX App Protect DoS utiliza un proceso de varios pasos para detectar y mitigar los ataques DoS de capa 7:

  1. Capturar el comportamiento habitual en un modelo estadístico del sitio
  2. Comprobar el estado del servicio
  3. Detectar una anomalía
  4. Identificar actores maliciosos y patrones de solicitudes
  5. Mitigue el ataque con una defensa multicapa

Captura del comportamiento habitual en un modelo estadístico del sitio

El primer paso del proceso consiste en registrar el comportamiento de los usuarios y de la aplicación durante un periodo en el que sabemos que el sitio no está siendo atacado, con el fin de crear un modelo estadístico del sitio que establezca una referencia del comportamiento habitual. NGINX App Protect DoS realiza un seguimiento de 320 métricas de usuarios y aplicaciones para ofrecer una visión completa de la implementación de su aplicación. Además, actualiza dinámicamente el modelo estadístico del sitio a medida que observa el tráfico. De este modo, no es necesario ajustar manualmente los umbrales del sistema y, al mismo tiempo, se garantiza que NGINX App Protect DoS tenga en cuenta los cambios en los patrones de tráfico que inevitablemente se producen con el tiempo.

Una de las categorías de métricas monitorizadas se refiere a las características de las solicitudes HTTP: el método HTTP, el valor de la cabecera «User-Agent» y otras como las que se muestran en el gráfico.

Gráficos circulares que representan la proporción de valores de las características de las solicitudes HTTP (método, valor de la cabecera User-Agent y otras 6)

Comprobación del estado del servicio

Muchas herramientas de mitigación de ataques DoS de capa 7 solo prestan atención a los patrones de tráfico de los clientes. Para mejorar la detección de ataques, también puede configurar NGINX App Protect DoS para que compruebe activamente el estado del servicio. Esta solución supervisa varias métricas de rendimiento del servidor, como el tiempo de respuesta y la proporción de solicitudes descartadas. El empeoramiento de los valores de estas métricas indica que una aplicación está «bajo presión», posiblemente debido a un ataque. El seguimiento de las métricas del servidor ofrece otra ventaja: una vez que NGINX App Protect DoS determina que hay un ataque en curso, el patrón de respuestas a las comprobaciones de estado ayuda a identificar cuándo comenzó el ataque.

Detección de una anomalía

Cuando NGINX App Protect DoS determina que se está produciendo un ataque —basándose en las desviaciones respecto al modelo estadístico del sitio y en los cambios en la respuesta del servidor (si se ha configurado)—, deja de actualizar el modelo estadístico del sitio y, en su lugar, analiza en qué medida difieren los valores actuales de las métricas respecto a los valores de referencia establecidos. Es probable que estas diferencias indiquen una anomalía global.

Identificación de actores maliciosos y patrones de solicitudes

NGINX App Protect DoS inicia entonces dos procedimientos que se ejecutan en paralelo:

  1. Analizar el comportamiento de cada usuario para detectar quién creó la anomalía o contribuyó a ella. Al principio, NGINX App Protect considera sospechosos a todos los usuarios y analiza su comportamiento. Es poco probable que todos los usuarios sean atacantes, pero medir el comportamiento de todos ellos permite a NGINX App Protect crear una representación estadística que revela quién contribuyó al ataque y quién no. Los actores maliciosos detectados se identifican mediante su dirección IP o la cabecera X-Forwarded-For de sus solicitudes.
  2. Generar una lista de reglas que describan el tráfico de ataque sin bloquear a los usuarios legítimos: firmas en tiempo real para proteger frente a ataques de día cero. Las firmas generadas durante ataques anteriores pueden reutilizarse. Las firmas generadas identifican los atributos HTTP asociados al ataque, como en este ejemplo:
http.request.method eq GET and http.user_agent contains Chrome and http.uri_parameters eq 6 and http.accept_header_exists eq false and 
http.headers_count eq 7

Mitigación del ataque mediante una defensa multicapa

El objetivo principal al defenderse de un ataque de capa 7 es detectarlo antes de que pueda causar daños.

Como se muestra en el siguiente diagrama, puede configurar una estrategia de mitigación conservadora o estándar. Con ambas estrategias, la primera capa de defensa consiste en bloquear las solicitudes de los actores maliciosos identificados en el paso anterior mediante la dirección IP y el encabezado X-Forwarded-For. La siguiente capa de defensa bloquea las solicitudes que coinciden con las firmas generadas en el paso anterior.

Por último, si ha configurado la mitigación estándar y NGINX App Protect DoS determina que las dos primeras capas de defensa son insuficientes, aplica una limitación global de la tasa de solicitudes durante un breve periodo.

NGINX App Protect DOS proporciona una defensa multicapa contra los ataques, aplicando primero medidas de mitigación conservadoras (bloqueo de direcciones IP maliciosas y firmas coincidentes) y, si es necesario, medidas de mitigación estándar (limitación de la tasa de solicitudes)

Minimización de falsos positivos durante la mitigación de ataques

Cuando NGINX App Protect DoS aplica una limitación de velocidad global, existe la posibilidad de que se bloqueen solicitudes de usuarios legítimos, lo que constituye un falso positivo. NGINX App Protect DoS puede reducir los falsos positivos basándose en el hecho de que un ataque DoS típico se lleva a cabo mediante scripts ejecutados por un controlador de botnet (malware instalado en equipos infectados), y no directamente por personas. A diferencia de los navegadores web, muchos de estos scripts sencillos no pueden gestionar correctamente una redirección HTTP, y aún menos pueden procesar JavaScript. Estas diferencias de capacidad entre los scripts y los navegadores ayudan a NGINX App Protect DoS a determinar cuál de ellos está generando el tráfico sospechoso.

Así, en lugar de limitar la tasa de solicitudes de todos los clientes, NGINX App Protect DoS envía primero una redirección HTTP y, a continuación, un fragmento de JavaScript para que se procese. Los bots automatizados no pueden responder correctamente, pero un navegador sí, lo que permite a NGINX App Protect DoS bloquear el tráfico procedente de scripts y, al mismo tiempo, permitir el tráfico de los navegadores.

Reconocemos que algunos usuarios no se sienten cómodos confiando en el aprendizaje adaptativo debido a la posibilidad de que se produzca un gran número de falsos positivos, pero hemos comprobado que es la forma más eficaz de mitigar los ataques DoS de capa 7. NGINX App Protect DoS reduce los falsos positivos combinando varios enfoques: analizar el comportamiento de los usuarios, comprobar el estado del servicio y medir la eficacia de las tácticas de mitigación. En conjunto, estos tres enfoques proporcionan una visibilidad y una protección integrales sin necesidad de modificar manualmente la configuración en respuesta a los ataques.

¿Por qué necesito protección contra ataques DoS de capa 7 si ya tengo un WAF?

Quizá se pregunte por qué necesita protección contra ataques DoS de capa 7 si su WAF ya le protege frente a los bots. Aunque es cierto que los ataques DDoS de capa 7 suelen ser lanzados por bots, su objetivo no es el mismo que el de otras actividades automatizadas. Por lo general, los bots intentan obtener información sin interrumpir el servicio, mientras que provocar dicha interrupción es precisamente el objetivo de los ataques DoS y DDoS de capa 7.

Otra diferencia es que las herramientas antibots estándar intentan distinguir entre «bots buenos» y «bots malos», una tarea compleja que suele requerir supervisión humana para evitar falsos positivos. NGINX App Protect DoS, en cambio, no tiene en cuenta si el tráfico lo generan bots u otro mecanismo, sino que se centra en distinguir entre atacantes y usuarios legítimos en función de su comportamiento. Dado que NGINX App Protect DoS solo utiliza técnicas antibots cuando ha determinado que los bots participan en un ataque DoS de capa 7, genera muchos menos falsos positivos que el software antibots estándar. Además, los métodos de mitigación de NGINX App Protect DoS hacen un uso eficiente de la CPU, lo que le permite seguir protegiendo sus aplicaciones durante todo el transcurso de un ataque DoS de capa 7.

Conclusión

NGINX App Protect DoS realiza un seguimiento de más de 320 métricas relacionadas con el comportamiento de los usuarios y las aplicaciones, lo que da lugar a un modelo estadístico multifactorial que proporciona la protección más precisa posible. Sus algoritmos exclusivos reducen considerablemente los falsos positivos. Estas funciones permiten a NGINX App Protect DoS mitigar ataques DoS altamente distribuidos, en los que cada solicitud maliciosa parece completamente legítima y un solo atacante puede incluso generar menos tráfico que el usuario legítimo medio. Gracias a su tecnología adaptativa, NGINX App Protect DoS protege las infraestructuras modernas no solo frente a los ataques actuales, sino también frente a los que evolucionen en el futuro.

Si desea obtener más información sobre cómo garantizar la protección contra ataques DoS, consulte nuestro documento sobre la solución. Consulte también estos artículos relacionados del blog:

Pruebe NGINX App Protect DoS – empiece hoy mismo una prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.


Compartir

Artículos relacionados del blog

Únete a F5 NGINX en AppWorld 2024
NGINX | 04/01/2024

Únete a F5 NGINX en AppWorld 2024

Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
NGINX | 26/09/2023

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source

La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.

Exposición de APIs en Kubernetes
NGINX | 10/03/2022

Exposición de APIs en Kubernetes

La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
NGINX | 23/08/2021

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto

Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.

Presentamos NGINX Plus R22
NGINX | 09/06/2020

Presentamos NGINX Plus R22

NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.

Presentamos NGINX Plus R17
NGINX | 11/12/2018

Presentamos NGINX Plus R17

NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.