DDoS जबरन वसूली: एडल्ट क्लासिफाइड्स साइट पर हमले को वास्तव में क्या रोकता है, और क्या नहीं

वह सुबह जब डायरेक्टरी बिना किसी वजह के लोड होना बंद कर देती है

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

इनमें से अधिकांश मामलों में वास्तव में जो हो रहा होता है वह एक डिस्ट्रिब्यूटेड डिनायल-ऑफ-सर्विस हमला है: हजारों समझौता किए गए डिवाइसों से आने वाला ट्रैफिक का एक रेला, जिसका मकसद साइट को असली विज़िटरों को जवाब देने से रोकना है। यह कोई दुर्लभ या अजीब बात नहीं है। Cloudflare की थ्रेट इंटेलिजेंस टीम ने बताया कि उसने 2026 की पहली छमाही में अपने नेटवर्क पर हर घंटे लगभग 5,343 नेटवर्क-लेयर DDoS हमलों को रोका, यानी रोज़ाना लगभग 128,000। इनमें से अधिकांश हमले सबसे बड़ी दर्ज घटनाओं की तुलना में छोटे और संक्षिप्त होते हैं: 96.62% हमले 500 Mbps से नीचे रहे, और 90.60% दस मिनट से भी कम समय में खत्म हो गए। फिर भी "छोटा" एक सापेक्ष शब्द है: एक 100 Mbps का हमला एक सामान्य असुरक्षित सर्वर को ठप करने के लिए काफी है, जो किसी ऐसी साइट के खिलाफ एक सामान्य सप्ताह की शाम को होने वाली घटनाओं का एक छोटा सा हिस्सा है जिसके बारे में किसी ने कभी सुना भी नहीं।

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

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

फिरौती का नोट, और भुगतान करने से कुछ भी खत्म क्यों नहीं होता

कुछ हमलों के साथ एक मांग जुड़ी होती है। सुरक्षा उद्योग में रैनसम DDoS या RDoS के नाम से जाना जाने वाला यह पैटर्न आम तौर पर एक छोटे डेमो हमले या ईमेल के ज़रिए सीधी धमकी से शुरू होता है, जिसके बाद एक रकम, लगभग हमेशा क्रिप्टोकरेंसी में, चुकाने का निर्देश आता है ताकि एक बड़ा हमला रोका जा सके या शुरू होने से पहले ही टाला जा सके। इस ठीक इस्तेमाल पर बने गिरोह, जिनमें DD4BC और Armada Collective सबसे शुरुआती हैं, लगभग 2014 से यह कर रहे हैं, और नए हमलावर आज भी उसी ढांचे का इस्तेमाल करते हैं क्योंकि यह इतनी बार काम कर जाता है कि मेहनत वसूल हो जाती है।

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

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

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

वास्तव में सर्वर तक पहुंचने से पहले ट्रैफिक को क्या रोकता है

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

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

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

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

ऐसा प्रदाता चुनना जो वास्तव में अकाउंट रखना चाहता हो

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

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

व्यावहारिक जांच सीधी है और इसमें कुछ ही मिनट लगते हैं: साइन करने से पहले प्रदाता की एक्सेप्टेबल यूज़ पॉलिसी या सेवा शर्तों में adult, pornographic, obscene और escort शब्दों को खोजना, बजाय यह मान लेने के कि कोई सिक्योरिटी वेंडर डिफ़ॉल्ट रूप से न्यूट्रल है सिर्फ इसलिए कि वह कोई पेमेंट प्रोसेसर या बैंक नहीं है। अगर पॉलिसी इस बारे में खामोश है, तो यह खामोशी भी कोई गारंटी नहीं है, सिर्फ एक ऐसी शर्त है जिसे अभी तक किसी ने टेस्ट नहीं किया। एक दूसरे प्रदाता को ज़हन में रखना, और एक ऐसा DNS सेटअप रखना जो एक दिन के बजाय एक घंटे में उस पर स्विच हो सके, यहां ठीक वैसी ही अहमियत रखता है जैसी सामान्य होस्टिंग में रखता है।

एक आउटेज खत्म होने के बाद वास्तव में उसकी कीमत क्या होती है

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

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

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

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