سایتی را به یاد می‌آورم که مدیرش بعد از خواندن یک راهنما، مجوز فایل wp-config.php را به ۴۰۰ تغییر داد؛ فردا صبح، افزونه پشتیبان‌گیری نمی‌توانست فایل را بخواند و سایت با خطا بالا نمی‌آمد. آن تجربه برای من یادآوری روشنی بود که امن‌سازی wp-config.php درست است، اما اگر بدون درک پیامدها انجام شود، می‌تواند سایت را از کار بیندازد. این نوشته، همان روشی است که در پروژه‌های واقعی برای امن کردن این فایل به‌کار می‌برم.

فایل wp-config.php دقیقاً چه چیزی را نگه می‌دارد؟

فایل wp-config.php، فایل پیکربندی اصلی هر نصب وردپرس است. این فایل، اطلاعاتی را در خود نگه می‌دارد که اگر به‌دست فرد نادرست بیفتد، کل سایت در معرض خطر قرار می‌گیرد. محتوای مهم این فایل شامل موارد زیر است:

  • اطلاعات اتصال دیتابیس: نام دیتابیس، نام کاربری، رمز عبور و میزبان دیتابیس. با این اطلاعات، مهاجم می‌تواند مستقیماً به دیتابیس وصل شود.
  • کلیدهای امنیتی (Salts): کلیدهایی که وردپرس برای رمزنگاری کوکی‌ها و داده‌های نشست استفاده می‌کند.
  • پیشوند جدول‌ها (Table Prefix): پیشوند جدول‌های دیتابیس که به‌طور پیش‌فرض wp_ است.
  • تنظیمات دیباگ: امکان فعال‌سازی حالت دیباگ برای توسعه.
  • تنظیمات مسیرها و ثابت‌های خاص: مثل WP_HOME، WP_SITEURL، DISALLOW_FILE_EDIT و WP_DEBUG.

در تجربه‌ام، بیشتر نشت اطلاعات از سه اشتباه در همین فایل می‌آید: مجوز فایل باز، محتوای فایل در دسترس از مرورگر و کلیدهای امنیتی قدیمی یا مشترک. اگر با مفاهیم پایه‌ای امنیت وردپرس تازه آشنا می‌شوید، ابتدا راهنمای امنیت وردپرس برای مبتدیان و چگونه دیتابیس وردپرس را امن کنیم را بخوانید و بعد به این مقاله برگردید.

wp-config.php مثل گاوصندوق خانه است: هرچه محکم‌تر و پنهان‌تر، امنیت خانه بیشتر. اما اگر گاوصندوق را در وسط پیاده‌رو بگذارید، هیچ قفلی نجاتش نمی‌دهد.

ذهنیت درست: سخت‌سازی تدریجی، نه تغییر یک‌شبه

بزرگ‌ترین اشتباه در امن‌سازی wp-config.php، اعمال همه تغییرات به‌طور هم‌زمان است. سه اصلی که در پروژه‌های واقعی رعایت می‌کنم:

  1. هر تغییر، در محیط staging تست شود: پیش از اعمال روی سایت زنده، همه تغییرات باید در محیط آزمایشی بررسی شوند. تغییر مجوز فایل می‌تواند افزونه‌های پشتیبان‌گیر را غیرفعال کند؛ این موضوع باید در محیط آزمایشی کشف شود.
  2. بکاپ کامل، پیش از هر تغییر: پیش از هر دستکاری در wp-config.php، بکاپ کامل از فایل‌ها و دیتابیس الزامی است.
  3. تغییرات تدریجی: هر تغییر، با فاصله انجام می‌شود تا در صورت بروز مشکل، مقصر قابل شناسایی باشد.

در تجربه‌ام، تیم‌هایی که این سه اصل را رعایت می‌کنند، امنیت را بدون آسیب به سایت اعمال می‌کنند؛ تیم‌هایی که تغییرات یک‌شبه اعمال می‌کنند، معمولاً در صبح روز بعد با خطای سایت روبه‌رو می‌شوند. اصول امنیت عمومی در بهترین روش‌های امنیت وب و اشتباهات امنیتی رایج در وردپرس آمده است.

گام اول: تنظیم مجوز فایل و مالکیت

اولین و ساده‌ترین گام امن‌سازی، تنظیم مجوز فایل (File Permission) است. مجوز درست wp-config.php، در بیشتر سناریوها:

chmod 600 wp-config.php

این عدد به‌معنی دسترسی خواندن و نوشتن فقط برای مالک فایل است؛ نه گروه و نه دیگران. سه نکته در تنظیم مجوز:

  • مجوز ۶۴۰ به‌جای ۶۰۰: اگر هاست شما کاربر وب را با گروه متفاوتی اجرا می‌کند، مجوز ۶۴۰ ممکن است لازم باشد. این مورد در بعضی هاست‌های اشتراکی رایج است.
  • مالکیت درست: فایل باید متعلق به کاربر هاست باشد، نه کاربر دیگری. در سرورهای اشتراکی، مالکیت معمولاً به‌طور خودکار تنظیم می‌شود.
  • پرهیز از ۷۷۷ و ۶۶۶: این مجوزها، دسترسی نوشتن را برای همه باز می‌گذارند و ریسک امنیتی جدی دارند. هیچ‌گاه از این مجوزها برای wp-config.php استفاده نکنید.

در تجربه‌ام، همین یک تغییر کوچک، بزرگ‌ترین کاهش سطح حمله را در فایل پیکربندی می‌سازد. اما باید در محیط staging تست شود؛ چون بعضی افزونه‌ها به دسترسی نوشتن روی این فایل نیاز دارند. راهنمای کامل مجوز فایل در رفع خطاهای دسترسی فایل در وردپرس.

گام دوم: جابجایی فایل به مسیر بالاتر

وردپرس به‌طور پیش‌فرض wp-config.php را در ریشه سایت قرار می‌دهد. یکی از تکنیک‌های امنیتی، جابجایی این فایل به یک پوشه بالاتر از ریشه سایت است. این کار مزیت‌های زیر را دارد:

  • دسترسی از مرورگر مسدود می‌شود: حتی اگر مجوز فایل اشتباه تنظیم شود، فایل از بیرون قابل دسترسی نیست.
  • پنهان‌تر می‌شود: ابزارهای اسکن خودکار که به‌دنبال wp-config.php در ریشه سایت هستند، آن را پیدا نمی‌کنند.
  • در برابر خطای سرور محافظت می‌کند: اگر سرور به‌اشتباه محتوای فایل‌های PHP را نمایش دهد، فایل بالا‌تر در دامنه عمومی نیست.

روش جابجایی:

  1. فایل wp-config.php را به پوشه بالاتر از ریشه سایت منتقل کنید. مثلاً اگر سایت در /public_html/ است، فایل را به /home/username/ منتقل کنید.
  2. در ریشه سایت، فایل جدیدی با نام wp-config.php بسازید که فقط شامل این خط باشد:
<?php
require_once dirname(__FILE__) . '/../wp-config.php';

در تجربه‌ام، این تکنیک در هاست‌های اشتراکی گاهی با محدودیت‌های دسترسی مواجه می‌شود؛ پیش از اعمال روی سایت زنده، باید در staging تست شود. اگر روی VPS کار می‌کنید، این تکنیک بدون مشکل اعمال می‌شود.

گام سوم: کلیدهای امنیتی و چرخش دوره‌ای

کلیدهای امنیتی (Security Keys یا Salts)، بخش مهمی از امنیت wp-config.php هستند. این کلیدها در رمزنگاری کوکی‌ها، داده‌های نشست و سایر مکانیزم‌های امنیتی وردپرس استفاده می‌شوند. سه اقدام در این بخش:

  1. کلیدهای منحصربه‌فرد: کلیدها را از سرویس رسمی وردپرس (WordPress.org Secret Key Service) به‌دست آورید، نه از قالب یا افزونه.
  2. هشت کلید اصلی: وردپرس هشت کلید امنیتی دارد: AUTH_KEY، SECURE_AUTH_KEY، LOGGED_IN_KEY، NONCE_KEY، AUTH_SALT، SECURE_AUTH_SALT، LOGGED_IN_SALT و NONCE_SALT. همه این هشت باید مقدار منحصربه‌فرد داشته باشند:
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');
  1. چرخش دوره‌ای: اگر شک دارید که کلیدها نشت کرده‌اند (مثلاً پشتیبان آلوده یا انتقال ناامن)، همه کلیدها را تغییر دهید. توجه: تغییر کلیدها، همه کاربران را از سایت خارج می‌کند و نیاز به ورود مجدد دارند.

در تجربه‌ام، بیشتر سایت‌هایی که هک شده‌اند، کلیدهای قدیمی و مشترک داشتند؛ همین کلیدها، امکان جعل کوکی و دسترسی بدون رمز را برای مهاجم فراهم می‌کرد. اصول در راهنمای امنیت وردپرس برای مبتدیان آمده است.

کلیدهای امنیتی، مثل قفل در خانه است: اگر قفل را سال‌ها عوض نکنید، حتی اگر کلید را گم نکرده باشید، فرسوده می‌شود. چرخش دوره‌ای، بخشی از نگهداری امنیت است.

گام چهارم: غیرفعال‌سازی ویرایشگر و محدودسازی دسترسی

پس از مجوز و جابجایی، دو اقدام مکمل در امن‌سازی wp-config.php:

  • غیرفعال‌سازی ویرایشگر فایل در پیشخوان: افزودن خط زیر به فایل:
define('DISALLOW_FILE_EDIT', true);

این خط، جلوی ویرایش مستقیم فایل‌های قالب و افزونه از پیشخوان را می‌گیرد. اگر مهاجم به پیشخوان دسترسی پیدا کند، این محدودیت جلوی تغییرات مستقیم در کد را می‌گیرد.

  • محدودسازی دسترسی به دیتابیس از طریق IP: کاربر دیتابیس در wp-config.php باید فقط از localhost یا IP مشخص اجازه اتصال داشته باشد. راهنمای کامل در محدودسازی دسترسی خارجی به دیتابیس.
  • غیرفعال‌سازی دیباگ در سایت زنده: اگر WP_DEBUG روی true تنظیم شده باشد، خطاهای حساس ممکن است به کاربر نمایش داده شود. در سایت زنده، این مقدار باید false باشد:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

در تجربه‌ام، نشت اطلاعات از دیباگ فعال در سایت زنده، یکی از شایع‌ترین مسیرهای نفوذ در سایت‌های تازه‌کار است. خطاها باید فقط در فایل لاگ ذخیره شوند، نه نمایش داده شوند.

گام پنجم: بکاپ و بازیابی

پس از امن‌سازی، باید اطمینان حاصل کرد که در صورت بروز مشکل، بازگشت به وضعیت قبل ممکن است. سه اقدام در این بخش:

  • بکاپ کامل پیش از هر تغییر: فایل‌ها و دیتابیس، به‌طور کامل. راهنما در چگونه از وردپرس بکاپ بگیریم.
  • بکاپ جداگانه از wp-config.php: پیش از هر تغییری در فایل، نسخه اصلی را در جای امن نگه‌داری کنید.
  • تست بازیابی دوره‌ای: بکاپی که بازیابی نشده، ارزشش اثبات نشده است. راهنما در بازیابی سایت از بکاپ.

در تجربه‌ام، سایت‌هایی که بکاپ تست‌شده دارند، پس از هر تغییر در wp-config.php با خیال راحت‌تر پیش می‌روند؛ سایت‌هایی که بکاپ ندارند، در صورت بروز مشکل، ساعت‌ها درگیر می‌شوند.

اشتباهات رایج در امن‌سازی wp-config

در پروژه‌هایی که wp-config.php امن‌سازی شده، چند الگوی تکراری دیده‌ام که می‌تواند سایت را از کار بیندازد:

  • اعمال مجوز ۴۰۰ بدون تست: بعضی افزونه‌ها مثل پشتیبان‌گیر به دسترسی خواندن نیاز دارند؛ با مجوز ۴۰۰، سایت با خطا مواجه می‌شود.
  • استفاده از مجوز ۷۷۷: دسترسی نوشتن برای همه، که ریسک امنیتی جدی دارد.
  • ویرایش مستقیم فایل بدون بکاپ: اگر ویرایش باعث شکست سایت شود، بازگشت بدون بکاپ دشوار است. حتی یک سمیکالن می‌تواند سایت را سفید کند. راهنمای رفع خطا در رفع خطای Parse error در functions.php.
  • کلیدهای تکراری از قالب: بعضی قالب‌ها کلیدهای ثابت مشترک دارند؛ این کلیدها در عمل بی‌فایده هستند.
  • فراموش کردن دیباگ: باقی‌ماندن WP_DEBUG روی true در سایت زنده، خطاها و اطلاعات حساس را برای همه نمایش می‌دهد.
  • جابجایی فایل بدون اطلاع به ابزارهای پشتیبان: بعضی افزونه‌های پشتیبان، مسیر پیش‌فرض را فرض می‌کنند و با جابجایی، نمی‌توانند فایل را پیدا کنند.
  • نبود مستندسازی: اگر تنظیمات wp-config.php مستند نشود، در مهاجرت‌ها یا بازبینی‌ها، تنظیمات کلیدی گم می‌شود.
  • فراموش کردن تنظیم WP_HOME و WP_SITEURL: در سایت‌های روی دامنه‌های متفاوت یا محیط‌های staging، این تنظیمات نبوده و باعث بازگشت آدرس نادرست می‌شود.
  • نبود پایش پس از امن‌سازی: تغییرات امنیتی بدون پایش، ممکن است به‌طور خاموش، خطای جدیدی بسازد.

برای مرور ساختاریافته‌تر، اشتباهات امنیتی رایج در وردپرس، اشتباهات امنیتی رایج در وب و راهنمای امنیت وردپرس برای مبتدیان را ببینید.

پرسش‌های پرتکرار درباره امن‌سازی wp-config

  • چگونه فایل wp-config را امن کنیم؟ با تنظیم مجوز فایل روی ۶۰۰ یا ۶۴۰ و مالکیت درست، جابجایی فایل به پوشه بالاتر از ریشه سایت، استفاده از کلیدهای امنیتی منحصربه‌فرد و چرخش دوره‌ای آن‌ها، غیرفعال‌سازی ویرایشگر فایل در پیشخوان، پرهیز از نمایش خطا در سایت زنده و بکاپ کامل پیش از هر تغییر.
  • مجوز درست wp-config.php چه عددی است؟ ۶۰۰ برای بیشتر سناریوها کافی است؛ ۶۴۰ در بعضی هاست‌های اشتراکی که کاربر وب در گروه متفاوت اجرا می‌شود. هرگز از ۷۷۷ و ۶۶۶ استفاده نکنید.
  • آیا باید wp-config.php را از ریشه سایت جابجا کنیم؟ بله، این تکنیک یکی از مؤثرترین روش‌های امن‌سازی است. اما در محیط staging تست شود تا با افزونه‌های پشتیبان‌گیر تعارض نداشته باشد.
  • کلیدهای امنیتی چند بار عوض شوند؟ در حالت عادی، یک بار در نصب کافی است؛ اما اگر شک به نشت کلیدها وجود دارد (پشتیبان آلوده، انتقال ناامن، یا هک قبلی)، همه کلیدها باید تغییر کنند. تغییر کلیدها، همه کاربران را از سایت خارج می‌کند.
  • آیا امن‌سازی wp-config می‌تواند سایت را از کار بیندازد؟ بله، اگر بدون تست در محیط staging و بدون بکاپ انجام شود. تغییر مجوز یا جابجایی فایل، در بعضی هاست‌ها می‌تواند باعث خطا شود. همیشه با بکاپ و در محیط آزمایشی شروع کنید.

امنیت wp-config، عادت نگهداری نه جراحی یک‌باره

امن‌سازی wp-config.php، مانند بسیاری از اقدامات امنیتی، یک پروژه با شروع و پایان مشخص نیست؛ بخشی از عادت نگهداری سایت است. تجربه‌ام می‌گوید سایت‌هایی که این فایل را به‌طور منظم بازبینی می‌کنند و پیش از هر تغییر، بکاپ می‌گیرند، در برابر بیشتر حملات رایج ایمن می‌مانند؛ سایت‌هایی که این فایل را سال‌ها بدون بازبینی رها می‌کنند، اغلب با حادثه‌های خاموش روبه‌رو می‌شوند. اگر امروز فقط یک کار می‌کنید، همین حالا مجوز wp-config.php سایت خودتان را بررسی کنید؛ اگر روی 644 یا بیشتر است، آن را در محیط staging روی 600 تنظیم کنید. اگر در پروژه‌ای امن‌سازی این فایل را انجام داده‌اید، برای من جالب است بدانید کدام اقدام بیشترین اثر را داشت و کجا با مشکل تعارض افزونه روبه‌رو شدید؛ تجربه‌تان را در دیدگاه‌ها بنویسید تا برای خواننده بعدی، مسیر روشن‌تری ساخته شود. 🔐