Cách một proxy công khai đến được nguồn gốc riêng qua VPN

Xuất bản một trang web qua đường hầm và cấp quyền truy cập VPN cho người dùng là hai cách bố trí khác nhau cùng chia sẻ một sợi cáp. Trong cách thứ nhất, một proxy ngược công khai nhận yêu cầu của khách truy cập và chuyển tiếp nó qua đường hầm đến một nguồn gốc mà không ai có thể chạm tới trực tiếp. Trong cách thứ hai, người dùng phải tham gia VPN trước khi ứng dụng có thể truy cập được. Trộn lẫn hai mô tả này chính là cách một backend riêng tư cuối cùng bị phơi bày công khai.

Hai mô hình trông giống nhau trên sơ đồ

Hãy vẽ các mũi tên trước khi chọn bất cứ thứ gì. Mô hình xuất bản công khai đi từ trình duyệt đến proxy qua HTTPS, rồi từ proxy đến nguồn gốc qua đường hầm, và nguồn gốc không bao giờ chấp nhận kết nối từ internet. Mô hình chỉ VPN đi từ máy khách đến cổng, và ứng dụng chỉ truy cập được từ bên trong đường đi đó. Máy tính xách tay của người dùng nằm trên cùng mạng với ứng dụng, và đó là toàn bộ ý nghĩa của mô hình đó.

Các mô hình khác nhau ở chỗ ai xác thực và ở đâu. Trong cách thứ nhất, proxy là lối vào công khai và nó chuyển tiếp mọi yêu cầu đến, kể cả yêu cầu thù địch, theo chính sách được cấu hình trên nó. Trong cách thứ hai, chính khả năng truy cập là cổng, một sự tiếp nhận thô nhưng thật.

TLS dừng ở đâu, và nó thực sự chứng minh điều gì

TLS giữa trình duyệt và proxy bảo vệ chặng đó và cho phép trình duyệt xác minh trang mà nó định truy cập. Nếu proxy kết thúc TLS, yêu cầu tồn tại ở dạng đọc được bên trong tiến trình đó trước khi được chuyển tiếp. Một phiên TLS thứ hai tới nguồn gốc có thể bảo vệ chặng tiếp theo và xác minh riêng điểm cuối của ứng dụng. Không phiên nào quyết định ai được dùng ứng dụng. Chứng chỉ wildcard trên proxy cũng không mở rộng tới chặng thứ hai đó.

Đây là phần mà người ta gói gọn trong từ mã hóa. Tính bảo mật, tính toàn vẹn và danh tính máy chủ là thuộc tính của truyền tải; còn cấp quyền là quyết định của ứng dụng. Một địa chỉ riêng tư sau đường hầm thay đổi ai có thể chạm tới ổ cắm, chứ không phải ai được đăng nhập sau khi đã tới.

Chỉ tin các tiêu đề được chuyển tiếp từ proxy

Các ứng dụng ghi nhật ký hoặc cấp quyền theo địa chỉ máy khách thường đọc một tiêu đề do proxy thêm vào. Tiêu đề đó chỉ là văn bản, nên bất cứ thứ gì chạm tới nguồn gốc trực tiếp đều có thể khai bất kỳ địa chỉ nào. Hãy giới hạn nguồn gốc để chỉ địa chỉ đường hầm của proxy được kết nối, và cấu hình ứng dụng chỉ chấp nhận tiêu đề từ địa chỉ đó.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Nếu yêu cầu đó thành công từ một máy chủ không phải proxy, nguồn gốc đang tin một tiêu đề mà nó nên bỏ qua. Hãy sửa trình lắng nghe trước khi chạm vào ứng dụng. Từ chối là kết quả tốt hơn nhiều so với một dòng nhật ký mang địa chỉ giả mạo.

Giữ nguồn gốc chỉ truy cập được từ đúng một nơi

Hãy gắn trình lắng nghe của nguồn gốc vào địa chỉ đường hầm hoặc rào nó bằng tường lửa về phía proxy, rồi xác nhận thứ thực sự đang lắng nghe. Một dịch vụ khởi động với ràng buộc wildcard chấp nhận kết nối trên mọi giao diện mà máy chủ có, kể cả giao diện mà bạn quên rằng nó có thể định tuyến. Bảng lắng nghe mới là sự thật nền tảng, không phải tệp cấu hình mà bạn định áp dụng. Nếu ràng buộc wildcard là cố ý, tường lửa vẫn phải là thành phần thu hẹp nó.

ss -ltnp | grep -E ':(80|443)'

Hãy làm cùng một đợt rà soát cho các giao diện quản trị, vì đó thường là chỗ phơi bày tình cờ. Sau đó viết hai mô hình riêng ra: trang công khai qua proxy, và giao diện quản trị chỉ truy cập được qua đường hầm. Câu nói rằng máy chủ nằm sau VPN không nói gì về những điều đó.