实战经验：电商平台遭遇CC攻击，我们是如何应对的？( 二 ) 本文转至二马读书几年前

慢速攻击--CC攻击的变异品种慢速攻击的基本原理如下：对任何一个开放了HTTP访问的HTTP服务器，先建立了一个连接，指定一个比较大的Content-length ，然后以非常低的速度发表，比如1-10s发一个字节，然后维持住这个连接不断开。如果客户端持续建立这样的连接，那么服务器上可用的连接将一点一点被占满，从而导致拒绝服务。
HTTP协议在接收到request之前是不对请求内容作校验的，所以即使你的Web应用没有可用的form表单，这个攻击一样有效。
在客户端建立较大数量的无用连接，并保持持续发包的代价非常的低廉。实际试验中一台普通PC可以建立的连接在3000个以上。这对一台普通的Web服务器，将是致命的打击。更不用说结合肉鸡群做分布式攻击了。
正因为其简单易用，成本低廉，效果明显的特性，慢速攻击成为众多攻击者的研究和利用对象。
发展到今天，慢速攻击也演变成了多种，典型的主要包括如下几类：
Slow headers：Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部，因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点，发起一个HTTP请求，一直不停的发送HTTP头部，消耗服务器的连接和内存资源。攻击客户端与服务器建立TCP连接后，每10秒才向服务器发送一个HTTP头部，而Web服务器在没接收到2个连续的\r\n时，会认为客户端没有发送完头部，而持续的等待客户端发送数据。
下面是使用 slowhttptest 工具发起的 slow header 攻击：
文章插图
Slowhttptest 所发送的请求
文章插图
服务端连接数变化
文章插图
Slow body：攻击者发送一个HTTP POST请求，该请求的Content-Length头部值很大，使得Web服务器或代理认为客户端要发送很大的数据。服务器会保持连接准备接收数据，但攻击客户端每次只发送很少量的数据，使该连接一直保持存活，消耗服务器的连接和内存资源。攻击客户端与服务器建立TCP连接后，发送了完整的HTTP头部， POST方法带有较大的Content-Length ，然后每10s发送一次随机的参数。服务器因为没有接收到相应Content-Length的body ，而持续的等待客户端发送数据。
Slow read：客户端与服务器建立连接并发送HTTP请求，客户端发送完整的请求给服务器端，然后一直保持这个连接，以很低的速度读取Response ，比如很长一段时间客户端不读取任何数据，通过发送Zero Window到服务器，让服务器误以为客户端很忙，直到连接快超时前才读取一个字节，以消耗服务器的连接和内存资源。
注：TCP通过滑动窗口（Window）的概念来进行流量控制。设想在发送端发送数据的速度很快而接收端接收速度却很慢的情况下，为了保证数据不丢失，显然需要进行流量控制，协调好通信双方的工作节奏。所谓滑动窗口，可以理解成接收端所能提供的缓冲区大小。顾名思义， Zero Window ，零窗口，即当发送方的发送速度大于接收方的处理速度，接收方的缓冲塞满后，就会告诉发送方当前窗口size=0 ，发送方此时会立即停止发送数据。
慢速攻击主要利用的是thread-based（基于线程）架构的服务器的特性，这种服务器会为每个新连接打开一个线程，它会等待接收完整的HTTP头部才会释放连接。比如Apache会有一个超时时间来等待这种不完全连接（默认是300s），但是一旦接收到客户端发来的数据，这个超时时间会被重置。正是因为这样，攻击者可以很容易保持住一个连接，因为攻击者只需要在即将超时之前发送一个字符，便可以延长超时时间。而客户端只需要很少的资源，便可以打开多个连接，进而占用服务器很多的资源。
Apache、httpd都采用thread-based架构，很容易遭到慢速攻击。而另外一种event-based（基于事件）架构的服务器，比如 nginx 和 lighttpd 却不容易遭受慢速攻击。
如何防御慢速攻击？
如果请求超过配置的超时时间或者传输速率低于最小速率，那么它就有可能是一个慢速攻击。可以配置合理的从客户端接收HTTP头部和HTTP body的超时时间和最小速率，来避免连接长时间等待。
周期地统计报文数量。一个TCP连接， HTTP请求的报文中，报文过多或者报文过少都是有问题的，如果一个周期内报文数量非常少，那么它就可能是慢速攻击，可以封禁对应IP；如果一个周期内报文数量非常多，那么它就可能是一个CC攻击。