sshd warning, “TENTATIVA DE INTERRUPÇÃO POSSÍVEL!” por DNS inverso com falha

Question

Sempre que eu SSH em algum lugar eu recebo algo assim nos logs:

sshd[16734]: reverse mapping checking getaddrinfo for
    1.2.3.4.crummyisp.net [1.2.3.4] failed - POSSIBLE BREAK-IN ATTEMPT!

E é correta: se eu host 1.2.3.4 , ele retorna 1.2.3.4.crummyisp.net , mas se eu faço host 1.2.3.4.crummyisp.net não é encontrado.

Eu tenho duas perguntas:

1. Qual ameaça à segurança existe? Como alguém poderia fingir um DNS unidirecional de alguma forma ameaçadora?

2. Eu tenho algum recurso para corrigir isso? Vou enviar um relatório de bug ao meu provedor, mas quem sabe para onde isso vai.

Answer 1

What security threat is there?
How could anyone fake a one-way DNS in some threatening way?

Qualquer parte com controle de uma zona reversa de DNS pode definir seus registros PTR para o que quiserem. É concebível que alguém possa definir seu registro PTR como legithost.example.com e, em seguida, tentar forçar a entrada de força em seu ambiente.

Se você tem usuários com dedos gordos que tendem a digitar incorretamente suas senhas e não têm medidas de força bruta, um monte de entradas de log para senhas com falha de legithost.example.com pode ser descartado como "Oh, isso é apenas Bob - ele não pode digitar para salvar sua vida! " e dar a um atacante a oportunidade de continuar adivinhando senhas até que elas entrem.

(O benefício de segurança teórico desta mensagem é que o invasor não pode criar / alterar o registro A de legithost.example.com em sua zona DNS, para que ele não possa silenciar o aviso - ausente um ataque de envenenamento de DNS de algum tipo ...)

Do I have any recourse for fixing this?

Opção 1: Corrija seu DNS para que os registros de encaminhamento ( A ) e reverso ( PTR ) correspondam.
Opção 2: Adicionar UseDNS no do arquivo sshd_config do seu sistema para encerrar o aviso.

    

Answer 2

Se HostbasedAuthentication estiver configurado, você pode especificar nomes de host que podem fazer login em /etc/hosts.equiv , ~/.shosts e ~/.rhosts . (Há uma verificação de chave pública no host do cliente também (pode ser um known_host para o servidor)).

Isso pode ser explorado se a chave vazar (nesse caso você já tem um problema) e HostbasedUsesNameFromPacketOnly estiver definido como yes (possivelmente UseDNS no também pode ser necessário) e um invasor, com as chaves relevantes , fornece o nome do host de um host autorizado.

Outro ataque pode ser um servidor conhecido fingindo ser um servidor conhecido diferente para obter maiores privilégios.

Para evitar esses ataques, o DNS reverso e avançado é comparado (e a entrada de log aparece se eles não corresponderem).

A outra coisa que pode ser atacada: o authorized_keys host= paramter e Match block para Host , que pode ser ativado para o host errado no caso de nomes de host serem usados (em vez de endereços IP ) e as entradas de DNS são modificadas. ( UseDNS yes é necessário para usar não-IPs para isso)