você está aqui: Home  → Arquivo de Mensagens

Dicas avançadas de segurança para SSH

Colaboração: Rubens Queiroz de Almeida

Data de Publicação: 29 de junho de 2010

Este artigo foi traduzido e adaptado a partir do original, publicado no site Linux.com, chamado Advanced SSH security tips and tricks, de autoria de Anze Vidmar. A versão traduzida para o português foi originalmente publicada no site SegurancaLinux.com.

Neste artigo irei demonstrar alguns truques simples para ajudá-lo a aperfeiçoar a segurança do seu serviço SSH.

O arquivo de configuração do servidor SSH fica em /etc/ssh/sshd_conf. Você precisará reiniciar o serviço SSH após cada mudança que fizer no arquivo para que as alterações sejam efetivadas.

Técnicas para melhoria da segurança do serviço SSH

Alterar a porta em que o servidor SSH ouve

Por default, o serviço SSH atende conexões na porta 22. Invasores usam software de scan de portas para identificar se os computador está rodando o serviço SSH. É recomendável mudar esta porta para um valor acima de 1024, visto que a maioria dos scanners de portas (inclusive o nmap), por default, não analisam portas altas.

Edite o arquivo /etc/ssh/sshd_config e procure por uma linha como:

  Port 22

Altere o número da porta e reinicie o serviço SSH:

  # /etc/init.d/ssh restart

Permita apenas SSH protocolo 2

Existem duas versões do protocolo SSH. Usar apenas a versão 2 do protocolo SSH é muito mais seguro; a versão 1 do protocolo SSH está sujeita a problemas de segurança, inclusive o ataque man-in-the-middle e ataques de inserção.

Edite o arquivo /etc/ssh/sshd_config e procure por uma linha com o seguinte conteúdo:

  Protocol 2,1

Mude a linha para que especifique apenas a versão 2 do protocolo SSH.

Permita o login via SSH apenas para determinados usuários

Você não deve permitir login do usuário root via SSH, pois é um risco de segurança grande e desnecessário. Se um atacante consegue logar como root em seu sistema, ele pode causar mais danos do que se conseguisse acesso como um usuário comum.

Configure seu servidor SSH de modo a impedir que o usuário root consiga fazer o login diretamente. Encontre a linha abaixo:

  PermitRootLogin yes

Mude o valor yes para no e reinicie o serviço. Você poderá fazer o login como qualquer outro usuário definido e mudar para o usuário root se precisar executar tarefas restritas ao superusuário.

É aconselhável criar um usuário local sem nenhum privilégio no sistema usar este usuário para fazer o login com SSH. Desta forma, nenhum prejuízo poderá decorrer se a conta deste usuário for comprometida. Ao criar este usuário certifique-se de que pertence ao grupo wheel, de forma a que ele possa se tornar o superusuário.

Se você deseja ter uma lista de usuários que são os únicos a poderem logar via SSH, você pode especificar estes usuários no arquivo de configuração sshd_config. Por exemplo, digamos que eu queira permitir que os usuários anze, dasa e kimy possam logar via SSH. Ao final do arquivo sshd_config adicione uma linha como abaixo:

  AllowUsers anze dasa kimy

Criar um banner customizado para o SSH

Se você quiser que qualquer usuário que se conecte através de seu serviço SSH veja uma mensagem específica, você pode criar um banner SSH customizado. Basta criar um arquivo de texto (em meu exemplo este arquivo se chama /etc/ssh-banner.txt) e escrever dentro dele qualquer mensagem que desejar; por exemplo:

  *****************************************************************
  * Este é um serviço SSH privado. Não é para você estar aqui     *
  * Por favor, saia imediatamente.                                *
  *****************************************************************

Ao terminar a edição, salve o arquivo. No arquivo sshd_conf, procure por uma linha que diz:

  #Banner /etc/issue.net

Descomente a linha e coloque o caminho para o seu banner SSH customizado.

Usando chave pública DSA para autenticação

Ao invés de usar nomes de login e senhas para autenticação via SSH, você pode usar chaves públicas DSA. Observe que você pode ter tanto nomes de login e autenticação por chaves públicas DSA habilitados ao mesmo tempo.

Ter a autenticação por chaves públicas DSA habilitadas torna o seu sistema a prova de balas para ataques de dicionário, porque você não precisa de um nome de login e senha para se logar no serviço SSH. Ao invés disto, você precisa de um par de chaves DSA -- uma pública e uma privada. Você mantém a chave privada na sua máquina e copia a chave pública para o servidor. Quando você quiser estabelecer uma sessão SSH, o servidor verifica as chaves, e se elas baterem, você recebe uma shell. Se as chaves não baterem, você é desconectado.

Neste exemplo, a máquina pessoal (a partir da qual me conectarei ao servidor) é station1 e a servidora é server1. Em ambas as máquinas eu tenho o mesmo diretório home; isto não irá funcionar se os diretórios home são diferentes nas máquinas cliente e servidor. Primeiro, você precisa criar um par de chaves em sua máquina pessoal com o comando:

  $ ssh-keygen -t dsa

Você precisará especificar uma frase para sua chave privada, mas você pode deixá-la em branco, o que não é recomendável. Um par de chaves é gerado. Sua chave privada será gravada em ~/.ssh/id_dsa e sua chave pública será gravada em .ssh/id_dsa.pub.

A seguir, copie o conteúdo de ~/.ssh/id_dsa.pub para server1, para o arquivo ~/.ssh/authorized_keys. O conteúdo de ~/.ssh/id_dsa.pub deve ser algo como:

  $ cat .ssh/id_dsa.pub
  
  ssh-dss AAAAB3NzaC1kc3MAAACBAM7K7vkK5C90RsvOhiHDUROvYbNgr7YEqtrdfFCUVwMWcJYDusNG
  AIC0oZkBWLnmDu+y6ZOjNPOTtPnpEX0kRoH79maX8NZbBD4aUV91lbG7z604ZTdrLZVSFhCI/Fm4yROH
  Ge0FO7FV4lGCUIlqa55+QP9Vvco7qyBdIpDuNV0LAAAAFQC/9ILjqII7nM7aKxIBPDrQwKNyPQAAAIEA
  q+OJC8+OYIOeXcW8qcB6LDIBXJV0UT0rrUtFVo1BN39cAWz5puFe7eplmr6t7Ljl7JdkfEA5De0k3WDs
  9/rD1tJ6UfqSRc2qPzbn0p0j89LPIjdMMSISQqaKO4m2fO2VJcgCWvsghIoD0AMRC7ngIe6btaNIhBbq
  ri10RGL5gh4AAACAJj1/rV7iktOYuVyqV3BAz3JHoaf+H/dUDtX+wuTuJpl+tfDf61rbWOqrARuHFRF0
  Tu/Rx4oOZzadLQovafqrDnU/No0Zge+WVXdd4ol1YmUlRkqp8vc20ws5mLVP34fST1amc0YNeBp28EQi
  0xPEFUD0IXzZtXtHVLziA1/NuzY= anze@station1.example.com

Se o arquivo ~/.ssh/authorized_keys já existir, adicione o conteúdo do arquivo ~/.ssh/id_dsa.pub ao arquivo ~/.ssh/authorized_keys em server1. A única coisa que resta fazer é definir as permissões de leitgura e gravação corretas para o arquivo ~/.ssh/authorized_keys em server1.

  $ chmod 600 ~/.ssh/authorized_keys

Agora, configure o arquivo sshd_conf para usar as chaves de autenticação DSA. Certifique-se de que as linhas a seguir estão descomentadas:

  RSAAuthentication yes
  PubkeyAuthentication yes
  AuthorizedKeysFile %h/.ssh/authorized_keys

Reinicie o serviço. Se você configurou tudo corretamente, você deve poder efetuar conexões SSH para o seu servidor e cair diretamente no seu diretório home, sem a necessidade de qualquer tipo de interação.

Se você deseja habilitar apenas a autenticação DSA, certifique-se de descomentar e alterar a linha PasswordAuthentication no arquivo sshd_config de yes para no:

  PasswordAuthentication no

Se alguém tentar se conectar ao seu serviço SSH e não possuir uma chave pública no servidor, ele será rejeitado sem ao menos ver o prompt de login, com o seguinte erro:

  Permission denied (publickey)

Usando TCP Wrappers para permitir a conexão de hosts específicos

Esta técnica é útil se você deseja autorizar que apenas hosts específicos em uma rede se conectem ao seu serviço SSH, mas você não quer usar ou estragar a sua configuração do iptables. Ao invés disto, você pode usar TCP wrappers; neste caso, o wrapper sshd.

Criarei uma regra para autorizar a conexão ao meu serviço SSH apenas para hosts em minha subrede local 192.168.1.0/24 e para o host remoto 193.180.177.13.

Por default, TCP Wrappers primeiro consultam o arquivo /etc/hosts.deny para ver quais hosts não podem acessar qual serviço. Em seguida, consultam o arquivo /etc/hosts.allow para verificar se existe alguma regra que permite que determinados hosts se conectem a serviços específicos. Criarei uma regra como esta no arquivo /etc/hosts.deny:

  sshd: ALL

Isto significa que, por default, todos os hosts são proibidos de acessar o serviço SSH. Preciso fazer esta especificação, pois caso contrário, todos os hosts teriam acesso ao serviço SSH, pois o TCP Wrappers primeiro consulta o arquivo hosts.deny e se não existir nenhuma regra bloqueando o serviço SSH, qualquer host poderá se conectar.

Em seguida, crie uma regra em /etc/hosts.allow para autorizar apenas hosts específicos (como definido anteriormente) a usar o serviço SSH:

  sshd: 192.168.1 193.180.177.13

Agora, apenas hosts da rede 192.168.1.0/24 e o host 193.180.177.13 poderão acessar o serviço SSH. Todos os outros hosts serão desconectados antes mesmo de chegar ao prompt de login, e receberão um erro como abaixo:

  ssh_exchange_identification: Connection closed by remote host

Usando iptables para autorizar a conexão de hosts específicos

Uma alternativa ao TCP Wrappers (embora você possa usar os dois ao mesmo tempo) é limitar o acesso ao serviço SSH com iptables. Aqui está um exemplo simples de como você pode autorizar apenas um host específico a se conectar usando o seu serviço SSH:

  # iptables -A INPUT -p tcp -m state --state NEW --source 193.180.177.13 --dport 22 -j ACCEPT

Certifique-se de que ninguém mais tenha acesso ao serviço SSH:

  # iptables -A INPUT -p tcp --dport 22 -j DROP

Salve as suas novas regras e pronto.

SSH time-lock

Você pode usar parâmetros diferentes do iptables para limitar as conexões ao seu serviço SSH por períodos de tempo pré-determinados. Você pode usar as diretivas /second, /minute, / hour ou /day, em qualquer dos exemplos abaixo.

No primeiro exemplo, se o usuário fornece a senha errada, seu acesso ao serviço SSH é bloqueado por um minuto, e o usuário só pode tentar um login por minuto a partir daquele momento:

  # iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
  # iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -j DROP

Em um segundo exemplo, iptables é configurado para permitir que apenas o host 193.180.177.13 se conecte ao serviço SSH. Depois de três tentativas mal sucedidas, o iptables permitirá apenas uma tentativa de login por minuto:

  # iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state NEW --dport 22 -m limit --limit 1/  minute --limit-burst 1 -j ACCEPT
  # iptables -A INPUT -p tcp -s 193.180.177.13 -m state --syn --state NEW --dport 22 -j DROP

Conclusão

Estes recursos não são difíceis de serem configurados, mas são técnicas poderosas para melhorar a segurança de seu serviço SSH. É um pequeno preço a ser pago para uma boa noite de sono.



Veja a relação completa dos artigos de Rubens Queiroz de Almeida

 

 

Opinião dos Leitores

Leonardo Lemos
10 Fev 2015, 23:37
Excelente, contra segurança não se brinc
Weberth
17 Abr 2014, 15:10
Ótimas dicas, Muito úteis!
Jordano
24 Jul 2010, 23:50
Dicas excelentes, bom trabalho pessoal...
*Nome:
Email:
Me notifique sobre novos comentários nessa página
Oculte meu email
*Texto:
 
  Para publicar seu comentário, digite o código contido na imagem acima
 


Powered by Scriptsmill Comments Script