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/

Community
  • 1
Cha0s
  • 2,432
  • 2
  • 15
  • 26
  • 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 09 '15 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 09 '15 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. http://serverfault.com/questions/658433/mysterious-misdirected-traffic-how-can-i-find-out-what-dns-server-an-http-requ?lq=1 I'm using nginx and I've returned 444 if the host doesn't match. – Chris Sattinger Jan 09 '15 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 '15 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 '15 at 14:03
  • http://viewdns.info/research/dns-cache-poisoning-in-the-peoples-republic-of-china/ – Evgeny Jan 23 '15 at 07:49
  • The question at http://serverfault.com/questions/658433/ contains the answer using nginx, blocking requests based on the ```Host``` header. – Evgeny Jan 23 '15 at 08:33

5 Answers5

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'"
user262546
  • 86
  • 1
  • 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 06 '15 at 13:24
  • Try to ```dig a.tracker.thepiratebay.org``` from any DNS server in this list http://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 http://viewdns.info/research/dns-cache-poisoning-in-the-peoples-republic-of-china/ with some additional sites. Trying to reverse some of the returned addresses using http://viewdns.info/reverseip/ shows that its pretty much random. – Evgeny Jan 22 '15 at 01: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.

Dan Armstrong
  • 51
  • 1
  • Thanks, but I needed a solution using mod_security and not mod_rewrite. – Cha0s Jan 06 '15 at 13:25
  • see http://engineering.bittorrent.com/2015/01/29/a-note-on-the-ddos-attacks/ for a better way (G/410 instead of F/403, and an explicit ErrorDocument) – ysth Feb 23 '15 at 18:17
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

Evgeny
  • 589
  • 5
  • 10
  • 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 '15 at 17:04
  • There is an extension for sharing trackers described here http://www.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 '15 at 17:25
  • 1
    the bittorrent folks suggest 410 instead of 404: http://engineering.bittorrent.com/2015/01/29/a-note-on-the-ddos-attacks/ – ysth Feb 23 '15 at 18:19
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
Franci
  • 51
  • 2
  • 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 '15 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 '15 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 '15 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 '15 at 19:54
  • 1
    +1 Nice one. We're going with `--string "GET /announce"` though, to cover the *actual* request. – Linus Kleen Jan 27 '15 at 12:38
  • Any reason why this might not work? I added `-A INPUT -p tcp --dport 80 -m string --algo bm --string "Bittorrent" --to 1000 -j DROP ` to my firewall rules file and updated the firewall with `/sbin/iptables-restore < /etc/iptables.firewall.rules` but i'm still seeing bittorrent traffic in my Apache logs like: `[27/Apr/2015:10:10:44 +1200] "GET /announce?info_hash=%2500m%25DDI%250E%250B%2512g6Y%25C6%259C%259E%25AE%25AE%25C4%2526%2509%2524Z&peer_id=%252DSD0100%252DQ%25BD%2$` – Projectile Fish Apr 26 '15 at 22:22
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
user3601800
  • 1
  • 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 05 '15 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 05 '15 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 05 '15 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 06 '15 at 17:18