Solicitações de bloco mod_security pelo cabeçalho do host http

16

Nos últimos dias, notei alguns servidores sendo atacados com solicitações desconhecidas.

A maioria deles é como o seguinte:

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 -

Após um pouco de registro e pesquisa, descobri que alguns ISPs chineses (provavelmente CERNET de acordo com os resultados de whatsmydns.net) e alguns ISP turcos (provavelmente TTNET) respondem a consultas de DNS, como a.tracker.thepiratebay.orgem vários IPs que não têm nada a ver com piratebay ou torrents. Em outras palavras, eles parecem fazer algum tipo de envenenamento de cache DNS por algum motivo bizarro.

Portanto, centenas (se não milhares) de clientes bittorrent nesses países fazem toneladas de 'anúncios' para meus servidores da Web, que resultam praticamente em um ataque DDoS preenchendo todas as conexões do Apache.

No momento, bloqueei completamente a China e a Turquia e ele faz o trabalho, mas gostaria de encontrar uma maneira melhor de bloquear esses pedidos.

Eu estava pensando em bloquear essas solicitações com mod_security com base no cabeçalho HTTP Host.

Todas essas solicitações incluem um cabeçalho de host HTTP como a.tracker.thepiratebay.org(ou muitos outros subdomínios do domínio thepiratebay.org).

Aqui está um despejo dos cabeçalhos da solicitação via $_SERVERvariável do PHP .

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

Portanto, minha pergunta é: como posso bloquear solicitações recebidas para o Apache com base no domínio da solicitação (cabeçalho do host HTTP)? Lembre-se de que as solicitações estão em vários URLs, não apenas no /announce.php; portanto, o bloqueio por URL não é útil.

Além disso, essa abordagem é viável ou causará muita carga e devo continuar descartando essas solicitações antes que elas cheguem ao Apache?

Atualizar:

Acontece que esse problema afetou muitas pessoas em muitos países ao redor do mundo.
Existem inúmeros relatórios e postagens de blog sobre o assunto e várias soluções para bloquear esse tráfego.

Reunimos alguns dos relatórios para ajudar quem vem aqui procurando uma solução para bloquear isso.

Misterioso tráfego chinês mal direcionado: como posso descobrir qual servidor DNS uma solicitação HTTP usou?
Logon Bittorrent estranho no meu servidor
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-attack-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- dando /

apache-2.2 http mod-security bittorrent Cha0s
fonte
11
Estou vendo um problema semelhante a esse, bloqueei as solicitações, mas fiquei imaginando como você descobriria quais ISPs estavam retornando os endereços IP incorretos. Estou interessado em saber onde as solicitações são provenientes de modo que parece ser um bom ponto de partida
pogo
De acordo com whatsmydns.net e outros verificadores de propagação glbal dns, CERNET e CPIP na China e TTNET na Turquia respondem a consultas em vários subdomínios do thepiratebay.org a vários IPs quando esse domínio não é resolvido em nenhum outro provedor de serviços de Internet no mundo.
usar o seguinte comando
2
Estou recebendo exatamente a mesma coisa e tudo começou na mesma hora em que você percebeu. facebook, bittorrent, sites pornográficos. mas o mais notável é esse anúncio constante de pirate bay. serverfault.com/questions/658433/… Estou usando o nginx e retornei 444 se o host não corresponder.
Felix
os pedidos de anúncio foram reduzidos um pouco. talvez tenha sido uma configuração incorreta temporária de DNS. você ainda está vendo tráfego?
Felix
2
Para ser sincero, acabei bloqueando a China no nível do firewall, afinal, mesmo com mod_security eles preenchiam todas as conexões do Apache. Portanto, eu não notei se os pedidos foram reduzidos.
usar o seguinte comando

Respostas:

7

O mesmo problema aqui. Estou usando o mod_security para bloquear o agente do usuário

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

Eu alteraria o log para nolog depois de verificar se está funcionando para evitar o preenchimento do seu arquivo de log

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,nolog,msg:'Bittorrent Hit Detected'"
user262546
fonte
11
Embora não seja exatamente o que eu precisava, sua resposta me guiou na direção certa, por isso escolhi a sua como a correta. Acabei bloqueando todas as solicitações de torrent, correspondendo à string '? Info_hash =' no REQUEST_URI. O User-Agent não foi a melhor abordagem, porque os clientes usam muitos clientes bittorrent diferentes com diferentes UAs. A regra final sobre mod_security com a qual eu terminei é:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"
Cha0s
Tente dig a.tracker.thepiratebay.orgde qualquer servidor DNS nesta lista public-dns.tk/nameserver/cn.html e em cada solicitação há uma resposta diferente. O mesmo para o tracker.thepiratebay.orgqual também apareceu em nosso Anfitrião: cabeçalhos. Há um post sobre isso em viewdns.info/research/… com alguns sites adicionais. Tentar reverter alguns dos endereços retornados usando viewdns.info/reverseip mostra que é praticamente aleatório.
Evgeny
5

Estamos enfrentando exatamente o mesmo problema em um dos sites de nossos clientes. Eu adicionei o seguinte próximo ao topo deles:

# 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>

O RewriteCond comentado pode ser descomentado para bloquear apenas um agente de usuário específico. Mas eles não têm conteúdo em anunciar ou anuncie.php, então apenas bloqueamos tudo.

Dan Armstrong
fonte
Obrigado, mas eu precisava de uma solução usando mod_security e não mod_rewrite.
usar o seguinte comando
consulte o site engineering.bittorrent.com/2015/01/29/… para obter uma maneira melhor (G / 410 em vez de F / 403 e um ErrorDocument explícito)
ysth
5

Estou tendo o mesmo problema no momento, tendo rastreadores de torrents apontados para o meu servidor. Eu experimentei o iptables nos últimos dias e examinei os cabeçalhos e os padrões das solicitações e reduzi-o a algumas regras do iptables que filtram praticamente todo o tráfego aparentemente malicioso recente da Ásia (China, Malásia, Japão e Hong Kong).

Abaixo estão as regras. Espero que ajude alguém.

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
fonte
Agradável! Eu não pensei nisso! Obrigado! : D Você escolheu em REJECTvez de, DROPpor algum motivo específico? (ou seja: os clientes podem parar depois de receber uma REJECT?)
Cha0s
11
Sim, REJECT deve dizer ao cliente para parar de solicitar esse recurso, embora não pareça estar ajudando nesse caso. Ele ainda o filtra, então eu o deixarei como REJECT, esperando que alguns clientes tenham uma dica. De qualquer forma, o iptables deve ter um desempenho muito melhor que o mod_security nesta tarefa, então espero que funcione bem para você.
31 de
Sim deveria! Eu estava bloqueando todos os prefixos chineses. Vou tentar esta abordagem que é melhor :) Eu acho que os clientes bittorrent não param de tentar novamente, mesmo com REJECT. Eles veriam isso como 'conexão recusada' e tentariam novamente depois de um tempo. Acredito GOTA é uma abordagem melhor (e usa menos recursos - ele simplesmente elimina os pacotes no momento em que se combinava sem qualquer processamento adicional)
Cha0s
11
A diferença é bastante insignificante, na verdade, em todos os casos, exceto nos extremos, e minha esperança era deter o tráfego. Se não discar, mudarei para DROP. Estou muito curioso para saber por que ou como isso aconteceu em primeiro lugar. Há algumas discussões sobre o redirecionamento do Great Firewall da China para IPs aleatórios, mas tenho certeza de que esse não é o caso aqui.
Franci
11
+1 Bom. No --string "GET /announce"entanto, vamos cobrir o pedido real .
Linus Kleen
5

Eu escrevi um post sobre como dizer aos clientes do BitTorrent para ir embora e nunca mais voltar, semelhante ao que Dan fez, mas usando o 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";
    }
}

Os rastreadores de torrents (normalmente) têm um URL padrão que começa com /announceou /scrape, portanto, eu não descartaria a filtragem por URL tão rapidamente. Funciona.

A publicação completa está em - http://dvps.me/ddos-attack-by-torrent

Evgeny
fonte
11
Leitura interessante. Obrigado por compartilhar :) Mas acredito que o ataque foi induzido por meio do DNS Cache PoisoningCERNET na China responder a domínios TPB com IPs aleatórios e não chineses. O AFAIK PEX é para compartilhar pares, não rastreadores. Você pode elaborar mais sobre isso ou fornecer alguma documentação?
usar o seguinte comando
Há uma extensão para compartilhar rastreadores descrita aqui bittorrent.org/beps/bep_0028.html . Mas você está certo de que o cabeçalho 'Host:' para todas essas solicitações é a.tracker.thepiratebay.orgou tracker.thepiratebay.orgpode ser ou não o destino real desses clientes. Ele também pode ser clientes falsificados apenas mascarando-se como bittorents chineses :)
Evgeny
11
o pessoal do bittorrent sugere 410 em vez de 404: engineering.bittorrent.com/2015/01/29/…
ysth
0

Eu peguei os intervalos de ip em chinês em: http://www.wizcrafts.net/chinese-blocklist.html e os bloquei no meu firewall csf, aqui estão os intervalos no caso de você querer copiar e colar na sua lista de negar ip do 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
fonte
Ou você pode simplesmente adicionar CC_DENY = "CN"no /etc/csf/csf.confe ele irá localizar automaticamente os prefixos chineses com base no banco de dados de GeoIP de MaxMind.
Página
obrigado, mas não tenho certeza de que maneira consome menos recursos do servidor, como o uso da CPU, o CC_DENY ou o bloqueio direto de IP. Eu diria que o bloqueio direto de IP é melhor.
user3601800
Não vejo diferença. Depois que as regras do iptables forem carregadas (de uma maneira ou de outra - as regras são essencialmente as mesmas), a carga no sistema será a mesma. A única diferença é que sua lista é estática (portanto, você deve atualizá-la manualmente), enquanto a lista do banco de dados GeoIP será atualizada periodicamente automaticamente para refletir quaisquer prefixos novos ou obsoletos por código de país. De qualquer maneira, ao bloquear muitos prefixos com o iptables, você terá uma carga extra no sistema. A carga vem do próprio iptables, não da maneira como você encontra quais prefixos bloquear.
Página
eu tenho que dizer que o bloqueio código de país CN no LCR não funcionou para mim, hoje eu encontrei novos IPs da China bloqueada por mod_security
user3601800