套上CDN 之后，CDN厂商一般会在回源时，将真实的客户端地址写入header 中，例如cloudflare 是CF-Connecting-IP，阿里云是Ali-Cdn-Real-Ip，当然也可以从X-Forwarded-For 中取。另外7层的负载均衡服务在转发时，也会携带此类header。

如果源站是按照此类header 进行ACL 判定的话，容易被篡改绕过。

例如：

1. 攻击者先用censys 过滤证书信息，找寻到可能的源站。
2. 按照目标站点cname 指向的域名找出对应的CDN厂商，找到对应的header 头；
3. 伪造header 头对源站发起探测；

最保险的是在源站配置防火墙或ACL，只让CDN厂商的回源服务器段访问，参考Allow Cloudflare IP addresses。

题外话，NGINX 1.19.4 有个新特性 ssl_reject_handshake on;，开启后，IP 访问时会终止 TLS 握手，降低证书暴露的可能性。

好文推荐：那些隱藏在 CDN 中的危險：為什麼 CDN 可能沒有你想的那麼安全

同样的风险，也存在与ProxyProtocol协议，以及TOA等扩展协议中。

这类协议，大多数都运行与内网之中。如果你的Nginx 在公网接收一个固定来源的ProxyProtocol，请务必开启网络层IP白名单。

另外看产品介绍，阿里云的全站加速DCDN、以及DDoS高防 ，腾讯DDoS防护均支持了TOA，TOA本身并无签名机制，所以如果你依赖 TOA 传递的地址做 ACL，也需要尽可能开启网络层白名单。

参考项目：BeichenDream/FakeToa。

最后，你可能会问，地址空间那么大，攻击者如何能猜测出我的来源地址白名单。

试想一下：

1. 我们在写ACL 的时候，是不是都喜欢把保留地址段和回环地址写入；
2. 某些机构出口白名单并没那么隐秘，例如通过地址库或者关联主体的ASN号收集，或其他资产收集方式；