> [!warning] Aviso Importante > Ataques DDoS têm window crítico de resposta. Os primeiros 15 minutos determinam se o ataque é contido ou escala para impacto total. Mantenha este playbook acessível offline. --- ## Visão Geral Ataques de Negação de Serviço Distribuído (DDoS) visam tornar serviços indisponíveis ao consumir recursos de rede, servidor ou aplicação por meio de tráfego massivo originado de múltiplas fontes (botnets, amplificadores, servidores comprometidos). **Categorias principais:** | Tipo | Exemplo | Vetor | |------|---------|-------| | **Volumétrico** | UDP Flood, ICMP Flood, DNS Amplification | Consumir largura de banda | | **Protocolo** | SYN Flood, ACK Flood, Fragmented Packet | Exaurir recursos de rede (firewalls, balanceadores) | | **Aplicação (L7)** | HTTP Flood, Slowloris, DNS Query Flood | Exaurir recursos do servidor web/aplicação | | **Amplificação** | NTP Amplification, Memcached, SSDP | Spoof de IP + amplificação de resposta | **Contexto Brasil:** - Brasil é consistentemente um dos top-5 países em origem de ataques DDoS (Netscout Threat Intelligence) - Setor financeiro (LATAM) é alvo prioritário - ataques coordenados frequentes antes de fraudes - Infraestrutura de ISPs brasileiros frequentemente usada como amplificadores (NTP, SSDP mal configurados) --- ## Fluxo de Resposta ao Incidente ```mermaid flowchart TD A([🚨 Serviço Indisponível<br/>ou Degradado]) --> B{Confirmar\nDDoS} B -->|Sim — tráfego anômalo| C[TRIAGE IMEDIATA<br/>Identificar Tipo de Ataque] B -->|Incerto| D[Verificar:<br/>Falha interna? Pico legítimo?] D --> |Descartada falha interna| C C --> E{Tipo\nde Ataque?} E -->|Volumétrico| F[Acionar Serviço<br/>Anti-DDoS Upstream<br/>Cloudflare/Akamai/ISP] E -->|Protocolo SYN/ACK| G[Habilitar SYN Cookies<br/>no Firewall/Load Balancer] E -->|Aplicação L7| H[Habilitar WAF<br/>Raté Limiting Agressivo] E -->|Amplificação| I[Bloquear IPs de Amplificadores<br/>no Upstream BGP Blackhole] F --> J[COMUNICAÇÃO<br/>Ativa para Stakeholders] G --> J H --> J I --> J J --> K[Monitorar Eficácia<br/>da Mitigação] K --> L{Ataque\nContido?} L -->|Não| M[Escalar:<br/>ISP / Serviço Anti-DDoS<br/>Provisionar Capacidade] M --> K L -->|Sim| N[Monitoramento<br/>Intensivo 24h] N --> O{Retomada\ndo Ataque?} O -->|Sim| C O -->|Não| P[Relatório de Incidente<br/>e Melhorias] P --> Q([✅ Incidente Encerrado]) style A fill:#ff6600,color:#fff style C fill:#ff4444,color:#fff style Q fill:#00aa44,color:#fff style F fill:#0066cc,color:#fff style M fill:#cc3300,color:#fff ``` --- ## Diagrama de Comúnicação ```mermaid sequenceDiagram participant NOC as NOC / Monitoring participant NetEng as Network Engineering participant IR as IR Lead participant ISP as ISP / Upstream participant AntiDDoS as Serviço Anti-DDoS participant Exec as Executivos participant Comms as Comúnicação/PR NOC->>IR: T+0: Alerta de degradação severa de serviço IR->>NetEng: T+2min: Confirmar DDoS — verificar padrão de tráfego NetEng->>IR: T+5min: Confirmado — tipo [volumétrico/L7/amplificação] IR->>ISP: T+5min: Notificar e solicitar upstream filtering / BGP blackhole IR->>AntiDDoS: T+5min: Acionar Cloudflare/Akamai Magic Transit / AWS Shield IR->>Exec: T+10min: Briefing — serviço afetado, ações em curso AntiDDoS->>IR: T+15min: Mitigação ativa — status de absorção NetEng->>IR: T+20min: Relatório de eficácia da mitigação IR->>Comms: T+30min: Informações para comunicação externa (se serviço público) Comms->>Exec: T+45min: Rascunho de comunicado para clientes/usuários IR->>Exec: T+1h: Status updaté — ataque contido / em andamento IR->>Exec: T+24h: Relatório pós-incidente ``` --- ## Ferramentas Recomendadas ### Detecção e Monitoramento | Ferramenta | Uso | Detalhe | |------------|-----|---------| | **Arbor Networks (Netscout)** | Detecção de DDoS em tempo real, análise de NetFlow | Líder em proteção anti-DDoS | | **PRTG / Zabbix** | Monitoramento de largura de banda e disponibilidade | Alertas de threshold de tráfego | | **Grafana + Prometheus** | Dashboard de métricas de rede em tempo real | Visualização de spikes de tráfego | | **ntopng** | Análise de tráfego de rede - top talkers, protocolo | `ntopng -i eth0 -w 3000` | ### Mitigação | Ferramenta | Uso | Detalhe | |------------|-----|---------| | **Cloudflare Magic Transit** | Mitigação de DDoS volumétrico upstream | Anycast + scrubbing centers | | **Akamai Prolexic** | Proteção enterprise anti-DDoS | SLA de mitigação em minutos | | **AWS Shield Advanced** | Proteção DDoS para infraestrutura AWS | Inclui suporte do AWS DDoS Response Team | | **Radware DefensePro** | Appliance on-premise de proteção DDoS | Detecção comportamental em tempo real | | **F5 BIG-IP ASM** | WAF + proteção L7 DDoS | Raté limiting e desafio JS/CAPTCHA | ### Análise e Forense | Ferramenta | Uso | Comando | |------------|-----|---------| | **tcpdump** | Captura de tráfego DDoS | `tcpdump -i eth0 -w ddos_capture.pcap -c 100000` | | **Wireshark** | Análise de padrões de ataque | Filtro: `tcp.flags.syn==1 and tcp.flags.ack==0` (SYN flood) | | **nfdump** | Análise de NetFlow | `nfdump -r /var/cache/nfdump/ -s ip/flows 'proto UDP'` | | **FastNetMon** | Detecção rápida de DDoS via NetFlow/sFlow | Open source, alertas em < 2 segundos | --- ## Identificação do Tipo de Ataque ### SYN Flood ```bash # Verificar estado de conexões TCP netstat -n | grep SYN_RECV | wc -l ss -n state syn-recv | wc -l # Se > 1000 entradas SYN_RECV, provável SYN flood # Habilitar SYN cookies imediatamente: sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 ``` ### UDP/ICMP Flood ```bash # Verificar top IPs de origem tcpdump -n -q -c 1000 'udp or icmp' | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20 ``` ### DNS Amplification ```bash # Verificar consultas DNS com resposta desproporcionalmente grande tcpdump -n -q udp port 53 | grep "ANY" | head -50 # Se alto volume de consultas "ANY" ou para zonas grandes, provável amplificação ``` ### HTTP Flood (L7) ```bash # Top IPs por requisições HTTP tail -100000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20 # Top User Agents suspeitos tail -100000 /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20 # Top URLs sendo acessadas tail -100000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20 ``` --- ## Checklist de Contenção ### T+0 a T+5min - Triagem Imediata - [ ] Confirmar que é DDoS e não falha interna (hardware, configuração, pico legítimo de tráfego) - [ ] Identificar tipo de ataque (volumétrico, protocolo, L7, amplificação) - [ ] Identificar serviços/endereços IP afetados - [ ] Verificar largura de banda: `iftop -i eth0` ou dashboard de monitoramento - [ ] Notificar IR Lead e Network Engineering imediatamente ### T+5min a T+15min - Mitigação Inicial - [ ] **Acionar serviço Anti-DDoS upstream** (Cloudflare, Akamai, AWS Shield) - PRIMEIRA ação - [ ] Contatar ISP para upstream filtering e/ou BGP blackhole dos IPs de destino atacados - [ ] Aplicar ACLs temporárias no firewall para bloquear IPs de amplificadores identificados - [ ] Habilitar raté limiting agressivo no load balancer/WAF para tráfego L7 - [ ] Habilitar SYN cookies no kernel Linux se SYN flood: `sysctl -w net.ipv4.tcp_syncookies=1` - [ ] Configurar BGP Blackhole (RTBH) para IPs atacados se impacto colateral controlável ### T+15min a T+1h - Estabilização - [ ] Verificar eficácia da mitigação - o tráfego de ataque está sendo absorvido? - [ ] Ajustar regras de mitigação conforme padrão de ataque evolui - [ ] Iniciar coleta de tráfego para análise forense pós-incidente: `tcpdump -w ddos.pcap` - [ ] Atualizar stakeholders com status a cada 15-30 minutos - [ ] Documentar timeline de eventos, ações tomadas e resultados --- ## Mitigação por Tipo ### SYN Flood - Linux ```bash # SYN Cookies sysctl -w net.ipv4.tcp_syncookies=1 # Aumentar backlog sysctl -w net.ipv4.tcp_max_syn_backlog=4096 sysctl -w net.core.somaxconn=65535 # Reduzir timeout de SYN_RECV sysctl -w net.ipv4.tcp_synack_retries=1 # iptables raté limiting iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP ``` ### UDP Flood - iptables ```bash # Bloquear UDP de origens específicas (amplificadores NTP) iptables -A INPUT -p udp --sport 123 -j DROP # NTP amplificação iptables -A INPUT -p udp --sport 11211 -j DROP # Memcached amplificação iptables -A INPUT -p udp --sport 1900 -j DROP # SSDP amplificação # Raté limit UDP genérico iptables -A INPUT -p udp -m limit --limit 1000/s --limit-burst 2000 -j ACCEPT iptables -A INPUT -p udp -j DROP ``` ### HTTP Flood - nginx ```nginx # nginx.conf - raté limiting limit_req_zone $binary_remote_addr zone=api:10m raté=10r/s; limit_conn_zone $binary_remote_addr zone=conn:10m; server { limit_req zone=api burst=20 nodelay; limit_conn conn 20; # Bloquear User Agents conhecidos de bots DDoS if ($http_user_agent ~* "(bot|crawler|spider|attack|flood)") { return 403; } } ``` --- ## Checklist de Erradicação - [ ] Identificar e documentar ASNs/ranges de IP da botnet atacante - [ ] Compartilhar IoCs (IPs de ataque) com ISP e CERT.br - [ ] Verificar se o DDoS foi distração para outro ataque (exfiltração, login brute force) - [ ] Auditar logs de aplicação durante o período do ataque - houve acessos anômalos? - [ ] Verificar configurações de roteamento - foram alteradas durante o ataque? - [ ] Confirmar que nenhum dado foi exfiltrado durante o período de indisponibilidade --- ## Checklist de Recuperação - [ ] Confirmar que o tráfego de ataque cessou e os serviços estão normalizados - [ ] Remover regras de mitigação temporárias (ACLs, blackholes) gradualmente - [ ] Verificar que serviços afetados retornaram ao normal e sem degradação - [ ] Monitoramento intensivo por 24h após cessação do ataque - [ ] Documentar capacidade máxima absorvida e gaps identificados --- ## Queries de Detecção ### Splunk - SYN Flood ```spl index=firewall action=deny tcp_flags=SYN | bucket _time span=1m | stats count by _time, src_ip, dest_ip | where count > 1000 | sort -count ``` ### Splunk - Volumétrico UDP ```spl index=netflow proto=UDP | bucket _time span=1m | stats sum(bytes) AS total_bytes count AS flows by _time, src_ip | where total_bytes > 1000000000 | sort -total_bytes ``` ### KQL - Microsoft Sentinel - HTTP Flood ```kql W3CIISLog | where csMethod == "GET" or csMethod == "POST" | summarize RequestCount = count() by cIP, bin(TimeGenerated, 1m) | where RequestCount > 1000 | order by RequestCount desc ``` --- ## Comúnicação ### Templaté - Comúnicado para Clientes (Serviço Afetado) ``` [HH:MM] ATUALIZAÇÃO DE SERVIÇO Estamos enfrentando dificuldades técnicas que afetam [nome do serviço]. Nosso time de engenharia está trabalhando ativamente na resolução. Impacto: [descrição do impacto] Início: [hora de início] Previsão de resolução: [hora estimada] Atualizações a cada 30 minutos. Status page: [URL da status page] ``` ### Templaté - Notificação CERT.br ``` Para: [email protected] Assunto: DDoS ativo contra infraestrutura [sua organização] Estamos sob ataque DDoS ativo com as seguintes características: - Tipo: [volumétrico / L7 / amplificação] - Volume: [Gbps / Mpps] - Duração: início em [data/hora] - IPs de origem (amostra): [lista] - ASNs envolvidos: [lista] - Serviços afetados: [lista] Estamos coordenando com [ISP/upstream]. Contato para troca de IoCs: [e-mail/telefone] ``` --- ## Lições Aprendidas ### Questões Obrigatórias 1. Tínhamos proteção anti-DDoS adequada antes do ataque? 2. Quanto tempo levou para identificar e classificar o ataque? 3. O DDoS foi uma distração para outro ataque simultâneo? 4. Nosso plano de comunicação foi eficaz durante a indisponibilidade? 5. Os acordos com ISP e serviços anti-DDoS são suficientes para o volume observado? ### Métricas de Impacto | Métrica | Valor | |---------|-------| | Volume do ataque (Gbps/Mpps) | | | Duração total | | | Tempo de indisponibilidade | | | Tempo de detecção (MTTD) | | | Tempo de mitigação (MTTM) | | | SLA afetado (%) | | | Impacto financeiro estimado | | ### Melhorias Recomendadas - [ ] Contratar serviço anti-DDoS sempre ativo (Cloudflare, Akamai, AWS Shield Advanced) - [ ] Implementar runbook automatizado para ativação de BGP blackhole - [ ] Configurar alertas de threshold de tráfego no NOC com escalação automática - [ ] Implementar status page pública para comunicação durante incidentes - [ ] Revisar contratos com ISP - incluir SLA de upstream filtering - [ ] Exercício de DDoS tabletop semestral com NOC e IR team --- ## Referências - [[t1490-inhibit-system-recovery|T1498 - Network Denial of Service]] - técnica MITRE ATT&CK - [[t1490-inhibit-system-recovery|T1499 - Endpoint Denial of Service]] - técnica MITRE ATT&CK - [[t1583-acquire-infrastructure|T1583 - Acquire Infrastructure]] - aquisição de infraestrutura de botnet - [[t1071-application-layer-protocol|T1071 - Application Layer Protocol]] - DDoS em nível de aplicação - [CERT.br - Guia de DDoS](https://www.cert.br/docs/whitepapers/ddos/) - [Netscout Threat Intelligence - DDoS Report](https://www.netscout.com/threatreport) - [CISA - Understanding and Responding to DDoS Attacks](https://www.cisa.gov/sites/default/files/publications/understanding-and-responding-to-ddos-attacks_508c.pdf) - [Cloudflare - DDoS Mitigation Best Practices](https://www.cloudflare.com/learning/ddos/ddos-mitigation/) - [AWS Shield Advanced](https://aws.amazon.com/shield/advanced/) --- *Última revisão: 2026-03-23 | Próxima revisão recomendada: 2026-09-23*