De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
Colaboração: Rubens Queiroz de Almeida
Data de Publicação: 29 de junho de 2010
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.
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
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.
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 e 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
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.
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)
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
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.
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
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.
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.
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários