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

बाद में, हमें पता चला कि यह एक था Ransom DDoS हमला, और वह कम से कम एक ऑनलाइन पाठ्यक्रम प्रदाता (जो नियमित पाठकों का है) रिपोर्ट इसके बारे में पता होगा) भी हमला किया गया था। हमलावर ने "सभी समस्याओं के समाधान फ़ाइल" के लिए बिटकॉइन में $ 5,000 की मांग की।

समय इससे बुरा नहीं हो सकता था। मैं ग्वाटेमाला में था एमओओसी के साथ सीखना सम्मेलन। मैंने अभी एक मुख्य भाषण दिया था ( स्लाइड्स यहाँ ) और कुछ घंटों बाद एक पैनल में भाग लेने के लिए निर्धारित किया गया था। और हमारे सबसे वरिष्ठ इंजीनियर अपने गृहनगर के रास्ते पर थे और सप्ताह के लिए रवाना हो गए थे।

क्लास सेंट्रल 36 घंटे तक नीचे रहा क्योंकि हमने इसे वापस लाने के लिए काम किया। हमलावर हमारी हर हरकत को देख रहा था और उसका जवाब दे रहा था, यहां तक कि हमें संदेश भी भेज रहा था कि हमारे प्रयास व्यर्थ थे।

यह कहानी है कि हमने हमले को कैसे कम किया, क्या काम किया और क्या काम नहीं किया, एसईओ प्रभाव (लघु और दीर्घकालिक), साथ ही साथ यह हमें कितना खर्च करता है।

हमला: कैसे और क्यों

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

लेकिन लॉग्स को देखने के बाद, यह स्पष्ट हो गया कि हम भारी हमले में थे, जिसका पैमाना हम क्लाउडफ्लेयर पर स्विच करने के बाद ही महसूस करेंगे।

यह हमला 'फिरौती' है। डीडीओएस हमला ." सीधे शब्दों में कहें, लाखों बॉट्स ने हर घंटे क्लास सेंट्रल होमपेज पर जाना शुरू कर दिया। हमारे सर्वर वास्तविक मनुष्यों और बॉट्स के बीच अंतर नहीं कर सकते थे, और हम केवल एक समय में उपयोगकर्ताओं की एक निश्चित संख्या की सेवा कर सकते हैं।

नतीजतन, हम वास्तविक लोगों को दूर कर रहे थे, क्योंकि हम बॉट्स की सेवा में व्यस्त थे। व्यावहारिक रूप से बोलते हुए, साइट हर किसी के लिए अनुपयोगी थी। अधिक जानने के लिए, Cloudflare में कुछ हैं इस विषय पर सबसे अच्छे व्याख्याकार .

कुछ घंटों बाद, हमें एहसास हुआ कि हमें क्यों निशाना बनाया जा रहा है। जॉन एवी जुनैद द्वारा किया गया हमलावर (ट्विटर हैंडल) @Evie24435208) मैंने मुझे मेरे व्यक्तिगत ट्विटर, क्लास सेंट्रल के ट्विटर के साथ-साथ हमारे संपर्क ईमेल पर भी मैसेज किया था। यहाँ संदेश है:

व्यक्ति ने संकेत दिया कि उन्होंने "एसक्यूएल इंजेक्शन भेद्यता" की पहचान की थी और इसका उपयोग "क्रैश अपाचे" के लिए किया था। यह एक स्पष्ट झूठ था। लॉग स्पष्ट थे: यह एक डीडीओएस हमला था। इसके अलावा, क्लास सेंट्रल उपयोग नहीं करता है Apache वेब सर्वर।

लेकिन मैं कल्पना कर सकता हूं कि कम तकनीकी संसाधनों वाली छोटी साइटें इसके लिए गिर सकती हैं। जैसा कि हमलावर ने उल्लेख किया है, असली खतरा "अपनी साइट को महीनों तक बंद रखना" था।  यहां तक कि अगर आप $ 5,000 का भुगतान करते हैं, तो कोई कारण नहीं है कि हमलावर रुक जाएगा या बाद में फिर से वही काम नहीं करेगा।

18 घंटे बाद, मुझे हमलावर से एक और संदेश मिला।

हमलावर ने देखा कि हमने Cloudflare (बाद में उस पर अधिक) पर स्विच किया था और अपनी मूल स्क्रिप्ट पर कायम रहे, यह कहते हुए कि यह एक "सॉफ्टवेयर समस्या" थी। लेकिन यहां, उन्होंने एक और खतरे की ओर इशारा किया: कि हम "Google रैंकिंग खो सकते हैं।

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

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

डीडीओएस शमन

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

लेकिन हमें जल्द ही एहसास हुआ कि यह हमला अधिक परिष्कृत था और विभिन्न प्रकार के आईपी पते का उपयोग किया गया था।

हमने नोट किया कि हमलावर हमारे होमपेज पर सारा ट्रैफिक भेज रहा था। इसलिए हमने होमपेज पर एक रखरखाव पृष्ठ दिखाना शुरू कर दिया, और इससे हमें बाकी साइट को ऊपर लाने की अनुमति मिली।

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

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

जैसा कि मैंने पहले उल्लेख किया था, उस समय, मैं एक सम्मेलन के लिए ग्वाटेमाला में था और अपने सहयोगी के साथ दूरस्थ रूप से काम कर रहा था @suparn जो भारत में था। जब यह सब शुरू हुआ तब भारत में रात के लगभग 2 बज रहे थे। और 24 घंटे बाद, सुपर्ण को एक ही सम्मेलन में दो रिमोट प्रस्तुतियां देनी थीं। कहने के लिए पर्याप्त है, उसे मुश्किल से नींद आई।

हमने तेजी से महसूस किया कि यह उससे कहीं अधिक है जिसे हम अपने दम पर संभाल सकते हैं। डीडीओएस शमन की दुनिया में, एक नाम है (सार्वजनिक धारणा के संदर्भ में, कम से कम) जो सबसे ऊपर खड़ा है: Cloudflare . हमारे अपने प्रयास विफल होने के बाद, हमने आखिरकार Cloudflare पर स्विच करने का फैसला किया।

Cloudflare बचाव के लिए सुपर्ण

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

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

खाता कार्यकारी ने हमें Cloudflare वेबसाइट पर कुछ उपयोगी संसाधनों के लिए निर्देशित किया, जिसमें हम कोशिश कर सकते थे। जब पूछा गया कि क्या वे क्लाउडफ्लेयर को कॉन्फ़िगर करने में हमारी मदद कर सकते हैं, तो हमने सीखा कि यह हमें न्यूनतम 1 साल की प्रतिबद्धता के साथ प्रति माह $ 5,000 खर्च करेगा। ईमानदारी से, हमलावर की कीमत अधिक उचित लग रही थी।

लेकिन सारी उम्मीदें खत्म नहीं हुईं। जब आप चुटकी में होते हैं, तो आप कभी-कभी अपनी बेड़ियों को तोड़ने और जल्दी से समतल करने में सक्षम होते हैं। सबसे बुरा क्या हो सकता है? साइट पहले से ही डाउन थी।

सुपर्ण ने बस यही किया। यह लगभग ऐसा था जैसे भविष्य का एक सुपर्ण वर्तमान में वर्तमान सुपर्ण का मार्गदर्शन कर रहा था।

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

रहस्य Cloudflare में निहित है दर सीमित करना और IP Access नियम। आखिरकार, हमलावर पीछे हट गया। हमला शुरू होने के करीब 36 घंटे बाद क्लास सेंट्रल फिर से ऑनलाइन हो गया और उसकी हालत स्थिर हो गई।

लागत

हमारे द्वारा सेवा किए जाने वाले ट्रैफ़िक की मात्रा की तुलना में क्लास सेंट्रल परिचालन लागत अपेक्षाकृत कम है। लेकिन सिर्फ 36 घंटों में, हमारे Google क्लाउड की लागत महीने के लिए दोगुनी हो गई। मूल रूप से बॉट ट्रैफ़िक की उच्च मात्रा ने हमारी नेटवर्किंग लागत को आसमान छूने का कारण बना दिया।

संक्षेप में, बॉट ट्रैफ़िक की लागत हमें प्रति दिन $ 1,000 थी, भले ही क्लास सेंट्रल इस समय के बहुमत से नीचे था। यह इस डीडीओएस हमले के सबसे डरावने पहलुओं में से एक था और शायद यह भी कारण है कि ये हमले प्रभावी हो सकते हैं।

एसईओ प्रभाव

सौभाग्य से, हमारे एसईओ पर दीर्घकालिक प्रभाव नहीं पड़ा। हमले के तुरंत बाद के सप्ताह में खोज यातायात में कमी आई थी, लेकिन तब से यह वापस आ गया है और ऊपर जाना जारी है।

एक बात जो मैंने नोटिस की थी वह Google से क्रॉल अनुरोधों में एक महत्वपूर्ण गिरावट थी। यह स्पष्ट नहीं है कि यह हमले के कारण है या क्लाउडफ्लेयर पर स्विच के कारण है। लेकिन यह एक ऐसी चीज है जिस पर नजर रखनी चाहिए।

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