Quais são os possíveis problemas de segurança com um daemon SSH?

Gostaria de poder fazer o SSH para o meu PC do escritório Ubuntu 10.04 de fora. Assim, estou pensando em iniciar um daemon SSH no PC. Quais são os problemas de segurança, possíveis falhas, configurações específicas, etc. Devo estar ciente?

Caso isso importe: isso é essencialmente apenas para meu próprio uso, acho que não haverá outras pessoas usando; é um PC Ubuntu 10.04 em um ambiente predominantemente Windows 7 / Vista / XP.

A maior preocupação seria as pessoas que efetuam login como administrador do computador através do SSH. Isso pode ser feito com força bruta, se você tiver uma senha fácil de adivinhar.

Existem várias medidas de segurança que você pode adotar. Abaixo estão algumas que eu sempre tomo ao configurar um servidor SSH e outras extras.

1. Use uma senha forte, composta por pelo menos (digamos) 10 letras maiúsculas e minúsculas, números e outros caracteres.

2. Prenda os usuários ao diretório inicial. Usuários presos não poderão acessar / editar arquivos que estão fora do diretório inicial. Portanto, seu usuário não poderá acessar / editar os principais arquivos do sistema. Muitos tutoriais podem ser encontrados on-line sobre como prender um usuário. A maioria deles usa o JailKit . Um exemplo desse tutorial pode ser encontrado aqui . Como alternativa, você também pode usar a ChrootDirectorydiretiva nativa do servidor OpenSSH . Um exemplo de um tutorial sobre isso pode ser encontrado aqui .

3. Instale o Fail2Ban . Fail2Ban é um programa que verifica os logs de autenticação quanto a entradas incorretas. Quando um determinado limite é atingido, ele adiciona um bloco de firewall para esse determinado IP por um período predefinido. Também existem vários tutoriais on-line encontrados sobre como configurar o Fail2Ban com SSH, um exemplo seria este . A página inicial do Fail2Ban contém alguns HOWTOs legais e completos também.

4. Desative o logon raiz através do SSH. Este é o usuário que tem acesso a praticamente todos os arquivos do seu sistema, portanto, é recomendável desativar o login do shell. Nas versões mais recentes do Ubuntu, o usuário root é automaticamente desabilitado, mas não custa desativar o acesso SSH de qualquer maneira. Isso é feito editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e verifique se não há # na frente dela.

   #PermitRootLogin no
   

5. Use uma porta não padrão (por exemplo, não 22). Isso é feito através do encaminhamento de porta no seu roteador (por exemplo, 16121 -> 22 em vez de 22 -> 22) ou fazendo o daemon SSH escutar em uma porta diferente. Isso tornará seu serviço SSH menos facilmente detectável por usuários mal-intencionados. Isso é feito editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e mude 22 para a porta que desejar. Não esqueça de encaminhar a porta correta no seu roteador posteriormente.

   Port 22
   

6. Não use senhas para efetuar login. Além de senhas, o SSH também permite o login usando chaves privadas. Isso significa que uma chave está armazenada no seu computador, na qual você acessa o SSH da máquina SSH. Quando uma conexão é tentada, o cliente SSH usa a chave para efetuar login no servidor em vez da autenticação por senha. As chaves de autenticação são muito mais criptografadas do que as senhas e, portanto, não são tão fáceis de decifrar. Existem também vários tutoriais online encontrados sobre como configurar a autenticação baseada em chave com SSH; um exemplo seria esse . (Se você fizer o SSH a partir do Windows com o PuTTY, verifique este link para um tutorial do PuTTY.) Depois de configurar a autenticação baseada em chave, você pode desativar a autenticação de senha editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e verifique se não há # na frente dela.

   #PasswordAuthentication no
   

7. Opcionalmente, como o @ Linker3000 mencionado em seu comentário, você pode configurar um túnel VPN para o PC que deseja acessar através do SSH e, em seguida, proibir o acesso à rede não local no servidor SSH. Dessa forma, nenhum dispositivo externo sem uma conexão VPN poderá acessar seu servidor SSH. Isso pode ser feito negando TODOS os hosts e permitindo apenas o login dos IPs da rede local. Isso é feito editando /etc/hosts.denye adicione o seguinte:

   sshd: ALL
   

   e para /etc/hosts.allowadicionar o seguinte:

   sshd: 192.168.1.*
   

   onde o IP corresponde ao da sua rede local. *é um curinga, portanto, todos os endereços IP iniciados por 192.168.1.serão aceitos. Se isso não funcionar, sua distribuição poderá ser usada em sshvez de sshd. Nesse caso, você deve tentar ssh: 192.168.1.*e ssh: ALLem vez disso.

8. Você só pode permitir hosts específicos, fazer o mesmo com /etc/hosts.allowe /etc/hosts.denyconforme descrito em 6, mas /etc/hosts.allowadicionar a seguinte linha e cada host para permitir separados por espaços:

   sshd: {IP OF HOST TO ALLOW 1} {IP OF HOST TO ALLOW 2} {IP OF HOST TO ALLOW 3} {ETC.}
   

9. Permita que apenas usuários específicos acessem seu servidor SSH. Isso é feito editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e verifique se não há # na frente dela. Se não existir, crie-o. Por exemplo, se você deseja permitir apenas john, tom e mary, adicione / edite esta linha:

   AllowUsers john tom mary
   

   Você também pode negar usuários específicos, por exemplo, se quiser negar acesso a john, tom e mary, adicione / edite esta linha:

   DenyUsers john tom mary
   

10. Permitir apenas o protocolo SSH2 para conexões de entrada. Existem duas versões do protocolo SSH. O SSH1 está sujeito a problemas de segurança, portanto, é recomendável usar o SSH 2. Isso pode ser forçado editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e verifique se não há # na frente dela. Se não existir, crie-o.

    Protocol 2,1
    

    remova o, 1 para que a linha seja

    Protocol 2
    

11. Não permita que usuários façam login sem senha definida. Isso pode ser forçado editando o arquivo /etc/ssh/sshd_config. ^✝ Procure a seguinte linha e verifique se não há # na frente dela. Se não existir, crie-o.

    PermitEmptyPasswords no
    

12. E, embora simples e talvez desnecessário dizer, mas tenha se mostrado crucial em vários casos, mantenha seu software atualizado. Atualize regularmente seus pacotes / software instalados.

^✝ = depois de editar o arquivo de configuração SSH, não se esqueça de reiniciar o daemon para aplicar as alterações. Reinicie o daemon executando:

sudo /etc/init.d/ssh restart

ou

sudo /etc/init.d/sshd restart

dependendo de qual distribuição do Linux você está usando.

Algumas dicas:

1. Use autenticação baseada em chave, que é MUITO MAIS segura do que senhas
2. Apenas SSH 2
3. Desativar logins raiz
4. Para o paranóico, altere a porta da porta padrão 22
5. Por conveniência, use uma ferramenta para mapear seu IP para um nome DNS, como Dyndns ou seu tipo. Você pode passar um longo tempo com o mesmo IP, mas, uma vez que estiver viajando e precisar, verá que recebeu um novo.
6. Obviamente, permita apenas a porta necessária para o SSH (porta 22 ou fora do padrão, se você escolher) através do seu firewall.

O principal risco é esquecer que você está executando um servidor ssh e colocando uma senha fraca em uma conta. Existem invasores que tentam sistematicamente nomes de contas comuns (como webmastere bob) e senhas fracas. Você pode eliminar esse risco, proibindo logins de senha (colocar PasswordAuthentication noem sshd_config, e quer também colocar UsePAM Noou autenticação de senha desativar nas configurações do PAM para o ssh). Uma medida intermediária é restringir os logins ssh a uma lista de permissões de usuários com AllowUsersou AllowGroupsdentro sshd_config.

Observe que permitir logins de senha não é, por si só, um problema de segurança. Senhas fracas e senhas snooped são os problemas, e permitir a autenticação de senha no servidor ssh é um facilitador. Para se proteger contra a espionagem de senha, nunca digite sua senha em uma máquina em que você não confia totalmente (mas, se você confiar em uma máquina, poderá instalar uma chave privada nela e não precisar de autenticação por senha).

O requisito mínimo para usar um cliente ssh em uma máquina é que você confie que não haverá um seqüestro ativo da comunicação ssh (um ataque do tipo intermediário é possível se estiver sendo executado na máquina cliente - você acha você está digitando comandos em um cliente ssh primitivo, mas o cliente está transmitindo seus dados de autenticação fielmente, mas também inserindo um cavalo de tróia na comunicação posteriormente). Esse é um requisito mais fraco do que confiar que não haverá uma invasão de senha (geralmente executada por meio de um keylogger, mas existem outros métodos menos automatizados, como navegação no ombro). Se você tem a confiança mínima, mas ainda tem medo de bisbilhoteiros, pode usar senhas únicas (o OpenSSH as suporta por meio do suporte ao PAM).

Obviamente, como qualquer outro programa que interaja com máquinas fora do seu controle (não apenas servidores de rede, mas também clientes), você deve acompanhar as atualizações de segurança.

Três coisas vieram à minha mente:

1. Se você abrir a porta padrão 22, em breve ela será detectada e seu PC será atacado por ataques de força bruta. Sugiro que você configure o sshd para escutar alguma outra porta ou faça o mapeamento de portas no seu firewall. Embora isso não seja uma bala mágica, você certamente salvará os mesmos ciclos de CPU pelo menos.

   Porta 12345

2. Desative explicitamente a autenticação por senha e use apenas chaves. Qualquer chave será melhor que a senha mais complexa que você consegue lembrar.

   PasswordAuthentication no

3. Mesmo que o Ubuntu tenha o usuário root desativado por padrão, desabilite explicitamente o login root

   PermitRootLogin no