OpenSSH Seguro
De Wiki Fedora
OpenSSH (ou Shell Seguro) tornou-se um padrão para o acesso remoto, substituindo o protocolo Telnet. O ssh tornou protocolos tais como o telnet redundantes devido, em maior parte, ao fato de sua conexão ser encriptada e as senhas não serem mais enviadas em texto plano para que todos vejam.
Contudo, uma instalação default do ssh não é perfeita e quando executando um servidor ssh existem alguns simples passos que podem aumentar dramaticamente a força em sua instalação.
Tabela de conteúdo |
Use senhas e nomes de usuários fortes
Uma das primeiras coisas nas quais se deve ficar atento se você tiver um ssh sendo executado e exposto ao mundo exterior é que você, provavelmente, vai gerar logs de tentativas feitas por hackers para adivinhar a sua senha/nome de usuário. Tipicamente, um hacker vai escanear a porta 22 (que é a porta padrão usada pelo ssh) para encontrar máquinas com o ssh rodando para, então, tentar um ataque de força-bruta. Usando senhas fortes, espera-se, qualquer ataque gerará um log e será percebido antes que o invasor tenha sucesso em adivinhar o login/senha.
Provavelmente você já usa uma senha forte, mas caso não use, tente uma (ou várias) das dicas a seguir:
- Mínimo de 8 caracteres
- Mistura de maiúsculas e minúsculas
- Mistura de letras e números
- Caracteres não alfanuméricos (i.e. caracteres especiais, como ! " £ $ % ^ etc)
- Não use palavras que constem em um dicionário
Os benefícios de usar senhas fortes não são específicos somente aos sistemas usando ssh mas para qualquer tipo de aplicação usando logins e senhas. Aplique estas regras a outros sistemas também, na tentativa de aumentar a segurança.
Se você não pode impedir seus usuários de escolherem senhas fracas, pense, então, em usar nomes de usuários gerados aleatoriamente ou difíceis de adivinhar para suas contas de usuário. Se os caras maus não conseguirem adivinhar os nomes de usuário não poderão usar ataques de força-bruta na senha. Em todo caso, confiar em segurança baseada nos nomes de usuários não é recomendado, posto que os usuários podem enviar seus usernames por e-mail e comprometer a segurança
Desative os logins como root
As configurações do servidor ssh ficam armazenadas no arquivo /etc/ssh/sshd_config. Para desativar logins como root, esteja certo de ter as seguintes entratas:
# Prevent root logins: PermitRootLogin no
e reinicie o serviço sshd
service sshd restart
Caso você necessite de acesso como root, logue-se como um usuário normal e depois torne-se root com o comando su.
Limite os usuários com acesso remoto
Os logins no ssh podem ser limitados somente aos usuários que realmente necessitam de acesso remoto. Caso você tenha muitas contas de usuário no sistema, faz sentido ativar o acesso ao ssh somente àqueles que realmente precisam acessar remotamente suas contas, diminuindo, dessa forma, o possível impacto na segurança causado por usuários com senha fracas. Adicione uma linha AllowUsers seguido pelos nomes de usuários com permissão, separados por um espaço ao arquivo /etc/ssh/sshd_config . Por exemplo:
AllowUsers alice bob
e reinicie o serviço sshd.
Desabilite o protocolo 1
O ssh tem dois protocolos, ele pode usar o protocolo 1 ou o protocolo 2. O velho protocolo 1 é menos seguro e deve ser desabilitado; a menos que você precise dele especificamente. Procure pela seguinte linha no arquivo /etc/ssh/sshd_config , descomente-o e edite-o da seguinte forma:
# Protocol 2,1 Protocol 2
e reinicie o serviço sshd.
Use uma porta diferente
Por padrão o ssh aceita conexões pela porta 22. Um hacker pode se valer dessa informação para descobrir se você está usando o ssh em sua máquina e, para isso, vai escanear a porta 22 da sua máquina. Um método bastante efetivo para aumentar a segurança é rodar o ssh em uma porta diferente da porta 22. Qualquer porta não usada serve para este propósito. De fato, qualquer porta acima de 1024 é preferível. Muitos administradores costumam usar a porta 2222 e a porta 8080 pela facilidade de lembrar dos números, mas estas não são boas escolhas, já que, provavelmente, qualquer hacker as escanearia também. Em vez disso escolha qualquer porta com numeração alta e aleatória que não esteja sendo usada por nenhum serviço.
Para que essa configuração seja possível, adicione uma linha como essa ao seu arquivo /etc/ssh/sshd_config :
# Run ssh on a non-standard port: Port 2345 #Change me
e reinicie o serviço sshd.
Não se esqueça de fazer quaisquer modificações necessárias ao seu roteador au às suas regras de firewall
Porque o ssh não está mais aceitando conexões pela porta padrão (22),será preciso que você diga ao seu cliente ssh em qual porta se conectar. Usando o cliente ssh pelo terminal, nós precisamos indicar a porta através da opção -p:
$ ssh -p 2345 myserver
Filtragem do ssh pelo firewall
Caso você somente necessite acesso remoto de um endereço IP (do trabalho para o seu servidor caseiro, por exemplo), considere configurar uma filtragem das conexões em seu firewall criando uma nova regra em seu router ou no iptables de modo a limitar o acesso na porta 22 apenas àquele endereço IP específico. Por exemlo, no iptables isso pode ser feito com o seguinte tipo de regra:
iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
O ssh suporta, nativamente, encapsulamentos e o acesso ao serviço ssh pode ser controlado de forma semelhante usando hosts.allow e hosts.deny.
Se você não for capaz de limitar as fontes de IP porque precisa deixar a porta ssh aberta para todos o iptables ainda pode ajudar a prevenir atques de força-bruta gerando logs e bloqueando tentativas repetidas de login de um mesmo endereço IP. Por exemplo:
iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT
A primeira regra grava os endereços IP de cada tentativa de acssso à porta 22 usando o módulo recent. A segunda regra se aquele endereço de IP tentou conectar-se 4 ou mais vezes durante os últimos 60 segundos; se não, o pacote é aceito. Observe que esta regra pode precisar de uma política padrão do tipo DROP no input chain. Agora, um exemplo usando o módulo limit do iptables para limitar o número de conexões à porta ssh para 3 por minuto:
iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT iptables -A INPUT -p tcp --dport 22 --syn -j DROP
A primeira linha irá aceitar novas conexões na porta 22 por um determinado endereço IP desde que ele não tenha feito mais que 3 tentativas de conexão no último minuto. Se mais que 3 tentativas forem feitas no último minuto, a segunda linha fará um DROP na conexão.
Use chave pública/privada para autenticação
Usar chaves critografadas para autenticação tem dois grandes benefícios. Primeiro, é muito conveniente já que você não terá mais necessidade de entrar um password (a menos que você criptografe as suas chaves por senha) se vc usa chaves públicas/privadas. Em segundo lugar, uma vez que o par de chaves pública/privada é configurado no servidor vocẽ pode desabilitar a autenticação por senha, o que significa que sem uma chave de autorização não é possível conseguir acesso - logo, é impossível tentar crackear suas senhas.
É um processo relativamente simples criar um par de chaves pública/privada e instalá-las para uso no seu servidor ssh. Primeiro, crie um par de chaves pública/privada no cleinte que você deseja usar para se conectar ao servidor (isso deverá ser feito em cada um dos clientes que irão se conectar ao servidor).
$ ssh-keygen -t rsa
Isso irá criar dois arquivos no seu diretório (oculto) ~/.ssh chamados id_rsa e id_rsa.pub. id_rsa é a sua chave privada e id_rsa.pub é a sua chave pública.
Se você não quer ser perguntado por uma senha cada vez que conecta, simplesmente aperte enter quando for perguntado por uma senha na hora de criar o par de chaves. Fica a seu cargo decidir quando criptografar (ou não) sua chave na hora de criá-la. Se você optar por não criptografar a sua chave com senha, isso significa que qualquer um que tenha acesso à sua máquina poderá usá-la para acessar o seu servidor ssh. Também, o root em sua máquina local terá acesso às suas chaves e isso será um grande problema se você não puder confiar no root ou se o root tiver sido comprometido por algum invasor. Criptografar a chave adiciona uma segurança extra ao custo de eliminar a necessidade de senhas na hora de acessar o servidor ssh, mas adiciona, por sua vez, a necessidade de entrar uma senha para conseguir usar a chave.
Agora, ajuste as permissões na sua chave privada:
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/id_rsa
Copie a chave pública (id_rsa.pub) ao servidor e instale-a na lista authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Uma vez que você importou a chave pública, pode deletá-la do servidor
e, finalmente, ajuste as permissões do arquivo no servidor:
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys
As permissões acima são necessárias se o StrictModes estiver ajustado para sim no /etc/ssh/sshd_config (este é o padrão).
Agora, quando você logar no servidor, não será perguntado por uma senha (a menos que tenha criado uma senha para o seu par de chaves quando as criou). Por padrão, o ssh primeiro vai tentar autenticar usando chaves. Se nenhuma chave for encontrada, ou caso a autenticação falhe, o ssh tenta a autenticação por senhas convencional.
Uma vez que tenha sido checado, pode logar com sucesso no servidor usando seu par de chaves pública/privada. A autenticação por senha pode ser desabilitada completamente adicionando-se o seguinte ao seu arquivo /etc/ssh/sshd_config:
# Disable password authentication forcing use of keys PasswordAuthentication no
