چرا Metasploit Framework؟
Metasploit Framework برای اعتبارسنجی کنترل‌های امنیتی و آسیب‌پذیری‌ها در محیط‌های تست و ارزیابی مجاز به کار می‌رود. Rapid7 installer و مستندات رسمی را برای سیستم‌عامل‌های مختلف ارائه می‌کند. اجرای moduleهای exploitation فقط باید روی سامانه‌ای باشد که مالک آن هستید یا مجوز کتبی دارید.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
Framework را از محصول تجاری جدا بشناسید
Metasploit Framework یک چارچوب ماژولار برای کارهای ارزیابی امنیت است. مستندات و صفحه‌های Rapid7 ممکن است هم قابلیت‌های Framework و هم امکانات محصول تجاری Pro را توضیح دهند. پیش از دنبال کردن یک راهنما، عنوان بخش و نوع محصول را بررسی کنید تا انتظار رابط یا گزارشی را نداشته باشید که در نصب شما وجود ندارد. برای کار فنی، نسخه نصب‌شده و منبع دریافت آن باید مشخص باشند. این ثبت کمک می‌کند نتیجه یک آزمایش بعداً با همان مجموعه ماژول‌ها قابل بازبینی باشد.
چارچوب، جای فرایند ارزیابی را نمی‌گیرد. داشتن یک ماژول مرتبط با نام سرویس به معنی مناسب بودن آن برای هدف شما نیست. نسخه دقیق، تنظیمات، معماری و شرایط لازم ماژول باید با محیط تطبیق داده شوند. نتیجه اسکن اولیه تنها یک فرضیه می‌سازد. پیش از هر آزمون اثرگذار، این فرضیه را با شواهد کم‌خطرتر مانند اطلاعات بسته، پیکربندی مجاز و بررسی مالک سامانه تقویت کنید. این کار تعداد آزمایش‌های غیرضروری و احتمال اختلال را کم می‌کند.
آزمایشگاه بازتولیدپذیر بسازید
برای یادگیری، یک شبکه مجازی جدا با ماشین ارزیاب و هدف آموزشی تحت مالکیت خودتان بسازید. هدف آسیب‌پذیر نباید به شبکه عمومی یا داده واقعی سازمان متصل باشد. نشانی‌ها، نسخه‌ها و مسیر ارتباط را ثبت کنید و از وضعیت پایه snapshot بگیرید. snapshot کمک می‌کند اثر آزمایش از آزمایش بعدی جدا شود، اما جای نسخه پشتیبان داده مهم نیست. در آزمایشگاه آموزشی بهتر است اصلاً داده واقعی وجود نداشته باشد.
پیش از اجرای ماژول، یک آزمون ساده دسترسی انجام دهید تا معلوم شود هدف روشن است و سرویس مورد نظر در همان شبکه پاسخ می‌دهد. اگر ارتباط پایه خراب باشد، نتیجه منفی ماژول درباره آسیب‌پذیری معنای روشنی ندارد. ساعت ماشین‌ها را نیز هماهنگ کنید تا logها قابل تطبیق باشند. یک برگه آزمایش شامل هدف، فرضیه، عمل مجاز و شاهد مورد انتظار بسازید؛ این ساختار از اجرای تصادفی مجموعه‌ای از ماژول‌ها جلوگیری می‌کند.
گروه‌های ماژول چه تفاوتی دارند؟
ماژول‌های auxiliary کارهای گوناگونی مانند بررسی و جمع‌آوری اطلاعات انجام می‌دهند، اما نام auxiliary تضمین بی‌اثر بودن نیست. هر ماژول رفتار و گزینه‌های خود را دارد. ماژول exploit برای بهره‌گیری از یک ضعف طراحی شده و payload به رفتاری مربوط می‌شود که در ادامه اجرا می‌شود. ماژول‌های post نیز در زمینه دسترسی موجود کاربرد دارند. این دسته‌ها را از نظر پیش‌نیاز، اثر و داده تولیدشده جدا بررسی کنید.
برای شروع، صفحه اطلاعات ماژول و توضیح گزینه‌ها را بخوانید. مقصد، پورت، مسیر سرویس و تنظیمات اختیاری باید با دامنه آزمایش تطبیق داده شوند. مقدار باقی‌مانده از آزمایش قبلی می‌تواند هدف اشتباه بسازد. پیش از اجرا، تنظیمات مؤثر را دوباره مرور کنید و آن را در پرونده آزمایش ثبت کنید، بدون ذخیره مقدار secret. این بازبینی کوتاه به‌ویژه هنگام جابه‌جایی میان چند آزمایشگاه یا پروژه اهمیت دارد.
Workspace و جداسازی داده‌ها
داده یک ارزیابی می‌تواند شامل میزبان‌ها، سرویس‌ها، یادداشت‌ها و شواهد حساس باشد. جداسازی workspace کمک می‌کند نتایج پروژه‌ها مخلوط نشوند، اما خود آن جای کنترل دسترسی سیستم و حفاظت از پایگاه داده را نمی‌گیرد. نام‌گذاری روشن و دامنه مشخص برای هر workspace انتخاب کنید. پیش از واردکردن داده اسکن، مطمئن شوید فایل به همان پروژه و همان بازه زمانی تعلق دارد. اطلاعات قدیمی ممکن است سرویس حذف‌شده را هنوز فعال نشان دهد.
برای گزارش، میان داده مشاهده‌شده مستقیم و داده واردشده از منبع دیگر تفاوت بگذارید. زمان و منبع هر مشاهده اهمیت دارد. اگر یک سرویس در inventory هست اما هنگام ارزیابی پاسخ نمی‌دهد، آن را به عنوان نتیجه قطعی آزمون مثبت گزارش نکنید. همین‌طور نبود پاسخ از شبکه ارزیاب ممکن است نتیجه فایروال باشد، نه نبود سرویس. ثبت محدودیت دید باعث می‌شود مخاطب گزارش بداند چه چیزی واقعاً بررسی شده است.
قابلیت check و معنای نتیجه منفی
بعضی ماژول‌ها روش بررسی اولیه دارند، اما همه آن‌ها چنین قابلیتی ندارند و دقت بررسی نیز یکسان نیست. نتیجه check را مطابق توضیح همان ماژول تفسیر کنید. تشخیص نسخه یا پاسخ خاص می‌تواند نشانه باشد، ولی لزوماً همه شرایط بهره‌برداری را ثابت نمی‌کند. نتیجه نامشخص باید نامشخص باقی بماند. تبدیل هر پاسخ غیرمثبت به عبارت «ایمن است» از نظر فنی نادرست است.
برای کاهش ابهام، شواهد مستقل جمع کنید. نسخه بسته از مدیریت پیکربندی، وضعیت وصله و تنظیم سرویس می‌توانند نتیجه ابزار را تکمیل کنند. اگر نسخه ظاهری تغییر نکرده ولی وصله توزیع backport شده است، تشخیص بر اساس banner ممکن است گمراه شود. برعکس پنهان بودن نسخه ضعف را برطرف نمی‌کند. هدف ارزیابی رسیدن به نتیجه مستند است، نه گرفتن یک عبارت سبز از یک فرمان خاص.
انتخاب شاهد با کمترین اثر
در آزمایش مجاز، لازم نیست برای اثبات هر یافته بیشترین سطح دسترسی یا بیشترین داده ممکن را جمع کنید. شاهد باید برای توضیح اثر کافی و با دامنه توافق‌شده سازگار باشد. یک نشانه بی‌خطر و مشخص در هدف آموزشی می‌تواند مسیر اجرا را ثابت کند. در محیط واقعی، نوع شاهد و توقف آزمون باید پیشاپیش با مالک هماهنگ باشد. کاهش اثر، کیفیت نتیجه را کم نمی‌کند؛ آن را قابل دفاع‌تر می‌کند.
از داده ساختگی برای آزمون دسترسی استفاده کنید تا اطلاعات واقعی افراد یا سازمان بی‌دلیل وارد پرونده نشود. اگر ابزار خروجی حساس تولید کرد، دسترسی و مدت نگه‌داری آن را محدود کنید. گزارش عمومی نباید secret، token یا محتوای محرمانه را بازنشر کند. شواهد فنی می‌توانند با حذف مقدار حساس و حفظ ساختار و زمان همچنان قابل بررسی باشند. نسخه کامل فقط در مسیر کنترل‌شده و در صورت نیاز نگه‌داری شود.
نرخ اجرا و سامانه‌های شکننده
افزایش هم‌زمانی یا اجرای گروهی ماژول‌ها ممکن است سرویس ضعیف یا قدیمی را تحت فشار بگذارد. برای هر دسته هدف، ظرفیت و حساسیت را بشناسید و از نرخ محدود آغاز کنید. دستگاه شبکه، سامانه صنعتی یا برنامه قدیمی ممکن است رفتار متفاوتی از سرور آزمایشگاهی داشته باشد. حتی بررسی بدون بهره‌برداری هم می‌تواند بار یا log زیادی بسازد. برنامه ارزیابی باید نشانه توقف و راه تماس عملیاتی داشته باشد.
وقتی خطا یا افت پاسخ مشاهده شد، ادامه خودکار آزمون‌ها نتیجه را مبهم می‌کند. ابتدا سلامت هدف را بررسی کنید و علت را از اثر ابزار جدا سازید. زمان دقیق شروع و پایان هر آزمون برای این تحلیل مهم است. اگر چند ابزار هم‌زمان روی یک هدف کار کنند، نسبت دادن اختلال دشوار می‌شود. در آزمایش نخست، تغییرها را محدود و قابل ردیابی نگه دارید تا اثر هر اقدام روشن بماند.
همکاری با تیم دفاعی
یک ارزیابی می‌تواند علاوه بر بررسی ضعف، کیفیت تشخیص را هم بسنجد. برای این هدف، زمان و رفتار آزمایشی را با تیم دفاعی طبق برنامه توافق‌شده هماهنگ کنید. سپس بررسی کنید کدام log و هشدار تولید شده و چه اطلاعاتی برای رسیدگی کافی بوده است. نبود هشدار الزاماً به معنی نبود هیچ داده‌ای نیست؛ ممکن است داده ثبت شده ولی قاعده یا مسیر اعلان کامل نباشد. این لایه‌ها را جدا گزارش کنید.
پس از آزمایش، یک خط زمانی مشترک بسازید: اقدام ارزیاب، رخداد هدف، ثبت حسگر و رسیدگی انسان. فاصله میان این مراحل نقاط قابل بهبود را نشان می‌دهد. هدف نباید صرفاً غافلگیر کردن تیم باشد؛ نتیجه باید به اصلاح کنترل یا دستورالعمل برسد. اگر هشدار درست بوده ولی صاحب رسیدگی مشخص نبوده است، مشکل فرایند با نصب ابزار تازه حل نمی‌شود. گزارش فنی خوب این تفاوت را روشن می‌کند.
پاک‌سازی و تأیید اصلاح
هر نشست، فایل آزمایشی یا تغییر مجاز ایجادشده باید در پایان تعیین تکلیف شود. فهرست تغییرات را در طول کار نگه دارید تا پاک‌سازی بر حافظه افراد متکی نباشد. بازگشت snapshot در آزمایشگاه مفید است، ولی در محیط عملیاتی باید وضعیت سرویس و داده با مالک تأیید شود. بسته شدن رابط ابزار به معنی پایان همه فرایندهای ایجادشده نیست. شاهد سلامت پس از آزمون بخشی از تحویل کار است.
برای یافته معتبر، راهکار اصلاح باید به علت ریشه‌ای وصل باشد: وصله، تغییر تنظیم، کاهش دسترسی یا جداسازی مسیر. پس از اصلاح، همان پیش‌شرط‌ها و آزمون شاهد را دوباره بررسی کنید. نتیجه منفی جدید فقط وقتی معنادار است که هدف و مسیر آزمایش واقعاً همان باشند. گزارش نهایی باید وضعیت پیش و پس، محدودیت آزمون و ریسک باقی‌مانده را توضیح دهد. مستند ماژول‌های Framework مرجع تکمیلی برای شناخت نوع و گزینه‌های ماژول‌هاست.
تفسیر شکست ارتباط پس از آزمون
اگر یک ماژول انتظار ارتباط برگشتی دارد، شکست آن ارتباط لزوماً اثبات اجرا نشدن مرحله قبلی نیست. مسیریابی آزمایشگاه، فایروال و نشانی انتخاب‌شده ممکن است مسیر برگشت را مسدود کرده باشند. به جای تکرار بی‌هدف آزمون اثرگذار، log هدف و شواهد شبکه مجاز را بررسی کنید و توپولوژی آزمایش را اصلاح کنید. این تحلیل باید در محیط محدود و متعلق به خودتان انجام شود تا هر دو سوی ارتباط قابل مشاهده باشند.
در گزارش، میان «آزمون به هدف نرسید»، «شرایط لازم وجود نداشت» و «نتیجه قابل تأیید نبود» تفاوت بگذارید. هر سه ممکن است در ظاهر بدون نشست پایان یابند، اما معنای امنیتی یکسانی ندارند. زبان دقیق از اطمینان کاذب جلوگیری می‌کند و به تیم اصلاح می‌گوید چه بررسی تکمیلی لازم است. اگر نتیجه مبهم باقی ماند، آن را با شواهد موجود و محدودیت زمان یا دسترسی ثبت کنید؛ حدس زدن درباره موفقیت یا شکست کامل، کیفیت ارزیابی را کاهش می‌دهد.
