一.引言

HTTP Flood攻击 DDoS的一种,别称叫做CC攻击(CC是Challenge Collapsar的缩写，而Collapsar是国内一家著名安全公司的DDoS防御设备) ，是针对Web服务在 第七层协议发起的攻击，重点在于突破前端的cache,通过HTTP头中的字段设置直接到达Web Server本身.第七层主要是 应用层，是一些终端的应用，比如（各种文件下载）、浏览器、QQ等，可以将其理解为在电脑屏幕上可以看到的东西，也就是我们常说的终端应用。HTTP Flood攻击的巨大危害性主要表现在三个方面：发起方便、过滤困难、影响深远。一般的攻击者会选择搜索之类需要做大量数据查询的页面作为攻击目标，可以消耗服务器尽可能多的资源。攻击时尽量选择正常用户也通过APP访问的页面，一般来说就是各种Web API。正常用户和恶意流量都是来源于APP，人机差别很小，基本融为一体难以区分

二.攻击原理

攻击者通过端口扫描程序在互联网上寻找匿名的HTTP 代理(代理是一种比较丰富的资源，花几天时间获取代理并不是难事，因此攻击容易发起而且可以长期高强度的持续)或者SOCKS代理或僵尸主机向目标服务器发起大量的 HTTP报文请求，请求涉及 数据库操作的URI（Universal Resource Identifier）或 其它消耗系统资源的URI，并且攻击在HTTP层发起，极力模仿正常用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案,从而造成服务器资源耗尽，无法响应正常请求,这个攻击类型和一种网络攻击有点像，就是 CC攻击（Challenge Collapsar），两者区别就在于一个是 消耗系统资源，一个是发送大量数据包 消耗服务器资源，都是打的持续仗，最终使服务器无法响应正常请求为止.HTTP Flood攻击会引起严重的连锁反应，不仅仅是直接导致被攻击的Web前端响应缓慢，还间接攻击到后端的业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对日志存储服务器都带来影响。例如门户网站经常受到的HTTP Flood攻击，攻击的最大特征就是选择消耗服务器CPU或内存资源的URI，如具有数据库操作的URI

三.防御原理

• HTTP Flood源认证

源认证防御方式是防御HTTP Flood最常用的手段，这种防御方式适用于客户端为浏览器的HTTP服务器场景，因为浏览器支持完整的HTTP协议栈，可以正常回应重定向报文或者是验证码，Anti-DDoS设备基于目的IP地址对HTTP报文进行统计，当HTTP报文达到设定的告警阈值时，启动源认证防御功能，源认证防御包含以下三种方式：

• 基本模式（META刷新）

该模式可有效阻止来自非浏览器客户端的访问，如果僵尸工具没有实现完整的HTTP协议栈，不支持自动重定向，无法通过认证。而浏览器支持自动重定向，可以通过认证，处理过程如图所示，该模式不会影响用户体验，但防御效果低于增强模式

当网络中有HTTP代理服务器时，只要有一次源认证通过，Anti-DDoS设备就会将代理服务器IP地址加入白名单，后续僵尸主机通过使用代理服务器就会绕开源认证，导致防御失效。在这种有代理服务器的网络中，建议开启代理检测功能，检测HTTP请求是否为通过代理发出的请求。如果是，Anti-DDoS设备会从HTTP报文中获取请求者的实际IP地址，将通过认证的真实IP地址和代理服务器IP地址加入白名单，后续只有此实际源IP地址发送的报文才能直接通过，其他源IP发送报文时，Anti-DDoS设备会对其进行源认证，达到防御效果。

• 增强模式（验证码认证）

有些僵尸工具实现了重定向功能，或者攻击过程中使用的免费代理支持重定向功能，导致基本模式的防御失效，通过推送验证码的方式可以避免此类防御失效。此时通过让用户输入验证码，可以判断HTTP访问是否由真实的用户发起，而不是僵尸工具发起的访问。因为僵尸网络攻击依靠自动植入PC的僵尸工具发起，无法自动响应随机变化的验证码，故可以有效的防御攻击。为避免防御对正常用户体验的影响，此防御方式仅对超过源访问阈值的异常源实施。具体处理过程如图所示

注意：
源认证对于机顶盒做视频点播场景防护、或者部分移动网络防护不适用。当客户端是机顶盒、特定移动网络时，客户端无法输入验证码，建议使用动态指纹学习或URI监控防御

• 302重定向模式

基本模式中的重定向功能只能对整个网页进行重定向，不能针对网页中的内嵌资源（比如：图片）进行重定向。当用户请求的页面与页面内嵌资源不在同一个服务器上，内嵌资源所在服务器发生异常时，可以对嵌套资源服务器启动302重定向防御，探测访问源是否为真实浏览器。真实浏览器支持重定向功能，可以自动完成重定向过程，不会影响客户体验,如果在允许的认证时间周期内，对同一源IP地址的认证次数大于最大值时，则将该源IP地址判定为攻击源，加入动态黑名单

• HTTP源统计

HTTP源统计是在基于目的IP流量异常的基础上，再启动针对源IP流量进行统计。Anti-DDoS设备首先对到达目的IP的流量进行统计，当目的IP流量触发告警阈值时，再启动到达这个目的IP的每个源的流量进行统计，判定具体某个源流量异常，并对源IP的流量进行限速。
HTTP源统计功能可以更准确的定位异常源，并对异常源发出的流量进行限速。

• URI监测

URI监测是HTTP源认证防御的补充功能，当通过HTTP源认证的流量还是超过阈值时，可以启用URI监测。Anti-DDoS设备对HTTP源认证过程中加入白名单的源IP也会进行URI监测。
当指定时间内，某个URI的访问流量超过一定阈值时，Anti-DDoS设备启动针对源IP的URI行为监测。当这个源IP地址对某个URI的访问数与总访问数的比例超过阈值时，则将该源IP地址作为攻击源并加入动态黑名单。在配置URI监测时，可将消耗内存或计算资源多、容易受攻击的URI加入“重点监测URI”列表。

• URI源指纹学习功能

指纹学习方法适用于攻击源访问的URI比较固定。因为如果要形成攻击效果，攻击者一般都事先探测，找到容易消耗系统资源的URI作为攻击目标，然后一个攻击源的一个会话上会有多个针对该URI的请求，最终呈现为该源对选定的URI发送大量的请求报文。动态指纹学习正是基于这个原理，Anti-DDoS设备对源访问的URI进行指纹学习，找到攻击目标URI指纹，如果对该URI指纹的命中次数高于设置的阈值就将该源加入黑名单。

四.防御方法

1.主动抑制

为了让Nginx支持更多的并发连接数，根据实际情况对工作进程数和每个工作进程支持的最大连接数进行调整。例如设置“ worker_processes 10”和“worker_connections 1024”，那这台服务器支持的最大连接数就是10×1024=10240。

worker_processes 10;
events {
        use epoll;
        worker_connections 1024;
}

Nginx 0.7开始提供了2个限制用户连接的模块： NginxHttpLimitZoneModule和 NginxHttpLimitReqModule

NginxHttpLimitZoneModule可以根据条件进行并发连接数控制

例如可以定义以下代码：

http {
     limit_zone   my_zone  $binary_remote_addr  10m;
    server {
             location   /somedir/   {
                       limit_conn   my_zone  1;
            }
   }
}

其中“limit_zone my_zone $binary_remote_addr 10m” 的意思是 定义一个名称为my_zone的存储区域、 my_zone中的内容为远程IP地址、my_zone的大小为10M；“ location /somedir/” 的意思是针对somedir目录应用规则；“ limit_conn my_zone 1”的意思是针对上面定义的my_zone 记录区记录的IP地址在指定的目录中只能建立一个连接

NginxHttpLimitReqModule可以根据条件进行请求频率的控制

例如可以定义以下代码：

http {
       limit_req_zone   $binary_remote_addr   zone=my_req_zone:  10m   rate=1r/s;
       ...
       server  {
            ...
            location /somedir/  {
                        limit_req_zone   zone= my_req_zone  burst=2;
        }

其中“limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s” 的意思是定义一个名称为 my_req_zone的存储区域，my_req_zone内容为远程IP地址，my_req_zone大小为 10M，my_req_zone中的平均请求速率只能为1个每秒；“ location /somedir/ ” 的意思是针对somedir目录应用规则；“l imit_req_zone zone= my_req_zone burst=2”的意思是针对上面定义的my_req_zone记录区记录的IP地址在请求指定的目录中的内容时最高2个每秒的突发请求速率。
当有连接触发上诉规则时，Nginx会报“503 Service Temporarily Unavailable”的错误，停止用户请求。返回一个503，对服务器来说影响不大，只占用一个nginx的线程而已，相对来说还是很划算的

2.被动防御

主动防御已经抵挡了大多数HTTP GET FLOOD攻击，但攻击者会总会找到薄弱的环节进行攻击,所以我在这里介绍一下被动防御的一些方法

(1).封IP地址

访问者通过浏览器正常访问网站，与服务器建立的连接一般不会超过20个，可以通过脚本禁止连接数过大的IP访问.
以下脚本通过netstat命令列举所有连接，将连接数最高的一个IP如果连接数超过150，则通过 iptables阻止访问

#!/bin/sh
status=`netstat -na|awk '$5 ~ /[0-9]+:[0-9]+/ {print $5}' |awk -F ":" -- '{print $1}' |sort -n|uniq -c |sort -n|tail -n 1`
NUM=`echo $status|awk '{print $1}'`
IP=`echo $status|awk '{print $2}'`
result=`echo "$NUM > 150" | bc`
if [ $result = 1 ]
then
  echo IP:$IP is over $NUM, BAN IT!
  /sbin/iptables -I INPUT -s $IP -j DROP
fi

运行crontab -e，将上述脚本添加到crontab每分钟自动运行：

* * * * * /root/xxxx.sh

通过apache自带的ab工具进行服务器压力测试：

ab -n 1000 -c 100 http://www.xxx.com/index.php

测试完成后，就可以看到系统中有IP被封的提示：

[root@xxxxxx ~]#tail /var/spool/mail/root
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <;PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

IP:58.246.xx.xx is over 1047, BAN IT!

至此，HTTP GET FLOOD防御成功

(2).根据特征码屏蔽请求（对CC攻击效果较好）

一般同一种CC攻击工具发起的攻击请求包总是相同的，而且和正常请求有所差异。当服务器遭遇CC攻击时，可以快速查看日志，分析其请求的特征，比如User-agent。

下面的是某一次CC攻击时的User-agent

Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE 3.01)Cache-Control: no-store, must-revalidate

几乎没有正常的浏览器会在User-agent中带上“must-revalidate”这样的关键字,所以可以以这个为特征进行过滤，将User-agent中带有“must-revalidate”的请求全部拒绝访问,在nginx配置里面的代码如下：

if ($http_user_agent ~ must-revalidate) {
       return 403;
}