在网络安全运维这块摸爬滚打了这些年被问得最频繁的一个问题就是DDoS攻击和CC攻击到底有什么区别很多刚入门的朋友或者甚至是一些做运维、做开发的同行在第一次遇到安全告警的时候容易把这两者混为一谈。但只要你把这两类攻击的原理、特征和防御策略彻底搞懂了你会发现在应对它们时的思路其实是完全不同的两条路。这篇文章就结合我自己的实战经验把这两个概念掰开揉碎了讲清楚从原理到防御、从识别到排查一次性讲透。先说个大概的框架。DDoS攻击全称是Distributed Denial of Service分布式拒绝服务攻击它打击的目标是网络带宽和协议栈资源。CC攻击它的全称是Challenge Collapsar行业内习惯称为CC攻击它是一种专门针对Web应用层的HTTP Flood攻击打击的目标是应用层的业务逻辑和计算资源。一个主打“网络层管道堵塞”一个主打“应用层业务瘫痪”。这两者的差别就是我今天要展开的整个文章的骨架。1. 基础定义理解DDoS和CC的核心本质1.1 DDoS攻击是什么DDoS攻击本质上是一种资源耗尽型攻击。攻击者利用大量被控主机也就是常说的“肉鸡”组成一个僵尸网络同时向目标服务器发送海量的请求数据包。这些数据包的类型多种多样可以是TCP SYN包、UDP包、ICMP包也可以是精心构造的DNS查询请求。目标服务器在收到这些海量数据包后它的处理逻辑是需要占用CPU、内存、网卡队列等资源来进行响应或者丢弃的。当这些请求的数量远远超过了服务器的处理能力上限时服务器的网络带宽会被撑满网卡会满载CPU会飙升到打满最终的结果就是正常的用户请求进不来即使进来了也得不到响应整个服务就瘫痪了。打个比方DDoS攻击就像一群人把一家商店的所有出入口都堵死了。这些堵门的人不一定都要进店他们的目的很简单就是不让任何顾客进店。在网络的语境下就是让整个服务器的对外通信通道彻底堵塞导致所有合法用户都无法访问。1.2 CC攻击是什么CC攻击的全称是Challenge Collapsar这个名字来源于早期国内一款叫做“Collapsar”的防护设备。本质上CC攻击是一种针对Web应用层的攻击。它通过模拟多个真实用户向Web服务器发送大量看似合法的HTTP请求比如请求某个页面、调用某个数据接口、提交某个表单。由于这些HTTP请求从协议上看是完全正常的它们能够穿过网络的防火墙和流量清洗设备直接打到Web服务器或者后端业务代码上。服务器为了处理这些海量的请求需要不断地进行数据库查询、生成动态页面、执行脚本逻辑最终造成CPU和内存资源的耗尽。还是拿商店来类比CC攻击就好比一群人涌入店里既不买东西也不聊天只是每人霸占一个试衣间进去之后又迟迟不出来一直占着位置。这样一来真正想买衣服的顾客没办法试衣服商家的服务能力就被这些“占着茅坑不拉屎”的人给消耗殆尽了。CC攻击消耗的不是门口的通道而是店里实实在在的服务资源。1.3 二者的本质定位差异从上面的描述里你应该能感受到核心差异了。DDoS攻击是流量型攻击它的单位是Gbps或者Mpps衡量的是攻击流量的大小和攻击数据包的数量。CC攻击是请求型攻击它的单位是QPS或者说请求频率衡量的是攻击请求的密度。在实际的安全防御场景里DDoS攻击通常由专业的流量清洗设备或者是高防IP来应对它的核心在于把海量的垃圾流量在到达服务器之前就过滤掉。而CC攻击则更麻烦因为它的请求是“正常”的你需要结合的是业务层的限流策略、验证码机制、Web应用防火墙的规则等一系列应用层防护手段。2. 攻击原理与机制拆解为什么会出现不同攻击形态2.1 协议层攻击原理DDoSDDoS攻击利用了网络协议栈在处理异常状态的逻辑漏洞或资源消耗特性。最常见的SYN Flood攻击就是一个经典例子。TCP协议的三次握手规则是客户端发送SYN包服务端回复SYN-ACK包客户端再回复ACK包以建立连接。SYN Flood攻击就是向服务器发送大量的SYN包并且故意不回最终的ACK包。服务端在收到SYN包之后会在内存中为这些半连接分配一个缓冲区专门存储连接状态等待客户端的ACK确认。这些半连接一直占着资源直到超时才能被释放。如果这种半连接的数量足够大服务器的内存就会被耗尽正常的连接也就无法建立了。UDP Flood攻击的原理就更简单粗暴了。它只需要向目标的某个UDP端口发送海量的UDP数据包让服务器的网卡处理和协议栈判断逻辑被打满即可。因为这些UDP包来源实际上是伪造的服务器即使要回应也找不到真正的来源。这类攻击的特点就是量大、凶猛通常能在几分钟之内就把机房的带宽资源打满。如果攻击带宽超过了服务器本身的带宽或者机房入口的带宽总值那么不管服务器的性能再好、代码再优秀照样会瘫痪因为流量根本进不来。2.2 应用层攻击原理CCCC攻击的原理是建立在高层的HTTP协议之上的。攻击者构造的每一个HTTP请求从格式上来讲都可能完全符合RFC标准请求头、请求体、请求方法都完整无缺。这些请求源地址可能是分散的也可能是集中的。早期有很多人用代理IP池来发起CC攻击让Web服务器难以通过IP封禁来防范。CC攻击真正消耗的是应用服务器的计算资源和I/O资源。比如一个门户网站首页通常会有很多数据库查询操作、页面渲染逻辑。如果有人用高频的HTTP请求反复请求首页每次请求服务器都要去执行这些复杂的后端逻辑CPU平均负载就会迅速升高。如果是更精细的查找操作比如搜索功能那么每次请求都需要搜索数据库数据库的查询并发就会被打满导致整个数据库服务挂掉。还有一种慢速攻击比如Slowloris它利用的是HTTP协议的keep-alive特性。攻击者建立连接后以极低的速度持续发送HTTP请求头信息让服务器认为这是一个尚在传输中的请求从而一直保持着连接。如果这种连接积累到足够多Web服务器的连接池就会被占满正常的新连接就无法建立了。这种也算是应用层攻击的一个变体。2.3 攻击效果与成本对比从攻击者的成本和收益角度来看DDoS攻击的成本相对较高。因为它要求攻击者必须拥有足够的带宽资源要么是自己控制的僵尸网络足够强大要么是租用外部的攻击流量服务。对于防护方而言一旦遭遇大流量DDoS清洗成本是极高的。CC攻击的成本就相对低很多只需要一台普通的中等配置云服务器配合一些能够发送HTTP请求的脚本或者工具就可以实现对一个小型网站的毁灭性打击。这也就是为什么很多小站点在做安全防护的时候流量型的DDoS反而不多见高频的CC攻击却是最常见的情况。从防御角度来说DDoS的防守策略偏硬件、偏网络层而CC的防守策略偏软件、偏代码层。理解了这一点你也就理解了为什么说DDoS是“治标”而CC是“治本”。3. 实战中的识别与区别判断如何快速定位攻击类型3.1 特征差异的直观对比在真实的运维场景里当网站出现服务不可用的情况时如何快速判断到底是DDoS还是CC呢这里我整理了一个实战速查表你可以直接把下面这些特征作为第一判断依据判断维度DDoS攻击特征CC攻击特征网络层状态带宽被占满网卡流量异常高带宽可能使用正常波动不大连接数特征半连接数量骤增或者大量UDP包TCP连接数快速上涨且多是完整连接CPU/内存协议栈处理导致内核态CPU升高但应用CPU不一定高应用CPU飙升数据库查询耗时增加日志表现无明显前端访问日志网络层清洗设备报警Web日志中有大量同一URL或者接口的高频请求访问体验根本连不上网络超时能连上但页面加载超慢、白屏主要受害者整个IP段的所有服务某一个域名、某个特定页面或某个API接口你可以看到DDoS在访问上带来的感受是整个服务器彻底失联而CC带来的感受是服务器偶尔能通但业务却毫无响应就好比网站“假死”一样。如果你打开服务器发现还能ping通但打开网页却怎么都转不出来那大概率就是CC攻击。3.2 受害目标的指向性差异DDoS攻击的攻击目标往往是IP地址因为流量是直接打到IP层的。也就意味着如果你服务器上绑定了多个域名、多个网站只要他们共用同一个IP那么所有网站都会在攻击时一起瘫掉。而CC攻击的目标则是URL或域名攻击者可以精准地只盯着某个站点的某个API接口打其他业务不受影响。这种目标性的差异也直接决定了应急处置的优先级。如果是DDoS你要立刻启用流量清洗或者更换IP如果是CC你要优先在Web层做限流和拦截。3.3 实战中的判断流程我自己在遇到突发安全告警的时候一般的判断流程是这样的第一先打开监控面板看带宽曲线和CPU曲线。如果带宽曲线的数值瞬间拉满到几Gbps甚至几十Gbps那必然是DDoS。如果带宽曲线基本平稳CPU却一路飙升那就进入第二步的判断。第二登录服务器查看连接状态。执行netstat -ant | grep SYN_RECV | wc -l如果SYN_RECV状态的连接数异常高那就属于TCP层的DDoS。如果ESTABLISHED状态的连接数特别多且都集中在80或者443端口上那就初步定位为CC攻击。第三打开Web服务访问日志统计同一个IP或同一个URL的请求频率。如果发现某几个IP单位时间内的请求数量成千上万那基本就可以确认CC攻击的流量来源了。这个过程其实很快熟练的话几分钟就能判断个八九不离十。关键不在于使用多么高级的工具而在于你是否理解不同攻击类型在服务器上留下的“指纹”是不同的。判断准确的攻击类型是后续所有防御动作能够生效的前提。4. 防御实操不同攻击的不同处理方式4.1 DDoS的防御思路DDoS攻击的防御核心是“抗得住流量”。由于攻击流量巨大单纯靠源站服务器自身的性能和带宽是无论如何也扛不住的。必须把防护能力前置到离攻击源更近的位置。对于大部分企业和个人站点来说最有效、最直接的方法是接入高防IP。高防IP的原理是将源站的IP地址隐藏起来对外只提供高防节点的IP。DNS解析指向高防IP所有流量先经过高防机房的流量清洗集群。清洗集群会识别出恶意的攻击流量将其丢弃或者限速而把正常流量转发回源站。这样源站本身就不直接暴露在攻击流量面前。除了接入高防IP之外在网络层还可以做这些加固措施调低TCP超时时间加快SYN半连接的释放速度启用SYN Cookie机制用CPU换内存避免半连接占满内存限制单IP的并发连接数减少某个单一来源IP造成的压力关闭不必要的UDP端口和ICMP响应减少被利用的攻击面。值得提醒的是DDoS防御需要做全链路评估。很多朋友觉得买了一个高防IP就万事大吉了结果攻击一来高防IP倒是没被打死但源站服务器的运营商带宽被人查到了攻击者把流量直接打到源站IP上照样瘫痪。所以在部署高防IP的时候源站服务器一定要配置安全组只允许来自高防节点IP的访问从网络层面彻底隔绝掉直连源站的可能性。4.2 CC的防御思路CC攻击的防御核心是“识别异常请求”。由于攻击流量从协议上看是合法的传统的流量清洗设备作用不大必须要在Web应用层做精细化的控制。第一步启用WAFWeb应用防火墙规则。目前主流的云厂商WAF产品都内置了CC防护规则你可以设置一个阈值比如单个IP在60秒内的请求次数超过100次就自动把这个IP的请求拦截掉或者触发人机验证。WAF的判断基于的是请求特征、IP信誉库和行为分析相比手工封禁IP响应速度要快得多。第二步在业务代码层面做限流。如果你的业务框架是Spring Boot或者NginxPHP你可以在网关层写一个限流插件对每个用户Token、每个设备ID、每个IP做请求速率限制。这里我建议用令牌桶算法或者滑动窗口算法这两个算法既能平滑突发流量又能精确限制速率。第三步配置验证码策略。当系统识别到某个IP或者会话的请求频率超出正常范围时可以通过接口返回一个验证码让用户手动操作。这个策略对真人用户几乎没有感知却能轻而易举地把绝大多数脚本请求拒之门外。第四步启用CDN加速服务。把静态资源和动态请求都经过CDN在CDN边缘节点上做缓存可以极大减少源站被直接攻击的概率。因为CDN节点本身有DDoS防护能力同时CDN节点上的缓存也能拦住大量的重复请求。4.3 监控预警配置的核心参数不管是防御DDoS还是CC前提都是能提前发现问题。监控预警做得不到位你会在攻击发生之后的一段时间里才意识到那时候损失往往已经造成了。监控面板上我建议至少关注五个核心指标入向带宽、出向带宽、TCP连接数的趋势、应用层CPU使用率、数据库连接池使用率。对于带宽指标建议设置两个等级的告警阈值比如正常带宽为50Mbps的情况下第一级警告设为80%也就是达到400Mbps触发提醒第二级紧急告警设为超过1Gbps时立即电话通知到值班人员。对于CC攻击的监控比较有效的指标是每台Web服务器的每秒请求数成功率。正常情况下请求成功率应该在99%以上。一旦发现成功率下降到90%以下同时平均响应时间翻了几倍就需要立刻进入排查流程。很多系统在遭遇攻击时最先报警的是数据库连接池耗尽因为无论是DDoS导致的大量连接进入了后端处理流程还是CC攻击直接进行了大量SQL查询最终崩溃的往往都是数据库。所以数据库连接池的监控曲线一定不能漏掉。4.4 防御中的常见误区我认为在实际的安全防御过程中很多朋友踩过的最大的坑是认为“单靠一个安全产品就能解决所有问题”。比如只买了高防IP却被CC攻击打得措手不及或者只配置了WAF却被大流量DDoS直接穿透。正确的心态是分层防御、纵深防御。边界网关上有流量清洗Web层有WAF和限流业务代码里有防重和验证码数据层有连接池超时限制每一层都只能解决一类问题切莫指望单一武器包打天下。第二个误区是忽视攻击溯源和监控日志的留存。遇到攻击时很多人的第一反应是赶紧关掉服务和IP但这个做法导致事后无法分析攻击者的攻击路径和手法。建议平时就要开启全量Web访问日志的持久化存储至少保留30天攻击发生时第一时间抓取网络全包。这些数据在后期的溯源和证据固定阶段价值不可估量。第三个误区是安全配置一成不变。攻击者的手法在持续演进如果策略设置了固定的IP限流阈值就再也不动了上线一段时间之后可能发现误杀率特别高正常的搜索引擎爬虫和用户都被拦截了而最新的攻击手法却绕过了配置。到这里定期复盘WAF告警日志、调整限流阈值迫在眉睫我自己的习惯是每周检查一次安全告警统计每月全量复盘一次防护策略。5. 常见问题排查与实践经验5.1 实战中的典型问题与处理方案在长期的应急响应过程中很多典型问题的处理方式具有高度的可复用性这里我整理成一份问题排查实录直接供你参考。现象一安装了高防IP但网站还是经常被攻击打挂。这种情况首先要查DNS解析是否全部切到了高防IP有可能某些地区的本地DNS缓存还残留着源站IP。其次要检查服务器安全组是否放开了来自高防IP回源段的访问如果安全组限制了回源IP正常的请求也无法经过高防到达源站。最后排查有没有其他以太网卡绑定了源站公网IP导致源站被绕过。现象二服务器的CPU突然飙升到100%但查看带宽流量并不高。这种状况大概率是CC攻击。查看Nginx和PHP-FPM的日志统计请求最集中的URL是哪一个再检查访问这个URL的人的IP分布。如果请求来源IP集中在几个C段内就可以快速封禁这些IP段。但如果来源IP分布很分散就需要开启WAF的人机验证策略。现象三TCP连接数很大但Web服务没有活跃请求日志。这种情况下往往是慢速连接攻击或者DDoS连接耗尽。用ss -s命令查看当前TCP状态的汇总信息如果TIME_WAIT或者SYN_RECV特别多那就分别对应不同的攻击类型。TIME_WAIT多说明存在大量短连接快速建立又断开常见于HTTP FloodSYN_RECV多说明TCP握手未完成是SYN Flood的典型特征。现象四遭遇攻击后服务器变得异常卡顿但攻击停止之后依然没有恢复正常。这通常是因为攻击期间积累了大量的请求日志、连接表项和缓存数据。建议在攻击停止后尽快重启一次Web服务和数据库服务释放掉内存中的垃圾数据同时清理掉大量的临时文件和日志片段。5.2 应急响应排查要点实操中排查此类攻击的原理与节点大致可以概括为三步先在入口层判断攻击流量是否来自特定的IP或IP段则该场景优先在网络层做丢包和封禁处理其次在中间层判断攻击是否集中在某个URL或者某个API接口该场景则在应用层配置限流和动态封禁最后在数据层判断数据库是否被大量查询拖垮该场景需要优先做数据库读写分离和缓存预热。这套排查顺序之所以要从入口层往数据层走是因为离用户越近的节点越容易拦截流量消耗的防护资源也最少。如果你一上来就在数据库层面做调整不仅防护范围小而且很难应对高强度的CC攻击。在日常演练中建议准备一套防护应急预案标注清楚每一步由谁执行、哪些账号有权限、是否可以直接操作高防开关等省得攻击发生时一团乱麻临时找不到授权。5.3 预防性巡检清单分享从防御的角度来看等到攻击发生再行动往往为时已晚。日常预防的价值远高于应急处理。这里给你一份我自己的日常巡检清单每周观察一次安全报表记录请求总量、异常IP数量、被拦截的攻击类型每月测试一次WAF规则的有效性用扫描器模拟常见攻击手法验证拦截率每月检查一次源站公网IP是否彻底隐藏尝试直接访问源站IP测试是否能通每季度进行一次容量压测确认服务器可以在多大的请求量下保持稳定每次上线新业务接口评估是否需要单独设置CC防护策略。这份清单并不复杂难的是坚持。网络安全本质上是一个持续投入和迭代的过程平时多花一小时做巡检可能就避免了攻击发生时好几个通宵的应急加班。最后再分享一个小技巧吧在我自己的防护经验里最有用的一招是始终保留一份当前全量业务的接口清单和正常流量基线数据。有了这份基线你的WAF和限流策略才有参照物。攻击来时你一眼就能看出当前请求和正常流量之间的偏离程度有多大从而快速判断攻击类型、评估攻击强度也就能用最快的速度恢复业务。这份基线数据建议你从今天开始就着手记录。