WordPress wp-login.php brute force attack

Written by Jacob Nicholson
Views: 61,054
Published: May 9, 2014
Comments: 157

Since mid April a very large brute force attack has been taking place against WordPress sites.

The brute force attacks have been conducted by a large botnet consisting of thousands of unique IP addresses across the world, trying to steal WordPress admin credentials.

This attack is not just isolated to Web Hosting Hub, and seems to be happening on a global scale across multiple web hosts.

What we're doing

At Web Hosting Hub we used fleet wide security rules to protect the WordPress admin dashboard and the wp-login.php script from being compromised.

You might have been also blocked by these same security measures and redirected to this article, and if so you can use the steps below to regain access to WordPress.

Also make sure you're using a strong WordPress admin username and password.

Regain access to your WordPress website

If you are blocked by our security rules, you can edit your .htaccess file to block WordPress admin access to everyone but yourself form being able to log in.

Our security rules block login attempts for 15 minutes after a failed login attempt, so after you put these .htaccess rules in place, wait 15 minutes, then try to login again.

If you already know how to edit files on the server with FTP access, you can edit your .htaccess file to block these brute force WordPress admin login attempts.

You could also use the directions below in order to edit the .htaccess file in cPanel:

  1. Login to cPanel.
  2. Under the Files section, click on the File Manager icon.
  3. From the Document Root for: drop-down, select your WordPress site.
  4. Make sure that Show Hidden Files is checked.
  5. Click Go
  6. Right-click on your .htaccess file, then click on Edit.
  7. You may have a dialog pop-up from the text editor, go ahead and click Edit.

Now you just need to decide which way you'd like to limit access to your WordPress admin:

Note! Place any of this code at the very top of your .htaccess file.

WordPress admin access via secondary password

The first recommended solution would be setting up a secondary .htaccess password.

First setup a password protected directory on your wp-admin directory.

Now you can copy the text from your /wp-admin/.htaccess file created by cPanel.

Also add the ErrorDocument and <Files admin-ajax.php> lines to the top of the file before closing it.

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

# Allow plugin access to admin-ajax.php around password protection
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>

AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"
require valid-user

Edit the .htaccess file at the root of your WordPress site, the same level as wp-login.php

Simply add the text from your /wp-admin/.htaccess file surrounded by FilesMatch tags.

Also be sure to place ErrorDocument tags for 401 and 403 at the top to prevent loops.

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

<FilesMatch "wp-login.php">
AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"
require valid-user
</FilesMatch>

Now when you try to access either the /wp-admin directory, or the wp-login.php file directly. You'll get a separate web-browser password prompt, and bots won't attack this as they are looking for a valid WordPress admin dashboard login box.

WordPress admin access via restricted IP

The 2nd recommended solution would be restricted IP address .htaccess protection.

Use the following code, replace the 123\.123\.123\.123 IP address with your IP:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/wp-admin$
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123$
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.124$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>

Now anyone trying to access your WordPress admin dashboard that is not an allowed IP address, will be blocked from even seeing your WordPress login page.

WordPress admin access via required referrer

This is the least recommended soultion, as a referrer can easily be faked or obtained.

Use the following code, replace the example\.com domain with your website:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?example\.com [NC]
RewriteCond %{REQUEST_URI} (.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} (.*)?wp-admin$
RewriteRule (.*)$ - [F]
</IfModule>

Now when POST requests are sent to your /wp-admin directory or wp-login.php file, the user must come from your website so that their referrer string matches your domain name.

Temporarily disable ModSecurity on your account

If you really need access right away, you also do have the option to follow the steps above with your .htaccess file, then you can disable mod_security via cPanel Modsec Manager. We would recommend after you're able to log back into WordPress to re-eanble mod_security so that other possible threats are still being blocked.

Use secure WordPress admin username and password

We also HIGHLY recommend making your WordPress admin password very secure.

Minimum password recommendations:
- At least 8 characters total
- Mixture of upper and lower-case letters
- Numbers and special characters, such as punctuation or other non-alphanumeric characters

Example weak password:
password123

Improved strong password:
Z$xusptZ2M4!Z

You can read our guide on using a strong WordPress admin password for step-by-step instructions on generating and applying a strong password for your WordPress site.

We would also strongly recommend that you use a different WordPress admin username for even further increased security.

Did you find this article helpful?

We value your feedback!

Why was this article not helpful? (Check all that apply)
The article is too difficult or too technical to follow.
There is a step or detail missing from the instructions.
The information is incorrect or out-of-date.
It does not resolve the question/problem I have.
How did you find this article?
Please tell us how we can improve this article:
Email Address
Name

new! - Enter your name and email address above and we will post your feedback in the comments on this page!

Did you find this article helpful?

Comments
2013-07-05 5:42 pm
Seems like this block is happening to my site on a more regular basis. I have followed your directives and changed my password almost every time. But what I don't get is that changing my password (or username for that matter) is a way to prevent them from getting access to my site, right? However, that doesn't do anything to stop the admin from being blocked every time they attack the site. Frankly, I have not seen this happening with other WP sites I have on other servers and I'm wondering if HUB is being targeted more. In any case, I realize the block lasts only temporarily and can be bypassed but I am curious if anything else can be done. I do appreciate your safety measures. Thanks.
Staff
3,713 Points
2013-07-05 9:47 pm
Hello yogijbrown, and thanks for your question.

Sorry to hear that you're having issues accessing your WordPress website. I took a look at your account and I do not see where you've added the .htaccess rules mentioned in the above article to limit access to your own IP address for the WordPress admin section.

This will help ensure that bots don't trigger the automated lock-down, which could in-turn also block yourself out. The level of attack on WordPress sites has subsided a lot from when these attacks first originated back in the middle of April, and Web Hosting Hub doesn't seem to targeted anymore than other hosting companies. Unfortunately one of your sites is probably just in a spammer's list and they continually are trying to come back and test for weaknesses.

Restricting WordPress admin access to a single IP address, might get them to remove you from their lists of sites to try, as they should see they get 403 Access Denied responses instead of a standard reply they'd be expecting.

Please let us know if you have any further issues!

- Jacob



2013-07-27 2:17 am
Thank you for your safety script! It has been stopping a great many attacks.

However, this also means I'm locked out of my site frequently. I've pasted the above code into my htaccess file with my ip address and am still getting almost-daily attacks where I'm then locked out of my Wordpress dashboard. The code is supposed to allow logins from my ip address only, right? Why am I still getting locked out?
Staff
17,314 Points
2013-07-29 9:38 pm
Hello BarbaraAllan,

Apologies for the problem and also for what appears to be a delay in the answer to your comment. Oddly, I had worked on your problem last Friday and implemented a solution, but for some reason my reply was not saved (probably user error on my end- so again, my apologies). The main issue with the code in Step 8 of the Wordpress wp-login.php brute force attack article.

I found that the problem you were having was specifically with this line in your code:

RewriteCond %{REMOTE_ADDR} !^68.2.216.203$

You needed to have the line look like this:

RewriteCond %{REMOTE_ADDR} !^68\.2\.216\.203$

The '\' s are required for the IP address specfication. Make sure to wait at least 30 minutes so that any existing blocks expire before you try to access the WordPress Admin page.

I hope this helps to answer your question and resolve the login issues! Please let us know if you require any further assistance.

Regards,
Arnel C.
2013-08-10 5:34 am
I greatly appreciate the extra security measures that are being enacted by WebHosting Hub, as I moved here from Dreamhost, where it seemed as if they had given the master key to Chinese hackers.

At the same time, it is annoying, and sometimes terribly inconvenient, to be unable to access my own WordPress-based sites, which are mostly web directories.

I am taking all of the security measures that I know of myself. I update software regularly. My password is, I believe a secure one. I require the use of a CAPTCHA, and I use multiple security plugins.

I have added my IP number to my .htaccess file but, as I use my Verizon hotspot as an ISP, my number changes frequently.

I don't want to sacrifice security, but I am hoping that there is some way that we could arrive at a point where hackers are unable to access my site, but I am.
Staff
3,713 Points
2013-08-12 9:28 pm
Hello Ken, and thanks for the comment.

One thing I might recommend in your case, is instead of locking down access to your WordPress admin section via limiting certain IP addresses access. Instead you could setup a .htaccess password on the /wp-admin directory, and also copy those rules over to protect your wp-login.php file as well.

In order to do this, these would be the basic steps:


  1. Login to cPanel

  2. From the Security section, click on Password Protected Directories

  3. Navigate to the /wp-admin directory you're trying to protect

  4. Setup password protection, including adding a user



At this point, anyone trying to access your WordPress admin section, must first enter in the correct password for the directory protection, before they're given the opportunity to login to the actual WordPress admin dashboard.

Now to prevent direct login attempts sent to the wp-login.php script, you'd also want to carry over your .htaccess password protection to that file, but note you would also need to then give out your .htaccess password to any website visitors that have WordPress users setup for your site and need the ability to log in. Here are the steps to do that:


  1. Open your /wp-admin/.htaccess file

  2. Look for this section of code, and copy it:


    AuthType Basic

    AuthName "Secure Area"

    AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"

    require valid-user


  3. Then you need to place that code in the root directory of your WordPress installation surrounded by <FilesMatch> tags, in the .htaccess file there. In this example it would be at /home/example/public_html/.htaccess and look like this:


    <FilesMatch "wp-login.php">
    AuthType Basic

    AuthName "Secure Area"

    AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"

    require valid-user

    </FilesMatch>




Hopefully this method would work better in your case for you. Please let us know if you had any further questions at all, or had any issues setting up the password protection this way.

- Jacob
2013-09-04 4:28 am
I have a follow up question to the article, which left something unclear to me.
The passage: "If you have either a dynamic IP address, or you access WordPress from multiple devices, each IP address that you access WordPress with would also need to be allowed in your .htaccess file", I suppose most of use dynamic IP addresses from our internet service provider. So how wide is the range of IP addresses we might have over a month. I suspect too many to use the REMOTE_ADDR option. Please confirm I should simply skip that tactic and move on to the .htaccess password.
For me at least, the original instructions need some clarity in this regard.
2013-09-04 5:05 am
And now....
a further follow up question.

When securing the directory, the form asks the user to name the protected directory. Since said user just clicked on a the intended directory (which brought up the form) and the directory and its full path is listed above: "set permissions for....", which directory was so obvious that I got confused and supposed that your interface wanted some sort of alias for the intended directory as a further layer of protection. Therefore, please! amend your directions above to state: 3-b. Re-enter the name of the directory you just clicked (in other words, I find the text box there entirely superfluous!).

Now, when adding the "<FilesMatch "wp-login.php">" information, does that go before or after the: "# BEGIN WordPress" // # END WordPress" section? This seems to me to be a very critical point to be clear on.
Thanks,
Staff
17,314 Points
2013-09-04 8:08 pm

Hello Datamason,

Thanks for the questions. I will try to clarify the issues that you have expressed.



"...how wide is the range of IP addresses we might have over a month?"



That entirely depends upon how often your IP address changes when you access the WordPress site. Typically internet providers do not vary your IP address. So, if you're accessing it from your home or office wireless, the outbound IP will most likely stay the same. If you access the site from a variety of locations, then the number of IPs used to access the site will depend on the number of these locations.



If you're using a mobile wireless solution, then the IP will more likely be consistent. IF you are using an anonymous connection where the IP address is repeatedly changed, then this solution (locking down the login by IP address) would not be suitable for you.



Concerning the Protected directories


The instructions are typical for this are correct, though maybe some distinction should be applied to the word "navigate." Here's the confusion...when you click on the TITLE (the name to the right folder icon) of the directory, then you are actually selecting that folder to protect it. However, you can navigate to a subfolder by clicking on the FOLDER icon. It will open up the contents of the folder if there is anything under it. For anyone else needing the explicit directions for this procedure, go to Password Protecting a directory.



And finally, in regards to .htaccess edit...



When you see a "#" sign, it actually means that the line is merely a comment and is NOT processed as an .htaccess rule. Therefore, those markings of beginning and ending are usually only there to simply organize the statements to place in the .htacess file. However, it is important to understand that the rules/settings that you place in the .htaccess file are executed in the order that they are read (top to bottom). Therefore, yes, the should go in the WordPress section of the .htaccess file. It's mainly being placed there for organization sake and to let anyone know that it applies to your WordPress installation. Placement of the rules depends on the other statements in your .htaccess file. If you intend for these rules to be executed before others, then the whole section should be at the top.

I hope this helps to explain this issue for you! Please let us know if you have any further questions or comments.

Regards,
Arnel C.
2013-10-07 8:14 pm
I've tried adding a secondary password and restricting access to my IP. In both cases, I get a Google Chrome error "This website has a redirect loop." In IE, the page never loads. I've been blocked for nearly 2 weeks now. I appreciate the security measures but I'm quite frustrated that the so-called fix doesn't work properly. Advice?
Staff
12,339 Points
2013-10-07 9:05 pm
Hello GregBeaman,

I looked into this further and this loop was created because the server was trying to find the correct ErrorDocument to handle the password request. So I've placed the following bit of code in both your /public_html/.htaccess and /public_html/wp-admin/.htaccess files:
ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

After adding this, I am no longer getting the "redirect loop error."

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
2014-01-07 1:04 am
I did the first two solutions and am still unable to access my site. When I navigate to my wp-admin page, I have the pop-up login but entering my username and password only sends me to a "Denied" message. Please help!
Staff
3,713 Points
2014-01-07 3:50 am
Hello GregBeaman,

Sorry to hear that you're having issues again. I saw that you also commented on this post back in October having some issues with a re-direct loop after adding the .htaccess password protection.

The password pop-up that you're getting when trying to access your WordPress admin section is from that same .htaccess password protection. It's not going to be the same credentials as your WordPress login, but rather what username and password you created in cPanel for the password protected /wp-admin directory.

If you've forgotten the password, you can simply update it using these steps:


  1. Login to cPanel

  2. Under the Security section, click on Password Protect Directories

  3. Click the Document Root for: option, then click Go

  4. Click on the wp-admin directory which should have a padlock beside it

  5. Under the Create User section, fill in the same Username that you have below in the Authorized Users section


    Fill out and confirm your password you want to use, then click Add/modify authorized user




Now when you get the password pop-up, enter in the new password you just set in cPanel. Then you should be presented with your normal WordPress admin login page, which you'll want to use your normal WordPress credentials to login to.

If you're still having any problems please let us know!

- Jacob
2014-01-07 4:13 am
Hi Jacob,
I just followed the steps you posted and I am still directed to a "Denied" message. Any further advice to get past this?
Thank you
Staff
3,713 Points
2014-01-07 7:51 am
Hello again GregBeaman,

If you're getting the "Denied" message, that means that the username and password you entered into the web-browser pop-up didn't match the password protection that's in your .htaccess file.

It's possible I suppose that your .htaccess file got cached in your web-browser, and it's not seeing the updated password that you created following the steps above in my last response.

Try to clear you web-brower's cache. Then in a new window try to bypass the .htaccess password protection again, but also note that your username is going to be what's in cPanel as well, and not related to WordPress itself.

If you're still getting a "Denied" message after clearing your cache, please let us know!

- Jacob
2014-01-07 8:34 am
JacobN,
I still get the "Denied" message. What is the deal? I would rather deal with 1000 fake gucci ads every day. Just please give me my website back,
Thank you.
Staff
2,342 Points
2014-01-07 5:08 pm
Hello GregBeaman,

If you are absolutely sure that your .htaccess file is not still within your browser by clearing your cache as well as trying another browser, as well as ensured that the username and password that you have entered are correct, you may want to remove the password protection and re-add it again to re-create the file. Renaming your .htaccess file and then adding the password protection would also be a good step as well.
2013-11-21 10:39 pm
I've applied the first solution to no avail. The first time I tried to login, a popup window appeared and I entered my newly username and password which I created for my protected "pswrd" folder but then I got the same block page.

I run a multi-author blog and I want everybody to be able to login safely. Please help!
Staff
3,713 Points
2013-11-21 11:49 pm
Hello Xenoash,

Sorry to hear that you're still having issues. It sounds like possibly you have a WordPress plugin that is continuing to hit your wp-login.php script and triggering the ModSecurity rules on the server.

After implementing the secondary .htaccess password, try to wait 15 minutes and then attempt to login again. If you're still having issues, than more than likely it is a plugin causing the problem.

Because you have a multi author blog, you might have better success using the required referrer method for restricting access to your WordPress admin.

If you're still running into issues, please let us know!

- Jacob
2013-11-27 9:35 pm
I have been attacked again after implementing the first option!
Is there a more secure solution that can protect my website for brute-force attacks permanently?

Is this happening to WHH's servers more frequently than other hosting companies?

Is my website on a shared server or it has its own private server?

Thanks for the help provided so far.
Staff
3,713 Points
2013-11-27 9:58 pm
Hello again Xenoash,

When you implement any of these .htaccess rules to lock down your WordPress administrator dashboard, that won't stop the brute force attacks from taking place, but it should secure your login credentials from being compromised and your site being modified without your permission.

The trend in WordPress brute force attacks is not limited to WebHostingHub and affects any website at any web host that the attackers have in their list as a target. So once they begin to attack your domain, it wouldn't matter what web host you're using, as they are still attacking directly by your domain name, and not from the web host's server level.

You are on a shared server, but again this problem isn't coming from internal at the server level. You simply have outside sources trying to directly access your wp-login.php script, and for the time being because you've implemented some .htaccess blocking, they are all getting denied requests, so they aren't actually getting the chance to attempt to login to your WordPress dashboard.

It looks like since yesterday, you've had 59 unique IP addresses attempt to POST a request to your wp-login.php script. But they got denied by your secondary .htaccess password rules.

Please let us know if you had any further questions at all.

- Jacob
2014-01-05 7:34 pm
I'm 'still' not able to login and access my wp admin dashboard. I tried the IP solution -and- the first recommended solution. Neither have granted me access, so I returned the htaccess files back to the way I initially had them. I have a question about the IP solution ... when I click on the link to get the IP info - is this the IP for my domain? My personal IP is different - so should I try using that, instead? I understand how the two are different ... I'm just willing to try an alternate route, if it's possible.
Staff
16,266 Points
2014-01-06 6:50 pm
Hello lcwhitlock,

The IP address shown when clicking the link is correct as that is your public facing IP for your network. The local IP address for your computer will not be seen by the server so it will have no effect if you place that in the list.

Also, keep in mind, if the site is currently under the block time, that time will still need to expire before any changes you make will work.

Kindest Regards,
Scott M
2014-01-06 7:14 pm
Hello ScottM~! Well, after numerous attempts (since yesterday), to secure login, I'm still unsuccessful. I just now submitted a support ticket. I don't know what else to do, and pardon me for saying so, I'm quite frustrated. heh
Staff
3,713 Points
2014-01-06 11:34 pm
Hello lcwhitlock,

Sorry to hear that you're having continued issues getting into your WordPress admin. I took a look and it appears it's probably coming from the placement of your rules in the .htaccess file. As I was taking a look at your account, it looks like you might have as well, as the admin block went back into place.

I'm waiting for the admin block to expire right now so that I can test the .htaccess edits, and once I have a solution working for you I'll go ahead and respond to the support ticket I see that you have open as well regarding the issue.

- Jacob
Staff
3,713 Points
2014-01-07 12:26 am
Hello again lcwhitlock,

Sorry it took awhile to figure out what the cause of your problems was. It looks like the php.ini file you were trying to include within your .htaccess file was causing the issues. So I've gone ahead and copied over the server's default one.

Unfortunately I was unable to determine exactly what setting in your php.ini file was causing the issues, as it didn't appear to be logging any errors. But I went ahead and left a copy of yours in the /public_html/ directory called php.ini-USER. Your current php.ini file is one that I copied from the server's default location of /usr/local/lib/php.ini.

If you get past the .htaccess password prompt successfully, but then after entering in your WordPress credentials you simply remain at the login page now, that should mean the credentials just aren't accepted.

You should be able to simply reset your WordPress admin password, I'd recommend using the 3rd method using phpMyAdmin in cPanel to adjust the user_pass column for your admin user to a MD5 format and then just entering in the password you'd like to use for WordPress.

If you're still having any issues at all, please let us know!

- Jacob
2014-01-06 10:29 pm
I have attempted the first solution about and not having any luck accessing my site. I believe that I have followed the directions, but not having any luck with entry to my site. This is beyond frustrating as I have time sensitive information that I need added to my site.
2014-01-06 10:32 pm
It also appears that my entire site is inaccessable.
Staff
3,713 Points
2014-01-06 11:55 pm
Hello dromens,

Sorry for the problems you were having. I see that your website is fully accessible at this time, are you still also having issues logging into the WordPress admin?

If you first got redirected to this article because of our internal ModSecurity rules, the instructions for the .htaccess modifications can help limit the amount of people that are even allowed to attempt to login to WordPress at all.

Currently I can pull up your WordPress admin login, so that means the ModSecurity temporary block is over at this time. However if there are some unsuccessful login attempts again, and you don't have one of the .htaccess methods setup for restricting access to just yourself this could possibly happen again.

If you followed the first option for adding secondary password protection in your .htaccess file, you should have gotten a password pop-up in your web-browser when trying to access the WordPress admin again. Did that happen for you? If you did get the password pop-up, after you filled that in, were you still told the ModSecurity block was active and directed to this article? If that's the case, you'd want to wait a full 15 minutes to ensure all signs of the block have worn off, before attempting to login again.

Please let us know if you're still having issues at all.

- Jacob
2014-01-17 12:53 am
Hi, We're having the same problem as GregBeaman above. We keep getting a denied message. We've tried option 1 as well as clearing cache, trying another browser and still getting denied. We absolutely cannot get into our website. Please help. Thank you.
Kath and Christie
Staff
3,713 Points
2014-01-17 2:31 am
Hello suminoizumick,

Sorry to hear that you're having issues with your WordPress site. You mentioned you setup the .htaccess password protection from option 1 above, so when you say you're being denied, are you seeing the website pop-up box requesting your secondary password?

Or are you simply getting redirected to this article right away and seeing our error page?

Once the .htaccess password protection is setup, if you clear your web-browser's cache after waiting 15 minutes for the previous block to expire, you should only be presented with the .htaccess password prompt in a pop-up window. If you instead are seeing the WordPress admin login form, or seeing our error page again, then that means the .htaccess rules are not setup properly.

Unfortunately I was unable to find an account associated with the email address used here to take a look myself. If you'd like you can email support at support@webhostinghub.com and let them know the domain you're having issues with so that we can take a look for you. Or if you feel comfortable you can respond here publicly with that information as well and we'd be glad to take a closer look for you.

- Jacob
2014-01-17 7:33 am
I added a seconday password but I am still getting blocked from my website by the security measures. What is happening? I can't afford to be locked out of my website.
Staff
12,339 Points
2014-01-18 1:16 am
Hello rholzer,

Thank you for your question. If you are getting locked out, most likely someone is attempting to gain access to your Wordpress powered site. If you have followed this guide and are still not able to get in to your Wordpress site, I recommend contacting live support, or replying with your domain name so we can look at your specific setup..

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-03-02 2:06 pm

While it is a complete pain being locked out of your wordpress admin, I would far rather this than find (as I did once) some dirtbag has gained access and destroyed my files. The last time WHH blocked access to my www.easyflatpax.com site was well over a year ago, and today, it has happened again. Hardly a real problem! Having just changed ISP, I was yesterday forced to remove the code requiring my safe ip addresses as it would appear my ISP has done something which does not allow me access via this way (what, I don't know). I therefore set up a secondary password via cPanel, which works! I recommend this method as it is simple to do and, provided your username and password both contain a mix of upper/lower case, digits, letters and punctuation, they will not get in that way. Thanks to WHH for having the extra layer of security on top of all this!
Staff
3,713 Points
2014-03-04 1:51 am
Hello Andrew, and thanks for the kind words!

Glad to hear that setting up the secondary .htaccess password protection worked for you. Your new ISP might be rotating your IP address causing conflicts with the restricting access to your IP method. But the secondary password should work in all cases.

I also went ahead and just updated this article and the password protection section to add in another rule that allows any plugins that needs access to the /wp-admin/admin-ajax.php script. If you're noticing any strange behavior after password protecting the /wp-admin directory be sure to try that out.

Thanks again!

- Jacob
n/a Points
2014-03-09 6:47 pm

Hi JacobN, Thought I would share this. I found that you were right, and that secondary .htaccess password protection no longer works for me because my isp is rotating my ip. I therefore went the route of password protecting wp-admin through cPanel but have encountered another problem in that visitors to website get the paswword box, not just visitors to wp-admin. Try as I might, I could not get around this , so have abandonned this method. I discovered a third alternative! This is a plugin which requires a second password (authorisation code) on the login page. I can't  tell you the name of the plugin as my site has been attacked again and you have put a block on it again. I have to ask the question, is it WebHostingHub that is being targeted? I do have other sites on other servers and don't have these problems.
Staff
2,342 Points
2014-03-10 6:05 pm
WordPress sites all over the world are being targeted. Most providers, however, do not have this additional layer of security so you would not see anything about it on their servers until your site becomes hacked.
n/a Points
2014-03-12 7:26 am

Hi, 

this does not work at all for a multisite Wordpress. I can only logon the the main web site.

Could you please indicate the cjhnges  to be done for a multi site Wordpress ?

Thanks

Jose

 
Staff
3,713 Points
2014-03-12 6:34 pm
Hello Jose, sorry for the troubles.

Which of the .htaccess rules above are you trying to use? I setup a new WordPress Multisite (now referred to as Network) using the secondary .htaccess password method, and I was able to login to each of the 4 sites I setup under the main install.

If you did it this way, each admin user of a separate Multisite would be prompted for a secondary .htaccess password. You could just have them all use the same credentials at this stage, then once they are past that they can just login to WordPress as normal. Or if you'd like you can create multiple users and passwords for your password protected directory as well.

This should still allow access to your WordPress Network, while also denying access to malicious bots trying to brute force any of your sites.

If you're still having any issues at all, please let us know how you have things setup, and we'd be glad to try to come up with a solution.

- Jacob
n/a Points
2014-03-13 1:41 pm

Thanks Jacob,

It's all working now. It was caused by a cache somewhere betweeen the server and my machine.

 I am not fully understanding the fact on mod_security? Does it have to be on or off ?

Thanks

Jose

 
Staff
2,342 Points
2014-03-13 3:13 pm
Hello Jose,

It is always a good idea to keep mod_security turned on as it is quite effective in blocking malicious attacks to your site.
n/a Points
2014-03-15 1:28 am

This changed now, all  my sites are asking for a password including from the root, hey what's going on ?

  Thanks

Jose

 
n/a Points
2014-03-13 10:18 pm

My site has been down all day because of this.. support have been fairly useless ("have a look on wordpress.org for a solution") and now i''m just getting a 406 error, before going back to the warning page mentioned above.

 
Staff
3,713 Points
2014-03-14 2:38 am
Hello Mat D,

Sorry to hear that you've been having issues getting to your WordPress dashboard. I see that it looks like you've implemented the required referrer method above.

It looks like your login attempts are coming in with a valid referrer, so the POST attempts are not being stopped by the .htaccess rules you've implemented.

I've gone ahead and temporarily setup the secondary .htaccess password method for you. This should stop all unwanted login requests from coming in, allow the 15 minute block of the admin panel to expire, and then you should be able to get back in.

You should see that the username / password is displayed in the pop-up box in your web-browser, so if you have multiple users needing to get into WordPress, they should all be able to use those same credentials mentioned in the pop-up to bypass the secondary password, then they can just login to WordPress as normal.

If you are not seeing a password pop-up when you try to visit your WordPress dashboard, please make sure to clear your cache, as it's possible that the server's old .htaccess rules would still be cached there locally.

If you're still having any issues at all, please let us know!

- Jacob
n/a Points
2014-03-14 2:42 am

i can login fine with the password box, but still get the 406 error, so the site is not usable
Staff
2,342 Points
2014-03-14 3:32 pm
How long have you had the protection in place? It can take up to 15-20 minutes to allow access again.
n/a Points
2014-03-14 3:35 pm

It's been there for about 12 hours... Like i said, i'm not getting the brute force protection screen, just the 406 error
Staff
2,342 Points
2014-03-14 3:54 pm
If you have the protection fully in place and are still locked out of your WordPress dashboard after a significant amount of time, you may want to submit a ticket to technical support in which they will be able to provide you with any account-specific information.
n/a Points
2014-03-15 4:53 am

While I appreciate the security concerns, it seems to defeat the purpose of having a site when I am "temporarily" locked out of it 99.99% of the time.I host a Wordpress-based directory, and have had to close submissions, which also defeats the purpose, because no one is ever allowed to register for an account or access it if they had one. More often than not, i can't even add sites myself because I'm locked out.I can't host Wordpress-based client sites on Webhosting Hub because no client is going to accept being locked out of his own site more often than not. I have a client who wants a site that will include a blog, and I am going to have to set him up on another host because this just isn't acceptable.There has to be a workable workaround. I tried the .htaccess thing, and that got me in once, but the next time I tried to get in, I was locked out again, and I can't imagine trying any of the other options without blowing everything up.
Staff
2,342 Points
2014-03-17 3:14 pm
Hello Ken,

I do understand that this can be frustrating. Your WordPress admin dashboard becoming locked down is due to an active brute force attack on your WordPress site at that time. Without the additional protection that we have in place, your site could either become compromised quite quickly, or the severity of the attacks could cause your server load to spike up causing your entire site to become unavailable. There are several solutions available to protect your site in this manner such as a secondary password, blocking based on referrer, or blocking based on IP ash shown within this article. It can be a bit inconvenient, but it is your best solution to avoiding your site becoming hacked.
n/a Points
2014-03-19 7:03 am

It would be SO USEFUL if the instructions above said that you have to wait 15 minutes. I've been beating my head against a wall trying to figure out what I did wrong in following the directions, but then read in the comments that I'm supposed to wait 15 minutes after making the changes to my .htaccess files. Arrgh!
Staff
3,713 Points
2014-03-20 8:51 pm
Hello Todd,

Sorry for the confusion, and thank you so much for pointing that out. I've updated the article to reflect that you do need to wait 15 minutes after implementing .htaccess rules to limit login access to yourself, before you attempt to login to your dashboard again.

I see this was talked about like you said multiple times in the comments, but I had assumed I had that in the article already, so I was just reiterating it to users.

Hopefully that clears up any confusion for other users, and thanks again so much for letting us know!

- Jacob
n/a Points
2014-03-20 4:03 pm

On my site I have over 100 students who log in to comment on posts. I've enacted secondary password protection. It seems to have helped, but users are still getting locked out quite frequently.

Is there a way to know via the control panel if the problem is truly because of spammers or if, perhaps, too many users are entering their login info incorrectly?Thank you!
Staff
2,342 Points
2014-03-20 4:06 pm
If you have locked down your WordPress admin with a secondary password and still see this occasionally, it is due to one of the legitimate users that have the secondary password entering in their WordPress user password incorrectly.
Staff
3,713 Points
2014-03-20 9:10 pm
Hello Ian,

Sorry for the troubles, when handling a lot of login attempts to WordPress our security rules might trip if the frequency of these requests having failed logins is too high.

You can login to cPanel, then under the Logs section click on Latest Visitors to view your recent login attempts.

In the search box, you would type in wp-login.php, and then I would recommend clicking on the settings cog towards the top-right, and placing a check-mark only beside IP, URL, Time, Status, Method.

If you see a lot of 200 responses in a row for your wp-login.php, these are failed password attempts, and will eventually trigger a 503 response which is when our security rules kick in.

If you are only having valid login attempts, then you should see a 200 GET /wp-login.php response, followed right away by a 302 POST /wp-login.php response.

The 302 response is a redirect code, showing that a successful WordPress password was entered, so you could look for any IP addresses that are causing only 200 GET /wp-login.php requests, without a corresponding 302 redirect, and then you would know what IPs are possibly still triggering our security rules.

If you noticed the IP address 123.123.123.123 was causing this for instance, you could add this rule to the top of your .htaccess file to stop them from being able to get past your secondary password protection, and stop them from using a bad WordPress login that is triggering our security rules:
deny from 123.123.123.123


If you are still having issues with our security rules triggering on your valid login attempts please let us know!

- Jacob
n/a Points
2014-03-23 6:45 am

Hi

Before I start playing around with code I want to know if the block will simply expire by itself after 15 minutes of if I abolutely have to make the changes above.
Staff
12,339 Points
2014-03-24 4:46 pm
Hello Peter,

As long as the brute force attempts stop, the block will expire after 15 minutes.

So, if you are still not able to get in after 15 minutes, then you will have to make the above changes.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-03-24 9:13 pm

I am getting email notifications of updates to the comments section of this page, latest update is 3/24.

However, the last message on the page that I can view is from 3/3/2014. Why is that?

Am using Firefox 27.0 on a Linux box.
Staff
3,713 Points
2014-03-24 9:26 pm
Hello Michael,

This could be getting caused by our server-side cache of this page. I've gone ahead and forcefully reset the cache, so you should be able to see the updated comments now.

If you didn't want to receive any further email notifications, simply click on the Email Notifications link below, and then click on No and Update.

Please let us know if you need anything else.

- Jacob
n/a Points
2014-04-01 3:23 am

At this time, I have four web hosts. This is the only one that has me locked out of my own site 99% of the time.My objective was to run a Word-Press base web directory. Well, I couldn't do that on WebHosting Hub because no one was ever allowed to create an account or submit a site.I had to disable submissions, adding sites myself, in order to get the directory going, in the hope that, at some point, WebHosting Hub will find a way to protect our sites without locking out the good guys.You provide several options here, none of which I am capable of following. I don't know what to say. While I can certainly understand security measures, locking out the site administators from their own sites just doesn't make sense.The whole point of WordPress is interactivity, and that is not allowed on WebHosting Hub.
Staff
17,314 Points
2014-04-01 5:07 am
Apologies for the trouble, Mr. Anderson.

Web Hosting Hub hosts hundreds of WordPress sites, and the problems in applying the provided solutions is not a common problem with our users. If you are unable to apply these solutions, we can apply them to your account, but you need to provide more information about the method you want to use and user information based on the method you have selected to implement. You can get this done by submitting a technical support ticket with the appropriate information so that we can help you. If one of the solutions is applied appropriately, you would not be locked out. If you want to make these changes yourself, then you can reference the tutorial on editing your .htaccess file.

We do apologize again with the problems you've had with the site. We have many users who are able to use their WordPress sites with no problem. We can help you with your issue as well, but we just need more information in order to give you assistance.

Regards,
Arnel C.
n/a Points
2014-04-04 7:42 am

This is by far the most annoying thing I have ever experienced in my life with any webhost and it seems as if the company itself does not care that this is more of an incovienece to it's customer than it is anyone else. I understand the need to keep hackers/spammers out. However, I use my wordpress to run and opperate a store front. Which requires users to register so that they may make a purchases and I may keep track of who and how often purchases are being made. Customers and even MYSELF are being locked out from logging in. if they can't login, they can't buy and when they get that god awful lockout message it scares them off from even ever wanting to make a purchase. I am losing customers and this is my lively hood how I pay my bills and feed my child. I would think that this company would care that the reason I am paying for hosting is to actually use it not be locked out of it every other day. I have another blog where only I access the login area because it is a test blog. I have the password stored into my computer so that I do not have to retype it and still I am locked out of that one as well even though I am very well not typing in my password inccorect.

 

I have contacted the support team by chat on several different occasions  about this issue and I am still brought to this very same page and instructions that clearly I can't use because I cannot .htaccess a login page that not only I am going to access but countless unknown users who plan to purchase on my site will need to be able to access. How on earth would I use a secondary password that all my users whom I don't personally know would know? I recommended this hosting to a client who's site I designed she also faces this same issue with her blog and her site has not even went live yet. Only her and I have used the login. She is upset and doesnt want to continue with it because this issue is too "big" to just let slide and I very well agree.

 

Not only is it annoying the lock doesnt only last 15 minutes sometimes it's a whole 2hrs before I can get back into my site. When i am trying to make updates and edit I don't have 2hrs to waste twiddling my thumbs waiting to be able to access my own darn site. I want to get in get it done and get out. I am honestly fed up & I think if this is the only solution you guys have I may have to cancel my hosting all together and find another place.
Staff
12,339 Points
2014-04-04 5:34 pm
Hello Odessa,

Thank you for your comment. We definitely understand your frustration, since the brute-force attacks cause trouble for us too.

Under most circumstances, adding your IP to the .htaccess fill is a viable option, but this seems to be a special case.

As an alternate solution, I recommend Submitting a verified ticket requesting that we Disable the mod_sec rules.

Then, use a 3rd party Wordpress plugin to protect your website.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
Staff
3,713 Points
2014-04-04 9:42 pm
Hello Odessa,

Sorry for the troubles and frustration. I went ahead and took a look at your account and did see in your access logs that you have been getting blocked out of your WordPress admin.

It seems that it is not your valid users attempting to login or register that is causing the problems but instead it looks like mostly malicious bot activity.

Luckily one thing of note is that any modern web enabled device a human would use is going to be using the HTTP/1.1 protocol which was made the standard towards the end of 1999. It looks like almost all of your malicious request attempts to login are coming from HTTP/1.0 clients, which would indicate more than likely an automated bot source.

I've gone ahead and implemented some .htaccess rules for your WordPress sites that should specifically block these type of bot attempts, while still allowing normal human attempts:

# Block HTTP/1.0 User-Agents from POSTing to wp-login.php

RewriteEngine On

RewriteCond %{SERVER_PROTOCOL} ^(HTTP/1.0)

RewriteCond %{REQUEST_METHOD} POST

RewriteCond %{REQUEST_URI} ^/wp-login.php

RewriteRule .* - [R=403,L]


Hopefully that should help prevent these malicious users from locking out your good users. If you continue to have any issues at all, I've gone ahead and enabled raw log archiving for your account so that we can review things historically from the server-side to help prevent further false positive security blocks.

Or as JohnPaul had mentioned, if you'd like to submit a ticket and request for the ModSecurity rules to be disabled altogether for your account, please go ahead and do that.

- Jacob
n/a Points
2014-04-05 1:32 am

Thank you both for the response it seems as if  the people in the support chat response is always just designed to point me here and I have explained several times to them this fix isn't really good for my personal situation.  I will submit a ticket to have it disabled are there any 3rd party apps you my recommend. Would something Like reCAPTCHA or anything else that would identify a human from a  bot at the login screen work well for keeping bots from making the lockout screen happen? Much like what you have here in the comment section..

 

Aside from this one issue I have had no problems with the hosting and I really appreciate you both taking the time to respond to me with helpful information. Thank you once again!
Staff
3,713 Points
2014-04-05 2:14 am
Hello again Odessa,

No problem for the responses, sorry if our front-line tech support hasn't been the biggest help with these issues for you. Unfortunately sometimes support is not aware of underlying implications causing our server security rules to trigger.

I sent you a separate email detailing that it seems like your WordPress Good Question plugin was not properly functioning, and that was making it seem like even your valid users trying to register had invalid login requests which triggered our security rules.

I would recommend the WordPress WP-reCAPTCHA plugin for blocking fake registration attempts. It uses the same Google reCAPTCHA service that we use here on our public comments section, but allows you to protect your WordPress comments, and registrations.

I see that you've gone ahead and put in a ticket to have the WordPress ModSecurity rules disabled on your account. I went ahead and did that for you and responded to that ticket separately as well.

Please let us know if you run into any other snags or have any further questions at all!

- Jacob
n/a Points
2014-04-14 4:06 am

Hello,

I've followed the steps for the first option of getting a secondary password. It worked. But when I tried again after a couple of hours, I'm blocked again. I have my htaccess files correct. Please let me know what else I can do, this is really inconvenient.

Thanks 
Staff
2,342 Points
2014-04-14 5:16 pm
Does your WordPress admin panel successfully prompt you for a secondary password when you attempt to log in? If not, the code may not be fully inserted correctly.
n/a Points
2014-04-19 3:20 am

I used the ip restriction protection, because I am locked out of my new account. I cannot log in to create my theme or anything else, using wordpress. Please let me know if I need to do something else, or if the code I entered in file manager htaccess, is correct.

Thanks!

 
 
Staff
17,314 Points
2014-04-19 3:31 am
Lorrie,

We can't see your website because you haven't provided the URL, but if you were denied access you need wait 15 minutes before you can get in again. If you continue to have problems, you may want to contact our live support team (available 24/7) as they can immediately take a look at what's happening.

Regards, Arnel C.
n/a Points
2014-04-26 2:56 am

I can't log on to Asamnews.com

It says I've been blocked because someone tried to hack into my account. How long will this block last?
Staff
17,314 Points
2014-04-26 3:15 am
Hello Randall,

Sorry to hear you're having problems with logging into the domain. When I tried to investigate the domain, it appears to be set to Bluehost making this an external account. I'd recommend using the .htaccess rule detailed above for allowing only specific IP addresses. This should help you avoid additional issues with the login. I'm not sure how long Bluehost servers are set to lock you out. For Web Hosting Hub, the lockout is typically 15 minutes.

Apologies that I can't give you direct assistance.

Kindest Regards,
Arnel C.
n/a Points
2014-04-26 3:55 pm

I am not able to login to my blog through wordpress page
Staff
16,266 Points
2014-04-28 8:44 am
Hello Rajiv,

We are glad to assist you. What type of error are you receiving when logging in? Are you getting blocked or simply getting authentication errors?

If you are being blocked from time to time, be sure to follow the instructions on this page in order to help prevent further blocking and let us know if you have any further issues.

Kindest Regards,
Scott M
n/a Points
2014-04-28 4:01 pm

Web Hosting Hub folks, I've noticed that this blog article, which started as a straightforward description of "here's a problem you may see, and here's how to fix it" has since started to be used for a general purpose tech support avenue. I'd like to suggest that people who need help contact support through one of the many ways that already exist, and that you pare down the comments in this thread to just those that add to the technical discussion. The list of comments is now so long that's essentially impossible for anyone new to this issue to benefit from this. Can you move those off to support tickets?
Staff
3,713 Points
2014-04-28 10:11 pm
Hello Todd, and thank you for your suggestion.

I do agree that this guide has evolved quite a bit from when the original WordPress brute force attacks happened in April 2013 and I just wrote a quick news update about it.

We can look into possibly cleaning up the comment section a bit, or looking for other alternatives to help condense all of the information. The main benefit right now of the guide also having these real world issues discussed in the same location is that we are getting roughly 500 unique visitors a month from search engines, seeming non Web Hosting Hub customers. Some of these users might be coming across this guide because their search query matched a comment and not the guide itself. So we've mainly left the comments as is to try to help the largest amount of people possible suffering from these issues.

Thanks for the insight, I'll definitely bring this up at our next team meeting to discuss a possible alternative.

- Jacob
n/a Points
2014-05-27 2:55 am

People are using this as a tech support avenue because our hosting support keeps repointing us back to this post for help and it seems the only people that are helpful in fixing our issue are responding to us here. Everytime I talked to support via chat about "this" issue they always dumped me off to some link they don't even fully listen to my question.

 

For those looking for help with the lockout...

I will say this since I was helped here and was told to have this block disabled by my host and add in a 3rd party plugin like reCaptcha  to my blog. I have no had the issue at all with being locked out of my blog since.

Your best bet is to submit a ticket and request for the ModSecurity rules to be disabled altogether  and make sure you have a plugin to protect your login and comment areas and totally forget the htaccess method.

 

I'd like to thank everyone here who helped me it's been smooth sailing since!!
n/a Points
2014-04-29 4:22 am

I really have no idea how to implement the suggestion to unlock things. The instructions how to put in a secondary .htaccess password are like chinese to me. I can get to the edit the .htaccess page but after that I have no clue. Even the stuff for restricted IP address .htaccess protection. Where are you supposed to put that stuff?

Are there options for people like me?
Staff
17,314 Points
2014-04-29 4:45 am
Hello Jeff,

Sorry to hear about the problems you're having. There is a tutorial here that can help you in editing the .htaccess file. The entries should go at the beginning of the file. The .htaccess file is a text file where the entries are parsed in consecutive order. These rules do NOT unlock your WordPress login. They provide a way to help make your login more secure. If a lock out does occur, you are generally locked out for 15 minutes. After 15 minutes expire, you then attempt the login again.

I hope this helps to explain the options explained above. If you have any further questions, please let us know.

Regards,
Arnel C.
n/a Points
2014-05-14 3:12 pm

Having an issue. This is the first time ive seen the wordpress login block on my site.

 

I followed the directions, password protected the wp-admin directory, altered the .htaccess in that directory as well as in the root of the wordpress site, yet im still getting blocked.Why? agh! 
Staff
12,339 Points
2014-05-14 3:39 pm
Hello Mike,

Thank you for contacting us. If the brute-force attempts just caused a block, be sure to wait 15 minutes to regain access.

If you are still unable to login after the 15 minutes has lapsed, we are happy to help. But, we will need some additional information such as the domain to investigate further.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-05-20 7:54 am

I host a number of wordpress sites. I tried the .htacess fix but the root for each install doesn't have an .htacess file to modify - only the main root has one - ex. www.completehavoc.com is the main install, www.drifterstudios.com is a sub (drifterstudios.completehavoc.com) so Drifterstudios.com doesn't have a .htacess file to change.
Staff
2,342 Points
2014-05-20 3:48 pm
To do so, you would simply create a new file named .htaccess, or you could enable permalinks on your WordPress site which would then generate this file for you.
2014-05-23 3:11 pm
I'm not sure if I'm facing a brute force attack issue on my site, but I've implemented security measures to protect it against those types of attacks (as instructed in these articles). The issue I'm currently having is similar though - I'm not able to log into my WP admin. When I try to log in, an error box pops up (but there's nothing written in it). This week I had to re-install Windows 8 (Pro) on my laptop (due to corrupted system files). After I updated all of my drivers and burned some recovery disks, I updated to Windows 8.1 (Pro) - and again, updated my drivers (for win 8.1). Something is different, though .... and for the life of me, I can't figure out what it is. I re-installed my local server and set it up as I had it before (the Windows re-install), and I re-installed my WP (on the local server). Everything is exactly the way I had it (before). I'm able to access my local WP with no problem - I'm using the exact same theme as my live site. The only difference is, I don't have an htaccess file on my local server. Since I have my WP admin secured for IP identification only, I checked my IP through my cPanel (online) to make sure it was the same - it is. What else could it be, that's keeping me from accessing my dashboard?
Staff
2,342 Points
2014-05-23 3:49 pm
Could you clarify what exactly you see? Possibly a screenshot?
2014-05-23 8:03 pm
here's the screenshot of the login page (after login attempt) http://lcwhitlock.com/misc/login_error.png
unless you prefer me take a screenshot of the view source results?
Staff
3,713 Points
2014-05-23 10:31 pm
Hello lcwhitlock,

It looks like the screenshot you provided is just the normal WordPress admin dashboard login. What happens when you attempt to enter your correct WordPress credentials? I was able to login without any issues.

You might want to try to reset your WordPress admin password to ensure that you are in fact using the correct credentials when you're trying to login.

I'm not aware of what would be causing a blank error box to be coming up on your site. The little box that is showing above your WordPress login box is the normal WordPress one that typically would say something like Error: Invalid username or Error: The password you entered for the user admin is incorrect.

It seems like it is probably related to the theme or possibly a plugin that you have installed. Please let us know after ensuring you are using the correct WordPress credentials to try to login to your site, if you're still having any issues at all.

- Jacob
2014-05-24 7:23 am
got it ... thank you~!
n/a Points
2014-05-30 3:17 pm

I purchased hubhosting a few days ago, and initially I was pleased with my decision.

Now however I am getting frustrated with hub's server-side way of preventing logins after a set number of logins (which number anyway??). NOTE: Not of failed logins (as would be obvious), but of correct logins!

NONE of my other hosters is using this archaic mod security script that hub is using, probably based on a certain staff member's humble suggestion. They ALL use a functioning firewall instead. And this is what I expect Hub to use as well if you wish to retain us as customer?

Also note: Should I ever experience that hub staff interferes in any files on OUR domain (incl. htaccess), this would be considered as a serious breach of trust.

David
Staff
12,339 Points
2014-05-30 3:49 pm
Hello David,

I understand your frustration, since the Wordpress brute-force attempts cause many headaches for us as well. This is because like many hosts, we have a lot of WordPress sites on our servers, and deal with this ongoing problem daily.

While we do use several methods (including a firewall) for preventing attacks, there is no block in place for successful logins.

After adding the .htaccess rule provided in this guide, you will be able to regain access after 15 minutes. We do not modify the code/files for a website, so you would have to add the .htaccess code.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-05-30 4:48 pm

Hi John-Paul,

I appreciate your quick reply and I also understand that hub staff suffer a lot from wordpress attacks too.

However, as I mentioned in my prior post on this page, you can - and should - completely BIN that archaic script brought over to you from inmotion (and whoever else before that). Because, ALL our other hosters use a BETTER firewall instead, with ZERO issues over the last 3+ years. Ie incl. the period of intense strain on wp-hosted sites!

Once again: Use a proper firewall (learn how to set it up), and NONE of the sites hosted on hub will be affected by downtime due to malicious DOS attacks etc.

Our site is brand-new to hub and its DNS IPs, and IMMEDIATELY your archaic script wrecks my nerves because of totally pointless shutdowns.

The site is not even open to registrations! I am still testing things out - and am glad I do, because we might well move away from hub by tomorrow if you don't stop this **primitive** script today.

AFTER testing, it was planned to have a membership site, and the appropriate htaccess restrictions are already in place. If you wish anything to be added kindly let me know?

(needless to say: without posting anything confidential here)

Otherwise, as I said, I will not tolerate this. No membership site can exist if members cannot log in!

David

 
Staff
12,339 Points
2014-05-30 7:32 pm
Hello David,

Thank you for contacting us again regarding the Wordpress brute-force attacks. We always appreciate feedback, and suggestions.

Since this is just our public forum, and there is nothing I can do for you from here regarding this issue, someone from Live Tech Support will be reaching out to you.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-05-30 10:09 pm

Hello again John-Paul,

Thank you, Tommy contacted me, yes. I replied to him, however your system may have a processing error: I received a server reply with a link to here, but no info whether Tommy received the reply or not?

Thus I sent the email again, to the spport address mentioned in the first auto-reply. But again, I received the same auto-reply. :-(

Anyway, would you mind passing on to Tommy that I sent a reply? And could you add this new thought: AFTER testing, we plan to install a dedicated SSL - will at least that then cancel the archaic mod script the server runs against "attacks" AND legitimate logins of myself ?

Maybe he can answer this when he sends his email reply about the other point.

Thanks again!
Staff
12,339 Points
2014-05-30 10:38 pm
Hello David,

Yes, I see Tommy has received and replied to your email already at this time. Purchasing a dedicated SSL will not disable mod_security, or affect the brute-force attempts in any way.

Many people followed this guide, and host WordPress sites on our servers without any issues. If you are still unable to login to your dashboard after adding the rules, something is most likely interfering with the security rules, such as a plugin or theme.

At this point, I recommend contacting Live Tech Support, so they can review the server log in real-time, and tell you more specifically what is triggering the security violation.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-05-30 11:04 pm

John-Paul, Tommy replied just now, but that isn't equal with answering. None of my two questions were answered. :-(

Also, I thought you knew: We have done MORE than most of your other customers ever would (referrer + brute force ip limit + s2m + registration closed). So pl do NOT place us in the same bucket as you place the average, unsecured wp site. This has nothing to do with shared hosting: Every other shared hoster we have or know is able to differentiate.

This is yet *another* indicator for just how archaic that inmotion souvenir of a departed staff member there is: Any merely mildly intelligent script (=script of an intelligent human) will differentiate based on the security level enforced by the site, and NOT disseminate a blanket "antibiotic" (= against life) to all hosted sites on one server.

May I suggest, instead of replying here next, to undertake a concerted effort at hubhosting TONIGHT to get things straight that many other hosters have straightened out after (or even during) the summit of attacks in 2013? Thank you.

Best regards

David

 

 
Staff
3,713 Points
2014-05-30 11:58 pm
Hello David,

Sorry for the issues you've encountered with our server side ModSecurity rules. I do see that your site isn't under a heavy WordPress brute force attack at this time, but they have blocked some 300 attempts from both Ukraine and Canada so far today.

The rules are suppose to very specific in nature as to what type of requests are blocked, so if they are interfering with your normal login activities then please contact us directly so we can review the logs at the time of you trying to login. I was able to login to your WordPress account without any issues as I was troubleshooting this problem for you.

If you can provide support with the IP address you're trying to login from we would be glad to further investigate what might be happening. Some WordPress plugins might be making your browser send additional requests to wp-login.php that the ModSecurity rules aren't expecting, so an exception to the server-wide rules might have to be made in your case.

I would recommend trying to disable all WordPress plugins temporarily by simply moving the /wp-content/plugins folder to something like /wp-content/plugins-BAK before attempting to login, and then renaming it back once you're done testing. If you enable your plugins again and start having login problems yet again, then you might want to review the recent WordPress attempts by logging into cPanel then clicking on Latest Visitors under the Logs section and searching for wp-login.php to see exactly what kind of requests are happening.

I apologize if you believe we're just throwing you in a bucket with other WordPress users, we've been dealing with this issue for over a year and no it's no fun. On the whole and large the ModSecurity rules are only negatively affect a very very small percentage of the total WordPress websites that we host. As such, and I apologize for this, it can be a bit rough the first time you have to deal with getting caught up in the security rules. But for the most part we don't have single users that continue to have login problems after implementing some of the .htaccess rules mentioned in this article or requesting an exception to the server-wide ModSecurity rules.

Please try to login again, and let us know if you continue to have problems even with plugins disabled.

- Jacob
n/a Points
2014-05-31 3:03 am

>I was able to login to your WordPress account without any issues

When was that? To log in, first one has to register. No one can register on our site, thus no one can log in.

The only exception was for a short window of opportunity while I was testing s2m features, and briefly opened up the registration page - which attracted 6 folks to register, were you one of them? They all got deleted quicker than it took them to register. :-)

Pl feel free to "log in" again as you say. Because if you truly can log in, we have another issue to solve (this time, on our side here).

Else: We do not have any login plugins, no. And if a handful of logins already trigger your script to go wild, even worse. How would that be once we open up and may have a hundred folks logging in?!

Again, as long as only correct logins appear from the same ip (or if forgotten, 3 attempts), NO script should prevent page access. - And in our specific case, if a user tries the fourth time, he is automatically blocked for 30 min anyway, thanks to s2m! (No referrer and other measures are also in place here, pl ask Tommy)

At the moment I cannot tell you which ip address seems to trigger your script going wild: a) I only got the lockouts sporadically, not all the time. And b) I use a vpn anyway, for security. I change ip's like my mood...

The point really is (and that's what our testing is about since we purchased hubhosting only a few days ago):

If already NOW, without active users, your script goes wild, how terrible will that be once we open up?!? Sorry, but we are not willing to take the risk with hub's script. And you wouldn't either as customer.

All the rest (so far) is good if not great with hub, but this point is nerve-wrecking, and that's unacceptable in our modern competitive times. Like I said multiple times, NO other hoster I know of/experienced uses such an archaic blanket treatment against their customers. Archaic, blanket, treatment, against. Exactly.

Let's see how it goes over the weekend now, while testing. One more script attack, and finished. Because your script attacks are much worse than any alleged hacker - which in all those years we've never had. Hmmm, so why then suddenly (allegedly) on the second day after joining hubhosting SO MANY that your script goes wild? Hmm, I have to THINK about that. And I suggest you too. ;-)

PS: Don't get me wrong, real attacks give you loads of trouble, I know that, and spammers' stupid perseverance is shocking!

 
Staff
3,713 Points
2014-05-31 3:56 am
Hello again David,

In your case I might recommend submitting a support ticket if the issues persist to see about having our internal ModSecurity rules excluded from your account since you have your own protection setup.

It looks like in total you've had 15 unique IPs blocked by ModSecurity since 5/28, and 9 of those only had one attempt on wp-login.php.

Definitely apologize for any inconvenience, as you can tell from the comments here on this guide I wrote last year we've been in here trying to help out any users that are still running into these issues when we can!

- Jacob
n/a Points
2014-05-31 11:50 am

Okay, that then further supports how inadequate that script is, don't you see: 15 IPs blocked in one (1) day, 9 of which only tried ONCE.

We allow them to try three times, because I forget passwords too.

I am not even asking to exclude one account that employs pretty strict limits itself(!), I am asking to REVISE a script that is so obviously inadequate that it is outright ridiculous (as even your own look in the logs confirm)!

Jacob, if it was me, this would motivate me to improve on it right away; the first time I notice or hear of weaknesses (and as you say, the list above is long).

Okay, I am trying to help hub here: Why not make the script...

a) block after three FAILED login attempts of the same IP (catches amateur spammers),

b) AND, to catch bot farms using different IPs!, block any further login attempts for 30 min AFTER a site's login attempts per sec OR min OR hour (!) exceed the four- of fivefold of its historical average index over the last 30 days.

c) Run a simple "cron" job every day (like you run countless other logs anyway) which saves these three indexes (sec/min/hour) for every hosted site, to be instantly comparable in a look up table when the server recognizes a spike in traffic. Have the "cron" job exclude such spikes from its built indexes, so as not to water down its effectiveness.

That's it! MUCH more effective and MUCH more appropriate for your customers - and for you too, because less stress! ;-)

You may want to give this a thorough thought, hm?

 

PS: So what about my question about your "login"? And no, Tommy hasn't replied yet.

 
n/a Points
2014-05-31 1:48 pm

Again!

Error 406 - Not Acceptable

Generally a 406 error is caused because a request has been blocked by Mod Security. If you believe that your request has been blocked by mistake please contact the web site owner.

 

Happened for IP 69.85.88.156--------

 

Is this your gratitude for my elaborate business advice given above??

I KINDLY asked you yesterday to use the night to revise or delete that ARCHAIC, DUMB script. Apparently you decided "our customers are not important to us".

Fine. You chose. Now we choose. Someone who cares about their customers.

 
Staff
3,713 Points
2014-05-31 11:41 pm
Hello David, sorry you're still having some issues.

Again as I've already mentioned if you continue to have issues with our internal ModSecurity rules, please first try disabling any plugins that you're using to ensure that one of them is not what is causing a request signature conflict and causing false positive hits on your wp-login.php script. I was able to login to your WordPress dashboard as the admin user when I was first testing your site, and it still looks like I can directly get in without triggering the ModSecurity block.

I apologize but I think there was a break down in communication at some point, as you should have arrived at this guide if your IP was getting blocked by the WordPress brute force protection rules we have on the server. But in your case it seems like it's your plugin S2member. Anytime you're having some sort of access issue if you can provide the IP address and steps you were taking to replicate the problem this can help speed the troubleshooting process along.

The IPs I mentioned getting blocked in the ModSecurity log were requesting more than once to your site, what I was saying is that only 15 IPs total had been blocked by ModSecurity all together. 9 of them only once, as to say that they weren't continually being blocked from accessing wp-login.php, but the other 6 IPs were getting blocked more than once by ModSecurity, one IP from Ukraine was blocked on 260 separate instances, and an IP from Canada was blocked 45 times.

I've talked to our senior system administration team about these ModSecurity rules many times over the past year, and we've actually talked directly with ModSecurity as well about them. Unfortunately as it stands the amount of users that are getting blocked for false positive hits is so low, that the advantages of protecting our entire fleet-wide user base currently overrides the disadvantages of a few users with unique circumstances to have to work around the security rules.

I appreciate the suggestions for improving our security rules and I'll pass those along for you. Please do keep in mind though that due to the nature of how WordPress brute force attacks are carried out these days, a simple level of protection like you've mentioned isn't going to work for the bulk of cases.

We are already blocking IPs automatically at the ModSecurity level after failed login attempts, the problem is the pool of IPs for attackers to rotate through is so large and ever growing that maintaining a list of IPs to block at the firewall or at the ModSecurity level isn't always going to work. They'll try 2 logins from one IP and then move onto the next and never use that IP again. So ModSecurity works at trying to stop the bad requests from an IP as soon as possible, and unfortunately sometimes this level of detection is prone to sensitivity errors in the requests that lead to false positive blocks.

In regards to the 406 error you got from ModSecurity the rule that got triggered was:

msg "POST to wp-login.php without redirect_to

This isn't the WordPress brute force ModSecurity rule that this guide covers, this is instead looking like a plugin that you're using that doesn't handle the login attempt to the wp-login.php script by passing along the redirect_to variable like a normal login attempt would:

[31/May/2014:06:40:48 -0400] "POST /wp-login.php HTTP/1.1" 406 300 "http://example.com/membership-options/"

[31/May/2014:06:50:15 -0400] "POST /wp-login.php HTTP/1.1" 406 300 "http://example.com/membership-options/"


There is no time expiry on these type of blocks because the IP isn't being blocked from the admin for a time limit, this is a straight up ModSecurity rule protecting against known vulnerable vectors of the WordPress login system.

Please submit a ticket and request for the ModSecurity rule 13053 to be excluded on your account to see if this fixes your login issues if you need to continue using that plugin, but note that this could be rejected as techincally it might still allow an attacker to take advantage of the security hole. Ultimately it would be ideal if any WordPress login plugins you use on the site mimics the same behavior of the standard WordPress login procedure so it wouldn't have these problems on a server running ModSecurity protecting against common WordPress attacks.

- Jacob
Staff
3,713 Points
2014-06-01 12:35 am
Hello David,

I dug a little deeper and fixed this issue for you with the S2Member Pro plugin until you can contact the plugin developer and figure out why it's not passing the redirect_to variable. Because it looks like they've coded it in place, but it's not actually getting used:

/wp-content/plugins/s2member-pro/includes/classes/login-widget.inc.php

On line 141 there was this line:

echo ($redirect_to) ? '<input type="hidden" name="redirect_to" value="'.esc_attr($redirect_to).'" />'."\n" : '';

I've just gone ahead and on line 142 manually placed the redirect_to hidden field:

echo '<input type="hidden" name="redirect_to" value="http://example.com/wp-admin/" />'."\n";

I went ahead and tested the login through your /membership-options page, and it's working. Now that the plugin is properly handling a WordPress login attempt the same way as going to /wp-admin would, it's not triggering the ModSecurity rule that looks out for that.

Hope that helps.

- Jacob
n/a Points
2014-06-02 2:24 pm

Hi Jacob,

I appreciate that you looked into this. I had sent Jason/Cristian (s2m) a message immediately on Friday when I discovered what's problematic for your script, and reinforced it per email on Saturday:

To s2m: "As a friendly, URGENT reminder: Continuing login problems with Apache's stupid mod security make it NECESSARY that in s2m ALL links to wp-login.php be replaced by links to wp-admin (ie in login widget, variables, everywhere!). Or I and your other customers cannot log in their own site! :-("

Plus, although we haven't even opened up, I already set up the email templates in a way urging everyone to ONLY use /wp-admin to attempt login later.

But here's why I say (again) that all this is NOT solving the issue of that dumb script, Jacob:

a) I am surprised that wannabe spammers haven't YET accomodated for /wp-admin; they will soon!

b) Both you and I proved that the script is even blocking LEGITIMATE, FIRST-TIME logins - which makes that script so outright primitive that it hurts!

This is why I gave you guys a MUCH BETTER, if not perfect!?, brute force attack solution! If you don't pick up this free advice, other hosters soon will. Because it was free - like mod security. ;-)

Surprisingly however, I haven't even heard a single word of thanks AND a statement when hubhosting will have this in place, instead of that incredible dumb "mod security" script. So dumb that it doesn't even make it impossible for a lazy server admin to configure it so wrong that it blocks 99% of the time unjustified! I would be ashamed if I were from Apache, or from a hoster who used the script...

Also pl note (again) that some other hosters who use the same free "firewall" (mod security) have properly set it up, such that it does NOT give 99% false alarms, as is the case with hubhosting. - Hopefully, your support team colleague Abraham S who replied to me without even bothering to READ what I had written here in meanwhile countless statements, took the time he saved on reading to revise his setup of mod security?

If not, THIS is what should be done - or better: implementing my above solution. ASAP, because the brute force will soon catch up on wp-admin!

Conversely, what should NOT be done (ever) is, to mess around with CUSTOMER's files. This is a NO-NO, Jacob. And I don't appreciate this part of your investigative work.

Yes, you were well-meaning, and you did well, but going forward pl understand that it is entirely unacceptable that a hoster modifies a client's files, UNLESS they informed the client first, and ASKED the client for permission.

Think about it as if you were the client, Jacob. Would you accept such behavior?

Well, most clients do not. ONLY those that seek "managed webhosting" would appreciate that - but hubhosting doesn't attract customers to managed webhosting, or do they now? ;-)

In summary: Thank you again for your effort, but pl note the points above, and share some of your great skill and work attitude with certain technical support staff managing the servers. ;-)

Regards, David

 
n/a Points
2014-06-02 5:25 pm

Jacob, I am only now seeing that you actually posted one more post above the one I was redirected to through your email.

Now THAT post really a) worries, and b) bothers me a lot!

a) "I was able to login to your WordPress dashboard as the admin user when I was first testing your site, and..."

What's that supposed to mean. Please can you be explicit, to avoid further misunderstandings on both sides (and time-waste).

Obviously NO ONE should be able to log in as admin!

b) "Please do keep in mind though that due to the nature of how WordPress brute force attacks are carried out these days, a simple level of protection like you've mentioned isn't going to work for the bulk of cases."

That is plain ridiculous: YOUR script copied from Apache (and free) is SO DUMB that it hurts! While my suggestion above is SO SMART that likely no brute force attack can overcome it! I noticed that you haven't properly READ/UNDERSTOOD my suggestion. Before you lazily refuse it, TRY IT. Right? TRY IT. Be amazed! Cause you will AFTER trying it.

Given the ENDLESS complaints about your script's inability to avoid that the MAJORITY of sites (FACT!) have login problems (not "a tiny number" as you wish to purport), is reason enough to TRY IT what I said.

I also said: If you *don't* want to try it (why not???), then at least configure that ridiculously STUPID FREE Apache firewall professionally.

"We are already blocking IPs automatically at the ModSecurity level after failed login attempts, the problem is the pool of IPs for attackers to rotate through is so large and ever growing that maintaining a list of IPs to block at the firewall or at the ModSecurity level isn't always going to work."

Man! I can't believe it! Can't you see WHY that approach will NEVER work?

ARCHAIC, like I said.

I'd appreciate not to have to waste more of my time with these messages about hubhosting's archaic server setup, but instead to see and experience that hubhosting actually DOES what a hoster is supposed to do.

Note that I retain everything I post here, just in case it gets "lost" somewhere on your server...

Thanks, and over.

David

 
Staff
3,713 Points
2014-06-02 11:21 pm
Hello David,

I apologize for fixing this issue for you, I use to be a system administrator until I moved over to help our Customer Community team, and so I'm quite capable of seeing what a problem on a server is and fixing it, so I might have moved hastily over the week-end from home to get your login system back up and running. I agree it's typically best not to go above and behind on a support issue like this and edit customer code. However in this case it was a matter of proof of concept to show it was the plugin causing your specific problems, and I wasn't seeing a lot of other user's having ModSecurity blocks in the server logs.

You came onto this public guide about our ModSecurity rules in place for blocking normal WordPress admin brute force activity, but your issue was not related to those ModSecurity rules. It was simply a problem with the plugin you were using for users logins called S2Member Pro not passing the redirect_to variable that a normal WordPress login would carry.

Since your site is hosted on a shared hosting server along with other customers who are also running WordPress along with many other types of website software, we can see very easily in the ModSecurity logs like I did for you, what websites are having issues logging in. On most days it's far less than 1% of the entire server's websites that are blocking any IPs at all.

So again this was an isolated problem for you. If you'd like to reverse the change I made I did give you the file and line that was modified here:

/wp-content/plugins/s2member-pro/includes/classes/login-widget.inc.php

Since it doesn't look like this file has been modified again, I assume you wouldn't want me to revert it at this point back to the version that would get blocked by the ModSecurity rules again for the missing redirect_to variable.

We have to think about the server as a whole, and again coming from a sysadmin, if one user is having a problem that hundreds of others running the same software are not having, you want to first try to isolate and correct the issue for the one user. The brute force ModSecurity rules server-wide have blocked in the millions of malicious login attempts, and we work with our customer to try to help themselves stay secure while also securing the server when they do interfere with normal activity.

If you do continue to have any problems at all with your normal WordPress login activities, please be sure to submit a ticket so that our support team can further assit you.

- Jacob
n/a Points
2014-06-11 10:42 pm

Okay let's calm down a bit and look at the facts, shall we.

You/Jacob wrote: "I went ahead and tested the login through your /membership-options page, and it's working. Now that the plugin is properly handling a WordPress login attempt the same way as going to /wp-admin would, it's not triggering the ModSecurity rule that looks out for that."

Can you tell me then why it still triggers the Mod, after your change? I just clicked the logout link in the widget, and was prompted with the script page. I thought "can't be true, Jacob changed it to prevent just that", and so I tried again. Same thing. I tried once more. Same thing.

So I looked again at your code above:

"On line 141 there was this line: echo ($redirect_to) ? '<input type="hidden" name="redirect_to" value="'.esc_attr($redirect_to).'" />'."\n" : ''; [yes, I still see this line there, you wrote "was", did you mean, it should be deleted?]

"I've just gone ahead and on line 142 manually placed the redirect_to hidden field: echo '<input type="hidden" name="redirect_to" value="http://example.com/wp-admin/" />'."\n";

I do understand this line, but it is not in line 142. So I don't really understand what you mean you changed? Did you mean, I shall REPLACE line 141 with your line 142?

Czaja wrote in an email that, after the plugin updated, you changed the code once more. So, you see why all this is confusing when looking at the present code?

I spoke to the developer again, and he says sth along the lines "we can't change the code for one server environment that is set up in a specific way", but he didn't say what code I myself need to use to make it work without hiccups (probably because he doesn't know your server environment).

It's not a problem for me to take a note down, what need be changed after updates; I have such file already and can just add another rule.

Or maybe, is the logout link not solved yet, but you meant only the login link? Shall I put your line 142 somewhere else as well to stop your Mod from blocking?

Here's why this situation is so strange anyway: BEFORE I purchased hubhosting, the (nice) salesperson said: "Oh, you know we actually recommend that plugin for that purpose. Many of our customers have it. We know it pretty well."

Hence why I am of course very surprised that this very plugin gives us (you and us) so much trouble now on your server with Mod?

Hope this clears it up now. And, for the benefit of all your other customers too who use/will use that plugin.

PS: A short instruction is easiest pl, like: "Replace line x with this ..., and line y with this, and keep it that way while with hubhosting and then it will work".

 
Staff
3,713 Points
2014-06-12 12:19 am
Hello again David,

On line 141 is where the plugin like I first mentioned seems to have code for inserting the redirect_to variable. I just went 1 line below that on line 142 and manually added it since it looked like plugin wasn't adding it to the resulting HTML code of your login page.

The code is still there, and that file was last modified on June 6th which is the same day that I put that fix back in place for you. So I'm not sure why you would still be encountering issues with that ModSecurity rule for the missing redirect_to variable.

I do see that there have been several IPs blocked from accessing the wp-login.php script due to the WordPress brute force protection. So it could be that's the error you were encountering instead. Unfortunately because it doesn't look like you've limited access to the WordPress login script like is discussed in this guide, the brute force rules could still be getting triggered by other users and locking out your access.

You can always submit a ticket with support with your IP address that you're having issues with to have them review what might have been the exact issue. Because this time it looks like it was not the S2Member Pro plugin causing issues.

- Jacob
n/a Points
2014-06-15 4:07 am

Sorry it took me a while to get through it (also had other problems).

You wrote: "So I'm not sure why you would still be encountering issues with that ModSecurity rule for the missing redirect_to variable."

I *think* the problem is the "logout link" in the widget, hm? The script hit me when I clicked that link (which, like you said, it shouldn't do at all because a) I came from the site, and b) I was logged in!).

Meanwhile Jason updated the plugin AGAIN (and seemingly he overwrites ALL files!), so I tried to replicate your change myself this time, and I think I managed.

But the logout link still triggers your script. So I looked in the file "login-widget.inc.php", and unfortunately there are tons of references for "logout", starting in line 170 with:

                                $options["logout_redirect"] = ($options["logout_redirect"] === "%%previous%%" && $ops_page && is_page($ops_page)) ? "" : $options["logout_redirect"];

Hence my question again: Shall I put your line 142 somewhere else as well to stop your Mod from blocking? Or some other line? Where? Any idea?

Given this: "Oh, you know we actually recommend that plugin for that purpose. Many of our customers have it. We know it pretty well."  ... I can't see why I should be the only one facing your script problems? What happens to all your other customers who use s2m? Why me?

 
n/a Points
2014-06-15 3:29 pm

Jacob, actually let me try something else before you scratch your head about why your other customers with s2m don't get the script hit.

Because I just saw that we can even customize the login/logout widget from within the sw. So let me first see if that solves the issue with your script. If not, I'll report back here.
Staff
3,713 Points
2014-06-18 12:00 am
Hello David,

It sounds like the issue you're encountering with the plugin's logout link is probably the same as with the login one. The plugin did appear to have code in it initially for using the redirect_to variable in the resulting HTML of your site. It just didn't seem to be activated.

So I would check to see if there is a setting for the plugin, or asking the plugin developer why that might be. If it is something with the server environment, we would expect to see other customers with the S2 Member plugin also having issues, so possibly it is also conflicting with another WordPress plugin you're running? I might suggest trying to have all plugins but S2 Member disabled and see if you're still having issue with logging out.

- Jacob
n/a Points
2014-06-01 9:59 pm

Please, help, I tried to follow the steps given above but I guess I am not skillfull enough in this field. I haven't been able to log in to my site for few months now (half a year!), I really need to make changes, there, I am paying money for the site I cannot access! Please, help.
Staff
2,342 Points
2014-06-02 4:08 pm
We cannot make any changes to your account via this public forum, but will be happy to assist you as much as possible. Could you clarify what step in this you are having trouble with?
n/a Points
2014-06-04 7:43 am

I have been hosting with WebHostingHub for over a year now. I moved here from Dreamhost, with the intention of moving all of my sites over to WebHostingHub.

At first, I was pleased with what appeared to be a genuine interest in security on the part of WebHostingHub, something that seemed to be missing at Dreamhost.

I had intended to operate a few web directories, based on a PremiumPress theme that uses a WordPress platform

However, in the time that I have been here, I think that it's fair to say that I have been locked out of my own Wordpress-based sites more often than not.

When I allowed direct submissions to my directories, I was receiving hundreds of spam submissions per day, and the only way that I could cut that down was to require registration, which cut the spam down to none that weren't caught by my anti-spam plugins.

However, I soon found that submitters were unable to create accounts more often than not, and those who were able to do so were unable to log into them, which is not surprising since I can seldom log into my own account.

So I have all but abandoned all of my directories but two, both of which are hosted on subdirectories of the same domain. On these, I have given up the idea of being able to accept submissions through the built-in submission features, for reasons outlined above.

Instead, I have modified my contact page to allow peopel to suggest sites to the directory. Since they are unable to access a submission form, of course, I am unable to charge for this.

So basically, because of I believe to be a wholly unreasonable policy on the part of WebHostingHub, I am unable to run an actual directory, but am resigned to allowing people to suggest them to me, and listing them for free, which was not the business model I had in mind, I promise you.

To make things worse, more often than not, I am unable even to list them for free because I am blocked from my site.

Yes, I know that you have given several options here that are supposed to be a fix.

However, I frequently log in from differenet IPs. I don't really understand the other ones but it seems to me that none of them would solve the problems that prohibit anyone from registering or accessing an account on my site.

I can't help but think that there has to be a more professional way to solve these problems than by blocking your customers from accessing their sites.
Staff
2,342 Points
2014-06-04 4:03 pm
I recommend using the referrer method mentioned in this article as it will allow any user to log in if they come from your site, but will disallow direct POST requests that are most commonly within the WordPress brute force attacks.

The protections that we have in place have been the most effective way to block the continuous stream of brute force attempts that are made as they come from various IP addresses in which overall rules for all users need to be in place to avoid hacks as well as the requests coming in so fast that they can cause the sites to become completely unavailable.
Staff
3,713 Points
2014-06-04 11:58 pm
Hello Ken,

Sorry for the problems you've been having with your WordPress website. I took a look at your account and do see an instance where you had a support chat with us from last May regarding the WordPress brute force attack protection, and you've had several support tickets regarding the matter as well.

It looks like by and large you are having successful WordPress logins. I attempted to go through your WordPress user registration process myself to see what might be going on, and it looks like your AVH First Defense Against Spam plugin has some issues because after trying to register a new account I get this error:

Warning: Missing argument 2 for AVH_FDAS_Public::handleFilterRegistrationErrors() in .../wp-content/plugins/avh-first-defense-against-spam/class/avh-fdas.public.php on line 254



Warning: Missing argument 3 for AVH_FDAS_Public::handleFilterRegistrationErrors() in .../wp-content/plugins/avh-first-defense-against-spam/class/avh-fdas.public.php on line 254


So that could be causing the problem with your users being unable to register for an account. It also looks like the WordPress brute force rules aren't working correctly on your site because I have seen a few lockouts getting triggered on the first time for seemingly all IP addresses rather than just one.

I have gone ahead and opened up a support ticket for you to further track this issue and have our system administration team take a closer look for you. Hopefully we will have this issue cleared up for you shortly.

- Jacob
n/a Points
2014-06-23 6:10 pm

[Please delete any links before posting, some text is blue?]

Hello guys, I thought I share this with you as it may help. AWS (where we have an account too) just sent us this info:

"Using an up-to-date version of PHP will generally improve the performance of your PHP applications. Did you know that PHP 5.4 is 20-40% faster than PHP 5.3? Upgrading to PHP 5.4 or greater will provide better performance and lower memory usage. If you cannot upgrade from PHP 5.3 to PHP 5.4 or PHP 5.5, upgrading to PHP 5.3.18 or greater will improve performance over older versions of PHP 5.3."

I checked and it seems the server I am on here is still running 5.2.17. While for me that is enough, for you an update will definitely improve performance and reduce cost dramatically.

Hope this helps.

David

 
Staff
12,339 Points
2014-06-23 6:47 pm
Hello David,

Thank you for contacting us. Your server has up to PHP 5.5 already installed, you can change the version (5.2.17-5.5.13 are available) in your specific account at any time via cPanel.

Please make sure your CMS, and all plugins/themes are compatible with the version you are switching to.

I left your links, since they may be helpful for other people who see this forum post.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-06-23 7:11 pm

Oh that's awesome, I didn't know that, John-Paul. Do you happen to know which php version the majority of customers use who don't raise tickets reporting problems?

We are on wp 3.9.1 as the base layer. I am not knowledgable as regards what changes say php 5.4 introduced that could impair plugin usability. I just thought that if all your customers use a better-performing version, it should help you dramatically to run a well-oiled machine.

 
Staff
12,339 Points
2014-06-23 7:21 pm
Hello David,

WordPress lists 5.2.4 as a minimum requirement.

The PHP version used really differs, based on how developers code their sites. People usually only change the PHP version when there is a problem, or specific requirement they need to meet.

If you lookup your plugins, or navigate to the developer's site, it will list which versions of PHP they are compatible with.
I don't recommend changing the version unless you are experiencing problems, or issues.

If you have any further questions, feel free to post them below.
Thank you,

-John-Paul
n/a Points
2014-09-03 5:56 pm

It is so frustrating to be locked out of my account again. Since I moved to webhostinghub, I've had this happen a number of times, despite having implemented security measures. :( 
Staff
12,339 Points
2014-09-03 6:03 pm
Hello Mindy,

Thank you for your comment. We definitely feel your frustration, since we have to deal with these issues daily.

If you have followed this guide and are still getting locked out, there may be something else, such as a plugin or theme also interfering with the security measures.

We are happy to help, but will need some additional information. Which access method did you implement?

What security plugins/addons are you using?

If you have any further questions, feel free to post them below.

Thank you,
John-Paul
n/a Points
2014-09-03 6:16 pm

Hi John-Paul.

Honestly, I've worked with support and I feel like all I get are links to instructions. Then, when I faithfully try them and run into struggles, they send me the same links again. I have been trying to implement solutions to stop Google spam from overloading the servers and, despite trying to adjust code, etc., I still haven't been able to block them. I put in these security measures - Right now I have the extra password that the admin has to put in to get to the main login page - and I'm still gettting blocked out. I am fairly new to Wordpress and worry about messing with code too much (I locked everyone out of my blog initially). If you can help me problem solve this issue, I would greatly appreciate it.
Staff
16,266 Points
2014-09-03 8:21 pm
Hello Mindy,

We are willing to take a look, but we do need more information as John-Paul asked above.

Which access method did you implement?

What security plugins/addons are you using?

Kindest Regards,
Scott M
n/a Points
2014-09-14 1:20 am
provide me with a simple solution to the error problem that says cookies not accepted because.....
I have had this problem last month and you said it was your updates that caused it. I am unable to login until you fix it.
Staff
2,342 Points
2014-10-02 4:41 pm
Which of the above protection methods are you currently using?
n/a Points
2014-10-02 4:04 pm

JACOB:

Hi, for a couple of months it was working pretty well despite your mod script, thanks to your tip how to circumvent it in the login widget.

However, just now, while rapidly logging in and out with different login details for certain tests, I got this:

WordPress Login Temporarily Disabled

We apologize for the inconvenience! You are seeing this message because your site has recently been targeted by attackers attempting to gain access to your WordPress Dashboard. In order to protect your site your WordPress Login page has been temporarily disabled.

Unfortunately, you will be unable to login to the Dashboard until the block expires.

And: I can't log in to our own site, and: No customer can log in either! :-(

Imagine this happens to your own site! It is totally unacceptable, it ruins our business right now - and it will ruin your business soon. Our customers and your customers must never be excluded from accessing their own site. This is plain obvious business sense, right?

What script change on your side causes this and how to circumvent it this time, and why - again - have we not been informed? 3 questions, 3 answers please?

Cheers, David

 
Staff
2,342 Points
2014-10-02 4:49 pm
If there have been multiple failed logins to the site, the site can be locked down. The reasoning behind this is due to the severity of brute force attacks that are reaching all WordPress sites across all hosting providers, they are causing either accounts to become compromised or entire servers to load spike due to the massive amount of login requests that are coming in. To ensure that your website does not become compromised, not become completely unavailable when these attacks reach your site, your WordPress login may become disabled automatically by the system. To avoid this, placing a secondary password or sometimes preventing direct POST requests to the wp-login.php file as described in this article can prevent the brute force attacks coming through and thus prevent our secondary security measures from activating which is what you see here. Once your login is fully protected from brute force attempts using either a secondary password, or in some cases preventing direct POST requests (although this may not always be the case if the attacker is accessing your site to log in and not simply sending an HTTP POST request), your login will reactivate within 15 minutes. We do understand this can be frustrating at times, but please keep in mind that this is for the safety and stability of your site.
n/a Points
2014-11-03 11:45 am

For my first year on WHH, I could barely remember what the back end of my site looked like because I was locked out pretty much 90% of the time. Then things went pretty good for the past few months, but here we are again. I don't understand how to implement any of the solutions, and I can't go with something that locks me into one IP address because I travel. It seems like there has to be a better solution than to lock out the people who are paying for the hosting.
Staff
16,266 Points
2014-11-03 5:13 pm
Hello Ken,

I am sorry to hear you are having troubles with the solutions. They are working for thousands of our customers so we know they do indeed work. Which ones have you tried? We can assist you with any steps you have questions on.

Kindest Regards,
Scott M
n/a Points
2014-11-05 3:45 am

Sadly I am becoming a regular visitor to this page.

While LOGGING OUT I just received "http://our-site/mod-security-error/rule-13051.html" AGAIN.

WordPress Login Temporarily Disabled

Totally inappropriate mod security rules you have there.

 

:-(

 

 

 
Staff
2,342 Points
2014-11-05 3:48 am
This occurs when there have been several failed logins, typically due to attack on your site. To remove the message, you will first need to prevent attackers from launching brute force attacks against your site. Following the instructions outlined in this article will fix this.
n/a Points
2014-12-02 7:35 pm
Rather than having to edit obscure files, we should be able to phone or chat with a Web Hosting Hub admin who can verify our identity and restore access. Also, I don't think five muffed attempts constitutes a brute force attack.
Staff
17,314 Points
2014-12-04 6:17 pm
Hello Ed,

Sorry for the issues with the brute force attack. The logistics of this issue are hard to understand because of the differences in perspective. I can certainly understand your concern about wanting to directly contact support - and you can always do so, as our live technical support team is available 24/7. However, the brute force attack on WordPress site does not affect just a handful of websites. We're seeing it affect thousands of WordPress websites, and the attacks aren't simply "5 muffed attempts". The automated attacks randomly attempt to access WordPress admins using commonly used passwords or patterns. If you want to see more proof and facts about these attacks, check out Threatpost.com's reports on these attacks. These attacks affect ALL hosting services, not just us.

The main reason we have published this article was to enable our users to be able to setup their own security measures and also to help us in our own overall efforts at stopping these attacks by improving security practices/measures. I hope this helps to provide some information on the overall issue. If you have any further questions or comments, please let us know.

Regards,
Arnel C.
n/a Points
2014-12-13 10:17 am

Best option is change wordpress default admin directory to other directory and make a fake defalt admin directory. ;P
n/a Points
2014-12-24 4:26 pm

I was updating my site when it tells me my session has expired. I try my (correct) admin and password but it still refuses to let me in. Now I am blocked! This is ridiculous. I have no idea how to put this code that you suggest so I can get into my blog! I am not that clever! And if I say I have forgotten my password (which I havent but it refuses to recognise the correct one) it then tells me my email address is invalid so it cant send me a new one...

It is Christmas eve - does this mean my site is blocked until someone else can fix it for me? It should recognise the correct username and password that I am using not block me!
Staff
17,314 Points
2014-12-24 5:14 pm
Hello Jenny,

Sorry to hear that you're being blocked. The tutorial above walks you through the steps to enter the code. If you continue to have problems with logging into WordPress and you need to get in immediately, please contact our live technical support team. They are available 24/7 via chat/email/phone and help you with the password issue and blockage issue one you have verified your account for security purposes.

If you have any further questions or comments, please let us know.

Regards,
Arnel C.
n/a Points
2015-01-15 6:20 am
Regarding the /wp-admin/.htaccess file to be modified, you failed to explain what to do with code that was present in the file before modifying the file. I found out the hard way that all of the existing code MUST be retained. So then I had to figure out where to put the new code from the root htaccess file.

You should explain that the original code should NOT be replaced entirely.

This is what my file ended up looking like AFTER I corrected it (no thanks to your instructions):

# To set your custom php.ini, add the following line to this file:
# suphp_configpath /home/yourusername/path/to/php.ini

# BEGIN WordPress

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

<FilesMatch "wp-login.php">
AuthType Basic
AuthName "science"
AuthUserFile "/home/pspehb5/.htpasswds/public_html/wp-admin/passwd"
require valid-user
</FilesMatch>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
n/a Points
2015-03-15 9:17 pm

Nice set of instructions. Personally I've found that using CloudFlare works the best for me to keep out bruteforcers. With CloudFlare you can setup Page Rules to keep the brute forcers out, and they never even get a chance to fully load your page. That way, your server isn't getting bogged down by hundreds of requests.The method I use : http://www.eliteenvy.com/protect-wordpress-login-page-cloudflare-wp-login-php/

 
n/a Points
2015-05-09 9:14 pm

On my site (http://www.soazviadecristo.org/), I followed the directions, and this works great for the admin id/password.  However, I have a couple other users defined as editors to help maintain the web site.  The only way to get thru the .htaccess password is to know the admin password before you get to the second password prompt screen.

What is the best way to set up the site when you have one or two more users that can make updates and you do not want to tgive them the admin id/password?
Staff
1,198 Points
2015-05-11 7:29 pm
Hello Scott,

When I try to visit your admin url, it requires the htaccess password. That is what you would need to share with your editors. After that then they would be able to log in with their credentials.

Best Regards,
TJ Edens
n/a Points
2015-05-26 1:15 am
I am really upset about what has happened with my blog. Spammed to the max and then locked out with this difficult text to try and follow? I am not a computer wiz. I signed up with you because I thought it was professional and user friendly. It has been anything but.
Staff
12,339 Points
2015-05-28 11:04 pm
Hello Vicky,

Thank you for contacting us about receiving spam, and getting locked out of your WordPress site. We definitely understand your frustration, as spam, and brute force attacks are a big headache for us as well.

Here is a link to our guide on how to Fight WordPress comment spam.

If you are getting locked out, there is most likely a brute force attempt occurring. You can wait 15 minutes to try again, or follow the above guide to regain access.

If your problems persist, it may be easier for you to contact our Live Support team.

Thank you,
John-Paul
n/a Points
2015-08-15 6:35 pm

hi i follow your step it work great but 1 problem is register or sign up how can when someone click register and pop up and log in pop up too how can i allow register not to pop up letter box any way can fix ????
Staff
16,266 Points
2015-08-17 5:44 pm
If you are using the password protection method it will pop up every time that file or folder is first accessed. There is not a way to set a condition for it to not pop up if they have not yet entered that password.
n/a Points
2015-09-23 2:45 am
"First setup a password protected directory on your wp-admin directory." Should read: password protect the wp-admin directory.

"Now you can copy the text from your /wp-admin/.htaccess file created by cPanel." Copy it to where?
n/a Points
2016-06-03 2:26 am
I am unable to login to my Wordpress dashboard. After an attempt I was directed to this link: http://www.webhostinghub.com/help/news/general/wp-login-brute-force-attack I am trying to regain access to my Wordpress site and have done the follow according to the article: -password protected my wp-admin. -Before I saved and closed the text in wp-admin/.htaccess that was generated by cPanel, I added the following text above the text: ErrorDocument 401 "Denied" ErrorDocument 403 "Denied" # Allow plugin access to admin-ajax.php around password protection Order allow,deny Allow from all Satisfy any -cPanel created some text in /wp-admin/.htaccess. I copied that text and added the below text (sandwhiched) to my .htaccess that is at the same level as wp-login.php ErrorDocument 401 "Denied" ErrorDocument 403 "Denied" After doing all that I get the new sign in page that I created. I enter the username and password and then I am presented with another sign in page that is not the standard Wordpress branded login. I enter my Wordpress username and login and then I get: "ooops... error 404 We're sorry, but the page you are looking for doesn't exist." I have disabled ModSecurity and I still can not access my wp dashboard. Please help :)
Staff
12,339 Points
2016-06-03 5:59 am
Hello Kris,

Thank you for contacting us. As a test, try disabling mod security as described above.

If your problems persist, try renaming the .htaccess file and adding just one of the options above. If this resolves the error, then you know it's something in the .htaccess file. If it doesn't resolve the issue, simply change the name back to .htaccess.

Thank you,
John-Paul
n/a Points
2016-06-16 11:27 pm

Could the subject of this thread be responsible for the recent failures of my daily cron job to establish a secure connection?  I'm getting this error:

"OpenSSL Error messages:

error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed"

The script had been working fine for months.

Anyone know how to fix this?  I do not use WordPress, but the description of the brute force attacks indicate they extend beyond WordPress, so maybe my script's failure is due to WHH taking some sort of blanket protective action?
Staff
12,339 Points
2016-06-17 12:56 am
Hello Mark,

Thank you for contacting us. The brute force attack rules discussed in this article are specific to WordPress websites. Since it is the most commonly used CMS, it is targeted often by attackers.

Thank you,
John-Paul
n/a Points
2016-06-17 1:33 am

Hi John-Paul,

Thank you for your prompt reply.

I think the "Web Hosting Hub" in this sentence

"This attack is not just isolated to Web Hosting Hub"

must have changed to "Wordpress" in my memory, so yes, my SSL problem will require some other type of fix.

Thanks again,

Mark

 

Post a Comment

Name:
Email Address:
Phone Number:
Comment:
Submit

Please note: Your name and comment will be displayed, but we will not show your email address.

Help Center Login

Related Questions

Here are a few questions related to this article that our customers have asked:
Would you like to ask a question about this page? If so, click the button below!
Need More Help?

Help Center Search

Current Customers

Email: support@WebHostingHub.com Ticket: Submit a Support Ticket
Call: 877-595-4HUB (4482)
757-416-6627 (Intl.) 		Chat: Click To Chat Now

Ask the Community

Get help with your questions from our community of like-minded hosting users and Web Hosting Hub Staff.

Not a Customer?

Get web hosting from a company that is here to help.
}