Chứng chỉ VPN không bảo vệ đoạn LDAP

Đăng nhập VPN kiểm tra thông tin xác thực với một thư mục bao gồm hai kết nối mạng riêng biệt. Kết nối của người dùng tới cổng được bảo vệ bằng chứng chỉ của chính VPN và cấu hình giao thức. Kết nối của cổng tới thư mục là một phiên khác với cài đặt TLS riêng, kho tin cậy riêng và các kiểu hỏng riêng. Không có gì ở kết nối thứ nhất bảo đảm điều gì về kết nối thứ hai.

Chính sự bất đối xứng đó là cơ chế đằng sau một lần đăng nhập trông như đã mã hóa mà vẫn gửi mật khẩu bind ở dạng rõ.

Hai kết nối, hai quyết định tin cậy

Phiên bên ngoài là thứ người dùng nhìn thấy: một chứng chỉ gắn với tên máy chủ VPN, được máy khách xác thực, mang cuộc trao đổi xác thực. Phiên bên trong thuộc về máy khách thư mục bên trong cổng, mở kết nối riêng và hoặc thương lượng TLS hoặc không. Mỗi bên xác thực đối tác mà nó nói chuyện, dùng tài liệu từ một tệp cấu hình khác. Đoạn bên trong cấu hình sai vẫn vô hình từ phía người dùng, vì đoạn bên ngoài hoạt động đúng như dự định.

Đó là lý do lỗi diễn ra âm thầm chứ không ồn ào. Một cổng không bao giờ kiểm tra chứng chỉ của thư mục vẫn xác thực người dùng đúng cách; nó chỉ xác thực họ qua một kênh mà nó chưa xác minh.

StartTLS và LDAPS, được chọn có chủ đích

StartTLS mở như LDAP thường và nâng cấp tại chỗ, theo quy ước trên cổng 389. LDAPS khởi động TLS cùng với kết nối, theo quy ước trên 636. Cả hai đều hợp lệ và bộ điều hợp phải khớp với những gì thư mục cung cấp. Yêu cầu StartTLS khác với việc thử nó rồi tiếp tục khi nâng cấp thất bại, và chính ở khác biệt đó mật khẩu bind có thể thoát ra. Cấu hình chế độ nghiêm ngặt và không cho phép đường dự phòng không được bảo vệ cho bind bằng mật khẩu.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Tùy chọn -ZZ là toàn bộ vấn đề: truy vấn thất bại thay vì âm thầm tiếp tục mà không nâng cấp. Các tên và tài khoản trong dòng đó là ví dụ. Tài liệu TLS của OpenLDAP đề cập các cài đặt tin cậy đằng sau.

Thư viện LDAP đọc kho tin cậy nào?

Thư viện máy khách OpenLDAP đọc cấu hình tin cậy của chính nó, dù từ tệp hệ thống hay từ cài đặt riêng của plugin. Chỉ thị CA của VPN áp dụng cho các đối tác VPN và không phải bằng chứng rằng thư viện LDAP đọc cùng một tệp. Dùng tên máy chủ thư mục mà chứng chỉ thực sự bao phủ, cùng chuỗi phát hành mà thư viện tin cậy. Trong Active Directory, triển khai chứng chỉ dịch vụ thư mục với mục đích xác thực máy chủ đúng, thay vì suy đoán từ tên hiển thị.

Mọi điểm đích chuyển đổi dự phòng phải đáp ứng cùng chính sách danh tính. Môi trường mà điểm chính được xác thực còn điểm phụ thì không thì tệ hơn môi trường không có dự phòng, vì con đường yếu hơn chỉ được phát hiện trong lúc gián đoạn.

Tài khoản bind vẫn là vấn đề riêng

Bảo vệ đường truyền không làm giảm những gì tài khoản bind có thể làm. Phạm vi tìm kiếm trong thư mục, ủy quyền theo nhóm và đặc quyền của tài khoản dịch vụ là các quyết định riêng, và một tài khoản bind rộng vẫn rộng sau khi bật TLS. Dùng tài khoản dịch vụ và cơ sở tìm kiếm hẹp nhất mà tích hợp cần, và ghi lại điểm cuối, chế độ TLS, chủ sở hữu tin cậy và quy trình gia hạn cùng với cấu hình VPN.

Khi xuất hiện sự không khớp chứng chỉ, hãy triển khai chứng chỉ hoặc chuỗi đúng. Tắt xác minh biến một sự không khớp hữu hình thành vô hình và để mối quan hệ tin cậy thứ hai không được kiểm tra.

Hai kết nối, hai chủ sở hữu, hai ngày gia hạn. Giữ chúng tách biệt trong tài liệu chính là điều giữ cho lần đăng nhập trung thực.