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

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

ما هو الباب الخلفي

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

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

أين تختبئ الأبواب الخلفية

يختار المهاجمون أماكن تبدو عادية أو نادرًا ما يفتحها الناس. هذه هي الأماكن المعتادة:

  • مجلد uploads. يجب أن يحتوي على وسائط فقط. وجود ملف PHP في wp-content/uploads غير مشروع في الغالب، وأسماء مثل image.jpg.php تنكّر شائع.
  • مجلد الإضافات الإلزامية. تُحمَّل ملفات wp-content/mu-plugins مع كل طلب، ولا تظهر في قائمة الإضافات العادية.
  • إضافات وقوالب مزيفة أو معدَّلة. مجلد باسم يبدو معقولًا لم تثبّته أنت، أو أسطر مضافة في نهاية functions.php في قالبك النشط.
  • مجلدات نواة ووردبريس. ملف دخيل في wp-includes أو wp-admin، وغالبًا باسم يشبه اسم ملف من النواة.
  • wp-config.php. شيفرة موضوعة فوق السطر الأول أو تحت الأخير.
  • ملفات إعدادات الخادم. يشغّل إعداد auto_prepend_file في .user.ini أو php.ini ملفًا قبل كل صفحة. وقواعد محقونة في .htaccess أسلوب مفضّل آخر.
  • حسابات مسؤول إضافية. مسؤول لم تنشئه، وأحيانًا ببريد إلكتروني يبدو جزءًا من نطاقك أنت.
  • المهام المجدولة. قد يعيد حدث cron في ووردبريس يستدعي دالة غير مألوفة إنشاء باب خلفي محذوف وفق جدول.
  • قاعدة البيانات. شيفرة مخزَّنة في خيار أو مقال، مع محمِّل صغير في مكان آخر يشغّلها. لا يراها فحص الملفات أبدًا.

كيف تبحث عن الأبواب الخلفية

الأوامر أدناه تقرأ موقعك فقط. شغّلها عبر SSH من مجلد ووردبريس، وهو عادةً public_html. وهي تحتاج إلى WP-CLI الذي تتضمنه معظم الاستضافات المُدارة.

1. قارن ملفات النواة والإضافات بالنسخ الرسمية

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

أي ملف مُدرج كمعدَّل، أو كملف لا ينبغي أن يوجد، يستحق النظر. ولا يمكن فحص الإضافات المدفوعة غير الموجودة على wordpress.org بهذه الطريقة.

2. ابحث عن ملفات PHP حيث لا ينبغي أن يوجد أي منها

find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins

كل نتيجة في uploads تحتاج إلى تفسير. وأي شيء في mu-plugins لم تضفه بنفسك علامة تحذير قوية.

3. تحقق مما تغيّر مؤخرًا

find . -type f -name "*.php" -mtime -14

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

4. تحقق من الحسابات والمهام المجدولة

wp user list --role=administrator
wp cron event list

ابحث عن مسؤول لا تعرفه وعن أحداث cron بأسماء لا تستطيع تحديد مصدرها.

5. اقرأ ملفات الإعدادات

cat .htaccess
cat .user.ini
head -n 20 wp-config.php

يجب ألا يحتوي ملف .htaccess إلا على قواعد ووردبريس القياسية وما أضفته عمدًا. ولا ينبغي أن يوجد .user.ini ما لم تكن استضافتك أو أنت من أنشأه. وفي wp-config.php يجب ألا يظهر شيء قبل سطر الافتتاح.

6. ابحث عن دوال مشبوهة، ثم اقرأ الملف

grep -RIl --include="*.php" -E "eval\(|base64_decode\(" wp-content

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

ما يستطيع الماسح وما لا يستطيع إخبارك به

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

ماذا تفعل عندما تجد واحدًا

  1. لا تكتفِ بحذفه. انسخ الملف إلى مجلد حجر خارج الجذر العام للويب لتتمكن من قراءته لاحقًا. ثم أزله من الموقع.
  2. أغلق الطريق الذي دخل منه. يُزرع الباب الخلفي عبر شيء ما، وغالبًا إضافة قديمة أو كلمة مرور مسروقة أو تسجيل دخول ضعيف للاستضافة. وإذا تركت ذلك مفتوحًا، يزرع المهاجم بابًا آخر.
  3. غيّر كل بيانات الدخول. الاستضافة، وSFTP ومفاتيح SSH، وكلمة مرور قاعدة البيانات، وكل مسؤول في ووردبريس، ومفاتيح الأمان في wp-config.php. افعل ذلك بهذا الترتيب.
  4. استبدل ولا تُصلح. أعد تثبيت النواة والإضافات والقوالب من نسخ نظيفة، كما هو موضح في كيف تزيل البرمجيات الخبيثة من موقع ووردبريس.
  5. افحص مرة أخرى. كرّر الأوامر أعلاه بعد 24 ساعة وبعد أسبوع. عودة ملف أو مسؤول تعني أنه فاتك شيء.

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

كيف يساعد SiftWP

يجري SiftWP فحوصات مثل هذه كل أسبوع عبر SSH، دون أي إضافة على موقعك. ينظر في سلامة ملفات النواة والملفات الجديدة في uploads/ وتغييرات قاعدة البيانات وأنماط البرمجيات الخبيثة، ويحقق وكيل ذكاء اصطناعي في كل نتيجة. تُحجر الملفات المشبوهة ولا تُحذف أبدًا، وأي أمر محفوف بالمخاطر ينتظر موافقتك.

ابدأ برصيد مجاني، دون بطاقة