4. VPN隧道密钥泄露：IPsec/IKE漏洞、预共享密钥风险
VPN隧道密钥泄露，听起来挺吓人对吧？说白了就是攻击者拿到了你用来加密隧道的那把“钥匙”。我这些年搞安全审计，遇到最多的就是IPsec/IKE的配置问题。预共享密钥（PSK）虽然简单，但风险可不小。
这一章我们就掰开揉碎了聊：IPsec/IKE到底哪里容易出问题？预共享密钥怎么就成了烫手山芋？怎么防、怎么修？
4.1 IPsec/IKE协议栈的薄弱环节
IPsec不是单一协议，是一组协议的集合。IKE（Internet Key Exchange）负责协商密钥，是整个隧道的“大脑”。一旦IKE出问题，IPsec就是纸糊的。
4.1.1 IKE版本差异与漏洞
| 对比项 | IKEv1 | IKEv2 |
|---|---|---|
| 主模式/野蛮模式 | 支持，野蛮模式身份泄露 | 统一交换，无野蛮模式 |
| 认证方式 | PSK、证书、共享密钥 | PSK、证书、EAP |
| 已知严重漏洞 | CVE-2005-3665（ISAKMP DoS） CVE-2016-0800（DROWN变种） |
CVE-2020-25282（IKEd资源耗尽） |
| 默认加密套件 | 3DES/SHA1（弱） | AES-GCM/SHA256（强） |
| 我个人倾向 | 能不用就别用 | 首选 |
IKEv1的野蛮模式会把发起方ID和PSK hash一起发出去。你想想看，攻击者只要抓个包，跑个字典，PSK就出来了。IKEv2已经修复了这个问题，但很多老旧设备默认还是v1。
4.1.2 预共享密钥的风险根源
预共享密钥（PSK）就是个“共享秘密”。听起来简单，但问题恰恰出在“共享”二字上。你一个人记着密码没事，一旦几十台设备都存同一个PSK，那泄露面就太大了。
- PSK硬编码：很多网管为了省事，直接把PSK写在配置脚本里，代码库都能搜到。
- PSK强度不足：我见过用“password123”做PSK的，跑个字典不到10秒。
- PSK轮换困难：一旦PSK泄露，你得重新配置所有隧道设备，线上业务还得停。
- 无认证绑定：PSK不绑定特定设备，拿到PSK就可以仿冒任意一端。
核心结论：PSK适合小规模测试环境或临时隧道。生产环境请换成数字证书或EAP‑TLS。
4.2 常见攻击手法与案例
4.2.1 中间人攻击（MITM）窃取PSK
攻击者部署一个伪装的VPN网关，诱导客户端连过来。IKEv1野蛮模式下，客户端直接把自己的身份和PSK hash发过去。攻击者拿到hash后，离线跑字典就能还原PSK。
我记得有一次审计，客户把PSK设成了公司域名“corp2023”。攻击者连字典都不用，猜几次就进去了。
4.2.2 离线字典攻击
只要捕获到IKEv1的野蛮模式交换包，或者IKEv2如果配置了弱PRF（伪随机函数），攻击者可以把PSK相关的计算拿到本地慢慢跑。
# 工具示例：ike-scan + psk-crack
ike-scan -M -A --id=any 192.168.1.100
# 捕获PSK hash后
psk-crack -b psk_hash_file /usr/share/wordlists/rockyou.txt
你看，就这两步，如果PSK不够强，密码就破了。我实测过，8位纯数字不到5分钟。
4.2.3 Rekey风暴与Doorslam攻击
IPsec隧道会定期Rekey（重新协商密钥）。如果攻击者伪造大量Rekey请求，VPN设备CPU瞬间飙满。更可怕的是，Rekey过程中如果密钥生成器有漏洞，新密钥可能被预测。
我在2019年处理过一起案例：客户用某品牌低端防火墙做IPsec，Rekey间隔设了30秒。攻击者发了一波伪造的删除通知（Delete Payload），设备直接清空了所有SA。隧道断了，业务瘫痪半小时。
4.3 应对方案与加固措施
4.3.1 迁移到IKEv2并禁用野蛮模式
这是最根本的。IKEv2去掉了野蛮模式，所有身份信息都在加密的保护下交换。配合强密码套件，攻击者几乎不可能离线破解。
4.3.2 预共享密钥加固
如果实在没法换证书（比如临时点对点链路），那PSK也得用到位。
- 长度至少32字符：混合大小写、数字、符号，避免字典猜解。
- 避免硬编码：使用外部密钥管理服务（KMS）动态下发。
- 定期轮换：每90天换一次，最好结合自动化脚本。
- 一隧一密钥：每条隧道独立的PSK，别共用一个。
# 生成强PSK示例（Linux）
openssl rand -base64 48 | tr -d '/+=' | cut -c1-32
# 输出如：f8K2jM7xPqR5tV9wYz3A6cB0nL44.3.3 升级加密套件与配置文件
很多VPN设备默认配了3DES、SHA1、DH Group 1/2，这些都已经不安全了。你自己看看配置就知道了。
| 参数 | 不推荐 | 建议 | 原因 |
|---|---|---|---|
| 加密算法 | 3DES, AES-CBC | AES-GCM-256 | GCM自带认证，CBC需额外HMAC |
| 完整性算法 | HMAC-MD5, HMAC-SHA1 | HMAC-SHA256 | SHA1已可碰撞（SHAttered） |
| DH组 | modp768(modp1024) | modp2048, modp3072, ECP256 | 防Logjam攻击 |
| 伪随机函数 | PRF-HMAC-SHA1 | PRF-HMAC-SHA256 | 增强密钥派生强度 |
| SA生命周期 | 8小时以上 | 1小时或更短 | 减少泄露窗口 |
4.4 监控与应急响应流程
光加固不够，还得能及时发现泄露。我一般会在VPN网关上部署以下监控项：
- 非正常Rekey频率：单位时间内Rekey次数超过阈值（比如10次/分钟），可能是攻击。
- 陌生ID连接尝试：IKEv1野蛮模式会暴露ID，日志里多留意不认识的ID。
- CPU/内存异常升高：IKE进程占满，大概率被DoS了。
应急三步走（我用过，有效）：
- 立刻断开疑似被攻陷的隧道（抓包留证）。
- 更换所有相关PSK或吊销泄露证书。
- 检查日志，确认攻击源IP，拉黑隔离。
还有一种情况——内部人员故意泄露PSK。我见过一次，运维离职前把PSK写在了公司Wiki上。幸好监控及时发现异常连接，我们半小时内换了所有密钥。
4.5 知识体系一览
这张图把根因、攻击手法和应对措施串在了一起。你对着图检查自己的VPN配置，应该能发现不少问题。我个人经验是，先解决最痛的点——关掉野蛮模式、换掉弱PSK——安全水位立马提升一大截。