تأكّدتَ للتوّ: موقعك مخترَق. وما تفعله في الساعة القادمة يقرّر إن كان هذا عملَ بعد ظهيرة أم عمل أسبوعين — وإن كان المهاجم سيبقى داخل موقعك الأسبوع المقبل. والغريزة تدفعك إلى حذف الملف الخبيث والمضيّ، وهي غريزة خاطئة، وهي سبب تنظيف مواقع كثيرة ثلاث مرات قبل أن يكتشف أحد كيف دخل الدخيل. هذا هو الترتيب الصحيح للعمل، ولماذا تأتي كل خطوة في موضعها، والأخطاء التي تحوّل حادثة محتواة إلى حادثة متكرّرة.
وإن كنت ما زلت في مرحلة «أشعر أن شيئاً ما خطأ ولستُ متأكداً»، فابدأ بدليلنا عن علامات اختراق موقعك وعُد إلى هنا بعد أن تتأكد.
الخلاصة السريعة
اعمل بهذا الترتيب: احتواء بلا إتلاف للأدلة، ثم حفظ السجلات ونسخة من الحالة المخترَقة، ثم إيجاد نقطة الدخول قبل تنظيف أي شيء، ثم استئصال البرمجية وكل آلية ثبات، ثم تبديل بيانات الاعتماد وإبطال الجلسات، ثم التعافي والتحصين. ولا تستعِد نسخة احتياطية أولاً — فستستعيد فوق الأدلة، وفي أغلب الحالات فوق لا شيء، لأن نقطة الدخول أقدم من النسخة.
الدقائق 0–10: احتوِ ولا تُتلِف
غاية الاحتواء إيقاف الضرر عن الزوّار وإيقاف المهاجم عن المضيّ، مع إبقاء مسرح الحادثة سليماً بما يكفي للتحقيق.
أنزِل الموقع إن كان يقدّم برمجية خبيثة أو يحوّل الزوّار. صفحة صيانة خير من موقع يؤذي عملاءك فعلاً أو يراكم تحذير Google Safe Browsing. وإن كان مشوَّهاً أو يستضيف تصيّداً فهذا ليس خياراً.
لا تحذف شيئاً بعد. كل ملف خبيث دليل: طابعه الزمني يخبرك متى وقع الاختراق، ومحتواه يخبرك غالباً بما ينبغي البحث عنه أيضاً. والحذف أولاً أشيع خطأ، وهو يُتلف الخطّ الزمني الذي ستحتاجه بعد قليل.
ولا تستعِد نسخة احتياطية بعد. فالاستعادة تطمس الحالة المخترَقة، والأهمّ أنها تعيد عادةً الثغرة التي أدخلت المهاجم. فإن كان المدخل كلمة مرور ضعيفة أو إضافة قديمة، فالموقع المستعاد يحمل الاثنتين.
وما ينبغي فعله فوراً: سجّل الوقت بالضبط، وابدأ بتدوين كل إجراء تقوم به. بعد ساعة لن تتذكّر الترتيب.
الدقائق 10–25: احفظ ما ستحتاجه
الأدلة تنتهي صلاحيتها. سجلات وصول الخادم تُدوَّر، أحياناً يومياً. وفاحصات البرمجيات الخبيثة تحجر الملفات بمهلة احتفاظ. وإن كان الاختراق أقدم من أسابيع قليلة، فقد يكون بعض ما تحتاجه قد ضاع — فانسخ أولاً وحقّق ثانياً.
خذ، بهذا الترتيب:
نسخة كاملة من الحالة الراهنة — الملفات وقاعدة البيانات كما هي الآن، محفوظة في مكان منفصل عن الموقع. هذه ليست نسخة ستستعيدها، بل السجلّ الذي ستحقّق فيه.
سجلات الوصول والأخطاء، بأقصى ما تعود إليه. هي ما يحدّد نقطة الدخول. وانسخ الأرشيفات الشهرية أيضاً لا سجلّ اليوم وحده.
قائمة بكل حساب مدير مع تاريخ إنشائه وبريده، والمهام المجدولة الحالية.
الدقائق 25–40: اعثر على المدخل قبل أن تنظّف
هذه الخطوة التي يتخطّاها الناس، وتخطّيها هو سبب إعادة اختراق المواقع. فتنظيف البرمجية دون إيجاد المدخل يغلق عَرَضاً لا باباً.
ابدأ بفحص سلامة الملفات. في ووردبريس يقارن wp core verify-checksums كل ملف نواة بالإصدار الرسمي ويسمّي كل مختلف. يستغرق ثوانيَ ويفصل فوراً بين «النواة عُدِّلت» و«المشكلة في إضافة أو قالب أو مرفوعات».
ابحث حيث تسكن الحمولات فعلاً. في ووردبريس يعني ذلك wp-content/mu-plugins/ — تُحمَّل مع كل طلب بلا تفعيل ولا تظهر في أي قائمة إضافات. ثم مجلد الرفع، الذي ينبغي أن يحوي وسائط لا ملفات PHP أبداً. ثم ملفات .htaccess، بحثاً عن قواعد تحويل محقونة وتوجيهات auto_prepend_file.
اقرأ سجلات الوصول حول الطابع الزمني لأقدم ملف خبيث. هنا تكون الإجابة عادةً. أنت تبحث عمّا حدث في الدقائق التي سبقت ظهور ذلك الملف. فطلب POST ناجح إلى صفحة الدخول يعيد 302، يتبعه طلب إلى نقطة رفع الإضافات، يعني أن المهاجم كان يملك كلمة مرور صحيحة — لا ثغرة. وطلب إلى نقطة إضافة بعينها يعيد 200 قبل ظهور الملف مباشرةً يعني العكس.
وهذا الفارق يغيّر كل ما تفعله بعده. فكلمة مرور مسروقة تعني أن كل حساب وكل موقع يتشارك تلك البيانات مكشوف، وأن ترقيع الإضافات لن ينفع. وثغرة مستغَلّة تعني: رقّعها ويُغلق الباب.
افحص قائمة المديرين بالسلوك لا بالأسماء. نادراً ما تحمل حسابات المهاجم اسماً واضحاً. والإشارات الموثوقة هي: مدير لم يؤلّف شيئاً إطلاقاً، وبريد بنطاق لا تملكه الشركة، وحسابان أُنشئا في الثانية نفسها، واسم يتكوّن من كلمة دور تليها أحرف سداسية عشوائية، وحساب يدّعي أنه لمورّد أمني إضافتُه غير مثبَّتة أصلاً. أيٌّ منها يستحق نظرة جادّة، واثنتان معاً تكادان تكونان قاطعتين.
الدقائق 40–55: استأصل كما ينبغي
الآن تستطيع التنظيف — والآن تعرف ما تبحث عنه.
أزِل الملفات المزروعة ولا «تنظّفها». فالإضافة الوهمية لا تُصلَح بنزع الأسطر الخبيثة منها؛ يبقى لك جذعٌ تستدعيه شيفرة أخرى، فيسقط الموقع مع كل طلب. ونرى هذا النمط باستمرار: فاحص آلي ينزع الحمولة، فيبقى الملف قشرةً فارغة، ويبدأ الموقع يعطي أخطاء 500 تبدو كعطل استضافة. احذف المكوّن كله.
احذر الملفات التي أفرغها الفاحص بدل حذفها. كثير من أدوات الأمن تقتطع الملف الخبيث إلى صفر بايت وتتركه مكانه. وملف PHP بصفر بايت في مسار غير معتاد ليس ملفاً سليماً — بل بصمة إصابة عولجت. وهو سهل الإغفال لأن لا شيء فيه يطابق نمط برمجية خبيثة بعد الآن. ابحث بالموضع والحجم لا بالمحتوى.
ابحث بالبنية لا باللاحقة. من التواقيع الموثوقة مسارٌ يحوي اسم مجلد مكرَّراً متتالياً — images/images/images/ أو widgets/widgets/. البرمجيات الشرعية لا تفعل هذا. ولا تقصر بحثك على .php: فالحمولات والملفات المهيَّأة تختبئ تحت لواحق الوسائط أيضاً.
استعِد ملفات النواة المعدَّلة من مصدرها. في ووردبريس، إعادة تثبيت نفس الإصدار تستعيد كل ملفات النواة دون المساس بمحتواك ودون هجرة قاعدة بيانات. وهي أسرع طريق لتحويل تقرير بصمات فاشل إلى تقرير نظيف.
ثم أزِل كل آلية ثبات. حسابات المديرين الخفية، والمهام المجدولة التي لم تنشئها، وخيارات محقونة في قاعدة البيانات، وأي أرشيف يعيد تثبيت نفسه تركته الحمولة. فعائلات البرمجيات الخبيثة صارت تشحن نسخة من نفسها في مواضع عدّة تحديداً كي لا يُجدي حذف النسخة العاملة.
الدقائق 55–60: بيانات الاعتماد والجلسات
إجراءان، بهذا الترتيب، والثاني هو ما يُنسى.
أعِد تعيين كل كلمة مرور مدير — على الموقع المخترَق وعلى كل موقع آخر يتشارك حساب الاستضافة نفسه، لأن اختراقاً على مستوى الملفات يبلغها جميعاً. وأعِد تعيين كلمة مرور قاعدة البيانات، ولوحة التحكم، وأي مفاتيح API يحتفظ بها الموقع.
ثم أبطل كل الجلسات النشطة. فملفّ ارتباط جلسة مسروق يبقى صالحاً بعد تغيير كلمة المرور. وحتى تُبطَل الجلسات، قد يبقى المهاجم مسجَّل الدخول ببيانات استبدلتَها للتوّ. وفي ووردبريس يعني ذلك مسح سجلات رموز الجلسات لكل المستخدمين، لا من تشكّ فيهم وحدهم.
الثماني والأربعون ساعة التالية
الساعة الأولى تحتوي الحادثة. وهذه الخطوات تُغلقها.
تحقّق أن الموقع نظيف فعلاً لا أنه يعمل فحسب. فعمل الموقع لا يُثبت شيئاً — وغاية الباب الخلفي الحديث كلها أن يبقى الموقع عاملاً. أعِد فحص السلامة، وأعِد سرد المديرين، وأعِد الفحص.
راقب عودة الإصابة. فإن عادت البرمجية نفسها خلال أيام، فقد فاتتك آلية ثبات أو نقطة الدخول. عُد إلى السجلات.
عالِج محركات البحث. إن وسمَ جوجل موقعك، فاطلب مراجعة في Search Console بعد أن ينظف. والتقديم وهو مصاب يعيد العدّاد إلى الصفر وقد يطيل العقوبة.
أغلق الباب الذي وجدته. إن كان مكوّناً مصاباً فرقّعه ودقّق البقية بحثاً عن الإهمال نفسه. وإن كانت كلمة مرور مسروقة ففعّل التحقق بخطوتين، واستقصِ كيف تسرّبت — كلمة معادة الاستعمال، أو جهاز مصاب، أو تسريب في خدمة أخرى. فتبديل كلمة مرور دون الإجابة عن هذا السؤال يعني أن الجديدة تسير في الطريق نفسه.
الأخطاء التي تزيد الأمر سوءاً
استعادة نسخة احتياطية كأول خطوة. تطمس الأدلة، وتعيد الثغرة عادةً. استعِد متأخراً، من نقطة تأكّدتَ أنها تسبق الاختراق، وبعد أن تعرف كيف دخل الدخيل.
تنظيف البرمجية دون الحسابات. فالمدير الخفي مفتاح دائم. وإزالة الحمولة مع إبقاء الحساب تعني أن المهاجم يسجّل الدخول ثانيةً ويزرعها من جديد.
افتراض أن موقعاً واحداً مشكلة واحدة. فحين تتشارك مواقع كثيرة حساب استضافة واحداً، تتشارك هوية نظام ملفات واحدة. وشيفرة تعمل على واحد تستطيع الكتابة فيها جميعاً. افحص كل موقع تحت الحساب، لا الذي ظهرت عليه الأعراض.
اعتبار تقرير الفاحص كاملاً. الفاحصات الآلية ممتازة في التواقيع المعروفة، وعمياء تماماً عن دخول بكلمة مرور صحيحة. فإن لم يُبلّغ فاحصك بشيء ولديك حسابات مديرين لا تفسير لها، صدّق الحسابات.
انتظار اليقين قبل الاحتواء. احتوِ عند الشك، وحقّق على مهل. فكلفة صفحة صيانة لساعة أقل بكثير من كلفة وسم Safe Browsing.
ما معنى «نظيف» فعلاً
الموقع نظيف حين تتحقق أربعة أمور معاً: فحص سلامة الملفات ينجح، وقائمة المديرين لا تضمّ إلا أشخاصاً تستطيع تسميتهم، ونقطة الدخول محدَّدة ومغلقة، وكل بيانات اعتماد يُحتمل انكشافها بُدِّلت والجلسات أُبطلت.
وثلاثة من أربعة ليست نظافة. بل موقع سيُخترق ثانيةً، غالباً على يد الشخص نفسه، وغالباً خلال أسابيع.
الأسئلة الشائعة
هل أُنزل الموقع فوراً؟
إن كان يقدّم برمجية خبيثة، أو يحوّل الزوّار، أو يستضيف تصيّداً، أو مشوَّهاً — نعم، فوراً. أمّا إن كان الاختراق باباً خلفياً بلا أثر يراه الزائر، فصفحة الصيانة تمنحك هدوءاً لكنها ليست عاجلة. احكم بالضرر على الزوّار لا بالإحراج.
ألا أستطيع استعادة نسخة الأسبوع الماضي فحسب؟
فقط إن استطعت إثبات أن الاختراق وقع بعد أخذ تلك النسخة، وبعد أن تحدّد المدخل وتغلقه. وأغلب الاختراقات تُكتشف بعد بدايتها بزمن طويل، فـ«الأسبوع الماضي» كثيراً ما يكون مخترَقاً أصلاً. والاستعادة تُتلف كذلك الأدلة التي تحتاجها لتتأكد.
كم يستغرق تنظيف صحيح؟
لموقع واحد بمدخل واضح: ساعات قليلة. ولحساب استضافة فيه مواقع كثيرة تتشارك نظام الملفات: احسب يوماً، لأن كل موقع يجب فحصه. التحقيق هو الجزء البطيء لا التنظيف.
مستضيفي يقول إن خوادمه آمنة. هل يحسم هذا الأمر؟
لا، وهو عادةً صحيح وغير ذي صلة في آن. فأمن مستوى الخادم لا يغطّي اختراقاً على مستوى التطبيق: كلمة مرور صحيحة استُعملت على صفحة دخولك، أو إضافة قديمة على موقعك، ليست ممّا يمنعه تحصين الخادم.
كيف أعرف أن المهاجم خرج فعلاً؟
لا تعرف ذلك من عمل الموقع بشكل طبيعي. تعرفه من تحقّق الشروط الأربعة أعلاه معاً، ومن فترة مراقبة بعدها لا يظهر فيها جديد.
إن كنت في وسط هذا الآن
الاستجابة للحوادث شيء سيّئ أن تتعلّمه أثناء حادثة. تدعم بيغ بانغ لحلول تقنية المعلومات شركات الإمارات منذ 2003، وتغطّي خدمة إصلاح المواقع المخترقة لدينا التسلسل أعلاه بالضبط — الاحتواء والمراجعة الجنائية والاستئصال وتبديل بيانات الاعتماد ورفع الحجب — مع تحديد نقطة الدخول لا تخمينها. ثم تضع خدمات أمن المواقع لدينا المراقبة التي تجعل المحاولة القادمة تُكتشف في ساعات لا شهور، وتعرض قائمة متطلبات الأمن في الإمارات خط الأساس الذي نوصي به.
تحدّث إلى فريقنا في دبي — وإن كنت في وسط حادثة الآن، فاحفظ سجلاتك قبل أي شيء آخر.
