سایتم هک شده، چه کنم؟ راهنمای قدم‌به‌قدم بازیابی سایت و بستن راه نفوذ

صفحه‌ی اول سایت با یک پیام عجیب عوض شده، گوگل کنار نتایج شما هشدار «This site may be hacked» نشان می‌دهد، کاربران به سایت‌های قمار ریدایرکت می‌شوند یا هاستینگ اطلاع داده که از سرور شما اسپم ارسال می‌شود. اولین واکنش طبیعی این است که هر چه زودتر فایل‌های مشکوک را پاک کنید و سایت را برگردانید. اما اگر راه نفوذ پیدا و بسته نشود، مهاجم معمولاً چند روز بعد برمی‌گردد.

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

قدم ۱: آرامش؛ و چیزی را پاک نکنید

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

قدم ۲: ایزوله کردن

هدف این است که آسیب به کاربران و دیگر سایت‌ها ادامه پیدا نکند:

سایت را در حالت تعمیر (Maintenance Mode) قرار دهید؛ بهتر است در سطح وب‌سرور یا کنترل‌پنل، نه از طریق خود CMS که ممکن است دستکاری شده باشد.
اگر چند سایت روی یک سرور هستند، بقیه را هم بررسی کنید؛ آلودگی معمولاً بین سایت‌های یک کاربر پخش می‌شود.
اگر سرور اسپم می‌فرستد یا به جاهای دیگر حمله می‌کند، ترافیک خروجی را محدود کنید.

قدم ۳: حفظ شواهد

قبل از هر تغییری، از وضعیت فعلی کپی بگیرید:

# اگر سرور مجازی است: از پنل یک Snapshot بگیرید
# کپی کامل فایل‌ها و دیتابیس آلوده (جدا از بکاپ‌های سالم)
sudo tar czf /root/evidence-files-$(date +%F).tar.gz /var/www/example.com
mysqldump -u root -p example_db > /root/evidence-db-$(date +%F).sql
# کپی لاگ‌ها
sudo tar czf /root/evidence-logs-$(date +%F).tar.gz /var/log/nginx /var/log/apache2 /var/log/auth.log* 2>/dev/null

در Plesk یا cPanel، لاگ‌های دسترسی هر سایت معمولاً در پوشه‌ی logs همان سایت است. این کپی‌ها را از دسترس وب خارج و روی سیستمی دیگر نگه دارید.

قدم ۴: تغییر همه‌ی رمزها و کلیدها

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

رمز کنترل‌پنل هاست و حساب ارائه‌دهنده‌ی سرور
رمز SSH و FTP/SFTP؛ و فهرست authorized_keys را برای کلیدهای ناشناس بررسی کنید
رمز کاربر دیتابیس (و به‌روزرسانی آن در فایل تنظیمات سایت)
رمز همه‌ی مدیران CMS
کلیدهای API: درگاه پرداخت، سرویس پیامک، ایمیل، ذخیره‌سازی و هر چیزی که در فایل تنظیمات یا .env بوده
در وردپرس، کلیدهای Salt را عوض کنید تا همه‌ی نشست‌های فعال، از جمله نشست مهاجم، باطل شوند: wp config shuffle-salts

قدم ۵: پیدا کردن راه نفوذ

این مهم‌ترین و سخت‌ترین قدم است. چند مسیر بررسی:

فایل‌های اخیراً تغییرکرده

# فایل‌های PHP تغییرکرده در ۱۴ روز اخیر
find /var/www/example.com -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort
# فایل PHP در پوشه‌ی آپلود (در وردپرس نباید وجود داشته باشد)
find /var/www/example.com/wp-content/uploads -type f -name "*.php"
# الگوهای رایج در کد مخرب
grep -rlE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(" /var/www/example.com --include=*.php

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

لاگ‌های دسترسی

زمان تغییر اولین فایل مشکوک را پیدا کنید و لاگ دسترسی همان حوالی را بخوانید:

# درخواست‌های POST به فایل مشکوک
grep "POST /wp-content/uploads/" /var/log/nginx/access.log*
grep "suspicious-file.php" /var/log/nginx/access.log*
# درخواست‌های POST در یک بازه‌ی زمانی مشخص
grep "12/Oct/2026:0[3-5]" /var/log/nginx/access.log | grep POST

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

کاربران مدیر ناشناس

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

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

افزونه‌ها و قالب‌های قدیمی یا نال‌شده

wp plugin list --update=available
wp theme list
wp core verify-checksums
wp plugin verify-checksums --all

شایع‌ترین راه نفوذ در سایت‌های وردپرسی ایران، افزونه‌ها یا قالب‌های قدیمی و نسخه‌های نال‌شده است. نسخه‌ی نال‌شده‌ی یک قالب یا افزونه‌ی تجاری اغلب از ابتدا Backdoor دارد. دستور verify-checksums فایل‌های هسته و افزونه‌های مخزن رسمی را با نسخه‌ی اصلی مقایسه می‌کند. راه‌های نفوذ دیگر: رمز ضعیف یا تکراری، PHP و نرم‌افزار سرور قدیمی (ببینید: به‌روزرسانی امنیتی PHP)، و کامپیوتر آلوده‌ی یکی از مدیران که رمز FTP را لو داده است.

قدم ۶: پاک‌سازی یا بازیابی از بکاپ سالم

دو راه دارید:

بازیابی از بکاپ سالم (ترجیحی): بکاپی را انتخاب کنید که قبل از اولین نشانه‌ی نفوذ گرفته شده؛ تاریخ را از تحلیل قدم ۵ دارید. اگر فقط بکاپ دیروز را برگردانید، احتمالاً Backdoor را هم برگردانده‌اید.
پاک‌سازی دستی: اگر بکاپ سالم ندارید. در وردپرس، هسته را از نسخه‌ی رسمی دوباره نصب کنید (wp core download --force --skip-content)، افزونه‌ها و قالب را حذف و از منبع رسمی دوباره نصب کنید، و فقط محتوای wp-content/uploads و دیتابیس را نگه دارید و آن‌ها را هم با دقت برای فایل‌های PHP و کد تزریق‌شده (مثلاً تگ‌های <script> ناشناس در جدول wp_posts و wp_options) بررسی کنید.

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

قدم ۷: به‌روزرسانی همه‌چیز

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

قدم ۸: امن‌سازی

دسترسی فایل‌ها: پوشه‌ها 755، فایل‌ها 644 و فایل تنظیمات محدودتر؛ و مالک فایل‌ها نباید کاربری باشد که بی‌دلیل بتواند همه‌چیز را بازنویسی کند.

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
chmod 640 /var/www/example.com/wp-config.php

جلوگیری از اجرای PHP در پوشه‌ی آپلود در تنظیمات وب‌سرور. نمونه برای Nginx:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

غیرفعال کردن ویرایشگر فایل در پیشخوان وردپرس در wp-config.php:

define('DISALLOW_FILE_EDIT', true);

ورود دومرحله‌ای برای همه‌ی مدیران و محدود کردن تلاش‌های ورود.
WAF: یک فایروال برنامه‌ی وب (در سطح سرور مثل ModSecurity، یا سرویس CDN با WAF) بسیاری از حملات خودکار به افزونه‌های آسیب‌پذیر را قبل از رسیدن به سایت متوقف می‌کند.
بکاپ خودکار خارج از سرور با نگه‌داری چند نسخه‌ی قدیمی، تا دفعه‌ی بعد بکاپ سالم داشته باشید.
امن‌سازی دسترسی سرور: امن‌سازی SSH و حذف FTP بدون رمزنگاری.

قدم ۹: گوگل و Search Console

اگر گوگل سایت را علامت‌گذاری کرده، در Google Search Console به گزارش Security Issues بروید. مشکلات اعلام‌شده را ببینید، بعد از رفع کامل گزینه‌ی Request Review را بزنید و در توضیحات بنویسید چه کاری انجام داده‌اید. اگر صفحات اسپم ساخته شده بودند، مطمئن شوید آن آدرس‌ها اکنون خطای 404 یا 410 برمی‌گردانند و نقشه‌ی سایت فقط صفحات واقعی را دارد. همچنین فهرست کاربران Search Console را بررسی کنید؛ مهاجمان گاهی خودشان را به‌عنوان مالک اضافه می‌کنند.

قدم ۱۰: بررسی پس از حادثه (Post-mortem)

بعد از برگشتن سایت، یک گزارش کوتاه بنویسید، بدون دنبال مقصر گشتن:

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

جمع‌بندی

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

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