AsiaTech logo

قطعی ۲۵ دقیقه‌ای Cloudflare ۲۸٪ وب را از کار انداخت

نوشته شده توسطحسین سلمانی | ۲۰ آذر ۱۴۰۴ | ۰۷:۰۶
Telegram IconX IconWhatsApp IconLinkedIn Icon
قطعی ۲۵ دقیقه‌ای Cloudflare ۲۸٪  وب را از کار انداخت

قطعی ۲۵ دقیقه‌ای Cloudflare ۲۸٪ وب را از کار انداخت

در تاریخ ۵ دسامبر ۲۰۲۵ (۱۵ آذر ۱۴۰۴)، اختلالی گسترده در شبکهٔ Cloudflare باعث شد بخش بزرگی از اینترنت برای حدود ۲۵ دقیقه عملاً از دسترس خارج شود. این حادثه از ساعت ۸:۴۷ تا ۹:۱۲ به وقت UTC رخ داد و طبق اعلام خود شرکت، حدود ۲۸ درصد از ترافیک HTTP که از زیرساخت Cloudflare عبور می‌کند تحت تأثیر قرار گرفت.
کاربران در سراسر دنیا هنگام تلاش برای ورود به سایت‌هایی مانند LinkedIn، Zoom، Canva، Coinbase، سرویس‌های بازی آنلاین و ده‌ها سرویس دیگر، با خطای «۵۰۰» یا صفحات خالی مواجه شدند.


علت حادثه: پیکربندی اشتباه در هنگام مقابله با یک حفرهٔ امنیتی

بر خلاف تصور اولیهٔ برخی کاربران، این اختلال نتیجهٔ یک حملهٔ سایبری نبود؛ بلکه ریشهٔ آن به یک تغییر پیکربندی اشتباه در فایروال وب Cloudflare (WAF) برمی‌گشت.
ماجرا از جایی شروع شد که یک آسیب‌پذیری بحرانی در React Server Components افشا شد. Cloudflare برای محافظت بهتر از مشتریانش در برابر سوءاستفاده از این باگ، تصمیم گرفت حجم بافر بدنهٔ درخواست‌ها (Request Body) در WAF را از ۱۲۸ کیلوبایت به ۱ مگابایت افزایش دهد تا بتواند درخواست‌های حجیم‌تر را هم اسکن کند.

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


باگ قدیمی در کد؛ ترکیبی که همه‌چیز را به هم ریخت

در بخشی از زیرساخت قدیمی Cloudflare که با نام FL1 شناخته می‌شود، کدی وجود داشت که سال‌ها بدون مشکل کار می‌کرد، اما ترکیب جدید تنظیمات آن را به باگی جدی تبدیل کرد.
در این مسیر قدیمی، اگر:

  • Managed Ruleset (مجموعهٔ قوانین مدیریت‌شدهٔ امنیتی Cloudflare) فعال بود و
  • آن ابزار تست داخلی از طریق یک killswitch (کلید خاموش‌کنندهٔ سراسری) غیرفعال می‌شد،

در بخشی از منطق WAF یک خطای زمان اجرا (Runtime Error) رخ می‌داد. کد انتظار داشت یک شیء execute همیشه وجود داشته باشد، اما بعد از غیرفعال شدن، این شیء مقدار nil (خالی) می‌گرفت و در نتیجه، WAF در لحظهٔ پردازش بعضی درخواست‌ها با خطا مواجه می‌شد.

نتیجه چه بود؟
پروکسی بجای پردازش عادی، برای آن دسته از درخواست‌هایی که به این مسیر می‌خوردند، به‌صورت خودکار پاسخ ۵۰۰ Internal Server Error برمی‌گرداند. این یعنی برای بسیاری از سایت‌هایی که در این شرایط خاص قرار داشتند، تمام درخواست‌های کاربران در آن بازهٔ زمانی با خطای ۵۰۰ پاسخ داده شد.


چه سرویس‌هایی و کدام مناطق تحت تأثیر بودند؟

به‌دلیل این‌که Cloudflare در نقش میان‌افزار اصلی بخش بزرگی از وب عمل می‌کند، از نگاه کاربران، این حادثه شبیه «خراب شدن نصف اینترنت» بود. سرویس‌های متعددی در گزارش‌ها نام برده شده‌اند که دچار مشکل شدند؛ از جمله:

  • سرویس‌های کسب‌وکار و تولید محتوا:
    LinkedIn، Zoom، Canva، GitLab و برخی پلتفرم‌های SaaS
  • خدمات مالی و رمز ارز:
    Coinbase و تعدادی سرویس مرتبط با فین‌تک و کریپتو
  • بازی و سرگرمی آنلاین:
    Fortnite، Valorant، League of Legends و سایر بازی‌های مبتنی بر زیرساخت Cloudflare
  • حتی سرویس‌های مانیتورینگ مانند Downdetector، که برای گزارش اختلالات استفاده می‌شوند، خودشان هم به‌خاطر اتکای زیرساختی به Cloudflare دچار مشکل شدند.

البته همهٔ مشتریان آسیب ندیدند. تنها سایت‌هایی تحت تأثیر قرار گرفتند که:

  1. ترافیک‌شان از مسیر قدیمی FL1 عبور می‌کرد و
  2. Managed Ruleset برای آن‌ها فعال بود و در ترکیب مشخصی تنظیم شده بود.

شبکهٔ Cloudflare در چین طبق گزارش‌ها از این اختلال مصون ماند.


این حمله سایبری نبود؛ اشتباه داخلی بود

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

همین موضوع باعث شده برخی تحلیل‌گران فناوری با لحن طنزآمیز بگویند:
«Cloudflare موقع تلاش برای نجات اینترنت از باگ React، ناگهان خودش ۲۸٪ اینترنت را خاموش کرد.»


حساسیت بیشتر به‌دلیل سابقه: دومین اختلال بزرگ در چند هفته

نکته‌ای که این حادثه را حساس‌تر کرد این بود که تنها چند هفته قبل از آن، در ۱۸ نوامبر ۲۰۲۵، Cloudflare یک اختلال بزرگ دیگر را تجربه کرده بود که در آن هم سرویس‌هایی مثل X (توییتر سابق)، برخی چت‌بات‌ها و خدمات ابری برای ساعت‌ها دچار مشکل شدند.
به همین دلیل، در واکنش به حادثهٔ پنجم دسامبر، مدیران ارشد Cloudflare صراحتاً اعلام کردند که «دوباره به اینترنت لطمه زده‌ایم» و بابت این موضوع از مشتریان و کاربران عذرخواهی کردند. این دو حادثهٔ پیاپی، بحث دربارهٔ ریسک تمرکز بخش زیادی از اینترنت روی چند ارائه‌دهندهٔ زیرساختی را دوباره داغ کرده است.


اقدامات اصلاحی Cloudflare برای جلوگیری از تکرار

Cloudflare در گزارش پس از حادثه (Post-mortem) مجموعه‌ای از تغییرات و تعهدات را برای افزایش پایداری اعلام کرده است، از جمله:

  • ایمن‌تر کردن فرایند اعمال پیکربندی‌ها
    قرار است تغییرات حساس، از جمله تنظیمات امنیتی و پاسخ به تهدیدات جدید، بیشتر شبیه انتشار نسخهٔ نرم‌افزار، به‌صورت مرحله‌ای و همراه با تست سلامت (Health Check) صورت بگیرد تا در صورت مشکل، بتوان سریعاً به نسخهٔ قبلی بازگشت.

  • بهبود حالت «شکستن شیشه» یا Break Glass
    Cloudflare می‌خواهد امکان بازگشت سریع و اضطراری از تنظیمات خطرناک را حتی در شرایطی که برخی سامانه‌های داخلی درست کار نمی‌کنند، تقویت کند.

  • انتقال برخی مسیرها به حالت Fail-Open به‌جای Fail-Closed
    در بعضی بخش‌ها، خطاهای داخلی باعث می‌شد سیستم به‌صورت «بسته» رفتار کند و تمام درخواست‌ها را با خطای ۵۰۰ رد کند. قرار است در بسیاری از این مسیرها، رفتار به‌سمت Fail-Open تغییر کند؛ یعنی در صورت بروز خطا، لاگ‌برداری انجام شود، اما ترافیک کاربران تا حد ممکن ادامه یابد.

  • محدود کردن موقت تغییرات شبکه‌ای
    تا زمانی که این safeguards جدید پیاده‌سازی و تست نشوند، Cloudflare اعلام کرده سطح دسترسی برای اعمال بعضی تغییرات حساس در شبکه را محدود کرده است.


این ماجرا برای صاحبان سایت‌ها چه پیامی دارد؟

برای اغلب مشتریان Cloudflare، این حادثه در حال حاضر نیازی به اقدام فوری خاصی ایجاد نمی‌کند؛ مشکل پیکربندی برطرف شده و سرویس‌ها به حالت عادی بازگشته‌اند.
با این حال، این رویداد یک هشدار جدی است برای هر کسب‌وکاری که کاملاً به یک ارائه‌دهندهٔ زیرساختی واحد متکی است:

  • اگر وب‌سایت یا اپلیکیشن شما عدم‌دسترس‌پذیری حتی چند دقیقه‌ای را هم تحمل نمی‌کند، شاید زمان آن رسیده که به استراتژی‌های چند-CDN، چند‌منطقه‌ای و مسیرهای جایگزین فکر کنید.
  • داشتن مانیتورینگ مستقل (Uptime Monitoring) و داشبوردهای جدا از ارائه‌دهندهٔ اصلی، کمک می‌کند سریع‌تر متوجه شوید مشکل دقیقاً از کجاست و چگونه باید به کاربران اطلاع‌رسانی کنید.

اخبار روز تکنولوژی و اینترنت رو از وبسایت ما بخوانید.

نظرات

هیچ نظری ثبت نشده است