Presentamos NGINX Plus R25

Zach WestallResponsable sénior de marketing de producto

Nos complace anunciar la disponibilidad de NGINX Plus Release 25 (R25). Basado en NGINX Open Source, NGINX Plus es la única solución de software todo en uno que funciona como servidor web, equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

Entre las nuevas funcionalidades de NGINX Plus R25 se incluyen:

• Casos de uso adicionales y más avanzados de JSON Web Token – NGINX Plus R25 amplía la compatibilidad con los JSON Web Tokens cifrados (JWE) introducida en NGINX Plus R24.
• Informes más detallados de los códigos de respuesta HTTP – La API de NGINX Plus ahora contabiliza los códigos de respuesta HTTP tanto individualmente como agrupados por clase. Es posible que tenga que aumentar la asignación de memoria; consulte Asignar memoria suficiente para evitar errores de inicio.
• Carga dinámica de certificados de cliente SSL/TLS para conexiones mediante proxy – Puede utilizar variables para seleccionar dinámicamente los certificados de las conexiones mTLS entre NGINX Plus y los servidores backend.
• Seguridad reforzada para el procesamiento de solicitudes HTTP – NGINX Plus realiza varias comprobaciones adicionales en las solicitudes HTTP para proteger sus aplicaciones frente a posibles ataques.
• Persistencia del estado de las comprobaciones de estado tras las recargas para aplicaciones TCP/UDP – Los resultados de las comprobaciones de estado obligatorias de los servidores TCP/UDP ahora pueden conservarse tras las recargas de la configuración.
• Mejoras en el módulo JavaScript de NGINX – Se ha mejorado la compatibilidad con JavaScript ES6.

Cambios importantes en el comportamiento

Mayor requisito de memoria para las zonas de servidores upstream

Como se describe en detalle en Informes más detallados de los 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 proxy inverso o equilibrador de carga, puede que sea necesario aumentar el tamaño de la zona de memoria compartida utilizada para supervisar los «pares» ascendentes (servidores backend) si hay más de 20 pares.

NGINX Plus R25 no se inicia si las zonas de memoria compartida no tienen suficiente memoria asignada, lo que provoca que las actualizaciones fallen. Antes de actualizar, es importante comprobar el uso de memoria de cada zona de servidores upstream. Para obtener instrucciones sobre cómo comprobar y ajustar la asignación de memoria, consulte Asignar suficiente memoria para evitar fallos de inicio.

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

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

Al instalar o actualizar NGINX Plus, el gestor de paquetes del sistema operativo (apt, yum o equivalente) se configura con el repositorio de software de NGINX Plus. En los sistemas existentes configurados para usar el repositorio antiguo (aquellos que ejecutan NGINX Plus R23 o una versión anterior), debe actualizar el gestor de paquetes para que apunte al nuevo repositorio. Consulte las instrucciones en la base de conocimientos de F5.

Si va a realizar 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 dejará de actualizarse y puede provocar errores en futuras instalaciones y actualizaciones.

Módulo Cookie-Flag obsoleto

Como se anunció con 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 sustituye por la directiva integrada proxy_cookie_flags. Le recomendamos que sustituya cuanto antes todas las directivas set_cookie_flag de su configuración por directivas proxy_cookie_flags.

Cambios en la compatibilidad con plataformas

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

Nuevas funciones en detalle

Casos de uso y funcionalidades adicionales de JSON Web Token

NGINX Plus R24 incorporó compatibilidad inicial con tokens web JSON cifrados (JWE), lo que añade confidencialidad de los datos a uno de los métodos de autenticación de clientes más populares. NGINX Plus R25 amplía esta capacidad e incorpora compatibilidad con casos de uso de autenticación adicionales y más avanzados que ayudan a mejorar la seguridad de la autenticación basada en JWT, tanto para tokens firmados (JWS) como cifrados (JWE). Estas mejoras reducen el riesgo de filtración de información de identificación personal (PII) y ofrecen una mayor flexibilidad. Las nuevas funciones y mejoras de JWT para NGINX Plus incluyen:

• Una nueva variable para el texto cifrado JWE descifrado
• Compatibilidad con JWT anidados
• Cifrado asimétrico para JWE
• Compatibilidad con claves web JSON de múltiples fuentes
• Reglas de validación de JWT personalizadas adicionales

Variable para el texto cifrado JWE descifrado

Los JWT son un método ampliamente utilizado y fiable para la autenticación sin estado de solicitudes HTTP (es decir, la autenticación basada en tokens). Al transmitir los atributos del usuario final en la carga útil del token, los JWT ayudan a aumentar la seguridad de las solicitudes. Sin embargo, los investigadores de seguridad y los profesionales de DevSecOps coinciden en que el riesgo que supone almacenar información de identificación personal (PII) sin cifrar en clientes web es una preocupación acuciante; de ahí el desarrollo del estándar JSON Web Encryption (RFC 7516), que proporciona directrices para implementar tokens cifrados.

NGINX Plus R24 incorporó compatibilidad con JWE, lo que garantiza la integridad y la confidencialidad de los datos de todo el conjunto de declaraciones. Codificar la PII en el token cifrado reduce considerablemente el riesgo de filtraciones de datos al utilizar JWT.

NGINX Plus R25 amplía la compatibilidad inicial con JWE mediante una nueva variable, $jwt_payload, que permite a NGINX Plus descifrar el JWE y el texto cifrado y, a continuación, acceder al texto sin cifrar durante el procesamiento de la solicitud HTTP. Esta nueva funcionalidad puede utilizarse para implementar políticas avanzadas de control de acceso y tomar decisiones de enrutamiento de solicitudes, además de permitir a los usuarios desplegar NGINX Plus como capa de descifrado de JWE para aplicaciones de backend.

Compatibilidad con JWT anidados

Los tokens JWE protegen eficazmente la información de identificación personal (PII), ya que el texto cifrado permite preservar la confidencialidad incluso al atravesar redes de distribución de contenidos (CDN) y otros proxies que terminan conexiones TLS. Sin embargo, el cifrado es un arma de doble filo, pues los JWE pueden añadir complejidad al entorno de la aplicación. Una forma de abordar este problema es utilizar JWT anidados.

Anatomía de un JWT anidado

Los JWT anidados incorporan un JWS como texto cifrado de un JWE. NGINX Plus R25 permite utilizar JWT anidados como método para autenticar solicitudes HTTP, ya que admite JWS y JWE simultáneamente. En una sola operación, NGINX Plus ahora puede descifrar el texto cifrado del JWE, validar el texto sin cifrar resultante como un JWS y utilizar las declaraciones exp (tiempo de expiración) y nbf (no antes de) del token incluido para comprobar que es válido. Esto permite actualizar un entorno JWS existente con cifrado de la carga útil envolviéndolo en un JWE.

El siguiente fragmento de configuración ilustra el proceso. El nuevo parámetro «nested» de la directiva «auth_jwt_type» indica a NGINX Plus que debe realizar tanto el descifrado de JWE como la validación de JWS. También afecta a la forma en que se evalúan las variables de las cabeceras y las declaraciones de JWT:

• La directiva auth_jwt_header_set opera sobre las cabeceras JWE externas.
• La directiva «auth_jwt_claim_set» actúa sobre las declaraciones del JWS anidado.
• $jwt_header_name contienen las propiedades del encabezado JWE externo.
• $jwt_claim_name contienen las declaraciones JWS anidadas.

Cargando ejemplo de código…

Con la siguiente configuración, NGINX Plus crea y envía cabeceras de solicitud HTTP adicionales a la aplicación de backend. El algoritmo de cifrado de la cabecera JWE (la variable $jwt_header_enc) y la declaración de sujeto del JWT incluida en la carga útil JWS (la variable $jwt_claim_sub) se reenvían junto con la solicitud original. Esto permite que las aplicaciones aprovechen la autenticación basada en JWE simplemente procesando cabeceras HTTP, sin necesidad de implementar código criptográfico ni bibliotecas.

Cargando ejemplo de código…

Para los usuarios que trabajan con arquitecturas de confianza cero, la siguiente configuración permite que la aplicación de backend valide el token JWS almacenado en la variable $jwt_payload. La variable contiene la versión descifrada en texto sin formato del texto cifrado JWE. Si hay un JWT anidado, el JWS puede enviarse a la aplicación de backend como token de portador.

Cargando ejemplo de código…

En esencia, los JWT anidados agilizan las operaciones y mejoran la seguridad de las aplicaciones, ya que permiten que NGINX Plus descifre y valide simultáneamente tokens seguros, a la vez que analiza o reenvía mediante proxy el token firmado «JWT convencional» a las aplicaciones de backend.

Cifrado asimétrico para JWE

NGINX Plus R24 incorporó compatibilidad con el cifrado simétrico de tokens mediante el estándar AES. NGINX Plus R25 añade compatibilidad con el cifrado asimétrico mediante pares de claves RSA. La criptografía asimétrica utiliza claves diferentes (pública y privada) para el cifrado y el descifrado, 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 el cliente y el servidor.

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

La siguiente configuración muestra que, para implementar el cifrado asimétrico de JWE, basta con especificar como parámetro de la directiva auth_jwt_key_file el archivo JSON Web Key (JWK) que contiene las claves RSA privadas (de desenvoltura); también se puede utilizar la directiva auth_jwt_key_request).

Cargando ejemplo de código…

Compatibilidad con JWK de múltiples fuentes

El uso de JWT anidados implica que es probable que los JWK asociados procedan de más de una fuente. NGINX Plus R25 admite varias directivas auth_jwt_key_file y auth_jwt_key_request en el mismo contexto. NGINX Plus carga las claves de todas las fuentes especificadas y busca la clave de verificación correspondiente en el conjunto combinado de claves, lo que resulta extremadamente útil cuando se trabaja con un JWS emitido por un proveedor de identidades externo y anidado dentro de un JWE cuyo cifrado se realizó mediante un proceso independiente.

Esta funcionalidad aporta aún más flexibilidad, seguridad y potencia a NGINX Plus cuando se implementa como puerta de enlace de API.

Reglas personalizadas de validación de JWT

Cuando NGINX Plus se implementa como puerta de enlace de API, es habitual inspeccionar las declaraciones JWT para aplicar un control de acceso detallado. Esto puede dar lugar a configuraciones complejas. En versiones anteriores de NGINX Plus, se podían utilizar bloques de configuración if para evaluar las declaraciones JWT, pero este enfoque era algo limitado y no funcionaba con tokens cifrados.

NGINX Plus R25 soluciona esta limitación al proporcionar una forma nativa de realizar comprobaciones adicionales en el token durante el proceso de validación de JWT. La directiva «auth_jwt_require» añade un paso opcional y personalizable al proceso de validación de JWT. Acepta una lista de cadenas separadas por espacios, todas las cuales deben contener algún valor y ser distintas de 0 (cero) para que la validación de JWT se realice correctamente. Esto aporta una enorme flexibilidad al proceso de validación de JWT.

El estándar JWT no establece qué declaraciones son obligatorias, por lo que puede utilizar auth_jwt_require para indicar las declaraciones adecuadas para cada entorno.

La siguiente configuración garantiza que las declaraciones exp y sub estén presentes en todos los tokens.

Cargando ejemplo de código…

Puede configurar casos de uso más complejos mediante bloques map o el almacén de clave-valor 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 avanzadas, como tokens de acceso vinculados a certificados de cliente de TLS mutuo (mTLS), definidos en la RFC 8705.

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

Cargando ejemplo de código…

Este es el código de la función validate invocada en la línea 2 del fragmento anterior:

Cargando ejemplo de código…

Informes más detallados sobre los códigos de respuesta HTTP

La monitorización y la visibilidad son pilares fundamentales del rendimiento, la disponibilidad y la seguridad de las aplicaciones. Los códigos de respuesta HTTP constituyen una de las fuentes de información más importantes sobre el estado de las aplicaciones. La API de NGINX Plus realiza un seguimiento de los códigos de respuesta HTTP tanto en las interacciones entre NGINX y los clientes como entre NGINX y los servidores ascendentes; los recuentos se muestran en las pestañas correspondientes del panel de monitorización de la actividad en tiempo real de NGINX Plus.

Las versiones anteriores de la API de NGINX Plus agrupaban los recuentos de códigos de respuesta HTTP por clase (2xx, 4xx, etc.). Ahora los códigos también se contabilizan individualmente (200, 404, 503, etc.). Esto permite comprender con mayor precisión qué ocurre exactamente con una aplicación y distinguir entre errores con causas muy diferentes, como picos de autenticaciones fallidas (403) y contenido no encontrado (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 versión más reciente de la API de NGINX Plus (versión 7), publicada con NGINX Plus R25, incluye un objeto codes dentro del objeto responses que permite contabilizar individualmente los códigos de respuesta HTTP. Las respuestas agregadas siguen estando disponibles y las versiones anteriores de la API de NGINX Plus, que no incluyen el objeto codes, se pueden seguir utilizando con NGINX Plus R25. Este es un ejemplo del nuevo conjunto de métricas:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

Asigne suficiente memoria para evitar fallos de inicio

Nota importante: Cuando NGINX Plus se configura como proxy inverso o equilibrador de carga, el recuento de códigos individuales aumenta el uso de memoria en la zona de memoria compartida de cada grupo de servidores ascendentes. Si hay más de 20 servidores en el grupo de servidores ascendentes, puede que sea necesario aumentar el tamaño de la memoria, según lo configurado mediante la directiva zone.

NGINX Plus R25 no se inicia si las zonas de upstream no tienen suficiente capacidad asignada, lo que provoca errores en las actualizaciones.

Esta es una configuración típica de la zona de memoria compartida para un grupo de servidores upstream:

Cargando ejemplo de código…

Antes de actualizar a NGINX Plus R25, es importante comprobar el uso de memoria de las zonas de servidores upstream existentes. Para ello, asegúrese de que la API de NGINX Plus esté habilitada antes de utilizar uno de estos métodos:

• Compruebe la pestaña «Upstreams HTTP» del panel de monitorización de la actividad en tiempo real, como en este ejemplo de demo.nginx.com, donde la utilización es del 54 %:
  
• Utilice la API de NGINX Plus directamente desde el host ejecutando el siguiente comando. Primero:

$ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done

• Instala la utilidad jq utility si es necesario
• Establezca la variable API en la ubicación donde esté habilitada la directiva api directive is enabled

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

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

TLS mutuo (mTLS) es una práctica de autenticación habitual que consiste en verificar la identidad tanto del cliente como del servidor. Con NGINX Plus, puede definir los servidores de un grupo de servidores ascendentes de forma dinámica y mediante variables. Esto implica que quizá también necesite seleccionar dinámicamente el certificado TLS que utiliza NGINX Plus para autenticarse ante esos servidores ascendentes.

NGINX Plus R25 amplía las directivas de configuración utilizadas para mTLS con un servidor backend, de modo que acepten una variable que represente el certificado. La variable puede hacer referencia a cualquiera de los siguientes elementos:

• Un archivo en el disco
• Datos sin procesar en formato PEM, con el prefijo data:

Esto permite que NGINX Plus seleccione dinámicamente un certificado y una clave privada, lo que resulta útil para entornos de aplicaciones modernos sujetos a cambios constantes. Puede almacenar el certificado y la clave privada en el almacén de pares clave-valor de NGINX Plus, lo que mejora la seguridad, ya que 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, en la que se utiliza una llamada a la API para actualizar los certificados del almacén de pares clave-valor.

En la siguiente configuración, NGINX Plus dirige las solicitudes a distintos grupos de servidores upstream en función del nombre de host. La conexión mediante proxy se establece utilizando mTLS y se selecciona dinámicamente el certificado de cliente adecuado para cada servidor upstream.

Cargando ejemplo de código…

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

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

Seguridad reforzada para el procesamiento de solicitudes HTTP

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

Como ejemplo de esto último, NGINX Plus R25 realiza varias comprobaciones adicionales en las solicitudes HTTP para proteger sus aplicaciones frente a posibles ataques, como el contrabando de solicitudes. Devuelve un error cuando se dan estas condiciones:

• Una solicitud HTTP/1.0 incluye la cabecera «Transfer-Encoding»
• Están presentes tanto las cabeceras «Transfer-Encoding» como «Content-Length»
• Hay espacios o caracteres de control en la línea de solicitud o en el nombre de algún encabezado
• Hay espacios o caracteres de control en la cabecera «Host»
• Se utiliza el método CONNECT method is used

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

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

Persistencia del estado de comprobación de estado obligatoria al recargar aplicaciones TCP/UDP

NGINX Plus utiliza comprobaciones de estado obligatorias para garantizar que los nuevos servidores añadidos a los grupos de servidores ascendentes se sometan a pruebas y estén en buen estado antes de que se redirijan a ellos las solicitudes de los clientes. En NGINX Plus R23 y versiones anteriores, los servidores ascendentes se consideraban en mal estado después de recargar la configuración, independientemente de su estado antes de la recarga. Como resultado, NGINX Plus no enviaba solicitudes a un servidor hasta que este superaba la primera comprobación obligatoria.

NGINX Plus R24 introdujo, para las aplicaciones HTTP, la persistencia opcional del estado de las comprobaciones de estado obligatorias entre recargas. Si la última comprobación de estado obligatoria antes de una recarga se realizó correctamente, NGINX Plus puede enviar solicitudes a un servidor de inmediato, en lugar de tener que esperar a que se complete correctamente una comprobación de estado obligatoria posterior a la recarga.

NGINX Plus R25 amplía esta funcionalidad a las aplicaciones TCP/UDP (dentro del contexto stream). Al igual que para HTTP, añada el parámetro persistent a la directiva health_check junto con el parámetro mandatory.

Cargando ejemplo de código…

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 refuerzan la compatibilidad con JavaScript ES6.

Declaración de variables con las palabras clave «let» y «const»

NGINX JavaScript ahora permite declarar variables con ámbito mediante 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 permitía definir variables limitadas al ámbito de una instrucción block concreta, necesarias para gestionar la complejidad que suele surgir cuando distintos proyectos, lenguajes de programación y equipos de ingeniería colaboran en repositorios de código o bibliotecas compartidos.

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

• let las variables están limitadas al ámbito de una instrucción block o de una expresión en la que se utilizan. En cambio, la palabra clave var declara una variable globalmente o de forma local para una función completa, independientemente del ámbito de bloque.
• const tienen un ámbito de bloque, al igual que las variables declaradas mediante la palabra clave let. El valor de una constante no se puede cambiar mediante una reasignación ni se puede volver a declarar.

Compatibilidad con todos los métodos del constructor «Promise»

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 ES6 de JavaScript.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R25 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el balanceo de carga y la puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días.

Sobre el autor

Zach WestallResponsable sénior de marketing de producto

Más artículos de Zach Westall