Web Application Firewall

We use ModSecurity as additional protection against application level attacks such as cross site-scripting and SQL injections. By default, the core rule set will be loaded, and we block common vulnerabilities and zero-day attacks by adding some more global rules.

Identify Blocks

If a request is blocked by the web application firewall, the HTTP status 403 will be returned. You can distinguish a 403 returned by the web application firewall from a 403 returned due to missing access rights by looking at the Apache error log file.

Apache Error Log

Details about each blocked request are available in the Apache error log file, located at ~/log/apache-error.log. You can identify the particular rule that has led to the block by looking for the [id "<rule-number>"] part within the log line.

Often, a block will be triggered by rule ID 949110. In this case, the threshold for the anomaly score was exceeded. Instead of just disabling rule 949110, and thus removing the anomaly threshold altogether, you should investigate further and disable or adapt the actual source rule.

To determine which rule triggered the anomaly score threshold, take a look at the audit log chapter below.

Tip

For details, please consult the ModSecurity documentation.

ModSecurity Audit Log

The audit log is available in ~/log/apache-waf.log. Each blocked request will be logged with all details, such as client and server headers, and in-depth details about the processed rules.

To return to the example above, we can analyze the detailed trail it took to exceed the anomaly threshold score. Such a log entry does include a section H (for example, --1d61f602-H--). The first line after the section title will be something like ModSecurity: Warning. Matched "Operator `Rx'.... This is the rule that triggers the anomaly score threshold.

Now that we have identified the root cause, you can modify the rule to allow your request, or even better, adjust your application accordingly when possible.

Tip

A detailed explanation of the available audit log parts can be found in the ModSecurity documentation.

Tip

For an easier representation and identification of the blocking WAF rules, the command waf-logparser can be used.

Custom Configuration

The rules added to the core rules set are there for a reason and do comply with the HTTP RFC. Even though, it can be required to adapt the rules instead of changing your application.

We recommend making adjustments to these rules as precisely as possible. For example, instead of disabling a rule completely, disable checking of the argument that triggered the rule for the URL on which it was triggered.

You can adjust the configuration through the ~/cnf/waf.conf file. We added some examples of common use cases to the default file, which you can copy and adjust to your needs.

Tip

To apply your changes, run waf-apply after each modification in ~/cnf/waf.conf.

Tip

For in depth details, see the ModSecurity documentation.

Disable Altogether

If you are unable to adapt the rules to your needs for whatever reason, it is possible to disable the web application altogether. You can do so by checking Disable WAF in the corresponding website’s Advanced tab.

Warning

For security reasons, we do not recommend disabling the web application firewall. Please let us know your concerns, and we will assist you in working out a running configuration.