Conntrack NEW trên gói ACK: điều nó không chứng minh

Trong nhật ký tường lửa có một dòng bạn không ngờ tới: một gói ACK, trạng thái conntrack là NEW, địa chỉ nguồn không phải của bạn, cổng đích đang mở. Cám dỗ là đọc nó như một kết nối vào mới mà không ai cho phép. Điều dòng đó thực sự nói thì hẹp hơn: khi gói đó đến hook này, bộ theo dõi không có trạng thái khớp, và gói mang theo ACK. Đó là hai sự thật về hai thứ khác nhau, và không cái nào là bản ghi đầy đủ của một lần bắt tay. Đây là trình tự tôi đi qua trước khi kết luận.

Bắt đầu từ gói, không phải từ phán quyết

Tách các quan sát ra trước khi diễn giải. Cờ TCP mô tả gói này, trạng thái của bộ theo dõi mô tả những gì nó biết tại hook đó, và bản bắt gói của bạn chỉ mô tả cửa sổ bạn đã ghi.

Gộp ba thứ đó lại chính là cách một ACK biến thành “nhà cung cấp đã cho ai đó vào”.

NEW thực sự có nghĩa gì tại hook

việc khớp conntrack của iptables ghi nhận NEW là gói khởi đầu một kết nối, hoặc gói gắn với một kết nối chưa thấy lưu lượng theo cả hai chiều. ESTABLISHED nghĩa là bộ theo dõi đã thấy gói theo cả hai chiều. Không định nghĩa nào nói rằng gói đó là SYN, cũng không nói rằng nó đến mà không có lịch sử.

Bộ theo dõi bắt đầu quan sát một luồng từ giữa sẽ phân loại gói tiếp theo theo những gì nó biết, và có thể là không gì cả. Đó là phát biểu về bộ nhớ của bộ theo dõi, không phải về ý định của máy chủ từ xa.

Theo dõi lỏng giải thích phần lớn các bất ngờ với ACK

Nhân hệ điều hành ghi nhận nf_conntrack_tcp_loose, cho phép bộ theo dõi bắt các kết nối TCP mà nó không thấy khởi đầu. Với cấu hình ở giá trị mặc định, một ACK từ giữa luồng có thể được nhận như luồng đã thiết lập. Tắt nó đi thì cùng gói đó nhiều khả năng bị phân loại là INVALID thay vì NEW. Cả hai kết quả đều mô tả quy tắc của bộ theo dõi, không phải lịch sử của ứng dụng.

Vì vậy hãy kiểm tra cấu hình đó trước khi dựng lý thuyết trên nhãn.

Loại trừ các nguyên nhân nhàm chán theo thứ tự này

Phần lớn các sự kiện NEW-trên-ACK tôi từng theo đuổi đều kết thúc ở một trong những nguyên nhân này, và tất cả đều rẻ để kiểm tra:

• Bảng conntrack đã bị xóa, hoặc bộ theo dõi đã khởi động lại.
• Máy chủ đã khởi động lại, hoặc luồng đã chuyển sang namespace hay thiết bị khác.
• Định tuyến không đối xứng đã đẩy SYN ra theo một đường bạn không bắt.
• NAT đã viết lại tuple, nên mục không còn khớp với điều bạn đọc.
• Việc bắt gói bắt đầu muộn và không bao giờ thấy phần đầu.

Mỗi nguyên nhân trong số đó loại bỏ các gói trước đó khỏi tầm nhìn của bộ theo dõi và để nguyên các gói sau. Khởi động lại hoặc xóa bảng là thứ dễ xác nhận nhất từ uptime và nhật ký. Định tuyến không đối xứng hiện ra như một lần bắt gói một chiều. NAT là kẻ xảo quyệt, vì tuple mà bộ theo dõi lưu không phải tuple in trong nhật ký.

Ghi lại bạn đã loại trừ những cái nào, và bằng cách nào, trước khi đi tiếp.

Đọc tuple, giao diện và hook

Một mục conntrack được khóa theo địa chỉ, cổng và giao thức, nên mọi bản dịch đều thay đổi mục nào khớp. Ghi lại cả giao diện và hook, vì một gói thấy trên giao diện sai hoặc sau một chuỗi khác cho bạn biết đường đi không như trong sơ đồ. Khi sự kiện liên quan đến VPN, quyết định xem bạn đang nhìn gói bên trong hay vật mang bên ngoài. Sau đó so sánh với những gì cổng vào đã ghi cho cùng tuple năm phần.

Hai góc nhìn về một luồng mà không khớp nhau cho nhiều thông tin hơn là mỗi góc nhìn riêng lẻ.

Khi nào đáng để leo thang

Hãy leo thang khi bạn có thể cho thấy một dịch vụ đang truy cập được và lẽ ra không nên như vậy, kèm theo luồng, chính sách đã cho phép nó và bằng chứng từ cả hai đầu. Đừng báo lỗi của nhà cung cấp chỉ dựa trên một nhãn trạng thái hay một lần bắt gói một phần, vì báo cáo đó sẽ bị đóng lại bằng chính lời giải thích bạn vừa đọc. Nếu dịch vụ thực sự bị phơi bày, chủ sở hữu ranh giới đó là người đúng để sửa nó, và một ánh xạ cổng được ủy thác hay một trình lắng nghe không chủ ý là nguyên nhân khả dĩ hơn một lỗi phần mềm.

Sau đó bịt lại khoảng trống quan sát đã khiến một gói trông như cả một phiên.