تم اختراق موقعي: ماذا أفعل خطوة بخطوة (تنظيف البرمجيات الخبيثة وImunify360)

إذا تم اختراق موقعك، فاتبع هذا الترتيب: أولًا امنع المهاجم من الدخول بتغيير جميع كلمات المرور. ثم أوقف الموقع واحفظ نسخة منه كدليل. بعد ذلك حدّد مكان الإصابة باستخدام فاحص البرمجيات الخبيثة في Imunify360 وبمراجعة الملفات التي عُدِّلت مؤخرًا، ثم نظّف الموقع. أفضل حل هو استرجاع نسخة احتياطية من تاريخ يسبق الاختراق. بعدها تعيد تثبيت ملفات WordPress الأساسية والإضافات من مصادرها الرسمية، وتحذف الأبواب الخلفية ومهام cron الخبيثة، وتغلق الثغرة التي استغلها المهاجم. ينطبق هذا الدليل على الاستضافة المشتركة بلوحة cPanel من Cloudesta، وعلى أي سيرفر cPanel أو Linux يعمل عليه WordPress أو أي موقع PHP آخر.

المتطلبات

• صلاحية الدخول إلى حساب cPanel الخاص بك. أما على VPS فتحتاج بدلًا من ذلك إلى صلاحية دخول SSH بمستخدم root.
• Terminal في cPanel (Advanced > Terminal) أو صلاحية دخول SSH لتنفيذ الفحوصات من سطر الأوامر. إذا لم يتوفر أي منهما، فاستخدم File Manager وافتح تذكرة دعم.
• WP-CLI (الأمر wp) لتنفيذ خطوات WordPress، إذا كان مثبتًا على السيرفر.
• صلاحية الدخول إلى Google Search Console الخاص بنطاقك، إذا كانت Google تعرض تحذيرًا.

كيف أعرف أن موقعي تعرّض للاختراق؟

هذه أكثر علامات الاختراق شيوعًا:

• يُعاد توجيه الزوار إلى مواقع احتيال أو كازينوهات أو صيدليات. يحدث هذا غالبًا على الأجهزة المحمولة فقط، أو للزوار القادمين من Google فقط.
• تظهر في نتائج Google صفحات سبام تحت نطاقك، مثل كلمات مفتاحية يابانية أو كلمات خاصة بالأدوية.
• تعرض Google أو متصفحك رسالة "This site may be hacked" أو "Deceptive site ahead".
• يظهر في WordPress مستخدمون بصلاحية مدير لا تعرفهم، أو تظهر في cPanel حسابات FTP غير مألوفة.
• تمتلئ قائمة انتظار البريد بالسبام، أو تصلك رسائل ارتداد لرسائل لم ترسلها، أو يُعلَّق حسابك بسبب إرسال سبام.
• تجد ملفات PHP لم تنشئها، خصوصًا داخل wp-content/uploads.

1. ماذا أفعل فور اكتشاف الاختراق؟

غيّر جميع كلمات المرور

غيّر كلمات المرور التالية بهذا الترتيب:

• كلمة مرور منطقة العملاء في Cloudesta.
• كلمة مرور cPanel، من Preferences > Password & Security.
• كل حسابات FTP، من Files > FTP Accounts. احذف أي حساب FTP لا تعرفه.
• كل حسابات البريد الإلكتروني، من Email > Email Accounts.
• مستخدم قاعدة البيانات، من Databases > MySQL Databases. بعد ذلك حدّث قيمة DB_PASSWORD في wp-config.php لتطابق كلمة المرور الجديدة.
• كل حسابات المديرين في WordPress.

أنشئ أيضًا مفاتيح salts جديدة لـ WordPress من https://api.wordpress.org/secret-key/1.1/salt/، واستبدل بها الأسطر المقابلة في wp-config.php. سيؤدي هذا إلى إنهاء جميع الجلسات المفتوحة، ومنها جلسات المهاجم.

ضع الموقع في وضع الصيانة

امنع الجميع من الوصول إلى الموقع ما عدا عنوان IP الخاص بك أثناء العمل. أضف هذه الأسطر في أول ملف public_html/.htaccess، واستبدل 203.0.113.10 بعنوان IP العام الخاص بك:

<RequireAny>
  Require ip 203.0.113.10
</RequireAny>

احفظ نسخة كدليل

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

cd ~
tar -czf hacked-evidence-$(date +%F).tar.gz public_html
mysqldump -u dbuser -p dbname > hacked-db-$(date +%F).sql

2. كيف أعثر على البرمجيات الخبيثة؟

راجع نتائج فحص Imunify360

على الاستضافة المشتركة من Cloudesta، يفحص Imunify360 ملفاتك تلقائيًا. لمراجعة نتائجه:

• في cPanel، اذهب إلى Security > Imunify360 وافتح قسم فحص البرمجيات الخبيثة.
• شغّل فحصًا جديدًا لحسابك.
• راجع قائمة الملفات المكتشفة. قد تظهر لك أمام كل ملف إجراءات مثل التنظيف أو الاسترجاع، حسب إعدادات السيرفر.
• دوّن مسارات الملفات المكتشفة وتواريخها. يدلّك أقدم تاريخ على الوقت التقريبي لحدوث الاختراق.

ابحث عن الملفات المعدّلة مؤخرًا والملفات المشبوهة

قد تفوت أدوات الفحص بعض الأشياء، لذلك افحص يدويًا أيضًا. نفّذ هذه الأوامر في Terminal الخاص بـ cPanel أو عبر SSH.

اعرض ملفات PHP التي تغيّرت خلال آخر 7 أيام، بدءًا من الأحدث:

find ~/public_html -type f -name "*.php" -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r

ابحث عن ملفات PHP داخل مجلد الرفع. يجب ألا يحتوي مجلد uploads إلا على ملفات الوسائط، لذلك اعتبر أي نتيجة تظهر مشبوهة:

find ~/public_html/wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)

ابحث عن أنماط الأكواد الشائعة في البرمجيات الخبيثة:

grep -rlE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(|eval\(\\\$_(POST|GET|REQUEST)" ~/public_html --include=*.php

راجع مهام cron وملفات .htaccess

كثيرًا ما يضيف المهاجمون مهمة cron تعيد تنزيل البرمجيات الخبيثة بعد حذفها. راجع Advanced > Cron Jobs في cPanel، أو نفّذ:

crontab -l

احذف أي مهمة تشغّل curl أو wget أو base64 أو ملفات لا تعرفها.

بعد ذلك، اعرض جميع ملفات .htaccess:

find ~/public_html -name ".htaccess" -printf '%TY-%Tm-%Td %p\n'

افتح كل ملف وابحث عن قواعد مدسوسة، مثل أسطر RewriteCond %{HTTP_REFERER} أو HTTP_USER_AGENT التي تعيد التوجيه إلى نطاقات غريبة.

ابحث عن مستخدمين بصلاحية مدير غير معروفين

اعرض جميع المديرين في WordPress. إذا وجدت مديرًا لم تنشئه، فاحذفه وانقل محتواه إلى مستخدم شرعي (صاحب المعرّف 1 في هذا المثال):

cd ~/public_html
wp user list --role=administrator
wp user delete 5 --reassign=1

3. كيف أنظّف موقعًا مخترقًا؟

الخيار A: استرجاع نسخة احتياطية نظيفة (موصى به)

في cPanel، افتح Files > JetBackup 5. استرجع الملفات وقاعدة البيانات معًا من تاريخ يسبق أقدم ملف خبيث عثرت عليه. حتى النسخة الاحتياطية النظيفة ما زالت تحتوي على الثغرة التي استغلها المهاجم، لذلك نفّذ خطوات القسم 4 فور انتهاء الاسترجاع.

الخيار B: التنظيف ملفًا ملفًا

إذا لم تتوفر نسخة احتياطية نظيفة، فاستبدل الأكواد بنسخ جديدة من المصادر الرسمية. تعيد هذه الأوامر تثبيت ملفات WordPress الأساسية دون المساس بمجلد wp-content، وتعيد تثبيت إضافة، ثم تتحقق من كل ملف بمقارنته بقيم checksums الرسمية:

cd ~/public_html
wp core download --force --skip-content
wp plugin install plugin-slug --force
wp core verify-checksums
wp plugin verify-checksums --all

بعد ذلك أكمل التنظيف:

• أعد تثبيت القوالب من مصدرها الرسمي.
• احذف كل ملفات PHP الموجودة في uploads.
• احذف أي كود مدسوس في أعلى ملف wp-config.php.
• احذف الملفات التي يُبلغ عنها verify-checksums بأنها "should not exist".
• احذف وسوم <script> المدسوسة في المقالات وفي الإعدادات (options) داخل قاعدة البيانات.

4. كيف أمنع اختراق موقعي مرة أخرى؟

التنظيف يزيل البرمجيات الخبيثة، لكنه لا يزيل الثغرة التي استغلها المهاجم. اتبع هذه الخطوات لإغلاقها:

• حدّث ملفات WordPress الأساسية وجميع الإضافات وجميع القوالب باستخدام wp core update وwp plugin update --all.
• احذف الإضافات والقوالب التي لا تستخدمها، بما فيها غير المفعّلة.
• فعّل المصادقة الثنائية لمديري WordPress ولحساب cPanel (Security > Two-Factor Authentication).
• أعد ضبط صلاحيات الملفات لتصبح صلاحيات المجلدات 755، والملفات 644، وملف wp-config.php بصلاحية 600.

لإعادة ضبط الصلاحيات، نفّذ:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 ~/public_html/wp-config.php

وأخيرًا، امنع تشغيل PHP داخل مجلد uploads. أنشئ الملف wp-content/uploads/.htaccess بالمحتوى التالي:

<FilesMatch "\.(?i:php[0-9]?|phtml|phar)$">
  Require all denied
</FilesMatch>

بعد الانتهاء من كل شيء، احذف أسطر وضع الصيانة من ملف .htaccess الرئيسي.

5. كيف أزيل تحذير Google بأن الموقع مخترق؟

في Google Search Console، اذهب إلى Security & Manual Actions > Security issues. أكّد أنك أصلحت المشكلات المذكورة، ثم اضغط Request Review. اكتب وصفًا مختصرًا لما نظّفته وكيف أغلقت الثغرة. تستغرق المراجعة عادةً من بضعة أيام إلى أسبوعين تقريبًا.

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

التحقق من نجاح الإصلاح

• شغّل فحصًا جديدًا في Imunify360. يجب ألا يُظهر أي ملفات مصابة.
• تأكد من أن الأمرين wp core verify-checksums وwp plugin verify-checksums --all يُبلغان بالنجاح.
• افتح الموقع من شبكة هاتف محمول ومن إحدى نتائج بحث Google. يجب ألا تحدث أي إعادة توجيه.
• بعد 48 ساعة، أعد تنفيذ البحث عن الملفات الوارد في القسم 2. كرّر الفحص find ... -mtime -2، وتأكد من عدم ظهور ملفات PHP جديدة في uploads.
• راجع Email > Track Delivery للتأكد من عدم وجود رسائل صادرة غير متوقعة.

المشكلات الشائعة

• يُصاب الموقع مجددًا خلال أيام. هناك باب خلفي أو مهمة cron لم تُكتشف، أو ما زالت إضافة بها ثغرة مثبتة. أعد مراجعة مهام cron، والمواقع الأخرى في الحساب نفسه، ومجلد uploads، والملفات المعدّلة مؤخرًا. تأكد من تحديث كل إضافة أو حذفها.
• عُلِّق الحساب بسبب إرسال سبام. افتح تذكرة دعم ليوضح لك فريق الدعم مصدر الرسائل المرسلة. بعد ذلك أعد تعيين كل كلمات مرور البريد، واحذف إعادات التوجيه (forwarders) غير المعروفة، واحذف سكربت الإرسال، ثم اطلب رفع التعليق عن الحساب.
• يتعطل الموقع بعد التنظيف بواسطة Imunify360. كان الملف المصاب ملفًا أصليًا من إحدى الإضافات أو القوالب. أعد تثبيت تلك الإضافة أو القالب من مصدره الرسمي.
• ما زال تحذير Google ظاهرًا. إما أن المراجعة ما زالت قيد الانتظار، أو أنها رُفضت. راجع تقرير Security issues لمعرفة عناوين URL المتبقية، ونظّفها، ثم اطلب مراجعة جديدة.

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

هل يزيل Imunify360 البرمجيات الخبيثة تلقائيًا؟

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

هل يكفي استرجاع نسخة احتياطية لإصلاح الاختراق؟

لا. النسخة الاحتياطية تزيل البرمجيات الخبيثة، لكن الثغرة تعود معها. حدّث كل شيء وغيّر جميع كلمات المرور فور الانتهاء من الاسترجاع.

ما مدى قِدم النسخة الاحتياطية النظيفة التي يجب أن أختارها؟

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

تحتاج إلى مساعدة؟ افتح تذكرة دعم من https://cloudesta.com/submitticket.php، واذكر فيها نطاقك وما توصلت إليه حتى الآن.