Presentamos NGINX Plus R24

Nos complace anunciar la disponibilidad de NGINX Plus Release 24 (R24). Basado en NGINX Open Source, NGINX Plus es el único software todo en uno que integra servidor web, equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

Entre las nuevas funcionalidades de NGINX Plus R24 se incluyen:

• Tokens web JSON cifrados – Partiendo de la compatibilidad con tokens web JSON (JWT) firmados de versiones anteriores, NGINX Plus ahora admite JWT cifrados para garantizar la confidencialidad y la integridad de los datos de información sensible cuando se almacena en navegadores web y otros clientes.
• Un hito importante en el desarrollo del módulo JavaScript de NGINX – Las nuevas funcionalidades – en particular, el filtrado de respuestas tanto para las cabeceras como para los cuerpos HTTP, y la compatibilidad con servicios de autenticación basados en HTTP para conexiones y sesiones TCP/UDP – abren la puerta a numerosos y potentes casos de uso.
• Integración con F5 Device ID+ – Este identificador de dispositivos de alta precisión y en tiempo real asigna un identificador único a cada dispositivo que visita su sitio web, lo que permite reforzar la protección frente a agentes maliciosos conocidos y ofrecer experiencias de usuario personalizadas a los visitantes recurrentes.

Para completar esta versión, se incluyen la conservación opcional de los resultados de las comprobaciones de estado obligatorias al recargar la configuración y valores dinámicos para los atributos de las cookies.

Cambios importantes de comportamiento

Módulo Cookie-Flag obsoleto

Tal 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 proxy_cookie_flags. Le recomendamos que sustituya cuanto antes todas las directivas set_cookie_flag de su configuración por directivas proxy_cookie_flags. Consulte también Marcas dinámicas de cookies.

Cambios en la compatibilidad con plataformas

• Nuevos sistemas operativos compatibles:
  • Alpine Linux 3.13 (aarch64, amd64)
  • CentOS 7.4+ (aarch64, además de x86_64 y ppc64le)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• Se han eliminado los sistemas operativos antiguos:
  • Debian 9 ya no es compatible; la versión más antigua compatible es la 10
• Sistemas operativos antiguos obsoletos y cuya retirada está prevista en NGINX Plus R25:
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 depende de OpenSSL 1.1

El paquete NGINX Plus para Amazon Linux 2 ahora depende de OpenSSL 1.1, lo que habilita TLS 1.3 y refuerza la seguridad de muchas otras formas. Al actualizar sistemas Amazon Linux 2 a NGINX Plus R24, compruebe que el resto del software del sistema que utiliza OpenSSL siga funcionando correctamente con OpenSSL 1.1.

Cambios en el procedimiento de instalación de NGINX Plus

Hemos reorganizado los repositorios de paquetes de NGINX Plus, lo que ha dado lugar a cambios en el procedimiento de instalación.

El cambio en la organización de los repositorios refleja la ampliación de nuestra cartera de productos y del ecosistema de productos que dependen de NGINX Plus. En el caso concreto de NGINX Plus, el repositorio pkgs.nginx.com/plus sustituye al antiguo repositorio plus-pkgs.nginx.com.

Al instalar y 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 utilizar el repositorio plus-pkgs.nginx.com, debe actualizar el gestor de paquetes para que haga referencia a pkgs.nginx.com/plus (más el elemento final de la ruta que indica el sistema operativo).

Para obtener instrucciones sobre cómo actualizar un sistema existente a NGINX Plus R24, consulte la base de conocimientos de F5. Para obtener instrucciones actualizadas sobre la instalación inicial, consulte Instalación de NGINX Plus en la Guía de administración de NGINX Plus.

Consolidación de las directivas de gestión de conexiones HTTP

A medida que el estándar HTTP/3 se acerca a su finalización y aumenta el uso de HTTP/2, hemos simplificado la configuración de las conexiones de larga duración. En NGINX Plus R24 y versiones posteriores, las directivas de configuración que antes solo se aplicaban a HTTP/1.1 también funcionan con HTTP/2. Ya no es necesario utilizar directivas diferentes para una misma funcionalidad solo porque la versión del protocolo sea distinta.

Directiva obsoleta Directiva de sustituciónhttp2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

Cierre de conexiones más agresivo

En NGINX Plus R23 y versiones posteriores, las directivas lingering_close, lingering_time y lingering_timeout funcionan tanto con HTTP/2 como con HTTP/1.1. Configurar una gestión más eficiente de las conexiones HTTP/2 mediante estas directivas mejora las capacidades generales de HTTP/2 de NGINX Plus.

NGINX Plus R24 modifica de forma importante el efecto de estas directivas y elimina un posible error: si se agota el conjunto de conexiones de trabajo libres, NGINX Plus empieza a cerrar no solo las conexiones persistentes, sino también las conexiones en modo de cierre diferido.

Cambio del nivel de gravedad de los cambios de estado registrados

NGINX escribe una entrada en el registro de errores cuando cambia el estado de salud de un servidor ascendente, una herramienta importante para supervisar y analizar el estado general de la infraestructura. El nivel de gravedad con el que se registran los cambios de estado ha cambiado tanto para los servidores ascendentes HTTP como para los TCP/UDP (stream):

• El cambio de healthy a unhealthy se registra con el nivel warn (antes era info).
• El cambio de unhealthy a healthy se registra en el nivel notice (antes, info).

Nuevas funcionalidades en detalle

Tokens web JSON cifrados

El uso de los tokens web JSON (JWT) sigue creciendo. Anteriormente, NGINX Plus admitía tokens firmados (el estándar JSON Web Signature [JWS] definido en la RFC 7515), que garantizan la integridad de los datos de las declaraciones codificadas en el token. Sin embargo, JWS no garantiza la confidencialidad de las declaraciones, ya que cualquier componente que tenga acceso al token puede leerlas. TLS/SSL reduce la exposición de los tokens en tránsito, pero los tokens almacenados en navegadores web y otros clientes siguen estando expuestos.

NGINX Plus R24 incorpora compatibilidad con tokens cifrados (el estándar JSON Web Encryption [JWE] definido en RFC 7516), que proporcionan tanto confidencialidad como integridad de los datos para todo el conjunto de declaraciones. Ahora se puede codificar información confidencial o de identificación personal (PII) dentro de los JWT sin riesgo de que clientes no seguros filtren esos datos.

NGINX Plus R24 y versiones posteriores admiten JWT firmados y cifrados. Los tokens firmados son la opción predeterminada y no requieren ninguna configuración explícita. La nueva directiva «auth_jwt_type» configura el cifrado de JWT.

Cargando ejemplo de código…

El algoritmo de cifrado (o firma) y el uso de la clave se definen en el archivo de claves JWT especificado por la directiva auth_jwt_key_file. NGINX Plus R24 y las versiones posteriores admiten los siguientes métodos de cifrado.

Algoritmos de gestión de claves JWE

• A128KW, A192KW, A256KW

• A128GCMKW, A192GCMKW, A256GCMKW

• dir – Configura el uso directo de una clave simétrica compartida como clave de cifrado del contenido

Algoritmos de cifrado de contenido JWE

• A128CBC-HS256, A192CBC-HS384, A256CBC-HS512

• A128GCM, A192GCM, A256GCM

Un gran hito de madurez para el módulo JavaScript de NGINX

NGINX Plus R24 marca un hito importante en el desarrollo del módulo JavaScript de NGINX (njs), que alcanza ahora la versión 0.5.3. Hay dos mejoras importantes que permiten ampliar NGINX Plus con soluciones personalizadas para una gran variedad de casos de uso:

• Filtrado de respuestas tanto para los encabezados como para los cuerpos de las respuestas HTTP
• Un cliente HTTP integrado que se puede utilizar para realizar solicitudes HTTP durante el procesamiento de HTTP o TCP/UDP

Si no conoce el módulo JavaScript de NGINX, lea esta introducción en nuestro blog<.htmla>.

[Los casos de uso descritos en esta sección son solo algunos de los muchos casos de uso del módulo JavaScript de NGINX. Para consultar la lista completa, consulte Casos de uso del módulo JavaScript de NGINX.]

Filtrado de respuestas

Una de las funciones más potentes de NGINX Plus cuando se implementa como puerta de enlace de API o proxy inverso es el filtrado de respuestas, que consiste en interceptar las respuestas de los servidores ascendentes y sustituir cadenas en el cuerpo de la respuesta, en los encabezados o en ambos mediante la coincidencia de expresiones regulares. Para el tráfico que no se manipula con el módulo JavaScript de NGINX, el filtrado de respuestas se implementa en el módulo Substitution.

NGINX Plus R24 incorpora una implementación independiente del filtrado de respuestas en el módulo JavaScript de NGINX, con dos directivas que permiten aprovechar la potencia de JavaScript para analizar y modificar los cuerpos y encabezados de las respuestas. JavaScript amplía las posibilidades de inspección y manipulación mucho más allá de la simple sustitución de cadenas basada en expresiones regulares, lo que permite un filtrado de respuestas aún más potente que el del módulo Substitution.

Filtrado de cuerpos de respuesta con la directiva js_body_filter Directive

Con la directiva js_body_filter puede usar JavaScript para inspeccionar y modificar el cuerpo de la respuesta de un servidor proxy. Entre los casos de uso se incluyen:

• Búsqueda de patrones complejos mediante expresiones regulares
• Transformación del formato de los datos
• Insertar contenido dinámico en las respuestas

En este ejemplo, analizamos las respuestas en busca de cualquier elemento que parezca una clave de acceso de AWS y sustituimos todas las coincidencias por un valor oculto.

Cargando ejemplo de código…

Para ejecutar este código, solo tenemos que hacer referencia a la función maskAwsKeys dentro del bloque location correspondiente.

Cargando ejemplo de código…

Filtrado de las cabeceras de respuesta con la directiva js_header_filter Directive

Puede utilizar la directiva js_header_filter para examinar —o incluso interceptar y modificar— el contenido de las cabeceras de respuesta. Imagine un servidor backend que emite varias cabeceras Set-Cookie que contienen información confidencial, pero que son esenciales para el correcto funcionamiento. NGINX Plus puede interceptar la respuesta, leer las cabeceras Set-Cookie y guardarlas en el almacén de clave-valor. Se puede crear una cabecera Set-Cookie de sustitución como referencia al almacén de clave-valor e insertarla en la respuesta original.

Flujo de solicitudes que muestra js_header_filter interactuando con el almacén de clave-valor

En las líneas 4 y 5 de la configuración de NGINX Plus, definimos el almacén de pares clave-valor:

Cargando ejemplo de código…

A continuación, en las líneas 12–13, sustituimos la cookie de referencia por el contenido del almacén de clave-valor e interceptamos las cookies nuevas con nuestro código JavaScript.

Cargando ejemplo de código…

El código JavaScript recorre cada nueva cabecera de respuesta «Set-Cookie» y crea una nueva entrada de clave-valor para almacenarla.

Cargando ejemplo de código…

Aprovechamiento de servicios HTTP para TCP/UDP con un cliente HTTP sencillo

El principal caso de uso de una puerta de enlace de API es controlar el acceso a recursos específicos. NGINX Plus ofrece un potente conjunto de funciones de autenticación y control de acceso en la capa 7 para las solicitudes HTTP, pero las implementaciones modernas de API también utilizan TCP/UDP como protocolo subyacente, lo que plantea nuevos retos de autenticación.

Con la función integrada de NGINX JavaScript ngx.fetch, ahora puede crear una instancia de un cliente HTTP sencillo desde el contexto de una conexión TCP/UDP. Esto permite utilizar servicios de autenticación basados en HTTP para controlar el acceso en el contexto de stream, por ejemplo, llamando a un demonio local de OpenPolicy Agent al actuar como proxy de una conexión a una base de datos.

Este ejemplo muestra el uso de un servicio local de autenticación HTTP en el puerto 8085 para autenticar cada nueva conexión. La directiva js_access y la función ngx.fetch implementan conjuntamente en el contexto HTTP recién creado una funcionalidad similar a la autorización de clientes basada en el resultado de una subsolicitud (tal como la implementa la directiva auth_request para las solicitudes HTTP convencionales). En función del código de estado HTTP disponible en el Response objeto, se permite (s.allow) o se rechaza (s.deny) la conexión con la base de datos de backend.

Cargando ejemplo de código…

Cargando ejemplo de código…

Nota: La función ngx.fetch funciona tanto con el módulo HTTP de NGINX JavaScript como con el módulo Stream de NGINX JavaScript, pero presenta importantes limitaciones en comparación con el objeto r.subrequest del módulo HTTP. Para la mayoría de los casos de uso de HTTP, se recomienda r.subrequest, ya que admite conexiones TLS, almacenamiento en caché y todas las funcionalidades del módulo Proxy.

Otras mejoras de njs

Cuando se define una variable de NGINX mediante la directiva set [HTTP][Stream] o js_set [HTTP][Stream], su valor puede sobrescribirse si se produce una redirección durante el procesamiento de la solicitud. La nueva directiva js_var [HTTP][Stream] permite que una función de JavaScript evalúe una variable y que su valor se conserve entre redirecciones.

El nuevo objeto njs.on permite ejecutar una función de JavaScript cuando finaliza la máquina virtual de njs. Esto puede utilizarse, por ejemplo, para ejecutar una función al finalizar una conexión TCP.

La nueva propiedad s.status del objeto de sesión Stream permite acceder al estado general de la sesión (consulte $status para ver los valores posibles).

Integración con F5 Device ID+

F5 Device ID+ es un identificador de dispositivos en tiempo real y de alta precisión que utiliza técnicas avanzadas de recopilación de señales y algoritmos de aprendizaje automático de eficacia probada para asignar un identificador único a cada dispositivo que visita su sitio web. Su implementación es sencilla y ofrece ventajas inmediatas a sus equipos de seguridad, redes, prevención del fraude y canales digitales. Nunca había sido tan fácil conocer los dispositivos únicos que acceden a sus aplicaciones.

Para obtener instrucciones sobre cómo activar F5 Device ID+ en sus instancias de NGINX Plus, consulte Mitigación del fraude y los riesgos con F5 Device ID+.

Ventajas de usar F5 Device ID+

• Refuerce la seguridad de las aplicaciones – Mejore el análisis de detección y mitigación de ataques mediante una identificación precisa de los dispositivos. Reconozca los dispositivos recurrentes que sus sistemas de seguridad ya hayan marcado como sospechosos.
• Optimice la gestión del tráfico – Incorpore un identificador único de dispositivo en la lógica de enrutamiento para gestionar y optimizar mejor el tráfico de red. Identifique los dispositivos incluso cuando actores maliciosos manipulen los datos de la capa 7.
• Mitigue el fraude y los riesgos – Supervise el comportamiento de los clientes en operaciones como la creación de cuentas, la autenticación de usuarios, el pago en comercios electrónicos y las transacciones financieras, y detecte patrones anómalos que puedan indicar un robo de identidad, entre otras amenazas.
• Personalice y agilice las experiencias online – Facilite el inicio de sesión, el proceso de compra y la autenticación para los usuarios y dispositivos conocidos que regresan. Las pruebas A/B de F5 demuestran que reducir las fricciones de seguridad aumenta los ingresos, y la identificación de dispositivos es un elemento importante en cualquier estrategia para reducir dichas fricciones.

Cómo funciona F5 Device ID+

Cuando un usuario visita su sitio web, F5 Device ID+ utiliza JavaScript para recopilar información sobre el navegador, el sistema operativo y el hardware del dispositivo, así como la configuración de red. Estos atributos se envían al servicio F5 Device ID+, basado en las capacidades de IA y aprendizaje automático de F5 Shape, reconocidas en el sector. Los datos se procesan en tiempo real y se asigna un identificador único al dispositivo, salvo que ya sea un dispositivo conocido. En el caso de los dispositivos que regresan, se pueden registrar, aprender y analizar su comportamiento, sus acciones y otras propiedades para ayudar a reducir el fraude y ofrecer una experiencia fluida a los usuarios legítimos conocidos.

Otras mejoras de NGINX Plus R24

El estado de las comprobaciones de estado obligatorias puede conservarse tras recargar la configuración

Las comprobaciones de estado obligatorias se utilizan para habilitar el arranque lento de los servidores ascendentes que se añaden mediante la API de NGINX Plus o a través de la resolución DNS. Garantizan que primero se compruebe el estado de los nuevos nodos y que, una vez que estén listos para recibir tráfico, se inicien lentamente.

Anteriormente, tras recargar la configuración, los servidores ascendentes se consideraban en mal estado independientemente de cuál fuera su estado antes de la recarga. Como resultado, los servidores no aceptaban solicitudes de clientes hasta que se superaba la primera comprobación obligatoria.

Con NGINX Plus R24, puede marcar las comprobaciones de estado HTTP obligatorias como persistentes, de modo que se recuerde su estado anterior al recargar la configuración. Añada el parámetro persistent a la directiva health_check junto con el parámetro mandatory.

Cargando ejemplo de código…

Atributos dinámicos de las cookies

En la versión anterior de NGINX Plus introdujimos la directiva proxy_cookie_flags como método nativo para configurar los atributos de las cookies. NGINX Plus R24 amplía esta funcionalidad al permitir valores dinámicos para los atributos de las cookies. Esto permite controlar atributos específicos de las cookies mediante variables de NGINX.

Nota: La directiva proxy_cookie_flags deja obsoleto el módulo Cookie‑Flag, que se eliminará en NGINX Plus R26. Consulte Módulo Cookie‑Flag obsoleto.

Este ejemplo utiliza un mapa para habilitar el atributo Secure de la cookie cuando el esquema es https en lugar de http.

Cargando ejemplo de código…

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R24 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 seguridad, balanceo de carga y como 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.

---