Anunciamos NGINX Plus R17

[ 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 que NGINX Plus Release 17 (R17) ya está disponible. NGINX Plus es el único balanceador de carga, caché de contenido, servidor web y puerta de enlace API todo en uno. NGINX Plus se basa en NGINX Open Source e incluye funciones mejoradas exclusivas y soporte galardonado.

Una novedad de esta versión es la compatibilidad con TLS 1.3 , la última versión del protocolo responsable de todo el tráfico seguro en Internet. Han pasado más de 10 años desde que se lanzó TLS 1.2 y muchas cosas han cambiado desde entonces. Se encontraron numerosas vulnerabilidades de seguridad en TLS 1.2, como FREAK, Heartbleed, POODLE y ROBOT. Muchas de estas vulnerabilidades fueron el resultado de demasiadas opciones de configuración inseguras en TLS 1.2 que dejaron los sitios expuestos a ataques.

TLS 1.3 es suma por resta. Se han eliminado muchos cifrados inseguros y ahora es obligatorio el intercambio de claves Diffie-Hellman. El resultado es un TLS más ligero, más rápido y más seguro. Al momento de escribir este artículo, Alpine Linux 3.9, FreeBSD 12.0 y Ubuntu 18.10 admiten TLS 1.3, por lo que puede usarlos con NGINX Plus R17 para TLS 1.3 en su entorno de producción; otros proveedores de sistemas operativos seguramente admitirán TLS 1.3 en versiones futuras. Tenga en cuenta que F5 BIG-IP y otros balanceadores de carga de hardware actualmente no admiten TLS 1.3 en su totalidad.

NGINX Plus R17 también incluye estas nuevas características:

• Limitación de velocidad en dos etapas : la limitación de velocidad es una de las características más populares en NGINX Open Source y NGINX Plus. Se puede utilizar para mitigar ataques DDoS y, en general, proteger a los servidores de aplicação para que no se vean sobrecargados por demasiadas solicitudes. El nuevo parámetro de retraso ayuda a que NGINX Plus limite la velocidad para adaptarse mejor a los patrones de solicitud típicos del navegador. Los métodos existentes de cumplimiento de demoras y rechazos ahora se pueden combinar para proporcionar una limitación de velocidad en dos etapas, mediante la cual las solicitudes excesivas se demoran inicialmente y luego se rechazan en última instancia si aún se excede el límite de velocidad.
• Configuración más sencilla de OpenID Connect : en NGINX Plus R15 introdujimos la integración de OpenID Connect para permitir que nuestros clientes agreguen inicio de sesión único (SSO) a sus aplicações. En R17 hemos simplificado la configuración para obtener automáticamente claves web JSON (JWK) del proveedor de identidad (IdP).
• NGINX Modsecurity WAF es 2 veces más rápido : NGINX ModSecurity WAF, un módulo dinámico para NGINX Plus basado en ModSecurity v3, proporciona protección sólida contra ataques de capa 7. ModSecurity se está desarrollando activamente y la última versión de NGINX ModSecurity WAF ofrece un rendimiento dos veces mejor y una serie de mejoras adicionales.

Las mejoras adicionales en NGINX Plus R17 incluyen keepalives TCP a upstreams, soporte SNI en entornos agrupados y más.

Cambios importantes en el comportamiento

• NGINX Plus R13 introdujo la nueva API NGINX Plus para la recopilación de métricas y la reconfiguración dinámica de grupos ascendentes, reemplazando las API de estado y configuración ascendente que anteriormente implementaban esas funciones. Como se anunció en ese momento, las API obsoletas continuaron estando disponibles y recibiendo soporte durante un período de tiempo significativo, que finalizó con NGINX Plus R16 . Si su configuración incluye las directivas status y/o upstream_conf , debe reemplazarlas con la directiva api como parte de la actualización a R17.

  Para obtener asesoramiento y asistencia para migrar a la API NGINX Plus , consulte la guía de transición en nuestro blog o comuníquese con nuestro equipo de soporte.

• Nuevos sistemas operativos compatibles:

  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • Servidor empresarial SUSE Linux 15
  • Ubuntu 18.10 (Cósmico)

• Sistemas operativos antiguos eliminados o programados para ser eliminados:

  • FreeBSD 10.4 y 11.1 ya no reciben soporte.
  • El soporte para CentOS/Oracle/RHEL 7.3 y anteriores se suspenderá en NGINX Plus R18 .
  • El soporte para Ubuntu 14.04 se suspenderá en NGINX Plus R19 .

Nuevas funciones en detalle

TLS 1.3: Suma por resta

Han pasado más de 10 años desde una actualización importante de TLS. TLS 1.2 se definió en agosto de 2008 como RFC 5246 , e Internet ha cambiado significativamente desde entonces. TLS 1.3 fue ratificado en agosto de 2018 como RFC 8446 para ayudar a abordar muchos de los problemas encontrados en TLS 1.2 y establecer una plataforma más escalable para el futuro.

Más seguro

A lo largo de los años se han revelado 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 utilizar un cifrado de exportación con una longitud de clave de 40 bits, que puede ser atacado mediante 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 a la gran cantidad de opciones configurables por el usuario. El mal uso de las opciones a menudo conducía a configuraciones inseguras que los atacantes podían explotar. TLS 1.3 elimina varias de estas opciones:

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

Mejor rendimiento

En la lista de eliminaciones se destaca el transporte de claves RSA. Este modo se utilizó 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 directo perfecto (PFS). Con TLS 1.3 el viaje de ida y vuelta adicional ya no es necesario. Con menos opciones de configuración, hay menos información para intercambiar y el protocolo de enlace Diffie-Hellman solo requiere un viaje de ida y vuelta para completarse (el diagrama también muestra una solicitud GET después del protocolo de enlace).

Además, TLS 1.3 admite la reanudación de sesión , lo que hace que el establecimiento de la conexión sea más rápido al eliminar la sobrecarga de repetir el protocolo de enlace TLS cuando un cliente regresa a un sitio visitado anteriormente. Esto también se llama reanudación de 0-RTT (tiempo de ida y vuelta cero) , porque no es necesario que se envíen mensajes de protocolo de enlace entre el cliente y el servidor para la sesión reanudada. La reanudación de la 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 regresa, presenta el ticket de sesión junto con su solicitud, que está encriptada con el secreto compartido que está en el ticket.

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

Para protegerse contra 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 reproducirlas 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 sesión acelera una gran proporción de las solicitudes a la mayoría de los sitios web. Sin embargo, es posible que no desee habilitar la reanudación de 0-RTT al implementar NGINX Plus como puerta de enlace de API, ya que para el tráfico de API es más probable que las sesiones TLS reanudadas contengan tipos de solicitud no idempotentes.

TLS 1.3 también protege contra ataques de repetición al incluir información de tiempo en el ticket de sesión y la solicitud del cliente, lo que permite al servidor determinar si la solicitud llegó del cliente razonablemente pronto después de que el cliente la envió. Un atacante no puede alterar la información de tiempo, por lo que si la solicitud tardó demasiado en llegar, probablemente se repitió.

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 también incluya TLSv1.2 porque no todos los navegadores admiten TLS 1.3 al momento de escribir este artículo (consulte la siguiente sección). NGINX Plus usa TLS 1.3 si el cliente lo admite y recurre a TLS 1.2 en caso contrario.

Para habilitar 0-RTT, configure también la directiva ssl_early_data en on .

Esta configuración habilita ambas funciones:

servidor { escuchar 443 ssl; certificado_ssl /etc/ssl/my_site_cert.pem; clave_certificado_ssl /etc/ssl/my_site_key.pem; protocolos_ssl TLSv1.2 TLSv1.3 ; datos_tempranos_ssl en ; # Habilitar 0-RTT (TLS 1.3) ubicación / { contraseña_proxy http://my_backend; } }

Plataformas compatibles

En el lado del servidor, TLS 1.3 requiere OpenSSL 1.1.1 o posterior. Al momento de escribir este artículo, solo Alpine Linux 3.9, FreeBSD 12.0 y Ubuntu 18.10 vienen con OpenSSL 1.1.1.

Del lado del cliente, recomendamos Chrome 70 o Firefox 63. Admiten la versión final de TLS 1.3, pero no la habilitan de forma predeterminada; siga estas instrucciones para habilitar TLS 1.3 en el navegador . Al momento de escribir este artículo, otros navegadores populares (incluidos Firefox para Android y Safari para iOS y Mac) aún no admiten TLS 1.3. Para obtener la información de estado más reciente, consulte ¿Puedo usar? TLS 1.3 .

Limitación de velocidad en dos etapas

Anteriormente, NGINX Plus podía imponer límites en la tasa de solicitudes de dos maneras: rechazando solicitudes excesivas inmediatamente o poniendo en cola las solicitudes excesivas hasta que puedan procesarse de acuerdo con el límite de tasa definido. Con NGINX Plus R17 , puede combinar ambos métodos de cumplimiento para la limitación de velocidad en dos etapas, mediante la cual las solicitudes excesivas se retrasan inicialmente y, en última instancia, se rechazan si aún se excede el límite de velocidad.

Al aplicar límites de tarifas, es esencial considerar el comportamiento típico de los clientes legítimos. Por ejemplo, los navegadores web generalmente intentan descargar varios recursos simultáneamente, por lo que es razonable ver una solicitud de contenido HTML, seguida rápidamente por solicitudes de hojas de estilo, código JavaScript e imágenes. Por este motivo, es posible que queramos permitir una ráfaga de 10 a 20 solicitudes rápidas antes de aplicar un límite de velocidad.

Con NGINX Plus R17 ahora puede permitir una ráfaga para adaptarse al patrón de solicitud típico del navegador web y luego retrasar solicitudes excesivas adicionales hasta un punto, más allá del cual se rechazan las solicitudes excesivas adicionales. La limitación de velocidad de dos etapas se habilita con el nuevo parámetro de retardo en la directiva limit_req .

Para ilustrar la limitación de velocidad en dos etapas, aquí configuramos NGINX Plus para proteger un sitio web imponiendo un límite de velocidad de 5 solicitudes por segundo ( rate=5r/s ). El sitio web normalmente tiene entre 4 y 6 recursos por página, y nunca más de 12 recursos. La configuración permite ráfagas de hasta 12 solicitudes, las primeras 8 de las cuales se procesan sin demora. Se agrega un retraso después de 8 solicitudes excesivas para aplicar el límite de 5 r/s. Después de 12 solicitudes excesivas, cualquier solicitud adicional será rechazada.

zona_solicitud_límite $dirección_remota_binaria zona=ip:10m tasa=5r/s;
servidor {
escucha 80;
ubicación / {
zona_solicitud_límite zona=ip ráfaga=12 retardo=8;
contraseña_proxy http://sitio web;
}
}

El parámetro de retraso define el punto en el cual, dentro del tamaño de ráfaga, las solicitudes excesivas se limitan (retrasan) para cumplir con el límite de velocidad definido. Con esta configuración establecida, un cliente que realiza un flujo continuo de solicitudes a 8 r/s experimenta el siguiente comportamiento.

Las primeras 8 solicitudes (el valor de delay ) son procesadas por NGINX Plus sin demora. Las siguientes 4 solicitudes ( ráfaga - retraso ) se retrasan para que no se supere la velocidad definida de 5 r/s. Las siguientes 3 solicitudes se rechazan porque se ha excedido el tamaño total de la ráfaga. Las solicitudes posteriores sufren retrasos.

Tenga en cuenta que esta ilustración es una descripción simplificada del proceso porque ignora el impacto de las solicitudes completadas en el cálculo de cuántas solicitudes excesivas se están procesando. En realidad, cada solicitud completada abre un espacio en la cola de retraso para que otra solicitud excesiva se ajuste al tamaño de ráfaga configurado. Para obtener más información sobre la implementación de 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 JWT, NGINX Plus R17 ahora se puede configurar para obtener el conjunto de claves web JSON (JWK) de la ubicación remota (generalmente un proveedor de identidad o IdP) especificada por la nueva directiva auth_jwt_key_request . La obtención automática es particularmente conveniente cuando se integra con un IdP que rota claves con frecuencia.

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

# Crear un directorio para almacenar en caché las claves recibidas de IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

servidor {
list 80; # Usar SSL/TLS en producción

ubicación / {
auth_jwt "sitio cerrado";
auth_jwt_key_request /_jwks_uri; # Las claves se obtendrán mediante una subsolicitud

proxy_pass http://my_backend;
}

ubicación = /_jwks_uri {
interno;
proxy_cache jwk; # Almacenar en caché las respuestas
proxy_pass https://idp.example.com/oauth2/keys; # Obtener las claves desde aquí
}
}

Se pueden usar directivas de almacenamiento en caché adicionales para anular los encabezados Expires y Cache-Control devueltos por la subsolicitud. El uso de proxy_cache_use_stale permite que NGINX Plus continúe usando 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 soporte para auth_jwt_key_request y configuración automática para IdP que admiten 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 posterior, que al momento de escribir este artículo solo está disponible en Ubuntu 18.10 y FreeBSD 12.0.

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

WAF NGINX ModSecurity dos veces más rápido

El módulo NGINX ModSecurity WAF para NGINX Plus es nuestra compilación compatible del firewall de aplicação web (WAF) ModSecurity de código abierto utilizado por más de un millón de sitios. Estamos trabajando activamente con el equipo de TrustWave SpiderLabs para mejorar el rendimiento de ModSecurity con NGINX Plus y nos complace informar que la última versión funciona dos veces mejor que las versiones anteriores.

Esta versión también agrega soporte para 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 detalles, consulte el blog TrustWave SpiderLabs .

Nota:  NGINX ModSecurity WAF es exclusivo de NGINX Plus.

Otras nuevas funciones de NGINX Plus R17

Keepalives TCP a los upstreams

La nueva directiva proxy_socket_keepalive controla si los keepalives TCP están habilitados entre NGINX Plus y el servidor proxy. Los keepalives de TCP mejoran el rendimiento de los protocolos (como WebSocket) donde hay un dispositivo de red TCP con estado entre NGINX y el servidor proxy, con conexiones que son de larga duración y a menudo inactivas. Sin keepalives TCP, dichos dispositivos podrían cerrar conexiones TCP inactivas con mayor frecuencia, lo que generaría la sobrecarga 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 HTTP ascendente y límite de solicitudes

La nueva directiva keepalive_timeout establece el tiempo de inactividad máximo antes de que se cierre una conexión HTTP keepalive 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 keepalive (momento en el cual se cierra y se crea una nueva).

Tamaño finito de sesión UDP ascendente

La nueva directiva proxy_requests (módulo Stream) establece la cantidad máxima de paquetes UDP enviados desde NGINX Plus al servidor proxy antes de que se cree una nueva “sesión” UDP. Esto permite un equilibrio de carga más uniforme de los paquetes UDP cuando un solo cliente envía una gran cantidad de paquetes UDP en poco tiempo (lo que puede suceder cuando hay un proxy descendente, por ejemplo).

Mejora en el uso compartido del estado del clúster

Al usar el uso compartido de estado en un clúster, ahora puede realizar la verificación del nombre del servidor, usando SNI para pasar el nombre del servidor al conectarse a los nodos del clúster. Esto se implementa con las directivas zone_sync_ssl_name y zone_sync_ssl_server_name .

Nota:  La agrupación en clústeres y el módulo zone_sync son exclusivos de NGINX Plus

Actualizaciones del ecosistema NGINX Plus

Mejoras del controlador de Ingress

El controlador de ingreso oficial NGINX 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 notables se destacan en nuestro blog :

• Soporte extendido para Prometheus
• Equilibrio de carga TCP/UDP
• El algoritmo de equilibrio de carga aleatorio con dos opciones es el nuevo valor predeterminado
• Anotaciones personalizadas

Lea más sobre el controlador de ingreso NGINX oficial para Kubernetes en nuestro sitio web y en el repositorio de GitHub .

Mejoras del módulo JavaScript

NGINX Plus R17 incluye una serie de mejoras que amplían el alcance del soporte del lenguaje JavaScript:

• objetos de argumentos
• Fracciones no enteras
• Métodos de tiempo adicionales: console.time() y console.timeEnd()
• Ahora es posible volver a declarar variables y funciones

La integración con el módulo NGINX Stream para aplicações TCP/UDP se ha refactorizado para utilizar varias funciones de retorno, incluido un método send() para modificar el tráfico de ingreso. El tráfico de salida ahora está disponible a través de una devolución de llamada.

El conjunto completo de cambios se puede encontrar en el registro de cambios del módulo JavaScript de NGINX .

Actualice o pruebe NGINX Plus

NGINX Plus R17 incluye soporte para TLS 1.3, que es más seguro y funciona mejor que TLS 1.2. Si está ejecutando NGINX Plus, le recomendamos encarecidamente que actualice a la versión 17 y TLS 1.3 lo antes posible. También recibirá una serie de correcciones y mejoras adicionales, y ayudará a NGINX, Inc. a ayudarlo cuando necesite generar un ticket de soporte.

Revise atentamente las nuevas características y los cambios de comportamiento descritos en esta publicación del blog antes de continuar con la actualización.

Si no ha probado NGINX Plus o NGINX ModSecurity WAF , le recomendamos que los pruebe (por seguridad, equilibrio de carga y puerta de enlace de API, o como un servidor web totalmente compatible con API de administración y monitoreo mejoradas). Puede comenzar hoy mismo de forma gratuita con una evaluación gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.

[ Editor – 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 al final de su vida útil<.htmla> en nuestro blog.]