咖啡馆实战：网站反向代理与加速器场景下的真实 IP 信任边界审计

背景

网站接入 CDN、WAF 或 Nginx 加速节点后，源站通常会从 X-Forwarded-For、X-Real-IP 等请求头获取访客 IP。这类配置直接影响后台访问控制、登录限速、审计日志和封禁策略。

授权测试中经常遇到一种问题：应用无条件信任客户端提交的转发头，或源站允许绕过代理直接访问。攻击者因此能够伪造 IP，绕过仅限内网访问的管理功能，或者污染日志。下面以一套“CDN/Nginx/应用服务器”架构为例，说明如何验证信任边界并完成修复。

测试前应确认目标域名、源站地址、允许的测试时间以及日志保留要求。不要对未授权的 CDN 节点或共享基础设施进行扫描。

问题定位

先梳理请求链路，明确究竟由哪一层重写客户端地址：

• 边缘代理：接收公网请求，并追加或覆盖转发头。
• Nginx：使用 realip 模块还原客户端地址。
• 应用：读取框架提供的 remote address，或自行解析请求头。
• 业务组件：依据 IP 执行后台白名单、限速、风控和日志记录。

审计时重点回答三个问题：

• 源站是否只能由受信代理访问？
• Nginx 的 set_real_ip_from 是否严格限定了代理网段？
• 应用是否绕过 Web 服务器，直接读取用户可控请求头？

授权验证步骤

先建立基线请求，分别记录响应状态、响应长度、应用显示的客户端 IP，以及源站 access log 中的地址。以下命令中的域名和地址均应替换为授权测试环境。

curl -skD- 

curl -skD-  \
  -H 'X-Forwarded-For: 127.0.0.1' \
  -H 'X-Real-IP: 127.0.0.1'

curl -skD-  \
  -H 'X-Forwarded-For: 10.10.20.15'

如果第二个请求导致页面、响应头或审计日志中的客户端地址变成了伪造值，说明至少存在日志污染；如果第三个请求因此进入原本受 IP 白名单保护的管理页面，则已经形成权限边界绕过。

验证源站暴露问题时，不必进行大范围资产探测。已知并获准测试源站地址后，可以通过固定解析将请求直接发往源站：

curl -skD- --resolve  \
   \
  -H 'X-Forwarded-For: 10.10.20.15'

若直连源站能够成功访问，同时 Nginx 信任任意来源提供的转发头，风险会明显放大。测试结论中应分别记录“代理链路可伪造”和“源站可绕过”两个条件，避免只凭单次响应下结论。

Nginx 配置审计

高风险配置通常表现为信任范围过大，甚至信任全部 IPv4 来源：

# 错误示例：任何客户端都可影响 $remote_addr
set_real_ip_from 0.0.0.0/0;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

推荐只信任实际存在的反向代理网段，并由边缘代理覆盖外部传入的相关请求头：

# 仅示例，应替换成实际代理出口网段
set_real_ip_from 10.20.0.0/16;
set_real_ip_from 2001:db8:1200::/48;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

log_format audit '$time_iso8601 peer=$realip_remote_addr '
                 'client=$remote_addr host=$host request="$request" '
                 'xff="$http_x_forwarded_for" status=$status bytes=$body_bytes_sent';
access_log /var/log/nginx/access_audit.log audit;

$realip_remote_addr 可保留与 Nginx 建立 TCP 连接的对端地址，$remote_addr 则是 realip 模块处理后的客户端地址。两者同时记录，便于判断请求是否确实经过受信代理。

修改配置后先执行语法检查，再平滑加载：

nginx -t
nginx -T | grep -nE 'set_real_ip_from|real_ip_header|real_ip_recursive|access_log'
systemctl reload nginx

应用层代码检查

即使 Nginx 已正确配置，应用自行读取请求头仍会重新引入问题。以下 Python/Flask 写法不安全：

# 不安全：请求头由客户端直接控制
client_ip = request.headers.get('X-Forwarded-For', request.remote_addr)

应用应优先使用服务器传入的连接地址。只有在框架明确配置了可信代理数量或网段后，才允许解析代理头。例如 Flask/Werkzeug 可限定链路中可信代理层数：

from werkzeug.middleware.proxy_fix import ProxyFix

# 仅当部署拓扑确定为一层受信代理时使用
app.wsgi_app = ProxyFix(
    app.wsgi_app,
    x_for=1,
    x_proto=1,
    x_host=1,
    x_port=0,
    x_prefix=0
)

代理层数并非越大越兼容。配置超出真实链路层数后，框架可能继续向左读取用户注入的地址。部署拓扑变化时，应同步修改应用配置并回归测试。

日志排查

修复前可搜索包含私网地址、回环地址或异常长转发链的请求。下面的命令仅用于快速初筛，最终仍需结合代理出口地址和业务行为判断：

grep -E 'xff="([^"]*,){3,}|xff="(127\.|10\.|192\.168\.)' \
  /var/log/nginx/access_audit.log | tail -n 100

journalctl -u nginx --since '2 hours ago' --no-pager

建议关联检查以下信息：

• TCP 对端是否属于已登记的 CDN 或反向代理网段。
• 同一会话中客户端地址是否频繁变化。
• 伪造地址请求是否命中后台、导出、调试或运维接口。
• 登录失败、验证码和限速记录是否使用了错误的 IP 字段。

风险与修复建议

修复后应重复基线请求与伪造头请求。预期结果是：公网客户端提交的伪造头不会改变应用识别的地址；直连源站被网络层拒绝；正常代理流量仍可正确还原真实 IP；日志中同时保留代理对端和处理后的客户端地址。

总结

网站使用 CDN、WAF 或 Nginx 加速后，真实 IP 处理不只是日志格式问题，而是一条完整的权限边界。有效审计需要同时检查源站暴露、代理网段、Web 服务器 realip 配置、框架代理设置和业务白名单逻辑。修复时不要仅增加请求头过滤，应从网络入口、可信代理范围、应用取值方式和审计留痕四个层面一起收口。

这个场景审计的重点不是“能否读到 X-Forwarded-For”，而是确认只有受信代理才能参与客户端 IP 的计算。建议把入口拆成两条路径验证：经加速器访问、绕过加速器直连源站。

先检查源站是否暴露。若源站公网端口允许任意地址连接，攻击者可以直连并伪造转发头，应用层再严谨也容易失去意义：

curl -vk --resolve example.com:443:ORIGIN_IP \
   \
  -H 'X-Forwarded-For: 127.0.0.1' \
  -H 'X-Real-IP: 127.0.0.1'

源站防火墙应只允许加速器或反代节点网段访问；运维入口另行放行。云防火墙、安全组和主机防火墙都要核对，避免只配置其中一层。

Nginx 侧不要直接使用客户端提交的任意头。以代理使用 X-Forwarded-For 为例，应显式列出可信代理网段：

set_real_ip_from 10.20.0.0/16;
set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

log_format ip_audit
  '$remote_addr peer=$realip_remote_addr '
  'xff="$http_x_forwarded_for" request="$request"';

access_log /var/log/nginx/ip_audit.log ip_audit;

这里 $remote_addr 是解析后的地址，$realip_remote_addr 保留实际 TCP 对端。排查时两者应同时记录，否则遇到伪造或代理链变化时很难还原。可信网段应来自实际代理出口地址，不要为了省事写 0.0.0.0/0，也不要信任整个办公网或容器网段。

如果链路是“客户端 → CDN → 自建反代 → Nginx”，还要确认每一跳如何处理已有的 X-Forwarded-For。边界代理应覆盖外部传入值，再追加已验证的对端地址；不能原样透传用户提供的头。可以构造多段地址测试解析方向：

curl -sk  \
  -H 'X-Forwarded-For: 127.0.0.1, 198.51.100.23'

分别从公网直连、可信代理、代理内网节点发起请求，对照审计日志。尤其要验证以下情况：

• 直连源站时，伪造头不会改变最终客户端 IP；
• 经过可信代理时，能剥离代理自身地址并得到真实客户端地址；
• 多个同名 X-Forwarded-For、空值、IPv4-mapped IPv6 等输入不会绕过判断；
• 加速器更新出口网段后，防火墙和 set_real_ip_from 同步更新；
• 限流、封禁、后台白名单和审计日志使用的是同一个规范化后的 IP。

最后建议不要仅凭“真实 IP”授权后台或敏感接口。IP 白名单适合作为附加限制，认证本身仍应使用独立凭据或双向 TLS；否则可信代理账号、配置或出口节点一旦失陷，IP 信任边界也会同时失效。