mod_security meta-character anomaly detection alert – repetitive non-word characters

[Bob]

😉

I presume yes, the loop error continues regardless of .htaccess used … else, why a 403 with each attempt to activate htaccess files?  …. and yet, why can I create & activate a maintenance.htaccess no problem?

10-4 on future of maintenance.htaccess … but it works now, so I’m befuddled why not for secure. or default.?

[AITpro Admin]

Ok I am not completely clear on what is happening exactly.

Are you saying that you are unable to activate or deactivate Root folder BulletProof Mode?  Forget about testing anything related to Maintenance Mode.  The fact that it is being activated or not is not relevant to the bigger problem that is occurring on your Server.

Do these steps manually using either FTP or your Host Control Panel File Manager.

Delete the .htaccess file in your wp-admin folder.
Download the default.htaccess file to your computer, upload it to your website root folder (where WordPress is installed).
Rename the default.htaccess file to .htaccess.
Is the infinite redirect loop error still occurring?

Also what Custom Permalink Structure are you using on this website?  You will find that under the WordPress >>> Settings panel >>> Permalinks page.  Post your permalink structure here.

[Bob]

1. Okay, done … activate root file returns 403 again.
2. /%year%/%postname%/
1. that’s a 404 0n live site; 403 on sandbox

[AITpro Admin]

Do not use BPS to try and activate anything at this point.  Do these steps manually using either FTP or your Host Control Panel File Manager.  We first need to determine if the problem is with your Server itself.

Delete the .htaccess file in your wp-admin folder.
Download the default.htaccess file to your computer, upload it to your website root folder (where WordPress is installed).
Rename the default.htaccess file to .htaccess.
Is the infinite redirect loop error still occurring?

[Bob]

Sorry, don’t know how to tell if the infinite loop is happening (i.e., based on any log information … appears Host stopped that yesterday while I degaussed) … let me ask if they’re seeing anything.

Also, yes, I can Activate BulletProof Mode … it’s just the buttons that are confounding my sense of “eveything is okay”.

Stand by …

[AITpro Admin]

I see that your Host Ultra webhosting uses cPanel.  The problem could be caused by this very common problem below.

The solution is to lock your root .htaccess file.  See the link below for details.
http://forum.ait-pro.com/forums/topic/read-me-first-free/#cpanel-hotlink-protection

[Bob]

That’s something I ran across at one point in all this … didn’t spend much time with it, except to Disable it to take it out of the equation.  Checking now, I see they’ve re-enabled with some funky instructions in the ‘URLs to allow access’ window:

(%0A|%0D|%27|%3C|%3E|%00)
\.opendirviewer\.
^.*smoothgrind.net.*
users\.skynet\.be.*

[AITpro Admin]

You cannot disable the cPanel HotLink Protection Tool.  Enable/Disable is also broken in that cPanel tool.  There is only one thing that will prevent that tool from breaking BPS, other plugins, your theme, WordPress, broken permalinks, broken URL’s and your website in general (causes 403, 400 and 500 errors – basically it breaks everything – has been broken for more than a decade now) – locking the root .htaccess file and turning on AutoLock in BPS is the ONLY thing that can stop the cPanel HotLink Protection Tool from breaking your website.

[Bob]

Beautiful.  What’s up with the cPanel folks?  (rhetorical)
Thanks for the info & tip … I take it the AutoLock feature is only with BPS Pro?  Not seeing it anywhere with Free.

[AITpro Admin]

Not sure.  I contacted them a few years back so maybe newer versions of cPanel have fixed that broken tool.  There are actually 4 cPanel tools that are broken. 😉

Go to the BPS htaccess File Editor tab page.  If you do not see the Lock htaccess File and Turn On AutoLock buttons then your Sever type is DSO and not CGI.  What that means is unfortunately you probably cannot lock your root .htaccess file.

[Bob]

Copy that … no AutoLock button.

However, I was able to set root.htaccess to 0404 via cPanel (not FTP: best that allows is 604) … bummer though, the activate button still returns a 403.  🙁

At least I know it’s just a mainly UX issue at this point in terms of my site’s protection, but the loss of convenience is at hand.  I’m waiting a reply from Host about any other ideas … like, what happened last weekend/is still happening on the server side (that just happened to coincide with the firewall block as initially mentioned in this post)?   Host concurs that Hotlinking can interfere with scripts and plugs … but no other details, yet.

[AITpro Admin]

Possible options available to you:

If you have Shared Hosting then switch from DSO to CGI.  If you have VPS or Dedicated Hosting then do not do that.

Have your Host disable (they will actually have to remove the module itself from cPanel Tools) the HotLink Protection Tool on their end at the Server.  That can only be done by them at the Server.  You cannot do that from your end.

Amel has figured out a way to lock a root .htaccess file on a DSO Server, but it appears to be very complicated so if you are not seriously tech savvy then do not attempt to do that – link below.

http://forum.ait-pro.com/forums/topic/allow-404-file-permissions-for-htaccess-files-dso/

[Bob]

Yeah, I’m on a Shared deal … haven’t heard anything from Host yet, so I’ll throw the idea of removing Hotlink if they don’t have anything.

And I think I’ll pass on Amel’s approach … looks do-able, but seems beyond the call; for now, I can set the perms via cPanel File Manager (albeit for no benefit, either/yet).

Thank you all who are working on this!

[AITpro Admin]

Personal and Professional opinion – if you have Shared Hosting then you should be on a CGI Server and not a DSO Server – CGI is more secure for Shared Hosting accounts.  If you have VPS or Dedicated Hosting then DSO is better than CGI – DSO is more secure for VPS and Dedicated Hosting accounts.  Making the switch from a DSO to CGI Server on Shared Hosting is very simple for a Host to do.  They basically just move your Hosting account from the DSO Server to a CGI Server.  Simple and painless to do.  That is the optimum choice/option here.

DSO is faster by default because of the lower CPU usage and PHP runtime is loaded only once.
DSO is problematic for WordPress because of the file ownership & permissions issues with DSO.
For Dedicated Hosting the usual security concerns about DSO security in a Shared Hosting environment are not a factor because all files have a single ownership.

suPHP works well with WordPress (suPHP also runs PHP as a CGI module instead of an Apache module – mod_php).
suPHP is more secure then DSO in a Shared Hosting environment, but in a Dedicated Hosting environment they are almost equal in security, with DSO being slightly more secure in general.
suPHP runs a higher CPU load usage and PHP runtime is loaded twice.  A performance decrease may be noticeable in a Shared environment, but this will not be noticeable for a Dedicated Server.
CANNOT use an Opcode Cache (such as Xcache or APC) with suPHP. It is strongly recommend that you install a caching plug-in supplement.

Site with some very good info on DSO, CGI, suPHP, FastCGI
http://boomshadow.net/tech/php-handlers/

[Bob]

Alright, I think this is good to wrap up …

Host states they run ruid2 (dso in a suexec environment), following the trend of hosting providers that standardize on current PHP builds (5.3.28 for my account), “… due to its concurrent, multi-threading and security which combines the natures of security of suphp with the speed of fastcgi and is being recommended by cPanel as well.”

Everything covered here, your input and their’s, all sounds good and focused on one sort of best practice of another, so I’m not going to split hairs about it.  I can see that both of you are working to keep up as best as can be given the multitude of ever-changing requirements of your businesses, technology trends and standards, professional opinions and pesky, persistent customers! 😉

Which is to say, kudos to you and your team for helping me get to a point where there was enough valid information exchanged to get my Host to make a well-informed exception on my account and disable mod_security (which apparently only they can control, not me via .htaccess instructions) … the Activate button now works as expected: no more 403! …  Yeah!

If there’s anything further, I’m all ears … otherwise, thank you very much again, and have great day!
Bob

[Author]

Posts