[ Editor – El módulo WAF NGINX ModSecurity para NGINX Plus dejó de venderse oficialmente el 1 de abril de 2022 y su transición al fin de su vida útil será efectiva el 31 de marzo de 2024. ] Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición al final de su vida útil<.htmla> en nuestro blog.]
Nos complace anunciar NGINX Plus Release 10 (R10), nuestro lanzamiento más importante hasta el momento. NGINX Plus amplía NGINX Open Source con funcionalidad avanzada y soporte galardonado, brindando a los clientes una solución completa de entrega de aplicação . Con esta versión, proporcionamos una serie de nuevas características para mejorar drásticamente la seguridad y el rendimiento de las aplicações entregadas por NGINX Plus, junto con características adicionales para una mejor integración de red y soporte para la personalización de NGINX Plus a través de scripts.
[ Editor : Para obtener más detalles sobre las nuevas características clave de NGINX Plus R10, consulte estos recursos relacionados:
]
NGINX Plus R10 presenta la versión inicial de nuestro firewall de aplicação web (WAF) , impulsado por ModSecurity y totalmente compatible con NGINX, Inc. Los ataques a aplicação web aumentaron un 50% el año pasado y los ataques DDoS aumentaron más del doble, según Akamai . Ahora todas las aplicação corren el riesgo de ser atacadas. NGINX ModSecurity WAF ayuda a proteger las aplicações web de usuarios maliciosos y ofrece a los clientes una herramienta versátil para ayudar a mantener sus aplicaciones y datos seguros.
NGINX ModSecurity WAF se basa en el nuevo software ModSecurity 3 y se ejecuta de forma nativa dentro de NGINX Plus. Disponible como una opción con costo adicional en nuestro repositorio de módulos dinámicos y respaldado por NGINX, Inc., ha sido probado exhaustivamente con NGINX Plus. Estamos trabajando con Trustwave y mantendremos actualizaciones probadas a medida que agreguemos funciones, mejoremos el rendimiento y solucionemos cualquier problema.
Dos nuevas características adicionales mejoran aún más las capacidades de seguridad de NGINX Plus:
Tokens web JSON : muchos de nuestros clientes utilizan NGINX Plus como puerta de enlace de API y nos han pedido una forma común y estándar de autenticar el acceso a las API en la capa NGINX Plus. Para abordar esa necesidad, con esta versión agregamos soporte para la autenticación mediante tokens web JSON (JWT).
NGINX Plus ahora puede validar un JWT antes de permitir que los clientes accedan a las API. Esta característica permite a los administradores de aplicação proteger el acceso a sus API con un estándar abierto, evitando el bloqueo del proveedor a un estándar propietario. La compatibilidad nativa con JWT también reduce la complejidad para los administradores de aplicação al descargar las operaciones de autenticación (como la validación de tokens OpenID Connect compatibles con OAuth 2.0) desde los servidores de aplicação a NGINX Plus.
Además de las funciones de seguridad, NGINX Plus R10 incluye:
Compatibilidad con proxy transparente : aunque muchas aplicações HTTP modernas pueden configurarse para confiar en un encabezado X-Forwarded-For
, algunas aplicações heredadas y otros servicios TCP o UDP hacen referencia a la dirección IP de origen de la transacción para fines de registro, seguridad o autenticación.
NGINX Plus ahora puede 'falsificar' la dirección IP de origen y el puerto de las conexiones HTTP y TCP y los datagramas UDP que reenvía a los servidores ascendentes. Esto se puede utilizar para proporcionar transparencia IP , una configuración donde NGINX Plus envía paquetes con la dirección IP del cliente remoto para que el servidor ascendente vea los paquetes como originados desde esa dirección en lugar de una dirección IP local en el servidor NGINX Plus. Esta función también se puede utilizar para habilitar el retorno directo al servidor para protocolos basados en UDP.
map
, soporte para pruebas A/B con la directiva split_clients
, operaciones Geo y GeoIP y enrutamiento selectivo ( parámetro variable a la directiva proxy_pass
). Estas extensiones le permiten crear políticas de equilibrio de carga TCP y UDP más sofisticadas, impulsadas por el lenguaje de configuración NGINX y la nueva integración de JavaScript de NGINX.La característica principal de NGINX Plus R10 es el lanzamiento inicial de nuestro WAF, construido sobre la reconocida y confiable tecnología ModSecurity . Desde su lanzamiento inicial de código abierto en 2002, ModSecurity ha estado ayudando a proteger algunas de las propiedades web más grandes del mundo contra usuarios maliciosos. Se le conoce comúnmente como la “navaja suiza®” de la seguridad. NGINX ModSecurity WAF es una opción con costo adicional y se proporciona a los suscriptores a través de nuestro repositorio de módulos dinámicos.
NGINX ModSecurity WAF es una solución imprescindible para ayudar a proteger aplicações críticas. Proporciona una alternativa rentable a los dispositivos de hardware costosos e inflexibles, como los proporcionados por F5, Citrix e Imperva, al tiempo que supera sus capacidades con la flexibilidad del software. NGINX ModSecurity WAF se puede implementar en cualquier entorno: servidores locales y nubes públicas, privadas e híbridas.
Un WAF opera sobre una base de datos de “reglas” que definen comportamientos maliciosos que deben bloquearse y/o registrarse. El conjunto de reglas centrales (CRS) de OWASP ModSecurity es uno de los conjuntos de reglas más utilizados con ModSecurity. NGINX ModSecurity WAF utiliza el CRS de OWASP para identificar y bloquear una amplia gama de ataques a aplicação , con características como:
También hay conjuntos de reglas adicionales disponibles de diferentes proveedores, como TrustWave , a distintos niveles de costo. Además, puede utilizar el poderoso lenguaje de reglas ModSecurity para definir sus propias reglas personalizadas que complementen cualquier conjunto de reglas que esté utilizando.
El soporte para NGINX ModSecurity WAF lo proporciona directamente NGINX, Inc. Nuestro equipo de soporte puede ayudar a instalar, configurar y depurar problemas con el WAF y el conjunto de reglas principales de OWASP.
NGINX ModSecurity WAF está disponible como un módulo dinámico en el repositorio NGINX Plus que se instala utilizando herramientas de administración de paquetes estándar. Estos comandos son para sistemas operativos basados en Debian:
# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-modsecurity
Tenga en cuenta que solo los suscriptores que hayan comprado el módulo WAF NGINX ModSecurity, y los suscriptores y evaluadores que hayan solicitado acceso, pueden descargar el paquete nginx-plus-module-modsecurity .
Para cargar el módulo WAF NGINX ModSecurity, incluya la directiva load_module
en el contexto “principal” de nivel superior del archivo de configuración NGINX Plus:
Para habilitar NGINX ModSecurity WAF con NGINX Plus, incluya la directiva modsecurity
junto con la directiva modsecurity_rules_file
para especificar el conjunto de reglas:
Luego vuelva a cargar la configuración de NGINX Plus:
# nginx -t && nginx -s recargar
Con soporte nativo para el estándar de autenticación JSON Web Token (JWT), NGINX Plus R10 facilita la incorporación de soluciones de autenticación sofisticadas a sus aplicações y API.
Los tokens JWT (pronunciado “jot”), definidos en RFC 7519 , son el formato de datos subyacente para la información del usuario en el estándar OpenID Connect , que es la capa de identidad estándar sobre el protocolo OAuth 2.0. Los implementadores de API y microservicios también están recurriendo al estándar JWT por su simplicidad y flexibilidad.
[ Editor : para conocer casos de uso que aprovechan la compatibilidad nativa con JWT, consulte estos blogs:
]
Como proxy inverso y equilibrador de carga , NGINX Plus se ubica frente a las aplicações, lo que lo coloca en una posición ideal para simplificar el desarrollo de aplicação al descargar la validación del JWT suministrado en cada solicitud HTTP. Esto proporciona dos beneficios. En primer lugar, NGINX Plus puede ayudar a evitar que solicitudes no autenticadas, malformadas y maliciosas lleguen a la aplicação, protegiéndola del esfuerzo y el riesgo que implica manejar dichas solicitudes.
El segundo beneficio es que NGINX Plus tiene acceso a todos los campos en el JWT validado (después de la verificación de la firma) y puede usar la potencia y flexibilidad inherentes de su sintaxis de configuración para proporcionar soluciones de autenticación sofisticadas tanto para microservicios como para API:
El siguiente fragmento de muestra de configuración de NGINX Plus muestra cómo usar JWT para proteger un sitio web.
La directiva auth_jwt
le dice a NGINX Plus que use JWT para autenticar a los usuarios que realizan solicitudes para un dominio, en este caso myrealm . La directiva auth_jwt_key_file
indica qué clave web JSON (JWK) utilizar para validar la firma del token; funciona como la clave pública en el cifrado SSL/TLS. La ubicación del archivo debe ser accesible para NGINX Plus.
A medida que NGINX Plus valida y analiza el token, crea automáticamente variables NGINX para las “ reclamos ” en el JWT, que representan entidades asociadas con él (su emisor, el usuario al que se emitió y el destinatario previsto, por ejemplo). Todos los nombres de las variables comienzan con $jwt_claim_
. Luego, puede utilizar la directiva add_header
para que NGINX Plus pase un reclamo a los servidores back-end en forma de un encabezado HTTP establecido en el valor de la variable $jwt_claim_
. En nuestro ejemplo, NGINX Plus pasa la identidad del usuario a la aplicação backend en la variable $jwt_claim_sub
, que corresponde al ID del usuario ( sub
reclamo) en el JWT.
En NGINX Plus R8 lanzamos una vista previa de la tecnología de compatibilidad con OAuth2. En la implementación de NGINX Plus R10, hemos tenido en cuenta los comentarios de nuestros clientes para ofrecer una implementación lista para producción que llegue a los casos de uso más valiosos en el complejo mundo de la autenticación de usuarios y computadoras.
Existen hoy en día numerosas razones para empezar a cifrar con SSL/TLS todo el tráfico de aplicação . Google recompensa a los sitios encriptados con SSL/TLS con clasificaciones más altas en los motores de búsqueda . Además, los estándares web modernos, como HTTP/2, exigen el cifrado SSL/TLS para todos los sitios web.
Con NGINX Plus R10, puede publicar servicios SSL/TLS utilizando certificados RSA y ECC. En nuestras pruebas, los certificados ECC fueron hasta tres veces más rápidos que los certificados RSA de potencia equivalente; esto se traduce en más conexiones SSL/TLS por servidor y protocolos de enlace SSL/TLS más rápidos. NGINX Plus selecciona el certificado óptimo en función de las capacidades de cada cliente, lo que permite a los clientes modernos usar certificados ECC de mayor velocidad y al mismo tiempo seguir admitiendo a los clientes tradicionales que solo utilizan RSA.
Para admitir certificados RSA y ECC, en la configuración de un servidor virtual simplemente incluya un par de directivas ssl_certificate
y ssl_certificate_key
para cada tipo de certificado, como se muestra en el siguiente ejemplo.
Continuamente agregamos funciones a NGINX Plus, como equilibrio de carga TCP y UDP , para admitir una gama más amplia de aplicações y modelos de implementación. Con NGINX Plus R10 hemos agregado una capacidad de proxy transparente que permite a NGINX Plus enviar paquetes a servidores ascendentes utilizando cualquier dirección IP y puerto de origen. Esto permite configuraciones como Transparencia de IP y Retorno directo al servidor.
La transparencia IP es una configuración en la que el balanceador de carga (NGINX Plus) utiliza la dirección IP del cliente remoto como dirección IP de origen en los paquetes que envía a los servidores ascendentes. Esto significa que los servidores ascendentes ven los paquetes como originados desde la dirección IP del cliente remoto, en lugar de desde una dirección IP local en el balanceador de carga. Esto es importante cuando las aplicações hacen referencia a la dirección IP de origen para fines de registro, seguridad, limitación de velocidad o autenticación.
La transparencia de IP también es un elemento fundamental para una técnica de equilibrio de carga de red denominada retorno directo del servidor (DSR). NGINX Plus puede realizar DSR para protocolos basados en UDP (pero no TCP o HTTP), lo que permite que los paquetes de retorno eviten completamente el balanceador de carga y vayan directamente al cliente remoto.
La transparencia de IP y DSR se configuran con el nuevo parámetro transparente
para las directivas proxy_bind
, fastcgi_bind
, memcached_bind
, scgi_bind
y uwsgi_bind
. El siguiente ejemplo muestra cómo configurar DSR para un backend DNS. La directiva proxy_responses
especifica que NGINX Plus no necesita ver ninguna respuesta del servidor (cero es el valor apropiado para DSR).
Tenga en cuenta que las comprobaciones de estado pasivas no son efectivas cuando DSR está habilitado, porque implican que NGINX Plus verifique que el servidor envió una respuesta al cliente. La configuración de comprobaciones de estado que tengan en cuenta las aplicação activas es obligatoria para una configuración de DSR. Para ver un ejemplo, consulte nuestras instrucciones detalladas para configurarlos para servidores DNS con equilibrio de carga.
Las configuraciones de transparencia IP y DSR son complejas, con requisitos adicionales de enrutamiento y reescritura de paquetes que quedan fuera del alcance del software NGINX Plus. Para obtener instrucciones completas, consulte Transparencia de IP y retorno directo al servidor con NGINX y NGINX Plus como proxy transparente en nuestro blog.
[ Editor : El módulo JavaScript de NGINX anteriormente se llamaba nginScript. El módulo estuvo disponible de forma general en NGINX Plus R12 (y NGINX 1.11.10).
Para explorar detalladamente otros casos de uso del módulo JavaScript de NGINX, consulte Casos de uso del módulo JavaScript de NGINX .
El código de esta sección se actualiza para utilizar la directiva js_import
, que reemplaza la directiva js_include
en NGINX Plus R23 y versiones posteriores. Para obtener más información, consulte la documentación de referencia del módulo JavaScript de NGINX : la sección Configuración de ejemplo muestra la sintaxis correcta para la configuración de NGINX y los archivos JavaScript. ]
NGINX Plus R10 incluye una versión preliminar de nuestro nuevo lenguaje de configuración JavaScript NGINX. Aún no está completo en cuanto a sus funciones, y agradecemos cualquier comentario sobre el trabajo realizado hasta el momento. NGINX JavaScript le permite utilizar código JavaScript para realizar acciones complejas y personalizadas en el tráfico HTTP, TCP y UDP. Proporciona una forma nueva y poderosa de controlar cómo se entregan y protegen sus aplicações . Con NGINX JavaScript puedes:
La vista previa de JavaScript de NGINX está disponible en nuestro repositorio de módulos dinámicos . Puede instalarlo utilizando herramientas de administración de paquetes estándar. Estos comandos son para sistemas operativos basados en Debian:
# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-njs
Para cargar los módulos JavaScript de NGINX para HTTP y TCP/UDP, incluya la directiva load_module
en el contexto “principal” de nivel superior del archivo de configuración de NGINX Plus:
Luego vuelva a cargar la configuración de NGINX Plus para cargar los módulos JavaScript de NGINX:
# nginx -t && nginx -s recargar
Los usuarios de NGINX Open Source pueden obtener NGINX JavaScript desde nuestro repositorio de código fuente abierto .
El código JavaScript no está incluido directamente en la configuración de NGINX Plus. En cambio, se lee con la directiva js_import
. En este ejemplo, el código JavaScript para una función “sin servidor” simple se lee desde /etc/nginx/conf.d/functions.js . La directiva js_content
indica a NGINX Plus que llame a la función JavaScript y devuelva los resultados al cliente.
El código JavaScript en /etc/nginx/conf.d/functions.js rellena una cadena de caracteres con un conjunto específico de caracteres:
NGINX Plus R10 presenta una serie de mejoras adicionales para ayudarlo a entregar aplicação sin fallas, que incluyen:
proxy_pass
.IP_BIND_ADDRESS_NO_PORT
cuando está disponible. Esta opción permite reutilizar los puertos de origen para conexiones salientes a servidores ascendentes, siempre que el “4-tupla” estándar (dirección IP de origen, dirección IP de destino, puerto de origen, puerto de destino) sea único. Está disponible en sistemas con kernel Linux versión 4.2 y posterior, y glibc 2.22 y posterior.$request_id
para cada nueva solicitud HTTP, asignando efectivamente a la solicitud un “ID de transacción” único. Esto facilita el seguimiento de aplicação y aporta capacidades de APM a las herramientas de análisis de registros. El ID de la transacción se envía a las aplicações back-end y a los microservicios para que todas las partes del sistema puedan registrar un identificador consistente para cada transacción.proxy_request_buffering
, fastcgi_request_buffering
, scgi_request_buffering
y uwsgi_request_buffering
ahora funcionan con HTTP/2 y se pueden usar para alternar el almacenamiento en búfer de solicitudes.http2_body_preread_size
permite que los clientes HTTP/2 comiencen a enviar el cuerpo de la solicitud inmediatamente. La directiva controla el tamaño del búfer utilizado antes de que NGINX Plus comience a leer el cuerpo de la solicitud del cliente.Como anunciamos en el lanzamiento de NGINX Plus R9, R10 es la última versión que incluirá el paquete NGINX Plus Extras.
Le recomendamos encarecidamente que modifique sus procedimientos de instalación y configuración ahora para utilizar el paquete nginx-plus y cargar dinámicamente los módulos en el paquete nginx-plus-extras que realmente utiliza. A partir de NGINX Plus R11, esta será la única forma posible de utilizar módulos que no estén integrados en el paquete nginx-plus .
Para cambiar al paquete nginx-plus y a los módulos dinámicos, realice estos pasos:
Elimine el paquete nginx-plus-extras e instale nginx-plus y los módulos dinámicos que desee utilizar. Para los sistemas basados en Debian, el conjunto apropiado de comandos es:
# apt-get update # apt-get remove nginx-plus-extras # apt-get install nginx-plus # apt-get install nombre-del-módulo
En el contexto principal (de nivel superior) en /etc/nginx/nginx.conf , agregue una directiva load_module
para cada módulo cargado dinámicamente:
Verifique la nueva configuración para verificar su validez sintáctica y vuelva a cargarla:
# nginx -t && nginx -s recargar
Si está ejecutando NGINX Plus, le recomendamos encarecidamente que actualice a la versión 10 lo antes posible. Recibirá una serie de correcciones y mejoras, y nos servirá para ayudarlo si necesita generar un ticket de soporte. Las instrucciones de instalación y actualización se pueden encontrar en el portal del cliente de NGINX Plus .
NOTA : NGINX Plus R10 es la última versión que incluirá el paquete nginx-plus-extras . Consulte El paquete de extras NGINX Plus está obsoleto , más arriba.
Si aún no ha probado NGINX Plus , le recomendamos que lo pruebe para aceleración web, equilibrio de carga y entrega de aplicação , o como un servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy de forma gratuita con una evaluación de 30 días y comprobar usted mismo cómo NGINX Plus puede ayudarle a ofrecer y escalar sus aplicações.
Para obtener más detalles sobre las nuevas características clave de NGINX Plus R10, consulte estos recursos relacionados:
[NGINX ModSecurity WAF oficialmente dejó de venderse el 1 de abril de 2022 y está en transición al fin de su vida útil a partir del 31 de marzo de 2024 . Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición hacia el fin de su vida útil en nuestro blog.]
"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.