Quy tắc UFW mới, kết nối cũ: trạng thái established thắng thế

Thêm một quy tắc từ chối và thấy một bản tải xuống đang mở vẫn tiếp tục không phải là lỗi của UFW. Quy tắc bạn thêm nằm sau những quy tắc đã chấp nhận luồng đó, và một kết nối được thiết lập trước đó vẫn khớp với chúng. Khắc phục điều này nghĩa là chèn đúng vị trí và hiểu những gì các quy tắc trước hứa hẹn. Phiên bản hẹp của thay đổi đó như sau.

Thứ tự quyết định, không phải sự tồn tại của quy tắc

UFW là một giao diện ghi các quy tắc netfilter theo từng giai đoạn: phần khung chạy trước các quy tắc người dùng, rồi đến chính các quy tắc người dùng, rồi đến phần chạy sau chúng. Các quy tắc trước mặc định chấp nhận lưu lượng của các kết nối established và related, và các quy tắc đó được đánh giá trước mọi thứ bạn thêm bằng allow hoặc deny thông thường. Tài liệu lệnh UFW ghi lại cú pháp chèn và chế độ xem trạng thái có đánh số mà thay đổi này phụ thuộc vào.

Thứ tự đó giải thích sự bất ngờ. Quy tắc mới của bạn là thật và nằm trong bảng đúng, nhưng nó không phải quyết định đầu tiên mà gói tin gặp. Một kết nối đã được theo dõi là established không bao giờ đến được nó.

Dùng quy tắc route cho việc này, vì gói tin được chuyển tiếp qua cổng chứ không hướng tới các dịch vụ của chính cổng. Một quy tắc đầu vào sẽ lọc sai lưu lượng và trông như không làm gì cả.

Chèn phía trên quyền cho phép rộng

Xem trước việc chèn trước khi áp dụng và xác nhận quy tắc chưa tồn tại ở nơi khác trong danh sách. Nhân bản một chính sách giống hệt khiến việc gỡ bỏ sau này mơ hồ, và người xóa nhầm bản sao sẽ không nhận ra trong nhiều tuần.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Nếu bản xem trước hiển thị đúng một quy tắc ở vị trí bạn mong đợi, hãy áp dụng cùng lệnh đó mà không có cờ dry-run. Vị trí 1 đặt nó phía trên các quyền người dùng rộng hơn, không phải phía trên các quy tắc khung đã bàn trước đó. Xác nhận tên giao diện khớp với thiết bị đường hầm trên cổng này, vì một quy tắc gắn với giao diện không còn tồn tại sẽ nằm trong danh sách trông có vẻ đúng mà không khớp với gì. Đổi tên tham chiếu thiết bị trước khi áp dụng, không phải sau khi kiểm tra thất bại.

Không có cổng đích trong quy tắc đó, nên nó từ chối mọi cổng TCP trên địa chỉ ấy chứ không chỉ HTTPS. Nếu ý định là một dịch vụ duy nhất, hãy nêu tên cổng; một quy tắc rộng hơn chính sách là một sự cố tương lai đang chờ người đọc đầu tiên.

Chỉ giới hạn nguồn ở một địa chỉ nếu địa chỉ đó gắn với danh tính dự định. Một nhóm VPN cấp phát động có thể trao cùng địa chỉ cho khách khác vào ngày mai, và lệnh từ chối sẽ đi theo địa chỉ chứ không theo người.

Luồng established sống sót qua quy tắc mới

Theo dõi kết nối là lý do phiên hiện tại tiếp tục. Khi một luồng được ghi nhận là established, các quy tắc trước chấp nhận gói của nó trước khi lệnh từ chối của bạn được xem xét, và quá trình truyền kết thúc như thể không có gì thay đổi. Vì vậy, thử nghiệm bằng trình duyệt dùng lại kết nối đang mở không cho bạn biết gì về chính sách mới. Một lệnh từ chối có thể trông vô dụng vài phút sau khi triển khai và hoàn toàn hiệu quả với người dùng tiếp theo kết nối.

Nếu yêu cầu bao gồm việc cắt lưu lượng đang chạy, thay đổi quy tắc người dùng này không thể đáp ứng. Thu hồi trạng thái được theo dõi là một hành động riêng với bán kính ảnh hưởng của nó, và thuộc về chủ sở hữu tường lửa chứ không phải người thêm quy tắc. Xóa mọi kết nối trên một cổng để một phiên biến mất là kiểu sửa chữa tạo ra sự cố thứ hai.

Cũng hãy nhớ các ranh giới. Quy tắc này không nói gì về ICMP, UDP hay IPv6, nên một ping thành công không phải bằng chứng rằng lệnh từ chối đã thất bại. Một địa chỉ IPv4 cũng không phải trang web: một tên có thể phân giải thành nhiều địa chỉ, và chỉ địa chỉ bạn nêu tên là được bao phủ.

Thử với một luồng mới

Đọc các quy tắc người dùng có đánh số và chế độ xem thô hiệu lực, rồi mở một kết nối mới từ máy khách đã chọn:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Chế độ xem thô quan trọng vì status bỏ qua các quy tắc khung viết tay, nên thứ tự có thể trông khác với những gì nhân hệ điều hành thực thi. So sánh cả hai trước khi kết luận rằng một quy tắc nằm sai chỗ.

Sau đó kiểm tra hai phép đối chứng chứng minh quy tắc là hẹp chứ không rộng: một đích được phép từ cùng máy khách vẫn hoạt động, và máy khách thứ hai vẫn đến được đích bị từ chối nếu chính sách của nó cho phép. Một lệnh từ chối phá cả hai phép thử là thay đổi chính sách, không phải biện pháp có mục tiêu.

Khi thử xong, chỉ gỡ quy tắc bạn đã thêm, bằng cách lặp lại chính xác nó. Nếu chính sách là vĩnh viễn, hãy bàn giao cho chủ sở hữu tường lửa kèm danh tính máy khách, chủ sở hữu đích và ngày xem xét, để một địa chỉ đường hầm được cấp lại không để lại lệnh từ chối cũ.