Nhóm bảo mật trên đám mây cho VPN: mở trình lắng nghe, không phải mở tất cả

Máy chủ VPN đang chạy, máy khách bị hết thời gian chờ, và phản ứng đầu tiên là thêm một quy tắc cho phép tất cả vào nhóm bảo mật. Đôi khi điều đó làm nó chạy được, và đó là kết quả tệ nhất, vì giờ không ai biết ranh giới nào thực sự đã bị đóng. Có bốn bộ lọc riêng biệt giữa máy khách và daemon, và chỉ một trong số đó là nhóm bảo mật.

Gọi tên giao thức trước quy tắc

Một quy tắc là giao thức, dải cổng và nguồn. WireGuard lắng nghe trên UDP, thường là 51820. OpenVPN thường là UDP hoặc TCP 1194 tùy cách cấu hình. IPsec cần trao đổi IKE trên UDP 500 và 4500 cùng chính giao thức ESP, vốn là số giao thức chứ không phải cổng. Đoán là TCP vì các quy tắc khác là TCP chính là cách tạo ra một quy tắc trông đúng mà không khớp với gì cả.

Đọc trình lắng nghe từ dịch vụ đang chạy, không phải từ bài hướng dẫn. Một daemon gắn với một địa chỉ sẽ không nhận lưu lượng đến ở địa chỉ khác.

Giới hạn nguồn trong dải máy khách mà thiết kế cho phép, thay vì toàn bộ internet.

Nhóm bảo mật có trạng thái; ACL mạng con thì không

Nhóm bảo mật có trạng thái và chỉ cho phép: luồng vào được phép tự động nhận phản hồi, và không có quy tắc từ chối nào để phải cân nhắc. ACL mạng con không có trạng thái và được đánh giá theo cả hai chiều, nên một lần cho phép vào mà thiếu dải cổng tạm thời ra tương ứng vẫn thất bại. Sự khác biệt đó giải thích nhiều quy tắc trông đúng trên bảng điều khiển.

Cũng xác nhận chính sách nào đang gắn với điểm cuối đang chạy, vì một phiên bản có thể có nhiều hơn một nhóm và một quy tắc trong nhóm không gắn thì không thay đổi gì.

Chính sách hiệu lực là hợp của những gì được gắn, không phải tệp bạn đã sửa.

Tường lửa của máy chủ là một ranh giới riêng

Chính sách đám mây cho phép lưu lượng đến giao diện mạng, rồi hệ điều hành quyết định liệu daemon có thấy nó hay không. Tường lửa máy chủ với chính sách từ chối mặc định sẽ bỏ một gói mà nhóm bảo mật đã cho phép, và bảng điều khiển đám mây sẽ không hiện từ chối nào vì nó chưa bao giờ có ý kiến. Kiểm tra cả hai, theo thứ tự mà gói gặp chúng.

Nếu máy chủ dùng giao diện tường lửa của bản phân phối, hãy xác nhận các quy tắc bên dưới thay vì tên hồ sơ, vì hồ sơ có thể đang hoạt động trong khi cổng đã đóng.

Một lần bắt gói trên giao diện cho bạn biết ranh giới nào đã bỏ gói.

Cho phép trình lắng nghe không phải là định tuyến máy khách

Một cổng VPN chuyển tiếp lưu lượng máy khách cần nhiều hơn một cổng mở. Nó cần chuyển tiếp IP, một chính sách cho phép luồng từ giao diện đường hầm đến mạng đích, và thường là kiểm tra nguồn-đích bị tắt trên giao diện để nền tảng không loại bỏ lưu lượng không được gửi đến nó. Không điều nào trong số đó do quy tắc trình lắng nghe tạo ra.

Đây là nơi một cái bắt tay hoạt động và một đường dữ liệu hỏng tách nhau, và đó là lý do trạng thái đường hầm có thể trông khỏe mạnh trong khi không có gì tải được.

Sửa định tuyến như một thay đổi riêng với kiểm chứng riêng, và lưu ý rằng cổng chuyển tiếp cũng cần chính sách ra cho phép đích.

Giữ một đường quay lại, rồi thu hẹp quy tắc

Trước khi thay đổi chính sách tường lửa từ xa, hãy xác nhận có một đường quản trị độc lập, như trình quản lý phiên, bảng điều khiển nối tiếp hoặc mạng ngoài băng. Nếu đường quản trị duy nhất đi qua quy tắc bạn đang sửa, bạn không có cách khôi phục. Sau đó áp dụng quy tắc hẹp, thử từ máy khách thật và đối chiếu lần thử với bằng chứng phía máy chủ. Câu trả lời từ một dịch vụ khác trên cùng máy không phải bằng chứng rằng trình lắng nghe đã được chạm tới.

Gỡ bỏ mọi cho phép rộng mang tính thử nghiệm ngay khi cái hẹp hoạt động, và ghi lại vì sao quy tắc tồn tại. AWS tài liệu hóa hành vi có trạng thái của nhóm bảo mật, và đó là tài liệu cần trích dẫn khi ai đó đề xuất một dải rộng như lối tắt.

Cũng hãy ghi lại việc gắn nhóm, nếu không một giao diện thay thế sẽ âm thầm mất chính sách.