سناریوهای حمله و ریسکهای عملیاتی در نسخههای 6 و 7 و 8 VMware
آیا ESXi بدون اینترنت امن است؟
بسیاری از سازمانها هنوز از VMware vSphere 6 ،7 یا نسخههای اولیه vSphere 8 استفاده میکنند. رایجترین استدلال برای بهتعویقانداختن ارتقا و نصب اصلاحیههای امنیتی نیز این است: «ESXi و vCenter ما به اینترنت متصل نیستند؛ بنابراین در معرض حمله قرار ندارند.»
نبود دسترسی مستقیم به اینترنت ≠ نبود مسیر حمله
این گزاره فقط بخشی از واقعیت را بیان میکند. قطع دسترسی مستقیم ESXi و vCenter به اینترنت، یک کنترل امنیتی ضروری و مفید است؛ اما آسیبپذیری نرمافزار را برطرف نمیکند. در بیشتر مراکز داده، ماشینهای مجازی به اینترنت، شبکه کاربران، Active Directory، سامانههای پشتیبانگیری، تجهیزات ذخیرهسازی یا رایانه مدیران متصلاند. مهاجم میتواند ابتدا یکی از این نقاط را تصاحب کند و سپس از داخل شبکه به سمت زیرساخت مجازیسازی حرکت کند. در برخی آسیبپذیریها نیز مهاجم دارای دسترسی مدیریتی داخل یک VM میتواند از مرز ماشین مجازی عبور کند و به فرایندهای Hypervisor یا خود Host برسد.
بنابراین، پرسش درست این نیست که «آیا ESXi اینترنت دارد؟» پرسش درست این است که:
اگر یکی از ماشینهای مجازی، حسابهای مدیریتی یا سامانههای متصل به شبکه آلوده شود، چه چیزی مانع حرکت مهاجم به سمت vCenter ،ESXi Datastoreها و سایر ماشینهای مجازی خواهد شد؟
این مقاله وضعیت پشتیبانی نسخههای ۶، ۷ و ۸، مهمترین مسیرهای حمله و اقدام ضروری برای هر نسل را بررسی میکند.
راهنمای مطالعه
مطلب مرتبط
منظور از «بهروز نگهداشتن VMware» چیست؟
بهروز نگهداشتن زیرساخت VMware الزاماً به این معنا نیست که هر نسخه Major جدید باید در همان روز انتشار روی محیط عملیاتی نصب شود. نسخههای Major باید پس از بررسی سازگاری سرور، CPU، کارت شبکه، HBA ،Firmware ،Storage، نرمافزار Backup و سایر اجزای وابسته پیادهسازی شوند.
اما از نظر امنیتی، یک محیط قابل دفاع باید دو شرط همزمان داشته باشد:
1. روی یک شاخه نرمافزاری تحت پشتیبانی سازنده قرار داشته باشد.
2. آخرین اصلاحیه امنیتی تأییدشده همان شاخه را نصب کرده باشد.
عبارتهایی مانند «ما VMware 8 داریم» یا «روی Update 3 هستیم» برای ارزیابی امنیتی کافی نیستند. شماره دقیق Update ،Patch و Build اهمیت دارد. ممکن است دو محیط هر دو با عنوان vSphere 8 Update 3 معرفی شوند، اما یکی چندین اصلاحیه امنیتی عقبتر باشد.
تا تاریخ 13 مرداد، جدیدترین نسل عمومی VMware، خانواده VMware Cloud Foundation 9.1 و VMware vSphere Foundation 9.1 است. در شاخه ۸ نیز جدیدترین اصلاحیههای موجود، vCenter Server 8.0 Update 3k با Build 25600417 و ESXi 8.0 Update 3k با Build 25595708 هستند؛ هر دو در ۲۹ ژوئیه ۲۰۲۶ منتشر شدهاند. فهرست رسمی Buildها در پایگاه Broadcom منتشر میشود: نسخهها و Buildهای ESXi/ESX و نسخهها و Buildهای vCenter Server.
وضعیت پشتیبانی نسخههای ۶، ۷ و ۸
| نسل | وضعیت در 13 مرداد 1405 | پیامد امنیتی | اقدام پیشنهادی |
|---|---|---|---|
| vSphere 6.0 | پایان پشتیبانی عمومی از ۱۲ مارس ۲۰۲۰؛ پایان Technical Guidance از ۱۲ مارس ۲۰۲۲ | فاقد اصلاحیههای عادی امنیتی و سازگاری جدید | مهاجرت فوری؛ در صورت امکان به نسل ۹ و حداقل به vSphere 8 U3k |
| vSphere 6.5 و 6.7 | پایان پشتیبانی عمومی از ۱۵ اکتبر ۲۰۲۲ | نبود تضمین برای Patchهای جدید؛ انباشت ریسک و محدودیت سختافزاری و نرمافزاری | مهاجرت فوری؛ ممکن است به ارتقای مرحلهای یا تعویض سختافزار نیاز باشد |
| vSphere 7 | پایان پشتیبانی عمومی از ۲ اکتبر ۲۰۲۵ | از این تاریخ، Patch و Update امنیتی جدید در چرخه عمومی ارائه نمیشود | مهاجرت به یک نسخه تحت پشتیبانی؛ در صورت سازگاری، vSphere 8 U3k یا نسل ۹.۱ |
| vSphere 8 | در دوره پشتیبانی عمومی؛ نصب اصلاحیههای جاری ضروری است | نسخه پایه یا Patchهای قدیمی همچنان در برابر CVEهای مهم آسیبپذیرند | ارتقا به آخرین Patch شاخه ۸ یا برنامهریزی برای نسل ۹.۱ |
Broadcom پایان پشتیبانی عمومی vSphere 6.5 و 6.7 را ۱۵ اکتبر ۲۰۲۲ و پایان پشتیبانی عمومی vSphere 7 را ۲ اکتبر ۲۰۲۵ اعلام کرده و صراحتاً ارتقا به vSphere 8 یا نسخههای بالاتر را توصیه میکند. پایان پشتیبانی عمومی vSphere 6.0 نیز در ۱۲ مارس ۲۰۲۰ بوده است و در دوره Technical Guidance هم ارائه Patch امنیتی جدید تضمین نمیشد.
درباره vSphere 7 نیز Broadcom توضیح داده است که پس از ۲ اکتبر ۲۰۲۵، مشتریان این نسل دیگر Patchها و Updateهای امنیتی جدید دریافت نمیکنند. باقیماندن فایل Patchهای قدیمی در پرتال Self-Service با تولید Patch برای آسیبپذیریهای تازه تفاوت دارد.
چرا قطع دسترسی مستقیم ESXi به اینترنت مانع حمله نمیشود؟
برای بهرهبرداری از یک آسیبپذیری، مهاجم الزاماً نباید از اینترنت مستقیماً به ESXi یا vCenter متصل شود. اصطلاح Network Access در بولتنهای امنیتی به معنی امکان دسترسی شبکهای به سرویس آسیبپذیر است؛ این دسترسی میتواند از اینترنت، شبکه کاربران، VLAN سرورها، یک VPN آلوده یا یک ماشین مجازی تصاحبشده فراهم شود.
یک زنجیره حمله متداول میتواند چنین باشد:
1. مهاجم از طریق یک وبسایت، VPN ،RDP، ایمیل آلوده، حساب سرقتشده یا نرمافزار آسیبپذیر وارد یکی از VMها میشود.
2. روی همان VM سطح دسترسی خود را افزایش میدهد یا اعتبارنامههای مدیریتی را سرقت میکند.
3. شبکه داخلی، DNS ،Active Directory ،Backup Server و مسیرهای دسترسی به vCenter یا ESXi را شناسایی میکند.
4. از یک CVE در vCenter/ESXi، پیکربندی نادرست، حساب مشترک یا مسیر مدیریتی باز استفاده میکند.
5. پس از تصاحب vCenter یا Host، چندین VM ،Snapshot ،Datastore یا نسخه پشتیبان را همزمان خاموش، حذف یا رمزگذاری میکند.
این زنجیره قطعی یا خودکار نیست؛ آلودهشدن یک VM لزوماً به معنی شکستن Hypervisor نیست. مهاجم باید شرایط CVE مربوط، سطح دسترسی لازم و مسیر شبکهای مناسب را داشته باشد. بااینحال، VM آلوده همان نقطه ورود اولیهای است که فرض «Hypervisor ما اینترنت ندارد» آن را نادیده میگیرد.
سناریوهای حمله به VMware vSphere 6
سناریوی اول: اجرای کد روی ESXi از طریق OpenSLP و سپس باجافزار
در CVE-2021-21974، سرویس OpenSLP در ESXi دارای Heap Overflow بود. مهاجمی که در همان Segment شبکهای قرار میگرفت و به پورت 427 دسترسی داشت، میتوانست به اجرای کد از راه دور برسد. این CVE روی ESXi 6.5 و 6.7 و نسخههای اولیه 7 اثر داشت و امتیاز CVSS آن 8.8 بود. VMware علاوه بر نصب Patch، غیرفعالکردن OpenSLP در صورت عدم استفاده را توصیه کرد. بولتن رسمی VMSA-2021-0002.
سناریوی عملی به این صورت است: یک سرور یا VM در شبکه سازمان تصاحب میشود؛ بهدلیل تفکیک ضعیف شبکه، مهاجم به رابط مدیریت ESXi و پورت 427 دسترسی پیدا میکند؛ سپس از OpenSLP برای اجرای کد روی Host بهره میبرد و فایلهای ماشینهای مجازی را هدف قرار میدهد.
کارزار گسترده ESXiArgs نشان داد که Hypervisorها مستقیماً هدف باجافزار قرار میگیرند. CISA و FBI برای بازیابی ماشینهای مجازی آسیبدیده از ESXiArgs راهنمای اختصاصی منتشر کردند و بر ارتقای ESXi، غیرفعالکردن SLP در صورت عدم نیاز و جلوگیری از دسترسی عمومی به رابطهای مدیریتی تأکید کردند.
نکته مهم این است که سازمان ممکن است تصور کند ESXi «اینترنت ندارد»، اما یک Rule قدیمی فایروال، NAT فراموششده، VPN پیمانکار یا دسترسی یک VM به شبکه مدیریت میتواند شرط دسترسی را فراهم کند.
سناریوی دوم: تصاحب vCenter از طریق پورت 443
در CVE-2021-21972، یکی از Pluginهای پیشفرض vSphere Client در vCenter دارای آسیبپذیری اجرای کد از راه دور با امتیاز 9.8 بود. مهاجم دارای دسترسی شبکهای به پورت 443 میتوانست بدون نیاز به حساب معتبر، فرمانهایی با سطح دسترسی بالا روی سیستمعامل vCenter اجرا کند. Endpoint آسیبپذیر در نصب پیشفرض وجود داشت و لازم نبود vRealize Operations واقعاً نصب شده باشد. این CVE روی vCenter 6.5 6.7 و 7 اثر گذاشت.
در این سناریو، مهاجم ابتدا یک VM یا رایانه مدیریتی را تصاحب میکند. اگر از آن نقطه به رابط HTTPS vCenter دسترسی وجود داشته باشد، اینترنتنداشتن خود vCenter مانع حمله نیست. تصاحب vCenter میتواند دید و کنترل گستردهای بر Inventory، حسابها، Clusterها و ماشینهای مجازی ایجاد کند.
ریسک ویژه نسخه ۶: پایان تولید Patch
حتی اگر تمام Patchهای تاریخی نسخه ۶ نصب شده باشند، این نسل دیگر مقصد قابل دفاعی برای بهرهبرداری بلندمدت نیست. پایان پشتیبانی به این معنی نیست که همه آسیبپذیریهای نسخه قدیمی شناخته شدهاند؛ بلکه یعنی برای ضعفهای تازهکشفشده، Patch عادی و تضمینشدهای تولید نمیشود. VMware در موارد بسیار خاص، مانند CVE-2023-34048، بهدلیل شدت 9.8 و نبود Workaround حتی برای بعضی نسخههای پایانعمر vCenter 6.5 و 6.7 Patch استثنایی منتشر کرد. این استثنا نباید بهعنوان تعهد سازنده برای Patchهای آینده تفسیر شود. بولتن VMSA-2023-0023.
نتیجه برای نسخه ۶: اعمال آخرین Patch تاریخی فقط یک اقدام موقت برای کاهش ریسک حین پروژه مهاجرت است؛ راهکار نهایی، خروج از این نسل است.
سناریوهای حمله به VMware vSphere 7
سناریوی سوم: اجرای کد از راه دور روی vCenter؛ CVE-2023-34048
CVE-2023-34048 یک Out-of-Bounds Write در پیادهسازی DCERPC در vCenter بود. مهاجم فقط با دسترسی شبکهای به vCenter میتوانست بسته ویژهای ارسال و احتمالاً کد دلخواه اجرا کند. امتیاز CVSS این آسیبپذیری 9.8 بود، Workaround قابل اتکایی نداشت و VMware بعداً بهرهبرداری واقعی از آن را تأیید کرد. این CVE نسخههای ۷ و ۸ و برخی نسخههای قدیمیتر را تحت تأثیر قرار داد.
در یک محیط vSphere 7 وصلهنشده، مهاجم پس از نفوذ به هر نقطهای که به شبکه مدیریت Route دارد، میتواند vCenter را هدف بگیرد. لازم نیست vCenter روی اینترنت Publish شده باشد. کافی است مرز میان شبکه Workload و Management بهدرستی اعمال نشده باشد یا سیستم مدیر شبکه آلوده شده باشد.
سناریوی چهارم: تصاحب ESXi از مسیر Active Directory؛ CVE-2024-37085
در CVE-2024-37085 ،ESXi متصل به Active Directory در شرایط مشخصی امکان دورزدن احراز هویت را فراهم میکرد. مهاجمی که مجوز کافی در AD داشت میتوانست گروه مدیریتی حذفشده با نام پیشفرض ESX Admins را دوباره ایجاد کند و به Host دسترسی مدیریتی کامل بگیرد. امتیاز این CVE فقط 6.8 بود، اما در حملات واقعی باجافزاری استفاده شد و CISA آن را در فهرست آسیبپذیریهای مورد بهرهبرداری قرار داد.
برای ESXi 8 اصلاحیه ارائه شد، اما در ماتریس رسمی برای ESXi 7 عبارت No Patch Planned درج شده و Workaround توصیه شده است. این نمونه نشان میدهد عدد CVSS بهتنهایی معیار مناسبی برای اولویتبندی نیست؛ امکان استفاده در عملیات باجافزاری میتواند یک CVE با امتیاز متوسط را به ریسک بحرانی کسبوکار تبدیل کند. بولتن رسمی VMSA-2024-0013.
سناریوی پنجم: عبور از VM به Host؛ زنجیره CVEهای سال ۲۰۲۵
سه آسیبپذیری CVE-2025-22224 ،CVE-2025-22225 و CVE-2025-22226 یک سناریوی مهم برای پاسخ به ادعای «ESXi اینترنت ندارد» ایجاد میکنند:
- CVE-2025-22224 با امتیاز 9.3، به مهاجم دارای دسترسی مدیریتی داخل VM امکان میداد در فرایند VMX میزبان کد اجرا کند.
- CVE-2025-22225 با امتیاز 8.2، امکان Arbitrary Write در Kernel و خروج از Sandbox را ایجاد میکرد.
- CVE-2025-22226 با امتیاز 7.1، میتوانست اطلاعات حافظه فرایند VMX را افشا کند.
Broadcom اعلام کرد شواهدی از بهرهبرداری واقعی هر سه CVE وجود دارد. این آسیبپذیریها ESXi 7 و 8 را تحت تأثیر قرار دادند. برای شاخه 7، نسخه اصلاحشده اولیه ESXi 7.0 U3s و برای شاخه 8، نسخههای 8.0 U3d و 8.0 U2d بودند. بولتن رسمی VMSA-2025-0004.
این CVEها نشان نمیدهند که هر بدافزار سادهای در هر VM میتواند فوراً ESXi را تصاحب کند. مهاجم باید دسترسی و شرایط فنی لازم را به دست آورد. اما نشان میدهند که مرز میان Guest و Host مطلق نیست و Patch نشدن Hypervisor میتواند یک آلودگی داخل VM را به رخداد کل زیرساخت تبدیل کند.
ریسک ویژه نسخه ۷: آخرین Patch تاریخی، محافظ آینده نیست
ESXi 7 در آخرین شاخه خود تا 7.0 Update 3w و vCenter 7 تا 7.0 Update 3w اصلاح شدهاند؛ بااینحال، پشتیبانی عمومی این نسل در ۲ اکتبر ۲۰۲۵ پایان یافته است. بنابراین حتی اگر محیط روی آخرین Build موجود شاخه ۷ باشد، برای آسیبپذیریهایی که پس از پایان پشتیبانی کشف میشوند، تولید اصلاحیه جدید تضمین نمیشود.
نتیجه برای نسخه ۷: نصب آخرین Patch موجود برای کاهش ریسک کوتاهمدت ضروری است، اما جایگزین پروژه مهاجرت نیست.
سناریوهای حمله به VMware vSphere 8
نسخه ۸ هنوز تحت پشتیبانی است، اما «نسخه ۸ بودن» بهتنهایی نشانه امن بودن نیست. چند نمونه جدید نشان میدهد حتی نسخههای پایه و Patchهای قدیمی این نسل باید سریعاً اصلاح شوند.
سناریوی ششم: دورزدن احراز هویت و اجرای کد روی vCenter؛ CVEهای ژوئیه ۲۰۲۶
در ۲۹ ژوئیه ۲۰۲۶، Broadcom بولتن بحرانی VMSA-2026-0006 را منتشر کرد:
- CVE-2026-59309، آسیبپذیری دورزدن احراز هویت در VMware Directory Service با امتیاز 9.8.
- CVE-2026-59310، آسیبپذیری Directory Traversal در Syslog Server با امکان اجرای کد دلخواه و امتیاز 9.8.
هر دو CVE از طریق دسترسی شبکهای به vCenter قابل بهرهبرداریاند، هیچ Workaround رسمی ندارند و علاوه بر vCenter 8، نسخههای 9.0 و 9.1 را نیز تحت تأثیر قرار میدهند. نسخه اصلاحشده شاخه ۸، vCenter 8.0 U3k است. بولتن رسمی VMSA-2026-0006.1.
این مورد یک درس مهم دارد: حتی مهاجرت به آخرین نسل Major نیز پایان Patch Management نیست. برای مثال، نسخه پایه vCenter 9.1 هم بدون اصلاحیههای بعدی در برابر این CVEها آسیبپذیر بود.
سناریوی هفتم: اجرای کد روی Host از طریق آداپتور VMXNET3
CVE-2026-47876 یک Out-of-Bounds Write در آداپتور شبکه مجازی VMXNET3 است. مهاجم دارای دسترسی مدیریتی محلی روی VM مجهز به VMXNET3 میتواند از این ضعف برای اجرای کد روی Host استفاده کند. امتیاز CVSS آن 9.3 است، Workaround رسمی ندارد و نسخههای ESX/ESXi 8، 9.0 و 9.1 را تحت تأثیر قرار داده است. برای شاخه ۸، اصلاحیه در ESXi 8.0 U3k ارائه شده است.
در این سناریو، اتصال اینترنتی ESXi موضوع اصلی نیست؛ مهاجم از یک VM آلوده یا تصاحبشده و یک مؤلفه مجازی مشترک با Hypervisor استفاده میکند.
سناریوی هشتم: RCE روی vCenter و Patch اولیه ناکامل
CVE-2024-38812 یک Heap Overflow در DCERPC با امتیاز 9.8 بود که امکان اجرای کد از راه دور را فراهم میکرد. CVE-2024-38813 نیز امکان افزایش سطح دسترسی تا root را ایجاد میکرد. Broadcom بهرهبرداری واقعی از هر دو CVE را تأیید کرد.
نکته مهمتر اینکه Patchهای اولیه سپتامبر ۲۰۲۴، CVE-2024-38812 را بهطور کامل برطرف نکردند و Broadcom ناچار شد Patchهای تکمیلی منتشر کند.
این رخداد نشان میدهد فرایند مدیریت آسیبپذیری فقط «یک بار نصب Patch» نیست؛ سازمان باید بولتنهای اصلاحشده، Change Log و نسخه نهایی Fixed Version را نیز دنبال کند. بولتن رسمی VMSA-2024-0019.
نتیجه برای نسخه ۸:
اگر vCenter و ESXi روی Update یا Build قدیمی قرار دارند، سازمان همچنان در معرض سناریوهای جدی RCE ،Authentication Bypass و VM Escape است. حداقل Baseline در تاریخ این مقاله، vCenter 8.0 U3k و ESXi 8.0 U3k است؛ البته هر بولتن جدید میتواند این Baseline را تغییر دهد.
از یک VM آلوده تا توقف کل کسبوکار
ارزش Hypervisor برای مهاجم با یک سرور عادی متفاوت است. تصاحب یک VM معمولاً یک Workload را تحت تأثیر قرار میدهد؛ اما تصاحب vCenter ،ESXi یا حسابهای مدیریتی میتواند دهها یا صدها Workload را همزمان در اختیار مهاجم قرار دهد.
پیامدهای محتمل عبارتاند از:
- خاموشکردن گسترده ماشینهای مجازی
- حذف Snapshotها یا تغییر تنظیمات VMها
- رمزگذاری فایلهای VMDK و VMFS
- دسترسی به اطلاعات چند سامانه از یک نقطه مرکزی
- سرقت Credentialها و Certificateهای مدیریتی
- اختلال همزمان در سرویسهای سازمانی، پایگاهدادهها و سامانههای احراز هویت
- هدفگرفتن Backup Server یا Repository و کاهش امکان بازیابی
- استفاده از Host برای ماندگاری و پنهانشدن از ابزارهای امنیتی داخل Guest OS
CISA در سال ۲۰۲۲ درباره بدافزارهای VirtualPITA ،VirtualPIE و VirtualGATE هشدار داد که محیطهای VMware vSphere را هدف میگرفتند و امکان دسترسی پایدار به Hypervisor یا Guestها را فراهم میکردند. این نمونهها نشان میدهند مهاجمان حرفهای صرفاً به سیستمعامل داخل VM بسنده نمیکنند.
مقصد مناسب برای سازمانهای دارای نسخه ۶ یا ۷ چیست؟
در 13 مرداد 1405، نسخه ۸ دیگر «آخرین نسل» VMware نیست؛ آخرین نسل، خانواده ۹.۱ است. بااینحال، برای بسیاری از سازمانهای دارای سختافزار قدیمی، نرمافزار Backup یا Storage وابسته، مهاجرت مستقیم به نسل ۹ ممکن است فوراً امکانپذیر نباشد.
تصمیم پیشنهادی به این صورت است:
| وضعیت سازمان | مقصد پیشنهادی |
|---|---|
| سختافزار و تمام اجزای جانبی با نسل ۹.۱ سازگار و مجوز مناسب وجود دارد | برنامهریزی برای VCF/VVF 9.1 با آخرین Patch جاری |
| مهاجرت به نسل ۹.۱ فعلاً به علت HCL، مجوز یا وابستگیها ممکن نیست | حداقل مهاجرت به vSphere 8 Update 3k بهعنوان مقصد میانی تحت پشتیبانی |
| سختافزار فقط نسخه ۶ یا ۷ را پشتیبانی میکند | تعویض یا نوسازی سختافزار بخشی از پروژه امنیت است؛ باقیماندن دائمی روی نسخه منقضی، راهکار قابلدفاعی نیست |
| امکان ارتقای In-place وجود ندارد | ساخت Cluster جدید و مهاجرت تدریجی Workloadها، پس از بررسی سازگاری و روش انتقال |
Broadcom در راهنمای رسمی خود نیز برای حفظ پشتیبانی، ارتقا از نسخههای 6.5، 6.7 و 7 به vSphere 8 یا بالاتر را توصیه میکند. مسیر دقیق ارتقا باید با Broadcom Compatibility Guide ،Interoperability Matrix و Upgrade Path بررسی شود. نسخه مبدأ، مدل سرور، CPU ،Firmware، درایور NIC/HBA ،Storage ،vSAN On-Disk Format ،NSX ،Backup و سایر افزونهها ممکن است ارتقای مرحلهای یا مهاجرت به Cluster جدید را ضروری کنند.
نسخه ۸ تا اکتبر ۲۰۲۷ در دوره پشتیبانی عمومی قرار دارد و میتواند برای برخی سازمانها مقصد میانی معقولی باشد؛ اما این انتخاب باید همراه با برنامه خروج پیش از پایان پشتیبانی باشد. Broadcom نیز در مطالب مهاجرتی، vSphere 8 را بهعنوان مسیر ارتقای سادهتر و VCF 9 را بهعنوان مقصد جدیدتر معرفی کرده است.
برنامه اجرایی پیشنهادی برای کاهش ریسک
۱. موجودی دقیق تهیه کنید.
برای هر vCenter ،ESXi Host و Cluster موارد زیر ثبت شود:
- نسخه، Update ،Patch و Build دقیق
- مدل سرور، CPU ،BIOS و Firmware
- درایور و Firmware کارتهای NIC و HBA
- نوع Storage ،Multipathing و Pluginهای Vendor
- نسخه VMware Tools و Virtual Hardware ماشینها
- نسخه نرمافزارهای Backup ،Monitoring ،Replication و Disaster Recovery
- وضعیت اتصال ESXi به Active Directory
- سرویسهای فعال مانند SSH ،ESXi Shell و SLP
- مسیرهای شبکهای منتهی به vCenter و رابط مدیریت ESXi
۲. محیطهای منقضی را بهعنوان ریسک ثبت کنید.
وجود نسخه ۶ یا ۷ نباید صرفاً یک «بدهی فنی» تلقی شود؛ این وضعیت یک ریسک امنیتی و تداوم کسبوکار است. ریسک باید دارای مالک، بودجه، مهلت اصلاح و تصمیم رسمی مدیریت باشد. پذیرش ریسک بدون تاریخ خروج، عملاً به معنی پذیرش نامحدود آسیبپذیریهای آینده است.
۳. Patch و Upgrade را از یکدیگر جدا کنید.
پروژه مهاجرت از نسخه ۶ یا ۷ ممکن است چند ماه طول بکشد. این زمان نباید بهانهای برای نصبنکردن آخرین Patch موجود نسخه فعلی باشد. ابتدا محیط مبدأ تا حد ممکن به آخرین Build تاریخی و تنظیمات سختسازی رسانده شود؛ سپس پروژه Upgrade یا Migration اجرا شود. Patch موقت، جایگزین مهاجرت نیست و مهاجرت آتی نیز جایگزین Patch فوری نیست.
۴. سازگاری را پیش از تغییر بررسی کنید.
پیش از ارتقا باید سازگاری Server ،CPU ،I/O Device ،Storage ،Firmware ،Backup ،NSX و سایر محصولات بررسی شود. استفاده از ISO یا Add-on تأییدشده سازنده سرور، درایورها و Firmware سازگار و رعایت ترتیب ارتقای اجزا اهمیت دارد. برای vSphere 8 نیز Broadcom ترتیب بهروزرسانی محصولات سازگار را مستند کرده است.
۵. پیش از Patch، بازیابی را اثبات کنید.
تنها داشتن Backup کافی نیست. پیش از تغییرات مهم باید موارد زیر آزموده شوند:
- Backup فایلمحور و قابل بازیابی vCenter
- Backup تنظیمات Hostها و تجهیزات وابسته
- سلامت Repository و جداسازی Credentialهای Backup
- وجود یک نسخه Immutable یا Offline
- اجرای آزمایشی Restore برای Workloadهای حیاتی
- برنامه Rollback یا Roll-forward در صورت شکست ارتقا
Snapshot بهتنهایی Backup محسوب نمیشود و اگر مهاجم به vCenter یا Host دسترسی مدیریتی پیدا کند، Snapshotها نیز ممکن است حذف شوند.
۶. شبکه مدیریت را واقعاً جدا کنید.
جداکردن Management Network فقط ایجاد یک VLAN با نام متفاوت نیست. باید ACL و Firewall بهگونهای تنظیم شوند که فقط Jump Serverها و ایستگاههای مدیریتی مشخص بتوانند به vCenter و ESXi دسترسی داشته باشند. VMهای عمومی، شبکه کاربران، Wi-Fi ،VPNهای عمومی و سرورهای غیرمدیریتی نباید Route آزاد به رابطهای مدیریت داشته باشند.
دسترسی مستقیم اینترنتی به vCenter و ESXi باید حذف شود. پورتهایی مانند 443، 902 و 427 نباید بدون نیاز و کنترل در دسترس شبکههای غیرمدیریتی باشند. وجود هر NAT ،Port Forward یا Rule قدیمی نیز باید بازبینی شود.
۷. سطح مدیریت Host را کاهش دهید.
- SSH و ESXi Shell در حالت عادی غیرفعال باشند؛ Broadcom نیز غیرفعالبودن SSH در محیط عملیاتی را توصیه میکند.
- Lockdown Mode متناسب با معماری و فرایند Break-glass فعال شود.
- حسابهای مشترک حذف و دسترسیها بر اساس حداقل سطح لازم تعریف شوند.
- حسابهای اضطراری محدود، ثبتشده و تحت نظارت باشند.
- ورودهای مدیریتی و تغییرات حساس به سامانه مرکزی ثبت رویداد ارسال شوند.
- راهنمای سختسازی رسمی vSphere برای ESXi و vCenter اجرا و بهصورت دورهای ممیزی شود.
۸. Active Directory و حسابهای مدیریتی را بازبینی کنید.
اگر ESXi یا vCenter به AD متصلاند، گروهها و مجوزهای مدیریتی، حسابهای Service ،Naming و Membership آنها بازبینی شود. رویدادهای ایجاد مجدد گروههای حساس، تغییر عضویت و اعطای Role باید هشدار ایجاد کنند. Credentialهای مدیریت مجازیسازی نباید روی ماشینهای عمومی یا سامانههایی با ریسک بالا استفاده شوند.
۹. برای CVEهای بحرانی SLA مشخص داشته باشید.
یک سیاست پیشنهادی عملی میتواند چنین باشد:
| وضعیت آسیبپذیری | مهلت پیشنهادی ارزیابی و اصلاح |
|---|---|
| بهرهبرداری فعال، بدون Workaround یا امکان RCE/Auth Bypass | ارزیابی فوری و اصلاح در ۲۴ تا ۷۲ ساعت |
| Critical، بدون گزارش بهرهبرداری فعال | حداکثر ۷ روز |
| Important، با مسیر حمله مرتبط با معماری سازمان | حداکثر ۱۴ تا ۳۰ روز |
| نسخه پایانپشتیبانی | برنامه خروج مصوب؛ ترجیحاً حداکثر ۹۰ روز، متناسب با پیچیدگی محیط |
این زمانها پیشنهاد اجراییاند و باید با حساسیت سرویس، امکان HA/vMotion، الزامات قانونی و فرایند Change Management سازمان تنظیم شوند. «پنجره نگهداری نداریم» نباید به تعویق نامحدود یک CVE با بهرهبرداری فعال منجر شود.
۱۰. پس از Patch ،Build را راستیآزمایی کنید.
موفقشدن Task در vCenter بهتنهایی کافی نیست. شماره Build عملیاتی هر Host و vCenter باید با Fixed Version بولتن تطبیق داده شود. برای نمونه، در ESXi 8.0 U3k ممکن است Installer یا Early Boot شماره Build قبلی را نمایش دهد؛ Broadcom توضیح داده است که معیار نهایی، Build گزارششده پس از Boot کامل در DCUI ،vSphere Client یا فرمان vmware -v است که باید 25595708 باشد.
چکلیست سریع تصمیمگیری
اگر پاسخ هر یک از پرسشهای زیر «بله» یا «نمیدانم» است، محیط به بررسی فوری نیاز دارد:
- آیا هنوز ESXi یا vCenter 6.x یا 7.x در محیط عملیاتی وجود دارد؟
- آیا فقط نام نسخه را میدانید و Build دقیق را ثبت نکردهاید؟
- آیا vCenter یا ESXi از شبکه VMها یا کاربران قابل دسترسی است؟
- آیا یک VM متصل به اینترنت میتواند به VLAN مدیریت Route داشته باشد؟
- آیا SSH یا ESXi Shell بهطور دائم فعال است؟
- آیا ESXi به Active Directory متصل است، اما گروههای مدیریتی آن مانیتور نمیشوند؟
- آیا Backup Server با همان Credentialهای مدیریت مجازیسازی اداره میشود؟
- آیا Restore واقعی ماشینهای حیاتی در ماههای اخیر آزمایش نشده است؟
- آیا Patchهای VMware فقط در زمان بروز خرابی نصب میشوند؟
- آیا برای CVEهای بحرانی هیچ SLA و مالک مشخصی وجود ندارد؟
جمعبندی
اینترنتنداشتن ESXi و vCenter یک اقدام درست است، اما فقط مسیر مستقیم حمله را محدود میکند. مهاجم میتواند از یک VM متصل به اینترنت، حساب Active Directory، رایانه مدیر، VPN ،Backup Server یا هر سامانه داخلی آلوده به زیرساخت مجازیسازی نزدیک شود. آسیبپذیریهای واقعی مانند CVE-2025-22224 و CVE-2026-47876 نیز نشان دادهاند که در شرایط مشخص، مسیر حمله میتواند از داخل VM به سمت Host امتداد یابد.
نسخههای VMware vSphere 6 و 7 دیگر تحت پشتیبانی عمومی نیستند. نصب آخرین Patch تاریخی آنها برای کاهش موقت ریسک لازم است، اما آینده امنیتی این محیطها را تضمین نمیکند. سازمانهای دارای این نسخهها باید پروژه خروج را آغاز کنند: ترجیحاً به نسل ۹.۱ و اگر محدودیت سازگاری یا مجوز وجود دارد، حداقل به vSphere 8 Update 3k بهعنوان مقصد میانی تحت پشتیبانی.
در نهایت باید میان دو مفهوم تفاوت گذاشت:
قطع اینترنت، یکی از مسیرهای ورود را میبندد؛ نصب اصلاحیه، خود آسیبپذیری را میبندد. هیچکدام جایگزین دیگری نیست.