白帽子讲Web安全（第 13 章 应用层拒绝服务攻击）

第 13 章 应用层拒绝服务攻击

13.1 DDOS 简介

DDOS 又称为分布式拒绝服务，全称是 Distributed Denial of Service 。 DDOS 本是利用合理的请求造成资源过载，导致服务不可用。

分布式拒绝服务攻击，将正常请求放大了若干倍，通过若干个网络节点同时发起攻击，以达成规模效应。这些网络节点往往是黑客们所控制的“肉鸡”，数量达到一定规模后，就形成了一个“僵尸网络”。大型的僵尸网络，甚至达到了数万、数十万台的规模。如此规模的僵尸网络发起的 DDOS 攻击，几乎是不可阻挡的。

常见的 DDOS 攻击有 SYN flood 、UDP flood 、ICMP flood 等。其中 SYN flood 是一种最为经典的 DDOS 攻击，其发现于 1996 年，但至今仍然保持着非常强大的生命力。SYN flood 如此猖狂是因为它利用了 TCP 协议设计中的缺陷，而 TCP/IP 协议是整个互联网的基础，牵一发而动全身，如今想要修复这样的缺陷几乎称为不可能的事情。

在正常情况下，TCP 三次握手过程如下：

1. 客户端向服务端发送一个 SYN 包，包含客户端使用的端口号和初始序列号 x ；
2. 服务器端收到客户端发送来的 SYN 包后，向客户端发送一个 SYN 和 ACK 都置位的 TCP 报文，包含确认号 x+1 和服务器端的初始序列号 y ；
3. 客户端收到服务器端返回的 SYN + ACK 报文后，向服务器端返回一个确认号为 y+1 、序号为 x+1 的 ACK 报文，一个标准的 TCP 连接完成。

而 SYN flood 在攻击时，首先伪造大量的源 IP 地址，分别向服务器端发送大量的 SYN 包，此时服务器端会返回 SYN/ACK 包，因为源地址是伪造的，所以伪造的 IP 并不会应答，服务器端没有收到伪造 IP 的回应，会重试 3~5 次并且等待一个 SYN time（一般为 30 秒至 2 分钟），如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的 SYN 请求，服务器端将会消耗非常多的资源（ CPU 和内存 ）来处理这种半连接，同时还要不断地对这些 IP 进行 SYN+ACK 重试。最后的结果是服务器无暇理睬正常的连接请求，导致拒绝服务。

对抗 SYN flood 的主要措施有 SYN Cookie/SYN Proxy、safereset 等算法。SYN Cookie 的主要思想是为每一个 IP 地址分配一个“ Cookie ”，并统计每个 IP 地址的访问频率。如果在短时间内收到大量的来自同一个 IP 地址的数据包，则认为收到攻击，之后来自这个 IP 地址的包将被丢弃。

在很多对抗 DDOS 的产品中，一般会综合使用各种算法，结合一些 DDOS 攻击的特征，对流量进行清洗。对抗 DDOS 的网络设备可以串联或者并联在网络出口处。

但 DDOS 仍然是业界的一个难题，当攻击流量超过了网络设备，甚至带宽的最大负荷时，网络仍将瘫痪。一般来说，大型网站之所以看起来比较能“抗” DDOS 攻击，是因为大型网站的带宽比较充足，集群内服务器的数量也比较多。但一个集群的资源毕竟是有限的，在实际的攻击中， DDOS 的流量甚至可以达到数 G 到 几十 G ，遇到这种情况，只能与网络运营商合作，共同完成 DDOS 攻击的相应。

13.2 应用层 DDOS

应用层 DDOS ，不同于网络层 DDOS ，由于发生在应用层，因此 TCP 三次握手已经完成，连接已经建立，所以发起攻击的 IP 地址也都是真实的，但应用层 DDOS 有时甚至比网络层 DDOS 攻击更为可怕，因为今天几乎所有的商业 Anti-DDOS 设备，只在对抗网络层 DDOS 时效果较好，而对应用层 DDOS 攻击却缺乏有效的对抗手段。

13.2.1 CC 攻击

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

CC 攻击的原理非常简单，就是对一些消耗资源较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的。在 Web 应用中，查询数据库、读/写硬盘文件等操作，相对都会消耗比较多的资源。

应用层 DDOS 攻击是针对服务器性能的一种攻击，那么许多优化服务器性能的方法，都或多或少的能缓解此种方法。

13.2.2 限制请求频率

常见的针对应用层 DDOS 攻击的防御措施，是在应用中针对每个“客户端”做一个请求频率的限制。

13.2.3 道高一尺，魔高一丈

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

如何让 IP 地址发生变化呢？

1. 代理服务器
2. 傀儡机

攻击者使用的混淆手段，我们如何进行防御 DDOS 攻击：

1. 应用代码要做好性能优化；
2. 网络架构上做好优化；
3. 实现一些对抗手段，比如限制每个 IP 地址的请求频率。

13.3 验证码的那些事儿

验证码是互联网中常用的技术之一，它的英文简称是 CAPTCHA （ Completely Automated Public Turing Test to Tell Computers and Humans Apart ，全自动区分计算机和人类的图灵测试）。

引入验证码能够有效的阻止自动化的重放行为。

13.4 防御应用层 DDOS

13.5 资源耗尽攻击

13.5.1 Slowloris 攻击

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

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

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0\r\n
Content-Length: 42\r\n

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

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

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

X-a: b\r\n

当构造多个连接后，服务器的连接数很快就会达到上限。

此类拒绝服务攻击的本质，实际上是对有限资源的无限制滥用。

13.5.2 HTTP POST DOS

在 2010 年的 OWASP 大会上，Wong Onn Chee 和 Tom Brennan 演示了一种类似于 Slowloris 效果的攻击方法，作者称之为 HTTP POST D.O.S 。

其原理是在发送 HTTP POST 包时，指定一个非常大的 Content-Length 值，然后以很低的速度发包，比如 10~100s 发一个字节，保持住这个连接不断开。这样当客户端连接数多了以后，占用住了 Web Server 的所有可用连接，从而导致 DOS。

凡是资源有“限制”的地方，都可能发生资源滥用，从而导致拒绝服务，也就是一种“资源耗尽攻击”。

出于可用性和物理条件的限制，内存、进程数、存储空间等资源都不可能无限制的增长，因此如果未对不可信任的资源使用者进行配额的限制，就有可能造成拒绝服务。内存泄露则被认为时一种能够造成拒绝服务攻击的方式。

13.5.3 Server Limit DOS

Cookie 也能造成一种拒绝服务，利用 Web Server 对 HTTP 包头都有长度限制。比如说：

假如攻击者通过 XSS 攻击，恶意的往客户端写入了一个超长的 Cookie ，则该客户端在清空 Cookie 之前，将无法再访问该 Cookie 所在域的任何页面。这是因为 Cookie 也是放在 HTTP 包头里发送的，而 Web Server 默认会认为这是一个超长的非正常请求，从而导致“客户端”的拒绝服务。

13.6 一个正则引发的血案：ReDOS

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

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