2026年7月17日 · Fortinet · Perimeter · Schwachstellenmanagement · IT-Sicherheit

防火墙自己打补丁：FortiOS 升级

FortiOS 会自动更新，在某些情况下甚至是强制更新。是什么触发了这些升级、有哪些例外，以及您可以如何应对。

一台防火墙在夜间重启，第二天早上运行的是另一个固件版本，而团队里没有任何人安装过更新。对于 FortiGate 系统而言，这是有文档记载的行为。2026 年 7 月 17 日，boll 的技术博客以“Your FortiGate Updated Itself – But You Don’t Know Why?”为题发表了一篇总结，说明这种情况是如何发生的。我们对照制造商文档核查了其中的说法。

简而言之：存在两种机制。其中一种您可以关闭，另一种则不能。

机制 1：自动补丁升级

自 FortiOS 7.2.1 起，可以设置让 FortiGate 自行安装新的补丁版本。在 7.4.5 之前，该功能仅在入门级型号上出厂即启用。Fortinet 在 FortiOS 7.4.5 中改变了这一点：根据制造商文档，自该版本起，自动固件升级“在所有 FortiGate 型号上，包括 FortiGate-VM”默认开启。更新到 7.4.5 后首次打开 Web 界面的人，必须点击“I acknowledge”加以确认——这一下点击在日常工作中很容易被忽略。

对于理解这一点很重要的是：该功能只在当前运行的版本分支内更新。7.4.x 会变成更新的 7.4.x，永远不会变成 7.6.x。所以这里涉及的是补丁，而不是版本跃迁。

该行为可在界面中“System > Firmware & Registration”下控制，或通过 CLI 在 config system fortiguard 下控制。您可以在那里设定该功能是否启用、允许在一周中的哪几天安装，或在补丁发布后等待多少天（根据文档，默认为三天），以及在哪个时段内进行。默认是当地时间 2 点至 4 点；具体时间点在该时段内随机选择。安装完成后，会向设备注册所在的 FortiCloud 账户发送一封电子邮件——而不一定发给如今负责这台防火墙的人。

机制 2：强制升级

第二种机制才是 boll 撰写那篇文章的真正原因。Fortinet 称之为“Required firmware upgrade”，boll 则称之为“Forced Upgrade”。当以下两个条件之一满足时，它就会生效：

  • 固件许可无效。 Fortinet 说的是无效的“Firmware & General Updates (FMWR)”许可，boll 则更笼统地说是缺少有效的 FortiCare 合同。
  • 版本分支已达到其 End of Engineering Support（EOES）。 也就是说，设备运行在一个制造商已不再进行开发的次版本上。

在这些情况下，FortiGate 每天检查自身版本分支中是否有更新的补丁，并自行安排安装。这里同样只限于次版本内的补丁；如果升级路径需要经过中间版本，则会依次逐个完成。

关于这一机制自哪个版本起适用，各来源的说法并不完全一致。boll 和 Fortinet 关于 FortiOS 8.0 的“New Features”页面给出的是 7.4.8 和 7.6.4；8.0 版管理手册给出的是 7.4.9 和 7.6.4。FortiOS 8.0.0 无论如何都受影响。运行 7.4.8 或 7.6.4 及更高版本的用户，应当假定这一机制适用。

与自动升级的决定性区别在于：强制升级一经安排便无法取消。 界面会将取消按钮置灰，控制台的提示大意是：该升级为强制升级，无法取消。唯一可行的是使用 execute auto-upgrade delay-installation 推迟。boll 给出的推迟时长为七天。FortiOS 8.0 管理手册确认了固定推迟七天，并补充了两个细节：该命令可以任意多次重复执行，但不能在计划安装的当天执行。

当前状态可通过 execute auto-upgrade status 查看。其中显示的内容包括合同状态、当前运行的镜像是否已到达生命周期终点，以及——如果到了那一步——“Enabled (Forced)”的标注连同计划的时间窗口。

例外情况——以及为什么它们并非都能提供保护

boll 列出了强制升级不生效的三种情形。制造商文档证实了这些情形，但描述得更为准确——而这些细节改变了结论：

  • 由 FortiManager 管理。 与 FortiManager 相连的 FortiGate 不会自行更新。如果在强制升级已被安排的情况下将其连接到 FortiManager，该升级会被取消。
  • Security Fabric 成员。 这里同样不会进行自动升级。反过来说：如果强制升级已被安排，该设备就无法加入任何 Fabric。
  • HA 集群的次要成员。 这是最容易被误解的例外。次要设备不会自行启动升级——但它会通过由主设备发起的集群升级获得新固件。也就是说，集群作为一个整体会被更新。

第四种例外只出现在制造商文档中：在特殊版本（“special builds”）上，强制升级不生效。

安全收益与变更控制之间的权衡

制造商以保护设备为由来解释这一机制，这个论点是成立的：一台没有固件合同、或运行在不再开发的版本分支上的防火墙，是一个再也得不到修复的边界系统。

但对运营而言，这仍然是对变更控制的一种干预。固件更换意味着重启，对单台设备而言也就意味着连接中断。它可能改变规则集、VPN 对端或所连接系统所依赖的行为。而且它发生的时间点不是由您的变更流程决定的，而是由设备自己决定的。

好消息是：两个触发条件都是可预见的。许可到期和 EOES 日期都是很早就已确定的。

您现在应当做什么

  • 摸清现状。 在每台设备上使用 execute auto-upgrade status 检查自动升级是否启用，以及是否已经安排了强制升级。
  • 将合同期限和 EOES 日期纳入资产清单。 固件许可的到期日和版本分支的支持终止日，应作为字段纳入资产登记表，并配有负责人和提前期——而不是存在个别员工的记忆里。
  • 把时间窗口与您的维护窗口挂钩。 设定一周中的日期和时段，使自动升级落在已公告的维护窗口内，并将该设置记录在案。
  • 先在实验环境中测试补丁。 一台运行同一版本分支的测试设备或虚拟实例，可以在生产设备之前显示某个补丁是否会影响规则集、VPN 或身份认证。
  • 把通知引导到正确的地方。 邮件会发送到已注册的 FortiCloud 账户。请检查如今是否还有人在读这个邮箱。
  • 清楚哪项例外适用于您。 通过 FortiManager 进行管理的用户不受强制升级影响——因此必须自己主动管理补丁状态。运营 HA 集群的用户则不在例外之列。
  • 把推迟视为工具，而不是解决方案。 七天可以争取时间，用来完成一次测试或约定一个窗口。它既不能替代合同，也不能替代向受支持版本分支的迁移。

sector7 如何提供支持

在我们的托管服务框架内，我们以补丁、配置和变更管理来运营防火墙和 VPN，并有计划、有记录地更新系统，而非临时应急；我们会提前公告维护窗口，并将其安排在营业时间之外。详情请见托管服务与支持和网络安全。

来源

让我们聊聊您的具体情况。

预约洽谈+49 212 240915 0