Quando uma falha do WAF está derrubando o negócio que ele deveria proteger, a correção mais rápida depende inteiramente de como ele está implantado — proxy transparente, proxy reverso, monitoramento fora de caminho (bypass) ou modo ponte têm cada um seu próprio caminho de bypass, e usar o errado desperdiça os minutos que mais importam.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Antes de mexer em qualquer configuração sob pressão, confirme qual dos quatro modos de implantação você realmente está usando — a mecânica de bypass nunca é a mesma entre dois deles.
Se uma falha do WAF pode ou não derrubar o negócio que ele protege, e o que «bypass» sequer significa para corrigir isso, depende inteiramente de o dispositivo estar em linha no caminho do tráfego ou apenas observar uma cópia espelhada dele. Proxy transparente, proxy reverso e modo ponte estão todos em linha — uma falha ali realmente interrompe o tráfego, e cada um tem sua própria mecânica de recuperação emergencial. O modo de monitoramento fora de caminho (bypass) não está em linha de forma alguma, então uma falha do dispositivo ali estruturalmente não pode interromper o negócio, e a resposta correta é reconhecer isso em vez de começar a mudar a configuração.
A seguir está um mapa do que «em linha» realmente significa para cada modo, os passos de recuperação emergencial para cada um com os caminhos exatos do console, uma escada de verificação e reversão em etapas, uma lista de verificação pós-incidente, as pegadinhas que mais desperdiçam tempo sob pressão, e 5 respostas de perguntas frequentes de implantações reais.
Se o dispositivo está genuinamente em linha decide se ele sequer precisa de um procedimento de bypass emergencial.
Compare sua implantação real com este mapa antes de fazer qualquer outra coisa — ele indica qual dos procedimentos abaixo realmente se aplica.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Somente os três modos em linha realmente precisam de um procedimento de bypass emergencial — uma falha no modo de monitoramento fora de caminho não pode, por definição, interromper o tráfego do negócio, porque o dispositivo nunca esteve no caminho de encaminhamento.
A mecânica de bypass de cada modo é diferente — aqui está o caminho de recuperação exato para cada um, na ordem em que devem ser tentados.
Dois tipos de recuperação em nível de software antes do hardware: desabilitar o site protegido, depois mudar o próprio dispositivo para bypass físico.
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 entirelyDois tipos de recuperação: primeiro uma regra de permitir-tudo em nível de aplicação, depois um bypass em nível de rede se isso sozinho não restaurar o negócio.
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 IPEste é o único modo de implantação que não tem absolutamente nenhum procedimento emergencial a executar — e confirmar isso já é a própria verificação.
Como um WAF em modo bypass só recebe uma cópia espelhada do tráfego e nunca fez parte do caminho de encaminhamento, uma falha no dispositivo — uma queda, um disco cheio, um motor de detecção travado — não tem como interromper o tráfego do negócio. Se um site protegido estiver fora do ar enquanto o WAF está rodando nesse modo, o WAF não é a causa; olhe para o caminho de encaminhamento real. Ajustar a configuração de espelhamento/SPAN do switch é uma tarefa administrativa separada, não emergencial, que não deve ser mexida sob a pressão de uma interrupção.
O menor número de alavancas de software entre os quatro — a recuperação vai direto para o nível de hardware.
O modo ponte não tem uma regra equivalente de permitir-tudo em nível de aplicação para recorrer antes do nível de hardware, porque o dispositivo é uma ponte de camada 2, não um proxy. Os dois tipos de recuperação são: desligar completamente a unidade, para que seu relé de bypass físico se acione automaticamente, ou colocar um jumper de cabo diretamente ao redor do dispositivo. Qualquer um restaura o link bruto; nenhum é elegante, e o site deve ser tratado como totalmente desprotegido até que a falha subjacente seja corrigida e o dispositivo seja deliberadamente recolocado em linha.
Reverter um bypass na ordem errada pode esconder o fato de que a falha real ainda está presente.
Depois de saber em qual modo você está, essas cinco causas explicam a maior parte dos minutos desperdiçados durante uma interrupção real.
SINTOMAUm engenheiro começa a procurar um procedimento de bypass para um WAF rodando em modo de monitoramento fora de caminho durante uma interrupção.
CAUSAO modo de monitoramento fora de caminho só vê uma cópia espelhada do tráfego — ele nunca esteve no caminho de encaminhamento, então uma falha no dispositivo estruturalmente não pode ser a razão de um site estar fora do ar.
SOLUÇÃOSe um site estiver fora do ar enquanto o WAF está nesse modo, pare completamente de olhar para o WAF e verifique o caminho de encaminhamento real — roteamento, o gateway real, o próprio servidor. Confirmar o modo é a própria verificação; não há etapa de bypass a executar.
SINTOMAUma regra de permitir-tudo de controle de acesso em proxy reverso é criada e salva, mas o site ainda está sendo bloqueado.
CAUSAAs regras de controle de acesso são avaliadas em ordem. Uma regra de permitir-tudo posicionada em qualquer lugar abaixo de uma regra de bloqueio existente nunca é alcançada, porque a regra anterior já correspondeu e agiu primeiro.
SOLUÇÃODepois de salvar a regra, arraste-a para a posição nº 1 da lista e clique em «Aplicar regras» — criar a regra e aplicá-la são duas etapas separadas, e pular a etapa de arrastar para o topo é a razão mais comum pela qual esse bypass parece falhar.
SINTOMAA regra de permitir-tudo é confirmada como aplicada e corretamente priorizada em modo de proxy reverso, mas o site ainda não volta.
CAUSAUm bypass de controle de acesso só aborda a camada do motor de segurança. Se o tráfego estiver chegando via ACLs de um switch de desvio ou uma regra de NAT/vinculação de domínio de gateway que é ela mesma parte do problema, uma regra de permitir-tudo dentro do WAF não muda nada sobre como o tráfego chega até ele em primeiro lugar.
SOLUÇÃOEscale para o nível de rede: remova as ACLs de desvio de entrada/saída do switch de desvio, ou cancele o mapeamento NAT ou a vinculação de domínio do gateway, para que o tráfego vá direto para o IP real do servidor sem tocar no WAF.
SINTOMAO negócio é restaurado depois de mudar direto para bypass de hardware/físico, mas ninguém consegue dizer depois qual motor do WAF realmente causou a interrupção.
CAUSAO bypass físico descarta todos os motores do WAF de uma vez — motor de regras/segurança, motor de proxy/encaminhamento, e motor de estatísticas web igualmente — então restaurar o negócio dessa forma responde «está consertado» mas não «o que realmente quebrou».
SOLUÇÃOQuando a interrupção permitir, escale primeiro pelas etapas mais restritas — desabilite o grupo de regras referenciado, depois uma regra de permitir-tudo de controle de acesso, depois desabilite um único site — antes de pular para o bypass físico, para que cada etapa que restaure o negócio também indique qual motor estava envolvido.
SINTOMAO bypass é revertido e a proteção é restaurada, e a mesma interrupção se repete em poucas horas.
CAUSAO fato de o negócio ser restaurado por um bypass só prova que o bypass funcionou — não diz nada sobre se a condição subjacente (uma tendência de esgotamento de recursos, uma regra que vai disparar de novo, uma falha de hardware que na verdade não foi reparada) foi resolvida.
SOLUÇÃOConfirme se CPU, memória, carga e disco voltaram às suas faixas normais e se a causa raiz realmente foi identificada antes de reverter o bypass — não apenas que o site carregue novamente enquanto o bypass ainda está em vigor.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Escale progressivamente: desabilite o grupo de regras referenciado pelo site, depois uma regra de permitir-tudo em nível de aplicação com prioridade máxima, depois desabilite o site individual (um bridge-through no nível do site), depois mude todo o dispositivo para o modo ponte/passagem, e use o bypass físico/de hardware ou um desligamento apenas como último recurso. Cada etapa descarta um motor diferente, e as etapas anteriores e mais restritas deixam a você a maior quantidade de informação para diagnosticar depois.
Não. Como o dispositivo só vê uma cópia espelhada do tráfego nesse modo, uma falha do WAF ali estruturalmente não pode derrubar o negócio. Se um site estiver fora do ar enquanto o WAF está em modo de monitoramento bypass, olhe para o caminho de encaminhamento real, não para o WAF.
Escale para o nível de rede: faça login no switch de desvio e remova as ACLs de desvio de entrada e saída, ou cancele o mapeamento NAT ou a vinculação de domínio do gateway para que o tráfego vá direto para o IP real do servidor sem tocar no WAF.
Confirme a partir de um teste de cliente real, não do gateway ou do próprio console do WAF. Confirme que CPU e memória estão abaixo de 60%, carga de CPU abaixo de 30, disco abaixo de 70%, e confirme que o volume de logs de alerta voltou à sua faixa normal por site (cerca de 10.000 a 50.000 entradas por dia) antes de reverter o bypass e declará-lo encerrado.
Um único runbook combinado, mas ele precisa se ramificar por modo já na primeiríssima etapa, porque as mecânicas não se sobrepõem: o proxy transparente recai em desabilitar o site e depois o bypass físico; o proxy reverso recai em um permitir-tudo de controle de acesso e depois um bypass em nível de desvio/NAT; o modo ponte recai direto no desligamento ou um cabo jumper; e o modo de monitoramento bypass não tem procedimento de bypass algum, porque nunca esteve em linha para começar.
Esta nota é construída em torno do modelo de modos de implantação da série Huawei WAF5000 — proxy transparente, proxy reverso, monitoramento fora de caminho e modo ponte — e os casos de campo de manutenção emergencial por trás dela. Se o seu WAF for de outro fornecedor ou versão de firmware, os caminhos exatos do console vão variar, mas a lógica subjacente — se o dispositivo está genuinamente em linha, e qual camada cada etapa de bypass descarta — se aplica diretamente. Não cobre em profundidade o failover de par WAF em cluster/HA, nem cenários de implantação sobreposta SD-WAN.
Diga-nos seu modo de implantação — proxy transparente, proxy reverso, monitoramento bypass, ou ponte — além do que você já tentou, e ajudaremos você a interpretá-lo.