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- давая /

— 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-хоста

Обновить: