Esta entrada de blog se centra en una vulnerabilidad relacionada con el protocolo HTTP/2 que se ha descubierto recientemente. En determinadas condiciones, esta vulnerabilidad puede aprovecharse para llevar a cabo un ataque de denegación de servicio contra NGINX Open Source, NGINX Plus y otros productos relacionados que implementan la parte del servidor de la especificación HTTP/2. Para proteger sus sistemas frente a este ataque, recomendamos actualizar de inmediato la configuración de NGINX.
El problema de los reinicios de flujo de HTTP/2
Tras establecer una conexión con un servidor, el protocolo HTTP/2 permite a los clientes iniciar flujos simultáneos para intercambiar datos. A diferencia de las versiones anteriores del protocolo, si un usuario final decide abandonar la página o detener el intercambio de datos por cualquier otro motivo, HTTP/2 ofrece un método para cancelar el flujo. Para ello, envía una trama RST_STREAM al servidor, evitando que este realice trabajo innecesario.
La vulnerabilidad se explota iniciando y cancelando rápidamente un gran número de flujos HTTP/2 a través de una conexión establecida, eludiendo así el límite máximo de flujos simultáneos del servidor. Esto ocurre porque los flujos entrantes se restablecen más rápido de lo que llegan los siguientes, lo que permite al cliente sobrecargar el servidor sin alcanzar en ningún momento el umbral configurado.
Impacto en NGINX
Por motivos de rendimiento y consumo de recursos, NGINX limita de forma predeterminada el número de flujos simultáneos a 128 (consulte http2_max_concurrent_streams). Además, para lograr un equilibrio óptimo entre el rendimiento de la red y el del servidor, NGINX permite de forma predeterminada que el cliente mantenga conexiones HTTP persistentes durante un máximo de 1000 solicitudes mediante HTTP keepalive (consulte keepalive_requests).
Al basarse en el límite predeterminado de conexiones persistentes, NGINX evita este tipo de ataque. La creación de conexiones adicionales para eludir este límite permite detectar a los actores maliciosos mediante herramientas estándar de supervisión y alerta de capa 4.
Sin embargo, si NGINX se configura con un límite de keepalive considerablemente superior al valor predeterminado y recomendado, el ataque puede agotar los recursos del sistema. Cuando se restablece un flujo, el protocolo HTTP/2 exige que no se devuelvan más datos al cliente a través de dicho flujo. Por lo general, el restablecimiento genera una sobrecarga insignificante en el servidor, derivada de las tareas que gestionan correctamente la cancelación. No obstante, eludir el umbral de flujos de NGINX permite a un cliente aprovechar esta sobrecarga y amplificarla iniciando rápidamente miles de flujos. Esto provoca un aumento brusco del uso de la CPU del servidor e impide prestar servicio a los clientes legítimos.
Denegación de servicio mediante el establecimiento de flujos HTTP/2, seguido de la cancelación de dichos flujos con límites de keepalive anormalmente altos.
Medidas para reducir la exposición a ataques
Como servidor y proxy con todas las funciones, NGINX proporciona a los administradores potentes herramientas para mitigar los ataques de denegación de servicio. Para aprovechar estas funciones, es fundamental realizar las siguientes actualizaciones en los archivos de configuración de NGINX, a fin de minimizar la superficie de ataque del servidor:
- keepalive_requests debe mantenerse en el valor predeterminado de 1000 solicitudes
- http2_max_concurrent_streams debe mantenerse en el valor predeterminado de 128 flujos
También recomendamos añadir estas medidas de seguridad como práctica recomendada:
- limit_conn limita el número de conexiones permitidas desde un único cliente. Esta directiva debe añadirse con una configuración razonable que equilibre el rendimiento de la aplicación y la seguridad.
- limit_req limita el número de solicitudes de un único cliente que se procesarán durante un periodo de tiempo determinado. Esta directiva debe añadirse con una configuración razonable que equilibre el rendimiento de la aplicación y la seguridad.
Cómo estamos respondiendo
Experimentamos con varias estrategias de mitigación que nos ayudaron a comprender cómo podría afectar este ataque a nuestra amplia variedad de clientes y usuarios. Aunque esta investigación confirmó que NGINX ya cuenta con todas las herramientas necesarias para evitar el ataque, quisimos adoptar medidas adicionales para garantizar que los usuarios que necesiten configurar NGINX más allá de las especificaciones recomendadas puedan hacerlo.
Nuestra investigación permitió desarrollar un método para mejorar la resiliencia de los servidores frente a diversas formas de ataques de inundación teóricamente posibles a través del protocolo HTTP/2. Como resultado, hemos publicado un parche que aumenta la estabilidad del sistema en estas condiciones. Para protegerse frente a estas amenazas, recomendamos que los usuarios de NGINX Open Source vuelvan a compilar los binarios a partir del código fuente más reciente y que los clientes de NGINX Plus actualicen inmediatamente a los paquetes más recientes (R29p1 o R30p1).
Cómo funciona el parche
Para garantizar la detección temprana de ataques de inundación contra NGINX, el parche limita el número de flujos nuevos que pueden iniciarse dentro de un mismo bucle de eventos. Este límite se establece en el doble del valor configurado mediante la directiva http2_max_concurrent_streams. El límite se aplicará aunque nunca se alcance el umbral máximo, como ocurre cuando los flujos se restablecen justo después de enviar la solicitud (como en el caso de este ataque).
Productos afectados
Esta vulnerabilidad afecta al módulo HTTP/2 de NGINX (ngx_http_v2_module). Para obtener información sobre el producto específico de NGINX o F5 que podría verse afectado, visite: https://my.f5.com/manage/s/article/K000137106.
Para obtener más información sobre CVE-2023-44487: ataque de restablecimiento rápido de HTTP/2, consulte: https://www.cve.org/CVERecord?id=CVE-2023-44487
Agradecimientos
Queremos reconocer la contribución de Cloudflare, Amazon y Google al descubrimiento de esta vulnerabilidad, así como su colaboración para identificarla y mitigarla.
Artículos relacionados del blog
Ú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
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
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
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 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 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.