那么应用层DDOS到底是怎么一回事呢？这就要从“CC攻击”说起了。

1.CC攻击

“CC攻击”的前身是一个叫的攻击程序，当时黑客为了挑战绿盟的一款反DDOS设备开发了它。绿盟是中国著名的安全公司之一，它有一款叫“黑洞()”的反DDOS设备，能够有效地清洗SYN Flood等有害流量。而黑客则挑衅地将所实现的攻击方式命名为： （简称CC），意指在黑洞的防御下，仍然能有效完成拒绝服务攻击。

CC攻击的原理非常简单，就是对一些资源消耗较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的，在Web应用中，查询数据库、读/写硬盘文件等操作，相对都会消耗比较多的资源。在百度百科中有一个很典型的例子，应用层常见SQL代码规范如下(以PHP为例)：

$sql=“select * from post where tagid=‘$tagid’ order by postid desc limit $start,30”

当post表数据庞大，翻页频繁，$start数字急剧增加时，查询影响结果集=$start+30,该查询效率呈现明显下降趋势，而多并发频繁调用，因查询无法立即完成，资源无法立即释放，会导致数据库请求连接过多，数据库阻塞，网站无法正常工作。

在互联网中充斥着各种搜索引擎、信息收集等系统的爬虫()，爬虫把小网站直接爬死的情况时有发生，这与应用层DDOS攻击的结果很像。由此看来，应用层DDOS攻击与正常业务的界限比较模糊。

应用层DDOS攻击还可以通过以下方式完成：在黑客入侵了一个流量很大的网站后，通过篡改页面，将巨大的用户流量分流到目标网站。比如，在大流量网站siteA上插入一段代码：

那么所有访问该页面的siteA用户，都将对此发起一次HTTP GET请求，这可能直接导致拒绝服务。

应用层DDOS攻击是针对服务器性能的一种攻击，那么许多优化服务器性能的方法，都或多或少地能缓解此种攻击。比如将使用频率高地数据放在中，相对于查询数据库所消耗的资源来说，查询所消耗的资源可以忽略不计，但很多性能优化的方案并非是为了对抗应用层DDOS攻击而设计的，因此攻击者想要找到一个资源消耗大的页面并不困难。比如当查询没有命中时，服务器必然会查询数据库，从而增大服务器资源的消耗，攻击者只需要找到这样的页面即可。同时攻击者除了触发“读”数据操作外，还可以触发“写”数据操作，“写”数据的行为一般会导致服务器操作数据库。

2.限制请求频率

最常见的针对应用层DDOS攻击的防御措施，是在应用中针对每个“客户端”做一个请求频率的限制。通过IP地址和定位一个客户端，如果客户端的请求在一定时间内过于频繁，则对之后来自该客户端的所有请求都重定向到一个出错页面。从架构上来看，这样的防护措施需要放在业务逻辑之前，才能起到保护后端应用的目的，可以看做是一个“基层”的安全模块。

3.道高一尺，魔高一丈

然而这种防御方法并不完美，因为它在客户端的判断依据上并不是永远可靠的。这个方案中有两个因素用以定位一个客户端：一个是IP地址，另一个是。但用户的IP地址可能会发生变化，而又可能会被清空，如果IP地址和同时都发生了变化，那么就无法再定位到同一个客户端了。

如果让IP地址发生变化呢？使用“代理服务器”是一个常见的做法。在实际的攻击中，大量使用代理服务器或傀儡机来隐藏攻击者的真实IP地址，已经成为一种成熟的攻击模式。攻击者使用这些方法可不断地变换IP地址，就可以绕过服务器对单个IP地址请求频率的限制了。

代理猎手是一个常用的搜索代理服务器的工具：

而则已经自动化地实现了这种变换IP地址的攻击，它可以批量导入代理服务器地址，然后通过代理服务器在线暴力破解用户名和密码。

攻击者使用的这些混淆信息的手段，都给对抗应用层DDOS攻击带来了很大的困难。那么到底如何解决一个问题呢？应用层DDOS攻击并非是一个无法解决的问题，一般来说，我们可以从以下几个方面着手：

首先，应用代码要做好性能优化。合理地使用就是一个很好的优化方案，将数据库的压力尽可能转移到内存中。此外还需要及时地释放资源，比如及时关闭数据库连接，减少空连接等消耗。

其次，在网络架构上做好优化。善于利用负载均衡分流，避免用户流量集中在单台服务器上，同时可以利用好CDN和镜像站点的分流作用，缓解主站的压力。

最后，也是最重要的一点，实现一些对抗手段，比如限制每个IP地址的请求频率。

下面继续更深入地探讨还有哪些方法可以对抗应用层DDOS攻击。

三.验证码的那些事儿

验证码是互联网常用的技术之一，它的英文简称是( Test to Tell and Human Apart,全自动区分计算机和人类的图灵测试)。在很多时候，如果可以忽略对用户体验的影响，那么引入验证码这一手段能够有效地阻止自动化的重放行为。

如下是一个用户提交评论的页面，嵌入验证码能够有效防止资源滥用，因为通常脚本无法自动识别出验证码。

但验证码也分三六九等，有的验证码容易识别，有的则较难识别。

发明的初衷是为了识别人和机器。但验证码如果设计得过于复杂，那么人也很难辨识出来，所以验证码是一把双刃剑。

有验证码，就会有验证码破解技术。除了直接利用图像相关算法识别验证码外，还可以利用Web实现上可能存在的漏洞破解验证码。

因为验证码的验证过程，是比对用户提交的名文和服务器端里保存的验证码明文是否一致。所以曾经有验证码系统出现过这样的漏洞：因为验证码消耗掉后未更新，导致使用原有的可以一直重复提交同一个验证码。

还有的验证码实现方式，是提前将所有的验证码图片生成好，以哈希过的字符串作为验证码图片的文件名。在使用验证码时，则直接从图片服务器返回已经生成好的验证码，这种设计原本的想法是为了提高性能。

但这种一一对应的验证码文件名会存在一个缺陷：攻击者可以事先采用枚举方式，遍历所有的验证码图片，并建立验证码到名文之间的一一对应关系，从而形成一张“彩虹表”DDOS，这也会导致验证码形同虚设。修补的方式是验证码的文件名需要随机化，满足“不可预测性”原则。

随着技术的发展，直接通过算法破解验证码的方法也变得越来越成熟。通过一些图像处理技术，可以将验证码逐步变化成可识别的图片。

四.防御应用层DDOS

验证码不是万能的，很多时候为了给用户一个最好的体验而不能使用验证码，且验证码不宜使用过于频繁，所以我们还需要有更好的方案。验证码的核心思想是识别人和机器，那么顺着这个思路，在人机识别方面，我们是否还能再做一些事情呢？答案是肯定的。

在一般情况下，服务器端应用可以通过判断HTTP头中的User-Agent字段来识别客户端。但从安全性来看这种方法并不可靠，因为HTTP头中的User-Agent是可以被客户端篡改的，所以不能信任。

一种比较可靠的方法是让客户端解析一段，并给出正确的运行结果。因为大部分的自动化脚本都是直接构造HTTP包完成的，并非在一个浏览器环境中发起的请求。因此一段需要计算的，可以判断出客户端到底是不是浏览器。类似的，发起一个flash让客户端解析，也可以起到同样的作用。但需要注意的是，这种方法并不是万能的，有的自动化脚本是内嵌在浏览器的“内挂”，就无法检测出来了。

除了人机识别外，还可以在Web 这一层做些防御，其好处是请求尚未到达后端的应用程序里，因此可以起到一个保护的作用。

在的配置文件中，有一些参数可以缓解DDOS攻击。比如调小、值，增加。但需要注意的是，这些参数的调整可能会影响到正常应用，因此需要视情况而定。提供的模块接口为我们扩展、设计防御措施提供了可能。目前已经有一些开源的全部或部分实现了针对应用层DDOS攻击的防护。

“”是的一个，它可以帮助缓解应用层DDOS攻击。比如的下面配置就非常有价值：

#minimum request rate (bytes/sec at request reading):
QS_SrvRequestRate                   120
#limits the connections for this virtual host:
QS_SrvMaxConn                       800
#allow keep-alive support till the server reaches 600 connections:
QS_SrvMaxConnClose                  600
#allow max 50 connections from a single ip address:
QS_SrvMaxConnPerIP                  50
#disables connection restrictions for certain clients:
QS_SrcMaxConnExcludeIP              172.18.3.32
QS_SrcMaxConnExcludeIP              192.168.10.32

有兴趣的朋友可以通过官方网站获得更多的信息。除了之外，还有专用于对抗应用层DDOS的也有类似的效果。从思路上仍然是限制单个IP地址的访问频率，因此在面对单个IP地址或者IP地址较少的情况，比较有用。但是前文曾经提到，如果攻击者使用了代理服务器、傀儡机进行攻击，该如何有效地保护网站呢？

Yahoo为我们提供了一个解决思路。因为发起应用层DDOS攻击的IP地址都是真实的，所以在实际情况下，攻击者的IP地址其实也不可能无限制增长。假设攻击者有1000个IP地址发起攻击，如果请求了10000次，则平均每个IP地址请求同一页面达到了10次，攻击如果持续下去，单个IP地址的请求也将变多，但无论如何变，都是在这1000个IP地址的范围内做轮询。

为此Yahoo实现了一套算法，根据IP地址和等信息，可以计算客户端的请求频率并进行拦截。Yahoo设计的这套系统也是为Web 开发的一个模块，但在整体架构上会有一台服务器集中计算所有IP地址请求频率，并同步策略到每台Web 上。

Yahoo为此申请了一个专利( abuse)，这套防御体系，经过实践检验，可以有效对抗应用层DDOS攻击和一些类似的资源滥用攻击。但Yahoo并未将其开源，因此对于一些研发能力较强的互联网公司来说，可以根据专利中的描述，实现一套类似的系统。

五.资源耗尽攻击

除了CC攻击外，攻击者还可能利用一些Web 的漏洞或设计缺陷，直接造成拒绝服务。下面看几个典型的例子，并由此分析此类分布式拒绝服务攻击的本质。

1.攻击

是在2009年由著名的Web安全专家提出的一种攻击方法，其原理是以极低的速度往服务器发送HTTP请求。由于Web 对于并发的连接数都有一定的上限，因此若是恶意地占用住这些连接不释放，那么Web 的所有连接都将被恶意连接占用，从而无法接受新的请求，导致拒绝服务。

要保持住这个连接，构造了一个畸形的HTTP请求，准确地说，是一个不完整的HTTP请求。比如-:

Content-Length:42\r\n

在正常的HTTP包头中，是以两个CLRF表示HTTP 部分结束的：

Content-Length:42\r\n\r\n

由于Web 只收到了一个\r\n，因此将认为HTTP 部分没有结束，并保持此连接不释放，继续等待完整的请求。此时客户端再发送任意HTTP头，保持住连接即可。

x-a:b\r\n

当构造多个连接后，服务器的连接数很快就会达到上限，从而达到拒绝服务攻击的目的。这种攻击几乎针对所有的Web 都是有效的。从这种方式可以看出：此类拒绝服务攻击的本质，实际上是对有限资源的无限制滥用。

在案例中，“有限”的资源是Web 的连接数。这是一个有上限的值，比如在中这个值由定义。如果恶意客户端可以无限制地将连接数占满，就完成了对有限资源的恶意消耗，导致拒绝服务。

在发布之前，也曾经有人意识到这个问题，但是官方否认的攻击方式是一个漏洞，他们认为这是Web 的一种特性，通过调整参数能够缓解此类问题。对Web 的消极态度使得这种攻击今天仍然有效。

2.HTTP POST DOS

在2010的OWASP大会上，Wong Onn Chee和Tom 演示了一种类似于效果的攻击方法，作者称为HTTP POST D.O.S.。其原理是在发送HTTP POST包时，指定一个非常大的-值，然后以很低的速度发包，比如10-100s发一个字节，保持住这个连接不断开。这样当客户端连接数多了以后，占用住了Web 的所有可用连接，从而导致DOS。

这种攻击的本质也是针对的限制的。要解决此类问题，可以使用Web应用防火墙，或者一个定制的Web 安全模块。

由以上两个例子我们很自然地联想到，凡事资源有“限制”的地方，都可能发生资源滥用，从而导致拒绝服务，也就是一种“资源耗尽攻击”。

出于可用性和物理条件的限制，内存、进程数、存储空间等资源都不可能无限制地增长，因此如果未对不可信任的资源使用者进行配额的限制，就有可能造成拒绝服务。内存泄漏是程序员经常要解决的一种bug，而在安全领域中，内存泄漏则被认为是一种能够造成拒绝服务攻击的方式。

3. Limit DOS

也能造成一种拒绝服务，称为 Limie DOS。Web 对HTTP包头都有长度限制，以举例，默认是8192字节。也就是说，所能接受的最大HTTP包头大小为8192字节(这里指的是 ,如果是 Body，则默认的大小限制是2GB)。如果客户端发送的HTTP包头超过这个大小，服务器就会返回一个4xx错误，提示信息为：

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

假如攻击者通过XSS攻击，恶意地往客户端写入了一个超长的，则该客户端在清空之前，将无法再访问该所在域的任何页面。这是因为也是放在HTTP包头里发送的，而Web 默认会认为这是一个超长的非正常请求，从而导致“客户端”的拒绝服务。要解决此问题，需要调整配置参数e，这个参数设置为0时，对HTTP包头的大小没有限制。

六.一个正则引发的血案：ReDOS

正则表达式也能造成拒绝服务？是的，当正则表达式写得不好时，就有可能被恶意输入利用，消耗大量资源，从而造成DOS，这种攻击被称为ReDOS。

与前面提到的资源耗尽攻击略有不同的是，ReDOS是一种代码实现上的缺陷。我们知道正则表达式是基于NFA( )的，它是一个状态机，每个状态和输入符号都可能有许多不同的下一个状态。正则解析引擎将遍历所有可能的路径直到最后。由于每个状态都有若干个“下一个”状态，因此决策算法将逐个尝试每个“下一个状态”直到找到一个匹配的。比如下面这个正则表达式：

^(a+)+$

当输入只有4个“a”时：

aaaaX

它只有16条可能的路径，引擎很快能遍历完。但是当输入以下字符串时：

aaaaaaaaaaaaaaaaX

就变成了65536条可能的路径，此后每增加一个“a”,路径的数量就会翻倍。这极大地增加了正则引擎解析数据时的消耗。当用户恶意构造输入时，这些有缺陷的正则表达式就会消耗大量的系统资源，比如CPU和内存等，从而导致整台服务器的性能下降，表现的结果是系统速度很慢，有的进程或服务失去响应，与拒绝服务的后果是一样的。由此可见，ReDOS可能会成为一个埋藏在系统中的炸弹。

在今天的互联网中，正则表达式可能存在于任何地方，如WAF、Web前端、Web后端、DB数据库等。但只要任何一个环节存在有缺陷的正则表达式，就都有可能会导致一次ReDOS。

在检查应用安全时，一定不能忽视ReDOS可能造成的影响，对其进行安全评估。

七.DDOS总结

DDOS防范大致分为两个层面，其中之一面向服务器维护人员，这个可以从通用型防范方法，比如通过CDN盾，ADS等，还可以针对常见的DDOS攻击类型提出针对性防范措施，比如针对CC，使用人机识别等；另外一个层面是网络服务商防范DDOS，通常采取配置URPF，近源部署ADS等。从网络层和应用层两方面来防范，网络层较易，应用层较难。

安全领域的方案很少具有唯一性，更多的是看解决方案的全面性。

补充内容：

1.绿盟科技ADS防止DDOS攻击

反欺骗：它会对数据包的地址及端口的正确性进行验证，同时进行反向探测。

协议栈行为模式分析：每个数据包类型需要符合RFC规定，这就好像每个数据包都要有完整规范的着装，只要不符合规范，ADS会自动识别并过滤。

特定应用防护：非法流量总是有一些特定特征的，这就好比即便你混进了顾客群中，但你的行为还是会暴露出你的动机，比如老重复问店员同一个问题，老做同样的动作，这样，你仍然还是会被发现的。

用户行为模式分析：真是的数据是随机访问的，这就好比顾客进店后的行为是随机的，或看看商品，或询询价，或来回比对，或和店员攀谈，而非法流量会大规模地，步调一致地去访问某一个点，这样一来，也是会被ADS识别。

动态指纹识别:合法的流量数据，都会有相应的加密算法，这就好比每个数据进入服务器前，都要通过私下分配的口令验证，如果你说不出口令或这口令不对，那么，ADS就直接把你OUT了。

带宽控制：而真实的访问数据过大时，ADS可以限制其最大输出的流量，以减少下游网络系统的压力，有了这个功能，苹果公司就可以不用这么手忙脚乱

2.URPF防止DDOS攻击

URPF（ Path ）是一种单播反向路由查找技术，用于防止基于源地址欺骗的网络攻击行为。URPF通过检查数据包中源IP地址，并根据接收到数据包的接口和路由表中是否存在源地址路由信息条目，来确定流量是否真实有效，并选择数据包是转发或丢弃。