اسم البرنامج الإضافي	نماذج نينجا
نوع الضعف	كشف البيانات
رقم CVE	CVE-2026-1307
الاستعجال	قليل
تاريخ نشر CVE	2026-03-28
رابط المصدر	CVE-2026-1307

تعرض البيانات الحساسة في نماذج نينجا (<= 3.14.1) — ما يحتاج مالكو مواقع ووردبريس إلى معرفته وكيفية حماية المواقع باستخدام WP-Firewall

ملخص: في 28 مارس 2026، تم نشر ثغرة تؤثر على إصدارات نماذج نينجا حتى 3.14.1 (CVE-2026-1307، CVSS 6.5). تسمح لمستخدم موثق لديه صلاحيات بمستوى المساهم (أو أعلى) بالوصول إلى معلومات حساسة عبر مسار رمز محرر الكتل. على الرغم من أن الثغرة تتطلب حسابًا موثقًا، يمكن استخدام البيانات المكشوفة لتنفيذ هجمات لاحقة وحركة جانبية. يشرح هذا المنشور المشكلة بلغة بسيطة، ويحدد سيناريوهات استغلال واقعية، ويقدم خطوات تصحيح فورية، ويصف أساليب الكشف والمراقبة، ويظهر كيف يمكن لـ WP-Firewall التخفيف من المشكلة وتصحيحها افتراضيًا أثناء تحديثك.

ملاحظة: إذا كنت تستخدم نماذج نينجا على موقعك، اعتبر هذا معلومات قابلة للتنفيذ — قم بتحديث الإضافة على الفور حيثما كان ذلك ممكنًا وطبق الحمايات المتعددة كما هو موضح أدناه.

---

ماذا حدث (نسخة مختصرة)

تسمح ثغرة في إضافة نماذج نينجا (الإصدارات <= 3.14.1) لمستخدم موثق لديه صلاحيات المساهم — وهو دور يُمنح عادةً للأشخاص الذين يقدمون محتوى ولكنهم ليسوا مدراء موثوقين — بالحصول على معلومات داخلية حساسة من خلال تكامل محرر الكتل. تم تصنيف المشكلة على أنها تعرض بيانات حساسة ولها درجة CVSS تبلغ 6.5. أصدرت الشركة المصنعة تصحيحًا في الإصدار 3.14.2؛ التحديث إلى 3.14.2 أو أحدث يزيل الثغرة.

بينما تتطلب الهجمة حسابًا مسجلاً، فإن حسابات مستوى المساهم شائعة نسبيًا في العديد من المواقع (المؤلفون الضيوف، المحررون الخارجيون، المتدربون، المقاولون). يمكن أن تتضمن المعلومات المكشوفة رموزًا أو قيمًا تسمح بالتصعيد أو إساءة استخدام سير العمل في الموقع أو وظائف REST API. وهذا يجعل هذا الأمر أكثر من مجرد قلق نظري: يمكن لمهاجم يتحكم في حساب المساهم أن ينتقل إلى إجراءات أكثر تدميرًا.

---

لماذا يهم هذا — بخلاف رقم CVSS

يتجاهل العديد من مالكي المواقع تهديدات مستوى المساهم تحت افتراض أن هذه الحسابات محدودة بشدة. في الممارسة العملية:

• غالبًا ما تكون لحسابات المساهمين إمكانية الوصول إلى محرر الكتل؛ بعض المحررين وتكاملات الإضافات تقوم بتحميل الأصول، وطلب نقاط نهاية REST، أو تضمين بيانات وصفية حساسة على المحتوى المسود.
• يمكن إعادة استخدام الرموز المكشوفة (nonces، رموز API قصيرة العمر، رموز المحرر) من قبل المهاجمين لاستدعاء نقاط نهاية REST، أو تعداد معلومات الموقع، أو محاولة تصعيد الصلاحيات اعتمادًا على كيفية تعامل الموقع والإضافات مع تلك الرموز.
• إذا تم تسريب الرموز أو المعرفات الداخلية، قد يكون من الممكن أتمتة الهجمات عبر العديد من المواقع التي تستخدم الإضافة — هذه هي الطريقة التي لا تزال بها الثغرات ذات الخطورة المنخفضة تسبب أضرارًا واسعة.

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

---

ملخص تقني (ماذا تخبر مطورك)

• المكونات الإضافية المتأثرة: نماذج نينجا
• الإصدارات المتأثرة: <= 3.14.1
• تم تصحيحه في: 3.14.2
• CVE: CVE-2026-1307
• الامتياز المطلوب: المساهم (المعتمد)
• فئة الثغرة: كشف البيانات الحساسة (OWASP A3)
• تأثير: الكشف عن الرموز المتعلقة بالمحرر أو معلومات داخلية حساسة أخرى لا ينبغي أن تكون متاحة لحسابات المساهم.

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

---

سيناريوهات الهجوم العملية

1. جمع الرموز وطلبات REST
   – يقوم مساهم خبيث بتسجيل الدخول وفتح محرر الكتل. يكشف المكون الإضافي عن رمز في سياق المحرر أو في استجابة نقطة النهاية. يقوم المهاجم بتصدير هذا الرمز ويستخدمه لاستدعاء نقاط نهاية المكون الإضافي أو REST التي تفترض أن الرمز هو دليل على الثقة.
2. الاستطلاع الآلي عبر المواقع
   – إذا كان بإمكان المهاجمين إنشاء نص برمجي صغير أو طلبات مزورة، فقد يكونون قادرين على تحديد المواقع التي تستخدم النسخة الضعيفة (على سبيل المثال، من خلال استكشاف نقاط النهاية والبحث عن شكل استجابة محدد). يمكنهم بعد ذلك استخدام حسابات المساهمين (المشتراة، أو التي تم إنشاؤها عبر تدفقات التسجيل، أو التي تم الحصول عليها من خلال الهندسة الاجتماعية) لجمع الرموز على نطاق واسع.
3. التحول إلى تكاملات الطرف الثالث
   – قد تكون للرموز أحيانًا تداعيات تتجاوز ووردبريس: قد تسمح بإساءة استخدام الخدمات المتصلة أو الويب هوكس في حال كانت هذه الأنظمة تثق في الرمز أو القيمة. حتى لو كانت الرموز قصيرة العمر، يمكن للمهاجم التصرف بسرعة.
4. التصعيد المحلي عبر ربط الثغرات
   – يمكن استخدام الرمز المكشوف كحلقة واحدة في سلسلة: على سبيل المثال، الرمز -> نقطة نهاية REST تكشف عن معرفات المستخدمين -> القوة الغاشمة لحسابات مميزة أو سير عمل إعادة تعيين كلمة المرور.

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

---

إجراءات فورية (ماذا تفعل في الـ 60 دقيقة القادمة)

1. تحديث Ninja Forms إلى 3.14.2 أو أحدث
   – هذه هي الخطوة الأكثر أهمية. قام البائع بإصلاح المشكلة في 3.14.2. قم بالتحديث في جميع البيئات المتأثرة: الإنتاج، والمرحلة، والتطوير.
2. إذا لم تتمكن من التحديث على الفور، قم بتعطيل المكون الإضافي أو تعطيل تكامل محرر الكتل
   – إذا كان التحديث يكسر الوظائف الحرجة وتحتاج إلى وقت للاختبار، فكر في تعطيل المكون الإضافي مؤقتًا على الإنتاج أو تقييد الوصول إلى محرر الكتل لحسابات المساهمين حتى تتمكن من التحديث.
3. مراجعة حسابات المستخدمين مع صلاحيات المساهمين وما فوق
   – تدقيق الحسابات التي تمت إضافتها مؤخرًا. قم بإزالة أو تخفيض مستوى الحسابات التي لا تعرفها. فرض كلمات مرور قوية و2FA لجميع الحسابات المرتفعة.
4. تدوير/إبطال الرموز والجلسات ذات الصلة
   – إذا كنت تشك في التعرض، قم بإجبار المستخدم على تسجيل الخروج للجلسات التي قد تكون تأثرت. توجد أدوات ومكونات إضافية لإنتهاء الجلسات أو تفعيل تسجيل خروج عالمي. فكر في تدوير مفاتيح API أو أسرار الويب هوك المرتبطة بـ Ninja Forms.
5. مراجعة السجلات للأنشطة المشبوهة
   – تحقق من سجلات الوصول وسجلات REST API للأنماط الشاذة من حسابات المساهمين، خاصة الطلبات إلى نقاط نهاية /wp-json/ أو نقاط نهاية محددة للمكون الإضافي بعد فترة وجيزة من فتح محرر الكتل.
6. إخطار المساهمين والمحررين
   – إذا كنت تدير حسابات المستخدمين، قم بإخطار المساهمين لديك بأن يكونوا حذرين، وتغيير كلمات المرور، والإبلاغ عن سلوك غير متوقع.

---

الكشف: كيف تعرف إذا كنت مستهدفًا أو تم استغلالك

ابحث عن المؤشرات التالية:

• طلبات REST API غير العادية التي تنشأ من حسابات المساهمين المعتمدة (POST/GET إلى نقاط نهاية المكون الإضافي).
• حالات متعددة لفتح محرر الكتل من نفس عنوان IP أو حسابات متعددة تأتي من نفس نطاق IP.
• اتصالات أو مكالمات ويب هوك جديدة أو غير متوقعة مرتبطة بخطافات المكون الإضافي الخاص بك.
• طلبات تعيد رموز داخلية أو حقول JSON غير متوقعة في الردود.
• نشاط الموقع أعلى من المعتاد من مستخدمين ذوي صلاحيات منخفضة خلال فترة زمنية قصيرة (خاصة إنشاء العديد من المسودات، تحميل المرفقات، أو تكوين النماذج).

استعلامات سجل قابلة للتنفيذ:

• ابحث في سجلات خادم الويب عن POST/GET إلى مسارات /wp-json/ المرتبطة بنماذج النينجا أو نقاط نهاية محرر الكتل.
• افحص سجلات تصحيح ووردبريس بحثًا عن إشعارات PHP/تحذيرات تكشف عن تعرض البيانات.
• إذا كان لديك سجلات تطبيق (WAF، لوحة الاستضافة، سجلات المكون الإضافي)، قم بتصفية حسب معرفات الحسابات التي هي بمستوى المساهمين وراجع الطلبات الأخيرة.

---

التصلب والتخفيف على المدى الطويل

حتى بعد التحديث، اتخذ هذه الخطوات لتقليل المخاطر وزيادة المرونة:

1. نموذج أقل الامتيازات
   – أعد زيارة تعيينات الأدوار. عادةً لا يحتاج المساهمون إلى محرر الكتل أو قدرات تحميل الوسائط. ضع في اعتبارك إزالة قدرة التحرير أو الانتقال إلى دور أكثر تقييدًا للمساهمين الخارجيين.
2. تفعيل المصادقة الثنائية
   – فرض 2FA (خاصة للحسابات التي لديها أي إذن مرتفع) حتى لا تمنح كلمات المرور المسروقة أو بيانات الاعتماد المعاد استخدامها الوصول على الفور.
3. سير عمل تعديل المحتوى
   – استخدم عمليات المراجعة والتحرير بحيث لا يمكن نشر المحتوى تلقائيًا بواسطة حسابات ذات ثقة محدودة.
4. تحديد تحرير المكونات الإضافية والقوالب
   – تعطيل تحرير الملفات في ووردبريس (تعريف('DISALLOW_FILE_EDIT'، صحيح)) وإزالة الشاشات الإدارية غير الضرورية من الأدوار ذات المستوى الأدنى.
5. التحكم في الوصول إلى REST
   – استخدم مكونًا إضافيًا أو كودًا مخصصًا لتقييد نقاط نهاية REST التي لا تحتاج إلى أن تكون عامة. قم بمراجعة دقيقة لنقاط النهاية التي تعيد البيانات وتأكد من إجراء فحوصات القدرة المناسبة.
6. تطبيق تحديثات الأمان بانتظام
   – حافظ على تحديث الإضافات والسمات ونواة ووردبريس. اختبر التحديثات في بيئة الاختبار قبل نشرها في الإنتاج.
7. تنفيذ تسجيل ومراقبة على مستوى التطبيق
   – تأكد من وجود سجلات واضحة لمن يصل إلى محرر الكتل ومتى. اربط السجلات بأحداث المصادقة حتى تتمكن من ربط سلوك الحساب.

---

كيف يساعد WP-Firewall (حمايات واقعية يمكنك تفعيلها اليوم)

كمزود حماية متعدد الطبقات لمواقع ووردبريس، يقدم WP-Firewall دفاعات متعددة لتقليل كل من القابلية للاستغلال والأثر:

• جدار حماية تطبيقات الويب المدارة (WAF): يحظر أنماط الاستغلال الشائعة ويمكنه نشر تصحيحات افتراضية لوقف حركة المرور الاستغلالية قبل أن تصل إلى الإضافة.
• فحص واكتشاف البرمجيات الضارة: يحدد الحمولة المدخلة أو المؤشرات التي حاول المهاجمون استخدامها من الرموز المسربة.
• تحديد معدل الطلبات والتحكم في IP: يقلل من فعالية جمع الرموز الآلي عن طريق تقليل الطلبات المشبوهة.
• إدارة الجلسات: السماح بإبطال الجلسات القسرية لضمان عدم استخدام الرموز أو الجلسات المكشوفة.
• المراقبة والتنبيهات: اكتشاف نشاط غير عادي للمساهمين وإخطار المسؤولين في الوقت القريب.

إذا لم تتمكن من الترقية على الفور، فإن طبقة WAF التي يمكنها اكتشاف وحظر أنماط الاستغلال المحددة هي حل عملي مؤقت. يدعم WP-Firewall التصحيح الافتراضي والقواعد المخصصة للتخفيف من هذه الفئة الدقيقة من تعرض البيانات الحساسة.

---

قواعد WAF المقترحة والتصحيحات الافتراضية (لمسؤولي المواقع ومهندسي الأمن)

فيما يلي أمثلة على الأساليب لمؤلفي قواعد WAF. هذه أنماط عامة - قم بتكييفها مع بيئتك واختبرها في بيئة الاختبار قبل الإنتاج.

1. حظر مكالمات REST لمحرر الكتل المفرطة من المستخدمين ذوي الامتيازات المنخفضة
   – الشرط: الطلبات إلى نقاط نهاية REST المتعلقة بمحرر الكتل أو وظائف إدارة الإضافات من حسابات ذات دور المساهم.
   – الاستجابة: تقليل أو حظر مع 403 إذا تم تجاوز الحدود.
2. اكتشاف الاستجابات التي تحتوي على رموز في HTML/JSON
   – الشرط: الاستجابات الصادرة لطلبات المساهمين المعتمدين التي تتضمن سلاسل تتطابق مع أنماط تشبه الرموز (مثل، سلاسل base64 الطويلة، “token”، “nonce” في جسم الاستجابة المتعلقة بالإضافة).
   – الاستجابة: سجل واحظر. مثال على regex: (رمز|رقم عشوائي|سر|مصادقة)[\"'\s:]{0,5}[\"']?[A-Za-z0-9-_]{24,}
   ملاحظة: تجنب حظر السلاسل القصيرة الشرعية. قم بضبط التعبير النمطي من خلال الاختبار على بيئة الاختبار.
3. حظر الأنماط المشبوهة حسب وكيل المستخدم ومرجع الطلب
   - الشرط: وكلاء مستخدمين غير متصفحات أو طلبات بدون مرجع إلى نقاط نهاية محرر الكتل.
   - الاستجابة: تحدي (CAPTCHA) أو حظر.
4. تحديد نقاط تحميل الملفات
   - الشرط: تحميلات متعددة إلى نقاط نهاية المحرر بواسطة حسابات المساهمين خلال فترة زمنية قصيرة.
   - الاستجابة: حظر أو طلب مراجعة يدوية.
5. تصحيح افتراضي لنقاط نهاية المكونات الإضافية
   - الشرط: الطلبات إلى مسار المكون الإضافي المعروف بإرجاع بيانات حساسة. إذا لم يكن التحديث ممكنًا بعد، قم بإسقاط الاستجابات أو إرجاع بيانات مُعقمة.
   - الاستجابة: إرجاع 403 أو استجابة مُعقمة حتى يتم تصحيح المكون الإضافي.

إذا كنت تستخدم WP-Firewall، يمكن لفريقنا تقديم ونشر تصحيحات افتراضية مختبرة لحظر توقيعات الاستغلال لهذه الثغرة، بينما تقوم بجدولة تحديث المكون الإضافي.

---

قائمة التحقق من استجابة الحوادث (دليل خطوة بخطوة)

إذا كنت تشك في أن موقعك كان مستهدفًا:

1. عزل
   - قم بتعطيل الوصول العام مؤقتًا أو ضع الموقع في وضع الصيانة إذا كنت تشك في وجود استغلال نشط.
2. الحفاظ على الأدلة
   - قم بتصدير سجلات الخادم، سجلات المكون الإضافي، وسجلات WAF مع الطوابع الزمنية. لا تقم بتقصير الملفات.
3. تدوير الأسرار
   - قم بإلغاء مفاتيح API، أسرار webhook، وأي مفاتيح يمكن الوصول إليها من خلال المكون الإضافي. قم بإجبار تسجيل الخروج لجميع المستخدمين وإصدار إعادة تعيين كلمات المرور للحسابات المتأثرة.
4. تحديث
   - قم بتحديث Ninja Forms على الفور إلى الإصدار المصحح (3.14.2+) عبر جميع البيئات.
5. قم بالمسح والإزالة
   - قم بإجراء فحص كامل للبرامج الضارة. ابحث عن webshells، أبواب خلفية، مهام مجدولة مشبوهة، أو ملفات معدلة.
6. تدقيق الحسابات
   - قم بتعطيل أو إزالة حسابات المساهمين المشبوهة. فرض المصادقة الثنائية وكلمات مرور أقوى عبر المسؤولين والمحررين.
7. استعادة والتحقق
   – إذا كانت سلامة قاعدة الشيفرة مشكوك فيها، استعد من نسخة احتياطية نظيفة تم أخذها قبل الاختراق. تحقق من الوظائف في بيئة الاختبار.
8. بعد الحادث
   – قم بتدوير جميع الأسرار مرة أخرى، راجع السجلات، وطبق تعزيزات إضافية موصى بها سابقًا (أقل امتياز، قيود REST، قواعد WAF).
9. التواصل
   – إذا كانت بيانات المستخدم أو الأنظمة التابعة لجهات خارجية قد تتأثر، اتبع عمليات الإفصاح الخاصة بك وأبلغ المعنيين.

---

توصيات لمزودي الاستضافة ومديري المواقع المتعددة

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

---

استعلامات الكشف النموذجية والبرامج النصية السريعة

سجل خادم الويب (nginx/apache) grep لنقاط نهاية REST:

grep "/wp-json/" /var/log/nginx/access.log | grep "ninja-forms\|block-editor"

ابحث عن نشاط حساب المساهمين:

# استبدل ACCOUNT_ID بمعرف المستخدم"

تحقق سريع من قاعدة بيانات WordPress للبيانات الوصفية المشبوهة للمحرر:

SELECT post_id, meta_key, meta_value;

استخدم هذه كنقاط انطلاق فقط - السجلات والمخططات تختلف حسب المضيف.

---

إرشادات الاختبار والبيئة التجريبية

• دائمًا اختبر تحديثات المكونات الإضافية في بيئة اختبار قبل الدفع للإنتاج.
• أعد تشغيل تفاعلات المحرر الحقيقي في بيئة الاختبار لضمان عدم وجود تراجعات.
• قم بتمكين تصحيح WAF الافتراضي في بيئة الاختبار أولاً للتحقق من الإيجابيات الكاذبة.
• حافظ على النسخ الاحتياطية المجدولة قبل أي تحديث كبير.

---

ابدأ بخطة WP-Firewall المجانية - حماية أساسية، بدون تكلفة

إذا كنت تريد حماية فورية بدون تكلفة لتقليل المخاطر أثناء اختبارك وتطبيق التحديثات، جرب خطة WP-Firewall الأساسية (مجانية). تتضمن جدار حماية مُدار، عرض نطاق غير محدود، جدار حماية لتطبيقات الويب (WAF)، ماسح للبرامج الضارة، وقدرات التخفيف من تهديدات OWASP Top 10 - جميع الأدوات التي تساعد في اكتشاف ومنع محاولات الاستغلال أثناء تطبيق الإصلاحات الدائمة.

اشترك في الخطة المجانية وفعّل الحمايات بسرعة

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

---

الأسئلة الشائعة التي نسمعها من مالكي المواقع

س: “إذا كان هناك مستخدم مساهم في موقعي خبيث، هل يمكنني منعه من استخدام المحرر تمامًا؟”
أ: نعم. يمكنك إزالة قدرات محرر الكتل من دور المساهم، استخدام مكون إضافي لمحرر كلاسيكي يحد من التعرض، أو تحويل المساهمين الخارجيين إلى دور بقدرات أقل.

س: “هل هذه مخاطرة استغلال جماعي واسعة الانتشار؟”
أ: أي ثغرة يمكن أن يتم تفعيلها بواسطة حساب مصدق منخفض الامتياز تصبح مرشحة للاستغلال الجماعي، لأن المهاجمين يمكنهم تسجيل أو شراء حسابات لتوسيع نطاق الاستغلال. نشر دفاعات متعددة الطبقات (تصحيح + WAF + مراقبة) لتقليل المخاطر.

س: “هل سيؤدي إجبار المستخدمين على تسجيل الخروج إلى إلغاء الرموز المعرضة في المحرر؟”
أ: بالنسبة للرموز غير المستمرة المعتمدة على الجلسة، فإن إجبار تسجيل الخروج يكون فعالًا. بالنسبة لمفاتيح API طويلة الأمد أو رموز webhook، يجب عليك إلغاء أو تدويرها بشكل صريح.

س: “هل يمكن لـ WP-Firewall حظر هذا دون تحديث المكون الإضافي؟”
أ: نعم - يمكن أن يحظر التصحيح الافتراضي أنماط حركة المرور الاستغلالية ويمنع تسرب الرموز. لكن التصحيحات الافتراضية هي حل مؤقت: تحديث المكون الإضافي هو الإصلاح طويل الأمد.

---

ملاحظات ختامية من فريق أمان WP-Firewall

الثغرات التي تسرب الرموز الداخلية خطيرة بشكل خاص لأنها تضعف الحمايات الأخرى في مجموعتك. تعامل مع هذه المشكلة بشكل عاجل: قم بتحديث Ninja Forms إلى 3.14.2 (أو أحدث) في أقرب وقت ممكن، وراجع وقلل من امتيازات المساهمين، ودوّر الأسرار المحتملة المتأثرة، وفعّل تصحيحًا افتراضيًا قائمًا على WAF إذا كان هناك أي تأخير في تطبيق التحديث.

إذا كنت بحاجة إلى مساعدة في الكشف، التصحيح الافتراضي، أو استجابة الحوادث، يقدم فريق WP-Firewall خدمات مُدارة ومساعدة احترافية لمساعدتك في استعادة وتقوية موقعك. ابدأ بخطة الحماية المجانية لدينا للحصول على تغطية فورية وانتقل إلى خطة مدفوعة مع زيادة احتياجاتك.

ابق آمنًا واحتفظ بموقعك محدثًا.

— فريق أمان جدار الحماية WP