Vì sao sửa tệp .ovpn không thể bật MFA trên máy chủ

Bạn thêm auth-user-pass vào một hồ sơ, kết nối lại, và ứng dụng khách hỏi tên người dùng và mật khẩu. Có vẻ như MFA đã bật. Rồi bạn nhập một mã từ tài khoản sai, hoặc một mã đã hết hạn mười phút trước, và đường hầm vẫn dựng lên. Đó là triệu chứng: ứng dụng khách đã thay đổi, máy chủ thì không. Mật khẩu dùng một lần chỉ là một yếu tố khi một bộ xác minh trên máy chủ quyết định liệu nó có hợp lệ cho danh tính đang yêu cầu hay không.

Lời nhắc chỉ chứng minh rằng ứng dụng khách đã hỏi, không hơn

Tệp .ovpn là một tài liệu phía ứng dụng khách. Nó có thể bảo ứng dụng khách yêu cầu thông tin đăng nhập, lưu vào bộ nhớ đệm hoặc ngừng làm việc đó. Nó không thể đăng ký người dùng, cài mô-đun PAM, hay khiến máy chủ đòi hỏi một yếu tố thứ hai mà hiện tại nó không kiểm tra.

Cài một ứng dụng xác thực trên điện thoại cũng không tạo ra mối quan hệ đó. Dự án Google Authenticator PAM là một thành phần xác minh OTP có thể đứng sau OpenVPN; nó không phải là cách gắn đăng nhập tài khoản Google vào một hồ sơ đã nhập.

Đăng ký là phần mà một hồ sơ không thể làm

TOTP cần vật liệu đăng ký được chia sẻ giữa ứng dụng xác thực và bộ xác minh của nó. Sáu chữ số trên điện thoại là đầu ra; hạt giống phía sau chúng là bí mật, và nó thuộc về một danh tính duy nhất.

Vì vậy người vận hành cần một quy trình đăng ký gắn hạt giống đúng với danh tính VPN đúng, cùng với một đường thay thế đã được xác minh cho điện thoại bị mất. Cho phép người dùng tải lên một tệp mang tên họ biến việc đăng ký thành cơ hội chiếm đoạt tài khoản, và việc mã hóa tệp tải lên không thay đổi điều đó.

Một thiết kế dựa trên PAM không cần tạo một tài khoản Unix riêng cho mỗi người dùng VPN. Tài liệu của mô-đun hỗ trợ các đường dẫn bí mật thay thế và một tài khoản chuyên dụng cho truy cập tệp, đó là danh tính của hệ thống tệp chứ không phải danh tính đăng nhập đang được xác minh.

Sai lầm phổ biến là một đường dẫn bí mật cố định kết thúc bằng một tên người dùng, được sao chép từ ví dụ một người dùng. Đó là bản trình diễn của một danh tính, không phải tra cứu theo từng người dùng, và dùng nó cho mọi yêu cầu không cho ai một ứng dụng xác thực được đăng ký độc lập. Hãy ghi lại ánh xạ danh tính, bảo vệ các tệp hạt giống và giữ các kiểm tra mật khẩu, chứng chỉ và tài khoản trong cùng một ngăn xếp xác thực.

Đọc ngăn xếp PAM để xem thực sự cần gì

Một dòng như account required pam_permit.so không triển khai tính đủ điều kiện của tài khoản và không thêm yếu tố nào. Nó cho phép giai đoạn quản lý tài khoản PAM đó, đây là một tuyên bố về một giai đoạn chứ không phải về người dùng của bạn.

Điều tương tự cũng áp dụng cho các tùy chọn đăng ký dễ dãi. Chấp nhận người dùng không có bí mật đã đăng ký có thể là lựa chọn triển khai có chủ ý, nhưng đó không phải bằng chứng rằng MFA là bắt buộc, và nó nên được ghi lại như một ngoại lệ tạm thời có ngày kết thúc.

Khớp tương tác của ứng dụng khách với thiết kế của máy chủ

auth-user-pass

Chỉ thị đó yêu cầu nhập tên người dùng và mật khẩu. Nó không cấu hình PAM, không tạo bản ghi đăng ký, và không nói với máy chủ rằng trường mật khẩu chứa giá trị TOTP. Tích hợp phía máy chủ và ứng dụng khách phải thống nhất về một tương tác mà việc triển khai thực sự hỗ trợ: một thách thức, một định dạng thông tin đăng nhập kết hợp đã được ghi lại, hoặc một luồng riêng cho sản phẩm.

Đừng nối thêm mã vào mật khẩu chỉ vì ứng dụng khách hiển thị một trường. Điều đó chỉ hoạt động ở nơi trình cắm của máy chủ mong đợi đúng định dạng đó, và nó thất bại một cách khó hiểu ở mọi nơi khác.

Giữ hạt giống và vật liệu QR ngoài các hồ sơ chia sẻ và nhật ký chẩn đoán thường lệ. Một mã được gửi qua kênh đăng nhập đã xác thực không phải là cùng một đối tượng với hạt giống được cấp trong quá trình đăng ký có kiểm soát, và trộn chúng trong một phiếu hỗ trợ là cách bí mật thoát ra ngoài.

Kết nối lại, mã thông báo và bài kiểm tra định đoạt

Hãy lên kế hoạch cho điều xảy ra sau lần đăng nhập thành công đầu tiên. Một mã đã được chấp nhận trước đó có thể đã hết hạn hoặc bị từ chối như một lần phát lại ở lần xác thực tiếp theo. auth-nocache kiểm soát việc lưu giữ thông tin đăng nhập và không cài MFA, và reneg-sec 0 không phải là định nghĩa của hỗ trợ TOTP, dù nó xuất hiện thường xuyên thế nào trong các chủ đề diễn đàn.

Một số triển khai phát hành mã thông báo xác thực sau lần kiểm tra đầu tiên để các lần kết nối lại không hỏi lại. Đó là một quyết định thiết kế với cửa sổ hiệu lực và câu chuyện thu hồi riêng, không phải một mặc định mà bạn thừa hưởng.

Sau đó hãy kiểm tra chính sách tiếp nhận với ứng dụng khách mà mọi người thực sự dùng. Một người dùng đã đăng ký với mật khẩu, chứng chỉ và mã hiện tại đúng phải kết nối được. Một mã sai, một người dùng không có đăng ký và một tài khoản bị cấm đều phải thất bại, và lý do phải hiển thị trong nhật ký máy chủ. Cho đến khi bạn đã thấy những từ chối đó, bạn có một lời nhắc, không phải một chính sách.