（CC）与（WAF）之间的较量

前言

在分享这个事件前，笔者先和你们一块儿来了解一下CC***：

【 CC***】

 者借助代理服务器生成指向受害主机的合法请求，实现DDOS和假装就叫：CC(ChallengeCollapsar)。
CC主要是用来页面的。CC的原理就是者控制某些主机不停地发大量数据包给对方服务器形成服务器资源耗尽，一直到宕机崩溃。CC主要是用来***页面的，每一个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户（多少线程就是多少用户）不停地进行访问那些须要大量数据操做（就是须要大量CPU时间）的页面，形成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的链接直至就网络拥塞，正常的访问被停止。

 CC是DDOS（分布式拒绝服务）的一种，相比其它的DDOSCC彷佛更有技术含量一些。这种***你见不到真实源IP，见不到特别大的异常流量，但形成服务器没法进行正常链接。

引用百度百科https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545?fr=aladdin

酸爽的时刻

 某天下午，正要到下班点的时候，笔者的手机忽然振动一下，打开一看，是一条阿里云发的短信。点进去一看，是公司某个项目中的服务器CPU报警的短信，报警内容震惊了!!!!!!

 服务器CPU爆了，紧接着又来收到好几条短信，短信内容和上一条短信是同样的，这个项目集群中全部的服务器CPU都爆了，这还得了。网站可用性的报警短信也来了，打开网站和APP一看，打不开了，一直在“菊花中”，此时笔者的心情是很酸爽的，不知道各位有没有体会过。

每每不少问题都是发生在一瞬间，让你感受很“惊喜”， 因此运维人员的心理素质是要很强大的，在任什么时候候都要能从容的面对一切刺激。

哪里出了问题

先登陆服务器，服务器CPU干满的状况下，登陆服务器的操做也会受影响的，先top看一下吧：

在登陆集群中其它服务器看一下，也是同样的：

这个项目以php程序为主，因此集群中的服务器除了php-fpm进程大量占用了CPU之外，没看到其它进程占用，注意看上面的running值，正在运行的进程数量一直居高不下，大量的进程不释放，莫非是调的PHP进程参数有问题，先来看下php的进程配置：

公司全部的服务器都是标准配置（CPU是16核，内存为32G）。平均一个php-fpm进程占用2M的内存左右，设置最大子进程数量为800个，启动进程为100，这么计算的话，参数都在合理的范围内，不该该出问题。

pm.max_children = 800 #php-fpm最大的子进程数量
pm.start_servers = 100 #动态方式下的起始php-fpm进程数量
pm.min_spare_servers = 100 #动态方式空闲状态下的最小php-fpm进程数量
pm.max_spare_servers = 200  #动态方式空闲状态下的最大php-fpm进程数量

说明：php-fpm进程池开启进程有两种方式，一种是static，直接开启指定数量的php-fpm进程，再也不增长或者减小；
另外一种则是dynamic，开始时开启必定数量的php-fpm进程，当请求量变大时，动态的增长php-fpm进程数到上限，当空闲时自动释放空闲的进程数到一个下限。这两种不一样的执行方式，能够根据服务器的实际需求来进行调整。

ps、
iostat、
free、
iftop、等方式查看进程、io、内存及带宽等状况都没有异常，也没有收到其它的报警，ecs服务器、slb负载的流量均无异常，奇怪了？

先解决问题，拿一台服务器重启一下nginx、php服务。不行，重启事后仍是同样，CPU瞬间满了。会不会php请求redis服务的时候找不到，一直卡在那里。

登陆redis查看一下，redis内存、cpu、链接数等使用状况都很稳定，服务器和redis的连通性测了也都Ok的：

这个时间点也没有活动啊，赶忙查看下日志吧。

问题来自CC***

查看一下nginx日志，error.log并无抛出异常日志，在来看看access.log：

发现可疑的请求了，tail -f access.log跟踪了一段时间后，发现不少ip不停的请求这个url “https://公司域名/captcha/new.html?height=35&********************=9999” ，为何会这么多IP会不停的请求这个url呢？查看并测试，发现这个url是登陆页的验证码，以下图所示的验证码，用户登陆时须要验证码才能登陆进去：

笔者开始猜想，会不会验证码被***了。先进入waf查看一下这段时间的业务量访问状况：

从waf的数据能够看到，业务访问量忽然抖增，咱们又没搞活动，也没有搞秒杀，这个点正常访问量不会出现这样的状况的。在来看下waf全量日志、waf总览访问状况：

在来看看上面这张图，笔者随便截的一页图，每条GET都是来自于不一样的IP，大概统计了一下，很多于上千个IP，此时有些朋友是否是想到了，把这些IP给限了。若是你去作IP限制，上千个IP去限制脑壳是否是要抓狂，何况你也不知道哪一个IP是真实用户的请求IP。

在来看看其它图表：

从上图能够看出，在waf的全量日志中，也一样发现和nginx同样的日志请求，被访问次数显示中，这个url一被请求了快30万次了，试想一下，正经常使用户谁会没事一直点击你的验证码。由此能够得出被cc***了。

waf和cc之间的较量

即然被cc***了，确定要处理，若是不用waf的话，单靠在服务器上处理会如何解决呢？利用nginx或iptables限制单ip访问次数、更改web端口、仍是屏蔽ip等，你们能够一块儿讨论一下，有好的建议和方法能够在留言一块儿学习进步。

即然笔者这里用了waf，下面来看看waf和cc之间会怎么玩呢？

一、首先，进入自定义cc配置，以下图：

二、根据以前查找到被***的URI，新增一条自定义规则,以下图所示：

其含义为：单个IP访问目标地址（前缀匹配，也就是匹配到/captcha这一前缀URI的时候）时，一旦在5秒内访问超过3次，就封禁该 IP20 分钟。

说明：

• URI：指定须要防御的具体地址。例如防御一个用户注册的接口，/register。支持输入参数，如 /user?action=login。
• 匹配规则：彻底匹配或前缀匹配。
  彻底匹配即精确匹配，请求地址必须与此处配置彻底同样才会统计。
  前缀匹配是包含匹配，只要是请求的URI以此处配置开头就会统计（例如，/register.html会被统计）。
• 检测时长：指定统计访问次数的周期。须要和访问次数配合。
• 单一IP访问次数：指定在统计周期内，容许单个源IP访问该URL的次数。
• 阻断类型：指定触发条件后的操做，能够是封禁或人机识别。
  封禁：触发条件后，直接断开链接。
  人机识别：触发条件后，用重定向的方式去访问客户端，经过验证后才放行。
• 阻断时间：指定执行阻断动做的时间。

三、配置好了自定CC，咱们来看下效果有没有起做用呢？以下图所示：

从上图黄颜色的线条能够看出，自定义配置的CC***拦截起做用了，没有拦截以前的时间段×××线条是不显示的。

即然CC被拦住了，业务正常了吗？回到服务器上查看，服务器的CPU确实已经恢复正常了，看下业务正常了吗？

打开APP，网站，访问公司的业务果真已恢复正常了。

等待了一段时间后，仍是有小部分用户反馈打不开，这是什么缘由呢，分析一下waf吧：

a,其实在waf上面自定义的CC规则配置是很是严格，在5秒钟以内，单IP访问访问超过3次就封禁掉，这种严格的规则会误杀掉不少真实的用户请求，你须要根据公司的业务反馈，有没有正常的用户被拦截了，等CC***没了，你在把策略规则调宽松一点（好比5秒、单IP40次/50次/60次等等去调整它），一句话，动态调整waf，不要调死。

b,还有，有些公司出口就一个Ip地址，客户端有n多个，共用1个IP出去，像这种状况可能每秒请求的数量就会比较多，这也是正经常使用户的请求，像上面这种严格的规则也可能会被拦截了。

c,waf防火墙，经过人机识别、大数据分析、模型分析等技术识别，对进行拦截。但不一样于与程序交互，安全是人与人的对抗，每一个网站的性能瓶颈也不一样，会在发现一种无效后，分析网站后进行定向。此时，须要根据业务状况来动态调整的，达到更高的防御等级和防御效果。

d,特别是首页内容，不少时候是须要运维人员和开发一块儿去分析、判断哪一个接口或者URI容易受***（好比短信接口、验证码接口等），提早在代码层，和安全层面作好防御，防范于未然。

总结

 整体说来CC的防御没那么简单的，假装手段也是千万变化，CC属于技术技巧强的。防护CC能够经过多种方法，禁止网站代理访问，尽可能将网站作成静态页面，限制链接数量，修改最大超时时间等。除了利用上述方法外，还能够经过第三方的防火墙进行防范，也能够省很多心。

本章内容到此结束，喜欢个人文章，请点击最上方右角处的《关注》！！！