Điều gì có thể khiến cờ đặt lại TCP/IP (RST) KHÔNG được gửi?

Question

Tôi có hai máy chủ Linux (hãy đặt tên cho chúng là A và B), được kết nối với cùng một công tắc (không được quản lý). Tôi đã tắt tường lửa trên cả hai máy chủ (không có quy tắc nào trong tất cả các bảng và tất cả các chính sách mặc định được đặt thành CHẤP NHẬN). Vì vậy, không có gì nên ngăn chặn một máy chủ để gửi bất kỳ gói TCP/IP và máy chủ khác để nhận chúng như là.

Bây giờ, trên A, chúng tôi chạy ứng dụng máy chủ TCP, ứng dụng này nghe/chấp nhận các kết nối đến và sau đó gửi nhiều dữ liệu trong vòng lặp tới (các) khách hàng được kết nối. Nó không cố gắng đọc từ máy khách, và mong đợi nhận được lỗi EPIPE khi thực hiện write() để socket nếu/khi máy khách ngắt kết nối.

Tiếp theo, trên B tôi chạy nc (netcat) làm ứng dụng khách, kết nối với ứng dụng máy chủ trên A, bắt đầu nhận dữ liệu và vài giây sau, tôi nhấn Ctrl-C để ngắt kết nối này.

Những gì tôi thấy, là ứng dụng máy chủ trên A chỉ bị treo trong write(), nó không bị lỗi EPIPE hoặc bất kỳ lỗi nào khác.

Tôi đã truy TCP/IP gói tin sử dụng tcpdump, và đây là những gì tôi thấy:

• sau khi gián đoạn netcat trên B, B gửi FIN đến A, mà trả lời một cách chính xác với ACK để FIN rằng - vì vậy , bây giờ chúng tôi đã kết nối TCP half-open công bằng, đó là ok
• tiếp theo, A cố gắng để gửi dữ liệu tiếp theo cho khách hàng với ACK thông thường và PSH, gói ACK, cũng được mong đợi và đúng
• NHƯNG, B doesn không trả lời bằng bất kỳ cách nào cho các gói này (trong khi tôi mong đợi nó trả lời bằng gói RST vì nó nhận các gói đến kết nối TCP đã đóng/không tồn tại)
• A không nhận được ACK, vì vậy nó ngừng gửi dữ liệu mới và bắt đầu gửi lại gói cũ (và vào thời điểm này cuộc gọi tiếp theo để viết() treo)

Tôi cũng đã cố gắng để chạy netcat trên A (vì vậy cả ứng dụng khách và máy chủ chạy trên cùng một máy chủ vật lý), và theo cách này mọi thứ hoạt động như mong đợi - ứng dụng máy chủ nhận được EPIPE ngay lập tức sau khi tôi ngắt kết nối netcat bằng Ctrl-C. Và tcpdump hiển thị có gói RST được gửi như mong đợi.

Vì vậy, điều gì có thể gây ra việc không gửi RST trong trường hợp này?

Tôi đang sử dụng Hardened Gentoo Linux, cập nhật, kernel 2.6.39-hardened-r8, không có bất kỳ cấu hình liên quan đến mạng sysctl cụ thể nào. Có thể hoặc có thể không quan trọng cần lưu ý rằng có hoạt động mạng đáng kể trên các máy chủ này, khoảng 5000 tcp kết nối được liệt kê bởi netstat -alnp tại bất kỳ thời điểm nào và tôi nghĩ khoảng 1000 kết nối sẽ mở và đóng mỗi giây trung bình. Đó là bình thường để nhìn thấy trong một cái gì đó log hạt nhân như thế này (nhưng số cổng khác được sử dụng bởi ứng dụng máy chủ thảo luận ở trên):

TCP: Possible SYN flooding on port XXXXX. Sending cookies. 
    net_ratelimit: 19 callbacks suppressed 

Sau đây là cách phiên TCP thường trông giống như: http://i54.tinypic.com/1zz10mx.jpg

Answer 1

Hành vi này là kết quả của kích hoạt tính năng trong kernel cứng của tôi:

Security options ---> 
    Grsecurity ---> 
     Network Protections ---> 
     [*] TCP/UDP blackhole and LAST_ACK DoS prevention 

CONFIG_GRKERNSEC_BLACKHOLE:

Nếu bạn nói Y ở đây, không phải res TCP ets hoặc ICMP đích-unreachable gói sẽ được gửi để đáp ứng với các gói được gửi đến cổng mà không có quá trình nghe liên quan tồn tại.Tính năng này hỗ trợ cả IPV4 và IPV6 và loại bỏ giao diện loopback khỏi blackholing. Kích hoạt tính năng này làm cho một máy chủ linh hoạt hơn đối với các cuộc tấn công DoS và giảm khả năng hiển thị mạng đối với các máy quét. Tính năng lỗ đen được triển khai tương đương với tính năng lỗ đen FreeBSD, vì nó ngăn các phản hồi RST cho tất cả các gói, không chỉ SYN.