16

Beberapa hari terakhir saya perhatikan beberapa server dipalu dengan permintaan yang tidak diketahui.

Kebanyakan dari mereka adalah sebagai berikut:

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 -

Setelah sedikit login dan pencarian saya menemukan bahwa beberapa ISP Cina (mungkin CERNET menurut hasil whatsmydns.net) dan beberapa ISP Turki (mungkin TTNET) menanggapi pertanyaan dns seperti a.tracker.thepiratebay.orgdengan berbagai IP yang tidak ada hubungannya dengan piratebay atau torrents. Dengan kata lain mereka tampaknya melakukan semacam Keracunan DNS Cache karena alasan yang aneh.

Jadi, ratusan (jika bukan ribuan) klien bittorrent di negara-negara itu membuat banyak 'pengumuman' ke server web saya yang menghasilkan serangan DDoS yang mengisi semua koneksi Apache.

Saat ini saya sama sekali memblokir China dan Turki dan itu berhasil, tetapi saya ingin menemukan cara yang lebih baik untuk memblokir permintaan itu.

Saya berpikir untuk memblokir permintaan itu dengan mod_security berdasarkan header HTTP Host.

Semua permintaan itu mencakup tajuk Host HTTP seperti a.tracker.thepiratebay.org(atau banyak subdomain lain dari domain thepiratebay.org).

Berikut adalah dump header permintaan melalui $_SERVERvariabel 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

Jadi pertanyaan saya adalah, bagaimana saya bisa memblokir permintaan masuk ke Apache berdasarkan domain permintaan (header Host HTTP)? Perlu diingat bahwa permintaan ada di berbagai URL bukan hanya /announce.php sehingga pemblokiran dengan URL tidak berguna.

Juga apakah pendekatan itu layak atau akankah itu menyebabkan terlalu banyak memuat dan saya harus terus menjatuhkan permintaan itu bahkan sebelum mereka mencapai Apache?

Memperbarui:

Ternyata masalah ini telah memengaruhi banyak orang di banyak negara di seluruh dunia.
Ada banyak laporan dan blogpost tentangnya dan berbagai solusi untuk memblokir traffic ini.

Saya telah mengumpulkan beberapa laporan untuk membantu siapa pun yang datang ke sini mencari solusi untuk memblokir ini.

Lalu lintas China yang salah arah dan misterius: Bagaimana saya bisa mengetahui server DNS apa yang digunakan permintaan HTTP?
Bittorrent Strange Masuk Di Server Saya
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-bahan bakar-chinese-ddos-attacks-150124 /
https://isc.sans.edu/forums/diary/Are+Anda+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- memberi/

apache-2.2 http mod-security bittorrent Kekacauan
sumber

1

Saya melihat masalah yang serupa dengan ini, saya telah memblokir permintaan tetapi saya bertanya-tanya bagaimana Anda menemukan ISP mana yang mengembalikan alamat IP yang salah? Saya tertarik untuk mencari tahu dari mana permintaan datang sehingga sepertinya merupakan titik awal yang baik

pogo

Menurut whatsmydns.net dan checker propagasi glbal dns lainnya, CERNET dan CPIP di China dan TTNET di Turki menanggapi pertanyaan pada berbagai subdomain thepiratebay.org untuk berbagai IP ketika domain itu tidak menyelesaikan ISP lain di planet ini.

Cha0s

2

Saya mendapatkan hal yang sama persis dan itu dimulai sekitar waktu yang sama Anda menyadarinya. facebook, bittorrent, situs porno. tetapi yang paling terkenal adalah bajak laut konstan ini mengumumkan. serverfault.com/questions/658433/... Saya menggunakan nginx dan saya telah mengembalikan 444 jika host tidak cocok.

felix

permintaan untuk mengumumkan telah berkurang sedikit. mungkin itu adalah kesalahan konfigurasi DNS sementara. apakah Anda masih melihat lalu lintas?

felix

2

Sejujurnya saya akhirnya memblokir China pada level firewall karena karena dengan mod_security mereka akan mengisi semua koneksi Apache. Jadi saya belum memperhatikan jika permintaan telah dikurangi.

Cha0s

7

Masalah yang sama di sini. Saya menggunakan mod_security untuk memblokir agen-pengguna

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

Saya akan mengubah log ke nolog setelah Anda memverifikasi itu berfungsi untuk menghindari mengisi file log Anda

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

pengguna262546
sumber

1

Meskipun tidak persis apa yang saya butuhkan, jawaban Anda mengarahkan saya ke arah yang benar sehingga saya memilih jawaban Anda sebagai yang benar. Saya akhirnya memblokir semua permintaan torrent dengan mencocokkan string '? Info_hash =' pada REQUEST_URI. User-Agent bukanlah pendekatan terbaik karena klien menggunakan banyak klien bittorrent yang berbeda dengan UA yang berbeda. Aturan mod_security terakhir yang saya dapatkan adalah:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

Cha0s

Coba dig a.tracker.thepiratebay.orgdari sembarang server DNS dalam daftar ini public-dns.tk/nameserver/cn.html dan pada setiap permintaan ada jawaban yang berbeda. Hal tracker.thepiratebay.orgyang sama juga muncul di Host kami: header. Ada posting tentang hal itu di viewdns.info/research/… dengan beberapa situs tambahan. Mencoba membalikkan beberapa alamat yang dikembalikan menggunakan viewdns.info/reverseip menunjukkan bahwa ini cukup acak.

Evgeny

5

Kami mengalami masalah yang persis sama dengan salah satu situs klien kami. Saya menambahkan yang berikut di dekat bagian atas mereka:

# 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 yang dikomentari dapat dibatalkan komentar untuk hanya memblokir agen pengguna tertentu. Tetapi mereka tidak memiliki konten di announce atau anno.php jadi kami hanya memblokir semuanya.

Dan Armstrong
sumber

Terima kasih, tetapi saya membutuhkan solusi menggunakan mod_security dan bukan mod_rewrite.

Cha0s

lihat engineering.bittorrent.com/2015/01/29/… untuk cara yang lebih baik (G / 410 daripada F / 403, dan eksplisit ErrorDocument)

ysth

5

Saya mengalami masalah yang sama saat ini, memiliki titik pelacak torrent di server saya. Saya telah bereksperimen dengan iptables selama beberapa hari terakhir dan memeriksa header dan pola permintaan serta mempersempitnya menjadi beberapa aturan iptables yang menyaring hampir semua lalu lintas yang tampaknya berbahaya baru-baru ini dari Asia (Cina, Malaysia, Jepang, dan Hongkong).

Di bawah ini adalah peraturannya. Semoga ini bisa membantu seseorang.

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
sumber

Bagus! Saya tidak memikirkan itu! Terima kasih! : D Apakah Anda memilih untuk REJECTbukan DROPkarena alasan tertentu? (yaitu: klien dapat berhenti setelah menerima REJECT?)

Cha0s

1

Ya, REJECT harus memberi tahu klien untuk berhenti meminta sumber daya itu meskipun sepertinya tidak membantu dalam kasus ini. Itu masih menyaringnya jadi saya akan meninggalkannya karena TOLAK berharap beberapa klien mengambil petunjuk. Bagaimanapun, iptables harus melakukan jauh lebih baik daripada mod_security pada tugas ini, jadi saya harap ini berfungsi dengan baik untuk Anda.

Franci

Ya harus! Saya memblokir semua awalan berbahasa Mandarin. Saya akan mencoba pendekatan ini yang lebih baik :) Saya pikir klien bittorrent tidak akan berhenti mencoba kembali bahkan dengan TOLAK. Mereka akan melihatnya sebagai 'koneksi ditolak' dan coba lagi setelah beberapa saat. Saya percaya DROP adalah pendekatan yang lebih baik (dan menggunakan lebih sedikit sumber daya - itu hanya menjatuhkan paket saat mereka dicocokkan tanpa proses lebih lanjut)

Cha0s

1

Perbedaannya cukup kecil sebenarnya dalam semua kasus tetapi ekstrim, dan harapan saya adalah untuk akhirnya menghalangi lalu lintas. Jika tidak dial down saya akan mengubahnya ke DROP. Saya sangat ingin tahu mengapa atau bagaimana ini terjadi pada awalnya. Ada beberapa diskusi tentang Great Firewall of China yang mengarahkan ulang ke IP acak tapi saya cukup yakin ini tidak terjadi di sini.

Franci

1

+1 Bagus. Kami akan tetap --string "GET /announce", untuk menutupi permintaan yang sebenarnya .

Linus Kleen

5

Saya menulis posting blog tentang bagaimana cara memberitahu klien BitTorrent untuk pergi dan tidak pernah kembali, mirip dengan apa yang dilakukan Dan, tetapi menggunakan 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";
    }
}

Pelacak torrent (biasanya) memiliki URL standar yang dimulai dengan /announceatau /scrape, jadi saya tidak akan mengabaikan pemfilteran dengan URL dengan cepat. Berhasil.

Pos lengkapnya ada di - http://dvps.me/ddos-attack-by-torrent

Evgeny
sumber

1

Baca menarik. Terima kasih telah berbagi :) Tapi saya percaya serangan itu disebabkan oleh DNS Cache Poisoningkarena CERNET di Cina merespons domain TPB dengan IP acak dan non-Cina. AFAIK PEX adalah untuk berbagi teman, bukan pelacak. Bisakah Anda menguraikan lebih lanjut tentang itu atau memberikan dokumentasi?

Cha0s

Ada ekstensi untuk berbagi pelacak yang dijelaskan di sini bittorrent.org/beps/bep_0028.html . Tetapi Anda benar bahwa tajuk 'Host:' untuk semua permintaan ini adalah a.tracker.thepiratebay.orgatau tracker.thepiratebay.orgyang mungkin atau tidak menjadi target sebenarnya dari klien ini. Ini juga bisa menjadi klien palsu hanya menutupi diri mereka sebagai bittorents Cina :)

Evgeny

1

orang-orang bittorrent menyarankan 410 alih-alih 404: engineering.bittorrent.com/2015/01/29/…

ysth

0

saya mengambil rentang ip Cina dari: http://www.wizcrafts.net/chinese-blocklist.html dan memblokirnya di firewall csf saya, di sini adalah rentang jika Anda ingin menyalin dan menempel ke daftar ip ditolak Anda dari 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

pengguna3601800
sumber

Atau Anda dapat menambahkan CC_DENY = "CN"pada /etc/csf/csf.confdan secara otomatis akan menemukan prefiks Cina berdasarkan database GeoIP Maxmind ini.

Cha0s

terima kasih, tapi saya tidak yakin cara mana yang mengonsumsi lebih sedikit sumber daya server seperti penggunaan CPU, CC_DENY atau pemblokiran IP langsung. Saya akan mengatakan bahwa pemblokiran IP langsung lebih baik.

user3601800

Saya tidak melihat perbedaan. Setelah aturan iptables dimuat (satu atau lain cara - aturan dasarnya sama) beban pada sistem akan sama. Satu-satunya perbedaan adalah bahwa daftar Anda statis (jadi Anda harus memperbaruinya secara manual) sementara daftar dari basis data GeoIP akan diperbarui dari waktu ke waktu secara otomatis untuk mencerminkan awalan baru atau usang per kode negara. Either way ketika Anda memblokir banyak awalan dengan iptables, Anda akan memiliki beban tambahan pada sistem. Muatan berasal dari iptables sendiri, bukan dari cara Anda menemukan awalan yang akan diblokir.

Cha0s

saya harus mengatakan bahwa memblokir kode negara CN di csf tidak bekerja untuk saya, hari ini saya telah menemukan IP baru dari China diblokir oleh mod_security

user3601800

mod_security memblokir permintaan oleh header http-host

Memperbarui:

Jawaban: