Dịch vụ MFA sập: quyết định quyền truy cập VPN trước khi hỏng

Quyền truy cập VPN dừng lại, và cảnh báo nói rằng dịch vụ yếu tố thứ hai không thể truy cập. Liệu ai đó còn kết nối được hay không là một câu hỏi chính sách đáng lẽ phải được trả lời trước sự cố, không phải trong lúc sự cố. Một trình xác minh không sẵn sàng không phải bằng chứng rằng một yếu tố đã qua, và một thử thách bị từ chối không phải là cùng một sự kiện với một thử thách không thể truy cập. Hướng dẫn dưới đây biến sự khác biệt đó thành một quy tắc bằng văn bản mà bạn có thể kiểm tra.

Bước 1: gọi tên ba kết quả riêng biệt

Viết ra ba trạng thái và từ chối gộp chúng lại: xác thực chính thất bại, thử thách yếu tố thứ hai bị từ chối hoặc hết hạn, và dịch vụ MFA không bao giờ trả lời. Mỗi trạng thái có chủ sở hữu khác nhau, dòng nhật ký khác nhau và phản ứng đúng khác nhau. Một thông báo hết thời gian chung chung che giấu bạn đang ở trạng thái nào, và chính sự mơ hồ đó biến sự cố thành cuộc tranh cãi. Hãy gọi tên các trạng thái trong hướng dẫn trước khi bạn cần đến chúng.

Từ chối nghĩa là trình xác minh đã trả lời và nói không, đó là kết quả chính sách chứ không phải vấn đề khả dụng. Một lần thử hết hạn nghĩa là thử thách đã tồn tại và không ai hoàn thành kịp. Một dịch vụ không thể truy cập nghĩa là câu hỏi chưa bao giờ được trả lời. Chỉ trường hợp thứ ba là sự cố.

Bước 2: đọc chế độ lỗi mà proxy thực sự dùng

Tìm cài đặt điều khiển hành vi khi không thể liên hệ dịch vụ, và đọc nó từ cấu hình đang chạy chứ không phải từ mẫu. Trong proxy RADIUS của Duo, các giá trị failmode được ghi lại là safe và secure, trong đó safe chỉ cho phép một lần thử khi xác thực chính thành công, và secure từ chối lần thử trong điều kiện đó.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Cái tên safe mô tả một lựa chọn khả dụng, không phải bảo đảm rằng mọi phiên được chấp nhận đều có yếu tố thứ hai mới. Câu đó thuộc sổ rủi ro, vì đó chính xác là sự đánh đổi mà cài đặt thực hiện. Đừng khái quát giá trị sang nhà cung cấp khác, tích hợp khác hoặc chế độ proxy khác; hãy đọc tài liệu của sản phẩm đó cho tương đương riêng của nó. Một cấu hình sao chép từ ví dụ của nhà cung cấp mà không có hiểu biết này là một bất ngờ đang chờ sự cố tiếp theo.

Dừng lại nếu không ai có thể nói chế độ nào đang hoạt động. Phần còn lại của hướng dẫn phụ thuộc vào câu trả lời đó.

Bước 3: làm cho các lần thử lại khớp với luồng

Căn chỉnh thời gian chờ và hành vi thử lại của cổng với luồng xác thực mà nó điều khiển. Các lần thử lại không phối hợp tạo ra nhiều lời nhắc, làm rối việc ghép lần thử và khiến nhật ký không thể nói kết quả nào thuộc lần đăng nhập nào. Một thời gian chờ rất dài không phải là thiết kế khả dụng; đó là chờ lâu hơn cho cùng một câu trả lời.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Thời gian chờ yêu cầu của chính proxy là một giới hạn riêng: một yêu cầu xác thực được phát ra và không bao giờ hoàn thành sẽ bị từ chối, và sự từ chối đó không phải là sự cố để lùi về. Hãy coi từ chối, thử thách chưa hoàn thành và dịch vụ không thể truy cập là ba đầu vào khác nhau cho bảng quyết định của bạn. Sau đó làm cho bảng rõ ràng: trạng thái nào chấp nhận, trạng thái nào giữ lại và trạng thái nào được chuyển lên cho con người.

Nếu hai thành phần đều thử lại, trước tiên hãy sửa quyền sở hữu việc thử lại. Lời nhắc trùng lặp là triệu chứng của hai chủ sở hữu, không phải của dịch vụ chậm.

Bước 4: quản trị truy cập khẩn cấp riêng

Nếu cần truy cập khẩn cấp, hãy cho nó phạm vi, danh tính, quyền hạn và dấu vết kiểm toán riêng. Việc âm thầm tắt MFA cho tất cả người dùng không phải là thủ tục khẩn cấp; đó là sự suy yếu vĩnh viễn gắn với một sự cố. Chủ sở hữu bảo mật phê duyệt trước quy tắc chấp nhận, khả năng hiển thị và đường leo thang.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Kiểm tra toàn bộ ma trận trong môi trường không phải sản xuất: lỗi chính, từ chối có chủ đích, hết hạn thử thách và dịch vụ không khả dụng. Với mỗi trường hợp, ghi lại kết quả chấp nhận và lý do đã được ghi nhật ký. Đừng tạo sự cố sản xuất để khám phá hành vi đã cấu hình, và đừng kiểm tra đường khẩn cấp lần đầu trong chính sự cố mà nó được viết ra. Một thủ tục khôi phục chưa bao giờ chạy là tài liệu, không phải kiểm soát.

Hướng dẫn kết thúc khi ba trạng thái được gọi tên, chế độ lỗi được đọc từ hệ thống đang chạy, các lần thử lại có một chủ sở hữu và truy cập khẩn cấp có phê duyệt và xem xét riêng. Thực thi có thể dự đoán cộng với một đường khôi phục đã biết là kết quả đáng được ghi lại.