# Updates
# 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

Bingbot WordPress pic
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

A linux web hosting administrator, a professional production sound man, and a renegade cop without nothing left to lose.... Ok, that last part is made up. In all seriousness, my passion in life is to help people; whether that be with help running their sites or with their productions. The name Boom Shadow was given to me by a great group of filmmakers called Star Wipe Films. back in 2005 and has been with me since. One of these days, I will post the full story, and many more, here. As a side note, I love my mac for video editing, my CentOS for web hosting, and my Windows box for Stepmania. Don't give me any OS hate, cause I don't care :P Also, nano is still the bomb!

Latest posts by Jacob "Boom Shadow" Tirey (see all)