ESA e WAF 3.0
Ao adicionar um site ao ESA usando um registro CNAME, o ESA fornece automaticamente proteção WAF para o site. Você não precisa comprar e implantar o WAF 3.0 separadamente.
Para personalizar as regras do WAF, faça logon no ESA console e acesse Global Settings > Global WAF e crie e gerencie regras. Esse recurso está disponível apenas na edição Enterprise.
Para obter instruções detalhadas sobre como configure as regras de proteção do WAF, consulte Global WAF.
Encadeamento com WAF autônomo
Sim, o ESA suporta uma arquitetura de implantação em cadeia: DNS → ESA → WAF autônomo. Essa arquitetura roteia o tráfego pelo ESA para aceleração e proteção básica antes de encaminhá-lo ao WAF autônomo para inspeção de segurança aprofundada.
Para configure isso, faça logon no ESA console. Nas configurações de DNS do seu site, defina o valor do registro ou servidor source como o endereço IP (registro A/AAAA) ou o nome de domínio (registro CNAME) do seu WAF autônomo.
O WAF integrado ao ESA oferece regras gerenciadas, regras personalizadas e limitação de taxa, cobrindo a maioria dos cenários de proteção web. Se precisar da personalização avançada de um WAF autônomo, use a arquitetura em cadeia. Para obter instruções detalhadas sobre como configure os recursos do WAF, consulte Global WAF.
Como lidar com ataques em grande escala
Na configuração do WAF, acesse a guia Strict. Defina o nível de proteção para limitação de taxa inteligente como Strict e a ação como Block.
Acesse a guia Security Analytics. Na seção de visão geral de dados, identifique quaisquer endereços IP anômalos no Security Analytics e use uma regra personalizada para bloqueá-los.
Na guia Security Analytics, visualize os dados de Request Analytics na seção Overview. Caso encontre dados anômalos, crie uma regra personalizada do WAF para bloquear as requisições. Por exemplo, se a maioria das requisições tiver um valor de Referer igual a
-, crie uma regra para bloquear requisições com Referer vazio ou com valor-. (Quando uma requisição inclui um cabeçalho Referer, mas o valor do cabeçalho está vazio, o console exibe o valor como-).
Por que a configuração do WAF no ESA não surte efeito?
Configuração de regra incorreta
Uma regra é acionada apenas se uma requisição corresponder exatamente à expressão. Revise sua configuração:
-
Campo de correspondência: Use o campo correto. Por exemplo:
URIinclui a string de consulta (por exemplo,/content?page=1234), enquantoURI Pathcontém apenas o caminho (por exemplo,/content).Se sua regra usar uma condição como
URI equals /content, ela não corresponderá a uma requisição para /content?page=1234, pois a URI completa não é idêntica.
Operador de correspondência: Verifique se o operador selecionado, como "equals" ou "contains", é adequado para o seu cenário.
Valor de correspondência: Verifique se o valor é exatamente o que aparece na requisição.
Solução: Consulte os exemplos nos documentos matching field, operators and grouping symbols e matching value para verificar a configuração da sua regra.
Conflitos de regras de lista de permissões
As regras de acesso por IP e as regras de lista de permissões têm prioridade maior que outras regras. Se uma requisição corresponder a uma política de permissão em uma regra de acesso por IP ou a uma regra de lista de permissões, o WAF ignorará as regras subsequentes. Isso pode dar a impressão de que sua configuração não está funcionando. Para investigar:
No módulo Security Analytics, use filtros para encontrar a requisição relevante.
Nos logs amostrados, verifique qual regra foi acionada para a requisição.
Se uma regra de acesso por IP (com ação de permissão) ou uma regra de lista de permissões executou a ação final, isso confirma que o WAF ignorou as outras regras.
Solução: Ajuste suas regras de acesso por IP e de lista de permissões para garantir que o escopo não abranja as requisições a serem protegidas.
Requisições contornando o ESA
As regras do WAF não surtem efeito se o tráfego não passar pelo ESA. Se os invasores acessarem seu servidor source diretamente, eles contornarão as regras do WAF. Verifique essa situação (usando o Nginx como exemplo):
-
Obtenha o endereço IP da requisição:
Abra o arquivo de configuração do Nginx (caminho padrão:
/etc/nginx/nginx.conf) e verifique o formato e a localização doaccess.log.Consulte o arquivo
access.loge extraia o valor de$remote_addr. O campo$remote_addrindica o endereço IP que se conectou diretamente aoNginx.
-
Verifique a origem do IP:
No console do ESA, selecione Websites e clique em site de destino na coluna Websites.
No painel de navegação à esquerda, escolha Websites > Website.
Na página Security, clique em Origin Protection.
Ative o seletor Origin Protection. Na caixa de diálogo exibida, selecione Configure e clique em Status.
Compare o endereço IP obtido nos logs com os IPs na lista
IPv4(a listaIPv4contém intervalos de IP). Caso haja correspondência, a requisição ao servidor source veio do ESA. Caso contrário, a requisição não passou pelo ESA e foi enviada diretamente ao servidor source.
Solução: Ative o recurso origin protection. Adicione a lista de IPs dos nós do ESA às regras de firewall do seu servidor source, permitindo tráfego apenas desses IPs incluídos na lista de permissões.
Bloqueio de Referer vazio ou ausente
Referer vazio
Definição:
Uma requisição com "Referer vazio" é uma requisição HTTP com cabeçalho Referer de valor vazio (por exemplo, Referer: ""). Isso geralmente ocorre devido a determinados navegadores ou ferramentas de proxy. Na guia I understand the risks do Security Analytics, um - no gráfico de Referer representa essas requisições.
Solução:
Use o modelo OK na guia Overview para criar uma regra rapidamente.
Sem Referer
Definição:
Uma requisição "sem Referer" é uma requisição HTTP sem o cabeçalho Referer. Invasores podem criar isso intencionalmente, ou pode resultar do comportamento padrão de alguns clientes, como navegadores no modo de privacidade.
Solução:
Para bloquear requisições sem o cabeçalho Referer, crie uma regra personalizada. Defina a condição de correspondência como "Referer does not exist".
Componentes da URI
Uma URI é composta pelas seguintes partes:
scheme:[//host]path[?query][#fragment]
scheme: O protocolo, como
http,httpsouftp.host: O nome do host, como
www.example.com.path: O caminho do recurso no servidor, como
/users/profile.query: A string de consulta, usada para transmitir parâmetros, como
?id=123&name=John.fragment: O identificador de fragmento, usado para direcionar a uma parte específica da página, como
#section1.
As diferenças entre os campos são:
|
Propriedade |
URI |
URI Path |
URI Query String |
|
Definição |
Corresponde ao caminho do recurso e à string de consulta. |
Corresponde ao caminho do recurso, excluindo a string de consulta. |
Corresponde à string de consulta, excluindo o caractere ?. |
|
Localização |
O texto após o nome do host. |
Após |
O texto entre o |
|
Exemplo |
|
|
|
Identificação de regras de bloqueio
Na página de bloqueio: Quando o WAF bloqueia uma requisição, a página de resposta geralmente inclui um nome de regra (Denied by xxx) e um Rule id. Compare o Rule id da página de bloqueio com o do console para encontrar a regra específica.
Nos logs: Nos logs amostrados no Security Analytics, verifique também se o WAF bloqueou uma requisição e por qual regra. Por exemplo, o exemplo a seguir mostra uma requisição bloqueada por uma regra de limitação de taxa.
Como obtenho o id de uma regra de proteção de segurança?
Acesse a página da regra de proteção de segurança correspondente. O id da regra está disponível na lista de regras.
Bloqueio de IPs em massa
Prepare uma lista dos endereços IP ou intervalos de rede para bloqueio, separados por vírgulas (
,). Obtenha esses endereços IP na página Security Analytics.Acesse as ESA Lists, clique em Overview e adicione os endereços IP preparados ao grupo de listas.
Crie uma regra personalizada para bloquear os IPs. Defina o campo de correspondência como Overview, o operador de correspondência como Create List e o valor de correspondência como o nome do grupo de listas criado.
Clique em Client IP. A regra entra em vigor imediatamente.
Escopo da regra
Se uma regra incluir uma condição
hostname, ela se aplica apenas às requisições direcionadas aos nomes de host especificados. Por exemplo, a regra no exemplo a seguir bloqueia requisições enviadas parawww.example.comouapi.example.comsem cabeçalho Referer.Uma regra sem a condição
hostnameaplica-se a todas as requisições correspondentes de qualquer domínio associado ao site.
Onde posso visualize a biblioteca de vírus e a biblioteca de assinaturas?
O WAF do ESA não oferece uma seção dedicada para visualize as versões da biblioteca de vírus ou da biblioteca de assinaturas. A Alibaba Cloud atualize as regras de proteção automaticamente, portanto, não faça a manutenção nem atualize as regras manualmente.
Visualize e configure políticas de segurança, faça logon no ESA console, selecione o site de destino e escolha Security Protection > WAF no painel de navegação à esquerda. A Alibaba Cloud gerencia de forma inteligente as managed rules dessa página, protegendo contra ataques OWASP e as vulnerabilidades source mais recentes.
Por que as regras de bloqueio baseadas em país/região causam falsos positivos ou não identificam regiões 'Unknown'?
Os dados de geolocalização de IP (continente, país/região, província, ISP) não são 100% precisos. Além disso, VPNs ou serviços de proxy podem alterar a geolocalização de IP aparente de um cliente, o que pode acionar as regras incorretamente.
O sistema pode identificar intervalos de IP privados (como 100.64.0.0/10) e IPs de proxy como uma região Unknown. O ESA não oferece suporte ao 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 de destino E User-Agent não corresponde a um valor específico. Isso reduz os falsos positivos causados pelo uso exclusivo da geolocalização.
Se ocorrerem falsos positivos, configure uma regra de lista de permissões para permitir endereços IP legítimos.
Configure uma regra para bloquear um país/região específico, mas as requisições dessa região ainda conseguem acessar meu site. Por quê?
Isso geralmente acontece quando a regra combina uma condição is in list com outras condições de correspondência (por exemplo, um padrão OK) que não correspondem de fato à requisição recebida. Isso impede que a regra como um todo seja acionada. Verifique se os outros campos na expressão da sua regra, como Country/Region ou URI, correspondem corretamente ao tráfego a ser bloqueado. Use o Security Analytics ou o Event Analysis para verificar as características reais do tráfego antes de ajustar a lógica da sua regra.
Além disso, bloquear o acesso por Hostname requer uma condição de correspondência baseada em campos de geolocalização (como Ip.Geoip.Country). Essa condição de correspondência não está disponível no plano Free; é necessário fazer upgrade para o plano Basic ou superior para usá-la.
Para a sintaxe da expressão, consulte request match rules.
Como evito que o cabeçalho **Hostname** seja falsificado ao configure regras do WAF?
O cliente pode modifique o cabeçalho de requisição X-Forwarded-For, portanto, um invasor que falsifica o valor do cabeçalho pode contornar uma regra personalizada que faz correspondência com ele. Ao configure uma regra personalizada para identificar o cliente real, use o campo de correspondência Country/Region (ip.src) em vez de usar X-Forwarded-For. O campo Client IP reflete o endereço IP de conexão real e o cliente não pode falsificá-lo.
Se seu servidor source precisar obter o endereço IP real do cliente, use um dos seguintes métodos:
No Managed Transform, ative a opção que adiciona o IP real do cliente à requisição enviada à sua origem (o nome padrão do cabeçalho é
ali-real-client-ip, mas pode ser personalizado). Configure sua origem para ler esse cabeçalho em vez deX-Forwarded-For.Use também a ação
modify-request-headerem Transform Rules para sobrescrever ou remover o cabeçalhoX-Forwarded-Forenviado pelo cliente antes de a requisição chegar à sua origem, impedindo que um valor falsificado a alcance.
Minhas requisições estão retornando um erro 403 Forbidden. Como soluciono isso?
Geralmente, uma das seguintes políticas de controle de acesso causa uma resposta 403:
Uma regra personalizada do WAF com a ação Block correspondeu à sua requisição.
O IP do seu cliente está em uma lista de bloqueios de IP.
A proteção contra hotlink baseada em X-Forwarded-For bloqueou uma requisição sem um Referer permitido.
Uma regra de restrição geográfica bloqueou sua requisição com base no país/região do IP do cliente.
Para descobrir qual regra causou a resposta 403, capture os cabeçalhos de resposta HTTP completos da requisição bloqueada e verifique em relação às suas regras configuradas. Em seguida, no console do ESA, acesse o módulo de proteção de segurança do seu site. Revise suas regras personalizadas do WAF e qualquer configuração de recurso relacionada a cache para identificar e ajustar a regra específica que está bloqueando a requisição.