Qual é o sentido da opção “UseDNS” do sshd?

Question

Eu sei o que isso faz, mas não sei por que . Que ataque (s) ele impede?

É relevante para todos os tipos de métodos de autenticação? (baseado em host, senha, publickey, teclado interativo ...)

    

Answer 1

A opção UseDNS é praticamente inútil. Se as máquinas clientes estiverem disponíveis na Internet, há uma grande chance de que elas não possuam nenhum DNS reverso, seu DNS reverso não resolve o problema ou seu DNS não fornece nenhuma informação além de “pertence a este ISP ”que o endereço IP já lhe diz.

Em configurações típicas, o DNS é usado apenas para registro. Pode ser usado para autenticação, mas somente se IgnoreRhosts no for especificado em sshd_config . Isso é para compatibilidade com instalações antigas que usaram rsh, onde você pode dizer “o usuário chamado bob na máquina chamada darkstar pode efetuar login como alice sem exibir nenhuma credencial” (escrevendo darkstar bob in ~alice/.rhosts ). É seguro apenas se você confiar em todas as máquinas que possam estar se conectando ao servidor ssh. Em outras palavras, isso é muito raramente utilizável de maneira segura.

Dado que a pesquisa de DNS não fornece nenhuma informação útil, exceto em circunstâncias muito peculiares, ela deve ser desativada. Tanto quanto eu posso dizer, a única razão pela qual é por padrão é que é tecnicamente mais seguro (se você está preocupado com a autenticação, não a disponibilidade), mesmo que isso se aplique apenas a um pequeno conjunto de circunstâncias.

Outro argumento para desativar esse recurso é que todo recurso supérfluo é desnecessário. risco de segurança .

    

Answer 2

Eu adicionei um relatório de bug (antigo, mas ainda atual) no Ubuntu sobre isso.

link

Eu propus mudar o padrão para Não e adicionar uma nova documentação:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

    

Answer 3

Na página de manual de sshd_config(5) :

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Ativar isso faz o acesso de um local sem o DNS adequado (direto e reverso) gerar um aviso nos logs.

Portanto, isso não impede nenhum ataque, exceto que seria necessário algum endereço remoto qualificado do cliente para não registrar nenhum aviso. Esse aviso pode ajudá-lo a rastrear o invasor somente se esse registro PTR fizer algum sentido.

^{edit: atualizado de acordo com o comentário de Andrey Voitenkov .}

    

Answer 4

É necessário quando você usa a opção FROM em um arquivo authorized_keys e deseja filtrar por nomes e não apenas por IPs.

A opção FROM em uma linha de um arquivo authorized_keys permite que você limite os hosts que podem usar uma chave específica.
Isso aumenta a capacidade de gerenciar vários servidores que têm acesso uns aos outros sem permitir que clones de uma máquina personifiquem sua origem, geralmente de forma não intencional (sobras de crontabs, erro humano).

    

Answer 5

Eu gostaria de acrescentar que no CentOS 7 (7.1.1503) e, portanto, no Red Hat Enterprise Linux 7, eu estava incapaz de logar com a configuração padrão de yes para UseDNS . Depois de descomentar e configurá-lo para no , consegui fazer o login. Assim, parece que se pode de fato ser negado serviço se o DNS não estiver funcionando corretamente! No CentOS 6, parece que o padrão é no e, portanto, posso ssh sem nenhum DNS em funcionamento!

Eu gostaria de acrescentar que minha experimentação foi em contêineres LXC e não em máquinas físicas, no caso de fazer diferença!