4

At the end of January we noticed a spike in traffic to what JetPack stats says was home/archive page and what Google was classifying as going to /gaming/ which is an archive list in WordPress.

This started off as ~3,000 unique visitors and jumped up to 65,000 unique visitors in one day, again all to the "home" page. This happened over a course of a couple of weeks and we thought we were getting attacked.

The traffic then dropped off for a few days but then came back but came back as only about ~15,000 uniques a day and has been like that every day since. We came to the conclusion that something wasn't tracking right somewhere and this is legitimate traffic and brushed it off.

Now here comes the problem, Google AdSense has just disabled our account for "invalid clicks". We are trying to figure out where this traffic is coming from and stop it if it's not legitimate or figure out a way to track it correctly.

Specs for the site: Dedicated server running CentOS 6 with nginx, php-fpm and MySQL. The site is built in WordPress and we use CloudFlare and W3 Total Cache. Analytics being used are Google Analytics, Quantcast, Alexa and Compete.

Any kind of help would be awesome.

UPDATE: I'm finding more people with the same type of problem and there doesn't seem to be a solution.

http://netmeg.com/bot-attack/

http://stkywll.com/2012/03/02/annoying-cyborgs-attach-distort-analytics/

After looking at the access logs I noticed they were all CloudFlare IP's. I looked into that and found out CloudFlare acts as a proxy and there was a way to fix the logs in nginx. They are coming from many different ISP's in the US. They are going to /games/ or /gaming/ (/games/ redirects to /gaming/) and all seem to have the same user agent of Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0).

8
  • I suspect you'll get better answers on webmasters.SE. Aug 18, 2012 at 20:30
  • 2
    Do you have access logs? The first step to finding where the requests come from is to look at the logs. Aug 18, 2012 at 20:31
  • Did you have a look at webserver logs?
    – user130370
    Aug 18, 2012 at 21:19
  • Ok, after looking at the access logs I noticed they were all CloudFlare IP's. I looked into that and found out CloudFlare acts as a proxy and there was a way to fix the logs in nginx. So I will be monitoring the logs to see what the actual IP address is now.
    – kel
    Aug 18, 2012 at 21:20
  • I'm looking at the logs and they are coming from many different ISP's in the US. They are going to /games/ or /gaming/ (/games/ redirects to /gaming/) and all seem to have the same user agent of Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0). What should I be looking for?
    – kel
    Aug 18, 2012 at 21:27

3 Answers 3

1

Yup I've had this problem for quite some time with a different user agent.

We just learned to live with the traffic ... if you want to keep the bad page views out of your google analytics or otherwise suspend certain services like adsense for them (we certainly did) you can find out more about doing that here:

http://stkywll.com/2012/04/27/annoying-robots-a-solution-for-google-analytics/

There is basically no good server side solution to this -- the solution above is based on click and mouse-move detection in the browser, and so far that's the only good way to tell good traffic of this sort from bad.

Good luck y'all!

2

Sounds like your site may be compromised, esp. if your AdSense has been suspended. Register for Google's Webmaster Tools and see if it reports any malware. Run the site through Sucuri's Sitecheck, too. Install the WordPress Exploit Scanner plugin for a quick check, then consider diffing your site against a clean copy of v3.4.1 and doing the same for your plugins and themes (including the twentyten & twentyeleven directories, which are a common hideout for malware files). I see a lot of sites getting owned via insecure plugins with third-party libraries like timthumb, so it's definitely a vector to be aware of.

Put some sort of protection in place for /wp-login.php, all the WordPress sites I admin get regular automated brute-force attempts against them, so if any of your users' passwords are weak you can be vulnerable there. I tend to protect this location in my nginx configs by limiting IP ranges for logins (if the clients permit), rate-limiting with limit_req_zone and/or installing plugins such as login-lockdown, Duo's Two-factor Auth or Google Authenticator for WordPress. I've seen hacks where the spammer will get an admin login to a blog and then alter the content, rather than trying to own the box, often with the objective of utilising a site's Pagerank to get a linkback boost.

If you've ruled out any sort of hack of your site and you're still getting malicious visitors deliberately trying to subvert the clicks on your ads, something that screens and bans them before they have a chance to will ameliorate matters. The Bad Behaviour plugin will do this and may be suitable (though it's rather agressive, so keep an eye on its ban list and whitelist generously where applicable) or, if you want to do it at a lower level, take a look at naxsi for nginx or fail2ban.

3
  • 1
    Bad Behavior is my code. As far as I know it's very conservative in what it blocks. Though you can make it more aggressive by enabling strict mode. Aug 19, 2012 at 3:07
  • @Stef Pause, no malware reported from GWT, Sucuri shows good. I run WordPress exploit scanner every week. I'm also connected with VaultPress. I've update the post with links of people having the same issue though.
    – kel
    Aug 19, 2012 at 4:59
  • @MichaelHampton, I have Bad Behavior installed but not active. Reason was a while ago there was conflict with Google +1 buttons. It looks like that's been resolved so I just reactivated it.
    – kel
    Aug 19, 2012 at 5:01
1

Very simple. Simply open up index.php in the root directory and add this to the beginning:

$useragent = $_SERVER['HTTP_USER_AGENT'];

if ($useragent == "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)")
    {
    header("Location: http://www.google.com/");
    exit();
    }

Since all these are coming from different IP addresses, it isn't practical, realistic, or time-efficient to block the IP addresses. But since they all have the same user agent, you can just block that instead. This simply redirects anyone with that user agent to Google. The only possible downside I can think of is that if any legitimate visitor has this same user agent, they will also be redirected to Google. To solve this, instead of redirecting to Google, you can make them enter in a CAPTCHA or something.

Thanks @Oerd for adding the essential exit/die statement.

1
  • 1
    An exit() or die() should go after your header(...) line. You need to make sure that code below won't execute if request has been redirected. You cannot be sure that these "attacking" bots will behave according to HTTP standards.
    – Oerd
    Dec 5, 2012 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .