The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

[Case 161501] OWASP - mod security disabled by upcp?

Discussion in 'Security' started by Mysticeti, Feb 6, 2015.

  1. Mysticeti

    Mysticeti Well-Known Member

    Joined:
    Sep 16, 2002
    Messages:
    45
    Likes Received:
    2
    Trophy Points:
    8
    Location:
    Southern NH
    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?
     
    October likes this.
  2. kernow

    kernow Well-Known Member

    Joined:
    Jul 23, 2004
    Messages:
    867
    Likes Received:
    9
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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.
     
  3. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    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.
     
    #3 quizknows, Feb 6, 2015
    Last edited: Feb 6, 2015
    October likes this.
  4. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,482
    Likes Received:
    203
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  5. Mysticeti

    Mysticeti Well-Known Member

    Joined:
    Sep 16, 2002
    Messages:
    45
    Likes Received:
    2
    Trophy Points:
    8
    Location:
    Southern NH
    Excellent. Thanks all.
     
  6. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    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.
     
    #6 quizknows, Feb 6, 2015
    Last edited: Feb 6, 2015
  7. kernow

    kernow Well-Known Member

    Joined:
    Jul 23, 2004
    Messages:
    867
    Likes Received:
    9
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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?
     
    #7 kernow, Feb 7, 2015
    Last edited: Feb 7, 2015
  8. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,482
    Likes Received:
    203
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  9. kernow

    kernow Well-Known Member

    Joined:
    Jul 23, 2004
    Messages:
    867
    Likes Received:
    9
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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.
     
  10. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    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.
     
    October likes this.
  11. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    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.
     
  12. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,482
    Likes Received:
    203
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Agreed. This one bugs me.

    This appears to be fixed up this morning.
     
    #12 Infopro, Feb 10, 2015
    Last edited: Feb 10, 2015
  13. Mysticeti

    Mysticeti Well-Known Member

    Joined:
    Sep 16, 2002
    Messages:
    45
    Likes Received:
    2
    Trophy Points:
    8
    Location:
    Southern NH
    Yes. Fixed in 11.48.0.11

    https://documentation.cpanel.net/display/ALD/11.48+Change+Log

    11.48.0.11
    2015-02-10
    Fixed case 153365: Upgrade roundcube from upstream to 1.0.5.
    Fixed case 159129: Undo: "Block upgrade if MySQL has max_user_connections > MAX_SIGNED_INT.".
    Fixed case 159585: Don't remove minified files when cleaning locales.
    Fixed case 160601: Fix display and deletion of email forwarders.
    Fixed case 160649: Autodiscover fails if autodiscover_host does not start with autodiscover.
    Fixed case 160753: Remove pixman as a required distro RPM to upgrade/install 11.48.
    Fixed case 160901: Ensure that cPHulk is usable on dnsonly systems.
    Fixed case 160921: Ensure cphulkd cleans up all children instead of just one.
    Fixed case 160929: Adding to cPHulk Black/Whitelist from email notice.
    Fixed case 160953: Attempt to repair cPHulkd tables if they are crashed.
    Fixed case 161033: Make MySQL use an init script to start and stop by default.
    Fixed case 161093: ServiceManager should use safe_shutdown_local_mysql.
    Fixed case 161501: Fix Mod Security bug where update attempts disabled vendor rules.
     
  14. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    942
    Likes Received:
    57
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    Fix looks good, verified with upcp run. Thank you :)
     
Loading...

Share This Page