تصليب موقعك قبل أن يُخترق، لا بعده

من يهاجمك، ولماذا

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

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

الترقيع، وهو تسعة أعشار الأمان

أكثر الاختراقات لا تستخدم شيئاً ذكياً. تستخدم إضافة لم تُحدَّث منذ سنة.

• فعّل التحديث التلقائي للإصدارات التصحيحية. الخطر المتوهَّم من تحديث يكسر شيئاً أصغر من الخطر المؤكَّد من نسخة قديمة معروفة الثغرة.
• احذف ما لا تستخدمه. إضافة معطّلة ليست إضافة غائبة — ملفاتها لا تزال على القرص ويمكن طلبها مباشرة عبر HTTP، وكثير من الثغرات لا تحتاج أن تكون الإضافة مفعّلة أصلاً.
• لا تشترِ قالباً "مكسوراً". هذا ليس توفيراً، بل تثبيت باب خلفي بيدك.
• اشترك في تنبيهات ثغرات المنصة التي تستخدمها، واقرأها.

إغلاق المسارات المعتادة

منع تنفيذ PHP في مجلدات الرفع. الثغرة تُستغلّ على مرحلتين: رفع ملف، ثم استدعاؤه. اقطع المرحلة الثانية:

# wp-content/uploads/.htaccess  (Apache 2.4)
<FilesMatch "\.(php|phar|phtml)$">
  Require all denied
</FilesMatch>

صلاحيات الملفات. المجلدات 755 والملفات 644، وwp-config.php عند 640. الصلاحية 777 ليست حلاً لمشكلة صلاحيات، بل تأجيل لها بثمن.

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

define('DISALLOW_FILE_EDIT', true);

xmlrpc.php. إن لم تكن تستخدم تطبيق الهاتف أو النشر عن بعد، أغلقه. الدالة system.multicall تسمح بتجربة مئات كلمات المرور في طلب واحد.

حساب قاعدة البيانات. مستخدم واحد لكل تطبيق، صلاحياته على قاعدته وحدها. لا GRANT ALL ON *.*. حين يُخترق تطبيق واحد لا تُخترق البقيّة معه.

الهوية

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

الرؤوس والنقل

HTTPS على كل شيء مع HSTS، وكوكيز الجلسة بعلامات Secure وHttpOnly وSameSite. ثم الرؤوس الرخيصة التي لا عذر في تركها:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy-Report-Only: default-src 'self'

ابدأ سياسة المحتوى في وضع التقرير فقط. سياسة مفروضة كُتبت بعجلة تكسر موقعك، فتُلغى بالكامل بعد نصف ساعة، فلا تحصل على شيء.

النسخ الاحتياطي جزء من الأمان، لكن بشرط

نسخة احتياطية لم تُجرَّب استعادتها ليست نسخة احتياطية، بل ملف كبير تظنّ به الخير. جرّب استعادة كاملة على بيئة اختبار مرة على الأقل، وسجّل كم استغرقت. واحتفظ بنسخة خارج الخادم نفسه: من يملك حسابك يملك النسخ التي داخله.

أن ترى ما يحدث

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

wp core verify-checksums
wp plugin verify-checksums --all

ثم مرّ على سجلّ الوصول مرة في الأسبوع، وابحث تحديداً عن طلبات POST إلى ملفات PHP داخل مجلدات الرفع، وعن طلبات متكرّرة على wp-login.php من عنوان واحد. أي ملف PHP جديد في مجلد لا يُفترض أن يحوي شيفرة هو حادثة حتى يثبت العكس، لا فضول تؤجّله إلى نهاية الأسبوع.

وحين يحدث

ابدأ من الافتراض أن كل بيانات الاعتماد على الخادم مسروقة: كلمات مرور قواعد البيانات، ومفاتيح API، ومفاتيح SSH، وأملاح الجلسات (salts). غيّرها كلها. ولا تكتفِ بحذف الملف الخبيث الذي وجدته — من رفعه رفع غيره في الغالب، والأنظف والأسرع هو إعادة تثبيت النواة والإضافات من مصادرها الأصلية، واستعادة المحتوى وحده، وسدّ الثغرة التي دخل منها. إن لم تجد تلك الثغرة فأنت لم تنتهِ بعد، مهما بدا الموقع نظيفاً.