من 8 إلى 11 أكتوبر 2026، فقدت ياندكس ثلاثة مراكز بيانات: ساسوفو وفولغوغراد توقفت تمامًا، بينما كانت كالوجا تعمل بتدهور. انتقل Yandex Cloud إلى وضع الطوارئ ونصح العملاء مباشرة بتفعيل خطط التعافي من الكوارث الخاصة بهم. ما حدث بعد ذلك كان الأكثر إثارة للاهتمام. قامت Cloudflare بتحليل ما حدث للبوتات التي كانت تعيش في هذه السحابة، ورأت: إنها لم تختفِ، بل انتقلت إلى مضيفين آخرين خلال يوم واحد. وظلت معروفة بنفس بصمة TLS JA4. بالنسبة للجميع الذين يعملون في مجال التحليل والأتمتة، هذه تجربة نادرة تتعلق بسؤالين: ماذا تفعل عندما تنهار البنية التحتية، ولماذا لا يغير تغيير IP والمضيف "هوية" البوت.
ماذا حدث لياندكس
وفقًا لموقع BleepingComputer، أفادت ياندكس بتضرر ثلاثة مراكز بيانات نتيجة هجمات الطائرات بدون طيار. لم تحدد ياندكس الجاني؛ وسائل الإعلام، استنادًا إلى BBC، تربط الضربات بأوكرانيا. التسلسل الزمني هو كما يلي:
- 8 أكتوبر — ساسوفو (منطقة ريازان): حريق، توقفت المنصة تمامًا؛
- 9 أكتوبر — كالوجا: العمل بتدهور، وليس توقفًا كاملًا؛
- 11 أكتوبر — فولغوغراد: توقفت تمامًا.
على صفحة حالة Yandex Cloud، ظلت بعض الخدمات (الكونسول، API، IAM، قواعد البيانات، S3، Kubernetes) متاحة مع مشاكل في الأداء، بينما كانت Compute وAI Studio تعمل جزئيًا. كتبت الشركة أنها لا تستطيع تحديد مواعيد موثوقة لاستعادة الخدمة، وتعتبر التكوين المتبقي للموارد غير مستقر، وتوصي العملاء باستخدام خطط بديلة للتعافي من الكوارث. لم تكن هناك مواعيد لاستعادة الخدمة أو وضوح بشأن فقدان البيانات المحتمل في وقت نشر BleepingComputer (12 أكتوبر).
ما رأته Cloudflare: انخفضت حركة المرور، لكن البوتات لم تتوقف
في 14 أكتوبر، نشرت Cloudflare تحليلًا للحادث من جانب شبكتها. الأرقام الرئيسية:
- في 11 أكتوبر، انخفضت حركة المرور من شبكة ياندكس للبحث (AS13238) بنسبة 99% عن المعدل الطبيعي، ومن Yandex.Cloud (AS200350) بنسبة 90%;
- 99.5% من الطلبات من AS13238 قبل الحادث كانت تلقائية، حيث كانت 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: مجموعة من الشفرات، الامتدادات، إصدارات البروتوكول. يصف البرنامج، وليس الشبكة. نفس سكربت بايثون على خادم جديد يعطي نفس JA4؛
- المسارات والعناوين النادرة — ترتيب ومجموعة من عناوين HTTP التي لا توجد في المتصفحات العادية؛
- User-Agent الخاص — سلسلة فريدة تعمل كعلامة.
الاستنتاج العملي للتحليل القانوني: تغيير مركز البيانات أو مجموعة IP لا يجعلك "جديدًا" بالنسبة لمكافحة البوت، إذا كان كل شيء في مجموعة العميل يبقى كما هو. وعلى العكس: إذا كان زاحفك يقدم نفسه بصدق، ويتصرف بحذر ولا يضرب النقاط الحساسة، فإن البصمة الثابتة ليست مشكلة. تظهر المشكلة عندما تبدو المجموعة كشيء لا يوجد لدى المستخدمين الحقيقيين: Chrome المعلن مع بصمة TLS لمكتبة requests، UA غريب، عناوين غير قياسية. كتبنا بالتفصيل عن كيفية عمل هذه الطبقة من الكشف في تحليل JA4 وTLS Fingerprinting في التحليل.
لاحظ أيضًا تفصيلًا آخر: انتقلت البوتات من مركز بيانات إلى مراكز بيانات أخرى. بالنسبة لـ Cloudflare، لا تزال هذه نفس فئة ASN المضيفين، التي تثير عدم الثقة المسبق لدى العديد من المواقع. الشبكة مختلفة — لكن ملف المخاطر هو نفسه.
الدرس الثاني: يجب أن تكون قادرًا على نقل البنية التحتية خلال ساعات
انتقل المهاجمون خلال يوم واحد، لأن أتمتتهم كانت قابلة للنقل منذ البداية. تحتاج الفرق الشريفة التي تجمع الأسعار، وتراقب النتائج، أو تقوم بالتحليل، إلى هذه القابلية للنقل بنفس القدر. توصية Yandex Cloud "استخدموا خطط بديلة للتعافي من الكوارث" جيدة فقط عندما تكون هناك خطة بالفعل. الحد الأدنى من قائمة التحقق:
- الكود والتكوينات — خارج السحابة. يجب أن تكون المستودعات، صور الحاويات، المتغيرات البيئية موجودة بحيث يمكن نشر المحلل لدى مضيف آخر بأمر واحد.
- مضيف ثانٍ مسبقًا. حساب، دفع، وخادم اختبار لدى مزود بديل في ولاية قضائية ومنطقة مختلفة. التسجيل والمرور بالتحقق في يوم الحادث — متأخر.
- الطبقة الخارجية منفصلة عن الحسابات. إذا كانت الطلبات إلى المواقع المستهدفة تمر عبر مزود بروكسي، وليس مباشرة من IP الخادم، فإن نقل الحسابات لا يغير الجغرافيا، ولا نوع IP، ولا تاريخ الجلسات. يمكن نقل الخادم، لكن بالنسبة للموقع، تظل أنت نفس العميل.
- البيانات والطوابير — مع النسخ. يتم نسخ نتائج التحليل وحالة المهام إلى تخزين آخر، وإلا بعد الحادث سيتعين عليك البدء من جديد.
- مزود احتياطي — مختلف حقًا. يجب ألا يكون الاستضافة الاحتياطية أو مزود البروكسي هو نفس البنية التحتية تحت علامة تجارية مختلفة. كيف يتم التحقق من ذلك على البروكسي، ناقشنا في المادة حول لماذا قد يكون مزود البروكسي الاحتياطي هو نفس المجموعة.
- إنذار تدريبي. مرة واحدة في الربع، قم بتشغيل المحلل على منصة احتياطية ومرر مهمة حقيقية. الخطة التي لم يتم تشغيلها مرة واحدة عادةً لا تعمل في الممارسة العملية.
ما هو نوع البروكسي الذي يحل ماذا في مثل هذه الحالة
لا تنقذ البروكسي من بصمة سيئة — وهذا واضح من المثال في تحليل Cloudflare. لكنها تفصل "وجه" طلباتك عن المكان الذي يتم فيه تشغيل الكود فعليًا:
- بروكسي سكنية — للمواقع التي يتم فيها قطع ASN المضيفين مسبقًا أو تتلقى CAPTCHA. عند الانتقال بين الخوادم، يبقى الخروج على IP المنزلية للدولة المطلوبة.
- بروكسي مراكز البيانات — لواجهات برمجة التطبيقات والمواقع الموالية، حيث تكون السرعة والسعر مهمين. يجب الاحتفاظ بها أيضًا لدى مزود مستقل عن سحابتك، حتى لا تأخذ حادثة الاستضافة معها IP الخروج.
ومع ذلك، البروكسي هو مجرد طبقة واحدة. إذا كانت مجموعة TLS، والعناوين، وسلوك عميلك تبرز، فسيتم التعرف عليها على أي IP، كما تم التعرف على البوتات التي انتقلت إلى Radist وSelectel.
ماذا يعني هذا لمالكي المواقع
تستنتج Cloudflare أيضًا عكس ذلك: ASN وحجم الحركة — علامات غير موثوقة للبوت. تعمل حظر الشبكة "السيئة" حتى الانتقال الأول. من الأكثر موثوقية النظر إلى السلوك: بصمات JA4 المشتركة بين الشبكات، وتكرار الطلبات الشاذة، وقواعد WAF على النقاط الحساسة بغض النظر عن مصدر الطلب. هناك أيضًا جانب آخر: 40.5% من عملاء Cloudflare ردوا على زاحف ياندكس برمز 403، بينما انخفضت حركة المرور من شبكات ياندكس إلى المواقع الإخبارية خلال فترة الحادث بنسبة 44% — مما يعني أن الفهرسة الشرعية تأثرت أولاً.
الاستنتاج
أصبح حادث ياندكس اختبارًا حيًا لحقيقتين بسيطتين. الأولى: يمكن أن تختفي البنية التحتية في يوم واحد، ويفوز من يستطيع نقلها خلال ساعات، — مع الكود خارج السحابة، ومضيف ثانٍ، وطبقة خروج غير مرتبطة بالخادم. الثانية: بالنسبة لمكافحة البوت، أنت هو مجموعة العميل الخاصة بك، وليس IP الخاص بك. مركز بيانات جديد بنفس JA4 ونفس User-Agent — هو نفس البوت بعنوان جديد. قم ببناء التحليل بحيث يمكنه تحمل تغيير المنصة ويبدو بنفس القدر من الدقة على أي IP.