تست نفوذ چیست؟ تفاوت Pentest با هک و اسکن امنیتی

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

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

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

تست نفوذ چیست؟ تعریف ساده و دقیق Pentest

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

برای تعریف فنی‌تر، واژه‌نامه NIST درباره Penetration Testing رو ببین. این مرجع درباره آزمودن مقاومت کنترل‌های امنیتی با روش‌های شبیه‌سازی حمله صحبت می‌کنه. اما یه نکته رو اشتباه نگیریم: هدف تست نفوذ لزوماً رسیدن به دسترسی غیرمجاز نیست. ممکنه یه کنترل درست کار کنه، ممکنه شواهد برای نتیجه‌گیری کافی نباشن، یا محدودیت‌های ایمنی اجازه ادامه تست رو ندن. گزارش خوب باید هر سه حالت رو دقیق توضیح بده، نه اینکه از هر نتیجه‌ای یه داستان نفوذ موفق بسازه.

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

فرق هک و تست نفوذ چیه؟

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

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

چرا شرکت‌ها تست نفوذ انجام می‌دن؟

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

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

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

یک سناریوی اختصاصی : تست نفوذ سامانه بلیت کنسرت

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

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

قدم اول سناریو : رفتار مورد انتظار رو بنویسیم

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

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

قدم دوم سناریو : یک سرنخ پیدا میشه

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

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

قدم سوم سناریو : اثبات کنترل‌شده، نه رفتن تا آخر خط

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

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

قدم چهارم سناریو : گزارش باید به درد توسعه‌دهنده بخوره

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

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

مدل ذهنی اختصاصی برای فهمیدن یک Pentest واقعی

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

Expected rule
      ↓
Security hypothesis
      ↓
Authorized, low-impact test
      ↓
Observed evidence
      ↓
Business impact
      ↓
Fix recommendation
      ↓
Authorized retest

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

مراحل تست نفوذ در ۵ قدم ساده

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

۱. تعیین هدف، مجوز و محدوده

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

۲. شناخت هدف و جمع‌آوری اطلاعات

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

۳. تحلیل سرنخ‌ها و فرضیه‌های امنیتی

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

۴. اعتبارسنجی محدود و ثبت شواهد

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

۵. گزارش، اصلاح و بررسی دوباره

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

انواع تست نفوذ؛ Black Box، Gray Box و White Box

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

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

تست نفوذ سایت با تست نفوذ شبکه چه فرقی داره؟

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

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

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

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

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

تست نفوذ با باگ‌بانتی و Red Team چه تفاوتی داره؟

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

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

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

اگه تازه فهمیدی تست نفوذ چیست و حالا دنبال آموزش تست نفوذ می‌گردی، احتمالاً اسم Kali Linux، Nmap، Burp Suite و Metasploit رو شنیدی. این‌ها ابزارهای شناخته‌شده‌ای هستن، ولی هیچ‌کدوم جای فهم شبکه، وب و سیستم‌عامل رو نمی‌گیرن. باید بدونی IP و پورت چی هستن، درخواست HTTP چه مراحلی داره، ورود کاربر با مجوز انجام عملیات چه فرقی داره و چرا یه هشدار ممکنه اشتباه باشه.

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

آیا کالی لینوکس برای تست نفوذ اجباریه؟

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

آیا بدون برنامه‌نویسی میشه Pentest یاد گرفت؟

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

یک تمرین آفلاین : آیا این دسترسی باید مجاز باشه؟

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

users = {
    "neda": {"role": "operator", "event": 7},
    "amir": {"role": "organizer", "event": 7},
    "sara": {"role": "organizer", "event": 8},
    "ali": {"role": "organizer", "event": 1},
}


def can_view_sales_report(authenticated_username, event_id):
    # In a real app, this identity MUST come from a verified server-side session.
    if not isinstance(authenticated_username, str):
        return False
    if type(event_id) is not int or event_id <= 0:
        return False

    user = users.get(authenticated_username)
    if user is None:
        return False

    return (
        user["role"] == "organizer"
        and type(user["event"]) is int
        and user["event"] == event_id
    )


print(can_view_sales_report("neda", 7))
print(can_view_sales_report("amir", 7))
print(can_view_sales_report("sara", 7))
print(can_view_sales_report("unknown", 7))
print(can_view_sales_report("amir", "7"))
print(can_view_sales_report("ali", True))
print(can_view_sales_report("ali", 1))

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

False
True
False
False
False
False
True

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

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

یک گزارش تست نفوذ حرفه‌ای چه چیزهایی داره؟

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

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

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

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

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

تست نفوذ چه کاری نمی‌تونه تضمین کنه؟

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

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

اشتباه‌های رایج تازه‌کارها در یادگیری تست نفوذ

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

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

اشتباه دوم : هر پورت باز یا هشدار رو باگ قطعی می‌دونیم

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

اشتباه سوم : برای اثبات ضعف بیش از حد جلو می‌ریم

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

اشتباه چهارم : تست نفوذ رو با حذف همه خطرها یکی می‌دونیم

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

اشتباه پنجم : گزارش رو آخر کار و بی‌اهمیت می‌بینیم

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

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

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

تمرین اول : مدیر فقط گفته «سایتم رو تست کن»

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

تمرین دوم : ابزار نوشته Critical، اما اثر مشخص نیست

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

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

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

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

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

یادگیری تست نفوذ رو از کجا شروع کنیم تا به مهارت واقعی برسیم؟

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

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

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

منابع معتبر برای مطالعه دقیق‌تر

اگه می‌خوای تعریف‌ها و روش کار رو از منبع اصلی هم بخونی، از واژه‌نامه NIST و راهنمای NIST SP 800-115 شروع کن. برای جزئیات تست وب، OWASP Web Security Testing Guide و برای مسائل کنترل دسترسی، مستند OWASP Broken Access Control مفیدن. درباره سازمان‌دهی فازها هم می‌تونی مستندات PTES رو ببینی. این درس و مثال بلیت مستقل و آموزشی نوشته شدن؛ لینک‌ها برای بررسی دقیق‌تر مفهوم‌ها هستن، نه اینکه داستان ما یه پروژه واقعی بوده باشه.

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

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

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