É inseguro deixar aberta uma conexão SSH?

4

Estou executando um servidor virtual Ubuntu em um local remoto, e várias pessoas têm acesso SSH ao servidor por razões de web-dev e outras várias coisas. Quando configuro o servidor, defino vários parâmetros, incluindo 'TMOUT = 1800', fazendo com que todas as sessões SSH sejam encerradas após 30 minutos de inatividade.

Um dos meus desenvolvedores da web está constantemente me pedindo para desligar o tempo limite porque ele 'continua sendo desconectado do servidor' e não gosta de ter que digitar sua senha a cada 30 minutos.

Ativei o tempo limite por motivos de segurança, para não permitir que as sessões SSH permanecessem abertas por períodos de tempo maiores que o necessário, pois é uma conexão aberta com o servidor com acesso raiz.

O desenvolvedor está discutindo comigo que é perfeitamente correto deixar a conexão aberta o tempo todo, o que, imagino, não é uma coisa boa.

Devo desativar o Tempo limite do SSH (não há problemas em deixar as conexões SSH inativas abertas)? Ou devo dizer a ele para lidar com isso? Raciocínio?

    
por Matt Clark 23.01.2013 / 23:46

3 respostas

4

Eu não acredito que deixar a conexão aberta é mais arriscado do que ter o SSH disponível em primeiro lugar.

Se qualquer coisa, pode-se argumentar que conexões repetidas representam mais um risco. Mas isso é altamente teórico baseado no possível sniffing das tentativas de conexão na rede.

O risco principal mais realista de deixar a conexão aberta é a possibilidade de o PC cliente ser comprometido enquanto a conexão estiver aberta. Portanto, seria sensato definir o tempo limite para um período razoável, como 4, 8 ou 12 horas, dependendo dos padrões de uso e da sensibilidade dos dados no sistema host.

4 horas permitem um trabalho normal de 1/2 dia. 8 horas por dia de trabalho nominal e 12 horas por um trabalho de dia decorrido mais realista. Em um serviço de conexão remota que estou ajudando a especificar, acabei de solicitar que as conexões remotas sejam mantidas abertas por 12 em vez de 8 horas para corresponder a um dia decorrido de trabalho mais normal. Eu realmente não vejo isso como um risco aumentado desde o bloqueio automático do PC do cliente após 5 minutos de inatividade e há uma instrução permanente para bloquear manualmente o PC ao se afastar da mesa.

    
por 24.01.2013 / 00:49
1

Se os usuários do ssh tiverem privilégios de superusuário. Em seguida, a questão se torna "os usuários têm um bloqueio de tela ou outra medida de segurança para impedir que outra pessoa fique sentada no computador e acessando o shell?".

É possível, em uma situação de escritório em plano aberto, que um colega de trabalho sente-se na mesa de outro funcionário para desligá-lo e, inadvertidamente, desligar o servidor.

Um usuário com má intenção pode criar uma conta de usuário ou alterar senhas para contas existentes para obter acesso em uma data posterior.

etc ... etc ...

Portanto, existem problemas de segurança para deixar as conexões ssh abertas por longos períodos de tempo se a estação de trabalho não estiver protegida de pessoas não autorizadas.

Penso, pergunte ao desenvolvedor se ele está disposto a assumir a responsabilidade por todos os funcionários da empresa e se qualquer tentativa de invasão for feita em qualquer estação de trabalho que não tenha sido atendida, ele se tornaria a única pessoa responsável pelos danos causados! ?

Não há risco de invasão de senha ou interceptação ssh como tal, definindo o tempo limite que você está protegendo a empresa contra estações de trabalho inseguras e oportunistas que tirariam proveito do shell não supervisionado com privilégios prejudiciais.

    
por 24.01.2013 / 02:04
0

Se a segurança é um fator, não, você não deve desabilitar os tempos limite. A conveniência de um desenvolvedor não supera a necessidade de segurança básica. Não é permitido deixar uma conexão aberta o tempo todo. Ele está sentado em sua mesa o tempo todo em que ele está conectado? E se ele for embora por uma hora para o almoço e alguém se sentar e tiver uma conexão aberta?

    
por 24.01.2013 / 02:25