Un équipement AntiDDoS qui semble entièrement configuré peut quand même laisser passer une attaque de bout en bout. Voici la chaîne de diagnostic qui trouve pourquoi, dans l'ordre — une tâche de détournement existe-t-elle réellement, le trafic d'attaque franchit-il le seuil de détection, l'équipement de détection communique-t-il encore avec SecoManager, et la commande display qui révèle une table de ressources discrètement épuisée sous tout le reste.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
L'équipement est actif, la politique est appliquée, la licence est active — et l'attaque est quand même passée. Cet écart se trouve presque toujours dans l'un de ces quatre points précis.
Une politique de protection entièrement configurée ne garantit pas que l'équipement défend réellement une adresse IP donnée à cet instant précis. Entre « la politique existe » et « le trafic est en cours de nettoyage » se trouve une chaîne d'états qui doit tenir de bout en bout : une tâche de détournement doit exister pour l'IP attaquée, l'équipement de détection doit avoir réellement vu le trafic d'attaque franchir son seuil, cet équipement doit encore pouvoir en informer SecoManager, et la table de ressources de l'équipement doit conserver une entrée libre pour héberger le nouvel état. Un seul maillon faible et l'attaque passe directement, alors que tout en amont continue d'afficher du vert.
Voici cette chaîne dans l'ordre où il vaut la peine de la vérifier, les commandes exactes pour chaque étape, les cinq causes profondes qui reviennent sans cesse une fois passées les premières vérifications, et des réponses de terrain pour les situations qui ne rentrent proprement dans aucune étape.
Quatre maillons, vérifiés de haut en bas — le premier qui revient vide indique où se trouve le vrai problème.
Parcourez cette chaîne dans l'ordre plutôt que de sauter directement à la vérification de la table de ressources tout en bas ; chaque étape écarte toute une catégorie de causes avant de passer à la suivante.
Les légendes du schéma restent en anglais pour la clarté technique.
Remarquez ce que cette chaîne omet délibérément : elle ne demande jamais si la politique de défense contre les attaques est bien réglée. Cette question ne compte qu'une fois les quatre maillons ci-dessus confirmés intacts — ajuster une politique qui ne reçoit jamais de trafic, ou qui n'obtient jamais d'entrée libre dans la table, ne change rien.
Chaque étape a son propre endroit à examiner et sa propre commande — confirmer une étape est le moyen le plus rapide d'écarter tout ce qui la sous-tend.
Commencez ici, pas dans la CLI de l'équipement — le statut de détournement se trouve côté SecoManager, et il indique laquelle des étapes suivantes s'applique réellement.
<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 yetUne tâche de détournement n'est générée qu'une fois que l'équipement de détection lui-même signale l'anomalie — une politique de défense parfaitement configurée en aval ne change rien si cette étape ne se déclenche jamais.
<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 itLe détecteur peut parfaitement voir l'attaque et ne jamais générer de tâche de détournement si SecoManager n'en est jamais informé.
<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 endC'est la vérification qui détecte la panne sans symptôme évident ailleurs — tout en amont indique que ça va, et l'équipement ne défend toujours pas.
<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 nowUne fois que la chaîne en quatre étapes ci-dessus vous a indiqué où se situe le problème, ces cinq causes expliquent la plupart de ce qui ne va vraiment pas.
SYMPTOMdisplay anti-ddos destination-ip ip x.x.x.x ne renvoie aucune entrée de surveillance pour l'adresse attaquée, alors même que la politique de défense et l'objet de protection semblent tous deux correctement configurés.
CAUSELe détournement dépend entièrement du fait que l'équipement de détection voie d'abord le trafic de cette IP. Si la configuration de miroir ou de détournement du routeur en amont n'inclut en réalité pas le trafic de cette adresse — une erreur de périmètre, pas une erreur AntiDDoS — l'équipement n'a jamais l'occasion de le mesurer, encore moins de le comparer à un seuil.
FIXVérifiez la configuration de miroir/détournement sur le routeur alimentant l'équipement de détection en la comparant à la documentation produit de cette configuration d'interface, avant de toucher quoi que ce soit dans la politique AntiDDoS elle-même.
SYMPTOMLa tâche de détournement existe, le seuil de détection a clairement été franchi, le canal vers SecoManager fonctionne — et l'attaque n'est toujours pas nettoyée.
CAUSEdisplay anti-ddos resource montre la colonne free de l'élément de ressource concerné à 0. L'équipement n'a plus de place pour installer un nouvel état de défense, et cela ne se manifeste pas comme le ferait une panne matérielle ou une expiration de licence — cela plafonne simplement et discrètement ce que l'équipement peut protéger à partir de ce moment.
FIXFaites de display anti-ddos resource une étape standard de cette liste de vérification, pas un dernier recours. Si free est à 0, la correction porte sur la capacité et le nettoyage de cet élément de ressource, pas sur un nouveau regard sur la configuration de la politique.
<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 montre le CPU comme non enregistré, et la défense ne s'active tout simplement jamais sur cette carte, quoi que dise la politique.
CAUSEUn CPU de détection ou de nettoyage non enregistré ne peut absolument pas exécuter les fonctions de défense. C'est très souvent un problème de licence sous-jacent — une licence en état Trial (ESN non concordant), une licence expirée, ou une licence tombée en état Default — plutôt qu'un défaut du CPU lui-même.
FIXVérifiez d'abord display license. Si l'état n'est pas Normal, résoudre la licence est la vraie correction ; enregistrer manuellement le CPU avec le bon type n'a de sens qu'une fois la licence elle-même saine.
<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 montre l'utilisation du CPU de la carte SPU déjà à 95 % ou plus, et la qualité de la défense se dégrade sous une charge qu'un équipement sain absorberait normalement.
CAUSEUn CPU SPU saturé ne peut pas suivre l'installation de nouveaux états ou l'inspection paquet par paquet au rythme exigé par l'attaque, indépendamment du fait que la table de ressources elle-même dispose encore d'entrées libres.
FIXEn mesure immédiate, configurez un trou noir sur le routeur en amont pour la seule IP attaquée la plus dommageable, afin de préserver la marge CPU pour tout ce qui est encore défendu. Demandez à l'opérateur en amont d'appliquer une limitation de débit ou un filtrage de protocole contre l'attaque à sa bordure. Comme correction structurelle, envisagez d'ajouter des cartes SPU pour relever le plafond de l'équipement.
SYMPTOMLe trafic métier chute nettement juste après avoir traversé l'équipement AntiDDoS, ou le trafic métier bondit et continue d'être transféré au même volume élevé sans réduction visible.
CAUSECe sont deux problèmes différents que l'on poursuit par erreur avec les mêmes étapes de dépannage. Une baisse par rapport à une ligne de base par ailleurs stable, apparaissant uniquement après l'équipement, pointe vers un blocage abusif (trafic légitime pris par une politique trop stricte). Un pic net au-dessus de la ligne de base qui continue d'être transféré à presque plein volume après l'équipement pointe vers une attaque manquée (une fuite de protection) — c'est dans ce cas qu'il faut exécuter la chaîne en quatre étapes ci-dessus.
FIXClassez d'abord quelle forme vous observez avant d'ouvrir la moindre configuration. Un blocage abusif se corrige en assouplissant la règle de politique précise qui se déclenche trop, une attaque manquée se corrige en travaillant la chaîne détournement-seuil-communication-ressource, pas en resserrant davantage la politique.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Pas nécessairement tout l'équipement — les éléments de ressource sont suivis séparément, et un châssis à plusieurs cartes SPU peut être vérifié par emplacement et par CPU avec display anti-ddos resource slot slot-id cpu cpu-id. Cela signifie en revanche que l'élément de ressource spécifique affichant 0 ne peut plus accepter de nouvel état, ce qui suffit à lui seul à expliquer pourquoi une attaque ou une IP particulière n'est pas défendue alors que d'autres le sont encore.
Regardez d'abord la ligne de base. Si le trafic métier était stable avant l'équipement et ne chute qu'après, sans pic correspondant nulle part en amont, c'est un blocage abusif — du trafic légitime est capturé par une règle de politique trop agressive. Si le trafic était déjà visiblement élevé par rapport à la normale avant d'atteindre l'équipement, une baisse après l'équipement est exactement à quoi ressemble un nettoyage correct.
Confirmez que l'IP de destination dispose bien d'un objet de protection créé et déployé sur l'équipement, pas seulement configuré quelque part dans SecoManager. Si l'IP n'a jamais été déployée sur l'équipement lui-même, celui-ci n'effectue jamais de statistiques de trafic pour cette adresse — il n'y a naturellement aucune donnée de trafic pour déclencher quoi que ce soit, quelle que soit la justesse du reste de la configuration.
Oui, directement. L'état Trial signifie le plus souvent que la licence a été activée avec un ESN qui ne correspond pas à l'équipement, et elle est plafonnée à 60 jours d'utilisation. Un équipement fonctionnant avec une licence Trial ou expirée peut tomber en état Default, ce qui interrompt franchement la fonction métier plutôt que de simplement la dégrader. Redemander et réactiver une licence correspondant au bon ESN est la seule vraie correction — il n'existe aucune solution de contournement par configuration pour un problème d'état de licence.
Deux causes habituelles priment sur une valeur de seuil mal réglée : l'interface de détection ne reçoit en réalité pas du tout le trafic mirroré pour cette IP spécifique (vérifiez d'abord display interface brief et la configuration du miroir), ou l'entrée de surveillance de l'IP de destination elle-même n'a jamais été créée parce que l'adresse n'a jamais été déployée comme objet de protection. Confirmez que le trafic arrive avant de supposer que la valeur du seuil elle-même doit changer.
Cette note s'appuie sur la famille d'équipements Huawei AntiDDoS gérée via SecoManager, et sur la liste de vérification de terrain derrière son comportement de détournement, détection, communication et table de ressources. Elle suppose un déploiement géré par SecoManager avec nettoyage basé sur le détournement ; un déploiement autonome ou en mode bypass suit une liste de vérification apparentée mais non identique. Elle ne couvre pas en profondeur la configuration spécifique FlowSpec ou détournement BGP, ni la liaison de nettoyage cloud pour les attaques dépassant entièrement la capacité locale.
Dites-nous quelle étape de la chaîne est revenue vide — détournement, seuil, communication, ou table de ressources — avec la sortie de display anti-ddos resource, et nous vous aiderons à l'interpréter.