Web Application Firewall:Protection configuration FAQ

Como encontrar o id de uma regra de proteção específica

Se não for possível localizar o id de uma regra específica no console do WAF, verifique os itens a seguir de acordo com o tipo de regra:

Localizar uma regra integrada do Core Web Protection

1. Faça login no console do Web Application Firewall 3.0. Na barra de navegação superior, selecione o grupo de recursos e a região (Chinese Mainland ou Outside Chinese Mainland) da sua instância do WAF.

2. No painel de navegação à esquerda, escolha Protection Config > Core Web Protection > Core Protection Rule.

3. Localize e expanda o modelo de proteção desejado e clique em Configure Engine na coluna Actions.

4. Na página Configure Engine, pesquise a regra.

Localizar uma regra personalizada

Para encontrar uma regra personalizada de outros módulos em Core Web Protection, como Custom Rule, HTTP Flood Protection ou Scanning Protection, siga estas etapas:

1. No painel de navegação à esquerda, escolha Protection Config > Core Web Protection.

2. Pesquise a regra na página.

Localizar uma regra da lista de permissões

1. No painel de navegação à esquerda, escolha Protection Config > Whitelist.

2. Pesquise a regra na página.

Localizar uma regra do Bot Management

A regra de proteção foi excluída

Se não for possível encontrar a regra em nenhuma das localizações acima, é provável que ela tenha sido excluída. Utilize o ActionTrail para verifique eventos com o nome DeleteDefenseRule ou DeleteDefenseTemplate. Para mais informações, consulte Query events in the ActionTrail console.

Significado de acl_action:block nos logs do WAF

O campo acl_action:block não indica necessariamente que a requisição foi bloqueada. Se acl_test estiver como true, o modo de observação está ativo. Nesse modo, o WAF apenas registra logs sem executar ações de proteção, como bloqueio. Para determinar se uma requisição foi de fato bloqueada, verifique o campo final_action. O valor final_action:block confirme que a requisição foi bloqueada.

Regra personalizada com o campo Body Parameter sem efeito

Uma possível causa é o conteúdo de correspondência ser curto demais. Para que o tráfego seja detectado ao utilizar o campo Body Parameter, o conteúdo de correspondência precisa ter mais de quatro caracteres. Por exemplo, defina o nome do parâmetro como name, o operador lógico como equals e o conteúdo de correspondência como David. Esse valor possui 5 caracteres, o que excede o mínimo de quatro.

Regras ineficazes para URL com barras duplas (//)

O mecanismo de regras do WAF normaliza URL comprimindo barras consecutivas (/) em uma única barra. Por esse motivo, uma regra personalizada configurada para corresponder a uma URL com barras duplas (//) não será disparada.

Se for necessário configure controle de acesso ACL para uma URL com barra dupla (//), utilize diretamente o caminho equivalente com barra simples como condição de correspondência. Por exemplo, para corresponder ao caminho de URL //api/sms/request, basta insira /api/sms/request como conteúdo de correspondência. O WAF aplicará o controle de acesso às requisições que contenham esse caminho.

Como investigar um bloqueio do WAF com o id da requisição

Quando o WAF bloqueia uma requisição, um id de requisição exclusivo é retornado na resposta. Utilize esse id para pesquisar detalhes em Security Reports ou nos logs e identificar o motivo do bloqueio.

1. Obtenha o id da requisição: quando uma requisição é bloqueada, a página de bloqueio exibe o id da requisição por padrão. Copie esse id para consultas posteriores.

2. Pesquise no console do WAF: faça login no console do Web Application Firewall 3.0. No painel de navegação à esquerda, escolha Detection and Response > Security Reports. Defina um intervalo de tempo, cole o id da requisição na caixa de pesquisa "Enter Trace ID" e inicie a pesquisa.

   Nota

   Se a entrega de logs estiver ativada para o objeto protegido, a pesquisa também pode ser feita na página Detection and Response > Log Service.

3. Analise o motivo do bloqueio: na página Security Reports, visualize os campos Protection Module e Rules Matched da requisição. Se você concluir que a requisição é legítima, localize-a em Logs e clique em Suppress False Positive na coluna Actions. Para mais informações, consulte whitelist.

Como desativar o API Security no WAF com pagamento conforme o uso

Se você não precisa mais do recurso API Security na instância do WAF com pagamento conforme o uso, siga estas etapas para desativá-lo.

1. Faça login no console do Web Application Firewall 3.0. Na barra de navegação superior, selecione o grupo de recursos e a região (Chinese Mainland ou Outside Chinese Mainland) da sua instância do WAF.

2. No painel de navegação à esquerda, escolha Protection Config > API Security.

3. Acesse a aba Policy Configurations > Applicable Object Configurations.

4. Desative o botão Basic Detection para todos os objetos protegidos e grupos de objetos protegidos. Após a desativação, os dados históricos do API Security são apagados e ficam inacessíveis.

Como o WAF lida com cabeçalhos CORS

O WAF não altera os cabeçalhos CORS de uma requisição e não oferece opções de configuração para injetar automaticamente cabeçalhos de resposta CORS ou ecoar dinamicamente o cabeçalho Origin. As políticas de CORS devem ser configuradas e gerenciadas no seu servidor de origem ou na sua aplicação.

Motivo do erro "413 Request Entity Too Large"

Causa: o tamanho do arquivo enviado excede o limite do WAF para uma única requisição, que atualmente é de 2 GB.

Solução:

• Reduza o tamanho do arquivo para garantir que cada requisição fique abaixo de 2 GB.

• Atualize o WAF para a edição Ultimate, que suporta um tamanho máximo de arquivo de 10 GB. Para mais informações, consulte Control the size of uploaded files.

Entendendo os alertas de bloqueio do WAF

Receber um alerta de bloqueio do WAF indica que o mecanismo de proteção está funcionando. Isso não significa necessariamente que seu service foi afetado. Porém, em alguns casos, é preciso verifique se há falsos positivos ou falhas de proteção.

O que o alerta significa

Um alerta de bloqueio do WAF significa que o sistema identificou e bloqueou com sucesso uma requisição maliciosa correspondente a uma regra de segurança. Essas requisições são filtradas antes de chegar ao servidor de origem, sem consumir seus recursos. Isso indica que a proteção está funcionando conforme esperado.

Cenários que exigem investigação

1. Falsos positivos: se tráfego legítimo de usuários, como logins de backend ou chamadas de API, estiver sendo bloqueado, suas regras de proteção podem ser restritivas demais. Nesse caso, a disponibilidade do service é afetada. Ajuste as regras de proteção ou adicione as características da requisição a uma lista de permissões.

2. Ataques CC em larga escala: durante um ataque CC de alta frequência, algumas requisições maliciosas podem contornar a proteção do WAF mesmo enquanto o WAF bloqueia tráfego. Além disso, tráfego excessivo de ataque pode acionar filtragem de blackhole, tornando o service do WAF indisponível. Para mais informações sobre estratégias de defesa, consulte Set up HTTP flood protection rules to defend against CC attacks.

Política padrão para upload de arquivos de script

A política de proteção padrão do WAF é projetada principalmente para defender contra ataques web de alta frequência, como injeção SQL e cross-site scripting (XSS), além de web shells comuns, como JSP, PHP e ASP.

Extensões de arquivo de script como .py, .sh, .cmd e .bat são frequentemente utilizadas em tarefas legítimas de background ou processamento em lote. Para evitar bloqueio incorreto de requisições normais de negócio, a política padrão não inclui essas extensões no escopo global de bloqueio.

Se for necessário bloquear esses uploads, recomendamos crie uma custom rule para controlar os uploads com precisão, utilizando correspondência de caminho da API de upload e extensão de arquivo.

Como bloquear ip de fora da China e permitir crawlers

É possível alcançar esse resultado com a seguinte combinação de configurações:

1. Ative o recurso geo-blocking e configure-o para bloquear todas as requisições de regiões Outside China.

2. Crie uma whitelist. Defina a Match Condition como User-Agent contendo um identificador de crawler específico, como Googlebot ou bingbot, e defina Bypassed Modules como Geo-blocking.

Correspondência por prefixo vs. correspondência por regex

1. Capacidades de correspondência: a correspondência por prefixo é um modo simples que só corresponde a strings fixas. Já a correspondência por regex é um modo avançado que suporta padrões complexos.

2. Desempenho: a correspondência por prefixo é altamente eficiente. A correspondência por regex consome um pouco mais de recursos devido à complexidade do mecanismo subjacente, e o custo é ligeiramente mais alto em instâncias do WAF com pagamento conforme o uso.

3. Recomendações de ajuste de regras: se uma regra não oferecer a proteção esperada, verifique se o método de correspondência é adequado. Por exemplo, para caminhos de URI, experimente usar Contains One of Multiple Values ou Regex Match em vez de uma correspondência única por prefixo ou sufixo, para melhorar a taxa de correspondência. Ao utilizar correspondência por regex, certifique-se de que suas expressões regulares estão bem formadas e evite aninhamentos complexos.

Tempo de vigência das regras da lista de permissões

Uma regra da lista de permissões entra em vigor imediatamente após ser adicionada. Não é necessário aguardar o término de um período de bloqueio existente.

Se as requisições continuarem sendo bloqueadas após a configuração da regra, verifique os seguintes itens:

• Os botões do modelo e da regra estão ativados.

• A configuração de Apply To está correta.

• A condição de correspondência está configurada corretamente.

• Um proxy de camada 7, como CDN ou Anti-DDoS, está implantado na frente do WAF. Nesse caso, selecione a opção Is a Layer 7 proxy such as Anti-DDoS Proxy or CDN deployed in front of WAF ao adicionar o ativo. Caso contrário, o WAF não conseguirá obter o endereço ip real do cliente.

Como gerencie objetos bloqueados por regras de limitação de taxa

• Desbloqueio manual: não é possível desbloquear objetos manualmente neste cenário. Para restaurar o acesso imediatamente, utilize um dos seguintes métodos:

  • Crie uma regra da lista de permissões (recomendado): adicione uma regra whitelist para permitir as requisições.

  • Modifique a configuração da regra: altere a Match Condition, a Action, o Statistical Object ou o Threshold da regra. Após modifique qualquer uma dessas configurações, a lista de bloqueios histórica da regra é limpa, desbloqueando todos os objetos anteriormente bloqueados.

• Bloqueio permanente: não é suportado. A duração máxima de bloqueio é de 86.400 segundos (24 horas).

Como bloquear requisições com Referer vazio ou ausente

Adicione as duas condições de correspondência a seguir para cobrir ambos os cenários:

• O operador lógico para o campo Header Referer definido como Does Not Exist.

• O operador lógico para o campo Header Referer definido como Empty.

Aviso de risco

Essa configuração pode bloquear requisições legítimas que não contêm o cabeçalho Referer, como chamadas internas de servidor, requisições de API e requisições de SDKs de clientes. Recomendamos crie uma regra da lista de permissões para permitir esse tráfego legítimo.

Disparo inconsistente de regras em portas diferentes

Os modelos de proteção do WAF entram em vigor de forma independente para cada objeto protegido. Se uma regra não for disparada para uma porta específica, geralmente o motivo é a porta não ter sido adicionada corretamente ao WAF ou não estar associada ao modelo de proteção correto.

Solução de problemas

1. Verifique o status de conexão da porta: confirme que a porta afetada foi adicionada ao WAF com sucesso.

2. Verifique a vinculação da política: certifique-se de que o objeto protegido correspondente à porta está corretamente associado ao modelo de proteção desejado.

Prioridade das regras da lista de permissões sobre outros módulos

As regras da lista de permissões possuem a maior prioridade. Quando uma requisição corresponde a uma regra da lista de permissões, o WAF ignora os módulos especificados em Bypassed Modules.

Como adicionar ip a regras por meio da API

Sim. Para mais informações, consulte Create a core web protection rule.

Como as regras de fingerprint do WAF funcionam

As regras de fingerprint fazem correspondência de requisições com base em valores de hash gerados a partir das características de navegadores ou ferramentas do cliente, e não com base em endereços ip. Veja os detalhes a seguir:

1. Fingerprint JA3: gerado pela aplicação de um hash MD5 em parâmetros-chave do handshake TLS, como a versão do TLS e os conjuntos de cifras.

2. Fingerprint JA4: introduz mais algoritmos que envolvem versões de navegadores e sistemas operacionais para reduzir duplicações.

3. Fingerprint HTTP/2: gerado com o algoritmo MD5 a partir do fingerprint original do cliente HTTP/2.

Desde que a requisição contenha um fingerprint correspondente, a regra é disparada independentemente da origem geográfica do endereço ip.

Suporte do WAF a redirecionamento de domínio

Não. O WAF não fornece recurso de redirecionamento de domínio. Para implementar esse tipo de redirecionamento, configure-o no servidor de origem ou na camada de DNS.