最近遇到个邪门事儿，有个客户的电商站明明挂了高防CDN，还是被刷了十几万假订单。查日志发现攻击者完美伪造了CDN节点IP，请求直接绕过了防护体系。这年头，连CDN都要“防队友”了——你以为套个盾就安全，殊不知源站验证没做好的话，高防CDN反而会成为攻击者的跳板。
IP伪造攻击早就不是新鲜玩意儿了。但很多人以为上了CDN就高枕无忧，其实大错特错。攻击者现在会先踩点扫描CDN节点IP段，然后伪造X-Forwarded-For这类标头，把垃圾流量包装成“合法CDN流量”直接打向源站。我去年实测过三家主流CDN服务商，其中有两家默认配置下居然允许任意IP声明自己是CDN节点，这安全漏洞简直比筛子还漏。
根源在于很多运维盲目信任CDN服务商提供的IP列表。但CDN节点IP是会更新的啊兄弟！上周刚更新的IP段名单，这周可能就失效了。更别说那些用云服务弹性IP的CDN厂商，节点IP变化比翻书还快。指望手动维护IP白名单？还不如直接给攻击者发请帖。
先说源IP验证这块。千万别再用那种网上下载的“CDN IP段大全”了，那玩意儿过期速度比酸奶保质期还快。我现在所有项目都改用动态认证机制：在CDN控制面板生成专属Token，然后通过自定义Header传递给源站。源站Nginx配置直接写死：
这招狠在哪？攻击者就算伪造了IP也拿不到Token。实测过CDN5和CDN07两家，配合自定义Header验证后，非法请求拦截率直接拉到100%。不过要注意Token得定期轮换，建议用密钥管理系统自动更新。
光有Token还不够。去年遇到个案例，攻击者通过社会工程学搞到了Token（某员工把配置文件丢GitHub上了），这时候就需要第二道防线——指纹识别。这技术原理其实特简单：给每个合法CDN节点打上数字水印，就像给特工发识别徽章似的。
我在08Host的节点上试过这么玩：在CDN配置里注入特定JS代码片段，源站通过检测这个指纹来确认身份。比如让CDN节点在返回响应时自动添加：
源站收到请求后，用同样的算法验签，时间戳偏差超过5秒的直接拒绝。这套方案最骚的地方在于，攻击者就算拿到密钥也没用，因为时间戳和节点ID都是动态变化的。具体实现可以用Lua脚本嵌入OpenResty：
现在说说性能开销问题。很多人一听“密码学验证”就头大，觉得会影响性能。其实实测下来，单请求验证延迟增加不到2毫秒。比起被DDoS打瘫的成本，这点开销几乎可以忽略不计。不过要注意密钥算法的选择，别傻乎乎用RSA这种重武器，ECDSA或者HMAC-SHA256完全够用了。
最近帮某金融平台做渗透测试时，发现个更隐蔽的攻击手法：攻击者会先合法访问CDN节点，抓取响应头里的指纹特征，然后尝试重放攻击。这时候光靠静态验签就不够了，得加上一次性随机数（Nonce）机制。我在CDN07的管理后台看到他们最新版已经支持Nonce生成器，每10分钟自动刷新一次种子值。
其实最省事的方案是直接用厂商提供的SDK。像CDN5的Edge Auth模块就封装了全套验证逻辑，源站只需要调个API就能验明正身。但千万别完全依赖黑盒方案——我就见过某厂商SDK被爆硬编码密钥的漏洞。现在我的做法是采用混合验证：既用厂商SDK做初步过滤，自己也实现一套备用的验签逻辑。
说到具体配置，给个Nginx实战示例。以下配置同时实现了IP白名单、Token验证和指纹签名三重防护：
最后吐槽下，有些小厂CDN服务商为了省成本，连基本的安全校验都懒得做。上次测试某家号称“智能高防”的CDN，发现他们居然把验证逻辑放在客户端JS执行——这不是明摆着告诉攻击者“快来绕过我吗”？所以选型时一定要技术团队实地测试防护方案，别光看宣传稿吹得天花乱坠。
真正靠谱的防护体系必须是多层次、动态化的。源IP验证只是地基，指纹识别是钢筋，还要配合流量行为分析（检测异常请求模式）、速率限制（防CC攻击）等一系列措施。我现在给所有客户部署方案时，都会要求至少每月做一次模拟绕过测试——安全这东西，没有一劳永逸的方案。
说实话，最近三年IP伪造攻击量翻了十倍不止。攻击工具都开始集成CDN指纹采集功能了，随便找个开源工具就能自动识别CDN厂商并抓取节点特征。防守方要是还停留在“配置个白名单就完事”的思维层面，被攻破真的只是时间问题。
最后分享个血泪教训：千万别在错误日志里泄露验证细节！见过有个系统会在验证失败时返回“签名过期”“Token无效”这种提示，这不等于是给攻击者递刀子吗？正确的做法是统一返回“404 Not Found”，让攻击者连失败原因都摸不着。
防护IP伪造攻击就像玩猫鼠游戏，没有银弹方案。关键是要建立持续演进的防御体系，毕竟攻击者的手段也在不断升级。至少从我的实战经验来看，结合动态Token和密码学签名的方案，目前还能把90%的伪造攻击摁死在源头。
