私有端口不能证明其背后的软件

这是一种合理的直觉：如果只有 VPN 能到达 SSH 监听器，暴露面就很小，问题也就解决了。然而暴露面并不等于完整性。前半句成立，后半句却推导不出来。可达性控制谁可以尝试建立连接；软件完整性控制监听器在收到连接后会做什么。一道门只是收窄了受众，对其背后的代码一无所知。

私有端口是一扇更小的门，而不是另一把锁，这个区别决定了你接下来该检查什么。

两套控制，两个问题

网络限制降低了暴露面。它让被放行的用户，以及任何已被攻陷的获准客户端，仍然能够到达受影响的服务。修复软件包恢复了软件，它同样不会收窄过宽的网络授权。每套控制各司其职，其中一套正确时另一套仍可能缺席。把两者放在一起审查，正是团队说服自己“一套管住两套”的方式，而这恰恰是本文所指的具体错误。

VPN 端点本身也是软件，也承担同样的义务。把它加入路径会引入它自己的维护义务，却不会免除其背后任何东西的供应链责任。

XZ 披露究竟证明了什么

2024 年三月的 XZ/liblzma 披露描述了一个后门，在受影响条件下可能导致 SSH 服务器被攻陷。它既是暴露面问题，同样是软件完整性问题；它并不能证明每一套 Linux 安装都带有易受攻击的构建。范围取决于受影响的版本以及发行这些版本的发行版，而不是操作系统的家族名称。

这个区别就是事件响应与传闻之间的区别，值得为此较真。

关闭端口不是恢复

如果入侵可能已经发生，改变可达性并不是恢复。已经执行的后门早就得到过机会；防火墙规则不会倒着走时间。针对主机和任何已泄露的凭据，遵循经批准的事件流程，并保留确定究竟执行了什么所需的证据。从已知良好的介质重建通常是这场对话的一部分。

同时使用发行版当前经核实的公告与修复流程，读受影响版本列表而不是标题。把一条历史降级命令复制到无关环境，正是修复变成新暴露面的方式。

分别审查两者

用它们各自的语言提出这两个问题。谁能到达监听器，这个受众是否正是该服务的目标受众？安装的是哪个版本的软件，谁签署了制品，组织如何在新闻里读到之前就得知一次糟糕的发布？答案属于不同所有者负责的不同文档，任何一方都无法替另一方回答。

对于受管机群，软件清单是让第二个问题真正可回答的那项控制。没有它，每次披露都会变成一场带截止日期的考古项目。

门收窄了受众。完整性决定受众是否重要。