اكتشاف وإزالة الاختراق والبرمجيات الخبيثة

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

كيف تعرف أن موقعك مخترَق فعلًا؟

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

علامات الإصابة الشائعة

الجدول التالي يربط أبرز العلامات بما تعنيه عادةً، لتقرأ الأعراض بسرعة وتوجّه فحصك:

تأكيد الإصابة قبل التنظيف

قبل أن تبدأ، ثبّت الحقائق. سجّل ما رأيته بالضبط: ما العَرَض، ومتى ظهر أول مرّة، وعلى أي صفحات. استخدم أداة فحص خارجية محايدة (تفحص الموقع كما يراه الزائر) لتأكيد وجود حقن أو إدراج في قوائم الحظر. تحقّق من Google Search Console وحساب Bing Webmaster. وافحص ملفات الوصول (Access Logs) في الاستضافة بحثًا عن طلبات مشبوهة أو ارتفاع غير معتاد. هذا التوثيق ليس بيروقراطية: تاريخ أول إصابة سيحدّد أي نسخة احتياطية ما زالت نظيفة، ونمط الطلبات قد يكشف ثغرة الدخول مبكّرًا.

ما أنواع البرمجيات الخبيثة التي تصيب المواقع؟

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

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

ما خطوات الاستجابة بالترتيب الصحيح؟

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

الخطوة 1–2: التأكيد ثم العزل

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

الخطوة 3: خذ نسخة للأدلّة قبل أي تعديل

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

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

كيف تفحص موقعك فحصًا شاملًا؟

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

أدوات الفحص المتاحة

تنوّع الأدوات يكشف ما تفوّته أداة واحدة. الجدول التالي يقارن الفئات الشائعة:

أماكن الاختباء الشائعة

اعرف خريطة المخابئ لتعرف أين توجّه فحصك. الجدول التالي يحصر المواضع المتكرّرة:

فحص الملفات بحثًا عن أنماط مشبوهة

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

# البحث عن دوال يكثر إساءة استخدامها (مرشّحون للمراجعة فقط)
grep -rEn "base64_decode|eval\(|gzinflate|str_rot13|assert\(|create_function" /path/to/site/

# ملفات PHP داخل مجلد الرفع — لا يُفترض وجودها أصلًا
find /path/to/site/wp-content/uploads/ -type f -name "*.php"

# الملفات المعدّلة خلال آخر 7 أيام (قارنها بآخر مرّة لمست فيها الموقع)
find /path/to/site/ -type f -name "*.php" -mtime -7

# ملفات حديثة جدًّا قد تكون مزروعة خلال الاختراق
find /path/to/site/ -type f -mtime -2 -ls

مقارنة الملفات بنسخة نظيفة

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

# نزّل نسخة النواة الرسمية لنفس الإصدار إلى مجلد منفصل، ثم قارن
diff -rq /path/to/clean-core/ /path/to/site/ | grep -E "differ|Only in /path/to/site"

# فحص ملف مشبوه بعينه قبل أي قرار
diff /path/to/clean-core/wp-settings.php /path/to/site/wp-settings.php

فحص قاعدة البيانات والمهامّ المجدولة

قاعدة البيانات مخبأ يُغفَل كثيرًا. ابحث في جدول wp_options (خصوصًا قيم مثل siteurl وhome التي قد تُحقَن) وفي wp_posts عن سكربتات أو إطارات iframe أو روابط خارجية مخفية. وراجع المهامّ المجدولة بدقّة: مهمّة cron خبيثة قد تعيد زرع كل شيء بعد ساعة من تنظيفك. افحص كلًّا من cron الخادم وجدولة ووردبريس الداخلية (WP-Cron):

# مهامّ cron الخادم للمستخدم الحالي (راجع أي سطر غريب)
crontab -l

# مهامّ النظام المجدولة (راجعها للقراءة فقط)
ls -la /etc/cron.* 2>/dev/null

# عبر WP-CLI: استعرض المهامّ المجدولة في ووردبريس
wp cron event list

كيف تنظّف الموقع: تنظيف يدوي أم استعادة نظيفة؟

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

المسار الموصى به: الاستعادة من نسخة نظيفة

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

المسار اليدوي: متى ولماذا بحذر

تلجأ للتنظيف اليدوي إن لم تملك نسخة نظيفة موثوقة، أو كانت الإصابة محدودة ومعروفة الموضع تمامًا. الأساس فيه هو الاستبدال لا الترقيع: استبدل ملفات النواة والإضافات والقوالب بنسخ أصلية كاملة من المصادر الرسمية بدل محاولة "إصلاح" الملفات المحقونة سطرًا سطرًا. أمّا الملفات التي لا بديل رسمي لها (مثل wp-config.php وقاعدة البيانات)، فنظّفها بحذر شديد بعد فهم كل تعديل. والقاعدة الحاكمة: لا تعلن النجاح حتى تتأكّد من إزالة كل الأبواب الخلفية والمهامّ المجدولة الخبيثة، فهي السبب الأول في تكرار الإصابة. عند أدنى شكّ، عد إلى مسار الاستعادة النظيفة.

كيف تسدّ ثغرة الدخول؟

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

تشخيص الناقل يبدأ من الأدلّة التي جمعتها: تاريخ أول ملف مصاب، سجلّات الوصول حول ذلك الوقت، والمكوّن الذي تركّزت فيه الإصابة. إن كانت كل الملفات المحقونة تتبع إضافة بعينها، فهي المشتبه الأول. وإن سبق الحقنَ سيلُ محاولات دخول في السجلّات، فالناقل غالبًا كلمة مرور. لا تخمّن وتمضِ؛ النقطة التي لا تسدّها هي التي يعود منها. وإذا كنت على لوحة cPanel، فراجع دليل تأمين لوحة cPanel فقد يكون الناقل على مستوى الحساب لا ووردبريس وحده.

كيف تعيد تعيين كل بيانات الدخول والمفاتيح؟

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

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

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

كيف ترفع الحظر من Google والقوائم السوداء؟

إذا أدرج جوجل موقعك ضمن "موقع خادع" أو ظهر تحذير في المتصفّح، فالمرور ينهار حتى بعد التنظيف، لأن الإدراج لا يُرفع تلقائيًّا. عليك طلب المراجعة — لكن بعد التأكّد التامّ من نظافة الموقع، فطلب مراجعة على موقع لا يزال مصابًا يُرفض ويؤخّر العملية. اتبع هذه الخطوات:

1. تأكّد من النظافة الكاملة: أعد فحص الموقع بأكثر من أداة، وتأكّد من خلوّ الملفات وقاعدة البيانات والمهامّ المجدولة من أي بقايا.
2. اطلب المراجعة في Google Search Console: من قسم "مشكلات الأمان"، اشرح ما اكتشفته وكيف نظّفته، ثم اطلب المراجعة.
3. افعل المثل في Bing Webmaster Tools إن كان موقعك مدرجًا هناك أيضًا.
4. اطلب الإزالة من قوائم الحظر الأخرى: بعض الخدمات تدرج النطاقات الموبوءة بشكل مستقلّ عن جوجل؛ تحقّق عبر أدوات فحص السمعة وقدّم طلب إزالة لكلٍّ منها.
5. عالج سبام البريد: إن كان خادمك يُرسل سبامًا، فقد يُدرَج نطاقك في قوائم الحظر البريدية (Blacklists). بعد إيقاف المصدر، اطلب الإزالة وفعّل سجلّات SPF وDKIM وDMARC لاستعادة سمعة الإرسال.

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

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

كيف تحصّن الموقع لمنع تكرار الاختراق؟

التنظيف يعيدك إلى نقطة الصفر؛ التحصين يمنعك من العودة إليها. الموقع الذي اختُرق مرّة هدف مغرٍ لتكرار المحاولة، فالمهاجمون يحتفظون بقوائم بالمواقع التي سبق اختراقها. ابنِ طبقات دفاع متراكمة، كل منها يشتري وقتًا ويرفع كلفة الاختراق.

طبقات الحماية الأساسية

الجدول التالي يلخّص أعمدة التحصين بعد التنظيف:

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

النسخ الاحتياطي بوصفه خطّة تعافٍ

الدرس الأهمّ من هذه التجربة كلّها: نسخة احتياطية نظيفة كانت ستحوّل الكارثة إلى حادث عابر. اعتمد قاعدة 3-2-1 (ثلاث نسخ، على وسيطين، واحدة خارج الموقع)، وأتمِت النسخ ليرتفع تلقائيًّا إلى تخزين خارجي منفصل عن الخادم. والأهمّ: احتفظ بسلسلة نسخ تعود لعدّة أسابيع، فالاختراق الصامت يجعل آخر نسخة مصابة أحيانًا، وتحتاج نقطة استعادة نظيفة أقدم. واختبر الاستعادة دوريًّا — نسخة لم تُختبَر استعادتها = لا نسخة.

للحماية على مستوى الشبكة قبل وصول المرور لخادمك، تضيف طبقة CDN/WAF سحابية دفاعًا مهمًّا ضدّ الهجمات الآلية وهجمات الحجب الموزّع. راجع الحماية من DDoS لفهم هذه الطبقة، وكيف تتكامل مع تحصين ووردبريس.

قائمة التحقّق بعد التنظيف

قبل أن تعلن أن الموقع نظيف وآمن، راجع كل بند:

مشاكل وحلول شائعة بعد التنظيف

حتى بعد عمل دقيق، قد تظهر مشاكل متبقّية. الجدول التالي يربط الأعراض بأسبابها وحلولها:

متى تستعين بمحترف؟

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

نصائح خبير لاستجابة أنظف

بعد إتقان الأساسيات، ارفع جاهزيتك بهذه الممارسات:

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

الخلاصة

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

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

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

كيف أعرف بسرعة أن موقعي مخترَق؟ أبرز العلامات: تحذير المتصفّح أو Google من "موقع خادع/خطِر"، إعادة توجيه غريبة للزائر (خصوصًا القادم من نتائج البحث)، ظهور صفحات أو منشورات سبام، بطء أو حمل CPU مرتفع غير مبرَّر، رسالة من شركة الاستضافة، حسابات مدير لم تنشئها، أو دخول بريد موقعك في السبام. أكّد الشكّ بأداة فحص خارجية محايدة وبتقرير Google Search Console قبل أن تبدأ أي تنظيف.

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

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

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

هل يكفي تغيير كلمة مرور ووردبريس؟ لا إطلاقًا. المهاجم الذي وصل لملفاتك رأى wp-config.php بكل أسراره. أعد تعيين كل شيء: كلمات مرور كل المستخدمين، وقاعدة البيانات، والاستضافة/cPanel، وFTP/SSH، ومفاتيح API، وولّد salts جديدة في wp-config.php لإبطال كل الجلسات النشطة فورًا وطرد المهاجم حتى لو كان مسجّلًا دخوله.

كيف أرفع تحذير "موقع خادع" من Google؟ بعد التأكّد التامّ من نظافة الموقع (ملفات وقاعدة بيانات ومهامّ مجدولة)، اذهب إلى قسم "مشكلات الأمان" في Google Search Console واطلب المراجعة موضّحًا ما اكتشفته وكيف نظّفته. لا تطلب المراجعة على موقع لا يزال مصابًا فسيُرفض ويتأخّر. قد تستغرق المراجعة من ساعات إلى أيام.

أين يختبئ الكود الخبيث عادةً؟ في مواضع متعدّدة معًا غالبًا: ملفات النواة المعدّلة، ملفات PHP المزروعة في مجلد الرفع، functions.php ورأس القالب، ملف .htaccess (إعادة توجيه)، وداخل قاعدة البيانات (جداول الخيارات والمنشورات)، إضافة إلى المهامّ المجدولة التي تعيد الزرع. لهذا الفحص الشامل لكل هذه المواضع ضروري — تنظيف موضع وترك آخر يعني عودة فورية.

هل تكشف أدوات الفحص كل الإصابات؟ لا أداة مثالية. الفحص الخارجي (مثل Sucuri SiteCheck) يكشف الحقن المرئي والإدراج في قوائم الحظر لكنه لا يرى الملفات. والفحص الداخلي (مثل Wordfence) يقارن بملفات النواة الأصلية ويكشف التعديلات والأبواب الخلفية. الأفضل دمج أكثر من أداة مع مراجعة يدوية ومقارنة الملفات بنسخة نظيفة، فما تفوّته أداة قد تمسكه أخرى.

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

كم يستغرق تنظيف موقع مخترَق؟ يتفاوت كثيرًا: إصابة بسيطة مع نسخة نظيفة جاهزة قد تُحلّ في ساعة أو ساعتين (استعادة + سدّ ثغرة + إعادة تعيين بيانات الدخول). أمّا الإصابة المعقّدة المتوزّعة على الملفات وقاعدة البيانات والمهامّ المجدولة، أو غياب نسخة نظيفة، فقد تستغرق ساعات إلى أيام. لا تتعجّل على حساب الدقّة — تنظيف ناقص يعني عودة الاختراق وبدء العملية من جديد.

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