Fortinet 資安長 Carl Windsor 日前在官方部落格緊急宣布，將於 10 月 22 日針對 FortiOS、FortiManager 與 FortiAnalyzer 同步推出安全更新，FortiMail 與 FortiAuthenticator 的修補版本則已先行釋出，接著是各防火牆等設備的新版韌體釋出。CyberQ 觀察，這批更新修補的是 critical 與 high 等級的漏洞，來源是 Fortinet 的「先進 AI 輔助安全測試計畫」，官方在文中也感謝 Anthropic、OpenAI、Google 與 SpaceX 的合作。
不但如此，針對最近全球爆發的 PHP2Shell 資安災情，Fortinet 也提供了其設備和服務的線上解法，協助採用的客戶企業度過難關。
這次發布方式和以往不同，Fortinet 決定讓修補版本先上架，漏洞公告（PSIRT advisory）延到 11 月 10 日的 Patch Tuesday 才公開。也就是說，現在所有人都拿得到修補版韌體，但沒有人知道修了哪些 CVE。Fortinet 要求全球客戶「規劃並迅速完成升級」，並以直接面對網際網路的設備為優先。
CyberQ 環境中有多台 FortiGate ，已於 10 月 23 日從 7.6.7 升級到 7.6.8，本文後半忠實記錄其中一台升級前後的實測結果。
一、受影響產品與修補版本
以下為官方公告列出的版本對照。
FortiOS（10 月 22 日釋出）
| 版本線 | 受影響版本 | 修補版本 |
|---|---|---|
| 8.0 | 8.0.0 到 8.0.1 | 8.0.2 以上 |
| 7.6 | 7.6.0 到 7.6.7 | 7.6.8 以上 |
| 7.4 | 7.4.0 到 7.4.12 | 7.4.13 以上 |
| 7.2 | 7.2.0 到 7.2.13 | 7.2.14 以上 |
FortiManager 與 FortiAnalyzer（10 月 22 日釋出，兩者版本相同）
| 版本線 | 受影響版本 | 修補版本 |
|---|---|---|
| 8.0 | 8.0.0 到 8.0.1 | 8.0.2 以上 |
| 7.6 | 7.6.0 到 7.6.7 | 7.6.8 以上 |
| 7.4 | 7.4.0 到 7.4.11 | 7.4.12 以上 |
| 7.2 | 7.2.0 到 7.2.12 | 7.2.13 以上 |
FortiMail（已先行釋出）
| 版本線 | 受影響版本 | 修補版本 |
|---|---|---|
| 8.0 | 8.0.0 到 8.0.1 | 8.0.2 以上 |
| 7.6 | 7.6.0 到 7.6.6 | 7.6.7 以上 |
| 7.4 | 7.4.0 到 7.4.8 | 7.4.9 以上 |
| 7.2 | 7.2.0 到 7.2.9 | 無修補，需升級到 7.4 以後版本線 |
FortiAuthenticator（已先行釋出）
| 版本線 | 受影響版本 | 修補版本 |
|---|---|---|
| 8.0 | 8.0.0 到 8.0.3 | 8.0.4 以上 |
| 6.6 | 6.6.0 到 6.6.10 | 6.6.11 以上 |
其他產品方面，FortiSASE 已在 10 月 22 日前自動更新，FortiManager Cloud 於 10 月 22 日前開放更新，但可能需要手動執行，公有雲上的執行個體則由全球各大雲端合作夥伴依其流程推送。
CyberQ 提醒，請注意 FortiOS 7.0 與更早的版本線不在表內，公告也沒有說明它們是否受影響。仍在使用這些版本線的設備，應向原廠確認支援狀態，並規劃升級到最新釋出更新表內的版本產品線。
二、為什麼 Fortinet 要求當成優先變更
CyberQ 觀察，公告列出四個理由：
- 修補的是 critical 與 high 等級的漏洞。
- AI 工具可能幫助攻擊者更快寫出利用程式。
- 修補版本一旦公開，攻擊者可以用「修補比對」（patch diffing）找出被修改的位置，反推漏洞。
- AI 可能把多個低風險漏洞串接成更嚴重的攻擊。
第 3 點正是這次發布方式的關鍵。官方說延後公告是在「負責任的透明度」與客戶安全之間取得平衡，讓防守方有一段沒有公開細節的時間先完成升級。但這段時間並不是對所有人都一樣長，韌體已經公開，有能力做修補比對的攻擊者不需要等到 11 月 10 日。對管理者來說，合理的假設是攻擊者手上的資訊會比公告更早出現，升級應該在公告前完成，而不是等看到 CVE 嚴重度再決定。
三、7.6.8 的 release notes 裡看得到什麼
CyberQ 分析了 FortiOS 7.6.8（build 3744）的 release notes，有幾點值得注意。
已修正問題沒有列出 CVE
Resolved issues 共 286 筆，分屬 30 個類別，沒有任何一筆附上 CVE 編號。唯一明確寫出是資安問題的是 SSL-VPN 類別的 bug 1309910，描述為「連線到惡意 SSH 伺服器並收到特製封包時發生的安全漏洞」，沒有更多細節。這和公告的說法一致，真正的漏洞清單要到 11 月 10 日才公開，release notes 不會提前透露。
預設行為的變更只有一項
「Changes in default behavior」只列 bug 1073893，大型 TCP 封包進入 IPsec 通道時，FortiGate 不再自動調整 TCP MSS，改為回送 ICMP 需要分段訊息，讓傳送端自行學習正確的 MTU。有 IPsec 通道的環境升級後，若遇到大封包傳輸卡住，要檢查路徑上的 ICMP 是否被擋。
2 GB 記憶體機型的 IPS 硬體加速預設關閉
Upgrade information 中有一條「2 GB 記憶體機型的 cp-accel-mode 預設改為 none」，適用於 FortiGate 與 FortiWiFi 的 4xF、6xF 系列。升級後 config ips global 的 cp-accel-mode 會從 advanced 改成 none，IPS 的特徵比對前處理改由 CPU 執行，不再交給 SoC4 的 CP 模組。官方說明這是為了降低記憶體用量、避免記憶體不足引起的異常，代價是 CPU 使用率可能上升。有啟用 IPS 的 60F、40F 等機型，升級後應觀察 CPU 負載。
其他與 2 GB 機型相關的特別注意事項
Special notices 共 16 項，其中與入門機型直接相關的包括，2 GB 機型不再支援大多數 proxy 相關功能、不再支援 Security Rating 與 Security Fabric 拓樸，以及 SSL VPN 通道模式已改由 IPsec VPN 取代。另外有一項「hairpin 流量需要政策檢查」，有做 hairpin（區網連自家公網位址）的環境升級後應實測一次。
四、實測：FortiGate 從 7.6.7 升級到 7.6.8
測試環境與升級方式
- 機型：FortiGate
- 升級前：FortiOS 7.6.7 build 3704
- 升級後：FortiOS 7.6.8 build 3744
- 用途：小型網路的對外閘道，單一 WAN（PPPoE），管理介面不開放在 WAN
特地選這台設備的原因是，它的 FortiGuard 服務授權（含韌體更新）已經過期，也沒有有效的支援合約。設定中的「修補層級自動升級」（auto-firmware-upgrade）是開啟的預設值，開機時事件日誌也記錄了「System patch-level auto-upgrade enabled」，但授權過期的設備不會因此自動拿到新版。這次是從 Fortinet 支援網站下載 7.6.8 映像檔，直接在 GUI 手動上傳升級。
沒有合約的設備也能升級
先前該公司更新了政策，目前 Fortinet 的韌體更新原則上綁定有效的支援合約，合約過期的設備通常拿不到新版韌體，即便是有韌體也不一定能更新。這次的情況則大不同，這台合約過期但仍算新的 F 系列設備不但順利上傳新版韌體並完成升級，筆者另外在其他設備上測試，連管理介面顯示已終止支援（EOS）的 E 系列機器也能照常更新到修補版本。
下圖即是已經過期且 EOS 的一台設備，也已經能更新到這次剛釋出的 7.2.14。
Fortinet 的公告並沒有明文說明這次開放的範圍，但從實際結果來看，這批修補是對所有設備開放，而不是只給合約內的客戶。對一批由 AI 輔助測試找出、細節即將公開的 critical 漏洞而言，這是比較負責任的作法，真正最需要修補的，往往正是那些合約早已過期、沒人顧的設備，特別是在許多公司的分點，舊產線環境上。
另外，升級後設定中會留下一筆 system device-upgrade 紀錄，其中 ignore-signing-errors 為 enable。這個參數與韌體映像的簽章檢查有關。手動下載映像時，建議先核對支援網站提供的雜湊值，再上傳到設備。
授權過期不代表會自動修補，也不代表可以放著不管。 自動升級開著、介面也會顯示有新版可用，容易讓人以為設備會自己處理，實際上必須有人手動完成。
升級前後設定差異
FortiOS 升級時會自動在 config revision 留下兩份備份，升級前（標示 upgrade report，版本為 7.6.7）與升級後（7.6.8）。CyberQ 把兩份設定依 config／edit 階層攤平成「路徑 = 值」再比對，排除每次都會重新加密的密文欄位與數千行的 IoT 特徵碼，結果如下：
| 類別 | 差異內容 |
|---|---|
| 自動化通知（automation action／stitch／trigger） | 原本共用的「Email Notification」拆成各事件專用的通知動作，新增韌體自動升級成功與失敗的觸發條件（失敗通知預設停用） |
| 服務物件 | ALL_ICMP、ALL_ICMP6 補上 icmpcode 欄位 |
| 其他 | 無 |
防火牆政策、介面存取設定、local-in 政策、DHCP、日誌設定、Web 過濾設定都沒有被升級轉換改動。另外，雖然設定檔中看不到 config ips global（因為是預設值），實際查詢 cp-accel-mode 已是 none，與 release notes 說明一致。這台的上網政策只掛了 flow 模式的 Web 過濾，沒有啟用 IPS 與 proxy 模式檢查，因此 IPS 加速關閉與 proxy 功能移除對它沒有影響。
安全設定逐項確認
升級後以 REST API 逐項檢查原有的強化設定，全部保留：
| 項目 | 升級後狀態 |
|---|---|
| WAN 介面 allowaccess | 空白，管理平面不對外 |
| 內網介面 allowaccess | 僅 ping、https、fabric（http 明文維持關閉） |
| 擋 WAN 側 SSL-VPN 埠的 local-in 政策 | 存在且啟用 |
| NTP 伺服器模式 | 關閉（僅對外校時） |
strong-crypto、TLS 最低版本 | enable、TLS 1.2 |
| 管理登入鎖定 | 失敗 3 次鎖定 60 秒 |
| 防火牆政策 | 4 條全部存在，升級後命中數持續增加 |
| DHCP 保留 | 20 筆全部存在 |
| 遠端 syslog | 設定保留（reliable、RFC 5424），收集端狀況見下文 |
值得一提的是 vpn.ssl settings 的 status 升級後仍是 enable。這台從未設定任何 SSL-VPN portal，這個值是原廠預設，由於它無法直接關閉，這台改用 local-in 政策在 WAN 側擋掉監聽埠。7.6.8 的 bug 1309910 正好落在 SSL-VPN 類別，沒在用 SSL-VPN 的設備，請確認它從外部真的連不到，不要只看 GUI 上的選單有沒有隱藏。
外部曝露驗證
從網際網路上的一台外部主機，對這台設備的公網位址測試常見的管理與 VPN 埠：
| 埠 | 結果 |
|---|---|
| TCP 10443（管理介面與 SSL-VPN 共用） | 逾時，無法連線 |
| TCP 443、80、22、23 | 無法連線 |
| TCP 541（FortiManager 管理通道） | 無法連線 |
| TCP 8443、8080 | 無法連線 |
升級沒有讓任何管理服務重新對外開放。
服務健康
| 項目 | 結果 |
|---|---|
| CPU | 閒置時 0% 到 9% |
| 記憶體 | 開機時 30%，運作約 1.7 小時後 47% |
| PPPoE WAN | 連線正常，無介面錯誤 |
| 兩台 FortiAP 221E | 皆 connected、authorized |
| DHCP | 正常發放，保留位址生效 |
| hairpin（區網經公網位址連內部服務） | 正常，HTTP 200 |
針對 release notes 提到的 hairpin 政策檢查，這台的 hairpin 流量原本就有明確的放行政策（來源包含內網位址），升級後實測正常。
實測中發現的管理細節
1記憶體日誌在重開機後歸零
有的設備沒有本機日誌硬碟，日誌存在記憶體中。升級需要重開機，重開後事件日誌從開機那一刻重新開始，升級前的管理登入紀錄與設定變更紀錄全部消失。Fortinet 建議在升級前後檢查日誌中是否有異常的管理存取，對沒有日誌硬碟的機型而言，這件事必須在升級前做，或者事先把日誌送到外部 syslog 或 FortiAnalyzer。
CyberQ 測試的這台設備其實設有遠端 syslog，重開機之後的日誌會繼續正常進來，升級前要實際到收集端確認最近幾分鐘的日誌有進來。
FortiGate 的升級報告
FortiGate 升級後管理介面會產生一份「Firmware Upgrade Report」，內容包含 Fabric 設備摘要與升級前後的設定差異。從報告中可以看到升級轉換同樣只替 ALL_ICMP、ALL_ICMP6 補上 icmpcode 欄位，system device-upgrade 紀錄中也同樣出現 ignore-signing-errors enable。不同機型、不同環境的設備結果相同，可見這個參數是 GUI 升級流程留下的一般紀錄，不是個別設備的狀況。
判讀升級報告時的兩個陷阱
所有 ENC 開頭的加密欄位每次匯出都會重新加密，所以報告中這些欄位幾乎全部顯示為有變更。這只是密文不同，不代表密碼被改過。
報告中會出現一整排以 -config 開頭、下一行緊接著 -end 的刪除行（例如 local-in-policy、DoS-policy）。這些都是原本就沒有任何內容的空區塊，被刪除的只是空殼，沒有任何規則消失。比對不同設備升級後的設定檔，這些空區塊仍然存在，可見這是報告比對方式造成的差異，不是升級刪掉了設定。
長期來說，建議在所有 FortiGate 上啟用 private-data-encryption，但要先確認 FortiManager 等管理平台的相容性，並妥善保存這把金鑰，否則日後會無法還原設定檔。
五、暫時無法升級時的緩解措施
Fortinet 在公告中列出的做法如下，官方也明說這些措施「能降低風險，但不能取代及時升級」：
把 HTTPS 與 SSH 管理存取限制在可信任的 IP，或直接在外部介面關閉。
確認 FortiManager 的管理介面不能從網際網路存取。
所有管理帳號使用強度足夠且不重複的密碼，並啟用多因素驗證。
考慮以頻外方式管理設備、把資源移到 VPN 或 SASE 後方，並套用虛擬修補（virtual patch）。
CyberQ 基於資安經驗另外補充兩點：
不要只看 allowaccess，這是因為SSL-VPN 等服務屬於設備本身的 local-in 流量，不受介面 allowaccess 與一般防火牆政策管轄，要用 local-in 政策處理，並從外部實際連線驗證。
預先保存日誌很重要， 如前所述，沒有日誌硬碟的機型重開機就會遺失記憶體日誌，入侵跡象的檢查要在升級前完成，並確認外部收集端真的有收到。
六、管理者檢查清單
升級前
盤點所有 FortiOS、FortiManager、FortiAnalyzer、FortiMail、FortiAuthenticator，優先處理直接面對網際網路的設備。
用具寫入權限的帳號下載完整設定備份。
匯出事件日誌，或到遠端收集端確認最近幾分鐘的日誌確實有進來，檢查有無異常的管理登入、新增的管理帳號或未經核准的設定變更。
從支援網站手動下載映像時，核對官方提供的雜湊值。
授權過期的設備不會自動升級，要排入人工作業。這次合約過期甚至 EOS 的設備也能取得修補版，不要因為沒有合約就略過。
升級後
確認版本與 build（比方說，7.6 分支為 7.6.8 build 3744）。
比對 config revision 中升級前後的兩份備份，確認升級轉換只動到預期的區塊。
2 GB 記憶體的 4xF、6xF 機型：檢查 config ips global 的 cp-accel-mode，有啟用 IPS 者觀察 CPU 負載。
有 IPsec 通道者：留意 TCP MSS 行為變更，確認路徑上 ICMP 未被阻擋。
從外部實際測試管理埠與 SSL-VPN 埠是否仍然關閉。
測試 hairpin、無線 AP、DHCP 等日常服務。
訂閱 FortiGuard PSIRT 公告，11 月 10 日公告公開後，對照 CVE 內容重新評估是否需要額外處置。
AI 讓漏洞被找到的速度變快
CyberQ 認為，這次 Fortinet 的做法，等於把「先修補、後公開」從單一廠商的協調揭露擴大成一次性的整批更新，背後的理由也很直接：AI 讓漏洞被找到的速度變快，修補比對與利用程式的開發也會跟著變快。對防守方來說，能利用的時間差就是現在到 11 月 10 日之間，而這段時間差是否真的存在，取決於攻擊者做修補比對的速度，沒有人能保證。
從實測來看，7.6 分支從 7.6.7 升到 7.6.8 是一次低風險的升級，設定轉換只動到自動化通知與 ICMP 服務物件，原有的強化設定全部保留，服務在重開機後正常恢復。真正需要留意的是 2 GB 機型的 IPS 加速預設關閉、IPsec 的 TCP MSS 行為變更，以及升級前要先保存日誌與完整備份。
CyberQ 建議，由於這次修補連合約過期的設備都能取得，沒有理由再拖延，建議儘早排入維護時段完成升級。
延伸閱讀
FortiOS 7.6.8 Changes in default behavior
Default setting of cp-accel-mode is changed to none on 2GB memory models
