Sophos Firewall：没有 CVE，但漏洞百出（v21.5 到 v22）

如果您目前在防火墙领域工作，您通常会面临两大恶魔之一：要么您因为关键漏洞（CVE，就像目前的 Fortinet）而持续处于压力之中，彻夜打补丁；要么系统因为不稳定的固件和烦人的 Bug（就像目前的 Sophos）在日常运维中给您设置了重重障碍，导致您什么也做不了。

在我的公司工作中，后者正是我们目前的真实写照——这种压力自然也会被我带回家。我们当前的痛点名为：Sophos Firewall。

当像 Fortinet 这样的竞争对手似乎每周都在发布新的 PSIRT 报告，让管理员们在打补丁的循环中连轴转时，Sophos 却在大量消耗我们的时间。不是因为那些登上头条的漏洞，而是因为日常运维中那些极其普通却又致命的 Bug。

免责声明，以免听起来像是在比较苹果和橘子： 我非常清楚 Fortinet 同样在与大量 Bug 作斗争（想想 FortiOS 7.2/7.4/7.6 中的 Conserve Mode 和内存泄漏），而且 Sophos 过去也发生过严重的 CVE。然而，在当前的 v21.5/v22 阶段，这种特定的情况正是我们的痛点所在：对于一家厂商，是不断的 CVE 补丁；而对于 Sophos，是由稳定性问题导致的无谓的运维工作。

版本背景 (简而言之)

为了说明我写的不是落满灰尘的 v19，而是很多人目前正在运行的“最新”版本：

• SFOS 21.5 GA (2025年6月2日): 发布说明: SFOS 21.5
• SFOS 21.5 MR2 (Build 323, 2026年2月18日): 根据发布说明，这是该时间段内最新的 21.5 版本。
• SFOS 22.0 GA (2025年12月) 和 v22 GA Re-Release (Build 411, 2026年1月20日): 发布说明: SFOS 22.0

这些都是 GA (通用可用性) 和维护版本 (MR)，而不是随机的 “夜间构建” 版本。

为了确保这种对比不仅仅是基于感觉，这里有一个快速的现实核查。

Fortinet：自 2025 年 11 月以来的 FortiOS CVE（截至 2026 年 2 月 26 日）

时间段：2025 年 11 月 1 日至 2026 年 2 月 26 日（发布日期）。来源：Fortinet PSIRT 报告（PSIRT 概览）。

我特意没有在这里列出“所有 Fortinet 问题”，而只列出了这段时间内与 FortiOS/FortiGate 相关的报告，因为在实践中，这才是痛点：您必须去修补、计划和测试。

CVSS 分数并不能代表一切，但它让运维中的对比变得明显：一个 5.x 的中危漏洞通常是可以计划的，而一个 9.x 的漏洞很快就会变成“放下一切立刻打补丁”的场景。

2026 年 2 月 10 日发布（同一天发布多个报告）

• FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): FortiOS GUI 中的请求走私。令人不快的还有它涉及到“未记录的请求”。
• FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): CAPWAP 快速故障转移模式下的格式字符串问题（Admin/Config 作为触发器）。
• FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): 无代理 VPN/FSSO 中的 LDAP 身份验证绕过（实践中常见的权宜之计：在 LDAP 服务器上禁用未经身份验证的绑定）。
• FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): SSL VPN 符号链接持久性补丁绕过。对上下文很重要：根据报告，它需要事先通过文件系统级别的其他漏洞进行妥协。
• FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): FSSO 终端服务代理中的策略绕过（修复方案是 FortiOS 版本和 TS 代理最低版本的组合）。

2026 年 1 月

• FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4)，2026 年 1 月 27 日发布: 管理 FortiCloud SSO 身份验证绕过。该报告还描述了在野外的利用情况和具体的对策。
• FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4)，2026 年 1 月 13 日发布: cw_acd 守护进程中的基于堆的缓冲区溢出 (FortiOS/FortiSwitchManager)。

2025 年 12 月 9 日发布

• FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): 通过伪造的 SAML 消息绕过 FortiCloud SSO 登录身份验证（功能并非默认强制开启，但在实际环境中存在）。
• FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): SSL VPN 中会话过期时间不足（会话生命周期/密码更改边缘情况）。
• FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): 敏感信息最终出现在 REST API 日志中（如果激活了 REST API 日志记录）。
• FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): 管理员可以读取私钥（密钥管理错误，可通过补丁级别修复）。

2025 年 11 月 18 日发布

• FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): CAPWAP 守护进程堆栈缓冲区溢出。
• FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): 另一个 CAPWAP 守护进程堆栈缓冲区溢出。
• FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): 通过 SSH 绕过受信任的主机（CLI 边缘情况）。

是的，这很多。而且是的，你可以通过流程（补丁窗口、Staging、变更管理、维护窗口）来管理这些。

然后是硬币的另一面。

Sophos：没有头条新闻，但运维却火烧眉毛

对于 Sophos，我们当然也会谈论安全性。但现在真正消耗我们时间的只是 Bug。

我们在公司目前有太多不必要的工作，仅仅是因为防火墙总是出问题。在某个时候，你会发现自己问了一个实际上很荒谬的问题：

我更喜欢什么：一个存在安全漏洞但运行稳定的防火墙，还是一个没有大型 CVE 头条新闻但在重启后无法启动的防火墙？

这不是一场学术辩论。这是运维 (Operations)。遗憾的是，与一个客户因为日常 Bug 而导致整个网络瘫痪几个小时相比，我现在甚至更愿意面对一个也许某天会被利用的理论上的安全漏洞。

我们当前的痛点（是的，同时发生）

为了说清楚：这些仅仅是我们在过去几个月中在不同系统上多次遇到过的 Bug。当运维变成一个项目时，这令人精疲力竭和沮丧。尤其是当您再次陷入 Sophos 支持的旋转木马，而他们喜欢假装您是“全球唯一一个遇到此问题的客户”时。不，我们不是。

• 防火墙在重启后有时无法干净地启动。
• HA 集群崩溃或表现得像脑裂 (Split-Brain)。
• 日志记录突然变得不可靠（或完全消失）。
• Let’s Encrypt 证书无法续期，你必须在晚上手动处理。
• 接口丢失，或者突然在 GUI 中不再可见。
• SSD 损坏（硬件损坏）。
• WebAdmin 登录完全罢工 – 您无法再登录，通常只有重启才能解决。
• 接口突然从配置中完全消失。
• 日志磁盘已满，导致出现错误消息或受影响的服务直接停止。

社区的反馈（你并不孤单！）

如果您看看 Sophos 社区（截至 2026 年初），质量下降的景象可悲地与我们的经历相吻合。除了我们的问题外，其他用户在 v21.5 / v22 中遇到了更严重的阻碍：

• 损坏的 SSL VPN 配置文件（v22.0 Build 411）： 一些用户报告说，在升级到最新的 v22 后，创建 SSL VPN 配置文件失败。有时他们不得不回滚到 v21.5，因为新版本实在太多 Bug。
• 损坏的 SNAT / Web 服务器访问（v22.0 Build 365）： 有报告称更新后，从外部访问内部 Web 服务器中断。通常，互联网路由会完全罢工，直到手动将 SNAT 重置为默认的 MASQ 选项。
• CLI 垃圾信息 / “Invalid rule id”： 控制台中大量出现如 “Invalid rule id or family for update” 等警告。（这似乎“仅仅”是一个显示错误，但它毫无意义地淹没了日志）。

最痛苦的是：所有这些事情中的每一件都不仅仅是烦人，而是一个巨大的风险。如果日志丢失，你就像在盲飞。如果 HA 不稳定，你就会对故障转移失去信任。如果证书没有续期，你就会构建变通方法 (workarounds)。而变通方法就是日后发生事故的温床。

Sophos Bugs（v21.5 到 v22）：直击您的症状

我在这里特意列出了官方发布说明或官方记录的已知问题中的特定 NC-ID，以便您作为管理员可以清楚地跟踪此情况。

简而言之：症状 -> 说明里怎么写

一个来自运维的烦人故事

我们早上坐在那里做着你一直在做的事情：处理工单，规划变更，查看监控。

然后防火墙不敲门就来拜访了。

不是带着 CVE，也不是带着“Critical Advisory”。而是带着日常问题。

第一杯咖啡，第一次重启，脑子里在想：它还能起来吗？

如果一切顺利，它启动了。如果情况糟糕，它会落在“Failsafe”和“存活，但不处理流量”之间。当你还在想是否真的需要再次拿出控制台线时，下一章开始了。

HA（高可用性）。你的安全气囊。有时候感觉气囊在停车的时候就弹出来了。

然后是日志记录。我们都知道：如果你看不到发生了什么，你就无法控制它。突然日志不见了，报告是空的，或者一个服务下线了。你站在那里想，你现在是有安全问题、数据质量问题，还是两者兼有。

然后是压轴戏：WAF、反向代理、Let’s Encrypt。

你甚至不想搞得太花哨。你只希望证书能被续期，你的网站不要在凌晨 02:13 尖叫“connection refused”。

作为奖励，一个接口“消失”了。不是真的消失了，只是在 UI 中看不到了。流量可能甚至还在跑，但你无法看到你需要调试的东西。

在某个时候，你会问自己这个实际上很荒谬的问题：

我更喜欢什么：一个存在安全漏洞但运行稳定的防火墙，还是一个没有大型 CVE 头条新闻，但在运维层面每周都在我地板上烧出新洞的防火墙？

1) 启动、重启、升级：“它还活着，但不工作了”

如果防火墙在重启后无法干净地启动，这不仅仅是“正常运行时间 (Uptime)”的问题。这是一天的损失加上风险，因为在这种情况下，你往往会做你平时绝对不会做的事情。

来自 SFOS 21.5 发布说明的几个例子：

• 重启期间进入 Failsafe 模式: NC-151715 (Firmware Management): 辅助设备在重启期间进入 Failsafe 模式；重启失败。
• 升级后流量停止: NC-152641 (Firmware Management): 升级后（21.0 MR1 Build 237），不再处理任何流量（SWAP 内存配置更改）。
• 内核恐慌 (Kernel Panic): NC-123910 (Firewall): 内核恐慌问题。

是的：SFOS 22.0 引入了一个额外的升级因素：Sophos 在发布说明中指出，v22 带来了架构上的改变，在极少数情况下可能需要额外的手动步骤。这正是那种在运维中令人头疼的升级边缘情况。

2) HA：在停车时弹出的安全气囊

HA 是你的安全网。这正是为什么当边缘情况正好在那里爆发时，会如此痛苦。

摘自 SFOS 21.5 发布说明（节选）：

• HA 事件跟踪在同时重启时停止: NC-142962 (HA)。
• 被动节点上的固件上传挂起: NC-132291 (HA)。
• 故障转移导致重启循环: NC-147307 (HA)（在说明中明确提到，例如 XGS 2300）。
• 断电后同步失败: NC-147739 (HA)。
• HA 状态闪烁，专用链路上发生崩溃转储 (Crash Dump): NC-149039 (HA)。

3) 日志记录和报告：当您盲飞时

对我来说，这就是为什么“Bug”不仅仅是“运维”的真正原因。当日志记录/报告不稳定时，这是一个安全问题。

摘自 SFOS 21.5 发布说明（节选）：

• 日志/报告偶尔停止；Garner 频繁发生核心转储 (coredump): NC-158526 (Logging Framework)。
• Garner 和 fwcm-heartbeatd 停止: NC-160962 (Logging Framework)。
• 升级后：没有更多报告: NC-157663 (Logging Framework)。
• Log Viewer 由于数据库损坏丢失事件: NC-169237 (Logging Framework)。
• Syslog 文件描述符 (fd) 损坏，数据发送到错误的 FD: NC-135594 (Logging Framework)。

此外，您还会在 Sophos 已知问题列表 (KIL) 中找到一些在日常生活中同样痛苦的问题：

• 日志查看器未显示新数据（缺少 active.db）: NC-175936 (Logging Framework)。在某些 21.5.1 系统上，/tmp/eventlogs/ 下的 active.db 可能丢失。然后日志查看器会“冻结”，尽管流量和安全功能继续运行。根据 KIL，这在 v22 中得到了修复，并应包含在 21.5 MR2 修复程序中。
• HA 中的误报 “advanced threat detected” (检测到高级威胁): NC-170292 (Logging Framework)。Sophos Central 可以在 HA 部署中发送警报，在描述中包含原始日志。根据 KIL 的权宜之计：重启 Garner 服务。KBA: https://support.sophos.com/support/s/article/KBA-000043672
• ReportDB_v9 显示 STOPPED（看起来很戏剧性，但事实并非如此）: NC-166381 (Reporting)。升级到 v21.0 GA 或更高版本后，该服务会在非常特定的时间段后显示为 STOPPED。根据 KIL，这是预期的，并且没有运维影响，因为它只影响 v21 之前的旧版报告。

这就是“Sophos Central 因素”：如果您将 Central 用作单一管理平台 (Single Pane of Glass)，那么日志记录问题会带来双倍的痛苦。如果本地日志管道（Garner/DB）翻车，向 Central Firewall Reporting (CFR) 的上传也可能失败或挂起。无论如何，CFR 并不总是“实时”的。这意味着：在最坏的情况下，您不仅缺少本地日志，而且还缺少了您实际上想在日常生活中依赖的中央视图。

4) WAF 和 Let’s Encrypt：公共服务，但请不要有戏剧性

当证书未更新并且反向代理失控时，这不是一个“小 Bug”。这是直接的客户影响 (Customer Impact)。

在 SFOS 21.5 发布说明中，您会发现有关 WAF/Let’s Encrypt 的一大家子问题：

• Let’s Encrypt 证书创建失败: NC-148937 (WAF)。
• LE 请求失败，因为缺少自动防火墙规则 (Auto-Firewall-Rule): NC-152022 (WAF)。
• 无效的 LE 配置导致反向代理不断重启: NC-140663 (WAF)。
• ACME 不为 IP 颁发证书: NC-141062 (WAF)。
• WAF 规则自动打开/关闭: NC-152540 (WAF)。

然后是“看起来像 Bug，但却是安全权衡”的话题。来自 KIL 的示例：

• URL 中编码的斜杠 (%2F)：WAF 返回 404: NC-159041 (WAF)。如果您的应用程序在 URL 中使用编码的斜杠，Apache 默认情况下会阻止此操作（指令 AllowEncodedSlashes 默认为 No），您会看到 404，尽管后端“实际上”具有该路径。背景：编码的斜杠可以绕过路径限制（经典示例：.../something%2F..%2Fadmin）。详细信息: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

如果您想知道它在现场是什么样子的：在这个社区帖子中，有人描述说在升级到 21.5.x 后，自动续订的证书“消失”了，WAF 没有启动，网站因 ERR_CONNECTION_REFUSED 而死掉。最终的解决方案是：清理 Web 保护规则并删除损坏的 LE CSR，之后它再次运行。（帖子：升级后 WAF/Let’s Encrypt 故障，ERR_CONNECTION_REFUSED）。

有时它甚至不是一个“Bug”，而是一个流程问题：在 Sophos 社区中，也有 Let’s Encrypt 服务条款在 WebAdmin 中被标记为过期，必须再次接受的情况。（帖子：Let’s Encrypt 服务条款已过期）。

来自已知问题列表的另一个“升级陷阱”经典案例：如果已有的内置证书与 CA 存储中新引入的 Let’s Encrypt 证书名称相同，则升级可能会失败（NC-146082）。

5) “接口缺失”（或者只是隐身了）

这种 Bug 在发布说明中听起来干巴巴的，但在实践中却迫使你盲飞。

官方记录为已知问题 (Known Issue)：

如果 SFOS 21.5 GA 及更高版本中的物理或逻辑接口具有以 10 个或更多数字结尾的名称（注释中的示例：VLAN_1234567890），则物理接口在 WebAdmin 的网络 > 接口下不可见，或者逻辑接口无法展开。重要提示：根据发布说明，功能不受影响，仅 WebAdmin 控制台中的显示受到影响。

中期结论（到目前为止）：启动/升级、HA、日志/报告、WAF/Let’s Encrypt 甚至 UI 都可能同时让您绊倒。从这里开始，这些主题最初看起来像是“网络细节”，但在运维上同样昂贵：Entra SSO、VPN 互操作性和看似随机的流量丢弃。

6) 身份/SSO (Entra) 和 Captive Portal：当访问似乎是“随机的”

这类 Bug 在运维中特别险恶：对用户来说，看起来像是“我的账户出问题了”。对你来说，看起来像是“那只是 SSO 的问题”。实际上，很多时候是中间的防火墙在捣鬼。

如果 Microsoft Entra ID (Azure AD) 在您的环境组合中，KIL 中的一些未解决问题：

• Sophos Connect VPN：未完全支持条件访问 (Conditional Access): NC-167126 (Authentication)。在首次登录时的初始 MFA 质询之后，条件访问检查不一定在每次后续连接时触发。根据 KIL 的说法，在用户在 Sophos Connect Client 中手动注销之前，不会再次执行策略实施。
• VPN SSO：UPN 和电子邮件不同，登录中断: NC-157635 (Authentication)。如果 Entra 中的电子邮件 ID 和 UPN 不同，用户可以访问 VPN 门户，但无法访问 SSL VPN 或 IPsec 门户。根据 KIL 的原因：OAuth 标头提供电子邮件，然后将其解释为 UPN。
• Captive Portal：Entra SSO 用户需要在规则中加入 Primary Group (主组): NC-167130 (Authentication)。只有当您在防火墙规则匹配中使用主组时，互联网访问才有效（次要组在此处不计算在内）。根据 KIL 的修复将在“下一次维护版本”中进行；权宜之计：显式匹配主组或使用基于用户的规则。
• 使用 Entra SSO 时偶尔出现 “no permission” (无权限) 错误: NC-167128 (Authentication)。当并行使用 Entra ID Auth 和 On-Prem AD Auth 时（Token 复用），可能会发生这种情况。根据 KIL 的权宜之计：清除浏览器 Cookie 或在 Sophos Connect Client 中“强制重新登录”。或者，一致地使用一种身份验证方法。

7) VPN/IPsec 互操作性：升级通常因为“对手”而失败

两个 KIL 主题不仅仅从 21.5 开始，但在 21.5/v22 中仍然相关，只要您在现场有旧客户端或远程节点：

• IPsec IKEv2：隧道无法启动 (分片/PMTU): NC-136352 (IPsec)。从 20.0 MR1 开始，默认的 IKEv2 配置文件可以生成更大的数据包（更多的默认字段），有时超过 1500 字节。如果路径上的分片/PMTU 较差（分片被丢弃），则 S2S 隧道不会启动。根据 KIL 的缓解措施：减少 IPsec 配置文件中的 DH 组（最小为 4），或准确配置远程对等体使用的组。
• SSL VPN/OpenVPN 2.6.0：与 EoL 客户端/UTM9 不兼容: NC-128116 (SSLVPN)。从 20.0 MR1 开始，OpenVPN 更新至 2.6.0。这会破坏与旧 SFOS 版本（18.5 及更早版本）、旧版 SSL VPN 客户端 (EoL) 和 UTM9 操作系统等的站点到站点 SSL VPN。根据 KIL 的建议：升级双方或切换到 IPsec/RED；远程设备：使用 Sophos Connect 或当前的 OpenVPN 客户端。

8) 没有规则命中的流量丢弃：Accurate ECN 作为一个讨厌的原因

当流量似乎“随机”丢弃时，您首先检查的是规则、IPS、TLS 检查和路由。在固件升级后，还会增加一个经典情况：IPS 引擎 (Snort) 或签名变得更加严格，阻止了合法流量，而您没有立即在日志中找到明确的事件。然后您花几个小时调试“路由”或“规则”，尽管最终它是策略或调优 (Tuning) 工作。

然而，KIL 也有一个候选者，如果你没有把它放在雷达上，它可以让你忙很长时间：

• 流量因 Accurate ECN Bits 被丢弃: NC-169842 (Firewall)。Accurate ECN 以不同的方式设置 TCP 位 (ECE/CWR/NS) (RFC 7560)。根据 KIL，内核将其解释为“设置了保留位 (reserved bit set)”并丢弃流量。为了缩小范围，查看客户端端有所帮助：在实践中，这可能在较新的 Linux 内核或 Apple 客户端中更容易注意到，因为它们倾向于更积极地使用 RFC 7560/Accurate ECN（“为什么只有 MacBooks 掉线？”）。RFC: https://www.rfc-editor.org/rfc/rfc7560

9) v22 GA Re-Release Build 411：为什么首先需要它

2026 年 1 月 20 日，Sophos 推出了 v22 GA 作为重新发布 (Build 411)，以修复“罕见且孤立的问题”。该列表读起来就像是“在变更窗口期进行不必要的工作”的精选集（来源：关于 Re-Release 的 Sophos 社区博文）：

• NC-171003: 带有 VLAN 过滤的 Bridge 接口无法访问 WebAdmin。
• NC-170987: CLI 垃圾日志 “Invalid rule id or family for update”。
• NC-170970: 如果 DNAT 规则具有特定的出站接口 (outbound interface)，则 DNAT 流量会失败。
• NC-171600: SSL/TLS Widget 和会话图表 (Session Chart) 数据不正确/为空。
• NC-172197: 无法添加任何 SNMP 配置。

博文: v22 GA re-release (Build 411) is now available。

真正的损害：Bugs 使安全性变得更加昂贵

重点不在于“Bug 比 CVE 更糟糕”，反之亦然。

重点是：当您的运维环境不稳定时，安全性会自动下降。

• 您推迟升级，因为您害怕下一个回归缺陷 (Regression-Bug)。
• 您禁用功能（“我们现在不需要那个”），因为它们会造成压力。
• 您失去了可观察性（日志），这意味着降低了响应速度。
• 您将时间投资于救火，而不是分段、备份和编写清晰的规则。

在实践中完全被低估的一点是：解决时间 (Time-to-Resolution)。对于 CVE，您通常有警告 (Advisory)、缓解措施和修复程序。对于 Bug，举证责任很快落在了管理员身上：tcpdump、CTR 日志、Advanced Shell 导出、“您尝试过重启吗？” - 与此同时，生产环境正在燃烧。只有在那之后，您才会进入支持轮盘：升级问题，等待热修复 (Hotfix) 或下一个 MR。这会消耗您未曾计划的额外运维时间。

这正是为什么“宁愿有漏洞，但要稳定？”这个问题虽然很人性化，但实际上是一条死胡同的原因：

不仅“漏洞”是安全问题。“不稳定的防火墙”也是一个安全问题。

我们从中带走了什么（为了不让情况完全失控）

一些能帮助我们限制疯狂，而无需每周重新发明轮子的事情：

升级起飞前检查 (Upgrade-Preflight)（开始之前）

• 像对待恢复 (Restore) 一样对待备份 (Backups)：导出配置，离线备份，至少测试过一次恢复。
• HA 状态“绿色”还不够 – 请测试故障转移！ 根据 GUI，我们的同步 (Sync) 没问题，心跳 (Heartbeat) 也干净。但在紧急情况下，辅助设备 (Auxiliary Appliance) 仍然没有干净地接管故障转移。WebAdmin 中的绿色勾号目前可悲地无法保证在变更窗口期 (Change-Window) 一切正常。
• 验证日志记录：外部 Syslog/Collector 接收到事件，没有间隙，时间/NTP 正确。
• 检查证书/WAF：过期日期，Let’s Encrypt 验证，将回退证书 (Fallback-Zertifikat) 作为 B 计划。
• 真正测试 SSO/VPN：Entra 登录、Captive Portal、Sophos Connect、SSL VPN、IPsec S2S（包括故障转移）都有自己的测试用例。
• 准备好打破玻璃 (Break-Glass)：控制台/带外 (Out-of-band) 访问，本地管理员，用于回滚的固件映像。
• 不要忘记双启动 (Dual-Boot)（也不要高估它）：Sophos 有两个固件分区。如果升级出错，回滚到 21.5 通常只需重启并选择另一个分区即可。但是：也有第二分区同样无法干净启动的情况，那时只有重新映像 (Reimage) 才能解决（感觉支持部门非常快就会要求这样做）。甚至 Reimage 也不总能解决根本原因。

在升级期间（如果涉及 HA）

• 首先是被动/辅助节点 (Passive/Secondary)，然后是故障转移，然后是主动节点 (Active)。
• 在每一步之后简要验证：流量、VPN、DNS、日志记录、WAF/反向代理。

在日常运维中

• 测试 HA，而不仅仅是配置它：故障转移演练 (Failover-Drills)，并明确何时拆分集群的标准。
• 将日志记录视为产品：针对日志间隙发出警报，服务运行状况 (Service Health)，如果 UI 出现问题，准备好通过 CLI 进行紧急导出。
• 主动监控证书：续订不是“有了更好 (nice to have)”，而是运维风险。像对待变更 (Changes) 一样对待 ToS 更改。
• Health Check 仅作为提示，而不是 KPI：在 v22 中，Sophos 引入了健康检查 (Health Check)（详见我的文章 Sophos Firewall v22 Health Check - 完整概览 ）。作为最佳实践清单，这很好，但有时感觉像是在“把生态系统开关拨到绿色”。实践中的例子：许多人激活登录免责声明仅仅是为了在健康检查中获得绿色勾号。然而，我在那里缺少的是硬性的运维指标，比如“日志/报告数据库健康吗？”或“SSD 状况如何？”——特别是因为一些设备出现存储问题的速度比预期的要快。

结论：当工具变成风险时

说到底，我们都在同一条船上。我们管理着关键的基础设施，必须能够相信那些本应保护我们免受混乱影响的工具，它们自己不会造成混乱。鉴于当前的固件质量（v21.5 / v22），Sophos 显然还有大量的功课要做。对于“稳定版本”的信任，在我们和社区的许多其他人心中，已经受到了严重的打击。

我不想要一个“要么安全，要么稳定”的防火墙。我想要——不，我需要——一个两者兼具的防火墙。

在 Sophos 控制住这些质量缺陷之前，我们在运维中只有一个选择：我们必须变得更加自律，不再在意 UI 中的“绿色勾号”，并在部署规划中像对待关键的 CVE 一样认真地对待这些平凡的 Bug。

下次见，
Joe

来源

• Fortinet PSIRT 报告
• Sophos Firewall v21.5 发布说明
• Sophos Firewall v22.0 发布说明
• Sophos KIL (已知问题 Known issues)
• Sophos 社区：v22 GA re-release Build 411
• Sophos 社区帖子 (Let’s Encrypt/WAF)
• Sophos 社区帖子 (Let’s Encrypt 服务条款 ToS)
• Apache 文档: AllowEncodedSlashes
• Sophos 知识库 KBA (Garner 误报高级威胁)
• RFC 7560 (Accurate ECN)