Ferramentas do usuário

Ferramentas do site


redes:openssh_server_hardening

OpenSSH Server: Hardening

Configurações do SSHD

Você deve configurar o comportamento padrão do servidor OpenSSH, sshd, editando o arquivo /etc/ssh/sshd_config. Para mais informações sobre as diretivas de configuração desse arquivo, consulte o manual com o seguinte comando no terminal:

  man sshd_config

Faça um backup da configuração original antes de qualquer coisa:

  sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
  sudo chmod a-w /etc/ssh/sshd_config.original

Após ter feito o backup, e protegido esse arquivo contra gravação você pode editar as configurações.

  gksudo gedit /etc/ssh/sshd_config

Quando alterar alguma configuração você deve reiniciar o servidor.

  sudo restart ssh

Altere a porta padrão do Servidor

Por padrão, o SSH escuta a porta 22 e todo mundo sabe disso, incluindo os bots chatos que executam brute force e enchem os logs com tentativas falhas de login.

Na maioria dos casos, não tem problema deixar ele escutando em uma porta diferente.

Por exemplo se quiser, pode deixar na porta 22666:

  Port 22666

Para conectar ao servidor você deve agora usar -p para especificar a porta:

   ssh -p22666 [email protected]

Ou editar o arquivo ~/.ssh/config dessa forma:

  Host someserver.org.tld
  Port 22666
  User myusername

<note>Não se esqueça que se você estiver com o ufw (Uncomplicated Firewall) ativado, e você realmente deveria estar, precisará habilitar essa porta para receber conexão tcp.</note>

Restrinja a versão do protocolo

SSH1 está obsoleto e é considerado inseguro, na maioria dos casos é melhor forçar a versão 2 do protocolo:

  Protocol 2

Defina um tempo limite

Após um período de inatividade, as conexões que atingirem o limite serão automaticamente desconectadas. Neste caso, 5 minutos.

  ClientAliveInterval 300
  ClientAliveCountMax 0

O parâmetro informado em “ClientAliveInterval” deve ser informado em segundos. No exemplo acima, a conexão seria finalizada se o cliente ficasse inativo por mais de 300 segundos (ou 5 minutos). A opção ClientAliveCountMax define a quantidade de mensagens de “client alive” (parecido com um heartbeat, usado para saber se a outra ponta da conexão está ativa ou não) que podem ser enviadas para o cliente sem que este envie alguma resposta. O valor padrão é três. O efeito disso está descrito na página de manual do SSH.

Se você é do tipo que deixa as conexões ssh abertas o dia inteiro, isso vai te chatear um pouco, mas é uma coisa a se pensar, se usa ou não.

Defina o tempo limite de conexão

Você também pode definir o tempo máximo em que o usuário poderá ficar conectado ao servidor, após esse tempo a conexão será fechada, o tempo é informado em segundos. Usar o valor for 0 indica que o usuário pode ficar conectado o quanto quiser, o padrão é 120 segundos.

  LoginGraceTime 120

Ignore o arquivo .rhosts

O arquivo .rhosts era utilizado para identificar hosts nos quais o seu servidor confia. Este arquivo servia principalmente para configurar o conjunto de ferramentas comumente apelidado de “rtools”: rsh, rcp, rlogin, rwho e rexec. Todas estas em desuso atualmente, principalmente por causa da falta de segurança que acaba causando muita dor de cabeça. Enfim, como as ferramentas não são mais utilizadas justamente por não serem seguras, nós podemos falar para o sistema não confiar mais no rhosts. Como? Assim:

  IgnoreRhosts yes
  RhostsAuthentication no
  RhostsRSAAuthentication no

Rejeite logins sem senha

O motivo é óbvio.

  PermitEmptyPasswords no

Desabilitar login com senha

Devido ao fato de muitas pessoas usarem senhas fracas em seus usuários, pessoas com o objetivo de atacar computadores vão procurar por servidores ssh, então podem tentar acessar esses servidores usando senhas aleatórias, é possível testar milhares de senhas num período de 1 hora. Ao invés de senhas, utilize chaves ssh. Desabilitando a autenticação por senha, será possível conectar ao servidor apenas através de computadores que você tenha aprovado antes. Isso aumenta consideravelmente a segurança, mas torna impossível conectar ao seu próprio computador através de um computador de um amigo ou se de seu laptop se apagou acidentalmente a chave. É altamente recomendado desabilitar esse tipo de autenticação, até que haja motivo pra habilitá-la novamente.

Para desabilitar,procure a linha no arquivo sshd_config:

  #PasswordAuthentication yes

Mude para isso:

  PasswordAuthentication no

Desative a autenticação baseada em host

Eu só não vejo como isso possa valee a pena. Basicamente, desde que o ID de usuário no cliente exista no servidor, esse seria seria capaz de fazer login sem nenhuma senha. Usar chaves de autenticação SSH é uma forma muito melhor de conseguir isso.

Especifique quais contas podem usar o SSH

Você pode explicitamente permitir ou negar acesso para certos usuários ou grupos. Por exemplo, se você tem um PC para a família, onde a maioria das pessoas possuem senhas fracas, você provavelmente prefere que apenas você tenha acesso ao SSH.

Permitir ou negar acesso ao SSH para usuários específicos, aumenta significativamente sua segurança se os usuários com pouca noção de práticas de segurança não precisam de acesso ao SSH.

É recomendado especificar quais contas podem usar SSH se apenas poucos usuários precisam, ou não, utilizar o SSH.

Para permitir que apenas os usuários Fred e Wilma conectem ao seu computador, adicione a linha abaixo no arquivo the sshd_config:

  AllowUsers Fred Wilma

Para permitir que todos, exceto os usuários Dino e Pedrita conectem ao seu computador, adicione a linha abaixo ao arquivo sshd_config:

  DenyUsers Dino Pedrita

É possível criar regras mais complexas sobre quem pode usar o SSH, você pode permitir ou negar grupos específicos de usuário.

  AllowGroups sysadmin dba
  DenyGroups developers qa

Você pode ainda permitir ou negar usuários cujos nomes correspondem a padrões específics, ou se conectar de locais específicos. Para mais detalhes sobre regras complexas, veja a página man do sshd_config.

<note>Você pode combinar todas as diretivas Allow (permitir) ou Deny (negar). Elas serão processadas na ordem: DenyUsers, AllowUsers, DenyGroups, e finalmente AllowGroups</note>

Bloqueio do login direto do usuário root via SSH

Para fechar brechas, o bloqueio do acesso root direto por SSH é fundamental, o usuário deve autenticar-se e depois subir privilégios via su ou sudo. No arquivo sshd_config.

Descomente e altere a linha:

  # PermitRootLogin yes

Para:

  PermitRootLogin no

Use Chaves Públicas

Chaves públicas, ou Public keys, são a melhor maneira de evitar ter que digitar uma senha, e exatamente por isso aumenta e muito a segurança.

É óbvio que existem algumas questões de segurança a serem consideradas. A chave deve ser mantida em segurança pelo dono, em qualquer circunstância. Se alguém tiver acesso a chave privada do usuário, é o mesmo que entregar sua senha.

  RSAAuthentication yes
  PubkeyAuthentication yes

No lado do cliente, gerar o par de chaves:

ssh-keygen -t rsa -b 2048

a chave deve ser nomeada como id_rsa, que é o padrão, ou você terá que especificar o nome do arquivo da chave no cliente sempre que quiser conectar. Depois copie a chave pública para o servidor:

  $ ssh-copy-id [email protected]

ou

  cat ~/.ssh/id_rsa.pub | ssh [email protected] 'mkdir ~/.ssh;cat >> .ssh/authorized_keys'

Reinicie o servidor

Não se esqueça de reiniciar o servidor após qualquer alteração:

  sudo restart ssh 

Referências

redes/openssh_server_hardening.txt · Última modificação: 2015/08/19 15:52 por 8812