咖啡馆实战：反向代理与 CDN 回源配置的权限边界检查

背景网站接入 Nginx 反向代理或 CDN 后，公网扫描通常只能看到边缘节点。问题在于，源站端口、真实客户端地址和内部管理路径经常仍按上线前的信任模型配置。一次授权测试中，业务主站经 CDN 对外提供服务，源站 443 端口却允许任意公网地址访问；Nginx 又无条件信任客户端提交的 X-Forwarded-For，导致后台访问控制可被绕过。本文讨论网站建设和服务器运维中常见的回源边界问题，验证动作应仅在书面授权的域名、IP 和时间窗口内进行。重点不是绕过 CDN 本身，而是确认源站是否只接受可信边缘节点流量，以及代理头是否由可信链路重写。问题定位先从自有资产信息入手，不建议对无关网段做盲目扫描。可核对 DNS 历史记录、证书资产台账、云负载均衡配置和发布文档，得到候选源站 IP。随后分别请求 CDN 域名和候选源站，对比状态码、响应头、证书、页面摘要及静态资源路径。# 授权范围内验证源站是否可被直接访问
curl -skI -H 'Host:

# 对比边缘节点响应
curl -skI

# 固定解析到候选源站，避免修改本机 hosts
curl -sk --resolve \
-o /tmp/origin.html
sha256sum /tmp/origin.html单凭页面相同不能认定泄露，因为不同站点可能共用模板。应继续核对 TLS 证书 SAN、Server-Timing、缓存头、错误页特征和应用生成的请求 ID。验证时控制请求频率，不访问真实用户数据，不执行写入操作。技术分析：两条容易混淆的信任链边界错误配置直接影响网络回源边界源站 80/443 对全网开放攻击者绕过 CDN 的 WAF、限速和抗压能力代理头边界对任意来源信任 X-Forwarded-For伪造来源地址，绕过 IP 白名单或污染审计日志虚拟主机边界默认站点承载真实业务通过 IP 或异常 Host 命中业务运维入口边界/admin、监控接口仅靠来源 IP 判断一旦代理头配置错误，权限控制失效Nginx 的 realip 模块会把指定请求头解析为客户端地址，但只有请求确实来自可信代理时才能启用。若配置为 set_real_ip_from 0.0.0.0/0，任何直连源站的客户端都能控制日志中的 remote_addr。更危险的是，应用若据此执行后台白名单判断，日志污染会进一步演变成权限绕过。可信代理地址应来自 CDN 官方公布且经过变更管理的网段；不要从网上复制一份长期不更新的列表，也不要把整个云厂商网段视为可信。授权验证步骤第一步，确认源站网络边界。使用测试终端直连候选 IP 并携带正确 Host。如果返回完整业务页面，检查云安全组、防火墙和负载均衡监听器是否仅允许 CDN 回源网段。若外部直连被拒绝，再从经过批准的 CDN 节点链路确认业务仍可用。第二步，检查默认虚拟主机。分别使用空业务 Host、随机 Host 和正确 Host 发起无害的 HEAD 请求。随机 Host 应直接拒绝或返回固定空页面，不应落入真实业务虚拟主机。# 只验证路由和状态，不提交业务数据
curl -skI -H 'Host: invalid.example.test'
curl -skI -H 'Host:

# 检查伪造代理头是否改变应用所见来源；仅请求专用测试接口
curl -sk --resolve \
\
-H 'X-Forwarded-For: 127.0.0.1'测试接口应仅在预发布环境或临时授权窗口开放，返回规范化后的客户端 IP 即可，禁止回显全部请求头、令牌或环境变量。若伪造头使结果变成 127.0.0.1，说明源站直连与 realip 信任配置共同形成了可利用链路。第三步，核对日志。边缘日志、Nginx access log、应用审计日志应能通过请求 ID 关联。重点搜索源站收到但 CDN 无对应记录的请求，以及 private、loopback、链路本地地址出现在公网访问日志中的情况。# 示例：筛选疑似伪造或异常来源；字段位置需按实际 log_format 调整
awk '$1 ~ /^(127\\.|10\\.|192\\.168\\.|169\\.254\\.)/ {print}' \
/var/log/nginx/access.log | head -n 50

# 查询直连源站常见特征：缺少由边缘统一注入的请求标识
grep -v 'edge-request-id=' /var/log/nginx/access.log | tail -n 100安全配置示例网络层应优先在云安全组或主机防火墙限制回源；Nginx 配置是第二道防线。以下网段仅为文档示例，部署时必须替换为实际 CDN 官方网段，并同时处理 IPv4 和 IPv6。# 默认虚拟主机不承载业务
server {
listen 443 ssl default_server;
server_name _;
ssl_certificate /etc/nginx/tls/default.crt;
ssl_certificate_key /etc/nginx/tls/default.key;
return 444;
}

server {
listen 443 ssl;
server_name

# 只信任实际边缘代理，禁止 0.0.0.0/0
set_real_ip_from 192.0.2.0/24;
set_real_ip_from 2001:db8:100::/48;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

location / {
proxy_set_header Host $host;
proxy_set_header X-Request-ID $request_id;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass /> }
}如果 CDN 提供带签名的回源鉴权头或双向 TLS，建议启用，但不能用固定明文 Header 替代网络边界。固定值容易出现在日志、工单和配置仓库中，泄露后无法证明请求确实来自边缘节点。日志留痕与排查建议同时记录连接源地址、realip 解析后的地址、原始代理头和请求 ID，但原始代理头属于不可信输入，检索时不能直接当作事实。可使用如下日志格式区分连接层与应用层地址：log_format trace '$time_iso8601 conn=$realip_remote_addr '
'client=$remote_addr xff=\\\"$http_x_forwarded_for\\\" '
'host=$host request_id=$request_id '
'status=$status request=\\\"$request\\\"';
access_log /var/log/nginx/access_trace.log trace;处置时先保全日志，再修改策略。至少保留 CDN 请求日志、云防火墙流日志、Nginx 日志及应用鉴权日志，并统一时区。若发现源站曾长期暴露，应回溯是否存在绕过边缘限速的高频请求、异常 Host、伪造内网地址以及对管理路径的直接访问。风险与修复建议云安全组仅允许 CDN 官方回源网段访问业务端口；SSH、数据库和监控端口使用独立运维网络，不与回源规则混用。建立 CDN 网段自动同步流程，但更新前做格式校验、差异审计和连通性灰度测试，避免误封。默认虚拟主机返回拒绝响应，业务站点显式匹配 server_name，并检查 IPv6 监听是否遗漏。realip 仅信任明确代理节点；应用层不直接使用用户可控 Header 做授权判断。后台权限采用身份认证、设备或网络边界与最小权限组合，IP 白名单只能作为附加条件。为源站证书、错误页和响应头做最小暴露，关闭非必要版本信息，但不要把隐藏指纹当作核心防护。修复后从公网、CDN 链路和运维网络分别回归，确认直连被拒绝、正常回源可用、日志中的连接地址和客户端地址可追溯。总结网站接入 CDN 或反向代理后，真正需要检查的是端到端信任关系：谁能连接源站、源站信任谁提供的客户端地址、应用又用这些地址做了什么决策。实际排查应把 DNS 与资产台账、网络访问控制、Nginx realip、默认虚拟主机和多层日志串起来。只修一处 Header 或隐藏源站页面，通常不足以关闭整条绕过链路。

这类检查我一般先把“CDN 能访问源站”和“客户端能直接访问源站”拆开验证，重点不是页面是否正常，而是源站有没有把 CDN 当成天然可信边界。

建议按下面几个点落地检查：

1. 验证回源是否可绕过：从非 CDN 节点直接请求源站 IP，并显式带业务域名。若仍能拿到 200，说明仅隐藏源站地址还不够。

curl -kiv --resolve  \
  

curl -kiv --resolve  \
  
源站入口应至少限制为 CDN 官方回源网段；更稳妥的是同时启用回源 mTLS 或 CDN 提供的 authenticated origin pull。网段白名单要自动同步，避免 CDN 扩容后误封，也避免旧网段长期残留。
# Nginx 示例：默认拒绝，仅放行 CDN 回源段
server {
    listen 443 ssl;
    server_name 

    allow 192.0.2.0/24;     # 示例网段，替换为厂商官方列表
    allow 2001:db8::/32;    # 示例网段
    deny all;

    ssl_client_certificate /etc/nginx/certs/cdn-origin-ca.pem;
    ssl_verify_client on;
}
不要仅依赖固定请求头或 User-Agent 鉴权，这些值在源站地址暴露后很容易被复现。若使用共享密钥头，也应叠加网络 ACL，并确认密钥不会被应用日志、错误页或链路追踪记录。

检查真实客户端 IP 的信任链：只有连接来源属于 CDN 网段时，才能采信 X-Forwarded-For 或厂商的真实 IP 头。否则攻击者直连源站时可以伪造 IP，绕过后台白名单、限速和审计。

# Nginx 示例
set_real_ip_from 192.0.2.0/24;
set_real_ip_from 2001:db8::/32;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
可分别经 CDN 和直连源站发送伪造头，核对访问日志中的 $remote_addr、$realip_remote_addr 与应用侧客户端 IP 是否符合预期。
curl -kiv --resolve  \
  -H 'X-Forwarded-For: 127.0.0.1' \
  

检查 Host/SNI 和默认虚拟主机：源站不应对任意 Host 返回业务内容，未知 Host 应直接拒绝，避免绕过 CDN 域名策略或命中内部虚拟主机。

server {
    listen 443 ssl default_server;
    server_name _;
    return 444;
}

核对 CDN 与源站的策略差异：重点比较管理路径、上传接口、调试端点、非标准端口和备用域名。常见问题是 CDN 已拦截 /admin，但源站同一路径可直连；或者 443 受控，源站的 80、8080、8443 仍对公网开放。

nmap -Pn -sT -p 80,443,8080,8443 203.0.113.10
curl -sSIk 
curl -sSIk --resolve  \
  
最后建议在源站防火墙日志里专门统计“非 CDN 网段访问业务端口”的事件；正常情况下应接近零。这样既能验证权限边界，也能及时发现源站 IP 泄露和绕过尝试。