Temos o prazer de anunciar que o NGINX Plus Release 22 (R22) já está disponível. Baseado no NGINX Open Source, o NGINX Plus é o único balanceador de carga de software, cache de conteúdo, servidor web e gateway de API tudo-em-um. O foco principal do lançamento é o monitoramento e a autenticação, para maior granularidade e resiliência de seus aplicativos em escala.
Os novos recursos do NGINX Plus R22 incluem:
Sistemas operacionais mais antigos não são mais suportados –
O NGINX Plus suporta TLS mútuo, que usa certificados de cliente para verificar a identidade do cliente que se conecta e para estabelecer uma conexão criptografada. O TLS mútuo fornece um alto nível de garantia sobre a identidade do cliente, mas gerenciar certificados revogados pode ser um fardo administrativo. O Protocolo de Status de Certificado Online (OCSP) resolve isso verificando o status dos certificados do cliente conforme eles são apresentados.
Você pode configurar o NGINX Plus para usar o OCSP para verificar a validade dos certificados de cliente X.509, conforme definido pelo RFC 6960 .
Para habilitar a validação OCSP de certificados de cliente SSL, inclua a nova diretiva ssl_ocsp
junto com a diretiva ssl_verify_client
, que habilita a verificação de certificado.
O NGINX Plus envia a solicitação OCSP para o URI OCSP incorporado no certificado do cliente, a menos que você defina um URI diferente com a diretiva ssl_ocsp_responder
.
Para armazenar em cache as respostas do OCSP em uma única zona de memória compartilhada por todos os processos de trabalho, inclua a diretiva ssl_ocsp_cache
para definir o nome e o tamanho da zona. As respostas são armazenadas em cache por 1 hora, a menos que o valor nextUpdate
na resposta do OCSP especifique um valor diferente.
O resultado da validação do certificado do cliente está disponível na variável $ssl_client_verify
, incluindo o motivo da falha do OCSP.
O handshake TLS falhará se o certificado do cliente não for confiável ou a resposta OCSP não for válida. Status código 495
(SSL
Certificado
Erro)
é retornado e uma entrada é criada no log de erros no erro
nível de gravidade:
AAAA / MM / DD hh : mm : ss [erro] 31222#0: *5 status do certificado "revogado" na resposta do OCSP ao solicitar o status do certificado, respondente: 127.0.0.1
Nossa implementação de referência do OpenID Connect para NGINX Plus estende o SSO entre aplicativos novos e existentes para minimizar a complexidade e o custo. A implementação de referência usa uma combinação de recursos do NGINX Plus e o módulo NGINX JavaScript (njs) para executar uma troca de código com o ponto de extremidade de autorização e receber um token de ID do IdP. Os tokens de ID em si são armazenados em cache no armazenamento de chave-valor do NGINX Plus e um token de sessão opaco é enviado ao cliente. Os clientes então se autenticam apresentando um token de sessão válido que o NGINX Plus usa para verificar o token de ID antes de acessar os aplicativos de backend.
Esta versão traz inúmeras melhorias para a implementação de referência do OIDC e duas mudanças significativas:
de mapa
. Essa flexibilidade adicional reduz a necessidade de modificar o código de implementação de referência do OIDC.Aqui está um exemplo de configuração:
Cada bloco de mapa
permite vários valores para que vários IdPs e parâmetros de autenticação (segredo do cliente, arquivo de chave JWK, pontos de extremidade de autorização) possam ser suportados. Aqui usamos a variável $host
como parâmetro de entrada, mas você pode especificar qualquer variável derivada do cabeçalho da solicitação.
A API NGINX Plus agora rastreia atividades relacionadas a logins do OpenID Connect para ajudar no monitoramento e na solução de problemas. Consulte o repositório do GitHub para obter mais informações sobre a implementação de referência do OpenID Connect.
Ataques DDoS e de força bruta para adivinhação de senhas são duas ameaças críticas aos seus aplicativos. Você pode mitigar seus efeitos com limitação de taxa – fazendo com que o NGINX Plus limite o número de solicitações que cada cliente pode fazer em um determinado período de tempo.
O NGINX Plus R20 adicionou monitoramento em tempo real da taxa de solicitação e limitação de conexão à API do NGINX Plus (nos endpoints /api/ versão /http/limit_reqs
e /api/ versão /http/limit_conns
). As informações agora aparecem no painel de monitoramento de atividades ao vivo do NGINX Plus, com contagens cumulativas em formato de tabela e contagens com registro de data e hora em formato de gráfico:
A tabela inclui uma linha para cada zona definida por uma diretiva limit_req_zone
e limit_conn_zone
. Para exibir o gráfico, clique no ícone do gráfico na extremidade esquerda da linha.
O gráfico expandido é atualizado continuamente e mostra valores para cada intervalo de tempo como um gráfico de áreas empilhadas. Você pode personalizar as informações exibidas das seguintes maneiras:
No intervalo padrão de atualização do painel de 1 segundo, cada gráfico armazena cerca de 30 minutos de dados históricos. Aumentar o intervalo de atualização do painel (atualizando com menos frequência) aumenta a quantidade de dados históricos disponíveis. Observe que os gráficos do painel não são persistentes e os dados históricos são perdidos quando você sai da guia ou a recarrega.
O módulo NGINX JavaScript estende a funcionalidade do NGINX Plus para permitir uma ampla variedade de casos de uso, incluindo obter maior controle sobre o tráfego, consolidar funções JavaScript em todos os aplicativos e defender-se contra ameaças de segurança. O módulo NGINX JavaScript foi atualizado para0.4.1 e inclui estes recursos:
js_import
para importar vários arquivos de módulo que implementam manipuladores de localização e variáveisO código e a configuração a seguir ilustram como o novo objeto r.rawHeadersIn
pode ser usado para registrar o conjunto exato de cabeçalhos enviados pelo cliente sempre que um erro for encontrado. [ Editor – Este é apenas um dos muitos casos de uso para o módulo NGINX JavaScript. Para uma lista completa, consulte Casos de uso para o módulo JavaScript NGINX . ]
Aqui está um exemplo de entrada de log para um404
resposta:
$ curl http://localhost/bogus $ tail --lines=1 /var/log/nginx/access_json.log {"response":{"timestamp":" AAAA - MM - DD T hh : mm : ss + TZ_offset ","status":404},"request":{"client":"127.0.0.1","uri":"/bogus","headers":[["Host","localhost:80"],["Agente do usuário","curl/7.64.1"],["Aceitar","*/*"]]}}
Para mitigar ataques de temporização , como ataques de força bruta de senha e preenchimento de credenciais, você pode fazer com que o NGINX Plus atrase sua resposta quando a autenticação falhar. A nova diretiva auth_delay
especifica o atraso, que pode ser aplicado a solicitações de autenticação processadas pelos módulos Auth Basic , Auth JWT e Auth Request .
Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R22 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 . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.
"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."