One of the first server-level compromises I had to deal with in my life was around 15 years ago, and it was caused by an SSH brute force attack. A co-worker set up a test server and chose a very weak root password. A few days later, the box was compromised and the attackers installed IRC bots and used that server as a stepping stone to hack others.
You would think that after 15 years of improvements on security, brute force attacks would be a thing of the past.
However, brute force attacks are still going strong. In fact, they are one of the leading causes of website compromises. When you have an unprotected login page, you will see brute force attempts. With WordPress sites, same rule applies. We see thousands of failed login attempts to /wp-login.php on the websites we protect per minute.
We see so many that we decided to create a separate page to track the state of brute force attacks against WordPress sites in our network:
This page is updated daily with new data that we see on brute force attacks live in the wild. We will be adding more data to it soon, but for now it can give a good idea of the current threat level.
If you have any suggestions or ideas on what to add, let us know.
I have also noted this steep increase. Are you counting xmlrpc.php attempts that use the wp.getUsersBlogs function as well? I find those to make up a varying but significant amount of WP brute force traffic.
Yes, we are. In fact, we are noticing an increase on brute force attempts through it as well. I think as more people are blocking their wp-login, the attackers are switching tactics and going straight to xmlrpc that very few people block or monitor.
thanks!
well in case of existing WP site, would please redirect us to a way to move everything from htdoc to a custom folder and keeping the necessary files in the htdoc.
Thanks in advance.
I found that hidding the login url is effective and easy to implement. If you don’t enter the hidden url, you will get a 403 error. As far as I can see, this reduces brute force attacks to a minimum. For most of my sites they were recuded to zero. The attack will simply never reach the wp login system. At the same time it is much more comfortable for the user than a classic password protection via the .htaccess.
Thanks Daniel, interesting. Could you (or someoe else) recommend a good fail2ban-like plugin against brute force attacks?
I’m not sure about the purpose of this post. Yes, you confirmed what I already know which is daily brute force attacks. I expected more help with all the different ways we can address these … as I’m working my way through what it’s going to take to stop them making my servers non-functional.
That’s for a follow up post 🙂 But some of the comments here already provided some solutions you can use:
-Captchas
-IP white listing
-2FA
Some of these can be done through free plugins or our Website Firewall (CloudProxy).
These attacks are easily defused by renaming the login URL (multiple WordPress plugins make this simple to do) and blocking it in .htaccess/IIS config. What I find astounding is that so many sites continue to leave the login URLs exposed. Automattic should give serious consideration to forcing people to rename their login pages. “wp-login.php” has outlived its usefulness.
We are seeing lots of brute force through xmlrpc as well. Can’t forget about that!
We host WordPress sites.
You can always implement catcha and 2-FA to prevent successful brute-force attacks.
There is a free WordPress Captcha plugin that requires you to solve simple Maths problem (2 + ? = 5).
2-FA plugins can use free Google Authenticator mobile app; you do not need a physical token hardware
Fail2Ban plugins are not very effective. Most brute-force login attempts use botnets and you get no more than 3 brute-force login attempts from each of the bot source IPs. If you blacklist all attempts, your web site will eventually slow down due to the excessive entries in your list.
An effective method is to restrict wp-login.php login url by IP addresses. We use mod_geoip2 module with free GeoIP database to restrict login URL to our country; which provides more than 95% hit rate. Mod_GeoIP2 module has options to further restrict by city if you use their paid GeoIP database.
I just replied on other comment, but I will add here as well: Agree 100% with you.
I generally recommend IP addresses restrictions followed by captchas, country-based blocks and 2FA. We just can not forget to do the same with the xmlrpc file, as lots of brute force attempts go through it.
Wow, not surprised to see the sharp increase from January to now, based on personal experiences with client websites. Not surprising, but powerful to see it mapped out like that! I think this is great information to help supplement our client education about online security. Thanks guys 🙂
Why was CloudFlare (previously) and Hostmaster (currently) so ridiculously overrepresented in your ASN data? Any ideas?
CloudFlare is overrepresented because lots of sites use their service and the real IP address gets hidden*. I thought about removing them from the list, but we kept it for the sake of keeping it honest.
We might remove it from there on the next update to avoid confusion, since quite a few people asked about it. What seems to be more surprising to so many people is that they allow that amount of brute force attempts to pass through them.
*It is not fully hidden as they pass it via some headers, but these can be easily spoofed, so we do not take them into consideration.
thanks!
I would vote for not removing CloudFlare from your results. It would not be that hard for them to filter the brute force traffic if they decided they cared enough to do it.
Interesting about CloudFlare showing up. In our setup we use a very simple page rule in CloudFlare that has drastically reduced wp-login attempts.
Match: *.example.com/wp-login*
Rule: Security = I’m under attack, Browser Integrity Check = On
Across 30 sites we might get a failed login lockout once a week. For the actual site owners they get a small delay in logging in while the browser integrity check runs.
The best way to protect WordPress sites is using OpenResty, extended Nginx server. Writing “access_by_lua” for sensitive WP paths/locations is not that hard. No need for Fail2Ban – just return 444 to block an ip. Use GeoIP to block countries, if needed. OpenResty is unbelievable effective in dealing with all kinds of brute-force attacks.
Thanks to the post and especially the comments we implemented WPS Hide Plugin to change the wp-admin url and its working great. Also, a sucuri customer which we would highly recommend the ongoing support/monitoring as we have on our sites.