Mantenimiento de emergencia del WAF: procedimientos de bypass para cada modo de despliegue

El bypass correcto depende del modo de despliegue

Antes de tocar cualquier configuración bajo presión, confirme cuál de los cuatro modos de despliegue está realmente usando — la mecánica de bypass nunca es la misma entre dos de ellos.

Que una falla del WAF pueda tumbar el negocio que protege, y lo que «bypass» siquiera significa para solucionarlo, depende por completo de si el dispositivo está en línea en la ruta del tráfico o solo observa una copia espejo de este. El proxy transparente, el proxy inverso y el modo puente están todos en línea — una falla ahí realmente detiene el tráfico, y cada uno tiene su propia mecánica de recuperación de emergencia. El modo de monitoreo fuera de ruta (bypass) no está en línea en absoluto, por lo que una falla del dispositivo ahí estructuralmente no puede interrumpir el negocio, y la respuesta correcta es reconocer eso en lugar de empezar a cambiar la configuración.

A continuación, un mapa de lo que «en línea» realmente significa para cada modo, los pasos de recuperación de emergencia para cada uno con las rutas exactas de la consola, una escalera de verificación y reversión por etapas, una lista de verificación posterior al incidente, los errores comunes que más tiempo desperdician bajo presión, y 5 respuestas de preguntas frecuentes de implementaciones reales.

Cuatro modos, cuatro mecánicas de bypass diferentes

Que el dispositivo esté realmente en línea decide si siquiera necesita un procedimiento de bypass de emergencia.

Compare su despliegue real con este mapa antes de hacer cualquier otra cosa — indica cuál de los procedimientos siguientes aplica realmente.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Solo los tres modos en línea realmente necesitan un procedimiento de bypass de emergencia — una falla en el modo de monitoreo fuera de ruta no puede, por definición, interrumpir el tráfico del negocio, porque el dispositivo nunca estuvo en la ruta de reenvío.

Recuperación de emergencia, modo por modo

La mecánica de bypass de cada modo es distinta — aquí está la ruta de recuperación exacta para cada uno, en el orden en que deben probarse.

Modo de proxy transparente

Dos tipos de recuperación a nivel de software antes del hardware: deshabilitar el sitio protegido, luego cambiar el propio dispositivo a bypass físico.

1. Deshabilite primero el sitio protegido: Configuración > Sitios protegidos, desmarque «Habilitar» para el sitio afectado, luego haga clic en el botón rojo «Aplicar cambios» en la esquina superior derecha y espere el mensaje de confirmación — no asuma que surtió efecto hasta que lo vea.
2. Si deshabilitar el sitio no restaura el negocio, cambie el propio dispositivo a bypass físico: inicie sesión en la consola web del WAF, abra Sistema, desplácese hasta la sección de modo de ejecución, seleccione «Bypass físico», haga clic en «Cambiar modo de ejecución», y confirme que el cambio realmente se completó.
3. Si ninguno de los dos pasos de software restaura el negocio (pérdida de energía, falla de hardware), haga un puente físico con un cable alrededor del WAF para restaurar el enlace directamente — este último recurso siempre está disponible sin importar el estado del propio dispositivo.

Configuration > Protected Sites > [site] > Enable   [ ] unchecked
Apply Changes  ...  Apply changes successful
// business restored? if not, escalate to physical bypass below

System > (scroll to runtime section) > Running Mode: [ Physical Bypass ]
[Switch Running Mode]  ...  Switch successful
// device is now hardware-bypassed -- traffic flows around every WAF engine entirely

Modo de proxy inverso

Dos tipos de recuperación: primero una regla de permitir-todo a nivel de aplicación, luego un bypass a nivel de red si eso solo no restaura el negocio.

1. Cree una regla de control de acceso que coincida con todo y lo permita: Configuración > Control de acceso de capa de aplicación > Crear regla, tipo de coincidencia «URL», agregue el patrón .*, modo de coincidencia «Coincidir», acción «Permitir», estado «Habilitar», y establezca el alcance en Todos (o solo la IP del sitio protegido afectado si solo necesita abrir un sitio).
2. Guarde la regla, luego arrástrela a la primerísima posición de la lista de reglas. La posición importa — las reglas se evalúan en orden, y una regla de bloqueo anterior sigue ganando sobre un permitir-todo de menor prioridad ubicado debajo.
3. Haga clic en «Aplicar reglas» en la parte inferior de la lista de reglas — el paso solo surte efecto una vez que este paso confirma el éxito.
4. Si el negocio sigue sin restaurarse, la falla está por debajo de la capa de aplicación: inicie sesión en el switch de desvío y elimine las ACL de desvío entrante y saliente para que el tráfico nunca llegue al WAF, o cancele el mapeo NAT o la vinculación de dominio del dispositivo de puerta de enlace y apunte el negocio directamente a la IP real del servidor.

Configuration > Application Layer Access Control > Create Rule
  Match type: URL   Pattern: .*
  Match mode: Match   Action: Allow   Status: Enable   Scope: All
Save Rule  ->  drag to position #1  ->  Apply Rules  ...  applied
// business restored? if not, the fault is below layer 7 -- bypass at the network level instead

// diversion switch: remove inbound/outbound diversion ACL for this site
// or: gateway device -- cancel NAT mapping / domain binding, point traffic at the real server IP

Modo de monitoreo fuera de ruta (bypass)

Este es el único modo de despliegue que no tiene absolutamente ningún procedimiento de emergencia que ejecutar — y confirmarlo es en sí mismo la comprobación.

Debido a que un WAF en modo bypass solo recibe una copia espejo del tráfico y nunca formó parte de la ruta de reenvío, una falla en el dispositivo — un fallo, un disco lleno, un motor de detección atascado — no tiene forma de interrumpir el tráfico del negocio. Si un sitio protegido está caído mientras el WAF funciona en este modo, el WAF no es la causa; en su lugar, revise la ruta de reenvío real. Ajustar la configuración de espejo/SPAN del switch es una tarea administrativa separada, no de emergencia, que no debe tocarse bajo la presión de una interrupción.

Modo puente

El menor número de palancas de software de los cuatro — la recuperación va directo al nivel de hardware.

El modo puente no tiene una regla equivalente de permitir-todo a nivel de aplicación en la que apoyarse antes del nivel de hardware, porque el dispositivo es un puente de capa 2, no un proxy. Los dos tipos de recuperación son: apagar completamente la unidad, para que su relé de bypass físico se active automáticamente, o puentear un cable directamente alrededor del dispositivo. Cualquiera restaura el enlace bruto; ninguno es elegante, y el sitio debe tratarse como completamente desprotegido hasta que la falla subyacente se corrija y el dispositivo se reincorpore deliberadamente en línea.

Restableciendo la protección en línea, en orden

Revertir un bypass en el orden equivocado puede ocultar el hecho de que la falla real todavía está ahí.

1. Confirme que la causa raíz realmente esté identificada y corregida — un error de configuración, agotamiento de recursos, una regla de falso positivo, o una falla de hardware — antes de revertir cualquier paso de bypass.
2. Revierta el bypass en el orden inverso al que se aplicó: el paso más invasivo (bypass físico/de hardware, o un apagado) debe ser el primero en revertirse, y el paso más conservador (un solo sitio deshabilitado, o una regla de permitir-todo) el último — de modo que si el problema reaparece, lo haga con la menor protección retirada, no con la mayor.
3. Vuelva a probar desde una sesión de cliente real, no solo desde la puerta de enlace o la propia consola del WAF.
4. Confirme el estado de salud del sistema antes de declarar cerrado el incidente: uso de CPU y memoria por debajo del 60%, carga de CPU por debajo de 30, uso de disco por debajo del 70% — un dispositivo que sobrevivió a la falla pero sigue funcionando caliente probablemente la repita.
5. Confirme que el volumen de alertas/registros haya vuelto a su rango normal por sitio — típicamente del orden de 10.000 a 50.000 entradas al día para un sistema web. Un pico muy fuera de ese rango generalmente significa que una regla (o el propio bypass) todavía necesita ajuste antes de poder declarar cerrado el incidente.

Lista de verificación posterior al incidente

1. Qué modo de despliegue y qué paso de bypass específico realmente restauró el negocio — esto indica qué motor (regla/seguridad, proxy/reenvío, o estadísticas web) estaba realmente implicado.
2. Causa raíz confirmada, no solo evitada: discrepancia de configuración, agotamiento de recursos, regla de falso positivo, o falla de hardware.
3. Marcas de tiempo exactas registradas: falla detectada, bypass aplicado, negocio restaurado, protección completa restaurada — para el registro de la duración de la interrupción.
4. Si el paso de bypass expuso solo el sitio afectado, o todo el WAF — un permitir-todo para todos los sitios o un bypass físico deja también sin protección a todos los demás sitios protegidos durante ese lapso, no solo al que falló.
5. CPU, memoria, carga, disco y volumen de registros de alerta todos confirmados de vuelta en rango normal antes de cerrar el incidente.
6. La regla de control de acceso de emergencia o el sitio deshabilitado realmente removidos o reactivados después — no dejados en su lugar indefinidamente una vez que pasa la presión.
7. El manual de operaciones y la lista de contactos de guardia actualizados si la vía de bypass de este modo de despliegue no estaba ya documentada antes del incidente.

5 errores comunes que más tiempo desperdician bajo presión

Una vez que sabe en qué modo está, estas cinco causas explican la mayoría de los minutos desperdiciados durante una interrupción real.

Diseños de soluciones relacionadas

Cinco preguntas que surgen constantemente

Extraídas directamente del campo — las que vale la pena tener una respuesta lista.

Límites honestos de esta nota

Lecturas relacionadas