رفتن به محتوا
IROSG.
EN
اپلیکیشن‌های امنیتی

Greenbone Community Edition

پلتفرم متن‌باز Vulnerability Management برای اسکن و مدیریت آسیب‌پذیری در زیرساخت‌های مجاز.

Greenbone Community Edition — تصویر رسمی
سازندهGreenbone
حوزهVulnerability management
پلتفرم‌هاLinux · Containers · Kali Linux
مجوز / مدلOpen source community stack
صفحهٔ رسمی ↗دانلود رسمی ↓

چرا Greenbone Community Edition؟

Greenbone Community Edition مجموعه‌ای برای Vulnerability Management است و مسیرهای نصب با container، Kali Linux و source code را ارائه می‌کند. برای اسکن شبکه باید targetها در Scope سازمان یا آزمایشگاه مجاز باشند و زمان‌بندی اسکن با ظرفیت سرویس‌ها هماهنگ شود.

دریافت امن

برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.

استفاده مسئولانه

در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.

مدیریت آسیب‌پذیری فراتر از اجرای یک اسکن است

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

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

اجزای سامانه و وابستگی‌های داده

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

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

انتخاب مسیر نصب قابل نگهداری

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

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

موجودی دارایی و دامنه مجاز

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

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

اسکن بدون اعتبارنامه و اسکن دارای اعتبارنامه

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

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

شدت اسکن و ظرفیت سرویس

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

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

یافته، شواهد و مثبت کاذب

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

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

اولویت اصلاح بر اساس اثر واقعی

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

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

بازاسکن و تأیید رفع

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

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

یک پایلوت با دارایی‌های نماینده

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

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

TRACEABLE KNOWLEDGE

منابع و مطالعهٔ بیشتر

01
Greenbone Community Edition — official projecthttps://www.greenbone.net/en/community-edition/
02
Greenbone Community Edition — official downloadhttps://community.greenbone.net/

آخرین بررسی تحریریه:

IROSG / EDITORIAL

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

سیاست تألیف و حقوق تصاویر ↗