افهم مخاطر السياسات. اطرح أسئلتك حول السياسات بلغة طبيعية. اطلب عرضًا توضيحيًا ←

Published:

أساسيات سياسة جدار الحماية – كيفية التحقق من قواعد التخفي

by FireMon

تم التحديث – يناير 2017

قاعدة التخفي في جدار الحماية هي القاعدة الصريحة الموضوعة قرب أعلى السياسة والتي تمنع الوصول إلى جدار الحماية بما يتجاوز ما هو مطلوب لإدارة الجهاز. وينبغي تعريفها على النحو التالي:

المصدر = ANY

الوجهة = [self]

الخدمة / التطبيق = ANY

الإجراء = DROP

التسجيل = مُفعّل

لا ينطبق هذا تمامًا على بعض جدران الحماية مثل Juniper Netscreen التي تُعرّف الوصول الإداري عبر إعدادات على مستوى الواجهة بدلًا من سياسة جدار الحماية. ومع ذلك، حتى في هذه الحالات، قد يطلب المدققون وجود قاعدة تخفي كأمر متبع في الممارسة العملية.

لماذا تُعرَّف قاعدة التخفي

تضمن قاعدة التخفي ألا تسمح القواعد المعرَّفة لاحقًا في السياسة بالوصول إلى جدار الحماية عن غير قصد. على سبيل المثال، قد يكون لجدار الحماية واجهة في منطقة Web-DMZ. وقد يصل طلب من فريق تطوير الويب يطلب الوصول عبر SSH إلى جميع الأنظمة في منطقة Web-DMZ. ودون التفكير مليًا في الطلب، يبدو معقولًا أنهم قد يحتاجون إلى وصول SSH إلى جميع تلك الخوادم إذا كانوا المالك الوحيد للأنظمة المعرَّفة في Web-DMZ. غير أنه بدون قاعدة تخفي معرَّفة بشكل صحيح، لن يُسمح بوصول SSH إلى الخوادم في Web-DMZ فحسب، بل إلى جدار الحماية نفسه أيضًا. ومن الواضح أن هذا غير ملائم، لكنه قد يظل دون اكتشاف من مسؤول جدار الحماية لسنوات.

لتفادي هذا الخطأ البسيط والجوهري في آن واحد، ينبغي تعريف قاعدة تخفي في سياسة جدار الحماية.

كيفية التحقق من وجود قاعدة تخفي

هذه العملية مباشرة للغاية. راجعوا كل سياسة وتحققوا من أن قاعدة قرب أعلى السياسة، بعد القواعد الإدارية الضرورية، تمنع كل حركة المرور المتجهة إلى جدار الحماية (Any, Self, Any, Drop, Log).

كيف يمكن لـ FireMon المساعدة

يوفّر FireMon ضوابط معرَّفة مسبقًا للتحقق من وجود قاعدة التخفي في كل سياسة. ويشكّل هذا الضابط جزءًا من التقييمات المعرَّفة مسبقًا، ويمكن إضافته إلى أي تقييم يعرّفه المستخدم كذلك.

وثمة خيار قوي آخر يتمثل في البحث عن القواعد بأنفسكم باستخدام SiCL. وفي هذه الحالة، يكون البحث مباشرًا إلى حد كبير. فأنتم تريدون التحقق من وجود قاعدة صريحة قرب أعلى السياسة تُسقط كل حركة المرور المتجهة إلى جدار الحماية. وباستخدام المتغير المعرَّف مسبقًا self يمكنكم إنشاء استعلام SiCL ينطبق على جميع الأجهزة. وفي هذه الحالة، تكون صيغة SiCL لهذا البحث كالتالي:

rule{ POSITION < 5 and source.any=true and destination is superset of self and SERVICE.any=true and action=’DROP’}

في المثال أعلاه، حدّدتُ أن القاعدة يجب أن تكون ضمن القواعد الأربع الأولى في السياسة وأن الوجهة يجب أن تحتوي بالكامل على مساحة عناوين جدار الحماية (destination is superset of self). ويشمل المجموعة الفائقة الحالة المساوية والأكبر. وself هو كائن جدار الحماية نفسه.

أساسيات سياسة جدار الحماية: التحقق من قواعد التخفي | FireMon