Um ataque de DDoS pode tirar seu site do ar em minutos, mas a maior parte da defesa acontece longe da sua aplicação, na borda da rede. Entenda como a mitigação funciona na prática e o que cabe a você fazer.
O que é um ataque DDoS
DDoS é a sigla em inglês para Distributed Denial of Service, ou negação de serviço distribuída. A ideia é simples e por isso mesmo perigosa: em vez de uma única máquina tentando derrubar um servidor, o atacante coordena milhares ou milhões de dispositivos espalhados pelo mundo para enviar tráfego simultâneo ao mesmo alvo. O objetivo não é invadir o sistema nem roubar dados, e sim esgotar algum recurso finito até que o serviço fique indisponível para os usuários reais.
Esses dispositivos costumam formar uma botnet, uma rede de máquinas comprometidas sem o conhecimento dos donos. Podem ser computadores infectados, roteadores domésticos mal configurados ou aparelhos de Internet das Coisas (IoT, dispositivos conectados como câmeras e gravadores de vídeo) com senhas padrão de fábrica. Como o tráfego vem de muitas origens diferentes e geograficamente dispersas, bloquear um endereço de cada vez é inútil: sempre haverá outros milhares ocupando o lugar.
O recurso esgotado pode ser a banda de rede, a capacidade de processamento do servidor, a tabela de conexões abertas ou até o tempo de CPU gasto montando páginas dinâmicas. Cada tipo de ataque mira um ponto fraco diferente da pilha, e é por isso que a defesa precisa atuar em várias camadas ao mesmo tempo.
Os três tipos principais de ataque
Os ataques volumétricos são os mais conhecidos: eles tentam saturar a banda disponível com um volume bruto de dados, medido em gigabits ou terabits por segundo. Técnicas de amplificação, como o abuso de servidores DNS ou NTP mal configurados, permitem que uma pequena requisição gere uma resposta muito maior direcionada à vítima, multiplicando o poder de fogo do atacante com pouco esforço.
Os ataques de protocolo exploram fragilidades no funcionamento das camadas 3 e 4 do modelo de rede, onde ficam o IP e os protocolos de transporte como o TCP. O exemplo clássico é o SYN flood, que abre um número enorme de conexões pela metade e ocupa a tabela de estados do servidor ou do firewall, deixando-os sem espaço para atender clientes legítimos. Aqui o problema não é o volume de dados, e sim a quantidade de conexões e pacotes por segundo.
Os ataques de aplicação, também chamados de camada 7, são os mais sutis. Em vez de tráfego óbvio, eles enviam requisições que parecem perfeitamente normais, como acessar uma página de busca ou um endpoint de login repetidamente. Cada requisição obriga o servidor a consultar o banco de dados, processar lógica ou montar respostas pesadas, de modo que um volume relativamente baixo de tráfego já consome muito recurso. Por imitarem usuários reais, são os mais difíceis de filtrar sem afetar quem é legítimo.
Por que é difícil separar o joio do trigo
O grande desafio da mitigação é que um pacote de ataque, isoladamente, costuma ser indistinguível de um pacote legítimo. Uma requisição HTTP de uma botnet tem o mesmo formato da requisição de um cliente real prestes a fazer uma compra. Bloquear de forma agressiva demais derruba usuários verdadeiros junto com o ataque, o que é, na prática, atingir o mesmo objetivo do agressor.
Some-se a isso o fato de que picos legítimos de tráfego existem e são desejáveis. Uma promoção relâmpago, uma menção na imprensa ou o lançamento de um produto podem multiplicar os acessos em segundos, de forma muito parecida com o começo de um ataque. Um sistema de defesa que confunda sucesso comercial com agressão é tão prejudicial quanto a própria ameaça.
Por isso a mitigação moderna raramente decide com base em um único pacote. Ela observa padrões agregados ao longo do tempo: distribuição geográfica das origens, comportamento de cada sessão, proporção entre tentativas de conexão e conexões concluídas, características técnicas das requisições e desvios em relação à linha de base normal do site. É a combinação de muitos sinais, e não uma regra única, que permite uma decisão razoável.
Como funciona a mitigação na borda
A defesa eficaz acontece na borda da rede, ou seja, o mais perto possível da origem do ataque e o mais longe possível do seu servidor. A ideia central é absorver e filtrar o tráfego malicioso antes que ele chegue à sua aplicação, que tem capacidade muito menor do que a infraestrutura de uma operadora ou de um datacenter. Quando o lixo é descartado na entrada, o seu servidor sequer percebe a tempestade.
Uma das técnicas fundamentais é o anycast, em que um mesmo endereço IP é anunciado a partir de vários pontos de presença espalhados geograficamente. Com isso, um ataque que viria concentrado em um único local é automaticamente distribuído entre dezenas de localidades, diluindo o volume e aproveitando a capacidade somada de toda a rede. O que seria avassalador para um ponto único torna-se administrável quando repartido.
Quando um ataque é detectado, o tráfego suspeito pode ser desviado para centros de limpeza, num processo chamado scrubbing. Nesses pontos, o tráfego passa por uma série de filtros que descartam pacotes malformados, bloqueiam padrões de amplificação conhecidos, aplicam desafios para validar se há um cliente real do outro lado e impõem rate limiting, ou seja, limites de taxa por origem. O tráfego considerado limpo segue para o servidor; o restante é descartado na borda.
Esse conjunto opera em camadas: as defesas volumétricas e de protocolo agem em alta velocidade nas camadas de rede, enquanto inspeções mais finas tratam dos ataques de aplicação. A mitigação costuma ser elástica e ajustar suas regras conforme o ataque evolui, já que agressores mudam de tática durante a própria ofensiva.
O que o cliente vê
No cenário ideal, o cliente não vê absolutamente nada. A maior prova de uma boa mitigação é a ausência de sintomas: o site continua respondendo, as compras seguem sendo concluídas e ninguém percebe que, naquele exato momento, uma quantidade enorme de tráfego malicioso estava sendo descartada na borda. A defesa silenciosa é a defesa bem-sucedida.
Em ataques muito intensos ou em momentos de ajuste das defesas, pode haver efeitos colaterais leves e temporários, como um pequeno aumento de latência ou, em casos extremos, uma página de verificação que pede a confirmação de que o visitante é humano. Esses são incômodos pontuais e muito preferíveis à alternativa, que é o site simplesmente fora do ar.
Do lado de quem administra o serviço, a visibilidade vem de painéis e alertas que mostram volume de tráfego filtrado, tipo de ataque identificado e duração do evento. Esse registro é valioso para entender o padrão de ameaças do seu negócio e para ajustar as proteções de forma proativa, em vez de apenas reagir.
Limites e boas práticas do lado da aplicação
A mitigação na borda é poderosa, mas não substitui o cuidado com a própria aplicação. Ataques de camada 7 bem-feitos podem imitar usuários legítimos a ponto de uma parcela do tráfego atravessar os filtros, e é aí que a resiliência do seu sistema faz diferença. Quanto mais leve e eficiente for a aplicação, maior a sua margem antes de sentir pressão.
Cache é a primeira linha de defesa do lado da aplicação. Servir conteúdo estático ou pré-renderizado a partir de um cache, idealmente em uma rede de distribuição de conteúdo (CDN), evita que cada requisição chegue ao banco de dados. Um WAF, sigla para Web Application Firewall ou firewall de aplicação web, complementa a borda inspecionando o conteúdo das requisições e bloqueando padrões maliciosos conhecidos antes que cheguem ao código.
Vale também implementar rate limiting na própria aplicação, limitando quantas requisições um mesmo cliente pode fazer a endpoints sensíveis como login, busca e formulários. Some a isso timeouts bem ajustados, filas que degradam o serviço de forma controlada em vez de travar, e a separação de recursos críticos para que um endpoint pesado sob ataque não derrube o restante do site. Defesa em profundidade significa não depender de uma única camada.
Por fim, tenha um plano. Saiba quem acionar, quais painéis observar e como comunicar usuários durante um incidente. A diferença entre uma indisponibilidade longa e um susto de poucos minutos costuma estar na preparação, e não apenas na tecnologia disponível.
Na prática
Mitigar DDoS é um trabalho em camadas: a borda absorve e filtra o volume bruto e os ataques de protocolo usando anycast, scrubbing e rate limiting, enquanto a sua aplicação se protege dos ataques mais sutis de camada 7 com cache, WAF, limites próprios e bom planejamento. Nenhuma camada sozinha resolve tudo, mas juntas elas tornam o seu serviço resiliente.
O ponto mais importante a guardar é que a defesa precisa começar antes do seu servidor. Quando o tráfego malicioso é descartado na entrada da rede, sua infraestrutura sequer sente o impacto, e o cliente continua navegando sem perceber que houve um ataque. Esse é o resultado que se busca.
Na Heffer, a mitigação de DDoS na borda já vem inclusa nos planos de hospedagem, operando de forma transparente para que seu site continue no ar mesmo sob ataque. Combinada com nosso datacenter Tier III em São Paulo, storage 100% NVMe, SLA de 99,9% e suporte 24/7, ela faz parte de uma base pensada para que a disponibilidade do seu negócio não dependa de sorte.