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

كام مرة سألت حد «موقعك محمي إزاي؟» وقالك «ما هو على Cloudflare»؟ السحابة البرتقالية لوحدها مش إعداد حماية، دي مجرد بداية. الحلو إن الخطة المجانية فيها أدوات تكفي موقع ووردبريس صغير أو متوسط، بس محتاجة تتظبط وتتختبر بأمر، مش بنظرة على لوحة التحكم.

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

ماذا تعطيك الخطة المجانية فعلاً؟

تشغيل الوكيل (Proxy) في Cloudflare يمنحك شهادة SSL مجانية على الحافة وحماية من هجمات DDoS. لكنه لا يضبط التشفير بين Cloudflare وسيرفرك، ولا يكتب قواعد تعرف شيئاً عن ووردبريس، ولا يضيف رؤوس الأمان.

هذه هي الأدوات التي تتحكم فيها على الخطة المجانية، بحسب توثيق Cloudflare (بتاريخ أكتوبر 2026):

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

ابدأ بالتشفير: Full (Strict) ثم TLS 1.2 ثم HSTS

القفل الأخضر في المتصفح يثبت فقط أن الاتصال بين الزائر وCloudflare مشفّر. في وضع Flexible يظهر القفل نفسه بينما تمر البيانات إلى سيرفرك بلا تشفير، لذلك هذا أول ما تراجعه.

1. افتح لوحة Cloudflare ثم اختر نطاقك، ثم SSL/TLS ثم Overview، واضبط الوضع على Full (strict).
2. إذا لم تكن على سيرفرك شهادة صالحة، أنشئ شهادة مجانية من SSL/TLS ← Origin Server ← Create Certificate وثبّتها في لوحة الاستضافة.
3. من SSL/TLS ← Edge Certificates فعّل Always Use HTTPS، واجعل Minimum TLS Version على 1.2، وفعّل TLS 1.3.
4. فعّل HSTS بمدة 6 أشهر مع تضمين النطاقات الفرعية، واترك خيار Preload مغلقاً في البداية.

تنبيه: لا تفعّل HSTS قبل أن تتأكد أن كل نطاق فرعي عندك يعمل على HTTPS، مثل mail أو shop. وخيار Preload يُدخل نطاقك في قائمة المتصفحات، والخروج منها يستغرق شهوراً.

قواعد WAF الخمس: أين تصرفها في موقع ووردبريس؟

من Security ← Security rules ← Custom rules أنشئ القواعد التالية، وكلها بإجراء Block. هذا هو التوزيع الذي اقترحه كاتب المصدر لموقع ووردبريس:

1. حظر xmlrpc.php: الملف باب معروف لهجمات تخمين كلمات المرور وهجمات Pingback. إذا لم تستخدم تطبيق ووردبريس على الجوال أو خدمة تعتمد عليه، فأغلقه.
2. حظر ملفات كشف المعلومات: مثل readme.html وlicense.txt وwp-config.php وأي مسار فيه /.env أو /.git/، والملفات المنتهية بـ .sql أو .bak أو .log.
3. حظر ملفات PHP داخل مجلد الرفع: مجلد uploads مكانه الصور وملفات PDF فقط، وأي ملف PHP فيه غالباً باب خلفي زرعه مهاجم.
4. حظر أدوات الفحص المعروفة حسب User Agent: مثل wpscan وsqlmap وnikto. المهاجم المحترف يغيّر هذه القيمة، لكن القاعدة تنظّف سجلاتك من الضجيج الآلي.
5. قاعدة لمسار لا تحتاجه: نتحدث عنها في القسم التالي.

هذا تعبير القاعدة الثالثة كما نشره الكاتب، انسخه في محرر التعبيرات (Edit expression):

(starts_with(http.request.uri.path, "/wp-content/uploads/") and ends_with(http.request.uri.path, ".php"))

في ووردبريس: قبل حظر xmlrpc.php تأكد أن إضافة Jetpack أو تطبيق نشر خارجي لا يعتمد عليه. وإذا حظرته فعطّله أيضاً من إضافة الحماية على السيرفر، حتى يبقى مغلقاً لو تجاوز أحد Cloudflare.

راجع مسارات REST API التي أضافتها إضافاتك

أثناء مراجعته وجد الكاتب مساراً في /wp-json/ لم يثبّته بنفسه، هو /wp-json/mcp/mcp-adapter-default-server. وبحسب روايته أضافته إضافة السيو التي يستخدمها مع أحد التحديثات، وكان يتطلب تسجيل الدخول لكنه يقبل كلمات مرور التطبيقات (Application Passwords) التي لا تمر بالمصادقة الثنائية.

لم يُخترق موقعه، لكنه أغلق المسار مرتين: بقاعدة خامسة في Cloudflare تحظر المسارات التي تبدأ بـ /wp-json/mcp، وبإضافة صغيرة من نوع must-use تحذف هذه المسارات عبر الفلتر rest_endpoints على السيرفر.

ما يهمك هنا ليس اسم الإضافة، بل العادة نفسها:

• افتح https://موقعك/wp-json/ وراجع قائمة namespaces، واسأل عن كل اسم لا تعرفه.
• من المستخدمون ← ملفك الشخصي راجع قائمة كلمات مرور التطبيقات واحذف ما لا تستخدمه.
• كرر المراجعة بعد كل تحديث كبير للإضافات، لأن الإضافات تضيف مسارات بهدوء.

قاعدة تحديد المعدل المجانية: مطب سرعة لا قفل

تسمح الخطة المجانية بقاعدة واحدة فقط، فاجعلها لصفحة الدخول. اختر المسار /wp-login.php، وحدداً منخفضاً مثل 3 طلبات خلال 10 ثوانٍ من العنوان نفسه، والإجراء Block.

انتبه إلى حدّين يذكرهما التوثيق الرسمي: فترة العد ومدة الحظر ثابتتان على 10 ثوانٍ، والحقول المتاحة هي المسار وVerified Bot فقط. أي أن القاعدة تعد كل الطلبات إلى المسار، لا طلبات POST وحدها كما كتب كاتب المصدر.

النتيجة أن سكربتاً صبوراً يرسل محاولتين كل عشر ثوانٍ لن يتوقف أبداً. لذلك تبقى الحماية الحقيقية لصفحة الدخول على السيرفر:

• إضافة حماية تقفل الحساب بعد عدد من المحاولات الفاشلة.
• مصادقة ثنائية بتطبيق TOTP على كل حساب مدير.

رؤوس الأمان من الحافة بدل ملفات السيرفر

على الاستضافة المشتركة غالباً لا تستطيع تعديل إعدادات السيرفر. الحل في Rules ← Transform Rules ← Modify Response Header بقاعدة واحدة تُطبَّق على كل الاستجابات:

• أضف: X-Frame-Options وReferrer-Policy وPermissions-Policy وCross-Origin-Opener-Policy.
• احذف: الرؤوس التي تكشف تفاصيل الاستضافة، مثل x-powered-by وأي رأس تضيفه لوحة الاستضافة باسمها.

ميزة هذا الأسلوب أن الرؤوس نفسها تصل مع الصفحات المخزنة في الكاش وغير المخزنة، بلا أي تعديل في .htaccess.

إعدادات تتركها مغلقة عن قصد

الحماية القصوى لا تعني تشغيل كل مفتاح. كل مفتاح تتركه مغلقاً يحتاج سبباً مكتوباً:

• Bot Fight Mode: يتحدى زواحف السيو مثل Ahrefs وSemrush، وأدوات مراقبة وقت التشغيل (Uptime) أيضاً. إذا كان موقعك يعيش على زيارات البحث، فالقواعد الموجهة أفضل من تحدٍّ عام لكل البوتات.
• زواحف الذكاء الاصطناعي: تركها الكاتب مسموحة لأنه يريد أن يظهر موقعه في إجابات أدوات الذكاء الاصطناعي. القرار لك حسب طبيعة محتواك.
• HSTS Preload: مغلق حتى يستقر موقعك على استضافته ونطاقاته الفرعية.

اترك مستوى الأمان على Medium وفعّل Browser Integrity Check، فلا تكلفانك شيئاً في الظهور.

السيرفر الأصلي ولوحة cPanel: حيث تتوقف الخطة المجانية

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

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

تحذير: لا تضف نطاقات IP الخاصة بـ Cloudflare إلى قائمة السماح للوحة WHM أو cPanel. ذلك يفتح لوحة الإدارة لكل من يمر عبر Cloudflare. ادخل إلى لوحة الإدارة عبر عنوان السيرفر مباشرة، واجعل اسم السيرفر نفسه في DNS بالسحابة الرمادية (DNS only).

كثير من الاستضافات المستخدمة في مصر والخليج مشتركة وتعمل بلوحة cPanel، لذلك هذا القسم يخصك غالباً. ولو سيرفرك في أوروبا، فـ Cloudflare يقرّب المحتوى من زوارك في القاهرة والرياض إلى جانب دوره في الحماية.

تحقق بالأوامر: الطريقة الوحيدة لتعرف أن القاعدة تعمل

لقطة الشاشة تُظهر ما نويت فعله، والأمر يُظهر ما يحدث فعلاً. استبدل example.com بنطاقك، وكل الأوامر التالية للقراءة فقط ولا تغيّر شيئاً.

المسارات المحظورة يجب أن ترجع 403:

curl -s -o /dev/null -w "%{http_code}n" https://example.com/xmlrpc.php

curl -s -o /dev/null -w "%{http_code}n" https://example.com/wp-content/uploads/test.php

curl -s -o /dev/null -w "%{http_code}n" https://example.com/wp-json/mcp/mcp-adapter-default-server

أداة الفحص يجب أن تُرفض بـ 403، بينما يرجع المتصفح العادي 200:

curl -s -o /dev/null -w "%{http_code}n" -A "WPScan v3.8" https://example.com/

الاتصال بـ TLS 1.0 يجب أن يفشل تماماً ويرجع 000، ثم أعد الأمر بـ --tlsv1.2 --tls-max 1.2 لتحصل على 200:

curl -s -o /dev/null -w "%{http_code}n" --tlsv1.0 --tls-max 1.0 https://example.com/

وأخيراً راجع الرؤوس بطلب GET حقيقي، لا بـ curl -I، لأن طلب HEAD قد يمر بمسار كاش مختلف:

curl -s -D - -o /dev/null https://example.com/

ابحث عن Strict-Transport-Security والرؤوس التي أضفتها، وتأكد من غياب x-powered-by.

ملاحظة: إذا رجع مسار محظور بـ 200 أو 404 فالتعبير لا يطابق. راجع القاعدة، وانتظر نحو 30 ثانية، ثم أعد الاختبار مع معامل يتجاوز الكاش مثل ?x=1. وعلى ويندوز، إذا ظهر خطأ في التحقق من إلغاء الشهادة أضف --ssl-no-revoke.

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

س: هل خطة كلاودفلير المجانية كافية لحماية موقع ووردبريس؟
ج: لموقع صغير أو متوسط تغطي الكثير: تشفير كامل، وHSTS، وخمس قواعد WAF، وقاعدة لتحديد المعدل، وحماية DDoS. لكنها لا تحمي السيرفر إذا وصل إليه أحد مباشرة، ولا توقف تخمين كلمات المرور البطيء، فأضف قفل الحساب والمصادقة الثنائية على الموقع نفسه.

س: ما الفرق بين وضع Flexible ووضع Full (Strict) في كلاودفلير؟
ج: في Flexible يكون الاتصال بين Cloudflare وسيرفرك غير مشفر رغم ظهور القفل للزائر. في Full (Strict) يُشفَّر هذا الاتصال ويتحقق Cloudflare من صلاحية شهادة السيرفر، وتكفي لذلك شهادة Origin المجانية.

س: هل حظر xmlrpc.php يعطل شيئاً في ووردبريس؟
ج: قد يعطل تطبيق ووردبريس على الجوال وبعض خدمات النشر الخارجية وبعض مزايا Jetpack. إذا لم تستخدم أياً منها فالحظر آمن، ويمكنك إزالة القاعدة في أي وقت.

س: هل أفعّل Bot Fight Mode؟
ج: فقط إذا لم تكن زيارات البحث مهمة لك، لأنه يتحدى زواحف السيو وأدوات المراقبة. لموقع يعتمد على جوجل، القواعد الموجهة لمسارات وأدوات محددة خيار أفضل.

الخلاصة

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

جرّب الأوامر دي على موقعك النهارده وشوف كام واحد فيهم رجع 403. ولو عايز حد يراجع إعدادات موقعك معاك، احجز جلسة من هنا احجز استشارة مجانية.

مراجع إضافية: Custom rules · Cloudflare WAF docs، Rate limiting rules · Cloudflare WAF docs

مرجع المقال (بالإنجليزية): Cloudflare Free Plan Security — The Exact Settings I Run on My Own Site
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.