http-host başlığı tarafından mod_security blok istekleri

16

Son birkaç gün, bazı sunucuların bilinmeyen isteklerle dövüldüğünü fark ettim.

Çoğu aşağıdaki gibidir:

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 -

Biraz giriş ve arama yaptıktan sonra bazı Çinli ISS'lerin (muhtemelen whatsmydns.net sonuçlarına göre CERNET) ve bazı Türk ISS'lerinin (muhtemelen TTNET) a.tracker.thepiratebay.orgpiratebay ile ilgisi olmayan çeşitli IP'lerle ilgili dns sorgularına yanıt verdiklerini öğrendim. veya sel. Başka bir deyişle, tuhaf bir nedenden dolayı bir tür DNS Önbellek Zehirlenmesi yapıyorlar gibi görünüyor.

Bu yüzden, bu ülkelerdeki yüzlerce (binlerce değilse) bittorrent müşterisi, web sunucularıma tonlarca 'duyurular' yapıyor ve bu da neredeyse tüm Apache bağlantılarını dolduran bir DDoS saldırısına neden oluyor.

Şu anda Çin ve Türkiye'yi tamamen engelledim ve bu işi yapıyor, ancak bu istekleri engellemenin daha iyi bir yolunu bulmak istiyorum.

HTTP Host üstbilgisine dayalı mod_security ile bu istekleri engelleme düşünüyordum.

Tüm bu istekler, benzer bir HTTP Ana Bilgisayar üstbilgisi a.tracker.thepiratebay.org(veya thepiratebay.org alan adının diğer birçok alt alanını) içerir.

İşte PHP'nin $_SERVERdeğişkeni üzerinden istek başlıklarının bir dökümü .

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

Benim sorum şu ki, istek etki alanına (HTTP Ana Bilgisayar üstbilgisi) dayalı olarak Apache'ye gelen istekleri nasıl engelleyebilirim? İsteklerin yalnızca /announc.php değil, aynı zamanda URL ile engellemenin de faydalı olmadığını çeşitli URL'lerde olduğunu unutmayın.

Ayrıca bu yaklaşım uygun mu yoksa çok fazla yüke neden olacak mı ve Apache'ye ulaşmadan önce bu istekleri bırakmaya devam etmeli miyim?

Güncelleme:

Bu sorunun dünyanın birçok ülkesinde birçok insanı etkilediği ortaya çıktı.
Bu konuda çok sayıda rapor ve blog yazısı ve bu trafiği engellemek için çeşitli çözümler var.

Buraya gelenlerin bunu engellemek için bir çözüm aramasına yardımcı olmak için bazı raporları topladım.

Gizemli yanlış yönlendirilmiş Çin trafiği: Bir HTTP isteğinin hangi DNS sunucusunu kullandığını nasıl öğrenebilirim?
Sunucumda Garip Bittorrent Oturum Açma
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
https://www.webhostingtalk.com/showthread.php?t=1443734
http: // torrentfreak. com.tr / zombi-korsan-bay-tracker-yakıtlar-çince-ddos-saldırıları-150124 /
https://isc.sans.edu/forums/diary/Are+You+Piratebay+thepiratebayorg+Çözünme + to+Çeşitli +Yasanlar/ 19175 /
http://furbo.org/2015/01/22/fear-china/
http://www.jwz.org/blog/2015/01/chinese-bittorrent-the-gift-that-keeps-on- veren /

apache-2.2  http  mod-security  bittorrent 
— CHA0S
kaynak
1
Buna benzer bir sorun görüyorum, istekleri engelledim ama hangi İSS'lerin yanlış IP adresleri döndürdüğünü nasıl anlayacağınızı merak ediyordum? İsteklerin nereden geldiğini öğrenmek istiyorum, bu iyi bir başlangıç ​​noktası gibi görünüyor
— pogo
Whatsmydns.net ve diğer glbal dns yayılma denetleyicilerine göre, Çin'deki CERNET ve CPIP ve Türkiye'deki TTNET, bu alanın gezegendeki başka herhangi bir ISP'de çözülmediği durumlarda, thepiratebay.org'un çeşitli alt alanlarındaki sorgulara çeşitli IP'lere yanıt vermektedir.
— Cha0s
2
Tam olarak aynı şeyi alıyorum ve fark ettiğin zamanla başladı. facebook, bittorrent, porno siteleri. ama en önemlisi bu sürekli korsan körfezi ilan edilir. serverfault.com/questions/658433/… nginx kullanıyorum ve ana bilgisayar eşleşmiyorsa 444 döndürdüm.
— felix
duyurma talepleri bir miktar azalmıştır. belki de geçici bir DNS yanlış yapılandırmasıydı. hala trafik görüyor musun?
— felix
2
Dürüst olmak gerekirse, Çin'i güvenlik duvarı düzeyinde engellemiştim, çünkü mod_security ile bile tüm Apache bağlantılarını dolduracaklardı. Bu yüzden isteklerin azaltıldığını fark etmedim.
— Cha0s

Yanıtlar:

7

Burada da aynı sorun var. Kullanıcı aracısını engellemek için mod_security kullanıyorum

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

Günlük dosyanızı doldurmaktan kaçındığını doğruladıktan sonra günlüğü nolog olarak değiştirirdim

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,nolog,msg:'Bittorrent Hit Detected'"
— user262546
kaynak
1
Tam olarak ihtiyacım olan şey olmasa da, cevabın beni doğru yöne yönlendirdi, bu yüzden seninkini doğru olanı seçtim. REQUEST_URI üzerindeki '? İnfo_hash =' dizesini eşleştirerek tüm torrent isteklerini engelledim. User-Agent en iyi yaklaşım değildi çünkü istemciler farklı UA'lara sahip birçok farklı bittorrent istemcisi kullanıyor. Nihai mod_security kuralı:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"
— Cha0s
Deneyin dig a.tracker.thepiratebay.orgBu liste herhangi bir DNS sunucusundan public-dns.tk/nameserver/cn.html farklı bir cevabı vardır ve her istek üzerine. Aynısı Host'umuzda tracker.thepiratebay.orgda göründü: başlıklar. Bu konuda bazı ek siteler içeren viewdns.info/research/… ' de bir yayın var . Viewdns.info/reverseip kullanarak döndürülen adreslerin bazılarını tersine çevirmeye çalışmak , onun oldukça rasgele olduğunu gösterir.
— Evgeny
5

Müşterilerimizin sitelerinden biriyle aynı sorunu yaşıyoruz. Onların üstüne yakın aşağıdakileri ekledim:

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

Yorum yapılan RewriteCond öğesinin yalnızca belirli bir kullanıcı aracısını engellemesi önerilmeyebilir. Ancak anons veya announc.php içeriği yok, bu yüzden hepsini engelledik.

— Dan Armstrong
kaynak
Teşekkürler, ama mod_ecrit kullanarak mod_security kullanarak bir çözüme ihtiyacım vardı.
— Cha0s
bkz engineering.bittorrent.com/2015/01/29/... daha iyi bir şekilde (G / 410 yerine F / 403 ve bir açık ErrorDocument) için
— ysth
5

Şu anda aynı sorunu yaşıyorum, sunucumda torrent izleyicileri işaret ediyor. Son birkaç gün boyunca iptables ile denemeler yaptım ve isteklerin başlıklarını ve modellerini inceledim ve Asya'dan (Çin, Malezya, Japonya ve Hong Kong).

Kurallar aşağıdadır. Umarım birine yardımcı olur.

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
kaynak
Güzel! Bunu düşünmedim! Teşekkürler! : D sen tercih mü REJECTyerine DROPbazı belirli bir nedenle? (örneğin: müşteriler bir REJECT? aldıktan sonra durabilir ?)
— Cha0s
1
Evet, REJECT, istemciye bu durumda yardımcı görünmese de bu kaynağı istemeyi bırakmasını söylemelidir. Hala filtreliyor, bu yüzden bazı müşterilerin bir ipucu almasını umarak reddetmek olarak bırakacağım. Her durumda, iptables bu görevde mod_security'den çok daha iyi performans göstermelidir, bu yüzden umarım sizin için iyi çalışır.
— Franci
Yeap gerekir! Tüm Çin öneklerini engelliyordum. Daha iyi olan bu yaklaşımı deneyeceğim :) Bittorrent istemcilerinin REJECT ile bile yeniden denemeyi bırakmayacağını düşünüyorum. Bunu 'bağlantı reddedildi' olarak görürler ve bir süre sonra tekrar denerler.
— DROP'un
1
Fark, aşırı durumlar dışında aslında oldukça ihmal edilebilir ve umarım sonunda trafiği caydırmaktı. Çevirmezse DROP olarak değiştiririm. Bunun neden ya da nasıl gerçekleştiğini çok merak ediyorum. Çin'in Büyük Güvenlik Duvarı'nın rastgele IP'lere yönlendirdiği hakkında bazı tartışmalar var, ancak burada böyle olmadığından eminim.
— Franci
1
+1 Güzel olan. Bununla birlikte --string "GET /announce", gerçek talebi karşılamak için gidiyoruz .
— Linus Kleen
5

BitTorrent istemcilerine Dan'ın yaptıklarına benzer şekilde nginx kullanarak gitmelerini ve asla geri dönmemelerini nasıl söyleyeceğime dair bir blog yazısı yazdım.

server {
    location /announc {
        access_log off;
        error_log off;
        default_type text/plain;
        return 410 "d14:failure reason13:not a tracker8:retry in5:nevere";
    }
}

Torrent izleyicileri (genellikle) /announceveya ile başlayan standart bir URL'ye sahiptir /scrape, bu nedenle URL'ye göre filtrelemeyi bu kadar hızlı bir şekilde reddetmem. İşe yarıyor.

Yazının tamamı - http://dvps.me/ddos-attack-by-torrent

— Evgeny
kaynak
1
İlginç bir okuma. Paylaştığınız için teşekkürler :) Ancak DNS Cache Poisoning, Çin'deki CERNET'in rastgele ve Çince olmayan IP'lerle TPB alanlarına yanıt vermesinden bu yana saldırının tetiklendiğine inanıyorum . AFAIK PEX izleyicileri değil akranları paylaşmak içindir. Bununla ilgili daha fazla ayrıntı verebilir veya bazı belgeler sağlayabilir misiniz?
— Cha0s
Burada açıklanan izleyicileri paylaşmak için bittorrent.org/beps/bep_0028.html bir uzantı var . Ama bunu doğru olup 'Ana Bilgisayar:' Bu taleplerin tümü için başlığıdır a.tracker.thepiratebay.orgveya tracker.thepiratebay.orghangi olabilir ya bu müşterilerin gerçek hedef olmayabilir. Aynı zamanda Çinli bittorentler olarak kendilerini maskeleyen sahte müşteriler olabilir :)
— Evgeny
1
bittorrent millet 404 yerine 410 önermektedir: engineering.bittorrent.com/2015/01/29/…
— ysth
0

Çince ip aralıklarını aldım: http://www.wizcrafts.net/chinese-blocklist.html ve onları csf güvenlik duvarımda bloke ettim, kopyalayıp csf inkar ip listenize yapıştırmak istediğiniz aralıklar :

#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
kaynak
Veya sadece ekleyebilir CC_DENY = "CN"üzerinde /etc/csf/csf.confve otomatik MaxMind Kullanıcı GeoIP veritabanına dayalı Çin önekleri bulacaksınız.
— Cha0s
teşekkürler, ancak CPU kullanımı, CC_DENY veya doğrudan IP engelleme gibi daha az sunucu kaynağı hangi yoldan tükettiğinden emin değilim. Doğrudan IP engellemenin daha iyi olduğunu söyleyebilirim.
— user3601800
Hiç bir fark görmüyorum. İptables kuralları yüklendikten sonra (şu ya da bu şekilde - kurallar esasen aynıdır) sistemdeki yük aynı olacaktır. Tek fark, listenizin statik olmasıdır (bu nedenle listeyi manuel olarak güncellemeniz gerekir), GeoIP veritabanındaki liste zaman zaman ülke kodu başına yeni veya eski önekleri yansıtacak şekilde otomatik olarak güncellenir. Her iki durumda da iptables ile birçok öneki engellediğinizde, sistemde fazladan bir yükünüz olur. Yük, hangi öneklerin engelleneceğini bulma biçiminizden değil, iptables'dan gelir.
— Cha0s
csf ülke kodu CN engelleme benim için işe yaramadı söylemek gerekir, bugün Çin mod_security tarafından engellenen yeni IP'ler bulduk
— user3601800
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.