In the last 24 hours, I have seen a large scale attack on the admin logins for thousands of Wordpress sites. The attackers are using the User Agent ‘Bingbot’. Bingbot certainly is not the culprit in these attacks, but is, unfortunately, being spoofed. These spoofing bots are attacking the wp-admin page. So far, I have only seen this affect WP Mage and Mage Monster users.
A brute force attack on any login is certainly undesirable; you obviously don’t want any unauthorized person accessing your admin area. However, the real problem comes from the CPU strain this is putting on the hosting server. These constant requests to hundreds of websites on the server will drive up the CPU load, effectively tying up the resources. The server will not be able to serve up pages to legitimate traffic or legitimate search engine bots that are trying to crawl the sites.
There is a solution you can use to combat this problem. The solution is to block the Bingbot user agent from accessing your these admin pages. An IP based firewall block would do no good as the source IP’s have no common denominator; the IP’s are too spread out and come from many different geographical locations.
By implementing the following fix, you can reduce the loads back to normal operating levels allowing your site’s pages to load once again and you will not affect your rank with Bing. After a couple of days, the attack should have subsided and you should be able to safely reverse the changes. However, per Duane Forrester of Bing’s webmaster tools, you do not have to undo the block. There is no harm in permanently preventing your admin pages from being indexed (for reference, see his comment here).
Are you affected?
You can run a quick check to see if your sites are being hit with this spoofed Bingbot attack. Check your sites’ domlogs and look for any Bingbot User Agent requests that are hitting Wordpress admin pages:
grep bingbot /usr/local/apache/domlogs/* | grep wp-login If you receive numerous results from running that, especially from various IP addresses, it means that you are being affected. If you see many POST commands in there, it means they are also trying to log into Wordpress.
Example:
/usr/local/apache/domlogs/domain.com:24.153.219.159 - - [01/Feb/2012:15:27:18 -0500] "GET /wp-login.php?redirect_to=http%3A%2F%2FDOMAIN.COM%2Fwp-admin%2F&reauth=1 HTTP/1.1" 200 2206 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
/usr/local/apache/domlogs/domain.com:24.153.219.159 - - [01/Feb/2012:15:27:18 -0500] "POST /wp-login.php HTTP/1.1" 200 3084 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" How to block them
Now that you’ve verified that this directly affects you, time to block them and restore your server’s vitality.
Edit the pre-virtual host conf
We need to tell the server what is a “bad bot”. In this case, it is Bingbot. Then, we tell it to block it:
nano /usr/local/apache/conf/includes/pre_virtualhost_global.conf At the bottom of the file add:
SetEnvIfNoCase User-Agent ".*bingbot" badbingbot
<Files wp-login.php>
order allow,deny
allow from all
Deny from env=badbingbot
</Files>
<Location /wp-admin/>
order allow,deny
allow from all
Deny from env=badbingbot
</Location> If you do not want to block Bingbot on every domain and would rather only block it on a few particular affected domains, you can, instead, make the change to each domains’ virtual host via an include file. For more information, see cPanel’s documentation here: http://docs.cpanel.net/twiki/bin/view/EasyApache3/InsideVHost
Restart Apache
Now it is time to restart Apache so that our changes can take effect:
service httpd restart Test it
Which Apache restarted, you should see your CPU load start dropping immediately. You will want to test it to make sure that bingbot is successfully blocked. Do what the attackers are doing, access your page while spoofing your User agent as Bingbot:
wget -U "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" http://domain.com/wp-admin/ Be sure to change domain.com with your actual domain name. You should receive a 403 Forbidden error. If not, the file that is downloaded should be completely empty, meaning no content was served up.
403 Error Handling
When successfully blocked, the bot will be sent to the 403 Forbidden page (as you saw in the test above). However, depending on your theme, the 403 page may be a custom error page that still loads part of the site and many of the plugins. This will still cause a heavy strain on the server because it has to process this 403 error page for every request. You have two options: Option #1. Set the 403 page for every affected site to be a lightweight page with little text. You will want a minimalistic page that will not cause large CPU load if it is accessed dozens or even hundreds of times. Option #2. Disable the 403 page temporarily.
If you have many Wordpress sites that are all being affected (this typically would fit Mage), then it would just be quicker to opt for Option #2.
To do that, edit the following file:
/usr/local/apache/conf/includes/errordocument.conf Comment out the line about 403 Forbidden. Once done, the top of the file will look like the following:
# 400 - Bad Request
ErrorDocument 400 /400.shtml
# 401 - Unauthorized
ErrorDocument 401 /401.shtml
# 402 - Payment Required
ErrorDocument 402 /402.shtml
# 403 - Forbidden
#ErrorDocument 403 /403.shtml
# 404 - Not Found
ErrorDocument 404 /404.shtml Then you must restart Apache and you’re done! The load issues should clear up.
Notes
The attack should subside within a few days. You do not have to undo your changes you made. You can leave the admin page blocks in there. No search engine should ever need to index or even access your admin pages. This is true for any CMS, not just Wordpress.
If you have implemented the disabling of the 403 Page, be sure to undo that one. You may actually want your 404 pages back when the attack has passed :P
Change Log
This post has been updated since it’s original publishing. Here is a list of changes:
- 06/18/12: Bingbot attack returns, but attacks the wp-admin folder instead of just the login page. Updated to patch that. Also added 403 Error handling
- 02/04/12: Revised wording to reinforce Bing’s perspective
- 02/02/12: Modified block code to identify bingbot as ‘badbingbot’ in case ‘bingbot’ is already being used somewhere