CN101572700A - 一种HTTP Flood分布式拒绝服务攻击防御方法 - Google Patents

Abstract

本发明公开了一种保护Web服务器免受HTTP Flood分布式拒绝服务攻击的方法和装置。该方法部署在网关设备上，网关设备位于客户端与Web服务器之间。方法实现于网络层，对所有进出网络的数据包进行IP分片重组和TCP流重组，并进行HTTP请求的解析。使用基于Cookie和端口重定向的机制鉴别合法请求和恶意请求，验证成功的合法请求会自动地经由网关转发至服务器，而验证失败的恶意请求会被网关过滤。该方法实现了对客户端的透明性和服务端低的资源消耗，能有效地识别并过滤恶意请求，达到良好的防御效果。

Description

一种HTTP Flood分布式拒绝服务攻击防御方法

技术领域

本发明一般地涉及拒绝服务攻击防御领域。更具体的，本发明涉及一种保护Web服务器免受HTTPFlood分布式拒绝服务攻击的方法和装置。

背景技术

分布式拒绝服攻击(DDos：Distributed Deny of Service)由于其潜在的破坏性强，而且难于防止和追查，越来越成为常见的攻击方式，严重地威胁着网络的可用性。最常见的DDos攻击，就是攻击者在短时间内，通过分布在世界各地的计算机产生大规模的垃圾数据或者非法请求，淹没目标服务器或者目标网络。DDos为了躲避检测和过滤，自身进行不断地演变，由早期的SYN Flood、UDP Flood、Ping of Death等单纯的流量型攻击转变为针对应用层的攻击。应用层的拒绝服务攻击中比较显著的一种是面向Web服务器的HTTP Flood攻击。攻击者往往针对Web服务的昂贵操作，以此大量消耗目标服务器的CPU、数据库和磁盘资源。例如，访问Web服务器的某些特定URL，服务器为了响应页面请求，必须进行大量的数据库检索、查询操作，以此大量消耗Web服务器的主机资源，使得正常用户的请求被拒绝。面向Web的HTTP Flood攻击不具备明显特征，能很好地伪装成突发流量，利用传统的技术难以防御，并且攻击者往往只需付出相对较小的代价，就能取得明显的攻击效果。

目前，存在一些技术和方法用于HTTP Flood攻击的检测和防御，但是其能力还十分有限。麻省理工大学的Srikanth Kandula设计和实现了Kill-Bots，该***采用图形测试识别非法请求，对其进行过滤，但是Kill-Bots是对Web服务器内核的扩展，只适用于中小型站点。西班牙Carlos III大学的Juan M.E-T提出采用Markovian模型对Http负载进行分析，建立正常流量的Markovian模型，并计算实时流量与正常流量的偏离度。Markovian模型参数的选取会极大地影响检测率和误警率，但在实际应用环境中参数的确定比较困难。

发明内容

本发明提供了一种保护Web服务器免受HTTP Flood分布式拒绝服务攻击的方法和装置。该方法部署在网关设备上，网关设备位于网络边缘，用于保护网络内所有的Web服务器。网关设备位于客户端与Web服务器之间，检测HTTP的TCP连接状态，使用基于Cookie和端口重定向的机制鉴别合法请求和非法请求。合法请求会自动地经由网关转发至服务器，而非法请求连接会被网关关闭。

Cookie是Web服务器向用户的浏览器发送的一段ASCII码文本。一旦收到Cookie，浏览器会把Cookie请求追踪客户并保持会话状态。Cookie保存在HTTP协议请求或者应答头部在服务器与客户端之间传递。通用的浏览器均能对Cookie进行解析和处理，而大多数攻击工具或者网络蠕虫不具备识别和处理Cookie的能力。利用这一点，网关能够鉴别大多数合法请求和恶意请求。

同时，为了增强网关抵抗攻击的鲁棒性，将端口重定向机制与基于Cookie的方法结合使用。Web服务的开放端口为固定端口(通常为80)，网关收到来自客户端未经认证的HTTP请求时，会将请求重定向到网关随机生成的端口上。客户端只有正确处理了重定向语义，才会被网关识别为合法用户。

网关监控客户端到服务的所有TCP连接，对连接进行IP分片重组和流重组。客户端到服务器的请求先经过网关，网关为了鉴别该请求来自合法的用户或是攻击工具会代替服务器对请求进行响应。网关利用HTTP协议的301响应码，响应内容如附图1所示。301响应码表示请求的数据已永久性地移动到新的位置。网关在Location头字段填入新的URL，改变URL中的Port值为Auth_Port，Path部分保持不变。为了便于处理，Auth_Port值在1024至65536之间随机取值，不能等于80。同时在Set-Cookie头字段指定由网关随机生成的Cookie值。Connection头字段赋值为close，表示关闭本连接，客户端需要重新建立连接发送HTTP请求。网关构造的响应包IP源地址置为Web服务器的地址，所以从客户端的角度，其收到的所有数据包都是来自服务器的，网关对用户来讲是透明的。

合法用户收到301响应，浏览器会自动对响应进行处理。客户端做两个操作：

1.向Web服务器发送带FIN标志位的TCP包关闭本次连接。网关收到FIN数据包后，代替Web服务器给客户端发送ACK包。网关将ACK包中的源IP地址设为服务器地址，并填入合适的TCP头字段，包括序列号、确认号、校验和等。

2.通过三次握手建立新的连接，并对301应答中的URL发起请求，在请求包中使用Cookie头字段，字段的值与应答包中Set-Cookie字段的值相同。

由于客户端再次发出请求前会关闭原先的连接，且网关作为中间人代替Web服务器响应了连接的关闭，Web服务器并不知道。因此，网关需要向Web服务器发送带RST标志的包，通知连接的关闭，该RST包的IP源地址设为客户端的IP地址。

客户端向Web服务器建立新的连接，网关收到新建连接的SYN包，检查目的端口值是否是之前反馈给客户端的端口值，若不是，直接将该数据包丢弃；若是，将数据包转发至服务器的80端口，完成三次握手。此后，该连接上所有的数据包都需要经过网关进行端口转发。

连接建立后，网关收到用户发送的HTTP请求，检查HTTP包Cookie头字段是否包含原先反馈给客户端的Cookie值。若Cookie值符合要求，表明本次请求是合法的，将请求转发给Web服务器。否则，丢弃该请求，并向服务器发送带RST标志的包，通知服务器将连接关闭。因网关作为中间人对服务器透明，RST包IP源地址设置为客户端的IP地址。

通常攻击工具或者网络蠕虫发起分布式拒绝服务攻击时，只是向Web服务器发送大量的HTTP请求，并不对服务器的响应进行处理。当网关返回301应答并在应答中***Cookie时，攻击工具或网络蠕虫并不能正确地解析应答的语义，体现为不能在预设的端口上进行重定向，并且HTTP请求中不会包含预设的Cookie值。网关利用这一点能有效地区分合法请求和攻击请求。攻击请求数据包不会被网关转发给Web服务器，从而避免了对服务器资源的消耗。

附图2表示了合法用户从发出请求到接收到Web服务器响应，与网关和Web服务器的交互过程。

附图3表示了攻击工具或网络蠕虫对Web服务器发起的攻击请求被网关截断的交互过程。

网关的实现基于定制的硬件和操作***，采用专为防火墙设计的硬件平台和裁减的Liunx操作***，上述算法的实现基于Liunx Netfilter框架。Netfilter是一种Liunx内核中用于扩展各种网络服务的结构化底层框架，它为IPv4、IPv6定义了一套钩子函数，钩子函数在数据报流过协议栈的几个关键点被调用。Netfilter提供了5个钩子函数挂载点，分别是NF_IP_PRE_ROUTING、NF_IP_FORWARD、NF_IP_LOCAL_IN、NF_IP_LOCAL_OUT、NF_IP_POST_ROUTING。内核模块可以对每种协议的一个或多个钩子进行注册，实现挂接。当某个数据包被传递给Netfilter框架时，内核检测是否有模块对该协议的钩子函数进行了注册，若注册了，则调用该模块注册时使用的回调函数。在回调函数中实现用户自定义的功能。

本发明提出的算法通过挂接在NF_IP_PRE_ROUTING的钩子函数实现，但不局限于NF_IP_PRE_ROUTING挂接点。本算法按照逻辑功能可划分为4个模块：流重组模块、端口验证模块、HTTP请求验证模块、端口转发模块。附图5表示了数据包流经网关的过程和各逻辑模块间的关系。

流重组模块使用Hash表存储正在建立连接和已经连接的TCP流，如附图4所示。Hash表由数组构成，数组中的每一个元素指向tcp_stream结构的双向链表，一个tcp_stream结构对应一个TCP连接。操作Hash表的关键数据结构是tuple，tuple是源地址、目的地址、源端口号、目的端口号的4元组。网关接收一个新的数据包时，首先调用Linux***函数ip_defrag进行IP分片重组。重组完成后，对tuple做Hash运算得到对应的Hash表数组下标，遍历该数组元素指向的tcp_stream结构双向链表，查找数据包是否属于网关已经维护的一个TCP连接。若没有找到，对tuple做逆运算，即调换源地址与目的地址、源端口号与目的端口号得到reverse_tuple，使用reverse_tuple重复上述的Hash表查找过程。

tcp_stream结构描述了一个TCP连接的所有信息，关键的变量包括2个half_stream结构分别描述客户端、服务器信息；一个verifier结构封装HTTP请求验证函数；一个reassem_stop标志位标识TCP重组是否继续进行；一个data缓冲区保存已排序的应用层数据。当***收到一个新的SYN数据包，且其不属于***维护的任何一个TCP连接时，表明它为TCP三次握手的SYN包。调用端口验证模块，检查其目的端口否为保护服务的开放端口或是重定向Auth_Port端口，若是，则为该TCP连接初始化一个新的tcp_stream结构加入Hash表，否则，直接丢弃SYN包。若目的端口是预期的Auth_Port端口，则调用端口转发模块将其转发至服务器的80端口。初始化tcp_stream结构时注册verifier结构，TCP重组的适当时候会根据verifier调用相应的HTTP请求验证函数。使用verifier结构的好处是使应用层的检查模块化，当需要添加新的验证逻辑时，只需在verifier结构中注册新的验证函数。

本算法只关心客户端发往服务器的应用层数据，tcp_stream结构的data缓冲区中存放已排序的应用层数据，在客户端的half_stream结构里维护失序的TCP包链表。当有新的TCP包到来，判断TCP重组条件：若未完整获取第一个HTTP请求的头部数据，并且已经重组的数据包长度或数据包个数未达到上限，则进行TCP重组；否则，停止重组，直接进行数据包转发。进行TCP重组时，检查序列号，将循序到达的包加入data缓冲区，作为HTTP请求验证函数的输入，失序的数据包存入half_stream的TCP包链表，供后续TCP重组使用。

每当有新的数据加入data缓冲区，会调用HTTP请求验证模块。验证模块判断data缓冲区是否已包含完整的HTTP头部数据，若是，进行Cookie值合法性检查；否则，终止本次检查，等待完整的HTTP头部数据到达。HTTP协议1.1版本默认采取持久连接，即在一个TCP连接中可进行多次HTTP请求和应答。持久连接中只需对第一个HTTP请求进行检查。那么完整获取第一个HTTP请求的头字段后，将reassem_top标志位置位，表示该TCP连接的后续数据无需重组，后续的数据包根据检查结果直接转发或丢弃。HTTP协议1.0及之前版本不支持持久连接，一个TCP连接中只可发送一次HTTP请求。网关对其的处理与1.1版本类似，不再累述。

端口验证模块在网关收到TCP三次握手的SYN包时被调用。若目的端口为80，表示即将建立的连接不是重定向连接，为该连接初始化tcp_stream结构。若目的端口非80，表明即将建立的连接是经过网关重定向的连接，检查端口号是否与源IP地址相对应，若对应，为该连接初始化tcp_stream结构，将该数据包交由端口转发模块进行转发；若不对应，将该数据包丢弃。

HTTP请求验证模块在获取TCP连接中第一个完整的HTTP请求头部时被调用。该模块检查请求头中的Cookie字段，按照数据包内容的不同，可能出现以下4种情况：

1.HTTP请求头中没有Cookie字段，且TCP目的端口为80，则网关给客户端发送301应答，在301应答中填入新的URL地址，新URL中填入为该客户端随机生成的端口值Auth_Port。在301应答头部加入Set-Cookie字段，填入随机生成的Cookie值。端口号、Cookie值、及对应的客户端IP地址会被记录下来，供之后的验证使用。同时，301应答头部Connection字段设为close，表示关闭本连接。因为网关对客户端透明，301应答的源IP地址设为Web服务器的地址，从客户的角度，该应答是从Web服务器发出的。同时，网关需要给Web服务器发送带RST标志的TCP包，通知服务器将本连接关闭。同样RST包的源地址设为客户端的IP地址。

2.HTTP请求头中没有Cookie字段，且TCP目的端口非80。因为只有经过网关重定向的数据包才会发往非80端口，但此时请求头中没有Cookie字段，表明该请求为非法请求。网关将数据包直接丢弃，并向Web服务器发送带RST标志位的包，通知Web服务器将已建立的连接关闭，减小Web服务器的资源消耗。

3.HTTP请求头中包含Cookie字段，且TCP目的端口为80。因目的端口为80，表明该连接未经过网关重定向，请求头中的Cookie为服务器与客户之间的约定，并不是由网关指定。类似于1中的情况，网关代替Web服务器给客户端发送301应答，应答中填入新的端口号和Cookie值。此时由网关随机生成的Cookie附在源Cookie值的后面，不会破坏原Cookie的语义。同时，网关需要给Web服务器发送带RST标志的TCP包，通知服务器将本连接关闭。

4.HTTP请求头中包含Cookie字段，且TCP目的端口非80。因目的端口非80，表明该连接经过了网关重定向，此时需进一步检查Cookie值的合法性。根据源IP地址查找网关为该客户端生成的Cookie值，检查存储的Cookie值是否是当前请求包中Cookie值的子串，若是，表明HTTP请求合法，调用端口转发模块进行转发；否则，将该请求丢弃，并向Web服务器发送带RST标志位的包，通知Web服务器将已建立的连接关闭。

上述1和3的情况下，网关在301应答中置Connection头字段值为close，通知客户端关闭连接。随后，网关收到来自客户端的带FIN标志的TCP数据包，网关需要代替Web服务器对该FIN包进行ACK回应。

网关对端口号和Cookie值的生成、维护、更新描述如下。端口号和Cookie值根据客户端源IP地址组织为一棵二叉排序树，如附图6所示。树中每个结点保存了IP源地址及该IP地址对应的存储结构。每个存储结构包括端口号、Cookie值、时间信息。端口号和Cookie值均具有时效性，存在时间超过一定值的端口号和Cookie值会失效。二叉排序树中，若根结点的的左子树非空，则左子树中所有结点的IP源地址小于根结点的IP源地址值；若根结点的右子树非空，则右子树中所有结点的IP源地址大于根结点的IP源地址值。左、右子树又各是一棵二叉排序树。网关生成重定向应答时，随机生成端口号和Cookie值，并记录下生成时间，根据客户端的源IP地址，在二叉树的适当位置***存储结构。网关收到新建连接的SYN包或者获取一个完整的HTTP头部数据时，查找二叉排序树，判断目的端口号或者Cookie值是否符合，且生成时间未超过时延，根据查找的结果进行后续的操作。TCP连接关闭时，删除源IP地址对应的结点。

附图说明

图1是网关利用HTTP协议301响应码进行应答的示意图。

图2是合法用户从发出请求到接收Web服务器响应与网关、Web服务器交互过程的示意图。

图3是攻击工具或网络蠕虫对Web服务器发起攻击被网关截断的交互过程示意图。

图4是实现TCP连接跟踪的数据结构示意图。

图5是网络数据包流经网关防御逻辑模块的示意图。

图6是网关维护端口号和Cookies值的数据结构示意图。

Claims (10)

1.一种网关保护Web服务器免受HTTP Flood分布式拒绝服务攻击的防御方法，所述的网关设置在Web服务器所在的网络边缘，所述方法包括步骤：

客户端连接Web服务器的开放端口，建立三次握手，网关接收客户端向服务器发送的HTTP请求。

网关代替Web服务器向客户端发送301应答。为该客户端生成全局唯一的Cookie和端口值；使用新生成的端口号代替开放端口，构造新的URL，将Cookie值和新URL在301应答头部返回给客户端。301应答的头部设置Connection字段值为close，通知客户端关闭本次连接。

网关接收客户端发送的带FIN标志的TCP包，该数据包是客户端用于通知服务器关闭本次连接的，网关作为中间人以服务器名义向客户端发送带ACK标志的TCP包响应连接的关闭。

网关以客户端名义向服务器发送带RST标志的TCP包，通知服务器关闭连接。

客户端连接Web服务器的非开放端口。网关接收建立三次握手的SYN数据包，验证目的端口值是否为预期的值，若是，对数据包进行端口转发，允许TCP连接的建立；若不是，丢弃SYN数据包。

在非开放端口建立连接后，网关接收客户端向服务器发送的HTTP请求，网关验证HTTP请求头部是否包含预期的Cookie值，若包含，将HTTP请求转发给Web服务器；若不包含，将HTTP请求丢弃，并以客户端名义向服务器发送带RST标志的TCP包，通知服务器关闭连接。

2.如权利要求1所述的方法，其特征在于网关位于客户端与Web服务器之间，包括对所有经过的IP报文进行IP分片重组的装置。

3.如权利要求1所述的方法，其特征在于网关包括对所有经过的TCP数据包进行流重组的装置。

4.如权利要求1所述的方法，其特征在于网关包括识别HTTP请求，并对请求头部进行解析的装置。

5.如权利要求1所述的方法，其特征在于网关包括代替Web服务器对客户端HTTP请求进行应答的装置。

6.如权利要求1所述的方法，其特征在于网关包括获取正确的TCP头部序列号、确认号，代替Web服务器对客户端发送的带FIN标志TCP包进行应答的装置。

7.如权利要求1所述的方法，其特征在于网关包括代替客户端对服务器发送带RST标志TCP包的装置。

8.如权利要求1所述的方法，其特征在于网关包括验证TCP连接目的端口是否合法的装置，包含对所有客户端端口值进行生成、维护、更新的装置。

9.如权利要求1所述的方法，其特征在于网关包括对数据包进行端口转发的装置。

10.如权利要求1所述的方法，其特征在于网关包括对每个客户端的Cookie进行生成、维护、更新的装置；包含检查Cookie是否有效的装置。

Images