安全加固指南 vs. 天生安全的设计：一份23页指南引发的思考

一位朋友给我发了一个链接，是关于 Versa Networks 产品去年的一个安全缺陷通知 —— CVE-2024-39717，该漏洞已被列入 CISA 的已知被利用漏洞目录。

https://versa-networks.com/blog/versa-security-bulletin-update-on-cve-2024-39717-versa-director-dangerous-file-type-upload-vulnerability/

其中这部分引起了我的注意：

“受影响客户未实施上述系统加固和防火墙指南，导致管理端口暴露在互联网上，为威胁行为者提供了初始访问途径。”

这里的含义很明确：Versa 将其网络安全的负担转移给了客户。而这个负担并不小——这是一份长达 23 页的加固指南。提醒一下，CISA 的“天生安全”设计原则第一条是：承担客户安全成果的责任。 该原则正是为了应对此类情况而制定的。制造商不应告诉客户如何让产品变得不那么危险，而应设计出难以被以不安全方式使用的产品。

事实上，我们已经建议制造商颠覆传统模式。他们应该提供一份“松绑指南”，而不是一份“加固指南”——这份文档能帮助客户有意识地、谨慎地、有节制地启用潜在的危险功能。

我很好奇这份加固指南里包含了什么。你可以在这里查看：

https://docs.versa-networks.com/Solutions/System_Hardening/Perform_Manual_Hardening_for_Versa_Director

第 1 节：使用签名的 SSL 证书

该指南指出，节点默认使用自签名证书，但“生产”环境需要签名证书。然而，它没有定义什么是“生产”环境，也没有说明什么才算是“签名”证书。这是否意味着我必须将所有设备上的所有证书替换为链接到根 CA 的证书？我可以使用内部 CA，还是必须使用浏览器信任的 CA？如果是这样，我真的需要为我部署环境中的每个设备都这样做吗？我也在想，如果默认是自签名证书，他们的证书验证有多可靠。

这部分引发的问题比它回答的要多。

第 2 节：修改 Director GUI 会话超时时间

指南说：“Director GUI 超时时间设置为 15 分钟。您可以选择减少此时间以提高 Director 的安全性。” 但是，减少超时时间究竟如何提高安全性？需要减少多少？据我所知，这与现实世界中的攻击发生方式并不相符，至少在我的认知里是这样。

第 3 节：修改 Versa Director 帐户密码复杂性

这一节依赖于关于什么构成“强”密码的过时观念。如今的强度意味着长（16+ 字符）、唯一（不在其他地方使用）和随机生成（最好由计算机或骰子生成）。字符复杂性不再是可靠的安全信号。

奇怪的是，虽然这一节试图改进密码，却没有提到多因素认证 (MFA)——这在现实世界的攻击中是一种被证明有效的防御措施。这个遗漏令人惊讶。

第 4 节：启用 SSH 横幅

不清楚为什么这会在加固指南里。

第 5 节：保护 Director HA 节点之间的通信

“为了在 Director 高可用性 (HA) 架构中提供额外的加固，您可以加密 Director 实例之间的 HA 通信。”

为什么默认不强制执行此操作？为什么允许一个安全产品在其节点间通信未加密的情况下运行？

第 6 节：保护 HA 端口安全

“此脚本修改 iptables 规则，以拒绝除 HA 设置中对等节点 IP 地址之外的端口访问。”

再说一次，为什么这是手动步骤？这应该是安装程序的一部分。

第 7–9 节：更改 Linux、Director、Postgres 的默认密码

为什么安装时不处理这个？如果需要更改这些密码，它们一开始就不应该被设置为默认值。

第 10 节：禁用 Shell-in-a-Box

“根据您的内部安全策略，您可能希望禁用此功能。”

再次提出，为什么默认启用一个有风险的功能？

第 11 节：更新安全包

这应该是自动化的并持续监控的。当有可用更新时，管理员应收到警报。制造商不应依赖客户重新阅读加固指南来保持安全。

第 12 节：配置时间

确保准确的时间应该是自动的，并伴有适当的监控和警报。该指南还讨论了时区，但为什么系统需要本地时区？设备应使用 UTC，并在需要时让浏览器处理到本地时间的转换。

第 13 节：配置 DNS 服务器

应在安装期间处理。

第 14 节：验证软件版本

“为了所有 SD-WAN 组件的最佳性能，Versa Networks 要求所有组件运行相同的软件版本。”

系统应自动检测版本不匹配并提醒管理员。

第 15 节：启用集中式身份验证

“建议您在所有 Versa 设备上使用 TACACS+ 或 RADIUS 启用集中式身份验证。”

这应该内置于安装程序中。

第 16 节：启用安全模式

“您启用安全模式来加固 Linux 核心操作系统组件，以满足 Linux CIS 基准测试。”

满足 CIS 基准听起来很重要。为什么默认不启用它？风险是什么？如果某些更改导致问题，我该如何撤销？

第 17 节：更新 IP 表

这部分在第 6 节中已经部分涉及。第一段令人困惑：

“您更新 Linux IP 表，为 Linux 内核防火墙定义 IP 包过滤规则，以允许或阻止系统流量。”

这需要更清晰的说明。我怎么知道何时以及为何要实施这个？

第 18 节：更改默认设备 Linux 密码

前面已经提到过。同样，这应该在安装期间处理。

第 19 节：禁用未使用的内核模块

“作为 Director 加固的一部分，您应该禁用以下未使用的 Linux 内核模块，以保护设备免受其实现中任何缺陷的利用。”

如果这些模块未被使用且存在漏洞，它们为什么会出现在生产系统中？

第 20 节：禁用混杂模式

这是另一个应该默认实施，而不是委托给客户的例子。

第 21 节：加固 SSH

如果这些步骤能有效降低风险，制造商就应该实施它们。如果不需要 SSH，它应该默认禁用，并通过松绑指南重新启用。

（抱歉，没想到这么长了！）

总结

我鼓励所有软件制造商采纳 CISA 的天生安全设计白皮书 中概述的原则。我们需要摒弃那种歌颂攻击者做对了什么、受害者做错了什么的安全文化。相反，我们必须关注供应商能做些什么来使攻击更困难、成本更高、效果更差。

加固指南应该简短且清晰。我读到的大多数加固指南中的任务，要么应该纳入基础系统，要么应该包含在为想要使用这些功能的客户准备的松绑指南中。其他任何做法都只是将风险推给那些在事发前往往对此一无所知的客户。FINISHED

CSD0tFqvECLokhw9aBeRqto/jjC/q4XSimWGnuuDccS7std19SbKPYGbksmjbetDBic8LEm8gQNKewjfseYYd//pwhVwhIXdY3F6qxB0vbPglwiv4QUv9YL/2B6AusAG