1. When upgrading to 11.48, will the update blow away an existing ModSecurity setup
I've been running the Atomic ruleset for years on servers I maintain. I prefer to keep it that way, at least for now. If I upgrade to 11.48, is anything at all going to get changed in the process (like modsec2.conf, modsec2.user.conf) ?
2. In 11.48, is there a "restore ModSecurity to stock/default" ?
Assuming I've backed up my existing ModSec configuration and want to try out the cPanel ModSecurity Solution including OWASP rules, is there a way to tell cPanel to totally wipe out existing modsec2.conf, modsec2.cpanel.conf and modsec2.user.conf and populate them with default settings and such before I attempt to install the OWASP rules?
I really want to make sure that I won't suddenly be surprised by a nonfunctioning modsecurity when updating to 11.48, and I really want to make sure that if I want to try out OWASP I can "start from scratch" and have only the information in modsec2.conf and modsec2.user.conf that cPanel provides.
I tested out the OWASP ruleset last night, and I don't like it's defaults. First off, it appears that if a rule is triggered, the end user has no clue -- basically, the request gets redirected back to http://FQDN. So if I sent http://www.mysite.com/index.php?get=http://www.foo.bar, modsecurity would show the rule as triggering and then would redirect the visitor to http://www.mysite.com. I'm so used to having a 403 or 406 error generated, and would prefer to keep it that way.
I also noticed that when running the OWASP rules, I would often see this in the Apache error log:
[Wed Feb 04 00:47:42.437126 2015] [:error] [pid 3560] [client 66.249.64.17] ModSecurity: Rule processing failed. [hostname "mysite.com"] [uri "/robots.txt"] [unique_id "VNGyfkJUCPQAAA3o0E0AAAAC"]
With issues like that, I have a very low confidence level in the cPanel+OWASP solution at this time. Maybe it's my configuration. And that's why I'm asking if there is a way to simply tell cPanel "revert back to a stock/default configuration" after I've removed OWASP rules. Then I can start from scratch attempting to get the OWASP rules working again.
Mike
I've been running the Atomic ruleset for years on servers I maintain. I prefer to keep it that way, at least for now. If I upgrade to 11.48, is anything at all going to get changed in the process (like modsec2.conf, modsec2.user.conf) ?
2. In 11.48, is there a "restore ModSecurity to stock/default" ?
Assuming I've backed up my existing ModSec configuration and want to try out the cPanel ModSecurity Solution including OWASP rules, is there a way to tell cPanel to totally wipe out existing modsec2.conf, modsec2.cpanel.conf and modsec2.user.conf and populate them with default settings and such before I attempt to install the OWASP rules?
I really want to make sure that I won't suddenly be surprised by a nonfunctioning modsecurity when updating to 11.48, and I really want to make sure that if I want to try out OWASP I can "start from scratch" and have only the information in modsec2.conf and modsec2.user.conf that cPanel provides.
I tested out the OWASP ruleset last night, and I don't like it's defaults. First off, it appears that if a rule is triggered, the end user has no clue -- basically, the request gets redirected back to http://FQDN. So if I sent http://www.mysite.com/index.php?get=http://www.foo.bar, modsecurity would show the rule as triggering and then would redirect the visitor to http://www.mysite.com. I'm so used to having a 403 or 406 error generated, and would prefer to keep it that way.
I also noticed that when running the OWASP rules, I would often see this in the Apache error log:
[Wed Feb 04 00:47:42.437126 2015] [:error] [pid 3560] [client 66.249.64.17] ModSecurity: Rule processing failed. [hostname "mysite.com"] [uri "/robots.txt"] [unique_id "VNGyfkJUCPQAAA3o0E0AAAAC"]
With issues like that, I have a very low confidence level in the cPanel+OWASP solution at this time. Maybe it's my configuration. And that's why I'm asking if there is a way to simply tell cPanel "revert back to a stock/default configuration" after I've removed OWASP rules. Then I can start from scratch attempting to get the OWASP rules working again.
Mike