हॉस्टल के दृष्टिकोण से सीएमएस पर ब्रूट बल का हमला

यह कोई रहस्य नहीं है कि जानवर बल (ब्रूट बल) द्वारा एक पासवर्ड का चयन करने का प्रयास एक निरंतर घटना है। वे मेलबॉक्स और सामाजिक नेटवर्क के लिए साइट व्यवस्थापक पृष्ठों और एफ़टीपी खातों के लिए सर्वर और आभासी मशीनों के लिए पासवर्ड का चयन करते हैं।

आमतौर पर, जानवर बल पृष्ठभूमि में होता है और व्यावहारिक रूप से संसाधनों के मालिकों के लिए ध्यान देने योग्य नहीं होता है, क्योंकि एक महत्वपूर्ण भार नहीं बनाता है और साइट के साथ हस्तक्षेप नहीं करता है, कम से कम जब तक खलनायक सर्वर में प्रवेश नहीं करता है :)

1 अगस्त को, शायद सबसे आम मुफ्त सीएमएस का उपयोग करके बनाई गई साइटों पर सबसे शक्तिशाली रन-अप जानवर बल हमला: Wordpress, Joomla! और अन्य



और यह इस प्रकार था:

मेगा ब्रूटफॉर के लिए फैशन हम तक पहुंच गया है

इसी साल अप्रैल में वर्डप्रेस साइटों पर एक समान हमला किया गया था। इस हमले ने मुख्य रूप से पश्चिमी संसाधनों को प्रभावित किया, और रूसी उपयोगकर्ताओं और होस्टिंग प्रदाताओं ने इसे नोटिस नहीं किया। इस बार, बॉटनेट का लक्ष्य मुख्य रूप से रूसी-भाषा साइटों को हैक करना है।



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

ऊपर दिए गए चार्ट पर, ऐसा लग सकता है कि 31 जुलाई की शुरुआत में कुछ होने लगा था, मैंने इस पल को एक लाल रेखा के साथ भी उजागर किया। जैसा कि आगे के शोध से पता चला है, यह एक स्थानीय विसंगति थी जो किसी हमले की शुरुआत के कारण नहीं, बल्कि एक नोड पर लोड के कारण हुई थी। विवरण के साथ इस ग्राफ के अनुसार, विसंगति के स्रोत की पहचान करना आसान है:



नोड को जानने के बाद, आप गहराई तक जा सकते हैं और पता लगा सकते हैं कि वास्तव में कौन लोड बनाता है:

जैसा कि आप देख सकते हैं, क्लाइंट वर्चुअल सर्वरों में से एक में वृद्धि हुई गतिविधि। इसी समय, सर्वर पड़ोसियों के साथ सब कुछ ठीक है और अन्य नोड्स पर सब कुछ ठीक है। इससे हम यह निष्कर्ष निकालते हैं कि मामला जांच हमले से संबंधित नहीं है, अर्थात्। 1 अगस्त से बड़ी क्रूर सेना शुरू हुई।

लड़ते हुए बॉट्स

बॉट्स का व्यवहार मानक था: वे विशिष्ट सीएमएस प्राधिकरण पृष्ठ पर चले गए। उदाहरण के लिए, WP के लिए, यह wp-login.php पेज है। पहले चरण में, हमले के हमले काफी अनाड़ी थे: बॉट्स ने पहले पृष्ठ (जीईटी) प्राप्त किए बिना तुरंत एक फॉर्म में एक पोस्ट लॉगिन और पासवर्ड बनाया। इस प्रकार, इस स्तर पर उन्हें वास्तविक उपयोगकर्ताओं से अलग करना बहुत आसान था, जिन्होंने पहले पेज प्राप्त किया, और फिर उपयोगकर्ता नाम और पासवर्ड दर्ज किया।

इस सुविधा का उपयोग करके, बॉट्स को जल्दी से अवरुद्ध कर दिया गया। स्वाभाविक रूप से, इसके बाद, हमलावरों ने बॉट्स के व्यवहार में समायोजन किया। उन्होंने कुकीज़ के साथ काम करना और काम करना सीखा।

उसके बाद, संभावित कवर विकल्प थे:
1) प्राधिकरण पृष्ठ का नाम बदलना;
2) आईपी-पते (श्वेत सूची, भौगोलिक या विभाजन के अन्य सिद्धांत) द्वारा व्यवस्थापक अनुभाग तक पहुंच का प्रतिबंध;
3) दोहरा प्राधिकरण।

प्राधिकरण पृष्ठ का नामकरण अच्छी तरह से Wordpress के लिए विशेष रूप से अनुकूल है, जैसा कि नतीजतन, कुछ भी नहीं टूटता है और आप काम करना जारी रख सकते हैं। लेकिन इस तथ्य से नहीं कि यह विधि अन्य सीएमएस के लिए अच्छी तरह से काम करती है। प्रणाली में, एक विशिष्ट स्क्रिप्ट नाम के लिए एक बंधन हो सकता है।
इस प्रकार, यह विधि हमारे लिए एक होस्टिंग प्रदाता के रूप में उपयुक्त नहीं थी, क्योंकि हम बस उनके ज्ञान के बिना सभी क्लाइंट फ़ाइलों को नहीं जा सकते और उनका नाम बदल सकते हैं। यह केवल क्लाइंट द्वारा किया जा सकता है।

IP पते की सफेद सूची द्वारा व्यवस्थापक पैनल तक पहुंच को प्रतिबंधित करना, सभी के लिए उपयुक्त नहीं है, क्योंकि सबसे पहले, लगभग हमेशा इंटरनेट प्रदाता एक गतिशील पता जारी करते हैं, जो सत्र से सत्र तक भिन्न हो सकते हैं, और दूसरी बात, यह बाहर से व्यवस्थापक पैनल तक पहुंच की संभावना को बाहर करता है, उदाहरण के लिए, एक मोबाइल डिवाइस से। इस विकल्प को गैर-कार्यशील के रूप में भी चिह्नित किया गया था।

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

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

होस्टिंग प्रदाताओं की खबर को देखते हुए, कई लोगों ने एक समान विधि का उपयोग किया, लेकिन बहुत ही गुप्त पासवर्ड सेट किए, जिसे ग्राहक केवल तकनीकी सहायता या व्यक्तिगत इलेक्ट्रॉनिक मेलिंग सूची में अनुरोध पर सीख सकता था।

हमें ग्राहकों के संबंध में यह अति-गुप्त दृष्टिकोण निरर्थक और गलत लगा। कभी-कभी व्यवस्थापक पैनल तक पहुंच की तत्काल आवश्यकता होती है, और एक एप्लिकेशन लिखना, कॉल करना या उस संदेश की तलाश करना जिसे आप होस्ट से ढूंढ रहे हैं, बहुत असुविधाजनक हो सकता है। इसलिए, हमने स्पष्ट रूप से पृष्ठ पर अतिरिक्त प्राधिकरण के लिए डेटा को इंगित किया, सरल धारणा के आधार पर कि बॉट्स पढ़ना और सोचना नहीं जानते हैं, और विशेष रूप से हमारे मामले के लिए उन्हें सिखाने के लिए बहुत श्रमसाध्य और कृतघ्न खलनायक व्यायाम है।

अतिरिक्त प्राधिकरण वाला पृष्ठ कुछ इस तरह दिखता है (क्षमा करें, यह पृष्ठ को खूबसूरती से डिजाइन करने से पहले नहीं किया गया था):


हमने इस तथ्य के कारण क्लासिक http-प्राधिकरण का उपयोग करने से भी इनकार कर दिया कि एक पॉप-अप विंडो लॉगिन और पासवर्ड के लिए पूछ रही है क्लाइंट को यह बताने का सबसे सुविधाजनक तरीका नहीं है कि उसके सीएमएस के साथ क्या हुआ और वह इस अनुरोध को क्यों देखता है। ऐसी खिड़की ब्राउज़र को ब्लॉक करती है, डराती है और आपको खुद को उन्मुख करने से रोकती है।

टिप्पणियों

बॉट्स से लड़ने के अलावा, यह देखना हमारे लिए बहुत दिलचस्प था कि उनके प्रयासों को कैसे समन्वित और वितरित किया जाता है। हमारे सिस्टम से एनालिटिक्स को देखते हुए, इस पते पर हमला किए गए साइटों की संख्या की परवाह किए बिना, प्रत्येक सीएमएस के लिए 1 होस्टिंग आईपी-एड्रेस के लिए एक साथ अनुरोधों की संख्या 30 से अधिक नहीं रखी गई है। इस प्रकार, यदि Wordpress और Joomla! एक ही आईपी-एड्रेस पर होस्ट किए जाते थे, तो एक साथ कॉल की संख्या 60 थी। यह साझा होस्टिंग के लिए काफी है।

यदि साइट ने जवाब देना बंद कर दिया है, तो इसके लिए अनुरोध तुरंत रोक दिए गए हैं। यह उचित है क्योंकि हमलावरों को पीड़ित को जीवित छोड़ने के लिए यह अधिक लाभदायक है। हालांकि, 60 समवर्ती अनुरोध साइट मालिकों और होस्टिंग प्रदाताओं दोनों द्वारा देखे जाने की गारंटी देने के लिए एक बड़ी पर्याप्त धारा है। एक राय है कि यह खलनायक के लिए अनुरोधों की एक छोटी सी धारा को 3-4 गुना करने के लिए खलनायक के लिए अधिक उचित होगा। इस मामले में, बॉटनेट की गतिविधि बहुत कम ध्यान देने योग्य होगी।

हमले का सक्रिय चरण शाम को शुरू हुआ और पूरी रात चला। बॉट को साइट पते वर्णानुक्रम में दिए गए थे।
इस प्रकार, शाम को A अक्षर से शुरू होने वाली साइटों को नुकसान होने लगा, और सुबह के करीब, Z पर साइटें। इस अर्थ में, वे थोड़ा भाग्यशाली थे।

और लड़ाई फिर से जारी है

अब हमला जारी है, यद्यपि काफी कम गति से। हम साझा होस्टिंग उपयोगकर्ताओं के लिए हमले से नुकसान को कम करने में कामयाब रहे। समर्पित भौतिक और आभासी सर्वर के उपयोगकर्ता जोखिम में रहते हैं। इस स्थिति में, CMS व्यवस्थापक पैनल के लिए केंद्रीय रूप से पहुंच को कवर करना असंभव है और सर्वर व्यवस्थापक द्वारा सुरक्षा उपाय किए जाने चाहिए।

आपका ध्यान के लिए धन्यवाद! :)

बॉट्स के खिलाफ लड़ाई में सभी सफलता। ऊपर से आत्मरक्षा के तरीके घोषित किए गए हैं। यदि आपके पास एक शांत तैयार नुस्खा है - कृपया टिप्पणी करें!