روش مقابله با Gumblar Attack
گامبلار (Gumblar) نام یک کارزار آلودگی انبوه در سال ۲۰۰۹ بود که رمزهای FTP را از کامپیوتر مدیران سایت میدزدید و با همان رمزها کدهای مخرب را به صفحات وب تزریق میکرد. آن کارزار سالهاست تمام شده، اما الگویش زنده است: هنوز رایجترین راه هک شدن یک سایت، لو رفتن یا ضعیف بودن اعتبارنامهها و بهروز نبودن نرمافزار سایت است. بنابراین به جای دنبال کردن یک بدافزار قدیمی، این مطلب را به شکل یک راهنمای امروزی نوشتهایم: چطور بفهمید سایتتان آلوده شده، چطور تمیزش کنید، چطور راه ورود را ببندید و چرا باید FTP ساده را کنار بگذارید.
نشانههای هک شدن سایت
آلودگی امروزی معمولا خودش را به شما نشان نمیدهد؛ مهاجم میخواهد تا حد ممکن دیده نشود. به این نشانهها حساس باشید:
- در نتایج گوگل، عنوان یا توضیحات صفحات شما به زبان دیگری یا با موضوعی نامربوط (دارو، شرطبندی، کفش تقلبی) نمایش داده میشود.
- سایت برای شما درست باز میشود اما بازدیدکنندهای که از گوگل یا از موبایل میآید به سایت دیگری هدایت میشود. تغییر مسیر شرطی، رایجترین رفتار بدافزارهای امروزی است.
- مرورگر یا آنتیویروس هنگام باز کردن سایت هشدار میدهد.
- فایلهای PHP با نامهای عجیب در پوشههای آپلود ظاهر شدهاند، یا تاریخ تغییر فایلهای اصلی بدون دلیل جابهجا شده است.
- مصرف CPU یا ترافیک خروجی هاست بدون رشد بازدید بالا رفته، یا ایمیلهای خروجی سرور به صورت اسپم علامت میخورند.
- کاربر مدیری در پنل سایت هست که شما نساختهاید.
گام اول: آلودگی را از بیرون تایید کنید
پیش از دست زدن به فایلها، تصویری بیرونی از وضعیت بگیرید. در سرچ کنسول گوگل بخش Security Issues (مسائل امنیتی) دقیقا میگوید گوگل چه چیزی روی سایت شما دیده و نمونه آدرسهای آلوده را فهرست میکند. اگر هنوز سایت را در سرچ کنسول ثبت نکردهاید، همین حالا ثبت کنید؛ سرویس قدیمی Webmaster Tools سالهاست با همین نام جایگزین شده است.
در کنار آن، سایت را با یک User-Agent موبایل و با ارجاع از گوگل هم باز کنید تا تغییر مسیرهای شرطی را ببینید. با curl میتوانید همین کار را از خط فرمان انجام دهید و بدون اجرای جاوااسکریپت، پاسخ خام سرور را ببینید. این کار جلوی خطای رایج «سایت که برای من سالم است» را میگیرد.
گام دوم: فایلهای دستکاریشده را پیدا کنید
اگر به SSH دسترسی دارید، سریعترین راه، مرتب کردن فایلها بر اساس زمان تغییر است. فایلهای PHP که در چند روز اخیر عوض شدهاند را با این دستور ببینید:
find /home/user/public_html -type f -name "*.php" -mtime -7
سپس دنبال الگوهای رایج در کدهای مخفیشده بگردید. توابع زیر به تنهایی مجرمانه نیستند، اما تجمعشان در یک فایل تازهساخته تقریبا همیشه معنادار است:
grep -RIl --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" /home/user/public_html
برای وردپرس یک راه دقیقتر هم وجود دارد: مقایسه فایلها با نسخه رسمی. با wp core verify-checksums هسته و با wp plugin verify-checksums --all افزونههای مخزن رسمی بررسی میشوند و هر فایل تغییریافته یا اضافه گزارش میشود. پوشههای wp-content/uploads، wp-includes و ریشه سایت را جداگانه نگاه کنید؛ فایل PHP در پوشه آپلود تقریبا هیچوقت مشروع نیست. فایلهای .htaccess را هم فراموش نکنید، چون تغییر مسیرهای مخرب اغلب آنجا کاشته میشوند.
گام سوم: پاکسازی
پیش از هر تغییری، از وضعیت فعلی (فایلها و دیتابیس) یک نسخه بگیرید و آن را جدا نگه دارید. این نسخه برای بازگردانی نیست، برای بررسی بعدی است.
مطمئنترین روش پاکسازی، جایگزینی است نه ویرایش. هسته سیستم مدیریت محتوا و همه افزونهها و قالبها را با نسخه سالم و بهروز از منبع رسمی بازنویسی کنید و فقط پوشه محتوای کاربر (آپلودها) و فایل پیکربندی را نگه دارید؛ آن دو را هم دستی بازرسی کنید. تکتک پاک کردن خطوط مخرب وسوسهانگیز است ولی معمولا شکست میخورد، چون بدافزارهای امروزی چند در پشتی در جاهای مختلف میکارند و کافی است یکی از قلم بیفتد تا چند روز بعد همه چیز برگردد.
دیتابیس را هم نگاه کنید. در وردپرس جدول کاربران را برای اکانت مدیر ناشناس، جدول تنظیمات را برای مقادیر مشکوک، و محتوای نوشتهها را برای <script> و آیفریم تزریقشده بررسی کنید. اگر قالب یا افزونه نالشده (کرکشده) نصب کردهاید، آن را حذف کنید؛ این یکی از پرتکرارترین راههای ورود است.
گام چهارم: راه ورود را ببندید
سایت تمیزشدهای که راه ورودش باز مانده، ظرف چند روز دوباره آلوده میشود. علت اولیه را پیدا کنید و ببندید:
- نرمافزار قدیمی: هسته، افزونهها و قالبها را بهروز کنید و افزونههای بیاستفاده را حذف کنید، نه صرفا غیرفعال.
- نسخه PHP: اگر روی نسخهای هستید که دیگر بهروزرسانی امنیتی نمیگیرد، از پنل هاست به نسخه پشتیبانیشده منتقل شوید.
- دسترسی فایلها: پوشهها ۷۵۵ و فایلها ۶۴۴ باشند. هیچ فایل یا پوشهای نباید ۷۷۷ باشد.
- اجرای PHP در پوشه آپلود: اجرای اسکریپت در مسیر آپلود را غیرفعال کنید تا فایل آپلودشده قابل اجرا نباشد.
- ورود مدیر: رمز قوی بگذارید، ورود دومرحلهای را فعال کنید و تلاشهای ناموفق ورود را محدود کنید.
- لاگها: لاگ دسترسی وبسرور را حوالی تاریخ تغییر فایلهای مخرب بخوانید؛ معمولا همانجا معلوم میشود مهاجم از کدام آدرس و با چه درخواستی وارد شده است.
گام پنجم: همه اعتبارنامهها را عوض کنید
فرض را بر این بگذارید که هر رمزی که در دوره آلودگی روی این سایت استفاده شده، لو رفته است. رمز پنل هاست، همه اکانتهای FTP و SFTP، کاربر و رمز دیتابیس (و بهروزرسانی همزمان فایل پیکربندی)، همه کاربران مدیر سایت، اکانتهای ایمیل مرتبط و هر کلید API که در فایلهای سایت ذخیره شده بوده را تغییر دهید. اکانتهای FTP قدیمی و بیاستفاده را به جای تغییر رمز، حذف کنید. اگر رمزها را روی کامپیوتر شخصی در نرمافزار FTP ذخیره کردهاید، سیستم خودتان را هم اسکن کنید و رمزها را از حالت ذخیرهشده خارج کنید و در یک مدیر رمز معتبر نگه دارید.
چرا FTP ساده باید کنار برود
پروتکل FTP نام کاربری و رمز و کل محتوای فایلها را بدون رمزنگاری روی شبکه میفرستد. هر کسی در مسیر — از یک وایفای عمومی گرفته تا یک تجهیز میانی — میتواند آنها را بخواند. راهحل، استفاده از SFTP (انتقال فایل روی بستر SSH) یا FTPS است. اتصال SFTP به همین سادگی است:
sftp user@example.com
یک قدم جلوتر، به جای رمز از کلید SSH استفاده کنید. کلید را با ssh-keygen -t ed25519 بسازید و کلید عمومی را روی سرور بگذارید؛ از آن پس رمزی وجود ندارد که سرقت شود.
و یک توصیه صریح: هرگز نام کاربری و رمز FTP خود را در سرویسهای وببیس شخص ثالث که در مرورگر اجرا میشوند وارد نکنید. در این مدل، اعتبارنامه شما به سرور یک شرکت ناشناس میرود و از آنجا به هاست شما وصل میشود؛ یعنی دقیقا همان چیزی که میخواستید محافظت کنید را داوطلبانه به یک واسطه میسپارید. توصیه قدیمی این صفحه در این مورد اشتباه بود و آن را اصلاح کردهایم. از یک کلاینت رومیزی معتبر روی سیستم خودتان استفاده کنید. اگر روی هاست اشتراکی هستید، فایل منیجر داخل پنل هاست هم گزینه امنتری از سرویسهای واسط بیرونی است، چون اعتبارنامه از هاست شما بیرون نمیرود.
گام آخر: درخواست بازبینی از گوگل
وقتی مطمئن شدید سایت تمیز است و راه ورود بسته شده، در سرچ کنسول از بخش Security Issues درخواست بازبینی (Request Review) ثبت کنید و توضیح دهید چه چیزی را پیدا و چطور برطرف کردید. اگر درخواست را پیش از پاکسازی کامل بفرستید و رد شود، نوبت بعدی دیرتر بررسی میشود؛ پس عجله نکنید. پس از تایید، هشدار مرورگرها و برچسب سایت در نتایج جستجو برداشته میشود.
پیشگیری برای دفعه بعد
پشتیبانگیری منظم و خودکار بگیرید و مهمتر از آن، هر چند وقت یک بار بازیابی را واقعا آزمایش کنید؛ پشتیبانی که تست نشده باشد فقط یک فرض است. نسخههای پشتیبان را بیرون از خودِ سرور نگه دارید تا در حادثهای که کل سرور را درگیر میکند از دست نروند. اگر مدیریت سرور مجازی یا اختصاصی را خودتان بر عهده دارید، بهروزرسانی سیستمعامل، فایروال و محدود کردن دسترسی SSH را هم به همین چرخه اضافه کنید. اگر ترجیح میدهید این کارها را به کسی بسپارید، سرویس پشتیبانی و مدیریت سرور پاکسازی، سختسازی امنیتی، مانیتورینگ و آزمایش بازیابی پشتیبان را پوشش میدهد.
جمعبندی
گامبلار دیگر تهدید امروز نیست، اما درسش هست: هک شدن سایت معمولا از یک اعتبارنامه لو رفته یا یک نرمافزار وصلهنشده شروع میشود، نه از یک حمله پیچیده. مسیر درست همیشه یکی است — تایید آلودگی از سرچ کنسول، پیدا کردن فایلهای تغییریافته، جایگزینی به جای وصله کردن، بستن راه ورود، تعویض کامل رمزها و در نهایت درخواست بازبینی. و اگر هنوز با FTP ساده کار میکنید، همین امروز به SFTP یا کلید SSH مهاجرت کنید.