امنیت وردپرس؛ راهنمای افزایش امنیت و جلوگیری از هک

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

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

در ادامه، می‌خوانید:

• آیا وردپرس امن است؟
• چرا سایت‌های وردپرسی هک می‌ شوند؟
• چگونه امنیت وردپرس را افزایش دهیم؟
• آیا افزونه امنیتی وردپرس برای محافظت از سایت کافی است؟
• نقش هاست در امنیت وردپرس چیست؟
• چگونه بفهمیم سایت وردپرسی هک شده است؟
• اگر سایت وردپرسی هک شد چه کنیم؟
• جمع‌بندی
• سوالات متداول

آیا وردپرس امن است؟

وردپرس سازوکار مشخصی برای بررسی کد، دریافت گزارش آسیب‌پذیری و انتشار اصلاحیه‌های امنیتی دارد. تیم امنیت وردپرس مشکلات گزارش‌شده را بررسی می‌کند و برای رفع آن‌ها، اصلاحیه و آزمون‌های مرتبط را توسعه می‌دهد. بنابراین، هسته وردپرس نرم‌افزاری بدون نظارت امنیتی نیست؛ با این حال، این فرایند به معنی نبود آسیب‌پذیری یا تضمین امنیت تمام سایت‌های وردپرسی نیست.

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

برای ارزیابی امنیت، باید سه پرسش را کنار هم قرار داد:

مهاجم از چه مسیرهایی می‌تواند وارد شود؟ در صورت ورود، به چه بخش‌هایی دسترسی پیدا می‌کند؟ و سایت با چه سرعتی می‌تواند مشکل را تشخیص دهد و به وضعیت سالم برگردد؟ پاسخ این پرسش‌ها، معیار کاربردی‌تری از تعداد افزونه‌های امنیتی نصب‌شده است.

چرا سایت‌ های وردپرسی هک می‌ شوند؟

دلایل نفوذ را می‌توان در چهار گروه بررسی کرد:

• آسیب‌پذیری نرم‌افزار
• استفاده از کد نامعتبر
• ضعف حساب‌های کاربری و پیکربندی نامناسب زیرساخت

۱. استفاده از نسخه‌ های قدیمی وردپرس، قالب و افزونه‌ ها

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

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

۲. نصب قالب و افزونه از منابع نامعتبر

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

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

۳. رمزهای عبور ضعیف و دسترسی‌ های بیش از نیاز

در حمله حدس‌زدن رمز عبور یا بروت فورس (Brute Force)، مهاجم ترکیب‌های مختلفی را برای ورود امتحان می‌کند. در حمله استفاده از اعتبارنامه‌های افشاشده (Credential Stuffing)، نام کاربری و رمزهایی که قبلا از سرویس دیگری افشا شده‌اند، روی سایت شما آزمایش می‌شوند. به همین دلیل، حتی یک رمز پیچیده نیز در صورت استفاده مجدد، انتخاب مناسبی نیست.

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

۴. پیکربندی نامناسب محیط میزبانی

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

عنوان‌هایی مانند “ابری”، “اختصاصی” یا “مدیریت‌شده” به تنهایی کیفیت امنیت را مشخص نمی‌کنند. باید روشن باشد چه کنترل‌هایی اجرا می‌شوند، چه کسی مسئول نگهداری آن‌هاست و در زمان حادثه چه امکاناتی برای بررسی و بازیابی وجود دارد.

چگونه امنیت وردپرس را افزایش دهیم؟

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

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

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

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

برای سایت فروشگاهی، یک روال پیشنهادی این است که تغییرات ابتدا در محیط آزمایشی (Staging) اجرا شوند و مسیرهای اصلی مانند ورود، افزودن محصول به سبد، ثبت سفارش و ارسال فرم بررسی شوند. پس از اعمال تغییر در سایت اصلی نیز همین آزمون‌های ضروری تکرار شوند.

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

۲. افزونه‌ ها و قالب‌ ها را بر اساس نیاز و قابلیت نگهداری انتخاب کنید

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

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

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

۳. ورود به وردپرس را در چند سطح محافظت کنید

برای حساب‌های مهم، به‌خصوص حساب‌های مدیریتی، از رمزهای عبور طولانی و منحصربه‌فرد استفاده کنید و احراز هویت دومرحله‌ای (2FA) را هم فعال کنید. با این کار، حتی اگر رمز عبور یک حساب فاش شود، ورود به سایت همچنان به مرحله تایید دیگری نیاز دارد. در کنار آن، بهتر است تعداد تلاش‌های ناموفق برای ورود نیز محدود شود تا حدس رمز دشوارتر شوند.

یکی از روش‌های انجام این کار، استفاده از محدودیت نرخ درخواست (Rate Limiting) است. این قابلیت جلوی ارسال تعداد زیادی درخواست ورود در مدت کوتاه را می‌گیرد و می‌تواند از طریق افزونه امنیتی، وب‌سرور یا فایروال برنامه وب اعمال شود. البته تنظیمات آن باید به‌درستی انجام شود تا کاربران واقعی به اشتباه مسدود نشوند.

همچنین امنیت ورود را فقط به صفحه ورود وردپرس محدود نکنید. اگر سایت از xmlrpc.php استفاده می‌کند، این مسیر هم باید بررسی و در صورت نیاز محدود شود. غیرفعال کردن XML-RPC زمانی مناسب است که مطمئن باشید سرویس یا ابزاری مانند بعضی اپلیکیشن‌های موبایل و اتصال‌های جانبی به آن وابسته نیست. در مقابل، مسدود کردن کامل مسیر wp-admin می‌تواند بعضی قابلیت‌های وردپرس و درخواست‌های AJAX را دچار اختلال کند؛ بنابراین این بخش را با دقت بیشتری محدود کنید.

۴. نقش کاربران را با وظیفه آن‌ ها هماهنگ کنید

اصل کمترین سطح دسترسی (Least Privilege) یعنی هر کاربر فقط به بخش‌هایی از سایت دسترسی داشته باشد که برای انجام کارش لازم است. برای مثال، در نقش‌های پیش‌فرض وردپرس، مشارکت‌کننده (Contributor) می‌تواند محتوا بنویسد اما امکان انتشار آن را ندارد؛ نویسنده (Author) می‌تواند نوشته‌های خودش را منتشر و مدیریت کند؛ و ویرایشگر (Editor) به محتوای سایر کاربران هم دسترسی دارد. دسترسی مدیر (Administrator) بهتر است فقط در اختیار افرادی باشد که واقعا مسئول مدیریت سایت هستند.

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

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

۵. بکاپ را بر اساس نیاز بازیابی طراحی کنید

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

برای تعیین برنامه بکاپ، دو معیار کاربردی وجود دارد:

• نقطه هدف بازیابی (RPO) مشخص می‌کند داده‌ها پس از اختلال باید تا چه نقطه‌ای از زمان بازیابی شوند؛ در عمل، به تعیین میزان قابل تحمل از دست رفتن داده کمک می‌کند.
• زمان هدف بازیابی (RTO) مشخص می‌کند بازیابی سرویس باید در چه بازه‌ای انجام شود تا پیامد اختلال برای فعالیت کسب‌وکار قابل مدیریت بماند.

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

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

۶. HTTPS را در تمام مسیرهای ضروری فعال کنید

آنچه در خدمات میزبانی با نام “SSL” شناخته می‌شود، در ارتباطات امروزی بر پروتکل TLS متکی است. این پروتکل از محرمانگی و یکپارچگی داده‌های در حال انتقال محافظت می‌کند. بنابراین، اطلاعات ورود و داده‌های فرم‌ها نباید از مسیر ارتباطی رمزگذاری‌نشده منتقل شوند.

پس از نصب گواهی معتبر، آدرس‌های سایت، انتقال درخواست‌های HTTP به HTTPS، منابعی که همچنان با HTTP بارگذاری می‌شوند و فرایند تمدید گواهی را بررسی کنید.

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

define( 'FORCE_SSL_ADMIN', true );

این گزینه، گواهی نصب نمی‌کند و جایگزین تنظیم HTTPS برای تمام سایت نیست. در محیط‌هایی که وردپرس پشت پراکسی معکوس (Reverse Proxy) قرار دارد، تشخیص ارتباط امن نیز باید درست پیکربندی شود؛ در غیر این صورت، احتمال ایجاد حلقه ریدایرکت وجود دارد.

HTTPS از ارتباط محافظت می‌کند، اما آسیب‌پذیری افزونه یا دسترسی غیرمجاز به سرور را برطرف نمی‌کند.

۷. دسترسی به فایل‌ها و تنظیمات حساس را محدود کنید

سطح دسترسی فایل‌ها باید با مالکیت آن‌ها و کاربری که PHP با آن اجرا می‌شود هماهنگ باشد. در بسیاری از سرورهای لینوکسی، مجوز 755 برای پوشه‌ها و 644 برای فایل‌ها رایج است، اما این مقادیر برای همه محیط‌ها مناسب نیستند و باید بر اساس تنظیمات سرور بررسی شوند. فایل‌های حساسی مثل wp-config.php نیز بهتر است با محدودیت بیشتری محافظت شوند. استفاده از مجوز 777 برای حل مشکلات دسترسی توصیه نمی‌شود، چون می‌تواند امکان نوشتن روی فایل‌ها را برای کاربران یا پردازش‌های غیرضروری باز کند.

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

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

define( 'DISALLOW_FILE_EDIT', true );

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

همچنین DISALLOW_FILE_EDIT را با DISALLOW_FILE_MODS اشتباه نگیرید. گزینه دوم محدودیت گسترده‌تری ایجاد می‌کند و می‌تواند نصب و به‌روزرسانی قالب‌ها و افزونه‌ها را هم غیرفعال کند.

نصب افزونه امنیتی وردپرس برای محافظت از سایت کافی است؟

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

آیا نصب چند افزونه امنیتی راهکار مناسبی است؟

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

بهتر است برای هر کنترل، ابزار و مسئول مشخصی داشته باشید. فایروال ممکن است بعضی درخواست‌های مخرب را مسدود کند، اما کد آسیب‌پذیر را اصلاح نمی‌کند. راهکار اصلی برای افزونه آسیب‌پذیر، نصب اصلاحیه یا حذف و جایگزینی آن است.

نقش هاست در امنیت وردپرس چیست؟

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

جداسازی سایت‌ها را از اختصاص منابع تفکیک کنید

اختصاصی بودن CPU و RAM به این معنی نیست که سایت از نظر امنیتی هم کاملا از سایت‌های دیگر جدا شده است. منابع اختصاصی بیشتر به عملکرد سایت مربوط می‌شوند؛ در حالی که امنیت به نحوه جداسازی محیط سایت، محدود بودن دسترسی‌ها و تنظیمات سرور بستگی دارد.

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

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

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

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

امکانات بکاپ و پایش را با نیاز واقعی سایت تطبیق دهید

عبارت “بکاپ خودکار” همه جزئیات لازم را مشخص نمی‌کند. بازه تهیه نسخه، مدت نگهداری، پوشش فایل‌ها و دیتابیس، محل ذخیره و روش بازیابی باید روشن باشد. همچنین، مشاهده نمودار مصرف CPU و RAM با بررسی کامل رویدادهای امنیتی یکسان نیست.

برای نمونه، در معرفی هاست وردپرس لیارا، اجرای سایت در کانتینر ایزوله، منابع اختصاصی، امکان فعال‌سازی SSL و بکاپ روزانه از هاست و دیتابیس با نگهداری در محلی متفاوت ذکر شده است. این امکانات می‌توانند بخشی از نیاز زیرساختی سایت را پوشش دهند، اما همچنان باید با برنامه نگهداری وردپرس و نیاز بازیابی کسب‌وکار هماهنگ شوند.

با خرید هاست وردپرس از لیارا، سایت وردپرسی خود را بهینه و سریع میزبانی کنید.
✅ سرعت بالا ✅ پشتیبانی حرفه‌ای ✅ امنیت و پایداری بالا
خرید هاست وردپرس

چگونه بفهمیم سایت وردپرسی هک شده است؟

همه نفوذها با تغییر صفحه اصلی یا از دسترس خارج شدن سایت همراه نیستند. ممکن است سایت همچنان کار کند، اما حساب غیرمجاز، لینک مخفی یا فایل دست‌کاری‌شده‌ای در آن وجود داشته باشد. در عین حال، کندی یا خطای سایت نیز به تنهایی اثبات‌کننده نفوذ نیست.

نشانه	چه چیزی باید بررسی شود؟
ایجاد حساب مدیریتی ناشناس	سابقه ایجاد حساب و تغییر سطح دسترسی کاربران
ریدایرکت یا لینک‌های بدون مجوز	تغییرات محتوا، قالب، افزونه‌ها و تنظیمات مرتبط
تغییر فایل‌ها خارج از زمان نگهداری	تفاوت فایل‌ها با نسخه سالم و دلیل تغییر
افزایش غیرعادی مصرف منابع	درخواست‌ها، خطاها و فعالیت فرایندهای اجرایی
هشدار مرورگر یا ابزار امنیتی	نوع هشدار، صفحات درگیر و شواهد گزارش‌شده

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

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

اگر سایت وردپرسی هک شد چه کنیم؟

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

۱. دسترسی را کنترل کنید و شواهد را نگه دارید

با مسئول زیرساخت هماهنگ کنید و در صورت لزوم، دسترسی عمومی یا مسیرهای درگیر را محدود کنید. هم‌زمان، از وضعیت فعلی فایل‌ها، دیتابیس و گزارش‌های موجود نسخه‌ای برای بررسی نگه دارید. نسخه آلوده باید جدا از بکاپ‌های سالم و با برچسب مشخص ذخیره شود تا اشتباهی برای بازیابی استفاده نشود.

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

۲. مسیر نفوذ و دامنه تغییرات را بررسی کنید

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

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

۳. فایل‌ ها را با نسخه معتبر مقایسه و پاک‌ سازی کنید

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

برای بررسی اولیه یکپارچگی فایل‌های هسته، در محیط کنترل‌شده و با نسخه قابل اعتماد WP-CLI می‌توان از دستور زیر در پوشه نصب وردپرس استفاده کرد:

wp core verify-checksums

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

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

۴. از بکاپ سالم بازیابی کنید و علت نفوذ را برطرف کنید

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

پس از بازیابی، نسخه‌های آسیب‌پذیر را اصلاح یا جایگزین کنید و دسترسی‌های غیرمجاز را حذف کنید. بازگردانی بکاپ، بدون بستن مسیر ورود، می‌تواند سایت را دوباره در همان وضعیت آسیب‌پذیر قرار دهد.

در سایت فروشگاهی، پیش از جایگزینی دیتابیس، وضعیت سفارش‌ها و تغییرات ثبت‌شده پس از زمان بکاپ را مشخص کنید. داده‌های جدید باید با بررسی سلامت و سازگاری مدیریت شوند، نه اینکه بدون برنامه همراه با بازگردانی از بین بروند.

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

رمزهای مشکوک یا افشاشده باید تغییر کنند. پس از پاک‌سازی نیز رمزهای حساس را دوباره تعویض کنید؛ زیرا تغییر رمز در ابتدای حادثه، زمانی که آلودگی هنوز وجود دارد، پایان فرایند نیست. اگر رمز دیتابیس تغییر کرده است، تنظیمات اتصال وردپرس را نیز هماهنگ کنید.

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

گزارش نهایی حادثه بهتر است مشخص کند چه اتفاقی افتاده، چه بخش‌هایی تغییر کرده، چه اقدام‌هایی انجام شده و کدام کنترل باید اصلاح شود. اگر علت نفوذ روشن نشده است، این ابهام باید در گزارش باقی بماند؛ نبود علائم ظاهری، به تنهایی دلیل کافی برای بسته شدن بررسی نیست.

جمع‌بندی

امنیت وردپرس به نگهداری هماهنگ نرم‌افزار، حساب‌های کاربری و زیرساخت وابسته است. به‌روزرسانی، دسترسی محدود، ورود امن و حفاظت از فایل‌ها احتمال نفوذ را کاهش می‌دهند؛ ثبت رویداد و بررسی تغییرات به تشخیص کمک می‌کنند؛ و بکاپ آزمایش‌شده امکان بازیابی را فراهم می‌کند.

برای تبدیل این توصیه‌ها به کار روزمره، مسئول هر بخش، زمان بازبینی و روش اقدام در شرایط اضطراری را مشخص کنید. ارزش یک کنترل امنیتی زمانی روشن می‌شود که درست اجرا شود، وضعیت آن قابل بررسی باشد و در زمان نیاز بتوان به آن اتکا کرد.

سوالات متداول

۱. آیا وردپرس برای سایت‌های حرفه‌ای امن است؟

وردپرس فرایند توسعه و رسیدگی امنیتی دارد، اما امنیت سایت به وضعیت تمام اجزا وابسته است. استفاده از هسته به‌روز، بدون نگهداری افزونه‌ها، مدیریت کاربران و پیکربندی مناسب زیرساخت، کافی نیست.

۲. مهم‌ترین دلیل هک شدن سایت وردپرسی چیست؟

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

۳. آیا افزونه امنیتی جایگزین به‌روزرسانی می‌شود؟

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

۴. آیا HTTPS مانع هک شدن وردپرس می‌شود؟

HTTPS از داده‌های در حال انتقال محافظت می‌کند. این لایه، ضعف رمز عبور، آسیب‌پذیری افزونه یا دسترسی غیرمجاز به فایل‌های سرور را برطرف نمی‌کند.

۵. هر چند وقت یک‌بار باید از وردپرس بکاپ گرفت؟

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

۶. آیا بازیابی بکاپ برای رفع هک کافی است؟

خیر. بکاپ باید سالم باشد و مسیر نفوذ نیز بسته شود. بعد از بازیابی، بررسی فایل‌ها و کاربران، اصلاح آسیب‌پذیری و تعویض اعتبارنامه‌های درگیر همچنان ضروری است.