Implementando segurança no SSH

Compartilho através deste artigo algumas dicas valiosas para aumentar o nível de segurança do acesso SSH ao seu servidor.

[ Hits: 20.759 ]

Por: Thiago Henrique de Lima em 19/06/2012


Utilize sempre um firewall ou Port Knocking



Bloquear a porta do SSH diretamente no firewall de sua rede ou no firewall local do servidor é uma implementação altamente recomendável, pois faz com que tentativas de invasões através do SSH sequer cheguem ao servidor.

Esta implementação não será um problema caso você tenha um IP fixo. Porém, caso você utilize um IP dinâmico não é uma solução viável para você. É para casos como estes que eu recomendo o uso de técnicas de Port Knocking! :)

Port Knocking, do inglês "batendo na porta", significa justamente isto! A sua porta 22 (ou a porta onde você alocou seu SSH) ficará fechada para qualquer origem.

Para liberá-la, ao invés de alterar configurações do firewall local, você simplesmente irá "bater" em outras portas numa sequência pré-determinada, em um determinado período de tempo. Se você acertar a sequência de portas nas quais deverá "bater" - ou seja, realizar conexões - dentro de um determinado período de tempo, a porta do SSH será liberada para você.

Para implementação deste tipo de técnica, você pode implementar regras de iptables "na mão", ou pode utilizar um serviço do GNU/Linux próprio para isto, o knockd.

Como a implementação do knockd não é tão complexa, mas, foge do escopo central deste post, deixo para você a dica de leitura deste artigo, que ensina como implementá-lo.

Utilize somente a versão 2 do protocolo SSH

Qualquer software tem suas falhas de segurança, que são corrigidas no decorrer da transição de versões. Com o SSH não é diferente, e na primeira versão dele, existem vulnerabilidades que eventualmente alguém pode tentar explorar em seu servidor.

Então, porque manter uma versão antiga do protocolo? Configure o seu servidor para aceitar somente conexões utilizando a versão 2 do protocolo:

# vim /etc/ssh/sshd_config

Protocol 2

Agora é só reiniciar o serviço de SSH e seu servidor não aceitará mais conexões utilizando a versão 1 do protocolo! :)

# /etc/init.d/sshd restart

Conclusão

Lembre-se sempre: segurança é um processo constante! Não se contente somente com a implementação destas dicas, ou de outras medidas de segurança. Se atualize sempre, audite seu servidor com frequência, procure brechas, leia listas de segurança.

Desde modo você estará contribuindo para minimizar as chances de ser a próxima vitima de uma exploração de alguma vulnerabilidade de segurança!

Espero ter contribuído para que de alguma maneira você possa tornar o seu SSH mais seguro através destas dicas.

Até a próxima! :)

Página anterior    

Páginas do artigo
   1. Introdução
   2. Restrinja o acesso à usuários específicos com as diretivas AllowGroups e AllowUsers
   3. Utilize sempre um firewall ou Port Knocking
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Procedimento para descoberta de chave WEP

Matriz <-> Filial com o OpenVPN

PacketFence em Debian 6

Malware, Vírus e Hacking. Estamos seguros usando Linux?

IDS com Debian 4, Snort 2.8.3.1 e BASE 1.4.1

  
Comentários
[1] Comentário enviado por fabio em 19/06/2012 - 08:14h

Belas dicas! Conteúdo simples, mas extremamente útil.

[2] Comentário enviado por eldermarco em 19/06/2012 - 09:48h

Muito bom! Vou seguir essas dicas e implementar isso nos PCs da minha casa.

[3] Comentário enviado por silent-man em 19/06/2012 - 10:23h

Boas dicas

Apenas para acescentar:

Na diretiva AllowUsers é possível especificar de onde(de qual ip, estação, host, etc...) determinado usuário poderá fazer acesso ssh.

Ex:

AllowUsers gleison@minhaestacao.com.br gleison@10.1.1.10

Assim, o usuário gleison só poderá fazer conexões ssh oriundas dos hosts 10.1.1.10 ou minhaestacao.com.br.

Esta configuração foi muito importante em um abiente de Oracle Rac. Onde o usuário oracle NECESSITA acesso em ambos os nós utilizando troca de chaves. Então foi permitido acesso SSH do usuário oracle apenas entre os hosts Oracle Rac.

Sds;

[4] Comentário enviado por danniel-lara em 19/06/2012 - 12:59h

Muito bom o artigo , Parabéns

[5] Comentário enviado por JoseHenriqueRJ em 19/06/2012 - 17:15h

Muito bom.
Aqui na empresa nós utilizamos o Pegeant com chave+senha. Nada além disso!
Boa dica!

[6] Comentário enviado por cristianovicosa em 21/06/2012 - 22:19h

Muito bom!

[7] Comentário enviado por m4cgbr em 24/06/2012 - 03:25h

THenrique

Deu certo, conectei normalmente, porém quando execute o comando: su - por exemplo diz que eu não tenho permissão?

Porque isso ocorre? Sei que se adicionar meu usuário no /etc/sudoers resolvo, porém o pessoal do DC não tem seus usuários arquivo sudoers e tem permissão total.

Agradeço quem puder me dar uma dica.

T+

[8] Comentário enviado por JoseHenriqueRJ em 25/06/2012 - 09:12h

Caro amigo Macbr, por favor, leia o seguinte, acho que vai te ajudar:

Existe no Linux um recurso muito interessante com relação a esse tipo de procedimento (su -, su), no qual o administrador de sistema poderá relacionar os usuários que poderão ou não executar o comando su, sem precisar alterar a permissão do comando.

Trata-se do arquivo suauth, localizado no diretório /etc. Geralmente esse arquivo não vem por padrão com as distribuições, e se vem, está em branco. Caso esse arquivo não exista, utilize o editor de texto de sua preferência para criá-lo. Veja a seguir o formato das linhas deste arquivo, que é bastante simples. Note que são utilizados dois-pontos (:) para separar os campos.

usuário1:usuários:ação

Em usuário1 é especificado o usuário no qual você se “transformará” ao executar o comando su; usuários, indica quem pode realizar esta tarefa, e ação poderá ter 3 valores: OWNPASS (pedir a senha do próprio usuário antes da mudança), NOPASS (não solicitar senha alguma) e DENY (nega o direito à execução do comando).

Para especificar mais de um usuário, separe-os com uma vírgula. Veja o exemplo a seguir:

# /etc/suauth
#
# Arquivo para controlar a execução do comando su no sistema.
root:alguém:OWNPASS
root:apaula,francis,roberta:DENY

Neste exemplo, é concedido ao usuário alguém o direito de executar o comando su para se transformar no superusuário e, para isto, ele deverá informar a sua própria senha (OWNPASS); já para os usuários apaula, francis e roberta é negado o direito de execução do comando su (DENY). Veja a seguir a mensagem apresentada para a usuária apaula, quando ela tenta executar o comando su.

apaula@host:~$ su -
Access to su to that account DENIED.
You are not authorized to su root
apaula@host~$

Já a ação NOPASS é muito perigosa para a segurança do sistema, pois garante o direito de se transformar no superusuário (ou em outro usuário especificado em /etc/suauth) sem a necessidade de digitar senha alguma. Agora, se você deseja que nenhum usuário execute o comando su em seu sistema, o mais prático é alterar sua permissão, deixando-o fora do alcance dos usuários comuns de seu sistema.

[9] Comentário enviado por m4cgbr em 27/06/2012 - 20:55h

JoseHenriqueRJ

Sou muito grato por ter disponibilizado seu tempo e escrever o texto acima de forma tão técnica e detalhada, muito obrigado e que isto seja útil (com certeza será) para outros usuários.

Obrigado por compartilhar.

[10] Comentário enviado por JoseHenriqueRJ em 27/06/2012 - 21:09h


[9] Comentário enviado por macgbr em 27/06/2012 - 20:55h:

JoseHenriqueRJ

Sou muito grato por ter disponibilizado seu tempo e escrever o texto acima de forma tão técnica e detalhada, muito obrigado e que isto seja útil (com certeza será) para outros usuários.

Obrigado por compartilhar.


Caro macbr, obrigado pelo apoio; mas, com certeza, eu que aprendo muito mais aqui.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts