Anunciando o NGINX Plus R24

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 24 (R24). Baseado no NGINX Open Source, o NGINX Plus é o único software completo que reúne servidor web, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os novos recursos do NGINX Plus R24 incluem:

• Tokens Web JSON criptografados – Com base no suporte a Tokens Web JSON (JWTs) assinados em versões anteriores, o NGINX Plus agora oferece suporte a JWTs criptografados para garantir a confidencialidade e a integridade de dados de informações confidenciais armazenadas em navegadores da Web e outros clientes.
• Um marco importante no desenvolvimento do módulo JavaScript do NGINX – Novos recursos – em especial, a filtragem de respostas para cabeçalhos e corpos HTTP, além do suporte a serviços de autenticação baseados em HTTP para conexões e sessões TCP/UDP – possibilitam diversos novos e avançados casos de uso.
• Integração com o F5 Device ID+ – Esse identificador de dispositivos de alta precisão e em tempo real atribui um identificador exclusivo a cada dispositivo que visita seu site, permitindo maior proteção contra agentes mal-intencionados conhecidos e experiências de usuário personalizadas para visitantes recorrentes.

Para completar a versão estão a persistência opcional dos resultados das verificações de integridade obrigatórias durante recarregamentos de configuração e os valores dinâmicos para sinalizadores de cookies.

Mudanças importantes de comportamento

Módulo Cookie-Flag obsoleto

Conforme anunciado no lançamento do NGINX Plus R23, o módulo Cookie-Flag de terceiros foi descontinuado e será removido do repositório de módulos dinâmicos no NGINX Plus R26. A diretiva set_cookie_flag definida nesse módulo foi substituída pela diretiva proxy_cookie_flags. Recomendamos que você substitua todas as diretivas set_cookie_flag da sua configuração por diretivas proxy_cookie_flags o mais rápido possível. Consulte também Flags dinâmicas de cookies.

Alterações no suporte a plataformas

• Novos sistemas operacionais compatíveis:
  • Alpine Linux 3.13 (aarch64, amd64)
  • CentOS 7.4+ (aarch64, além de x86_64 e ppc64le)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• Sistemas operacionais mais antigos removidos:
  • O Debian 9 não é mais compatível; a versão mais antiga com suporte é a 10
• Sistemas operacionais mais antigos descontinuados e com remoção programada no NGINX Plus R25:
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

O Amazon Linux 2 depende do OpenSSL 1.1

O pacote NGINX Plus para o Amazon Linux 2 agora depende do OpenSSL 1.1, que habilita o TLS 1.3 e reforça a segurança de várias outras maneiras. Ao atualizar sistemas Amazon Linux 2 para o NGINX Plus R24, confirme se os outros softwares do sistema que usam o OpenSSL continuam funcionando corretamente com o OpenSSL 1.1.

Alterações no procedimento de instalação do NGINX Plus

Reorganizamos os repositórios de pacotes do NGINX Plus, o que resultou em alterações no procedimento de instalação.

A mudança na organização dos repositórios reflete a expansão do nosso portfólio de produtos e do ecossistema de produtos que dependem do NGINX Plus. Especificamente para o NGINX Plus, o repositório pkgs.nginx.com/plus substitui o antigo repositório plus-pkgs.nginx.com.

Ao instalar e atualizar o NGINX Plus, o gerenciador de pacotes do sistema operacional (apt, yum ou equivalente) é configurado com o repositório de software do NGINX Plus. Em sistemas existentes configurados para usar o repositório plus-pkgs.nginx.com, é necessário atualizar o gerenciador de pacotes para apontar para pkgs.nginx.com/plus (acrescentando o elemento final do caminho que indica o sistema operacional).

Para obter instruções sobre como atualizar um sistema existente para o NGINX Plus R24, consulte a Base de conhecimento da F5. Para obter instruções atualizadas sobre a instalação inicial, consulte Instalação do NGINX Plus no Guia de Administração do NGINX Plus.

Consolidação das diretivas de tratamento de conexões HTTP

À medida que o padrão HTTP/3 se aproxima da conclusão e o uso do HTTP/2 aumenta, simplificamos a configuração de conexões de longa duração. No NGINX Plus R24 e versões posteriores, as diretivas de configuração que antes se aplicavam apenas ao HTTP/1.1 também funcionam com o HTTP/2. Você não precisa mais usar diretivas diferentes para a mesma funcionalidade apenas porque a versão do protocolo é diferente.

Diretiva obsoleta Diretiva substitutahttp2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

Encerramento de conexões mais agressivo

No NGINX Plus R23 e versões posteriores, as diretivas lingering_close, lingering_time e lingering_timeout funcionam tanto para HTTP/2 quanto para HTTP/1.1. Configurar um tratamento mais eficiente das conexões HTTP/2 com essas diretivas aprimora os recursos gerais de HTTP/2 do NGINX Plus.

O NGINX Plus R24 modifica o efeito dessas diretivas de maneira importante e elimina um possível bug: se o pool de conexões livres dos processos de trabalho se esgotar, o NGINX Plus começará a fechar não apenas as conexões keepalive, mas também as conexões no modo lingering-close.

Nível de gravidade alterado para mudanças de status de integridade registradas

O NGINX grava uma entrada no log de erros quando o status de integridade de um servidor upstream muda – uma ferramenta importante para monitorar e analisar a integridade geral da sua infraestrutura. O nível de severidade usado para registrar as mudanças de status foi alterado tanto para servidores upstream HTTP quanto TCP/UDP (stream):

• A mudança de healthy para unhealthy é registrada no nível warn (anteriormente, info).
• A mudança de unhealthy para healthy é registrada no nível notice (anteriormente, info).

Novos recursos em detalhes

Tokens Web JSON criptografados

O uso de JSON Web Tokens (JWTs) continua crescendo. Anteriormente, o NGINX Plus oferecia suporte a tokens assinados (o padrão JSON Web Signature [JWS] definido na RFC 7515), que garantem a integridade dos dados das declarações codificadas no token. No entanto, o JWS não garante a confidencialidade das declarações, pois elas podem ser lidas por qualquer componente que tenha acesso ao token. O TLS/SSL reduz a exposição dos tokens em trânsito, mas os tokens armazenados em navegadores da Web e outros clientes continuam expostos.

O NGINX Plus R24 passa a oferecer suporte a tokens criptografados (o padrão JSON Web Encryption [JWE] definido na RFC 7516), que garantem tanto a confidencialidade quanto a integridade dos dados de todo o conjunto de declarações. Agora, informações confidenciais ou de identificação pessoal (PII) podem ser codificadas em JWTs sem o risco de esses dados serem vazados por clientes não seguros.

O NGINX Plus R24 e versões posteriores oferecem suporte a JWTs assinados e criptografados. Os tokens assinados são o padrão e não exigem configuração explícita. A nova diretiva auth_jwt_type configura a criptografia de JWTs.

Carregando exemplo de código…

Você define o algoritmo de criptografia (ou assinatura) e o uso da chave no arquivo de chaves JWT especificado pela diretiva auth_jwt_key_file. O NGINX Plus R24 e versões posteriores são compatíveis com os seguintes métodos de criptografia.

Algoritmos de gerenciamento de chaves JWE

• A128KW, A192KW, A256KW

• A128GCMKW, A192GCMKW, A256GCMKW

• dir – Configura o uso direto de uma chave simétrica compartilhada como chave de criptografia de conteúdo

Algoritmos de criptografia de conteúdo JWE

• A128CBC-HS256, A192CBC-HS384, A256CBC-HS512

• A128GCM, A192GCM, A256GCM

Marco importante de maturidade para o módulo JavaScript do NGINX

O NGINX Plus R24 representa um marco importante no desenvolvimento do módulo JavaScript do NGINX (njs), agora na versão 0.5.3. Há duas melhorias importantes que permitem estender o NGINX Plus com soluções personalizadas para uma ampla variedade de casos de uso:

• Filtragem de respostas para cabeçalhos e corpos de respostas HTTP
• Um cliente HTTP integrado que pode ser usado para fazer solicitações HTTP durante o processamento de HTTP ou TCP/UDP

Se você não conhece o módulo JavaScript do NGINX, leia esta introdução em nosso blog<.htmla>.

[Os casos de uso descritos nesta seção são apenas alguns dos muitos casos de uso do módulo JavaScript do NGINX. Para ver uma lista completa, consulte Casos de uso do módulo JavaScript do NGINX.]

Filtragem de respostas

Um dos recursos mais avançados do NGINX Plus quando implantado como gateway de API ou proxy reverso é a filtragem de respostas, que consiste em interceptar respostas de servidores upstream e substituir strings no corpo da resposta, nos cabeçalhos ou em ambos, com base na correspondência de expressões regulares. Para o tráfego que não está sendo manipulado com o módulo JavaScript do NGINX, a filtragem de respostas é implementada no módulo Substitution.

O NGINX Plus R24 apresenta uma implementação separada da filtragem de respostas no módulo JavaScript do NGINX, com duas diretivas que permitem aproveitar o poder do JavaScript para analisar e modificar corpos e cabeçalhos de respostas. O JavaScript amplia as possibilidades de inspeção e manipulação muito além da simples substituição de strings com base em expressões regulares, proporcionando uma filtragem de respostas ainda mais avançada do que a oferecida pelo módulo Substitution.

Filtragem de corpos de resposta com a diretiva js_body_filter Directive

Com a diretiva js_body_filter você pode usar JavaScript para inspecionar e modificar o corpo da resposta de um servidor com proxy. Os casos de uso incluem:

• Busca de padrões complexos com expressões regulares
• Transformação do formato dos dados
• Inserção de conteúdo dinâmico nas respostas

Neste exemplo, verificamos as respostas em busca de qualquer conteúdo que se pareça com uma chave de acesso da AWS e substituímos todas essas ocorrências por um valor mascarado.

Carregando exemplo de código…

Para executar esse código, basta referenciar a função maskAwsKeys dentro do bloco location relevante.

Carregando exemplo de código…

Filtrando cabeçalhos de resposta com a diretiva js_header_filter Directive

Você pode usar a diretiva js_header_filter para examinar — ou até mesmo interceptar e modificar — o conteúdo dos cabeçalhos de resposta. Considere um servidor de backend que emita vários cabeçalhos Set-Cookie que contenham informações confidenciais, mas sejam essenciais para o funcionamento correto. O NGINX Plus pode interceptar a resposta, ler os cabeçalhos Set-Cookie e salvá-los no armazenamento de chave-valor. Um cabeçalho Set-Cookie substituto pode ser criado como uma referência ao armazenamento de chave-valor e inserido na resposta original.

Fluxo de requisição mostrando js_header_filter interagindo com o armazenamento de chave-valor

Nas linhas 4 e 5 da configuração do NGINX Plus, definimos o armazenamento de chave-valor:

Carregando exemplo de código…

Em seguida, nas linhas 12–13, substituímos o cookie de referência pelo conteúdo do armazenamento de chave-valor e interceptamos todos os novos cookies com nosso código JavaScript.

Carregando exemplo de código…

O código JavaScript percorre cada novo cabeçalho de resposta Set-Cookie e cria uma nova entrada de chave-valor para armazená-lo.

Carregando exemplo de código…

Aproveitando serviços HTTP para TCP/UDP com um cliente HTTP simples

O principal caso de uso de um gateway de API é controlar o acesso a recursos específicos. O NGINX Plus oferece um conjunto avançado de recursos de autenticação e controle de acesso na Camada 7 para solicitações HTTP, mas as implementações modernas de APIs também utilizam TCP/UDP como protocolo subjacente, o que traz novos desafios de autenticação.

Com a função integrada do NGINX JavaScript ngx.fetch, agora você pode instanciar um cliente HTTP simples no contexto de uma conexão TCP/UDP. Isso permite usar serviços de autenticação baseados em HTTP para controle de acesso no contexto stream, por exemplo, chamando um daemon local do OpenPolicy Agent ao fazer proxy de uma conexão com um banco de dados.

Este exemplo demonstra o uso de um serviço local de autenticação HTTP na porta 8085 para autenticar cada nova conexão. A diretiva js_access e a função ngx.fetch implementam, em conjunto, no contexto HTTP recém-instanciado, uma funcionalidade semelhante à autorização de clientes com base no resultado de uma subsolicitação (conforme implementado pela diretiva auth_request para solicitações HTTP comuns). Com base no código de status HTTP disponível no Response objeto, a conexão com o banco de dados de backend é permitida (s.allow) ou rejeitada (s.deny).

Carregando exemplo de código…

Carregando exemplo de código…

Observação: A função ngx.fetch funciona tanto com o módulo HTTP do NGINX JavaScript quanto com o módulo Stream do NGINX JavaScript, mas apresenta limitações significativas em comparação com o objeto r.subrequest do módulo HTTP. Para a maioria dos casos de uso de HTTP, é preferível usar r.subrequest, pois ele oferece suporte a conexões TLS, cache e todos os recursos do módulo Proxy.

Outras melhorias do njs

Quando uma variável do NGINX é definida com a diretiva set [HTTP][Stream] ou js_set [HTTP][Stream], seu valor pode ser substituído quando o processamento da solicitação encontra um redirecionamento. A nova diretiva js_var [HTTP][Stream] permite que uma variável seja avaliada por uma função JavaScript e que seu valor seja mantido entre redirecionamentos.

O novo objeto njs.on permite que uma função JavaScript seja executada quando a máquina virtual njs é encerrada. Isso pode ser usado, por exemplo, para executar uma função ao final de uma conexão TCP.

A nova propriedade s.status do objeto de sessão Stream fornece acesso ao status geral da sessão (consulte $status para ver os valores possíveis).

Integração com o F5 Device ID+

O F5 Device ID+ é um identificador de dispositivos em tempo real e de alta precisão que utiliza coleta avançada de sinais e algoritmos comprovados de aprendizado de máquina para atribuir um identificador exclusivo a cada dispositivo que acessa seu site. A implantação é simples e oferece benefícios imediatos para suas equipes de segurança, redes, prevenção a fraudes e canais digitais. Nunca foi tão fácil identificar os dispositivos únicos que acessam suas aplicações.

Para obter instruções sobre como ativar o F5 Device ID+ em suas instâncias do NGINX Plus, consulte Mitigue fraudes e riscos com o F5 Device ID+.

Benefícios de usar o F5 Device ID+

• Reforce a segurança das aplicações – Aprimore sua análise de detecção e mitigação de ataques por meio da identificação precisa de dispositivos. Reconheça dispositivos recorrentes que seus sistemas de segurança já sinalizaram como suspeitos.
• Otimize o gerenciamento de tráfego – Incorpore um identificador exclusivo de dispositivo à lógica de roteamento para gerenciar e otimizar melhor o tráfego de rede. Identifique dispositivos mesmo quando agentes mal-intencionados manipularem dados da Camada 7.
• Mitigue fraudes e riscos – Monitore o comportamento dos clientes em operações como criação de novas contas, autenticação de usuários, finalização de compras no comércio eletrônico e transações financeiras, detectando padrões anômalos que possam indicar roubo de identidade, entre outras ameaças.
• Personalize e acelere as experiências online – Torne o login, a finalização da compra e a autenticação simples e fluidos para usuários recorrentes e dispositivos conhecidos. Testes A/B realizados pela F5 demonstram que reduzir os atritos de segurança aumenta a receita, e a identificação de dispositivos é um elemento importante em qualquer estratégia de redução de atritos.

Como o F5 Device ID+ funciona

Quando um usuário visita seu site, o F5 Device ID+ usa JavaScript para coletar informações sobre o navegador, o sistema operacional e o hardware do dispositivo, bem como a configuração da rede. Esses atributos são enviados ao serviço F5 Device ID+, desenvolvido com base nos recursos de IA e aprendizado de máquina reconhecidos pelo setor da F5 Shape. Os dados são processados em tempo real, e um identificador exclusivo é atribuído ao dispositivo, a menos que ele já seja conhecido. No caso de dispositivos recorrentes, o comportamento, as ações e outras propriedades podem ser registrados, assimilados e analisados para ajudar a reduzir fraudes e proporcionar uma experiência fluida aos usuários legítimos já conhecidos.

Outras melhorias no NGINX Plus R24

O status das verificações de integridade obrigatórias pode persistir após recarregamentos da configuração

As verificações de integridade obrigatórias são usadas para habilitar a inicialização lenta dos servidores upstream adicionados por meio da API do NGINX Plus ou da resolução de DNS. Elas garantem que a integridade dos novos nós seja verificada primeiro e que, quando estiverem prontos para receber tráfego, eles sejam inicializados lentamente.

Anteriormente, após o recarregamento da configuração, os servidores upstream eram considerados não íntegros, independentemente do status que apresentavam antes do recarregamento. Como resultado, os servidores não aceitavam solicitações de clientes até que a primeira verificação obrigatória fosse concluída com êxito.

Com o NGINX Plus R24, você pode marcar as verificações de integridade HTTP obrigatórias como persistentes, para que o estado anterior delas seja mantido quando a configuração for recarregada. Adicione o parâmetro persistent à diretiva health_check junto com o parâmetro mandatory.

Carregando exemplo de código…

Flags dinâmicas de cookies

Na versão anterior do NGINX Plus, introduzimos a diretiva proxy_cookie_flags como um método nativo para definir atributos de cookies. O NGINX Plus R24 amplia esse recurso ao permitir valores dinâmicos para os atributos de cookies. Isso permite que atributos específicos de cookies sejam controlados por variáveis do NGINX.

Observação: A diretiva proxy_cookie_flags torna obsoleto o módulo Cookie‑Flag, que será removido no NGINX Plus R26. Consulte Módulo Cookie‑Flag obsoleto.

Este exemplo usa um mapa para habilitar o sinalizador de cookie Secure quando o esquema é https em vez de http.

Carregando exemplo de código…

Faça upgrade ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R24 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que faça um teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias.

---