المشكلة في الأمان القائم على الإضافات
تعمل إضافة أمان ووردبريس داخل ووردبريس — باستخدام عملية PHP الخاصة بالموقع نفسه، واتصال قاعدة البيانات الخاص به، ووصول الملفات الخاص به. هذا ليس عيبًا بالضبط، إنه فقط كيف تعمل الإضافات. لكنه يعني أن الأداة التي تراقب موقعك تشارك بالضبط نفس سطح الهجوم مثل الموقع نفسه. إذا تم اختراق ووردبريس يومًا ما بمستوى عميق بما يكفي ليهم، فإن الإضافة التي تحميه تتعرض للاختراق معه.
هناك تكلفة ثانية، أكثر هدوءًا: كل إضافة هي المزيد من الكود الذي يجب الحفاظ عليه محدّثًا، والمزيد من مساحة الهجوم لثغرة مستقبلية، وغالبًا بيانات اعتماد أخرى على مستوى المسؤول مخزنة في مكان ما في المكدس. من المفترض أن تقلل أدوات الأمان من مخاطرك، وليس أن تُضاف إلى كومة الأشياء التي يمكن أن تسوء.
ماذا يعني الأمان «من الخارج إلى الداخل» فعليًا
أي شيء يمكن للإضافة قراءته — ملفات ووردبريس الأساسية، وملفات القالب والإضافة، ومجلد التحميلات، وقاعدة البيانات — يمكن الوصول إليه أيضًا بطريقة مختلفة تمامًا: عبر SSH، باستخدام مفتاح مخصص محدود لهذا الغرض. لا تلمس الأداة أبدًا تسجيل دخول مسؤول ووردبريس الخاص بك، ولا تعمل أبدًا كمستخدم ووردبريس، ولا تصبح أبدًا جزءًا من التطبيق الذي تتحقق منه.
بشكل ملموس، هذا يعني:
- فحوصات سلامة الملفات الأساسية تعمل من خلال مقارنة ملفات ووردبريس الفعلية بمجاميع تحقق معروفة أنها سليمة — تتم من جلسة shell، وليس من خطاف PHP داخل ووردبريس.
- فحص البرمجيات الخبيثة والأبواب الخلفية يقرأ مجلدات القالب والإضافة والتحميل مباشرة من القرص، بنفس الطريقة التي سيفعلها محقق بشري عبر SSH.
- فحوصات قاعدة البيانات تتصل باستخدام بيانات اعتماد مقروءة من
wp-config.php، دون إشراك طبقة استعلامات ووردبريس نفسها أو أي من خطافات إضافاته.
- الإصلاحات — عندما تكون آمنة وقابلة للعكس — تُطبَّق بنفس الطريقة: مباشرة على نظام الملفات أو قاعدة البيانات، أبدًا عن طريق تشغيل كود داخل عملية ووردبريس قيد التشغيل.
لماذا SSH بدلاً من تسجيل دخول ووردبريس
يمكن إنشاء مفتاح SSH خصيصًا لغرض واحد، واستيراده إلى مدير المفاتيح لحساب استضافة، وإلغاؤه في أي وقت دون لمس أي شيء آخر بخصوص الحساب — انظر بالضبط كيف في دليل التثبيت الخاص بنا. هذا بصمة أصغر جوهريًا من إضافة تحتفظ بجلسة مسؤول دائمة داخل ووردبريس نفسه. يعني ذلك أيضًا أن أداة الأمان تستمر في العمل حتى لو كان نظام تسجيل الدخول الخاص بووردبريس نفسه هو ما تم اختراقه.
ما لا يستطيع هذا النهج فعله
بصراحة حول المقايضة: تحتاج الأدوات من الخارج إلى الداخل إلى وصول SSH، الذي يوفره معظم المضيفين لكن يقيده أو يعطله البعض افتراضيًا. ولا يمكنها الارتباط ببيئة تشغيل ووردبريس نفسها كما تفعل الإضافة — لذا فهي ليست الخيار المناسب لأشياء مثل تصفية الطلبات في الوقت الفعلي، وهو ما يُستخدم له فعليًا جدار حماية على مستوى DNS. يحل الفحص من الخارج إلى الداخل وجدار الحماية الطرفي مشكلات مختلفة، وتخدم العديد من المواقع جيدًا باستخدام كليهما.
كيف يبدو هذا عمليًا
يُبنى SiftWP بالكامل على هذا النموذج — بدون إضافة، وصول بمفتاح SSH فقط، ووكيل ذكاء اصطناعي يحقق في كل نتيجة قبل تحديد ما هو آمن لإصلاحه تلقائيًا. اطّلع على القائمة الكاملة للمصطلحات التي يعتمد عليها هذا النهج في مسرد الأمان الخاص بنا.