تواصل معي منذ فترة عميل يدير مؤسسة حساسة متعلقة بالأمور المالية، وأخبرني أن موقعهم يتعرض لمحاولات اختراق يومية، وبرغم أن برامج الحماية WAF تقوم بعملها وتمنع المخترقين، لكنه لا يزال قلقًا من ثغرات الـ Zero-day غير المعروفة للمطورين والتي قد تظهر في الإضافات وتسمح للمهاجم برفع ملفات خبيثة (Backdoor).
وبسبب طبيعة المؤسسة، طلب مني العميل أن أوفر للموقع أقصى درجات الحماية والأمان، ولهذا قررت تغيير طبيعة السيرفر ليكون بنظام للقراءة فقط (Read-Only)، ففي هذه الحالة حتى لو وجد الهاكر ثغرة وحاول رفع ملف خبيث، لن يتمكن من ذلك.
وسأوضح في هذا المقال كيف فعلت ذلك، وكيف تجاوزت أهم العقبات التي تواجه هذا الإعداد مثل تحديث الإضافات والقالب والتعامل مع الصور.
ما هو مفهوم Read-Only Filesystem؟
في البنية التقليدية لاستضافة ووردبريس، يمتلك خادم الويب سواء كان Apache أو Nginx أو غيرهما صلاحيات الكتابة على مجلدات الموقع، وذلك ليتمكن من رفع الصور وتحديث الإضافات، وتعديل بعض الملفات مثل wp-config.php عند الحاجة.
وبسبب ذلك فإن أي سكربت خبيث يتم حقنه في الموقع بأي طريقة سيرث هذه الصلاحية، ويتمكن من الكتابة داخل الملفات وتعديلها.
ويعني نظام ملفات للقراءة فقط تجريد خادم الويب من صلاحية الكتابة هذه بحيث يصبح الموقع مثل PDF محمي يمكن قراءته وعرضه، لكن لا يمكن لأي كود برمجي التعديل عليه أو إضافة ملفات جديدة، وهذا يمنع السكربتات الخبيثة من العبث بالموقع حتى لو كانت موجودة.
خطوات تشغيل ووردبريس على نظام ملفات للقراءة فقط
لتحويل ووردبريس إلى موقع يعمل بنظام للقراءة فقط، قمت بتنفيذ الخطوات التالية:
1. إخبار ووردبريس أنه لا يسمح بتعديل الملفات
قبل تعديل الصلاحيات في السيرفر، يجب إخبار ووردبريس نفسه بأن يتوقف عن محاولة كتابة الملفات حتى لا تمتلئ سجلات الأخطاء بمحاولات فاشلة، ولإخفاء أزرار التحديث والتنصيب من لوحة التحكم.
ولفعل ذلك استخدمت برنامج FTP للوصول إلى ملف wp-config.php، وأضفت الكود التالي فيه قبل السطر * That's all, stop editing! Happy publishing. */
define( 'DISALLOW_FILE_MODS', true );
إضافة كود يعلم ووردبريس بعدم السماح بالكتابة في ملف wp-config.php
حيث يقوم هذا الكود بأمرين أساسيين:
- يمنع تنصيب أو تحديث الإضافات والقوالب من لوحة التحكم.
- يمنع محرر الملفات (File Editor) داخل ووردبريس.
صفحة الإضافات في الموقع خالية من أزرار التنصيب والتحديث
تغيير مالك الملفات (Owner) ليصبح root
عادة ما تكون ملفات مواقع ووردبريس مملوكة للمستخدم www-data وهو المستخدم الذي يعمل تحته نظام ووردبريس، ولذلك جعلت مالك الملفات هو المستخدم root وأعطيت الخادم صلاحية القراءة فقط.
لفعل ذلك وصلت إلى استضافة الـ VPS الخاصة بموقع ووردبريس عبر تيرمينال (SSH)، ونفذت الكود التالي:
# تغيير المالك إلى الروت
chown -R root:root /var/www/html# إعطاء صلاحية الكتابة والقراءة للمالك فقط، والقراءة فقط للبقية (بمن فيهم السيرفر)
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;علمًا أن /var/www/html يمثل المسار الافتراضي لمجلد الموقع، ويجب عليك تغييره بما يتناسب مع مسار تثبيت ووردبريس على خادمك.
وبهذا عندما يحاول ووردبريس أو أي سكربت خبيث تم حقنه تعديل أي ملف سيرفض نظام تشغيل الخادم هذا الأمر فورًا.
إضافة استثناءات ضرورية
بالطبع من الأفضل أن يكون كامل السيرفر بنظام Read-Only لكن فعليًا تم تصميم ووردبريس والعديد من إضافاته للكتابة في المجلدات لغرضين رئيسيين هما السرعة والتشخيص. وعند تفعيل نظام للقراءة فقط، قد تتوقف بعض الإضافات عن العمل، ولذلك احتجت لفتح ثغرات ضيقة ومدروسة في نظام ملفات للقراءة فقط.
بداية كان العميل يستخدم إضافة WP Rocket للتخزين المؤقت، وتقوم هذه الإضافة بتوليد نسخة HTML ثابتة من صفحات الموقع بالإضافة إلى ملفات CSS و JS مضغوطة، ولإنشاء هذه الملفات يجب أن تتمكن WP Rocket من الكتابة في المجلدات المناسبة.
ولذلك استخدمت الكود التالي لفتح صلاحية الكتابة في مجلد الكاش:
chown -R www-data:www-data /var/www/html/wp-content/cacheكذلك كان الموقع يستخدم إضافة WooCommerce، وتحتاج هذه الإضافة لكتابة سجلات الأخطاء ليتمكن المطورون من مراجعة سبب فشل عملية دفع مثلًا أو أي أخطاء برمجية أخرى، ولذلك استخدمت الأمر التالي في تيرمينال لفتح مجلد سجلات أخطاء ووكومرس للكتابة:
chown -R www-data:www-data /var/www/html/wp-content/uploads/wc-logs
تحديات تشغيل ووردبريس على نظام ملفات للقراءة فقط
تحويل الموقع للقراءة فقط يخلق تحديين رئيسيين يمنعان أغلب المطورين من اعتماد هذا الأسلوب، وإليك كيف قمت بحلهما:
التعامل مع الصور
إذا كان السيرفر للقراءة فقط، عندما يحاول العميل رفع صورة لمقال جديد، ستفشل العملية لأن ووردبريس لا يستطيع الكتابة في مجلد /wp-content/uploads، وهنا يوجد حلان، إما السماح بالكتابة في هذا الملف مع منع تنفيذ السكربتات أو استخدام خدمة تخزين سحابي لتخزين الصور مثل S3.
ولأنني لا أريد تعقيد العملية عبر استخدام خدمة تخزين سحابي، اتبعت الحل الأول، حيث استخدمت الأمر التالي للسماح بالكتابة في المجلد:
chown -R www-data:www-data /var/www/html/wp-content/uploadsثم توجهت إلى ملف إعدادات السيرفر عبر لوحة تحكم الاستضافة فاست بانل وذلك بالنقر على Manual settings.
الوصول إلى ملف إعدادات الخادم
فظهر محتوى ملف الإعدادات وأضفت الكود التالي الذي يمنع تنفيذ ملفات php ضمن server:
location ^~ /wp-content/uploads/ {
# منع تنفيذ ملفات PHP
location ~ \.php$ {
deny all;
return 403;
}
# عرض الصور أو إرجاع خطأ 404
try_files $uri $uri/ =404;
}
إضافة كود منع تنفيذ ملفات PHP
وبعد ذلك استخدمت الأمر التالي في تيرمينال لإعادة تشغيل الخادم:
systemctl reload nginxالتعامل مع التحديثات
بما أن نظام للقراءة فقط يزيل ويمنع تثبيت وتحديث الإضافات عبر لوحة تحكم ووردبريس، وهذا أمر ضروري للاستفادة من أحدث الميزات وتحييد الثغرات الأمنية المكتشفة في الإصدارات القديمة، فقد شرحت للعميل كيف يجري التحديثات اللازمة.
حيث يقوم أولًا بفك الحماية مؤقتًا، إذ يستخدم الأمر التالي لإعادة ملكية ملفات ووردبريس إلى المستخدم www-data والسماح بالكتابة:
chown -R www-data:www-data /var/www/html
ثم يزيل الكود الذي وضعناه في ملف wp-config.php، ويجري التحديثات التي يريدها، ويعيد تنفيذ أوامر للقراءة فقط التي وضحتها.
وختامًا، فإن اعتماد نظام للقراءة فقط هو بمثابة تحويل موقعك من منزل إلى قلعة حصينة. هذا الأمر يضيف طبقة من التعقيد على مهام الإدارة الروتينية، إلا أنه في المقابل يقدم راحة لمديري المواقع الحساسة، لهذا إذا مستعدًا للتخلي عن بعض سهولة الاستخدام وكان موقعك حساسًا، أنصحك باعتماد هذا النظام فورًا للوصول إلى أقصى درجات الأمان.
علي ملص
17 يناير، 2026