本地回环服务的暴露面：DNS Rebinding 与诊断端点防护¶

分类：系统调优与安全 · 本地服务安全

本文解释一个常见误解：服务只监听 127.0.0.1 不等于外界无法触达。本地 AI 推理服务、开发服务器、桌面代理（本地 API 网关）等都属于此范畴。

一、"只监听 127.0.0.1"挡住了谁、漏掉了谁¶

回环监听挡住的是外部网络的直接连接。但有一条通路它挡不住：受害者自己的浏览器。

浏览器运行在本机上，天然有权访问 127.0.0.1。同源策略（Same-Origin Policy）本应阻止 evil.com 的页面读取本地服务的响应，但 DNS Rebinding 可以绕过这层防护：

攻击者域名 a.attacker.com 首先解析到攻击者服务器（如 1.2.3.4），浏览器加载页面完成，此时一切合法；
该域名的 DNS TTL 极短（如 1 秒），过期后二次解析被重绑定到 127.0.0.1；
此后页面内向 a.attacker.com:8080 发起的请求，实际命中的是受害者本机的 8080 端口服务——且在浏览器看来这仍是"同源"请求，响应可读。

攻击效果：恶意网页无需任何授权即可调用本机服务的 API、读取响应内容。GitHub Security Lab 的分析确认这类攻击不需要 CORS 缺陷即可达成。

案例	服务类型	后果
CVE-2024-28224（Ollama，NCC Group 通告）	本地 LLM 推理服务	恶意网页经 DNS Rebinding 调用本机 API：未经授权访问模型、外传私有数据、发起拒绝服务
GUPnP Host 校验缺失（GNOME GitLab issue）	媒体服务	服务端不校验 `Host` 头，直接构成 Rebinding 可达面
CVE-2025-66414（本地 MCP 服务器）	本地工具服务	恶意网站向 localhost 的 MCP 服务器发送任意请求，无 CORS 报错、无浏览器警告

共同点：本地 AI/工具服务 + 无鉴权或弱鉴权 + 不校验 Host 头。

本地服务常提供 /health、/status、/debug 类"只读诊断端点"，普遍认为"反正是本机用的，不配鉴权"。问题在于这类端点经常返回超出必要的细节：账号昵称、凭据过期时间、配置文件绝对路径、内部组件版本与模式。

在 Rebinding 可达的前提下，这些字段等于把用户的身份画像与服务端布局免费交给恶意网页。诊断端点应当只回答"活着吗/配置好了吗"这类布尔问题。

校验 Host 头：服务端中间件拒绝 Host 不是 localhost / 127.0.0.1 / [::1]（含端口后缀，IPv6 注意方括号解析）的请求——这是 GUPnP 与 Ollama 两个案例的一线修复手段，也是对 Rebinding 最直接的断路器；
本地 API 默认鉴权：即使是本机 IPC 场景，也建议默认生成随机 token 并要求携带，把"零鉴权"降级为显式选择；
无鉴权端点只输出布尔/状态：身份、路径、版本细节一律移入鉴权端点；
不要用 DNS/反向 DNS 判断可信（CWE-350）：安全决策基于显式配置或凭据，而非名称解析结果；
保持浏览器与系统更新：Chrome/Firefox 的 Private Network Access / Local Network Access 检查正在成为对 Rebinding 的浏览器级防线（Radboud 大学 2026 年评估认为 LNA 是强防线），但服务端防线不能依赖浏览器行为。

本主题没有"一键注册表修复"：它属于服务实现质量问题，检查对象是你本机运行的每个本地服务（AI 推理、代理网关、开发服务器、路由器管理页）。自查方法：对本机监听端口逐一确认三件事——是否校验 Host、无鉴权端点暴露了哪些字段、默认凭据是否存在。

声明	核查结果
DNS Rebinding 可绕过同源策略读取 localhost 服务响应	✅ 属实：NCC Group 对 Ollama CVE-2024-28224 的技术通告与 GitHub Security Lab 的机制分析一致
不校验 `Host` 头是 Rebinding 可达的一线原因，校验 Host 是一线修复	✅ 属实：GUPnP issue 明确以"不校验 Host"为漏洞成因，修复即加入 Host 白名单校验
浏览器 LNA/PNA 检查可阻断公网对内网/回环的请求	⚠️ 属实但仍在推进中：Radboud 大学 2026 年评估认为强有效，各浏览器覆盖率与默认行为有差异，服务端防护不可省略