Không có tun0? Khớp IPsec đã giải mã trong nftables bằng meta ipsec

Bạn mong đợi một giao diện đường hầm, tìm nó, và không có gì để khớp trong tường lửa. Điều này là bình thường với cổng dựa trên chính sách: trao đổi được mã hóa đến trên giao diện vật lý, và gói bên trong đã giải mã được chuyển tiếp sau đó cũng được quan sát là đến trên cùng giao diện đó. Không có tun0 vì không có gì tạo ra nó.

Yêu cầu bên trong vẫn là một gói riêng với nguồn, đích và dịch vụ riêng, và nhân biết nó ra khỏi hiệp hội bảo mật nào. Chính kiến thức đó là thứ một quy tắc tường lửa có thể khớp.

Hai gói, một giao diện

Hãy hình dung hướng vào. Một gói được đóng gói trong ESP hoặc UDP đến, nhân tìm chính sách tương ứng, giải mã nó và chuyển gói rõ cho đường chuyển tiếp. Một quy tắc chỉ nhìn vào tên giao diện không thể phân biệt gói đó với bất kỳ lưu lượng nào khác đến trên cùng sợi dây.

Điều phân biệt nó là ngữ cảnh của đường đi bảo mật vào gắn với gói. nftables hiển thị nó dưới dạng meta ipsec exists, đúng khi gói đến qua một đường đi bảo mật IPsec. Kết hợp nó với nhóm máy khách, đích và dịch vụ, và quy tắc trở nên đủ cụ thể để an toàn.

Bỏ qua ngữ cảnh là lỗi phổ biến, và đó là lỗi bảo mật chứ không phải lỗi thẩm mỹ. Một quy tắc chấp nhận mọi thứ có nguồn từ nhóm máy khách cũng vui vẻ chấp nhận một gói giả mạo từ mạng cục bộ, vì địa chỉ nguồn tự nó không là bằng chứng cho bất cứ điều gì. Ngữ cảnh đường đi bảo mật là cách rẻ nhất để làm cho nguồn có ý nghĩa. Hãy viết quy tắc với nó ngay từ đầu thay vì thêm vào sau một cuộc kiểm toán.

Viết quy tắc chuyển tiếp

Giả sử có một dịch vụ truy cập từ xa IPv4 đã xác thực với máy khách trong 10.90.0.0/24 và một đích đã được phê duyệt tại 203.0.113.40. Một đoạn quy tắc cho luồng đó trông như sau.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Các địa chỉ và giao diện là ví dụ cần thay thế. Đặt tương đương đã xem xét vào chính sách chuyển tiếp trước quy tắc mà nếu không sẽ từ chối luồng, và không xóa một bộ quy tắc hiện có để cài đặt nó; một cổng không phải là thí nghiệm trong phòng sạch.

Thuật ngữ oifname đáng được giữ lại. Nó ghi lại quyết định ra và ngăn quy tắc khớp theo một hướng bạn không định, điều này quan trọng trên một cổng có nhiều đường ra internet. Trên một hộp thử với một đường lên duy nhất, thuật ngữ có vẻ thừa, và đó chính là lý do nó bị bỏ trước khi hộp có đường lên thứ hai.

Các quyền cho trao đổi bên ngoài là riêng biệt. Đường vào của cổng cần các cổng IKE và ESP hoặc đóng gói UDP mà nó thực sự dùng, và những quyền đó không cho phép gì về gói đã giải mã bên trong. Trộn lẫn hai thứ là cách một đường hầm đang hoạt động kết thúc với một tường lửa chuyển tiếp mọi thứ.

Ngữ cảnh vào không phải ngữ cảnh ra

Cùng một họ biểu thức bao gồm hướng còn lại với rt ipsec, mô tả hiệp hội bảo mật ra mà một gói sẽ dùng. Nó trả lời một câu hỏi khác: không phải gói này đến từ đâu, mà liệu nó có được bảo vệ ở chặng tiếp theo không.

Sự khác biệt đó quan trọng trên một cổng vừa kết thúc một đường hầm vừa chuyển tiếp vào một đường hầm khác. Một gói có thể đến đã giải mã và vẫn phải đi ra được mã hóa, và một sự chấp nhận chỉ viết cho ngữ cảnh vào không nói gì về yêu cầu ra. Nếu chính sách yêu cầu sự bảo vệ đó, bộ quy tắc nên thể hiện nó thay vì giả định định tuyến sẽ xử lý.

Giữ hai câu hỏi trong các quy tắc riêng để người đọc thấy cái nào đang được áp dụng. Một quy tắc khéo léo kiểm tra cả hai thì khó xem xét hơn và khó gỡ lỗi hơn nhiều khi một nửa của nó ngừng khớp. Hai quy tắc có bộ đếm cũng cho bạn biết yêu cầu nào đang thất bại, điều mà một quy tắc gộp sẽ không bao giờ làm.

NAT không phải quyết định của tường lửa

Lưu lượng ra internet từ một nhóm máy khách riêng thường cần dịch nguồn để phản hồi tìm được đường về. Nhưng lưu lượng được chọn cho một chính sách IPsec ra khác phải giữ miễn trừ cần thiết của nó, và việc che mọi nguồn riêng mà không nghĩ đến quyết định bảo vệ tiếp theo sẽ phá vỡ điều đó.

Một sự chấp nhận bên trong chuỗi NAT cũng không phải là sự cho phép chung. NAT và lọc có nhiệm vụ khác nhau, và một chuỗi NAT không kiểm tra mọi gói về sau của một luồng đã thiết lập, và đó chính là lý do dựa vào nó để bảo mật tạo ra những quy tắc trông có vẻ hoạt động trong thử nghiệm và thất bại dưới tải.

Điều ngược lại cũng đúng và khiến người ta ngạc nhiên: một sự chấp nhận ở đâu đó trong một chuỗi lọc cơ sở không có trọng lượng nào chống lại một sự từ chối về sau trong một chuỗi áp dụng khác. Thứ tự và phạm vi chuỗi quyết định kết quả, không phải sự hiện diện của một chấp nhận trong tệp.

Xác minh dịch vụ bên trong chính xác

Hãy thử đích và cổng cụ thể mà bạn đã cho phép, từ một máy khách thật, và xác nhận rằng phản hồi quay lại. Sau đó thử một thứ bạn không cho phép và kiểm tra rằng nó không đi qua, vì một quy tắc quá rộng cũng vượt qua thử nghiệm đầu tiên tốt như một quy tắc đúng. Một yêu cầu không bao giờ rời máy khách cũng không phải là kết quả của tường lửa, nên hãy đọc bộ đếm để xem gói có được đánh giá hay không. Hai thử nghiệm và một lần đọc bộ đếm sẽ cho bạn biết nhiều hơn một buổi chiều đọc bộ quy tắc.

Tài liệu tham chiếu nftables mô tả meta ipsec, rt ipsec và các biểu thức dành riêng cho hướng, và đó là nơi kiểm tra cú pháp so với phiên bản đã cài của bạn. Và hãy giữ phạm vi rõ ràng: đây là ví dụ IPv4, nó không nói gì về IPv6, và nó không biến việc chuyển tiếp cổng công cộng tùy tiện thành một phần của dịch vụ VPN.