网站服务器接入 CDN 后的真实源站暴露排查与加固记录

背景

最近帮一个中小型站点做授权安全检查，站点架构比较常见：域名接入 CDN，源站是一台云服务器，Nginx 反代 PHP-FPM，后台管理路径做了基础访问控制。客户的直观理解是“上了 CDN，源站 IP 就安全了”。但实际测试中发现，源站仍然可以被直接访问，并且绕过了 CDN 层的部分访问控制规则。

这个话题放在咖啡馆板块比较合适：它不是单纯漏洞复现，也不是工具使用，而是网站建设和服务器运维中很常见的安全边界问题。下面按一次真实排查流程展开，重点放在定位方法、配置检查、日志留痕和修复建议。

问题定位

授权范围内，先确认业务访问链路：

• 公网用户访问： CNAME 到 CDN 厂商节点
• CDN 回源到云服务器公网 IP
• 源站 Nginx 根据 Host 分发到业务站点

初步检查发现两个异常点：

• 直接访问源站公网 IP 时，仍然返回了业务首页。
• 使用源站 IP 加 Host 头访问，可以完整访问网站，且响应头中看不到 CDN 注入的特征头。

这意味着攻击者一旦拿到源站 IP，就可以绕过 CDN 的 WAF、CC 防护、访问频控以及部分地域策略，直接打源站。

技术分析

源站暴露通常不是单点问题，常见原因有几类：

• 历史 DNS 记录泄露，例如旧 A 记录、测试子域名、邮件记录。
• 源站服务监听 0.0.0.0，且安全组允许全网访问 80/443。
• Nginx 默认站点未限制，IP 访问也落到了业务 server 块。
• 回源鉴权缺失，源站只认 Host，不校验 CDN 来源 IP 或自定义回源头。
• 日志中没有区分 CDN 访问和直连访问，导致长期未发现。

这次的核心问题是：云安全组放行了 0.0.0.0/0 的 80、443，同时 Nginx 的 default_server 配置直接指向了业务站点。只要知道源站 IP，再带上正确 Host，就能绕过 CDN。

操作步骤

以下命令仅用于授权测试环境。先从客户端确认域名解析和访问链路：

dig  +short
curl -I 

# 测试源站 IP 是否可直接访问
curl -I 

# 带 Host 头访问源站，确认是否命中业务站点
curl -k -I  -H 'Host:  200、301、302，并且响应内容或 Location 指向真实业务路径，就需要继续看源站日志。
Nginx 默认日志如果只记录 remote_addr，在接入 CDN 后容易误判。建议临时增加一个更清晰的日志格式，把 Host、X-Forwarded-For、CDN 特征头都打出来。
log_format cdn_check '$remote_addr - $host [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     'xff="$http_x_forwarded_for" '
                     'realip="$http_x_real_ip" '
                     'ua="$http_user_agent" '
                     'cdn_ray="$http_cf_ray" '
                     'via="$http_via"';

access_log /var/log/nginx/access_cdn_check.log cdn_check;
重新加载配置后观察直连请求和 CDN 请求的差异：
nginx -t && systemctl reload nginx

tail -f /var/log/nginx/access_cdn_check.log
如果看到 remote_addr 是非 CDN 节点 IP，并且 Host 为业务域名，这类请求基本可以判断为直连源站。进一步可以统计最近一段时间是否已经存在绕过 CDN 的访问：
awk '{print $1}' /var/log/nginx/access_cdn_check.log | sort | uniq -c | sort -nr | head

grep ' /var/log/nginx/access_cdn_check.log \
  | grep -v 'cdn厂商IP段关键字或已知节点' \
  | tail -n 50
实际环境里不建议用 grep 简单排除 CDN IP 段做长期判断，更稳妥的是把 CDN 官方 IP 段维护成 allowlist，并在防火墙或 Nginx 层做限制。
关键配置示例
第一步，修正 Nginx 默认站点。不要让 IP 访问落到业务站点，可以直接返回 444 或固定的 403。
server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;

    ssl_certificate     /etc/nginx/ssl/default.crt;
    ssl_certificate_key /etc/nginx/ssl/default.key;

    return 444;
}
第二步，在业务 server 块中限制来源。更推荐在云安全组或系统防火墙层面只允许 CDN 回源 IP 访问 80/443。Nginx 层可以作为补充，但不要把它当唯一边界。
# 示例：仅演示结构，实际 IP 段应以 CDN 厂商官方公布为准
geo $cdn_allowed {
    default 0;
    203.0.113.0/24 1;
    198.51.100.0/24 1;
}

server {
    listen 80;
    server_name 

    if ($cdn_allowed = 0) {
        return 403;
    }

    location / {
        proxy_pass 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
第三步，如果 CDN 支持自定义回源 Header，可以增加一层轻量校验。注意这个 Header 不能暴露在前端响应中，也不要写得过于简单。
server {
    listen 80;
    server_name 

    if ($http_x_origin_verify != "change-this-to-a-long-random-value") {
        return 403;
    }

    location / {
        proxy_pass 
    }
}
这类 Header 校验不能替代 IP allowlist，因为 Header 可以伪造；但在“CDN IP 段更新滞后”或“多 CDN 回源”的场景下，它能提供额外防护。
日志留痕与排查重点
加固后建议至少观察 24 到 72 小时，重点看以下几类日志：
Nginx access 日志中是否仍有非 CDN IP 访问业务 Host。
Nginx error 日志中是否出现大量 403、444，判断是否有人在探测源站。
云防火墙或安全组日志中是否有针对 80/443 的直连扫描。
应用日志中是否存在异常后台路径访问、批量参数探测、异常 UA。
可以用一条简单命令查看被拦截的来源分布：
grep ' 403 ' /var/log/nginx/access_cdn_check.log \
  | awk '{print $1}' \
  | sort | uniq -c | sort -nr | head -20
如果在加固前已经发生过直连访问，建议回溯这些 IP 的请求路径。尤其关注：
/admin、/manage、/login 等后台入口。
/.env、/config.php、/backup、/sql、/zip 等敏感文件探测。
带有明显注入、文件包含、路径穿越特征的参数。
高频 POST 请求或异常 500 响应。
风险与修复建议
问题
风险
建议
源站 IP 可直接访问
绕过 CDN 防护，直接消耗源站资源
安全组仅允许 CDN 回源 IP，默认站点 return 444
Host 头即可命中业务
攻击者可通过源站 IP 访问完整业务
业务 server 限制来源，并校验回源 Header
日志未区分真实来源
难以及时发现直连和绕过行为
记录 XFF、Host、CDN 特征头，定期统计异常来源
历史解析记录泄露
源站 IP 被动暴露
清理旧 A 记录、测试域名，源站换 IP 后同步加固
个人经验：很多站点并不是被“打穿 CDN”，而是源站一直裸露在公网。CDN 只能保护经过它的流量，不能自动保护错误开放的源站端口。
总结
网站接入 CDN 后，真正要确认的是“用户是否只能通过 CDN 到达源站”。排查时不要只看 DNS 是否 CNAME 到 CDN，还要验证源站 IP、Host 头、默认站点、安全组和访问日志。比较稳的加固顺序是：先收敛云安全组，再修正 Nginx 默认站点，然后增加回源 Header 校验，最后通过日志持续观察。
这类问题不复杂，但很容易被忽略。对中小站点来说，把源站访问边界处理好，往往比堆很多上层安全策略更实际。