اسکن آسیب‌پذیری چیست؟ فرق اسکن امنیتی با هک و تست نفوذ

فرض کن مسئول فنی یه مجموعه پارکینگ ساعتی، نتیجه بررسی امنیت سایت رو گذاشته جلوت. صفحه اولش با حروف درشت نوشته «۴۷ هشدار» و چند تا مورد هم قرمزه. مدیر می‌پرسه : «یعنی یکی سایت ما رو هک کرده؟» تو گزارش، نسخه یه سرویس قدیمی دیده شده، چند پورت بازه و یه تنظیم هم مشکوک به نظر می‌رسه. اما هنوز کسی نپرسیده این‌ها واقعاً چه ربطی به سامانه رزرو دارن. از کجا می‌دونیم نسخه درست تشخیص داده شده؟ اصلاً باز بودن اون پورت غیرعادیه؟ قبل از اینکه مدیر رو بترسونیم، باید بفهمیم ابزار دقیقاً چی دیده و چی رو فقط حدس زده.

ببین، موضوع این درس اسکن آسیب‌پذیریه؛ همون کاری که با اسم Vulnerability Scanning می‌شناسی. می‌خوایم بفهمیم اسکن امنیتی سایت چه چیزی رو می‌تونه پیدا کنه، چرا گاهی اشتباه می‌کنه و خروجیش چه فرقی با گزارش تست نفوذ داره. وسط راه هم سراغ Nessus، OpenVAS، Nmap و Nuclei می‌ریم، اما قرار نیست با ردیف کردن اسم ابزارها ادای متخصص بودن رو دربیاریم. یه سناریوی ساختگی رو تا آخر دنبال می‌کنیم، خروجی نمونه رو با پایتون دسته‌بندی می‌کنیم و یاد می‌گیریم هر هشدار چه زمانی ارزش پیگیری داره. هیچ هدف واقعی رو برای این درس اسکن نمی‌کنیم.

اسکن آسیب‌پذیری چیست؟ تعریف ساده با مثال واقعی‌نما

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

یه تفاوت ظریف این وسط هست : هشدار با آسیب‌پذیری تأییدشده یکی نیست. ممکنه ابزار از روی شماره نسخه بگه سرویس مشکل داره، ولی وصله امنیتی روی همون نسخه اعمال شده باشه. ممکنه هم برعکس، اسکن هیچ هشداری نده، درحالی‌که یه خطای منطقی مهم تو فرایند رزرو وجود داره. برای همین توی راهنمای رسمی NIST SP 800-115 اسکن فقط یکی از روش‌های ارزیابی معرفی شده و بررسی نتایج و محدودیت روش‌ها هم بخشی از کاره. پس نه با دیدن رنگ قرمز نتیجه بگیر سایت هک شده، نه با دیدن صفحه سبز خیال خودت رو راحت کن.

اسکن امنیتی سایت دقیقاً چه چیزهایی رو پیدا می‌کنه؟

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

مثلاً پورت ۴۴۳ بازه. خب قرار هم هست کاربر از طریق HTTPS وارد سایت بشه؛ پس صرف باز بودنش نه باگه و نه نشونه نفوذ. حالا اگه یه پنل مدیریتی حساس بدون محدودیت مناسب از اینترنت قابل دسترس باشه، موضوع فرق می‌کنه. اسکن آسیب‌پذیری کمک می‌کنه این نقطه‌ها رو ببینیم، ولی فهمیدن اینکه «وضعیت مشاهده‌شده با طراحی امن سیستم سازگاره یا نه» هنوز به اطلاعات تیم فنی نیاز داره. سعی کن از همین اول مشاهده، احتمال و نتیجه قطعی رو قاطی نکنی.

سناریوی آموزشی : بررسی ۴۷ هشدار در سامانه رزرو جای پارک

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

وسوسه‌انگیزه که از اولین هشدار Critical شروع کنیم و همین‌طور دونه‌دونه جلو بریم، ولی رنگ به‌تنهایی اولویت واقعی رو معلوم نمی‌کنه. شاید ابزار نسخه سرویس رو اشتباه تشخیص داده باشه؛ شاید هم یه تنظیم واقعاً مشکل داشته باشه که اصلاحش چند دقیقه بیشتر طول نکشه. من ترجیح می‌دم اول هر مورد رو به یه سؤال تبدیل کنیم : «چه چیزی مشاهده شده؟ چه مدرکی داریم؟ این دارایی واقعاً داخل محدوده هست؟» جدول زیر دقیقاً همین طرز نگاه رو برای چهار هشدار فرضی نشون می‌ده.

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

فرق اسکن آسیب‌پذیری، ارزیابی آسیب‌پذیری و تست نفوذ چیست؟

اینجا سه اصطلاح رو خوب از هم جدا کن. Vulnerability Scanning خودِ فرایند جست‌وجوی نشونه‌های ضعف رو توصیف می‌کنه. Vulnerability Assessment یا ارزیابی آسیب‌پذیری معمولاً قدم جلوتر می‌ره؛ هشدارها رو با اطلاعات دارایی، شواهد، اعتبار و اولویت اصلاح بررسی می‌کنه. Penetration Testing یا تست نفوذ هم یک ارزیابی هدفمند و مجازه که ممکنه با استفاده از اسکن و تحلیل دستی، اثر بعضی ضعف‌ها رو تا حد توافق‌شده بسنجه. تفاوت اسکن آسیب‌پذیری و تست نفوذ توی پروژه‌ها می‌تونه هم‌پوشانی داشته باشه؛ اما صرف گرفتن خروجی از اسکنر، جای گزارش تست نفوذ رو نمی‌گیره.

پس جواب سؤال «اسکن بهتره یا تست نفوذ؟» این نیست که یکی رو برای همیشه انتخاب کنیم. برای پایش منظم چندین سرور، اسکن آسیب‌پذیری خیلی کمک‌کننده‌ست. برای فهمیدن اینکه یه کاربر می‌تونه قیمت رزرو رو دست‌کاری کنه یا به اطلاعات بقیه دسترسی بگیره، معمولاً به بررسی عمیق‌تر نیاز داریم. اگر مفهوم این دو کار هنوز قاطیه، یه بار درس تست نفوذ چیست؟ رو بخون. اینجا تمرکز ما روی کیفیت خروجی اسکنره، نه تکرار تعریف Pentest.

False Positive و False Negative در اسکن آسیب‌پذیری

دو اصطلاح هست که هر کسی می‌خواد اسکن آسیب‌پذیری رو درست بفهمه باید بلد باشه : False Positive و False Negative. اولی یعنی اسکنر هشدار داده ولی بعد از بررسی معتبر می‌فهمیم اون هشدار برای این دارایی درست نبوده. دومی یعنی ضعف واقعی وجود داشته، اما اسکنر پیداش نکرده. به زبان خودمونی، یکی «آژیر بی‌مورد»ه و اون یکی «مشکلی که از زیر چشم ابزار در رفته». هر دو روی تصمیم تیم امنیت اثر می‌ذارن و به همین خاطره که نتیجه خام ابزار نباید آخرین حرف ما باشه.

مثبت کاذب چه شکلیه؟

برای فهمیدن False Positive چیست، یه مثال واقعی از رفتار بسته‌های نرم‌افزاری بزنیم. ابزار اسکن آسیب‌پذیری روی سرور یه شماره نسخه قدیمی می‌بینه و اون رو به CVE مربوط می‌کنه. اما ممکنه توزیع لینوکس، اصلاح امنیتی رو روی همون شاخه قدیمی اعمال کرده باشه؛ به این کار Backport می‌گن. خود مستندات Red Hat درباره Backporting توضیح می‌ده که قضاوت صرفاً از روی شماره نسخه می‌تونه هشدار اشتباه بسازه. پس باید بسته نصب‌شده، اطلاعیه سازنده و جزئیات وصله رو هم ببینیم، نه فقط بنر سرویس رو.

البته از این مثال نتیجه نگیر که هر وقت مدیر سرور گفت «وصله داریم»، هشدار رو ببندیم. حرف درست اینه : مدرک نشون بده. اسم بسته، نسخه بسته‌بندی‌شده توزیع، شناسه اصلاح و راهنمای رسمی سازنده می‌تونن کمک کنن. اگر هنوز شواهد کافی نداریم، وضعیت رو «در انتظار بررسی» می‌ذاریم؛ نه بی‌دلیل «آسیب‌پذیر» و نه عجولانه «سالم». این همون جاییه که تحلیل تخصصی از کلیک کردن روی دکمه Scan جدا می‌شه.

منفی کاذب چه شکلیه؟

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

توی راهنمای OWASP درباره Business Logic Testing هم همین مسئله توضیح داده شده : ایرادهای منطق کسب‌وکار معمولاً به شناخت جریان واقعی برنامه و بررسی حالت‌های غیرعادی نیاز دارن. پس قبل از اینکه درباره «امنیت کامل سایت» حرف بزنیم، باید بدونیم چه چیزهایی اصلاً تست نشده. این نکته به‌خصوص برای فروشگاه، کیف پول، رزرو، تخفیف و سامانه‌های چندنقشی خیلی مهمه.

اسکن آسیب‌پذیری با حساب کاربری و بدون حساب چه فرقی داره؟

تا حالا به این فکر کردی چرا دو گزارش اسکن آسیب‌پذیری از یه سایت گاهی نتیجه متفاوت می‌دن؟ یکی از دلیل‌ها سطح دسترسیه. توی Unauthenticated Scan ابزار بدون نشست معتبر، از دید یه بازدیدکننده بیرونی بررسی می‌کنه. توی Authenticated Scan با حساب آزمایشی مجاز می‌تونه بخش‌های پشت صفحه ورود رو هم ببینه. برای سرورها هم Credentialed Scan ممکنه از دسترسی محدودِ سیستم‌عاملی برای بررسی بسته‌ها و پیکربندی واقعی استفاده کنه. این مدل‌ها لزوماً جای هم نیستن؛ هر کدوم یه محدوده دید متفاوت دارن.

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

اسکن آسیب‌پذیری Passive و Active؛ آیا هر اسکن امنه؟

یه تقسیم‌بندی دیگه هم داریم : Passive و Active. در بررسی غیرفعالِ وب، معمولاً پاسخ‌ها و ترافیکی رو تحلیل می‌کنیم که از تعامل‌های موجود به دست اومدن، بدون اینکه برای آزمودن ضعف درخواست اضافه‌ای بسازیم. اسکن فعال ممکنه درخواست‌های تازه‌ای برای بررسی رفتار سامانه بفرسته. توجه کن «Passive» به معنی «همیشه مجاز و بدون ریسک» نیست؛ شیوه جمع‌آوری داده و رعایت حریم خصوصی همچنان مهمه. همین‌طور «Active» ذاتاً غلط نیست، ولی باید روشش صریحاً مجاز باشه.

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

ابزارهای اسکن آسیب‌پذیری؛ Nessus، OpenVAS، Nmap و Nuclei

بریم سراغ اسم‌هایی که زیاد می‌شنوی. شاید سرچ کرده باشی «ابزار اسکن آسیب‌پذیری چی خوبه؟» یا «Nessus چیست و OpenVAS چیست؟» جواب بستگی داره دنبال چه نوع ضعفی هستی. Nessus بیشتر برای بررسی دارایی‌ها و آسیب‌پذیری‌ها و پیکربندی‌ها شناخته می‌شه؛ OpenVAS در اکوسیستم Greenbone نقش اسکنر رو داره؛ Nuclei با Templateهای مشخص بررسی می‌کنه؛ Nmap بیشتر برای کشف میزبان و سرویس شناخته می‌شه و بعضی اسکریپت‌های امنیتی هم داره. جدول زیر کاربرد هر کدوم رو جدا می‌کنه تا اسم ابزار رو با نتیجه واقعی قاطی نکنیم.

نکته‌ای که مخصوصاً توی Nmap و تست نفوذ باید یادت بمونه اینه که باز بودن پورت یا کشف نسخه، به‌تنهایی اثبات ضعف نیست. مستندات رسمی Nmap Scripting Engine نشون می‌ده NSE قابلیت اجرای اسکریپت‌های متنوع، از جمله بعضی بررسی‌های امنیتی رو داره؛ ولی اجرای Nmap معادل تست کامل امنیت سایت نیست. برای انتخاب ابزارها می‌تونی سراغ مستندات Greenbone و راهنمای Nuclei هم بری. به‌جای اینکه بگی «با فلان ابزار هک کردم»، بگو چه چیزی رو، با چه مجوزی و با چه مدرکی بررسی کردی.

CVE، CVSS و KEV در گزارش اسکن آسیب‌پذیری یعنی چی؟

در خروجی اسکن آسیب‌پذیری ممکنه شناسه‌ای مثل CVE-2024-XXXX ببینی؛ اینجا XXXX فقط جای‌نگه‌دارِ مثال ماست، نه یک CVE واقعی. برنامه CVE برای شناسایی و ارجاع مشترک به ضعف‌های عمومی شناخته‌شده‌ست. ولی اینکه یه هشدار اسم CVE رو آورده، ثابت نمی‌کنه سرور تو هم واقعاً اون ضعف رو داره. باید محصول، نسخه، بسته توزیع، شرایط فعال شدن ضعف و وضعیت وصله رو بررسی کنی. اگه این زنجیره معلوم نباشه، هنوز یه سرنخ داریم، نه نتیجه قطعی.

کنار CVE معمولاً عدد CVSS رو هم می‌بینی. این امتیاز برای توصیف شدت ویژگی‌های فنی آسیب‌پذیریه، اما به‌تنهایی نمی‌گه کسب‌وکار تو چقدر در معرض خطره. مثلا یه سرویس داخلی ایزوله و یه سامانه پرداخت در دسترس اینترنت ممکنه به یک ضعف مشابه واکنش متفاوتی نشون بدن. برای فهم امتیازها، مرجع رسمی FIRST درباره CVSS رو ببین و برای تشخیص تفاوت شدت و ریسک هم درس تهدید، آسیب‌پذیری و ریسک کمک می‌کنه. اولویت اصلاح با رنگ گزارش به‌تنهایی تعیین نمی‌شه.

یه منبع دیگه که موقع اولویت‌بندی به کار میاد، فهرست CISA Known Exploited Vulnerabilities یا KEV هست. این فهرست مواردی رو جمع می‌کنه که شواهد سوءاستفاده واقعی ازشون وجود داره. البته وجود یه CVE داخل KEV به معنی آسیب‌پذیر بودن قطعی سامانه ما نیست؛ باید اول ببینیم اصلاً محصول و شرایط ما به اون مورد مربوط می‌شن یا نه. نبودن یه مورد در KEV هم اثبات نمی‌کنه هیچ مهاجمی ازش استفاده نکرده. برای تصمیم خوب، چند منبع شواهد رو کنار هم می‌ذاریم.

از هشدار اسکنر تا یافته قابل اعتماد؛ مدل سه‌دروازه‌ای ما

حالا می‌خوام یه روش ساده برای خوندن هشدارها بهت بدم؛ اسمش رو توی این درس می‌ذاریم «نشانه → اعتبارسنجی → تصمیم». این اسم، استاندارد رسمی جهانی نیست؛ فقط یه مدل آموزشی برای مرتب کردن فکرمونه. وقتی اسکن آسیب‌پذیری هشدار می‌ده، اول می‌پرسیم چه چیزی دیده؛ بعد می‌سنجیم شواهد با واقعیت دارایی جور درمیاد یا نه؛ آخر سر تصمیم می‌گیریم مورد تأیید شده، اشتباه بوده یا هنوز به بررسی احتیاج داره. همین سه سؤال جلوی خیلی از گزارش‌های عجولانه رو می‌گیره.

SIGNAL  →  VALIDATION  →  DECISION

What was observed?
       ↓
What evidence supports it?
       ↓
What is actually affected?
       ↓
Confirm / Reject / Investigate / Stop

دروازه اول : ابزار دقیقاً چه چیزی مشاهده کرده؟

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

دروازه دوم : شواهد با وضعیت واقعی تطبیق دارن؟

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

دروازه سوم : چه تصمیم قابل اقدامی باید ثبت کنیم؟

در قدم سوم، به هر هشدار یه وضعیت قابل پیگیری می‌دیم : Confirmed برای موردی که واقعاً بررسی و تأیید شده، False Positive برای مورد ردشده با دلیل، Needs Review برای نتیجه نامشخص و Out of Scope برای موردی که اجازه بررسیش رو نداریم. وضعیت‌ها رو آدم مسئول بر اساس شواهد تعیین می‌کنه، نه اینکه برنامه از روی رنگ Critical حدس بزنه. بعد باید معلوم باشه چه کسی مسئول اصلاحه، دلیل تصمیم چی بوده و نتیجه بررسی مجدد کجا ثبت می‌شه.

تمرین پایتون آفلاین : خروجی اسکنر رو چطور دسته‌بندی کنیم؟

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

ACTIONS = {
    "confirmed": "send to remediation",
    "false_positive": "record evidence and close",
    "needs_review": "request more evidence",
    "out_of_scope": "stop and clarify authorization",
}


def route_finding(record):
    if not isinstance(record, dict):
        return "UNKNOWN", "manual review: invalid record"

    finding_id = record.get("id")
    if not isinstance(finding_id, str) or not finding_id.strip():
        return "UNKNOWN", "manual review: invalid id"

    status = record.get("status")
    if not isinstance(status, str):
        return finding_id, "manual review: invalid status"

    return finding_id, ACTIONS.get(status, "manual review: unknown status")


findings = [
    {"id": "F-01", "status": "confirmed"},
    {"id": "F-02", "status": "false_positive"},
    {"id": "F-03", "status": "needs_review"},
    {"id": "F-04", "status": "out_of_scope"},
]

for item in findings:
    finding_id, action = route_finding(item)
    print(f"{finding_id} -> {action}")

اگه برنامه رو با پایتون ۳ اجرا کنی، این خروجی رو می‌بینی :

F-01 -> send to remediation
F-02 -> record evidence and close
F-03 -> request more evidence
F-04 -> stop and clarify authorization

فقط مورد F-01 به مسیر اصلاح می‌ره؛ چون توی داده ساختگی ما وضعیتش از قبل confirmed ثبت شده. مورد دوم بسته می‌شه اما باید دلیل False Positive بودنش همراهش باشه؛ مورد سوم شواهد بیشتری می‌خواد و مورد چهارم باید متوقف بشه تا محدوده مجوز روشن بشه. اگه کسی به‌اشتباه وضعیت confirmed رو روی یه هشدار تأییدنشده ثبت کنه، این برنامه نمی‌تونه حقیقت رو کشف کنه. این مثال فقط یه مسیریاب آموزشی برای داده‌های بررسی‌شده‌ست، نه سامانه امن مدیریت آسیب‌پذیری در Production.

اسکن امنیتی سایت بدون مجوز هم میشه انجام داد؟

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

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

وقتی گزارش اسکن آسیب‌پذیری صفر شد، سایت امنه؟

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

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

اسکن آسیب‌پذیری رو هر چند وقت یک‌بار انجام بدیم؟

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

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

گزارش اسکن آسیب‌پذیری باید چه اطلاعاتی داشته باشه؟

یه گزارش اسکن آسیب‌پذیری خوب نباید فقط ۴۷ ردیف اسم CVE باشه. باید بفهمیم دقیقاً چه دارایی و محیطی بررسی شده، اسکن چه تاریخی انجام شده، با چه نوع دسترسی‌ای جلو رفته و کجاها محدودیت داشته. برای هر هشدار هم باید شواهد اولیه، وضعیت اعتبارسنجی، اثر احتمالی، مسئول پیگیری و پیشنهاد اصلاح معلوم باشه. اون وقت مدیر می‌فهمه چه چیزی نیاز به تصمیم داره و توسعه‌دهنده هم می‌تونه سراغ مشکل مشخص بره؛ نه اینکه با یه PDF پر از رنگ تنها بمونه.

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

پنج اشتباه رایج موقع شروع اسکن امنیتی و هک

اشتباه اول : هر پورت باز رو آسیب‌پذیری بدونیم

هر پورت بازی باگ نیست. مثلاً وب‌سایتی که باید HTTPS ارائه بده، طبیعی‌ه که سرویس مناسبش در دسترس باشه. سؤال بهتر اینه که آیا اون سرویس با هدف واقعی سامانه سازگاره، به‌روز و درست پیکربندی شده و فقط به اندازه نیاز در معرض دسترس قرار گرفته؟ توی اسکن امنیتی سایت، اگه صرف دیدن عدد پورت نتیجه بگیری «نفوذ شد»، تحلیل رو از همون اول اشتباه رفتی.

اشتباه دوم : عدد CVSS رو با ریسک واقعی برابر بگیریم

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

اشتباه سوم : هیچ هشداری نیومده، پس سیستم هک نمیشه

اگه اسکنر چیزی پیدا نکرد، خوبه؛ ولی هنوز درباره چیزهایی که ندیده حرفی نزده. شاید باید با یه نقش کاربری دیگه وارد می‌شده، شاید APIای بیرون از پوشش مونده یا شاید ایراد فقط هنگام استفاده هم‌زمان از تخفیف‌ها اتفاق بیفته. اسکن آسیب‌پذیری قراره کمک کنه سرنخ‌ها رو پیدا کنیم، نه اینکه نبود هشدار رو به «هک‌نشدنی بودن» ترجمه کنیم.

اشتباه چهارم : برای اثبات هشدار، بدون مجوز جلوتر بریم

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

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

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

چهار تمرین تحلیلی؛ از هشدار ابزار تا تصمیم حرفه‌ای

تمرین اول : نسخه سرویس با وصله Backport

فرض کن اسکن آسیب‌پذیری یه سرویس رو به CVE مشخصی مرتبط کرده، ولی تیم فنی می‌گه اصلاح امنیتی از طریق Backport اعمال شده. بدون بررسی، کدوم رو قبول می‌کنی؟ هیچ‌کدوم رو قطعی فرض نمی‌کنی. نسخه بسته، اطلاعیه امنیتی سازنده و شواهد وصله رو می‌بینی. اگه اطلاعات کافی نبود، هشدار رو باز نگه می‌داری تا بررسی بشه؛ نه اینکه از سر ترس تأییدش کنی یا از روی اعتماد کورکورانه ببندیش.

تمرین دوم : یک تخفیف و دو رزرو

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

تمرین سوم : گزارش روی دارایی بیرون از محدوده

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

تمرین چهارم : هشدار جدی اما شواهد ناقص

ابزار اسکن آسیب‌پذیری کنار یه یافته نوشته Critical، اما تنها چیزی که ثبت کرده یه حدس درباره شماره نسخه‌ست. آیا می‌تونی به مدیر بگی «نفوذ بحرانی تأیید شد»؟ قطعاً نه. شدت پیشنهادی ابزار، کیفیت شواهد و وضعیت تأیید سه چیز متفاوتن. باید دقیق بنویسیم چه چیزی مشاهده شده، چه چیزی هنوز نامعلومه و برای تصمیم بعدی به چه بررسی مجازی نیاز داریم.

بعد از یادگیری اسکن آسیب‌پذیری، مسیرت برای تست نفوذ چیه؟

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

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

سؤالات متداول درباره اسکن آسیب‌پذیری و تست نفوذ

منابع معتبر برای بررسی عمیق‌تر

اگه می‌خوای این موضوع رو از روی منابع اصلی هم دنبال کنی، NIST SP 800-115 درباره روش‌ها و محدودیت ارزیابی‌های امنیتی توضیح می‌ده؛ OWASP WSTG برای آزمون امنیت وب مرجعه؛ راهنمای NSE در Nmap قابلیت‌های واقعی این ابزار رو روشن می‌کنه؛ و فهرست KEV در CISA یه ورودی برای اولویت‌بندی ضعف‌های دارای شواهد سوءاستفاده‌ست. برای خطای تشخیص نسخه هم توضیح رسمی Red Hat درباره Backport رو بخون. همه مثال‌های پارکینگ، عدد ۴۷ و داده‌های پایتون توی این درس ساختگی‌ان و قرار نیست به‌عنوان نتیجه آزمایش واقعی معرفی بشن.

جمع‌بندی : اسکنر سرنخ می‌ده، تحلیل امنیتی به اون معنا می‌ده

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

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