Presentamos NGINX Plus R17

Liam CrillyDirector sénior de Gestión de Producto

[Editor – El módulo NGINX ModSecurity WAF para NGINX Plus dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]

Nos complace anunciar que NGINX Plus Release 17 (R17) ya está disponible. NGINX Plus es el único equilibrador de carga, caché de contenido, servidor web y puerta de enlace de API todo en uno. NGINX Plus se basa en NGINX Open Source e incluye funciones avanzadas exclusivas y un servicio de asistencia galardonado.

Esta versión incorpora compatibilidad con TLS 1.3, la versión más reciente del protocolo responsable de todo el tráfico seguro en Internet. Han pasado más de 10 años desde el lanzamiento de TLS 1.2 y muchas cosas han cambiado desde entonces. Se descubrieron numerosas vulnerabilidades de seguridad en TLS 1.2, como FREAK, Heartbleed, POODLE y ROBOT. Muchas de estas vulnerabilidades se debían a que TLS 1.2 ofrecía demasiadas opciones de configuración poco seguras, lo que dejaba los sitios expuestos a ataques.

TLS 1.3 mejora eliminando elementos innecesarios. Se han suprimido muchos cifrados inseguros y ahora el intercambio de claves Diffie-Hellman es obligatorio. El resultado es un TLS más ligero, rápido y seguro. En el momento de redactar este texto, Alpine Linux 3.9, FreeBSD 12.0 y Ubuntu 18.10 son compatibles con TLS 1.3, por lo que puede utilizarlos con NGINX Plus R17 para implementar TLS 1.3 en su entorno de producción; sin duda, otros proveedores de sistemas operativos admitirán TLS 1.3 en futuras versiones. Tenga en cuenta que F5 BIG-IP y otros balanceadores de carga de hardware no ofrecen actualmente compatibilidad total con TLS 1.3.

NGINX Plus R17 también incluye estas nuevas funciones:

• Limitación de velocidad en dos etapas – La limitación de velocidad es una de las funciones más populares de NGINX Open Source y NGINX Plus. Puede utilizarse para mitigar ataques DDoS y, en general, evitar que los servidores de aplicaciones se vean desbordados por un exceso de solicitudes. El nuevo parámetro delay permite que la limitación de velocidad de NGINX Plus se adapte mejor a los patrones de solicitudes habituales de los navegadores. Los métodos existentes de aplicación mediante retraso y rechazo ahora pueden combinarse para ofrecer una limitación de velocidad en dos etapas, de modo que las solicitudes excesivas se retrasan inicialmente y, en última instancia, se rechazan si se sigue superando el límite de velocidad.
• Configuración más sencilla de OpenID Connect – En NGINX Plus R15 introdujimos la integración con OpenID Connect para que nuestros clientes pudieran añadir el inicio de sesión único (SSO) a sus aplicaciones. En R17 hemos simplificado la configuración para obtener automáticamente las claves web JSON (JWK) del proveedor de identidad (IdP).
• NGINX ModSecurity WAF es el doble de rápido – NGINX ModSecurity WAF, un módulo dinámico para NGINX Plus basado en ModSecurity v3, ofrece una protección sólida contra ataques de capa 7. ModSecurity se encuentra en desarrollo activo y la última versión de NGINX ModSecurity WAF ofrece el doble de rendimiento y varias mejoras adicionales.

Mejoras adicionales en NGINX Plus R17 incluyen conexiones persistentes TCP con los servidores ascendentes, compatibilidad con SNI en entornos en clúster y mucho más.

Cambios importantes en el comportamiento

• NGINX Plus R13 presentó la nueva API de NGINX Plus para la recopilación de métricas y la reconfiguración dinámica de grupos de servidores upstream, que sustituyó a las API Status y Upstream Conf que anteriormente implementaban esas funciones. Tal como se anunció en su momento, las API obsoletas siguieron estando disponibles y recibiendo soporte durante un periodo considerable, que finalizó con NGINX Plus R16. Si su configuración incluye las directivas status o upstream_conf, debe sustituirlas por la directiva api como parte de la actualización a R17. Para obtener asesoramiento y ayuda con la migración a la API de NGINX Plus, consulte la guía de transición en nuestro blog o póngase en contacto con nuestro equipo de soporte.
• Nuevos sistemas operativos compatibles:
  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (Cosmic)
• Sistemas operativos antiguos eliminados o cuya eliminación está programada:
  • FreeBSD 10.4 y 11.1 ya no son compatibles.
  • La compatibilidad con CentOS/Oracle/RHEL 7.3 y versiones anteriores dejará de ofrecerse en NGINX Plus R18.
  • La compatibilidad con Ubuntu 14.04 dejará de ofrecerse en NGINX Plus R19.

Nuevas funcionalidades en detalle

TLS 1.3: sumar mediante la resta

Han pasado más de 10 años desde la última actualización importante de TLS. TLS 1.2 se definió en agosto de 2008 en el RFC 5246, y desde entonces Internet ha cambiado considerablemente. TLS 1.3 se ratificó en agosto de 2018 en el RFC 8446 para ayudar a resolver muchos de los problemas detectados en TLS 1.2 y establecer una plataforma más escalable de cara al futuro.

Más seguro

A lo largo de los años se han descubierto numerosas vulnerabilidades de seguridad en TLS 1.2, como FREAK, Heartbleed, POODLE y ROBOT. FREAK, por ejemplo, permite a un atacante degradar una conexión TLS para que utilice un cifrado de exportación con una clave de 40 bits, que puede descifrarse por fuerza bruta. TLS 1.3 elimina por completo los cifrados de exportación.

Muchos de los problemas que han surgido con TLS 1.2 y especificaciones anteriores se deben al gran número de opciones configurables por el usuario. El uso incorrecto de estas opciones solía dar lugar a configuraciones poco seguras que podían ser aprovechadas por los atacantes. TLS 1.3 elimina varias de estas opciones:

• AES‑CBC
• Grupos Diffie-Hellman arbitrarios
• Cifrados de exportación
• DES/3DES
• MD5
• Relleno PKCS#1 v1.5
• RC4
• Transporte de claves RSA (Diffie-Hellman es obligatorio)
• SHA‑1

Mejor rendimiento

Entre los elementos eliminados destaca el transporte de claves RSA. Este modo se utilizaba principalmente porque era más rápido que Diffie‑Hellman, que requería un viaje de ida y vuelta adicional para establecer la conexión con secreto perfecto hacia adelante (PFS). Con TLS 1.3, ese viaje adicional ya no es necesario. Al haber menos opciones de configuración, hay menos información que intercambiar y el protocolo de enlace Diffie‑Hellman solo necesita un viaje de ida y vuelta para completarse (el diagrama también muestra una solicitud GET después del protocolo de enlace).

TLS 1.3 mejora el rendimiento al reducir el número de intercambios necesarios para establecer una conexión segura

Además, TLS 1.3 admite la reanudación de sesión, que agiliza el establecimiento de la conexión al evitar la sobrecarga que supone repetir el protocolo de enlace TLS cuando un cliente vuelve a un sitio que ya había visitado. Esto también se denomina reanudación 0‑RTT (tiempo de ida y vuelta cero), ya que no es necesario intercambiar mensajes del protocolo de enlace entre el cliente y el servidor para reanudar la sesión. La reanudación de sesión se implementa creando un secreto compartido durante la sesión original y almacenándolo en un ticket de sesión. Cuando el cliente vuelve, presenta el ticket de sesión junto con su solicitud, que está cifrada con el secreto compartido incluido en el ticket.

TLS 1.3 permite reanudar rápidamente las sesiones TLS

El uso de 0‑RTT conlleva el riesgo de sufrir un ataque de repetición, como se ilustra a continuación. En este escenario, el atacante reenvía un paquete que provoca un cambio de estado, como una solicitud para transferir dinero entre dos cuentas bancarias.

Un ataque de repetición con 0-RTT

Para protegerse contra los ataques de repetición, el único tipo de solicitud HTTP que los clientes deben enviar en los datos 0‑RTT (los datos cifrados con el secreto compartido) es GET. Las solicitudes HTTP GET son idempotentes por definición (RFC 7231), por lo que repetirlas no tiene ningún efecto. Cargar una página suele ser lo primero que hace un cliente cuando vuelve a visitar un sitio, y la mayoría de las cargas de páginas comienzan con una solicitud GET, por lo que habilitar la reanudación de sesiones acelera una gran proporción de las solicitudes a la mayoría de los sitios web. Sin embargo, puede que no sea conveniente habilitar la reanudación 0‑RTT al implementar NGINX Plus como puerta de enlace de API, ya que, en el tráfico de API, es más probable que las sesiones TLS reanudadas contengan tipos de solicitudes no idempotentes.

TLS 1.3 también ofrece protección contra los ataques de repetición al incluir información temporal en el ticket de sesión y en la solicitud del cliente, lo que permite al servidor determinar si la solicitud llegó en un plazo razonable después de que el cliente la enviara. Un atacante no puede alterar la información temporal, por lo que, si la solicitud tardó demasiado en llegar, probablemente se trataba de una repetición.

Cómo habilitar TLS 1.3 en NGINX Plus

TLS 1.3 y 0‑RTT no están habilitados de forma predeterminada.

Para habilitar TLS 1.3, incluya el parámetro TLSv1.3 en la directiva ssl_protocols. Le recomendamos que incluya también TLSv1.2, ya que, en el momento de redactar este documento, no todos los navegadores son compatibles con TLS 1.3 (consulte la siguiente sección). NGINX Plus utiliza TLS 1.3 si el cliente lo admite; de lo contrario, recurre a TLS 1.2.

Para habilitar 0‑RTT, establezca también la directiva ssl_early_data en on.

Esta configuración habilita ambas funciones:

server {    listen 443 ssl;
    ssl_certificate     /etc/ssl/my_site_cert.pem;
    ssl_certificate_key /etc/ssl/my_site_key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_early_data on; # Enable 0-RTT (TLS 1.3)

    location / {
        proxy_pass http://my_backend;
    }
}

Plataformas compatibles

En el servidor, TLS 1.3 requiere OpenSSL 1.1.1 o una versión posterior. En el momento de redactar este texto, solo Alpine Linux 3.9, FreeBSD 12.0 y Ubuntu 18.10 incluyen OpenSSL 1.1.1.

En el lado del cliente, recomendamos Chrome 70 o Firefox 63. Ambos son compatibles con la versión final de TLS 1.3, pero no la activan de forma predeterminada; siga estas instrucciones para activar TLS 1.3 en el navegador. En el momento de redactar este texto, otros navegadores populares (incluidos Firefox para Android y Safari tanto para iOS como para Mac) aún no son compatibles con TLS 1.3. Para consultar la información más reciente sobre su compatibilidad, visite Can I Use: TLS 1.3.

Limitación de tasa en dos etapas

Anteriormente, NGINX Plus podía aplicar límites a la tasa de solicitudes de dos formas: rechazando de inmediato las solicitudes excesivas o poniéndolas en cola hasta que pudieran procesarse de acuerdo con el límite de tasa definido. Con NGINX Plus R17, puede combinar ambos métodos para aplicar una limitación de tasa en dos etapas, de modo que las solicitudes excesivas se retrasen inicialmente y, en última instancia, se rechacen si se sigue superando el límite de tasa.

Al aplicar límites de frecuencia, es fundamental tener en cuenta el comportamiento habitual de los clientes legítimos. Por ejemplo, los navegadores web suelen intentar descargar varios recursos simultáneamente, por lo que es normal recibir una solicitud del contenido HTML seguida rápidamente de solicitudes de hojas de estilo, código JavaScript e imágenes. Por este motivo, puede ser conveniente permitir una ráfaga de entre 10 y 20 solicitudes rápidas antes de aplicar un límite de frecuencia.

Con NGINX Plus R17, ahora puede permitir una ráfaga para adaptarse al patrón de solicitudes habitual de los navegadores web y, a continuación, retrasar las solicitudes excesivas adicionales hasta cierto punto, a partir del cual se rechazan. La limitación de velocidad en dos etapas se habilita con el nuevo parámetro «delay» de la directiva «limit_req».

Para ilustrar la limitación de velocidad en dos etapas, configuramos NGINX Plus para proteger un sitio web imponiendo un límite de 5 solicitudes por segundo (rate=5r/s). El sitio web suele tener entre 4 y 6 recursos por página, y nunca más de 12. La configuración permite ráfagas de hasta 12 solicitudes, de las cuales las primeras 8 se procesan sin demora. Después de 8 solicitudes excesivas, se añade una demora para aplicar el límite de 5 solicitudes por segundo. Después de 12 solicitudes excesivas, se rechazan todas las solicitudes adicionales.

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
server {
    listen 80;
    location / {
        limit_req zone=ip burst=12 delay=8;
        proxy_pass http://website;
    }
}

El parámetro «delay» define el punto a partir del cual, dentro del tamaño de la ráfaga, se limitan (retrasan) las solicitudes excesivas para cumplir con el límite de velocidad definido. Con esta configuración, un cliente que envíe un flujo continuo de solicitudes a 8 solicitudes/s experimentará el siguiente comportamiento.

Ilustración del comportamiento de limitación de velocidad con rate=5r/s burst=12 delay=8

Las primeras 8 solicitudes (el valor de delay) son procesadas por el proxy NGINX Plus sin demora. Las siguientes 4 solicitudes (burst - delay) se retrasan para no superar la tasa definida de 5 solicitudes/s. Las siguientes 3 solicitudes se rechazan porque se ha superado el tamaño total de la ráfaga. Las solicitudes posteriores se retrasan.

Tenga en cuenta que esta ilustración es una descripción simplificada del proceso, ya que no tiene en cuenta el efecto de las solicitudes completadas al calcular cuántas solicitudes excesivas se están procesando. En realidad, cada solicitud completada libera un espacio en la cola de espera para que pueda incluirse otra solicitud excesiva dentro del tamaño de ráfaga configurado. Para obtener más información sobre la implementación de la limitación de velocidad, consulte Limitación de velocidad con NGINX y NGINX Plus en nuestro blog.

Configuración más sencilla de OpenID Connect

Al realizar la validación de JWT, ahora se puede configurar NGINX Plus R17 para que obtenga el conjunto de claves web JSON (JWK) desde la ubicación remota (normalmente, un proveedor de identidades o IdP) especificada mediante la nueva directiva auth_jwt_key_request. La obtención automática resulta especialmente práctica al integrar un IdP que rota las claves con frecuencia.

La mayoría de los IdP proporcionan una URL fija desde la que se puede obtener el conjunto actual de claves, especialmente si admiten OpenID Connect Discovery; en ese caso, la URL de las claves viene definida por el valor jwks_uri.

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

Se pueden utilizar directivas de almacenamiento en caché adicionales para sobrescribir las cabeceras Expires y Cache-Control devueltas por la subsolicitud. El uso de proxy_cache_use_stale permite que NGINX Plus siga utilizando las claves almacenadas en caché cuando la URL de las claves no está disponible.

Nuestra implementación de referencia de OpenID Connect se ha actualizado para incluir compatibilidad con auth_jwt_key_request y la configuración automática de los IdP compatibles con OpenID Connect Discovery.

La compatibilidad con JWT también se ha ampliado para admitir dos variantes del algoritmo de firma digital de curva de Edwards (EdDSA): Ed448 y Ed25519. Tenga en cuenta que EdDSA requiere OpenSSL 1.1.1 o una versión posterior, que en el momento de redactar este texto solo está disponible en Ubuntu 18.10 y FreeBSD 12.0.

Nota: La compatibilidad con OpenID Connect es exclusiva de NGINX Plus.

WAF ModSecurity para NGINX 2 veces más rápido

El módulo NGINX ModSecurity WAF para NGINX Plus es nuestra compilación con soporte del firewall de aplicaciones web (WAF) ModSecurity de código abierto, utilizado por más de un millón de sitios web. Estamos colaborando activamente con el equipo de TrustWave SpiderLabs para mejorar el rendimiento de ModSecurity con NGINX Plus y nos complace anunciar que la última versión ofrece el doble de rendimiento que las versiones anteriores.

El WAF de NGINX protege contra ataques de capa 7

Esta versión también añade compatibilidad con pdateActionById, ctl:requestBodyProcessor=URLENCODED y la acción setenv.

La nueva compilación de NGINX ModSecurity WAF se basa en ModSecurity 3.0.3; para obtener más información, consulte el blog de TrustWave SpiderLabs.

Nota: NGINX ModSecurity WAF es exclusivo de NGINX Plus.

Otras funciones nuevas de NGINX Plus R17

Conexiones persistentes TCP con servidores upstream

La nueva directiva «proxy_socket_keepalive» controla si se habilitan los mensajes de mantenimiento de conexión TCP entre NGINX Plus y el servidor proxy. Estos mensajes mejoran el rendimiento de protocolos como WebSocket cuando hay un dispositivo de red TCP con estado entre NGINX y el servidor proxy, y las conexiones son de larga duración y suelen permanecer inactivas. Sin estos mensajes, dichos dispositivos podrían cerrar las conexiones TCP inactivas con mayor frecuencia, lo que conllevaría el coste adicional de restablecerlas desde cero.

La directiva también está disponible en los módulos FastCGI, gRPC, memcached, SCGI y uwsgi.

Tiempo de espera de keepalive y límite de solicitudes HTTP al servidor upstream

La nueva directiva keepalive_timeout establece el tiempo máximo de inactividad antes de que se cierre una conexión HTTP persistente entre NGINX Plus y el servidor proxy. Además, la directiva keepalive_requests establece el número máximo de solicitudes que se pueden enviar a través de una conexión persistente (momento en el que se cierra y se crea una nueva).

Tamaño finito de las sesiones UDP ascendentes

La nueva directiva proxy_requests (módulo Stream) establece el número máximo de paquetes UDP que NGINX Plus envía al servidor al que se redirige el tráfico antes de crear una nueva «sesión» UDP. Esto permite distribuir la carga de los paquetes UDP de forma más uniforme cuando un único cliente envía una gran cantidad de paquetes UDP en poco tiempo (algo que puede ocurrir, por ejemplo, cuando hay un proxy descendente).

Mejora del uso compartido del estado del clúster

Al usar el uso compartido de estado en un clúster, ahora puede verificar el nombre del servidor mediante SNI para transmitir dicho nombre al conectarse a los nodos del clúster. Esto se implementa mediante las directivas zone_sync_ssl_name y zone_sync_ssl_server_name.

Nota: Los clústeres y el módulo zone_sync son exclusivos de NGINX Plus

Actualizaciones del ecosistema de NGINX Plus

Mejoras del Ingress Controller

El controlador de entrada NGINX oficial para Kubernetes se ha actualizado a la versión 1.4.0. El registro de cambios enumera todos los cambios, correcciones y mejoras, y los más destacados se detallan en nuestro blog:

• Compatibilidad ampliada con Prometheus
• Equilibrado de carga TCP/UDP
• El algoritmo de balanceo de carga «Random with Two Choices» es ahora el predeterminado
• Anotaciones personalizadas

Obtén más información sobre el controlador de entrada NGINX oficial para Kubernetes en nuestro sitio web y en el repositorio de GitHub.

Mejoras del módulo de JavaScript

NGINX Plus R17 incluye varias mejoras que amplían el alcance de la compatibilidad con el lenguaje JavaScript:

• arguments objetos
• Fracciones no enteras
• Métodos adicionales para medir el tiempo: console.time() y console.timeEnd()
• Ahora se pueden volver a declarar variables y funciones

La integración con el módulo NGINX Stream para aplicaciones TCP/UDP se ha refactorizado para utilizar varias funciones de retorno, incluido un método send() para modificar el tráfico entrante. Ahora se puede acceder al tráfico saliente mediante una función de devolución de llamada.

La lista completa de cambios se puede consultar en el registro de cambios del módulo JavaScript de NGINX.

Actualiza o prueba NGINX Plus

NGINX Plus R17 incluye compatibilidad con TLS 1.3, que es más seguro y ofrece un mejor rendimiento que TLS 1.2. Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a la versión 17 y a TLS 1.3 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX, Inc. pueda ayudarle cuando necesite abrir una incidencia de soporte.

Revise detenidamente las nuevas funcionalidades y los cambios de comportamiento descritos en esta entrada del blog antes de proceder con la actualización.

Si aún no ha probado NGINX Plus ni NGINX ModSecurity WAF, 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 mejoradas de supervisión y gestión. Puede empezar hoy mismo de forma gratuita con una evaluación gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a distribuir y escalar sus aplicaciones.

[Editor – NGINX ModSecurity WAF dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly