Tìm hiểu về DDos Attack

[tinman]

hì,

Đối với các Syn/AckDoS, hiện nay hầu hết các Firewallm IDS tiên tiến đều có thể ngăn chặn được hết, tốt nửa là khác.

Xin cho ké 1 đoạn nghe. Phương pháp mà cái firewall hay Packet Processor (của hảng mình) dùng để defend Syn/Ack là như sau.

Khi 1 client gởi Syn packet tới server, đi ngang firewall hay thiết bị này. Thiết bi này sẻ tạo ra 1 record trong database của nó (silicon database - thường là dùng CAM "constant address memory) rồi forward packet đó tới server sau đó thì thiết bị đó chờ cho server trả lời bằng Syn-Ack packet, nó forward packet này tới client, và đồng thời gởi trả lời Server bằng 1 packet Ack tự tạo ra. Lúc đó Server đã hoàn tât giai đoạn 3-way handshake nên sẻ đưa pending connection đó vào establish connection queue và chờ packet mới ở đây (establish connection queue thường rất lớn vì sử dụng thread tuỳ theo mổi server).

Sau khi gởi packet Ack tự tạo tới server, thiết bị này tiếp tục lắng nghe và theo dỏi client trong 1 thời gian nhất định có gởi trở lại Ack packet không. Nếu client gởi trở lại thì 1) là nó drop packet đó, 2) là forward tới server và server cũng sẻ drop packet đó, sau đó nó clear entry này trong silicon database. Client và Server thoải mái nói chuyện với nhau vì đã có 1 entry trong established connection queue.

Nếu sau thời gian quy định thiết bị này vẩn không gởi Ack packet tới thì thiết bị này sẻ gởi packet TCP-Reset tự tạo ra tới server. Server sẻ close connection đó trong established connection queue. Và thiết bị này cũng xoá record đó đi khỏi database. Record đó thường chứa Source + Dest IP address, Source + Dest Port.

Sử dụng phương pháp này thì sẻ loại trừ được tình trạng halfway connection ở trên của server. Nhưng giá thành cho các loại stateful firewall và thiết bị loại này rất là mắc. Ở những server trên những đường truyền chậm, các bạn có thể thực hiện phương pháp bảo vệ trên sử dụng 1 pc thực hiện những bước ở trên. Tuy không hoàn hảo như những stateful firewall, nhưng có thể bảo vệ được server của bạn khỏi bị syn-ack attack.

[C++]

Đệ xin hỏi huynh là có thể dùng một loại SoftWare hay Hardware nào để hạn chế việc Flood nhưng giá rẻ không ? vì cũng như huynh đã biết là ở VN chúng ta còn rất hạn chế về chi phí

Mong mỏi chờ hồi âm

[tinman]

Đệ xin hỏi huynh là có thể dùng một loại SoftWare hay Hardware nào để hạn chế việc Flood nhưng giá rẻ không ? vì cũng như huynh đã biết là ở VN chúng ta còn rất hạn chế về chi phí

Mong mỏi chờ hồi âm

Không biết bạn C++ muốn nói tới việc hạn chế Flood, là hạn chế ở mức độ nào. Nếu bạn có thể nói rỏ hơn yêu cầu của bạn thì mình có thể trả lời 1 cách chính xác hơn. Mình tạm giả định ý kiến của bạn như sau:

+ Chống flood trên 1 đường truyền. Nếu chỉ nói là chống flood trên 1 đường truyền thì khó vô cùng. Flood giống như 1 cơn lủ, tràn vào cửa ngỏ của đường truyền internet nào đó. Muốn hạn chế nó 1 cách hửu hiệu thì chỉ có thể chống flood ở gần nguồn. Chứ 1 khi flood đã tràn vào 1 đường truyền thì đâu còn các nào chống ngoài tắt máy đi ngủ.
Ví dụ bạn có 1 đường truyền DSL chạy khoảng 200Kbit/s. Nhưng ở ngoài lượng traffic attack gởi vào khoảng chừng 300Kbit/s thì khó có thể mà chống lại. Phương pháp duy nhất bạn có thể làm là drop những loại traffic không cần thíêt.

Phương pháp chống flood tốt nhất là chống ở tại các ISP nơi nhận và chuyển traffic vào từng đường truyền. Nếu các router ở đây "thông minh" 1 chút thì có thể dập tắt flood. Các thế hệ router gần đây có khả năng phân tích các loại traffic đi qua mà áp dụng những filter thích hợp (Rate Shapping). Nhưng các thế hệ router này có thể là khá đắt tiền.

Những phương pháp đơn giản hiện nay mình thấy đó là người ta dùng software (Netflow, NetMap...) để tính ra các loại traffic đi qua. Khi có 1 loại tăng bất thường, thì nó có thể update router table của các router để tạm thời block 1 loại traffic nào đó khi loại traffic đó vượt quá mức quy định, hay là có thể đưa traffic đó qua những router khác nơi có những máy phân tích và gạn lọc traffic để loại bỏ những traffic xấu này. Nếu có tiền thì có thể mua những thiết bị như đã nêu ở trên. Nếu kinh tế hạn hẹp thì có thể thực hiện những máy phân tích và gạn lọc traffic này bằng các PC flatform với gigabit ethernet card và dung lượng bộ nhớ cao. Có khả năng đọc và phân tích các packet đi qua bằng software bạn tự viết ra. Theo mình dự tính 1 PC loại này có thể phân tích vào gạn lọc các traffic đi qua ở tốc độ T2 - T3. Trên thị trường hiện tại những thiết bị gan lọc bằng PC based thì chẳng ai làm vì những ISP hiện tại ở US chạy với tốc độ khác cao. Họ muốn router làm hết các chuyện đó cho nên chỉ đưa hết các khả năng chống flood này vào các thế hệ router mơí. Còn ở VN thì mình không biết như thế nào nên không dám góp ý kiến. Nếu bạn nghĩ chỉ cần xử lý ở tốc độ 20Mbit/s... bạn có thể dùng 1 PC + xây dựng 1 software dùng trên nền tảng open source để thử.

[C++]

Huynh nói đúng, hiện những hệ thống Server như NetSpace chẳng hạn, mình thấy họ có 1 người chuyên ngồi trên máy để theo dõi những lưu lượng của Server để khi lưu lượng tăng một cách đột biến thì họ tắt Router và chuyển Post chẳng hạn, hiện mình rất muốn có một phần mềm giống vậy, bạn có thể nói cho mình biết phần mềm nào như vậy không ? hay có phần mềm nào thể hiện số lưu lượng đi vào Server hay không ? rất mong bạn trả lời

Mình muốn hạn chế ở mức này, ch oví dụ nghe:

Khi thấy lưu lượng quá cao mình sẽ lập tức chuyển Port để chống lại nạn flood

chỉ có thể thôi, nhưng mình không biết cách để "xem" được lưu lượng ra vào Server, rất mong đại huynh ra tay giúp đỡ

[tinman]

Ở đây có 1 số software dùng làm các chuyện monitor traffic, một số của cisco, 1 số khác open source. Bạn có thể từ từ ngâm cứu. Trong đó mình thấy Netflow của cisco coi bộ có thể theo dỏi traffic 1 cách hửu hiệu. Các software khác như flowscan viết bằng PERL coi bộ củng OK vì nó có thể theo dõi traffic và bandwidth...

http://www.switch.ch/tf-tant/floma/software.html

http://netflow.cesnet.cz/index.php

http://www.caida.org/tools/taxonomy/

Ý tưởng chính ở đây là dùng các software open source này, để định dạng cho hệ thống network của bạn ví dụ ở 1 thời điểm nào từng loại traffic là bao nhiêu phần trăm. Cao nhất là bao nhiêu và thấp nhất cho phép là bao nhiêu. Sau khi đưa các software monitor này vào, bạn có thể đọc được các dử liệu của những software này trong các database của chúng. Tùy theo từng trường hợp bạn có thể viết các software module tự động thay đổi route table của các router hay chuyển đổi các port, hay apply các loại filter khác nhau.

[7604]

Gần như bất cứ một hệ thống monitor nào cũng có một điểm gọi là break-even. Trong trường hợp này nghĩa đơn giản là cá giá phải trả, nếu siết chặc kiểm soát thì gây khó khăn cho chính mình nhưng thả lỏng thì thì kiểm soát không chặc. Tìm ra một điểm thích hợp để vừa kiểm soát hiệu quả vừa không trở ngại hoạt động bình thường gần như là đều không dễ. Lấy thí dụ như cái soft mà Tinman đề cập đến, đúng là có lợi cho xếp khi kiểm tra hết thư từ ra vào cũng như thái độ làm việc của nhân viện nhưng lại vi phạm luật riêng tư có thể dẫn đến tòa án.

Hiện tại, gần như các monitor system đều hạn chế ở một điểm là khả năng lưu lại thông tin. Security taskforce, Mỹ, vừa thông qua một luật đòi hỏi các monitor system phải lưu lại dữ liệu. Chính vì vậy mà nhiều hãng sử dụng cisco hardware đã dùng IT-Monitor của OSI. Lưu trữ thông tin không chỉ phục vụ cho tòa án, kiện tụng mà còn giúp nguyên cứu và phát triển những kỷ thuật phòng chống từ xa. Cơn lũ trước khi vào bờ thì mặt biển phẳng lặng với những cơn sống ngầm. Tìm ra được qui luật của cơn lũ thì dù không ngăn chặn nổi cũng có thể hạn chế thiệt hại xảy ra. Mấu chốt của hệ thống bảo vệ không chỉ là phải ngăn chặn tất cả mà là giảm thiểu hậu quả trong mọi trường hợp.
=================

[C++]

Phải phải, khi thấy lũ tràn vào thì cũng phải biết cách hạn chế chứ không lẽ chạy toán loạn một cách vô ý thức hay là ngồi chờ chết phải không nào ?, với Flood thì hình như không một Router nào mà không bị "chết" phải không mấy huynh ?

[[oo]]

Thấy mấy u nói về DoS attack, tui cũng xin nói thêm một chút,mấy bồ nói vậy tuy không sai nhưng giải thích vậy chắc các newbie cũng khó hiểu, tuy tôi chưa thực hành bao giờ ,nhưng cũng đọc khá nhiều nên cũng xin lấy một bài của ngưới khác từ HAV về đây, bên đó là cả một câu chuyện về Dos Attack ,còn mấy bồ muốn tìm hiểu kĩ hơn thì mời vô qua HAV mà coi, rất thú vị :

http://www.hvaonline.net/forum/showt...8514_st_0.html

DoS Attack ( có thể gọi là không ăn thì đạp đổ -vì không hack được thì phá tan nó thôi) là một kĩ thuật cao,đòi hỏi phải có nhiều kiến thức ,nhất là kiến thức về lập trình và hệ thống mạng,còn về kĩ thuật thì mấy bồ kia đã nói gần hết rồi, tui chỉ xin post thêm một câu chuyện về Dos của HAV thôi, hy vọng mấy bạn thích :


From Mod comale in HAV:

Dấu hiệu
Mấy tuần lễ gần đây, đột nhiên lượng tải trên máy chủ HVA tăng vọt trong khi số lượng thành viên chính thức truy nhập diễn đàn vẫn ở mức bình thường. DoS? hay DDoS? Lượng tải này tăng vọt khá đều đặn vài giờ trong mỗi ngày. Lượng thành viên gia tăng nên có quá nhiều người cùng truy cập? không phải. HVA đang có đề tài gì hấp dẫn nên thiên hạ ùn ùn kéo vào? cũng không phải.

Dấu vết
Tôi nhận công tác điều tra và xử lý tình trạng bất bình thường này, trong đầu đã phần nào đoán sự thể do DoS. Khuya ngày 10 tháng 10, tôi log vào server của HVA và tạo ra vài console, mở ra vài cái đuôi -1-, làm một ấm trà và ngồi đó nhâm nhi... một mình. Không cần phải đợi lâu, hàng loạt thông tin từ log của web server hiện lên màn hình với một số chi tiết rất lý thú:

CODE

210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)"
203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)"
203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)"
80.170.198.46 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1617 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)"
81.66.147.0 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1"

Chà, chẳng lẽ thành viên "hối hả" kéo vào diễn đàn và "POST" bài nhiều đến vậy sao? hai mươi lăm cái "POST" trong một giây từ một vài IP? Cứ cho là hợp lệ vì thành viên ở VN đi ra Internet, qua cùng một cửa ngõ -2- là chuyện bình thường. Nhưng, hẵng đã, vừa rồi lại có một chùm đến hơn năm mươi cái "POST" đi đến trong một giây, cũng từ các IP như trên. Bất thường hay bất tường?

Tôi để yên mấy "cái đuôi" chạy trên mấy console và mở trình duyệt của mình lên, thử log vào HVA bằng nickname và password của tôi để xem thử "thái độ" POST từ máy của tôi có tương tự như những cái POST tôi nhận được vài chục giây trước đây (xác thực là bạn của nghề phân tích). Cha chả, cái POST của tôi nhìn hợp lệ hơn nhiều:

CODE

***.xx.***.98 - - [10/Oct/2004:07:11:25 +0900] "POST /forum/act_Login_CODE_01.html HTTP/1.0" 200 7405 "http://www.hvaonline.net/forum/act_Login_CODE_00.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510"




Tôi thử mở "cái đuôi" của firewall log trên server xem có gì hấp dẫn không. Chà, log của web server vẫn "POST" vào ầm ầm nhưng firewall log thì vẫn im ắng như đỉnh Himalaya. Thôi rồi, chắc đây là một "kiểu chơi" rất hợp lệ nên firewall cho phép chúng vào thả cửa. Tôi gởi nhanh một PM đến JAL, nhờ lão phóng cái sniffer lên để "hít" -3- một ít gói tin và lưu lại một nơi thích hợp dùm tôi. Đêm đã khuya, tôi phải đi ngủ để mai còn đi làm. Sáng mai sẽ copy mớ gói tin đã được lưu và sẽ phân tích xem sự thể ra sao.

Phân tích

Ngày 11/10
Trên tàu lửa đến sở làm, tôi hăm hở mở laptop ra và bắt tay vào xem xét thông tin "bắt" được tối hôm qua. Chuyện đầu tiên đập vào mắt tôi là kích thước hồ sơ đã sniff, chà, sao nó bé tí tẹo vậy nhỉ? Sáng nay lúc tôi log vào HVA server để copy hồ sơ này, tôi đã không để ý đến kích thước (vì cứ nghĩ nó phải ít nhất là vài megabytes), tôi chỉ chạy lệnh scp và bỏ đó rồi đi thay đồ đi làm. Lúc này mới nhận ra là nó bé tí tẹo, không biết có gì trong này.

Tôi dùng Ethereal mở hồ sơ này ra, và.... đúng như dự phỏng, Ethereal phàn nàn "stream not completed". Tôi bật cười và tự nhủ: "chà, chắc lão JAL sợ nó sniff lâu quá thành một hồ sơ khổng tượng nên chỉ sniff một, hai giây rồi tắt liền". Thông tin "bắt" được từ sniffer quá ít, chỉ vỏn vẹn hơn mười dòng, trong đó có được một cái SYN -4-, một cái ACK,PSH từ một segment khác, một cái HTTP (POST) cộng thêm vài cái "continuation" từ các segment trước và sau cái SYN ở trên không thấy gì đi theo.

Xếp laptop lại, tôi trầm ngâm vài phút, có vài chi tiết cần xem lại trong mớ packets ngắn ngủi mà lão JAL đã cung cấp. Tôi lại mở laptop ra và đi xuyên qua mười mấy mảnh packets rời rạc. Không thể "gom" các packets này thành một stream hoàn chỉnh, tôi đành xem xét từng mảnh một lần nữa. Điểm lý thú đập ngay vào mắt tôi khi dò đến http packet chứa mảng đầu của phần "POST". Cha chả, POST cái gì mà lắm thế?

- payload -5- của "POST" có đến 2205 bytes?
- đoạn đầu của mảnh "POST" này có thông tin:

. Lý thú nhỉ, lý thú nhưng cũng chưa có gì rõ ràng cho lắm. Tôi hơi ngạc nhiên là tại sao mấy lão trên HVA lại để yên những http header và payload có dính ngổn ngang các "chú" ampersand -6-. Có lẽ mấy lão cho phép vì đây là phần cần thiết cho forum? Tôi chưa nắm được bao nhiêu các phần tố ngổn ngang giữa "Invision Board" và web server đứng trước, cái này phải điều tra kỹ mới được.

Thiếu các mảnh tiếp theo của đoạn POST trên, tôi đành thở dài và dừng lại vì chẳng đi tới đâu. Thôi vậy, đành phải sniff lại vì mớ thông tin này chẳng giúp được bao nhiêu



Tối 11/10
Tôi gởi PM cho lão JAL để "hít" thêm ít gói tin, lần này tôi nắm chắc phải có vài megabytes packets để ngịch. Không lâu sau đó, tôi nhận được hồi đáp từ JAL thông báo các mảnh packets đã có sẵn trên server. Tôi log vào HVA server và tải chúng xuống. Hăm hở mở đoạn "hit" thứ nhất, tôi rà xuyên qua trọn bộ các gói tin bắt được trong nhóm thứ nhất để tìm một dấu hiệu nổi bật và những dấu hiệu nào có liên quan đến đoạn payload của HTTP POST ở trên. Quá nhiều! có quá nhiều "stream" -7- từ nhiều nguồn khác nhau như mang cùng một đặc tính. Thử xem một "stream" do client IP là 203.210.233.28, dùng proxy server là 203.162.3.148 để "POST" vào server của HVA:

CODE

POST /forum/ HTTP/1.1
Accept: */*
x-flash-version: 7,0,19,0
Content-Type: application/x-www-form-urlencoded
Content-Length: 2387
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Cookie: session_id=433ab8bcc276414badb0e83891bbb9a6
Host: www.quangvinhonline.info
X-Forwarded-For: 203.210.233.28
Connection: Keep-Alive
Cache-Control: no-cache, bypass-client=203.210.233.28


Uh oh! Cái gì đây? Thử decode xem nó chứa gì, mấy cái %2, %3 xem chỉ tổ... mù mắt:

CODE

POST /forum/ HTTP/1.1
Accept: */*
x-flash-version: 7,0,19,0
Content-Type: application/x-www-form-urlencoded
Content-Length: 2387
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Cookie: session_id=433ab8bcc276414badb0e83891bbb9a6
Host: www.quangvinhonline.info
X-Forwarded-For: 203.210.233.28
Connection: Keep-Alive
Cache-Control: no-cache, bypass-client=203.210.233.28




Cái gì nổi bật trong hai đoạn trên? Đúng rồi: x-flash. Tại sao lại có chuyện dùng flash để "duyệt" HVA forum? Ngoài x-flash còn có những gì nổi bật? Có quá nhiều điểm nổi bật trong payload ở trên. Tuy nhiên, ứng dụng ra sao là yếu tố quyết định phải chọn những gì và ở đâu trong payload.

Hãy thử "dựng" lại các gói tin thuộc một "stream" tương tự để xét xem chúng có gì đặc biệt về mặt chuyển gởi và chuyển nhận gọi tin:


Tôi log vào HVA server lần nữa và "grep" -11- xuyên qua vài cái log cũ của web server chạy trên HVA. Ái chà, "bệnh" x-flash này đã xảy ra cũng đã nhiều ngày nhưng HVA không "chết" nổi, chỉ chậm lại ở những lúc cao điểm, chứng tỏ chiến thuật x-flash này không mấy hữu hiệu? Hay vì "chủ nhân" của mớ x-flash này chỉ cài chúng đâu đó rồi.... "sống chết mặc bây"? Tôi tiếp tục đào sâu trong mớ log đã cũ của HVA để hình thành vài con số thống kê. Sau hơn một giờ "chọc ngoáy" các log files và ghi chú thành một trang notepad chi chít chi tiết, tôi hình thành được khá nhiều thông tin hết sức lý thú, Những thông tin này khá phức tạp và tế nhị nên không thể công bố rộng rãi cho độc giả. Tôi đành phải tạm tóm lược như sau:
- căn bệnh x-flash này đã xảy ra nhiều tháng.
- trung bình mỗi ngày có khoảng +- 15,000 requests dùng x-flash vào HVA forum.
- các request này thường tập trung từ khoảng 6 giờ chiều cho đến khuya giờ VN.
- cao điểm các request này "đụng" vào HVA là khoảng 9 giờ tối.

Có thể rút tỉa được điều gì thuộc phương diện kỹ thuật từ những thông tin trên nhỉ?
- đám "x-flash" này có thể được xếp loại vào dạng DDoS vì chúng đến từ nhiều nguồn (IP) khác nhau cùng một lúc.
- chúng có cùng đặc tính (nói về mặt giao thức, kích thước và thái độ).
- có một số "stream" đi vào có cùng tính chất như các x-flash phá hoại này nhưng không hề mang "x-flash" trong header của HTTP POST, có lẽ chúng được một proxy server nào đó "lột" mất cái header?
- chúng hoàn toàn hợp lệ về mặt giao thức cho nên cấu hình server của HVA tiếp nhận chúng với "vòng tay rộng mở".
- và dường như chúng được gởi đến từ các máy con trong thời điểm duyệt Internet cao độ trong ngày.

Với những nhận định trên, tôi tin rằng các "con" x-flash kia không được chủ nhân điều tác theo kiểu master / zombies thông thường mà đây có thể là cách cài các "x-flash" trên những diễn đàn tương tự như HVA. Khi người dùng duyệt đúng trang web nào đó có gắn những "x-flash" này, chúng được dùng làm phương tiện để gởi request đến HVA server. Số lượng người truy cập các diễn đàn ấy càng nhiều thì số lượng request gởi đến HVA càng cao. Vậy, HVA phải đối phó ra sao?
- cản? cản ai? cản những gì? nếu phải cản thì chỉ có thể cản một mớ IP của các gateway hoặc các proxy server đi từ VN (là chủ yếu) và nếu vậy thì chuyện gì xảy ra? Đúng vậy! "x-flash" đã "deny service" thành công vì nó buộc HVA phải cản luôn những "kẻ vô can" trong cuộc chơi quái dị này.
- không cản? thì "căn bệnh" này cứ đeo đuổi mãi sao? và nếu cứ để như vậy thì chuyện gì xảy ra? tất nhiên là HVA server không thể "chết" nổi nhưng ảnh hưởng đến các thành viên (và khách) truy cập đến diễn đàn HVA là ảnh hưởng tiêu cực (chậm, đứt quãng, phí tài nguyên, phí băng thông...).

Có khá đầy đủ các dữ kiện cần thiết, tôi bắt đầu hình thành chiến thuật "trị" nhưng "trị" thế nào thì xin độc giả đón xem phần kế tiếp

<còn tiếp>

[dinhbaochau]

Các bạn ơi! Đang đọc chuyển qua trang thì thự nhiên bị cái lỗi này. Là gì vậy???

There seems to have been a slight problem with the database.
Please try again by pressing the refresh button in your browser.

An E-Mail has been dispatched to our Technical Staff, who you can also contact if the problem persists.

We apologise for any inconvenience.

[yuna_admirer]

to Swan

HVA đang đổi forum software.

Quote bài của conmale sao không quote của Yunie's death kiss

Bài của conmale không có nói detail về algorithm

ps : bác conma có qua đây đừng trách em nhé hehehe