قطعی Yandex: داده ها نشان می دهد که به جای تاریک شدن، ربات های مخرب جابجا شده اند

پس از حملات گزارش شده به مراکز داده Yandex، ادعاهایی در اینترنت منتشر شد مبنی بر اینکه مزارع ربات و عملیات نفوذ روسیه آفلاین شده اند. نمودارهای ترافیک HTTP افت شدیدی را نشان می‌دهد و این گمانه‌زنی را تقویت می‌کند که آسیب زیرساختی این عوامل مخرب را متوقف کرده است. با این حال، معیارهای کل ترافیک می توانند به راحتی گمراه شوند. دو شماره سیستم مستقل (ASN) مرتبط با Yandex وجود دارد: AS13238 توسط موتور جستجوی Yandex استفاده می‌شود، در حالی که AS200350 خدمات ابری خود را اجرا می‌کند.

با استفاده از داده‌های رادار Cloudflare و مدیریت ربات، نحوه تأثیرگذاری بر این دو ASN را تجزیه و تحلیل کردیم - و در حالی که هر دو شاهد کاهش ترافیک بودند، تأثیرات متفاوتی را مشاهده کردند.

در حالی که ترافیک مخرب ممکن است از یک ارائه دهنده خاص سرچشمه بگیرد، لزوما به ما نمی گوید که چه کسی مسئول ترافیک است. درک اینکه چرا اعتصاب ها تأثیر پایدار کمی بر ترافیک مخرب داشته اند، به جای صرفا الگوهای ترافیک کلی، به تجزیه و تحلیل رفتار درخواست نیاز دارد.

بین 7 و 11 اکتبر، حملات پهپادهای اوکراینی به سه تأسیسات یاندکس در روسیه اصابت کرد و به تدریج مراکز داده و ظرفیت شبکه را به حالت آفلاین رساند. همانطور که در رادار Cloudflare مشاهده شد، این امر با فروپاشی تقریبا کامل شبکه Yandex در 11 اکتبر به اوج خود رسید، زمانی که ترافیک به 99٪ زیر سطح پایه برای Yandex Search (AS13238) و 90٪ برای Yandex.Cloud (AS200350) کاهش یافت. علیرغم بهبود نسبی مختصر، هر دو شبکه تا 13 اکتبر مختل باقی ماندند و در 86 تا 90 درصد پایین‌تر از خطوط پایه عادی قرار گرفتند. (از 14 اکتبر ساعت 18:00 UTC، ترافیک 85٪ از حالت عادی است.)

کاهش در ترافیک کلی HTTP فقط قطع شدن شبکه را تایید می کند. نشان نمی دهد که آیا ربات های مخرب یا فراری مختل شده اند یا خیر. با نگاهی به خط پایه اتوماسیون قبل از رویداد، می‌توانیم ببینیم که قبل از حملات، درخواست‌های خودکار 36.1٪ از کل ترافیک HTTP مشاهده شده در سطح جهانی در سراسر شبکه Cloudflare و 35.8٪ از ترافیک را از آدرس‌های IP روسیه تشکیل می‌دادند.

این قطعی اثرات متفاوتی بر فعالیت خودکار روی دو ASN آسیب‌دیده داشت زیرا نقش‌های متفاوتی داشتند.

Yandex Search ASN (AS13238) برای خزیدن فهرست جستجو استفاده می شود. Cloudflare 99.5٪ از درخواست های خود را به صورت خودکار و 93.6٪ از درخواست های ربات خود را به عنوان تأیید شده طبقه بندی کرد. تجزیه و تحلیل ما نشان داد که ترافیک این ASN صفحات، صفحات رندر شده و تصاویر رندر شده را نمایه می کند، که رفتاری سازگار برای خزنده جستجو است. Yandex Search ASN حدود 7 درصد از درخواست‌های ربات منشأ روسیه و فقط 0.05 درصد از کل درخواست‌های جهانی را ارائه کرد.

Yandex.Cloud ASN (AS200350) یک شبکه میزبانی ابری است و ترکیب بسیار متفاوتی از اتوماسیون را حمل می کند. تقریبا 95.0٪ از درخواست های امتیازدهی شده آن ربات بودند، اما هیچ یک از درخواست های ربات مشاهده شده توسط Cloudflare تأیید نشد. ربات‌های Yandex.Cloud بیشتر شبیه برنامه‌های نرم‌افزاری به نظر می‌رسند: تقریبا دو سوم درخواست‌های آن‌ها داده‌ها را به وب‌سایت‌ها ارسال می‌کردند، برخی خود را به عنوان برنامه‌های جاوا اسکریپت، پایتون یا Go معرفی می‌کردند و سهم بیشتری نسبت به ربات‌های جستجوی Yandex به شرکت‌های نرم‌افزاری تعلق گرفت. Yandex.Cloud ASN حدود 2 درصد از درخواست‌های ربات منشأ روسیه و تنها 0.01 درصد از کل درخواست‌های جهانی را ارائه کرد.

«ترافیک ربات» به درخواست‌های خودکار به وب‌سایت‌های موجود در شبکه Cloudflare، مانند خزنده‌ها و اسکریپت‌ها اشاره دارد، نه لزوما فعالیت در پلتفرم‌های رسانه‌های اجتماعی. با از دست دادن ظرفیت شبکه های Yandex، درخواست های ربات آنها نیز کاهش یافت. انتظار می رفت: تقریبا تمام ترافیک Yandex Search و Yandex.Cloud خودکار بود. در حالی که شاهد کاهش آشکار در کل ترافیک بودیم، هیچ مدرکی مبنی بر ارتباط اختلال جهانی در ترافیک مخرب و کاهش ترافیک از Yandex مشاهده نکردیم.

درخواست‌های ربات منشأ روسیه تقریبا به نسبت ترافیک Yandex که آفلاین بود کاهش یافت، زیرا اکثر درخواست‌های آن شبکه‌ها خودکار بودند.

درخواست‌های ربات جهانی (% از تمام درخواست‌های HTTP)*

درخواست‌های ربات منشاء روسیه (% درخواست‌های HTTP با منشاء روسیه)

* رادار ترافیک جهانی را بر اساس کل درخواست های HTTP و درخواست های HTML (تقریبی از یک نمای صفحه) گزارش می دهد. جدول بالا حجم کل درخواست را نشان می دهد.

کاهش در Yandex Search ASN تقریبا به طور کامل خزیدن جستجو بود. درخواست‌های نمونه نشان داد که 78.1 درصد متعلق به YandexBot تأیید شده، 11.5 درصد به YandexRenderResourcesBot و 1.9 درصد متعلق به YandexImages است.

در میان وب‌سایت‌ها و خدمات، بخش صنعتی که بیشترین افت را داشت، انتشارات و روزنامه‌ها بودند که ترافیک شبکه‌های Yandex 44 درصد کاهش یافت. تقریبا 90 درصد از ترافیک قبل از رویداد به سایت‌های خبری از این ASN، مقالات نمایه‌سازی YandexBot بود، با 40.5 درصد از مشتریان Cloudflare، پاسخ‌های HTTP 403 Forbidden را به دلیل مسدود کردن خزنده توسط مالک سایت، برمی‌گرداندند. هنگامی که Yandex Search ASN آفلاین شد، مشتریان به سادگی نمایه سازی کمتری از Yandex مشاهده کردند.

Yandex.Cloud نمایه کاملا متفاوتی را نشان داد. به دنبال اعتصابات گزارش شده، ترافیک ربات از Yandex.Cloud حدود 40٪ کاهش یافت. چندین دسته حمله مانند کاهش شدیدی را نشان دادند. به عنوان مثال، بررسی پلاگین وردپرس 90٪ کاهش یافت و درخواست های شناسایی شده توسط اسکنر 93٪ کاهش یافت. جالب توجه است (و گویا)، بلوک های مشتریان Cloudflare در ترافیک Yandex.Cloud نیز در طول دوره رویداد 70 درصد کاهش یافت، که نشان می دهد ترافیک مخرب کمتری حتی به Cloudflare WAF از این ASN وارد شده است.

ترافیک ربات Yandex.Cloud هنگامی که بر اساس صنایع مقصد اصلی درخواست تقسیم می شود نیز جالب است:

4xx (خطای مشتری) اشتراک وضعیت پاسخ HTTP: قبل از → رویداد

اکثر ترافیک از Yandex.Cloud ASN به دو سطل صنعتی تقسیم می شود: نرم افزار رایانه و قمار. سطل نرم افزار کامپیوتری برای یک ASN که قرار بود میزبان برنامه های شخص ثالث و ادغام نرم افزار باشد قابل پیش بینی بود. در واقع، ما حتی دیدیم که api.cloudflare.com یک نام میزبان برتر برای ترافیک درخواست Yandex.Cloud است. اکثریت کلی این ترافیک هم قبل و هم در حین رویداد موفقیت آمیز بود (درخواست‌ها 200 ثانیه برگردانده شدند) که به استفاده قانونی اشاره دارد.

بخش قمار واضح‌ترین شواهد را ارائه می‌دهد که نشان می‌دهد اتوماسیون مخرب به جای ناپدید شدن، جابه‌جا شده است. تقریبا تمام درخواست‌های ربات Yandex.Cloud یک حساب مشتری قمار را هدف قرار داده بود و ترافیک بین نام‌های میزبان آن جابه‌جا می‌شد. بلافاصله پس از اختلال در 8 اکتبر، درخواست‌های ربات از Yandex.Cloud به این حساب به صفر رسید. به طور همزمان، درخواست‌های مشابهی از سایر میزبان‌های روسی ASN، از جمله Radist و Selectel ظاهر شد. ترافیک ورودی اثر انگشت یکسانی را در بین ارائه دهندگان حفظ کرد:

به طور کلی، ترافیک ربات روسی که حساب‌های قمار را هدف قرار می‌دهد، اساسا در طول هفته ثابت ماند و از 167.7 میلیون درخواست به 170.1 میلیون درخواست (+1.4٪) رسید. اتوماسیون هرگز متوقف نشد. هنگامی که Yandex.Cloud در دسترس نبود، اپراتورها به سادگی بارهای کاری خود را به ارائه دهندگان ابری جایگزین منتقل کردند.

در اکثر صنایع، سهم درخواست‌های ربات از Yandex.Cloud که هر پاسخ HTTP 4xx را برمی‌گرداند، کاهش یافت. این تا حد زیادی به دلیل کاهش در ترافیک حمله مانند ذکر شده در بالا است. این، در ترکیب با تجزیه و تحلیل مشتریان قمار، نشان می‌دهد که ترافیک مخربی که درخواست‌ها را از طریق Yandex.Cloud ارسال می‌کردند، به سادگی «سرویس‌های» خود را پس از اختلال در سرویس به سایر ارائه‌دهندگان منتقل کردند.

در نهایت، وقتی ترافیک رسانه‌های اجتماعی را تجزیه و تحلیل کردیم، هیچ تغییر غیرمنتظره‌ای در ترافیک چه از IP‌های روسی (0.6٪ کاهش در کل ترافیک در طول دوره رویداد) و چه در سطح جهانی (1.2٪ افزایش در کل ترافیک در طول دوره رویداد) پیدا نکردیم. ما تجزیه و تحلیل ترافیک ربات‌هایی را که به نقاط پایانی «پست»، «پاسخ» و «پسندیدن» برای یک پلتفرم رسانه اجتماعی خاص تکرار می‌کردند، تکرار کردیم و به‌طور مشابه تغییر غیرمنتظره‌ای قبل یا در طول دوره رویداد از IP‌های منشأ روسیه (5.7٪ کاهش در کل ترافیک در طول دوره رویداد) یا در سطح جهانی (1.1٪ افزایش در ترافیک کل در طول رویداد در هر رویداد) پیدا نکردیم.

ید). بر اساس ارزیابی ما، به نظر نمی‌رسد که داده‌ها از ادعاهایی مبنی بر اینکه اعتصابات دستکاری رسانه‌های اجتماعی را فلج کرده است، پشتیبانی نمی‌کند، اگرچه بدون تجزیه و تحلیل بیشتر با داده‌های خارج از Cloudflare، نمی‌توان قاطعانه گفت هیچ ارتباطی وجود ندارد.

هنگامی که ترافیک شبکه های Yandex از بین رفت، گمانه زنی ها در سراسر اینترنت پخش شد مبنی بر اینکه عملیات نفوذ روسیه و بات نت های مخرب ضربه فلج کننده ای را متحمل شده اند. داده‌های Cloudflare داستان متفاوتی را بیان می‌کند: در سراسر شبکه Cloudflare، هیچ مدرکی وجود نداشت که نشان دهد این حملات دستکاری رسانه‌های اجتماعی را آفلاین کرده است یا فعالیت‌های مخرب در اینترنت را مختل کرده است. در عوض، داده ها نشان دادند:

اختلال در شبکه به این معنی است که سرورهای خاص ارسال درخواست را متوقف کردند، اما به این معنی نیست که یک تهدید خودکار ناپدید شده است. بارهای کاری ابری قابل حمل هستند، بنابراین وقتی یک مرکز داده تاریک می شود یا یک پیشوند IP مسدود می شود، اپراتورها می توانند اسکریپت های خود را در عرض چند ساعت به ارائه دهنده دیگری منتقل کنند.

تحلیل ما در اینجا یادآوری است که حجم ترافیک ASN مشتری یک پروکسی غیرقابل اعتماد برای تفسیر رفتار ربات خودکار است. دفاع در برابر تهدیدات خودکار مستلزم بازرسی رفتار درخواست است، مانند شناسایی اثر انگشت مشترک JA4، نظارت بر نرخ درخواست غیرعادی، و اعمال قوانین WAF برای نقاط انتهایی حساس، صرف نظر از اینکه درخواست از کدام شبکه منشا گرفته است. زیرساخت فیزیکی ثابت است، اما اتوماسیون مخرب برای حرکت ساخته شده است.