وقتی یک آسیبپذیری FortiWeb وارد کاتالوگ KEV میشود، موضوع فقط «یک CVE جدید» نیست. یعنی شواهد بهرهبرداری فعال وجود دارد و تیم شبکه باید با ترتیب درست جلو برود: نسخه را مشخص کند، سطح دسترسی مدیریتی را محدود کند، ارتقا را زمانبندی کند، لاگها را بخواند و بعد از تغییر، رفتار سرویسهای پشت WAF را دوباره بسنجد.
در هشدار رسمی CISA برای ۱۴ نوامبر ۲۰۲۵، آسیبپذیری CVE-2025-64446 به KEV اضافه شده است. راهنمای Fortinet هم این مورد را بهعنوان path traversal در FortiWeb معرفی میکند که در بعضی نسخهها میتواند با درخواست HTTP یا HTTPS ساختهشده، اجرای دستور مدیریتی را ممکن کند. Fortinet در FG-IR-25-910 نوشته که بهرهبرداری در محیط واقعی مشاهده شده و برای نسخههای تحت تأثیر، ارتقا و محدودسازی دسترسی مدیریتی را توصیه کرده است.
اول نسخه و محل قرارگیری FortiWeb را روشن کنید
قبل از هر تصمیم فنی، باید بدانید FortiWeb کدام نقش را بازی میکند. یک FortiWeb که فقط پشت VPN مدیریتی و در مسیر داخلی قرار دارد، با FortiWebی که پنل مدیریتی یا interface مدیریتی آن از اینترنت دیده میشود، ریسک یکسانی ندارد. نسخههای تحت تأثیر در راهنمای Fortinet شامل شاخههای 8.0، 7.6، 7.4، 7.2 و 7.0 هستند و هر شاخه حداقل نسخه امن خودش را دارد. بنابراین اولین خروجی قابل دفاع باید یک جدول ساده باشد: نام دستگاه، نسخه فعلی، مدل استقرار، مسیر مدیریت، سرویسهای پشت WAF، آخرین زمان backup و owner تغییر.
اگر FortiWeb بخشی از سرویسهای عمومی سازمان است، بهتر است ارزیابی فقط در حد نگاه کردن به نسخه تمام نشود. باید مشخص شود کدام virtual serverها، server policyها و certificateها روی دستگاه فعال هستند و تغییر نسخه چه اثری روی ترافیک production میگذارد. برای چنین سناریویی، داشتن یک نقشه روشن از معماری در طراحی استقرار FortiWeb در سازمان کمک میکند تصمیم ارتقا از حالت واکنش عجولانه خارج شود.
مسیر مدیریت را تا زمان ارتقا کمریسک کنید
در advisory رسمی، workaround اصلی این است که HTTP یا HTTPS برای interfaceهای internet-facing غیرفعال شود؛ اگر مدیریت فقط از داخل شبکه و طبق best practice در دسترس باشد، ریسک به شکل معناداری کمتر میشود. در عمل، این یعنی قبل از تغییر نسخه باید ACL، policy، routing و مسیرهای VPN مدیریت بررسی شوند. اگر تیم مجبور است پنل مدیریتی را موقتاً در دسترس نگه دارد، حداقل باید محدودسازی بر اساس source معتبر، احراز هویت قوی، لاگگیری دقیق و بازبینی sessionهای فعال انجام شود.
اشتباه رایج این است که تیم فقط firmware را میبیند و مسیر رسیدن مهاجم به interface مدیریتی را رها میکند. در FortiWeb، تفاوت بین data plane سرویسهای وب و مسیر administrative management باید روشن باشد. اگر همان segment یا همان rule base برای هر دو استفاده شده، قبل از ارتقا هم باید محدودسازی انجام شود، چون زمانبندی patch ممکن است چند ساعت یا چند روز طول بکشد.
ارتقا را مثل change عملیاتی اجرا کنید، نه مثل نصب فوری
برای نسخههای تحت تأثیر، Fortinet نسخههای حداقلی امن را معرفی کرده است؛ برای مثال 8.0.2 به بالا در شاخه 8.0، 7.6.5 به بالا در شاخه 7.6، 7.4.10 به بالا در شاخه 7.4، 7.2.12 به بالا در شاخه 7.2 و 7.0.12 به بالا در شاخه 7.0. این عددها نباید جدا از مسیر upgrade path خوانده شوند. در Fortinet، پریدن بین نسخهها بدون توجه به مسیر پیشنهادی میتواند مشکل configuration، policy behavior یا سازگاری ایجاد کند.
قبل از ارتقا، backup پیکربندی، خروجی policyها، لیست administratorها، وضعیت HA، certificateها، server poolها و exceptionهای حساس باید ذخیره شود. اگر FortiWeb در مسیر پرداخت، پورتال مشتری یا API حساس است، یک window کوچک بدون rollback plan کافی نیست. بهتر است یک سناریوی smoke test نوشته شود: باز شدن صفحههای کلیدی، login، requestهای API مهم، ruleهای rate limit، exceptionهای WAF و لاگ شدن eventهای مهم.
بعد از ارتقا دنبال نشانه تغییر غیرمجاز بگردید
Fortinet در post-upgrade step توصیه کرده configuration و logها برای تغییرات غیرمنتظره یا ایجاد administrator غیرمجاز بررسی شوند. این بخش برای تیمهای عملیاتی مهمتر از خود خبر CVE است. اگر دستگاه قبل از ارتقا در معرض exploit بوده، صرفاً بالا بردن نسخه کافی نیست؛ باید فرض کنید ممکن است تغییری در تنظیمات رخ داده باشد و با شواهد جلو بروید.
چند نقطه شروع کمریسک برای triage عبارتاند از: administrator accountهای جدید یا تغییر نقشها، loginهای غیرعادی، تغییر روی server policyها، تغییر در access control، certificate یا profileها، ruleهایی که ناگهان relax شدهاند، خاموش شدن logging، تغییر در exceptionها و requestهایی که قبل از هشدار رسمی با الگوی غیرمعمول به مسیر مدیریتی رسیدهاند. برای خواندن درست همین شواهد، مطلب عیبیابی FortiWeb با لاگ و Request مسیر عملیتری نسبت به نگاه کلی به داشبورد میدهد.
Exceptionها را بدون پاک کردن ردپا اصلاح کنید
در روزهای بعد از چنین CVEهایی معمولاً فشار روی تیم زیاد میشود: سرویس باید بالا بماند، patch باید سریع انجام شود و کاربر هم نباید خطای بیمورد بگیرد. خطر اینجاست که برای عبور از مشکل، یک exception بزرگ ساخته شود یا policy از حالت Block به Monitor برگردد و بعد همان تغییر فراموش شود. اگر لازم است exception موقت ساخته شود، باید scope، علت، تاریخ بازبینی و owner داشته باشد.
برای WAF، exception بینام و بیزمان همانقدر خطرناک است که patch نکردن. اگر بعد از ارتقا false positive بالا رفت، مسیر درست این است که request نمونه، rule مربوط، application behavior و مدت اعتبار exception مشخص شود. در این بخش میتوان از چارچوب مدیریت Exception در WAF استفاده کرد تا تیم بین امنیت و availability، تصمیم قابل دفاع بگیرد.
کجا پای مشاوره یا بازبینی بیرونی وسط میآید؟
اگر FortiWeb فقط یک appliance ساده در lab باشد، اجرای checklist داخلی احتمالاً کافی است. اما در محیط سازمانی، FortiWeb معمولاً روی مسیر چند سرویس مهم نشسته و تغییر آن به load balancer، reverse proxy، certificate chain، مسیر لاگ و گاهی SIEM وصل است. وقتی تیم نمیداند کدام policy واقعاً active است، مسیر مدیریت از کجاها باز است، یا بعد از ارتقا چه testی باید انجام شود، یک بازبینی بیرونی میتواند ریسک تصمیمهای شتابزده را کم کند.
برای عربیان، این موضوع بهطور طبیعی به مشاوره و پیادهسازی WAF و همچنین پاسخ به رخداد در شبکه وصل میشود. هدف از واکنش به CVE فقط عبور از یک هشدار نیست؛ باید به نقطهای برسید که بدانید دستگاه در معرض بوده یا نه، تغییرات غیرمجاز دیده شده یا نه، نسخه اصلاح شده یا نه، و بعد از change، WAF هنوز همان رفتاری را دارد که برای سرویسهای سازمان لازم است. اگر این چهار سؤال جواب شفاف ندارند، بهتر است قبل از تغییر بعدی، یک baseline قابل اتکا ساخته شود.
چکلیست کوتاه واکنش به CVE-2025-64446
- نسخه FortiWeb و شاخه ارتقا را با advisory رسمی تطبیق دهید.
- دسترسی HTTP/HTTPS مدیریتی از اینترنت را ببندید یا تا زمان ارتقا به sourceهای مشخص محدود کنید.
- backup کامل configuration و وضعیت policyها، administratorها، certificateها و HA را نگه دارید.
- مسیر ارتقا را طبق upgrade path اجرا کنید و smoke test سرویسهای پشت WAF را از قبل بنویسید.
- بعد از ارتقا، accountهای مدیریتی، تغییرات policy، exceptionها و لاگ requestهای مشکوک را بررسی کنید.
- اگر نشانه تغییر غیرمجاز دیدید، موضوع را مثل رخداد امنیتی مدیریت کنید، نه فقط یک patch فنی.
این نوع واکنش وقتی ارزش دارد که خروجی آن قابل پیگیری باشد: نسخه اصلاحشده، مسیر مدیریت محدود، شواهد لاگ بررسیشده، exceptionهای موقت ثبتشده و نتیجه تست سرویسها. بدون این خروجیها، حتی اگر CVE از نظر نسخه بسته شده باشد، ریسک عملیاتی و امنیتی هنوز میتواند در پیکربندی باقی بماند.
