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.
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
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
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.
Người dùng duyệt diễn đàn này: Không có thành viên nào đang trực tuyến và 0 khách
