أساسيات ModSecurity وOWASP CRS: درجات الشذوذ ومستويات الحساسية وضبط جدار حماية تطبيقات الويب

يفحص جدار حماية تطبيقات الويب (WAF) طلبات HTTP واستجاباتها ويحجب ما يبدو هجوماً مثل حقن SQL أو حقن السكربتات عبر المواقع أو اجتياز المسارات. وعلى خوادم Linux التي تديرها بنفسك، فإن التركيبة مفتوحة المصدر الأكثر شيوعاً هي محرك ModSecurity مع مجموعة القواعد الأساسية من OWASP المعروفة بـCRS. وهي طبقة إضافية مفيدة بشرط ضبطها، فالجدار غير المضبوط إما يحجب العملاء الحقيقيين أو يُعطَّل في النهاية.

يشرح هذا الدليل كيف تقرر CRS ما تحجبه، وكيف تطبقها بأمان، وما الإصدارات الحالية حتى أكتوبر 2026.

المكونات وإصداراتها

• ModSecurity هو المحرك، وتتولى صيانته الآن OWASP على GitHub. الإصدار 2 وحدة لـApache، والإصدار 3 (libmodsecurity) مكتبة مستقلة تُستخدم مع موصلات مثل ModSecurity-nginx. وقد صدر للخطين إصداران في 29 سبتمبر 2026 (2.9.15 و3.0.17).
• CRS هي مجموعة القواعد. يذكر مشروع CRS أن أحدث إصدار هو 4.30.0 وأن إصدار الدعم طويل الأمد (LTS) هو 4.25.2، وكلاهما صدر في 2 أكتوبر 2026، ويؤكد أن خط CRS 3.3.x وصل إلى نهاية عمره وأن على من ما زال يستخدمه الانتقال. كما تعمل CRS على محرك Coraza.

حزم التوزيعات متأخرة عن ذلك. فـDebian 12 وDebian 13 يوفران ModSecurity 2.9.x لـApache (libapache2-mod-security2)، وlibmodsecurity 3.0.x مع وحدة لـNginx، وCRS من خط 3.3 (modsecurity-crs). هذا مناسب للتعلم ولأول نشر، لكن خطط للانتقال إلى CRS 4، إذ تذكر سلسلة الترحيل من مشروع CRS أن خط 3.3 لا يتلقى إصلاحات للإنذارات الكاذبة ولا اكتشافات جديدة. وإذا جمعت إصداراً من CRS الأصلية مع محركات التوزيعة فاقرأ ملاحظات الإصدار أولاً: فـملاحظات إصدار يوليو 2026 تطلب ModSecurity 2.9.14 أو libmodsecurity 3.0.16، وهي أحدث من الإصدارين 2.9.11 و3.0.14 في Debian 13.

كيف تقرر CRS: درجات الشذوذ

لا تحجب CRS الطلب عند أول قاعدة مطابقة. فبحسب وثائق درجات الشذوذ، تضيف كل قاعدة مطابقة إلى درجة الطلب، وبعد تشغيل كل قواعد الطلب يُحجب إذا بلغت درجته عتبة الطلبات الواردة، وتُقيَّم الاستجابات بالطريقة نفسها مقابل عتبة الاستجابات الصادرة.

• معظم الهجمات المكتشفة تحمل درجة 5 (حرجة).
• العتبتان الافتراضيتان 5 للطلبات و4 للاستجابات، أي أن مطابقة حرجة واحدة تحجب الطلب.
• يحذّر فريق CRS من أن رفع العتبات فوق القيم الافتراضية يسمح بمرور عدد كبير من الهجمات.

مستويات الحساسية (Paranoia Levels)

يحدد مستوى الحساسية عدد القواعد المفعّلة:

تقترح الوثائق ربط المستوى بالمخاطر: لا بيانات شخصية، PL 1؛ بيانات شخصية مثل الأسماء والعناوين، PL 2؛ بيانات مالية حساسة، PL 3. ابدأ بـPL 1 في كل الأحوال وارتفع بعد أن يعمل دون مشكلات.

تطبيق متدرج على Debian مع Apache

sudo apt update
sudo apt install libapache2-mod-security2 modsecurity-crs
sudo a2enmod security2
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo apachectl configtest && sudo systemctl restart apache2

يُضمِّن إعداد الوحدة في Debian كل ملفات *.conf في /etc/modsecurity ويحمّل CRS من /usr/share/modsecurity-crs، أما ملف إعدادات CRS فهو /etc/modsecurity/crs/crs-setup.conf. ويبدأ إعداد المحرك الموصى به بالقيمة SecRuleEngine DetectionOnly: تعمل القواعد وتُسجَّل نتائجها دون حجب أي شيء.

شغّل الوضع DetectionOnly مدة كافية لرؤية الحركة الطبيعية، بما فيها تسجيل الدخول وإتمام الشراء ورفع الملفات وصفحات الإدارة وعملاء الواجهات البرمجية. راجع ما كان سيُحجب؛ ويحدد التوجيه SecAuditLog في modsecurity.conf مكان سجل التدقيق. ثم انتقل إلى SecRuleEngine On. وتصف وثائق CRS بديلاً آخر: البدء بوضع الحجب مع عتبات مرتفعة جداً (حتى 10000) ثم خفضها تدريجياً إلى القيم الافتراضية.

يُضبط مستوى الحساسية والعتبات في crs-setup.conf عبر القاعدتين 900000 و900110. وفي CRS 4 اسم متغير الحساسية tx.blocking_paranoia_level، بينما استخدم خط 3.3 الاسم tx.paranoia_level.

معالجة الإنذارات الكاذبة

الإنذار الكاذب طلب مشروع يحصل على درجة مرتفعة، مثل محرر نظام إدارة محتوى يحفظ شيفرة HTML، أو حقل كلمة مرور يحتوي رموزاً تشبه SQL. عالجه باستثناء ضيق قدر الإمكان، كما يشرح دليل الضبط:

• SecRuleRemoveById يعطل القاعدة في كل مكان (استثناء واسع؛ استخدمه بحذر).
• SecRuleUpdateTargetById يوقف فحص القاعدة لمعامل أو ملف تعريف ارتباط محدد في كل مكان.
• ctl:ruleRemoveById وctl:ruleRemoveTargetById داخل قاعدة خاصة بك يفعلان ذلك لمسار أو شرط محدد فقط (وهو المفضل).

مثلاً، لإيقاف فحص القاعدة 941320 للمعامل wp_post:

SecRuleUpdateTargetById 941320 "!ARGS:wp_post"

مكان الاستثناءات هو الملفات التي توفرها CRS لهذا الغرض (REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf وRESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf، المنشأة من نسختيهما بامتداد .example)، لا تعديل ملفات القواعد التي تستبدلها التحديثات. وقد استبدلت CRS 4 حزم استثناءات التطبيقات القديمة بإضافات (plugins)، فإن كنت تستخدم إحدى تلك الحزم في CRS 3 فثبّت الإضافة المقابلة لها.

أخطاء شائعة

• رفع عتبة الشذوذ لإسكات الإنذارات الكاذبة بدلاً من كتابة الاستثناءات.
• القفز مباشرة إلى PL 3 أو 4 في وضع الحجب.
• ترك DetectionOnly مفعلاً لأشهر دون قراءة السجلات.
• اعتبار الجدار بديلاً عن تحديث التطبيق؛ فهو يقلل المخاطر ولا يصلح الشيفرة المعرضة للثغرات.

ما الذي ينبغي فعله

• ابدأ بـPL 1 والعتبات الافتراضية، في وضع DetectionOnly أو مع عتبات مرتفعة جداً.
• راجع السجلات مقابل الحركة الحقيقية واكتب استثناءات ضيقة في ملفات الاستثناءات.
• انتقل إلى الحجب، ثم فكّر في PL 2 إن كنت تعالج بيانات شخصية.
• خطط للانتقال من CRS 3.3 إلى إصدار من CRS 4 مع التحقق من متطلبات إصدار المحرك في ملاحظات الإصدار.
• حافظ على تحديث التطبيق والمحرك ومجموعة القواعد.

المصادر

• coreruleset.org
• coreruleset.org/docs/2-how-crs-works/2-1-anomaly_scoring
• coreruleset.org/docs/2-how-crs-works/2-2-paranoia_levels
• coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning
• coreruleset.org/docs/1-getting-started/1-1-crs-installation
• coreruleset.org/20260330/migrating-crs-3-to-4-part-1-overview
• coreruleset.org/20260702/crs-versions-4.28.0-4.25.1-lts-and-3.3.10-released
• coreruleset.org/20261002/crs-versions-4.30.0-and-4.25.2-lts-released
• github.com/coreruleset/coreruleset/blob/v4.25.2/crs-setup.conf.example
• github.com/owasp-modsecurity/ModSecurity
• github.com/owasp-modsecurity/ModSecurity/releases
• github.com/owasp-modsecurity/ModSecurity-nginx
• packages.debian.org/trixie/libapache2-mod-security2
• packages.debian.org/trixie/modsecurity-crs
• packages.debian.org/trixie/libmodsecurity3t64
• packages.debian.org/bookworm/modsecurity-crs
• sources.debian.org/src/modsecurity-apache/2.9.11-1%2Bdeb13u1/debian/security2.conf