Ataques DoS e DDoS: Técnicas, Ferramentas e Estratégias de Defesa

Ataques DoS e DDoS: Técnicas, Ferramentas e Estratégias de Defesa

Nenhuma outra classe de ataque traduz tão diretamente em impacto financeiro mensurável quanto o Denial of Service. Enquanto técnicas de exploração e exfiltração roubam dados silenciosamente, um ataque DoS derruba a porta da frente — clientes não acessam, receita para, SLAs quebram e a reputação despenca. No contexto do CEH v13, entender como esses ataques funcionam é essencial tanto para a fase de reconhecimento de vulnerabilidades quanto para a de relatório e remediação. Este artigo cobre o espectro completo: dos floods mais primitivos às campanhas DDoS sofisticadas orquestradas por botnets, passando pelas ferramentas que um ethical hacker usa em laboratório e pelas contra-medidas que todo profissional de segurança precisa dominar.

1. O Que São Ataques DoS e DDoS

Definição e Objetivo

Um ataque Denial of Service (DoS) tem um único objetivo: tornar um serviço, recurso ou rede indisponível para seus usuários legítimos. Diferente de ataques de injeção ou elevação de privilégio, o DoS não visa roubar dados — visa o tempo de inatividade.

A mecânica é simples: sobrecarregar um recurso até que ele não consiga mais atender requisições normais. Isso pode ser feito esgotando largura de banda, consumindo CPU/memória do servidor, preenchendo tabelas de estado, ou explorando bugs em implementações de protocolo.

DoS vs. DDoS

• DoS (Denial of Service): um único source ataca o alvo. Escalável apenas até os recursos do atacante.
• DDoS (Distributed Denial of Service): múltiplos sources — geralmente uma botnet — coordenam o ataque. Volume distribuído, muito mais difícil de mitigar porque bloquear um IP não resolve.

Impacto Financeiro

Segundo relatórios da ENISA e da Cloudflare, o custo médio de um ataque DDoS para empresas de médio porte gira em torno de USD 120.000 por hora de indisponibilidade. Setores como e-commerce, gaming, financeiro e saúde são os mais visados. O custo inclui perda de receita direta, SLAs penalizados, custo de mitigação de emergência e danos à marca.

2. Ataques Volumétricos

Ataques volumétricos são a categoria mais direta: o objetivo é esgotar a largura de banda ou a capacidade de processamento do alvo com um volume massivo de tráfego. Se o link do datacenter é de 10 Gbps e o atacante consegue injetar 100 Gbps, o alvo fica inacessível.

SYN Flood

O SYN flood explora o mecanismo de three-way handshake do TCP. O processo normal é:

1. Cliente envia SYN
2. Servidor responde SYN-ACK e aloca recursos para a conexão
3. Cliente envia ACK → conexão estabelecida

No SYN flood, o atacante envia milhares de pacotes SYN com IPs de origem forjados (spoofed). O servidor aloca recursos para cada half-open connection e envia o SYN-ACK, mas a resposta nunca volta. A tabela de conexões semi-abertas (backlog queue) enche, e novas conexões legítimas são descartadas.

UDP Flood

O protocolo UDP é connectionless — sem handshake, sem garantia de entrega. O atacante envia pacotes UDP massivos para portas aleatórias do alvo. O servidor processa cada pacote, verifica se há um serviço escutando naquela porta e, quando não há, gera um ICMP Destination Unreachable. O custo de processamento para lidar com esse tráfego inútil pode derrubar o servidor.

ICMP Flood

Flood de pacotes ICMP (ping). O atacante envia uma quantidade massiva de requisições Echo Request. Cada uma exige processamento e resposta, consumindo largura de banda e CPU. Em ambientes com rate limiting desabilitado em ICMP, é surpreendentemente eficaz.

Amplification e Reflection Attacks

Este é o tipo de ataque volumétrico mais devastador na era moderna. A mecânica:

1. Spoofing: o atacante forja o IP de origem dos pacotes para o IP do alvo
2. Amplificação: envia pequenas requisições para serviços vulneráveis (DNS, NTP, memcached, SSDP) que respondem com payloads muito maiores
3. Reflexão: as respostas (agora massivas) são enviadas para o IP spoofed — o alvo

Um atacante com 1 Gbps de upload pode gerar 100+ Gbps contra o alvo, dependendo do fator de amplificação do serviço explorado.

  Atacante (1 Gbps)
       │
       │  Requisição pequena com IP spoofed do Alvo
       ▼
  ┌─────────────┐
  │  Serviços   │  DNS (28-54x) │ NTP (556x) │ Memcached (51.000x)
  │  Vulneráveis │  SSDP (30x)   │ SNMP (6.3x) │ DNSSEC (44-100x)
  └──────┬──────┘
         │
         │  Resposta amplificada → IP spoofed = Alvo
         ▼
  ┌─────────────┐
  │    ALVO     │  Recebe 50-100+ Gbps sem ter feito nada
  │  (derrubado)│
  └─────────────┘

A ferramenta Shodan pode ser usada para descobrir serviços abertos e vulneráveis a amplification com queries como port:11211 memcached, port:1900 SSDP ou "ntp" port:123. Em um lab controlado, isso demonstra a escala do problema — nunca contra alvos sem autorização.

3. Ataques de Protocolo

Enquanto ataques volumétricos sobrecarregam largura de banda, ataques de protocolo exploram vulnerabilidades na implementação dos protocolos de rede, consumindo recursos do servidor (CPU, memória, tabelas de estado) de forma mais eficiente que um flood bruto.

Smurf Attack

O atacante envia pacotes ICMP Echo Request para o endereço de broadcast de uma rede, com o IP de origem forjado para o do alvo. Todos os hosts da rede respondem ao Echo Request com um Echo Reply para o alvo. A rede inteira vira amplificador. Praticamente extinto em redes modernas com no ip directed-broadcast configurado em roteadores.

Fraggle Attack

Variante do Smurf que usa UDP em vez de ICMP. O atacante envia pacotes UDP para a porta 7 (Echo) de redes com broadcast habilitado. Mesma mecânica, mesmo efeito devastador quando encontrado.

Ping of Death

Explora um bug histórico em implementações TCP/IP: pacotes ICMP Echo maiores que o máximo permitido (65.535 bytes para IPv4). Fragmentação maliciosa fazia o kernel reconstruir o pacote com tamanho excedente, causando buffer overflow e crash. Corrigido na década de 1990 em todos os sistemas modernos — agora é mais conceito histórico que ameaça real.

Teardrop

O atacante envia fragmentos IP com campos de offset sobrepostos. Quando o sistema alvo tenta remontar o pacote, a lógica de fragmentação entra em conflito — offsets que se sobrepõem causam crash (kernel panic). Variantes Bonk e Boink modificam campos adicionais para contornar patches específicos. Como o Ping of Death, hoje é principalmente um tópico de estudo.

4. Ataques de Camada de Aplicação

Ataques de camada 7 (OSI) são os mais insidiosos. Diferente de floods de rede, que são identificados por volume anômalo, ataques de aplicação geram tráfego que parece legítimo — requisições HTTP válidas, formulários completos, sessões autenticadas. Detectar a diferença entre um pico de tráfego real e um ataque exige análise profunda de padrões.

Slowloris

Ferramenta clássica. O atacante abre múltiplas conexões HTTP com o servidor e envia headers parciais periodicamente — o suficiente para manter a conexão aberta, mas sem completá-la. O servidor mantém cada conexão em estado de espera, consumindo um slot no seu pool de worker threads. Com poucas centenas de conexões Slowloris, um servidor Apache com configuração padrão fica inacessível. A requisição nunca “termina”, então o timeout do servidor nunca dispara.

Slow POST (R-U-Dead-Yet)

Variante do conceito: o atacante envia um POST HTTP com um cabeçalho Content-Length enorme (digamos, 4 GB) e um corpo que transmite lentamente — alguns bytes por segundo. O servidor aloca recursos esperando o corpo completo, que nunca chega em tempo útil. Enquanto isso, o pool de conexões se esgota.

HTTP Flood

O mais “simples” dos ataques de aplicação: requisições GET ou POST volumosas contra URLs específicas. Pode ser tão rudimentar quanto acessar a homepage repetidamente, ou tão sofisticado quanto mirar em endpoints pesados (buscas complexas, relatórios, uploads). A sofisticação moderna inclui variações de User-Agent, cookies de sessão, e sequências de navegação que imitam um usuário real.

R.U.D.Y. (R U Dead Yet?)

Ferramenta que automatiza o Slow POST com interface gráfica. Permite ao atacante configurar o target, definir a taxa de envio de dados e monitorar o progresso. Envia requisições HTTP POST com corpo partido em pequenos pacotes enviados em intervalos longos. O servidor mantém a conexão aberta esperando dados que chegam a conta-gotas.

5. Botnets e Command & Control

Um ataque DDoS eficaz precisa de volume distribuído. A fonte desse volume é a botnet.

O Que É uma Botnet

Uma botnet é uma rede de máquinas comprometidas (bots ou zombies) sob o controle de um atacante (botmaster). As máquinas podem ser desktops, servidores, dispositivos IoT — qualquer coisa com conectividade e processamento. Uma botnet moderna pode ter dezenas de milhares a milhões de nós.

Infecção

• Malware tradicional: emails com anexos maliciosos, downloads de software pirata, drive-by downloads via exploits em navegadores
• IoT: dispositivos com credenciais padrão (admin/admin), firmware desatualizado, interfaces de gerenciamento expostas na internet
• Phishing: engenharia social para instalar o bot client
• Exploitation: vulnerabilidades públicas sem patch (a maioria dos botnets IoT funciona assim)

Comunicação C2 (Command and Control)

O botmaster precisa comunicar comandos aos bots. Os protocolos de C2 evoluíram para evadir detecção:

BaaS — Botnet as a Service

Modelo de negócio criminal: botnets são oferecidas como serviço em marketplaces na dark web. O cliente aluga capacidade DDoS por preço e duração — USD 10 para um ataque de 1 hora, USD 200 para campanhas prolongadas. Interfaces web, APIs, suporte ao cliente. A democratização do DDoS.

Caso de Estudo: Mirai

Em 2016, a botnet Mirai varreu a internet. Funcionamento:

• Escaneava a internet por dispositivos IoT com telnet exposto
• Tentava credenciais padrão de uma lista de 60+ combinações comuns
• Comprometia câmeras, roteadores, DVRs — dispositivos fracos em número absurdo
• Infectou mais de 600.000 dispositivos
• Foi usada no ataque à DYN DNS que derrubou Twitter, Reddit, Netflix, GitHub, e dezenas de outros sites por horas

O código-fonte do Mirai foi divulgado publicamente após a prisão de seus criadores. Desde então, variantes proliferaram (Mozi, Echobot, Hajime), usando a mesma estratégia: IoT mal configurado + credenciais fracas = exército de bots.

6. Ferramentas (Uso Exclusivo em Laboratório)

7. Técnicas de Mitigação

Não existe solução única para DDoS — a defesa é em camadas, adaptada ao tipo e escala do ataque.

Rate Limiting

Limitar o número de requisições por IP, por sessão ou por endpoint em um determinado período. Eficaz contra floods simples e bots rudimentares. Limitações: não escala para ataques volumétricos massivos e pode bloquear usuários legítimos se mal configurado.

WAF — Web Application Firewall

Inspeciona e filtra tráfego HTTP/HTTPS. Protege contra ataques de camada 7 (Slowloris, HTTP flood, R.U.D.Y.) analisando padrões de request, assinaturas de ataque e anomalies. Soluções: ModSecurity (open source), Cloudflare WAF, AWS WAF, Imperva.

CDN — Content Delivery Network

CDNs como Cloudflare, Akamai e Fastly operam redes globais com capacidade agregada de dezenas de Tbps. O tráfego passa pelos POPs (Points of Presence) do CDN antes de chegar ao servidor de origem. Em um ataque volumétrico, o CDN absorve o tráfego malicioso — o servidor de origem nem vê o ataque.

Anycast

Endereços Anycast permitem que o mesmo IP seja anunciado de múltiplos POPs ao redor do mundo. Tráfego é roteado automaticamente para o POP mais próximo. Em um ataque DDoS, o tráfego de ataque se distribui entre todos os POPs, diluindo o impacto em qualquer ponto único. É a base da arquitetura anti-DDoS da Cloudflare e Cloudflare.

Blackholing e Sinkholing

• Blackholing (Null routing): o ISP ou datacenter anuncia a rota do alvo para o blackhole. Todo o tráfego é descartado. O alvo fica “fora do ar” tanto para atacantes quanto para usuários legítimos. Extremo, mas evita que o ataque afete outros clientes do mesmo ISP.
• Sinkholing: tráfego malicioso é redirecionado para um servidor controlado (sinkhole) que analisa e descarta as conexões. Permite coleta de inteligência sobre a fonte do ataque.

Filtragem em Nível de ISP

Para ataques volumétricos massivos, a filtragem precisa acontecer antes de chegar ao link do datacenter. ISPs podem implementar ACLs, rate limiting e blackholing. O BCP38 (RFC 2827) — Ingress Filtering — requer que ISPs bloqueiem tráfego de saída com IPs spoofed. Se universalmente implementado, eliminaria a maioria dos ataques de reflexão/amplificação.

SYN Cookies

Como mencionado na seção de SYN flood, o servidor elimina o estado por conexão half-open codificando informações no ISN (Initial Sequence Number) do SYN-ACK. O custo computacional é mínimo e a proteção é robusta. Habilitado por padrão em kernels Linux modernos.

8. Detecção e Resposta

Detecção por Anomalia

A detecção eficaz de DDoS começa com baselines — entender o tráfego normal do serviço. Ferramentas de monitoramento (NetFlow, sFlow, SNMP, Prometheus) estabelecem o comportamento esperado. Quando o tráfego diverge significativamente do baseline — seja em volume, tipo de pacotes, geografia de origem, ou padrões de requisição — um alerta dispara.

Análise de Tráfego

• NetFlow/sFlow: amostragem de tráfego de rede que permite identificar padrões de flood, portas de destino incomuns, e fontes de tráfego anômalo
• PCAP analysis: captura e análise granular de pacotes com tcpdump, Wireshark
• Log analysis: access logs do web server, logs de firewall, logs de CDN

Correlação em SIEM

Plataformas SIEM (Splunk, Elastic SIEM, QRadar) correlacionam eventos de múltiplas fontes: firewall, WAF, CDN, IDS/IPS, server logs. Um ataque DDoS de camada 7, por exemplo, pode gerar um aumento em requests/segundo (CDN logs) + erros 503 (web server) + queda nas métricas de uptime (monitoring) — a correlação automática desses sinais acelera a detecção.

Incident Response para DDoS

Um playbook de resposta a DDoS deve cobrir:

1. Detect: alertas de monitoramento confirmam tráfego anômalo. Classificar: volumétrico? protocolo? aplicação?
2. Analyze: identificar tipo de ataque, fontes, escala. Envolvam CDN/ISP se necessário.
3. Mitigate: ativar rate limiting, WAF rules, CDN protection mode, blackhole como último recurso.
4. Communicate: notificar stakeholders — equipe de infra, gerência, clientes afetados, provedores.
5. Post-incident: documentar o ataque, métricas (duração, pico de tráfego), resposta tomada, eficácia, lições aprendidas. Atualizar o playbook.

9. Casos Reais

DYN DNS — outubro 2016

A botnet Mirai atacou os servidores DNS da DYN, provedor de DNS para sites como Twitter, Reddit, Netflix, Spotify, GitHub e PayPal. O ataque durou o dia inteiro, com dois picos principais. Os sites ficaram inacessíveis para grande parte da costa leste dos EUA. Impacto: estimativas de USD 110 milhões em perdas coletivas.

GitHub — fevereiro 2018

Ataque de Memcached amplification que atingiu 1.35 Tbps — o maior ataque registrado até então. O fator de ampliação do Memcached (até 51.000x) permitiu que poucos servidores vulneráveis gerassem volume absurdo. GitHub ficou offline por ~10 minutos, mas a mitigação via Akamai Prolexic redirecionou o tráfego rapidamente. Sem o CDN, o resultado seria catastrófico.

AWS Shield — junho 2020

AWS revelou ter mitigado um ataque de 2.3 Tbps contra um cliente não identificado. O ataque usou CLDAP reflection (Connectionless Lightweight Directory Access Protocol) com fator de ampliação de 56-70x. Duração: ~3 dias de tráfego sustentado. A AWS absorveu o ataque sem impacto no cliente.

Estonia — abril-maio 2007

Um dos primeiros ataques DDoS de grande escala com motivação política/estatal. Após a remoção de uma estátua soviética em Tallinn, sites do governo, bancos, mídia e telecomunicações da Estônia foram alvo de ataques DDoS coordenados. Paralisou o país digital por semanas. A Estônia tornou-se pioneira em ciberdefesa após o incidente, sediando o NATO Cooperative Cyber Defence Centre of Excellence.

10. Contra-medidas Checklist

Preparação

• ✅ Contratar CDN com proteção DDoS nativa (Cloudflare, Akamai, AWS Shield)
• ✅ Implementar rate limiting em todas as camadas (CDN, WAF, load balancer, aplicação)
• ✅ Configurar WAF com rules para ataques de camada 7
• ✅ Habilitar SYN cookies no kernel
• ✅ Implementar monitoring com baselines e alertas
• ✅ Desenvolver e testar playbook de incident response para DDoS
• ✅ Garantir que o ISP suporte BCP38 (ingress filtering)
• ✅ Contratar serviço DDoS protection dedicated se o negócio é crítico

Resposta

• ✅ Classificar o tipo de ataque (volumétrico, protocolo, aplicação)
• ✅ Ativar modo “under attack” no CDN
• ✅ Aumentar rate limiting se o ataque é de aplicação
• ✅ Contatar o ISP para filtragem upstream se necessário
• ✅ Blackhole como último recurso (salvar outros serviços)
• ✅ Comunicar stakeholders

Prevenção

• ✅ Security hardening: fechar serviços desnecessários, desabilitar respostas a broadcast
• ✅ Patch management: manter sistemas atualizados
• ✅ Desabilitar UPnP/SSDP se não necessário
• ✅ Configurar firewalls para blocar tráfego ICMP/UDP de entrada desnecessário
• ✅ Implementar IP reputation e geo-blocking quando aplicável

11. Tabela Resumo: Tipos de Ataque