4.76
這不是什麼性能指標，也不是財報上的增長數字。它是 2024 年，駭客留給全世界 FortiGate 用戶的**『緩刑時間』**。
從原廠發布漏洞公告，到第一批企業被駭客徹底打穿，平均只有 4.76 天。在這不到五天的時間裡，無數的工程師被迫在半夜驚醒。你面對的是一個無解的選擇題：要現在重啟設備、承擔營運中斷的風險去修補？還是要賭那 4.76 天的運氣，祈禱 IP 不在駭客的掃描名單裡？
但最讓人絕望的，即便用戶不離不棄，付出了時間與各種成本，換來的卻是原廠的一句：**『我不修了，這功能我直接廢了。』**那一刻才明白，在商業資安的巨輪下，原廠為了自救，可以不計代價，而用戶，就是那個代價。
[2024-2025 漏洞編年史]
回顧這段歷史，FortiOS 的安全神話並非一夕崩解，而是在長達一年的時間裡，經歷了密集的結構性潰敗。我們攤開這份由日期與編號組成的清單，就能看清這場連環爆的真實樣貌：
2024 年 2 月 8 日，CVE-2024-21762 (SSL-VPN)：全年的第一聲喪鐘。這是一個嚴重的遠端代碼執行漏洞，攻擊者無需身分驗證即可接管設備。資安署隨即發布專案通報，要求企業在數小時內採取行動。
2 月 9 日，CVE-2024-23108 (FortiSIEM)：緊接著邊界漏洞，威脅燒到了企業的安全中樞。這是一個高達 9.8 分的命令注入漏洞，讓駭客能直接接管你的資安監控大腦。這證明了這不只是單一模組的疏失，而是整個 Fortinet 產品線在代碼審查上的系統性失靈。
3 月 12 日，CVE-2023-48788 (FortiClient EMS)：威脅從邊界蔓延至管理中樞。攻擊者利用 SQL 注入手段，繞過驗證取得端點管理權限，讓內部網路門戶大開。
10 月 10 日，CVE-2024-23113 (fgfm)：針對管理協議的重擊。即便管理員關閉了 Web 介面，只要管理協議在運行，攻擊者就能透過格式化字串漏洞取得控制權。
10 月 23 日，CVE-2024-47575 (FortiManager)：被資安界稱為**『FortiJump』**的危機爆發。駭客繞過驗證直接接管管理平台，將防禦核心轉化為大規模滲透的跳板。
2025 年 1 月 14 日，CVE-2024-50604 (SSL-VPN)：這是一個資訊洩漏漏洞。雖然它不像 RCE 那樣能直接奪權，但它暴露了 SSL-VPN web-mode 的底層配置，讓防禦者徹底透明化。它傳達了一個最讓人不安的訊號：即便修了一年，這個模組依然處於『修好一個、漏一個』的虛弱狀態。
這份橫跨 340 多天的清單，向我們展示了一個殘酷的事實：漏洞已不再是偶發的臭蟲，而是一種修不好的結構性常態。
[SSL-VPN 的結構性崩潰]
分析這份跨年度的漏洞清單，雖然威脅散佈在各個產品線，但最致命、最頻繁、且最終導致原廠採取「焦土政策」的震央，始終鎖定在 SSL-VPN 模組。
這不只是代碼寫錯的問題，而是反映了 FortiOS 在初期設計上的核心邏輯：為了效能，犧牲了隔離。 在 Fortinet 的架構中，SSL-VPN 服務並非運行在隔離的用戶空間（User Space），而是與系統內核（Kernel）存在高度的交互與依賴。
這種設計在過去「效能至上」的環境下，能透過硬體加速實現漂亮的數據；但在面對現代零日漏洞（0-day）攻擊時，這種架構特性卻演變成了「風險放大器」。因為 SSL-VPN 與系統核心的界線模糊，一旦這個對外開放的門戶出現任何溢位漏洞，駭客拿到的不只是 VPN 權限，而是直接握住了整台設備的命脈。
這解釋了為什麼 2024 年的修補輪迴會如此絕望。即便工程師修好了 FortiManager 或 FortiSIEM 的漏洞，只要這個高度耦合的 SSL-VPN 模組還在運行，這台設備的結構性風險就永遠無法根除。
[7.6.3 的焦土政策]
面對無法根除的結構性風險，Fortinet 在 2024 年底給出了一個令業界震驚的答案。
**2025 年 4 月 17 日，Fortinet 正式發布了 FortiOS 7.6.3。**在這份看似平凡的韌體更新公告中，隱藏了一個極其罕見的決定：全面移除 SSL-VPN 功能。
這項決策不分硬體等級、不論企業規模，只要用戶選擇升級到 7.6.3 或後續版本，原本熟悉的 SSL-VPN 設定選單將會徹底消失。在商用網路設備的發展史上，這是一個極具象徵意義的轉折點——這並非功能更迭，而是一場因技術架構失控而進行的技術性撤退。
從新聞敘事的角度觀察，這是一次徹底的**『焦土政策』**。官方數據與密集的漏洞通報證明，在現有的耦合架構下，原廠已無法有效防禦針對 SSL-VPN 的零日攻擊。為了保住品牌的信任底線，他們選擇直接終止了這個擁有數百萬用戶核心功能的歷史使命。
這項舉動雖然強制止住了漏洞的連環爆發，但也留下了一個巨大的技術真空。它迫使所有依賴該功能的用戶，在毫無緩衝的情況下，必須全面轉向 IPsec VPN 或 ZTNA 架構。
[轉嫁給用戶的技術債]
當 7.6.3 的公告正式生效，原廠成功地將技術風險『清零』，但對用戶而言，這卻是一場龐大成本與死線賽跑的開始。
被壓縮的轉型時限：原廠透過產品支援終止（EOS）向老客戶施壓。FortiOS 7.2 分支將在 2026 年 9 月 30 日停止維護，而 7.4 分支也將在 2027 年 11 月 11 日迎來終點。
維運架構的劇烈震盪：移除 SSL-VPN 代表 IT 團隊必須重新佈署 IPsec 或 ZTNA 架構，重新定義安全原則，這背後代表的是數百個、甚至數千個原本不需要存在的加班小時。
硬體價值的貶損：許多企業採購中高階設備看中的是其專屬晶片的硬體加速。隨著功能切除，這些昂貴資源在一夜之間變成了冗餘的空殼。
[專有架構的技術臨界點]
這場長達一年的修補風暴，引發了一個深層的技術省思：為什麼會選擇『移除功能』這一條路？
從技術層面分析，Fortinet 將 SSL-VPN 協議與系統內核（Kernel）進行了深度的私有化整合。當代碼庫在長年的優化與魔改下變得過於臃腫，其安全性邊界也隨之模糊。2024 年的連環爆發證明：這套私有架構在面對現代安全挑戰時，已經觸及了其自我修復的極限。
遺憾的是，我們看到的不是原廠轉向更透明、更具彈性的開源標準——如 OpenVPN 或 WireGuard。相反地，為了維持生態系的封閉性與主導權，原廠選擇了直接終止功能。
真正的營運韌性，不應該鎖死在任何一家廠商的私有代碼裡。 只有回歸『簡單、解耦、擁抱標準』，當品牌的神話面臨考驗時，企業才能擁有真正的選擇權，而不僅僅是等待一張功能廢止的公告。
觀看完整影音解說： https://youtu.be/ENR0H95FWBg
沒有留言:
張貼留言