Hai lần kiểm tra đăng nhập không phải hai yếu tố: VPN và RADIUS

Thêm một backend xác thực thứ hai vào cổng VPN có cảm giác như thêm một yếu tố thứ hai. Thông thường nó thêm một lần kiểm tra thứ hai, một đối tượng khác với các chế độ lỗi khác. Việc cả hai phải thành công, mỗi bên chứng minh điều gì và điều gì xảy ra khi một bên không khả dụng là ba quyết định riêng biệt. Làm sai và cổng sẽ chặt chẽ hơn trong bản trình diễn và yếu hơn khi có sự cố.

Một backend thứ hai thực sự chứng minh điều gì

Tra cứu tài khoản cục bộ chứng minh rằng một tên tồn tại trong cơ sở dữ liệu và một mật khẩu khớp với nó. Trao đổi RADIUS chứng minh rằng một máy chủ RADIUS đã trả về Access-Accept cho các thuộc tính nhận được. Không câu nào nhắc đến loại yếu tố, bởi vì cả hai đều xác minh kiến thức. Và hướng dẫn của NIST về danh tính số đếm các loại yếu tố riêng biệt và bộ xác thực của chúng, không phải máy chủ hay lời nhắc.

Có một thiết kế hợp lý trong đó cả hai hệ thống tham gia. Một dịch vụ trung tâm có thể xác thực con người trong khi cổng kiểm tra độc lập xem tài khoản đó có quyền với đường hầm này không. Đó là sự ủy quyền bên cạnh xác thực, và gọi đó là hai yếu tố sẽ nhầm lẫn giữa kiểm tra chính sách với bằng chứng sở hữu.

RADIUS có thể mang một yếu tố thứ hai thực sự khi nó đứng trước thứ gì đó xác minh một yếu tố, chẳng hạn phê duyệt push hoặc token phần cứng. Phong bì không cho biết người dùng đã trình bày bộ xác thực nào, nên hãy đọc chính sách backend chứ không phải nhãn của cổng.

AND, OR và dự phòng là các sản phẩm khác nhau

Trước khi so sánh các triển khai, hãy quyết định cả hai nghĩa là gì trong yêu cầu của bạn. Chính sách AND yêu cầu mọi kiểm tra được nêu phải đạt, chính sách OR chấp nhận bất kỳ cái nào thành công, và dự phòng chỉ thử cái thứ hai trong các điều kiện lỗi đã nêu. Ba cái này hành xử ngược nhau khi có sự cố, và thường chỉ một trong số chúng là điều mà buổi đánh giá muốn.

Thêm hai mục backend vào màn hình cấu hình không tiết lộ sản phẩm triển khai chính sách nào. Một số cổng nối chuỗi plugin theo thứ tự và dừng ở lần từ chối đầu tiên, chỉ là AND khi mọi plugin đều bắt buộc. Những cái khác coi tài khoản cục bộ là ghi đè, biến sự cố trung tâm thành đường vòng. Câu trả lời đáng tin cậy là một bài kiểm thử phủ định được ghi lại cho từng đường đi, chạy trên bản dựng bạn triển khai.

Dự phòng đáng bị nghi ngờ nhất, vì nó tồn tại để tiếp tục hoạt động khi có thứ gì đó hỏng. Một dự phòng chấp nhận mật khẩu cục bộ mỗi khi RADIUS không thể truy cập đã biến chính sách trung tâm thành cánh cửa thứ hai yếu hơn.

Kiểm tra kép của OpenVPN là một trường hợp cụ thể

OpenVPN cộng đồng 2.6 yêu cầu cả chứng chỉ máy khách và script auth-user-pass-verify đã cấu hình khi cả hai được bật. Đó là một AND được ghi lại giữa xác minh chứng chỉ và script thông tin đăng nhập, và thực sự là hai lần kiểm tra. Nó vẫn chưa tự động là hai loại yếu tố, vì script có thể chỉ xác thực mật khẩu.

Tổ hợp cũng để mở câu hỏi liên kết. Chứng chỉ thường nhận diện thiết bị trong khi thông tin đăng nhập nhận diện con người, và không có gì trong luồng mặc định yêu cầu cả hai cùng chỉ một chủ thể. Hãy quyết định những cặp nào được phép, rồi thực thi bản đồ đó bên trong script xác minh hoặc ở bước ủy quyền sau.

Chế độ chỉ chứng chỉ là một lần kiểm tra, dựa trên một khóa có thể có hoặc không được bảo vệ bằng PIN. PIN biến cùng thông tin đăng nhập thành kiến thức cộng sở hữu chỉ khi không thể dùng khóa mà không có nó. Để khóa đó không mã hóa trên đĩa sẽ rút gọn phần thứ hai thành quyền tệp.

Các nhà sản xuất thiết bị tự xây hệ thống của họ, thường là một mô-đun PAM hoặc plugin RADIUS sau bảng điều khiển web. Hành vi cộng đồng là tài liệu tham khảo về hình thức kiểm tra kép, không phải mô tả cách thiết bị kết hợp chúng.

Kiểm tra tổ hợp trên cổng của bạn

Đọc cấu hình trước khi tin bản tóm tắt của bảng điều khiển. Các dòng quyết định chính sách là chế độ chứng chỉ, script thông tin đăng nhập và thứ tự plugin.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep cho biết có cần chứng chỉ không và script nào chạy sau đó, và thứ tự quan trọng hơn những gì tên gợi ý. Bản kết xuất chứng chỉ cung cấp danh tính mà cổng sẽ thấy, bao gồm CN và số sê-ri cần cho bản đồ liên kết. Bài kiểm thử RADIUS là trường hợp phủ định: mật khẩu sai phải tạo Access-Reject, và đúng tạo Access-Accept. Nếu thông tin đăng nhập bị từ chối vẫn tạo phiên, script hoàn toàn không nằm trên đường xác thực.

Sau đó chạy trường hợp sự cố trên một phiên bản phòng thí nghiệm: dừng backend bắt buộc và kết nối bằng thông tin đăng nhập hợp lệ. Kết quả mong đợi là từ chối, và bất cứ điều gì khác là chính sách dự phòng mà không ai ghi lại.

Viết yêu cầu dưới dạng các trường hợp phủ định

Một yêu cầu dùng được nêu tên các bằng chứng, các tài khoản được phép trình bày chúng và kết quả khi thiếu bộ xác minh. Nó cũng nêu cặp ghép được phép giữa danh tính thiết bị và danh tính con người. Điều đó chính xác hơn tên sản phẩm trên đơn đặt hàng, và có thể kiểm thử.

Việc chấp nhận nên gồm bốn lần từ chối: tài khoản cục bộ không đủ điều kiện, thiếu bằng chứng bắt buộc, yếu tố thứ hai không hợp lệ và backend bắt buộc không thể truy cập. Mỗi lần từ chối cần một dòng nhật ký phân biệt nó với những lần khác, nếu không sự cố tiếp theo sẽ bắt đầu bằng phỏng đoán. Ghi lại thành phần nào đưa ra từng quyết định, vì cổng, máy chủ RADIUS và thư mục sẽ đổ lỗi cho nhau.

Chạy lại bốn lần từ chối sau mọi thay đổi plugin hoặc firmware. Chúng rẻ, và chính sách mà chúng bảo vệ là phần kẻ tấn công kiểm tra đầu tiên.