IKEv1 với XAuth và OTP: mỗi lời nhắc đang hỏi điều gì

IKEv1 với PSK, XAuth và OTP không đòi một mật khẩu phức tạp duy nhất. Nó xếp lớp một khóa chia sẻ giữa các peer, một trao đổi người dùng, và một yếu tố thứ hai do phần phụ trợ quyết định cách yêu cầu. Mỗi lớp có chủ riêng và thông báo lỗi riêng. Nhầm lẫn giữa chúng khiến người ta nhập lại mã dùng một lần vào ô lưu bí mật của nhóm.

Hãy gán mỗi lời nhắc cho lớp đã yêu cầu nó trước khi cài ứng dụng khách khác hoặc đặt lại thông tin đăng nhập.

Ba bí mật, ba chủ sở hữu

Khóa chia sẻ trước thuộc về quan hệ giữa các peer và được người quản lý cả hai đầu cấu hình một lần. Thông tin đăng nhập của người dùng thuộc về phần phụ trợ xác thực và được kiểm tra ở mỗi lần đăng nhập. Yếu tố thứ hai thuộc về hệ thống token mà phản hồi thay đổi ở mỗi lần thử. Không cái nào thay thế cái nào, và một triển khai coi cả ba là một mật khẩu sẽ hỏng ở đúng lớp mà không ai ghi lại.

Hãy ghi ra ba cột: chủ sở hữu, thời hạn, và thông báo lỗi mà mỗi cái tạo ra. Bảng đó mới là công cụ chẩn đoán, còn tên trường trong ứng dụng khách thì không.

PSK: của peer, không phải của người

Trong cách bố trí cũ này, khóa chia sẻ trước xác thực cặp cổng, nên thông tin đăng nhập của người dùng không bao giờ thay thế được nó. Đây cũng là giá trị dễ sai theo cách tạo ra lỗi thương lượng chung chung thay vì một lời nhắc. Khi đường hầm hỏng trước khi lời nhắc người dùng xuất hiện, nghi phạm là khóa hoặc các đề xuất.

Thông tin đăng nhập của người dùng không sửa được lỗi giai đoạn một. Xoay vòng nó chỉ làm mất thông tin đăng nhập duy nhất bạn có thể xoay vòng an toàn, và củng cố giả thuyết sai.

XAuth: trao đổi người dùng kiểu cũ

XAuth thêm một trao đổi xác thực người dùng lên trên xác thực peer của IKEv1, và cổng quyết định phần phụ trợ nào kiểm tra nó. Tùy phần phụ trợ đó, trao đổi có thể nhận mật khẩu thư mục, thông tin đăng nhập RADIUS hoặc phản hồi token. Từ XAuth đặt tên cho cách vận chuyển của trao đổi, không phải loại thông tin đăng nhập.

Hãy kiểm tra hồ sơ cổng trỏ tới phần phụ trợ nào. Điều đó cho biết người dùng sẽ được yêu cầu gì và việc đặt lại mật khẩu thực sự thay đổi điều gì, và cả hai đều không hiện ra trong hồ sơ ứng dụng khách.

OTP: phần phụ trợ muốn gì thì theo đó

Một số triển khai yêu cầu một mã dùng một lần riêng sau mật khẩu, còn những triển khai khác định nghĩa một định dạng nhập kết hợp với dấu phân cách được ghi trong tài liệu. Cả hai đều tồn tại, và hồ sơ trước mắt bạn quyết định dùng cái nào. Tự phát minh cách nối chuỗi vì nó từng chạy ở một trang khác là cách phổ biến nhất để đốt một token đăng ký. Chỉ tài liệu của chính cổng mới phân xử được điều này.

Hãy dùng định dạng được ghi trong tài liệu với một ứng dụng khách có thể hoàn tất trao đổi mà cổng đưa ra.

Nơi ranh giới ứng dụng khách cắn

Fortinet ghi rằng FortiClient 7.4.4 trở đi không còn hỗ trợ IKEv1 cho VPN IPsec, đây là ranh giới của sản phẩm và phiên bản chứ không phải việc loại bỏ toàn cầu, như ghi chú tương thích FortiClient ghi lại. Các ứng dụng khách khác cũng không thay thế được cho nhau: OpenConnect và openfortivpn nói những giao thức cổng cụ thể, không phải mọi hồ sơ IKEv1. Hãy kiểm tra riêng phiên bản IKE, chế độ PSK, hỗ trợ XAuth và mô hình tương tác của ứng dụng khách đã cài. Một ứng dụng khách kết nối bằng phương thức khác chưa chứng minh được yêu cầu ban đầu.

IKEv1 đã bị ngừng hỗ trợ, nên một đợt triển khai mới dựa trên ứng dụng khách cũ không còn được hỗ trợ là giải pháp ngắn hạn. Hãy hỏi chủ cổng một lộ trình chuyển đổi được hỗ trợ, kể cả việc yếu tố thứ hai sẽ được xử lý thế nào ở đó.

Chẩn đoán mà không tắt yếu tố

Hãy tách các giai đoạn trong nhật ký: thương lượng peer, trao đổi người dùng, kết quả yếu tố thứ hai, rồi đến gán địa chỉ và tuyến. Ghi lại thành phần và giai đoạn thay vì thử mã ở mọi ô. Tắt yếu tố để một bài kiểm tra chạy qua tạo ra một đường hầm không chứng minh được gì về triển khai.

Hãy giữ bí mật đăng ký và khóa chia sẻ trong kho được bảo vệ theo quy trình của tổ chức. Một mã dùng một lần nằm trong tệp lưu thường trực là yếu tố đã thôi làm yếu tố.