BLOG | NGINX

Anunciando o NGINX Plus R17

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Liam Crilly
Liam Crilly
Publicado em 11 de dezembro de 2018

[ Editor – O módulo NGINX ModSecurity WAF para NGINX Plus foi oficialmente encerrado em 1º de abril de 2022 e está em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da 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 é o único balanceador de carga, cache de conteúdo, servidor web e gateway de API tudo-em-um. O NGINX Plus é baseado no NGINX Open Source e inclui recursos aprimorados exclusivos e suporte premiado.

A novidade nesta 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 que o TLS 1.2 foi lançado, e muita coisa mudou desde então. Várias vulnerabilidades de segurança foram encontradas no TLS 1.2, como FREAK, Heartbleed, POODLE e ROBOT. Muitas dessas vulnerabilidades eram resultado de muitas opções de configuração inseguras no TLS 1.2, que deixavam os sites abertos a ataques.

TLS 1.3 é adição por subtração. 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 em que este artigo foi escrito, o Alpine Linux 3.9, o FreeBSD 12.0 e o Ubuntu 18.10 eram compatíveis com o TLS 1.3, então você pode usá-los com o NGINX Plus R17 para TLS 1.3 em seu ambiente de produção; outros fornecedores de sistemas operacionais sem dúvida oferecerão suporte ao TLS 1.3 em versões futuras. Observe que o F5 BIG-IP e outros balanceadores de carga de hardware não oferecem suporte total ao TLS 1.3 no momento.

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 no NGINX Open Source e no NGINX Plus. Ele pode ser usado para mitigar ataques DDoS e, em geral, proteger servidores de aplicativos de serem sobrecarregados por muitas solicitações. O novo parâmetro de atraso ajuda a limitação de taxa do NGINX Plus a acomodar melhor os padrões típicos de solicitação do navegador. Os métodos de aplicação de atraso e rejeição existentes agora podem ser combinados para fornecer limitação de taxa em dois estágios, em que solicitações excessivas são inicialmente atrasadas e, em seguida, rejeitadas se o limite de taxa ainda for excedido.
  • Configuração mais fácil do OpenID Connect – No NGINX Plus R15, introduzimos a integração do OpenID Connect para permitir que nossos clientes adicionem logon único (SSO) aos seus aplicativos. No R17, simplificamos a configuração para buscar automaticamente JSON Web Keys (JWKs) do provedor de identidade (IdP).
  • O NGINX Modsecurity WAF é 2x mais rápido – O NGINX ModSecurity WAF, um módulo dinâmico para o NGINX Plus baseado no ModSecurity v3, fornece proteção robusta contra ataques de Camada 7. O ModSecurity está sendo desenvolvido ativamente e a versão mais recente do NGINX ModSecurity WAF oferece desempenho 2x melhor e uma série de melhorias adicionais.

Melhorias adicionais no NGINX Plus R17 incluem keepalives TCP para upstreams, suporte SNI em ambientes em cluster e muito mais.

Mudanças importantes no comportamento

  • O NGINX Plus R13 introduziu a novíssima API NGINX Plus para coleta de métricas e reconfiguração dinâmica de grupos upstream, substituindo as APIs Status e Upstream Conf que implementavam essas funções anteriormente. Conforme anunciado na época, as APIs obsoletas continuaram disponíveis e com suporte por um período significativo de tempo, que terminou com o NGINX Plus R16 . Se sua configuração incluir as diretivas status e/ou upstream_conf , você deverá substituí-las pela diretiva api como parte da atualização para o R17.

    Para obter orientação e assistência na migração para a API NGINX Plus , consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.

  • Novos sistemas operacionais suportados:

    • Alpine Linux 3.8
    • Alpine Linux 3.9
    • FreeBSD 11.2
    • FreeBSD 12.0
    • Servidor SUSE Linux Enterprise 15
    • Ubuntu 18.10 (Cósmico)
  • Sistemas operacionais mais antigos removidos ou programados para remoção:

    • O FreeBSD 10.4 e 11.1 não são mais suportados.
    • O suporte para CentOS/Oracle/RHEL 7.3 e versões anteriores será descontinuado no NGINX Plus R18 .
    • O suporte para 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 resolver muitos dos problemas encontrados no TLS 1.2 e definir uma plataforma mais escalável para o futuro.

Mais seguro

Ao longo dos anos, inúmeras vulnerabilidades de segurança no TLS 1.2 foram divulgadas, como FREAK , Heartbleed , POODLE e ROBOT . O FREAK, por exemplo, permite que um invasor faça downgrade de uma conexão TLS para usar uma cifra de exportação com um comprimento de chave de 40 bits, que pode ser forçada brutamente. O TLS 1.3 remove completamente as cifras de exportação.

Muitos dos problemas que surgiram com o TLS 1.2 e especificações anteriores são devidos ao grande número de opções configuráveis pelo usuário. O uso indevido de opções geralmente levava a configurações inseguras que poderiam ser exploradas por invasores. O TLS 1.3 remove várias dessas opções:

  • AES-CBC
  • Grupos arbitrários de Diffie-Hellman
  • Exportar cifras
  • DES/3DES
  • MD5
  • Preenchimento PKCS#1 v1.5
  • RC4
  • Transporte de chave RSA (Diffie‑Hellman é obrigatório)
  • SHA-1

Melhor desempenho

Notável na lista de remoções é o transporte de chaves RSA. Este modo foi usado principalmente porque era mais rápido que o Diffie-Hellman, que exigia uma viagem de ida e volta adicional para configurar a conexão com sigilo de encaminhamento perfeito (PFS). Com o TLS 1.3, a viagem de ida e volta adicional não é mais necessária. Com menos opções de configuração, há menos informações para trocar e o handshake Diffie-Hellman leva 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 reduzindo o número de viagens de ida e volta para configurar uma conexão segura

Além disso, o TLS 1.3 oferece suporte à retomada de sessão , o que torna o estabelecimento da conexão mais rápido 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) , porque nenhuma mensagem de handshake precisa ir e voltar entre o cliente e o servidor para a sessão retomada. A retomada da sessão é implementada criando um segredo compartilhado durante a sessão original e armazenando-o 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 que está no tíquete.

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

Usar 0-RTT abre 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, reproduzi-las não tem 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 , portanto, habilitar a retomada da 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, porque para o tráfego de API, as sessões TLS retomadas têm mais probabilidade de conter tipos de solicitação não idempotentes.

O TLS 1.3 também protege contra ataques de repetição ao incluir informações de tempo no tíquete de sessão e na solicitação do cliente, o que permite ao servidor determinar se a solicitação chegou do cliente razoavelmente logo após o cliente enviá-la. Um invasor não pode alterar as informações de tempo, então, se a solicitação demorou muito para chegar, ela provavelmente foi repetida.

Como habilitar o TLS 1.3 no NGINX Plus

TLS 1.3 e 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 o TLSv1.2 porque nem todos os navegadores suportam o TLS 1.3 no momento da redação deste artigo (consulte a próxima seção). O NGINX Plus usa TLS 1.3 se o cliente oferecer suporte a ele e, caso contrário, volta para TLS 1.2.

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

Esta configuração habilita ambos os recursos:

servidor { ouvir 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 ; # Habilitar 0-RTT (TLS 1.3) location / { proxy_pass http://my_backend; } }

Plataformas suportadas

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

Do lado do cliente, recomendamos o Chrome 70 ou o Firefox 63. Eles suportam a versão final do TLS 1.3, mas não o habilitam por padrão; siga estas instruções para habilitar o TLS 1.3 no navegador . No momento em que este artigo foi escrito, outros navegadores populares (incluindo Firefox para Android e Safari para iOS e Mac) ainda não eram compatíveis com TLS 1.3. Para obter as informações de status mais recentes, consulte Posso usar: TLS 1.3 .

Limitação de taxa em dois estágios

Anteriormente, o NGINX Plus podia impor limites na taxa de solicitações de duas maneiras: rejeitando solicitações excessivas imediatamente ou enfileirando solicitações excessivas até que pudessem ser processadas em conformidade com o limite de taxa definido. Com o NGINX Plus R17 , você pode combinar ambos os métodos de aplicação para limitação de taxa em dois estágios, em que solicitações excessivas são inicialmente atrasadas e, por fim, rejeitadas se o limite de taxa ainda for excedido.

Ao aplicar limites de taxa, é essencial considerar o comportamento típico de clientes legítimos. Por exemplo, os navegadores da web geralmente tentam baixar vários recursos simultaneamente, então é razoável ver 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 melhor permitir um intervalo de 10 a 20 solicitações rápidas antes de aplicar um limite de taxa.

Com o NGINX Plus R17, agora você pode permitir um pico para acomodar o padrão típico de solicitação do navegador da web e, então, atrasar solicitações excessivas adicionais até um ponto, além do qual solicitações excessivas adicionais são rejeitadas. A limitação de taxa em dois estágios é habilitada com o novo parâmetro de atraso na diretiva limit_req .

Para ilustrar a limitação de taxa em dois estágios, aqui configuramos o NGINX Plus para proteger um site impondo um limite de taxa 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 rajadas de até 12 solicitações, sendo que as 8 primeiras são processadas sem demora. Um atraso é adicionado após 8 solicitações excessivas para impor o limite de 5 r/s. Após 12 solicitações excessivas, quaisquer solicitações adicionais serão rejeitadas.

limit_req_zone $binary_remote_addr zona=ip:10m taxa=5r/s;
servidor {
ouvir 80;
localização / {
limit_req zona=ip burst=12 atraso=8;
proxy_pass http://website;
}
}

O parâmetro de atraso define o ponto em que, dentro do tamanho do burst, solicitações excessivas são limitadas (atrasadas) para cumprir com o limite de taxa definido. Com essa configuração em vigor, um cliente que faz um fluxo contínuo de solicitações a 8 r/s experimenta o seguinte comportamento.

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

As primeiras 8 solicitações (o valor de delay ) são representadas por proxy pelo NGINX Plus sem delay. As próximas 4 requisições ( burst - delay ) são atrasadas para que a taxa definida de 5 r/s não seja excedida. As próximas 3 solicitações são rejeitadas porque o tamanho total do burst foi excedido. Solicitações subsequentes serão adiadas.

Observe que esta ilustração é uma descrição simplificada do processo porque ignora o impacto das solicitações concluídas no cálculo de quantas solicitações excessivas estão sendo processadas. Na realidade, cada solicitação concluída abre um espaço na fila de atraso para outra solicitação excessiva se ajustar ao tamanho de burst configurado. Para obter mais informações sobre a implementação de limitação de taxa, consulte Limitação de taxa com NGINX e NGINX Plus em nosso blog.

Configuração mais fácil do OpenID Connect

Ao executar a validação do JWT, o NGINX Plus R17 agora pode ser configurado para buscar o conjunto de JSON Web Keys (JWKs) do 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 rotaciona chaves com frequência.

A maioria dos IdPs fornece uma URL fixa onde o conjunto atual de chaves pode ser obtido, especialmente se eles suportam OpenID Connect Discovery ; nesse caso, a URL para as chaves é definida pelo valor jwks_uri .

# Crie um diretório para armazenar em cache as chaves recebidas de IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # Use SSL/TLS em produção

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # As chaves serão obtidas por subrequest

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # Cache de respostas
proxy_pass https://idp.example.com/oauth2/keys; # Obtenha chaves daqui
}
}

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

Nossa implementação de referência do OpenID Connect foi atualizada para incluir suporte para auth_jwt_key_request e configuração automática para IdPs que suportam o OpenID Connect Discovery.

O suporte ao JWT também foi estendido para oferecer suporte a duas variantes do Algoritmo de Assinatura Digital da 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 artigo 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 NGINX Plus é nossa versão com suporte do firewall de aplicativo 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 o prazer de informar que a versão mais recente tem um desempenho duas vezes melhor que as versões anteriores.

O NGINX WAF protege contra ataques da Camada 7

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

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

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

Outros novos recursos no NGINX Plus R17

TCP Keepalives para Upstreams

A nova diretiva proxy_socket_keepalive controla se os keepalives TCP estão habilitados entre o NGINX Plus e o servidor proxy. Keepalives TCP melhoram o desempenho de protocolos (como WebSocket) onde há um dispositivo de rede TCP com estado entre o NGINX e o servidor proxy, com conexões de longa duração e frequentemente ociosas. Sem keepalives TCP, esses dispositivos podem fechar conexões TCP ociosas com mais frequência, incorrendo na 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 HTTP upstream e limite de solicitação

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 fechada. Além disso, a diretiva keepalive_requests define o número máximo de solicitações que podem ser enviadas por meio de uma conexão keepalive (momento em que ela é fechada e uma nova é criada).

Tamanho de sessão UDP upstream finito

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

Melhoria no compartilhamento de estado do cluster

Ao usar o compartilhamento de estado em um cluster, agora você pode fazer a verificação do nome do servidor, usando SNI para passar o nome do servidor 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 NGINX Plus

Melhorias no controlador Ingress

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

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

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

Melhorias no módulo JavaScript

O NGINX Plus R17 inclui uma série de melhorias que ampliam o escopo do suporte à linguagem JavaScript:

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

A integração com o módulo NGINX Stream para aplicativos 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 um retorno de chamada.

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 para TLS 1.3, que é mais seguro e tem melhor desempenho que o TLS 1.2. Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para a versão 17 e o TLS 1.3 o mais rápido possível. Você também receberá uma série de correções e melhorias adicionais, e isso ajudará a NGINX, Inc. a ajudá-lo quando precisar abrir um tíquete de suporte.

Revise cuidadosamente os novos recursos e mudanças de comportamento descritos nesta postagem 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 você os 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 uma avaliação gratuita de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.

[ Editor – O NGINX ModSecurity WAF foi oficialmente encerrado em 1º de abril de 2022 e está em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]


"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."