مراحل تست نفوذ چیست؟ از شناسایی تا گزارش و رفع آسیب‌پذیری

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

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

مراحل تست نفوذ چیست؟ ۶ گام از مجوز تا بررسی دوباره

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

Permission & Scope
       ↓
Understand the system
       ↓
Identify possible weaknesses
       ↓
Validate safely
       ↓
Document & report
       ↓
Fix & retest

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

آیا روش انجام تست نفوذ برای همه پروژه‌ها یکسانه؟

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

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

یه تفاوت دیگه هم هست: عبارت‌های مراحل Penetration Testing و مراحل هک و تست نفوذ رو ممکنه توی جست‌وجوها کنار هم ببینی، اما هر روشی که از دید مهاجم استفاده می‌کنه لزوماً «مجاز» نیست. برای آموزش مراحل تست نفوذ باید قبل از تکنیک‌ها یاد بگیری چه کاری داخل قرارداد جا می‌گیره. مثلاً یک پروژه Gray Box با حساب تست می‌تونه خیلی متفاوت‌تر از یه پروژه Black Box پیش بره؛ اسم روش بدون Scope و هدف چیز زیادی بهمون نمی‌گه.

یه مثال واقعی‌نما : تست امنیت سامانه امانت تجهیزات

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

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

مرحله اول : مجوز، هدف و Scope تست نفوذ

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

Scope دقیقاً شامل چه چیزهاییه؟

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

این توافق‌ها رو معمولاً توی سند Rules of Engagement یا ROE ثبت می‌کنن: هدف پروژه، محدوده، زمان مجاز، روش‌های ممنوع، راه تماس اضطراری و شرایط توقف. تصور کن وسط کار با یه خطای عجیب روبه‌رو شدی که شاید اطلاعات واقعی نشون بده؛ اون لحظه نباید با حدس تصمیم بگیری ادامه بدی. سند توافق دقیقاً برای همین موقعیت‌هاست. صفحه بخش هماهنگی اولیه PTES هم روی اهمیت تعیین Scope تأکید می‌کنه.

خروجی قابل تحویل مرحله اول چیه؟

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

مرحله دوم : جمع‌آوری اطلاعات در تست نفوذ (Reconnaissance)

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

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

تفاوت جمع‌آوری اطلاعات Passive و Active چیه؟

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

خروجی مرحله شناسایی چیه؟

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

مرحله سوم : تحلیل سطح حمله و ساختن فرضیه امنیتی

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

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

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

مرحله چهارم : آزمون کنترل‌شده و ثبت شواهد

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

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

آیا مرحله Exploitation همیشه باید به دسترسی کامل برسد؟

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

تفاوت مشاهده، شواهد و فرضیه چیه؟

یه عادت حرفه‌ای پیدا کن: همیشه «چیزی که دیدم» رو از «برداشتی که ازش دارم» جدا کن. Observation خود مشاهده‌ست؛ مثلاً «این حساب تست پاسخ ۲۰۰ گرفت». Evidence شواهد قابل ارائه‌ایه که شرایط اون مشاهده رو نشون می‌ده؛ مثل درخواستِ بدون داده حساس و پاسخ مربوط. Assumption هم چیزیه که هنوز تأیید نکردیم؛ مثلاً «شاید بقیه حساب‌ها هم همین مشکل رو داشته باشن». هیچ‌کدوم رو جای اون یکی ننویس. پاسخ ۲۰۰ هم به‌تنهایی اثبات دسترسی غیرمجاز نیست؛ باید محتوای پاسخ و رفتار مورد انتظار رو هم بفهمیم.

در طول تست، چه زمانی باید فوراً توقف کنیم؟

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

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

مرحله پنجم : تبدیل یافته‌ها به گزارش تست نفوذ

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

گزارش مدیریتی و فنی چه فرقی دارن؟

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

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

اولویت‌بندی یافته‌ها فقط با برچسب Critical انجام میشه؟

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

مرحله ششم : اصلاح، Retest تست نفوذ و پیگیری یافته

یکی از قسمت‌هایی که خیلی‌ها زود ازش رد می‌شن، Retest تست نفوذه. فرض کن تیم برنامه‌نویسی کنترل مالکیت رزرو رو اصلاح کرده. این یعنی کار تمومه؟ هنوز نه؛ باید دوباره همون شرایط مجاز رو بسنجیم تا ببینیم رفتار اشتباه قبلی تکرار می‌شه یا نه. Retest معمولاً یه ارزیابی هدفمند روی یافته اصلاح‌شده‌ست و با اجرای دوباره یه پروژه کامل Pentest فرق داره.

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

اگر باگ در Retest هنوز وجود داشت چه میشه؟

اگه مشکل هنوز تکرار می‌شه، وضعیت یافته «رفع نشده» می‌مونه و نتیجه جدید با شواهد مجاز به تیم توسعه برمی‌گرده. اگه اصلاح یه رفتار دیگه رو خراب کرده، اون هم باید به‌عنوان موضوع جدا بررسی بشه. در نهایت هر یافته باید وضعیت روشنی داشته باشه: باز، در حال اصلاح، آماده Retest یا رفع‌شده و تأییدشده در محدوده بررسی.

مراحل تست نفوذ در عمل خطی نیست؛ چه چیزهایی بین مرحله‌ها برمی‌گردن؟

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

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

یک نمونه فلوچارت تصمیم‌گیری؛ در هر مرحله چه باید کرد؟

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

Asset AND activity authorized?
  No / Unclear  → STOP: clarify scope and permission
  Yes           → Describe expected behavior
                    ↓
               Have a testable hypothesis?
                 No  → Gather approved information
                 Yes → Validate within agreed limits
                          ↓
                    Enough safe evidence?
                      No  → Document limitation / seek approval
                      Yes → Record finding, impact and fix
                                   ↓
                           Remediation → Authorized retest

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

تمرین Python آفلاین : آیا یک فعالیت در محدوده تست قرار می‌گیره؟

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

approved_assets = {"training-app", "test-accounts"}
approved_actions = {"read-test-data", "review-role-permissions"}


def is_in_scope(asset, action, permission_confirmed):
    return (
        type(permission_confirmed) is bool
        and permission_confirmed
        and isinstance(asset, str)
        and isinstance(action, str)
        and asset in approved_assets
        and action in approved_actions
    )


checks = [
    ("training-app", "review-role-permissions", True),
    ("payment-provider", "review-role-permissions", True),
    ("training-app", "stress-test", True),
    ("training-app", "read-test-data", False),
]

for asset, action, permission in checks:
    print(is_in_scope(asset, action, permission))

خروجی اجرای مثال برای چهار حالت اولیه اینه :

True
False
False
False

فقط بررسی اول قبول شد، چون دارایی و فعالیت هر دو در لیست مجاز بودن و تأیید مجوز هم دقیقاً True بود. مورد دوم به سرویس پرداخت خارج از Scope اشاره می‌کنه؛ مورد سوم فعالیت ممنوعه؛ مورد چهارم هم مجوز تأیید نشده. دقت کن اگه دارایی ناشناخته باشه یا مقدار مجوز رو اشتباهی به صورت متن بفرستیم، نسخه اصلاح‌شده کد نتیجه رو False می‌ده. باز هم تأکید می‌کنم: توی پروژه واقعی وجود این سه مقدار داخل یه برنامه، جای قرارداد، احراز هویت و هماهنگی با مالک رو نمی‌گیره.

چه ابزارهایی در مراحل تست نفوذ استفاده میشن؟

توی هر کدوم از مراحل تست نفوذ ممکنه از ابزار متفاوتی استفاده کنی. برای شناخت سرویس‌های مجاز، Nmap می‌تونه به کار بیاد؛ برای بررسی درخواست و پاسخ وب، Burp Suite؛ و برای تحلیل ترافیک شبکه، Wireshark. ولی هیچ‌کدوم خودشون نمی‌فهمن سیاست دسترسی سامانه امانت تجهیزات چی بوده. ابزار بهت داده می‌ده؛ تفسیر و نتیجه‌گیری درست با خودته.

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

سه اشتباه رایج هنگام اجرای یک پروژه تست نفوذ

اشتباه اول : اسکن رو جای برنامه‌ریزی می‌ذاریم

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

اشتباه دوم : تعداد یافته‌ها رو با کیفیت ارزیابی اشتباه می‌گیریم

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

اشتباه سوم : فقط به نفوذ فکر می‌کنیم و اصلاح رو فراموش می‌کنیم

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

چهار تمرین تحلیلی : قبل از جواب خودت تصمیم بگیر

تمرین اول : مجوز برای سایت هست، نه سرویس پیامک

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

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

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

تمرین سوم : یک نقش حق مشاهده داره، نه تغییر

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

تمرین چهارم : اصلاح انجام شده ولی Retest نداشتیم

توسعه‌دهنده می‌گه مشکل مالکیت رزرو رو حل کرده، اما تست قبلی هنوز تکرار نشده. می‌شه وضعیت رو Verified Fixed زد؟ جواب: نه؛ فعلاً «اصلاح اعلام شده، منتظر بررسی مجدد» دقیق‌تره. تا آزمون مجاز تکرار نشه، رفع شدن رفتار مشکل‌دار تأیید نشده.

هر مرحله از تست نفوذ چه خروجی‌ای داره؟

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

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

مراحل تست نفوذ چقدر زمان می‌بره و چه چیزی روی زمان اثر داره؟

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

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

بعد از شناخت مراحل تست نفوذ، چی یاد بگیریم؟

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

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

سؤالات متداول درباره مراحل تست نفوذ

منابع معتبر برای بررسی بیشتر

اگه خواستی اطلاعات این درس رو با منابع تخصصی تطبیق بدی، NIST SP 800-115 رو برای طراحی و اجرای ارزیابی امنیتی ببین. برای تست برنامه‌های وب، راهنمای پایدار OWASP WSTG مفیده. مستندات PTES هم تقسیم‌بندی هفت‌بخشی خودش رو داره و مستندات FIRST درباره CVSS بهت کمک می‌کنه شدت فنی رو بهتر بشناسی. همه این لینک‌ها منابع مطالعه‌ان؛ سناریوی امانت تجهیزات و مثال‌های این درس ساختگی و آموزشی هستن.

جمع‌بندی : تست نفوذ از برنامه‌ریزی شروع می‌شه، نه ابزار

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

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