Como a Cloudflare mitigou automaticamente um ataque DDoS recorde mundial de 3,8 Tbps

Desde o início de setembro, os sistemas de proteção contra DDoS da Cloudflare têm combatedo uma campanha de um mês de ataques DDoS hipervolumétricos nas camadas 3/4. As defesas da Cloudflare mitigaram mais de cem ataques DDoS hipervolumétricos nas camadas 3 e 4 ao longo do mês, com muitos excedendo 2 bilhões de pacotes por segundo (Bpps) e 3 terabits por segundo (Tbps). O maior ataque atingiu o pico de3,8 Tbps, o maior já divulgado publicamente por qualquer organização. A detecção e a mitigação foram totalmente autônomas. Os gráficos abaixo representam dois eventos de ataques separados que tiveram como alvo o mesmo cliente da Cloudflare e foram mitigados de forma autônoma.

Um ataque DDoS mitigado de 3,8 Terabits por segundo que durou 65 segundos

Um ataque DDoS mitigado de 2,14 bilhões de pacotes por segundo que durou 60 segundos

Os clientes da Cloudflare que usam os serviços de proxy reverso HTTP da Cloudflare (por exemplo, Cloudflare WAF e CDN da Cloudflare) estão protegidos automaticamente.

Os clientes da Cloudflare que usam o Spectrum e o Magic Transit também estão protegidos automaticamente. Os clientes do Magic Transit podem otimizar ainda mais sua proteção implantando regras do Magic Firewall para impor um modelo de segurança positivo e negativo rigoroso na camada de pacote.

A escala e a frequência desses ataques não têm precedentes. Devido ao seu tamanho e taxas de bits/pacotes por segundo, esses ataques têm a capacidade de derrubar ativos da internet desprotegidos, bem como ativos da internet protegidos por equipamentos no local ou por provedores de nuvem que simplesmente não têm capacidade de rede suficiente ou cobertura global para conseguir lidar com esses volumes paralelamente ao tráfego legítimo, sem afetar o desempenho. 

A Cloudflare, no entanto, tem a capacidade de rede, a cobertura global e os sistemas inteligentes necessários para absorver e mitigar automaticamente esses ataques monstruosos. 

Neste post do blog, analisaremos a campanha de ataques e por que seus ataques são tão graves. Vamos descrever a anatomia de um ataque DDoS nas camadas 3/4, seus objetivos e como os ataques são gerados. Em seguida, iremos detalhar como os sistemas da Cloudflare foram capazes de detectar e mitigar de forma autônoma esses ataques monstruosos sem afetar o desempenho de nossos clientes. Vamos descrever os principais aspectos de nossas defesas, começando com a forma como nossos sistemas geram assinaturas em tempo real (dinâmicas) para corresponder ao tráfego de ataques até como aproveitamos os recursos do kernel para descartar pacotes na velocidade do fio.

Observamos essa campanha de ataques visando vários clientes nos setores de serviços financeiros, internet e telecomunicações, entre outros. Essa campanha de ataque visa a saturação de largura de banda, bem como o esgotamento de recursos de aplicativos e dispositivos in-line.

Os ataques aproveitam predominantemente o UDP em uma porta fixa e são originados em todo o mundo com ataques maiores vindos do Vietnã, da Rússia, do Brasil, da Espanha e dos Estados Unidos. 

Os ataques de alta taxa de pacotes parecem se originar de vários tipos de dispositivos comprometidos, incluindo dispositivos MikroTik, DVRs e servidores web, orquestrados para trabalhar em conjunto e inundar o alvo com volumes de tráfego excepcionalmente grandes. Os ataques de alta taxa de bits parecem se originar de um grande número de roteadores domésticos da ASUS comprometidos, provavelmente explorados usando uma vulnerabilidade CVE 9.8 (Crítica) que foi descoberta recentemente pela Censys.

^{Participação de pacotes observados por local de origem}

Antes de discutirmos como a Cloudflare detectou e mitigou automaticamente os maiores ataques DDoS já vistos, é importante entender o básico sobre ataques DDoS.

Diagrama simplificado de um ataque DDoS

O objetivo de um ataque de negação de serviço distribuída (DDoS) é negar o acesso de usuários legítimos a um serviço. Isso geralmente é feito ao esgotar os recursos necessários para fornecer o serviço. No contexto desses recentes ataques DDoS nas camadas 3/4, esse recurso são os ciclos de CPU e a largura de banda de rede .

O processamento de um pacote consome ciclos de CPU. No caso de tráfego normal (sem ataque), um pacote legítimo recebido por um serviço fará com que esse serviço execute alguma ação e ações diferentes requerem quantidades diferentes de processamento da CPU. No entanto, antes mesmo que um pacote seja entregue a um serviço, há um trabalho por pacote que precisa ser feito. Os cabeçalhos de pacote da camada 3 precisam ser analisados e processados para entregar o pacote à máquina e à interface corretas. Os cabeçalhos de pacote da camada 4 precisam ser processados e roteados para o soquete correto (se houver). Pode haver várias etapas de processamento adicionais que inspecionam cada pacote. Portanto, se um invasor enviar a uma taxa de pacotes alta o suficiente , ele pode saturar os recursos disponíveis da CPU, negando serviço para usuários legítimos.

Para se defender contra ataques de alta taxa de pacotes, você precisa ser capaz de inspecionar e descartar os pacotes ruins usando o menor número de ciclos de CPU possível, deixando CPU suficiente para processar os pacotes bons. Além disso, você pode adquirir mais CPUs ou CPUs mais rápidas para realizar o processamento, mas esse processo pode ser muito demorado e com altos custos. 

A largura de banda da rede é a quantidade total de dados por vez que podem ser entregues a um servidor. Você pode pensar na largura de banda como um cano para transportar água. A quantidade de água que podemos fornecer por meio de um canudo é menor do que podemos fornecer por meio de uma mangueira de jardim. Se um invasor for capaz de enviar mais dados de lixo em um canal do que ele pode distribuir, então tanto os dados ruins quanto os dados bons serão descartados upstream, na entrada do canal, e o DDoS será, portanto, bem-sucedido.

A defesa contra ataques que podem saturar a largura de banda da rede pode ser difícil porque há muito pouco que pode ser feito se você estiver no lado downstream do canal saturado. Na verdade, existem apenas algumas opções: você pode obter um canal maior, pode encontrar uma maneira de mover o tráfego legítimo para um novo canal que não esteja saturado ou pode pedir ao lado upstream do canal para parar de enviar alguns ou todos os dados no canal.

Se pensarmos no que isso significa pelo ponto de vista do invasor, percebemos que existem restrições semelhantes. Assim como são necessários ciclos de CPU para receber um pacote, também são necessários ciclos de CPU para criar um pacote. Se, por exemplo, o custo para enviar e receber um pacote fosse igual, então o invasor precisaria de uma quantidade igual de capacidade de CPU para gerar o ataque assim como nós precisaríamos para nos defender dele. Na maioria dos casos, isso não é verdade. Há uma assimetria de custos, pois o invasor pode gerar pacotes usando menos ciclos de CPU do que leva para receber esses pacotes. No entanto, vale a pena notar que gerar ataques não é gratuito e pode exigir uma grande quantidade de capacidade de CPU.

Saturar a largura de banda de rede pode ser ainda mais difícil para um invasor. Aqui o invasor precisa ser capaz de gerar mais largura de banda do que o serviço visado alocou. Na verdade, ele precisa ser capaz de exceder a capacidade do serviço receptor. Isso é tão difícil que a maneira mais comum de conseguir um ataque de largura de banda de rede é usar um método de ataque de reflexão/amplificação, por exemplo, um ataque de amplificação de DNS. Esses ataques permitem que o invasor envie um pequeno pacote a um serviço intermediário e o serviço intermediário enviará um grande pacote à vítima.

Em ambos os cenários, o invasor precisa adquirir ou obter acesso a muitos dispositivos para gerar o ataque. Esses dispositivos podem ser adquiridos de várias maneiras diferentes. Podem ser máquinas de classe de servidor de provedores de nuvem ou serviços de hospedagem, ou podem ser dispositivos comprometidos como DVRs, roteadores e webcams que foram infectados com o malware do invasor . Essas máquinas juntas formam a botnet.

Agora que entendemos os fundamentos de como os ataques DDoS funcionam, podemos explicar como a Cloudflare pode proteger contra esses ataques.

O primeiro ingrediente não tão secreto é que a rede da Cloudflare é construída sobre Anycast. Em resumo, o anycast permite que um único endereço de IP seja anunciado por várias máquinas em todo o mundo. Um pacote enviado para esse endereço de IP será entregue pela máquina mais próxima. Isso significa que quando um invasor usar sua botnet distribuída para lançar um ataque, o ataque será recebido de maneira distribuída na rede da Cloudflare. Um DVR infectado em Dallas, Texas, enviará pacotes para um servidor da Cloudflare em Dallas. Uma webcam infectada em Londres enviará pacotes para um servidor da Cloudflare em Londres.

^{Redes Anycast versus Unicast}

Nossa rede anycast também permite que a Cloudflare aloque recursos de computação e largura de banda mais próximos das regiões que mais precisam deles. Regiões densamente povoadas gerarão maiores quantidades de tráfego legítimo e os data centers colocados nessas regiões terão mais largura de banda e recursos de CPU para atender a essas necessidades. Regiões pouco povoadas naturalmente gerarão menos tráfego legítimo, então os data centers da Cloudflare nessas regiões podem ser dimensionados adequadamente. Como o tráfego de ataque vem principalmente de dispositivos comprometidos, esses dispositivos tendem a ser distribuídos de maneira a corresponder aos fluxos de tráfego normais, enviando o tráfego de ataques proporcionalmente para data centers que podem lidar com ele. Da mesma forma, dentro do data center, o tráfego é distribuído por várias máquinas.

Além disso, para ataques de alta largura de banda, a rede da Cloudflare apresenta outra vantagem. Uma grande proporção do tráfego na rede da Cloudflare não consome largura de banda de maneira simétrica. Por exemplo, uma solicitação HTTP para obter uma página web de um site protegido pela Cloudflare será um pacote de entrada relativamente pequeno, mas produzirá uma quantidade maior de tráfego de saída de volta para o cliente. Isso significa que a rede da Cloudflare tende a deixar sair de um tráfego muito mais legítimo do que o que recebemos. No entanto, os links de rede e a largura de banda alocada são simétricos, o que significa que há uma abundância de largura de banda de entrada disponível para receber tráfego de ataque volumétrico.

No momento em que você alcança um servidor individual dentro de um data center, a largura de banda do ataque já foi distribuída o suficiente para que nenhum dos links upstream fique saturado. Isso não significa que o ataque já foi totalmente interrompido, pois não descartamos os pacotes ruins. Para fazer isso, precisamos coletar uma amostra do tráfego, qualificar um ataque e criar regras para bloquear os pacotes ruins.  Amostra de tráfego e descartar pacotes ruins é o trabalho do nosso componente l4drop, que usa XDP (eXpress Data Path) e aproveita uma versão estendida do Berkeley Packet Filter conhecida como eBPF (BPF estendido). Isso nos permite executar código personalizado no espaço do kernel e processar (soltar, encaminhar ou modificar) cada pacote diretamente no nível da placa de interface de rede (NIC). Esse componente ajuda o sistema a descartar pacotes de maneira eficiente, sem consumir recursos excessivos de CPU na máquina. 

^{Visão geral do sistema de proteção contra DDoS da Cloudflare}

Usamos o XDP para amostrar pacotes e procurar atributos suspeitos que indiquem um ataque. As amostras incluem campos como IP de origem, porta de origem, IP de destino, porta de destino, protocolo, sinalizadores de TCP, número de sequência, opções, taxa de pacotes e muito mais. Essa análise é conduzida pelo daemon de negação de serviço (dosd). O dosd é o segredo do nosso sucesso. Ele tem muitos filtros que o instruem, com base em nossas heurísticas selecionadas, quando inicia a mitigação. Para nossos clientes, esses filtros são agrupados logicamente por vetores de ataque e expostos como regras gerenciadas de DDoS. Nossos clientes podem personalizar seu comportamento até certo ponto, conforme necessário.

À medida que recebe amostras do XDP, o dosd gera várias permutações de impressões digitais para padrões de tráfego suspeitos. Em seguida, usando um algoritmo de streaming de dados, o dosd identifica as impressões digitais ideais para mitigar o ataque. Após o ataque ter sido qualificado, o dosd envia uma regra de mitigação in-line como um programa eBPF para eliminar cirurgicamente o tráfego de ataque.  A detecção e a mitigação de ataques pelo dosd são feitas no nível do servidor, no nível do data center e no nível global, e é tudo definido por software. Isso torna nossa rede extremamente resiliente e leva a uma mitigação quase instantânea. Não há "centros de depuração" ou "dispositivos de depuração" fora do caminho. Em vez disso, cada servidor executa a pilha completa do conjunto de produtos da Cloudflare, incluindo a detecção e o componente de mitigação de DDoS . E tudo é feito de forma autônoma. Cada servidor também transmite (faz multicast de) instruções de mitigação dentro de um data center entre servidores e globalmente entre data centers. Isso garante que, seja um ataque localizado ou distribuído globalmente, o dosd já terá instalado regras de mitigação in-line para garantir uma mitigação robusta.

Nossos sistemas autônomos e definidos por software de detecção e mitigação de DDoS são executados em toda a nossa rede. Neste post, nos concentramos principalmente em nossos recursos dinâmicos de impressões digitais, mas nosso arsenal de sistemas de defesa é muito maior. Os sistemas Advanced TCP Protection e Advanced DNS Protection trabalham em conjunto com nossa impressão digital dinâmica para identificar ataques DDoS sofisticados e altamente randomizados baseados em TCP e também aproveitam análises estatísticas para impedir ataques DDoS complexos baseados em DNS. Nossas defesas também incorporam inteligência contra ameaça em tempo real, perfil de tráfego e classificação de aprendizado de máquina como parte de nossa Proteção Adaptativa contra DDoS para mitigar anomalias de tráfego. 

Juntos, esses sistemas e todo o portfólio de segurança da Cloudflare , são construídos sobre a rede da Cloudflare, uma das maiores redes do mundo, para garantir que nossos clientes estejam protegidos contra os maiores ataques do mundo.