1 概述
CC攻击是DDoS攻击的一种，早期的DDoS伪造数据包对目标网络及服务的协议栈发动攻击，轻易的就造成系统不可用，以此达到攻击的目的。后来绿盟推出了黑洞产品，英文名是Collapsar，一度打击了流量型的DDoS攻击；再后来又有黑客实施了应用层的攻击，轻松绕过黑洞的防御，同样实现了DDOS攻击，为此命名为Challenge Collapsar，简称为CC。CC事实上就是模拟访问者的正常请求，通过发起更多更容易混淆的请求达到消耗服务器资源的目的。
2 开放的服务
CC攻击的WEB服务，正是网站拥有者建立起来提供公众访问的服务，这样的服务是面向大众访问的，谁都可以访问。
2.1 CC攻击来了
- 由程序模拟访问，访问方式看起来很正常
a) 组织一些服务器进行访问
b) 挂许多代理（匿名或不匿名的）进行访问
c) 控制大量的僵尸主机进行访问 - 劫持攻击，通过劫持第三方的请求，导入式攻击攻击的方式好多，攻击过程中的样子就更多了：
- 直接攻击单一url，有的还变换参数，绕开缓存
- 攻击某几个url
- 随机攻击url
- 空连接攻击
- 慢连接攻击
似乎都有特征，好象能防住，但没多久，502了，一查源站挂了。
2.2 坚强的代理
3 安全的服务
要保护被访问的服务，如果资源不受控，那就控制去访问的量，同时做为代理节点还应提供尽可能多的服务资源。要提供服务，首先要保护好服务，源站需要保护，代理节点也需要保护。
3.1 保护服务
3.1.1 源站保护
1秒内就能响应完的服务肯定是好服务，2秒内能响应完也不错。 假设当前的响应能力为k秒，请求发出，当还没有响应完，称这类请求为半请求，可累积半请求数量n，按秒统计半请求的增量超过响应数量m时，响应能力进一步减弱，预期的响应能力可按下述公式计算k*(n/m) = g秒，根据用户设定的CC响应灵敏度值映射的响应能力来判定是否启动保护。
启动保护后，从队列中取出要回源的请求，建立请求前要分析url和IP的访问指数，满足可访问条件的允许回源，不满足的拦截，未知的重新放回队列，待下一次判断。
3.1.2 节点保护
节点的性能、带宽在应对CC攻击时都存在较大的波动，确保清洗的过程中，还能提供较好的访问体验需要对节点也采取保护措施。
清洗过程中，每一次CC请求都正确的响应拦截数据有可能影响节点的性能，触发保护时可以有选择的做一些reset操作，即能统计到攻击次数，又可以降低性能损耗。
3.2 扩容服务
缓存是扩容服务的最好的途径，但我们平常用的都是常规缓存，许可缓存。当一个新的未知IP初始请求一个资源时，如果源站压力大，服务资源有限时，可以考虑在节点上提供该IP尽可能正确的缓存内容，依此来观察该IP后续的行为。
4 清洗服务
当服务过程中，节点感知到系统触发了CC防御，必然要对所有的请求进行清洗，把CC洗掉，让正常的请求获取正确完整的资料。
4.1 服务分析
- Nginx反向代理的方式保护源站，根据清洗策略提供服务，实时的输出服务信息；
- Ccap/spark平台分析服务信息，形成清洗策略，下发到nginx。
4.1.1 输出服务信息
在整个请求过程中，refer,agent等都可以伪造，没有分析的必要；x-forward虽然也存在伪造，但我们需要统计一个IP使用代理的数量，同时默认上也可以直接拦截3次代理以上的请求，同时nginx为每一次新的请求（除api类url）提供一个cookie，记录session用，所以从本方案上需要输出的服务信息包括：
- 防御输出
Session, client_ip, xforward_list, url,hostx(master_domain),def_code
- 请求输出
Session,client_ip,xforward_list,url,hostx(master_domain),wait_time
- 响应输出
Session,client_ip, url,hostx(master_domain),localtime,valid_time,code
Session要做好设计，在nginx中只有正常使用的session会记录到共享内存中，也有必要输出，同一个session可使用次数随机（5~50次），session同时还有伪造session、session过期、空session、无session等
4.1.2 清洗策略分析
清洗策略分析的目的是找到可疑目标，可疑目标参与的请求优先进行控制
4.1.2.1 可疑目标分析
- 可疑IP
- 同时使用多个代理进行访问
- 在黑名单中
- 非正常session次数超限
- 并发session高，访问内容重合度大
- 单IP最近周期内错误率高
- 单IP重复率高
- 可疑url
- 可疑IP集中度高的url
- 最近周期内访问量达平均值2倍以上的url
4.1.2.2 清洗指数分析
建立模型，根据可疑目标最近周期的访问情况，对比整体服务的状态，得到可疑目标的清洗指数，下发给nginx，nginx依据模型的清洗原理，控制可疑目标的服务状态，把更多的资源让给未知或安全的请求。
4.2 清洗流程
5 实施方案
5.1 模块划分
上述方案完整的模块包括：
5.1.1 回源保护
用户也可以手动开启防御模式。
在防御模式下，会对可疑IP涉及的访问拦截、对未知IP涉及的可疑url进行延迟，对其它情况的访问在资源允许情况下放行。
模块以nginx modules模式设计，存在部分patch。
该模块有别于现在的cc_limit，部分思路相同，从request上控制。
5.1.2 Nginx信息输出
该模块负责输出请求数据，从原来的cc_clear、cc_log中精减和改进，具体数据输出根据阶段性实际需求改进。
5.1.3 Nginx接收策略
接收ccap下发的策略，录入到相应的共享内存中，与各防御或保护模块协调一致。
5.1.4 CCAP
5.1.5 节点保护
节点保护模块用于在较大压力下的节点自身防御能力的优化流程处理
5.1.6 Cookie session
为开启cc防御服务的站点提供cookie session机制，优化CC行为的分析方法，涉及输出、CCAP等模块的改进。
5.1.7 恶意IP库
5.1.8 SPARK
大数据实时分析平台，该平台获取实时访问数据，建立模型，提供更精确的黑白名单。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/198160.html原文链接：https://javaforall.net
