1. 先搞清楚CC攻击和DDoS攻击到底是不是一回事我见过太多人把CC和DDoS混为一谈尤其在跟客户沟通的时候经常听到我们被DDoS了特征是有大量请求打不进来。但实际情况往往分成两种截然不同的场景一种是带宽被塞满你的服务器还能登录但外网访问奇慢无比另一种是带宽正常但你的进程列表里全是php-fpm或Apache的活线程CPU被打到100%服务直接假死。前者多半是DDoS后者多半是CC。在正式聊识别和防御之前必须先把两个概念掰开因为选错方向防御手段基本就废了。DDoS全称是Distributed Denial of Service分布式拒绝服务核心在于流量——攻击者控制大量僵尸主机同时向目标发送数据包目的是把带宽、交换机端口、防火墙会话表这些流量通道打满。而CC攻击在中文语境里通常指Challenge Collapsar前些年是从Collapsar这个黑洞设备来的叫法放到现在更精确的对应是HTTP Flood也就是应用层的恶意请求洪泛。它打的是你的业务接口、登录页面、搜索接口这些消耗CPU和数据库连接的地方。打个比方DDoS相当于有人雇了一群搬运工把你店铺的大门用沙袋堵死顾客进不来。CC呢则是一群假装顾客的人挤在你的收银台前反复问这个多少钱不买但也不走把收银员累瘫。前者堵路后者耗人。两者最本质的区别在于攻击发生的协议层级DDoS主要发生在网络层和传输层L3/L4CC主要发生在应用层L7。这个区别直接决定了你在哪个环节做防御以及用什么手法做识别。搞反了的话用网络层的手段去防应用层的攻击基本等于拿盾牌挡子弹但是人家用的是毒气你得先知道对手用的是哪种武器。好在这个领域已经有比较清晰的行业惯例大流量DDoS用流量清洗、黑洞路由、高防IP来解决CC攻击则需要靠限速、验证码、WAF规则、IP信誉库、行为分析这类应用层手段来解决。两者需要联动但又不能互相替代。2. 攻击者常用的套路从SYN Flood到低频CC2.1 网络层和传输层流量型的工具玩法我们先看DDoS这边的常见打法。最老牌的是SYN Flood攻击者伪造海量源地址向目标服务器的固定端口发起TCP握手请求但永远不完成第三次握手。服务器内核里维护的半连接队列会被塞满新的正常连接进不来表现为用户访问时一直转圈、超时。防御这类攻击的关键是优化TCP协议栈参数比如开启syn_cookies同时前置流量清洗设备去代理完成握手验证。UDP Flood也很常见。攻击者往目标端口疯狂扔UDP报文用来打满带宽或者打NTP反射放大、DNS反射放大这类手法——攻击者用小的查询包骗公网上的NTP/DNS服务器往你的IP回大流量。尤其NTP反射放大放大倍数可以到几百倍是历史上很多大流量攻击的主力方式。这类攻击的特征在网络层非常明显入向流量瞬间飙升流量构成里特定协议占比异常高源端口和目的端口高度集中。还有一类相对进阶的是TCP Connection Flood不是半连接而是完整建连但不发数据占住你的连接表项。这种攻击不会让带宽爆炸但会让服务器的连接数达到上限内存耗尽表现同样是无响应。很多传统网络层清洗设备在识别这种攻击时会有延迟因为它特征不突出。2.2 应用层CC攻击的小流量高杀伤CC攻击这几年最大的变化是从高并发打爆转向低而缓的逼疯式打法。早年的CC脚本就是单线程或几十线程循环请求一个动态页面UA特征固定、频率有规律、容易识别。现在的CC攻击更聪明攻击者会在真实代理池的基础上做源IP轮换每个IP每秒只发一两个请求但整体并发规模可能达到数万。这种攻击的带宽占用可能才几百兆但足以把你的数据库连接池打满让所有业务接口超时。高频CC的打法也分几种。一种是直接打首页和商品详情页这类页面通常走缓存还好另一种是打搜索接口、登录接口、下单接口这些都是查数据库甚至写数据库的操作一个请求的CPU开销可能是静态页面的几十倍。有些攻击者还会专门挑你的慢接口打比如导出报表、批量查询并发一上来线程池直接耗尽。这就是为什么我前面强调识别CC攻击不能只看流量要看应用性能和错误率。另外注意一个术语混淆很多人把CC说成是Challenge Collapsar其实今天是拜攻击脚本所赐CC已经泛化成应用层HTTP攻击的代名词。不用纠结字面意思你只需要知道凡是针对应用资源消耗的攻击在行业实践中都归入CC大类的防御策略里。3. 攻击来临时的识别信号别等用户告诉你卡了才动手3.1 四层识别流量型攻击的指标快照识别DDoS最直接的信号是带宽和PPS每秒数据包数。正常业务的带宽曲线是平滑的有高峰有低谷但很少出现瞬间的陡峭爬升。如果某天你的出口带宽在1到3分钟内从2Gbps冲到10Gbps且没有预兆不是发布会、不是整点活动基本可以判断是流量型攻击。此时你ssh进服务器可能还很流畅——因为瓶颈在运营商链路而不是你的服务器CPU——但用户已经访问不了。PPS指标同样重要。有些攻击是小包攻击比如SYN Flood一个包只有几十字节带宽占用不高但每秒几十万的包量会把服务器的网卡中断打到满负荷CPU被软中断吃掉。所以监控里如果发现PPS异常高、而带宽没有对等上升也要警觉。我一般建议运维同学同时盯五个数入向带宽、入向PPS、SYN_RECV状态连接数、Established连接数、以及交换机或防火墙的会话表使用率。其中SYN_RECV大量堆积是SYN Flood的典型标志Established高企且空转是Connection Flood的标志。3.2 七层识别从访问日志里找CC攻击的指纹CC攻击的识别更依赖应用侧的观察。最实用的做法是先看QPS每秒请求数的分布再看指定接口的耗时和错误率。攻击来临前日志里的特征是集中某个URL的请求数暴涨且来源IP分散但User-Agent异常集中或异常分散有的攻击脚本所有请求都是同一个UA有的则随机伪造几百种UA。另一个很有价值的特征是请求的Referer和路径组合不合理。比如正常用户是先访问首页再进入详情页而CC攻击脚本往往直接拿固定URL列表打没有Referer或者Referer固定成某一页。再比如访问频率正常人一分钟内反复刷新一个页面二三十次是极限如果用脚本打单IP可以达到每秒几十次分布极其规律。更隐蔽的低速CC特征反而是太规整——每个IP的请求间隔几乎精确相等比如每3秒一次持续几小时不间断。真实用户的行为是随机的太规整就一定有问题。建议把Nginx或网关的访问日志接入实时分析别等到事后再查。我自己常用的一个简单判断公式是如果某个URL的请求总量在10分钟内超过了日常同时段的5倍且该URL对应的5xx/4xx比例同时上升超过2倍那么有大概率是CC攻击而不是正常流量突增。这个阈值可以直接做成告警规则。3.3 最难的一点分清突发事件和恶意攻击这一条是我最想提醒的。很多中小团队第一次收到流水告警时第一反应是是不是CMDB里在批量跑数据是不是市场部在搞秒杀这种排查成本很高还容易误判。区分攻击和正常业务突增关键看三个不一致源IP地理分布和业务用户画像不一致。平时90%是国内用户突然大量来自海外的请求大概率异常。请求路径和产品动线不一致。用户都在反复请求一个需要登录的后台接口但前端页面根本没有入口指向它异常。请求的行为统计学特征不一致。真实的高并发活动请求URL分布是多样化的除了热点页面还有其他页面在正常访问而CC攻击集中在少量URL上其他页面纹丝不动。如果这三个不一致里有两条命中就不用再犹豫了先做限流和封禁然后再复盘是不是误伤。这个原则比任何检测算法都好用因为攻击者和正常用户的本质区别不是流量大而是行为结构不一样。4. 防御体系搭建从快、准、狠的应急三板斧到长效架构4.1 应急三板斧第一时间止血别管完美攻击正在打的时候最忌讳的是想一步到位把攻击者全部揪出来。不可能也没必要。第一目标是快速止血恢复可用性然后再固化防线。我的应急三板斧是第一步在防火墙或安全组层面对来源IP做粗粒度封禁。这里不用太精细直接封掉攻击集中的IP段宁可误封几个运营商的大网段把可用性先保住。比如攻击来源集中在某个云厂商的一段IP池那就先封掉那整段通常能在几分钟内降掉一半以上的压力。但要做好用户投诉的准备所以封禁要有时效一般先封半小时观察效果。第二步在Nginx或CDN层打开限流。按IP限并发连接数和请求速率比如单IP限制每秒5个请求单IP最大并发连接数20。对于大多数真实用户来说这个数字完全够用但能把CC脚本的并发打散。如果是攻击集中在某个接口还可以对指定URL做更严格的限速比如搜索接口单IP每分钟最多60次请求。第三步检查静态资源是否走了缓存动态请求是否走到了数据库。如果原来没有动静分离此刻临时把图片、JS、CSS都切到CDN或加一层Nginx缓存能瞬间减少大量后端压力。很多时候CC攻击打的其实是那些不需要计算资源的静态请求加了缓存之后攻击就失去意义了——它还在打但打的都是CDN的存储你的源站已经降载了。这三板斧基本可以在20分钟内完成不要因为配置不规范、规则不好看就纠结先活下来再说。4.2 流量清洗与高防IP的选型逻辑如果攻击规模超过了你出口带宽的冗余单靠自己扛是扛不住的这时候就要上流量清洗和高防IP。这里要理解一个关键点防御DDoS不是把流量消灭而是把流量引走、过滤、回注。高防IP的原理是把你的DNS解析切到高防节点攻击流量先到高防机房高防机房里的清洗设备把攻击流量过滤掉把正常流量通过隧道回传到你的源站。选型时有几个硬指标清洗能力通常按峰值Gbps算、CC防护策略的灵活性、回源链路质量、以及封禁IP的精度。很多便宜的三线高防只是大水管能扛流量但对CC攻击识别得很粗糙攻击者换个IP池继续打它根本拦不住。好的高防应该同时具备网络层DDoS清洗、四层会话防护、七层HTTP分析、分布式CC识别、源站IP隐藏等能力。我看到很多团队只买高防IP但不清楚是不是包含七层CC清洗结果流量攻击扛住了CC攻击依然把源站打趴了这属于典型的钱没花在刀刃上。另外非常关键的一点源站IP的隐藏。很多人买了高防IP但源站的真实IP还是暴露在DNS历史记录里攻击者绕过高防直接打源站IP一样出事。正确做法是源站IP只允许接受高防节点和CDN的回源请求用防火墙白名单把其他所有来源都断掉宁可增加漏配的风险也不能让源站裸奔。4.3 长效架构WAF、CDN与源站保护的协同应急扛住之后需要从架构层面慢慢加固。我认为合理的分层是这样的入口层放CDN或高防IP负责扛大流量和粗粒度清洗中间层放WAF负责应用层的精确识别和拦截包括SQL注入、XSS、CC攻击、恶意爬虫源站层做应用加固包括接口鉴权、参数校验、连接池和线程池的合理配置、依赖数据库查询加缓存和限流。CDN在这里的价值不只是加速它能吸收大量的静态请求攻击。就算攻击者打的是静态页面CDN节点直接命中缓存压根不回源你的源站就安全了。所以做网站架构的时候哪怕不差钱也建议把所有可直接缓存的资源尽量扔到CDN静态资源永不回源。WAF的CC防护规则我的做法是配置双阈值单IP速率阈值和单会话总请求阈值。比如单IP在10秒内请求同一个URL超过20次触发告警超过50次直接阻断。但要注意WAF的CC防护最大坑是误杀。因为很多公司办公室出口是同一个公网IP几十个人共享如果阈值定得太低整个办公室会被一锅端。所以我建议对于已知的企业IP段加白名单对于登录用户通过Cookie维持会话WAF对带合法会话的请求放宽速率限制只有对未登录的匿名请求执行严格限速。攻击者大部分是匿名请求这个策略精准且误伤小。4.4 业务侧隐藏技巧验证码与动态令牌对于真正的低频CC它每个IP的速率不高限速规则很难触发。这时候要靠更业务化的手段来识别。我给几个实用性强的做法核心接口登录、下单、注册强制启用滑块或点选验证码。攻击脚本处理验证码的成本陡增一旦超过攻击者的成本收益比攻击自然停止。对关键操作增加会话绑定比如要求请求里携带一次性的CSRF Token攻击脚本如果不去解析页面提取Token请求就会失败。老式CC脚本大多数没有这个能力。后端对同一账号的请求频率做限制而不是只对IP限。因为攻击者能换IP但账号体系没那么容易批量伪造尤其是需要短信验证码注册的账号成本很高。我之前接手过一个被低频CC骚扰了半个多月的电商站点攻击者用分布在几百个IP上的请求反复调价格查询接口QPS不高但每次查询都触发数据库扫描。后面就是加了页面动态Token和价格查询结果10秒缓存攻击直接废了——因为它拿不到有效Token所有请求都被前置网关拦截了。很多时候你不需要复杂算法只需要把业务逻辑上明显可以被低成本利用的洞补上。5. 实战中我踩过的坑和几个值得分享的判断经验5.1 最常见的失误把CC攻击当成了服务器故障我刚开始做防护的时候碰到过一次线上服务器CPU持续100%的情况。当时第一反应是排查慢SQL、看代码死循环、找日志异常折腾了两个小时没结果。后面仔细看访问日志才发现某个接口的请求量在缓慢上涨源IP分布极广请求路径高度集中——这就是典型的低而缓的CC攻击。那次给我的教训很深刻以后遇到任何CPU/内存异常先花两分钟看网络连接和请求分布再往下钻代码。从攻击者视角出发做事比从系统视角出发更快。如果你一上来就查应用代码很容易陷入大海捞针的局面。5.2 封禁IP时一定要考虑运营商NAT带来的误伤这也是个容易翻车的地方。很多用户用的是运营商大内网出口公网IP是几万人共用的。你根据攻击特征封了一个IP可能同时把几百个正常用户封了。有一次我们严厉封禁攻击源IP段结果半个城市的用户访问全跳出验证码客服电话被打爆。后面的策略调整为封禁只针对命中多种攻击特征的IP而不是单一特征的IP先限速观察再做阻断封禁时效默认10分钟动态延长别一刀切封24小时。5.3 监控不仅仅要报警还要能还原攻击过程最后想说监控的细节。很多团队的告警只有一句流量超阈值没有上下文等你去翻日志已经是半小时以后的事攻击者早把特征变了。所以我提倡在所有关键入口配置请求日志的全量记录并至少保留72小时的分钟级聚合数据。这样攻击结束后你可以回放看清楚整个攻击分几个阶段、每个阶段的特征是什么、我们的防御策略在哪一步失效了。回放一次胜过看十篇技术文档。我现在处理任何一次攻击事后都要写一份攻击复盘里面包含时间线、特征指纹、防御动作、效果评估这对下一次防御的优化帮助非常大。5.4 不要过度依赖任何单一安全产品我的习惯是纵深防御人工兜底层次别太单薄。就算有高防IP、WAF、CDN也建议保留一套可以快速手动执行的基础防御脚本比如用iptables快速封禁、用Nginx的limit_req模块临时限流、用fail2ban做暴力破解阻断。这些土办法在自动化产品失效、或者你怀疑产品漏拦的时候特别管用。安全产品是概率性的不是绝对性的关键时候决定能不能撑住的往往是你是否有足够的基础功底去手动干预。5.5 防御之后要做的自检清单每次经历攻击后我建议按这个清单过一遍源站IP是否已经完全隐藏历史DNS解析记录里还能不能找到所有对外接口是否有全链路限流包括网关层、应用层、数据层动态Token和验证码机制是否覆盖了最核心的业务接口日志和监控的粒度是否足够支撑下次攻击的快速定位跟安全产品供应商的服务响应流程是否验证过高防IP的调度电话能不能24小时打通真实的安全运营是一个不断被攻击、不断复盘、不断补短板的过程。DDoS与CC攻击没有一劳永逸的解法但有系统和经验之后至少你能做到在攻击来的时候不慌知道从哪儿下手知道怎么止血知道攻击结束之后如何把防线再往前推一层。