ALB nội bộ với tên DNS công khai: có thật sự bị lộ?

Chạy tra cứu DNS công cộng vào một bộ cân bằng tải nội bộ và bạn có thể nhận lại địa chỉ riêng, trông giống cấu hình sai cho đến khi bạn kiểm tra bản ghi dùng để làm gì. AWS ghi nhận rằng tên bộ cân bằng tải nội bộ có thể phân giải công khai trong khi các nút của chúng chỉ giữ địa chỉ riêng. Trình phân giải trả lời dịch vụ ở đâu; nó không tạo tuyến, không mở nhóm bảo mật và không xác thực ai. Câu trả lời đó có phải vấn đề hay không phụ thuộc vào các sự kiện bạn có thể kiểm tra theo thứ tự.

Bước một: đọc scheme, không phải IP

Trường scheme là tuyên bố của chính bộ cân bằng tải về ranh giới của nó. aws elbv2 describe-load-balancers --names app-internal trả về Scheme với giá trị internal hoặc internet-facing, cùng loại địa chỉ cho IPv4 hoặc ngăn xếp kép. Bộ cân bằng tải hướng ra internet vẫn có thể chuyển tiếp tới mục tiêu riêng, nên việc thấy địa chỉ backend riêng không chứng minh gì về phía trước.

Ghi lại scheme trước khi xem bất cứ thứ gì khác, vì mọi đánh giá sau đó phụ thuộc vào nó. Nó cũng cho biết những kiểm soát nào tồn tại, từ nhóm bảo mật và quy tắc listener đến bộ tính năng của loại bộ cân bằng tải đó. Một scheme sao chép từ ảnh chụp màn hình console cũ còn tệ hơn không có ghi chú. Đọc lại từ API và dán giá trị vào ticket.

Bước hai: xem tên phân giải tới đâu

Truy vấn từ ngoài VPC bằng dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com và ghi nhận các câu trả lời có nằm trong 10.0.0.0/8, 172.16.0.0/12 hay 192.168.0.0/16. Câu trả lời riêng từ trình phân giải công cộng là hành vi mong đợi với tên bộ cân bằng tải nội bộ; đó không phải bằng chứng địa chỉ định tuyến được từ internet.

Phân giải cùng tên từ bên trong VPC và so sánh. Nếu hai câu trả lời khác nhau, bạn đang thấy cách đặt tên split-horizon, và khác biệt đó là chi tiết thiết kế, không phải rò rỉ.

Bước ba: liệt kê các đường có thể chạm tới nó

Địa chỉ riêng có thể tiếp cận từ bất cứ nơi nào có tuyến và quy tắc bảo mật. Hãy liệt kê có chủ đích: VPN site-to-site, VPN máy khách, VPC peering, kết nối transit gateway, Direct Connect và mọi proxy hoặc bastion trong VPC. Một trong số đó là đường dự kiến, phần còn lại là những đường kẻ tấn công sẽ tìm.

Sau đó kiểm tra các kiểm soát trên từng đường: nhóm bảo mật trên bộ cân bằng tải, ACL mạng trên subnet và định tuyến tạo ra đường đó. Hầu hết các trường hợp dịch vụ nội bộ bị lộ được báo cáo đều được giải quyết ở đây, hoặc do có peering ngoài ý muốn hoặc do đường đó là chủ đích và ứng dụng không có xác thực.

Bước bốn: thử listener và ứng dụng riêng rẽ

Thử kết nối từ mạng không được phép chạm tới dịch vụ và xác nhận bạn không thể. Sau đó thử từ mạng được phép, và xác nhận bạn chạm tới listener. Hai kết quả đó tách khả năng tiếp cận mạng khỏi hành vi ứng dụng, và chúng là bằng chứng duy nhất quan trọng cho câu hỏi phơi bày.

Listener tiếp cận được không giống với ứng dụng truy cập được. Kiểm tra chứng chỉ TLS và chính sách giao thức, sau đó xác thực và phân quyền của chính ứng dụng. Một công cụ nội bộ chấp nhận mọi người gọi trên VPN doanh nghiệp sẽ lộ với mọi laptop bị xâm nhập trên VPN đó, là rủi ro khác với hướng ra internet nhưng vẫn là rủi ro.

Hãy nhớ rằng kiểm soát thay đổi theo loại. Tường lửa lớp ứng dụng gắn với một họ bộ cân bằng tải chứ không phải họ kia, nên hãy xác nhận điều gì thực sự có sẵn cho scheme và loại trước mắt thay vì giả định sự tương đương.

Bước năm: quyết định xem bản thân cái tên có quan trọng không

Khả năng phân giải công khai có thể tiết lộ tên dịch vụ, khu vực và dải địa chỉ. Hãy coi đó là câu hỏi tiết lộ thông tin có câu trả lời chính sách, không phải sự cố tự động: giữ thuật ngữ kinh doanh nhạy cảm ngoài tên tài nguyên, và ghi lại việc tiết lộ trong hồ sơ rủi ro nếu quy ước đặt tên tiết lộ nhiều hơn bạn muốn.

Nếu tổ chức muốn trải nghiệm đặt tên riêng, vùng lưu trữ riêng có thể phục vụ alias chỉ phân giải trong các VPC liên kết. Điều đó thay đổi tên người dùng thấy; nó không làm tên do nhà cung cấp tạo ra thành bí mật và không xóa bất kỳ đường mạng nào.

Đừng cố ghim địa chỉ để giấu câu trả lời. Địa chỉ bộ cân bằng tải thay đổi, ghim phá thói quen xác thực TLS, và kiểm soát bạn thực sự cần là ai có thể lập kết nối và ứng dụng yêu cầu gì ở họ. Kiểm tra bốn sự kiện, ghi lại, và câu hỏi không còn mơ hồ.