Last Updated on January 19, 2020 by Christopher G Mendla

I woke up this morning to see that some of my sites were a bit slow to respond.  Shortly after, I was getting a resource limit message from my host when trying to get to the front or back ends of any of the WordPress sites.  I checked cPanel and my resources were maxed out.

The Problem

The first order of business was to figure out what was happening. The hosting doesn’t have raw logs so that made it a bit harder to analyze. Is soon became apparent that it was probably a brute force attack. The screenshot below from cpanel shows the effects of a determined brute force attack.

If your cpanel has the CPU and Concurrent Connection Usage, you can click on that.

It was obvious that there was a sudden spike in resource usage.

First Steps

The first thing I did was to FTP into my server. I have a couple of sites in a folder under my main hosting account. I simply renamed the folders for the sites from site.com to site.com.old. As soon as the folders were renamed, the resources dropped to zero.

I started renaming the files back one by one. It wasn’t until I renamed the folder for this site back that the resource usage spiked again.  Since this site is US centered my first thought was to block visitors from countries other than the US. The easiest way to do that would be to purchase a premium license for Wordfence.  However, I had doubts that would completely resolve the problem.

I tried a couple of ways to block countries in .htaccess. After working with that for a bit I found it was extremely difficult and it began to look like that would not solve my problem.

Use strong passwords for ALL users including accounts used for testing.

htaccess as a stopgap

I applied a temporary fix to my .htaccess to block all visits except for those from my ip.

• Go to a site like whatismyip.com and find your public ip for your workstation.
• Add the following lines to your .htaccess

A user with IP address 73.29.XX.XX has been locked out from signing in or using the password recovery form for the following reason:
Used an invalid username 'test' to try to sign in.
User IP: 73.29.XX.XX
User hostname: c-73-29-XX-XX.hsd1.nj.comcast.net
User location: Toms River, United States

That is not exactly correct for the version of Apache that I’m running but it works. The new version of Apache uses a different syntax.  The lines above will deny all access to the site except for visits from the IP listed. That allowed me to work on the back end and kept my other sites from crashing due to resource limits. When I wanted to try the site ‘live’, I would just comment the lines out with # and save to the server. If the resources spiked, which they did, I would just go back in and uncomment and save.  I’m leaving those lines in my htaccess commented out. That way, I can quickly reactivate them if necessary.

Geo Blocking

I added the Geo IP Plugin to allow me to block or allow visits by country. After some trial and error I got that working. However, I don’t believe that geo blocking is the answer.

Wordfence

Wordfence had an upgrade for their amazing free version. I applied that and started getting messages about visitors being locked out for trying to login with ‘test’ or ‘chrismendlatech’. The login attempts were from a variety of countries: Spain, Lebanon, Australia, India and the United States.  The pattern seems to be that the master server is sending instructions to a hundred or more bots to start with an id of test and probably passwords. Then they try the name of the site and probably passwords. Apparently they didn’t consider throttling their attempts because they broke my hosting. When I would put the site back online by commenting out the htaccess lines, I would see emails from Wordfence with

A user with IP address 73.29.XX.XX has been locked out from signing in or using the password recovery form for the following reason:
Used an invalid username 'test' to try to sign in.
User IP: 73.29.XX.XX
User hostname: c-73-29-XX-XX.hsd1.nj.comcast.net
User location: Toms River, United States

The email had the actual IP. As you can see, I was getting attacks from bots in the US as well as other countries.

Wordfence can be configured to be more aggressive when blocking visitors. Take a good look at the configuration page.

Hide the login page

I found a plugin called WPS hide login that allows you to rename your login page so your login is no longer site.com/wp-login but rather site.com/whatevertheheckyouwant. Security through obscurity is not extremely robust but in this case, it definitely helped.  It’s like the Klingons cloaking their Bird of Prey. You have a hard time hitting what you can’t see.

The resource usage was finally back to normal. There is a possibility that the attacks stopped but from what I could see, they are still occurring. Without the ability to hit the login page, the attacks are using minimal resources.

The final step was to apply the WPS hide Login to all of my other sites.

Once that was in place, the resource usage dropped to normal

Summary:

• Brute force attacks, especially against WordPress sites, are becoming a problem.
• If you have multiple sites on a shared hosting account, an attack on one hurts all the sites.
• While blocking countries might help in some cases, it probably isn’t the answer.
• Changing the name of the login screen seems to work.
• Be sure to NEVER use weak or obvious id/pw combinations such as test/test. Even a non admin account can be useful to the hackers.

Update 1/25/2018 –  I noticed that I was still getting a few brute force attempts from IPs in the United States. I removed the Meta widget from my widgets. That puts a login link on each page which links to the obscured login page. The current plan for the sites does not include visitor registration or sign ins in the foreseeable future. If you did need to provide a link for user sign ins, it might be possible to modify the login page with a captcha. (Keep in mind that one of the Captcha plugins was compromised)