Adicione autenticação por nome de usuário ao Dante

Passe de uma política SOCKS baseada apenas na origem para uma verificação explícita de conta no Dante 1.4.4, mantendo as restrições de origem e destino.

No Dante 1.4.4, as regras de cliente aceitam a conexão antes da negociação SOCKS, enquanto as regras SOCKS decidem quais solicitações autenticadas podem prosseguir. Uma conexão de uma origem permitida ainda pode exigir um nome de usuário na segunda etapa.

Para autenticar com usuários do sistema operacional, examine as identidades do serviço além do método. A leitura do banco de contas pode exigir uma identidade privilegiada:

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

Use a conta de serviço real com poucos privilégios instalada para o Dante. Crie ou escolha uma conta de cliente autorizada e compatível com o backend de nomes de usuário; a identidade do serviço e o login do cliente têm funções diferentes.

Mantenha os limites das solicitações

Depois da regra de cliente restritiva existente, exija a conta na rota SOCKS permitida:

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
}

Os endereços e o nome da conta são valores de exemplo. Isso permite uma origem, um destino, um comando e o usuário autenticado indicado. Não substitua esse limite por origens sem restrições só porque uma senha foi adicionada.

As configurações globais do método e as específicas da regra devem coincidir. Procure uma regra antiga que só permita none e tenha sobrado da configuração baseada apenas na origem. Mantenha também as restrições previstas do listener e do firewall.

Teste a negociação e o acesso separadamente

Antes de iniciar o servidor, verifique o arquivo com o modo de checagem de configuração da versão instalada. Depois use um cliente autorizado que realmente suporte a negociação SOCKS5 com nome de usuário e senha. Teste credenciais ausentes, credenciais incorretas e uma conta permitida solicitando um destino proibido.

A subnegociação de nome de usuário e senha definida na RFC 1929 não criptografa a senha. Uma sessão HTTPS posterior com o destino não protege aquela troca anterior com o proxy. Use um caminho devidamente protegido entre cliente e servidor.

Uma checagem de configuração bem-sucedida confirma a sintaxe e as identidades, não o banco de contas nem o caminho de rede. Consulte os logs do servidor para descobrir em qual etapa um teste real foi rejeitado.

Artigos relacionados