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

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

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

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

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

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

استفاده از ابزارهای امنیتی

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

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

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

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

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

خوشبختانه، غیرفعال کردن این گزینه خیلی راحته. کافیه یک خط کد رو به فایل wp-config.php اضافه کنید.

همچنین افزونه‌های امنیتی مثل افزونه SUCURI  و iTheme Security این اماکن رو به شما می‌دن که ادیتور رو غیرفعال کنید.

بررسی تاثیرات نفوذ

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

سوال بعدی اینه که “دیگه چی تغییر کرده؟”. ما از ابزارهای بازبینی استفاده می‌کنیم تا بفهمیم آیا فایلی تغییر کرده است یا خیر.

با بررسی لاگ تغییرات، متوجه می‌شیم که هکر دو فایل رو دستکاری کرده.

twentythirteen/page.php

twentythirteen/index.php

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

با استفاده از filezilla و پروتوکول SFTP به سرورمتصل می‌شیم و می‌بینیم که واقعا این فایل‌ها امروز تغییر کرده‌اند.

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

البته می‌تونیم به شیوه خود هکرها با رفتن به محیط مدیریت سایت و با استفاده از theme Editor، این فایل‌ها رو باز کنیم.

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

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

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

ما همچنین می دونیم که در این دوبار، نفوذ کننده‌ها از IP های روسیه و ترکیه وارد سایت شده اند. البته اونها می‌تونن هرجایی از دنیا باشند.

هرچند این اطلاعات کمک چندانی نمی‌کنن اما گروه هکر رو می‌شناسیم:

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

بهبود وضعیت امنیت سایت

این مساله طولانی‌تر از اونیه که با یه پست وبلاگ بتونیم بگیمش. بسیاری از این حمله‌ها اتوماتیک انجام می‌شه اما این حمله خاص، دستی بوده. هرچند که نفوذ به مکانیزم کنترل (مثلا لاگین به wp-admin)، دسترسی بوده اما احتمال داره که فاز اول حمله به صورت اتوماتیک انجام شده باشه. به این شکل که یک اسکریپت احتمالا اطلاعات کاربری ضعیف رو پیدا کرده و جایی ثبت می‌کنه و هکرها بعدا و سرفرصت در فاز دوم حمله، سایت رو هک می‌کنن.

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

برای جلوگیری از هک چکار می‌تونستیم بکنیم؟

پیشنهادهای ما برای این مورد خاص اینهاست:

مفیدترین گزینه: محدودیت دسترسی

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

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

جایگزین ۱: محدودیت تلاش برای ورود

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

جایگزین ۲: استفاده از پسورد پیچیده، طولانی و یکتا

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

جایگزین ۳: استفاده از ورود دو مرحله‌ای

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

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

در پایان وقتی که همه کارهای لازم برای پاک سازی سرور رو انجام دادید، باید برخی کارهای دیگه هم بکنید. برای مثال همه کاربرها رو مجبور کنید که پسوردشون رو تغییر بدن. کلیدها و salt های مندرج در wp-config.php رو تغییر بدید. اگر نمی دونید اینها چیه، می تونید از افزونه رایگان Sucuri استفاده بکنید.

پیشنهادهای تکمیلی

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

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

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

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

در پایان هم پیشنهاد می‌کنم در صورت هک شدن، حتما از یک متخصص برای پاک‌سازی سایت و سرور کمک بگیرید.

منبع:

http://blog.sucuri.net/2014/08/my-wordpress-website-was-hacked.html