Implementando segurança no SSH

THenrique

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

[ Hits: 20.804 ]

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

1 1

Denuncie Favoritos Indicar Impressora

Restrinja o acesso à usuários específicos com as diretivas AllowGroups e AllowUsers

Através da diretiva AllowUsers você pode informar um ou mais usuários cujo acesso ao SSH estará liberado.

Se você especificar algum usuário nesta diretiva, à todos os demais usuários que não estiverem nesta lista, o acesso ao SSH será bloqueado. Por exemplo, a linha abaixo somente permitirá que os usuários "thiago" e "joao" acessem o SSH:

# vim /etc/ssh/sshd_config

Após abrir o arquivo, basta inserir a linha abaixo:

AllowUsers thiago joao

A diretiva AllowGroups funciona de maneira idêntica, porém, ao invés de validar o usuário em si, ela irá validar se o usuário está em algum dos grupos cujo login está liberado. Isto é especialmente interessante quando você tem uma rotatividade grande de usuários cujo login será liberado, e não quer ficar editando o arquivo de configuração a todo momento. Neste caso, basta criar um grupo, por exemplo, "allowssh":

# groupadd allowssh
# groupmems -a thiago -g allowssh
# groupmems -a joao -g allowssh

E incluí-lo no AllowGroups:

# vim /etc/ssh/sshd_config

Agora, basta inserir a linha permitindo acesso SSH ao grupo allowssh:

AllowGroups allowssh

Basta reiniciar o SSH, e após isto ninguém que não estiver no grupo allowssh conseguirá realizar login no sistema.

# /etc/init.d/sshd restart

Nunca, jamais, never e em hipótese alguma permita o acesso do root via SSH

Esta é uma das dicas que você mais vai encontrar se pesquisar sobre segurança em SSH. Proibir o login do root através do SSH fará com que qualquer usuário que quiser realizar login tenha que subir com um usuário comum, e somente depois de já estar no SSH, efetuar login como root através do comando su.

Isto diminui muito as chances de algum atacante conseguir subir como root em seu servidor, pois, qualquer tentativa de login como root diretamente irá falhar. Além disto, com esta mudança, caso algum atacante queira invadir seu sistema, ele deverá primeiro deduzir o nome de um usuário válido em seu sistema.

Para isto, basta alterar a diretiva PermitRootLogin para "no".

# vim /etc/ssh/sshd_config

Agora basta inserir a linha permitindo acesso SSH ao grupo allowssh:

PermitRootLogin no

Depois disto, basta reiniciar o serviço de SSH e o root não poderá mais realizar login via SSH.

# /etc/init.d/sshd restart

Página anterior Próxima página

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

Implementando a segurança em servicos de acesso remoto

Buffer Overflow: Entendendo e explorando

Cliente "automágico" Linux logando no domínio NT/Samba

Instalação e configuração do Snort Inline (modo IPS), Baynard2, Mysql e PulledPork no Debian Squeeze

Bom escudo não teme espada: o módulo pam_cracklib

Comentários

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

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

0 0

[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.

0 0

[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;

0 0

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

Muito bom o artigo , Parabéns

0 0

[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!

0 0

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

Muito bom!

0 0

[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+

0 0

[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.

0 0

[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.

0 0

[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.

0 0