owasp-modsecurity/modsecurityModSecurity هو محرك جدار حماية لتطبيقات الويب (WAF) مفتوح المصدر ومتعدد المنصات، مخصص لخوادم Apache وIIS وNginx. يمتلك لغة برمجة قوية قائمة على الأحداث توفر الحماية من مجموعة من الهجمات ضد تطبيقات الويب، وتتيح مراقبة حركة مرور HTTP وتسجيلها وتحليلها في الوقت الفعلي.
Libmodsecurity هو أحد مكونات مشروع ModSecurity v3. تعمل قاعدة كود المكتبة كواجهة لموصلات ModSecurity التي تستقبل حركة مرور الويب وتطبّق معالجة ModSecurity التقليدية. بشكل عام، توفر إمكانية تحميل/تفسير القواعد المكتوبة بتنسيق SecRules الخاص بـ ModSecurity وتطبيقها على محتوى HTTP المقدَّم من تطبيقك عبر الموصلات (Connectors).
إذا كنت تبحث عن ModSecurity الخاص بـ Apache (المعروف أيضاً باسم ModSecurity v2.x)، فهو لا يزال قيد الصيانة ومتاح: هنا.
Libmodsecurity هو إعادة كتابة كاملة لمنصة ModSecurity. عندما صُمم لأول مرة، بدأ مشروع ModSecurity كوحدة Apache فقط. ومع مرور الوقت، تم توسيع المشروع، نظراً للطلب المتزايد، لدعم منصات أخرى تشمل (على سبيل المثال لا الحصر) Nginx و IIS. ومن أجل تلبية الطلب المتنامي على دعم منصات إضافية، أصبح من الضروري إزالة تبعيات Apache الكامنة وراء هذا المشروع، مما يجعله أكثر استقلالية عن المنصة.
نتيجة لهذا الهدف، قمنا بإعادة هيكلة Libmodsecurity بحيث لم يعد يعتمد على خادم الويب Apache (سواء في وقت الترجمة أو أثناء التشغيل). ومن الآثار الجانبية لذلك أنه يمكن للمستخدمين توقع أداء محسّن عبر جميع المنصات. بالإضافة إلى ذلك، انتهزنا هذه الفرصة لوضع الأساس لبعض الميزات الجديدة التي طالما سعى إليها المستخدمون. على سبيل المثال، نسعى إلى دعم سجلات التدقيق (auditlogs) بصيغة JSON بشكل أصلي، إلى جانب مجموعة كبيرة من الوظائف الأخرى في الإصدارات المستقبلية.
لم يعد فرع 'ModSecurity' يحتوي على منطق الوحدات التقليدي (لـ Nginx و Apache و IIS) الذي كان يُجمَّع معاً في السابق. بدلاً من ذلك، يحتوي هذا الفرع فقط على جزء المكتبة (libmodsecurity) الخاص بهذا المشروع. يتم استهلاك هذه المكتبة بواسطة ما أسميناه 'الموصلات' (Connectors)؛ ستتفاعل هذه الموصلات مع خادم الويب الخاص بك وتزوّد المكتبة بصيغة موحدة تفهمها. كل من هذه الموصلات يُدار كمشروع GitHub مستقل. على سبيل المثال، يتم توفير موصل Nginx بواسطة مشروع ModSecurity-nginx (https://github.com/owasp-modsecurity/ModSecurity-nginx).
إن إبقاء هذه الموصلات منفصلة يتيح لكل مشروع دورات إصدار وقضايا وأشجار تطوير مختلفة. بالإضافة إلى ذلك، فهذا يعني أنه عند تثبيت ModSecurity v3 فإنك تحصل فقط على ما تحتاجه بالضبط، دون إضافات لن تستخدمها.
قبل بدء عملية التجميع، تأكد من تثبيت جميع التبعيات المطلوبة.
راجع قسمي التبعيات و الوحدات الفرعية Git لمزيد من المعلومات.
بعد التجميع، تأكد من عدم وجود مشاكل في البناء/النظام الأساسي لديك.
نوصي بشدة بتشغيل اختبارات الوحدة واختبارات الانحدار. توجد أدوات الاختبار هذه في المجلد الفرعي tests/.
كمكتبة ديناميكية، يجب تثبيت libmodsecurity في مكان يمكن لنظام التشغيل لديك العثور فيه على المكتبات الديناميكية.
على الأنظمة الشبيهة بيونكس، يستخدم المشروع autotools في عملية التجميع.
إذا كنت تعمل مع استنساخ git، فتأكد من استنساخ المستودع بشكل متكرر (recursively) أو تهيئة جميع الوحدات الفرعية قبل البناء.
راجع أيضاً قسم الوحدات الفرعية Git.
git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity
يستخدم هذا المستودع وحدات فرعية (submodules) تابعة لـ git. بعد الاستنساخ، تأكد من تهيئة جميع الوحدات الفرعية وجلبها:
git submodule update --init --recursive
يمكنك التحقق من أن جميع الوحدات الفرعية تمت تهيئتها بشكل صحيح باستخدام:
git submodule status
تُظهر الوحدات الفرعية التي تمت تهيئتها بشكل صحيح تجزئة الالتزام (commit hash).
تشير العلامة البادئة - إلى أن الوحدة الفرعية لم تتم تهيئتها.
يمكنك بعد ذلك بدء عملية البناء:
./build.sh
./configure
make
sudo make install
تفاصيل البناء الخاص بتوزيعات معينة موجودة في الويكي الخاص بنا: وصفات التجميع
يمكن العثور على معلومات بناء ويندوز هنا.
تتم معالجة التعبيرات النمطية في SecRules عبر أداة Regex (src/utils/regex.*).
افتراضياً، يستخدم ModSecurity PCRE2 للتعامل مع التعبيرات النمطية.
تُستخدم هذه الآلية بواسطة عوامل تشغيل مثل @rx و @rxGlobal و @verifyCC.
السلوك أثناء البناء:
--with-pcre بشكل صريح (WITH_PCRE).بعبارة أخرى، تتوقع البنيات الحالية استخدام PCRE2 ما لم يتم تكوين خلاف ذلك صراحة.
جميع التبعيات الأخرى مرتبطة بعوامل تشغيل محددة داخل SecRules أو بتوجيهات الإعداد وقد لا تكون مطلوبة للتجميع.
libinjection مطلوب لعاملي التشغيل @detectXSS و @detectSQL.curl مطلوب للتوجيه SecRemoteRules.إذا كانت هذه المكتبات مفقودة، فسيتم تجميع ModSecurity دون دعم لعوامل التشغيل أو التوجيهات المعنية.
يتضمن المستودع الوحدات الفرعية التالية:
others/libinjection – يُستخدم بواسطة عاملي التشغيل @detectSQLi و @detectXSS.
others/mbedtls (مجموعة فرعية من TF-PSA-Crypto) – يُستخدم للوظائف والأدوات المساعدة الخاصة بالتشفير (مثل التجزئة، base64).
ملاحظة: تخطيط mbedTLS v4 الأحدث غير متوافق مع بنية v3 الأقدم. لقد تغيرت البنية الداخلية بشكل كبير، وتم نقل العديد من المكونات إلى وحدات فرعية (مثل TF-PSA-Crypto).
بعد دمج PR #3532، يلزم تشغيل:
git submodule update --init --recursive
يضمن هذا جلب جميع الوحدات الفرعية المطلوبة. بدون هذه الخطوة، لن ينجح بناء المشروع.
يمكنك التحقق من أن جميع الوحدات الفرعية تمت تهيئتها بشكل صحيح باستخدام:
git submodule status
مثال على الإخراج:
bc625d5... bindings/python
2117822... others/libinjection (v4.0.0)
0fe989b... others/mbedtls (v4.1.0)
a3d4405... test/test-cases/secrules-language-tests
إذا كانت وحدة فرعية مفقودة، فستظهر بعلامة بادئة -، على سبيل المثال:
-bc625d5... bindings/python
تشير العلامة البادئة - إلى أن الوحدة الفرعية لم تتم تهيئتها أو جلبها.
test/test-cases/secrules-language-tests – مجموعة اختبارات التوافق والانحدار المشتركة الخاصة بـ SecRules والتي يستخدمها make check.
bindings/python – روابط Python الخاصة بـ ModSecurity (غير مطلوبة لتجميع المكتبة الأساسية).
others/libinjection و others/mbedtls مطلوبان فعلياً للبناء من المصدر ويجب تهيئتهما قبل البناء.