Mitigación de vulnerabilidades de seguridad de forma rápida y sencilla con NGINX Plus

Aquí en NGINX estamos orgullosos de que literalmente millones de organizaciones en todo el mundo confíen en nuestro software para impulsar sus sitios web y su infraestructura de entrega de aplicaciones. Teniendo en cuenta lo críticamente que nuestros usuarios dependen de NGINX, nos sorprende que admitan que no han pensado mucho en la importancia de ejecutar una versión actualizada que tenga correcciones para las vulnerabilidades de seguridad, como las vulnerabilidades y exposiciones comunes (CVE), que se han vuelto tan comunes en Internet hoy en día.

Por supuesto, no basta con pensar en protegerse contra las amenazas a la seguridad: es necesario implementar procesos bien definidos para rastrear las vulnerabilidades y poner en funcionamiento las protecciones tan pronto como estén disponibles. Es fácil subestimar el tiempo y el esfuerzo que puede llevar si uno tiene que hacerlo todo uno mismo, como es el caso del open source software. De hecho, protegerse rápida y fácilmente contra amenazas de seguridad es un beneficio que a menudo se pasa por alto del software con soporte comercial como NGINX Plus.

En este blog exploramos los desafíos de proteger el open source software y explicamos cómo NGINX Plus hace que sea mucho más rápido y fácil mitigar CVE y otras amenazas de seguridad.

Cómo abordar las vulnerabilidades del open source software

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 cumplimiento de calidad, y que solo aparezcan unos pocos durante el uso normal de la aplicación. En el peor de los casos, los errores son descubiertos por usuarios malintencionados.

Las consecuencias de los errores se agravan en gran medida cuando usted construye su pila de aplicação a partir de múltiples herramientas, lenguajes de programación y plataformas de código abierto. Debe revisar cada componente por separado para validarlo como libre de errores. Cuando se descubren errores en un open source software, es importante tener una política definida para validarlos, probarlos y (si es posible) solucionarlos.

Su política para el open source software debe incluir al menos tres procesos:

1. Revisión y pruebas periódicas
2. Seguimiento de vulnerabilidades y reporte interno de las mismas
3. Remediar vulnerabilidades de manera oportuna

Informar sobre una vulnerabilidad

Cuando se descubre una vulnerabilidad de seguridad , existe una secuencia estándar de eventos para divulgarla. El primer paso es enviar un informe detallado al autor o proveedor del software. El reportero y el autor deciden juntos cómo y cuándo revelar la vulnerabilidad, generalmente en forma de un registro en la base de datos de Vulnerabilidades y Exposiciones Comunes (CVE). Por convención, el autor tiene 90 días para resolver el asunto antes de la divulgación, pero es posible negociar más tiempo.

NGINX y CVE

Como proveedor de open source software y vendedor de software comercial, NGINX participa activamente en el proceso de informes y remediación de CVE y otras vulnerabilidades que afectan a NGINX Open Source y NGINX Plus , así como a sus otros productos comerciales (que al momento de escribir este artículo incluyen NGINX Controller [ahora F5 NGINX Management Suite ] , NGINX App Protect y NGINX Ingress Controller ) y ofertas gratuitas y de código abierto, que incluyen NGINX Service Mesh , NGINX Unit y NGINX Amplify .

Los usuarios de NGINX Open Source se benefician del hecho de que NGINX Plus se basa en él, porque estamos comprometidos con el soporte a nivel empresarial y los estándares de procesos para los clientes de NGINX Plus. Estos estándares incluyen acuerdos de nivel de servicio (SLA) con nuestros clientes que dictan los procedimientos de prueba y corrección de errores que deben cumplir los parches, tanto para el software principal, las dependencias y los módulos compatibles. Los SLA ayudan a los clientes a lograr el cumplimiento de las regulaciones, minimizando el riesgo de exposición a vulnerabilidades.

Una dificultad añadida para NGINX Open Source es que muchas tecnologías de terceros lo aprovechan y lo integran en sus productos. Los proveedores de esas tecnologías tienen sus propios procesos para revelar y corregir las vulnerabilidades del software cuando se descubren. Como analizamos en la siguiente sección , a veces hay un retraso bastante significativo entre el lanzamiento de un parche para NGINX Open Source y el lanzamiento de un parche correspondiente para tecnologías de terceros.

Cómo NGINX Plus protege a los suscriptores contra vulnerabilidades

En la introducción mencionamos que un beneficio de NGINX Plus que a menudo se pasa por alto es cómo hace que sea más rápido y más fácil para nuestros clientes protegerse de las vulnerabilidades. Lidiar con las vulnerabilidades del open source software puede llevar mucho más tiempo (y, por lo tanto, resultar más costoso) de lo que mucha gente cree.

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

NGINX informa de forma proactiva a los suscriptores de NGINX Plus sobre los parches

Cuando lanzamos un parche de seguridad para NGINX Open Source y NGINX Plus, informamos de manera proactiva a los clientes de NGINX Plus por correo electrónico. También publicamos un blog anunciando la disponibilidad de la mayoría de los parches, pero no tenemos forma de llegar directamente a los usuarios de NGINX Open Source. Esto les impone la carga de monitorear los CVE y otras bases de datos de vulnerabilidades y de revisar nuestro blog regularmente.

F5 SIRT proporciona ayuda en tiempo real a los suscriptores de NGINX Plus bajo 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 (SIRT) de F5 está allí para brindar asistencia en tiempo real. El SIRT trabaja rápidamente para mitigar ataques de manera efectiva y permitirle volver a funcionar. Siguen trabajando con usted incluso después de que el ataque se detiene: “miran más allá del incidente informado para reducir el daño general a su organización, así como para comprender, anticipar y disuadir amenazas futuras”.

NGINX App Protect mejora la protección de las aplicação

NGINX App Protect es un firewall de aplicação web (WAF) de nivel empresarial impulsado por los 20 años de experiencia en seguridad de F5 e implementado como un módulo dinámico NGINX Plus. Aumenta la seguridad de capa 7 de NGINX Plus con protección específica de la aplicação contra incluso más CVE en sus servidores de aplicação backend. NGINX y F5 se comprometen a proporcionar firmas relacionadas con campañas de ataque específicas. ¿El resultado? NGINX App Protect libera a los suscriptores de NGINX Plus de crear sus propias firmas y de lidiar con múltiples falsos positivos.

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

Incluso en ausencia de vulnerabilidades específicas que requieran parches, los protocolos de autenticación sofisticados ayudan a evitar que actores maliciosos 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 API .

Los suscriptores de NGINX Plus reciben parches de inmediato

Como se describe en Informar una vulnerabilidad , cuando una vulnerabilidad afecta al software NGINX, generalmente recibimos una notificación antes de que se divulgue públicamente como una CVE. La advertencia previa nos permite preparar un parche antes de la divulgación pública y generalmente lanzamos el parche el día de la divulgación (o dentro de unos días en algunos casos). La solución está disponible para los clientes de NGINX Plus en forma de binarios parcheados. Está disponible para los usuarios de NGINX Open Source en forma de código fuente corregido y binarios parcheados para los sistemas operativos compatibles, pero como se indicó anteriormente, no tenemos forma de informar directamente a los usuarios de NGINX Open Source.

Es posible que las tecnologías de terceros que aprovechan o integran NGINX Open Source no se den cuenta de la vulnerabilidad antes de su divulgación. Incluso si lo hacen, nuestra experiencia es que sus parches pueden demorar varios meses con respecto al parche NGINX. Esto es comprensible, especialmente para el open source software , que a menudo es mantenido por voluntarios, pero deja su infraestructura desprotegida y sujeta a la explotación por parte de piratas informáticos después de que la vulnerabilidad se revela públicamente.

A modo de ejemplo, en el otoño de 2018 se descubrieron dos CVE sobre vulnerabilidades con HTTP/2 ( CVE-2018-16843 y CVE-2018-16844 ). Aplicamos parches de seguridad a NGINX Plus R16 y NGINX Open Source 1.15.6 en respuesta. El popular software OpenResty, basado en NGINX de código abierto para ofrecer algunas de las funciones de NGINX Plus, publicó por primera vez una versión candidata que incorporaba estos parches el 3 de marzo de 2019 , cuatro meses después del parche de NGINX. Las soluciones basadas en OpenResty suelen tardar aún más en aplicar parches a su código base.

A veces, el estado de una vulnerabilidad no está claro o el proveedor de software no cree que sea necesario un parche incluso si constituye un vector de ataque potencial. Una situación similar ocurrió durante 2020 con ModSecurity, el software WAF de código abierto más utilizado. El equipo que mantiene el conjunto de reglas centrales (CRS) de OWASP ModSecurity descubrió que la forma en que ModSecurity v3 realiza la coincidencia global de expresiones regulares puede resultar en lo que el equipo de CRS de OWASP considera una vulnerabilidad de denegación de servicio ( CVE-2020-15598 ). La organización que mantiene ModSecurity, Trustwave, negó que el comportamiento sea un problema de seguridad y se negó a emitir un parche.

NGINX ModSecurity WAF es un módulo dinámico para NGINX Plus creado en ModSecurity v3. El equipo de NGINX decidió que el comportamiento descrito en CVE-2020-15598 tenía suficiente potencial para causar una vulnerabilidad DoS, por lo que emitimos un parche en septiembre de 2020. Como explicamos en el blog que anuncia el parche , los usuarios de una compilación de ModSecurity de código abierto (que incluye a los usuarios de NGINX de código abierto) deben decidir por sí mismos si aplican el parche del equipo de OWASP CRS o se quedan con el software sin parchear de Trustwave y posiblemente implementan los cambios de mitigación propuestos por Trustwave.

[ Editor – NGINX ModSecurity WAF oficialmente dejó de venderse el 1 de abril de 2022 y está en transición al fin de su vida útil a partir del 31 de marzo de 2024 . Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición al final de su vida útil<.htmla> en nuestro blog.]

CONCLUSIÓN

En el panorama empresarial cada vez más competitivo de hoy, los equipos de software están bajo presión para entregar código nuevo y actualizado lo más rápido posible para brindar los servicios más innovadores. Al mismo tiempo, el aumento de ataques sofisticados a la infraestructura y las aplicações hace que sea vital rastrear las vulnerabilidades y mitigarlas lo antes posible, una práctica tediosa y que consume mucho tiempo.

Una suscripción a NGINX Plus alivia esa carga, lo que permite a los equipos de aplicação concentrarse en su misión principal (entregar código más rápido) mientras la organización permanece protegida de las vulnerabilidades de seguridad.

Pruebe usted mismo todas las funciones avanzadas de NGINX Plus: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .