شرح ModSecurity 2026: كيف تحمي موقعك من SQL Injection و XSS

شرح ModSecurity أصبح من أهم المواضيع التي يجب على كل مدير سيرفر أو مالك موقع فهمها في عام 2026، فمع تصاعد الهجمات الإلكترونية بشكل غير مسبوق وتطور تقنيات المهاجمين لاستغلال ثغرات تطبيقات الويب، لم يعد الاعتماد على جدار الحماية التقليدي على مستوى الشبكة كافياً لحماية المواقع. هنا يأتي دور شرح ModSecurity كحل متكامل وفعّال يعمل على مستوى التطبيق نفسه، ويفحص كل طلب HTTP قبل وصوله إلى موقعك ويحلّل محتواه بحثاً عن أي محاولة استغلال خبيثة.

في هذا الدليل المتكامل سنقدم شرح ModSecurity من الصفر حتى الاحتراف، بدءاً من فهم آلية عمله كجدار ناري لتطبيقات الويب (Web Application Firewall)، مروراً بخطوات التثبيت العملية على Apache و Nginx، وصولاً إلى كتابة قواعد مخصصة وتحليل سجلات الحماية. سواء كنت تدير موقع ووردبريس صغير أو منصة تجارة إلكترونية كبيرة، فإن إتقان شرح ModSecurity سيمنحك طبقة حماية أساسية لا غنى عنها ضد أخطر تهديدات الإنترنت.

ما هو ModSecurity ولماذا تحتاجه؟

ModSecurity هو مشروع مفتوح المصدر يُعد الجدار الناري الأكثر شعبية لتطبيقات الويب على مستوى العالم، تم تطويره أول مرة عام 2002 على يد إيفان ريستيتش (Ivan Ristić)، ثم انتقل لاحقاً إلى شركة Trustwave SpiderLabs، وفي عام 2024 أصبح تحت رعاية مؤسسة OWASP. يعمل هذا الجدار الناري كوحدة (module) داخل خادم الويب، ويقوم بفحص كل طلبات HTTP الواردة والصادرة في الوقت الفعلي، مقارنةً إياها بمجموعة من القواعد المُعرّفة مسبقاً للكشف عن أي نشاط خبيث وحجبه قبل وصوله إلى التطبيق.

قبل قراءة هذا المقال: إذا كنت مبتدئاً في عالم أمن المواقع، ننصحك بقراءة دليل شهادات SSL وحماية ووردبريس من 7 هجمات شائعة أولاً. كذلك إذا كنت تدير سيرفر VPS، اطلع على دليل تأمين سيرفر Linux في 15 دقيقة.

الحاجة إلى ModSecurity أصبحت ملحّة جداً في 2026، فبحسب تقارير الأمن السيبراني الحديثة، فإن أكثر من 70% من الهجمات الناجحة على المواقع تستهدف طبقة التطبيق وليس البنية التحتية، أي أن الجدران النارية التقليدية مثل iptables و UFW عاجزة عن صدّها لأنها لا تفهم محتوى طلبات HTTP. هنا تأتي قوة ModSecurity في فحص محتوى كل طلب: ترويسات HTTP، معاملات GET و POST، الكوكيز، حتى محتوى رفع الملفات، وكلها تخضع لتحليل دقيق قبل تسليمها للتطبيق.

المزايا الرئيسية لاستخدام ModSecurity

• الحماية من هجمات OWASP Top 10 بشكل شامل ومُتكامل.
• قابلية التوسع والتخصيص عبر كتابة قواعد خاصة بطبيعة موقعك.
• سجلات تفصيلية تساعد في التحقيق الجنائي الرقمي بعد الحوادث.
• دعم Virtual Patching لإصلاح ثغرات التطبيقات قبل تحديثها رسمياً.
• عمل ضمن نفس عملية خادم الويب مما يقلل overhead الشبكة.
• مجاني ومفتوح المصدر بلا أي رسوم ترخيص.
• دعم متين من مجتمع OWASP عبر مجموعة CRS الشهيرة.

تستخدم آلاف الشركات حول العالم ModSecurity لحماية مواقعها، من بنوك ومؤسسات حكومية إلى متاجر إلكترونية كبرى. ويُعد جزءاً قياسياً من معظم لوحات تحكم الاستضافة مثل cPanel و Plesk و DirectAdmin، ويمكن تشغيله أيضاً بشكل مستقل على VPS أو Dedicated Server.

كيف يعمل ModSecurity كـ Web Application Firewall (WAF)؟

لفهم آلية عمل ModSecurity بعمق، يجب أن نتصور دورة حياة طلب HTTP الكاملة منذ لحظة وصوله إلى السيرفر حتى استجابة التطبيق وإرسال النتائج للمستخدم. ModSecurity يتموضع بين خادم الويب (Apache أو Nginx) وبين التطبيق الفعلي (PHP أو Python أو غيرها)، ويعمل وفق نموذج خمس مراحل (Five Phases) تغطي كل دورة الطلب والاستجابة بالكامل، وهذا ما يميزه عن أدوات الحماية التي تركز فقط على ترويسات HTTP أو عناوين URL.

المراحل الخمس لمعالجة ModSecurity

• Phase 1 – Request Headers: فحص ترويسات الطلب مثل User-Agent و Cookie و Referer.
• Phase 2 – Request Body: فحص محتوى الطلب بما فيها معاملات POST و JSON و XML.
• Phase 3 – Response Headers: فحص ترويسات الاستجابة قبل إرسالها للعميل.
• Phase 4 – Response Body: فحص محتوى الاستجابة لمنع تسريب بيانات حساسة.
• Phase 5 – Logging: تسجيل الأحداث في ملفات السجل للتحليل لاحقاً.

كل قاعدة في ModSecurity تُكتب بلغة SecRule المخصصة، وتُحدد عند أي مرحلة يجب تطبيقها وما الإجراء المطلوب اتخاذه عند تطابقها. هذه المرونة تمنح المسؤول قدرة هائلة على ضبط الحماية بدقة، فيمكنك مثلاً منع رفع ملفات بامتدادات معينة في Phase 2، أو إخفاء ترويسة Server في Phase 3 لإخفاء معلومات السيرفر عن المهاجمين.

أوضاع التشغيل في ModSecurity

• DetectionOnly: يكتشف الهجمات ويسجلها فقط دون حجبها، مفيد للاختبار الأولي.
• On: الوضع الكامل الذي يكتشف ويحجب الهجمات تلقائياً.
• Off: تعطيل ModSecurity بالكامل، لا يُنصح به على البيئات الإنتاجية.

ينصح خبراء الأمن دائماً بتشغيل ModSecurity في وضع DetectionOnly لمدة أسبوع كامل على الأقل عند التثبيت الأول لمراقبة السلوك الطبيعي للمستخدمين والتعرف على أي False Positives محتملة، ثم الانتقال تدريجياً إلى الوضع الكامل On بعد ضبط القواعد بشكل سليم. هذا المنهج التدريجي يحمي تجربة المستخدم من الانقطاع المفاجئ بسبب قواعد صارمة جداً.

تثبيت ModSecurity على Apache (دليل عملي)

تثبيت ModSecurity على Apache هو السيناريو الأكثر شيوعاً وأسهل بكثير من Nginx بفضل وجود وحدة libapache2-mod-security2 الجاهزة في معظم توزيعات Linux. سنستعرض هنا خطوات التثبيت الكاملة على Ubuntu 24.04 و CentOS Stream 10 و AlmaLinux 10، مع شرح كل أمر ودوره. قبل البدء تأكد أن لديك صلاحيات root أو sudo على السيرفر، وأن خادم Apache يعمل بشكل سليم. الموقع الرسمي httpd.apache.org يحتوي على وثائق التكوين الأساسية لخادم Apache.

التثبيت على Ubuntu/Debian

# تحديث قائمة الحزم
sudo apt update

# تثبيت ModSecurity v2 لـ Apache
sudo apt install libapache2-mod-security2 -y

# تفعيل الوحدة في Apache
sudo a2enmod security2

# نسخ ملف الإعدادات الموصى به
sudo cp /etc/modsecurity/modsecurity.conf-recommended \
        /etc/modsecurity/modsecurity.conf

# تفعيل الوضع On (المنع وليس الكشف فقط)
sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' \
        /etc/modsecurity/modsecurity.conf

# إعادة تشغيل Apache لتطبيق الإعدادات
sudo systemctl restart apache2

# التحقق من تحميل الوحدة
sudo apache2ctl -M | grep security

التثبيت على CentOS/AlmaLinux/Rocky Linux

# تثبيت EPEL repository أولاً
sudo dnf install epel-release -y

# تثبيت ModSecurity
sudo dnf install mod_security -y

# نسخ ملف الإعدادات
sudo cp /etc/httpd/conf.d/mod_security.conf.bak \
        /etc/httpd/conf.d/mod_security.conf

# تفعيل المحرك
sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' \
        /etc/httpd/conf.d/mod_security.conf

# إعادة تشغيل Apache
sudo systemctl restart httpd
sudo systemctl enable httpd

بعد التثبيت يجب التأكد من أن ModSecurity يعمل فعلياً عبر فحص ملف الإعدادات الرئيسي والتحقق من القيم الأساسية مثل SecRuleEngine و SecRequestBodyAccess و SecResponseBodyAccess. الإعداد الموصى به هو تشغيل فحص محتوى الطلب وتعطيل فحص محتوى الاستجابة لتقليل الحمل على السيرفر، خاصة على المواقع ذات الزوار الكثيف.

تثبيت ModSecurity على Nginx

تثبيت ModSecurity على Nginx أكثر تعقيداً قليلاً من Apache لأنه يتطلب في معظم الأحيان إعادة بناء (compile) خادم Nginx من المصدر مع وحدة ModSecurity-Nginx Connector، ولكن النتيجة تستحق العناء بالنسبة للسيرفرات عالية الأداء التي تستضيف عشرات المواقع. المرجع الرسمي nginx.org يقدم وثائق مفصلة عن بناء وحدات Nginx الديناميكية.

خطوات بناء Nginx مع ModSecurity من المصدر

# تثبيت أدوات البناء والاعتماديات
sudo apt install -y git build-essential libpcre3 libpcre3-dev \
    libssl-dev libtool autoconf apache2-dev libxml2-dev \
    libcurl4-openssl-dev automake pkgconf libgeoip-dev liblua5.3-dev

# تنزيل وبناء libmodsecurity v3
cd /opt
sudo git clone --depth 1 -b v3/master \
    https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
sudo git submodule init
sudo git submodule update
sudo ./build.sh
sudo ./configure
sudo make -j$(nproc)
sudo make install

# تنزيل ModSecurity-Nginx Connector
cd /opt
sudo git clone --depth 1 \
    https://github.com/SpiderLabs/ModSecurity-nginx

# تنزيل مصدر Nginx بنفس النسخة المثبتة
nginx -v # تحقق من الإصدار
cd /opt
sudo wget https://nginx.org/download/nginx-1.27.4.tar.gz
sudo tar xzf nginx-1.27.4.tar.gz
cd nginx-1.27.4

# بناء وحدة ديناميكية
sudo ./configure --with-compat \
    --add-dynamic-module=/opt/ModSecurity-nginx
sudo make modules

# نسخ الوحدة لمسار وحدات Nginx
sudo cp objs/ngx_http_modsecurity_module.so \
    /usr/share/nginx/modules/

تكوين Nginx لاستخدام ModSecurity

# أضف هذه السطور في بداية /etc/nginx/nginx.conf
load_module modules/ngx_http_modsecurity_module.so;

# داخل بلوك server أو http
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;

# في ملف /etc/nginx/modsec/main.conf
Include /etc/nginx/modsec/modsecurity.conf
Include /usr/local/owasp-crs/crs-setup.conf
Include /usr/local/owasp-crs/rules/*.conf

بعد إعادة تشغيل Nginx بأمر sudo systemctl restart nginx، يمكنك اختبار الحماية بإرسال طلب يحتوي على نمط XSS بسيط مثل ?test=<script>alert(1)</script> ويجب أن تستلم استجابة 403 Forbidden إذا كانت قواعد OWASP CRS مفعّلة. هذا الاختبار البسيط يؤكد أن المنظومة تعمل ويحجب الهجمات الفعلية.

تفعيل OWASP Core Rule Set (CRS)

OWASP Core Rule Set أو اختصاراً CRS هي مجموعة القواعد القياسية الأكثر استخداماً مع ModSecurity، وتُعد بمثابة “الذخيرة” التي يستخدمها هذا الجدار الناري لاكتشاف الهجمات. بدون قواعد CRS، فإن ModSecurity يعمل كمحرك فارغ لا يحجب أي شيء. CRS تطورها مجموعة OWASP منذ 2006 وتُحدَّث باستمرار لتغطي أحدث الهجمات. يمكنك زيارة المشروع الرسمي عبر coreruleset.org للاطلاع على آخر إصدار ووثائق التكوين.

تنزيل وتفعيل CRS أحدث إصدار

# تنزيل آخر إصدار من CRS
cd /etc/modsecurity/
sudo git clone --depth 1 -b v4.0/master \
    https://github.com/coreruleset/coreruleset.git crs

# نسخ ملف الإعداد الافتراضي
cd crs
sudo cp crs-setup.conf.example crs-setup.conf

# في Apache: تفعيل الـ Includes في security2.conf
sudo nano /etc/apache2/mods-enabled/security2.conf
# أضف:
IncludeOptional /etc/modsecurity/crs/crs-setup.conf
IncludeOptional /etc/modsecurity/crs/rules/*.conf

# إعادة تشغيل Apache
sudo systemctl restart apache2

فهم Paranoia Levels في CRS

تستخدم CRS مفهوم مستويات البارانويا (Paranoia Levels) لتحديد صرامة الفحص، حيث تتراوح من المستوى 1 (الأقل صرامة) إلى المستوى 4 (الأكثر صرامة). كل مستوى يضيف قواعد إضافية أكثر دقة ولكنه يزيد احتمالية ظهور إيجابيات كاذبة (False Positives). للمواقع العامة عادةً يكفي المستوى 1، أما المواقع الحساسة كالبنوك وبوابات الدفع فتحتاج المستوى 3 أو 4.

• Paranoia Level 1: يحجب 95% من الهجمات الشائعة بأقل False Positives، مناسب لمعظم المواقع.
• Paranoia Level 2: فحص أعمق للمعاملات والترويسات، مناسب للتطبيقات المالية المتوسطة.
• Paranoia Level 3: صارم جداً ويتطلب تخصيصاً واسعاً، مناسب للمواقع الحكومية.
• Paranoia Level 4: أقصى مستوى أمان، يتطلب فريق أمان متخصص لإدارته.

الحماية من هجمات SQL Injection

هجمات SQL Injection تظل من أخطر التهديدات على المواقع الديناميكية رغم مرور أكثر من عشرين عاماً على اكتشافها، وهي تحتل المرتبة الثالثة في قائمة OWASP Top 10 لعام 2026. شرح ModSecurity لطريقة الحماية من هذه الهجمات يوضح كيف تعمل قواعد CRS الخاصة بالكشف عن أنماط SQL داخل معاملات الطلب، وكيف تحجب أي محاولة لاستغلال ثغرات الاستعلامات قبل وصولها لقاعدة البيانات.

أنواع SQL Injection التي يحجبها ModSecurity

• Classic Injection: حقن مباشر مثل OR 1=1 و UNION SELECT.
• Blind SQL Injection: الاستفسار باستخدام الشروط المنطقية وقياس وقت الاستجابة.
• Time-based Injection: استخدام دوال مثل SLEEP() لتأخير الاستجابة.
• Out-of-Band Injection: تنفيذ استعلامات DNS أو HTTP لسحب بيانات.
• Second-order Injection: حقن يخزَّن في قاعدة البيانات ثم يُستخدم لاحقاً.

مثال عملي: قاعدة لحجب SQL Injection

# قاعدة مخصصة لمنع كلمات مفتاحية شائعة في SQL Injection
SecRule ARGS "@detectSQLi" \
    "id:1000001,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    msg:'SQL Injection Detected by Custom Rule',\
    severity:CRITICAL,\
    tag:'application-multi',\
    tag:'OWASP_CRS/WEB_ATTACK/SQLI'"

# قاعدة لحجب UNION SELECT
SecRule ARGS "@rx (?i)(union\s+select|union\s+all\s+select)" \
    "id:1000002,\
    phase:2,\
    deny,\
    status:403,\
    msg:'UNION SELECT Attack Blocked'"

المُشغّل @detectSQLi هو محرك ذكي مدمج في ModSecurity v3 يستخدم مكتبة libinjection المخصصة لاكتشاف SQL Injection بدقة عالية ومعدل False Positives منخفض جداً، وهو يتفوق على الأنماط التقليدية القائمة على التعبير المنتظم لأنه يحلل البنية النحوية الفعلية للنص.

الحماية من هجمات XSS (Cross-Site Scripting)

هجمات Cross-Site Scripting أو XSS تأتي في المرتبة الثانية بعد SQL Injection من حيث الانتشار، وتسمح للمهاجم بحقن سكربتات JavaScript خبيثة داخل صفحات الموقع لسرقة الكوكيز أو إعادة توجيه المستخدمين لمواقع تصيد. شرح ModSecurity لكيفية صد XSS مهم جداً لأن قواعد CRS الخاصة بهذا النوع من الهجمات معقدة وتحتاج فهماً دقيقاً لتجنب إيجابيات كاذبة في المواقع التي تسمح للمستخدمين بكتابة محتوى HTML.

أنواع هجمات XSS الثلاثة

• Reflected XSS: يحقن السكربت في URL ويعكسه السيرفر فوراً للمستخدم.
• Stored XSS: يخزَّن السكربت في قاعدة البيانات ويُعرض لاحقاً لكل المستخدمين.
• DOM-based XSS: ينفَّذ في المتصفح فقط دون مرور بالسيرفر.

مثال على قاعدة XSS مخصصة

# قاعدة لاكتشاف XSS باستخدام libinjection
SecRule ARGS|REQUEST_HEADERS|REQUEST_COOKIES "@detectXSS" \
    "id:1000010,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    msg:'XSS Attack Detected',\
    severity:CRITICAL,\
    tag:'OWASP_CRS/WEB_ATTACK/XSS'"

# قاعدة إضافية لحجب الأنماط المشبوهة
SecRule ARGS "@rx (?i)(<script|javascript:|onerror=|onload=)" \
    "id:1000011,\
    phase:2,\
    deny,\
    status:403,\
    msg:'Suspicious XSS Pattern'"

للحصول على أعلى مستوى حماية ضد XSS، يُنصح بدمج ModSecurity مع رؤوس HTTP الأمنية مثل Content-Security-Policy و X-XSS-Protection و X-Content-Type-Options. هذه الرؤوس تُضيف طبقة حماية على مستوى المتصفح وتمنع تنفيذ السكربتات الخبيثة حتى لو نجحت بالعبور من ModSecurity.

الحماية من هجمات RFI و LFI

هجمات Remote File Inclusion (RFI) و Local File Inclusion (LFI) تستهدف بشكل أساسي تطبيقات PHP التي تستخدم دوال include و require بشكل غير آمن، حيث يتمكن المهاجم من جعل التطبيق يحمّل ملفات من السيرفر نفسه أو من سيرفر بعيد لتنفيذ كود خبيث. ModSecurity يحجب هذه الهجمات بفحص محاولات الوصول لملفات حساسة مثل /etc/passwd أو محاولات تضمين روابط HTTP خارجية في معاملات الطلب.

أنماط الهجمات الشائعة

• ../../etc/passwd: محاولة قراءة ملف كلمات مرور النظام.
• php://filter: استخدام wrapper PHP لقراءة ملفات المصدر.
• http://evil.com/shell.txt: تضمين ملف من سيرفر بعيد.
• data:// و expect://: wrappers PHP لتنفيذ كود مباشر.

قاعدة لمنع LFI

SecRule ARGS "@rx (?i)(\.\./|\.\.\\|/etc/passwd|/proc/self|/var/log)" \
    "id:1000020,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    msg:'LFI Attack Detected',\
    severity:CRITICAL"

# منع RFI
SecRule ARGS "@rx (?i)(https?:|ftps?:|php:|data:|expect:)" \
    "id:1000021,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    msg:'RFI Attack Detected'"

كتابة قواعد ModSecurity مخصصة

القدرة على كتابة قواعد مخصصة هي ما يجعل ModSecurity أداة قوية حقاً، فبدلاً من الاعتماد على قواعد CRS العامة، يمكنك تصميم قواعد دقيقة تناسب طبيعة موقعك. شرح ModSecurity لكتابة القواعد يبدأ بفهم بنية SecRule الأساسية: المصدر (Variable)، المُشغّل (Operator)، الإجراء (Action). كل قاعدة لها معرّف فريد (id) يجب أن يكون أكبر من 1000000 لتجنب التعارض مع قواعد CRS.

المتغيرات (Variables) الأكثر استخداماً

• ARGS: كل معاملات GET و POST.
• ARGS_NAMES: أسماء المعاملات فقط.
• REQUEST_HEADERS: ترويسات الطلب.
• REQUEST_URI: المسار الكامل بما فيه query string.
• REQUEST_METHOD: طريقة الطلب (GET، POST، PUT، إلخ).
• REMOTE_ADDR: عنوان IP للزائر.
• FILES_NAMES: أسماء الملفات المرفوعة.

أمثلة عملية لقواعد مخصصة

# منع وصول دول معينة (مثلاً جميع الدول ما عدا العراق)
SecGeoLookupDB /etc/modsecurity/GeoLite2-Country.mmdb
SecRule REMOTE_ADDR "@geoLookup" \
    "id:1000100,phase:1,nolog,pass"
SecRule GEO:COUNTRY_CODE "!@streq IQ" \
    "id:1000101,phase:1,deny,status:403,\
    msg:'Country Not Allowed'"

# تحديد معدل الطلبات (Rate Limiting)
SecAction "id:1000200,phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}"
SecRule REQUEST_URI "@beginsWith /wp-login.php" \
    "id:1000201,phase:2,nolog,pass,setvar:ip.attempts=+1,\
    expirevar:ip.attempts=300"
SecRule IP:ATTEMPTS "@gt 10" \
    "id:1000202,phase:2,deny,status:429,\
    msg:'Too Many Login Attempts'"

# منع رفع ملفات بامتدادات خطيرة
SecRule FILES_NAMES "@rx (?i)\.(php|phtml|pl|py|jsp|asp|sh|cgi)$" \
    "id:1000300,phase:2,deny,status:403,\
    msg:'Dangerous File Upload Attempt'"

تحليل سجلات ModSecurity وفهمها

سجلات ModSecurity هي كنز من المعلومات يجب على كل مدير سيرفر فهمها واستثمارها. يكتب ModSecurity ثلاثة أنواع من السجلات: Audit Log الذي يحتوي تفاصيل كاملة عن الطلبات المحجوبة، Debug Log للتشخيص، وسجلات الأخطاء العادية لخادم الويب. الموقع الافتراضي لـ Audit Log في Apache هو /var/log/apache2/modsec_audit.log أما في Nginx فيتم تحديده يدوياً في ملف الإعدادات.

بنية Audit Log

كل حدث في Audit Log يُقسم إلى أقسام تبدأ بحرف معين بعد العلامة %–xxx-A– مثل A للترويسة، B لطلب الترويسات، C لمحتوى الطلب، F لرد الترويسات، H للاستجابة الكاملة، K للقواعد المطابقة، Z للنهاية. هذا التقسيم يجعل تحليل السجلات أسهل سواء يدوياً أو عبر أدوات مثل ELK Stack و Splunk.

# مثال على إدخال Audit Log
--abcd1234-A--
[27/Apr/2026:10:23:45 +0300] aBcDeFgH 192.168.1.100 54321 ...

--abcd1234-B--
GET /index.php?id=1' UNION SELECT user,password FROM users-- HTTP/1.1
Host: example.com
User-Agent: sqlmap/1.7

--abcd1234-H--
Message: Access denied with code 403 (phase 2).
Matched "Operator detectSQLi against ARGS:id"
[file "/etc/modsecurity/crs/rules/REQUEST-942.conf"]
[id "942100"] [msg "SQL Injection Attack Detected via libinjection"]

# أوامر مفيدة لتحليل السجل
# عد الهجمات حسب IP
grep "Access denied" /var/log/apache2/modsec_audit.log | \
    awk '{print $4}' | sort | uniq -c | sort -rn | head -20

# أكثر القواعد إطلاقاً
grep "id \"" /var/log/apache2/modsec_audit.log | \
    grep -oP 'id "\d+"' | sort | uniq -c | sort -rn

تحسين أداء ModSecurity وتقليل False Positives

أحد أكبر التحديات عند تشغيل ModSecurity على بيئة إنتاجية هو إدارة False Positives، أي الحالات التي تحجب فيها قاعدة طلباً مشروعاً عن طريق الخطأ. هذه المشكلة شائعة جداً في المواقع التي تتعامل مع محتوى مستخدمين مثل المدونات والمنتديات. الحل الصحيح ليس تعطيل القواعد بل ضبطها بدقة عبر استثناءات (exclusions) محددة.

استراتيجيات تقليل False Positives

• تشغيل DetectionOnly لمدة أسبوع لجمع بيانات السلوك الطبيعي.
• استخدام SecRuleRemoveById لاستثناء قواعد محددة لمسارات معينة.
• استخدام SecRuleUpdateTargetById لتعديل المتغيرات المفحوصة.
• رفع Anomaly Threshold تدريجياً بدلاً من حذف القواعد.
• استخدام sec-tweaks الجاهزة لتطبيقات شائعة مثل ووردبريس.

أمثلة على استثناءات شائعة

# استثناء قاعدة معينة لمسار محدد
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:1001000,phase:1,nolog,pass,\
    ctl:ruleRemoveById=941100;ctl:ruleRemoveById=941110"

# استثناء معامل من جميع القواعد
SecRuleUpdateTargetByTag "OWASP_CRS" "!ARGS:editor_content"

# رفع مستوى الإنذار
SecAction \
    "id:900110,phase:1,nolog,pass,t:none,\
    setvar:tx.inbound_anomaly_score_threshold=10"

إدارة ModSecurity من cPanel

إذا كنت تستخدم استضافة مع cPanel/WHM فإن إدارة ModSecurity تصبح أبسط بكثير عبر الواجهة الرسومية. يقدم WHM في إصدار 2026 لوحة كاملة لإدارة ModSecurity من قسم Security Center تتيح لك تشغيل وإيقاف القواعد، عرض الهجمات المحجوبة، إضافة استثناءات، وتنزيل قواعد جديدة. هذه الواجهة مثالية لمن يريد قوة ModSecurity دون التعامل مع سطر الأوامر.

مهام شائعة من WHM

• ModSecurity Tools: عرض الهجمات الأخيرة وفلترتها حسب القاعدة أو IP.
• ModSecurity Vendors: إضافة مزودي قواعد مثل OWASP CRS أو Comodo CWAF.
• ModSecurity Configuration: ضبط الإعدادات العامة من واجهة بسيطة.
• cPHulk Brute Force Protection: يعمل بالتكامل مع ModSecurity.

المستخدم النهائي في cPanel يستطيع أيضاً عرض هجمات ModSecurity الخاصة بحسابه فقط من خلال أداة ModSecurity داخل cPanel، ويمكنه طلب رفع قواعد معينة من المسؤول إذا كانت تسبب مشاكل لموقعه. هذا التكامل بين WHM و cPanel يجعل إدارة الأمن جماعية ومركزية مع منح المستخدمين الشفافية الكاملة.

ModSecurity vs ImunifyAV vs Cloudflare WAF

كثير من المستخدمين يتساءلون عن الفرق بين ModSecurity وحلول الحماية الأخرى مثل Imunify360 و Cloudflare WAF. الحقيقة أن هذه الأدوات ليست بدائل بل مكملات لبعضها، وأفضل بنية أمنية تجمع بينها جميعاً في طبقات متعددة (Defense in Depth). فهم نقاط القوة لكل حل يساعدك على بناء استراتيجية حماية متكاملة.

المقارنة الجوهرية

• ModSecurity: WAF على مستوى السيرفر، مفتوح المصدر، مرونة عالية، يحتاج خبرة.
• Imunify360: حل تجاري شامل يدمج WAF و antivirus و patch management، أسهل إدارة.
• Cloudflare WAF: حماية على مستوى الـ Edge، يحجب الهجمات قبل وصولها لسيرفرك أصلاً.
• BitNinja: منافس Imunify360 بميزات مماثلة وسعر متقارب.

الإستراتيجية المثالية تجمع Cloudflare WAF كخط دفاع أول على مستوى DNS، ثم ModSecurity كخط ثانٍ على مستوى خادم الويب، وأخيراً تطبيق نفسه يجب أن يكتب بطريقة آمنة باستخدام prepared statements ومصادقة قوية. هذا النموذج المتعدد الطبقات يضمن أن فشل طبقة واحدة لا يعني سقوط الحماية بالكامل.

الخلاصة

قدّمنا في هذا الدليل شرح ModSecurity بشكل عملي ومتكامل، بدءاً من فهم آلية عمله كجدار ناري لتطبيقات الويب، مروراً بخطوات التثبيت على Apache و Nginx، وصولاً إلى كتابة قواعد مخصصة وتحليل السجلات. أصبح واضحاً أن ModSecurity ليس مجرد أداة إضافية بل ركيزة أساسية في حماية أي موقع جدي على الإنترنت، خاصة في 2026 حيث تتطور الهجمات بشكل أسرع من أي وقت مضى.

أهم نقطة في شرح ModSecurity هي أن الحماية ليست منتجاً تشتريه وتنساه، بل عملية مستمرة من الضبط والمراقبة وتحليل السجلات. ابدأ بوضع DetectionOnly، ثم انتقل تدريجياً للحجب الفعلي، واستثمر في فهم القواعد التي تنطلق على موقعك لضبط تجربة سلسة لزوارك مع أعلى مستوى أمان. والأهم: لا تعتمد على ModSecurity وحده بل اجمعه مع طبقات حماية أخرى مثل Cloudflare و SSL و backup منتظم لتحصل على بنية أمنية متينة لا تنهار من ضربة واحدة.

الأسئلة الشائعة

هل ModSecurity مجاني فعلاً أم هناك إصدار مدفوع؟

ModSecurity مجاني تماماً ومفتوح المصدر تحت رخصة Apache 2.0، ولا يوجد إصدار مدفوع منه. ما يدفع له بعض المستخدمين هو قواعد تجارية متخصصة مثل Trustwave Commercial Rules أو Atomicorp Rules التي تقدم قواعد إضافية لتطبيقات معينة، لكن قواعد OWASP CRS مجانية وكافية لمعظم الحالات.

هل ModSecurity يبطئ موقعي؟

الـ overhead الذي يضيفه ModSecurity عادة ما يكون بين 5% و 15% على وقت معالجة الطلب، وهو ضئيل مقارنة بالحماية التي يوفرها. على السيرفرات الحديثة بمعالجات قوية لا يشعر الزوار بأي فرق. لتقليل التأثير يمكن تعطيل فحص محتوى الاستجابة (SecResponseBodyAccess Off) لأنه الأكثر استهلاكاً للموارد.

ما الفرق بين ModSecurity v2 و v3؟

الفرق الرئيسي أن v3 أعيدت كتابتها بالكامل بلغة C++ كمكتبة مستقلة (libmodsecurity) يمكن دمجها مع أي خادم ويب عبر connectors، بينما v2 كانت وحدة Apache مرتبطة بشكل وثيق بـ Apache. v3 أسرع وأكثر مرونة وتدعم Nginx بشكل أصلي، لكن v2 لا تزال أكثر استقراراً ومدعومة بشكل أفضل في cPanel/WHM.

هل يمكن استخدام ModSecurity بدون OWASP CRS؟

نعم تقنياً، لكنه لن يوفر أي حماية لأنه مجرد محرك بدون قواعد. عليك إما استخدام CRS أو كتابة قواعدك الخاصة من الصفر، وهذا غير عملي للمستخدم العادي. CRS هو الخيار القياسي والمجاني الذي يوفر تغطية شاملة لـ OWASP Top 10 دون الحاجة لخبرة عميقة بكتابة القواعد.

كيف أتعامل مع False Positive يحجب موقعي؟

أولاً افحص /var/log/apache2/modsec_audit.log لتحدد رقم القاعدة (id) التي تسببت بالحجب، ثم أضف استثناء باستخدام SecRuleRemoveById لتلك القاعدة فقط للمسار المتأثر. لا تعطل القاعدة بشكل كامل لأنها قد تحمي مسارات أخرى. الحل المثالي هو تحديد المعامل الذي سبب المشكلة واستثناؤه فقط بدلاً من تعطيل القاعدة كاملة.