Ataques DDoS: tipos, sintomas e mitigação

17 de fevereiro de 2026 • 8 min read

DDoS não é um fenómeno novo, mas tornou-se muito mais fácil, barato e escalável. No passado, alguns servidores mal configurados ou um botnet pequeno eram suficientes para derrubar um serviço. Hoje vemos ataques que conseguem saturar ligações em frações de segundo, sobrecarregar firewalls ou colocar aplicações de joelhos com pedidos que parecem “normais”.

Este artigo não é para assustar. É para dar contexto: o que é DDoS de facto, que classes de ataque importam na prática, como detetar em produção e que contramedidas valem o esforço.

O que é (D)DoS?

Num ataque de Denial-of-Service (DoS), um atacante tenta tornar um serviço inutilizável não roubando dados, mas sobrecarregando-o ou esgotando os seus recursos. O alvo é a disponibilidade: o teu website deixa de carregar, a tua API entra em timeout, o teu gateway VPN deixa de aceitar sessões ou os teus resolvers DNS não conseguem acompanhar.

O “D” de Distributed significa que o tráfego não vem de uma única fonte, mas de muitas. Pode ser um botnet de dispositivos comprometidos, infraestrutura legítima (reflection/amplification) ou uma mistura. Para ti, enquanto operador, o resultado é o mesmo: não estás a lidar com um atacante único, mas com uma inundação distribuída.

Motivação: porque é que se lançam ataques DDoS?

As motivações costumam ser pouco glamorosas, mas eficazes:

Extorsão: “Paga, ou voltamos a derrubar”.
Ativismo/política: visibilidade, mensagens, disrupção.
Distração: um DDoS pode prender a tua equipa enquanto outra coisa acontece em paralelo.
Concorrência/sabotagem: em momentos críticos (ticketing, releases, lançamentos), mesmo um downtime curto dói.
Pressão de custos: nem todos os ataques visam um outage total; por vezes o objetivo é aumentar custos de cloud, carga de suporte ou stress operacional.

As camadas importantes (e porque importam)

O DDoS é frequentemente descrito por camadas porque a camada diz-te que sinais observar e que defesas são sequer possíveis.

Camada 3 (IP): de onde vem e para onde vai.
Camada 4 (TCP/UDP): portas, conexões, handshakes, estado.
Camada 7 (Aplicação): pedidos HTTP(S), APIs, endpoints de negócio.
“Camada 8” (lógica de negócio): não oficial, mas real: lógica cara na aplicação que pode ser explorada.

A conclusão principal: uma defesa perfeita na camada 3/4 pode falhar na camada 7, porque os pedidos podem parecer legítimos e só se tornam caros quando chegam à aplicação.

Classe de ataque 1: volume e amplificação (frequentemente UDP)

Ataques volumétricos tentam esmagar largura de banda ou processamento de pacotes (pps). Um amplificador clássico é reflection/amplification:

O atacante envia pedidos pequenos para servidores publicamente acessíveis (por exemplo, resolvers DNS abertos).
Faz spoofing do IP de origem e coloca o IP da vítima como “source”.
Esses servidores respondem com respostas muito maiores para a vítima.

Se um pedido de 100 bytes gerar uma resposta de 1 000 bytes, já tens um fator 10. Dependendo do protocolo e do payload, o fator pode ser muito maior. O problema: do ponto de vista da vítima, o tráfego vem de serviços “normais” que não queres bloquear.

Ponto importante: a amplificação depende muitas vezes de spoofing do IP de origem. Por isso, o ingress filtering (BCP 38) é tão importante. Se os fornecedores bloquearem endereços de origem forjados na borda, este vetor torna-se muito mais difícil.

Classe de ataque 2: esgotamento de protocolo e estado (TCP/camada 4)

Nem todo DDoS é sobre máxima largura de banda. Muitas vezes é mais eficiente criar estado no alvo até encher tabelas ou esgotar recursos.

Um exemplo clássico é um SYN flood contra TCP:

Normalmente, o TCP estabelece uma conexão via three-way handshake (SYN -> SYN/ACK -> ACK).
Num SYN flood, o atacante envia enormes quantidades de pacotes SYN, mas o ACK final não chega.
O servidor mantém muitas conexões meio abertas (state) e tenta novamente até aos timeouts.

Isto consome memória e CPU e pode afetar a largura de banda de saída. E mesmo com muita banda: quando o tracking de sessões enche, o “down” está perto.

Uma categoria relacionada são ataques low and slow: o atacante abre conexões reais e mantém-nas abertas com tráfego mínimo até o web server ou o load balancer atingirem limites de conexões. Isto pode ser bem menos visível do que um grande pico de tráfego.

Classe de ataque 3: camada 7 e “camada 8” (HTTP, APIs, endpoints caros)

Ataques de camada 7 são frequentemente os mais irritantes, porque é mais difícil distingui-los de tráfego legítimo. Exemplos:

HTTP floods: muitos pedidos para páginas dinâmicas, endpoints de pesquisa ou fluxos de login.
Slowloris/slow headers: conexões mantidas abertas enviando headers ou bodies muito lentamente.
Lógica de negócio “cara”: endpoints que disparam queries na base de dados, chamadas a APIs externas, geração de PDF, criptografia ou até workflows de AI/agent.

O truque não é necessariamente “mais tráfego”, mas mais trabalho por pedido. Uma pequena quantidade de tráfego bem escolhido pode sair mais cara do que uma grande vaga de GETs estáticos em cache.

Como detetar um DDoS em produção?

Se só olhares para CPU e RAM, vais apanhar alguns ataques tarde demais. Na prática, baselines e algumas métricas robustas ajudam muito:

Tráfego: bps e pps na borda (router, firewall, load balancer).
Métricas de conexão: novas conexões/s, sessões abertas, SYN backlog, TLS handshakes/s.
Métricas HTTP: RPS, latência (p95/p99), ratios 4xx/5xx, timeouts.
Sintomas upstream: perda de pacotes, RTT a subir, ligações saturadas, eventos BGP.
Sinais em logs e WAF: paths invulgares, headers inválidos, muitos pedidos incompletos, user agents/padrões suspeitos.

O mais importante é simples: precisas de uma baseline. Sem baseline, tudo parece “mais ou menos muito”. Com baseline, vês rapidamente que, por exemplo, “pacotes pequenos” ou “pedidos incompletos” fogem muito do normal.

Mitigação: o que funciona mesmo na prática

Existem duas abordagens: make (construir) ou buy (comprar um serviço). Para a maioria das equipas, “buy” é mais realista, porque a mitigação DDoS cresce rapidamente para um problema que não podes gerir como side project.

1) Colocar algo à frente da app: CDN/WAF/provedor anti-DDoS

Para websites e APIs, isto costuma ser a medida mais eficaz:

Anycast distribui tráfego por muitas localizações.
Regras WAF filtram padrões óbvios de camada 7.
Bot management, rate limits e challenge/response reduzem ataques “baratos”.

Importante: nem todo ataque é HTTP. Se expuseres VPN, VoIP, game servers ou outros protocolos baseados em UDP, vais precisar de outras camadas de proteção consoante o setup.

2) Acertar rate limiting e timeouts

Simples, mas eficaz se bem implementado:

ICMP/“ping”: limitar, não proibir totalmente (é útil para troubleshooting).
HTTP: limitar por IP/token/rota, sobretudo para endpoints caros.
Pedidos lentos: timeouts duros para headers/bodies incompletos.

Exemplo (Nginx, muito simplificado) de limites numa rota:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Não é uma solução mágica, mas muda a economia: ataques “baratos” ficam mais difíceis.

3) Arquitetura: desacoplar trabalho caro

Um DDoS de camada 7 muitas vezes não atinge a largura de banda. Atinge as partes onde um único pedido é desproporcionalmente caro. E em setups normais existem muitos: login, pesquisa, exports PDF, relatórios, uploads, queries complexas, chamadas a APIs externas.

Exemplo típico: um portal de clientes tem um botão de exportação (“fatura em PDF”, “gerar relatório”, “descarregar tudo em ZIP”). Em operação normal alguém clica a cada poucos minutos. Num ataque, o endpoint é acionado centenas ou milhares de vezes por minuto. O problema não é a banda; é CPU (rendering), base de dados (queries) e worker pools (threads/conexões). Por fora, parece apenas “o site está lento”. Por dentro, aparecem timeouts, filas e uma base de dados que já não acompanha.

A boa notícia: não precisas de reconstruir tudo. Algumas decisões de arquitetura costumam bastar para separar a parte cara do caminho da requisição e colocar um travão:

Caching (incluindo páginas de erro), TTLs sensatos, edge caching.
Processamento assíncrono (queues) para jobs caros: em vez de “PDF agora”, disparar um job e entregar mais tarde.
Validação rigorosa e abort cedo: limitar complexidade e impor limites por pedido.
Proteção separada para login, pesquisa, upload, export: rate limits e timeouts dedicados e, se necessário, worker pools dedicados.
“Modo degradado” (feature flags): desativar temporariamente funções sem stress de deploy.

4) Opções upstream: filtragem, scrubbing, planos de emergência

Se ficar realmente grande, tens de filtrar o tráfego antes de chegar à tua ligação:

Filtragem do fornecedor / scrubbing center
Regras temporárias (por exemplo: “porque há UDP a chegar ao meu web server?”)
Emergency routing (por exemplo: mudar para um IP “protegido”)

Isto só funciona se tiver sido combinado com o fornecedor com antecedência. Começar “ad hoc” a meio de um incidente é caro e lento.

Checklist pragmática (para equipas sem especialistas em DDoS)

Inventário: que serviços são públicos? HTTP, DNS, VPN, mail, gaming, VoIP?
Single points of failure: provedor DNS, reverse proxy, load balancer, uma única região?
Observabilidade: bps/pps, RPS, latências, erros, conexões, alertas com baseline.
Endurecer defaults: timeouts, limites, tamanho máximo de headers, limites de conexões, backpressure.
Plano com o fornecedor: quem faz scrubbing, quem filtra, caminhos de escalada.
Runbook: “se X acontecer, então Y”, com contactos, limites e switches (feature flags).
Praticar: load tests controlados e drills de incidente (legais e coordenados).

Por fim: testar, mas de forma legal e útil

Testar DDoS é um tema sensível. Qualquer coisa que toque a internet pública, sistemas de terceiros ou infraestrutura sem permissão explícita está fora de limites. O que podes e deves fazer:

Load tests no staging (por exemplo para endpoints caros).
Chaos tests para dependências (cache em baixo, DB lenta, rate limits mais apertados).
Treinar o processo de resposta: alertas, comunicação, escalada ao fornecedor, medidas de emergência.

Fontes e leituras adicionais

Até à próxima, Joe