Proteja sus aplicaciones gRPC frente a ataques DoS graves con NGINX App Protect DoS

La demanda de bienes y servicios por parte de los clientes durante los últimos dos años ha puesto de relieve lo crucial que es para las organizaciones poder escalar con facilidad e innovar con mayor rapidez, lo que ha llevado a muchas de ellas a acelerar la transición de una arquitectura monolítica a una nativa de la nube. Según el reciente informe de F5, El estado de la estrategia de aplicaciones 2021, el número de organizaciones que modernizaron sus aplicaciones aumentó un 133 % solo en el último año. Las aplicaciones habilitadas para la nube están diseñadas para ser modulares y distribuidas, así como para implementarse y gestionarse de forma automatizada. Aunque es posible trasladar sin más una aplicación monolítica existente, hacerlo no aporta ninguna ventaja en términos de costes o flexibilidad. La mejor forma de aprovechar el modelo distribuido que ofrecen los servicios de computación en la nube es adoptar un enfoque modular: aquí entran en juego los microservicios.

Los microservicios son un enfoque arquitectónico que permite a los desarrolladores crear una aplicación como un conjunto de servicios ligeros, estructuralmente independientes entre sí y de la plataforma subyacente. Cada microservicio se ejecuta como un proceso único y se comunica con otros servicios mediante API bien definidas y estandarizadas. Cada servicio puede ser desarrollado e implementado por un pequeño equipo independiente. Esta flexibilidad ofrece a las organizaciones mayores ventajas en términos de rendimiento, costes, escalabilidad y capacidad para innovar rápidamente.

Los desarrolladores buscan constantemente formas de aumentar la eficiencia y agilizar el despliegue de aplicaciones. Las API permiten la comunicación entre aplicaciones y proporcionan los componentes básicos para el desarrollo. Para solicitar datos a los servidores mediante HTTP, los desarrolladores web utilizaban originalmente SOAP, que envía los detalles de la solicitud en un documento XML. Sin embargo, los documentos XML suelen ser grandes, requieren una sobrecarga considerable y llevan mucho tiempo de desarrollo.

Desde entonces, muchos desarrolladores han adoptado REST, un estilo arquitectónico y un conjunto de directrices para crear API web fiables y sin estado. Una API web que cumple estas directrices se denomina RESTful. Las API web RESTful suelen basarse en métodos HTTP para acceder a recursos mediante parámetros codificados en la URL y utilizan JSON o XML para transmitir datos. El uso de API RESTful permite desarrollar aplicaciones con mayor rapidez y reducir la sobrecarga.

Los avances tecnológicos brindan nuevas oportunidades para mejorar el diseño de aplicaciones. En 2015, Google desarrolló Google Remote Procedure Call (gRPC) como un moderno framework RPC de código abierto capaz de ejecutarse en cualquier entorno. Mientras que REST se basa en el protocolo HTTP 1.1 y utiliza un modelo de comunicación de solicitud-respuesta, gRPC utiliza HTTP/2 para el transporte y un modelo de comunicación cliente-respuesta, implementado mediante búferes de protocolo (protobuf) como lenguaje de descripción de interfaces (IDL) para describir servicios y datos. Protobuf se utiliza para serializar datos estructurados y está diseñado para ofrecer simplicidad y rendimiento. gRPC es aproximadamente 7 veces más rápido que REST al recibir datos y 10 veces más rápido al enviarlos, gracias a la eficiencia de protobuf y al uso de HTTP/2. gRPC también permite la comunicación por streaming y atiende varias solicitudes simultáneamente.

Los desarrolladores consideran que crear microservicios con gRPC es una alternativa atractiva al uso de API RESTful debido a su baja latencia, su compatibilidad con varios lenguajes, su representación compacta de los datos y su transmisión en tiempo real, características que lo hacen especialmente adecuado para la comunicación entre microservicios y a través de redes de bajo consumo y ancho de banda limitado. La popularidad de gRPC ha aumentado porque facilita la creación rápida y eficiente de nuevos servicios, con mayor fiabilidad y escalabilidad, y con independencia del lenguaje tanto para los clientes como para los servidores.

Aunque la naturaleza abierta del protocolo gRPC ofrece varias ventajas, el estándar no proporciona ninguna protección frente al impacto que un ataque de denegación de servicio (DoS) puede tener en una aplicación. Una aplicación gRPC puede sufrir los mismos tipos de ataques DoS que una aplicación tradicional.

Por qué es difícil identificar un ataque DoS en una aplicación gRPC

Aunque los microservicios y los contenedores ofrecen a los desarrolladores más libertad y autonomía para lanzar rápidamente nuevas funcionalidades a los clientes, también introducen nuevas vulnerabilidades y oportunidades de explotación. Un tipo de ciberataque que ha ganado popularidad son los ataques de denegación de servicio (DoS), que en los últimos años han sido responsables de un número cada vez mayor de vulnerabilidades y exposiciones comunes (CVE), muchas de ellas causadas por una gestión inadecuada de las solicitudes gRPC. Los ataques DoS de capa 7 contra aplicaciones y API han aumentado un 20 % en los últimos años, mientras que la magnitud y la gravedad de su impacto han aumentado casi un 200 %.

Un ataque DoS suele enviar grandes cantidades de tráfico aparentemente legítimo para agotar los recursos de la aplicación y hacer que deje de responder. En un ataque DoS típico, un agente malicioso inunda un sitio web o una aplicación con tal cantidad de tráfico que los servidores se ven desbordados por todas las solicitudes, lo que provoca que se bloqueen o incluso que fallen. Los ataques DoS están diseñados para ralentizar o deshabilitar por completo equipos o redes, impidiendo que las personas que los necesitan puedan acceder a ellos. Hasta que se mitigue el ataque, los servicios que dependen del equipo o de la red —como los sitios de comercio electrónico, el correo electrónico y las cuentas en línea— no se pueden utilizar.

Cada vez observamos más ataques DoS que utilizan solicitudes HTTP y HTTP/2 o llamadas a API para atacar la capa de aplicación (capa 7), en gran medida porque los ataques de capa 7 pueden eludir las defensas tradicionales, que no están diseñadas para proteger las arquitecturas de aplicaciones modernas. ¿Por qué han pasado los atacantes de los ataques volumétricos tradicionales en las capas de red (capas 3 y 4) a los ataques de capa 7? Porque siguen el camino de menor resistencia. Los ingenieros de infraestructuras llevan años desarrollando mecanismos de defensa eficaces contra los ataques de capa 3 y capa 4, lo que facilita su bloqueo y reduce sus probabilidades de éxito. Esto hace que lanzar dichos ataques resulte más costoso, tanto en dinero como en tiempo, por lo que los atacantes han optado por otras vías.

Detectar ataques DoS en aplicaciones gRPC es extremadamente difícil, especialmente en entornos modernos donde el escalado horizontal se realiza automáticamente. Es posible que un servicio gRPC no esté diseñado para gestionar un gran volumen de tráfico, lo que lo convierte en un blanco fácil para los atacantes que buscan dejarlo fuera de servicio. Los servicios gRPC también son vulnerables a ataques de inundación HTTP/2 con herramientas como h2load. Además, los servicios gRPC pueden convertirse fácilmente en objetivos cuando el atacante aprovecha las definiciones de datos declaradas correctamente en una especificación protobuf.

Un caso habitual, aunque involuntario, de uso indebido de un servicio gRPC se produce cuando un error en un script hace que este envíe un número excesivo de solicitudes al servicio. Por ejemplo, supongamos que un script de automatización realiza una llamada a una API cuando se cumple una determinada condición, algo que sus diseñadores esperan que ocurra cada dos segundos. Sin embargo, debido a un error en la definición de la condición, el script realiza la llamada cada dos milisegundos, lo que genera una carga inesperada en el servicio gRPC de backend.

Otros ejemplos de ataques de denegación de servicio (DoS) contra una aplicación gRPC incluyen:

• La inserción de un campo malicioso en un mensaje gRPC puede provocar un fallo en la aplicación.
• Un ataque Slow POST envía solicitudes parciales en la cabecera gRPC. A la espera de que llegue el resto de la solicitud, la aplicación o el servidor mantienen abierta la conexión. El grupo de conexiones simultáneas podría llenarse, lo que provocaría el rechazo de nuevos intentos de conexión de los clientes.
• Una inundación de ajustes HTTP/2 (CVE-2019-9515), en la que el atacante envía tramas SETTING vacías al protocolo gRPC, consume los recursos de NGINX e impide que pueda atender nuevas solicitudes.

Aproveche el potencial del análisis dinámico del comportamiento de los usuarios y del sitio para mitigar los ataques DoS de gRPC con NGINX App Protect DoS

Proteger las aplicaciones frente a los ataques DoS actuales requiere un enfoque moderno. Para proteger aplicaciones complejas y adaptativas, necesita una solución que proporcione una protección dinámica y de gran precisión basada en el comportamiento de los usuarios y del sitio, que reduzca la carga de trabajo de los equipos de seguridad y, al mismo tiempo, favorezca el desarrollo rápido de aplicaciones y la ventaja competitiva.

F5 NGINX App Protect DoS es un módulo de software ligero para NGINX Plus, basado en el WAF y la protección del comportamiento líderes del mercado de F5. Diseñado para defenderse incluso de los ataques DoS de capa 7 más sofisticados, NGINX App Protect DoS utiliza algoritmos únicos para crear un modelo estadístico dinámico que ofrece aprendizaje automático adaptativo y protección automatizada. Mide continuamente la eficacia de la mitigación, se adapta a los cambios en el comportamiento de los usuarios y del sitio, y realiza comprobaciones proactivas del estado del servidor. Para obtener más información, consulte Cómo NGINX App Protect Denial of Service se adapta a la evolución del panorama de amenazas en nuestro blog.

Se proporciona análisis del comportamiento tanto para las aplicaciones HTTP tradicionales como para las cabeceras de aplicaciones HTTP/2 modernas. NGINX App Protect DoS mitiga los ataques mediante firmas y la identificación de actores maliciosos. En la fase inicial de mitigación mediante firmas, NGINX App Protect DoS analiza los atributos asociados a comportamientos anómalos para crear firmas dinámicas que, a partir de ese momento, bloquean las solicitudes que coinciden con dichos comportamientos. Si el ataque persiste, NGINX App Protect DoS pasa a la fase de mitigación de actores maliciosos.

Basándose en la detección estadística de anomalías, NGINX App Protect DoS identifica eficazmente a los actores maliciosos mediante la dirección IP de origen y las huellas digitales TLS, lo que le permite generar e implementar firmas dinámicas que identifican y mitigan automáticamente estos patrones específicos de tráfico de ataque. Este enfoque difiere del de las soluciones tradicionales contra ataques DoS disponibles en el mercado, que detectan cuándo se supera un umbral de volumen. NGINX App Protect DoS puede bloquear ataques en los que las solicitudes parecen totalmente legítimas y cada atacante puede incluso generar menos tráfico que un usuario legítimo medio.

Los siguientes paneles de Kibana muestran cómo NGINX App Protect DoS detecta y mitiga de forma rápida y automática un ataque de inundación DoS contra una aplicación gRPC.

La figura 1 muestra una aplicación gRPC que está sufriendo un ataque de inundación DoS. En el contexto de gRPC, la métrica clave son los datagramas por segundo (DPS), que se corresponden con la tasa de mensajes por segundo. En esta imagen, la curva amarilla representa el proceso de aprendizaje: cuando la predicción de DPS de referencia converge hacia el valor de DPS entrantes (en azul), NGINX App Protect ha aprendido cómo es el tráfico «normal» de esta aplicación. El fuerte aumento de los DPS a las 12:25:00 indica el inicio de un ataque. La campana de alarma roja señala el momento en que NGINX App Protect DoS determina con certeza que hay un ataque en curso e inicia las fases de mitigación.

Figura 1: Una aplicación gRPC que está sufriendo un ataque DoS

La figura 2 muestra NGINX App Protect DoS durante el proceso de detección de comportamientos anómalos y neutralización de un ataque de inundación DoS contra gRPC mediante un enfoque de mitigación por fases. El pico rojo indica el número de redirecciones HTTP/2 enviadas a todos los clientes durante la fase de mitigación global de la tasa. El gráfico morado representa las redirecciones enviadas a clientes específicos cuando sus solicitudes coinciden con una firma que modela el comportamiento anómalo. El gráfico amarillo representa las redirecciones enviadas a actores maliciosos específicos detectados e identificados mediante la dirección IP y la huella digital TLS.

Figura 2: NGINX App Protect DoS utiliza un enfoque de mitigación por fases para frustrar un ataque de inundación DoS de gRPC

La figura 3 muestra una firma dinámica creada por NGINX App Protect DoS, basada en aprendizaje automático, que perfila los atributos asociados al comportamiento anómalo de este ataque de inundación gRPC. La firma bloquea las solicitudes que coinciden con ella durante la fase inicial de mitigación mediante firmas.

Figura 3: Una firma dinámica

La figura 4 muestra cómo NGINX App Protect DoS pasa de la mitigación basada en firmas a la mitigación de agentes maliciosos cuando un ataque persiste. Mediante el análisis del comportamiento de los usuarios, NGINX App Protect DoS ha identificado a los agentes maliciosos por la dirección IP de origen y las huellas digitales TLS que se muestran aquí. En lugar de examinar cada solicitud en busca de firmas específicas que indiquen un comportamiento anómalo, se deniega el servicio a atacantes concretos. Esto permite generar firmas dinámicas que identifican estos patrones de ataque específicos y los mitigan automáticamente.

Figura 4: NGINX App Protect DoS identifica a los actores maliciosos por su dirección IP y huella digital TLS

Con las API de gRPC, se utiliza la interfaz de gRPC para establecer la política de seguridad en el archivo de la biblioteca de tipos (IDL) y en los archivos de definición proto de protobuf. Esto proporciona una solución de políticas de seguridad sin intervención: no es necesario depender de la definición de protobuf para proteger el servicio gRPC frente a ataques. Los archivos proto de gRPC se utilizan con frecuencia como parte de las canalizaciones de CI/CD, lo que permite coordinar a los equipos de seguridad y desarrollo mediante la automatización de la protección y la habilitación de la seguridad como código para una integración completa en la canalización de CI/CD. NGINX App Protect DoS garantiza una seguridad uniforme al integrar perfectamente la protección en las aplicaciones gRPC, de modo que estén siempre protegidas por las políticas de seguridad más recientes y actualizadas.

Aunque gRPC ofrece la velocidad y la flexibilidad que los desarrolladores necesitan para diseñar e implementar aplicaciones modernas, la naturaleza intrínsecamente abierta de su framework lo hace muy vulnerable a los ataques DoS. Para anticiparse a los graves ataques DoS de capa 7, que pueden provocar una degradación del rendimiento, interrupciones en aplicaciones y sitios web, pérdidas de ingresos y daños a la fidelidad de los clientes y a la marca, necesita una defensa moderna. Por eso, NGINX App Protect DoS es esencial para sus aplicaciones gRPC modernas.

Para probar NGINX App Protect DoS con NGINX Plus, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Para obtener más información, consulta nuestro informe técnico, «Protección de aplicaciones modernas frente a ataques DoS de capa 7».

---