सेवा हमलों से इनकार: परीक्षण आचरण

पद - रिज्यूमे

मुझे लगता है कि यह इस तथ्य से शुरू होने लायक है कि हाल के वर्षों में अधिक से अधिक ग्राहक न केवल पैठ परीक्षण के लिए बदल गए हैं, बल्कि सेवा हमलों से इनकार करने के लिए अपनी सेवाओं के प्रतिरोध का परीक्षण करने के लिए, सबसे अधिक बार वेबसाइटों। और हमारे व्यवहार में, अभी तक एक भी ऐसा मामला नहीं आया है जहाँ एक वास्तविक कार्य स्थल (पहले से तैयार साइट नहीं) विफल नहीं हुआ, जिसमें शामिल हैं विभिन्न सुरक्षात्मक प्रणालियों के तहत स्थित है। और यह पोस्ट पूरी तरह से अलग-अलग इन्फ्रास्ट्रक्चर के विभिन्न तरीकों (बैंकों से लेकर विशिष्ट कॉरपोरेट कंपनियों) द्वारा वर्तमान (डी) DoS परीक्षण अनुभव का सारांश है।


DDoS अटैक विज़ुअलाइज़ेशन

तो चलिए फिर चलते हैं। कार्य किसी भी उपलब्ध तरीकों से संसाधन को अक्षम करना है, चाहे हम घुसपैठिए हों। 99% में, स्रोत डोमेन आईपी / आईपी है।

काम कैसा चल रहा है?

सबसे पहले, एक परीक्षण तकनीक का चयन किया जाता है और ग्राहक के साथ सहमति व्यक्त की जाती है। चयन में निम्न शामिल हैं:

• चैनल पर हमलों (अधिकतम थ्रूपुट तक पहुंच);
• नेटवर्क सेवाओं पर हमले (धीमी http, कुछ वेब सर्वरों के DDoS के लिए उपयोग का उपयोग, SSL पर हमले, अन्य तकनीकें);
• और सबसे शांत और सबसे दिलचस्प बात है आवेदन स्तर पर एक हमला (इस एप्लिकेशन की विशेषताओं का उपयोग करके)।

समय, शक्ति समन्वित हैं, स्काइप चैट सही समय पर चल रही है और सभी क्रियाएं पहले से ही समन्वित हैं।

और अब प्रत्येक तकनीकों के बारे में।

चैनल पर हमला

या माथे पर हमला। कार्य सर्वर चैनल को रोकना और वैध ग्राहकों के लिए दुर्गम बनाना है। वास्तव में, हमलावर विभिन्न तकनीकों का उपयोग करते हैं - वास्तविक बोटनेट से लेकर सार्वजनिक डीएनएस / एनटीपी सर्वर के माध्यम से हमलों तक। हम क्या कर रहे हैं? Habré पर एक लेख था - Node.js. पर एक साथ लाखों कनेक्शन महान विचार - अमेज़न बादल का उपयोग करें! हम छवि में ट्रैफ़िक उत्पन्न करने के लिए अपने कुछ टूल जोड़ते हैं / लॉन्च के बाद इसे नोड्स पर डालते हैं और बोर्ड पर 100 एमबीपीएस कार्ड के साथ अपना मिनी-बॉट प्राप्त करते हैं! नतीजतन, हम नोड्स की संख्या से हमले को नियंत्रित कर सकते हैं और दुनिया के विभिन्न क्षेत्रों (क्योंकि अमेज़न विभिन्न देशों में सर्वर प्रदान करता है) से लक्ष्य को हिट कर सकता है, कई गीगाबिट्स के हमले तक पहुंच सकता है (सबसे वास्तविक हमले <1 GB / s की गति पर हैं, जो विभिन्न आँकड़ों द्वारा देखते हैं)। व्यवहार में, फिर होस्टर में पूरा रैक गिर जाएगा, फिर कुछ और। होस्टर के साथ काम करने की जिम्मेदारी ग्राहक द्वारा ग्रहण की जाती है (यह चेतावनी देने के लिए कि परीक्षण आदि होगा)। इस तरह के हमलों के खिलाफ अनुभव परीक्षण सर्वर और विभिन्न सुरक्षा के तहत था, उदाहरण के लिए, CloudFlare जैसी सेवाएं।


CloudFlare के काम की योजना और DDoS के खिलाफ सुरक्षा के लिए कई अन्य सेवाएं

और व्यवहार में - वे वास्तव में सुरक्षा प्रदान करते हैं। साइट दोनों काम करती है और काम करती है। लेकिन सुरक्षा के तहत सर्वर बहुत दुर्लभ हैं। लेकिन फिर भी, यह याद रखने योग्य है कि dns / ntp सर्वर का उपयोग करते समय क्या हुआ। ऐसी क्षमताओं से, यह न केवल कि DDoS सुरक्षा सेवा खराब महसूस करेगी, बल्कि कभी-कभी ट्रैफ़िक एक्सचेंज खुद को इंगित करता है।

नेटवर्क सेवाओं पर हमले

लब्बोलुआब यह है कि किसी भी तरह से पूरी तरह से नेटवर्क सेवा (वेब ​​सर्वर, प्रॉक्सी, बैलेंसर, कुछ और जो दिखता है) डालनी है। बेशक, पहली बात जो दिमाग में आती है वह है धीमी http! जिसके बारे में एक से अधिक बार यह एक हाब पर लिखा गया था । मैं धीमे POST के उदाहरण का उपयोग करते हुए कुछ वाक्यों के सार को समझाने की कोशिश करूंगा: हम एक HTTP अनुरोध भेजते हैं, जो एक बड़ी सामग्री-लंबाई का संकेत देता है और धीरे-धीरे केवल एक बाइट प्रसारित करता है, एक बिंदु पर हमारे कनेक्शन को तोड़कर एक नया शुरू करता है। मानक के अनुसार, सर्वर को पूरी तरह से भेजे जाने वाले डेटा के लिए प्रतीक्षा करनी चाहिए (सामग्री-लंबाई बाइट्स में सामग्री प्राप्त करने के बाद), केवल टाइमआउट द्वारा बाधित। वह सब है! सर्वर कनेक्शन का एक क्लाउड खोलता है, संसाधनों का उपभोग करता है (सबसे अधिक बार - सिस्टम में खुली फ़ाइल डिस्क्रिप्टर की संख्या) और नीचे देता है। वही अपाचे एक दो सेकंड में दुर्घटनाग्रस्त हो जाता है। घर पर, आप OWASP से उपकरण डाउनलोड कर सकते हैं।


OWASP HTTP पोस्ट टूल

इसी तरह की योजना के अनुसार, एसएसएल सर्वर के मामले में, "धीमी एसएसएलटी" पर हमला करने का प्रयास किया जाता है (हमें एक एसएसएल प्रमाणपत्र धीरे-धीरे मिलता है)। इसके अलावा, बंदरगाह पर बाढ़, यदि संभव हो - वेब सर्वर के लिए एक शोषण ही। और आप यह सब नोड्स के साथ कर सकते हैं, सर्वर बस ऐसे कई कनेक्शनों (यहां तक ​​कि वैध वाले) की सेवा नहीं दे सकता है।
वैसे, अभ्यास से। एक बार जब हम इस तथ्य पर आ गए कि Microsoft फ़ोरफ़्रंट परीक्षण ऑब्जेक्ट पर स्थापित किया गया था और हमने धीमी HTTP की कोशिश की। और उसने सफलतापूर्वक इसे दोहराया - यह लॉग में था।

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

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

आवेदन स्तर पर हमला

लब्बोलुआब यह है कि इस एप्लिकेशन की विशेषताओं को ढूंढना है और उनके माध्यम से सर्वर डालना है। कोई सुरक्षा, बैलेन्सर, बाहरी सेवाएँ इससे नहीं बचती हैं। मेरा क्या मतलब है? विभिन्न "भारी" प्रश्न, जैसे कि बड़ी मात्रा में डेटा प्राप्त करना। दर्जनों कारों में से एक पूरी तरह से वैध अनुरोध पर, वे पहुंचे। स्वाभाविक रूप से, ऐसे स्थानों को ढूंढना आसान होता है यदि DoS परीक्षण पेंटेस्ट का हिस्सा है और आवेदन का अध्ययन करने का समय है। वास्तविक उदाहरण के रूप में:

• जिप बम ( ४.५ पेटाबाइट्स पर ४२ kb संग्रह )
• XML बम - en.wikipedia.org/wiki/Billion_laughs (यदि XXE है, लेकिन आप बाहरी संस्थाओं को नहीं जोड़ सकते हैं, केवल आंतरिक अग्रेषण)
• जैसा कि कहा गया है - बस स्पष्ट रूप से एक बड़ा डेटा नमूना
• विभिन्न डेटा का नमूना लेते समय पैरामीटर छेड़छाड़ (उदाहरण के लिए, यह कहा जाता है कि आप 100 उत्पादों का चयन कर सकते हैं, और हम मैन्युअल रूप से HTTP अनुरोध को बदलते हैं और 999999+ उत्पादों का चयन करते हैं)
• कार्यक्षमता खोजें
• Django और पासवर्ड बदलने जैसे अन्य विशिष्ट मामले

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

निष्कर्ष

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