Community Support Forums

Re: Mod Security ( Random 503/403 Errors )

2011-11-20T19:37:39-05:00

Update. Raam Dev recently discovered that suPHP can cause a problem in some cases also.
Please take a quick look at this thread to rule this out before you give up.
See: viewtopic.php?f=4&t=14619&p=53536#p53526

Statistics: Posted by Jason Caldwell — November 20th, 2011, 7:37 pm

Re: Mod Security ( Random 503/403 Errors )

2011-11-10T11:01:30-05:00

Thanks for all of the tips. I am thinking about switching and running my own dedicated server or some type of cloud service. I'll have to bookmark this post so that I can save myself some headaches associated with mod_security. I will definitely be referring back to how I can disable it inside my httpd.conf file with something like you suggested.

Statistics: Posted by webamin — November 10th, 2011, 11:01 am

Re: Mod Security ( Random 403 Errors )

2011-09-14T01:21:47-05:00

98% Resolved ( Please Report Bugs In This Thread )

This seems to resolve the issue now with HostGator. Great support they have!

The latest from HostGator on this issue:

Hello Jason,

I have globally whitelisted all url's using s2member from all rules I have seen hit after a farm wide search for Mod_Security hits for s2member.

David N.
Network Security and Support
HostGator.com LLC
http://support.hostgator.com

Statistics: Posted by Jason Caldwell — September 14th, 2011, 1:21 am

Re: Mod Security ( Random 403 Errors )

2011-09-13T17:38:46-05:00

50% ( Resolved? ) response from HostGator...

HostGator has been great about addressing the problem.

Jason,

I've looped through all of our servers error logs and found a few of our mod_security rules hit. We have pushed an update to our rule set which should resolve the problems. Do you have any customer domains that reported the problem? I would like to make sure these have been fixed.

Thanks,
Josh
HostGator.com LLC

Just to note, the tilda ( ~ ) in the query string that s2Member uses, seems to be somewhat to blame in at least one of these bug reports at HostGator. A tilda ( ~ ) is sometimes used as a URL-safe alternative to the ( = ) sign in base64 encoding.

However, we already have plans to strip the tildas off the end of these URLs in the next release of s2Member, in a further attempt to help HostGator avoid this problem, and also, just in case other hosts have an issue with this in the future. In the mean time though, maybe this info will help HostGator with the mod_security ruleset changes.

It seems like the tilda ( ~ ) scores quite negatively on HostGator for some reason.

Statistics: Posted by Jason Caldwell — September 13th, 2011, 5:38 pm

Re: Mod Security ( Random 403 Errors )

2011-09-13T13:46:48-05:00

It seems that HostGator has made changes to their mod_security configuration recently, and in particular, this host seems to be troublesome for the s2Member application. HostGator support has been contacted about this, and I'm awaiting a response from the higher-ups.

Hopefully I will NOT get a response like this,
"please ask them to write to us for white-listing".

Here is a copy of my conversation with HostGator thus far. I'll update this thread again once I hear more. Hopefully they'll provide a well-thought-out, long-term, solution so we can continue to recommend HostGator as a viable solution for WordPress/s2Member.

Welcome to GatorChat!
Your Chat ID is 4559257.

Your question is:
"The mod_security extension for Apache, as it affects the s2Member plugin for WordPress installations at HostGator. I'm the s2Member Lead Developer."

(12:50:49 PM) Corey Sc: Welcome to HostGator Live Chat, my name is Corey. How can I help you today?

(12:53:02 PM) Jason: Hi there. Hope you're doing well today! My name is Jason Caldwell. I'm the Lead Developer for s2Member.com, providing a popular e-commerce plugin for WordPress. http://www.s2member.com/ Recently, we've had numerous complaints from our customers regarding the mod_security extension for Apache, as configured by HostGator. It seems that recent changes in your mod_security ruleset have caused various parts of s2Member's functionality to break. I'd like to speak with someone that can help get the s2Member application URLs whitelisted across your network so this is not an ongoing issue. I've posted an article here explaining the issue: viewtopic.php?f=36&t=14787

(12:54:16 PM) Corey Sc: Just a moment please, while I check on this, Jason.

(12:55:57 PM) Jason: Thank you Corey. Just to give you full disclosure, I will be re-posting our conversation to our own clients reporting this issue, so they know that we're working toward a solution with you ( i.e. HostGator ).

(12:58:37 PM) Corey Sc: Alright, Jason, that's understandable.

(01:00:01 PM) Corey Sc: Unfortunately for security reasons we can't whitelist this across our servers. However, users of your plugin are free to come to us individually to have this whitelisted, which you could put in the readme file of your plugin.

(01:06:18 PM) Jason: Thank you. Right, and that's what our customers have been forced to do recently. The trouble is, how many site owners know what mod_security is? For that matter, how many of them do you think leave HostGator, and/or s2Member for that matter, because the application produces 403 errors on HostGator? See where I'm going? I would understand this if s2Member was doing something that *should* be considered suspect, but I'm finding nothing unique about the s2Member application in this regard. That is, URLs with encrypted data in query strings is a VERY common practice. So what can I do to help prevent this problem from every occurring in the first place, for the benefit of both s2Member and HostGator?

(01:08:54 PM) Corey Sc: I understand that this can be troublesome, and I do apologize, however we do have specific security reasons for not having them whitelisted, but if you feel this is something we should look into whitelisting across our servers you can email feedback@hostgator.com.

(01:10:05 PM) Jason: I should also mention that we currently work with MediaTemple, Rackspace, Dreamhost, XLHost, and many other hosting companies, none of which have this problem with the s2Member application. Thus, it seems that HostGator (to your credit), has tighter security. But is it too tight?

(01:11:40 PM) Jason: Corey. Please don't refer me to a feedback address. If you have a higher-up that I can call directly, I'll be happy to discuss this matter with them if you prefer, but I've been around long enough to know better than to send an email to feedback@ addresses  Nothing ever gets resolved that way. You see where I'm coming from?

(01:13:08 PM) Corey Sc: Yes, I understand, Jason.

(01:18:54 PM) Jason: OK great! Thank you. So can you please send this article to your higher-ups on my behalf? Along with a copy of our conversation here? I'm sure you can get this to the right person for us faster than I can through a feedback address. The "Known Problematic Areas" listed in that article should be enough for your techs, I would think. That being said, if there is more information needed, please let me know. Article outlining the issue: viewtopic.php?f=36&t=14787

(01:21:47 PM) Corey Sc: Alright, one moment, please.

(01:22:24 PM) Jason: Certainly. I'm a patient person.

(01:22:38 PM) Corey Sc: Thank you, I very much appreciate your patience.

(01:26:28 PM) Corey Sc: I will be more than happy to create a formal ticket for you about this issue and have it immediately escalated to a member of our Quality Assurance team who will ensure that it ends up with the right Management team member so that you can get prompt assistance with this matter, as I understand that it impacts your clients as much as it does ours. If you would like, I can also note a Callback number to request a callback once that has been escalated. Would that be okay?"

(01:27:39 PM) Jason: Very welcome, and thank you as well. It will be great to have this resolved, or at least into the right person's inbox so we can work toward a long term solution in this regard. Yes, certainly. Please have them email me directly at XXX, or to XXX, or call our office and ask for me by name at: XXXXXXXXXX.

(01:28:53 PM) Corey Sc: Alright, allow me a minute to set up this ticket for you.

(01:29:05 PM) Jason: Thank you Corey. Waiting patiently.

(01:32:01 PM) Corey Sc: Okay, I've created this ticket for you. I'm having this escalated right away.

(01:32:39 PM) Jason: Thank you Corey. You've been most helpful. I'll keep a log of our conversation and follow-up on this in a few days. Anything more you need from me right now?

(01:34:05 PM) Corey Sc: I'm glad to help, Jason. That should be it.

(01:39:13 PM) Corey Sc: Was there anything else you needed?

(01:39:26 PM) Jason: OK. Nope, that's it. Thank you! Have a great day!

Statistics: Posted by Jason Caldwell — September 13th, 2011, 1:46 pm

Mod Security ( Random 503/403 Errors )

2011-08-31T20:25:11-05:00

Regarding mysterious 503/403 ( access denied )
errors associated with mod_security ( Mod Security ).

We've just taken a closer look at some of the most popular configurations for mod_security, such as the default ruleset that many hosts use from this source. Unfortunately, there are MANY mod_security rules that can produce false positive results, and we've also found that each host runs with a little bit different combination of rules, based on what they consider to be most important to their clients; and perhaps tailored to the most common software applications they host for their clients.

In short, there's really no way for s2Member to work around everything mod_security looks at, from one host to another. If you're running mod_security, and you plan to continue to run it, you may need your hosting company or sysadmin to tweak things for the applications that you run, by removing paranoid rules from your mod_security configuration. For instance, in the Core Rule Set Project, we've found several rules that would negatively impact even a default WordPress installation, even counting points against cookies set by the core WordPress framework. Anyway, you get the picture, paranoid!

Known Problematic Areas In s2Member ( under the right scenario ):

URL: http://example.com/?s2member_register=[encrypted data string appears here]
URL: http://example.com/?s2member_sp_access=[encrypted data string appears here]
URL: http://example.com/?s2member_paypal_notify=[followed by GET/POST data from PayPal]
URL: http://example.com/?s2member_paypal_return=[followed by GET/POST data from PayPal]
For that matter, any URL that contains: ?s2member_ and/or ?s2member_pro_ could be considered suspect, under a paranoid mod_security configuration. Also, some cookie data, stored in cookie names starting with: `s2member_` and/or `wordpress_`.

I don't personally care for mod_security ( I think it produces too many false positives, and too many headaches ). If configured properly, it can be useful. The problem is, it seldom is. That being said, I do understand that many hosts use this as a way to further protect the integrity of their servers. Given the degree of complexity associated with heuristic rule sets for mod_security, all we can do with s2Member, is follow "best practices" about what data we include in GET/POST/COOKIE/HEADER data ( i.e. no HTML in query strings, no function/parameter names, no SQL keywords, etc ).

Beyond that, if you are still experiencing what are seemingly random 403 errors ( possibly associated with cookies, headers, query string variables, etc ), please follow the instructions below.

Here are some basic instructions that may help some of you.

1. If you run your own dedicated server, and you want to save yourself headaches associated with mod_security, you can disable it inside your httpd.conf file with something like this.

Code:: # Mod Security v1.x. # May work in .htaccess too, on some hosts. SecFilterEngine Off SecFilterScanPOST Off # Mod Security v2.x. # Will NOT work in .htaccess, use httpd.conf. SecRuleEngine Off

Code:: # Mod Security v2.x only. # Will NOT work in .htaccess, use httpd.conf. SecRuleRemoveById 960024 981173 981212 960032 960034

This solution is a tradeoff: security vs usability. Use this solution at your own risk.
( * please do this at your own risk though, research things for yourself! ) ( also see: this article )
Or see: http://sourceforge.net/apps/mediawiki/m ... RuleEngine

3. Or, if you're on shared/managed hosting, ask your hosting company to disable mod_security for you. Or, ask them to whitelist the s2Member application, by disabling mod_security for URLs that contain ?s2member_ in their query string, or are otherwise associated with your WordPress® installation. As yet another alternative, ask them to whitelist specific URLs that are causing problems for you. Hosts that run mod_security are familiar with these requests, because mod_security is so very picky.

All you need to do is provide your host with the full URL that is failing ( including any query string variables that appear after the ? mark in the URL ), and point them to this thread. Or, just ask them to back down on the paranoia a bit overall with respect to mod_security and/or the PHP Suhosin extension, which is yet another paranoid module ( under certain configurations, that is ).

If you continue to have trouble, consider using a host that does NOT use mod_security, or one that has a good flexible configuration; one which does not inhibit the functionality of trusted PHP applications and plugins for WordPress®. Some hosts that just recently started using mod_security, or have recently upgraded to mod_security v2.x, may still need time to work the kinks out of their default configuration. Try to be patient with your hosting company, but don't hang around forever waiting for a miracle either.

We recommend MediaTemple® (gs): http://www.mediatemple.net/go/order/?re ... ks-inc.com

Statistics: Posted by Jason Caldwell — August 31st, 2011, 8:25 pm