Lorsque l'appareil AntiDDoS lui-même est devenu la panne — bloquant du trafic métier réel au lieu de le protéger — voici le chemin de retour rapide : distinguer d'abord un faux positif d'une attaque manquée, la capture diagnostique à effectuer avant de toucher à quoi que ce soit, la procédure de contournement pour les déploiements hors chemin et en ligne, comment confirmer que cela a réellement fonctionné, et l'ajustement des seuils qui empêche que cela se reproduise.
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
Un dispositif de nettoyage DDoS qui bloque de vrais clients est une panne auto-infligée — et elle exige une réponse plus rapide et plus calme qu'une véritable attaque.
Un appareil AntiDDoS qui commence à rejeter du trafic légitime est une urgence en soi : l'impact métier ressemble en tout point à une panne, mais la solution n'est pas une réparation réseau — c'est reconnaître que la propre politique de défense de l'appareil est devenue le problème, et la défaire rapidement et correctement. Actionner d'abord le mauvais levier (ou actionner le bon levier sans vérifier ce qui ne va vraiment pas) fait perdre exactement les minutes qui comptent.
Voici cette réponse, directement issue du manuel de récupération d'urgence AntiDDoS : comment distinguer cela d'une attaque réellement en train de passer, les informations à recueillir avant de toucher à quoi que ce soit, la procédure de contournement elle-même pour les deux formes de déploiement courantes, comment confirmer que cela a réellement fonctionné, et l'ajustement qui empêche que cela se reproduise.
Le contournement est la bonne réponse à exactement l'un de ces deux cas — faites ce choix correctement avant toute autre chose.
| Modèle de trafic | Diagnostic |
|---|---|
| Le trafic entrant n'a pas augmenté sensiblement par rapport à la normale, mais le trafic sortant de l'autre côté de l'appareil AntiDDoS a nettement diminué. | Faux positif (误防) — la propre politique de l'appareil bloque un trafic qui n'a jamais été une attaque. Cette note s'applique : passez au contournement. |
| Le trafic entrant a nettement augmenté par rapport à la normale, et le trafic sortant de l'autre côté reste bien plus élevé que la normale. | Attaque manquée (漏防) — l'attaque passe, elle n'est pas bloquée. Contourner l'appareil ici supprime la seule défense en place ; la bonne réponse est d'activer la défense plus vite, pas de la contourner. |
Se tromper dans ce diagnostic, dans un sens ou dans l'autre, fait perdre les minutes qui comptent — contourner pendant une attaque réelle, ou chercher un trafic d'attaque qui n'a jamais existé, retardent tous deux la correction réellement nécessaire.
Six commandes, exécutées avant la récupération — le dossier dont vous aurez besoin une fois la pression retombée.
| Command | What it captures |
|---|---|
| collect diagnostic information | Le pack complet d'informations de diagnostic pour cet incident. |
| display firewall statistic system discard | Statistiques de rejet de paquets à l'échelle du système — ce qui est réellement rejeté et où. |
| display anti-ddos packet-trace statistic | Statistiques de rejet spécifiques au traitement AntiDDoS — séparant ses rejets des rejets ordinaires du pare-feu. |
| display cpu-usage slot slot-id cpu cpu-id | L'utilisation CPU de la carte SPU au moment de l'incident. |
| display anti-ddos resource slot slot-id cpu cpu-id | Utilisation de la table de ressources — si une table est proche de sa capacité indépendamment de toute attaque. |
| display firewall session table verbose | Utilisation de la table de sessions au moment de l'incident, pour comparaison avec l'état après contournement. |
Les déploiements hors chemin et en ligne échouent différemment, donc le chemin de retour le plus rapide diffère aussi.
Dans cette forme de déploiement, le trafic n'est détourné vers l'appareil AntiDDoS que lorsque quelque chose semble anormal — couper le détournement est donc le levier le plus rapide, mais ce n'est pas le seul à actionner.
[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/64Dans cette forme de déploiement, l'appareil se trouve physiquement dans le chemin du trafic en mode Couche 2 transparent, donc le chemin de récupération dépend du type de matériel de contournement réellement présent.
Même objectif, mécanique différente — car le trafic atteint l'appareil différemment selon le déploiement.
Les légendes du schéma restent en anglais pour la clarté technique.
Le contournement arrête l'hémorragie — il ne corrige pas la raison pour laquelle le faux positif s'est produit en premier lieu.
[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 questionChacun de ces pièges a coûté à quelqu'un un temps de récupération réel.
SYMPTOML'interface de détournement est arrêtée sur l'appareil, mais le trafic concerné semble toujours détourné ou bloqué.
CAUSELes tâches de détournement, Flowspec et trou noir résident dans SecoManager, indépendamment de l'état de l'interface elle-même — arrêter l'interface empêche le trafic d'atteindre physiquement l'appareil par ce chemin, mais ne désactive pas les tâches qui le redétourneraient dès le retour de l'interface.
FIXTraitez l'arrêt de l'interface et la désactivation des tâches de détournement/Flowspec/trou noir côté SecoManager comme une seule et même action, pas une séquence qu'on peut arrêter à mi-chemin.
SYMPTOML'objet de protection a été supprimé via SecoManager, mais l'appareil semble toujours rejeter une partie du trafic.
CAUSELes filtres matériels constituent une liaison distincte de l'objet de protection — supprimer l'objet de protection ne détache pas automatiquement un filtre matériel déjà associé et rejetant activement du trafic.
FIXDissociez explicitement chaque filtre matériel sous Défense contre les attaques > Filtre > Filtre matériel comme une étape à part entière, pas un effet secondaire supposé de la suppression de l'objet de protection.
SYMPTOMLe comportement du trafic change pour des services autres que celui en cours de dépannage, juste après la modification de l'objet de protection.
CAUSESi l'IP concernée n'a jamais eu son propre objet de protection dédié, elle a partagé l'objet par défaut avec toutes les autres IP dans la même situation — désactiver le détournement automatique ou le trou noir automatique change alors le comportement de toutes en même temps.
FIXConfirmez si l'IP concernée dispose d'un objet de protection dédié avant de modifier largement, et comprenez tout le rayon d'impact avant de toucher à l'objet par défaut.
SYMPTOMreset anti-ddos blacklist a été exécuté une fois, mais le même trafic légitime continue d'être bloqué.
CAUSELa liste noire dynamique est maintenue par CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id n'efface que le seul CPU sur lequel elle est réellement exécutée — la liste noire reste pleinement en vigueur sur tous les autres CPU de l'emplacement.
FIXRépétez la commande de réinitialisation pour chaque CPU du ou des emplacements concernés ; une seule exécution n'équivaut pas à effacer l'appareil.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// must be repeated for each CPU to fully clear the blacklistSYMPTOMLa procédure de contournement est exécutée intégralement, mais l'impact métier sous-jacent ne s'améliore pas — ou empire.
CAUSELe contournement est la bonne réponse uniquement à un faux positif. Si le trafic entrant est réellement élevé et que le trafic après l'appareil reste élevé, c'est une attaque manquée — contourner supprime la seule défense réellement nécessaire, au lieu de restaurer le trafic légitime bloqué.
FIXConfirmez le modèle de trafic par rapport au diagnostic faux positif/attaque manquée avant de démarrer le contournement, pas après qu'il soit déjà en cours.
Celles qui méritent une réponse toute prête avant le prochain incident, pas pendant.
L'arrêt de l'interface lui-même est quasi immédiat, mais il n'arrête pas complètement le problème sauf si les tâches de détournement, Flowspec et trou noir de SecoManager pour cette IP sont désactivées en même temps — traitez ces quatre étapes comme une seule action à exécuter ensemble, pas une séquence à parcourir une par une sous la pression.
L'appareil reste physiquement dans le chemin du trafic pendant toute la durée, puisqu'il est déployé en Couche 2 transparente en ligne — le trafic continue de le traverser pendant le changement. Supprimer l'objet de protection, dissocier les filtres matériels et désactiver les tâches trou noir/Flowspec vise à empêcher l'appareil d'appliquer une logique de protection à ce trafic, pas à le retirer physiquement du chemin.
Relancez les mêmes captures d'avant récupération — table de sessions, statistiques de rejet, statistiques packet-trace — et comparez-les aux chiffres d'avant l'incident, et confirmez séparément que le service concerné est joignable depuis un vrai client, pas seulement que les compteurs de l'appareil semblent plus calmes.
Seulement une fois que vous avez confirmé que c'est réellement ce que vous voulez — chaque IP sans son propre objet de protection dédié partage l'objet par défaut, donc désactiver le détournement automatique ou le trou noir automatique y affecte toutes en même temps, pas seulement l'IP actuellement en difficulté. Si c'est trop large, créez plutôt un objet de protection dédié pour l'IP concernée.
Le manuel ne donne pas d'intervalle fixe pour cela — le bon ordre consiste à confirmer ce qui a réellement causé le faux positif (généralement un seuil obsolète ou un changement d'activité non pris en compte), à ajuster cette politique, et alors seulement à réactiver la protection pendant une fenêtre à moindre risque en surveillant à nouveau les mêmes compteurs.
La liste noire est maintenue par CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id n'efface que le CPU sur lequel elle est réellement exécutée, il faut donc la répéter pour chaque CPU du ou des emplacements concernés avant que la liste noire ne disparaisse réellement à l'échelle de l'appareil.
Cette note est construite directement à partir du propre chapitre de récupération d'urgence du manuel de dépannage AntiDDoS, couvrant le chemin de contournement rapide pour faux positif pour les déploiements hors chemin et en ligne ainsi que les opérations SecoManager sous-jacentes. Elle ne couvre pas le volet attaque manquée du même chapitre — activer rapidement la défense lorsqu'une attaque passe réellement — et ne remplace pas la référence de configuration Flowspec ou trou noir sous-jacente. Pour les commandes du quotidien utilisées pour d'abord remarquer qu'un problème existe, voir la note complémentaire ci-dessous.
Indiquez-nous la forme de déploiement — hors chemin ou en ligne — et si vous avez confirmé un faux positif plutôt qu'une attaque manquée, et nous vous aiderons à agir vite.