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

 

[brianc]

OWASP ModSecurity Rule unusable

My server updated to 11.48 and along came the new OWASP ModSecurity ruleset. The only problem is that it is completely unusable. My IP address has been blocked multiple of times doing routine work within WordPress and WHMCS. The only way I can access my sites is to completely disable the rule set.

I check the logs and I cannot find which rules are triggering the block nor is anything showing up in any of the logs. The block is just as if I was blocked by a firewall which I am not because I checked both CSF and cPHulkd. I am also able to access WHM just not my two sites on the server.

So I have some questions cPanel Techs:

1. How is this new ruleset blocking IPs?

2. Why is there no trace of rules being violated in the logs? There were two initial rules that I triggered that I was able to disable but the blocks continued but there were no more rules being listed.

 

[quizknows]

Re: OWASP ModSecurity Rule unusable

There should definitely be information in the apache error_log or the modsecurity audit log.

The OWASP rule set is a bit advanced... I didn't think they would include it in that form. I was hoping they would strip out some of the troublesome rules and test it better against common CMSes before simply putting it into WHM.

I run a custom rule set, so I definitely will not be enabling the OWASP rules any time soon. They're good rules but generally there are at least 5-10 you need to disable for most modern CMS software to work; which ones you need to disable will vary based on the software you use for your site(s).

It's important to note the ModSecurity itself only blocks requests, not IP addresses, but if you use CSF then LFD will block your IP for repeat modsecurity entries in the logs from your IP tripping rules.

To be fair I think cPanel is on the right track, but there's a serious lack of knowledge in the industry surrounding ModSecurity in general. That is really sad, because it's honestly the best tool you can use to block a huge variety of attacks and exploit attempts against websites. The new tools, while useful, are still a bit tough to use without a good understanding of ModSecurity to begin with.

 

[cPanelMichael]

Re: OWASP ModSecurity Rule unusable

Hello

You mentioned checking log files. Did you check /usr/local/apache/logs/error_log or were there other log files that you checked?

Thank you.

 

[brianc]

Re: OWASP ModSecurity Rule unusable

I checked everything in /etc/httpd/logs and nothing showed up except the two previous hits. This is bad to have a rule totally block access to two sites and nothing shows in the log files. The only thing that allowed me access was disabling the entire ruleset.

Brian

- - - Updated - - -

I checked CSF and I was not being blocked by it. However I did disable it to make sure but nope, I was still being blocked.

 

[kernow]

Re: OWASP ModSecurity Rule unusable

This rule set from OWASP is a load of rubbish. As soon as we enabled it clients complained of not being able to acces wp-admin or if they could they could'nt edit posts. Other clients said they were unable to make posts to wordpress sites. We have spent the last few hours disabling many of the rules.
cpanel 11.48 release notes

Through the guidance of OWASP, cPanel now distributes a curated set of these rules

Did you not think to at least try these out on a production server?

 

[Echelon17]

OWASP: False Positives

You guys really screwed the pooch with the latest release. The OWASP rules are terrible and it's pretty obvious they haven't been tested very well. Within minutes of activating it I've seen the following false positive ID's being triggered from a single Wordpress website:

950120
981257
981243
960015
981044
981049
950901

Can you please let us know who/where we report false positive ID's that require investigation?

 

[axwell]

Re: OWASP ModSecurity Rule unusable

I have the same the issues.
Rules are blocking a lot of legitimate users including me.

Login stopped working in WHMCS on IE
PIWIK Analytics stopped working
Owncloud client no syncing anymore
Pages are redirected in a infinite loop (sometimes)
And a lot more...

Rules are s***

The 2nd issue is with mod_ruid2, a lot of conflicts i had to disable (Jailshell) so modsecurity could write the files.

The 3rd issue modsecurity can't write to secdatadir
"ModSecurity: collection_store: Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied"
This is obviously a issue with user perm. The ip files are created after deletion with a virtualhostuser. (first serverd by apache?)
After that the other users can't write to IP files. Solution is to allow other RWX. But is not normal.

 

[4u123]

Re: OWASP ModSecurity Rule unusable

Same issues here - mainly lots of sites with some sort of infinite redirect loop and PHP scripts with redirection limit errors too. I've had to disable the rules completely.

 

[Infopro]

Multiple ModSec related threads merged here.

 

[BobHoliday]

Yeah me too. Lots of sites killed for varying reasons so I've disabled OWASP.

Does anyone know if the rules in CSF/LFD ModSec Control are automatically updated at all? I'm currently only using those but don't recall updating them for some time (ever).

I like the idea of using OWASP but not if it's going to kill most of my sites, or parts of them.

Mine are all custom made - not with CMS off the shelf stuff. About 50 of them. Too many to check in detail very often.

 

[Infopro]

Does anyone know if the rules in CSF/LFD ModSec Control are automatically updated at all? I'm currently only using those but don't recall updating them for some time (ever).

CSF does not provide rules. ConfigServer ModSec control tool is for managing existing rules on your server. New or old rules and the configuration options it does provide.

The new Mod Security implementation in cPanel does not replace your existing rules, it leaves them in place. These new rules just added will be updated with cPanel if you have updates enabled, here:
WHM » Security Center » Manage Vendors

You will need to track your hits a bit to see which rules are being tripped that you don't want to be, and take appropriate action:
WHM » Security Center » Hits List

Until you #remark out your own Includes for your existing rules, or just plain remove them, they are in play right along side the new rules provided by OWASP for cPanel.

 

[Brian]

The OWASP Rule Set is something that we definitely expect is going to further mature over the next weeks/months. When we investigated using a curated rule set for cPanel & WHM, we reached out to OWASP and asked them what they felt their biggest roadblock was.

Unilaterally, the response was that they seem to never get much feedback on the ruleset which leaves them will similarly little to go on for curating problematic rules. We wanted to help out when we deployed OWASP on cPanel & WHM.

With that, we've developed a reporting feature with the OWASP rule set in 11.48 so that users can directly send these reports to OWASP and they can resolve them. Right now this direct reporting feature is unavailable while OWASP is working to setup their end of the system to receive the reports cPanel users will submit. When this is available, you will notice a new "Report" button on each log entry in the ModSecurity Hits List page. The idea being, over time, the rule set becomes absolutely rock solid.

This isn't to say that we didn't review the OWASP rule set or otherwise knowingly deployed a rule set that would cause wide spread problems. We did test the OWASP rule set internally with popular CMSs (like WordPress), popular forum software (like phpBB), and more. We did run into some initial problems and either make curation changes at the cPanel distribution level or OWASP themselves resolved them. So, when we deployed this rule set we did believe that a reasonable effort was made to make them work out-of-the-box. However, as many know, ModSecurity rules are rarely so cut and dry. It is not surprising that, despite our internal testing and exercising the rules against real world scripts, that there are still some rough edges.

What I recommend is what we recommend on our ModSecurity OWASP CRS Rule Set page (this is the same article linked to from the feature showcase pop-up that alerts you to OWASP's availability)

https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Essentially, as with any rule set (OWASP or otherwise), there is always a risk of false positives when deploying traffic blocking rules of any sort (be it firewall, anti-spam, modsecurity, or otherwise). What we advise is turning ModSecurity into "report only" mode by setting SecRuleEngine within the ModSecurity Configuration section of WHM to "Process the rules in verbose mode, but do not execute disruptive actions.".

From there, you can see what traffic *would* be blocked without actually blocking any traffic. If false positives seem apparent, you can then disable the rules and report them to OWASP/cPanel before turning SecRuleEngine back onto its active mode.

I've passed this thread on to the contacts at OWASP we've been working with, as this feedback is precisely what they're looking for to further go after improving the rule set. This should be a much more direct process when the report feature is active and you can report the rules direct to OWASP straight from WHM. As OWASP makes changes upstream to the rule set, they will automatically update on your server within 24 hours (as part of the normal cPanel update mechanism).

 

[kernow]

Thanks for the explanation.
Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.

 

[quizknows]

We did test the OWASP rule set internally with popular CMSs (like WordPress), popular forum software (like phpBB), and more.

Whoever did that testing was asleep at the wheel. I couldn't even access a wordpress or phpbb site without flagging ModSecurity errors; forget about POST requests.

Hopefully we can help mature the rule set without everyone getting too frustrated to even want to use it any more. I feel like a LOT more QA or beta testing should have been done.

 

[Echelon17]

@Brian: Thanks for your response. I look forward to a 'report' feature, since I have a feeling it's going to be used quite heavily when live...

Can you tell us more about how the rule updates will work? I see there's an option to keep them automatically updated, but how and when will this trigger? Via regular automatic updates like cPanel presently does, or will it only update via EasyApache? Who is maintaining these rule updates? Yourself or OWASP?

Can you also tell us more about how compatible these rules are with Litespeed? Litespeed does not have the same mod_security implementation that Apache does, obviously, so it may be useful for multiple sets of rules depending on which software is installed. I understand you're currently not likely to support Litespeed, but it's something to bear in mind given the large number of hosting providers using it.

In regards to testing the rules against Wordpress etc, I'm sorry but you really couldn't have tested them for very long or even at all. Every single server I deployed the rules on was throwing up huge numbers of false positives. From things like busier sites triggering DoS warnings to people literally being unable to login to their admin pages on quiet sites, or make very basic edits to posts in their blogs because the rules thought they were SQL injecting themselves. I think my personal favourite was that one customer accessed their Wordpress site backend without the 'www' prefix and because Wordpress was set to use the www prefix, it redirected them to a login page on the www. variant of the domain. The current rules considered that a cross-site attack (because the referer didn't match) and blocked it completely, denying access to the site for the client.

If you're going to release, or at least provide rules like these, whoever is maintaining them really needs to test them thoroughly and ensure that they work "out of the box" on common software such as WHMCS, Joomla, Wordpress, et all. I know that's hard to do unless you test on a production server, but some of the false positives here are very obvious and simple stuff.

@kernow: With respect, Comodo's WAF rules are also a mess and have an insane number of false positives with them out of the box. I've personally reported in the region of 40-50 false positives rules to them in the last 6 months alone.

I see the potential benefit of adding them as a vendor, but they are by no means a perfect ruleset provider.

 

[Silver_2000]

Wow - Glad I posted and glad Im not the only one with issues

 

[Brian]

Thanks for the explanation.
Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.

Given what we're doing with OWASP is more than just a copy/paste of the rule set and we have automation curation processes/steps to make sure the various paths/rules comply with cPanel & WHM systems, we are not currently considering additional cPanel distributed rule sets at this time. We evaluated Comodo WAF along with a few others when we initially started in on the project of including a rule set to cPanel & WHM, but ultimately we decided to go with OWASP for various reasons -- such as their creators' responsiveness and extensive history.

However, this does not preclude Comodo WAF or any other organization/person from extending the same benefits that OWASP has if they choose to maintain it. Any individual/organization has the ability to create what's called a "ModSecurity Vendor". What this essentially means is they'd host a simple file that defines their ModSecurity Rule Set and where to get it. Then, any cPanel & WHM server owner can plug that URL into the ModSecurity Vendors section of WHM and receive auto-updates from the custom vendor.

Hosting providers can even extend this to provide their own customers with a unified auto-synchronized auto-updated ruleset of their own or that supplements OWASP/other rulesets.

I would definitely welcome Comodo WAF, ASL, and others participate in this functionality. The full process on how to create a ModSecurity Vendor is located here:

http://documentation.cpanel.net/display/CKB/How+to+Create+a+ModSecurity+Vendor

The mechanism even allows the curators of those custom vendors to define a report URL for their users to report bad rules to.

So the short answer to that question is that, while we're not looking to add additional rule sets at this time, there are tools we've developed that would allow Comodo WAF (or anyone else) to implement their ModSecurity rules in the same way we've implemented OWASP's rules.

 

[kernow]

@kernow: With respect, Comodo's WAF rules are also a mess and have an insane number of false positives with them out of the box. I've personally reported in the region of 40-50 false positives rules to them in the last 6 months alone.
I see the potential benefit of adding them as a vendor, but they are by no means a perfect ruleset provider.

That many eh? Thankfully we only had to remove 3 rules on our servers running WAF

 

[ashworth102680]

Thanks for the explanation.
Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.

Seconded. I was about to ask the same thing!