源站仅允许 CDN 回源的访问控制

上了 CDN（内容分发网络）站点还是被打挂，多半是攻击者绕过节点直连了源站 IP。源站只接受 CDN 回源流量，这条后路就断掉了。做法有两种，建议都上。 ## 一、IP 段白名单 CDN 服务商一般会公布回源 IP 网段，Nginx 里用 allow/deny 收口： ``` location / { allow 203.0.113.0/24; allow 198.51.100.0/24; deny all; } ``` 示例网段换成服务商文档里的实际值。这个方案的维护点在于回源段会不定期调整，漏更新新网段就会误杀正常回源，要把"核对回源 IP 列表"放进定期检查项。拿不准网段全不全，就把日志里来自已知网段之外、却带正常回源特征的请求拉出来核对，缺哪个补哪个。 ## 二、密钥头验证 更稳的方式是约定一个自定义请求头。在 CDN 的回源配置里追加： ``` X-Origin-Key: 用 openssl rand -hex 32 生成的随机值 ``` 源站校验这个头： ``` if ($http_x_origin_key != "上面生成的随机值") { return 403; } ``` 随机值足够长就不会被猜到，更换 CDN 服务商或怀疑泄露时换一个即可，不依赖维护 IP 列表。头的名字避开 X-Forwarded 这类常见前缀，起一个自家专属的名字，扫描器的字典里不会有它。 ## 三、两层叠加更稳 IP 白名单和密钥头同时开启，单独一层被绕过或误配置时还有兜底。部分回源请求还带固定的 Host 值，可以顺带校验 Host 头，进一步收紧。校验逻辑放 server 块还是 location 块按站点结构定，有多个子域时各自配一套，密钥可以共用同一个。 ## 四、防火墙再收一道口 Nginx 之外，用防火墙把 80/443 只对回源网段放行： ``` iptables -A INPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP ``` 务必先放行自己的管理 IP，否则连排查问题的入口都进不去。改防火墙规则前保留一个已连接的 SSH 会话，规则配错时，这条会话就是最后的退路。 配置完成做两个测试：浏览器直连源站 IP 应返回 403 或超时；正常走域名访问，页面和接口都要通。HTTPS 证书校验、回源 Host、回源协议这些环节任何一处不一致，都会让站点当场中断，验证要跑完整链路。