你的 VPN 网关遭入侵：真正被暴露的是什么
被攻破的 VPN 网关能看见自己隧道内部，但这不等于掌握每一个会话。恢复前请区分流量、可达范围与已存储的密钥。
VPN 网关位于它所保护的隧道末端，这意味着它会终止加密，而不是把加密原样透传。若攻击者控制了该主机，隧道从外面看仍然健康，而中间那台机器已不再可信。真正有用的问题不是“是否全部被解密”，而是该主机能看到什么、能到达哪里、上面究竟存了哪些密钥。这三个答案差别很大，应对方式也随之不同。
网关终止隧道，所以能看见隧道内部
VPN 中的加密是逐跳进行的，网关就是其中一跳。它剥掉外层、执行策略并转发内层数据包，因此每个被承载的数据包都在某个时刻以可读形式存在于该主机的内存里。这是设计使然，而非缺陷。也正因如此，网关被攻破与隧道密码学被攻破是两件不同的事。
攻击者首先获得的是位置：能够观察被承载的流量、改变转发，或代替某个后端作出应答。接下来能得到什么取决于该主机，而这正是人们容易高估的地方。仅有网关访问权限并不会交出浏览器的 TLS 会话密钥，因为那些密钥从未存在于网关上。
三种规模并不相同的暴露
把问题拆成被承载的流量、可达系统与已存储的密钥，然后分别作答。
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
中间那一行最容易被跳过。网关通常有一条通往私有网络的路由，以及后端本就信任的源地址，因此有意思的问题是：这些后端允许来自该地址的哪些访问。狭窄的客户端访问策略是良好的控制，但网关主机上的攻击者并不受普通客户端所用接口的限制。
最下面一行决定事件持续多久。服务器密钥与 CA 密钥的影响半径完全不同，本地管理员账号与只读监控令牌也是如此。
隧道内的 HTTPS 仍然是 HTTPS
应用层 TLS 在应用处终止，而不在 VPN 网关终止，因此被攻破的网关对这些流量只能看到密文。这是攻击者所得的真实边界，值得明确说出来，因为相反的说法会散播恐慌和错误决策。有两种情况会打破这一边界。如果路径上存在持有受信任证书的检查组件，网关按设计就可能看到明文。如果应用自身的端点被攻破，隧道便无关紧要。
因此“他们看到了什么”的答案是带条件的，应当写成条件，而不是当作结论对外宣布。
在重新信任它之前必须改变什么
重建主机是必要的，却很少足够。仍然持有管理账号、部署凭据或签名密钥的攻击者，可以把主机恢复成他想要的样子。恢复必须从一条不依赖被攻破机器的管理路径开始。
在决定轮换什么之前，先清点主机上有什么。密钥、服务账号、API 令牌、本地用户、计划任务、信任关系与部署流水线都是候选对象，每一项都应有负责人加以确认。
ss -lntup
getent passwd
crontab -l
ip route show table all这份清单是查看主机提供过什么、能到达哪里的最快方式。先保存证据，按响应负责人的流程处理，因为重建恰好会毁掉调查所需要的东西。NIST SP 800-61 第 3 版把准备、检测、响应与恢复视为同一风险管理流程的组成部分，而不是一条重启指令。
让下一次更省事的边界
有四条边界值得在需要之前就建好。保留一条不经网关认证的独立恢复路径。把签名权限与承载流量的主机分开。限制网关的可达范围，使被攻破的网关不会自动等于被攻破的管理网。并记录每份凭据的归属，让轮换成为一通电话，而不是一项考古工程。
这些都不能阻止被攻破。它们限定其范围，并决定了是糟糕的一周还是糟糕的一个季度。