阿里云的Web应用防火墙对网站或者APP的业务流量进行恶意特征识别及防护，将正常、安全的流量回源到服务器。避免网站服务器被恶意入侵，保障业务的核心数据安全，解决因恶意攻击导致的服务器性能异常问题。
今天我们就来说说CC防护攻击怎么配置规则。CC攻击是DDOS（分布式拒绝服务）的一种，攻击者通过代理服务器向受害主机大批量的发出合法的请求。
相关产品资料：
1.Web应用防火墙
2.云安全中心
3.DDOS防护
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是否有什么特征，我们可以源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，同时满足这两个条件的，那我们同时对他进行阻断的操作。
通过这种方式能够有效的将所有恶意的请求排除在外。真正回到原站的请求都是我们判断是可信的一个请求，从而达到防护的效果。
原文链接：https://blog.csdn.net/qq_43486781/article/details/110532363
