كيفية تنظيف موقع WordPress أو مدونة تم اختراقها
نشرت: 2021-02-16سواء تم اختراق موقع WordPress الخاص بك وأنت حاليًا تحت سيطرة الضرر ، أو ما إذا كنت تستعد للأسوأ ، ستوجهك هذه المقالة خلال عملية تنظيف موقع WordPress الذي تم اختراقه. تم توثيق العملية بطريقة سهلة الاتباع خطوة بخطوة لمساعدتك على إنجاز ما يلي:
- استعد السيطرة على موقع WordPress الخاص بك
- حدد المصدر المحتمل للعدوى
- ابحث عن العدوى والشفرة الخبيثة
- قم بإزالة أي برامج ضارة وأبواب خلفية وقذائف ويب
- قم بإزالة نطاقك من أي قوائم برامج ضارة مثل قاعدة بيانات Google Safe Browsing
- منع التكرار
هل موقع WordPress الإلكتروني الخاص بك مخترق حقًا؟
في بعض الأحيان يكون من الواضح تمامًا متى يتم اختراق موقع WordPress ، على سبيل المثال ، إذا تم تشويه موقع الويب الخاص بك. في حالات أخرى ، قد لا يكون الأمر واضحًا للغاية. قبل الشروع في عملية تنظيف WordPress ، تأكد من أن موقع WordPress الخاص بك قد تم اختراقه بالفعل ، وأنه ليس مشكلة فنية غير ذات صلة. اقرأ المقال حول كيفية التحقق مما إذا كان موقع WordPress الخاص بي قد تم اختراقه لتحديد ما إذا كان موقع الويب الخاص بك أو مدونتك قد تم اختراقها أم لا.
استعادة السيطرة
تبدأ استعادة التحكم اعتمادًا على مقدار الوصول الذي قد تفقده نتيجة للهجوم. على سبيل المثال ، عند الوصول إلى خادم ، قد يقوم المهاجم بتدوير بيانات الاعتماد لمنع المستخدمين الشرعيين من الوصول إلى الخادم ، أو ربما يمكنهم تغيير كلمة مرور مسؤول WordPress لمنع مسؤول WordPress من تسجيل الدخول.
في حين أن هذا سيعتمد إلى حد كبير على الإعداد الخاص بك ، فمن المرجح أن يكون مزود الاستضافة الخاص بك قادرًا على المساعدة في استعادة الوصول إلى بيئة استضافة مشتركة أو خادم خاص افتراضي (VPS) يقوم بتشغيل موقع الويب الخاص بك. إذا فقدت الوصول إلى مسؤول WordPress ، فاتبع دليل WordPress الرسمي حول إعادة تعيين كلمة مرور المسؤول.
أخذ نسخة احتياطية
حتى إذا كان لديك حل النسخ الاحتياطي على WordPress ، فقم بعمل نسخة احتياطية من موقع WordPress الحالي. يعد أخذ نسخة احتياطية من WordPress في هذه المرحلة أمرًا مهمًا للغاية لعدد من الأسباب ، بما في ذلك ما يلي.
- يسمح لك النسخ الاحتياطي بتحليل العدوى في مرحلة لاحقة ،
- قد يلجأ بعض موفري الاستضافة إلى حذف مواقع الويب التي تم اختراقها كإجراء وقائي لمنعها من نشر البرامج الضارة أو البريد العشوائي - اعتمادًا على مزود الاستضافة الخاص بك ، قد يحدث هذا دون سابق إنذار ،
- إذا لم يكن لديك إستراتيجية نسخ احتياطي مطبقة حاليًا ، فقد تتمكن من إنقاذ بعض محتوى موقع الويب من هذه النسخة الاحتياطية قبل أن تسوء الأمور.
بالإضافة إلى ذلك ، إذا كنت تقوم بتشغيل WordPress على خادم افتراضي خاص (VPS) ، ففكر في أخذ لقطة من الجهاز الظاهري بأكمله إن أمكن (ضع في اعتبارك أن هذا يرتبط عادةً بتكلفة إضافية). عند أخذ لقطات ، ضع في اعتبارك أنه إذا كنت تستخدم أي وحدات تخزين خارجية لاستضافة تثبيت WordPress الخاص بك (مثل التخزين المتصل بالشبكة) ، فيجب عليك أيضًا أخذ نسخة من أي وحدات تخزين تخزن تثبيت WordPress الرئيسي ، ومحتوى wp ، وقاعدة بيانات MySQL ، بالإضافة إلى أي وصول إلى خادم الويب وسجلات الأخطاء.
استعادة من نسخة احتياطية
إذا كانت لديك إستراتيجية نسخ احتياطي مطبقة ، فقد حان الوقت لتطبيقها. بافتراض أن لديك حق الوصول إلى نسخة احتياطية حديثة ، قد تكون الاستعادة هي أسرع طريقة لإعادة الاتصال بالإنترنت - ولكن لا تخطئ ، بينما قد تؤدي الاستعادة من نسخة احتياطية من موقع WordPress الخاص بك إلى إزالة العدوى وتسمح لك بالعمل مرة أخرى ، فهي لا تفعل ذلك. حل سبب تعرضك للاختراق في المقام الأول.
إذا تم اختراق موقع WordPress الخاص بك نتيجة لاستغلال ثغرة أمنية أو عيب أمني ، فهذه خطوة تالية أساسية لمحاولة اكتشاف ما حدث (إن أمكن).
ماذا يحدث إذا لم يكن لدي نسخة احتياطية ، أو لا يمكنني استعادة النسخة الاحتياطية الخاصة بي بنجاح؟
إذا لم يكن لديك نسخة احتياطية ، يمكنك استعادتها بنجاح ، اعتمادًا على خطورة الموقف ، قد ترغب في وضع موقع WordPress الخاص بك في وضع الصيانة للسماح لك بالعمل على استعادة موقعك مع السماح للزائرين بمعرفة أنه يجب عليهم التحقق مرة أخرى لاحقًا. في غضون ذلك ، تابع اتباع بقية هذا الدليل. من خلال وضع موقع الويب الخاص بك في وضع الصيانة ، من خلال استخدام wp_maintenance () 1 وظيفة ، سيعيد WordPress رمز حالة HTTP 503. تشير الحالة 503 إلى Google وبرامج الزحف الأخرى إلى حدوث خطأ ما في الصفحة ، ويجب عليهم التحقق مرة أخرى لاحقًا.
تعد استجابة 503 HTTP مهمة بالنسبة إلى مُحسّنات محرّكات البحث لأنها ستمنع الضرر الذي يلحق بتصنيفات البحث في حالة تعطل موقع الويب الخاص بك مؤقتًا. لمزيد من المعلومات حول رمز حالة 503 HTTP وأهميته في تحسين محركات البحث ، راجع مقالة Yoast حول هذا الموضوع.
حدد كيف تم اختراق WordPress
بمجرد أن يتم نسخ موقعك احتياطيًا ، فإن الشيء التالي على جدول الأعمال هو اكتشاف أكبر قدر ممكن من المعلومات حول ما حدث ، أي ضعف الأمان الذي استغله المهاجم للوصول إلى تثبيت WordPress الخاص بك.
التحقق من سجلات النشاط وخادم الويب وسجلات خادم FTP
إذا كنت تحتفظ بسجل نشاط WordPress ، فقد يكون هذا هو أفضل مكان تبدأ منه تحليلك. تحقق مما إذا كان يمكنك تحديد أي سلوك مشبوه. ابحث عن أحداث المستخدمين الذين تم إنشاؤهم حديثًا أو تغييرات كلمة مرور المستخدم. تحقق أيضًا مما إذا كان قد تم تعديل أي ملفات WordPress أو ملحقات أو سمات.
يجب عليك أيضًا إلقاء نظرة على خادم الويب وخادم FTP وملفات سجل نظام التشغيل بحثًا عن سلوك غير عادي أو مريب. على الرغم من أن هذه العملية قد تكون مرهقة إلى حد ما ، إلا أنك تريد أن تبدأ بالتحقق مما إذا كانت هناك حركة مرور غريبة قادمة من عنوان IP واحد . يمكنك القيام بذلك باستخدام مجموعة متنوعة من البرامج النصية لقذيفة الأداة المساعدة وبطانات واحدة. للحصول على عرض في الوقت الفعلي لسجلات خادم الويب ، قد يكون GoAccess مفيدًا.
الإضافات والقوالب غير المستخدمة والقديمة في WordPress
تحقق من قائمة المكونات الإضافية المثبتة ، من لوحة معلومات WordPress وفي الدليل / wp-content / plugins / . هل يتم استخدام جميع مكونات WordPress الإضافية؟ هل كلها حديثة؟ تحقق من السمات ودليل السمات / wp-content / theme / أيضًا. يجب أن يكون لديك سمة واحدة فقط مثبتة ، تلك التي تستخدمها. إذا كنت تستخدم موضوعًا فرعيًا ، فسيكون لديك دليلين.
كود WordPress والتثبيتات غير المستخدمة
الكود المتبقي وغير المستخدم مشكلة شائعة أخرى. يقوم المطورون ومسؤولو النظام أحيانًا بتحديث الملفات مباشرة على الخادم ويأخذون نسخة احتياطية من الملف الأصلي بامتداد مثل .old أو .orig أو .bak . غالبًا ما يستفيد المهاجمون من هذه الممارسة السيئة والأدوات للبحث عن ملفات النسخ الاحتياطي هذه متوفرة على نطاق واسع وبسهولة.
الطريقة التي يعمل بها هذا هي من قبل مهاجم يحاول الوصول إلى ملفات مثل index.php.old . عادة ، يتم تكوين ملفات .php ليتم تنفيذها بواسطة مترجم PHP ، ولكن بإضافة امتداد .old (أو غيره) إلى نهاية الملف ، يتسبب خادم الويب في تقديم الملف للمستخدم. بمجرد القدرة على تخمين اسم ملف النسخ الاحتياطي ، قد يتمكن المهاجم من تنزيل الكود المصدري الذي قد يحتوي على معلومات حساسة ، أو قد يزود المهاجم بتلميحات حول ما يجب استغلاله.
هناك مشكلة مماثلة تتمثل في الاحتفاظ بالتثبيتات القديمة لـ WordPress. عندما يعيد مسؤولو النظام بناء مواقعهم على الويب ، فإنهم يتركون أحيانًا نسخًا من تثبيتات WordPress القديمة في دليل فرعي / قديم / . عادةً ما تظل هذه التثبيتات القديمة لـ WordPress متاحة عبر الإنترنت ، وبالتالي فهي هدف مثير للمهاجم لاستغلال نقاط الضعف المعروفة في الإصدارات القديمة من WordPress جنبًا إلى جنب مع أي مكونات إضافية.
يُنصح بإزالة أي كود غير مستخدم ، تثبيتات WordPress ، إضافات WordPress ، سمات WordPress وأي ملفات أخرى قديمة أو غير مستخدمة (تذكر أنه يمكنك دائمًا الرجوع إلى نسختك الاحتياطية إذا كنت بحاجة إلى استعادة شيء قمت بحذفه عن طريق الخطأ). يجب أن يحتوي موقع الويب الخاص بك على الملفات التي تحتاجها فقط. يجب التعامل مع أي شيء إضافي أو غير مستخدم كسطح هجوم إضافي.
مستخدمي ووردبريس وأدواره
تحقق من استخدام جميع مستخدمي WordPress. هل هناك أي أشياء جديدة مشبوهة؟ تأكد من أن جميع الأدوار سليمة. إذا اتبعت إرشادات مستخدمي WordPress والأدوار ، فيجب أن يكون لديك مستخدم واحد فقط لديه دور مسؤول WordPress.
مقدمو الاستضافة المشتركة
إذا كان WordPress الخاص بك يعمل على مزود استضافة مشترك ، فقد يكون مصدر الاختراق هو موقع ويب آخر صادف أنه يعمل على نفس الخادم الخاص بك. في هذه الحالة ، يكون السيناريو الأكثر احتمالاً هو أن المهاجم قد تمكن من تصعيد امتيازاته. ثم نتيجة لذلك ، يمكنك الوصول إلى الخادم بالكامل ، وبالتالي الوصول إلى موقع WordPress الخاص بك. إذا كنت تشك في حدوث مثل هذا الهجوم ، فسيكون أفضل سبيل هو الاتصال على الفور بمزود الاستضافة الخاص بك ، بعد عمل نسخة احتياطية من موقع الويب الخاص بك.
ملفات htaccess
تعد ملفات .htaccess (ملفات تكوين خادم Apache HTTP على مستوى الدليل) أيضًا هدفًا شائعًا للمتسللين. تُستخدم عادةً لإعادة توجيه المستخدمين إلى مواقع ويب أخرى غير مرغوب فيها أو تصيد احتيالي أو غير ذلك من المواقع الضارة. تحقق من جميع ملفات .htaccess الموجودة على خادمك ، حتى تلك التي لا يستخدمها WordPress. قد يكون من الصعب تحديد بعض عمليات إعادة التوجيه.
انتبه بشكل خاص للتهيئة التي تعيد توجيه طلبات HTTP استنادًا إلى سلاسل وكيل مستخدم محددة - قد يستهدف المهاجمون أجهزة معينة (مثل مستخدمي الأجهزة المحمولة) ، أو حتى الانخراط في مُحسّنات محرّكات البحث ذات القبعة السوداء من خلال تكوين خادم الويب الخاص بك للاستجابة بشكل مختلف لزواحف محركات البحث.
إذا كان ذلك ممكنًا ، ففكر في اعتماد التكوين العام بدلاً من الاعتماد على ملفات .htaccess داخل خادم Apache HTTP. لا تؤدي ملفات .htaccess فقط إلى تدهور الأداء ، ولكنها تفتح موقع WordPress الخاص بك على الويب لمجموعة متنوعة من الثغرات الأمنية إذا كان المهاجم في وضع يسمح له بقراءة محتويات هذه الملفات ، أو الأسوأ من ذلك ، كتابة محتويات هذه الملفات. وفقًا لوثائق خادم Apache HTTP 2 ، يمكن تعطيل استخدام ملفات .htaccess تمامًا عن طريق تعيين التوجيه AllowOverride على "لا شيء" في ملف httpd.conf الرئيسي.
التحقق من نقاط أخرى من المدخلات
هناك عدة نقاط أخرى للإدخالات على خادم الويب. تأكد من التحقق منها جميعًا ، مثل خوادم FTP و SSH وخادم الويب وما إلى ذلك.
ابحث عن عدوى WordPress والشفرات الخبيثة
قبل أن تبدأ : عادةً ما يتضمن اختراق WordPress إدخال رمز في قالب WordPress أو مكون إضافي أو ملف أساسي. ومن ثم ، لمتابعة عملية التنظيف ، يجب أن تكون مرتاحًا لتعديل التعليمات البرمجية. إذا لم تكن كذلك ، فقم بتعيين متخصصين في الأمن في WordPress.
بمجرد تحديد نقطة دخول المتسللين ، يكون من السهل نسبيًا العثور على العدوى. على الرغم من عدم العثور على العدوى بعد ، إلا أن هناك عدة طرق يمكنك استخدامها للعثور على العدوى. وهنا عدد قليل.
التحقق من الملفات التي تم تعديلها في الأيام القليلة الماضية
من الناحية المثالية ، يجب أن تستخدم مكونًا إضافيًا لمراقبة ملفات WordPress يراقب الملفات عبر تثبيت WordPress الخاص بك من أجل التغييرات وينبهك على الفور. إذا لم يكن لديك مكون إضافي لمراقبة تكامل الملفات (FIM) ، فسيتعين عليك البحث عن تغييرات الملف يدويًا.
إذا كان لديك وصول SSH إلى الخادم الخاص بك ، فتحقق من الملفات الموجودة في موقع WordPress الخاص بك والتي تم تغييرها مؤخرًا. عادةً ، يُنصح بالبدء في البحث عن التغييرات خلال الأيام الخمسة الأخيرة من ملاحظة الاختراق ، وتوسيع نطاق البحث حسب الضرورة. للقيام بذلك ، انتقل إلى الدليل حيث يوجد موقع WordPress الخاص بك واستخدم الأمر find.
find .mtime -5 –ls
يسرد الأمر أعلاه (-ls) جميع الملفات التي تم تعديلها (.mtime) في الأيام الخمسة الماضية (-5). إذا كانت القائمة طويلة جدًا ، فاستخدم أقل جهاز نداء لتصفح القائمة والبحث فيها بسهولة أكبر.
find .mtime -5 –ls | less
إذا قمت مؤخرًا بتحديث مكون إضافي أو سمة ، فستظهر أي تغييرات ذات صلة بالملف في نتائج البحث. يتم أيضًا تحديث السجلات وملفات تصحيح الأخطاء بشكل متكرر ، لذا ستظهر في نتائجك أيضًا. نتيجة لذلك ، قد تضطر إلى إجراء بعض التصفية الشاملة للنتائج للعثور على تغييرات الملفات التي تهمك. لاحظ أن المكونات الإضافية المتخصصة مثل المكون الإضافي WordPress File Changes Monitor لبرنامج WordPress مصممة خصيصًا للتخلص من مثل هذه الإيجابيات الخاطئة تلقائيًا. تم تصميم المكون الإضافي عن قصد لـ WordPress ويمكنه تحديد تغيير الملف من WordPress الأساسي أو البرنامج الإضافي أو تحديثات السمة أو تثبيته أو إلغاء تثبيته.
فحص جميع ملفات HTML
يوجد في WordPress عدد قليل جدًا من ملفات HTML ويحب المتسللون الاستفادة منها. ابحث في موقع الويب الخاص بك عن جميع ملفات HTML وقم بتحليل محتواها. تأكد من أن جميع ملفات HTML الموجودة على موقع الويب الخاص بك شرعية ، وأنك تعرف الغرض من استخدامها.
طريقة سهلة لسرد جميع ملفات HTML في دليل WordPress الخاص بك (والأدلة الفرعية) هي استخدام الأمر التالي.
find . -type f -name '*.html'
البحث عن نص الإصابة
إذا تم تشويه موقع الويب الخاص بك ، أو ظهر بعض النص على موقع الويب الخاص بك نتيجة للإصابة ، فابحث عنه باستخدام أداة grep. على سبيل المثال ، إذا رأيت النص "تم الاختراق بواسطة" ، فانتقل إلى الدليل الجذر لموقع الويب وأصدر الأمر التالي.
grep –Ril "hacked by"
سيعيد الأمر أعلاه قائمة بالملفات التي تتضمن المحتوى "اخترق بواسطة". بمجرد حصولك على قائمة الملفات المصابة ، يمكنك تحليل الكود وإزالة العدوى.
ماذا تعني مفاتيح grep؟
- -R يشير إلى grep للبحث بشكل متكرر (عمليات البحث من خلال بنية الدليل بالكامل ، بما في ذلك جميع الأدلة الفرعية والروابط الرمزية).
- يشير -i إلى grep إلى أن البحث يجب أن يكون غير حساس لحالة الأحرف (أي تجاهل الكتابة بالأحرف الكبيرة لمصطلح البحث). هذا مهم جدًا في بيئات Linux / Unix ، نظرًا لأن أنظمة ملفات Linux على عكس Windows ، حساسة لحالة الأحرف.
- يشير -l إلى grep أنه يجب أن يعرض اسم الملف بدلاً من محتويات الملف. عندما يتم اختراق موقع WordPress الخاص بك ، فهذه شفرة ضارة أخرى يجب البحث عنها.
بصرف النظر عن سلسلة "hacked by" الواضحة ، فيما يلي قائمة بالشفرات والعبارات النصية التي تُستخدم عادةً في مواقع WordPress التي تم اختراقها. يمكنك استخدام أداة grep للبحث عن ما يلي:
- base64_decode
- is_admin
- EVAL
- gzuncompress
- تمر من خلال
- إكسيك
- قذيفة_exec
- يجزم
- str_rot13
- النظام
- phpinfo
- chmod
- مكدير
- fopen
- fclose
- إقرا الملف
هناك طريقة سريعة لتحقيق ذلك باستخدام grep وهي عبر الأمر grep التالي الذي يبحث عن الملفات بشكل متكرر (يتبع أي روابط رمزية) ، ويبحث عن السلاسل التي تطابق التعبير العادي المحدد لـ PCRE 3 ، ويعيد تطابق النص بالإضافة إلى رقم السطر الذي حدثت فيه المطابقة.
grep -RPn "(base64_decode|is_admin|eval|gzuncompress|passthru|exec|shell_exec|assert|str_rot13|system|phpinfo|chmod|mkdir|fopen|fclose|readfile) *\("
ملاحظة : يمكن أيضًا استخدام بعض هذه التعليمات البرمجية في رمز شرعي ، لذا قم بتحليل الكود بشكل صحيح وفهم كيفية استخدامه قبل وضع علامة على شيء ما على أنه إصابة أو اختراق.
قارن الملفات مع تثبيت WordPress الأصلي
هذه طريقة مدرسية قديمة ، وعلى الرغم من أنها تستغرق وقتًا طويلاً إلى حد ما ، إلا أنها تعمل بشكل رائع. قارن ملفات موقع الويب الخاص بك بملفات موقع الويب الذي لم يتم العبث به. لذلك ، إذا كان لديك نسخة احتياطية من موقع الويب الخاص بك ، فقم بمقارنة موقع الويب الذي تم العبث به. إذا لم يكن الأمر كذلك ، فقم بتثبيت نسخة جديدة من WordPress والمكونات الإضافية الموجودة على موقع الويب المصاب على مضيف مختلف وقارنها.
هناك العديد من الأدوات التي يمكنك استخدامها لمقارنة الملفات. في هذا المثال ، نستخدم أداة تجارية تسمى Beyond Compare ، على الرغم من وجود العديد من البدائل المجانية. فيما يلي بعض لقطات من مقارنة عينة.
عند مقارنة الدلائل الجذر لموقعين على الويب على WordPress ، تبرز الأداة الاختلاف في محتوى ملف index.php وملفات htaccess و wp-config.php الجديدة والاختلافات في الدلائل الفرعية.
من خلال النقر المزدوج على ملف index.php يمكننا أن نرى ما هي الاختلافات.
ما الذي تبحث عنه في مقارنة ملف WordPress؟
ابحث عن الملفات التي لا تشكل جزءًا من نواة WordPress. تضيف معظم الإصابات ملفات إلى جذر تثبيت WordPress أو إلى دليل wp-content . إذا كان الاختراق ناتجًا عن مكون إضافي ضعيف ، فربما تم تعديل ملفات المكون الإضافي.
تنظيف اختراق ووردبريس
حان الوقت لبدء التنظيف باتباع الإجراء أدناه ، بمجرد معرفة مصدر اختراق WordPress واكتشاف الإصابة.
البحث عن الإصابة تلقائيًا باستخدام خدمة WordPress
إذا كان ما سبق يبدو أكثر من اللازم ، فلا تيأس. هناك العديد من خدمات أمان WordPress والمكونات الإضافية التي يمكنك استخدامها لفحص موقع الويب الخاص بك بحثًا عن البرامج الضارة والإصابات الأخرى. نوصي باستخدام Malcare WordPress Security Services.
ومع ذلك ، لاحظ أن هذه المكونات الإضافية لديها قائمة محدودة من توقيعات البرامج الضارة التي يبحثون عنها. على هذا النحو ، إذا لم يكن الهجوم الذي أثر على موقع WordPress الخاص بك شائعًا ، فقد تفشل هذه المكونات الإضافية في تحديد الإصابة. ليس من غير المعروف بالنسبة لنا أن نتلقى تعليقات من مسؤولي WordPress الذين وقع موقعهم على الويب في WordPress ضحية لهجوم لم تحدد المكونات الإضافية للبرامج الضارة في WordPress أي خطأ.
الخلاصة هنا هي أن الضوابط الأمنية الفعالة تتضمن وجود عدة طبقات من الدفاعات والكشف. في حين أن التحليل اليدوي هو دائمًا أفضل طريقة للمضي قدمًا عندما يمكنك القيام بذلك ؛ لا ينبغي الاستهانة بهذه المكونات الإضافية - فلا يزال من الممكن استخدامها وستكون مفيدة في وقت ما.
استعادة ووردبريس الخاص بك من النسخة الاحتياطية
إذا كان لديك نسخة احتياطية من موقع الويب أو المدونة الخاصة بك على WordPress ، فاستعدها. إنه دائمًا أسهل بكثير من تنظيف الكود يدويًا.
تغيير جميع كلمات المرور وحذف المستخدمين غير المستخدمين والتحقق من أدوار مستخدمي WordPress
قم بتغيير جميع كلمات المرور لجميع المستخدمين والخدمات بما في ذلك WordPress و CPanel و MySQL و FTP وجهاز الكمبيوتر الشخصي الخاص بك. تحقق من قائمة المستخدمين على FTP و WordPress و MySQL وأي خدمة أخرى للتأكد من شرعية جميع المستخدمين. إذا كان هناك أي مستخدمين لم يعودوا مستخدمين ، فاحذفهم. تحقق من أن جميع مستخدمي WordPress لديهم الأدوار والأذونات الصحيحة.
ترقية WordPress core والإضافات والقوالب والبرامج الأخرى
تأكد من أنك تقوم بتشغيل أحدث إصدار من جميع البرامج المطلوبة لتشغيل موقع WordPress الخاص بك. لا يقتصر هذا على WordPress نفسه فحسب ، بل يمتد أيضًا إلى أي مكونات إضافية وموضوعات بالإضافة إلى تصحيحات نظام التشغيل و PHP و MySQL وخادم الويب (مثل خادم Apache HTTP أو Nginx) وأي خادم FTP قد تقوم بتشغيله.
النسخ الاحتياطي لموقع WordPress الخاص بك
مرة واحدة في هذه المرحلة ، قبل إزالة الشفرة المصابة الفعلية ، خذ نسخة احتياطية من موقع WordPress الخاص بك.
قم بإزالة تنبيه البرامج الضارة للتصفح الآمن من Google
إذا تم رفض موقع الويب الخاص بك بواسطة التصفح الآمن من Google ، فيمكنك التقدم بطلب للحصول على مراجعة أمنية لإزالة التنبيه.
بمجرد إزالة اختراق WordPress ...
تهانينا ، لقد استعدت موقع الويب الخاص بك على WordPress من الاختراق. الآن يجب أن تتأكد من عدم حدوث ذلك مرة أخرى. إليك بعض النصائح حول ما يجب عليك فعله:
- قم بتثبيت مكون إضافي لسجل نشاط WordPress لتتبع كل ما يحدث على موقع WordPress الخاص بك.
- إذا لم يكن لديك حل نسخ احتياطي ، فاحصل عليه.
- استخدم خدمة فحص أمان WordPress.
- قم بتدوير قاعدة البيانات وكلمات مرور المسؤول ، وفرض أمان كلمة مرور WordPress قويًا.
- حافظ دائمًا على تحديث WordPress وإضافات WordPress والسمات وأي برامج أخرى تستخدمها.
- قم بإزالة أي ملفات غير مستخدمة مثل تثبيتات WordPress القديمة ومكونات WordPress الإضافية والسمات غير المستخدمة (بما في ذلك سمات WordPress الافتراضية غير المستخدمة). تضيف المكونات والبرامج غير المستخدمة سطح هجوم غير ضروري ويجب إزالتها بشكل مثالي.
- اتبع دليل الصلابة الأمنية في WordPress الخاص بنا للتأكد من أنك تعتني بكل مشكلة أمنية محتملة على موقع الويب الخاص بك.