Thay đổi quy tắc tường lửa không có tác dụng: thứ tự quy tắc và trạng thái kết nối

Bạn đã sửa quy tắc, tải lại bộ quy tắc, và đường hầm vẫn hành xử y như trước. Kết quả đó có hai nguyên nhân phổ biến, và chúng cần những phép thử khác nhau. Hoặc quy tắc mới nằm sau một quy tắc trước đó đã chấp nhận gói tin, hoặc trao đổi bạn đang quan sát là một kết nối được theo dõi mà thay đổi không bao giờ đánh giá lại. Một quy tắc trong tệp thể hiện ý định; thứ quyết định gói tin là đường đi đang hoạt động mà nó gặp. Hãy làm lần lượt các kiểm tra bên dưới, và trong lúc đó giữ mở một đường quay lại.

Thứ tự quy tắc và trạng thái kết nối là hai lỗi khác nhau

Các chuỗi có thứ tự được đánh giá từ trên xuống dưới, và quy tắc đầu tiên đạt tới phán quyết cuối cùng sẽ kết thúc việc duyệt qua chuỗi đó. Đặt một cho phép rộng phía trên một quy tắc khóa được viết cẩn thận, và quy tắc khóa trở thành tài liệu: nó có trong bộ quy tắc, bộ đếm của nó bằng không, và không gói tin nào sẽ chạm tới nó. Cùng văn bản đó áp dụng cho một chuỗi khác cũng chẳng chứng minh được gì. Trong nftables, các chuỗi cơ sở gắn vào hook theo mức ưu tiên, nên một cho phép trong một chuỗi không ngăn một chuỗi khác trên hook hay mức ưu tiên khác nhìn thấy cùng gói tin đó.

Theo dõi kết nối tạo ra triệu chứng thứ hai, và từ bên ngoài nó trông giống hệt. Khi một luồng đã nằm trong bảng trạng thái, một cho phép cho established-or-related gần đầu chuỗi sẽ trả về trước khi quy tắc mới của bạn được xét đến. Ánh xạ NAT cũng có tính chất đó: bản dịch đã được cố định khi luồng bắt đầu, nên một quy tắc postrouting đã sửa không viết lại một phiên đang chạy. Đó là lý do một thay đổi trông như có tác dụng lúc 09:00 với kết nối mới và trông như không làm gì với phiên mà ai đó mở lúc 08:55.

Các nhóm bảo mật trên đám mây thêm mô hình thứ ba bắt được những người học bằng iptables. Quy tắc vào của chúng là danh sách cho phép được đánh giá như một tập hợp chứ không phải duyệt theo lần khớp đầu tiên, chúng có trạng thái, và việc xóa một quy tắc cho phép không kết thúc những luồng đã được theo dõi. Giả định ngữ nghĩa khớp đầu tiên trên một nền tảng không có nó dẫn tới những kết luận tự tin nhưng sai.

Đọc bộ quy tắc đang hoạt động, không phải tệp bạn đã sửa

Bắt đầu từ thứ mà nhân đang thực thi ngay lúc này. Một cấu hình đã lưu chưa bao giờ được áp dụng giải thích được một số lượng đáng ngạc nhiên các hành vi không đổi, và loại trừ nó chỉ tốn một lệnh:

nft list ruleset
iptables-save

Sau đó hỏi xem quy tắc của bạn có được chạm tới hay không. Bộ đếm gói tin trả lời trực tiếp điều đó, và trả lời tốt hơn mọi lập luận về ý định:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Một quy tắc khóa có bộ đếm gói bằng không sau một lần thử thật không phải vấn đề chính sách, mà là vấn đề vị trí. Di chuyển nó là thay đổi một dòng, và cú pháp chính là thứ đã gây ra lỗi ban đầu. Với iptables, -I chèn và -A thêm vào cuối; với nftables, insert đặt quy tắc ở đầu chuỗi trong khi add thêm vào cuối. Khi một quy tắc buộc phải thắng, hãy nói rõ điều đó thay vì tin vào thứ tự tình cờ được nạp.

Chứng minh xem luồng có được theo dõi hay không

Trước khi đổ lỗi cho quy tắc, hãy kiểm tra xem lưu lượng có phải là một kết nối được theo dõi hay không. Hỏi bảng trạng thái về luồng cụ thể thay vì trút toàn bộ nó ra:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Danh sách cho thấy trạng thái và thời gian còn lại, và đó là cách bạn phân biệt một phiên đã thiết lập với một lần thử mới; chế độ sự kiện in các cập nhật ngay khi chúng xảy ra, hữu ích khi bạn kết nối lại một máy khách. Nếu luồng đã hiện diện ở trạng thái đã thiết lập trước khi bạn chạm vào bất cứ thứ gì, không bản sửa quy tắc lọc nào sẽ đổi được số phận của nó. Đó không phải lỗi trong tường lửa, đó là hợp đồng của việc lọc có trạng thái.

Hãy chống lại lối tắt xả sạch toàn bộ bảng trên một cổng vào sản xuất. conntrack -F có sẵn, và nó cũng phá hủy mọi luồng đang được theo dõi trên máy, kể cả phiên quản trị mà bạn đang làm việc từ đó và đường hầm chở shell của bạn. Có thể xóa từng mục khi bạn thật sự cần, nhưng một luồng mới từ cổng nguồn mới thường là thí nghiệm sạch hơn.

Một số đường đi không được theo dõi, và chúng hành xử ngược lại. Lưu lượng được đánh dấu notrack trong bảng raw, một số đường hầm bỏ qua các hook thông thường, và định tuyến bất đối xứng chia một luồng giữa hai cổng vào đều tạo ra những gói tin được đánh giá lần lượt, hoặc trạng thái không bao giờ được tạo ở cả hai đầu. Nếu bộ đếm nhúc nhích với từng gói, hãy nghi loại đường đi đó trước khi nghi thứ tự.

Thử từ một luồng mới với một đường quay lại

Trước khi thử một quy tắc có thể cắt truy cập từ xa, hãy lập một đường khôi phục: bảng điều khiển của nhà cung cấp, một console nối tiếp, một địa chỉ quản trị ngoài băng, hoặc một giao diện thứ hai mà quy tắc không thể khớp. Một hẹn giờ hoàn tác là bạn đồng hành hợp lý, vì nó sẽ khôi phục bộ quy tắc trước đó ngay cả khi phiên của bạn chết giữa phép thử.

Sau đó thử bằng một trao đổi mà trạng thái chưa thể bao phủ. Ngắt và kết nối lại máy khách để tạo một bộ năm mới, và quan sát cả hai đầu trong khi điều đó diễn ra:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Chạy phép thử theo cả hai chiều. Một quy tắc chặn cú bắt tay vào mới vẫn có thể cho phép đường phản hồi, hoặc ngược lại, và kết quả một chiều là lý do thường gặp khiến một khóa chỉ hoạt động một nửa. Kết nối lại một lần sau phép thử để xác nhận trạng thái ổn định, và kiểm tra xem truy cập quản trị hợp lệ có sống sót không; một quy tắc viết cho một cổng có thói quen khớp với một dải rộng hơn dự định.

Ghi lại mục đích và vị trí cùng với quy tắc

Một quy tắc không có mục đích được ghi lại là quy tắc không ai dám gỡ. Bên cạnh mỗi mục khóa, hãy giữ luồng mà nó bảo vệ, chuỗi và hook nơi nó sống, vị trí mà nó phải giữ so với những cho phép rộng hơn, và phép thử đã chứng minh điều đó. Khi ai đó sửa bộ quy tắc xung quanh sáu tháng sau, ghi chú đó là lời cảnh báo duy nhất rằng vị trí là có chủ đích.

Trước khi khép lại thay đổi, hãy xác nhận bốn điều: bộ quy tắc đang chạy khớp với tệp, quy tắc mới có bộ đếm khác không sau một lần thử mới, chiều ngược và truy cập quản trị vẫn hoạt động, và bạn đã kết nối lại một lần để chứng minh trạng thái ổn định chứ không phải trạng thái của một phiên cũ hơn thay đổi. Nếu bất kỳ điều nào chưa được xác minh, thay đổi chưa xong, bất kể đường hầm đang làm gì.