Segurança SSH enquanto viaja


2

Eu sou novo no lado sysadmin / IT, por isso peço desculpas se isso pode parecer simples. Tentei pesquisar, mas como o SSH é um campo tão amplo, não sabia quais palavras-chave ou terminologia usar especificamente.

Vou viajar em breve e preciso fazer o SSH no meu servidor EC2 Ubuntu. Atualmente, tenho um IP estático em casa e o UFW configurado para restringir o acesso IP à porta 22. No que diz respeito ao SSH, uso um par de chaves para efetuar login.

Existe alguma maneira de obter um IP estático ou usar algum tipo de VPN e depois fazer o SSH no meu servidor para manter a porta 22 segura? Obviamente, eu não sou a primeira pessoa a viajar enquanto tenho que fazer o SSH em um servidor, então é preciso haver uma solução.

Como afirmei, atualmente mantenho o acesso à porta 22 permitido apenas ao meu IP. Seria arriscado abrir a porta 22 para todo o tráfego? Eu uso um par de chaves para SSH, não um nome de usuário / senha.

Respostas:


5

Manter a porta 22 aberta não é menos segura do que manter a porta 80 aberta no servidor da Web, desde que você esteja usando autenticação de chave pública ou senhas de usuário seguras. Muitas práticas de segurança são mitos infundados. É improvável que existam explorações graves no sshd.

Por que a porta do servidor VPN é subitamente mais segura que a porta SSH? Apenas verifique sua chave pública SSH toda vez que você se conectar para impedir ataques MITM.


Então, isso é um "vá em frente" até a porta 22 de abertura?
user3258348

Sim. Qualquer servidor testado projetado para acesso público deve ser usado dessa maneira.
Monstieur 12/02

2

Exigir uma VPN para SSH é certamente mais seguro; a maneira usual de fazer isso é estabelecer uma rede de gerenciamento (à qual seus servidores tenham uma conexão secundária) e fornecer acesso VPN a ela. Faça com que toda a infraestrutura escute o tráfego de gerenciamento apenas nessa rede. Em seguida, conforme necessário, entre e gerencie a VPN.

Se você tiver apenas um servidor, isso provavelmente é um exagero. Deve ser suficiente usar chaves públicas fortes e garantir que apenas usuários que realmente possuem contas de shell possam se autenticar. Desabilitar a autenticação de senha para SSH nesse caso não é uma má idéia. Para fazer isso, edite /etc/ssh/sshd_confige defina PasswordAuthentication no. Se você estiver usando apenas a autenticação de chave pública, também desabilite o PAM com UsePAM no, pois o PAM pode autenticar usuários com senhas mesmo quando você desabilitou a autenticação de senha no sshd.


Obrigado pela sua resposta. Atualmente, só tenho uma chave sem senha. Só permito acesso à porta 22 do meu IP. Se eu desabilitá-lo e permitir que alguém acesse a porta 22, são grandes as chances de alguém ser capaz de invadir? Basicamente, acho que estou perguntando se não há problema em desativar a restrição de IP da porta 22 enquanto estou viajando e continuar efetuando login via par de chaves?
user3258348

Eles precisariam da chave ou para encontrar um usuário com permissão para usar uma senha (a menos que esteja completamente desativada, como eu recomendo). Essa configuração é bastante segura. É aproximadamente tão seguro quanto uma VPN.
Falcon Momot;

2

Primeiro, algumas dicas gerais de segurança:

  • Use Key logins - você é bom nessa frente
  • use chaves grandes - por exemplo, gere uma chave 4k rsa (provavelmente a atual é 1k ou 2k
  • use uma senha forte para a chave - você deve fazer isso. Se eu puder colocar minhas mãos em sua chave sem palavras não protegida .. tudo está discutível
  • mova ssh para uma porta mais alta - ex. 12322 - isso ajudará a investigar um pouco os serviços. E não se esqueça de abrir a porta no grupo de segurança
  • monitore o que está acontecendo com seu servidor - fail2ban é uma ferramenta maravilhosa
  • desativar logins de senha (existem instruções nas outras respostas)
  • implemente AllowUsers / AllowGroups para permitir apenas usuários específicos (e o root não é um deles) - juntamente com a configuração agressiva do fail2ban, isso é muito bom.

Especificamente para sua pergunta, existem ferramentas conhecidas como PortKnock-ers

Basicamente, você faz algo (como tentar conectar-se a várias portas diferentes em pouco tempo) e uma porta é aberta magicamente nas tabelas de ip.

Algumas leituras sobre esse tópico:

NOTA: Não tenho experiência com portknocking e não o recomendo, pois pode interferir nas operações normais. Chave segura grande e ssh na porta não-padrão são suficientes.


Então, você está sugerindo o uso de uma chave 4K e uma senha para acompanhá-la?
user3258348

Sim, exatamente. O fato de a chave não ter senha não melhora um pouco sua segurança. Ele pode ser stollen, perdido, encontrado, visto e missused
zeridon

1

Você pode configurar um servidor OpenVPN na sua máquina e acessar sua instância através disso. Verifique o link abaixo para configurar o servidor OpenVPN.

http://www.whiteboardcoder.com/2012/12/amazon-aws-vpc-setting-up-openvpn-server.html

Você precisa alterar um pouco o seu grupo de segurança. Atualmente, você tem um IP estático como host permitido para conexões de entrada. Crie um intervalo de IP que corresponda ao intervalo de endereços IP do endereço IP dinâmico do servidor OpenVPN (aquele que você especificar nas configurações de VPN no link acima).

O servidor OpenVPN estará acessível a todos, mas essa conexão é criptografada (https) e protegida pela sua chave de perfil OpenVPN e pela senha da sua conta.


Infelizmente, não estou usando uma instância de VPC. Eu estava planejando lançar um em breve e substituir o atual.
user3258348

0

Eu configuraria uma conta de DNS dinâmico como no-ip ou dynds no seu laptop, então você pode adicionar esse nome de host dyn ao /etc/hosts.allow e bloquear tudo o mais em / etc / hosts / deny.

Dessa forma, você tem seu linux para permitir apenas esse host dinâmico; também pode ser necessário adicionar seu segmento de sub-rede local ao arquivo /etc/hosts.allow.

Felicidades...

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.