از ۸ تا ۱۱ اکتبر ۲۰۲۶، یاندکس سه مرکز داده را از دست داد: ساسوو و ولادیمیر به طور کامل متوقف شدند و کالوگا با کاهش کارایی کار کرد. Yandex Cloud به حالت اضطراری رفت و به طور مستقیم به مشتریان توصیه کرد که برنامه‌های بازیابی اضطراری خود را فعال کنند. جالب‌ترین اتفاق بعد از آن رخ داد. Cloudflare بررسی کرد که چه بر سر ربات‌هایی که در این ابر زندگی می‌کردند، آمده است و دید: آن‌ها ناپدید نشدند، بلکه در عرض یک روز به میزبان‌های دیگر منتقل شدند. و با همان اثر انگشت TLS JA4 قابل شناسایی باقی ماندند. برای همه کسانی که به پارسینگ و اتوماسیون مشغول هستند، این یک آزمایش نادر در دو زمینه است: چه باید کرد وقتی زیرساخت سقوط می‌کند و چرا تغییر IP و میزبان «شخصیت» ربات را تغییر نمی‌دهد.
چه اتفاقی برای یاندکس افتاد
به گزارش BleepingComputer، یاندکس از آسیب به سه مرکز داده به دلیل حملات پهپادها خبر داد. خود یاندکس مقصر را نام نبرد؛ رسانه‌ها به نقل از BBC این حملات را به اوکراین مرتبط می‌دانند. زمان‌بندی به این صورت است:
- ۸ اکتبر — ساسوو (استان ریازان): آتش‌سوزی، سایت به طور کامل متوقف شد؛
- ۹ اکتبر — کالوگا: کار با کاهش کارایی، نه توقف کامل؛
- ۱۱ اکتبر — ولادیمیر: به طور کامل متوقف شد.
در صفحه وضعیت Yandex Cloud، بخشی از خدمات (کنسول، API، IAM، پایگاه‌های داده، S3، Kubernetes) با مشکلات عملکردی در دسترس بود، Compute و AI Studio به طور جزئی کار می‌کردند. شرکت اعلام کرد که نمی‌تواند زمان‌های قابل اعتماد برای بازیابی را مشخص کند، باقی‌مانده پیکربندی منابع را ناپایدار می‌داند و به مشتریان توصیه می‌کند از برنامه‌های جایگزین بازیابی اضطراری استفاده کنند. در زمان انتشار BleepingComputer (۱۲ اکتبر) زمان‌های بازیابی و وضوح در مورد احتمال از دست دادن داده‌ها وجود نداشت.
چه چیزی Cloudflare دید: ترافیک کاهش یافت، ربات‌ها نه
در ۱۴ اکتبر Cloudflare تجزیه و تحلیل حادثه را از جانب شبکه خود منتشر کرد. اعداد کلیدی:
- در ۱۱ اکتبر، ترافیک از شبکه جستجوی یاندکس (AS13238) به میزان ۹۹٪ از حد نرمال کاهش یافت و از Yandex.Cloud (AS200350) به میزان ۹۰٪؛
- ۹۹.۵٪ از درخواست‌ها از AS13238 و قبل از حادثه خودکار بودند، به طوری که ۹۳.۶٪ از درخواست‌های رباتی، خزنده‌های تأیید شده یاندکس بودند. این شبکه حدود ۷٪ از تمام درخواست‌های رباتی از IPهای روسی را تأمین می‌کرد؛
- در Yandex.Cloud حدود ۹۵٪ از درخواست‌های ارزیابی شده ربات‌ها بودند و هیچ‌یک از آن‌ها تأیید شده نبودند. این حدود ۲٪ از ترافیک رباتی روسیه است؛
- ترافیک رباتی از Yandex.Cloud تقریباً ۴۰٪ کاهش یافت و اسکن پلاگین‌های وردپرس از این شبکه ۹۰٪ کاهش یافت.
و بعد مهم‌ترین نکته. تقریباً تمام درخواست‌های رباتی از Yandex.Cloud به یک حساب کاربری مشتری Cloudflare در حوزه قمار هدایت شده بودند. بلافاصله پس از خرابی ۸ اکتبر، درخواست‌ها از Yandex.Cloud به آن حساب به صفر رسید — و بلافاصله درخواست‌های مشابهی از شبکه‌های دیگر میزبان‌های روسی، Radist و Selectel ظاهر شدند. با همان اثر انگشت JA4 TLS، با همان مسیرها و هدرهای نادر و با همان رشته‌های غیرمعمول User-Agent. نتیجه در یک هفته: ترافیک رباتی روسی به حساب‌های قمار کاهش نیافت، بلکه افزایش یافت — از ۱۶۷.۷ به ۱۷۰.۱ میلیون درخواست (+۱.۴٪).
نتیجه‌گیری Cloudflare به شدت بیان شده است: زیرساخت فیزیکی ایستا است و اتوماسیون مخرب به گونه‌ای طراحی شده است که منتقل شود. کاهش حجم ترافیک HTTP نشان‌دهنده حادثه است، اما به این معنا نیست که ربات‌ها متوقف شده‌اند.
نسخه جنجالی و داده‌ها: چرا «ربات‌ها خاموش شدند» اغراق‌آمیز بود
به طور همزمان، مرکز اوکراینی مقابله با اطلاعات نادرست (CPD) اعلام کرد که پس از حمله به ساسوو، تعداد پیام‌های حساب‌های مشکوک در فیسبوک و تلگرام در یک روز ۸۳.۶٪ کاهش یافته است — از ۴۰۳۲ به ۶۶۰. اما، همان‌طور که TechRadar بررسی کرد، در ۱۰ اکتبر فعالیت به ۴۵۸۵ پیام بازگشت و در ۱۱ اکتبر از سطح قبل از حمله فراتر رفت. Cloudflare تغییر قابل توجهی نیافت: ترافیک رباتی از IPهای روسی به نقاط پایانی «پست، پاسخ، لایک» یک شبکه اجتماعی تنها ۵.۷٪ کاهش یافت. Graphika نیز کاهش حساب‌های فعال در جوامع تحت نظارت را مشاهده نکرد. پژوهشگر رنه دی‌ریستا در Lawfare این داستان را زیبا توصیف کرد، اما بیشتر شبیه یک افسانه بود تا یک واقعیت.
درس جداگانه‌ای برای تحلیلگران: در ۸ اکتبر، در سراسر روسیه بانک‌ها، خرده‌فروشی‌ها، اپراتورها و رسانه‌ها دچار اختلال شدند، بنابراین هرگونه کاهش «فعالیت» در آن روز نمی‌تواند بدون قید و شرط به ربات‌ها نسبت داده شود. ترافیک تجمیعی به راحتی می‌تواند گمراه‌کننده باشد.
درس اول: IP و میزبان — شخصیت ربات نیست
Cloudflare ارتباط «Yandex.Cloud → Radist/Selectel» را نه از طریق آدرس‌ها — که به طور کامل تغییر کرده بودند — شناسایی کرد، بلکه از طریق رفتار و اثر انگشت مشتری:
- JA4 — هش TLS ClientHello: مجموعه‌ای از رمزنگاری‌ها، گسترش‌ها و نسخه‌های پروتکل. این برنامه را توصیف می‌کند، نه شبکه را. همان اسکریپت Python در سرور جدید همان JA4 را تولید می‌کند؛
- مسیرها و هدرهای نادر — ترتیب و مجموعه‌ای از هدرهای HTTP که در مرورگرهای معمولی یافت نمی‌شوند؛
- User-Agent اختصاصی — رشته‌ای منحصر به فرد که به خودی خود به عنوان برچسب عمل می‌کند.
نتیجه عملی برای پارسینگ قانونی: تغییر مرکز داده یا مجموعه IP شما را برای ضد ربات «جدید» نمی‌کند، اگر تمام استک مشتری همان باشد. و برعکس: اگر خزنده شما به طور صادقانه خود را معرفی کند، به آرامی رفتار کند و به نقاط حساس ضربه نزند، اثر انگشت پایدار مشکلی ایجاد نمی‌کند. مشکل زمانی پیش می‌آید که استک به گونه‌ای به نظر برسد که در کاربران واقعی وجود ندارد: Chrome اعلام شده با اثر انگشت TLS کتابخانه requests، UA عجیب و غریب، هدرهای غیرمعمول. در مورد اینکه این لایه شناسایی چگونه کار می‌کند، ما در تجزیه و تحلیل JA4 و TLS-fingerprinting در پارسینگ نوشتیم.
به یک جزئیات دیگر توجه کنید: ربات‌ها از یک مرکز داده به مراکز داده دیگر منتقل شدند. برای Cloudflare، این همچنان همان دسته ASN میزبان است که بسیاری از وب‌سایت‌ها از قبل به آن بی‌اعتماد هستند. شبکه متفاوت است — اما پروفایل ریسک همان است.
درس دوم: زیرساخت باید بتواند در عرض چند ساعت منتقل شود
مجرمان در عرض یک روز منتقل شدند، زیرا اتوماسیون آن‌ها از ابتدا قابل حمل بود. تیم‌های صادق که قیمت‌ها را جمع‌آوری می‌کنند، نتایج را نظارت می‌کنند یا تجزیه و تحلیل انجام می‌دهند، به این قابلیت حمل نیاز دارند. توصیه Yandex Cloud «از برنامه‌های جایگزین بازیابی اضطراری استفاده کنید» تنها زمانی خوب است که چنین برنامه‌ای از قبل وجود داشته باشد. حداقل چک‌لیست:
- کد و پیکربندی‌ها — خارج از ابر. مخزن، تصاویر کانتینر، متغیرهای محیطی باید به گونه‌ای ذخیره شوند که بتوان پارس‌کن را در یک میزبان دیگر با یک دستور راه‌اندازی کرد.
- میزبان دوم از قبل. حساب، پرداخت و سرور آزمایشی در یک ارائه‌دهنده جایگزین در حوزه قضایی و منطقه‌ای دیگر. ثبت‌نام و گذراندن تأیید در روز حادثه — دیر است.
- لایه خروجی جدا از محاسبات. اگر درخواست‌ها به وب‌سایت‌های هدف از طریق ارائه‌دهنده پروکسی می‌روند و نه به طور مستقیم از IP سرور، انتقال محاسبات هیچ‌یک از جغرافیا، نوع IP یا تاریخچه جلسات را تغییر نمی‌دهد. سرور می‌تواند منتقل شود، اما برای وب‌سایت شما همان مشتری باقی می‌مانید.
- داده‌ها و صف‌ها — با تکرار. نتایج پارسینگ و وضعیت وظایف باید در یک ذخیره‌سازی دیگر کپی شوند، در غیر این صورت پس از حادثه باید از نو شروع کنید.
- ارائه‌دهنده پشتیبان — واقعاً متفاوت. میزبانی پشتیبان یا ارائه‌دهنده پروکسی نباید همان زیرساخت با برند دیگری باشد. چگونه این را در پروکسی بررسی کنیم، ما در مطلبی درباره چرا ارائه‌دهنده پروکسی پشتیبان ممکن است همان مجموعه باشد بررسی کردیم.
- هشدار آموزشی. هر سه ماه یک بار پارس‌کن را در یک سایت پشتیبان راه‌اندازی کنید و یک وظیفه واقعی را اجرا کنید. برنامه‌ای که هرگز اجرا نشده باشد، معمولاً در عمل کار نمی‌کند.
چه نوع پروکسی چه مشکلی را در چنین وضعیتی حل می‌کند
پروکسی‌ها از اثر انگشت بد جلوگیری نمی‌کنند — این را می‌توان در مثال تجزیه و تحلیل Cloudflare مشاهده کرد. اما آن‌ها «چهره» درخواست‌های شما را از جایی که کد به طور فیزیکی اجرا می‌شود جدا می‌کنند:
- پروکسی‌های مسکونی — برای وب‌سایت‌هایی که ASNهای میزبان از قبل محدود شده‌اند یا CAPTCHA دریافت می‌کنند. هنگام انتقال سرور، خروجی همچنان بر روی IPهای خانگی کشور مورد نظر باقی می‌ماند.
- پروکسی‌های مراکز داده — برای API و وب‌سایت‌های وفادار، جایی که سرعت و قیمت مهم است. آن‌ها نیز باید در یک ارائه‌دهنده مستقل از ابر شما نگهداری شوند تا حادثه میزبان، IPهای خروجی را نیز با خود نبرد.
در عین حال، پروکسی تنها یک لایه است. اگر استک TLS، هدرها و رفتار مشتری شما متمایز باشد، آن‌ها در هر IP شناسایی می‌شوند، همان‌طور که ربات‌هایی را که به Radist و Selectel منتقل شدند، شناسایی کردند.
این چه معنی برای صاحبان وب‌سایت‌ها دارد
Cloudflare نتیجه معکوس را نیز می‌گیرد: ASN و حجم ترافیک — نشانه‌ای غیرقابل اعتماد از ربات است. مسدود کردن شبکه «بد» تا اولین انتقال کار می‌کند. بهتر است به رفتار نگاه کنید: اثر انگشت‌های JA4 مشترک در شبکه‌های مختلف، فراوانی غیرعادی درخواست‌ها و قوانین WAF در نقاط حساس بدون توجه به اینکه درخواست از کجا آمده است. طرف دیگر سکه نیز وجود دارد: ۴۰.۵٪ از مشتریان Cloudflare به خزنده یاندکس کد ۴۰۳ پاسخ دادند و ترافیک از شبکه‌های یاندکس به وب‌سایت‌های خبری در زمان حادثه ۴۴٪ کاهش یافت — یعنی در درجه اول ایندکس‌گذاری قانونی آسیب دید.
نتیجه‌گیری
حادثه یاندکس یک آزمایش زنده از دو حقیقت ساده بود. اول: زیرساخت می‌تواند در یک روز ناپدید شود و برنده کسی است که می‌تواند آن را در عرض چند ساعت منتقل کند — با کد خارج از ابر، میزبان دوم و لایه خروجی که به سرور وابسته نیست. دوم: برای ضد ربات، شما استک مشتری خود هستید، نه IP شما. مرکز داده جدید با همان JA4 و همان User-Agent — همان ربات در آدرس جدید است. پارسینگ را به گونه‌ای بسازید که بتواند تغییر سایت را تحمل کند و در عین حال در هر IP به طور یکسان مرتب به نظر برسد.