Quy tắc EC2 chỉ cho VPN: mọi nhóm bảo mật được gắn phải đồng ý

Bạn thêm một quy tắc vào cho nhóm máy khách VPN, không gỡ bỏ gì, và dịch vụ vẫn truy cập được từ internet. Không có gì bị hỏng. Một nhóm bảo mật không có ghi đè, ưu tiên hay từ chối cuối cùng mà quy tắc hẹp có thể thắng. Mỗi nhóm được gắn vào instance đóng góp quyền của mình vào một tập hợp chung, và quy tắc rộng mà bạn quên vẫn nằm trong tập đó. Biến instance thành chỉ-VPN nghĩa là kiểm tra tất cả, không phải thêm một quy tắc nghe hay hơn vào một nhóm.

Viết ra dịch vụ trước khi viết quy tắc

Hãy bắt đầu bằng đích đến, giao thức và cổng chính xác, cùng giao diện mạng mà dịch vụ thực sự lắng nghe. Một instance có nhiều giao diện hoặc nhiều dịch vụ trên một cổng cần kiểm tra theo từng giao diện, vì các nhóm được gắn có thể khác nhau. Sau đó xác định giao diện đó thực sự nhận địa chỉ nguồn nào cho một người dùng VPN, thay vì địa chỉ mà máy khách hiển thị trong cửa sổ kết nối của chính nó.

Hai địa chỉ này lệch nhau thường xuyên hơn người ta tưởng khi có dịch địa chỉ và định tuyến.

Ba mô hình nguồn, ba quy tắc khác nhau

Với truy cập định tuyến riêng, instance nhận nhóm máy khách hoặc dải mạng doanh nghiệp, tùy thuộc vào cách đường đi được định tuyến và dịch địa chỉ. Với một điểm cuối công khai tiếp cận qua lối ra doanh nghiệp, instance thay vào đó thấy địa chỉ NAT của doanh nghiệp, và chỉ khi đích đó thực sự dùng đường VPN, vì đường hầm tách có thể để nó trên một kết nối gia đình. Với điểm cuối Client VPN được quản lý, mô hình liên kết và mạng đích đã được ghi nhận sẽ áp dụng, và địa chỉ máy khách đến từ CIDR máy khách đã cấu hình.

Điều không hiệu quả là tham chiếu một cổng VPN làm nguồn của nhóm bảo mật. Tham chiếu nhóm khớp với các giao diện mạng co giãn bên trong VPC hoặc một mạng ngang hàng, và một cổng chuyển tiếp gói không phải là một trong số đó.

Đọc hợp của tất cả các nhóm được gắn

Mở instance, tìm giao diện mạng của nó và liệt kê mọi nhóm bảo mật được gắn. Với mỗi nhóm, hãy kiểm tra mọi quy tắc bao phủ giao thức và cổng của bạn, bao gồm dải cổng rộng và cả hai họ địa chỉ. Một quy tắc IPv4 từ 0.0.0.0/0 không miễn cho bạn việc kiểm tra ::/0, và một quy tắc cho phép mọi lưu lượng che giấu hoàn toàn câu hỏi về cổng. Chỉ sau bản kiểm kê đó bạn mới có thể nói quyền thực tế cho dịch vụ là gì.

Tài liệu tham chiếu quy tắc của AWS mô tả nhóm bảo mật là chỉ-cho-phép và nêu rằng các quy tắc từ mọi nhóm được gắn đều được tổng hợp, và đó là toàn bộ cơ chế đằng sau thất bại này.

ACL mạng là một chính sách riêng, không trạng thái, với các mục cho phép và từ chối có thứ tự, và chúng được đánh giá trên subnet chứ không phải trên instance.

Đừng trả lời bằng một bức tường từ chối

Thêm một lệnh từ chối NACL toàn subnet để bắt chước tường lửa mà bạn quen dùng là công cụ sai và đầy rủi ro. Các mục NACL có thứ tự và không trạng thái, nên một lệnh từ chối đặt trên một lệnh cho phép hiện có sẽ âm thầm phá vỡ lưu lượng không liên quan, kể cả đường về của các phiên mà bạn đang cố giữ lại. Hãy sửa quyền rộng của nhóm bảo mật trong chính nhóm sở hữu nó, rồi để ACL yên trừ khi nó thực sự là một phần của thiết kế.

Gỡ một địa chỉ công khai khỏi instance là một bảo đảm mạnh hơn, và đó cũng là một thay đổi kiến trúc với hệ quả về quản trị và ứng dụng, không phải một ô đánh dấu trên danh sách cho phép.

Kiểm thử với một phiên mới và giữ một đường vào

Trước khi rút bất kỳ quyền hiện có nào, hãy xác nhận một đường quản trị độc lập đã được phê duyệt, vì quy tắc bạn sắp xóa có thể là quy tắc mà việc khôi phục phiên của bạn phụ thuộc vào. Sau đó kiểm thử một kết nối được cho phép mới từ VPN và một kết nối bị từ chối mới từ một đường kiểm thử không phải VPN đã được cấp phép. Các phiên đang được theo dõi hiện có sống sót qua thay đổi quy tắc theo những cách khiến các shell mở cũ trở nên vô dụng làm bằng chứng chấp nhận.

Cuối cùng, hãy giữ nguyên quyền ủy quyền của chính ứng dụng. Một lối ra doanh nghiệp đã dịch có thể đại diện cho hàng trăm người, và việc gia nhập mạng chưa bao giờ nhận diện một người dùng cá nhân hay thiết bị của họ.