16

Vài ngày qua tôi nhận thấy một số máy chủ bị tấn công với các yêu cầu không xác định.

Hầu hết trong số họ là như sau:

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 -

Sau một chút đăng nhập và tìm kiếm, tôi phát hiện ra rằng một số ISP Trung Quốc (có thể là CERNET theo kết quả của whatsmydns.net) và một số ISP Thổ Nhĩ Kỳ (có thể là TTNET) trả lời các truy vấn dns như a.tracker.thepiratebay.orgvới các IP khác nhau không liên quan đến piratebay hoặc torrent. Nói cách khác, họ dường như thực hiện một số loại Ngộ độc DNS Cache vì một lý do kỳ quái.

Vì vậy, hàng trăm (nếu không phải hàng ngàn) khách hàng bittorrent trên các quốc gia đó tạo ra hàng tấn 'thông báo' cho máy chủ web của tôi, điều này dẫn đến khá nhiều cuộc tấn công DDoS làm đầy tất cả các kết nối của Apache.

Hiện tại tôi đã chặn Trung Quốc và Thổ Nhĩ Kỳ hoàn toàn và nó thực hiện công việc, nhưng tôi muốn tìm một cách tốt hơn để chặn các yêu cầu đó.

Tôi đã nghĩ đến việc chặn các yêu cầu đó bằng mod_security dựa trên tiêu đề Máy chủ HTTP.

Tất cả các yêu cầu đó bao gồm tiêu đề Máy chủ HTTP như a.tracker.thepiratebay.org(hoặc nhiều tên miền phụ khác của tên miền thepiratebay.org).

Đây là một bãi chứa các tiêu đề yêu cầu thông qua $_SERVERbiến của 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

Vì vậy, câu hỏi của tôi là, làm cách nào tôi có thể chặn các yêu cầu đến Apache dựa trên miền yêu cầu (tiêu đề Máy chủ HTTP)? Hãy nhớ rằng các yêu cầu nằm trên nhiều URL khác nhau không chỉ là /announce.php nên việc chặn bằng URL không hữu ích.

Ngoài ra, cách tiếp cận đó có khả thi hay nó sẽ gây ra quá nhiều tải và tôi nên tiếp tục bỏ các yêu cầu đó trước khi chúng đến được Apache?

Cập nhật:

Hóa ra vấn đề này đã ảnh hưởng đến nhiều người ở nhiều quốc gia trên toàn cầu.
Đã có nhiều báo cáo và blogpost về nó và các giải pháp khác nhau để chặn lưu lượng truy cập này.

Tôi đã thu thập một số báo cáo để giúp bất kỳ ai đến đây tìm kiếm giải pháp để chặn điều này.

Lưu lượng truy cập Trung Quốc sai lầm bí ẩn: Làm cách nào tôi có thể tìm ra máy chủ DNS mà yêu cầu HTTP được sử dụng?
Nhật ký Bittorrent kỳ lạ trên máy chủ của tôi
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-nhiên liệu-chinese-ddos-tấn-150.124 /
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- cho /

— Cha0
nguồn

1

Tôi đang gặp một vấn đề tương tự như vậy, tôi đã chặn các yêu cầu nhưng tôi tự hỏi làm thế nào bạn tìm ra ISP nào đang trả lại địa chỉ IP không chính xác? Tôi muốn tìm hiểu xem các yêu cầu đến từ đâu để có vẻ như là một điểm khởi đầu tốt

— pogo

Theo whatsmydns.net và các công cụ kiểm tra tuyên truyền glbal dns khác, CERNET và CPIP tại Trung Quốc và TTNET tại Thổ Nhĩ Kỳ trả lời các truy vấn trên các tên miền phụ khác nhau của thepiratebay.org cho các IP khác nhau khi tên miền đó không giải quyết trên bất kỳ ISP nào khác trên hành tinh.

— Cha0s

2

Tôi đang nhận được điều tương tự chính xác và nó bắt đầu về cùng lúc bạn nhận thấy nó. facebook, bittorrent, trang web khiêu dâm. nhưng đáng chú ý nhất là vịnh cướp biển liên tục này thông báo. serverfault.com/questions/658433/ ( Tôi đang sử dụng nginx và tôi đã trả lại 444 nếu máy chủ không khớp.

— felix

các yêu cầu thông báo đã giảm đi một chút. có lẽ đó là một cấu hình sai DNS tạm thời. bạn vẫn thấy giao thông chứ?

— felix

2

Thành thật mà nói, cuối cùng tôi đã chặn Trung Quốc ở cấp độ tường lửa bởi vì ngay cả với mod_security họ cũng sẽ lấp đầy tất cả các kết nối của Apache. Vì vậy, tôi đã không nhận thấy nếu các yêu cầu đã được giảm.

— Cha0s

7

Vấn đề tương tự ở đây. Tôi đang sử dụng mod_security để chặn tác nhân người dùng

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

Tôi sẽ thay đổi nhật ký thành nolog sau khi bạn xác minh nó đang hoạt động để tránh điền vào tệp nhật ký của bạn

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

— người dùng262546
nguồn

1

Mặc dù không chính xác những gì tôi cần, câu trả lời của bạn đã đưa tôi đi đúng hướng nên tôi đã chọn câu trả lời đúng. Cuối cùng tôi đã chặn tất cả các yêu cầu torrent bằng cách khớp chuỗi '? Info_hash =' trên REQUEST_URI. Tác nhân người dùng không phải là cách tiếp cận tốt nhất vì các máy khách sử dụng nhiều máy khách bittorrent khác nhau với các UAs khác nhau. Quy tắc bảo mật cuối cùng mà tôi đã kết thúc là:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

— Cha0s

Hãy thử dig a.tracker.thepiratebay.orgtừ bất kỳ máy chủ DNS nào trong danh sách này public-dns.tk/nameserver/cn.html và trên mỗi yêu cầu có một câu trả lời khác nhau. Tương tự tracker.thepiratebay.orgmà cũng xuất hiện trong Host của chúng tôi: tiêu đề. Có một bài viết về nó trên viewdns.info/research/, với một số trang web bổ sung. Cố gắng đảo ngược một số địa chỉ được trả về bằng cách sử dụng viewdns.info/reverseip cho thấy rằng nó khá ngẫu nhiên.

— Evgeny

5

Chúng tôi đang gặp vấn đề chính xác với một trong các trang web của khách hàng. Tôi đã thêm vào sau gần đầu của họ:

# 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 đã nhận xét có thể không bị bỏ sót khi chỉ chặn một tác nhân người dùng cụ thể. Nhưng họ không có nội dung tại thông báo hoặc thông báo.php nên chúng tôi chỉ chặn tất cả.

— Dan Armstrong
nguồn

Cảm ơn, nhưng tôi cần một giải pháp sử dụng mod_security chứ không phải mod_rewrite.

— Cha0s

xem Engineering.bittorrent.com/2015/01/29/ cho cách tốt hơn (G / 410 thay vì F / 403 và ErrorDocument rõ ràng)

— ysth

5

Hiện tại tôi đang gặp vấn đề tương tự, có trình theo dõi torrent tại máy chủ của tôi. Tôi đã thử nghiệm với iptables trong vài ngày qua và kiểm tra các tiêu đề và mẫu yêu cầu và thu hẹp nó thành một số quy tắc iptables lọc gần như tất cả lưu lượng truy cập có vẻ nguy hiểm gần đây từ Châu Á (Trung Quốc, Malaysia, Nhật Bản và Hồng Kông).

Dưới đây là các quy tắc. Hy vọng nó sẽ giúp được ai đó.

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

— Pháp
nguồn

Đẹp! Tôi đã không nghĩ về điều đó! Cảm ơn! : D Bạn đã chọn REJECTthay vì DROPmột số lý do cụ thể? (tức là: khách hàng có thể dừng lại sau khi nhận được REJECTkhông?)

— Cha0s

1

Có, ĐỐI TƯỢNG nên yêu cầu khách hàng ngừng yêu cầu tài nguyên đó mặc dù nó dường như không giúp ích gì trong trường hợp này. Nó vẫn lọc nó ra vì vậy tôi sẽ để nó như là DỰ ÁN hy vọng rằng một số khách hàng đưa ra gợi ý. Dù sao đi nữa, iptables sẽ thực hiện tốt hơn rất nhiều so với mod_security trong nhiệm vụ này, vì vậy tôi hy vọng nó hoạt động tốt cho bạn.

— Franci

Yeap nó nên! Tôi đã chặn tất cả các tiền tố của Trung Quốc. Tôi sẽ thử cách tiếp cận này tốt hơn :) Tôi nghĩ rằng các khách hàng bittorrent sẽ không ngừng thử lại ngay cả với DỰ ÁN. Họ sẽ xem đó là "kết nối bị từ chối" và thử lại sau một thời gian. Tôi tin rằng DROP là một cách tiếp cận tốt hơn (và sử dụng ít tài nguyên hơn - nó chỉ đơn giản là giảm các gói ngay khi chúng được khớp mà không cần xử lý thêm)

— Cha0s

1

Sự khác biệt là không đáng kể thực sự trong tất cả các trường hợp ngoại trừ trường hợp cực đoan, và hy vọng của tôi là cuối cùng sẽ ngăn chặn giao thông. Nếu nó không quay số, tôi sẽ đổi nó thành DROP. Tôi rất tò mò về lý do tại sao hoặc làm thế nào điều này xảy ra ở nơi đầu tiên mặc dù. Có một số cuộc thảo luận về Tường lửa vĩ đại của Trung Quốc chuyển hướng đến các IP ngẫu nhiên nhưng tôi khá chắc chắn rằng đây không phải là trường hợp ở đây.

— Franci

1

+1 Đẹp. Chúng tôi sẽ đi với --string "GET /announce"mặc dù, để đáp ứng yêu cầu thực tế .

— Linus Kleen

5

Tôi đã viết một bài đăng trên blog về cách nói với các khách hàng BitTorrent đúng cách và không bao giờ quay lại, tương tự như những gì Dan đã làm, nhưng sử dụng 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";
    }
}

Trình theo dõi torrent (thường) có một URL tiêu chuẩn bắt đầu bằng /announcehoặc /scrape, vì vậy tôi sẽ không loại bỏ việc lọc theo URL quá nhanh. Nó hoạt động.

Bài viết đầy đủ có tại - http://dvps.me/ddos-attack-by-torrent

— Evgeny
nguồn

1

Thú vị đọc. Cảm ơn đã chia sẻ :) Nhưng tôi tin rằng cuộc tấn công đã được gây ra bởi phương tiện DNS Cache Poisoningkể từ khi CERNET ở Trung Quốc phản hồi các tên miền TPB bằng các IP ngẫu nhiên và không phải của Trung Quốc. AFAIK PEX là để chia sẻ các đồng nghiệp, không phải theo dõi. Bạn có thể giải thích thêm về điều đó hoặc cung cấp một số tài liệu?

— Cha0s

Có một tiện ích mở rộng để chia sẻ trình theo dõi được mô tả ở đây bittorrent.org/beps/bep_0028.html . Nhưng bạn đã đúng khi tiêu đề 'Máy chủ:' cho tất cả các yêu cầu này là a.tracker.thepiratebay.orghoặc tracker.thepiratebay.orgcó thể là hoặc không phải là mục tiêu thực sự của các khách hàng này. Nó cũng có thể là khách hàng giả mạo chỉ che dấu mình là người bán hàng Trung Quốc :)

— Evgeny

1

folks bittorrent đề xuất 410 thay vì 404: Engineering.bittorrent.com/2015/01/29/ trên

— ysth

0

tôi lấy các dải ip Trung Quốc từ: http://www.wizccraft.net/chinese-blocklist.html và chặn chúng trong tường lửa csf của tôi, đây là các phạm vi trong trường hợp bạn muốn sao chép và dán vào danh sách ip từ chối của bạn về 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

— người dùng3601800
nguồn

Hoặc bạn có thể chỉ cần thêm CC_DENY = "CN"vào /etc/csf/csf.confvà nó sẽ tự động tìm các tiền tố tiếng Trung dựa trên cơ sở dữ liệu GeoIP của Maxmind.

— Cha0s

cảm ơn, nhưng tôi không chắc cách nào tiêu tốn ít tài nguyên máy chủ như sử dụng CPU, CC_DENY hoặc chặn IP trực tiếp. Tôi sẽ nói rằng chặn IP trực tiếp là tốt hơn.

— dùng3601800

Tôi không thấy bất kỳ sự khác biệt. Khi các quy tắc iptables được tải (cách này hay cách khác - về cơ bản các quy tắc đều giống nhau), tải trên hệ thống sẽ giống nhau. Sự khác biệt duy nhất là danh sách của bạn là tĩnh (vì vậy bạn sẽ phải cập nhật danh sách theo cách thủ công) trong khi danh sách từ cơ sở dữ liệu GeoIP sẽ tự động được cập nhật để phản ánh bất kỳ tiền tố mới hoặc lỗi thời nào theo mã quốc gia. Dù bằng cách nào, khi bạn chặn nhiều tiền tố bằng iptables, bạn sẽ có thêm một tải trên hệ thống. Tải xuất phát từ chính iptables, không phải từ cách bạn tìm thấy tiền tố nào để chặn.

— Cha0s

Tôi phải nói rằng việc chặn mã quốc gia CN trong csf không hoạt động với tôi, hôm nay tôi đã tìm thấy IP mới từ Trung Quốc bị chặn bởi mod_security

— user3601800 6/2/2015

yêu cầu chặn mod_security bởi tiêu đề http-host

Cập nhật: