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 -

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

Тож сотні (якщо не тисячі) клієнтів бітторентів у цих країнах роблять безліч "анонсів" для моїх веб-серверів, внаслідок чого DDOS-атака заповнює всі з'єднання Apache.

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

Я думав заблокувати ці запити mod_security на основі заголовка HTTP Host.

Усі ці запити включають заголовок HTTP-хоста, як-от 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 header)? Майте на увазі, що запити містяться на різних 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-атаки-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-адреси? Мені цікаво дізнатись, звідки надходять запити, що здається гарним початковим пунктом

— пого

За даними whatsmydns.net та іншими перевіряючими поширення glbal dns, CERNET і CPIP в Китаї та TTNET в Туреччині відповідають на запити різних піддоменів thepiratebay.org до різних IP-адрес, коли цей домен не вирішується в будь-якому іншому провайдері по всій планеті.

— Cha0s

2

Я отримую абсолютно те саме, і воно почалося приблизно в той же час, коли ви це помітили. facebook, bittorrent, порно сайти. але найбільш помітно цю постійну піратську бухту. serverfault.com/questions/658433/… Я використовую nginx, і я повернув 444, якщо хост не відповідає.

— felix

запити оголосити зменшилися зовсім небагато. можливо, це була тимчасова неправильна конфігурація DNS. Ви все ще бачите трафік?

— Фелікс

2

Якщо чесно, я врешті-решт заблокував Китай на рівні брандмауера, оскільки навіть за умови mod_security вони заповнили б усі з'єднання Apache. Тож я не помітив, чи зменшувались запити.

— Ча0с

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'"

— користувач262546
джерело

1

Незважаючи на те, що мені було потрібно, ваша відповідь спрямовувала мене в правильному напрямку, тому я вибрав вашу як правильну. Я заблокував усі запити на торрент, збігаючи рядок '? Info_hash =' на REQUEST_URI. Користувач-агент не був найкращим підходом, оскільки клієнти використовують безліч різних клієнтів бітторентів з різними UA. Остаточне правило mod_security я закінчив з це:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

— cha0s

Спробуйте dig a.tracker.thepiratebay.orgз будь-якого сервера DNS у цьому списку public-dns.tk/nameserver/cn.html, і на кожен запит є різна відповідь. Те саме, tracker.thepiratebay.orgщо з’явилося і в нашому Господарі: заголовки. Про це є публікація на 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 може коментувати лише блокування конкретного користувача-агента. Але у них немає контенту на оголошення або оголошення.php, тому ми просто заблокували це все.

— Ден Армстронг
джерело

Дякую, але мені було потрібно рішення, використовуючи mod_security, а не mod_rewrite.

— Ча0с

см 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 повинен сказати клієнтові припинити запитувати цей ресурс, хоча він, мабуть, не допомагає в цьому випадку. Він все ще відфільтровує його, тому я залишу це ЗАМОВЛЕНО, сподіваючись, що деякі клієнти підкажуть. У будь-якому випадку, iptables повинні виконувати набагато краще, ніж mod_security при цьому завданні, тому я сподіваюся, що він працює добре для вас.

— Франці

Так, треба! Я блокував усі китайські префікси. Я спробую такий підхід, який є кращим :) Я думаю, що клієнти, що користуються bittorrent, не перестануть повторюватись навіть з REJECT. Вони вважали б це "відмовою у зв'язку" і через деякий час повторяться. Я вважаю, що DROP - це кращий підхід (і використовує менше ресурсів - він просто скидає пакети в той момент, коли вони підходять без будь-якої подальшої обробки)

— Cha0s

1

Різниця є фактично незначною у всіх, крім крайніх випадках, і я сподівався, що врешті-решт стримувати трафік. Якщо він не набирає номер, я зміню його на DROP. Мені дуже цікаво, чому або як це сталося в першу чергу. Є деякі дискусії щодо того, що Великий Брандмауер Китаю перенаправляється на випадкові ІС, але я впевнений, що це не так.

— Franci

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 призначений для обміну однолітками, а не трекерами. Чи можете ви детальніше про це детальніше розповісти або надати якусь документацію?

— Ча0с

Існує розширення для обміну трекерами, описане тут bittorrent.org/beps/bep_0028.html . Але ви вірні в тому, що заголовок "Хост:" для всіх цих запитів є a.tracker.thepiratebay.orgабо tracker.thepiratebay.orgможе бути фактичною ціллю цих клієнтів. Це також можуть бути фальшиві клієнти, що просто маскують себе як китайські бітторенти :)

— Євген

1

люди з бітторентом пропонують 410 замість 404: Engineering.bittorrent.com/2015/01/29/…

— ysth

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, а не від того, як ви знаходите, які префікси блокувати.

— Ча0с

я мушу сказати, що блокування коду країни CN у CSF не спрацювало для мене, сьогодні я знайшов нові IP-адреси з Китаю, заблоковані mod_security

— user3601800

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

Оновлення: