CC攻击防护结合CDN隐藏网站源站IP

CC攻击的本质是耗尽服务器资源，而隐藏源站IP则是让攻击者根本找不到你的真实服务器。两者结合，不是简单叠加，而是把防御从“被动挨打”前置到“无法锁定目标”。很多站点只做了CDN加速，却忽略源站IP已经通过历史DNS记录、邮件头、子域名、SSL证书指纹等方式泄露，结果攻击者绕过CDN直连源站，防护形同虚设。所以真正有效的做法，是先彻底隐藏源站IP，再在CDN层做CC攻击策略，最后在源站做兜底限制。

先解决源站IP泄露的问题。最直接的检查方法是查看域名的历史解析记录，很多安全情报平台都能查到过去几年的A记录变化。如果之前域名直接解析到过真实服务器IP，这个IP就已经进入攻击者的字典库。此时换一个新IP是必要的，不是可选项。换IP之后，立即把域名解析全部切到CDN的CNAME或NS，源站只允许CDN回源节点访问。在源站防火墙里，把CDN厂商公布的回源IP段加入白名单，其余所有IP一律拒绝443和80端口。这个动作能挡住99%的绕过CDN直连扫描。

每家CDN服务商都会公开自己的回源IP段，例如阿里云、腾讯云、Cloudflare都有对应的IP列表。在源站的iptables或云安全组里，只允许这些IP段访问Web端口。配置时注意，CDN厂商会不定期更新IP段，需要定期同步。如果源站还承载其他服务，比如SSH、数据库，这些端口不要对公网开放，只允许自己的办公网IP或跳板机访问。这样即使攻击者拿到源站IP，也无法直接访问Web服务。

# 示例：只允许CDN回源IP段访问80和443端口
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 192.0.2.0/24 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP

除了防火墙，源站Web服务器本身也要做访问来源校验。Nginx或Apache可以配置只响应带有特定回源标识的请求。很多CDN支持自定义回源请求头，源站校验这个头，不匹配的直接返回444或403。这样即使攻击者通过某种方式连到源站，没有正确的回源头也会被拒绝。这个方法比单纯依赖IP白名单更灵活，因为IP段可能被伪造或误伤，而自定义头只有CDN和源站知道。

隐藏源站之后，CC攻击的主要压力就集中在CDN节点上。CDN本身有分布式带宽和连接处理能力，但如果不做策略，攻击流量也会消耗你的CDN账单，甚至触发CDN的回源保护机制导致服务降级。所以要在CDN控制台开启CC防护模块，设置合理的频率阈值。一般建议单IP每秒请求数超过20次就触发验证码或直接拦截。但这个阈值要根据业务类型调整，静态资源站可以更严格，API接口站要结合业务峰值设置。

更精细的做法是基于请求特征做拦截。CC攻击通常有固定模式，比如大量请求同一个URL、User-Agent异常、Referer为空、Cookie缺失等。在CDN的WAF规则里，把这些特征组合起来，命中就拦截或挑战。例如，对没有合法Cookie的请求直接返回302跳转到验证页面，验证通过后种下Cookie，后续请求放行。这种方式对工具化的CC攻击非常有效，因为大部分攻击脚本不会执行JavaScript，也就无法通过验证。

即使CDN层做了防护，仍可能有漏网之鱼或者攻击者直接针对源站发起慢速连接攻击。源站需要有自己的限速模块。Nginx可以用limit_req和limit_conn模块限制单IP的请求速率和并发连接数。注意这里的单IP指的是CDN回源节点IP，所以阈值要设置得足够高，避免误伤正常用户。更合理的做法是结合CDN传递的真实客户端IP，用real_ip模块获取客户端真实IP，然后针对真实IP做限速。

# Nginx 获取CDN传递的真实客户端IP
set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

# 限制单IP请求速率
limit_req_zone $binary_remote_addr zone=cc_limit:10m rate=10r/s;
limit_req_status 429;

源站还可以配置连接超时和缓冲区大小，防止慢速攻击占用连接资源。client_header_timeout、client_body_timeout设置短一些，比如5秒。对于没有数据传输的连接，及时断开。同时，源站日志要记录真实客户端IP，方便事后分析攻击来源。如果CDN传递的X-Forwarded-For头被伪造，可以在CDN层清洗掉这个头，由CDN重新写入真实IP，源站只信任CDN回源IP传来的这个头。

隐藏源站IP还有一个容易被忽视的泄露点：SSL证书。如果源站和CDN使用同一个证书，攻击者可以通过证书透明日志或全网扫描找到所有使用该证书的IP。解决办法是源站使用自签名证书或单独的内部证书，CDN使用公开的证书。CDN回源时，如果源站证书是自签名的，需要在CDN回源配置里关闭证书校验或指定信任该自签名证书。这样外部扫描到的证书只对应CDN节点，无法关联到源站。

DNS配置方面，确保所有子域名都走CDN，不要有任何一个子域名直接解析到源站。攻击者经常通过扫描常见子域名，比如mail、ftp、direct、origin等，找到直连源站的入口。定期用子域名枚举工具检查自己的域名，发现直连源站的子域名立即处理。另外，源站IP不要出现在任何公开的SPF记录、TXT记录或DNS历史里。如果之前有，换IP后要清理干净。

CDN的CC防护阈值不是越高越好，也不是越低越好。阈值太高，攻击流量消耗资源；阈值太低，误杀正常用户。一个实用的方法是先观察正常业务的峰值请求速率，取峰值的1.5到2倍作为阈值。比如正常单IP每秒最多请求5次，阈值就设8到10次。对于登录、注册、搜索等敏感接口，单独设置更严格的规则，比如每秒2次，超过就要求验证码。对于静态资源，可以设置较高的阈值，因为静态资源命中缓存后不消耗源站资源。

另一个关键点是区分攻击流量和正常突发流量。电商大促、抢票、秒杀场景下，正常用户也会在短时间内集中请求。这时候单纯按频率拦截会误伤。可以结合请求路径、参数、Cookie、设备指纹等多维度判断。例如，正常用户在抢购前会先浏览商品页、加入购物车，有完整的会话流程；攻击脚本往往直接请求下单接口，没有前置行为。在CDN的WAF里配置基于行为序列的规则，能有效区分两者。

如果发现源站IP已经泄露并且正在遭受攻击，不要慌张。第一步是在源站防火墙临时封禁攻击IP，但这不是长久之计，因为攻击者会换IP。第二步是立即更换源站IP，同时保持CDN配置不变。换IP的过程要快，尽量减少服务中断。第三步是排查泄露渠道，修复漏洞。第四步是在CDN层加大防护力度，观察攻击是否转移到CDN节点。如果攻击者已经拿到新IP，说明泄露渠道还在，需要重新排查。

有些场景下，源站IP无法频繁更换，比如使用独立服务器且IP与业务绑定较深。这时候可以在源站前面加一层反向代理，比如用另一台云主机作为中间层，源站只接受中间层的连接。攻击者即使拿到中间层IP，也无法直接打到源站。中间层可以做简单的限速和过滤，把压力再分散一层。这种架构增加了运维复杂度，但在IP无法更换的情况下是有效的折中方案。

隐藏源站IP不是一次性工作，需要持续监控。定期检查域名的DNS解析是否全部指向CDN，检查源站防火墙规则是否仍然只放行CDN回源IP段，检查是否有新的子域名出现。同时，从外部网络模拟攻击者视角，尝试绕过CDN直连源站。可以用curl指定Host头直接访问源站IP，看是否返回网站内容。如果返回了内容，说明源站仍然暴露，需要立即处理。

CC攻击防护同样需要持续调优。攻击手法在变，业务流量也在变。每周分析CDN的拦截日志，找出被拦截的请求特征，判断是否有误杀。对于被误杀的IP或UA，加入白名单。对于新出现的攻击模式，更新WAF规则。把这项工作流程化，才能保持防护的有效性。最终的目标是让攻击者找不到源站，即使找到也打不进去，即使打进去也消耗不了多少资源。