16

Последние несколько дней я заметил, что некоторые серверы забиты неизвестными запросами.

Большинство из них похожи на следующие:

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 -

После небольшой регистрации и поиска я обнаружил, что некоторые китайские интернет-провайдеры (вероятно, CERNET по результатам whatsmydns.net) и некоторые турецкие интернет-провайдеры (вероятно, TTNET) отвечают на DNS-запросы, например, a.tracker.thepiratebay.orgс различными IP-адресами, которые не имеют ничего общего с piratebay. или торренты. Другими словами, кажется, что они делают какое-то отравление DNS-кэша по какой-то причудливой причине.

Поэтому сотни (если не тысячи) битторрент-клиентов в этих странах делают тонны «анонсов» для моих веб-серверов, что в значительной степени приводит к DDoS-атаке, заполняющей все соединения Apache.

На данный момент я полностью заблокировал Китай и Турцию, и она выполняет свою работу, но я бы хотел найти лучший способ заблокировать эти запросы.

Я думал о блокировке этих запросов с помощью mod_security на основе заголовка HTTP Host.

Все эти запросы включают, например, заголовок HTTP Host a.tracker.thepiratebay.org(или множество других поддоменов домена thepiratebay.org).

Вот дамп заголовков запросов через $_SERVERпеременную 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

Итак, мой вопрос, как я могу заблокировать входящие запросы к Apache на основе домена запроса (заголовок HTTP Host)? Имейте в виду, что запросы относятся к разным URL-адресам, а не только к /announce.php, поэтому блокировка по URL-адресу бесполезна.

Также этот подход жизнеспособен или он вызовет слишком большую нагрузку, и я должен продолжать отбрасывать эти запросы, прежде чем они достигнут Apache?

Обновить:

Оказывается, эта проблема затронула многих людей во многих странах мира.
Об этом было множество сообщений и постов в блогах, а также различные решения для блокирования этого трафика.

Я собрал некоторые отчеты, чтобы помочь любому, кто придет сюда в поисках решения, чтобы заблокировать это.

Таинственный неверно направленный китайский трафик: Как я могу узнать, какой DNS-сервер использовал HTTP-запрос?
Странная регистрация Bittorrent на моем сервере
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- давая /

apache-2.2 http mod-security bittorrent cha0s
источник

1

Я вижу похожую проблему с этим, я заблокировал запросы, но мне было интересно, как вы выяснили, какие интернет-провайдеры возвращают неправильные IP-адреса? Мне интересно узнать, откуда поступают запросы, так что это кажется хорошей отправной точкой

pogo

Согласно whatsmydns.net и другим средствам проверки распространения glbal dns, CERNET и CPIP в Китае и TTNET в Турции отвечают на запросы в различных поддоменах thepiratebay.org к различным IP-адресам, когда этот домен не разрешается ни одним другим провайдером по всей планете.

Cha0s

2

Я получаю то же самое, и это началось примерно в то же время, когда вы заметили это. facebook, битторрент, порносайты. но особенно это постоянное объявление о пиратском заливе. serverfault.com/questions/658433/… Я использую nginx и вернул 444, если хост не совпадает.

Феликс

количество запросов на объявление значительно сократилось. возможно это была временная неправильная настройка DNS. Вы все еще видите движение?

Феликс

2

Честно говоря, в конце концов я заблокировал Китай на уровне брандмауэра, потому что даже с mod_security они будут заполнять все соединения Apache. Так что я не заметил, были ли уменьшены запросы.

Cha0s

7

Та же проблема здесь. Я использую mod_security для блокировки агента пользователя

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

Я бы изменил журнал на nolog после того, как вы убедитесь, что он работает, чтобы избежать заполнения вашего файла журнала

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

user262546
источник

1

Хотя это не совсем то, что мне было нужно, ваш ответ направил меня в правильном направлении, поэтому я выбрал ваш правильный. В итоге я заблокировал все торрент-запросы, сопоставив строку «? Info_hash =» в REQUEST_URI. User-Agent был не лучшим подходом, потому что клиенты используют много разных bittorrent клиентов с разными UA. Последнее правило mod_security, с которым я закончил, SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

таково

Попробуйте dig a.tracker.thepiratebay.orgс любого DNS-сервера в этом списке public-dns.tk/nameserver/cn.html и на каждый запрос есть разные ответы. То же самое для tracker.thepiratebay.orgчего также появился в нашем Host: заголовки. На viewdns.info/research/ есть пост об этом с некоторыми дополнительными сайтами. Попытка перевернуть некоторые из возвращенных адресов, используя viewdns.info/reverseip, показывает, что это довольно случайно.

Евгений

5

У нас точно такая же проблема с одним из сайтов наших клиентов. Я добавил следующее в верхней части их:

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

Закомментированный RewriteCond может быть закомментирован, чтобы блокировать только определенный пользовательский агент. Но они не имеют никакого контента на announce или announce.php, поэтому мы просто заблокировали все это.

Дэн Армстронг
источник

Спасибо, но мне нужно решение с использованием mod_security, а не mod_rewrite.

Cha0s

см engineering.bittorrent.com/2015/01/29/... лучшего способа (G / 410 вместо F / 403, и явное ErrorDocument)

ysth

5

У меня сейчас такая же проблема, когда торрент-трекеры указывают на мой сервер. Я экспериментировал с iptables в течение последних нескольких дней, проверял заголовки и шаблоны запросов и сужал его до пары правил iptables, которые фильтруют практически весь недавний, по-видимому, вредоносный трафик из Азии (Китай, Малайзия, Япония и Гонконг).

Ниже приведены правила. Надеюсь, это кому-нибудь поможет.

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

Франци
источник

Ницца! Я не думал об этом! Благодарность! : D Вы решили REJECTвместо того, чтобы DROPпо какой-то конкретной причине? (то есть: клиенты могут остановиться после получения REJECT?)

Cha0s

1

Да, REJECT должен сказать клиенту прекратить запрашивать этот ресурс, хотя, похоже, он не помогает в этом случае. Он все еще отфильтровывает, поэтому я оставлю это как REJECT, надеясь, что некоторые клиенты поймут намек. В любом случае, iptables должен работать намного лучше, чем mod_security, поэтому я надеюсь, что он вам подходит.

Франси

Да это должно! Я блокировал все китайские префиксы. Я попробую этот подход, который лучше :) Я думаю, что клиенты bittorrent не перестанут повторять попытки даже с REJECT. Они увидят это как «отказано в соединении» и попытаются через некоторое время. Я считаю, что DROP - лучший подход (и использует меньше ресурсов - он просто отбрасывает пакеты в тот момент, когда они сопоставляются без какой-либо дальнейшей обработки)

Cha0s

1

Разница довольно незначительная на самом деле во всех случаях, кроме крайних, и я надеялся в конечном итоге сдержать движение. Если он не наберет номер, я поменяю его на DROP. Мне очень любопытно, почему и как это произошло в первую очередь. Есть некоторые дискуссии о перенаправлении Великого брандмауэра Китая на случайные IP-адреса, но я почти уверен, что это не тот случай.

Фрэнси

1

+1 Хороший. Мы собираемся с --string "GET /announce"тем, чтобы покрыть фактический запрос.

Линус Клин

5

Я написал сообщение в блоге о том, как правильно сказать клиентам BitTorrent уходить и никогда не возвращаться, подобно тому, что делал Дэн, но используя 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";
    }
}

У торрент-трекеров (обычно) есть стандартный URL-адрес, который начинается с /announceили /scrape, поэтому я бы не отказался от фильтрации по URL-адресу так быстро. Оно работает.

Полный пост находится по адресу - http://dvps.me/ddos-attack-by-torrent

Евгений
источник

1

Интересно читать. Спасибо, что поделились :) Но я считаю, что атака была вызвана тем, что DNS Cache PoisoningCERNET в Китае отвечает на домены TPB со случайными и некитайскими IP-адресами. AFAIK PEX предназначен для обмена пэрами, а не трекерами. Можете ли вы подробнее рассказать об этом или предоставить некоторую документацию?

Cha0s

Здесь описано расширение для совместного использования трекеров bittorrent.org/beps/bep_0028.html . Но вы правы в том, что заголовок «Host:» для всех этих запросов является a.tracker.thepiratebay.orgили tracker.thepiratebay.orgможет быть или не быть фактической целью этих клиентов. Это также могут быть фальшивые клиенты, просто маскирующиеся под китайских битторентов :)

Евгений

1

Биттуррент люди предлагают 410 вместо 404: engineering.bittorrent.com/2015/01/29/…

15:15

0

я взял китайские диапазоны IP-адресов с: http://www.wizcrafts.net/chinese-blocklist.html и заблокировал их в моем брандмауэре CSF, вот диапазоны на случай, если вы хотите скопировать и вставить в свой список запрещенных IP-адресов 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
источник

Или вы можете просто добавить CC_DENY = "CN"на , /etc/csf/csf.confи он будет автоматически найти китайские префиксы на основе базы данных GeoIP Maxmind в.

Cha0s

спасибо, но я не уверен, какой путь потребляет меньше ресурсов сервера, таких как загрузка процессора, CC_DENY или прямая блокировка IP. Я бы сказал, что прямая блокировка IP лучше.

user3601800

Я не вижу никакой разницы. Как только правила iptables будут загружены (так или иначе - правила одинаковы по существу), нагрузка на систему будет одинаковой. Единственное отличие состоит в том, что ваш список статичен (поэтому вам придется обновлять его вручную), в то время как список из базы данных GeoIP будет периодически обновляться автоматически, чтобы отражать любые новые или устаревшие префиксы для кода страны. В любом случае, когда вы блокируете много префиксов с помощью iptables, у вас будет дополнительная нагрузка на систему. Нагрузка исходит от самих iptables, а не от того, как вы находите префиксы для блокировки.

Cha0s

Я должен сказать, что блокировка кода страны CN в CSF у меня не сработала, сегодня я нашел новые IP-адреса из Китая, заблокированные mod_security

user3601800

Блокировка запросов mod_security по заголовку http-хоста

Обновить:

Ответы: