CC攻击是网络上很常见的一种大规模攻击方案。流量超大，攻击很猛，一般的网站根本无法抵御。
什么是 CC 攻击
CC（Challenge Collapsar）该攻击与我们常见的 DDOS（网络层分布式拒绝服务攻击）不同之处在于，CC 攻击只会导致 WEB服务或者只是 WEB 服务中的某一接口或单一页面无法服务，相比网络层的拒绝服务攻击，其优势在于能够使用相对较少的资源对更为精确的目标进行攻击。
攻击方式
主要的攻击方式分为快速和慢速两种：
快速 CC 攻击是指快速请求服务器处理消耗较大的页面或者接口，这种方式是通过大量占用服务器的 CPU、IO 等资源，致使服务器无法正常响应其它用户的请求。
慢速 CC 攻击是指是通过与服务器建立连接后，以最慢的速度发送请求/读取响应，通过占用服务器的进程、线程、网络套接字等资源，达到导致服务器无法继续服务的目的，这种攻击一般针对 Apache、httpd 这类 thread-base 架构的服务器。
防护手段
针对两种不同类型的攻击防护方式分别是：
快速攻击： 限制单一源IP的请求速率、限制并发连接数
慢速攻击： 限制单一请求的超时时间
Nginx 和 Apache 都有相应的模块来解决这类问题，只要配置得当能够抵挡住大多数的 CC 攻击，以下我们以 Nginx 为例看看具体的配置。
限制单一源 IP 的请求速率，平均每秒不超过 1 个请求，并且突发不超过 5 个请求：
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
...
server {
...
location /limit_req/ {
limit_req zone=one burst=5;
}}
限制并发连接数，单一源 IP 最大并发数是 100，总的连接数不超过 1000：
http {
limit_conn_zone $binary_remote_addr zone=one:10m;
limit_conn_zone $server_name zone=perserver:10m;
...
server {
...
limit_conn one 100;
limit_conn perserver 1000;
...}
限制单个请求的超时时间：
http {
...
server {
...
client_header_timeout 60s; //等待客户端发送请求头的超时时间，将这个值改小可以应对慢速发送请求头的CC攻击；
client_body_timeout 60s; //读取客户端发送请求体的超时时间，将这个值改小可以应对慢速发送请求体的CC攻击；
keepalive_timeout 75s; //与客户端的连接超时时间，如果连接大量被占用，可以将其改小一些，释放被占用的连接，减轻服务器压力；
...}
阿里云的Web应用防火墙对网站或者APP的业务流量进行恶意特征识别及防护，将正常、安全的流量回源到服务器。避免网站服务器被恶意入侵，保障业务的核心数据安全，解决因恶意攻击导致的服务器性能异常问题。
更多参阅阿里云web防火墙配置文档
CC防护攻击紧急模式
当网站遇到CC攻击的时候，我们一般想到的是第一时间的恢复网站的业务，但这个时候我们可以直接在web应用防火墙上开启CC防护攻击紧急模式。开启之后，能够有效的对客户端校验。
这个模式有一个注意的点就是他这个模式只能对Web应用、网站应用及H5页面有效。对于API以及Native的App会造成大量的误杀，所以这两个应用场景下是不支持攻击紧急模式的。这种情况，我们建议的方案是使用CC自定义防护进行防御。
CC自定义防护
那么随着自定义的一个防御怎么来配置呢？有两个步骤，一是先要从攻击的日志中分析找到攻击的特征。然后使用工具或者对应的功能对我们发现的特征进行封禁，从而达到保护的目的。
特征分析
我们先来看一下CC攻击有哪些特征，一般情况下面最主要最明显的特征是某个URL的请求异常的集中。另外一方面，他请求的源IP异常的集中。第三点，他请求的Refer或者user-agent异常的集中。有了这几个概念之后，我们就可以根据这几个概念去分析日志，获取对应的特征。
我们可以以下面这个网站为例，可以看一下对应的时间段。
从这个日志的一个趋势来看，其实是被打得挺厉害的，峰值时间最高的时候有13万的QPS。那我们怎么来对这种攻击进行分析呢？我们采用了SLS的日志服务，快捷的自动化地进行分析分析的过程。
request URL分析
我们通过对request URL进行分析，可以看到他99%的请求全都请求了//index.php的路径。这个请求占这么大的量绝对是有问题的，正常情况下面对比相同时间段，其实不会有这么大的量出现。那么我们要做的事情就是把恶意的请求给他分辨出来，然后把它拦截表对他进行自定义的CC防护。
规则配置
配置规则的时候，对这个URL进行完全匹配，然后配置我们检测的周期是十秒或者五秒，然后对他进行的检测的次数，在这个时间范围内他访问的次数十次或5次。然后对应的主端动作是可以是封禁，也可以是人机识别。最后是他封禁的时间，可以封禁他三十分钟甚至更长。我的配置是采用封禁的策略，在十秒内访问五次就直接对他进行封禁的一个动作，从而达到对网站业务的一个防护。
这里可以看到还有一个是人机识别的阻断类型，人机识别它是对客户端的请求进行一个脚印的一个过程，它会返回给客户端一串特殊的代码，可以理解为JS的代码，让客户端去执行。
如果能够正常的执行成功，那么说明这个客户端是一个真实的客户端。校验成功过后，我们对他进行加白，让他能够正常访问。如果不能执行，那么这个客户端我们不认为他是一个正常的客户端，会把他拉黑一段时间。这个时间就是我们配置上配的那个时间。
需要注意，在WAF前面如果有高防或者CDN的场景下，我们不建议使用封禁的策略，建议使用人机识别的策略。
经过这段配置，其实我们的网站业务能够得到一定的缓解，如果不能缓解的话，可以根据我们上面配置的一个策略进行调整。由松到紧配置仅一点达到缓解业务的一个效果。
IP分析
得到一定缓解之后，我们继续分析一只去分析更加精确的攻击特征加以保护，提高我们防护的效果。
先看一下源IP分布没有什么特征，没有在几个段里面，然后去查市里面。其实各个市都有，也没有市和省的维度，那这两个不能作为一个明显的一个特征去做防护。
refer或者user-agent分析
那么第三个去通过refer或者user-agent去看，通过refer去看的时候，这边就不说了，因为没有特别明显的特征，但是再去看user-agent的时候，发现99%的请求都是来自于microsoft和Firefox浏览器的请求。
这个访问比例与我们请求的request，index.php的请求比例是非常接近的，然后我们拿着这个user-agent去对比前一天相同时间段的请求，是否有这个user-agent。
前一天的相同时间段下没有出现过类似这样的一个UA。那么我们认为当前时间段出现这个UA的请求是异常的，是恶意的。那么我们针对这个UA进行防护的时候，我们使用WAF的精准防护，控制精准的对这个UA进行配置阻断。
WAF的精准防护配置
配置方式是为了更加准确而使用两个条件，一个是user-agent，让它包含Firefox，另外一个是URL包含上述所说的index.php，同时满足这两个条件的，那我们同时对他进行阻断的操作。
通过这种方式能够有效的将所有恶意的请求排除在外。真正回到原站的请求都是我们判断是可信的一个请求，从而达到防护的效果。
更多参阅阿里云web防火墙配置文档
