AntiDDoS bloqueando tráfego legítimo: procedimentos de bypass de emergência
Quando o próprio dispositivo AntiDDoS se torna a interrupção — bloqueando tráfego de negócio real em vez de protegê-lo — este é o caminho rápido de volta: distinguir primeiro um falso positivo de um ataque não detectado, a captura de diagnóstico a executar antes de tocar em qualquer coisa, o procedimento de bypass para implantações fora de linha e em linha, como confirmar se realmente funcionou, e o ajuste de limiares que evita que aconteça de novo.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Quando a proteção se torna a interrupção
Um scrubber de DDoS que bloqueia clientes reais é uma interrupção autoinfligida — e exige uma resposta mais rápida e mais calma do que um ataque real.
Um dispositivo AntiDDoS que começa a descartar tráfego legítimo é uma emergência por si só: o impacto no negócio parece idêntico a uma interrupção, mas a correção não é um reparo de rede — é reconhecer que a própria política de defesa do dispositivo se tornou o problema, e desfazê-la rápida e corretamente. Acionar primeiro a alavanca errada (ou acionar a certa sem verificar o que realmente está errado) desperdiça exatamente os minutos que importam.
A seguir está essa resposta, diretamente do manual de recuperação de emergência do AntiDDoS: como distinguir isso de um ataque que realmente está passando, as informações que vale a pena capturar antes de tocar em qualquer coisa, o próprio procedimento de bypass para as duas formas comuns de implantação, como confirmar que realmente funcionou, e o ajuste que evita que aconteça de novo.
Primeiro: falso positivo ou ataque não detectado?
O bypass é a resposta certa para exatamente um desses dois casos — acerte esse diagnóstico antes de fazer qualquer outra coisa.
| Padrão de tráfego | Diagnóstico |
|---|---|
| O tráfego de entrada não aumentou de forma perceptível em relação ao normal, mas o tráfego que sai do outro lado do dispositivo AntiDDoS caiu de forma perceptível. | Falso positivo (误防) — a própria política do dispositivo está bloqueando tráfego que nunca foi realmente um ataque. Esta nota se aplica: prossiga para o bypass. |
| O tráfego de entrada aumentou de forma perceptível em relação ao normal, e o tráfego que sai do outro lado ainda é muito maior que o normal. | Ataque não detectado (漏防) — o ataque está passando, não está sendo bloqueado. Fazer bypass do dispositivo aqui remove a única defesa existente; a resposta correta é ativar a defesa mais rápido, não contorná-la. |
Errar esse diagnóstico em qualquer direção queima os minutos que importam — fazer bypass durante um ataque real, ou procurar tráfego de ataque que nunca existiu, ambos atrasam a correção realmente necessária.
Capture isto antes de tocar em qualquer coisa
Seis comandos, executados antes da recuperação — o registro que você vai querer ter quando a pressão passar.
| Command | What it captures |
|---|---|
| collect diagnostic information | O pacote completo de informações de diagnóstico para este incidente. |
| display firewall statistic system discard | Estatísticas de descarte de pacotes em todo o sistema — o que está realmente sendo descartado e onde. |
| display anti-ddos packet-trace statistic | Estatísticas de descarte específicas do processamento AntiDDoS — separando seus descartes dos descartes comuns do firewall. |
| display cpu-usage slot slot-id cpu cpu-id | O uso de CPU da placa SPU no momento do incidente. |
| display anti-ddos resource slot slot-id cpu cpu-id | Uso da tabela de recursos — se uma tabela está próxima da capacidade independentemente de qualquer ataque. |
| display firewall session table verbose | Uso da tabela de sessões no momento do incidente, para comparação com o estado pós-bypass. |
O procedimento de bypass — duas formas de implantação
As implantações fora de linha e em linha falham de forma diferente, então o caminho mais rápido de volta também difere.
Implantação fora de linha
Nessa forma de implantação, o tráfego é desviado para o dispositivo AntiDDoS apenas quando algo parece errado — então desligar o desvio é a alavanca mais rápida, mas não é a única que precisa ser acionada.
- No dispositivo, desligue a interface voltada para o desvio para parar o desvio imediatamente.
- Faça login no plano de O&M do SecoManager (https://[IP flutuante norte]:31943).
- Em Defesa contra Ataques > Desvio, verifique se existe uma tarefa de desvio para o IP afetado; se existir, desative-a.
- Em Defesa contra Ataques > Flowspec, verifique uma tarefa de Flowspec no IP afetado; desative-a se estiver presente.
- Em Defesa contra Ataques > Blackhole, verifique uma tarefa de blackhole no IP afetado; desative-a se estiver presente.
- Em Defesa contra Ataques > Objetos de Proteção, encontre o objeto de proteção do IP afetado (o objeto de proteção padrão, se nenhum foi configurado individualmente), edite seu modo de defesa para desativar o desvio automático e o blackhole automático, depois salve e implante.
[HUAWEI-100GE4/0/1] display this
interface 100GE4/0/1
shutdown
ipv6 enable
ip address 172.16.1.1 255.255.255.0
ipv6 address 2001:db8:1::1/64Implantação em linha
Nessa forma de implantação, o dispositivo fica fisicamente no caminho do tráfego em modo de Camada 2 transparente, então o caminho de recuperação depende de que tipo de hardware de bypass está realmente presente.
- Se houver uma unidade de bypass externa presente, siga suas próprias instruções de operação para colocar o dispositivo AntiDDoS em bypass.
- Se houver uma placa de bypass embutida presente, faça login diretamente no dispositivo AntiDDoS e configure o bypass pela CLI.
- Se não houver nenhum hardware de bypass, faça login no plano de O&M do SecoManager em vez disso: em Defesa contra Ataques > Objetos de Proteção, encontre e remova o objeto de proteção do IP afetado (e também o objeto de proteção padrão, se existir).
- Em Defesa contra Ataques > Filtro > Filtro de Hardware, desassocie todos os filtros de hardware atualmente vinculados.
- Em Defesa contra Ataques > Blackhole, verifique uma tarefa de blackhole no IP afetado e desative-a se estiver presente.
- Em Defesa contra Ataques > Flowspec, verifique uma tarefa de Flowspec no IP afetado e desative-a se estiver presente.
Os dois caminhos de bypass, lado a lado
Mesmo objetivo, mecânica diferente — porque o tráfego chega ao dispositivo de forma diferente em cada implantação.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Projetos de soluções relacionadas
Depois do bypass: verificar e depois ajustar
O bypass estanca a hemorragia — não corrige por que o falso positivo aconteceu em primeiro lugar.
- Execute novamente as mesmas capturas anteriores à recuperação (tabela de sessões, estatísticas de descarte, estatísticas de packet-trace) e compare com os números de antes do incidente, e confirme que o próprio negócio afetado está realmente acessível — não apenas que os contadores do dispositivo parecem mais calmos.
- Se o falso positivo foi causado pela lista negra, limpe a lista negra dinâmica — mas por CPU, não uma única vez para o dispositivo inteiro.
- Atualize os limiares de defesa de acordo com os últimos resultados de aprendizado de linha de base à medida que o tráfego de negócio cresce — um limiar definido para o tráfego do trimestre passado é uma fonte comum de falso positivo meses depois.
- Fique atento a mudanças no tipo de negócio no mesmo objeto protegido — por exemplo, um serviço que costumava ser tráfego web TCP puro e desde então adicionou tráfego de vídeo UDP precisa ter sua antiga política de limitação de taxa UDP revisada e, se não se aplicar mais, removida.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// clears the blacklist for one CPU only -- repeat for every CPU on the slot(s) in questionCinco armadilhas sob a pressão do bypass
Cada uma dessas já custou tempo real de recuperação para alguém.
1. Desligar a interface não impede que o SecoManager volte a desviar
SYMPTOMA interface voltada para o desvio está desligada no dispositivo, mas o tráfego afetado ainda parece estar sendo desviado ou bloqueado.
CAUSEAs tarefas de desvio, Flowspec e blackhole residem no SecoManager, independentemente do estado da própria interface — desligar a interface impede que o tráfego chegue fisicamente ao dispositivo por aquele caminho, mas não desativa as tarefas que voltariam a desviá-lo assim que a interface voltasse.
FIXTrate o desligamento da interface e a desativação das tarefas de desvio/Flowspec/blackhole do lado do SecoManager como uma única ação, não como uma sequência que pode ser interrompida no meio.
2. O bypass em linha sem placa de bypass ainda precisa desassociar os filtros de hardware
SYMPTOMO objeto de proteção foi removido pelo SecoManager, mas o dispositivo ainda parece estar descartando parte do tráfego.
CAUSEOs filtros de hardware são uma vinculação separada do objeto de proteção — remover o objeto de proteção não desassocia automaticamente um filtro de hardware já associado e que está descartando tráfego ativamente.
FIXDesassocie explicitamente cada filtro de hardware em Defesa contra Ataques > Filtro > Filtro de Hardware como um passo próprio, não como um efeito colateral presumido de remover o objeto de proteção.
3. Editar o objeto de proteção padrão afeta todos os IPs que o compartilham
SYMPTOMO comportamento do tráfego muda para serviços diferentes daquele que está sendo solucionado, logo após o objeto de proteção ser editado.
CAUSESe o IP afetado nunca teve seu próprio objeto de proteção dedicado, ele vem compartilhando o padrão junto com qualquer outro IP na mesma situação — desativar ali o desvio automático ou o blackhole automático muda o comportamento de todos eles ao mesmo tempo.
FIXConfirme se o IP afetado tem um objeto de proteção dedicado antes de editar amplamente, e entenda todo o raio de impacto antes de mexer no objeto padrão.
4. A lista negra dinâmica precisa ser limpa por CPU, não uma vez para todo o dispositivo
SYMPTOMreset anti-ddos blacklist foi executado uma vez, mas o mesmo tráfego legítimo continua sendo bloqueado.
CAUSEA lista negra dinâmica é mantida por CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id só limpa a única CPU contra a qual é realmente executado — a lista negra permanece totalmente em vigor em todas as outras CPUs do slot.
FIXRepita o comando de reset para cada CPU no(s) slot(s) relevante(s); uma única execução não equivale a limpar o dispositivo.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// must be repeated for each CPU to fully clear the blacklist5. Interpretar mal falso positivo vs. ataque não detectado desperdiça todo o esforço
SYMPTOMO procedimento de bypass é executado por completo, mas o impacto de negócio subjacente não melhora — ou piora.
CAUSEO bypass é a resposta correta apenas para um falso positivo. Se o tráfego de entrada está realmente elevado e o tráfego após o dispositivo continua elevado, isso é um ataque não detectado — fazer bypass remove a única defesa realmente necessária, em vez de restaurar o tráfego legítimo bloqueado.
FIXConfirme o padrão de tráfego em relação ao diagnóstico de falso positivo/ataque não detectado antes de iniciar o bypass, não depois que ele já estiver em andamento.
Seis perguntas que aparecem sob pressão
As que vale a pena ter uma resposta pronta antes do próximo incidente, não durante ele.
Com que rapidez o bypass deve fazer efeito depois que eu desabilito o desvio em uma implantação fora de linha?
O desligamento da interface em si é quase imediato, mas não interrompe completamente o problema a menos que as tarefas de desvio, Flowspec e blackhole do SecoManager para aquele IP sejam desativadas ao mesmo tempo — trate os quatro passos como uma única ação a executar juntos, não como uma sequência para fazer um de cada vez sob pressão.
Se não houver uma placa de bypass dedicada em uma implantação em linha, o que realmente acontece com o tráfego enquanto eu removo o objeto de proteção?
O dispositivo permanece fisicamente no caminho do tráfego o tempo todo, já que é implantado como Camada 2 transparente em linha — o tráfego continua fluindo por ele durante a mudança. Remover o objeto de proteção, desassociar os filtros de hardware e desativar as tarefas de blackhole/Flowspec tem o objetivo de impedir que o dispositivo aplique lógica de proteção a esse tráfego, não de removê-lo fisicamente do caminho.
Depois do bypass, como confirmo que o tráfego legítimo realmente está fluindo novamente?
Execute novamente as mesmas capturas anteriores à recuperação — tabela de sessões, estatísticas de descarte, estatísticas de packet-trace — e compare com os números de antes do incidente, e confirme separadamente que o próprio negócio afetado está acessível a partir de um cliente real, não apenas que os contadores do próprio dispositivo parecem mais calmos.
É seguro editar o objeto de proteção padrão se outro tráfego também depende dele?
Somente depois de confirmar que é realmente isso que você quer — cada IP sem seu próprio objeto de proteção dedicado compartilha o padrão, então desativar ali o desvio automático ou o blackhole automático afeta todos eles de uma vez, não apenas o IP com problema no momento. Se isso for muito amplo, crie um objeto de proteção dedicado para o IP afetado.
Quanto tempo devo esperar antes de reativar a proteção depois de um bypass, e o que devo verificar primeiro?
Não há um intervalo fixo no manual para isso — a ordem certa é confirmar o que realmente causou o falso positivo (geralmente um limiar desatualizado ou uma mudança de negócio não considerada), ajustar essa política, e só então reativar a proteção durante uma janela de menor risco enquanto se observam novamente os mesmos contadores.
Reiniciamos a lista negra dinâmica em uma CPU e o bloqueio ainda está acontecendo — por quê?
A lista negra é mantida por CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id só limpa a CPU contra a qual é realmente executado, então tem que ser repetido para cada CPU no(s) slot(s) relevante(s) antes que a lista negra realmente desapareça em todo o dispositivo.
Esta nota é construída diretamente a partir do próprio capítulo de recuperação de emergência do manual de solução de problemas do AntiDDoS, cobrindo o caminho rápido de bypass por falso positivo para implantações fora de linha e em linha, e as operações do SecoManager por trás disso. Não cobre o lado do ataque não detectado do mesmo capítulo — habilitar a defesa rapidamente quando um ataque realmente está passando — e não substitui a referência de configuração subjacente do Flowspec ou blackhole. Para os comandos do dia a dia usados para notar primeiro que algo está errado, veja a nota complementar abaixo.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
O AntiDDoS está bloqueando tráfego real agora?
Diga-nos a forma de implantação — fora de linha ou em linha — e se você confirmou falso positivo em vez de ataque não detectado, e ajudamos você a agir rápido.