SSH Hardening: como melhorar a segurança do seu SSH

O hardening, na área de segurança, é o processo de se aumentar a segurança de um serviço ou servidor como um todo através de configurações finas do sistema. Esta é talvez a tarefa mais importante pela qual você é responsável como um administrador de redes ou sistemas e deve ser feita em novos servidores ou mesmo em servidores que já estão em produção para reduzir os riscos a que você está expondo os seus dados.

Todo sistema operacional e todo serviço rodando nele possuem configurações para melhorar a segurança (ainda que muito pouco). No post de hoje você vai aprender a melhorar a segurança do SSH, um dos serviços mais importantes e populares presente em 99% dos servidores Unix.

NOTA: Tirando os itens “Usar port knocking” e “Se mantenha atualizado”, todas as configurações mostradas abaixo podem ser feitas através do arquivo sshd_config. Geralmente este arquivo está localizado no /etc/ssh, porém a localização na sua distribuição pode variar.

Não permitir login como root

Permitir que o root faça login via SSH é o maior erro que um administrador pode cometer. Primeiro, isso já facilita a vida do atacante pois ele não precisa adivinhar o nome de usuário do qual ele vai tentar adivinhar a senha já que ele pode usar o root, que é o padrão em todo sistema *nix (e descobrir qual sistema operacional está sendo executado por um host não é tão difícil assim. Basta um scan com NMap para descobrir). Segundo, se ele vier a adivinhar a senha, já era. Ele tem poder total no seu sistema e você não pode fazer mais nada pra segurar ele.

Felizmente, impedir que o root faça o login no sistema é bem simples. No arquivo sshd_config procure pela linha PermitRootLogin e mude para “no”:

PermitRootLogin no

Assim, outros usuários poderão fazer o login via SSH porém a conta root não conseguirá. Não se esqueça de criar um outro usuário no sistema e adicioná-lo a um grupo que tenha permissões para logar remotamente (veremos como fazer isso abaixo) para que você consiga usar o SSH.

Definir quais grupos e/ou contas de usuários podem fazer login via SSH

Além de impedir que o usuário root faça o login remotamente via SSH, é uma boa ideia que você também especifique quais usuários e/ou grupos podem fazer o login remoto. Para isso, existem algumas opções que você deve encontrar (ou adicionar) no arquivo de configuração:
AllowUsers
DenyUsers
AllowGroups
DenyGroups

Basta colocar os nomes de usuários ou grupos separados por espaço seguido das opções que começam com Allow para permitir o login ou das opções que começam com Deny, para bloquear o login:
AllowUsers joao maria jose
Denygroups rh controladoria visitantes

Assim, escolhendo a opção correta, fica bem simples controlar quem pode e quem não pode fazer o login.

Não permitir senhas em branco

Não permita que senhas em branco sejam aceitas pelo sistema. Acho que o motivo é óbvio, né? Para impedir que senhas em branco sejam aceitas, procure pela linha PermitEmptyPasswords e mude o valor para “no”:

PermitEmptyPasswords no

Fazer autenticação com chaves e não senhas

Esta dica vale ouro e passar a usar chaves ao invés de senhas sozinho já aumenta e muito a segurança do seu sistema. Já expliquei passo a passo como fazer esta configuração no post “SSH sem senha: autenticação através de certificados RSA“.

Recomendo que você vá lá e dê uma lida para apender a configurar mais esta proteção para o seu sistema.

Usar port knocking

O port knocking é um esquema muito interessante. Quando configurado adequadamente, ele fará com que uma determinada porta só seja aberta depois de o host enviar pacotes para um conjunto específico de portas e na ordem correta. Como existem mais de 65 mil portas em um sistema, adivinhar a combinação é bem complicado! É uma boa ideia combinar o port knocking com a dica de fazer com que o SSH use uma outra porta que não a 22.

Já fiz um post bem detalhado sobre como configurar o port knocking em “SSH Port Knocking“. Dê uma lida lá para mais informações sobre como implantar esta medida de segurança no seu servidor.

Forçar o uso da versão 2 do protocolo

A versão 1 do protocolo SSH possui falhas seríssimas de segurança que minam qualquer medida que você tome para aumentar a segurança do sistema. Por isso, você deve sempre forçar o uso da versão 2 do protocolo onde possível. Para isso, procure pela linha Protocol no sshd_config e deixe ela assim:

Protocol 2

Assim, o seu servidor SSH vai exigir que apenas a versão 2 do protocolo (considerada segura enquanto escrevo este texto) seja usada.

Modificar a porta padrão

Muitos atacantes fazem robôs que varrem a Internet fazendo um sweep atrás de hosts com a porta 22/TCP aberta. Isso facilita a vida pois identifica rapidamente hosts que podem ter o SSH habilitado e aceitando conexões de qualquer host na Internet. Se você não utilizar a porta padrão 22 (nem uma variação boba, tipo 2222) você já consegue se livrar de vários destes robôs, podendo ficar mais tranquilo.

Para mudar a porta na qual o SSH vai escutar, procure a linha Port logo no começo do arquivo e mude o valor dela para qualquer outro que esteja livre no seu sistema (de preferência, use valores de portas maiores que 1024):

Port 35670

Lembre-se que, depois de mudar a porta padrão do serviço, você vai precisar especificar a porta correta quando for se conectar via PuTTY ou mesmo usando o cliente SSH na linha de comando:

$ ssh -p 35670 usuario@192.168.0.1

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

É muito provável que o arquivo de configuração do seu servidor já tenha estas opções configuradas dessa maneira. Mas é sempre bom ter certeza de que tudo está certo, por isso é uma boa ideia verificar e ficar tranquilo! :)

​

Ative os timeouts

É muito comum que durante o dia nós precisemos sair das nossas mesas para irmos a alguma outra sala, tomar uma água, ir ao banheiro, etc. Nestas ocasiões, nem sempre nos lembramos de bloquear a nossa máquina onde estamos conectados ao servidor via SSH. O que, obviamente, é um grande risco para a segurança.

Por isso, é sempre interessante que você configure um timeout que irá desconectar do servidor depois de um tempo de inatividade. Para isso, edite ou adicione as seguintes linhas:
ClientAliveInterval 300
ClientAliveCountMax 3

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 (traduzido livremente por mim):

“Se ClientAliveInterval for configurada para 15, e ClientAliveCountMax é deixada no valor padrão de 3, clientes SSH que não responderem serão desconectados em aproximadamente 45 segundos.”

Use o sudo

Não só não é bom deixar que o root faça login via SSH, como também não é bom que qualquer usuário (por mais experiente que seja) use esta conta no dia-a-dia. O ideal é que você instale e configure o sudo nos seus servidores para que cada usuário use a sua própria conta e para que todas as atividades executadas com poderes de root sejam devidamente logadas.

Já detalhei bastante a configuração do sudo no post “Como configurar e usar o sudo“. Recomendo que você vá lá e dê uma boa lida em como fazer e implante a ferramenta no seu servidor assim que possível!

Se mantenha atualizado

Deixar o seu sistema desatualizado vai fazer com que você fique vulnerável mesmo que siga à risca todas as dicas acima. É importantíssimo que você sempre utilize as versões mais recentes de todos os softwares instalados na máquina e que aplique as correções de segurança assim que elas são disponibilizadas.

Porém, cuidado ao aplicar patches e instalar novas versões em sistemas que estão em produção pois isso pode acabar fazendo com que o serviço em questão pare de funcionar. O ideal é que você utilize máquinas virtuais que imitam o ambiente de produção e teste tudo nestas VMs antes de aplicar as correções ou instalar novas versões no host de produção. Isso já diminui muito a chance de alguma coisa dar errado e você consegue se manter seguro.

Não seja preguiçoso: assim que patches forem lançados, teste e os aplique nos seus hosts.

Reinicie o serviço depois de fazer todas as configurações!

Depois que você analisar todas as dicas acima e adaptá-las ao seu ambiente, salve e feche o arquivo sshd_config. Para fazer com que todas as alterações entrem em vigor você vai precisar reiniciar o serviço. O modo de reiniciar o serviço varia um pouco de distribuição para distribuição. No Ubuntu e no CentOS você pode usar o comando service:

# service sshd restart

A diferença é que no Ubuntu você precisa colocar o “sudo” na frente do comando para executá-lo como root.

Conclusão

O hardening não é o tipo de coisa que você pode deixar pra depois. Em novos servidores, é interessante que você tenha uma checklist de tudo o que é necessário fazer para ter um servidor mais seguro assim que ele entrar em produção. Porém, também é necessário que você faça o hardening em servidores que já estão em produção. Estes são os seus principais alvos já que eles já oferecem riscos à sua infra por estarem em produção sem as devidas medidas de segurança.

No geral, aquelas dicas de sempre também valem: mantenha seus servidores sempre atualizados; configure o seu firewall corretamente; não seja preguiçoso, faça tudo da maneira segura e não da maneira fácil e conheça bem a sua rede e as ameaças.

​

​Creditos: Pedro Pereira