إذا قمت بتثبيت ووردبريس بالإعدادات الافتراضية، فإن جداول قاعدة بياناتك تبدأ بالتأكيد بـ wp_. هذا ليس خطأ، إنه فقط الإعداد الافتراضي. لكنه يعني أيضًا أن كل سكريبت هجوم تلقائي في الخارج يعرف بالفعل بالضبط ما هي أسماء جداولك. تغيير هذه البادئة هو خطوة صغيرة تزيل بهدوء هدفًا سهلاً من موقعك.
لن يمنع هذا مهاجمًا مصممًا بمفرده. لكن الأمان لا يتعلق بحل سحري واحد. بل يتعلق بتكديس حواجز صغيرة إلى أن يتجاوز الجهد المطلوب للاختراق العائد المتوقع منه. وهذا واحد من تلك الحواجز.
ما الذي تفعله بادئة الجدول فعليًا
يخزن كل موقع ووردبريس بياناته في قاعدة بيانات MySQL، مقسمة على جداول مثل wp_posts وwp_users وwp_options. البادئة هي فقط التسمية الملحقة بمقدمة كل اسم جدول. يتيح لك ووردبريس تحديد هذا خلال التثبيت، أو تغييره لاحقًا إذا كنت تعمل على موقع قائم.
لأن wp_ هي الإعداد الافتراضي، فهي أول شيء تحاوله كثير من سكريبتات SQL injection. بعض الهجمات مكتوبة خصيصًا لتخمين أسماء الجداول، وتبدأ بالأكثر شيوعًا. إذا كانت بادئتك غير قابلة للتنبؤ، فإن هذه المحاولات العشوائية التلقائية تفشل قبل أن تبدأ حتى.
لماذا هذا أهم مما تظن
تعمل هجمات SQL injection عبر تمرير استعلامات ضارة داخل حقول النماذج أو معطيات الروابط أو مدخلات أخرى، على أمل أن ينفذها الموقع على قاعدة البيانات. الكثير من هذه الهجمات ليست موجهة خصيصًا لموقعك. إنها سكريبتات عامة تُطلق على آلاف مواقع ووردبريس دفعة واحدة، وتفترض عادة البادئة الافتراضية.
تغيير بادئتك لا يعالج ثغرة في كودك. ما يفعله هو كسر الافتراضات المبنية في هذه السكريبتات المُصنّعة بالجملة. إنه المعادل الرقمي لنقل مفتاحك الاحتياطي من تحت السجادة، وهو تمامًا المكان الذي يتحقق منه كل لص أولاً.
كيف تغيّر بادئة الجداول بأمان
إذا كنت تُنشئ تثبيتًا جديدًا لووردبريس، فهذا سهل. أثناء التثبيت، سترى حقلاً لبادئة الجدول. استبدل wp_ بشيء عشوائي، مثل wp7x2_ أو سلسلة خاصة بموقعك. وانتهى الأمر.
تغيير البادئة في موقع فعلي وقائم أصعب لأنك يجب أن تحدّثه في مكانين بشكل متسق:
- كل اسم جدول في قاعدة البيانات نفسها
- متغيّر $table_prefix في ملف wp-config.php
- أي بيانات مُسلسلة أو مراجع إضافات (plugins) تحتوي على البادئة القديمة بشكل ثابت
هذه هي الخطوات العامة إذا كنت تقوم بذلك يدويًا:
- قم بأخذ نسخة احتياطية كاملة قبل لمس أي شيء. هذه الخطوة غير قابلة للتفاوض.
- أعد تسمية كل جدول في phpMyAdmin (أو عبر أوامر SQL) من wp_tablename إلى newprefix_tablename.
- حدّث جدول wp_options حيث يبدأ option_name بالبادئة القديمة.
- حدّث جدول wp_usermeta حيث يبدأ meta_key بالبادئة القديمة.
- عدّل ملف wp-config.php لتعكس قيمة $table_prefix الجديدة.
- احذف أي ذاكرة تخزين مؤقت واختبر الموقع بشكل شامل، مع فحص الواجهة الأمامية وتسجيل دخول لوحة التحكم ووظائف الإضافات.
هذه بالضبط نوعية المهام التي يمكن أن يؤدي فيها خطأ واحد في جملة SQL إلى تعطيل موقعك بالكامل، لذلك يتجنب كثير من مالكي المواقع القيام بها يدويًا بشكل مفهوم. إضافات مثل Change DB Prefix أو iThemes Security يمكنها أتمتة هذه العملية بأمان، وتنفيذ إعادة التسمية وتحديث المراجع لك بضغطات قليلة.
إذا كنت على استضافة توفر لك أدوات قاعدة بيانات مدمجة في لوحة التحكم، يمكنك أيضًا استخدام أداة بحث واستبدال للعثور على أي مراجع متبقية للبادئة القديمة في قاعدة بياناتك وتحديثها، وهذه غالبًا الخطوة التي ينساها الناس والسبب الذي يجعل تغيير البادئة يعطّل الموقع.
ما لا تحمي منه هذه الخطوة
من المهم أن نكون صادقين بشأن حدود هذا الإجراء. تغيير بادئة الجدول لا يفعل شيئًا ضد:
- كلمات المرور الضعيفة أو هجمات credential stuffing
- الإضافات القديمة ذات الثغرات المعروفة
- محاولات التصيد (phishing) التي تستهدف حساب المسؤول لديك
- هجوم يدوي موجّه بكفاءة حيث يكون شخص ما ينظر فعليًا إلى موقعك بالتحديد
فكر فيها على أنها إزالة للفاكهة المتدلية بسهولة، وليست بناء جدار. تعمل بشكل أفضل جنبًا إلى جنب مع عادات أخرى، كالحفاظ على تحديث البرامج، واستخدام كلمات مرور قوية وفريدة، وتفعيل المصادقة الثنائية على تسجيل دخول ووردبريس. تناولنا أيضًا مكاسب سريعة أخرى في لماذا يجب على معظم المواقع تعطيل XML-RPC، الذي يتبع نفس المنطق: إزالة الأهداف الافتراضية التي تعتمد عليها الهجمات التلقائية.
كلمة عن النسخ الاحتياطية قبل لمس قاعدة البيانات
في أي وقت تُحرر جداول قاعدة البيانات مباشرة، هناك خطر حقيقي من كسر شيء ما، حتى مع قيام إضافة بالعمل الأساسي. قبل أن تبدأ، تأكد من أن لديك نسخة احتياطية حديثة وقابلة للاستعادة. إذا حدث خطأ في منتصف العملية، تريد أن تكون قادرًا على التراجع في دقائق، لا أن تقضي فترة بعد ظهر مليئة بالتوتر تحاول فيها فهم ما حدث. الاستضافة المُدارة التي تُشغّل نسخًا احتياطية تلقائية في الخلفية تمنحك تلك الشبكة الأمنية دون أي جهد إضافي. تعرّف على كيفية عمل النسخ الاحتياطية والاستعادة التلقائية إذا كنت تريد تذكيرًا بما يجب أن يشمله إعداد نسخ احتياطي جيد.
أين يقع هذا في روتين الأمان الأوسع لموقعك
تغيير بادئة الجدول هو مهمة "افعلها مرة وانسها إلى حد كبير". قم بها مرة، تحقق من نجاحها، وانتقل لما بعدها. تترافق بشكل طبيعي مع مراجعة دورية لإعدادات الأمان الأخرى لديك، مثل حمايات تسجيل الدخول، وتحديثات الإضافات، وصلاحيات الملفات. إذا لم تقم بمراجعة كاملة منذ فترة، فإن قائمة فحص أمان ووردبريس الفصلية الخاصة بنا مكان جيد لتنظيم تلك المراجعة.
في بيئة استضافة مُدارة، يمكن التعامل مع بعض هذه الصيانة على مستوى قاعدة البيانات من خلال أدوات مدمجة بدلًا من التحرير اليدوي لـ SQL، مما يقلل من فرصة أن يؤدي خطأ مطبعي بسيط إلى تعطيل موقعك. وفي كل الحالات، يبقى المبدأ الأساسي واحدًا: التغييرات الصغيرة والمتعمدة في إعدادك تجعل الهجمات التلقائية ترتد عن موقعك بدلًا من أن تجد طريقًا سهلاً للدخول.
الخلاصة
تغيير بادئة جداول ووردبريس يستغرق حوالي عشرين دقيقة ونسخة احتياطية جيدة. لن يمنع كل مهاجم، لكنه سيصفّي بهدوء جزءًا كبيرًا من الضجيج التلقائي الذي يضرب مواقع ووردبريس كل يوم. بالجمع بين هذا وبين أفضل ممارسات أمان ووردبريس الأخرى، مثل المصادقة القوية والتحديثات المنتظمة، يصبح هذا طبقة إضافية تجعل موقعك هدفًا أقل جاذبية.
