8 से 11 अक्टूबर 2026 के बीच, यांडेक्स ने तीन डेटा सेंटर खो दिए: सासोवो और व्लादिमीर पूरी तरह से बंद हो गए, जबकि कालुगा में प्रदर्शन में गिरावट आई। Yandex Cloud आपातकालीन मोड में चला गया और सीधे ग्राहकों को अपने आपातकालीन पुनर्प्राप्ति योजनाओं को सक्रिय करने की सलाह दी। सबसे दिलचस्प बात यह हुई कि बाद में Cloudflare ने देखा कि उन बॉट्स का क्या हुआ, जो इस क्लाउड में रहते थे, और पाया: वे गायब नहीं हुए, बल्कि एक दिन में अन्य होस्टर्स पर चले गए। और वे उसी TLS फ़िंगरप्रिंट JA4 के माध्यम से पहचानने योग्य बने रहे। सभी के लिए, जो पार्सिंग और स्वचालन में लगे हुए हैं, यह दो सवालों पर एक दुर्लभ वास्तविक प्रयोग है: जब अवसंरचना गिरती है तो क्या करना चाहिए, और क्यों IP और होस्टिंग बदलने से बॉट की "पहचान" नहीं बदलती।
यांडेक्स के साथ क्या हुआ
BleepingComputer के अनुसार, यांडेक्स ने तीन डेटा सेंटरों को ड्रोन हमलों से क्षति की सूचना दी। यांडेक्स ने दोषी का नाम नहीं लिया; मीडिया बीबीसी के हवाले से हमलों को यूक्रेन से जोड़ता है। समयरेखा इस प्रकार है:
- 8 अक्टूबर — सासोवो (रियाज़ान क्षेत्र): आग, स्थल पूरी तरह से बंद;
- 9 अक्टूबर — कालुगा: प्रदर्शन में गिरावट, पूरी तरह से बंद नहीं;
- 11 अक्टूबर — व्लादिमीर: पूरी तरह से बंद।
Yandex Cloud की स्थिति पृष्ठ पर कुछ सेवाएँ (कंसोल, API, IAM, डेटाबेस, S3, Kubernetes) प्रदर्शन समस्याओं के साथ उपलब्ध थीं, Compute और AI Studio आंशिक रूप से काम कर रहे थे। कंपनी ने लिखा कि वह विश्वसनीय पुनर्प्राप्ति समय सीमा नहीं बता सकती, शेष संसाधनों की कॉन्फ़िगरेशन को अस्थिर मानती है और ग्राहकों को वैकल्पिक आपातकालीन पुनर्प्राप्ति योजनाओं का उपयोग करने की सिफारिश करती है। BleepingComputer के प्रकाशन के समय (12 अक्टूबर) पुनर्प्राप्ति समय सीमा और संभावित डेटा हानि के बारे में स्पष्टता नहीं थी।
Cloudflare ने क्या देखा: ट्रैफ़िक गिरा, बॉट्स नहीं
14 अक्टूबर को Cloudflare ने अपनी नेटवर्क के दृष्टिकोण से दुर्घटना का विश्लेषण प्रकाशित किया। मुख्य आंकड़े:
- 11 अक्टूबर को यांडेक्स सर्च नेटवर्क (AS13238) का ट्रैफ़िक सामान्य से 99% गिर गया, Yandex.Cloud (AS200350) का 90%;
- AS13238 से 99.5% अनुरोध और दुर्घटना से पहले स्वचालित थे, जिसमें से 93.6% बॉट अनुरोध यांडेक्स के सत्यापित क्रॉलर थे। यह नेटवर्क सभी बॉट अनुरोधों का लगभग 7% रूस के IP से प्रदान करता था;
- Yandex.Cloud में लगभग 95% अनुमानित अनुरोध बॉट्स थे, और इनमें से कोई भी सत्यापित नहीं था। यह रूस के बॉट ट्रैफ़िक का लगभग 2% है;
- Yandex.Cloud से बॉट ट्रैफ़िक लगभग 40% गिर गया, इस नेटवर्क से WordPress प्लगइन्स का स्कैनिंग 90% गिर गया।
और फिर मुख्य बात। Yandex.Cloud से लगभग सभी बॉट अनुरोध एक ग्राहक के Cloudflare खाते की ओर लक्षित थे जो जुआ क्षेत्र में था। 8 अक्टूबर को विफलता के तुरंत बाद, Yandex.Cloud से उसके लिए अनुरोध शून्य हो गए — और तुरंत अन्य रूसी होस्टर्स के नेटवर्क से समान अनुरोध आए, Radist और Selectel। उसी JA4 फ़िंगरप्रिंट TLS के साथ, समान दुर्लभ पथ और हेडर और समान गैर-मानक User-Agent स्ट्रिंग्स के साथ। एक सप्ताह का परिणाम: रूसी बॉट ट्रैफ़िक जुआ खातों के लिए नहीं गिरा, बल्कि बढ़ा — 167.7 से 170.1 मिलियन अनुरोध (+1.4%)।
Cloudflare का निष्कर्ष कठोर है: भौतिक अवसंरचना स्थिर है, और हानिकारक स्वचालन इस तरह से निर्मित है कि यह स्थानांतरित हो सके। HTTP ट्रैफ़िक की मात्रा में गिरावट दुर्घटना को दर्शाती है, लेकिन इसका मतलब यह नहीं है कि बॉट्स रुक गए हैं।
गूंजती हुई संस्करण और डेटा: क्यों "बॉट्स चुप हो गए" का दावा बढ़ा-चढ़ा कर किया गया
साथ ही, यूक्रेनी सूचना विरोध केंद्र (ЦПД) ने कहा कि सासोवो पर हमले के बाद फेसबुक और टेलीग्राम में संदिग्ध खातों की संख्या एक दिन में 83.6% गिर गई — 4,032 से 660 तक। लेकिन, जैसा कि TechRadar ने विश्लेषण किया, 10 अक्टूबर को गतिविधि 4,585 संदेशों पर लौट आई, और 11 अक्टूबर को हमले से पहले के स्तर को पार कर गई। Cloudflare ने कोई महत्वपूर्ण बदलाव नहीं पाया: रूसी IP से "पोस्ट, उत्तर, लाइक" के एंडपॉइंट्स पर बॉट ट्रैफ़िक केवल 5.7% गिरा। Graphika ने भी ट्रैक किए गए समुदायों में सक्रिय खातों की हानि नहीं देखी। शोधकर्ता रене डिरेस्टा ने Lawfare में इस कहानी को सुंदर बताया, लेकिन यह तथ्य से अधिक कल्पना की तरह लगती है।
विश्लेषकों के लिए एक अलग पाठ: 8 अक्टूबर को पूरे रूस में बैंकों, रिटेल, ऑपरेटरों और मीडिया में विफलता हुई, इसलिए उस दिन "गतिविधि" में कोई भी गिरावट बॉट्स पर बिना शर्त नहीं डाली जा सकती। समग्र ट्रैफ़िक आसानी से भ्रमित कर सकता है।
पहला पाठ: IP और होस्टिंग — बॉट की पहचान नहीं
Cloudflare ने "Yandex.Cloud → Radist/Selectel" संबंध को पते के आधार पर नहीं पहचाना — पते और ASN पूरी तरह से बदल गए। इसे व्यवहार और क्लाइंट फ़िंगरप्रिंट के आधार पर पहचाना:
- JA4 — TLS ClientHello का हैश: एन्क्रिप्शन सेट, एक्सटेंशन, प्रोटोकॉल के संस्करण। यह प्रोग्राम का वर्णन करता है, न कि नेटवर्क का। वही Python स्क्रिप्ट नए सर्वर पर वही JA4 देती है;
- दुर्लभ पथ और हेडर — HTTP हेडर का क्रम और सेट, जो सामान्य ब्राउज़रों में नहीं मिलते;
- स्वयं का User-Agent — एक अद्वितीय स्ट्रिंग, जो अपने आप में एक लेबल के रूप में कार्य करती है।
कानूनी पार्सिंग के लिए व्यावहारिक निष्कर्ष: डेटा सेंटर या IP पूल बदलने से आप एंटी-बॉट के लिए "नए" नहीं बनते, यदि पूरा क्लाइंट स्टैक वही रहता है। और इसके विपरीत: यदि आपका क्रॉलर ईमानदारी से प्रस्तुत होता है, सावधानी से व्यवहार करता है और संवेदनशील एंडपॉइंट्स पर नहीं मारता है, तो स्थिर फ़िंगरप्रिंट कोई समस्या नहीं है। समस्या तब होती है जब स्टैक ऐसा दिखता है जैसे यह वास्तविक उपयोगकर्ताओं के पास नहीं होता: घोषित Chrome TLS फ़िंगरप्रिंट के साथ, विदेशी UA, गैर-मानक हेडर। इस परत के डिटेक्शन के बारे में हमने JA4 और TLS फ़िंगरप्रिंटिंग पर स्क्रैपिंग में लिखा है।
एक और विवरण पर ध्यान दें: बॉट्स एक डेटा सेंटर से अन्य डेटा सेंटर में चले गए। Cloudflare के लिए, यह सभी वही होस्टिंग ASN की श्रेणी है, जिन पर कई साइटों को पहले से ही उच्च अविश्वास है। नेटवर्क अलग है — जोखिम का प्रोफ़ाइल वही है।
दूसरा पाठ: अवसंरचना को घंटों में स्थानांतरित करना सीखना चाहिए
दुश्मनों ने एक दिन में स्थानांतरित किया, क्योंकि उनका स्वचालन मूल रूप से पोर्टेबल था। ईमानदार टीमों के लिए, जो कीमतें इकट्ठा करती हैं, परिणामों की निगरानी करती हैं या विश्लेषण करती हैं, ऐसी पोर्टेबिलिटी की आवश्यकता कम नहीं है। Yandex Cloud की सिफारिश "वैकल्पिक आपातकालीन पुनर्प्राप्ति योजनाओं का उपयोग करें" केवल तभी अच्छी है जब ऐसा योजना पहले से मौजूद हो। न्यूनतम चेकलिस्ट:
- कोड और कॉन्फ़िग्स — क्लाउड से बाहर। रिपॉजिटरी, कंटेनर इमेज, पर्यावरण चर को इस तरह से रखा जाना चाहिए कि किसी अन्य होस्टर पर पार्सर को एक ही कमांड से तैनात किया जा सके।
- दूसरा होस्टर पहले से। एकाउंट, भुगतान और एक परीक्षण सर्वर वैकल्पिक प्रदाता के साथ एक अलग न्याय क्षेत्र और क्षेत्र में। दुर्घटना के दिन पंजीकरण और सत्यापन करना — देर हो चुकी है।
- आउटपुट लेयर को गणनाओं से अलग। यदि लक्षित साइटों के लिए अनुरोध प्रॉक्सी प्रदाता के माध्यम से जाते हैं, न कि सीधे सर्वर के IP से, तो गणनाओं का स्थानांतरण न तो भूगोल बदलता है, न IP का प्रकार, न सत्रों का इतिहास। सर्वर को स्थानांतरित किया जा सकता है, लेकिन साइट के लिए आप वही ग्राहक बने रहते हैं।
- डेटा और कतारें — प्रतिकृति के साथ। पार्सिंग के परिणाम और कार्यों की स्थिति को अन्य संग्रहण में कॉपी किया जाता है, अन्यथा दुर्घटना के बाद फिर से शुरू करना पड़ेगा।
- बैकअप प्रदाता — वास्तव में अलग। बैकअप होस्टिंग या प्रॉक्सी प्रदाता को उसी अवसंरचना के तहत नहीं होना चाहिए, जो दूसरे ब्रांड के तहत है। प्रॉक्सी पर इसे कैसे जांचें, हमने क्यों बैकअप प्रॉक्सी प्रदाता वही पूल हो सकता है में चर्चा की।
- शिक्षण अलार्म। हर तिमाही में बैकअप साइट पर पार्सर को उठाएं और वास्तविक कार्य चलाएं। योजना, जिसे कभी नहीं चलाया गया, आमतौर पर व्यावहारिक रूप से काम नहीं करती।
इस स्थिति में किस प्रकार का प्रॉक्सी क्या हल करता है
प्रॉक्सी खराब फ़िंगरप्रिंट से नहीं बचाते — यह Cloudflare के विश्लेषण के उदाहरण से स्पष्ट है। लेकिन वे आपके अनुरोधों के "चेहरे" को उस स्थान से अलग करते हैं, जहां कोड भौतिक रूप से चलता है:
- रहवासी प्रॉक्सी — उन साइटों के लिए, जहां होस्टिंग ASN पहले से ही काटे जाते हैं या कैप्चा प्राप्त करते हैं। जब सर्वर को स्थानांतरित किया जाता है, तो आउटपुट आवश्यक देश के घरेलू IP पर रहता है।
- डेटा सेंटर प्रॉक्सी — API और वफादार साइटों के लिए, जहां गति और कीमत महत्वपूर्ण हैं। इन्हें भी आपके क्लाउड से स्वतंत्र प्रदाता के पास रखना चाहिए, ताकि होस्टिंग की दुर्घटना आउटगोइंग IP को अपने साथ न ले जाए।
इस बीच, प्रॉक्सी केवल एक परत हैं। यदि TLS स्टैक, हेडर और आपके क्लाइंट का व्यवहार अलग हैं, तो उन्हें किसी भी IP पर पहचाना जाएगा, जैसे कि बॉट्स को Radist और Selectel पर चले गए।
यह साइट के मालिकों के लिए क्या मतलब है
Cloudflare एक विपरीत निष्कर्ष भी निकालता है: ASN और ट्रैफ़िक की मात्रा — बॉट का एक असुरक्षित संकेत। "खराब" नेटवर्क को ब्लॉक करना पहले स्थानांतरण तक काम करता है। व्यवहार पर ध्यान देना अधिक विश्वसनीय है: विभिन्न नेटवर्क में सामान्य JA4 फ़िंगरप्रिंट, अनुरोधों की असामान्य आवृत्ति और संवेदनशील एंडपॉइंट्स पर WAF नियम, चाहे अनुरोध कहाँ से आया हो। दूसरी ओर, 40.5% Cloudflare ग्राहकों ने यांडेक्स क्रॉलर को 403 कोड के साथ जवाब दिया, और यांडेक्स से समाचार साइटों के लिए ट्रैफ़िक दुर्घटना के समय 44% गिर गया — यानी पहले से ही वैध अनुक्रमण को सबसे अधिक नुकसान हुआ।
निष्कर्ष
यांडेक्स की दुर्घटना दो सरल सत्य की जीवित परीक्षा बन गई। पहला: अवसंरचना एक दिन में गायब हो सकती है, और जीतता है वह, जो इसे घंटों में स्थानांतरित करना जानता है — क्लाउड के बाहर कोड, दूसरे होस्टर और आउटगोइंग लेयर के साथ, जो सर्वर से बंधा नहीं है। दूसरा: एंटी-बॉट के लिए आप — आपका क्लाइंट स्टैक हैं, न कि आपका IP। नया डेटा सेंटर उसी JA4 और उसी User-Agent के साथ — वही बॉट है, नए पते पर। पार्सिंग को इस तरह से बनाएं कि यह साइट के परिवर्तन को सहन करे और किसी भी IP पर समान रूप से सावधानी से दिखे।