WordPress wp-login.php Brute Force Attack

245 thoughts on “WordPress wp-login.php Brute Force Attack”

1. Hey, I install a new WordPress in Cpanel and when I try to go wp-admin I got this error. I create it new . just in 1 min how to fix that ??

   1. Hello,

      Thank you for your question. Unfortunately, I am not able to see what the error message says. I recommend contacting our Technical Support team for direct assistance with this issue.

      Best Regards,
      Alyssa K.

2. Hello, My name is William. I was trying to login to a members area with wordpress, but for some reason it says that I have been blocked from going into the members area. Also it said that I needed to wait until the block expires. How long will that take? Can some one assist me with this issue?

   1. I recommend you check out the Login temporarily disabled guide mentioned above.

3. In WordPress portal, i can’t see  my admin login button and one error is display “To use reCAPTCHA you must get an API key from https://www.google.com/recaptcha/admin/create“

   anyone plz give me solution

   1. If you have somehow loaded to the reCaptcha plugin, then you will need to disable it manually in order to login. You will need access your website files, and remove the recaptcha folder from your plugins folder. You should be able to login after that.

4. thanks

5. i tried to log in to my wordpress dashboard but isn’t  successful. wordpress kept signalling that there is error that i should allow cookies. i tried the instruction and put the cookies button on on my browser,yet same issue persisted. what can i do?

   1. I would recommend disabling any extensions you are using in your browser or switch to a different browser. If that does not work you may be having an issue with a plugin or theme on your site which means you will need to manually disable the plugins or theme to be able to log in.

6. I don’t use WordPress but I do log all access requests to my site. On an average day my site gets over 100 wp-login.php attempts from all over the world. Fully 90% of hacking attempts on my site are WordPress exploit attempts. Since most (probably all) are bot-net attacks I check the IP address and if they are a US company I send a note to ISP abuse contact informing them that they have a compromised machine on their service.

   I was thinking of having some fun and mimicing the wp-login process and seeing what these fools will do to try to do.

   1. Hello. I’m not quite sure what the issue you are experiencing is. I don’t see any errors at the link you provided. Are you still having problems?

7. Hello InMotion,
   Please we just tried logging out of our WordPress site but noticed a “WordPress Login Temporarily Disabled” page coming up. Please when will this block expire. And do you suggest we later install a plugin that can change the default “wp-admin” login page link to a custom link of our choice? Please reply, thank you.

   1. The block is lifted after 15 minutes. Then, lock down your WordPress admin with .htaccess rules, it should stop our rules from blocking your requests and lock out attackers.

      Thank you,
      John-Paul

8. I did not know this information … thanks for sharing your knowledge!

9. All of my .net websites get dozens of “wp-login.php” requests a day, so this is not limited to WordPress sites. The majority of hack attacks on my sites are WordPress exploit attempts. I usually redirect them to the Department of Homeland Security’s CyberCrime page with a tag of “I’m_a_stupid_hacker_Log_my_IP_address”

10. This is the easist of all hacks to prevent.   You do not need to go to extraordinary lengths.   

    1. limiting log in attempts to 3 trials is a typical number.  Where did it come from? Everyone uses that number.  You all buy into this magical number.  How many times have you had a brain freeze where you forget.  Or your browser has a brain freeze.   Limit to 6.  Any bot is eventually going to give up.    No bot is going to hit you for hours.   They are looking for easy doors.

    2. All-in-one-security plugin allows you to change the login directory.  That alone is nearly fool proof.    Really simple name can be used.    You never use login.php

    3.  The craze over passwords is insane!  8-20 letters. One capital   _ or ! but not – or $.  There are very simple alogrithms for passwords that can be memorized but are “unbreakable.”  Try this very simple example.  It’s just an example.  I could give you a dozen.    “The…..FBI…..is…..watching”    Try it.  Uncrackable.  or 1…..2…..3…..4…..5…..   Luckily finger prints and iris scanners will eventually takeover.   I use LastPass otherwise it would be hopeless. I have hundreds of password.   I can’t even remember how to log into Facebook.

    4. People live in the real world.  Use simple real world solutions.  Simplfy!

    5.  Even the captcha below is crazy and outdated.  Most of the time I can’t read it.  It can be very very simple.   “what is two + 3”    Simple.  

         

    1. Phil, thank you for sharing your take on this!

11. Hi,

    how long till i can login again to update my wordpress etc. =?

     

    1. The blocks last for 15 minutes, and so long as there are not more failed login attempts, you should be able to log back in after the block expires.

       Thank you,
       John-Paul

12. Thanks for the reply. To be clear I am writing to talk about protecting WordPress users on a large scale, not about how to protect a singe instance. That is why the method we use is httpd.conf based and not .htaccess based.

    I was hoping to hear your opinion on the two issues I’ve specifically talked about since I think these would affect your users if they made use of some of the techniques you’ve suggested, like IP based .htaccess protections.

    Using per-instance WP plugins is highly inefficient and as documented in some of your own posts can actually cause server-wide resource issues on shared systems and/or render a tiny VPS or CloudLinux instance effectively dead in its tracks.

    That is why we went with the httpd.conf method to protect all sites at once. But because of the two issues I mentioned (WP page protection and non display of AuthName) it looks like this solution may have to be modified or abandoned altogether.

    Also, your suggestion to protect wp-admin/ has its own set of issues. We’ve run into multiple cases where plugins that run on the WP front end pull resources from within wp-admin/. This could be looked upon as bad programming practice, but nonetheless it does occur and of course, as soon as that happens whatever protection that is in place for wp-admin/ gets invoked and an unsuspecting end user is either blocked based on their IP or challenged with a popup. And now with Chrome not displaying the AuthName (which is typically used to explain why a login prompt is being displayed) the end user will be confused and likely leave the web site.

    Also, we do make use of fail2ban with/csf just for good measure so that unusual, repeated access attempts to wp-login.php get blocked based on IP address.

    I think these are important aspects of protecting WordPress installations. Maybe some of your colleagues would care to weigh in? I’d love to hear some other thoughts, maybe something outside the box?

     

    1. Hello C M,

       Unfortunately we couldn’t implement a httpd method due to the nature of our shared/reseller servers. While plugins do pull from the wp-admin directory, you can protect direct access to the folder. This way your website can still pull from the folder but if a browser directly went specifically to wp-admin it would ask for an additional password or be IP restricted. I would suggest also reaching out to the wordpress.org community to see if they have come up with multiple WordPress login protection solutions.

       Best Regards,
       TJ Edens

13. Thank you for having this public area.

    Locking down wp-login.php can done in a variety of ways. I prefer forcing the user to do a simple human check by password protecting wp-login.php using LocationMatch directly from the httpd.conf file, server wide. This is extremely efficient and universal for all web sites on the web server.

    While this method does work well there are two problems that I’ve not seen mentioned. I was hoping I could pick your brain on some ideas.

    The first issue is if a customer is making use of the built in WordPress per-page password protection (as a means for protecting private content, not for stopping hacking attempts). When an end user enters the page password, WordPress actually invokes wp-login.php! That means any protection in place that was intended only for the admin user now gets invoked by an end user simply trying to log into a WordPress password protected page. In my case this means an .htaccess style popup is displayed asking them to prove they are human (as if they were trying to log into the WP backend). But for those who use an IP based .htaccess style protection for wp-login.php this would immediately stop the end user from being able to continue and they would never be able to access any password protected WP pages.

    The other issue is that on newer versions of Chrome (and maybe other browsers) the AuthName is not displayed. So there is no way to explain to the end user what they are supposed to do if they do encounter the httpd.conf based human check login box.

    These two issues may render the best, most efficient protection against wp-login.php hacking available completely useless, forcing people to go back to PHP based WP plugins, which IMO are not viable on a large scale.

    I would really enjoy hearing InMotion’s thoughts on these two issues.

    Thank you!

    1. Hello C M,

       What I would suggest to resolve issues on both parts is a plugin such as limit login attempts. This plugin blocks the users IP after 3 failed attempts (can be changed) for 24 hours (again can be changed). So if someone sent out a botnet to attack your website each IP is only getting a few chances. Also you can not put in the wp-login.php and just leave the wp-admin/ while locking it down.

       Best Regards,
       TJ Edens

14. how long do you block our log in page – we need to add things asap!!!!!

    1. The lock comes off in about 15 minutes, but if you need to access your site right away you can disable mod_security in cPanel. However, this leaves your site more vulnerable to brute force attacks. So I recommend turning off for as short a time as possible, making the most use of time to secure the login page with the methods listed above.

15. Hi,

    I’ve just had the temporarily locked out thing.  Sorry this is my first website and I can’t remember all the terminology all the time.  Not attempted to get back in yet as I want to make sure I do it right and am reading up on it.  I see in the article for using the plug in that it’s not suitable anymore.  I don’t think option 2 will work for me as I travel around a lot through multiple countries and need to be able to log in from wherever I am.  I have a strong password, but will replace it anyway once I’m back in.
    What would you recommend that I do?

    Many thanks

    Fiona

    1. Hi Fiona,

       Do as many of the options as possible, you do not need to do all of them, but the more you do, the better.

       Kindest Regards,
       Scott M

16. Hallo!

    How to protect A wordpress site when the brute-force attack is on the “Front-end Membership” login box?

    🙂

    1. Hello Marco,

       Thank you for contacting us. I recommend using a security plugin such as WP-reCAPTCHA to protect from spam registration attempts.

       Thank you,
       John-Paul

17. There is one malicious UA site that is repeatedly attacking  us.  How do we report these people?

    1. Hi Philip, there’s nowhere to really “report” them. I’d suggest trying to block their IP address. How exactly are they attacking you?

18. Having been under a brute force attack for several days, I just wanted to chime in with what I did to resolve my problem – without modifying the .htaccess file or using a 3rd party “hide the login page” plugin.

    Using the free Wordfence plugin that I’ve had installed for quite a while, under Live Traffic Views> Live Logins & Logouts, I noticed that the majority (if not all) of the attacks were originating from Russia, and the attacks rarely came from the same IP address.  So trying to block specific IP addresses was not a logical option.

    With premium Wordfence service, Wordfence has the ability to block countries with one click.  But since I don’t have the $40 to spend right now, I found a great free country blocking plugin called IP Geo Block.  It’s available at https://wordpress.org/plugins/ip-geo-block/

    This plugin allows you to manually create a black list of all countries you want to block, and it also allows you to create a white list of countries you of course want to allow through.

    But after I activated the IP geo Block plugin, my attacks dropped from 20-30 attempts an hour to perhaps just a few a day.  And over the past few days, I’ve not had any problems logging into my WordPress site at any time of the day or night.

    As a footnote, I saw what appeared to be the attacking robots trying to skirt around the RU block by going through some infected sites that originated from the Ukraine so BAM!  I added the country code UA to my black list and ended that real quick too!

    The plugin is easy to use (for this novice WordPress user), and it also has quick-links for access to all global country codes definitions.

    All has been peaceful since I added this plugin and since I don’t sell anything online globally, I have no problem blocking the entire Russian Federation or Ukraine either.

    Frank

19. When will i be able to regain access to my site?

    1. Hello Marc,

       If you’re getting blocked by the brute force protection on the server, then you can regain access within 15 minutes. If it continues and you still have problems, please contact our live technical support team for immediate assistance via phone/chat/email. They can help you get immediate access.

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

       Kindest regards,
       Arnel C.

    2. Hello Oviya,

       If you require information please let us know what you are searching for. You can contact our live technical support team for immediate assistance if necessary. We unfortunately cannot contact you via phone.

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

       Kindest regards,
       Arnel C.

20. Well, recently Brute force Attacks has immensely increases, becoming a dangerous factor for for all WordPress users, but it is thing, which is fight-able, I mean, by using security methods, we can move brute force attacks out of the window. Although, it can be difficult for a  newbies who just got started with WordPress, but he can learn by reading posts online and then can implement security.
    In my view, implementing only three tricks works very well, Changing Login Slug, A content Delivery network (CDN) and a Security Plugin, which bans IP address after a few Login attempts. I ma using this on my blog and it is working fine.

21. The thing is, I keep getting the message when I’m trying to log-out!  

    1. Hello Julie,

       Thank you for contacting us. We are happy to help you troubleshoot, but will need some additional information. What is the full error you are getting when you log out?

       Have you tried Turning on WordPress debugging? This may provide a more detailed error.

       Thank you,
       John-Paul

22. Why not simply rename the wp-admin.php to another name?

    your login url would be something like mysite.com/anothername The brute force bot would be looking for wp-admin.php and receive a “Page Not Found” error.

    This works for me.

23. Just log in via the regular user login but with your admin credentials. You can then access the admin section.

    1. Hi Jacob,
       Thanks for the information.
       I know this is an old post, but here is what I did as a layer of protection from the brute force.
       I added the following line at the beginning of the wp-login.php
       if ($_GET[‘something’] != “value”) { exit(); }

       then edited the line:

       THis is inasane. I just signed up for inmotion and installed WordPress. and now I am unable to login. Can yoiu please remove the block?

       1. Hello Harish,

          You may want to check into the Brute Protect plugin to assist with keeping this issue at bay.

          Kindest Regards,
          Scott M

    2. I posted a question last night but have not seen it appear as of yet? I have been hosted with you for several years with a main and addon domains with WP.

       Have had the ‘prevent unauth access’ in place for referer attempts for most of that time and it has worked. Lately however it is not working. Seeing failed remove attempts to login.

       Yesterday I sought to implement the limit login by restricting the IP addresses to mine and 10 others ip addresses – with the referer code in place and without it . Testing it afterwards and I was still able to log in from an alternate IP address… ? (if this is not the correct place to post or more details needed please let me know. thank you.

       1. Using the referrer method can sometimes still fail if any attacks access your login page before sending a POST request to it.

          As for the IP filtering rules, those should be blocking anything that isn’t listed there. Could you provide me with the exact code that is within your .htaccess file?

       2. In addition, could you provide me with your site URL so that I can also test access to the WordPress admin with my IP?

       3. Thanks Jeff Ma – made sure cell was not on the wifi – earlier post reply *wordpress/lock-down-wordpress-admin-login-with-htaccess-* same core thread but different thread route… : ) aggregating the 2 into one here – thanks for that info though

          the code at the top of the htaccess is as follows – before wp super cache which is then follow by basic wpress code for the site: island real estate with a dot com url.

          Options -Indexes

          
          RewriteEngine on
          RewriteCond %{REQUEST_METHOD} POST
          RewriteCond %{HTTP_REFERER} !^https://(.*)?my domain name is here\.com [NC]
          RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
          RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
          RewriteRule ^(.*)$ – [F]
          

          
          RewriteEngine on
          RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
          RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
          RewriteCond %{REMOTE_ADDR} !^xx\.xxx\.xxx\.xx$
          RewriteRule ^(.*)$ – [R=403,L]
          

       4. Your .htaccess file looks just fine. Could you provide me with your domain so that I can test the login as well? With the code you have there now, it should be blocking any IP addresses not defined without any issues.

       5. its there my last reply – 2nd paragraph top – end of the sentence –

       6. Thanks. I’m actually getting a 403 error like I should be, so it appears that everything is working. You may just be seeing old cached data if you are accessing it from an unallowed IP.

       7. thank you very much – i am getting 403 now on wp-admin – I typically am logging in via .com/login and it still provides access which I realize is probably outside the scope here : ) I use theme my login for style purposes and will see if it has a code box for the IP restriction. thank you.

    3. This site is really helpful.

    4. Hi Jacob,

       Thanks for making this block.

       I think my website ww.hmxmedia.com is also facing  brute force attacks.

       But first i want to share my website’s problems.

       My website is taking too long in loading even i am not able to open wordpress admin page. sometimes it open but can not go to lugin page it says this webpage is not available. using ftp also some times it connect sometimes not.the only thing i am able to work on is my hosting console panel.

       Can you please help me in this as soon as possible

       1. Hello ankur,

          Thank you for contacting us. If you suspect you are being brute-force attacked, I recommend reading our section above on Brute force protection.

          Also, for speeding up your website, please see our guide on Optimizing WordPress, as it explains many ways to speed up your site.

          Since your site is not hosted with us, I could not check your server. But, it may be helpful to contact your host when you are unable to connect. As they may be aware of known issues causing the problems.

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

          Thank you,
          John-Paul

    5. WP has a plug in for that.  I have admin blocked unless you are logged in and they can’t log in because wp-login doesn’t exist under that name so all they get are 404s.    The entire backend is blocked unless you log in.  There is no where to register because there is no need for anyone to register since I am using it as a website with no blog or comments.   It’s been downright quiet.

    6. I’ve used IP Blacklist Cloud quite successfully to block repeated attempts on a wordpress install and anyone trying to login as “admin” is automatically blocked. The IPs are stored on my site and attacked have dropped off dramatically. No. I do not work for them.

       1. Ultimately, what I’ve done is renamed my login to something ridiculous, and it’s worked for me.

    7. Ah, understood.  Thanks for staying attentive to these comments.  Very helpful.

       1. No problem, Wayne! We do appreciate the feedback and the questions. Let us know if you require any further assistance.

          Regards,
          Arnel C.

    8. Thanks for the reply, JeffMa.  But, again:  I don’t understand how any of your suggestions here (in your reply to my post) would help.  The web server still has to respond to each and every request from a client, whether it’s to reject the direct POST, reject based on the IP address, or deliver a 404.  

       Is it because the brute-force perpetrator will abandon the exercise if they see 404s or other error/rejection messages?  (This would make much sense.) 

       1. We have noticed that most of the bots will cease attempts when they reach various HTTP error codes so it certainly does help.

          In addition, a request that is directly returning an error will use far less resources than WordPress fully processing the login attempt, therefore can handle 1000 403 errors much better than 1000 direct POST requests to the WordPress admin page.

    9. Not trying to be pedantic here, but how would changing the admin username/password reduce brute force ATTEMPTS…?  It might reduce the chance of success, but the bigger problem (assuming you have a strong username/password) is the CPU utilization, in which the brute-force attack becomes more of a Denial of Service attack.  

       Wouldn’t a perimeter DDOS-migration approach be more effective (and far easier)…?

    10. There is no reason to assume say that inmotion hosts get attacked any more than other hosts, and I work with over a dozen other hosting companies and none of them implement this (and I also never had a problem getting hacked, ddos, etc) So why does inmotion take such a disruptive stance on this?

        It is more inconvenient and frustrating than anything and having been a sysadmin and network admin for over a decade, I find this quite on the extreme. 

        There should be a one checkbox option on our dashboard to turn this *on* if we want to. 

        Please consider fixing this.

        1. Hello Oscar, and thanks for your comment.

           Typically our internal ModSecurity rules that protect our entire server fleet from unwanted WordPress brute force attacks, don’t interfere with normal admin login activity once a WordPress user implements their own brute force protection.

           It’s an extra level of protection to ensure not only our own customers are safe, but also making sure our customer’s aren’t unknowingly setting up an insecure WordPress install with a simple password and then our servers going out and attacking other WordPress users at other hosts.

           It’s a lot easier helping a customer protect themselves by setting up a secondary WordPress admin password, or they could change the WordPress admin url with the Lockdown WP Admin plugin. The steps to reinstall WordPress after a hack aren’t nearly as easy to follow along with, and we’ve heard this from customers so decided to be proactive in this case.

           We still see WordPress brute force attacks on a daily basis, and the typical customer doesn’t pay too much attention to their website, or have the server knowledge to make sure they are safe on their own. We are still looking for a better alternate solution that’s easier for everyone all around.

           Thanks again for your comments, and please let us know if you have any other questions.

           – Jacob

    11. Hi,

        I modified the Htaccess file and limited it to only my ip and it still blocks me out.

        This morning I was able to regain access, but when I tried again now, still blocking me again.

        I will wait 20 minutes before trying again… But this is getting anoying and it’s not the first time it happened to me.

        Could you suggest something else or try to see where is the attack coming from? Is this blocking protection only happening when someone is tryin to access the wp-admin?

         

        Thank you

        1. When blocking based on IP, only your IP would be able to even see your WordPress admin without getting a 403 error stating that permission is denied. With this block correctly in place, nobody else but you would be able to see the admin login, therefore, would never trigger your WordPress admin to be locked down to prevent brute force attacks.

           If your WordPress admin is still being blocked, it sounds like you have not placed the lines within your .htaccess file correctly. I recommend checking over your .htaccess file to ensure that the correct lines are at the top of the file. You may also check to see that it is correctly in place by attempting to access your WordPress admin from another IP address that is not defined within the .htaccess file. If you are getting a 403 Permission Denied error, the changes are in place correctly.

    12. Just got blocked out of my site! I have work to do! Please assist!

        1. As described in this article, your WordPress admin dashboard becomes locked down in the event that there have been several repeated failed login attempts. To regain access, you would need to stop those login attempts that are trying to steal your password by placing additional protection within your .htaccess file.

    13. Hello guys, I cannot get acces to the Word Press blog of the William PAterson University’s Music Biz blog. We suppose to submit an assignment today for the Music Business class and it seems that I have forgot my password:((( Are there any possible solutions??

        Thanks a lot!!!

        1. Hello fima,

           Thank you for contacting us today. You may be able to reset your Wordpess password via email, which is explained in this guide.

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

           -John-Paul

    14. My access to login to my wordpress site is blocked. What do I need to do to regain access?

         

        1. Hello Ratopati,

           If you are seeing this message you will want to apply one of the solutions on this page. This should help eliminate receiving this message in the future.

           Kindest Regards,
           Scott M

        2. Hello Mara,

           Thank you for the kind words! It is always nice to hear from someone who knows and appreciates the issues that hosting can bring!

           Kindest Regards,
           Scott M

        3. Hello Vicki,

           If your site admin area is being blocked you will want to perform the instructions on this page. If you are having issues after that, please reply with the specific steps you have taken so we can take a look at your individual situation.

           Kindest Regards,
           Scott M

        4. Hello Phil,

           Thank you for your comment. The solutions on this page will help with the login issue, but will have to be enacted by the owner of the website. This is because you must have access to the .htaccess for WordPress.

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

           -John-Paul

    15. Am an avid reader of FreakoutNation, and was wondering how to set up a login account?

         

        Thanks for your time!

         

        Phil Palmer

        Gulf Coast USA

    16. I’m not a client, in fact I’m a competitor. You don’t need to make this comment public (if you don’t want to), I just wanted to say that Jacob, Arnel, Jeff and the other support staff are doing an AMAZING job under very difficult circumstances.

        The patience you’ve shown in dealing with some of your customers who don’t understand the value of a proactive approach to security is impressive. These are the same customers who would brerate you to no end over downtime due to a DDoS, and expect that you should have done more when they site gets hacked.

        Kudos.

    17. i couldn’t open admin
        it looks like 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.

    18. We are changing hosting once our term is up. I support two other clients that are on other hosting services and I implement solutions for security that eliminates most risk. But, supporting this one client when they continuously cannot log in is not a sustainable choice for us. My recommendation for WP will never be to use your hosting service unless you change this. I would recommend a less hands-on approach. Help people WHEN they get hacked. Give ways of preventing, but don’t limit access. It’s just bad business.

        Do what you like, that’s just my advice.

        1. Hello Thomas, and thanks for your comment.

           While not an ultimate solution by any means, I would recommend changing your WordPress admin URL if you are experiencing WordPress brute force attacks, as more than likely the majority of the bots hitting you are simply sending blind requests to the default admin URL.

           Sure some bots could potentially find your hidden URL, but you could be wasting resources needlessly on 90% of the dumb bots that try to hit your WordPress site. It’s a very easy if you’ve changed your URL to then review WordPress login attempts and just look for IPs or User-Agents hitting your hidden URL. You would know then they’re bots for sure if they aren’t you, and can manually block them with your .htaccess rules.

           You could rely on a plugin to help keep bots out, but this requires a PHP script execution for each and every request typically, which could lead to higher CPU usage if you’re under attack. Using your own custom .htaccess rules to limit access is highly recommended as mentioned in this article we recommend limiting WordPress admin access with them, or setting up a secondary WordPress admin password to help keep bots out.

           In regards to the Big Brother aspect of a web host stepping in and protecting their customers, unfortunately in this case it is an unfortunate necessity. I’d guess that probably 1% of our own WordPress customers if that enact their own WordPress admin protection on their own. So we step in for the security of our server population, and to make sure we aren’t hosting hacked WordPress accounts that then go off and attack other WordPress sites.

           It wouldn’t be fair to let 10 WordPress sites on the same server as yourself just sit there and use up server resources over and over until the owners decided to protect themselves. Most customers after implementing their own WordPress security will stop triggering our internal security ModSecurity rules, and we can disable it altogether on an individual customer basis if they continue to have problems with it.

           I couldn’t find an account with us based off your email, but if you were having any issues with our security rules locking you out of WordPress please let us know!

           – Jacob

        2. Hello again Thomas,

           Sorry to hear that. I’ve worked with hundreds of our customers to try to clear up any problems they’ve been having with WordPress brute force issues, and I’d be glad to help you out if you’re still having problems. It’s usually a matter of reviewing their logs, ensuring they aren’t under constant attack, making sure they have their WordPress site protected, and then we can disable our ModSecurity rules for them. You can comment here with any account info and it won’t go public until we remove any private data and approve the comment if you’d like me to take a look into an account for you.

           We do help customers when they get hacked, and in this case our approach is proactive. The largest scale brute force attack against WordPress had occurred back in April 2013 when I first wrote this guide and it continues to come in waves here and there which I’ve always noticed in the Google traffic to this guide spiking as people search for help.

           We limit access, because most WordPress website owners don’t pay attention to the security of their site. It’s a lot easier to prevent the hacks from happening in the first place then having to reinstall WordPress after a hack.

           Sorry for any frustrations, I can tell you on both sides of the coin this isn’t a fun problem to deal with.

           – Jacob

    19. Changing your login location is not a recommended practice as bots can still find you. It’s better to take an action-based approach. Plus, I don’t like any hosting service taking my sites security over and limiting my access. It’s a little bit like Big Brother. I have a plugin that adds a captcha at login that eliminates almost all attempts for bots to log in. So, this feature of disabling the wp-admin login is really not needed at all. Plus, I use custom .htaccess rules to take action on bots or suspected ones.

    20. Jacob, I’m a mere mortal running his business 🙂 who would like some expert help to just solve this problem for me. Something you’d be willing and able to do? If so, pls email me and thanks…

        1. Hello Bob, I’d be glad to help!

           I went ahead and removed your email from this post before making it public, and sent you a separate email with further details specific to your account’s WordPress login issues.

           If you’re still having any issues at all, feel free to comment here again or just reply to my email directly!

           – Jacob

    21. this sucks. way to protect me with more annoying crap. you are my only problem. thanks for sucking.

        1. Hello Noah,

           I went ahead and implemented secondary WordPress admin protection for you.

           You can get in with:

           Username: noah
           Password: wordpress

           If you’d like to setup a different user, in cPanel just go to Password Protected Directories and then click on your wp-admin folder and you should see the Create User section towards the bottom.

           I’ve also gone ahead and disabled our WordPress ModSecurity rules for your domain now that this secondary password protection is setup.

           Sorry for any issues, please let us know if you have any further problems!

           – Jacob

    22. Hello,

        This is an excellent guideline and I have taken all precautions as suggested here. I have one query though which I tried to get resolved through your mail support but could not get satisfactory answer and hence am posting it here:

        1. Won’t locking down of WP admin area to this extend will lead to attacks on cpanel ?

        2. Why  there are no provisions to lock-down cpanel to this extend ?  eg. provision similar to that given by HC Custom WP-Admin URL plugin, or cascaded login where second login will have a onetime password sent to a pre-registered email ID, or cascaded login with Google/Facebook/Stackexchange login IDs ?
        

        3. Your representative told me that since cpanel login is done through a secured server it is not prone to attacks. I am not sure what makes this hold true ? Can anyone please elaborate more ?

        Thanks and Regards,

        Tekihcan

        1. The WordPress brute force attacks are targeted specifically at WordPress and are blingly firing at every WordPress site that their bots find, so the attackers are not going any further than WordPress at the moment as their bots are not configured to attempt multiple locations. As they are unsure of what you are running on the back end, the bots don’t even try to access any other services other than WordPress.

           Currently, cPanel does not support any form of 2-factor authentication at the moment. Although they may build it in at some point, we are unaware of any plans of them to release it. When they do, we may indeed implement it on our servers.

           We have brute force protection on all of our servers to keep cPanel secure. Repeated login attempts to cPanel will result in a blocking of the IP from the server. I cannot provide you with much more than that regarding the security practices of the servers, but rest assured that they are monitored 24/7 and we do our best to keep your information secure on the server side of things.

    23. I’m not a customer, but a client is. He’s asked me to implement your suggestions, but most either don’t work or become way too cumbersome. I hit on an easier solution.

        Create a new php script in the main folder. Name it anything you want. Inside the folder use the following code…

        <?
        setcookie(“MyLogin”, ‘valid’);
        header(‘Location: /wp-login.php’);
        ?>

        You can change “MyLogin”, actually it’s better that you do, to reduce the chance of someone spoofing the cookie.

        At the very top of wp-login.php, just below the <?php add…

        if($_COOKIE[‘MyLogin’]!=’valid’)
          {
          exit();
          }

        …make sure “MyLogin” matches what you set the cookie to in the first script.

        If someone loads wp-login.php without first going to the other script and having the cookie set, then all they get is a blank page. Access the first script to log in.

        1. Hello Danny, and thank you for your suggestion.

           Implementing a Cookie check within the wp-login.php script like you’ve shown, could be a viable option for trying to ensure that an attacker doesn’t get a valid login from being able to POST to your wp-login.php script.

           Unfortunately, if your WordPress site is under a brute force attack, there will still be POST attempts sent to the wp-login.php script from the attacker. The attacker is not going to first try going to the main site, they will just directly POST to wp-login.php. So our internal ModSecurity rules could still kick in if you’re only using a cookie checking method to limit access.

           The best sure fire way we’ve seen for limiting access to your WordPress admin dashboard is to use a secondary .htaccess password and still allow requests to /wp-admin/admin-ajax.php for plugins.

           Doing it this way, a POST request can not even be attempted on the wp-login.php script from the outside, because it’s being blocked at the .htaccess level, and not allowing the request at all to come in and fire up PHP to run a cookie check to determine if it’s a valid POST attempt or not.

    24. Jacob,
        It’s Charles, but no big deal.
        I actually meant “HC Custom WP-Admin URL”, not “custom registration link”, but I couldn’t find any way to edit my comment. Please change this for others searching this forum, if possible.

        1. Hello again Charles, my apologies on the name mix-up.

           I went ahead and updated your comment, and if anyone else runs across this guide as well, I do also have another guide on the WPS Hide Login plugin that you mentioned.

           Please let us know if you find any other helpful plugins or methods for helping manage your WordPress security.

    25. I had installed the “HC Custom WP-Admin URL” WordPress plugin and have been adding additional configuration to my htaccess file over the last few days after experiencing a brute force attempt on my wordpress site.

        Unfortunately, the “HC Custom WP-Admin URL” plugin does not play nice with some other plugins, and most importantly to me, was causing the styling on my registration page to not load. I manually changed my htaccess file to address this, but it was a pain, and I know that I would probably have to replace this htaccess file any time I would update WordPress in the future.

        This morning, I found the “Better WP Security” plugin. This allows you to change your login, admin, and registration links to whatever you specify. It also works seamlessly with my other plugins and allows the registration styling to load properly. It has many configuration options that allow you to better secure your site and protect against attacks. It modifies your htaccess file cleanly in one section all from the plugin settings database and has an easy to understand, color coded dashboard that allows you to see what features you have enabled along with the protection gained from each.

        I highly recommend this plugin, and I cannot thank the author enough for writing and maintaining such an excellent tool.

        1. Hello Charles, thank you for your comment.

           I took a look at the WordPress Custom Registration Link plugin, and it does look that could be a helpful plugin if you’re having issues with fake WordPress registration attempts, and not just logins. But please note that plugin seems to not have been updated for over 2 years, so users might experience issues with it.

           Like you mentioned the WordPress Better WP Security plugin is a great robust security plugin, in most cases it can be overkill for your general WordPress user though.

           Thanks again for your recommendations, and let us know if you run across any others.

    26. Hi mates, good paragraph and pleasant arguments commented here, I am in fact enjoying by these.

    27. Hi
        changing the admin name does not solve anything as one can call any wordpress site by author id revealing the new admin name,
        https://yourwebsite.com/?author=1
        those are bogus and temp solutions. You need to change the admin name and disable the author pages or at least create a huge users database and hide the admin within those.
        Best regards,
        BackuPs

        1. Hello BackuPs,

           As these brute force attacks are completely bot generated, changing the admin username will indeed help as they are not checking for a username on the site, but just simply trying to log in under the username of “admin” regardless of what the actual username is.

        2. Hello BackuPs,

           As Jeff had mentioned, these brute force attacks are typically carried out by bots which won’t go the extra step of trying to discover your admin user from any author pages.

           If your admin user was ID number 1, and you wanted to block anyone from being able to call their pages at all, you could simply add this to the top of your WordPress .htaccess file:

           RewriteEngine On
           RewriteCond %{QUERY_STRING} ^author=1
           RewriteRule .* – [F,L]

           This would deny any requests for example.com/?author=1 with a 403 Access Denied error.

           Ultimately it would be best to limit access to the WordPress admin dashboard altogether, so that even if someone did know your admin username they wouldn’t be able to attempt logging in.

    28. Hi, i have a really dumb problem here…

        I changed my admin password yesterday and forget to give the new one to a guy who works with it. The guy tried to login with the old password a lot of times and now the account is blocked for 24 whole hours! 

         

        Can i do something to fix it right now? 🙁

    29. Hello TheBoatPeople, thanks for the kind words!

        That doesn’t appear to be malicious in nature more than likely. It looks like the Fast Secure Contact Form uses the /captcha/cache/ directory to place temporarily CAPTCHA challenge responses.

        When using the Better WP Security plugin, you can navigate to Security from the left-hand menu, then click on Intrusion Detection.

        If you scroll down to the File Change Detection section, there is a Include/Exclude List drop-down that you should set to Exclude. Then below that in the File/Directory Check List field type in an exception for the Fast Secure Contact Form like this:

        wp-content/plugins/si-contact-form/captcha/cache

        That should stop you from getting alerts about files in that specific directory. Please let us know if you had any other questions at all!

        – Jacob

    30. is this a malware code injection?

        cache/xedmdvy4vnroflyJ.php file has changed – is this a malware code injection?

        my Better WP Security sent me an email:

        A file (or files) on your site at MYSITE.com have been changed. Please review the report below to verify changes are not the result of a compromise.

        wp-content/plugins/si-contact-form/captcha/cache/xedmdvy4vnroflyJ.php

        i’m using Fast Secure Contact Form

        thank you!
        TBP
        (IMH customers you better take what the IMH guys say seriously, cause my cpanel account was hacked with code injection (which i found sunday night, who knows when the hack took place)). my passwords are all strong to very strong, i doubt that’s the way my account was breached, that’d be 1 in a trillion. after installing Better WP Security, which IMH techs suggested, i only get 3 Red alerts and 2 are false Red (it’s actually been done). my only Red is DO NOT NAME YOUR DATABASES PREFIXED WITH “wp_” but this is the IMH/Softaculous default.

        Thanks for all the help IMH, i’m positive NO OTHER hosting service would give this much help to customers! i’m positive i would have gotten the “this it outside our hosting agreement there’s nothing we can do you’ll have to hire a security firm, we only provide hosting space”. i’m positive this would be the response from other hosting companies!

    31. Hello swolock,

        No problem at all, glad to help! If you’ve already setup a secondary WordPress password for your site, it’s probably not necessary to also restrict access to WordPress admin by IP address.

        Most bots won’t attempt to guess your secondary WordPress password, as they’re expecting to be seeing a WordPress login form, and not a .htaccess password prompt pop-up. If you’re restricting access by IP and just wanted an additional level of security on top of that it won’t hurt to have both, but again it’s probably not needed since either way you’re greatly minimizing the potential of a malicious user guessing your valid WordPress admin credentials.

        – Jacob

    32. Hello swolock,

        No problem, let us know if you have any further questions at all!

        – Jacob

    33. Jacob

        That’s what I thought. Thanks again for your very helpful help.

    34. Jacob,

        Thanks for the informative articles. My question: is it best to use both the secondary level password as well as allowing access by IP, or is it best to do one or the other?

        Thanks

    35. Hello Paul,

        Sorry to hear about the continued problems you’ve been having with our WordPress Brute Force protection on the server.

        From the information you’ve provided, and looking at your access logs for today, it would seem that some attempts to the WordPress wp-admin directory, as well as the wp-login.php script were attempted today, and they did trigger a 403 access denied error.

        The 403 error would be logged when one of the .htaccess methods for blocking access to your WordPress admin is implemented. I don’t see any 503 errors which is what would be logged when our Mod Security rules are triggered, which would show an error message directing you back to this article.

        The whole concept is that if a bot is attacking your site, it will keep attempting to hit your wp-login.php script with login attempts. Our Mod Security rules block this from happening,if continued incorrect login attempts occur on your WordPress login.

        If you successfully supply your correct WordPress login credentials, this should log as a 302 response, and the Mod Security rules should be ignored. However, if it’s a failed login attempt, you will see continued 200 responses to your wp-login.php script, without a redirection to the /wp-admin directory, and eventually a 503 error that is our simple block page with a link to this article.

        This is what it would look like from the Logs >> Latest Visitors cPanel tool if your WordPress site triggered our Mod Security rules:

        

        You can see at the bottom the first attempt is a GET request for the wp-login.php script, and it gets a 200 status. Then it’s followed by 4 POST requests all showing a 200 status, and then finally on the 5th POST attempt it throws a 503 error. It’s at this point when further login attempts would all re-direct back to the page that then links off to this article.

        If you however are seeing 403 errors that means you could just be triggering any .htaccess rules you’ve implemented. In you case it looks like a matter of when you setup the limit by referer method for blocking, it seems your domains got mis-matched.

        What I mean by that is that it looks like when you were trying to login to WordPress admin for domain1.com your referer string was coming from domain2.com. To prevent that from happening, you’d want to be sure to directly visit your WordPress website at domain1.com, and then from there go to domain1.com/wp-admin to attempt to login to the WordPress dashboard for that site, or you’d want to be sure to edit the .htaccess file for each domain to also possibly expect one of your other domains as the referer URL. This appears to be already done for your primary domain, and I’m guessing this is what support found out for your from reading an account note.

        At this point, it doesn’t look like your site has been under a brute force attack recently. I’ve gone ahead and also enabled raw access logs on your account for you. This can help in the event that you continue to have any problems, as these archived logs can be investigated for any patterns that might be triggering any security rules.

        At this point, because you’re not under a heavy brute force attack, just leaving the referer method active for blocking should probably be enough. If you’re actually having issues logging into WordPress itself, make sure that you’re not just incorrectly logging in there which could then trigger our Mod Security rules. You can always reset your WordPress admin password if you think you’ve forgotten it.

        If you continue to have issues, or have any further questions at all, please let us know!

        – Jacob

    36. If the lock down targets multiple attempts regardless of correct info, and it is hitting me even though I am using correct info because attempts are already being made, which it seems you are telling me, then why does it give me three attempts instead of just locking me out immediately? It would seem to me that if my wplogin is under attack, I would be locked out period until the attack ended.

        I returned my HTaccess to its normal state. I will change it to allow multiple IPs once I am sure access is normal again for all users. I have checked resources, and it does not appear anything unusal is taking place. CPU usage is low, no overly large number of bot visits, bandwidth low. I am going to call tech support and hopefully get this taken care of decisively. As I mentioned, already went through it once, and now have the same problem all over again. I have no time for it and it is eating into my work time.

    37. What information do you have within your .htaccess file?

        The teasoning behind locking it down even with the correct password, is because this is triggered when multiple people have attempted to log into your account with an incorrect password, thus locking out all users to avoid them guessing your password and gaining unauthorized access to your WordPress site.

    38. I made the HTaccess change, which did nothing. I then went through about 45 minutes with support which got me back up and running. Then today, I am back to square one. In addition, domains I manage for others are now inaccessible to them due to the HTaccess change.
        What I don’t get here, is that I am using the corrrect login information on my WP sites, as are my friends, yet it will not alllow access, and then locks you out after a couple tries. If you use the corrrect login information on the first try, why will it not allow access normally?

    39. Hello PaulN68,

        We placed these rules in place to protect our customers, as the brute force attacks can either cause your WordPress site to either become compromised, or overload the servers taking your site down due to the severity of the attacks. If you are still getting the message saying that the login is blocked, this means that attacks are still failing to log into your site which keeps the block on. Be sure that you are blocking your site within your .htaccess file by either filtering by IP, or by adding a secondary password to lock down your WordPress admin.

    40. Wow, this is extremely annoying. I can’t help but feel this is not a workable solution. I have been blocked out of my sites, changed HTaccess, still screwed up my password, and am now once again blocked . To make matters worse, hours later I still have no access. IMnotion has been stellar for me for years, so this kind of annoyance is very unexpected. My WP sites on other hosts have not skipped a beat, just Inmotion, which leads me to wonder are they using a better solution, or am I just lucky? At any rate, getting back in would be really nice considering I am PAYING for this service I now cannot use.

    41. The 403 error is due to the IP requesting the site being blocked within your .htaccess. Because of how Cloudflare works, you are actually interacting with their server, and then their servers are requesting the information from the site. Thus blocking based on IP will not work correctly unless you were to add all of Cloudflare’s IPs and then any individual would still be able to go to your site so it would not be blocking anything. You could try disabling Cloudflare, or you could password protect the directory instead.

    42. I modified the .htaccess to allow a single IP and I still keep getting the 403 error.
        I have cloud flare on my site. Do I need to do something extra with Cloudflare?
        Why do I keep getting the 403 error? The tech support keeps messing with my .htaccess file with not much result.

    43. Hello HistoryasPrologue, and sorry for the delayed response.

        While I can relate to your Vietnam quote, the scenario in this conflict is a bit different. We are only blocking access to the WordPress admin dashboard (officer’s quarter), so we aren’t wiping out the whole site (village), we are just implementing a safe-guard (perimeter security) to ensure that your WordPress credentials are not hacked and then used in further attacks.

        Our senior system administration team had chosen to go this particular route of protecting all of our customers at once, and then I wrote up the instructions in this article so that you can setup your own protection for your site to help ensure that our internal blocks aren’t triggered blocking your own access.

        I don’t see that any of the recommended .htaccess rules have been implemented yet for your website. So I went ahead and used the rules from the lock down WordPress admin login with .htaccess and allow a single IP article which should cause all WordPress login attempts to get a 403 access denied error.

        This will make it so our internal rules do not take place. Then all you need to do is go in and edit this line of your .htaccess file, to only allow your IP address access:

        #RewriteCond %{REMOTE_ADDR} !^123.123.123.123$

        Then just remove the # symbol at the beginning of the line to turn that comment off, and replace the fictional 123.123.123.123 IP address with your own. You can figure out your IP address by using our IP check tool.

        Please let us know if you continue to have issues with this going forward. Sorry again for our delayed response and the inconveniences from these brute force attacks.

        – Jacob

    44. I refer to the now infamous statement by a U.S. military officer explaining to a reporter why his men had just burned down a South Vietnamese village. “We had to destroy the village in order to save it.”

        As other ISPs also concerned with safety issues have effectively employed means to protect security without needlessly interrupting login access, why does Inmotion hosting continue with this annoyingly needless “security” measure?

    45. Hello Askthedogguy,

        Apologies for the frustration and confusion in regards to this issue. It is definitely confusing and difficult to understand so some of the technical support reps may not be aware of the exact reasons why using the .htaccess rules would be preferable over using a security plugin within WordPress. Also, I’ll cover how the brute force attack is affecting resources and why the attack shouldn’t be the MAIN reason for upgrading to a VPS or dedicated server. I’ll break it down per your questions:

        Upgrading to a larger server for more resources. Won’t it just provide the attackers with more resources to eat up somewhat delaying my being shut down again?

        If you were using the .htaccess rules, the resource usage by the attacks would be minimal. The main reason for going to a larger server would be the resource usage of your websites. Do you have a lot of traffic? Are you using caching on your WordPress sites? Going to a larger server is NOT meant to be a way to reduce the brute force login attack.

        I would also like some clarification regarding the problem overall. Is this actually brute force attacks solely that are WordPress specific or are they attacks that are WordPress specific that are hosted by larger hosting companies like Inmotion? In other words am I safer going to a lower profile company?

        Good questions. In some cases, some hosting companies have taken action, but they’re not being transparent with their efforts in order to hide their methods of securing their security actions. You can easily use your favorite search engine and search for “WordPress brute force attacks” and you’ll find lots of information on it, including our own article which ranks high because of the success and authority we have in identifying and reducing the attacks with the information that we have provided.

        The attacks are WordPress specific, meaning that large botnets are basically looking for WordPress sites no matter what host you’re on. It’s possible that the botnets wouldn’t target the smaller hosts, but there’s no guarantee. The attack is specifically targeting the wp-login.php page typically using a direct post request.

        Let me clarify one thing on the brute force attack that the .htaccess rule addresses. If you are using a plugin/PHP solution, then for every attempt that hits your server, there will need to be a thread running code to identify and block the attempted login. It’s basically always hitting the wp-login.php page meaning the PHP script runs. This means that cpu and memory resources are used. It’s not much for a few hits, but when it’s hundreds or thousands, then cpu usage and memory usage will skyrocket. Take a look at your cPanel Resource graph. It shows that your hosting account is consistently going over the 100% cpu usage mark. Either this is caused by traffic, or possible brute force attacks hitting your login page.

        As per item #4 in the article above:

        Blocking this attack with .htaccess rules is the preferred method, as login limiting plugins can not only lead to issue with triggering our own internal security rules, but they also will not be effective in this type of large scale attack.

        Currently, you do not use the .htaccess rules on any of your WordPress sites – I checked your account and it doesn’t appear that you have any of the rules on your websites. Try implementing the.htaccess rules to stop possible brute-force attacks, it can only help with possible resource usage issues. Also, if you are using multiple WordPress sites, use caching to help with performance. Both of these steps should help bring down your resource usage. However, if you are getting a lot of traffic, caching would only impact the issue a little. You would simply need to move to a server with more resources to handle the traffic hitting your website. I would recommend that you implement the .htaccess rule and caching first, then check and see your website usage. This way, you can determine if an upgrade is actually necessary.

        I hope this helps to clarify the issue. If you have any further questions or need further assistance, please let us know.

        Regards,
        Arnel C.

    46. Hello Proffer.ca,

        Sorry for the problems that you’re having with the WordPress logins. Unfortunately, the fact that your website is shutting is an indication that it’s being hit by the brute force attack. I took a look at your .htaccess file and it indicates that you’re using a plugin (All-in-one-WP-Security). It does not appear you’re using our preferred method of locking down access to your WordPress admin.

        If you go to the tutorial in the link above, it shows almost EXACTLY what you need to lock down your web site using only the .htaccess rules. You would need remove the current security plugin before trying to use the .htaccess rule.

        I could not modify anything in htaccess file because you still have the security plugin running. You will need to disable the plug.

        Let us know if you require any further assistance!
        Regards,
        Arnel C.

    47. My website seems to be shutting down without any traffic besides my self. Is there a way to over ride this security measure. If there is .htaaccess override, could you please edit my .htaccess accordingly.

        Thanks

    48. Thanks for the information. My site has been shut down 3 times in the last 10 days by Inmotion due to brute force login attacks due to resultant resource usage breeches. (All unsuccessful I might add as I had seemingly already implemented sufficient protection.) A recent email from Inmotion stated, “Upon investigation, this was being caused by a brute force attack against your WordPress administrative login page.” While some of the suggestions in the article above were made during these episodes the article itself was not mentioned and now having read it I will work on the others as well now.

        However, here is my frustration/problem/question. These strategies may protect against a successful hack but they do not impact the resource usages which was the reason I given each time I was shut down. The most recent solution I was given included upgrading to a more expensive platform with more resources. My site, which is small time and according to Inmotion – outside of these attacks – is normally fine as far as the resource usage – would simply lose money each month rather then make a few dollars. Either way I don’t understand how upgrading does anything to solve the real problem. Won’t it just provide the attackers with more resources to eat up somewhat delaying my being shut down again?

        Some additional suggestions were made by Inmotion today when they once again took my site down but they told me that – bottom line I’m responsible for the resources used on my account no matter what. I understand that these attacks must be as frustrating for Inmotion as they are for those of us on this part of the receiving end of the attacks and I appreciate the efforts they are making but when things are serious enough that a “fleet wide security policy to help contain these attacks” is in progress and it’s severity is such that; “removing any public information detailing the new way we’re blocking these attacks” is a further requirement I think penalizing customers/victims by repeatedly shutting their sites down is ethically if not legally on shaky ground.

        I would also like some clarification regarding the problem overall. Is this actually brute force attacks solely that are WordPress specific or are they attacks that are WordPress specific that are hosted by larger hosting companies like Inmotion? In other words am I safer going to a lower profile company?

        I very much like everything about Inmotion particularly the technical support but the way this has been handled has me reluctantly considering other options.

    49. Thanks for the info ejelly!

    50. Hi,
        The best security measure I’ve seen so far in terms of protecting against brute force attacks for WP sites is the following plugin:
        https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/
        It has a “Brute Force Prevention” feature which uses .htacess rules combined with a special cookie. When you enable the feature, the plugin will block all access attempts to your admin area except for those who have the specific cookie in their browser, OR, it allows those who know the special URL which you can set by choosing a secret word in the settings page.
        (You will be assigned a special login url by the plugin when you saver the feature’s settings).

        Before installing this plugin I noticed that the brute force attacks on my site were reaching epic proportions so-much-so that inmotion had to temporarily make my site unavailable on a number of occassions.
        However after installing the above plugin I’ve had zero brute force issues because they are all being blocked at the .htaccess level.

    51. Hello grumpygit,

        Awesome, glad to hear that’s working for you now! Please let us know if you run into any further issues at all!

        – Jacob

    52. Hello grumpygit, I apologize for the continued issues.

        Because you’re already on a VPS, I’ve gone ahead and followed the instructions from my find and disable specific ModSecurity rules article for you. This will prevent our automated blocks from continuing to happen on that website for you.

        Please let us know if you are still having any issues at all!

        – Jacob

    53. Thanks Jacob.
        All seems fine now.
        I can implement the other security measures suggested now.
        Regards
        grumpygit

    54. Hi.
        I have added the .htaccess rule and waited the recommended time but I’m still blocked from login.
        Any suggestions?
        grumpygit.net

    55. Hello jkwalz108 and thanks for the suggestion!

        It looks like the WordPress Move Login plugin only deals with wp-login.php, and doesn’t do anything about the /wp-admin folder.

        So it is essentially attempting to just hide your login form from bots. While this might be fine in some cases, it’s still highly recommended to restrict WordPress admin access via .htaccess rules to limit only requests coming from your domain name, or from certain IP addresses. Or by adding a second WordPress admin password via .htaccess.

        It looks like 4 of your websites were under attack today, ranging from 101 attempts on one to 847 on another. So it is possible our ModSecurity rules came into play as that was happening on previous days as well.

        Because you are on a VPS already, if you’d like we can find and disable specific ModSecurity rules for you on any of your domains, to disable our automated blocks. You’ll just want to let us know which sites you’d like to no longer be protected by this automated protection, and you’ll also want to ensure that you’ve followed some of the recommendations in this article such as choosing a strong password and .htaccess protection first.

        You can simply send this information to us at [email protected] and we’d be glad to look into disabling it for you.

        – Jacob

    56. Would something like this be a simple solution:

        https://wordpress.org/plugins/sf-move-login/

        It will move your admin login url.

    57. Hello Jkwalz108,

        The security that’s put into place will trigger based on attempts to access the WordPress login page, so in general, if you’re getting notice of a possible attack, then it’s very possible. It’s always possible that there may be a false positive because someone’s just trying to get in and a password has been forgotten, but it’s better to err on the side of caution. Especially in light of all of the brute force attacks on WordPress logins. It’s not just been our hosting service hit – they attacked multiple hosting services all around the country (if not the world). So please bear with the security changes, and apply the appropriate security measures per your needs.

        Regards,
        Arnel C.

    58. I find it really hard to believe that my test environment only wp-admin login, that isn’t even at top level of the domain, is under attack. No one even knows it exists other than WooThemes tech support. I went ahead and changed the admin password to a godawful random mass of characters that only Steven Hawking can remember. Are you sure my domain is “under attack”???

    59. Like RichardStep, I am coming in via DHCP through a mobile hotspot at home. Trying to even discover host names and other information for the .htaccess fix has been a nightmare.

        What about the two factor authentication that some WordPress plug-ins provide? Would this be a work-around to the problem?

        I know that DOS and other brute force attacks are a problem and have been for a long time. HOWEVER, I am paying you to help provide security for my WP site and not being able to access my site is just not an option. What can you be doing ON YOUR END to help make the WordPress sites you are hosting more secure?

        I am going away now to back up my site that I still cannot access…

        Thanks.

    60. Hello Nickgrinlinton,

        Sorry for the trouble logging into your WordPress site. It appears that you are getting hit by the Brute Force attack – records indicate different IP addresses hitting your account. Jacob (the author of this article) reviewed the issue and suggested that you try editing your .htaccess file and using the IP address method to allow your IP address to login to the WordPress admin. Once you have changed the rule, make sure that you have cleared your browser cache.

        I hope this helps with your WordPress login issue, please let us know if you require further assistance.

        Regards,
        Arnel C.

    61. Hi,
        I’ve been experiencing this problem for some time now. I thought I did the .htaccess and everything correctly and it worked for awhile, but I tried to login today and I couldn’t get access. Can somebody check and fix this for me so this doesn’t consistently happen? Let me know if you need anything from me.

        Best,
        Nick

        Best,
        Nick Grinlinton

    62. Hello Michaela, sorry to hear you’re having issues with your WordPress admin login.

        Unfortunately I was unable to find an account with us using the email address you’ve provided. If you’re getting re-directed to this page from our security rules, then you’d want to lock down your WordPress admin login with .htaccess rules.

        If you follow those steps, it should stop our security rules from blocking your request attempts, while at the same time locking out the bad attackers.

        If you’re still having any issues at all please let us know, if you can mention the domain name you’re having issues accessing I can go ahead and take a closer look for you.

        – Jacob

    63. I have been locked out of my admin panel since last night. How can I regain access?
        -Michaela

    64. Hello Richard, and thanks for taking the time to share your comment with us.

        To answer your first question regarding a less intrusive experience for the users, in most cases our rules are not blocking legitimate traffic, and in the fringe cases where they are blocking legitimate use, we do have the ability to disable the rules for specific accounts or domains. Definitely sorry that it sounds like you’ve been getting impacted by these blocks.

        It sounds to me like you possibly have a WordPress login plugin of some sort installed that might be causing your login attempts to be duplicated, and causing our ModSecurity rules to trigger. Being that you’ve now got the .htaccess rules to block WordPress brute force attack attempts in place, and you’re on a more isolated VPS platform now, we can go ahead and disable specific ModSecurity rules for you.

        The ability to disable ModSecurity via the cPanel Modsec Manager is only on shared, and this is due to the additonal SSH access you have on a VPS. It’s not ideal to completely disable ModSecurity, and the plugin is meant as a quick way to disable it while testing things out on shared.

        I’ve gone ahead and completed this for you, following the instructions from my guide on how to find and disable specific ModSecurity rules.

        This should help ensure as you’ve mentioned in your second question, that your new paying members are not getting unintentionally blocked out from any of your WordPress sections. If you are still noticing any issues at all, please be sure to update us and let us know, but hopefully what I’ve done today will help resolve these problems for you!

        – Jacob

    65. Thank you for putting this page together. I have 2 main questions / concerns.

        Question #1:
        Do you expect to have a less-user restrictive plan of action? Like within the next month?

        I’m on dynamic IP’s that change every day (home-connection and mobile hotspot). I’ve implemented both the referrer and IP specific .htaccess rules. I am still constantly blocked for at least the first 10-20 minutes of trying to do anything on any given day. I eventually get in, but with much frustration.

        My frustration levels are growing (especially when I just need to make a “real quick change”…. and this only started happening when I paid 10x as much money to move to a VPS… which makes no sense to me at all. Also, I am not able to easily implement the mod-sec change rules in my cpanel because (for some reason) the VPS account does NOT have that functionality while the shared account does. Again, confused at this decision.

        Question # 2:
        I am planning to launch a membership portion of my site within a few weeks. How best can I ensure that paying members will not have to deal with my daily headaches as THEY try to login to their wordpress account on my site?

        I am attempting to make pivotal business decisions and am very interested in your responses.

        Thank you for your help and time,
        Richard

    66. Hello again CrushTheStreet,

        I apologize, it looks like you have a VPS with us that is using custom name servers and that is why I didn’t see your site being hosted with us at first.

        After you lock down the WordPress admin login with .htaccess by restricting it to only allowing your IP address. You need to wait 15 minutes for any previous block to expire before attempting to login to WordPress again.

        Taking a look at your server logs, it would appear that the last block happened about 3 hours ago, so you should be able to access it again now.

        If you continue to have issues with this please let us know!

        – Jacob

    67. Hello again CrushTheSteet,

        Ok great to hear that it is in fact working for you now. I’m not exactly sure what might have caused it to continue blocking you previously. If it does begin to give you issues again, definitely let us know!

        – Jacob

    68. well something changed to where I can finally login. I haven’t changed anything since after last login attempts. After any last changes I’ve made I waited 20 minutes before trying and it still gave me error until this time trying

    69. Hello again CrushTheStreet,

        I’m not seeing any further blocked login attempts since my last comment. Are you still actively having issues logging into WordPress, or are you just stating that prior to my comment you were still getting blocked after waiting 15 minutes?

        The blocking should have nothing to do with your admin username/password, other than of course if you provide an incorrect login multiple times in a short duration of time.

        – Jacob

    70. But it still gave me the login disabled error after I entered username/password
        Admin username is not admin and my password is quite difficult

    71. I did do the waiting and the IP address block worked (changed the text to wrong IP and it blocked me, changed to mine and it allowed me to view page)

    72. On my domain futuremoneytrends.com cpanel

    73. Hello CrushTheStreet, and thanks for the update.

        If you’re logging into cPanel and seeing our branded version, is this on a different domain name then the one you had posted here?

        Or are you talking about when you attempt to login to your WordPress admin page, you’re getting blocked and seeing a message from us? I’m not sure why that would be the case, unless web.com is using our blocking rules as well for some reason.

        – Jacob

    74. Unfortunately we are using the dreaded web.com who when I submitted two tickets regarding this matter obviously can’t understand what the $&# I’m talking about. WHen I do login the cpanel though it says ‘inmotion hosting’ on the top for some reason

    75. Hello CrushTheStreet,

        The ModSecurity rules that we put in place on our servers shouldn’t be still getting triggered if you’ve implemented the .htaccess rules to restrict access to WordPress admin.

        From what I can see, it looks like the domain name linked to the email account you submitted this comment under, as well as the other domain you mentioned in your comment, are not hosted with us. Many other hosting providers are also employing automated blockings for these WordPress brute force attacks, so it’s possible that they might have the rules set up slightly different where our .htaccess rules are not able to stop you from being locked out.

        If you are in fact still having this problem on an account that you have hosted with us, please let us know!

        – Jacob

    76. Hello andyks,

        Yes, the .htaccess file should already be in the root of your wordpress install. If it is not you can just create one.

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

        -John-Paul

    77. Hello CrushTheStreet,

        Thank you for your question. This is due to a protection measure that was rolled out. You must add your specific IP address to your .htaccess file, in order to access the WordPress login page.

        Here is a link to a full guide on locking down Wordpres with an .htaccess, you only need to add your IP address to the existing rules.

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

        -John-Paul

    78. I got it to restrict only to my IP address now but it still blocked the login after I tried
        this is for futuremoneytrends.com/blog

    79. I have done that; I have it in another directory, do I need the .htaccess file in the main directory or my subdirectory where the blog is at?

        I don’t think the ip address thing is working. I waited the 20 minutes after editing and followed the other directions there and it’s still disabling the login

    80. Any way I install wordpress (from built-in server install or stanadlone 3.5.1) with whatever username/pass it locks me out of logging in with the same message!

        WordPress Login Temporarily Disabled

        We apologize for the inconvenience!

    81. Hello warmwhisky, and sorry for the problems you’ve been experiencing.

        I did not see that you had implemented any .htaccess rules to help block the malicious login requests that were happening. So those more than likely continued to trip our security rules, which in turn might have blocked access for yourself.

        I went ahead and followed the steps in our guide on how to lock down WordPress admin login with .htaccess for each of your WordPress websites to hopefully help prevent this from happening to you again.

        As mentioned with many of the other VPS users that have commented on this post, if you continue to experience issues with our internal security rules, you could follow the steps in our guide on how to find and disable specific ModSecurity rules to de-activate our specific ModSecurity rules. However this would be recommended as a last resort for overall site security.

        If you do continue to have issues, please start a live chat with our support team so that we can look at allowing you access again if our security rules do start to block your own access again.

        – Jacob

    82. This is becoming ridiculous now. I had access last week after changing username, password and locking the wp-admin folder with htaccess. Now I try today and I am back to square one with out a clue what more I can do. These directories are mine and I want access to them.

    83. Hello andyks, yes unfortunately we do still see some signs of this WordPress attack trying to break into customer’s websites.

        The blocks that we’ve put in place we able to protect thousands of customers from the possibility of their WordPress websites being compromised, and only a very small handful of customers have had issues with their own access being blocked by the security rules we implemented.

        I agree that everyone is responsible for their own site’s security. However being on a shared server with other users, if one user didn’t secure themselves and was getting attacked, the sheer amount of requests would affect the performance of the other websites on the server, and the same could be true for a VPS. So it was in everyone’s best interest that these attacks were handled on a server-wide basis, instead of a much less efficient site-by-site basis.

        All that is needed to avoid these blocks, is simply follow the instructions on our guide on limit WordPress login by referer via .htaccess, so that your WordPress website is locked down from the brute force attack. Then so long as you don’t have a WordPress plugin that is causing excessive requests to the wp-login.php script, our mod_security rules should not be getting triggered.

        I’ve gone ahead and implemented these .htaccess rules for you, as well as deactivated our specific mod_security rules on your WordPress websites. If you still continue to have any problems at all, please let us know.

        – Jacob

    84. Hello MrDesjardins, sorry for the continued troubles you’re experiencing.

        I went ahead and followed the steps in my guide on how to find and disable specific mod_security rules for your server, and disabled the WordPress lock-down rules that we had rolled out for your websites.

        Our security rules shouldn’t have been getting triggered with the .htaccess rules for locking down the /wp-admin directory, so I apologize if that kept happening to you. It’s possible that you might have a WordPress plugin that was causing additional requests that triggered the mod_security rules.

        I apologize again for the problems you’ve been having, and if you’re still running into any problems at all, please let us know.

        – Jacob

    85. This thing is still going on?? Man, is this block ever going to be lifted?? Its pretty fcked now its been weeks and I have not worked on my websites because all of them are based on WordPress and this block is a nothing but a PAIN IN THE ASS! Just lift this block people, everyone is responsible for their own blog and if people are keeping username/password combinations that can be easily cracked, then be it. Let them suffer. My passwords are generally extremely hard to crack because I use 16+ digits with numbers, letters, special signs and all that. Now are we going to get a break from this hacking attack hoopla? This is INSANE with all due respect. PLEASE allow me to work on my websites now! Thanks.

    86. We are the 29th April 2013, I have contacted twice InMotionHosting and they cannot find a way to log me in on my own website. When are you gonna let us having our websites available? Securing by blocking everybody, even the owner is not a security option… it would be better to tell us to just close our account with you (InMotion) or stop doing web business… come on.

    87. Hello again Phil,

        At this point I’d recommend handling further questions about this issue via a support ticket so that we can better help you out directly if you are having problems with new subdomain installations of WordPress. I’ll leave a note on your account to contact me if there are any further issues.

        As mentioned in my previous comment, if you setup a new WordPress subdomain and implement .htaccess password protection, and referer protection correctly, then you shouldn’t end up with the mod_security block, and if you are, we can disable it for you.

        If you’re only getting a “Denied” message when trying to login, then that means you’ve triggered either a 401 or 403 error which you’ve set ErrorDocuments for with only that word. I would assume that means the username / password you entered in was incorrect.

        As I also explained in my previous comment, you want to be sure that you’re following the steps for setting up .htaccess password protection exactly. As again this time I found you had this in your /word23/.htaccess file:

        AuthUserFile “/home/example/.htpasswds/public_html/word23/passwd”

        You need to be sure you’re using the same password file you protected your /wp-admin directory with:

        AuthUserFile “/home/example/.htpasswds/public_html/word23/wp-admin/passwd“

        Also, when you were blocking by referer, you had used word32.example.com instead of your actual domain name. I went ahead and corrected both of these things for you, and was able to verify I could get logged into the WordPress admin without any problems.

        – Jacob

    88. Hello PhilipLCP,

        I apologize, as I had intended to comment about your domain: https://word23.lowcosttest.com. I have the issue escalated to be reviewed by T2c tech. If I do not have an immediate response to your question, I will make sure to have the issue reviewed by Jacob tomorrow (as he is familiar with your server setup). Apologies again for the delay on getting you an answer and for the frustration with the logins.

        If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

        Regards,

        Arnel C.
        Community Support

    89. Hello PhilipLCP,

        You can actually turn off mod_sec yourself. Instructions on how to do this are here. However, we do not recommend this as you would be opening yourself up to possible attack.

        Is there a time frame when this whole wordpress issue will be resolved?

        I wish it were a simple WordPress issue that could simply be fixed immediately. Unfortunately, the individuals responsible for this issue do not have a timeline or intent to stop their malicious activities. We do the best we can to implement the best solutions possible that can be both effective for the issue and provide a secure solution for all of our customers. However, these attacks do continue to evolve. Our efforts to stop these events rely on you, the WordPress developement community, our government, and our own security efforts to provide a safe and secure hosting environment for your website. We appreciate your patience, understanding, and vigilance.

        If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

        Regards,

        Arnel C.
        Community Support

    90. Hi Jacob,

        ok it works and for future word25, word26, etc. I would have to contact Support to have the mod_security turned off?

        word24 mod security is turned on I assume.

        But with word23
        if I go to here:
        https://word23.lowcosttest.com/wp-login.php

        I login to the password protected directory. I then get to the wordpress login page. I get denied after I attempt to log in. That’s all the screen says – Denied

        Is there a time frame when this whole wordpress issue will be resolved?

        I know this is not Inmotions fault but it is effecting my business at this point.

        Thanks again,

        Phil

    91. Hello Phil, and sorry for the delayed response, as also mentioned in your support ticket reply from a few days ago we can disable our mod_security rules for you after you have .htaccess rules in place if you continue to have issues.

        The reason that you were getting multiple password prompts before being able to login directly to WordPress, was that you had set up separate .htaccess password protection for each directories.

        If you were following the steps in my guide on how to prevent unauthorized wp-admin and wp-login.php attempts, you might have noticed I instructed you needed to create password protection on the /wp-admin directory first, and then in your WordPress site’s root directory, creating a different .htaccess rule to just password protect wp-login.php.

        What you ended up with was this rule in your /wp-admin/.htaccess file:

        AuthUserFile “/home/example/.htpasswds/public_html/wp-admin/passwd”

        This is what was just in your /.htaccess file:

        AuthUserFile “/home/example/.htpasswds/public_html/passwd”

        You should notice how the 2nd one isn’t pointed to the same password file, hence you get prompted for a username/password twice.

        Going forward if you decide to create another subdomain for another WordPress site, if you create password protection on the /wp-admin directory, and then in the site’s main root place the .htaccess rules to limit requests by referer and password protect the wp-login.php script, that should prevent you from continuing to have issues with our security rules blocking your requests.

        In summary you’d end up with this for /wp-admin/.htaccess:

        ErrorDocument 401 “Denied”
        ErrorDocument 403 “Denied”
        <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteCond %{REQUEST_METHOD} POST
        RewriteCond %{HTTP_REFERER} !^https://(.*)?word24.example.com [NC]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-login.php(.*)$ [OR]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-admin$
        RewriteRule ^(.*)$ – [R=403,L]
        </IfModule>
        AuthName “Secure Area”
        AuthUserFile “/home/userna5/.htpasswds/public_html/word24/wp-admin/passwd”
        AuthType Basic
        require valid-user

        This would be in your main /public_html/word24/.htaccess:

        ErrorDocument 401 “Denied”
        ErrorDocument 403 “Denied”
        <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteCond %{REQUEST_METHOD} POST
        RewriteCond %{HTTP_REFERER} !^https://(.*)?word24.example.com [NC]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-login.php(.*)$ [OR]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-admin$
        RewriteRule ^(.*)$ – [R=403,L]
        </IfModule>

        <FilesMatch “wp-login.php”>
        AuthType Basic
        AuthName “Secure Area”
        AuthUserFile “/home/userna5/.htpasswds/public_html/word24/wp-admin/passwd”
        require valid-user
        </FilesMatch>

        If you’re still having any issues at all, please let us know.

        – Jacob

    92. So I managed to duplicate what was done with word21, word22 into word23

        I have password protected the whole subdomains that use wordpress except for word21, word22,word23,word24 and took off the total password protect of lowcosttest.com in the root.

        I password protected the wp-admin folder like was suggested on your site for 21, 22,23,24.

        I added the following code to the .htaccess in the word24 wp-admin folder

        ErrorDocument 401 “Denied”
        ErrorDocument 403 “Denied”
        
        RewriteEngine on
        RewriteCond %{REQUEST_METHOD} POST
        RewriteCond %{HTTP_REFERER} !^https://(.*)?word24.lowcosttest\.com [NC]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-login\.php(.*)$ [OR]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-admin$
        RewriteRule ^(.*)$ – [R=403,L]
        
        BEGIN WordPress
        AuthName “lowcostpanel”
        AuthUserFile “/home/lowcostt/.htpasswds/public_html/word24/wp-admin/passwd”
        AuthType Basic
        require valid-user

        What happens is when I go to word24.lowcosttest.com/wp-login.php is:

        1) I get a pop up to enter in my username and password for that protected directory
        2) I then get to the wordpress login page
        3) I enter the u/n and p/w to get into the wordpress dashboard.
        4) I get denied as too many attempts logging in.

        I remember reading about the redirect loop thing when logging in so I thought this code took care of that.
        ErrorDocument 401 “Denied”
        ErrorDocument 403 “Denied”

        Like I said I design the site in a subdomain and change the functionality of wordpress to suite the customer needs. Once done I transfer the site to the customers real domain.

        word24 is a potential big client that could suddenly be on the go at anytime and when I demonstrate the site or try to do anything I can’t

        what happens if tonight or Monday or whenever I get a call for another client and thus I start word25?

        Thanks again for your time.

        Phil

    93. Hi Jacob,

        Thank you for your response and help 🙂

        I can get into the dashboard of wordpress now but it seems like quite a task to only for word23.

        As of yesterday I password protected the entire domain, in the root – the www, public_html, so everything in it including subdomains requires and user name and password.

        when I go to word23.lowcost…/wp-login.php these are the steps I have to do to get into the dashboard.

        1) I have to login with the u/n and p/w for the password protected directory

        2) I then log in with what looks like the same form as the password protected directory form using the wordpress u/n and p/w

        3) Then I get to the wordpress login page and have to enter the u/n and p/w for the wordpress credentials

        4) then the final step is I am prompted from the password protected directory form for my u/n and p/w not for the wordpress but for my password protected directory.

        Now I’m in the dashboard and it works. That is a lot of steps.

        with word22 the login to the dashboard is as exected. I login to the password protected directory then I get to the wordpress login page and login from there.

        I duplicated the .htaccs file in word23 from word22 just changing a variable to match but that hasn’t changed the big login procedure for word23.

        What can I do to get the word23 login as seamless as the word22? Since word23 is being heavily worked on by the client with the adding of content.

        Thanks again,

        Phil

    94. Hey Phil, sorry for the problems you’ve been having on your VPS with our blocks and my delayed response.

        It looks like you were encountering a similar issue that one of our other customers pointed out about the define an ErrorDocument. It looks like you also had some unnecessary duplicate rules in your /wp-admin/.htaccess file that I’ve commented out for you.

        Along with that it also looks like your website was throwing multiple requests to wp-login.php with just one login attempt. So I’ve disabled our mod_security rules triggering the specific block since you’re site should now be protected via .htaccess for this attack. I did the same for your word21, and word22, sites as well as I saw them triggering the blocks as well.

        Hopefully that should resolve all the issues you were having. Please let us know if you continue to experience any problems at all.

        – Jacob

    95. Hi again dbuxton, sorry for the problems.

        I went ahead and disabled our mod_security rules for the hh.com domain. If you’re still getting 403 errors on the other sites, make sure that your current local IP address is actually added to their .htaccess files.

        Please let us know if you keep having issues.

        – Jacob

    96. This is Phil again,

        sorry about all those duplicate posts. I kept on getting an error when I tried to post my question so I hit refresh.

        An update.

        Password protecting the entire domain, in the root – the www, public_html, so everything in it including subdomains requires and user name and password.

        That didn’t work either. I still can’t log in. I can once and only once.

        My entire domain is password protected so how can there be 5 attempts at a /wp-login in 30 seconds?

        Phil

    97. Jacob,

        I hate to respond here as yesterday I was told not to, but since you were kind enough to check on things again I wanted to acknowledge your response. I have gone ahead and again responded to the ticket email that I received to let them know that I at least am now getting 403 access denied errors for jl.com and thetp.com (please see ticket for full domains). However, the hh.com is still giving me the brute force attack.

        No need to respond but just acknowledging your response.

        Day 7 of no ability to access wordpress installs on 2 separate VPS servers at IMH and as Phil says above I now have clients getting irritated with me that I have been able to get a resolution. 🙁

    98. Hello,

        I know this isn’t Inmotion’s fault but I do have clients that are getting on my case.

        I have a VPS and on one my my domains I creat subdomains where I put wordpress sites. word1.domain.com etc.

        The clients tell me what they want in terms of looks and functionality of their wordpress site. Once that is completed to their satisfaction I then transfer over the trial wordpress site from my domain to their domain,

        I am actively working on 4 sites right now and I can’t do the work because of this problem.

        I have tried that
        RewriteEngine on
        RewriteCond %{REQUEST_METHOD} POST
        RewriteCond %{HTTP_REFERER} !^https://(.*)?word23.lowcosttest\.com [NC]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-login\.php(.*)$ [OR]
        RewriteCond %{REQUEST_URI} ^/(.*)?wp-admin$
        RewriteRule ^(.*)$ – [R=403,L]
        

        it didn’t work.

        I then thought maybe I would password protect the whole directory in my cpanel. the directory being the subdomain. That didn’t work either. I waited 20 mins to try to /wp-login.php and I was still denied access to that page.

        I am at a loss of what to do.

        Thanks,

        Phil

    99. Hey johnzeiger, sorry for the problems you’ve been having as well.

        Things should hopefully be fully resolved for you now with the newest set of mod_security rules that we had rolled out. Also you were having the same issue as both robtish and aldenes regarding the .htaccess referer error, so I deeply apologize for that. I had just copied and pasted all of the HTML code from this present article into that newer one, and for some reason our HTML editor decided to interrupt the code differently and miss a space.

        Please let us know if you’re still noticing any further problems

        – Jacob

    100. Hello aldenes, I apologize for problems and delay.

         It looks like you had the same issue that robtish had, please see my response about the .htaccess referer error for what happened.

         I’ve gone ahead and corrected that across all of your websites. Please let me know if you’re still experiencing issues with them.

         – Jacob

    101. Hello again HankStroll, sorry I didn’t catch all of those the first time through.

         I’ve gone ahead and ensured the .htaccess blocks are in place properly for the mentioned websites, and disabled our specific mod_security rules triggering the blocks.

         Please let us know if you had any further problems.

         – Jacob

    102. Hello robtish, I apologize for the delayed response,
         
         I took a look on your VPS associated with the email address you’re using on the account posting here, and I believe I found the issue. If you had copied the referer .htaccess rules that were laid out in my article on how to lock down WordPress admin login with .htaccess, it looks like there was possibly a problem with our editing software when extracting the rules from this article into that one, and I apologize for the oversight.

         The problem was with this line:

         RewriteCond %{HTTP_REFERER} !^https://(.*)?example.com[NC]

         It has been correctly updated to:

         RewriteCond %{HTTP_REFERER} !^https://(.*)?example.com [NC]

         Notice there should be a space present in between your domain name and the [NC] rule for not checking case sensitivity. I went ahead and applied the updated rules to your website, and it’s no longer 403’ing, because it is properly detecting the referer now.

         Please let us know if you continue to experience any issues.

         – Jacob

    103. Correction .. the above should read ‘three out of 8 sites’

    104. Jacob … thanks for making a dent in the websites we manage. Three of the 14 sites under the root directory are now working. Could you help us get the back end of these sites up and running also?
         Mc2talks.mc-2.com/wp-admin
         Blog.musicinsidermagazine.com/wp-admin
         Spergatory.com/wp-admin
         Womens-spirituality.com/wp-admin
         internetviz.com/b2bsmblog/wp-admin

    105. Hi again dbuxton, sorry about that didn’t see you had included your ticket # in your previous comment.

         I see that ticket was already responded to, and that the support tech was unable to replicate your issues. I tested it again, and I was seeing the block put in place again.

         I’ve gone ahead and ensured your sites are protected via the .htaccess rules for blocking access, and have disabled our specific mod_security rules that were triggering the blocks for those two domains on your VPS.

         If you continue to have any issues at all, please let us know.

         – Jacob

    106. Hey Jacob,

         Well I abbreviated the domain names (which is why I included my ticket #) so I am definitely hosted with you guys or I wouldn’t be still posting here. trying to get help. I can only hope that maybe on tomorrow (day 7) that things might get fixed, but really not counting on it honestly.

    107. Hello dbuxton, and sorry for the issues you’ve been having.

         We’ve rolled out new mod_security rules that should no longer cause problems for you. Please note though, the domains you’ve mentioned in your comment, currently do not appear to be hosted with us.

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

         – Jacob

    108. Hello HankStroll, sorry for the continued issues.

         As with MrDesjardins above, I’ve made sure you .htaccess rules were in place, then I disabled the specific mod_security rules of ours that were causing this block.

         If you’re still having any issues at all, please let us know.

         – Jacob

    109. Hello MrDesjardins , sorry for the troubles on your sites,

         We have been updating the mod_security rules, and most recently they’ve been updated to block access to any IPs that trigger our blocking conditions. So it sounds like from your work computer these blocks might have been triggered, but not at your house.

         I’ve gone ahead through your sites that were triggering these blocks and implemented blocking via referer in the .htaccess file. I then turned off the specific mod_security rules that were getting triggered for the WordPress logins. That way you still have mod_security protecting against other common attacks, but it will skip over the login blocking that we put in that is giving you some issues.

         Please let us know if you continue to have any issues at all.

         – Jacob

    110. Hi zygrinsites, apologize for the delayed response.

         I see that you had a support ticket in on this issue, and it appears to have been cleared up for you. If you’re still having problems please let us know.

         – Jacob

    111. Hello Pam, sorry for the delay in response.

         Glad to help, and I hope things are all still working correctly for you. If you’re still having any issues at all, let us know.

         – Jacob

    112. Hello Dbuxton,

         I can understand your frustration. This matter is currently in a technical support ticket. If you need to add more information, please respond to that email. You have several accounts, so the issue that you are facing is more complex than for a customer facing it with one account. We do try to hear issues out hear on the public support site. Your issue is being handled at the highest technical level by the live support team. They do NOT see your replies in this forum, so it would help us if you would please reply to the ticket in play and keep the added site issues limited to that avenue of communication. The problem you’re seeing is the SAME as what others are facing and it’s all related to the WP Brute Force changes security. We are not only working with from a systems standpoint, but they’re also working with the makers of Mod_sec in order to get a better working solution.

         Additionally, immediate responses to the Support Center will generally occur 8:00 am – 5:00 pm. After that, you may not see an immediate response to comments. Apologies again for the frustrations – I know it’s been quite some time. Respond to the ticket – I have noted your account that this issue should be receiving top priority to resolve. They have definitely been working on it, so please let us know if the problem persists so that live support can immediately respond.

         If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

         Regards,

         Arnel C.
         Community Support

    113. John Paul,

         Thanks, but as I have repeatedly have said we (both myself and IMH techs) have tried both ways of the htaccess rules to no avail. This is what is so frustrating.

         I am at this point willing to take the risk of having the security turned off for both of the vps servers, so I can get work done since I am now going on day 6 of neither myself or my clients being able to do anything on their websites.

    114. Hello dbuxton,

         Okay, I recommend giving them some time to replicate and investigate this issue. I would also make sure you have added your IP address to the .htaccess allow rule.

         This can also be caused by a plugin, that is attempting to connect to the login page. So you may want to try renaming the plugin folder.

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

         -John-Paul

    115. John-Paul,

         I responded to the system email that came when you posted. I just would prefer to not post my admin links here on this community forum. However, things still are not working for me — even after restarting and trying different browsers after caches cleared.

    116. Hello dbuxton,

         Thank you for your question. Sorry to hear you are having trouble. I tested your WordPress login pages referenced in the ticket and I am able to access them successfully.

         Please provide exact steps so I can replicate the issue, such as what is the specific URL you are getting the error on, and what is the exact error?

         Also, our support department closes any email ticket when we reply by default, when you reply, the ticket is automatically re-opened.

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

         -John-Paul

    117. Thanks. I am definitely going to check it out further as I manage several sites and would be great to just be able to go to one spot, plus if it worked while all these issues were going on with IMH maybe I would still have most of my hair and no hangovers. 😉

    118. dbuxton,

         sorry for the confusion…I have been able to access my dashboards with ManageWP all long…regardless of what changes were made by InMotion Hosting.

         What I meant to say is that I can now access my dashboards via a browser as well now that the mod_security rules were removed again

    119. Thanks John for the info on ManageWP. Are you saying that now you can’t access your dashboards even with ManageWP? Just trying to figure out if worth investigating more.

    120. Luckily I use ManageWP so, until mod_security rules were removed, I was able to access my admin dashboard and was able to create sub-users so my clients could too.

         https://managewp.com/?utm_source=A&utm_medium=Link&utm_campaign=A&utm_mrl=479

    121. Arnel (or whomever is monitoring this today),

         Again the problem has not been fixed. I just responded to the support ticket that it wasn’t fixed and to quit closing my ticket when there is definitely not a permanent solution you guys are putting in place.

         I can see by others that IMH recommended fixes are definitely not working for the vps servers. I am now going on day 6 of being unable to work on sites. It appears that turning off the mod_security rules above worked for John. I would like that to happen for both the vps servers on my ticket #1382839. I also have the Better WP Security plugin installed and Bootstrap. I think I would like to take a chance with them, so that I can get work done.

    122. After 18 hours, I finally received an update to my support ticket. They re-disabled the mod_security rules on my VPS. When I tested, only 1 of my sites was working. Fortunately, I was able to quickly determine that they had updated all of my .htaccess and inserted the following code at the bottom. I removed the code and now have access. Now the Better WP Security plugin can handle the attacks.

         # Begin InMotion Hosting solution for wp-login.php brute force attack
         
         RewriteEngine on
         RewriteCond %{REQUEST_METHOD} POST
         RewriteCond %{HTTP_REFERER} !^https://(.*)?acwi\.org[NC]
         RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
         RewriteRule ^(.*)$ – [F]
         

    123. Hello Alexd,

         This issue has been ongoing now for sometime, and we do apologize for the frustrations. The systems people have been striving to come up with a consistent and permanent solution. Currently, the best solution for the issue is to use one of the two solutions in this article (this is from a Systems person who spoke with us):

         Lock-down WordPress Admin logins

         He suggested that the Single IP and Multiple IP methods are the current best solutions in Step 8. I checked your main site and I was able to duplicate the 403 error. Currently, all WordPress login issues of this nature are being requested to escalate to our Systems team. As soon as I’m done with this reply, I will create a ticket for you and submit it to the Systems queue – they are addressing them as fast as they can. So you should see results soon. Apologies again for the issue and please reply to the ticket if the issue persists.

         If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

         Regards,

         Arnel C.
         Community Support

    124. I have a rule to allow only 1 IP address of my office. It worked for a little bit and then I’m locked out again. It is not the 403 error msg, it is your host customized locked message.

         Some of the websites but not all are:
         Fresnodentalstudio. Com
         Fresnodentalimplants. Com
         Hilltopfamilydental. Com
         Ravonknopfdds.com.
         Ca-broker.com
         UnitedAmericarealty. Com
         Familydentistryofwalnutcreek. Com
         AlexDenes. Com

         And many others less important.

         I understand that this is an unprecedented attack that required some unprecedented measures and I’m actually grateful to you for taking this step for preventing potential damage.

         What I’m asking is: what can I do on my own time to help bring my websites into compliance one by one? So far everything I’ve done for the past 2 days proved useless.

         Also I find frustrating the fact that I have to keep looking and get on the phone and online to keep looking for a solution. Could you perhaps update your paying customers via email? Let me know what needs to be done and I will be more than glad to do it myself. That’s if you know what needs to be done, otherwise it’s a waste of time for all of us. But I don’t think anybody knows what needs to be done at this point. We may just not want to admit it…

         Alex

    125. aldenes,

         I’m experiencing the same thing – it works for a while and then I’m blocked again…they removed blocking from my VPS and withing a couple of hours it was put back in place…I submitted a ticket 11 hours ago asking for the blocking to be removed and the ticket has not been answered…I tried Live Chat earlier and it wasn’t working so I called and the tech who I talked to didn’t have the ability to even confirm whether blocking had been reapplied

         Luckily I use ManageWP so I can access my admin dashboards but my clients are still locked out…I will need to setup ManageWP user accounts for them so they can log in

         P.S. I couldn’t log into this site with my AMP account (zygrinsites) to post this comment so I had to setup a new account that logs in via Facebook

    126. Hello Dbuxton,

         I just spoke with the systems person, and they were testing both of the sites that you listed, but they were both okay when I tried to get into them just now. Please review the login and let us know if the problem persists. I’m going to close the ticket (you’ll see a response) – please respond to the ticket if the problem is still occurring.

         If you have any further questions, please contact technical support or leave a comment at the bottom of the page. It will go straight to the systems team.

         Regards,

         Arnel C.
         Community Support

    127. I have at least 10 very important work related blogs hosted on a virtual private server. I followed the exact instructions on editing rules for the .htaccess file on each one of my websites. That made it work for less than an hour or so; then last night I called customer support and was told to take out the rule that I had just put in earlier in the day. Again, that made it work. I was advised to install recaptcha for additional security for login and I did that. I was able to test that all my modifications and additional recaptcha security measures were implemented and actually working on all of my websites at about 1 AM when I finished. This morning, again I have the same exact problem and cannot log in to any of my websites. I called customer support again and was told that the generic referral rules from the domain name that I had (and then took out) in the .htaccess were not permitted and that I should allow access only by IP addresses. As much as that would limit access from several places and other editors on the road because their IP constantly change, I did that. I was again able to login. But not for more than 30 min and then got the login denial again. While I praise very much your customer support, I don’t understand why I was guided and assured that the 3 different subsequent solutions will work, just to see otherwise. I need these websites for business but I also don’t want to spend days trying to fix it. If I secured my websites and then even installed recaptcha why is customer support not allowing me to access my websites?? I understand that it is a global, complicated and serious problem without a solution yet. But could we be allowed to go back online with the websites that we can prove are compliant with the new security measures?? Alex D

    128. Hello Dbuxton,

         I’m sorry for the continuing login issues. I re-opened your support center ticket and escalated to our Systems team for immediate review. You should see a response from them soon. Our apologies again for the ongoing WordPress login issues, we do appreciate your patience and are working to resolve this as soon as possible.

         If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

         Regards,

         Arnel C.
         Community Support

    129. Hey Arnel,

         I do appreciate the help. However, I just tried accessing both jl.com and thetp.com and I am getting your WordPress block warning. This is after clearing my browser cache, shutting it down, then going to a different 2 different computers, including 1 that has not even ever accessed the sites on the browser (hubby’s basically syncs with ipod laptop).

         So it sounds like it was again fixed momentarily, then locked down again. 🙁

    130. Hello HankStroll,

         Apologies for the problems with the WordPress site. We have our Systems Administrators reviewing these problems at this time (I was asked to escalate your issue to them when I looked at the problem). Therefore, I will be placing a ticket in queue for you and you will seeing an email sent to you in regards to the problem.

         If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

         Regards,

         Arnel C.
         Community Support

    131. Jacob .. I am stumped. After speaking with InMotionHosting 1st level support 4 timea, I still am not able to login to our wordpress sites. You usually excellent team also appears a bit stumped. Each one of the helpful techs has looked at my .htaccsess account(s) mutiple times, and made changes to my original fix I attempted by following your artilce, but to no available. Last night the tech had the block removed from my account, since he could not figure it out either. For a while I was able to get into the account(s) and update my passwords and make other changes that are listed in the artilces you wrote. However, today I am blocked again. Would you please point me the in right direction?

         We have been with InHosting for many years, because of your high level of tech support. I know that this attack is WAY out of the norm and has probably create a new paradigm for all wordpress users. So, I do understand how 1st level support can stumble. Any assitance from you would be greatly appreciated.

         No one has tried the referral method, yet. We have mulitple subscribers and others who have the role of admininstator, so we tried to use one of the other methods. I am not sure what syntax to use with the referral method. I also get differant answers from tech support when I ask it I need to change .htaccess file for each WP domain. Some say ‘yes’ .. others say ‘no’, since I have all under one cpanel and the main WP is in the root directory … I am many other questions, but don’t wish to take us down a non productive path. So, please check out my account and let me know what needs to be done.

         Thank you.

    132. How come I can login with my laptop but not with my tablet now?I can’t log from work but I can from home. What is the process to remove all that protection? It’s annoying and I people with dedicated host and VPS shouldn’t be annoyed by InMotionHosting WordPress “hack” to protect WordPress. WordPress should be enough with Apache Module to protect everything. Please contact me I am not satisfy by how everything is handled. My clients pay to be able to edit their content and InMotionHosting is not considering the whole situations by simply blocking every thing instead of deploying a real secure solution.

    133. Hi robtish, thanks for your comment, and sorry for the problems.

         I went ahead and resolved this for you by following the steps in my guide on how to find and disable specifc mod_security rules.

         I confirmed it should be working for you now. Please let us know if you still encounter any additional problems at all.

         – Jacob

    134. Hello pamella, I apologize for the cPanel issues you’ve been having.

         I was unfortunately able to replicate those, so hopefully that has cleared up for you, and you’re able to access cPanel once again.

         I also took a look at your email queue, and I was able to directly push out some messages without any issues. However for a few of your delivery attempts, the remote receiving server was simply refusing a mail connection from your VPS and therefore causing a time-out when attempting to send mail.

         Your VPS’s mailing IP address doesn’t appear to be currently in any public blacklists, so it could be that the mail administrators of the server’s you’re trying to delivery to, simply blocked your IP at their firewall for some reason.

         If you happen to have a Gmail account from Google, you could follow the steps in my guide on how to send mail via Gmail when server IP is blocked, and see if you’re able to get a message through that way. If you are, I’d suggest having the people you’re sending mail to inform their mail admins that they might be blocking your VPS’s IP address.

         Due to this recent huge brute force attack, I wouldn’t be surprised if some server admins blocked very large IP address ranges at their firewalls trying to mitigate the attacks, so hopefully if that is the case the blocks will be lifted shortly. In the meantime hopefully you can get your mail out to those specific addresses it’s failing for, delivered out via Gmail.

         Let us know if you continue to experience ongoing issues with that.

         – Jacob

    135. Hello MrDesjardins, and thanks for your comment.

         If you are just now today having problems accessing your WordPress website, than that means that possibly your site had not yet been targeted in the brute force attack, or you were getting attacked at a slower rate that was required to trigger the block.

         As mentioned earlier in the comments you can check out why action was necessary to protect our user base, for more information on why we had to act, and fast.

         With the scale of this attack normal protection methods weren’t enough, and we did have to ensure that our customer’s data was protected above all else.

         – Jacob

    136. Hey, JacobIMH!

         I’m still having issues. After the following was completed:

         1) I implemented the referrer method as described in
         https://www.inmotionhosting.com/support/news/general/wp-login-brute-force-attack

         2) InMotion installed mod_security

         3) InMotion restarted Apache

         Whenever I go to mysite.com/wp-admin and enter my username and password, I get your error page.

    137. Thanks for the quick response Jacob. Unfortunately now when I try to log on I get:
         Error 403 – Forbidden
         You don’t have permission to access the requested resource. Please contact the web site owner for further assistance.

    138. Thanks Jacob; I resolved the cpanel issue via live chat earlier; the email was unresolved until about 20 minutes ago. I am glad you were able to do something as no one else had a clue! best regards, pam

    139. Hello DavidMoore, and sorry for the troubles.

         I see from your account notes you were already able to contact support, and they removed the brute force protection we had put in place for you.

         If you’re still having any issues at all, please let us know.

         – Jacob

    140. Hello zygrinsites, and thanks for the comment and suggestions.

         I have actually given this article a complete overhaul, with more things you can do to help protect yourself. Also I’ve removed the mentions regarding exactly how our latest role out of security rules works, as we have been noticing the attackers seemingly change up their tactics.

         You shouldn’t have as much of an issue now with our latest security rules. However if you still are having extended problems getting back into your WordPress website, please be sure to let us know.

         – Jacob

    141. I’ve been locked out for days now. I’ve got the referrer script in my htaccess file in my public html directory. And now I also have it in my blog subdirectory.

         Still locked out. And I did wait for 90 minutes before trying to log in again.

         Can you just go in and fix it for me?

    142. My WordPress sites are working fine. My VPS / cpanel is not responding to anything. Email going out, but not coming in. Can’t login to cPanel

    143. Same thing happened to me, DavidMoore…the tech had to install mod_security which still didn’t resolve the issue until Apache was restarted

    144. I understand that the attacker get blocker for 15 minutes if this one hit too much the server but I really do not appreciate, neither my clients that you block the whole admin pages for every IP. I do not appreciate that you are doing this without any notice, or any email. It’s been few days that this new policy is in place and it’s only this morning that all my WordPress account are locked. Really not professional from InMotion.

         How come the mod_evasive is not enough to protect against this attack? It’s been ON on my server since few months and it at greatly work for DDOS attack. It should have been enough again multiple fast hit on the login page of wordpress.

    145. I’d recommend updating this article…it’s not failed attempts; rather it’s attempts…in other words, going to yoursite.com/wp-admin counts as an attempt before you even enter a username and password…plus, at least in my case, it’s 2 not 5 attempts…for example, if I go to mysite.com/wp-admin and refresh my browser, I get locked out

    146. Hello again inspire,

         I apologize for the lack of full transparency of the mod_security rules that were deployed, as the attackers significantly changed up their attack methods 3 times within the span of a few hours, we want to be careful about spelling out the exact specifics of how we’re currently blocking the attack, to avoid the possibility of them evolving their attack around the blocks.

         You can read another comment of mine regarding the need for action to protect WordPress users across all servers that hopefully illustrates a bit better the ultimate escalated security problem we were trying to prevent.

         The simple solution of throwing a WordPress security plugin at these issues I’ve seen unfortunately propagate through the Internet as a recommended solution, and it shouldn’t be touted as a great way to prevent this. These plugins typically require PHP script executions, and sometimes even have extra overhead from logging to a MySQL database.

         When this botnet has enough IP addresses to simply hit your site twice from one IP, and then the next second move on with two requests from another IP, it could simply hit you all day from primarily unique IP addresses. This would render an IP blocking WordPress plugin useless, while at the same time making your account use up un-needed CPU resources just to block a known malicious request. When you do the math of how many users run WordPress on a shared server, or even VP node, there simply wouldn’t be enough physical processing power for each site to independently keep up with the attack.

         Again I apologize for the issues and frustrations this issue has caused you, just please keep in mind how large scale this attack was, and why we had to start taking immediate actions to protect our overall customer base.

         – Jacob

    147. Hey satisfice, and Wicasta, sorry for the delay responding back to you both.

         Glad to be of what help I can, we definitely want our customers to know this issue is high priority for us and we’re hard at work ensuring everyone’s security and access to their sites.

         I was poking around in your server and discovered a few things, unfortunately I had some other tasks I had to get to prior to being able to relay those to you.

         It looks like you both came to the same conclusions that I did, the main problem that was getting logged in your Apache error_log was:

         RewriteRule: invalid HTTP response code for flag ‘R’

         Which was coming from the following rule:

         RewriteRule ^(.*)$ – [R=403,L]

         What is very odd, is this same rule is working on other servers, so I haven’t yet figured out why that is the case. But I was able to fix it using the same method you’ve mentioned. There shouldn’t be any issues using the [F] flag, as it returns a 403 error which denies access.

         However I then ran into another issue which as Wicasta had mentioned, the rules I gave out, did not have logic in them for a sub-directory WordPress installation. They’ve been updated in this article so thanks for pointing that out Wicasta! I’ll also post it here.

         If your WordPress site is installed in the sub-directory /blog, you’d edit the following .htaccess file:

         /home/userna5/public_html/blog/.htacess

         With this code, where I’ve highlighted in red the bit that allows for any sub-directory:

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

         Thank you both for hanging in there, and updating us with what you’ve found, our community of users is a great resource for us to have, and we really appreciate your help!

         As always, if any other questions or issues pop-up, let me know!

         – Jacob

    148. Woo hoo! I fixed it.

         The problem was that “R=403,L” part.

         I changed that line to:

         RewriteRule ^(.*)$ – [F]

         and now it’s happy.

         Jacob, is there any reason you can see that the “F” wouldn’t work?

    149. I’m interested in the follow-up to satisfice’s last comments, as well, since it didn’t work for me, either. The first thing I wonder is if the code should be changed to allow for sub-folders, if, for example, your WordPress installation is in its own sub-folder. ie;

         
         RewriteEngine on
         RewriteCond %{REQUEST_METHOD} POST
         RewriteCond %{HTTP_REFERER} !^https://(.*)?satisfice\.com [NC]
         RewriteCond %{REQUEST_URI} ^/WordPress/wp-login\.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^/WordPress/wp-admin$
         RewriteRule ^(.*)$ – [R=403,L]
         

         Or does that matter?

    150. Thank you for being so responsive. You are obviously concerned for your customers and it makes me feel great to be with Inmotion.

         However, putting the rule block at the top of .htaccess did not solve the problem. Can you look a little more closely at this example to spot what is wrong? I still get a 500 error wherever I add the referrer rule block. Example:

         
         RewriteEngine on
         RewriteCond %{REQUEST_METHOD} POST
         RewriteCond %{HTTP_REFERER} !^https://(.*)?satisfice\.com [NC]
         RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^/wp-admin$
         RewriteRule ^(.*)$ – [R=403,L]
         

         Options +Includes All -Indexes
         AddType text/html shtml
         AddHandler server-parsed shtml

         RewriteEngine on
         RewriteRule blog/feed/ blog/?feed=rss2

         
         RewriteEngine On
         RewriteBase /blog/
         RewriteCond %{REQUEST_FILENAME} !-f
         RewriteCond %{REQUEST_FILENAME} !-d
         RewriteRule . /blog/index.php [L]
         

    151. Hello inspire, and thanks for your comment,

         Could you please elaborate a bit on how you believe this issue hasn’t been properly explained, so that we know what to update? If you employed any of our .htaccess rules mentioned in this article, and then waited 15 minutes for the most recent block to expire, or went ahead and disabled mod_security temporarily, the block should have been avoided.

         I apologize if you had a fringe case where a WordPress plugin might have interfered and triggered a block due to attempting more than 5 requests in 30 seconds.

         Again I can not stress enough that these security rules that got rolled out were to prevent your sites from possibly being compromised. We’ve had a ton of traffic to this article and also looking through support tickets relating to this problem it doesn’t sound like the majority of customers were having the same issue as yourself, so I apologize for the frustrations they’ve caused you.

         I unfortunately can’t find any data to support it, but I think the difference between using <FilesMatch> or a RewriteCond is going to be extremely minimal, since in this case you’re using it for, it must still complete a regular expression lookup.

         Please let us know if you had any other questions.

         – Jacob

    152. Hello inspire, thanks for the comment.

         I definitely apologize for the inconvenience. Unfortunately due to the extreme large scale of this attack it was enough that if a few VPS containers were being attacked simultaneously, and they were just relying on WordPress security plugins powered by PHP scripts it could start to delay requests on the VP node as a whole affecting other users who are not using WordPress.

         The fact that you were locked out of your WordPress site is an indication that your website was targeted by this botnet, or you happened to have 5 failed login attempts within a 30 second window.

         It appears that you might have already resolved this issue yourself. If you are still having problems, I’d recommend you temporarily disable mod_security to regain access.

         Please let us know if you’re still having any further issues at all.

         – Jacob

    153. I’ve still no idea at all exactly what you’ve done in mod_security. You’ve told me you’ve done a thing and what you think it’s going to do. It’s not even close to the level of detail I need to diagnose why it conflicted with the module I had.( I do now, I’ve found the config fie)

         I suspect your mod_security patterns are giving a false positive because the wp-login page I have didn’t correspond to the vanilla one after I installed the modules. Only, of course, I’ve no way of knowing that because I’ve not seen exactly what you did. Initially, I wasted a lot of time assuming the plugin was broken when it actually worked perfectly fine and was being clobbered by mod_security.

         I never had the problem anyway. The only reason I was looking at some modules was because I run some other wordpress instals where I need multiple authors to login so I’ve never been able to use the simple htaccess rules. The modules were “limit logins” and “google authenticator”. These are the being touted on some other sites are good triages for this problem. My experience says if someone followed that advice they’d run up against your mod_security fixes and wind up in trouble. I’d have been totally locked out had I not got command line access.

         Mostly, you fixed a problem I’d not got and broke something I was using. You put a frustratingly light explanation of what you’d done with a fix that doesn’t work as there’s no way in my cpanel to disable mod_security. As I have root on the VPS I was able to do it from the command line of course.

         At the end of the day the problem was that I’d no way of knowing you’d done any of this until it caused me a problem. I think you ought to have scanned for wordpress installs and mailed the account owners telling them what you’d done. In fact, I think you ought to do this as a matter of urgency now while people are still coming online. Otherwise you’ll be deluged, people will try and install their own fixes and not have the knowledge to dig themselves out again so they’ll hit your level 1 support.

         Incidentally, the difference is you’re making multiple comparisons then rewriting. I thought a single comparison without a rewrite was better. My memory of the implementation is slightly hazy but I’m fairly sure it’s a marginal but identifiable difference. Filematch doesn’t require a module load either.

    154. Hello satisfice, and thanks for your comments.

         Any of the .htaccess rules mentioned in this article, will need to be placed at the very top of that file above any other current rules. I’ve gone ahead and updated this article to spell that our clearer.

         I’ve also updated the referer section explaining it in more detail. Using a bookmark to your site will work with the referer method, as the bots are currently sending POST requests directly to wp-login.php, whereas when you click on your bookmark, and then attempt to login, it will pass the referer URL and should allow you access.

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

         – Jacob

    155. I was locked out of my site because of a combination of a plugin I installed and the updates made by inMotion. Fixing it was extremely difficult because you’ve not properly explained what you did or what you were trying to achieve.

         I was _not_ locked out because of an attack. I know that for certain as I always protected the wp-login script anyway from htaccess. A simple version of some htaccess lines are :

         
         order deny,allow
         Deny from all
         allow from x.x.x.x
         

         The other files are just some that happened to have been used in an attack previously. I *thought* that using RewriteCond was marginally more cpu cost than a FilesMatch with a simple deny.

    156. Also, could you explain more about the referrer option? I get to my login from a bookmark, normally. If I use the referrer option, does that mean I have to click on an actual “login” button on my site (presumably the attackers are not doing that?). If so, you should say that in the article.

    157. When I add either of the code snippets you suggest, then re-save my .htaccess file, I immediately get a 500 error when I try to log in. What I’m doing is adding the new code at the end of the file. Is that correct?

         Here’s what it looks like:

         Options +Includes All -Indexes
         AddType text/html shtml
         AddHandler server-parsed shtml
         RewriteEngine on
         RewriteRule blog/feed/ blog/?feed=rss2

         
         RewriteEngine On
         RewriteBase /blog/
         RewriteCond %{REQUEST_FILENAME} !-f
         RewriteCond %{REQUEST_FILENAME} !-d
         RewriteRule . /blog/index.php [L]
         

         
         RewriteEngine on
         RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^/wp-admin$
         RewriteCond %{REMOTE_ADDR} !^94\.246\.89\.138$
         RewriteRule ^(.*)$ – [R=403,L]
         

    158. This is extremely frustrating. I’ve got a VPS with root access. I really, really didn’t want someone else messing around with my configuration. I’m now locked out of my own wordpress installation. And, instead of doing what I was supposed to be doing, I’ve not got to unravel what you’ve done to my configuration.

    159. Hello again jamestr,

         Sorry for the continued problems, unfortunately when I looked up your account based off the email address for the support center, a shared account was pulled up.

         If you have root access on your VPS, you can follow my guide on how to disable ModSecurity for a domain.

         Otherwise, simply start up a chat session with us and pass along your VPS number and that you’d like to have mod_security disabled for a specific domain, and we should be able to get that handled for you.

         If you put the .htaccess rules in place, all the botnet IPs should get 403 errors right away and not be able to keep triggering the IP access limit. Then you just need to wait a full 15 minutes, before attempting to access the WordPress dashboard from your own IP, and it should allow you to login then.

         – Jacob

    160. Hello jamestr, and thanks for your question.

         While the Limit Login Attempts WordPress plugin scenario that you’ve laid out, technically should work. In this case due to the scale of the brute force attack, I’d probably lean more towards one of the other methods mentioned in this article.

         Either limiting requests to your WordPress admin via .htaccess by requiring the referrer URL to be your own domain, or adding a second level of password protection before an admin is able to attempt a WordPress login would probably be more efficient ways of handling this particular issue.

         If you do end up using the WordPress plugin and that seems to be working for you, please comment back on here and let me know, so we can also share that knowledge with the rest of our customers as a viable option.

         – Jacob

    161. Hey jkwalz, and thanks for the comment!

         I took a look on your VPS, and it was a bit tricky to figure out what was going wrong, but I did correct this for you, and I’ll also update that article to reflect my findings.

         Essentially after enabling password protection via .htaccess I did see the redirect loop you spoke of. It turns out this loop was created because the server was simply 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”

         Now that the server can find these, the redirect loop has stopped.

         Please let me know if you’re still seeing any issues.

         – Jacob

    162. Hi Karen, sorry for the problems!

         If a WordPress site of yours blocked your access, and directed you to this article, then yes that does mean that your WordPress sites were under attack from this botnet.

         The migration of your VPS just happened to coincide with the roll-out of these security rules on our network, and the two things are unrelated.

         The blocks last for 15 minutes, and so long as there are not more failed login attempts, you should be able to log back in after the block expires. I’ve updated this article above to allow for multiple IP addresses to have access to the WordPress admin, as well as just blocking requests not coming from the domain name itself. In your case one of these methods sounds more practical.

         Also I just finished writing a new article detailing that you can prevent unauthorized WordPress wp-admin and wp-login.php attempts. This would allow for your clients to setup a username / password that must be entered correctly before a login attempt to WordPress directly is allowed.

         We’ve been getting lots of great feedback from customers, and we’ll continue to update things here if we find any easier ways for customer to deal with these recent issues.

         – Jacob

    163. Yes, I have a personal account that is shared, which is apparently how I’m logged in, but this problem is with a work account that is VPS. I’ll follow your instructions above and hopefully that will solve our problems.

    164. Thanks. A half-hour after installing the plugin, the server-level lockout still doesn’t seem to have ended. I’m not sure what that means. I will be trying the referrer URL .htaccess fix. But I do need to say that my cpanel (on a VPS account) doesn’t have a modsec tool under security.

    165. I have an account that is working because I hadn’t been logged out, but anyone trying to login anew is failing, over hours and hours, presumably because brute force attacks are still happening. Might the following work as a way to keep from getting locked out?

         Install the plugin “Limit Login Attempts,” and set it to lockout after three attempts. This blocks based not all attempts, but those from particular IP addresses. So, if these IP addresses get locked out before InMotion’s server-level lockout is triggered, legitimate admin users shouldn’t get blocked.

         Does that make sense? I’m experimenting with it, but won’t know if it works until some time has passed.

    166. Hello medbills, sorry for the troubles you’ve been having.

         This is definitely a preventive measure that is out of the normal, due to such the large scale of the brute force attack. Unfortunately the problem with relying on each customer to have their WordPress site protected already via a WordPress security plugin, is that those plugins have to run PHP processes in order to do their work, and that requires precious CPU time.

         The issue we were seeing, is that the attack was so large scale that it had the potential to slow down an entire shared server, when allowing just WordPress security plugins to try to handle the attack. Additionally there were users that did not have security plugins already installed, and the impact on the server of their site attempting to be brute forced into, could turn around and impact the availability of your own site altogether, rendering your security plugin useless.

         I can understand that these preemptive measures might make it a bit more difficult to work on your sites on the road, but please note as I mentioned in the article above, you can always disable mod_security via the cPanel Modsec Manager if you really need access to the sites. But be warned that this could open your websites up to other types of security problems as well.

         The action we are taking on these blocks is actually consistent, we are not employing .htaccess rules on any user’s accounts. We are only blocking access to the wp-login.php script after there has already been 5 failed login attempts within 30 seconds. The .htaccess rules mentioned above will simply allow you to stop any login attempts at all except from your IP address, and that way the security rules are not getting triggered which totally locks down access to the wp-login.php script.

         In your case I’d recommend blocking based off the referrer URL for the time being, as it seems like the bulk of this attack is happening by directly trying to POST to the wp-login.php script remotely. So basically this .htaccess rule will make it so that only logins where you first go to the website in your web-browser, and then attempt to login will be allowed. Of course replace example.com with your own domain name:

         <IfModule mod_rewrite.c>
         RewriteEngine on
         RewriteCond %{REQUEST_METHOD} POST
         RewriteCond %{HTTP_REFERER} !^https://(.*)?example.com [NC]
         RewriteCond %{REQUEST_URI} ^/(.*)?wp-login.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^/(.*)?wp-admin$
         RewriteRule ^(.*)$ – [R=403,L]
         </IfModule>

         Hope that helps you out!

         – Jacob

    167. Hey again medbills,

         When I was referring to the “precious CPU time” I was talking about the server as a whole, and not just your individual user. If we had 50 users on a shared server all attempting to block their WordPress sites from being brute forced just via WordPress plugins that require PHP script executions, with the rate of the attack, there would be so many running PHP processes that the server as a whole could lack the necessary CPU time to keep on handling normal website requests, database activity and email delivery.

         This wasn’t a matter of too many users being on the shared server, but shared servers by nature are for handling staggering website requests. When there is a large distributed flood of malicious requests, implementing server-wide security policies can be hundreds of times more efficient than handling those requests one by one via a scripting language like PHP.

         I apologize for the syntax error in the .htaccess rules, these have been corrected and updated in this article. Also you can look on this page as well for a link to my new article which talks about adding password protection to your .htaccess file. That way you can simply prevent all unauthorized login attempts before they’re even able to attempt to directly login to WordPress.

         Hopefully this attack will be subsiding shortly, and we’ll be keeping our customers up to date via this article as soon as we have more information to share.

         – Jacob

    168. Hello again Jacob,

         For the time being, I have limited WP admin panel access to the IP address in my office for both WP sites. Once the brute force attacks subside and/or I need to have access to the panel from anywhere, I’ll remove this limitation.

    169. Hello Jacobs,

         While I understand the performance implication of actually utilizing the resources on a shared server, it seems to me that using “precious CPU time” is part of the webhosting service provided by Inmotion. At least, I don’t recall explicit limitation stated by Inmotion Hosting when the service is renewed. You may have some of the servers oversubscribed, but it is not an issue that I’d need to be concerned about. Oversubscribed server did happen for my account sometimes last year and Inmotion had moved my account to a different server. One of the reason for staying with Inmotion is your company is proactively monitors their service performance and other variables and make adjustments as needed.

         Your suggested “mod-rewrite”, blocking based off the referrer URL had been added to the .htaccess file by Inmotion. The scrip may have had a syntax error:

         
         RewriteEngine on
         RewriteCond %{REQUEST_METHOD} =POST
         RewriteCond %{HTTP_REFERER} !^https://(.*)?.mydomain\.com [NC]
         RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
         RewriteCond %{REQUEST_URI} ^/wp-admin$
         RewriteRule ^(.*)$ – [R=403,L]
         

         Please note the blank space between “{HTTP_REFERER} !^https://” when compared with your systax in your posting.

         The referer limitation above prevented logging into the WP control panel from anywhere, including from my office. The login attempt was made by clicking on the “Login” link located within the blog. As such, the referer limitation had been removed from the blog site’s .htaccess file. There’s no issues with accessing the WP admin control panel after it had been removed.

         Disabling mod_security could pose more security risk to the site(s) in question, even if it is temporary. I’d rather not do that and rely on Better WP Security to protect the site, in addition to following best security practices for WordPress.

    170. Jacob,

         Have all inmotion WordPress sites come under attack today? All of my WordPress sites have this block as of today. My account was just moved to a new server yesterday, and I wondered if the migration had anything to do with this block on my sites. Will inmotion lift the block on the sites, or do I have to go into each of the .htaccess files and make the above changes? Some of these sites belong to clients, and the above changes are not practical for them.

         Thanks,
         Karen

    171. Ahh yes you Right Jacob, the directory htaccess would only block the directory protecting the admin files but the login could still be attacked. Joomla is a little different in this aspect where admin login is separate from the front end login.

    172. I have two WordPress blogs hosted by Inmotion that had been the target for the brute force attack and you are correct, the source of this attack is all over the world. While Inmotion’s pre-emptive action is certainly appreciated, I have couple of comments.

         Both of my blogs have pretty much the same security configuration. The WordPress default “admin” account has been renamed and yes, each blogs have their own strong password. Well, maybe not as strong as suggested, but close enough.

         The WordPress is also running the latest stable version and has the “Better WP Security” plugin active. This plugin does monitor for file changes, among other things, and automatically blocks the source IP’s access after three unsuccessful attempt for ten days. I’ve also get an email, if and when a lockout takes place at which point, I do login to check the site.

         The Inmotion’s “block all” access does prevent me to address any issues with the blogs, when email notification has been received. You’re solution of allowing a single IP address for administering the blog does prevent me to login, when I am “on the road” during the work week. My internet access type is varies, it could be public, customer, tethering, etc., access and changing couple of times during the day.

         The action taken by Inmotion is not consistent either. I can login to one of my blogs with no problem, while the other is blocking login via your .htaccess file change. The pre-emptive action is appreciated and certainly the correct one in most cases; however, I am going to restore my .htaccess file to allow login from any IP.

    173. Hey c-baez, and thank you for your comment.

         That is a viable solution for only allowing your own local IP address access to the directory you’ve placed that .htaccess file in. However please note, in this particular case regarding the brute forcing of wp-login.php that rule would not be as effective.

         The reason for this, is that you wouldn’t want to place it in your main /public_html/.htaccess file, as it would outright block all normal traffic to your WordPress site.

         If it was only placed in your /public_html/wp-admin/.htaccess file, then a potential attacker would still be able to attempt to POST requests to wp-login.php directly, as it is not in the /wp-admin directory.

         An attacker would still be able to brute force your WordPress site, as they would simply know that once they get an access denied error when wp-login.php tries to pass a successful login attempt to /wp-admin, that the recent username/password combo they tried should be valid.

         Another way to handle this would be directly disabling access to the wp-login.php script from any IP addresses but your own:

         <FilesMatch wp-login.php>
         Order Allow,Deny
         Allow from xx.xx.xx.xx
         Deny from all
         </FilesMatch>

         Thanks again for your comment!

         – Jacob

    174. To Tap on to the above simply add a .htaccess file with a deny/ allow control in a directory from a IP address that you have approved. For Example:

         order deny,allow
         deny from all
         allow from 000.00.00.000
         allow from 11.111.111.111
         allow from 22.22.222.222

         If the IP is not recognized It will completely deny access to that directory no questions asked.

         * NOTE * This will only work with applications that separate the admin side from the front end user side like Joomla and WordPress. Do not attempt to use in a directory that will share files publicly as well in this directory. But if there is a portion of the site that will never be accessed by the public but is used to modify your front end just block it entirely and only allow access from approved ip’s * End Note *

    Comments are closed.