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 servidor web de software completo, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os novos recursos do NGINX Plus R24 incluem:

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

Completando o lançamento, há persistência opcional em recargas de configuração dos resultados de verificações de integridade obrigatórias e valores dinâmicos para sinalizadores de cookies.

Mudanças importantes no comportamento

Módulo Cookie-Flag obsoleto

Conforme anunciado no lançamento do NGINX Plus R23 , o módulo Cookie-Flag de terceiros está obsoleto e será removido do repositório de módulos dinâmicos no NGINX Plus R26 . A diretiva set_cookie_flag definida naquele módulo é substituída pela diretiva proxy_cookie_flags . Recomendamos que você substitua quaisquer diretivas set_cookie_flag em sua configuração por diretivas proxy_cookie_flags o mais rápido possível. Veja também Sinalizadores de Cookies Dinâmicos .

Mudanças no suporte da plataforma

• Novos sistemas operacionais suportados :
  • 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 suportado; a versão mais antiga suportada é 10
• Sistemas operacionais mais antigos foram descontinuados e programados para remoção no NGINX Plus R25 :
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 depende do OpenSSL 1.1

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

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

Reorganizamos os repositórios de pacotes NGINX Plus, com alterações resultantes no procedimento de instalação.

A mudança na organização do repositório reflete a expansão do nosso portfólio de produtos e do ecossistema de produtos que dependem do NGINX Plus. Para o NGINX Plus em particular, 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 , você precisa atualizar o gerenciador de pacotes para fazer referência a pkgs.nginx.com/plus (mais o elemento de caminho final 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 do F5 . Para obter instruções atualizadas para a instalação inicial, consulte Instalando o NGINX Plus no Guia de administração do NGINX Plus.

Consolidação de diretivas de manipulação de conexão HTTP

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

Fechamento de conexão mais agressivo

No NGINX Plus R23 e 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 de conexões HTTP/2 com essas diretivas melhora os recursos gerais de HTTP/2 do NGINX Plus.

O NGINX Plus R24 modifica o efeito dessas diretivas de forma importante e elimina um possível bug: se o conjunto de conexões de trabalhadores livres estiver esgotado, o NGINX Plus começa 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 alterações de status de saúde 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 no qual as alterações de status são registradas foi alterado para servidores upstream HTTP e TCP/UDP ( stream ):

• A mudança de saudável para não saudável é registrada no nível de alerta (era info ).
• A mudança de não saudável para saudável é registrada no nível de notificação (era info ).

Novos recursos em detalhes

Tokens da Web JSON criptografados

O uso de JSON Web Tokens ( JWTs ) continua a crescer. Anteriormente, o NGINX Plus suportava tokens assinados (o padrão JSON Web Signature [JWS] definido no RFC 7515 ), que fornecem integridade de dados para as declarações codificadas no token. No entanto, o JWS não fornece confidencialidade para reivindicações – elas podem ser lidas por qualquer componente que tenha acesso ao token. TLS/SSL atenua a exposição de tokens em trânsito, mas tokens armazenados em navegadores da web e outros clientes ainda ficam expostos.

O NGINX Plus R24 apresenta suporte para tokens criptografados (o padrão JSON Web Encryption [JWE] definido no RFC 7516 ), que fornecem confidencialidade e integridade de dados para todo o conjunto de reivindicações. Informações confidenciais ou de identificação pessoal (PII) agora podem ser codificadas dentro de JWTs sem risco de vazamento desses dados por clientes inseguros.

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

Você define o algoritmo de criptografia (ou assinatura) e o uso da chave no arquivo de chave JWT nomeado pela diretiva auth_jwt_key_file . O NGINX Plus R24 e versões posteriores oferecem suporte aos seguintes métodos de criptografia.

Marco de maturidade importante para o módulo JavaScript NGINX

O NGINX Plus R24 marca um marco importante no desenvolvimento do módulo JavaScript NGINX (njs), agora em0.5.3 . Há dois aprimoramentos importantes que permitem estender o NGINX Plus com soluções personalizadas para uma ampla variedade de casos de uso:

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

Se você não estiver familiarizado com 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 NGINX. Para uma lista completa, consulte Casos de uso para o módulo JavaScript NGINX . ]

Filtragem de Resposta

Um dos recursos mais poderosos do NGINX Plus implantado como um gateway de API ou proxy reverso é a filtragem de resposta , que envolve a interceptação de respostas de servidores upstream e a substituição de strings no corpo da resposta, cabeçalhos ou ambos, com base na correspondência de expressões regulares. Para tráfego que não está sendo manipulado com o módulo NGINX JavaScript, a filtragem de resposta é implementada no módulo Substituição .

O NGINX Plus R24 apresenta uma implementação separada de filtragem de resposta dentro do módulo NGINX JavaScript, com duas diretivas que permitem que você aproveite o poder do JavaScript para analisar e modificar corpos e cabeçalhos de resposta. 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, para uma filtragem de resposta ainda mais poderosa do que com o módulo Substituição.

Filtrando corpos de resposta com a diretiva js_body_filter

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

• Procurando padrões complexos com expressões regulares
• Transformando formato de dados
• Inserindo conteúdo dinâmico em respostas

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

Para executar este código, precisamos simplesmente referenciar a função maskAwsKeys dentro do bloco de localização relevante.

Filtrando cabeçalhos de resposta com a diretiva js_header_filter

Você pode usar a diretiva js_header_filter para examinar – ou mesmo interceptar e modificar – o conteúdo dos cabeçalhos de resposta. Considere um servidor de backend que emite uma série de cabeçalhos Set-Cookie que contêm informações confidenciais, mas são essenciais para a operação correta. O NGINX Plus é capaz de interceptar a resposta, ler os cabeçalhos Set-Cookie e salvá-los no armazenamento de chave-valor. Um cabeçalho Set-Cookie de substituição pode ser criado como uma referência ao armazenamento de chave-valor e injetado na resposta original.

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

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

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

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 suporte a um poderoso conjunto de recursos de autenticação e controle de acesso na Camada 7 para solicitações HTTP, mas as implementações de API modernas também aproveitam o TCP/UDP como o protocolo subjacente, apresentando novos desafios de autenticação.

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

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

Observação:  A função ngx.fetch funciona com o módulo HTTP NGINX JavaScript, bem como com o módulo Stream NGINX JavaScript, mas tem limitações significativas em comparação com o objeto r.subrequest no módulo HTTP. Para a maioria dos casos de uso de HTTP, r.subrequest é o preferido, pois fornece suporte para conexões TLS, cache e todos os recursos do módulo Proxy .

Outros aprimoramentos do njs

Quando uma variável NGINX é definida com a diretiva set [ HTTP ][ Stream ] ou js_set [ HTTP ][ Stream ] , o 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 seu valor persista em redirecionamentos.

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

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

Integração com F5 Device ID+

O F5 Device ID+ é um identificador de dispositivo de alta precisão e em tempo real que utiliza coleta avançada de sinais e algoritmos comprovados de aprendizado de máquina para atribuir um identificador exclusivo a cada dispositivo que visita seu site. A implantação é simples, com benefícios imediatos para suas equipes de segurança, rede, fraude e digital. Nunca foi tão fácil entender os dispositivos exclusivos que visitam seus aplicativos.

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

Benefícios de usar o F5 Device ID+

• Fortaleça a segurança do aplicativo – Fortaleça sua análise de detecção e mitigação de ataques por meio da identificação precisa do dispositivo. Reconheça o retorno de dispositivos que seus sistemas de segurança já sinalizaram como suspeitos.
• Otimize o gerenciamento de tráfego – Incorpore um identificador de dispositivo exclusivo na lógica de roteamento para gerenciar e otimizar melhor o tráfego de rede. Identifique dispositivos mesmo quando agentes mal-intencionados manipulam dados da Camada 7.
• Reduza fraudes e riscos – Monitore o comportamento do cliente em operações como criação de novas contas, autenticação de usuários, checkout de comércio eletrônico e transações financeiras, detectando padrões anômalos que podem indicar roubo de identidade, entre outras ameaças.
• Personalize e acelere experiências on-line – Torne o login, o checkout e a autenticação perfeitos para usuários e dispositivos recorrentes conhecidos. Os testes A/B da F5 demonstram que a redução do atrito de segurança aumenta a receita, e a identificação do dispositivo é um elemento importante em qualquer estratégia para redução do atrito.

Como funciona o F5 Device ID+

Quando cada usuário visita seu site, o F5 Device ID+ utiliza JavaScript para coletar informações sobre o navegador, o sistema operacional do dispositivo, o hardware e a configuração de rede. Esses atributos alimentam o 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 já seja um dispositivo conhecido. Para dispositivos de devolução, comportamento, ações e outras propriedades podem ser registrados, aprendidos e estudados para facilitar a redução de fraudes e uma experiência tranquila para usuários conhecidos.

Outras melhorias no NGINX Plus R24

O status das verificações de integridade obrigatórias pode persistir em recargas de configuração

Verificações de integridade obrigatórias são usadas para permitir a inicialização lenta de servidores upstream que são adicionados usando a API NGINX Plus ou por meio da resolução de DNS. Eles garantem que os novos nós sejam primeiro verificados quanto à integridade e, em seguida, iniciados lentamente quando estiverem prontos para receber tráfego.

Anteriormente, após uma recarga de configuração, os servidores upstream eram considerados não íntegros, independentemente de seu status antes da recarga. Como resultado, os servidores não aceitaram solicitações de clientes até que a primeira verificação obrigatória fosse aprovada.

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

Bandeiras de cookies dinâmicas

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

Observação:  A diretiva proxy_cookie_flags descontinua 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 seguro quando o esquema é https em vez de http .

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R24 o mais rápido possível. Você também receberá diversas correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias .