WAF stands for Web Application Firewall<\/strong>, and it serves as a protective layer for web applications such as WordPress. By blocking suspicious requests at the web server level, WAF reduces the risk of damage from unpatched vulnerabilities. <\/p>\n\n\n\n We\u2019ve briefly touched on this topic before in our article \u201cPreparing for attacks with WAF\u201d<\/em>, but this time we\u2019ll take a deeper dive into its setup and troubleshooting. <\/p>\n\n\n\n KUSANAGI includes a built-in WAF feature out of the box. You can enable it with a single command: <\/p>\n\n\n\n During the first execution, KUSANAGI will automatically install any necessary packages. Once you've enabled WAF, you may occasionally encounter errors such as 403 Forbidden when accessing your site. In this section, we'll explain how to analyze and resolve such issues. <\/p>\n\n\n\n Note: KUSANAGI includes NAXSI rules optimized for WordPress by default, so the example error below won\u2019t normally occur. For demonstration purposes, these default rules have been disabled.<\/em> <\/p>\n\n\n\n If you see a 403 Forbidden page, the first step is to check the nginx error log<\/strong> for the corresponding profile. <\/p>\n\n\n\n Here\u2019s an example of an actual log entry: <\/p>\n\n\n\n Look for id0 in the log \u2014 in this case, it shows 1315. This indicates the rule ID that triggered the block. If multiple rules were triggered, you\u2019d see id1, id2, and so on. <\/p>\n\n\n\n To understand what rule 1315 refers to, open the base rules file: <\/p>\n\n\n\n \/etc\/opt\/kusanagi\/nginx\/naxsi.d\/naxsi_core.rules.conf This rule flags content with double encoding as a potential XSS threat and increases the risk score accordingly. <\/p>\n\n\n\n Next, let\u2019s craft an exception rule (whitelist) to prevent this from being triggered in safe cases. <\/p>\n\n\n\n From the log entry: <\/p>\n\n\n\n To bypass this rule only in that context, add the following line: <\/p>\n\n\n\n Place the whitelist rule into the following file: <\/p>\n\n\n\n \/etc\/opt\/kusanagi\/nginx\/naxsi.d\/wordpress\/user.conf <\/p>\n\n\n\n Then restart nginx: <\/p>\n\n\n\n kusanagi nginx <\/p>\n\n\n\n After restarting, confirm that the issue is resolved. <\/p>\n\n\n\n Repeat this process whenever false positives occur. While KUSANAGI uses nginx<\/strong> as its default web server, many production environments run on Apache<\/strong>. <\/p>\n\n\n\n In this section, we'll cover how to investigate and respond to errors when using ModSecurity<\/strong> with Apache. <\/p>\n\n\n\n For this demonstration, we used a specially crafted test script to send requests and intentionally trigger a block screen. <\/p>\n\n\n\n When ModSecurity detects a suspicious or malformed request, the server responds with a block page and denies access. <\/p>\n\n\n\n When a request is blocked, the reason is logged in: <\/p>\n\n\n\n \/home\/kusanagi\/(profile_name)\/log\/httpd\/error.log <\/p>\n\n\n\n If the request was made via HTTPS, check: <\/p>\n\n\n\n ssl_error.log <\/p>\n\n\n\n These logs often contain a large volume of information. Start by checking the timestamp<\/strong> near the beginning of the line, such as: <\/p>\n\n\n\n These indicate which ModSecurity rules were triggered. <\/p>\n\n\n\n Here's a sample log entry (with some parts masked): <\/p>\n\n\n\n This warning means the request included a null character (invalid input) in the query string. <\/p>\n\n\n\n Such errors are typically triggered by malformed or suspicious inputs. While these may not cause issues with thread-safe software, non-thread-safe software could be vulnerable. Use caution when deciding to whitelist such requests. <\/p>\n\n\n\n In this case, the requests were intentionally crafted and confirmed to be safe, so we\u2019ll create a whitelist rule. <\/p>\n\n\n\n You may also need the request path, query string, or referrer. These appear toward the end of the log line as: <\/p>\n\n\n\n Now identify which rule IDs to exclude. Ideally, only exclude the minimal necessary rules<\/strong> to avoid weakening your WAF protection. <\/p>\n\n\n\n For example, let\u2019s say we determined that these two IDs can be safely ignored: <\/p>\n\n\n\n Here's a sample log for 949110: <\/p>\n\n\n\n Two more rule IDs remain (e.g., 920220, 920270). We'll add a conditional rule that disables them only when the query string or referrer matches a specific pattern<\/strong>, like test_query_string. <\/p>\n\n\n\n Append the following block to: <\/p>\n\n\n\n \/etc\/opt\/kusanagi\/httpd\/modsecurity.d\/kusanagi_activated_rules\/wordpress\/user.conf <\/p>\n\n\n\n apache <\/p>\n\n\n\n This rule tells ModSecurity to remove<\/strong> the specified rules only under tightly defined conditions, reducing the risk of over-whitelisting. <\/p>\n\n\n\n After saving the file, restart Apache using: <\/p>\n\n\n\n kusanagi httpd <\/p>\n\n\n\n Then verify that the site loads correctly and the design remains intact. <\/p>\n\n\n\n By repeating this process and reviewing each blocked request, you can fine-tune your WAF configuration for both security and usability. <\/p>\n\n\n\n If you've investigated the error using the above methods and still cannot resolve the issue\u2014and only if absolutely necessary<\/strong>\u2014you may disable the WAF entirely using the following command: <\/p>\n\n\n\n By leveraging the built-in WAF in KUSANAGI, you can operate a more secure website with minimal effort. <\/p>\n\n\n\n While false positives can occur, they are generally easy to investigate and correct once you get the hang of it. <\/p>\n\n\n\n We recommend evaluating the trade-off between security<\/strong> and convenience<\/strong>, and considering WAF as a practical solution to harden your web application. <\/p>\n\n\n\n https:\/\/code.google.com\/archive\/p\/naxsi\/wikis\/BasicRule.wiki<\/a><\/p>\n\n\n\n
It helps prevent malicious access attempts that exploit known vulnerabilities\u2014like SQL injection or directory traversal\u2014before<\/strong> they reach the application layer (e.g., PHP). <\/p>\n\n\n\n<\/span>How to Enable WAF in KUSANAGI<\/strong><\/span><\/h2>\n\n\n\n
It uses NAXSI<\/strong> for nginx and ModSecurity<\/strong> for Apache.
Note, however, that WAF is not enabled by default<\/strong>, so you\u2019ll need to activate it manually. <\/p>\n\n\n\nkusanagi waf on<\/code><\/pre>\n\n\n\n
If the setup is successful, you should see the following messages at the end: <\/p>\n\n\n\nrestart completed.
waf completed.<\/code><\/pre>\n\n\n\n<\/span>How to Analyze Errors with NAXSI on nginx<\/strong> <\/span><\/h2>\n\n\n\n
<\/span>Step 1: Check the nginx Error Log<\/strong><\/span><\/h3>\n\n\n
![\"NAXSI](\"https:\/\/www.prime-strategy.co.jp\/column\/wp-content\/uploads\/2023\/07\/29d3bc99193cb0b837fb8cc53f050ae5.png\")
<\/figure>\n<\/div>\n\n\n\n
\/home\/kusanagi\/(profile_name)\/log\/nginx\/error.log <\/li>\n\n\n\n
\/home\/kusanagi\/(profile_name)\/log\/nginx\/ssl_error.log <\/li>\n<\/ul>\n\n\n\n2023\/07\/21 08:36:23 [error] 7432#7432: *1 NAXSI_FMT: ip=192.0.2.1&server=example.com.internal&uri=\/wp-login.php&vers=1.3&total_processed=1&total_blocked=1&config=block&cscore0=$XSS&score0=16&zone0=HEADERS&id0=1315&var_name0=cookie, client: 50.5.35.41, server: example.com.internal, request: \"GET \/wp-login.php?action=logout&_wpnonce=facec0ed55 HTTP\/1.1\", host: \"example.com.internal\", referrer: \"http:\/\/example.com.internal\/\" <\/code><\/pre>\n\n\n\n<\/span>Step 2: Look Up the Rule ID<\/strong><\/span><\/h3>\n\n\n\n
Search for rule ID 1315. You might find something like this: <\/p>\n\n\n\nMainRule \"rx:%[23].\" \"msg:double encoding\" \"mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie\" \"s:$XSS:8\" id:1315;<\/code><\/pre>\n\n\n\n<\/span>Step 3: Whitelist the Rule for the Specific Context<\/strong> <\/span><\/h3>\n\n\n\n
\n
BasicRule wl:1315 \"mz:$HEADERS_VAR:cookie\";<\/code><\/pre>\n\n\n\n\n
<\/span>Step 4: Apply the Rule and Restart nginx<\/strong><\/span><\/h3>\n\n\n\n
By refining your rules over time, you can improve both security precision<\/strong> and site usability<\/strong>. <\/p>\n\n\n\n<\/span>How to Analyze Errors with ModSecurity on Apache<\/strong><\/span><\/h2>\n\n\n\n
![\"ModSecurity](\"https:\/\/www.prime-strategy.co.jp\/column\/wp-content\/uploads\/2023\/07\/image-1-1024x474.png\")
<\/figure>\n\n\n\n<\/span>Step 1: Review Apache Error Logs<\/strong><\/span><\/h3>\n\n\n\n
[Fri Jul 21 08:36:23.102987 2023] \nThis tells you exactly when the event occurred (in this case, July 21, 2023 at 08:36:23 AM). \nThen, look for lines that mention rule IDs like: \n[id \"920220\"], [id \"920270\"], [id \"949110\"], [id \"980130\"] <\/code><\/pre>\n\n\n\n<\/span>Example Error Log<\/strong><\/span><\/h3>\n\n\n\n
[Fri Jul 21 08:36:23.103004 2023] [security2:error] [pid *****:tid ***************] [client 192.0.2.1:*****] [client 192.0.2.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file \"\/etc\/opt\/kusanagi\/httpd\/modsecurity.d\/activated_rules\/REQUEST-949-BLOCKING-EVALUATION.conf\"] [line \"153\"] [id \"949110\"] [msg \"Inbound Anomaly Score Exceeded (Total Score: 10)\"] [severity \"CRITICAL\"] [ver \"OWASP_CRS\/3.3.4\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-generic\"] [hostname \"example.com.internal\"] [uri \"\/\"] [unique_id \"***************************\"] <\/code><\/pre>\n\n\n\n<\/span>Step 2: Creating an Exception (Whitelist)<\/strong><\/span><\/h3>\n\n\n\n
\n
\n
[Fri Jul 21 08:36:23.103004 2023] [security2:error] ... [id \"949110\"] [msg \"Inbound Anomaly Score Exceeded (Total Score: 10)\"] ... <\/code><\/pre>\n\n\n\n<\/span>Step 3: Add a Conditional Exception Rule<\/strong><\/span><\/h3>\n\n\n\n
<If \"%{QUERY_STRING} =~ \/.*test_query_string=.*\/ || %{HTTP_REFERER} =~ \/.*test_query_string=.*\/\"> \n\n SecRuleRemoveById 920220 \n\n SecRuleRemoveById 920270 \n\n<\/If> <\/code><\/pre>\n\n\n\n<\/span>Step 4: Restart and Verify<\/strong> <\/span><\/h3>\n\n\n\n
<\/span>5. Disabling WAF as a last resort<\/strong> <\/span><\/h2>\n\n\n\n
kusanagi waf off <\/code><\/pre>\n\n\n\n<\/span>6. Conclusion<\/strong><\/span><\/h2>\n\n\n\n
<\/span>References<\/span><\/h2>\n\n\n\n