Cuando el propio dispositivo AntiDDoS se ha convertido en la interrupción — bloqueando tráfico de negocio real en lugar de protegerlo — este es el camino rápido de vuelta: distinguir primero un falso positivo de un ataque no detectado, la captura de diagnóstico a realizar antes de tocar nada, el procedimiento de bypass para despliegues fuera de línea y en línea, cómo confirmar que realmente funcionó, y el ajuste de umbrales que evita que vuelva a suceder.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Un depurador DDoS que bloquea a clientes reales es una interrupción autoinfligida — y requiere una respuesta más rápida y serena que un ataque real.
Un dispositivo AntiDDoS que empieza a descartar tráfico legítimo es una emergencia en sí misma: el impacto en el negocio se ve idéntico a una interrupción, pero la solución no es una reparación de red — es reconocer que la propia política de defensa del dispositivo se ha convertido en el problema, y deshacerla rápida y correctamente. Accionar primero la palanca equivocada (o accionar la correcta sin verificar qué está realmente mal) desperdicia justamente los minutos que importan.
A continuación está esa respuesta, directamente del manual de recuperación de emergencia de AntiDDoS: cómo distinguir esto de un ataque que realmente está pasando, la información que vale la pena capturar antes de tocar nada, el propio procedimiento de bypass para las dos formas de despliegue habituales, cómo confirmar que realmente funcionó, y el ajuste que evita que vuelva a suceder.
El bypass es la respuesta correcta exactamente para uno de estos dos casos — acierte con este diagnóstico antes de hacer cualquier otra cosa.
| Patrón de tráfico | Diagnóstico |
|---|---|
| El tráfico entrante no ha aumentado notablemente respecto a lo normal, pero el tráfico que sale al otro lado del dispositivo AntiDDoS ha caído notablemente. | Falso positivo (误防) — la propia política del dispositivo está bloqueando tráfico que nunca fue realmente un ataque. Esta nota aplica: proceda al bypass. |
| El tráfico entrante ha aumentado notablemente respecto a lo normal, y el tráfico que sale al otro lado sigue siendo mucho mayor de lo normal. | Ataque no detectado (漏防) — el ataque está pasando, no está siendo bloqueado. Hacer bypass del dispositivo aquí elimina la única defensa existente; la respuesta correcta es activar la defensa más rápido, no evitarla. |
Equivocarse en este diagnóstico en cualquier dirección quema los minutos que importan — hacer bypass durante un ataque real, o buscar tráfico de ataque que nunca existió, ambos retrasan la corrección realmente necesaria.
Seis comandos, ejecutados antes de la recuperación — el registro que querrá tener una vez que la presión haya pasado.
| Command | What it captures |
|---|---|
| collect diagnostic information | El paquete completo de información de diagnóstico para este incidente. |
| display firewall statistic system discard | Estadísticas de descarte de paquetes en todo el sistema — qué se está descartando realmente y dónde. |
| display anti-ddos packet-trace statistic | Estadísticas de descarte específicas del procesamiento AntiDDoS — separando sus descartes de los descartes ordinarios del firewall. |
| display cpu-usage slot slot-id cpu cpu-id | El uso de CPU de la tarjeta SPU en el momento del incidente. |
| display anti-ddos resource slot slot-id cpu cpu-id | Uso de la tabla de recursos — si una tabla está cerca de su capacidad independientemente de cualquier ataque. |
| display firewall session table verbose | Uso de la tabla de sesiones en el momento del incidente, para comparar con el estado posterior al bypass. |
Los despliegues fuera de línea y en línea fallan de manera distinta, así que la forma más rápida de volver también difiere.
En esta forma de despliegue, el tráfico se desvía hacia el dispositivo AntiDDoS solo cuando algo parece estar mal — así que cortar el desvío es la palanca más rápida, pero no es la única que hay que accionar.
[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/64En esta forma de despliegue, el dispositivo se encuentra físicamente en la ruta del tráfico en modo de Capa 2 transparente, así que la ruta de recuperación depende de qué tipo de hardware de bypass está realmente presente.
Mismo objetivo, mecánica distinta — porque el tráfico llega al dispositivo de manera diferente en cada despliegue.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
El bypass detiene la hemorragia — no corrige por qué ocurrió el falso positivo en primer lugar.
[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 questionCada uno de estos le ha costado a alguien tiempo real de recuperación.
SYMPTOMLa interfaz orientada al desvío está cerrada en el dispositivo, pero el tráfico afectado parece seguir siendo desviado o bloqueado.
CAUSELas tareas de desvío, Flowspec y blackhole residen en SecoManager, independientemente del estado de la propia interfaz — cerrar la interfaz impide que el tráfico llegue físicamente al dispositivo por esa ruta, pero no desactiva las tareas que volverían a desviarlo en cuanto la interfaz vuelva.
FIXTrate el cierre de la interfaz y la desactivación de las tareas de desvío/Flowspec/blackhole en SecoManager como una sola acción, no como una secuencia que se puede detener a mitad de camino.
SYMPTOMEl objeto de protección se eliminó a través de SecoManager, pero el dispositivo aún parece estar descartando parte del tráfico.
CAUSELos filtros de hardware son una vinculación separada del objeto de protección — eliminar el objeto de protección no desvincula automáticamente un filtro de hardware ya asociado y que está descartando tráfico activamente.
FIXDesasocie explícitamente cada filtro de hardware en Defensa contra ataques > Filtro > Filtro de hardware como un paso propio, no como un efecto secundario asumido de eliminar el objeto de protección.
SYMPTOMEl comportamiento del tráfico cambia para servicios distintos al que se está resolviendo, justo después de editar el objeto de protección.
CAUSESi la IP afectada nunca tuvo su propio objeto de protección dedicado, ha estado compartiendo el predeterminado junto con cualquier otra IP en la misma situación — desactivar allí el desvío automático o el blackhole automático cambia el comportamiento de todas ellas a la vez.
FIXConfirme si la IP afectada tiene un objeto de protección dedicado antes de editar ampliamente, y comprenda todo el radio de impacto antes de tocar el objeto predeterminado.
SYMPTOMreset anti-ddos blacklist se ejecutó una vez, pero el mismo tráfico legítimo sigue siendo bloqueado.
CAUSELa lista negra dinámica se mantiene por CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id solo borra la CPU sobre la que realmente se ejecuta — la lista negra sigue plenamente vigente en todas las demás CPU de la ranura.
FIXRepita el comando de reinicio para cada CPU en la(s) ranura(s) relevante(s); una sola ejecución no equivale a borrar el dispositivo.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// must be repeated for each CPU to fully clear the blacklistSYMPTOMEl procedimiento de bypass se ejecuta por completo, pero el impacto de negocio subyacente no mejora — o empeora.
CAUSEEl bypass es la respuesta correcta solo para un falso positivo. Si el tráfico entrante está realmente elevado y el tráfico tras el dispositivo sigue elevado, eso es un ataque no detectado — hacer bypass elimina la única defensa realmente necesaria, en lugar de restaurar el tráfico legítimo bloqueado.
FIXConfirme el patrón de tráfico contra el diagnóstico de falso positivo/ataque no detectado antes de iniciar el bypass, no después de que ya esté en marcha.
Las que vale la pena tener respondidas antes del próximo incidente, no durante él.
El cierre de la interfaz en sí es casi inmediato, pero no detiene completamente el problema a menos que las tareas de desvío, Flowspec y blackhole de SecoManager para esa IP se desactiven al mismo tiempo — trate los cuatro pasos como una sola acción a ejecutar juntos, no como una secuencia para hacer uno a la vez bajo presión.
El dispositivo permanece físicamente en la ruta del tráfico todo el tiempo, ya que se despliega como Capa 2 transparente en línea — el tráfico sigue fluyendo a través de él durante el cambio. Eliminar el objeto de protección, desasociar los filtros de hardware y desactivar las tareas de blackhole/Flowspec busca impedir que el dispositivo aplique lógica de protección a ese tráfico, no retirarlo físicamente de la ruta.
Vuelva a ejecutar las mismas capturas previas a la recuperación — tabla de sesiones, estadísticas de descarte, estadísticas de packet-trace — y compárelas con los números de antes del incidente, y confirme por separado que el negocio afectado es alcanzable desde un cliente real, no solo que los contadores del propio dispositivo se ven más tranquilos.
Solo una vez que haya confirmado que eso es realmente lo que quiere — cada IP sin su propio objeto de protección dedicado comparte el predeterminado, así que desactivar allí el desvío automático o el blackhole automático afecta a todas a la vez, no solo a la IP con problemas actualmente. Si eso es demasiado amplio, cree en su lugar un objeto de protección dedicado para la IP afectada.
No hay un intervalo fijo en el manual para esto — el orden correcto es confirmar qué causó realmente el falso positivo (generalmente un umbral obsoleto o un cambio de negocio no contemplado), ajustar esa política, y solo entonces volver a habilitar la protección durante una ventana de menor riesgo mientras se vigilan de nuevo los mismos contadores.
La lista negra se mantiene por CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id solo borra la CPU sobre la que realmente se ejecuta, así que hay que repetirlo para cada CPU en la(s) ranura(s) relevante(s) antes de que la lista negra desaparezca realmente en todo el dispositivo.
Esta nota se construye directamente a partir del propio capítulo de recuperación de emergencia del manual de resolución de problemas de AntiDDoS, cubriendo la ruta rápida de bypass por falso positivo para despliegues fuera de línea y en línea, y las operaciones de SecoManager detrás de ella. No cubre el lado del ataque no detectado del mismo capítulo — habilitar la defensa rápidamente cuando un ataque realmente está pasando — y no sustituye la referencia de configuración subyacente de Flowspec o blackhole. Para los comandos diarios usados para notar primero que algo está mal, vea la nota complementaria a continuación.
Díganos la forma de despliegue — fuera de línea o en línea — y si ha confirmado falso positivo en lugar de ataque no detectado, y le ayudamos a actuar rápido.