وقتی متوجه میشوید سایت وردپرسی هک شده است، بدترین کار این است که بدون برنامه شروع به حذف فایلها، نصب چند افزونه امنیتی یا بازگردانی اولین بکاپی کنید که پیدا میکنید. ممکن است ظاهر سایت برای چند دقیقه بهتر شود، اما اگر راه نفوذ باز بماند یا مهاجم حساب و فایل پنهان ساخته باشد، آلودگی دوباره برمیگردد.
واکنش درست بعد از هک سه هدف دارد: جلوگیری از ادامه آسیب، پاکسازی کامل سایت و بستن راه نفوذ. در این آموزش مراحل را به ترتیبی میرویم که برای مدیر یک سایت وردپرسی قابل اجرا باشد؛ از محدود کردن سایت و حفظ شواهد گرفته تا بررسی کاربران، فایلها، دیتابیس، رمزها، سرچ کنسول و بازگشت امن سایت.
اول مطمئن شوید واقعاً با هک روبهرو هستید
هر خطای عجیب در وردپرس به معنی هک شدن نیست. یک بروزرسانی ناقص، تداخل افزونه یا مشکل هاست هم میتواند سایت را خراب کند. قبل از شروع پاکسازی، نشانهها را کنار هم قرار دهید.
موارد زیر از نشانههای جدیتر هستند:
- انتقال خودکار کاربران به دامنهای که نمیشناسید؛
- ایجاد نوشته، صفحه یا لینکهای اسپم بدون اطلاع شما؛
- وجود کاربر مدیر ناشناس؛
- تغییر ناخواسته صفحه اصلی یا فایلهای سایت؛
- هشدار بدافزار یا فیشینگ در مرورگر و سرچ کنسول؛
- ارسال ایمیلهای ناخواسته از هاست؛
- افزایش ناگهانی مصرف منابع همراه با فایل یا درخواست مشکوک؛
- عدم امکان ورود با رمز درست یا تغییر ایمیل مدیر؛
- فایلهای PHP ناشناس در مسیرهایی که معمولاً نباید چنین فایلهایی داشته باشند.
اگر فقط یک نشانه مبهم میبینید، ابتدا آن را تأیید کنید. اما اگر چند مورد از فهرست بالا همزمان رخ دادهاند، بهتر است سایت را آلوده فرض کنید و مراحل بعدی را انجام دهید.
1. قبل از پاکسازی، وضعیت فعلی سایت را ثبت کنید
در فایل اولیهای که برای این مقاله بررسی شد، تهیه بکاپ از نسخه هکشده پیشنهاد شده بود. این کار درست است، اما باید بدانیم این نسخه بکاپ سالم برای بازگردانی نیست؛ بلکه یک نسخه از وضعیت فعلی سایت است تا اگر هنگام پاکسازی چیزی را از دست دادید یا بعداً لازم شد مسیر نفوذ را بررسی کنید، اطلاعات اولیه باقی مانده باشد.
پیش از حذف فایلها یا بروزرسانی گسترده، این موارد را ثبت کنید:
- زمانی که اولین نشانه هک را دیدید؛
- آدرس صفحهها یا فایلهای مشکوک؛
- اسکرینشات هشدار مرورگر یا سرچ کنسول؛
- فهرست کاربران مدیر؛
- گزارشهای ورود و لاگهای هاست در صورت دسترسی؛
- نسخه فعلی فایلها و دیتابیس.
اگر هاست اشتراکی دارید، همین ابتدا یک تیکت با اولویت بالا برای پشتیبانی بفرستید و از آنها بخواهید لاگهای مربوط به بازه زمانی حادثه را نگه دارند. حذف یا بازنویسی لاگها میتواند پیدا کردن مسیر ورود را دشوار کند.
2. اگر خطر برای کاربران ادامه دارد، سایت را موقتاً محدود کنید
اگر سایت فقط ظاهر نامرتب دارد، لازم نیست فوراً آن را از دسترس خارج کنید. اما اگر بازدیدکننده به سایت ناشناس هدایت میشود، صفحه جعلی پرداخت یا ورود نمایش داده میشود، مرورگر هشدار امنیتی میدهد یا احتمال سرقت اطلاعات وجود دارد، ادامه فعالیت عمومی سایت ریسک را بیشتر میکند.
در این شرایط میتوانید با کمک هاستینگ، فایروال یا تنظیمات سرور، دسترسی عمومی را موقتاً محدود کنید و فقط IP تیم فنی را مجاز نگه دارید. هدف این مرحله جلوگیری از ادامه آسیب است، نه پنهان کردن مشکل.
3. با شرکت هاستینگ تماس بگیرید و دامنه نفوذ را مشخص کنید
یکی از بخشهای مفید مقاله قدیمی همیار وردپرس، تأکید روی تماس با شرکت میزبانی بود. هاستینگ میتواند اطلاعاتی ببیند که شما در پیشخوان وردپرس به آن دسترسی ندارید؛ مانند لاگهای ورود، مصرف منابع، تغییرات حساب میزبانی یا آلودگی احتمالی سایر سایتهای همان حساب.
از پشتیبانی بخواهید این موارد را بررسی کند:
- ورودهای مشکوک به پنل هاست، FTP یا SFTP؛
- تغییر یا ایجاد فایل در زمان حادثه؛
- وجود بدافزار یا فایلهای قرنطینهشده توسط اسکنر سرور؛
- اینکه آیا سایت دیگری روی همان حساب آلوده شده است؛
- وجود بکاپی که قبل از شروع نفوذ تهیه شده باشد.
اگر چند سایت روی یک هاست دارید، فقط سایتی را که علامت واضح دارد بررسی نکنید. مهاجم ممکن است از یک نصب قدیمی وردپرس، سابدامین رهاشده یا نسخه آزمایشی وارد شده باشد و بعد به سایت اصلی رسیده باشد.
4. رمزها و دسترسیهای مهم را از یک دستگاه سالم تغییر دهید
بعد از اینکه وضعیت اولیه ثبت شد، دسترسیهای احتمالی مهاجم را قطع کنید. این کار را ترجیحاً از رایانه یا موبایلی انجام دهید که از سالم بودن آن مطمئن هستید. اگر سیستم شخصی آلوده باشد، تغییر رمز روی همان دستگاه ممکن است رمز جدید را هم در معرض خطر قرار دهد.
حداقل این موارد را بررسی و در صورت احتمال افشا تغییر دهید:
- حسابهای مدیر وردپرس؛
- پنل هاست؛
- SFTP، FTP و SSH؛
- حساب ثبتکننده دامنه و DNS؛
- ایمیل مدیر سایت؛
- رمز دیتابیس؛
- سرویس CDN و فایروال؛
- پنل ایمیل، پیامک و درگاهها در صورت مرتبط بودن با حادثه؛
- کلیدهای API و رمزهای اپلیکیشن.
فقط تغییر رمز مدیر کافی نیست. مستندات رسمی وردپرس درباره سایت هکشده توصیه میکند بعد از نفوذ، کلیدهای امنیتی موجود در wp-config.php نیز تازه شوند تا نشستهای فعلی کاربران بیاعتبار شوند. همچنین رمزهای اپلیکیشن و نشستهای فعال مدیران را بررسی کنید.
5. حسابهای مدیر و دسترسیهای ناشناس را بررسی کنید
به مسیر «کاربران» در پیشخوان بروید و حسابهایی را که نقش مدیر دارند بررسی کنید. اگر کاربری را نمیشناسید، قبل از حذف آن اطلاعاتش را ثبت کنید تا بعداً بتوانید زمان و علت ایجادش را بررسی کنید.
اگر به خط فرمان وردپرس دسترسی دارید، فهرست مدیران را میتوانید با این دستور ببینید:
wp user list --role=administratorعلاوه بر حسابهای وردپرس، این موارد را هم فراموش نکنید:
- کاربران FTP یا SFTP قدیمی؛
- کلیدهای SSH ناشناس؛
- کاربران جدید در پنل هاست؛
- رمزهای اپلیکیشن وردپرس؛
- دسترسی توسعهدهنده یا پیمانکاری که دیگر با سایت کار نمیکند.
6. هسته وردپرس را با نسخه رسمی مقایسه کنید
یکی از امنترین روشها برای بررسی هسته، مقایسه فایلهای موجود با نسخه رسمی وردپرس است. ابزار خط فرمان وردپرس این کار را بدون تکیه به فایلهای فعلی سایت انجام میدهد:
wp core verify-checksums --include-rootاین دستور فایلهای هسته را با مقادیر رسمی وردپرس مقایسه میکند. اگر فایل اصلی تغییر کرده باشد یا فایل ناشناسی در مسیرهای اصلی وجود داشته باشد، باید نتیجه بررسی شود.
اما یک نکته مهم وجود دارد: سالم بودن checksum هسته به معنی پاک بودن کل سایت نیست. بدافزار میتواند داخل wp-content، دیتابیس یا یک فایل تازه ایجادشده قرار داشته باشد.
برای افزونههایی که از مخزن رسمی وردپرس نصب شدهاند نیز میتوان از این دستور استفاده کرد:
wp plugin verify-checksums --all --strictاگر برای افزونه پولی یا اختصاصی پیام «checksum در دسترس نیست» دیدید، آن را بهتنهایی نشانه آلودگی ندانید. برای چنین افزونهای باید فایل سالم را از منبع اصلی تهیه و مقایسه کنید.
7. افزونهها و قالبها را از منبع سالم جایگزین کنید
اگر به پاک بودن فایلهای فعلی اعتماد ندارید، بهتر است فایلهای هسته، قالب و افزونهها را از منبع رسمی یا نسخه سالم جایگزین کنید؛ نه اینکه فقط کدهای مشکوکی را که پیدا کردهاید پاک کنید.
برای افزونه و قالب این اصول را رعایت کنید:
- نسخه جدید و سالم را از منبع اصلی تهیه کنید؛
- افزونه و قالب استفادهنشده را حذف کنید؛
- نسخههای نالشده یا بستههایی که منبع آنها مشخص نیست دوباره نصب نکنید؛
- اگر قالب فرزند یا افزونه اختصاصی دارید، فایلها را با مخزن کد یا نسخه سالم قبلی مقایسه کنید؛
- پوشههای قدیمی سایت و بکاپهای استخراجشده داخل
public_htmlرا هم بررسی کنید.
فایلهای wp-admin و wp-includes باید با نسخه رسمی سازگار باشند. پوشه uploads نیز نیاز به توجه دارد؛ وجود فایل PHP در این مسیر در یک سایت معمولی نشانهای است که باید بررسی شود، هرچند نباید صرفاً بر اساس نام یا پسوند، فایلی را بدون بررسی حذف کرد.
8. فقط فایلها را بررسی نکنید؛ دیتابیس هم میتواند آلوده باشد
یکی از ضعفهای رویکرد قدیمی این است که تمرکز اصلی روی فایلهای وردپرس قرار میگیرد. در حالی که کد مخرب، لینک اسپم یا اسکریپت انتقال میتواند داخل دیتابیس ذخیره شده باشد. خود فایل ورودی نیز به این نکته اشاره کرده که پاکسازی فقط فایلها کافی نیست.
موارد زیر را بررسی کنید:
- کاربران و نقشهای کاربری؛
- آدرس اصلی سایت و وردپرس؛
- نوشتهها و برگههای جدید یا ویرایششده؛
- تنظیمات قالب و ابزارکها؛
- تنظیمات افزونههای امنیتی و تغییرمسیر؛
- کد جاوااسکریپت یا iframe ناشناس؛
- وظایف زمانبندیشده و کارهای تکرارشونده؛
- جدول یا رکوردی که اخیراً و بدون دلیل ساخته شده است.
از اجرای دستورهای گسترده حذف و جایگزینی روی دیتابیس بدون بکاپ خودداری کنید. پاک کردن یک رشته مشکوک با دستور عمومی ممکن است محتوای سالم یا داده سریالشده افزونهها را خراب کند.
9. فایلهای حساس و راههای پایداری مهاجم را بررسی کنید
حذف یک فایل آلوده به معنی پایان نفوذ نیست. مهاجم ممکن است چند راه برای بازگشت ساخته باشد. در یک سایت وردپرسی، این بخشها ارزش بررسی بیشتری دارند:
wp-config.phpبرای تغییرات ناشناس؛.htaccessبرای تغییرمسیر یا کد غیرمنتظره؛wp-content/mu-pluginsبرای افزونههای اجباری ناشناس؛wp-content/uploadsبرای فایل اجرایی مشکوک؛- وظایف زمانبندیشده وردپرس و Cron هاست؛
- نصبهای قدیمی وردپرس در پوشههای فرعی؛
- فایلهای بکاپ یا ابزارهای مدیریتی قدیمی که از وب در دسترس ماندهاند.
اگر بعد از پاکسازی، فایلهای مخرب دوباره ساخته میشوند، به احتمال زیاد هنوز یک راه پایداری، حساب آلوده یا مسیر نفوذ باز مانده است. در این شرایط پاک کردن دوباره همان فایل، راهحل اصلی نیست.
10. بکاپ را فقط وقتی برگردانید که از سالم بودن آن مطمئن هستید
بازگردانی بکاپ میتواند سریعترین روش بازیابی باشد، اما تنها زمانی که بکاپ واقعاً مربوط به قبل از نفوذ باشد. ممکن است سایت هفتهها قبل از اینکه شما متوجه شوید آلوده شده باشد؛ بنابراین «بکاپ مربوط به دیروز» الزاماً بکاپ سالم نیست.
قبل از بازگردانی:
- زمان تقریبی شروع نفوذ را مشخص کنید؛
- بکاپ را ترجیحاً در محیط آزمایشی بازگردانی کنید؛
- فایلها و کاربران را بررسی کنید؛
- آسیبپذیری یا مسیر ورود اولیه را ببندید؛
- سپس نسخه پاک را جایگزین سایت اصلی کنید.
اگر راه نفوذ از افزونه آسیبپذیر بوده و همان افزونه قدیمی را همراه بکاپ برگردانید، سایت میتواند دوباره هک شود.
خلاصه مراحل بازیابی سایت هکشده
اگر در میانه کار نمیدانید قدم بعدی چیست، جدول زیر ترتیب مناسب اقدامات را نشان میدهد. این ترتیب کمک میکند قبل از حذف شواهد یا بازگردانی عجولانه بکاپ، اول جلوی ادامه آسیب گرفته شود.
| مرحله | اقدام | هدف |
|---|---|---|
| 1 | ثبت وضعیت، تهیه نسخه از فایلها و دیتابیس و نگهداری لاگها | حفظ اطلاعات لازم برای بررسی و برگشت در صورت اشتباه |
| 2 | محدود کردن دسترسی عمومی در صورت خطر برای کاربران | جلوگیری از ادامه انتقال، فیشینگ یا انتشار بدافزار |
| 3 | بررسی لاگها و تماس با هاستینگ | پیدا کردن مسیر احتمالی ورود و دامنه نفوذ |
| 4 | تغییر رمزها، کلیدها و بستن نشستهای قدیمی | قطع دسترسی باقیمانده مهاجم |
| 5 | بررسی کاربران، فایلها، افزونهها، قالب و دیتابیس | حذف آلودگی و راههای پنهان بازگشت |
| 6 | بازیابی از منبع سالم یا بکاپ تأییدشده | بازگرداندن سایت بدون بازگرداندن آلودگی |
| 7 | بررسی سرچ کنسول، تست سایت و مانیتورینگ | اطمینان از بازگشت امن و شناسایی آلودگی دوباره |
11. بعد از پاکسازی، وضعیت سایت را در سرچ کنسول بررسی کنید
اگر گوگل سایت را آلوده یا هکشده تشخیص داده باشد، ممکن است در نتایج جستجو هشدار نمایش داده شود یا مرورگر قبل از باز شدن سایت صفحه هشدار نشان دهد. بعد از پاکسازی، وارد Google Search Console شوید و بخش Security Issues را بررسی کنید.
اگر مشکل امنیتی ثبت شده است، فقط زمانی درخواست بررسی مجدد بدهید که مطمئن شدهاید:
- همه نمونههای آلوده گزارششده پاک شدهاند؛
- مسیر ورود مهاجم بسته شده است؛
- صفحهها و فایلهای اسپم حذف شدهاند؛
- حسابها و دسترسیهای ناشناس حذف یا غیرفعال شدهاند؛
- سایت دوباره اسکن و تست شده است.
در متن درخواست بررسی، کوتاه و روشن توضیح دهید چه مشکلی وجود داشت و چه کاری برای رفع آن انجام دادید. درخواست بررسی قبل از پاکسازی کامل معمولاً فقط روند بازگشت سایت را طولانیتر میکند.
12. راه نفوذ را ببندید و سایت را بعد از بازیابی زیر نظر بگیرید
پاک شدن ظاهر سایت پایان کار نیست. اگر ندانید مهاجم از چه مسیری وارد شده، احتمال تکرار آلودگی بالا میماند. بعد از بازیابی این موارد را انجام دهید:
- هسته وردپرس، قالب و افزونهها را بروزرسانی کنید؛
- افزونه و قالب بدون استفاده را حذف کنید؛
- برای مدیران احراز هویت دومرحلهای فعال کنید؛
- رمزهای تکراری یا ضعیف را کنار بگذارید؛
- بکاپ منظم خارج از همان هاست داشته باشید و بازیابی آن را دورهای تست کنید؛
- تغییرات فایلها، ورود مدیران و هشدارهای سرچ کنسول را زیر نظر بگیرید؛
- نصبهای قدیمی وردپرس و پوشههای آزمایشی رهاشده را حذف کنید؛
- سطح دسترسی کاربران را بر اساس نیاز واقعی محدود کنید.
اگر میخواهید بعد از پاکسازی بدانید از چه مسیرهایی معمولاً به وردپرس نفوذ میشود و قبل از هک شدن چه کارهایی باید انجام دهید، مقاله هک سایت وردپرس چیست؟ انواع آن کدام است و چگونه رخ میدهد؟ را هم مطالعه کنید. در آن مطلب، راههای رایج نفوذ و اقداماتی که پیش از وقوع دوباره حمله باید جدی بگیرید توضیح داده شده است.
چطور مطمئن شویم سایت واقعاً پاک شده است؟
هیچ افزونه یا اسکنر واحدی نمیتواند با یک کلیک تضمین کند که سایت کاملاً سالم شده است. اطمینان زمانی بیشتر میشود که چند بررسی مختلف نتیجه یکسانی بدهند.
قبل از باز کردن کامل سایت برای کاربران، این موارد را کنترل کنید:
- راه نفوذ اولیه شناسایی و بسته شده باشد؛
- کاربر مدیر یا دسترسی ناشناس باقی نمانده باشد؛
- نشستها، رمزها و کلیدهای قدیمی باطل شده باشند؛
- هسته و افزونههای رسمی با نسخه سالم تطبیق داده شده باشند؛
- دیتابیس از نظر کد و محتوای ناشناس بررسی شده باشد؛
- فایلهای مخرب بعد از چند ساعت یا چند روز دوباره ایجاد نشوند؛
- اسکن امنیتی جدید مورد مشکوک مهمی نشان ندهد؛
- فرمها، ورود، خرید، ایمیل و سایر بخشهای مهم سایت سالم کار کنند؛
- لاگها بعد از بازیابی رفتار غیرعادی نشان ندهند.
اگر آلودگی چند بار برمیگردد، سایت داده حساس کاربران را نگهداری میکند، مهاجم به پنل هاست یا سرور دسترسی داشته یا نمیتوانید مسیر ورود را پیدا کنید، بهتر است پاکسازی را به متخصص امنیت بسپارید. در این وضعیت صرفاً نصب یک افزونه امنیتی کافی نیست.
اگر اطلاعات کاربران در معرض خطر بوده چه کنیم؟
اگر شواهد نشان میدهد مهاجم فقط فایل سایت را تغییر نداده و احتمال دسترسی به اطلاعات کاربران، سفارشها، ایمیلها یا حسابها وجود دارد، موضوع را جدیتر بررسی کنید.
بسته به نوع سایت ممکن است لازم باشد:
- رمز کاربران را بازنشانی کنید؛
- توکنها و کلیدهای دسترسی مرتبط را تعویض کنید؛
- تراکنشها و سفارشهای مشکوک را بررسی کنید؛
- به کاربران توضیح دهید چه اتفاقی افتاده و چه اقدامی باید انجام دهند؛
- الزامات قانونی یا قراردادی مربوط به گزارش رخداد را بررسی کنید.
در اطلاعرسانی از حدس و ادعای تأییدنشده خودداری کنید. فقط اطلاعاتی را اعلام کنید که بررسی شدهاند و اگر داده حساس درگیر است، هماهنگی با متخصص امنیت و مشاور حقوقی میتواند ضروری باشد.
اشتباهات رایج بعد از هک وردپرس
حذف فوری همه فایلهای مشکوک
اگر قبل از ثبت وضعیت و تهیه نسخه فعلی فایلها را حذف کنید، ممکن است سرنخ مهمی درباره مسیر ورود از بین برود. ابتدا شواهد لازم را نگه دارید و بعد پاکسازی را شروع کنید.
بازگردانی اولین بکاپ موجود
بکاپی که بعد از شروع نفوذ تهیه شده میتواند خودش آلوده باشد. زمان حادثه را تا حد ممکن مشخص کنید و نسخه پشتیبان را قبل از استفاده بررسی کنید.
فقط تغییر رمز وردپرس
مهاجم ممکن است نشست فعال، کاربر پنهان، رمز اپلیکیشن، کلید API یا دسترسی هاست داشته باشد. تغییر یک رمز بهتنهایی کافی نیست.
اعتماد کامل به یک افزونه امنیتی
اسکنرها ابزار مفیدی هستند، اما ممکن است همه تغییرات دیتابیس، فایل سفارشی یا راه پایداری مهاجم را تشخیص ندهند. نتیجه اسکن باید کنار بررسی کاربران، فایلها، لاگها و دیتابیس قرار گیرد.
باز کردن سریع سایت بدون پیدا کردن علت
اگر فقط صفحه آلوده را حذف کنید و سایت را دوباره در دسترس قرار دهید، مهاجم میتواند از همان راه قبلی برگردد. مهمترین سؤال بعد از پاکسازی این است: «چرا این اتفاق افتاد و چه چیزی تغییر کرد تا دوباره تکرار نشود؟»
جمعبندی
بعد از هک وردپرس، هدف فقط این نیست که صفحه خراب یا فایل آلوده را حذف کنیم. باید ابتدا جلوی ادامه آسیب را بگیریم، وضعیت فعلی و لاگها را حفظ کنیم، دسترسیهای مهاجم را ببندیم و سپس فایلها، افزونهها، قالب، کاربران و دیتابیس را از نظر تغییرات مشکوک بررسی کنیم.
بعد از پاکسازی نیز سایت باید با نسخههای سالم بازسازی شود، رمزها و کلیدها تغییر کنند، بکاپ قبل از بازیابی بررسی شود و سرچ کنسول و لاگهای سایت برای مدتی زیر نظر بمانند. اگر مسیر ورود پیدا نشود، حتی یک پاکسازی ظاهراً موفق هم تضمین نمیکند که سایت دوباره آلوده نشود.
ترتیب کار اهمیت زیادی دارد: ثبت و مهار حادثه، بررسی گستردگی، حذف عامل نفوذ، بازیابی امن و سپس پیشگیری از تکرار. این رویکرد معمولاً بسیار مطمئنتر از پاک کردن چند فایل مشکوک یا نصب سریع یک افزونه امنیتی است.
