I have been working with cPanel support for days on some mod security Mysql authentication errors and traced it back to Easy Apache not creating some files. Now that we have that solved, before installing CWAF mod_security only logged to MySQL, and not an ip.pag file which can get big, and cause major CPU overhead.
My question is, since cPanel’s mod security is logging to MySQL, is it safe to comment out SecDataDir /tmp and SecTmpDir /tmp from the modec2.conf files?
When I do it, every thing seems to operate fine, CSF still picks up rule triggers and blocks according to the settings… Seems like this might be duplicate logging in a cPanel system?
Below there are links from Mod_security reference manual:
initcol and setsid are used in some our rules.
So, you can comment out this Configuration Directives, but we cannot promise that all will work correctly.
Got it. You guys pretty much stick to standard mod_security setups and whatever cPanel does is outside of the scope (i.e. using MySQL instead if ip.pag file).
We got all this sorted out… cPanel/WHM uses MySQL to store the modsecurity logs in and using the ip.pag file for logging is redundant. This may need to be a future tweak for Comodo WAF unless they are using ip.pag for something? (comodo, care to chime in?).
We commented out two lines which stops logging to the ip.* files that can become huge when your server is under attack. Reading and writing to gigabit size will have resources hovering around 80% CPU utilization until you delete these files. Below is the commented lines we used which keeps CPU loads normal while also working with WHM’s new ModSecurity consoles.
LoadModule security2_module modules/mod_security2.so
ip.pag is not for logging. It is for ip-addresses collection, for example to prevent bruteforce.
After the back and forth on this, there still is no clear answer as to if your plugin uses that file, because the WHM mod security uses MySQL to log to?? Could you clarify the need for an ip.pag file in a cPanel/WHM environment?
When the ip.pag file gets to be 1gb in size, it causes a large strain on the server.
Yes, Comodo rules require ip.pag file as IP persistence storage for example to store IP for Brute force protection.
However according to this bugreport (IP persistence storage seems to not clean up · Issue #574 · SpiderLabs/ModSecurity · GitHub) it’s implementation in mod_securty is broken.
Of course it possible to comment SecDataDir directory out, but it will lead to non-working persistence storage dependent rules and flood logs with complains about missing SecDataDir directory.
So I’d recommend just turn persistence storage dependent rules off (Plugin - Catalog - Global - Bruteforce - OFF).
Also you can try to use SecCollectionTimeout 600 parameter to optimize ip.pag size or even try this utility ( GitHub - SpiderLabs/modsec-sdbm-util: Utility to manipulate SDBM files used by ModSecurity. With that utility it is possible to _shrink_ SDBM databases. It is also possible to list the SDBM contents with filters such as: expired or invalid items only. ) to ‘shrink’ collection.
I have a default installation of WAF (Bruteforce Off) but am still getting DBM errors. Are there other rules that use DBM storage and where would I find them?
Yes, here is a couple of such rules.
DBM storage directory is defined by SecDataDir directive.
According to manual “SecDataDir must be provided before initcol, setsid, and setuid can be used.”
Quick search through rules reveals following IDs:
210080 - initcol
210090 - initcol
219900-219903 - setsid
setuid - none
Thanks, that looks to have fixed it.
I have all the necessary directives in place but am using mod_ruid2 so I can’t use DBM rules unless I want to try it with Cloud Linux