آسیب‌پذیری Cisco Nexus در NX-OS؛ مدیران شبکه چه کار کنند؟

آسیب‌پذیری Cisco Nexus در به‌روزرسانی امنیتی اکتبر ۲۰۲۶ به مجموعه‌ای از نقص‌های بحرانی در NX-OS اشاره دارد که در شرایط مشخص می‌توانند به اجرای کد با دسترسی root یا ازکارافتادن سرویس منجر شوند. اقدام درست این نیست که بدون بررسی همه قابلیت‌ها را خاموش کنیم؛ ابتدا مدل و نسخه NX-OS، حالت بهره‌برداری و فعال‌بودن NX-API، NGOAM و MPLS OAM را ثبت کنید، سپس نسخه اصلاح‌شده مناسب را از ابزار رسمی Cisco Software Checker پیدا کرده و ارتقا را در پنجره نگهداری کنترل‌شده انجام دهید.

آسیب‌پذیری Cisco Nexus دقیقاً چیست؟

گزارش BleepingComputer در ۸ اکتبر ۲۰۲۶ پنج آسیب‌پذیری بحرانی را جمع‌بندی کرده است که Cisco برای سوئیچ‌های Nexus 3000 و Nexus 9000 در حالت مستقل NX-OS منتشر کرده است. این نقص‌های Cisco Nexus به ورودی‌های نامعتبر در قابلیت‌های مدیریتی و پایش شبکه مربوط‌اند و مهاجم راه دور، در صورت فراهم‌بودن پیش‌شرط هر نقص، ممکن است بتواند کد دلخواه را با سطح دسترسی root اجرا کند یا پردازش آسیب‌پذیر را از کار بیندازد.

مهم‌ترین شناسه‌های مطرح‌شده شامل CVE-2026-76471 برای NX-API، شناسه CVE-2026-76465 برای MPLS OAM و سه شناسه CVE-2026-76485، CVE-2026-76486 و CVE-2026-76501 برای NGOAM هستند. امتیاز پایه CVSS اعلام‌شده برای موارد بحرانی ۹.۸ است. این عدد شدت بالقوه را نشان می‌دهد، اما ریسک واقعی هر سازمان به مدل دستگاه، نسخه نرم‌افزار، فعال‌بودن قابلیت مربوط، میزان دسترسی مدیریتی و کنترل‌های پیرامونی بستگی دارد.

کدام سوئیچ‌ها و قابلیت‌ها باید بررسی شوند؟

طبق هشدارهای رسمی Cisco، دامنه اثر هر CVE یکسان نیست. برای مجموعه پنج نقصی که خبر اصلی درباره آن‌هاست، تمرکز روی Nexus 3000 و Nexus 9000 در حالت standalone NX-OS است. بهره‌برداری از هر مورد به فعال‌بودن قابلیت مرتبط وابسته است:

• NX-API: رابط برنامه‌نویسی NX-OS که برای مدیریت و اتوماسیون استفاده می‌شود. نقص CVE-2026-76471 به همین سطح حمله مربوط است.
• NGOAM: قابلیت Next Generation OAM برای عملیات، مدیریت و نگهداری شبکه. سه CVE بحرانی به پردازش ورودی در این بخش مرتبط‌اند.
• MPLS OAM: قابلیت پایش مسیرهای MPLS که به‌طور پیش‌فرض فعال نیست؛ CVE-2026-76465 تنها در صورت فعال‌بودن این ویژگی قابل بهره‌برداری است.
• SRv6: در یکی از مسیرهای مرتبط با CVE-2026-76501 نقش دارد و فقط روی برخی مدل‌های Nexus 9000 پشتیبانی می‌شود.

بر اساس گزارش منبع، در خانواده Cisco Nexus مدل‌های Nexus 7000 و Nexus 9000 در حالت ACI از این پنج آسیب‌پذیری مشخص متأثر نیستند. بااین‌حال Cisco هم‌زمان یک بسته گسترده‌تر سخت‌سازی NX-OS منتشر کرده است؛ بنابراین نتیجه «این پنج مورد شامل دستگاه من نیست» به معنی بی‌نیازی کامل از بررسی همه هشدارهای اکتبر نیست.

چرا اجرای کد با دسترسی root خطرناک است؟

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

در تجهیزات Cisco Nexus، حتی اگر اجرای کد کامل ممکن نشود، ایجاد DoS و reload اجباری برای سوئیچ هسته می‌تواند سرویس‌های زیادی را هم‌زمان متوقف کند. در محیط‌های دارای vPC، مسیرهای افزونه و کنترل تغییر مناسب، اثر کاهش می‌یابد؛ اما افزونگی نباید جایگزین وصله امنیتی شود، چون پیکربندی و نسخه مشابه ممکن است هر دو عضو را در معرض یک نقص مشترک قرار دهد.

چگونه در پنج مرحله وضعیت شبکه را ارزیابی کنیم؟

۱. موجودی دقیق مدل و نسخه بسازید

فهرستی از مدل، شماره سریال، نسخه NX-OS، نقش دستگاه، حالت standalone یا ACI و تاریخ آخرین ارتقا تهیه کنید. اتکا به نام‌گذاری رک یا فایل قدیمی CMDB کافی نیست؛ خروجی واقعی دستگاه را با مستندات دارایی تطبیق دهید. اگر قرار است زیرساخت توسعه پیدا کند، هنگام مقایسه سوئیچ‌های سیسکو علاوه بر تعداد پورت و سرعت، وضعیت پشتیبانی نرم‌افزاری و دسترسی به نسخه‌های اصلاح‌شده را هم معیار خرید قرار دهید.

۲. سطح حمله را با وضعیت قابلیت‌ها تطبیق دهید

فقط وجود نام یک مدل در فهرست محصولات آسیب‌پذیر برای نتیجه‌گیری کافی نیست. بررسی کنید NX-API، NGOAM، MPLS OAM و SRv6 واقعاً فعال هستند یا خیر و رابط مدیریتی از چه شبکه‌هایی در دسترس است. قابلیت بلااستفاده نباید بدون دلیل عملیاتی فعال بماند. هر تغییر باید ابتدا در محیط آزمایشی یا روی عضو غیرفعال زوج افزونه آزموده شود.

۳. نسخه اصلاح‌شده را از منبع رسمی تعیین کنید

جدول نسخه‌های ثابت میان خانواده‌های Nexus متفاوت است و ممکن است Cisco آن را بعداً به‌روزرسانی کند. به همین دلیل شماره نسخه را از مقاله‌های خبری یا فهرست‌های کپی‌شده انتخاب نکنید. Advisory رسمی و Cisco Software Checker را برای مدل و نسخه جاری بررسی کنید و فایل نرم‌افزار، hash، فضای bootflash، سازگاری ماژول‌ها و مسیر ارتقا را پیش از شروع تأیید کنید.

۴. پنجره تغییر و مسیر بازگشت طراحی کنید

پیش از ارتقا از running-config و startup-config نسخه پشتیبان بگیرید، وضعیت همسایه‌ها و پروتکل‌های مسیریابی را ثبت کنید و معیار موفقیت تعریف کنید. زمان بازگشت، نسخه قبلی معتبر، دسترسی کنسول و فرد مسئول تصمیم rollback باید مشخص باشد. در شبکه‌های حساس، ارتقای مرحله‌ای از سوئیچ کم‌ریسک‌تر آغاز شود تا ناسازگاری احتمالی با اپتیک، ماژول یا ابزار مانیتورینگ زودتر دیده شود.

۵. پس از تغییر فقط به بالا آمدن دستگاه اکتفا نکنید

نسخه نصب‌شده، وضعیت vPC یا MLAG، همسایه‌های OSPF و BGP، VLAN و VXLAN، خطاهای interface، latency، packet loss و logهای امنیتی را کنترل کنید. همچنین ابزارهای اتوماسیون و مانیتورینگ را آزمایش کنید تا تغییر در NX-API یا سیاست دسترسی باعث اختلال پنهان نشده باشد.

اگر فعلاً امکان ارتقا نداریم چه کنیم؟

برای Cisco Nexus، بهترین راه ارتقا به نسخه اصلاح‌شده است. اگر محدودیت عملیاتی اجازه reboot فوری نمی‌دهد، کاهش سطح حمله باید موقت، مستند و زمان‌دار باشد. قابلیت آسیب‌پذیر و بلااستفاده را پس از ارزیابی اثر غیرفعال کنید، دسترسی مدیریتی را به شبکه مدیریت جداگانه و فهرست IPهای مجاز محدود کنید و از قرار دادن NX-API یا رابط مدیریت روی اینترنت عمومی پرهیز کنید.

Cisco برای برخی از این نقص‌ها محافظ‌های موقت Live Protect ارائه کرده است. این گزینه باید به‌عنوان کنترل جبرانی بررسی شود، نه جایگزین دائمی وصله. ثبت رویدادها را به سامانه مرکزی بفرستید، تغییر حساب‌های مدیریتی و پیکربندی را هشداردهی کنید و تلاش‌های غیرعادی به پورت‌ها یا APIهای مدیریت را جست‌وجو کنید.

چک‌لیست عملیاتی برای مدیر شبکه

• مدل و نسخه NX-OS همه Nexusها ثبت شده است.
• حالت standalone یا ACI برای هر دستگاه مشخص است.
• وضعیت NX-API، NGOAM، MPLS OAM و SRv6 مستند شده است.
• Advisory رسمی و Software Checker برای همان مدل و نسخه بررسی شده است.
• نسخه اصلاح‌شده، checksum و مسیر ارتقا تأیید شده است.
• پشتیبان پیکربندی و دسترسی کنسول آماده است.
• طرح rollback و معیار توقف تغییر تعریف شده است.
• کنترل‌های پس از ارتقا برای routing، vPC، interface و log اجرا می‌شوند.
• زمان حذف کنترل‌های موقت و تکمیل وصله ثبت شده است.

هنگام خرید یا نوسازی زیرساخت چه نکاتی مهم است؟

رخداد Cisco Nexus یادآوری می‌کند که امنیت تجهیزات شبکه فقط ویژگی سخت‌افزاری نیست. چرخه پشتیبانی، امکان دریافت نرم‌افزار معتبر، دسترسی به advisoryها، ظرفیت نگهداری نسخه‌های پشتیبان و توان اجرای ارتقای کم‌وقفه بخشی از هزینه واقعی مالکیت هستند. در پروژه‌های دیتاسنتری، انتخاب سرورهای HPE و سوئیچ باید همراه با طراحی شبکه مدیریت خارج از باند، افزونگی توان و مسیر، نسخه‌بندی firmware و برنامه نگهداری انجام شود.

برای سازمانی که صرفاً به سوئیچ access نیاز دارد، خرید Nexus بدون نیاز واقعی می‌تواند پیچیدگی عملیاتی را افزایش دهد. در مقابل، دیتاسنتری که VXLAN، ترافیک east-west سنگین یا اتصال سرورهای پرتراکم دارد باید علاوه بر ظرفیت، توان تیم در مدیریت NX-OS، مانیتورینگ و پاسخ‌گویی امنیتی را بسنجد. خرید ارزان بدون مسیر پشتیبانی شفاف ممکن است هزینه توقف یا ریسک امنیتی بیشتری ایجاد کند.

پرسش‌های متداول درباره نقص‌های NX-OS

آیا این نقص‌ها در زمان انتشار در حال سوءاستفاده بوده‌اند؟

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

آیا خاموش‌کردن NX-API مشکل را کامل حل می‌کند؟

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

آیا همه Nexus 9000ها آسیب‌پذیرند؟

خیر. مدل، نسخه، حالت standalone یا ACI و قابلیت فعال تعیین‌کننده‌اند. نتیجه نهایی باید با Advisory و Software Checker رسمی Cisco برای همان دستگاه به دست آید.

جمع‌بندی

آسیب‌پذیری Cisco Nexus در اکتبر ۲۰۲۶ یک هشدار جدی برای شبکه‌های دیتاسنتری است، اما واکنش درست باید مبتنی بر موجودی واقعی و تغییر کنترل‌شده باشد. ابتدا دامنه اثر را با مدل، نسخه و قابلیت فعال مشخص کنید؛ سپس نسخه ثابت را از Cisco انتخاب کنید، پشتیبان و rollback بسازید و ارتقا را مرحله‌ای اجرا کنید. تا زمان وصله، سطح دسترسی مدیریت و قابلیت‌های بلااستفاده را محدود کنید و همه کنترل‌های موقت را با تاریخ پایان ثبت نمایید.

منبع

ناشر: BleepingComputer
عنوان اصلی: Cisco warns of critical flaws allowing Nexus switch takeover
مطالعه مقاله اصلی در BleepingComputer