لقد تلقيت مؤخرًا المزيد من مشاريع تنظيف WordPress بنفس النمط العام:
هذا هو السبب الرئيسي وراء رغبتي في كتابة هذا المقال: مثل هذه الحالات لم تعد نادرة.
أظل أرى نفس النمط يتكرر. في أحد حسابات الاستضافة، يتم اختراق أحد مواقع الويب أولاً، ثم تبدأ مواقع الويب الأخرى الموجودة في نفس البيئة في إظهار أعراض مشابهة. وفي حالات أخرى، تظل الصفحة الرئيسية تبدو “طبيعية”، لكن الملفات الغريبة تستمر في الظهور مرة أخرى في مدير الملفات. لقد رأيت أيضًا السيناريو الأسوأ: تعرض قاعدة البيانات للتلف أو الضياع، ولا توجد نسخة احتياطية نظيفة، ويجب إعادة بناء موقع الويب من الصفر.
ولهذا السبب لا أريد أن يُقرأ هذا كمقال أمني عام. أريد أن أتناول الأمر من زاوية أكثر عملية:
إذا كان موقع الويب الخاص بك يظهر بالفعل علامات مثل عمليات إعادة التوجيه الغريبة، أو صفحات المقامرة في Google، أو فهرسة البريد العشوائي الياباني، أو الملفات المشبوهة التي تعود باستمرار، فتابع مع كيف تدخل البرامج الضارة إلى موقع WordPress، 7 علامات على أن موقع WordPress الخاص بك مصاب ببرامج ضارة وكيفية إصلاحها، أو انتقل مباشرة إلى خدمة إزالة البرامج الضارة في WordPress إذا كنت بحاجة إلى مساعدة فورية.
ولجعل هذا الأمر أكثر وضوحًا، إليك نوعان من الحالات التي ظهرت مؤخرًا. أنا أعيد كتابتها بشكل أكثر مجهولة، لكن الأنماط حقيقية.
في إحدى الحالات، احتوى حساب استضافة واحد على ثلاثة مواقع WordPress.
لقد تم بالفعل إعادة تعيين أسوأ ما في الأمر على مستوى WordPress وقاعدة البيانات. من الناحية السطحية، بدا الموقع نظيفًا وأُعيد بناؤه حديثًا، لكنه كان يتحول كل ليلة حوالي منتصف الليل إلى موقع إلكتروني للمقامرة. وفي الوقت نفسه، كانت فهرسة Google ملوثة بالفعل، بما في ذلك عناوين نتائج البحث والأيقونات المفضلة.
أظهر موقع الويب الثاني في نفس الحساب عرضًا مختلفًا: استمر ظهور مجلد مشبوه بنفس الاسم حتى بعد حذفه.
لا يزال موقع الويب الثالث يبدو حيًا نسبيًا، ولكن استمرت إضافة ملفات غريبة في مدير الملفات على الرغم من إزالة الصفحة التي تم اختراقها بشكل واضح.
بالنسبة لي، يظهر نمط كهذا بوضوح أن المشكلة ليست مجرد ملف واحد تالف. هذه بالفعل مشكلة بيئة استضافة واستمرارية على مستوى أوسع.
وهناك حالة أخرى كانت أكثر إثارة للقلق من منظور النطاق.
لقد بدأ الأمر بسؤال بسيط “هل يمكنك التحقق من هذا؟” طلب. ولكن مع استمرار المحادثة، اتضح أن هناك ما يقرب من 4 أو 5 مواقع بها مشكلات مماثلة داخل بيئات الاستضافة ذات الصلة.
وهذا أمر مهم لأن العديد من مالكي مواقع الويب ما زالوا يعتقدون أن البرامج الضارة تمثل مشكلة موقع ويب واحدة، وتتكرر مرة واحدة. ومن الناحية العملية، كثيرا ما أرى أن العدوى تظهر في مجموعات.
إذا تم اختراق أحد مواقع الويب بالفعل، فهناك احتمال حقيقي أن يتم أيضًا كشف موقع ويب آخر في نفس البيئة، حتى لو لم تظهر الأعراض بعد.
إذا قمت بتلخيص المشاريع الأخيرة التي جاءت، فإن النمط عادة ما يبدو كالتالي:
في بعض الحالات، يضع العملاء العديد من مواقع WordPress ضمن حساب الاستضافة نفسه.
على السطح، يبدو ذلك فعالاً. حساب واحد، مواقع متعددة، تكلفة أقل.
ولكن بمجرد اختراق أحد مواقع الويب، فإن الخطر لا يتوقف عند هذا الحد. يمكن أن تصبح مواقع الويب الأخرى الموجودة في نفس الحساب أو البيئة مكشوفة أيضًا، خاصة إذا كان العزل ضعيفًا أو كان الوصول إلى الملفات فضفاضًا للغاية.
ولهذا السبب غالبًا ما تبدو حالات البرامج الضارة في البيئات المشتركة غريبة. يعتقد العميل أن موقع ويب واحدًا فقط هو المتأثر، بينما في الواقع قد يكون أكثر من موقع ويب واحد مكشوفًا بالفعل أو في قائمة الانتظار للاستغلال.
يعد هذا أحد أكثر الأعراض المحبطة التي يواجهها أصحاب مواقع الويب.
يتم حذف ملف أو مجلد غريب اليوم، ثم غدًا أو في اليوم التالي يظهر مرة أخرى. في بعض الأحيان يكون اسم المجلد هو نفسه. في بعض الأحيان تظهر الملفات في أماكن مختلفة. في بعض الأحيان تبدو الصفحة الرئيسية نظيفة، ولكن الثبات لا يزال نشطًا في الخلفية.
بالنسبة لي، عادة ما يعني هذا العرض شيئًا واحدًا: لم يتم العثور على مصدر العدوى الحقيقي بعد.
تمت إزالة العرض فقط، وليس جذر المشكلة.
قد يعني ذلك أنه لا يزال هناك:
لقد رأيت أيضًا نمطًا مزعجًا للغاية مثل هذا:
تتم إعادة تعيين موقع الويب، وإعادة تثبيت WordPress، وتنظيف قاعدة البيانات، وتبدو الصفحة الرئيسية طبيعية، ولكن في وقت معين يتحول موقع الويب مرة أخرى إلى موقع للمقامرة.
وبمجرد وصول الأمر إلى هذه المرحلة، فمن المؤكد تقريبًا أن المشكلة لن تكون مجرد “ملف واحد مشبوه”.
هناك بعض آليات الثبات التي تم وضعها عمدًا حتى تتمكن العدوى من إعادة تنشيطها بعد تنظيف مستوى السطح. ولهذا السبب كثيرًا ما أذكّر العملاء بأن إعادة تثبيت WordPress وحدها لا تحل المشكلة تلقائيًا.
إذا لم يتم قطع نقطة الدخول وطبقة الثبات، فيمكن أن يبدو موقع الويب مستعادًا للحظة ثم يتعطل مرة أخرى.
يشعر العديد من الأشخاص بالذعر فقط عندما تتغير الصفحة الرئيسية أو يبدأ الموقع في إعادة التوجيه.
لكن الضرر الأكبر غالبًا ما يكون موجودًا بالفعل داخل نتائج بحث Google.
لقد رأيت حالات حيث:
وفي تلك المرحلة، لم تعد المشكلة تتعلق بالأمن فقط. لقد تم بالفعل تلف مُحسّنات محرّكات البحث (SEO) أيضًا.
وبمجرد استبدال الفهرس الشرعي بالبريد العشوائي، لا يكون الاسترداد فوريًا دائمًا. وحتى بعد تنظيف الملفات، لا تزال الآثار المتبقية في بحث Google بحاجة إلى التعامل معها واحدًا تلو الآخر.
من وجهة نظري، لا يزال العديد من مالكي مواقع الويب يعتبرون البرامج الضارة مصدر إزعاج تقني.
لكن في أسوأ الحالات، تكون الخسارة أخطر من ذلك بكثير.
الضرر الذي أقلق بشأنه ليس فقط:
ولكن أيضًا:
عندما يختفي موقع ويب تجاري، عادةً ما يأتي الضرر من كلا الاتجاهين في وقت واحد:
وإذا حدثت عملية إعادة البناء هذه في حالة من الذعر، فإنها غالبا ما تكون أكثر تكلفة من العمل الوقائي الذي كان من الممكن القيام به قبل ذلك بكثير.
هذا هو واحد من المفاهيم الخاطئة الأكثر شيوعا.
بمجرد أن يرى الأشخاص ملفًا مشبوهًا في مدير الملفات، يميلون إلى التفكير:
“إذا قمت بحذف هذا الملف، فستنتهي المشكلة.”
ولسوء الحظ، فإن هذا لا يكفي في كثير من الحالات.
نادرًا ما تعتمد البرامج الضارة الحديثة في WordPress على ملف واحد واضح. يمكن أن يترك آثارًا في العديد من الأماكن:
.htaccess،إذا تم حذف ملف واحد ولكن نقطة الإدخال الأصلية لا تزال مفتوحة، فيمكن للمهاجم العودة أو يمكن للبرنامج النصي المتبقي استعادة نفس الإصابة.
ولهذا السبب عادةً ما أكون حذرًا جدًا مع مواقع الويب التي يقول الناس إنها “تم تنظيفها بالفعل عدة مرات”، ولكن الأعراض نفسها تستمر في العودة. عادةً لا تكمن المشكلة في أن الاستضافة “غريبة”. تكمن المشكلة في أن عملية التنظيف السابقة لم تغطي مطلقًا سطح الهجوم بالكامل.
أتفهم الرغبة في إصلاح أي شيء يبدو خاطئًا في أسرع وقت ممكن عندما يكون الموقع في حالة من الفوضى. ولكن هناك العديد من ردود الفعل التي غالبًا ما تجعل التعافي من الموقف أكثر صعوبة:
إذا كان مسار الوصول الأصلي لا يزال مفتوحًا أو كان الباب الخلفي مخفيًا في مكان آخر، فإن إعادة تثبيت WordPress تؤدي فقط إلى تنظيف السطح المرئي.
إذا كان الملف الضار معزولًا بالفعل، فقد يبدو أن هذا يعمل لفترة من الوقت. ولكن إذا كانت المشكلة الفعلية موجودة في المستخدمين الإداريين أو قاعدة البيانات أو المهام المجدولة أو موقع آخر داخل نفس حساب الاستضافة، فستعود الإصابة.
هذا فخ شائع. يشعر العميل بالأمان بسبب وجود نسخة احتياطية، ولكن تم إنشاء هذه النسخة الاحتياطية بعد دخول العدوى إلى النظام بالفعل.
والنتيجة يمكن التنبؤ بها: يبدو أن الموقع قد تم ترميمه، ثم تعود الأعراض.
إذا قمت بتغيير كلمة مرور WordPress ولكنك لم تقم بتدقيق الوصول إلى الاستضافة، وFTP، وبيانات اعتماد قاعدة البيانات، وحسابات الإدارة الأخرى، فأنت لم تغلق الباب حقًا.
تختلف كل حالة عن الأخرى، ولكن بشكل عام يبدو النهج الذي أتبعه عادةً كما يلي:
إذا كانت هناك عدة مواقع ويب موجودة تحت نفس حساب الاستضافة، فعادةً ما أتعامل معها جميعًا على أنها مشبوهة أولاً.
وهذا أمر مهم، لأن تنظيف موقع واحد مع ترك موقع آخر مصابًا غالبًا ما يؤدي إلى حدوث حلقة حيث تستمر نفس المشكلة في العودة.
عادة أريد أن أعرف:
وبدون ذلك، غالبًا ما تتحول عملية التنظيف إلى حذف عشوائي للملفات دون توجيه.
نادرًا ما يكون التنظيف المناسب مجرد مهمة مدير ملفات.
تشمل المناطق التي تحتاج غالبًا إلى الفحص ما يلي:
إذا تمت فهرسة صفحات البريد العشوائي أو صفحات المقامرة أو صفحات البريد العشوائي اليابانية بالفعل، فلن تنتهي المهمة حتى بعد أن يصبح موقع الويب نظيفًا من الناحية الفنية.
تحتاج فهرسة Google أيضًا إلى الاهتمام.
ولهذا السبب أعتبر أن التنظيف المناسب للبرامج الضارة يتطلب نتيجتين في وقت واحد:
بعد التنظيف، أفضل الانتقال مباشرة إلى الوقاية:
إذا ظلت هذه المشكلات الجذرية في مكانها، فمن الممكن أن يعود نفس موقع الويب بسهولة إلى نفس الحالة بعد بضعة أشهر.
أعلم أن معظم العملاء يركزون على شيء واحد:
“أريد فقط أن يعمل موقع الويب الخاص بي بشكل طبيعي مرة أخرى.”
هذا منطقي. ولكن بمجرد عودة الموقع إلى طبيعته مرة أخرى، يصبح السؤال الأهم:
كيف نمنع حدوث ذلك مرة أخرى؟
في تلك المرحلة، أعتقد أن هناك ثلاثة مجالات هي الأكثر أهمية.
إذا كان موقع WordPress يدعم نشاطًا تجاريًا، فإن الصيانة ليست مهمة إضافية. إنه جزء من طبقة الدفاع الأساسية.
وبالصيانة، لا أقصد فقط النقر على زر التحديث. أعني روتين أكثر اكتمالا:
إذا كنت تريد مسارًا أكثر تنظيمًا، فراجع خدمة صيانة موقع الويب لدينا واقرأ أيضًا لماذا تعد صيانة WordPress مهمة.
إذا كانت عدة مواقع ويب موجودة تحت حساب استضافة واحد وتم اختراق أحدها بالفعل، فإنني أوصي عادةً بإجراء مراجعة جادة للمؤسسة.
هذا لا يعني أن جميع الاستضافة المشتركة تكون سيئة تلقائيًا. الأمر ليس بهذه البساطة.
لكن بالنسبة لموقع ويب تجاري، أشعر براحة أكبر عندما تكون الأساس أكثر انضباطًا:
إذا كنت تريد التفكير بعناية أكبر في جانب الاستضافة من المشكلة، فتابع مع عندما لم يعد موقع الويب الخاص بك يناسب استضافته الحالية أو لماذا يفضل أصحاب الأعمال غالبًا الاستضافة المُدارة على لوحات التحكم.
أغلى الحالات التي رأيتها لم تكن مجرد مواقع ويب مخترقة. لقد كانت مواقع ويب لم يعد من الممكن استعادتها لأن النسخة الاحتياطية لم تكن موجودة أو لم تكن قابلة للاستخدام.
في حالة تلف قاعدة البيانات، والملفات تالفة، وعدم وجود نسخة احتياطية نظيفة، يكون الخيار المتبقي غالبًا هو إعادة البناء.
ولهذا السبب أرى دائمًا أن النسخ الاحتياطية جزء من استراتيجية العمل، وليس قائمة مراجعة فنية.
لو كان علي أن أجيب بجملة واحدة:
لأن المشكلة تأتي عادةً من مزيج من الأساس غير المستقر، والصيانة المتأخرة، وبيئة الاستضافة غير الصحية، وعملية الأمان التي كانت شديدة التفاعل لفترة طويلة جدًا.
عادةً لا يتحول موقع الويب إلى موقع للمقامرة بسبب لحظة دراماتيكية واحدة.
يتحول لأن العديد من الأبواب تركت مفتوحة لفترة طويلة جدا.
وبحلول الوقت الذي يصبح فيه الهجوم مرئيًا على السطح، غالبًا ما يكون الضرر قد انتشر بالفعل إلى:
إذا كان موقع الويب الخاص بك يعرض حاليًا علامات مثل:
فلن أتوقف عند “حذف الملف المشبوه”.
ابدأ بإجابة أكثر اكتمالاً.
أنت تستطيع:
بالنسبة لي، الهدف الحقيقي ليس فقط “جعل الموقع يعمل مرة أخرى اليوم”، ولكن منع موقع الويب الخاص بنشاطك التجاري من البقاء في حالة ضعيفة بشكل دائم.
مؤسس Harun Studio ومطور مواقع ومدوّن ومراجع لاستضافات المواقع. يساعد أصحاب الأعمال على بناء مواقع أكثر صحة من خلال التصميم والتطوير والصيانة طويلة الأمد.
اكتشف رؤى أخرى ترتبط ارتباطًا مباشرًا بهذا الموضوع.
الأمان عادةً ما تعني برامج WordPress الضارة التي تعود بعد التنظيف أن السبب الجذري لم تتم إزالته مطلقًا: باب خلفي متبقي، أو مهمة cron مخفية، أو مستخدم إداري غير معروف، أو مكون إضافي لاغي، أو إعادة توجيه للجوال فقط فاتت أثناء فحص سطح المكتب.
اقرأ المقال
الأمان تعرف على كيفية وصول البرامج الضارة إلى موقع WordPress الخاص بك، بدءًا من المكونات الإضافية المقرصنة وبيانات الاعتماد المسربة وحتى نقاط الضعف في المكونات الإضافية وضعف أمان الخادم.
اقرأ المقال
الأمان تعرف على كيفية التعرف على موقع WordPress المصاب ببرامج ضارة من خلال 7 علامات مخفية وإيجاد طرق فعالة لإصلاحه بسرعة.
اقرأ المقال