Nos últimos anos, o Google observou que os ataques distribuídos de negação de serviço (DDoS) estão aumentando em frequência e crescendo exponencialmente. As cargas de trabalho atuais voltadas para a Internet estão em constante risco de ataque com impactos que vão desde a degradação do desempenho e da experiência do usuário para usuários legítimos até o aumento dos custos operacionais e de hospedagem e a indisponibilidade total de cargas de trabalho de missão crítica. Os clientes do Google Cloud podem usar o Cloud Armor para aproveitar a escala global e a capacidade da borda da rede do Google para proteger seu ambiente de alguns dos maiores ataques DDoS já vistos.
Em 1º de junho, um cliente do Google Cloud Armor foi alvo de uma série de ataques HTTPS DDoS que atingiram o pico de 46 milhões de solicitações por segundo. Este é o maior DDoS de Camada 7 relatado até o momento – pelo menos 76% maior do que o registro relatado anteriormente. Para dar uma ideia da escala do ataque, é como receber todas as solicitações diárias para a Wikipedia (um dos 10 sites mais trafegados do mundo) em apenas 10 segundos.
O Cloud Armor Adaptive Protection foi capaz de detectar e analisar o tráfego no início do ciclo de vida do ataque. A Cloud Armor alertou o cliente com uma regra de proteção recomendada, que foi implantada antes que o ataque chegasse à sua magnitude total. A Cloud Armor bloqueou o ataque, garantindo que o serviço do cliente permanecesse online e continuasse atendendo seus usuários finais.
O que aconteceu: análise de ataque e linha do tempo
A partir das 9h45 PT de 1º de junho de 2022, um ataque de mais de 10.000 solicitações por segundo (rps) começou a atingir o balanceador de carga HTTP/S de nosso cliente. Oito minutos depois, o ataque cresceu para 100.000 solicitações por segundo. O Cloud Armor Adaptive Protection detectou o ataque e gerou um alerta contendo a assinatura do ataque avaliando o tráfego em várias dezenas de recursos e atributos. O alerta incluiu uma regra recomendada para bloquear a assinatura maliciosa.
A equipe de segurança de rede de nosso cliente implantou a regra recomendada pela Cloud Armor em sua política de segurança e imediatamente começou a bloquear o tráfego de ataque. Nos dois minutos que se seguiram, o ataque começou a aumentar, passando de 100.000 rps para um pico de 46 milhões de rps. Como o Cloud Armor já estava bloqueando o tráfego de ataque, a carga de trabalho de destino continuou a operar normalmente. Nos minutos seguintes, o ataque começou a diminuir de tamanho, terminando 69 minutos depois, às 10h54. Presumivelmente, o invasor provavelmente determinou que não estava tendo o impacto desejado ao incorrer em despesas significativas para executar o ataque.
Analisando o ataque
Além do volume de tráfego inesperadamente alto, o ataque teve outras características dignas de nota. Havia 5.256 IPs de origem de 132 países contribuindo para o ataque. Como você pode ver na Figura 2 acima, os 4 principais países contribuíram com aproximadamente 31% do tráfego total de ataques. O ataque alavancou solicitações criptografadas (HTTPS) que exigiriam recursos computacionais adicionais para serem geradas. Embora o encerramento da criptografia fosse necessário para inspecionar o tráfego e mitigar efetivamente o ataque, o uso do HTTP Pipelining exigia que o Google concluísse relativamente poucos handshakes TLS.
Aproximadamente 22% (1.169) dos IPs de origem correspondiam a nós de saída do Tor, embora o volume de requisições provenientes desses nós representasse apenas 3% do tráfego de ataque. Embora acreditemos que a participação do Tor no ataque foi incidental devido à natureza dos serviços vulneráveis, mesmo em 3% do pico (mais de 1,3 milhão de rps), nossa análise mostra que os nós de saída do Tor podem enviar uma quantidade significativa de tráfego indesejado para aplicativos e serviços da web.
A distribuição geográfica e os tipos de serviços não seguros aproveitados para gerar o ataque correspondem à família de ataques Mēris. Conhecido por seus ataques maciços que quebraram recordes de DDoS, o método Mēris abusa de proxies não seguros para ofuscar a verdadeira origem dos ataques.
Como paramos o ataque
O ataque foi interrompido na borda da rede do Google, com as solicitações maliciosas bloqueadas a montante do aplicativo do cliente. Antes do início do ataque, o cliente já havia configurado o Adaptive Protection em sua política de segurança relevante da Cloud Armor para aprender e estabelecer um modelo de linha de base dos padrões de tráfego normais para seu serviço.
Como resultado, o Adaptive Protection foi capaz de detectar o ataque DDoS no início de seu ciclo de vida, analisar seu tráfego de entrada e gerar um alerta com uma regra de proteção recomendada – tudo antes que o ataque se intensificasse. O cliente agiu de acordo com o alerta implantando a regra recomendada, aproveitando o recurso de limitação de taxa recentemente lançado do Cloud Armor para limitar o tráfego de ataque. Eles escolheram a ação de ‘acelerador’ em vez de uma ação de ‘negar’ para reduzir a chance de impacto no tráfego legítimo, limitando severamente a capacidade de ataque, eliminando a maior parte do volume de ataque na borda da rede do Google.
Antes de implantar a regra no modo de imposição, ela foi implantada primeiro no modo de visualização, o que permitiu ao cliente validar que apenas o tráfego indesejado seria negado enquanto os usuários legítimos poderiam continuar acessando o serviço. À medida que o ataque atingiu seu pico de 46 milhões de rps, a regra sugerida pela Cloud Armor já estava em vigor para bloquear a maior parte do ataque e garantir que os aplicativos e serviços direcionados permanecessem disponíveis.
Protegendo seus aplicativos na nuvem
Os tamanhos de ataque continuarão a crescer e as táticas continuarão a evoluir. Para estar preparado, o Google recomenda usar uma estratégia de defesa profunda implantando defesas e controles em várias camadas do seu ambiente e da rede de seus provedores de infraestrutura para proteger seus aplicativos e serviços da Web contra ataques direcionados da Web. Essa estratégia inclui a modelagem de ameaças para entender as superfícies de ataque de seus aplicativos, desenvolver estratégias proativas e reativas para protegê-los e arquitetar seus aplicativos com capacidade suficiente para gerenciar aumentos imprevistos no volume de tráfego.
