Truques para realmente proteger conexões SSH

2

Sei que o SSH é seguro, desde que você não esteja sofrendo um ataque MITM, mas quero saber se há uma maneira de tornar o SSH 100% seguro mesmo nessas circunstâncias, descubra que você está sendo inspecionado e desconectado antes de qualquer ataque. informações confidenciais são divulgadas, ou pelo menos não são impossíveis, mas "mais difíceis" para o invasor ler / escrever dados reais (talvez haja uma maneira de distorcer os dados para que não faça sentido ou algo assim?). / p>

Eu acho que você conseguiu o que eu quero.

Por exemplo, se você se recusar a se conectar caso a impressão digital não seja a que você esperava, o MITM ainda funcionará?

Vou tentar atualizar esta pergunta se surgirem ideias na minha mente.

    
por Guilherme Vieira 20.04.2011 / 21:50

2 respostas

5

discover you're being sniffed

Isso é exatamente o que o SSH protege contra. Contanto que você verifique cuidadosamente a chave do host, não importa se alguém está lendo seu tráfego: tudo é criptografado.

disconnecting before any sensitive information is disclosed

Novamente, o SSH padrão ficará bem. A verificação da chave do host é uma das primeiras tarefas feitas ao estabelecer uma conexão SSH; se você cancelá-lo, a conexão é fechada imediatamente sem transmitir nenhum dado de autenticação.

For example, if you refuse to connect in case the fingerprint isn't the one you expected, do MITM still work?

O atacante não receberá dados SSH "privados", se é isso que você quer dizer. Veja acima - a verificação da chave do host é uma das primeiras coisas feitas. Nada mais é enviado até que o servidor seja verificado.

maybe there's a way of garbling the data so it doesn't make sense or something?

Ele é chamado de "criptografia" e acontece de ser uma parte essencial do SSH. :) O atacante não poderá ler nada a menos que você aceite o seu hostkey em vez do real. Da mesma forma, a criptografia junto com a verificação de integridade (usando o HMAC) torna impossível inserir pacotes.

Eu admito que não sou um criptógrafo nem nada. Mas, IMHO, se você verificar cuidadosamente a impressão digital da chave do host, o SSHv2 será o mais seguro possível.

  • Se não fosse seguro, ele teria sido corrigido / substituído / atualizado. Isso aconteceu uma vez: o SSH v1 foi substituído pelo SSH v2.

  • Isso significa que você deve desativar o SSH v1 no servidor e no cliente.

    A versão 1 do SSH é muito insegura e, embora a maioria dos clientes esteja configurada para usar o SSHv2 primeiro, eles ainda retornam à v1 se um servidor não oferecer a v2. Isto introduz uma oportunidade para um ataque MITM ... embora eu não me lembre dos detalhes, tem algo a ver com o atacante gerando uma chave v1 com uma impressão digital muito similar.

    Para o OpenSSH, coloque Protocol 2 no seu arquivo de configuração.

  • Existe uma pequena possibilidade de um dos algoritmos usados pelo SSH ser quebrado. Mas se alguém conseguir quebrar RSA ou DH, o mundo terá problemas maiores para se preocupar do que a segurança do seu servidor ... (Além disso, existem algoritmos alternativos).

A propósito, o OpenSSH v5.8 mudou de DH e DSA para ECDH e ECDSA como seus algoritmos primários (para troca de chaves e chaves de host, respectivamente).

    
por 20.04.2011 / 22:27
-1

O SSH NÃO é bom, é propenso ao ataque man-in-the-middle.

A Microsoft está fazendo um "ataque" em sua conexão se houver um firewall do Forefront TMG entre você e o servidor que você tenta acessar. E isso inclui a falsificação de certificados SSH.

    
por 11.07.2012 / 09:47