لا تحمي إضافة واحدة موقع ووردبريس بمفردها، كما أن الحماية اليدوية ليست أفضل تلقائياً. الإضافة الموثوقة قد توفر مصادقة ثنائية أو مراقبة أو تحديداً للمحاولات. إعداد الخادم قد يوقف بعض الطلبات قبل PHP. والتحديث والنسخ الاحتياطي يحدان الضرر عندما تفشل طبقة أخرى.
الخطة الجيدة توزع المسؤولية بين الاستضافة والخادم وووردبريس والحسابات والمراقبة.
ابدأ بالتحديثات والمكونات المستخدمة
تضع وثائق ووردبريس الرسمية تحديث النواة والقوالب والإضافات في مقدمة الحماية. النسخ القديمة لا تحصل دائماً على إصلاحات، وتصبح تفاصيل الثغرات معروفة بعد نشر التحديث.
اعمل بقائمة واضحة:
- حدث النواة والإضافات والقوالب إلى نسخ مدعومة.
- احذف الإضافات والقوالب غير المستخدمة، ولا تكتف بتعطيلها.
- ثبت البرامج من WordPress.org أو من المورد الرسمي فقط.
- راجع سجل التغييرات قبل التحديثات الكبيرة.
- اختبر التحديث في staging عندما تكون للموقع معاملات أو تكاملات حساسة.
- احتفظ بنسخة احتياطية قابلة للاستعادة قبل تغيير واسع.
التحديث الآلي مناسب لكثير من الإصلاحات، لكنه لا يلغي مراقبة الموقع. يجب أن تعرف كيف ستكتشف فشل تحديث وكيف ستعود إلى نسخة سليمة.
الحسابات أهم من إخفاء صفحة الدخول
استخدم كلمة مرور فريدة ومدير كلمات مرور. فعّل المصادقة الثنائية للحسابات الإدارية من خلال إضافة موثوقة أو مزود هوية. وقلل عدد المديرين إلى من يحتاجون الصلاحية فعلاً.
ووردبريس لا يتضمن 2FA في النواة وفق دليل الحماية الحالي، لذلك تحتاج إلى مكون محافظ عليه أو SSO. للتكاملات البرمجية استخدم Application Passwords بدلاً من مشاركة كلمة مرور المدير. يمكن إلغاء كلمة مرور التطبيق دون تغيير بيانات دخول المستخدم.
تغيير مسار wp-login.php قد يقلل ضوضاء بعض الروبوتات، لكنه ليس بديلاً عن كلمة مرور قوية و2FA وتحديد المحاولات. المهاجم يستطيع اكتشاف نقاط الدخول بطرق أخرى.
حدد المحاولات قبل أن تستهلك PHP
طلبات تسجيل الدخول الموزعة قد تستهلك موارد حتى عندما تفشل. إذا كانت الاستضافة أو CDN توفر WAF وتحديد معدل، يمكنها إيقاف جزء من الحمل قبل وصوله إلى ووردبريس.
إذا لم توجد حماية على الحافة، تستطيع إضافة أمنية تحديد المحاولات داخل التطبيق، لكنها ما زالت تشغل PHP. اختر المكان بناء على صلاحياتك والبنية المتاحة، وراقب الحظر الخاطئ للمستخدمين الحقيقيين.
لا تعتمد على حظر IP دائم كحل وحيد. الهجمات قد تأتي من عناوين كثيرة، وقد تتغير عناوين المستخدمين الشرعيين.
احم wp-config.php وفق نوع الخادم
يحتوي wp-config.php معلومات اتصال وإعدادات حساسة. في إعداد PHP سليم لا يعرض الخادم مصدر الملف، لكن منع الوصول المباشر طبقة إضافية معقولة.
في Apache 2.4 يمكن استخدام الصيغة الحالية:
<Files "wp-config.php">
Require all denied
</Files>التوجيهات Order, Allow, وDeny قديمة وتعتمد على mod_access_compat. توثيق Apache 2.4 ينصح باستخدام Require وعدم خلط الصيغتين.
قبل تعديل .htaccess:
- تأكد أن الخادم Apache وأن override مسموح.
- احفظ نسخة من الملف.
- اختبر الإعداد في staging.
- تحقق من استجابة الموقع ولوحة الإدارة والمهام المجدولة.
- جهز طريقة رجوع لا تعتمد على لوحة ووردبريس نفسها.
Nginx لا يقرأ .htaccess. هناك تحتاج قاعدة في إعداد server يملكها مسؤول الخادم. بعض الاستضافات تمنع الوصول إلى الملف أصلاً، لذلك افحص الإعداد الحالي قبل إضافة قاعدة مكررة.
يمكن أيضاً وضع wp-config.php مستوى واحداً فوق مجلد ووردبريس عندما يسمح هيكل الاستضافة، كما تشرح وثائق hardening. لا تنقل الملف عشوائياً في استضافة مُدارة قبل مراجعة قيودها.
اضبط صلاحيات الملفات بأقل قدر مطلوب
لا تستخدم 777 لحل خطأ كتابة. توصي وثائق ووردبريس بأن تكون الملفات قابلة للكتابة لمالكها، وأن تمنح خادم الويب ما يحتاجه فقط. القيم المناسبة تعتمد على المالك والمجموعة وطريقة تشغيل PHP والاستضافة.
المخطط الشائع الذي تعرضه الوثائق هو 755 للمجلدات و644 للملفات، لكنه ليس قاعدة تصلح كل خادم. افهم المستخدم الذي يشغل PHP قبل تطبيق أمر recursive على موقع إنتاج.
إذا لم يحتج فريق المحتوى محرر القوالب والإضافات داخل لوحة التحكم، عطله:
define('DISALLOW_FILE_EDIT', true);هذا يقلل قدرة حساب إداري مخترق على تعديل ملف من الواجهة، لكنه لا يمنع مهاجماً حصل على وصول إلى نظام الملفات.
XML-RPC قرار تكامل وليس مفتاحاً عاماً
xmlrpc.php هدف متكرر لمحاولات brute force، خصوصاً system.multicall. مع ذلك قد تستخدمه Jetpack أو تطبيقات وتكاملات أخرى.
إذا أثبت الجرد أن الموقع لا يحتاجه، يمكن حجبه في Apache 2.4:
<Files "xmlrpc.php">
Require all denied
</Files>إذا كان مطلوباً، ضع rate limit أو قواعد WAF وراقب الطلبات بدلاً من تعطيله. اختبر النشر عن بعد و Jetpack وأي تطبيق جوال بعد التغيير.
لا تخلط XML-RPC مع REST API. تعطيل أحدهما لا يعني تعطيل الآخر، وقد تعتمد إضافات أو محرر الكتل على REST.
بادئة الجداول ليست دفاعاً رئيسياً
تغيير wp_ قد يعطل بعض محاولات SQL injection التي تفترض الاسم الافتراضي، وهذا ما تقوله وثائق hardening. لكنه لا يصلح ثغرة SQL injection ولا يحمي بيانات اعتماد قاعدة البيانات.
اختر بادئة غير افتراضية عند إنشاء موقع جديد إذا كان ذلك ضمن معيار الفريق. لا تغير بادئة موقع قائم باستخدام إضافة عشوائية من دون نسخة احتياطية واختبار، لأن التغيير يمس الجداول وبعض القيم التي تشير إليها.
الأولوية هي استخدام إضافات محدثة واستعلامات آمنة وتقليل صلاحيات مستخدم قاعدة البيانات وفق حاجة التشغيل.
النسخة الاحتياطية يجب أن تنجح في الاستعادة
انسخ قاعدة البيانات وwp-content وأي إعدادات لا يمكن إعادة إنشائها. احتفظ بنسخة خارج الخادم نفسه، وحدد مدة الاحتفاظ والحماية من الحذف.
اختبار الاستعادة هو الدليل. نفذ استعادة دورية في بيئة معزولة، ثم افحص:
- فتح الصفحات والصور.
- تسجيل الدخول.
- الروابط الدائمة.
- الطلبات أو النماذج إن وجدت.
- المهام المجدولة والتكاملات.
نسخة يومية لا تكفي إذا اكتشف الاختراق بعد أسابيع وكانت كل النسخ المحتفظ بها مصابة. احتفظ بنقاط زمنية تناسب مخاطر الموقع، وسجل آخر اختبار استعادة ناجح.
راقب ما يحدث
سجل محاولات الدخول والتغييرات الإدارية والتحديثات، لكن لا تخزن كلمات مرور أو أسرار أو بيانات حساسة في السجلات. راقب ارتفاع 401 و403 وطلبات wp-login.php وxmlrpc.php وتغير ملفات غير متوقع.
جهز تنبيهاً يصل إلى شخص يستطيع التصرف. تقرير أمني داخل لوحة لا يراه أحد ليس مراقبة عملية.
إذا اشتبهت في اختراق، لا تكتف بتغيير كلمة مرور. اعزل الموقع، احفظ الأدلة اللازمة، افحص الحسابات والملفات وقاعدة البيانات، ألغ مفاتيح الجلسات والتكاملات عند الحاجة، ثم استعد من أصل معروف ونفذ تحديثات السبب الجذري.
قائمة قبول قبل النشر
- النواة والقوالب والإضافات على نسخ مدعومة.
- المكونات غير المستخدمة محذوفة.
- حسابات الإدارة محدودة و2FA مفعلة.
- التكاملات تستخدم Application Passwords أو اعتماداً قابلاً للإلغاء.
- WAF أو rate limit يغطي نقاط الدخول بحسب البنية.
- قرار XML-RPC موثق ومختبر.
- صلاحيات الملفات لا تمنح كتابة أوسع من الحاجة.
- النسخ الاحتياطية خارج الخادم واختبار الاستعادة مسجل.
- مراقبة الدخول والتغييرات ترسل تنبيهاً قابلاً للتنفيذ.
- توجد طريقة رجوع إذا عطلت قاعدة خادم الموقع.