[Case 161501] OWASP - mod security disabled by upcp?
I enabled the OWASP ruleset on my server when it was upgraded to 11.48 and when visiting Home "Security Center "Hits List it was clear the ruleset was blocking a lot of malicious traffic.
However, the next day I looked at the Hits List and there were no new hits after 4:30am (which is about when upcp runs). OWASP was still enabled according to the GUI but I forced it to be disabled and then re-enabled and the Hits List started showing more hits again.
The same thing happened today. No new hits after 4:30am. Disable/re-enable... more hits.
Anyone else seeing this?
-
Hi, Yes this happened to us at exactly the same time as you. If you go into the mod security vendors section and disable and then enable the rules it fixes it. 0 -
I was able to reproduce this. Enable OWASP vendor, /scripts/upcp, httpd restart, and boom; no modsec. I tracked it down to modsec2.cpanel.conf. The line SecRuleEngine "On", as well as all vendor directives, were removed from modsec2.cpanel.conf during the upcp. No SecRuleEngine setting means no rule enforcement at all. At least if OWASP is not enabled, the config seems to stay intact through upcp and the custom rules in modsec2.user.conf are still working. With OWASP enabled, this error results in both the OWASP rules and custom rules in modsec2.user.conf being effectively disabled. 0 -
There is a resolved case on this, I've modified the thread title with the case ID. A fix is on the way. and boom; no modsec.
I'm not sure if its a great idea or not, but I've left my own rules and includes to them in place after enabling the new vendor supplied rules. They are not affected by this issue of the modsec2.cpanel.conf file being wiped.0 -
Excellent. Thanks all. 0 -
]There is a resolved case on this, I've modified the thread title with the case ID. A fix is on the way. I'm not sure if its a great idea or not, but I've left my own rules and includes to them in place after enabling the new vendor supplied rules. They are not affected by this issue of the modsec2.cpanel.conf file being wiped.
Thanks for the update. Regarding leaving your own rules in place, it should generally be fine to leave them and add OWASP on top of that. Once the kinks are worked out of the OWASP rules, I've already ensured they will work on top of my already extensive modsec2.user.conf file. Your custom rules won't be affected by modsec2.cpanel.conf being wiped if (and only if) you have "SecRuleEngine On" in your modsec2.user.conf (or elsewhere if you're using more custom includes files). If you do not, then the rules won't do anything once that line is removed from modsec2.cpanel.conf, since ModSecurity won't process any rules without that line somewhere in the apache config. My rules worked OK after upcp until httpd was restarted. It threw me for a loop the first time I tested this bug. It looks like httpd doesn't restart after upcp, so ModSecurity would continue to work with its prior config until httpd restarts and has no SecRuleEngine directive in the config files. Anyway, If I remember right, the SecRuleEngine was enabled in modsec2.conf prior to 11.46, then moved to modsec2.cpanel.conf in 11.46. I've always relied on the SecRuleEngine being enabled outside of modsec2.user.conf, which has worked fine for the last 5+ years.0 -
] I've modified the thread title with the case ID.
You forgot to modify the thread title correctly, it should read Beta OWASP or should that be Alpha OWASP ? "sigh" man this script and rule set is a bloody mess. Sorry for the sarcasm, but really...........where was the quality control?0 -
I understand the sarcasm here. You and I both know of the many, many threads on these forums over the years having to do with ModSec, I'm sure. With that in mind, this is a really nice setup to make it easier for all to secure their servers better. cPanel will fix this, and it will be great. 0 -
I'm sure they will fix it. :) Its just that it would have been so much better if cpanel had said something like: With this new 11.48 release we introduce OWASP [COLOR="#FF0000">Note this has not been fully tested in a production environment but we would welcome your input. Please test this script and rule set out and let us know of any problems. We have created a topic on the support forums where you can post your views or any errors you may have found.
Something like the above would have saved sytem admins hours of work ( because most would not have installed it) fixing the rule set and explaining/apologising to countless clients why their CMS /WHMCS aren't working.0 -
]I'm sure they will fix it. :) Its just that it would have been so much better if cpanel had said something like: Something like the above would have saved sytem admins hours of work ( because most would not have installed it) fixing the rule set and explaining/apologising to countless clients why their CMS /WHMCS aren't working.
I absolutely agree with this. I love cPanel software, and I think cPanel support is great. I knew [in the back of my mind, really I did] that there was no way the 11.48 deployment of all the new ModSec stuff was going to go off well. You guys know a lot, but I really didn't have much faith that cPanel internally was going to vet all of these rules and make the necessary exceptions by default for common applications. I don't know of any ruleset other than Atomicorp rules [when configured per their recommendations on a cPanel server] that generate very few false positives, actually work, and give you confidence that it is working because you can test them and see the 403 errors. I hate to criticize, but absent a paragraph such as the one Kernow suggested above, QA dropped the ball. The rules either work and block way too much legitimate hosting content, or they don't work, or they might work but give you no confidence that they are when you see notations in the error_log that rule processing failed, or UPCP updates break the functionality. I have no doubt cPanel will get it right, but the general public should have been informed from the onset that there were likely to be issues and that if they used ModSecurity with cPanel's own configuration [and especially with the OWASP vendor], they should expect to have issues initially that may require support. This is specifically why I thought to ask before I updated my servers. Incidentally, I didn't update any of my servers to 11.48 for this reason. I don't even have faith that the 11.48 will leave my current Atomicorp configuration 100% untouched. And a proper working modsecurity setup / ruleset is extremely important to me. I don't want to update to 11.48 and have to spend even 5 minutes on a server getting things to work should something go wrong as part of the update process. I might be willing to, but only if I'm told ahead of time that it might be a problem. Mike PS: There also does need to be a one-click option that is guaranteed 100% to restore the modsecurity configuration back to cPanel's default [that it would come with if you just installed 11.48 from scratch, sans any OWASP]. Having that available will at least allow somebody to get Apache back up and running if it fails on a restart because of bad rules or misconfiguration, or disable rules instantly if an admin suddenly gets an onslaught of complaints that its blocking a ton of legitimate activity. Of course, anybody running another configuration [like Atomicorp rules] should have their configurations backed up anyway.0 -
upcp is still messing up modsec2.cpanel.conf if OWASP rules are enabled. Please fix this ASAP... everyone who has enabled these rules is now potentially at more risk. 0 -
]upcp is still messing up modsec2.cpanel.conf if OWASP rules are enabled. Please fix this ASAP... everyone who has enabled these rules is now potentially at more risk.
Agreed. This one bugs me. This appears to be fixed up this morning.0 -
Fix looks good, verified with upcp run. Thank you :) 0
Please sign in to leave a comment.
Comments
13 comments