Dante에 사용자 이름 인증 추가하기

출발지와 목적지 제한을 유지하면서 Dante 1.4.4 SOCKS 정책을 출발지만 확인하는 접근 제어에서 명시적인 계정 확인으로 바꿉니다.

Dante 1.4.4에서는 클라이언트 규칙이 SOCKS 협상 전에 연결을 허용하고, SOCKS 규칙이 인증된 요청 중 무엇을 계속 처리할지 결정합니다. 허용된 출발지에서 온 연결도 두 번째 단계에서 사용자 이름을 요구할 수 있습니다.

운영체제 사용자 이름으로 인증하려면 인증 방식과 함께 서비스의 실행 주체도 살펴보세요. 계정 데이터베이스를 읽으려면 권한이 높은 실행 주체가 필요할 수 있습니다.

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

Dante용으로 설치된 실제 저권한 서비스 계정을 사용하세요. 사용자 이름 백엔드에 맞는 허가된 클라이언트 계정을 만들거나 선택합니다. 서비스 실행 주체와 클라이언트 로그인은 서로 다른 역할입니다.

요청의 허용 범위 유지하기

기존의 좁게 제한된 클라이언트 규칙 다음에, 허용된 SOCKS 경로에서 계정을 요구하도록 설정합니다.

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
}

주소와 계정 이름은 예시 값입니다. 이 설정은 출발지 하나, 목적지 하나, 명령 하나와 지정된 인증 사용자만 허용합니다. 비밀번호를 추가했다는 이유만으로 이 경계를 없애고 출발지를 무제한으로 허용하지 마세요.

전역 인증 방식과 규칙별 인증 방식 설정은 일치해야 합니다. 출발지만으로 허용하던 설정에서 none만 허용하는 옛 규칙이 남아 있는지 확인하세요. 의도한 리스너와 방화벽 제한도 유지합니다.

협상과 접근을 따로 시험하기

서버를 시작하기 전에 설치된 서버의 설정 검사 모드로 파일을 확인합니다. 그런 다음 SOCKS5 사용자 이름/비밀번호 협상을 실제로 지원하는 허가된 클라이언트를 사용하세요. 인증 정보 누락, 잘못된 인증 정보, 허용된 계정의 금지된 대상 요청을 시험합니다.

RFC 1929의 사용자 이름/비밀번호 하위 협상은 비밀번호를 암호화하지 않습니다. 나중에 목적지와 맺는 HTTPS 세션은 그보다 앞선 프록시 교환을 보호하지 않습니다. 클라이언트에서 서버까지 적절히 보호된 경로를 사용하세요.

설정 검사 성공은 문법과 실행 주체를 확인할 뿐, 계정 데이터베이스나 네트워크 경로를 보장하지 않습니다. 실제 시험이 어느 단계에서 거절되었는지 서버 로그를 살펴보세요.

관련 글