Mitigue las vulnerabilidades de seguridad de forma rápida y sencilla con NGINX Plus

NGINX | 04 de marzo de 2021

En NGINX nos enorgullece que, literalmente, millones de organizaciones de todo el mundo confíen en nuestro software para hacer funcionar sus sitios web y su infraestructura de entrega de aplicaciones. Dada la enorme dependencia de nuestros usuarios respecto a NGINX, nos sorprende que admitan no haber reflexionado demasiado sobre la importancia de utilizar una versión actualizada que incluya correcciones para las vulnerabilidades de seguridad —como las vulnerabilidades y exposiciones comunes (CVE)— que se han vuelto tan habituales en la Internet actual.

Por supuesto, no basta con pensar en protegerse frente a las amenazas de seguridad: es necesario implementar procesos bien definidos para realizar un seguimiento de las vulnerabilidades y aplicar medidas de protección en cuanto estén disponibles. Es fácil subestimar el tiempo y el esfuerzo que esto puede requerir si tiene que hacerlo todo por su cuenta, como ocurre con el software de código abierto. De hecho, la posibilidad de protegerse frente a las amenazas de seguridad de forma rápida y sencilla es una ventaja que a menudo se pasa por alto en el software con soporte comercial, como NGINX Plus.

En este blog analizamos los retos que plantea la protección del software de código abierto y explicamos cómo NGINX Plus permite mitigar las CVE y otras amenazas de seguridad de forma mucho más rápida y sencilla.

Cómo abordar las vulnerabilidades del software de código abierto

Por mucho que a todos los desarrolladores les guste pensar que escriben código perfecto, ningún software está libre de errores. Los desarrolladores esperan que la mayoría de los errores se detecten durante el desarrollo como parte de un riguroso proceso de control de calidad y que solo unos pocos salgan a la luz durante el uso normal a lo largo de la vida útil de la aplicación. En el peor de los casos, los errores son descubiertos por usuarios malintencionados.

Las consecuencias de los errores se agravan considerablemente cuando la pila de aplicaciones se construye a partir de múltiples herramientas de código abierto, lenguajes de programación y plataformas. Es necesario revisar cada componente por separado para comprobar que no contiene errores. Cuando se descubren errores en software de código abierto, es importante contar con una política definida para validarlos, probarlos y, si es posible, corregirlos.

Tu política sobre software de código abierto debe incluir al menos tres procesos:

Revisión y pruebas periódicas
Seguimiento de vulnerabilidades y comunicación interna de estas
Corregir las vulnerabilidades de manera oportuna

Notificación de una vulnerabilidad

Cuando se descubre una vulnerabilidad de seguridad, se sigue una secuencia estándar de pasos para divulgarla. El primer paso consiste en enviar un informe detallado al autor o proveedor del software. La persona que informa de la vulnerabilidad y el autor deciden conjuntamente cómo y cuándo divulgarla, normalmente mediante un registro en la base de datos de Vulnerabilidades y Exposiciones Comunes (CVE). Por convención, el autor dispone de 90 días para resolver el problema antes de su divulgación, aunque es posible negociar una ampliación del plazo.

NGINX y las CVE

Como proveedor de software de código abierto y fabricante de software comercial, NGINX participa activamente en el proceso de notificación y corrección de CVE y otras vulnerabilidades que afectan a NGINX Open Source y NGINX Plus, así como a sus otros productos comerciales, que en el momento de redactar este documento incluyen NGINX Controller [ahora F5 NGINX Management Suite], NGINX App Protect y NGINX Ingress Controller, y a sus soluciones gratuitas y de código abierto, entre las que se incluyen NGINX Service Mesh, NGINX Unit y NGINX Amplify.

Los usuarios de NGINX Open Source se benefician de que NGINX Plus se base en él, ya que nos comprometemos a ofrecer a los clientes de NGINX Plus un soporte y unos estándares de procesos de nivel empresarial. Estos estándares incluyen acuerdos de nivel de servicio (SLA) con nuestros clientes que establecen los procedimientos de corrección de errores y pruebas que deben cumplir los parches, tanto para el software principal como para las dependencias y los módulos compatibles. Los SLA ayudan a los clientes a cumplir la normativa y minimizan el riesgo de exposición a ataques que aprovechen vulnerabilidades.

Una complicación adicional para NGINX Open Source es que muchas tecnologías de terceros lo utilizan y lo integran en sus productos. Los proveedores de esas tecnologías tienen sus propios procesos para divulgar y corregir las vulnerabilidades de software cuando se descubren. Como explicamos en la siguiente sección, a veces transcurre bastante tiempo entre la publicación de un parche para NGINX Open Source y la publicación del parche correspondiente para las tecnologías de terceros.

Cómo NGINX Plus protege a los suscriptores frente a las vulnerabilidades

En la introducción mencionamos que una ventaja de NGINX Plus que a menudo se pasa por alto es que permite a nuestros clientes protegerse frente a las vulnerabilidades de forma más rápida y sencilla. Gestionar las vulnerabilidades del software de código abierto puede requerir mucho más tiempo —y, por tanto, resultar más caro— de lo que mucha gente cree.

En las siguientes secciones analizamos cinco formas concretas en las que la resolución de vulnerabilidades resulta más rápida y sencilla para los suscriptores de NGINX Plus.

NGINX informa proactivamente a los suscriptores de NGINX Plus sobre los parches

Cuando publicamos un parche de seguridad para NGINX Open Source y NGINX Plus, informamos de forma proactiva por correo electrónico a los clientes de NGINX Plus. También publicamos una entrada en el blog para anunciar la disponibilidad de la mayoría de los parches, pero no tenemos forma de contactar directamente con los usuarios de NGINX Open Source. Por tanto, recae sobre ellos la responsabilidad de supervisar los CVE y otras bases de datos de vulnerabilidades, así como de consultar nuestro blog periódicamente.

F5 SIRT ofrece ayuda en tiempo real a los suscriptores de NGINX Plus que están sufriendo un ataque

Cuando los clientes de F5, incluidos los suscriptores de NGINX Plus, son víctimas de ataques, el Equipo de Respuesta a Incidentes de Seguridad de F5 (SIRT) está a su disposición para prestarles asistencia en tiempo real. El SIRT actúa con rapidez para mitigar eficazmente los ataques y restablecer el funcionamiento de sus sistemas. Además, sigue colaborando con usted incluso después de que el ataque haya cesado: «mira más allá del incidente notificado para reducir el daño global a su organización, así como para comprender, anticipar y disuadir futuras amenazas».

NGINX App Protect refuerza la protección de las aplicaciones

NGINX App Protect es un firewall de aplicaciones web (WAF) de nivel empresarial, respaldado por los 20 años de experiencia en seguridad de F5 e implementado como módulo dinámico de NGINX Plus. Refuerza la seguridad de capa 7 de NGINX Plus con protección específica para aplicaciones frente a aún más vulnerabilidades CVE en los servidores de aplicaciones backend. NGINX y F5 se comprometen a proporcionar firmas relacionadas con campañas de ataque específicas. ¿El resultado? NGINX App Protect evita que los suscriptores de NGINX Plus tengan que crear sus propias firmas y lidiar con numerosos falsos positivos.

NGINX Plus admite la autenticación basada en JWT y OpenID Connect

Incluso si no existen vulnerabilidades específicas que requieran parches, los protocolos de autenticación avanzados ayudan a impedir que agentes malintencionados accedan a sus aplicaciones e infraestructura. Además de los métodos disponibles en NGINX Open Source, NGINX Plus admite la autenticación basada en JSON Web Token (JWT) y OpenID Connect, tanto para clientes web como de API.

Los suscriptores de NGINX Plus reciben los parches de inmediato

Como se describe en Notificación de una vulnerabilidad, cuando una vulnerabilidad afecta al software NGINX, normalmente recibimos una notificación antes de que se divulgue públicamente como CVE. Este aviso previo nos permite preparar un parche antes de la divulgación pública y, por lo general, lo publicamos el mismo día de la divulgación (o, en algunos casos, unos días después). La corrección está disponible para los clientes de NGINX Plus en forma de archivos binarios parcheados. Para los usuarios de NGINX Open Source, está disponible en forma de código fuente corregido y archivos binarios parcheados para los sistemas operativos compatibles, pero, como se ha indicado anteriormente, no tenemos forma de informar directamente a los usuarios de NGINX Open Source.

Es posible que las tecnologías de terceros que utilizan o integran NGINX Open Source no tengan conocimiento de la vulnerabilidad antes de que se divulgue. Incluso si lo tienen, nuestra experiencia indica que sus parches pueden tardar varios meses más que el parche de NGINX. Esto es comprensible, especialmente en el caso del software de código abierto, que a menudo mantienen voluntarios, pero deja su infraestructura desprotegida y expuesta a ataques de hackers una vez que la vulnerabilidad se hace pública.

Por ejemplo, en otoño de 2018 se descubrieron dos CVE relacionados con vulnerabilidades de HTTP/2 (CVE-2018-16843 y CVE-2018-16844). Como respuesta, aplicamos parches de seguridad a NGINX Plus R16 y NGINX Open Source 1.15.6. El popular software OpenResty, que se basa en NGINX Open Source para ofrecer algunas de las funcionalidades de NGINX Plus, no publicó una versión candidata que incorporaba estos parches hasta el 3 de marzo de 2019, cuatro meses completos después del parche de NGINX. Las soluciones basadas en OpenResty suelen tardar aún más en parchear su código base.

A veces, el estado de una vulnerabilidad no está claro, o el proveedor del software no considera necesario aplicar un parche, aunque pueda constituir un posible vector de ataque. Una situación así se produjo en 2020 con ModSecurity, el software WAF de código abierto más utilizado. El equipo encargado de mantener el conjunto de reglas básicas de OWASP ModSecurity (CRS) descubrió que la forma en que ModSecurity v3 realiza la búsqueda global de coincidencias de expresiones regulares puede dar lugar a lo que el equipo de OWASP CRS considera una vulnerabilidad de denegación de servicio (CVE-2020-15598). Trustwave, la organización encargada de mantener ModSecurity, negó que este comportamiento supusiera un problema de seguridad y se negó a publicar un parche.

NGINX ModSecurity WAF es un módulo dinámico para NGINX Plus basado en ModSecurity v3. El equipo de NGINX decidió que el comportamiento descrito en CVE-2020-15598 tenía suficiente potencial para provocar una vulnerabilidad de denegación de servicio (DoS), por lo que publicamos un parche en septiembre de 2020. Como explicamos en la entrada del blog en la que anunciamos el parche, los usuarios de una compilación de código abierto de ModSecurity (incluidos los usuarios de NGINX Open Source) deben decidir por sí mismos si aplican el parche del equipo de OWASP CRS o si continúan utilizando el software sin parchear de Trustwave y, posiblemente, implementan las medidas de mitigación propuestas por Trustwave.

[Editor – NGINX ModSecurity WAF dejó de comercializarse oficialmente el 1 de abril de 2022 y está en proceso de alcanzar el fin de su vida útil, que será efectivo el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al fin de su vida útil<.htmla> en nuestro blog.]