हमारे ग्राहकों में से एक के ऑनलाइन स्टोर की सुरक्षा के लिए काम करते समय, हमें कई बार एक जिज्ञासु क्रूरतापूर्ण हमले का सामना करना पड़ा, जिसका मुकाबला करना इतना आसान नहीं था। यह एक सरल से अनुग्रह समाधान पर आधारित था जिसने हमले को अपनी तरह के रैंकों से अलग किया। वह क्या थी और कैसे हम अभी भी उससे खुद का बचाव करते हैं, कटौती के तहत पढ़ें।
जैसा कि आप जानते हैं, "क्लासिक" ब्रूट-फोर्स एक डेटा ब्रूट फोर्स अटैक है। उदाहरण के लिए, प्रसिद्ध खातों को लिया जाता है, और पासवर्ड को उनके लिए कुछ मानदंडों के अनुसार चुना जाता है, या तो मक्खी पर या चोरी किए गए शब्दकोशों पर आधारित होता है। यह खातों को हैक करने का मूल तरीका है।
और जिस मामले का मैंने वर्णन किया है, उसमें हमलावरों ने थोड़ा अलग अभिनय किया। सबसे पहले, उन्होंने कई सौ संक्रमित कंप्यूटरों से विभिन्न देशों के बीच वितरित एक बड़े बॉटनेट का उपयोग किया। मॉनिटरिंग सिस्टम में, सब कुछ ऐसा दिखता था जैसे वे पूरी तरह से अलग कंप्यूटर थे, या प्रॉक्सी जो वास्तविक लोग साइट पर बैठे थे और पहुंच रहे थे। इस तरह का हमला लंबे समय तक किसी का ध्यान नहीं जा सकता है।
हमले की दूसरी विशेषता, इसके मजबूत भौगोलिक वितरण के अलावा, लॉगिन नहीं, बल्कि लॉगिन की गणना थी। हमलावरों ने संभवतः लोकप्रिय पासवर्ड और चोरी की लॉगिन सूचियों के शब्दकोशों का उपयोग किया था। और पहले एक लॉगिन ज्ञात पासवर्ड पर ले जाया गया, फिर दूसरा, तीसरा और इसी तरह। यह उस स्थिति के समान था जब एक प्रदाता के माध्यम से जुड़े सामान्य उपयोगकर्ता अपने पासवर्ड से लॉग इन नहीं कर सकते। यानी पहली नजर में अपराधी कुछ भी नहीं। इसके अलावा, संसाधन तक पहुंच बहुत कम थी - एक या दो प्रति मिनट।
हमले की तीसरी विशेषता यह थी कि बॉटनेट के पास बहुत ही "मानवीय" व्यवहार था: ग्राहकों ने जावास्क्रिप्ट को संसाधित किया, कुकीज़ को स्वीकार किया।
कारकों के इस परिसर के कारण, हमले लंबे समय तक किसी का ध्यान नहीं गया। जब हमने इसे खोजा, तब हमने अपने आप से एक गैर-तुच्छ प्रश्न पूछा: अपना बचाव कैसे करें? उपयोगकर्ता एजेंट में एक निश्चित त्रुटि के अपवाद के साथ सभी बॉटनेट कंप्यूटरों में कोई विशेष विशिष्ट विशेषताएं नहीं थीं। लेकिन हमने इस संकेत के आधार पर हमले को अवरुद्ध नहीं किया, क्योंकि इस मामले में हम हमलावर के कार्यों को देखना बंद कर देंगे। कुछ अन्य विसंगतियों को उजागर करना आवश्यक था। आईपी पतों के संदर्भ में कुछ खास नहीं हुआ। लॉगइन को ब्लॉक करना भी असंभव है जो बड़ी संख्या में असफल लॉगिन प्रयास करता है, क्योंकि आवृत्ति बहुत कम है, और लॉगिन को हाथापाई नहीं की जाती है। एक ही रास्ता था - कैप्चा शुरू करने का। लेकिन ग्राहक वास्तव में ऐसा नहीं करना चाहते थे, क्योंकि उनका मानना था कि कैप्चा कई ग्राहकों को अलग कर सकता है। इस बीच, हमलावर पहले ही कुछ खातों के लिए सही संयोजन चुनने में कामयाब रहे हैं।
निश्चित रूप से आप हैरान हैं: कोई ऑनलाइन स्टोर के ग्राहकों के खातों में क्यों टूट जाएगा? तथ्य यह है कि आपके खाते में बोनस अंक जमा होते हैं, जिसका उपयोग माल पर छूट प्राप्त करने के लिए किया जा सकता है। शायद कोई वास्तव में इंटरनेट पर बोनस अंक खरीदना या बेचना चाहता था।
नतीजतन, हमने क्लाइंट को F5 टूल का उपयोग करके कैप्चा को लागू करने के लिए राजी किया: यह एक निश्चित संख्या में असफल प्रविष्टियों के बाद दिखाई देना चाहिए था। लेकिन पहले, सिस्टम में सफल लॉगिन के मानदंड को कॉन्फ़िगर करना आवश्यक था। यह दिखने में थोड़ा अधिक जटिल निकला, क्योंकि कुछ मामलों में संसाधन किसी भी लॉगिन प्रयासों के लिए समान प्रतिक्रिया कोड देता है। लॉगिन की सफलता के लिए एक मानदंड के रूप में, हमने ग्राहक डोमेन कुकीज़ भेजने के लिए चुना।
F5 ASM के नवीनतम संस्करण में, डिवाइस आईडी के संदर्भ में चयन के प्रयासों का जवाब देना संभव हो गया - एक अद्वितीय ब्राउज़र पहचानकर्ता। एक JS कोड पृष्ठ पर जोड़ा जाता है, और जब संक्रमित मशीन इस पृष्ठ को खोलता है, तो यह अपने विशिष्ट पहचानकर्ता की रिपोर्ट करता है। हमारे हमलावरों के मामले में, यह पता चला कि ब्राउज़र का डिवाइस आईडी प्रत्येक आईपी पते के लिए समान था। यही है, वास्तव में, एक ब्राउज़र एक आईपी पते से पहुँचा।
इसलिए, आप निम्न मानदंड निर्धारित कर सकते हैं: यदि 15 मिनट के भीतर एक ब्राउज़र से 5 से अधिक असफल लॉगिन प्रयास किए जाते हैं, तो इस क्लाइंट को एक कैप्चा दिखाया जाएगा। यदि यह वास्तव में सामान्य उपयोगकर्ता है, तो वह इसे हल करेगा और शांति से लॉग इन करेगा। यदि ब्राउज़र जावास्क्रिप्ट का समर्थन नहीं करता है, तो हमने अपवाद जोड़े हैं। लेकिन, सुरक्षा को कमजोर न करने के लिए, हमने एक अलग मानदंड का उपयोग किया: यदि एक आईपी पते से 20 से अधिक असफल लॉगिन प्रयास किए जाते हैं, तो एक कैप्चा फिर से पेश किया जाता है। फिर से: एक सामान्य उपयोगकर्ता के लिए, यह समस्याएं पैदा नहीं करेगा।
लेकिन आज कैप्चा का उपयोग करके सुरक्षा को दरकिनार करने के पहले से ही तरीके हैं। उदाहरण के लिए, बॉटनेट ने कैप्चा को "आउटसोर्सिंग" में भेजा - चीन या भारत में, जहां एक छोटे से शुल्क के लिए मेहनती स्थानीय लोग कैप्चा को हल करते हैं और पाठ मूल्यों को वापस करते हैं। लेकिन इस मामले में, आप उचित उपाय कर सकते हैं: भले ही लॉगिन प्रयास असफल रहे हों, यदि विशिष्ट प्रयासों की निर्दिष्ट संख्या पार हो गई है, तो लॉगिन प्रयासों को एक विशिष्ट आईपी या डिवाइस आईडी से अवरुद्ध किया जा सकता है।
पिछली बार ऑनलाइन स्टोर पर इस तरह से हमला किया गया था, हमने कैप्चा को प्रबंधित किया, और यह काम किया। इसकी शुरुआत के बाद, ब्रूट-बल हमला धीरे-धीरे फीका पड़ने लगा और आखिरकार यह बंद हो गया। तब से लगभग एक साल बीत चुका है - कोई रिलेप्स नहीं थे।
आंद्रेई चेरनिख, सूचना सुरक्षा केंद्र जेट इन्फोसिस्टम्स के विशेषज्ञ