Anunciando o NGINX Plus R17

Liam CrillyDiretor Sênior de Gestão de Produtos

[Editor – O módulo NGINX ModSecurity WAF para NGINX Plus deixou oficialmente de ser comercializado em 1º de abril de 2022 e entrará em fim de vida útil em 31 de março de 2024. Para mais detalhes, consulte F5 NGINX ModSecurity WAF está entrando em fim de vida útil<.htmla> em nosso blog.]

Temos o prazer de anunciar que o NGINX Plus Release 17 (R17) já está disponível. O NGINX Plus é a única solução completa que reúne balanceador de carga, cache de conteúdo, servidor web e gateway de API. O NGINX Plus é baseado no NGINX Open Source e inclui recursos avançados exclusivos e suporte premiado.

A novidade desta versão é o suporte ao TLS 1.3, a versão mais recente do protocolo responsável por todo o tráfego seguro na Internet. Já se passaram mais de 10 anos desde o lançamento do TLS 1.2, e muita coisa mudou desde então. Foram encontradas diversas vulnerabilidades de segurança no TLS 1.2, como FREAK, Heartbleed, POODLE e ROBOT. Muitas dessas vulnerabilidades resultaram do excesso de opções de configuração inseguras no TLS 1.2, que deixavam os sites expostos a ataques.

O TLS 1.3 faz mais com menos. Muitas cifras inseguras foram removidas, e a troca de chaves Diffie‑Hellman agora é obrigatória. O resultado é um TLS mais enxuto, rápido e seguro. No momento da redação deste texto, Alpine Linux 3.9, FreeBSD 12.0 e Ubuntu 18.10 oferecem suporte ao TLS 1.3, portanto, você pode usá-los com o NGINX Plus R17 para implementar o TLS 1.3 em seu ambiente de produção; sem dúvida, outros fornecedores de sistemas operacionais oferecerão suporte ao TLS 1.3 em versões futuras. Observe que F5 BIG-IP e outros balanceadores de carga de hardware ainda não oferecem suporte completo ao TLS 1.3.

O NGINX Plus R17 também inclui estes novos recursos:

• Limitação de taxa em dois estágios – A limitação de taxa é um dos recursos mais populares do NGINX Open Source e do NGINX Plus. Ela pode ser usada para mitigar ataques DDoS e, de modo geral, evitar que os servidores de aplicações sejam sobrecarregados por um número excessivo de solicitações. O novo parâmetro delay ajuda a limitação de taxa do NGINX Plus a se adaptar melhor aos padrões típicos de solicitações dos navegadores. Os métodos existentes de aplicação de atraso e rejeição agora podem ser combinados para oferecer limitação de taxa em dois estágios, na qual as solicitações excedentes são inicialmente atrasadas e, por fim, rejeitadas caso o limite de taxa continue sendo excedido.
• Configuração mais fácil do OpenID Connect – No NGINX Plus R15, introduzimos a integração com o OpenID Connect para permitir que nossos clientes adicionem o logon único (SSO) aos seus aplicativos. No R17, simplificamos a configuração para buscar automaticamente as chaves Web JSON (JWKs) do provedor de identidade (IdP).
• O NGINX ModSecurity WAF está 2 vezes mais rápido – O NGINX ModSecurity WAF, um módulo dinâmico para o NGINX Plus baseado no ModSecurity v3, oferece proteção robusta contra ataques à camada 7. O ModSecurity está em desenvolvimento ativo, e a versão mais recente do NGINX ModSecurity WAF oferece desempenho 2 vezes melhor e várias outras melhorias.

Aprimoramentos adicionais no NGINX Plus R17 incluem conexões TCP keepalive com servidores upstream, suporte a SNI em ambientes de cluster e muito mais.

Mudanças importantes no comportamento

• O NGINX Plus R13 introduziu a nova API do NGINX Plus para coleta de métricas e reconfiguração dinâmica de grupos de upstream, substituindo as APIs Status e Upstream Conf, que anteriormente implementavam essas funções. Conforme anunciado na época, as APIs obsoletas continuaram disponíveis e com suporte por um período significativo, que terminou com o NGINX Plus R16. Se a sua configuração incluir as diretivas status e/ou upstream_conf, você deverá substituí-las pela diretiva api como parte da atualização para a R17. Para obter orientações e assistência na migração para a API do NGINX Plus, consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.
• Novos sistemas operacionais compatíveis:
  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (Cosmic)
• Sistemas operacionais mais antigos removidos ou com remoção programada:
  • O FreeBSD 10.4 e o 11.1 não são mais compatíveis.
  • O suporte ao CentOS/Oracle/RHEL 7.3 e versões anteriores será descontinuado no NGINX Plus R18.
  • O suporte ao Ubuntu 14.04 será descontinuado no NGINX Plus R19.

Novos recursos em detalhes

TLS 1.3: Adição por subtração

Já se passaram mais de 10 anos desde uma grande atualização do TLS. O TLS 1.2 foi definido em agosto de 2008 como RFC 5246, e a Internet mudou significativamente desde então. O TLS 1.3 foi ratificado em agosto de 2018 como RFC 8446 para ajudar a solucionar muitos dos problemas encontrados no TLS 1.2 e estabelecer uma plataforma mais escalável para o futuro.

Mais seguro

Ao longo dos anos, diversas vulnerabilidades de segurança no TLS 1.2 foram divulgadas, como FREAK, Heartbleed, POODLE e ROBOT. O FREAK, por exemplo, permite que um invasor rebaixe uma conexão TLS para usar uma cifra de exportação com uma chave de 40 bits, que pode ser quebrada por força bruta. O TLS 1.3 elimina completamente as cifras de exportação.

Muitos dos problemas que surgiram com o TLS 1.2 e especificações anteriores se devem ao grande número de opções configuráveis pelo usuário. O uso incorreto dessas opções frequentemente resultava em configurações inseguras que podiam ser exploradas por invasores. O TLS 1.3 elimina várias dessas opções:

• AES‑CBC
• Grupos Diffie‑Hellman arbitrários
• Cifras de exportação
• DES/3DES
• MD5
• Preenchimento PKCS#1 v1.5
• RC4
• Transporte de chaves RSA (Diffie-Hellman é obrigatório)
• SHA‑1

Melhor desempenho

Um item de destaque na lista de recursos removidos é o transporte de chaves RSA. Esse modo era usado principalmente por ser mais rápido que o Diffie-Hellman, que exigia uma viagem de ida e volta adicional para estabelecer a conexão com sigilo de encaminhamento perfeito (PFS). Com o TLS 1.3, essa viagem adicional não é mais necessária. Com menos opções de configuração, há menos informações a serem trocadas, e o handshake Diffie-Hellman precisa de apenas uma viagem de ida e volta para ser concluído (o diagrama também mostra uma solicitação GET após o handshake).

O TLS 1.3 melhora o desempenho ao reduzir o número de viagens de ida e volta necessárias para estabelecer uma conexão segura

Além disso, o TLS 1.3 oferece suporte à retomada de sessão, que agiliza o estabelecimento da conexão ao eliminar a sobrecarga de repetir o handshake TLS quando um cliente retorna a um site visitado anteriormente. Isso também é chamado de retomada 0‑RTT (tempo de ida e volta zero), pois nenhuma mensagem de handshake precisa ser trocada entre o cliente e o servidor para retomar a sessão. A retomada de sessão é implementada por meio da criação de um segredo compartilhado durante a sessão original e de seu armazenamento em um tíquete de sessão. Quando o cliente retorna, ele apresenta o tíquete de sessão junto com sua solicitação, que é criptografada com o segredo compartilhado contido no tíquete.

O TLS 1.3 permite a retomada rápida de sessões TLS

O uso de 0‑RTT cria o risco de um ataque de repetição, conforme ilustrado abaixo. Nesse cenário, o invasor reenvia um pacote que resulta em uma mudança de estado, como uma solicitação para transferir dinheiro entre duas contas bancárias.

Um ataque de repetição com 0-RTT

Para se proteger contra ataques de repetição, o único tipo de solicitação HTTP que os clientes devem enviar nos dados 0‑RTT (os dados criptografados com o segredo compartilhado) é GET. As solicitações HTTP GET são idempotentes por definição (RFC 7231), portanto, repeti-las não produz nenhum efeito. Carregar uma página geralmente é a primeira coisa que um cliente faz ao revisitar um site, e a maioria dos carregamentos de página começa com uma solicitação GET. Assim, habilitar a retomada de sessão acelera uma grande proporção das solicitações para a maioria dos sites. No entanto, talvez você não queira habilitar a retomada 0‑RTT ao implantar o NGINX Plus como um gateway de API, pois, no tráfego de API, é mais provável que as sessões TLS retomadas contenham tipos de solicitação não idempotentes.

O próprio TLS 1.3 também oferece proteção contra ataques de repetição ao incluir informações de tempo no tíquete de sessão e na solicitação do cliente, permitindo que o servidor determine se a solicitação chegou em um intervalo razoavelmente curto após ter sido enviada pelo cliente. Um invasor não pode alterar as informações de tempo; portanto, se a solicitação demorou muito para chegar, provavelmente foi repetida.

Como habilitar o TLS 1.3 no NGINX Plus

O TLS 1.3 e o 0‑RTT não são habilitados por padrão.

Para habilitar o TLS 1.3, inclua o parâmetro TLSv1.3 na diretiva ssl_protocols. Recomendamos que você também inclua TLSv1.2, pois, no momento da redação deste texto, nem todos os navegadores oferecem suporte ao TLS 1.3 (consulte a próxima seção). O NGINX Plus usa o TLS 1.3 se o cliente oferecer suporte a ele; caso contrário, usa o TLS 1.2.

Para habilitar o 0‑RTT, defina também a diretiva ssl_early_data como on.

Esta configuração habilita ambos os recursos:

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 compatíveis

No lado do servidor, o TLS 1.3 requer o OpenSSL 1.1.1 ou posterior. No momento em que este texto foi escrito, apenas o Alpine Linux 3.9, o FreeBSD 12.0 e o Ubuntu 18.10 são fornecidos com o OpenSSL 1.1.1.

No lado do cliente, recomendamos o Chrome 70 ou o Firefox 63. Eles são compatíveis com a versão final do TLS 1.3, mas não a habilitam por padrão; siga estas instruções para habilitar o TLS 1.3 no navegador. No momento da redação deste texto, outros navegadores populares (incluindo o Firefox para Android e o Safari para iOS e Mac) ainda não são compatíveis com o TLS 1.3. Para obter as informações mais recentes sobre a compatibilidade, consulte Can I Use: TLS 1.3.

Limitação de taxa em dois estágios

Anteriormente, o NGINX Plus podia impor limites à taxa de solicitações de duas maneiras: rejeitando imediatamente as solicitações excedentes ou colocando-as em uma fila até que pudessem ser processadas em conformidade com o limite de taxa definido. Com o NGINX Plus R17, é possível combinar os dois métodos de imposição para implementar a limitação de taxa em dois estágios, na qual as solicitações excedentes são inicialmente adiadas e, por fim, rejeitadas caso o limite de taxa continue sendo excedido.

Ao aplicar limites de taxa, é essencial considerar o comportamento típico dos clientes legítimos. Por exemplo, os navegadores geralmente tentam baixar vários recursos simultaneamente, portanto, é normal receber uma solicitação de conteúdo HTML seguida rapidamente por solicitações de folhas de estilo, código JavaScript e imagens. Por esse motivo, talvez seja conveniente permitir uma rajada de 10 a 20 solicitações rápidas antes de aplicar um limite de taxa.

Com o NGINX Plus R17, agora você pode permitir uma rajada para acomodar o padrão típico de solicitações dos navegadores da Web e, em seguida, atrasar solicitações excessivas adicionais até certo ponto, após o qual elas serão rejeitadas. A limitação de taxa em dois estágios é habilitada com o novo parâmetro delay da diretiva limit_req.

Para ilustrar a limitação de taxa em dois estágios, configuramos aqui o NGINX Plus para proteger um site impondo um limite de 5 solicitações por segundo (rate=5r/s). O site normalmente tem de 4 a 6 recursos por página e nunca mais de 12 recursos. A configuração permite picos de até 12 solicitações, sendo que as primeiras 8 são processadas sem atraso. Após 8 solicitações excedentes, é adicionado um atraso para aplicar o limite de 5 solicitações/s. Após 12 solicitações excedentes, todas as solicitações adicionais são rejeitadas.

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;
    }
}

O parâmetro delay define o ponto, dentro do tamanho da rajada, a partir do qual as solicitações excedentes são limitadas (atrasadas) para cumprir o limite de taxa definido. Com essa configuração, um cliente que envia um fluxo contínuo de solicitações a 8 solicitações/s apresenta o seguinte comportamento.

Ilustração do comportamento da limitação de taxa com rate=5r/s burst=12 delay=8

As primeiras 8 solicitações (o valor de delay) são encaminhadas pelo NGINX Plus sem atraso. As 4 solicitações seguintes (burst - delay) são atrasadas para que a taxa definida de 5 r/s não seja excedida. As 3 solicitações seguintes são rejeitadas porque o tamanho total da rajada foi excedido. As solicitações subsequentes são atrasadas.

Observe que esta ilustração é uma descrição simplificada do processo, pois ignora o impacto das solicitações concluídas no cálculo de quantas solicitações excedentes estão sendo processadas. Na prática, cada solicitação concluída libera uma posição na fila de espera, permitindo que outra solicitação excedente seja acomodada dentro do tamanho de burst configurado. Para obter mais informações sobre a implementação da limitação de taxa, consulte Limitação de taxa com o NGINX e o NGINX Plus em nosso blog.

Configuração mais fácil do OpenID Connect

Ao realizar a validação de JWT, o NGINX Plus R17 agora pode ser configurado para buscar o conjunto de chaves Web JSON (JWKs) no local remoto (geralmente um provedor de identidade, ou IdP) especificado pela nova diretiva auth_jwt_key_request. A busca automática é particularmente conveniente ao integrar com um IdP que alterna as chaves com frequência.

A maioria dos IdPs fornece uma URL fixa na qual é possível obter o conjunto atual de chaves, especialmente se houver suporte à OpenID Connect Discovery; nesse caso, a URL das chaves é definida pelo 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
    }
}

Diretivas adicionais de cache podem ser usadas para substituir os cabeçalhos Expires e Cache-Control retornados pela subsolicitação. O uso de proxy_cache_use_stale permite que o NGINX Plus continue usando as chaves armazenadas em cache quando a URL das chaves estiver indisponível.

Nossa implementação de referência do OpenID Connect foi atualizada para incluir suporte a auth_jwt_key_request e configuração automática para IdPs compatíveis com o OpenID Connect Discovery.

O suporte a JWT também foi ampliado para incluir duas variantes do Algoritmo de Assinatura Digital de Curva de Edwards (EdDSA): Ed448 e Ed25519. Observe que o EdDSA requer o OpenSSL 1.1.1 ou posterior, que, no momento da redação deste texto, está disponível apenas no Ubuntu 18.10 e no FreeBSD 12.0.

Observação: O suporte ao OpenID Connect é exclusivo do NGINX Plus.

NGINX ModSecurity WAF 2x mais rápido

O módulo NGINX ModSecurity WAF para o NGINX Plus é a nossa versão com suporte do firewall de aplicações web (WAF) ModSecurity de código aberto, usado por mais de um milhão de sites. Estamos trabalhando ativamente com a equipe do TrustWave SpiderLabs para melhorar o desempenho do ModSecurity com o NGINX Plus e temos a satisfação de informar que a versão mais recente apresenta um desempenho duas vezes melhor que o das versões anteriores.

O NGINX WAF protege contra ataques à camada 7

Esta versão também adiciona suporte a pdateActionById, ctl:requestBodyProcessor=URLENCODED e à ação setenv.

A nova compilação do NGINX ModSecurity WAF é baseada no ModSecurity 3.0.3; para obter mais detalhes, consulte o blog da TrustWave SpiderLabs.

Observação: O NGINX ModSecurity WAF é exclusivo do NGINX Plus.

Outros novos recursos do NGINX Plus R17

Keepalives TCP para servidores upstream

A nova diretiva proxy_socket_keepalive controla se os keepalives TCP são habilitados entre o NGINX Plus e o servidor que recebe o proxy. Os keepalives TCP melhoram o desempenho de protocolos (como o WebSocket) quando há um dispositivo de rede TCP com estado entre o NGINX e o servidor que recebe o proxy, com conexões de longa duração e frequentemente ociosas. Sem os keepalives TCP, esses dispositivos podem fechar conexões TCP ociosas com mais frequência, gerando a sobrecarga de restabelecê-las do zero.

A diretiva também está disponível nos módulos FastCGI, gRPC, memcached, SCGI e uwsgi.

Tempo limite de keepalive e limite de requisições HTTP upstream

A nova diretiva keepalive_timeout define o tempo máximo de inatividade antes que uma conexão HTTP keepalive entre o NGINX Plus e o servidor proxy seja encerrada. Além disso, a diretiva keepalive_requests define o número máximo de solicitações que podem ser enviadas por uma conexão keepalive (quando esse limite é atingido, ela é encerrada e uma nova conexão é criada).

Tamanho finito da sessão UDP upstream

A nova diretiva proxy_requests (módulo Stream) define o número máximo de pacotes UDP enviados do NGINX Plus ao servidor com proxy antes que uma nova “sessão” UDP seja criada. Isso proporciona um balanceamento de carga mais uniforme dos pacotes UDP quando um único cliente envia um grande número de pacotes UDP em um curto período (o que pode acontecer, por exemplo, quando há um proxy downstream).

Aprimoramento do compartilhamento de estado do cluster

Ao usar o compartilhamento de estado em um cluster, agora é possível verificar o nome do servidor usando SNI para transmitir esse nome ao se conectar aos nós do cluster. Isso é implementado com as diretivas zone_sync_ssl_name e zone_sync_ssl_server_name.

Observação: O clustering e o módulo zone_sync são exclusivos do NGINX Plus

Atualizações no ecossistema do NGINX Plus

Aprimoramentos do Ingress Controller

O NGINX Ingress Controller oficial para Kubernetes foi atualizado para a versão 1.4.0. O registro de alterações lista todas as mudanças, correções e melhorias, e as mais relevantes são destacadas em nosso blog:

• Suporte ampliado ao Prometheus
• Balanceamento de carga TCP/UDP
• O algoritmo de balanceamento de carga Random with Two Choices é o novo padrão
• Anotações personalizadas

Saiba mais sobre o NGINX Ingress Controller oficial para Kubernetes em nosso site e no repositório do GitHub.

Aprimoramentos do módulo JavaScript

O NGINX Plus R17 inclui diversas melhorias que ampliam o escopo do suporte à linguagem JavaScript:

• arguments objetos
• Frações não inteiras
• Métodos adicionais de medição de tempo: console.time() e console.timeEnd()
• Variáveis e funções agora podem ser redeclaradas

A integração com o módulo NGINX Stream para aplicações TCP/UDP foi refatorada para usar várias funções de retorno, incluindo um método send() para modificar o tráfego de entrada. O tráfego de saída agora está disponível por meio de uma função de callback.

O conjunto completo de alterações pode ser encontrado no changelog do módulo JavaScript do NGINX.

Atualize ou experimente o NGINX Plus

O NGINX Plus R17 inclui suporte ao TLS 1.3, que é mais seguro e oferece melhor desempenho do que o TLS 1.2. Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para a versão 17 e o TLS 1.3 o mais rápido possível. Você também terá acesso a diversas correções e melhorias adicionais, além de facilitar o suporte da NGINX, Inc. quando precisar abrir um chamado.

Analise cuidadosamente os novos recursos e as mudanças de comportamento descritas nesta publicação do blog antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus ou o NGINX ModSecurity WAF, recomendamos que os experimente – 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 gratuitamente hoje mesmo com uma avaliação gratuita de 30 dias. Veja por si mesmo como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.

[Editor – O NGINX ModSecurity WAF deixou oficialmente de ser comercializado em 1º de abril de 2022 e está em transição para o fim de sua vida útil, que entrará em vigor em 31 de março de 2024. Para mais detalhes, consulte O F5 NGINX ModSecurity WAF está em transição para o fim de sua vida útil<.htmla> em nosso blog.]

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly