Variti बॉट्स और DDoS हमलों के खिलाफ सुरक्षा विकसित करती है, और तनाव और लोड परीक्षण भी करती है। हाईलोड++ 2018 सम्मेलन में हमने विभिन्न प्रकार के हमलों से संसाधनों को सुरक्षित करने के तरीके के बारे में बात की। संक्षेप में: सिस्टम के कुछ हिस्सों को अलग करें, क्लाउड सेवाओं और सीडीएन का उपयोग करें और नियमित रूप से अपडेट करें। लेकिन आप अभी भी विशेष कंपनियों के बिना सुरक्षा संभालने में सक्षम नहीं होंगे :)
पाठ पढ़ने से पहले, आप संक्षिप्त सार पढ़ सकते हैं .
और अगर आपको पढ़ना पसंद नहीं है या आप सिर्फ वीडियो देखना चाहते हैं, तो हमारी रिपोर्ट की रिकॉर्डिंग स्पॉइलर के नीचे है।
रिपोर्ट की वीडियो रिकॉर्डिंग
कई कंपनियाँ पहले से ही जानती हैं कि लोड परीक्षण कैसे किया जाता है, लेकिन सभी तनाव परीक्षण नहीं करते हैं। हमारे कुछ ग्राहक सोचते हैं कि उनकी साइट अजेय है क्योंकि उनके पास हाईलोड सिस्टम है, और यह हमलों से अच्छी तरह से बचाता है। हम दिखाते हैं कि यह पूरी तरह सच नहीं है।
बेशक, परीक्षण करने से पहले, हम ग्राहक से अनुमति लेते हैं, हस्ताक्षरित और मुहर लगाते हैं, और हमारी मदद से किसी पर DDoS हमला नहीं किया जा सकता है। परीक्षण ग्राहक द्वारा चुने गए समय पर किया जाता है, जब उसके संसाधन पर ट्रैफ़िक न्यूनतम होता है, और पहुंच संबंधी समस्याएं ग्राहकों को प्रभावित नहीं करेंगी। इसके अलावा, चूंकि परीक्षण प्रक्रिया के दौरान हमेशा कुछ गलत हो सकता है, इसलिए हमारा ग्राहक के साथ निरंतर संपर्क रहता है। यह आपको न केवल प्राप्त परिणामों की रिपोर्ट करने की अनुमति देता है, बल्कि परीक्षण के दौरान कुछ बदलने की भी अनुमति देता है। परीक्षण पूरा होने पर, हम हमेशा एक रिपोर्ट तैयार करते हैं जिसमें हम पाई गई कमियों को इंगित करते हैं और साइट की कमजोरियों को दूर करने के लिए सिफारिशें देते हैं।
हम कैसे काम कर रहे हैं
परीक्षण करते समय, हम एक बॉटनेट का अनुकरण करते हैं। चूँकि हम उन ग्राहकों के साथ काम करते हैं जो हमारे नेटवर्क पर नहीं हैं, यह सुनिश्चित करने के लिए कि सीमा या सुरक्षा ट्रिगर होने के कारण परीक्षण पहले मिनट में समाप्त नहीं होता है, हम लोड को एक आईपी से नहीं, बल्कि अपने स्वयं के सबनेट से आपूर्ति करते हैं। साथ ही, एक महत्वपूर्ण भार उत्पन्न करने के लिए, हमारे पास अपना स्वयं का काफी शक्तिशाली परीक्षण सर्वर है।
अभिधारणाएं
बहुत ज्यादा का मतलब अच्छा नहीं है
जितना कम भार हम किसी संसाधन को विफलता की ओर ला सकें, उतना बेहतर है। यदि आप प्रति सेकंड एक अनुरोध, या प्रति मिनट एक अनुरोध पर भी साइट को काम करना बंद कर सकते हैं, तो यह बहुत अच्छा है। क्योंकि क्षुद्रता के नियम के अनुसार, उपयोगकर्ता या हमलावर गलती से इस विशेष भेद्यता में पड़ जाएंगे।
आंशिक विफलता पूर्ण विफलता से बेहतर है
हम हमेशा सिस्टम को विषम बनाने की सलाह देते हैं। इसके अलावा, यह उन्हें भौतिक स्तर पर अलग करने के लायक है, न कि केवल कंटेनरीकरण द्वारा। भौतिक अलगाव के मामले में, भले ही साइट पर कुछ विफल हो जाए, इस बात की बहुत अधिक संभावना है कि यह पूरी तरह से काम करना बंद नहीं करेगा, और उपयोगकर्ताओं को कार्यक्षमता के कम से कम हिस्से तक पहुंच मिलती रहेगी।
अच्छी वास्तुकला स्थिरता का आधार है
किसी संसाधन की दोष सहनशीलता और हमलों और भार को झेलने की उसकी क्षमता को डिज़ाइन चरण में, वास्तव में, नोटपैड में पहला फ़्लोचार्ट खींचने के चरण में निर्धारित किया जाना चाहिए। क्योंकि यदि घातक त्रुटियाँ सामने आती हैं, तो भविष्य में उन्हें ठीक करना संभव है, लेकिन यह बहुत कठिन है।
न केवल कोड अच्छा होना चाहिए, बल्कि कॉन्फिगरेशन भी अच्छा होना चाहिए
बहुत से लोग सोचते हैं कि एक अच्छी विकास टीम दोष-सहिष्णु सेवा की गारंटी है। एक अच्छी विकास टीम वास्तव में आवश्यक है, लेकिन अच्छे संचालन, अच्छे DevOps भी होने चाहिए। अर्थात्, हमें ऐसे विशेषज्ञों की आवश्यकता है जो लिनक्स और नेटवर्क को सही ढंग से कॉन्फ़िगर करेंगे, nginx में सही ढंग से कॉन्फ़िगरेशन लिखेंगे, सीमाएँ निर्धारित करेंगे, आदि। अन्यथा, संसाधन केवल परीक्षण में ही अच्छा काम करेगा, और किसी बिंदु पर उत्पादन में सब कुछ विफल हो जाएगा।
भार और तनाव परीक्षण के बीच अंतर
लोड परीक्षण आपको सिस्टम कार्यप्रणाली की सीमाओं की पहचान करने की अनुमति देता है। तनाव परीक्षण का उद्देश्य किसी प्रणाली में कमजोरियों का पता लगाना है और इसका उपयोग इस प्रणाली को तोड़ने और यह देखने के लिए किया जाता है कि यह कुछ हिस्सों की विफलता की प्रक्रिया में कैसा व्यवहार करेगा। इस मामले में, तनाव परीक्षण शुरू होने से पहले लोड की प्रकृति आमतौर पर ग्राहक के लिए अज्ञात रहती है।
L7 हमलों की विशिष्ट विशेषताएं
हम आमतौर पर लोड के प्रकारों को L7 और L3&4 स्तरों पर लोड में विभाजित करते हैं। L7 एप्लिकेशन स्तर पर एक लोड है, अक्सर इसका मतलब केवल HTTP होता है, लेकिन हमारा मतलब TCP प्रोटोकॉल स्तर पर कोई भी लोड होता है।
L7 हमलों में कुछ विशिष्ट विशेषताएं हैं। सबसे पहले, वे सीधे एप्लिकेशन पर आते हैं, यानी, यह संभावना नहीं है कि वे नेटवर्क माध्यमों से प्रतिबिंबित होंगे। ऐसे हमले तर्क का उपयोग करते हैं, और इसके कारण, वे सीपीयू, मेमोरी, डिस्क, डेटाबेस और अन्य संसाधनों का बहुत कुशलता से और कम ट्रैफ़िक के साथ उपभोग करते हैं।
HTTP बाढ़
किसी भी हमले के मामले में, भार को संभालने की तुलना में बनाना आसान होता है, और L7 के मामले में भी यह सच है। हमले के ट्रैफ़िक को वैध ट्रैफ़िक से अलग करना हमेशा आसान नहीं होता है, और अक्सर यह आवृत्ति द्वारा किया जा सकता है, लेकिन अगर सब कुछ सही ढंग से योजनाबद्ध है, तो लॉग से यह समझना असंभव है कि हमला कहाँ है और वैध अनुरोध कहाँ हैं।
पहले उदाहरण के रूप में, 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 बाढ़ के मामले में होता है।
डेटाबेस में यादृच्छिक क्वेरीज़ बनाना भी हमेशा प्रभावी नहीं होता है। खोज के लिए प्रासंगिक कीवर्ड की एक सूची बनाना कहीं बेहतर है। यदि हम एक ऑनलाइन स्टोर के उदाहरण पर लौटते हैं: मान लें कि साइट कार टायर बेचती है और आपको टायर की त्रिज्या, कार का प्रकार और अन्य पैरामीटर सेट करने की अनुमति देती है। तदनुसार, प्रासंगिक शब्दों का संयोजन डेटाबेस को अधिक जटिल परिस्थितियों में काम करने के लिए बाध्य करेगा।
इसके अलावा, पेजिनेशन का उपयोग करना उचित है: किसी खोज के लिए पहले की तुलना में खोज परिणामों के अंतिम पृष्ठ पर लौटना अधिक कठिन होता है। यानी पेजिनेशन की मदद से आप लोड में थोड़ा विविधता ला सकते हैं।
नीचे दिया गया उदाहरण खोज लोड दिखाता है. यह देखा जा सकता है कि परीक्षण के पहले ही सेकंड से प्रति सेकंड दस अनुरोधों की गति से, साइट बंद हो गई और कोई प्रतिक्रिया नहीं दी।
यदि कोई खोज न हो तो?
यदि कोई खोज नहीं है, तो इसका मतलब यह नहीं है कि साइट में अन्य असुरक्षित इनपुट फ़ील्ड नहीं हैं। यह क्षेत्र प्राधिकरण हो सकता है. आजकल, डेवलपर्स लॉगिन डेटाबेस को रेनबो टेबल हमले से बचाने के लिए जटिल हैश बनाना पसंद करते हैं। यह अच्छा है, लेकिन ऐसे हैश बहुत सारे CPU संसाधनों का उपभोग करते हैं। गलत प्राधिकरणों के एक बड़े प्रवाह के कारण प्रोसेसर विफल हो जाता है, और परिणामस्वरूप, साइट काम करना बंद कर देती है।
साइट पर टिप्पणियों और फीडबैक के लिए सभी प्रकार के प्रपत्रों की उपस्थिति वहां बहुत बड़े पाठ भेजने या बस एक विशाल बाढ़ पैदा करने का एक कारण है। कभी-कभी साइटें संलग्न फ़ाइलें स्वीकार करती हैं, जिनमें gzip प्रारूप भी शामिल है। इस मामले में, हम एक 1TB फ़ाइल लेते हैं, इसे gzip का उपयोग करके कई बाइट्स या किलोबाइट्स में संपीड़ित करते हैं और इसे साइट पर भेजते हैं। फिर इसे अनज़िप किया जाता है और एक बहुत ही दिलचस्प प्रभाव प्राप्त होता है।
बाकी एपीआई
मैं रेस्ट एपीआई जैसी लोकप्रिय सेवाओं पर थोड़ा ध्यान देना चाहूंगा। रेस्ट एपीआई को सुरक्षित करना एक नियमित वेबसाइट की तुलना में कहीं अधिक कठिन है। यहां तक कि पासवर्ड क्रूर बल और अन्य नाजायज गतिविधि के खिलाफ सुरक्षा के तुच्छ तरीके भी रेस्ट एपीआई के लिए काम नहीं करते हैं।
रेस्ट एपीआई को तोड़ना बहुत आसान है क्योंकि यह सीधे डेटाबेस तक पहुंचता है। साथ ही, ऐसी सेवा की विफलता व्यवसाय के लिए काफी गंभीर परिणाम देती है। तथ्य यह है कि रेस्ट एपीआई का उपयोग आमतौर पर न केवल मुख्य वेबसाइट के लिए किया जाता है, बल्कि मोबाइल एप्लिकेशन और कुछ आंतरिक व्यावसायिक संसाधनों के लिए भी किया जाता है। और यदि यह सब गिर जाता है, तो प्रभाव एक साधारण वेबसाइट विफलता की तुलना में बहुत अधिक मजबूत होता है।
भारी सामग्री लोड हो रही है
यदि हमें किसी सामान्य एकल-पृष्ठ एप्लिकेशन, लैंडिंग पृष्ठ, या बिजनेस कार्ड वेबसाइट का परीक्षण करने की पेशकश की जाती है, जिसमें जटिल कार्यक्षमता नहीं है, तो हम भारी सामग्री की तलाश करते हैं। उदाहरण के लिए, सर्वर द्वारा भेजी जाने वाली बड़ी छवियां, बाइनरी फ़ाइलें, पीडीएफ दस्तावेज़ - हम यह सब डाउनलोड करने का प्रयास करते हैं। ऐसे परीक्षण फ़ाइल सिस्टम को अच्छी तरह से लोड करते हैं और चैनलों को रोकते हैं, और इसलिए प्रभावी होते हैं। यानी, भले ही आप सर्वर को बंद न करें, कम गति पर एक बड़ी फ़ाइल डाउनलोड करते हुए, आप बस लक्ष्य सर्वर के चैनल को रोक देंगे और फिर सेवा से इनकार हो जाएगा।
ऐसे परीक्षण का एक उदाहरण दिखाता है कि 30 आरपीएस की गति पर साइट ने प्रत्युत्तर देना बंद कर दिया या 500वीं सर्वर त्रुटियाँ उत्पन्न कीं।
सर्वर स्थापित करने के बारे में मत भूलना. आप अक्सर पा सकते हैं कि एक व्यक्ति ने एक वर्चुअल मशीन खरीदी, वहां अपाचे स्थापित किया, डिफ़ॉल्ट रूप से सब कुछ कॉन्फ़िगर किया, एक PHP एप्लिकेशन इंस्टॉल किया, और नीचे आप परिणाम देख सकते हैं।
यहां लोड जड़ तक चला गया और केवल 10 आरपीएस तक पहुंच गया। हमने 5 मिनट इंतजार किया और सर्वर क्रैश हो गया। यह सच है कि यह पूरी तरह से ज्ञात नहीं है कि वह क्यों गिरा, लेकिन एक धारणा है कि उसकी याददाश्त बहुत अधिक हो गई थी और इसलिए उसने प्रतिक्रिया देना बंद कर दिया।
तरंग आधारित
पिछले एक या दो वर्षों में, तरंग हमले काफी लोकप्रिय हो गए हैं। यह इस तथ्य के कारण है कि कई संगठन DDoS सुरक्षा के लिए हार्डवेयर के कुछ टुकड़े खरीदते हैं, जिन्हें हमले को फ़िल्टर करना शुरू करने के लिए आंकड़े जमा करने के लिए एक निश्चित समय की आवश्यकता होती है। यानी वे पहले 30-40 सेकंड में हमले को फ़िल्टर नहीं करते हैं, क्योंकि वे डेटा जमा करते हैं और सीखते हैं। तदनुसार, इन 30-40 सेकंड में आप साइट पर इतना लॉन्च कर सकते हैं कि संसाधन लंबे समय तक पड़ा रहेगा जब तक कि सभी अनुरोध साफ़ नहीं हो जाते।
नीचे दिए गए हमले के मामले में, 10 मिनट का अंतराल था, जिसके बाद हमले का एक नया, संशोधित हिस्सा आया।
यानी, रक्षा ने सीखा, फ़िल्टर करना शुरू कर दिया, लेकिन हमले का एक नया, पूरी तरह से अलग हिस्सा आया, और रक्षा ने फिर से सीखना शुरू कर दिया। दरअसल, फ़िल्टरिंग काम करना बंद कर देती है, सुरक्षा अप्रभावी हो जाती है और साइट अनुपलब्ध हो जाती है।
तरंग हमलों को चरम पर बहुत उच्च मूल्यों की विशेषता होती है, यह L7 के मामले में प्रति सेकंड एक लाख या दस लाख अनुरोधों तक पहुंच सकता है। यदि हम L3&4 के बारे में बात करते हैं, तो सैकड़ों गीगाबिट ट्रैफ़िक हो सकता है, या, तदनुसार, सैकड़ों एमपीपीएस, यदि आप पैकेट में गिनती करते हैं।
ऐसे हमलों में समस्या सिंक्रनाइज़ेशन की है। हमले एक बॉटनेट से आते हैं और बहुत बड़ी एक बार की स्पाइक बनाने के लिए उच्च स्तर के सिंक्रनाइज़ेशन की आवश्यकता होती है। और यह समन्वय हमेशा काम नहीं करता है: कभी-कभी आउटपुट किसी प्रकार का परवलयिक शिखर होता है, जो काफी दयनीय दिखता है।
अकेले HTTP नहीं
L7 पर HTTP के अलावा, हम अन्य प्रोटोकॉल का फायदा उठाना पसंद करते हैं। एक नियम के रूप में, एक नियमित वेबसाइट, विशेष रूप से एक नियमित होस्टिंग, में मेल प्रोटोकॉल और MySQL चिपके रहते हैं। मेल प्रोटोकॉल डेटाबेस की तुलना में कम लोड के अधीन हैं, लेकिन उन्हें काफी कुशलता से लोड किया जा सकता है और सर्वर पर ओवरलोडेड सीपीयू के साथ समाप्त हो सकता है।
हमें 2016 एसएसएच भेद्यता के साथ काफी वास्तविक रूप से सफलता मिली। अब यह भेद्यता लगभग सभी के लिए तय कर दी गई है, लेकिन इसका मतलब यह नहीं है कि लोड एसएसएच को सबमिट नहीं किया जा सकता है। कर सकना। बस प्राधिकरणों का एक बड़ा भार है, एसएसएच सर्वर पर लगभग पूरे सीपीयू को खा जाता है, और फिर वेबसाइट प्रति सेकंड एक या दो अनुरोधों से ढह जाती है। तदनुसार, लॉग के आधार पर इन एक या दो अनुरोधों को वैध लोड से अलग नहीं किया जा सकता है।
कई कनेक्शन जो हम सर्वर में खोलते हैं वे भी प्रासंगिक बने रहते हैं। पहले, अपाचे इसके लिए दोषी था, अब nginx वास्तव में इसके लिए दोषी है, क्योंकि यह अक्सर डिफ़ॉल्ट रूप से कॉन्फ़िगर किया जाता है। nginx जिन कनेक्शनों को खुला रख सकता है उनकी संख्या सीमित है, इसलिए हम इस संख्या में कनेक्शन खोलते हैं, nginx अब एक नया कनेक्शन स्वीकार नहीं करता है, और परिणामस्वरूप साइट काम नहीं करती है।
हमारे परीक्षण क्लस्टर में एसएसएल हैंडशेक पर हमला करने के लिए पर्याप्त सीपीयू है। सिद्धांत रूप में, जैसा कि अभ्यास से पता चलता है, बॉटनेट भी कभी-कभी ऐसा करना पसंद करते हैं। एक ओर, यह स्पष्ट है कि आप एसएसएल के बिना नहीं कर सकते, क्योंकि Google परिणाम, रैंकिंग, सुरक्षा। दूसरी ओर, एसएसएल में दुर्भाग्य से सीपीयू समस्या है।
एल3&4
जब हम L3&4 स्तरों पर किसी हमले के बारे में बात करते हैं, तो हम आमतौर पर लिंक स्तर पर हमले के बारे में बात कर रहे होते हैं। ऐसा भार लगभग हमेशा वैध भार से भिन्न होता है, जब तक कि यह SYN-बाढ़ हमला न हो। सुरक्षा उपकरणों के लिए SYN-बाढ़ हमलों की समस्या उनकी बड़ी मात्रा है। अधिकतम L3&4 मान 1,5-2 Tbit/s था। इस प्रकार के ट्रैफ़िक को Oracle और Google सहित बड़ी कंपनियों के लिए भी संसाधित करना बहुत कठिन है।
SYN और SYN-ACK ऐसे पैकेट हैं जिनका उपयोग कनेक्शन स्थापित करते समय किया जाता है। इसलिए, SYN-बाढ़ को वैध लोड से अलग करना मुश्किल है: यह स्पष्ट नहीं है कि यह एक SYN है जो कनेक्शन स्थापित करने के लिए आया है, या बाढ़ का हिस्सा है।
यूडीपी बाढ़
आमतौर पर, हमलावरों के पास वे क्षमताएं नहीं होती हैं जो हमारे पास हैं, इसलिए हमलों को व्यवस्थित करने के लिए प्रवर्धन का उपयोग किया जा सकता है। यानी, हमलावर इंटरनेट को स्कैन करता है और या तो असुरक्षित या गलत तरीके से कॉन्फ़िगर किए गए सर्वर ढूंढता है, उदाहरण के लिए, एक SYN पैकेट के जवाब में, तीन SYN-ACK के साथ प्रतिक्रिया करता है। लक्ष्य सर्वर के पते से स्रोत पते को धोखा देकर, एक ही पैकेट के साथ, मान लीजिए, तीन गुना तक शक्ति बढ़ाना और पीड़ित को ट्रैफ़िक पुनर्निर्देशित करना संभव है।
प्रवर्धन के साथ समस्या यह है कि उनका पता लगाना कठिन है। हाल के उदाहरणों में असुरक्षित मेमकैच्ड का सनसनीखेज मामला शामिल है। साथ ही, अब बहुत सारे IoT डिवाइस, आईपी कैमरे हैं, जो ज्यादातर डिफ़ॉल्ट रूप से कॉन्फ़िगर किए जाते हैं, और डिफ़ॉल्ट रूप से वे गलत तरीके से कॉन्फ़िगर किए जाते हैं, यही कारण है कि हमलावर अक्सर ऐसे उपकरणों के माध्यम से हमले करते हैं।
कठिन SYN-बाढ़
डेवलपर के दृष्टिकोण से SYN-बाढ़ संभवतः सबसे दिलचस्प प्रकार का हमला है। समस्या यह है कि सिस्टम प्रशासक अक्सर सुरक्षा के लिए आईपी ब्लॉकिंग का उपयोग करते हैं। इसके अलावा, आईपी ब्लॉकिंग न केवल सिस्टम प्रशासकों को प्रभावित करती है जो स्क्रिप्ट का उपयोग करके कार्य करते हैं, बल्कि, दुर्भाग्य से, कुछ सुरक्षा प्रणालियाँ भी प्रभावित करती हैं जो बहुत सारे पैसे के लिए खरीदी जाती हैं।
यह विधि एक आपदा में बदल सकती है, क्योंकि यदि हमलावर आईपी पते बदलते हैं, तो कंपनी अपने स्वयं के सबनेट को ब्लॉक कर देगी। जब फ़ायरवॉल अपने स्वयं के क्लस्टर को ब्लॉक कर देता है, तो आउटपुट बाहरी इंटरैक्शन विफल हो जाएगा और संसाधन विफल हो जाएगा।
इसके अलावा, अपने नेटवर्क को ब्लॉक करना मुश्किल नहीं है। यदि ग्राहक के कार्यालय में वाई-फाई नेटवर्क है, या यदि संसाधनों का प्रदर्शन विभिन्न निगरानी प्रणालियों का उपयोग करके मापा जाता है, तो हम इस निगरानी प्रणाली या ग्राहक के कार्यालय वाई-फाई का आईपी पता लेते हैं और इसे स्रोत के रूप में उपयोग करते हैं। अंत में, संसाधन उपलब्ध प्रतीत होता है, लेकिन लक्ष्य आईपी पते अवरुद्ध हैं। इस प्रकार, हाईलोड सम्मेलन का वाई-फाई नेटवर्क, जहां कंपनी का नया उत्पाद प्रस्तुत किया जा रहा है, अवरुद्ध हो सकता है, और इसमें कुछ व्यावसायिक और आर्थिक लागतें शामिल हैं।
परीक्षण के दौरान, हम किसी बाहरी संसाधन के साथ मेम्केच्ड के माध्यम से प्रवर्धन का उपयोग नहीं कर सकते, क्योंकि केवल अनुमत आईपी पते पर ट्रैफ़िक भेजने के समझौते हैं। तदनुसार, हम SYN और SYN-ACK के माध्यम से प्रवर्धन का उपयोग करते हैं, जब सिस्टम दो या तीन SYN-ACK के साथ एक SYN भेजने पर प्रतिक्रिया करता है, और आउटपुट पर हमला दो या तीन गुना बढ़ जाता है।
उपकरण
L7 वर्कलोड के लिए हमारे द्वारा उपयोग किए जाने वाले मुख्य उपकरणों में से एक यांडेक्स-टैंक है। विशेष रूप से, एक प्रेत का उपयोग बंदूक के रूप में किया जाता है, साथ ही कारतूस बनाने और परिणामों का विश्लेषण करने के लिए कई स्क्रिप्ट भी हैं।
Tcpdump का उपयोग नेटवर्क ट्रैफ़िक का विश्लेषण करने के लिए किया जाता है, और Nmap का उपयोग सर्वर का विश्लेषण करने के लिए किया जाता है। L3&4 स्तर पर लोड बनाने के लिए, OpenSSL और DPDK लाइब्रेरी के साथ हमारे अपने कुछ जादू का उपयोग किया जाता है। डीपीडीके इंटेल की एक लाइब्रेरी है जो आपको लिनक्स स्टैक को दरकिनार कर नेटवर्क इंटरफ़ेस के साथ काम करने की अनुमति देती है, जिससे दक्षता बढ़ती है। स्वाभाविक रूप से, हम DPDK का उपयोग न केवल L3&4 स्तर पर, बल्कि L7 स्तर पर भी करते हैं, क्योंकि यह हमें एक मशीन से प्रति सेकंड कई मिलियन अनुरोधों की सीमा के भीतर, बहुत अधिक लोड प्रवाह बनाने की अनुमति देता है।
हम कुछ ट्रैफ़िक जेनरेटर और विशेष टूल का भी उपयोग करते हैं जिन्हें हम विशिष्ट परीक्षणों के लिए लिखते हैं। यदि हम एसएसएच के तहत भेद्यता को याद करते हैं, तो उपरोक्त सेट का फायदा नहीं उठाया जा सकता है। यदि हम मेल प्रोटोकॉल पर हमला करते हैं, तो हम मेल उपयोगिताएँ लेते हैं या बस उन पर स्क्रिप्ट लिखते हैं।
निष्कर्ष
निष्कर्ष के रूप में मैं कहना चाहूंगा:
- क्लासिक लोड परीक्षण के अलावा, तनाव परीक्षण करना आवश्यक है। हमारे पास एक वास्तविक उदाहरण है जहां एक भागीदार के उपठेकेदार ने केवल लोड परीक्षण किया। इससे पता चला कि संसाधन सामान्य भार का सामना कर सकता है। लेकिन फिर एक असामान्य भार दिखाई दिया, साइट विज़िटर ने संसाधन का थोड़ा अलग तरीके से उपयोग करना शुरू कर दिया, और परिणामस्वरूप उपठेकेदार लेट गया। इस प्रकार, कमजोरियों की तलाश करना उचित है, भले ही आप पहले से ही DDoS हमलों से सुरक्षित हों।
- सिस्टम के कुछ हिस्सों को दूसरों से अलग करना आवश्यक है। यदि आपके पास कोई खोज है, तो आपको इसे अलग-अलग मशीनों में ले जाना होगा, यानी डॉकर तक भी नहीं। क्योंकि यदि खोज या प्राधिकरण विफल हो जाता है, तो कम से कम कुछ तो काम करना जारी रहेगा। ऑनलाइन स्टोर के मामले में, उपयोगकर्ता कैटलॉग में उत्पाद ढूंढना जारी रखेंगे, एग्रीगेटर से जाएंगे, यदि वे पहले से अधिकृत हैं तो खरीदेंगे, या OAuth2 के माध्यम से अधिकृत करेंगे।
- सभी प्रकार की क्लाउड सेवाओं की उपेक्षा न करें।
- सीडीएन का उपयोग न केवल नेटवर्क विलंब को अनुकूलित करने के लिए करें, बल्कि चैनल थकावट पर हमलों और स्थिर ट्रैफ़िक में बाढ़ से सुरक्षा के साधन के रूप में भी करें।
- विशेष सुरक्षा सेवाओं का उपयोग करना आवश्यक है। आप चैनल स्तर पर L3&4 हमलों से अपनी रक्षा नहीं कर सकते, क्योंकि संभवतः आपके पास पर्याप्त चैनल नहीं है। आपके L7 हमलों से लड़ने की भी संभावना नहीं है, क्योंकि वे बहुत बड़े हो सकते हैं। साथ ही, छोटे हमलों की खोज अभी भी विशेष सेवाओं, विशेष एल्गोरिदम का विशेषाधिकार है।
- नियमित रूप से अपडेट करें. यह न केवल कर्नेल पर लागू होता है, बल्कि एसएसएच डेमॉन पर भी लागू होता है, खासकर यदि आपने उन्हें बाहर की ओर खुला रखा है। सिद्धांत रूप में, हर चीज़ को अद्यतन करने की आवश्यकता है, क्योंकि आप स्वयं कुछ कमजोरियों को ट्रैक करने में सक्षम होने की संभावना नहीं रखते हैं।
स्रोत: www.habr.com