OpenVPN chỉ hành động dựa trên đúng một đầu ra của tập lệnh đăng nhập: trạng thái thoát. Mọi thứ khác tập lệnh làm chỉ là trang trí. Một hook có thể đến đúng trình xác thực, phân tích phản hồi và in một dòng thân thiện nhưng lại trả về trạng thái mang nghĩa ngược với ý định của tác giả. Hãy đọc hợp đồng trước và viết adapter xoay quanh nó, rồi cả lớp lỗi đó biến mất.

Hợp đồng rất nhỏ: xác định tài khoản đã gửi, hỏi trình xác thực đã được phê duyệt câu hỏi dự định và chỉ chấp nhận kết quả tích cực đã được ghi nhận của chính trình xác thực đó cho yêu cầu ấy. Mọi thứ khác là hạ tầng.

Ba trạng thái mà hook có thể trả về

Đối với auth-user-pass-verify, hướng dẫn OpenVPN 2.6 định nghĩa mã thoát 0 là chấp nhận, 1 là từ chối và 2 là xác thực bị hoãn. Đó là ba câu trả lời duy nhất máy chủ hiểu, và mỗi câu có hệ quả khác nhau cho kết nối. Một tập lệnh thoát với trạng thái của lệnh cuối cùng thực chất đã để một lệnh gọi nhật ký hoặc bước dọn dẹp bỏ phiếu. Hãy ghi trạng thái một cách tường minh ở mọi nhánh, kể cả những nhánh chưa bao giờ đến được trình xác thực.

Thành công HTTP và thành công xác thực là hai tầng riêng biệt, và nhầm lẫn chúng là cách phổ biến nhất khiến hook này sai. Phản hồi 202 nghĩa là yêu cầu đã được nhận để xử lý, không phải mật khẩu đã được xác minh. Hãy định nghĩa trạng thái mong đợi, hình dạng phản hồi và phán quyết cuối cùng từ hợp đồng API mà bạn được cấp, và đừng bịa ra tên trường chỉ vì nó có vẻ hợp lý.

Nếu câu trả lời thực sự đến muộn hơn, đó là đường hoãn và phải được xây dựng như vậy. Một lần thử bị hoãn mà không bao giờ hoàn tất sẽ giữ tài nguyên cho đến khi hết thời gian chờ.

Đọc tệp thông tin xác thực đúng y như nó được ghi

Với phương thức qua tệp đã được ghi nhận, máy chủ ghi tên người dùng và mật khẩu thành hai dòng đầu của một tệp tạm, chuyển đường dẫn đó cho tập lệnh và xóa tệp khi tập lệnh trả về. Hãy đọc hai dòng đó như dữ liệu: không bao giờ source tệp, không bao giờ đánh giá nó và không bao giờ dán nội dung của nó vào một dòng lệnh nơi bảng tiến trình có thể nhìn thấy. Giữ nguyên mật khẩu theo từng byte, vì việc chuẩn hóa như bạn vẫn làm với tên người dùng sẽ âm thầm thay đổi thông tin xác thực. Thư mục dùng cho tệp tạm đó là một quyết định triển khai, nên hãy xác nhận rằng nó tồn tại và không phải ai trên máy chủ cũng đọc được.

Hãy tách thông tin xác thực của chính trình xác thực khỏi thông tin của người dùng: nó thuộc về tích hợp cổng, sống trong kho bí mật của nền tảng và chỉ cần quyền xác minh, nên nó không phải bằng chứng rằng một người cụ thể đã được xác thực. Cũng đừng để hook trở thành trình xác thực mật khẩu thứ hai. Việc viết lại thủ công phép so sánh băm không trở nên an toàn nhờ tối ưu vòng lặp, và một trình xác thực được duy trì đã hiểu sơ đồ muối và chi phí của kho tài khoản.

Hãy quyết định một câu trả lời không thể phân loại nghĩa là gì

Hết thời gian, lỗi truyền tải, phản hồi méo mó và backend không khả dụng có chung một thuộc tính: không cái nào là xác minh tích cực. Hook nên thất bại theo hướng đóng cho từng trường hợp và ghi lại lý do mà người vận hành có thể xử lý. Lý do đó thuộc về nhật ký được bảo vệ, không phải thông báo trả về cho người đang cố kết nối.

Hãy cẩn thận tương tự với những đường không bao giờ đến được trình xác thực. Giá trị cấu hình bị thiếu, bí mật không đọc được hoặc phụ thuộc chưa cài đặt nên tạo ra từ chối với dấu hiệu vận hành riêng biệt thay vì chấp nhận tình cờ. Hãy kiểm thử các nhánh đó bằng cách gỡ phụ thuộc trong phòng thí nghiệm thay vì suy luận về chúng. Ở nơi việc ghi nhật ký thất bại có thể thay đổi trạng thái thoát, việc ghi nhật ký đã trở thành một phần của quyết định và phải được làm cho vô hại.

Cấu hình máy chủ cũng quan trọng ở đây: các tập lệnh do người dùng định nghĩa chỉ được tôn trọng khi cấu hình đang chạy cho phép chúng ở mức bảo mật yêu cầu, và thiết lập đó là lựa chọn có chủ đích chứ không phải giá trị mặc định cần nâng lên.

Hãy xác minh phán quyết, không phải dòng được in

Hãy xây dựng một bài kiểm tra trực tiếp kiểm tra trạng thái thoát. Viết một tệp thông tin xác thực mẫu, chạy hook với nó bằng một tài khoản tốt đã biết và một tài khoản xấu đã biết, và đọc trạng thái mà shell báo cáo thay vì văn bản tập lệnh in ra. Chính lần kiểm tra đó bắt được phần lớn lỗi hợp đồng trước khi máy khách kết nối.

Sau đó chạy các trường hợp tương tự qua một máy khách thật với trình lắng nghe phi sản xuất và xác nhận những gì máy chủ ghi lại: chấp nhận, từ chối hoặc hoãn. Hãy bao phủ tài khoản bị vô hiệu hóa, mật khẩu sai, phản hồi méo mó của trình xác thực, hết thời gian và trình xác thực không thể truy cập. Nếu bất kỳ trường hợp nào rơi vào trạng thái bạn không thể đặt tên, adapter chưa hoàn chỉnh.

Hãy giữ ánh xạ từ kết quả của trình xác thực sang trạng thái thoát bên cạnh tập lệnh trong kho mã, để kỹ sư tiếp theo có thể đọc hợp đồng mà không phải dịch ngược mã.

Bài viết liên quan