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 (whatsydns.net के परिणामों के अनुसार शायद CERNET) और कुछ तुर्की ISP (शायद TTNET) a.tracker.thepiratebay.orgविभिन्न IPs जैसे प्रश्नों का जवाब देते हैं जिनका पाइरेटबाय से कोई लेना देना नहीं है या अत्याचार। दूसरे शब्दों में, वे कुछ विचित्र कारण के लिए किसी प्रकार का डीएनएस कैश पॉइज़निंग करते हैं।

तो उन देशों के सैकड़ों (यदि हजारों नहीं) सैकड़ों ग्राहक मेरे वेबसर्वरों को 'अनाउंस' करते हैं, जिसके परिणामस्वरूप डीडीओएस हमले में सभी अपाचे के कनेक्शन भरते हैं।

फिलहाल मैंने चीन और तुर्की को पूरी तरह से अवरुद्ध कर दिया है और यह काम करता है, लेकिन मैं उन अनुरोधों को अवरुद्ध करने का एक बेहतर तरीका खोजना चाहता हूं।

मैं HTTP होस्ट हेडर के आधार पर mod_security के साथ उन अनुरोधों को अवरुद्ध करने के बारे में सोच रहा था।

उन सभी अनुरोधों में एक HTTP होस्ट हेडर जैसे a.tracker.thepiratebay.org(या thepiratebay.org डोमेन के कई अन्य उप डोमेन) शामिल हैं।

यहाँ PHP के $_SERVERचर के माध्यम से अनुरोध हेडर का एक डंप है ।

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

तो मेरा सवाल है, मैं अनुरोध डोमेन (HTTP होस्ट हेडर) के आधार पर अपाचे के लिए आने वाले अनुरोधों को कैसे रोक सकता हूं? ध्यान रखें कि अनुरोध विभिन्न URL पर होते हैं न कि केवल /announce.php इसलिए URL द्वारा अवरुद्ध करना उपयोगी नहीं है।

इसके अलावा वह दृष्टिकोण व्यवहार्य है या यह बहुत अधिक भार का कारण होगा और मुझे अपाचे तक पहुंचने से पहले ही उन अनुरोधों को छोड़ देना चाहिए?

अपडेट करें:

यह पता चला है कि इस मुद्दे ने दुनिया भर के कई देशों में कई लोगों को प्रभावित किया है।
इस ट्रैफ़िक को अवरुद्ध करने के लिए इसके बारे में और विभिन्न समाधानों के बारे में कई रिपोर्ट और ब्लॉगपोस्ट आए हैं।

मैंने इसे ब्लॉक करने के समाधान पर खोज करने में किसी की मदद करने के लिए कुछ रिपोर्ट एकत्र की हैं।

रहस्यमय तरीके से गलत तरीके से किया गया चीनी ट्रैफिक: मैं कैसे पता लगा सकता हूं कि DNS सर्वर एक HTTP अनुरोध का क्या उपयोग करता है?
मेरा सर्वर
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
https://www.webhostingtalk.com/showthread.php?t=144373734
http: // torrentfreak पर अजीब बिट लॉगेंट लॉग ऑन करें । com / ज़ॉम्बी-पाइरेट-बे-ट्रैकर-फ्यूल-चाइनीज-डीडोस-अटैक -150124 /
https://isc.sans.edu/forums/diary/Are+You+Piratebay+theparatebayorg+Resolve+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

मैं इसी तरह के मुद्दे को देख रहा हूं, मैंने अनुरोधों को अवरुद्ध कर दिया है, लेकिन मैं सोच रहा था कि आप कैसे पता लगा पाएंगे कि आईएसपी गलत आईपी पते वापस कर रहे थे? मुझे यह जानने में दिलचस्पी है कि अनुरोध कहां से आ रहे हैं, जो एक अच्छा शुरुआती बिंदु लगता है

— पोगो

Whatsmydns.net और अन्य ग्लैबल डीएनएस प्रचार चेकर्स के अनुसार, CERNET और CPIP चीन और तुर्की में TTNET thepiratebay.org के विभिन्न उप-डोमेन पर पूछे गए प्रश्नों का जवाब विभिन्न IP को देते हैं, जब वह डोमेन ग्रह के चारों ओर किसी अन्य ISP पर हल नहीं करता है।

— च्स

2

मैं ठीक वैसी ही बात कर रहा हूं और यह उसी समय शुरू हुआ जब आपने इसे देखा था। फेसबुक, बिटटोरेंट, पोर्न साइट्स। लेकिन विशेष रूप से यह निरंतर समुद्री डाकू बे घोषणा है। serverfault.com/questions/658433/… मैं nginx का उपयोग कर रहा हूं और अगर मैं मेजबान से मेल नहीं खाता हूं तो मैंने 444 वापस कर दिया है।

— फेलिक्स

घोषणा करने के अनुरोध काफी कम हो गए हैं। शायद यह एक अस्थायी DNS ग़लतफ़हमी थी। क्या आप अभी भी ट्रैफ़िक देख रहे हैं?

— felix

2

सच कहूं तो मैंने चीन को फायरवॉल स्तर पर आखिरकार रोक दिया क्योंकि mod_security के साथ भी वे अपाचे के सभी कनेक्शन भर देंगे। अगर अनुरोध कम हो गए हैं तो मैंने गौर नहीं किया है।

— 14

7

एक ही मुद्दा यहाँ। मैं उपयोगकर्ता-एजेंट को ब्लॉक करने के लिए mod_security का उपयोग कर रहा हूं

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

आपके लॉग फ़ाइल को भरने से बचने के लिए यह सत्यापित करने के बाद कि मैं यह सत्यापित करने के लिए लॉग को बदल दूंगा

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

— user262546
स्रोत

1

जबकि वास्तव में मुझे क्या चाहिए, आपका जवाब मुझे सही दिशा में ले गया, इसलिए मैंने आपको सही के रूप में चुना। REQUEST_URI पर '? Info_hash =' स्ट्रिंग के मिलान से मैंने सभी टोरेंट अनुरोधों को रोक दिया। उपयोगकर्ता-एजेंट सबसे अच्छा तरीका नहीं था क्योंकि ग्राहक विभिन्न यूएएस के साथ कई अलग-अलग बिटोरेंट क्लाइंट का उपयोग करते हैं। अंतिम 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>

केवल एक विशिष्ट उपयोगकर्ता एजेंट को ब्लॉक करने के लिए टिप्पणी की गई आउट-रीट्रीकॉन्ड को अनियंत्रित किया जा सकता है। लेकिन उनके पास घोषणा या घोषणा के लिए कोई सामग्री नहीं है। इसलिए हमने अभी यह सब अवरुद्ध कर दिया है।

— डैन आर्मस्ट्रांग
स्रोत

धन्यवाद, लेकिन मुझे mod_security का उपयोग करके समाधान की आवश्यकता थी न कि mod_rewrite की।

— Cha0s

देख engineering.bittorrent.com/2015/01/29/... एक बेहतर तरीका (जी / 410 के बजाय एफ / 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

— Franci
स्रोत

अच्छा! मैंने ऐसा नहीं सोचा था! धन्यवाद! : क्या आपने किसी विशेष कारण के REJECTबजाय चुना DROP? (यानी: ग्राहक एक प्राप्त करने के बाद बंद हो सकता है REJECT?)

— Cha0s

1

हां, ग्राहक को उस संसाधन का अनुरोध करने से रोकने के लिए कहना चाहिए, हालांकि यह इस मामले में मदद नहीं करता है। यह अभी भी इसे फ़िल्टर करता है इसलिए मैं इसे उम्मीद के रूप में छोड़ दूंगा कि कुछ ग्राहक संकेत दें। किसी भी तरह से, iptables को इस कार्य में mod_security से बहुत बेहतर प्रदर्शन करना चाहिए, इसलिए मुझे उम्मीद है कि यह आपके लिए अच्छा काम करेगा।

— फ्रैंकी

यह चाहिए! मैं सभी चीनी उपसर्गों को रोक रहा था। मैं इस दृष्टिकोण की कोशिश करूंगा जो बेहतर है :) मुझे लगता है कि बिटटोरेंट क्लाइंट REJECT के साथ भी पुन: प्रयास करना बंद नहीं करेंगे। वे इसे 'कनेक्शन से इनकार' के रूप में देखेंगे और थोड़ी देर बाद फिर से प्रयास करेंगे। मेरा मानना है कि DROP एक बेहतर दृष्टिकोण है (और कम संसाधनों का उपयोग करता है - यह केवल पैकेटों को उस क्षण को

— गिरा देता है

1

अंतर वास्तव में सभी लेकिन चरम मामलों में काफी नगण्य है, और मेरी आशा अंत में यातायात को रोकना था। अगर यह नीचे डायल नहीं करता है तो मैं इसे DROP में बदल दूंगा। मैं इस बात से बहुत उत्सुक हूं कि पहली बार में ऐसा क्यों या कैसे हुआ। चीन के ग्रेट फ़ायरवॉल के बारे में कुछ चर्चाएँ हैं जो यादृच्छिक आईपी को पुनर्निर्देशित करती हैं लेकिन मुझे पूरा यकीन है कि यहाँ ऐसा नहीं है।

— फ्रेंकी

1

+1 अच्छा लगा। --string "GET /announce"हालांकि, हम वास्तविक अनुरोध को कवर करने के लिए जा रहे हैं।

— लाइनस क्लेन

5

मैंने एक ब्लॉग पोस्ट लिखा कि कैसे बिटटोरेंट ग्राहकों को ठीक से जाने के लिए और कभी भी वापस नहीं आना चाहिए, जैसा कि डैन ने किया था, लेकिन 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 Poisoningचीन में CERNET के कारण से प्रेरित था क्योंकि यादृच्छिक और गैर-चीनी IP के साथ TPB डोमेन का जवाब है। AFAIK PEX सहकर्मी साझा करने के लिए है, ट्रैकर नहीं। क्या आप उस पर अधिक विस्तार कर सकते हैं या कुछ दस्तावेज प्रदान कर सकते हैं?

— 17

यहाँ वर्णित ट्रैकर साझा करने के लिए एक एक्सटेंशन है bittorrent.org/beps/bep_0028.html । लेकिन आप सही हैं कि इन सभी अनुरोधों के लिए 'होस्ट:' हेडर है a.tracker.thepiratebay.orgया tracker.thepiratebay.orgजो इन क्लाइंट्स का वास्तविक लक्ष्य हो सकता है या नहीं। यह नकली ग्राहक भी हो सकता है जो खुद को चीनी बिटकॉइन के रूप में मास्क कर रहा है :)

— इवगेनी

1

: बिटटोरेंट लोगों 410 के बजाय 404 सुझाव है engineering.bittorrent.com/2015/01/29/...

— ysth

0

मैंने चाइनीज आईपी रेंजों को यहां से लिया: http://www.wizcrafts.net/chinese-blocklist.html और मेरे सीएसएफ फ़ायरवॉल में उन्हें ब्लॉक किया, यहां उन श्रेणियों की सीमा है, जब आप सीएसपी की अपनी अस्वीकार्य आईपी सूची में कॉपी और पेस्ट करना चाहते हैं। :

#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और यह स्वचालित रूप से मैक्समाइंड के जियोआईपी डेटाबेस के आधार पर चीनी उपसर्गों को ढूंढ लेगा।

— Cha0s

धन्यवाद, लेकिन मुझे यकीन नहीं है कि सीपीयू उपयोग, CC_DENY या प्रत्यक्ष आईपी ब्लॉकिंग जैसे कम सर्वर संसाधनों का उपयोग किस तरह से किया जाता है। मैं कहूंगा कि डायरेक्ट आईपी ब्लॉकिंग बेहतर है।

— user3601800

मुझे कोई मतभेद नज़र नहीं आ रहा है। एक बार iptables नियम लोड होने के बाद (एक तरीका या दूसरा - नियम समान रूप से समान हैं) सिस्टम पर लोड समान होगा। अंतर केवल इतना है कि आपकी सूची स्थिर है (इसलिए आपको इसे मैन्युअल रूप से अद्यतित रखना होगा) जबकि देश के किसी भी नए या अप्रचलित उपसर्ग को दर्शाने के लिए जियोआईपी डेटाबेस से सूची को समय-समय पर स्वचालित रूप से अपडेट किया जाएगा। किसी भी तरह से जब आप iptables के साथ कई उपसर्गों को अवरुद्ध करते हैं, तो आपके पास सिस्टम पर एक अतिरिक्त भार होगा। लोड खुद iptables से आता है, उस तरह से नहीं जब आप पाते हैं कि किस उपसर्ग को ब्लॉक करना है।

— Cha0s

मेरा कहना है कि csf में ब्लॉकिंग कंट्री कोड CN ने मेरे लिए काम नहीं किया, आज मैंने चीन के नए IP को

— mod_security

HTTP_ होस्ट हेडर द्वारा mod_security ब्लॉक अनुरोध

अपडेट करें: