做企业网站防护这些年CC攻击是我见得最多、也最容易被低估的攻击方式。很多人一听“CC防护”就觉得不就是防几个请求吗DDoS都能扛CC怕什么。实际情况恰恰相反CC攻击是典型的“蚂蚁啃大象”——单个请求看起来完全正常但只要量上去了服务器的CPU、数据库连接、应用线程就会被一点点耗尽页面从秒开变成白屏最后连登录页都打不开。这篇文章我想把CC防护这件事从头到尾捋一遍。从攻击的技术原理讲起再到企业级防护架构该怎么设计最后落到德迅云安全这类云防护服务上说说落地接入时我实际踩过的一些坑和调优思路。无论你是刚接手公司网站的运维还是正在选型防护方案的开发负责人这篇内容应该都能给你一个比较完整的参考框架。1. CC攻击的技术原理与攻击特征1.1 CC攻击到底是什么和DDoS有什么区别CC攻击的英文全称是Challenge Collapsar前身是DDoS攻击的一种变种但它攻击的目标完全不同。传统DDoS攻击打的是网络层和传输层靠大量数据包塞满带宽或者耗尽防火墙连接表让服务器“收不到”正常请求。CC攻击走的是应用层它模拟的是真实用户的HTTP请求打的是Web应用的处理能力。打个比方普通DDoS像是把一条高速公路全部堵死所有车都进不来CC攻击则像是派一群人涌进商场每一层的扶梯、电梯、收银台全部占满每个人都问一句“这件商品多少钱”但就是不买。商场的保安检查每一个进来的顾客都合法问题不是“能不能进门”而是“服务资源被消耗完了”。正因为请求本身是合法构造的传统基于IP和流量的清洗方案对CC攻击效果很差。我在实际处理中遇到过很多次带宽和防火墙CPU都很正常但业务就是卡死日志里全是同一类HTTP请求这就是典型的CC攻击特征。1.2 识别一次CC攻击的5个典型特征判断是否正在遭受CC攻击不要只看服务器负载而是要把请求日志、网络连接、访问行为结合起来看。我通常会按下面几个维度快速判断请求频率异常单个IP或单个用户代理User-Agent在短时间内发出大量请求远超正常访问节奏。比如一个普通用户一分钟请求20次页面已经算高频了攻击时一个IP可能一秒钟请求几十甚至上百次。目标资源固定攻击请求通常集中在某个消耗较大的接口上比如搜索接口、登录接口、报表下载接口、分页查询接口。攻击者会选择那些需要大量CPU计算或数据库查询的URL用最少的请求量打垮后端。请求特征单一日志里大量请求的User-Agent、Referer、Accept-Language等头信息完全一样或者在一个很小的集合里轮换。正常用户访问时这些字段是比较分散的。流量曲线呈脉冲状攻击流量不是一个持续的高峰而是每隔一段时间突然涌起一波打一会儿停一会儿。这种脉冲式攻击就是为了绕开防护规则的速率限制。地域和IP分布集中如果突然发现大量请求来自同一个IP段、同一个运营商或者来自某个不在业务范围内的地区那大概率是攻击流量。以上特征不一定全部命中但只要中了三条以上就要开始警惕了。我见过很多企业被CC打了大半天才发现就是因为只看服务器CPU而忽略了请求日志的特征分析。1.3 为什么传统防护手段经常失灵很多企业第一反应是“我用防火墙限个速不就行了”但实际效果往往不理想。原因有几个攻击源IP是动态变化的。CC攻击常用代理池或僵尸网络发起源IP成千上万而且随时切换静态封IP根本封不过来。限速参数难以界定。设得太宽防不住攻击设得太紧会误伤正常用户。尤其是电商、资讯类网站正常用户本身就存在高并发访问场景用固定阈值很难区分。应用层问题需要应用层解决。防火墙和流量清洗设备能看到四层以下的流量但判断不了“这个POST请求是搜索还是下单、这个查询是否消耗了大量数据库资源”。只有具备应用层检测能力的防护方案才能做精细判断。所以真正有效的CC防护一定要建立在应用层流量分析和动态行为判断的基础上而不是单纯靠网络层的限速和封禁。这也是我后面讲架构设计时反复强调的一点。2. 企业级CC防护架构设计2.1 整体架构的三个关键层次一套能用的企业CC防护架构至少要包含三个层次入口流量清洗层、应用层检测层、源站保护层。入口流量清洗层负责把流量先“过一遍水”过滤掉明显的恶意流量比如已知攻击源IP、畸形HTTP报文、高频连接等。这一层通常由高防IP或云清洗集群承载带宽容量要大至少是业务正常峰值的3到5倍否则攻击一来直接被带宽打满后面的防护都无从谈起。应用层检测层是CC防护的核心。它需要做的是对每一条HTTP请求进行深度检测包括请求频率统计、请求特征识别、浏览器指纹校验如JS Challenge、Cookie合法性校验等。这一层要能区分“真实用户”和“恶意脚本”并且具备动态封禁能力。源站保护层则是兜底方案。即使前两层全部被穿透源站也要能扛住一定的冲击。做法包括隐藏源站IP、限制源站并发连接数、数据库连接池隔离、接口熔断降级等。很多企业把源站IP直接暴露在DNS记录里防护做得再好也等于白做。2.2 流量调度与高可用设计架构设计的另一个重点是流量调度。CC攻击防护不能做成“单点接入”否则清洗节点本身被打垮全站就瘫痪了。合理的做法是采用多节点就近接入。用户在DNS解析阶段通过智能线路调度访问最近的清洗节点清洗节点之间做流量负载均衡当某个节点即将达到容量上限时自动将部分流量调度到其他冗余节点。这需要考虑切换和回落机制关键节点要有双活条件不能一个机房断网就全军覆没。高可用设计上要特别关注清洗节点的容量规划。我之前遇到过一种情况防护服务商宣称提供100Gbps的清洗能力但实际业务流量是单节点20Gbps一旦攻击流量达到50Gbps节点已经开始丢包业务直接受损。选型时一定要确认是单节点容量还是集群总容量不能用集群总量来对抗单点攻击。2.3 防护策略的自动化与联动CC防护策略不能“配一次就不管了”攻击方式在变业务情况也在变。好的架构应该包含自动化的策略调整机制。比如当检测到某个URL的请求频率突然飙升时系统能自动触发对该URL的限速策略同时向运维人员发送告警当某个IP段在短时间内反复触发校验码错误时能自动加入观察名单经过人工或自动复核后加入黑名单当攻击流量超过某个阈值时能自动切换到更高级别的防护模式比如强制启用验证码或JS Challenge。我曾经帮一家电商客户做过一次应急响应的复盘发现他们最终能撑住那次攻击除了云防护的基础能力之外最大的功臣是自动化的CC防护策略和人工的快速研判流程从接收到告警、分析攻击特征、调整策略到流量恢复正常整个过程不到20分钟。这在完全靠人工操作的防护体系里几乎不可能做到。3. 德迅云安全落地实践3.1 接入前的准备工作这里以我实际接触过的德迅云安全防护服务为例说说企业接入CC防护的完整流程和注意事项。德迅云安全提供的防护能力本质上是把DNS解析介入云端清洗节点业务流量先经过安全节点检测再反代回源站。这种方式最大的优势是无需改动业务服务器只需要调整DNS解析记录和相关配置即可适合大部分传统Web应用。接入前有几件事必须提前确认源站IP的保密接入前检查历史DNS解析记录确保源站IP没有在公网暴露过。如果无法确认建议先更换源站IP再接入云防护。否则攻击者完全可以绕开防护直接打源站。业务域名的备案状态云防护服务通常要求接入域名已完成ICP备案否则无法提供解析服务。这个问题很多企业临到接入才发现耽误上线进度。业务回调地址和API接口如果业务涉及支付回调、第三方API回调等场景需要提前梳理回调来源IP或确认是否支持放行策略避免防护开启后回调请求被误拦截。HTTPS证书的准备接入后流量会经过云节点需要把证书上传至防护平台或使用平台提供的证书管理功能。3.2 典型接入流程和关键配置德迅云安全的接入流程在控制台操作上是比较标准化的大致分成五个步骤第一步添加防护域名。在控制台添加需要防护的域名填写源站IP或源站域名。这里如果有多台源站服务器建议全部填上并在源站配置时设置不同的权重实现简单负载均衡。第二步配置防护模式。平台一般提供“DNS解析接入”和“反向代理接入”两种模式。我一般建议选反向代理接入因为这种模式下CDN节点能够真正看到HTTP层的数据做CC防护时精度高得多。第三步下发CNAME记录。替换掉你原来的DNS的A记录改为平台提供的CNAME地址。这一步需要去域名DNS服务商那里操作。CNAME解析生效时间一般在几分钟到几十分钟不等取决于DNS缓存刷新速度。第四步配置SSL证书。如果业务是HTTPS访问必须在平台上传证书。这里要注意证书的私钥和证书链要完整很多人在这一步漏了中间证书导致部分老旧客户端无法正常访问。第五步开启CC防护策略。平台默认会有一套基础防护策略建议先观察24小时根据防护日志和正常业务流量数据做调整不要直接调到最高档。3.3 防护策略配置与参数调优附一份参考方案CC防护配置最忌讳一刀切。不同业务场景对请求频率的容忍度完全不同。比如一个企业官网正常日UV可能就几千单个IP一分钟请求十次已经算很高了但一个API服务单个客户端一分钟请求几百次可能是正常行为。所以策略参数必须结合业务基线来设定。我常用的一个调优思路是阶梯式防护分成日常基础防护、增强防护和紧急最高防护三档。日常模式下单IP每秒请求数超过20次触发客户端验证超过50次直接封禁10分钟增强模式下单IP每秒超过10次就触发验证30次直接封禁紧急模式下所有访问都要求先通过JS Challenge验证单IP秒级超过5次就封禁。这个参数范围仅供参考具体要结合服务器性能来定前提是要先明确服务器压测数据支撑的QPS能力上限。配置时还有几个容易忽略的细节全局访问频率阈值要区分“动态请求”和“静态请求”。静态资源图片、CSS、JS可以由CDN缓存扛住不必触发CC校验否则会增加漏拦风险同时增加校验噪音。要单独给搜索爬虫设置白名单。搜索引擎的蜘蛛访问频率远高于普通用户如果按照常规阈值去限制很可能会把百度、谷歌的蜘蛛全部误封对SEO影响非常严重。IP黑名单要支持自定义批量导入和导出同时设置过期时间。CC攻击的源IP变化非常快有些已经不再活跃的IP继续留着只会增加匹配开销可以定期清理过期封禁。4. 常见问题与排查技巧实战4.1 误拦正常用户怎么办CC防护被吐槽最多的就是误伤。明明没有攻击正常用户却被弹验证码甚至直接被封IP。这个问题的根源通常有三个防护阈值设置得太低把正常的高频访问当成了攻击。公司办公网出口IP往往是NAT出来的多个内网用户共享同一个公网IP某一个用户频繁刷新页面导致同IP下所有同事都被封禁。反向代理、CDN回源节点没有加白名单导致云防护把CDN节点的统一出口IP误判为攻击源。排查时我一般会先看防护平台的拦截日志确定误封的IP是真实用户IP还是CDN回源IP。如果是CDN回源节点一定要在防护配置里添加回源IP白名单否则用户的正常请求经过CDN后会统一带上CDN节点IP而任何一个CDN节点的出口IP是整个区域用户共享的此时再按IP维度限速就完全失去了区分意义。如果是公司办公网出口IP解法是放宽阈值并开启Cookie验证机制让合法用户在第一次访问时通过验证后放行一段时间避免每次都触发频率限制。这里有个经验优先用Cookie验证而不是IP封禁。Cookie验证对用户体验影响小用户在首次访问时可能多等几百毫秒之后一段时间内的请求都不再受限制。IP封禁应该是最后一道手段只针对确认的恶意源。4.2 防护效果不达预期的排查思路有客户问我为什么开启了防护还是被打挂了。每次遇到这种问题我的排查顺序都是固定的第一步确认攻击是不是直接打在源站IP上。查询源站IP是否出现在公网历史数据库中或者直接看向防护平台的日志看攻击请求有没有被正常转发过来的记录。如果攻击流量根本没经过云防护节点说明攻击者直接打源站IP进行活动DNS解析记录和回源信息没有做好保密与联动。第二步确认回源是否超时。云防护节点和源站之间的链路如果不够稳定防护节点会不断重试连接源站导致源站连接数被瞬间占满。这种情况看起来像CC攻击其实源头是回源链路问题。解决方案是增加回源线路质量、配置回源多线路同时限制回源连接数。第三步确认防护规则的生效范围。有些策略只配置了对单个URL的防护但攻击流量会随机分散到多个URL有些策略只配置了某一层比如只做了IP限速但没做Cookie验证和特征匹配。CC攻击的方式非常多不要把鸡蛋放在一个篮子里IP限速、Cookie验证、User-Agent校验、行为分析都要开起来。4.3 遭遇混合攻击怎么处理现在攻击者很少只用一种手段。最常见的是DDoS大流量清洗CC应用层攻击同时进行目的就是让云防护的两层防护互相干扰。带宽被DDoS打满时CC清洗节点的处理能力会受到影响CC攻击导致源站资源耗尽时又会让云防护误以为源站故障而触发切回导致防护失效。应对混合攻击我最推荐的做法是重写源站的高可用架构把必须的能力和可选的能力分离。比如数据库和应用服务分开部署应用无状态化可以被快速扩容数据库做一主多从结构即使应用层被拖垮恢复速度也会快很多。同时配置熔断机制当某接口的响应时间超过一定阈值时自动返回缓存结果而不是继续请求数据库避免雪崩效应。另外一个容易被忽略的点是监控告警的优先级设置。混合攻击发生时告警信息可能非常多如果所有告警都是同一级别运维人员根本无法分辨哪些才是真正需要立即处理的。我习惯把告警分级大带宽攻击、源站不可达、核心接口成功率暴跌设为P0级CPU高、请求量突增、部分地域访问异常设为P1级其余策略调整类通知设为P2级。告警级别清晰应急响应的效率会明显提升。4.4 防护成本与业务连续性之间的权衡最后说一个很多决策者关心但很少被公开讨论的问题CC防护的成本。防护不是越强越好。最高等级的防护会主动拦截大量“可疑但未必恶意”的请求对用户体验的影响是存在的可能影响转化率。而低等级防护虽然用户体验好但在高强度的攻击下被击穿的风险也更高。所以需要根据自己业务对可用性的容忍度来确定防护等级。我的建议是给核心业务和边缘业务设置不同的防护策略。核心交易链路、登录注册等高价值接口使用更严格的校验策略确保极端情况下优先保住核心功能在线即可资讯展示、静态资源等次要内容则使用宽松策略。这种分级防护既能节省防护资源也能把业务连续性的风险控制在一个可以接受的范围内。5. 写在最后的一点体会CC防护这件事说难并不难原理、架构、产品、配置都是可以学习和复制的但真正落地到自己的业务上一定会遇到各种文档里没写明的情况尤其是业务流量模型和攻击特征交织在一起的时候。我自己做了这么多年防护最大的体会是三个词基线、分层、演练。基线是必须清楚自己业务正常流量的样子没有基线就谈不上识别异常分层是从网络层到应用层再到源站每层承担各自的职责不要把希望寄托在单一手段上演练是防护方案不是配上就完事了定期模拟一次攻击把应急响应流程跑通才能在真正的攻击来临时从容应对。另外还有一个小建议给正在做方案选型的朋友选择云防护厂商时不要只比价格和带宽数量更要看对方的清洗节点分布是否覆盖你的用户区域、防护响应团队是否能提供及时的技术支持以及厂商是否愿意陪你把参数调优到匹配你的业务。防护是持续优化的过程不是一次性采购。