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

Home Forums BulletProof Security Free mod_security meta-character anomaly detection alert – repetitive non-word characters

This topic contains 30 replies, has 2 voices, and was last updated by  AITpro Admin 5 years, 9 months ago.

Viewing 15 posts - 16 through 30 (of 31 total)
  • Author
    Posts
  • #12655

    Bob
    Participant

    ūüėČ

    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.?

    #12657

    AITpro Admin
    Keymaster

    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.

    #12659

    Bob
    Participant

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

    #12662

    AITpro Admin
    Keymaster

    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?

    #12668

    Bob
    Participant

    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 …

    #12669

    AITpro Admin
    Keymaster

    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

    #12670

    Bob
    Participant

    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.*
    #12673

    AITpro Admin
    Keymaster

    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.

    #12680

    Bob
    Participant

    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.

    #12681

    AITpro Admin
    Keymaster

    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.

    #12684

    Bob
    Participant

    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.

    #12685

    AITpro Admin
    Keymaster

    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/

    #12688

    Bob
    Participant

    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!

    #12689

    AITpro Admin
    Keymaster

    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/

    #12705

    Bob
    Participant

    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

Viewing 15 posts - 16 through 30 (of 31 total)

You must be logged in to reply to this topic.