• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Mod_Security IP persistent storage massive

websavers

websavers

Regular Pleskian
This issue affects CentOS6 running mod_security-2.9.0-centos6.16102616.x86_64
From repo : PLESK_17_0_17-extras

OS ‪CentOS 6.9 (Final)‬
Product Plesk Onyx
Version 17.0.17 Update #28, last updated on June 23, 2017 04:09 AM

The detected symptoms of the issue:
- High CPU usage on servers with lots of traffic or at least lots of domains. It's particularly noticeable as IO load if you're watching iotop or htop.
- The file /var/cache/modsecurity/ip.pag grows to be over 1GB in size

Like any apache related log file, this means heavy IO load while regularly reading and appending to this database file.

This appears to be a known (and solved) issue as described in the ModSec GitHub repo here. At the bottom of that GitHub issue is a marked solution as found here.

I'm hoping you folks might be so kind as to apply the patch/solution to the build of ModSec in the Plesk 17 extras repo to resolve this issue. Note that I think 2.9.1 doesn't even have this patch applied yet, and so it would need to be manually applied to your SRPMs in the repo.

At the moment our only usable workaround to keep the performance of our CentOS6 boxes in check is to zero out the database file every day, which isn't great for the effectiveness of Mod_Security when it's IP persistence is important for IP banning!

Thanks in advance for any help that can be provided on this issue.
 
Last edited:
Where you getting errors along the lines of "Message: collections_remove_stale: Failed deleting collection" with this issue?
And did you manage to fix it?

Also, which ruleset were you running?
 
surfgatinho said:
Where you getting errors along the lines of "Message: collections_remove_stale: Failed deleting collection" with this issue?
And did you manage to fix it?

Also, which ruleset were you running?
Click to expand...

I'm honestly not sure if there were such errors; did you find those in the audit log or in the main apache error log?

We're running the Comodo ruleset.

I wouldn't say we fixed it, but we worked around it by having a cron job run daily like this: cat /dev/null > /var/cache/modsecurity/ip.dir && cat /dev/null > /var/cache/modsecurity/ip.pag. Clearly it's not optimal for security, but neither is the complete and utter destruction of performance on all of our busy servers.
 
I found the errors in both the audit log and the apache logs.

This only started happening to me when I changed over to the Comodo ruleset. When I use the OSWAP ruleset it bans practically everything but the ip.pag file doesn't grow.

Makes me wonder if the issue is with the Comodo ruleset. I might try OSWAP again but introduce it one rule at a time...
 
surfgatinho said:
I found the errors in both the audit log and the apache logs.

This only started happening to me when I changed over to the Comodo ruleset. When I use the OSWAP ruleset it bans practically everything but the ip.pag file doesn't grow.

Makes me wonder if the issue is with the Comodo ruleset. I might try OSWAP again but introduce it one rule at a time...
Click to expand...

According to the bug report I linked to on GitHub, the fix for this issue comes out of the persistent storage collection name not being passed properly through to the storage DB. In other words, my bet is on OWASP not naming their collection and thusly using default_ as the collection prefix (which works fine) vs. Comodo naming their collection (perhaps something like comodo_) which doesn't work because of that bug.

Technically Comodo would be doing it according to spec (the right way) but that bug causes the problem. If my guess is correct, then it's still up to Plesk to include that patch in their build of mod_security. Once fixed, then Comodo's namespace would no longer suffer from the bug and therefore removal of records from persistent storage would proceed as it's expected to.
 
Same issue here with Centos 7.4 - after a couple of weeks, /var/cache/modsecurity/ip.pag size is 12G !!! Clearly an issue when using Comodo rules.
thx for the daily script to clear the /var/cache/modsecurity/ip.pag file.
 
UFHH01 said:
Hi Alban Staehli,

pls. note, that CentOS 7.4 is ( not yet ) supported by Plesk ( pls. see: => Question - Plesk Onyx & CentOS 7.4 compatible? ). The expected official announcement is scheduled to 25. september, where ( possible ) Plesk updates/patches could be included. ;)
Click to expand...

Hi @UFHH01 ,
Thx for your feedback - I've even commented the post in regards to Centos 7.4 last Monday as I did a successful upgrade.
But, please, note that the size of /var/cache/modsecurity/ip.pag was already huge prior to last Monday - I checked a backup. Therefore, it's not a bug related to Centos 7.4, but as mentioned by @websavers , the issue seems to be more related to the use of Comodo rules and ModSec under Plesk.
Cheers
 
You must log in or register to reply here.

Similar threads

A
Forwarded to devs Mod_Security (with Comodo ruleset) IP persistent storage not being cleaned/rotated
Replies
11
Views
3K
websavers
websavers
Back
Top