(CC)与(WAF)之间的较量

  

前言

  

在分享这个事件前,笔者先和大家一起来了解一下CC * * *:

  【CC * * *】

  

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

  

? CC <强> 是DDOS(分布式拒绝服务)的一种,相比其它的DDOS CC似乎更有技术含量一些。这种* * *你见不到真实源IP,见不到特别大的异常流量,但造成服务器无法进行正常连接。

  

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

  

酸爽的时刻

  

?某天下午正,要到下班点的时候,笔者的手机突然振动一下,打开一看,是一条阿里云发的短信。点进去一看,是公司某个项目中的服务器CPU报警的短信,报警内容震惊了! ! ! ! ! !
 (CC)与(WAF)之间的较量”> <br/> ?服务器CPU爆了,紧接着又来收到好几条短信,短信内容和上一条短信是一样的,这个项目集群中所有的服务器CPU都爆了,这还得了。网站可用性的报警短信也来了,打开网站和应用一看,打不开了,一直在“菊花中”,此时笔者的心情是很酸爽的,不知道各位有没有体会过。</p>
  <blockquote>
  <p>往往很多问题都是发生在一瞬间,让你感觉很惊“喜”,所以运维人员的心理素质是要很强大的,在任何时候都要能从容的面对一切刺激。</p>
  </引用>
  <h3>哪里出了问题</h3>
  <p>先登录服务器,服务器CPU干满的情况下,登录服务器的操作也会受影响的,先上看一下吧:<br/> <img src=

  

在登录集群中其它服务器看一下,也是一样的:
 (CC)与(WAF)之间的较量

  

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

  

公司所有的服务器都是标准配置(CPU是16核内存为32 g)。平均一个php-fpm进程占用2米的内存左右,设置最大子进程数量为800个,启动进程为100年,这么计算的话,参数都在合理的范围内,不应该出问题。

  
 <代码>点。max_children=800 # php-fpm最大的子进程数量
  点。start_servers=100 #动态方式下的起始php-fpm进程数量
  点。min_spare_servers=100 #动态方式空闲状态下的最小php-fpm进程数量
  点。max_spare_servers=200 #动态方式空闲状态下的最大php-fpm进程数量 
  

说明:php-fpm进程池开启进程有两种方式,一种是静态的,直接开启指定数量的php-fpm进程,不再增加或者减少;
另一种则是动态的,开始时开启一定数量的php-fpm进程,当请求量变大时,动态的增加php-fpm进程数到上限,当空闲时自动释放空闲的进程数到一个下限。这两种不同的执行方式,可以根据服务器的实际需求来进行调整。

  

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

  

先解决问题,拿一台服务器重启一下nginx, php服务。不行,重启过后还是一样,CPU瞬间满了。会不会php请求复述,服务的时候找不到,一直卡在那里。

  

登录复述,查看一下,复述,内存,cpu,连接数等使用情况都很稳定,服务器和复述的连通性测了也都好了的:

  

 (CC)与(WAF)之间的较量

  

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

(CC)与(WAF)之间的较量