16

Ces derniers jours, j'ai remarqué que certains serveurs étaient soumis à des requêtes inconnues.

La plupart d'entre eux sont les suivants:

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 -

Après un peu de journalisation et de recherche, j'ai découvert que certains FAI chinois (probablement CERNET selon les résultats de whatsmydns.net) et certains FAI turcs (probablement TTNET) répondent aux requêtes DNS telles que a.tracker.thepiratebay.orgdiverses IP qui n'ont rien à voir avec piratebay ou des torrents. En d'autres termes, ils semblent faire une sorte d'empoisonnement du cache DNS pour une raison bizarre.

Ainsi, des centaines (sinon des milliers) de clients bittorrent sur ces pays font des tonnes d '«annonces» à mes serveurs Web, ce qui entraîne à peu près une attaque DDoS remplissant toutes les connexions d'Apache.

Pour le moment, j'ai complètement bloqué la Chine et la Turquie et cela fait l'affaire, mais je voudrais trouver un meilleur moyen de bloquer ces demandes.

Je pensais à bloquer ces demandes avec mod_security basé sur l'en-tête de l'hôte HTTP.

Toutes ces demandes incluent un en-tête d'hôte HTTP comme a.tracker.thepiratebay.org(ou de nombreux autres sous-domaines du domaine piratebay.org).

Voici un vidage des en-têtes de demande via la $_SERVERvariable 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

Donc, ma question est, comment puis-je bloquer les demandes entrantes vers Apache en fonction du domaine de demande (en-tête de l'hôte HTTP)? Gardez à l'esprit que les requêtes se trouvent sur différentes URL et pas seulement sur /announce.php, donc le blocage par URL n'est pas utile.

Cette approche est-elle également viable ou causera-t-elle trop de charge et je devrais continuer à supprimer ces demandes avant même qu'elles n'atteignent Apache?

Mise à jour:

Il s'avère que ce problème a touché de nombreuses personnes dans de nombreux pays du monde.
Il y a eu de nombreux rapports et articles de blog à ce sujet et diverses solutions pour bloquer ce trafic.

J'ai rassemblé certains des rapports pour aider ceux qui viennent ici à chercher une solution pour bloquer cela.

Mystérieux trafic chinois mal dirigé: comment savoir quel serveur DNS une requête HTTP a utilisé?
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-attaques-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- donnant/

apache-2.2 http mod-security bittorrent Cha0s
la source

1

Je vois un problème similaire à celui-ci, j'ai bloqué les demandes, mais je me demandais comment vous aviez déterminé quels FAI renvoyaient les adresses IP incorrectes? Je suis intéressé de savoir d'où viennent les demandes, ce qui semble être un bon point de départ

pogo

Selon whatsmydns.net et d'autres vérificateurs de propagation glbal dns, CERNET et CPIP en Chine et TTNET en Turquie répondent aux requêtes sur divers sous-domaines de thepiratebay.org vers diverses adresses IP lorsque ce domaine ne se résout pas sur aucun autre FAI de la planète.

Cha0s

2

Je reçois exactement la même chose et cela a commencé à peu près au même moment où vous l'avez remarqué. facebook, bittorrent, sites pornographiques. mais surtout cette constante baie des pirates annonce. serverfault.com/questions/658433/… J'utilise nginx et j'ai renvoyé 444 si l'hôte ne correspond pas.

felix

les demandes d'annonces ont beaucoup diminué. c'était peut-être une mauvaise configuration DNS temporaire. voyez-vous encore du trafic?

felix

2

Pour être honnête, j'ai fini par bloquer la Chine au niveau du pare-feu, car même avec mod_security, ils rempliraient toutes les connexions d'Apache. Je n'ai donc pas remarqué si les demandes avaient été réduites.

Cha0s

7

Même problème ici. J'utilise mod_security pour bloquer l'agent utilisateur

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

Je changerais le journal en nolog après avoir vérifié qu'il fonctionne pour éviter de remplir votre fichier journal

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

user262546
la source

1

Bien que ce ne soit pas exactement ce dont j'avais besoin, votre réponse m'a orienté dans la bonne direction, j'ai donc choisi la vôtre comme étant la bonne. J'ai fini par bloquer toutes les demandes de torrent en faisant correspondre la chaîne '? Info_hash =' sur la REQUEST_URI. User-Agent n'était pas la meilleure approche car les clients utilisent de nombreux clients bittorrent différents avec différents UA. La règle finale de mod_security avec laquelle je me suis retrouvé est:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

Cha0s

Essayez de dig a.tracker.thepiratebay.orgpartir de n'importe quel serveur DNS dans cette liste public-dns.tk/nameserver/cn.html et à chaque demande il y a une réponse différente. Idem pour tracker.thepiratebay.orgqui figurait également dans notre Host: en-têtes. Il y a un article à ce sujet sur viewdns.info/research/… avec quelques sites supplémentaires. Essayer d'inverser certaines des adresses retournées en utilisant viewdns.info/reverseip montre que c'est à peu près aléatoire.

Evgeny

5

Nous rencontrons exactement le même problème avec l'un des sites de nos clients. J'ai ajouté ce qui suit en haut de leur:

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

Le RewriteCond commenté peut être décommenté pour ne bloquer qu'un agent utilisateur spécifique. Mais ils n'ont aucun contenu sur announce ou announce.php, nous avons donc tout bloqué.

Dan Armstrong
la source

Merci, mais j'avais besoin d'une solution utilisant mod_security et non mod_rewrite.

Cha0s

voir engineering.bittorrent.com/2015/01/29/… pour un meilleur moyen (G / 410 au lieu de F / 403, et un ErrorDocument explicite)

ysth

5

J'ai le même problème en ce moment, ayant des trackers torrent pointant sur mon serveur. J'ai expérimenté avec iptables au cours des deux derniers jours et inspecté les en-têtes et les modèles des demandes et les ai réduits à quelques règles iptables qui filtrent à peu près tout le trafic récent apparemment malveillant en provenance d'Asie (Chine, Malaisie, Japon et Hong Kong).

Voici les règles. J'espère que cela aide quelqu'un.

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
la source

Agréable! Je n'y ai pas pensé! Merci! : D Avez-vous choisi au REJECTlieu de DROPpour une raison particulière? (c'est-à-dire: les clients peuvent arrêter après avoir reçu un REJECT?)

Cha0s

1

Oui, REJECT devrait dire au client d'arrêter de demander cette ressource bien qu'elle ne semble pas aider dans ce cas. Il le filtre toujours, donc je le laisse comme REJECT en espérant que certains clients prennent un indice. Quoi qu'il en soit, iptables devrait fonctionner beaucoup mieux que mod_security dans cette tâche, donc j'espère que cela fonctionne bien pour vous.

Franci

Oui, ça devrait! Je bloquais tous les préfixes chinois. Je vais essayer cette approche qui est meilleure :) Je pense que les clients bittorrent n'arrêteront pas de réessayer même avec REJECT. Ils verraient cela comme une «connexion refusée» et réessayeraient après un certain temps. Je crois que DROP est une meilleure approche (et utilise moins de ressources - il supprime simplement les paquets au moment où ils sont appariés sans autre traitement)

Cha0s

1

La différence est en fait assez négligeable dans tous les cas, sauf dans les cas extrêmes, et mon espoir était de dissuader éventuellement le trafic. S'il ne compose pas, je le changerai en DROP. Je suis très curieux de savoir pourquoi ou comment cela s'est produit en premier lieu. Il y a des discussions sur la redirection du Grand Pare-feu de Chine vers des adresses IP aléatoires, mais je suis sûr que ce n'est pas le cas ici.

Franci

1

+1 Sympa. Nous allons --string "GET /announce"cependant avec pour couvrir la demande réelle .

Linus Kleen

5

J'ai écrit un article de blog sur la façon de dire correctement aux clients BitTorrent de partir et de ne jamais revenir, similaire à ce que Dan a fait, mais en utilisant 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";
    }
}

Les trackers torrent (généralement) ont une URL standard qui commence par /announceou /scrape, donc je ne rejetterais pas le filtrage par URL si rapidement. Ça marche.

Le post complet est à - http://dvps.me/ddos-attack-by-torrent

Evgeny
la source

1

Lecture intéressante. Merci pour le partage :) Mais je pense que l'attaque a été provoquée par le fait DNS Cache Poisoningque CERNET en Chine répond aux domaines TPB avec des adresses IP aléatoires et non chinoises. AFAIK PEX est pour partager des pairs, pas des trackers. Pouvez-vous nous en dire plus à ce sujet ou fournir de la documentation?

Cha0s

Il existe une extension pour le partage des trackers décrite ici bittorrent.org/beps/bep_0028.html . Mais vous avez raison en ce que l'en-tête «Host:» pour toutes ces demandes est a.tracker.thepiratebay.orgou tracker.thepiratebay.orgpourrait être ou non la cible réelle de ces clients. Il peut aussi s'agir de faux clients se faisant passer pour des bittorents chinois :)

Evgeny

1

les gens de bittorrent suggèrent 410 au lieu de 404: engineering.bittorrent.com/2015/01/29/…

ysth

0

j'ai pris les plages IP chinoises de: http://www.wizcrafts.net/chinese-blocklist.html et les ai bloquées dans mon pare-feu csf, voici les plages au cas où vous voudriez copier et coller dans votre liste ip de refus 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
la source

Ou vous pouvez simplement ajouter CC_DENY = "CN"sur /etc/csf/csf.confet il détectera automatiquement les préfixes chinois sur la base de la base de données GeoIP de Maxmind.

Cha0s

merci, mais je ne sais pas dans quel sens consomme moins de ressources de serveur comme l'utilisation du processeur, le CC_DENY ou le blocage IP direct. Je dirais que le blocage IP direct est meilleur.

user3601800

Je ne vois aucune différence. Une fois que les règles iptables sont chargées (d'une manière ou d'une autre - les règles sont essentiellement les mêmes), la charge sur le système sera la même. La seule différence est que votre liste est statique (vous devrez donc la tenir à jour manuellement) tandis que la liste de la base de données GeoIP sera mise à jour de temps en temps automatiquement pour refléter tout préfixe nouveau ou obsolète par code de pays. Quoi qu'il en soit, lorsque vous bloquez de nombreux préfixes avec iptables, vous aurez une charge supplémentaire sur le système. La charge vient d'iptables eux-mêmes, pas de la façon dont vous trouvez les préfixes à bloquer.

Cha0s

je dois dire que le blocage du code de pays CN dans le csf n'a pas fonctionné pour moi, aujourd'hui j'ai trouvé de nouvelles adresses IP en provenance de Chine bloquées par mod_security

user3601800

demandes de bloc mod_security par en-tête d'hôte http

Mise à jour:

Réponses: