CC攻击又可以被称为Challenge Collapsar攻击，是一种十分常见的分布式拒绝服务攻击方式，CC攻击的工作原理是在与攻击者通过控制一系列主机，不间断的向目标服务器发送大量的数据包，从而导致目标服务器的资源被消耗殆尽，使服务器崩溃。
CC攻击的原理
一个静态网页几乎不需要服务器分配多少资源，甚至可以说直接从缓存里调取出来就能推送给你。但论坛类站点截然不同——每打开一篇帖子，系统都得先去数据库里校验你是否具备阅读该帖子的权限，若权限通过，再把帖子内容读取出来并展示。这一过程至少要与数据库交互两回。假如数据库容量达到200MB，系统很可能就得在这200MB的数据空间里完整检索一遍。如果换成关键词搜索，耗时更是成倍增长，因为前面的权限校验可以把范围锁定在极小的表内，比如用户权限只查用户表、帖子内容只查帖子表，而且命中即停；而关键词搜索则需要对全部数据逐一扫描判断，资源消耗极为惊人。
CC攻击正是巧妙利用了这一特性——模拟大量用户（多少个线程就等同于多少个用户）持续不断地发起请求，专门瞄准那些需要进行大量数据运算、也就是需要占用大量CPU时间的页面。
不少人会疑惑：为何要借助代理？原因在于代理能够有效隐匿攻击者的真实身份，同时还能规避绝大多数防火墙的拦截。因为基本上所有防火墙都会监测并发TCP/IP连接的数量，一旦超过设定的阈值和频率，就会被判定为Connection-Flood并加以阻断。借助代理发起攻击还能很好地维持连接状态：我们这边把数据发出后，代理会替我们转发至目标服务器，随后我们便可立即断开，而代理依然会与对方保持连接（据我所知，曾有人利用2000个代理制造出了35万并发连接的记录）。
我们来做一个推算：假设服务器A处理Search.asp这个页面需要0.01秒（多线程只是把时间进行了切割，对最终结论并无影响），也就是说它每秒最多能响应100个用户的搜索请求。若服务器允许的最大连接保持时长为60秒，那么我们用CC模拟120个用户同时发起连接，一分钟下来，服务器累计收到了7200次请求，实际处理了6000次，剩余1200个并发连接堆积在队列中未能被响应。
或许有人会说：那就丢弃连接呗！但问题在于，服务器是按照先来后到的顺序进行丢弃的。这1200个未处理的连接是在最后10秒内发起的，想丢？还没轮到。经过计算可知，当服务器满载并开始丢连接时，队列中应该已经积压了7200个并发连接。此后服务器以每秒120个的速度丢弃连接，而我们发起新连接的速率同样是每秒120个，服务器永远有清理不完的连接堆积。服务器CPU长期处于100%满负荷运转状态，而在丢连接的那60秒内，服务器同样无法处理新进来的请求，最终整个服务器陷入极度繁忙的瘫痪状态。当然，CC攻击同样可以用这套逻辑对FTP发起冲击，也能实现TCP-FLOOD效果，这些均已经过实测验证。
网站遭遇CC攻击后的典型表现
1. 动态站点被攻击时： 若网站属于asp/asp.net/php等动态类型，在CC攻击下发，IIS站点通常会弹出”SERVER IS TOO BUSY”的错误提示。若非IIS承载网站服务，则会发现网站服务程序无故自动崩溃或报错。若已排除网站程序本身的缺陷，却依然出现此类状况，基本可以判定该网站正遭受CC攻击。
2. 静态站点被攻击时： 若网站属于html等静态类型，在CC攻击下发，打开任务管理器查看网络流量，会发现网络应用中的数据发送量出现异常飙升。在大规模CC攻击下，网络占用率甚至可能逼近99%。当然，遭遇CC攻击时网站已无法正常打开，但通过3389远程桌面连接服务器通常仍可正常接入。
3. 少量CC攻击时： 站点仍能间歇性访问，但体积较大的文件（如图片）会出现无法加载的情况。若动态网站遭受小规模CC攻击，还会观察到服务器CPU占用率急剧攀升。以上便是CC攻击最基本的几种症状表现。
如果你的网站出现了上述CC攻击症状中的任意一种，无需惊慌，余初云提供Web应用防火墙（WAF）及网络安全解决方案，为公有云、私有云、混合云等环境下的用户提供安全服务。为政府、金融、教育、工业、互联网等领域的企业提供云安全防护解决方案，欢迎联系我们处理。
原创文章，作者：余初云，如若转载，请注明出处：https://blog.jidcy.com/jsjc/3007.html