CISA در به‌روزرسانی 2026-07-27 کاتالوگ Known Exploited Vulnerabilities، آسیب‌پذیری CVE-2025-68686 مربوط به Fortinet FortiOS را اضافه کرده است. Fortinet این مورد را در advisory با شناسه FG-IR-25-934 توضیح داده و آن را به FortiOS SSL-VPN و سناریویی مرتبط می‌داند که مهاجم پیش‌تر به سطحی از دسترسی فایل‌سیستمی روی دستگاه رسیده باشد. نکته عملی برای تیم شبکه این است که موضوع فقط «نصب یک patch» نیست؛ باید وضعیت SSL-VPN، نسخه FortiOS، نشانه‌های ماندگاری بعد از بهره‌برداری و مسیر ارتقا همزمان بررسی شوند.

برای سازمان‌هایی که FortiGate را در مرز اینترنت، شعب، VPN کاربران یا اتصال پیمانکارها استفاده می‌کنند، این نوع خبر باید به یک برنامه کوتاه واکنش تبدیل شود. اگر SSL-VPN هرگز فعال نبوده، Fortinet می‌گوید دستگاه از این مسئله خاص متاثر نیست؛ اما همین گزاره باید از روی config و history تغییرات تایید شود، نه از حافظه تیم. اگر SSL-VPN فعال بوده یا قبلا فعال بوده و بعدا غیرفعال شده، بهتر است بررسی نسخه، لاگ‌ها و وضعیت فایل‌سیستم با نگاه incident response انجام شود.

خلاصه فنی ماجرا

بر اساس Fortinet، CVE-2025-68686 از جنس exposure of sensitive information است و می‌تواند در ادامه یک compromise قبلی، امکان bypass بخشی از patch مربوط به symbolic link persistence را فراهم کند. متن advisory صریحا می‌گوید مهاجم برای سوءاستفاده باید ابتدا از راه آسیب‌پذیری دیگری به سطح فایل‌سیستم رسیده باشد. همین نکته باعث می‌شود ارزیابی ریسک با یک سوال ساده شروع نشود که «نسخه ما vulnerable هست یا نه؟»؛ سوال درست‌تر این است که آیا دستگاه در گذشته در معرض آسیب‌پذیری‌های مسیر SSL-VPN بوده، آیا نشانه‌ای از دسترسی قبلی وجود دارد و آیا ارتقای فعلی به نسخه fixed واقعا مسیر persistence را بسته است؟

نسخه‌های affected طبق Fortinet شامل FortiOS 7.6.0 تا 7.6.1، FortiOS 7.4.0 تا 7.4.6 و همه نسخه‌های 7.2، 7.0 و 6.4 است. برای شاخه 7.6 ارتقا به 7.6.2 یا بالاتر و برای 7.4 ارتقا به 7.4.7 یا بالاتر مطرح شده است. برای شاخه‌های قدیمی‌تر، توصیه عملی مهاجرت به release fixed است. این بخش باید با upgrade path رسمی Fortinet و سازگاری featureهای سازمان چک شود، چون ارتقای عجولانه روی فایروال مرزی می‌تواند به اندازه تاخیر در patch دردسرساز باشد.

اولویت‌بندی در شبکه واقعی

اولویت اول، دستگاه‌هایی هستند که SSL-VPN روی اینترنت دارند یا در گذشته داشته‌اند. بعد از آن باید FortiGateهایی بررسی شوند که مدیریت آن‌ها از بیرون، policyهای پیچیده، اکانت‌های متعدد ادمین یا history نامشخص تغییرات دارند. اگر چند FortiGate در شعب مختلف وجود دارد، بهتر است فهرست assetها با نسخه FortiOS، نقش دستگاه، وضعیت SSL-VPN، exposure اینترنتی و حساسیت سرویس‌ها کنار هم قرار بگیرد.

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

چک‌لیست واکنش پیشنهادی

ابتدا inventory دستگاه‌ها را کامل کنید: مدل، نسخه FortiOS، نقش دستگاه، حالت HA، فعال بودن SSL-VPN، مسیرهای مدیریتی و آخرین تاریخ ارتقا. بعد، exposure را مشخص کنید؛ یعنی کدام public IPها، کدام پورت‌ها و کدام virtual server یا policyها به VPN یا مدیریت دستگاه مرتبط‌اند. اگر SSL-VPN فعال نیست، فقط به وضعیت فعلی اکتفا نکنید و history تغییرات یا backupهای config را هم ببینید.

مرحله بعد، بررسی نشانه‌های غیرعادی است. لاگ loginهای ادمین، تغییرات config، رفتار SSL-VPN، اکانت‌های تازه، فایل‌ها یا مسیرهای غیرمنتظره و هر نشانه‌ای از persistence باید با احتیاط بررسی شود. در محیط‌هایی که SIEM یا log collector دارند، بهتر است بازه قبل و بعد از advisory و همچنین بازه آسیب‌پذیری‌های قبلی Fortinet بررسی شود. اینجا عجله برای پاک کردن اثرها می‌تواند شواهد مهم را از بین ببرد؛ اگر احتمال رخداد جدی است، snapshot، backup امن و مستندسازی قبل از تغییر مهم‌تر از clean-up سریع است.

برای ارتقا، مسیر رسمی Fortinet را مبنا قرار دهید و قبل از تغییر، dependencyها را مشخص کنید: VPN کاربران، routeها، policyهای حساس، integration با RADIUS/LDAP، HA sync و پنجره قطعی قابل قبول. بعد از ارتقا، فقط به بالا آمدن دستگاه اکتفا نکنید. تست ورود VPN، دسترسی کاربران، log تولیدشده، policyهای اصلی، route برگشت و سلامت HA باید کنترل شود. اگر از Virtual Patch یا IPS signature مرتبط استفاده می‌کنید، آن را جایگزین ارتقا ندانید؛ می‌تواند کنترل موقت باشد، نه پایان کار.

چه زمانی موضوع را جدی‌تر کنیم؟

اگر دستگاه قبلا SSL-VPN عمومی داشته، نسخه vulnerable طولانی‌مدت روی اینترنت بوده، لاگ‌ها ناقص‌اند یا چند نشانه کوچک کنار هم دیده می‌شود، بهتر است موضوع را مثل incident بالقوه مدیریت کنید. در چنین وضعیتی، تغییر password ادمین‌ها، بازبینی trustهای داخلی، بررسی دسترسی‌های مدیریتی، محدود کردن management plane و مرور backupهای config باید در برنامه بیاید. برای این بخش، Baseline هاردنینگ تجهیزات شبکه و لاگ‌های مهم امنیت شبکه مسیر اجرایی بهتری می‌دهند.

یک خطای رایج این است که تیم فقط نسخه را upgrade می‌کند و پرونده را می‌بندد. در advisoryهایی که به persistence یا post-exploit اشاره دارند، upgrade لازم است اما کافی نیست. باید بدانید قبل از upgrade چه اتفاقی افتاده، بعد از upgrade چه چیزی عوض شده و آیا راه دسترسی غیرعادی باقی مانده یا نه. اگر سازمان چند فایروال و چند مسیر VPN دارد، همین کار باید برای همه نقاط تکرار شود؛ نه فقط دستگاهی که بیشتر جلوی چشم است.

جمع‌بندی عملی

CVE-2025-68686 به‌خاطر اضافه شدن به CISA KEV و ارتباط با FortiOS SSL-VPN ارزش توجه فوری دارد، اما واکنش درست آن panic نیست. فهرست دارایی، تایید وضعیت SSL-VPN، بررسی نشانه‌های compromise، انتخاب مسیر ارتقای امن و کنترل بعد از تغییر، باید در یک runbook کوتاه کنار هم قرار بگیرد. اگر FortiGate در مرز اینترنت یا مسیر VPN سازمان نقش حیاتی دارد، بهتر است این بررسی با نگاه عملیاتی و قابل بازگشت انجام شود؛ همان جایی که طراحی فایروال، مانیتورینگ و پاسخ به رخداد از هم جدا نیستند.

علیرضا عربیان

مشاور و مدرس امنیت شبکه، متخصص FortiGate، FortiWeb و F5 BIG-IP در زیرساخت‌های سازمانی.

مشاهده همه مقالات ←

دیدگاه بگذارید