Como mitigar DDoS: passo a passo da contenção para provedores
Como mitigar DDoS: escolha a contenção pelo tamanho e pelo vetor do ataque, aplique-a o mais longe possível do seu link e suba de camada só quando a anterior não bastar. A escada vai do filtro na borda à regra FlowSpec, ao blackhole na operadora e ao desvio para limpeza, e cada degrau cobra um preço diferente do assinante atacado.
Resumo
- Mitigar é decidir onde o tráfego ruim é descartado, na sua borda, na operadora ou num centro de scrubbing.
- Filtro na borda só funciona enquanto o link ainda tem folga e a CPU do roteador aguenta a regra.
- O blackhole salva o resto da rede, mas tira o alvo do ar; FlowSpec e limpeza preservam o tráfego legítimo.
- Ataque espalhado por um bloco inteiro e ataque contra a própria borda pedem contenções próprias.
O que é mitigar um DDoS, e o que não é
Mitigar um DDoS é reduzir o efeito do ataque até a rede voltar a atender os assinantes, descartando ou desviando o tráfego ruim. Não é fazer o ataque parar, porque isso depende só de quem ataca.
A diferença muda o critério de sucesso. A mitigação deu certo quando o link esvaziou e os outros assinantes voltaram a navegar, mesmo que o atacante continue mandando tráfego para um ponto onde ele já não faz estrago.
Saber como mitigar DDoS exige decidir em que ponto do caminho o tráfego ruim vai morrer, e essa decisão depende do diagnóstico feito antes. O guia de como identificar DDoS mostra como chegar ao alvo, ao vetor e ao tamanho; a visão geral da proteção DDoS para provedor mostra como as camadas se encaixam.
Como parar ataque DDoS: o que está nas suas mãos
Parar o ataque na origem quase nunca está ao alcance do provedor, porque o tráfego vem de milhares de máquinas que ele não controla. O que dá para parar em minutos é o estrago, quando o tráfego ruim deixa de chegar ao link.
O ataque em si termina por caminhos que ficam fora da sua borda: o atacante desiste ao ver que o alvo não cai mais, o tempo pago num serviço de ataque acaba ou as redes de origem limpam as máquinas usadas, o que leva dias ou semanas. A notificação ao CERT.br, com horários e IPs de origem, ajuda nesse último caminho, mas não substitui a contenção.
Durante o ataque, a pergunta útil deixa de ser como fazê-lo parar e passa a ser em que ponto descartar o tráfego, que é o que as ferramentas abaixo resolvem.
As quatro ferramentas de contenção
Toda mitigação de provedor regional combina quatro ferramentas. Elas diferem no lugar onde agem e no que sobra para o assinante atacado depois que a contenção entra.
| Ferramenta | Onde age | Funciona com o link cheio? | O que acontece com o alvo |
|---|---|---|---|
| Filtro na borda | No seu roteador, por ACL ou firewall | Não | Continua no ar, se a regra for precisa |
| FlowSpec | No roteador da operadora que aceita a regra | Sim, se a operadora aplicar | Continua no ar, perde só o vetor filtrado |
| Blackhole | Na operadora ou no IX | Sim | Fica fora do ar enquanto durar |
| Limpeza externa | No centro de scrubbing contratado | Sim, até a capacidade do serviço | Continua no ar, com latência um pouco maior |
A coluna do meio é a que decide. Se o ataque já lota o link, qualquer regra aplicada no seu roteador chega tarde, porque o tráfego ruim ocupou a banda antes de ser descartado.
Como mitigar DDoS passo a passo, do filtro ao desvio
A mitigação segue uma escada: começa pela contenção mais precisa que ainda funciona e sobe quando o ataque passa do que aquele degrau aguenta. Cada degrau tem uma condição de entrada que dá para conferir em minutos.
Degrau 1
Filtro na borda
O link tem folga e o vetor tem assinatura clara. A regra entra no seu roteador.
Degrau 2
FlowSpec na operadora
O link lotou, mas o vetor é claro. A operadora descarta só o tráfego que bate com a regra.
Degrau 3
Blackhole do alvo
Sem filtro fino disponível, o IP atacado é sacrificado para o resto da base voltar.
Degrau 4
Desvio para limpeza
O alvo não pode sair do ar. O prefixo é anunciado pelo serviço de limpeza, que devolve o tráfego bom.
O degrau 4 só existe se o serviço de limpeza estiver contratado e testado antes. No meio do ataque, a escada real de quem não contratou termina no degrau 3.
- Proteja a borda: confira que as sessões BGP e o acesso de gerência seguem de pé, porque toda contenção depende deles.
- Escolha o degrau: compare o tamanho do ataque com a folga do link por onde ele entra e veja se o vetor tem assinatura.
- Comece por uma operadora: aplique a contenção no link que recebe a maior parte do ataque e confira o efeito antes de repetir.
- Meça o resultado: acompanhe a interface e os fluxos do alvo por alguns minutos; se o link não esvaziou, suba um degrau.
- Siga o vetor: atacantes trocam de porta ou de protocolo quando a primeira onda é contida, e a regra precisa acompanhar.
- Retire com critério: desfaça a contenção aos poucos e deixe a regra salva para voltar se o tráfego subir.
DDoS: como resolver quando a rede já está caindo?
Para resolver um DDoS em andamento, garanta primeiro o acesso à borda, ache alvo e vetor nos fluxos e só então escolha o degrau. Resolvido, aqui, quer dizer link vazio e base navegando, mesmo com o atacante ainda ativo.
- Gerência caiu: entre por um acesso de gerência separado, se houver, e aplique antes o filtro do plano de controle.
- Link cheio, alvo único: regra FlowSpec pelo vetor e, se nenhuma operadora aceitar, blackhole do /32.
- Tráfego espalhado no bloco: regra pelo vetor valendo para o prefixo inteiro ou desvio para limpeza.
- Link com folga: filtro na própria borda, sem envolver a operadora.
Quando nenhum degrau está pronto e a equipe não sabe por onde começar, a mitigação emergencial assume a contenção com o ataque em curso.
Degrau 1: filtro na borda, configuração de referência
O filtro na borda é o único degrau que não depende de ninguém de fora. No MikroTik, a tabela raw descarta o pacote antes do rastreamento de conexões, o que poupa CPU durante o ataque.
# prefixos dos assinantes e lista das interfaces de trânsito (crie antes)
/ip firewall address-list
add list=prefixos-clientes address=203.0.113.0/24
add list=prefixos-clientes address=198.51.100.0/24
/ip firewall raw
# reflexão Memcached: não há uso legítimo vindo da internet para assinante
add chain=prerouting in-interface-list=TRANSITO protocol=udp src-port=11211 dst-address-list=prefixos-clientes action=drop comment="ddos memcached"
# reflexão NTP: descarta só as respostas grandes da porta 123
add chain=prerouting in-interface-list=TRANSITO protocol=udp src-port=123 packet-size=200-1500 dst-address-list=prefixos-clientes action=drop comment="ddos ntp"
# reflexão SSDP: porta 1900 de origem vinda da internet
add chain=prerouting in-interface-list=TRANSITO protocol=udp src-port=1900 dst-address-list=prefixos-clientes action=drop comment="ddos ssdp"As mesmas regras precisam existir em /ipv6 firewall raw, com os prefixos IPv6 dos assinantes. Para os degraus 2 e 3, os guias de configuração de FlowSpec e de configuração de RTBH trazem a configuração completa.
Qual contenção usar para cada tipo de ataque?
O vetor decide a primeira contenção, e o tamanho decide se ela basta. A tabela mostra a combinação mais comum em provedor regional e o passo seguinte quando a primeira não segura.
| Vetor | Assinatura | Primeira contenção | Se não bastar |
|---|---|---|---|
| Reflexão UDP | Porta de origem fixa, como 53, 123, 389, 1900 ou 11211 | Regra pela porta de origem, na borda ou por FlowSpec | Blackhole do alvo ou limpeza |
| SYN flood | TCP SYN em massa, pacotes mínimos, origens forjadas | Proteção de SYN no servidor ou no serviço de limpeza | Desvio do prefixo para limpeza |
| Fragmentos UDP | Pedaços de pacote sem porta, quase sempre parte de reflexão | Descarte de fragmentos para IPs residenciais [CONFIRMAR impacto na sua base] | Blackhole do alvo |
| Espalhado no bloco | Muitos destinos do mesmo /24, nenhum se destaca | Regra pelo vetor valendo para o prefixo inteiro | Desvio do /24 para limpeza |
| Contra a borda | Tráfego para os IPs do roteador e dos enlaces | Filtro do plano de controle e GTSM nas sessões | Enlaces sem rota pública |
Quer a escada de contenção pronta antes do próximo ataque?
Na proteção DDoS da Táquion Tech, filtros, blackhole e desvio para limpeza ficam combinados com as operadoras e testados com IP de laboratório.
Ataque espalhado pelo pool do CGNAT
O ataque espalhado derrota o blackhole de um IP só. Para conter com /32, seria preciso anunciar dezenas ou centenas de endereços e tirar do ar todos os assinantes que dividem o pool do CGNAT.
Nesse caso, a contenção certa filtra pelo vetor e vale para o prefixo inteiro, por FlowSpec ou na limpeza. A regra descarta, por exemplo, UDP com origem na porta 123 para todo o /24, e o tráfego normal dos assinantes continua passando.
Quando o alvo é a própria borda
Alguns ataques miram o roteador de borda, os IPs dos enlaces com as operadoras ou o acesso de gerência. Se a CPU trava, as sessões BGP caem e a rede some da internet, com ou sem link cheio.
- Plano de controle: uma ACL deixa chegar ao roteador só o BGP dos vizinhos, a gerência da rede interna e o ICMP com limite de taxa.
- GTSM: a checagem de TTL definida na RFC 5082 faz a sessão BGP recusar pacotes que não vêm do vizinho direto.
- Enlaces: endereços dos enlaces ponto a ponto fora dos anúncios públicos deixam o atacante sem alvo.
Esses ajustes fazem parte do hardening de roteadores e precisam ser aplicados fora do ataque, em janela de manutenção.
Na prática: um ataque de reflexão DNS em quatro tempos
Um caso comum mostra a escada funcionando e o vetor mudando no meio. O provedor tem duas operadoras de trânsito, e só uma delas aceita FlowSpec.
- 21h05: o link da operadora A lota com UDP de origem na porta 53 para um IP de assinante; o filtro na borda descarta o tráfego, mas o link segue cheio.
- 21h12: a equipe anuncia uma regra FlowSpec para a operadora A, descartando UDP da porta 53 com destino ao /32 atacado, e o link esvazia.
- 21h30: o atacante troca para reflexão NTP; o alarme por protocolo dispara e uma segunda regra, pela porta 123, entra no mesmo minuto.
- 22h40: sem tráfego de ataque há meia hora, as regras são retiradas uma de cada vez, com a configuração guardada para voltar.
O assinante atacado não saiu do ar em nenhum momento, porque o blackhole não foi necessário. Se a operadora A não aceitasse FlowSpec, o degrau seguinte seria o blackhole do /32, com o assinante fora até o ataque acabar.
O horário de cada passo entra no registro do incidente. Esse histórico mostra à operadora que o problema se repete e ajuda a negociar no contrato uma contenção mais rápida.
Erros comuns ao mitigar DDoS
Os piores erros de mitigação trocam o ataque por uma queda causada pelo próprio provedor. Quase todos vêm de regra larga demais ou de contenção que ninguém lembra de retirar.
Evite
- Descartar todo o UDP da porta 53 e derrubar a resolução de nomes dos assinantes.
- Anunciar regra FlowSpec sem destino, que vale para a rede inteira.
- Deixar o blackhole ativo por dias, com o assinante sem internet e sem saber por quê.
- Mitigar só no IPv4 e deixar o ataque passar pelo IPv6.
- Aplicar a mesma regra em todas as operadoras de uma vez, sem medir o efeito.
- Contratar limpeza externa e nunca testar o desvio nem o túnel de retorno.
O primeiro erro é comum porque a reflexão DNS usa a porta 53, e a regra apressada pega tudo. A regra correta descarta só o que vem da porta 53 para os assinantes, e não o que sai deles nem o que vai para o DNS do provedor.
Como saber que a mitigação funcionou?
A mitigação funcionou quando três medidas voltam ao normal ao mesmo tempo. Olhar só uma delas engana, porque o ataque pode ter só trocado de vetor.
- Link: a interface por onde o ataque entrava voltou ao tráfego normal do horário.
- Fluxos do alvo: o volume para o IP ou o prefixo atacado caiu, e o vetor sumiu dos maiores protocolos.
- Assinantes: as reclamações pararam e os testes a partir da rede voltaram a responder.
Quando vale ter a mitigação pronta em vez de improvisar?
Vale ter pronta desde o segundo ataque, porque a partir dele o provedor já é alvo conhecido. Improvisar custa os minutos em que alguém procura a community certa ou o contato da operadora.
Marque o que já está pronto na sua borda
- As regras de filtro dos vetores comuns estão salvas e só precisam ser ativadas.
- Cada operadora confirmou por escrito a community de blackhole que aceita.
- Pelo menos uma operadora aceita FlowSpec, e a regra foi testada com IP de laboratório.
- A lista de IPs de infraestrutura que nunca entram no blackhole está escrita.
- O desvio para limpeza, se contratado, já foi acionado num teste.
- A equipe de turno sabe aplicar cada degrau sem esperar uma pessoa específica.
Cada item em branco é um degrau que vai faltar no meio do ataque. Com três ou mais em branco, a mitigação ainda depende de improviso.
A Táquion Tech implanta a detecção e a contenção automática na borda, combina blackhole e FlowSpec com as operadoras e integra o serviço de limpeza quando o histórico pede. Os detalhes estão na mitigação de DDoS e no scrubbing de tráfego; com o ataque em andamento, o caminho é a mitigação emergencial.
Perguntas frequentes
Tem como resolver DDoS de vez no provedor?
De vez, não, porque o ataque depende de quem ataca e pode voltar a qualquer noite. O que se resolve de forma duradoura é a capacidade de conter, com regras salvas, blackhole testado com cada operadora e limpeza contratada se o histórico pedir.
Dá para mitigar DDoS sem tirar o cliente do ar?
Dá, com FlowSpec ou limpeza externa, que descartam só o tráfego de ataque. O blackhole é o único degrau que tira o alvo do ar, e por isso fica para quando os outros não estão disponíveis.
Quanto tempo a contenção deve ficar ativa depois do ataque?
Não há tempo fixo, mas o usual é esperar um período sem tráfego de ataque e retirar aos poucos, medindo a cada passo. Ataques contra jogadores costumam voltar em ondas, então a regra deve ficar salva para reativar.
A operadora de trânsito mitiga o ataque por conta própria?
Algumas oferecem proteção no próprio link, mas muitas só agem quando o provedor pede ou anuncia a community. Vale perguntar por escrito o que a operadora faz, a partir de que volume e em quanto tempo. [CONFIRMAR com cada operadora]
Como parar ataque DDoS que volta toda noite?
Ataque que se repete pede contenção pronta, e não reação: deixe a regra do vetor salva para ativar em segundos e um alarme por fluxo que dispare no começo da onda. Se o alvo é sempre o mesmo assinante, registre cada episódio e use esse histórico para combinar com a operadora uma contenção mais rápida.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 8955, Dissemination of Flow Specification Rules: padrão das regras FlowSpec enviadas por BGP para descartar só o tráfego de ataque.
- RFC 7999, BLACKHOLE Community: community padrão para pedir o descarte do tráfego de um IP à operadora.
- RFC 5082, The Generalized TTL Security Mechanism (GTSM): checagem de TTL que protege as sessões BGP contra pacotes forjados.
