咖啡馆实战：网站接入 CDN 后的源站暴露、真实 IP 边界与日志留痕排查

背景

网站接入 CDN 或反向代理后，常见误区是把“域名已走 CDN”当成“源站已经隐藏”。实际授权测试中，经常能看到三类问题：源站公网端口仍对任意地址开放、Nginx 无条件信任客户端提交的 X-Forwarded-For、源站与 CDN 使用相同证书或默认站点，导致资产被关联和绕过。

本文以自有域名 example.com、源站 203.0.113.10 为示例，重点讨论服务器边界、加速链路、日志取证与修复。示例地址均为文档保留地址，验证时应替换为明确授权的资产。

问题定位

先画清实际请求链路：

客户端 -> CDN/WAF -> 源站 Nginx -> 应用服务
                         |
                         +-> access.log / 应用审计日志

排查时应分别回答以下问题：

• 源站的 80、443 端口是否只允许 CDN 回源地址访问？
• 知道源站 IP 后，能否通过 Host 或 SNI 直接访问业务？
• Nginx 是否只信任 CDN 节点写入的真实客户端 IP 请求头？
• 应用读取的是经过校验的 remote_addr，还是任意客户端可伪造的请求头？
• 日志能否同时保留代理地址、原始连接地址和规范化后的客户端地址？

一、验证源站是否可以被直接访问

在授权测试机上使用 curl 的 resolve 参数，把业务域名临时解析到源站。该方式同时保留正确的 Host 与 TLS SNI，比直接访问 IP 更接近真实绕过路径。

curl -vk --resolve example.com:443:203.0.113.10 \
  

curl -sS --resolve example.com:443:203.0.113.10 \
  -D - -o /dev/null  CDN 访问和直连源站时的状态码、Server、缓存头、页面长度及证书信息：
curl -sS -D cdn.headers -o cdn.body 
curl -sS --resolve example.com:443:203.0.113.10 \
  -D origin.headers -o origin.body 

sha256sum cdn.body origin.body
diff -u cdn.headers origin.headers
如果直连源站返回完整业务页面，说明攻击者可能绕过 CDN 的限速、Bot 管理和部分 WAF 规则。即使返回 403，也要检查是否存在其他虚拟主机、备用端口或默认站点泄露。
验证应控制请求频率，不进行目录爆破、压力测试或未授权扫描。目标是证明边界缺失，而不是扩大影响。
二、检查真实 IP 信任边界
错误配置通常表现为应用直接信任 X-Forwarded-For，或 Nginx 将 set_real_ip_from 配置为 0.0.0.0/0。此时外部客户端可能伪造来源地址，影响访问控制、限速、审计和后台白名单。
可以先发送一个明显的测试地址，再检查响应、应用日志与 Nginx 日志是否把它误认为真实客户端：
curl -sk  \
  -H 'X-Forwarded-For: 198.51.100.77' \
  -H 'X-Real-IP: 198.51.100.77'
仅凭响应无法判断是否存在问题，必须结合服务端日志确认。建议临时增加诊断日志格式，同时记录连接源、规范化地址和转发链：
log_format edge_audit '$time_iso8601 '
  'remote_addr=$remote_addr '
  'realip_remote_addr=$realip_remote_addr '
  'xff="$http_x_forwarded_for" '
  'host="$host" request="$request" '
  'status=$status bytes=$body_bytes_sent '
  'request_id=$request_id';

access_log /var/log/nginx/edge_audit.log edge_audit;
其中 remote_addr 是 realip 模块处理后的地址，realip_remote_addr 保留原始 TCP 对端。若外部测试请求能够让 remote_addr 变成 198.51.100.77，而原始对端并非可信 CDN 节点，则信任边界配置错误。
三、Nginx 安全配置思路
不要信任全部网络，也不要凭经验填写长期不维护的地址段。应从 CDN 厂商官方接口或文档同步回源网段，并建立变更流程。以下仅为结构示例：
# 只能填写 CDN 官方公布并定期同步的地址段
set_real_ip_from 192.0.2.0/24;
set_real_ip_from 2001:db8:100::/48;

# 请求头名称必须与所用 CDN 的官方约定一致
real_ip_header X-Forwarded-For;
real_ip_recursive on;

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Request-ID $request_id;
        proxy_pass 
    }
}
如果 CDN 提供专用真实 IP 请求头，优先使用该头，并确保源站只能由 CDN 节点访问。否则，攻击者直连源站时仍可能自行构造同名请求头。
四、从网络层限制回源
最稳妥的做法是在云安全组、防火墙或上游 ACL 中只允许 CDN 回源网段访问 80、443，运维入口单独走 VPN、堡垒机或管理网。不要只依赖 Nginx 的 allow 和 deny，因为连接仍然到达主机，且配置遗漏时容易失效。
使用 nftables 时可以通过集合维护 CDN 地址。执行前应保留现有 SSH 会话，并先确认管理链路，避免把自己锁在服务器外：
nft add table inet edge
nft 'add set inet edge cdn4 { type ipv4_addr; flags interval; }'
nft 'add element inet edge cdn4 { 192.0.2.0/24 }'
nft 'add chain inet edge input { type filter hook input priority 0; policy accept; }'
nft add rule inet edge input tcp dport { 80, 443 } ip saddr @cdn4 accept
nft add rule inet edge input tcp dport { 80, 443 } counter drop

nft list table inet edge
生产环境应将规则写入配置管理系统，并采用“下载官方网段、校验格式、生成候选配置、语法检查、原子替换、失败回滚”的更新流程。不要直接把远程接口返回内容拼接进防火墙命令。
五、限制 Host 与默认虚拟主机
源站经常因为默认 server 返回业务内容而暴露。可以设置拒绝型默认虚拟主机，只为合法域名提供服务：
server {
    listen 80 default_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 example.com;
    # 正常业务配置
}
该措施不能替代网络层 ACL。因为 curl --resolve 仍能提供正确的 SNI 和 Host，所以只校验域名无法阻止已知源站 IP 的访问。
六、日志排查与留痕
发生疑似绕过时，可从源站日志中筛选“连接源不属于 CDN 网段”的请求。简单排查可先观察原始连接地址：
grep 'realip_remote_addr=' /var/log/nginx/edge_audit.log | tail -n 100

awk '{print $3}' /var/log/nginx/edge_audit.log \
  | sort | uniq -c | sort -nr | head
实际日志字段可能包含引号和空格，长期分析建议输出 JSON 日志并交给日志平台解析，不要依赖固定列号。至少保留以下字段：
字段
用途
realip_remote_addr
确认实际连接到源站的代理或客户端
remote_addr
记录经过可信代理链规范化后的客户端地址
X-Forwarded-For 原值
分析伪造、重复追加和代理链异常
Host、SNI、请求路径
判断虚拟主机绕过与资产探测
request_id
关联 CDN、Nginx 与应用日志
状态码与响应字节数
识别直连成功及异常响应差异
日志应设置访问权限、轮转和集中留存。安全事件期间避免立即覆盖原始日志；导出后计算哈希，并记录时间范围、时区与采集命令，便于后续复盘。
风险判定
高风险：源站可直接访问，且 CDN/WAF 承担认证、限速或漏洞拦截职责。
高风险：任意客户端可以伪造真实 IP，并影响后台白名单、支付风控或管理接口访问控制。
中风险：源站只泄露默认页面、证书或版本信息，但尚未证明业务绕过。
低风险：源站网络层已限制为 CDN 网段，真实 IP 头仅在可信连接上解析，日志链路完整。
修复与复测清单
在云安全组或上游防火墙限制 80、443 的回源来源。
仅信任 CDN 官方网段，禁止 set_real_ip_from 0.0.0.0/0。
为 CDN 网段更新设置自动化校验、审批和回滚。
默认虚拟主机拒绝未知 Host，但不把它当作唯一防线。
应用只使用反向代理规范化后的客户端地址，不直接读取任意转发头做鉴权。
同时记录原始 TCP 对端和规范化客户端 IP，使用 request_id 串联多层日志。
修复后分别从公网测试机、CDN 节点链路和运维网络复测，确认直连被拒绝且正常业务未受影响。
总结
CDN 解决的是加速与边缘防护问题，不会自动完成源站隔离。有效的防护需要三层同时成立：网络层只接受合法回源、代理层严格定义真实 IP 信任边界、日志层保留足够的原始证据。授权验证时，用少量可复现请求证明问题，再结合配置和日志给出修复闭环，通常比大范围扫描更有价值。