ModSecurity Review
مراجعة:
ModSecurity
· أمور يجب عليك معرفتها مُسبقًا قبل قراءة هذه المقالة:
- Web Application Firewall
- HTTP Request/Response
السلام عليكم ورحمة الله وبركاته،
خلال العمل على أحد المشاريع، مرَرت بمشروع مفتوح المصدر وقضيت بعض الوقت في دراسته والإطلاع عليه بحكم إرتباط فكرته بالمشروع الذي كنت أعمل عليه، وأرى أنه يستحق المراجعة والكتابة عنه.
المشروع المفتوح المصدر الذي سأتحدث عنه في هذه المقالة هو : ModSecurity
· لا تناقش هذه المقالة خطوات تنصيب المشروع وما إلى ذلك، لكن تركّز على طبيعة عمل المشروع الداخلي وإلقاء نظرة على بعض المفاهيم المتعلقة به.
ما هو الـ ModSecurity ؟
هو مشروع مفتوح المصدر عبارة عن Web Application Firewall
ومثل أي WAF ، الـ ModSecurity مُعتمد في طبيعة عمله على بناء Rules يتم إدراجها في هذا النظام
الجدير بالذكر هنا، أن OWASP لديهم مشروع مفتوح المصدر هو الآخر اسمه:
OWASP ModSecurity Core Rule Set (CRS)
والغرض منه هو بناء Rules خاصة بالـ ModSecurity ( بالإمكان أيضًا تطبيقها على WAF أخرى( .
هدف فريق OWASP من هذا المشروع هو بناء قواعد مُتعلّقة بأشهر أنواع الإختراقات، مثل تلك المتضمّنة في قوائمهم.
كيف يعمل الـ ModSecurity ؟
الـ Rules التي يتم بنائها في الـ ModSecurity بالإمكان تطبيقها على مراحل مختلفة:
المرحلة الأولى : REQUEST_HEADERS
في هذه المرحلة يقوم النظام بقراءة الـ HTTP Request Headers
وبالإمكان تطبيق قواعد أمنية تختبر كل ما هو متضمن في الـ Request Headers
على سبيل المثال: بالإمكان في هذه المرحلة بناء قواعد تختبر إذا ما كان أي جزء من أجزاء الـ Request Headers يحتوي على injection code ومن ثم حجبه، أو فَلترَته.
المرحلة الثانية : REQUEST_BODY
في هذه المرحلة النظام قادر على قراءة محتوى الـ HTTP Request Body
وتطبيق قواعد مُتعلقة بهذا الجزء
ملاحظة: لاحظت بأن الـ ModSecurity يحتوى على XML Parser ، بالتالي أعتقد أنه بالإمكان بناء قواعد مُتعلّقة ببعض ثغرات الـ XML Parsers مثل الـ XXE من خلال هذه المرحلة
بعد أن يُعالج الـ ModSecurity المرحلة الأولى والثانية،
سيتم تمرير الـ HTTP Request كاملًا إلى الـ Web Application الذي يقع خلف الـ ModSecurity
ومن ثُم سيُعالج تطبيق الويب الطّلب ويقوم بإرسال الـ HTTP Response ، وهنا يأتي دور المرحلة الثالثة والرابعة في الـ ModSecurity
المرحلة الثالثة : RESPONSE_HEADERS
في هذه المرحلة نستطيع بناء قواعد تتعامل مع الـ HTTP Response Headers
على سبيل المثال: نستطيع بناء قاعدة تقوم بالتعديل على الـ Response Headers بقيم معيّنة.
المرحلة الرابعة : RESPONSE_BODY
في هذه المرحلة بالإمكان كتابة قواعد تقوم بعمل inspect/parse للـ Response Body القادم من تطبيق الويب وقبل أن يتم إرساله للـ Client
على سبيل المثال: بالإمكان بناء قاعدة تقوم بفحص الـ Response Body والتأكد بأنه لم يتم تسريب بعض المعلومات الحساسة ضمن الـ Response Body ، بمعنى آخر بإمكاننا بناء قواعد تخدم ما يعرف بمفهوم الـ Data Leakage Prevention
يوجد مرحلة أخرى أيضًا وهي ما يعرف بـ
المرحلة الخامسة : Logging
في هذه المرحلة يتيح لنا الـ ModSecurity تسجيل كل الأحداث، لفحصها ومراجعتها لاحقًا، وبالإمكان أيضًا بناء قواعد تقوم بعملية التسجيل Logging في حالة تحقق شرط ما، قد يكون هذا الشرط مثلًا محاولة حقن كود خبيث في الـ Request Headers
ملخّص المراحل:
المرحلة الأولى والثانية: تتيح التّحكم الكامل بالـ HTTP Request القادم من الـ Client
المرحلة الثالثة والرابعة: تتيح التّحكم الكامل بالـ HTTP Response القادم من الـ Web Application
لذلك قبل بناء أي قاعدة، أو لصد أي هجوم ( في حدود إمكانيات الـ WAF )، يجب عليك معرفة المرحلة التي يحدث فيها الضّرر حتى تستطيع معالجته، الجدول التالي يُلخّص المراحل:
في الجزء الأخير من المقالة سنتطرّق لمفهوم جميل جدًا في وجهة نظري ويتيح لنا إمكانيات قويّة إذا ما أُستُخدم بطريقة فعّالة وهو :
Virtual Patching :
حتى نعرف الفائدة الأساسية وراء هذا المفهوم لنأخذ هذا المثال:
تخيّل معي أنّك مبرمج مسؤول عن تطبيق ويب، وتم إكتشاف ثغرة في أحد المكتبات التي قمت باستخدامها في بناء التطبيق، لنفترض أن هذه الثغرة يتم إستغلالها عن طريق الحقن في أحد المتغيرات في الـ HTTP Request ، والفريق الذي قام ببناء هذه المكتبة على الأغلب سيأخذ مدة طويلة جدًا لمعالجة هذا الخلل في كود المكتبة ..
فـ ما الحل هُنا ؟
- عملية التعديل على الكود الخاص بتطبيق الويب وإستبدال المكتبة بمكتبة أخرى قد لا تبدو فكرة جيدة وقابلة للتطبيق! من جهة أخرى قد يوجد dependencies عدة في الكود الخاص بك مرتبطة بهذه المكتبة، فعملية استبدال المكتبة قد تنتهي بك بإعادة برمجة بعض الخواص الأساسية في التطبيق.
- عملية الإنتظار حتى يُصدِر فريق المطورين الـ Fix أيضًا ليست خيار
وهنا يأتي دور مفهوم الـ Virtual Patching ، وهو :
طالما لدينا نظام يقع في المنتصف بين الـ Requests القادمة من المستخدم، والـ Responses القادمة من تطبيق الويب، لماذا لا يتم حل المشكلة في هذه الطبقة؟
بمعنى آخر :
إستغلال الثغرة ماهو إلا malicious Request قادم من المستخدم ، ومن إمكانيات الـ ModSecurity هي عمل inspect/parse لهذه الـ Requests ، فالفكرة هي بناء Patch يعمل على هذه الطبقة ويقوم بحجب الـ malicious Request قبل أن يصل لتطبيق الويب.
مثال : الكود التالي يحتوي على ثغرة SQLi
· الكود فقط لتوضيح الغرض من هذا المفهوم، لكن الآلية التي كُتب بها تعتبر مُمارسة خاطئة جدًا في معالجة مدخلات المستخدم
الـ Patch الخاص بالثغرة السابقة سيتم تطبيقه في الـ ModSecurity وسيكون كالآتي:
ملاحظات أخيرة حول الـ Virtual Patching في الـ ModSecurity :
- قبل بناء الـ Virtual Patch ، يجب أن تقوم ببناء Exploit خاص بالثغرة التي تود معالجتها، والغرض من هذه الخطوة هو التأكد من أن الثغرة تمت معالجتها عبر الـ Virtual Patch ، حيث أنك ستقوم بمحاولة إستغلال الثغرة مجددًا بهذا الـ Exploit والتأكد بأنه لن ينجح.
- بناء Virtual Patch يحتاج معرفة كافية بمكان الضرر في التطبيق الخاص بك، وبماهية الثغرة التي قد يتم إستغلالها وعلى أساس هذا ستقوم ببناء الـ Virtual Patch
- خذ بعين الإعتبار بأنه بناء بعض الـ Virtual Patches قد تعطّل بعض الخدمات services في تطبيق الويب الخاص بك، لذلك تأكد جيدًا من المُهمة التي يقوم الـ Virtual Patch بعملها.
ختامًا، إن أصبت فمن توفيق الله وحده، وإن أخطأت فمن نفسي والشيطان
هذه بعض المصادر التي إستندَت عليها هذه المقالة وأرشّح لك الإطلاع عليها في حال أردت الإستزادة حول الـ ModSecurity :
المراجع:
كتب:
- ModSecurity 2.5 - Securing your Apache installation and web applications by Magnus Mischel
أوراق علمية:
- WAF Virtual Patching Challenge: Securing WebGoat with ModSecurity by Ryan Barnett : https://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf
- Methods for the Controlled Deployment and Operation of a Virtual Patching Program by William Vink : https://www.sans.org/reading-room/whitepapers/threats/paper/38430