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