सवाल http_ होस्ट सुरक्षा द्वारा http_security ब्लॉक अनुरोध


पिछले कुछ दिनों में मैंने देखा कि कुछ सर्वर अज्ञात अनुरोधों के साथ हथियार लगाए जा रहे हैं।

उनमें से ज्यादातर निम्नलिखित की तरह हैं:

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 -

कुछ लॉगिंग और खोज के बाद मुझे पता चला कि कुछ चीनी आईएसपी (शायद सीईएसएनईटी whatsmydns.net के परिणामों के अनुसार) और कुछ तुर्की आईएसपी (शायद टीटीएनईटी) डीएनएस प्रश्नों का जवाब देते हैं जैसे कि a.tracker.thepiratebay.org विभिन्न आईपी के साथ जिनके पास समुद्री डाकू या टोरेंटों से कोई लेना देना नहीं है। दूसरे शब्दों में वे कुछ विचित्र कारणों के लिए कुछ प्रकार के डीएनएस कैश जहर लगते हैं।

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

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

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

उन सभी अनुरोधों में एक HTTP होस्ट शीर्षलेख शामिल है a.tracker.thepiratebay.org (याpiratebay.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 होस्ट हेडर) के आधार पर अपाचे को आने वाले अनुरोधों को कैसे अवरुद्ध कर सकता हूं? ध्यान रखें कि अनुरोध विभिन्न यूआरएल पर हैं, न कि सिर्फ /announce.php, इसलिए यूआरएल द्वारा अवरुद्ध करना उपयोगी नहीं है।

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

अद्यतन करें:

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

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

रहस्यमय गलत निर्देशित चीनी यातायात: मैं कैसे पता लगा सकता हूं कि एक DNS अनुरोध HTTP सर्वर का उपयोग किस प्रकार किया जाता है?
मेरे सर्वर पर अजीब बिटोरेंट लॉग ऑन करें
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-attacks-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-giving/ 


16
2018-01-03 19:13


मूल


मुझे इस तरह के एक समान मुद्दे को देख रहा है, मैंने अनुरोधों को अवरुद्ध कर दिया है, लेकिन मैं सोच रहा था कि आप कैसे पता लगाएंगे कि कौन से आईएसपी गलत आईपी पते लौट रहे थे? मुझे यह जानने में दिलचस्पी है कि अनुरोध कहां से आ रहे हैं, जो कि एक अच्छा प्रारंभिक बिंदु जैसा लगता है - pogo
Whatsmydns.net और अन्य ग्लबल डीएनएस प्रचार जांचकर्ताओं के मुताबिक, चीन में सीईआरएनईटी और सीपीआईपी और तुर्की में टीटीएनईटी, विभिन्न आईपी के लिए thepiratebay.org के विभिन्न उप डोमेनों पर प्रश्नों का उत्तर देते हैं, जब वह ग्रह ग्रह के चारों ओर किसी अन्य आईएसपी पर हल नहीं होता है। - Cha0s
मुझे वही चीज़ मिल रही है और यह उसी समय शुरू हुआ जब आपने इसे देखा था। फेसबुक, bittorrent, अश्लील साइटों। लेकिन सबसे विशेष रूप से यह निरंतर समुद्री डाकू बे घोषणा। serverfault.com/questions/658433/...  मैं nginx का उपयोग कर रहा हूं और मेजबान मेल नहीं खाता है तो मैं 444 लौटा दिया है। - felix
घोषणा करने के अनुरोध काफी कम हो गए हैं। शायद यह एक अस्थायी DNS गलत कॉन्फ़िगरेशन था। क्या आप अभी भी यातायात देख रहे हैं? - felix
ईमानदार होने के लिए मैंने फ़ायरवॉल स्तर पर चीन को अवरुद्ध कर दिया क्योंकि सभी के बाद भी mod_security के साथ वे सभी अपाचे कनेक्शन को भर देंगे। इसलिए मैंने ध्यान नहीं दिया है कि अनुरोध कम हो गए हैं या नहीं। - Cha0s


जवाब:


यहां एक ही मुद्दा है। मैं उपयोगकर्ता-एजेंट को अवरुद्ध करने के लिए 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'"

7
2018-01-06 07:26



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


हम अपने ग्राहक की साइटों में से एक के साथ बिल्कुल वही समस्या का सामना कर रहे हैं। मैंने निम्नलिखित के शीर्ष के पास निम्नलिखित जोड़ा:

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

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


5
2018-01-06 04:46



धन्यवाद, लेकिन मुझे mod_security का उपयोग करके समाधान की आवश्यकता है और mod_rewrite नहीं। - Cha0s
देख engineering.bittorrent.com/2015/01/29/... बेहतर तरीके से (एफ / 403 के बजाय जी / 410, और एक स्पष्ट त्रुटि दस्तावेज़) - ysth


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

नियम हैं। उम्मीद है कि यह किसी की मदद करता है।

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

5
2018-01-24 17:18



अच्छा! मैंने इसके बारे में नहीं सोचा था! धन्यवाद! : डी क्या आपने चुना था REJECT के बजाय DROP किसी विशेष कारण के लिए? (यानी: ग्राहक प्राप्त करने के बाद बंद हो सकते हैं REJECT?) - Cha0s
हां, अस्वीकृति क्लाइंट को उस संसाधन का अनुरोध करना बंद करने के लिए कहनी चाहिए, हालांकि यह इस मामले में मदद नहीं कर रहा है। यह अभी भी इसे फ़िल्टर करता है इसलिए मैं इसे उम्मीद के रूप में छोड़ दूंगा कि कुछ ग्राहक संकेत देते हैं। किसी भी तरह से, iptables को इस कार्य में mod_security से बहुत बेहतर प्रदर्शन करना चाहिए, इसलिए मुझे आशा है कि यह आपके लिए अच्छा काम करेगा। - Franci
हाँ यह चाहिए! मैं सभी चीनी उपसर्गों को अवरुद्ध कर रहा था। मैं इस दृष्टिकोण को आजमाऊंगा जो बेहतर है :) मुझे लगता है कि बिटोरेंट क्लाइंट रीजेट के साथ भी पुनः प्रयास करना बंद नहीं करेंगे। वे इसे 'कनेक्शन से इनकार कर' के रूप में देखेंगे और थोड़ी देर बाद पुनः प्रयास करेंगे। मेरा मानना ​​है कि डीआरओपी एक बेहतर दृष्टिकोण है (और कम संसाधनों का उपयोग करता है - यह पैकेट को तब भी छोड़ देता है जब वे बिना किसी प्रोसेसिंग के मेल खाते हैं) - Cha0s
अंतर वास्तव में चरम मामलों में काफी नगण्य है, और मेरी आशा अंततः यातायात को रोकना था। यदि यह डायल नहीं करता है तो मैं इसे डीआरओपी में बदल दूंगा। मैं बहुत उत्सुक हूं कि यह पहली जगह क्यों हुआ या यह कैसे हुआ। चीन के ग्रेट फ़ायरवॉल के बारे में कुछ चर्चाएं यादृच्छिक आईपी पर रीडायरेक्ट कर रही हैं लेकिन मुझे पूरा यकीन है कि यह मामला यहां नहीं है। - Franci
+1 अच्छा है। हम साथ जा रहे हैं --string "GET /announce" हालांकि, कवर करने के लिए वास्तविक निवेदन। - Linus Kleen


मैंने ब्लॉग पोस्ट को बिटकटेंट क्लाइंट को दूर जाने के बारे में सही तरीके से बताने के बारे में लिखा और दान कभी नहीं किया, जैसा कि दान ने किया था, लेकिन 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";
    }
}

टोरेंट ट्रैकर्स (आमतौर पर) के पास एक मानक यूआरएल होता है जो शुरू होता है /announce या /scrape, इसलिए मैं यूआरएल द्वारा इतनी जल्दी फ़िल्टरिंग को खारिज नहीं करूँगा। यह काम करता हैं।

पूर्ण पोस्ट पर है - http://dvps.me/ddos-attack-by-torrent


5
2018-01-21 16:37



दिलचस्प पढ़ा। साझा करने के लिए धन्यवाद :) लेकिन मेरा मानना ​​है कि हमले के माध्यम से प्रेरित किया गया था DNS Cache Poisoning चूंकि चीन में सीईआरएनईटी यादृच्छिक और गैर-चीनी आईपी के साथ टीपीबी डोमेन का जवाब देता है। AFAIK PEX सहकर्मियों को साझा करने के लिए है, न कि ट्रैकर्स। क्या आप उस पर अधिक विस्तार कर सकते हैं या कुछ दस्तावेज प्रदान कर सकते हैं? - Cha0s
यहां वर्णित ट्रैकर्स साझा करने के लिए एक एक्सटेंशन है bittorrent.org/beps/bep_0028.html। लेकिन आप इन सभी अनुरोधों के लिए 'होस्ट:' हेडर में सही हैं a.tracker.thepiratebay.org या tracker.thepiratebay.org जो इन ग्राहकों का वास्तविक लक्ष्य हो सकता है या नहीं। यह नकली क्लाइंट भी चीनी बिट्टोरों के रूप में खुद को मास्क कर सकते हैं :) - Evgeny
bittorrent लोग 404 के बजाय 410 सुझाव देते हैं: engineering.bittorrent.com/2015/01/29/... - ysth


मैंने चीनी आईपी श्रेणियों को यहां से लिया: 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

0
2018-02-05 07:18



या आप बस जोड़ सकते हैं CC_DENY = "CN" पर /etc/csf/csf.conf और यह स्वचालित रूप से चीनी उपसर्गों को मैक्समिंड के जियोआईपी डेटाबेस के आधार पर पायेगा। - Cha0s
धन्यवाद, लेकिन मुझे यकीन नहीं है कि सीपीयू उपयोग, सीसी_DENY या प्रत्यक्ष आईपी अवरोधन जैसे कम सर्वर संसाधनों का उपभोग कौन सा तरीका है। मैं कहूंगा कि प्रत्यक्ष आईपी अवरोधन बेहतर है। - user3601800
मुझे कोई मतभेद नज़र नहीं आ रहा है। एक बार iptables नियम लोड हो जाते हैं (एक तरफ या दूसरा - नियम एक ही अनिवार्य रूप से हैं) सिस्टम पर लोड वही होगा। केवल अंतर यह है कि आपकी सूची स्थैतिक है (इसलिए आपको इसे मैन्युअल रूप से अद्यतित रखना होगा) जबकि जियोआईपी डेटाबेस की सूची समय-समय पर स्वचालित रूप से अपडेट की जाएगी ताकि देश के किसी भी नए या अप्रचलित उपसर्ग को प्रतिबिंबित किया जा सके। किसी भी तरह से जब आप iptables के साथ कई उपसर्गों को अवरुद्ध करते हैं, तो आपके पास सिस्टम पर अतिरिक्त भार होगा। लोड iptables से आता है, जिस तरह से आप ब्लॉक करने के लिए उपसर्ग को खोजने के तरीके से नहीं। - Cha0s
मुझे कहना है कि सीएसएफ में देश कोड सीएन को अवरुद्ध करना मेरे लिए काम नहीं करता है, आज मुझे चीन से नए आईपी मिल गए हैं mod_security - user3601800