BLOG | NGINX

Anunciando o NGINX Plus R25

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Zach Westall
Zach Westall
Publicado em 28 de setembro de 2021

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 25 (R25) . 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 R25 incluem:

Mudanças importantes no comportamento

Aumento da necessidade de memória para zonas upstream

Conforme descrito em detalhes em Relatórios mais granulares de códigos de resposta HTTP , o NGINX Plus R25 fornece contagens de códigos de status individuais, bem como contagens agregadas por classe. Quando o NGINX Plus é configurado como um proxy reverso ou balanceador de carga, pode ser necessário aumentar o tamanho da zona de memória compartilhada usada para monitorar “pares” upstream (servidores de back-end), se houver mais de 20 pares.

O NGINX Plus R25 não inicia se as zonas de memória compartilhada estiverem subprovisionadas, causando falhas nas atualizações. Antes de atualizar, é importante verificar a utilização de memória de cada zona upstream. Para obter instruções sobre como verificar e ajustar a alocação de memória, consulte Alocar memória suficiente para evitar falhas de inicialização .

Alterações na organização e procedimento de instalação do repositório NGINX Plus

No lançamento do NGINX Plus R24 , os repositórios de pacotes para todos os softwares NGINX foram reorganizados, resultando em alterações no procedimento de instalação do NGINX Plus.

Ao instalar ou 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 antigo (aqueles executando o NGINX Plus R23 ou anterior), você precisa atualizar o gerenciador de pacotes para consultar o novo repositório. Veja as instruções na Base de Conhecimento F5 .

Se estiver executando uma instalação inicial do NGINX Plus R25 , consulte Instalando o NGINX Plus no Guia de administração do NGINX Plus .

Observação:  Você deve usar o novo repositório de software. O repositório antigo não será mais atualizado e pode causar erros em instalações e atualizações futuras.

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 integrada. Recomendamos que você substitua quaisquer diretivas set_cookie_flag em sua configuração por diretivas proxy_cookie_flags o mais rápido possível.

Mudanças no suporte da plataforma

  • Novos sistemas operacionais suportados:
    • Debian 11 (x86_64, aarch64)
    • Alpine Linux 3.14 (x86_64, aarch64)
  • Sistemas operacionais mais antigos removidos:
    • Alpine Linux 3.10; a versão mais antiga suportada é 3.11
    • Amazon Linux 1 (2018.03+); mudar para Amazon Linux 2 LTS
    • FreeBSD 11.4+; a versão mais antiga suportada é 12.1+
    • Ubuntu 16.04 LTS; a versão mais antiga suportada é 18.04 LTS
  • Sistemas operacionais mais antigos foram descontinuados e programados para remoção no NGINX Plus R26 :
    • Linux Alpino 3.11

Novos recursos em detalhes

Casos de uso e funcionalidade adicionais do JSON Web Token

O NGINX Plus R24 introduziu suporte inicial para JSON Web Tokens (JWE) criptografados, estendendo um dos métodos mais populares de autenticação de cliente com confidencialidade de dados. O NGINX Plus R25 se baseia nessa capacidade e apresenta suporte para casos de uso de autenticação adicionais e mais avançados que ajudam a melhorar a segurança da autenticação baseada em JWT para casos de uso assinados (JWS) e criptografados (JWE). Os aprimoramentos reduzem o risco de vazamento de informações de identificação pessoal (PII) e oferecem mais flexibilidade. A nova funcionalidade e os aprimoramentos do JWT para NGINX Plus incluem:

Variável para texto cifrado JWE descriptografado

JWTs são um método amplamente utilizado e confiável para autenticação sem estado de solicitações HTTP (ou seja, autenticação baseada em token). Ao transmitir atributos do usuário final na carga útil do token, os JWTs ajudam a tornar as solicitações mais seguras. No entanto, pesquisadores de segurança e profissionais de DevSecOps concordam que o risco apresentado pelo armazenamento de PII não criptografados em clientes da web é uma preocupação urgente – daí o desenvolvimento do padrão JSON Web Encryption (RFC 7516) , que fornece diretrizes para a implementação de tokens criptografados.

O NGINX Plus R24 introduziu suporte para JWE, fornecendo integridade de dados e confidencialidade para todo o conjunto de reivindicações. A codificação de PII no token criptografado reduz muito o risco de vazamentos de dados ao usar JWTs.

O NGINX Plus R25 se baseia no suporte inicial ao JWE com uma nova variável, $jwt_payload , que permite ao NGINX Plus descriptografar o JWE e o texto cifrado e, em seguida, acessar o texto simples durante o processamento da solicitação HTTP. Essa nova funcionalidade pode ser usada para implementar políticas avançadas de controle de acesso e decisões de roteamento de solicitações, além de permitir que os usuários implantem o NGINX Plus como uma camada de descriptografia JWE para aplicativos de back-end.

Suporte para JWTs aninhados

Os tokens JWE são eficazes na proteção de PII, com texto cifrado servindo para preservar a confidencialidade mesmo entre CDNs e outros proxies que terminam TLS. Mas a criptografia é uma faca de dois gumes, pois os JWEs podem introduzir complexidade no ambiente do aplicativo. Uma maneira de resolver esse problema é usar JWTs aninhados.

Diagrama mostrando a estrutura de um JWT aninhado
Anatomia de um JWT aninhado

JWTs aninhados incorporam JWS como o texto cifrado de um JWE. O NGINX Plus R25 habilita JWTs aninhados como um método para autenticar solicitações HTTP, oferecendo suporte a JWS e JWE simultaneamente. Em uma operação, o NGINX Plus agora pode descriptografar o texto cifrado no JWE, validar o texto simples resultante como um JWS e usar as declarações exp (tempo de expiração) e nbf (não antes) no token incluído para verificar se ele é válido. Isso permite que um ambiente JWS existente seja atualizado com criptografia de carga útil, envolvendo-o em um JWE.

O snippet de configuração a seguir ilustra o processo. O novo parâmetro aninhado na diretiva auth_jwt_type informa ao NGINX Plus para executar a descriptografia JWE e a validação JWS. Isso também afeta como as variáveis para cabeçalhos JWT e declarações JWT são avaliadas:

 

Com a configuração a seguir, o NGINX Plus constrói e envia cabeçalhos de solicitação HTTP adicionais para o aplicativo de backend. O algoritmo de criptografia do cabeçalho JWE (a variável $jwt_header_enc ) e a declaração de assunto JWT da carga útil JWS (a variável $jwt_claim_sub ) são representados por proxy com a solicitação original. Isso significa que os aplicativos podem aproveitar a autenticação baseada em JWE simplesmente consumindo cabeçalhos HTTP, sem necessidade de implementar código criptográfico ou bibliotecas.

 

Para usuários que operam em arquiteturas de confiança zero, a configuração a seguir permite que o aplicativo de backend valide o token JWS conforme capturado na variável $jwt_payload . A variável contém a versão em texto simples descriptografada do texto cifrado JWE. Se houver um JWT aninhado, o JWS poderá ser passado para o aplicativo de backend como um token portador.

 

Em essência, os JWTs aninhados simplificam as operações e melhoram a segurança dos aplicativos ao permitir que o NGINX Plus descriptografe e valide simultaneamente tokens seguros, tudo isso enquanto analisa ou faz proxy do token assinado “JWT regular” para aplicativos de back-end.

Criptografia assimétrica para JWE

O NGINX Plus R24 introduziu suporte para criptografia simétrica de tokens usando o padrão AES. O NGINX Plus R25 adiciona suporte para criptografia assimétrica ao usar pares de chaves RSA. A criptografia assimétrica usa chaves diferentes (pública e privada) para criptografia e descriptografia, que são matematicamente vinculadas entre si com o algoritmo RSA (Rivest–Shamir–Adleman) , o mesmo mecanismo usado para criptografia SSL/TLS do tráfego HTTPS entre cliente e servidor.

O NGINX Plus R25 oferece suporte a RSA com Optimal Asymmetric Encryption Padding (OEAP) como um algoritmo de gerenciamento de chaves, sem necessidade de configuração explícita no lado do NGINX Plus. Os valores suportados para o cabeçalho JWS alg (algoritmo) são RSA-OAEP , RSA-OAEP-256 , RSA-OAEP-384 e RSA-OAEP-512 .

A configuração a seguir mostra como tudo o que é necessário para implementar a criptografia assimétrica para JWE é especificar o arquivo JSON Web Key (JWK) que contém as chaves privadas RSA (desembrulhadas) como o parâmetro para a diretiva auth_jwt_key_file (a diretiva auth_jwt_key_request também pode ser usada).

 

Suporte JWK multifonte

Aproveitar JWTs aninhados significa que os JWKs associados provavelmente virão de mais de uma fonte. O NGINX Plus R25 suporta várias diretivas auth_jwt_key_file e auth_jwt_key_request no mesmo contexto. O NGINX Plus carrega chaves de todas as fontes especificadas e procura a chave de verificação correspondente entre o conjunto combinado de chaves — extremamente útil ao trabalhar com um JWS que foi emitido por um provedor de identidade externo e está aninhado dentro de um JWE, onde a criptografia foi feita por um processo separado.

Esse recurso adiciona mais flexibilidade, segurança e potência ao NGINX Plus implantado como um gateway de API.

Regras de validação JWT personalizadas

Quando o NGINX Plus é implantado como um gateway de API, é comum inspecionar declarações JWT para implementar controle de acesso refinado. Isso pode levar a configurações complexas. Em versões anteriores do NGINX Plus, você podia usar blocos de configuração if para avaliar declarações JWT, mas essa abordagem era um tanto limitada e não funcionava para tokens criptografados.

O NGINX Plus R25 resolve essa limitação fornecendo uma maneira nativa de realizar verificações adicionais no token durante o processo de validação do JWT. A diretiva auth_jwt_require adiciona uma etapa opcional e personalizável ao processo de validação do JWT. Ele aceita uma lista de strings separadas por espaços, todas as quais devem ser não vazias e não iguais a0 (zero) para que a validação do JWT seja bem-sucedida. Isso adiciona grande flexibilidade ao processo de validação do JWT.

O padrão JWT não prescreve quais declarações são obrigatórias, então você pode usar auth_jwt_require para listar as declarações apropriadas para cada ambiente.

A configuração a seguir garante que as declarações exp e sub estejam presentes em cada token.

 

Você pode configurar casos de uso mais complexos usando blocos de mapa ou o armazenamento de chave-valor do NGINX Plus para passar valores booleanos para a diretiva auth_jwt_require . Você também pode usar o módulo JavaScript NGINX para implementar soluções de autenticação avançadas, como tokens de acesso vinculados a certificados de cliente TLS mútuos (mTLS) (definidos em RFC 8705 ).

A configuração a seguir executa a autenticação de certificado de cliente (mTLS) e a validação de JWT. A diretiva auth_jwt_require na linha 14 solicita que a variável $thumbprint_match seja avaliada, e a validação do JWT será bem-sucedida somente se tiver um valor diferente de zero. Esta variável é avaliada executando a função JavaScript invocada na linha 2.

 

Aqui está o código para a função validate invocada na linha 2 do snippet anterior:

 

Relatórios mais granulares de códigos de resposta HTTP

Monitoramento e visibilidade são pilares do desempenho, disponibilidade e segurança do aplicativo. Os códigos de resposta HTTP são uma das fontes mais cruciais de informações sobre a integridade do aplicativo. A API do NGINX Plus rastreia códigos de resposta HTTP para interações entre o NGINX e os clientes, e entre o NGINX e os servidores upstream; as contagens são relatadas nas guias relevantes do painel de monitoramento de atividades ao vivo do NGINX Plus.

Versões anteriores da API NGINX Plus agregavam contagens de código de resposta HTTP por classe ( 2xx , 4xx e assim por diante). Agora os códigos também são contados individualmente ( 200,404 ,503 , etc.). Isso lhe dá uma visão mais profunda do que exatamente está acontecendo com um aplicativo – distinguindo entre erros que têm causas muito diferentes, como picos em autenticações com falha (403 ) e conteúdo ausente (404 ). Para obter informações sobre como configurar a coleta de métricas, consulte o Guia de administração do NGINX Plus .

A versão mais recente da API NGINX Plus ( versão 7 ), lançada com o NGINX Plus R25 , inclui um objeto de códigos dentro do objeto de respostas para permitir a contagem de códigos de resposta HTTP individuais. Respostas agregadas ainda estão disponíveis e versões anteriores da API NGINX Plus – que não incluem o objeto de códigos – ainda podem ser usadas com o NGINX Plus R25 . Aqui está um exemplo do novo conjunto de métricas:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "processando": 31, "pedidos": 63192, "respostas": { "1xx": 0, "2xx": 54368, "3xx": 8454, "4xx": 330, "5xx": 9, "códigos": { "200": 54368, "302": 8454, "401": 30, "404": 200, "429": 100, "503": 9 }, "total": 63161 }, "descartado": 0, "recebido": 693436, "enviado": 13843478 }

Aloque memória suficiente para evitar falhas de inicialização

Nota importante: Quando o NGINX Plus é configurado como um proxy reverso ou balanceador de carga, a contagem de códigos individuais aumenta a utilização de memória na zona de memória compartilhada para cada grupo upstream. Se houver mais de 20 pares no grupo upstream , talvez seja necessário aumentar o tamanho da memória, conforme configurado com a diretiva de zona .

O NGINX Plus R25 não inicia se as zonas upstream estiverem subprovisionadas, causando falhas nas atualizações.

Aqui está uma configuração típica da zona de memória compartilhada para um grupo upstream:

 

Antes de atualizar para o NGINX Plus R25 , é importante verificar a utilização de memória para zonas upstream existentes. Para fazer isso, certifique-se de que a API NGINX Plus esteja habilitada antes de usar um destes métodos:

  • Verifique a aba HTTP Upstreams do painel de monitoramento de atividades ao vivo, como neste exemplo de demo.nginx.com , onde a utilização é de 54%:

  • Use a API do NGINX Plus diretamente do host executando o seguinte comando. Primeiro:

    • Instale o utilitário jq se necessário
    • Defina a variável API para o local onde a diretiva api está habilitada
    $ API=http://localhost:8080/api; para i em `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; faça echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% usado"'; feito

Se a utilização atual estiver acima de 40% (como na captura de tela), aumente o segundo parâmetro (tamanho) da diretiva de zona em pelo menos 2,5x. Por exemplo, recomendamos aumentar de 64k para 160k no snippet de configuração acima.

Carregamento dinâmico de certificado de cliente SSL/TLS para proxy

TLS mútuo (mTLS) é uma prática de autenticação comum que envolve a verificação da identidade do cliente e do servidor. Com o NGINX Plus, você pode definir os servidores em um grupo upstream dinamicamente e com variáveis. Isso significa que você também pode precisar selecionar dinamicamente o certificado TLS usado pelo NGINX Plus para se verificar nesses servidores upstream.

O NGINX Plus R25 estende as diretivas de configuração usadas para mTLS para um servidor de backend, para aceitar uma variável que representa o certificado. A variável pode se referir a qualquer um destes:

  • Um arquivo no disco
  • Dados brutos em formato PEM, prefixados com data:

Isso permite que o NGINX Plus selecione um certificado e uma chave privada dinamicamente – útil para ambientes de aplicativos modernos que estão sujeitos a mudanças constantes. Você pode armazenar o certificado e a chave privada no armazenamento de chave-valor do NGINX Plus , o que aumenta a segurança porque a chave privada é armazenada na memória e não no disco. Outro caso de uso é a rotação automatizada de certificados, em que você usa uma chamada de API para atualizar certificados no armazenamento de chave-valor.

Na configuração a seguir, o NGINX Plus roteia solicitações para diferentes grupos upstream com base no nome do host. A conexão proxy é feita usando mTLS, e o certificado de cliente apropriado para cada upstream é selecionado dinamicamente.

 

As seguintes diretivas oferecem suporte ao carregamento dinâmico de certificados para mTLS com servidores upstream:

Segurança reforçada para processamento de solicitações HTTP

Um dos princípios fundamentais da filosofia NGINX é a melhoria contínua, especialmente no que diz respeito à segurança. Usamos todos os recursos disponíveis, incluindo colaboração com pesquisadores de segurança, integração das tecnologias de segurança líderes do setor da F5 em nossos produtos e esforços de desenvolvimento interno.

Como exemplo do último, o NGINX Plus R25 realiza diversas verificações adicionais em solicitações HTTP para proteger seus aplicativos contra possíveis ataques, como contrabando de solicitações . Ele retorna um erro para estas condições:

  • Uma solicitação HTTP/1.0 inclui o cabeçalho Transfer-Encoding
  • Os cabeçalhos Transfer-Encoding e Content-Length estão presentes
  • Existem espaços ou caracteres de controle na linha de solicitação ou em qualquer nome de cabeçalho
  • Há espaços ou caracteres de controle no cabeçalho do Host
  • O método CONNECT é usado

Além disso, os seguintes caracteres agora são sempre escapados em um URI com proxy: " , < , > , \ , ^ , ` , { , | , } .

Observe que essas alterações são melhorias proativas de segurança e não são feitas em resposta a nenhuma vulnerabilidade conhecida.

Persistência do status de verificação de integridade obrigatória na recarga para aplicativos TCP/UDP

O NGINX Plus usa verificações de integridade obrigatórias para garantir que novos servidores adicionados aos grupos upstream sejam testados e estejam íntegros antes que as solicitações do cliente sejam enviadas a eles por proxy. No NGINX Plus R23 e versões anteriores, os servidores upstream eram considerados não íntegros após uma recarga de configuração, independentemente de seu status antes da recarga. Como resultado, o NGINX Plus não enviou solicitações a um servidor até que a primeira verificação obrigatória fosse aprovada.

O NGINX Plus R24 introduziu a persistência opcional do status de verificação de integridade obrigatória em todas as recargas para aplicativos HTTP. Se a última verificação de integridade obrigatória antes de uma recarga tiver sido bem-sucedida, o NGINX Plus poderá enviar solicitações a um servidor imediatamente, em vez de ter que esperar que uma verificação de integridade obrigatória pós-recarga seja bem-sucedida.

O NGINX Plus R25 estende essa funcionalidade para aplicativos TCP/UDP (dentro do contexto de fluxo ). Quanto ao HTTP, adicione o parâmetro persistente à diretiva health_check junto com o parâmetro obrigatório .

 

Melhorias no módulo JavaScript NGINX

O módulo JavaScript NGINX (njs) foi atualizado para a versão 0.6.2 com várias correções de bugs e alguns aprimoramentos funcionais que fortalecem a compatibilidade com o JavaScript ES6 .

Declaração de variável com as palavras-chave let e const

O NGINX JavaScript agora oferece suporte à declaração de variáveis com escopo usando as palavras-chave let e const . Versões anteriores do NGINX Plus e njs suportavam apenas a palavra-chave var para declarar e atribuir variáveis. Isso não previa variáveis limitadas ao escopo de uma instrução de bloco específica, que são necessárias para lidar com a complexidade que geralmente surge quando diferentes projetos, linguagens de programação e equipes de engenharia colaboram em bases de código ou bibliotecas compartilhadas.

O JavaScript ES6 fornece as palavras-chave let e const para definir variáveis com escopo:

  • variáveis let são limitadas ao escopo de uma instrução de bloco ou de uma expressão na qual ela é usada. Em contraste, a palavra-chave var declara uma variável globalmente ou localmente para uma função inteira, independentemente do escopo do bloco.
  • As variáveis const são de escopo de bloco, assim como as variáveis declaradas usando a palavra-chave let . O valor de uma constante não pode ser alterado por meio de reatribuição e não pode ser redeclarado.

Suporte para todos os métodos do construtor Promise

Com a adição dos métodos construtores Promise.all() , Promise.allSettled() , Promise.any() e Promise.race() , o njs agora oferece suporte ao conjunto completo de métodos construtores definidos no padrão JavaScript ES6.

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R25 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 .

Leia mais postagens de blog sobre F5 NGINX›

"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."