Custom rules

Scenario: In Security Analytics or Event Analysis, you find that the client IP 192.168.0.1 is sending suspicious requests to the hostname dns.example.com.

Configuration:

Result: The custom rule blocks all matching requests.

Why do country/region-based block rules cause false positives or fail to identify 'Unknown' regions?

IP geolocation data (continent, country/region, province, ISP) cannot be 100% accurate. In addition, VPNs or proxy services can change a client's apparent IP geolocation, which can cause rules to trigger incorrectly.

Private IP ranges (such as 100.64.0.0/10) and proxy IPs may be identified as an Unknown region. ESA does not support directly blocking the Unknown region.

Recommendations:

• Combine geolocation conditions with other attributes like User-Agent or Referer. For example: country/region is not in the target list AND User-Agent does not match a specific value. This reduces false positives caused by relying solely on geolocation.

• If false positives occur, configure a whitelist rule to allow legitimate IP addresses.

I configured a rule to block a specific country/region, but requests from that region can still access my site. Why?

This usually happens when the rule combines a Country/Region condition with other match conditions (for example, a Hostname pattern) that do not actually match the incoming request, so the rule as a whole never triggers. Check that the other fields in your rule expression, such as Hostname or URI, correctly match the traffic you intend to block. You can use Security Analytics or Event Analysis to verify the actual traffic characteristics before adjusting your rule logic.

Also note that blocking access by Country/Region requires a match condition based on geolocation fields (such as Ip.Geoip.Country). This match condition is not available on the Free plan; you must upgrade to the Basic plan or higher to use it.

For expression syntax, see request match rules.

How do I prevent the X-Forwarded-For header from being spoofed when I configure WAF rules?

The X-Forwarded-For request header can be modified by the client, so a custom rule that matches on it can be bypassed by an attacker who forges the header value. When you configure a custom rule that needs to identify the real client, use the Client IP match field (ip.src) instead of matching on X-Forwarded-For. The Client IP field reflects the actual connecting IP address and cannot be spoofed by the client.

If your origin server needs to obtain the real client IP address, you can use one of the following methods:

• In Managed Transform, enable the option that adds the real client IP to the request sent to your origin (the header is named ali-real-client-ip by default; the header name can be customized). Configure your origin to read this header instead of X-Forwarded-For.

• You can also use the modify-request-header action in Transform Rules to overwrite or remove the client-submitted X-Forwarded-For header before the request reaches your origin, so that a forged value does not reach your origin.

My requests are returning a 403 Forbidden error. How do I troubleshoot this?

A 403 response is most often caused by one of the following access control policies:

• A WAF custom rule with the Block action matched your request.

• Your client IP is on an IP blacklist rule.

• Referer-based hotlink protection blocked a request that did not carry an allowed Referer.

• A geo-restriction rule blocked your request based on the country/region of the client IP.

To find out which rule caused the 403 response, capture the complete HTTP response headers of the blocked request and check them against your configured rules. Then, in the ESA console, go to the security protection module for your site and review your WAF custom rules and any cache-related resource configuration to identify and adjust the specific rule that is blocking the request.