O que é ataque DDoS: causa e defesa da indisponibilidade

ataque DDoS é um ataque distribuído de negação de serviço no qual muitos equipamentos enviam tráfego ou requisições ao mesmo alvo ao mesmo tempo, com o objetivo de exaurir banda, processamento ou conexões e deixar o serviço indisponível para usuários legítimos, sem que o intuito principal seja invadir o sistema ou roubar dados.

Você abre o painel e o site responde com atraso, o checkout trava e o suporte começa a receber reclamações de timeout. Em muitos casos o problema não é um bug de código nem uma falha simples de capacidade, e sim um pico de tráfego hostil que o servidor e o enlace não conseguem separar do uso normal. Quem opera loja, API ou portal institucional precisa entender o mecanismo para não confundir sobrecarga legítima com sabotagem.

Este verbete explica o que acontece na rede, quais famílias de ataque aparecem com mais frequência e quais decisões de defesa costumam reduzir dano. Além disso, deixa claro o limite do que dá para controlar sozinho, porque parte da mitigação depende do provedor, da CDN e da capacidade de filtragem fora do seu data center.

Como um ataque DDoS funciona na prática?#

Ele funciona ao consumir um recurso finito do alvo até o serviço deixar de atender quem deveria ser atendido. Segundo as recomendações do CERT.br sobre DDoS, a negação de serviço usa equipamentos na rede para tirar de operação um serviço, um computador ou uma rede, e na forma distribuída esse esforço vem de um conjunto coordenado de fontes. O glossário da MDN sobre DDoS descreve o mesmo núcleo, ou seja, vários sistemas comprometidos ou controlados atacando um único alvo para saturar recursos e bloquear usuários legítimos.

Na prática o atacante não precisa “entrar” no sistema para atingir o objetivo. O CERT.br destaca que o intuito direto não é invadir nem coletar informações, e sim exaurir recursos e causar indisponibilidade. Por isso o firewall e o balanceador podem continuar “saudáveis” no sentido de estarem ligados, porém sem capacidade livre para aceitar sessões novas. Enquanto isso, o time de produto vê apenas lentidão e erros 5xx, e o time de rede vê saturação de banda, de pacotes por segundo ou de tabela de conexões.

Há caminhos conceituais recorrentes descritos pelo próprio CERT.br. Um deles usa botnets formadas por equipamentos infectados, mal configurados ou invadidos, de computadores pessoais a câmeras e roteadores. Outro abusa de serviços da Internet, como DNS, NTP e SSDP, que permitem amplificação quando mal expostos. Também existem casos em que pessoas voluntárias ou serviços de “stresser” alimentam o volume. Em todos esses cenários o alvo recebe mais demanda do que consegue tratar, e a distinção entre acesso legítimo e acesso abusivo fica cara de fazer em tempo real.

Um exemplo cotidiano ajuda a fixar a escala. Imagine uma API de login que normalmente atende 200 requisições por segundo. Se milhares de fontes começam a pedir a mesma rota ao mesmo tempo, a CPU sobe, o pool de conexões do banco de dados estoura e o tempo de resposta passa de milissegundos para vários segundos. Porém o mesmo sintoma pode surgir num lançamento bem-sucedido ou numa campanha de mídia. Por isso o plano de capacidade e o plano de incidente precisam coexistir, e nenhum dos dois sozinho basta.

A armadilha clássica é tratar DDoS só como problema de “mais banda”. Banda maior atrasa a saturação volumétrica, no entanto não resolve ataque de aplicação que manda poucas requisições caras. Também não evita que um roteador ou appliance de borda esgote memória de estado. Assim, quem só compra link sem olhar aplicação, cache e filtros tende a pagar caro e continuar fora do ar.

Na prática, o que eu vejo com mais frequência é operador gastando horas só no painel da aplicação enquanto o gargalo já está no enlace ou no equipamento de borda. Se o monitoramento não cobre banda, taxa de pacotes, erros de origem e latência de DNS ao mesmo tempo, a resposta atrasa e o prejuízo comercial cresce mesmo quando o código está correto.

Quais são os tipos de ataque DDoS mais comuns?#

Os tipos de ataque DDoS mais citados em material técnico brasileiro se organizam em três famílias principais. O CERT.br descreve ataques à camada de aplicação, ataques de exaustão de recursos de hardware e ataques volumétricos, e lembra que eles podem ocorrer isolados ou combinados. Combinar famílias aumenta o impacto porque obriga respostas diferentes ao mesmo tempo, por exemplo filtragem de volume na rede e endurecimento de limites na aplicação.

Ataques à camada de aplicação#

Nessa família o volume de bits pode ser pequeno, porém o custo por requisição é alto. O CERT.br aponta que esses ataques exploram características da camada 7, saturam recursos mal dimensionados, excedem o máximo de requisições que o servidor Web ou o SGBD consegue gerenciar e disparam consultas complexas. Exemplos citados no mesmo documento incluem padrões HTTP GET e HTTP POST abusivos, além de cenários de leitura lenta. Do ponto de vista do leitor, a página “parece no ar”, no entanto cada clique demora ou falha.

A OWASP, na página sobre Denial of Service, reforça que a categoria busca tornar o recurso indisponível para o propósito original, seja por enchente de pedidos, seja por exploração da forma como o serviço trata recursos. Além disso, a cheat sheet da OWASP sobre DoS destaca que ataques de aplicação costumam ser difíceis de identificar porque não precisam consumir a banda inteira para derrubar a experiência. Por isso rate limit, validação barata primeiro e degradação graciosa entram no desenho, não só no “kit de emergência”.

Ataques de exaustão de recursos de hardware#

Aqui o alvo costuma ser a capacidade do equipamento de rede ou de segurança. O CERT.br exemplifica consumo de CPU e memória em roteadores, redução da capacidade de encaminhamento em pacotes por segundo e esgotamento da tabela de estado em firewalls e IPSs. Em outras palavras, o link ainda tem megabits livres, porém o aparelho não consegue abrir conexões novas. Quem só olha gráfico de banda fica cego para esse modo de falha.

Ataque volumétrico e reflexão com amplificação#

O ataque volumétrico tenta exaurir a banda disponível com grande volume de tráfego. O CERT.br descreve o DRDoS, em que protocolos UDP permitem amplificação e o atacante usa endereço IP forjado para que respostas grandes voltem para a vítima. No mesmo documento, citando o alerta US-CERT TA14-017A, o fator de amplificação do DNS aparece na faixa de 28 até 54 vezes, enquanto NTP chega a centenas de vezes em cenários de abuso. Esses números são fatores potenciais de protocolo mal exposto, não uma garantia de que todo incidente atinja esse teto.

Um “e se” frequente é o serviço legítimo virar refletor sem o dono perceber. Servidor DNS recursivo aberto, por exemplo, pode ser abusado para atacar terceiros e ainda consumir a própria banda da organização, tema detalhado pelo CERT.br nas recomendações sobre DNS recursivo aberto. Por outro lado, picos de audiência reais também saturam banda. A diferença operacional está no padrão das origens, no perfil das requisições e na correlação com campanhas ou publicações.

Se fosse comigo, eu começaria qualquer conversa de defesa listando qual recurso quebra primeiro em cada família, banda, estado de conexão ou custo por request. Sem esse mapa, a compra de ferramenta vira chute, e o time treina o playbook errado para o incidente que de fato chega.

Ataque DDoS e DoS simples: o que muda para quem opera o serviço?#

A diferença central está na distribuição das fontes. No DoS clássico uma origem ou um conjunto pequeno pode bastar; no DDoS o volume e a diversidade de origens crescem, o que dificulta bloqueio por lista simples de IP. A RFC 4732 trata considerações de negação de serviço na Internet e deixa explícito que, quando há escala suficiente por meio de muitos hosts comprometidos, fala-se em ataque distribuído. Essa distinção importa porque a mitigação deixa de ser “bloquear um endereço” e passa a exigir filtragem em massa, cooperação com o provedor e, em muitos casos, limpeza de tráfego fora do seu enlace.

Para quem opera o serviço, a mudança prática aparece em três frentes. Primeiro, o sinal no log fica mais ruidoso, com milhares de origens e poucos padrões óbvios de assinatura. Segundo, o custo de resposta sobe, porque bloquear de forma agressiva demais também derruba clientes reais atrás de NAT ou de redes móveis. Terceiro, a comunicação com o negócio precisa ser franca, pois a recuperação pode depender de terceiros e de capacidade contratada de mitigação, não só de restart de pod.

Há ainda a confusão com flash crowd, o pico legítimo de audiência. A própria RFC 4732 observa que, em princípio, não é trivial distinguir uma enxurrada de visitantes de um ataque, e que ter o site derrubado por pico de interesse é experiência comum. Assim, a resposta madura combina autoscaling com limites, filas e páginas de degradação, em vez de assumir má-fé em todo pico. No entanto, ignorar a hipótese de DDoS quando os indicadores de abuso batem forte também é erro caro.

O erro que mais custa caro aqui é tratar todo 503 como “bug de release” e só abrir war room de engenharia de software. Em paralelo, alguém precisa olhar rede, DNS, provedor e contrato de mitigação, senão o deploy vira teatro enquanto o enlace continua saturado.

Quais sinais costumam aparecer durante um ataque volumétrico?#

Os sinais mais úteis misturam sintoma de usuário com métrica de infraestrutura. Do lado do usuário, o site fica lento ou inacessível, formulários param no meio e apps móveis acusam timeout. Do lado da rede, a ocupação do enlace sobe de forma abrupta, a taxa de pacotes explode e o erro de origem cresce mesmo quando a aplicação ainda responde em health check interno. A MDN, no glossário de DDoS, recapitula sintomas clássicos associados a negação de serviço, como desempenho de rede anormalmente lento e indisponibilidade de um site específico.

Em um ataque volumétrico o gráfico de banda costuma ser o primeiro a gritar. Já em ataque de aplicação o gráfico de banda pode parecer “quase normal”, enquanto CPU, threads e latência de endpoint disparam. Por isso um único painel não basta. Vale correlacionar RPS por rota, latência p95, taxa de 429 e 503, uso de estado no firewall e health do DNS autoritativo. Em seguida, compare com o calendário de campanhas e com anúncios públicos que possam explicar pico legítimo.

Exemplo concreto: uma loja com pico diário de 50 Mbps vê o enlace a 1 Gbps saturado em minutos, com origem espalhada e pouca conversão no funil. Se ao mesmo tempo o checkout interno responde bem em rede privada, a hipótese de saturação de borda ganha força. Porém, se a banda está estável e só a rota de busca pesada derruba o cluster, a hipótese migra para camada de aplicação. O custo de errar o diagnóstico é continuar aplicando o antídoto errado.

Outra armadilha é achar que “sumiu o ataque” quando o tráfego cai. Pode ter sido só mudança de vetor, por exemplo de UDP amplificado para HTTP flood mais baixo e mais seletivo. Enquanto isso, contas de IoT ou estações com malware na sua própria rede podem estar participando de campanhas contra terceiros, o que gera risco reputacional e consumo local mesmo quando você não é o alvo principal.

Muita gente acha que basta um alarme de CPU alta para detectar DDoS, e quase sempre está enganada, porque o primeiro recurso a falhar pode ser o link, o estado do firewall ou o resolvedor. Sem telemetria de borda, o time só percebe o problema quando o cliente já foi embora.

Como montar proteção contra DDoS sem criar falsa sensação de segurança?#

A proteção contra DDoS começa pelo reconhecimento de que impedir a existência do ataque não é realista, porém reduzir eficácia e dano é. O CERT.br afirma de forma direta que, apesar de não ser possível impedir que esses ataques ocorram, um planejamento adequado pode torná-los menos eficazes e danosos. Essa frase deveria estar no briefing de qualquer projeto que exponha serviço crítico à Internet pública.

No desenho de aplicação, a OWASP recomenda práticas defensivas como validar barato primeiro, evitar ponto único de falha, limitar operações muito custosas de CPU e prever degradação graciosa. Além disso, limites de taxa e controle de concorrência diminuem o ganho de quem tenta esgotar pools com requisições baratas de produzir e caras de atender. Uma CDN e caches bem posicionados afastam parte do volume do origin, no entanto não substituem correção de endpoints caros nem autenticação sólida em APIs sensíveis.

Na rede e no provedor, entra a higiene que reduz amplificação e falsificação de origem. A publicação NIST SP 800-189, anunciada em dezembro de 2019 no CSRC, trata de troca resiliente de tráfego entre domínios, segurança BGP e mitigação de DDoS, incluindo validação de endereço de origem com ACLs e uRPF, além de mecanismos como RTBH e Flowspec. Isso é linguagem de operador de rede, e é exatamente o tipo de conversa que o time de produto precisa saber pedir ao provedor ou ao time de plataforma.

Há custos e limites em cada camada. Filtro agressivo demais gera falso positivo e derruba cliente bom. Mitigação gerenciada custa dinheiro e exige processo de acionamento testado. Autoscaling sem teto transforma ataque em fatura. Por outro lado, não ter nenhum contrato, nenhum contato de emergência e nenhum runbook deixa a organização refém do horário comercial do fornecedor. O equilíbrio maduro combina prevenção configuracional, detecção com limiares, capacidade de absorção e caminho claro para escalar ao provedor.

Se a sua rede publica serviços UDP desnecessários ou DNS recursivo aberto, você também pode virar peça do ataque de outra pessoa. Fechar o que não precisa estar exposto, aplicar filtragem de ingresso e manter inventário do que escuta na borda são medidas de higiene, não “projeto de anti-DDoS de luxo”. Assim, a proteção contra DDoS deixa de ser só um produto comprado e vira disciplina contínua de exposição mínima.

Quando acompanho um incidente real, o time que já ensaiou o acionamento com o provedor e já sabe qual métrica autoriza o modo de mitigação perde bem menos tempo do que o time que discute ferramenta no meio do ataque. Ensaio chato em dia calmo vale mais do que dashboard bonito sem dono.

O que priorizar durante um incidente de ataque DDoS?#

Priorize estabilizar o serviço para o usuário legítimo e preservar evidência, nessa ordem. Declare incidente com horário, sintomas e hipóteses, isole o que for possível degradar com segurança e acione o canal do provedor ou da proteção contratada antes de sair mudando regra sem registro. Em seguida, separe indicadores de volume, de estado e de aplicação para não aplicar um único remédio a três doenças diferentes.

Comunicação interna importa tanto quanto filtro. Financeiro e atendimento precisam saber que pode haver lentidão residual mesmo após a mitigação começar, porque filas e caches demoram a esvaziar. Do ponto de vista técnico, evite reiniciar tudo sem critério, pois reinício pode limpar sintoma local e apagar rastro útil, além de piorar tempestade de reconexão. Porém também não fique paralisado coletando pacote enquanto o checkout está morto. O meio-termo é mitigar com trilha de auditoria.

Depois do pico, faça postmortem com dados que digam qual recurso quebrou primeiro, qual alarme falhou, qual regra gerou falso positivo e o que ainda falta no contrato de capacidade. Sem essa etapa, o próximo ataque DDoS repete o mesmo roteiro. E se a motivação parecer extorsão ou cortina de fumaça para outro abuso, trate disponibilidade e investigação de comprometimento como trilhas paralelas, nunca como substitutas uma da outra.

No dia a dia de quem opera disponibilidade, o melhor “primeiro passo” depois do incidente é um checklist curto de exposição e de acionamento, revisado a cada trimestre. Ferramenta nova sem processo novo raramente muda o resultado na hora H.

Termos relacionados#

• servidor É o destino frequente da sobrecarga de requisições quando a aplicação ou o origin satura.
• DNS Serviço abusável em reflexão e amplificação quando recursivo aberto ou mal restrito.
• CDN Camada que pode absorver e filtrar parte do tráfego antes que ele chegue ao origin.
• firewall Equipamento cuja tabela de estado pode ser o primeiro recurso a esgotar em certos vetores.
• endereço IP Identificador forjado em muitos cenários de reflexão, o que dificulta rastreio simples.
• malware Vetor comum para recrutar máquinas em botnets usadas em campanhas distribuídas.

Perguntas frequentes sobre ataque DDoS#

Antes de seguir, vale reunir as dúvidas que mais aparecem quando o site oscila e o time precisa decidir rápido. As respostas abaixo são autossuficientes para orientar conversa inicial entre produto, rede e suporte, porém não substituem análise do tráfego do seu caso nem o contrato com o provedor responsável pela mitigação na borda.

O que é ataque DDoS em uma frase útil para o time?#

É uma campanha distribuída para tornar um serviço indisponível ao consumir banda, processamento ou conexões mais depressa do que a infraestrutura consegue atender usuários legítimos. O foco costuma ser a disponibilidade, não o roubo direto de dados. Ainda assim, o caos do incidente pode ser usado como distração para outras ações abusivas, então disponibilidade e checagem de comprometimento precisam caminhar juntas.

Todo pico de acesso é um ataque DDoS?#

Não. Campanha, menção viral ou falha de cache também derrubam serviço. A RFC 4732 lembra a dificuldade de separar flash crowd de ataque só pelo sintoma de sobrecarga. Por isso compare calendário de marketing, perfil de rotas, diversidade de origens e sinais de amplificação antes de acionar bloqueios agressivos.

Proteção na nuvem elimina o risco?#

Não elimina. Reduz superfície e oferece ferramentas, porém configuração frágil, endpoint caro e ausência de limites ainda quebram a experiência. Além disso, o custo de mitigação e de saída de dados pode subir durante o evento, então o benefício de elasticidade vem com risco financeiro se não houver tetos e alertas.

Fechar o site resolve?#

Tirar o serviço do ar para o mundo inteiro “resolve” o sintoma ao preço de cumprir o objetivo do atacante. Em alguns casos extremos a equipe escolhe modo de manutenção controlado para proteger sistemas internos, no entanto isso é decisão de negócio consciente, não vitória técnica. Sempre que possível, prefira degradar funções não essenciais e preservar o núcleo transacional.

Dispositivo doméstico ou câmera pode participar de um ataque?#

Sim, quando comprometido ou mal configurado ele pode integrar botnet e gerar tráfego abusivo sem o dono perceber. Atualizar firmware, trocar senha padrão e evitar exposição desnecessária de serviços na Internet reduz a chance de a sua rede virar peça do problema de outra organização.

Vale a pena testar a própria defesa com ferramenta pública de stress?#

Somente com autorização explícita, escopo escrito e ambiente adequado. Disparar carga contra sistema de terceiro ou contra produção sem acordo é abuso e pode ser crime. O caminho seguro é teste contratado, janela combinada e critérios de aceitação ligados a disponibilidade e a falso positivo.

Conclusão#

Para a maioria das equipes que publica serviço na Internet, o caminho maduro é tratar ataque DDoS como risco permanente de disponibilidade, não como evento raro de filme. Isso significa inventário do que está exposto, métricas de borda e de aplicação, limites na camada 7, conversa explícita com o provedor e ensaio do acionamento antes do incidente.

A resposta muda quando o negócio depende de janelas curtas, como checkout de campanha ou API de pagamento. Nesses casos a prioridade sobe, o orçamento de mitigação precisa ser discutido com antecedência e o plano de degradação tem de existir no produto, não só no runbook de rede. Se a operação ainda é pequena, o primeiro passo continua sendo higiene básica, monitoramento honesto e um contato de emergência testado.

Comece amanhã por três checagens concretas. Confirme se há DNS recursivo ou serviço UDP exposto sem necessidade. Liste os três recursos que quebrariam primeiro no seu desenho atual. Ensaie com o time quem liga para quem quando o enlace saturar. Essa ordem simples reduz improvisação quando o volume hostil aparecer.

Este texto sobre ataque DDoS é informativo e voltado à compreensão defensiva do tema. Não é consultoria de segurança, pentest nem orientação para explorar sistemas de terceiros. Ferramentas, capacidades de provedores e práticas de mitigação mudam com o tempo. Em outubro de 2026, decisões de arquitetura e de resposta a incidente devem considerar a realidade do seu ambiente e, quando houver risco relevante ao negócio, o acompanhamento de profissional de segurança e de operação de rede habilitado.