ProtectHome so với một hạt giống TOTP: vì sao đăng nhập VPN thất bại

Ứng dụng xác thực hiển thị một mã sáu chữ số mới, VPN từ chối nó, và chính mã đó lại được xác minh tốt khi bạn thử từ shell của chính mình. Khoảng cách đó là toàn bộ câu chuyện. Một mô-đun PAM không mở được bí mật đăng ký sẽ trả về lỗi trông giống hệt mã sai, và môi trường dịch vụ ẩn các thư mục nhà là nguyên nhân phổ biến. Trước khi nới lỏng bất kỳ quyền nào, hãy xác định bạn đang ở tình huống nào trong ba tình huống.

Đây là lỗi nào trong ba lỗi?

Lỗi thứ nhất là bí mật mà mô-đun hoàn toàn không đọc được. Lỗi thứ hai là bí mật mà nó đọc được nhưng không cập nhật được. Lỗi thứ ba là một mã thực sự sai, thường do lệch đồng hồ hoặc một giá trị bị phát lại.

Phân biệt chúng bằng cách đọc nhật ký dịch vụ và nhật ký xác thực của hệ thống cho một lần thử thất bại, rồi xác nhận plugin nạp dịch vụ PAM nào và dịch vụ đó dùng dòng mô-đun nào. Một thông báo lỗi xác thực chung chung không phân biệt được chúng, và một bài kiểm tra thủ công thành công cũng vậy, vì shell của bạn không phải môi trường của dịch vụ.

Góc nhìn hệ thống tệp của unit là thủ phạm thường gặp khi chỉ dịch vụ thất bại.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Tùy chọn A: đưa bí mật ra khỏi thư mục nhà

Khi dịch vụ ẩn /home và bạn muốn giữ biện pháp bảo vệ đó, hãy lưu bí mật ở nơi nó có thể thấy. Mô-đun chấp nhận một đường dẫn secret= và một tài khoản user= thực hiện các thao tác tệp, cho phép một kho lưu trữ trung tâm phục vụ nhiều danh tính.

Đây là tùy chọn gọn gàng, và cũng là tùy chọn cần cẩn thận nhất, vì kho lưu trữ dùng chung biến một thư mục thành ranh giới bảo mật cho mọi tài khoản.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Kiểm tra ba điều trước khi tin tưởng: tài khoản tồn tại, tiến trình làm việc của mô-đun có thể chuyển sang nó, và các tệp thuộc sở hữu của nó với chế độ hạn chế. Đừng dùng ~ hay đường dẫn có biến nhà cùng với user=, và đừng tắt các kiểm tra sở hữu của mô-đun để làm cho một đường dẫn hoạt động. Giữ nguyên giai đoạn mật khẩu và phần còn lại của ngăn xếp.

Tùy chọn B: để tệp lại và mở một đường dẫn

Nếu bí mật phải ở lại thư mục nhà của người dùng, unit cần một góc nhìn bao gồm đúng thư mục đó mà không lộ mọi thư mục nhà trên máy chủ. Một drop-in có thể thêm một bind mount giới hạn hẹp dưới một thư mục nhà đã sandbox.

Điều này giữ quyền sở hữu theo từng người dùng làm mô hình, với cái giá là một thay đổi unit phải được xem xét lại mỗi khi sandbox thay đổi.

Hai giới hạn dễ bị bỏ qua. Một đường dẫn chỉ đọc được thêm dưới một thư mục mà sandbox ẩn đi sẽ không làm lộ nó, vì thư mục cha đơn giản là không có ở đó. Và mount phải ghi được nếu mô-đun cần cập nhật trạng thái, điều này đưa tùy chọn tiếp theo vào cuộc. Viết drop-in thành một tệp riêng thay vì sửa unit đã đóng gói dưới /usr/lib, để một bản nâng cấp gói không âm thầm hoàn tác nó.

Tùy chọn C: giữ sandbox và sửa các lần ghi trạng thái

Đọc bí mật chỉ là một nửa của xác thực. Mô-đun có thể ghi lại thông tin lệch thời gian, bảo vệ chống phát lại hoặc một bộ đếm, và một tệp vượt qua kiểm tra đọc vẫn có thể thất bại khi ghi.

Lỗi đó trông giống mã sai ở lần thử tiếp theo chứ không phải lần này, nên nó bị nhầm với lệch đồng hồ.

Hãy cho nó một thư mục ghi được riêng và trỏ đường dẫn bí mật tới đó, thay vì làm cho toàn bộ thư mục nhà ghi được. Xác nhận chủ sở hữu thư mục, dung lượng trống của hệ thống tệp và việc unit có hạn chế ghi ở nơi khác hay không. Sau đó thử hai lần đăng nhập liên tiếp, vì lần thứ hai chứng minh đường dẫn ghi còn lần thứ nhất chỉ chứng minh việc đọc.

Xác minh với tư cách dịch vụ, không phải với tư cách chính bạn

Mọi kiểm tra quan trọng phải chạy bên trong sandbox của unit với danh tính của unit.

Một lệnh thành công với quyền root chỉ cho biết tệp tồn tại và không hơn thế. Một lần đăng nhập qua dịch vụ thực sẽ cho biết mô-đun có đọc được bí mật, dùng nó và ghi lại những gì cần thiết hay không.

Cuối cùng, hãy giữ nguyên yêu cầu. Thêm tùy chọn mật khẩu rỗng, chấp nhận lỗi chỉ đọc hoặc bỏ sandbox đều sẽ làm triệu chứng biến mất bằng cách thay đổi chính sách. Người dùng bắt buộc phải trình mã vẫn nên bị từ chối khi không thể tiếp cận bí mật.