Thêm xác thực bằng tên người dùng cho Dante

Chuyển chính sách SOCKS của Dante 1.4.4 từ truy cập chỉ dựa trên nguồn sang kiểm tra tài khoản rõ ràng, đồng thời giữ các giới hạn nguồn và đích.

Trong Dante 1.4.4, quy tắc máy khách chấp nhận kết nối trước khi thương lượng SOCKS, còn quy tắc SOCKS quyết định yêu cầu đã xác thực nào được tiếp tục. Kết nối từ nguồn được phép vẫn có thể phải cung cấp tên người dùng ở giai đoạn thứ hai.

Khi xác thực bằng tên người dùng của hệ điều hành, hãy xem cả danh tính dịch vụ lẫn phương thức. Việc đọc cơ sở dữ liệu tài khoản có thể cần danh tính có đặc quyền:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Dùng tài khoản dịch vụ ít quyền thực tế đã được cài cho Dante. Tạo hoặc chọn tài khoản máy khách được phép, tương thích với cơ chế xác thực tên người dùng phía sau; danh tính dịch vụ và thông tin đăng nhập của máy khách có vai trò khác nhau.

Giữ giới hạn của yêu cầu

Sau quy tắc máy khách giới hạn sẵn có, bắt buộc dùng tài khoản trên tuyến SOCKS được phép:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

Các địa chỉ và tên tài khoản là giá trị mẫu. Cấu hình này cho phép một nguồn, một đích, một lệnh và người dùng đã xác thực được chỉ định. Đừng thay giới hạn đó bằng nguồn không hạn chế chỉ vì đã thêm mật khẩu.

Cài đặt phương thức chung và cài đặt riêng của quy tắc phải khớp nhau. Kiểm tra xem có quy tắc cũ chỉ cho phép none còn sót từ cấu hình dựa trên nguồn hay không. Giữ cả các giới hạn listener và tường lửa dự kiến.

Kiểm tra thương lượng và quyền truy cập riêng biệt

Trước khi khởi chạy, kiểm tra tệp bằng chế độ kiểm tra cấu hình của máy chủ đã cài. Sau đó dùng máy khách được phép thực sự hỗ trợ thương lượng tên người dùng/mật khẩu SOCKS5. Thử thiếu thông tin đăng nhập, thông tin sai và tài khoản được phép yêu cầu đích bị cấm.

Thương lượng phụ tên người dùng/mật khẩu do RFC 1929 định nghĩa không mã hóa mật khẩu. Phiên HTTPS với đích diễn ra sau đó không bảo vệ lượt trao đổi trước đó với proxy. Dùng đường truyền từ máy khách đến máy chủ được bảo vệ phù hợp.

Kiểm tra cấu hình thành công xác nhận cú pháp và danh tính, không phải cơ sở dữ liệu tài khoản hay đường mạng. Xem nhật ký máy chủ để biết phép thử thực tế bị từ chối ở giai đoạn nào.

Bài viết liên quan