16

Los últimos días noté que algunos servidores estaban siendo abarrotados con solicitudes desconocidas.

La mayoría de ellos son como los siguientes:

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 -

Después de un poco de registro y búsqueda, descubrí que algunos ISP chinos (probablemente CERNET según los resultados de whatsmydns.net) y algunos ISP turcos (probablemente TTNET) responden a consultas de DNS, como a.tracker.thepiratebay.orgcon varias IP que no tienen nada que ver con piratebay o torrentes. En otras palabras, parecen hacer algún tipo de envenenamiento de caché de DNS por alguna extraña razón.

Entonces, cientos (si no miles) de clientes bittorrent en esos países hacen toneladas de 'anuncios' a mis servidores web que resultan en un ataque DDoS que llena todas las conexiones de Apache.

En este momento bloqueé China y Turquía por completo y hace el trabajo, pero me gustaría encontrar una mejor manera de bloquear esas solicitudes.

Estaba pensando en bloquear esas solicitudes con mod_security basado en el encabezado HTTP Host.

Todas esas solicitudes incluyen un encabezado HTTP Host como a.tracker.thepiratebay.org(o muchos otros subdominios del dominio thepiratebay.org).

Aquí hay un volcado de los encabezados de solicitud a través de la $_SERVERvariable de 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

Entonces, mi pregunta es, ¿cómo puedo bloquear las solicitudes entrantes a Apache en función del dominio de solicitud (encabezado de host HTTP)? Tenga en cuenta que las solicitudes se encuentran en varias URL, no solo /announce.php, por lo que el bloqueo por URL no es útil.

¿También es viable ese enfoque o causará demasiada carga y debería seguir descartando esas solicitudes incluso antes de que lleguen a Apache?

Actualizar:

Resulta que este problema ha afectado a muchas personas en muchos países del mundo.
Ha habido numerosos informes y publicaciones de blog al respecto y varias soluciones para bloquear este tráfico.

He recopilado algunos de los informes para ayudar a cualquiera que venga a buscar una solución para bloquear esto.

Misterioso tráfico chino mal dirigido: ¿Cómo puedo saber qué servidor DNS utilizó una solicitud HTTP?
Registro extraño de Bittorrent en mi 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
fuente

1

Estoy viendo un problema similar a esto, he bloqueado las solicitudes, pero me preguntaba cómo había descubierto qué ISP estaban devolviendo las direcciones IP incorrectas. Me interesa saber de dónde provienen las solicitudes, por lo que parece un buen punto de partida

Pogo

Según whatsmydns.net y otros verificadores de propagación de glbal dns, CERNET y CPIP en China y TTNET en Turquía responden a consultas en varios subdominios de thepiratebay.org a varias IP cuando ese dominio no se resuelve en ningún otro ISP del planeta.

Cha0s

2

Estoy obteniendo exactamente lo mismo y comenzó casi al mismo tiempo que lo notaste. facebook, bittorrent, sitios porno. pero sobre todo este anuncio constante de la bahía pirata. serverfault.com/questions/658433/… Estoy usando nginx y he devuelto 444 si el host no coincide.

Felix

Las solicitudes de anuncio se han reducido bastante. tal vez fue una mala configuración temporal de DNS. ¿sigues viendo tráfico?

Felix

2

Para ser honesto, terminé bloqueando China en el nivel de firewall después de todo porque incluso con mod_security llenarían todas las conexiones de Apache. Así que no me he dado cuenta si las solicitudes se han reducido.

Cha0s

7

Mismo problema aquí. Estoy usando mod_security para bloquear el agente de usuario

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

Cambiaría el registro a nolog después de verificar que está funcionando para evitar llenar su archivo de registro

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

usuario262546
fuente

1

Aunque no era exactamente lo que necesitaba, su respuesta me condujo a la dirección correcta, así que elegí la suya como la correcta. Terminé bloqueando todas las solicitudes de torrent haciendo coincidir la cadena '? Info_hash =' en REQUEST_URI. User-Agent no fue el mejor enfoque porque los clientes usan muchos clientes bittorrent diferentes con diferentes UA. La regla final de mod_security con la que terminé es:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

Cha0s

Intente dig a.tracker.thepiratebay.orgdesde cualquier servidor DNS en esta lista public-dns.tk/nameserver/cn.html y en cada solicitud hay una respuesta diferente. Lo mismo para lo tracker.thepiratebay.orgque también apareció en nuestro Host: encabezados. Hay una publicación al respecto en viewdns.info/research/… con algunos sitios adicionales. Intentar revertir algunas de las direcciones devueltas usando viewdns.info/reverseip muestra que es bastante aleatorio.

Evgeny

5

Estamos experimentando exactamente el mismo problema con uno de los sitios de nuestros clientes. Agregué lo siguiente cerca de la parte superior de su:

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

El RewriteCond comentado puede ser descomentado para bloquear solo un agente de usuario específico. Pero no tienen contenido en el anuncio o el anuncio.php, así que simplemente lo bloqueamos todo.

Dan Armstrong
fuente

Gracias, pero necesitaba una solución usando mod_security y no mod_rewrite.

Cha0s

ver engineering.bittorrent.com/2015/01/29/… para una mejor manera (G / 410 en lugar de F / 403, y un ErrorDocument explícito)

ysth

5

Tengo el mismo problema en este momento, los rastreadores de torrents apuntan a mi servidor. Experimenté con iptables durante los últimos días e inspeccioné los encabezados y patrones de las solicitudes y lo reduje a un par de reglas de iptables que filtran prácticamente todo el tráfico reciente aparentemente malicioso de Asia (China, Malasia, Japón y Hong Kong).

Debajo están las reglas. Espero que ayude a alguien.

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
fuente

¡Agradable! ¡No pensé en eso! ¡Gracias! : D ¿Elegiste hacerlo en REJECTlugar de DROPpor alguna razón en particular? (es decir: los clientes pueden detenerse después de recibir una REJECT?)

CHA0S

1

Sí, RECHAZAR debería decirle al cliente que deje de solicitar ese recurso, aunque en este caso no parece estar ayudando. Todavía lo filtra, así que lo dejaré como RECHAZAR con la esperanza de que algunos clientes lo entiendan. De cualquier manera, iptables debería funcionar mucho mejor que mod_security en esta tarea, por lo que espero que funcione bien para usted.

Franci

Yeap debería! Estaba bloqueando todos los prefijos chinos. Probaré este enfoque que es mejor :) Creo que los clientes bittorrent no dejarán de volver a intentarlo incluso con REJECT. Lo verían como "conexión rechazada" y volverían a intentarlo después de un tiempo. Creo que DROP es un mejor enfoque (y utiliza menos recursos; simplemente descarta los paquetes en el momento en que se combinan sin ningún procesamiento adicional)

Cha0s

1

La diferencia es realmente insignificante en todos los casos, excepto en casos extremos, y mi esperanza era disuadir el tráfico. Si no se marca, lo cambiaré a DROP. Sin embargo, tengo mucha curiosidad sobre por qué o cómo sucedió esto. Hay algunas discusiones sobre el Gran Firewall de China que redirige a direcciones IP aleatorias, pero estoy bastante seguro de que este no es el caso aquí.

Franci

1

+1 Nice one. Sin --string "GET /announce"embargo, vamos a cubrir la solicitud real .

Linus Kleen

5

Escribí una publicación de blog sobre cómo decirle correctamente a los clientes de BitTorrent que se vayan y que nunca regresen, similar a lo que hizo Dan, pero usando 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";
    }
}

Los rastreadores de torrents (generalmente) tienen una URL estándar que comienza con /announceo /scrape, por lo que no descartaría el filtrado por URL tan rápido. Funciona.

La publicación completa está en: http://dvps.me/ddos-attack-by-torrent

Evgeny
fuente

1

LecturA INTERESANTE. Gracias por compartir :) Pero creo que el ataque fue inducido por el hecho de DNS Cache Poisoningque CERNET en China responde a dominios TPB con IPs aleatorias y no chinas. AFAIK PEX es para compartir compañeros, no rastreadores. ¿Puedes dar más detalles sobre eso o proporcionar alguna documentación?

Cha0s

Hay una extensión para compartir rastreadores que se describe aquí bittorrent.org/beps/bep_0028.html . Pero tiene razón en que el encabezado 'Host:' para todas estas solicitudes es a.tracker.thepiratebay.orgo tracker.thepiratebay.orgpuede ser o no el objetivo real de estos clientes. También pueden ser clientes falsos que se enmascaran como bittorents chinos :)

Evgeny

1

la gente de bittorrent sugiere 410 en lugar de 404: engineering.bittorrent.com/2015/01/29/…

ysth

0

tomé los rangos de ip chinos de: http://www.wizcrafts.net/chinese-blocklist.html y los bloqueé en mi cortafuegos csf, aquí están los rangos en caso de que desee copiar y pegar en su lista de denegación de ip de 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
fuente

O simplemente puede añadir CC_DENY = "CN"en /etc/csf/csf.confy encontrará automáticamente los prefijos chinos basados en la base de datos GeoIP de MaxMind.

Cha0s

gracias, pero no estoy seguro de qué manera consume menos recursos del servidor, como el uso de la CPU, el CC_DENY o el bloqueo directo de IP. Yo diría que el bloqueo directo de IP es mejor.

user3601800

No veo ninguna diferencia Una vez que se cargan las reglas de iptables (de una forma u otra, las reglas son esencialmente las mismas) la carga en el sistema será la misma. La única diferencia es que su lista es estática (por lo que deberá mantenerla actualizada manualmente), mientras que la lista de la base de datos GeoIP se actualizará periódicamente para reflejar los prefijos nuevos u obsoletos por código de país. De cualquier manera, cuando bloquee muchos prefijos con iptables, tendrá una carga adicional en el sistema. La carga proviene de iptables, no de la forma en que encuentra qué prefijos bloquear.

Cha0s

Tengo que decir que bloquear el código de país CN en el csf no funcionó para mí, hoy he encontrado nuevas IP de China bloqueadas por mod_security

user3601800

solicitudes de bloqueo de mod_security por encabezado http-host

Actualizar:

Respuestas: