Support » Plugin: BulletProof Security » Addin Site and Htaccess redirects

  • Resolved Susan Warren


    I first asked this question on the main WP troubleshooting forum, but I suspect I’m better off asking here.

    My question on the WP troubleshooting forum was:
    I just added a new addon site under my main domain name. I then installed WordPress 3.4.2 and added some plugins and some working content, along with the Graphene theme. As part of doing that, I installed Bullet Proof WP Security and Better WP Security, as well as Yoast SEO and several other plugins. I know that those three (at least) make major changes to the default htaccess file.

    This morning I was looking at my site stats via my Cpanel and while I was in Cpanel I decided to remove some old subdomains that I don’t use anymore. And what I found surprised me. On my list of subdomains was the new addon site, as would be expected. But along with that new subdomain was another new subdomain that I hadn’t created, and that subdomain had the user name that I had assigned to the new subdomain that I *had* created.

    Something like this:

    –new subdomain (also new addon) =

    –When I created “newaddonsite” I had to add a user name for ftp, etc– let’s say “newsiteusername”

    –But now there’s also a new subdomain in the list called “”, which I didn’t create.

    –Moreover, both subdomains are shown to redirect to /\..*$ and I never set any redirects for either of those subdomains or any others.

    When I checked the Cpanel list of addon sites “” showed up in the list, as it should. But it also shows as being redirected to /\..*$, the same as the two new subdomains. And there should be no redirect.

    So, I have a strange new subdomain that I didn’t create and a new subdomain/addon site that I did create, both of which redirect to somewhere or other that I can’t figure out, and that I didn’t create.

    I asked my site host tech support what was going on, and they said that this was happening because there was something wrong or hacked in the htaccess file for the new site.

    So that brings me back to Bullet Proof Security and Better WP Security, and perhaps other plugins that modify htaccess files: is the redirect and the extra subdomain something that are part of the security settings, or do I have larger problems?
    After further research, I found a line in the site’s htaccess as follows:

    # DENY ACCESS TO PROTECTED SERVER FILES - .htaccess, .htpasswd and all file names starting with dot
    RedirectMatch 403 /\..*$

    Which tells me that the redirect is part of Bulletproof’s security. But the questions remain, why is there an unwanted subdomain and is the addon redirect what should be happening? Is what I’m seeing normal and OK? At this point I’m asking not only for my own sake, but to pass the info onto my web host because they were clueless.

    I’m basically a Joomla developer, and my site host is primarily dedicated to Joomla hosting, so I’m in unfamiliar territory here, and it would appear that my host is also.

    Thanks for any feedback…

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author AITpro


    This redirect code would NOT have nothing at all to do with the problem you are describing. This code ONLY does this – DENY ACCESS TO PROTECTED SERVER FILES – .htaccess, .htpasswd and all file names starting with dot (.)

    If the filename starts with dot (.) then Forbid access to it by sending that person to your 403 error document page (if you have one, otherwise just display a 403 Forbidden error).

    RedirectMatch 403 /\..*$

    BPS does not have the capability to create websites or create addon sites and I doubt seriously that the other plugins you have listed here can do that or for that matter I think this would be impossible for any plugin to be able to do.

    If you did not accidentally create the addon site then I can only think of 2 other logical things that might be happening here.

    1. You have a Network/Multisite installation and you are talking about subsites of a Network/Multisite installation.

    2. Your website might be hacked/someone else has access to your cPanel account and someone else/a hacker has created this addon site.

    My site host and I have finally figured out what was happening. It seems that when you do an addon site in Cpanel and you *don’t* use the default username that Cpanel generates, Cpanel uses the username that you assign as the name of the subdomain that’s associated with the addon domain. For example, if you have an addon called “”, Cpanel will choose the ftp username as “abc” and will call the associated subdomain “”. But, if you decide that “abc” is too insecure and you want the addon’s ftp login username to be “xyz*45”, then Cpanel calls the associated subdomain “xyz*”. Neither my site host nor I had seen that before, and neither of us can figure out why Cpanel would set things up that way– you’d think a user should be able to determine the username apart from the subdomain name. But anyway, it’s a Cpanel design decision, and we basically spent our time reverse engineering that decision. My site host has asked Cpanel about it, but so far there’s no reply.

    As for the 403 redirect, I made up a basic site with just an index.html and one other page, and then copied the WordPress htaccess with the redirect string in it (`# DENY ACCESS TO PROTECTED SERVER FILES – .htaccess, .htpasswd and all file names starting with dot

    RedirectMatch 403 /\..*$`)
    into the site. When I checked my Cpanel the redirect string showed up immediately, with the redirect going to 403. When I commented out the redirect line in the htaccess and then refreshed my Cpanel screen, the addon site and associated subdomain went back to having no redirect. So it’s that redirect line in the Bulletproof htaccess section that was causing the redirects to show up in Cpanel.

    Plugin Author AITpro


    I do not understand what this means? “When I checked my Cpanel the redirect string showed up immediately”. What showed up? What exactly are you checking in cPanel?

    The code is ONLY designed to redirect files starting with a dot (.) to a 403 error document page or the Server’s default 403 error page and will not redirect any other files that do not start with a dot.

    What this code is really doing is saying you cannot access any files starting with a dot in the name.

    .htaccess – is forbidden
    .htpasswd – is forbidden

    The code would not effect files that do not start with a dot (.) because that is what the rule says to look at – ONLY file names starting with a dot (.) and nothing else.

    Plugin Author AITpro


    I found this string, /\..*$, in the redirects column of my new addon site and also in the redirects column of the associated subdomain, in Cpanel. When I chose “manage redirects” for that addon site, that redirect string showed up as being redirected to 403.

    So, to test what was happening, I put nothing but an index.html and one other plain page in the new addon’s folder. At that time there were no redirects showing for the new addon site nor in the associated subdomain. I then added the WordPress Bulletproof htaccess to the site folder and returned to the Cpanel addon screen, refreshed the screen, and immediately the redirect string was in the redirects column; and when I checked the redirect in the “manage redirects” page, the string was shown to be redirecting to 403. The string also appeared in the Cpanel subdomain redirect column.

    I then went back to the addon site folder and commented out the line in the htaccess containing the redirect string. When I returned to the Cpanel addon screen and refreshed it, the redirect string was gone from both the addon redirect column and the subdomain redirect column. And when I unconmmented the htaccess line and returned once again to the Cpanel screens, the redirect string was back again.

    If I could attach screen shots of the before and after it would probably help a lot, but I can’t. If you would like to see them I can upload them somewhere for you.

    OK, some screenshots of the Cpanel addon panel:

    — this is a shot of the addon panel when the htaccess redirect line is commented out: commented out

    — this is a shot of the addon panel when the htaccess redirect line is uncommented– notice the string underlined in red: uncommented

    Plugin Author AITpro


    Wow ok then this problem is very similar (basically the identical problem) to the broken cPanel HotLink Protection Tool problem. Basically what appears to happening is that the cPanel Modify Addon Domain Tool is seeing the .htaccess code in your root .htaccess file and incorrectly grabbing that code and trying to interpret what that code means. Unfortunately, it is not interpreting that .htaccess code correctly. This is the exact same problem with the cPanel HotLink Protection Tool.

    The cPanel coding check is supposed to be a helpful thing that automates things, but unfortunately since the cPanel coding check is not accurate it is actually breaking things.

    So the only solution I see is that you cannot use that particular BPS .htaccess code in your Root .htaccess file and will have to either comment it out or just delete it. This particular BPS .htaccess code is not critical and can be be eliminated entirely without decreasing your website’s security significantly. Hopefully there is not going to be any other BPS .htaccess code that is misinterpreted by this cPanel Tool. 😉

    I have no problem just commenting out the code. I’m used to setting permissions manually so I can just set the htaccess to 400 and be OK with it, if I want.

    The only strangeness I saw in Cpanel was the redirect string, but at the time I found it I wasn’t intentionally looking for crazies. The stuff I can see is one thing, but what worries me is the stuff I can’t see– hopefully there won’t be any more than what I found.

    I may wind up writing Cpanel to tell them about the addon/subdomain username thing, and if I do I’ll also mention the redirect string problem as well. They’ll most likely ignore me, but at least I can say I tried.

    On a related topic (and one which got me going on WP security), did you happen to see my post on the main WP Plugins and Hacks forum, here? If there isn’t something already like what I’m looking for, it might make an interesting project for you or someone you know. The token string makes for excellent backend protection.

    Plugin Author AITpro


    The maximum permssions settings you can use for .htaccess files is 404. 400 permissions will cause the site to crash.

    Don’t waste your time trying to contact the cPanel folks. why? The broken cPanel HotLink Protection Tool has been broken for over 10 years. There are 1,000’s of posts about this known problem all over the Internet. There are posts in the cPanel Forum that state this problem. I have also posted in the cPanel Forum without getting any response from them. They are probably just to big at this point and are not or will not look at these types of issues…i guess?

    Yes, i have looked at the other post. I am not a big fan of trying to hide things or add additional authentication to an already authenticated folder, but i like the token idea. I will look into this and see how beatable it is. 😉 if i can beat it in less than 1 hour than i won’t add it. if it takes more than 3 days to beat then i will add it.

    Plugin Author AITpro


    Personally i think a login protection plugin that locks the user account after X amount of failed login attempts is the best approach and is sufficient protection.

    Also everything is beatable unless you take away all of the hackers “tools”, which means methods of attack.

    Yep, you’re right– in fact I normally set my Joomla htaccess to 440.

    One thing I like about the token string is being able to set the page redirect. The first time I used the token plugin I had all kinds of happy thoughts about imagining seeing the faces of folks who finally managed to get past the admin folder username/password only to find themselves at the front page of the FBI website 🙂 But then I had seconds thoughts and just redirected to the site’s front page.

    I forgot to mention that the firewall I use with Joomla sites has a built-in admin protection scheme– however many login attempts I select and then a captcha screen, three more attempts and then they get locked out. And any and all logins, correct or otherwise, get logged and I get an email for every attempt. The firewall also passwords any access to the admin dashboard, so even if someone gets that far they can’t do anything except look at the dashboard. And once again, any and all firewall logins or attempts are logged and emailed to me as soon as they happen, as well as any attempts to change the firewall settings if they do get in.

    But as you say, nothing is foolproof. I installed all of the above on a client’s site and noticed they’d set up a weak ftp username/pword combo, and advised them to change it (I gave suggestions). A month later they were hacked via their ftp because they didn’t change what they had– and what they had was uname= companyname and pword= companyname1234

    Plugin Author AITpro


    Yes, using a Token has interesting possibilies so i will put it to the test. 😉

    Yep Brute Force cracking FTP passwords is the #1 thing that hackers go after because it gives them full control of a website.

    Plugin Author AITpro


    Hey Susan,
    I’m going to resolve this thread since i have already scheduled testing for adding a token feature to BPS. Once that testing is completed then i will post back here. thanks.


    It’ll be interesting to see what you come up with. And for your next project: a way to add a token string plus two-factor authentication to ftp logins 🙂 (That *was* a joke you know)

    Plugin Author AITpro


    Well actually one of the areas we are looking into next is how to protect against Brute Force FTP password cracking. We have some logical theories about how to do this, but you never know until you actually create/build it. 😉

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Addin Site and Htaccess redirects’ is closed to new replies.