Làm thế nào một tường lửa sẽ giết kết nối TCP mà không có RST hoặc FIN? [đóng cửa]

Tình hình là như thế này:

http client ----> corporate firewall ----> http server

Do giữ nguyên, máy chủ và máy khách sẽ giữ kết nối TCP mở và máy khách sẽ sử dụng nhóm kết nối cho các yêu cầu HTTP.

Tường lửa có quy tắc "tiêu diệt" các kết nối TCP lâu đời sau 1 giờ. Vấn đề là máy khách HTTP của chúng tôi sẽ không phát hiện ra rằng kết nối TCP đã bị phá hủy và nó đã cố gắng sử dụng lại các kết nối cơ bản đã chết mà về phía chúng tôi trông giống như máy khách "bị treo" sau một khoảng thời gian. Một yêu cầu sẽ bị treo, sau đó yêu cầu tiếp theo sẽ hoạt động, có lẽ là do một kết nối mới được thiết lập.

Câu hỏi ở đây là cơ chế mà tường lửa đang giết các kết nối TCP theo cách mà máy khách HTTP của chúng tôi không thể phát hiện ra chúng là gì. Tôi đã cố gắng tái tạo hành vi này cục bộ theo một số cách:

1. Giết các kết nối TCP trên bộ định tuyến vyos của chúng tôi, Wireshark ở phía máy khách đã bắt được TCP FIN-ACK. đồng ý
2. Giết phía máy khách kết nối TCP trong TCPView trên Windows, Wireshark đã phát hiện TCP RST ở phía máy khách. đồng ý
3. Chặn cổng sau khi thiết lập kết nối với tường lửa phía máy khách, dẫn đến ngoại lệ đặt lại ổ cắm. đồng ý

Tôi có một bãi chứa Wireshark ở phía máy chủ và tôi đã cố gắng tìm xem tường lửa có gửi FIN hoặc RST ip.dst==serverip && (tcp.flags.reset==1 || tcp.flags.fin==1)không nhưng không có gì hiển thị.

Ngoài ra, chụp Wireshark ở phía máy khách cho thấy vấn đề khi yêu cầu HTTP xuất hiện, theo sau là hàng tá truyền lại TCP, cuối cùng không đi đến đâu.

Máy khách HTTP là máy khách Java gốc và / hoặc máy khách HTTP (đã thử cả hai), cả hai đều không phát hiện được kết nối TCP đã chết. Tôi muốn tái tạo hành vi cục bộ nhưng tôi không thể hiểu được cách thức mà tường lửa phá hủy các kết nối, do đó tìm kiếm câu trả lời có thể.

Bạn không đề cập đến loại tường lửa, nhưng tôi nghi ngờ nhất là bỏ các gói.

Tôi có một kết xuất Wireshark ở phía máy chủ và tôi đã cố gắng tìm xem tường lửa có gửi FIN hoặc RST với ip.dst == serverip && (tcp.flags.reset == 1 || tcp.flags.fin == 1) nhưng không có gì thể hiện.

Mà sẽ có xu hướng xác nhận điều này.

Nhiều khả năng tường lửa chỉ bỏ gói mà không gửi gói RST, có thể sau khi đạt giá trị thời gian chờ phiên nào đó. Đây thường là hành vi cấu hình.

Cá nhân tôi thích gửi gói RST đó một cách chính xác vì nó giúp khách hàng cư xử bình thường, nhưng tôi đã nghe thấy những tranh luận về hiệu quả của việc này không nên được thực hiện trên tường lửa đối diện bên ngoài để tránh cung cấp bất kỳ phản hồi nào cho những kẻ tấn công tiềm năng.

Tôi đã thấy điều này gây ra khá nhiều vấn đề bởi vì khách hàng thường không xử lý loại kịch bản này rất thanh lịch. Về cơ bản, họ tiếp tục thử lại thông qua phiên TCP ban đầu (hiện đã chết) và không bao giờ thử thiết lập lại một phiên bản mới. Cuối cùng, một kích hoạt thời gian chờ phía máy khách và người dùng nhận được một thông báo lỗi khó chịu. Thiết lập HTTP keepalive một cách thích hợp cho ứng dụng có thể giúp khắc phục điều này.

@Ron Trunk hoàn toàn chính xác, gần như chắc chắn kết nối mở đang bị hủy hoặc chủ động (từ chối quy tắc được chèn) hoặc thụ động (bị xóa khỏi các kết nối đã biết và không được phép tạo lại mà không có đồng bộ hóa). Một trong những ý kiến ​​đề nghị tự thử. Đây là một công thức để làm như vậy bằng cách sử dụng không gian tên mạng linux. Nó giả định rằng chuyển tiếp ip được kích hoạt trong kernel của máy chủ của bạn, bạn là root và có thể là những thứ khác.

# Create network namespacs
ip netns add one; ip netns add two; ip netns add three
# Create interfaces between namespaces
ip link add dev i12 type veth peer name i21
ip link add dev i32 type veth peer name i23
# Bring interfaces up and assign them to respective namespaces
ip link set dev i12 netns one up
ip link set dev i21 netns two up
ip link set dev i32 netns three up
ip link set dev i23 netns two up
# Assign IP addresses
ip netns exec one ip addr add 1.1.1.1/24 dev i12
ip netns exec two ip addr add 1.1.1.2/24 dev i21
ip netns exec three ip addr add 3.3.3.3/24 dev i32
ip netns exec two ip addr add 3.3.3.2/24 dev i23
# Add routes when necessary
ip netns exec one ip route add default via 1.1.1.2
ip netns exec three ip route add default via 3.3.3.2

Sau đó, bạn cần ba cửa sổ / vỏ / màn hình / thiết bị đầu cuối. Chạy từng lệnh dưới đây trong một thiết bị đầu cuối riêng biệt:

• Bắt đầu nghe trên máy chủ: ip netns exec three socat TCP-LISTEN:5001 STDIO
• Bắt đầu truyền trên máy khách: ip netns exec one socat STDIO TCP:3.3.3.3:5001

Lưu ý rằng sau khi chạy các lệnh này, mọi thứ bạn nhập vào một cửa sổ sẽ được phản ánh trong cửa sổ kia và ngược lại (sau khi nhấn return). Nếu điều đó không đúng, bạn có thể cần phải bật chuyển tiếp ip.

• Khởi tạo quy tắc từ chối: ip netns exec two iptables -I FORWARD -j DROP

Sau đó, không có gì bạn gõ sẽ được cho phép thông qua.

Bạn có thể mô phỏng một phương thức thả ít hoạt động hơn với các quy tắc chuyển tiếp (chưa được kiểm tra) như:

ip netns exec two iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip netns exec two iptables -A FORWARD -m tcp -p tcp -dport 5001 --tcp-flags ALL SYN -j ACCEPT
ip netns exec two iptables -A FORWARD -j DROP

Xem /unix/127081/conntrack-tcp-timeout-for-state-st Thiếted-not- Business và https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysct .txt để biết thông tin về cách điều chỉnh thời gian chờ - mặc dù tôi không rõ ràng rằng iptables thực sự hỗ trợ tuổi thọ kết nối tối đa; Tôi tin rằng tất cả thời gian chờ là thời gian chờ nhàn rỗi.

Dọn dẹp với ip netns del one; ip netns del two; ip netns del three

Tường lửa có thể gửi gói ICMP chỉ ra rằng mục tiêu không thể truy cập được. Đối với bất cứ điều gì ngoại trừ TCP, đó là dấu hiệu lỗi duy nhất có thể xảy ra, ví dụ gửi gói đến cổng UDP đã đóng sẽ tạo ra thông báo "không thể truy cập đích" với mã lý do được đặt thành "cổng không thể truy cập".

Cũng có thể gửi tin nhắn "không thể truy cập cổng" dưới dạng phản hồi cho các gói TCP, điều này cũng chấm dứt kết nối, nhưng bất kỳ ai phân tích các gói dữ liệu sẽ nhận thấy rằng điều này là bất thường, vì quy ước TCP là chỉ ra các cổng đóng với RST.

Người gửi dự kiến ​​sẽ ánh xạ bất kỳ gói lỗi ICMP nào nhận được về kết nối ban đầu và xử lý chúng một cách thích hợp, do đó, một gói lỗi tạo tường lửa cũng có thể được sử dụng để chấm dứt kết nối TCP. Gói ICMP chứa một bản sao của các tiêu đề của gói vi phạm để cho phép ánh xạ này.