Anunciamos NGINX Plus R24

Nos complace anunciar la disponibilidad de NGINX Plus Release 24 (R24). 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 R24 incluyen:

• Tokens web JSON cifrados : basándose en la compatibilidad con tokens web JSON (JWT) firmados en versiones anteriores, NGINX Plus ahora admite JWT cifrados para garantizar la confidencialidad y la integridad de la información confidencial cuando se almacena en navegadores web y otros clientes.
• Un hito importante en el desarrollo del módulo JavaScript de NGINX : las nuevas características, en particular el filtrado de respuestas para encabezados y cuerpos HTTP y la compatibilidad con servicios de autenticación basados en HTTP para conexiones y sesiones TCP/UDP, desbloquean una serie de nuevos y potentes casos de uso.
• Integración con F5 Device ID+ : este identificador de dispositivo de alta precisión y en tiempo real asigna un identificador único a cada dispositivo que visita su sitio, lo que permite una mayor protección contra actores maliciosos conocidos y experiencias de usuario personalizadas para los visitantes que regresan.

Para completar el lanzamiento se incluyen la persistencia opcional en las recargas de configuración de los resultados de los controles de estado obligatorios y los valores dinámicos para los indicadores de cookies.

Cambios importantes en el comportamiento

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 . Le recomendamos que reemplace cualquier directiva set_cookie_flag en su configuración con directivas proxy_cookie_flags lo antes posible. Consulte también Banderas de cookies dinámicas .

Cambios en el soporte de la plataforma

• 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
• Sistemas operativos más antiguos eliminados :
  • Debian 9 ya no recibe soporte; la versión compatible más antigua es la 10
• Sistemas operativos antiguos obsoletos y programados para su eliminación 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 , que habilita TLS 1.3 y fortalece la seguridad de muchas otras maneras. Al actualizar los sistemas Amazon Linux 2 a NGINX Plus R24 , confirme que el otro software que usa OpenSSL en el sistema aún funcione correctamente con OpenSSL 1.1.

Cambios en el procedimiento de instalación de NGINX Plus

Hemos reorganizado los repositorios de paquetes NGINX Plus, con cambios resultantes en el procedimiento de instalación.

El cambio en la organización del repositorio refleja la expansión de nuestra cartera de productos y del ecosistema de productos que dependen de NGINX Plus. Para NGINX Plus en particular, el repositorio pkgs.nginx.com/plus reemplaza al antiguo repositorio plus-pkgs.nginx.com .

Cuando instala y 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 que están configurados para usar el repositorio plus-pkgs.nginx.com , debe actualizar el administrador de paquetes para hacer referencia a pkgs.nginx.com/plus (más el elemento de ruta final que indica el sistema operativo).

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

Consolidación de directivas de manejo 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 forma en que se configuran las conexiones de larga duración. En NGINX Plus R24 y versiones posteriores, las directivas de configuración que antes se aplicaban solo a HTTP/1.1 también funcionan para HTTP/2. Ya no es necesario utilizar directivas diferentes para la misma funcionalidad sólo porque la versión del protocolo sea diferente.

Cierre de conexión más agresivo

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

NGINX Plus R24 modifica el efecto de estas directivas de una manera importante y elimina un error potencial: si el grupo de conexiones de trabajadores libres se agota, NGINX Plus comienza a cerrar no solo las conexiones keepalive, sino también las conexiones en modo de cierre persistente.

Se modificó el nivel de gravedad de los cambios de estado de salud registrados

NGINX escribe una entrada en el registro de errores cuando cambia el estado de salud de un servidor ascendente: una herramienta importante para monitorear y analizar la salud general de su 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 saludable a no saludable se registra en el nivel de advertencia (antes información ).
• El cambio de no saludable a saludable se registra en el nivel de aviso (antes información ).

Nuevas funciones en detalle

Tokens web JSON cifrados

El uso de JSON Web Tokens ( JWT ) continúa creciendo. Anteriormente, NGINX Plus admitía tokens firmados (el estándar JSON Web Signature [JWS] definido en RFC 7515 ), que proporcionan integridad de datos para las reclamaciones codificadas en el token. Sin embargo, JWS no proporciona confidencialidad para las reclamaciones: pueden ser leídas por cualquier componente que tenga acceso al token. TLS/SSL mitiga la exposición de los tokens en tránsito, pero los tokens almacenados en navegadores web y otros clientes aún están expuestos.

NGINX Plus R24 introduce soporte para tokens encriptados (el estándar JSON Web Encryption [JWE] definido en RFC 7516 ), que brindan tanto confidencialidad como integridad de datos para todo el conjunto de reclamos. Ahora es posible codificar información confidencial o de identificación personal (PII) dentro de JWT sin riesgo de que clientes inseguros filtren dichos datos.

NGINX Plus R24 y versiones posteriores admiten JWT firmados y cifrados. Los tokens firmados son los predeterminados y no requieren ninguna configuración explícita. La nueva directiva auth_jwt_type configura el cifrado JWT.

Usted define el algoritmo de cifrado (o firma) y el uso de la clave en el archivo de clave JWT denominado por la directiva auth_jwt_key_file . NGINX Plus R24 y versiones posteriores admiten los siguientes métodos de cifrado.

Hito de madurez importante para el módulo JavaScript de NGINX

NGINX Plus R24 marca un hito importante en el desarrollo del módulo JavaScript de NGINX (njs), ahora en0.5.3 . Hay dos mejoras importantes que le permiten ampliar NGINX Plus con soluciones personalizadas para una amplia 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 HTTP o TCP/UDP

Si no está familiarizado con 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 obtener una lista completa, consulte Casos de uso del módulo JavaScript NGINX . ]

Filtrado de respuestas

Una de las características más potentes de NGINX Plus implementada como puerta de enlace API o proxy inverso es el filtrado de respuestas , que implica interceptar respuestas de servidores ascendentes y reemplazar cadenas en el cuerpo de la respuesta, los encabezados o ambos, según 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 Sustitución .

NGINX Plus R24 presenta una implementación separada de filtrado de respuestas dentro del módulo JavaScript de NGINX, con dos directivas que le permiten aprovechar el poder de JavaScript para analizar y modificar los cuerpos y encabezados de respuesta. 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, para un filtrado de respuesta aún más potente que con el módulo Sustitución.

Filtrado de cuerpos de respuesta con la directiva js_body_filter

Con la directiva js_body_filter puedes usar JavaScript para inspeccionar y modificar el cuerpo de la respuesta de un servidor proxy. Los casos de uso incluyen:

• Escaneo de patrones complejos con expresiones regulares
• Transformación del formato de datos
• Inserción de contenido dinámico en las respuestas

En este ejemplo, escaneamos las respuestas en busca de cualquier cosa que parezca una clave de acceso de AWS y reemplazamos dichas ocurrencias con un valor enmascarado.

Para ejecutar este código simplemente necesitamos referenciar la función maskAwsKeys dentro del bloque de ubicación correspondiente.

Filtrado de encabezados de respuesta con la directiva js_header_filter

Puede utilizar la directiva js_header_filter para examinar (o incluso interceptar y modificar) el contenido de los encabezados de respuesta. Consideremos un servidor backend que emite una serie de encabezados Set-Cookie que contienen información confidencial pero que son esenciales para el funcionamiento correcto. NGINX Plus puede interceptar la respuesta, leer los encabezados Set-Cookie y guardarlos en el almacén de clave-valor. Se puede crear un encabezado Set-Cookie de reemplazo como referencia al almacén de clave-valor e inyectarlo en la respuesta original.

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

Luego, en las líneas 12 y 13, reemplazamos la cookie de referencia con el contenido del almacén de clave-valor e interceptamos cualquier cookie nueva con nuestro código JavaScript.

El código JavaScript itera sobre cada nuevo encabezado de respuesta Set-Cookie y crea una nueva entrada de clave-valor para almacenarlo.

Aprovechamiento de los servicios HTTP para TCP/UDP con un cliente HTTP simple

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

Con la función ngx.fetch de JavaScript NGINX incorporada, ahora puede crear una instancia de un cliente HTTP simple desde el contexto de una conexión TCP/UDP. Esto permite el uso de servicios de autenticación basados en HTTP para el control de acceso en el contexto de transmisión , por ejemplo, llamando a un demonio de agente OpenPolicy local al hacer de proxy de una conexión de base de datos.

Este ejemplo demuestra el uso de un servicio de autenticación HTTP local en el puerto 8085 para autenticar cada nueva conexión. La directiva js_access y la función ngx.fetch implementan juntas una funcionalidad en el nuevo contexto HTTP instanciado que es similar a la autorización del cliente basada en el resultado de una subsolicitud (como lo implementa la directiva auth_request para solicitudes HTTP regulares). Según el código de estado HTTP disponible en el objeto Respuesta , se permite la conexión a la base de datos backend ( s.allow ) o se rechaza ( s.deny ).

Nota:  La función ngx.fetch funciona con el módulo HTTP de JavaScript de NGINX así como con el módulo Stream de JavaScript de NGINX, pero tiene limitaciones significativas en comparación con el objeto r.subrequest en el módulo HTTP. Para la mayoría de los casos de uso de HTTP, se prefiere r.subrequest ya que proporciona soporte para conexiones TLS, almacenamiento en caché y todas las capacidades del módulo Proxy .

Otras mejoras de NJS

Cuando se define una variable NGINX con la directiva set [ HTTP ][ Stream ] o js_set [ HTTP ][ Stream ] , el valor puede anularse cuando el procesamiento de la solicitud encuentra una redirección. La nueva directiva js_var [ HTTP ][ Stream ] permite que una función de JavaScript evalúe una variable y que su valor persista en las redirecciones.

El nuevo objeto njs.on permite que se ejecute una función de JavaScript cuando la máquina virtual njs sale. Esto se puede utilizar para ejecutar una función al final de una conexión TCP, por ejemplo.

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

Integración con F5 Device ID+

F5 Device ID+ es un identificador de dispositivos de alta precisión y en tiempo real que utiliza recopilación de señales avanzada y algoritmos de aprendizaje automático probados para asignar un identificador único a cada dispositivo que visita su sitio. La implementación es sencilla y ofrece beneficios inmediatos para sus equipos de seguridad, redes, fraude y digitales. Nunca ha sido tan fácil comprender los dispositivos únicos que visitan tus aplicações .

Para obtener instrucciones sobre cómo activar F5 Device ID+ en sus instancias NGINX Plus, consulte Mitigar fraudes y riesgos con F5 Device ID+ .

Beneficios de usar F5 Device ID+

• Fortalezca la seguridad de las aplicação : fortalezca el análisis de detección y mitigación de ataques mediante una identificación precisa de los dispositivos. Reconozca los dispositivos que regresan y que sus sistemas de seguridad ya han marcado como sospechosos.
• Optimice la gestión del tráfico : incorpore un identificador de dispositivo único en la lógica de enrutamiento para administrar y optimizar mejor el tráfico de la red. Identifique dispositivos incluso cuando actores maliciosos manipulan datos de la capa 7.
• Mitigue el fraude y el riesgo : monitoree el comportamiento del cliente en operaciones como creación de nuevas cuentas, autenticación de usuarios, pago en comercio electrónico y transacciones financieras, detectando patrones anómalos que podrían indicar robo de identidad, entre otras amenazas.
• Personalice y acelere las experiencias en línea : haga que el inicio de sesión, el pago y la autenticación sean sencillos para usuarios y dispositivos recurrentes conocidos. Las pruebas A/B de F5 demuestran que reducir la fricción de seguridad aumenta los ingresos, y la identificación del dispositivo es un elemento importante en cualquier estrategia de reducción de la fricción.

Cómo funciona F5 Device ID+

Cuando cada usuario visita su sitio web, F5 Device ID+ aprovecha JavaScript para recopilar información sobre el navegador, el sistema operativo del dispositivo, el hardware y la configuración de red. Estos atributos alimentan el servicio F5 Device ID+ creado con las capacidades de inteligencia artificial y aprendizaje automático reconocidas por la industria de F5 Shape. Los datos se procesan en tiempo real y se asigna un identificador único al dispositivo, a menos que ya sea un dispositivo conocido. En el caso de los dispositivos que regresan, se pueden registrar, aprender y estudiar el comportamiento, las acciones y otras propiedades para facilitar la reducción del fraude y una experiencia fluida para los buenos usuarios conocidos.

Otras mejoras en NGINX Plus R24

El estado de las comprobaciones de estado obligatorias puede persistir tras recargas de configuración

Los controles de estado obligatorios se utilizan para permitir el inicio lento de los servidores ascendentes que se agregan mediante la API NGINX Plus o a través de la resolución de DNS. Se aseguran de que los nuevos nodos primero sean verificados y luego se inicien lentamente una vez que estén listos para recibir tráfico.

Anteriormente, después de una recarga de configuración, los servidores ascendentes se consideraban no saludables independientemente de su estado antes de la recarga. Como resultado, los servidores no aceptaron solicitudes de clientes hasta que se pasó la primera verificación obligatoria.

Con NGINX Plus R24, puede marcar las comprobaciones de estado HTTP obligatorias como persistentes, de modo que se recuerde su estado anterior cuando se vuelva a cargar la configuración. Agregue el parámetro persistente a la directiva health_check junto con el parámetro obligatorio .

Banderas de cookies dinámicas

En la versión anterior de NGINX Plus, presentamos la directiva proxy_cookie_flags como un método nativo para configurar indicadores de cookies . NGINX Plus R24 amplía esta capacidad al habilitar valores dinámicos para los indicadores de cookies. Esto permite que indicadores de cookies específicos sean controlados por variables NGINX.

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

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

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R24 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 .