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 estão protegidos
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 .
Outros ativos da internet podem não ser seguros
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.
Análise da campanha
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.
Anatomia dos ataques DDoS
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 .
Ciclos de CPU exaustivos
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.
Largura de banda de rede exaustiva
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.
Gerar ataques DDoS
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.
Como a Cloudflare protege contra os grandes ataques
Agora que entendemos os fundamentos de como os ataques DDoS funcionam, podemos explicar como a Cloudflare pode proteger contra esses ataques.
Distribuir a superfície de ataque usando anycast global
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.
Anycast vs. Unicast networks
Our anycast network additionally allows Cloudflare to allocate compute and bandwidth resources closest to the regions that need them the most. Densely populated regions will generate larger amounts of legitimate traffic, and the data centers placed in those regions will have more bandwidth and CPU resources to meet those needs. Sparsely populated regions will naturally generate less legitimate traffic, so Cloudflare data centers in those regions can be sized appropriately. Since attack traffic is mainly coming from compromised devices, those devices will tend to be distributed in a manner that matches normal traffic flows sending the attack traffic proportionally to datacenters that can handle it. And similarly, within the datacenter, traffic is distributed across multiple machines.
Additionally, for high bandwidth attacks, Cloudflare’s network has another advantage. A large proportion of traffic on the Cloudflare network does not consume bandwidth in a symmetrical manner. For example, an HTTP request to get a webpage from a site behind Cloudflare will be a relatively small incoming packet, but produce a larger amount of outgoing traffic back to the client. This means that the Cloudflare network tends to egress far more legitimate traffic than we receive. However, the network links and bandwidth allocated are symmetrical, meaning there is an abundance of ingress bandwidth available to receive volumetric attack traffic.
Generating real-time signatures
By the time you’ve reached an individual server inside a datacenter, the bandwidth of the attack has been distributed enough that none of the upstream links are saturated. That doesn’t mean the attack has been fully stopped yet, since we haven’t dropped the bad packets. To do that, we need to sample traffic, qualify an attack, and create rules to block the bad packets.
Sampling traffic and dropping bad packets is the job of our l4drop component, which uses XDP (eXpress Data Path) and leverages an extended version of the Berkeley Packet Filter known as eBPF (extended BPF). This enables us to execute custom code in kernel space and process (drop, forward, or modify) each packet directly at the network interface card (NIC) level. This component helps the system drop packets efficiently without consuming excessive CPU resources on the machine.
Cloudflare DDoS protection system overview
We use XDP to sample packets to look for suspicious attributes that indicate an attack. The samples include fields such as the source IP, source port, destination IP, destination port, protocol, TCP flags, sequence number, options, packet rate and more. This analysis is conducted by the denial of service daemon (dosd). Dosd holds our secret sauce. It has many filters which instruct it, based on our curated heuristics, when to initiate mitigation. To our customers, these filters are logically grouped by attack vectors and exposed as the DDoS Managed Rules. Our customers can customize their behavior to some extent, as needed.
As it receives samples from XDP, dosd will generate multiple permutations of fingerprints for suspicious traffic patterns. Then, using a data streaming algorithm, dosd will identify the most optimal fingerprints to mitigate the attack. Once an attack is qualified, dosd will push a mitigation rule inline as an eBPF program to surgically drop the attack traffic.
The detection and mitigation of attacks by dosd is done at the server level, at the data center level and at the global level — and it’s all software defined. This makes our network extremely resilient and leads to almost instant mitigation. There are no out-of-path “scrubbing centers” or “scrubbing devices”. Instead, each server runs the full stack of the Cloudflare product suite including the DDoS detection and mitigation component. And it is all done autonomously. Each server also gossips (multicasts) mitigation instructions within a data center between servers, and globally between data centers. This ensures that whether an attack is localized or globally distributed, dosd will have already installed mitigation rules inline to ensure a robust mitigation.
Strong defenses against strong attacks
Our software-defined, autonomous DDoS detection and mitigation systems run across our entire network. In this post we focused mainly on our dynamic fingerprinting capabilities, but our arsenal of defense systems is much larger. The Advanced TCP Protection system and Advanced DNS Protection system work alongside our dynamic fingerprinting to identify sophisticated and highly randomized TCP-based DDoS attacks and also leverages statistical analysis to thwart complex DNS-based DDoS attacks. Our defenses also incorporate real-time threat intelligence, traffic profiling, and machine learning classification as part of our Adaptive DDoS Protection to mitigate traffic anomalies.
Together, these systems, alongside the full breadth of the Cloudflare Security portfolio, are built atop of the Cloudflare network — one of the largest networks in the world — to ensure our customers are protected from the largest attacks in the world.