A demanda dos clientes por bens e serviços nos últimos dois anos ressaltou o quão crucial é para as organizações escalar facilmente e inovar mais rápido, levando muitas delas a acelerar a mudança de uma arquitetura monolítica para uma nativa da nuvem. De acordo com o recente relatório da F5, The State of Application Strategy 2021 , o número de organizações que modernizaram aplicativos aumentou 133% somente no ano passado. Os aplicativos habilitados para nuvem são projetados para serem modulares, distribuídos, implantados e gerenciados de forma automatizada. Embora seja possível simplesmente transferir e transferir um aplicativo monolítico existente, isso não oferece nenhuma vantagem em termos de custos ou flexibilidade. A melhor maneira de se beneficiar do modelo distribuído que os serviços de computação em nuvem oferecem é pensar em módulos – entre em contato com os microsserviços .
Microsserviços são uma abordagem arquitetônica que permite aos desenvolvedores criar um aplicativo como um conjunto de serviços de aplicativo leves que são estruturalmente independentes uns dos outros e da plataforma subjacente. Cada microsserviço é executado como um processo único 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 procurando maneiras de aumentar a eficiência e agilizar a implantação de aplicativos. As APIs permitem a comunicação entre softwares e fornecem os blocos de construção para o desenvolvimento. Para solicitar dados de servidores usando HTTP , os desenvolvedores web originalmente usavam SOAP , que envia detalhes da solicitação em um documento XML . No entanto, os documentos XML tendem a ser grandes, exigem uma sobrecarga substancial e levam muito tempo para serem desenvolvidos.
Desde então, muitos desenvolvedores migraram para REST , um estilo arquitetônico e um conjunto de diretrizes para criar APIs da web confiáveis e sem estado. Uma API web que obedece a essas diretrizes é chamada RESTful. As APIs da Web RESTful geralmente são baseadas em métodos HTTP para acessar recursos por meio de parâmetros codificados em URL e usam JSON ou XML para transmitir dados. Com o uso de APIs RESTful, os aplicativos são mais rápidos de desenvolver e geram menos sobrecarga.
Os avanços na tecnologia trazem novas oportunidades para avançar no design de aplicativos. Em 2015, o Google desenvolveu o Google Remote Procedure Call ( gRPC ) como uma estrutura RPC moderna de código aberto que pode ser executada em qualquer ambiente. Enquanto o REST é construído no protocolo HTTP 1.1 e usa um modelo de comunicação de solicitação-resposta, o gRPC usa HTTP/2 para transporte e um modelo de comunicação de cliente-resposta, implementado em buffers de protocolo (protobuf) como a 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 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, devido à eficiência do protobuf e ao uso do HTTP/2. O gRPC também permite comunicação de streaming e atende a várias solicitações simultaneamente.
Os desenvolvedores consideram a construção de microsserviços com gRPC uma alternativa atraente ao uso de APIs RESTful devido à sua baixa latência, suporte para vários idiomas, representação compacta de dados e streaming em tempo real, tudo o que o torna especialmente adequado para comunicação entre microsserviços e em redes de baixa potência e baixa largura de banda. O gRPC aumentou em popularidade porque facilita a construção de novos serviços de forma rápida e eficiente, com maior confiabilidade e escalabilidade, e com independência de idioma para clientes e servidores.
Embora a natureza aberta do protocolo gRPC ofereça vários benefícios positivos, o padrão não fornece nenhuma proteção contra o impacto que um ataque DoS pode ter em um aplicativo. Um aplicativo gRPC ainda pode sofrer os mesmos tipos de ataques DoS que um aplicativo tradicional.
Embora microsserviços e contêineres ofereçam aos desenvolvedores mais liberdade e autonomia para lançar rapidamente novos recursos aos clientes, eles também introduzem novas vulnerabilidades e oportunidades de exploração. Um tipo de ataque cibernético que ganhou 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 causadas pelo tratamento inadequado de solicitações gRPC. Os ataques DoS de camada 7 em aplicativos e APIs aumentaram 20% nos últimos anos, enquanto a escala e a gravidade do impacto aumentaram em quase 200%.
Um ataque DoS geralmente envia grandes quantidades de tráfego que parecem legítimas, para esgotar os recursos do aplicativo e torná-lo sem resposta. Em um ataque DoS típico, um criminoso inunda um site ou aplicativo com tanto tráfego que os servidores ficam sobrecarregados com todas as solicitações, fazendo com que eles parem ou até mesmo travem. Ataques DoS são projetados para deixar máquinas ou redes lentas ou desabilitá-las completamente, tornando-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 inutilizáveis.
Cada vez mais, temos visto mais ataques DoS usando solicitações HTTP e HTTP/2 ou chamadas de API para atacar a camada de aplicação (Camada 7), em grande parte porque os ataques da Camada 7 podem ignorar defesas tradicionais que não são projetadas para defender arquiteturas de aplicações modernas. Por que os invasores mudaram de ataques volumétricos tradicionais nas camadas de rede (camadas 3 e 4) para ataques de camada 7? Eles estão seguindo o caminho de menor resistência. Engenheiros de infraestrutura passaram anos criando mecanismos de defesa eficazes contra ataques de Camada 3 e Camada 4, tornando-os mais fáceis de bloquear e menos propensos a serem bem-sucedidos. Isso torna esses ataques mais caros de serem lançados, tanto em termos de dinheiro quanto de tempo, e por isso os invasores seguiram em frente.
Detectar ataques DoS em aplicativos gRPC é extremamente difícil, especialmente em ambientes modernos onde o dimensionamento é realizado automaticamente. Um serviço gRPC pode não ser projetado para lidar com tráfego de alto volume, 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 alvos quando o invasor explora definições de dados que são declaradas corretamente em uma especificação protobuf.
Um uso indevido típico, ainda que não intencional, de um serviço gRPC ocorre quando um bug em um script faz com que ele produza solicitações excessivas ao serviço. Por exemplo, suponha que um script de automação emita uma chamada de API quando uma determinada condição ocorre, o que os designers esperam que aconteça a cada dois segundos. No entanto, devido a um erro na definição da condição, o script emite a chamada a cada dois milissegundos, criando uma carga inesperada no serviço gRPC de backend.
Outros exemplos de ataques DoS em um aplicativo gRPC incluem:
POST
lento envia solicitações parciais no cabeçalho gRPC. Antecipando 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, causando a rejeição de tentativas de conexão adicionais de clientes.SETTING
vazios para o protocolo gRPC, consome recursos do NGINX, tornando-o incapaz de atender novas solicitações.Proteger aplicativos contra ataques DoS atuais requer uma abordagem moderna. Para proteger aplicativos complexos e adaptáveis, você precisa de uma solução que forneça proteção dinâmica e altamente precisa com base no comportamento do usuário e do site e alivie a carga das equipes de segurança, ao mesmo tempo em que oferece suporte ao rápido desenvolvimento de aplicativos e à vantagem competitiva.
O F5 NGINX App Protect DoS é um módulo de software leve para o NGINX Plus, desenvolvido com base no WAF e na proteção comportamental líderes de mercado da F5. Projetado para defender até mesmo contra os ataques DoS de Camada 7 mais sofisticados, o NGINX App Protect DoS usa algoritmos exclusivos para criar um modelo estatístico dinâmico que fornece aprendizado de máquina adaptável e proteção automatizada. Ele mede continuamente a eficácia da mitigação e se adapta às mudanças no comportamento do usuário e do site, além de executar verificações proativas da integridade do servidor. Para obter detalhes, consulte Como o NGINX App Protect Denial of Service se adapta ao cenário de ataques em evolução 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 atenua ataques com base em assinaturas e identificação de agentes mal-intencionados. Na fase inicial de mitigação de assinatura, o NGINX App Protect DoS cria perfis dos atributos associados ao comportamento anômalo para criar assinaturas dinâmicas que bloqueiam solicitações que correspondem a esse comportamento daqui para frente. Se o ataque persistir, o NGINX App Protect DoS passa para a fase de mitigação de agentes mal-intencionados.
Com base na detecção de anomalias estatísticas, o NGINX App Protect DoS identifica com sucesso agentes mal-intencionados por endereço IP de origem e impressões digitais TLS, permitindo gerar e implantar assinaturas dinâmicas que identificam e mitigam automaticamente esses padrões específicos de tráfego de ataque. Essa abordagem é diferente das soluções DoS tradicionais no mercado que detectam quando um limite volumétrico é excedido. O NGINX App Protect DoS pode bloquear ataques em que as solicitações parecem completamente legítimas e cada invasor pode até gerar menos tráfego do que o usuário legítimo médio.
Os painéis do Kibana a seguir mostram como o NGINX App Protect DoS detecta e atenua de forma rápida e automática um ataque de inundação DoS em um aplicativo gRPC.
A Figura 1 exibe um aplicativo gRPC sofrendo um ataque de inundação DoS. No contexto do gRPC, a métrica crítica é 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 do DPS de linha de base converge para o valor do DPS de entrada (em azul), o NGINX App Protect aprendeu como é o tráfego "normal" para este aplicativo. O aumento acentuado no DPS em 12:25:00 indica o início de um ataque. O alarme vermelho indica o ponto em que o NGINX App Protect DoS tem certeza de que há um ataque em andamento e inicia as fases de mitigação.
A Figura 2 mostra o NGINX App Protect DoS no processo de detecção de comportamento anômalo e de frustração de um ataque de inundação DoS 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 global de mitigação de taxa. O gráfico roxo representa os redirecionamentos enviados para 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 para agentes maliciosos específicos detectados e identificados por endereço IP e impressão digital TLS.
A Figura 3 mostra uma assinatura dinâmica criada pelo NGINX App Protect DoS que é alimentada por aprendizado de máquina e cria perfis dos atributos associados ao comportamento anômalo desse ataque de inundação gRPC. A assinatura bloqueia solicitações que correspondem a ela durante a fase inicial de mitigação de assinatura.
A Figura 4 mostra como o NGINX App Protect DoS passa da mitigação baseada em assinatura para a mitigação de agentes mal-intencionados quando um ataque persiste. Ao analisar o comportamento do usuário, o NGINX App Protect DoS identificou agentes mal-intencionados pelo endereço IP de origem e pelas impressões digitais TLS mostradas aqui. Em vez de analisar cada solicitação em busca de assinaturas específicas que indiquem comportamento anômalo, aqui o serviço é negado a invasores específicos. Isso permite a geração de assinaturas dinâmicas que identificam esses padrões de ataque específicos e os mitigam automaticamente.
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 para o protobuf. Isso fornece uma solução de política de segurança zero-touch – você não precisa depender da definição protobuf para proteger o serviço gRPC de ataques. Os arquivos proto gRPC são frequentemente usados como parte de pipelines de CI/CD , alinhando equipes de segurança e desenvolvimento ao automatizar a proteção e habilitar a segurança como código para integração completa do pipeline de CI/CD. O NGINX App Protect DoS garante segurança consistente ao integrar perfeitamente a proteção aos seus aplicativos gRPC para que eles estejam sempre protegidos pelas políticas de segurança mais recentes e atualizadas .
Embora o gRPC forneça a velocidade e a flexibilidade que os desenvolvedores precisam para projetar e implantar aplicativos modernos, a natureza aberta inerente de sua estrutura o torna altamente vulnerável a ataques DoS. Para ficar à frente de ataques DoS severos da Camada 7 que podem resultar em degradação de desempenho, interrupções de aplicativos e sites, abandono de receita e danos à fidelidade do cliente e à marca, você precisa de uma defesa moderna. É por isso que o NGINX App Protect DoS é essencial para seus aplicativos gRPC modernos.
Para experimentar o NGINX App Protect DoS com NGINX Plus, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .
Para mais informações, confira nosso whitepaper, Protegendo aplicativos modernos contra ataques DoS de camada 7 .
"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."