Como testar proteção DDoS: passo a passo seguro para provedores
Como testar proteção DDoS: teste cada camada separadamente, com tráfego pequeno e controlado contra um IP de laboratório, em vez de simular um ataque inteiro. Primeiro se faz a conta do que o link aguenta; depois se confere se a detecção dispara, se cada operadora aceita o blackhole, se o filtro age e se o desvio para limpeza volta limpo.
Resumo
- Um teste de DDoS útil prova cada peça da defesa isoladamente, e não o tamanho máximo de ataque que a rede suporta.
- [object Object]
- O blackhole precisa ser testado em cada operadora, porque uma community aceita numa não diz nada sobre a outra.
- Lançar tráfego de ataque de verdade exige autorização escrita, operadoras avisadas e janela combinada.
Como testar proteção DDoS sem derrubar a rede
Testa-se a proteção desmontando a defesa em peças e provando cada uma com pouco tráfego. Um ataque simulado em tamanho real não prova mais do que isso e ainda coloca assinantes e operadoras em risco.
A defesa contra DDoS de um provedor é uma corrente: detecção nos fluxos, filtros na borda, blackhole nas operadoras, FlowSpec quando existe e desvio para limpeza quando o contrato prevê. Basta um elo solto para o ataque derrubar a rede, e cada elo pode ser conferido sem gerar volume de ataque.
É a mesma lógica de um teste de freio: ninguém bate o carro no muro para saber se o freio funciona. Mede-se a pastilha, o fluido e a resposta do pedal, cada um no seu teste.
Antes de qualquer tráfego de teste, vale ter um retrato do que já existe. A Táquion Tech faz a avaliação de resiliência anti-DDoS com acesso só de leitura, sem mudar a configuração, e entrega os riscos em ordem com a evidência de cada achado.
Os três níveis de teste, do mais seguro ao mais arriscado
Os testes se dividem pelo quanto mexem na rede em produção. Comece pelo primeiro nível e só suba quando o anterior estiver limpo.
- Teste de papel: conferir contratos, communities, contatos das operadoras, acessos e o roteiro escrito, sem enviar nenhum pacote.
- Teste funcional: disparar cada mecanismo contra um IP de laboratório, com tráfego mínimo, e ver se ele age.
- Teste de carga: gerar volume real contra a rede para medir limites, só com autorização formal e fornecedor preparado.
Minha rede aguenta ataque DDoS? Faça a conta antes do teste
Aguenta enquanto o ataque couber na folga do link no horário de pico e o roteador conseguir processar os pacotes. Acima disso, só o que acontece fora da sua rede, na operadora ou num centro de limpeza, resolve.
A conta usa números que você já tem nos gráficos de interface. Ela não diz se a proteção funciona, mas diz a partir de que tamanho de ataque cada camada precisa entrar.
| Limite | Como medir | O que acontece quando o ataque passa dele |
|---|---|---|
| Folga do link | Capacidade do trânsito menos o pico de tráfego da semana | Os assinantes começam a sentir lentidão e perda de pacotes |
| Capacidade do link | Soma dos contratos de trânsito que recebem o ataque | Nenhum filtro dentro da sua rede ajuda; o descarte precisa ser na operadora |
| Pacotes por segundo da borda | Limite do roteador informado pelo fabricante para o tamanho de pacote do ataque | O roteador perde sessões BGP e a gerência, mesmo com o link sobrando |
O terceiro limite surpreende muita gente. Um ataque de pacotes pequenos pode derrubar a borda com o link pela metade, porque o gargalo é o processamento, e não a banda [CONFIRMAR o limite na ficha do equipamento].
Exemplo: a conta em dois links de 10 Gbps
Um provedor com dois trânsitos de 10 Gbps e pico de 14 Gbps tem 6 Gbps de folga somada. Um ataque de 5 Gbps passa quase despercebido; um de 8 Gbps já afeta assinantes; um de 25 Gbps lota os dois links.
Se o ataque chega todo por um link só, a folga real é a daquele link, e não a soma. Por isso a conta precisa ser feita por operadora, olhando por onde os ataques anteriores entraram.
Teste funcional camada por camada
O teste funcional usa um IP de laboratório, fora de qualquer cliente, e uma janela de pouco uso combinada com as operadoras. Cada passo prova um mecanismo e tem um critério claro de aprovado.
- Preparo: reserve um IP de laboratório num /24 seu, avise o contato técnico de cada operadora e registre a janela.
- Detecção: de um host de teste fora da rede, envie tráfego baixo e com prazo contra o IP e cronometre até o alarme por destino aparecer.
- Proteção da borda: confira se os contadores do filtro de controle do roteador sobem quando pacotes de gerência chegam de fora.
- Blackhole: anuncie o /32 do laboratório com a community de cada operadora, uma por vez, e confira no looking glass dela.
- FlowSpec: se a operadora aceita, aplique uma regra contra a porta de teste e veja se o tráfego deixa de chegar.
- Desvio para limpeza: se há contrato, desvie o bloco de laboratório, meça a latência e teste pacotes grandes pelo túnel.
- Retirada: desfaça cada mecanismo pelo roteiro e confirme que o IP volta a receber tráfego normalmente.
A configuração que o passo do blackhole confere está detalhada no guia de configuração de RTBH, e a regra de filtro do passo seguinte segue a configuração de FlowSpec.
Comandos de referência para o teste funcional
Os comandos abaixo usam endereços de documentação e servem de modelo. Ajuste a sintaxe ao seu equipamento e mantenha a taxa de envio baixa.
# 1. Host de teste fora da rede: tráfego UDP baixo, com fim definido, contra o IP de laboratório
hping3 --udp -p 9999 -i u2000 -c 30000 203.0.113.10
# 2. Borda (sintaxe estilo Cisco IOS XR): o /32 saiu para a operadora com a community?
show bgp ipv4 unicast neighbor 198.51.100.1 advertised-routes | include 203.0.113.10
show bgp ipv4 unicast 203.0.113.10/32
# 3. Borda (MikroTik RouterOS 7): mesma conferência
/routing/route/print detail where dst-address=203.0.113.10/32
# 4. Durante o desvio para limpeza: pacotes grandes atravessam o túnel?
ping -M do -s 1472 -c 5 203.0.113.10
ping -M do -s 1400 -c 5 203.0.113.10
# 5. Caminho do tráfego durante o desvio (rodar de fora da rede)
mtr -rwc 50 203.0.113.10
Se o ping com 1.472 bytes falha e o de 1.400 passa durante o desvio, o túnel está cortando pacotes grandes e o ajuste de MSS precisa ser revisto antes de um ataque real.
Critério de aprovado para cada camada
Checklist de referência do teste funcional
- O alarme por destino apareceu e apontou o IP de laboratório, não só a interface.
- O tempo entre o início do tráfego e o alarme foi anotado.
- Cada operadora mostrou o /32 com a marca de descarte no looking glass.
- A remoção do anúncio devolveu o tráfego ao IP em poucos minutos.
- A regra de filtro reduziu o tráfego da porta de teste sem afetar outras portas.
- Pacotes grandes passaram pelo túnel durante o desvio para limpeza.
- Quem estava de turno executou o roteiro sem ajuda de quem escreveu.
Item sem marca é falha que vai aparecer no ataque real. Corrija, repita só aquele passo e anote a data do teste no roteiro da equipe.
Na prática: o alarme que chegou tarde demais
Num teste funcional típico, o blackhole funcionou nas duas operadoras, mas o alarme de detecção só apareceu muitos minutos depois do início do tráfego. O problema estava na exportação dos fluxos, e não no sistema de detecção.
O roteador de borda exportava os fluxos com o tempo ativo padrão do fabricante, longo demais para um ataque. Fluxos longos só eram enviados ao coletor quando o tempo vencia, e a detecção enxergava o ataque com atraso [CONFIRMAR o padrão na versão do equipamento].
A correção foi reduzir o tempo ativo de exportação para um valor curto, compatível com a capacidade do coletor, e repetir o passo de detecção. O alarme passou a aparecer logo no começo do tráfego de teste. O guia sobre como identificar DDoS mostra o que os fluxos precisam revelar.
Esse tipo de achado não aparece num teste de papel, porque a configuração parece certa. Só o tráfego de teste, mesmo pequeno, revela o tempo real entre o começo do ataque e a primeira reação.
Quando vale um teste com tráfego de ataque de verdade?
Vale quando o teste funcional já passou e falta saber o limite real de um equipamento ou de um contrato de limpeza. Ele só deve ser feito com autorização formal, fornecedor especializado e todas as redes no caminho avisadas.
Gerar volume de ataque atravessa a rede das operadoras e de outros sistemas autônomos. Mesmo contra o seu próprio IP, um teste sem aviso pode disparar a proteção de quem está no caminho e afetar clientes de terceiros.
- Autorização escrita: assinada por quem responde pela rede, com escopo, horário e limite de volume.
- Operadoras avisadas: cada trânsito e o ponto de troca precisam saber da janela e do tamanho previsto.
- Botão de parada: um canal direto com quem gera o tráfego para interromper o teste a qualquer momento.
- Fornecedor identificado: empresa com contrato e responsabilidade, nunca serviço anônimo de stress test.
Serviços anônimos que vendem ataques disfarçados de teste são usados por criminosos, e contratar um deles pode configurar crime pela legislação brasileira [CONFIRMAR na norma]. Testar a própria rede com eles também financia quem ataca os provedores.
Erros comuns ao testar proteção DDoS
Os erros mais frequentes vêm de testar tudo de uma vez, testar só uma operadora ou nunca repetir o teste. Todos deixam a sensação de proteção sem a proteção.
Evite no teste de proteção DDoS
- Usar IP de cliente: um blackhole de teste num IP em uso derruba alguém que não sabia do teste.
- Testar só a operadora principal: o ataque escolhe o caminho, e a operadora secundária costuma ser a que falha.
- Medir só se funcionou: sem cronometrar, não se sabe se a reação levou um minuto ou meia hora.
- Esquecer a retirada: um teste que não confere a volta deixa rotas de descarte esquecidas na operadora.
- Testar uma vez e nunca mais: troca de operadora, de equipamento ou de equipe invalida o resultado anterior.
O ensaio com a equipe, em que quem está de turno executa o roteiro sozinho, complementa o teste técnico. O guia sobre DDoS, como evitar descreve esse exercício como parte da preparação.
Quando repetir o teste
Repita o teste funcional sempre que algo mudar na borda ou nos contratos. A data do último teste deve ficar anotada no roteiro, ao lado de cada mecanismo.
- Operadora nova: cada trânsito novo tem community, filtros e contato próprios.
- Troca de equipamento: firmware novo muda padrões de exportação de fluxos e de filtros de controle.
- Mudança de equipe: quem entrou precisa executar o roteiro ao menos uma vez em teste.
- Depois de um ataque: o que falhou no incidente vira o primeiro passo do teste seguinte.
Perguntas frequentes
Posso testar a proteção DDoS sozinho?
O teste de papel e o teste funcional com tráfego mínimo podem ser feitos pela equipe da casa, desde que as operadoras sejam avisadas. O teste de carga exige fornecedor especializado e autorização formal.
Como saber se minha rede aguenta ataque DDoS?
Compare o tamanho dos ataques que você já recebeu com a folga dos links no pico e com o limite de pacotes do roteador de borda. Se o ataque passa da capacidade do link, a resposta depende do que as operadoras ou a limpeza fazem.
O teste de blackhole afeta outros clientes?
Não, se for feito com um IP de laboratório que não atende ninguém. O descarte vale só para o /32 anunciado, e o resto do bloco segue normal.
Preciso avisar a operadora antes do teste?
Sim, sempre. A operadora pode estranhar um anúncio de descarte fora de um ataque ou tráfego incomum vindo de fora, e o contato técnico dela ajuda a conferir se a marca chegou.
De quanto em quanto tempo testar a proteção?
Depois de cada mudança de operadora, equipamento ou equipe, e também depois de cada ataque real. Sem mudanças, um teste periódico combinado com as operadoras evita que a configuração envelheça sem ninguém perceber.
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 7999: BLACKHOLE Community: define a community padrão de descarte, conferida em cada operadora no teste de blackhole
- RFC 8955: Dissemination of Flow Specification Rules: especifica o FlowSpec, usado no passo de teste do filtro na operadora
- RFC 4732: Internet Denial-of-Service Considerations: descreve os tipos de negação de serviço e por que a defesa precisa de várias camadas
