Cisco IOS XE 暴露了管理平面暴露于互联网的问责问题

摘要

• 已确认的公开记录：思科披露了 IOS XE 软件 Web UI 功能正被活跃利用，并随后确认攻击者利用了两个此前未知的漏洞：CVE-2023-20198 用于初始访问和创建权限为 15 的账户，随后利用 CVE-2023-20273 提升至 root 权限并将后门写入文件系统。（思科安全公告）
• 政府指南：CISA 表示，这两个漏洞影响 IOS XE Web UI，可能允许未经身份验证的远程攻击者控制受影响的系统；CISA 敦促组织在面向互联网的系统上禁用 HTTP 服务器功能，搜寻恶意活动，并在修复软件可用时进行升级。（CISA 指南）
• 管理平面问题：公开记录支持以下结论：这是一个涉及暴露的 Web 管理、账户创建、命令注入和植入后门的控制面故障。但记录不支持声称所有 IOS XE 设备都受影响、所有暴露的设备都已被攻陷，或思科独自控制着每个客户的互联网暴露面。
• 评估：攻击者控制了漏洞利用。思科控制了产品代码、公告内容、修复交付、安全加固指南和检测支持。客户、MSP 和公共机构控制了暴露面、资产清单、配置、网络分段、监控和恢复纪律。该事件将“Web UI 是否已暴露在互联网上？”变成了董事会层面的业务连续性议题。

网络设备是控制点，而不仅仅是另一台服务器

Cisco IOS XE Web UI 事件之所以重要，是因为路由器、交换机或无线控制器不仅仅是一种工作负载，它是其他工作负载的控制点。被攻陷的网络设备可能位于身份验证、流量路由、网络分段、分支机构连接、无线接入、语音、监控和事件响应本身的路径中。当管理平面被攻陷波及此类设备时，恢复问题不仅仅是 CVE 是否已被修补，而是设备是否仍可被信任来描述、实施和保护其周围的网络。

思科的安全公告将该事件定位在 IOS XE 软件的 Web UI 功能中，并明确表示攻击链涉及活跃利用。攻击者首先使用 CVE-2023-20198 获得初始访问权限，并执行权限 15 的命令，创建本地用户和密码组合。然后，攻击者利用 Web UI 功能的另一个组件 CVE-2023-20273，使用新创建的本地用户将权限提升至 root，并将后门程序写入文件系统。思科为 CVE-2023-20198 分配了 CVSS 10.0 分，为 CVE-2023-20273 分配了 7.2 分。（思科安全公告）

CISA 的公开指南将同样的事实转化为运营紧急程度。CISA 描述了针对影响 Cisco IOS XE 软件 Web UI 的 CVE-2023-20198 和 CVE-2023-20273 进行的活跃且广泛的利用，并表示未经身份验证的远程攻击者可以利用这些漏洞来控制受影响的系统，要求运行 IOS XE Web UI 的组织实施思科的缓解措施，包括在面向互联网的系统上禁用 HTTP 服务器功能，并搜寻恶意活动。（CISA 指南）

管理平面方面的区别在于，这不仅仅是漏洞事件，更是责任归属事件。普通 Web 服务器中的应用程序漏洞可能很严重；而用于引导数据包和执行策略的设备管理界面的漏洞则是一种控制平面风险。攻击者不仅仅是窃取单个应用程序的数据，还可能获得一个观察、篡改、持久化或准备进一步访问网络可信设备的位置。

这并不意味着所有受影响的设备都被用于流量拦截或破坏性操作。公开的主要记录并不支持这种普遍的论断。思科和 CISA 记录了账户创建、root 权限提升和植入后门程序的利用模式。需要追责的问题是，这种访问权限可能意味着什么，以及在操作人员能够重新信任设备之前需要哪些证据。

对于许多组织，尤其是网络团队精简的中小企业和公共机构来说，管理界面在历史上一直是实用的便利工具。Web UI 管理可能使远程配置更加容易，MSP 可能将其用于客户支持，分支机构团队可能在部署后仍保持其可访问。最初作为便利工具的控制措施，如果暴露面未被持续盘点和限制，就可能变成面向互联网的攻击面。

思科在修复工作仍在进行时披露了攻击链

公开的事件时间表很重要，因为漏洞利用、缓解措施和修复版本的发布并非一气呵成。思科最初警告存在活跃利用，并建议采取防御措施，包括在面向互联网的系统上禁用 HTTP 服务器功能。后续的公告更新添加了第二个 CVE、修复版本信息和软件检查工具。CISA 的页面更新了多个 IOS XE 版本的修复版本可用性信息，并将操作人员引向思科的公告和修复文档。（思科公告，CISA 指南）

这一序列创造了一个实际的责任窗口期。当漏洞利用活跃且完整的修复矩阵仍在构建时，缓解工作的重心急剧转移到减少暴露面和检测上。如果管理界面可访问，操作人员无法等待完美的补丁计划，而必须禁用或限制面向互联网的 HTTP/HTTPS 服务器功能，搜寻新创建或不明来源的用户，检查指标，保存证据，并判断设备是否可能已被攻陷。

思科随后发布的软件修复可用性文档为操作人员提供了一种更具体的方式，将 Bug ID CSCwh87343 映射到 IOS XE 的修复版本。CISA 在 11 月 1 日的更新中列出了 17.9、17.6、17.3 和 16.12 等版本系列中针对特定 Catalyst 3650 和 3850 设备的修复版本。这一区别很重要：在早期的利用窗口期，最重要的控制措施可能是“立即关闭管理平面的暴露”。而在修复版本发布后，控制措施则变为“升级、验证、搜寻和恢复”。（思科修复可用性，思科软件检查器）

国家漏洞数据库的条目和 CVE 记录为这些漏洞提供了额外的公开锚点。NVD 的 CVE-2023-20198 页面引用了思科公告并描述了活跃利用的背景。CVE.org 记录将漏洞标识符作为公开漏洞记录的一部分保存。（NVD CVE-2023-20198，NVD CVE-2023-20273，CVE 记录 CVE-2023-20198，CVE 记录 CVE-2023-20273）

该攻击链也表明了仅凭 CVSS 评分不足以进行治理。CVE-2023-20198 的 10.0 分表明了技术严重性，但业务风险因暴露面、设备角色和恢复能力而异。一台面向互联网、日志记录薄弱且没有已知干净镜像的分支路由器，与一台在管理 VPN 控制下的内部实验室设备，所带来的运营问题截然不同。严重性提醒领导层需要关注，而资产清单和暴露面证据则告诉领导层该优先做什么。

互联网暴露是后果放大器

最重要的由操作人员控制的变量是 Web UI 管理表面是否可从互联网访问。思科和 CISA 的缓解措施核心在于禁用面向互联网系统的 HTTP 服务器功能。思科的安全加固指南与此控制措施一致：思科的 IOS 和 IOS XE 安全加固材料指出，可以使用no ip http server禁用 HTTP 服务器，使用no ip http secure-server禁用安全 HTTP 服务器。（思科 IOS XE 软件安全加固指南，思科 IOS 设备加固指南）

这并非新的安全原则。除非有充分、受监控、受限制且有文档记录的理由，管理界面不应广泛暴露于互联网。CISA 关于互联网暴露管理界面的约束性操作指令 BOD 23-02 要求联邦民事机构降低暴露管理界面的风险，其建议在联邦边界之外也具有更广泛的意义。（CISA BOD 23-02）

问题在于，真实的网络会累积例外。合并期间部署的设备保留旧的访问规则；MSP 为紧急故障排除打开管理路径后从未关闭；分支办公室继承的模板启用了 HTTP；公网 IP 变更所有权；为临时迁移设置的防火墙规则成为永久规则。Web UI 暴露不一定是因为某个工程师做出了鲁莽的决定，而是因为资产清单、变更控制和托管服务交接未能跟上网络的历史演变。

这种历史对于追责很重要。思科控制了产品漏洞是否存在以及诊断和修复的速度。客户控制了脆弱的管理表面是否可访问。MSP 控制了许多客户的配置。公共机构控制了自己的资产清单和紧急禁用流程。攻击者利用了可访问的系统。责任归属应遵循这些控制点，而不是简单地归结为一句话。

对于中小企业而言，暴露问题尤其困难。小型组织可能依赖托管服务提供商进行网络设备配置，可能不知道 IOS XE Web UI 是否启用、暴露、内部限制或未使用，可能不知道运行的是哪个版本系列、是否有修复软件可用，或者是否出现了不明来源的本地用户。当 CISA 要求禁用面向互联网系统的 HTTP 服务器功能并搜寻恶意活动时，中小企业可能需要其提供商将这些要求转化为具体的设备检查和证据。

这就是为什么该事件不仅关乎思科和大型企业。它是对托管网络支持经济体系的一次考验。如果 MSP 能够集中管理客户网络，他们也必须集中进行准确的暴露面清单管理、快速缓解和恢复证明。如果设备在打补丁前可能存在 root 级别的后门，客户就不能认为“我们已经打补丁了”就足够了。

后门程序将打补丁转变为恢复

公开事实包括植入后门程序，这改变了工作性质。当漏洞仅允许未经身份验证的账户创建时，在某些情况下，删除账户并打补丁可能就足够了。但当攻击链包括 root 权限提升和将后门写入文件系统时，操作人员必须将受影响的设备视为可能已被攻陷的系统，需要进行取证分类和恢复验证。

CISA 的指南指引组织搜寻恶意活动，并引用了 Cisco Talos 的检测方法。Cisco Talos 博客是一个关键的公开检测来源，尽管对该页面的自动化访问受到限制；CISA 引用了其中的实用建议：组织应在设备上查找不明来源或新创建的用户，作为可能存在恶意活动的证据。（Cisco Talos 博客，CISA 指南）

“新创建的用户”这个短语听起来可能很普通。但在网络设备上，情况并非如此。通过漏洞利用创建的具有特权的本地用户可能会逃过粗略审查，被重新用于后续访问，或提供篡改证据。Root 级别的命令执行会引发更深层次的问题，涉及配置完整性、文件系统状态、启动映像、持久化、日志以及设备自身的遥测是否可信。

打补丁关闭了已知的漏洞路径，但并不能自动证明被攻陷的设备没有残留的后门、未经授权的账户、被篡改的配置或隐藏的持久化。因此，恢复证据需要多个层面：确认 Web UI 是否启用；确定其是否可从互联网访问；检查可疑用户和指标；尽可能收集并保存日志；删除未经授权的账户；升级到修复软件；比较运行配置和启动配置；验证镜像完整性；在怀疑被攻陷时重建或重装系统；以及在恢复服务后进行监控。

NIST 的事件处理指南在这里很有用，因为它将恢复视为一个阶段，而非一个复选框。检测、遏制、根除和恢复是相关的，但并不等同。设备可以在仍在收集证据时打补丁，可以在仍在加强监控时恢复服务，可以从漏洞管理的角度被视为“已修复”，但从事件响应的角度看仍未解决。（NIST SP 800-61 Rev. 2）

这种区别应当影响向董事会报告的内容。一份报告说“所有设备都已打补丁”可能在技术上是正确的，但仍然不完整。领导层需要知道有多少设备启用了脆弱的功能，有多少暴露在互联网上，有多少显示了受攻击的指标，有多少被重建，有多少存在未经授权的用户，是否有任何日志不可用，以及托管服务客户是否收到了证据。这些是恢复指标，而不仅仅是补丁指标。

检测证据在设计上就存在不均衡

网络设备通常被视为真相的来源。它们生成日志、执行 ACL、路由流量并报告状态。但在管理平面被攻陷的情况下，这种假设就减弱了。如果攻击者可以创建用户并以高权限执行命令，设备自身的记录可能是不完整、被篡改或缺失的。操作人员可能需要外部证据：NetFlow、防火墙日志、SIEM 记录、配置备份、带外管理日志、TACACS 或 RADIUS 日志、类似 EDR 的网络遥测，以及与已知可信配置的比较。

这就是清单中提到的“网络资源证据”问题。受影响资源不仅是承载证据的，还是可能塑造证据的。如果路由器或交换机本应是日志生成的位置，而该设备已被攻陷，那么证据的质量就取决于日志在事件发生前是否已被导出并受到保护。设备上的本地日志缓冲区可能有用但脆弱。集中式日志和 AAA 记录变得重要得多。

CISA 的已知被利用漏洞目录也是一种证据基础设施。将 CVE-2023-20198 及相关被利用漏洞列入目录，向机构和操作人员发出优先级信号，表明该问题并非理论上的。KEV 目录和 BOD 22-01 为联邦机构建立了修复已知被利用漏洞的流程，许多私营组织也使用该目录作为分类信号。（CISA 已知被利用漏洞目录，CISA BOD 22-01）

然而，KEV 的收录并不能告诉操作人员其设备是否已被攻陷。它告诉操作人员存在已知的利用，应优先修复。操作人员仍然需要回答本地证据问题：该功能是否启用？是否可访问？是否被探测过？是否创建了用户？后门是否存在？是否安装了修复软件？设备是否被重建？下游路由、ACL 或凭据是否被更改？

凭据证据尤其重要。如果攻击者创建了本地账户，设备可能也已访问了 AAA 服务器、SNMP 社区字符串、网络管理系统、自动化凭据、备份存储库或配置档案。公开的思科和 CISA 公告并未说明所有此类下游系统均被访问。但它们确实提供了一个合理的理由，需要验证设备本地的攻陷是否可能暴露了更广泛的管理凭据或信任关系。

对于使用集中式身份验证的组织，本地账户应被视为异常。对于混合了本地应急账户和外部 AAA 的组织，调查会更困难。如果命名规则、文档记录和定期审查薄弱，可疑账户可能隐藏在合法的应急账户之中。因此，该事件奖励了那些基础的治理工作：唯一账户、AAA 日志记录、配置基线、定期备份、最小权限和清晰的资产清单。

思科的角色远不止编写补丁

思科的责任包括产品漏洞，但不仅限于此。网络操作软件供应商控制着安全设计、代码审查、默认配置态势、公告清晰度、修复交付、软件兼容性、检测指南、TAC 容量、安全加固文档以及客户识别受影响版本的能力。在此次事件中，思科披露了攻击链，确定了两个 CVE，提供了建议，发布了修复版本信息，并维护了安全加固指南。

修复矩阵之所以重要，是因为 IOS XE 并非单台设备上的单一版本。大型网络可能包含不同的版本系列、硬件系列、支持合同、运营限制和维护窗口。“立即打补丁”的指令方向正确，但在运营上是不完整的。客户需要知道哪些镜像已修复，哪些 SMU 可用，哪些版本系列仍受支持，哪些设备需要升级，以及升级是否有停机风险。思科的修复可用性文档和软件检查工具有助于实现这种转换。（思科修复可用性，思科软件检查器）

公告的清晰度与修复可用性同等重要。在活跃利用期间，公告必须告诉操作人员应禁用哪些功能、应查找什么、哪些受影响、哪些不受影响、是否存在变通方案、修复软件何时可用，以及如何解读指标。思科的公告不仅仅分配了 CVE 编号，还解释了从初始访问到本地用户创建，再到 root 权限提升和植入后门的观察到的攻击链。正是这类信息将响应从常规打补丁转变为攻陷评估。

供应商的默认设置是一个合理但需谨慎提出的问题。仅仅询问 Web UI 是否存在是不够的。管理功能通常是有合法理由存在的。更好的问题是，产品和文档是否使不安全的暴露难以发生、易于察觉或产生告警。如果启用了 HTTP/HTTPS 管理服务器，操作人员能否轻松看到它是否可从不可信网络访问？模板和向导是否默认偏向最小暴露？警告是否明确说明面向互联网的管理是危险的？遥测是否显示互联网暴露？软件是否帮助操作人员禁用未使用的管理服务？

思科的安全加固文档建议减少管理平面的暴露面，这很有用。但安全加固文档与部署压力、既有配置以及“上次能用”的运营习惯相竞争。安全设计理念越来越期望供应商让安全路径比暴露路径更容易。CISA 的安全设计指南指出，技术制造商应更多地承担起客户安全结果的责任，而不仅仅是发布安全加固检查清单。（CISA 安全设计）

将这一原则应用到这里，并不意味着思科要对每一个暴露的设备负全责。但它确实提出了一个问题：网络产品是否可以做更多的工作来揭示管理暴露面、阻止互联网可达性、减少对部署后安全加固的依赖，并帮助操作人员证明当前状态。指南中的警告与产品中的控制措施不是一回事。

客户和 MSP 的责任不能外包给思科

客户控制了决定影响范围的许多变量。他们决定或继承了 Web UI 是否启用、HTTP/HTTPS 管理是否可从互联网访问、管理访问是否限制在 VPN 或专用网络、配置是否备份、日志是否集中、本地用户账户是否定期审查，以及脆弱设备是否能被快速发现。

托管服务提供商为许多客户控制了这些变量，这使 MSP 的角色至关重要。如果 MSP 管理客户的网络设备，它就应维护准确的设备清单、版本清单、管理暴露面清单、AAA 模型、备份状态、日志状态和紧急缓解预案。当思科发布安全公告时，提供商不应从询问哪些客户可能暴露了该功能开始，而应该已经心中有数。

对中小企业业务连续性的影响源于这种依赖。小型制造商、诊所、学校、本地零售商或专业服务公司在经历网络设备被攻陷时，可能面临停机、不确定性或紧急承包商费用。它们可能没有内部专业知识来评估 IOS XE 版本系列或攻陷指标。如果其 MSP 不能提供证据，客户就只能在信任和高昂的第三方评估之间左右为难。

这种不确定性甚至在任何恶意流量操纵发生之前就可能成为业务中断的原因。客户可能需要安排紧急维护、更换设备、轮换凭据、审查日志、通知领导层、暂停远程管理或安抚审计师。对于中小企业来说，这些成本相对于员工容量可能很高。脆弱产品是企业级的这一事实，并不意味着每个受影响的运营商都具备企业级的响应能力。

合同应反映这一现实。托管网络合同应说明谁负责维护暴露面清单、谁接收供应商公告、谁可以禁用面向互联网的管理、谁批准紧急变更、谁保存证据、谁向客户报告指标、谁为紧急重建付费，以及客户在事件结束后收到哪些证据。如果没有这些条款，像 IOS XE 这样的事件就会演变成供应商、MSP、客户、保险公司和审计师之间的混乱应对。

公共机构也有类似的义务。它们往往运营着分布式的网络，面临遗留设备、采购限制和维护窗口的挑战。如果路由、无线、紧急通信、学校网络或市政服务降级，它们也可能面临公共服务后果。联邦的 BOD 并不自动适用于每个地方或外国公共实体，但其原则是可以借鉴的：了解暴露的管理界面，优先修复已知被利用漏洞，并记录补救措施。（CISA BOD 23-02，CISA KEV 目录）

国际公告显示出共同的依赖

IOS XE 事件是全球性的，因为思科设备遍布全球。美国以外的政府网络机构发布或转发了相关警告。澳大利亚网络安全中心警告称，利用该漏洞可能允许远程未经身份验证的用户在脆弱的系统上创建高权限账户并控制该系统。加拿大网络安全中心发布了跟踪思科公告和修复可用性的更新。（澳大利亚网络安全中心警报，加拿大网络安全中心公告）

这些公告之所以重要，是因为网络设备漏洞跨越国界的速度比采购系统更快。一家跨国公司、一家区域 ISP、一个学校网络和一个市政机构都可能以不同的方式运行 IOS XE，使用不同的版本系列和支持合同。同一份公告在不同的环境中变成了不同的运营问题。

国际上的广泛传播也降低了将事件视为某个供应商的私人客户通知的可能性。当多个国家机构告诉运营商采取行动时，该问题就成为了公共基础设施卫生的一部分。这具有责任归属的后果：在思科、CISA 和其他网络安全机构发布指南后，董事会和公共行政人员无法再以风险不明确为由推卸责任。

同时，全球公告并不能解决本地的执行问题。一个机构页面无法登录客户的网络设备、禁用 Web UI、审查本地用户、安装修复软件或重建受攻陷的设备。它只能提高信号的强度。最后一公里的工作仍然属于资产所有者及其提供商。

因此，该事件展示了一种常见的非对称性：警告是全球性的，但恢复是本地的。思科可以发布修复程序，CISA 可以发布指南，国家机构可以传播信息，研究人员可以扫描互联网。但一个学区、中小企业或公共机构仍然需要知道自己拥有哪些设备、谁在管理它们、如何关闭暴露面、可接受的停机窗口是什么，以及什么样的清理证据才能让其自身的风险决策满意。

操作人员本应保存的完整恢复记录

一份可辩护的 IOS XE Web UI 事件恢复记录应该比“已打补丁”更具体。它应从资产清单开始：所有 IOS XE 设备、型号、版本系列、角色、管理地址、管理访问路径、Web UI 状态、互联网暴露状态和负责的所有者。然后应记录缓解措施：适当时禁用或限制 HTTP 和 HTTPS 服务器、应用访问控制、确定修复软件、安排维护窗口，并批准紧急例外情况。

接下来是攻陷评估。操作人员应记录每台设备是否出现不明来源或新创建的用户、是否存在已知指标、日志是否显示可疑访问、AAA 记录是否与预期管理活动一致、配置更改是否看似未经授权，以及设备是否必须重建。记录应区分“未受漏洞影响”“受影响但未暴露”“暴露但未发现指标”“暴露且发现指标”和“确认已被攻陷”等不同状态。

随后是恢复步骤。应记录修复软件版本、镜像来源、校验和或完整性验证、配置备份比对、删除未经授权的用户、凭据轮换、AAA 审查、SNMP 和自动化凭据审查、日志验证以及变更后监控。对于高价值设备，当怀疑存在攻陷时，从可信介质重建可能比在原位清理更可信。

最后，还应有面向客户和领导层的沟通。高管需要一份将技术状态与业务风险联系起来的摘要。MSP 的客户需要针对具体设备的证据，而不仅仅是一个通用的公告链接。公共机构需要一份适合审计师、保险公司和监管机构查阅的记录。一次良好的恢复与一次薄弱的恢复之间的区别，往往在于紧急情况过后保留的证据。

NIST 的补丁管理指南强调，漏洞修复是一个受管理的生命周期，而非一次性的动作。组织需要资产清单、优先级排序、测试、部署和验证。在一次活跃利用的网络设备事件中，这个生命周期被压缩了，但并未消失。（NIST SP 800-40 Rev. 4）

该事件还表明，需要进行定期的暴露面测试。每季度或持续检查互联网暴露的管理服务本可以减少意外。配置管理系统如果在面向互联网的设备上标记ip http server或ip http secure-server，本可以缩短响应时间。集中式 AAA 本可以让异常的本地用户更容易被发现。这些并不是奇特的控件，而是那些只有在缺失时才会被大声疾呼的静默控制措施。

配置来源应在该记录中占有一席之地。网络设备可能通过漏洞扫描，但仍然运行着来源不明的配置。操作人员应知道运行配置是来自标准模板、紧急变更、MSP 例外、接管的网络还是一线管理员的临时修复。在 IOS XE 案例中，来源可以解释为什么 Web UI 会被启用并可访问。没有这个背景，补救措施可能关闭了眼前的暴露面，却让组织容易在下一次模板推送或替换设备时再次出现同样的问题。

提供商的证据同样应具体。MSP 应能够向客户提供一份带有日期的受影响和未受影响设备清单、缓解前的暴露状态、用于关闭管理表面的命令或配置变更、目标修复软件版本、攻陷评估结果，以及任何剩余例外情况。客户不需要每个数据包捕获或敏感的凭据细节，但确实需要足够的证据来决定是否需要进行业务连续性、网络安全保险通知、审计师沟通或客户通告。一份“思科设备已审查”的笼统声明与一份恢复记录不是一回事。

该记录还应指明在事件发生前是谁批准了暴露状态。在许多网络中，管理界面变得可访问是因为旧的例外情况、临时的故障排除变更、继承自前任的模板，或是悄悄将广泛访问标准化的外包支持模式。零日漏洞过后关闭暴露面是必要的，但责任归属要求了解暴露面为何存在。如果不记录原因，那么在安装替换设备、恢复备份配置或服务提供商标准化下一次部署时，同样的模式可能会再次出现。

证据空白本身具有启示意义

公开记录没有提供完整的受害者数量、明确的攻击者归因、每个后门细节、每个受影响的硬件平台、每个客户的暴露状态，或通用的恢复方案。其中一些信息可能无法公开获取，另一些可能已私下分享给受影响的客户或执法部门。这种缺失不应被猜测所填补。

最负责任的公开结论是比较狭窄的：思科和 CISA 记录了 IOS XE Web UI 漏洞的活跃利用，涉及权限 15 账户创建、root 权限提升和植入后门。CISA 敦促禁用面向互联网的 HTTP 服务器暴露、进行搜寻和升级。各版本系列的修复版本已发布。责任归属的结果取决于本地的暴露面、资产清单和恢复情况。

这种证据边界可以防止两种不良叙事。第一种不良叙事说整个事件完全是思科的错，这忽略了客户和 MSP 对面向互联网管理暴露面的控制。第二种不良叙事说整个事件完全是客户的错，因为他们暴露了管理面，这忽略了思科对漏洞、公告质量、修复交付和产品设计激励的责任。

真相不那么令人满意，但更有用。产品缺陷和部署暴露面共同作用，攻击者同时利用了两者。良好的恢复需要供应商的修复和操作人员的纪律。任何一方都不能完全控制，但双方都有足够的控制力来承担各自的责任。

该事件还表明，在管理平面被攻陷之后，证明消极信任是多么困难。设备可能已打补丁，但操作人员能证明没有账户创建吗？用户可能已删除，但操作人员能证明配置没有更改吗？后门可能在重启后消失，但操作人员能证明没有后续的持久化吗？一个面向公众的状态消息很少能回答这些问题。而在事件发生前构建的证据架构则可以。

责任归属跟随管理平面

管理平面是权力集中的地方。这里是管理员进行身份验证、更改配置、创建用户、启用服务、查看日志和开始恢复的地方。让这个平面可以从公共互联网访问，就形成了一个永久性的赌注，即身份验证、代码、配置、监控和补丁管理将始终保持足够强大，足以抵御当前和未来的每一次漏洞利用。

IOS XE Web UI 事件表明这个赌注可能会失败。思科的产品在 Web UI 链中存在两个此前未知的问题。客户和提供商暴露了管理界面。攻击者的行动速度之快，使得缓解和修复交付成为紧急事项。政府机构不得不放大指南。操作人员不得不搜寻账户创建和后门。中小企业不得不依赖提供商寻求答案。

教训不是要消除所有远程管理。现代网络需要远程管理。教训是要将管理访问视为享有较小攻击面的特权基础设施，并具备更强的身份验证、网络限制、日志记录、变更控制和持续暴露面审查。远程管理应通过经过深思熟虑的管理路径访问，而不是通过广泛的公共互联网暴露。

对思科而言，持续的教训是管理平面态势的安全设计理念：使不安全的暴露更加困难，使危险的配置可见，使修复可追踪，使检测指南可操作，并简化版本映射。对客户和 MSP 而言，教训是资产和暴露面真相：知道什么在运行，什么可被访问，谁拥有它，如何禁用它，如何重建它，并知道哪些证据将证明清理工作。

对公共机构和监管机构而言，教训是网络设备管理界面应获得与头条应用程序 CVE 同等的可见性。受攻陷的路由器或交换机可以扭曲围绕其他事件的证据环境，可能在响应架构中成为一个盲点。这使得管理平面暴露面成为一种业务连续性风险，而不仅仅是 IT 卫生问题。

Cisco IOS XE 2023 年 Web UI 利用事件的记录之所以有价值，是因为它拒绝了一个简单的结局。补丁重要，安全加固重要，公告重要，资产清单重要，MSP 的责任重要，后门程序重要。暴露的界面之所以最重要，是因为它决定了在防御者获得完美信息之前哪些设备是可访问的。

因此，负责任结论是实用主义的。一台网络设备不应在其所有者发现 Web 管理界面向世界开放之后才被攻陷。供应商不应依赖客户在零日漏洞已经落地之后才去发现每一个不安全的暴露面。提供商不应在没有证据的情况下告诉客户“我们已经处理好了”。在管理平面安全中，信任不是对品牌或补丁级别的感觉。它是一份记录：暴露面已关闭，攻陷已评估，软件已修复，必要时设备已重建，网络管理权限已通过证据证明恢复。