Web Application Firewall:FAQ about protection configuration

Why can I not find a specific protection rule ID in the WAF console?

If you cannot find a specific rule ID in the WAF console, check the following items based on the rule type:

Search for built-in web core protection rules

1. Log on to the Web Application Firewall 3.0 console. From the top menu bar, select the resource group and region (Chinese Mainland or Outside Chinese Mainland) for the WAF instance..

2. In the left-side navigation pane, choose Protection Config > Core Web Protection > Core Protection Rule.

3. Locate and expand the target protection template, and click Configure Engine in the Actions column.

4. In the Configure Engine page that appears, search for the rule.

Search for custom rules

For other protection modules (such as Custom Rule, HTTP Flood Protection, and Scanning Protection) under Core Web Protection, follow these steps to search for custom rules:

1. In the left-side navigation pane, choose Protection Config > Core Web Protection.

2. Search in the location shown in the following figure.

Search for whitelist rules

1. In the left-side navigation pane, choose Protection Config > Whitelist.

2. Search in the location shown in the following figure.

Search for Bot Management rules

The protection rule is deleted

If the rule cannot be found in any of the preceding locations, it may have been deleted. You can use Operation Audit to check whether any event named DeleteDefenseRule or DeleteDefenseTemplate exists. For more information, see Query events in the ActionTrail console.

Does acl_action:block in WAF logs indicate that the request is actually blocked?

acl_action:block does not necessarily mean that the request is blocked. If acl_test is set to true, it indicates the observation mode. In this mode, only logs are recorded and no protection actions such as blocking are triggered. To determine whether a request is actually blocked, check the final_action field. final_action:block indicates that the request is blocked.

Why does a custom rule not take effect after I set the match field to Body Parameter?

This may be because the match content that you entered is too short. When you use the Body Parameter field, make sure that the match content is longer than four characters. Otherwise, the traffic cannot be detected.

Why do custom protection policy rules not take effect when the URL match field contains double slashes (//)?

The WAF rule engine normalizes URLs by compressing consecutive forward slashes (/) by default. Therefore, custom protection policy rules that contain double slashes (//) in the URL match field cannot be correctly matched.

To configure an ACL rule for a URL that contains double slashes (//), you can use the corresponding single-slash path as the match condition. For example, if you want to use //api/sms/request as the condition value for the URL match field, enter /api/sms/request in the match content field. WAF can then apply access control to requests that contain this path.

How do I troubleshoot why a request is blocked by WAF by using a request ID?

When a request is blocked by WAF, the system returns a unique request ID in the response. You can use this ID to search for detailed information in security reports or logs to identify the blocking reason.

1. Obtain the request ID: After a request is blocked, the request ID is displayed by default on the blocking page. Copy this ID for subsequent search.

2. Search in the WAF console: Log on to the WAF 3.0 console. In the left-side navigation pane, choose Detection and Response > Security Reports. Set a time range for the search, and paste the request ID in the Enter Trace ID search box.

   Note

   If log delivery is enabled for the protection object, you can also search on the Detection and Response > Log Service page.

3. Analyze the blocking reason: On the Security Reports page, view the Protection Module and Rules Matched matched by the request at the bottom of the page. If you confirm that the request is normal business traffic, click Suppress False Positive in the Actions column of Logs to add the request to a whitelist. For more information, see Whitelist.

How to disable the API Security feature for a pay-as-you-go WAF instance?

If you no longer need the API Security feature for a pay-as-you-go WAF instance, follow these steps to disable it.

1. Log on to the Web Application Firewall 3.0 console. From the top menu bar, select the resource group and region (Chinese Mainland or Outside Chinese Mainland) for the WAF instance..

2. In the navigation pane on the left, choose Protection Config > API Security.

3. Go to the Policy Configurations > Applicable Object Configurations tab.

4. Turn off the Basic Detection switch for all protected objects and protected object groups. After this operation, historical data for API Security is purged and can no longer be viewed.

Does Alibaba Cloud WAF inject CORS response headers or dynamically echo the Origin request header by default?

WAF does not modify CORS headers of requests and does not provide configuration options to automatically inject CORS response headers or dynamically echo the Origin header. CORS policies should be configured and managed by the origin server or your application.

What causes WAF to return a 413 Request Entity Too Large error?

Cause: The uploaded file exceeds the maximum request size limit set by WAF (currently 2 GB).

Solution:

• Reduce the file size to ensure each request is under 2 GB.

• Upgrade WAF to the Ultimate edition, which supports files up to 10 GB. For more information, see Upload file size.

Does receiving a WAF interception alert mean that the business has been affected?

Receiving a WAF interception alert indicates that the security protection mechanism is working properly and does not directly mean that your business has been impacted. However, in specific scenarios, you may need to investigate potential false positives or protection failures.

Alert meaning

A WAF interception alert indicates that the system has successfully identified and blocked malicious requests that match security rules. Such requests are cleaned before reaching the origin server and do not consume origin server resources or cause actual attack damage. This is a sign that the protection mechanism is working normally.

Scenarios that require investigation

1. False positive: If legitimate user access (such as backend logins or API calls) is blocked, the rule configuration may be too strict, causing false blocks. In this case, business availability is affected, and you need to adjust the protection rules or add the relevant features to a whitelist.

2. Large-scale CC attacks: When experiencing high-frequency CC attacks, even though WAF performs interception, some requests may still slip through. Additionally, excessive attack traffic may trigger the blackhole mechanism, making the WAF service unavailable. For specific defense strategies, see Configure HTTP flood protection.

Why does the default WAF protection strategy not intercept script file uploads such as .py/.sh?

The default WAF protection strategy primarily targets high-frequency web attacks (such as SQL injection and XSS) and common webshells (JSP, PHP, ASP).

Script file extensions such as .py, .sh, .cmd, and .bat are commonly used in legitimate business scenarios for background tasks or batch processing. To avoid blocking normal business requests, the default strategy does not include these extensions in the global interception scope.

If you need to intercept such uploads, we recommend using Custom rules to precisely control uploads by matching the upload interface path and file name extension.

How do I block overseas IPs while allowing specific search engine crawlers?

You can achieve this through combined configuration:

1. Enable the Configure region blocking rules feature and select to block all Outside China regions.

2. Create a Whitelist. Set Match Condition to User-Agent containing a specific crawler identifier (such as Googlebot or bingbot), and set Bypassed Modules to Geo-blocking.

What is the difference between prefix matching and regex matching? How to choose?

1. Matching capability: Prefix matching is a simple mode that supports only fixed string matching. Regex matching is an advanced rule that supports complex pattern matching.

2. Performance: Prefix matching has high execution efficiency. Regex matching consumes slightly more resources due to the complexity of the underlying engine, and the cost is slightly higher when using the pay-as-you-go edition.

3. Rule tuning suggestions: If the current rule does not block as expected, check whether the matching method is inappropriate. For example, for URI paths, you can try using Contains One of Multiple Values or Regex Match instead of a single prefix/suffix match to improve the hit rate. When using regex matching, pay attention to the regex syntax and avoid complex nesting.

Does the whitelist take effect immediately after configuration, or do I need to wait for the ban period to end?

After you add a whitelist rule, it takes effect immediately. You do not need to wait for the original ban period to end.

If you are still being blocked after configuration, check the following:

• Check that the template and rule switches are enabled.

• Confirm the Apply To settings are correct.

• Verify the match conditions are accurate.

• Confirm whether a Layer 7 proxy such as CDN or Anti-DDoS exists before WAF. If so, you must correctly configure the Is a Layer 7 proxy such as Anti-DDoS Proxy or CDN deployed in front of WAF option when adding the asset. Otherwise, WAF cannot obtain the real client IP.

What is the matching principle of WAF fingerprint rules (JA3/JA4/HTTP2)? Why can they be hit from non-IP dimensions?

Fingerprint rules match based on hash values generated from client browser or tool characteristics, not based on IP addresses. Specifically:

1. JA3 fingerprint: Generated by applying MD5 hashing to key TLS handshake parameters (version, cipher suites, etc.).

2. JA4 fingerprint: Introduces additional algorithms (browser version, OS, etc.) to reduce duplication.

3. HTTP/2 fingerprint: Generated using the MD5 algorithm based on the HTTP/2 client's original fingerprint.

As long as a request carries a matching fingerprint signature, the rule is triggered regardless of the IP's geographic origin.