When your website encounters a WAF-related error (typically a 403 Forbidden error), you may need to identify the specific WAF rule ID that is causing the issue. This guide will help you track down the problematic rule using the security audit log.
4 Easy Steps to Identify the Rule ID :
-
Tail the Security Audit Log To begin, you'll need to monitor the security audit log file to observe any new WAF-related entries. Depending on your server setup, use the following commands:
-
For LiteSpeed servers:
docker exec litespeed tail -f /usr/local/lsws/logs/security_audit.log -
For OpenLiteSpeed servers:
docker exec openlitespeed tail -f /usr/local/lsws/logs/security_audit.log
-
-
Clear the Terminal Once you’ve started tailing the log, press Enter a few times to clear the terminal screen. This will help you more easily observe the new entries that appear.
-
Trigger the WAF Error Next, visit the URL that is generating the WAF error (typically a 403 Forbidden message). If the URL is part of an admin area (such as WordPress), you may need to ask your client to provide login credentials so you can access the page.
-
Observe the Log for the Rule ID After triggering the error, return to the terminal window. The log will update with a new entry showing the details of the blocked request, including the problematic WAF rule ID.
Example log entry:
[client 192.168.1.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Within' with parameter..." [id "200007"] [severity "CRITICAL"]TIP: Repeat to Confirm the Correct Rule It is recommended to repeat this process 2 or 3 times to ensure you’ve identified the correct rule ID. On busy servers, the log may be very active, and unrelated entries could appear.
By following these steps, you should be able to identify the problematic WAF rule ID and adjust your configuration accordingly. Check the whitelisting guide for more info. If you need further assistance or clarification, don’t hesitate to reach out to support.
