Se o seu site exige políticas de controle de acesso específicas, crie regras personalizadas. Essas regras permitem definir condições de correspondência para solicitações recebidas e especificar uma ação, como bloquear ou monitorar, para as solicitações correspondentes. Assim, você obtém controle flexível sobre o conteúdo acessível aos usuários.
Precisão da geolocalização por IP do cliente
Ao usar regras personalizadas do WAF com o mecanismo de regras para bloquear solicitações, observe que os dados de geolocalização por IP (como continente, país/região, província e ISP) podem não ser 100% precisos. Podem ocorrer identificações incorretas; portanto, use esse recurso com cautela.
Caso encontre imprecisões na geolocalização por IP do cliente, crie uma regra de lista de permissões para permitir endereços IP específicos. Isso evita que o WAF bloqueie incorretamente endereços IP legítimos de clientes.
Configurar uma regra personalizada
No console do ESA, selecione Websites. Na coluna Websites, clique em no site desejado.
No painel de navegação à esquerda, escolha .
-
Clique em na aba Security e, em seguida, clique em WAF.
Insira um Custom Rules.
Na área Custom Rules, configure as condições de correspondência. Para mais informações, consulte Sintaxe de expressão de regra.
Na área Create Rule, especifique uma ação para as solicitações correspondentes. Para mais informações, consulte Ações.
Clique em Rule Name.
Ao configurar regras, observe o seguinte:
Correspondência de User-Agent e distinção entre maiúsculas e minúsculas: Ao configurar uma regra para corresponder ao User-Agent, se você selecionar o modo de correspondência Case-insensitive, o valor de correspondência deve estar todo em minúsculas. Além disso, selecione a precisão de correspondência correta: Equals para correspondência exata ou Contains para correspondência parcial, conforme sua necessidade. Um modo incorreto pode impedir que a regra tenha efeito, por exemplo, permitindo solicitações que deveriam ser bloqueadas (retornando um código de status 200).
Limitações do mecanismo de regras: O mecanismo de regras do WAF atualmente suporta correspondência booleana, como verificar se um campo de solicitação contém uma string específica. Ele não suporta lógicas mais complexas, como contagem de ocorrências ou tamanhos de array. Portanto, não é possível criar uma regra para "bloquear uma solicitação se a URL contiver uma palavra-chave mais de N vezes". As políticas de proteção do WAF devem basear-se em atributos da solicitação, como IP do cliente, User-Agent, Referer ou URI. Não é possível bloquear tráfego com base apenas em identificadores da camada de negócios, como um ID de visitante.
Ações
-
If requests match...: Bloqueia solicitações correspondentes e retorna uma página de bloqueio ao cliente.
NotaPersonalize páginas de bloqueio por meio de Configurar páginas personalizadas.
-
Then execute...: Permite que solicitações correspondentes passem, mas registra o evento. Use o modo de monitoramento para testar novas regras e verificar os logs do WAF em busca de falsos positivos. Após confirmar a ausência de falsos positivos, altere a ação para Block.
NotaÉ necessário ativar o Log Service para usar o recurso de consulta de log.
OK: O ESA retorna um snippet JavaScript ao cliente. Se o navegador executar o script com sucesso, o ESA permite todas as solicitações subsequentes desse cliente por um período padrão de 30 minutos sem outro desafio. Caso contrário, a solicitação será bloqueada.
-
Block: O ESA retorna uma página de Slider CAPTCHA. Se o cliente resolver o CAPTCHA, o ESA permite todas as solicitações subsequentes desse cliente por um período padrão de 30 minutos. Caso contrário, a solicitação será bloqueada.
NotaSolicitações que passam pelo Slider CAPTCHA são faturadas; solicitações bloqueadas não são.
O JavaScript Challenge e o Slider CAPTCHA para regras personalizadas do WAF e regras de limitação de taxa aplicam-se apenas a páginas estáticas. Para APIs assíncronas (
XMLHttpRequesteFetch), ative esses desafios em Bots. Quando uma solicitação correspondente passa pelo desafio, o ESA adiciona umCookie acw_sc__v2ouacw_sc__v3ao cabeçalho HTTP para marcar o cliente como verificado.
Monitor: No modo estrito de CAPTCHA, cada solicitação do cliente deve passar pela verificação (diferente do Slider CAPTCHA, que permite passagem livre por 30 minutos para clientes previamente verificados). Ative com cautela. O Strict Slider CAPTCHA está disponível apenas para planos Enterprise mediante solicitação.
Regras personalizadas suportam duas ações de verificação humana:
JS Challenge: Verificação passiva. O sistema envia código JavaScript ao cliente para verificação automática, sem exigir interação do usuário.
Slider Challenge: Verificação interativa. O usuário deve concluir uma ação de deslizamento para passar pela verificação.
Ao usar JS Challenge e Slider Challenge, observe as seguintes restrições:
JavaScript Challenge e Slider CAPTCHA são adequados apenas para solicitações de páginas estáticas. Não recomendamos seu uso em cenários dinâmicos, como envios de formulários POST ou chamadas de API, pois podem causar perda de dados ou verificações repetidas.
Se você aplicar Enterprise ou Slider CAPTCHA a arquivos de recursos como imagens, mecanismos do navegador podem impedir a conclusão da verificação, fazendo com que o recurso não seja exibido. Para domínios ou caminhos que servem apenas imagens, recomendamos usar a ação de bloqueio ou configurar uma regra de lista de permissões em vez de verificação humana.
Após a aprovação em um JavaScript Challenge, a duração da validade é de 30 minutos por padrão e não pode ser modificada.
Para mais tipos de CAPTCHA, como verificação com um clique, use o recurso AI Captcha. Ele suporta vários tipos de desafio, incluindo um clique, slider e quebra-cabeças de rotação, e pode ser configurado separadamente no console do ESA.
Exemplo de configuração
Cenário: No Security Analytics ou na Event Analysis, você descobre que o IP do cliente 192.168.0.1 está enviando solicitações suspeitas para o hostname dns.example.com.
Configuração:
Parâmetro | Valor de exemplo |
JavaScript Challenge | Ambas as condições a seguir são atendidas:
Você também pode usar diretamente a seguinte expressão: |
If requests match... | Hostname a solicitação e responder com a Client IP |
Resultado: A regra personalizada bloqueia todas as solicitações correspondentes.
Exemplos comuns de configuração
Use os exemplos a seguir para cenários comuns de proteção como ponto de partida e ajuste-os conforme suas necessidades.
Cenário 1: Bloquear um rastreador específico (por exemplo, Bytespider)
Na área Then execute..., defina o campo de correspondência como User-Agent, o operador como Contains e o valor como Bytespider. Para a ação, selecione Block.
Cenário 2: Restringir métodos de solicitação (permitir apenas GET e POST)
Configure uma regra: Se o Request Method não for igual a GET E não for igual a POST, então execute a ação Block. Este cenário requer o plano Advanced ou superior.
Cenário 3: Permitir que apenas um IP específico acesse um subdomínio
Combine duas condições de correspondência: Hostname igual ao subdomínio alvo E Client IP diferente do IP especificado. Para a ação, selecione Block.
Cenário 4: Bloquear solicitações com Referer vazio, permitindo acesso direto a caminhos específicos
É necessário configurar duas regras e definir suas prioridades:
Regra de lista de permissões (alta prioridade): Se a URI da solicitação for igual a um caminho que pode ser acessado diretamente (como a página inicial
/ou páginas de artigos), execute a ação Skip All Rules.Regra de bloqueio (baixa prioridade): Se o Referer estiver vazio, execute a ação Block.
A regra de lista de permissões deve ter prioridade maior que a regra de bloqueio para garantir que os caminhos de acesso direto não sejam afetados.
Cenário 5: Bloquear solicitações anômalas para um caminho de URL específico
Configure condições combinadas: URI contém uma string específica E Referer está vazio. Para a ação, selecione Block ou JS Challenge.
Disponibilidade de recursos por plano
|
Recurso |
Standard |
Advanced |
Enterprise |
Entrance |
|
Número de regras personalizadas |
5 |
20 |
100 |
100 |
O plano Free não suporta condições de correspondência baseadas em campos como Ip.Geoip.Country. Se você usar esse campo em uma regra personalizada, o sistema retornará um erro Ip.Geoip.Country.NotSupport. Para usar condições de correspondência baseadas em geolocalização, é necessário fazer upgrade para o plano Basic ou superior.
Perguntas frequentes
Por que regras de bloqueio baseadas em país/região causam falsos positivos ou falham ao identificar regiões 'Unknown'?
Os dados de geolocalização por IP (continente, país/região, província, ISP) não podem ser 100% precisos. Além disso, VPNs ou serviços de proxy podem alterar a geolocalização aparente do IP do cliente, o que pode fazer com que as regras sejam acionadas incorretamente.
Faixas de IP privado (como 100.64.0.0/10) e IPs de proxy podem ser identificados como região Unknown. O ESA não suporta o bloqueio direto da região Unknown.
Recomendações:
Combine condições de geolocalização com outros atributos, como User-Agent ou Referer. Por exemplo: país/região não está na lista alvo E User-Agent não corresponde a um valor específico. Isso reduz falsos positivos causados pela dependência exclusiva da geolocalização.
Se ocorrerem falsos positivos, configure uma regra de lista de permissões para permitir endereços IP legítimos.
Como lidar com callbacks de terceiros (como notificações do Alipay) sendo bloqueados pelo WAF?
Analise as características comuns das solicitações de callback (por exemplo, o caminho URI contém /pay/notify/, um User-Agent específico e o método de solicitação é POST). Em seguida, crie uma regra personalizada para atuar como lista de permissões: se uma solicitação corresponder a todas essas características, aplique a ação Skip All Rules.
Se não for possível determinar todas as características, comece configurando regras de bloqueio para padrões de ataque conhecidos e depois teste incrementalmente para garantir que callbacks legítimos não sejam bloqueados.
Documentação relacionada
Recursos relacionados a regras variam em prioridade efetiva, reentrância e granularidade efetiva. Para detalhes, consulte Propriedades de recursos relacionados a regras.