DDOS攻击剖析

DDOS攻击剖析"/>

DDOS攻击剖析

**

一、DDOS简介

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

二、DDOS分类

**
网络层DDOS：
DDOS分为：SYN flood、UDP flood、ICMP flood。
SYN flood是一种最为 经典的DDOS攻击，其发现于19%年，但至今仍然保持着非常强大的生命力。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 flood 的主要措施有 SYN Cookie/SYN Proxy、safereset 等算法。SYN Cookie 的主要 思想是为每一个〖P地址分配一个“Cookie”，并统计每个IP地址的访问频率。如果在短时间内 收到大量的来自同一个IP地址的数据包，则认为受到攻击，之后来自这个IP地址的包将被丢弃。
为什么大型的网站能够对抗DDOS？
因为大型网站 的带宽比较充足，集群内服务器的数量也比较多。但一个集群的资源毕竟是有限的，在实际的 攻击中，DDOS的流量甚至可以达到数G到几十G，遇到这种情况，只能与网络运营商合作， 共同完成DDOS攻击的响应。
应用层DDOS：
应用层DDOS,不同于网络层DDOS,由于发生在应用层，因此TCP三次握手已经完成， 连接己经建立，所以发起攻击的IP地址也都是真实的。
cc攻击：
CC攻击的原理非常简单，就是对一些消耗资源较大的应用页面不断发起正常的请求，以 达到消耗服务端资源的目的。在Web应用中，査询数据库、读/写硬盘文件等操作，相对都会 消耗比较多的资源。
应用层常见SQL代码范例如下（以PHP为例）：
$sql="select * from post where tagid=’ $tagid’ order by postid desc limit s t a r t , 30 " ; 当 p o s t 表 数 据 庞 大 ， 翻 页 频 繁 ， start ,30"; 当post表数据庞大，翻页频繁， start,30";当post表数据庞大，翻页频繁，start数字急剧增加时，查询影响结果集=$51811+30;该查询效率呈现明显下降趋势，而多并发频繁调用，因查询无法立即完成，资源无法立即释 放，会导致数据库请求连接过多，数据库阻塞，网站无法正常打开。
应用层DDOS攻击还可以通过以下方式完成：在黑客入侵了一个流量很大的网站后，通过 篡改页面，将巨大的用户流量分流到目标网站。
应用层DDOS攻击的防御：
应用层DDOS攻击是针对服务器性能的一种攻击，那么许多优化服务器性能的方法，都或 多或少地能缓解此种攻击。比如将使用频率高的数据放在memcache中，相对于查询数据库所 消耗的资源来说，查询memcache所消耗的资源可以忽略不计。但很多性能优化的方案并非是 为了对抗应用层DDOS攻击而设计的，因此攻击者想要找到一个资源消耗大的页面并不困难。 比如当memcache查询没有命中时，服务器必然会查询数据库，从而增大服务器资源的消耗， 攻击者只需要找到这样的页面即可。同时攻击者除了触发“读”数据操作外，还可以触发“写” 数据操作，“写”数据的行为一般都会导致服务器操作数据库。
最常见的针对应用层DDOS攻击的防御措施，是在应用中针对每个“客户端”做一个请求 频率的限制。它的思路很简单，通过IP地址与 Cookie定位一个客户端，如果客户端的请求在一定时间内过于频繁，则对之后来自该客户端的 所有请求都重定向到一个出错页面。
然而这种防御方法并不完美，因为它在客户端的判断依据上并不是永远可靠的。这个方案 中有两个因素用以定位一个客户端：一个是IP地址，另一个是Cookie。但用户的IP地址可能 会发生改变，而Cookie又可能会被清空，如果IP地址和Cookie同时都发生了变化，那么就无 法再定位到同一个客户端了。
如何让［P地址发生变化呢？使用“代理服务器”是一个常见的做法。在实际的攻击中，大 量使用代理服务器或傀儡机来隐藏攻击者的真实IP地址，己经成为一种成熟的攻击模式。攻击 者使用这些方法可不断地变换IP地址，就可以绕过服务器对单个IP地址请求频率的限制了。
防御措施：
1)应用代码要做好性能优化。合理地使用memcache就是一个很好的优化方案，将数 据库的压力尽可能转移到内存中。此外还需要及时地释放资源，比如及时关闭数据库连接，减 少空连接等消耗。
2)其次，在网络架构上做好优化。善于利用负载均衡分流，避免用户流量集中在单台服务器 上。同时可以充分利用好CDN和镜像站点的分流作用，缓解主站的压力。
3)在Apache的配置文件中，有一些参数可以缓解DDOS攻击。比如调小Timeout、 KeepAliveTimeout值，增加MaxClients值。但需要注意的是，这些参数的调整可能会影响到正 常应用，因此需要视实际情况而定。
4)如果攻击者使用代理服务器、傀儡机进行 攻击，该如何有效地保护站点呢？
Yahoo为我们提供了 一个解决思路。因为发起应用层DDOS攻击的IP地址都是真实的， 所以在实际情况中，攻击荞的IP地址其实也不’能无限制增长。假设攻击者有1000个IP地址 发起攻击，如果请求了 10000次，则f•均每个IP地址清求同I -页面达到10次，攻击如果持续 下去，单个IP地址的请求也将变多，何无论如何变，都是在这100()个IP地址的范围内做轮询。
为此Yahoo实现了 •套算法，根据IP地址和Cookie等信息，可以计算客户端的请求频率 并进行拦截。Yahoo设计的这套系统也是为Web Server开发的一个模块，但在整体架构上会有 一台master服务器集中汁算所有1P地址的请求频率，并同步策略到每台Webserver上。
apache配置中的Timeout和KeepAliveTimeout、MaxClients的解释

**

三、验证码

**
验证码的验证过程，是比对用户提交的明文和服务器端Session里保存的验证码明文 是否一致。所以曾经有验证码系统出现过这样的漏洞：因为验证码消耗掉后SessionID未更新，导致使用原有的SessionID可以一直重复提交同一个验证码。还有的验证码实现方式，是提前将所有的验证码图片生成好，以哈希过的字符串作为验证 码图片的文件名。在使用验证码时，则直接从图片服务器返回已经生成好的验证码，这种设计 原本的想法是为了提高性能。但这种一一对应的验证码文件名会存在一个缺陷：攻击者可以事先采用枚举的方式，遍历所 有的验证码图片，并建立验证码到明文之间的一一对应关系，从而形成一张“彩虹表”，这也会 导致验证码形同虚设。修补的方式是验证码的文件名需要随机化，满足“不可预测性”原则。
验证码的核心思想是识别人与机器，那么顺着这个思路，在人机识别方面，我们是否还能 再做一些事情呢？答案是肯定的。
在一般情况下，服务器端应用可以通过判断HTTP头中的User-Agent字段来识别客户端。 但从安全性来看这种方法并不可靠，因为HTTP头中的User-Agent是可以被客户端篡改的，所 以不能信任。一种比较可靠的方法是让客户端解析一段JavaScript,并给出正确的运行结果。因为大部 分的自动化脚本都是直接构造HTTP包完成的，并非在一个浏览器环境中发起的请求。因此一 段需要计算的JavaScript,可以判断出客户端到底是不是浏览器。类似的，发送一个flash让客 户端解析，也可以起到同样的作用。但需要注意的是，这种方法并不是万能的，有的自动化脚 本是内嵌在浏览器中的“内挂”，就无法检测出来了。
**

三、分布式拒绝服务攻击

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

GET / HTTP/l.l\r\n Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50313; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) \r\n 
Content-Length: 42\r\n
Content-Length: 42\r\n\r\n //在正常的HTTP包头中，是以两个CLRF表示HTTP Headers部分结束的。

由于Web Server只收到了一个\r\n,因此将认为HTTP Headers部分没有结束，并保持此连 接不释放，继续等待完整的请求。此时客户端再发送任意HTTP头，保持住连接即可。
X-a: b\r\n
2.HTTP POST D.O.S.
原理是在发送HTTP POST包时，指定一个非常大的Content-Length值，然后以很低的 速度发包，比如lO-lOOs发-个字节，保持住这个连接不断开。这样当客户端连接数多了以 后，占用住了 Webserver的所有可用连接，从而导致DOS。这种攻击的本质也是针对Apache的MaxClients限制的。
3.Server Limit DOS
Web Server对HTTP包头都有长度限制，以Apache举例，默认是8192字节。也就是说， Apache所能接受的最大HTTP包头大小为8192字节(这里指的是Request Header,如果是 Request 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攻击，恶意地往客户端写入了一个超长的Cookie,则该客户端在清空Cookie之前，将无法再访问该Cookie所在域的任何页面。这是因为Cookie也是放在HTTP 包头里发送的，而Web Server默认会认为这是一个超长的非正常请求，从而导致“客户端”的 拒绝服务。
要解决此问题，需要调整Apache配置参数LimitRequestFieldSize这个参数设置为0时， 对HTTP包头的大小没有限制。关于LimitRequest的一些参数请详细参见：LimitRequest