۵.۵ میلیون درخواست در دقیقه؛ شکستِ مسدودسازی IP در برابر بات‌نت‌های هوشمند

۵.۵ میلیون درخواست در دقیقه؛ این حجم از ترافیک، مقیاس حمله‌ای بود که در ژوئن ۲۰۲۶ زیرساخت‌های Read the Docs را هدف قرار داد. این سیل ترافیکی که نزدیک به ۱۰ روز ادامه داشت، ۱۰۰ برابر ترافیک عادی پلتفرم بود و تمام لایه‌های دفاعی، سیستم‌های لبه (Edge) و فرآیندهای پاسخ به حوادث را تا آخرین حد توانشان به چالش کشید. این حادثه ثابت کرد که دفاع‌های سنتی مبتنی بر IP دیگر برای متوقف کردن حملات پیچیده کافی نیستند.

برای سال‌ها، میزبان‌های مستندات فنی با تکیه بر محدودیت‌های ساده‌ای در نرخ درخواست‌ها (Rate Limits)، بات‌ها و اسکرایپرهای وب را تحمل می‌کردند تا آرامش سیستم حفظ شود. اما ظهور خزنده‌های هوش مصنوعی — شبیه به یک ارتش از کتابخانه‌داران سریع که هر ثانیه هزاران صفحه را می‌بلعند — بازی را تغییر داده است. طبق گزارش‌های فنی، از حدود دو سال پیش، Read the Docs شاهد افزایش چشمگیر فعالیت خزنده‌های هوش مصنوعی بود؛ روندی که در بسیاری از جوامع زیرساخت‌های توسعه‌دهندگان (Dev Infrastructure) مشاهده شده است. اکنون اتصال یک اسکرایپر تولیدشده توسط هوش مصنوعی به یک شبکه پروکسی جهانی بسیار ساده است و این موضوع حملات را بزرگ‌تر و توزیع‌شده‌تر از هر زمان دیگری کرده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن و زیرساخت‌های آن‌ها اشاره کردیم، توزیع‌شدگی ترافیک، بزرگ‌ترین کابوس تیم‌های عملیاتی است. به نقل از پست‌مورتوم مفصل منتشرشده در about.readthedocs.com، حمله ژوئن ۲۰۲۶ از نظر مقیاس و قدرت تطبیق‌پذیری با تمام سیل‌های ترافیکی قبلی متفاوت بود. این حمله بیش از ۱۰ برابر بزرگ‌تر از هر چیزی بود که تیم فنی پیش‌تر با آن مواجه شده بود. مهاجمان تنها ترافیک نمی‌فرستادند، بلکه فعالانه زیرساخت را برای یافتن نقاط ضعف کاوش (Probe) می‌کردند. این سرعت در شناسایی نقاط ضعف، یادآور گزارش‌های اخیر است که نشان می‌دهد زمان نفوذ به شبکه‌ها به دلیل استفاده از عوامل هوش مصنوعی به شدت کاهش یافته و حتی به ۱۰ ساعت رسیده است.

کالبدشکافی حمله

این حمله از چندین تاکتیک پیچیده برای دور زدن لایه‌های امنیتی استاندارد استفاده می‌کرد:

• حجم عظیم: در نقطه اوج، زیرساخت ۵.۵ میلیون درخواست در دقیقه دریافت می‌کرد. برای مقایسه، پیک ترافیک عادی روزانه معمولاً زیر ۱۰۰ هزار درخواست در دقیقه است.
• توزیع جهانی: درخواست‌ها از میلیون‌ها IP منحصربه‌فرد در صدها شماره سیستم خودمختار (ASN) مختلف در سراسر جهان ارسال می‌شد. این ترافیک شامل بلوک‌های IP خانگی و همچنین ارائه‌دهندگان میزبانی بزرگ و کوچک بود.
• تصادفی‌سازی اثرانگشت: مهاجمان برای دور زدن فیلترهای مبتنی بر امضای JA3/JA4، هدرهای HTTP و پارامترهای اتصال TLS را به‌طور سیستماتیک تصادفی می‌کردند.
• دور زدن حافظه پنهان: بات‌نت به‌طور خاص URLهایی را هدف قرار داد که باعث عدم یافتن داده در حافظه پنهان (Cache Miss) می‌شوند، مانند صفحاتی که وجود ندارند (۴۰۴) و تغییر مسیرهای موقت (۳۰۲).
• رفتار تطبیقی: هرگاه تیم فنی مسدودسازی‌های جدیدی را اعمال می‌کرد، بات‌نت نرخ درخواست‌ها را تنظیم کرده و مسیرهای هدف را تغییر می‌داد تا شکاف‌های جدید را پیدا کند.

حتی Cloudflare، شبکه توزیع محتوای (CDN) اصلی پلتفرم، نتوانست تمام ترافیک را متوقف کند. در حالی که حفاظت‌های خودکار، بات‌نت‌های شناخته‌شده را مسدود می‌کردند، بخش قابل توجهی از ترافیک از این لایه عبور کرده و به دیواره آتش اپلیکیشن (WAF) داخلی و قوانین محدودکننده نرخ نفوذ می‌کرد.

ابعاد و گستره اثرات

حملات DDoS کوچک‌تر یا اسکرایپرهای توزیع‌شده قبلی معمولاً متمرکز بودند. آن‌ها معمولاً از مجموعه‌ای کوچک از کشورها، بلوک‌های IP خاص یا اثرانگشت‌های مرورگر مشترک منشأ می‌گرفتند. اما حمله ژوئن ۲۰۲۶ واقعاً جهانی بود و از تمام کشورهای دنیا به‌طور هم‌زمان اجرا شد. این موضوع برای تیم عملیات یک کابوس بود، زیرا قوانین محدودیت نرخ در هر مرکز داده (Colo) کلاودفلر به‌طور مجزا اعمال می‌شوند.

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

در یک مرحله، مهاجمان روی تغییر مسیرها (Redirects) تمرکز کردند و یک دستور تغییر مسیر سخت‌افزاری در Nginx (یک دستور ساده rewrite regex) را فلج کردند. با وجود اینکه تغییر مسیرهای Nginx معمولاً هزاران درخواست در ثانیه را مدیریت می‌کنند، حجم ترافیک به قدری بالا بود که حتی در زیرساخت‌های مقیاس‌پذیر افقی (Horizontally Scaling)، منجر به حذف درخواست‌ها (Dropped Requests) شد.

الگوی «یو-یو»

مهاجمان از استراتژی خاصی به نام الگوی «یو-یو» استفاده کردند. آن‌ها ترافیک را تا رسیدن به آستانه دقیق محدودیت‌های نرخ بالا می‌بردند تا مرزهای دفاعی را شناسایی کنند و سپس درست پیش از مسدود شدن، حجم را کاهش می‌دادند تا پنجره‌های زمانی محدودیت نرخ منقضی شوند.

این نوسان برای به حداکثر رساندن هزینه مالی زیرساخت‌های مقیاس‌پذیری خودکار (Autoscaling) و ایجاد اختلالات متناوب برای کاربران واقعی طراحی شده بود. مهاجمان به‌وضوح درک کرده بودند که پلتفرم از یک WAF با محدودیت نرخ استفاده می‌کند و انفجارهای ترافیکی خود را برای ایجاد بیشترین آسیب با وجود این دفاع‌ها، زمان‌بندی کردند.

دفاع از زیرساخت

تیم فنی برای حفظ دسترسی کاربران قانونی، از حالت «Under Attack Mode» (که چالش‌های جاوااسکریپت را برای همه اجباری می‌کند) دوری کرد؛ زیرا می‌ترسیدند این کار باعث شکست تمام یکپارچگی‌های API شود و برای صدها هزار خواننده واقعی اصطکاک ایجاد کند. در عوض، آن‌ها بر استراتژی دفاع در عمق تمرکز کردند.

حافظه پنهان لبه (Edge Caching) اولین خط دفاع بود. تیم متوجه شد که مهاجمان می‌توانند درخواست‌های غیر-کش‌شده را از روی سرعت پاسخ تشخیص دهند. برای مقابله، آن‌ها شروع به کش کردن حتی صفحات ۴۰۴ و تغییر مسیرهای ۳۰۲ برای بازه‌های زمانی کوتاه کردند تا از رسیدن آن‌ها به سرورهای اصلی (Origin Servers) جلوگیری کنند.

در ابتدا، حمله تغییر مسیرهای موقت (۳۰۲) را هدف قرار داد که توسط بک‌اند پایتون سرویس داده می‌شدند و نه Nginx. این موضوع باعث قطعی کوتاهی شد که منجر به فعال شدن هشدار (Page) برای تیم عملیات شد. در عرض نیم ساعت، تیم این تغییر مسیرها را به لبه (Edge) در کلاودفلر منتقل کرد تا توسط CDN سرویس داده شوند. با این حال، مهاجمان برای یک هفته و نیم بعدی، به‌سادگی تاکتیک‌های خود را به میزبان‌ها و سرویس‌های مختلف تغییر دادند.

محدودیت نرخ هدفمند جایگزین مسدودسازی‌های کورکورانه IP شد. تیم به‌جای اینکه بپرسد درخواست «از کجا» می‌آید، روی اینکه درخواست «چه شکلی» است تمرکز کرد:

• ناهنجاری‌های TLS: استفاده از ابزارهایی برای شناسایی اتصالات TLS غیرعادی که با مرورگرهای استاندارد متفاوت بودند. کلاودفلر ابزارهای خاصی برای تشخیص بات‌ها در این سطح ارائه داد.
• جعبه جریمه (Penalty Box): اعمال محدودیت نرخ روی اثرانگشت‌های مرورگر یا ASNهایی که تعداد بیش از حدی خطای ۴۰۴ یا تغییر مسیر تولید می‌کردند. از آنجایی که پاسخ‌های ۲۰۰ همیشه کش می‌شوند و به‌ندرت مشکل ایجاد می‌کنند، «جعبه جریمه» درخواست‌های گران‌قیمت‌تر را هدف قرار داد.
• طبقه‌بندی ASN: اختصاص محدودیت‌های متفاوت برای ارائه‌دهندگان ابری بزرگ (AWS, Google Cloud, Azure) در مقابل IPهای خانگی. چون Read the Docs اجازه فعالیت بات‌ها را می‌دهد، ASNهای ابری به محدودیت‌های بالاتری نسبت به ارائه‌دهندگان کوچک میزبانی نیاز داشتند.
• ناهمخوانی پروتکل: تیم به دنبال ابزارهایی گشت که رشته‌های User-Agent مدرن را اعلام می‌کردند اما از HTTP/1.1 استفاده می‌کردند. با این حال، این روش در این حمله خاص کاربردی نبود، زیرا تمام ترافیک از HTTP/2 و HTTP/3 استفاده می‌کرد.
• اثرانگشت کلاینت: نظارت بر اثرانگشت‌های JA4 (مانند کلاینت‌های HTTP در Golang یا ماژول requests پایتون). در این مورد، این روش کمتر مؤثر بود زیرا مهاجمان پارامترهای TLS خود را تصادفی می‌کردند.

نقش اتوماسیون

مدیریت دستی این قوانین پیچیده غیرممکن بود. تیم از Terraform برای مدیریت WAF و قوانین محدودیت نرخ به‌صورت کد (Infrastructure as Code) استفاده کرد. این کار به آن‌ها اجازه داد تا قوانین فیلترینگ را در هزاران نام دامنه و زیردامنه به‌سرعت بررسی، تست، نسخه‌بندی (Version-control) و منتشر کنند. این نیاز به اتوماسیون با واقعیت‌های جدید امنیت سایبری همسو است، چرا که دفاع‌های دستی در برابر حملات سریع AI دیگر غیرممکن شده و اتوماسیون می‌تواند هزینه‌های میلیونی ناشی از نفوذها را کاهش دهد.

در نهایت، تیم تصمیم گرفت یک «راه خروج» (Escape Hatch) فراهم کند. Read the Docs به‌ندرت IPها یا User-Agentهای خاص را به‌طور کامل مسدود می‌کند. در عوض، سخت‌ترین جریمه، یک چالش جاوااسکریپت بود. کاربر واقعی پس از حل چالش، معمولاً برای ۲۴ ساعت از بررسی‌های بعدی معاف می‌شد.

درس‌های آموخته‌شده و نتایج کلیدی

این حادثه نشان‌دهنده تغییری در چشم‌انداز تهدیدات است. حملات حجیم دیگر مختص غول‌های سازمانی نیستند و به واقعیت روزمره هر سرویس عمومی شناخته‌شده تبدیل شده‌اند. حمله ژوئن ۲۰۲۶ چندین نکته حیاتی را تایید کرد:

• مسدودسازی IP منسوخ شده است: بات‌نت‌ها و سرویس‌های پروکسی، مسدودسازی‌های ساده IP را بی‌فایده می‌کنند. دفاع باید بر محدودیت‌های گسترده‌تر در سطح ASN و نام دامنه متمرکز شود.
• کشینگ تهاجمی اجباری است: همه چیز — از جمله فایل‌های استاتیک، صفحات ۴۰۴ و تغییر مسیرهای موقت — باید کش شوند. حتی یک پنجره زمانی کوتاه از چند دقیقه، مانع از تبدیل شدن این منابع به بردارهای حمله می‌شود.
• محافظت از سطوح Cache-Miss: مهاجمان فعالانه به دنبال تغییر مسیرهای پویا، نقاط انتهایی جست‌وجو و صفحات ۴۰۴ هستند. اگر کشینگ امکان‌پذیر نیست، این موارد باید در لبه (Edge) مدیریت شوند.
• چالش‌های هدفمند بر ابزارهای کورکورانه برتری دارند: ترکیب اکتشافات مدیریت بات با محدودیت نرخ، حملات را با کمترین اثر بر کاربران واقعی کاهش می‌دهد.
• زیرساخت به‌مثابه کد (IaC) ضروری است: استفاده از Terraform استقرار سریع و ایمن قوانین پیچیده فیلترینگ را ممکن کرد.

اگرچه تیم عملیات اکنون دوباره شب‌های آرامی دارد، اما این را یک مهلت موقت می‌بیند. با ارزان‌تر شدن ابزارهای هوش مصنوعی و گسترش شبکه‌های پروکسی، این تهدید به یک واقعیت دائمی تبدیل شده است.

گام بعدی شما

• بررسی استراتژی کشینگ برای پاسخ‌های خطا (۴۰۴) و تغییر مسیرها در زیرساخت خود برای کاهش فشار روی سرور اصلی.
• انتقال مدیریت قوانین WAF از پنل‌های گرافیکی به ابزارهای IaC مانند Terraform برای واکنش سریع‌تر در زمان حمله.
• جایگزینی مسدودسازی‌های سخت IP با سیستم‌های امتیازدهی بر اساس ASN و اثرانگشت TLS.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و توان پردازشی آن‌ها در مقابله با ترافیک‌های حجیم مراجعه کنید.