बचावासाठी DDoS: आम्ही तणाव आणि लोड चाचण्या कशा घेतो

Variti बॉट्स आणि DDoS हल्ल्यांपासून संरक्षण विकसित करते आणि तणाव आणि लोड चाचणी देखील करते. HighLoad++ 2018 परिषदेत आम्ही विविध प्रकारच्या हल्ल्यांपासून संसाधने कशी सुरक्षित करावी याबद्दल बोललो. थोडक्यात: सिस्टमचे भाग वेगळे करा, क्लाउड सेवा आणि CDN वापरा आणि नियमितपणे अपडेट करा. परंतु तरीही आपण विशेष कंपन्यांशिवाय संरक्षण हाताळण्यास सक्षम असणार नाही :)

मजकूर वाचण्यापूर्वी, आपण लहान गोषवारा वाचू शकता परिषदेच्या वेबसाइटवर.
आणि जर तुम्हाला वाचायला आवडत नसेल किंवा फक्त व्हिडिओ पाहायचा असेल, तर आमच्या अहवालाचे रेकॉर्डिंग खाली स्पॉयलरमध्ये आहे.

अहवालाचे व्हिडिओ रेकॉर्डिंग

बर्‍याच कंपन्यांना लोड चाचणी कशी करायची हे आधीच माहित आहे, परंतु सर्वच तणाव चाचणी करत नाहीत. आमच्या काही ग्राहकांना वाटते की त्यांची साइट अभेद्य आहे कारण त्यांच्याकडे हायलोड सिस्टम आहे आणि ती हल्ल्यांपासून चांगले संरक्षण करते. आम्ही दाखवतो की हे पूर्णपणे सत्य नाही.
अर्थात, चाचण्या घेण्यापूर्वी, आम्ही ग्राहकाकडून परवानगी घेतो, स्वाक्षरी आणि शिक्का मारतो आणि आमच्या मदतीने कोणावरही DDoS हल्ला केला जाऊ शकत नाही. ग्राहकाने निवडलेल्या वेळी चाचणी केली जाते, जेव्हा त्याच्या संसाधनावरील रहदारी कमी असते आणि प्रवेश समस्या क्लायंटवर परिणाम करणार नाहीत. याव्यतिरिक्त, चाचणी प्रक्रियेदरम्यान काहीतरी नेहमी चुकीचे होऊ शकते, आम्ही ग्राहकांशी सतत संपर्क साधतो. हे आपल्याला केवळ प्राप्त केलेल्या परिणामांचा अहवाल देण्यासच नव्हे तर चाचणी दरम्यान काहीतरी बदलण्याची देखील परवानगी देते. चाचणी पूर्ण झाल्यावर, आम्ही नेहमी एक अहवाल तयार करतो ज्यामध्ये आम्ही आढळलेल्या कमतरता दर्शवतो आणि साइटच्या कमकुवतपणा दूर करण्यासाठी शिफारसी देतो.

आम्ही कसे काम करत आहोत

चाचणी करताना, आम्ही बॉटनेटचे अनुकरण करतो. आम्ही आमच्या नेटवर्कवर नसलेल्या क्लायंटसह काम करत असल्याने, मर्यादा किंवा संरक्षण ट्रिगर झाल्यामुळे चाचणी पहिल्या मिनिटात संपत नाही याची खात्री करण्यासाठी, आम्ही लोड एका IP वरून नाही तर आमच्या स्वतःच्या सबनेटवरून पुरवतो. शिवाय, एक महत्त्वपूर्ण लोड तयार करण्यासाठी, आमच्याकडे आमचा स्वतःचा शक्तिशाली चाचणी सर्व्हर आहे.

Postulates

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

पूर्ण अपयशापेक्षा आंशिक अपयश चांगले
आम्ही नेहमी प्रणालींना विषम बनवण्याचा सल्ला देतो. शिवाय, त्यांना भौतिक स्तरावर वेगळे करणे फायदेशीर आहे, आणि केवळ कंटेनरायझेशनद्वारे नाही. भौतिक पृथक्करणाच्या बाबतीत, जरी साइटवर काहीतरी अयशस्वी झाले तरीही, ते पूर्णपणे कार्य करणे थांबवणार नाही याची उच्च संभाव्यता आहे आणि वापरकर्त्यांना कार्यक्षमतेच्या किमान भागामध्ये प्रवेश करणे सुरू राहील.

चांगली वास्तुकला हा टिकाऊपणाचा आधार आहे
संसाधनाची दोष सहिष्णुता आणि हल्ले आणि भार सहन करण्याची त्याची क्षमता डिझाइनच्या टप्प्यावर, खरं तर, नोटपॅडमध्ये प्रथम फ्लोचार्ट काढण्याच्या टप्प्यावर मांडली पाहिजे. कारण जीवघेण्या चुका रेंगाळल्या तर भविष्यात त्या दुरुस्त करणे शक्य असले तरी ते फार कठीण आहे.

केवळ कोडच नाही तर कॉन्फिगरेशन देखील चांगले असले पाहिजे
बर्याच लोकांना असे वाटते की एक चांगला विकास संघ दोष-सहिष्णु सेवेची हमी आहे. एक चांगला विकास संघ खरोखर आवश्यक आहे, परंतु तेथे चांगले ऑपरेशन्स, चांगले DevOps देखील असणे आवश्यक आहे. म्हणजेच, आम्हाला तज्ञांची आवश्यकता आहे जे लिनक्स आणि नेटवर्क योग्यरित्या कॉन्फिगर करतील, nginx मध्ये कॉन्फिग योग्यरित्या लिहतील, मर्यादा सेट करतील इ. अन्यथा, संसाधन केवळ चाचणीमध्ये चांगले कार्य करेल आणि काही क्षणी सर्वकाही उत्पादनात खंडित होईल.

लोड आणि तणाव चाचणी दरम्यान फरक
लोड चाचणी आपल्याला सिस्टम कार्याच्या मर्यादा ओळखण्याची परवानगी देते. ताण चाचणीचा उद्देश प्रणालीतील कमकुवतपणा शोधणे आहे आणि ही प्रणाली खंडित करण्यासाठी आणि काही भागांच्या अपयशाच्या प्रक्रियेत ती कशी वागेल हे पाहण्यासाठी वापरली जाते. या प्रकरणात, ताण चाचणी सुरू होण्यापूर्वी लोडचे स्वरूप सामान्यतः ग्राहकांना अज्ञात राहते.

L7 हल्ल्यांची विशिष्ट वैशिष्ट्ये

आम्ही सामान्यतः L7 आणि L3 आणि 4 स्तरांवर लोडचे प्रकार विभाजित करतो. L7 हे ऍप्लिकेशन स्तरावर एक लोड आहे, बहुतेकदा याचा अर्थ फक्त HTTP असतो, परंतु आम्हाला TCP प्रोटोकॉल स्तरावर कोणतेही लोड म्हणायचे आहे.
L7 हल्ल्यांमध्ये काही विशिष्ट वैशिष्ट्ये आहेत. प्रथम, ते थेट अनुप्रयोगावर येतात, म्हणजेच ते नेटवर्क माध्यमांद्वारे प्रतिबिंबित होण्याची शक्यता नाही. असे हल्ले तर्कशास्त्र वापरतात आणि यामुळे ते CPU, मेमरी, डिस्क, डेटाबेस आणि इतर संसाधने अतिशय कार्यक्षमतेने आणि कमी रहदारीसह वापरतात.

HTTP पूर

कोणत्याही हल्ल्याच्या बाबतीत, भार हाताळण्यापेक्षा तयार करणे सोपे आहे आणि L7 च्या बाबतीत हे देखील खरे आहे. अटॅक रहदारीला कायदेशीर रहदारीपासून वेगळे करणे नेहमीच सोपे नसते आणि बहुतेकदा हे वारंवारतेनुसार केले जाऊ शकते, परंतु सर्वकाही योग्यरित्या नियोजित केले असल्यास, हल्ला कुठे आहे आणि कायदेशीर विनंत्या कुठे आहेत हे लॉगमधून समजणे अशक्य आहे.
पहिले उदाहरण म्हणून, HTTP फ्लड हल्ल्याचा विचार करा. आलेख दर्शवितो की असे हल्ले सहसा खूप शक्तिशाली असतात; खालील उदाहरणामध्ये, विनंत्यांची शिखर संख्या 600 हजार प्रति मिनिट ओलांडली आहे.

HTTP फ्लड लोड तयार करण्याचा सर्वात सोपा मार्ग आहे. सामान्यतः, ते काही प्रकारचे लोड चाचणी साधन घेते, जसे की ApacheBench, आणि विनंती आणि लक्ष्य सेट करते. अशा सोप्या पद्धतीसह, सर्व्हर कॅशिंगमध्ये धावण्याची उच्च संभाव्यता आहे, परंतु त्यास बायपास करणे सोपे आहे. उदाहरणार्थ, विनंतीमध्ये यादृच्छिक स्ट्रिंग जोडणे, जे सर्व्हरला सतत नवीन पृष्ठ देण्यासाठी सक्ती करेल.
तसेच, लोड तयार करण्याच्या प्रक्रियेत वापरकर्ता-एजंटबद्दल विसरू नका. लोकप्रिय चाचणी साधनांचे बरेच वापरकर्ता-एजंट सिस्टम प्रशासकांद्वारे फिल्टर केले जातात आणि या प्रकरणात लोड बॅकएंडपर्यंत पोहोचू शकत नाही. विनंतीमध्ये ब्राउझरमधून कमी-अधिक वैध शीर्षलेख टाकून तुम्ही परिणामात लक्षणीय सुधारणा करू शकता.
HTTP फ्लड हल्ले जितके सोपे आहेत तितकेच त्यांचे दोष देखील आहेत. प्रथम, लोड तयार करण्यासाठी मोठ्या प्रमाणात शक्ती आवश्यक आहे. दुसरे म्हणजे, असे हल्ले शोधणे खूप सोपे आहे, विशेषतः जर ते एका पत्त्यावरून आले असतील. परिणामी, विनंत्या ताबडतोब एकतर सिस्टम प्रशासकाद्वारे किंवा प्रदाता स्तरावर फिल्टर केल्या जाऊ लागतात.

काय शोधायचे

कार्यक्षमता न गमावता प्रति सेकंद विनंत्यांची संख्या कमी करण्यासाठी, तुम्हाला थोडी कल्पनाशक्ती दाखवावी लागेल आणि साइट एक्सप्लोर करावी लागेल. अशा प्रकारे, आपण केवळ चॅनेल किंवा सर्व्हरच नाही तर अनुप्रयोगाचे वैयक्तिक भाग देखील लोड करू शकता, उदाहरणार्थ, डेटाबेस किंवा फाइल सिस्टम. तुम्ही साइटवरील ठिकाणे देखील शोधू शकता जी मोठी गणना करतात: कॅल्क्युलेटर, उत्पादन निवड पृष्ठ इ. शेवटी, असे घडते की साइटवर काही प्रकारची PHP स्क्रिप्ट असते जी अनेक लाख ओळींचे पृष्ठ तयार करते. अशी स्क्रिप्ट देखील सर्व्हरला लक्षणीयरीत्या लोड करते आणि आक्रमणासाठी लक्ष्य बनू शकते.

कोठे पहावे

जेव्हा आम्ही चाचणी करण्यापूर्वी संसाधन स्कॅन करतो, तेव्हा आम्ही प्रथम साइटवरच पाहतो. आम्ही सर्व प्रकारचे इनपुट फील्ड, जड फायली शोधत आहोत - सर्वसाधारणपणे, संसाधनासाठी समस्या निर्माण करू शकणारी प्रत्येक गोष्ट आणि त्याचे कार्य कमी करू शकते. गुगल क्रोम आणि फायरफॉक्स मधील बॅनल डेव्हलपमेंट टूल्स येथे मदत करतात, पृष्ठ प्रतिसाद वेळ दर्शवितात.
आम्ही सबडोमेन देखील स्कॅन करतो. उदाहरणार्थ, एक विशिष्ट ऑनलाइन स्टोअर आहे, abc.com, आणि त्यात एक सबडोमेन admin.abc.com आहे. बहुधा, हे अधिकृततेसह प्रशासक पॅनेल आहे, परंतु आपण त्यावर भार टाकल्यास, ते मुख्य स्त्रोतासाठी समस्या निर्माण करू शकते.
साइटवर api.abc.com सबडोमेन असू शकते. बहुधा, हे मोबाइल अनुप्रयोगांसाठी एक संसाधन आहे. अनुप्रयोग अॅप स्टोअर किंवा Google Play मध्ये आढळू शकतो, एक विशेष प्रवेश बिंदू स्थापित करा, API चे विच्छेदन करा आणि चाचणी खाती नोंदणी करा. समस्या अशी आहे की लोक सहसा असे विचार करतात की अधिकृततेद्वारे संरक्षित केलेली कोणतीही गोष्ट सेवा हल्ल्यांना नकार देण्यास प्रतिकारशक्ती आहे. समजा, अधिकृतता सर्वोत्तम कॅप्चा आहे, परंतु तसे नाही. 10-20 चाचणी खाती बनवणे सोपे आहे, परंतु ते तयार केल्याने, आम्हाला जटिल आणि अस्पष्ट कार्यक्षमतेमध्ये प्रवेश मिळतो.
स्वाभाविकच, आम्ही robots.txt आणि WebArchive, ViewDNS येथे इतिहास पाहतो आणि संसाधनाच्या जुन्या आवृत्त्या शोधतो. काहीवेळा असे घडते की विकसकांनी mail2.yandex.net ला रोल आउट केले आहे, परंतु जुनी आवृत्ती, mail.yandex.net, कायम आहे. हे mail.yandex.net यापुढे समर्थित नाही, विकास संसाधनांचे वाटप केले जात नाही, परंतु ते डेटाबेस वापरणे सुरू ठेवते. त्यानुसार, जुन्या आवृत्तीचा वापर करून, आपण बॅकएंडची संसाधने आणि लेआउटच्या मागे असलेल्या सर्व गोष्टींचा प्रभावीपणे वापर करू शकता. अर्थात, हे नेहमीच घडत नाही, परंतु तरीही आपल्याला अनेकदा याचा सामना करावा लागतो.
स्वाभाविकच, आम्ही सर्व विनंती पॅरामीटर्स आणि कुकीच्या संरचनेचे विश्लेषण करतो. तुम्ही, म्हणा, कुकीच्या आत JSON अॅरेमध्ये काही मूल्य टाकू शकता, भरपूर घरटे तयार करू शकता आणि संसाधनास अवास्तव दीर्घकाळ काम करू शकता.

शोध लोड

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

शोध नाही तर?

कोणताही शोध नसल्यास, याचा अर्थ असा नाही की साइटमध्ये इतर असुरक्षित इनपुट फील्ड नाहीत. हे फील्ड अधिकृतता असू शकते. आजकाल, डेव्हलपरला इंद्रधनुष्य टेबल हल्ल्यापासून लॉगिन डेटाबेसचे संरक्षण करण्यासाठी जटिल हॅश बनवणे आवडते. हे चांगले आहे, परंतु अशा हॅश खूप CPU संसाधने वापरतात. खोट्या अधिकृततेच्या मोठ्या प्रवाहामुळे प्रोसेसर अयशस्वी होतो आणि परिणामी, साइट कार्य करणे थांबवते.
टिप्पण्या आणि फीडबॅकसाठी सर्व प्रकारच्या फॉर्मची साइटवर उपस्थिती हे तेथे खूप मोठे मजकूर पाठवण्याचे किंवा फक्त एक प्रचंड पूर निर्माण करण्याचे कारण आहे. कधीकधी साइट gzip फॉरमॅटसह संलग्न फाइल स्वीकारतात. या प्रकरणात, आम्ही 1TB फाइल घेतो, ती gzip वापरून अनेक बाइट्स किंवा किलोबाइट्सवर संकुचित करतो आणि साइटवर पाठवतो. मग ते अनझिप केले जाते आणि एक अतिशय मनोरंजक प्रभाव प्राप्त होतो.

रेस्ट API

मला बाकी API सारख्या लोकप्रिय सेवांकडे थोडे लक्ष द्यायचे आहे. रेस्ट एपीआय सुरक्षित करणे नियमित वेबसाइटपेक्षा खूप कठीण आहे. पासवर्ड ब्रूट फोर्स आणि इतर बेकायदेशीर क्रियाकलापांपासून संरक्षणाच्या क्षुल्लक पद्धती देखील बाकी API साठी कार्य करत नाहीत.
बाकी API तोडणे खूप सोपे आहे कारण ते थेट डेटाबेसमध्ये प्रवेश करते. त्याच वेळी, अशा सेवेच्या अपयशामुळे व्यवसायासाठी गंभीर परिणाम होतात. वस्तुस्थिती अशी आहे की बाकी API सामान्यतः केवळ मुख्य वेबसाइटसाठीच नाही तर मोबाइल अनुप्रयोग आणि काही अंतर्गत व्यवसाय संसाधनांसाठी देखील वापरली जाते. आणि जर हे सर्व कमी झाले, तर परिणाम साध्या वेबसाइटच्या अपयशाच्या तुलनेत खूपच मजबूत आहे.

भारी सामग्री लोड करत आहे

जर आम्हाला काही सामान्य सिंगल-पेज अॅप्लिकेशन, लँडिंग पेज किंवा बिझनेस कार्ड वेबसाइटची चाचणी घेण्याची ऑफर दिली गेली ज्यामध्ये जटिल कार्यक्षमता नाही, तर आम्ही भारी सामग्री शोधतो. उदाहरणार्थ, सर्व्हर पाठवलेल्या मोठ्या प्रतिमा, बायनरी फाइल्स, पीडीएफ दस्तऐवजीकरण - आम्ही हे सर्व डाउनलोड करण्याचा प्रयत्न करतो. अशा चाचण्या फाईल सिस्टीम चांगल्या प्रकारे लोड करतात आणि चॅनेल बंद करतात आणि म्हणूनच प्रभावी आहेत. म्हणजेच, जरी आपण सर्व्हर खाली ठेवला नाही, कमी वेगाने एक मोठी फाईल डाउनलोड करून, आपण फक्त लक्ष्य सर्व्हरचे चॅनेल बंद कराल आणि नंतर सेवा नाकारली जाईल.
अशा चाचणीचे उदाहरण दर्शविते की 30 RPS च्या वेगाने साइटने प्रतिसाद देणे थांबवले किंवा 500 व्या सर्व्हर त्रुटी निर्माण केल्या.

सर्व्हर सेट करण्याबद्दल विसरू नका. तुम्हाला अनेकदा आढळू शकते की एखाद्या व्यक्तीने व्हर्च्युअल मशीन विकत घेतली आहे, तेथे Apache स्थापित केले आहे, सर्व काही डीफॉल्टनुसार कॉन्फिगर केले आहे, PHP अनुप्रयोग स्थापित केला आहे आणि खाली आपण परिणाम पाहू शकता.

येथे लोड रूटवर गेला आणि फक्त 10 आरपीएस इतका होता. आम्ही 5 मिनिटे थांबलो आणि सर्व्हर क्रॅश झाला. हे खरे आहे की तो का पडला हे पूर्णपणे माहित नाही, परंतु एक गृहितक आहे की त्याला फक्त खूप स्मरणशक्ती होती आणि म्हणून त्याने प्रतिसाद देणे थांबवले.

लहर आधारित

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

म्हणजेच, संरक्षण शिकले, फिल्टर करणे सुरू केले, परंतु हल्ल्याचा एक नवीन, पूर्णपणे वेगळा भाग आला आणि संरक्षण पुन्हा शिकू लागले. खरं तर, फिल्टरिंग काम करणे थांबवते, संरक्षण अप्रभावी होते आणि साइट अनुपलब्ध होते.
लाटांचे हल्ले शिखरावर अत्यंत उच्च मूल्यांद्वारे वैशिष्ट्यीकृत आहेत, ते L7 च्या बाबतीत प्रति सेकंद एक लाख किंवा दशलक्ष विनंत्यांपर्यंत पोहोचू शकतात. जर आपण L3 आणि 4 बद्दल बोललो, तर शेकडो गीगाबिट्स ट्रॅफिक असू शकतात, किंवा त्यानुसार, शेकडो mpps, जर तुम्ही पॅकेटमध्ये मोजले तर.
अशा हल्ल्यांची समस्या सिंक्रोनाइझेशन आहे. हल्ले बॉटनेट वरून येतात आणि खूप मोठे एक-वेळ स्पाइक तयार करण्यासाठी उच्च प्रमाणात सिंक्रोनाइझेशन आवश्यक असते. आणि हे समन्वय नेहमीच कार्य करत नाही: कधीकधी आउटपुट काही प्रकारचे पॅराबॉलिक पीक असते, जे ऐवजी दयनीय दिसते.

एकट्या HTTP नाही

L7 वर HTTP व्यतिरिक्त, आम्हाला इतर प्रोटोकॉलचे शोषण करायला आवडते. नियमानुसार, नियमित वेबसाइट, विशेषत: नियमित होस्टिंगमध्ये मेल प्रोटोकॉल आणि MySQL चिकटलेले असतात. मेल प्रोटोकॉल डेटाबेसपेक्षा कमी लोडच्या अधीन असतात, परंतु ते बर्‍याच कार्यक्षमतेने लोड केले जाऊ शकतात आणि सर्व्हरवर ओव्हरलोड केलेल्या CPU सह समाप्त होतात.
आम्हाला 2016 च्या SSH भेद्यतेसह वास्तविकपणे यश मिळाले. आता ही भेद्यता जवळजवळ प्रत्येकासाठी निश्चित केली गेली आहे, परंतु याचा अर्थ असा नाही की लोड SSH वर सबमिट केला जाऊ शकत नाही. करू शकतो. अधिकृततेचा एक मोठा भार आहे, SSH सर्व्हरवरील जवळजवळ संपूर्ण CPU खातो आणि नंतर वेबसाइट प्रति सेकंद एक किंवा दोन विनंत्यांमुळे कोलमडते. त्यानुसार, लॉगवर आधारित या एक किंवा दोन विनंत्या कायदेशीर लोडपासून वेगळे केल्या जाऊ शकत नाहीत.
आम्ही सर्व्हरमध्ये उघडलेले अनेक कनेक्शन देखील संबंधित राहतात. पूर्वी, अपाचे यासाठी दोषी होते, आता nginx प्रत्यक्षात यासाठी दोषी आहे, कारण ते अनेकदा डीफॉल्टनुसार कॉन्फिगर केलेले असते. nginx उघडे ठेवू शकणार्‍या कनेक्शनची संख्या मर्यादित आहे, म्हणून आम्ही कनेक्शनची ही संख्या उघडतो, nginx यापुढे नवीन कनेक्शन स्वीकारत नाही आणि परिणामी साइट कार्य करत नाही.
आमच्या चाचणी क्लस्टरमध्ये SSL हँडशेकवर हल्ला करण्यासाठी पुरेसा CPU आहे. तत्वतः, सराव दर्शविल्याप्रमाणे, botnets कधीकधी हे देखील करायला आवडतात. एकीकडे, हे स्पष्ट आहे की आपण SSL शिवाय करू शकत नाही, कारण Google परिणाम, रँकिंग, सुरक्षा. दुसरीकडे, SSL मध्ये दुर्दैवाने CPU समस्या आहे.

L3 आणि 4

जेव्हा आपण L3 आणि 4 स्तरावरील हल्ल्याबद्दल बोलतो, तेव्हा आपण सहसा लिंक स्तरावरील हल्ल्याबद्दल बोलत असतो. SYN-पूरचा हल्ला असल्याशिवाय असा भार जवळजवळ नेहमीच कायदेशीर भारापासून वेगळा केला जातो. सुरक्षा साधनांसाठी SYN-पूर हल्ल्यांची समस्या ही त्यांची मोठी मात्रा आहे. कमाल L3 आणि 4 मूल्य 1,5-2 Tbit/s होते. Oracle आणि Google सह मोठ्या कंपन्यांसाठी देखील अशा प्रकारच्या रहदारीवर प्रक्रिया करणे खूप कठीण आहे.
SYN आणि SYN-ACK हे पॅकेट आहेत जे कनेक्शन स्थापित करताना वापरले जातात. म्हणून, SYN-पूर हे कायदेशीर भारापासून वेगळे करणे कठीण आहे: हे कनेक्शन स्थापित करण्यासाठी आलेले SYN आहे की पुराचा भाग आहे हे स्पष्ट नाही.

UDP-पूर

सामान्यतः, आक्रमणकर्त्यांकडे आमच्याकडे असलेल्या क्षमता नसतात, म्हणून प्रवर्धनाचा वापर हल्ले आयोजित करण्यासाठी केला जाऊ शकतो. म्हणजेच, हल्लेखोर इंटरनेट स्कॅन करतो आणि त्याला एकतर असुरक्षित किंवा चुकीचे कॉन्फिगर केलेले सर्व्हर सापडतात जे, उदाहरणार्थ, एका SYN पॅकेटला प्रतिसाद म्हणून, तीन SYN-ACK सह प्रतिसाद देतात. लक्ष्य सर्व्हरच्या पत्त्यावरून स्त्रोत पत्ता स्पूफिंग करून, एका पॅकेटसह तीन वेळा पॉवर वाढवणे आणि पीडिताकडे रहदारी पुनर्निर्देशित करणे शक्य आहे.

प्रवर्धनाची समस्या अशी आहे की ते शोधणे कठीण आहे. अलीकडील उदाहरणांमध्ये असुरक्षित मेमकॅशेडचे खळबळजनक प्रकरण समाविष्ट आहे. शिवाय, आता बरीच IoT उपकरणे, IP कॅमेरे आहेत, जे बहुतेक डीफॉल्टनुसार कॉन्फिगर केलेले असतात आणि डीफॉल्टनुसार ते चुकीच्या पद्धतीने कॉन्फिगर केलेले असतात, म्हणूनच हल्लेखोर बहुतेकदा अशा उपकरणांद्वारे हल्ले करतात.

कठीण SYN-पूर

विकासकाच्या दृष्टिकोनातून SYN-पूर हा कदाचित सर्वात मनोरंजक प्रकारचा हल्ला आहे. समस्या अशी आहे की सिस्टम प्रशासक अनेकदा संरक्षणासाठी आयपी ब्लॉकिंग वापरतात. शिवाय, आयपी ब्लॉकिंग स्क्रिप्ट वापरून कार्य करणार्‍या सिस्टम प्रशासकांवरच परिणाम करत नाही, तर दुर्दैवाने, काही सुरक्षा प्रणालींवर देखील परिणाम करते ज्या मोठ्या पैशासाठी खरेदी केल्या जातात.
ही पद्धत आपत्तीमध्ये बदलू शकते, कारण आक्रमणकर्त्यांनी IP पत्ते बदलल्यास, कंपनी स्वतःचे सबनेट अवरोधित करेल. जेव्हा फायरवॉल स्वतःचे क्लस्टर अवरोधित करते, तेव्हा आउटपुट बाह्य परस्परसंवाद अयशस्वी होईल आणि संसाधन अयशस्वी होईल.
शिवाय, आपले स्वतःचे नेटवर्क अवरोधित करणे कठीण नाही. जर क्लायंटच्या ऑफिसमध्ये वाय-फाय नेटवर्क असेल किंवा विविध मॉनिटरिंग सिस्टम वापरून संसाधनांची कार्यक्षमता मोजली गेली असेल, तर आम्ही या मॉनिटरिंग सिस्टमचा किंवा क्लायंटच्या ऑफिस वाय-फायचा IP पत्ता घेतो आणि त्याचा स्रोत म्हणून वापर करतो. शेवटी, संसाधन उपलब्ध असल्याचे दिसते, परंतु लक्ष्यित IP पत्ते अवरोधित केले आहेत. अशा प्रकारे, हायलोड कॉन्फरन्सचे वाय-फाय नेटवर्क, जिथे कंपनीचे नवीन उत्पादन सादर केले जात आहे, ते अवरोधित केले जाऊ शकते आणि यासाठी काही विशिष्ट व्यवसाय आणि आर्थिक खर्च समाविष्ट आहेत.
चाचणी दरम्यान, आम्ही कोणत्याही बाह्य संसाधनांसह मेमकॅशेडद्वारे प्रवर्धन वापरू शकत नाही, कारण केवळ परवानगी असलेल्या IP पत्त्यांवर रहदारी पाठविण्याचे करार आहेत. त्यानुसार, आम्ही SYN आणि SYN-ACK द्वारे प्रवर्धन वापरतो, जेव्हा सिस्टम दोन किंवा तीन SYN-ACK सह एक SYN पाठविण्यास प्रतिसाद देते आणि आउटपुटवर हल्ला दोन किंवा तीन वेळा गुणाकार केला जातो.

साधने

L7 वर्कलोडसाठी आम्ही वापरत असलेल्या मुख्य साधनांपैकी एक म्हणजे Yandex-tank. विशेषतः, फॅंटमचा वापर तोफा म्हणून केला जातो, तसेच काडतुसे तयार करण्यासाठी आणि परिणामांचे विश्लेषण करण्यासाठी अनेक स्क्रिप्ट्स आहेत.
Tcpdump चा वापर नेटवर्क रहदारीचे विश्लेषण करण्यासाठी केला जातो आणि Nmap चा वापर सर्व्हरचे विश्लेषण करण्यासाठी केला जातो. L3 आणि 4 स्तरावर लोड तयार करण्यासाठी, OpenSSL आणि DPDK लायब्ररीसह आपली स्वतःची थोडी जादू वापरली जाते. DPDK ही इंटेलची एक लायब्ररी आहे जी तुम्हाला Linux स्टॅकला बायपास करून नेटवर्क इंटरफेससह कार्य करण्यास अनुमती देते, ज्यामुळे कार्यक्षमता वाढते. साहजिकच, आम्ही DPDK केवळ L3 आणि 4 स्तरावरच नाही तर L7 स्तरावर देखील वापरतो, कारण ते आम्हाला एका मशीनकडून प्रति सेकंद अनेक दशलक्ष विनंत्यांच्या मर्यादेत खूप उच्च भार प्रवाह तयार करण्यास अनुमती देते.
आम्ही काही ट्रॅफिक जनरेटर आणि विशेष साधने देखील वापरतो जी आम्ही विशिष्ट चाचण्यांसाठी लिहितो. जर आपल्याला SSH अंतर्गत भेद्यता आठवत असेल, तर वरील संचाचा गैरफायदा घेतला जाऊ शकत नाही. आम्ही मेल प्रोटोकॉलवर हल्ला केल्यास, आम्ही मेल युटिलिटी घेतो किंवा त्यावर स्क्रिप्ट लिहितो.

निष्कर्ष

निष्कर्ष म्हणून मी असे म्हणू इच्छितो:

• क्लासिक लोड चाचणी व्यतिरिक्त, तणाव चाचणी आयोजित करणे आवश्यक आहे. आमच्याकडे एक वास्तविक उदाहरण आहे जिथे भागीदाराच्या उपकंत्राटदाराने फक्त लोड चाचणी केली. हे दर्शविते की संसाधन सामान्य भार सहन करू शकते. परंतु नंतर एक असामान्य भार दिसू लागला, साइट अभ्यागतांनी स्त्रोत थोड्या वेगळ्या पद्धतीने वापरण्यास सुरुवात केली आणि परिणामी उपकंत्राटदार खाली पडला. अशा प्रकारे, आपण आधीच DDoS हल्ल्यांपासून संरक्षित असले तरीही असुरक्षा शोधणे योग्य आहे.
• सिस्टमचे काही भाग इतरांपासून वेगळे करणे आवश्यक आहे. तुमच्याकडे शोध असल्यास, तुम्हाला ते वेगळ्या मशीनवर हलवावे लागेल, म्हणजेच डॉकरकडेही नाही. कारण शोध किंवा अधिकृतता अयशस्वी झाल्यास, किमान काहीतरी कार्य करत राहील. ऑनलाइन स्टोअरच्या बाबतीत, वापरकर्ते कॅटलॉगमध्ये उत्पादने शोधणे सुरू ठेवतील, एग्रीगेटरकडून जातील, ते आधीच अधिकृत असल्यास ते खरेदी करतील किंवा OAuth2 द्वारे अधिकृत करतील.
• सर्व प्रकारच्या क्लाउड सेवांकडे दुर्लक्ष करू नका.
• CDN चा वापर केवळ नेटवर्क विलंब ऑप्टिमाइझ करण्यासाठीच नाही तर चॅनेलच्या थकवा आणि स्थिर रहदारीवर होणार्‍या हल्ल्यांपासून संरक्षणाचे साधन म्हणून देखील करा.
• विशेष संरक्षण सेवा वापरणे आवश्यक आहे. तुम्ही चॅनल स्तरावर L3 आणि 4 हल्ल्यांपासून स्वतःचे संरक्षण करू शकत नाही, कारण बहुधा तुमच्याकडे पुरेसे चॅनल नाही. तुम्ही L7 हल्ल्यांचा सामना करू शकत नाही, कारण ते खूप मोठे असू शकतात. शिवाय, लहान हल्ल्यांचा शोध अजूनही विशेष सेवा, विशेष अल्गोरिदमचा विशेषाधिकार आहे.
• नियमितपणे अपडेट करा. हे फक्त कर्नललाच लागू होत नाही, तर SSH डिमनलाही लागू होते, खासकरून जर तुम्ही ते बाहेरून उघडले असेल. तत्वतः, सर्वकाही अद्ययावत करणे आवश्यक आहे, कारण आपण स्वतःहून काही असुरक्षा ट्रॅक करण्यास सक्षम असण्याची शक्यता नाही.

स्त्रोत: www.habr.com