أمان الموقع والنسخ الاحتياطيّ: حصّن موقعك واحمِ نفسك من الكارثة

في دليل تحصين ووردبريس الرسميّ مثالٌ قصيرٌ يلخّص نصف هذا المقال. موقعٌ يأخذ نسخةً احتياطيّةً كلّ أسبوع، ويُخترَق في الأوّل من مايو، ولا يكتشف صاحبه الاختراق إلّا في الثاني عشر منه. هذا الموقع يملك نسخًا من قبل الاختراق يعيد منها بناءه، ونسخًا من بعده تساعده في معرفة كيف دخل المهاجم.^[1] فالنسخة التي تنقذه هي التي أُخذت قبل أن يعرف أنّ شيئًا حدث، وقد تكون أقدم من آخر نسخةٍ عنده بأسبوعين.

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

لماذا يُهاجَم موقعٌ صغير

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

والتقرير السنويّ لشركة Verizon عن اختراقات البيانات، في نسخته الصادرة في مايو 2026، يضع الثغرات البرمجيّة في المقدّمة. استغلال ثغرات البرمجيّات صار أوّل طريقٍ يدخل منه المهاجمون، بنسبة 31% من الاختراقات، متجاوزًا لأوّل مرّةٍ سرقة بيانات الدخول. ويقول التقرير إنّ الذكاء الاصطناعيّ سرّع الهجمات من أشهرٍ إلى ساعات.^[2]

وفي عالم ووردبريس الأرقام أوضح. وجدت Patchstack في تقريرها لسنة 2026 أنّ 2025 شهدت 11,334 ثغرةً جديدةً في منظومة ووردبريس، 91% منها في الإضافات و9% في القوالب، وستّ ثغراتٍ فقط في النواة وكلّها منخفضة الخطورة. ووجدت أنّ الثغرات التي تُستغَلّ بكثافة يبدأ استغلالها الواسع بعد خمس ساعاتٍ في الوسيط.^[3] وقد عرضت هذه الأرقام بالتفصيل في مقال الاستضافة المُدارة لووردبريس، ويكفي منها هنا أنّ الخطر الأكبر يعيش في الإضافات التي تثبّتها أنت.

الطبقة الأولى: التحديث، وحدوده

إن لم تأخذ من هذا المقال إلّا عادةً واحدة، فلتكن التحديث. نواة ووردبريس تحدّث نفسها تلقائيًّا في الخلفيّة منذ الإصدار 3.7، وهذا مفعّلٌ افتراضيًّا في معظم المواقع،^[4] والإضافات والقوالب تستطيع ذلك إن فعّلته لكلٍّ منها. والثغرة التي نُشر إصلاحها تصير خريطةً في يد المهاجمين، فهم يعرفون أين الباب ويبحثون عن المواقع التي لم تغلقه بعد.

والوجه الثاني من هذه الطبقة أن تقلّل ما تحتاج تحديثه. يقول دليل التحصين الرسميّ أن تحذف أيّ إضافةٍ لا تستعملها، لا أن تكتفي بتعطيلها.^[1] فالإضافة المعطّلة تبقى ملفّاتها على خادمك، وقد تصل إليها ثغرةٌ فيها دون أن تشغّلها أنت. ولا تثبّت نسخًا مقرصنةً من إضافاتٍ مدفوعة، فهي مقطوعةٌ عن التحديثات الرسميّة من يومها الأوّل، ولا تعرف ما أضافه إليها من وزّعها.

لكنّ التحديث وحده لا يحميك من كلّ شيء، وحادثةٌ وقعت في 2026 تشرح السبب. نشرت Patchstack في 15 أبريل 2026 تحليلًا لهجومٍ على أكثر من 20 إضافةً لمطوّرٍ اسمه EssentialPlugin، كانت متاحةً في دليل ووردبريس الرسميّ. بيعت الشركة في 2025 لمشترٍ جديد، وكان أوّل ما نشره المالك الجديد في سبتمبر 2025 تحديثًا يحمل بابًا خلفيًّا، تحت رسالةٍ تقول إنّه يفحص التوافق مع إصدارٍ من ووردبريس. وبقي الباب نائمًا حتى أبريل 2026، ثمّ فُعّل ليزرع برمجيّاتٍ خبيثةً في آلاف المواقع.^[5]

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

الطبقة الثانية: الدخول

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

أمّا نصائح «الإخفاء» الشائعة، كتغيير عنوان صفحة الدخول، فيقول دليل التحصين الرسميّ إنّ الأمان بالإخفاء استراتيجيّةٌ غير سليمةٍ إن اعتمدت عليها أساسًا. لكنّه يستثني خطوةً مفيدة: ألّا يكون اسم حساب المدير كلمةً يسهل تخمينها مثل admin، لأنّ هذه الأسماء أوّل ما تُهاجَم.^[1] فغيّر الاسم، ولا تعوّل على إخفاء الصفحة، وحدّد عدد محاولات الدخول الفاشلة قبل أن يُحظر صاحبها.

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

define( 'DISALLOW_FILE_EDIT', true );

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

الطبقة الثالثة: أقلّ الصلاحيّات

في ووردبريس خمسة أدوارٍ للمستخدمين في الموقع الواحد، من المدير إلى المحرّر والكاتب والمساهم والمشترك، ولكلّ دورٍ صلاحيّاتٌ محدّدة.^[6] والقاعدة أن تعطي كلّ شخصٍ أقلّ دورٍ يكفيه لعمله. من يكتب مقالاتٍ فقط يحتاج دور الكاتب وحده، ومن يراجع مقالات غيره وينشرها يحتاج دور المحرّر، ولا يحتاج أيٌّ منهما أن يثبّت إضافةً أو يغيّر قالبًا.

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

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

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

الطبقة الرابعة: درعٌ أمام الخادم

كلّ ما سبق يعمل داخل موقعك. وطبقةٌ أخرى تعمل قبله: جدار حماية تطبيقات الويب، الذي يقف بين الزوّار وخادمك، ويفحص كلّ طلبٍ قبل أن يصل، ويردّ ما يطابق أنماط الهجمات المعروفة. وخدمةٌ مثل Cloudflare تقدّم جزءًا من هذا مجّانًا. تقول وثائقها إنّ مجموعة قواعدها المجّانيّة المُدارة متاحةٌ في كلّ الخطط، وتحمي من الثغرات عالية الأثر والأوسع استغلالًا.^[7]

وتقول الوثائق نفسها إنّ حمايتها من هجمات الحرمان من الخدمة، التي تغرق الموقع بطلباتٍ وهميّةٍ حتى يتوقّف، غير محدودةٍ ولا تُحسب بالاستهلاك، ومتاحةٌ لكلّ العملاء في كلّ الخطط.^[8] فموقعٌ صغيرٌ يمرّ عبرها يحصل على حمايةٍ كانت قبل سنواتٍ حكرًا على الشركات الكبيرة. وتذكّر ما قلته في مقال الشهادات عن الوضع المرن: اجعل الطريق بين Cloudflare وخادمك مشفّرًا أيضًا.

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

الطبقة الخامسة: المراقبة

الجدران لا تكفي إن لم يكن أحدٌ ينظر إليها. يقول دليل التحصين إنّ السجلّات أفضل صديقٍ لك حين تريد أن تفهم ما يجري في موقعك، لأنّها تريك ما حدث، ومن فعله، ومتى.^[1] وأغلب الاختراقات تسبقها إشارات: محاولات دخولٍ كثيرةٌ من عنوانٍ واحد، أو ملفٌّ تغيّر ولم تغيّره أنت، أو حساب مديرٍ جديدٌ لم تنشئه.

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

النصف الثاني: قاعدة 3-2-1

مهما أحكمت الطبقات السابقة، يبقى احتمال الاختراق، ومعه احتمالاتٌ أخرى لا علاقة لها بالمهاجمين: تحديثٌ يكسر الموقع، أو عطلٌ في الخادم، أو ملفٌّ تحذفه أنت بالخطأ. والنسخة الاحتياطيّة جوابٌ واحدٌ لكلّ هذه الاحتمالات. وأشهر قواعدها قاعدة 3-2-1، التي نشرها فريق الاستجابة للطوارئ الحاسوبيّة الأمريكيّ في ورقةٍ لسنة 2012. تقول القاعدة: ثلاث نسخٍ من كلّ ملفٍّ مهمّ، أصلٌ ونسختان، على نوعين مختلفين من الوسائط، وواحدةٌ منها على الأقلّ خارج مكان العمل.^[9]

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

وانتبه إلى أنّ «خارج الخادم» لا يكفي وحده في زمن برمجيّات الفدية. يقول المركز الوطنيّ البريطانيّ للأمن السيبرانيّ إنّه رأى حوادث كثيرةً شفّرت فيها برمجيّات الفدية البيانات الأصليّة. وشفّرت معها أقراص الذاكرة والتخزين الشبكيّ المتّصلة التي تحمل النسخ الاحتياطيّة، وأصابت أماكن التخزين السحابيّ المتّصلة بها.^[10] فاجعل نسخةً واحدةً على الأقلّ منفصلةً عن كلّ ما يصل إليه موقعك: قرصٌ تفصله بعد النسخ، أو خدمة تخزينٍ لا تسمح بحذف النسخ ولا تعديلها قبل مدّة تحدّدها.

والنسخة الكاملة شيئان معًا: ملفّات الموقع، وقاعدة بياناته. الملفّات فيها القالب والإضافات والصور، وقاعدة البيانات فيها المقالات والتعليقات والإعدادات والمستخدمون. نسخةٌ من أحدهما دون الآخر لا تعيد موقعًا يعمل، ويذكّر دليل التحصين بأن تنسخ قاعدة البيانات بانتظامٍ مع الملفّات.^[1]

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

mysqldump -u site_user -p site_db > site-db-2026-09-24.sql
tar -czf site-files-2026-09-24.tar.gz /var/www/site

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

كم مرّةً تنسخ، وكم نسخةً تحتفظ

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

شكل 1

فعدد النسخ التي تحتفظ بها يحدّده سؤالٌ واحد: كم يمكن أن يمرّ بين الاختراق واكتشافه؟ وجواب الحادثة التي رويتها قبل قليل سبعة أشهر، بين سبتمبر 2025 وأبريل 2026. فاحتفظ بنسخٍ يوميّةٍ لأسبوعين، وأسبوعيّةٍ لشهرين، وشهريّةٍ لسنة إن كانت المساحة تسمح، فتكون لك نقطة عودةٍ قريبة ونقطةٌ بعيدة معًا.

أمّا كم مرّةً تنسخ، فتحدّده كمّيّة العمل التي تقبل أن تخسرها. تسمّي وكالة الأمن السيبرانيّ الأمريكيّة هذا «هدف نقطة الاستعادة»، وتسمّي المدّة التي تقبل أن يبقى فيها موقعك متوقّفًا «هدف زمن الاستعادة»، وتوصي الشركات الصغيرة بأن تحدّدهما وتراجعهما.^[11] مدوّنةٌ تُنشر فيها مقالةٌ كلّ أسبوعٍ تكفيها نسخةٌ يوميّة. ومتجرٌ تصله طلباتٌ كلّ ساعةٍ يحتاج نسخًا لقاعدة بياناته كلّ ساعة، لأنّ نسخةً من ليلة أمسٍ تعني أنّ طلبات اليوم كلّها ضاعت.

النسخة التي لم تُستعَد مرّةً مجرّد أمل

أسوأ لحظةٍ لتكتشف أنّ نسختك معطوبةٌ هي اللحظة التي تحتاجها. ملفٌّ مضغوطٌ لم يكتمل، أو قاعدة بياناتٍ لم تُنسخ لأنّ كلمة مرورها تغيّرت، أو نسخٌ توقّفت منذ أشهرٍ دون أن يلاحظ أحد. ولهذا توصي وكالة الأمن السيبرانيّ الأمريكيّة باختبارات استعادةٍ مجدولةٍ تتحقّق من سلامة النسخ.^[11]

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

ويضيف دليل التحصين خطوةً لمن يريد ثقةً أكبر. اقترح أن تشفّر النسخة، أو تحفظ بصمةً رقميّةً لكلّ ملفٍّ منها في سجلٍّ مستقلّ، أو تضعها على وسيطٍ للقراءة فقط، فتتأكّد أنّ أحدًا لم يعبث بها.^[1] والنسخة التي تعيد منها موقعًا مخترقًا يجب أن تكون أنت واثقًا أنّها لم تُلمس.

نسخ الاستضافة ونسختك أنت

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

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

يوم تكتشف أنّ موقعك اختُرق

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

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

وافتح بعد ذلك تقرير «مشكلات الأمان» في أداة مشرفي المواقع من Google. تقول صفحة المساعدة إنّ هذا التقرير يعرض ما وجدته Google إن قرّرت أنّ الموقع مخترق. وتقول أيضًا إنّ الصفحات المصابة قد تظهر في نتائج البحث مع علامة تحذير، أو تظهر للزائر صفحة تحذيرٍ في المتصفّح قبل أن تفتح. فإن وجدت فيه شيئًا يخصّ موقعك، فبعد أن تنظّف الموقع كلّه اطلب مراجعةً من التقرير نفسه، وتقول الصفحة إنّ المراجعة قد تستغرق من أيّامٍ إلى أسابيع.^[12] وهذه مدّةٌ يخسر فيها موقعك زوّار البحث، فهي سببٌ آخر لأن تمنع الاختراق قبل أن تضطرّ إلى إصلاحه.

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

جرّبه بنفسك

اكتب على ورقةٍ أجوبة خمسة أسئلة: أين آخر نسخةٍ من موقعي خارج الخادم، ومتى أُخذت؟ متى جرّبت استعادتها آخر مرّة؟ هل التحديث التلقائيّ مفعّلٌ للإضافات؟ هل التحقّق بخطوتين مفعّلٌ لحسابي؟ كم حساب مديرٍ في موقعي، ولمن؟ كلّ سؤالٍ لم تعرف جوابه نقطةٌ تبدأ منها.

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

خلاصة عمليّة

أغلب الهجمات آليّة، والثغرات البرمجيّة صارت في 2026 أوّل طرقها، وأغلبها في ووردبريس يسكن الإضافات. فحدّث كلّ شيء، واحذف ما لا تستعمله، ولا تثق بإضافةٍ لمجرّد أنّها في الدليل الرسميّ. واحمِ الدخول بكلمة مرورٍ طويلةٍ وتحقّقٍ بخطوتين، وأعطِ كلّ حسابٍ أقلّ دورٍ يكفيه، وضع أمام موقعك درعًا مجّانيًّا إن أمكن. ثمّ طبّق قاعدة 3-2-1 مع نسخةٍ منفصلةٍ لا يصل إليها الخادم، واحتفظ بسلسلة نسخٍ تغطّي أسابيع وأشهرًا، واختبر الاستعادة قبل أن تحتاجها.

وبعد أن صار موقعك محميًّا وقابلًا للاستعادة، يبقى سؤالٌ يواجهه كلّ صاحب موقعٍ يومًا بعد يوم: لماذا يتأخّر موقعي في الفتح، وكيف أسرّعه؟ دور التخزين المؤقّت وشبكات توزيع المحتوى في ذلك، وأين يكمن البطء فعلًا، موضوع المقال التالي: سرعة الموقع وشبكات CDN.

المصادر

1. ‏WordPress، «Hardening WordPress» (حُدّث في 7 يناير 2026): مثال النسخ الأسبوعيّة (اختراق 1 مايو واكتشاف 12 مايو)، وحذف الإضافات غير المستعملة، والأمان بالإخفاء استراتيجيّةٌ أساسيّةٌ غير سليمة مع تجنّب اسم admin، وDISALLOW_FILE_EDIT، والسجلّات، ونسخ قاعدة البيانات، وتشفير النسخ أو بصماتها أو وسائط القراءة فقط.
2. ‏Verizon، «Vulnerability exploitation top breach entry point, 2026 industry-wide DBIR finds» (19 مايو 2026): استغلال الثغرات البرمجيّة 31% أوّل طرق الدخول متجاوزًا سرقة بيانات الدخول لأوّل مرّة، والذكاء الاصطناعيّ سرّع الهجمات من أشهرٍ إلى ساعات.
3. ‏Patchstack، «State of WordPress Security in 2026» (بيانات 2025): 11,334 ثغرةً جديدة، 91% في الإضافات و9% في القوالب و6 في النواة منخفضة الأولويّة، والوسيط حتى الاستغلال الواسع للثغرات الأكثر استغلالًا 5 ساعات.
4. ‏WordPress، «Upgrading WordPress» (قُرئت في 24 سبتمبر 2026): التحديثات التلقائيّة في الخلفيّة منذ الإصدار 3.7، مفعّلةٌ افتراضيًّا في معظم المواقع.
5. ‏Patchstack، «Critical Supply Chain Compromise on 20+ Plugins by EssentialPlugin» (15 أبريل 2026): بيع الشركة في 2025، وبابٌ خلفيٌّ في تحديث سبتمبر 2025، وتفعيله في أبريل 2026 لزرع برمجيّاتٍ خبيثةٍ في آلاف المواقع.
6. ‏WordPress، «Roles and Capabilities» (قُرئت في 24 سبتمبر 2026): الأدوار Administrator وEditor وAuthor وContributor وSubscriber، وSuper Admin في الشبكات.
7. ‏Cloudflare، «Managed rules» (قُرئت في 24 سبتمبر 2026): Cloudflare Free Managed Ruleset متاحةٌ في كلّ الخطط، تحمي من الثغرات عالية الأثر والواسعة الاستغلال.
8. ‏Cloudflare، «DDoS protection: About» (عُدّلت في 15 أبريل 2026): حمايةٌ غير محدودةٍ ولا تُحسب بالاستهلاك في الطبقات 3 و4 و7 لكلّ العملاء في كلّ الخطط.
9. ‏US-CERT، «Data Backup Options» (2012، من إعداد جامعة كارنيغي ميلون): قاعدة 3-2-1، ثلاث نسخٍ على نوعين من الوسائط وواحدةٌ خارج المكان.
10. ‏NCSC، «Offline backups in an online world» (قُرئت في 24 سبتمبر 2026): برمجيّات فديةٍ شفّرت البيانات الأصليّة وأقراص USB والتخزين الشبكيّ المتّصل الحامل للنسخ، وأصابت تخزينًا سحابيًّا متّصلًا.
11. ‏CISA، «Back Up Business Data» (قُرئت في 24 سبتمبر 2026): اختبارات استعادةٍ مجدولة، وتحديد هدف نقطة الاستعادة RPO وهدف زمن الاستعادة RTO ومراجعتهما.
12. ‏Google Search Console Help، «Security issues report» (قُرئت في 24 سبتمبر 2026): يعرض التقرير نتائج Google إن حكمت بأنّ الموقع مخترق، والصفحات المصابة قد تظهر بعلامة تحذيرٍ في النتائج أو بصفحة تحذيرٍ في المتصفّح، والمراجعة بعد الإصلاح تستغرق من أيّامٍ إلى أسابيع.