سایت هک شد؟ اول این کارها را انجام دهید

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

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

مرحله اول: دسترسی مهاجم را قطع کنید، نه فایل‌ها را پاک

هدف این مرحله فقط یک چیز است: مهاجم دیگر نتواند وارد شود. هنوز هیچ فایلی را حذف نکنید.

اول از همه رمز عبور پنل مدیریت هاست و پنل دامنه را عوض کنید، از یک دستگاه دیگر، نه از همان سیستمی که ممکن است آلوده باشد. بعد کلیدهای SSH را بررسی کنید:

cat ~/.ssh/authorized_keys

هر کلیدی که نمی‌شناسید، حذفش کنید. اگر سرور شما پورت SSH را روی 22 گذاشته و احراز هویت با رمز فعال است، این احتمالاً همان دری بوده که مهاجم از آن وارد شده. راهنمای امنیت SSH؛ از تغییر پورت تا fail2ban و کلید عمومی دقیقاً همین سناریو را پوشش می‌دهد.

بعد نوبت به کاربران می‌رسد. در MySQL یا MariaDB:

SELECT user, host FROM mysql.user;
SELECT user, host, command, time, state FROM information_schema.processlist;

کاربری که نباید وجود داشته باشد، یا کاربری که از هاست اشتباهی وصل می‌شود، یعنی یک backdoor دیتابیس. رمز همه کاربران اپلیکیشن را عوض کنید و wp-config.php یا فایل تنظیمات مشابه را به‌روز کنید.

اگر سایت روی وردپرس است، کاربران ادمین را چک کنید. مهاجم معمولاً یک کاربر با نام بی‌معنی و نقش administrator می‌سازد:

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

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

مرحله دوم: شواهد را قبل از پاک‌سازی نگه دارید

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

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

tar czf /root/evidence-$(date +%F).tar.gz \
  /var/log/nginx /var/log/apache2 /var/log/auth.log \
  /var/www/html/wp-content/uploads 2>/dev/null

لاگ‌های وب سرور را نگاه کنید و دنبال الگوهای عجیب بگردید. یک درخواست POST به یک فایل PHP که نباید ورودی بگیرد، یا حجم غیرعادی ترافیک از یک IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

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

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

find /var/www/html -type f -newermt "2024-01-01" -printf "%T+ %p\n" | sort

در وردپرس، بررسی checksum هسته سریع‌ترین راه پیدا کردن فایل دست‌کاری‌شده است:

wp core verify-checksums
wp plugin verify-checksums --all

خروجی این دو دستور معمولاً فهرست کوتاهی از فایل‌ها می‌دهد. همان‌ها را جدا کنید و کنار بگذارید؛ بعداً برای تحلیل مفیدند.

اینجا اشتباه می‌کنند

اشتباه رایجی که بارها دیده‌ام: مدیر سایت بلافاصله فایل‌های آلوده را حذف می‌کند، سایت بالا می‌آید، همه خوشحال می‌شوند، و سه هفته بعد دقیقاً همان صفحه سیاه برمی‌گردد. چرا؟ چون مهاجم فقط یک فایل نگذاشته. یک cron job در /etc/cron.d/، یک تابع اضافه در functions.php قالب، یا یک ردیف در جدول wp_options باقی مانده که هر شب فایل آلوده را از نو می‌سازد. علامتش هم این است: فایل را حذف می‌کنید، چند ساعت بعد با همان محتوا و همان timestamp جدید برمی‌گردد. تا وقتی منبع بازتولید را پیدا نکنید، پاک کردن فایل بی‌فایده است.

مرحله سوم: پاک‌سازی از یک نقطه تمیز

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

1. هسته و همه افزونه‌ها و قالب‌ها را از منبع رسمی دوباره نصب کنید، نه از فایل‌های فعلی سرور.
2. هر فایل PHP با نام تصادفی در uploads یا cache را حذف کنید. هیچ فایل اجرایی نباید در پوشه آپلود باشد.
3. دیتابیس را برای رشته‌های مشکوک جست‌وجو کنید: eval(، base64_decode، <script src= با دامنه ناشناس.
4. کاربران ادمین را بازبینی کنید و رمز همه را عوض کنید.
5. کلیدهای API، توکن‌های پرداخت و رمزهای سرویس‌های بیرونی را باطل و از نو صادر کنید.

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

مرحله چهارم: بازگرداندن و بستن حفره ورود

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

• نسخه PHP، وردپرس، و همه افزونه‌ها را به آخرین نسخه پایدار برسانید. افزونه‌های رهاشده را حذف کنید، نه غیرفعال.
• احراز هویت دو مرحله‌ای را برای همه حساب‌های مدیریتی فعال کنید.
• دسترسی به پنل مدیریت را محدود کنید، یا با IP یا با یک لایه احراز هویت اضافه.

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

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

چه زمانی باید کمک بیرونی بگیرید

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

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

پرسش‌های پرتکرار

اولین کاری که بعد از هک شدن سایت باید بکنم چیست؟

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

آیا باید سایت را فوراً از دسترس خارج کنم؟

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

چطور بفهمم مهاجم از کدام نقطه وارد شده؟

لاگ وب سرور، لاگ احراز هویت و فهرست فایل‌های تغییر یافته را با هم مقایسه کنید. در وردپرس، دستور wp core verify-checksums سریع‌ترین راه پیدا کردن فایل‌های دست‌کاری‌شده است. اگر لاگ ممیزی از قبل فعال نبوده، بازسازی مسیر ورود سخت‌تر اما غیرممکن نیست.

بعد از پاک‌سازی، چطور مطمئن شوم دوباره هک نمی‌شود؟

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