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.
 

TimeOut 2
or
TimeOut 5

breaks this tool.

The default is 8.19 minutes and by default it's not in the config file. With the default setting the tool does in fact break Apache 2.2. With 2 second timeout, there's no noticeable lag with the tool running against the server. With 5 second timeout the lag becomes noticeable. On a busy server you will see some lag.

This timeout setting doesn't affect how long the client waits for an ack. It also doesn't affect file uploads.

-Neil 

Sao không có bác nào khác hứng thú vụ này vậy hen.
Ngoài giải pháp dựng 1 con proxy đằng trước thì các bác nào có ý kiến khác không. Hệ thống phòng thủ HVA sẽ phản ứng như thế nào. 

em trích lại một comment của tác giả Neil trên LinuxSecurity:

Neil wrote:

TimeOut 2
or
TimeOut 5

breaks this tool.

The default is 8.19 minutes and by default it's not in the config file. With the default setting the tool does in fact break Apache 2.2. With 2 second timeout, there's no noticeable lag with the tool running against the server. With 5 second timeout the lag becomes noticeable. On a busy server you will see some lag.

This timeout setting doesn't affect how long the client waits for an ack. It also doesn't affect file uploads.

-Neil 

Tool này chỉ là demo nên có lẽ "mức độ nguy hại" không cao, em dùng từ có lẽ vì em chưa test.
Chi tiết về Timeout directive ở http://httpd.apache.org/docs/2.2/mod/core.html#TimeOut 

Việc dùng các giải pháp như : Hạ timeout, Limit connection như bạn Hoàng đề cập ở trên thì cũng không khả thi, các cú SYN attack cứ tấn công vào 1 server mặc dù có optimize cho apache, điều chỉnh trong iptables nhưng server vẫn cứ hứng đòn.... từ từ .
 

Còn về cách phòng thủ của HVA, em nghĩ cái "tốc độ ánh sáng" của HVA đã chống được 50% ??  

Nếu muốn đạt đủ "impact" thì tầng số nện phải gấp rút hơn mà làm vậy thì bị firewall của HVA tóm ngay. Nếu nện gấp, nện dai, nện dài thì nó (firewall) cho vô blacklist mà đã vô blacklist rồi thì nện cũng y như nện vào /dev/null thôi. Chỉ sau một khoảng thời gian ngưng không nện nữa thì mới được bỏ ra ngoài blacklist. Nói trước, dùng IP của mình mà nện HVA thì khỏi vô HVA luôn ráng chịu á . 

Em có vài thắc mắc:
Tại sao thằng IIS 6, 7 lại miễn nhiễm ??
Tại sao anh Hoàng nói hạ time-out là ko khả thi ??
... và tại sao thằng phát minh ra chiêu này nó ko dùng POST ??
Cái cách hạ time-out có khả thi với POST request ko??
Còn về cách phòng thủ của HVA, em nghĩ cái "tốc độ ánh sáng" của HVA đã chống được 50% ?? 

@tranvanminh: ủa, cu thần bài thử.... nện rồi hả?  

Em thấy kết quả phía trên của anh thì bị cản lọc rồi, nhưng chưa rõ trong trường hợp cụ thể của anh thì dùng cách nào.
Nếu firewall HVA chặn IP, sẽ có thể xảy ra tình rạng nếu các users dùng chung IP thì cũng sẽ bị "dính đạn" theo, ví dụ như VNPT dùng cùng 1 proxy. Như vậy anh giải quyết bài toán này thế nào? 

Current stats:  Slowloris has now sent 6539 packets successfully.
This thread now sleeping for 100 seconds...

                Building sockets.
                Building sockets.
                Building sockets.
                Building sockets.
                Building sockets.
                Building sockets.
                Sending data.
Current stats:  Slowloris has now sent 6625 packets successfully.
This thread now sleeping for 100 seconds...

                Building sockets.
                Sending data.
Current stats:  Slowloris has now sent 6675 packets successfully.
This thread now sleeping for 100 seconds...

                Sending data.
Current stats:  Slowloris has now sent 6724 packets successfully.
This thread now sleeping for 100 seconds...

                Building sockets.
                Sending data.
Current stats:  Slowloris has now sent 6790 packets successfully.
This thread now sleeping for 100 seconds...

sudo yum install nginx 

proxy_set_header X-Forwarded-For $remote_addr;


worker_processes 2
client_header_timeout 5;
ignore_invalid_headers on;
limit_zone gulag $binary_remote_addr 1m;


server {
listen 80;
server_name hvaonline.net;
location / { proxy_pass http://hvaonline.net:8000; }
}

 

listen 8000 

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy-combined 

iptables -A INPUT -p tcp -s xxx.xxx.xxx.xxx --dport 8000 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
 

You can practice good web server security by doing the following:

1. Limit the amount of connections and how fast those connections can be made from any ip address to your web server by use of your firewall. This can be done with PF (we have a "how to") or Iptables.
2. Time out clients who take too long to perform any action.
3. Drop clients immediately who send invalid data.
4. Limit the amount or memory, cpu time and system resources the webserver can use. This is so the webserver can not take down the machine if the site is attacked.

The following Nginx directives will timeout clients who take too long to communicate their intentions to the server. The ignore_invalid_headers directive will drop any client trying to send invalid headers to the server. The explanations of each one is listed above on this page.

* client_header_timeout 5;
* client_body_timeout 10;
* keepalive_timeout 5;
* ignore_invalid_headers on;
* send_timeout 10; 

PS: lighthttpd chịu không thấu slowloris.
 

conmale wrote:

PS: lighthttpd chịu không thấu slowloris.
 

Ý anh ở đây là sao ạ (chịu không thấu ở đây là sức chịu đựng khi so sánh với apache và nginx có phải không anh), anh có thể phân tích rõ hơn nguyên nhân tại sao không anh  

Mình hết sức thắc mắc 2 điểm là :

1. Sao đến giờ này, chưa thấy có report / chưa "cảm thấy" được một.. "làn sóng" căng thẳng nào về việc khai thác lỗ hổng này vì với tính chất nghiêm trọng và khả năng dễ khai thác như vậy thì đây quả là một điều hết sức..không bình thường. Phải chẳng là trước khi bão thì biển rất lặng?!
 

2. Đã khá lâu rồi mà bạn Apache chưa thể hiện bất kể một ý định gì ? 

Abe wrote:

Mình hết sức thắc mắc 2 điểm là :

1. Sao đến giờ này, chưa thấy có report / chưa "cảm thấy" được một.. "làn sóng" căng thẳng nào về việc khai thác lỗ hổng này vì với tính chất nghiêm trọng và khả năng dễ khai thác như vậy thì đây quả là một điều hết sức..không bình thường. Phải chẳng là trước khi bão thì biển rất lặng?!
 

Chưa đâu. Còn mới mẻ quá mà. Thật ra cái perl script (slowloris) đã được công bố và đã có vài phiên bản khác nhau (viết bằng python và php) đã được ra đời. Tuy nhiên để tích hợp nó vào botnets thì không đơn giản mà nếu chơi "solo" thì không mấy hiệu quả vì IP có thể bị ban ngay. Riêng cái slowloris nguyên thủy nếu để chạy được thì khối ông kiddies cũng phải vò đầu, rứt tai bởi vì cần phải có một mớ perl modules (cộng thêm một mớ dependencies nữa).

Hiện nay sans đã chính thức công bố có vài vụ DDoS sử dụng slowloris để tấn công Iran (từ sau vụ bầu cử ở Iran). Ngoài ra chưa thấy thêm thông tin gì về các cuộc tấn công khác dùng slowloris. Riêng trên HVA thì từ ngày 19 tháng 6 2009 đến nay cũng có kha khá các vụ "thử nghiệm" nhưng chỉ xảy ra rời rạc và ngắn ngủi. Tuy vậy, tương lai vài tháng tới thì chưa biết sao.
 

Abe wrote:

2. Đã khá lâu rồi mà bạn Apache chưa thể hiện bất kể một ý định gì ? 

Theo một số thảo luận của đám developers thì apache chưa có quyết định chính thức nhưng hiện đã có nhiều đề xuất khác nhau để fix tình trạng này. Hiện tượng trông có vẻ đơn giản nhưng lại khá phức tạp vì nó đụng đến nền tảng architecture của httpd apache. Đã có một patch (unofficial) cho apache 2.2.11 (và chỉ cho prefork mpm mà thôi) nhưng tôi thấy biện pháp xử lý mà patch này muốn thực hiện có vẻ không được triệt để.

Nếu tôi đoán không sai thì apache sẽ áp dụng biện pháp "granular timeout". Hãy đón xem chuyện gì sẽ xảy ra trong vòng vài tuần tới.