CC防御方案

1 概述

CC攻击是DDoS攻击的一种，早期的DDoS伪造数据包对目标网络及服务的协议栈发动攻击，轻易的就造成系统不可用，以此达到攻击的目的。后来绿盟推出了黑洞产品，英文名是Collapsar，一度打击了流量型的DDoS攻击；再后来又有黑客实施了应用层的攻击，轻松绕过黑洞的防御，同样实现了DDOS攻击，为此命名为Challenge Collapsar，简称为CC。CC事实上就是模拟访问者的正常请求，通过发起更多更容易混淆的请求达到消耗服务器资源的目的。

攻击技术的不断演进，倒逼着防御技术持续跟进，但效果上还差些意思，后来以至于到现在，我们还在想着新的对策来防御CC攻击。
CC是模拟访问，用户是访问，用户的目的是获取资料，而CC是消耗资源，注定其特征不同。

本文档提出新的CC防御思路，应对高中低各类服务器性能、应对分布式防御、应对水平高低不同的管理员提出的解决方案，几乎就是免配置的防御方案。
存在一项配置，CC防御灵敏度，那就用滚动条来服务吧。

2 开放的服务

CC攻击的WEB服务，正是网站拥有者建立起来提供公众访问的服务，这样的服务是面向大众访问的，谁都可以访问。

2.1 CC攻击来了

但是CC攻击的时候，这些访问权限都被CC攻击者占有了，正常的访问者几乎没有机会访问到，网站就已经打不开了。
好，把CC拦下来，怎么拦呢，CC攻击可能通过如下途径实施：

1. 由程序模拟访问，访问方式看起来很正常
   a) 组织一些服务器进行访问
   b) 挂许多代理（匿名或不匿名的）进行访问
   c) 控制大量的僵尸主机进行访问
2. 劫持攻击，通过劫持第三方的请求，导入式攻击攻击的方式好多，攻击过程中的样子就更多了：
   1. 直接攻击单一url，有的还变换参数，绕开缓存
   2. 攻击某几个url
   3. 随机攻击url
   4. 空连接攻击
   5. 慢连接攻击
      似乎都有特征，好象能防住，但没多久，502了，一查源站挂了。

2.2 坚强的代理

攻击者真傻，打的是静态页面，我们的代理轻松能扛；但是攻击主机不断的出现，似乎代理也快扛不住了，加ipset吧，加、加、加，最后一统计十几二十万呢，似乎防住了，接下来，不断的接到投诉，某某IP怎么访问不了？最后一查，发现都在ipset中，汗啊。
配置界面上让用户设置的阈值，结果源站挂了，用户评价说设置的不大，可节点上还没有触发阈值，原来因为是分布式CDN，攻击者是通过好多节点一起攻击的。

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 服务分析

1. Nginx反向代理的方式保护源站，根据清洗策略提供服务，实时的输出服务信息；
2. Ccap/spark平台分析服务信息，形成清洗策略，下发到nginx。
   

4.1.1 输出服务信息

在整个请求过程中，refer,agent等都可以伪造，没有分析的必要；x-forward虽然也存在伪造，但我们需要统计一个IP使用代理的数量，同时默认上也可以直接拦截3次代理以上的请求，同时nginx为每一次新的请求（除api类url）提供一个cookie，记录session用，所以从本方案上需要输出的服务信息包括：

1. 防御输出
   Session, client_ip, xforward_list, url,hostx(master_domain),def_code

2. 请求输出
   Session,client_ip,xforward_list,url,hostx(master_domain),wait_time

3. 响应输出
   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 可疑目标分析

1. 可疑IP
   1. 同时使用多个代理进行访问
   2. 在黑名单中
   3. 非正常session次数超限
   4. 并发session高，访问内容重合度大
   5. 单IP最近周期内错误率高
   6. 单IP重复率高
2. 可疑url
   1. 可疑IP集中度高的url
   2. 最近周期内访问量达平均值2倍以上的url

4.1.2.2 清洗指数分析

建立模型，根据可疑目标最近周期的访问情况，对比整体服务的状态，得到可疑目标的清洗指数，下发给nginx，nginx依据模型的清洗原理，控制可疑目标的服务状态，把更多的资源让给未知或安全的请求。

4.2 清洗流程

5 实施方案

5.1 模块划分

上述方案完整的模块包括：

5.1.1 回源保护

回源保护模块能感知源站的响应能力，从而决定当前要发起到源站的请求是放行还是挂起，挂起有两种情况，包括阻断或延迟处理。
该模块能感知源站的响应能力是指能预测响应能力，每次请求源站前，会判定预测的响应能力是否达到了用户介意值，这一介意值通过用户设定的CC灵敏度阈值来换算。当预测响应能力超过介意值，则进入防御模式。

用户也可以手动开启防御模式。

在防御模式下，会对可疑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

该模块收集nginx的输出信息，进行分析汇总：
1) 产生防御策略，实时或定时下发到nginx，包括按域按回源IP的关键值，可疑url和可疑IP等
2) 外发到spark平台
3) 汇总数据上报到报表数据中心

5.1.5 节点保护

节点保护模块用于在较大压力下的节点自身防御能力的优化流程处理

5.1.6 Cookie session

为开启cc防御服务的站点提供cookie session机制，优化CC行为的分析方法，涉及输出、CCAP等模块的改进。

5.1.7 恶意IP库

恶意IP库是一个系统工程，包括追加、更新、清理等多个机制，同时涉及分布式管理和维护，包括一个自主更正平台。
从使用者的角度来说，nginx中使用该库的接口，如果发现属于这类IP，应转发请求，让其进入更正平台。

5.1.8 SPARK

大数据实时分析平台，该平台获取实时访问数据，建立模型，提供更精确的黑白名单。