موقعنا على WordPress مخترق ولا الإضافة هي المعطوبة، كيف نعرف أن هناك من تسلل إلى الداخل؟

سبب رؤية عملائكم لما لا ترونه هو فلترة User-Agent و Referer. كود PHP الخبيث يعرض الصفحة النظيفة للزوار القادمين مباشرة، بينما يفعّل التحويل الخبيث للقادمين من بحث Google أو المواقع الخارجية. تحققوا من ملفي .htaccess و index.php في المجلد الرئيسي للسيرفر. سترون أجزاء كود غريبة مخفية في الأعلى تستدعي eval أو base64_decode أو ملفات خارجية.

اتبعوا هذه الخطوات لإنقاذ الوضع الحالي دون إتلاف الأدلة: 1) نزّلوا فوراً ملف access.log الخام لآخر 30 يوماً من لوحة تحكم السيرفر إلى قرصكم المحلي. 2) خذوا نسخة احتياطية كاملة لقاعدة البيانات عبر phpMyAdmin. 3) سجّلوا تاريخ إنشاء المستخدم المشبوه في جدول wp_users. 4) فلتروا سجلات الوصول في نطاق هذا التاريخ والوقت لتحددوا إلى أي ملف PHP أو ثغرة أُرسل طلب POST.

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

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

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

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

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

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

شكرًا لكتابة هذا.

هذا العنوان مؤرشف.

أنت محق.

دعوني ألخص ما قيل حتى الآن. الحلول التي تنجح على نطاق صغير تنهار عند التوسع، تعلمت هذا متأخراً.

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

عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

لم أكن أعلم بهذا لكن إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا.

بالتأكيد. وإذا أردت إضافة شيء: بيئات الاختبار المنسية تصبح ثغرات أمنية أكثر تكرارًا من الأنظمة الحية.

صححوا لي إن أخطأت.

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

القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر. اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

ملخص سريع للجدد: كل بند غير مكتوب هو بند سيتذكره الطرفان بشكل مختلف لاحقًا.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

هناك فخ هنا، لا أريد المرور عليه دون ذكره. محاولة فعل هذا بمفردك هي أغلى الطرق.

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