सवाल मैं डीडीओएस के तहत हूं। मैं क्या कर सकता हूँ?


यह है एक कैननिकल प्रश्न डीओएस और डीडीओएस शमन के बारे में।

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

कभी-कभी, मेरी वेबसाइट में एक और विशिष्ट लेकिन संबंधित समस्या है: मेरे सर्वर का भार औसत (जो आम तौर पर लगभग 25 है) रॉकेट 20 या उससे अधिक तक और कोई भी मेरी साइट को अन्य मामले के समान ही नहीं पहुंच सकता है। यह कुछ घंटों के बाद भी चला जाता है।

मेरे सर्वर को पुनरारंभ करने से मदद नहीं मिलती है; मेरी साइट को फिर से सुलभ बनाने के लिए मैं क्या कर सकता हूं, और क्या हो रहा है?

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


171
2017-08-19 09:14


मूल


मैंने पढ़ने के बाद इसका पालन किया (एक कैनोनिकल "सहायता बनाना, मुझे डीडीओएस-एड मिल रहा है!" सवाल?)। क्या मैं सिर्फ अच्छा काम कहना चाहता था !!! - AngryWombat
और देखें security.stackexchange.com/a/792/2379 - Pacerier


जवाब:


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

सेवा का अस्वीकार आमतौर पर कुछ श्रेणियों में पड़ता है: यातायात आधारित, और लोड-आधारित। आखिरी वस्तु (क्रैशिंग सेवा के साथ) शोषण-आधारित डीओएस है और यह काफी अलग है।

यदि आप यह जानने का प्रयास कर रहे हैं कि किस प्रकार का हमला हो रहा है, तो आप कुछ ट्रैफिक कैप्चर करना चाहते हैं (वायरशर्क, टीसीपीडम्प या libpcap का उपयोग करके)। यदि संभव हो, तो आपको यह भी पता होना चाहिए कि आप शायद बहुत सारे ट्रैफिक को कैप्चर करेंगे।

जितनी बार नहीं, ये बोनेट से आएंगे (कुछ हमलावरों के केंद्रीय नियंत्रण के तहत समझौता किए गए मेजबानों के नेटवर्क, जिनकी बोली-प्रक्रिया वे करेंगे)। यह हमलावर के लिए एक बहुत अच्छा तरीका है (बहुत सस्ता) अलग-अलग नेटवर्कों पर कई अलग-अलग मेजबानों की अपस्ट्रीम बैंडविड्थ को अपने ट्रैक को कवर करते समय, हमला करने के लिए। कम कक्षा आयन तोप एक बॉटनेट का एक उदाहरण है (मैलवेयर से व्युत्पन्न होने के बावजूद स्वैच्छिक होने के बावजूद); ज़ीउस एक और आम है।

यातायात आधारित

यदि आप यातायात आधारित डीओएस के अंतर्गत हैं, तो आप इसे ढूंढ रहे हैं बस इतना अधिक यातायात है आपके सर्वर पर आ रहा है कि इंटरनेट से इसका कनेक्शन पूरी तरह से संतृप्त है। अपने सर्वर को कहीं और पिंग करते समय एक उच्च पैकेट हानि दर है, और (उपयोग में रूटिंग विधियों के आधार पर) कभी-कभी आप वास्तव में उच्च विलंबता देख रहे हैं (पिंग उच्च है)। इस तरह का हमला आमतौर पर एक डीडीओएस होता है।

हालांकि यह वास्तव में "जोरदार" हमला है, और यह स्पष्ट है कि क्या हो रहा है, सर्वर प्रशासक के लिए कम करना मुश्किल है (और साझा होस्टिंग के उपयोगकर्ता के लिए मूल रूप से असंभव है)। आपको अपने आईएसपी से मदद की आवश्यकता होगी; उन्हें बताएं कि आप डीडीओएस के तहत हैं और वे मदद करने में सक्षम हो सकते हैं।

हालांकि, अधिकांश आईएसपी और पारगमन प्रदाता सक्रिय रूप से महसूस करेंगे कि क्या हो रहा है और प्रकाशित करें ब्लैकहोल मार्ग आपके सर्वर के लिए इसका अर्थ यह है कि वे आपके सर्वर पर जितना संभव हो उतना कम लागत के साथ एक मार्ग प्रकाशित करते हैं 0.0.0.0: वे आपके सर्वर पर यातायात को इंटरनेट पर अब रूट करने योग्य नहीं बनाते हैं। ये मार्ग आमतौर पर / 32s होते हैं और अंततः उन्हें हटा दिया जाता है। यह आपकी मदद नहीं करता है; उद्देश्य आईएसपी के नेटवर्क को जलप्रलय से बचाने के लिए है। अवधि के लिए, आपका सर्वर प्रभावी रूप से इंटरनेट का उपयोग खो देगा।

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

संक्षेप में, आप बहुत कम कर सकते हैं इस समस्या के बारे में। सबसे अच्छा दीर्घकालिक समाधान इंटरनेट पर कई अलग-अलग स्थानों में अपनी सेवाओं को होस्ट करना है, जो डीडीओएस को अधिक महंगा बनाते हुए डीडीओएस व्यक्तिगत रूप से और साथ ही साथ होना चाहिए। इसके लिए रणनीतियां उस सेवा पर निर्भर करती हैं जिसकी आपको रक्षा करने की आवश्यकता है; DNS को कई आधिकारिक नेमसर्वर, बैकअप एमएक्स रिकॉर्ड और मेल एक्सचेंजर्स के साथ एसएमटीपी, और राउंड-रॉबिन डीएनएस या मल्टीहोमिंग के साथ HTTP (लेकिन कुछ गिरावट भी अवधि के लिए ध्यान देने योग्य हो सकता है) के साथ संरक्षित किया जा सकता है।

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

यदि आप ऐसा करने में सक्षम हैं, तो ए का उपयोग करने पर विचार करें सामग्री वितरण नेटवर्क (सीडीएन) जैसे अकामाई, लीमाइट और सीडीएन 77, या क्लाउडफ्लेयर या प्रोलेक्सिक जैसे डीडीओएस स्क्रबिंग सेवा का उपयोग करें। ये सेवाएं इन प्रकार के हमलों को कम करने के लिए सक्रिय उपाय करती हैं, और इन्हें बाढ़ करने वाले कई अलग-अलग स्थानों में इतनी अधिक उपलब्ध बैंडविड्थ भी संभव नहीं है।

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

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

लोड के आधार पर

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

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

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

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

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

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

शोषण आधारित

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

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

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

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


183
2017-08-19 09:14



आपके अंतिम पैराग्राफ के बारे में, और यदि आपको शोषण-आधारित मिलता है तो क्या होगा डी DoS? आप इसे कैसे ट्रैक और रोक सकते हैं? - Pacerier


यदि आप एक उद्यम हैं, तो आपके पास कई विकल्प हैं। यदि आप मेरे जैसे छोटे लड़के हैं, एक छोटी वेबसाइट की सेवा के लिए एक वीपीएस या समर्पित सर्वर किराए पर लेना, लागत जल्दी ही निषिद्ध हो सकती है।

मेरे अनुभव से, मेरा मानना ​​है कि सबसे समर्पित और वीपीएस प्रदाता सिर्फ आपके सर्वर के लिए विशेष फ़ायरवॉल नियम स्थापित नहीं करेंगे। लेकिन आजकल, आपके पास कुछ विकल्प हैं।

CDN

यदि आप एक वेब सर्वर चला रहे हैं, तो इसे क्लाउडफ्लेयर या अमेज़ॅन क्लाउडफ्रंट जैसे सीडीएन के पीछे डालने पर विचार करें।

सीडीएन महंगा हैं। लागत को नियंत्रण में रखने के लिए, सीडीएन के बजाय सीधे अपने सर्वर से बड़ी फ़ाइलों (बड़ी छवियों, ऑडियो, वीडियो) की सेवा करें। हालांकि, यह हमलावरों को आपके सर्वर आईपी पते का पर्दाफाश कर सकता है।

निजी बादल

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

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

जब आपका टीसीपी पोर्ट पर हमला किया जाता है और अन्य सभी विफल होते हैं

यह एक समाधान है जिसे मैंने विकसित किया है जो गैर-वेब सर्वर पर लागू होता है जो सीडीएन के पीछे छिप नहीं सकते हैं, जैसे वेबसॉकेट, मीडिया सामग्री / स्ट्रीमिंग सर्वर। क्लाउडफ्लेयर वेबसॉकेट का समर्थन करता है लेकिन इस समय केवल उद्यम के लिए।

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


6
2017-12-05 18:04





एक छोटी अवधि के लिए 0.0.0.0 जैसे ब्लैक होल पर जाने के लिए अपना डोमेन बदलें।

अपने सर्वर से बात करें और देखें कि क्या वे आपको सर्वर तक पहुंचने के अस्थायी तरीके के रूप में किसी अन्य आईपी पते के साथ जारी कर सकते हैं या देख सकते हैं कि सर्वर में रिमोट कंसोल पहुंच है (जैसे आप इसके सामने बैठे हैं)। यहां से आप देख सकते हैं कि यह एक एकल आईपी पता है या इसे साइट से या वितरित हमले से अवरुद्ध करता है।


3
2018-02-26 07:44



इस तरह के DNS को बदलने से अच्छे से ज्यादा नुकसान होता है। सबसे पहले मैं एक रिकॉर्ड के टीटीएल को कम कर दूंगा, लेकिन आईपी एड्रेस को अपरिवर्तित छोड़ दूंगा - जब तक कि मेरे पास यह इंगित करने के लिए कोई नया आईपी न हो। - kasperd


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


0
2017-11-18 11:42