یک توسعه‌دهنده SaaS متوجه شد که فعال کردن Bot Fight Mode کلودفلر برای تمام دامنه‌های موجود در حساب کاربری‌اش، باعث توقف ترافیک API به مدت یک ماه کامل شده است؛ اتفاقی که باعث شد مشتریان پولی نتوانند از ویژگی‌های اصلی محصول او استفاده کنند.

این مشکل زمانی آشکار شد که توسعه‌دهنده متوجه ثابت ماندن ناگهانی نمودار معیارهای استفاده شد. ثبت‌نام‌های جدید همچنان ادامه داشت، اما تعداد نشست‌های (sessions) فعال دیگر رشد نمی‌کرد. پس از هفته‌ها بازنویسی کد و عیب‌یابی، مشخص شد که یک کلید امنیتی واحد مقصر اصلی بوده است: Bot Fight Mode کلودفلر، نقطه انتهایی (endpoint) AWS Lambda خودِ آن سرویس SaaS را به عنوان یک بات مخرب شناسایی و آن را مسدود کرده بود.

چگونه یک تنظیم واحد، کل یک سرویس را از کار انداخت

پشته تکنولوژی (stack) این توسعه‌دهنده بر فراخوانی‌های سرور-به-سرور متکی بود. یک تابع Lambda داخلی به‌طور منظم داده‌ها را به دامنه عمومی SaaS ارسال می‌کرد؛ الگویی که در معماری‌های مدرن میکروسرویس بسیار رایج است. Bot Fight Mode درخواست‌هایی را که شبیه به اسکرپرهای (scrapers) خودکار به نظر می‌رسند، به چالش می‌کشد یا مسدود می‌کند تا از سایت‌های محتوا-محور در برابر جمع‌آوری داده‌ها محافظت کند.

وقتی این حالت برای تمام زون‌ها (zones) فعال شد، کلودفلر با درخواست خروجی Lambda مانند یک کلاینت خودکار دیگر برخورد کرد. درخواست هرگز به اپلیکیشن نمی‌رسید و چون مسدودسازی در لبه (edge) رخ داده بود، ابزارهای مانیتورینگ SaaS هیچ خطایی را نشان نمی‌دادند – ترافیک به سادگی ناپدید می‌شد. استفاده از CPU در Cloudflare Workers توسعه‌دهنده به شدت افزایش یافت و همین باعث شد او به جای بک‌اِند خودش، به یک اسکرپر خارجی شک کند.

تنها پس از بررسی دقیق لاگ‌های کلودفلر بود که او ورودی‌های مسدود شده توسط "Bot Fight Mode" را که با محدوده IP مربوط به Lambda مطابقت داشتند، مشاهده کرد. او این ویژگی را برای زون‌های آسیب‌دیده خاموش کرد، ترافیک API دوباره برقرار شد و معیارهای استفاده به حالت عادی بازگشت.

چرا این اشتباه برای اپراتورهای SaaS اهمیت دارد

  • محصولات API-محور به کانال‌های باز سرور-به-سرور نیاز دارند. Bot Fight Mode فرض را بر این می‌گذارد که ترافیک اصلی، درخواست‌های انسانی از طریق مرورگر برای دریافت HTML، تصاویر یا دارایی‌های استاتیک است. پلتفرم‌های SaaS که APIها، وب‌هوک‌ها یا کال‌بک‌های داخلی را ارائه می‌دهند، ممکن است بدون اینکه کد خطای قابل مشاهده‌ای به لایه اپلیکیشن برسد، محدود یا مسدود شوند.
  • تنظیمات امنیتی سراسری به‌ندرت با تمام بارهای کاری (workloads) سازگار هستند. اعمال یک پیکربندی واحد کلودفلر برای تمام دامنه‌ها، با هر سایت به گونه‌ای برخورد می‌کند که گویی همگی مدل تهدید یکسانی دارند. سایت‌های محتوا-محور، تالارهای گفتگو و بک‌اِندهای SaaS، الزامات امنیتی بسیار متفاوتی دارند.
  • شکست‌های بی‌صدا باعث از دست رفتن درآمد می‌شوند. سیستم هشداردهی توسعه‌دهنده فعال نشد، زیرا درخواست‌های مسدود شده هرگز به اپلیکیشن نمی‌رسیدند. تنها افت در معیارهای تعامل کاربر بود که به مشکل اشاره داشت. بدون بررسی فعالانه لاگ‌های سطح لبه (edge-level)، مشکلات مشابه می‌توانند بدون اینکه شناسایی شوند، پابرجا بمانند.

چه کارهایی می‌توانند توسعه‌دهندگان برای جلوگیری از سرنوشتی مشابه انجام دهند

  1. پروفایل ترافیک هر زون را بازرسی کنید. قبل از فعال کردن Bot Fight Mode، انواع درخواست‌هایی را که دامنه شما انتظار دارد لیست کنید: مرورگرهای انسانی، فراخوانی‌های API، کال‌بک‌های وب‌هوک یا فراخوانی‌های سرویس‌های داخلی. اگر هر یک از آن‌ها برای عملکرد اصلی ضروری هستند، با آن زون به عنوان یک زون "API-first" برخورد کنید و تنظیمات کاهش اثرات بات را در حداقل نگه دارید.
  2. تغییرات را در یک محیط مرحله‌ای (staged environment) تست کنید. کلودفلر به شما اجازه می‌دهد تنظیمات را روی یک زیردامنه واحد یا یک زون مرحله‌ای اعمال کنید. قبل از اعمال تغییرات در سطح جهانی، تأیید کنید که اتوماسیون‌های قانونی همچنان کار می‌کنند.
  3. لاگ‌های سطح لبه را به عنوان بخشی از پشته مشاهده‌پذیری (observability stack) خود مانیتور کنید. لاگ‌های فایروال و کاهش اثرات بات کلودفلر را به یک SIEM، Loki یا هر سرویس تجمیع‌کننده‌ای ارسال کنید. افزایش ناگهانی در درخواست‌های مسدود شده را با افت در معیارهای اپلیکیشن همبسته کنید تا شکست‌های بی‌صدا را زودتر شناسایی کنید.
  4. تنظیمات امنیتی را برگشت‌پذیر کنید. یک برنامه بازگشت (rollback plan) مستند داشته باشید. اگر یک قانون جدید باعث رفتار غیرمنتظره شد، ابتدا آن را غیرفعال کنید و قبل از صرف وقت برای راه‌حل‌های جایگزین در کد، تغییر را تأیید کنید.
  5. سوال درستی بپرسید. به جای پرسیدن "چگونه می‌توانم اسکرپرها را متوقف کنم؟"، بپرسید "آیا این ابزار مشکل خاصی را که من می‌بینم حل می‌کند؟". یک ویژگی امنیتی که اسکرپرها را مسدود می‌کند، ممکن است پاسخ مناسبی برای یک SaaS نباشد که به دسترسی باز به API نیاز دارد.

دیدگاه گسترده‌تر

Bot Fight Mode برای سایت‌هایی که نیاز دارند از محتوای استاتیک خود در برابر خزنده‌های (crawlers) تهاجمی محافظت کنند، همچنان ارزشمند است. نقطه ضعف آن، عدم توانایی در تشخیص بین یک اسکرپر خصمانه و یک کلاینت خودکار قانونی است که از همان الگوهای HTTP پیروی می‌کند.

نتیجه‌گیری

وقتی چندین دامنه را تحت یک حساب کاربری واحد کلودفلر مدیریت می‌کنید، با هر کدام به عنوان یک زون امنیتی مجزا برخورد کنید. Bot Fight Mode را فقط در جاهایی فعال کنید که ترافیک صرفاً انسانی است؛ برای بارهای کاری SaaS با ترافیک سنگین API، این تنظیم را خاموش نگه دارید یا آن را با قوانین سفارشی فایروال تنظیم دقیق کنید. یک کلیک می‌تواند ترافیک قانونی را به همان اندازه که می‌تواند یک اسکرپر را متوقف کند، ساکت و بی‌اثر کند.