تحويل مؤشرات تهديد 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 في القيام بذلك لا تكمن فقط في قدرتها على الحصول على المزيد من إشارات التهديد، ولكن لديها القدرة على دفع الإشارات إلى طبقة القاعدة، ثم توصيل طبقة القاعدة مرة أخرى بالمراقبة والتراجع والتدقيق. وبدون هذه السلسلة، فإن الوقت الفعلي لن يؤدي إلا إلى حدوث الأخطاء بشكل أسرع؛ مع هذه السلسلة، يمكن للقواعد أن تدخل الإنتاج حقًا.