Um equipamento AntiDDoS que parece totalmente configurado ainda pode deixar um ataque passar direto. Esta é a cadeia de diagnóstico que encontra o porquê, em ordem — se uma tarefa de desvio realmente existe, se o tráfego de ataque ultrapassa o limite de detecção, se o equipamento de detecção ainda está se comunicando com o SecoManager, e o comando display que flagra uma tabela de recursos silenciosamente esgotada por baixo de tudo o mais.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O equipamento está ativo, a política está aplicada, a licença mostra ativa — e o ataque mesmo assim passou. Essa lacuna quase sempre está em um destes quatro pontos específicos.
Uma política de proteção totalmente configurada não garante que o equipamento esteja de fato defendendo um determinado IP neste exato momento. Entre “a política existe” e “o tráfego está sendo limpo” existe uma cadeia de estados que precisa se manter de ponta a ponta: precisa existir uma tarefa de desvio para o IP atacado, o equipamento de detecção precisa ter realmente visto o tráfego de ataque cruzar seu limite, esse equipamento de detecção ainda precisa conseguir avisar o SecoManager, e a própria tabela de recursos do equipamento precisa ter uma entrada livre para guardar o novo estado. Basta um elo fraco e o ataque passa direto, enquanto tudo a montante continua reportando normal.
A seguir está essa cadeia na ordem que vale a pena verificar, os comandos exatos para cada etapa, as cinco causas raiz que aparecem repetidamente depois das primeiras verificações, e respostas de casos reais de campo para situações que não se encaixam claramente em nenhuma etapa.
Quatro elos, verificados de cima para baixo — o primeiro que voltar vazio é onde está o problema real.
Percorra essa cadeia em ordem em vez de pular direto para a verificação da tabela de recursos no final; cada etapa descarta uma categoria inteira de causas antes de passar para a próxima.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Note o que esta cadeia deliberadamente deixa de fora: ela nunca pergunta se a própria política de defesa contra ataques está bem ajustada. Essa pergunta só importa depois que os quatro elos acima forem confirmados intactos — ajustar uma política que nunca recebe tráfego, ou que nunca consegue uma entrada livre na tabela, não muda nada.
Cada etapa tem seu próprio lugar a verificar e seu próprio comando — confirmar uma etapa é a forma mais rápida de descartar tudo o que está por trás dela.
Comece aqui, não na CLI do equipamento — o status de desvio vive do lado do SecoManager, e ele indica qual das próximas etapas realmente se aplica.
<Huawei> display anti-ddos destination-ip ip x.x.x.x
// no entry returned -> this IP's traffic was never mirrored to the detection device
// an entry with zero counters -> traffic is arriving but hasn't crossed threshold yetUma tarefa de desvio só é gerada depois que o próprio equipamento de detecção reporta a anomalia — uma política de defesa perfeitamente configurada a jusante não muda nada se essa etapa nunca disparar.
<Huawei> display interface brief
// confirm the detection interface status is up and is actually receiving mirrored traffic,
// not just physically up with nothing arriving on itO detector pode ver o ataque perfeitamente bem e mesmo assim nunca gerar uma tarefa de desvio se o SecoManager nunca ficar sabendo.
<Huawei> ping -a x.x.x.x(detection device log-port IP) x.x.x.x(SecoManager collector IP)
// unreachable in either direction -> the detector-to-manager channel itself is the fault,
// not the attack-defense configuration on either endEsta é a verificação que flagra a falha sem sintoma óbvio em nenhum outro lugar — tudo a montante reporta normal, e o equipamento mesmo assim não está defendendo.
<Huawei> display anti-ddos resource slot slot-id cpu cpu-id
// check the free column for the resource item this attack/IP needs
// free = 0 -> defense for anything new on this resource stops here, regardless of policy
<Huawei> display cpu-usage slot slot-id cpu cpu-id
<Huawei> display ddos slot
// cross-check: is the SPU CPU actually registered, and how loaded is it right nowDepois que a cadeia de quatro etapas acima indicar onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SYMPTOMdisplay anti-ddos destination-ip ip x.x.x.x não retorna nenhuma entrada de monitoramento para o endereço atacado, mesmo que a política de defesa e o objeto de proteção pareçam corretamente configurados.
CAUSEO desvio depende inteiramente de o equipamento de detecção ver o tráfego deste IP em primeiro lugar. Se a configuração de espelhamento ou desvio do roteador a montante não incluir de fato o tráfego deste endereço — um erro de escopo, não um erro do AntiDDoS — o equipamento nunca tem a chance de medi-lo, muito menos de compará-lo com um limite.
FIXVerifique a configuração de espelhamento/desvio no roteador que alimenta o equipamento de detecção em relação à documentação do produto para essa configuração de interface, antes de mexer em qualquer coisa dentro da própria política do AntiDDoS.
SYMPTOMA tarefa de desvio existe, o limite de detecção claramente foi ultrapassado, o canal para o SecoManager está normal — e o ataque mesmo assim não está sendo limpo.
CAUSEdisplay anti-ddos resource mostra a coluna free do item de recurso correspondente em 0. O equipamento ficou sem espaço para instalar novo estado de defesa, e isso não se anuncia como uma falha de hardware ou o vencimento de uma licença faria — simplesmente limita silenciosamente o que o equipamento consegue proteger a partir daquele ponto.
FIXTorne o display anti-ddos resource um passo padrão nesta lista de verificação, não um último recurso. Se free estiver em 0, a correção é capacidade e limpeza naquele item de recurso, não outra olhada na configuração da política.
<Huawei> display anti-ddos resource
// free column at 0 for the resource item this attack needs -> defense stops here
// regardless of how correctly everything upstream is configuredSYMPTOMdisplay ddos slot mostra a CPU como não registrada, e a defesa simplesmente nunca entra em ação naquela placa, não importa o que a política diga.
CAUSEUma CPU de detecção ou limpeza não registrada não consegue executar as funções de defesa de forma alguma. Isso muitas vezes é um problema de licença por trás — uma licença em estado Trial (ESN incompatível), uma licença vencida, ou uma licença que caiu em estado Default — em vez de algo errado com a própria CPU.
FIXVerifique primeiro display license. Se o estado não for Normal, resolver a licença é a correção real; registrar manualmente a CPU com o tipo correto só faz sentido depois que a própria licença estiver saudável.
<Huawei> display ddos slot
// CPU not registered -> check License state before anything else
<Huawei> display license
// License state should read Normal; Trial / Default / expired all block real defense capacity
[Huawei] firewall ddos detect-spu slot x cpu x
// specifies the CPU type once the License itself is confirmed healthySYMPTOMdisplay health mostra que a utilização da CPU da placa SPU já está em ou acima de 95%, e a qualidade da defesa se degrada sob uma carga que um equipamento saudável absorveria normalmente.
CAUSEUma CPU de SPU saturada não consegue acompanhar a instalação de novo estado ou a inspeção por pacote no ritmo que o ataque exige, independentemente de a própria tabela de recursos ainda ter entradas livres.
FIXComo medida imediata, configure um buraco negro no roteador a montante para o único IP atacado mais prejudicial, para proteger a folga de CPU para tudo o mais que está sendo defendido. Peça à operadora a montante para aplicar limitação de taxa ou filtragem de protocolo contra o ataque em sua borda. Como correção estrutural, considere adicionar placas SPU para elevar o teto do equipamento.
SYMPTOMO tráfego de negócio cai visivelmente logo depois de passar pelo equipamento AntiDDoS, ou o tráfego de negócio dispara e continua sendo encaminhado no mesmo volume elevado sem redução visível.
CAUSEEsses são dois problemas diferentes que, por engano, acabam sendo perseguidos com os mesmos passos de solução. Uma queda em relação a uma linha de base normalmente estável, que aparece só depois do equipamento, aponta para um bloqueio falso (tráfego legítimo pego por uma política rígida demais). Um pico claro acima da linha de base que continua sendo encaminhado em volume quase total depois do equipamento aponta para um ataque não detido (uma brecha de proteção) — é nesse caso que se deve rodar a cadeia de quatro etapas acima.
FIXClassifique primeiro qual formato você está vendo antes de abrir qualquer configuração. Um bloqueio falso se corrige afrouxando a regra de política específica que está disparando em excesso; um ataque não detido se corrige trabalhando a cadeia de desvio-limite-comunicação-recurso, não apertando ainda mais a política.
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Não necessariamente todo o equipamento — os itens de recurso são rastreados separadamente, e um chassi com várias placas SPU pode ser verificado por slot e por CPU com display anti-ddos resource slot slot-id cpu cpu-id. O que isso realmente significa é que aquele item de recurso específico em 0 não consegue aceitar novo estado, o que já basta para explicar por que um ataque ou IP específico não está sendo defendido enquanto outros ainda estão.
Olhe primeiro a linha de base. Se o tráfego de negócio estava estável antes do equipamento e só cai depois dele, sem nenhum pico correspondente em qualquer lugar a montante, isso é um bloqueio falso — tráfego legítimo está sendo pego por uma regra de política agressiva demais. Se o tráfego já estava visivelmente elevado acima do normal antes de chegar ao equipamento, uma queda depois do equipamento é exatamente como uma limpeza correta deve parecer.
Confirme se o IP de destino realmente tem um objeto de proteção criado e implantado no equipamento, não apenas configurado em algum lugar do SecoManager. Se o IP nunca foi implantado no próprio equipamento, o equipamento nunca faz estatísticas de tráfego para esse endereço — naturalmente não há dados de tráfego para disparar nada, não importa quão correto seja o resto da configuração.
Sim, diretamente. O estado Trial na maioria das vezes significa que a licença foi ativada com um ESN que não corresponde ao equipamento, e está limitada a 60 dias de uso. Um equipamento rodando com uma licença Trial ou vencida pode cair em estado Default, o que interrompe a função de negócio de vez em vez de apenas degradá-la. Solicitar novamente e reativar uma licença compatível com o ESN correto é a única correção real — não há solução de contorno por configuração para um problema de estado de licença.
Duas causas habituais superam um valor de limite mal ajustado: a interface de detecção na verdade não está recebendo o tráfego espelhado para aquele IP específico (verifique primeiro display interface brief e a configuração de espelhamento), ou a própria entrada de monitoramento do IP de destino nunca foi criada porque o endereço nunca foi implantado como objeto de proteção. Confirme que o tráfego está chegando antes de supor que o próprio número do limite precisa mudar.
Esta nota se baseia na família de equipamentos Huawei AntiDDoS gerenciada pelo SecoManager, e na lista de verificação de campo por trás do seu comportamento de desvio, detecção, comunicação e tabela de recursos. Ela assume uma implantação gerenciada pelo SecoManager com limpeza baseada em desvio; uma implantação autônoma ou em modo bypass segue uma lista de verificação relacionada, mas não idêntica. Não cobre em profundidade a configuração específica de FlowSpec ou desvio BGP, nem o vínculo de limpeza em nuvem para ataques que ultrapassam totalmente a capacidade local.
Conte-nos qual etapa da cadeia voltou vazia — desvio, limite, comunicação, ou a tabela de recursos — junto com a saída de display anti-ddos resource, e ajudamos você a interpretá-la.