Skip to main content

OWASP - mod security and wordpress

Silver_2000
I updated Cpanel to the version that supports OWASP and enabled it Everything seemed fine on most sites until I tried to edit a wordpress page Various issues including unable to edit pages - editing pages results in odd behavior when I disabled the ruleset - wordpress went back to normal The mod security logs showed that the text I was trying to add to a wordpress page matched some rules
958977 PHP injection attack Function name found CRITICAL 302 Request: POST /wp-admin/post.php Action Description: Access denied with redirection to http://domain.com/ using status 302 (phase 2). Justification: Matched phrase "\"" at ARGS:content.
The text I was trying to post had no code or special charcters in it. It was simply about 5 paragraphs describing some recent work. now Im a little concerned that OWASP replaced previous rulesets ... Searched for OWASP and wordpress issues and didnt find anything specific

Comments

80 comments

Date Votes
  • kernow
    Reading on the Comodo forums I see that cPanel are talking to Comodo about adding them as a vendor. Should that happen you can forget about waiting years for the OWASP rules to be sorted, just switch to the Comodo WAF rules :)
    0
  • wrender
    Infopro, I think you are a bit confused of the security model for the OWASP ruleset for ModSecurity. It is designed as a "generic attack detection" so it will always have false positives. See here:
    0
  • quizknows
    ] cPanel's implementation of this new ModSec setup is coming along great, I'm really enjoying seeing the efforts here to make all this easier for us. But, the OWASP rulesets are the weakest, untested, part of the equation right now. And, it seems for some time to come, going by the public feedback I've been reading.

    Quoted for truth.
    0
  • Vliegtuig
    ]What good does yet another github project for modsec accomplish? OWASP needs reports of false positives to make the rules any better, and you're hoping to get folks to contribute to your repository and theirs (I guess) or just yours?

    I'd gladly report issues, if the WHM interface would not keep giving me 500's... (see
    0
  • Infopro
    ]Not sure if I am the only one with this problem, but when reporting a rule, I get the following error:
    The system was unable to submit the request: curl: (22) The requested URL returned error: 500 Internal Server Error
    An additional side-effect of this error: we cannot disable it through the web interface. In particular, we are receiving a *lot* of false positives caused by rule 950901, which looks for SQL tautologies. This rule seems to be very outdated because it lacks word boundaries. This problem ahs been discussed here in 2013:
    0
  • Infopro
    ]I'd gladly report issues, if the WHM interface would not keep giving me 500's... (see
    0
  • Vliegtuig
    ]To clarify, when you see the rule in the Hits list, and then you click, More, to the right side of listing, when that area expands you see the Report this hit button, bottom left corner. When you click that, and fll in all forms and click Review Report, what happens next, exactly? Thanks.

    "Review report" works fine, but when clicking on "Submit" on the next page, I get the following error:27211
    0
  • Infopro
    Please feel free to open a ticket to cPanel Technical Support about this for closer investigation.
    0
  • JaredR.
    The problem of a 500 error when trying to report ModSecurity rule hits has already been reported to our developers. The internal case for this is 174401. There is no estimate for when this will be addressed in a public build, but when it is, it will be mentioned in our changelog by that case number. You can view our changelog at any time at this URL:
    0
  • hekri
    I also have problems with cpanel OWASP and go to
    0
  • Infopro
    Thanks for sharing that link.
    0
  • cPanelDon
    Not sure if I am the only one with this problem, but when reporting a rule, I get the following error:
    The system was unable to submit the request: curl: (22) The requested URL returned error: 500 Internal Server Error

    The problem of a 500 error when trying to report ModSecurity rule hits has already been reported to our developers. The internal case for this is 174401. There is no estimate for when this will be addressed in a public build, but when it is, it will be mentioned in our changelog by that case number.

    Case 174401 and the Internal Server Error, seen when reporting OWASP rule hits, is now resolved after corrective changes on the modsecurity.org systems that receive and process report submissions. The only other known issue with reporting at this time is from servers with an OS older than CentOS 6, such as CentOS 5, where an SSL warning is presented because the OS doesn't include a recent-enough CA bundle that is necessary to verify the SSL certificate used on modsecurity.org. This remaining issue is being tracked via internal Case 174373. Upon resolution this case number will be mentioned in an upcoming change-log entry at
    0
  • sonicthoughts
    I feel your pain of the ModSecurity OWASP false positives. It seems to be that especially with WordPress there are a lot of false positives with different plugins (Probably same reason it always gets hacked). I don't think it is really either a problem with cPanel, or with ModSecurity though. The OWASP rules for ModSecurity are designed to provide "Generic Attack Detection" so naturally they are going to block out some good web traffic to valid applications too as they are overly secure. In this case they seem to be so secure they create a lot of false positives which is a nightmare for a small business to whitelist. For us a couple of setups that are working well: Option 1 - (Commercial rules, with some basic OWASP rules enabled). 1. Buy a subscription to the Trustwave Commercial ModSecurity rules (Or other commercial mod security rule vendor), and run their application specific rules in conjunction with some of the base OWASP rules in anomaly detection mode. For example with these rules loaded in your ModSecurity Vendor Configuration: modsecurity_crs_10_setup.conf (Set to run in Anomaly Detection Mode by uncommenting that line, and increasing the 255 character limit line to something higher like 512). rules/REQUEST-01-COMMON-EXCEPTIONS.conf rules/REQUEST-10-IP-REPUTATION.conf rules/REQUEST-12-DOS-PROTECTION.conf rules/REQUEST-13-SCANNER-DETECTION.conf rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf rules/REQUEST-21-PROTOCOL-ATTACK.conf rules/REQUEST-49-BLOCKING-EVALUATION.conf rules/RESPONSE-59-BLOCKING-EVALUATION.conf rules/RESPONSE-80-CORRELATION.conf 2. And enable these commercial rules in the bottom of your /usr/local/apache/conf/modsec2.user.conf file:
    # Include Trustwave Commercial Modsecurity Rules Include conf/slr_vuln_rules/modsecurity_slr_10_ip_reputation.conf Include conf/slr_vuln_rules/modsecurity_slr_46_known_vulns.conf Include conf/slr_vuln_rules/modsecurity_slr_50_malware_detection.conf Include conf/slr_vuln_rules/owasp_crs_integration/application_specific/*.conf Include conf/slr_vuln_rules/botnet_attacks/*.conf Include conf/slr_vuln_rules/dos_attacks/*.conf Include conf/slr_vuln_rules/webshell_backdoors/*.conf
    * I think this method will always be a better way, because you are basically paying for a commercial rule set that will always have better protection with almost no false positives. (you get what you pay for!) Option 2 - (Only OWASP Rules Loaded) 1. Enable all of the OWASP rule sets in your ModSecurity Vendors. 2. Create a whitelist repository, and start whitelisting any false positives for each application. (I would strongly recommend setting up an AuditConsole server, as it will really help with this). I"ve started an OWASP whitelist repository here: /
    0
  • iso99
    I feel your pain of the ModSecurity OWASP false positives. It seems to be that especially with WordPress there are a lot of false positives with different plugins (Probably same reason it always gets hacked). I don't think it is really either a problem with cPanel, or with ModSecurity though. The OWASP rules for ModSecurity are designed to provide "Generic Attack Detection" so naturally they are going to block out some good web traffic to valid applications too as they are overly secure. In this case they seem to be so secure they create a lot of false positives which is a nightmare for a small business to whitelist. For us a couple of setups that are working well: Option 1 - (Commercial rules, with some basic OWASP rules enabled). 1. Buy a subscription to the Trustwave Commercial ModSecurity rules (Or other commercial mod security rule vendor), and run their application specific rules in conjunction with some of the base OWASP rules in anomaly detection mode. For example with these rules loaded in your ModSecurity Vendor Configuration: modsecurity_crs_10_setup.conf (Set to run in Anomaly Detection Mode by uncommenting that line, and increasing the 255 character limit line to something higher like 512). rules/REQUEST-01-COMMON-EXCEPTIONS.conf rules/REQUEST-10-IP-REPUTATION.conf rules/REQUEST-12-DOS-PROTECTION.conf rules/REQUEST-13-SCANNER-DETECTION.conf rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf rules/REQUEST-21-PROTOCOL-ATTACK.conf rules/REQUEST-49-BLOCKING-EVALUATION.conf rules/RESPONSE-59-BLOCKING-EVALUATION.conf rules/RESPONSE-80-CORRELATION.conf 2. And enable these commercial rules in the bottom of your /usr/local/apache/conf/modsec2.user.conf file:
    # Include Trustwave Commercial Modsecurity Rules Include conf/slr_vuln_rules/modsecurity_slr_10_ip_reputation.conf Include conf/slr_vuln_rules/modsecurity_slr_46_known_vulns.conf Include conf/slr_vuln_rules/modsecurity_slr_50_malware_detection.conf Include conf/slr_vuln_rules/owasp_crs_integration/application_specific/*.conf Include conf/slr_vuln_rules/botnet_attacks/*.conf Include conf/slr_vuln_rules/dos_attacks/*.conf Include conf/slr_vuln_rules/webshell_backdoors/*.conf
    * I think this method will always be a better way, because you are basically paying for a commercial rule set that will always have better protection with almost no false positives. (you get what you pay for!) Option 2 - (Only OWASP Rules Loaded) 1. Enable all of the OWASP rule sets in your ModSecurity Vendors. 2. Create a whitelist repository, and start whitelisting any false positives for each application. (I would strongly recommend setting up an AuditConsole server, as it will really help with this). I"ve started an OWASP whitelist repository here: /GitHub - wrender/modsecurity-whitelist-apps: This repository is for people to contribute common ModSecurity web application false positive whitelists. If anyone is able to help contribute I think it would be very helpful to anyone running ModSecurity with all of the OWASP rules enabled. ** This is the very labor intensive way, because there are a lot of different false positives depending on which web applications you are running.

    I'm re-thinking of using OWASP again on my new server. It's good that I've found your project. Thanks for this! I'll try to contribute as much as possible. :)
    0
  • epaslv
    My personal experience has been terrible. I enabled the OWASP ModSecurity Rules thinking they were ready for production, being available in RELEASE tier. It pretty much screwed up more that 50% of CMS sites. Various redirections not working, infinate loops, unable to login etc, and our support department spent the whole day screening issues. I quickly uninstalled it from all our servers to restore services. I am surprised they are even made available, were they even tested?
    0
  • cPanelMichael
    Hello, For others who are considering the OWASP ruleset for the first time, it's important to review the following document: OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation In particular, pay close attention to this section: What are the risks? As with any mechanism that blocks web traffic, there is the risk that the rules could block legitimate traffic (false positives). While both OWASP and cPanel, Inc. aim to curate the OWASP rule set to reduce the potential for false positives, there is a risk that the rule set may block legitimate traffic. Review theModSecurity Tools (Home >> Security Center >> ModSecurity" Tools) interface routinely to evaluate the traffic that the rule set blocks and whether these blocks affect legitimate users.
    This is a core rule set that requires monitoring and fine tuning. Thank you.
    0
  • Infopro
    While both OWASP and cPanel, Inc. aim to curate the OWASP rule set...
    I'm still looking forward to the curated rules, although it doesn't look good going by dates: github.com/SpiderLabs/owasp-modsecurity-crs/tree/master/base_rules
    0
  • hrace009
    2. And enable these commercial rules in the bottom of your /usr/local/apache/conf/modsec2.user.conf file:
    # Include Trustwave Commercial Modsecurity Rules Include conf/slr_vuln_rules/modsecurity_slr_10_ip_reputation.conf Include conf/slr_vuln_rules/modsecurity_slr_46_known_vulns.conf Include conf/slr_vuln_rules/modsecurity_slr_50_malware_detection.conf Include conf/slr_vuln_rules/owasp_crs_integration/application_specific/*.conf Include conf/slr_vuln_rules/botnet_attacks/*.conf Include conf/slr_vuln_rules/dos_attacks/*.conf Include conf/slr_vuln_rules/webshell_backdoors/*.conf
    * I think this method will always be a better way, because you are basically paying for a commercial rule set that will always have better protection with almost no false positives. (you get what you pay for!) Option 2 - (Only OWASP Rules Loaded) 1. Enable all of the OWASP rule sets in your ModSecurity Vendors. 2. Create a whitelist repository, and start whitelisting any false positives for each application. (I would strongly recommend setting up an AuditConsole server, as it will really help with this). I"ve started an OWASP whitelist repository here: github.com/wrender/modsecurity-whitelist-apps If anyone is able to help contribute I think it would be very helpful to anyone running ModSecurity with all of the OWASP rules enabled. ** This is the very labor intensive way, because there are a lot of different false positives depending on which web applications you are running.

    After find this, i would like to use OWASP again, instead commodo WAF
    0
  • bloatedstoat
    We've "so far" had to disable the following because the editor TinyMCE employed in our CMS became unusable, seems we've been more fortunate than others in that we only have a few rules triggering which have been disabled: 942360 949110 980130
    0
  • Infopro
    Closing this thread as it's related to an earlier version of OWASP rules. Please feel free to start a new thread or visit the other threads related to OWASP 3 rules if needed to continue the discussion.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post