Hi,
It’s possible that the attack was just too fast for your server to process all of the attempts at once. When Wordfence blocks an IP, Wordfence usually still has to start, and plugins have to be loaded, but Wordfence will stop the login process before the blocked user can log in (whether they guessed the right password or not), and will stop them from seeing content when trying to visit pages.
If Wordfence’s Falcon cache is enabled, it can also automatically add bad IPs to the .htaccess file, so they’re blocked before WordPress is even loaded.
You should be able to see the blocked attempts in the access log, showing a ‘503’ response (or 403 if Falcon was enabled) instead of 200. If all of the xmlrpc.php hits still showed up with a 200 response code, it would most likely be caused by a conflict with another plugin, preventing Wordfence from doing its intended work — if that is the case, let me know. I don’t know of any plugins currently that stop blocking from working on xmlrpc.php.
-Matt R
Hi Matt and thanks for your reply!
An example of my server logs is below, and I X’ed out some of the offending IP’s and the IP of my server.
185.130.X.XXX - - [02/Mar/2016:03:22:55 +0000] "POST /xmlrpc.php HTTP/1.0" 503 608 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 176 0.000 "-" "-" "X.X.X.X"
185.106.XX.XXX - - [02/Mar/2016:03:22:55 +0000] "POST /xmlrpc.php HTTP/1.0" 503 608 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 176 0.000 "-" "-" "X.X.X.X"
185.130.X.XXX - - [02/Mar/2016:03:22:55 +0000] "POST /xmlrpc.php HTTP/1.0" 503 608 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 176 0.000 "-" "-" "X.X.X.X"
185.106.XX.XX - - [02/Mar/2016:03:22:56 +0000] "POST /xmlrpc.php HTTP/1.0" 503 608 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 176 0.000 "-" "-" "X.X.X.X"
185.130.X.XXX - - [02/Mar/2016:03:22:56 +0000] "POST /xmlrpc.php HTTP/1.0" 502 568 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 439 87.092 "0" "87.092" "X.X.X.X"
185.130.X.XXX - - [02/Mar/2016:03:22:56 +0000] "POST /xmlrpc.php HTTP/1.0" 503 608 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-" 176 0.000 "-" "-" "X.X.X.X"
The following plugins were installed:
MainWP Dashboard
MainWP Advanced Uptime Monitor Extension
MainWP Clean and Lock Extension
MainWP UpdraftPlus Extension
CloudFlare
and of course, Wordfence Security.
This server is basically just a MainWP installation that manages my other WordPress sites, so a pretty minimal. The Falcon cache is not activated on it.
So, while my server was giving a 503 response according to my logs, the WordPress install was still not responding in the slightest. I had to SSH into the server and quickly deny the file in .htaccess before WordPress would display anything at all.
Just wondering if you’ve seen this before and if you believe it is due to the sheer volume of the attack. The WordPress install was running at Vultr on a storage VPS (SATA HDD, not an SSD).
Hi,
Yes, you’re correct that it is just due to the volume of the attack — so they were attempting a brute force password attack, but (probably unintentionally) ended up doing a denial of service instead!
The ‘503’ response does mean that Wordfence blocked the attempts, so even if a correct password was guessed, it would not have been accepted. It does also end the connection earlier than a normal response from WordPress, but if the requests are coming in too fast, the server sometimes just can’t keep up.
If Falcon is enabled, the connections are blocked much faster since it’s done outside of WordPress, as soon as the bad IP fails logging in too many times. We’re looking at possibly adding that feature for sites not using Falcon, in a future version.
Since it’s a VPS, one thing I’ve found helpful in the past is to decrease Apache’s MaxClients option. If MaxClients is set too high for the server’s speed, it can let too many WordPress instances run at once, taking up all the server’s memory, and causing some of it to be swapped to disk, greatly slowing down the response. The site may still respond slowly during the attack since connections will be queued up, but it should be able to respond to each connection more quickly and move onto the next.
-Matt R
