موقع WordPress مخترق ويعيد التوجيه؟ كيف تكتشف الاختراق وتنظفه وتمنع عودته

إذا كان موقع WordPress الخاص بك يرسل الزوار إلى صفحات مزعجة أو احتيالية أو صفحات “لقد ربحت جائزة”، فقد حقن أحدهم كودًا يعيد توجيههم. ويختبئ هذا الكود عادة في .htaccess، أو في ملف معدَّل من النواة أو القالب أو إحدى الإضافات، أو في قاعدة البيانات. تأكد من الاختراق بأمان، وأحكِم إغلاق كل عمليات تسجيل الدخول، وخذ نسخة احتياطية، وأزل الكود والطريق الذي دخل منه المهاجم، ثم اطلب من Google إزالة أي تحذير.

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

علامات وجود اختراق إعادة توجيه في موقع WordPress

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

• يبلّغ زوار أو عملاء أو زملاء عن وصولهم إلى موقع مختلف، خاصة من نتائج Google أو على هواتفهم.
• تعرض Google عبارة “This site may be hacked” أو تحذيرًا أحمر في المتصفح، أو يبلّغ Search Console عن مشكلة في Security issues.
• تُظهر نتائج البحث عن نطاقك عناوين مزعجة، أو صفحات بلغات أجنبية، أو روابط لم تنشئها أبدًا.
• يوجد مستخدمو مدير لا تعرفهم، أو حصلت حسابات أنشأتها على أدوار جديدة.
• يعلّق مزود الاستضافة الموقع أو يبلّغ عن برمجيات خبيثة، أو تبدأ رسائلك بالوصول إلى الرسائل المزعجة لأن عنوان IP الخادم أُدرج في القوائم السوداء.
• تظهر سكربتات مجهولة في مصدر الصفحة، أو يحدث هبوط مفاجئ في Core Web Vitals دون أي تغيير من جهتك.

تسمي صفحة الأسئلة الشائعة “My site was hacked” في WordPress.org هذه العلامات مؤشرات الاختراق. دوّن أيها تراه ومتى لاحظته أول مرة، فستحتاج إلى ذلك لاحقًا.

مستخدمو مدير أُضيفوا ولم تنشئهم أنت

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

تأكد من إعادة التوجيه دون تعريض جهازك للخطر

توصي Google بعدم فتح الصفحات المشتبه في احتوائها على برمجيات خبيثة في متصفحك المعتاد، لأن البرمجيات الخبيثة كثيرًا ما تنتشر عبر ثغرات المتصفح. ويستخدم دليلها حول المواقع المخترقة ببرمجيات خبيثة أداة curl بدلًا من ذلك، مع إرسال مُحيل (referrer) من Google ووكيل مستخدم (user agent) مختلف لإطلاق عمليات إعادة التوجيه المشروطة. من الطرفية:

# Plain request: look at the status code and any Location header
curl -sI https://example.com/

# Pretend to arrive from Google search
curl -sI --referer "https://www.google.com/" https://example.com/

# Pretend to be a phone arriving from Google
curl -sI --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0 Mobile Safari/537.36" \
  https://example.com/

استجابة 301 أو 302 مع ترويسة Location: تشير إلى نطاق لا تملكه تؤكد وجود إعادة توجيه من جهة الخادم. وإذا كانت كل الاستجابات 200، فقد تكون إعادة التوجيه في JavaScript. اجلب HTML كاملًا (curl -s دون -I) وابحث عن وسوم <script> غير مألوفة، أو eval(، أو atob(، أو window.location قرب أعلى الصفحة أو أسفلها.

وافحص أيضًا تقرير Security Issues في Search Console. تعتبره Google مصدر الحقيقة، ويعرض عينات من الروابط المتأثرة. والعينة ليست كاملة، لذا لا تفترض أن تلك الصفحات وحدها مصابة.

الساعة الأولى: احتوِ الاختراق

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

1. وثّق ما تراه، ومتى، وأي شيء تغيّر مؤخرًا (إضافة جديدة، أو تعديل في القالب، أو مستخدم جديد).
2. أبلغ مزود الاستضافة. في الاستضافة المشتركة، قد تتأثر مواقع أخرى على الخادم نفسه، وقد يكون المزود يتخذ إجراءات بالفعل.
3. التقط نسخة من الملفات وقاعدة البيانات كما هي الآن، رغم أنها مصابة. تحتاج إليها للتحقيق الجنائي الرقمي، وكخطة احتياطية إذا أفسد التنظيف شيئًا ما.
4. أعد تعيين كل صلاحيات الوصول، لا كلمة مرور WordPress فقط: كل مستخدمي WordPress (المدراء أولًا)، و SFTP/FTP، ولوحة تحكم الاستضافة (cPanel أو ما يشبهها)، ومستخدم قاعدة البيانات. استخدم كلمات مرور طويلة وفريدة وفعّل المصادقة الثنائية.
5. سجّل خروج الجميع عبر استبدال المفاتيح السرية (salts) في wp-config.php بمجموعة جديدة من مولّد المفاتيح في WordPress.org.
6. افحص جهازك أنت. تشير صفحة الأسئلة الشائعة إلى أن بعض الإصابات تبدأ بكلمات مرور FTP أو مدير مسروقة من جهاز صاحب الموقع.

أين يختبئ كود إعادة التوجيه عادة

إذا كان لديك SSH و WP-CLI، فهذه الأوامر تغطي معظم الجدول. شغّلها من جذر WordPress:

# Core files that don't match WordPress.org's checksums
wp core verify-checksums

# Plugins from the WordPress.org directory that were modified
wp plugin verify-checksums --all

# Who has admin rights?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Has the site address been changed?
wp option get siteurl
wp option get home

# Script tags hidden in the database
wp db search "<script" --all-tables

# PHP files in the uploads folder (there should normally be none)
find wp-content/uploads -name "*.php"

هناك حدّان يجب معرفتهما: الأمر plugin verify-checksums لا يفحص إلا الإضافات المستضافة على WordPress.org، لذا تحتاج الإضافات والقوالب المدفوعة إلى مقارنتها بنسخة جديدة من المزوّد. والأمر db search سيجد أيضًا سكربتات مشروعة (أكواد التتبع، والعناصر المضمّنة)، لذا اقرأ كل نتيجة قبل حذف أي شيء.

لا يوجد SSH؟ استخدم مدير الملفات في لوحة الاستضافة أو SFTP للملفات، و phpMyAdmin لقاعدة البيانات. إنه أبطأ، لكن أماكن البحث هي نفسها.

نظّفه خطوة بخطوة

1. استبدل نواة WordPress. نزّل الإصدار نفسه الذي تشغّله من WordPress.org، واستبدل /wp-admin و /wp-includes بالكامل عبر SFTP. تنصح صفحة الأسئلة الشائعة بعدم استخدام زر إعادة التثبيت في لوحة التحكم، لأنه يستبدل الملفات الموجودة لكنه لا يحذف الملفات الجديدة التي أضافها المهاجم.
2. استبدل الإضافات والقوالب بنسخ نظيفة من WordPress.org أو من المزوّد. واحذف أي إضافة أو قالب لا تستخدمه بدلًا من تنظيفه.
3. استعد ملف .htaccess نظيفًا لا يحتوي إلا على القواعد التي تحتاجها، وافحص المجلدات الفرعية بحثًا عن ملفات .htaccess إضافية.
4. نظّف wp-config.php: قارنه سطرًا بسطر مع wp-config-sample.php واحتفظ بإعداداتك الحقيقية فقط.
5. نظّف قاعدة البيانات: أصلح siteurl و home، وأزل السكربتات المحقونة، واحذف المدراء المجهولين (بعد تسجيل بياناتهم).
6. احذف ملفات PHP من مجلد uploads وأي إضافات إلزامية (must-use) لم تثبّتها.
7. حدّث كل شيء إلى أحدث الإصدارات: النواة، والإضافات، والقوالب، و PHP.
8. غيّر كل كلمات المرور والمفاتيح السرية مرة أخرى. فقد تكون إعادة التعيين الأولى حدثت والمهاجم ما زال يملك بابًا خلفيًا.
9. أعد تشغيل فحوصات curl وفحصًا للبرمجيات الخبيثة، ثم راقب الموقع لبضعة أيام.

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

أزل تحذير Google

لا تختفي التحذيرات من تلقاء نفسها بعد التنظيف. يسرد دليل Google لطلب المراجعة الشروط المسبقة: أن يكون الموقع موثقًا في Search Console، ومنظفًا، وأن تكون الثغرة قد أُصلحت، وأن يكون الموقع متاحًا مجددًا. ثم:

1. أعد فحص صفحتك الرئيسية والروابط النموذجية عبر curl. يجب أن تعيد كلها استجابات نظيفة.
2. افتح Security issues في Search Console واختر Request review.
3. اشرح ما كان خاطئًا، وما الذي أزلته، وكيف أغلقت الثغرة (مثلًا: “أزلنا قواعد إعادة التوجيه من .htaccess، واستبدلنا ملفات النواة والإضافات، وحذفنا حساب مدير مجهولًا، وحدّثنا إضافة قديمة”).

لا تطلب المراجعة إلا عندما تكون متأكدًا. فـ Google تشير إلى أن طلبها والمشكلة ما زالت قائمة لا يؤدي إلا إلى إطالة مدة بقاء موقعك موسومًا.

لماذا يُخترق WordPress مجددًا، وكيف توقف ذلك

“اختُرق مجددًا” تعني دائمًا تقريبًا أن التنظيف أزال العَرَض لا طريق الدخول: ملف باب خلفي تُرك، أو حساب مدير ثانٍ، أو كلمة مرور مُعاد استخدامها، أو مفاتيح سرية لم تتغير، أو الإضافة القديمة نفسها. ويغطي دليل التحصين في WordPress الإصلاحات التي تسد هذه الثغرات:

• أبقِ كل شيء محدّثًا واحذف الإضافات والقوالب التي لا تستخدمها.
• عطّل محرر الملفات المدمج حتى لا يمكن استخدام تسجيل دخول مدير مسروق لتعديل PHP من لوحة التحكم. أضف هذا إلى wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

• أقل قدر من الصلاحيات. امنح الأشخاص والأدوات الدور الذي يحتاجونه فقط. يجب أن يكون عدد المدراء قليلًا، وأن تستخدم التكاملات كلمات مرور تطبيقات محدودة النطاق للأدوات ووكلاء الذكاء الاصطناعي بدلًا من كلمة مرور مدير.
• المصادقة الثنائية لكل حساب يستطيع النشر أو تثبيت أي شيء.
• SFTP لا FTP، حتى لا تُرسل كلمات المرور كنص صريح.
• جدار حماية لتطبيقات الويب (WAF)، على مستوى الخادم، أو كإضافة، أو كخدمة وكيلة أمام الموقع.
• نسخ احتياطية خارجية يمكنك الوثوق بها: لقطات منتظمة للملفات وقاعدة البيانات، يُحتفظ بها مدة كافية حتى تبقى لديك نسخة سابقة للإصابة إذا ظل الاختراق غير مكتشف لأسابيع.
• المراقبة: تنبيهات تغيّر الملفات وفحوصات وقت التشغيل، حتى تعلم بملف جديد أو إعادة توجيه غير متوقعة خلال دقائق، لا عندما يشتكي عميل.

هذا أكثر جزء أهتم به في عملي في الاستضافة. أنظّف مواقع WordPress المخترقة، ثم أغلق الثغرة التي سمحت للمهاجم بالدخول، وأدير خوادم cPanel و VPS مع تحصين ومراقبة مدمجين، محافظًا على وقت تشغيل بنسبة 99.9% عبر البنية التحتية المُدارة. وإذا أردت معرفة وضع إعدادك أنت، فابدأ بـ فحص مجاني لسلامة الموقع وسرعته ضمن تدقيق MarTech الذي أقدمه. وللصورة الأوسع، إليك فحص الأمان والأداء الذي يمكنك تطبيقه على المنظومة كاملة.

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

كيف أفحص عمليات إعادة التوجيه في موقع WordPress؟

اطلب صفحاتك عبر curl -sI، مع مُحيل من Google ووكيل مستخدم للجوال وبدونهما، وابحث عن استجابات 301/302 تشير إلى نطاقات أخرى. ثم افحص ملفات .htaccess وقواعد أي إضافة لإعادة التوجيه بحثًا عن مدخلات لم تضفها.

هل يمكن أن تصاب ببرمجيات خبيثة من إعادة توجيه؟

إعادة التوجيه نفسها ترسلك إلى موقع آخر، وذلك الموقع قد يحاول تثبيت برمجيات خبيثة أو سرقة بياناتك بالتصيد. ولهذا تنصح Google بفحص الصفحات المخترقة بأدوات مثل curl بدلًا من متصفح عادي.

هل تزيل إضافة الأمان الاختراق؟

يساعدك الماسح في العثور على الملفات المصابة، ويوصي WordPress.org بالجمع بين ماسح قائم على إضافة وآخر عن بُعد. لكن لا أحد منهما يحل محل الخطوات اليدوية: إعادة تعيين صلاحيات الوصول، واستبدال ملفات النواة والإضافات، وإصلاح الثغرة التي سمحت للمهاجم بالدخول.

لماذا تحدث إعادة التوجيه على الجوال أو من Google فقط؟

يستهدف المهاجمون الزوار القادمين من البحث ويتجنبون صاحب الموقع (الذي يكون عادة مسجّل الدخول، على سطح المكتب، ويكتب الرابط مباشرة). وهذا يُبقي الاختراق يعمل مدة أطول قبل أن يلاحظه أحد.