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.
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.
A Internet de cabeça para baixo
Versão para impressora
Indicar para um amigo
Enviar artigo