Further adventures in Plesk, Comodo, & mod_security

Further issues today with Plesk, Web Application Firewall (mod_security on Apache2) and also looks specific to the Comodo ruleset. This is not the first time I have had an issue with Plesk and Comodo ruleset. On this instance, the user was finding themselves facing blank pages, and eventually a block thanks to fail2ban. The main theme was as follows: “ModSecurity: collection_store: Failed to access DBM file” with variations including global, ip and default_SESSION.

Looking in the logging for the user I found the following:

[client123.123.123.123] ModSecurity: collection_store: Failed to access DBM file “/var/cache/modsecurity/default_SESSION”: No such file or directory [hostname “blah.tld”] [uri “/wp-admin/admin.php”] [unique_id “Wg1kTrpC@b-DVE16kvFnUQAAAME”], referer: https://blah.tld/someothercontent

[client123.123.123.123] ModSecurity: collections_remove_stale: Failed to access DBM file “/var/cache/modsecurity/global”: No such file or directory [hostname “blah.tld”] [uri “/wp-admin/admin-ajax.php”] [unique_id “Wg1kT2hQoUxGFrtb29hTkQAAAEs”], referer: https://blah.tld/someothercontent

[client 123.123.123.123] ModSecurity: collections_remove_stale: Failed to access DBM file “/var/cache/modsecurity/ip”: No such file or directory [hostname “blah.tld”] [uri “/wp-admin/admin-ajax.php”] [unique_id “Wg1kT2hQoUxGFrtb29hTkQAAAEs”], referer: https://blah.tld/someothercontent

A very quick Google tied that down to what appears to be related to a similar Plesk KB Article that is – at the time of writing 16 days old – so just over 2 weeks.

The Plesk KB article names “mod_security2: Failed to write to DBM file “/var/cache/modsecurity/ip“: Invalid argument” runs through a similar but unrelated issue – however, it was all I needed to see to resolve this really.

The folder that it is trying to write to – very simply put – is not there. So yes – it is going to have trouble accessing that.

# ls -ld /var/cache/modsecurity/
drwxr-xr-x 2 apache root 4096 Jun 29 18:37 /var/cache/modsecurity/

Are you seeing that? If you are not seeing that – then “there’s your problem.”

Creating the folder is going to stop a lot of pain – assuming that it creates the files it is looking for.

I ran through the other steps there to avoid running into the issue having already found two issues and upset the same user twice with it.

So to run through the suggested steps:

====> PLESK KB ARTICLE <====

  1. Connect to the server using SSH.
  2. Install the latest version of comodo ruleset where the issue is resolved (1.142):

    # /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php -f UpdateModSecurityRuleSet

  3. Make sure that the version is 1.142 or higher by the following command:
    • for RedHat-based OSes

      # cat /etc/httpd/conf/modsecurity.d/rules/comodo/rules.dat

    • for Debian-based OSes

      # cat /etc/apache2/modsecurity.d/rules/comodo/rules.dat

If it does not help, use one of following workarounds:

  1. Switch off and then switch on ModSecurity in Tools & Settings > Web Application Firewall (ModSecurity).
  2. Use modsec-sdbm-util with -k key to remove expired elements from ip.pag.
    The information regarding this utility can be found here.
  3. Reduce SecCollectionTimeout to 600 sec (the default value is 1 hour). This option specifies the time-out after which old records in IP collection storage are deleted. It should help to prevent /var/cache/modsecurity/ip.pag growing.

    For doing this open Tools & Settings > Web Application Firewall (ModSecurity) > Settings > and specify following value in Custom directives:

  4. Create /var/cache/modsecurity/ directory if it does not exist with the following permissions:

    # ls -ld /var/cache/modsecurity/
    drwxr-xr-x 2 apache root 4096 Jun 29 18:37 /var/cache/modsecurity/

  5. If ip.pag file is present in /var/cache/modsecurity/, and has huge size, clear it:
    – Switch off ModSecurity in Tools & Settings > Web Application Firewall (ModSecurity).
    – Run the following command to clear the file:

    # echo “” > /var/cache/modsecurity/ip.pag

    – Switch on ModSecurity.

  6.  De-activate Bruteforce or/and Initialization rule in Tools & Settings > Web Application Firewall (ModSecurity) > select Bruteforce from the list of active rules and move to deactivated > OK:
    2017-10-05_20_06_23-Web_Application_Firewall_-_Plesk_Onyx_17.5.3.png

====> PLESK KB ARTICLE <====

Entertainingly at the bottom, they say to contact Comodo or ModSecurity for support. The last issue I had with ModSecurity and Comodo was down to Plesk web interface.

I found that creating the folder it was looking for with the permissions suggested above, and creating a blank IP file seems to get the ball rolling nicely.

Given that fail2ban is on the door for brute-force attempts and watching the output of mod_security – I was quite happy to disable this rule set for this host.

On completion, the issue evaporated, and I am no longer seeing these errors in the user’s control panel. Happy days.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this:
Skip to toolbar