ModSecurity and later ModSecurity2 used to be an Apache dependent module hosted by Trustwave in earlier years and hosted on Github now under v2 and v3 which turned into a complete rewrite called LibModSecurity now (v3), a standalone Web Application Firewall supporting all Webservers.

ModSecurity's basic functionality can be explained in the way that it applies a set of fine grained rules to the activities of software run on Apache (and now on any other webserver) on the application level (after the outer firewall level). It is used by some hosting environments to assure security.

But some rules can interfere with the normal operation of Drupal or other big Applications like Nextcloud etc. But since each ModSecurity administrator can write their own rules, it is impossible to be certain that Drupal does not get caught up in these rules in a bad way. So, simply enabling LibModSecurity (v3) oder ModSecurity2 (v2) can cause that you are not able to update your Drupal installation or to save nodes because of False Positives blocking actions on Drupal, which can be checked in the ModSecurity logs on the server.

NOTE: This part below needs rework(!) since this is not up-to-date and belongs to older versions of ModSecurity. Please help to make this docs up-to-date.

It is possible for Drupal to get caught correctly. Before implementing the solutions below to turn off part or all of ModSecurity, be sure that Drupal is being caught improperly. Be certain that the activity being stopped is not due to some malicious or potentially dangerous activity and that the security of your site will not be compromised.

It is possible, given the right permission or cooperation from your hosting company, to either turn off specific rules for your site or turn ModSecurity off entirely for your VirtualHost.

Reporting Bad Rules to ModSecurity

Sometimes, ModSecurity rules that catch Drupal doing valid things are simply unneeded or over-reaching. You can help ModSecurity consider stronger and more precise rules that will benefit the whole ModSecurity community by submitting them as bugs upstream and encouraging them to fix the rules. In the mean time, you'll probably want to turn the rule off as described below.

You can report problems with ModSecurity's rules through the ModSecurity Bug Tracker. If you are using a different rule set, you may need to report your problems to the maintainer of your rule set.

Turning off a Rule

If you can find the errors put in the logs when your Drupal installation fails, you can identify the Rule ID and the location. Using this information you can disable a rule based on a path. Here is an example based on a rule ID of 990011 that interferes with the Drupal update script at /update.php. In many environments, these log entries are not available to the hostee and must be examined by the hoster.

Here is an example of a what will appear in the logs. You'll note the Rule ID and path are bold.

[Wed Jan 20 11:43:01 2010] [error] [client 2.1.6.1] ModSecurity: Access denied with code 501 (phase 2). Match of "rx (?:^(?:application\\\\/x-www-form-urlencoded(?:;(?:\\\\s?charset\\\\s?=\\\\s?[\\\\w\\\\d\\\\-]{1,18})?)??$|multipart/form-data;)|text/xml)" against "REQUEST_HEADERS:Content-Type" required. [file "/etc/apache2/modsecurity_crs/modsecurity_crs_30_http_policy.conf"] [line "69"] [id "960011"] [msg "Request content type is not allowed by policy"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [hostname "d6test.domain.com"] [uri "/update.php"] [unique_id "R5esoc-ASakAAHGeOqAAAAAI"]

<LocationMatch "/update.php">
        SecRuleRemoveById 960011
</LocationMatch>

Turning ModSecurity Off

If you can change the VirtualHost record, this may be used to turn off ModSecurity for a specific VirtualHost.

<ifModule mod_security2.c>
        SecRuleEngine off
</ifModule>