Esta publicação do blog aborda uma vulnerabilidade relacionada ao protocolo HTTP/2 que foi descoberta recentemente. Sob determinadas condições, essa vulnerabilidade pode ser explorada para executar um ataque de negação de serviço contra o NGINX Open Source, o NGINX Plus e produtos relacionados que implementam a parte da especificação HTTP/2 referente ao servidor. Para proteger seus sistemas contra esse ataque, recomendamos uma atualização imediata da configuração do NGINX.
O problema com as redefinições de fluxo do HTTP/2
Após estabelecer uma conexão com um servidor, o protocolo HTTP/2 permite que os clientes iniciem fluxos simultâneos para a troca de dados. Ao contrário das versões anteriores do protocolo, se um usuário final decidir sair da página ou interromper a troca de dados por qualquer outro motivo, o HTTP/2 oferece um método para cancelar o fluxo. Para isso, ele envia um quadro RST_STREAM ao servidor, evitando que este execute tarefas desnecessariamente.
A vulnerabilidade é explorada iniciando e cancelando rapidamente um grande número de fluxos HTTP/2 em uma conexão estabelecida, contornando assim o limite máximo de fluxos simultâneos do servidor. Isso ocorre porque os fluxos recebidos são redefinidos mais rapidamente do que os fluxos subsequentes chegam, permitindo que o cliente sobrecarregue o servidor sem nunca atingir o limite configurado.
Impacto no NGINX
Por motivos de desempenho e consumo de recursos, o NGINX limita o número de fluxos simultâneos a 128 por padrão (consulte http2_max_concurrent_streams). Além disso, para equilibrar de forma ideal o desempenho da rede e do servidor, o NGINX permite que o cliente mantenha conexões HTTP por até 1.000 solicitações por padrão usando uma conexão HTTP persistente (consulte keepalive_requests).
Ao utilizar o limite padrão de keepalive, o NGINX impede esse tipo de ataque. A criação de conexões adicionais para contornar esse limite expõe agentes mal-intencionados por meio de ferramentas padrão de monitoramento e alerta da camada 4.
No entanto, se o NGINX estiver configurado com um limite de keepalive substancialmente maior do que a configuração padrão e recomendada, o ataque poderá esgotar os recursos do sistema. Quando ocorre a redefinição de um fluxo, o protocolo HTTP/2 exige que nenhum dado subsequente seja retornado ao cliente nesse fluxo. Normalmente, a redefinição resulta em uma sobrecarga insignificante para o servidor, na forma de tarefas que processam o cancelamento de maneira adequada. No entanto, contornar o limite de fluxos do NGINX permite que um cliente explore essa sobrecarga e a amplifique iniciando rapidamente milhares de fluxos. Isso provoca um pico no uso da CPU do servidor, impedindo o atendimento a clientes legítimos.
Negação de serviço por meio do estabelecimento de fluxos HTTP/2, seguido pelo cancelamento desses fluxos sob limites de keepalive anormalmente altos.
Etapas para reduzir a exposição a ataques
Como servidor e proxy completo, o NGINX oferece aos administradores ferramentas avançadas para mitigar ataques de negação de serviço. Para aproveitar esses recursos, é essencial fazer as seguintes atualizações nos arquivos de configuração do NGINX, minimizando a superfície de ataque do servidor:
- keepalive_requests deve ser mantido na configuração padrão de 1.000 solicitações
- http2_max_concurrent_streams deve ser mantido na configuração padrão de 128 fluxos
Também recomendamos que estas medidas de segurança sejam adotadas como uma prática recomendada:
- limit_conn impõe um limite ao número de conexões permitidas de um único cliente. Essa diretiva deve ser adicionada com uma configuração adequada que equilibre o desempenho e a segurança da aplicação.
- limit_req impõe um limite ao número de solicitações de um único cliente que serão processadas em um determinado período. Essa diretiva deve ser adicionada com uma configuração adequada que equilibre o desempenho e a segurança da aplicação.
Como estamos respondendo
Testamos várias estratégias de mitigação que nos ajudaram a entender como esse ataque poderia afetar nossa ampla gama de clientes e usuários. Embora essa pesquisa tenha confirmado que o NGINX já conta com todas as ferramentas necessárias para evitar o ataque, quisemos tomar medidas adicionais para garantir que os usuários que realmente precisam configurar o NGINX além das especificações recomendadas possam fazê-lo.
Nossa investigação resultou em um método para melhorar a resiliência dos servidores diante de várias formas de ataques de inundação teoricamente possíveis por meio do protocolo HTTP/2. Como resultado, lançamos um patch que aumenta a estabilidade do sistema nessas condições. Para se proteger contra essas ameaças, recomendamos que os usuários do NGINX Open Source recompilarem os binários usando a base de código mais recente e que os clientes do NGINX Plus atualizem imediatamente para os pacotes mais recentes (R29p1 ou R30p1).
Como o patch funciona
Para garantir a detecção precoce de ataques de inundação no NGINX, o patch impõe um limite ao número de novos fluxos que podem ser introduzidos em um único ciclo de eventos. Esse limite é definido como o dobro do valor configurado por meio da diretiva http2_max_concurrent_streams. O limite será aplicado mesmo que o limite máximo nunca seja atingido, como quando os fluxos são redefinidos logo após o envio da solicitação (como ocorre neste ataque).
Produtos afetados
Esta vulnerabilidade afeta o módulo HTTP/2 do NGINX (ngx_http_v2_module). Para obter informações sobre seu produto específico da NGINX ou F5 que possa ser afetado, acesse: https://my.f5.com/manage/s/article/K000137106.
Para obter mais informações sobre a CVE-2023-44487 – Ataque de redefinição rápida do HTTP/2, consulte: https://www.cve.org/CVERecord?id=CVE-2023-44487
Agradecimentos
Gostaríamos de agradecer à Cloudflare, à Amazon e ao Google por sua contribuição na descoberta, identificação e mitigação desta vulnerabilidade.
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.