آموزش افزایش امنیت وردپرس؛ چک‌لیست سخت‌سازی، فایروال و جلوگیری از هک
🗓 آخرین به‌روزرسانی:
امنیت وردپرس با نصب یک افزونه و فشردن دکمه «اسکن» کامل نمی‌شود. امنیت واقعی مجموعه‌ای از تصمیم‌های هماهنگ درباره به‌روزرسانی، حساب‌های مدیریتی، رمزها، دسترسی‌ها، هاست، فایل‌ها، افزونه‌ها، نسخه پشتیبان، فایروال، مانیتورینگ و واکنش به حادثه است. اگر فقط یکی از این لایه‌ها ضعیف باشد، مهاجم می‌تواند از همان مسیر وارد شود.
بیشتر حملات لزوماً به‌دلیل ضعف هسته وردپرس رخ نمی‌دهند. افزونه یا قالب قدیمی، رمز تکراری، حساب مدیر اضافی، دسترسی فایل اشتباه، هاست ناامن، کد سفارشی بررسی‌نشده یا بکاپ غیرقابل بازیابی می‌تواند کل سایت را در معرض خطر قرار دهد. هدف این مقاله ساخت یک برنامه عملی برای سخت‌سازی وردپرس است؛ نه ایجاد ترس و نه ارائه تنظیماتی که بدون آزمایش سایت را از کار بیندازند.
در این راهنما، امنیت ورود، رمز و 2FA، Passkey، فایروال و Rate Limit، XML-RPC، Application Passwords، افزونه‌ها و قالب‌ها، فایل‌های وردپرس، wp-config.php، دسترسی‌ها، پایگاه داده، SSL، بکاپ، Log، مانیتورینگ، امنیت ووکامرس و برنامه واکنش به هک را مرحله‌به‌مرحله بررسی می‌کنیم.
وضعیت بررسی‌شده سایت: dev-source.ir روی WordPress 7.0.2 و WoodMart 8.3.7 اجرا می‌شود، یک حساب Administrator دارد و چند افزونه عمومی و سفارشی روی آن فعال‌اند. افزونه امنیتی اختصاصی مشاهده نشد. در این مقاله هیچ تنظیم عملیاتی امنیتی بدون Staging، بکاپ و تست مسیرهای ووکامرس تغییر داده نمی‌شود.
امنیت وردپرس دقیقاً یعنی چه؟
امنیت یعنی کاهش احتمال نفوذ، محدودکردن دامنه خسارت و امکان بازیابی سریع. هیچ سایت اینترنتی «صددرصد غیرقابل هک» نیست، اما می‌توان احتمال حمله موفق و اثر آن را به‌شدت کاهش داد.
سه هدف اصلی امنیت:
- محرمانگی: اطلاعات مشتری، مدیر و تنظیمات خصوصی افشا نشوند.
- یکپارچگی: فایل‌ها، محصولات، سفارش‌ها و محتوای سایت بدون مجوز تغییر نکنند.
- دسترس‌پذیری: سایت و Checkout در زمان لازم قابل استفاده بمانند.
یک راهکار امنیتی که Checkout را مسدود یا سایت را دائماً کند کند، راهکار کاملی نیست. امنیت باید با عملکرد و تجربه کاربر هماهنگ باشد.
مرحله اول: از نسخه پشتیبان قابل بازیابی شروع کنید
قبل از هر Hardening، بکاپ کامل بگیرید. بکاپ باید شامل این دو بخش باشد:
- فایل‌های وردپرس، قالب، افزونه‌ها، تصاویر و فایل‌های دانلودی
- پایگاه داده شامل نوشته‌ها، کاربران، تنظیمات، سفارش‌ها و مجوزهای دانلود
بکاپی که فقط روی همان هاست نگهداری می‌شود، در خرابی سرور یا نفوذ گسترده ممکن است همراه سایت از بین برود. حداقل یک نسخه خارج از هاست اصلی داشته باشید و بازیابی آن را آزمایش کنید.
چک‌لیست بکاپ امن
- بکاپ خودکار و زمان‌بندی‌شده باشد.
- نسخه خارج از سرور اصلی نگهداری شود.
- فایل بکاپ عمومی و قابل دانلود نباشد.
- دسترسی به فضای بکاپ محدود و ترجیحاً دومرحله‌ای باشد.
- دوره نگهداری نسخه‌های روزانه، هفتگی و ماهانه مشخص باشد.
- حداقل یک Restore آزمایشی روی Staging انجام شود.
قبل از آپدیت نیز مقاله آموزش به‌روزرسانی امن وردپرس را بررسی کنید.
مرحله دوم: وردپرس، قالب و افزونه‌ها را به‌روز نگه دارید
مهم‌ترین اقدام امنیتی، استفاده از نسخه‌های پشتیبانی‌شده است. وقتی آسیب‌پذیری عمومی می‌شود، سایت‌های قدیمی به هدف خودکار Botها تبدیل می‌شوند.
روال پیشنهادی آپدیت
- بکاپ کامل بگیرید.
- Changelog و سازگاری نسخه‌ها را بررسی کنید.
- آپدیت را روی Staging اجرا نمایید.
- ورود، جست‌وجو، فرم، محصول، سبد، Checkout، درگاه و دانلود را تست کنید.
- آپدیت را در سایت اصلی اجرا کنید.
- Log و خطاهای PHP را کنترل نمایید.
برای افزونه‌های سفارشی که در مخزن رسمی نیستند، تیم توسعه باید فرایند بررسی امنیتی و انتشار نسخه داشته باشد. نبود پیام Update به معنی امن‌بودن کد سفارشی نیست.
افزونه و قالب بلااستفاده را حذف کنید
غیرفعال‌بودن افزونه لزوماً تمام خطر را حذف نمی‌کند؛ فایل‌های آن همچنان روی سرور وجود دارند. هر افزونه و قالبی که نیاز ندارید حذف کنید.
- فقط قالب فعال و یک قالب پشتیبان معتبر نگه دارید.
- افزونه آزمایشی، قدیمی و رهاشده را حذف نمایید.
- نسخه Null یا دانلودشده از منبع ناشناس نصب نکنید.
- افزونه‌هایی با قابلیت تکراری را کاهش دهید.
- قبل از نصب، تاریخ آخرین به‌روزرسانی و سازگاری را بررسی کنید.
راهنمای نصب و ارزیابی افزونه در مقاله آموزش نصب و مدیریت افزونه وردپرس قرار دارد.
مرحله سوم: حساب‌های کاربری را سخت‌سازی کنید
هر حساب مدیریتی یک مسیر ورود بالقوه است. اصل «حداقل دسترسی» می‌گوید هر کاربر فقط به مجوزهای لازم برای کار خود دسترسی داشته باشد.
اقدام‌های ضروری
- حساب مشترک میان چند نفر ایجاد نکنید.
- برای نویسنده، فروشنده و پشتیبان نقش مناسب بسازید.
- حساب مدیر سابق یا همکار جداشده را فوراً غیرفعال یا حذف کنید.
- رمزهای قدیمی و تکراری را تغییر دهید.
- Sessionهای مشکوک را از پروفایل کاربر خارج کنید.
- ایمیل بازیابی حساب مدیر باید امن و در دسترس باشد.
سایت فعلی فقط یک حساب Administrator دارد؛ این موضوع سطح حمله را کاهش می‌دهد، اما امنیت همان حساب بسیار مهم‌تر می‌شود. جزئیات نقش‌ها در مقاله مدیریت کاربران و نقش‌های وردپرس توضیح داده شده است.
رمز قوی و منحصربه‌فرد
رمز مدیر نباید در ایمیل، هاست، شبکه اجتماعی یا سایت دیگر تکرار شود. از Password Manager معتبر برای ساخت و نگهداری رمز طولانی استفاده کنید.
رمز مناسب:
- طول کافی داشته باشد.
- قابل حدس از نام، شماره تلفن یا دامنه نباشد.
- در هیچ سرویس دیگری استفاده نشده باشد.
- از طریق پیام‌رسان عمومی ارسال نشود.
تغییر دوره‌ای رمز بدون دلیل، اگر باعث انتخاب رمز ضعیف‌تر شود، مفید نیست. رمز را پس از نشت، تغییر تیم، دستگاه آلوده یا رخداد مشکوک فوراً عوض کنید.
2FA و Passkey برای مدیران
وردپرس Core در حالت عادی 2FA داخلی ارائه نمی‌کند. برای حساب‌های Administrator و Shop Manager از افزونه معتبر یا Identity Provider استفاده کنید.
- اپلیکیشن TOTP معمولاً از SMS امن‌تر است.
- Recovery Codeها را خارج از سایت نگهداری کنید.
- Passkey با WebAuthn در برابر Phishing مقاومت بیشتری دارد.
- راه بازیابی حساب را قبل از اجباری‌کردن 2FA آزمایش کنید.
2FA برای مشتریان عمومی را فقط در صورت نیاز واقعی اجباری کنید؛ زیرا اصطکاک ورود را افزایش می‌دهد. برای مدیران، این کنترل بسیار ارزشمند است.
Rate Limit و محافظت در برابر Brute Force
Botها می‌توانند هزاران تلاش ورود روی wp-login.php و XML-RPC انجام دهند. دفاع بهتر، مسدودکردن ترافیک مخرب پیش از رسیدن به PHP است.
ترتیب پیشنهادی دفاع
- WAF یا Rate Limit در CDN و لبه شبکه
- قواعد امنیتی هاست و وب‌سرور
- محدودیت تلاش ورود در سطح وردپرس
- Turnstile یا CAPTCHA برای رفتار مشکوک
- 2FA برای کاربران حساس
مسدودکردن دائمی IPهای پراکنده معمولاً کافی نیست، زیرا حملات از Botnet و IPهای متغیر انجام می‌شوند. محدودیت زمانی و تحلیل رفتار مؤثرتر است.
تغییر URL ورود کافی نیست
تغییر مسیر ورود می‌تواند حجم Botهای ساده را کم کند، اما جایگزین 2FA، Rate Limit و WAF نیست. URL جدید ممکن است از طریق لینک‌ها، Source، خطا یا Endpointهای دیگر کشف شود.
این اقدام را یک لایه جانبی بدانید، نه ستون اصلی امنیت.
XML-RPC را آگاهانه مدیریت کنید
xmlrpc.php برای بعضی اپلیکیشن‌های موبایل، ابزارهای انتشار و سرویس‌های خارجی استفاده می‌شود. اگر نیاز ندارید، می‌توانید آن را محدود یا غیرفعال کنید؛ اما قبل از آن وابستگی‌های سایت را بررسی نمایید.
خاموش‌کردن کامل XML-RPC ممکن است Jetpack، اپلیکیشن موبایل یا Integration خاص را مختل کند. گزینه بهتر در بسیاری از سایت‌ها Rate Limit و محدودکردن Methodهای غیرضروری است.
Application Passwords را به‌جای رمز اصلی استفاده کنید
Application Password برای اتصال REST API، اسکریپت، ابزار انتشار یا سرویس خارجی طراحی شده است. این رمز:
- به یک User متصل است.
- برای ورود مرورگری به wp-admin استفاده نمی‌شود.
- فقط یک بار هنگام ساخت نمایش داده می‌شود.
- برای هر Integration جداگانه قابل لغو است.
برای هر اتصال یک Application Password مستقل با نام واضح بسازید و پس از پایان نیاز آن را Revoke کنید. رمز اصلی Administrator را در ابزارهای ثالث وارد نکنید.
سایت فعلی از اتصال AI امن استفاده می‌کند؛ بنابراین Application Password و دسترسی اتصال باید دوره‌ای بازبینی و در صورت تغییر تیم یا نشت احتمالی تعویض شوند.
مرحله چهارم: HTTPS و امنیت ارتباط
تمام صفحات سایت، wp-admin، Login، REST API، Checkout و Callback درگاه باید از HTTPS استفاده کنند. SSL فقط برای صفحه پرداخت نیست.
کنترل‌های لازم
- گواهی معتبر و تمدید خودکار
- Redirect کامل HTTP به HTTPS
- نبود Mixed Content
- URL سایت و وردپرس روی HTTPS
- عدم ارسال رمز FTP در شبکه ناامن
- استفاده از SFTP یا SSH به‌جای FTP ساده
در صورت اطمینان از SSL می‌توان در wp-config.php مدیریت را اجباراً روی HTTPS قرار داد:
define( 'FORCE_SSL_ADMIN', true );این کد را فقط زمانی اضافه کنید که HTTPS و Proxy Headerها درست تنظیم شده باشند؛ در غیر این صورت ممکن است Loop ایجاد شود.
مرحله پنجم: ویرایش فایل از پیشخوان را غیرفعال کنید
وردپرس امکان ویرایش فایل قالب و افزونه از Dashboard را دارد. اگر حساب مدیر هک شود، مهاجم می‌تواند از همین بخش کد مخرب وارد کند.
در wp-config.php می‌توان این قابلیت را غیرفعال کرد:
define( 'DISALLOW_FILE_EDIT', true );این تنظیم نصب یا آپدیت افزونه را متوقف نمی‌کند؛ فقط ویرایشگر داخلی فایل را می‌بندد. تغییر فایل باید از مسیر کنترل‌شده، Child Theme و Version Control انجام شود.
دسترسی فایل‌ها و پوشه‌ها
قاعده عمومی در بسیاری از هاست‌های لینوکسی:
- پوشه‌ها:
755 - فایل‌ها:
644 wp-config.php: محدودتر در صورت سازگاری هاست
از 777 برای حل خطای آپلود استفاده نکنید. این کار دسترسی نوشتن گسترده ایجاد می‌کند. مشکل مالکیت فایل، User وب‌سرور یا تنظیم PHP را از هاست پیگیری کنید.
سطح دقیق به معماری هاست بستگی دارد؛ قبل از تغییر گروهی Permissions بکاپ بگیرید.
حفاظت از wp-config.php
wp-config.php شامل اطلاعات حساس پایگاه داده و کلیدهای امنیتی است. اقدامات پیشنهادی:
- دسترسی فایل را محدود کنید.
- فایل را در Backup عمومی قرار ندهید.
- در صورت پشتیبانی سرور، آن را یک سطح بالاتر از Web Root قرار دهید.
- کلیدها و رمزهای API را داخل Repository عمومی ثبت نکنید.
- در رخداد امنیتی، Credentialهای مرتبط را تعویض کنید.
انتقال فایل بالاتر از Root در همه هاست‌ها یکسان نیست. اگر معماری را نمی‌شناسید، از مدیر سرور کمک بگیرید.
نمایش خطا در سایت اصلی را خاموش کنید
نمایش مستقیم PHP Error می‌تواند مسیر فایل، نام افزونه، Query یا اطلاعات ساختار سرور را افشا کند. روی Production، خطاها باید Log شوند نه برای بازدیدکننده نمایش داده شوند.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );در زمان عیب‌یابی می‌توانید Log را روی Staging فعال کنید. فایل debug.log نیز نباید عمومی باقی بماند.
فایل‌های هسته را ویرایش نکنید
هر تغییر در Core با آپدیت از بین می‌رود و بررسی Integrity را دشوار می‌کند. سفارشی‌سازی را در Child Theme، افزونه اختصاصی یا Must-Use Plugin انجام دهید.
اگر فایل Core تغییر کرده و دلیل مشخصی ندارد، آن را نشانه احتمالی آلودگی در نظر بگیرید و با نسخه رسمی مقایسه کنید.
مرحله ششم: پایگاه داده را امن کنید
- User دیتابیس فقط مجوزهای لازم را داشته باشد.
- رمز دیتابیس قوی و منحصربه‌فرد باشد.
- phpMyAdmin عمومی بدون محافظت رها نشود.
- Backup دیتابیس رمزگذاری یا محدود شود.
- Remote Database Access فقط برای IPهای لازم باز باشد.
تغییر Prefix جدول‌ها می‌تواند Botهای بسیار ساده را گیج کند، اما دفاع اصلی نیست. آسیب‌پذیری SQL Injection باید در کد و Query رفع شود.
مرحله هفتم: افزونه‌های سفارشی را بازبینی کنید
در سایت فعلی چند افزونه سفارشی برای محصول، دانلود و Checkout فعال‌اند. این افزونه‌ها باید مانند یک نرم‌افزار مستقل بررسی شوند:
- کنترل Capability قبل از عملیات مدیریتی
- Nonce برای فرم و درخواست حساس
- Sanitize ورودی و Escape خروجی
- استفاده امن از Queryهای دیتابیس
- عدم افشای Token و Secret در Log
- بررسی Upload و MIME Type
- سازگاری با HPOS و REST API
- فرایند Update و Changelog مشخص
کد سفارشی بدون سیستم نسخه‌بندی و بررسی همتا، ریسک نگهداری و امنیت را بالا می‌برد.
آپلود SVG را کنترل کنید
SVG یک فایل XML قابل برنامه‌ریزی است و در صورت Sanitization ضعیف می‌تواند حاوی محتوای خطرناک باشد. سایت از افزونه Safe SVG استفاده می‌کند؛ بااین‌حال:
- آپلود SVG را به نقش‌های ضروری محدود کنید.
- فایل ناشناس را آپلود نکنید.
- افزونه Sanitizer را به‌روز نگه دارید.
- SVG محصول یا کاربر را بدون بررسی عمومی نکنید.
مرحله هشتم: WAF و امنیت در لبه شبکه
Web Application Firewall می‌تواند Bot، Brute Force، درخواست‌های مخرب و الگوهای شناخته‌شده حمله را قبل از رسیدن به WordPress مسدود کند.
ویژگی‌های مهم
- Rate Limiting برای Login و XML-RPC
- Bot Management
- قواعد OWASP با امکان Exclude هدفمند
- DDoS Protection
- Log درخواست مسدودشده
- امکان Whitelist امن برای Callback درگاه و API
قواعد بیش‌ازحد سخت ممکن است REST API، Admin Ajax، Upload، Checkout یا Callback بانکی را مسدود کنند. هر Rule باید با مسیرهای واقعی تست شود.
امنیت ووکامرس و فروشگاه
سایت فروشگاهی علاوه بر WordPress، داده سفارش، مشتری، دانلود و پرداخت دارد. مسیرهای زیر حساس‌اند:
- Cart و Checkout
wc-ajaxوadmin-ajax.php- REST API و Store API
- Callback و Webhook درگاه
- صفحه
order-pay - My Account و Downloads
این مسیرها نباید با Cache عمومی، CAPTCHA دائمی یا Block کورکورانه مختل شوند. امنیت درگاه در مقاله آموزش درگاه پرداخت ووکامرس توضیح داده شده است.
حفاظت از فایل‌های دانلودی ووکامرس
فایل فروشی نباید با URL مستقیم عمومی قابل دریافت باشد. موارد زیر را کنترل کنید:
- Download Method مناسب انتخاب شده باشد.
- Directory Listing غیرفعال باشد.
- فایل داخل مسیر قابل ایندکس عمومی قرار نگیرد.
- Permission دانلود به سفارش معتبر متصل باشد.
- Limit و Expiry مطابق سیاست فروشگاه تنظیم شوند.
- Log دانلود غیرعادی مانیتور شود.
قرار دادن فایل اصلی در Media Library عمومی ممکن است لینک مستقیم قابل اشتراک ایجاد کند.
مرحله نهم: Log و مانیتورینگ
بدون Log نمی‌توانید بفهمید چه اتفاقی افتاده است. حداقل این موارد را مانیتور کنید:
- ورود موفق و ناموفق مدیران
- ایجاد، حذف یا تغییر نقش کاربر
- نصب و فعال‌سازی افزونه
- ویرایش فایل یا تنظیمات حساس
- تغییر درگاه، ایمیل یا URL سایت
- خطاهای PHP و REST API
- افزایش ناگهانی CPU، Traffic یا 404
- سفارش و Refund غیرعادی
Log نباید رمز، Token، شماره کارت یا داده حساس کامل را ذخیره کند. دوره نگهداری و دسترسی آن را مشخص کنید.
File Integrity Monitoring
Integrity Monitoring فایل‌های Core، قالب و افزونه را با نسخه شناخته‌شده مقایسه می‌کند. هشدار تغییر همیشه به معنی هک نیست؛ آپدیت و Deploy نیز فایل را تغییر می‌دهند.
برای هر هشدار این سؤال‌ها را پاسخ دهید:
- چه فایلی تغییر کرده است؟
- تغییر در چه زمانی رخ داده است؟
- کدام کاربر یا Deploy مسئول بوده است؟
- آیا فایل با نسخه رسمی مطابقت دارد؟
- آیا تغییر همراه Login یا Request مشکوک بوده است؟
امنیت ایمیل مدیر
اگر مهاجم ایمیل مدیر را در اختیار بگیرد، می‌تواند رمز وردپرس، هاست یا درگاه را بازیابی کند. برای ایمیل مدیر:
- 2FA فعال کنید.
- رمز منحصربه‌فرد داشته باشید.
- Recovery Email و شماره بازیابی را کنترل کنید.
- Forward ناشناس و Filter مشکوک را بررسی کنید.
- هشدار Login جدید را فعال نمایید.
راهنمای تحویل ایمیل فروشگاه در مقاله تنظیم ایمیل‌های ووکامرس قرار دارد.
کامپیوتر مدیر هم بخشی از امنیت سایت است
اگر لپ‌تاپ مدیر آلوده باشد، رمز، Cookie ورود و فایل بکاپ می‌تواند سرقت شود.
- سیستم عامل و مرورگر را به‌روز کنید.
- افزونه مرورگر ناشناس نصب نکنید.
- روی Wi-Fi عمومی بدون VPN معتبر وارد مدیریت نشوید.
- دستگاه مشترک برای مدیریت استفاده نکنید.
- دانلودهای ناشناس و فایل کرک‌شده را اجرا نکنید.
- هنگام پایان همکاری Sessionها و دسترسی‌ها را لغو کنید.
امنیت از طریق پنهان‌کاری کافی نیست
کارهایی مانند مخفی‌کردن نسخه وردپرس، تغییر Prefix و تغییر Login URL ممکن است نویز حملات ساده را کم کنند، اما آسیب‌پذیری واقعی را رفع نمی‌کنند.
اولویت صحیح:
- آپدیت و حذف نرم‌افزار رهاشده
- 2FA و حداقل دسترسی
- WAF و Rate Limit
- بکاپ و Restore
- کد امن و مانیتورینگ
- سپس اقدامات Obscurity به‌عنوان لایه کمکی
آیا افزونه امنیتی نصب کنیم؟
افزونه امنیتی معتبر می‌تواند Login Protection، Scanner، Firewall سطح برنامه، 2FA و Log ارائه دهد؛ اما نصب چند افزونه امنیتی هم‌زمان توصیه نمی‌شود.
قبل از انتخاب بررسی کنید
- سازگاری با WordPress و WooCommerce فعلی
- پشتیبانی از REST API، AJAX و Checkout
- مصرف CPU و دیتابیس
- روش Firewall
- حریم خصوصی و ارسال داده به Cloud
- قابلیت Export و حذف Log
- به‌روزرسانی و تیم پاسخ‌گو
افزونه امنیتی جایگزین امنیت هاست، بکاپ و رمز قوی نیست.
برنامه واکنش به هک
پیش از حادثه مشخص کنید چه کسی و با چه ترتیبی اقدام می‌کند.
- علائم را ثبت کنید؛ فایل مشکوک را فوراً پاک نکنید.
- سایت را در صورت نیاز محدود یا Maintenance کنید.
- از وضعیت آلوده یک Snapshot برای بررسی بگیرید.
- Credentialهای مدیر، هاست، دیتابیس، SMTP و API را تغییر دهید.
- Sessionها و Application Passwordها را Revoke کنید.
- فایل Core را با نسخه رسمی جایگزین کنید.
- افزونه و قالب آلوده را پاک و از منبع معتبر نصب کنید.
- پایگاه داده و Userهای جدید را بررسی نمایید.
- بکاپ سالم را فقط پس از بستن مسیر نفوذ Restore کنید.
- مشتریان و مراجع قانونی را در صورت لزوم مطلع کنید.
Restore بدون رفع علت نفوذ باعث آلودگی دوباره می‌شود.
نشانه‌های احتمالی نفوذ
- Redirect ناخواسته یا تبلیغ ناشناس
- User مدیر جدید
- افزونه ناشناخته
- فایل PHP در Uploads
- افزایش ناگهانی مصرف منابع
- ایمیل Spam از دامنه
- هشدار مرورگر یا موتور جست‌وجو
- تغییر درگاه یا شماره حساب
- سفارش و Refund غیرعادی
- کد JavaScript ناشناس در Header و Footer
یک نشانه به‌تنهایی اثبات هک نیست، اما باید بررسی شود.
چک‌لیست امنیت وردپرس
- WordPress، WoodMart و همه افزونه‌ها به‌روز هستند.
- افزونه و قالب بلااستفاده حذف شده‌اند.
- فقط کاربران ضروری دسترسی دارند.
- رمز مدیر منحصربه‌فرد و طولانی است.
- 2FA یا Passkey برای مدیر فعال است.
- WAF و Rate Limit ورود تنظیم شده‌اند.
- XML-RPC براساس نیاز کنترل شده است.
- Application Passwordها نام‌گذاری و بازبینی شده‌اند.
- HTTPS روی تمام مسیرها فعال است.
- FTP ساده استفاده نمی‌شود.
- File Editor غیرفعال است.
- Permissions مناسب‌اند و 777 وجود ندارد.
- خطاهای PHP در Frontend نمایش داده نمی‌شوند.
- افزونه‌های سفارشی بازبینی امنیتی دارند.
- Cart، Checkout و Callback توسط WAF یا Cache خراب نمی‌شوند.
- بکاپ خارج از سرور و Restore آزمایشی وجود دارد.
- Login، تغییر فایل و عملیات حساس Log می‌شوند.
- برنامه واکنش به حادثه نوشته شده است.
📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید
پرسش‌های متداول
آیا وردپرس ذاتاً ناامن است؟
خیر. WordPress Core فرایند امنیتی و به‌روزرسانی فعال دارد. بیشتر ریسک‌ها از نسخه قدیمی، افزونه ناامن، رمز ضعیف، هاست یا پیکربندی نامناسب ایجاد می‌شوند.
بهترین افزونه امنیتی وردپرس کدام است؟
یک پاسخ ثابت وجود ندارد. انتخاب به هاست، WooCommerce، منابع سرور، WAF موجود و نیاز 2FA یا Monitoring بستگی دارد. چند افزونه امنیتی هم‌زمان نصب نکنید.
آیا تغییر wp-admin جلوی هک را می‌گیرد؟
خیر. فقط بخشی از Botهای ساده را کاهش می‌دهد. 2FA، Rate Limit و WAF مهم‌تر هستند.
آیا باید XML-RPC را ببندیم؟
فقط اگر هیچ سرویس وابسته‌ای ندارید. در غیر این صورت آن را Rate Limit و Methodهای غیرضروری را محدود کنید.
آیا نصب SSL برای امنیت کافی است؟
SSL ارتباط را رمزگذاری می‌کند، اما افزونه آسیب‌پذیر، رمز ضعیف یا فایل آلوده را رفع نمی‌کند.
چرا بکاپ جزو امنیت است؟
زیرا پس از نفوذ، خرابی یا باج‌افزار باید بتوانید سایت را از نسخه سالم برگردانید. بکاپ بدون تست Restore قابل اعتماد نیست.
Application Password امن است؟
برای Integration و API طراحی شده و از اشتراک رمز اصلی بهتر است. باید فقط روی HTTPS استفاده، برای هر ابزار جدا ساخته و پس از پایان نیاز لغو شود.
آیا فایل‌های وردپرس را روی 777 بگذاریم؟
خیر. 777 دسترسی نوشتن بسیار گسترده ایجاد می‌کند. مشکل Permission را با مالکیت صحیح و تنظیم هاست حل کنید.
جمع‌بندی
افزایش امنیت وردپرس یک پروژه یک‌باره نیست. امنیت باید به روال نگهداری سایت تبدیل شود: آپدیت منظم، حساب‌های محدود، 2FA، WAF، بکاپ قابل بازیابی، کد سفارشی بازبینی‌شده و Log قابل تحلیل.
برای dev-source.ir مهم‌ترین گام‌های بعدی، راه‌اندازی 2FA برای مدیر، بررسی Application Passwordهای اتصال، تعریف بکاپ خارج از هاست، بازبینی افزونه‌های سفارشی، فعال‌سازی WAF سازگار با WooCommerce و مانیتورینگ تغییر فایل‌هاست. این اقدامات باید ابتدا روی Staging اجرا شوند تا Cart، Checkout، API و دانلود فایل مختل نشوند.
در مقاله‌های بعدی فاز چهارم، هر بخش—بکاپ، امنیت ورود، فایروال، پاک‌سازی سایت هک‌شده و مانیتورینگ—به‌صورت مستقل و عملی بررسی خواهد شد.