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!
  • Pingback: Google Launches New Site To Assist Hacked Website Owners | RefuGeeks()

  • Hello, thank you for this usefull information that cannot be found anywhere else. All the sites refer to this page of yours :)

    I applied these codes as shown here almost 2 weeks ago, but still getting bad bingbot attacks. It seems it will never stop. I applied the codes exactly as shown here. Do you have any suggestions why it does not work at my server?

  • Mark

    I followed this to the letter and noticed that wget is returning a 302 instead of 403? I added the code as shown and not sure what it isn’t kicking back the 403…

  • What if you don’t have this file?

    /usr/local/apache/conf/includes/pre_virtualhost_global.conf

    • A cPanel box normally has that file, but if not, you can either create it or use a different file. Inside the /usr/local/apache/conf/includes/ folder, there should be at least one other file you can use as an alternative:

      pre_virtualhost_1.conf

  • Aaaa

    My site attacked by bingbot too, I checked those Ips and all are true IPs from Microsoft, if you think they are spoof, how to explain those IPs? Microsoft Gave them Proxiex to attacked us? Or how is it possible to make a MS IP if not bingbot?

    • I have not heard of any attacks from legitimate Microsoft owned IP’s. Although, I have heard of Googlebot accidentally slamming servers before. Its not outside the realm of possibility that Bingbot could do the same. If that is the case, the fix provided in the article will also correct your problem.

  • Pingback: BrooksDC()

  • Well it’s just not the BingBot – spoofing attacks give all sorts of crappy referrer logs, and try to deceive you that search engines are trying to index your /wp-admin area, and some poor amateur bloggers even grant 777 permissions lol! (that’s such a pity, but I’ve personally seen a few bloggers do it – though it may sound too funny and unbelievable!)

    • Indeed, you are right. Spoofing major search engines is a pretty smart way to attack. Most people are scared to do any blocks against search engines because they need to be indexed. Luckily, the steps provided above won’t harm anything as search engines should NEVER need to to access or index your admin login pages. That goes for any CMS. Also, 777 permissions are pretty common still and a major source for hacks. I’m glad you know when to use it and when not to.

  • Man, <3 you !  :PPP you saved one of my boxes 😉

  • Mr

    thanks a ton! was getting hit hard today with this. running multiple vhosts all with WP.. blocked this crap all at once. in Ubuntu with apache2 add the code in /etc/apache2/httpd.conf i wonder if there is a way to block only if a Ueser Agent is trying to POST to a form… am researching this now.

    • Glad the information was helpful to you! Also, your idea about POST
      blocking would be rather handy. However, it would be even nicer if that
      could be handled by something active like CSF. Lets say it detects too many POST commands
      from the same IP on the same file (such as the admin login), it could
      automatically insert a block rule into IPtables. Blocking at the
      firewall level would be far more efficient. Perhaps this is something I can get my coder buddy to make….. Hmmmmm

  • Duane Forrester

    I’ll add a couple of point here:

    1 – this is not coming from Bing, as noted.
    2 – opting to leave the block on Bingbot to NOT index the Admin pages is fine.  No need to undo the work once you do it.  Bing isn’t gaining a lot of value in indexing the Admin login page for your WordPress site, so blocking that page doesn’t hurt you in any way.  Be careful not to block the other, public-facing pages on your site though.  Those we definitely want to index. :)

    duane forrester
    sr. product manager
    bing webmaster tools

    • Guest

      Thanks for the feed back Duane! 

    • @17a6c781b154dda89bee1a486ed2a7d0:disqus , indeed, thank you for adding official input from Bing’s perspective. I’m sure users will want to know that Bing isn’t at fault and, most importantly, that the block won’t adversely affect their rank. I have updated the article reinforce what you’ve said.

  • gjpcoach

    Is this happening on other servers other than those at Servint?

    • @39052357d2714832d1c0ab73cae3ec95:disqus , This kind of attack certainly could affect any host. I read on a forum of other users that were getting hit with this as well.