Panix.com डोमेन हाईजैक: कैसे पाँच दिनों के ऑटो-अप्रूवल नियम ने न्यू यॉर्क के सबसे पुराने ISP को चुरा लिया

पंद्रह से अधिक वर्षों तक, संयुक्त राज्य अमेरिका के सबसे पुराने व्यावसायिक इंटरनेट प्रदाताओं में से एक एक ही पते पर रहा: panix.com। फिर, जनवरी 2005 में एक लंबी छुट्टी के सप्ताहांत के दौरान, किसी ने उसे छीन लिया।

किसी सर्वर को हैक करके नहीं। कोई पासवर्ड अनुमान लगाकर नहीं। उन्होंने एक ट्रांसफर फॉर्म भरा, चुराए गए क्रेडिट कार्ड से भुगतान किया, और एक बिल्कुल नए ICANN नियम का इंतजार किया कि वह बाकी काम करे। कुछ ही घंटों में panix.com की स्वामित्व ऑस्ट्रेलिया की एक कंपनी को स्थानांतरित कर दी गई थी, इसके DNS को यूनाइटेड किंगडम के एक होस्ट पर इंगित किया गया था, और इसका ईमेल कनाडा के ज़रिए रीरूट किया गया था — और यह सब तब हुआ जब जो लोग वास्तव में Panix चलाते थे, वे शनिवार की रात सो रहे थे, बिना किसी चेतावनी के।

यह उस कहानी है कि कैसे एक प्रशासनिक कागज़ी कार्रवाई, किसी exploit से नहीं, ने न्यू यॉर्क के सबसे पुराने ISP को हाईजैक किया — और कैसे इसकी सफाई ने उन नियमों को फिर से लिखने में मदद की जो यह तय करते हैं कि डोमेन को कौन स्थानांतरित कर सकता है।

एक अग्रणी ISP जिसका पूरा व्यवसाय एक डोमेन पर निर्भर था

Panix — Public Access Networks Corporation — कोई छोटी कहानी नहीं थी। 1989 में स्थापित, यह विकिपीडिया के अनुसार, The World और NetCom के बाद दुनिया का तीसरा सबसे पुराना ISP था। यह न्यू यॉर्क शहर में प्रारंभिक व्यावसायिक इंटरनेट का एक अभिन्न हिस्सा था: शेल अकाउंट, ईमेल, वेब होस्टिंग, डायल-अप और फिर ब्रॉडबैंड कनेक्शन जिनका उपयोग हजारों न्यू यॉर्कवासी ऑनलाइन होने के लिए करते थे।

और लगभग हर इंटरनेट व्यवसाय की तरह तब और अब, Panix की पहचान उसका डोमेन था। ग्राहकों के मेलबॉक्स @panix.com पर समाप्त होते थे। वेब सर्वर www.panix.com पर उत्तर देते थे। पूरी कंपनी — उसका ब्रांड, उसकी पहुँच, वह चीज़ जो ग्राहक का ईमेल वास्तव में पहुँचाती थी — एक नाम से जुड़े DNS रिकॉर्ड पर टिकी थी। उस नाम का नियंत्रण खो दें, और आप कोई मार्केटिंग संपत्ति नहीं खोते। आप व्यवसाय का तंत्रिका तंत्र खो देते हैं।

ठीक यही हुआ।

जनवरी 2005: धोखाधड़ी से ट्रांसफर

कानूनी वृत्तांत दिन के बारे में सटीक है। जैसा कि लॉ फर्म Davis Wright Tremaine ने उस समय सारांशित किया, शुक्रवार, 14 जनवरी 2005 को, एक हाई-प्रोफाइल हाईजैकिंग तब हुई जब डोमेन नाम "panix.com," जो उसी नाम के न्यू यॉर्क-स्थित इंटरनेट सेवा प्रदाता का था, को अनधिकृत रूप से एक तृतीय पक्ष को स्थानांतरित कर दिया गया।

उस सप्ताहांत की शुरुआती घड़ियों तक, परिणाम जीवंत हो गए थे। The Register ने घटना के सामने आते ही रिपोर्टिंग करते हुए, एक वाक्य में पुनर्निर्देशन का वर्णन किया जो आज भी एक डकैती आरेख की तरह पढ़ता है: panix.com की स्वामित्व ऑस्ट्रेलिया की एक कंपनी को स्थानांतरित की गई, वास्तविक DNS रिकॉर्ड यूनाइटेड किंगडम की एक कंपनी को स्थानांतरित किए गए, और Panix.com का मेल कनाडा की एक और कंपनी के ज़रिए पुनर्निर्देशित किया गया।

Slashdot, जहाँ 16 जनवरी को व्यापक तकनीकी समुदाय तक खबर पहुँची, ने इसे स्पष्ट शब्दों में कहा: Panix, न्यू यॉर्क का सबसे पुराना व्यावसायिक इंटरनेट प्रदाता, अपना डोमेन नाम 'panix.com' अज्ञात व्यक्तियों द्वारा हाईजैक कर लिया गया।

Panix के दृष्टिकोण से सबसे निंदनीय विवरण था — चुप्पी। कंपनी जो 1989 में स्थापित हुई थी और न्यू यॉर्क के सबसे पुराने व्यावसायिक ISP थे, ने कहा कि न तो उसे और न ही उसके रजिस्ट्रार को प्रस्तावित परिवर्तनों की कोई सूचना मिली। डोमेन छीनने वाला ट्रांसफर, जहाँ तक वैध मालिक बता सकता था, पूरी तरह से अदृश्य था जब तक कि यह हो नहीं गया था।

व्यवधान: वेब और ईमेल कई दिनों के लिए बंद

एक हाईजैक किया गया डोमेन एक साफ ऑन/ऑफ स्विच नहीं है — यह एक धीमा, भद्दा क्षय है, और सबसे बुरा नुकसान मेल का है।

जब आप किसी डोमेन के DNS को नियंत्रित करते हैं, तो आप नियंत्रित करते हैं कि उसका ईमेल कहाँ डिलीवर होता है। panix.com के मेल रिकॉर्ड को पुनः इंगित करके, हाईजैकर्स पूरे ISP के ग्राहक आधार के लिए डाकघर बन गए। आने वाले संदेश — बिल, पासवर्ड रीसेट, व्यावसायिक पत्राचार, व्यक्तिगत मेल — Panix पर आना बंद हो गए और हमलावरों द्वारा नियंत्रित सर्वर की ओर प्रवाहित होने लगे। InfoWorld ने, धूल जमने के बाद रिपोर्ट करते हुए, नोट किया कि हाईजैकिंग ने कुछ Panix ग्राहकों को दो दिनों के लिए ई-मेल एक्सेस से वंचित कर दिया, और कि उन ग्राहकों में से कुछ ने सप्ताहांत में सौ या अधिक संदेश खो दिए होंगे।

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

और ग्राहक कुछ नहीं कर सकते थे। समस्या Panix की मशीनों पर नहीं थी, जो ठीक चल रही थीं। यह डोमेन नाम प्रणाली की वैश्विक रूटिंग तालिका में थी, जिसे — ऑस्ट्रेलिया के एक रजिस्ट्रार द्वारा, एक धोखाधड़ी के अनुरोध पर कार्य करते हुए — बताया गया था कि panix.com अब किसी और का है।

यह कैसे हुआ: ऑटो-अप्रूव ट्रांसफर लूपहोल

यहाँ वह हिस्सा है जो Panix को एक मील का पत्थर मामला बनाता है, न कि केवल एक और बुरा सप्ताहांत: कोई अंदर नहीं घुसा। सिस्टम ने ठीक उसी तरह काम किया जैसा डिज़ाइन किया गया था। डिज़ाइन ही कमज़ोरी था।

यांत्रिकी बिचौलियों की एक श्रृंखला के माध्यम से चली। Panix का डोमेन Dotster के साथ पंजीकृत था, जो वैंकूवर, वाशिंगटन का एक रजिस्ट्रार था। धोखाधड़ी का ट्रांसफर Fibranet Services Ltd. पर एक खाते के माध्यम से शुरू किया गया था, जो एक यू.के.-स्थित रिसेलर था, जिसने इसे Melbourne IT, ऑस्ट्रेलिया के एक बड़े रजिस्ट्रार तक प्रस्तुत किया। जैसा कि InfoWorld ने रिपोर्ट किया, Melbourne IT Ltd. की एक त्रुटि ने चुराए गए क्रेडिट कार्ड का उपयोग करने वाले धोखेबाजों को Panix.com का नियंत्रण लेने की अनुमति दी — ट्रांसफर के लिए उपयोग किया गया खाता धोखाधड़ीपूर्ण था और चुराए गए क्रेडिट कार्ड से स्थापित किया गया था।

लेकिन क्रेडिट कार्ड धोखाधड़ी ने केवल खाता खोला। डोमेन को वास्तव में जो स्थानांतरित किया वह एक नीति थी। ICANN ने एक नई इंटर-रजिस्ट्रार ट्रांसफर प्रक्रिया पेश की थी जो केवल कुछ सप्ताह पहले नवंबर 2004 में प्रभावी हुई थी, डिफ़ॉल्ट अनुमोदन के सिद्धांत के इर्द-गिर्द बनाई गई थी। जैसा कि The Register ने समझाया, नए ढाँचे के तहत ये नियम, जो पिछले नवंबर में प्रभावी हुए, का मतलब है कि इंटर-रजिस्ट्री ट्रांसफर अनुरोध पाँच दिनों के बाद स्वचालित रूप से अनुमोदित हो जाते हैं जब तक कि डोमेन मालिक द्वारा प्रतिआदेश न दिया जाए।

इसे फिर से पढ़ें, क्योंकि यही पूरी कहानी है। चुप्पी का मतलब था हाँ। अगर वैध मालिक ने कुछ नहीं किया — क्योंकि, उदाहरण के लिए, उन्हें कभी नोटिस नहीं मिला — ट्रांसफर अपने आप हो गया। Davis Wright Tremaine ने कानूनी पक्ष से उसी जाल का वर्णन किया: नए नियम शायद धोखाधड़ी के ट्रांसफर को पूरा करना आसान बनाते हैं क्योंकि नियमों के तहत डोमेन स्वचालित रूप से ट्रांसफर हो जाते हैं जब तक कि मालिक पाँच दिनों के भीतर ट्रांसफर अनुरोध का प्रतिआदेश नहीं देता।

विफलताओं को ढेर करें और तस्वीर भयावह है। लाभ प्राप्त करने वाले रजिस्ट्रार (Melbourne IT, Fibranet के माध्यम से) ने एक चुराए गए कार्ड पर आधारित अनुरोध स्वीकार किया और, अपनी बाद की स्वीकारोक्ति से, अनुरोध को ठीक से सत्यापित करने में विफल रहा। डोमेन खोने वाले रजिस्ट्रार (Dotster) और वैध मालिक (Panix) को कोई प्रभावी सूचना नहीं मिली और इसलिए उन्होंने कभी कोई प्रतिआदेश नहीं दिया। और नीति का डिफ़ॉल्ट — जब तक कोई आपत्ति न करे तब तक अनुमोदित करें — ने आपत्ति की उस अनुपस्थिति को एक पूर्ण चोरी में बदल दिया। कोई फ़ायरवॉल नहीं तोड़ा गया। कागज़ी कार्रवाई ही हमला थी।

पुनर्प्राप्ति, और इससे शुरू हुए नीति सुधार

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

रविवार तक, Panix ने ऑस्ट्रेलियाई डोमेन होस्टिंग / पंजीकरण फर्म Melbourne IT से अपना Panix.com डोमेन वापस पा लिया, जहाँ चुराया गया डोमेन पार्क किया गया था, और इसे Dotster पर अपने प्राकृतिक घर पर वापस इंगित किया। रजिस्ट्री स्तर पर सुधार लगभग तुरंत था; वैश्विक सफाई नहीं थी, क्योंकि DNS आदेश पर नहीं भूलता। जैसा कि The Register ने नोट किया, रूट सर्वर जल्दी से अपडेट किए गए लेकिन DNS की वितरित प्रकृति का मतलब था कि सामान्यता पूरी तरह से बहाल होने से पहले 24 घंटे तक का समय लगेगा — दुनिया भर के कैश को समाप्त होना था इससे पहले कि हर उपयोगकर्ता वास्तविक panix.com देखे।

Melbourne IT ने, अपने श्रेय को, छिपाया नहीं। दो दिन बाद The Register ने रिपोर्ट किया कि एक ऑस्ट्रेलियाई डोमेन रजिस्ट्रार ने पिछले सप्ताहांत के डोमेन नाम हाईजैक में अपनी भूमिका को स्वीकार किया है, विफलता को अपनी ट्रांसफर प्रक्रिया में एक सत्यापन चरण से जोड़ते हुए जो नहीं किया गया था और यह वचन देते हुए कि त्रुटि की अनुमति देने वाले लूपहोल को बंद कर दिया गया है।

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

• डिफ़ॉल्ट रूप से रजिस्ट्रार लॉक। clientTransferProhibited पर सेट डोमेन बस ट्रांसफर करने से इनकार करता है जब तक कि वैध धारक द्वारा लॉक हटाया न जाए। जो कभी एक अस्पष्ट ऑप्ट-इन था, वह कई रजिस्ट्रार के लिए डिफ़ॉल्ट स्थिति बन गया — एक ब्रेक जिसे ऑटो-अप्रूव नियम ओवरराइड नहीं कर सकता था।
• Auth कोड (EPP ट्रांसफर कोड)। आधुनिक gTLD ट्रांसफर के लिए एक गुप्त प्राधिकरण कोड की आवश्यकता होती है जिसे डोमेन खोने वाला रजिस्ट्रार केवल सत्यापित रजिस्ट्रेंट को जारी करता है, इसलिए लाभ प्राप्त करने वाला रजिस्ट्रार अब अकेले कागज़ी कार्रवाई पर डोमेन नहीं खींच सकता।
• एक दस्तावेज़ीकृत ICANN ट्रांसफर नीति सख्त पुष्टि कर्तव्यों के साथ और ठीक इस प्रकार के धोखाधड़ीपूर्ण ट्रांसफर को तेज़ी से उलटने के लिए एक आपातकालीन संपर्क चैनल के साथ।

Panix हाईजैक ने अकेले इन तंत्रों का आविष्कार नहीं किया, लेकिन यह वह मामला बन गया जिसे हर कोई तब इंगित करता था जब यह तर्क करता था कि वे आवश्यक हैं।

ट्रांसफर लॉक और सत्यापन के बारे में यह क्या सिखाता है

तारीखें और रजिस्ट्रार नाम हटा दें, और Panix कुछ स्थायी सबक छोड़ता है।

1. डिफ़ॉल्ट-अनुमति एक सुरक्षा निर्णय है, और आमतौर पर गलत। 2005 में एकल सबसे खतरनाक डिज़ाइन विकल्प यह था कि चुप्पी सहमति के बराबर है। एक ट्रांसफर जो तब पूरा होता है जब मालिक कुछ नहीं करता, मानता है कि मालिक हमेशा देख रहा है और हमेशा पहुँचयोग्य है। छुट्टी के सप्ताहांत में न तो पहला सच है और न ही दूसरा।
2. पहचान को संपत्ति देने वाले पक्ष द्वारा सत्यापित किया जाना चाहिए, न केवल इसे लेने वाले पक्ष द्वारा। लाभ प्राप्त करने वाला रजिस्ट्रार व्यवसाय चाहता था और हाँ कहने के लिए हर प्रोत्साहन था। वास्तविक सुरक्षा तभी आई जब डोमेन खोने वाले रजिस्ट्रार को एक सत्यापित धारक को एक auth कोड जारी करना पड़ा — सत्यापन को वहाँ रखना जहाँ संपत्ति वास्तव में रहती है।
3. लॉक चालू करें। clientTransferProhibited सबसे सस्ता, सबसे प्रभावी सुरक्षा है जो एक डोमेन मालिक के पास इस सटीक हमले के खिलाफ है, और इसकी कोई कीमत नहीं है। एक लॉक किए गए डोमेन को कागज़ी कार्रवाई कितनी भी आश्वस्त करने वाली हो, चुपचाप ट्रांसफर नहीं किया जा सकता। अपने महत्वपूर्ण नाम लॉक करें और उन्हें लॉक रखें।
4. आपका डोमेन आपकी एकमात्र विफलता का बिंदु है। Panix के सर्वर कभी समझौता नहीं हुए, फिर भी कंपनी प्रभावी रूप से ऑफलाइन थी। जब एक रजिस्ट्री में एक रिकॉर्ड आपकी पूरी वेब और ईमेल उपस्थिति को पुनर्निर्देशित कर सकता है, तो उस रिकॉर्ड को आपके सर्वर से अधिक सुरक्षा की आवश्यकता है।
5. नोटिस देखें। पाँच-दिवसीय प्रतिआदेश विंडो केवल उस मालिक की रक्षा करती है जो वास्तव में ट्रांसफर नोटिस प्राप्त करता है — और पढ़ता है। पुराना रजिस्ट्रेंट ईमेल, एक अनमॉनिटर्ड एडमिन संपर्क, या एक छुट्टी का सप्ताहांत एक सेफ्टी वाल्व को एक मूक विफलता में बदल देता है।

Namefi का दृष्टिकोण

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

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

1989 में जब Panix की स्थापना हुई थी तब इनमें से कुछ भी मौजूद नहीं था — या 2005 में भी नहीं, जब हाईजैक हुआ। लेकिन यह उस सबक की ओर इशारा करता है जो उस सप्ताहांत ने पूरे उद्योग को सिखाया: एक डोमेन बहुत महत्वपूर्ण है कि उसे चुप्पी से संचालित किया जाए। स्वामित्व कुछ ऐसा होना चाहिए जिसे आप माँग पर साबित कर सकें — और कुछ ऐसा जो एक अजनबी केवल इसलिए नहीं ले सकता क्योंकि आप एक लंबे सप्ताहांत में इनबॉक्स नहीं देख रहे थे।

स्रोत और आगे की पढ़ाई

• The Register — Panix डोमेन हाईजैक से उबरता है
• The Register — Panix.com हाईजैक: ऑस्ट्रेलियाई फर्म ज़िम्मेदारी लेती है
• Davis Wright Tremaine — डोमेन नाम हाईजैकिंग से बचाव
• InfoWorld — ऑस्ट्रेलियाई कंपनी Panix डोमेन हाईजैक की ज़िम्मेदारी लेती है
• Slashdot — न्यू यॉर्क के सबसे पुराने ISP का डोमेन-जैक
• Wikipedia — Panix (ISP)
• Wikipedia — डोमेन हाईजैकिंग
• ICANN SSAC — डोमेन नाम हाईजैकिंग: घटनाएँ, खतरे, जोखिम और उपचारात्मक कार्रवाइयाँ (2005)
• ICANN — ट्रांसफर नीति
• NANOG मेलिंग सूची संग्रह — panix.com ट्रांसफर और ICANN उपचारों की चर्चा