I manage multiple WordPress installs (all related/cross-linked) and I've been getting hit hard with brute force attempts for the past few weeks, enough to crash my servers on multiple occasions. I went ahead and installed WP Limit Login Attempts, but I want something better. I'm still seeing spikes in resource utilization, I imagine because even though the user/password check against the DB is being skipped, the WordPress login code is still being executed for every request.

My stack is Nginx in front of Apache/PHP-FPM. Is there a tool out there I can use to let Nginx do the blocking?


  • Nginx has a set of configurations for restricting access. What were you thinking? IP range blocking or something? Apr 20, 2016 at 20:49
  • This isn't strictly what you asked for but have you looked at putting CloudFlare in front of the install(s)?
    – JSP
    Apr 26, 2016 at 20:44
  • I've been using CloudFlare on all my sites for years, this attack was getting around it. I ended up just going with Wordfence and so far so good, we'll see how it holds up over time.
    – bhamrick
    Apr 30, 2016 at 8:20

4 Answers 4


If the "attack" is distributed, the only thing you can do is to change the url of the login endpoint. This should be easy to do with web server config (block /login and friends, map some other "slug" to wp-login.php). This will also break the automatic redirect from /wp-admin to /login which is a good thing in this case.

Don't forget to handle xml-rpc as well in the same way.

Of course this answer is not great if you have many users, but it can work if the number of users is small.

  • I also use WooCommerce and AffilaiteWP, which both have their own registration/login forms. Would this affect those at all?
    – bhamrick
    Apr 20, 2016 at 17:13
  • If it is ajax based, then it should not have an affect, but knowing how Pippin loves his code, AffiliateWP probably uses the WP core login system. The issue here is really about communicating the user the new login url, if you can just send emails to notify them, then there is no problem. Another alternative is to assume that brutefoorcers are dumb and replace the original login form with some message about what is the new login URL is Apr 20, 2016 at 17:20

If you can add fail2ban to the server, try the wpfail2ban plugin.


If using it on your own server, I wouldnt recommend using a WP plugin as a base, try to configure fail2ban ( a brief tutorial - https://easyengine.io/tutorials/nginx/fail2ban/ ) , it will work like a charm.


Elaborating on @dExit and @dave-ross answers about fail2ban. Surly using a custom fail2ban "jail" is a better practice then stopping attacks with a wordpress plugin. The problem is that fail2ban filters work with a log pattern and AFAIK vanilla wordpress installation does not give us any clue via log or header that something has gone wrong with authentication.

So a plugin like wpfail2ban might help. A better solution in my opinion would be forcing wordpress to return a 401 http status code (See my question here ) which conforms to modern web standards and exceptions and allows other tools to block repeated offences. In this case we are not limited to using fail2ban blocking on the server (Although we can easily configure a custom jail and filter to search for 401 response in web server log) But we can use a WAF service, to monitor this kind of attack, using the response codes, and blocking them on the perimeter.

Why wordpress default is still to return 200 "OK" response to failed login I really can't guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.