Spoofed Bingbot attacks against WP

February 2, 2012 — 18 Comments

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:

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:

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:

At the bottom of the file add:

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:

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:

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:

Comment out the line about 403 Forbidden. Once done, the top of the file will look like the following:

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 😛

Change Log:

  • 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

Jacob "Boom Shadow" Tirey

Posts Twitter

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. I hope my site is helpful to you, and if there's something you need, drop me a line!