DDoS हमले के लिए तैयार!

शुभ दोपहर, Khabrovites! आज हम आपके साथ DDoS हमले की स्थिति में सुरक्षा के लिए स्व-तैयारी पर अपने विचार साझा करेंगे। विषय दर्दनाक है , और न केवल एलजे उपयोगकर्ताओं और अन्य हमला साइटों के बीच, बल्कि हमारे कैस्पर्सकी डीडीओएस रोकथाम परियोजना के विशेषज्ञ भी हैं।


रूस में DDoS हमलों की ख़ासियत

DDoS एक तत्व है। तत्वों की भविष्यवाणी करना असंभव है, लेकिन इसके लिए तैयारी करना आवश्यक है।

एक ज्वलंत उदाहरण एक जीवन-यात्रा है और जहाजों पर नावें हैं। यह संभावना नहीं है कि वे सर्वशक्तिमान Cthulhu से बचाएंगे, लेकिन वे औसत तूफान और अन्य सामान्य घटनाओं से काफी सामना कर सकते हैं।

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

DDoS सुरक्षा समाधानों के सभी प्रदाताओं द्वारा सुरक्षा के लिए इंटरनेट संसाधन का त्वरित रूप से उपयोग एक जैसा दिखता है: आपको अपने संसाधन के DNS रिकॉर्ड में IP पता बदलने के लिए कहा जाएगा।

यहां तक ​​कि अगर आपको किसी प्रकार की सुरक्षित होस्टिंग में जाने की पेशकश की जाती है - तो भी यह पता बदलने की कोशिश करता है। इसलिए, बहुत पहले "बचाव उपकरण" है:
1. उपलब्धता में डीएनएस रिकॉर्ड को बदलने के लिए क्रेडेंशियल्स की उपस्थिति;
2. संसाधन नाम के DNS रिकॉर्ड के जीवनकाल की प्रारंभिक कमी 10-15 मिनट।

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

दूसरे, अग्रिम में निर्दिष्ट करें कि आपके संसाधन के संचालन के दौरान कौन से प्रोटोकॉल का उपयोग किया जाता है। कुछ संसाधन मालिकों के लिए, यह एक रहस्योद्घाटन हो जाता है कि संरक्षित होने के बाद, व्यक्तिगत उपयोगकर्ता डैशबोर्ड और अन्य समान कार्यक्षमता HTTPS प्रोटोकॉल का उपयोग करके काम कर रहे हैं।

हमारे विशेषज्ञ साइटों के चारों ओर घूमते हैं और "छिपी हुई" कार्यक्षमता की पहचान करने की कोशिश करते हैं, लेकिन अगर संसाधन के मालिक को शुरू में इसके बारे में पता था, तो यह आसान होगा।

अग्रिम में संसाधन घटकों की बातचीत की जाँच करें। एक आईपी पते या स्थानीय रास्तों वाले लिंक सुरक्षा के तहत एक हमले वाले घटक को स्थानांतरित करते समय कुछ कार्यक्षमता को काट सकते हैं।

ठीक है, निश्चित रूप से, यह सलाह दी जाती है कि संसाधन को ऐसी स्थिति में न लाया जाए जहां मोर जीवनकाल में "अपने पैरों पर" काम करता है। इसे सत्यापित करना अक्सर मुश्किल होता है, लेकिन साझा होस्टिंग पर होस्ट की गई साइट से लोड को सहन करने की क्षमता के लिए इंतजार करना अक्सर आवश्यक नहीं होता है। हमले के आधार पर, कुछ सहज अनुरोध किसी भी सुरक्षा प्रणाली के माध्यम से जा सकते हैं। फिर से, कोई सुरक्षा प्रणाली मानसिक रूप से एक साधारण उपयोगकर्ता से बॉट की पहचान और अंतर नहीं कर सकती है। विश्लेषण में समय लगता है, जिसके दौरान हमलावर से आग्रहपूर्ण अनुरोध किए जाएंगे। संसाधन को लोड में कम से कम 10-15% वृद्धि का सामना करने में सक्षम होना चाहिए। कैस्परस्काई लैब के अभ्यास में, ऐसे मामले सामने आए हैं जब आपको हर अतिरिक्त छूट के लिए लड़ना पड़ा था: पीकटाइम में, पोर्टल ने प्रति सेकंड 3 अनुरोध संसाधित किए, और हमले के तहत यह पता चला कि प्रति सेकंड 5 अनुरोध इसके लिए घातक थे।

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

जाहिर है, 24x7 मोड में प्रशासकों का परिवर्तन उपलब्ध है और सभी के लिए आवश्यक नहीं है, लेकिन DNS से ​​एक ही पासवर्ड उस व्यक्ति के लिए उपलब्ध होना चाहिए जिसे कभी भी पहुंचा जा सकता है।