SSH 004: Configurações Mínimas em Nosso Servidor SSH para um Acesso com Mais Segurança

No post anterior, vimos sobre o protocolo SSH, se o ssh cliente e servidor estão instalados e preparamos um terreno para esse post.

Segue nossa estrutura

Esses passo a passos serão feitos apenas no servidor, ou seja, na máquina empresa100, com ip 192.168.0.40.

Após Instalado o SSH server, Quais os Primeiros passos para Garantir um mínimo de Segurança em minha Rede?

 

Após instalado o servidor SSH  já traz boas configurações por padrão, mas não podemos aceitá-las às cegas.

Podemos controlar o comportamento do nosso servidor de 3 maneiras:

1. configurações globais: que afetarão todo o sistema  do servidor SSH.
2. Configurações Por  Usuário: São praticadas por usuários finais. Afetam apenas o Servidor SSH na conta do usuário que está realizando essas modificações. As configurações SSH nas outras contas de usuários  não são alteradas.
   Um usuário, por exemplo, pode querer negar acesso ssh à sua conta.
3. Configurações durante a instalação/compilação: do nossos servidor SSH. Podemos escolher quais recursos incluir ou não no SSH durante sua configuração.

 

As configurações globais podem depender das configurações durante a instalação/compilação. Por exemplo, se optamos por não instalar uma determinada função durante a compilação do servidor ssh então essa função não ficará disponível para configurarmos mais tarde através das configurações globais.

Aqui iremos alterar algumas Configurações Globais do servidor SSH que nos dará seguranças minímas.

Configurações Globais do SSH

Podemos alterar as configurações globais do servidor ssh de duas maneiras,

1) através do arquivo de configuração

2) por linha de comando.

iremos alterar o arquivo, ou seja, usando o método 01.

No CentOS, o arquivo de configuração do servidor ssh é o “/etc/ssh/sshd_config”. Acesse ele usando seu editor favorito. Usarei o vim.

[elder@centos65 ~]$ sudo vim  /etc/ssh/sshd_config

Protocol: Versão do Protocolo SSH

Podemos escolher entre os protocolos SSH-1 e SSH-2. Por questão de segurança é bom evitarmos usar “Protocol 1(SSH-1).

Esse opção já vem como “Protocol 2” por padrão e assim não há o que alterar, mas citei aqui para conhecimento dos marinheiros de primeira viagem.

Port: Alterar Porta SSH no Servidor SSH

Após alterada a porta de 22 para 2222, você irá acessar o servidor ssh utilizando a opção “-p”

Exemplo,

elder@ubuntu:~$ ssh 192.168.0.40 -p 2222

A porta padrão de acesso para o servidor SSH é a 22.  Uma boa prática é alterá-la para um valor igual ou acima de 1024. portas abaixo de 1024 são reservadas pelo Sistema Operacional.

Alterar a porta pode evitar que “Robôs”, que ficam tentando encontrar IPs aleatórios na internet, encontre seu ip público e faça milhares de tentativas a fim de descobrir a senha SSH por força bruta. Vai por mim 🙂 Se deixar na porta padrão 22 e seu ip público acessível dentro de poucas horas irá ver muitas tentativas de acesso.

PermitRootLogin: Desativar Acesso do Usuário Root no Servidor SSH

Defina para “no” a opção PermitRootLogin.

Além da porta 22, o usuário root, além de todo poderoso, é um usuário que existe em todas as distros Linux. Se deixar acesso via ssh ao root e ainda a porta 22 definida estará dando quase que a faca e o queijo aos hackers: “Já tenho o ip, a porta e o usuário root.  ÊÊÊÊbba! Falta apenas a senha!” 🙂 

Altere porta, defina “PermitRootLogin no”

MaxAuthTries: Limitar Tentativas Máximas de Login  

limite as tentativas com falhas de login. Isso irá frustrar tentativas de “adivinhação de senha”.

Acima, deixei 2. Assim, tenho duas tentativas. Após isso, é bom definir um tempo de espera para novas tentativas.

LoginGraceTime: Tempo de Espera para Próximas tentativas

Após tentar logar 2 vezes e falhar, terei que esperar 2 minutos. Poderíamos aumentar esse tempo para 5 minutos(5m) ou 10(10m) 🙂

MaxStartups: Quantidade Máximas de Conexões Simultâneas 

O valor de MaxStartups é definido da seguinte forma

onde, com 10 conexões a probabilidade de rejeição das próximas será de 50%; com 20 conexões a rejeição será 100%, não aceitando mais nenhum nova.

Limitar essas conexões limitará ataques de DOS(Denial of Service) ou DDOS(Distributed Denial of Service). Também evitará que muito mais pessoas em um ambiente de trabalho acessem de forma a esgotar a memória ram ou outro recurso do seu servidor.

 

PubkeyAuthentication:  Autenticação usando um par de chaves

Essa configuração é muiiiito recomendada!!!

Quando PubkeyAuthentication é definida como yes a função de login(modo de acesso) por meio de chaves é habilitada.

Iremos criar um post sobre esse assunto, visto a sua importância! mas para entendermos seu funcionamento básico insiro abaixo algumas linhas:

• No computador cliente, que você usa para acessar o servidor ssh, usamos o comando ssh-keygen para gerar um par de chaves: uma chave privada e outra pública.
• Enviamos a chave pública para o servidor ssh e a inserimos ao final do arquivo “/home/elder/.ssh/authorized_keys”
• Opcional, mas Recomendado: No arquivo “/etc/ssh/sshd_config” definimos “PasswordAuthentication no”

Bom, esse último método , PubkeyAuthentication  yes, é fortemente recomendado. Mas temos que ter a garantia que o acesso via chaves está funcionando antes de colocar PasswordAuthentication no.

O próximo post será sobre a geração e uso do par de chaves.

 

Conclusão

As medidas acima são básicas mas primordiais após instalação dos serviços de ssh.

Reforçando, “PasswordAuthentication no” deve ser usado apenas quando estamos certos do funcionamento das chaves. Se chegarmos a enviar a chave pública para o servidor ssh e, por exemplo, inserirmos por engano outra pública chave no arquivo authorized_keys ou apagar, sem querer querendo, todo o conteúdo dentro de authorized_keys ficaremos sem acesso e para consertar teríamos que ir até o local de instalação do servidor para realizar as devidas correções. Isso se o servidor ssh não ficar situado em outra cidade.