DEFCON सम्मेलन 19. DoS हमलों की तीन पीढ़ियों (पीड़ितों के रूप में दर्शकों को शामिल करना)। भाग २

DEFCON सम्मेलन 19. DoS हमलों की तीन पीढ़ियों (पीड़ितों के रूप में दर्शकों को शामिल करना)। भाग 1

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



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

छात्रों को दिलचस्पी नहीं होगी, क्योंकि वे कुछ भी नहीं सीखेंगे यदि वे हमले के कारण होने वाले नुकसान को नहीं देख सकते हैं। मैंने सोचा कि "ठीक है, यह एक बुरा प्रोजेक्ट है, मुझे क्या करना चाहिए?", लेकिन फिर यह मुझ पर हावी हो गया - यह बात एक डोमेन नियंत्रक, एक मेल सर्वर और सभी को मारती है, यह बहुत बुरा है। यह इतना बुरा है कि मैं अपने छात्रों को इसके बारे में बिल्कुल नहीं बता सकता, बेहतर होगा कि मैं इसके बारे में Microsoft को चुपचाप बताऊं!

इसलिए मैंने एक ट्वीट भेजा कि विंडोज 7 में एक खतरनाक भेद्यता है, जो, हालांकि, बिल्कुल आश्चर्य की बात नहीं है। मैंने कहा कि इसके संबंध में मुझे विंडोज सुरक्षा सेवा से संपर्क की आवश्यकता है, और ट्विटर पर लोगों ने मुझे Microsoft में सही लोगों को खोजने में मदद की। 2 दिनों के बाद, मुझे Microsoft से आधिकारिक प्रतिक्रिया मिली, जिसमें यह बताया गया कि मार्क ह्यूजेस ने उन्हें एक साल पहले इस बारे में बताया था। लेकिन इससे कोई फर्क नहीं पड़ता, क्योंकि वे विंडोज के वर्तमान संस्करणों में सुधार करने का इरादा नहीं रखते हैं, क्योंकि विस्टा, विंडोज 7, विंडोज सर्वर 2003, विंडोज सर्वर 2008, विंडोज एक्सपी धीरे-धीरे मर रहे हैं और वे उनका समर्थन करना बंद कर देते हैं। इसके बजाय, वे इस भेद्यता को विंडोज 8 या विंडोज 9 में ठीक कर देंगे यदि वे अभी भी किसी चीज के साथ नहीं आते हैं।

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

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

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



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

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

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

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

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



इसलिए, मैं आपको एक कहानी बताऊंगा कि कैसे उन्होंने मुझे इस में घसीटा, डीडीओएस के कुछ हमलों के बारे में जो हमने 23 दिनों तक देखे और हमने उन्हें रोकने के लिए क्या किया।
2 जून, 2011 को लगभग 4:54 बजे GMT, LulzSec ने अपने ट्विटर अकाउंट पर घोषणा की कि उन्होंने lulzsecurity.com पर Lulz Security पेज बनाया है । हैरानी की बात यह थी कि एक शक्तिशाली DDoS हमले के कारण यह पृष्ठ 15 मिनट के लिए ऑफ़लाइन था। मुझे इस विशेष हमले का विवरण नहीं पता है, क्योंकि तब हम अभी तक इसमें शामिल नहीं थे।

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



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



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

इसलिए, अगले 23 दिनों में, इन लोगों ने तरह-तरह से कहर बरपाया। अंत में, 25 जून को, उन्होंने एक ट्वीट पोस्ट किया जिसमें हमले के अंत को चिह्नित किया गया था।



यह दिलचस्प था कि CloudFlare एक रिवर्स प्रॉक्सी के रूप में काम करता है, इसलिए Lulz Security में जाने वाले सभी ट्रैफ़िक सबसे पहले हमारे नेटवर्क से गुजरे, जिसके दो महत्वपूर्ण प्रभाव हैं। पहला - लुल्ज़ सिक्योरिटी पर हमला करने वाले किसी ने भी हम पर हमला किया, दूसरा - हमारे लिए धन्यवाद, लुलज़ सिक्योरिटी अपने हमले के स्रोत के स्थान को छिपा सकती थी, यानी वह स्थान जहाँ उनकी मेजबानी वास्तव में स्थित थी। ये हमारे सिस्टम की वास्तुकला के दुष्प्रभाव हैं, लेकिन हैकर्स ने उन्हें अपने लाभ के लिए उपयोग किया है।

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



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



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

इन 23 दिनों में क्या हुआ, इसके बारे में आपको थोड़ा और बता दूं और इस दौरान लुलज़ सुरक्षा वेबसाइट पर वास्तविक ट्रैफ़िक का विश्लेषण दिखाऊंगा।



इस समय के दौरान, इस साइट पर जाने पर 18 मिलियन से अधिक पृष्ठ दृश्य बनाए गए। आप देख सकते हैं कि लगभग 22 जून से 5 जुलाई तक हमले की शुरुआत में लगभग सामान्य यातायात का एक शिखर देखा गया था, और फिर साइट ने काम करना बंद कर दिया, हालांकि यह अभी भी CloudFlare का उपयोग करता है। यदि आप आज इस साइट पर जाने का प्रयास करते हैं, तो आपको वहाँ केवल Apache कॉन्फ़िगरेशन पृष्ठ दिखाई देगा, और मुझे नहीं पता कि वे आगे क्या करने की योजना बना रहे हैं।
साइट को नीचे लाने वाले हमले के यातायात को देखना दिलचस्प है।



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

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

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



ऐसा लगता है कि जस्टर ने लल्ज़सेक वेबसाइट के स्थान का पता लगाने और अपने पेज पर अपने संसाधनों के आईपी पते: www.lulzsecurity.com : 204.197.240.133 और lzzsecurity.com: 111.90.139.55 पर बहुत समय बिताया।

मुझे पता है कि 25 जून को लुलज़ेक वेबसाइट की मेजबानी क्या थी और मैं आपको बता सकता हूं कि इन पते का इससे कोई लेना-देना नहीं है। इन 23 दिनों के दौरान, उन्होंने 7 अलग-अलग मेजबानों का इस्तेमाल किया, शुरू में मेजबान मॉन्ट्रियल, कनाडा में स्थित था। कुछ समय के लिए, जून की शुरुआत में, 111.90.139.55 के आईपी पते के साथ मलेशियाई होस्टिंग का उपयोग किया गया था। अधिकांश होस्ट जो वे उपयोग करते हैं, वे संयुक्त राज्य में स्थित थे, जिसमें एक बड़ा मेजबान भी शामिल है, जो DoS हमलों के प्रभावों को कम करने में विशेषज्ञता रखता है, और अंत में वे जर्मन होस्टिंग पर स्विच कर गए, जहां आज साइट स्थित है।

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



मुझे लगता है कि जब लोगों ने दावा किया कि उन्होंने लल्ज़सेक साइट को नीचे लाया है, तो वास्तव में ऐसा क्या हुआ कि लुलज़ेक के लोग बस अपने मेजबानों से बाहर निकल गए। इसलिए, 36 घंटे की छोटी अवधि के लिए, उन्होंने वास्तव में अपने पते के रूप में अमान्य आईपी पते 2.2.2.2 का संकेत दिया, क्योंकि इस पते के तहत कोई होस्ट या सक्रिय वेब सर्वर नहीं है। मुझे लगता है कि उन्होंने सिर्फ एक यादृच्छिक आईपी पता चुना है ताकि हमारा सिस्टम उन्हें लगातार ऑनलाइन "पुश" करे, क्योंकि कैश संस्करण सीमित अवधि तक मौजूद रहता है जब तक कि यह समाप्त नहीं हो जाता। इस बिंदु पर, वे संक्षेप में मेजबान के पास वापस आ गए और हमारे कैश में दिखाई देने के लिए एक नकली पते का संकेत दिया।

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

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

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



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

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

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

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

आप जानते हैं, जब मैंने हमारे द्वारा देखे गए सबसे बड़े हमलों की तुलना की थी, तो मैंने भी इसे देखा था जब हमारे ग्राहक को पाठ के साथ एक ईमेल मिला था: "नमस्ते, हम एक चीनी सरकारी एजेंसी हैं जिसने यह पाया है कि नेटवर्क पर कोई व्यक्ति आप पर हमला करने जा रहा है। "और यदि आप हमें $ 10,000 भेजते हैं, तो हम शायद इस समस्या को हल करने में सक्षम होंगे।" जाहिर है, यह एक एजेंसी नहीं है, लेकिन वे वास्तव में इस समस्या को हल करने में सक्षम हैं, क्योंकि वे खुद इसे बनाते हैं। हालांकि, इस तरह के हमले अपेक्षाकृत कम थे।

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



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

, Lulz Security, , Cloudflare. , , , . , , .



, 23 «», , . , !

: , , , . . , , , , . , , Microsoft , . . , RA Flood.

, IPv6, , , . Router Discovery , , IPv6, , , .

RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .



, : , . — , — , .

, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .

, Akamai, , . Load Balancer, , , . , , 4 , .



. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.

CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .

, , ? - ? - ? ? , , . , . , !


हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?