راهنمای جامع ایمن سازی فایل wp-config.php و ممانعت از افشای اطلاعات دیتابیس

فایل wp-config.php مغز متفکر و گاوصندوق امنیتی وردپرس است. این فایل حاوی حساس‌ترین اطلاعات کل زیرساخت وب‌سایت شماست: نام پایگاه داده، نام کاربری و کلمه عبور MySQL، آدرس میزبان (DB_HOST)، پیشوند جداول و کلیدهای هش رمزنگاری نشست‌های کاربری (Security Salts).

به محض نشت یا افشای حتی یک سطر از این فایل، مهاجم بدون نیاز به لاگین در پیشخوان یا عبور از احراز هویت دو مرحله‌ای، مستقیماً به دیتابیس متصل شده، جداول را تخلیه (Dump) می‌کند، حساب مدیر ارشد با دسترسی روت ایجاد می‌نماید و کل دارایی دیجیتال کسب‌وکار را تصاحب می‌کند.

بحران اصلی اینجاست که آسیب‌پذیری‌های منتهی به افشای wp-config.php معمولاً ناشی از باگ‌های هسته وردپرس نیستند؛ بلکه حاصل اشتباهات در مدیریت کانفیگ وب‌سرورها، خطاهای اپراتوری در ویرایشگرهای لینوکس، یا اکسپلویت‌های تزریق مسیر فایل (Path Traversal / LFI) در افزونه‌های متفرقه هستند. تکیه بر تنظیمات پیش‌فرضِ پس از نصب وردپرس، سایت را در وضعیت آسیب‌پذیر مطلق رها می‌کند. مقاوم‌سازی این فایل نیازمند پیاده‌سازی هم‌زمان ایزولاسیون سیستم‌فایل، بازتعریف سلسله‌مراتب دسترسی‌های لینوکسی، و فیلترینگ سخت‌گیرانه در لایه وب‌سرور (LiteSpeed / Apache / Nginx) است.

کالبدشکافی ریشه‌ای بردارهای نشت و اکسپلویت wp-config.php

چگونه فایلی که یک اسکریپت سمت سرور است و باید توسط مفسر PHP اجرا شود، به صورت متن ساده (Plain Text) افشا شده یا مورد سوءاستفاده قرار می‌گیرد؟ تحلیل لاگ‌ها در رخدادهای نفوذ نشان می‌دهد این رخداد معمولاً از ۴ معبر فنی رخ می‌دهد:

۱. بارگذاری فایل‌های پشتیبان موقت ناشی از ادیتورها (Text Editor Artifacts)

بسیاری از توسعه‌دهندگان و وب‌مسترها هنگام ویرایش مستقیم فایل با ترمینال یا پنل‌های هاستینگ، از ادیتورهایی مثل Nano یا Vim استفاده می‌کنند، یا پیش از اعمال تغییرات، یک فایل بکاپ با نام‌هایی نظیر wp-config.php.bak، wp-config.php.old، wp-config.php.save یا wp-config.php~ در همان دایرکتوری ایجاد می‌کنند.

مصیبت معماری اینجاست: وب‌سرورها (لایت‌اسپید، آپاچی و انجین‌ایکس) فقط پسوندهایی را که به مفسر PHP نگاشت (Map) شده‌اند (معمولاً پسوندهای منتهی به .php) اجرا می‌کنند. هنگامی که یک اسکنر بدافزار آدرس زیر را درخواست می‌دهد:

GET /wp-config.php.bak HTTP/1.1
Host: example.com

وب‌سرور به دلیل اینکه پسوند نهایی .bak است، آن را به عنوان یک فایل متنی یا باینری معمولی (MIME-Type: text/plain یا application/octet-stream) تشخیص داده و به جای اجرای کد، تمام سورس فایل حاوی کلمات عبور دیتابیس را بی‌درنگ برای دانلود در اختیار مرورگر مهاجم می‌گذارد.

۲. آسیب‌پذیری‌های گنجاندن فایل محلی (Local File Inclusion – LFI) با PHP Wrappers

اگر افزونه‌ای دارای باگ LFI باشد، مهاجم ممکن است نتواند فایل wp-config.php را مستقیماً فراخوانی کند؛ چون فایل اجرا می‌شود و چیزی در خروجی چاپ نمی‌کند. اما نفوذگران از پروتکل‌های استریم اختصاصی PHP به نام PHP Wrappers استفاده می‌کنند:

GET /index.php?page=php://filter/convert.base64-encode/resource=wp-config.php HTTP/1.1
Host: example.com

مفسر PHP پیش از کامپایل کردن فایل، سورس متنی آن را به رشته Base64 تبدیل کرده و در بدنه پاسخ چاپ می‌کند. مهاجم با دی‌کد کردن این رشته، اطلاعات دیتابیس را کاملاً استخراج می‌نماید.

۳. کرش مفسر PHP یا خطای وب‌سرور در پردازش هندلرها

در صورت بروز نقص در سرویس PHP-FPM یا خرابی ماژول LSPHP، برخی وب‌سرورهای با کانفیگ ناقص، در زمان عدم توانایی در ارتباط با سوکت FastCGI، به جای ارسال خطای 502 Bad Gateway، فایل PHP را به عنوان یک فایل متنی دانلودشدنی به مرورگر تحویل می‌دهند.

۴. حملات سمبلیک لینک (Symlink Bypass) در هاست‌های اشتراکی

در سرورهایی که مکانیزم‌های سخت‌گیرانه‌ای مانند CloudLinux CageFS ندارند، مهاجم می‌تواند روی هاست همسایه اسکریپتی اجرا کند که یک پیوند نمادین (Symlink) از مسیر /home/victim/public_html/wp-config.php به پوشه وب خودش بسازد و محتویات کانفیگ سایت قربانی را بدون محدودیت بخواند.

پروتکل اجرایی و گام‌به‌گام ایمن سازی فایل wp-config.php

این پروتکل نیازمند دسترسی به ترمینال لینوکس (SSH) یا ابزار مدیریت فایل کنترل‌پنل است و باید با دقت بالا و رعایت اولویت اجرا شود.

گام ۱: انتقال فیزیکی فایل به یک دایرکتوری بالاتر از ریشه وب (public_html)

معماری هسته وردپرس به صورت بومی دارای یک ویژگی امنیتی عالی است: اگر فایل wp-config.php در روت سایت (public_html) وجود نداشته باشد، وردپرس به صورت خودکار یک پوشه به عقب برگشته و دایرکتوری والد (../wp-config.php) را بررسی می‌کند.

با انتقال فایل به خارج از public_html، وب‌سرور حتی در صورت اشتباه در کانفیگ یا آسیب‌پذیری‌های دانلود فایل، دسترسی به این دایرکتوری نخواهد داشت؛ چرا که خارج از سند وب (Document Root) است.

دستور انتقال در ترمینال لینوکس:

# رفتن به پوشه وب‌سایت
cd /home/USER/public_html

# انتقال فایل به پوشه والد (خارج از دید وب‌سرور)
mv wp-config.php ../wp-config.php

# راستی‌آزمایی حضور فایل در پوشه هوم کاربر
ls -la ../wp-config.php

نکته زیرساختی:
این انتقال تنها زمانی کار می‌کند که وردپرس در یک ساختار عادی نصب شده باشد. اگر سایت دیگری در دایرکتوری والد نصب باشد، وردپرس از فایل بالاتر استفاده نخواهد کرد. همچنین اگر از چندسایته (Multisite) یا دایرکتوری‌های فرعی عمیق استفاده می‌کنید، باید مطمئن شوید سایر سرویس‌ها با این تغییر دچار تداخل مسیر نمی‌شوند.

گام ۲: اعمال پرمیشن‌های محدودکننده و اصلاح مالکیت در سیستم‌فایل

به طور پیش‌فرض، فایل‌های PHP دارای سطح دسترسی 644 هستند که به تمامی فرآیندهای لینوکسی سرور اجازه «خواندن» (Read) می‌دهد. فایل کانفیگ باید قفل شود تا تنها کاربر مالک آن اجازه خواندن داشته باشد:

# تنظیم دقیق سطح دسترسی برای فایل wp-config.php
chmod 400 /home/USER/wp-config.php
# یا در سرورهایی که وب‌سرور با گروه مجزا اجرا می‌شود
chmod 440 /home/USER/wp-config.php

بررسی مالکیت فایل (Ownership):

# اطمینان از اینکه مالکیت فایل متعلق به همان کاربر اکانت لینوکس است
chown USER:USER /home/USER/wp-config.php

# بررسی نهایی وضعیت پرمیشن
ls -l /home/USER/wp-config.php

خروجی مورد انتظار:-r-------- 1 USER USER 3420 Oct 26 15:00 /home/USER/wp-config.php

گام ۳: سد دفاعی چندلایه در وب‌سرورهای آپاچی و لایت‌اسپید (.htaccess)

حتی با وجود انتقال فایل به پوشه بالاتر، برای دفاع در عمق (Defense in Depth) باید قوانین مسدودسازی در وب‌سرور برای فایل wp-config.php و تمام پسوندهای موقت و مشتقات آن وضع شود.

کدهای زیر را در بالاترین سطر فایل /home/USER/public_html/.htaccess (قبل از دستورات وردپرس) درج کنید:

# مسدودسازی دسترسی مستقیم به wp-config.php و تمام فایل‌های بکاپ آن
<FilesMatch "(?i)^wp-config(-sample)?\.php(\.bak|\.old|\.save|\.txt|\.swp|~)?$">
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</FilesMatch>

# مسدودسازی مشاهده و دسترسی به تمام دات‌فایل‌های سیستم لینوکس
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

گام ۴: پیکربندی امنیتی در وب‌سرور Nginx

از آنجا که Nginx از .htaccess تبعیت نمی‌کند، قوانین مسدودسازی باید در بلوک کانفیگ دامنه (/etc/nginx/sites-available/your-domain.conf) تعبیه شوند:

# مسدودسازی دسترسی به wp-config.php و تمام پسوندهای بکاپ آن
location ~* wp-config.* {
    deny all;
    access_log off;
    log_not_found off;
    return 404;
}

# مسدودسازی تلاش برای اجرای کدهای PHP در پوشه‌های آپلود و دات‌فایل‌ها
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
    return 404;
}

پس از ثبت، دستور nginx -t را اجرا کرده و با systemctl reload nginx وب‌سرور را بازنشانی کنید. برگرداندن کد 404 به جای 403 مانع از این می‌شود که اسکنرهای بدافزار به وجود فایل در سرور پی ببرند.

گام ۵: تزریق ثوابت امنیتی اختصاصی درون کدهای wp-config.php

فایل wp-config.php را باز کنید و ثوابت کنترلی زیر را دقیقاً قبل از سطر /* That's all, stop editing! Happy publishing. */ اضافه کنید:

// ۱. غیرفعال کردن ویرایشگر زنده فایل در پیشخوان وردپرس (خنثی‌سازی RCE در صورت تصاحب ادمین)
define( 'DISALLOW_FILE_EDIT', true );

// ۲. مسدودسازی نصب و آپدیت افزونه و قالب از طریق پیشخوان (پیشگیری از آپلود وب‌شل در محیط پروداکشن)
define( 'DISALLOW_FILE_MODS', true );

// ۳. اجبار ورود به بخش مدیریت صرفاً با پروتکل امن SSL
define( 'FORCE_SSL_ADMIN', true );

// ۴. غیرفعال‌سازی دیباگ زنده در نمایشگر کاربران
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// ۵. مسدودسازی درخواست‌های نامتعارف خارجی از سوی وردپرس (اختیاری جهت کنترل ارتباطات سرور)
// define( 'WP_HTTP_BLOCK_EXTERNAL', true );
// define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org' );

گام ۶: چرخش و بازسازی کلیدهای امنیتی (Security Salts) با WP-CLI

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

cd /home/USER/public_html
wp config shuffle-salts --allow-root

این دستور فوراً مقادیر AUTH_KEY، SECURE_AUTH_KEY، LOGGED_IN_KEY و سایر سالت‌ها را به مقادیر رندوم ۶۴ بیتی تازه تغییر می‌دهد و تمامی کاربران (از جمله نفوذگرانی که سشن لاگین فعال دارند) را از سیستم خارج می‌کند.

جدول مقایسه‌ای: ماتریس روش‌های حفاظت از wp-config.php و میزان تاب‌آوری

تکنیک امنیتی	لایه حفاظتی	مقابله با باگ LFI در افزونه	مقابله با دانلود بکاپ موقت	تأثیر بر عملکرد و سرعت	پیچیدگی پیاده‌سازی
انتقال به دایرکتوری والد (../)	سیستم‌فایل (خارج از Web Root)	متوسط (اگر مسیر ../ فیلتر نشود)	۱۰۰٪ (خارج از دسترس وب‌سرور)	بدون هیچ‌گونه افت سرعت	بسیار ساده
پرمیشن chmod 400 / 440	لینوکس (Kernel Permissions)	بالا (کاربران دیگر سرور دسترسی ندارند)	بالا	صفر	ساده (نیازمند ترمینال)
رول‌های فیلترینگ در وب‌سرور	لایت‌اسپید / آپاچی / انجین‌ایکس	ضعیف (در لایه وب قبل از PHP عمل می‌کند)	۱۰۰٪ (مسدودسازی قطعی .bak)	بدون بار پردازشی محسوس	متوسط
غیرفعال‌سازی DISALLOW_FILE_EDIT	هسته وردپرس (Application Logic)	بی‌ارتباط با نشت اطلاعات	بی‌ارتباط با نشت اطلاعات	صفر	بسیار ساده
متغیرهای محیطی (.env بیرونی)	معماری نرم‌افزار (Environment Level)	بسیار بالا (حتی با خواندن فایل رمزی نیست)	۱۰۰٪ (پسورد در فایل کد نیست)	نیاز به پردازش ماژول Dotenv	پیشرفته

هشدار امنیتی و ریسک عملیاتی در لایه سرور
اعمال تغییرات روی فایل wp-config.php ، کوچک‌ترین خطا در سینتکس زبان PHP (مانند جا افتادن یک سیمیکالن یا فاصله نامتعارف قبل از تگ بازشونده <?php) یا تغییر نادرست پرمیشن‌ها در سرورهایی که مالکیت فایل‌ها بر اساس کاربری وب‌سرور مجزا تفکیک شده است، بلافاصله منجر به خطای ۵۰۰ یا صفحه سفید مرگ (WSOD) در تمام بخش‌های فرانت و بک‌اند سایت خواهد شد.
اگر سایت شرکتی یا فروشگاهی پردرآمدی را اداره می‌کنید و می‌خواهید بدون کوچک‌ترین ریسک دان‌تایم، معماری زیرساخت هاست و فایل‌های کانفیگ را مطابق با بالاترین استانداردهای ضد نفوذ مقاوم‌سازی کنید، واگذاری کار به یک متخصص ارشد زیرساخت مطمئن‌ترین رویکرد است. شما می‌توانید برای بررسی جامع و سفت‌سازی قطعی وب‌سایت خود، از خدمات اختصاصی در صفحه امنیت وردپرس یا بسته جامع پشتیبانی وردپرس در وب‌سایت شخصی بهنام باقری استفاده نمایید؛ و در صورتی که احساس می‌کنید اطلاعات دیتابیس لو رفته و تغییراتی مشکوک در جداول به وجود آمده است، از خدمات اورژانسی پاکسازی سایت هک شده بهره‌مند شوید.

خطاهای رایج و بن‌بست‌های متداول

• انتقال فایل به دو دایرکتوری بالاتر (../../wp-config.php): لاجیک پیش‌فرض وردپرس در فایل wp-load.php فقط یک پله به عقب (dirname(__DIR__) . '/wp-config.php') را جستجو می‌کند. اگر فایل را دو لایه بالاتر ببرید، وردپرس صفحه نصب اولیه («به وردپرس خوش آمدید») را نشان می‌دهد که مهاجم می‌تواند با دیتابیس دلخواه سایت را دوباره اینستال کند!
• قرار دادن کدهای پشتیبان در ریشه هاست بدون پسوند مخفی: ساخت فایل‌هایی مثل wp-config-old.php به هیچ وجه ایمن نیست. وب‌سرور این فایل را اجرا می‌کند، اما اگر نام آن wp-config.txt باشد، محتویات را بدون هیچ مانعی به مرورگر می‌فرستد.
• تنظیم پرمیشن‌های بسیار افراطی و ناسازگار (chmod 000): برخی با بستن تمام دسترسی‌ها، حتی اجازه خواندن را از کاربری که PHP با آن اجرا می‌شود می‌گیرند؛ نتیجه این کار خطای فوری Error establishing a database connection در بارگذاری صفحات است.
• تغییر ندادن پسورد دیتابیس پس از کشف نشانه‌های نفوذ: اگر متوجه شدید که یک فایل بکاپ دانلود شده است، قفل کردن فایل کنونی به تنهایی سودی ندارد. باید فوراً وارد کنترل‌پنل سرور شوید، پسورد یوزر دیتابیس را ریست کنید و رمز جدید را درون فایل کانفیگ قرار دهید.

پرسش‌های پرتکرار تکنیکال

۱. آیا انتقال wp-config.php به یک پوشه عقب‌تر برای تمام هاست‌ها و ساختارهای وردپرس امکان‌پذیر است؟

در اکثر هاست‌های لینوکسی اشتراکی و سرورهای اختصاصی که روت سایت در مسیر /home/username/public_html/ قرار دارد، این کار کاملاً ممکن و ایمن است؛ چون یک پوشه عقب‌تر (/home/username/) هنوز درون محدوده دسترسی کاربر قرار دارد اما خارج از دسترسی وب‌سرور است. با این حال، اگر روی یک هاست چند دامنه مجزا (Addon Domain) دارید و روت دامنه دیگر در دایرکتوری بالاتر قرار دارد، یا اگر هاست شما دارای ساختارهای پیچیده Symlink باشد، ابتدا باید یک نسخه تستی ایجاد کنید تا مطمئن شوید وردپرس مسیر را به درستی می‌خواند.

۲. چرا سطح دسترسی ۴۰۰ از ۶۴۴ بسیار امن‌تر است و چه تفاوتی در سیستم‌فایل لینوکس ایجاد می‌کند؟

پرمیشن 644 در لینوکس به معنای این است که: مالک اجازه خواندن و نوشتن دارد (rw-)، گروه اجازه خواندن دارد (r--) و تمام سایر کاربران سرور (Others) نیز اجازه خواندن دارند (r--). در هاست‌های اشتراکی، این اجازه خواندن به سایر کاربران اجازه می‌دهد در صورت نبود ایزولاسیون کرنل، فایل شما را بخوانند. پرمیشن 400 یعنی: فقط و فقط مالک فایل اجازه خواندن دارد (r--------) و هیچ کاربر دیگری (نه گروه و نه دیگران) و حتی خود مالک در حالت عادی اجازه نوشتن یا تغییر فایل را ندارند.

۳. آیا پنهان‌سازی اطلاعات دیتابیس از طریق متغیرهای محیطی (.env) در وردپرس توصیه می‌شود؟

بله، این متد استاندارد توسعه‌دهندگان مدرن (مانند فریمورک Bedrock) است. در این شیوه، اطلاعات اتصال دیتابیس درون یک فایل با فرمت .env در مسیری کاملاً ایزوله خارج از وب قرار می‌گیرد و با پکیج vlucas/phpdotenv در وردپرس فراخوانی می‌شود. بدین ترتیب حتی اگر فایل wp-config.php به دلیل نقص وب‌سرور لو برود یا روی گیت‌هاب عمومی کامیت شود، هیچ نام کاربری یا کلمه عبوری درون کدهای آن نوشته نشده و از افشا در امان می‌ماند.

۴. اگر مهاجم دسترسی LFI داشته باشد، آیا انتقال فایل به بیرون از public_html جلوی حمله را می‌گیرد؟

به تنهایی خیر. اگر مهاجم در آسیب‌پذیری LFI امکان فرستادن رشته‌های پیمایش مسیر مانند ../../wp-config.php را داشته باشد و کاربری وب‌سرور به دایرکتوری بالاتر دسترسی خواندن داشته باشد، باز هم می‌تواند فایل را لود کند. به همین دلیل است که امنیت یک زنجیره چندلایه است: انتقال فایل جلوی اسکنرهای عمومی وب و دانلود فایل را می‌گیرد، پرمیشن ۴۰۰ دسترسی سایر کاربران محلی سرور را مسدود می‌کند، و فایروال WAF یا ماژول ModSecurity رشته‌های LFI را پیش از رسیدن به مفسر PHP خنثی می‌نماید.