WP Toolkit Security Hardening مجموعه‌ای از Security Measureها برای کاهش برخی از ریسک‌های متداول WordPress است.

WP Toolkit می‌تواند وضعیت امنیتی یک WordPress Installation را بررسی کرده و اقداماتی مانند:

• محدود کردن دسترسی به فایل‌های حساس
• غیرفعال کردن برخی قابلیت‌های غیرضروری WordPress
• بررسی Permission فایل‌ها و Directoryها
• محدود کردن اجرای PHP در برخی مسیرها
• غیرفعال کردن Pingback
• محافظت از wp-config.php

را اعمال کند.

WP Toolkit این تنظیمات را Security Measures می‌نامد و برخی از آن‌ها را به‌عنوان Critical در نظر می‌گیرد. طبق مستندات Plesk، Critical Security Measureها روی WordPress Installationهای جدید ایجادشده توسط WP Toolkit به‌صورت خودکار اعمال می‌شوند.

با این حال، اعمال تمام گزینه‌های Hardening بدون بررسی می‌تواند روی عملکرد بعضی Pluginها یا سرویس‌های WordPress تأثیر بگذارد. به همین دلیل قبل از اعمال تغییرات بهتر است Backup تهیه شده و هر Security Measure جداگانه بررسی شود.

WP Toolkit Security Hardening چیست؟

WP Toolkit یک مجموعه بررسی امنیتی برای WordPress در اختیار Administrator قرار می‌دهد.

این بررسی‌ها تنها به WordPress Dashboard محدود نیستند و بسته به Security Measure می‌توانند روی قسمت‌های مختلفی مانند:

WordPress Configuration
File Permissions
Web Server Configuration
wp-config.php
XML-RPC
wp-content

تغییر ایجاد کنند.

در نتیجه Hardening در WP Toolkit با نصب یک Security Plugin ساده تفاوت دارد.

برای مثال، گزینه:

Block access to sensitive files

می‌تواند Ruleهایی در تنظیمات Apache یا Nginx ایجاد کند تا دسترسی مستقیم به فایل‌های حساس مسدود شود. Plesk تأیید می‌کند که این Security Measure می‌تواند Ruleهای مربوطه را به Virtual Host Configuration اضافه کند.

دسترسی به WP Toolkit

مسیر دسترسی به WP Toolkit بسته به Control Panel متفاوت است.

در Plesk

معمولاً از:

WordPress

یا:

Websites & Domains
→ WordPress

می‌توان وارد WP Toolkit شد.

در cPanel

در cPanel معمولاً مسیر:

cPanel
→ Domains
→ WP Toolkit

است.

cPanel مستند می‌کند که دسترسی کاربران به WP Toolkit می‌تواند توسط Hosting Provider از طریق Feature Manager فعال یا غیرفعال شود.

بنابراین اگر WP Toolkit را مشاهده نمی‌کنید، ممکن است این قابلیت در Hosting Plan شما فعال نشده باشد.

بررسی وضعیت Security سایت

WP Toolkit را باز کرده و WordPress Installation موردنظر را پیدا کنید.

در Card مربوط به سایت قسمتی با عنوان:

Security

وجود دارد.

بسته به وضعیت سایت، ممکن است پیامی مانند:

Apply critical security measures

یا:

Critical security measures applied

یا:

All security measures applied

مشاهده شود.

طبق مستندات فعلی WP Toolkit:

قبل از Security Hardening بکاپ بگیرید

قبل از اعمال Security Measureها بهتر است از WordPress Backup تهیه کنید.

حداقل:

Website Files
+
Database

را Backup کنید.

این موضوع مخصوصاً زمانی اهمیت دارد که قصد دارید:

Apply All

را اجرا کنید.

Plesk نیز صراحتاً توصیه می‌کند قبل از Securing یک WordPress Installation از آن Backup گرفته شود، زیرا بعضی Security Measureها قابل Revert نیستند.

ایجاد بکاپ و ریستور دستی وردپرس

اعمال Security Hardening روی یک سایت

برای یک WordPress Installation:

WP Toolkit
→ choose the site
→ Security

را باز کنید.

روی وضعیت Security کلیک کنید.

برای مثال:

Apply critical security measures

WP Toolkit لیست Security Measureهای قابل اعمال را نمایش می‌دهد.

در این قسمت می‌توانید:

Critical Measures
Recommended Measures

را مشاهده کنید.

سپس Measureهای موردنظر را انتخاب کنید و:

Secure

را بزنید.

برای فعال‌سازی تمام Measureهای موجود نیز ممکن است گزینه:

Apply All

در دسترس باشد. این Workflow در مستندات رسمی WP Toolkit نیز ذکر شده است.

آیا باید Apply All را بزنیم؟

نه الزاماً.

برای یک WordPress Installation جدید و ساده ممکن است تمام Security Measureها بدون مشکل قابل استفاده باشند.

اما در سایتی که دارای:

• Pluginهای قدیمی
• Integration خارجی
• XML-RPC
• Custom Application
• Custom .htaccess
• API Integration
• Cache Plugin خاص

است، بهتر است قبل از Apply All هر Measure بررسی شود.

رویکرد مناسب‌تر:

Backup
   ↓
Apply Critical Measures
   ↓
Test Website
   ↓
Review Recommended Measures
   ↓
Apply Selected Measures
   ↓
Test Again

Critical و Recommended چه تفاوتی دارند؟

WP Toolkit Security Measureها را از نظر اهمیت دسته‌بندی می‌کند.

Critical

مواردی هستند که WP Toolkit اهمیت امنیتی بیشتری برای آن‌ها در نظر گرفته است.

Plesk توصیه می‌کند تمام Critical Security Measureها اعمال شوند.

Recommended

این موارد Hardening بیشتری ایجاد می‌کنند، اما ممکن است برای تمام سایت‌ها مناسب نباشند.

بنابراین Recommended به معنی:

Enable blindly on every website

نیست.

موارد و شیوه نمایش این تنظیمات در بخش security measures بین کنترل پنل‌های مختلف متفاوت است.

Security Measureهای مهم WP Toolkit

لیست دقیق Security Measureها می‌تواند با توجه به:

WP Toolkit Version
Operating System
Web Server
Control Panel
License

متفاوت باشد.

این لیست مربوط به یک سیستم لینوکسی با کنترل پنل cPanel می‌باشد:

اما در ادامه تعدادی از Measureهای مهم و رایج را بررسی می‌کنیم.

Block access to wp-config.php

فایل:

wp-config.php

یکی از حساس‌ترین فایل‌های WordPress است.

این فایل معمولاً شامل:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

و سایر Configurationهای مهم سایت است.

Security Measure مربوطه دسترسی مستقیم Web Request به این فایل را محدود می‌کند.

به‌طور معمول Browser نباید بتواند محتوای:

https://example.com/wp-config.php

را دریافت کند.

WP Toolkit برای این Protection می‌تواند Rule مربوطه را در تنظیمات Web Server ایجاد کند. Plesk نیز این Measure را در مستندات و Support Cases خود به‌عنوان یکی از Security Rules معرفی کرده است.

پیشنهاد

در بیشتر سایت‌ها این Measure باید فعال باشد.

Block access to sensitive files

WordPress و Pluginها ممکن است فایل‌هایی مانند:

readme.html
license.txt
*.bak
*-config.php
*-sample.php

داشته باشند.

بعضی از این فایل‌ها می‌توانند اطلاعات غیرضروری درباره Application یا Configuration در اختیار Visitor قرار دهند.

WP Toolkit دارای Security Measure برای محدود کردن دسترسی به این نوع فایل‌ها است.

Plesk مستند کرده که فعال بودن این Measure می‌تواند برای فایل‌های حساس Rule ایجاد کرده و دسترسی مستقیم به آن‌ها را با 403 Forbidden متوقف کند.

نکته مهم

اگر بعد از فعال کردن این گزینه مشاهده کردید URL خاصی با:

403 Forbidden

مواجه شده است، بررسی کنید نام File یا URL با Security Rule مربوط به Sensitive Files تطابق نداشته باشد.

در چنین شرایطی 403 الزاماً مشکل Web Server نیست؛ ممکن است نتیجه مستقیم Security Hardening در WP Toolkit باشد.

Turn off Pingbacks

WordPress از Pingback برای اطلاع‌رسانی بین سایت‌هایی که به یکدیگر Link می‌دهند استفاده می‌کند.

Pingback از XML-RPC استفاده می‌کند و در گذشته برای Abuse و DDoS Amplification نیز مورد استفاده قرار گرفته است.

WP Toolkit می‌تواند Pingback را غیرفعال کند.

Plesk این گزینه را به‌صورت:

Turn off pingbacks

در Security Measureهای WP Toolkit ارائه می‌کند.

پیشنهاد

اگر سایت واقعاً به Pingback نیاز ندارد، غیرفعال کردن آن معمولاً منطقی است.

Block unauthorized access to xmlrpc.php

فایل:

xmlrpc.php

امکان Remote Communication با WordPress را فراهم می‌کند.

بعضی سرویس‌ها و Applicationها ممکن است از XML-RPC استفاده کنند.

WP Toolkit می‌تواند دسترسی به این Endpoint را محدود کند.

Plesk نیز برای برخی Vulnerabilityها گزینه:

Block unauthorized access to xmlrpc.php

را به‌عنوان یکی از Security Measureها ارائه می‌کند.

آیا باید xmlrpc.php را همیشه Block کنیم؟

خیر.

قبل از Block کردن آن بررسی کنید سایت از قابلیت‌هایی مانند:

• Remote Publishing
• Mobile Application
• برخی Integrationهای خارجی
• Pluginهایی که به XML-RPC وابسته هستند

استفاده نکند.

اگر سایت به XML-RPC نیاز دارد، ممکن است Block کامل آن باعث اختلال شود.

در چنین شرایطی غیرفعال کردن فقط:

Pingbacks

می‌تواند گزینه کم‌ریسک‌تری باشد.

Plesk نیز در یکی از Security Advisories خود بین غیرفعال کردن کامل xmlrpc.php و فقط Turn Off کردن Pingbacks تفاوت قائل شده است.

بررسی Permission فایل‌ها و Directoryها

Permission نادرست می‌تواند یکی از عوامل مهم Security Problem در Hosting Environment باشد.

برای مثال Permissionهای بسیار باز مانند:

777

می‌توانند دسترسی غیرضروری به Fileها ایجاد کنند.

WP Toolkit می‌تواند Permission فایل‌ها و Directoryهای WordPress را بررسی کرده و در صورت نیاز اصلاح کند.

Plesk حتی برای کاهش Symlink-related Risk توصیه می‌کند در WP Toolkit بررسی شود که Measure مربوط به:

Permissions for files and directories

در وضعیت OK باشد.

نکته

اگر بعد از تغییر Permission:

• Upload کار نمی‌کند.
• Cache ایجاد نمی‌شود.
• Plugin Update Error می‌دهد.
• WordPress فایل ایجاد نمی‌کند.

فقط Permission را روی 777 قرار ندهید.

Ownership و Hosting Configuration را نیز بررسی کنید.

غیرفعال کردن PHP Execution در Directoryهای غیرضروری

یکی از روش‌های رایج Hardening جلوگیری از اجرای PHP در Directoryهایی است که معمولاً نباید PHP Script اجرا کنند.

برای مثال:

wp-content/uploads

معمولاً برای Media Fileها استفاده می‌شود.

اگر یک File مخرب مانند:

shell.php

در Upload Directory قرار گیرد، جلوگیری از اجرای PHP می‌تواند مانع Execution مستقیم آن شود.

WP Toolkit در بعضی Environmentها Security Measureهایی برای محدود کردن PHP Execution در مسیرهای Upload یا Cache ارائه می‌کند.

نکته

در سایت‌های استاندارد این Hardening معمولاً مفید است.

اما بعضی Pluginها ممکن است ساختار غیرمعمولی داشته باشند و فایل PHP قابل اجرا در Directoryهای خاص ایجاد کنند.

بنابراین پس از اعمال Measure سایت را تست کنید.

Disable file editing in WordPress Dashboard

WordPress به‌صورت پیش‌فرض می‌تواند امکان Edit بعضی فایل‌های Theme و Plugin را از Dashboard فراهم کند.

Hardening می‌تواند File Editing را غیرفعال کند.

از نظر عملی این کار باعث می‌شود در صورت Compromise شدن Administrator Account، مهاجم نتواند به‌سادگی از Editor داخلی WordPress برای تغییر PHP File استفاده کند.

بعد از فعال شدن این گزینه ممکن است:

Appearance
→ Theme File Editor

یا:

Plugins
→ Plugin File Editor

دیگر در Dashboard در دسترس نباشند.

این موضوع روی Frontend سایت تأثیری ندارد و Plugin/Theme Files همچنان از طریق File Manager یا SSH قابل مدیریت هستند.

Disable scripts concatenation for WordPress Admin

WP Toolkit ممکن است گزینه‌ای برای غیرفعال کردن Script Concatenation در WordPress Administrator داشته باشد.

این Measure روی نحوه Load شدن Scriptهای Admin Panel تأثیر می‌گذارد.

این گزینه بیشتر به Hardening بخش Administrator مربوط است و معمولاً روی Frontend سایت تأثیر مستقیمی ندارد.

Plesk نیز وجود این Measure را در توضیحات WP Toolkit تأیید کرده است.

بعد از Hardening سایت را تست کنید

بعد از Apply کردن Security Measureها موارد زیر را بررسی کنید.

Homepage

https://example.com

WordPress Login

/wp-login.php

Dashboard

/wp-admin/

صفحات داخلی

چند Page و Post را باز کنید.

Pluginها

به‌خصوص:

Cache
Security
Forms
WooCommerce
REST/API integrations

Upload

یک Media File آزمایشی Upload کنید.

Forms

Contact Form و سایر Formهای سایت را بررسی کنید.

External Services

اگر سایت به API یا Remote Service متصل است، آن Integration را نیز تست کنید.

Revert کردن Security Measure

یکی از قابلیت‌های مهم WP Toolkit این است که بعضی Security Measureها قابل Rollback هستند.

Measureهای قابل بازگشت با علامتی مشابه:

can be reverted

مشخص می‌شوند.

برای Revert:

WP Toolkit
→ WordPress Site
→ Security

را باز کنید.

Measure موردنظر را انتخاب کرده و:

Revert

را بزنید.

WP Toolkit تغییر مربوطه را بازمی‌گرداند.

همه Security Measureها قابل Revert نیستند

این نکته بسیار مهم است.

طبق مستندات WP Toolkit، بعضی Security Measureها:

can be reverted

هستند و برخی قابل Revert نیستند.

به همین دلیل قبل از Apply کردن Security Measureهای غیرقابل بازگشت Backup داشته باشید.

اگر بعد از Hardening سایت 403 شد

یکی از Errorهایی که ممکن است بعد از Security Hardening مشاهده شود:

403 Forbidden

است.

ابتدا بررسی کنید آیا Security Measureهایی مانند:

Block access to sensitive files
Block access to wp-config.php
XML-RPC protection

اعمال شده‌اند یا خیر.

Plesk یک نمونه مستند دارد که در آن readme.html، license.html و فایل‌های مشابه پس از فعال شدن:

Block access to sensitive files

عمداً با 403 Forbidden مسدود می‌شوند.

بنابراین قبل از تغییر Permission یا Web Server Configuration بررسی کنید 403 نتیجه Hardening نباشد.

اگر Plugin بعد از Hardening کار نکرد

اول مشخص کنید مشکل دقیقاً بعد از فعال شدن کدام Measure ایجاد شده است.

برای مثال:

Website works
        ↓
Enable XML-RPC restriction
        ↓
External service stops working

در این حالت احتمالاً Integration خارجی به XML-RPC وابسته است.

یا:

Enable PHP execution restriction
        ↓
Plugin functionality fails

ممکن است Plugin ساختار File غیرمعمولی داشته باشد.

اگر Measure قابل Revert است:

Security
→ Measure
→ Revert

را اجرا کرده و دوباره سایت را تست کنید.

استفاده از Apply All در سایت Production

روی یک Production Website مهم، بهتر است بدون Test:

Apply All

اجرا نشود.

Workflow مناسب‌تر:

Backup
   ↓
Apply Critical Measures
   ↓
Test Website
   ↓
Apply Recommended Measures
   ↓
Test Again

برای سایت‌های حساس می‌توانید ابتدا Hardening را روی Staging آزمایش کنید.

ایجاد محیط Staging با WP Toolkit

اعمال Security Measures روی چند WordPress Site

WP Toolkit امکان مدیریت Security چند WordPress Installation را نیز دارد.

در WP Toolkit وارد:

WordPress
→ Security
→ Security Measures

شوید.

سایت‌های موردنظر را انتخاب کنید و:

Secure

را بزنید.

در حالت Mass Management می‌توان تعیین کرد:

Critical only

یا:

Custom selection

یا:

All critical and recommended

اعمال شود.

این قابلیت برای Serverهایی که تعداد زیادی WordPress Hosting دارند بسیار کاربردی است.

Automatic Hardening در WP Toolkit

بسته به Edition و License مورد استفاده، قابلیت‌های اضافی WP Toolkit مانند:

1-Click Hardening
Automatic Hardening
Multiple Hardening
Security Rollback

ممکن است در دسترس باشند.

cPanel نیز این قابلیت‌ها را در Feature Matrix مربوط به WP Toolkit فهرست می‌کند.

در Shared Hosting موجود بودن این قابلیت‌ها به License و تنظیمات Hosting Provider بستگی دارد.

Security Hardening با Vulnerability Detection متفاوت است

در نسخه‌های جدید WP Toolkit ممکن است بخش‌هایی مانند:

Security Risk
Vulnerable Components

نیز مشاهده کنید.

این موارد با Security Measures یکسان نیستند.

Security Measures

Configuration سایت را در برابر حملات مقاوم می‌کنند.

Vulnerability Detection

بررسی می‌کند WordPress Core، Theme یا Plugin دارای Vulnerability شناخته‌شده است یا خیر.

برای مثال:

Outdated vulnerable plugin

صرفاً با Protect کردن wp-config.php امن نمی‌شود؛ Plugin باید Update، Replace یا Mitigate شود.

در WP Toolkit 6.10 سیستم Security Risk rating برای مشخص کردن ریسک سایت و Componentها اضافه شده است.

بنابراین Hardening جایگزین Update کردن WordPress نیست.

Security Hardening جایگزین WordPress Update نیست

حتی اگر:

All security measures applied

نمایش داده شود، همچنان باید:

• WordPress Core
• Pluginها
• Themeها

به‌روز نگه داشته شوند.

WP Toolkit نیز Outdated Core، Plugin و Theme را Security Risk در نظر می‌گیرد.

برای Core Update:

آموزش آپدیت هسته وردپرس

برای Pluginها:

آموزش نصب و آپدیت افزونه‌ها

Security Hardening جایگزین Malware Scan نیست

Security Hardening برای کاهش Attack Surface استفاده می‌شود.

اما اگر سایت از قبل آلوده شده باشد:

Security Hardening

Malware موجود را الزاماً شناسایی یا حذف نمی‌کند.

برای سایت آلوده باید:

• Fileها بررسی شوند.
• Core Integrity بررسی شود.
• Pluginها بررسی شوند.
• Database بررسی شود.
• Malware Scan انجام شود.
• Passwordها Reset شوند.
• Backdoorها حذف شوند.

برای این موضوع:

پاکسازی کامل سایت وردپرس آلوده به بدافزار

بررسی WordPress Core Integrity

WP Toolkit قابلیت بررسی Integrity فایل‌های WordPress Core را نیز ارائه می‌کند.

در سایت موردنظر گزینه:

Check WordPress Integrity

را باز کرده و:

Verify Checksums

را اجرا کنید.

WP Toolkit فایل‌های Core را با Checksumهای رسمی WordPress مقایسه می‌کند.

در صورتی که مشکلی وجود نداشته باشد پیام زیر نمایش داده می‌شود:

اگر Core Fileها تغییر کرده باشند، امکان:

Reinstall WordPress Core

نیز وجود دارد.

Plesk اعلام می‌کند این قابلیت در WP Toolkit 5.6 و بالاتر پشتیبانی می‌شود و Reinstall کردن Core محتوای سایت را حذف نمی‌کند، هرچند قبل از آن Backup توصیه می‌شود.

Security Hardening پیشنهادی برای سایت معمولی

به‌صورت کلی می‌توان از این رویکرد استفاده کرد:

این جدول یک Rule مطلق نیست؛ Configuration هر سایت باید جداگانه بررسی شود.

اشتباهات رایج

زدن Apply All بدون Backup

بعضی Security Measureها قابل Revert نیستند.

Block کردن XML-RPC بدون بررسی

ممکن است Integration خارجی سایت متوقف شود.

تصور اینکه هر 403 مشکل Permission است

Security Ruleهای WP Toolkit نیز می‌توانند عمداً 403 ایجاد کنند.

استفاده از 777 برای رفع مشکل

اگر Hardening باعث محدودیت File Access شده، تغییر Permission به:

777

راه‌حل امنی نیست.

تصور اینکه Hardening سایت آلوده را پاک می‌کند

Hardening بیشتر Preventive است، نه Malware Cleanup.

آپدیت نکردن Pluginها بعد از Hardening

Security Measure نمی‌تواند جای Vulnerability Fix را بگیرد.

Hardening Production بدون تست

بعد از هر تغییر مهم، Functionality سایت را بررسی کنید.

Workflow پیشنهادی

برای یک سایت Production:

1. Check WordPress / Plugins / Themes
             ↓
2. Create Backup
             ↓
3. Open WP Toolkit Security
             ↓
4. Review Critical Measures
             ↓
5. Apply Critical Measures
             ↓
6. Test Frontend + wp-admin
             ↓
7. Review Recommended Measures
             ↓
8. Apply appropriate measures
             ↓
9. Test plugins / forms / APIs
             ↓
10. Check Security Status again

اگر مشکلی ایجاد شد:

Identify recently applied measure
             ↓
Check whether it can be reverted
             ↓
Revert
             ↓
Test Website

مطالعه بیشتر

مقالات مرتبط در دانشنامه:

• آموزش آپدیت هسته وردپرس
• آموزش نصب و آپدیت افزونه‌ها
• آموزش فعال‌سازی Auto Update
• ایجاد محیط Staging با WP Toolkit
• استفاده از Smart Updates در WP Toolkit
• فعال‌سازی Two-Factor Authentication در وردپرس
• آموزش افزونه Wordfence Security، نصب و پیکربندی
• پاکسازی کامل سایت وردپرس آلوده به بدافزار

مستندات رسمی:

• Plesk WP Toolkit Documentation
• cPanel WP Toolkit Documentation
• WP Toolkit for cPanel

جمع‌بندی

WP Toolkit Security Hardening مجموعه‌ای از Security Measureها برای کاهش Attack Surface سایت WordPress است.

برای فعال‌سازی آن:

WP Toolkit
→ WordPress Installation
→ Security
→ Select Measures
→ Secure

را باز کنید.

WP Toolkit Security Measureها را به Critical و Recommended تقسیم می‌کند و توصیه می‌شود حداقل Critical Measureها روی سایت اعمال شوند.

با این حال قبل از استفاده از:

Apply All

باید تأثیر هر Measure بررسی شود؛ مخصوصاً گزینه‌هایی که XML-RPC، PHP Execution یا Web Server Access Rules را تغییر می‌دهند.

همچنین بعضی Measureها قابل:

Revert

هستند و برخی قابل بازگشت نیستند، بنابراین تهیه Backup قبل از Hardening اهمیت زیادی دارد.

در نهایت Security Hardening باید در کنار:

WordPress Updates
Plugin Updates
Theme Updates
Backups
Strong Passwords
2FA
Malware Monitoring
Hosting Security

استفاده شود و به‌تنهایی جایگزین سایر لایه‌های امنیتی WordPress نیست.