F5 BIG-IP LTM معمولاً در مسیر سرویسهای مهم قرار دارد؛ یعنی یک تصمیم اشتباه در Patch یا کاهش ریسک میتواند روی وبسایت، API، پنل مشتریان یا سرویس داخلی اثر مستقیم بگذارد. از طرف دیگر، رها کردن CVEهای BIG-IP هم خطرناک است، چون بعضی آسیبپذیریها به مدیریت دستگاه، iControl REST، TMUI، SSL Profile یا پردازش ترافیک مربوط میشوند. پس مدیریت CVE در F5 باید دقیق، مرحلهای و قابل تست باشد.
این چکلیست برای زمانی است که تیم شبکه یا امنیت با یک CVE جدید در BIG-IP LTM روبهرو میشود و باید تصمیم بگیرد: آیا ما آسیبپذیریم؟ ریسک چقدر است؟ آیا کنترل موقت داریم؟ Patch را چه زمانی و با چه تستی اجرا کنیم؟
۱. نسخه BIG-IP و سطح دسترسی را مشخص کنید
اول باید بدانید نسخه BIG-IP در بازه آسیبپذیر هست یا نه. بعد باید سطح دسترسی قابلیت آسیبپذیر را بررسی کنید. آسیبپذیری در Management Plane وقتی خطرناکتر میشود که پنل مدیریتی از شبکههای عمومی یا VLANهای غیرادمین دیده شود. آسیبپذیری در Data Plane هم باید با نوع Virtual Server، Profile و ترافیک واقعی سنجیده شود.
- نسخه دقیق BIG-IP، Hotfix و ماژولهای فعال را ثبت کنید.
- دسترسی به TMUI، SSH و iControl REST را از نظر Source محدود بررسی کنید.
- Virtual Serverهای اینترنتی را از سرویسهای داخلی جداگانه ارزیابی کنید.
- اگر ASM/WAF یا APM هم فعال است، اثر CVE را فقط به LTM محدود فرض نکنید.
۲. ریسک را بر اساس نقش سرویس اولویتبندی کنید
همه BIG-IPها ارزش یکسان ندارند. دستگاهی که پشت آن سرویس عمومی، پرداخت، احراز هویت یا API حساس قرار دارد، باید زودتر بررسی شود. در مقابل، محیط تست یا سرویس داخلی محدود ممکن است با کنترل موقت تا پنجره تغییر بعدی مدیریت شود. اولویت درست از ترکیب CVSS، سطح دسترسی، نوع سرویس و امکان Exploit ساخته میشود.
| محور | بررسی لازم | تصمیم اجرایی |
|---|---|---|
| Management | TMUI یا iControl REST از کجا قابل دسترسی است؟ | محدودسازی فوری Source |
| Data Plane | کدام Virtual Server و Profile درگیر است؟ | تست سرویس و کنترل موقت |
| HA | Active/Standby یا Active/Active است؟ | برنامه Patch مرحلهای |
| سرویس | اثر قطعی روی چه کاربران یا سامانههایی است؟ | انتخاب پنجره تغییر |
۳. کنترل موقت را قبل از تغییر اعمال کنید
اگر Patch فوری ممکن نیست، باید سطح حمله را کم کنید. محدود کردن مدیریت به شبکه ادمین، بستن دسترسیهای غیرضروری، بررسی لاگ ورود، و کنترل Profileهای پرریسک میتواند تا زمان Patch ریسک را پایین بیاورد. این کنترلها باید مستند باشند تا بعد از Patch هم معلوم باشد چه چیزی تغییر کرده است.
- Management Interface را فقط از شبکه ادمین قابل دسترسی کنید.
- دسترسی iControl REST و TMUI را به Sourceهای مشخص محدود کنید.
- لاگ ورود و تغییرات مدیریتی را بررسی و نگهداری کنید.
- برای Virtual Serverهای حساس، رفتار SSL، HTTP و Persistence را قبل از Patch ثبت کنید.
۴. Patch را با تست LTM ببندید
در F5، موفق بودن Patch فقط با بالا آمدن دستگاه تمام نمیشود. باید Virtual Server، Pool Member، Health Monitor، SSL Profile، Persistence، SNAT، Route و لاگها پس از تغییر بررسی شوند. در HA، بهتر است سناریوی Failover هم کنترل شود تا مطمئن شوید سرویس در وضعیت واقعی پایدار میماند.
- از UCS Backup و تنظیمات کلیدی قبل از تغییر خروجی بگیرید.
- مسیر ارتقا و نسخه هدف را با Release Notes تطبیق دهید.
- تست قبل و بعد برای Virtual Serverهای حیاتی تعریف کنید.
- پس از Patch، وضعیت Sync، Failover، Pool و Monitor را بررسی کنید.
۵. گزارش CVE را قابل استفاده نگه دارید
برای هر CVE، خروجی باید شامل نسخه آسیبپذیر، تجهیزات درگیر، کنترل موقت، زمان Patch، نتیجه تست و ریسک باقیمانده باشد. این گزارش فقط برای ممیزی نیست؛ در رخداد بعدی کمک میکند سریعتر بفهمید کدام سرویسها حساستر هستند و کدام مسیر تغییر قبلاً جواب داده است.
برای طراحی و اجرای مطمئنتر، صفحه F5 Load Balancer و راهنمای Persistence در F5 مکمل این موضوع هستند. اگر بحث WAF و False Positive هم مطرح است، مقاله تنظیم False Positive در F5 ASM مسیر بعدی بررسی است.
