چرا Nmap؟
Nmap برای inventory شبکه، بررسی سطح سرویس‌ها و اعتبارسنجی Exposure در محیط‌های مجاز استفاده می‌شود. بسته‌های رسمی Windows، macOS و Linux در سایت پروژه منتشر می‌شوند و Zenmap نیز رابط گرافیکی آن است. اسکن باید فقط روی دارایی‌هایی انجام شود که مجوز ارزیابی‌شان را دارید.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
پرسش درست پیش از اجرای اسکن
Nmap زمانی مفیدتر است که سؤال مشخصی داشته باشید. «چه چیزی در شبکه باز است؟» برای شروع گسترده است، اما «آیا درگاه مدیریتی این سرویس فقط از شبکه مدیریت قابل دسترس است؟» نتیجه قابل آزمون می‌دهد. پیش از اجرا، فهرست دارایی‌های مجاز، محل اجرای اسکن، درگاه‌های مورد نظر و زمان مناسب را بنویسید. این اطلاعات بخشی از نتیجه فنی‌اند، زیرا وضعیت دیده‌شده از یک نقطه شبکه ممکن است با نقطه دیگر تفاوت داشته باشد. خروجی بدون این زمینه می‌تواند در بازبینی بعدی به برداشت نادرست منجر شود.
برای تمرین، یک ماشین آزمایشی خودتان با یک سرویس وب و یک سرویس مدیریتی در نظر بگیرید. انتظار دسترسی هرکدام را از دو شبکه بنویسید. سپس مشاهده واقعی را با انتظار مقایسه کنید. هدف پیدا کردن بیشترین تعداد درگاه نیست؛ هدف کشف اختلاف میان طراحی و وضعیت واقعی است. اگر درگاه غیرمنتظره دیده شد، مالک سرویس و دلیل وجود آن را بررسی کنید. بستن فوری بدون شناخت وابستگی ممکن است اختلال ایجاد کند، و نادیده گرفتن آن نیز سطح دسترسی ناخواسته را باقی می‌گذارد.
کشف میزبان با بررسی درگاه یکسان نیست
مرحله کشف میزبان می‌کوشد تشخیص دهد مقصد در دسترس است یا نه. اگر سیاست شبکه پاسخ بعضی پرس‌وجوها را مسدود کند، نتیجه کشف ممکن است تصویر کاملی از دارایی‌ها ندهد. بنابراین نبودن میزبان در خروجی، به تنهایی اثبات خاموش بودن آن نیست. از فهرست دارایی، سامانه مدیریت و مشاهده سرویس کمک بگیرید. برای یک هدف مشخص و مجاز که وجودش قطعی است، روش ارزیابی باید با سیاست شبکه هماهنگ انتخاب شود. این انتخاب باید در گزارش ثبت شود تا تفاوت دو اجرا قابل توضیح باشد.
نام دامنه نیز می‌تواند به چند نشانی یا زیرساخت مشترک اشاره کند. قبل از اسکن، مطمئن شوید نشانی حل‌شده در محدوده مجاز شماست و فقط به دلیل مالکیت نام، تمام زیرساخت پشت آن را مجاز فرض نکنید. در محیط ابری، تغییر نشانی یا بارمتوازن‌کننده می‌تواند نتیجه را عوض کند. ثبت نشانی واقعی، زمان و محل اجرا کمک می‌کند گزارش به دارایی درست نسبت داده شود. برای ارزیابی تکراری، فهرست هدف باید با دارایی‌های جاری تطبیق داده شود و نشانی قدیمی بی‌دلیل دوباره اسکن نشود.
وضعیت درگاه، گزارش مشاهده است
Open یعنی از دید آزمون، سرویس روی آن درگاه پذیرش دارد. Closed به این معناست که مقصد پاسخ می‌دهد اما سرویس متناظر گوش نمی‌دهد. Filtered بیانگر ناتوانی ابزار در تشخیص باز بودن به دلیل مانع یا فیلتر است. حالت‌های ترکیبی نیز عدم قطعیت را نشان می‌دهند. این واژه‌ها باید همان‌طور که هستند در گزارش بمانند؛ تبدیل همه آن‌ها به «بسته» یا «امن» اطلاعات را از بین می‌برد. راهنمای رسمی وضعیت درگاه‌ها این تفاوت را توضیح می‌دهد.
اگر از داخل شبکه درگاهی باز و از بیرون فیلترشده دیده می‌شود، این دو نتیجه لزوماً متناقض نیستند. ممکن است سیاست دقیقاً همین جداسازی را ایجاد کرده باشد. برای تأیید، مسیر و هویت مبدأ را ثبت کنید و نتیجه را با قانون مورد انتظار مقایسه کنید. همچنین فیلترشدن یک درگاه به معنی امن بودن خود برنامه نیست؛ اگر مسیر مجاز دیگری وجود دارد، برنامه از آن مسیر همچنان در معرض استفاده قرار دارد. ارزیابی سطح دسترسی و ارزیابی آسیب‌پذیری برنامه دو کار مرتبط اما متفاوت‌اند.
نام سرویس با تشخیص نسخه تفاوت دارد
شماره درگاه می‌تواند به یک نام رایج نگاشت شود، اما برنامه واقعی ممکن است روی درگاه غیرمعمول اجرا شود یا پشت پراکسی باشد. تشخیص سرویس و نسخه اطلاعات بیشتری جمع می‌کند، با این حال نتیجه همچنان باید بررسی شود. Banner می‌تواند تغییر داده شده باشد و توزیع‌ها ممکن است اصلاح امنیتی را بدون تغییر ظاهری شماره نسخه اعمال کنند. پس صرف دیدن یک رشته نسخه، اثبات آسیب‌پذیر بودن نیست. برای تصمیم اصلاح، موجودی بسته، وضعیت وصله و مستندات سازنده را با مشاهده شبکه تطبیق دهید.
در گزارش، شواهد خام مرتبط را از نتیجه تحلیلی جدا کنید. بنویسید ابزار چه نامی تشخیص داده و با چه میزان اطمینان یا چه نشانه‌ای، سپس توضیح دهید چه بررسی تکمیلی انجام شده است. اگر فقط احتمال وجود نسخه قدیمی مطرح است، آن را به عنوان نیاز به تأیید ثبت کنید. این دقت جلوی ایجاد هشدارهای بی‌اعتبار برای تیم عملیات را می‌گیرد. اعتبار گزارش امنیتی به تعداد یافته‌ها نیست؛ به قابلیت بازتولید و ارتباط روشن میان شاهد و نتیجه وابسته است.
TCP و UDP را با انتظار یکسان نسنجیم
رفتار پاسخ در UDP با TCP متفاوت است و نبود پاسخ همیشه معنای ساده‌ای ندارد. بعضی سرویس‌ها فقط به درخواست معتبر پاسخ می‌دهند و فیلترها نیز ممکن است خاموش باشند. بنابراین آزمون UDP می‌تواند زمان‌برتر و مبهم‌تر شود. برای هدف آموزشی، چند سرویس مشخص و مجاز را انتخاب کنید و پاسخ را با مشاهده خود سرویس مقایسه کنید. استفاده از فهرست بزرگ درگاه‌ها بدون شناخت نیاز، ممکن است زمان زیادی صرف کند و نتیجه‌ای پر از حالت‌های نامطمئن بدهد.
همچنین محدودیت نرخ پاسخ در تجهیزات میانی می‌تواند بر مدت و نتیجه اثر بگذارد. افزایش تهاجمی سرعت همیشه کیفیت را بهتر نمی‌کند و ممکن است نشانه‌های گم‌شده ایجاد کند. اگر دو اجرا نتایج متفاوت دارند، زمان، بار شبکه و تنظیمات اجرا را مقایسه کنید. برای دستگاه‌های حساس یا قدیمی، با آزمون کوچک و هماهنگ شروع کنید و سلامت سرویس را هم‌زمان ببینید. هدف از این احتیاط، حفظ اعتبار اندازه‌گیری و جلوگیری از تغییر محیط توسط خود آزمون است.
انتخاب اسکریپت باید آگاهانه باشد
موتور اسکریپت Nmap قابلیت‌های متنوعی دارد و همه اسکریپت‌ها اثر یکسان ندارند. پیش از اجرا، هدف، ورودی‌ها و رفتار اسکریپت انتخابی را از مستندات بخوانید. انتخاب گسترده صرفاً بر اساس نام دسته می‌تواند عملیات ناخواسته‌ای وارد ارزیابی کند. برای یک کار ساده موجودی، ممکن است اصلاً به اسکریپت نیاز نباشد. اگر هدف بررسی مشخصی مانند تنظیم عمومی یک سرویس است، همان بررسی محدود را در محیط آزمایش بشناسید و سپس در دامنه مجاز اجرا کنید.
خروجی اسکریپت نیز نیاز به تفسیر دارد. پیام «ممکن است» یا شکست اتصال نباید به یافته قطعی تبدیل شود. اگر اسکریپت به دلیل نبود احراز هویت نتوانسته بررسی را کامل کند، نتیجه عدم دسترسی است، نه اثبات سلامت یا آسیب‌پذیری. در پرونده ارزیابی، نام و نسخه ابزار، اسکریپت انتخابی و آرگومان‌های غیرحساس را نگه دارید. اطلاعات محرمانه‌ای که برای آزمون لازم بوده نباید در فرمان‌های ثبت‌شده یا گزارش عمومی باقی بماند؛ استفاده از روش مناسب مدیریت ورودی اهمیت دارد.
خروجی قابل مقایسه برای موجودی دوره‌ای
برای مقایسه اجراها، خروجی ساخت‌یافته و گزارش خواندنی را همراه با مشخصات اسکن نگه دارید. تغییر محل اجرا، هدف‌ها یا تنظیمات می‌تواند تفاوتی ایجاد کند که ناشی از تغییر واقعی دارایی نیست. یک برنامه دوره‌ای باید این عوامل را تا حد ممکن ثابت نگه دارد. سپس تغییرهای مهم مانند درگاه تازه، سرویس حذف‌شده یا نام نسخه متفاوت را برای بررسی مالک ارسال کند. نتیجه دوره‌ای نباید بدون بازبینی به اقدام تخریبی خودکار منجر شود، زیرا خطای موقت شبکه نیز می‌تواند ظاهر یک سرویس را تغییر دهد.
در تحلیل اختلاف، نشانی را تنها شناسه دارایی ندانید. ماشین‌ها ممکن است جابه‌جا شوند و نشانی قبلی به دارایی دیگری برسد. نام، مالک، شناسه سامانه مدیریت و نقش سرویس به نسبت دادن صحیح کمک می‌کنند. اگر یک درگاه مدیریتی تازه ظاهر شد، مشخص کنید تغییر مجاز بوده یا ناشی از پیکربندی اشتباه است. همین ارتباط با موجودی و فرایند تغییر، Nmap را از یک ابزار خروجی‌ساز به بخشی از کنترل عملیاتی تبدیل می‌کند. اسکن بدون مالک یافته معمولاً به انباشت گزارش‌های خوانده‌نشده ختم می‌شود.
نمونه مسیر بررسی یک یافته
فرض کنید درگاه مدیریت یک ماشین آزمایشی از شبکه کاربران قابل دسترس دیده شده، در حالی که باید فقط از شبکه مدیریت باز باشد. ابتدا مشاهده را با همان تنظیم محدود تکرار کنید. سپس روی میزبان، سرویس گوش‌دهنده و نشانی اتصال آن را بررسی کنید و قواعد شبکه را با طراحی مقایسه کنید. پس از اصلاح، هم مسیر غیرمجاز و هم مسیر مجاز را دوباره آزمایش کنید. بسته شدن همه مسیرها ممکن است یافته را ظاهراً رفع کند اما کار مدیران را مختل سازد؛ آزمون مثبت و منفی هر دو لازم‌اند.
گزارش پایان باید بگوید چه چیزی تغییر کرد، از کدام نقطه آزمون شد و چه محدودیتی باقی است. اگر فقط IPv4 بررسی شده، درباره IPv6 ادعای پوشش نکنید. اگر فقط چند درگاه هدف بررسی شده‌اند، نتیجه را ارزیابی کامل میزبان ننامید. این مرزبندی از ارزش کار کم نمی‌کند؛ باعث می‌شود خواننده بداند دقیقاً کدام فرض تأیید شده است. مرجع رسمی Nmap برای انتخاب گزینه‌ها و تفسیر خروجی مبناست، و سناریوی این بخش یک روش آموزشی دفاعی برای دارایی‌های مجاز است.
محدودیت یک خروجی موفق
تمام شدن اسکن بدون خطای اجرایی به معنی کامل بودن پوشش نیست. ممکن است بخشی از هدف‌ها پاسخ نداده باشند، نام‌ها به مقصد دیگری حل شده باشند یا آزمون فقط یک پروتکل را پوشش داده باشد. پیش از بستن گزارش، تعداد هدف‌های مورد انتظار را با تعداد ارزیابی‌شده مقایسه کنید و موارد نامعلوم را جدا بنویسید. همچنین اگر در زمان اجرا تغییر شبکه رخ داده، آن را ثبت کنید. این بازبینی کوتاه مانع آن می‌شود که نتیجه محدود یک فرمان به عنوان تأیید کلی امنیت شبکه استفاده شود. خروجی خوب باید هم یافته‌ها و هم محدوده اطمینان را به خواننده منتقل کند.
