[ 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.]
Estamos felizes em anunciar o NGINX Plus Release 10 (R10), nosso lançamento mais significativo até agora. O NGINX Plus estende o NGINX Open Source com funcionalidade avançada e suporte premiado, fornecendo aos clientes uma solução completa de entrega de aplicativos. Com esta versão, estamos fornecendo uma série de novos recursos para melhorar drasticamente a segurança e o desempenho dos aplicativos fornecidos pelo NGINX Plus, juntamente com recursos adicionais para melhor integração de rede e suporte para personalização do NGINX Plus por meio de scripts.
[ Editor – Para mais detalhes sobre os principais novos recursos do NGINX Plus R10, consulte estes recursos relacionados:
]
O NGINX Plus R10 apresenta a versão inicial do nosso firewall de aplicativo da web (WAF) , desenvolvido pela ModSecurity e totalmente suportado pela NGINX, Inc. Os ataques a aplicativos da Web aumentaram 50% no ano passado e os ataques DDoS mais que dobraram, de acordo com a Akamai . Agora, todos os aplicativos correm o risco de serem atacados. O NGINX ModSecurity WAF ajuda a proteger aplicativos da web de usuários mal-intencionados e oferece aos clientes uma ferramenta versátil para ajudar a manter seus aplicativos e dados seguros.
O NGINX ModSecurity WAF é baseado no novo software ModSecurity 3 e é executado nativamente no NGINX Plus. Disponível como uma opção de custo adicional em nosso repositório de módulos dinâmicos e com suporte da NGINX, Inc., ele foi testado exaustivamente com o NGINX Plus. Estamos trabalhando com a Trustwave e manteremos atualizações testadas à medida que adicionamos recursos, melhoramos o desempenho e resolvemos quaisquer problemas.
Dois novos recursos adicionais aprimoram ainda mais os recursos de segurança do NGINX Plus:
Tokens da Web JSON – Muitos de nossos clientes usam o NGINX Plus como um gateway de API e nos pediram uma maneira comum e padrão de autenticar o acesso às APIs na camada NGINX Plus. Para atender a essa necessidade, com esta versão estamos adicionando suporte para autenticação usando JSON Web Tokens (JWTs).
O NGINX Plus agora pode validar um JWT antes de permitir que os clientes acessem as APIs. Esse recurso permite que os administradores de aplicativos protejam o acesso às suas APIs com um padrão aberto, evitando o bloqueio do fornecedor a um padrão proprietário. O suporte nativo ao JWT também reduz a complexidade para administradores de aplicativos ao descarregar operações de autenticação – como a validação de tokens OpenID Connect compatíveis com OAuth 2.0 – de servidores de aplicativos para o NGINX Plus.
Além dos recursos de segurança, o NGINX Plus R10 inclui:
Suporte a proxy transparente – Embora muitos aplicativos HTTP modernos possam ser configurados para depender de um cabeçalho X-Forwarded-For
, alguns aplicativos legados e outros serviços TCP ou UDP referem-se ao endereço IP de origem da transação para fins de registro, segurança ou autenticação.
O NGINX Plus agora pode "falsificar" o endereço IP de origem e a porta de conexões HTTP e TCP e datagramas UDP que ele encaminha para servidores upstream. Isso pode ser usado para fornecer transparência de IP , uma configuração em que o NGINX Plus envia pacotes com o endereço IP do cliente remoto para que o servidor upstream veja os pacotes como originários desse endereço em vez de um endereço IP local no servidor NGINX Plus. Esse recurso também pode ser usado para habilitar o Direct Server Return para protocolos baseados em UDP.
map
, suporte para testes A/B com a diretiva split_clients
, operações Geo e GeoIP e roteamento seletivo ( parâmetro variável para a diretiva proxy_pass
). Essas extensões permitem que você crie políticas de balanceamento de carga TCP e UDP mais sofisticadas, orientadas pela linguagem de configuração NGINX e pela nova integração NGINX JavaScript.O principal recurso do NGINX Plus R10 é o lançamento inicial do nosso WAF, desenvolvido com base na conhecida e confiável tecnologia ModSecurity . Desde seu lançamento inicial de código aberto em 2002, o ModSecurity tem ajudado a proteger algumas das maiores propriedades da web do mundo contra usuários mal-intencionados. É comumente chamado de “canivete suíço®” da segurança. O NGINX ModSecurity WAF é uma opção de custo adicional e é fornecido aos assinantes por meio do nosso repositório de módulos dinâmicos.
O NGINX ModSecurity WAF é uma solução essencial para ajudar a proteger aplicativos críticos. Ele fornece uma alternativa econômica aos dispositivos de hardware inflexíveis e caros , como os fornecidos pela F5, Citrix e Imperva, ao mesmo tempo em que excede suas capacidades com a flexibilidade do software. O NGINX ModSecurity WAF pode ser implantado em qualquer ambiente – servidores locais e nuvens públicas, privadas e híbridas.
Um WAF opera em um banco de dados de “regras” que definem comportamentos maliciosos a serem bloqueados e/ou registrados. O conjunto de regras básicas (CRS) do OWASP ModSecurity é um dos conjuntos de regras mais amplamente utilizados com o ModSecurity. O NGINX ModSecurity WAF usa o OWASP CRS para identificar e bloquear uma ampla gama de ataques a aplicativos, com recursos como:
Conjuntos de regras adicionais também estão disponíveis de diferentes fornecedores, como a TrustWave , em diferentes níveis de custo. Além disso, você pode usar a poderosa linguagem de regras do ModSecurity para definir suas próprias regras personalizadas que complementam quaisquer conjuntos de regras que você esteja usando.
O suporte para NGINX ModSecurity WAF é fornecido diretamente pela NGINX, Inc. Nossa equipe de suporte pode ajudar a instalar, configurar e depurar problemas com o WAF e o conjunto de regras principais do OWASP.
O NGINX ModSecurity WAF está disponível como um módulo dinâmico no repositório NGINX Plus que você instala usando ferramentas padrão de gerenciamento de pacotes. Esses comandos são para sistemas operacionais baseados em Debian:
# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-modsecurity
Observe que somente assinantes que compraram o módulo NGINX ModSecurity WAF e assinantes e avaliadores que solicitaram acesso podem baixar o pacote nginx-plus-module-modsecurity .
Para carregar o módulo NGINX ModSecurity WAF, inclua a diretiva load_module
no contexto “principal” de nível superior do arquivo de configuração do NGINX Plus:
Para habilitar o NGINX ModSecurity WAF com o NGINX Plus, inclua a diretiva modsecurity
junto com a diretiva modsecurity_rules_file
para especificar o conjunto de regras:
Em seguida, recarregue a configuração do NGINX Plus:
# nginx -t && nginx -s recarregar
Com suporte nativo para o padrão de autenticação JSON Web Token (JWT), o NGINX Plus R10 facilita a adição de soluções de autenticação sofisticadas aos seus aplicativos e APIs.
Os tokens JWT (pronuncia-se “jot”), definidos no RFC 7519 , são o formato de dados subjacente para informações do usuário no padrão OpenID Connect , que é a camada de identidade padrão sobre o protocolo OAuth 2.0. Os implantadores de APIs e microsserviços também estão recorrendo ao padrão JWT por sua simplicidade e flexibilidade.
[ Editor – Para casos de uso que aproveitam o suporte JWT nativo, consulte estes blogs:
]
Como um proxy reverso e balanceador de carga , o NGINX Plus fica na frente dos aplicativos, posicionando-se idealmente para simplificar o desenvolvimento de aplicativos ao descarregar a validação do JWT fornecido em cada solicitação HTTP. Isso proporciona dois benefícios. Primeiro, o NGINX Plus pode ajudar a impedir que solicitações não autenticadas, malformadas e maliciosas cheguem ao aplicativo, protegendo-o do esforço e do risco envolvidos no tratamento dessas solicitações.
O segundo benefício é que o NGINX Plus tem acesso a todos os campos no JWT validado (após a verificação da assinatura) e pode usar o poder e a flexibilidade inerentes de sua sintaxe de configuração para fornecer soluções de autenticação sofisticadas para microsserviços e APIs:
O seguinte snippet de configuração de exemplo do NGINX Plus mostra como usar JWTs para proteger um site.
A diretiva auth_jwt
informa ao NGINX Plus para usar o JWT para autenticar usuários que fazem solicitações para um domínio, neste caso myrealm . A diretiva auth_jwt_key_file
indica qual JSON Web Key (JWK) usar para validar a assinatura do token; ela funciona como a chave pública na criptografia SSL/TLS. O local do arquivo deve ser acessível ao NGINX Plus.
À medida que o NGINX Plus valida e analisa o token, ele cria automaticamente variáveis NGINX para as “ declarações ” no JWT, que representam entidades associadas a ele (seu emissor, o usuário para quem foi emitido e o destinatário pretendido, por exemplo). Todos os nomes das variáveis começam com $jwt_claim_
. Você pode então usar a diretiva add_header
para que o NGINX Plus passe uma reivindicação aos servidores de backend na forma de um cabeçalho HTTP definido como o valor da variável $jwt_claim_
. Em nosso exemplo, o NGINX Plus passa a identidade do usuário para o aplicativo de backend na variável $jwt_claim_sub
, que corresponde ao ID do usuário ( sub
claim) no JWT.
No NGINX Plus R8, lançamos uma prévia da tecnologia de suporte ao OAuth2. Na implementação do NGINX Plus R10, recebemos o feedback de nossos clientes para entregar uma implementação pronta para produção que alcança os casos de uso mais valiosos no complexo mundo de autenticação de usuários e computadores.
Agora, há muitos motivos para começar a criptografar todo o tráfego de aplicativos com SSL/TLS. O Google recompensa sites criptografados com SSL/TLS com classificações mais altas nos mecanismos de busca . Além disso, padrões modernos da web, como HTTP/2, estão exigindo criptografia SSL/TLS para todos os sites.
Com o NGINX Plus R10, você pode publicar serviços SSL/TLS usando certificados RSA e ECC. Em nossos testes, os certificados ECC foram até 3x mais rápidos que os certificados RSA de força equivalente; isso se traduz em mais conexões SSL/TLS por servidor e handshakes SSL/TLS mais rápidos. O NGINX Plus seleciona o certificado ideal com base nas capacidades de cada cliente, permitindo que clientes modernos usem certificados ECC de maior velocidade e ainda ofereçam suporte a clientes legados somente RSA.
Para oferecer suporte aos certificados RSA e ECC, na configuração de um servidor virtual, basta incluir um par de diretivas ssl_certificate
e ssl_certificate_key
para cada tipo de certificado, conforme mostrado no exemplo a seguir.
Estamos continuamente adicionando recursos ao NGINX Plus, como balanceamento de carga TCP e UDP , para oferecer suporte a uma gama mais ampla de aplicativos e modelos de implantação. Com o NGINX Plus R10, adicionamos um recurso de proxy transparente que permite que o NGINX Plus envie pacotes para servidores upstream usando qualquer endereço IP de origem e porta. Isso permite configurações como Transparência de IP e Retorno Direto do Servidor.
Transparência de IP é uma configuração em que o balanceador de carga (NGINX Plus) usa o endereço IP do cliente remoto como o endereço IP de origem em pacotes que ele envia para servidores upstream. Isso significa que os servidores upstream veem os pacotes como originários do endereço IP do cliente remoto, e não de um endereço IP local no balanceador de carga. Isso é significativo quando os aplicativos se referem ao endereço IP de origem para fins de registro, segurança, limitação de taxa ou autenticação.
A transparência de IP também é um componente essencial de uma técnica de balanceamento de carga de rede chamada Direct Server Return (DSR). O NGINX Plus pode executar DSR para protocolos baseados em UDP (mas não TCP ou HTTP), permitindo que os pacotes de retorno ignorem completamente o balanceador de carga e vão diretamente para o cliente remoto.
A transparência de IP e o DSR são configurados com o novo parâmetro transparente
para as diretivas proxy_bind
, fastcgi_bind
, memcached_bind
, scgi_bind
e uwsgi_bind
. O exemplo a seguir mostra como configurar o DSR para um backend DNS. A diretiva proxy_responses
especifica que o NGINX Plus não precisa ver nenhuma resposta do servidor (zero é o valor apropriado para DSR).
Observe que as verificações de integridade passivas não são eficazes quando o DSR está habilitado, porque elas envolvem o NGINX Plus verificando se o servidor enviou uma resposta ao cliente. A configuração de verificações de integridade ativas com reconhecimento de aplicativo é obrigatória para uma configuração de DSR. Para ver um exemplo, consulte nossas instruções detalhadas para configurá-los para servidores DNS com balanceamento de carga.
As configurações de transparência de IP e DSR são complexas, com requisitos adicionais de roteamento e reescrita de pacotes que estão fora do escopo do software NGINX Plus. Para obter instruções completas, consulte Transparência de IP e retorno direto do servidor com NGINX e NGINX Plus como proxy transparente em nosso blog.
[ Editor – O módulo NGINX JavaScript era anteriormente chamado de nginScript. O módulo ficou disponível para o público em geral no NGINX Plus R12 (e NGINX 1.11.10).
Para explorações detalhadas de outros casos de uso do módulo NGINX JavaScript, consulte Casos de uso do módulo NGINX JavaScript .
O código nesta seção foi atualizado para usar a diretiva js_import
, que substitui a diretiva js_include
no NGINX Plus R23 e posteriores. Para obter mais informações, consulte a documentação de referência do módulo NGINX JavaScript – a seção Configuração de exemplo mostra a sintaxe correta para a configuração do NGINX e arquivos JavaScript. ]
O NGINX Plus R10 inclui uma versão de pré-visualização da nossa nova linguagem de configuração JavaScript NGINX. Ainda não está completo em termos de recursos e agradecemos qualquer feedback sobre o trabalho realizado até agora. O NGINX JavaScript permite que você use código JavaScript para executar ações complexas e personalizadas em tráfego HTTP, TCP e UDP. Ele fornece uma nova maneira poderosa de controlar como seus aplicativos são entregues e protegidos. Com o NGINX JavaScript você pode:
A visualização do JavaScript do NGINX está disponível em nosso repositório de módulos dinâmicos . Você pode instalá-lo usando ferramentas padrão de gerenciamento de pacotes. Esses comandos são para sistemas operacionais baseados em Debian:
# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-njs
Para carregar os módulos JavaScript do NGINX para HTTP e TCP/UDP, inclua a diretiva load_module
no contexto “principal” de nível superior do arquivo de configuração do NGINX Plus:
Em seguida, recarregue a configuração do NGINX Plus para carregar os módulos JavaScript do NGINX:
# nginx -t && nginx -s recarregar
Usuários do NGINX Open Source podem obter o NGINX JavaScript em nosso repositório de código aberto .
O código JavaScript não está incluído diretamente na configuração do NGINX Plus. Em vez disso, ele é lido com a diretiva js_import
. Neste exemplo, o código JavaScript para uma função simples “sem servidor” é lido em /etc/nginx/conf.d/functions.js . A diretiva js_content
instrui o NGINX Plus a chamar a função JavaScript e retornar os resultados ao cliente.
O código JavaScript em /etc/nginx/conf.d/functions.js preenche uma sequência de caracteres com um conjunto especificado de caracteres:
O NGINX Plus R10 apresenta uma série de melhorias adicionais para ajudar você na entrega perfeita de aplicativos, incluindo:
proxy_pass
.IP_BIND_ADDRESS_NO_PORT
quando disponível. Esta opção permite que portas de origem sejam reutilizadas para conexões de saída para servidores upstream, desde que o padrão “4-tupla” (endereço IP de origem, endereço IP de destino, porta de origem, porta de destino) seja exclusivo. Ele está disponível em sistemas com kernel Linux versão 4.2 e posterior, e glibc 2.22 e posterior.$request_id
automaticamente para cada nova solicitação HTTP, atribuindo efetivamente à solicitação um “ID de transação” exclusivo. Isso facilita o rastreamento de aplicativos e traz recursos de APM para ferramentas de análise de log. O ID da transação é enviado por proxy para aplicativos de back-end e microsserviços para que todas as partes do sistema possam registrar um identificador consistente para cada transação.proxy_request_buffering
, fastcgi_request_buffering
, scgi_request_buffering
e uwsgi_request_buffering
agora funcionam com HTTP/2 e podem ser usadas para alternar o buffer de solicitações.http2_body_preread_size
permite que clientes HTTP/2 comecem a enviar o corpo da solicitação imediatamente. A diretiva controla o tamanho do buffer usado antes que o NGINX Plus comece a ler o corpo da solicitação do cliente.Como anunciamos antecipadamente no lançamento do NGINX Plus R9, o R10 é o último lançamento que incluirá o pacote NGINX Plus Extras.
Recomendamos fortemente que você modifique seus procedimentos de instalação e configuração agora para usar o pacote nginx-plus e carregar dinamicamente os módulos no pacote nginx-plus-extras que você realmente usa. A partir do NGINX Plus R11, esta será a única maneira possível de usar módulos que não estão incorporados ao pacote nginx-plus .
Para alternar para o pacote nginx-plus e módulos dinâmicos, execute estas etapas:
Remova o pacote nginx-plus-extras e instale o nginx-plus e os módulos dinâmicos que você deseja usar. Para sistemas baseados em Debian, o conjunto apropriado de comandos é:
# apt-get update # apt-get remove nginx-plus-extras # apt-get install nginx-plus # apt-get install nome-do-módulo
No contexto principal (nível superior) em /etc/nginx/nginx.conf , adicione uma diretiva load_module
para cada módulo carregado dinamicamente:
Verifique a nova configuração quanto à validade sintática e recarregue-a:
# nginx -t && nginx -s recarregar
Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para a versão 10 o mais rápido possível. Você aprenderá uma série de correções e melhorias, e isso nos ajudará a ajudar você caso precise abrir um tíquete de suporte. Instruções de instalação e atualização podem ser encontradas no portal do cliente NGINX Plus .
OBSERVAÇÃO : O NGINX Plus R10 é a última versão que incluirá o pacote nginx-plus-extras . Veja O pacote de extras do NGINX Plus está obsoleto , acima.
Se você ainda não experimentou o NGINX Plus , recomendamos que experimente para aceleração web, balanceamento de carga e entrega de aplicativos, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento . Você pode começar hoje mesmo gratuitamente com uma avaliação de 30 dias e ver por si mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.
Para obter mais detalhes sobre os principais novos recursos do NGINX Plus R10, consulte estes recursos relacionados:
[O NGINX ModSecurity WAF foi oficialmente encerrado em 1º de abril de 2022 e entrará em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja o F5 NGINX ModSecurity WAF está em transição para o fim da vida útil 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."