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:
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.
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 .
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.
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.
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.
Directiva obsoleta | Directiva de sustitución |
---|---|
Tiempo de espera inactivo de http2 |
tiempo de espera de mantenimiento de vida |
tamaño máximo del campo http2 tamaño máximo del encabezado http2 |
grandes búferes de encabezado de cliente |
http2_max_solicitudes |
solicitudes de mantenimiento de actividad |
Tiempo de espera de recepción http2 |
tiempo de espera del encabezado del cliente |
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.
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
):
saludable
a no saludable
se registra en el nivel de advertencia
(antes información
).no saludable
a saludable
se registra en el nivel de aviso
(antes información
).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.
Algoritmos de gestión de claves JWE |
|
Algoritmos de cifrado de contenido JWE |
|
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:
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 . ]
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.
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:
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.
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.
de js_header_filter
con el almacén de clave-valorEn 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.
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 .
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).
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+ .
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.
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
.
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 .
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 .
"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.