The tcp_synack_retries setting tells the kernel how many times to retransmit the SYN,ACK reply to an SYN request. In other words, this tells the system how many times to try to establish a passive TCP connection that was started by another host.

This variable takes an integer value, but should under no circumstances be larger than 255 for the same reasons as for the tcp_syn_retries variable. Each retransmission will take aproximately 30-40 seconds. The default value of the tcp_synack_retries variable is 5, and hence the default timeout of passive TCP connections is aproximately 180 seconds. 

Ấn định tcp_synack_retries cho kernel biết sẽ nên thử hồi đáp SYN,ACK bao nhiêu lần đối với một SYN. Nói một cách khác, ấn định này cho hệ thống biết sẽ thử bao nhiêu lần để thiết lập một xuất TCP thụ động được máy đầu bên kia khởi tạo.

Giá trị biến này là một số nguyên nhưng không nên lớn hơn 255 trong bất cứ hoàn cảnh nào. Mỗi lần hồi đáp sẽ mất khoảng 30-40 giây. Giá trị mặc định của tcp_synack_retries là 5 và bởi thế, thời gian mãn hạn theo mặc định của một xuất TCP thụ động là khoảng 180 giây. 

Hi anh
Theo em thì nếu tăng giá trị của tcp_synack_retries thì sẽ giảm thời gian kết nối xuống, và ngược lại . 

Khi một hệ thống bị DDoS (SYN-flooding), nhiều khả năng backlog sẽ bị đầy, và OS không thể nhận thêm connections, và phải đợi cho đến khi lifetime của một số connections kết thúc thì mới tiếp tục nhận SYN. Như vậy, việc tăng số lượng retries sẽ khiến tình hình trở nên tồi tệ hơn, vì OS sẽ không có khả năng nhận thêm connections trong một khoảng lớn thời gian (e.g., 180s).
 

Việc giảm số lượng retries ở một khía cạnh nhỏ có hiệu ứng tốt, vì half-opened connection lifetime sẽ giảm, dẫn đến OS sẽ nhanh chóng loại bỏ half-opened connections và nhận các SYN mới. Tuy nhiên, điều đó cũng có nghĩa là khả năng legitimate peer có thể connect đến cũng giảm mạnh, vì 2 lí do:
- Trong khi bị DDoS, legitimate peers có rất ít cơ hội để nhảy vào được backlog.
- (cũng) trong khi bị DDoS (massively), việc packets loss là đương nhiên (gồm syn, syn/ack, ack), nên retransmission là cần thiết.

Cuối cùng, việc giảm số lượng retries không thực sự cải thiện được tình hình DDoS, vì attacker chỉ cần tăng attack frequency thì mọi việc lại như cũ. 

Có mấy ý kiến phản hồi nhỏ với chuyên gia StarGhost.  

StarGhost wrote:

Khi một hệ thống bị DDoS (SYN-flooding), nhiều khả năng backlog sẽ bị đầy, và OS không thể nhận thêm connections, và phải đợi cho đến khi lifetime của một số connections kết thúc thì mới tiếp tục nhận SYN. Như vậy, việc tăng số lượng retries sẽ khiến tình hình trở nên tồi tệ hơn, vì OS sẽ không có khả năng nhận thêm connections trong một khoảng lớn thời gian (e.g., 180s).
 

Điều này đúng, nhưng cũng là không đúng vì bất kể lifetime dài hay ngắn, OS cũng ko thể tiếp nhận được thêm kết nối khi đó => kết quả đều là toi như nhau và hầu như ko thể tồi tệ hơn. 

- Sai: Khi bị SYN flooding, việc mất packet sẽ vẫn ít khi xảy ra (nghĩa là không có tắc nghẽn), bởi đơn giản là là gói SYN nó rất bé và thường thì khả năng đáp ứng của đg truyền của server là thừa sức. SYN flood là cách tấn công của những client có băng thông nhỏ, với mục tiêu tốn ít để đạt đc kết quả. Nó làm cho server đầy backlog không thể nhận thêm kết nối chứ không phải là nhằm làm cho đường truyền bị nghẽn. Nếu muốn làm đường truyền nghẽn, người ta gửi gói thật to như là ICMP to hay UDP to, chứ không gửi gói TCP SYN bé tí làm gì. 

Cách người ta chống back-log bị đầy: ví dụ Linux nó dùng Syn Cookies http://en.wikipedia.org/wiki/Syn_cookies), Khi back-log bị đầy, linux host vẫn trả lời gói SYN gửi tới bằng 1 gói tin SYN-ACK với cái sequence là 1 giá trị được tính toán đặc biệt gọi là cookie, nó không cần lưu cái haft connection này và không cần back-log buffer đang bị đầy kia. Nếu client xịn, nó sẽ reply cái gói SYN-ACK của server kia bằng 1 gói ACK có chứa cái seq đúng là cái cookie của server kia. Server nhận được gói ACK, check được đúng cookies mà mình gửi, cho dù không tìm được haft connection trong backlog tương ứng với cái ACK này (lúc trước có lưu đâu?), nó vẫn cho tạo kết nối và kết nối được thiết lập với đủ 3 bước, và mặc kệ cái back-log đang bị full.
Tất nhiên lúc này sẽ chậm hơn 1 chút đối với các client xịn mà có đường truyền tệ, vì nếu SYN-ACK trả lời mà bị mất, server sẽ không retries việc gửi này (vì có lưu lại đâu mà biết retry?), client sẽ buộc phải gửi lại SYN mới và sẽ nhận SYN-ACK khác. Tham số retries lúc này cũng vô nghĩa.
Và mọi thứ vẫn chạy được, kệ SYN flooding. 

@StarGhost: mình thấy bạn myquartz đề cập đến cái syncookies vì bạn ấy cho rằng chỉ cần kích hoạt syncookies thì không cần quan tâm đến giá trị của tcp_synack_retries, điều mà mình tin là sai, còn sai như thế nào thì hai bạn thảo luận tiếp đi nha, mình chưa từng bao giờ coi code phần network stack của linux kernel cũng như chưa bị tấn công DDoS nặng nề nên mình không biết . 

@myquartz: hình như bạn không rành lắm về việc linux kernel xử lý cái khoản network thế nào ấy nhỉ? Ở trên mrro đã có nhắc đến vấn đề cookies rồi.

SYN flooding ít hiệu quả không phải là vì đã có một fancy mechanism để chống lại nó (kể cả syn cookies cũng chỉ là cực chẳng đã thôi), mà là vì các tay admin có trình độ thì biết cách tune system để "sống chung với lũ", cộng thêm khả năng của hệ thống. Chính vì vậy, nếu một hệ thống hoặc là có ít tài nguyên, hoặc là được quản lý bởi một tay mơ thì việc SYN flooding thành công là đương nhiên, và không cần thiết phải làm nghẽn đường truyền, vì bản thân SYN flooding cũng khó mà làm được như vậy. Những hệ thống như vậy thì nhan nhản ra.

 

Tạm dịch:

Ấn định tcp_synack_retries cho kernel biết sẽ nên thử hồi đáp SYN,ACK bao nhiêu lần đối với một SYN. Nói một cách khác, ấn định này cho hệ thống biết sẽ thử bao nhiêu lần để thiết lập một xuất TCP thụ động được máy đầu bên kia khởi tạo.

Giá trị biến này là một số nguyên nhưng không nên lớn hơn 255 trong bất cứ hoàn cảnh nào. Mỗi lần hồi đáp sẽ mất khoảng 30-40 giây. Giá trị mặc định của tcp_synack_retries là 5 và bởi thế, thời gian mãn hạn theo mặc định của một xuất TCP thụ động là khoảng 180 giây. 

Xét trong tình trạng "half-open" của một TCP connection và hệ thống có số truy cập rất lớn, thậm chí đang bị DDoS, thử phân tích và đánh giá:

1) Chuyện gì xảy ra nếu giá trị tcp_synack_retries sẽ gia tăng?

1) Chuyện gì xảy ra nếu giá trị tcp_synack_retries sẽ gia giảm?

Mời bà con thảo luận