16

The last few days I noticed some servers being hammered with unknown requests.

Most of them are like the following:

60.246.*.* - - [03/Jan/2015:20:59:16 +0200] "GET /announce.php?info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1 HTTP/1.1" 200 -

After a bit of logging and searching I found out that some Chinese ISP (probably CERNET according to the results of whatsmydns.net ) and some Turkish ISP (probably TTNET) respond to dns queries such as a.tracker.thepiratebay.org with various IPs that have nothing to do with piratebay or torrents. In other words they seem to do some kind of DNS Cache Poisoning for some bizarre reason.

So hundreds (if not thousands) of bittorrent clients on those countries make tons of 'announces' to my webservers which result pretty much in a DDoS attack filling up all Apache's connections.

At the moment I blocked China and Turkey altogether and it does the job, but I would like to find a better way to block those requests.

I was thinking of blocking those requests with mod_security based on the HTTP Host header.

All those requests include an HTTP Host header like a.tracker.thepiratebay.org (or many other subdomains of thepiratebay.org domain).

Here's a dump of the request headers via PHP's $_SERVER variable.

DOCUMENT_ROOT: /usr/local/apache/htdocs
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT_ENCODING: gzip
HTTP_CONNECTION: Close
HTTP_HOST: a.tracker.thepiratebay.org
HTTP_USER_AGENT: uTorrent/342(109415286)(35702)
PATH: /bin:/usr/bin
QUERY_STRING: info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1
REDIRECT_STATUS: 200
REMOTE_ADDR: 60.246.*.*
REMOTE_PORT: 3445
REQUEST_METHOD: GET
REQUEST_URI: /announce.php?info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1
SCRIPT_FILENAME: /usr/local/apache/htdocs/announce.php
SCRIPT_NAME: /announce.php
SERVER_ADDR: *.*.*.*
SERVER_ADMIN: *@*.*
SERVER_NAME: a.tracker.thepiratebay.org
SERVER_PORT: 80
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE: 
SERVER_SOFTWARE: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 mod_perl/2.0.8 Perl/v5.10.1
UNIQUE_ID: VKg8BJBMIPQAD01XYzgAAAAD
PHP_SELF: /announce.php
REQUEST_TIME_FLOAT: 1420311556.43
REQUEST_TIME: 1420311556
argv: Array
argc: 1

So my question is, how can I block incoming requests to Apache based on the request domain (HTTP Host header) ? Keep in mind that the requests are on various URLs not just /announce.php so blocking by URL is not useful.

Also is that approach viable or will it cause too much load and I should keep dropping those requests before they even reach Apache?

Update:

It turns out this issue has affected many people in many countries around the globe.
There have been numerous reports and blogposts about it and various solutions to block this traffic.

I've collected some of the reports to help anyone coming here searching on a solution to block this.

Mysterious misdirected Chinese traffic : How can I find out what DNS server an HTTP request used?
Strange Bittorrent Log On My Server
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
https://www.webhostingtalk.com/showthread.php?t=1443734
http://torrentfreak.com/zombie-pirate-bay-tracker-fuels-chinese-ddos-attacks-150124/
https://isc.sans.edu/forums/diary/Are+You+Piratebay+thepiratebayorg+Resolving+to+Various+Hosts/19175/
http://furbo.org/2015/01/22/fear-china/
http://www.jwz.org/blog/2015/01/chinese-bittorrent-the-gift-that-keeps-on-giving/

Improve this question
7
  • 1
    I'm seeing a similar issue to this, I've blocked the requests but I was wondering how you'd figured out which ISPs were returning the incorrect IP addresses? I'm interested to find out where the requests are coming from so that seems like a good starting point
    – pogo
    Jan 9, 2015 at 10:31
  • According to whatsmydns.net and other glbal dns propagation checkers, CERNET and CPIP at China and TTNET at Turkey respond to queries on various subdomains of thepiratebay.org to various IPs when that domain does not resolve on any other ISP around the planet.
    – Cha0s
    Jan 9, 2015 at 12:45
  • 2
    I'm getting the exact same thing and it started about the same time you noticed it. facebook, bittorrent, porn sites. but most notably this constant pirate bay announce. serverfault.com/questions/658433/… I'm using nginx and I've returned 444 if the host doesn't match.
    – Chris Sattinger
    Jan 9, 2015 at 16:07
  • the requests to announce have reduced by quite a bit. maybe it was a temporary DNS misconfiguration. are you still seeing traffic ?
    – Chris Sattinger
    Jan 13, 2015 at 11:32
  • 2
    To be honest I ended up blocking China at the firewall level after all because even with mod_security they would fill up all Apache's connections. So I haven't noticed if the requests have been reduced.
    – Cha0s
    Jan 13, 2015 at 14:03

5 Answers 5

Reset to default
7

Same issue here. I am using mod_security to block the user-agent

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,log,msg:'Bittorrent Hit Detected'"

I would change the log to nolog after you verify it is working to avoid filling up your log file

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,nolog,msg:'Bittorrent Hit Detected'"
Improve this answer
2
  • 1
    While not exactly what I needed, your answer steered me to the right direction so I chose yours as the correct one. I ended up blocking all torrent requests by matching the '?info_hash=' string on the REQUEST_URI. User-Agent wasn't the best approach because the clients use many different bittorrent clients with different UAs. The final mod_security rule I ended up with is: SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"
    – Cha0s
    Jan 6, 2015 at 13:24
  • Try to dig a.tracker.thepiratebay.org from any DNS server in this list public-dns.tk/nameserver/cn.html and on each request there is a different answer. Same for tracker.thepiratebay.org which also appeared in our Host: headers. There is a post about it on viewdns.info/research/… with some additional sites. Trying to reverse some of the returned addresses using viewdns.info/reverseip shows that its pretty much random.
    – Evgeny
    Jan 22, 2015 at 1:33
5

We are experiencing exactly the same issue with one of our client's sites. I added the following near the top of their :

# Drop Bittorrent agent 2015-01-05 before redirect to https
<IfModule mod_rewrite.c>
    RewriteEngine on
    # RewriteCond %{HTTP_USER_AGENT} =Bittorrent
    RewriteRule ^/announce$ - [F]
    RewriteRule ^/announce\.php$ - [F]
</IfModule>

The commented-out RewriteCond can be uncommented to only block a specific user agent. But they have no content at announce or announce.php so we just blocked it all.

Improve this answer
2
  • Thanks, but I needed a solution using mod_security and not mod_rewrite.
    – Cha0s
    Jan 6, 2015 at 13:25
  • see engineering.bittorrent.com/2015/01/29/… for a better way (G/410 instead of F/403, and an explicit ErrorDocument)
    – ysth
    Feb 23, 2015 at 18:17
5

I'm having the same issue at the moment, having torrent trackers point at my server. I've experimented with iptables for the past couple of days and inspected headers and patterns of the requests and narrowed it down to a couple of iptables rules that filters pretty much all of the recent seemingly malicious traffic from Asia (China,Malaysia,Japan and Hong Kong).

Below are the rules. Hope it helps someone.

iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Bittorrent" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "spider" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "announce" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "deviantart" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Bittorrent" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "baidu" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Baiduspider" --to 1000 -j REJECT
Improve this answer
6
  • Nice! I didn't think of that! Thanks! :D Did you choose to REJECT instead of DROP for some particular reason? (ie: clients may stop after receiving a REJECT?)
    – Cha0s
    Jan 24, 2015 at 17:21
  • 1
    Yes, REJECT should tell the client to stop requesting that resource though it doesn't seem to be helping in this case. It still filters it out so I'll leave it as REJECT hoping that some clients take a hint. Any way, iptables should perform a lot better than mod_security at this task, so I hope it works well for you.
    – Franci
    Jan 24, 2015 at 18:36
  • Yeap it should! I was blocking all Chinese prefixes. I will try this approach which is better :) I think that the bittorrent clients won't stop retrying even with REJECT. They would see it as 'connection refused' and retry after a while. I believe DROP is a better approach (and uses less resources - it simply drops the packets the moment they get matched without any further processing)
    – Cha0s
    Jan 24, 2015 at 18:43
  • 1
    The difference is quite negligible actually in all but extreme cases, and my hope was to eventually deter the traffic. If it doesn't dial down I'll change it to DROP. I'm very curious as to why or how this came to happen in the first place though. There are some discussions about the Great Firewall of China redirecting to random IPs but I'm pretty sure this is not the case here.
    – Franci
    Jan 24, 2015 at 19:54
  • 1
    +1 Nice one. We're going with --string "GET /announce" though, to cover the actual request.
    – Linus Kleen
    Jan 27, 2015 at 12:38
5

I wrote a blog post about how to properly tell BitTorrent clients to go away and never come back, similar to what Dan did, but using nginx.

server {
    location /announc {
        access_log off;
        error_log off;
        default_type text/plain;
        return 410 "d14:failure reason13:not a tracker8:retry in5:nevere";
    }
}

Torrent trackers (usually) have a standard URL that begins with /announce or /scrape, so I wouldn't dismiss filtering by URL so quickly. It works.

The full post is at - http://dvps.me/ddos-attack-by-torrent

Improve this answer
3
  • 1
    Interesting read. Thanks for sharing :) But I believe the attack was induced by means of DNS Cache Poisoning since CERNET in China responds to TPB domains with random and non-chinese IPs. AFAIK PEX is for sharing peers, not trackers. Can you elaborate more on that or provide some documentation?
    – Cha0s
    Jan 21, 2015 at 17:04
  • There is an extension for sharing trackers described here bittorrent.org/beps/bep_0028.html. But you are correct in that the 'Host:' header for all of these requests is a.tracker.thepiratebay.org or tracker.thepiratebay.org which might be or not be the actual target of these clients. It can also be fake clients just masking themselves as Chinese bittorents :)
    – Evgeny
    Jan 21, 2015 at 17:25
  • 1
    the bittorrent folks suggest 410 instead of 404: engineering.bittorrent.com/2015/01/29/…
    – ysth
    Feb 23, 2015 at 18:19
0

i took the Chinese ip ranges from: http://www.wizcrafts.net/chinese-blocklist.html and blocked them in my csf firewall, here is the ranges in case you want to copy and paste into your deny ip list of csf:

#china blocks start
1.80.0.0/13
1.92.0.0/14
1.192.0.0/13
1.202.0.0/15
1.204.0.0/14
14.144.0.0/12
14.208.0.0/12
23.80.54.0/24
23.104.141.0/24
23.105.14.0/24
27.8.0.0/13
27.16.0.0/12
27.36.0.0/14
27.40.0.0/13
27.50.128.0/17
27.54.192.0/18
27.106.128.0/18
27.115.0.0/17
27.148.0.0/14
27.152.0.0/13
27.184.0.0/13
36.32.0.0/14
36.248.0.0/14
42.96.128.0/17
42.120.0.0/15
58.16.0.0/15
58.20.0.0/16
58.21.0.0/16
58.22.0.0/15
58.34.0.0/16
58.37.0.0/16
58.38.0.0/16
58.40.0.0/16
58.42.0.0/16
58.44.0.0/14
58.48.0.0/13
58.56.0.0/15
58.58.0.0/16
58.59.0.0/17
58.60.0.0/14
58.68.128.0/17
58.82.0.0/15
58.100.0.0/15
58.208.0.0/12
58.242.0.0/15
58.246.0.0/15
58.248.0.0/13
59.32.0.0/12
59.51.0.0/16
59.52.0.0/14
59.56.0.0/13
59.72.0.0/16
59.108.0.0/15
59.172.0.0/14
60.0.0.0/13
60.11.0.0/16
60.12.0.0/16
60.24.0.0/13
60.160.0.0/11
60.194.0.0/15
60.208.0.0/13
60.216.0.0/15
60.220.0.0/14
61.4.64.0/20
61.4.80.0/22
61.4.176.0/20
61.48.0.0/13
61.128.0.0/10
61.135.0.0/16
61.136.0.0/18
61.139.0.0/16
61.145.73.208/28
61.147.0.0/16
61.150.0.0/16
61.152.0.0/16
61.154.0.0/16
61.160.0.0/16
61.162.0.0/15
61.164.0.0/16
61.175.0.0/16
61.177.0.0/16
61.179.0.0/16
61.183.0.0/16
61.184.0.0/16
61.185.219.232/29
61.187.0.0/16
61.188.0.0/16
61.232.0.0/14
61.236.0.0/15
61.240.0.0/14
101.64.0.0/13
101.72.0.0/14
101.76.0.0/15
101.80.0.0/12
103.253.4.0/22
106.112.0.0/13
110.6.0.0/15
110.51.0.0/16
110.52.0.0/15
110.80.0.0/13
110.88.0.0/14
110.96.0.0/11
110.173.0.0/19
110.173.32.0/20
110.173.64.0/18
110.192.0.0/11
110.240.0.0/12
111.0.0.0/10
111.72.0.0/13
111.121.0.0/16
111.128.0.0/11
111.160.0.0/13
111.172.0.0/14
111.176.0.0/13
111.228.0.0/14
112.0.0.0/10
112.64.0.0/14
112.80.0.0/12
112.100.0.0/14
112.111.0.0/16
112.122.0.0/15
112.224.0.0/11
113.0.0.0/13
113.8.0.0/15
113.12.0.0/14
113.16.0.0/15
113.18.0.0/16
113.62.0.0/15
113.64.0.0/10
113.128.0.0/15
113.136.0.0/13
113.194.0.0/15
113.204.0.0/14
114.28.0.0/16
114.80.0.0/12
114.96.0.0/13
114.104.0.0/14
114.112.0.0/14
112.109.128.0/17
114.216.0.0/13
114.224.0.0/11
115.24.0.0/15
115.28.0.0/15
115.32.0.0/14
115.48.0.0/12
115.84.0.0/18
115.100.0.0/15
115.148.0.0/14
115.152.0.0/15
115.168.0.0/14
115.212.0.0/16
115.230.0.0/16
115.236.96.0/23
115.236.136.0/22
115.239.228.0/22
116.1.0.0/16
116.2.0.0/15
116.4.0.0/14
116.8.0.0/14
116.16.0.0/12
116.52.0.0/14
116.76.0.0/15
116.90.80.0/20
116.112.0.0/14
116.128.0.0/10
116.204.0.0/15
116.208.0.0/14
116.224.0.0/12
116.254.128.0/18
117.8.0.0/13
117.21.0.0/16
117.22.0.0/15
117.24.0.0/13
117.32.0.0/13
117.40.0.0/14
117.44.0.0/15
117.60.0.0/14
117.79.224.0/20
117.80.0.0/12
117.136.0.0/13
118.26.0.0/16
118.72.0.0/13
118.112.0.0/13
118.120.0.0/14
118.132.0.0/14
118.144.0.0/14
118.180.0.0/14
118.186.0.0/15
118.192.0.0/15
118.248.0.0/13
119.0.0.0/13
119.8.0.0/16
119.10.0.0/17
119.18.192.0/20
119.36.0.0/16
119.57.0.0/16
119.60.0.0/16
119.88.0.0/14
119.96.0.0/13
119.112.0.0/13
119.120.0.0/13
119.128.0.0/12
119.144.0.0/14
119.164.0.0/14
119.176.0.0/12
119.233.0.0/16
120.0.0.0/12
120.24.0.0/14
120.32.0.0/13
120.40.0.0/14
120.68.0.0/14
120.80.0.0/13
120.192.0.0/10
121.0.16.0/20
121.8.0.0/13
121.16.0.0/12
121.32.0.0/14
121.60.0.0/14
121.76.0.0/15
121.196.0.0/14
121.204.0.0/14
121.224.0.0/12
122.10.128.0/17
122.51.128.0/17
122.64.0.0/11
122.119.0.0/16
122.136.0.0/13
122.156.0.0/14
122.188.0.0/14
122.192.0.0/14
122.198.0.0/16
122.200.64.0/18
122.224.0.0/12
123.4.0.0/14
123.8.0.0/13
123.52.0.0/14
123.64.0.0/11
123.97.128.0/17
123.100.0.0/19
123.112.0.0/12
123.128.0.0/13
123.138.0.0/15
123.150.0.0/15
123.152.0.0/13
123.164.0.0/14
123.180.0.0/14
123.184.0.0/14
123.196.0.0/15
123.232.0.0/14
123.249.0.0/16
124.42.64.0/18
124.64.0.0/15
124.67.0.0/16
124.73.0.0/16
124.114.0.0/15
124.126.0.0/15
124.128.0.0/13
124.160.0.0/15
124.162.0.0/16
124.163.0.0/16
124.192.0.0/15
124.200.0.0/13
124.226.0.0/15
124.228.0.0/14
124.236.0.0/14
124.240.0.0/17
124.240.128.0/18
124.248.0.0/17
125.36.0.0/14
125.40.0.0/13
125.64.0.0/12
125.79.0.0/16
125.80.0.0/13
125.88.0.0/13
125.104.0.0/13
125.112.0.0/12
125.210.0.0/15
140.224.0.0/16
140.237.0.0/16
140.246.0.0/16
140.249.0.0/16
142.4.117.0/30
159.226.0.0/16
171.34.0.0/15
171.36.0.0/14
171.40.0.0/13
175.0.0.0/12
175.16.0.0/13
175.24.0.0/14
175.30.0.0/15
175.42.0.0/15
175.44.0.0/16
175.46.0.0/15
175.48.0.0/12
175.64.0.0/11
175.102.0.0/16
175.106.128.0/17
175.146.0.0/15
175.148.0.0/14
175.152.0.0/14
175.160.0.0/12
175.178.0.0/16
175.184.128.0/18
175.185.0.0/16
175.186.0.0/15
175.188.0.0/14
180.76.0.0/16
180.96.0.0/11
180.136.0.0/13
180.152.0.0/13
180.208.0.0/15
182.18.0.0/17
182.32.0.0/12
182.88.0.0/14
182.112.0.0/12
182.128.0.0/12
183.0.0.0/10
183.64.0.0/13
183.129.0.0/16
183.148.0.0/16
183.160.0.0/12
183.184.0.0/13
183.192.0.0/11
192.34.109.224/28
192.74.224.0/19
198.2.203.64/28
198.2.212.160/28
202.43.144.0/22
202.46.32.0/19
202.66.0.0/16
202.75.208.0/20
202.96.0.0/12
202.111.160.0/19
202.112.0.0/14
202.117.0.0/16
202.165.176.0/20
202.196.80.0/20
203.69.0.0/16
203.86.0.0/18
203.86.64.0/19
203.93.0.0/16
203.169.160.0/19
203.171.224.0/20
210.5.0.0/19
210.14.128.0/19
210.21.0.0/16
210.32.0.0/14
210.51.0.0/16
210.52.0.0/15
210.77.0.0/16
210.192.96.0/19
211.76.96.0/20
211.78.208.0/20
211.86.144.0/20
211.90.0.0/15
211.92.0.0/14
211.96.0.0/13
211.136.0.0/13
211.144.12.0/22
211.144.96.0/19
211.144.160.0/20
211.147.0.0/16
211.152.14.0/24
211.154.64.0/19
211.154.128.0/19
211.155.24.0/22
211.157.32.0/19
211.160.0.0/13
211.233.70.0/24
218.0.0.0/11
218.56.0.0/13
218.64.0.0/11
218.84.0.0/14
218.88.0.0/13
218.96.0.0/14
218.102.0.0/16
218.104.0.0/14
218.108.0.0/15
218.194.80.0/20
218.200.0.0/13
218.240.0.0/13
219.128.0.0/11
219.154.0.0/15
219.223.192.0/18
219.232.0.0/16
219.234.80.0/20
219.235.0.0/16
220.112.0.0/16
220.154.0.0/15
220.160.0.0/11
220.181.0.0/16
220.191.0.0/16
220.192.0.0/12
220.228.70.0/24
220.242.0.0/15
220.248.0.0/14
220.250.0.0/19
220.252.0.0/16
221.0.0.0/12
221.122.0.0/15
221.176.0.0/13
221.192.0.0/14
221.200.0.0/14
221.204.0.0/15
221.206.0.0/16
221.207.0.0/16
221.208.0.0/12
221.212.0.0/15
221.214.0.0/15
221.216.0.0/13
221.224.0.0/13
221.228.0.0/14
221.232.0.0/13
222.32.0.0/11
222.64.0.0/12
222.80.0.0/12
222.132.0.0/14
222.136.0.0/13
222.168.0.0/13
222.172.222.0/24
222.176.0.0/13
222.184.0.0/13
222.200.0.0/16
222.208.0.0/13
222.219.0.0/16
222.220.0.0/15
222.240.0.0/13
223.4.0.0/14
223.64.0.0/11
223.144.0.0/12
223.240.0.0/13
#china blocks end
Improve this answer
4
  • Or you can simply add CC_DENY = "CN" on /etc/csf/csf.conf and it will automatically find the Chinese prefixes based on Maxmind's GeoIP database.
    – Cha0s
    Feb 5, 2015 at 11:37
  • thanks, but I'm not sure which way consumes less server resources like CPU usage, the CC_DENY or the direct IP blocking. I would say that direct IP blocking is better.
    – user3601800
    Feb 5, 2015 at 16:38
  • I don't see any difference. Once the iptables rules are loaded (one way or another - the rules are the same essentially) the load on the system will be the same. The only difference is that your list is static (so you'll have to manually keep it up to date) while the list from the GeoIP database will be updated from time to time automatically to reflect any new or obsolete prefixes per country code. Either way when you block many prefixes with iptables, you will have an extra load on the system. The load comes from iptables themselves, not from the way you find which prefixes to block.
    – Cha0s
    Feb 5, 2015 at 17:12
  • i have to say that blocking country code CN in the csf didn't work for me, today i have found new IPs from China blocked by mod_security
    – user3601800
    Feb 6, 2015 at 17:18

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