BLOG | NGINX

Anunciamos NGINX Plus R25

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Zach Westall
Zach Westall
Publicado el 28 de septiembre de 2021

Nos complace anunciar la disponibilidad de NGINX Plus Release 25 (R25) . Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno , balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.

Las nuevas características de NGINX Plus R25 incluyen:

Cambios importantes en el comportamiento

Mayor requisito de memoria para zonas ascendentes

Como se describe en detalle en Informes más granulares de códigos de respuesta HTTP , NGINX Plus R25 proporciona recuentos de códigos de estado individuales, así como recuentos agregados por clase. Cuando NGINX Plus se configura como un proxy inverso o un balanceador de carga, es posible que sea necesario aumentar el tamaño de la zona de memoria compartida utilizada para monitorear a los “pares” ascendentes (servidores back-end), si hay más de 20 pares.

NGINX Plus R25 no se inicia si las zonas de memoria compartida están subabastecidas, lo que provoca actualizaciones fallidas. Antes de actualizar, es importante verificar la utilización de la memoria de cada zona ascendente. Para obtener instrucciones sobre cómo comprobar y ajustar la asignación de memoria, consulte Asignar suficiente memoria para evitar fallas de inicio .

Cambios en la organización y el procedimiento de instalación del repositorio NGINX Plus

Con el lanzamiento de NGINX Plus R24 , se reorganizaron los repositorios de paquetes para todo el software NGINX, lo que resultó en cambios en el procedimiento de instalación de NGINX Plus.

Cuando instala o actualiza NGINX Plus, el administrador de paquetes del sistema operativo ( apt , yum o equivalente) se configura con el repositorio de software para NGINX Plus. En los sistemas existentes configurados para usar el repositorio antiguo (aquellos que ejecutan NGINX Plus R23 o anterior), debe actualizar el administrador de paquetes para hacer referencia al nuevo repositorio. Consulte las instrucciones en la Base de conocimientos de F5 .

Si realiza una instalación inicial de NGINX Plus R25 , consulte Instalación de NGINX Plus en la Guía de administración de NGINX Plus .

Nota:  Debe utilizar el nuevo repositorio de software. El repositorio antiguo ya no se actualizará y puede causar errores en futuras instalaciones y actualizaciones.

Módulo de bandera de cookies obsoleto

Como se anunció en el lanzamiento de NGINX Plus R23 , el módulo de terceros Cookie-Flag está obsoleto y se eliminará del repositorio de módulos dinámicos en NGINX Plus R26 . La directiva set_cookie_flag definida en ese módulo se reemplaza por la directiva proxy_cookie_flags incorporada. Le recomendamos que reemplace cualquier directiva set_cookie_flag en su configuración con directivas proxy_cookie_flags lo antes posible.

Cambios en el soporte de la plataforma

  • Nuevos sistemas operativos compatibles:
    • Debian 11 (x86_64, aarch64)
    • Alpine Linux 3.14 (x86_64, aarch64)
  • Sistemas operativos más antiguos eliminados:
    • Alpine Linux 3.10; la versión compatible más antigua es la 3.11
    • Amazon Linux 1 (2018.03+); cambiar a Amazon Linux 2 LTS
    • FreeBSD 11.4+; la versión compatible más antigua es 12.1+
    • Ubuntu 16.04 LTS; la versión compatible más antigua es 18.04 LTS
  • Sistemas operativos antiguos obsoletos y programados para su eliminación en NGINX Plus R26 :
    • Alpine Linux 3.11

Nuevas funciones en detalle

Casos de uso y funcionalidades adicionales del token web JSON

NGINX Plus R24 introdujo soporte inicial para tokens web JSON (JWE) encriptados, extendiendo uno de los métodos más populares de autenticación de clientes con confidencialidad de datos. NGINX Plus R25 se basa en esa capacidad e introduce soporte para casos de uso de autenticación adicionales y más avanzados que ayudan a mejorar la seguridad de la autenticación basada en JWT para casos de uso firmados (JWS) y cifrados (JWE). Las mejoras reducen el riesgo de fuga de información personal identificable (PII) y ofrecen más flexibilidad. Las nuevas funcionalidades y mejoras de JWT para NGINX Plus incluyen:

Variable para texto cifrado JWE descifrado

Los JWT son un método ampliamente utilizado y confiable para la autenticación sin estado de solicitudes HTTP (es decir, autenticación basada en tokens). Al transmitir atributos del usuario final en la carga útil del token, los JWT ayudan a que las solicitudes sean más seguras. Sin embargo, los investigadores de seguridad y los profesionales de DevSecOps coinciden en que el riesgo que representa almacenar información de identificación personal no cifrada en clientes web es una preocupación apremiante; de ahí el desarrollo del estándar de cifrado web JSON (RFC 7516) , que proporciona pautas para implementar tokens cifrados.

NGINX Plus R24 introdujo soporte para JWE, brindando integridad y confidencialidad de datos para todo el conjunto de reclamaciones. La codificación de PII dentro del token cifrado reduce en gran medida el riesgo de fugas de datos cuando se utilizan JWT.

NGINX Plus R25 se basa en el soporte inicial de JWE con una nueva variable, $jwt_payload , que permite a NGINX Plus descifrar el JWE y el texto cifrado, y luego acceder al texto simple durante el procesamiento de la solicitud HTTP. Esta nueva funcionalidad se puede utilizar para implementar políticas avanzadas de control de acceso y decisiones de enrutamiento de solicitudes, además de permitir a los usuarios implementar NGINX Plus como una capa de descifrado JWE para aplicações backend.

Compatibilidad con JWT anidados

Los tokens JWE son eficaces para proteger la información de identificación personal (PII), y el texto cifrado sirve para preservar la confidencialidad incluso entre CDN y otros servidores proxy con terminación TLS. Pero el cifrado es un arma de doble filo, ya que los JWE pueden introducir complejidad en el entorno de la aplicação . Una forma de abordar este problema es utilizar JWT anidados.

Diagrama que muestra la estructura de un JWT anidado
Anatomía de un JWT anidado

Los JWT anidados incorporan JWS como texto cifrado de un JWE. NGINX Plus R25 permite JWT anidados como método para autenticar solicitudes HTTP al admitir JWS y JWE simultáneamente. En una sola operación, NGINX Plus ahora puede descifrar el texto cifrado en el JWE, validar el texto simple resultante como un JWS y usar las declaraciones exp (tiempo de expiración) y nbf (no antes) en el token adjunto para verificar que sea válido. Esto permite que un entorno JWS existente se actualice con cifrado de carga útil envolviéndolo en un JWE.

El siguiente fragmento de configuración ilustra el proceso. El nuevo parámetro anidado en la directiva auth_jwt_type le indica a NGINX Plus que realice tanto el descifrado JWE como la validación JWS. También afecta la forma en que se evalúan las variables de los encabezados JWT y las notificaciones JWT:

 

Con la siguiente configuración, NGINX Plus construye y envía encabezados de solicitud HTTP adicionales a la aplicação backend. El algoritmo de cifrado del encabezado JWE (la variable $jwt_header_enc ) y el reclamo del sujeto JWT de la carga útil JWS (la variable $jwt_claim_sub ) se envían con la solicitud original. Esto significa que las aplicações pueden aprovechar la autenticación basada en JWE simplemente consumiendo encabezados HTTP, sin necesidad de implementar código criptográfico o bibliotecas.

 

Para los usuarios que operan en arquitecturas de confianza cero, la siguiente configuración permite que la aplicação backend valide el token JWS tal como se captura en la variable $jwt_payload . La variable contiene la versión descifrada del texto cifrado JWE. Si hay un JWT anidado, el JWS se puede pasar a la aplicação backend como un token portador.

 

En esencia, los JWT anidados agilizan las operaciones y mejoran la seguridad de las aplicação al permitir que NGINX Plus descifre y valide simultáneamente tokens seguros, todo mientras analiza o envía por proxy el token firmado “JWT normal” para aplicações backend.

Cifrado asimétrico para JWE

NGINX Plus R24 introdujo soporte para el cifrado simétrico de tokens utilizando el estándar AES. NGINX Plus R25 agrega soporte para cifrado asimétrico al utilizar pares de claves RSA. La criptografía asimétrica utiliza claves diferentes (públicas y privadas) para el cifrado y descifrado que están vinculadas matemáticamente entre sí mediante el algoritmo RSA (Rivest–Shamir–Adleman) , el mismo mecanismo utilizado para el cifrado SSL/TLS del tráfico HTTPS entre cliente y servidor.

NGINX Plus R25 admite RSA con relleno de cifrado asimétrico óptimo (OEAP) como algoritmo de administración de claves, sin necesidad de configuración explícita en el lado de NGINX Plus. Los valores admitidos para el encabezado alg (algoritmo) JWS son RSA-OAEP , RSA-OAEP-256 , RSA-OAEP-384 y RSA-OAEP-512 .

La siguiente configuración muestra cómo todo lo que se necesita para implementar el cifrado asimétrico para JWE es especificar el archivo de clave web JSON (JWK) que contiene las claves privadas RSA (unwrap) como parámetro de la directiva auth_jwt_key_file (también se puede usar la directiva auth_jwt_key_request ).

 

Compatibilidad con JWK de múltiples fuentes

El aprovechamiento de JWT anidados significa que es probable que los JWK asociados provengan de más de una fuente. NGINX Plus R25 admite múltiples directivas auth_jwt_key_file y auth_jwt_key_request en el mismo contexto. NGINX Plus carga claves de todas las fuentes especificadas y busca la clave de verificación coincidente entre el conjunto combinado de claves, lo que resulta extremadamente útil cuando se trabaja con un JWS emitido por un proveedor de identidad externo y está anidado dentro de un JWE, donde el cifrado se realizó mediante un proceso separado.

Esta característica agrega mayor flexibilidad, seguridad y potencia a NGINX Plus implementado como puerta de enlace API.

Reglas de validación de JWT personalizadas

Cuando NGINX Plus se implementa como una puerta de enlace API, es común inspeccionar las reclamaciones JWT para implementar un control de acceso de grano fino. Esto puede dar lugar a configuraciones complejas. En versiones anteriores de NGINX Plus, se podían usar bloques de configuración if para evaluar reclamos JWT, pero este enfoque era algo limitado y no funcionaba con tokens cifrados.

NGINX Plus R25 aborda esta limitación al proporcionar una forma nativa de realizar comprobaciones adicionales en el token durante el proceso de validación JWT. La directiva auth_jwt_require agrega un paso opcional y personalizable al proceso de validación de JWT. Acepta una lista de cadenas separadas por espacios, todas las cuales deben ser no vacías y no iguales a0 (cero) para que la validación JWT tenga éxito. Esto agrega una enorme flexibilidad al proceso de validación de JWT.

El estándar JWT no prescribe qué reclamaciones son obligatorias, por lo que puede utilizar auth_jwt_require para enumerar las reclamaciones adecuadas para cada entorno.

La siguiente configuración garantiza que las reclamaciones exp y sub estén presentes en cada token.

 

Puede configurar casos de uso más complejos mediante el uso de bloques de mapas o el almacén de valores clave de NGINX Plus para pasar valores booleanos a la directiva auth_jwt_require . También puede utilizar el módulo JavaScript de NGINX para implementar soluciones de autenticación enriquecidas, como tokens de acceso vinculados a certificados de cliente TLS mutuo (mTLS) (definidos en RFC 8705 ).

La siguiente configuración realiza tanto la autenticación del certificado de cliente (mTLS) como la validación JWT. La directiva auth_jwt_require en la línea 14 exige que se evalúe la variable $thumbprint_match , y la validación JWT solo tiene éxito si tiene un valor distinto de cero. Esta variable se evalúa ejecutando la función JavaScript invocada en la línea 2.

 

Aquí está el código para la función de validación invocada en la línea 2 del fragmento anterior:

 

Informes más granulares de códigos de respuesta HTTP

La supervisión y la visibilidad son piedras angulares del rendimiento, la disponibilidad y la seguridad de las aplicação . Los códigos de respuesta HTTP son una de las fuentes de información más importantes sobre el estado de la aplicação . La API de NGINX Plus rastrea los códigos de respuesta HTTP tanto para las interacciones entre NGINX y los clientes, como entre NGINX y los servidores ascendentes; los recuentos se informan en las pestañas correspondientes del panel de monitoreo de actividad en vivo de NGINX Plus.

Las versiones anteriores de la API NGINX Plus agregaban recuentos de códigos de respuesta HTTP por clase ( 2xx , 4xx , etc.). Ahora los códigos también se cuentan individualmente ( 200,404 ,503 , etc.). Esto le brinda una visión más profunda de exactamente qué está sucediendo con una aplicação , distinguiendo entre errores que tienen causas muy diferentes, como picos en autenticaciones fallidas (403 ) y contenido faltante (404 ). Para obtener información sobre cómo configurar la recopilación de métricas, consulte la Guía de administración de NGINX Plus .

La última versión de la API NGINX Plus ( versión 7 ), lanzada con NGINX Plus R25 , incluye un objeto de códigos dentro del objeto de respuestas para permitir el conteo de códigos de respuesta HTTP individuales. Las respuestas agregadas aún están disponibles y las versiones anteriores de la API NGINX Plus (que no incluyen el objeto de códigos ) aún se pueden usar con NGINX Plus R25 . A continuación se muestra un ejemplo del nuevo conjunto de métricas:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "procesando": 31, "solicitudes": 63192, "respuestas": { "1xx": 0, "2xx": 54368, "3xx": 8454, "4xx": 330, "5xx": 9, "códigos": { "200": 54368, "302": 8454, "401": 30, "404": 200, "429": 100, "503": 9 }, "total": 63161 }, "descartado": 0, "recibido": 693436, "enviado": 13843478 }

Asignar suficiente memoria para evitar fallos de inicio

Nota importante: Cuando NGINX Plus se configura como un proxy inverso o un balanceador de carga, el conteo de códigos individuales aumenta la utilización de la memoria en la zona de memoria compartida para cada grupo ascendente. Si hay más de 20 pares en el grupo ascendente , es posible que deba aumentar el tamaño de la memoria, tal como se configura con la directiva de zona .

NGINX Plus R25 no se inicia si las zonas ascendentes tienen un suministro insuficiente, lo que provoca actualizaciones fallidas.

A continuación se muestra una configuración típica de la zona de memoria compartida para un grupo ascendente:

 

Antes de actualizar a NGINX Plus R25 , es importante que verifique la utilización de la memoria para las zonas ascendentes existentes. Para ello, asegúrese de que la API NGINX Plus esté habilitada antes de utilizar uno de estos métodos:

  • Verifique la pestaña HTTP Upstreams del panel de monitoreo de actividad en vivo, como en este ejemplo de demo.nginx.com , donde la utilización es del 54 %:

  • Utilice la API NGINX Plus directamente desde el host ejecutando el siguiente comando. Primero:

    • Instale la utilidad jq si es necesario
    • Establezca la variable API en la ubicación donde está habilitada la directiva api
    $ API=http://localhost:8080/api; para i en `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; hacer echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% usado"'; hecho

Si la utilización actual es superior al 40 % (como en la captura de pantalla), aumente el segundo parámetro (tamaño) de la directiva de zona en al menos 2,5x. Por ejemplo, recomendamos aumentar de 64k a 160k en el fragmento de configuración anterior.

Carga dinámica de certificados de cliente SSL/TLS para proxy

TLS mutuo (mTLS) es una práctica de autenticación común que implica verificar la identidad tanto del cliente como del servidor. Con NGINX Plus, puedes definir los servidores en un grupo ascendente de forma dinámica y con variables. Esto implica que es posible que también deba poder seleccionar dinámicamente el certificado TLS utilizado por NGINX Plus para verificarse en esos servidores ascendentes.

NGINX Plus R25 extiende las directivas de configuración utilizadas para mTLS a un servidor backend, para aceptar una variable que representa el certificado. La variable puede referirse a cualquiera de estos:

  • Un archivo en el disco
  • Datos en bruto en formato PEM, con el prefijo datos:

Esto permite que NGINX Plus seleccione un certificado y una clave privada de forma dinámica, lo que resulta útil para entornos de aplicação modernos que están sujetos a cambios constantes. Puede almacenar el certificado y la clave privada en el almacén de clave-valor de NGINX Plus , lo que mejora la seguridad porque la clave privada se almacena en la memoria en lugar de en el disco. Otro caso de uso es la rotación automatizada de certificados, donde se utiliza una llamada API para actualizar los certificados en el almacén de clave-valor.

En la siguiente configuración, NGINX Plus enruta las solicitudes a diferentes grupos ascendentes en función del nombre de host. La conexión mediante proxy se realiza mediante mTLS y el certificado de cliente apropiado para cada upstream se selecciona de forma dinámica.

 

Las siguientes directivas admiten la carga dinámica de certificados para mTLS con servidores ascendentes:

Seguridad reforzada para el procesamiento de solicitudes HTTP

Uno de los principios fundamentales de la filosofía NGINX es la mejora continua, especialmente en lo que respecta a la seguridad. Utilizamos todos los recursos disponibles, incluida la colaboración con investigadores de seguridad, la integración de las tecnologías de seguridad líderes en la industria de F5 en nuestros productos y esfuerzos de desarrollo internos.

Como ejemplo de esto último, NGINX Plus R25 realiza varias comprobaciones adicionales en las solicitudes HTTP para proteger sus aplicações contra posibles ataques, como el contrabando de solicitudes . Devuelve un error para estas condiciones:

  • Una solicitud HTTP/1.0 incluye el encabezado Transfer-Encoding
  • Los encabezados Transfer-Encoding y Content-Length están presentes
  • Hay espacios o caracteres de control en la línea de solicitud o en cualquier nombre de encabezado
  • Hay espacios o caracteres de control en el encabezado del Host
  • Se utiliza el método CONNECT

Además, los siguientes caracteres ahora siempre se escapan en una URI proxy: " , < , > , \ , ^ , ` , { , | , } .

Tenga en cuenta que estos cambios son mejoras de seguridad proactivas y no se realizan en respuesta a ninguna vulnerabilidad conocida.

Persistencia del estado de comprobación de estado obligatorio al recargar aplicações TCP/UDP

NGINX Plus utiliza controles de salud obligatorios para garantizar que los nuevos servidores agregados a los grupos ascendentes se prueben y funcionen correctamente antes de que las solicitudes de los clientes se les envíen. En NGINX Plus R23 y versiones anteriores, los servidores ascendentes se consideraban no saludables después de una recarga de configuración, independientemente de su estado antes de la recarga. Como resultado, NGINX Plus no envió solicitudes a un servidor hasta que se pasó la primera verificación obligatoria.

NGINX Plus R24 introdujo la persistencia opcional del estado de verificación de estado obligatorio en las recargas para aplicações HTTP. Si la última verificación de estado obligatoria antes de una recarga fue exitosa, NGINX Plus puede enviar solicitudes a un servidor inmediatamente en lugar de tener que esperar a que se realice una verificación de estado obligatoria posterior a la recarga.

NGINX Plus R25 extiende esta funcionalidad a las aplicações TCP/UDP (dentro del contexto de transmisión ). En cuanto a HTTP, agregue el parámetro persistente a la directiva health_check junto con el parámetro obligatorio .

 

Mejoras en el módulo JavaScript de NGINX

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión 0.6.2 con varias correcciones de errores y algunas mejoras funcionales que fortalecen la compatibilidad con JavaScript ES6 .

Declaración de variable con las palabras clave let y const

NGINX JavaScript ahora admite la declaración de variables con ámbito utilizando las palabras clave let y const . Las versiones anteriores de NGINX Plus y njs solo admitían la palabra clave var para declarar y asignar variables. Esto no contemplaba variables que están limitadas al alcance de una declaración de bloque particular, que son necesarias para lidiar con la complejidad que a menudo surge cuando diferentes proyectos, lenguajes de programación y equipos de ingeniería colaboran en bases de código o bibliotecas compartidas.

JavaScript ES6 proporciona las palabras claves let y const para definir variables con ámbito:

  • Las variables let están limitadas al alcance de una declaración de bloque o una expresión en la que se utilizan. Por el contrario, la palabra clave var declara una variable globalmente o localmente para una función entera, independientemente del alcance del bloque.
  • Las variables constantes tienen alcance de bloque, de forma muy similar a las variables declaradas utilizando la palabra clave let . El valor de una constante no se puede cambiar mediante reasignación y no se puede volver a declarar.

Compatibilidad con todos los métodos de construcción de promesas

Con la incorporación de los métodos constructores Promise.all() , Promise.allSettled() , Promise.any() y Promise.race() , njs ahora admite el conjunto completo de métodos constructores definidos en el estándar JavaScript ES6.

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R25 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días .

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.