تبدیل نشانگرهای تهدید Cloudflare به قوانین WAF بلادرنگ

به محض ورود یک نشانگر تهدید به سیستم، قوانین شروع به مسدود کردن ترافیک می کنند. این عمل بسیار تمیز به نظر می رسد. سرعت سریع است، بازخورد سریع است، و گزارش ها زیبا هستند. اما به محض اینکه این چیز به تولید رسید، مشکل اصلی دیگر تبدیل نشانگر به یک قانون نیست، بلکه این است که این قانون در برابر ترافیک، مثبت‌های کاذب و عقب‌نشینی‌ها ایستادگی کند.

وقتی نشانگرهای تهدید Cloudflare را تبدیل به قوانین WAF بلادرنگ کردم، چیزی که به ذهنم رسید کلمات تخیلی “اتوماسیون دسترسی هوشمند” نبود، بلکه چندین تصویر بسیار کاربردی بود: یک IP قرمز علامت گذاری شده بود و ده دقیقه بعد رهگیری شد. یک ASN با ریسک بالا مشخص شد و در نتیجه، یک خروج مشترک کامل درگیر شد. یک نمونه حمله کوتاه مدت به تازگی وارد پایگاه قانون شده بود، و ترافیک حمله قطع شده بود و یک قانون قدیمی باقی می ماند که همچنان به قوت خود باقی است. زمان واقعی در اینجا فقط به سرعت مربوط نمی شود، چرخه حیات قوانین، اعتبار داده ها و مسئولیت های تنظیم را در یک پنجره فشرده می کند.

قوانین می توانند سریع باشند، مشروط بر اینکه بتوان آنها را پس گرفت

هنگامی که یک نشانگر تهدید وارد یک WAF می شود، معمولاً اولین کسی که شکیبایی خود را از دست می دهد نه مهاجم، بلکه فرد وظیفه است. زیرا هنگامی که یک قانون اجرا می شود، آنچه در ادامه می آید «بهبود امنیت» انتزاعی نیست، بلکه صدمات تصادفی خاص، درخواست تجدیدنظر، عقب نشینی و ممیزی است. نشانگرهای سطح IP ساده ترین راه برای تفویض اختیار هستند. آنها ضربه های تک نقطه ای، زمان بقای کوتاه و هزینه های بازیابی پایینی دارند. شاخص هایی مانند ASN، بخش شبکه، اثر انگشت TLS و ترکیب درخواست بسیار محتاط تر هستند. آنها منطقه بزرگ تری را پوشش می دهند و در هنگام ضربه عوارض جانبی سخت تری دارند.

بخش واقعاً ارزشمند این است که قوانین یک بار نوشته نمی‌شوند و سپس با آن انجام نمی‌شوند، بلکه با TTL، منبع، محدوده ضربه و شرایط لغو ظاهر می‌شوند. بدون این فیلدها، قوانین بلادرنگ به سرعت به دسته ای از سوابق ممنوعیت منقضی شده تبدیل می شوند. اگر امروز یک حمله را مسدود کنید، از فردا شروع به مسدود کردن کاربران عادی خواهید کرد. رایج ترین بوی بد در تولید این است که پایه قانون ضخیم تر و غلیظ تر می شود و آنچه حفظ می شود قضاوت مؤثر نیست، بلکه احساسات تاریخی است.

باید بین لایه نشانگر و لایه عمل یک بافر باقی بماند.

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

هنگامی که این قانون واقعاً اجرا می‌شود، بهتر است این قانون یک کلید روشن/خاموش تخت نباشد، بلکه مجموعه‌ای از حالت‌ها است که می‌تواند شدت عمل را بیان کند: ابتدا ضبط، سپس چالش، سپس محدود کردن جریان، و در نهایت وارد کردن رهگیری. مزیت این امر ساده است، قوانین را می توان به تدریج با قوی تر شدن شواهد تشدید کرد، و زمانی که شواهد ضعیف تر شد، می توان آنها را به سرعت کاهش داد. برای تیم امنیتی، این می تواند اعتبار را بهتر از پر کردن همه قوانین به طور همزمان حفظ کند. برای طرف کسب و کار، حداقل می توانند نوسانات غیرعادی را در اولین ظهور ببینند، به جای اینکه منتظر بمانند تا بلیط های خدمات مشتری انباشته شوند تا بفهمند چه اتفاقی افتاده است.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

این ساختار ساده به نظر می رسد، اما در واقع بسیار مهم است. وقتی confidence کم است، چالش اول بیشتر شبیه قضاوت مهندسی است تا رهگیری مستقیم. ttl به طور خودکار پس از انقضا منقضی می شود تا از آویزان شدن اطلاعات قدیمی در کناره جلوگیری شود. scope به یک مسیر یا بخش ترافیک کاهش می یابد تا ناحیه آسیب تصادفی بی نهایت بزرگ شود.

بدون بررسی، قوانین فقط طولانی تر می شوند و مانند یک زباله دان به نظر می رسند.

بزرگترین ترس از WAF در زمان واقعی نرخ ضربه کم نیست، بلکه این است که هیچ کس نمی داند پس از ضربه چه اتفاقی افتاده است. پس از انتشار قوانین، باید بتوانید به سه چیز نگاه کنید: تعداد حملات واقعی مسدود شده‌اند، تعداد درخواست‌های عادی به طور تصادفی کشته شده‌اند، و اینکه آیا روش‌های بای پس جدیدی پس از بازدیدها وجود داشته است یا خیر. تنها با اتصال این سه چیز می توان قاعده را قابل اجرا و نگهداری دانست. بدون هیچ یک از آنها، در نهایت به یک اقدام اینرسی تبدیل می شود که “به هر حال ابتدا آن را مسدود کنید”.

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

این مجموعه ابزار فقط برای تیم هایی مناسب است که از قبل قابلیت دفع دارند

تبدیل نشانگرهای تهدید به قوانین WAF در زمان واقعی برای همه سناریوها مناسب نیست. برای سیستم‌هایی با ترافیک کم، سطح حمله باریک، و به اندازه کافی سریع در حین انجام وظیفه، ادامه تکیه بر قوانین استاتیک و به‌روزرسانی‌های دستی اغلب مشکل‌سازتر است. کسانی که واقعاً به این قابلیت نیاز دارند، معمولاً تیم هایی با ترافیک سنگین، تراکم حمله بالا، تغییرات مکرر قوانین، و از قبل دارای لاگ، بررسی و فرآیندهای وظیفه هستند.

هنگامی که این نوع سیستم پیاده سازی می شود، ارزش فقط “سریعتر توقف” نیست. آنچه مهمتر است تبدیل دفع ایمنی از یک قضاوت دستی یکباره به یک زنجیره اجرایی قابل برگشت، قابل بررسی و درجه بندی است. مزیت پلتفرمی مانند Cloudflare در انجام این کار فقط این نیست که می تواند سیگنال های تهدید بیشتری دریافت کند، بلکه این توانایی را دارد که سیگنال ها را به لایه قانون فشار دهد و سپس لایه قانون را به نظارت، بازگشت و ممیزی وصل کند. بدون این زنجیره، بلادرنگ باعث می شود که خطاها سریعتر اتفاق بیفتند. با این زنجیره، قوانین واقعاً می توانند وارد تولید شوند.