Debug WAF blocking

What is WAF rule blocking?

cPGuard WAF is a set of rules written using the ModSecurity module integrated with the web server. The ModSecurity module works in Layer 7 and helps to analyse the request/response body, headers, etc to identify the web attack attempts. So our WAF has such a set of rules that can identify generic and specific web attack attempts. Each incoming requests are parsed through the rules so that we can make a better defence against the web attacks. Whenever one of the conditions, AKA rules, matches against a specific request, that will trigger the action and block the requests with a 403 or 406 response code. There should be a “Rule ID” along with each such block, and that is the unique identifier to understand which rule triggered in a specific incident. You can use this rule ID to whitelist the rule triggered just in case you want to allow the particular type of transitions. 

Why do you need to debug the WAF blocking?

As mentioned above, the WAF is a set of rules with known web attack patterns. There are some conditions in which legitimate requests resemble the attack patterns and thus get blocked in the WAF. Even if we built the WAF rules carefully to avoid false positives, certain websites have specific requirements, and thus, such false positive case can happen in isolated cases. In such case, it is important to identify the rule or rule ID that is triggering to block access. Though you can find the respective incident in our WAF/Bot attacks logs, we provide a utility now to troubleshoot this manually. 

How to identify which rule is blocking access?

To start with the troubleshooting, you have to run the following command on your server to watch the WAF logs.

That will start WAF log monitoring and ask you to enter a filter/pattern that you wish to search. You can enter anything like your IP address, domain or URI affected, etc. After that, you can recreate the incident from your browser and that will show the rule that triggered

An example of this is given below

The filter can be any part of the above incident, and that can help to identify the rule triggered. You can immediately whitelist it or exit the prompt and manually review and whiteliste the specific rule ID.

PS: It is important to enter right “filter” and recreate the incident after starting the watch.