Namefi

Dyn DNS हमला: जब हैक किए गए कैमरों के Mirai बॉटनेट ने आधे इंटरनेट को ठप कर दिया

21 अक्टूबर 2016 को, Mirai IoT बॉटनेट द्वारा संचालित एक DDoS हमले ने DNS प्रदाता Dyn को तीन लहरों में निशाना बनाया, जिससे Twitter, Netflix, Reddit, Spotify, GitHub, Airbnb और PayPal घंटों के लिए ऑफलाइन हो गए — DNS प्रदाता केंद्रीकरण पर एक Domain Mayday केस स्टडी।

Fenwei BianFenwei BianलेखकVictor ZhouVictor Zhouसंपादक17 जून 2026लगभग 12 मिनट पढ़ाई
  • domains
  • security
  • dns
  • domain-security
X पर शेयर करें

अक्टूबर 2016 के एक शुक्रवार को कुछ घंटों के लिए, इंटरनेट खुद को ढूंढना भूल गया।

Twitter एक खाली पेज दिखाने लगा। Netflix स्पिन होता रहा और फिर बंद हो गया। Reddit, Spotify, GitHub, Airbnb, PayPal — सभी वहाँ थे, सभी ऑनलाइन थे, अपने सर्वर पर बिल्कुल ठीक से चल रहे थे, और फिर भी पूरी तरह से अपहुँच हो गए थे। कोई हैक नहीं हुआ था। कोई डेटा चोरी नहीं हुआ था। वेबसाइटें ठीक वहीं थीं जहाँ वे हमेशा से रही थीं। जो टूटा वह था इंटरनेट का वह हिस्सा जो आपको बताता है कि चीज़ें कहाँ हैं

हमले ने Twitter या Netflix को नहीं मारा। उसने एक ऐसी कंपनी को मारा जिसके बारे में उनके अधिकांश उपयोगकर्ताओं ने कभी नहीं सुना था: Dyn, न्यू हैम्पशायर की एक फर्म जो DNS — इंटरनेट की पता-पुस्तिका — चलाती थी, आधुनिक वेब के एक बड़े हिस्से के लिए। और हथियार कोई सर्वर फ़ार्म या किसी राष्ट्र-राज्य का शस्त्रागार नहीं था। यह हैक किए गए बेबी मॉनिटर, वेबकैम और होम राउटर का एक झुंड था: साधारण घरेलू उपकरण, चुपचाप एक सेना में भर्ती किए गए जिसे Mirai कहा गया।

यह है Domain Mayday EP08 — वह दिन जब असुरक्षित स्मार्ट-कैमरों ने इंटरनेट की फ़ोन बुक को ठप कर दिया।

DNS: इंटरनेट की फ़ोन बुक, और उसमें Dyn की जगह

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

Dyn उस लुकअप सेवा के बड़े प्रबंधित प्रदाताओं में से एक था। जब किसी साइट ने अपना DNS Dyn को आउटसोर्स किया, तो Dyn के नेमसर्वर "यह डोमेन कहाँ रहता है?" के लिए आधिकारिक स्रोत बन गए। The Register ने हमले के दौरान स्पष्ट रूप से निर्भरता को बताया: Dyn को ऑफलाइन करके, Google और ISP द्वारा चलाए जाने वाले सार्वजनिक DNS रिसॉल्वर netizens के लिए hostnames lookup करने के लिए Dyn से संपर्क करने में असमर्थ थे, जिससे लोग Dyn को DNS के लिए उपयोग करने वाली साइटों तक पहुँचने से वंचित हो गए

यही इस कहानी के केंद्र में शांत नाज़ुकपन है। एक वेबसाइट बेदाग हो सकती है — अनावश्यक सर्वर, सही अपटाइम, विश्व स्तरीय इंजीनियर — और फिर भी इंटरनेट से गायब हो सकती है यदि "यह कहाँ है?" का उत्तर देने वाला एक प्रदाता अंधेरे में चला जाए। जैसा कि Carnegie Mellon के CyLab ने बाद में सारांशित किया, प्रभावित डोमेन एक तृतीय-पक्ष DNS, Dyn पर गंभीर रूप से निर्भर थे। दूसरे शब्दों में, वे केवल Dyn पर निर्भर थे, इसलिए जब Dyn नीचे गया, तो वे भी नीचे चले गए

21 अक्टूबर 2016: हमला लहरों में आया

ग्लोइंग जंक ट्रैफ़िक की एक ज्वारीय लहर का जीवंत रंगीन अवधारणा कला जो एक विशाल प्रकाशित फ़ोन-बुक स्विचबोर्ड से टकरा रही है, एक अंधेरे नक्शे पर डायरेक्टरी की लाइटें टिमटिमा कर बंद हो रही हैं

हमला शुक्रवार, 21 अक्टूबर 2016 की सुबह शुरू हुआ, और यह एक ही प्रहार के रूप में नहीं आया। यह दिन के दौरान अलग-अलग लहरों में आया।

Wikipedia का घटना का रिकॉर्ड Dyn के खिलाफ तीन लगातार distributed denial-of-service हमलों को सूचीबद्ध करता है, जो UTC 11:10 के आसपास शुरू हुए। यांत्रिकी एक पाठ्यपुस्तक distributed denial-of-service थी: DDoS हमला करोड़ों IP पतों से DNS lookup अनुरोधों के माध्यम से पूरा किया गया, Dyn के नेमसर्वर को इतने जंक ट्रैफ़िक में डुबो दिया कि वैध लुकअप नहीं हो सके।

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

कच्ची मात्रा में, हमला उस युग के लिए विशाल था — उस बिंदु तक देखी गई सबसे बड़ी DDoS घटनाओं में से एक, जिसे The Register ने 1 TBps से अधिक की चरम के रूप में चित्रित किया। (Dyn ने स्वयं चेतावनी दी थी कि वैध ट्रैफ़िक के "retry storm" ने कुछ प्रारंभिक अनुमानों को बढ़ा-चढ़ाकर दिखाया, एक बिंदु जिस पर हम वापस आएंगे।)

कौन सी साइटें अंधेरे में गईं — और यह कैसा लगा

जब Dyn के नेमसर्वर उत्तर नहीं दे सके, तो विफलता उन सभी लोगों तक फैल गई जो उन पर निर्भर थे। यह वेब का कोई अस्पष्ट कोना नहीं था। यह उपभोक्ता इंटरनेट का पहला पृष्ठ था।

The Register की लाइव रिपोर्ट ने कुछ हताहतों को सीधे नाम दिया: Dyn पर एक असाधारण, केंद्रित हमला जो सैकड़ों कंपनियों के इंटरनेट सेवाओं को बाधित करता रहा, जिसमें ऑनलाइन दिग्गज Twitter, Amazon, AirBnB, Spotify और अन्य शामिल हैं। Wikipedia की प्रभावित सेवाओं की सूची उस युग की सबसे बड़ी साइटों की एक फहरिस्त जैसी पढ़ी जाती है: Airbnb, Amazon.com, CNN, GitHub, Netflix, PayPal, Reddit, Spotify, Twitter, और दर्जनों और।

Brian Krebs, जिनकी अपनी साइट को हफ्तों पहले उसी मैलवेयर ने मारा था, ने उपभोक्ता अनुभव का वर्णन किया — हमले ने इंटरनेट उपयोगकर्ताओं के लिए साइटों की एक श्रृंखला तक पहुँचने में समस्याएं पैदा करनी शुरू कर दीं, जिनमें Twitter, Amazon, Tumblr, Reddit, Spotify और Netflix शामिल हैं। साधारण उपयोगकर्ताओं के लिए, कोई ऐसी त्रुटि नहीं थी जो समझ में आती। साइटें बस लोड नहीं होती थीं — पहले US East Coast के साथ, फिर जैसे-जैसे बाद की लहरें आईं, अमेरिका भर में और यूरोप तक फैलती गईं।

यह कैसे हुआ: असुरक्षित स्मार्ट डिवाइस की एक सेना

हज़ारों छोटे मुस्कुराते हैक किए गए स्मार्ट-कैमरों, टोस्टरों और बेबी मॉनिटरों का जीवंत रंगीन अवधारणा कला जो ग्लोइंग कीड़ों की तरह एक ओवरलोडेड डायरेक्टरी टॉवर की ओर झुंड में आ रहे हैं

यहाँ वह हिस्सा है जिसने Dyn हमले को एक महत्वपूर्ण मोड़ बना दिया: आग्नेय शक्ति कंप्यूटरों से नहीं आई। यह चीज़ों से आई।

Mirai एक मैलवेयर है जो Internet-of-Things डिवाइस — कैमरे, राउटर, DVR — की तलाश करता है और उन्हें हाईजैक करता है। यह उपभोक्ता हार्डवेयर में सबसे आलसी कमज़ोरी का फायदा उठाकर काम करता है: वह पासवर्ड जो डिवाइस शिप के साथ आया था। जैसा कि The Register ने इसका वर्णन किया, Mirai वेब पर फैलता है, आज्ञाकारी ज़ॉम्बी की अपनी रैंक बढ़ाता है, Telnet और SSH के माध्यम से उनके डिफ़ॉल्ट, फ़ैक्टरी-सेट पासवर्ड का उपयोग करके डिवाइस में लॉग इन करके। Krebs ने यंत्रविधि को उतनी ही सीधी तरह से बताया: Mirai IoT डिवाइस के लिए वेब खंगालता है जो केवल फ़ैक्टरी-डिफ़ॉल्ट उपयोगकर्ता नाम और पासवर्ड से सुरक्षित हैं, और फिर डिवाइस को हमलों में शामिल कर लेता है

Dyn हमले के केंद्र में डिवाइस मुख्य रूप से सस्ते वेबकैम और DVR थे। Krebs ने बॉटनेट को मुख्य रूप से डिजिटल वीडियो रिकॉर्डर (DVR) और IP कैमरों से समझौता किए गए, जो XiongMai Technologies नामक एक चीनी हाई-टेक कंपनी द्वारा बनाए गए थे तक ट्रेस किया — ऐसे डिवाइस जिनके डिफ़ॉल्ट क्रेडेंशियल, कई मामलों में, एक उपयोगकर्ता व्यावहारिक रूप से बदल नहीं सकता क्योंकि पासवर्ड फर्मवेयर में हार्डकोड था।

दो चीज़ों ने Mirai को परेशानी से तबाही में बदल दिया। पहला, मैलवेयर के लेखक ने सितंबर 2016 के अंत में इसका सोर्स कोड जारी किया था, जिससे प्रभावी रूप से कोई भी अपनी खुद की हमले की सेना बना सकता था। दूसरा, कमज़ोर डिवाइस की आबादी विशाल थी। Dyn ने हमले के हस्ताक्षर की पुष्टि की: कंपनी यह पुष्टि करने में सक्षम थी कि हमले के ट्रैफ़िक की एक महत्वपूर्ण मात्रा Mirai-based बॉटनेट से उत्पन्न हुई थी, और Wikipedia बॉटनेट को इंटरनेट-कनेक्टेड डिवाइस — जैसे प्रिंटर, IP कैमरे, रेज़िडेंशियल गेटवे और बेबी मॉनिटर — के एक झुंड के रूप में वर्णित करता है जो Mirai मैलवेयर से संक्रमित थे

परिणाम: झुंड की गिनती — और अपराधियों की

जब धूल जम गई, तो यह कितना बड़ा था का बुनियादी सवाल भी मुश्किल साबित हुआ। Dyn का अपना घटना-पश्चात विश्लेषण, EVP Scott Hilton के माध्यम से, बॉटनेट का अनुमान 100,000 दुर्भावनापूर्ण endpoints तक लगाया — बड़ा, लेकिन कुछ शुरुआती आंकड़ों द्वारा सुझाए गए "करोड़ों IPs" से छोटा। विसंगति एक फीडबैक लूप से आई: दुर्भावनापूर्ण हमले कम से कम एक बॉटनेट से उत्पन्न हुए, retry storm के साथ endpoints के एक महत्वपूर्ण रूप से बड़े सेट का झूठा संकेत प्रदान करते हुए जितना हम अब जानते हैं। दूसरे शब्दों में, इंटरनेट के अपने स्वचालित "पुनः प्रयास करें" व्यवहार ने अराजकता को बढ़ा दिया।

कानूनी परिणाम ने एक मोड़ जोड़ा। Mirai के पीछे तीन युवा — Paras Jha, Josiah White, और Dalton Norman — अंततः "Mirai botnet" बनाने, संचालित करने और उसकी पहुँच बेचने में उनकी भूमिका के लिए दोषी साबित हुए। लेकिन Dyn हमले के समय तक, Jha पहले ही सोर्स कोड सार्वजनिक रूप से जारी कर चुका था — और अभियोजकों और पत्रकारों ने ध्यान देने योग्य रूप से नोट किया है कि Dyn हमलावर जरूरी नहीं कि मूल तीनों थे। जैसा कि CyberScoop ने रिपोर्ट किया, यह अभी तक स्पष्ट नहीं है, उदाहरण के लिए, इंटरनेट परफॉर्मेंस मैनेजमेंट कंपनी Dyn के खिलाफ सबसे अधिक प्रोफाइल वाले Mirai-linked हमले के पीछे कौन था। एक बार हथियार ओपन-सोर्स हो गया, कोई भी ट्रिगर खींच सकता था।

Dyn के लिए, व्यावसायिक नुकसान वास्तविक था: उसके बाद के महीनों में, हजारों डोमेन ने अपना DNS कहीं और ले जाया, एक बुरे दिन के बाद ग्राहक विश्वास में एक महंगा सबक।

यह DNS प्रदाता केंद्रीकरण के बारे में क्या सिखाता है

Dyn हमले को IoT-सुरक्षा की कहानी के रूप में याद किया जाता है, और यह है भी। लेकिन इसका गहरा सबक वास्तुकला के बारे में है: इंटरनेट के बहुत अधिक हिस्से को एक चोकपॉइंट के माध्यम से रूट करने का खतरा।

21 अक्टूबर को अंधेरे में गई हर साइट ने वही उचित लगने वाला निर्णय लिया था — DNS को एक उत्कृष्ट प्रदाता को आउटसोर्स करें। व्यक्तिगत रूप से, स्मार्ट। सामूहिक रूप से, इसका मतलब था कि एक कंपनी को खटखटाने से एक साथ वेब का एक महत्वपूर्ण अंश खाली हो सकता था। CyLab का फैसला था कि हमले के सबक केवल उन कुछ मुट्ठी भर वेबसाइटों द्वारा ही अमल में लाए गए हैं जो सीधे प्रभावित हुई थीं, यहाँ तक कि वर्षों बाद भी।

रक्षात्मक उत्तर अतिरेक है: एक से अधिक प्रदाता में आधिकारिक DNS फैलाना ताकि कोई एकल आउटेज घातक न हो। Dyn के दो साल बाद, The Register को पता चला कि यह अभी भी दुर्लभ था और अभी भी कष्टदायक था — Infoblox के Cricket Liu ने नोट किया कि कई आधिकारिक DNS प्रदाताओं का उपयोग करना आसान नहीं हो गया है, उदाहरण के लिए (जैसे Dyn plus Verisign या Neustar)। कई प्रदाताओं का उपयोग करने में सक्षम होना एक बड़ा अंतर करेगा। डोमेन पर निर्भर किसी के लिए भी मुख्य बातें:

  1. एक डोमेन में उसके रजिस्ट्रार से अधिक विफलता बिंदु होते हैं। "यह नाम कहाँ इंगित करता है?" का उत्तर देने वाला प्रदाता उतना ही बोझ उठाने वाला है जितना कि इसके पीछे के सर्वर।
  2. सिंगल-प्रदाता DNS एकल विफलता बिंदु है। सामान्य परिस्थितियों में उत्कृष्ट अपटाइम 1 Tbps बाढ़ के तहत व्यवहार के बारे में कुछ नहीं कहता।
  3. केंद्रीकरण सुविधाजनक और नाज़ुक है। वही दक्षता जो एक प्रदाता को आकर्षक बनाती है, उसकी आउटेज को व्यापक रूप से महसूस कराती है।
  4. लचीलापन स्वामित्व की एक संपत्ति है, न कि केवल होस्टिंग की। जब कुछ टूटता है, तो आपको अपने डोमेन के कॉन्फ़िगरेशन को इतनी साफ़ तरह से नियंत्रित करने में सक्षम होना चाहिए कि आप तेज़ी से पुनः रूट कर सकें।

Namefi का कोण

रंगीन चित्रण सत्यापन योग्य, लचीले डोमेन स्वामित्व का — एक हरे रंग की ढाल, एक हरे Namefi टोकन, और DNS निरंतरता द्वारा सुरक्षित एक डोमेन कार्ड

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

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

Namefi इस विचार पर बना है कि डोमेन को इंटरनेट-नेटिव संपत्तियों की तरह व्यवहार करना चाहिए: स्वामित्व जो क्रिप्टोग्राफिक रूप से सत्यापन योग्य और पोर्टेबल हो, जबकि DNS के साथ पूरी तरह से संगत रहे। सत्यापन योग्य, मालिक-नियंत्रित डोमेन स्वामित्व एक बॉटनेट को नहीं रोकता — लेकिन यह दुनिया को एक ऐसे इंटरनेट की ओर धकेलता है जहाँ एक नाम का नियंत्रण साबित किया जा सकता है, ऑडिट किया जा सकता है, और चुपचाप एक प्रदाता के सबसे बुरे दिन पर निर्भर नहीं है। Mirai-Dyn हमला एक अनुस्मारक है कि आप जो डोमेन "अपना" रखते हैं वह उतना ही लचीला है जितनी कि उसके लिए उत्तर देने वाली परत। लचीलापन स्वामित्व और नियंत्रण को कुछ ऐसा बनाने से शुरू होता है जिसे आप वास्तव में सत्यापित कर सकें।

स्रोत और आगे पढ़ने के लिए

योगदानकर्ता

Fenwei Bian
Fenwei Bianलेखक
Software Developer & Writer • Namefi

Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.

She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.

For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.

Victor Zhou
Victor Zhouसंपादक
Founder & Standards Editor • Namefi

Victor Zhou is a technology founder and standards editor focused on digital identity and trust. He founded Namefi, edits Ethereum Improvement Proposals, and previously led smart-contract architecture work at Google Labs.

His work sits at the intersection of naming, ownership, and the systems people use to establish identity online. That perspective makes him especially interested in the way names move between personal meaning, public recognition, and digital infrastructure.

For Namefi, Victor edits and writes about domains as durable digital identity: how names become ownable onchain assets, how tokenization changes custody and trust, and what naming can learn from the systems people use to establish identity online.

संबंधित गाइड