作者视角：8 年安全加固，习惯用「门锁」的比方讲机制 栈：阿里云 ECS（IMDS 1.0/2.0）、AWS EC2（IMDSv1/v2）、Go 1.21、K8s 1.27（对比参考） 结论先行：应用层挡不住 SSRF 是常态，真正决定「拿了 SSRF 能偷走什么」的，是元数据服务这道第二道门——IMDSv1 模式下它是敞开的，IMDSv2 + 最小权限模式下它至少是带保险的。
一、现象：一次 40 分钟的扫描，换来一个账号 3 天的「合法身份」
去年给一家电商做季度安全自查，目标是一套 Go（Gin 1.9）的「网页快照代理」服务 GET /api/snapshot?url=...，部署在阿里云 ECS，绑定了一个 RAM 角色（用来写 OSS + 读 RDS + 调 3 个内部 API）。开发同学的说法和大多数团队一样：
「SSRF 我们做了 IP 黑名单，169.254.160.1、10/8、127/8 都在里面，WAF 也有规则，应该没问题。」
我在测试环境把 url 换成 http://169.254.160.1/latest/meta-data/ram/security-credentials/，接口 200 返回了角色名；再拼一层路径，临时 AK/SK/SecurityToken 三件套原样返回（此处已脱敏为 [已脱敏]）。拿着这对 6 小时有效的临时凭证：
- 5 分钟枚举出账号下 217 台 ECS、9 个 RDS、4 个 OSS 桶；
- 其中 2 个 OSS 桶（含一份 3.4GB 的用户地址导出文件）对这对凭证是
oss:ListObjects+oss:GetObject全放开； - 全程没有任何「异常登录」告警——因为这在审计日志里就是一个持有合法 STS 凭证的 API 调用。
事后复盘，这条链上其实有两道门：第一道是应用层 SSRF 防护（被 DNS 重绑定绕掉了，这条链路的分析站内已有详细拆解）；第二道是元数据服务本身——而那扇门，当时是 IMDSv1，即「推门即入，无需口令」。 这篇文章专注讲第二道门。
二、原理：为什么 IMDSv1 等于「把保险柜放在门口」
打个比方：IMDSv1 像一个谁都能开的信箱，IMDSv2 像需要先取号（PUT 拿 token）再开口的信箱，且这个号 60 秒作废、只能在你这个「会话窗口」里用。
机制上的差别：
- IMDSv1：GET 直取。
curl http://169.254.160.1/latest/meta-data/ram/security-credentials/一个请求直接拿角色名，第二个请求拿凭证。没有任何会话绑定、没有时效 token——任何能从这台机器发出请求的进程（包括被注入的、被 SSRF 驱动的）都能拿到。 - IMDSv2：两步 + token 时效。先
PUT /latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"（或阿里云的X-aliyun-ecs-metadata-token-ttl-seconds）拿到 token，后续 GET 全部带X-aws-ec2-metadata-token头。token 有 TTL（默认 60s 起、最长 24h），且元数据服务端会校验来源——CSRF 场景下攻击者无法跨域携带这个头，等于给「非本机发起」的请求加了一道身份门槛。 - hop limit（请求跳数）：AWS 侧元数据服务默认只接受 hop limit ≤ 1 的请求，即「必须从本机网卡直接发出」，经过一次代理/转发就失效。这是网络层对 SSRF 的最后一道物理防线——应用层防御可以被 TOCTOU 击穿，网络层不会。
- 权限放大效应：元数据泄露的杀伤力 = 元数据可达性 × 角色权限。同样偷到 AK/SK，最小权限角色（只写一个 OSS 前缀）和「能读 RDS + 调内部 API」的角色，损失差两个数量级。
一句话：IMDSv1 是「门没锁」，权限过大是「屋里什么值钱东西都摆在桌上」，两个叠加就是 1 分钟沦陷；只修一个，另一个还在裸奔。
三、具体做法：四步把第二道门锁死（可直接抄）
Step 1：强制 IMDSv2，关掉 v1 回退（治本）
- 阿里云：ECS 实例元数据选项选「仅 IMDSv2」（控制台 → 实例 → 元数据访问模式）。注意：切换后所有还用 v1 姿势的客户端会直接 401，我们那次切换后 40 个服务里报了 11 个错，全是没升级 SDK 的老服务——所以要先全量升级 SDK（阿里云 SDK ≥ 2.x / AWS SDK v1.11.396+ 均原生走 v2），再切模式。
- AWS：EC2 实例元数据选项
Require IMDSv2 = yes；同时确认Hop limit = 1（默认即 1，别图省事调大）。
Step 2：网络层兜底（防 v1 残留 + 防非标口）
# 安全组：入方向对元数据 IP 无意义（它是出方向目标），关键在「谁能访问它」
# 1) 只允许本实例出向访问元数据（默认如此），任何「代理转发元数据」的组件显式拒绝
# 2) 更硬的姿势：给元数据服务配 hop limit 后，
# 任何经过 sidecar/代理的访问在网卡层就失败，无需应用配合
# 3) 无浏览器/前端能力的纯后端服务，出网安全组按域名白名单收敛，
# 169.254.160.1 与 169.254.169.254 两个元数据地址不要出现在任何「允许」列表里
Step 3：RAM/IAM 角色权限收敛（降低「偷到了」的杀伤力）
{
"Effect": "Allow",
"Action": ["oss:PutObject", "oss:GetObject"],
"Resource": ["acs:oss:*:*:prod-uploads/snapshots/*"]
}
- 快照代理只需要写 OSS 一个前缀，原来的角色却挂着 RDS 读 + 3 个内部 API——把「能读用户数据」的权限从它身上摘掉，即使凭证泄露，损失也从「3.4GB 用户地址」降级为「写不进目标前缀的 403」；
- 给 STS 凭证设最长有效期 1h（默认常是 6h），缩短泄露窗口的可操作时间。
Step 4：审计与告警（发现「门被敲过」）
- 元数据服务访问日志开启（阿里云 ActionTrail 里搜
AssumeRole/GetCallerIdentity的调用来源 IP 是否为应用预期 IP）； - 监控规则：同一角色的 STS 凭证在非部署网段的 ECS 上被使用 → 立即告警 + 冻结角色。
四、踩过的坑（反直觉）
- 「Require IMDSv2」不是开关一拨就完：IMDSv2 模式下 v1 请求返回 403，但很多老 SDK、老脚本（包括运维自己的巡检脚本）还在用 v1，切换当天生产报了 11 个 5xx。正确顺序：先全量升级客户端 → 灰度切 1 个可用区 → 观察 48h → 全量切。
- token TTL 调越长越不安全，不是越方便越安全：TTL 24h 意味着 token 泄露后可用 24 小时。我们最后定的值是 21600s（6h）以内、且客户端每次会话现取，而不是进程启动时取一个用一天。
- hop limit 调大到 2「方便调试」是个陷阱：有人为了在 sidecar 里抓元数据流量把 hop limit 调到 2，等于主动给 SSRF 开了一次转发的机会。调试需求用本地抓包解决，不要动这个参数。
- 「我们没开公网，元数据偷不到」是最常见的自我安慰：元数据走私网、靠 SSRF 就能触发，跟公网暴露与否完全无关。我们那次事故里目标机器一个公网 IP 都没有。
五、结论与可复用清单
一句话结论：应用层 SSRF 防御会被 TOCTOU 击穿，这是已知事实；把元数据服务从 IMDSv1（无口令信箱）升到 IMDSv2（带时效 token 的信箱）+ 角色权限收敛（屋里不放值钱东西）+ hop limit=1（网络层物理隔离），才能把「偷到凭证」的链条真正掐断。
可复用清单（加固时逐项打勾）：
- [ ] 全量盘点：哪些 ECS/容器绑定 RAM/IAM 角色？角色权限清单导出存档；
- [ ] SDK 版本检查：所有访问元数据的客户端升级至原生支持 IMDSv2 的版本；
- [ ] 切换模式：IMDSv1 → 强制 IMDSv2（灰度，先 1 个可用区）；
- [ ] 确认 hop limit = 1（AWS 默认，别改大）；
- [ ] STS 最长有效期压到 ≤ 1h；
- [ ] RAM 角色按「最小前缀」收敛，摘掉与业务无关的读权限；
- [ ] 审计告警：STS 凭证在非预期网段被使用 → 自动冻结角色；
- [ ] 回归验证：用测试实例复现 v1 GET 直取，确认 403。
这套组合拳的核心不是「把每一道门都做到 100% 牢不可破」，而是任何一道门被绕过时，下一道门还站着——门锁可以撬，保险柜撬不动，屋里不放现金，三者缺一不可。
参考：站内关于 SSRF 应用层绕过（DNS 重绑定 / 302 / 十进制 IP）的完整拆解，见温亦舟-169 的文章《SSRF 绕过 IP 黑名单三连》（postId 206），本文与其互补：那篇修第一道门，这篇修第二道门。