I have a site (built with wordpress) that is currently under a bot attack (as best I can tell). A file is being requested over and over, and the referrer is (almost every time) turkyoutube.org/player/player.swf. The file being requested is deep within my theme files, and is always followed by "?v=" and a long string (i.e. r.php?v=Wby02FlVyms&title=izlesen.tk_Wby02FlVyms&toke).

I've tried setting an .htaccess rule for that referrer, which seems to work, except that now my 404 page is being loaded over and over, which is still using lots of bandwidth. Is there a way to create an .htaccess rule that requires no bandwidth usage on my part?

I also tried creating a robots.txt file, but the attack seems to be ignoring that.

#This is the relevant part of the .htaccess file:
RewriteCond %{HTTP_REFERER} turkyoutube\.org [NC]
RewriteRule .* - [F]
  • 2
    Is the attack coming from the same IP every time? Commented Jul 28, 2010 at 16:09
  • Is your .htaccess rule intentionally triggering the 404 file? Seems like throwing a plain permission denied error would be less bandwidth usage.
    – artlung
    Commented Jul 28, 2010 at 16:13
  • This is the relevant part of the .htaccess file: RewriteCond %{HTTP_REFERER} turkyoutube\.org [NC] RewriteRule .* - [F] Commented Jul 28, 2010 at 16:20
  • However, even though my access logs show "Http Code: 404", it looks like my bandwidth usage stopped when I made that .htaccess change. Commented Jul 28, 2010 at 16:21
  • Do you have the .htaccess code you posted before or after the main wordpress .htaccess rules?
    – artlung
    Commented Jul 28, 2010 at 16:36

5 Answers 5


How about a little corbomite maneuver?

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http(s)?://(www\.)?turkyoutube.org.*$ [NC]
RewriteRule ^(.*)$$1 [R=401,L]

Note, untested but should redirect requests from them back to themselves with a 401 Not Authorized status code. That is, if the bot even handles redirects (very unlikely), but it will still see the status code. A 404 status code may be more effective. Either one should tell the bot that it should probably give up.

The rule you posted in comments is also more than adequate if you broaden the expression to match the host a little more. I use something close (as far as the actual rule) to block user-agents matching libwww-perl:

RewriteCond %{HTTP_USER_AGENT} libwww-perl.*
RewriteRule .* - [F,L]
  • Do you find that many bots have HTTP_USER_AGENT = libwww-perl? This seems like something most bots would lie about.
    – Liam
    Commented Aug 10, 2010 at 11:35
  • @Liam - surprisingly, a decent percentage of them never attempt to masquerade as a real browser (though surely, more do than do not). I thought it was strange too :)
    – Tim Post
    Commented Aug 10, 2010 at 13:23
  • Note that you are using a lot of very slow regex here. The .*$ is equivalent to nothing which is a lot faster. Also the RewriteRule .* - [F,L], no need for the * since you ignore the entry anyway. Commented Jun 2, 2014 at 21:54

Aside from the IP blocking, I would scrutinize the files that are being requested. It's a fairly common thing for open-source systems such as WordPress and Joomla to be exploited, which is one reason why they're frequently updated. If you've neglected a few updates, it's possible that someone has penetrated your site.

I've had that scenario happen to me twice, once on a testing site that never got fully deployed (but was left in place) and another time on a company website where an employee with valid access "snuck" a phpBB on for his family to communicate--updates would have prevented the issues. In both cases, the problem was found with analytics as it seems might be true in your case. The Joomla attack injected javascript that caused the user's browser to load software, while the latter allowed the hacker to upload files to the server that were part of a distributed "alternate" google site that lead the user to p*rn every time. Though it's not entirely a common hack, check your DB users table, just in case.

I certainly don't mean to cause alarm, but it never hurts to take the time to dig through your site once in a while to know exactly what's going on. Sometimes you'll be surprised what you find.

  • I think this is exactly what's happening, actually. Looks like the file being requested shouldn't even be there. Thanksfully, a friendly wordpress core contributor contacted me, so I feel like we'll get it figured out. Commented Jul 28, 2010 at 20:13

If the attack is coming from the same IP number each time (or a small set of IP numbers) you should block that IP number in your firewall. That should not cost any bandwidth or load on your web server.

If you are hosting it on a Linux machine that you have root access to this article explains how to do this.

  • It is not coming from the same IP every time. Commented Jul 28, 2010 at 16:19

I use DenyHosts[1] on all my servers. DenyHosts disallow all IPs which failed to login after n times. You can also send notifications. So you have a great overview from which ips/hosts the logins came; and it also have a web update function and other great features. But it's still very simple to install.

An other method is to disallow all IP Ranges/Blocks (in e.g.) from China or other countries which are not your targeted group. This can be done with online "Blacklists" or just with the hosts.deny file (like DenyHosts).

[1] http://denyhosts.sourceforge.net/


Simply do the 301 redirect to fbi site.

RewriteEngine on RewriteCond %{HTTP_REFERER} ^http(s)?://(www.)?turkyoutube.org.$ [NC] RewriteRule ^(.)$ http://www.fbi.gov [R=301,L]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.