Đây là kĩ thuật tương tự như SYN flood (tạo nửa kết nối để làm cạn kiệt tài nguyên máy chủ) nhưng diễn ra ở lớp HTTP (lớp ứng dụng). Để tấn công, tin tặc gửi yêu cầu HTTP đến máy chủ, nhưng không gửi toàn bộ yêu cầu, mà chỉ gửi một phần (và bổ sung nhỏ giọt, để khỏi bị ngắt kết nối). Với hàng trăm kết nối như vậy, tin tặc chỉ tốn rất ít tài nguyên, nhưng đủ để làm treo máy chủ, không thể tiếp nhận các kết nối từ người dùng hợp lệ.Ưu điểm khác của Slowloris là trong suốt quá trình tấn công, do kết nối chưa hoàn chỉnh, sẽ không có thông tin gì trong log. Chỉ đến khi ngưng kết nối, sẽ có hàng loạt lỗi 404 trong log do truy vấn sai.Không phải mọi máy chủ đều bị ảnh hưởng bởi kiểu tấn công này. Các máy chủ như Microsoft IIS hoặc nginx không “hề hấn” gì trước Slowloris. Nếu dùng nginx làm proxy nghịch, tuy nhiên Apache chạy phía sau vẫn nghe trên IP công cộng (vì còn chạy một website thử nghiệm khác, không qua proxy) nên đã bị tấn công.Có nhiều cách để khắc phục kiểu tấn công này, mỗi cách đều có ưu điểm riêng:- Không dùng Apache nữa! Nếu dùng Apache sau proxy nghịch, thì chỉ cho nghe trên cổng 127.0.0.1 hoặc các IP cục bộ.
- Giảm Timeout cho Apache. Tuy nhiên cách này không mấy hiệu quả, tin tặc chỉ phải gửi thêm nhiều gói tin mà thôi.
- Giới hạn số kết nối đến Apache cho mỗi IP. Có thể dùng mod_qos chẳng hạn để làm việc này.
- Giải quyết ở lớp dưới: cấu hình firewall để giới hạn số kết nối đến cổng 80 trên mỗi IP.
Yesterday an interesting HTTP DoS tool has been released. The tool performs a Denial of Service attack on Apache (and some other, see below) servers by exhausting available connections. While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.In this case, the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:GET / HTTP/1.1\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.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n
After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:X-a: b\r\n
Which obviously doesn’t mean anything to the server so it keeps waiting for the rest of the header to arrive. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.According to the web site where the tool was posted, Apache 1.x and 2.x are affected as well as Squid, so the potential impact of this tool could be quite high considering that it doesn’t need to send a lot of traffic to exhaust available connections on a server (meaning, even a user on a slower line could possibly attack a fast server). Good news for Microsoft users is that IIS 6.0 or 7.0 are not affected.At the moment I’m not sure what can be done in Apache’s configuration to prevent this attack – increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.We’ll keep an eye on this, of course, and will post future diaries or update this one depending on what’s happening. It will be interesting to see how/if other web servers as well as load balancers are resistant to this attack. Code:
RequestReadTimeout header=5-10,MinRate=500
