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.

Tip

Certain rules can directly lead to blocking a request, while others (similar to rules in a spam-filter) do not right away block the request and just add some points and once the sum of points is over a threhold, the request is blocked.

The rule 949110 is the threshold rule, ignore it when you see it in the logs as it’s the result of other rules that matched, but not the underlying source of the problem.

Also do not disable this rule, instead find the rule(s) that effectively led to the blocking and tweak/disable those if needed.

To determine which rule(s) triggered the anomaly score threshold for a single request, you can lookup further details with the following helper function:

waf-why "SEARCH"

Where SEARCH can be either (a part of) the requested URL path - or the Request-ID from the 403 error page delivered to the browser. This will then list, which ModSecurity Rule IDs have led to the block based on the current error log file.

Once you have one or multiple Rule IDs, you can look them up via your preferred search engine. If the ID is in the Range 900’000 to 999’999, it’s an OWASP Core Ruleset rule and you can find the details in https://github.com/coreruleset/coreruleset/tree/main/rules.

If you want to find out which rules have triggered the most, you can you can use the following helper alias to get a list with the top 50 rules by number of blocked requests.

waf-filtered
waf-filtered --all

The logs are taken from either the current error log file or with --all from all available error log files.

This also works if you’re running the WAF in “detect-only” mode while testing (see further down on this page).

Tip

For details, please consult the ModSecurity documentation.

ModSecurity Audit Log

The audit log is disabled by default to save server resources and disk-space.

If required temporarily for debugging, it can be reactivated by putting the following configuration into ~/cnf/waf.conf of the website for which the audit log should be activated:

SecAuditEngine RelevantOnly

After applying this configuration via waf-apply, the audit log is getting written to ~/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 in the Audit Log. But first we need to activate the Audit Log as described above and then perform the request that’s blocked once again to capture it in the Log.

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.

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 firewall altogether. You can do so by checking Disable WAF in the corresponding website’s Advanced tab in the cockpit.

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.

Testing your configuration

Instead of completely disabling the web application firewall, it might be more useful to (temporarily) run it in a “detect-only” mode, so the rules apply, logs get written - but no requests get actively blocked.

To do so, set SecRuleEngine DetectionOnly in ~cnf/waf.conf and then apply the configuration with waf-apply.

Warning

Do not forget to revert this change after your tests and make sure the WAF is active and blocks malicious requests!