DDoS मदद करने के लिए: हम तनाव और तनाव परीक्षण कैसे करते हैं

Variti बॉट और DDoS हमलों से सुरक्षा विकसित करती है, और तनाव और भार परीक्षण भी करती है। हाईलाड ++ 2018 सम्मेलन में, हमने विभिन्न प्रकार के हमलों से संसाधनों को सुरक्षित करने के बारे में बात की। संक्षेप में: सिस्टम के अलग-अलग हिस्सों, क्लाउड सेवाओं और सीडीएन का उपयोग करें और नियमित रूप से अपडेट करें। लेकिन विशेष कंपनियों के बिना, सुरक्षा आप अभी भी नहीं कर सकते :)

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


कई कंपनियों को पहले से ही पता है कि तनाव परीक्षण कैसे करना है, लेकिन सभी तनाव परीक्षण नहीं करते हैं। हमारे कुछ ग्राहक सोचते हैं कि उनकी साइट अतुलनीय है क्योंकि उनके पास एक उच्च भार प्रणाली है और यह हमलों से बचाता है। हम दिखाते हैं कि यह पूरी तरह सच नहीं है।

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

हम कैसे काम करते हैं?

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

तत्वों

बहुत कुछ अच्छा नहीं है

जितना कम लोड हम संसाधन को विफलता में ला सकते हैं, उतना ही बेहतर होगा। यदि आप साइट को प्रति सेकंड एक अनुरोध या प्रति मिनट एक अनुरोध से भी काम करना बंद करने का प्रबंधन करते हैं, तो यह ठीक है। क्योंकि मतलबी कानून के अनुसार, उपयोगकर्ता या हमलावर गलती से इस जोखिम में पड़ जाते हैं।

आंशिक विफलता पूर्ण विफलता से बेहतर है

हम हमेशा सिस्टम को विषम बनाने की सलाह देते हैं। इसके अलावा, यह उन्हें भौतिक स्तर पर अलग करने के लायक है, न कि केवल कंटेनरीकरण। भौतिक पृथक्करण के मामले में, भले ही साइट पर कुछ विफल हो, यह संभावना है कि यह पूरी तरह से काम करना बंद नहीं करेगा, और उपयोगकर्ताओं के पास अभी भी कार्यक्षमता के कम से कम हिस्से तक पहुंच होगी।

उचित वास्तुकला स्थिरता की नींव है

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

न केवल कोड अच्छा होना चाहिए, बल्कि एक कॉन्फ़िगरेशन भी होना चाहिए

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

तनाव और तनाव परीक्षण के बीच अंतर

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

एल 7 हमलों की विशिष्ट विशेषताएं

हम आमतौर पर लोड के प्रकारों को एल 7 और एल 3 और 4 के स्तर पर लोड में विभाजित करते हैं। L7 आवेदन स्तर पर एक लोड है, सबसे अधिक बार इसे केवल HTTP के रूप में समझा जाता है, लेकिन हमारा मतलब है कि टीसीपी प्रोटोकॉल स्तर पर कोई लोड।

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

HTTP बाढ़

किसी भी हमले के मामले में, भार को संभालने की तुलना में बनाना आसान है, और एल 7 के मामले में यह भी सच है। आक्रमण ट्रैफ़िक को हमेशा वैध से अलग करना आसान नहीं होता है, और अक्सर यह आवृत्ति द्वारा किया जा सकता है, लेकिन अगर सब कुछ सही ढंग से योजनाबद्ध है, तो यह समझना असंभव है कि हमला कहां है और लॉग से वैध अनुरोध कहां हैं।

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



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

क्या देखना है

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

जहां देखो

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

हम सबडोमेन को भी स्कैन करते हैं। उदाहरण के लिए, एक निश्चित ऑनलाइन स्टोर है, abc.com, और इसमें एक उपडोमेन admin.abc.com है। सबसे अधिक संभावना है, यह प्राधिकरण के साथ व्यवस्थापक पैनल है, लेकिन यदि आप इसमें लोड डालते हैं, तो यह मुख्य संसाधन के लिए समस्याएं पैदा कर सकता है।

साइट में एक उपडोमेन api.abc.com हो सकता है। सबसे अधिक संभावना है, यह मोबाइल एप्लिकेशन के लिए एक संसाधन है। एप्लिकेशन को ऐप स्टोर या Google Play में पाया जा सकता है, एक विशेष पहुंच बिंदु डाल सकता है, एपीआई को विच्छेद कर सकता है और परीक्षण खातों को पंजीकृत कर सकता है। समस्या यह है कि अक्सर लोग सोचते हैं कि प्राधिकरण द्वारा संरक्षित सब कुछ सेवा हमलों से इनकार करने के लिए प्रतिरक्षा है। कथित तौर पर, प्राधिकरण सबसे अच्छा कैप्चा है, लेकिन ऐसा नहीं है। 10-20 परीक्षण खाते बनाना सरल है, और उन्हें बनाने से, हमें जटिल और अविवादित कार्यक्षमता तक पहुंच मिलती है।

स्वाभाविक रूप से, हम robots.txt और WebArchive, ViewDNS में इतिहास को देखते हैं, हम संसाधन के पुराने संस्करणों की तलाश कर रहे हैं। कभी-कभी ऐसा होता है कि डेवलपर्स रोल आउट करते हैं, कहते हैं, mail2.yandex.net, लेकिन पुराने संस्करण, mail.yandex.net, बने रहे। यह mail.yandex.net अब समर्थित नहीं है, विकास संसाधनों को इसके लिए आवंटित नहीं किया गया है, लेकिन यह डेटाबेस का उपभोग करना जारी रखता है। तदनुसार, पुराने संस्करण का उपयोग करके, आप प्रभावी रूप से बैकएंड के संसाधनों और लेआउट के पीछे की सभी चीजों का उपयोग कर सकते हैं। बेशक, यह हमेशा नहीं होता है, लेकिन हम अभी भी कुछ इस तरह से मुठभेड़ करते हैं।

स्वाभाविक रूप से, हम सभी अनुरोध मापदंडों, कुकी संरचना को विच्छेदित करते हैं। आप कह सकते हैं, कुकी के अंदर JSON सरणी में कुछ मान पुश करें, अधिक घोंसला बनाएं और संसाधन को अनुचित रूप से लंबे समय तक काम करें।

खोज भार

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

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

इसके अलावा, यह पृष्ठांकन का उपयोग करने के लायक है: किसी खोज के लिए पहले की तुलना में किसी पृष्ठ के पृष्ठ का अंतर लौटना अधिक कठिन है। यही है, पेजिंग की मदद से, आप लोड को थोड़ा विविधता दे सकते हैं।

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

अगर कोई खोज नहीं है?

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

टिप्पणियों और प्रतिक्रिया के लिए सभी प्रकार के रूपों की साइट पर उपस्थिति बहुत बड़े ग्रंथों को वहां भेजने या बस एक बड़े पैमाने पर बाढ़ बनाने का एक अवसर है। कभी-कभी साइटें फ़ाइल अटैचमेंट स्वीकार करती हैं, जिसमें gzip फॉर्मेट भी शामिल है। इस मामले में, हम 1TB फ़ाइल लेते हैं, gzip का उपयोग करके हम इसे कुछ बाइट्स या किलोबाइट्स में संपीड़ित करते हैं और इसे साइट पर भेजते हैं। फिर इसे अनज़िप किया जाता है और एक बहुत ही रोचक प्रभाव प्राप्त किया जाता है।

बाकी एपीआई

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

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

भारी सामग्री लोड

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



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



यहां लोड जड़ तक चला गया और केवल 10 आरपीएस की राशि हुई। हमने 5 मिनट इंतजार किया और सर्वर क्रैश हो गया। हालांकि, यह ज्ञात नहीं है कि वह क्यों गिर गया, लेकिन एक धारणा है कि वह बस स्मृति से भरा था, और इसलिए जवाब देना बंद कर दिया।

तरंग आधारित

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

हमले के मामले में, नीचे 10 मिनट का अंतराल था, जिसके बाद हमले का एक नया, संशोधित हिस्सा आ गया।



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

वेव हमलों को चरम पर बहुत उच्च मूल्यों की विशेषता है, यह एल 7 के मामले में प्रति सेकंड एक लाख या एक लाख अनुरोधों तक पहुंच सकता है। अगर हम L3 & 4 के बारे में बात करते हैं, तो यातायात के सैकड़ों गीगाबिट हो सकते हैं, या, तदनुसार, सैकड़ों mpps, यदि आप पैकेट में गिनते हैं।

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

HTTP एकीकृत नहीं

L7 स्तर पर HTTP के अलावा, हम अन्य प्रोटोकॉल का फायदा उठाना पसंद करते हैं। एक नियम के रूप में, एक नियमित वेबसाइट, विशेष रूप से एक नियमित होस्टिंग, में मेल प्रोटोकॉल और MySQL चिपके रहते हैं। मेल प्रोटोकॉल डेटाबेस से कम प्रभावित होते हैं, लेकिन वे भी काफी कुशलता से लोड किए जा सकते हैं और आउटपुट पर सर्वर पर एक अतिभारित सीपीयू प्राप्त कर सकते हैं।

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

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

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

एल 3 और 4

जब हम L3 & 4 स्तरों पर हमले के बारे में बात करते हैं, तो हम आमतौर पर चैनल स्तर पर हमले के बारे में बात करते हैं। इस तरह का भार लगभग हमेशा वैध से अलग होता है अगर यह SYN बाढ़ का हमला नहीं है। सुरक्षा सुविधाओं के लिए SYN बाढ़ के हमलों की समस्या बड़ी है। L3 & 4 का अधिकतम मूल्य 1.5-2 Tb / s था। ऐसी ट्रैफ़िक को ओरेकल और Google सहित बड़ी कंपनियों के लिए भी संभालना बहुत मुश्किल है।

SYN और SYN-ACK पैकेज हैं जो कनेक्शन स्थापित करने के लिए उपयोग किए जाते हैं। इसलिए, SYN-बाढ़ को एक वैध लोड से अलग करना मुश्किल है: यह स्पष्ट नहीं है कि यह SYN है, जो कनेक्शन, या बाढ़ का हिस्सा स्थापित करने के लिए आया था।

यूडीपी बाढ़

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



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

मुश्किल SYN-बाढ़

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

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

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

परीक्षण के दौरान, हम कुछ बाहरी संसाधनों द्वारा मेमकेड के माध्यम से प्रवर्धन का उपयोग नहीं कर सकते हैं, क्योंकि केवल आईपी पते के लिए यातायात की आपूर्ति करने के लिए समझौते हैं। तदनुसार, हम SYN और SYN-ACK के माध्यम से प्रवर्धन का उपयोग करते हैं, जब सिस्टम एक SYN भेजने के लिए दो या तीन SYN-ACKs भेजने के साथ प्रतिक्रिया करता है, और आउटपुट दो से तीन गुना गुणा होता है।

उपकरण

L7 स्तर पर लोड के लिए हम जिन मुख्य उपकरणों का उपयोग करते हैं, उनमें से एक है यैंडेक्स-टैंक। विशेष रूप से, एक प्रेत का उपयोग बंदूक के रूप में किया जाता है, साथ ही कारतूस उत्पन्न करने और परिणामों का विश्लेषण करने के लिए कई स्क्रिप्ट हैं।

Tcpdump का उपयोग नेटवर्क ट्रैफ़िक का विश्लेषण करने के लिए किया जाता है, और Nmap का उपयोग सर्वर ट्रैफ़िक के विश्लेषण के लिए किया जाता है। L3 और 4 के स्तर पर लोड बनाने के लिए, OpenSSL का उपयोग किया जाता है और DPDK लाइब्रेरी के साथ इसका अपना जादू होता है। DPDK इंटेल से एक लाइब्रेरी है जो आपको लिनक्स स्टैक को दरकिनार कर नेटवर्क इंटरफेस के साथ काम करने की अनुमति देती है, और इस तरह दक्षता में वृद्धि होती है। स्वाभाविक रूप से, हम डीपीडीके का उपयोग न केवल एल 3 और 4 के स्तर पर करते हैं, बल्कि एल 7 स्तर पर भी करते हैं, क्योंकि यह आपको एक मशीन से प्रति सेकंड कुछ मिलियन अनुरोधों के भीतर एक बहुत ही उच्च लोड प्रवाह बनाने की अनुमति देता है।
हम कुछ ट्रैफ़िक जनरेटर और विशेष टूल का भी उपयोग करते हैं जो हम विशिष्ट परीक्षणों के लिए लिखते हैं। यदि हम SSH के तहत भेद्यता को याद करते हैं, तो उपरोक्त सेट के साथ, यह बच नहीं सकता है। यदि हम मेल प्रोटोकॉल पर हमला करते हैं, तो हम मेल यूटिलिटीज लेते हैं या उन पर स्क्रिप्ट लिखते हैं।

निष्कर्ष

परिणामस्वरूप, मैं कहना चाहूंगा:

• शास्त्रीय भार परीक्षण के अलावा, तनाव परीक्षण भी किया जाना चाहिए। हमारे पास एक वास्तविक दुनिया का उदाहरण है जहां एक भागीदार उपठेकेदार ने केवल लोड परीक्षण किया। यह दिखाया गया है कि संसाधन मानक लोड को रोक देता है। लेकिन फिर एक असामान्य भार दिखाई दिया, साइट आगंतुकों ने संसाधन को थोड़ा अलग तरीके से उपयोग करना शुरू कर दिया, और आउटपुट पर उपठेकेदार को नीचे रखा गया। इस प्रकार, यह कमजोरियों की तलाश के लायक है, भले ही आप पहले से ही DDoS हमलों से सुरक्षित हों।
• सिस्टम के कुछ हिस्सों को दूसरों से अलग करना आवश्यक है। , , . , - . - , , , , OAuth2.
• .
• CDN , .
• . L3&4 , , , . L7 , . , - , .
• . , SSH daemon, . , , .