dongdu.info

Đã gửi: **Năm T2 03, 2005 3:43 am**

Mấy chú Đông Du thôi không xách mé matrix nhé.Fair play chứ,mình giỏi cái này nhưng cái kia có người khác giỏi hơn mình.Khi nói chuyện về chuyên môn thì nên nghiêm túc 1 tí, không nên chê bai nhau.Matrix post bài có thể dưới cơ mấy chú ,nhưng mấy thằng như anh đây lại thấy hay .
Matrix cũng đừng tự ái để bụng nhé, có gì nhậu với nhau 1 phát,vui vẻ cả làng.

Đã gửi: **Năm T2 03, 2005 3:55 am**

EM rất nể những người như anh Tâm nagoya,thực ra em cũng không phải cao thủ gì và có thể là kém cỏi so với các anh Đông Du nhưng em cũng tự hào rằng em vận dụng được toàn bộ những gì mình biết và giới thiệu lại cho mọi người tham khảo,còn về việc các anh Đông Du chê em em cũng ko có í kiến gì,các anh là chủ nên có thể nói rất dễ nhưng em nghĩ các anh đang gây sức ép với em đúng hơn là bàn luận về những gì em post!Đây là 1 bài học bổ ích khi mà ko phải thành vieen đông du nào cũng định nghía được dos,ddos là gì,anh quá ca nhân khi nghĩ ngay tới việc em ddos đong du đấy,cả anh concord nữa(chưa biết tài năng anh ra sao) mà khinh người quá đấy
Nick yahoo của em là chandoi.enet các anh có thể vào pm với em,một ngày em thường online 10h,các anh có thể gặp em thường xuyên nếu add nick đố>Em cám ơn anh Tâm nagoya đã lên tiếng bảo vệ em và em cũng nói em mới 17 tuổi và cái tôi của em đang ko được ổn định,ăn nói có gì sai các anh bỏ qua!

Đã gửi: **Năm T2 03, 2005 4:10 am**

Den phan tranh luan
Em thấy cách phòng chống tấn công của anh Chung chưa phải hay,em nghĩ cách hay nhất là làm lụt các gói SYN phải ko nào

Đã gửi: **Năm T2 03, 2005 11:04 am**

Ái chà không ngờ bài viết của mình đã gây nhiều phản ứng như vậy.
To matrix2k-org: Em đã có lời xin lỗi về lần này, coi như em đã là bạn của DD, không có lý do gì anh khiêu khích em tấn công, hay chọc tức em đâu. Và server Đông Du cũng không phải là của riêng, vật thí nghiệm của anh.
Thật ra lần này anh viết reply đó rất là thiện chí với em. Công khai phần thiết định của TCP/IP trên kernel của Đông Du (chính xác hơn là để phòng chống em trong lần vừa qua), để cùng với em tham khảo. Có lẽ từ ngữ anh dùng không chuẩn nên đã gây ra sự cảm nhận vừa rồi của em, anh rút kinh nghiệm vậy.

Tóm lại điều anh đã muốn nói là: Muốn là cracker, gây được sự uy hiếp cho server người khác không phải là điều đơn giản đâu. Và học vi tính để phục vụ vào việc này rất là vô lý.

Trở lại phần bàn luận với em:

Anh đã nói rất rõ trình tự là nếu em chỉ tấn công tràn syn đơn thuần thì không làm gì được server DD đâu, hay những server có thiết định đó. . Bởi vì:
#sysctl -w net.ipv4.tcp_syncookies=1
Thiết định này làm tê liệt lối tấn công tràn syn dựa trên lợi dụng phương thức 3 way handshake. Bằng cách server không lưu lại thông tin của syn packet vào hệ thống bộ nhớ, sử dụng hash function để tái tao ra một synack khác để trả lời cho client, nếu client không trả lại ack packet thì coi như connect đó chấm dứt. Vì server không lưu lại bộ nhớ cho packet đó, nên không có trạng thái sử dụng resource để tái phóng synack cho đến khi timeout.
#sysctl -w net.ipv4.conf.all.rp_filter=1
Cái này xem xét IP nguồn của packet, nếu IP nguồn là không tồn tại (cái này chỉ đối ứng với IPv4), thì bản thân packet đó bị reject.
#sysctl -w net.ipv4.conf.all.accept_source_route=0
Cái này chống lại kiểu thiết định đường dẫn route giả mạo của đối phương thường dùng cho router.
...

Tuy nhiên, như anh đã nói

Theo mình nghĩ nguy hiểm nhất là DDos, tuy nhiên nó chỉ phát huy được tác dụng khi các nguồn phóng thật sự tồn tại và có quá nhiều, chứ không phải kiểu packet giả tạo đâu. Các site lớn bị loại này tấn công cũng vì vậy.

Anh không hề xem thường DDos, nếu em có khả năng vận động được 50IP thật, cùng lúc để tấn công dồn dập vào port 80, quét toàn bộ trang web, thì thật là không đơn giản. Thú thật nếu điều đó xảy ra thì anh chỉ biết cách, xem tất cả các đường connect của em và reject toàn bộ những IP nguồn kết nối vào port 80, hay đơn giản hơn là reject toàn bộ tất cả packet được phát ra từ những IP nguồn đó. Tất nhiên anh phải có mặt đúng lúc em tấn công vậy.
Hay một cách khác đối với một nguồn phóng, trong 1 giây chỉ cho phép connect tối đa bao nhiêu request...
Không biết có giải pháp nào khác không nhỉ?

Đã gửi: **Năm T2 03, 2005 12:45 pm**

Thực ra cách tìm và reject íp nguồn là giải pháp tạm thời khi hết cách. Nó chỉ tránh cho server khỏi bị sụm chứ ko phải là giải pháp lâu dài để chống dos.Nếu phải nói đến những biện pháp hữu hiệu nào chống Ddos thì bản thân nghĩ là việc thiết lập những rules,signitures trên firewall là quan trọng nhất.những rules,signatures này sẽ giới hạn packets và sockets connect đến server...Ngoài ra chính Apache cũng có chức năng chống ddos nếu khi install cài thêm mod-security...
Theo như tớ biết thì hiện nay ngoài ddos ra thì còn có một dạng dos khác cũng cực kì nguy hiểm là drdos!Nếu ddos đòi hỏi phải exploit được victims để biến nó thành mạng zombies (clients) thì drdos không đòi hỏi phải tốn thời gian như thế ,sử dụng drdos attackers sẽ dùng chính ip của victims kích hoạt những server khác truy cập dồn dập đến server victims .Ở đây chỉ nêu nguyên lí hoạt động không đi sâu vào được ...
Hiện nay trong giới hacker có một kiểu chơi biến thái của drdos là thay vì kích hoạt các server khác ,anh ta sẽ tạo ra một image được thiết kế bằng flash chứa đoạn code dos.Sau đó chàng sẽ upload cái image vào những forum có đông người truy cập ra vào ...Mỗi lần user truy cập vào image này sẽ bị kích họat và sẽ tự động dos vào server victims...Xem như một kiểu mượn tay giết người vây...hehhe!
Nói tóm lại ddos là một dạng chơi nguy hiểm nhưng không lành mạnh cho lắm .Ví như một tên đạo chích dùng kĩ thuật mở khoá nhà người ta không xong rồi tức quá quay ra đốt nhà người ta!極端な話ですけど。。。Thế nên ai muốn chơi tìm hiểu trò này thì cứ bước vào chơi tìm hiểu ...

Đã gửi: **Năm T2 03, 2005 5:57 pm**

Theo em thi giai phap tot nhat chong ddos la tao cac table ao?nhu the se danh lua dc muc tieu cua ddos con` voi cach phong thu cua anh Chugn em co the su dung chinh ip dong du de ddos dong du,nhu vay ko biet se the nao,anh Chung cho i kien di nao,cangngaycang thay thu vi voi DOng Duroi day,ko kheo vai hom nua lai ru cac anh di uong ruoc day

Đã gửi: **Năm T2 03, 2005 6:30 pm**

Theo em thi giai phap tot nhat chong ddos la tao cac table ao?nhu the se danh lua dc muc tieu cua ddos

??? Rõ thêm đi chứ em trai.

con` voi cach phong thu cua anh Chugn em co the su dung chinh ip dong du de ddos dong du,nhu vay ko biet se the nao,anh Chung cho i kien di nao,cangngaycang thay thu vi voi DOng Duroi day,ko kheo vai hom nua lai ru cac anh di uong ruoc day

Cái này chắc là bất khả, một packet từ ngoài vào có IP source, destination là một và cùng bằng với IP của chính mình.
#sysctl -w net.ipv4.conf.all.rp_filter=1
Thiết định này sẽ reject được.

rp_filter - BOOLEAN
1 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.

0 - No source validation.

conf/all/rp_filter must also be set to TRUE to do source validation
on the interface

(Document đóng gói cùng kernel 2.4)

Đã gửi: **Năm T2 03, 2005 6:40 pm**

Anh đã nói rất rõ trình tự là nếu em chỉ tấn công tràn syn đơn thuần thì không làm gì được server DD đâu, hay những server có thiết định đó. . Bởi vì:
#sysctl -w net.ipv4.tcp_syncookies=1
Thiết định này làm tê liệt lối tấn công tràn syn dựa trên lợi dụng phương thức 3 way handshake. Bằng cách server không lưu lại thông tin của syn packet vào hệ thống bộ nhớ, sử dụng hash function để tái tao ra một synack khác để trả lời cho client, nếu client không trả lại ack packet thì coi như connect đó chấm dứt. Vì server không lưu lại bộ nhớ cho packet đó, nên không có trạng thái sử dụng resource để tái phóng synack cho đến khi timeout.

Về chuyện này muốn hỏi Chung thêm một chút. Server phải thiết định timeout để chấm dứt connect trong trường hợp attacker không trả lại ack packet. Như vậy thì server không rơi vào trạng thái chờ và tái phóng synack. Tuy nhiên nếu như attacker thiết lập một khoảng thời gian t của server để gửi đến một syn packet khác thì server vẫn bị giữ trong trạng thái busy ??

Đã gửi: **Năm T2 03, 2005 7:56 pm**

Trả lời anh Việt:

Về chuyện này muốn hỏi Chung thêm một chút. Server phải thiết định timeout để chấm dứt connect trong trường hợp attacker không trả lại ack packet. Như vậy thì server không rơi vào trạng thái chờ và tái phóng synack. Tuy nhiên nếu như attacker thiết lập một khoảng thời gian t

Khi mà giá trị net.ipv4.tcp_syncookies=0 thì mọi việc sẽ xảy ra theo kiểu 3wayhandshake.
Trị Timeout này được thiết lập để bỏ một connect packet nếu quá thời gian, và có giá trị trên chính cái packet đó. Chứ không phải là có giá trị cho một connect của cả server. Cho nên ở đây đối phương phóng hàng loạt các packet chứ không phải như anh Việt nói đâu.
Vấn đề ở chỗ là:
Chính vì là TCP nên mới có chuyện là server sau khi nhận một syn packet, thì trả lại (syn+ack) packet, và đợi ack packet cuối cùng từ client, sau đó mới trả lại trạng thái ESTABLISHED để chuẩn bị truyền dữ liệu (3way handshake). Giả sử như mà không thấy ack cuối cùng của client thì bản thân server phán đoán là syn+ack packet của mình bị đứt đoạn và gởi định kỳ lại syn+ack packet cho đến khi nào timeout thì huỷ bỏ. Để làm được điều này server phải sử dụng bộ nhớ và phải xử lý động tác này nên tiêu tốn resource.
Attacker lợi dụng chỗ là truyền liên tục syn packet(mà không có ack packet), buộc server phải thụ lý hàng loạt liên tục số lượng lớn syn và xử lý, đối phương càng đông thì số lượng packet này lại càng nhiều, cuối cùng dẫn đến cạn kiệt resource ( chính xác là do 2 lý do, một là hết khả năng xử lý, hai là số lượng max syn mà server xử lý là một con số có hạn(tcp_max_syn_backlog), quá cái này sẽ bị busy. )

Còn khi thiết định
#sysctl -w net.ipv4.tcp_syncookies=1
tại sao lại khống chế được lối tấn công này, là vì:
Để hiểu phần này phải hiểu được cụ thể nguyên lý của 3way handshake ở mức độ packet, và các header của nó. (Về phần này dài nên em lượt bỏ, nếu anh có 興味 thì hẹn buổi khác vậy).
Đại khái là packet để hiểu nhau phải bằng cách sử dụng 2 số trị REQ và ACK, Thì đối với một packet phản hồi phải có ACK = REQ(packet gởi đến) + 1.
Quy tắc lần này là phát triển thêm của 3wayhandshake, khi mà server nhận syn của client thì bản thân server sẽ trả lại syn+ack packet trong đó số trị REQ của mình được sinh ra từ hash function (nói đơn giản là sản sinh ra một con số mà đối phương nếu không nhận nghiêm chỉnh thì khó mà phán đoán được), sau đó server chỉ lưu cái con số vừa sử dụng đó và quên đi cái syn packet vừa rồi. Tức là ở đây sẽ không có cái chuyện thụ lý những syn packet đó để đợi ack của client nữa.
Khi đó khi một ack bất kỳ nào đó đến thì bản thân server sẽ đem so với những con số đang nhớ nếu khớp thì OK, chuyển sang state ESTABLISHED bắt đầu cho phóng data. Và bản thân những con số này cũng sẽ bị huỷ nếu timeout. Những con số này được xem như là một dạng cookies của syn packet nên cái options này mới có tên là net.ipv4.tcp_syncookies. Động tác cực kỳ nhẹ nhàng, tê liệt được lối tấn công này. Nhưng bản thân nó có yếu điểm sẽ làm giảm tính tin cậy của truyền phóng TCP, nhưng nó buộc phải sản sinh ra để chống lại SYN FLOODING.

dongdu.info

Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ

Re:Giới thiệu về tấn công từ chối dịch vụ