Proteja seus aplicativos gRPC contra ataques graves de DoS com o NGINX App Protect DoS

A demanda dos clientes por bens e serviços nos últimos dois anos ressaltou como é crucial para as organizações ganhar escala com facilidade e inovar mais rapidamente, levando muitas delas a acelerar a migração de uma arquitetura monolítica para uma arquitetura nativa da nuvem. De acordo com o recente relatório da F5, O Estado da Estratégia de Aplicações 2021, o número de organizações modernizando aplicações aumentou 133% somente no último ano. As aplicações habilitadas para a nuvem são projetadas para serem modulares, distribuídas, implantadas e gerenciadas de forma automatizada. Embora seja possível simplesmente migrar uma aplicação monolítica existente sem modificações, isso não oferece nenhuma vantagem em termos de custos ou flexibilidade. A melhor maneira de aproveitar o modelo distribuído proporcionado pelos serviços de computação em nuvem é pensar de forma modular — é aí que entram os microsserviços.

Microsserviços são uma abordagem arquitetural que permite aos desenvolvedores criar uma aplicação como um conjunto de serviços leves, estruturalmente independentes entre si e da plataforma subjacente. Cada microsserviço é executado como um processo exclusivo e se comunica com outros serviços por meio de APIs bem definidas e padronizadas. Cada serviço pode ser desenvolvido e implantado por uma pequena equipe independente. Essa flexibilidade proporciona às organizações maiores benefícios em termos de desempenho, custo, escalabilidade e capacidade de inovar rapidamente.

Os desenvolvedores estão sempre buscando maneiras de aumentar a eficiência e agilizar a implantação de aplicações. As APIs permitem a comunicação entre softwares e fornecem os componentes básicos para o desenvolvimento. Para solicitar dados de servidores usando HTTP, os desenvolvedores web utilizavam originalmente o SOAP, que envia os detalhes da solicitação em um documento XML. No entanto, documentos XML tendem a ser grandes, exigem uma sobrecarga considerável e levam muito tempo para serem desenvolvidos.

Desde então, muitos desenvolvedores migraram para o REST, um estilo arquitetural e um conjunto de diretrizes para a criação de APIs web confiáveis e sem estado. Uma API web que segue essas diretrizes é chamada de RESTful. As APIs web RESTful geralmente se baseiam em métodos HTTP para acessar recursos por meio de parâmetros codificados em URLs e usam JSON ou XML para transmitir dados. Com o uso de APIs RESTful, o desenvolvimento de aplicações é mais rápido e gera menos sobrecarga.

Os avanços tecnológicos trazem novas oportunidades para aprimorar o design de aplicações. Em 2015, o Google desenvolveu o Google Remote Procedure Call (gRPC) como uma moderna estrutura RPC de código aberto capaz de ser executada em qualquer ambiente. Enquanto o REST se baseia no protocolo HTTP 1.1 e usa um modelo de comunicação de solicitação e resposta, o gRPC usa HTTP/2 para transporte e um modelo de comunicação cliente-resposta, implementado em buffers de protocolo (protobuf) como linguagem de descrição de interface (IDL) usada para descrever serviços e dados. O Protobuf é usado para serializar dados estruturados e foi projetado para oferecer simplicidade e desempenho. O gRPC é aproximadamente 7 vezes mais rápido que o REST ao receber dados e 10 vezes mais rápido ao enviar dados, graças à eficiência do protobuf e ao uso do HTTP/2. O gRPC também permite comunicação por streaming e atende a várias solicitações simultaneamente.

Os desenvolvedores consideram a criação de microsserviços com gRPC uma alternativa atraente ao uso de APIs RESTful devido à baixa latência, ao suporte a várias linguagens, à representação compacta de dados e ao streaming em tempo real, características que o tornam especialmente adequado para a comunicação entre microsserviços e em redes de baixo consumo de energia e baixa largura de banda. A popularidade do gRPC aumentou porque ele facilita a criação rápida e eficiente de novos serviços, com maior confiabilidade e escalabilidade, além de oferecer independência de linguagem tanto para clientes quanto para servidores.

Embora a natureza aberta do protocolo gRPC ofereça vários benefícios, o padrão não fornece nenhuma proteção contra o impacto que um ataque de DoS pode causar em uma aplicação. Uma aplicação gRPC ainda pode sofrer os mesmos tipos de ataques de DoS que uma aplicação tradicional.

Por que é difícil identificar um ataque de DoS em um aplicativo gRPC

Embora os microsserviços e os contêineres proporcionem aos desenvolvedores mais liberdade e autonomia para disponibilizar rapidamente novos recursos aos clientes, eles também introduzem novas vulnerabilidades e oportunidades de exploração. Um tipo de ataque cibernético que vem ganhando popularidade são os ataques de negação de serviço (DoS), que, nos últimos anos, têm sido responsáveis por um número crescente de vulnerabilidades e exposições comuns (CVEs), muitas delas causadas pelo tratamento inadequado de solicitações gRPC. Os ataques DoS de camada 7 contra aplicações e APIs aumentaram 20% nos últimos anos, enquanto a escala e a gravidade do impacto cresceram quase 200%.

Um ataque de DoS geralmente envia grandes volumes de tráfego aparentemente legítimo para esgotar os recursos da aplicação e fazer com que ela pare de responder. Em um ataque de DoS típico, um agente mal-intencionado inunda um site ou uma aplicação com tanto tráfego que os servidores ficam sobrecarregados com todas as solicitações, fazendo com que fiquem paralisados ou até mesmo falhem. Os ataques de DoS são projetados para tornar máquinas ou redes lentas ou desativá-las completamente, deixando-as inacessíveis para as pessoas que precisam delas. Até que o ataque seja mitigado, os serviços que dependem da máquina ou da rede – como sites de comércio eletrônico, e-mail e contas online – ficam indisponíveis.

Cada vez mais, temos observado ataques de DoS que usam solicitações HTTP e HTTP/2 ou chamadas de API para atingir a camada de aplicação (Camada 7), em grande parte porque os ataques de Camada 7 conseguem contornar defesas tradicionais que não foram projetadas para proteger arquiteturas de aplicações modernas. Por que os invasores migraram dos ataques volumétricos tradicionais nas camadas de rede (Camadas 3 e 4) para ataques de Camada 7? Porque estão seguindo o caminho de menor resistência. Os engenheiros de infraestrutura passaram anos desenvolvendo mecanismos de defesa eficazes contra ataques de Camada 3 e Camada 4, tornando-os mais fáceis de bloquear e menos propensos a ter sucesso. Isso torna o lançamento desses ataques mais caro, tanto em termos de dinheiro quanto de tempo, e, por isso, os invasores partiram para outros tipos de ataque.

Detectar ataques de DoS em aplicações gRPC é extremamente difícil, especialmente em ambientes modernos nos quais o escalonamento horizontal é realizado automaticamente. Um serviço gRPC pode não ter sido projetado para lidar com um alto volume de tráfego, o que o torna um alvo fácil para invasores derrubarem. Os serviços gRPC também são vulneráveis a ataques de inundação HTTP/2 com ferramentas como h2load. Além disso, os serviços gRPC podem ser facilmente atacados quando o invasor explora definições de dados devidamente declaradas em uma especificação protobuf.

Um exemplo comum, embora não intencional, de uso indevido de um serviço gRPC ocorre quando um bug em um script faz com que ele envie solicitações em excesso ao serviço. Por exemplo, suponha que um script de automação faça uma chamada de API quando determinada condição ocorrer, algo que os desenvolvedores esperam que aconteça a cada dois segundos. No entanto, devido a um erro na definição da condição, o script faz a chamada a cada dois milissegundos, gerando uma carga inesperada no serviço gRPC de backend.

Outros exemplos de ataques de DoS contra uma aplicação gRPC incluem:

• A inserção de um campo malicioso em uma mensagem gRPC pode causar uma falha no aplicativo.
• Um ataque Slow POST envia solicitações parciais no cabeçalho gRPC. Enquanto aguarda a chegada do restante da solicitação, o aplicativo ou servidor mantém a conexão aberta. O pool de conexões simultâneas pode ficar cheio, fazendo com que novas tentativas de conexão dos clientes sejam rejeitadas.
• Um ataque de inundação de configurações HTTP/2 (CVE-2019-9515), no qual o invasor envia quadros SETTING vazios ao protocolo gRPC, consome os recursos do NGINX, impedindo-o de atender a novas solicitações.

Aproveite o poder da análise dinâmica do comportamento de usuários e sites para mitigar ataques de DoS ao gRPC com o NGINX App Protect DoS

Proteger aplicações contra os ataques de DoS atuais exige uma abordagem moderna. Para proteger aplicações complexas e adaptáveis, você precisa de uma solução que ofereça proteção dinâmica e altamente precisa, baseada no comportamento dos usuários e do site, e reduza a carga das equipes de segurança, ao mesmo tempo que favorece o desenvolvimento ágil de aplicações e a vantagem competitiva.

F5 NGINX App Protect DoS é um módulo de software leve para NGINX Plus, desenvolvido com base no WAF e na proteção comportamental líderes de mercado da F5. Projetado para oferecer defesa até mesmo contra os ataques de DoS de camada 7 mais sofisticados, o NGINX App Protect DoS usa algoritmos exclusivos para criar um modelo estatístico dinâmico que oferece aprendizado de máquina adaptativo e proteção automatizada. Ele mede continuamente a eficácia da mitigação, adapta-se às mudanças no comportamento dos usuários e do site e realiza verificações proativas da integridade do servidor. Para obter detalhes, consulte Como o NGINX App Protect Denial of Service se adapta à evolução do cenário de ataques em nosso blog.

A análise comportamental é fornecida tanto para aplicativos HTTP tradicionais quanto para cabeçalhos de aplicativos HTTP/2 modernos. O NGINX App Protect DoS mitiga ataques com base em assinaturas e na identificação de agentes mal-intencionados. Na fase inicial de mitigação por assinatura, o NGINX App Protect DoS traça o perfil dos atributos associados ao comportamento anômalo para criar assinaturas dinâmicas que passam a bloquear solicitações correspondentes a esse comportamento. Se o ataque persistir, o NGINX App Protect DoS avança para a fase de mitigação de agentes mal-intencionados.

Com base na detecção estatística de anomalias, o NGINX App Protect DoS identifica com sucesso agentes mal-intencionados pelo endereço IP de origem e pelas impressões digitais TLS, o que permite gerar e implantar assinaturas dinâmicas que identificam e mitigam automaticamente esses padrões específicos de tráfego de ataque. Essa abordagem difere das soluções tradicionais de DoS disponíveis no mercado, que detectam quando um limite volumétrico é excedido. O NGINX App Protect DoS pode bloquear ataques nos quais as solicitações parecem totalmente legítimas e cada invasor pode até mesmo gerar menos tráfego do que um usuário legítimo médio.

Os painéis do Kibana a seguir mostram como o NGINX App Protect DoS detecta e mitiga, de forma rápida e automática, um ataque de inundação de DoS contra uma aplicação gRPC.

A Figura 1 mostra um aplicativo gRPC sofrendo um ataque de inundação DoS. No contexto do gRPC, a métrica crítica é o número de datagramas por segundo (DPS), que corresponde à taxa de mensagens por segundo. Nesta imagem, a curva amarela representa o processo de aprendizado: quando a previsão de DPS de referência converge para o valor de DPS de entrada (em azul), o NGINX App Protect aprendeu como é o tráfego “normal” desse aplicativo. O aumento acentuado no DPS às 12:25:00 indica o início de um ataque. O sino de alarme vermelho indica o momento em que o NGINX App Protect DoS está confiante de que há um ataque em andamento e inicia as fases de mitigação.

Figura 1: Um aplicativo gRPC sofrendo um ataque de DoS

A Figura 2 mostra o NGINX App Protect DoS no processo de detecção de comportamentos anômalos e de bloqueio de um ataque de inundação de DoS contra gRPC usando uma abordagem de mitigação em fases. O pico vermelho indica o número de redirecionamentos HTTP/2 enviados a todos os clientes durante a fase de mitigação global de taxa. O gráfico roxo representa os redirecionamentos enviados a clientes específicos quando suas solicitações correspondem a uma assinatura que modela o comportamento anômalo. O gráfico amarelo representa os redirecionamentos enviados a agentes mal-intencionados específicos detectados e identificados pelo endereço IP e pela impressão digital TLS.

Figura 2: NGINX App Protect DoS usando uma abordagem de mitigação em fases para impedir um ataque de inundação de DoS via gRPC

A Figura 3 mostra uma assinatura dinâmica criada pelo NGINX App Protect DoS, baseada em aprendizado de máquina, que traça o perfil dos atributos associados ao comportamento anômalo desse ataque de inundação gRPC. A assinatura bloqueia as solicitações correspondentes durante a fase inicial de mitigação por assinatura.

Figura 3: Uma assinatura dinâmica

A Figura 4 mostra como o NGINX App Protect DoS passa da mitigação baseada em assinaturas para a mitigação de agentes mal-intencionados quando um ataque persiste. Ao analisar o comportamento dos usuários, o NGINX App Protect DoS identificou agentes mal-intencionados por meio do endereço IP de origem e das impressões digitais TLS mostradas aqui. Em vez de examinar cada solicitação em busca de assinaturas específicas que indiquem um comportamento anômalo, o serviço é negado a invasores específicos. Isso permite gerar assinaturas dinâmicas que identificam esses padrões de ataque específicos e os mitigam automaticamente.

Figura 4: NGINX App Protect DoS identificando agentes mal-intencionados por endereço IP e impressão digital TLS

Com as APIs gRPC, você usa a interface gRPC para definir a política de segurança no arquivo da biblioteca de tipos (IDL) e nos arquivos de definição proto do protobuf. Isso oferece uma solução de política de segurança sem intervenção manual – você não precisa depender da definição do protobuf para proteger o serviço gRPC contra ataques. Os arquivos proto do gRPC são frequentemente usados como parte de pipelines de CI/CD, alinhando as equipes de segurança e desenvolvimento por meio da automação da proteção e da adoção de segurança como código para uma integração completa com o pipeline de CI/CD. O NGINX App Protect DoS garante uma segurança consistente ao integrar perfeitamente a proteção aos seus aplicativos gRPC, para que estejam sempre protegidos pelas políticas de segurança mais recentes e atualizadas.

Embora o gRPC ofereça a velocidade e a flexibilidade de que os desenvolvedores precisam para projetar e implantar aplicações modernas, a natureza inerentemente aberta de sua estrutura o torna altamente vulnerável a ataques de DoS. Para se antecipar a ataques graves de DoS na Camada 7, que podem resultar em degradação do desempenho, indisponibilidade de aplicações e sites, perda de receita e danos à fidelidade dos clientes e à marca, você precisa de uma defesa moderna. É por isso que o NGINX App Protect DoS é essencial para suas aplicações gRPC modernas.

Para experimentar o NGINX App Protect DoS com o NGINX Plus, inicie hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Para mais informações, confira nosso whitepaper, “Proteção de aplicações modernas contra ataques de DoS na camada 7”.

---